추가 리소스 제공자 설치

MAS TP1을 설치하시면, 기본적으로 IaaS(Infrastructure as a Service)에서 필요한 가상 네트워크, 저장소, 가상 컴퓨터, 부하 분산기등은 설치가 되고, 제공됩니다. MAS는 이러한 서비스 영역을 리소스 제공자(Resource Provider, RP)라는 이름으로 제공하고, Compute RP, Network RP, Storage RP가 이를 담당합니다. 현재 MAS TP1에서 추가적으로 구성 가능한 RP는 Web Apps, MySQL, SQL이 있습니다. 이를 추가적인 서비스라고 아래 그림에서는 표현해놓았습니다.

MySQL RP를 설치하면, 서비스에서 제공할 수 있는 항목에 MySQL이 추가되며, SQL은 Microsoft SQL, Web Apps는 웹 서비스를 제공할 수 있는 PaaS 기반이 구성된다고 보시면 됩니다. Web Apps의 경우에는 웹 서비스의 형태에 따라 MySQL, SQL 서비스와 연계하여 WordPress 형태를 제공할 수도 있습니다.

MAS TP1 출시 초기에는 이러한 작업들을 모두 PowerShell 스크립트를 직접 입력하여 처리하는 형태로 하여, 에러의 가능성이 높았지만, 지난 4~5월 스크립트를 모두 구성한 형태로 패키지를 제공, 필요한 경우에는 Installer 형태의 설치할 수 있게 되었습니다.(MySQL, SQL 공지, Web Apps 공지) 대표적으로 Azure Stack의 정보가 많은 azurestack.eu 사이트에서 정보를 찾아보신 분은 지금의 형태와 조금은 다른 모습을 보실 수 있습니다.

설치는 MySQL 또는 SQL (순서 상관 없음) RP를 설치하고, SQL RP 설치시 만들어진 데이터베이스를 통해, Web Apps를 설치합니다. 설치 형태는 매우 간단하기에, 설치 단계가 정리된 Microsoft 페이지를 링크로 달아놓겠습니다.

1. SQL 리소스 제공자 설치
2. MySQL 리소스 제공자 설치
3. Web Apps 리소스 제공자 설치

이슈가 발생할 수 있는 부분은 몇가지 정도로 정리됩니다.

• 각 RP 설치시 VM 생성 단계에서 Conflict 에러가 발생하고 실패하는 경우 : 1편에서 설명한 바와 같이, MAS TP1 호스트 운영 체제의 업데이트가 필요 이상으로 많이된 경우입니다.
• SQL RP 등록시 계정과 암호를 물어볼 때 : 이때는 VM 생성시 입력한 계정과 암호를 입력하는 것이 아니라, sqlRpUsername/sqlRpPassw0rd를 입력하시면 됩니다.
• MySQL RP 등록시 계정과 암호를 물어볼 때 : MySQL 구성시 입력한 기본 계정과 암호(BASICAUTHUSERNAME/BASICAUTHPASSWORD)를 입력합니다.
• Web Apps 설치 확인 단계에서 SQL 데이터베이스에 연결되지 않는 경우 : SQL RP를 설치하시고, MAS TP1 호스트를 다시 시작한 적이 있다면, 1편에서 언급드린 바와 같이 공용 IP 주소가 분리되는 이슈가 있기 때문입니다. 이 경우에는 SQL RP VM에서 원격 데스크톱 연결이 안될 것입니다.

MAS 포탈에서 SQLRP VM의 공용 IP 주소를 재설정해줘야 합니다. VM의 정보에서 나오는 블레이드의 Network Interface를 클릭하고, NIC을 클릭하면, 아래의 그림과 같은 형태까지 가실 수 있습니다.

노란색으로 표시된 부분을 이용하여, Public IP 주소를 None으로 설정한 후, 다시 생성하시면 새 IP 주소가 생성되고, 연결됩니다. 이는 MAS TP1의 알려진 이슈로 차후 발표될 다음 프리뷰에서는 해결될 것으로 보입니다. IP가 변경되었다면, SQLRP로 접속하는 DNS 호스트 레코드도 변경해야 합니다. MAS TP1 호스트의 ADVM으로 로그온하고, DNS 관리자를 엽니다. 여기에 SQLRP 레코드를 변경된 주소로 업데이트합니다.

이런 문제가 발생하지 않게 만드는 가장 좋은 해결책은 아쉽지만 현재로서는 MAS TP1 호스트의 다시 시작을 하지 않는 것입니다.

추가 VM 템플릿 이미지 생성

기본적으로 MAS TP1을 설치하면, Windows Server 2012 R2 이미지만을 제공합니다. 몇가지 작업을 통해 Linux와 Windows Server 2016을 추가할 수 있습니다. 해당 작업은 대부분 PowerShell 기반이기에, 조금은 복잡하게 느낄 수 있습니다.

$RefNetIsolation = Get-VM -Name ADVM | Get-VMNetworkAdapter | Get-VMNetworkAdapterIsolation

이를 통해 MAS TP1의 VM에 구성된 네트워크 VLAN 정보를 가져올 수 있습니다. (1편 내용 참고)

$VM = New-VM –Name <VM이름> -MemoryStartupBytes 4GB -SwitchName 'CCI_External_vSwitch' -BootDevice CD -Generation 1 -NoVHD
$VM | Set-VMProcessor -Count 2
$VHD = New-VHD -Path C:\ClusterStorage\Volume1\Share\VM\<파일이름>.vhd -SizeBytes 40GB –Dynamic

기존에 이미 만들어놓은 1세대 VHD 파일이 있다면, 이를 복사하셔서 사용하셔도 됩니다. 이 예제는 VHD를 생성하는 예제입니다.

$VM | Add-VMHardDiskDrive -ControllerType IDE -ControllerNumber 0 -ControllerLocation 0 -Path $vhd.Path
$VM | Get-VMDvdDrive | Set-VMDvdDrive -Path C:\설치이미지.ISO

역시나 이미 만들어놓은 1세대 VHD가 있다면, DVD를 추가하지 않아도 됩니다.

$VMNetAdapter = $VM | Get-VMNetworkAdapter
$IsolationSettings = @{
    IsolationMode = 'Vlan'
    AllowUntaggedTraffic = $true
    DefaultIsolationID = $RefNetIsolation.DefaultIsolationID
    MultiTenantStack = 'off'
}
$VMNetAdapter | Set-VMNetworkAdapterIsolation  @IsolationSettings

. C:\ClusterStorage\Volume1\Share\NCDeployment\Scripts\NetworkControllerRESTWrappers.ps1
Set-PortProfileId -resourceID ([System.Guid]::Empty.tostring()) -VMName $VM.Name -NicName $VMNetAdapter.Name

