アーキテクチャおよび設計

Oracle Private Cloud Applianceの概要

Oracle Private Cloud Applianceは、オンプレミス・ネットワークの安全な環境内で、包括的なクラウド・インフラストラクチャ・サービス・スイートを提供するように設計されています。システムは、必要なすべてのハードウェアおよびソフトウェア・コンポーネントを統合し、Oracleエンジニアが最適なパフォーマンスを実現するようにテスト、構成およびチューニングされています。基本的に、最も幅広いワークロードをサポートする、柔軟で汎用のIaaS (Infrastructure as a Service)ソリューションです。そのプラガブル・プラットフォームは、インフラストラクチャの上にPaaS (Platform as a Service)およびSaaS (Software as a Service)ソリューションをレイヤー化するための優れた基盤を提供します。

このリリースのPrivate Cloud Applianceは、Oracleパブリック・クラウド・ソリューションOracle Cloud InfrastructureとのAPI互換性を提供します。コアIaaSサービスには、Oracle Cloud Infrastructureと同じメソッド、ツールおよびインタフェースを使用してアクセスします。 Private Cloud Applianceのインストールは、顧客リージョンを表します。ワークロードはプライベート・クラウド環境とパブリック・クラウド環境の間で移植できますが、プライベート・クラウドはOracle Cloud Infrastructureから切断されるため、互換性のある一連のサービスをホストするために独自のコントロール・プレーン・コンポーネントが実行されます。

Private Cloud Applianceは、エンジニアド・システムとして、最高のビジネス継続性と保守性要件に準拠しています。すべてのコンポーネントを監視し、潜在的な問題を検出し、アラートを送信し、サービス・リクエストを自動的に記録する機能があります。それ以降のトラブルシューティングおよび修復は、環境の稼働時間に影響を与えずに実行できます。

システムのアップグレードは、中断を最小限に抑え、可用性を最大化するためにも設計されています。ヘルス・チェックは、すべてのコンポーネントが許容可能な状態であることを確認するために、アップグレードの前に実行されます。アップグレード・プロセスはモジュール化されており、コンポーネントを使用できます - ファームウェア、オペレーティング・システム、コンテナ化されたサービス、システム・メイン・データベースなど - 個別にアップグレードするか、統合マルチ・コンポーネント・ワークフローとしてアップグレードします。

Oracle Cloud Infrastructureとの互換性

Private Cloud Applianceの主な目的は、独自のオンプレミス・ネットワークの安全性から、独自のファイアウォールの背後でコアOracle Cloud Infrastructureサービスを消費できるようにすることです。インフラストラクチャ・サービスは、PaaSおよびSaaSソリューションを構築するための基盤を提供します。デプロイされたワークロードは、最小限の変更または不要の変更で、パブリック・クラウド・インフラストラクチャとプライベート・クラウド・インフラストラクチャ間で移行できます。このため、Private Cloud ApplianceはOracle Cloud InfrastructureとのAPI互換性を提供します。

ラック・スケール・システムとして、Private Cloud Applianceは、パブリック・クラウド設計の物理階層に沿った、Oracle Cloud Infrastructureの最小デプロイ可能ユニットとみなすことができます:

階層コンセプト	Oracle Cloud Infrastructure設計	Oracle Private Cloud Applianceマッピング
レルム	レルムはリージョンのスーパーセットで、Oracleクラウドの物理的な下位区分が最も高くなります。レルム間フィーチャはありません。 Oracle Cloud Infrastructureは現在、商用リージョン用のレルムとGovernment Cloudリージョン用のレルムで構成されています。	レルムの概念はPrivate Cloud Applianceに存在しますが、実際的な機能はありません。これにより、アプライアンスは任意のレルムに参加できます。
Region	リージョンは地理的な領域です。 Oracle Cloud Infrastructureリージョンは、少なくとも3つのアベイラビリティ・ドメインで構成されます。リージョン間でデータとリソースを移行またはレプリケートできます。	Private Cloud Applianceは、単一のリージョンとして設計されています。このプライベート・リージョンは他のシステムから切断されているため、実用的な機能はありません。かわりに、ドメイン構成で使用され、リージョンおよびレルムの値にマップされます。
可用性ドメイン	アベイラビリティ・ドメインは1つ以上のデータ・センターで構成されます。アベイラビリティ・ドメインは相互に分離され、独立した電力および冷却インフラストラクチャを持ち、内部ネットワーキングを分離しています。あるアベイラビリティ・ドメインでの障害が、他のドメインに影響する可能性が非常に低い。同じリージョン内のアベイラビリティ・ドメインは、暗号化されたネットワークを介して高帯域および低レイテンシで相互接続されます。これは、高可用性とディザスタ・リカバリを提供する際の重要なファクタです。	各Private Cloud Applianceは、可用性ドメインとして構成されます。複数のインストールが相互に独立している: 同じリージョン内のアベイラビリティ・ドメインとして機能しません。
フォルト・ドメイン	フォルト・ドメインは、アベイラビリティ・ドメイン内のインフラストラクチャ・コンポーネントをグループ化したものです。目的は、障害またはメンテナンスのためにダウンタイム・イベントを分離し、他のフォルト・ドメイン内のリソースが影響を受けないことを確認することです。各アベイラビリティ・ドメインに3つのフォルト・ドメインが含まれます。フォルト・ドメインはアンチ・アフィニティを提供: 同じ物理ハードウェアで実行されないようにインスタンスを分散する機能。	Private Cloud Applianceはパブリック・クラウド設計に準拠: 各アベイラビリティ・ドメインに3つのフォルト・ドメインが含まれます。フォルト・ドメインは、1つ以上の物理コンピュート・ノードに対応します。

Private Cloud Applianceは、Oracle Cloud Infrastructureの論理パーティション化とも連携します。アプライアンスのアンダー・レイ・ネットワークへのトンネリングとカプセル化によって相互に安全に分離される複数のテナンシをサポートします。テナンシは同じ物理ハードウェアでホストされますが、特定のテナンシに属するユーザーおよびリソースは、他のテナンシと対話できません。さらに、「コンピュート・エンクレーブ」 - すべてのテナンシをまとめて参照し、その中に作成および管理されるクラウド・リソース - 、アプライアンス・インフラストラクチャが制御される「サービス・エンクレーブ」から論理的に分離されます。詳細は、「エンクレーブとインタフェース」を参照してください。

「コンピュート・エンクレーブ」インタフェースは、Oracle Cloud Infrastructureと同じ方法でアクセスを提供します。 CLIは同一ですが、ブラウザUIは実質的に同じユーザー・エクスペリエンスを提供します。 APIサポートも同じですが、Private Cloud Applianceが提供するクラウド・サービスのサブセットに制限されます。

サポートされているAPIの一貫性は、パブリック・クラウド・プラットフォームとプライベート・クラウド・プラットフォーム間の互換性において重要なファクタです。これにより、コア・クラウド・サービスがリソースと構成も同様にサポートされます。具体的には、Private Cloud Applianceはネットワーキングとストレージに対して同じ論理構造をサポートし、ユーザー・アイデンティティとアクセスを同じ方法で管理し、Oracle Cloud Infrastructureと同じコンピュート・シェイプとイメージをインスタンス・デプロイメントに提供します。そのため、プライベート・クラウド環境に設定されたワークロードは、Private Cloud Applianceに簡単に移植でき、その逆も同様です。ただし、プライベート・クラウド環境の切断された動作モードのため、ワークロードはオフラインで移行する必要があります。

エンクレーブとインタフェース

クラウド・ユーザーのパースペクティブから見ると、Private Cloud Appliance 「コンピュート・エンクレーブ」はOracle Cloud Infrastructureとほぼ同じ操作性を提供します。ただし、アプライアンスでは、「サービス・エンクレーブ」と呼ばれる独自の個別の管理領域も実行されます。この項では、異なるユーザー・グループと、明確に異なるアクセス・プロファイルを持つ管理者を対象とした、エンクレーブとそのインタフェース間の境界について説明します。

エンクレーブ境界

「コンピュート・エンクレーブ」は、Oracle Cloud Infrastructureとの互換性を最大にするために意図的に設計されています。「コンピュート・エンクレーブ」のユーザーには、クラウド・リソースを作成および管理するための特定の権限があります。通常、これらの権限はグループ・メンバーシップに基づきます。「コンピュート・エンクレーブ」は、ワークロードが作成、構成およびホストされる場所です。ユーザーの処分における主要なビルディング・ブロックは、コンピュート・インスタンスと関連するネットワーク・リソースおよびストレージ・リソースです。

