가상화 패브릭 설계 고려 사항 가이드
이 가이드의 대상 중소기업 또는 대기업에서 여러 가상 컴퓨터를 지원하는 가상화 패브릭 설계를 담당하는 IT(정보 기술) 전문가. 이 문서의 남은 부분에서는 이러한 사람을 패브릭 관리자라고 부릅니다. 패브릭에서 호스트되는 가상 컴퓨터를 관리하는 사람은 가상 컴퓨터 관리자라고 부르지만, 이 문서의 대상이 아닙니다. 조직 내에서 한 사람이 두 가지 역할을 모두 담당하고 있을 수도 있습니다.
이 가이드의 활용 방법 이 가이드에서는 조직 내에서 여러 가상 컴퓨터를 호스트할 수 있는 가상화 패브릭 설계 방법을 이해할 수 있습니다. 이 문서에서는 서버와 하이퍼바이저, 조직 내에서 가상 컴퓨터를 호스트하는 데 사용되는 저장소 및 네트워킹 하드웨어 컬렉션을 가상화 패브릭이라고 부릅니다. 다음 그림은 가상화 패브릭의 예를 보여 줍니다.
.jpeg "가상화 패브릭")
그림 1:가상화 패브릭 예
참고: 이 문서의 각 다이어그램은 가상화 패브릭 설계 고려 사항 다이어그램 문서의 개별 탭에 포함되어 있으며, 각 테이블 제목에서 해당 그림 이름을 클릭하여 다운로드할 수 있습니다.
모든 가상화 패브릭에는 저장소를 위한 서버와 가상 컴퓨터를 호스트하기 위한 서비 및 이를 연결하는 네트워크가 포함되지만, 모든 조직의 가상화 패브릭 설계는 서로 다른 요구 사항으로 인해 그림 1에 표시된 예와 다를 가능성이 높습니다.
이 가이드에서는 조직의 고유한 요구 사항에 적합한 가상화 패브릭을 설계하기 위해 따를 수 있는 일련의 단계 및 작업에 대해 자세히 설명합니다. 각 단계 및 작업을 진행하면서 이 가이드에서는 기능 및 서비스 품질(예: 가용성, 확장성, 성능, 관리 및 보안) 수준 요구 사항을 충족할 수 있는 관련 기술 및 기능 옵션을 설명합니다.
이 문서에서는 관리 가능한 가상화 패브릭 설계와 관련된 도움을 제공하지만, Microsoft System Center 2012 또는 System Center 2012 R2와 같은 제품을 사용하여 가상화 패브릭을 관리 및 운영할 때의 설계 고려 사항 및 옵션에 대해서는 다루지 않습니다. 자세한 내용은 TechNet 라이브러리에서 System Center 2012를 참조하세요.
이 가이드에서는 Windows Server 2012 R2 및 Windows Server 2012와 공급업체의 제약이 없는 하드웨어를 사용하여 가상화 패브릭을 설계하는 데 유용한 정보를 얻을 수 있습니다. 이 문서에서 설명하는 일부 기능은 Windows Server 2012 R2 고유 기능이며 문서 전체에 나옵니다.
가정: Hyper-V, 가상 컴퓨터, 가상 네트워크, Windows Server 파일 서비스, 장애 조치(Failover) 클러스터링 및 일부 물리 서버, 저장소 및 네트워크 장비 배포 경험이 있다고 가정합니다.
추가 리소스
가상화 패브릭을 설계하기 전에 다음 문서에서 유용한 정보를 찾아볼 수 있습니다.
이 두 문서는 여러 가상화 패브릭 설계에서 나타나고 모든 가상화 패브릭 설계의 기초로 사용될 수 있는 기본적인 개념을 제공합니다.
사용자 의견: 이 문서에 대한 사용자 의견을 제공하려면 virtua@microsoft.com으로 메일을 보내세요.
설계 고려 사항 개요
이 문서의 나머지 부분에서는 조직의 고유한 요구 사항에 가장 적합한 가상화 패브릭을 설계하기 위해 따를 수 있는 일련의 단계 및 작업을 설명합니다. 이러한 단계는 순서에 따라 제시됩니다. 이후 단계에서 배우는 설계 고려 사항에 따라 충돌이 있는 경우 이전 단계에서 결정한 사항을 변경해야 할 수 있습니다. 이 문서에서는 설계상 발생 가능한 모든 충돌 요소에 대해 알려줍니다.
이 문서에 포함된 모든 고려 사항을 적용할 수 있도록 필요한 만큼 단계를 반복하면 요구 사항에 가장 적합한 설계를 얻을 수 있습니다.
1단계: 가상 컴퓨터 리소스 요구 사항 결정
2단계: 가상 컴퓨터 구성 계획
3단계: 서버 가상화 호스트 그룹 계획
4단계: 서버 가상화 호스트 계획
5단계: 가상화 패브릭 아키텍처 개념 계획
6단계: 초기 기능 특징 계획
1단계: 가상 컴퓨터 리소스 요구 사항 결정
가상화 패브릭을 설계할 때의 첫 번째 단계는 패브릭이 호스트할 가상 컴퓨터의 리소스 요구 사항을 결정하는 것입니다. 패브릭에는 이러한 요구 사항을 충족하는 데 필요한 물리적 하드웨어가 포함되어야 합니다. 가상 컴퓨터 리소스 요구 사항은 가상 컴퓨터 내에서 실행되는 운영 체제 및 응용 프로그램별로 지정됩니다. 이 문서의 나머지 부분에서는 가상 컴퓨터 내에서 실행되는 운영 체제 및 응용 프로그램의 조합을 작업(workload)이라고 부릅니다. 이 단계의 작업은 작업(workload)의 리소스 요구 사항을 정의하는 데 도움이 됩니다.
팁: 기존 작업(workload)의 리소스 요구 사항을 평가한 후 이러한 각 작업을 지원할 수 있는 가상화 패브릭을 설계하는 대신, 가장 일반적인 작업(workload) 요구 사항을 충족할 수 있는 가상화 패브릭을 설계할 수도 있습니다. 그런 다음 작업(workload)의 고유 요구 사항을 해결할 수 있습니다.
이러한 가상화 패브릭의 예는 Microsoft Azure(Azure)와 같은 공용 클라우드 공급자가 제공하는 가상화 패브릭입니다. 자세한 내용은 Azure의 가상화 컴퓨터 및 클라우드 서비스 크기를 참조하세요.
공용 클라우드 공급자는 일반적으로 대부분의 작업(workload) 요구 사항을 충족하는 가상 컴퓨터 구성을 선택하여 제공합니다. 이 접근 방식을 따를 경우, 이 문서에서 2단계: 가상 컴퓨터 구성 계획로 직접 건너 뛸 수 있습니다. 이 방식을 사용할 경우의 추가적인 이점은 다음과 같습니다.
일부 온-프레미스 가상 컴퓨터를 공용 클라우드 공급자로 마이그레이션할 때 온-프레미스 가상 컴퓨터 구성 유형이 공용 공급자 유형과 비슷한 경우, 구성 유형이 다를 때보다 더 쉽게 가상 컴퓨터를 마이그레이션할 수 있습니다.
용량 요구 사항을 보다 쉽게 예측하고 가상화 패브릭에 대한 서비스 프로비저닝을 자체적으로 쉽게 수행할 수 있습니다. 즉, 조직 내 가상 컴퓨터 관리자가 패브릭 관리자의 개입 없이도 새로운 가상 컴퓨터를 자동으로 자체 프로비전할 수 있습니다.
작업 1: 작업(workload) 리소스 요구 사항 결정
각 작업(workload)에는 다음과 같은 리소스 요구 사항이 있습니다. 가장 먼저 해야 할 일은 각 작업(workload)에 대해 나열된 다음과 같은 질문의 답을 찾는 것입니다.
프로세서: 필요한 프로세서 속도 또는 아키텍처(Intel 또는 AMD) 또는 프로세서 수는 얼마인가?
네트워크: 인바운드 및 아웃바운드 트래픽에 필요한 네트워크 대역폭(Gbps)은 얼마인가? 작업(workload)의 올바른 작동을 위해 허용 가능한 네트워크 대기 시간은 최대 얼마인가?
저장소: 작업(workload)에 필요한 응용 프로그램 및 운영 체제 파일의 저장소 용량(GB)은 얼마인가? 작업(workload)의 데이터에 필요한 저장소 용량(GB)은 얼마인가? 작업(workload)의 저장소에 필요한 IOPS(초당 입력/출력 작업 수)는 얼마인가?
메모리: 작업(workload)에 필요한 메모리 양(GB)은 얼마인가? 작업(workload)은 NUMA(non-uniform memory access)를 인식하는가?
이전 리소스 요구 사항을 이해하는 것 외에도 다음 사항을 결정해야 합니다.
리소스 요구 사항이 최소 사항인지 또는 권장 사항인지 여부
시간, 일, 주, 월 또는 연간 기준으로 각 하드웨어 요구 사항의 최대 및 평균 요구 사항
작업(workload) 및 작업(workload) 데이터에 대해 허용 가능한 월간 가동 중지 시간(분) 이러한 사항을 결정할 때는 다음을 고려해야 합니다.
작업(workload)이 1개의 가상 컴퓨터에서만 실행되는지 또는 모두 동일한 작업(workload)을 실행하는 네트워크 부하 분산 서버 컬렉션과 같이 하나의 단위로 작동하는 가상 컴퓨터 컬렉션에서 실행되는지 여부. 서버 컬렉션을 사용할 경우, 기술된 가동 중지 시간이 해당 컬렉션에 있는 각 서버에 대해 적용되는지, 컬렉션에 있는 모든 서버에 적용되는지 또는 컬렉션 수준에서 적용되는지를 명확히 해야 합니다.
작동 시간과 비작동 시간. 예를 들어 오후 9시부터 오전 6시 사이에는 아무도 작업(workload)을 사용하지 않지만, 오전 6시부터 오후 9시까지는 월별 허용 가능한 가동 중지 시간이 단 10분으로 최대한 사용 가능한 상태로 유지되어야 할 경우, 이러한 요구 사항을 지정해야 합니다.
예기치 않은 가상 인프라 오류가 발생할 때 허용 가능한 데이터 손실량. 이는 가상 인프라 복제 전략이 일반적으로 시간을 기준으로 하기 때문에 분 단위로 표시됩니다. 일반적으로는 데이터 무손실이 요구 사항으로 지정되지만, 이를 위해서는 비용이 너무 높아지는 경우가 많으며 성능 저하가 발생하는 경우도 많습니다.
작업(workload) 파일 및/또는 해당 데이터를 디스크에서 암호화해야 하는지 여부 및 가상 컴퓨터와 해당 최종 사용자 사이에 데이터를 암호화해야 하는지 여부
이전 리소스 요구 사항을 결정할 때 다음과 같은 방법을 사용할 수 있습니다.
Option |
장점 |
단점 |
|---|---|---|
리소스 사용률 수동 평가 및 기록 |
선택하는 모든 항목에 대해 보고할 수 있음 |
상당한 수동 작업이 필요할 수 있음 |
Microsoft Assessment and Planning Toolkit(영문)을 사용하여 리소스 사용률 자동 평가 및 기록 |
|
필요한 일부 데이터가 보고서에 포함되지 않을 수도 있음 |
참고: 리소스 요구 사항을 수동으로 결정하는 경우, 가상화 패브릭 설계 고려 사항 가이드 워크시트(영문)를 다운로드하고 작업(workload) 리소스 요구 사항 워크시트에 해당 정보를 입력할 수 있습니다. 이 가이드에서는 해당 문서의 특정 워크시트를 참조합니다.
작업 2: 작업(workload) 특성 정의
환경에서 작업(workload) 특성은 원하는 만큼 정의할 수 있습니다. 이 문서에 나온 다음 각각의 예는 가상화 패브릭 구성 요소에 대해 서로 다른 구성이 필요하며 이에 대해서는 이후 단계에서 자세히 설명합니다.
상태 비저장: 작업을 처음 프로비전하고 고유 컴퓨터 이름 및 네트워크 주소를 할당한 후 해당 로컬 하드 디스크에 고유 정보를 기록하지 않습니다. 하지만 데이터베이스와 같은 개별 저장소에 고유 정보를 기록할 수는 있습니다. 상태 비저장 작업(workload)은 가상 컴퓨터에 대해 "마스터" 이미지를 만들 수 있기 때문에 가상화 패브릭에서 실행하는 데 가장 적합합니다. 이 이미지는 쉽게 복사해서 가상화 패브릭에서 부팅하여 작업(workload)을 확장하거나 가상화 호스트 실패 시 사용할 수 없게 된 가상 컴퓨터를 신속하게 대체할 수 있습니다. 상태 비저장 작업(workload)의 예로는 프런트 엔드 웹 응용 프로그램을 실행하는 웹 서버를 들 수 있습니다.
상태 저장: 작업을 처음 프로비전하고 고유 컴퓨터 이름 및 네트워크 주소를 할당한 후 해당 로컬 하드 디스크에 고유 정보를 기록합니다. 데이터베이스와 같은 개별 저장소에 고유 정보를 기록할 수도 있습니다. 상태 저장 작업(workload)은 일반적으로 상태 비저장 작업(workload)에 비해 복잡한 프로비저닝 및 확장 전략이 필요합니다. 상태 저장 작업(workload)의 고가용성 전략에 따라 다른 가상 컴퓨터와의 공유 상태가 필요할 수 있습니다. 상태 저장 작업(workload)의 예로는 SQL Server 데이터베이스 엔진을 들 수 있습니다.
공유 상태 저장: 다른 가상 컴퓨터와의 공유 상태가 일부 필요한 상태 저장 작업(workload)입니다. 이러한 작업(workload)에서는 공유 저장소에 대한 액세스가 필요한 고가용성 확보를 위해 Windows Server의 장애 조치(Failover) 클러스터링이 자주 사용됩니다. 공유 상태 저장 작업(workload)의 예로는 Microsoft System Center(Virtual Machine Manager)를 들 수 있습니다.
기타: 가상화 패브릭에서 전혀 실행되지 않거나 최적으로 실행되지 않을 수 있는 작업(workload)의 특성을 정의합니다. 다음과 같은 요구 사항을 가지는 것이 이러한 작업(workload)의 특성(attribute)입니다.
물리적 주변 장치에 대한 액세스. 이러한 응용 프로그램의 예로는 물리적 호스트에서 전화 통신 네트워크 어댑터와 통신하는 전화 통신 작업(workload)을 들 수 있습니다.
대부분의 다른 작업(workload)보다 훨씬 높은 리소스 요구 사항. 한 가지 예로, 응용 프로그램 계층 간 요구되는 대기 시간이 1밀리초 이하인 실시간 응용 프로그램을 들 수 있습니다.
이러한 응용 프로그램은 가상화 패브릭에서 실행되거나 실행되지 않을 수 있으며, 대부분의 다른 작업(workload)과 공유되지 않는 매우 한정적인 하드웨어 또는 구성이 필요할 수 있습니다.
참고:설정(영문) 워크시트에서 작업(workload) 특성을 정의하고 작업 리소스 요구 사항(영문) 워크시트에서 각 작업(workload)에 대한 적합한 특성을 선택할 수 있습니다.
2단계: 가상 컴퓨터 구성 계획
이 단계에서는 1단계에서 정의한 작업(workload)의 리소스 요구 사항 및 특성을 충족하는 데 필요한 가상 컴퓨터 유형을 정의합니다.
작업 1: 계산 구성 정의
이 작업에서는 각 가상 컴퓨터에 필요한 메모리 및 프로세서의 양을 결정합니다.
작업 1a: 가상 컴퓨터 생성 유형 정의
Windows Server 2012 R2에는 2세대 가상 컴퓨터가 도입되었습니다. 2세대 가상 컴퓨터에서는 1세대 가상 컴퓨터에서 지원되지 않는 하드웨어 및 가상화 기능이 지원됩니다. 가상 컴퓨터를 만든 다음에는 해당 유형을 변경할 수 없으므로, 요구 사항에 맞게 결정하는 것이 중요합니다.
2세대 가상 컴퓨터는 다음과 같은 새로운 기능을 제공합니다.
표준 네트워크 어댑터를 사용한 PXE 부팅
SCSI 가상 하드 디스크에서 부팅
SCSI 가상 DVD에서 부팅
보안 부팅(기본적으로 설정됨)
UEFI 펌웨어 지원
2세대 가상 컴퓨터에서는 다음과 같은 게스트 운영 체제가 지원됩니다.
Windows Server 2012 R2
Windows Server 2012
Windows 8.1 64비트 버전
Windows 8 64비트 버전
특정 버전의 Linux. 2세대 가상 컴퓨터가 지원되는 배포판 및 버전 목록을 보려면 Hyper-V의 Linux 가상 컴퓨터(영문)를 참조하세요.
다음 표에는 1세대 및 2세대 가상 컴퓨터의 장점과 단점이 나와 있습니다.
Option |
장점 |
단점 |
|---|---|---|
1세대 |
|
새 가상 컴퓨터 기능에 액세스할 수 없음 |
2세대 |
|
|
중요: Linux 2세대 가상 컴퓨터에서는 보안 부팅이 지원되지 않습니다. 가상 컴퓨터를 만들 때 Linux를 설치하려면 가상 컴퓨터 설정에서 보안 부팅을 해제해야 합니다.
추가 정보:
작업 1b: 메모리 정의
물리적 컴퓨터에서 서버 응용 프로그램에 대한 메모리 크기를 계획할 때와 마찬가지로 가상 컴퓨터 메모리 크기를 계획해야 합니다. 일반적인 사용 시간 및 최대 사용 시간에 예상되는 부하를 합리적으로 처리할 수 있어야 합니다. 메모리가 부족하면 응답 시간 및 CPU 또는 I/O 사용량이 크게 늘어날 수 있습니다.
정적 메모리 또는 동적 메모리
정적 메모리는 가상 컴퓨터에 할당된 메모리의 양입니다. 가상 컴퓨터가 시작될 때 항상 할당되고 가상 컴퓨터를 실행하는 동안 변경되지 않습니다. 모든 메모리가 시작 중 가상 컴퓨터에 할당되고 가상 컴퓨터에서 사용 중이 아닌 메모리라도 다른 가상 컴퓨터에서 사용할 수 없습니다. 가상 컴퓨터가 시작될 때 호스트에 가상 컴퓨터에 할당할 수 있는 메모리가 부족하면 가상 컴퓨터가 시작되지 않습니다.
정적 메모리는 메모리 사용량이 많은 작업(workload) 및 SQL Server와 같이 고유 메모리 관리 시스템이 있는 작업(workload)에 적합합니다. 이러한 작업(workload) 유형은 정적 메모리에서 더 나은 성능을 제공합니다.
참고: 정적 메모리는 특별한 설정이 필요하지 않습니다. 정적 메모리는 동적 메모리 설정을 지정하지 않은 경우에 설정됩니다.
동적 메모리를 사용하면 작업량이 많은 가상 컴퓨터에는 더 많은 메모리를 할당하고, 작업량이 적은 가상 컴퓨터에서는 메모리를 제거하여 여러 가상 컴퓨터에 총 물리적 메모리를 분산함으로써 시스템에서 물리적 메모리를 보다 효과적으로 활용할 수 있습니다. 이 방식은 VDI(가상 데스크톱 인프라) 또는 웹 서버와 같은 동적 환경에서 특히 통합 비율이 높아집니다.
정적 메모리를 사용할 때는 가상 컴퓨터에 10GB 메모리가 할당되었고 이중에 3GB만 사용된다고 해도, 남은 7GB를 다른 가상 컴퓨터에서 사용할 수 없습니다. 가상 컴퓨터에 동적 메모리가 설정되어 있으면, 가상 컴퓨터에서 필요한 양의 메모리(구성된 최소 RAM 이상)만 사용합니다. 따라서 다른 가상 컴퓨터에서 사용할 수 있는 메모리를 더 많이 확보할 수 있습니다.
다음 표에는 정적 메모리와 동적 메모리의 장점과 단점이 나와 있습니다.
Option |
장점 |
단점 |
|---|---|---|
정적 메모리 |
|
|
동적 메모리 |
|
|
다음은 메모리 구성 설정입니다.
시작 RAM: 가상 컴퓨터를 시작하는 데 필요한 메모리 양을 지정합니다. 게스트 운영 체제를 시작할 수 있을 정도로 충분히 높은 값을 지정해야 하지만, 최적의 메모리 사용률과 잠재적으로 높은 통합 비율을 허용할 수 있는 수준으로 최대한 낮추어야 합니다.
최소 RAM: 가상 컴퓨터가 시작된 후 가상 컴퓨터에 할당해야 하는 최소 메모리 양을 지정합니다. 값은 32MB(최소값)부터 시작 RAM 값과 동일한 값(최대값)까지 설정할 수 있습니다. 이 설정은 동적 메모리가 설정된 경우에만 사용할 수 있습니다.
최대 RAM: 이 가상 컴퓨터가 사용할 수 있는 최대 메모리 양을 지정합니다. 이 값은 시작 RAM 값(최소값)부터 최대 1TB(최대값)까지 설정할 수 있습니다. 하지만 가상 컴퓨터는 게스트 운영 체제에서 최대한 지원할 수 있는 메모리 양만 사용할 수 있습니다. 예를 들어 최대 32GB를 지원하는 게스트 운영 체제를 실행하는 가상 컴퓨터에 64GB를 지정하면 가상 컴퓨터에서 32GB 이상을 사용할 수 없습니다. 이 설정은 동적 메모리가 설정된 경우에만 사용할 수 있습니다.
메모리 가중치: 모든 가상 컴퓨터에 요청된 메모리 양을 제공할 수 있을 만큼 호스트에 물리적 메모리가 충분하지 않은 경우 이를 사용하여 Hyper-V에서 가상 컴퓨터 간에 메모리를 분산하는 방법을 결정합니다. 가상 메모리 가중치가 높은 가상 컴퓨터는 메모리 가중치가 낮은 가상 컴퓨터보다 우선합니다.
참고:
동적 메모리 및 가상 NUMA 기능은 동시에 사용할 수 없습니다. 동적 메모리가 설정된 가상 컴퓨터는 가상 NUMA 노드를 하나만 포함할 수 있으며, 가상 NUMA 설정에 관계없이 가상 컴퓨터에 NUMA 토폴로지가 제공되지 않습니다.
가상 컴퓨터의 운영 체제를 설치하거나 업그레이드할 때는 설치 및 업그레이드 프로세스 동안 가상 컴퓨터에 제공되는 메모리 양이 시작 RAM 값으로 지정됩니다. 동적 메모리가 가상 컴퓨터에 구성되어 있더라도, 가상 컴퓨터에는 시작 RAM 설정에 구성된 메모리 양만 사용됩니다. 시작 RAM 값이 설치 또는 업그레이드 절차 중 운영 체제의 최소 메모리 요구 사항을 충족하는지 확인합니다.
가상 컴퓨터에서 실행되는 게스트 운영 체제는 동적 메모리를 지원해야 합니다.
SQL Server 또는 Exchange Server와 같은 복잡한 데이터베이스 응용 프로그램은 고유 메모리 관리자를 구현합니다. 작업(workload)이 동적 메모리와 호환되는지 여부를 결정하려면 작업(workload) 설명서를 참조하세요.
추가 정보:
동적 메모리 개요(영문)
작업 1c: 프로세서 정의
가상 컴퓨터를 구성하려면 다음 구성 설정을 결정해야 합니다.
각 가상 컴퓨터에 필요한 프로세서 수를 결정합니다. 이 개수는 종종 작업(workload)에 필요한 프로세서 수와 동일합니다. Hyper-V에서는 가상 컴퓨터당 최대 64개의 가상 프로세서가 지원됩니다.
각 가상 컴퓨터의 리소스 제어를 결정합니다. 가상 컴퓨터가 가상화 호스트의 프로세서 리소스를 독점할 수 없도록 제한을 설정할 수 있습니다.
NUMA 토폴로지를 정의합니다. 고성능 NUMA 인식 작업(workload)의 경우 최대 프로세서 수, 단일 가상 NUMA 노드에서 허용되는 메모리 양, 단일 프로세서 소켓에서 허용되는 최대 노드 수를 지정할 수 있습니다. 자세한 내용은 Hyper-V 가상 NUMA 개요(영문)를 참조하세요.
참고: 가상 NUMA 및 동적 메모리는 동시에 사용할 수 없습니다. 동적 메모리를 사용할지 또는 NUMA를 사용할지 여부를 결정할 때는 다음과 같은 질문을 고려해야 합니다. 두 질문에 대한 대답이 모두 예인 경우에는 가상 NUMA를 설정하고 동적 메모리는 설정하지 마세요.
가상 컴퓨터에서 실행되는 작업(workload)이 NUMA를 인식하는가?
가상 컴퓨터가 단일 물리적 NUMA 노드에서 제공되는 것보다 많은 리소스, 프로세서 또는 메모리를 소비하는가?
작업 1d: 지원되는 운영 체제 정의
작업(workload)에서 필요한 운영 체제가 게스트 운영 체제로 지원되는지 확인해야 합니다. 다음 사항을 고려합니다.
Supported Windows Guest Operating Systems for Hyper-V in Windows Server 2012 R2 and Windows 8.1
Supported Windows Guest Operating Systems for Hyper-V in Windows Server 2012 and Windows 8
Linux의 경우: 지원되는 Linux 배포판에 대한 자세한 내용은 Hyper-V의 Linux 가상 컴퓨터(영문)를 참조하세요.
참고: Hyper-V에는 지원되는 게스트 운영 체제를 위한 소프트웨어 패키지가 포함되어 있으며 이러한 패키지는 물리적 컴퓨터와 가상 컴퓨터 사이에 성능 및 통합을 향상해 줍니다. 이러한 서비스 및 소프트웨어 드라이버 컬렉션을 통합 서비스라고 부릅니다. 최상의 성능을 위해서는 가상 컴퓨터에서 최신 통합 서비스를 실행해야 합니다.
라이선싱
게스트 운영 체제에 제대로 라이선스가 부여되었는지 확인해야 합니다. 가상화된 환경을 실행할 때의 특정 라이선싱 요구 사항은 공급업체의 설명서를 검토하세요.
AVMA(가상 컴퓨터 자동 정품 인증)는 Windows Server 2012 R2에 도입된 기능입니다. AVMA는 라이선스가 부여된 가상화 서버에 가상 컴퓨터 정품 인증을 바인딩하고 시작 시 가상 컴퓨터를 정품 인증합니다. 이렇게 하면 라이선싱 정보를 입력하고 각 가상 컴퓨터를 개별적으로 정품 인증할 필요가 없습니다.
AVMA를 위해서는 호스트에서 Windows Server 2012 R2 Datacenter를 실행해야 하고, 게스트 가상 컴퓨터 운영 체제가 Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard 또는 Windows Server 2012 R2 Essentials여야 합니다.
참고: 가상화 패브릭에 배포된 각 호스트에서 AVMA를 구성해야 합니다.
추가 정보:
작업 1e: 가상 컴퓨터 명명 규칙 정의
기존 컴퓨터 명명 전략은 컴퓨터 또는 서버의 물리적 위치를 나타낼 수 있습니다. 가상 컴퓨터는 호스트 간에 또는 데이터 센터 간에 이동할 수도 있으므로, 기존 명명 전략은 더 이상 적용할 수 없습니다. 컴퓨터가 가상 컴퓨터로 실행됨을 나타내도록 기존 명명 규칙을 업데이트하면 가상 컴퓨터가 실행 중인 위치를 찾는 데 도움이 될 수 있습니다.
작업 2: 네트워크 구성 정의
각 가상 컴퓨터는 서로 다른 유형의 네트워크 트래픽을 수신 또는 송신합니다. 각 네트워크 트래픽 유형은 서로 다른 성능, 가용성 및 보안 요구 사항을 갖습니다.
1세대 가상 컴퓨터는 최대 12개의 네트워크 어댑터(레거시 네트워크 어댑터 4개와 가상 네트워크 어댑터 8개)를 포함할 수 있습니다. 2세대 가상 컴퓨터에서는 레거시 네트워크 어댑터가 지원되지 않으므로, 지원되는 최대 어댑터 수는 8개입니다.
작업 2a: 네트워크 트래픽 유형 결정
각 가상 컴퓨터는 다음과 같은 서로 다른 유형의 데이터를 송신 및 수신합니다.
응용 프로그램 데이터
데이터 백업
클라이언트 컴퓨터, 서버 또는 서비스와의 통신
작업(workload)이 게스트 가상 컴퓨터 장애 조치(failover) 클러스터에 속하는 경우 클러스터간 통신
Support(지원)
저장소
다른 유형의 네트워크 트래픽 전용의 기존 네트워크가 이미 있는 경우, 이 작업에 해당 네트워크를 사용하도록 선택할 수 있습니다. 가상화 패브릭 지원을 위한 새로운 네트워크 설계를 정의하는 경우, 각 가상 컴퓨터에 대해 지원할 네트워크 트래픽 유형을 정의할 수 있습니다.
작업 2b: 네트워크 트래픽 성능 옵션 정의
각 네트워크 트래픽 유형은 최대 대역폭 및 최소 대기 시간 요구 사항을 갖고 있습니다. 다음 표에서는 서로 다른 네트워크 성능 요구 사항을 충족하기 위해 사용할 수 있는 전략을 보여 줍니다.
전략 |
장점 |
단점 |
|---|---|---|
서로 다른 물리적 네트워크 어댑터에 대한 트래픽 유형 구분 |
다른 트래픽 유형에 공유되지 않도록 트래픽을 구분합니다. |
|
Hyper-V 대역폭 관리(Hyper-V QoS) |
|
|
SR-IOV |
|
|
|
|
|
Jumbo 프레임 |
|
|
작업 2c: 네트워크 트래픽 가용성 옵션 정의
LBFO(부하 분산 및 장애 조치(failover))라고도 부르는 NIC 팀은 대역폭 집계 및 트래픽 장애 조치(failover)를 위해 여러 네트워크 어댑터를 팀으로 배치할 수 있게 해줍니다. 이 방식은 네트워크 구성 요소 오류 시 연결을 유지합니다. NIC 팀은 일반적으로 호스트에서 구성되며, 가상 스위치를 만들 때 네트워크 어댑터 팀에 바인딩됩니다.
배포되는 네트워크 스위치에 따라 NIC 팀 모드가 결정됩니다. Windows Server 2012 R2의 기본 설정은 대부분의 배포에 적합합니다.
참고: SR-IOV는 NIC 팀과 호환되지 않습니다. SR-IOV에 대한 자세한 내용은 작업 2b: 네트워크 트래픽 성능 옵션 정의를 참조하세요.
추가 정보:
작업 2d: 네트워크 트래픽 보안 옵션 정의
각 네트워크 트래픽 유형은 격리 및 암호화 등과 관련하여 요구 사항이 서로 다를 수 있습니다. 다음 표에서는 다양한 보안 요구 사항을 충족하기 위해 사용할 수 있는 전략에 대해 설명합니다.
전략 |
장점 |
단점 |
|---|---|---|
서로 다른 네트워크 어댑터에 대한 구분 |
트래픽을 다른 네트워크 트래픽과 구분합니다. |
확장성이 낮습니다. 네트워크가 많을수록 호스트에서 더 많은 네트워크 어댑터를 설치하고 관리해야 합니다. |
IPsec 및 IPsec 작업 오프로딩(영문) |
|
|
VLAN 태깅 |
|
|
|
|
|
DHCPGuard(영문) |
|
사용하도록 설정한 경우 성능에 대한 최소한의 영향이 있습니다. |
RouterGuard(영문) |
|
사용하도록 설정한 경우 성능에 대한 최소한의 영향이 있습니다. |
설계 결정 - 가상화 패브릭 설계 고려 사항 가이드 워크시트(영문)를 다운로드하고 가상 컴퓨터 configs. 워크시트의 샘플 데이터를 변경하여 이 단계의 모든 이전 작업에서 결정한 사항을 캡처할 수 있습니다. 이후에 결정하는 설계 사항의 경우 이 문서에서는 이 가이드의 특정 워크시트를 참조하며 해당 워크시트에 데이터를 입력할 수 있습니다.
작업 2e: 가상 네트워크 어댑터 정의
트래픽에 대한 성능, 가용성 및 보안 전략과 더불어 가상 컴퓨터에서 요구되는 트래픽 유형을 이해하면 각 가상 컴퓨터에 필요한 가상 네트워크 어댑터 수를 결정할 수 있습니다.
가상 네트워크 어댑터는 가상 스위치에 연결됩니다. 가상 스위치는 다음과 같은 세 가지 유형이 있습니다.
외부 가상 스위치
내부 가상 스위치
개인 가상 스위치
외부 가상 스위치는 연결된 가상 스위치와 연관되어 있는 네트워크 어댑터를 통해 가상 컴퓨터가 물리적 네트워크에 액세스할 수 있도록 합니다. 호스트에서 물리적 네트워크 어댑터는 단일 외부 스위치와만 연결할 수 있습니다.
1세대 가상 컴퓨터는 최대 12개의 네트워크 어댑터(레거시 네트워크 어댑터 4개와 가상 네트워크 어댑터 8개)를 포함할 수 있습니다. 2세대 가상 컴퓨터는 레거시 네트워크 어댑터를 지원하지 않으므로 최대 8개의 어댑터가 지원됩니다. 가상 네트워크 어댑터에는 트렁크 모드로 구성되지 않는 한 1개의 VLAN ID를 지정할 수 있습니다.
가상 컴퓨터 트래픽을 다른 VLAN에 할당하려는 경우, VLAN을 지원하는 네트워크 어댑터를 호스트에 설치하고 가상 스위치에 할당해야 합니다. 가상 컴퓨터 속성에서 가상 컴퓨터에 대해 VLAN ID를 설정할 수 있습니다. 가상 스위치에 설정된 VLAN ID는 호스트 운영 체제에 할당된 가상 네트워크 어댑터에 할당되는 VLAN ID입니다.
참고: 사용 가능한 어댑터보다 많은 네트워크에 액세스해야 하는 가상 컴퓨터의 경우, Set-VMNetworkAdapterVlan Windows PowerShell cmdlet을 사용하여 가상 컴퓨터 네트워크 어댑터에 대해 VLAN 트렁크 모드를 사용하도록 설정할 수 있습니다.
작업 2f: IP 주소 지정 전략 정의
가상 컴퓨터에 IP 주소를 할당할 방법을 결정해야 합니다. 그렇지 않으면 IP 주소 충돌이 발생하여 네트워크에 있는 다른 가상 컴퓨터 및 물리적 장치에 부정적인 영향을 줄 수 있습니다.
또한 권한이 없는 DHCP 서버로 인해 네트워크 인프라에서 혼란이 발생하고, 서버가 가상 컴퓨터로 실행되는 경우 이를 추적하기가 특히 어려워질 수 있습니다. 가상 컴퓨터 설정에서 DHCPGuard를 사용하도록 설정하여 가상 컴퓨터에서 실행되는 권한이 없는 DHCP 서버로부터 네트워크를 보호할 수 있습니다. DHCPGuard는 메시지 가로채기(man-in-the-middle) 공격을 위해 DHCP 서버로 가장하는 악의적인 가상 컴퓨터로부터 네트워크를 보호합니다.
추가 정보:
DHCP(Dynamic Host Configuration Protocol) 개요
DHCPGuard(영문)
작업 3: 저장소 구성 정의
저장소 구성을 결정하려면, 가상 컴퓨터가 저장하는 데이터 형식 및 필요한 저장소 유형을 정의해야 합니다.
작업 3a: 데이터 형식 정의
다음 표에서는 가상 컴퓨터가 저장해야 하는 데이터 형식 및 해당 데이터 형식이 자주 저장되는 위치를 보여 줍니다.
데이터 형식 |
데이터 형식의. 저장소 위치 |
|---|---|
운영 체제 파일 |
가상화 호스트에서 저장되는 가상 하드 디스크 파일 내부. 가상화 호스트에 대한 저장소 고려 사항은 아래의 4단계: 서버 가상화 호스트 계획에 나와 있습니다. |
Windows 페이지 파일 |
운영 체제 파일과 동일한 위치에 저장되는 경우가 많습니다. |
응용 프로그램 파일 |
운영 체제 파일과 동일한 위치에 저장되는 경우가 많습니다. |
응용 프로그램 구성 데이터 |
운영 체제 파일과 동일한 위치에 저장되는 경우가 많습니다. |
응용 프로그램 데이터 |
응용 프로그램 및 운영 체제 파일과 별도로 저장되는 경우가 많습니다. 예를 들어 응용 프로그램이 데이터베이스 응용 프로그램인 경우, 데이터베이스 파일이 운영 체제 또는 응용 프로그램 파일이 저장되는 위치와 떨어진 고가용성의 효율성이 높은 네트워크 기반 저장소 솔루션에 저장되는 경우가 많습니다. |
CSV(클러스터된 공유 볼륨) 및 디스크 미러링 모니터(게스트 가상 컴퓨터 클러스터링에 필요) |
응용 프로그램 및 운영 체제 파일과 별도로 저장되는 경우가 많습니다.
|
크래시 덤프 파일 |
운영 체제 파일과 동일한 위치에 저장되는 경우가 많습니다. |
작업 3b: 저장소 유형 정의
다음 표에서는 위의 2단계, 작업 2a에 정의된 데이터 형식에 사용될 수 있는 저장소 유형을 보여 줍니다.
저장소 유형 |
고려 사항 |
|---|---|
가상 IDE 디스크 |
1세대 가상 컴퓨터:
2세대 가상 컴퓨터는 IDE 장치를 지원하지 않습니다. |
가상 SCSI |
|
가상 컴퓨터의 iSCSI 시작자 |
|
가상 파이버 채널 |
|
SMB 3.0 |
가상 컴퓨터 내에서 SMB(Server Message Block) 3.0 공유에 저장된 파일에 액세스합니다. |
작업 3c: 가상 하드 디스크 형식 및 유형 정의
가상 하드 디스크 저장소 유형을 사용할 경우, 다음 표에 나열된 옵션 중에서 사용하려는 VHD 형식을 먼저 선택해야 합니다.
디스크 형식 |
장점 |
단점 |
|---|---|---|
VHD |
|
|
VHDX(영문) |
|
|
게스트 가상 컴퓨터 클러스터의 공유 저장소에 사용됩니다. |
|
다음으로, 다음 표에 나열된 옵션 중에서 사용하려는 디스크 유형을 선택합니다.
디스크 유형 |
장점 |
단점 |
|---|---|---|
고정 |
|
|
동적 |
프로비전된 모든 공간을 사용하지 않고 필요한 만큼 디스크 공간을 사용합니다. |
|
차이점 보관용 |
여러 차이점 보관용 디스크가 동일한 상위 디스크를 사용할 경우 디스크 공간 사용량이 줄어들 수 있습니다. |
|
가상 하드 디스크 파일 유형 및 형식을 선택할 때는 다음을 고려하세요.
VHDX 형식을 사용하면 필요할 때만 공간을 할당함으로써 공간을 절약할 수 있을 뿐만 아니라 복원성이 보장되므로 동적 디스크를 사용할 수 있습니다.
또한 호스팅 볼륨의 저장소가 적극적으로 모니터링되지 않을 경우에는 형식에 관계없이 고정 디스크를 사용할 수도 있습니다. 이렇게 하면 VHD 파일이 런타임에 확장될 때 충분한 디스크 공간이 제공되도록 보장할 수 있습니다.
가상 컴퓨터의 검사점(이전의 스냅샷)은 차이점 보관용 가상 하드 디스크를 만들어 디스크에 쓰기를 저장합니다. 검사점이 일부만 포함될 경우 저장소 I/O의 CPU 사용이 늘어날 수 있지만, 성능에 큰 영향을 주지는 않습니다(I/O 집약적인 서버 작업(workload)은 제외).
하지만 검사점 체인이 대규모로 포함될 경우 가상 하드 디스크에서 읽기를 수행하기 위해 여러 차이점 보관용 디스크에서 요청된 블록을 검사해야 할 수 있으므로 성능에 큰 영향을 줄 수 있습니다. 올바른 디스크 I/O 성능을 유지하기 위해서는 검사점 체인을 짧게 유지하는 것이 중요합니다.
작업 3d: 각 데이터 형식에 대해 사용할 저장소 유형 정의
가상 컴퓨터가 저장할 데이터 형식 및 저장소 유형을 정의한 다음에는 각 데이터 형식에 대해 사용할 가상 디스크 형식 및 유형과 저장소 유형을 결정할 수 있습니다.
작업 4: 가상 컴퓨터 가용성 전략 정의
패브릭 관리자는 패브릭 가용성을 책임지지만, 가상 컴퓨터 관리자는 궁극적으로 가상 컴퓨터의 가용성을 책임집니다. 따라서, 가상 컴퓨터 관리자는 가상 컴퓨터에 대해 적절한 가용성 전략을 설계하기 위해 패브릭의 성능을 이해해야 합니다.
다음 표에서는 위의 1단계, 작업 2에서 정의한 특성의 작업(workload)을 실행하는 가상 컴퓨터에 대한 세 가지 가용성 전략을 분석합니다. 일반적으로 패브릭 관리자는 패브릭에 대해 가동 중지 활동이 예정되어 있는 경우 가상 컴퓨터 관리자가 적절하게 이를 계획할 수 있도록 가상 컴퓨터 관리자에게 미리 알려줍니다. 세 가지 가용성 전략은 다음과 같습니다.
상태 비저장
상태 저장
공유 상태 저장
상태 비저장
Option |
고려 사항 |
|---|---|
호스트 수준의 가상 컴퓨터 실시간 마이그레이션(영문) |
|
부하 분산된 클러스터(Windows 네트워크 부하 분산 사용) |
|
부하 분산된 클러스터(하드웨어 부하 분산 장치 사용) |
|
상태 저장
Option |
고려 사항 |
|---|---|
Hyper-V 클러스터(영문) |
|
공유 상태 저장
클러스터 인식 작업(workload)을 실행할 때 가상 컴퓨터 게스트 클러스터링을 사용하도록 설정하여 추가적으로 가용성을 제공할 수 있습니다. 게스트 클러스터링은 가상 컴퓨터 내에서 작업(workload)에 대한 고가용성을 지원합니다. 게스트 클러스터링은 가상 컴퓨터가 실행되는 호스트가 실패하더라도 가상 컴퓨터에서 실행되는 작업(workload)을 보호합니다. 작업(workload)은 장애 조치(Failover) 클러스터링으로 보호되기 때문에 다른 노드의 가상 컴퓨터가 자동으로 작업을 수행할 수 있습니다.
Option |
고려 사항 |
|---|---|
|
추가 정보:
공유 가상 하드 디스크를 사용하여 게스트 클러스터 배포
재해 복구
재해가 발생할 경우, 클라이언트에 서비스를 계속 제공할 수 있도록 필요한 작업(workload)을 얼마나 빨리 작동 및 실행할 수 있을까요? 일부 경우에는 할당된 시간이 단 몇 분밖에 되지 않을 수 있습니다.
지연으로 인한 데이터 손실을 적정 수준으로 유지하면서 최신 데이터를 복제할 수 있도록 하려면 기본 데이터 센터에서 재해 복구 센터로 데이터를 복제해야 합니다. 가상 컴퓨터에서 작업(workload)을 실행하면 기본 사이트에서 복제본 사이트로 가상 하드 디스크 및 가상 컴퓨터 구성 파일을 복제할 수 있습니다.
다음 표에서는 재해 복구 옵션을 비교하여 보여 줍니다.
Option |
고려 사항 |
|---|---|
Hyper-V 복제본 |
|
백업 |
|
참고:
System Center 2012 R2 Virtual Machine Manager를 실행할 때 복제를 중앙에서 관리하고 자동화하려면 Microsoft Azure 사이트 복구를 사용해야 합니다.
Microsoft Azure 사이트 복구를 사용해서 가상 컴퓨터를 Azure에 복제합니다. 가상 컴퓨터를 Azure에 복제하는 기능은 현재 미리 보기 모드입니다.
추가 정보:
중요:
Hyper-V 복제본 용량 플래너를 사용하여 Hyper-V 복제본이 네트워크 인프라에 미치는 영향 즉, 주 서버, 복제본 및 확장 복제본 서버에 대한 프로세서 사용률, 주 서버 및 복제본 서버의 메모리 사용량, 기존 가상 컴퓨터를 기준으로 주 서버, 복제본 및 확장 복제본 서버의 디스크 IOPS를 이해할 수 있습니다.
작업(workload)에 SQL Server의 AlwaysOn 가용성 그룹과 같은 기본 제공되는 재해 복구 솔루션이 포함되어 있을 수 있습니다. Hyper-V 복제본이 작업(workload)에서 지원되는지 여부는 해당 작업(workload) 설명서에서 확인하세요.
추가 정보:
System Center Data Protection Manager
작업 5: 가상 컴퓨터 유형 정의
사용자 환경에서 작업(workload)을 지원하려면 모든 작업(workload)의 요구를 충족할 수 있도록 고유한 리소스 요구 사항을 갖는 가상 컴퓨터를 만들 수 있습니다. 또는 서비스를 호스트하는 가상 컴퓨터의 공용 공급업체와 비슷한 접근 방식을 취할 수 있습니다(IaaS(Infrastructure-as-a-Service)라고도 함).
Microsoft Azure 인프라 서비스에서 제공되는 가상 컴퓨터 구성에 대한 자세한 내용은 Azure를 위한 가상 컴퓨터 및 클라우드 서비스 크기를 참조하세요. 이 문서를 작성할 때 이 서비스에서는 프로세서, 메모리, 저장소 및 IOP에 대해 각기 서로 다른 공간 조합을 갖는 13개 가상 컴퓨터 구성이 지원되었습니다.
설계 결정 사항(영문) - 이 단계의 모든 작업에서 결정하는 사항을 가상 컴퓨터 configs. 워크시트에 입력할 수 있습니다.
3단계: 서버 가상화 호스트 그룹 계획
개별 서버 호스트를 정의하기 전에 먼저 호스트 그룹을 정의해야 할 수 있습니다. 호스트 그룹은 이 단계의 남은 작업에서 설명하는 공통의 목표를 충족할 수 있도록 하나로 그룹화하여 이름을 지정한 단순한 서버 컬렉션입니다.
작업 1: 물리적 위치 정의
하드웨어 리소스는 물리적 위치에 따라 그룹화하고 관리할 가능성이 높으므로, 조직 내에서 패브릭 리소스를 포함할 위치를 먼저 정의해야 합니다.
작업 2: 호스트 그룹 유형 정의
다음과 같은 특징을 갖는 작업(workload)을 호스트하거나 기타 다른 다양한 이유로 호스트 그룹을 만들 수 있습니다.
특정 작업(workload) 특성
특정 리소스 요구 사항
특정 서비스 품질 요구 사항
다음 이미지는 2개 위치에 5개 호스트 그룹을 생성한 조직을 보여 줍니다.
.jpeg "호스트 그룹")
그림 2:호스트 그룹 예(영문)
이 조직은 다음 표에 설명된 이유로 호스트 그룹을 만들었습니다.
호스트 그룹 |
생성 이유 |
|---|---|
상태 비저장 및 상태 저장 작업(workload) |
|
회계 부서 상태 저장 및 상태 비저장 작업(workload) |
이 호스트 그룹에 있는 서버의 하드웨어 구성은 해당 환경에 있는 다른 상태 비저장 및 상태 저장 작업(workload) 호스트 그룹과 동일하지만 회계 부서에는 조직 내 다른 부서보다 보안 요구 사항이 높은 응용 프로그램이 있습니다. 그 결과, 패브릭의 다른 호스트 그룹과 다르게 보호될 수 있도록 해당 응용 프로그램을 위한 전용 호스트 그룹이 생성되었습니다. |
공유 상태 저장 작업(workload) |
이 호스트 그룹에서 호스트되는 작업(workload)은 가용성 유지를 위해 Windows Server의 장애 조치(Failover) 클러스터링에 의존하기 때문에 공유 저장소가 필요합니다. 이러한 작업(workload)은 해당 가상 컴퓨터 구성이 조직 내 다른 가상 컴퓨터와 다르기 때문에 전용 호스트 그룹에 의해 호스트됩니다. |
높은 I/O 상태 저장 작업(workload) |
이 호스트 그룹의 모든 호스트는 다른 호스트 그룹의 호스트보다 높은 속도의 네트워크에 연결되어 있습니다. |
이 조직은 호스트 그룹을 포함하는 위치를 확장할 수도 있었지만, 쉽게 관리할 수 있도록 각 호스트 그룹의 모든 멤버를 동일한 위치에 유지하도록 선택했습니다. 이 예에서 볼 수 있듯이, 호스트 그룹은 여러 가지 이유로 생성할 수 있으며 이러한 이유는 각 조직마다 다를 수 있습니다. 조직 내에서 생성하는 호스트 그룹 유형이 많을수록 관리할 환경이 보다 복잡해지므로, 결국 가상 컴퓨터를 호스트하는 비용이 늘어날 수 밖에 없습니다.
팁: 호스트 그룹 내에서 서버 하드웨어를 표준화할수록 시간이 지남에 따라 호스트 그룹을 보다 쉽게 확장 및 유지 관리할 수 있습니다. 호스트 그룹 내에서 하드웨어를 표준화하기로 결정한 경우에는 가상화 패브릭 설계 고려 사항 워크시트(영문)의 호스트 그룹 워크시트에 표준화된 구성 데이터를 추가할 수 있습니다. 물리적 하드웨어 고려 사항에 대한 자세한 내용은 4단계: 서버 가상화 호스트 계획을 참조하세요.
현재까지는 가상 컴퓨터를 호스트하는 대부분의 공용 클라우드 공급자에 대해 다음을 고려해야 합니다.
공유 상태가 필요하지 않은 가상 컴퓨터만 호스트합니다.
모든 고객에 대해 하나의 서비스 품질 메트릭 집합만 제공하는 경우가 많습니다.
특정 고객에 맞게 특정 전용 하드웨어를 제공하지 않습니다.
비용 대비 효과에 따라 동일한 하드웨어를 포함하는 단일 호스트 그룹 유형으로 시작하고 추가 호스트 유형만 추가하는 방식이 권장됩니다.
작업 3: 호스트 그룹 멤버를 클러스터링할지 여부 결정
이전에는 서버 가용성 향상을 위해 Windows Server의 장애 조치(Failover) 클러스터링만 사용되었지만, 이제는 보다 많은 기능을 제공하도록 기술이 성장했습니다. 다음 표의 정보에 따라 호스트 그룹 멤버를 클러스터링할지 여부를 결정하세요.
Option |
장점 |
단점 |
|---|---|---|
호스트 그룹 멤버가 장애 조치(failover) 클러스터에 포함됨 |
|
|
호스트 그룹 멤버가 장애 조치(failover) 클러스터에 속하지 않습니다. |
|
실패한 호스트에서 실행 중인 가상 컴퓨터를 정상 작동하는 호스트로 수동으로 이동하고 다시 시작해야 합니다(또는 일정 형태의 자동화 기능을 사용할 수 있음). |
설계 결정 사항(영문) - 이 단계의 모든 작업에서 결정하는 사항을 설정 워크시트에 입력할 수 있습니다.
4단계: 서버 가상화 호스트 계획
이 단계에서는 가상화 패브릭에서 실행하려는 가상 컴퓨터를 호스트하는 데 필요한 호스트 유형을 정의합니다. 일부 단일 구성의 경우에는 조달 및 지원 비용 절감을 위해 호스트 구성 수를 제한해야 할 수 있습니다. 또한 잘못된 장비를 구입하는 것도 배포 비용을 높입니다.
클라우드 플랫폼 시스템
Microsoft는 일부 대규모 데이터 센터 및 클라우드 서비스 운영 경험을 통해 공장 내에서 통합되고 완전히 검증된 통합형 시스템을 제공합니다. CPS(클라우드 플랫폼 시스템)는 Windows Server 2012 R2, System Center 2012 R2 및 Windows Azure Pack의 입증된 Microsoft 소프트웨어 스택과 Dell의 클라우드 서버, 저장소 및 네트워킹 하드웨어를 결합합니다. 클라우드를 위한 확장 가능한 빌딩 블록으로서 CPS는 가치 구현 시간을 단축하고 일관적인 클라우드 환경을 가능하게 해줍니다.
CPS는 PaaS(Platform-as-a-Service), Windows 및 Linux 가상 컴퓨터에 대한 셀프 서비스, 다중 테넌트 클라우드 환경을 제공하며 SQL Server, SharePoint 및 Exchange와 같은 Microsoft 응용 프로그램에 대한 최적화된 배포 팩을 포함합니다. 공장 내 통합을 통해 위험 및 복잡성을 줄이고 배포 시간을 몇 개월에서 며칠 단위로 단축합니다. 또한 간소화된 지원 프로세스와 일상적인 인프라 작업에 대한 자동화 기능으로 IT 리소스를 혁신 업무에 집중할 수 있습니다.
자세한 내용은 클라우드 플랫폼 시스템 사이트를 참조하세요.
Fast Track
하드웨어(및 소프트웨어) 구성을 설계하는 대신 Microsoft Private Cloud Fast Track 프로그램을 통해 다양한 하드웨어 파트너로부터 미리 구성된 하드웨어 구성을 구입할 수 있습니다.
Fast Track 프로그램은 Microsoft 및 해당 하드웨어 파트너가 검증되고 미리 구성된 솔루션을 공동으로 제공하는 프로그램으로서, 가상화 패브릭 및 이에 대한 관리 도구 구현과 관련된 복잡성 및 위험을 줄여줍니다.
Fast Track 프로그램을 통해 고객은 하드웨어 공급업체의 여러 기술 중에서 원하는 솔루션을 유연하게 선택할 수 있습니다. 이 프로그램은 Windows Server 운영 체제, Hyper-V 기술, Microsoft System Center의 핵심 기능을 사용하여 사설 클라우드 IaaS(infrastructure as a service) 제공을 위한 빌딩 블록을 제공합니다.
추가 정보:
Microsoft Private Cloud Fast Track 사이트
작업 1: 계산 구성 정의
이 작업에서는 각 호스트에 대해 필요한 메모리 양, 프로세서 수 및 Windows Server 버전을 결정합니다. 한 호스트에서 실행되는 가상 컴퓨터 수는 이 섹션에서 설명하는 하드웨어 구성 요소에 따라 결정됩니다.
참고: 솔루션이 완전히 지원되도록 보장하려면 구입하는 모든 하드웨어에 사용자가 실행하는 Windows Server 버전에 대해 Certified for Windows Server 로고가 포함되어야 합니다.
Certified for Windows Server 로고는 해당 서버 시스템이 보안, 안정성 및 관리 효율성에 대한 Microsoft의 엄격한 기술 요건을 충족함을 나타냅니다. 다른 인증 장치 및 드라이버와 함께, 클라우드 및 엔터프라이즈 작업(workload)과 비즈니스 크리티컬 응용 프로그램을 위한 역할, 기능 및 인터페이스를 지원할 수 있습니다.
최신 Certified for Windows Server 하드웨어 목록은 Windows Server 카탈로그(영문)를 참조하세요.
작업 1a: 프로세서 정의
Hyper-V는 논리적 프로세서를 각 활성 가상 컴퓨터에 하나 이상의 가상 프로세서로 제공합니다. EPT(확장 페이지 테이블) 또는 NTP(중첩 페이지 테이블)와 같은 SLAT(Second Level Address Translation) 기술을 지원하는 프로세서를 사용하여 추가 런타임 효율성을 얻을 수 있습니다. Windows Server 2012 R2의 Hyper-V에서는 최대 320개의 논리적 프로세서가 지원됩니다.
고려 사항:
프로세스 집약적이지 않은 작업(workload)은 가상 프로세서를 하나만 사용하도록 구성해야 합니다. 시간별로 호스트 프로세서 사용률을 모니터링하여 최대 효율성을 얻도록 프로세서를 할당했는지 확인합니다.
CPU 집약적인 작업(workload)에는 가상 프로세서를 2개 이상 할당해야 합니다. 가상 컴퓨터에는 최대 64개의 가상 프로세서를 할당할 수 있습니다. 가상 컴퓨터에서 인식되는 가상 프로세서 수는 게스트 운영 체제에 따라 달라집니다. 예를 들어 Windows Server 2008 서비스 팩 2에서는 가상 프로세서가 4개만 인식됩니다.
추가 정보:
Hyper-V 서버 성능 튜닝(영문)
작업 1b: 메모리 정의
물리적 서버에는 호스트 및 가상 컴퓨터 실행을 위해 충분한 메모리가 필요합니다. 호스트가 가상 컴퓨터를 대신해서 I/O 및 가상 컴퓨터 검사점과 같은 작업을 효율적으로 수행하기 위해서는 메모리가 필요합니다. Hyper-V는 호스트에 제공된 메모리가 충분한지 확인하고 남은 메모리를 가상 컴퓨터에 할당할 수 있도록 허용합니다. 가상 컴퓨터의 크기는 각 가상 컴퓨터의 예상 부하 요구에 따라 조정해야 합니다.
하이퍼바이저는 게스트 물리적 메모리를 가상화하여 가상 컴퓨터를 서로 격리시키고 비가상화 시스템과 동일하게 각 게스트 운영 체제에 대해 0부터 시작되는 인접한 메모리 공간을 제공합니다. 최대 성능을 얻도록 보장하려면 SLAT 기반 하드웨어를 사용하여 메모리 가상화의 성능 비용을 최소화합니다.
물리적 컴퓨터의 서버 응용 프로그램에 대해 일반적으로 수행하는 것과 마찬가지로 가상 컴퓨터 메모리의 크기를 조정합니다. 가상 컴퓨터에 할당되는 메모리 양은 가상 컴퓨터가 일반적인 사용 시간 및 최대 사용 시간에 예상되는 부하를 합리적으로 처리할 수 있도록 충분해야 합니다. 메모리가 부족하면 응답 시간 및 CPU 또는 I/O 사용량이 크게 늘어날 수 있습니다.
가상 컴퓨터에 메모리를 할당하면 다른 가상 컴퓨터에 제공할 수 있는 메모리 양이 줄어듭니다. 호스트에 메모리가 부족하면 가상 컴퓨터가 시작되지 않습니다.
동적 메모리를 사용하면 다시 시작 작업의 안정성이 향상되고 더 높은 통합 수치를 얻을 수 있습니다. 이렇게 하면 특히 풀링된 VDI 환경과 같이 유휴 상태 또는 부하가 낮은 상태의 가상 컴퓨터가 많은 환경에서 비용 절감에 도움이 될 수 있습니다. 동적 메모리 런타임 구성을 변경하면 가동 중지 시간을 줄이고 요구 사항 변경에 대응할 수 있는 민첩성을 향상시킬 수 있습니다.
동적 메모리에 대한 자세한 내용은 가상 컴퓨터에 대한 메모리를 결정하는 방법이 설명된 작업 1b: 메모리 정의를 참조하세요.
추가 정보:
동적 메모리 개요(영문)
작업 1c: Windows Server 운영 체제 버전 정의
Windows Server Standard 및 Windows Server Datacenter의 기능 집합은 완전히 동일합니다. Windows Server Datacenter에서는 가상 컴퓨터 수가 제한되지 않습니다. Windows Server Standard에서는 가상 컴퓨터 수가 2개로 제한됩니다.
Windows Server 2012 R2에는 AVMA(가상 컴퓨터 자동 정품 인증) 기능이 추가되었습니다. AVMA를 사용하면 연결되지 않은 환경에서도 각 가상 컴퓨터에 대해 제품 키를 관리할 필요 없이 올바르게 정품 인증된 서버에서 가상 컴퓨터를 설치할 수 있습니다.
AVMA를 사용하기 위해서는 게스트 운영 체제가 Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Standard 또는 Windows Server 2012 R2 Essentials를 실행해야 합니다. 다음 표에서는 각 버전을 비교하여 보여 줍니다.
버전 |
장점 |
단점 |
|---|---|---|
Standard |
|
가상 컴퓨터 2개로 제한됩니다. |
Datacenter |
|
비용이 더 많이 듭니다. |
Hyper-V를 Windows Server의 Server Core 설치 옵션으로 설치할 수 있습니다. Server Core 설치를 이용하면 디스크에 필요한 공간이 줄어들고, 공격 노출 영역이 줄어들고, 특히 서비스 요구 사항이 줄어듭니다. Server Core 설치는 명령줄, Windows PowerShell 또는 원격 관리를 사용해서 관리됩니다.
사용하려는 소프트웨어의 라이선싱 조건을 검토하는 것이 중요합니다.
Microsoft Hyper-V Server
Microsoft Hyper-V Server는 조직이 서버 사용률을 높이고 비용을 낮출 수 있게 해주는 간단하고 신뢰할 수 있는 가상화 솔루션을 제공합니다. 이 제품은 Windows 하이퍼바이저, Windows Server 드라이버 모델 및 가상화 구성 요소만 포함된 독립 실행형 제품입니다.
Hyper-V Server는 고객의 기존 IT 환경에 쉽게 통합될 수 있으며, 기존 프로비저닝, 관리 프로세스 및 지원 도구를 활용할 수 있습니다. Windows Server의 해당 버전과 동일한 하드웨어 호환성을 지원하며, Microsoft System Center 및 Windows Update, Active Directory 및 장애 조치(Failover) 클러스터링과 같은 Windows 기술과 완벽하게 통합됩니다.
Hyper-V Server는 무료로 다운로드할 수 있으며, 설치 시에 이미 활성화됩니다. 하지만 호스트된 가상 컴퓨터에서 실행되는 모든 운영 체제에는 적절한 라이선스가 필요합니다.
추가 정보:
작업 2: 네트워크 구성 정의
위의 2단계, 작업 2에서는 가상 컴퓨터 네트워킹의 설계 고려 사항에 대해 다루었습니다. 이제는 호스트의 네트워킹 고려 사항에 대해 다뤄보겠습니다. Hyper-V를 배포할 때는 계획 및 고려해야 할 네트워크 트래픽 유형이 몇 가지 있습니다. 네트워크 구성을 설계할 때는 다음과 같은 목표를 고려해야 합니다.
네트워크 QoS 보장
네트워크 중복성 제공
트래픽을 정의된 네트워크로 격리
작업 2a: 네트워크 트래픽 유형 정의
Hyper-V 클러스터를 배포할 때는 몇 가지 네트워크 트래픽 유형을 계획해야 합니다. 다음 표에서는 트래픽 유형을 요약해서 보여 줍니다.
트래픽 유형 |
설명 |
|---|---|
관리 |
|
클러스터 및 CSV |
|
실시간 마이그레이션 |
가상 컴퓨터 실시간 마이그레이션 및 공유 없음 실시간 마이그레이션에 사용됨 |
저장소 |
SMB 트래픽 또는 iSCSI 트래픽에 사용됨 |
복제본 |
Hyper-V 복제본 기능을 통한 가상 컴퓨터 복제 트래픽에 사용됨 |
가상 컴퓨터(테넌트) 트래픽 |
참고: 가상 컴퓨터 트래픽 유형 목록은 2단계: 가상 컴퓨터 구성 계획을 참조하세요. |
백업 |
가상 하드 디스크 파일 백업에 사용됨 |
작업 2b: 네트워크 트래픽 성능 옵션 정의
각 네트워크 트래픽 유형에는 최대 및 최소 대역폭 요구 사항과 최소 대기 시간 요구 사항이 있습니다. 다음은 여러 가지 네트워크 성능 요구 사항을 충족하기 위해 사용할 수 있는 전략입니다.
정책 기반 QoS
Hyper-V 클러스터를 배포할 때는 최소 6개의 트래픽 패턴 또는 네트워크가 필요합니다. 각 네트워크에는 네트워크 중복성이 필요합니다. 먼저 호스트에 12개의 네트워크 어댑터 설치를 고려합니다. 쿼드 네트워크 어댑터를 여러 개 설치할 수 있지만 어느 시점이 되면 호스트에서 슬롯이 부족해질 것입니다.
네트워킹 장비는 점점 더 빨라지고 있습니다. 얼마 전까지만 해도 1GB 네트워크 어댑터가 최상의 성능이었습니다. 이제는 서버에서 10GB 어댑터가 보다 일반화되었고 10GB 인프라 지원 비용도 점점 합리적으로 바뀌고 있습니다.
10GB 팀 네트워크 어댑터를 2개 설치하면 쿼드 1GB 어댑터를 2개 설치하는 것보다 많은 대역폭을 제공할 수 있으며, 필요한 스위치 포트 수가 적고, 케이블 구성이 간단합니다. 팀 10GB 네트워크 어댑터에 더 많은 네트워크 트래픽 유형을 통합할 경우, 정책 기반 QoS를 통해 네트워크 트래픽을 관리하여 가상화 인프라 요구를 올바르게 충족시킬 수 있습니다.
정책 기반 QoS를 사용하면 응용 프로그램 유형, 사용자 및 컴퓨터를 기반으로 네트워크 대역폭 제어를 지정할 수 있습니다. QoS 정책을 사용하면 네트워크 대역폭을 측정하고, 바뀌는 네트워크 조건(예: 네트워크 정체 또는 대역폭 가용성)을 감지하고, 네트워크 트래픽의 우선 순위를 정하여 작업(workload) 또는 응용 프로그램의 서비스 요구 사항을 충족할 수 있습니다.
Windows Server 2012 R2의 QoS 정책은 최대 대역폭을 강제 적용할 수 있는 기능뿐만 아니라 새로운 대역폭 관리 기능인 최소 대역폭 기능을 제공합니다. 대역폭 상한을 나타내는 최대 대역폭과 달리 최소 대역폭은 대역폭의 하한을 나타내며, 특정 트래픽 유형에 특정 분량의 대역폭을 지정합니다. 최소 및 최대 대역폭 제한은 동시에 구현할 수 있습니다.
장점 |
단점 |
|---|---|
|
|
추가 정보:
정책 기반 서비스 품질(영문)
데이터 센터 브리징
DCB(데이터 센터 브리징)는 특정 유형의 트래픽에 대해 하드웨어 기반 대역폭 할당 기능을 제공하며, 우선 순위에 따른 흐름 제어를 사용하여 이더넷 전송 신뢰성을 향상합니다. DCB는 FCoE 및 iSCSI를 사용할 때 권장됩니다.
장점 |
단점 |
|---|---|
|
|
추가 정보:
SMB 다이렉트
SMB 다이렉트(RDMA(원격 직접 메모리 액세스)를 통한 SMB)는 Windows Server 2012 R2의 저장소 프로토콜입니다. 이 프로토콜은 서버와 저장소 간의 직접 메모리 간 데이터 전송을 지원합니다. 이 프로토콜에는 최소 CPU 사용량이 필요하며, 표준 RDMA 가능 네트워크 어댑터가 사용됩니다. 이 프로토콜은 네트워크 요청에 대해 매우 빠른 응답을 제공하며, 따라서 원격 파일 저장소 응답이 직접 연결 블록 저장소만큼 빨라집니다.
장점 |
단점 |
|---|---|
|
|
수신 세그먼트 통합
RSC(수신 세그먼트 통합)는 CPU의 작업을 RSC 가능 네트워크 어댑터로 오프로딩하여 인바운드 네트워크 처리에 대한 CPU 사용률을 줄여줍니다.
장점 |
단점 |
|---|---|
|
|
수신측 배율
RSS(수신측 배율)는 네트워크 어댑터가 커널 모드 네트워크 처리 부하를 다중 코어 컴퓨터의 여러 프로세서 코어로 분산할 수 있게 해줍니다. 이러한 처리 분산으로 인해 단일 코어만 사용할 때에 비해 더 많은 네트워크 트래픽 부하를 지원할 수 있습니다. RSS는 네트워크 처리 부하를 여러 프로세서에 분산시키고 TCP(전송 제어 프로토콜)로 종료되는 트래픽을 능동적으로 부하 분산함으로써 이를 지원합니다.
장점 |
단점 |
|---|---|
|
|
SR-IOV
Hyper-V에서는 SR-IOV 가능 네트워크 장치가 지원되며, 물리적 네트워크 어댑터의 SR-IOV 가상 기능을 가상 컴퓨터에 직접 할당할 수 있습니다. 그 결과 네트워크 처리량이 향상되고, 네트워크 대기 시간이 줄어들고, 네트워크 트래픽 처리에 필요한 호스트 CPU 오버헤드가 줄어듭니다.
SR-IOV에 대한 자세한 내용은 위의 작업 2b: 네트워크 트래픽 성능 옵션 정의위에 있는 작업 2b: 네트워크 트래픽 성능 옵션 정의를 참조하세요.
작업 2c: 네트워크 트래픽 고가용성 및 대역폭 집계 전략 정의
LBFO(부하 분산 및 장애 조치(failover))라고도 부르는 NIC 팀을 사용하면 대역폭 집계 및 트래픽 장애 조치(failover)를 위해 여러 네트워크 어댑터를 하나의 팀으로 배치할 수 있습니다. 이 기능은 네트워크 구성 요소 실패 시 연결을 유지하는 데 도움이 됩니다.
이 기능은 네트워크 어댑터 공급업체에서 제공되었습니다. Windows Server 2012에서 도입된 NIC 팀은 Windows Server 운영 체제의 한 기능으로 포함됩니다.
NIC 팀은 Windows Server 2012 R2의 모든 네트워킹 기능과 호환되지만 다음과 같은 세 가지 예외가 있습니다.
SR-IOV
RDMA
802.1X 인증
확장성 측면에서는 Windows Server 2012 R2에서 최소 1개, 최대 32개의 네트워크 어댑터를 단일 팀에 추가할 수 있습니다. 단일 호스트에서 만들 수 있는 팀 개수는 제한이 없습니다.
추가 정보:
Microsoft Virtual Academy:Windows Server 2012의 NIC 팀(영문)
Windows PowerShell의 NIC 팀(NetLBFO) Cmdlet(영문)
Windows Server 2012 R2 NIC 팀(LBFO) 배포 및 관리(영문)
작업 2d: 네트워크 트래픽 격리 및 보안 전략 정의
각 네트워크 트래픽 유형은 격리 및 암호화와 같은 기능에 대한 보안 요구 사항이 서로 다를 수 있습니다. 다음 표에서는 다양한 보안 요구 사항을 충족하기 위해 사용할 수 있는 전략을 보여 줍니다.
전략 |
장점 |
단점 |
|---|---|---|
암호화(IPsec) |
회선을 통과하는 동안 트래픽이 보호됩니다. |
|
개별 물리적 네트워크 |
네트워크가 물리적으로 분리됩니다. |
|
VLAN(Virtual local area network) |
|
|
작업 2e: 가상 네트워크 어댑터 정의
가상 서버 호스트, 성능, 가용성 및 트래픽 보안 전략에 필요한 트래픽 유형을 이해하면 각 호스트에 대해 필요한 물리적 네트워크 어댑터 수 및 각 어댑터를 통해 전송되는 네트워크 트래픽 유형을 결정할 수 있습니다.
작업 2f: 가상 스위치 정의
가상 컴퓨터를 네트워크에 연결하려면 네트워크 어댑터를 Hyper-V 가상 스위치에 연결해야 합니다.
Hyper-V에서는 다음과 같은 3가지 유형의 가상 스위치를 만들 수 있습니다.
외부 가상 스위치
외부 가상 스위치는 외부에 위치한 서버 및 클라이언트와 통신하기 위해 가상 컴퓨터에 물리적 네트워크에 대한 액세스를 제공하려는 경우에 사용합니다. 이 유형의 가상 스위치를 사용할 경우 동일한 호스트에 있는 가상 컴퓨터가 서로 통신할 수도 있습니다. 이 유형의 네트워크는 또한 네트워킹 구성 방법에 따라 호스트 운영 체제에서 사용할 수도 있습니다.
중요: 물리적 네트워크 어댑터는 한 번에 하나의 가상 스위치에만 바인딩할 수 있습니다.
내부 가상 스위치
내부 가상 스위치는 동일한 호스트에 있는 가상 컴퓨터 사이의 통신을 허용하고 가상 컴퓨터와 호스트 운영 체제 사이의 통신을 허용하려는 경우에 사용합니다. 이 유형의 가상 스위치는 일반적으로 호스트 운영 체제에서 가상 컴퓨터에 연결해야 하는 테스트 환경을 구축하기 위해 사용됩니다. 내부 가상 스위치는 물리적 네트워크 어댑터에 바인딩되지 않습니다. 따라서 내부 가상 네트워크가 외부 네트워크 트래픽으로부터 격리됩니다.
개인 가상 스위치
개인 가상 스위치는 동일한 호스트에 있는 가상 컴퓨터 사이에만 통신을 허용하려는 경우에 사용합니다. 개인 가상 스위치는 물리적 네트워크 어댑터에 바인딩되지 않습니다. 개인 가상 스위치는 가상화 서버의 모든 외부 네트워크 트래픽으로부터 격리되며, 호스트 운영 체제와 외부 네트워크 사이의 모든 네트워크 트래픽으로부터 격리됩니다. 이 유형의 네트워크는 격리된 테스트 도메인과 같은 격리된 네트워킹 환경을 만들어야 할 경우에 유용합니다.
참고: 개인 및 내부 가상 스위치는 외부 가상 스위치에 연결된 가상 컴퓨터에 제공되는 하드웨어 가속 기능의 이점을 활용할 수 없습니다.
설계 결정 사항(영문) - 이 단계의 모든 작업에서 결정하는 사항을 가상화 호스트 워크시트에 입력할 수 있습니다.
팁: 서로 다른 호스트에 있더라도 동일한 네트워크에 연결되는 가상 스위치 이름은 동일해야 합니다. 이렇게 하면 가상 컴퓨터를 연결해야 하는 가상 스위치를 혼동하지 않고, 한 호스트에서 다른 호스트로 가상 컴퓨터를 쉽게 이동할 수 있습니다. 대상 호스트에서 동일한 가상 스위치 이름을 찾을 수 없으면 Move-VM Windows PowerShell cmdlet이 실패합니다.
작업 3: 저장소 구성 정의
호스트 운영 체제에 필요한 저장소 외에도 각 호스트에는 가상 컴퓨터 구성 파일 및 가상 하드 디스크가 저장된 저장소에 대한 액세스 권한이 필요합니다. 이 작업에서는 가상 컴퓨터 저장소에 대해 자세히 다룹니다.
작업 3a: 데이터 형식 정의
다음은 저장소 요구 사항에 대해 고려해야 하는 샘플 데이터 형식입니다.
데이터 형식 |
데이터 형식의 저장소 위치 |
|---|---|
호스트 운영 체제 파일 |
일반적으로 로컬 하드 드라이브에 있음 |
Windows의 호스트 페이지 파일 및 크래시 덤프 |
일반적으로 로컬 하드 드라이브에 있음 |
장애 조치(Failover) 클러스터 공유 상태 |
공유 네트워크 저장소 또는 클러스터 공유 볼륨 |
가상 하드 디스크 파일 및 가상 컴퓨터 구성 파일 |
일반적으로 공유 네트워크 저장소 또는 클러스터 공유 볼륨에 있음 |
이 단계의 나머지 부분에서는 가상 컴퓨터에 필요한 저장소에 대해 자세히 다룹니다.
작업 3b: 저장소 옵션
가상 컴퓨터 구성 파일 및 가상 하드 디스크를 저장하기 위해서는 다음과 같은 옵션을 사용할 수 있습니다.
옵션 1: 직접 연결 저장소
직접 연결 저장소는 네트워크에 직접 연결되는 대신 서버에 직접 연결된 컴퓨터 저장소 시스템을 말합니다. 직접 연결 저장소는 내부 저장소로만 제한되지 않습니다. 여기에는 JBOD(just-a-bunch-of-disks) 엔클로저 및 SAS 또는 다른 디스크 컨트롤러를 통해 연결된 엔클로저를 비롯하여 하드 디스크 드라이브가 포함된 외부 디스크 엔클로저도 사용될 수 있습니다.
장점 |
단점 |
|---|---|
|
|
옵션 2: 네트워크 연결 저장소
네트워크 연결 저장소 장치는 파일 공유를 통해 액세스할 수 있는 네트워크에 저장소를 연결합니다. 직접 연결 저장소와 달리 이 장치는 컴퓨터에 직접 연결되어 있지 않습니다.
네트워크 연결 저장소 장치는 이더넷 연결을 지원하며, 일반적으로 관리자가 디스크 공간을 관리하고, 디스크 할당량을 설정하고, 보안 기능을 제공하고, 검사점 기술을 사용할 수 있습니다. 네트워크 연결 저장소 장치에서는 다중 프로토콜이 지원됩니다. 여기에는 네트워크 연결 파일 시스템, CIFS(Common Internet File Systems) 및 SMB(Server Message Block)가 포함됩니다.
장점 |
단점 |
|---|---|
|
|
옵션 3: 저장소 영역 네트워크
SAN(저장소 영역 네트워크)은 저장소를 공유할 수 있게 해주는 전용 네트워크입니다. SAN은 저장소 장치, 상호 연결된 네트워크 인프라(스위치, 호스트 버스 어댑터 및 케이블) 및 이 네트워크에 연결된 서버로 구성됩니다. SAN 장치는 대규모 데이터에 대한 연속적이고 신속한 액세스 기능을 제공합니다. 지정된 배포에 대한 통신 및 데이터 전송 메커니즘은 일반적으로 저장소 패브릭으로 알려져 있습니다.
SAN에는 개별 네트워크가 사용되며, 일반적으로 LAN(local area network)을 통해 다른 장치에서 액세스할 수 없습니다. SAN은 SMI-S(Storage Management Initiative Specification), SNMP(Simple Network Management Protocol) 또는 고유 관리 프로토콜을 사용하여 관리할 수 있습니다.
SAN은 파일 추상화를 제공하지 않으며, 블록 수준 작업만 제공합니다. 가장 일반적으로 사용되는 SAN 프로토콜은 iSCSI, 파이버 채널 및 FCoE(Fiber Channel over Ethernet)입니다. SMI-S 또는 소유 관리 프로토콜은 디스크 영역 지정, 디스크 매핑, LUN 마스킹 및 오류 관리와 같은 추가 기능을 제공할 수 있습니다.
장점 |
단점 |
|---|---|
|
|
옵션 4: 서버 메시지 블록 3.0 파일 공유
Hyper-V는 구성 파일, 가상 하드 디스크 파일 및 검사점과 같은 가상 컴퓨터 파일을 SMB(서버 메시지 블록) 3.0 프로토콜을 사용하는 파일 공유에 저장할 수 있습니다. 파일 공유는 일반적으로 중복성을 제공할 수 있도록 스케일 아웃 파일 서버에 배치됩니다. 스케일 아웃 파일 서버를 실행할 때는 한 노드가 가동 중지될 경우에도 스케일 아웃 파일 서버에 있는 다른 노드에서 파일 공유를 계속 사용할 수 있습니다.
장점 |
단점 |
|---|---|
|
|
SMB 다이렉트
SMB 다이렉트는 SMB 파일 공유의 일부로 작동합니다. SMB 다이렉트에는 낮은 대기 시간의 저장소 액세스와 최대 속도를 제공하기 위해 RDMA를 지원하는 네트워크 어댑터 및 스위치가 필요합니다. SMB 다이렉트를 통해 원격 파일 서버가 로컬 및 직접 연결 저장소와 유사하게 작동할 수 있습니다. SMB의 장점 외에도 SMB 다이렉트에는 다음과 같은 장점 및 단점이 있습니다.
장점 |
단점 |
|---|---|
|
|
.jpeg "스케일 아웃 파일 서버")
그림 3:RDMA를 포함하는 수렴형 네트워킹을 사용하는 샘플 스케일 아웃 파일 서버(영문)
추가 정보:
Windows Server를 사용하여 Hyper-V 작업(workload)에 대한 비용 효율적인 저장소 제공
Windows Server 2012 R2를 사용하여 스케일 아웃 파일 서버 클러스터의 Hyper-V VM에서 백만이 넘는 IOPS 달성(영문)
작업 3c: 물리적 드라이브 아키텍처 유형 정의
저장소에 대해 선택한 물리적 드라이브 아키텍처 유형은 저장소 솔루션의 성능에 영향을 줍니다. 디스크 유형에 대한 자세한 내용은 IaaS(Infrastructure-as-a-Service) 제품 라인 아키텍처(영문)의 섹션 7.1을 참조하세요.
작업 3d: 저장소 네트워킹 유형 정의
사용할 저장소 컨트롤러 또는 저장소 네트워킹 컨트롤러 유형은 각 호스트 그룹에 대해 선택하는 저장소 옵션에 따라 결정됩니다. 자세한 내용은 작업 3b: 저장소 옵션을 참조하세요.
작업 3e: 각 데이터 형식에 대해 사용할 저장소 유형 결정
데이터 형식을 이해하면 요구 사항에 가장 적합한 저장소 옵션, 저장소 컨트롤러, 저장소 네트워킹 컨트롤러, 물리적 디스크 아키텍처를 결정할 수 있습니다.
설계 결정 사항(영문) - 이 작업에서 결정하는 사항을 가상화 호스트 워크시트에 입력할 수 있습니다.
추가 정보:
Windows Server 2012 및 Windows Server 2012 R2에서 SMB를 통한 Hyper-V를 위한 네트워킹 구성(영문)
Windows Server 2012 Hyper-V 구성 요소 아키텍처 포스터 및 부록 참조(영문)
저장소 기술 개요(영문)
작업 4: 서버 가상화 호스트 확장 단위 정의
개별 서버 구입에는 각 서버에 대한 조달, 설치 및 구성이 필요합니다. 확장 단위를 사용하면 일반적으로 동일한 하드웨어가 포함된 서버 컬렉션을 구입할 수 있습니다. 이러한 서버 컬렉션은 미리 구성되어 있으며, 개별 서버를 추가하는 대신 확장 단위를 추가함으로써 데이터 센터에 용량을 추가할 수 있습니다.
다음 이미지는 여러 하드웨어 공급업체로부터 미리 구성된 상태로 구입할 수 있는 확장 단위를 보여 줍니다. 여기에는 랙, UPS(무정전 전원 공급 장치), 랙 내에 포함된 서버에 대한 중복 네트워크 스위치 쌍 및 10개의 서버가 포함되어 있습니다.
.jpeg "호스트 배율 단위")
그림 4:가상화 서버 호스트 확장 단위 예(영문)
확장 단위는 미리 구성된 상태로 제공되며 UPS 및 네트워크 스위치에 대해 케이블이 미리 연결되어 있습니다. 이 단위는 데이터 센터에 추가하여, 전원을 연결하고, 네트워크 및 저장소에 바로 연결하기만 하면 됩니다. 그런 다음 바로 사용할 수 있습니다. 개별 구성 요소를 확장 단위로 구입하지 않은 경우, 구매자가 모든 구성 요소를 랙에 설치하고 배선해야 합니다.
설계 결정 사항(영문) - 서버 가상화 호스트 확장 단위를 사용하도록 결정한 경우, 호스트 확장 단위 워크시트에 가상화 호스트 확장 단위에 대한 하드웨어를 정의할 수 있습니다.
팁:Microsoft Private Cloud Fast Track 프로그램을 통해 다양한 Microsoft 하드웨어 파트너에서 제공하는 미리 구성된 확장 단위를 구입할 수 있습니다.
작업 5: 서버 가상화 호스트 가용성 전략 정의
가상화 서버 호스트는 계획된 이유(예: 유지 관리) 또는 계획되지 않은 이유로 인해 사용 불가능한 상태가 될 수 있습니다. 다음은 이러한 두 가지 이유에 대해 사용할 수 있는 몇 가지 전략입니다.
계획됨
실시간 마이그레이션을 사용하여 한 호스트에서 다른 호스트로 가상 컴퓨터를 이동할 수 있습니다. 이 경우 가상 컴퓨터를 가동 중지할 필요가 없습니다.
계획되지 않음
이 시나리오는 호스트가 호스트하는 작업(workload) 특성 유형에 따라 달라집니다.
공유 상태 저장 작업(workload)의 경우, 가상 컴퓨터 내에서 장애 조치(Failover) 클러스터링을 사용합니다.
상태 저장 작업(workload)의 경우, Hyper-V 클러스터에서 고가용성 가상 컴퓨터로 실행합니다.
상태 비저장 작업(workload)의 경우, 새 인스턴스를 수동으로 또는 일부 자동화된 방식으로 시작합니다.
Hyper-V가 포함된 Windows Server에서 장애 조치(Failover) 클러스터링을 사용하는 경우 다음 표에 나열된 기능을 사용할지 여부를 고려합니다. 각 기능에 대한 자세한 정보를 보려면 해당 하이퍼링크를 클릭하세요.
기능 |
고려 사항 |
|---|---|
네트워킹 및 저장소에서 장애 조치(Failover) 클러스터링 서비스로 모니터링되지 않는 오류가 있는지 가상 컴퓨터를 모니터링합니다. |
|
가상 컴퓨터 우선 순위 설정(영문) |
|
가상 컴퓨터 선호도 방지 |
Hyper-V 클러스터의 동일 노드에서 실행하지 않으려는 가상 컴퓨터에 대해 선호도 방지를 설정합니다. 이 방식은 중복 서비스를 제공하거나 게스트 가상 컴퓨터 클러스터에 속하는 가상 컴퓨터에 사용될 수 있습니다. 참고: 선호도 방지 설정은 Windows PowerShell을 사용하여 구성합니다. |
자동화된 노드 드레이닝(영문) |
|
|
|
가상 컴퓨터에 우선 순위를 설정하는 또 다른 이유는 우선 순위가 높은 가상 컴퓨터를 시작하는 데 필요한 메모리 및 기타 리소스가 부족할 경우, 클러스터 서비스에서 우선 순위가 낮은 가상 컴퓨터를 오프라인으로 전환할 수 있기 때문입니다.
|
참고: Hyper-V 클러스터는 최대 64개 노드와 8,000개 가상 컴퓨터를 포함할 수 있습니다.
5단계: 가상화 패브릭 아키텍처 개념 계획
이 단계에서는 패브릭 아키텍처에 사용되는 논리적 개념을 정의해야 합니다.
작업 1: 유지 관리 도메인 정의
유지 관리 도메인은 함께 서비스되는 논리적 서버 컬렉션입니다. 서비스에는 하드웨어 또는 소프트웨어 업그레이드 또는 구성 변경 사항이 포함될 수 있습니다. 유지 관리 도메인은 일반적으로 각 유형의 호스트 그룹 또는 각 위치 내에 걸쳐져 있으며, 반드시 그렇게 되어야 하는 것은 아닙니다. 이 도메인의 목적은 서버 유지 관리가 소비자의 작업(workload)에 부정적인 영향을 주지 않도록 하기 위한 것입니다.
참고: 이 개념은 물리적 네트워크 및 저장소 구성 요소에 적용됩니다.
작업 2: 물리적 장애 도메인 정의
네트워크 스위치 또는 UPS(무정전 전원 공급 장치)와 같은 공유 인프라 구성 요소가 실패할 경우 가상화 서버 호스트 그룹이 함께 실패하는 경우가 많습니다. 물리적 장애 도메인은 가상화 패브릭 내에서 복원력을 지원하는 데 도움이 됩니다. 패브릭에 대해 정의한 각 호스트 그룹에 대해 장애 도메인이 어떤 영향을 주는지 이해하는 것이 중요합니다.
참고: 이 개념은 물리적 네트워크 및 저장소 구성 요소에 적용됩니다.
다음 그림의 예에서는 데이터 센터 내에 있는 호스트 그룹 컬렉션에서 유지 관리 및 물리적 장애 도메인을 보여 줍니다.
.jpeg "오류 도메인")
그림 5:유지 관리 및 물리적 장애 도메인 정의 예(영문)
이 예에서 각 서버 랙은 개별적으로 번호가 지정된 물리적 장애 도메인으로 정의되어 있습니다. 이는 각 랙의 맨 위에 네트워크 스위치가 있고 맨 아래에 UPS가 있기 때문입니다. 랙 내에 있는 모든 서버는 이러한 두 가지 구성 요소에 의존하고 있으며, 어느 하나라도 실패할 경우, 해당 랙에 있는 모든 서버가 실패합니다.
랙 내에 있는 모든 서버는 또한 고유한 호스트 그룹의 멤버이기 때문에 이러한 설계는 물리적 장애 도메인 오류 시 마이그레이션이 수행되지 않음을 의미합니다. 문제 완화를 위해서는 각 호스트 그룹 유형의 물리적 장애 도메인을 추가할 수 있습니다. 더 작은 규모의 환경에서는 각 랙에서 중복 스위치 및 전원 공급 장치를 추가하거나 물리적 장애 도메인 간에 가상화 서버 호스트에 대해 장애 조치(Failover) 클러스터링을 사용할 수도 있습니다.
그림 5에서 색이 지정된 각 점선 상자는 유지 관리 도메인을 정의합니다(MD 1부터 5까지). 가상 컴퓨터의 부하 분산된 클러스터에 있는 각 서버가 개별 유지 관리 도메인 및 개별 물리적 장애 도메인 내에 포함된 서버 가상화 호스트에서 호스트되는 방식에 유의하세요.
이를 통해 패브릭 관리자는 유지 관리 도메인에 여러 서버가 분산된 응용 프로그램에 중대한 영향을 주지 않으면서도 유지 관리 도메인 내에서 모든 가상화 서버 호스트를 가동 중지할 수 있습니다. 또한 물리적 장애 도메인이 실패하더라도 부하 분산된 클러스터에서 실행되는 응용 프로그램이 완전히 사용 불가능한 상태로 되지 않습니다.
설계 결정 사항(영문) - 작업 1 및 2에서 결정한 사항을 설정 워크시트에 입력할 수 있습니다.
작업 3: 예약 용량 정의
패브릭에서 발생하는 개별 서버 오류는 불가피합니다. 패브릭 설계는 장애 및 유지 관리 도메인에서 서버 컬렉션의 오류를 수용하는 것처럼 개별 서버 오류도 수용할 수 있어야 합니다. 다음 그림은 그림 5와 동일하지만, 여기에서는 실패한 3개 서버가 빨간색으로 표시되어 있습니다.
.jpeg "실패한 서버")
그림 6:실패한 서버(영문)
그림 6에서 서버 가상화 호스트는 다음 호스트 그룹, 유지 관리 도메인 및 물리적 장애 도메인에서 실패했습니다.
호스트 그룹 |
물리적 장애 도메인 |
유지 관리 도메인 |
|---|---|---|
2 |
2 |
3 |
3 |
3 |
2 |
4 |
4 |
2 |
부하 분산된 클러스터에서 실행되는 응용 프로그램은 물리적 장애 도메인 2의 호스트가 실패하더라도 응용 프로그램이 세 번째로 용량이 적은 상태로 작동하기 때문에 계속 사용할 수 있습니다.
물리적 장애 도메인 3의 가상 컴퓨터 중 하나를 호스트하는 서버 가상화 호스트가 실패한 경우 또는 유지 관리 도메인 2가 유지 관리를 위해 가동 중지된 경우에는 어떻게 될지 고려해 보세요. 그러한 경우에는 응용 프로그램의 용량이 2/3 줄어듭니다.
이러한 상황이 가상화 패브릭에서 허용될 수 없는지 결정할 수 있습니다. 실패한 서버로 인한 영향을 완화하기 위해서는 각 물리적 장애 도메인 및 유지 관리 도메인에 예약 용량이 충분한지 확인하여 정의하는 허용 가능한 수준 아래로 용량이 떨어지지 않도록 할 수 있습니다.
예약 용량 계산에 대한 자세한 내용은 클라우드 서비스 기초 참조 아키텍처 - 원칙, 개념 및 패턴에서 예약 용량(영문)을 참조하세요.
6단계: 초기 기능 특징 계획
이 문서의 모든 작업을 완료한 다음에는 패브릭이 충족할 수 있는 초기 서비스 품질 수준뿐만 아니라 패브릭에서 가상 컴퓨터 및 저장소를 호스트하기 위한 초기 비용을 결정할 수 있습니다. 하지만 이 문서의 다음 단계 섹션에서 설명하는 패브릭 관리 도구 및 인적 자원을 구현해야만 이러한 작업을 완료할 수 있습니다.
작업 1: 저장소 및 가상 컴퓨터에 대한 초기 SLA 메트릭 정의
패브릭 관리자는 패브릭이 충족해야 하는 서비스 품질 메트릭이 자세히 기술된 SLA(서비스 수준 계약)를 정의합니다. 가상 컴퓨터 관리자는 패브릭 사용 방식을 계획하기 위해 이러한 내용을 알아야 합니다.
최소한 여기에는 가용성 메트릭이 포함되지만, 다른 메트릭도 포함될 수 있습니다. 가상화 패브릭 SLA 메트릭에 대한 기준을 이해하기 위해서는 Microsoft Azure와 같은 공용 클라우드 공급자에서 제공하는 항목을 검토해볼 수 있습니다. 가상 컴퓨터 호스팅의 경우, 이러한 SLA는 고객이 동일한 작업(workload)을 실행하는 2개 이상의 가상 컴퓨터 인스턴스를 배포하고, 이러한 인스턴스를 서로 다른 장애 및 업그레이드 도메인(이 설명서에서 "유지 관리 도메인"이라고 부름)에 배포할 경우 최소한 이러한 가상 컴퓨터 중 하나는 항상 99.95%의 가용성을 갖도록 보장합니다.
Azure SLA에 대한 자세한 내용은 서비스 수준 계약을 참조하세요. 가상화 패브릭에서는 이러한 공용 클라우드 공급자의 메트릭을 충족하거나 초과하는 것이 가장 좋습니다.
작업 2: 저장소 및 가상 컴퓨터 호스트를 위한 초기 비용 정의
패브릭 설계 후에는 다음을 계산할 수도 있습니다.
패브릭에 대한 하드웨어, 공간, 전원 및 냉각 비용
패브릭의 호스팅 용량
이 정보를 패브릭 관리 도구 및 인적 자원 비용과 같은 다른 비용 정보와 함께 사용하면 가상 컴퓨터 및 저장소를 호스트하기 위한 최종 비용을 결정할 수 있습니다.
가상 컴퓨터 및 저장소의 초기 비용을 파악하기 위해서는 Microsoft Azure와 같은 공용 클라우드 공급자의 호스팅 비용을 검토할 수 있습니다. 자세한 내용은 가상 컴퓨터 가격 세부 정보를 참조하세요.
항상 그런 것은 아니지만, 일반적으로 사용자의 패브릭은 하드웨어, 데이터 센터 공간 및 전원 등에서 대규모 할인을 얻을 수 있는 대규모 공용 공급자의 패브릭에 비해 크기가 훨씬 작기 때문에 그러한 공급자들보다 비용이 상당히 높습니다.
다음 단계
이 문서의 모든 작업을 완료한 다음에는 조직의 요구 사항을 충족하는 패브릭 설계를 얻을 수 있습니다. 또한 비용 및 서비스 수준 메트릭이 포함된 초기 서비스 특징 정의도 얻을 수 있습니다. 하지만 패브릭에 사용할 인적 자원 비용 및 관리 도구와 프로세스를 결정할 때까지는 최종 서비스 수준 메트릭 및 비용을 결정할 수 없습니다.
Microsoft System Center 2012는 가상화 패브릭 프로비전, 모니터링 및 유지 관리를 위한 완벽한 기능 집합을 제공합니다. 다음과 같은 리소스를 참고하여 패브릭 관리를 위해 System Center를 사용하는 방법을 확인할 수 있습니다.
패브릭 관리 아키텍처 가이드(영문)