네트워크 구성 정보를 반영하고, MAS TP1내 VM간 기본 통신을 위해 PortProfileID를 지정합니다. Set-PortProfileID는 Hyper-V에서 제공하는 Cmdlet이 아니기에, NetworkControllerRESTWrappers를 실행한 후, 입력하는 것입니다.
이를 통해 VM을 구동하고 기본 OS 구성을 시작합니다. 기본적으로 MAS TP1은 인프라 네트워크(192.168.100.0/24)에 DHCP가 없으므로, 192.168.100.X(대략 20번대 이후, 안쓰는 IP)를 기본 IP 주소로 입력합니다. 게이트웨이는 192.168.100.1, 서브넷 마스크는 /24, DNS는 192.168.100.2입니다.

Linux에 대한 부분은 CentOS를 기반으로 잘 정리된 링크가 있습니다. 여기를 참고합니다. SUSE의 경우에는 여기를 참고합니다.

Windows의 경우, 필요한 업데이트를 모두 반영한 후, 네트워크 IP 구성을 다시 동적으로 변경한 후, SysPrep 명령어로 진행해주면 됩니다.

이렇게 기본 이미지 생성이 완료되면, PowerShell 스크립트를 통해 MAS내 항목으로 추가할 수 있습니다.

$ImageImport = @{
PlatformImageRespositoryPath = '\\SOFS\Share\CRP\PlatformImages\'
ImagePath = 'C:\ClusterStorage\Volume1\Share\VM\<파일 이름>.vhd'
Publisher = ‘적절한이름'
Offer = 'OS 종류’'(예, CentOS, WindowsServer)'
Sku = ‘큰버전(예, 7.2, 2016-TP5)'
Version = '세부버전(예, 1.0.0, 7.2.20160729)'
OsType = ‘Windows 또는 Linux'}

D:\CRP\VM\Microsoft.AzureStack.Compute.Installer\content\Scripts\CopyImageToPlatformImageRepository.ps1 @ImageImport

명령어가 완료되면, 조금만 기다리면, MAS 포탈내에 해당 이미지가 나와, 이제 VM 생성용으로 사용자나 관리자가 사용할 수 있습니다. 단일 형태의 이미지가 아닌, MarketPlace에 추가하는 형태는 여기를 참고하시면 됩니다.

오늘도 크게 2가지 정도 MAS TP1을 사용하면서 알게 된, 그리고 필요했던 내용을 정리해보았습니다. 또다른 내용을 가지고 3편으로 되돌아 오겠습니다.

지난 1월 Microsoft 하이브리드 클라우드의 핵심인 Microsoft Azure Stack(MAS)의 첫번째 기술 프리뷰(Technical Preview)가 릴리즈되었습니다. 이후 4월에 MAS 첫번째 프리뷰에 대한 추가 업데이트가 발표되어 지금까지 사용해볼 수 있는 형태로 제공되고 있습니다. 첫 프리뷰가 나온 이후, 계획된 일정과는 달리, 두번째 프리뷰가 올해 연말 발표로 연기됨에 따라(실제 출시 역시 내년 중반으로 연기), 현재의 MAS TP1을 기반으로 테스트나 기술에 대한 확인을 하셔야 하는 시간이 늘어나게 되었죠.

원래 꼬알라는 두번째 프리뷰가 발표되면, 관련된 기술 정리를 포스팅으로 진행할 마음을 가지고 있었지만, 이에 따라 TP1을 기반으로 몇가지 사항을 정리해보려고 합니다. 그 첫번째는 MAS TP1을 설치하시고, 자주 접하실 수 있는 사항에 대한 정리 및 이에 대한 트러블슈팅 방법을 써보려고 합니다. 몇몇 정보는 공식 페이지, 그리고 인터넷에 산재된 형태를 정리하기도 하였고, 몇몇 정보는 지난 6개월간 제가 직접 쓰면서 경험하고 해결한 문제들에 대한 정리입니다. 아직은 초기 단계인 첫번째 프리뷰이기에, 문제가 발생하거나, 야기했을 경우, 문제 소지를 없앤다고 다시 문제가 해결되지 않는 경우가 많습니다.

설치 관련 이슈

Windows Server 2016 TP4 영문판을 이용하셔야 합니다.(현재 최신은 TP5) MAS TP1이 릴리즈되었을 때, Windows Server 2016이 TP4였기에, TP4 버전만을 지원합니다. 또한 주의 사항 중 하나가, TP4가 작년 말에 릴리즈되었기에, 추가적으로 업데이트된 누적 업데이트가 꽤 많습니다. 이 누적 업데이트를 모두다 설치하시면 절대 안됩니다. MAS TP1이 출시되었을 당시에, 릴리즈된 업데이트인 KB3124262만 설치하시고, 나머지 업데이트는 모두 설치하시면 안됩니다. 다른 업데이트들이 설치되었을 경우, MAS 포탈에서 VM 생성시(특히 Windows 기반 VM), Conflict 상태가 되는 형태로 에러가 발생하고, 해결 방법이 없습니다. (TP4 재설치 필요)

역시나 MAS TP1에 대한 설치 이후, 지속적으로 발표되는 업데이트를 설치하실 필요는 없습니다. 이에 저는 Windows Update 서비스를 아예 중지시키고 쓰고 있습니다.

시간 대역도 중요합니다. 한국 시간 대역이 아닌, 태평양 표준시로 맞추셔야 합니다. 또한 서버의 BIOS 설정에, 시간과 관련된 부분(UTC)이 있다면, 이를 사용하지 마셔야 합니다.(아니면 UTC에 근거하여 시간을 설정하셔야 합니다.)

NIC이 여러개인 경우, 연결된 NIC은 하나를 제외하곤 모두 설치 전, 사용 중지하셔야 합니다.

서버 스펙 역시, TP1에서 요구하는 사양이 필요합니다. (최소 12개의 물리적인 코어, 96GB) 설치 후, 개별 메모리들의 용량을 줄여서 사용할 수 있다고 합니다만, 설치시 만들어주는 MAS용 역할 VM들의 메모리는 사용해본 느낌상 이미 최소 형태로 구성된다고 느껴집니다. MAS TP1의 기본 설치 후, MySQL, SQL, Web Apps에 대한 리소스 제공자를 추가하여, 제공 서비스를 늘릴 수 있습니다. 이 경우, 상단 그림의 VM이 생성되고, 대략 60GB의 메모리를 소모합니다. 이후 남은 메모리는 MAS에서 만들어지는 추가적인 서비스 VM들이나 서비스들이 차지하게 될 것입니다.

MAS TP1 설치시, NATVM에서 외부 네트워크와 연결되는 형태를 가져갑니다. NATVM – BGPVM – 내부 이런 형태의 네트워크를 가지고 있습니다. 이에 NATVM에 DHCP 형태로 네트워크 IP가 제공되어야 합니다. 고정 IP가 필요한 경우, DeployAzureStack.ps1 -Verbose -NATVMStaticIP 10.10.10.10/24 -NATVMStaticGateway 10.10.10.1 를 이용하여 IP 주소를 연결해주셔야 합니다.

사내 액티브 디렉터리를 통해 바로 MAS에 인증을 처리할 수 없습니다. MAS는 Azure AD를 이용하고 있으며, 사내 AD 인증 처리를 위해서는 Windows Server내 ADFS를 통해, Azure AD와 연결하는 작업이 필요합니다.

MAS TP1은 PoC를 위한 프리뷰이므로, 아직 고가용성 기술은 지원하지 않습니다. 이에 MAS내 가용성 집합을 만들 수는 있지만, 이를 직접 동작시킬 수는 없습니다. 차후 정식 버전의 MAS에서는 물리적인 서버의 추가 요구 및 최대 지원 숫자가 발표될 것입니다.

MAS TP1의 네트워크의 기본 구조

설치 후, 꼬알라가 가장 궁금했던 부분은 바로 MAS내 네트워크의 구성이었습니다.

MAS TP1은 크게 3개의 네트워크 영역을 가지고 있습니다. 192.168.100.0/24 (기본 인프라 영역) 192.168.133.0/24 (부하 분산기 외부 IP 영역) 192.168.200.0/24 (사용자 네트워크 영역)이 여기에 해당됩니다. 이 경우, 보통 3개의 가상 스위치가 필요할 것으로 예상하지만, MAS TP1의 Hyper-V 관리자는 하나의 가상 스위치만이 만들어져 있습니다.

IP 주소를 확인하기 위해, Hyper-V 관리자에서 VM 정보를 확인해도 IP 정보는 보이지 않습니다.

MAS TP1은 L2 네트워크간의 구분을 VLAN으로 하고 있습니다. 보통 VLAN은 Hyper-V 관리자내 VM 설정에서 한다고 생각하는 경우가 많습니다만, Windows Server 2016에서 새롭게 추가된 VMNetworkAdapterIsolation를 사용합니다. ExternalVirtualSubnet은 3rd 파티 네트워크 가상화, NativeVirtualSubnet은 Hyper-V 네트워크 가상화, VLAN은 가상 스위치 기반내 VLAN을 의미합니다.

가장 바깥단에 위치한 NATVM은 VLAN 1002번의 Transit Network와 0번의 외부 네트워크에 연결되어 있습니다. IP 주소는 외부 IP와 내부 IP 192.168.200.1을 가지고 있죠. VLAN 1002의 192.168.200.0/24라고 보시면 됩니다.

또하나의 내부 라우터인 BGPVM은 VLAN ID 1002에 소속된 192.168.200.3(Gateway 192.168.200.1), 그리고 VLAN 1001에 소속된 192.168.100.1을 가지고 있습니다.

BGPVM은 라우터이기에 192.168.100.0/24 영역에서 라우팅된 패킷을 192.168.200.0/24 영역의 기본 게이트웨이로 전달하도록 만들어져 있습니다.

마지막으로 인프라내 ADVM은 VLAN ID 1001에 192.168.100.0/24 영역을 사용합니다. 게이트웨이로 192.168.100.1을 바라보고 있기에, BGPVM으로 네트워크를 전달하게 됩니다.

참고로, MAS를 사용하시면서 만드신 가상 네트워크는 IsolationMode가 Vlan이 아닌, ExternalVirtualSubnet 형태로 만들어집니다.

192.168.100.0(내부) - 192.168.200.0(사용자가 사용할 외부) - 실제 네트워크 외부 형태로 구성되어 있는 것이죠. 그럼 이제 192.168.133.0/24가 남았습니다. 차후 시간이 될때, 별도로 살펴볼 예정입니다만, 192.168.133.0은 부하 분산기의 외부 IP입니다. BGPVM에서 Get-BGPRouteInformation을 내려보면, 하기 그림과 같은 결과가 나옵니다. 192.168.133.XX/32 (해당 IP를 칭하는 것이죠)에 대한 다음 홉 경로가 나옵니다. 192.168.100.5인데, 해당 VM은 MuxVM입니다.

결국 MAS 내부 인프라나 사용자가 사용할 외부 주소(NATVM에 고정 경로로 192.168.133.0/24를 BGPVM으로 전달하게 되어 있음)에서 192.168.133.0을 요청하면 처리할 수 있는 MuxVM이 있는 것이죠. 192.168.133.X의 IP들은 MAS 포탈내 공용 IP 주소에서 볼 수 있고, 이 주소가 부하 분산기에 연결되어 있습니다. 아니면 바로 VM에 할당하여, 부하 분산 처리를 받지 않는 형태로도 가능합니다.

이제 조금 그림이 그려지시나요? 복잡해보이지만, 잘 생각해보시면 이해가 되실 것입니다.

MAS TP1 네트워크에서 쉽게 발생할 수 있는 문제와 해결책

MAS TP1을 이용하다보면, 실제 MAS 호스트가 다시 시작되면, 192.168.133.0의 IP를 가진 VM이나 서비스가 동작하지 않는 것을 경험할 수 있습니다. TP1이기에 발생하고 있는 버그죠. 이 경우는 해당 공용 IP와 연결된 서비스(부하 분산 또는 가상 컴퓨터)를 잠시 연결 해제하시고, 새롭게 공용 IP 주소를 생성한 후, 연결하면 재동작을 시작합니다. 조금 피곤한 일이지만, 이런 형태의 해결책이 있는 것도 다행입니다. 가장 이상적인 방법은 MAS TP1 호스트에 서비스 형태의 VM들을 구성하신 후에는 다시 시작을 최대한 안하셔야 합니다.

추가적인 테스트 용도나 MAS내 베이스 이미지로 사용하기 위해서, MAS TP1 Hyper-V에 VM을 만드시는 경우가 있을 것입니다. (Windows Server 2016 또는 Linux 이미지 추가)

이 경우, 해당 VM이 192.168.100.0 등의 MAS내 네트워크와 교신이 되지 않는 것을 보실 수 있습니다. (네트워크 IP 주소를 맞췄음에도 불구하고) 이는 Port 프로필이 내부적으로 명시되어 있기 때문입니다. 이를 명시하기 위해서는 PowerShell 처리가 필요합니다. 먼저 해당 Cmdlet이 기본 포함되어 있지 않기에, 모듈을 불러와야 합니다. . C:\ClusterStorage\Volume1\Share\NCDeployment\Scripts\NetworkControllerRESTWrappers.ps1

이후, Set-PortProfileId -resourceID ([System.Guid]::Empty.tostring()) -VMName <VM이름> –NicName <네트워크 아답터 이름>을 입력합니다.

실수하기 좋은 것들

Hyper-V 관리 도구를 많이 사용하다 보면, 아무렇지도 않게, VM을 직접 삭제하시고, 더불어, MAS 포탈에서 만든 파일들을 직접 호스트에서 삭제할 수 있습니다. MAS는 클라우드 기술이므로, 모든 기본 처리는 전부 MAS 포탈을 이용해야 합니다. (인프라는 사용자가 사용하는 클라우드의 추상화 계층 밑에 있는 형태입니다.)

MAS 호스트의 Hyper-V 관리도구에는 이렇게 GUID 형태로 표현된 VM들이 존재합니다. 이에 대한 필요성이 없거나, 삭제를 원할 경우에, 관리 도구를 이용해서는 안된다는 것입니다. 해당 VM이 클라우드에서 가지는 이름을 확인한 후, MAS 포탈에서 삭제해야 합니다.

VM을 선택한 후, 하단 Summary를 보면, VMName이라는 형태로 확인이 가능합니다.

이를 GridView 형태로 보여주는 PowerShell이 PowerShell Gallery에 올라와있습니다.

또한 MAS내 저장소내 VM용 VHD가 생성되면, 이는 MAS 호스트내 배치되어 있습니다. 이 역시 정상적인 처리는 MAS 포탈을 이용해야 합니다.

MAS 포탈에 appsvclocalstor 저장소가 있죠.

이런 형태의 포스팅으로 MAS TP1에 대한 이야기를 정리해볼까 합니다. 또다른 이야기로 다음 포스팅에서 뵙겠습니다. 미약하지만, MAS TP1을 활용해보시는데 도움이 되셨으면 합니다.

• 05022016 - Protect and manage Identity and devices with Microsoft Enterprise Mobility Suite (Repeated 동일)
• 05022016 - Run Azure Services in your Datacenter
• 05022016 - New Docker and Containers Introduction for IT Professionals
• 05032016 - Create a Dynamic Datacenter with Software Defined Networking
• 05032016 - Deliver scalable Software Defined Storage anywhere
• 05032016 - Minimize reboots and improve security with next-gen server deployment

각설하고, 12월에 포스팅했던 [동영상] 액티브 디렉터리(AD, Active Directory)의 정석, 탄탄한 기초를 위해~! 세션에 열화와 같은 성원을 보내주셔서, 2월말, Windows 보안의 기초라는 세션을 2편에 걸쳐 촬영하였습니다.

보안의 고수분들께서는 보실 필요가 없지만, Windows 엔지니어를 준비하시는 분들에게는 시간되실 때 한번 살펴보시는 것을 권장드립니다. 아래 이미지를 클릭하시면, 해당 사이트로 연결됩니다.

Windows 보안의 기초 1편

Windows 보안의 기초 2편

반응이 역시나 좋으시면, 다른 형태의 기초 콘텐츠는 2016년에 계속 만들어볼 예정입니다.]]> https://docs.microsoft.com/archive/blogs/koalra/ad-active-directory Sun, 27 Dec 2015 17:01:00 GMT https://blogs.technet.microsoft.com/koalra/2015/12/27/ad-active-directory/