コンピュート・インスタンスは、事前構成済のオペレーティング・システムおよびオプションの追加ソフトウェアが含まれる「コンピュート・イメージ」から作成されます。コンピュート・インスタンスには、CPUやメモリーなどの仮想ハードウェア・リソースのテンプレートである特定の「シェイプ」があります。最小限の操作では、コンピュート・インスタンスにブート・ボリュームと仮想クラウド・ネットワーク(VCN)への接続が必要です。ワークロード用の仮想インフラストラクチャの構築を続けるにつれ、より多くのコンピュート・インスタンスの追加、プライベートおよびパブリック・ネットワーク・インタフェースの割当て、NFS共有またはオブジェクト・ストレージ・バケットの設定などを行うことができます。これらのリソースはすべてOracle Cloud Infrastructureと完全に互換性があり、プライベート・クラウド環境とパブリック・クラウド環境の間で移植できます。

「サービス・エンクレーブ」は、アプライアンス・インフラストラクチャが制御されるシステムの一部です。アクセスは厳密に監視され、特権管理者に制限されます。 3つの管理ノードのクラスタで実行されます。 Private Cloud ApplianceはOracle Cloud Infrastructureから操作的に切断されるため、アプライアンスの設計およびスケールに固有のコントロール・プレーンが必要です。 APIはPrivate Cloud Applianceに固有で、アクセスは厳密に制御されています。「サービス・エンクレーブ」が提供する機能には、ハードウェアおよび容量の管理、サービスの提供、サービスおよびサポートのためのモニタリングおよびツールが含まれます。

両方のエンクレーブが互いに厳密に分離されています。各enclaveは、独自のインタフェース・セットを提供: web UI、CLI、およびエンクレーブごとのAPI。「サービス・エンクレーブ」へのフル・アクセスを持つ管理者アカウントには、「コンピュート・エンクレーブ」には権限がありません。管理者は、初期アクセス用のプライマリ・ユーザー・アカウントを持つテナンシを作成しますが、テナンシのコンテンツおよびアクティビティに関する情報はありません。「コンピュート・エンクレーブ」のユーザーには、クラウド・リソースを使用、管理および作成する権限が付与されますが、ユーザーが作業するテナンシ、または仮想リソースが存在するハードウェアを制御することはできません。

アクセス・プロファイル

各エンクレーブには独自のインタフェースがあります。「コンピュート・エンクレーブ」にアクセスするには、「コンピュートWeb UI」またはOCI CLIを使用します。「サービス・エンクレーブ」にアクセスするには、「サービスWeb UI」または「サービスCLI」を使用します。

ノート:

webブラウザを使用して、両方のエンクレイブのグラフィカル・インタフェースにアクセスします。サポート情報については、「Oracleソフトウェアwebブラウザのサポート・ポリシー」を参照してください。

アカウントのプロパティによって、実行が承認されている操作と、表示、管理または作成できるリソースが決まります。 web UIを使用する場合もCLIを使用する場合も、権限に関して違いはありません。すべての操作によって、エンクレーブの3番目の中央インタフェースへのリクエストが発生: API。 Service APIまたは「コンピュートAPI」からの受信リクエストは評価され、その後APIサービスによって認可または拒否されます。

ユーザーの様々なカテゴリが、異なる目的でアプライアンスと対話します。エンクレーブ・レベルでは、アプライアンス・インフラストラクチャの管理者と、一方の手のテナンシ内のクラウド・リソースを管理するユーザーを区別します。各エンクレーブには、異なる権限を提供する異なるアクセス・プロファイルが存在します。

「サービス・エンクレーブ」では、管理者の選択チームのみにフル・アクセス権を付与する必要があります。システムのモニタリング、容量計画、可用性、アップグレードなど、アクセスが制限されているその他の管理者ロールがあります。管理者ロールの詳細は、「管理者アクセス」を参照してください。 Oracleが「サービス・エンクレーブ」にアクセスしてサービスおよびサポート操作を実行する場合は常に、フル・アクセス権を持つアカウントを使用する必要があります。

