새로운 Azure ILB 기능으로 Azure에서 다중 인스턴스 SQL Server 장애 조치 (Failover) 클러스터 구축 가능

새로운 기능인 Cloud Witness는 현재 내가 가장 좋아하는 기능입니다. Windows Server 2016의 새로운 쿼럼 기능을 살펴보기 전에 우리가 어디서 왔는지를 아는 것이 중요하다고 생각합니다. 이전 글에서는 Windows Server 2012 R2의 Windows Server 장애 조치 (Failover) 클러스터 쿼럼 (Understanding the Windows Server Failover Cluster Quorum)에 대해 클러스터 쿼럼의 내역과 발전에 대해 자세히 설명했습니다. 이 게시물을 검토하여 Windows Server 2012 R2에서 쿼럼이 어떻게 작동하는지 이해하는 것이 좋습니다. 또한 Windows Server 2016의 새로운 기능으로 인해 클러스터 배포가 더욱 탄력을받을 것입니다.

구름 증인

Cloud Witness를 사용하면 Azure Blob 저장소를 활용하여 클러스터의 미러링 모니터 역할을 할 수 있습니다. 이 증인은 디스크 증인이나 파일 공유 증인이 될 것입니다. Cloud Witness의 구성은 매우 쉽습니다. 내 경험에 비추어 볼 때 Azure에서 호스트해야 할 것이 없습니다. 유일한 단점은 클러스터 노드가 Azure BLOB 저장소와 인터넷을 통해 통신 할 수 있어야한다는 것입니다. 매우 자주 클러스터 노드는 공용 인터넷에 통신 할 수 없습니다. 따라서 Cloud Witness를 사용하려면 보안 팀과상의해야합니다. Cloud Witness를 사용하여 Azure에서 다중 인스턴스 SQL Server 장애 조치 (Failover) 클러스터를 구축해야하는 많은 이유가 있습니다. 하지만 필자는 저에게 Azure의 장애 조치 클러스터, 지점 클러스터 및 다중 사이트 클러스터의 세 가지 매우 특정한 환경에서 가장 잘 이해하고 있습니다.

가까이에서

Cloud Witness가 어떻게 도움이되는지 알아 보려면 각 시나리오를 살펴 보겠습니다. 그림 1 – 다중 인스턴스 SQL Server 장애 조치 (Failover) 클러스터를 Azure에서 빌드하려고 할 때 클라우드 감시 서버 저장소는 항상 구성되어야합니다. 로컬 중복 저장소 (Local Advisory Storage) (LRS) [/ caption]

고 가용성 배포

Azure (또는 정말로 클라우드 제공자)로 이동하는 경우, 배치의 가용성을 높이고 싶을 것입니다. Windows Server 장애 조치 (Failover) 클러스터링으로 전통적으로 클러스터링 된 SQL Server, 파일 서버, SAP 또는 다른 작업 부하를 처리하는 경우 Azure에서 디스크 감시가 불가능하므로 파일 공유 감시 또는 클라우드 감시를 사용해야합니다. Windows Server 2012 R2 또는 Windows Server 2008 R2에서는 파일 공유 감시 기능을 사용해야합니다. Windows Server 2016을 사용하면 Cloud Witness를 사용할 수 있습니다. Cloud Witness의 이점은 파일 공유를 호스팅하기 위해 Azure에서 다른 Windows 인스턴스를 유지 관리 할 필요가 없다는 것입니다. 대신 Blob 저장소를 활용할 수 있습니다.  이렇게하면 관리하기가 훨씬 쉽고 탄력적 인 솔루션을 얻을 수 있습니다.

위치

지사의 클러스터 구축을 고려할 때 비용 및 유지 관리가 항상 고려됩니다. 수백 또는 수천 개의 위치가있는 소매 체인의 경우 각 위치에 SAN을 설치하는 것은 비용이 많이들 수 있습니다. 각 위치에서 다수의 가상 시스템을 호스트하기 위해 S2D Hyper-converged 구성 또는 타사 ^복제 솔루션에서 2 노드 Hyper-V 클러스터를 실행할 수 있습니다. 이제 Cloud Witness가 할 수있는 일은 각 위치에 추가 물리적 서버를 추가하는 비용을 피하여 파일 공유 감시 또는 각 위치에 SAN을 추가하는 데 드는 비용을 피할 수 있도록 지원하는 것입니다.

세 번째 데이터 센터에 대^한 필요성 제거

