このコンテンツを正しく表示するには、JavaScriptが有効になっている必要があります

第1章 Oracle Private Cloud Applianceのコンセプト、アーキテクチャおよびライフ・サイクル

この章では、Oracle Private Cloud Applianceが構成されるハードウェアおよびソフトウェアと、仮想化プラットフォームとしてのデプロイ方法を説明します。

1.1 Oracle Private Cloud Applianceとは

クラウド・チャレンジへの応答

クラウド・アーキテクチャおよび仮想化ソリューションは、高度かつ複雑に実装できます。従来のデータ・センターで単一管理者が取得する必要がないスキル・セットが必要: システム・ハードウェア、オペレーティング・システム、ネットワーク管理、ストレージ管理、アプリケーション。これらのドメインの各1つに専門知識がないと、管理者は仮想化テクノロジの機能と利点を最大限に活用できません。多くの場合、これは不適切なパフォーマンスと信頼性をもたらし、ビジネスの柔軟性を損なう実装につながります。

技術的な複雑さと専門知識の不足によって作成されたリスクを考慮すると、企業は、ビジネス・ニーズにあわせて新しいインフラストラクチャをすぐにデプロイできなくなります。新しいシステムのデプロイメントに関与する管理、およびこれらのシステムを構成するための時間と作業量は、週数に比例することができます。物理デプロイメントに必要な時間の割合で、新しいアプリケーションを柔軟な仮想化環境にプロビジョニングすると、実質的な利点が得られます。

コンバージド・インフラストラクチャの高速デプロイメント

Oracle Private Cloud Applianceは、業界のアナリストがコンバージド・インフラストラクチャ・アプライアンスと呼ぶ、出荷時に事前構成されるハードウェア・アプライアンスの形式のインフラストラクチャ・ソリューションです。一連の個々のサーバー、ネットワーク・ハードウェア、ストレージ・プロバイダではなく、システム全体を1つの単位として操作できます。インストール、構成、高可用性、拡張およびアップグレードは自動化され、最適な度合いに編成されます。電源投入後数時間以内に、アプライアンスは仮想サーバーを作成できます。仮想サーバーは、一般に仮想アプライアンスから、Oracle VMテンプレート(個々の事前構成済VM)およびアセンブリ(事前構成済VMのグループ)の形式でデプロイされます。

完全なスタックのモジュール実装

Oracle Private Cloud Applianceが装備されたOracleでは、仮想アプライアンスを介して、ハードウェア、ソフトウェア、仮想化テクノロジおよび迅速なアプリケーション・デプロイメントの一意のフル・スタックが提供されます。このパッケージはすべて、単一のモジュラ製品および拡張可能製品にパッケージ化されています。最小構成は、インフラストラクチャ・コンポーネント、管理ノードのペア、および2つのコンピュート・ノードを含む基本ラックから構成されます。この構成は、一度に1つのコンピュート・ノードで拡張できます。移入済かどうかにかかわらず、すべてのラック・ユニットは、後で拡張コンピュート・ノードのオン・サイトのインストールを容易にするために、ファクトリで事前に有効化および事前構成済です。

使いやすさ

Oracle Private Cloud Applianceの主な価値の提案は、使いやすさと迅速なデプロイメントのために、コンポーネントとリソースを統合することです。 Windowsを含む最も広範なオペレーティング・システムおよびホストするアプリケーションをサポートするためには、汎用的なソリューションと考える必要があります。顧客は、既存のストレージをアタッチするか、Oracleまたはサードパーティから新しいストレージ・ソリューションを接続できます。

1.2 ハードウェア・コンポーネント

出荷時に設置されたコントローラ・ソフトウェア・リリース2.4.xを含む現在のOracle Private Cloud Applianceハードウェア・プラットフォームは、「図1.1」に識別されたハードウェア・コンポーネントが移入されたOracle Rackキャビネット1242ベースで構成されます。

図1.1 Oracle Private Cloud Applianceラックのコンポーネント

表1.1 図の説明

項目	数量	説明
A	2	Oracle ZFS Storage Appliance ZS7-2コントローラ・サーバー
B	2	管理ノードとして使用されるOracle Server X8-2
C	2-22	Oracle Server X9-2(仮想化コンピュート・ノードとして使用されます) (アプライアンスに22kVA PDUが装備されている場合、Oracle Server X9-2の電力要件には、コンピュート・ノードの最大数は22です。 15KVAを使用するPDUの最大コンピュート・ノード数は13コンピュート・ノードです。)
D	2	Cisco Nexus 9336C-FX2 Switch(リーフ/データ・スイッチとして使用)
E	1	Oracle ZFS Storage Appliance ZS7-2ディスク・シェルフ
F	1	Cisco Nexus 9348GC-FXPスイッチ
G	2	スパイン・スイッチとして使用されるCisco Nexus 9336C-FX2スイッチ

以前のハードウェア・コンポーネント世代のサポート

Oracle Private Cloud Applianceコントローラ・ソフトウェアの最新バージョンは、前述のハードウェア構成のみをサポートします。

1.2.1 管理ノード

各Oracle Private Cloud Applianceのインストールの中心は、管理ノードのペアです。これらはラック・ユニット5および6にインストールされ、高可用性のためのアクティブ/スタンバイ構成でクラスタを形成します: どちらのサーバーも同じサービスを実行でき、システム構成には同等にアクセスできますが、一方のサーバーはアクティブとして動作し、もう一方は、障害が発生した場合にアクティブな機能を引き継ぐ準備ができています。アクティブ管理ノードは必要なサービスの完全なセットを実行し、スタンバイ管理ノードはアクティブ・ロールに昇格されるまでサービスのサブセットを実行します。アクティブ・ロールは、iSCSI LUNのOCFS2 Distributed Lock Managementを介してブート時に決定され、どちらの管理ノードもラック内にインストールされているZFS Storage Applianceで共有されます。ラック・ユニットは下から上へ番号付けされ、下から4つはZFS Storage Applianceのコンポーネントによって占有されるため、アクティブ管理ノードは通常、ラック・ユニット5のサーバーです。アプライアンスをオンラインにするには、プロセス全体で管理者によって電源が投入される必要がある唯一のサーバーです。

Oracle Private Cloud Applianceで高可用性が実現される仕組みの詳細は、第1.5項、「高可用性」を参照してください。

Oracle Private Cloud Applianceに初めて電源を投入すると、データ・センターのネットワークから簡単に到達できるように、管理ノード・クラスタのファクトリ出荷時のデフォルトIP構成を変更できます。管理ノードは仮想IPを共有し、管理webインタフェースにアクセスできます。この仮想IPは、任意の時点でactiveロールを持つサーバーに割り当てられます。システムの初期化中、管理クラスタが正常に設定されると、アクティブ管理ノードはOracle VMおよび関連するMySQLデータベースに加えて、多数のOracle Linuxサービスをロード - network、sshd、ntpd、iscsiイニシエータ、dhcpdを含む - すべてのシステム・コンポーネントのプロビジョニングを編成します。プロビジョニング時には、すべてのネットワークおよびストレージが構成され、すべてのコンピュート・ノードが検出およびインストールされてOracle VMサーバー・プールに追加されます。すべてのプロビジョニング構成はファクトリで事前ロードされるため、顧客が変更することはできません。

