データセンターの発煙試験で火災が発生した場合、サーバーを消火すべきでしょうか?

ある晴れた夏の日、あなたの機器が置かれたデータセンターがこのように見えたらどう思いますか?

こんにちは、みんな！ 私の名前はドミトリー・サムソノフです。「」で主要なシステム管理者として働いています。クラスメート」 写真は、私たちのプロジェクトに役立つ機器が設置されている 4 つのデータセンターのうちの XNUMX つを示しています。 これらの壁の後ろには、サーバー、データ ストレージ システム、ネットワーク機器など、約 XNUMX 個の機器があります。 - 当社の全機器のほぼ XNUMX/XNUMX。
ほとんどのサーバーは Linux です。 また、Windows (MS SQL) 上には数十台のサーバーがあり、これは私たちが長年にわたり計画的に放棄してきた私たちの遺産です。
そこで、5 年 2019 月 14 日 35 時 XNUMX 分、当社のデータセンターの XNUMX つでエンジニアが火災警報器を通報しました。

否認

14:45。 データセンターでの軽度の煙事故は、思っているよりも頻繁に発生します。 ホール内のインジケーターは正常だったので、私たちの最初の反応は比較的穏やかでした。つまり、何かの修正に関連する作業を除いて、本番環境での作業、つまり構成変更や新しいバージョンのロールアウトなどの作業が禁止されました。

激怒

消防士から屋根のどこで火災が発生したかを正確に聞き出そうとしたことや、燃えている屋根に自分で乗り込んで状況を確認しようとしたことはありますか? XNUMX人を通して得られる情報の信頼度はどうなるのか？

14：50。 火災が冷却システムに近づいているとの情報が入った。 しかし、それは来るでしょうか？ 勤務中のシステム管理者は、このデータ センターの前面から外部トラフィックを削除します。

現時点では、当社のすべてのサービスのフロントは XNUMX つのデータ センターで複製されており、DNS レベルでバランシングが使用されています。これにより、DNS から XNUMX つのデータ センターのアドレスを削除できるため、サービスへのアクセスに関する潜在的な問題からユーザーを保護できます。 。 データセンターですでに問題が発生している場合、ローテーションは自動的に終了します。 詳細はこちらでご覧いただけます: Odnoklassniki の負荷分散とフォールト トレランス。

火災による当社への影響はまだまったくなく、ユーザーも機器も被害を受けていません。 これは事故ですか？ 文書「事故行動計画」の最初のセクションでは「事故」の概念が定義されており、そのセクションは次のように終了しています。
«事故かどうか疑わしい場合は、それは事故です。»

14:53。 緊急コーディネーターが任命されます。

コーディネーターは、すべての参加者間のコミュニケーションを管理し、事故の規模を評価し、緊急行動計画を使用し、必要な人員を集め、修理の完了を監視し、そして最も重要なことに、あらゆるタスクを委任する人です。 言い換えれば、これは緊急対応プロセス全体を管理する人物です。

トレーディング

