마침내 Azure Outage Mortem Part 3 결론
나의 이전 블로그 포스트 인 Azure Outage Post-Mortem – Part 1과 Azure Outage Post-Mortem Part 2는 블로그 게시물과 트위터에서 나오는 제한된 정보를 바탕으로 몇 가지 가정을했습니다. 방금 Ignite에서 실제로 어떤 일이 일어 났는지 좀 더 명확하게 설명하는 세션에 참석했습니다. 언젠가는 내일 당신이 직접 세션을 볼 수 있어야합니다. BRK3075 – 예기치 못한 상황에 대비하기 : Azure 정전에 대한 분석 공식 근본 원인 분석은 곧 발표 될 예정입니다. 한편, 세션에서 수집 한 정보의 일부는 다음과 같습니다.
원인
푸른 하늘의 사후 사후에서 정전은 이전에보고 된 번개로 인한 것이 아니었다. 대신, 폭풍우의 본질 때문에, 폭풍우의 폭풍과 폭우가있었습니다. 그 결과, 제 1 데이터 센터에 냉각 장치를 잠갔습니다. 이 첫 번째 정전 동안 그들은 눈에 띄는 영향없이 냉각기를 신속하게 회수 할 수있었습니다. 그 후 곧 복구되지 않은 두 번째 데이터 센터에 두 번째 정전이 발생했습니다. 그것은 일련의 불행한 사건을 야기했습니다.
두 번째 작동 중단
이 정전 동안 Microsoft는 "엔지니어는 경고장을 올바르게 분류하지 못했습니다. 냉각기 플랜트 복구는 우선 순위가 지정되지 않았습니다." 현재 수많은 경고가 발생했습니다. 불행히도 오프라인 상태 인 냉각기는 우선 순위를받지 못했습니다. 왜 그런 일이 일어 났는지에 대한 RCA는 아직 조사 중입니다. Microsoft는 물론 이중화 된 냉각기 시스템이 설치되어 있다고 말합니다. 그러나 냉각 시스템은 자동으로 장애 조치되도록 설정되지 않았습니다. 최근에 설치된 새로운 장비가 완전히 테스트되지 않았습니다. 따라서 테스트가 완료 될 때까지 수동 모드로 설정되었습니다. 45 분이 경과하면 주변 냉각이 실패하고 하드웨어가 종료되고 화재가 발생했다고 판단하여 에어 핸들러가 종료되었습니다. 직원이 거짓 화재 경보로 대피했습니다. 이 기간 동안 데이터 센터의 온도가 상승하고있었습니다. 일부 하드웨어가 제대로 종료되지 않아 일부 저장 장치 및 네트워킹이 손상되었습니다. 칠러를 수동으로 리셋하고 에어 핸들러를 열면 온도가 정상으로 돌아 오기 시작했습니다. 데이터 센터의 상태를 완전히 파악하기까지는 약 3 시간 29 분이 걸렸습니다. 가장 큰 문제는 스토리지 손상이었습니다. Microsoft의 주요 관심사는 데이터 보호입니다. Microsoft는 데이터 손실을 방지하기 위해 데이터를 복구하기 위해 노력할 것입니다. 이것은 물론 정전의 전체 길이를 연장하는 데 다소 시간이 걸렸습니다. 좋은 소식은 고객 데이터가 손실되지 않았다는 것입니다. 나쁜 소식은 일이 정상적으로 돌아 오는 데 24-48 시간이 걸린 것처럼 보였습니다. 이것은 장기간의 가동 중단에 대해 불평하는 고객으로부터 트위터를 통해 읽은 내용을 토대로 한 것입니다.
가정
누구나이 중단은 South Central Region에서 주최 한 고객에게 영향을 줄 것으로 예상했습니다. 그러나 그들이 기대하지 않은 것은 정전이 그 지역 밖에서 영향을 미칠 것이라는 것이 었습니다. 세션에서 Microsoft는 정전의 연장 범위 중 일부를 논의합니다.
Azure (Azure Service Manager)
Azure "Classic"리소스, AKA, ARM 이전 리소스를 제어합니다. ASM에 의존하는 누구나 영향을받을 수있었습니다. 왜 이런 일이 일어 났는지는 분명하지 않았습니다. 사우스 센트럴 리전 (South Central Region)은 해당 서비스의 일부 중요한 구성 요소를 호스팅하여 사용할 수 없게 된 것으로 보입니다.
Visual Studio Team Service (VSTS)
다시 말하지만,이 서비스를 지원하는 많은 자원이 South Central Region에서 호스팅되는 것으로 보입니다. 이 중단은 Buck Hodges (@tfsbuck), Azure Dev의 엔지니어링 이사가이 블로그 게시물에서 자세히 설명합니다.
POSTMORTEM : 2018 년 9 월 4 일 VSTS
Azure Active Directory (AAD)
사우스 센트럴 지역이 고장 났을 때 AAD는 기한 내에 설계된 것을 수행하고 다른 지역으로 인증 요청을하기 시작했습니다. 이스트 코스트 (East Coast)가 깨어나 온라인으로 시작되면서 인증 트래픽이 증가하기 시작했습니다. 이제는 AAD가 자동 확장을 통해 이러한 트래픽 증가를 처리하게되었습니다. 그러나 자동 크기 조정은 ASM에 종속되어 있습니다. ASM은 오프라인 상태였습니다. autoscale 기능이 없으면 AAD는 인증 요청의 증가를 처리 할 수 없었습니다. 상황을 과장하는 것은 Office 클라이언트의 버그였습니다. Office 클라이언트는 매우 적극적인 재시도 논리 및 백 오프 논리가없는 버그였습니다. 이 추가 인증 트래픽은 결국 AAD를 무릎까지 가져 왔습니다. Ignite 세션에서이 문제에 대해 더 논의 할 시간이 없었습니다. 앞으로 소개 될 기능 중 하나는 사용자가 장래에 수동으로 스토리지 계정을 장애 조치 할 수있는 기능을 제공한다는 것입니다. 따라서 복구 시간 목표 (RPO)가보다 중요한 경우 (RPO) 사용자는 향후 Microsoft에서 또 다른 장기간의 중단이 발생하면 대체 데이터 센터에서 비동기 복제 된 지리적 중복 스토리지를 복구 할 수 있습니다.
지금 할 수있는 일
그 때까지는 SIOS DataKeeper Azure Site Recovery와 같은 다른 복제 솔루션에 의존해야합니다. 또는 지역별로 데이터를 복제하고 재해 복구 계획을 수립 할 수있는 애플리케이션 별 복제 솔루션. 우리의 푸른 정전에 대한 자세한 내용은 Clusteringformeremortals.com의 허락하에 재현