プロビジョニング・プロセスの詳細は、第1.4項、「プロビジョニングおよびオーケストレーション」を参照してください。

1.2.2 コンピュート・ノード

仮想化プラットフォームは、Oracle Private Cloud Appliance内のコンピュート・ノードによって構成されます。コンピュート・ノードでは、ホストする仮想サーバーの処理能力とメモリー容量が提供されます。プロビジョニング・プロセス全体が管理ノードによってオーケストレーションされます: コンピュート・ノードは、Oracle VM Server 3.4.xおよびSoftware Defined Networkingの追加パッケージとともにインストールされます。プロビジョニングが完了すると、Oracle Private Cloud Appliance Controllerソフトウェアは、同じラックのすべてのコンピュート・ノードが同じOracle VMサーバー・プールの一部であることを想定します。コンピュート・ノードのハードウェア構成の詳細は、「Oracle Private Cloud Applianceインストレーション・ガイド」の「サーバー・コンポーネント」を参照してください。

Oracle Private Cloud ApplianceのDashboardを使用すると、管理者はコンピュート・ノードのヘルスとステータス、およびその他のすべてのラック・コンポーネントを監視し、特定のシステム操作を実行できます。仮想インフラストラクチャはOracle VM Managerで構成および管理されます。

Oracle Private Cloud Applianceでは、ビジネス・ニーズに従って増加できるモジュラ・コンピュート能力を提供しています。ベース・ラックの最小構成には2つのコンピュート・ノードのみが含まれますが、最大22個のコンピュート・ノードまで1つのノードで拡張できます。コンピュート・ノード構成の最大値とサポートされるラック・ロケーションの詳細は、「Oracle Private Cloud Applianceインストレーション・ガイド」の「コンピュート・ノード・ラックのロケーションのリファレンス」を参照してください。

ハードウェアの設置以外に、コンピュート・ノードを追加する場合、管理者による操作は必要ありません。新しいノードは、アクティブな管理ノードによって自動的に検出、電源投入、インストール、プロビジョニングされます。追加のコンピュート・ノードは既存の構成に統合されているため、Oracle VMサーバー・プールはより多くの仮想マシンの容量の増加を提供します。

さらに拡張オプションとして、コンピュート・ノードは、インストール済みのファイバ・チャネル・カードを使用してオーダーすることも、インストール後にファイバ・チャネル・カードを装備することもできます。これらのコンピュート・ノードがOracle Private Cloud Appliance環境に統合されると、ファイバ・チャネルHBAはデータセンター内の標準のFCスイッチおよびストレージ・ハードウェアに接続できます。外部FCストレージ構成は、Oracle VM Managerを介して管理されます。詳細は、「Oracle VM概要ガイド」の「ネットワークにアタッチされたファイバ・チャネル・ストレージ」に関する項を参照してください。

仮想化シナリオの多様性により、コンピュート容量をいくつかの仮想マシンとして定量化することは困難です。サイズ設定のガイドラインについては、「Oracle Private Cloud Applianceリリース・ノート」で「構成最大値」に適用される章を参照してください。

1.2.3 ストレージ・アプライアンス

1.2.3.1個のOracle ZFS Storage Appliance ZS7-2

Oracle Private Cloud Applianceコントローラ・ソフトウェアは、Oracle ZFS Storage Appliance ZS7-2のサポートを提供します。

1.2.3.1個のOracle ZFS Storage Appliance ZS7-2

Oracle ZFS Storage Appliance ZS7-2は、アプライアンス・ラックの下部に取り付けられた2つのコントローラ・サーバーと、途中のディスク・シェルフで構成され、アプライアンス全体に対してシステム・ディスクのロールを果たします。 Oracle Private Cloud Applianceソフトウェア用のストレージ領域を提供することが重要です。

ディスク領域の一部。デフォルトでは3 Tbが顧客の使用が可能になり、いくつかの仮想マシン、テンプレートおよびアセンブリがあるOracle VMストレージ・リポジトリに十分です。合計ディスク領域の残りの約100TBの部分も、仮想マシン・リソースのストレージ・リポジトリとして構成できます。外部ストレージとの追加の容量拡張も可能です。

Oracle ZFS Storage Appliance ZS7-2のハードウェア構成は、次のとおりです。

2つのクラスタ化されたストレージ・ヘッドと、それぞれ14TBハードディスク
ディスクのシャーシに14TBのハード・ディスクで完全に装着されている
ディスク・シェルフに取り付けられている4つのキャッシュ・ディスク: 2x 200GB SSDおよび2x 7.68TB SSD
RAID-1最適なデータ保護用の構成、使用可能な合計領域は約100TB

ストレージ・アプライアンスは、管理サブネット(192.168.4.0/24)およびストレージ・サブネット(192.168.40.0/24)に接続されています。どちらのヘッドもアクティブ/パッシブ構成では、1つのストレージ・ヘッドで障害が発生した場合のサービスの継続を保証するためにクラスタを形成します。ストレージ・ヘッドは、ストレージ・サブネット内の単一のIPを共有しますが、両方に簡単なメンテナンス・アクセス用の個々の管理IPアドレスがあります。 RAID-1ストレージ・プールには、OVCAおよびOVMという名前の2つのプロジェクトが含まれています。

OVCAプロジェクトには、Oracle Private Cloud Applianceソフトウェアが使用するすべてのLUNとファイルシステムが含まれます。

LUN
- Locks (12GB) - 2つの管理ノード上のクラスタのロックに排他的に使用されます。
- Manager (200GB) - 両方の管理ノード上の追加ファイル・システムとして排他的に使用
ファイルシステム:
- MGMT_ROOT - Oracle Private Cloud Applianceに固有のすべてのファイルのストレージで使用されます
- Database - データベースのプレースホルダー・ファイル・システム
- Incoming (20GB) - FTPファイル転送に使用するもの(主にOracle Private Cloud Applianceコンポーネントのバックアップ用)
- Templates - 将来使用するためのプレースホルダー・ファイル・システム
- User - 将来使用するためのプレースホルダー・ファイル・システム
- Yum - システム・パッケージの更新に使用

OVMプロジェクトには、Oracle VMで使用されるすべてのLUNとファイルシステムが含まれます。

LUN
- iscsi_repository1 (3TB) - Oracle VMストレージ・リポジトリとして使用されます
- iscsi_serverpool1 (12GB) - Oracle VMクラスタ化サーバー・プール用のサーバー・プール・ファイル・システムとして使用されます
ファイルシステム:
- nfs_repository1 (3TB) - kdumpで使用され、顧客が使用することはできません
- nfs_serverpool1 (12GB) - NFSがiSCSIより優先される場合に、Oracle VMクラスタ化サーバー・プールのサーバー・プール・ファイル・システムとして使用されます

注意

