푸른 구름이 캐나다에 닥쳤습니다.

Azure Cloud에서 SQL Server 장애 조치 (Failover) 클러스터 인스턴스를 구축하려는 이유는 무엇입니까?

오늘 Twitterverse에서 흥미로운 토론이있었습니다. 기본적으로 "누군가 Azure에서 SQL Server 장애 조치 (Failover) 클러스터 인스턴스를 설정 했습니까?"라는 질문을 한 후 다음 대화에서 SQL Server 전문가를 존중했습니다. 그리고 "클라우드에서 SQL Server AlwaysOn 장애 조치 (Failover) 클러스터 인스턴스를 구축하려는 이유는 무엇입니까?"라는 질문이 생겼습니다.

이 질문은 두 가지 방식으로 해석 될 수 있습니다. "클라우드에서 고 가용성이 필요한 이유"또는 "장애 조치 (Failover) 클러스터 인스턴스 대신 AlwaysOn 가용성 그룹을 사용하지 않는 이유는 무엇입니까?"

한 번에 하나씩 각 질문에 대해 설명하겠습니다.

질문 1 – Azure Cloud에서 고 가용성을 사용해야하는 이유는 무엇입니까?

• Azure에서 SQL Server 인스턴스를 호스트하기 때문에 99.95 % 가동 시간의 SLA가 적용된다고 생각할 수도 있습니다. 네가 그렇게 생각하면 틀릴거야. 99.95 % SLA를 이용하려면 최소한 가용성 세트에서 실행중인 SQL 인스턴스를 두 개 가져야합니다. SQL을 하나의 인스턴스로 실행하면 유지 관리 기간 중에 다운 타임이 최소화 될 것으로 기대할 수 있습니다. 그러나 계획되지 않은 오류의 영향을 받기 쉽습니다.
• SQL Server의 두 인스턴스는 일반적으로로드 균형을 조정할 수 없습니다. 서버를 동기화 상태로 유지하기 위해 일종의 메커니즘을 구현해야합니다. 서버 중 하나에 문제가있는 경우 다른 서버는 요청을 계속 서비스 할 수 있습니다. AlwaysOn 가용성 그룹, AlwaysOn 장애 조치 클러스터 인스턴스 및 더 이상 사용되지 않는 데이터베이스 미러링과 같은 고 가용성 솔루션은이 시나리오에서 SQL Server에 대한 고 가용성을 제공 할 수 있습니다. 로그 전달 및 트랜잭션 복제와 같은 다른 솔루션은 서버간에 데이터를 동기화하는 데 도움을 줄 수 있습니다. 그러나 일반적으로 고 가용성 솔루션으로 간주되지 않으며 SQL Server의 가용성을 보장하지 않습니다.
• Microsoft는 Azure에서 전체 업그레이드 도메인 및 해당 업그레이드 도메인에서 실행중인 모든 인스턴스를 중단시킬 수있는 유지 관리 작업을 수행해야하는 경우가 있습니다. 언제 이런 일이 일어날 지에 대해서는 아무 말도하지 않습니다. 따라서 기본 SQL Server 인스턴스를 중단해야하는 경우 보조 SQL Server 인스턴스가 손실을 보지 않고 작업 부하를 처리 할 것으로 예상 할 수있는 메커니즘을 마련해야합니다. 위에 언급 된 모든 고 가용성 솔루션은 Microsoft가 주 서버의 업그레이드 도메인에서 유지 관리를 수행하는 경우에도 계속 실행할 수 있도록합니다. Microsoft는 한 번에 하나의 업그레이드 도메인에서만 유지 관리 작업을 수행합니다. 이렇게하면 보조 서버가 동일한 가용성 세트에 둘 다 있다고 가정 할 때 보조 서버가 여전히 온라인 상태로 유지됩니다.
• 프로덕션 SQL Server에서 성능 유지 관리를 원할 경우 어떻게합니까? 어쩌면 서비스 팩이나 다른 핫픽스를 설치하고 싶습니까? 장애 조치를 수행 할 보조 서버가 없으면 계획된 중단 시간을 예약해야합니다. 고 가용성 솔루션의 주요 이점 중 하나는 롤링 업그레이드를 수행하여 계획된 중단 시간의 영향을 최소화하는 것입니다.

