ハードウェア概要

2 ハードウェア概要

この章では、Oracle Private Cloud Applianceを構成するハードウェア・コンポーネントの概要について説明: サーバー、スイッチ、およびストレージを備えた基本ラック。各セクションでは、各コンポーネントのロールについて説明します。アプライアンスのネットワーク・インフラストラクチャ、およびデータセンター環境、およびオプションでOracle Exadataシステムとの統合方法には特に注意してください。

基本ラック・コンポーネント

現在のPrivate Cloud Applianceハードウェア・プラットフォーム(出荷時にインストールされたソフトウェア・リリース3.0.1)は、Oracleラック・キャビネット1242ベースで構成され、次の図に示されているハードウェア・コンポーネントが装着されています。この図は完全な構成を示していますが、必要に応じて異なるストレージまたはコンピュート容量を含めるようにシステムをカスタマイズできます。

リリース3.0.1以降、フレックス・ベイの概念はPrivate Cloud Applianceにあります。フレックス・ベイは、システムの柔軟な拡張に使用できる4ラック・ユニット専用のセクションです。ストレージ・リソースまたはコンピュート・リソースを追加します。フレックス・ベイごとに、1-4のコンピュート・ノード、1 Oracle Storage Drive Enclosure DE3-24Cまたは1-2 Oracle Storage Drive Enclosure DE3-24Pを追加することを選択できます。フレックス・ベイは、ストレージ・リソースまたはコンピュート・リソースのいずれかを格納できますが、両方を同じベイに配置することはできません。

図の凡例

コールアウト	数量	説明
A	1 - 4	電気コード 1-4個のコンピュート・ノードまたは1-2個のストレージ・エンクロージャに対応可能
B	2	リーフ・スイッチ
C	1	Oracle Storage Drive Enclosure DE3-24Cディスク・シェルフ
D	1	管理スイッチ
E	2	スパイン・スイッチ
F	1 - 5	1を収容できる - 5つのコンピューティング・ノード
G	3	コンピュート・ノード最小構成に必要な3つ
H	3	管理ノード
I	2	ストレージ・コントローラ

サーバー

これらのセクションでは、Private Cloud Applianceによって使用される管理およびコンピュート・ノードについて説明します。

管理ノード

各Private Cloud Applianceインストールの中心には、3つの管理ノードがあります。これらはラック・ユニット5、6および7に取り付けられ、高可用性のためのクラスタを形成: すべてのサーバーが同じコントローラ・ソフトウェアとシステムレベルのサービスを実行でき、システム構成に等しくアクセスでき、3つのすべてのサーバーが完全にアクティブなクラスタとしてシステムを管理します。管理ノード・コンポーネントの詳細は、「サーバー・コンポーネント」を参照してください。

コントローラ・ソフトウェアを実行する管理ノードは、Private Cloud Applianceの動作および管理を担当するサービスの集まりの基盤を提供します。管理クラスタの役割には、システム・ハードウェアのモニタリングと保守、システムの可用性の確保、ソフトウェアとファームウェアのアップグレード、アプライアンスのバックアップとリストア、障害リカバリの管理などがあります。管理ノード・サービスの概要は、「アプライアンス管理の概要」を参照してください。管理機能の実行手順については、「Oracle Private Cloud Appliance管理者ガイド」を参照してください。

アプライアンス・インフラストラクチャが制御されるシステムの部分は、管理ノード・クラスタで実行され、「サービスCLI」または「サービスWeb UI」を介してアクセスできる「サービス・エンクレーブ」と呼ばれます。アクセスは厳密に監視され、特権管理者に制限されます。詳細は、「管理者アクセス」を参照してください。「Oracle Private Cloud Appliance管理者ガイド」の章「サービス・エンクレーブでの作業」も参照してください。

コンピュート・ノード

Private Cloud Applianceのコンピュート・ノードはハードウェア・レイヤーの一部であり、コンピュート・インスタンスをホストするための処理能力とメモリー容量を提供します。ハードウェア層の管理は、アプライアンスのプラットフォームとサービス・レイヤーによって提供されます。レイヤー・アーキテクチャ・アプローチの詳細は、「アーキテクチャと設計」を参照してください。

システムが初期化されると、コンピュート・ノードは管理サービスによって自動的に検出され、プロビジョニング準備完了状態になります。管理者は、「サービス・エンクレーブ」を使用してコンピュート・ノードをプロビジョニングでき、すぐに使用できます。後の段階で追加のコンピュート・ノードをインストールすると、新しいノードが検出され、電源が投入され、同じメカニズムによって自動的に検出されます。

管理者は、コンピュート・ノードのヘルスおよびステータスをPrivate Cloud Appliance 「サービスWeb UI」または「サービスCLI」からモニターし、コンピュート・ノードのテナンシへの割当てやコンピュート・ノード・コンポーネントのアップグレードなどのその他の操作を実行できます。一般的な管理情報については、「アプライアンス管理の概要」を参照してください。コンピュート・リソースの管理の詳細は、「コンピュート・インスタンスの概念」を参照してください。

