ブート順序およびヘルス・チェック

電源が最初の管理ノードに適用されると、サーバーの起動に約5分かかります。 Oracle Linux 6オペレーティング・システムのロード中に、Apache webサーバーが起動されます。これによって、静的なようこそページが表示され、管理者はアプライアンス管理ネットワークに接続しているワークステーションから参照できます。

サーバーが実行レベル3 (ネットワークを搭載したマルチユーザー・モード)になると、必要なOracle Linuxサービスが起動します。 この時点で、管理ノードは一連のシステム・ヘルス・チェックを実行します。 これは、すべての予測インフラストラクチャ・コンポーネントが、アプライアンス管理ネットワークおよびラック・ユニット番号と固定IPアドレスで識別される正しい事前定義のロケーションに存在することを検証します。 次に、管理ノードは管理NFSエクスポート用のZFSストレージ・アプライアンスと、OCFS 2ファイル・システムを含む管理iSCSI LUNを調べます。 ストレージとそのアクセス・グループがファクトリで構成されています。 ヘルス・チェックで問題が検出されなかった場合は、ocfs2およびo2cbサービスが自動的に起動します。

管理クラスタの設定

共有iSCSI LUN上のOCFS 2ファイルシステムの準備が完了し、o2cbサービスが正常に起動されると、管理ノードがクラスタに参加できます。 その間に、1つ目の管理ノードで2つ目の管理ノードも起動され、これは同じ構成になります。 両方の管理ノードが最終的にクラスタに参加しますが、最初の管理ノードは、分散ロック管理(DLM)を使用して共有OCFS2ファイル・システムに対する排他的ロックを取得します。 2番目の管理ノードは永続スタンバイのままで、最初の管理ノードが停止するか、ロックを解放する場合にのみロックを引き継ぎます。

管理クラスタの両方のメンバー間で相互排他性が確立されていると、マスター管理ノードでは、dhcpd、Oracle VM ManagerおよびOracle Private Cloud Applianceデータベースなどの残りのOracle Private Cloud Applianceサービスが引き続きロードされます。 管理クラスタの仮想IPアドレスもオンラインになり、Oracle Private Cloud Applianceダッシュボードがアクティブ化されます。 静的Apache webサーバーは、仮想IPでダッシュボードにリダイレクトされます。管理者は、アプライアンス・ラック・コンポーネントのステータスのライブ・ビューにアクセスできます。

dhcpdサービスが開始されると、システム状態が「準備状況のプロビジョニング」に変わります(これは、フレーム構造以外のコンポーネントを検出する準備ができたことを意味します)。

ノード・マネージャ

コンピュート・ノードを検出するために、マスター管理ノード上のノード・マネージャはDHCPサーバーとノード・データベースを使用します。 ノード・データベースは、管理NFS共有にあるBerkeleyDBタイプのデータベースで、MACアドレス、IPアドレス、ホスト名などシステム内の各ノードの状態および構成の詳細が含まれます。 ノードの検出プロセスは、ILOMからのDHCPリクエストで始まります。 ほとんどの検出およびプロビジョニング・アクションは同期的であり、順次発生しますが、インストールおよび構成プロセスの消費時間は並行して非同期で起動されます。 DHCPサーバーは、事前に割り当てられているIPアドレスをアプライアンス管理ネットワーク(192.168.4.0/24)に渡します。 ノード・マネージャは、Oracle Private Cloud Applianceで使用するための有効なサービス・タグがノードにあることを検証すると、一連のプロビジョニング・タスクを起動します。 必要なすべてのソフトウェア・リソースがファクトリでZFSストレージ・アプライアンスにロードされていること。

プロビジョニング・タスク

