이미 아시는 것과 같이 VHDX나 VHD는 하이퍼 브이 호스트에 직접 붙여 줄 수 있습니다.
실은 제가 Unattend.xml 때문에 꽤나 애를 먹었는데, 알고 보니 배포 시 발생하는 에러를 해당 VM의 Local Disk에 기록해 주더군요.

즉 배포에서 문제가 발생한 VM이 있었다면 해당 VM의 C:\에 해당 하는 VHDX를 하이퍼 브이 호스트에 직접 붙여 로그를 확인해 볼 수 있다는 거죠.

로그 위치는 %SystemDrive%\Windows\Panther 입니다.

즐거운 Private Cloud!

OS 설치 미디어에는 Install.wim 이라고 하는 설치 이미지가 있습니다.
전 이 설치 이미지로 부터 바로 VHDX를 추출하여 Sysprep된 이미지로 사용토록 하겠습니다.

툴이 필요한데요. “http://gallery.technet.microsoft.com/scriptcenter/Convert-WindowsImageps1-0fe23a8f”

어렵게 변환할 필요 없이 –ShowUI 옵션을…

안녕하세요.

이미 여러분도 아시는 것과 같이 PDT을 이용하면 System Center을 한번에 설치 할 수 있을 뿐 아니라 System Center Component 간의 Integration까지 완료 해주죠.

잠깐 PDT란?
- Private Cloud 를 구현하는데 있어 System Center의 설치 및 연동 작업처럼 쉽지 않고 시간이 많이 드는 작업이 없습니다. PDT는 Powershell Deployment Toolkit 의 약자로 필요한 컴포넌트를 마음대로 약간의 Customize 만으로 배포 할 수 있습니다. (물론 기존 도메인에 배포 또는 신규 도메인에 배포까지도 지원하고 필요한 컴포넌트들에 대한 고 가용성 구현까지 지원 합니다.)

다만 아쉬운 점이 있었다면 “한글”이 지원되지 않는다는 점이였습니다.
그런데 최근에 저희 팀에 정훈형님께서 일부 스크립트를 수정해서 한글이 가능하게 됐습니다.
자 그럼 지금부터 PDT 한글 버전을 살펴 보도록 하겠습니다.
(실은 제게 시켰는데… 제가 게을러서… 질질 끌었더니 정훈형님이 뚝딱!)

“한글 버전 System Center 배포가 가능한 PDT 다운로드 클릭”

먼저 필요한 사전 작업은 아래와 같습니다.
1. Hyper-v Host를 먼저 한 대 준비합니다.
2. WinRAR를 설치 합니다.
3. PowerShell 실행 정책을 풀어 줍니다. (작업이 끝나면 다시 올려줘야 겠죠? RemoteSigned로)

자 그 다음아래와 같이 읽기 전용 속성을 풀어 줍니다.

자 설치 이전에 가장 먼저 해야 하는 작업은 바로 Variable.xml을 편집하는 작업 입니다.
실은 제가 글을 쓰는 이유도 바로 Variable.xml을 설명하기 위해서죠.

실제 PDT는 아래와 같은 파일로 이루어져 있습니다.

위의 그림에서 보시는 바와 같이 바로 Variable.xml이 Deployment 시나리오를 설정하는 부분이며 실제로 여러분들 환경에 맞춘 시나리오로 Cloud OS (앞으로 System Center, Hyper-v, Azure을 합쳐 Cloud OS 시나리오라 부르겠습니다.)를 구현하기 위해서 편집해야 하는 파일 입니다.

자 그럼 Variable.xml을 한번 볼까요?
가장 상단에 위치한 정보 입니다.

<Installer version="2.0">
  <Variable Name="RegisteredUser" Value="Microsoft Corporation" />
  <Variable Name="RegisteredOrganization" Value="Microsoft Corporation" />
  <Variable Name="InstallerServiceAccount" Value="contoso\!Installer" />
  <Variable Name="InstallerServiceAccountPassword" Value="Passw0rd" />
  <Variable Name="SourcePath" Value="$SystemDrive\Temp" />
  <Variable Name="Download" Value="C:\Installer" />

실제로 편집 가능한 내용이 보이시죠?
설치 계정 및 설치 시 소스 파일의 위치 등에 대한 정보를 기록하게 됩니다.

실은 이 XML 파일을 Root에 확인해 보면 아래와 같은 4가지 주요 테이블로 이루어져 있음을 알 수 있습니다.
(XML파일을 보고 직접 설명해 드려야 하나 TEXT 파일을 읽는 것 차체가 쉽지 않아 보여 Tool을 이용해 Table로 표현 하였습니다.

- Components
각 System Center Role 별로 여러 가지 설치 관련 정보들을 기록합니다.
예를 들어 “설치 위치”, “서비스 계정”등을 정의 합니다.

- Roles
System Center는 여러 Component로 이루어져 있는데, 이에 대한 설치 서버 정보 및 SQL Server 관련 설정 등등이 등록되어 있습니다.

- SQL
SQL 설치 관련 정보들이 등록되어 있습니다.

-VMs
실제로 배포 되는 VM에 대한 설정입니다. 예를 들어 Dynamic Disk를 쓸 것인지 혹은 Diff Disk를 쓸것인지 다이나믹 메모리를 쓸것인지 등이 등록되어 있습니다.
 

자 구체적으로 VM에는 어떤 정보가 들어가 있을까요?
한번 VM 중 Count 4번의 XML을 직접 들여다 볼까요?

어때요? 별로 어렵지 않죠?
만약 Diff 형태의 Disk를 쓰지 않고 Dynamic Disk를 쓰시고 싶다면 단순하게 아래의 Differencing 을 Copy만 바꿔 주면 됩니다. 뭐 이런 형태로 편집해서 쓰는거죠.

Variable.xml을 편집하여 여러분의 입맛에 맞는 시나리오로 배포가 가능합니다.
그럼 지금 바로 TEST 해보시겠어요?

저는 VM 이름이 너무 알아먹기 어려워서 VM명 및 성능을 위한 Disk Type만을 Copy로 변경 했습니다.
컴퓨터 이름을 어떻게 줬냐구요?
아래와 같이 DB-Role로 줬어요. 원래는 P-DB01, P-DB02 형식이라 알아 보기 어려웠거든요.

자 모든 준비가 끝났나요? 그럼 Downloader.ps1을 실행 하고 VMCreator.ps1을 실행하여 CloudOS를 배포해 보자구요… : )

