안녕하세요.

Request Virtual Machine Service Request 항목은 Reviewer의 승인(Approve Virtual Machine)이 필요합니다.
- 라이브러리 > 템플릿 > Request Virtual Machine Service Request 선택 후 속성 클릭 > 창 닫은 후 마법사에서 작업 클릭

CSPP 에 대한 구성이 완료는 됐지만 여러분은 항상 Service Manager 콘솔에 가야만 확인할 수 있고 승인 버튼 즉 Appove을 할 수 있을까요?

아마도 여러분은 Review 요청을 메일로 수신하고 메일로 즉시 답변하고 싶겠죠. 이번에는 Review 요청을 메일로 수신하고 다시 메일로 간단하게 Approve 하는 방법에 대해 알아보겠습니다.

Exchange Connector 구성

먼저 Exchange에 사용자 메일 박스를 하나 만들어 줍니다.
예를 들어 SCSMHelpDesk 라고 하겠습니다. 자 그렇다면 사용자 메일 박스는 SCSMHelpDesk@contoso.com 이 되겠죠… :)
그런 다음 Exchange Server Auto Discovery을 위한 DNS 설정을 추가 합니다.
예를 들어 사용하고 있는 Domain 명이 contoso.com 이라면 contoso.com에 새로운 SRV 레코드를 추가 합니다.
- Service : _autodiscover
- Protocol : _tcp
- Port Number : 443
- Host : Ex01.contoso.com (저는 임의로 Ex01을 Exchange 서버로 삼았습니다.)

자 여기까지 끝났으면 필요한 준비 작업은 끝났습니다. 이제 Exchange Connector와 연동해야 되겠죠.

먼저 Exchange Connector 3.0을 다운 받습니다.
http://www.microsoft.com/en-us/download/details.aspx?id=38791
3.0은 SCSM 2012 SP1의 Rollup 2 이상 부터 지원 됩니다.. 물론 R2도 지원 하구요.

Exchange Connector을 이용하게 되면 필요한 간단하게 Incident ID와 Message Body만으로 SCSM의 여러 Action들을 Control 할 수 있습니다. 예를 들면 만약 Incident ID가 IR1234 라면 메일 제목을 IR1234로 쓰고 메일 본문에 필요한 Activity 즉 [Closed] 또는 [Resolved]등을 기입하는 방식이죠.

자세한 설치 방법 설치 파일과 함께 제공되는 SM2012_EC_DepGuide을 참고 하시면 됩니다.

자 여기까지 됐으면 필요한 Activity을 SCSMHelpDesk@contoso.com 에 메일로 보내게 되면 필요한 과정을 진행하게 됩니다. 하지만 아직 Notification이 오지는 않죠.
지금부터는 Reviewer 에게 Notification을 보낸 방안을 설명하도록 하겠습니다.

Notification Channel 구성

먼저 Notification Channel을 설정해야 합니다. SCSM 관리 콘솔에서 관리를 선택한 후 알림 > 채널을 선택합니다.

내용을 보면 이미 “전자 메일 알림 채널”이 만들어 졌는데, 여기에 우리는 메일 발신을 위한 SMTP만 등록해주면 되죠. 물론 전자 메일 주소 반환 항목에는 이미 설정해 놓은 SCSMHelpDesk@contoso.com을 등록 합니다.

(여담으로 이전 글에서는 SCVMM에 대한 이해와 함께 Private Cloud 운영에 대한 이해가 필요 했는데, 이번에는 DNS에서 부터 Exchange 그리고 SMTP 설정까지를 담고 있군요… ㅜㅜ 쉽지 않습니다.)

Notification Template 작성

자 채널까지 만들어 졌으니 이젠 Notification을 템플릿을 작성해야 겠죠?
먼저 알림>템플릿을 클릭 합니다.

우측의 작업 창에서 “전자 메일 템플릿 만들기”을 클릭 합니다.

이때 대상 클래스는 검토 작업으로 해주셔야 합니다.
아래의 찾아 보기를 클릭한 후 검토 작업을 선택 해주시면 되겠죠… :) 영어로는 Review Activity 가 되겠습니다.

특히 템플릿 디자인에서 삽입 버튼을 누르면 메일 제목 및 본문에 다양한 필요한 내용을 넣어 줄 수 있습니다.
예를 들어 아래와 같이 작업 항목에 ID를 선택한다면