마지막으로 다중 사이트 클러스터를 배포 할 때 Cloud Witness는 File Share Witness를 호스팅 할 세 번째 데이터 센터가 필요하지 않습니다. Cloud Witness가 도입되기 전에 File Share Witness가 3 번째 위치에 있어야한다고 명시하는 것이 ^가장 좋습니다. 파일 공유 감^시를 호스팅하기위한 제 3의 데이터 센터에 대한 액세스는 항상 실현 가능할뿐만 아니라 또 다른 복잡성의 층을 가져 왔습니다. Cloud Witness를 사용하면 세 번째 위치를 유지할 ^필요가없고 감시 네트워크에 대한 액세스가 공용 인터넷을 통해 이루어 지므로 네트워크 요구 사항도 최소화됩니다.

사이트 인식

다중 사이트 클러스터를 구축 할 때 또 다른 공통된 문제가있었습니다. 로컬 사이트를 항상 선호하도록 장애 조치를 제어하는 ​​것은 불가능했습니다. 기본 소유자를 지정할 수는 있지만 기본 설정 소유자는 일반적으로 잘못 이해합니다. 관리자는이를 인식하지 못할 수도 있습니다. 그러나 기본 소유자로 서버를 나열하지 않더라도 서버는 클러스터에서 유지 관리하는 기본 소유자 목록의 끝에 자동으로 추가됩니다. 이 오해의 결과는 로컬 서버를 기본 소유자로 나열했을지라도 잠재적으로 DR 사이트에 대한 클러스터 리소스 페일 오버를 가질 수 있다는 것입니다. 그리고 이것은 로컬 사이트에서 사용할 수있는 완벽한 노드가있는 경우에도 마찬가지입니다. 분명히 이것은 당신이 기대하는 것이 아니며 사이트 인식을 사용하면 앞으로이 문제를 제거 할 수 있습니다. 사이트 인식은 온라인 상태로 전환 할 노드를 결정할 때 항상 로컬 사이트를 선호하므로이 문제를 해결합니다. 따라서 정상적인 상황에서 클러스터 된 작업 부하는 완전한 사이트 중단이 발생하지 않는 한 항상 로컬 노드로 장애 조치됩니다. 이 경우 DR 노드 중 하나가 온라인 상태가됩니다. DR 사이트에서 실행되면 동일하게 적용됩니다. 클러스터는 DR 사이트의 노드에서 이전에 실행 중이었던 DR 사이트의 서버에서 작업 부하를 복구합니다. 사이트 인식은 항상 로컬 노드를 선호합니다.

오류 도메인

사이트 인지도를 구축하는 것은 결함 도메인입니다. 오류 도메인 (Fault Domains)은 한 걸음 더 나아가 사이트 (Site) 외에도 노드, 섀시 및 랙 위치를 정의 할 수있게합니다. 오류 도메인에는 3 가지 장점이 있습니다. 스트레치 클러스터의 스토리지 선호도는 스토리지 공간 복원력을 높입니다. 경보를 발생시키는 관련 자원의 위치에 대한 메타 데이터를 포함하여 Health Services 경보를 향상시킵니다. Storage Affinity는 클러스터 작업 부하와 스토리지가 동일한 위치에서 실행되도록합니다. 확실히 당신의 VM이 다른 도시의 CSV에 앉아 데이터를 읽고 쓰는 것을 원하지 않을 것입니다. 그러나 여기서 가장 큰 승자는 S2D (Storage Spaces Directive) 시나리오입니다. SD2는 클러스터 노드 위치 (사이트, 랙, 섀시)에 대해 제공 한 정보를 활용하여 중복성을 위해 작성된 여러 데이터 복사본이 서로 다른 오류 도메인에 있는지 확인합니다. 이를 통해 단일 Node, Chassis, Rack 또는 Site의 장애로 인해 전체 S2D 배치가 중단되지 않도록 데이터 배치를 최적화 할 수 있습니다.  코스모스 다윈 (Cosmos Darwin)은이 개념을 아주 자세하게 설명하는 채널 9에 관한 훌륭한 비디오를 가지고 있습니다.

개요

Windows Server 2016은 클러스터 배포에 몇 가지 즉각적인 이점을 제공하는 몇 가지 새로운 기능을 클러스터 쿼럼에 추가합니다. 또한 롤링 시스템 업그레이드, 가상 컴퓨터 복원력, 작업 그룹 및 다중 도메인 클러스터 및 기타 여러 가지 새로운 클러스터 향상된 기능을 확인하십시오. 새로운 Multi-Instance SQL Server 장애 조치 클러스터 구축과 같은 다른 팁을 읽으려면 Cloud Witness가있는 Azure에서 게시물을 읽으십시오. Clusteringformeremortals.com의 허락을 받아 재현