高可用性

ハードウェアの冗長性 🔗

最小限のベース・ラック構成には、1つの要素の障害がシステム全体の可用性に影響しないように、冗長ネットワーク、ストレージおよびサーバー・コンポーネントが含まれています。

システム全体でのデータ接続は、リーフ・スイッチとスパイン・スイッチの冗長ペアに基づいて構築されます。リンクアグリゲーションは、スイッチポート、ホストNIC、およびアップリンクのすべてのインタフェースで構成されます。リーフ・スイッチは、クロスケーブルを使用してラック・コンポーネントを相互接続し、各コンポーネントの冗長ネットワーク・インタフェースに接続します。また、各リーフ・スイッチは各スパイン・スイッチに接続され、スパイン・スイッチも相互に接続されます。スパイン・スイッチはネットワークのバックボーンを形成し、ラック外部のトラフィックを有効にします。データ・センター・ネットワークへのアップリンクは、2つのケーブル・ペアで構成され、2つの冗長なToR (トップ・オブ・ラック)スイッチに相互接続されます。

コントローラのソフトウェアおよびシステムレベルのサービスを実行する管理クラスタは、完全にアクティブな3つの管理ノードで構成されます。インバウンド・リクエストは管理ノード・クラスタの仮想IPを通過し、ロード・バランサによって3つのノードに分散されます。いずれかのノードの応答が停止し、クラスタからのフェンスが発生した場合、ロード・バランサは、障害が発生したノードが再度正常になり、クラスタに再度参加するまで、残りの2つのノードにトラフィックを引き続き送信します。

システムおよび環境内のクラウド・リソースのストレージは、内部ZFS Storage Applianceによって提供されます。その2つのコントローラはアクティブ/アクティブクラスタを形成し、同時に高可用性と優れたスループットを提供します。ZFSプールは、最適なデータ保護のためにミラー化構成のディスク上に構築されます。

システム可用性 🔗

ソフトウェアおよびサービス・レイヤーは、3ノード管理クラスタにデプロイされ、クラスタ設計に固有の高可用性を利用します。Kubernetesコンテナ・オーケストレーション環境では、独自のコントローラ・ノードとホストするサービス・ポッドの両方にクラスタリングも使用されます。マイクロサービスの多くのレプリカが、常に実行されています。ノードとポッドは管理ノード全体に分散され、Kubernetesは、すべてのサービスがアクティブ/アクティブな設定で実行されるように、失敗したポッドが新しいインスタンスに置き換えられるようにします。

すべてのサービスおよびコンポーネントは、共通の中央のMySQLデータベースにデータを格納します。MySQLクラスタ・データベースには、3つの管理ノードにデプロイされたインスタンスがあります。可用性、ロード・バランシング、データ同期およびクラスタリングはすべて、MySQLクラスタの内部コンポーネントによって制御されます。

システム・レベルのインフラストラクチャ・ネットワークの大部分は、ソフトウェア定義です。仮想スイッチ、ルーター、およびゲートウェイの構成は、スイッチによって格納および管理されませんが、ネットワークアーキテクチャーの複数のコンポーネントに分散されます。ネットワークコントローラは、高可用性コンテナ化されたサービスとして配備されます。

アップグレード・フレームワークは、ハードウェア冗長性とクラスタ化された設計を利用して、すべてのコンポーネントのローリング・アップグレードを提供します。1つのコンポーネント・インスタンスのアップグレード中に、残りのインスタンスは停止時間がないことを確認します。アップグレードは、すべてのコンポーネント・インスタンスがアップグレードされ、通常の操作に戻ると完了します。

コンピュート・インスタンスの可用性 🔗

コンピュート・インスタンスの場合、高可用性とは、基礎となるインフラストラクチャに障害が発生した場合のインスタンスの自動リカバリを指します。コンピュート・ノード、ハイパーバイザおよびコンピュート・インスタンスの状態は継続的に監視されます。各コンピュート・ノードは5分間隔でポーリングされます。コンピュート・インスタンスが停止すると、デフォルトでは、システムによって自動的にリカバリが試行されます。

デフォルトでは、システムは選択したフォルト・ドメインのインスタンスを再起動しようとしますが、選択したフォルト・ドメインで使用可能なリソースが不足している場合は、他のフォルト・ドメインのインスタンスを再起動します。選択したフォルト・ドメインは、インスタンス構成で指定されているフォルト・ドメインです。

計画外の再起動によってコンピュート・ノードがダウンした場合、コンピュート・ノードが正常に通常の操作に戻ると、インスタンスは再起動されます。次のポーリング間隔で、実行中であるはずの状態が異なるインスタンスが見つかった場合は、デフォルトでstartコマンドが再度発行されます。いずれかのインスタンスが停止し、その状態のままになっている場合、ハイパーバイザはそれらの再起動を最大5回試行します。コンピュート・ノードが使用不可になる前に実行されなかったインスタンスは、コンピュート・ノードが稼働して再度稼働しているときに停止したままになります。

コンピュートノードは、データネットワークから切断されているか、または約5分間電源切断状態になっていると、障害があるとみなされます。この5分間のタイムアウトは、ポーリング試行の失敗に2回対応し、コンピュート・ノードをFAIL状態にし、そのエージェントをEVACUATING状態にするためのしきい値です。この状態は、リブート移行を開始する前に必要です。

リブート移行とは、障害が発生したコンピュートノードのすべてのコンピュートインスタンスが停止され、別のコンピュートノード上で再起動されることを意味します。移行が完了すると、障害が発生したコンピュートノードのエージェントは、インスタンスが退避されたことを示します。コンピュート・ノードが最終的に正常に再起動した場合は、失効したすべてのインスタンス構成および関連する仮想ディスクを削除するクリーンアップ・プロセスを実行する必要があります。クリーンアップ後、コンピュート・ノードはコンピュート・インスタンスを再度ホストできます。

リブート移行全体の間、インスタンスは「移動中」構成状態のままです。移行が完了すると、インスタンス構成の状態が「実行中」に変更されます。障害の前に停止されたインスタンスは、どのコンピュート・ノードにも関連付けられていないため、移行されません。

サービスの継続性 🔗

Compute Cloud@Customerには、高可用性をさらに強化する複数の機能があります。システムのあらゆるレベルでの健全性監視が重要な要素です。診断およびパフォーマンスのデータは、すべてのコンポーネントから収集され、一元的に格納および処理され、Oracle担当者が使用できるようになります。

障害発生時のデータ損失を軽減し、システムおよびサービス構成のリカバリをサポートするために、一貫性のある完全なバックアップが定期的に作成されます。

オプションで、Compute Cloud@Customerにデプロイされたワークロードを、ディザスタ・リカバリの実装を通じてダウンタイムやデータ損失から保護できます。これを実現するには、2つのCompute Cloud@Customerインフラストラクチャを異なるサイトに設定し、相互にレプリカとして構成する必要があります。障害回復制御下のリソースは、各システムの ZFS Storageアプライアンスに別々に格納され、2つの間でレプリケートされます。インシデントが1つのサイトで発生すると、最小限の停止時間でレプリカ・システムで環境が起動されます。ディザスタ・リカバリは、すべてのクリティカルな本番システムに実装することをお薦めします。