데이터센터 연기 테스트에서 불이 붙으면 서버를 꺼야 할까요?

어느 화창한 여름날, 귀하의 장비가 있는 데이터 센터가 이렇게 보인다면 어떤 기분이 들겠습니까?

안녕하세요 여러분! 제 이름은 Dmitry Samsonov입니다. 저는 "에서 최고의 시스템 관리자로 일하고 있습니다.급우" 사진은 우리 프로젝트에 사용되는 장비가 설치된 4개의 데이터 센터 중 하나를 보여줍니다. 이 벽 뒤에는 서버, 데이터 저장 시스템, 네트워크 장비 등 약 XNUMX개의 장비가 있습니다. - 당사 전체 장비의 거의 XNUMX/XNUMX입니다.
대부분의 서버는 Linux입니다. 또한 Windows(MS SQL)에는 수십 대의 서버가 있습니다. 이는 우리가 수년 동안 체계적으로 포기해 온 유산입니다.
따라서 5년 2019월 14일 35시 XNUMX분에 우리 데이터 센터 중 한 곳의 엔지니어가 화재 경보를 보고했습니다.

부정

14:45. 데이터 센터에서 사소한 연기 사고는 생각보다 더 흔합니다. 홀 내부의 지표는 정상이었기 때문에 우리의 첫 번째 반응은 상대적으로 차분했습니다. 무언가 수정과 관련된 작업을 제외하고는 프로덕션 작업, 즉 구성 변경, 새 버전 출시 등을 금지하는 조치를 도입했습니다.

분노

지붕에서 화재가 발생한 정확한 위치를 소방관으로부터 알아내거나 상황을 평가하기 위해 직접 불타는 지붕에 올라가려고 노력한 적이 있습니까? 다섯 사람을 통해 얻은 정보에 대한 신뢰도는 얼마나 될까요?

14 : 50. 화재가 냉각 시스템에 접근하고 있다는 정보가 접수되었습니다.. 하지만 올까요? 근무 중인 시스템 관리자는 이 데이터 센터 전면에서 외부 트래픽을 제거합니다.

현재 모든 서비스의 전면은 XNUMX개의 데이터 센터에 복제되어 있으며 DNS 수준에서 밸런싱이 사용됩니다. 이를 통해 DNS에서 한 데이터 센터의 주소를 제거할 수 있으므로 서비스 액세스와 관련된 잠재적인 문제로부터 사용자를 보호할 수 있습니다. . 데이터 센터에 이미 문제가 발생한 경우 자동으로 회전을 종료합니다. 여기에서 자세한 내용을 읽을 수 있습니다. Odnoklassniki의 로드 밸런싱 및 내결함성.

화재는 아직 어떤 식으로든 우리에게 영향을 미치지 않았습니다. 사용자나 장비도 손상되지 않았습니다. 이건 사고인가요? "사고 조치 계획" 문서의 첫 번째 섹션은 "사고"의 개념을 정의하며 섹션은 다음과 같이 끝납니다.
«사고인지 아닌지 의심이 든다면 그것은 사고입니다!»

14:53. 비상 코디네이터가 임명됩니다.

코디네이터는 모든 참가자 간의 의사 소통을 제어하고, 사고 규모를 평가하고, 비상 조치 계획을 사용하고, 필요한 인력을 유치하고, 수리 완료를 모니터링하고, 가장 중요한 작업을 위임하는 사람입니다. 즉, 비상대응 과정 전반을 관리하는 사람이다.

거래