ベース・ラックの最小構成には3つのコンピュート・ノードが含まれますが、コンピュート・ノード用にすべてのフレックス・ベイ・スペースを使用する場合は、一度に3つのノードで拡張できます。システムは合計で最大20のコンピュート・ノードをサポートでき、例外プロセスでリクエストできるスペア用に予約された2つのスロットがあります。システム内のコンピュート・ノード容量の拡張については、Oracle担当者に連絡してください。コンピュート・ノードのハードウェア構成の詳細は、「サーバー・コンポーネント」を参照してください。

サーバー・コンポーネント

次の表に、Private Cloud Applianceラックに取り付けられ、現在のソフトウェア・リリースでサポートされるサーバー・モデルのコンポーネントを示します。

数量	Oracle Server X9-2管理ノード	Oracle Server X9-2コンピュート・ノード
1	Oracle Server X9-2基本シャーシ	Oracle Server X9-2基本シャーシ
2	Intel Xeon Gold 5318Y CPU、24コア、2.10 GHz、165W	Intel Xeon Platinum 8358 CPU、32コア、2.60 GHz、250W
16	16x 64 GB DDR4-3200 DIMM (1TB合計)	16x 64 GB DDR4-3200 DIMM (1TB合計)
2	240GB M.2 SATAブート・デバイスをRAID1ミラーとして構成	240GB M.2 SATAブート・デバイスをRAID1ミラーとして構成
2	3.84 RAID1ミラーとして構成されるTB NVMe SSDストレージ・デバイス
1	リモート管理用のEthernetポート	リモート管理用のEthernetポート
1	OCPv3形式のデュアル・ポート100Gbit Ethernet NICモジュール	OCPv3形式のデュアル・ポート100Gbit Ethernet NICモジュール
2	冗長電源装置およびファン	冗長電源装置およびファン

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

ネットワーク接続の場合、Private Cloud Applianceは、必要な高可用性、帯域幅および速度を提供する物理レイヤーに依存します。これに加えて、ソフトウェア定義スイッチ、ルーター、ゲートウェイおよびトンネルで構成される分散ネットワーク・ファブリックにより、セキュアな分離されたデータ・トラフィックが可能になります - クラウド・リソース間の内部的、およびアプライアンスの外部リソースと外部リソースの両方。

デバイス管理ネットワーク

デバイス管理ネットワークは、すべてのアプライアンス・コンポーネントの管理インタフェースへの内部アクセスを提供します。これらには1Gbit管理スイッチへのEthernet接続があり、すべては次の各アドレス範囲からIPアドレスを受け取ります:

100.96.0.0/23 - すべてのハードウェア・コンポーネントのOracle Integrated Lights Out Manager (ILOM)サービス・プロセッサのIP範囲
100.96.2.0/23 - すべてのハードウェア・コンポーネントの管理インタフェースのIP範囲

デバイス管理ネットワークにアクセスするには、ワークステーションを1Gbit管理スイッチのポート2に接続し、IPアドレス100.96.3.254を接続されたインタフェースに静的に割り当てます。または、データ・センターの管理マシン(bastion hostとも呼ばれる)からPrivate Cloud Applianceデバイス管理ネットワークへの永続的な接続を設定できます。バスチョン・ホストまたは(一時的に)接続されたワークステーションから、接続されているすべてのラック・コンポーネントのILOMおよび管理インタフェースにアクセスできます。バスチョン・ホストの構成の詳細は、「Oracle Private Cloud Applianceインストレーション・ガイド」の「オプションのバスチョン・ホスト・アップリンク」セクションを参照してください。

1Gbit管理スイッチのポート1は、サポート担当者のみが使用できるように予約されています。

データ・ネットワーク

アプライアンスのデータ接続は、リーフ・スパイン・トポロジに似た2レイヤー設計の冗長100Gbitスイッチ上に構築されます。リーフ・スイッチはラック・ハードウェア・コンポーネントを相互接続しますが、スパイン・スイッチはネットワークのバック・ボーンを形成し、外部トラフィックのパスを提供します。各リーフ・スイッチは、相互に接続されているすべてのスパイン・スイッチに接続されます。このトポロジの主な利点は、拡張性とパスの最適化です。 Private Cloud Applianceラックには、2つのリーフ・スイッチと2つのスパイン・スイッチがあります。

データ・スイッチは、ポート当たり最大スループット100Gbitを提供します。スパイン・スイッチは5つのインター・リンク(500Gbit)を使用し、リーフ・スイッチは各スパインに2つのインター・リンク(200Gbit)および2x2クロス・リンクを使用します。各サーバー・ノードは、モードで2つの100GビットEthernetポートで構成されるbond0インタフェースを介して、ラック内の両方のリーフ・スイッチに接続されます。 2つのストレージ・コントローラは、4x100Gbit接続を使用してスパイン・スイッチに接続されます。