内部ZFS Storage Applianceに顧客作成のLUNが含まれている場合は、それらがデフォルトのイニシエータ・グループにマップされていないことを確認してください。次の場所にある" 「顧客が作成したLUNが間違ったイニシエータ・グループにマップされます」 "を参照してください

「Oracle Private Cloud Applianceリリース・ノート」の「既知の制約および回避策」セクション。

ZFSストレージ・アプライアンスは、ストレージを提供するのみでなく、xinetdおよびtftpdサービスも実行します。これらは、すべてのOracle Private Cloud Applianceシステム・コンポーネントのプロビジョニングを調整するために、アクティブな管理ノードのOracle Linuxサービスを補完します。

「セクション1.6、「Oracle Private Cloud Applianceバックアップ」」機能とともに、ネイティブZFS機能を使用して内部ZFSストレージ・アプライアンスをバックアップすることもできます。 Oracle ZFS Storage Appliance は、ソースアプライアンスからレプリケーションターゲット、同じアプライアンス上の別のプール、またはオフラインレプリケーション用の NFS サーバーへのプロジェクトとシェアのスナップショットベースのレプリケーションをサポートしています。レプリケーションは手動で、定期的に、あるいは連続して実行するように構成できます。詳細は、「Oracle® ZFS Storage Appliance管理ガイド、リリースOS 8.8.x」の「リモート・レプリケーション」を参照してください。

ノート

内部ZFSアプライアンスを外部ホストのストレージ・デバイスとして構成しないでください。

1.2.4 ネットワーク・インフラストラクチャ

1.2.4.1 ネットワーク・アーキテクチャ

ネットワーク接続の場合、Oracle Private Cloud Applianceは必要な高可用性、帯域幅および速度を提供する物理レイヤーに依存します。この上で、様々なタイプのデータ・トラフィックに対応するように、いくつかの異なる仮想ネットワークが最適に構成されます。内部管理ネットワークのみが物理的なものであり、アプライアンス・データ接続はソフトウェア定義ネットワーク(SDN)を使用します。アプライアンス・ラックには、障害が発生した場合のサービスの継続性を保証するためにファクトリで事前に有効化されている、冗長なネットワーク・ハードウェア・コンポーネントが含まれています。

1.2.4.1 ネットワーク・アーキテクチャ

Ethernetベース・ネットワーク・アーキテクチャを備えたOracle Private Cloud Applianceは、冗長な物理的高速Ethernet接続に依存しています。

管理ネットワーク

管理ネットワークは、すべてのアプライアンス・コンポーネントの管理インタフェースへの内部アクセスを提供します。これらには、Cisco Nexus 9348GC-FXPスイッチへのEthernet接続があり、すべて192.168.4.0/24範囲で事前定義済のIPアドレスがあります。また、すべての管理ノードおよびコンピュート・ノードのIPアドレスは、この範囲でOracle Integrated Lights Out Manager (ILOM)接続に使用される2つ目のIPアドレスを持っています。

アプライアンスの初期化中は、データ・ネットワークにアクセスできません。つまり、内部管理ネットワークはシステムに接続するための唯一の一時的な方法です。したがって、管理者は、Cisco Nexus 9348GC-FXPスイッチで予約済Ethernetポート48にワークステーションを接続し、固定IPアドレス192.168.4.254をワークステーションに割り当てる必要があります。このワークステーションから、管理者はアクティブ管理ノードのwebサーバーへのブラウザ接続をhttps://192.168.4.216で開いて、初期化プロセスをモニターし、アプライアンスの電源がはじめて投入されたときに初期構成ステップを実行します。

データ・ネットワーク

アプライアンス・データ接続は、リーフのスパイン・スイッチの冗長Cisco Nexus 9336C-FX2スイッチ上に組み込まれています。この2レイヤーの設計では、リーフ・スイッチはラック・ハードウェア・コンポーネントを相互接続し、スパイン・スイッチはネットワークのバック結合を形成し、ルーティング・タスクを実行します。各リーフ・スイッチは、相互に接続されているすべてのスパイン・スイッチに接続されます。このネットワーク・アーキテクチャの主な利点は、拡張性とパスの最適化です。 Oracle Private Cloud Applianceラックには、2つのリーフ・スイッチと2つのスパイン・スイッチが含まれます。

Cisco Nexus 9336C-FX2 Switchでは、1ポート当たり最大スループットは100Gbitです。スパイン・スイッチでは5つのインター・リンク(500Gbit)が使用され、リーフ・スイッチでは2つのインター・リンク(200Gビット)と2x2のクロス・リンクがスピンに使用されます。各コンピュート・ノードは、リンク集計モードの2つの100Gbit Ethernetポートで構成されるbond1インタフェースを介して、ラック内の両方のリーフ・スイッチに接続されます。 2つのストレージ・コントローラは、4x40Gbit接続を使用してスパイン・スイッチに接続されています。

外部接続の場合、各スパイン・スイッチに5つのポートが予約されます。カスタム・ネットワーク構成には4つのポートを使用できます。デフォルトのアップリンクには1つのポートが必要です。この「デフォルト外部アップリンク」では、両方のスパイン・スイッチのポート5がQSFP+-to-SFP+ 4方向のスプリッタまたはブレークアウト・ケーブルを使用して分割されている必要があります。スパイン・スイッチの4つの10GbE SFP+ブレークアウト・ポート、ポート5/1および5/2の2つは、ラックの上位またはToRスイッチとも呼ばれる次レベルのデータ・センター・スイッチのペアに接続されている必要があります。

ソフトウェア定義ネットワーク

前述の物理データ・ネットワークではデータ・パケットの転送が可能ですが、実際の接続はソフトウェア定義ネットワーク(SDN)を介して実装されます。 VxLANのカプセル化とVLANのタグ付けを使用して、数千の仮想ネットワークをデプロイして、分離されたデータ交換を提供できます。トラフィックは、アプライアンス環境内のリソース間、または外部へのネットワーク・ストレージ、アプリケーション、またはデータセンターやインターネット上のその他のリソースに対する外部リソースとなります。 SDNでは、分離された接続のトラフィックの分離を保持し、パフォーマンスや動的(再)割当てを向上させます。顧客ネットワークから見て、Oracle Private Cloud ApplianceでのVxLANsの使用は透過的です: カプセル化およびカプセル化解除は、インバウンドまたはアウトバウンドのデータ・パケットを変更せずに内部的に実行されます。つまり、この設計では、アプライアンスでホストされる仮想化環境に、顧客のネットワーク(タグ付けまたはタグ付けの解除)を拡張します。

Oracle Private Cloud Applianceの初期化プロセス時に、いくつかの必須のデフォルト・ネットワークが構成されます。