15:01。 本番環境に関係のないサーバーの無効化を開始します。
15:03。 予約されているすべてのサービスを正しくオフにします。
これには、フロント (この時点でユーザーはアクセスできなくなります) とその補助サービス (ビジネス ロジック、キャッシュなど) だけでなく、レプリケーション ファクター 2 以上のさまざまなデータベースも含まれます (カサンドラ, バイナリデータストレージ, 冷蔵, 新しいSQL 等。）。
15：06。 データセンターのホールの XNUMX つが火災の危険にさらされているという情報が入りました。 この部屋には設備はありませんが、火災が屋根からホールまで延焼する可能性があるという事実は、何が起こっているかの状況を大きく変えます。
（ホールは屋上から密閉されていたため、物理的な脅威はなかったことが後に判明しました。脅威はこのホールの冷却システムのみでした。）
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ホールと第XNUMXホール）についての情報はありません。
通常、火災が発生するとすぐに電源が切れますが、この場合は消防士とデータセンターの技術員の連携作業のおかげで、どこでもすぐにではなく、必要に応じて電源が切れることはありませんでした。
（8・9ホールは停電していなかった事が後に判明）
15:28。 他のデータセンターのバックアップから MS SQL データベースを展開し始めています。
どのくらい時間がかかりますか？ ルート全体に十分なネットワーク容量はありますか?
15：37。 ネットワークの一部のシャットダウンが記録されました。
管理ネットワークと運用ネットワークは物理的に相互に分離されています。 運用ネットワークが利用可能な場合は、サーバーにアクセスしてアプリケーションを停止し、OS をオフにすることができます。 利用できない場合は、IPMI 経由でログインし、アプリケーションを停止して OS をオフにすることができます。 どのネットワークも存在しない場合は何もできません。 「ありがとう、キャップ！」と思うでしょう。
「そして、一般的には混乱が多いのではないか」とあなたも思うかもしれません。
問題は、火がなくてもサーバーは大量の熱を発生するということです。 より正確に言うと、冷却があるときは熱を発生し、冷却がないときは地獄のような地獄を作り出し、良くても機器の一部が溶けて別の部品が停止し、最悪の場合は...ホール内で火災が発生し、ほぼ確実にすべてが破壊されます。

15:39。 conf データベースの問題を修正します。

conf データベースは、同じ名前のサービスのバックエンドであり、すべての実稼働アプリケーションで設定を迅速に変更するために使用されます。 この基盤がなければ、ポータルの動作を制御することはできませんが、ポータル自体は機能します。

15:41。 コア ネットワーク機器の温度センサーは、最大許容値に近い測定値を記録します。 これはラック全体を占有し、データセンター内のすべてのネットワークの動作を保証するボックスです。

15:42。 Issue Tracker と Wiki は利用できません。スタンバイに切り替えてください。
これは本番環境ではありませんが、事故が発生した場合には、知識ベースの可用性が非常に重要になる可能性があります。
15:50。 監視システムの XNUMX つがオフになりました。
それらはいくつかあり、サービスのさまざまな側面を担当します。 それらの中には、各データセンター内で自律的に動作するように構成されているもの (つまり、独自のデータセンターのみを監視しているもの) もあれば、データセンターが失われても透過的に存続する分散コンポーネントで構成されているものもあります。
この場合は動作しなくなりました ビジネスロジックインジケーター異常検知システム、マスタースタンバイモードで動作します。 スタンバイ状態に切り替わりました。

養子縁組

15:51。 MS SQL を除くすべてのサーバーが、正しくシャットダウンされずに IPMI 経由でオフになりました。
必要に応じて、IPMI を介して大規模なサーバー管理を行う準備はできていますか?

この段階でデータセンター内の機器の救出が完了する瞬間です。 できることはすべて行われました。 休める同僚もいます。
16：13。 エアコンのフロン管が屋上で破裂したとの情報が入っており、火災が鎮火した後のデータセンターの立ち上げが遅れることになる。
16:19。 データセンターの技術スタッフから受け取ったデータによると、ホール内の温度上昇は止まっているとのこと。
17:10。 conf データベースが復元されました。 これでアプリケーションの設定を変更できるようになりました。
すべてがフォールトトレラントであり、XNUMX つのデータセンターがなくても機能するのであれば、これがなぜそれほど重要なのでしょうか?
まず、すべてがフォールトトレラントであるわけではありません。 データセンターの障害から十分に回復できていないさまざまなセカンダリ サービスがあり、マスター/スタンバイ モードのデータベースもあります。 設定を管理する機能により、困難な状況であっても、事故によるユーザーへの影響を最小限に抑えるために必要なすべてのことを行うことができます。
第 XNUMX に、データ センターの運用は今後数時間以内に完全には復旧しないことが明らかになったため、レプリカが長期間利用できなくなることでディスクがいっぱいになるなどのさらなるトラブルが発生しないように対策を講じる必要がありました。残りのデータセンター。
17:29。 ピザタイム！ 私たちはロボットではなく人間を雇用しています。

リハビリテーション

18:02。 8番ホール(当社)、9番、10番、11番ホールは気温が安定してきました。 オフラインのままの 7 つ (XNUMX 番) には当社の機器が設置されており、そこの温度は上昇し続けています。
18:31。 彼らは、ホール No.1 とホール No.3 での機器の起動にゴーサインを出しました。これらのホールは火災の影響を受けませんでした。

現在、ホール No.1、3、8 で重要度の高いサーバーから順にサーバーを立ち上げています。 実行中のすべてのサービスが正しく動作するかどうかがチェックされます。 7番ホールにはまだ問題が残っています。

18時44分。 データセンターの技術スタッフは、7 号室 (当社の機器のみが置かれている) で多くのサーバーの電源がオフになっていないことを発見しました。 私たちのデータによると、26 台のサーバーがオンラインのままです。 58 回目のチェックの後、XNUMX 台のサーバーが見つかりました。
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。 突然、別のデータ センターのコア ネットワーク機器スタックの半分が再起動しました。 リスクを最小限に抑えるためにフロント陣はローテーションから外された。 ユーザーへの影響はありません。 その後、シャーシの故障であることが判明しました。 コーディネーターは同時に XNUMX 件の事故の修復に取り組んでいます。
17:17。 別のデータセンターのネットワーク動作は復旧し、すべてが確認されました。 データセンターはローテーションに入ります。
18:29。 XNUMX日目の作業と、事故後の復旧は概ね完了しました。

後書き

04.04.2013年、 404エラーの日、「クラスメイト」 最大の事故を生き延びた - 100 日間、ポータルが完全または部分的に利用できなくなりました。 この間ずっと、さまざまな都市、さまざまな企業の XNUMX 人以上の人々 (改めて感謝します!) が、データ センターでリモートおよび直接、手動および自動で数千台のサーバーを修復しました。
私たちは結論を導き出しました。 このようなことが二度と起こらないように、私たちは大規模な取り組みを実施し、現在も継続して実施しています。

今回の事故と404の主な違いは何ですか？

• 当社では「事故対応計画」を設けています。 四半期に一度、私たちは演習を実施します。緊急事態のロールプレイングを行い、管理者のグループが (順番に) 「緊急時行動計画」を使用してこの事態を排除する必要があります。 主要なシステム管理者が交代でコーディネーターの役割を果たします。
• 四半期に一度、テスト モードで LAN および WAN ネットワーク経由でデータ センターを (すべて順番に) 隔離するため、ボトルネックを迅速に特定できます。
• 基準を厳格化したため、ディスクの破損が減少しました。稼働時間の短縮、SMART のしきい値の厳格化、
• 私たちは、サーバーの再起動後に回復するのに多くの時間を必要とした、古くて不安定なデータベースである BerkeleyDB を完全に放棄しました。
• MS SQL を使用するサーバーの数を減らし、残りのサーバーへの依存を減らしました。
• 私たちには独自のものがあります クラウド - XNUMX つのクラウドでは、XNUMX 年間にわたってすべてのサービスを積極的に移行してきました。 クラウドはアプリケーションの操作サイクル全体を大幅に簡素化し、事故が発生した場合には次のような独自のツールを提供します。
  • ワンクリックですべてのアプリケーションを正しく停止します。
  • 障害が発生したサーバーからアプリケーションを簡単に移行できます。
  • データセンター全体を自動的にランク付け（サービスの優先順位に従って）起動します。

この記事で説明した事故は、404日目以来最大のものでした。 もちろん、すべてが順調に進んだわけではありません。 たとえば、火災で被害を受けた別のデータセンターのデータセンターが利用できなくなったとき、サーバーの 4,2 つのディスクに障害が発生しました。つまり、Cassandra クラスター内の 30 つのレプリカのうち XNUMX つだけがアクセス可能でした。そのため、モバイルの XNUMX% がアプリケーションユーザーはログインできませんでした。 同時に、すでに接続しているユーザーは引き続き作業を続けました。 事故の結果、ありふれたバグからサービス アーキテクチャの欠陥に至るまで、合計 XNUMX 以上の問題が特定されました。

しかし、今回の事故と 404 件目の事故の最も重要な違いは、私たちが火災の影響を排除している間も、ユーザーは依然としてテキスト メッセージやビデオ通話を行っていたことです。 トムトム、ゲームをしたり、音楽を聴いたり、お互いに贈り物をしたり、ビデオやテレビシリーズやテレビチャンネルを見たりしました。 ОК、でもストリーミングされています OKライブ.

あなたの事故はどうなりますか？

出所： habr.com