질문 2 – 왜 장애 조치 (Failover) 클러스터 인스턴스 대신 AlwaysOn 가용성 그룹을 사용하지 않습니까?

• 돈 절약! SQL Server AlwaysOn 가용성 그룹을 사용하려면 Enterprise Edition의 SQL Server가 필요합니다. 왜 돈을 절약하고 SQL Server Standard Edition을 배포하고 간단한 2- 노드 장애 조치 (Failover) 클러스터 인스턴스를 구축해야합니까? 다른 이유로 Enterprise Edition이 필요한 경우가 아니라면 이는 당연한 생각입니다.
• 전체 SQL Server 인스턴스를 보호하십시오. AlwaysOn 가용성 그룹은 사용자 정의 데이터베이스 만 보호합니다. 시스템 및 MSDB 데이터베이스를 보호 할 수 없습니다. SQL Server 장애 조치 (Failover) 클러스터 인스턴스를 대신 구축하면 시스템 및 MSDB 데이터베이스를 포함하여 전체 인스턴스가 보호됩니다.
• 관리를 용이하게하십시오. Azure에서는 클라이언트 청취자에게만 제한됩니다. 이렇게하면 하나의 가용성 그룹으로 제한됩니다. 반대로 장애 조치 (Failover) 클러스터 인스턴스를 사용하면 클라이언트 수신기 하나만 있으면되므로 제한이 없습니다.
• 작업자 스레드 고갈. AlwaysOn AG에서는 사용 가능한 작업자 스레드를 주시해야합니다. 사용 가능한 작업자 스레드는 AlwaysOn AG로 보호 할 수있는 데이터베이스 수를 제한합니다. 반면, DataKeeper 블록 수준 복제를 사용하는 AlwaysOn 장애 조치 (Failover) 클러스터링은 추가하는 각 데이터베이스에 대해 더 많은 리소스를 사용하지 않습니다. 즉, AlwaysOn AG와 관련된 추가 오버 헤드없이 수백 개의 데이터베이스를 보호하도록 확장 할 수 있습니다.
• 분산 트랜잭션 지원. AlwaysOn AG는 분산 트랜잭션 (DTC)을 지원하지 않습니다. 응용 프로그램에 DTC 지원이 필요한 경우에는 AlwaysOn 장애 조치 (failover) 클러스터 인스턴스를 대신 사용해야합니다.
• 기타 복제 기술 지원. AlwaysOn AG가 보호하는 두 데이터베이스간에 피어 투 피어 (Peer to Peer) 복제를 설정하려는 경우 잊어 버릴 수 있습니다. 실제로 AlwaysOn 가용성 그룹을 배포하면 여러 가지 제한 사항에 유의해야합니다. AlwaysOn FCI에는 그러한 제한이 없습니다.

결론

위에서 알 수 있듯이 AlwaysOn 장애 조치 클러스터 인스턴스를 구축 할 때 훨씬 강력하고 저렴한 솔루션을 제공 할 수있을 때 클라우드에 AlwaysOn AG를 구현하려는 이유는 무엇입니까?

Azure에서 AlwaysOn 장애 조치 (Failover) 클러스터 인스턴스를 만드는 데 관심이 있다면 내 블로그 게시물을 단계별로 확인하십시오 : Microsoft Azure IaaS에서 SQL Server 장애 조치 (failover) 클러스터 인스턴스 (FCI)를 구성하는 방법 #SQLServer #Azure #SANLESS

https://clusteringformeremortals.com/2015/03/05/why-would-you-want-to-build-a-sqlserver-failover-cluster-instance-in-the-azure-cloud/에서 허락을 받아 재현했습니다.