PS. WS2012, WS2012R2와 SYSTEM CENTER 2012R2는 직업 다운 받아 C:\Installer에 넣어주셔야 해요.

Guest Cluster를 구현 하는 방법은 Shared Storage 구현 방식에 따라 3가지로 나뉠 수 있습니다.

1. iSCSI SAN 이용
2. vFC SAN 이용
3. Shared VHDX 이용 : http://technet.microsoft.com/en-us/library/dn265980.aspx

제가 생각하는 Check List는 다음과 같습니다.

- vFC SAN 구성에 대한 권장 가이드는 아래 문서를 참고 하시면 됩니다.
http://blogs.technet.com/b/privatecloud/archive/2013/07/23/hyper-v-virtual-fibre-channel-design-guide.aspx

주요 주의 사항은 다음과 같습니다.
- 간략하게 요약하자면 vSAN은 Fabric의 갯수에 맞춰서 만들어 줘야 합니다.
즉 물리 SAN Switch가 1개만 있다면 HBA의 Port갯수에 관계없이 vSAN은 1개만 만들면 됩니다.
만약 물리 SAN Switch가 2개 이상 있다면 갯수만큼 vSAN을 만들어 줘야 합니다.
다만 만약 SAN Switch 사이에 Interconnect가 있다면 이경우에는 Fabric을 하나로 봐야 함으로 vSAN은 하나가 됩니다. 그리고 마지막으로 개인적인 취향이 들어가는 부분인데, 제 경우에는 SAN Fabric을 하나로 가져가고 VM상에서 굳이 MPIO를 구현 하지 않습니다.

주의 : 잘못 설정하면 NPIV 포트 고갈로 인해 VM이 시작되지 않을 수 있습니다.
실은 HBA는 NPIV Queue를 가지고 있습니다. 일단은 제가 포트로 표현했는데… 만약 특정 VM 시작하는 시점에 이 NPIV Queue가 고갈되게 되어 할당을 못 받는 경우 VM시작이 실패하게 됩니다.

- NPIV는 HBA와 SAN 모두 활성화 해야 합니다.

- Zone을 잡으실때는 WWPN으로 잡으셔야 합니다.

1. Guest OS가 Shared VHDX를 지원 하는 경우 즉 Windows Server 2012 이상의 경우에는 관리적인 측면에서 Shared VHDX를 선호 합니다.

2. SCVMM을 이용하여 Cluster Member 간에 Antiaffinity 설정이 가능 합니다. (강력 권고)

3. 일부의 아주 가끔 발생하는 이슈인데 Guest Clustering 구현이 실패하는 경우가 있습니다.
이 경우에는 “Microsoft Failover Cluster Virtual Adapter Performance Filter” 를 Guest Cluster의 Heartbeat으로 설정한 네트워크에서 제외해 주셔야 합니다. (관련 이슈 : http://support.microsoft.com/kb/2872325)
문제가 발생하는 경우에 적용해 주시기 바랍니다.

참고:
“Microsoft Failover Cluster Virtual Adapter Performance Filter” 는 Host Cluster 상에서의 Heartbeat Communication Path을 분산 시켜주는 역활을 합니다.
이전의 Cluster의 경우 Metric Value가 작은 Network Path로만 Heartbeat 통신을 했지만 현재의 경우 Metric 뒷 4Bit을 가지고 Offset 연산을 하여 Heartbeat 네트워크 자체를 분산시키고 있습니다.

기본적으로 Storage Space를 사용하게 되면 Disk에 대해서는 이미 RAID (n-way mirror 및 페러티) 를 통해 FT(Fault Tolerance)을 제공 하고 있습니다.
물론 실제로 Storage Space를 호스팅하는 서버의 경우에는 마찮가지로 Failover Cluster를 통해 고가용성을 제공하고, 물론 Disk Pool 역시 Failover cluster에 등록되어 고가용성을 제공 하며, 마지막으로 SMB File Share 역시도 Scale-out file server 즉 Failover Cluster 기반의 SMB 전용 파일 서버 구축을 통하여 FT(Fault Tolerance)를 제공 하고 있습니다.

즉 전방위적으로 고가용성 및 Fault Tolerance를 제공하고 있는 것이죠.
그런데 잠깐? 실제 JBOD 박스 즉 Enclosure는 어떻게 될까요? 물론 지원 합니다.
만약 다음의 조건을 충족한다면요… :)

1. 적어도 3개 이상의 JBOD Enclosure로 구성하여야 합니다. (2 Way Mirror 구성인 경우)
2. Disk 생성 시 IsEnclosureAware 를 꼭 True로 설정하여야 합니다.

짦은 Tip 이였습니다.
감사합니다.