外部接続の場合、各スパイン・スイッチに5つのポートが予約されます。アプライアンスとデータセンター・ネットワークの間にアップリンクを確立するために4つのポートを使用できます。データ・トラフィックから管理ネットワークをオプションで分離するために、1つのポートが予約されています。

アップリンク

Private Cloud Applianceと顧客データ・センターの間の接続は、「アップリンク」と呼ばれます。アプライアンス・ラックの2つのスパイン・スイッチと1つまたは2つのスパイン・スイッチの間の物理ケーブル接続 - 好む - データセンター・インフラストラクチャ内の2つの次レベルのネットワーク・デバイス。物理的な側面に加えて、アップリンクに対する論理的な側面もあります: アプライアンスと接続先の外部ネットワークとの間のトラフィックのルーティング方法。

物理接続

各スパイン・スイッチで、データセンター・ネットワークへのアップリンクにポート1-4を使用できます。 10Gbpsまたは25Gbpsの速度の場合、スパイン・スイッチ・ポートはMPO-to-4xLCのブレーク・アウト・ケーブルを使用して分割する必要があります。 40Gbpsまたは100Gbpsの速度では、各スイッチ・ポートが単一のMPO-to-MPOケーブル接続を使用します。スイッチ・ポートが適切なブレーク・アウト・モードおよび転送速度で構成されるように、初期設定時に正しい接続速度を指定する必要があります。

アップリンクは、インストール・チェック・リストの一部として指定した情報に基づいて、システムの初期化中に構成されます。使用されていないスパイン・スイッチ・アップリンク・ポート(未使用ブレーク・アウト・ポートを含む)は、セキュリティ上の理由から無効になっています。この表は、サポートされるアップリンク構成をポート数と速度、結果の帯域幅の合計を示しています。

アップリンク速度	スパイン・スイッチごとのアップリンク数	合計帯域幅
10 Gbps	1, 2, 4, 8, または 16	20、40、80、160または320 Gbps
25 Gbps	1, 2, 4, 8, または 16	50、100、200、400、または800 Gbps
40 Gbps	1, 2, または 4	80、160または320 Gbps
100 Gbps	1, 2, または 4	200、400または800 Gbps

構成されているポート数やポート速度に関係なく、スパイン・スイッチとデータセンター・ネットワークの間のアップリンクのトポロジも選択します。この情報は、ネットワーク管理者がデータ・センター・スイッチでリンク・アグリゲーション(ポート・チャネル)を構成するために重要です。次の表に、使用可能なオプションを示します。

トポロジ	説明
三角形	三角形のトポロジでは、両方のスパイン・スイッチからのすべてのケーブルが1つのデータセンター・スイッチに接続されます。
正方形	四角形のトポロジでは、2つのデータセンター・スイッチが使用されます。特定のスパイン・スイッチからのすべてのアウトバウンド・ケーブルが同じデータセンター・スイッチに接続されます。
Mesh	メッシュ・トポロジでは、2つのデータ・センター・スイッチも使用されます。四角形トポロジとの違いは、アップリンクがクロス・パターン内に作成される点です。各スパイン・スイッチからのアウトバウンド・ケーブルはペアで接続されます: 各データセンター・スイッチへの1本のケーブル。

参照トポロジ

アプライアンスからデータセンター・ネットワークへのアップリンクの物理トポロジは、帯域幅要件および使用可能なデータセンター・スイッチおよびポートによって異なります。単一のデータ・センター・スイッチに接続すると、三角形のトポロジを選択することになります。冗長性を高めるには、データセンター・スイッチのペアにアップリンクを分散し、四角形またはメッシュ・トポロジを選択します。各トポロジでは、最小限の帯域幅から開始でき、必要に応じてスケール・アップできます。データセンターのスイッチ、トランシーバ、およびケーブルで許可されている場合、最大帯域幅は800 Gbpsです。

次の図は、サポートされているトポロジのサブセットを表しており、アプライアンスをデータセンター・ネットワークに統合するためのリファレンスとして使用できます。図と注記を使用して、設置に適した配線とスイッチ構成を決定します。

サポートされるアップリンク・トポロジの6つの例を示す図。例については、次の図のノートで説明します。

ダイアグラム・ノート

アプライアンス側には、データセンター・ネットワークに接続する必要があるスパイン・スイッチが2つあります。両方のスパイン・スイッチに同じポートとケーブル構成が必要です。各例では、スパイン・スイッチが下部に表示され、すべてのアップリンク・ポートがポート番号で識別されます。線は、各例の最上部にポート番号のないデータセンター・スイッチへの送信ケーブル接続を表します。

配線パターンとポート速度

合計には6つの例があり、2つの行に3つの列で構成されています。