テナンシが作成されると、「コンピュート・エンクレーブ」ユーザー・アカウントは1つのみになります: テナンシ管理者。テナンシ内のすべてのリソースへの完全なアクセス権を持ちます。実際には、テナンシへのアクセス権を持つすべての追加アカウントは、通常の「コンピュート・エンクレーブ」ユーザー・アカウントであり、グループ・メンバーシップやポリシー定義に応じて、制限の多い権限または少ない権限を持ちます。テナンシ管理者が、追加のユーザー・アカウントおよびユーザー・グループを設定し、リソース組織および管理戦略を定義し、その戦略を適用するポリシーを作成するタスクです。

リソース管理戦略が定義され、ユーザー、グループおよびコンパートメントの基本構成が存在すると、テナンシ管理者は、昇格された権限を持つ他のユーザーに責任を委任できます。管理者のグループが組織全体のリソースを管理できるようにする単純なポリシーを使用するか、より詳細なアプローチを使用するかを決定できます。たとえば、チームまたはプロジェクトごとにコンパートメント内のリソースを編成し、コンパートメント管理者がそのリソースを管理できるようにします。さらに、ネットワーク・リソースとストレージ・リソースをそれぞれネットワーク管理者とストレージ管理者によって制御される独自のコンパートメント内に格納しておくこともできます。 Identity and Access Managementサービスのポリシー・フレームワークには、リソースを編成し、リソースへのアクセスを制御するための様々なオプションが用意されています。詳細は、「Identity and Access Management概要」の章を参照してください。

APIと直接対話するスクリプトまたは自動化ツールを作成する場合は、開発者が認証および認可の原則と、完全分離を理解していることを確認してください。基本APIリファレンス・ドキュメントは、両方のエンクレーブで使用可能です。

API参照を表示するには、「コンピュートWeb UI」または「サービスWeb UI」のベースURLに/api-referenceを追加します。たとえば:

「サービスWeb UI」ベースURL : https://adminconsole.myprivatecloud.example.com.

「サービス・エンクレーブ」 APIリファレンス : https://adminconsole.myprivatecloud.example.com /api-reference.
「コンピュートWeb UI」ベースURL : https://console.myprivatecloud.example.com.

「コンピュート・エンクレーブ」 APIリファレンス : https://console.myprivatecloud.example.com /api-reference.

階層化されたアーキテクチャ

Oracle Private Cloud Applianceのアーキテクチャでは、階層化アプローチが使用されます。基本的には、コア・プラットフォームが構築されるハードウェア・コンポーネントです。これにより、異なるユーザー・グループに公開される管理および操作サービスのフレームワークが提供されます。レイヤーは統合されていますが、単体ではありません: これらは、互換性を維持しているかぎり、異なる速度でさらに開発できます。たとえば、新しいタイプのサーバー・ハードウェアをサポートしたり、ストレージ機能を拡張したりすることは、個別に適用したり、コントローラ・ソフトウェア・スタック全体を再デプロイしたりすることなく、拡張機能です。

ハードウェア層

ハードウェア層には、すべての物理システム・コンポーネントとそのファームウェアとオペレーティング・システムが含まれています。

3つの管理ノードは、コントローラ・ソフトウェアのベース環境を実行するクラスタを形成します。
コンピュート・ノードは、コンピュート・インスタンスをホストするための処理能力を提供します。
ストレージ・アプライアンスは、コンピュート・インスタンスによって使用されるストレージ・リソースのディスク領域を提供します。また、アプライアンスで内部的に操作するために必要なストレージ領域も提供されます。
ネットワーク・スイッチは、すべてのコンポーネントとアップリンク間の物理接続をパブリック(データセンター)ネットワークに提供します。

プラットフォーム・レイヤー

Private Cloud Applianceは、サービス・ベースのデプロイメント・モデルを使用します。製品は、サービスとして実行される機能領域(それぞれ独自のコンテナ内)に分割されます。プラットフォームは、このモデルのベースを提供します。 Oracle Cloud Native Environmentの機能を利用して、管理ノード・クラスタは、イメージ・レジストリもホストするコンテナ化されたサービスのデプロイメントを編成します。

さらに、このプラットフォームは、他のすべてのサービスに必要な数多くの基本サービスを提供しています: メッセージ転送、シークレット管理、データベース・アクセス、ロギング、モニタリングなど。これらの基本的なサービスは、プラットフォーム上にデプロイされているすべてのサービスを同じ方法でそれらに接続できるように標準化されており、新しいサービス統合が簡単かつ高速になります。