「内部ストレージ・ネットワーク」は、スパイン・スイッチからZFSストレージ・アプライアンスへの冗長40GbitEthernet接続です。 4つのストレージ・コントローラ・インタフェースはすべて、LACPを使用して1つのデータリンクに結合されます。管理ノードおよびコンピュート・ノードは、VLAN 3093で192.168.40.0/21サブネット全体に内部ストレージに到達できます。このネットワークは、クラスタ化されたOracle VMサーバー・プールのハートビート機能も満たします。
「内部管理ネットワーク」によって、管理ノードと、VLAN 3092のサブネット192.168.32.0/21にあるコンピュート・ノード間の接続が提供されます。 Oracle VM Manager、Oracle VM ServerおよびOracle VM Agentsに固有のすべてのネットワーク・トラフィックで使用されます。
「内部基礎ネットワーク」は、コンピュート・ノード間のデータ・トラフィックに対応するインフラストラクチャ・レイヤーを提供します。これは、VLAN 3091上のサブネット192.168.64.0/21を使用します。内部基礎ネットワークの上位には、内部アクセスのみが必要な仮想マシン接続を有効化するために、内部VxLANオーバーレイ・ネットワークが構築されます。

そのような内部VxLANの1つが事前に構成されています: すべてのコンピュート・ノードがそれぞれのvx2インタフェースを使用して接続される「デフォルトの内部VMネットワーク」。タグ付け解除されたトラフィックは、デフォルトでこのネットワーク上でサポートされます。カスタマは、選択したVLANをOracle VMネットワーク構成に追加し、仮想マシン・レベルでIPアドレス割当てに適したサブネットを定義できます。
「外部基礎ネットワーク」は、Oracle Private Cloud Applianceとデータ・センター・ネットワーク間のデータ・トラフィック用のインフラストラクチャ・レイヤーを提供します。これは、VLAN 3090上のサブネット192.168.72.0/21を使用します。外部基礎ネットワークの上には、外部アクセスのあるVxLANオーバーレイ・ネットワークが構築されて、物理ノードおよびホストするすべての仮想マシンのパブリック接続が可能になります。

そのようなパブリックVxLANの1つは事前に構成されています: すべてのコンピュート・ノードおよび管理ノードのvx13040インタフェースを使用して接続先の「デフォルトの外部ネットワーク」タグ付けされたトラフィックとタグ付けされていないトラフィックの両方は、このネットワーク上でデフォルトでサポートされます。カスタマは、選択したVLANをOracle VMネットワーク構成に追加し、仮想マシン・レベルでIPアドレス割当てに適したサブネットを定義できます。

デフォルトの外部ネットワークでは、データ・センター・ネットワークから管理ノードにアクセスし、複数のシステム・サービスを管理ノードで実行することもできます。管理ノードの外部ネットワーク設定は、Oracle Private Cloud Appliance Dashboardの「ネットワーク設定」タブ」で構成できます。このネットワークがVLANの場合、そのIDまたはタグは、ダッシュボードの「ネットワーク設定」タブ内で構成する必要があります。

アプライアンスのデフォルト・ネットワークを正常に構成するには、アプライアンスの初期化を開始する前にデフォルトの外部アップリンクを設定する必要があります。管理者は、初期化プロセスの最後に、データ・センター(パブリック)のネットワーク範囲からOracle Private Cloud Applianceの管理ノード・クラスタに3つの予約済IPアドレスを割り当てます: 1つは各管理ノード用、もう1つはクラスタ化ノードによって共有される仮想IPです。これ以降、仮想IPは、Oracle Private Cloud ApplianceダッシュボードとOracle VM Manager webインタフェースの両方をホストするアクティブな管理ノードのWebサーバーに接続するために使用されます。

注意

両方のスパインCisco Nexus 9336C-FX2スイッチは、次のレベルのデータ・センター・スイッチのペアにそれぞれ2つの10GbE接続を持つことが重要です。このため、4方向の遮断ケーブルを各スパイン・スイッチのポート5にアタッチし、10GbE遮断ポート5/1および5/2をアップリンクとして使用する必要があります。ポート5/3および5/4は使用されないままです。

このアウトバウンド配線は、サービスの最適な継続性を確保するために、スパイン・スイッチとデータ・センター・ネットワーク間のケーブル接続を超えているか、または調整する必要があります。

1.3 ソフトウェア・コンポーネント

この項では、Oracle Private Cloud Applianceで操作および構成用に使用する主要なソフトウェア・コンポーネントについて説明します。

1.3.1 Oracle Private Cloud Applianceダッシュボード

Oracle Private Cloud Applianceには、独自のwebベースのグラフィカル・ユーザー・インタフェースが用意されており、このインタフェースを使用して、アプライアンスに固有の様々な管理タスクを実行できます。 Oracle Private Cloud Applianceダッシュボードは、アクティブ管理ノードを通して使用できるOracle JETアプリケーションです。

ダッシュボードを使用して、次のタスクを実行します。

アプライアンス・システムのモニタリングとコンポーネントの識別
管理ノードのネットワーク・データの初期構成
Oracle Private Cloud Appliance構成コンポーネントのグローバル・パスワードのリセット

Oracle Private Cloud Applianceダッシュボードは、第2章、「Oracle Private Cloud Applianceのモニタリングおよび管理」で詳細に説明されています。

1.3.2 パスワード・マネージャ(Wallet)

Oracle Private Cloud Applianceのすべてのコンポーネントには、デフォルトのパスワードを持つ管理者アカウントがあります。 Oracle Private Cloud Appliance Dashboardを通じてデータセンターのネットワーク設定を適用した後には、デフォルトのアプライアンスのパスワードを変更することをお薦めします。「認証」タブでは新規パスワードを設定でき、それはメイン・システムの構成コンポーネントに適用されます。一覧表示されているすべてのコンポーネントに対して、新規パスワードを一度に設定することも、選択のためにのみ設定することもできます。ベスト・プラクティスは、すべてのパスワードを変更する場合に、2つのフェーズで変更することを推奨します。まず、すべてのハードウェア・コンポーネントのパスワードを変更し、変更が有効になるまで10分以上待ってから、ovm-admin、mysqlおよびwls-weblogicのパスワードを変更します。

すべてのコンポーネントのすべてのアカウントのパスワードは、512ビットの暗号化で保護されたグローバルWalletに格納されます。パスワード・エントリを更新するには、Oracle Private Cloud Applianceダッシュボードまたはコマンドライン・インタフェースを使用します。詳細は、第2.8項、「認証」を参照してください。

1.3.3 Oracle VM Manager

すべての仮想マシン管理タスクは、各管理ノードにインストールされたWebLogicアプリケーションであるOracle VM Manager内で実行され、Webベースの管理ユーザー・インタフェースおよびOracle Private Cloud Appliance内のOracle VMインフラストラクチャを管理できるコマンドライン・インタフェースを提供します。

Oracle VM Managerは、次のソフトウェア・コンポーネントで構成されています。

Oracle VM Managerアプリケーション: Oracle WebLogic Serverドメインおよびコンテナとして提供されます。
Oracle WebLogic Server 12c: Application Development Framework (ADF)リリース12のcなど、Oracle VM Managerアプリケーションのホストと実行に使用されます。
MySQL 8.0 Enterprise Editionサーバー: Oracle VM Managerアプリケーションを管理リポジトリとして排他的に使用し、ZFSストレージ・アプライアンスのホストとなるデータベース・ファイル・システムにインストールします。

