プラットフォーム・レイヤーの主なプロパティ

基盤サービス

オンプレミス・クラウド・サービスを導入するためのベース・インフラストラクチャの提供というコア・ロールを達成するために、このプラットフォームは独自の基盤となる内部サービスのセットに依存しています。

ハードウェア管理

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

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

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

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

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

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と直接通信できます。

• 「アナリティクス」

  ロギングおよびモニタリング・データは、インフラストラクチャ管理者を対象としています。Service Web UIを介してデータを調べることができます。Service Web UIでは、状態およびパフォーマンス・パラメータに関する多数の組込み問合せがダッシュボードでビジュアル化されます。キーしきい値を超えるとアラートが送信されるため、適切な対策を講じることができます。

• データベース

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

• ロード・バランシング

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

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