また、このプラットフォームは、ハードウェア管理において中心的なロールを果たし、ハードウェア層とサービス間のデータ交換を管理します。ハードウェア・レイヤーに関する情報、およびそのレイヤーに加えた変更は、インベントリを最新の状態に保つためにサービス・レイヤーと通信する必要があります。サービス・レイヤーで操作を実行する場合は、コマンドをハードウェアに渡すためにインタフェースが必要です。この目的のために、プラットフォームには内部でのみ公開され、最高の権限を必要とする、緊密に保護されたAPIがあります。このAPIは、サーバーILOMやストレージ・コントローラ、インベントリ・データベースおよびコンテナ・オーケストレーション・ツールなどの管理インタフェースと相互作用します。

アプライアンス・アーキテクチャでのこのレイヤーの詳細は、「プラットフォーム・レイヤーの概要」を参照してください。

インフラストラクチャ・サービス・レイヤー

このレイヤーには、プラットフォーム上にデプロイされているすべてのサービスが含まれます。機能的に異なる2つのグループを形成: ユーザー・レベルのクラウド・サービスと管理サービス。

クラウド・サービスは、クラウド環境のユーザーに機能を提供し、対応するOracle Cloud Infrastructureサービスと同様に動作します。「コンピュート・エンクレーブ」を構成し、コンピュート・インスタンスおよび関連リソースを介した顧客ワークロードのデプロイメントを有効にします。クラウド・サービスには、コンピュートおよびストレージ・サービス、アイデンティティおよびアクセス管理、ネットワーキングが含まれます。

管理サービスは、アプライアンスの管理者に内部的に、または制限されています。これにより、クラウド・サービスの運用が可能になり、サポートが提供されます。「サービス・エンクレーブ」を構成します。管理者操作には、システム初期化、コンピュート・ノードのプロビジョニング、容量拡張、テナンシ管理、アップグレードなどがあります。 Oracle Cloud Infrastructureでは、これらの操作に同等の外部化はありません。Oracleはインフラストラクチャ管理者のロールを実行します。

プラットフォーム・レイヤーの概要

Oracle Private Cloud Applianceアーキテクチャでは、プラットフォーム・レイヤーは、オンプレミス・クラウド・サービスの標準化されたインフラストラクチャを提供する部分です。ハードウェア・レイヤーを制御し、サービス・レイヤーを使用可能にし、セキュア・インタフェースを確立して、これらのレイヤーを統一的かつ一元的に操作できるようにします。インフラストラクチャ・サービス・レイヤーの共通コンポーネントと機能はプラットフォームに組み込まれているため、これらのマイクロサービスのデプロイメントを簡素化して迅速化できます。

基本的なサービス

オンプレミス・クラウド・サービスをデプロイするための基本インフラストラクチャの提供の中核的なロールを果たすために、プラットフォームは独自の基本的な内部サービスのセットに依存します。この項では、その機能について説明します。

ハードウェア管理

システムが初期化されると、低レベルのプラットフォーム・コンポーネントは、管理ノード・クラスタおよびコンピュート・ノードのプロビジョニングを編成します。このプロセスでは、ZFS Storage Applianceのコントローラを含むすべてのノードが、必要な管理ネットワークおよびデータ・ネットワークに接続されます。後の段階で追加のコンピュート・ノードをインストールすると、同じプロビジョニング・メカニズムによって新しいノードがグローバル・システム構成に統合されます。追加のディスク・トレイも、ストレージ・コントローラによって自動的に統合されます。

ハードウェアの管理の最初のステップは、ラック・コンポーネントのインベントリを作成することです。インベントリは、ラックに取り付けられているコンポーネントの仕様および構成の詳細を含む個別のデータベースです。システムに表示されたすべてのコンポーネントの履歴が保持され、アクティブなシステム・コンポーネントから取得された最新情報で継続的に更新されます。

サービス・レイヤーといくつかのシステム・コンポーネントには、ハードウェアと対話できるようにハードウェア・インベントリの詳細が必要です。たとえば、コンポーネント・アップグレードまたはサービス・デプロイメント・プロセスでは、指示をハードウェア・レイヤーに送信し、レスポンスを受信する必要があります。同様に、コンピュート・インスタンスを作成する場合、インスタンスおよび関連するネットワーク・リソースとストレージ・リソースを起動するために、コンピュート・ノード、ネットワーク・コンポーネントおよびストレージ・アプライアンスのレベルで一連の操作を実行する必要があります。