2010년 10월에 포스팅한 Active Directory에 대한 기초 동영상 세션이 사실 제 블로그에서 가장 View가 높은 포스팅 중 하나입니다. 다양한 형태의 세미나나 IT CAMP에서 AD에 관련된 기초 강좌가 있으면 좋겠다는 의견을 지속적으로 주셨고, 꼬알라가 생각해보아도, Microsoft 엔지니어 기술에서 기본중에 기본이 되는 기술이 바로 AD인 것은 틀림없는 사실입니다.

해당 동영상이 Windows Server 2008 R2에 대한 이야기로 구성되어 있고, 조금더 깊이 있고, 오랫동안 찾아보실 수 있는 형태가 되었으면 하는 바램으로, 금년 연말에는 액티브 디렉터리의 정석이라는 주제로 대략 6시간정도의 동영상을 구성해보았습니다.

파트 1 : Active Directory를 살펴보기 전에 반드시 알아야 할 기본 지식 - Microsoft Active Directory를 살펴보기 위해, 반드시 이해해야 할 기본 단어들에 대한 정의

파트 2 : Active Directory의 기초 개념, 1편 - Microsoft Active Directory의 정의, 도메인(Domain), 조직 구성 단위(OU – Organizational Unit), 포리스트(Forest), 트리 및 트러스트(Trust)에 대한 기본 개념정의