15:01. 프로덕션과 관련되지 않은 서버를 비활성화하기 시작합니다.
15:03. 예약된 모든 서비스를 올바르게 끕니다.
여기에는 프런트(현재 사용자가 더 이상 액세스하지 않음) 및 보조 서비스(비즈니스 로직, 캐시 등)뿐만 아니라 복제 요소가 2 이상인 다양한 데이터베이스(카산드 라, 바이너리 데이터 저장, 냉장, 새로운SQL 등.).
15 : 06. 데이터 센터 홀 중 하나에서 화재가 발생하고 있다는 정보가 접수되었습니다. 이 방에는 장비가 없지만 불이 지붕에서 복도로 퍼질 수 있다는 사실은 무슨 일이 일어나고 있는지에 대한 그림을 크게 바꿉니다.
(나중에 홀이 지붕에서 밀폐되어 있었기 때문에 홀에 물리적인 위협이 없다는 것이 밝혀졌습니다. 위협은 이 홀의 냉각 시스템에만 있었습니다.)
15:07. 추가 확인 없이 가속 모드의 서버에서 명령 실행을 허용합니다(우리가 가장 좋아하는 계산기 없이).
15:08. 홀의 온도는 정상 범위 내에 있습니다.
15 : 12. 홀의 온도 상승이 기록되었습니다.
15:13. 데이터센터 서버 절반 이상이 꺼져 있다. 계속합시다.
15:16. 모든 장비를 끄기로 결정했습니다.
15:21. 애플리케이션과 운영 체제를 올바르게 종료하지 않고 상태 비저장 서버의 전원을 끄기 시작합니다.
15:23. MS SQL을 담당하는 사람들 그룹이 할당됩니다 (그 중 소수이고 서비스 의존도는 크지 않지만 기능 복원 절차는 예를 들어 Cassandra보다 더 오래 걸리고 더 복잡합니다).

Депрессия

15 : 25. 16개관 중 6개관(7호, 8호, 9호, XNUMX호)에서 전원이 꺼졌다는 안내를 받았다. 우리 장비는 홀 7과 8에 있습니다. 저희 두 홀(1번, 3번)에 대한 정보가 없습니다.
일반적으로 화재가 발생하면 전원 공급 장치가 즉시 꺼지는데, 이 경우 소방관과 데이터 센터 기술 인력의 조화로운 작업 덕분에 모든 곳에서 즉시 꺼지지 않고 필요에 따라 꺼졌습니다.
(8번홀과 9번홀에서는 전원이 꺼지지 않은 것으로 나중에 밝혀졌다.)
15:28. 우리는 다른 데이터 센터의 백업에서 MS SQL 데이터베이스를 배포하기 시작했습니다.
얼마나 걸릴까요? 전체 경로에 대한 네트워크 용량이 충분합니까?
15 : 37. 네트워크 일부의 종료가 기록되었습니다.
관리 및 생산 네트워크는 물리적으로 서로 분리되어 있습니다. 프로덕션 네트워크를 사용할 수 있는 경우 서버로 이동하여 애플리케이션을 중지하고 OS를 끌 수 있습니다. 사용할 수 없는 경우 IPMI를 통해 로그인하고 애플리케이션을 중지한 다음 OS를 끌 수 있습니다. 네트워크가 없으면 아무것도 할 수 없습니다. “고마워요, 캡틴!”이라고 생각하실 겁니다.
“그리고 일반적으로 많은 혼란이 있습니다.”라고 생각할 수도 있습니다.
문제는 불이 없어도 서버에서 엄청난 양의 열이 발생한다는 것입니다. 더 정확하게 말하면, 냉각이 되면 열이 발생하고, 냉각이 없으면 지옥 같은 지옥불이 발생하는데, 이는 기껏해야 장비의 일부를 녹이고 다른 부품을 끄게 되며, 최악의 경우... 홀 내부에 불이 나면 거의 모든 것이 파괴됩니다.

15:39. conf 데이터베이스의 문제를 해결합니다.

conf 데이터베이스는 모든 프로덕션 애플리케이션에서 설정을 빠르게 변경하는 데 사용되는 동일한 이름의 서비스에 대한 백엔드입니다. 이러한 기반이 없으면 포털의 운영을 제어할 수 없지만 포털 자체는 작동할 수 있습니다.

15:41. 코어 네트워크 장비의 온도 센서는 허용되는 최대값에 가까운 판독값을 기록합니다. 랙 전체를 차지하는 박스로, 데이터센터 내부의 모든 네트워크의 운영을 보장합니다.