아래와 같이 자동으로 필요한 내용들이 삽입되게 되는 거죠.

자 이제 필요한 템플릿을 만들었습니다.
(물론 마지막에 해당 템플릿에 대한 Exchange Connector을 이용한 관리를 위해 추가적인 설정이 필요합니다만… 마지막에 다루기로 하고…)
이제는 Review 요청이 오면 바로 메일이 오도록 설정해 줘야 합니다. 보통은 구독이라고 하죠.

Workflow을 통한 메일 보내기 설정 하기

구독에 대한 설정 역시 관리 > 알림 > 구독 부분에서 할 수 있습니다.
역시 관리 > 워크플로 > 구성 에서 “작업 이벤트 워크플로 구성”을 선택 하고 우측 작업 창의 “워크플로 규칙 구성”을 클릭 합니다.

클래스 선택에서 검토 작업을 선택 합니다.
 

이렇게 하여 워크플로 구성 창이 뜨게 되면 새로운 워크플로를 추가 하면 됩니다.
이때 이벤트 확인란은 “개체를 업데이트하는 경우”을 선택합니다.

당연히 작업의 상태가 진행 중일 때 받으면 않되겠죠.

마지막으로 알릴 사람 선택에 가면 이전에 만들어 놓았던 메시지 템플릿을 확인할 수 있습니다. 당연히 알림 사용 클릭 후 추가 해야겠죠… : )

메일 본문에 승인 버튼 넣기

자 드디어 마지막 작업 입니다. 바로 메일 본문에 승인 버튼을 넣는 건데요. 이미 설명 드린 바와 같이 SCSMHelpDesk@contoso.com 에게 메일 제목은 “WorkItem ID” 메일 본문은 승인 하는 경우 “[Approved]” 거절하는 경우 “[Rejected]” 라는 내용을 삽입하여 메일을 쓰게 되면 간단한 승인 또는 거절이 가능한데요. 이 부분을 그때 그때 마다 메일을 받는 담당자가 직접 SCSMHelpDesk@contoso.com 에 내용을 적어서 보내는 건 좀 그렇죠?
그래서 간단한 꼼수를 알려 드립니다.

이미 우리는 메시지 템플릿을 만들어 놨습니다.
이제는 본문에 메일 보내기에 대한 하이퍼링크만 달아 주면 간단하게 해결이 됩니다.
제 경우는 다음과 같이 하면 되겠죠?

<a href="mailto:SCSMHelpDesk@contoso.com?subject=[<insert the work item ID here>]&body=[Approved]">Approved</a>
<br/>
<a href="mailto:SCSMHelpDesk@contoso.com?subject=[<insert the work item ID here>]&body=[Rejected]">Rejected</a>

이렇게 해 놓으면 아래와 같이 Approved 또는 Rejected 에 대한 링크가 뜨고 해당 링크를 클릭하면 바로 메일이 하나 생성이 됩니다. 여러분은 그저… Send 버튼만 누르시면 모든일이 완료 되게 되죠… :)

여기까지 따라온 당신이라면 다른 주제들에 대해서도 최고가 되리라 확인 해 봅니다.
그럼 다음에 다른 주제로 다시 찾아 뵙겠습니다.

출처 : http://blogs.technet.com/b/servicemanager/archive/2011/02/08/tricky-way-to-handle-review-activity-approvals-with-the-exchange-connector.aspx

여러분의 시스템에 System Center Service Manager 가 인스톨 되어 있다면 CSPP을 추가로 인스톨 하는 것 만으로 Private Cloud 시스템을 구축 할 수 있습니다.

특히 CSPP의 경우 Service Manager의 Cloud 관리를 위한 결제 프로세스와 같은 Workflow 및 여러 데이터 센터 작업에 대한 Orchestrator 의 Runbook을 자동으로 생성해주기 때문에 실제 구현 시 단순 Installation 작업 및 몇몇 Configuration 작업 만으로 자신만의 Private Cloud 데이터를 만들 수 있습니다.
(특히 Microsoft에서 미리 정의 해 놓은 Private Cloud의 여러 Workflow 를 바로 쓸 수 있다는 장점이 있죠.)

CSPP에 다가가기 위한 Required Knowleadge 에 대해 알아보겠습니다.