파트 3 : Active Directory의 기초 개념, 2편 - Microsoft Active Directory의 스키마(Schema), 파티션(Partition), 도메인 컨트롤러(DC – Domain Controller), 글로벌 카탈로그(GC – Global Catalog), 커베로스(Kerberos) 프로토콜 및 인증 프로세스, 작업 마스터(Operations Master)

파트 4 : Active Directory 도메인 컨트롤러(DC)의 설치, Active Directory내 서비스 조회 구조 및 DNS 서버 기본

파트 5 : 서버 코어 및 전체 설치 버전의 Windows Server를 활용하여 Active Directory 추가 도메인 컨트롤러(DC)의 설치, Active Directory내 그룹 개체 이해 및 활용

파트 6 : Active Directory 도메인 컨트롤러간 복제(Replication)에 대한 이해 및 Active Directory 사이트(Site) 구성

파트 7 : Active Directory 그룹 정책의 기본 이해

또 언젠가, 제가 계속적으로 이 일을 하고 있다면, 몇 년후, 다시 최신 버전으로 업데이트를 하겠죠. 아무쪼록 Microsoft 기술을 지향하시는데, 미약하지만 도움이 되었으면 합니다!

12012015 - AD.pdf

Windows Server 2012에서는 GUI와 서버 코어 사이에 연결 고리를 Minimum Shell (MinShell) 형태로 만들어서, 관리자가 필요할 경우, GUI 관련 구성 요소를 추가적으로 설치하고, 필요하지 않을 경우엔 제거할 수 있는 형태까지 발전하였죠.

Windows Server 2016에서는 서버 코어보다 훨씬(!) 더 적은 용량을 가지면서도, 강력한 서버 운영 체제의 기반을 만들기 위해, 기존 Windows Server의 명맥을 유지하면서, 완전히 새로운 운영 체제를 개발하고 있습니다. 바로 Nano Server (나노 서버)가 여기에 해당됩니다. 잘 아시다시피, Microsoft는 Microsoft Azure라는 공용 클라우드를 서비스하고 있습니다. Microsoft Azure에는 백만대 이상의 물리적인 서버들이 서비스를 제공하고 있는데, 물리적인 서버의 운영 체제 크기가 영향을 줄 수 있는 부분은 여러 곳이 있습니다. 우선 여러 구성 요소들이 엮일수록, 패치가 나올 확률이 높게 됩니다. 더불어, 해당 패치를 설치하였을 때, 리부팅을 할 확률 역시 높아지게 되죠. 서버 코어가 나오면서, GUI 버전보다 패치의 숫자와 이로 인한 다시 시작 빈도는 낮아졌지만, 더 높은 수준의 요구 사항이 Microsoft Azure에서 나타났던 것입니다. 또한 기반 운영 체제의 용량은 물리적인 서버내 운영 체제를 설치할 때, 소요되는 시간, 그리고 이를 설치하기 위해 네트워크로 전송하는 대역폭에 대한 요구 사항도 필요하게 됩니다.