上の行は、フル・ポート100Gbps接続または40Gbps接続に基づく配線オプションを示しています。下の行には、25Gbpsまたは10Gbpsの速度でブレーク・アウト・ポートを使用する配線オプションが表示されます。1-4の小さいボックスには、スパイン・スイッチごとに4つのメイン・アップリンク・ポートそれぞれに対するブレーク・アウト接続が表示されます。
3列目には、フル・ポート接続とブレーク・アウト接続がある三角形のトポロジが表示されます。列2との違いは、すべてのアップリンクが1つのデータセンター・スイッチに接続されることです。合計帯域幅は同じですが、三角形トポロジにはデータセンター・スイッチの冗長性がありません。
四角形トポロジには図がありません。四角形の配線構成は、メッシュの例に似ていますが、交差パターンはありません。図内のすべてのコネクタは、視覚的に平行になります。四角形のトポロジでは、1つのスパイン・スイッチからのすべての送信ケーブルが、ポートに対して同じデータセンター・スイッチに接続されます。メッシュとは異なり、四角形は各スパイン・スイッチが1つのデータ・センター・スイッチでのみピアリングされることを意味します。

リンク数

アップリンクを接続するときは、スパイン・スイッチ・ポートの番号付けに従う必要があります。両方のスパイン・スイッチが同じケーブルで接続されるため、各アップリンクまたは接続はケーブルのペアに対応します。

スパインポートごとに1つのケーブル(100または40 Gbpsトランシーバを使用)では、最初のアップリンク・ペアは「1」のスパイン・スイッチ・ポートを使用し、2つ目はポート2を使用します。この構成では、アップリンクの最大数はスパイン・スイッチあたり4つです。
25または10Gbpsのポート速度でブレーク・アウト・ケーブルを使用する場合、最初のアップリンク・ペアはポート1/1を使用します。スパイン・スイッチあたり2つまたは4つのアップリンクでは、使用中のフル・ポートは1つのみです。スパイン・スイッチごとにアップリンク数を8に増やすと、ポート1/1-2/4は使用中です。スパイン・スイッチあたり16アップリンクでは、4つの予約済みポートすべてのブレーク・アウト接続が使用されます。
メッシュ・トポロジでは、特定の配線パターンに従う必要があります: すべてのアップリンクの前半を1つのデータセンター・スイッチに接続し、後半をもう1つのデータセンター・スイッチに接続します。次に例を示します: 4つのアップリンクがある場合、最初の2つは同じスイッチに移動します。8つのアップリンクがある場合(図には示されていません)、最初の4つは同じスイッチに移動します。16つのアップリンクがある場合、最初の8つは同じスイッチに移動します。

メッシュ・トポロジの意味

メッシュ・トポロジでは、スパイン・スイッチ構成では、すべてのアップリンクの前半が1つのデータセンター・スイッチに接続され、後半がほかのデータセンター・スイッチに接続されると想定されます。アプライアンスをデータ・センター・ネットワークに初めて接続する場合、このパターンに従うことは簡単です。
ただし、あとでアップリンクの数を増やすと、メッシュの配線パターンは既存のアップリンクに大きな影響を与えます。最初の2列の図を比較: アップリンク数を倍にした場合、既存の接続の半分をほかのデータセンター・スイッチに移動する必要があります。 100/40Gビット・アップリンクの場合、リンク数を2から4に増やす場合にのみ、再配線が必要です。ケーブルの数が多いため、25/10Gビット・アップリンクの再配線が必要になります: アップリンク数を2から4、4から8、および8から16に増やす場合。

論理接続

アプライアンスとデータ・センター間の論理接続は、すべて第3層に実装されます。 OSIモデル(オープン・システム相互接続モデル)では、レイヤー3はネットワーク・レイヤーと呼ばれ、接続されているデバイス間のトラフィックをルーティングするために、ヘッダー内のソースと宛先のIPアドレス・フィールドを使用します。

Private Cloud Applianceでは、2つの論理接続オプションがサポートされています: 静的ルーティングと動的ルーティングのいずれかを選択する必要があります。どちらのルーティング・オプションも、3つの物理トポロジすべてでサポートされています。

接続タイプ	説明
静的ルーティング	静的ルーティングが選択されている場合、すべてのエグレス・トラフィックは、データ・センター・ネットワーク・デバイスで構成された単一のデフォルト・ゲートウェイIPアドレスを通過します。このゲートウェイIPアドレスは、スパイン・スイッチから到達できるように、アプライアンスのアップリンクIPアドレスと同じサブネット内にある必要があります。データセンター・ネットワーク・デバイスは、2-3899の範囲のVLAN IDでSVI (スイッチ仮想インタフェース)を使用できます。仮想クラウド・ネットワーク(VCN)内で構成されているすべてのゲートウェイには、外部宛先を目的としたすべてのトラフィックをデフォルト・ゲートウェイのIPアドレスに送信するルート・ルールが自動的に設定されます。
動的ルーティング	動的ルーティングが選択されると、2つのAutonomous Systems間のTCP接続を確立するためにBGP (Border Gateway Protocol)が使用されます: アプライアンス・ネットワークとデータ・センター・ネットワーク。この構成では、接続の両側に登録済またはプライベートASN (Autonomous System Number)が必要です。 Private Cloud Appliance BGP構成では、デフォルトでASN 136025が使用されます。これは、初期構成中に変更できます。 BGPルーティングの場合、データ・センターの2つのルーティング・デバイスをアプライアンス・ラックの2つのスパイン・スイッチに接続する必要があります。スパイン・スイッチとデータ・センター・ネットワーク・デバイス間の対応するインタフェース(ポート・チャネル)は同じサブネット内にある必要があります。ルート・ハンド・オフ・ネットワークとも呼ばれる、ポイント・ツー・ポイント回線ごとに専用の /30サブネットを使用することをお薦めします。この設定によって、冗長性とマルチパスが提供されます。動的ルーティングは、両方のスパイン・スイッチが同じデータ・センター・ネットワーク・デバイスに物理的に接続されている三角形のトポロジでもサポートされています。この構成では、2つのBGPセッションがまだ確立されています: 各スパイン・スイッチから1つ。ただし、この方法では冗長性のレベルが低下します。

