Date: 11월 7, 2018
어떻게 된 거예요? 여기 Azure Outage Post Mortem Part 2가 있습니다.
어떻게 된 거예요? 여기 Azure Outage Post Mortem Part 2가 있습니다.
저의 이전 블로그 게시물에 따르면 Cloud-to-Cloud 또는 Hybrid-Cloud는 CSP가 만날 수있는 모든 문제에 대해 가장 고립되어 있다고 말합니다. 그러나 South Central 지역에서 가용 구역을 사용할 수 있다면이 자연 재해로 인한 가동 중지 시간의 대부분을 피할 수있었습니다. Microsoft는 9 월 4 일 South Central Outage의 예비 RCA를 발표했습니다. 전체 요약에서 가장 중요한 부분은 다음과 같습니다.
“온 사이트 리던던시를 없애고, 데이 터 센터 냉각 실패가 영향을받은 데이터 센터의 고객 워크로드에 영향을 미칠 수있는 시나리오가 있습니다.”
당신에게 무슨 의미입니까?
응용 프로그램이 모두 동일한 데이터 센터에서 실행되는 경우 향후 동일한 유형의 중단이 발생할 수 있습니다. 마이크로 소프트의 주장에 의하면, 이것은 정말로 당신에게 뉴스가되어서는 안된다. Azure, AWS, Google 또는 자신의 데이터 센터에서 실행하든 관계없이 항상 사실입니다. 다른 데이터 센터로 데이터 복제를 미리 계획하지 못하고 신속하게 애플리케이션을 복구 할 수있는 계획을 세우는 것만으로도 계획을 세울 수 없습니다. Microsoft는 정확한 가용성 영역 위치를 게시하지 않았습니다. 이지도가 여기에 게시되었다고 믿는다면, 아마 2 ~ 10 마일 떨어진 곳에서 찾을 수 있습니다. 가장 극단적 인 경우를 제외하고 가용성 영역에서 데이터를 복제하면 데이터 보호에 충분해야합니다. SQL Server와 같은 일부 응용 프로그램에는 복제 기술이 내장되어 있습니다. 그러나 광범위한 응용 프로그램, 운영 체제 및 데이터 유형의 경우 블록 레벨 복제 SANless 클러스터 솔루션을 조사하십시오. SANless 클러스터 솔루션은 전통적으로 멀티 사이트 클러스터에 사용되었습니다. 그러나 동일한 기술을 가용성 영역 및 재해 복구를 위해 가용성 영역, 지역 또는 하이브리드 클라우드에서 클라우드에서도 사용할 수 있습니다. Azure, AWS 또는 Google과 같은 가용 영역을 망라하는 SANless 클러스터를 구현하는 데는 적절한 도구가 제공되는 매우 간단한 프로세스입니다. 하늘색 정전 사후의 일환으로, 여기 당신을 시작할 수 있도록 도와주는 몇 가지 자료가 있습니다. 단계별 : 가용성 영역에 걸친 Azure에서 파일 서버 클러스터 구성 Google Cloud Platform에서 SANless SQL Server 장애 조치 (Failover) 클러스터 인스턴스를 구축하는 방법 MS SQL Server 복제 및 고 가용성을 갖춘 Linux의 v.Next #Azure #Cloud #Linux #Azure Resource Manager (ARM)에서 Microsoft SQL Server 2014 장애 조치 (failover) 클러스터 배포 AWS의 SANless SQL Server 클러스터 AWS의 SANless Linux 클러스터 빠른 시작
푸른 기운 사후 모템에 대한 교훈
Azure에있는 경우 ASR (Azure Site Recovery)을 고려할 수도 있습니다. ASR을 사용하면 하나의 Azure 영역에서 다른 영역으로 전체 VM을 복제 할 수 있습니다. ASR은 실시간으로 VM을 복제하고 언제든지 무중단 DR 테스트를 수행 할 수 있습니다. 대부분의 Windows 및 Linux 버전을 지원하며 설정하기가 비교적 쉽습니다. “다중 VM 일관성”이있는 복제 작업을 만들 수도 있습니다. 이는 서버가 정확히 동일한 시점에서 복구되어야 함을이 일관성 그룹에 결합 할 수 있고 동일한 복구 지점을 갖게됨을 의미합니다. 기본적으로 고 가용성을 위해 단일 영역에 DataKeeper가 포함 된 SANless 클러스터를 구축하는 경우 DR에 대해 두 가지 옵션이 있습니다. 하나는 SANless 클러스터를 다른 지역의 노드로 확장 할 수 있거나 ASR을 사용하여 일관성 그룹의 두 노드를 복제 할 수 있다는 것입니다.
차이점이 뭐야?
ASR과의 트레이드 오프 (trade off)는 RPO와 RTO가 SANless 다중 사이트 클러스터와 같이 좋지 않다는 것입니다. 구성하기 쉽고 모든 응용 프로그램에서 작동합니다. 조심해. 응용 프로그램이 정기적으로 디스크 쓰기 작업에서 10 MBps를 초과하면 ASR은 계속 유지할 수 없습니다. 또한 Storage Spaces Direct를 기반으로하는 클러스터는 ASR로 복제 할 수 없으며 일반적으로 Azure에서 사용할 때 좋은 DR 전략이 부족합니다. Managed Disks가 출시 된 후 얼마 지나지 않아 ASR은 약 1 년 후까지이를 완벽하게 지원하지 못했습니다. Managed Disks에 대한 완벽한 지원은 ASR을 사용하려는 많은 사람들에게 커다란 장애물이었습니다. 다행히도 2018 년 2 월 이후 ASR은 Managed Disks를 완벽하게 지원합니다. 그러나 방금 도입 된 또 다른 문제가 있습니다. 가용성 영역 (Availability Zones)이 도입되면서 ASR은 다시 한번 시대에 뒤처집니다. 현재는 가용 영역에 배포 된 VM을 지원하지 않습니다.
어쨌든 나는 그것을 시도했다. 복제를 구성하는 것이 가능 해졌고 테스트 장애 조치를 수행 할 수있었습니다.
Crackeringformeremortals.com의 허락을 받아 재현 된 Azure Outage Post Mortem에 대한 내 분석에 대해 자세히 읽어보십시오.