クラウドプロバイダーのインフラストラクチャに実際に単一障害点がないことを確認する方法
それをチェックしてください！
ここでは、新しいクラウドプラットフォームの受け入れテストの実施方法について説明します。
背景
9月24日、サンクトペテルブルクに新しいパブリッククラウドプラットフォームをオープンしました。
www.it-grad.ru/tsentr_kompetentsii/blog/39クラウドプラットフォームの予備テスト計画：
habrahabr.ru/post/234213そして、ここから始めます...
リモートテスト
1. FAS8040コントローラーをオフにする
| 期待される結果 | 実際の結果 |
| 作業ノードへの自動テイクオーバー、すべてのVSMリソースがESXiで利用可能になっている必要があり、データストアへのアクセスが失われることはありません。 | 1つの「ヘッド」（次に2番目）の自動テイクオーバーに成功しました。 最初のコントローラーからのボリュームが正常に2番目のコントローラーに切り替えられたため、手順自体に数十秒かかったことは注目に値します（「ヘッド」障害の検出を含む）。
インジケーターはノードで設定されます：options cf.takeover.detection.seconds 15 |
2. CN1610スイッチ間のすべてのスイッチ間リンクを無効にする
| 期待される結果 | 実際の結果 |
| CN1610スイッチ間のすべてのインタースイッチリンクを切断する場合、ノード間の通信を中断しないでください。 | ホストとネットワーク間の接続は失われず、ESXiへのアクセスは2番目のリンクを介して実行されました。 |
3.ペアになったクラスタースイッチの1つとNexusの1つのシーケンシャルリブート
| 期待される結果 | 実際の結果 |
| NetAppクラスターの障害なし | NetAppコントローラーは、2番目のCN1610スイッチを通じてクラスター化されたままです。 クラスタースイッチとコントローラーへのリンクを複製することで、1枚の鉄CN1610の落下を簡単に転送できます。 |
| ノード上のポートの1つはアクセス可能なままである必要があり、各ノード上のIFGRPインターフェイスでは10 GbEインターフェイスの1つがアクセス可能なままである必要があり、すべてのVSMリソースがESXiで利用可能であり、データストアへのアクセスが失われないようにする必要があります。 | リンクを複製してポートチャネルにマージした結果、Nexus 5548の1つを再起動しても感情は生じませんでした。 |
4. NexusのvPC（vPC-1、vPC-2）のいずれかのシリアルキャンセル
| 期待される結果 | 実際の結果 |
| NetAppノードの1つがネットワークリンクを失ったときの状況のシミュレーション。 この場合、2番目の「ヘッド」が制御する必要があります。 | コントローラーインターフェイスはそれぞれ消滅しました：e0bおよびe0c、続いてダウン状態ifgrp a0aおよびその上で発生したVLAN。 ノードが通常のteikoverに入った後、最初のテストからそれについて知ることができます。 |
5. Cisco Nexus 5548スイッチ間でスイッチ間リンクを交互に無効にする
| 期待される結果 | 実際の結果 |
| スイッチ間の接続を維持します。 | インターフェイスEth1 / 31およびEth1 / 32は、ポートチャネル1（Po1）に組み込まれています。 以下のスクリーンショットからわかるように、リンクの1つがクラッシュしても、Po1はアクティブのままであり、スイッチ間の接続性は失われません。 |
6. ESXiの代替ハードシャットダウン
稼働中のESXiホストの1つをオフにしました。シャットダウン時には、異なるOS（Windows、Linux）のテストマシンがありました。 無効にすると、動作中のホストのフォール状態がエミュレートされます。 ホスト（およびその上の仮想マシン）が使用不可になるトリガーがトリガーされた後、VMを2番目の（稼働中の）ホストに再登録するプロセスが開始されました。 その後、VMは数分以内に正常に起動しました。
| 期待される結果 | 実際の結果 |
| 隣接ホスト上の仮想マシンを再起動します。 | 予想どおり、HA VMwareのテスト後、マシンは5〜8分以内に隣接ホストで再起動しました。 |
7.監視の進行状況を監視する
| 期待される結果 | 実際の結果 |
| エラーメッセージを受信します。 | 私が言えることは...エラーと警告の複数のメール、テンプレートによる処理済みのリクエストとアピールのシステム、サービスデスクは完璧に反応しました。 |
監視システムは、サービスデスクで悲嘆に暮れました。
ITSMシステムは、テンプレートによってこれらの文字を解析し、イベントを生成しました。 同じイベントに基づいて、インシデントは自動的に完了しました。 以下は、監視システムのイベントに基づいてITSMシステムによって作成されたインシデントの1つです。
これらの事件の1つは私に落ちました。
機器側で直接テスト
1.電源ケーブルを取り外します（機器のすべてのアイテム）
もちろん、電源の1つが不良であることを発見しない限り、新しいことはありません。
テスト全体を通して、鉄片が損傷することはありませんでした。
また、NetAppは、それ自体とCluster Interconnect Switchの両方のサブスクリプションを解除しました。
Cluster-Netスイッチ：
VMware vSphereでは、ホストエラー：
注：Cisco SG200-26スイッチ管理には電源の冗長性はありません。
このスイッチは、アクセスネットワーク管理（ストレージシステム、サーバーの制御ポート上）に関与します。 このスイッチの電源をオフにしても、クライアントサービスのダウンタイムは発生しません。 また、インフラストラクチャの可用性の監視は、Cisco Nexus 5548レベルで形成される管理ネットワークを通じて実行されるため、Cisco SG200-26の障害によって監視が失われることはありません。
それにもかかわらず、このスイッチを介した制御の喪失を避けるために、自動転送スイッチAPC AP7721はすでに購入されており、2つのバスから冗長電源を提供しています。
2.ネットワークリンクをESXiから交互に切断する（Dell r620 / r810）
ホストとデータストア間の接続は消えず、2番目のリンクでESXiへのアクセスが実行されました。
以上です。 すべてのテストが成功しました。 受け入れテストに合格しました。 クラウドのハードウェアは、新規顧客向けに仮想インフラストラクチャを展開する準備ができています。
PS
テストを行った後、私は長い間、信頼性の高い鉄の力感と品質係数を手放しませんでした。これは、耐障害性の複雑なチェック全体で自分の手で触れる機会がありました。