接続タイプ

説明

静的ルーティング

静的ルーティングが選択されている場合、すべてのエグレス・トラフィックは、データ・センター・ネットワーク・デバイスで構成された単一のデフォルト・ゲートウェイIPアドレスを通過します。このゲートウェイIPアドレスは、スパイン・スイッチから到達できるように、アプライアンスのアップリンクIPアドレスと同じサブネット内にある必要があります。データセンター・ネットワーク・デバイスは、2-3899の範囲のVLAN IDでSVI (スイッチ仮想インタフェース)を使用できます。

仮想クラウド・ネットワーク(VCN)内で構成されているすべてのゲートウェイには、外部宛先を目的としたすべてのトラフィックをデフォルト・ゲートウェイのIPアドレスに送信するルート・ルールが自動的に設定されます。

動的ルーティング

動的ルーティングが選択されると、2つのAutonomous Systems間のTCP接続を確立するためにBGP (Border Gateway Protocol)が使用されます: アプライアンス・ネットワークとデータ・センター・ネットワーク。この構成では、接続の両側に登録済またはプライベートASN (Autonomous System Number)が必要です。 Private Cloud Appliance BGP構成では、デフォルトでASN 136025が使用されます。これは、初期構成中に変更できます。

BGPルーティングの場合、データ・センターの2つのルーティング・デバイスをアプライアンス・ラックの2つのスパイン・スイッチに接続する必要があります。スパイン・スイッチとデータ・センター・ネットワーク・デバイス間の対応するインタフェース(ポート・チャネル)は同じサブネット内にある必要があります。ルート・ハンド・オフ・ネットワークとも呼ばれる、ポイント・ツー・ポイント回線ごとに専用の /30サブネットを使用することをお薦めします。この設定によって、冗長性とマルチパスが提供されます。

動的ルーティングは、両方のスパイン・スイッチが同じデータ・センター・ネットワーク・デバイスに物理的に接続されている三角形のトポロジでもサポートされています。この構成では、2つのBGPセッションがまだ確立されています: 各スパイン・スイッチから1つ。ただし、この方法では冗長性のレベルが低下します。

サポートされるルーティング設計

次の表に、データ・センターの物理トポロジおよび実装対象として選択した論理接続に応じてサポートされるルーティング設計を示します。

複数のデバイス(vPCまたはMLAG)間のリンク・アグリゲーションは、静的ルーティングでのみサポートされています。動的ルーティングを選択すると、リンクアグリゲーションは同じスイッチのポートに制限されます。

メッシュ・トポロジでアップリンクが接続されている場合は、スパイン・スイッチごとに最低2つの物理接続が適用されます。 BGPピアリングを確立するには、2つのサブネットが必要です。アップリンク・カウントが変更された場合、ポート・チャネルは再構成されますが、専用サブネットは同じままです。

論理接続	物理トポロジ	ルーティング設計
論理接続	物理トポロジ	単一サブネット	デュアル・サブネット	vPC/MLAG
静的ルーティング	正方形	はい	はい	はい
	Mesh	はい	はい	はい
	三角形	はい	はい	はい
動的ルーティング	正方形	はい	-	-
	Mesh	-	はい	-
	三角形	はい	-	-

アップリンク・プロトコル

データセンターへのアップリンクは、さまざまなプロトコルを実行して冗長性を確保し、これらのリンクでのリンク障害の検出およびリカバリ時間を短縮します。これらのプロトコルは、三角形、四角形、またはメッシュ・トポロジで動作します。

アップリンク・プロトコルのスイートには、次のものがあります:

双方向転送検出(BFD)
仮想ルーター冗長プロトコル(VRRP)
ホット・スペア・ルーター・プロトコル(HSRP)
Equal Cost Multi-Path (ECMP)

それぞれの詳細は、このトピックの次の項を参照してください。

BFD