ハードウェア層を対象としたすべての手順は、ハードウェア管理サービスで一元化されています。ハードウェア層へのゲートウェイとして機能します。ハードウェア管理サービスでは、専用で高度に保護されたプラットフォームAPIを使用して、ハードウェア・コンポーネントに対して必要なコマンドを実行: サーバーILOM、ZFSストレージ・コントローラなど。このAPIは、管理ノードのオペレーティング・システムで直接実行されます。マイクロサービスがデプロイされるコンテナ・オーケストレーション環境から分離されます。

サービス・デプロイメント

Oracle Private Cloud Applianceは、詳細なサービス・ベースの開発モデルに従います。機能は、アーキテクチャ・レイヤー全体に存在し、システムの垂直ビューを表す個別のマイクロサービスに論理的に分割されています。サービスには、内部および外部化された機能があり、様々なレイヤーで相互に作用します。

これらのマイクロサービスは、Kubernetesコンテナにデプロイされます。コンテナ・ランタイム環境およびレジストリは、3ノード管理クラスタでホストされます。 Oracle Cloud Native Environmentは、マイクロサービス・コンテナの自動デプロイメント、構成および起動を含むコンテナ・オーケストレーションの基礎を提供します。設計上、すべてのマイクロサービスは、異なるKubernetesノードおよびポッドに分散する複数のインスタンスで構成されます。高可用性に加えて、Kubernetes設計では、各マイクロサービスのインスタンス間のロード・バランシングも提供されます。

コンテナ化により、サービスのアップグレードと機能拡張が簡素化されます。サービスは緊密に統合されていますが単体ではないので、互換性要件が考慮された状態では個々のアップグレードが可能です。マイクロサービスの新しいバージョンがコンテナ・レジストリに公開され、Kubernetesノードおよびポッドに自動的に伝播されます。

共通サービス・コンポーネント

コンポーネントや運用メカニズムの一部は、多くまたはすべてのサービスで必要になるため、それらをプラットフォームに構築する方が効率的であり、プラットフォーム上にデプロイする際にサービスを利用できるようにします。これらの共通コンポーネントによって、プラットフォーム上に構築された各サービスに一連の重要な機能が追加されるため、サービスの開発とデプロイメントが簡素化されます。

メッセージ・トランスポート

すべてのコンポーネントおよびサービスは、共通トランスポート・レイヤーに接続されます。これは、コンポーネントが標準化された形式で書き込まれたメッセージの送受信を可能にするメッセージ・ブローカです。このメッセージ転送サービスは、高可用性およびスループットを実現するために3つのインスタンスのクラスタとしてデプロイされ、認証およびトラフィックの暗号化にTLSを使用します。
シークレット・サービス

ログイン資格証明や証明書など、システム全体でプログラムで使用されるシークレットは、シークレット・サービスによって集中管理されます。すべてのコンポーネントとサービスは、シークレット・サービスのクライアントです: 認証に成功すると、クライアントは実行を試みるすべての操作で使用するトークンを受け取ります。シークレット・サービス内で定義されたポリシーによって、クライアントが実行を許可されている操作が決まります。シークレットは静的な方法で格納されず、存続期間に制限があり、動的に作成および管理されます。

システムの初期化中、シークレット・サービスは保護解除され、使用できるように準備されます。管理ノード上のアクティブ/スタンバイ・クラスタとして、プラットフォーム・レイヤーのコンテナ内にデプロイされますが、Kubernetesマイクロサービス環境の外側にもデプロイされます。これにより、シークレット・サービスは、マイクロサービスが使用可能になる前に、起動時にプラットフォーム・レイヤーに機能を提供できます。すべてのプラットフォーム・コンポーネントおよびマイクロサービスは、操作の実行を許可される前に、シークレット・サービスとの信頼関係を確立する必要があります。
ロギング

このプラットフォームは、システム全体で統合ロギングを提供します。このため、すべてのサービスおよびコンポーネントはFluentdデータ・コレクタと統合されます。 Fluentdは、事前構成された一連のログ・ファイルからデータを収集し、中央のロケーションに格納します。ログは、システム・コンポーネント、プラットフォーム・レイヤーおよびマイクロサービス環境から取得され、トレーサビリティおよび分析のためにLokiログ集計システムを介して使用可能になります。
監視