仮想マシンの管理は、第5章、「Oracle VM仮想インフラストラクチャの管理」で説明されているように、Oracle VM Manager webユーザー・インタフェースを使用して実行されます。 Oracle VM Managerで提供されるコマンドライン・インタフェースを使用することは可能ですが、これは、Oracle Private Cloud Applianceのコンテキストで実行されるOracle VM Managerの制限を十分に理解した状態でのみ実行する必要がある高度なアクティビティと考えられています。

1.3.4 オペレーティング・システム

Oracle Private Cloud Applianceのハードウェア・コンポーネントは、独自のオペレーティング・システムを実行します。

管理ノード: Oracle Linux 7とUEK R5
コンピュート・ノード: Oracle VM Server 3.4.7
Oracle ZFS Storage Appliance: Oracle Solaris 11

その他のすべてのコンポーネントは、それぞれのファームウェアの特定のリビジョンを実行します。すべてのオペレーティング・ソフトウェアが選択され、Oracle Private Cloud Applianceの一部として連携するように開発されています。更新がリリースされると、すべてのソフトウェア・コンポーネントの適切なバージョンがバンドルされます。新しいソフトウェア・リリースがアクティブ化されると、それに応じてすべてのコンポーネントのオペレーティング・ソフトウェアが更新されます。 Oracleに明示的に指示がないかぎり、個々のコンポーネントを更新しないでください。

1.3.5 データベース

Oracle Private Cloud Applianceでは、システムの状態の追跡、構成およびプロビジョニングの処理、およびOracle VM Managerのために、多数のデータベースが使用されます。すべてのデータベースはZFSストレージ・アプライアンスに格納され、NFSファイル・システムを介してエクスポートされます。高可用性を保証するために、各管理ノードがデータベースにアクセス可能です。

注意

データベースは手動で編集しないでください。アプライアンス構成は依存するため、操作は機能を中断する可能性があります。

次の表は、Oracle Private Cloud Applianceで使用される様々なデータベースを示しています。

表1.2 Oracle Private Cloud Applianceデータベース

項目	説明
Oracle Private Cloud Applianceノード・データベース	ラック内のすべてのコンピュート・ノードおよび管理ノードに関する情報が含まれ、ソフトウェア更新の処理に必要なコンピュート・ノードおよびデータのプロビジョニングを制御するために使用される状態が含まれます。タイプ: BerkeleyDB 各管理ノードの`/nfs/shared_storage/db/node`を介してアクセスできる、ZFS上のロケーション: `MGMT_ROOT/db/node`
Oracle Private Cloud Appliance Inventoryデータベース	管理ネットワーク`192.168.4.0/24`に出現するすべてのハードウェア・コンポーネントに関する情報が含まれます。コンポーネントには、管理ノードとコンピュート・ノードが含まれますが、スイッチ、ファブリック相互接続、ZFSストレージ・アプライアンス、PDUも含まれます。保存される情報には、IPアドレスとホスト名、ping可能なステータス、コンポーネントが最後にオンラインで見つかったときなどがあります。このデータベースの問合せは、複数のOracle Private Cloud Applianceサービスによって定期的に行われます。タイプ: BerkeleyDB 各管理ノードの`/nfs/shared_storage/db/inventory`を介してアクセスできる、ZFS上のロケーション: `MGMT_ROOT/db/inventory`
Oracle Private Cloud Appliance Netbundleデータベース	システム全体で構成可能で、動的に割り当てられるすべてのネットワークのEthernetおよび結合デバイスの名前を、あらかじめ定義します。タイプ: BerkeleyDB 各管理ノードの`/nfs/shared_storage/db/netbundle`を介してアクセスできる、ZFS上のロケーション: `MGMT_ROOT/db/netbundle`
Oracle Private Cloud Appliance DHCPデータベース	新しく検出されたコンピュート・ノードへのDHCPアドレスの割当てに関する情報が含まれます。タイプ: BerkeleyDB 各管理ノードの`/nfs/shared_storage/db/dhcp`を介してアクセスできる、ZFS上のロケーション: `MGMT_ROOT/db/dhcp`
Ciscoデータ・ネットワーク・データベース	スパイン・スイッチ経由のトラフィック用に構成されたネットワーク、およびネットワークに参加しているインタフェースに関する情報が含まれます。 Ethernetベースのネットワーク・アーキテクチャのあるシステムでのみ使用されます。タイプ: BerkeleyDB 各管理ノードの`/nfs/shared_storage/db/cisco_data_network_db`を介してアクセスできる、ZFS上のロケーション: `MGMT_ROOT/db/cisco_data_network_db`
Cisco管理スイッチ・ポート・データベース	Cisco Nexus 9348GC-FXPスイッチ・ポートのファクトリで構成されたマップを、そのポートが接続されているラック・ユニットまたは要素に定義します。スイッチ・ポートをマシン名にマップする際に使用されます。 Ethernetベースのネットワーク・アーキテクチャのあるシステムでのみ使用されます。タイプ: BerkeleyDB 各管理ノードの`/nfs/shared_storage/db/cisco_ports`を介してアクセスできる、ZFS上のロケーション: `MGMT_ROOT/db/cisco_ports`
Oracle Private Cloud Appliance Mini Database	コンピュート・ノードのハードウェア・プロファイルをオンボード・ディスクのサイズ情報にマップするために使用される、多目的のデータベース。また、Oracle Private Cloud Applianceコンポーネントとして受け入れられるためにサーバーが準拠する必要のある有効なハードウェア構成も含まれます。エントリには、コマンド行インタフェース(CLI)内でより便利に使用できるように同期IDが含まれています。タイプ: BerkeleyDB 各管理ノードの`/nfs/shared_storage/db/mini_db`を介してアクセスできる、ZFS上のロケーション: `MGMT_ROOT/db/mini_db`
Oracle Private Cloud Applianceモニター・データベース	インベントリ・データベースで識別されたすべてのアクティブ・コンポーネントのILOMを介して検出された障害数を記録します。タイプ: BerkeleyDB 各管理ノードの`/nfs/shared_storage/db/monitor`を介してアクセスできる、ZFS上のロケーション: `MGMT_ROOT/db/monitor`
Oracle Private Cloud Appliance設定データベース	Oracle Private Cloud Appliance Dashboardの設定機能で設定されたデータが含まれています。変更が検出されると、このデータベース内のデータは、アクティブ管理ノードとスタンバイ管理ノードの両方によって自動的に適用されます。タイプ: BerkeleyDB 各管理ノードの`/nfs/shared_storage/db/setup`を介してアクセスできる、ZFS上のロケーション: `MGMT_ROOT/db/setup`
Oracle Private Cloud Applianceタスク・データベース	Oracle Private Cloud Appliance内でディスパッチされたすべての非同期タスクの状態データが格納されます。タイプ: BerkeleyDB 各管理ノードの`/nfs/shared_storage/db/task`を介してアクセスできる、ZFS上のロケーション: `MGMT_ROOT/db/task`
Oracle Private Cloud Appliance同期データベース	ラック・コンポーネント間で適用および保守するための同期サービスのデータおよび構成設定が含まれています。アプライアンス・コンポーネント間での構成パラメータの同期化試行が失敗した場合のエラーは、`sync_errored_tasks`データベースで確認でき、そこから再試行または確認できます。デフォルトでは、同期データベースは存在しません。特定のタイプの最初の同期タスクを受信すると作成されます。タイプ: BerkeleyDB 各管理ノードの`/nfs/shared_storage/db/sync_`を介してアクセスできる、ZFS上のロケーション:* `MGMT_ROOT/db/sync_*`
Oracle Private Cloud Applianceデータベース更新	2ノードで調整された管理ノードの更新プロセスを追跡するために使用します。ノートコントローラ・ソフトウェアの異なるリリース間でのデータベース・スキーマの変更およびウォレットの変更は、ファイルに書き込まれます。この設定により、他のアプライアンス・コンポーネントがバックアップされる前に、ソフトウェア更新プロセスの早い時点で、これらの重要な変更が適用されることが保証されます。タイプ: BerkeleyDB 各管理ノードの`/nfs/shared_storage/db/update`を介してアクセスできる、ZFS上のロケーション: `MGMT_ROOT/db/update`
Oracle Private Cloud Applianceテナント・データベース	すべてのテナント・グループに関する詳細を含みます: デフォルトおよびカスタム。これらの詳細には、一意のテナント・グループID、ファイル・システムID、メンバー・コンピュート・ノード、ステータス情報などが含まれます。タイプ: BerkeleyDB 各管理ノードの`/nfs/shared_storage/db/tenant`を介してアクセスできる、ZFS上のロケーション: `MGMT_ROOT/db/tenant`
Oracle VM Managerデータベース	各管理ノードで、Oracle VM Managerの管理データベースとして使用されます。 Oracle VM環境のすべての構成詳細(サーバー、プール、ストレージおよびネットワークを含む)と、環境によってホストされる仮想化システムが含まれます。タイプ: MySQLデータベース各管理ノードの`/nfs/shared_storage/ovmm_mysql/data/`を介してアクセスできる、ZFS上のロケーション: `MGMT_ROOT/ovmm_mysql/data/`

