3.2 Planning Clustered Implementations of SQL Server under vSphere

기본 WSFC는 가용성만 제공합니다. 스케일 아웃 또는 로드 밸런싱 기능은 제공하지 않습니다. WSFC 위에서 실행되는 워크로드는 이러한 기능을 제공하는 기능의 일부로 추가할 수 있지만, SQL Server 배포에 대한 일반적인 경험 법칙은 AG 또는 FCI의 크기를 적절히 조정하고 확장해야 한다는 것입니다. WSFC에 참여하는 서버 또는 VM을 노드라고 합니다. 클러스터된 SQL Server에 참여하는 각 노드의 구성이 동일한지 확인하는 것이 일반적인 모범 사례입니다.

vSphere에서 지원되는 Microsoft 클러스터 구성의 최신 구성에 대한 자세한 내용은 항상 VMware 기술 자료 문서 “Microsoft Cluster Service (MSCS) support on ESXi (1004617)“을 참조하십시오.

3.2.1 Windows Server 장애 조치 클러스터 배포

이 섹션에서는 vSphere에서 AG 또는 FCI에 대한 기본 WSFC 구성을 계획하는 데 도움이 됩니다.

3.2.1.1. Windows Server 버전, 노드 수 및 지원 가능성 Windows Server 2008 R2 이하 버전에서는 엔터프라이즈 또는 데이터센터 에디션이 WSFC(이전 버전에서는 Microsoft Clustering Service (MSCS)로 알려짐)를 생성할 수 있어야 합니다. Windows Server 2012 이상에서는 표준 또는 데이터센터 에디션을 사용할 수 있습니다.

Windows Server 2012 이상은 하나의 WSFC에서 노드라고 하는 서버를 최대 64대까지 지원할 수 있습니다. VMware ESXi™는 단일 FCI 구성에서 최대 16개의 VM을 지원합니다.

현재 Microsoft 설명서에서는 FCI와 AG를 상호 배타적인 것으로 취급하며 총 노드 수에 대해 다른 방식으로 해석할 수 있습니다. 공유 스토리지가 있는 구성, 즉 FCI의 경우 최대 노드 수는 SQL Server 버전에 따라 다릅니다. SQL Server 2022 Enterprise 에디션의 경우 Windows Server 에디션이 지원하는 최대 노드 수입니다. SQL Server 2022 Standard 에디션의 경우 최대 노드는 2개입니다.

자세한 내용은 다음 자료를 참조하세요:

AG는 최대 복제본 수까지 지원할 수 있으므로 하나 이상의 FCI를 결합하여 AG를 구성하는 경우에도 WSFC 구성의 총 VM 수는 걱정할 필요가 없습니다. 그러나 혼동이 있는 경우 VMware 지원팀에 문의하여 제안한 솔루션이 지원되는 솔루션인지 확인해야 합니다. Microsoft는 WSFC에서 최대 64개의 노드를 지원하며 SQL Server의 노드 수는 기능에 따라 다르므로 FCI를 배포하는지 여부와 공유 스토리지가 있는지 여부에 따라 제한이 적용됩니다. WSFC 구성이 Microsoft에서 지원되는지 확인하기 위해 Windows Server 2008에 유효성 검사라는 프로세스가 도입되었습니다. 이 프로세스는 WSFC를 만들기 전에 제안된 구성의 유효성을 검사합니다. 유효성 검사 테스트 결과 구성에 문제가 없는 것으로 나타나면 VM을 WSFC로 클러스터링할 수 있습니다.

가상화가 널리 채택됨에 따라 Microsoft는 클러스터 유효성 검사 프로세스의 특정 부분을 건너뛰고 특히 Microsoft의 제어 또는 책임 범위를 벗어난 구성 요소에 대해 특정 결과를 다르게 해석할 수 있는 옵션을 도입했습니다. 이러한 구성 요소에 대한 지원은 VMware와 같은 타사 공급업체로 전환되었습니다. 또한 Microsoft는 테스트 실패 시 취해야 할 필수 조치에 대한 지침도 업데이트했습니다. 이제 Microsoft는 더 이상 테스트 보고서가 실패했거나 테스트를 건너뛰었다는 이유만으로 클러스터 설정을 막지 않습니다.

VMware는 고객이 VMware vSphere에서 호스팅되는 VM에서 클러스터를 설정하기 전에 클러스터 유효성 검사를 수행할 것을 계속 권장합니다. 노드에 스토리지를 표시하기 위해 RDM(Raw Device Mapping)을 사용하는 경우 클러스터 유효성 검사 마법사가 스토리지 테스트에서 오류를 보고할 수 있습니다. 이는 마법사가 이 유효한 스토리지 옵션에 대한 개념이 없기 때문입니다. 이 테스트를 완전히 건너뛰거나 경고를 무시해도 괜찮습니다.

Microsoft는 Windows Server 2022에서 클러스터링 관련 기능을 더 이상 사용하지 않습니다. 그러나 클러스터 유효성 검사 마법사는 Windows Server 2022에서 클러스터 설정의 유효성을 검사할 때 이러한 기능 중 일부를 여전히 확인합니다. 예를 들어, Microsoft는 “LBFO” 기능을 제거하고 VMware vSphere에 존재하지 않는 Microsoft 하이퍼바이저 기능인 “Switch Enabled Teaming Configurations"으로 대체했습니다. 마법사는 기본 하이퍼바이저 플랫폼에 관계없이 모든 Windows OS 인스턴스에서 이 기능을 확인하기 때문에 유효성 검사 프로세스 중에 “Switch Enabled Teaming (SET) Configurations” 경고가 생성됩니다.

이 문제는 향후 Windows Server 2022 업데이트에서 수정될 가능성이 높지만, 이전 버전의 Windows에는 이러한 수정 사항이 백포트되지 않을 가능성이 높습니다. 유효성 검사 테스트를 수행하기 전에 이 오류를 무시하거나 이 기능에 대한 확인을 선택 취소하는 것이 안전합니다. 아래 그림 6을 참조하세요:

그림 6 - 유효성 검사 마법사의 SET 확인

