第2章 ハードウェアの概要
この章では、Oracle Private Cloud Applianceを構成するハードウェア・コンポーネントの概要について説明: サーバー、スイッチ、およびストレージを備えた基本ラック。 各セクションでは、各コンポーネントのロールについて説明します。 アプライアンスのネットワーク・インフラストラクチャ、およびデータ・センター環境(オプションでExadataシステム)との統合方法に特別な注意を払います。
2.1 基本ラック・コンポーネント
ファクトリ出荷時にインストールされたソフトウェア・リリース3.0.1を持つ現在のOracle Private Cloud Applianceハードウェア・プラットフォームは、Oracle Rackキャビネット1242ベースで構成され、「図2.1」で識別されるハードウェア・コンポーネントが移入されます。 この図は完全な構成を示していますが、必要に応じて異なるストレージまたはコンピュート容量を含めるようにシステムをカスタマイズできます。
リリース3.0.1以降、フレックス・ベイの概念はOracle 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 |
ストレージ・コントローラ |
2.2 サーバー
これらのセクションでは、Oracle Private Cloud Applianceで使用される管理ノードとコンピュート・ノードについて説明します。
2.2.1 Management Nodes
各Oracle Private Cloud Applianceインストールの中心は、3つの管理ノードです。 これらはラック・ユニット5、6および7に取り付けられ、高可用性のためのクラスタを形成: すべてのサーバーが同じコントローラ・ソフトウェアとシステムレベルのサービスを実行でき、システム構成に等しくアクセスでき、3つのすべてのサーバーが完全にアクティブなクラスタとしてシステムを管理します。 管理ノード・コンポーネントの詳細は、第2.2.3項、「サーバー・コンポーネント」を参照してください。
管理ノードは、コントローラ・ソフトウェアを実行し、Oracle Private Cloud Applianceの操作および管理を担当するサービスのコレクションの基盤を提供します。 管理クラスタの役割には、システム・ハードウェアのモニタリングと保守、システムの可用性の確保、ソフトウェアとファームウェアのアップグレード、アプライアンスのバックアップとリストア、障害リカバリの管理などがあります。 管理ノード・サービスの概要は、「第3章 アプライアンス管理の概要」を参照してください。 管理機能の実行手順については、「Oracle Private Cloud Appliance管理者ガイド」を参照してください。
アプライアンス・インフラストラクチャが制御されるシステムの部分は、管理ノード・クラスタで実行されるサービス・エンクレーブと呼ばれ、サービスCLIまたはサービスWeb UIを介してアクセスできます。 アクセスは厳密に監視され、特権管理者に制限されます。 詳細は、第3.1項、「管理者アクセス」および「Oracle Private Cloud Appliance管理者ガイド」の「サービス・エンクレーブでの作業」セクションを参照してください。
2.2.2 計算ノード
Oracle Private Cloud Applianceのコンピュート・ノードはハードウェア・レイヤーの一部であり、コンピュート・インスタンスをホストするための処理能力およびメモリー容量を提供します。 ハードウェア層の管理は、アプライアンスのプラットフォームとサービス・レイヤーによって提供されます。 レイヤー・アーキテクチャ・アプローチの詳細は、「アーキテクチャと設計」を参照してください。
システムが初期化されると、コンピュート・ノードは管理サービスによって自動的に検出され、プロビジョニング準備完了状態になります。 管理者は、サービス・エンクレーブを介してコンピュート・ノードをプロビジョニングでき、すぐに使用できます。 後の段階で追加のコンピュート・ノードをインストールすると、新しいノードが検出され、電源が投入され、同じメカニズムによって自動的に検出されます。
管理者は、Oracle Private Cloud Appliance Service Web UIまたはサービスCLIからコンピュート・ノードのヘルスおよびステータスをモニターしたり、コンピュート・ノードをテナンシに割り当てる、コンピュート・ノード・コンポーネントのアップグレードなどのその他の操作を実行できます。 一般的な管理情報については、「アプライアンス管理の概要」を参照してください。 コンピュート・リソースの管理の詳細は、「コンピュート・インスタンス」を参照してください。
ベース・ラックの最小構成には3つのコンピュート・ノードが含まれますが、コンピュート・ノード用にすべてのフレックス・ベイ・スペースを使用する場合は、一度に3つのノードで拡張できます。 システムは合計で最大20のコンピュート・ノードをサポートでき、例外プロセスでリクエストできるスペア用に予約された2つのスロットがあります。 システム内のコンピュート・ノード容量の拡張については、Oracleの担当者にお問い合わせください。 コンピュート・ノードのハードウェア構成の詳細は、第2.2.3項、「サーバー・コンポーネント」を参照してください。
2.2.3 Server Components
「表2.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-32 |
16x 64 GB DDR4-3200 DIMM (1TB合計) |
16または32個のDDR4-3200 DIMM 使用可能な構成:
|
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 |
冗長電源装置およびファン |
冗長電源装置およびファン |
2.3 ネットワーク・インフラストラクチャ
ネットワーク接続の場合、Oracle Private Cloud Applianceは必要な高可用性、帯域幅および速度を提供する物理レイヤーに依存します。 これに加えて、ソフトウェア定義スイッチ、ルーター、ゲートウェイおよびトンネルで構成される分散ネットワーク・ファブリックにより、セキュアな分離されたデータ・トラフィックが可能になります - クラウド・リソース間の内部的、およびアプライアンスの外部リソースと外部リソースの両方。
2.3.1 デバイス管理ネットワーク
デバイス管理ネットワークは、すべてのアプライアンス・コンポーネントの管理インタフェースへの内部アクセスを提供します。 これらには1Gbit管理スイッチへのEthernet接続があり、すべては次の各アドレス範囲からIPアドレスを受け取ります:
-
100.96.0.0/23 - すべてのハードウェア・コンポーネントのILOMサービス・プロセッサのIP範囲
-
100.96.2.0/23 - すべてのハードウェア・コンポーネントの管理インタフェースのIP範囲
デバイス管理ネットワークにアクセスするには、ワークステーションを1Gbit管理スイッチのポート2に接続し、IPアドレス100.96.3.254を接続されたインタフェースに静的に割り当てます。 または、bastion hostとも呼ばれるデータ・センター管理マシンからOracle Private Cloud Applianceデバイス管理ネットワークへの永続的な接続を設定することもできます。 要塞ホストから、または(一時的に)接続されたワークステーションから、接続されているすべてのラック・コンポーネントのILOMおよび管理インタフェースにアクセスできます。
1Gbit管理スイッチのポート1は、サポート担当者のみが使用できるように予約されています。
2.3.2 データ・ネットワーク
アプライアンスのデータ接続は、リーフ・スパイン・トポロジに似た2レイヤー設計の冗長100Gbitスイッチ上に構築されます。 リーフ・スイッチはラック・ハードウェア・コンポーネントを相互接続しますが、スパイン・スイッチはネットワークのバック・ボーンを形成し、外部トラフィックのパスを提供します。 各リーフ・スイッチは、相互に接続されているすべてのスパイン・スイッチに接続されます。 このトポロジの主な利点は、拡張性とパスの最適化です。 Oracle Private Cloud Applianceラックには、2つのリーフ・スイッチと2つのスパイン・スイッチが含まれます。
データ・スイッチは、ポート当たり最大スループット100Gbitを提供します。 スパイン・スイッチは5つのインター・リンク(500Gbit)を使用し、リーフ・スイッチは各スパインに2つのインター・リンク(200Gbit)および2x2クロス・リンクを使用します。 各サーバー・ノードは、モードで2つの100GビットEthernetポートで構成されるbond0
インタフェースを介して、ラック内の両方のリーフ・スイッチに接続されます。 2つのストレージ・コントローラは、4x100Gbit接続を使用してスパイン・スイッチに接続されます。
外部接続の場合、各スパイン・スイッチに5つのポートが予約されます。 アプライアンスとデータセンター・ネットワークの間にアップリンクを確立するために4つのポートを使用できます。データ・トラフィックから管理ネットワークをオプションで分離するために、1つのポートが予約されています。
2.3.3 アップリンク
Oracle 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です。
次の図は、サポートされているトポロジのサブセットを表しており、アプライアンスをデータセンター・ネットワークに統合するためのリファレンスとして使用できます。 図と注記を使用して、設置に適した配線とスイッチ構成を決定します。