최근 릴리즈된 Windows Server 2016 Technical Preview 4를 기준으로, GPT를 사용하는 형태의 VHDX 파일을 생성하였을 때, GUI 버전은 대략 9GB, 코어 버전은 6.5GB 정도를 차지합니다.

나노 서버는 지금까지의 서버 코어와 GUI 버전과의 설치 연결 고리를 가지지는 않습니다. 별도의 Windows Server 형태로 설치가 진행되게 되며, 이를 서버 코어나 GUI 버전으로 변경할수는 없습니다.

Windows Server 2016 설치 미디어를 열어보면, NanoServer라는 폴더가 있습니다. 해당 폴더에서 나노 서버의 이야기는 시작됩니다.

NanoServer.wim 파일이 바로 나노 서버의 설치 관련 파일입니다. 용량이 놀랍지 않나요? 약 130MB 정도밖에 되지 않습니다. 130MB 정도의 설치 파일이 Windows Server를 제공할 수 있다니… 도대체 어떠한 형태인지에 대해서 많이들 여쭤보십니다. 기본적으로 NanoServer.wim에는 Windows 관련 드라이버조차 포함되어 있지 않습니다. Windows Server가 제공하는 역할 및 기능 역시, 파일 형태로 포함하고 있지 않습니다. 말 그대로 Windows Server의 코어중 코어만을 집적해놓은 것입니다.

Packages 폴더에 들어가보면, 현재 Windows Server 2016 Technical Preview 4에서 사용할 수 있는 나노 서버의 용도를 알 수 있습니다. Compute는 Hyper-V이며, Containers는 곧 업데이트된 내용으로 다시 포스팅할 Windows Container (Docker)입니다. 관련된 패키지에 대한 정리는 TechNet 페이지에서 볼 수 있습니다.

앞서 언급한 바와 같이 나노 서버에는 기본적인 하드웨어 드라이버조차도 포함되어 있지 않습니다. 본인의 하드웨어에 적절한 드라이버를 WIM 파일내, 혹은 VHD/VHDX 파일내에 추가시켜줘야 합니다. Windows Server 서버 코어 버전에 포함된 형태의 드라이버 셋트와 동일한 형태의 드라이버를 나노 서버에 추가하려면, 패키지중 OEM-Drivers 패키지 파일을 추가하면 됩니다. 또한 나노 서버를 Hyper-V 기반에서 사용하려면, Guest 패키지가 이에 해당됩니다. 잠시 후 살펴볼, 이미지 제작에서 해당 패키지를 손쉽게 나노 서버 이미지에 넣는 방법을 살펴볼 것입니다.

Windows Server 2016 Technical Preview 3에서는 이번 Technical Preview 4보다 나노 서버에서 활용할 수 있는 패키지가 적었습니다. 이 의미는 차후 정식 버전의 Windows Server 2016내 나노 서버는 더 많은 역할을 제공할 것임을 알 수 있게 합니다. 기존 Technical Preview 3에서는 Windows Container의 호스트로 나노 서버를 사용할 수 없었지만, 이번 버전에는 드디어 제공하며, Nested Virtualization 기술과 결합하면, Hyper-V Container까지 이용할 수 있습니다.

자.. 이제 나노 서버를 이용할 수 있는 형태의 이미지로 제작해봐야겠죠. 앞서 언급한 바와 같이, 물리적인 서버에 나노 서버를 설치할 수도 있고(WIM 파일을 직접 하드 디스크에 풀어주는 형태), 아니면 VHDX 파일 형태로 제작하여, Hyper-V에서 가상 컴퓨터(VM) 형태로 사용하는 것입니다. 우선 VM 형태로 사용하기 위해 VHDX 파일을 제작하는 것을 살펴보죠.

Windows Server 2016 Technical Preview 4 설치 미디어내 NanoServer 폴더에 보면, NanoServerImageGenerator.psm1 파일이 존재합니다. 해당 모듈을 가져오기(Import)하여, Windows PowerShell에서 손쉽게 이미지를 제작할 수 있게 합니다. 제 경우에는 해당 폴더를 서버내 디스크로 복사한 후, 가져오기를 진행하였습니다.

감이 올 것입니다. New-NanoServerImage Cmdlet을 이용해서, Hyper-V 가상 컴퓨터용 나노 서버 이미지를 생성하는 것입니다. New-NanoServerImage Cmdlet의 자세한 사용법은 관련 링크를 활용하시면 됩니다.

New-NanoServerImage의 옵션 중 MediaPath는 Windows Server 2016 원본 미디어의 위치입니다. 예제에서는 F:\가 여기에 해당됩니다. BasePath의 경우는 나노 서버의 WIM과 관련 패키지를 복사할 폴더를 의미하며, TargetPath는 결과로 생성될 이미지의 위치 및 이름입니다. 여기서 중요한 것은 VHD로 파일 확장자를 지정하면 1세대(MBR 기반)의 VHD 파일이 생성되며, VHDX로 지정하면 2세대(GPT 기반)의 VHDX 파일이 생성됩니다.

Compute 옵션을 붙이면, Hyper-V가 설치되고, Containers 옵션을 사용하면 Container Host 관련 패키지가 설치됩니다. Storage는 파일 서버와 관련된, Clustering은 장애 조치 클러스터에 해당됩니다.

New-NanoServerImage Cmdlet에 ? 옵션을 붙여서 모든 옵션들을 다 뽑아내면, 아래와 그림과 같습니다.

제가 예제에서 사용한 EnableRemoteManagementPort 옵션은 Windows Remote Management(WinRM)을 이용하여 나노 서버에 다른 서브넷에서도 접근할 수 있도록 5985 포트를 방화벽에서 설정하라는 의미입니다. Windows Server 2016 Technical Preview 3의 나노 서버는 이미지 구성시, IP 주소와 같은 기본적인 설정조차, 이미지 생성시 고려해야 했지만, Windows Server 2016 Technical Preview 4부터는 기본 부팅 화면에서 IP 주소와 방화벽 설정은 구성이 가능하게 편의성을 높혔습니다.

New-NanoServerImage Cmdlet에서 가장 중요한 한가지가 있습니다. 사용하는 Windows의 언어에 따라서, 관련 패키지 언어를 사용하게 되어 있기에, 이미지를 제작하는 운영 체제가 한글판인 경우, 한글판 Windows Server 2016 이미지를 사용하면, 아무 문제가 없습니다만, 영문판 이미지를 사용할 경우에는 Language 옵션과 en-us를 붙여줘야 합니다. 반대의 경우도 동일합니다. Hyper-V용 드라이버만을 포함하여, 2세대 VM 이미지를 제작해보면, 아래와 같은 결과를 얻게 됩니다. 이미지 제작시 관리자 암호를 입력하게 됩니다.

이를 MB로 환산해보니, 644MB밖에 되지 않는군요. 서버 코어가 6.5GB 정도였으니, 1/10 수준입니다.