15:42. 이슈 트래커와 위키를 사용할 수 없습니다. 대기 모드로 전환하세요.
이는 생산이 아니지만 사고 발생 시 지식 기반의 가용성이 중요할 수 있습니다.
15:50. 모니터링 시스템 중 하나가 꺼졌습니다.
그 중에는 여러 가지가 있으며 서비스의 다양한 측면을 담당합니다. 그 중 일부는 각 데이터 센터 내에서 자율적으로 작동하도록 구성되고(즉, 자체 데이터 센터만 모니터링) 다른 일부는 데이터 센터 손실 시에도 투명하게 살아남는 분산 구성 요소로 구성됩니다.
이 경우 작동이 중지되었습니다. 비즈니스 로직 지표 이상 탐지 시스템, 마스터-대기 모드에서 작동합니다. 대기상태로 전환되었습니다.

수락

15:51. MS SQL을 제외한 모든 서버는 올바르게 종료되지 않고 IPMI를 통해 꺼졌습니다.
필요한 경우 IPMI를 통해 대규모 서버 관리를 수행할 준비가 되셨습니까?

이 단계에서 데이터센터 장비 구출이 완료되는 바로 그 순간이다. 할 수 있는 일은 모두 이루어졌습니다. 일부 동료는 쉴 수 있습니다.
16 : 13. 에어컨의 프레온 파이프가 지붕에서 터졌다는 정보가 접수되었습니다. 이로 인해 화재가 진압된 후 데이터 센터의 가동이 지연될 것입니다.
16:19. 데이터센터 기술진으로부터 받은 자료에 따르면 홀의 온도 상승이 멈췄다.
17:10. conf 데이터베이스가 복원되었습니다. 이제 애플리케이션 설정을 변경할 수 있습니다.
모든 것이 내결함성이 있고 하나의 데이터 센터 없이도 작동한다면 이것이 왜 그렇게 중요합니까?
첫째, 모든 것이 내결함성이 있는 것은 아닙니다. 아직 데이터 센터 장애를 충분히 극복하지 못한 다양한 보조 서비스가 있으며, 마스터-대기 모드의 데이터베이스도 있습니다. 설정 관리 기능을 사용하면 어려운 상황에서도 사고가 사용자에게 미치는 영향을 최소화하는 데 필요한 모든 작업을 수행할 수 있습니다.
둘째, 앞으로 몇 시간 내에 데이터센터의 운영이 완전히 복구되지 않을 것이 분명해졌으므로, 장기간의 복제본 가용성 불가로 인해 디스크가 가득 차는 등 추가적인 문제가 발생하지 않도록 조치를 취할 필요가 있었습니다. 나머지 데이터 센터.
17:29. 피자 타임! 우리는 로봇이 아닌 사람을 고용합니다.

복권

18:02. 8번 홀, 9번 홀, 10번 홀, 11번 홀의 온도가 안정되었습니다. 오프라인 상태로 남아 있는 곳 중 하나(7번)에는 우리 장비가 보관되어 있으며 그곳의 온도는 계속해서 상승하고 있습니다.
18:31. 그들은 1번 홀과 3번 홀의 장비 가동을 승인했습니다. 이 홀은 화재의 영향을 받지 않았습니다.

현재 서버는 가장 중요한 홀부터 시작하여 1, 3, 8번 홀에서 출시되고 있습니다. 실행 중인 모든 서비스가 올바르게 작동하는지 확인합니다. 7번 홀에는 여전히 문제가 있습니다.