ほとんどのルーター・ネットワークでは、ルーティング・プロトコルによって送信された「hello」パケットの損失によって、接続の障害が検出されます。ただし、このメソッドによる検出には1秒以上かかることが多く、高速リンク上のパケットの多くを到達できない宛先にルーティングします。これにより、リンクバッファがバー・デンされます。「hello」パケット・レートを増やすと、ルーターCPUがバー・デンします。

BFD (Bidirectional Forwarding Detection)は、障害が発生したリンクの最後にルーターに警告する組み込みのメカニズムで、他のメカニズムよりも早く問題が発生し、バッファやCPUの負荷を軽減します。 BFDは、ルーター間にスイッチまたはハブが存在する場合でも機能します。

BFDは構成を必要とせず、ユーザー設定可能なパラメータもありません。

VRRPv3

仮想ルーター冗長プロトコル・バージョン3 (VRRPv3)は、仮想ルーターの概念を使用して物理ルーターをグループ化し、参加しているホストに1つとして表示されるようにするネットワーク・プロトコルです。これにより、IPサブネット・ワーク上のデフォルト・ゲートウェイの自動選択によってルーティング・パスの可用性と信頼性が向上します。

VRRPv3を指定すると、プライマリ/アクティブおよびセカンダリ/スタンバイ・ルーターが1つの仮想ルーターとして機能します。この仮想ルーターは、VRRPv3に参加しているサブネット上の任意のホストのデフォルト・ゲートウェイになります。グループ内の1つの物理ルーターが、パケット転送のプライマリ/アクティブのルーターになります。ただし、このルーターに障害が発生した場合、グループ内の別の物理ルーターが転送ロールを引き継ぎ、ルーター構成に冗長性を追加します。 VRRPv3 "network"はローカル・サブネットに制限され、ローカル・サブネットを超えるルートは通知されません。

HSRP

Ciscoルーターでは、多くの場合、プロトコル(HSRP)と呼ばれる冗長プロトコルを使用してルーターの可用性を向上させます。 VRRPのメソッドと同様に、HSRPは物理ルーターを単一の仮想ルーターにグループ化します。物理的なデフォルト・ルーターに障害が発生すると、別のルーターがHSRPを使用して、ホスト・デバイスにストレスをかけずにパケットのデフォルトの転送を引き継ぐことになります。

ECMP

Equal Cost Multi-Path (ECMP)は、特に多くの冗長リンクを持つより複雑なネットワークで、ネットワーク帯域幅をより効果的に使用する方法です。

通常、別の宛先ネットワークへの複数のルーター・パスを持つルーター・ネットワークは、ゲートウェイ・ルーターへの1つのアクティブなルートを「最適な」パスとして選択し、障害発生時にほかのパスをスタンバイとして使用します。使用するネットワーク・ゲートウェイ・ルーターへのパスに関するディシジョンは、通常、ルーティング・プロトコルのパースペクティブから「コスト」によってディシジョンされます。ネットワーク・ゲートウェイに到達するための複数のリンクのコストが等しい場合、ルーターは条件に基づいて1つを選択します。これにより、ルーティングのディシジョンが容易になりますが、選択されていないパスのネットワーク・リンクがアイドル状態になるため、ネットワーク帯域幅が無駄になります。

ECMPは、複数のパス・リンクで同じコストでトラフィックを送信できるため、ネットワーク帯域幅をより効率的に使用できます。

管理ネットワーク

セキュリティ要件が高まる環境では、オプションで管理アプライアンスへのアクセスをデータ・トラフィックから分離できます。管理ネットワークは、アプライアンス管理操作のための専用のセキュアなネットワーク・パスを提供することによって、構成および管理トラフィックをデータ・ネットワーク上の操作アクティビティと物理的に分離します。この構成では、「サービス・エンクレーブ」全体には管理ネットワークを介してのみアクセスできます。これには、モニタリング、メトリック収集およびアラート・サービス、APIサービスおよびすべてのコンポーネント管理インタフェースも含まれます。

管理ネットワークを設定するには、次レベルのデータセンター・ネットワーク・デバイスからアプライアンス内の各スパイン・スイッチ上のポート5への追加のEthernet接続が必要です。管理ネットワーク内では、スパイン・スイッチはそれぞれ1つのIPアドレスと、2つの間で共有される仮想IPを持つ必要があります。トラフィックをルーティングするにはデフォルト・ゲートウェイが必要であり、NTPおよびDNSサービスを有効にする必要があります。管理ノードには、管理ネットワークでホスト名とIPアドレスを割り当てる必要があります - それぞれ1つずつ、3つすべてで1つずつ共有されます。

静的ルーティングと動的ルーティングの両方で別の管理ネットワークを使用できます。 VLANの使用がサポートされていますが、静的ルーティングと組み合わせると、VLAN IDがデータ・ネットワーク用に構成されたものと異なる必要があります。

予約済ネットワーク・リソース