이제 해당 VHDX 파일을 적절한 폴더로 복사하여, Hyper-V의 VM으로 동작시켜봅니다. 아주 심플한 형태의 로그온 창이 나타납니다. 이미지 제작시 지정한 암호를 Administrator 계정과 함께 입력합니다. 로컬 로그온이므로, Domain 항목은 비워놓아도 됩니다.

로그온은 마치면, 텍스트 기반의 기본 콘솔이 나타납니다. 여기서, IP 주소와 방화벽 설정은 변경할 수 있습니다.

이제 어떻게 해야 하는지가 참 고민이 되실 것입니다. 나노 서버의 경우에는 모든 관리는 원격에서 PowerShell 형태의 관리나, 차후 출시될 Microsoft Azure Stack을 통해 웹 기반으로 관리하게 될 예정입니다. (사실 Microsoft Azure Stack의 경우에도 내부적으론 WS-Management를 활용한 원격 PowerShell과 동일합니다.)

도메인 환경이 아니기에, 우선 세션을 연결하기 위한 계정 정보를 입력받아야 합니다. $Cred = Get-Credential “IP 주소\Administrator”라고 입력합니다.

암호를 입력하면, $Cred 변수에 계정 정보가 저장되게 됩니다. 이를 이용해서 세션을 연결해보죠. 이때, Enter-PSSession Cmdlet을 활용합니다.

프롬프트에 IP 주소가 추가되었습니다. 해당 서버에 원격으로 연결되었다는 의미입니다. 이제는 PowerShell Cmdlet으로 시스템들에 대한 설정을 할 수 있습니다. 이미지 제작시 컴퓨터 이름을 입력하지 않았거나, 이름을 변경할 경우, Rename-Computer Cmdlet을 이용합니다. 기본적으로 동작하는 프로세스의 목록을 살펴보면..

22개밖에 되지 않습니다. Windows Server 2016 서버 코어 버전은 28개, GUI 버전은 46개의 프로세스가 기본 동작합니다.

동일하게 2GB씩 메모리를 할당한 VM에서 사용 가능한 물리 메모리의 크기는 나노 서버가 1894888, 서버 코어가 1589228, GUI 버전이 1135208입니다. 메모리에 대한 사용량도 매우 적죠.

나노 서버에서 살펴볼 내용은 매우 많지만, 오늘의 기본적인 나노 서버 이야기는 도메인에 나노 서버를 가입시키는 것으로 끝낼까 합니다. GUI 라면 매우 손쉽게 진행할 수 있는 도메인 가입이 나노 서버에서는 도통 감이 안잡히실거라 생각합니다. Offline Domain Join (ODJ)를 활용해야 합니다. ODJ에 대한 자세한 설명은 여기를 살펴보시면 됩니다. 도메인에 가입된 서버 코어나 GUI 버전의 Windows Server에서 명령 프롬프트를 열고, djoin /provision /domain “KOALRA.COM” /machine “KOALRA-NANO-01” /savefile C:\ODJ\KOALRA-NANO-01 이라고 입력합니다. 도메인 이름과 컴퓨터 이름은 본인이 사용하는 이름을 입력하시면 됩니다.

C:\ODJ에 도메인 가입을 위한 BLOB이 생성되었습니다. 이 다음 난관은 이 파일을 어떻게 나노 서버 안으로 복사하느냐는 것입니다. 이때 Windows Server 2016의 개선 사항이 또다시 빛을 냅니다.  

Copy-Item Cmdlet이 ToSession, FromSession이라는 옵션이 추가되어, 세션내로 복사가 가능해졌습니다. 반대로도 파일을 가져나올 수도 있고.. 위의 그림을 살펴보시면, 매우 쉽게 이해되실 것입니다. 나노 서버로 세션을 연결하여, djoin /requestodj /loadfile “BLOB 파일” /windowspath “Windows 경로” /localos라고 입력합니다. 그리고 Shutdown /r /t 5 명령어를 이용하여 다시 시작을 시킵니다.

다시 시작이 완료되면, 도메인 계정으로 로그온할 수 있습니다. 서버의 표준 시간대는 tzutil 명령어로 수정할 수 있습니다.

나노 서버는 기존의 Windows Server의 모든 모습을 다 호환할 수는 없을 것입니다. 그렇지만, 최대한 하위 호환성을 가지기 위해서 노력하고 있습니다. 패키지 중 ReverseForwarders 패키지가 이를 반증하고 있습니다.

나노 서버는 매우 최적화된 형태로 서비스에 보다 많은 자원을 할당해야 하는 클라우드 기반 운영 체제에 목적을 가지고 있으며, 기존 서버 코어는 Windows Server GUI 버전과의 호환성 및 기존 응용 프로그램과의 연관성을 방향으로 가지고 있습니다.

조금 길었지만, 어떠신가요? 새로운 Windows Server의 세계가 느껴지시는가요? 앞으로 출시까진 시간이 남았지만, Windows Server 2016의 향상은 계속될 것이며, 여기 중심에 나노 서버가 있을 것이라고 생각합니다.

우리가 사용하는 Hypervisor의 경우에는 CPU의 가상화 기술(Intel-VT, AMD-V)을 기반으로 동작하는 기술입니다. Hypervisor가 전체적인 하드웨어를 하단에 놓고, 실제 운영 체제를 포함하여, 가상 컴퓨터(VM)까지 Hypervisor의 통제하에 하드웨어를 사용하는 형태이죠.

여기서 중요한 단어가 하나 나오게 됩니다. 바로 추상화(Abstraction)이라는 단어입니다.

상단의 그림은 Hypervisor 위에서 동작하는 VM의 하드웨어 모습입니다. 네트워크 어댑터, 디스크 드라이브, 디스플레이 어댑터등이 모두 Microsoft Hyper-V 관련된 이름으로 표시되고 있습니다. (Intel® 82599로 표시된 NIC은 SR-IOV와 관련된 기술, 관련 포스팅, 이기에, 조금 다른 의미입니다.) Microsoft Hyper-V라고 표시되는 하드웨어는 실제 하드웨어를 바로 VM이 사용하는 것이 아니라, Hypervisor의 통제를 받고 있다는 의미와 함께, 실제 하드웨어를 접근하지 않는 모조의 하드웨어 형태 접근을 의미합니다. 이를 Hyper-V에서는 Synthetic Device(모조 장치)라고 합니다. 가장 중요한 것은 하드웨어를 직접 쓰지 않는다는 것입니다.

이렇게 되면, Intel-VT, AMD-V와 같은 형태의 CPU 기술도 VM에서는 인지하지 못하는 기술입니다. 그러한 이유로 Hyper-V를 설치한 후, 실제 서버에서 CPU 관련 유틸리티를 실행하면, 가상화 기술이 검색되지 않는다고 뜨게 되죠. 상단 그림이 이러한 구조를 잘 보여주고 있습니다.