ダイアグラム・ノート
アプライアンス側には、データセンター・ネットワークに接続する必要があるスパイン・スイッチが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アドレス・フィールドを使用します。
Oracle 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)が必要です。 Oracle Private Cloud Appliance BGP構成では、デフォルトでASN 136025が使用されます。これは初期構成時に変更できます。 BGPルーティングの場合、データ・センターの2つのルーティング・デバイスをアプライアンス・ラックの2つのスパイン・スイッチに接続する必要があります。 スパイン・スイッチとデータ・センター・ネットワーク・デバイス間の対応するインタフェース(ポート・チャネル)は同じサブネット内にある必要があります。 ルート・ハンド・オフ・ネットワークとも呼ばれる、ポイント・ツー・ポイント回線ごとに専用の /30サブネットを使用することをお薦めします。 この設定によって、冗長性とマルチパスが提供されます。 動的ルーティングは、両方のスパイン・スイッチが同じデータ・センター・ネットワーク・デバイスに物理的に接続されている三角形のトポロジでもサポートされています。 この構成では、2つのBGPセッションがまだ確立されています: 各スパイン・スイッチから1つ。 ただし、この方法では冗長性のレベルが低下します。 |
サポートされるルーティング設計
次の表に、データ・センターの物理トポロジおよび実装対象として選択した論理接続に応じてサポートされるルーティング設計を示します。
複数のデバイス(vPCまたはMLAG)間のリンク・アグリゲーションは、静的ルーティングでのみサポートされています。 動的ルーティングを選択すると、リンクアグリゲーションは同じスイッチのポートに制限されます。
メッシュ・トポロジでアップリンクが接続されている場合は、スパイン・スイッチごとに最低2つの物理接続が適用されます。 BGPピアリングを確立するには、2つのサブネットが必要です。 アップリンク・カウントが変更された場合、ポート・チャネルは再構成されますが、専用サブネットは同じままです。
論理接続 |
物理トポロジ |
ルーティング設計 |
||
---|---|---|---|---|
単一サブネット |
デュアル・サブネット |
vPC/MLAG |
||
静的ルーティング |
正方形 |
はい |
はい |
はい |
Mesh |
はい |
はい |
はい |
|
三角形 |
はい |
はい |
はい |
|
動的ルーティング |
正方形 |
はい |
- |
- |
Mesh |
- |
はい |
- |
|
三角形 |
はい |
- |
- |
2.3.4 管理ネットワーク
セキュリティ要件が高まる環境では、オプションで管理アプライアンスへのアクセスをデータ・トラフィックから分離できます。 この別の管理ネットワークでは、Service EnclaveとCompute Enclaveの両方の構成および管理インタフェース(UIおよびCLI)にアクセスできます。
管理ネットワークを設定するには、次レベルのデータセンター・ネットワーク・デバイスからアプライアンス内の各スパイン・スイッチ上のポート5への追加のEthernet接続が必要です。 管理ネットワーク内では、スパイン・スイッチはそれぞれ1つのIPアドレスと、2つの間で共有される仮想IPを持つ必要があります。 トラフィックのルーティングには、デフォルト・ゲートウェイも必要です。
静的ルーティングと動的ルーティングの両方で別の管理ネットワークを使用できます。 VLANの使用がサポートされていますが、静的ルーティングと組み合わせると、VLAN IDがデータ・ネットワーク用に構成されたものと異なる必要があります。
2.3.5 予約済ネットワーク・リソース
Oracle Private Cloud Applianceのネットワーク・インフラストラクチャおよびシステム・コンポーネントには、内部操作のために多数のIPアドレスと複数のVLANが必要です。 顧客データ・センターで使用されているアドレスと、仮想クラウド・ネットワーク(VCN)で構成されたCIDR範囲との競合を回避することが重要です。
これらのIPアドレス範囲は、Oracle Private Cloud Applianceによる内部使用のために予約されています:
予約済IPアドレス |
説明 |
---|---|
共有アドレス領域のCIDRブロック |
IP範囲100.64.0.0/10,を持つ共有アドレス・スペースは、顧客構内機器をインターネット・サービス・プロバイダのコア・ルーターに接続するために実装されました。 IPアドレスをハードウェア・コンポーネントの管理インタフェースおよびILOMに割り当てるには、内部使用のために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ブロックは、マイクロサービス、仮想スイッチ、ルーターおよびゲートウェイによってVCNデータ・ネットワーク、ハイパーバイザ、アプライアンス・シャーシ・コンポーネントなどを有効化するKubernetesコンテナの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は、お客様が使用可能です。
2.3.6 Exadata統合
オプションで、Oracle Private Cloud ApplianceをOracle Exadataと統合して、コンピュート容量とデータベース最適化のパフォーマンスの高い組合せを実現できます。 この構成では、データベース・ノードはOracle Private Cloud Applianceのスパイン・スイッチの予約済ポートに直接接続されています。 スパイン・スイッチごとに4つの100Gbitポートが予約され、4x25Gbitブレーク・アウト・ポートに分割され、合計で最大32のケーブル接続が実現されます。 各データベース・ノードは両方のスパイン・スイッチに直接接続されています。つまり、最大16個のデータベース・ノードをアプライアンスに接続できます。 異なるExadataラックからデータベース・ノードを接続できます。
ケーブル接続が確立されると、管理者は、接続されたデータベース・ノードと一連のコンピュート・インスタンス間のトラフィックを有効にする「Exadataネットワーク」を構成します。 次の前提条件が適用されます:
-
Exadataネットワークは、オンプレミス・ネットワークのサブネットと重複できません。
-
データベース・ノードに接続するコンピュート・インスタンスを含むVCNには、動的ルーティング・ゲートウェイ(DRG)が構成されている必要があります。
-
関連するサブネット・ルート表には、Exadataネットワークとの間のトラフィックを許可するルールが含まれている必要があります。
Exadataネットワーク構成によって、公開されているExadataクラスタとそれらのクラスタにアクセスできるサブネットが決まります。 アクセスは、Exadataクラスタごと、およびコンピュート・サブネットごとに有効化または無効化できます。 また、Exadataネットワークはアプライアンスの外部ネットワークを介して公開できるため、オンプレミス・ネットワーク内の他のリソースは、アプライアンスのスパイン・スイッチを介してデータベース・ノードに接続できます。 Exadataネットワーク構成の作成と管理は、サービスCLIを使用して行います。
2.4 記憶域
Oracle Private Cloud Applianceには、ベース・ストレージ・オプションとしてOracle ZFS Storage Appliance ZS9-2が含まれており、必要に応じてラック内のストレージを拡張できます。
2.4.1 Oracle ZFS Storage Appliance ZS9-2
Oracle ZFS Storage Appliance ZS9-2は、アプライアンス・ラックの下部に設置された2つのコントローラ・サーバーと、ディスク・シェルフの約半分の稼働で構成され、アプライアンス全体のシステム・ディスクのロールを満たします。 Oracle 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つのプロジェクトが含まれます。
2.4.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エンクロージャに含まれるデバイスは、エンクロージャがストレージ・コントローラにインストールされてケーブル接続されると、オプションの高性能ストレージ・プールに自動的に追加されます。