Cloud Service는 실제로는 VMM의 리소스를 의미 합니다. 우리는 VMM에서 이미 구현 되어 있는 여러 가지 서비스 특히 VM Template과 같은 형태의 서비스를 사용하기 위하여 먼저 해당 Cloud Service을 구독 즉 Subsciption 하게 되는데, 이는 다음의 문서를 통해 확인 할 수 있습니다.
Cloud Services Terminology : http://technet.microsoft.com/en-us/library/hh872874.aspx
About Cloud Services User Roles : http://technet.microsoft.com/en-us/library/hh872827.aspx

VMM을 통해 구현된 Cloud는 실제로는 추상화된 Infrastructer 와 아주 잘 Provisioning 된 서비스의 리스트 (VM Template을 포함)로 볼 수 있는데요. 이는 그 상위 레벨에서 사용자는 Tenant 단위로 관리되게 됩니다. 먼저 사용자는 Tenant 를 요청하게 되고, 이후 생성된 Tenant에 필요한 Cloud 리소스들을 Subscription 즉 사용할 수 있도록 할당해줍니다. 다시 말해 Tenant 는 Cloud 관리자에게 VMM을 통해 이미 만들어진 Cloud 및 Cloud을 이루고 있는 리소스에 대한 구독 즉 Subscription을 요청하고 이러한 기본적인 작업이 완료된 이후 우리는 VM의 생성 및 Update을 간단한 서비스 요청으로써 제공 받을 수 있습니다.
Process Workflows : http://technet.microsoft.com/en-us/library/hh872838.aspx

자 시작하기 전에 Virtual Machine Manager의 리소스에 대한 이해가 필요한데요. 아래의 사항에 대해서만 이해 하시면 됩니다.
About Virtual Machine Manager Resources : http://technet.microsoft.com/en-us/library/hh872828.aspx

설치가 완료된 이후에는 몇 가지 수동으로 진행해야 하는 작업들이 있습니다. 먼저 Connector을 만들어 줘야 합니다. 특히 기본적으로 VMM, Orchestrator OM 그리고 AD에 대한 Connector가 필요하며 아래의 문서를 참조 하시면 됩니다.
Create Connectors : http://technet.microsoft.com/en-us/library/hh872851.aspx
위의 문서는 여타 System Center 제품과의 연동은 정리되어 있습니다. 다만 하나 ”아! AD는 빠져 있군요.”
아래와 같이 System Center 및 AD와의 연동을 마무리 지었습니다.

여러 가지 설정을 해놓고 실제 VMM의 리소스 내역을 봤더니… 음… 아무 내용도 없군요.

자 이제 Conntor 설정은 모두 끝났고 VMM Resource에 대한 설정을 진행 해야 합니다.
Configure Virtual Machine Manager Resources : http://technet.microsoft.com/en-us/library/hh872818.aspx

위의 설정까지 완료가 됐다면 Service Manager에서 어떻게 Cloud 서비스를 다룰지를 설정해 줄 필요가 있습니다.
그 중 가장 우선 진행 해야 하는 것이 Tenant ID 및 Cloud Resources Subscription ID 대한 Prefix을 정의해 주는 거겠죠.
Configure General Properties : http://technet.microsoft.com/en-us/library/hh872839.aspx
그 외에 비용과 관련된 부분 설정이 필요 합니다. (VM별 비용 설정 및 Cost Center / 부서별 비용 코드 설정)
Configure Cost Properties : http://technet.microsoft.com/en-us/library/hh872830.aspx
Create Cost Center : http://technet.microsoft.com/en-us/library/hh872853.aspx

자 이제 CSPP의 Installation 만으로 간단한 (나름… 간단한…) Private Cloud 구축에 대해 알아봤습니다.
관리에 대한 부분은 아래의 URL을 참고하시면 됩니다.
CSPP Administration : http://technet.microsoft.com/en-us/library/hh872820.aspx

안녕하세요.
9월 20일 Windows 서버 2012 제품 발표회 ITDM LG CNS 사례때 사용한 발표 자료 입니다.

Windows 2012 제품 발표회.pdf

이전에 이야기했던 TLB Flushing으로 인한 성능 저하 문제에 대해 확인해봤는데, 아래와 같습니다.
이전 글 http://maystyle.tistory.com/556