1.3.6 Oracle Private Cloud Appliance管理ソフトウェア

Oracle Private Cloud Applianceには、アプライアンス内のすべてのコンポーネントのプロビジョニング、管理およびメンテナンス用に設計されたソフトウェアが含まれています。様々なハードウェア・コンポーネントにわたるタスクの編成および自動化を処理するコントローラ・ソフトウェアは、人による操作では使用できません。そのアプライアンスの管理機能は、ブラウザ・インタフェースとコマンドライン・インタフェースを通じて公開されます。詳細は、このガイドを参照してください。

重要

すべての構成および管理タスクは、Oracle Private Cloud Applianceダッシュボードおよびコマンドライン・インタフェースを使用して実行する必要があります。 Oracle Supportの担当者から明示的に指示されていないプロセスを直接実行しないようにしてください。これを行おうとすると、アプライアンスが使用できなくなる可能性があります。

ダッシュボードおよびCLIに加え、このソフトウェアには、アクティブ管理ノードで実行される多数のPythonアプリケーションも含まれます。これらのアプリケーションは、/usr/sbinの各管理ノードにあり、次のような一部がリストされています。

pca-backup: 第1.6項、「Oracle Private Cloud Applianceバックアップ」で説明されている、アプライアンス構成のバックアップを実行するスクリプト
pca-check-master: 現在アクティブなロールを持っている2つの管理ノードを検証するスクリプト
ovca-daemon: Oracle Private Cloud Applianceのコア・プロビジョニングおよび管理デーモン
pca-dhcpd: DHCPデーモンがコンピュート・ノードの登録を支援するヘルパー・スクリプト
pca-diag: 第1.3.7項、「Oracle Private Cloud Appliance診断ツール」の説明に従って、Oracle Private Cloud Applianceから診断情報を収集するためのツール。
pca-factory-init: アプライアンスを出荷時の構成に設定するために使用されるアプライアンス初期化スクリプト。このスクリプトはリセットとして機能しません。初期ラック設定にのみ使用されます。
pca-redirect: 第1.3.1項、「Oracle Private Cloud Applianceダッシュボード」で説明されているOracle Private Cloud ApplianceダッシュボードにHTTPまたはHTTPSリクエストをリダイレクトするデーモン
ovca-remote-rpc: リモート・プロシージャのスクリプトによって、Oracle VM Serverエージェントが直接コールされます。現在、これは、Oracle VM Serverエージェントのハートビートを監視するために管理ノードによってのみ使用されます。
ovca-rpc: Oracle Private Cloud Applianceソフトウェア・コンポーネントが、管理ノードで実行されている基礎となる管理スクリプトと直接通信できるようにするスクリプト

これらのアプリケーションの多くは、各管理ノードの/usr/lib/python2.7/site-packages/ovca/にインストールされている特定のOracle Private Cloud Applianceライブラリを使用します。

1.3.7 Oracle Private Cloud Appliance診断ツール

Oracle Private Cloud Applianceには、診断データを収集するために実行できるツールが用意されています: ハードウェアやソフトウェアの問題のトラブルシューティングに役立つ可能性のある、ログなどのタイプのファイル。このツールは、/usr/sbin/内の各管理ノードおよびコンピュート・ノードにあり、pca-diagという名前です。取り出されるデータは、選択されたコマンドライン引数によって異なります。

pca-diag

このコマンドを追加の引数なしで入力すると、ツールはOracle Private Cloud Applianceの現在のヘルス・ステータスを洞察するファイルの基本セットを取得します。このコマンドは、すべての管理ノードおよびコンピュート・ノードで実行できます。収集されたすべてのデータは/tmpで保管され、単一のターゲット(ovcadiag_<node-hostname>_<ID>_<date>_<time>.tar.bz2)に圧縮されます。
pca-diag version

このコマンドを入力すると、現在のOracle Private Cloud Applianceソフトウェア・スタックのバージョン情報が表示されます。 version引数を他の引数と組み合せることはできません。
pca-diag ilom

このコマンドを入力すると、ipmitoolでホストILOMを使用して診断データが取得されます。データ・セットには、ホスト・オペレーティング・システム、プロセス、ヘルス・ステータス、ハードウェアおよびソフトウェアの構成、およびOracle Private Cloud Appliance構成に固有の多くのファイルに関する詳細が含まれます。このコマンドは、すべての管理ノードおよびコンピュート・ノードで実行できます。収集されたすべてのデータは/tmpに保存され、単一のtar (ovcadiag_<node-hostname>_<ID>_<date>_<time>.tar.bz2)に圧縮されています。
pca-diag vmpinfo

注意

vmpinfo引数を使用する場合、コマンドはアクティブな管理ノードから実行する必要があります。

このコマンドを入力すると、Oracle VMの診断データ収集メカニズムがアクティブ化されます。 vmpinfo3スクリプトは、Oracle VM Managerからログと構成の詳細を収集し、および各Oracle VM Serverからまたはコンピュート・ノードからログおよびsosreport情報を収集します。収集されたすべてのデータは、2つのタボールに圧縮されて/tmpに格納されます: ovcadiag_<node-hostname>_<ID>_<date>_<time>.tar.bz2およびvmpinfo3-<version>-<date>-<time>.tar.gz。