• Level 0 : 실제 하드웨어 및 Hypervisor가 사용하는 레벨
• Level 1 Root : Level 0 Hypervisor 및 VM을 관리하는 호스트 운영 체제
• Level 1 Guest : 우리가 잘 알고 있는 VM

Windows 10 TH2(10565 이상), 그리고 Windows Server 2016 TP4에서는 Level 1 Guest를 위한 vCPU에 가상화 관련 기술을 제공하는 형태가 되었습니다. 이를 이용하여, VM내 가상화 기술을 사용할 수 있게 되었죠.

• Level 2 Root : Hyper-V가 설치된 VM
• Level 2 Guest : Hyper-V가 설치된 VM내에서 동작하는 VM

이렇게 가상화 안에서 또다른 가상화를 지원한다는 의미를 Nested Virtualization이라고 합니다. 둥지안에 둥지.. 의미적으론 이해가 되시죠? 현재 Nested Virtualization은 Preview 단계이며, Intel-VT만을 지원하고 있습니다. 이에 Hyper-V만을 지원하고 있습니다. (차후 정식 버전에서는 VT를 지원하기에, VT를 사용하는 모든 가상화 기술을 지원할 예정입니다.)

사용하는 방법은 매우 쉽습니다. GUI 설정이 없기에, Windows PowerShell에서만 설정할 수 있습니다.

VM Processor를 Get-VMProcessor로 확인해보면, ExposeVirtualizationExtensions 속성이 False입니다. 이 속성이 바로 VT와 관련된 속성입니다. 이를 Set-VMProcessor -VMNAME <VM이름> -ExposeVirtualizationExtentions:$True 로 설정하시면 됩니다.

이후, VM내에 Windows 10 TH2(10576+), Windows Server 2016 TP4를 설치하시면, Hyper-V를 사용할 수 있습니다. (현재 하위 버전 안됨)

현재 Nested Virtualization은 Preview 단계이기에, 몇가지 제약사항이 있습니다. (정식 버전시 변경 예정)

• VM내에서 Device Guard를 사용할 수 없습니다. (VSM 및 vTPM 동작 안됨)
• 호스트에 가상화 기반 보안이 적용되었을 경우에도 안됩니다.
• Nested Virtualization을 사용할 VM에서 동적 메모리 사용할 수 없습니다.
• Windows Server 2016부터 추가될 운영 중 VM 메모리 수정도 안됩니다.
• Nested Virtualization이 적용된 VM에서 검사점(Checkpoint)를 구성할 수 없습니다.
• 실시간 마이그레이션은 현재 지원하지 않습니다.
• VM 운영 중 저장/복원이 불가능합니다.

Nested Virtualization을 기반으로, 다음에 소개해드릴 Windows Container 기술의 Hyper-V Container가 동작하게 됩니다. 가상화 안에 가상화 Nested Virtualization을 통해, 보다 많은 구성 시나리오가 앞으로 사용될 수 있을거라 생각합니다.

관련된 세션의 다시보기 영상이 Technical Preview 4 공개와 함께, 오픈되었습니다.

