おい、ハブル！
正月休み明けに、XNUMX拠点を拠点とした災害に強いクラウドを再起動しました。 今日は、その仕組みを説明し、クラスターの個々の要素に障害が発生し、サイト全体がクラッシュした場合にクライアント仮想マシンに何が起こるかを示します (ネタバレ – すべて問題ありません)。
OSTサイトに災害に強いクラウドストレージシステムを導入。
中身は何ですか
クラスタの内部には、VMware ESXi ハイパーバイザを備えた Cisco UCS サーバ、2240 つの INFINIDAT InfiniBox FXNUMX ストレージ システム、Cisco Nexus ネットワーク機器、および Brocade SAN スイッチが含まれています。 クラスターは OST と NORD の XNUMX つのサイトに分割されています。つまり、各データセンターには同一の機器セットがあります。 実はこれが災害に強いのです。
XNUMX つのサイト内では、主要な要素 (ホスト、SAN スイッチ、ネットワーキング) も複製されます。
XNUMX つのサイトは、これも予約された専用の光ファイバー ルートで接続されています。
ストレージ システムについて少し説明します。 私たちは、NetApp 上に災害に強いクラウドの最初のバージョンを構築しました。 ここでは INFINIDAT を選択しました。その理由は次のとおりです。
- アクティブ-アクティブ レプリケーション オプション。 これにより、ストレージ システムの XNUMX つが完全に故障した場合でも、仮想マシンは動作し続けることができます。 レプリケーションについては後ほど詳しく説明します。
- システムの耐障害性を高めるための XNUMX つのディスク コントローラー。 通常はXNUMXつあります。
- 準備ができたソリューション。 組み立て済みのラックを受け取ったので、あとはネットワークに接続して設定するだけです。
- 丁寧な技術サポート。 INFINIDAT のエンジニアは、ストレージ システムのログとイベントを常に分析し、新しいファームウェア バージョンをインストールし、構成を支援します。
開梱時の写真は次のとおりです。
その仕組み
クラウドはそれ自体ですでに耐障害性を備えています。 単一のハードウェアおよびソフトウェアの障害からクライアントを保護します。 耐災害性は、XNUMX つのサイト内の大規模な障害から保護するのに役立ちます。たとえば、ストレージ システム (または SDS クラスター。これは非常に頻繁に発生します 🙂) の障害、ストレージ ネットワーク内の大規模なエラーなどです。 そして最も重要なことは、このようなクラウドは、火災、停電、レイダーの乗っ取り、またはエイリアンの上陸によってサイト全体がアクセスできなくなったときに救われるということです。
これらのすべてのケースにおいて、クライアント仮想マシンは引き続き動作します。その理由は次のとおりです。
クラスタ設計は、クライアント仮想マシンを備えた ESXi ホストが XNUMX つのストレージ システムのいずれかにアクセスできるように設計されています。 OST サイト上のストレージ システムに障害が発生した場合でも、仮想マシンは動作し続けます。仮想マシンが実行されているホストは、データを取得するために NORD 上のストレージ システムにアクセスします。
クラスター内の接続図は次のようになります。
これは、XNUMX つのサイトの SAN ファブリック間にスイッチ間リンクが構成されているため可能です。ファブリック A OST SAN スイッチはファブリック A NORD SAN スイッチに接続されており、ファブリック B SAN スイッチも同様です。
SAN ファクトリのこれらすべての複雑さが理解できるように、アクティブ/アクティブ レプリケーションが 0 つのストレージ システム間で構成されます。情報は、ローカル ストレージ システムとリモート ストレージ システムにほぼ同時に書き込まれます (RPO = XNUMX)。 元のデータは XNUMX つのストレージ システムに保存され、そのレプリカはもう XNUMX つのストレージ システムに保存されていることがわかります。 データはストレージ ボリュームのレベルでレプリケートされ、VM データ (ディスク、構成ファイル、スワップ ファイルなど) がストレージ ボリュームに保存されます。
ESXi ホストは、プライマリ ボリュームとそのレプリカを 24 つのディスク デバイス (ストレージ デバイス) として認識します。 ESXi ホストから各ディスク デバイスへのパスは XNUMX あります。
12 のパスはローカル ストレージ システム (最適なパス) に接続し、残りの 12 のパスはリモート ストレージ システム (非最適なパス) に接続します。 通常の状況では、ESXi は「最適な」パスを使用してローカル ストレージ システム上のデータにアクセスします。 このストレージ システムに障害が発生すると、ESXi は最適なパスを失い、「最適でない」パスに切り替わります。 図で見るとこんな感じです。
災害に強いクラスターの仕組み。
すべてのクライアント ネットワークは、共通のネットワーク ファブリックを介して両方のサイトに接続されます。 各サイトはプロバイダー エッジ (PE) を実行し、クライアントのネットワークはそこで終端されます。 PE は共通のクラスターに結合されます。 XNUMX つのサイトで PE に障害が発生した場合、すべてのトラフィックは XNUMX 番目のサイトにリダイレクトされます。 このおかげで、PE なしで放置されたサイトの仮想マシンは、ネットワーク経由でクライアントにアクセス可能なままになります。
次に、さまざまな障害が発生したときにクライアント仮想マシンに何が起こるかを見てみましょう。 最も軽いオプションから始めて、最も深刻な、サイト全体の障害で終わりましょう。 この例では、メイン プラットフォームは OST で、データ レプリカを備えたバックアップ プラットフォームは NORD になります。
次の場合、クライアント仮想マシンはどうなりますか?
レプリケーション リンクが失敗します。 XNUMX つのサイトのストレージ システム間のレプリケーションが停止します。
ESXi は、ローカル ディスク デバイスでのみ動作します (最適なパス経由)。
仮想マシンは引き続き動作します。
ISL (スイッチ間リンク) が切断されました。 そのようなケースは考えられません。 狂った掘削機が一度に複数の光ルートを掘り起こし、それらの光ルートが独立したルートを走り、異なる入力を介してサイトに運ばれる場合を除きます。 とにかく。 この場合、ESXi ホストはパスの半分を失い、ローカル ストレージ システムのみにアクセスできます。 レプリカは収集されますが、ホストはレプリカにアクセスできません。
仮想マシンは正常に動作しています。
いずれかのサイトで SAN スイッチに障害が発生しました。 ESXi ホストはストレージ システムへのパスの一部を失います。 この場合、スイッチに障害が発生したサイトのホストは、いずれかの HBA を介してのみ動作します。
仮想マシンは引き続き正常に動作します。
いずれかのサイト上のすべての SAN スイッチに障害が発生します。 OST サイトでそのような災害が発生したとします。 この場合、このサイトの ESXi ホストはディスク デバイスへのすべてのパスを失います。 標準の VMware vSphere HA メカニズムが機能し、NORD の OST サイトのすべての仮想マシンが最大 140 秒以内に再起動されます。
NORD サイト ホスト上で実行されている仮想マシンは正常に動作しています。
XNUMX つのサイトで ESXi ホストに障害が発生します。 ここで、vSphere HA メカニズムが再び動作します。障害が発生したホストの仮想マシンは、同じサイトまたはリモート サイトの他のホストで再起動されます。 仮想マシンの再起動時間は最大 1 分です。
OST サイト上のすべての ESXi ホストに障害が発生した場合、選択肢はありません。VM は別のホストで再起動されます。 再起動時間も同じです。
ストレージ システムの XNUMX つのサイトで障害が発生しました。 OST サイトでストレージ システムに障害が発生したとします。 その後、OST サイトの ESXi ホストは、NORD のストレージ レプリカを使用するように切り替わります。 障害が発生したストレージ システムが復旧すると、強制レプリケーションが実行され、ESXi OST ホストは再びローカル ストレージ システムへのアクセスを開始します。
仮想マシンはこれまでずっと正常に動作していました。
サイトの XNUMX つが失敗します。 この場合、すべての仮想マシンは vSphere HA メカニズムを通じてバックアップ サイトで再起動されます。 VM の再起動時間は 140 秒です。 この場合、仮想マシンのすべてのネットワーク設定が保存され、クライアントはネットワーク経由で引き続きアクセスできます。
バックアップ サイトでのマシンの再起動がスムーズに行われるようにするため、各サイトは半分だけ使用されます。 後半は、すべての仮想マシンが XNUMX 番目の破損したサイトから移動する場合に備えて予備です。
XNUMX つのデータセンターを基盤とする災害に強いクラウドは、このような障害から保護します。
メインのリソースに加えて、XNUMX番目のサイトに予備が必要なため、この喜びは安くありません。 したがって、長期的なダウンタイムが経済的および評判の大きな損失を引き起こす場合、または情報システムが規制当局や社内規制による災害耐性要件の対象となる場合、ビジネスに不可欠なサービスはそのようなクラウドに配置されます。
ソース：
出所： habr.com