環境内のOracle VM Serversのサブセットの診断情報を収集するには、追加のserversパラメータを指定してコマンドを実行します: pca-diag vmpinfo servers='ovcacn07r1,ovcacn08r1,ovcacn09r1'

pca-diagを使用した診断収集は、システム内の任意のノードのコマンドラインから行うことができます。アクティブな管理ノードのみが、すべてのコマンド行引数を使用できます。 vmpinfoはコンピュート・ノードでは使用できませんが、コンピュートに対して直接pca-diagを実行すると、vmpinfoでは取得できないOracle VM Serverに関する重要な診断情報を取得できます。

pca-diagツールは、通常、異なるロールを持つ複数のユーザーによって実行されます。システム管理者またはフィールド・サービス・エンジニアは、そのツールを標準的な操作手順の一部として使用することも、Oracle Supportチームが、報告されたハードウェアまたはソフトウェアの問題を診断して解決する作業として、特定の方法でツールを実行するようにリクエストすることもできます。詳細および手順については、「Oracle Private Cloud Applianceリリース・ノート」の「" サービスおよびサポート用のデータ・コレクション "」セクションも参照してください。

1.4 プロビジョニングおよびオーケストレーション

コンバージド・インフラストラクチャ・ソリューションとして、Oracle Private Cloud Applianceは、システム構成の最適化の多くの組込みを排除するように構築されています。ハードウェア・コンポーネントは、ファクトリで設置およびケーブル接続されます。構成設定およびインストール・ソフトウェアはシステムに事前ロードされています。アプライアンスがデータ・センターの電源とパブリック・ネットワークに接続されると、最初の管理ノードの電源ボタンを押している管理者と「デプロイメントの準備状況」状態に達しているアプライアンス間のプロビジョニング・プロセスは、アクティブな管理ノードによって完全にオーケストレーションされます。この項では、Oracle Private Cloud Applianceの初期化およびすべてのノードのプロビジョニング時に行われる処理について説明します。

1.4.1 アプライアンス管理の初期化

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

電源が最初の管理ノードに適用されると、サーバーの起動に約5分かかります。 Oracle Linuxオペレーティング・システムのロード中に、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サービスが開始されると、システム状態が「準備状況のプロビジョニング」に変わります(これは、フレーム構造以外のコンポーネントを検出する準備ができたことを意味します)。

1.4.2 コンピュート・ノードの検出およびプロビジョニング

ノード・マネージャ

コンピュート・ノードを検出するために、アクティブな管理ノードのノード・マネージャは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がアクティブな同じ管理ノードを介してプロビジョニング・タスクが実行されるため、コンピュート・ノードのプロビジョニングに大幅に時間がかかります。機能に影響はありませんが、プロビジョニング・タスクの完了には数時間かかる可能性があります。システム・アクティビティが最も低い時間にコンピュート・ノード・プロビジョニングを実行することをお薦めします。

1.4.3 サーバー・プールの準備状況

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は、同期サービスの公開された機能へのインタフェースを提供します。

1.5 高可用性

Oracle Private Cloud Applianceは、そのコンポーネント・マーカーのすべてのレベルで高可用性用に設計されています。

管理ノードのフェイルオーバー

Oracle Private Cloud Applianceのファクトリ・インストール時に、管理ノードがクラスタとして構成されます。クラスタは、ZFSストレージからiSCSI LUNとしてエクスポートされたOCFS 2ファイルシステムに依存してハートビート機能を実行し、各管理ノードが制御を試行するロック・ファイルを格納します。ロック・ファイルを制御する管理ノードは、自動的にクラスタ内のアクティブ・ノードになります。

Oracle Private Cloud Applianceが最初に初期化されると、o2cbサービスは各管理ノードで開始されます。このサービスは、OCFS2ファイル・システムのデフォルトのクラスタ・スタックです。クラスタ内のノードを追跡するノード・マネージャ、ライブ・ノードを検出するためのハートビート・エージェント、イントラクラスタ・ノード通信用のネットワーク・エージェント、およびロック・リソースを追跡するための分散ロック・マネージャが含まれています。これらのコンポーネントはすべてカーネル内です。

さらに、ovcaサービスは、各管理ノードで開始されます。クラスタ・ロックを制御し、それによってアクティブな管理ノードに昇格する管理ノードは、Oracle Private Cloud Applianceサービスの完全な補完を実行します。また、このプロセスは、アクティブ管理ノードにアクセスするために使用される仮想IPを構成し、アクティブ管理ノード上では稼働中、スタンバイ管理ノードでは停止中になります。これによって、管理ノード用に構成した仮想IPアドレスへの接続を試みるときに、常にアクティブ管理ノードにアクセスできるようになります。

アクティブ管理ノードに障害が発生した場合、クラスタが障害を検出し、ロックが解除されます。スタンバイ管理ノードは、ロック・ファイルを制御するために常にポーリングしているため、このファイルを制御できる時期を検出し、ovcaサービスが必要なすべてのOracle Private Cloud Applianceサービスを提供します。スタンバイ管理ノードでは、仮想IPはアクティブ・ロールにプロモートされるため、適切なインタフェース上に構成されます。

障害が発生した管理ノードがオンラインに戻ると、クラスタ・ロック・ファイルを制御できなくなります。これは自動的にスタンバイ・モードになり、仮想IPは管理インタフェースから削除されます。つまり、ラック内の2つの管理ノードのいずれかが常に同じIPアドレスから使用でき、正しく構成されています。管理ノードのフェイルオーバー・プロセスは完了するのに最大5分かかります。

Oracle VM Management Databaseのフェイルオーバー

Oracle VM Managerデータベース・ファイルは、ZFSストレージ・アプライアンスによって公開される共有ファイル・システム上にあります。アクティブ管理ノードは、共有ストレージ上のデータベース・ファイルにアクセスするMySQLデータベース・サーバーを実行します。管理ノードに障害が発生した場合は、スタンバイ管理ノードが昇格され、昇格されたノードのMySQLデータベース・サーバーが起動されて、サービスを通常どおり再開できます。データベースの内容は、新しく実行しているMySQLデータベース・サーバーで利用できます。

コンピュート・ノードのフェイルオーバー

Oracle Private Cloud Appliance内のコンピュート・ノードの高可用性(HA)は、コンピュート・ノードのプロビジョニング処理中にOracle VM Managerに自動的に作成されるクラスタ化サーバー・プールを使用して有効化されます。サーバー・プールは基礎となるOCFS2ファイル・システムを使用してクラスタとして構成されているため、任意のコンピュート・ノードで実行されているHA対応仮想マシンを障害発生時に代替コンピュート・ノードで自動的に移行および再起動できます。

「Oracle VM概要ガイド」は、高可用性の原則に関する適切なバックグラウンド情報を提供します。「高可用性(HA)の仕組み」の項を参照してください。

記憶域の冗長性