[View:https://video.ch9.ms/ch9/89d7/a86e3a55-504f-4159-beb7-5c0e50a189d7/T15_high.mp4:0:0]

1부 직접 보기 링크

[View:https://video.ch9.ms/ch9/7ace/6576e708-d5ee-4cdc-9fba-a94d6ead7ace/T16_high.mp4:0:0]

2부 직접 보기 링크

발표 자료 역시, 해당 링크에서 같이 확인해보실 수 있습니다.

추가적으로 Windows Server 2016 Technical Preview 4는 여기에서 다운로드 가능합니다.

아무쪼록 새롭게 출시할 Windows Server 2016에 대한 전반적인 내용을 살펴보시는데 도움이 되셨으면 합니다.

각설하고! 오늘은 Windows Server 2016 TP3을 이용하여 Windows Container를 사용하기 위한, Container Host를 구성해보도록 하겠습니다. (Container Host라는 단어가 익숙하지 않으시다면, 앞선 개념 이해 포스팅을 다시 한번 읽어보시고~!)

Container Host를 구성하기 위한 운영 체제는 Windows Server 2016 TP3이어야 합니다. Container Host는 실제 물리적인 서버에 설치하셔도 되고, Windows Server 2012/2012 R2 기반의 VM에 설치하셔도 무방합니다.

다만 주의 사항은, Windows Server 2016 TP3을 코어(Core) 버전으로 사용하셔야 한다는 것입니다. 차후 Windows Server 2016이 릴리즈되면, 코어 버전의 Windows Server뿐만 아니라, Nano Server (언젠가 포스팅을 또 하겠습니다. ㅜㅜ) 기반에서도 활용할 수 있습니다. 많이 사용하시는 GUI 기반의 전체 설치 버전은 Container Host의 형태로 사용할 수 없는 방향으로 가고 있습니다. 어찌 생각해보면, Container 기술 자체가, 빠른 배포 및 유연성을 위한 기술이기에, 작은 용량의 형태가 필요해지고, 이러한 방향성에서는 전체 설치 버전은 잘 맞지 않는 것이라고 해석할 수 있습니다.

Windows Server 2016 TP3 코어 버전을 설치하셨다면, Container Host를 구성하기 위한 절반의 절차는 완료하신 셈입니다. 또한, 현재 Container Host를 구성하시려면, 반드시 대상 서버(혹은 VM)이 인터넷에 연결되어 있어야 합니다. (관련 파일 다운로드를 위해) GUI에 익숙하신 분들은 시작부터 명령어가 감이 안오실 수 있습니다. 우선 서버의 이름, IP 주소등을 설정해야 하므로, 명령 프롬프트에서 sconfig를 이용하는 것입니다.

Container Host를 구성하는 가장 편리한 방법은 Windows PowerShell을 이용하시는 것입니다. 이를 위해 PowerShell이라고 입력하여, 이를 실행합니다.

Windows PowerShell에서 Container Host를 구성하는 PowerShell 스크립트를 Microsoft에서 다운로드받습니다. 브라우저가 없기 때문에, Invoke-WebRequest(wget으로 Alias가 설정되어 있음)을 이용하여, https://aka.ms/setupcontainers의 스크립트를 ContainerSetup.ps1으로 다운로드합니다.

https://aka.ms/setupcontainers 에 접속해보면, Setup용 스크립트임을 알 수 있습니다. 보다 세부적인 구성 순서나 기술 습득을 위해서 시간이 허락될 때, 해당 스크립트 파일을 분석해보시는 것도 좋습니다.

한가지를 결정하고 이후 작업을 진행해야 합니다. Container들에 대한 네트워크 방식을 결정해야 합니다. Windows Server 2016 TP3의 Container는 2가지 형태의 네트워킹을 지원합니다.

1. Container와 Container Host간의 NAT 구성
2. Container와 Container Host가 동일한 네트워크에 배치(현재는 DHCP 시나리오만 지원)

그냥 방금 다운로드받은 스크립트를 실행하면, Container가 Container Host를 게이트웨이로 쓰는 형태인 NAT가 구성됩니다. 이 경우에 Container의 네트워킹을 위해 개인 네트워크(Private Network) 스위치가 생성되고, Container Host가 실제 NIC과 개인 네트워크에 연결된 vNIC의 네트워킹을 NAT 형태로 처리하게 됩니다.

NAT로 구성된 경우에는 Container가 외부 네트워크에 연결되어 서비스할 경우, 외부 IP 주소와 외부 포트를, 내부의 주소와 포트로 맵핑해주는 NAT의 포트 포워딩을 사용해야 합니다.

이 경우, 많은 NetNat 관련 cmdlet 중 Add-NetNatStaticMapping을 이용합니다.

Container도 직접 네트워크가 가능한 형태로 구성을 하기 위해서는 ContainerSetup.ps1 스크립트를 실행시 하나의 옵션을 설정해야 합니다. 바로 UseDHCP 옵션입니다.

해당 스크립트의 75번째 줄에는 UseDHCP에 대한 옵션을 지정할 수 있으며,

293번째 줄에서 UseDHCP를 지정했을 경우엔, New-ContainerDhcpSwitch Function으로, 아닐 경우엔 New-ContainerNatSwitch와 New-ContainerNat Function이 동작함을 알 수 있습니다.

203번째 줄에서 시작되는 New-ContainerDhcpSwitch Function은 전역 변수 SwitchName으로 그냥 VmSwitch를 생성합니다. (외부 네트워크입니다.)

93번째 줄에 SwitchName에 대한 전역 변수가 선언되어 있습니다. (이를 바꾸시면 Container에서 사용 가능한 스위치 이름도 바뀝니다.) 물론, NAT로 구성 후, DHCP로 구성 후, 상호 변경이 가능합니다. 또한 2개 이상의 스위치를 생성하시고, 이를 묶어서 활용하실 수도 있습니다.

외부 네트워크에 직접 Container들을 바로 연결하려면, ContainerSetup.ps1 -usedhcp 를 입력하시고, 그냥 NAT로 사용하실 것이라면, ContainerSetup.ps1만 바로 실행하면 됩니다. NAT 활용시, Container들은 기본적으로 스크립트내 61번째 줄에서 선언된 172.16.0.0/12 IP 서브넷을 사용합니다. 이 역시 실행 전, 차후 변경이 가능합니다.

설치는 한 줄로 되는 것을 알 수 있습니다.

설치 이후, Windows Container가 동작할 때, 필요한 각종 파일을 다운로드받습니다. 자 이제 설치를 시작하기 위해, Windows PowerShell에서 ContainerSetup.ps1을 실행하죠.

한번의 다시 시작이 발생하고, 다시 로그온을 요청합니다. Windows Server 2016부터는 기존 코어 버전에 있었던 로그온 UI 페이지가 없이, 글자로 표시됩니다.

다시 로그온을 완료하면, 사전 다시 설치 프로세스가 시작되도록, 구성되고, 다시 시작되었으므로, Windows PowerShell이 자동 시작됩니다. 그 후, 옵션을 별도로 붙이지 않았기에, 네트워크는 NAT 모드로, 그리고 NAT 내부 IP 대역은 언급한 172.16.0.0/12입니다.

Container에서 활용할 Container OS 이미지를 https://aka.ms/ContainerOSImage에서 다운로드를 시작합니다. 해당 이미지가 각종 Container를 생성할 때, 기반이 될 OS 이미지가 되며, Windows Server 2016 TP3에서는 Windows Server 2016 Core만 제공하고 있습니다. 다운로드에 걸리는 시간은 네트워크의 상황에 따라 유동적입니다. 해당 경로를 직접 브라우저에 넣으면, 약 3G의 크기를 가진 Windows Server 2016 TP3 Core가 다운로드됩니다.

다운로드가 잘 진행되는지 확인하고 싶다면, Ctrl+Alt+Del을 누르고, 작업 관리자를 선택합니다.

이더넷에 Receive 쪽이 속도가 나옴을 알 수 있습니다.

그리고 작업 관리자의 메뉴 파일, 새 작업 실행을 통해 PowerShell이나 명령 프롬프트를 하나 더 열수 있습니다. 이를 통해 다른 작업을 하실 수도 있습니다.

설치가 완료된 이후, 작업 관리자의 세부 정보 탭에서 Docker.exe를 확인하실 수 있습니다.

NAT 형태로 네트워크를 구성하였기에, NAT 서비스가 구성되어 있고, Get-VMSwitch cmdlet에서 2개의 네트워크가 나타나게 됩니다.

Container IP 주소 172.16.0.2의 80번 포트를 외부로 매핑하려면, Add-NetNatStaticMapping cmdlet을 사용하게 됩니다.

NAT는 외부에서 접속하는 형태의 Container는 조금 불편한 감이 있습니다. 이에 IP 주소를 직접 가지는 모드가 더 유용할 수 있습니다. 이를 외부 네트워크 유형의 가상 스위치라고 하며, 현재는 DHCP 서버가 IP 주소를 제공해야 합니다. 일단 현재의 NAT 유형의 VM Switch를 제거합니다.

그 후, New-VMSwitch cmdlet으로 새롭게 외부 네트워크 유형의 가상 스위치를 생성합니다. Get-NetAdapter를 통해 NIC의 Name 속성을 확인하고, New-VMSwitch <스위치 이름> -NetAdapterName <NIC의 Name 속성>을 입력합니다. 이러면 SwitchType이 External인 가상 스위치가 만들어집니다.

물리적인 서버를 직접 이용하는 형태라면, 이 후, 해당 가상 스위치를 사용하는 Container는 IP 주소를 DHCP 서버에서 받아 옵니다. 그러나 VM의 경우에는 Hyper-V에서 구성해준 기본 설정을 사용한다면, IP 주소를 받지 못하는 문제(?!?!)아닌 문제가 발생합니다.

이유는 Hyper-V의 보안 기능때문입니다. VM 설정에 NIC에 대한 MAC 주소 스푸핑(Spoofing)을 할 수 없게 하는 옵션이 기본이기 때문입니다. 하나의 NIC에서 여러 MAC 주소가 나오는 형태이기에, Hyper-V에서는 MAC 주소 스푸핑이라고 판단하는 것이죠. (소프트웨어 네트워크 로드 밸런싱인 NLB시에도 동일한 이슈가 발생합니다.) 이를 할 수 있게 하는 옵션이 VM 설정에 있습니다.

이럼, 이렇게 잘 해결이 됩니다.

현재 Windows Container와 관련된 PowerShell Cmdlet은 여기에서 확인하실 수 있습니다.

자세한 설정을 설명하고자, 스크린샷이 많아서, 길어졌던 포스팅이었습니다. 다음에는 Container를 직접 만들고, 운영하는 사항에 대해서 살펴보겠습니다.