高可用性

ハードウェアの冗長性

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

システム全体のデータ接続は、リーフ・スイッチとスパイン・スイッチの冗長ペアに基づいて構築されます。リンクアグリゲーションは、スイッチポート、ホスト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つの間で複製されます。あるサイトでインシデントが発生すると、環境は最小限の停止時間でレプリカ・システム上で起動されます。ディザスタ・リカバリは、すべてのクリティカルな本番システムに実装することをお薦めします。