처음에는 TLB가 무조건 Flushing이 되서 성능 이슈가 생겼다는거죠.
그러다 보니 이에 대한 고려가 필요하게 된거구요.

그래서 VPID 값을 주고 해당 VPID가 Active 라면 녀석의 TLB는 Flushing 하지 않도록 고쳤다는 것입니다.
결론은 Active 상태의 VPID 값이 사용중인 TLB는 Flusing 시키지 않는 다는 거죠

그리고 왜?? 이녀석과 SLAT와 같이 봐야하냐면 SLAT와 같이 활성화 되면 더욱 성능에 도움이 되기 때문 입니다.

음 제가 MS 올 때 받았던 질문이기도 하고…
깊게는 이야기 하지 않고 딱 고객이 질문하면 대답할 수 있는 수준만 정리해봤습니다.
결론만 보실려면 맨 아래 영문만 보시면 됩니다.

먼저 하이퍼 스래딩을 알려면 CPU 구조 중 파이프라인과 수퍼 스칼라를 알아야 합니다.

먼저 파이프 라인을 알아 보겠습니다.

CPU의 성능을 높히기 위해서는 어떻게 해야 할까요?

1. 당연히 처리 속도를 높힌다.
2. 그리고 단위 시간당 처리할 수 있는 양을 늘린다.

음 1번과 2번이 같은 이야기로 들리시나요?
다시 CPU에서 명령어가 실행 된다 함은 “메모리에서 읽어서 > 해독하고 > Operation Code를 찾아 내어 > 해당 코드를 실행 하고 > 결과를 적제 한다.” 정도가 되겠죠?

자 이렇게 명령어가 한 사이클 동작한다고 했을때 다음과 같은 가정을 해 봅니다.

1. 5단계의 과정이 다 끝난 이후 다음 명령어가 실행 된다.

명령어 처리는 분명 5단계라는 가정을 했습니다. 즉 특정 명령어는 분명 5단계 중 하나의 단계인 상태로 남아 있을 것이고, 이는 나머지 4단계를 처리하는 모듈들은 모두 쉬고 있다라고 볼 수 있는 것이죠.

그래서 명령어는 CPU는 각 단계를 통해 실행 되고 해당 단계가 완료 됐을 때, Pipe line을 통해 다음 실행 단계로 전이됩니다. 이 기술을 파이프 라인이라고 부르며 이를 통해 단위 시간당 처리 량을 늘릴 수 있죠.

자 이제는 수퍼 스칼라 구조에 대해서 알아보겠습니다.

그런데 파이프 라인만으로는 처리률을 늘리는데 한계가 있습니다.
자 다음과 같은 코드를 생각해 보겠습니다.

1. a1 = a0 + 1
2. a2 = a1 + 5
3. b1 = b2 +b3
4. c0 = c1 +4

각각이 하나의 명령어라고 볼 때, 1번과 2번은 1번 명령어가 첫번째 “메모리에서 읽어서”가 진행 된 이후 2번이 진행되기가 어렵습니다. 왜냐? 2번은 1번 과정이 끝난 이후 즉 1번 과정에서 결과를 적재한 이후 a1 을 읽어서 진행해야 하기 때문이죠. 물론 recursive 하게 호출하는 방식으로 병렬 처리율을 높히기는 하지만 말이죠. 하지만 코드를 자세히 보니깐 음… 3번과 4번은 1번과 2번과 같은 종속성이 없군요. 자 그렇다면 3번과 4번을 먼저 실행하는건 어떨까요? 이렇게 하기위해서는? 파이프 라인이 병렬로 있으면 되겠군요! (물론 비 순차 실행을 위한 여러 도구가 필요하긴 합니다.)

그래서 현대의 Processor는 파이프라인을 병렬로 여러개 가지게 돼었습니다.

그리고 이런 명령어 수준의 병렬화 처리 다시 말해 처리 집적도를 높혀주기 위해서 비 순차 수퍼 스칼라 파이프 라인 구조를 탄생하게 됐습니다.