Private Cloud Applianceのネットワーク・インフラストラクチャおよびシステム・コンポーネントでは、内部操作に多数のIPアドレスと複数のVLANが必要です。顧客データ・センターで使用されているアドレスと、仮想クラウド・ネットワーク(VCN)で構成されたCIDR範囲との競合を回避することが重要です。

これらのIPアドレス範囲は、Private Cloud Applianceによって内部使用のために予約されています:

予約済IPアドレス	説明
共有アドレス領域のCIDRブロック	IP範囲100.64.0.0/10,を持つ共有アドレス・スペースは、顧客構内機器をインターネット・サービス・プロバイダのコア・ルーターに接続するために実装されました。 IPアドレスを管理インタフェースおよびハードウェア・コンポーネントのILOM (Oracle Integrated Lights Out Manager)に割り当てるには、2つのCIDRブロックが内部使用のために予約されています: 100.96.0.0/23および100.96.2.0/23。
クラスEアドレス範囲のCIDRブロック	クラスEは、クラス・フル・ネットワーク・アドレス指定アーキテクチャで、240.0.0.0から255.255.255.255までの32ビットIPv4アドレス空間の一部です。その時点では、将来の使用のために予約されているため、パブリック・インターネットでは使用できません。物理100Gbit接続を介したすべてのインフラストラクチャ・ネットワーキングのアドレス指定要件に対応するため、253.255.0.0/16サブネット全体が予約されます。 IPアドレスをネットワーク関数またはタイプ別にグループ化するために、さらに複数のCIDRブロックに分割されます。 253.255.0.0/16範囲内の様々なCIDRブロックは、マイクロサービスを実行しているKubernetesコンテナ、仮想スイッチ、ルーターおよびゲートウェイ(VCNデータ・ネットワーク、ハイパーバイザ、アプライアンス・シャーシ・コンポーネントなど)のIPアドレスを割り当てるために使用されます。
ローカルCIDRブロックのリンク	リンク・ローカル・アドレスは、169.254.0.0/16 IP範囲に属し、ホスト・ネットワーク・セグメント内の接続にのみ有効です。これは、アドレスはそのネットワーク・セグメントの外部で一意であることが保証されないためです。リンク・ローカルのソース・アドレスまたは宛先アドレスを持つパケットは、ルーターによって転送されません。リンク・ローカルCIDRブロック169.254.239.0/24,およびIPアドレス169.254.169.254は、DNSリクエスト、コンピュート・インスタンスのメタデータ転送、クラウド・サービス・エンドポイントなどの機能用に予約されています。

予約済IPアドレス

説明

共有アドレス領域のCIDRブロック

IP範囲100.64.0.0/10,を持つ共有アドレス・スペースは、顧客構内機器をインターネット・サービス・プロバイダのコア・ルーターに接続するために実装されました。

IPアドレスを管理インタフェースおよびハードウェア・コンポーネントのILOM (Oracle Integrated Lights Out Manager)に割り当てるには、2つのCIDRブロックが内部使用のために予約されています: 100.96.0.0/23および100.96.2.0/23。

クラスEアドレス範囲のCIDRブロック

クラスEは、クラス・フル・ネットワーク・アドレス指定アーキテクチャで、240.0.0.0から255.255.255.255までの32ビットIPv4アドレス空間の一部です。その時点では、将来の使用のために予約されているため、パブリック・インターネットでは使用できません。

物理100Gbit接続を介したすべてのインフラストラクチャ・ネットワーキングのアドレス指定要件に対応するため、253.255.0.0/16サブネット全体が予約されます。 IPアドレスをネットワーク関数またはタイプ別にグループ化するために、さらに複数のCIDRブロックに分割されます。

253.255.0.0/16範囲内の様々なCIDRブロックは、マイクロサービスを実行しているKubernetesコンテナ、仮想スイッチ、ルーターおよびゲートウェイ(VCNデータ・ネットワーク、ハイパーバイザ、アプライアンス・シャーシ・コンポーネントなど)のIPアドレスを割り当てるために使用されます。

ローカルCIDRブロックのリンク

リンク・ローカル・アドレスは、169.254.0.0/16 IP範囲に属し、ホスト・ネットワーク・セグメント内の接続にのみ有効です。これは、アドレスはそのネットワーク・セグメントの外部で一意であることが保証されないためです。リンク・ローカルのソース・アドレスまたは宛先アドレスを持つパケットは、ルーターによって転送されません。

リンク・ローカルCIDRブロック169.254.239.0/24,およびIPアドレス169.254.169.254は、DNSリクエスト、コンピュート・インスタンスのメタデータ転送、クラウド・サービス・エンドポイントなどの機能用に予約されています。

すべてのVCNトラフィック - あるVCNから別のVCNへ、さらにVCNと外部リソースの間 - 100Gbit接続にまたがり、VLAN 3900によって伝送されます。サーバー管理に関連するトラフィックはVLAN 3901によって伝送されます。より高いIDを持つすべてのVLANは内部使用のために予約され、VLAN 1はタグなしトラフィックのデフォルトです。残りのVLAN範囲2-3899は、お客様が使用可能です。

