각 클러스터 노드에는 동일한 스토리지가 필요합니다. 각 서버에서 장애 조치 클러스터링 및 .Net 3.5 프레임 워크 사용
도메인에 서버 추가
기본 클러스터를 만들지 만 POWERSHELL을 사용하고 클러스터 IP 주소를 지정하십시오. GUI를 사용하여 클러스터를 작성하면 혼동을 일으키고 중복 IP 주소를 제공합니다. GUI를 통해 연결하면 노드 중 하나에서 클러스터에 연결할 수 있습니다. 연결하는 경우 클러스터 리소스에서 사용할 정적 IP 주소를 지정하여 문제를 해결할 수 있습니다. 다음은 클러스터를 생성하는 Powershell 사용법의 예입니다
새 클러스터 -Name cluster1 -Node sql1, sql2 -StaticAddress 10.0.0.101 -NoStorage-
파일 공유 감시자를 클러스터에 추가
두 클러스터 노드에 DataKeeper 설치
DataKeeper 볼륨 리소스를 만들고 사용 가능한 저장소인지 확인하십시오.
공유 저장소 클러스터에서 일반적으로하는 것처럼 SQL을 클러스터에 설치하십시오.
Azure ILB를 구성하고 powershell 스크립트를 실행하여 Probe 포트에서 수신 대기하도록 SQL 클러스터 IP 리소스를 업데이트합니다.
SIOS DataKeeper로 SANless SQL Server 클러스터를 구축하고 있습니다. 또는 SQL Server의 가용성 그룹에 대해 항상 구성 중입니다. 성능을 위해 Simple Storage Space (RAID 0)에 여러 개의 디스크를 함께 떼어내는 것은 어떻습니까? 이는 일반적으로 각 인스턴스가 일반적으로 하드웨어 탄력성에 의해 뒷받침되는 클라우드에서 이루어 지므로 RAID 0은 그다지 위험하지 않습니다. 예를 들어 AWS의 고객 중 IOPS를 최대 80,000 (현재 단일 인스턴스에서 사용할 수있는 최대 IOPS)까지 늘리고 싶습니다. 이제 가장 큰 EBS 최적화 인스턴스 크기 만이 80,000 IOPS를 지원합니다. 따라서 특정 인스턴스 크기가 지원하는 최대 IOPS를 확인하십시오. 이 경우 우리는 80,000 IOPS를 지원하는 ac5.18xlarge 인스턴스를 가졌습니다. 그러나 개별 EBS 프로비저닝 IOPS 볼륨은 최대 32,000 IOPS까지만 지원합니다. 단일 볼륨에 쓸 때 80,000 IOPS를 얻는 유일한 방법은이 볼륨 중 3 개를 Simple Storage Space에서 제거하는 것입니다. 여기에 문지름이있다. Strip Together Multiple Disk를 기존 클러스터의 단순한 저장 공간에 넣으려고하면, 일이 꽤 빨라질 것입니다. 동료 MVP 인 Joey D' Antoni는 최근이 문제에 관해 블로그를 보냈습니다. 여전히 Windows Server 20109 미리보기에서 문제가되는 것으로 보입니다. Joey가 말했듯이 클러스터링 프로세스를 시작하기 전에 항상 고객에게 노드와 스토리지 공간을 구축 할 것을 권고합니다. 이렇게하면 단순 저장 공간에서 여러 디스크를 함께 제거하는 프로세스가 훨씬 원활 해집니다. 또한 고객은 복제를 추가하기 전에 서버 성능을 벤치마킹 할 수있는 시간을 가질 수 있습니다. 또한 모든 것이 예상대로 작동하는지 확인합니다. 스트립 함께 사용하는 방법과 같은 더 빠른 팁을 알고 싶다면 간단한 스토리지 공간에서 여러 디스크를 클러스터링하는 방법에 대한 다른 게시물을 확인하십시오. Clusteringformeremortals.com의 허가를 받아 복제했습니다.
어제 새벽 트위터 피드를 열어 Azure Cloud 정전으로 많은 사람들이 영향을 받았다는 사실을 알게되었습니다. 정전에 관한 거의 모든 리소스 페이지를 사용할 수 없었습니다. 다행히 @AzureSupport는 Twitter를 통해 업데이트를 계속 제공했습니다. @AzureSupport의 원본 업데이트는 오전 7:12 (동부 표준시)에 제공되었습니다. 트위터 피드를 다시 살펴보면 처음에는 문제가 처음 1 시간에서 2 시간 전에 시작된 것처럼 보입니다. 원래 중단 된 미국 중부 지역보다 정전 사태가 더 큰 영향을 미쳤다는 것이 빠르게 나타났습니다. Azure Active Directory에 의존하는 서비스가 영향을받을 수 있고 새로운 구독을 제공하려는 고객에게 문제가있는 것처럼 보입니다. 그리고 24 시간 후에 문제는 완전히 해결되지 않았고 오늘 아침 마지막 업데이트에 따르면 … 그래서이 푸른 구름의 영향을 최소화하기 위해 할 수 있었습니까? 아무도 번개 같은 자연 재해로 Microsoft를 비난 할 수는 없습니다. 그러나 문제가 해결 될 때까지 유일한 재해 복구 계획이 Microsoft에 전화를 걸고 Microsoft에 전자 메일을 보내면 하루가 끝나면 방금 무례한 각성을 받게됩니다. 재해 복구 계획과 관련하여 모든 기반을 보장하는 것은 사용자의 몫입니다.
몇몇 대안을 탐구 할 시간?
먼지가 영향을받은 부분과 고객이 중단 시간을 최소화하기 위해 할 수 있었던 부분에 여전히 정착하는 동안, 여기에 나의 초기 생각이 있습니다.
가용성 세트 (오류 도메인 / 도메인 업데이트)
이 시나리오에서 페일 오버 클러스터를 구축했거나 Azure로드 밸런서 및 가용성 세트를 사용하더라도 전체 지역이 오프라인이 된 이후로 여전히 운이 없었을 것입니다. 특히 계획된 중단 시간에 가용성 세트를 활용하는 것이 좋습니다.이 경우에도 여전히 오프라인 상태 였을 것입니다.
가용 영역
아직 미국 중남부에서는 사용할 수 없습니다. 그러나 Azure에서 가동 가능한 가용 영역의 개념이 가동 중단의 영향을 최소화 할 수 있었던 것 같습니다. 번개가 하나의 데이터 센터에만 영향을 준다고 가정하면 다른 가용 영역의 다른 데이터 센터는 계속 작동해야합니다. 그러나 Azure Active Directory (AAD)와 같은 다른 비 지역 서비스의 중단은 여러 지역에 영향을 미쳤습니다. 가용 영역이 당신을 완전히 고립 시켰을 것이라고 생각하지 않습니다.
글로벌로드 밸런서, 교차 영역 페일 오버 클러스터 등
지역을 가로 지르는 SANLess 클러스터를 구축하든 글로벌로드 밸런서를 사용하여 여러 지역에 걸쳐로드를 분산하든 관계없이 South Central US에서의 정전 영향을 최소화 할 수 있습니다. 그러나 당신은 여전히 AAD 정전에 취약 할 수 있습니다.
하이브리드 클라우드, 크로스 클라우드
클라우드 전반의 장애 시나리오에서 탄력성을 보장하려면 주요 클라우드 제공 업체 외부의 대상에 실시간으로 데이터를 복제하고이 다른 위치에서 신속하게 응용 프로그램을 온라인으로 가져올 수있는 계획을 포함하는 DR 계획을 세우는 것이 좋습니다. 이 두 위치는 완전히 독립적이어야합니다. AAD와 같은 기본 위치에서 사용할 수있는 서비스에 의존해서는 안됩니다. DR 위치는 다른 클라우드 제공 업체가 될 수 있습니다. 이 경우 AWS 또는 Google Cloud Platform은 논리적 인 대안처럼 보일 수도 있고 자체 데이터 센터 일 수도 있습니다. 그러나 이런 종류의 일은 처음부터 클라우드에서 실행되는 목적을 무효화시킵니다.
서비스로서의 소프트웨어
Azure Active Directory (ADD), Azure SQL 데이터베이스 (Database-as-Service) 또는 클라우드 제공자의 많은 SaaS 오퍼링 중 하나와 같은 서비스로서의 소프트웨어는 유혹적으로 보일 수 있지만 최악의 시나리오를 계획해야합니다 . 비즈니스 크리티컬 한 애플리케이션을 단일 벤더에 맡기고 있기 때문에 컨트롤이 거의 없을 수도 있습니다. 현재 클라우드 서비스 공급자 외부의 복구를 포함하는 DR 옵션이라는 점을 기억하십시오. SaaS 서비스를 구현하기 전에 DR 옵션을 조사하는 것 외에 다른 말로는 나을 수 없습니다. 클라우드 외부의 복구가 옵션이 아닌 경우 해당 서비스에 가입하기 전에 오래 동안 열심히 생각하십시오. 비즈니스 관계자에게 클라우드 서비스가 오프라인 인 경우 전화 이외에는 아무 것도 할 수 없으며 불평 할 수 있음을 알립니다.
미래 동향
아주 가까운 장래에 크로스 클라우드 가용성에 대해 더 많은 것을 듣게 될 것입니다. 또한 사람들이 SIOS DataKeeper와 같은 솔루션을 활용하여 클라우드 공급자를 교차하는 강력한 HA 및 DR 전략을 구축하는 방법에 대해서도 설명합니다. 진정한 교차 클라우드 또는 하이브리드 클라우드 모델은 생각할 수있는 대부분의 클라우드 중단으로부터 진정으로 자신을 보호 할 수있는 유일한 방법입니다. 이 최근 정전으로 인해 영향을받은 경우 귀하의 의견을 듣고 싶습니다. 무엇이 내려 갔는지, 얼마나 오래 있었는지, 그리고 당신이 회복하기 위해 한 일을 말해주십시오. 미래에 당신의 경험이 나아질 수 있도록하기 위해 무엇을 할 계획입니까? Azure 클라우드 정전을 극복하는 방법과 같은 기사를 더 읽으십시오. Clusteringformeremortals.com의 허락을 받아 재현
SQL Server를 사용하는 가용성 그룹에서 두뇌를 분리하지 마십시오.이 지원 기사가있는 Linux에서 Microsoft가 게시했습니다. Linux에서 SQL Server를 실행하면 Azure에서 실행되는 경우 OS의 비용 절감을 포함하여 몇 가지 이점이 있습니다. 약간의 계산을하십시오. 코어 수가 증가하면 비용 절감 효과가 상당합니다. 또한 모든 클러스터 쌍에 적어도 두 개의 서버에 대한 라이센스를 부여합니다. 그러나 기술이 견고하지 않다면 왜 돈을 저축해야합니까? Linux에서 SQL Server를 실행하면서 볼 수있는 가장 큰 문제점 중 하나는 응집력있는 HA / DR 스토리가 없다는 것입니다. Windows에서 Microsoft는 전체 HA 스택을 소유하고 있으며 SQL Server는 Windows Server 장애 조치 (Failover) 클러스터링에 크게 의존하여 가용성 그룹과 장애 조치 (Failover) 클러스터 인스턴스를 모두 지원합니다. 이것은 오랫동안 잘 운영되어 왔으며 성공 사례에 대한 오랜 경험이 있습니다. Linux로 이동할 때 Microsoft는 더 이상 OS 수준에서 HA 스택을 소유하지 않습니다. Linux의 배포판에 따라 Pacemaker와 같은 오픈 소스 솔루션을 하나로 모으기 위해 노력하고 있습니다. SQL Server 가용성 그룹과 협력하기 위해 노력하는 것은 물론입니다. SQL Server를 사용하여 가용성 그룹을 분할하지 않으려면 Linux에서는 SPS-L (Linux 용 SIOS Protection Suite)과 같은 타사 고 가용성 솔루션을 고려해야합니다. Linux에서 실행되는 비즈니스 크리티컬 애플리케이션을위한 검증 된 HA 솔루션을 제공합니다.
SPS-L은 1999 년부터 Linux에서 실행되는 업무상 중요한 응용 프로그램을 보호 해 왔습니다. 이는 모니터링하는 전체 HA / DR 솔루션입니다. 물리적 인 서버 및 네트워크뿐 아니라 전체 응용 프로그램 스택을 복구하여 업무상 중요한 응용 프로그램의 가용성을 높입니다. 이 모든 것은 원격 데이터 센터 또는 클라우드의 다른 지리적 영역에서 재해 복구 용으로 3 부 복사본을 유지하는 동안 수행됩니다. SPS-L의 또 다른 이점은 SQL Server의 Enterprise Edition이 필요하지 않으므로 SQL Server 라이센스에도 상당한 비용 절감 이점이있을 수 있다는 것입니다. SQL Server Standard Edition의 코어 당 $ 1859와 SQL Server Enterprise Edition의 코어 당 $ 7128을 고려하십시오. 라이센스를 취득해야하는 코어 수에 따라 비용 절감 이점이 상당 할 수 있습니다. 아래는 Azure Cloud에서 Linux로 실행되는 SQL Server를 보호하는 SPS-L의 비디오 데모입니다. 이 데모에서는 SQL Server Standard Edition 클러스터가 다른 Azure 오류 도메인의 노드와 예기치 않은 오류에 대응하는 SPS-L 사이에서 수동으로 장애 조치되는 것을 보여줍니다. 가용성 문제에 대한 다른 팁을 배우고 싶습니다. 가용성 그룹에 SQL Server 사용 Linux에서 블로그에 대한 정보 ClusteringForMereMortals.com으로 복제
Windows Server 2003의 장애 조치 (Failover) 클러스터 쿼럼에 대한 파일 공유 감시에 관해 몇 가지 새로운 기능이 추가 될 예정입니다. 고객이 오랫동안 요구해온 기능입니다. USB 썸 드라이브에서 파일 공유를 목격했습니다! 많은 사람들이 각 매장 위치, 지사 등에 간단한 2- 노드 클러스터를 배포하려고했습니다. 그들은 SAN의 추가 비용이 Disk Witness를 활용하기를 원치 않았으며 Azure의 Cloud Witness에 의존 할 수있는 연결성을 갖고 있지 않았습니다. 결과적으로 클러스터링을하지 않습니다. 또는 SIOS Protection Suite와 같은 대체 클러스터링 솔루션을 사용했습니다. 이제는 Windows Server 2019에서 제공되는 USB Thumb 드라이브에서 파일 공유 감시 기능을 사용할 수 있습니다. 지원되는 라우터를 활용하면 라우터에 삽입 된 USB 디스크를 미러링 모니터 서버로 사용할 수있는 파일 공유로 구성 할 수 있습니다. 따라서 세 번째 서버 또는 인터넷 연결이 필요 없습니다.
상상할 수있는 몇 가지 시나리오가 있습니다. Hyper-V 용 HCI에서 DataKeeper를 사용하는 간단한 파일 서버 클러스터로. 시나리오에 관계없이 작업 그룹 클러스터를 만들 계획이 아니라면 각 서버에서 VM을 실행하여 중복 도메인 컨트롤러로 작동하는 것이 좋습니다. 또는 주 데이터 센터에서 호스팅되는 도메인 컨트롤러로 WAN 연결을 신뢰할 수 있습니다.
USB 썸 드라이브에서 파일 공유 감시를 구성하는 것과 같은 팁과 트릭을 보려면 여기를 읽어보십시오. ClusteringForMereMortals.com의 허락을 받아 재현
)에 제공되었습니다. 트위터 피드를 다시 살펴보면 처음에는 문제가 처음 1 시간에서 2 시간 전에 시작된 것처럼 보입니다. 
원래 중단 된 미국 중부 지역보다 정전 사태가 더 큰 영향을 미쳤다는 것이 빠르게 나타났습니다. Azure Active Directory에 의존하는 서비스가 영향을받을 수 있고 새로운 구독을 제공하려는 고객에게 문제가있는 것처럼 보입니다. 
그리고 24 시간 후에 문제는 완전히 해결되지 않았고 오늘 아침 마지막 업데이트에 따르면 … 
그
래서이 푸른 구름의 영향을 최소화하기 위해 할 수 있었습니까? 아무도 번개 같은 자연 재해로 Microsoft를 비난 할 수는 없습니다. 그러나 문제가 해결 될 때까지 유일한 재해 복구 계획이 Microsoft에 전화를 걸고 Microsoft에 전자 메일을 보내면 하루가 끝나면 방금 무례한 각성을 받게됩니다. 재해 복구 계획과 관련하여 모든 기반을 보장하는 것은 사용자의 몫입니다.