그!런!데! 지금까지 전 명령어 수준의 즉 Instruction 수준의 병렬화만 이야기 했죠.
다시 쓰래드 수준의 병렬화가 이루어진다면 해당 명령어들 사이의 종속성은 훨씬 줄어 들게 되고, 다시 이 병렬 파이프 라인들을 더욱 효율적으로 사용하게 될 수 있지 않을까요? 그래서 지금의 Processor 들은 쓰래드 간의 병렬화를 지원하기 위한 하이퍼 쓰래딩 기술이 적용되게 됐습니다. 단지 쓰래드들간의 문맥 교환 비용 완화를 위한 약간의 레지스터가 필요했을 뿐이니깐요. (펜티엄 4에서 하이퍼 쓰래딩 구현을 위한 레지스터로 인한 증가량은 단일 면적에 비하여 약 5% 수준이라고 합니다.)

자 다시 말하면 명령어를 처리하는 파이프 라인을 빈틈 없이 꽉 채워 쓰기 위해서 하이퍼 쓰래딩 기술이 나왔다고 할 수 있습니다. 하지만 하이퍼 쓰래딩 환경은 실제로 케시 및 비 순차 실행 (위에서 설명한 1~4까지의 코드 실행을 생각해 보면 알 수 있습니다.) 으로 인한 불균형 문제가 발생 할 수 있습니다. 먼저 비 순차 실행은 이발소 문제와 같은 스래드 간의 기아 조건을 야기 시킬 수 있고, (즉 실행하는 쓰래드만 열라 실행하게 되는….) 이를 위한 여러가지 해결 책들이 적용되고 있음에도 쉽지 않음이 사실입니다. 또한 실행하는 쓰래드들 간의 캐쉬가 충돌을 일으키는 경우에도 성능저하가 발생하게 됩니다.

하지만 그럼에도 불구하고 인텔에서는 약 30% 정도의 성능 향상 효과가 있다고 이야기 하고 있습니다. 더불어서 현재의 Windows 2008 R2의 경우 하이퍼 쓰래딩을 aware 하여 CPU 스케줄링을 하고 있습니다. (이전에는 잘 모르겠습니다… ㅡㅡ;;;)

하지만 결론은 무조건 하이퍼 쓰래딩을 Disable 시키는 것은 아니다 정도가 되지 않을까 합니다.
더 나아간다면 실제 성능 측정을 통한 방법 많이 이익인지 불이익인지를 명확하게 판가름하는 방법이 아닐까 합니다.

SQL Server에서의 적용에 대한 저희 문서는 아래와 같이 이야기 하고 있습니다.

”The performance of hyper-threaded environments varies. Conservative testing has shown 10 to 20 percent gains for SQL Server workloads, but the application patterns have a significant affect. You might find that some applications do not receive an increase in performance by taking advantage of hyper-threading. If the physical processors are already saturated, using logical processors can actually reduce the workload achieved.
For example, applications that cause high levels of contention can cause decreased performance in a hyper-threaded environment. We recommend that you test your application thoroughly to make sure that a hyper-threaded environment provides you the performance gain that you want versus the purchase of equivalent physical CPUs. Hyper-threading can be very helpful but hyper-threading cannot replace the full power of an additional physical CPU.
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.”
출처 : http://support.microsoft.com/kb/322385/en-us

Hyper-V 관점에서는 64개 까지 LP를 지원 함으로 이에 따라 Hyper Thread 사용 여부를 판별 하면 됩니다.

Exchange는 아직까지는 Disable이 권고 입니다.

SQL Server는 2000까지는 Disable 이후에는 위에 언급한것과 같이 TEST후 적용 입니다.

오늘 글을 연속 3개 올리는군요.
너무 블로그를 소홀히 했던거 같습니다.

그리고 항상 그렇지만 제 글은 항상 약 50%의 신뢰도만 갖는다는거… 무책임하게 그러면서 왜 글을 올리냐고 물어보면 할 말은 없지만…ㅡㅡ;;

Windows 2003과 Windows 2008 간의 인스톨 및 Role / Feature 추가에 대한 차이점

Windows 2003의 경우 필요한 Binary 파일을 CD 및 Service Pack으로 부터 읽어서 System32 밑에 기록합니다.

Windows 2008의 경우 설치 시 모든 컴포넌트 (Role 및 Feature를 위한 설치 파일, 설정, 레지스트리의 합본)를 우선 WinSxS에 Staging (아직 사용은 하지 않는 즉 System 32 밑에 Hard Link를 생성하지 않는 다시 말해 비 활성화된)해 놓은 후 실치될 파일들만 확인하여 System 32 밑에 기록 (Hard Link의 생성 / Projection) 합니다.