18:44. 데이터 센터의 기술 직원은 7번 방(우리 장비만 있는 곳)에서 많은 서버가 꺼지지 않는 것을 발견했습니다. 우리 데이터에 따르면 그곳에는 26개의 서버가 온라인 상태로 남아 있습니다. 두 번째 확인 후에는 58개의 서버를 찾았습니다.
20:18. 데이터 센터 기술자는 복도를 따라 흐르는 이동식 덕트를 통해 에어컨이 없는 방에 공기를 불어넣습니다.
23:08. 첫 번째 관리자가 집으로 보내졌습니다. 누군가는 내일 일을 계속하려면 밤에 잠을 자야 합니다. 다음으로 더 많은 관리자와 개발자를 출시할 예정입니다.
02:56. 우리는 출시할 수 있는 모든 것을 출시했습니다. 우리는 자동 테스트를 사용하여 모든 서비스에 대해 많은 검사를 수행합니다.

03:02. 마지막 7홀 에어컨이 복구되었습니다.
03:36. 우리는 데이터 센터의 전선을 DNS로 교체했습니다. 이 순간부터 사용자 트래픽이 도착하기 시작합니다.
우리는 대부분의 행정팀을 집으로 보내고 있습니다. 하지만 우리는 몇 사람을 남겨두고 있습니다.

작은 FAQ:
Q: 18시 31분부터 02시 56분까지 무슨 일이 일어났나요?
A: '재난 대책 계획'에 따라 가장 중요한 서비스부터 시작하여 모든 서비스를 시작합니다. 이 경우 채팅의 코디네이터는 무료 관리자에게 서비스를 발급하고, 관리자는 OS 및 애플리케이션의 시작 여부, 오류가 있는지, 표시기가 정상인지 확인합니다. 출시가 완료된 후 그는 채팅에 자신이 한가함을 보고하고 코디네이터로부터 새로운 서비스를 받습니다.
하드웨어 오류로 인해 프로세스 속도가 더욱 느려집니다. OS 중지 및 서버 종료가 제대로 이루어졌음에도 불구하고 디스크, 메모리, 섀시의 갑작스러운 장애로 인해 일부 서버가 복귀하지 않는 경우가 있습니다. 정전되면 고장률이 높아집니다.
Q: 모든 것을 한 번에 실행한 다음 모니터링에 나타나는 문제를 수정할 수 없는 이유는 무엇입니까?
A: 서비스 간에 종속성이 있으므로 모든 작업은 점진적으로 수행되어야 합니다. 그리고 모니터링을 기다리지 않고 모든 것을 즉시 확인해야합니다. 문제가 악화되기를 기다리지 않고 즉시 문제를 처리하는 것이 더 낫기 때문입니다.

7시 40분. 마지막 관리자(코디네이터)는 잠자리에 들었습니다. 첫날의 작업이 완료되었습니다.
8:09. 첫 번째 개발자, 데이터 센터 엔지니어 및 관리자(새 코디네이터 포함)가 복원 작업을 시작했습니다.
09:37. 우리는 7 번 홀 (마지막 홀)을 올리기 시작했습니다.
동시에 우리는 디스크/메모리/서버 교체, 모니터링에서 "소진"되는 모든 항목 수정, 마스터-대기 구성에서 역할 전환 및 기타 작은 작업 등 다른 공간에서 수정되지 않은 사항을 계속 복원하고 있습니다. 그럼에도 꽤 많다.
17:08. 우리는 생산과 관련된 모든 정규 작업을 허용합니다.
21:45. 둘째날의 작업이 완료되었습니다.
09:45. 오늘은 금요일입니다. 모니터링에는 아직 몇 가지 작은 문제가 있습니다. 주말이 코앞으로 다가왔습니다. 모두가 긴장을 풀고 싶어합니다. 우리는 가능한 모든 것을 계속해서 대대적으로 수리하고 있습니다. 연기될 수 있었던 정기 관리 작업도 연기되었습니다. 코디네이터가 새로 왔습니다.
15:40. 갑자기 다른 데이터 센터에 있는 핵심 네트워크 장비 스택의 절반이 다시 시작되었습니다. 위험을 최소화하기 위해 전선을 교체하지 않았습니다. 사용자에게는 아무런 영향이 없습니다. 나중에 알고 보니 섀시 결함이었습니다. 코디네이터는 두 건의 사고를 동시에 수리하는 작업을 진행하고 있습니다.
17:17. 다른 데이터 센터의 네트워크 작동이 복원되었으며 모든 사항이 확인되었습니다. 데이터 센터가 순환됩니다.
18:29. 셋째 날의 작업과 일반적으로 사고 후 복구가 완료되었습니다.