Support policy for clustered configurations - SQL Server | Microsoft Learn에 명시된 Microsoft의 지원 가능성을 충족하는 한 WSFC 노드는 모두 물리적 노드, 모두 가상 노드 또는 물리적 노드와 가상화된 노드가 혼합된 노드가 될 수 있습니다. 물리적 노드와 vSphere의 VM이 혼합된 WSFC는 vSphere 5.5 이상에서 지원됩니다.

3.2.1.2. Active Directory 도메인 서비스 및 도메인 이름 서비스

Windows Server 2016부터 Microsoft는 WSFC에 “Active Directory-Detached Cluster” 기능을 도입했습니다. 이를 통해 Active Directory 도메인에 속하지 않는 노드(“Workgroup Cluster"라고 함)로 WSFC를 만들 수 있습니다. 작업 그룹 WSFC를 사용하면 도메인 구성원이 아닌 노드(이 구성을 “Domain Independent Availability Group“이라고 함)가 없는 SQL Server Always On 가용성 그룹을 구성할 수 있으며, 도메인 구성원 요구 사항을 제외하고는 모든 의도와 목적에 있어 “일반” 가용성 그룹과 동일합니다. 이와 유사하지만 제한적이고 덜 강력한 구성 옵션이 Windows Server 2012 and SQL Server 2012에 도입되었습니다.

이전 단락에서 설명한 시나리오를 제외하고 WSFC에는 Active Directory Domain Services (ADDS)와 Domain Name Services (DNS)가 모두 필요합니다. DNS는 반드시 Microsoft의 구현일 필요는 없습니다. 필요한 경우 인프라, 특히 WSFC가 액세스할 수 있도록 ADDS와 DNS를 모두 이중화해야 합니다. ADDS에서는 이름인 모든 리소스에 대해 해당 개체가 만들어지고, 이후 해당 이름과 연결된 IP 주소가 DNS에 저장됩니다.

3.2.1.3. 네트워킹

Windows Server 2008 이전에는 WSFC를 구성하는 전통적인 방법은 각각 자체 서브넷에 두 개의 개별 네트워크를 두는 것이었습니다:

하나는 일반적으로 공용 네트워크라고 하는 외부 트래픽용 네트워크입니다.
하나는 클러스터 내 트래픽 전용으로, 일반적으로 사설망 또는 하트비트 네트워크라고 합니다.

이 구성은 또한 이 두 네트워크 아래에 별도의 네트워크 카드가 있다고 가정합니다. 각 네트워크 카드는 서로 다른 물리적 스위치에 연결되어 있습니다. 이 구성은 WSFC의 네트워킹이 단일 장애 지점이 아니며 네트워크 중 하나가 다운되더라도 WSFC 노드가 계속 통신할 수 있도록 보장합니다. 가상화된 환경으로 변환하면 그림 7과 같습니다.

그림 7. WSFC 노드의 논리적 네트워크 토폴로지 예시

Windows Server 2008에 유효성 검사 기능이 도입되면서 Microsoft는 여전히 중복 네트워킹을 확인하지만 중복 네트워킹이 없는 구성도 허용합니다. 소프트웨어 정의 환경에서는 물리적 네트워크에 다시 매핑하는 것이 물리적 NIC가 있을 때와 동일하지 않습니다. 네트워크 연결이 섀시에 통합된 블레이드 기반 시스템을 사용하는 경우 이는 더욱 추상화될 수 있습니다. 현실적으로 vNIC는 일반적으로 물리적 네트워크 카드와 같은 방식으로 장애가 발생할 수 없습니다.

Microsoft는 더 이상 WSFC에 두 개 이상의 NIC를 요구하지 않으며, “dedicated heartbeat NIC"라는 개념은 하나의 NIC를 그렇게 지정하더라도 WSFC가 정상 작동 시 정상적인 “public” 트래픽에 해당 NIC를 사용한다는 사실에 의해 사라졌습니다.

WSFC의 일부가 될 VM에 단일 vNIC를 구성하는 경우 유효성 검사에서 WSFC에 대해 단일 네트워크가 확인되면 여전히 경고를 생성합니다. 이 구성을 고의로 생성한 경우 이러한 경고가 예상됩니다. 보고서 상단에서 네트워크 카테고리에 그림 8과 유사한 경고가 표시되는 것을 볼 수 있습니다.

그림 8. 경고를 반영하는 네트워크 유효성 검사 카테고리

네트워크를 클릭하면 실행된 테스트 목록이 있는 섹션으로 이동합니다. 이 경우 그림 9에서 네트워크 구성 유효성 검사가 경고를 생성한 테스트라는 것을 알 수 있습니다.

그림 9. 경고와 함께 네트워크 통신 확인

더 자세히 살펴보면 그림 10에서 구성된 단일 vNIC로 인해 생성된 경고 메시지를 확인할 수 있습니다. 강조 표시된 두 개의 메시지는 동일하며 하나의 NIC만 인식하고 있으며 단일 장애 지점일 수 있음을 보고하고 있습니다.

그림 10. 단일 vNIC 경고

vSphere 인프라의 networking configuration에 대한 규범적 지침을 따랐다면 네트워킹이 단일 vNIC 아래에서 완전히 이중화되므로 이 구성은 완벽하게 허용됩니다. 그러나 해당 vNIC가 단일 물리적 NIC에 잘못 매핑된 vSwitch(또는 vSphere Distributed Switch)에 연결되어 있는 경우 네트워크 장애로 인해 WSFC가 중단될 수 있으며, 이에 따라 해당 스위치에 구성된 AG 또는 FCI가 중단될 수 있습니다. 이러한 구성인 경우, 네트워크 계층에서 고가용성이나 중복성이 없으므로 Windows Server를 클러스터링하고 AG 또는 FCI를 만들지 마세요.

비슷한 방식으로, 여러 물리적 스위치에 연결된 여러 포트가 있는 vSphere 호스트 내부의 단일 물리적 NIC도 단일 장애 지점입니다. 포트는 물리적으로 분리된 것으로 간주되지만 카드 자체가 단일 장애 지점입니다. 블레이드를 사용하는 경우 블레이드는 모든 네트워킹을 포함하는 인클로저와 백플레인을 공유한다는 점에 유의하세요.

vSphere 수준에서 중복성을 생성하는 한 가지 방법은 ESXi에서 NIC를 티밍하는 것입니다(KB 100488을 따르십시오). 일반적으로 드라이버 또는 소프트웨어에서 제공하는 기능에 따라 장애 조치, 부하 분산 또는 이 두 가지의 조합(일반적으로 권장됨) 중 한 가지 방식으로 구성할 수 있으므로 NIC를 팀으로 구성하면 더 높은 대역폭을 제공할 수도 있습니다. Microsoft는 게스트 내부의 NIC 팀 구성도 지원하며, 이 경우 Windows Server 2012 이상에서 Windows Server에서 제공하는 기본 제공 팀 구성을 사용하는 것이 좋습니다.

3.2.1.4. Quorum

WSFC가 정상적으로 운영되도록 하기 위해 정족수(Quorum)이라는 메커니즘을 사용합니다. 정족수를 채우지 못하면 WSFC와 그 위에서 실행 중인 모든 것(예: AG 또는 FCI)도 오프라인 상태로 전환됩니다. 쿼럼은 디스크, 파일 공유 또는 Windows Server 2016 이상 버전에서는 Microsoft Azure의 클라우드 증인(witness)라는 다른 리소스를 사용합니다. 파일 공유의 경우, 공유는 고가용성이 보장되어야 하는 erver Message Block (SMB) 3.2 이상 공유여야 합니다. 쿼럼에 대해 자세히 논의하는 것은 이 백서의 범위를 벗어납니다. 자세한 내용은 문서 끝에 있는 링크를 참조하세요. 좀 더 특별한 주의가 필요한 한 가지 방법은 디스크 기반 증인(witness)입니다. 공유 디스크 스토리지에 접근하는 방법은 섹션 3.2.2.2에서 다룹니다.

3.2.1.5. 박스 내 클러스터, 박스 간 클러스터, 호스트 수 및 노드 배치

vSphere에는 VMware 개념인 WSFC를 생성하는 두 가지 방법, 즉 CIB(클러스터 인 박스) 및 CAB(클러스터 간 박스)가 있습니다. CIB는 모든 WSFC 노드가 동일한 물리적 호스트에 있는 경우입니다. CAB는 WSFC 노드가 서로 다른 하이퍼바이저 호스트에 배치되는 경우입니다. 이러한 용어는 vSphere의 AG 및 FCI 구성 모두에 적용될 수 있습니다. ESXi 호스트는 단일 장애 지점이기 때문에 일반적으로 프로덕션 환경에는 CIB를 권장하지 않지만 테스트 구성에는 적합할 수 있습니다. 또한 기본 스토리지가 RDM으로 표시되는 FCI 구성에서는 CIB가 지원되지 않습니다.

두 구성 모두에서 노드에 대한 선호도 또는 반선호도 규칙을 구성하여 노드를 함께 유지(CIB) 또는 분리(CAB)해야 합니다. CAB의 경우, 적절한 선호도 방지 규칙을 구성하면 가상화된 WSFC 노드가 동일한 하이퍼바이저 호스트에서 실행될 수 없습니다. 이는 필요한 호스트 수에 영향을 미치며, 최종적으로 VMware vSphere DRS(Distributed Resource Scheduler™), VMware vSphere HA(High Availability) 또는 VMware vSphere vMotion®을 사용할 수 있는 방법을 결정합니다. CIB의 경우 선호도를 구성하면 노드가 동일한 호스트에 유지되도록 할 수 있습니다.

예를 들어, CAB여야 하는 FCI 구성을 구성하는 WSFC 노드가 두 개 있는 경우 WSFC 노드 중 하나를 실행하던 호스트 중 하나에 장애가 발생하는 경우 세 번째 호스트에서 해당 VM을 시작할 수 있도록 최소 세 개의 vSphere 호스트가 필요합니다. 활성 WSFC 노드가 장애가 발생한 ESXi 호스트의 VM인 경우 WSFC 메커니즘이 먼저 인계받아 이 장애가 발생하는 동안 클러스터된 리소스를 피어(패시브) 노드로 이동합니다. 장애가 발생한 호스트의 노드가 다른 곳에서 다시 시작되면 해당 노드는 더 이상 WSFC의 리소스를 소유하지 않게 됩니다.

그림 11. FCI 구성에서 두 개의 WSFC 노드에 대한 DRS 선호도 방지 규칙

vSphere HA 및 vMotion이 선호도/반선호도 규칙을 준수하도록 하려면 그림 12에 표시된 대로 적절한 vSphere HA 규칙 설정도 설정해야 합니다.

그림 12. CAB 구성에 대해 설정된 WSFC 노드에 대한 선호도 반감을 위한 vSphere HA 설정

한 가지 주의해야 할 점은 VMware는 ESXi 호스트 또는 WSFC VM이 포함된 vSphere 클러스터에서 메모리 리소스를 과도하게 커밋하지 않을 것을 강력히 권장한다는 것입니다. ESXi 메모리 초과 커밋을 피할 수 없는 경우 VMware는 WSFC VM에 할당된 모든 메모리를 예약하여 항상 리소스에 대한 권한을 갖도록 할 것을 권장합니다. 자세한 내용은 “Setup for Failover Clustering and Microsoft Cluster Service “을 참조하십시오.

3.2.2 장애 조치 클러스터 인스턴스 상시 가동

FCI는 역사적으로 물리적 또는 가상 클러스터링된 SQL Server 구성의 가장 일반적인 형태입니다. 클러스터된 SQL Server 인스턴스가 하나 있는 WSFC를 단일 인스턴스 장애 조치 클러스터라고 합니다. 인스턴스가 두 개 이상인 경우 해당 FCI 구성을 다중 인스턴스 장애 조치 클러스터라고 합니다. WSFC에 두 개 이상의 노드 및/또는 두 개 이상의 인스턴스를 가질 수 있으므로 활성/비활성 및 활성/활성은 올바르지 않습니다. FCI에 대한 적절한 용어에 대한 자세한 내용은 백서 뒷부분의 링크를 참조하세요. SQL Server Standard Edition은 2노드 FCI를 지원하며, Enterprise Edition은 기본 Windows Server 버전 및 에디션에서 지원하는 최대 노드 수까지 지원합니다.

FCI는 인스턴스 장애 조치(계획된 또는 계획되지 않은)가 발생할 경우 다른 노드에서 자동으로 다시 시작되고 필요한 모든 것(예: 로그인, SQL Server 에이전트 작업 등)이 있는지 걱정할 필요가 없기 때문에 VMware에서도 여전히 인기가 있습니다. 또한 기본 Windows Server 설치에 패치를 적용해야 할 때 다른 노드로 FCI를 이전하면 되므로 가용성을 제공하고 다운타임을 최소화할 수 있습니다. VMware 옵션은 VM 자체는 보호하지만 애플리케이션 수준 중단 또는 전체 중단을 유발하지 않는 Windows Server OS의 구성 요소 오류로 인한 다운타임은 보호하지 않습니다.

3.2.2.1. ADDS, DNS 및 FCI

FCI는 AD, DS 및 DNS에서 개체를 가져오는 고유한 이름도 갖습니다. 이는 또한 FCI에 하나 이상의 IP 주소가 할당되어야 함을 의미합니다. WSFC가 멀티 서브넷인 경우 둘 이상의 IP 주소를 할당할 수 있습니다. 각 IP 주소와 이름은 WSFC 및 기본 노드의 이름과 IP 주소와 다릅니다. 예를 들어, 노드의 이름이 PHILLY 및 SOUTHJERSEY이고 WSFC의 이름이 BFBRIDGE인 경우, FCI의 이름은 LIBERTYBELL이 될 수 있습니다. 그러면 LIBERTYBELL은 CNO의 자식인 가상 컴퓨터 객체(VCO)라는 객체를 가져옵니다.

인스턴스가 기본 인스턴스인 경우, 다른 이름이 아닌 LIBERTYBELL을 통해 액세스됩니다. 명명된 인스턴스는 위에서 언급한 대로 슬래시 뒤에 추가 이름이 붙습니다(예: LIBERTYBELL\MUSEUM). 동일한 WSFC에 다른 FCI를 설치하려면 추가 고유 이름과 IP 주소가 필요합니다.

3.2.2.2. FCI용 스토리지

FCI에서 사용하는 주 데이터 및 로그 스토리지의 경우 모든 노드에서 액세스할 수 있는 일종의 스토리지가 필요합니다. 스토리지는 FCI 구성에서 단일 장애 지점입니다. 게스트 내부 관점에서 볼 때 아래 표 2에 표시된 다음 방법을 통해 이 작업을 수행할 수 있습니다.

표 2. WSFC의 버전별 SQL Server FCI 공유 디스크 옵션


	Drive Letter	Drive Letter + Mount Point	SMB 3.0	Cluster Shared Volume (CSV)	Local TempDB
SQL Server 2008	Yes	Yes	No	No	No
SQL Server 2008 R2	Yes	Yes	No	No	No
SQL Server 2012	Yes	Yes	Yes	No	Yes
SQL Server 2014	Yes	Yes	Yes	Yes	Yes
SQL Server 2016	Yes	Yes	Yes	Yes	Yes
SQL Server 2017	Yes	Yes	Yes	Yes	Yes
SQL Server 2019	Yes	Yes	Yes	Yes	Yes
SQL Server 2022	Yes	Yes	Yes	Yes	Yes

드라이브 문자, 마운트 지점이 아래에 있는 드라이브 문자 및 CSV를 모두 사용하려면 스토리지가 모든 기본 호스트에 제공된 다음 해당 WSFC 구성에 참여하는 VM에 제공되어야 합니다. SQL Server FCI가 CSV를 사용하는 방법에 대한 자세한 내용은 SQL HA blog post을 참조하세요.

Use Cluster Shared Volumes in a failover cluster을 참조하여 Windows Server 장애 조치 클러스터에 CSV를 사용하기 위한 자세한 정보 및 고려 사항을 확인하십시오.

다음과 같은 방법으로 스토리지가 vSphere에서 지원됨을 나타냅니다:

파이버 채널
FCoE(이더넷을 통한 파이버 채널) - vSphere 5.5 이상에서는 기본 지원, FCoE에 대한 자세한 내용은 VMware 기술 자료 문서 “Microsoft Clustering on VMware vSphere: Guidelines for supported configurations“의 표 1의 참고 4를 참조하십시오: 지원되는 구성에 대한 지침"을 참조하십시오.
iSCSI - 기본(vSphere 5.5 이상) 또는 게스트 내. 게스트 내부에서 iSCSI를 사용하는 경우 별도의 vNIC를 사용하여 노드가 SQL Server 또는 WSFC 트래픽에 사용하는 네트워크가 아닌 다른 네트워크에 연결해야 합니다.
물리적 원시 디바이스 매핑(RDM, 물리적 RDM 또는 pRDM이라고도 함)
가상 볼륨(vVols) - Virtual Volumes (vVols) now supports WSFC을 참조하세요.
공유 디스크 WSFC 구성에 VMFS 지원 스토리지(VMDK)를 사용하는 것에 대한 지원은 vSphere 6.7 U3(vSAN 스토리지용)에서 시작되었으며, 일반적으로 “Clustered VMDK Datastore” 유형이 도입된 vSphere 7.0부터 지원되기 시작했습니다.
VMware는 vSAN iSCSI feature의 출시와 함께 vSphere 6.7에서 제한적으로 FCI용 VMDK 지원 공유 디스크를 지원하기 시작했습니다.

vSphere 6.7 이전에는 FCI에 대해 지원되는 유일한 디스크 옵션은 RDM(Raw Device Mapping)이었습니다. vSphere 6.7은 VMware 가상 볼륨 스토리지 옵션을 통해 제공되는 VMDK에 대한 지원을 제공했습니다. 6.7 업데이트 3의 릴리스와 함께 VMDK에 대한 이 지원은 VMware vSAN 스토리지로 확장되었습니다.

vSphere 7.0에서는 SAN 기반 스토리지에 대한 “Clustered VMDK” 데이터스토어 옵션을 도입하여 디스크 프레젠테이션 옵션인 FCI 구성으로 RDM에 대한 기존 요구 사항(및 이에 대한 의존성)을 제거했지만 RDM은 모든 버전의 vSphere에서 계속 지원됩니다.

FCI 데이터 및 로그 파일에 사용할 디스크에는 PVSCSI(VMware Paravirtual SCSI) 어댑터를 사용하고, 성능 향상을 위해 둘 이상의 PVSCSI 컨트롤러를 사용하여 I/O 부하를 분할하여 동시성을 향상시키는 것이 좋습니다. 큐 깊이 및 VM커널 허용량과 같은 디스크 관련 구성 주제에 대해 설명하는 다음 VMware KB(1267, 1268, 2053145)의 조언에 따라 PVSCSI 어댑터를 올바르게 구성하고 있는지 확인합니다.

3.2.2.3. FCI에 기본 VMDK 사용(vSphere 6.7U3 이상)

vSphere 7.0의 “Clustered VMDK” 기능이 릴리스됨에 따라 이제 SCSI-3 영구 예약 기능을 지원하여 기본적으로 WSFC 노드 간/노드 간에 VMDK를 성공적으로 공유할 수 있습니다. 따라서 더 이상 WSFC shared-disk clustering에 RDM이 필요하지 않습니다.

클러스터된 VMDK를 사용할 때 고려해야 할 사항과 제한 사항은 VMware vSphere Product Documentation의 “Limitations of Clustered VMDK support for WSFC” 섹션에 자세히 나와 있습니다.

몇 가지 제한 사항만 충족하면 기존 VMFS 데이터스토어에서 클러스터된 VMDK 지원을 사용하도록 설정할 수 있습니다. 클러스터된 VMDK 지원 데이터스토어는 범용 데이터스토어를 위한 것이 아니므로, VMware는 클러스터된 VMDK를 고려할 때 가능하면 실용적인 경우 새로운 전용 LUN을 생성하여 사용할 것을 권장합니다.

이 기능의 가장 일반적인 용도로 예상되는 것은 SQL Server Failover Clustering Instance (FCI)를 생성하는 데 필요한 공유 디스크 Windows Server Failover Clustering (WSFC)에 대한 지원입니다.

이 용도로 기존 데이터스토어를 다시 사용해야 하는 경우, 특히 해당 VMDK가 FCI 구성에 참여하지 않을 경우 기존 VMDK를 모두 대상 데이터스토어에서 마이그레이션할 것을 VMware는 적극 권장합니다. VMware는 클러스터된 VMDK 사용 데이터스토어에서 공유 VMDK와 비공유 VMDK의 혼합을 지원하지 않습니다.

데이터스토어가 프로비저닝된 후에만 데이터스토어에서 클러스터된 VMDK에 대한 지원을 사용하도록 설정할 수 있습니다.

프로세스는 아래 이미지와 같습니다:

VMware vCenter® Client에서 “Clustered VMDK"를 사용하도록 설정할 데이터스토어를 선택합니다.
“Configure” 탭을 클릭합니다.
“General” 섹션을 클릭합니다.
아래 그림과 같이 “Clustered VMDK” 섹션에서 “Enable"을 클릭합니다. 그림 13 - 클러스터된 VMDK 활성화(1단계)
경고를 읽은 후 “Enable"을 클릭하여 변경 사항을 커밋합니다. 그림 14 - 클러스터된 VMDK 활성화(2단계)
“클러스터된 VMDK"의 상태가 “사용됨"으로 설정되었는지 확인합니다.

그림 15 - 클러스터된 VMDK 사용(3단계)

Windows Server Failover Clustering은 SCSI-3 PR 명령을 사용하여 클러스터된 디스크 리소스에 대한 액세스를 조정합니다. 이러한 명령(PR-IN 및 PR-Out)은 데이터스토어의 VSCSI 계층에서 에뮬레이션됩니다. 이 기능을 사용하려면 데이터스토어 관점에서 지원이 필요합니다. 위와 같이 데이터스토어에서 “Clustered VMDK” 기능을 활성화하는 것만으로도 데이터스토어가 SQL Server FCI 구성에 필요한 공유 디스크(VMDK)를 호스팅하는 데 유용하게 사용되기 위한 WSFC의 요구 사항을 충족할 수 있습니다.

3.2.2.4. 첫 번째 FCI 노드에서 공유 VMDK 프로비저닝

“Clustered VMDK” 데이터스토어에서 VMDK를 생성하고 할당하는 프로세스는 모든 측면에서 모든 vSphere 데이터스토어에서 수행하는 프로세스와 유사합니다.

다음은 vSphere 환경에서 VMDK 디스크를 생성하고 둘 이상의 VM에 할당하는 데 필요한 단계에 대한 개략적인 설명입니다:

디스크를 공유할 VM 중 하나를 마우스 오른쪽 버튼으로 클릭하고 “Edit Settings"을 선택합니다.
“Add New Device” 메뉴에서 아래와 같이 “Hard Disk"를 선택합니다.

그림 16 - VM에 새 공유 VMDK 디스크 추가

“New Hard disk"를 확장하고 원하는 대로 디스크 크기를 변경합니다. 그림 17에 예가 나와 있습니다.

그림 17 - 원하는 디스크 크기 지정

그림 18과 같이 “Location"를 선택한 다음 “Browse"를 클릭합니다.

그림 18 - 클러스터된 VMDK 데이터스토어 찾아보기

앞서 생성한 “Clustered VMDK” 데이터스토어를 선택합니다. OK을 클릭합니다. 그림 19에 예시가 나와 있습니다.

참고: 이 위치를 기록해 두는 것이 매우 중요합니다. 이 공유 디스크를 다른 노드에 연결할 준비가 되었을 때 이 위치에서 찾아볼 수 있습니다.

그림 19 - 공유 디스크에 대한 클러스터된 VMDK 데이터스토어 선택

그림 20과 같이 “Disk Provisioning"을 클릭하고 “Thick Provision Eager Zeroed"를 선택합니다. 백업 스토리지 어레이가 올플래시인 경우에도 Microsoft SQL Server 데이터, 로그 및 TempDB 볼륨에 대한 성능 및 높은 처리량을 고려할 경우 Eager Zeroed 씩 프로비저닝을 사용하는 것이 좋습니다.

참고: 씬 프로비저닝된 디스크는 vSAN을 사용하는 경우에만 지원됩니다.

그림 20 - 디스크 프로비저닝 형식 선택

그림 21과 같이 “Disk Mode"를 클릭하고 “Independent – Persistent"로 변경합니다.

그림 21 - 디스크 모드 지정

“Virtual Device Node” 메뉴에서 그림 22와 같이 디스크를 연결할 적절한 SCSI 컨트롤러 ID를 선택합니다.

참고: 이 디스크의 SCSI ID를 기록하는 것이 중요합니다. 이 디스크를 공유할 모든 VM의 동일한 SCSI 채널에 동일한 디스크를 연결해야 합니다.

그림 22 - SCSI 컨트롤러에 VMDK 연결하기

그림 23과 같이 디스크를 연결한 SCSI 컨트롤러를 확장하고 “SCSI Bus Sharing"를 클릭한 다음 “Physical"으로 설정되어 있는지 확인합니다. 확인을 클릭하여 모든 변경 사항을 커밋합니다.

그림 23 - 컨트롤러 버스 공유 옵션 선택

완료되면 구성이 아래 그림 24에 표시된 것과 유사하게 나타납니다:

그림 24 - 공유 VMDK 구성 정보 샘플

이제 VM의 전원을 켜고 Windows Server에서 원하는 대로 이 디스크를 포맷하는 것이 좋습니다. 이제 동일한 디스크를 공유할 추가 VM에 제공할 수 있습니다.

3.2.2.5. 다른 FCI 노드에 공유 VMDK 추가하기

디스크를 공유할 VM 중 하나를 마우스 오른쪽 버튼으로 클릭하고 “Edit Settings"을 선택합니다.
“Add New Device” 메뉴에서 그림 25와 같이 “SCSI Controller"를 선택합니다:

![]() 그림 25 - 공유 VMDK에서 사용할 컨트롤러 추가

새 SCSI 컨트롤러를 확장하고 유형을 “VMware Paravirtual"로 변경합니다. 그림 26에 예가 나와 있습니다.

그림 26 - 유형을 “VMware Paravirtual"로 변경

그림 27과 같이 SCSI 버스 공유를 “Physical"으로 변경합니다.

그림 27 - 버스 공유 옵션을 물리로 변경하기

“Add New Device"를 다시 클릭합니다. 이번에는 “Existing Hard Disk"를 선택합니다. 그림 28에 예시가 나와 있습니다.

그림 28 - 공유 디스크를 다른 VM에 추가하기

그림 29와 같이 공유하려는 디스크가 포함된 위치를 찾은 다음 올바른 디스크를 선택합니다(이전 단계에서 디스크를 생성할 때 위치를 기록해 두었음을 기억하세요).

그림 29 - 올바른 디스크 선택

중요: 디스크가 원래 노드에서와 마찬가지로 이 노드에서도 동일한 SCSI 버스에 연결되어 있는지 확인해야 합니다. 즉, 그림 30에 표시된 것처럼 이 디스크를 공유하는 모든 노드에서 SCSI ID가 일치해야 합니다.

그림 30 - 설정 검토

이제 OK를 클릭하여 구성을 완료합니다.

참고: 이전 섹션에서 이전에 이 디스크를 포맷한 경우, 추가 노드에서 다시 포맷할 필요가 없습니다. 이제 디스크를 Windows Server 및 WSFC 구성에서 사용할 수 있습니다. WSFC는 이 시점부터 리소스로서 디스크에 대한 액세스(및 소유권)를 중재합니다.

3.2.2.6. FCI에 원시 장치 매핑 지원 디스크 사용

FCI 구성에 RDM을 계속 사용해야 하는 경우 디스크를 SCSI 컨트롤러(VMware Paravirtual)에 연결하고 물리적 호환성 모드로 설정해야 합니다. 그림 31에 예가 나와 있습니다.

그림 31 - SCSI 컨트롤러에 RDM 연결

FCI에 참여할 VM에 RDM 디스크를 추가하려면 아래 지침을 따릅니다.

노드 중 하나의 설정을 편집합니다(어느 노드든 상관 없음).
“Add New Device"에서 그림 32와 같이 RDM Disk를 선택합니다.

그림 32 - RDM 디스크 선택

이제 사용 가능한 LUN 목록이 표시됩니다. RDM을 배치할 LUN을 선택한 다음 OK를 클릭합니다. 그림 33에 예가 나와 있습니다.

그림 33 - RDM 디스크용 LUN 선택

New Hard disk를 확장합니다. Compatibility Mode가 Physical로 설정되어 있고, Virtual Device Node가 올바른 PVSCSI 컨트롤러로 설정되어 있으며, Disk Mode가 물리적 디스크이므로 Independent – Persistent로 설정되어 있는지 확인합니다. 그림 34에 예가 나와 있습니다.

그림 34 - RDM 구성

그림 35와 같이 ‘Location’ 아래의 ‘Browse’를 클릭하여 RDM의 매핑 파일과 호환되는 데이터스토어로 이동합니다.

그림 35 - 호환 가능한 데이터스토어 찾아보기

이제 RDM의 매핑 파일에 적합한 데이터스토어를 선택합니다. 그림 36에 예가 나와 있습니다.

그림 36 - 데이터스토어 선택

“OK"을 클릭하여 변경 사항을 커밋합니다.

VM의 해당 데이터스토어를 보면 추가된 RDM의 크기가 포함된 VMDK를 확인할 수 있습니다. 이는 그림 37의 예에서 볼 수 있듯이 vCenter에서 “친숙한” 시각적 표현입니다. 덮개 아래의 모습은 약간 다릅니다.

그림 37 - vCenter에서 본 RDM

덮개 아래를 살펴보면 실제 VMDK는 작은 파일(520바이트)입니다. RDM은 기본 LUN의 크기와 이름이 friendlyname-rdmp.vmdk 형식인 매핑 파일로 표시됩니다. 이는 그림 38에서 볼 수 있습니다.

그림 38 - 명령줄에 표시된 RDM과 연결된 파일

이 구성에 참여할 다른 VM에서 RDM 디스크를 추가하는 대신 아래 그림 39와 같이 “Existing Hard Disk"를 선택합니다.

그림 39 - 기존 RDM 디스크 추가하기

9 아래 그림 40과 같이 이전에 생성한 디스크로 이동하여 디스크를 선택합니다. 그런 다음 OK를 클릭합니다.

그림 40 - RDM 디스크 선택

디스크가 이전 단계와 동일하게 구성되었는지 확인합니다. 또한 가상 디바이스 노드가 올바른 PVSCSI 컨트롤러 ID로 설정되어 있는지 확인합니다. 그림 41에 예가 나와 있습니다.

그림 41 - 추가 노드에서 RDM 구성하기

확인을 클릭하여 이 노드에 RDM을 추가합니다.
FCI 구성에 참여할 다른 VM에 대해 8~11단계를 반복합니다.
완료되면 그림 42와 같이 모든 노드에서 디스크를 사용할 수 있으며 Windows Server에서 사용하도록 구성할 수 있습니다.

그림 42 - Windows Server에서 본 공유 RDM 지원 디스크

SQL Server에서 사용하기 위해 디스크를 포맷할 때는 64KB 할당 단위 크기를 사용하고 파일 시스템에는 NTFS를 사용하거나 SQL Server 2014 이상에서는 ReFS를 사용할 수도 있습니다.

참고: RDM을 사용 중이고 WSFC 노드 VM이 어떤 이유로 동일한 호스트(CIB)에 있는 경우 그림 43과 유사한 유효성 검사 오류가 표시됩니다.

중요: 중요한 클러스터링된 SQL Server 워크로드에는 클러스터 인 어 박스(“CIB”) 구성을 사용하지 않는 것이 좋습니다. 호스트를 사용할 수 없게 되면 클러스터된 모든 노드를 사용할 수 없게 되기 때문입니다. CIB는 진정한 “고가용성"을 제공하지 않습니다.

그림 43 - WSFC 유효성 검사 중 디스크 오류

겉으로 드러나지 않게 vSphere 5.5 이상에서는 기본 스토리지가 지원하는 한 공유 디스크를 사용하는 Path Selection Policy (PSP)인 Round Robing (PSP_RR)을 지원합니다. PSP는 호스트 수준에서 설정되며, 클러스터된 Windows Server VM을 실행하는 다른 PSP 설정이 있는 호스트는 지원되는 구성입니다.

SQL Server 데이터, 로그 및 백업에 SMB 3.0 파일 공유를 사용하는 경우 VMware는 Windows Server 2012 이상에서만 이를 지원합니다. 이는 Microsoft의 제한 사항이 아닙니다. 이 요구 사항은 데이터, 로그 또는 백업이 FCI 또는 SQL Server의 독립 실행형 인스턴스를 사용하여 저장되는 경우에 해당됩니다.

FCI 구성에서 “로컬” 디스크를 사용할 수 있는 위치는 OS 디스크, SQL Server의 임시 작업 공간인 TempDB, CIB 시나리오의 세 곳입니다.

각 노드의 OS 디스크는 동일한 데이터스토어에 배치해서는 안 되며, 가능한 경우 이러한 데이터스토어는 동일한 스토리지 유닛에 있어서는 안 됩니다. 데이터/로그/백업 RDM과 결합할 경우, 이러한 디스크는 기술적으로는 단일 장애 지점이지만 스토리지 계층에서 어느 정도 수준의 중복성을 확보하기 위해 OS 디스크와 분리되어야 합니다.

TempDB에 사용할 VMDK를 생성하려는 경우, 이것이 필요한지, 워크로드를 유지하기에 충분한 IOPS를 확보할 수 있는지 평가한 후에만 수행해야 합니다. 또한 vSphere HA 및/또는 vMotion에 영향을 미치고 SQL Server 배포의 일부로 로컬 디스크가 있을 수 있으므로 구성이 약간 복잡해지므로 이 백서의 뒷부분에서 다룰 예정입니다.

드라이브 문자, 드라이브 문자 + 탑재 지점 또는 CSV를 사용하는 경우 VMware는 Windows Server의 각 WSFC 노드에서 다음 레지스트리 키(HKEY_LOCAL_MACHINE > System > CurrentControlSet > Services > Disk) 값을 “60"으로 설정할 것을 권장합니다.

3.2.3 Always On Availability Groups

Availability Groups (AGs)는 복제본으로 구성되며 다음과 같은 제한 사항이 있습니다:

SQL Server 2019 이상에서 기본 복제본 1개 및 보조 복제본 8개(이 중 5개는 동기식일 수 있음)
SQL Server 2017의 경우 기본 복제본 1개 및 보조 복제본 8개(이 중 3개는 동기식일 수 있음)
SQL Server 2016 및 2014에서 기본 복제본 1개 및 보조 복제본 8개(이 중 2개는 동기화 가능)
SQL Server 2012에서 기본 복제본 1개 및 보조 복제본 4개

게스트 환경 내에서 보호 기능을 더욱 강화하기 위해 AG를 FCI와 결합할 수 있습니다. SQL Server를 설치할 때 구성하는 FCI와 달리, AG는 SQL Server 설치 후에 구성할 수 있습니다.

AG에는 다음과 같은 다른 데이터베이스 수준 기능에 비해 향상된 기능이 있습니다:

리스너는 FCI의 고유 이름과 마찬가지로 최종 사용자와 애플리케이션이 실행 중인 노드에 대해 걱정할 필요 없이 인스턴스에 액세스할 수 있도록 추상화를 제공합니다.
가용성뿐만 아니라 읽기 전용 활동, 백업 및 DBCC에도 사용할 수 있는 하나 이상의 보조 복제본(이러한 추가 용도는 라이선싱 및 SQL Server 에디션 선택에 영향을 미침)
동일한 기능으로 고가용성 및 기능적 재해 복구 모두 제공

AG는 로그 스트림을 통해 트랜잭션을 전송하여 보조 복제본을 동기화 상태로 유지합니다. 동기화는 동기식 또는 비동기식으로 이루어질 수 있으며, 이는 AG에 참여하는 VM 간의 네트워크가 강력하고 안정적이어야 함을 의미합니다. 경우에 따라 추가 vNIC(및 전용 물리적 네트워크/VLAN)에 매핑할 수 있는 추가 전용 네트워크가 필요할 수 있습니다. 이는 테스트를 통해 결정됩니다.

SQL Server 2012 및 2014에서 AG는 엔터프라이즈 에디션 기능입니다. SQL Server 2016 이상에서는 Microsoft에서 Standard Edition을 사용하여 AG(Basic Availability Group이라고도 함)를 만들 수 있지만 총 2개의 복제본으로 제한됩니다.

3.2.3.1. ADDS, DNS 및 AG

SQL Server 2012 및 2014에서는 모든 AG 구성과 함께 ADDS(Active Directory 도메인 서비스), DNS(도메인 이름 서비스)를 사용해야 합니다. 수신기가 구성된 경우 DNS의 항목과 함께 VCO가 필요합니다. AG에 적용되는 ADDS 및 DNS 요구 사항 및 고려 사항에 대한 자세한 내용은 섹션 3.2.1.1을 참조하십시오.

3.2.3.2. 가용성 그룹을 위한 스토리지 및 네트워킹

각 복제본에는 특정 AG에 참여하는 데이터베이스의 사본이 있습니다. 즉, 2TB의 데이터베이스가 있는 경우 2개의 복제본 구성에는 4TB의 공간이 필요합니다. FCI는 데이터의 복사본이 하나만 있지만 단일 장애 지점입니다.

AG에 참여하는 데이터베이스의 여러 복사본으로 인해 스토리지 사용량이 증가하지만, vSphere에서 AG를 사용할 때의 가장 큰 이점 중 하나는 FCI를 AG와 결합하지 않는 한 특별한 공유 스토리지 요구 사항이 없다는 것입니다. 즉, vSphere를 사용하는 경우 SQL Server 데이터 및 트랜잭션 로그 파일에 RDM을 사용해야 하는 이유(예: FCI와 AG를 결합하고 FCI 부분에 RDM을 사용하는 경우)가 없는 한 RDM 대신 표준 VMDK 및 VMFS 데이터스토어를 사용해야 합니다. 이렇게 하면 계획 및 구성이 간소화되고 AG가 vSphere에서 사용하기에 적합합니다.

SQL Server 데이터베이스 및 트랜잭션 로그 파일의 성능뿐만 아니라 가용성을 고려하여 VMDK를 어떻게 배치할지 계획해야 합니다. 모든 파일을 동일한 스토리지 유닛의 동일한 데이터스토어에 배치하면 단일 장애 지점이 될 수 있습니다.

VMDK를 사용하는 AG 구성에 대한 디스크 프레젠테이션 접근 방식의 예는 다음과 같습니다. 특정 VM에 대해 동일한 데이터스토어에 있을 수도 있고 없을 수도 있는 데이터 파일이 두 개 이상 있을 수 있지만, 이는 대안과 비교했을 때 허용되는 수준입니다.

vSphere 기반 Microsoft SQL Server의 스토리지를 최적으로 프로비저닝하는 방법에 대한 포괄적인 규정 지침은 Architecting Microsoft SQL Server on VMware vSphere의 “Storage Best Practices” 섹션을 참조하십시오. 한 가지 예가 그림 44에 나와 있습니다.

그림 44 - AG에 참여하는 VM에 대한 샘플 디스크 프레젠테이션

중복성 및 가용성 관점에서 6개의 데이터스토어가 논리적 분리를 통해 최소 2개의 서로 다른 스토리지 유닛에 분산되어 있다고 가정해 보겠습니다. 예를 들어, 서로 다른 두 개의 OS 데이터스토어가 서로 다른 기본 스토리지에 있고, 각각의 데이터 및 트랜잭션 로그도 서로 다른 스토리지에 있다고 가정해 보겠습니다. 가용성 그룹의 목표는 기본 스토리지가 FCI의 경우처럼 단일 장애 지점이 되지 않도록 하는 것입니다. 일부 사용자는 읽기 가능한 복제본 기능만 사용하도록 AG를 구성할 수 있으며, 이는 모든 복제본의 데이터를 동일한 스토리지 유닛에 저장하는 데 완벽하게 허용되는 사용 방식입니다. 이 경우 스토리지에 대한 vSAN 또는 vVols와 같은 기본 옵션의 사용 방식이 제한될 수도 있고 제한되지 않을 수도 있으므로 VM을 배포하기 전에 AG를 어떻게 사용할 계획인지 신중하게 고려해야 합니다,

스토리지 성능은 AG에 매우 중요합니다. 읽기/쓰기 복사본인 기본 복제본에 대해 걱정해야 할 뿐만 아니라 동기식 데이터 이동을 사용하는 경우 보조 복제본도 뒤처지지 않도록 더 좋지는 않더라도 비슷한 수준의 IOPS를 가져야 합니다. 보조 복제본이 읽기 전용 트래픽과 같은 다른 용도로 사용되는 경우, 해당 복제본에서 TempDB뿐만 아니라 AG에 참여하는 데이터베이스에 대한 추가 IOPS가 필요합니다. 이러한 복제본이 VMDK인 경우, eagerzeroedthick으로 구성해야 합니다.

위에 표시된 디스크 표현의 로직은 단순한 디스크, 데이터스토어 또는 LUN 중복성을 넘어서는 것입니다. 디스크를 여러 개의 데이터스토어, LUN 및 SCSI 컨트롤러로 분리하면 SQL Server 워크로드의 성능이 크게 향상됩니다. 이는 위의 샘플에서 연결된 디스크의 IO가 병렬화되어 각 디스크의 총 IO가 IO 경로를 따라 단일 장치를 포화시킬 가능성이 적고 따라서 해당 장치의 큐 깊이를 초과할 가능성이 낮기 때문입니다. 큐 깊이를 초과하면 IO 스로틀링이 발생하여 쿼리 및 트랜잭션 성능이 최적화되지 않습니다.