3月3日、モスクワ時間22時50分頃、車は新しいクラウドで応答しなくなりました。
ロードスケジュールを確認できました。最後の15分間は、プロセッサアクティビティがゼロでした。
再起動を2回試行し、強制シャットダウンを2回行いました-失敗しました。
現在、クラウド管理はまったく無効になっています。
システムエンジニアはチケットに回答しました。
こんにちは。 実際、クラウド内のいくつかのサーバーがクラッシュしました。 当社の専門家がこの問題に取り組んでいます。
おaび申し上げます。
コミュニティに通知し、テクニカルサポートの負荷をわずかに軽減するトピックを作成しています。
残念ながら、事故はもっと深刻でした。
タイムライン
22:50問題が始まりました。 サーバー上でアクティビティがゼロの場合、管理は機能しません。
01:25車が上昇し始めた。
02:05落ちたようです-車は同じように反応しなくなりました。 早く喜んだ。
04:00 アマラオ ：
非難する。 データは損傷なしで保存されましたが、ストレージシステムとホストの間の接続は、はい、2回壊れました。
修理が完了し、影響を受けた車が始動しました。
05:10 Dlusskyは、「何も機能しない」ことを発見しました。グラフから判断すると、車は約4倍に削減されました。
05:25 Dlusskyは、クラウドコントロールパネルをオフにし、 0.5〜3時間の復旧時間について話すことをサポートしました。
07:08アマラオ ：
まだ問題に取り組んでおり、解決方法について考えています。 比較的高いディスクアクティビティがあると、IOが麻痺します。
10:00変更なし。 いいえ、彼らはカルマを漏らした。 8まで落ちたら-ドラフトのトピックを削除します。
11:12 dyadyavasya ：
ちょうどチケットに答えた：
「専門家による予備的な見積もりによると、作業は2時間以内に完了します。」
14:00状況に特別な変更はありません。 しかし、善良な人々のおかげで、カルマは正常に戻りました！
14:15コントロールパネルのメッセージ：
車を始動します。私は立ち上がって働いていましたが、今のところは喜びを待っています。
15:00タイプサーバーは動作しています。リソース消費スケジュールは正常であり、応答しますが、単一サイトまたはsshアクセスは機能しません。
15:04 アマラオ ：
事故の最後の痕跡は除去されました。
ごめんなさい
補償は、明日私はサイズのために戦うでしょう。 状況が再現されないようになりました。 本質的に、最高の優先度で決定します。
ごめんなさい
アマラオからの状況の公式説明
それで何が起こった。
要するに-順番に（10分間隔で）、ストレージクラスターを提供する両方のサーバーのraid10アレイが停止しました。 これらのアレイの上に、flashcache（キャッシュ層）とdrbdがあり、Cプロトコル（同期記録モード）で動作します。
システムは、次のアルゴリズムに従って構成されました。ストレージの1つがクラッシュした場合、2番目のストレージは引き続き動作します。 どのストレージが活発であるか、そうでないかは、仮想化ホストでmultipathdを使用して決定されます。
開始前に実行した基本的なテストには、ノードのクラッシュ（クラッシュ）、電源の喪失、raid10が生き残ることができる以上のディスクの取り出し（死）、キャッシュssd raid（raid10）の死、再起動 '、ネットワークケーブルを取り外して、そこに突っ込む/戻る（スプリットブレインからの保護）。 これらのテストはすべて合格し、（I）システムがニーズに十分耐えられるという自信がありました。
その夜、通常の襲撃チェックが開始されました。 バックグラウンドでレイドの整合性をチェックする無害なプロセス。 最初のプールでのストレージは、このプロセスをゆっくりと続けます（約2〜5 MB /秒）。 チェックを実行するカーネルモジュールにより、遅延が大幅に増加しないことが保証されるため、クライアントは通常モードではこのプロセスに気付かないはずです。
ただし、問題が発生しました（現在の仮説はカーネルモジュールのバグです）-検証プロセスと同時にアグレッシブIO（ディスクアレイあたり約25 IOPS）が存在すると、アレイのIOが停止しました。 完全に。 dd if = / dev / md10 of = / dev / null bs = 512 count = 1だけが「ハングアップ」しました。 同時に、基礎となるすべてのディスクからの読み取りは直接成功し、通常の速度で行われました。 これにより、ioのiscsiターゲット（およびその後のチェーン内の他のすべて）が成功も応答も受け取らなかったという事実に至りました。 さらに、通常の「チェッカー」マルチパスは、ディスクの最初の512バイトの可読性をチェックするため、状況は複雑でした。 これらの512バイトがフラッシュキャッシュにキャッシュされているかどうかを推測してください...状況は、リクエストの一部（ssdキャッシュにあったもの）が正常に処理され、書き込みリクエストも問題なく到着するという事実によって混乱しました。 ある時点で、ssdキャッシュがいっぱいで、ドロップに問題がありました。 同期drbdモードにより、停止（エラーではなく、つまり停止）により、両方のピアが停止しました。 理論的には、「病気の」ごちそうをオフにすることによってのみ問題を解決することができました（これは最初に行いました）。 これは長い間役に立たず、その後、2番目の問題で問題が繰り返されました（ハードウェアではなく、カーネルモジュールの問題を再度言います）。 この時点で、ほとんどのお客様が問題に気づきました。 録音が完全に麻痺したため、この時点までに上昇した（そして何も起こらなかったかのようにディスクをチェックし続けていた）前の宴会の場所に戻ることができませんでした。 最初の「グローバルリブート」。 車のおおよそのリフティング速度は、1台あたり約2〜3秒です（車はより長く始動し、始動操作は並行して行われます）。 300台のマシンのどこかで、同期速度が急速に低下し始めました（実際、すでに0であり、「平均の減少」は単なるランダムな効果でした）。 ほぼ同時に、問題は2番目のピアで繰り返されました（この時点でリブートされました）。 カーネルの更新を試みることが決定されましたが、これは状況を修正しませんでした。 「手動回復」の計画が描かれ始めました。 この時点で、私のアシスタントは「再構築してください」と提案しました。 ダリ（350分）。 この時間の間に、私はなんとか少し昼寝をすることさえできました（時間が午前7時までにすでに忍び上がっていたからです）。 念のため、これはディスク障害が発生した場合の「再構築」ではなく、アレイ内のすべてのディスクの稼働状態を「毎月」チェックすることです。 このプロセスは、10個すべてのraidで行われ、そのうちのストレージは（両方のストレージで）約200-250Mb / sの速度で収集されました。
午後の1時までに、プロセスは終了し、クラスターバインドを手動で引き上げるのにさらに10分かかり、プールが再起動したのはさらに5分でした（2番目のプールのすべてのマシンが影響を受けたため、誰が生きているのか、誰がいないのかについてのマルチパスの意見を手動で修正して整理する意味はありませんでした）。 打ち上げが開始されました。 午後2時までに開始が終わり、画面上のボタンを押すように求めるさまざまなfsckの手動分析が開始されました。
結論と取られた措置。
1）「今後数日で」ローカルソリューションとして-再同期raidの起動は禁止されています。
2）近い将来、raid（およびスタック内の他のブロックデバイス-flashcache、lvm、drbdなど）に対してシナリオ「機能しないがエラーを報告しない」が提供される予定です。
3）並行して、同等のスタンドが構築され（SSDなしのディスクはより少なくなります）、状況を再現し、それが表示されない構成を探し始めます。 現在の想定では、raid1の上のraid0はこのように動作しないはずです。
4）バグレポートを送信します（ステップ3が成功した場合）。
おApび
非難する。 これは不可能であり、状況を改善するためにあらゆる努力をすることを理解しています。
補償：
補償として、影響を受ける仮想マシンに費やされた資金の100％を返すことが決定されました。