사후

04.04.2013 년 404 오류가 발생한 당일, "동급생" 가장 큰 사고에서 살아남았어 —100일 동안 포털을 완전히 또는 부분적으로 사용할 수 없었습니다. 이 전체 기간 동안 다양한 도시, 다양한 회사(다시 한 번 감사드립니다!)에서 온 XNUMX명 이상의 사람들이 데이터 센터에서 원격 및 직접, 수동 및 자동으로 수천 대의 서버를 수리했습니다.
우리는 결론을 내렸습니다. 이러한 일이 다시 발생하지 않도록 우리는 오늘날까지 광범위한 작업을 수행하고 계속 수행하고 있습니다.

이번 사고와 404의 가장 큰 차이점은 무엇인가요?

• 우리는 "사고 조치 계획"을 가지고 있습니다. 분기마다 한 번씩 훈련을 실시합니다. 우리는 관리자 그룹(모두 차례로)이 "긴급 조치 계획"을 사용하여 이를 제거해야 하는 긴급 상황의 역할극을 수행합니다. 주요 시스템 관리자가 교대로 코디네이터 역할을 수행합니다.
• 분기별로 테스트 모드에서 LAN 및 WAN 네트워크를 통해 데이터 센터를 차례로 격리하여 병목 현상을 즉시 식별할 수 있습니다.
• 운영 시간 단축, SMART 임계값 강화 등 표준을 강화하여 손상된 디스크 수가 감소했습니다.
• 우리는 서버를 다시 시작한 후 복구하는 데 많은 시간이 필요한 오래되고 불안정한 데이터베이스인 BerkeleyDB를 완전히 버렸습니다.
• MS SQL을 사용하여 서버 수를 줄이고 나머지 서버에 대한 의존도를 줄였습니다.
• 우리는 우리 자신의 클라우드 - 단일 클라우드, 우리는 현재 XNUMX년 동안 모든 서비스를 적극적으로 마이그레이션해 왔습니다. 클라우드는 애플리케이션 작업의 전체 주기를 크게 단순화하고 사고 발생 시 다음과 같은 고유한 도구를 제공합니다.
  • 한 번의 클릭으로 모든 응용 프로그램을 올바르게 중지합니다.
  • 실패한 서버에서 애플리케이션을 쉽게 마이그레이션할 수 있습니다.
  • 전체 데이터 센터의 자동 순위(서비스 우선 순위) 출시.

이 글에 기술된 사고는 404일째 이후 최대 규모다. 물론 모든 일이 순조롭게 진행된 것은 아니다. 예를 들어, 화재로 인해 다른 데이터 센터에 있는 데이터 센터를 사용할 수 없는 동안 서버 중 하나의 디스크에 장애가 발생했습니다. 즉, Cassandra 클러스터의 복제본 4,2개 중 하나만 액세스할 수 있었습니다. 이것이 바로 모바일의 30%가 액세스 가능한 이유입니다. 애플리케이션 사용자가 로그인할 수 없습니다. 동시에 이미 연결된 사용자는 계속해서 작업했습니다. 사고의 결과로 평범한 버그부터 서비스 아키텍처의 단점까지 총 XNUMX개 이상의 문제가 확인되었습니다.

하지만 이번 사고와 404차의 가장 중요한 차이점은 화재 후유증을 제거하는 동안에도 이용자들은 여전히 ​​문자나 영상통화를 하고 있었다는 점이다. 탐탐, 게임을 하고, 음악을 듣고, 서로에게 선물을 주고, 비디오, TV 시리즈 및 TV 채널을 시청했습니다. OK, 또한 스트리밍되었습니다. OK 라이브.

사고는 어떻게 진행되나요?

출처 : habr.com