ZFSストレージ・アプライアンスを使用してストレージをホストすることで、さらなる冗長性が提供されます。このコンポーネントは、RAID-1で構成され、統合された冗長性および優れたデータ損失の保護を提供します。さらに、ストレージ・アプライアンスには、クラスタ化構成で相互接続されている2つのストレージ・ヘッドまたはコントローラが含まれています。コントローラのペアはアクティブ/パッシブ構成で動作します。つまり、1つのストレージ・ヘッドで障害が発生した場合は、サービスの継続が保証されます。ストレージ・ヘッドは、ストレージ・サブネット内の単一のIPを共有しますが、両方に簡単なメンテナンス・アクセス用の個々の管理IPアドレスがあります。

ネットワーク冗長性

Oracle Private Cloud Appliance内の顧客が使用できるネットワークはすべて、冗長性のために構成されます。 ILOM接続の初期化に使用される内部管理Ethernetネットワークだけが冗長ではありません。各スイッチ・タイプには、シングル・ポイント障害がないことを確認するために2つのタイプがあります。ネットワークの配線とインタフェースは同等に複製され、スイッチは第1.2.4項、「ネットワーク・インフラストラクチャ」で説明されているように相互接続されます。

1.6 Oracle Private Cloud Applianceバックアップ

Oracle Private Cloud Appliance内のすべてのコンポーネントの構成は自動的に、一連のアーカイブとしてZFSストレージ・アプライアンスにバックアップおよび格納されます。バックアップは、バックアップを実行するときのタイムスタンプを使用して名前が付けられます。

初期化中、各管理ノードにcrontabエントリが作成され、24時間ごとにグローバル・バックアップが2回実行されます。 1番目のバックアップは09h00で、2番目のバックアップは21h00で実行されます。バックアップ・プロセスのトリガー時には、アクティブ管理ノードでのみ実際にバックアップ・プロセスが実行されます。

ノート

デフォルト・スケジュールの外部でバックアップをトリガーするには、「コマンドライン・インタフェース」を使用します。詳細は、第4.2.8項、「backup」を参照してください。

バックアップは、ZFSストレージ・アプライアンス上のMGMT_ROOTファイル・システムに格納され、/nfs/shared_storage/backupsの各管理ノードでアクセスできます。バックアップ・プロセスがトリガーされると、現行のバックアップ・プロセスのタイムスタンプを使用して、指定された一時ディレクトリが作成されます。プロセスが完了すると、ディレクトリ全体が*.tar.bz2ファイルにアーカイブされます。このディレクトリ内では、次のサブディレクトリも作成されます。

data_net_switch: Ethernetベースのネットワーク・アーキテクチャのシステムでのみ使用します。スパイン・スイッチとリーフ・スイッチの構成データが含まれます。
mgmt_net_switch: Ethernetベースのネットワーク・アーキテクチャのあるシステムでのみ使用します。管理スイッチの構成データが含まれます
ovca: パスワード・ウォレット、管理ノードのネットワーク構成、Oracle Private Cloud Applianceサービスの構成データベース、DHCP構成など、管理ノードのデプロイメントに関連するすべての構成情報が含まれています。
ovmm: Oracle VM Managerデータベースの最新バックアップ、現行データベースの実際のソース・データ・ファイル、およびOracle VM ManagerインストールのUUID情報が含まれます。 Oracle VM Managerデータベースの実際のバックアップ・プロセスは、Oracle VM Managerから自動的に処理されます。手動によるバックアップとリストアの詳細は、「Oracle VM Manager管理ガイド」のOracle VM Managerのバックアップとリストアというセクションを参照してください。
ovmm_upgrade: 各アップグレード試行に必要な情報が含まれています。アップグレードが開始されると、タイムスタンプの付いたサブディレクトリが作成され、アップグレード前のチェックの出力とともにpreinstall.logファイルが格納されます。アップグレード前プロセス中に変更された他のファイルのバックアップも、このディレクトリに保存されます。
zfssa: ZFSストレージ・アプライアンスのすべての構成情報を含む

バックアップ・プロセスでは、アプライアンスの各コンポーネントのデータが収集され、障害の場合にそのコンポーネントの操作を簡単にリストアできる方法で格納されます ^[1]。

通常のバックアップの作成は、本番システムの標準的なオペレーティング・プロシージャです。内部バックアップ・メカニズムは、システムの完全障害、サイトの停止または障害から保護することはできません。したがって、キー・システム・データを外部ストレージにコピーするバックアップ計画を実装することを検討する必要があります。これには、bastion hostと呼ばれることが多いものが必要です: 特定の内部および外部接続を使用して構成された専用システム。

バックアップの内容の詳細、およびアプライアンス外部の内部バックアップをエクスポートするためのガイドラインについては、「Oracle Private Cloud Applianceバックアップ・ガイド」というタイトルのOracleテクニカル・ペーパーを参照してください。

1.7 Oracle Private Cloud Applianceアップグレーダ

Oracle Private Cloud Appliance Controllerソフトウェア・リリース2.3.4とともに、新しい独立したアップグレード・ツールが導入されました: Oracle Private Cloud Applianceアップグレーダこれは、個別のアプリケーションとして、独自のリリースおよび更新スケジュールとともに提供されます。これには段階的アプローチが保持されます。管理ノード、コンピュート・ノード、その他のラック・コンポーネントは個別の手順で更新されますが、同時にグループ化され、スクリプトまたは手動ステップとして以前に実行されたタスクのセットが自動化されます。新しい設計では、端末のクラッシュ、sshタイムアウト、または不注意によるユーザーの終了に対して、より適切なエラー処理と保護を行います。これは、複雑さを減らして全体的なアップグレード操作性を向上させることを目的としています。

Oracle Private Cloud Applianceアップグレーダは、モジュール式フレームワークとして作成されました。各モジュールは事前チェック、アップグレードやインストールなどの実行フェーズ、および事後チェックで構成されます。標準の対話モードに加え、モジュールでは、プログラムを使用するためのサイレント・モードや、実行フェーズを開始せずに事前チェックを実行するための検証のみのモードも提供します。

Oracle Private Cloud Applianceアップグレーダ・フレームワーク内で開発された最初のモジュールは、管理ノードのアップグレードです。単一のコマンドで、管理者にアップグレード前の検証ステップをガイドします。 - アップグレーダの事前チェックに、ソフトウェア・イメージのデプロイメント、Oracle Private Cloud Appliance Controllerソフトウェアの更新、Oracle Linuxオペレーティング・システムのYumの更新、およびOracle VM Managerのアップグレードが含まれています。

コントローラ・ソフトウェア・リリース2.4.4の時点では、Oracle Private Cloud Appliance Upgraderにはコンピュート・ノードのアップグレードを実行するための機能が含まれています。

ソフトウェアの更新手順は、第3章、「Oracle Private Cloud Applianceの更新」を参照してください。

特定のOracle Private Cloud Applianceアップグレーダの詳細は、第3.3項、「管理ノード・コントローラ・ソフトウェアのアップグレード」を参照してください。

^[1] バックアップからのリストアは、Oracle Service担当者のみが実行する必要があります。