그러므로 Windows 2008에서 항상 이야기하는 “설치본이 통합 됐다.” 라는 말의 의미를 WinSxS 를 의미합니다.

다시 잠깐… 그렇다면 System 32와 WinSxS에 파일이 2개가 동시에 존재 하는 게 아닌가? 하는 의문이 듭니다.

그렇지 않습니다. HDD에 존재하는 파일은 1개 이며, 이에 대한 Hard Link가 2개가 존재 하는 것입니다.

어 파일이 동일하고 Disk에 Allocate 되는 위치도 같은데 그럼 왜? WinSxS의 크기는 커지는 거야?

버전업이 된 컴포넌트들은 당연히 System32밑에 바로 적용이 되게 됩니다. (System32는 예를 들어서 설명하기 위한 위치 이며 컴포넌트에는 바이너리 파일 부터 레지스트리 설정 파일들까지의 합을 의미하는 것이므로 항상 System 32 밑에 존재 하지는 않습니다.)

하지만 이전 버전들의 a.exe 가 완전히 사라지지 않습니다. 단지 WinSxS에 남겨 두게 됩니다.

다시 말해서 1.0 버전의 a.exe가 있습니다. 이는 System32\a.exe v1.0 과 WinSxS\a.exe v1.0이 있다는 의미 입니다. 그러므로 파일 Allocate Size는 같습니다.

그리고 이 a.exe가 1.1 버전으로 Upgrade 되게 되면 System32\a.exe v1.1 과 WinSxs\a.exe v1.0, a.exe v1.1이 병렬로 존재하게 됩니다. 그래서 사이즈가 점차 늘어나게 되는 거죠.

System 32 밑에 있는 CPFilters.dll 날짜 및 위치를 기억하세요!!!!!!

WinSxS에는? 2개의 버전이 있내요… : )

내용을 보니깐 WinSxS의 해당 파일 중 최신버전의 CPFilters.dll은 현재 설치된 녀석과 같은 놈이군요!!!!!!!

그렇다면 Service Pack 1 업그래이드를 한 이후 특정 Role이나 Feature를 활성화 시키면, 당연히 Service Pack1이 적용된 버전의 컴포넌트로 활성화 되게 됩니다.
왜냐하면 이전에 말한 것과 같이 WinSxS에서 Staging만 된 녀석들도 이미 업그래이드가 모두 되어 있으므로…(됐다기 보다는 추가로 기록되어…)

만약 특정 컴포넌트들이 아직 업그래이드가 되지 않았다면 이는%windir%\WinSXS\Pending.xml 에 기록되고, 재부팅 이후 적용 되게 됩니다.

자 다시 말해서 Service Pack을 적용했고, 특정 hotfix 들이 해당 Service Pack에 포함되어 있다면 무! 조! 건! 이는 적용되게 됩니다.

적용이 되지 않았다면%windir%\WinSXS\Pending.xml 를 한번 들여 보거나 혹은%windir%\Logs\CBS\CBS.log 를 한번 들여다 보시는게 좋겠죠?

이는 Windows 2008의 Component Based Servicing 의 향상된 기능으로 자세한 내용은http://blogs.technet.com/b/askperf/archive/2008/04/22/understanding-component-based-servicing.aspx 를 한번 읽어 보는 것도 좋습니다.

마지막으로 이렇게 필요없는 이전 버전의 컴포넌트를 어떻게 하느냐…

DISM이라는 새로운 툴이 나왔습니다. Windows 2008 R2 및 Windows 7 부터 쓰는 툴인데 이녀석을 통해 Role 및 Feature의 활성화 및 비 활성화 그리고 추가로 이제 더이상 쓰지 않는 (보통 Service Pack 단위) 컴포넌트를 제거할 수 있습니다… : )

dism /online /cleanup-image /spsuperseded (실행은 주의 깊게!!!!!!!!!)

PS. 적당한 Root Partition Size는? 80GB 정도를 애기하는데… 메모리가 어마어마하게 큰 경우!!!!!!!!!! Paging File Size 및 Hibernation File Size 도 고려를 해야 겠죠?

요세는 147GB SAS가 보편화 되서 걍 2개를 Mirror로 묶어 쓰는게… ㅡ,.ㅡ;;