Oracle Exadata統合

オプションで、Private Cloud ApplianceをOracle Exadataと統合して、コンピュート容量とデータベース最適化の高パフォーマンスな組合せを実現できます。この構成では、データベース・ノードはPrivate Cloud Applianceのスパイン・スイッチの予約済ポートに直接接続されます。スパイン・スイッチごとに4つの100Gbitポートが予約され、4x25Gbitブレーク・アウト・ポートに分割され、合計で最大32のケーブル接続が実現されます。各データベース・ノードは両方のスパイン・スイッチに直接接続されています。つまり、最大16個のデータベース・ノードをアプライアンスに接続できます。異なるOracle Exadataラックからデータベース・ノードに接続できます。

ケーブル接続が確立されると、管理者は、接続されたデータベース・ノードと一連のコンピュート・インスタンス間のトラフィックを有効にする「Exadataネットワーク」を構成します。次の前提条件が適用されます:

Exadataネットワークは、オンプレミス・ネットワークのサブネットと重複できません。
データベース・ノードに接続するコンピュート・インスタンスを含むVCNには、動的ルーティング・ゲートウェイ(DRG)が構成されている必要があります。
関連するサブネット・ルート表には、Exadataネットワークとの間のトラフィックを許可するルールが含まれている必要があります。

Exadataネットワーク構成によって、公開されているExadataクラスタとそれらのクラスタにアクセスできるサブネットが決まります。アクセスは、Exadataクラスタごと、およびコンピュート・サブネットごとに有効化または無効化できます。また、Exadataネットワークはアプライアンスの外部ネットワークを介して公開できるため、オンプレミス・ネットワーク内の他のリソースは、アプライアンスのスパイン・スイッチを介してデータベース・ノードに接続できます。 Exadataネットワーク構成は、「サービスCLI」を使用して作成および管理されます。

ストレージ

Private Cloud Applianceには、ベース・ストレージ・オプションとしてOracle ZFS Storage Appliance ZS9-2が含まれており、必要に応じてラック内のストレージを拡張する機能があります。

Oracle ZFS Storage Appliance ZS9-2

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

アプライアンスのデフォルトのディスク・シェルフには、パブリック・オブジェクト・ストレージ、顧客コンピュート・イメージおよび顧客ブロック・ストレージ用の100 TBを超える使用可能なストレージがあります。

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

クラスタ化された2つのストレージ・コントローラ・ヘッド
18TBのハード・ディスクが20個のフル構成のディスク・シャーシ
ディスク・シェルフに取り付けられている4つのキャッシュ・ディスク: 2x 200GB SSDおよび2x 7.68TB SSD
ミラー化された構成、最適なデータ保護

ストレージ・アプライアンスは、管理サブネットおよびストレージ・サブネットに接続されています。両方のヘッドはアクティブ/アクティブ構成でクラスタを形成し、1つのストレージ・ヘッドに障害が発生した場合にサービスの継続を保証します。ストレージ・ヘッドはストレージ・サブネットに2つのIPを提供: 1つはデフォルトの容量ストレージ・プール用で、もう1つはオプションのパフォーマンス(SSD)ストレージ・プールにアクセスします。 4つの管理IPアドレスが提供されます: 1つは各コントローラ・ヘッドにローカル、もう1つはコントローラ間のプール・リソースに従うストレージ・プールごとに1つはテイクオーバーまたはフェイルバック・イベントを超過し、メンテナンス・アクセスを便利にします。プライマリ・ミラー化容量ストレージ・プールには、PCAおよびprivate_ostore_projectという2つのプロジェクトが含まれます。

追加記憶域

オプションで、システム・フレックス・ベイにディスク・シェルフを追加することによって、システムのストレージを増やすことができます。拡張に使用できるストレージ・オプションは、Oracle Storage Drive Enclosure DE3-24CおよびOracle Storage Drive Enclosure DE3-24Pです。

Oracle Storage Drive Enclosure DE3-24Cのサポートされるハードウェア構成は次のとおりです:

20台の18TBハード・ディスクを搭載したフル装備ディスク・シャーシ
ディスク・シェルフに取り付けられている4つのキャッシュ・ディスク: 2x 200GB SSDおよび2x 7.68TB SSD

Oracle Storage Drive Enclosure DE3-24Pのサポートされるハードウェア構成は次のとおりです:

20個の7.68 TB SSD
ディスク・シェルフに取り付けられた2つのキャッシュ・ディスク: 2x 200GB SSD
ドライブ・ベイ・フィラー2台

追加のOracle Storage Drive Enclosure DE3-24Cエンクロージャに含まれるストレージ・デバイスは、プライマリ容量ストレージ・プールに自動的に追加されます。一方、Oracle Storage Drive Enclosure DE3-24Pエンクロージャに含まれるデバイスは、エンクロージャがインストールされてストレージ・コントローラに接続されると、オプションの高パフォーマンス・ストレージ・プールに自動的に追加されます。