ステータスの変更を使用して、ノード・データベース内でプロビジョニング・プロセスが追跡されます。 次のプロビジョニング・タスクは、ノード・ステータスが前のタスクが正常に完了したことを示す場合のみ開始できます。 有効なノードごとに、ノード・マネージャはPXE構成の作成から開始し、Oracle Private Cloud Applianceランタイム・サービスを使用してノードの起動を強制します。 ハードウェアRAID-1の構成が適用されると、ノードが再起動され、Oracle VM Serverのkickstartインストールが実行されます。 Crucialカーネル・モジュールおよびホスト・ドライバがインストールに追加されます。 インストール・プロセスの最後に、ネットワーク構成ファイルが更新され、必要なすべてのネットワーク・インタフェースを起動できます。

内部管理ネットワークが存在する場合、コンピュート・ノードは、このネットワークを介して通信するためにOracle VM Agentを最後に再構成するために1度リブートされます。 この時点で、ノードはOracle VM Manager検出の準備ができています。

Oracle VM環境が大きくなり、さらに多くの仮想マシンと、接続している多数の異なるVLANが含まれると、管理操作および登録されたイベントの数が急速に増加します。 このアクティビティが多いシステムでは、Oracle VM Managerがアクティブな同じ管理ノードを介してプロビジョニング・タスクが実行されるため、コンピュート・ノードのプロビジョニングに大幅に時間がかかります。 機能に影響はありませんが、プロビジョニング・タスクの完了には数時間かかる可能性があります。 システム・アクティビティが最も低い時間にコンピュート・ノード・プロビジョニングを実行することをお薦めします。

Oracle VM Serverプール

ノード・マネージャは、Oracle VM環境に参加する準備ができている、完全にインストールされたコンピュート・ノードを検出すると、必要なOracle VM CLIコマンドを発行して新しいノードをOracle VMサーバー・プールに追加します。 最初のノードを検出すると、システムは、適切なネットワークを使用してクラスタ化されたOracle VMサーバー・プールを構成し、共有ストレージにアクセスします。 Oracle VM Managerに追加されたすべてのコンピュート・ノードで、IPMI構成は、便利なリモートの電源オン/オフを有効にするために格納されます。

Oracle Private Cloud Applianceは、最初に1つのラック内のすべてのコンピュート・ノードが高可用性(HA)と分散リソース・スケジュール(DRS)が有効になっている単一のクラスタ化サーバー・プールに属すると想定します。 すべてのコンピュート・ノードがOracle VMサーバー・プールに参加している場合、アプライアンスは「準備完了」状態であり、仮想マシン(VM)をデプロイできることを意味します。

拡張コンピュート・ノード

拡張コンピュート・ノードがインストールされると、ILOMからのDHCPリクエストに基づいてその存在が検出されます。 新しいサーバーがOracle Private Cloud Applianceノードとして識別されると、new状態でノード・データベースにエントリが追加されます。 これにより、初期化およびプロビジョニング・プロセスがトリガーされます。 新しいコンピュート・ノードは、管理者が手動で再構成する必要なく、実行中のシステムの容量を拡張するためにシームレスに統合されています。

同期サービス

プロビジョニング・プロセスの一環として、多数の構成設定が、グローバルに、または個別のコンポーネント・レベルで適用されます。 管理者が表示可能なものもあれば、システム全体で表示されるものもあります。 アプライアンスのライフ・サイクル全体を通して、ソフトウェアの更新、容量拡張、および構成の変更が、異なる時点で発生します。 たとえば、拡張コンピュート・ノードには、環境内にすでに使用されているサーバーと比較して異なるハードウェア、ファームウェア、ソフトウェア、構成およびパスワードが含まれており、実行中のシステムの設定と一致しない出荷時のデフォルト設定があります。 管理ノードに実装された同期サービスを使用して、Oracle Private Cloud Appliance環境内の異種のコンポーネント・セット間で構成可能なパラメータを設定およびメンテナンスできます。 容量の拡張または保守の場合に新しいシステム・コンポーネントを統合できるため、管理者は手動操作が必要なときにプロセスを効率化できます。 CLIは、同期サービスの公開された機能へのインタフェースを提供します。