モニタリングの目的で、プラットフォームはPrometheusを使用してメトリック・データを収集します。 PrometheusはKubernetes環境内にデプロイされるため、マイクロサービス・メトリックに直接アクセスできます。ハードウェア・コンポーネントやコンピュート・インスタンスなどのKubernetes外のコンポーネントは、内部ネットワークおよびロード・バランサを介してメトリック・データをPrometheusに提供します。管理ノードおよびKubernetes自体は、Prometheusと直接通信できます。
分析

ロギングおよびモニタリング・データは、インフラストラクチャ管理者を対象としています。「サービスWeb UI」を使用してデータを参照できます。ここで、ヘルス・パラメータおよびパフォーマンス・パラメータに対する組込み問合せがダッシュボードでビジュアル化されます。適切な対策が取れるように、キーしきい値を超えるとアラートが送信されます。
データベース

すべてのサービスおよびコンポーネントは、共通の中央データベースにデータを格納します。 3つの管理ノードにデプロイされ、ベア・メタルで実行されているインスタンスを含むMySQLクラスタ・データベースです。可用性、ロード・バランシング、データ同期およびクラスタリングはすべて、MySQLクラスタの内部コンポーネントによって制御されます。最適なパフォーマンスのために、各管理ノードに直接アタッチされたZFS Storage Appliance上のLUNによってデータ・ストレージが提供されます。データベースへのアクセスは、シークレット・サービスによって厳密に制御されます。
ロード・バランシング

管理ノードは、3つのアクティブ・ノードのクラスタを形成します。つまり、すべてが同時にインバウンド接続を受信できます。イングレス・トラフィックは、フローティングIPアドレスをリスニングし、3つの管理ノードにトラフィックを分散する、静的に構成されたロード・バランサによって制御されます。ロード・バランサのインスタンスは、各管理ノードで実行されます。

同様に、すべてのコンテナ化されたマイクロサービスは、管理ノード・クラスタのコンテナ・オーケストレーション環境内で複数のポッドとして実行されます。 Kubernetesは、マイクロサービスへのイングレス・トラフィックのロード・バランシングを提供します。

物理リソース割り当て

ユーザーがコンピュート・インスタンスをデプロイしたとき - または仮想マシン - これらは、ハードウェア層によって提供される物理リソースを消費します。ハイパーバイザは、特定の構成で可能なかぎり最高のパフォーマンスを実現するアルゴリズムに基づいて、これらの物理リソースの割当てを管理します。

Private Cloud Applianceのコンピュート・ノードには、Non-Uniform Memory Access (NUMA)アーキテクチャがあります。つまり、各CPUは独自のローカル・メモリーだけでなく、他のCPUのメモリーにもアクセスできます。各CPUソケットとそれに関連付けられたローカル・メモリー・バンクは、「NUMAノード」と呼ばれます。同じNUMAノード内のローカル・メモリー・アクセスでは、常に高い帯域幅と低いレイテンシが提供されます。

一般に、NUMAのメモリー共有設計は、マルチプロセッサ・ワークロードのスケーリングに役立ちますが、複数のNUMAノードにリソースが分散されている場合、仮想マシンのパフォーマンスに悪影響を与えることもあります。ハイパーバイザ・ポリシーにより、仮想マシンCPUおよびメモリーが可能なかぎり同じNUMAノードに存在することが保証されます。特定のCPU固定技術を使用して、各仮想マシンは1つまたは複数のCPUコアに固定されるため、仮想マシンが実行されているNUMAノード上のメモリーにローカルでアクセスされます。ノード間メモリー・トランスポートは避けられるか、最小限保持されるため、コンピュート・インスタンスのユーザーは、システム全体の最適なパフォーマンスによるメリットがあります。

仮想マシンがハイパーバイザ・ホストの単一のNUMAノードに収まる場合、このNUMAノードは固定に使用されます(「厳格なピンニング」)。仮想マシンがハイパーバイザ・ホストの単一のNUMAノードに収まらないが、複数のNUMAノードに収まる場合、「固定」と呼ばれる複数のNUMAノードが固定に使用されます。

注意:

コンピュート・インスタンスへのCPUおよびメモリーの割当てを最適化するためにハイパーバイザを通じて適用されるCPU固定は、アプライアンス管理者、テナンシ管理者またはインスタンス所有者が構成することはできません。

