高可用性

Oracleエンジニアド・システムは、単一障害点を排除するために構築されており、ハードウェアまたはソフトウェアの障害発生時、およびアップグレードやメンテナンス操作中に、システムおよびホストされたワークロードが稼働し続けることができます。 Private Cloud Applianceには、すべてのレベルのアーキテクチャに組み込まれた冗長性があります: ハードウェア、コントローラ・ソフトウェア、マスター・データベース、サービスなど。バックアップ、自動化されたサービス・リクエスト、オプションのディザスタ・リカバリなどの機能により、システムの保守性とサービスの継続性がさらに向上します。

ハードウェアの冗長性

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

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

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

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

システム可用性

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

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

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

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

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

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

デフォルトでは、システムは選択したフォルト・ドメイン内のインスタンスを再起動しようとしますが、選択したフォルト・ドメインで十分なリソースがない場合、他のフォルト・ドメイン内のインスタンスを再起動します。選択したフォルト・ドメインは、インスタンス構成で指定されたフォルト・ドメインです。選択したフォルト・ドメインでのみインスタンスを再起動するようにコンピュート・サービスを構成し、選択したフォルト・ドメインで十分なリソースを使用できない場合はインスタンスを停止できます。厳密なフォルト・ドメイン強制を構成するには、「Oracle Private Cloud Appliance管理者ガイド」の「ハードウェア管理」の章にある高可用性のためのコンピュート・サービスの構成を参照してください。

計画外のリブートのためにコンピュート・ノードが停止した場合、コンピュート・ノードが正常に通常の操作に戻ると、デフォルトではインスタンスが再起動されます。この動作は構成可能です。次のポーリング間隔で、デフォルトでは、インスタンスが実行中であるが別の状態にあることが検出された場合、startコマンドが再度発行されます。いずれかのインスタンスがクラッシュしてその状態のままである場合、ハイパーバイザは最大5回再起動しようとします。コンピュート・ノードが使用できなくなる前に実行されていなかったインスタンスは、コンピュート・ノードが稼働し、再度実行されているときに停止したままになります。

障害によりコンピュート・ノードが失われた場合、デフォルトでは、システムは実行中のコンピュート・インスタンスを障害が発生したコンピュート・ノードから他のコンピュート・ノードにライブ・マイグレーションしようとします。実際の動作は、コンピュート・サービスの構成方法によって異なります(「Oracle Private Cloud Appliance管理者ガイド」の「ハードウェア管理」の章にある「高可用性のためのコンピュート・サービスの構成」を参照)。

コンピュート・ノードは、データ・ネットワークから切断されているか、または約5分間電源切断状態になっていると、障害があるとみなされます。この5分間のタイムアウトは、コンピュート・ノードをFAIL状態にして、そのエージェントをEVACUATING状態にするしきい値です。この条件は、「リブート移行」を起動する前に必要です。

リブート移行は、障害が発生したコンピュート・ノードのすべてのコンピュート・インスタンスが停止され、別のコンピュート・ノードでリブートされることを意味します。移行が完了すると、障害が発生したコンピュート・ノード・エージェントは、インスタンスが退避されたことを示します。コンピュート・ノードが正常にリブートした場合は、古いインスタンス構成および関連する仮想ディスクをすべて削除するクリーン・アップ・プロセスを実行する必要があります。クリーンアップ後、コンピュート・ノードはコンピュート・インスタンスを再度ホストできます。 Computeサービスで自動解決が有効になっている場合、別のフォルト・ドメインに移行されたインスタンスを、選択したフォルト・ドメインに戻すことができます。

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

デフォルトでは、フォルト・ドメイン・プリファレンスはインスタンスの移行に厳密には適用されません。これは、「Oracle Private Cloud Appliance管理者ガイド」の「ハードウェア管理」の章にある「高可用性のためのコンピュート・サービスの構成」の説明に従って構成できるもう1つのプリファレンスです。

計画メンテナンスの場合、管理者はまず問題のコンピュート・ノードのプロビジョニングを無効にし、メンテナンス・ロックを適用する必要があります。コンピュート・ノードがプロビジョニング・ロック下にある場合、管理者は、「Oracle Private Cloud Appliance管理者ガイド」の「ハードウェア管理」の章にある「コンピュート・ノードからのインスタンスの移行」の説明に従って、実行中のすべてのコンピュート・インスタンスを別のコンピュート・ノードにライブ移行できます。メンテナンス・モードは、コンピュート・ノードで実行中のインスタンスがなくなった場合にのみアクティブ化できます。移行できないインスタンスを停止する強制オプションを指定できます。このコンピュート・ノード上のすべてのコンピュート・インスタンス操作は無効になります。メンテナンス・モードのコンピュート・ノードはプロビジョニングまたはプロビジョニング解除できません。

サービスの継続性

Private Cloud Applianceは、高可用性をサポートし、さらに強化するいくつかの機能を提供します。システムのすべてのレベルでのヘルス・モニタリングが重要なファクタです。診断およびパフォーマンス・データはすべてのコンポーネントから収集され、一元的に格納および処理され、標準ダッシュボードでのビジュアライゼーションの形式で管理者が使用できるようになります。また、メトリックが定義済のしきい値を超えるとアラートが生成されます。

Monitoringを使用すると、管理者はシステムの健全性を一定期間追跡し、必要に応じて予防措置を講じ、問題が発生したときにその問題に対応できます。さらに、My Oracle Supportに登録されているシステムは、障害モニタリングおよびターゲットのプロアクティブ・サポートのために収集された診断データを使用して、フォン・ホーム機能を提供します。登録されたシステムは、アプライアンスによって報告された特定の問題に対して、Oracleで自動サービス・リクエストを送信することもできます。

データ損失を軽減し、障害発生時にシステムおよびサービスの構成のリカバリをサポートするために、一貫性のある完全バックアップを定期的に実行します。クリティカル変更の直前にリストア・ポイントを作成するなど、バックアップを手動で実行することもできます。バックアップはZFS Storage Applianceの専用のNFS共有に格納され、必要に応じて「サービス・エンクレーブ」全体をリストアできます。

オプションで、アプライアンスにデプロイされているワークロードをディザスタ・リカバリの実装を通じて、ダウンタイムやデータ損失から保護できます。これを実現するには、2つのPrivate Cloud Applianceシステムを異なるサイトに設定し、相互にレプリカとして構成する必要があります。ディザスタ・リカバリ制御下のリソースは、各システムのZFS Storage Appliancesに個別に格納され、2つのシステム間でレプリケートされます。あるサイトでインシデントが発生した場合、環境は実際にはダウンタイムなしでレプリカ・システムで起動されます。 Oracleでは、すべてのクリティカルな本番システムにディザスタ・リカバリを実装することをお薦めします。