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

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

  • 分析

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

  • データベース

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

  • ロード・バランシング

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

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