Private Cloud Applianceは、プロビジョニング中にコンピュート・ノードのNUMAトポロジ(またはあるリリースから別のリリースへのアップグレード・パス)を検出し、コンピュート・インスタンスのデプロイメント中に使用するためにこの情報を格納します。各コンピュート・インスタンスのNUMAの詳細は、インスタンス構成に格納されます。 NUMA設定は、コンピュート・インスタンスが別のホスト・コンピュート・ノードに移行されたときに保持されますが、ターゲット・コンピュート・ノードがその特定の構成に対応できない場合、オーバーライドおよび動的に調整される可能性があります。

まだNUMA対応ではないPrivate Cloud Applianceで実行されているコンピュート・インスタンスは、システムにパッチが適用またはアップグレードされるとすぐに最適化ポリシーを利用できます。管理者がインスタンスをNUMAトポロジと連携させるためのアクションは必要ありません。既存のインスタンス構成は、プロセスの一部として互換性があります。

高可用性

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分間隔でポーリングされます。コンピュート・インスタンスが停止すると、自動的にリカバリするためのメジャーが使用されます。

内部の問題が原因で個々のコンピュート・インスタンスがクラッシュした場合、ハイパーバイザは同じコンピュート・ノード上のインスタンスを再起動しようとします。

計画外の再起動のためにコンピュート・ノードが停止した場合、コンピュート・ノードが正常に正常な操作に戻ると、同じホストのコンピュート・ノードでインスタンスを再起動します。次のポーリング間隔で、実行されているはずの状態が異なるインスタンスが見つかった場合、startコマンドが再度発行されます。いずれかのインスタンスがクラッシュしてその状態のままである場合、ハイパーバイザは最大5回再起動しようとします。コンピュート・ノードが使用できなくなる前に実行されていなかったインスタンスは、コンピュート・ノードが稼働し、再度実行されているときに停止したままになります。

ノート:

コンピュート・ノードが使用できなくなると、影響を受ける「実行」コンピュート・インスタンスは「コンピュートWeb UI」にその構成状態のままになります。コンピュート・ノードが再起動され、インスタンス・リカバリ操作が実行されると、その構成状態は「停止」に変わり、インスタンスが再度使用可能になると、最終的に「実行中」に戻ります。

障害が原因でコンピュート・ノードが失われた場合、そのコンピュート・インスタンスは他のコンピュート・ノードに退避されます。コンピュート・ノードは、データ・ネットワークから切断されたか、10分を超えて電源切断状態になった場合に失敗したとみなされます。この10分間のタイムアウトは、2回の失敗したポーリング試行に対応し、コンピュート・ノードをFAIL状態にし、そのエージェントをEVACUATING状態にするためのしきい値です。この条件は、「移行の再起動」を起動する前に必要です。

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

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

フォルト・ドメイン・プリファレンスは、インスタンスの移行に厳密に適用されます。容量が不十分なため、コンピュート・インスタンスを同じフォルト・ドメイン内の別のコンピュート・ノードに移行できない場合、インスタンスは停止されます。他のフォルト・ドメインは考慮されません。インスタンスは、別のフォルト・ドメインまたは現在のフォルト・ドメインで、十分なリソースが再度使用可能になった時点で手動で再起動する必要があります。

計画メンテナンスの場合、管理者はまず問題のコンピュート・ノードのプロビジョニングを無効にし、メンテナンス・ロックを適用する必要があります。コンピュート・ノードがプロビジョニング・ロック下にある場合、管理者は実行中のすべてのコンピュート・インスタンスを別のコンピュート・ノードにライブ移行できます。同じフォルト・ドメインで使用可能なターゲット・コンピュート・ノードがない場合は、インスタンスを別のフォルト・ドメインに移行できます。ライブ移行が失敗した場合、管理者はインスタンスを手動で停止し、別のコンピュート・ノードで再起動する必要があります。メンテナンス・モードは、コンピュート・ノードで実行中のインスタンスがなくなった場合にのみアクティブ化できます。このコンピュート・ノード上のすべてのコンピュート・インスタンス操作は無効になります。メンテナンス・モードのコンピュート・ノードはプロビジョニングまたはプロビジョニング解除できません。

サービスの継続性

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

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

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

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