1. Kubernetesクラスタ内のOracle Identity and Access Managementのためのエンタープライズ・デプロイメント・ガイド
  2. エンタープライズ・デプロイメントの準備
  3. オンプレミス・エンタープライズ・デプロイメントの準備

9 オンプレミス・エンタープライズ・デプロイメントの準備

オンプレミス・エンタープライズ・デプロイメントでは、ハードウェア・ロード・バランサとポート、ファイル・システム、オペレーティング・システムおよびKubernetesクラスタを準備します。

この章の内容は次のとおりです。

親トピック: エンタープライズ・デプロイメントの準備

エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

オンプレミス・エンタープライズ・デプロイメントの準備には、トポロジで使用されるファイアウォールで開いておく必要があるハードウェアまたはソフトウェアのロード・バランサおよびポートの構成も含まれます。

親トピック: オンプレミス・エンタープライズ・デプロイメントの準備

ハードウェア・ロード・バランサでの仮想ホストの構成

ハードウェア・ロード・バランサ構成を利用すると、リクエストを認識し、様々な種類のネットワーク・トラフィックや監視に対応する複数の仮想サーバーと関連ポートにリクエストをルーティングすることができます。

次の各項で、ハードウェア・ロード・バランサの構成方法について説明し、必要な仮想サーバーのサマリーとこれらの仮想サーバーに関する追加指示を示します。

親トピック: エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

ハードウェア・ロード・バランサ構成の概要

トポロジのダイアグラムに示すように、リクエストを認識し、様々な種類のネットワーク・トラフィックや監視に対応する複数の仮想サーバーと関連ポートにリクエストをルーティングできるように、ハードウェア・ロード・バランサを構成する必要があります。

ロード・バランシング・デバイスにおける仮想サーバーとは、ロード・バランシングのために複数の物理サーバーを1つのサーバーのように見せかけることができる構成です。仮想サーバーは通常、IPアドレスとサービスによって表され、受信したクライアント・リクエストをサーバー・プール内の各サーバーに配信するために使用されます。

仮想サーバーは、エンタープライズ・デプロイメントで使用可能な各種サービス用の適切なホスト・コンピュータおよびポートにトラフィックをルーティングするように構成しておく必要があります。

さらに、サービスが停止したときに特定のサーバーへのトラフィックをできるだけ早く停止できるように、ホスト・コンピュータとポートの可用性を監視するようにロード・バランサを構成する必要があります。これによって、特定の仮想ホストの着信トラフィックが他の層の使用不可のサービスに送信されることがなくなります。

ロード・バランサを構成した後で、同じ名前を持つ一連の仮想ホストを、ロード・バランサに定義した仮想サーバーとして認識するように、Web層のWebサーバー・インスタンスを構成することも可能です。Webサーバーは、ハードウェア・ロード・バランサから受信した各リクエストを、リクエストのヘッダーに記述されているサーバー名に基づいて適切にルーティングできます。「管理およびOracle Web Services Manager用のOracle HTTP Serverの構成」を参照してください。

トラフィックをワーカー・ノードに転送するようにロード・バランサを構成する場合は、ロード・バランサをネットワーク・ロード・バランサとして構成する必要があります。これにより、ソース・ポートに関係なく、そこに送信されたすべてのトラフィックがターゲット・ノードに転送されます。

ハードウェア・ロード・バランサの構成の一般的な手順

次の手順では、エンタープライズ・デプロイメントのハードウェア・ロード・バランサを構成する標準的なステップの概要を示します。

特定のロード・バランサの実際の構成手順は、ロード・バランサの特定のタイプによって異なります。また、ロード・バランシングされるプロトコルのタイプによっても違いが生じる場合があります。たとえば、TCP仮想サーバーとHTTP仮想サーバーはプールで異なる種類のモニターを使用します。実際のステップは、ベンダーが提供するドキュメントを参照してください。

  1. サーバーのプールを作成します。このプールには、ロード・バランシングの定義に含まれているサーバーとポートのリストが格納されます。

    たとえば、Webホスト間のロード・バランシングの場合、リクエストをポート7777でWEBHOST1およびWEBHOST2のホストに送信するサーバーのプールを作成します。

  2. 特定のホストとサービスが使用可能かどうかを決定するルールを作成し、ステップ1で説明したサーバーのプールに割り当てます。

  3. アプリケーションに対するリクエストを受信するアドレスおよびポートのロード・バランサで必要な仮想サーバーを作成します。

    エンタープライズ・デプロイメントに必要な仮想サーバーの完全なリストは、「エンタープライズ・デプロイメントに必要なロード・バランサ仮想サーバーのサマリー」を参照してください。

    ロード・バランサで各仮想サーバーを定義するときは、次のことを考慮します。

    1. ロード・バランサがこれをサポートする場合は、その仮想サーバーが内部、外部またはその両方で使用可能かどうかを指定します。内部アドレスはネットワーク内からのみ解決可能であることを確認します。

    2. 適用可能な場合は、仮想サーバーに対するSSL終端を構成します。

    3. ステップ1で作成したサーバーのプールを、仮想サーバーに割り当てます。

ロード・バランサのヘルスのモニタリング

ロード・バランサは、ロード・バランサ・プール内のサービスが使用可能であることをチェックするように構成する必要があります。そうしないと、サービスが実行されていないホストにリクエストが送信されます。

次の表で、サービスが使用可能かどうかを判断する方法の例を示します。

表9-1 サービスが使用可能かどうかを判断する方法の例

サービス モニター・タイプ モニター・メカニズム

OUD

ldap

cn=oudadminに対するldapbind

OHS

http

GET /\r\nのチェック
エンタープライズ・デプロイメントに必要なロード・バランサ仮想サーバーのサマリー

このトピックでは、エンタープライズ・デプロイメント用に構成する必要がある仮想サーバーについて詳しく説明します。

次の表は、Oracle Identity and Access Managementエンタープライズ・トポロジのハードウェア・ロード・バランサで定義する必要がある仮想サーバーの一覧です。

表9-2 Oracle Identity and Access Managementエンタープライズ・トポロジのハードウェア・ロード・バランサで定義する必要がある仮想サーバー

仮想ホスト サーバー・プール プロトコル SSL終端かどうか その他の必要な構成/コメント

login.example.com:443

WEBHOST1.example.com:7777

WEBHOST2.example.com:7777

HTTPS

あり

アイデンティティ管理では、次のコードをHTTPヘッダーに追加する必要があります。

ヘッダー名: IS_SSL

ヘッダー値: ssl

ヘッダー名: WL-Proxy-SSL

ヘッダー値: true

prov.example.com:443

WEBHOST1.example.com:7777

WEBHOST2.example.com:7777

HTTPS

あり

アイデンティティ管理では、次のコードをHTTPヘッダーに追加する必要があります。

ヘッダー名: IS_SSL

ヘッダー値: ssl

ヘッダー名: WL-Proxy-SSL

ヘッダー値: true

iadadmin.example.com:80

WEBHOST1.example.com:7777

WEBHOST2.example.com:7777

HTTP

igdadmin.example.com:80

WEBHOST1.example.com:7777

WEBHOST2.example.com:7777

HTTP

igdinternal.example.com:7777

WEBHOST1.example.com:7777

WEBHOST2.example.com:7777

HTTP

oiri.example.com

Kubernetesワーカー・ホスト: 30777

HTTP

いいえ

イングレスが有効になったスタンドアロン・モードでOIRIをデプロイする場合にのみ必要です。

oaaadmin.example.com

Kubernetesワーカー・ホスト: 30636

HTTPS

いいえ

イングレスが有効になったスタンドアロン・モードでOAAをデプロイする場合にのみ必要です。

oaa.example.com

Kubernetesワーカー・ホスト: 307636

HTTPS

いいえ

イングレスが有効になったスタンドアロン・モードでOAAをデプロイする場合にのみ必要です。

ノート:

  • ポート80は、HTTPリクエストに使用されるロード・バランサ・ポートです。

  • ポート443は、HTTPSリクエストに使用されるロード・バランサ・ポートです。

  • ポート7777は、内部コールバック・リクエストに使用されるロード・バランサ・ポートです。

エンタープライズ・デプロイメントのファイアウォールとポートの構成

管理者として、Oracle Fusion Middlewareの様々な製品およびサービスで使用されるポート番号を把握することが重要です。そうすることで、同じポート番号が1つのホスト上の2つのサービスによって使用されないようにし、エンタープライズ・トポロジのファイアウォールで正しいポートを開くことができます。

次の表は、トポロジのファイアウォールで開く必要があるポートの一覧です。

ファイアウォールの説明:

  • FW0は、最も外側のファイアウォールを表します。
  • FW1は、Web層とアプリケーション層の間のファイアウォールを表します。
  • FW2は、アプリケーション層とデータ層との間におけるファイアウォールを示します。

表9-3 すべてのFusion Middlewareエンタープライズ・デプロイメントに共通のファイアウォール・ポート

タイプ ファイアウォール ポートとポートの範囲 プロトコル/アプリケーション インバウンド/アウトバウンド その他の考慮事項とタイムアウトのガイドライン

ブラウザ・リクエスト

FW0

80

HTTP/ロード・バランサ

インバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

ブラウザ・リクエスト

FW0

443

HTTPS/ロード・バランサ

インバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

ブラウザ・リクエスト

FW1

80

HTTP/ロード・バランサ

アウトバウンド(イントラネット・クライアント)

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

ブラウザ・リクエスト

FW1

443

HTTPS/ロード・バランサ

アウトバウンド(イントラネット・クライアント)

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

コールバックおよびアウトバウンド呼出し

FW1

80

HTTP/ロード・バランサ

アウトバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

コールバックおよびアウトバウンド呼出し

FW1

443

HTTPS/ロード・バランサ

アウトバウンド

タイムアウトは、HTMLコンテンツのサイズとタイプによって異なります。

ロード・バランサからOracle HTTP Serverへ

該当なし

7777

HTTP

該当なし

該当なし

WebLogic Serverクラスタ内におけるセッション・レプリケーション

該当なし

該当なし

該当なし

該当なし

デフォルトでは、サーバーのリスニング・アドレスのポートと同じポートがこの通信で使用されます。

データベース・アクセス

FW2

1521

SQL*Net

両方

タイムアウトは、SOAに使用されるプロセス・モデルのタイプとデータベース・コンテンツによって異なります。

デプロイメント用Coherence

該当なし

9991

該当なし

該当なし

該当なし

Oracle Notification Server (ONS)

FW2

6200

ONS

両方

Gridlinkに必要。ONSサーバーは各データベース・サーバー上で稼働します。

Elasticsearch

FW1

31920

HTTP

アウトバウンド

Elasticsearchへのログ・ファイルの送信に使用されます(オプション)。

Elasticsearch

FW12

31920

HTTP

インバウンド

Elasticsearchへのログ・ファイルの送信に使用されます(オプション)。

表9-4 Oracle Identity and Access Managementエンタープライズ・デプロイメント固有のファイアウォール・ポート

タイプ ファイアウォール ポートとポートの範囲 プロトコル/アプリケーション インバウンド/アウトバウンド その他の考慮事項とタイムアウトのガイドライン

Oracle Weblogic管理サーバー(IAMAccessDomain)へのWeb層アクセス

FW1

30701

HTTP/Oracle HTTP Serverと管理サーバー

インバウンド

該当なし

Oracle Weblogic管理サーバー(IAMGovernanceDomain)へのWeb層アクセス

FW1

30711

HTTP/Oracle HTTP Serverと管理サーバー

インバウンド

該当なし

Enterprise Managerエージェント - Web層からEnterprise Managerへ

FW1

5160

HTTP/Enterprise ManagerエージェントとEnterprise Manager

両方

該当なし

Oracle HTTP Serverからイングレス

FW1

30777

HTTP

インバウンド

該当なし

Oracle HTTP Serverからoam_serverへ

FW1

30410

HTTP/Oracle HTTP ServerからWebLogic Serverへ

インバウンド

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります

Oracle HTTP Server oim_server

FW1

30140

HTTP/Oracle HTTP ServerからWebLogic Serverへ

インバウンド

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります

Oracle HTTP Server soa_server

FW1

30801

HTTP/Oracle HTTP ServerからWebLogic Serverへ

両方

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります

Oracle HTTP Server oam_policy_mgr

FW1

30510

HTTP/Oracle HTTP ServerからWebLogic Serverへ

両方

使用されるmod_weblogicパラメータに応じて、タイムアウトは異なります

Oracle HTTP ServerからOIRI UI

FW1

30305

HTTP/Oracle HTTP ServerからOIRI UIマイクロサービス

両方

NA

Oracle HTTP ServerからOIRI

FW1

30306

HTTP/Oracle HTTP ServerからOIRIマイクロサービス

両方

NA

Oracle Coherenceポート

FW1

8000–8088

TCMP

両方

該当なし

OUDポート

FW1

31389

LDAP

インバウンド

理想的には、タイムアウトが発生しないようにこれらの接続を構成します

ノート: Kubernetesクラスタの外部でOUDにアクセスする必要がある場合にのみ必要です。

OUD SSLポート

FW1

31636

LDAPS

インバウンド

理想的には、タイムアウトが発生しないようにこれらの接続を構成します

ノート: Kubernetesクラスタの外部でOUDにアクセスする必要がある場合にのみ必要です。

Kubernetesクラスタからデータベース・リスナー

FW2

1521

SQL*Net

両方

Oracle Identity and Access Managementで使用されるプロセス・モデルのタイプとすべてのデータベース・コンテンツに応じて、タイムアウトは異なります

Oracle Notification Server (ONS)

FW2

6200

ONS

両方

Gridlinkに必要。ONSサーバーは各データベース・サーバー上で稼働します

Oracle HTTP ServerからOAA管理へ

FW1

32721

HTTP/Oracle HTTP ServerからOAA管理UIマイクロサービスへ

両方

NA

親トピック: エンタープライズ・デプロイメントのロード・バランサとファイアウォールの準備

エンタープライズ・デプロイメント用のKubernetesクラスタの準備

オンプレミス・ベースのKubernetesクラスタを使用する場合は、クラスタを作成する必要があります。多数のKubernetesを使用できますが、OracleではOracle Cloud Native Environmentを使用することをお薦めします。

このガイドの手順では、Kubernetesデプロイメントと連携する必要があり、Oracle Cloud Native Environmentクラスタで検証されています。

親トピック: オンプレミス・エンタープライズ・デプロイメントの準備

Kubernetesクラスタのホスト要件

Kubernetesクラスタは、次の2つのタイプのホストで構成されます:
  • コントロール・プレーン・ホスト: コントロール・プレーン・ホストは、Kubernetesクラスタの管理を実行します。コントロール・プレーンには1つのホストを使用できますが、Oracleでは、3つ以上のコントロール・プレーン・ホスト(理想的には5つ)で構成される高可用性コントロール・プレーンを作成することを強くお薦めします。
  • ワーカー・ホスト: ワーカー・ホストは、Kubernetesコンテナの実行に使用されます。各Kubernetesワーカー・ノードには、デプロイメントを実行するための十分な容量が必要です。高可用性を確保するには、少なくとも2つのワーカー・ノードが必要です。ワーカー・ノードの数は、デプロイするアプリケーション・コンポーネントとワーカー・ノードの容量によって異なります。アプリケーション数が多いほど、ワーカー・ノードの数または容量(あるいはその両方)が多くなります。

親トピック: エンタープライズ・デプロイメント用のKubernetesクラスタの準備

デプロイメント・オプション

Kubernetesは、次のいずれかのサーバー・タイプにインストールできます:

  • ベアメタル・サーバー
  • オンプレミス・ハードウェアまたはクラウドで実行されている仮想マシン・インスタンス
  • クラウド・ベースのベアメタル・インスタンス
  • クラウド・ベースのインフラストラクチャ仮想インスタンス
  • Oracle Private Cloud Appliance仮想インスタンス
  • Oracle Private Cloud at Customer仮想インスタンス

親トピック: エンタープライズ・デプロイメント用のKubernetesクラスタの準備

ハードウェア要件

(Oracle Cloud Native Environmentデプロイメントに基づく)デプロイメントの最小ハードウェア要件は次のとおりです:

  • Kubernetesコントロール・プレーン・ノード・ハードウェア - Kubernetesコントロール・プレーン・ノードの最小構成は次のとおりです:
    • 4 CPUコア(Intel VT対応CPU)
    • 16 GB RAM
    • 1 GBイーサネットNIC
    • XFSファイル・システム(Oracle Linuxのデフォルト・ファイル・システム)
    • /varディレクトリに40 GBのディスク領域
  • Kubernetesワーカー・ノード・ハードウェア - Kubernetesワーカー・ノードの最小構成は次のとおりです:
    • 1 CPUコア(Intel VT対応CPU)
    • 8 GB RAM
    • 1 GBイーサネットNIC
    • XFSファイル・システム(Oracle Linuxのデフォルト・ファイル・システム)
    • /varディレクトリに15 GBのハード・ディスク領域
  • オペレータ・ノード・ハードウェア - オペレータ・ノードの最小構成は次のとおりです:
    • 1 CPUコア(Intel VT対応CPU)
    • 8 GB RAM
    • 1 GBイーサネットNIC
    • /varディレクトリに15 GBのハード・ディスク領域

ノート:

これらは、Kubernetesクラスタを実行するための最小要件です。ご使用のアプリケーションでは、これらの最小値をはるかに上回るリソースが必要になる可能性が高いです。

親トピック: エンタープライズ・デプロイメント用のKubernetesクラスタの準備

Kubernetesクラスタの作成

Kubernetesクラスタをデプロイする手順は、このガイドの範囲外です。Kubernetesデプロイメントごとに独自のデプロイメント・メカニズムがあります。Oracle Cloud Native Environmentをインストールするには、Oracle Cloud Native Environmentのインストールを参照してください。

親トピック: エンタープライズ・デプロイメント用のKubernetesクラスタの準備

Oracle Cloud Native Environmentのファイアウォール・ルールの有効化

Oracle Cloud Native Environmentを使用してKubernetesクラスタをデプロイする場合は、各Kubernetesワーカー・ノードでファイアウォール・マスカレードが有効になっていることを確認する必要があります。このファイアウォールを有効にするには、各ワーカー・ノードで次のコマンドを使用します:

sudo firewall-cmd --add-masquerade --permanent

親トピック: エンタープライズ・デプロイメント用のKubernetesクラスタの準備

エンタープライズ・デプロイメント用の記憶域の準備

エンタープライズ・デプロイメントを開始する前に、ストレージ要件を理解することが重要です。記憶域を取得および構成する必要があります。

記憶域を構成する手順については、「エンタープライズ・デプロイメントの記憶域の要件」を参照してください。

親トピック: オンプレミス・エンタープライズ・デプロイメントの準備

エンタープライズ・デプロイメントにおける共有記憶域ボリュームのサマリー

標準的なOracle Fusion Middlewareエンタープライズ・デプロイメントにおける共有ボリュームおよびその目的を理解することは重要です。

Oracle Identity and Access Managementデプロイメントの記憶域の要件を理解するには、「エンタープライズ・デプロイメントの記憶域の要件」を参照してください。

記憶域の推奨事項の詳細は、「エンタープライズ・デプロイメントの記憶域の要件」を参照してください。

親トピック: エンタープライズ・デプロイメント用の記憶域の準備

エンタープライズ・デプロイメントで使用されるローカル記憶域のサマリー

エンタープライズ・デプロイメントのローカル記憶域の要件を理解するには、「エンタープライズ・デプロイメントで使用されるローカル記憶域のサマリー」を参照してください。

親トピック: エンタープライズ・デプロイメント用の記憶域の準備

ローカル記憶域の要件

各ワーカー・ノードには、コンテナだけでなくコンテナ・イメージも保持できる十分なストレージが必要です。

親トピック: エンタープライズ・デプロイメント用の記憶域の準備

エンタープライズ・デプロイメント用のKubernetesホスト・コンピュータの準備

ホスト・コンピュータの準備は、主にデプロイするKubernetesの種類によって異なります。適切なKubernetesインストール手順を参照してください。

また、次のアクションを実行する必要があります:

親トピック: オンプレミス・エンタープライズ・デプロイメントの準備

各ホストの最小ハードウェア要件の検証

エンタープライズ・デプロイメントに必要なハードウェアを調達した後は、各ホスト・コンピュータがKubernetesクラスタの最小システム要件を満たしていることを確認します。「ハードウェア要件」を参照してください。

十分なローカル・ディスク記憶域があり、共有記憶域が「エンタープライズ・デプロイメントの記憶域の要件」の説明に従って構成されていることを確認します。

次のように十分なスワップ領域および一時領域を確保します。

  • スワップ領域 - ほとんどのKubernetesデプロイメントでは、スワップを無効にすることをお薦めします。バージョン固有の推奨事項については、Kubernetesのドキュメントを参照してください。

  • 一時領域 – /tmpディレクトリに500MB以上の空き領域が必要です。

親トピック: エンタープライズ・デプロイメント用のKubernetesホスト・コンピュータの準備

Linuxオペレーティング・システムの要件の検証

エンタープライズ・デプロイメント用の標準的なLinuxオペレーティング・システムの設定について確認できます。

ホスト・コンピュータがKubernetesクラスタの最小オペレーティング・システム要件を満たしていることを確認するには、動作保証済のオペレーティング・システムがインストールされていることと、そのオペレーティング・システムに必要なパッチがすべて適用されていることを確認してください。

さらに、エンタープライズ・デプロイメント用の標準的なLinuxオペレーティング・システムの設定について、次の項を確認してください。

親トピック: エンタープライズ・デプロイメント用のKubernetesホスト・コンピュータの準備

Linuxのカーネル・パラメータの設定

Kubernetesワーカー・ホストのカーネルは、それで実行するすべてのコンテナのデプロイメントをサポートするのに十分な大きさである必要があります。表9-5に示す値は、Oracle Identity and Access Managementをデプロイするための絶対最小値です。これらの値をチューニングしてシステムのパフォーマンスを最適化することをお薦めします。カーネル・パラメータの調整については、ご使用のオペレーティング・システムのマニュアルを参照してください。

次の表の値は、現行のLinuxの推奨値です。Linuxおよびその他のオペレーティング・システムの最新の推奨値は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。

表9-5 UNIXのカーネル・パラメータ

パラメータ 値

kernel.sem

256 32000 100 142

kernel.shmmax

4294967295

これらのパラメータを設定するには:

  1. rootとしてサインインし、/etc/sysctl.confファイルのエントリを追加または修正します。
  2. ファイルを保存します。
  3. 次のコマンドを入力して、変更をアクティブ化します。
    /sbin/sysctl -p
UNIXシステムでのオープン・ファイル制限とプロセス数の設定

UNIXオペレーティング・システムでは、Open File Limitは重要なシステム設定です。ホスト・コンピュータ上で動作するソフトウェアのパフォーマンス全体に影響を及ぼす可能性があります。

Oracle Fusion Middlewareエンタープライズ・デプロイメントに適したオープン・ファイル制限の設定のための指針として、「 ホスト・コンピュータのハードウェア要件」を参照してください。

ノート:

次の例はLinuxオペレーティング・システム用です。オペレーティング・システムのドキュメントを確認して、システムで使用するコマンドを判別します。

詳細は、次の項を参照してください。

現在開いているファイル数の表示

次のコマンドでオープンになっているファイル数を確認できます。

/usr/sbin/lsof | wc -l

オープン・ファイル制限を確認するには、次のコマンドを使用します。

Cシェル: 

limit descriptors

Bash: 

ulimit -n
オペレーティング・システムのオープン・ファイルおよびプロセス制限の設定

Oracle Enterprise Linux 6以上でオープン・ファイル制限値を変更するには:

  1. rootユーザーとしてサインインし、次のファイルを編集します。

    /etc/security/limits.d/*-nproc.conf

    たとえば:

    /etc/security/limits.d/20-nproc.conf

    ノート:

    この数字は、ホストによって異なる可能性があります。
  2. このファイルに次の行を追加します。(ここに示す値は例にすぎません):
    * soft  nofile  4096
* hard  nofile  65536
* soft  nproc   2047
* hard  nproc   16384

    nofilesの値はオープン・ファイル制限を表します。nproc値はプロセス制限を表します。

  3. 変更内容を保存して、ファイルを閉じます。
  4. ホスト・コンピュータに再ログインします。

エンタープライズ・デプロイメント用のディレクトリの作成およびマウント

Kubernetesは、従来のUNIXデプロイメントとは異なる方法でストレージを使用します。Kubernetesデプロイメントでは、コンテナ・データは永続ボリューム内に格納されます。永続ボリュームはローカル・ファイル・システムでもかまいませんが、各Kubernetesノードで使用可能な共有ストレージに永続ボリューム(PV)を作成することをお薦めします。この方法により、Kubernetesコンテナを任意のKubernetesワーカー・ノードで起動できます。

  • このガイドでは、NFS永続ボリュームを使用します。NFS永続ボリュームで、共有ストレージに「共有」を作成し、各Kubernetesコンテナでその共有をマウントします。この機能により、堅牢なエンタープライズ・ストレージがクリティカル・データに使用されるようになります。詳細は、「エンタープライズ・デプロイメントの記憶域の要件」を参照してください。

    この他に、NFSボリュームを各ワーカー・ノードにマウントする方法があります。このアプローチのデメリットは、コンテナが起動されるすべてのKubernetesワーカー・ノードに、ファイル・システムをマウントする必要があることです。大規模なクラスタでは、管理オーバーヘッドが大幅に増加する可能性があります。ただし、NFSボリュームを冗長化できるため、破損の可能性から保護できます。このシナリオでは、冗長NFSマウントの同期を維持する独自のプロセスを作成する必要があります。ポッドにマウントしたNFSを使用すると、ワーカー・ノードへの依存関係がなくなります。この特性により、NFSをマウントする任意のクラスタ・ノードで必要に応じてポッドを実行できるため、管理が簡素化されます。ただし、手動で冗長化するというよりも、NFSストレージの組み込まれた冗長性に依存することになります。

  • このガイドでは、Oracle Web層ソフトウェアがローカル・ディスクまたはプライベートにアタッチされた共有記憶域にインストールされていることを想定しています。

    Web層のインストールは通常、WEBHOSTノードのローカル記憶域で実行されます。共有記憶域を使用している場合、Oracle Web層バイナリを共有ディスクにインストール(およびOracle HTTP Serverインスタンスを作成)できます。ただし、これを行う場合、共有ディスクをアプリケーション層に使用する共有ディスクとは別にする必要があり、層を横断する記憶域デバイスへのアクセスに適切なセキュリティ制限を適用することを検討する必要があります。

    アプリケーション層サーバー(OAMHOST1およびOAMHOST2)の場合と同様に、両方のコンピュータで同じディレクトリ・パスを使用します。

    たとえば:

    /u02/private/oracle/products/web
  • デプロイメント中、コンテナにマウントされる'Shares'をデプロイメント・ホストにマウントすることをお薦めします。マウントすると、コンテナが起動していない場合でも、永続ボリュームにファイルをコピーしやすくなります。また、失敗したインストールのクリーンアップとデバッグ(必要な場合)も簡単になります。多くのコンテナ・イメージには、ファイルを表示するためのVimなどのユーティリティは含まれません。

親トピック: エンタープライズ・デプロイメント用のKubernetesホスト・コンピュータの準備

ホストへのファイル・システムのマウント

OHSホストの場合、次のマウント・オプションを使用して/etc/fstabにエントリを配置します:

サンプルOHS /etc/fstabエントリ: 


<IP>:/export/IAMBINARIES/webbinaries1 /u02/private/oracle/products nfs auto,rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768
<IP>:/export/IAMCONFIG/webconfig1  /u02/private/oracle/config nfs auto,rw,bg,hard,nointr,tcp,vers=3,timeo=300,rsize=32768,wsize=32768

コンテナでファイル・システムを使用する前に、ファイル・システムへの書込みが可能であることを確認してください。ファイル・システムを要塞ノードにマウントして書き込みます。書込みできない場合は、chmodコマンドを使用してファイル・システムへの書込みを有効にします。

たとえば:

sudo mkdir -p /u02/private/oracle/products /u02/private/oracle/config
sudo mount -a
sudo chmod -R 777 /u02/private/oracle

表9-6 マウントするホストとファイル・システムのサマリー

マウント・ホスト ファイル・システム コメント

webhost1

webbinaries1

/u02/private/oracle/productsとしてマウントされます。

webhost2

webbinaries2

/u02/private/oracle/productsとしてマウントされます。

webhost1

webconfig1

/u02/private/oracle/configとしてマウントされます。

webhost2

webconfig2

/u02/private/oracle/configとしてマウントされます。

すべてのKubernetesノード

images

nfs_volumes*

コンテナ・イメージを一時的に格納するステージング・ディレクトリとして使用されます。

/imagesとしてマウントされます。

要塞ノード

oudconfigpv

/nfs_volumes/oudconfigpvとしてマウントされます。

oudpv

/nfs_volumes/oudpvとしてマウントされます。

oudsmpv

/nfs_volumes/oudsmpvとしてマウントされます。

oigpv

/nfs_volumes/oigpvとしてマウントされます。

oampv

/nfs_volumes/oampvとしてマウントされます。

oiripv

/p_volumes/oiripvとしてマウントされます。

dingpv

/p_volume/idingpvとしてマウントされます。

docker_repo*

/docker_repoとしてマウントされます。

オプションで、すべてのPVをマウントします。このオプションでは、必要に応じて構成フェーズでデプロイメントを削除できます。システムの稼働後にこれらのマウントを削除します。

ノート:

*これらのファイル・システムに、ブロック・ボリュームを使用することもできます。

Unicodeサポートの有効化

オペレーティング・システムでUnicodeサポートを有効にして、Unicodeの文字を処理することをお薦めします。

オペレーティング・システムの構成がOracle Fusion Middleware製品でサポートされる文字の動作に影響を与えることがあります。

UNIXオペレーティング・システムでは、LANGとLC_ALLの各環境変数をUTF-8文字セットを使用したロケールに設定し、Unicodeサポートを有効化することを強くお薦めします。これにより、Unicodeのすべての文字が処理できるようになります。たとえば、Oracle Identity and Access ManagementテクノロジはUnicodeに基づいています。

オペレーティング・システムがUTF-8以外のエンコードを使用するように構成されている場合、Oracle Identity and Access Managementコンポーネントが予期しない動作をする可能性があります。たとえば、ASCII以外のファイル名の場合は、ファイルにアクセスできず、エラーが発生する可能性があります。オペレーティング・システムの制約によって発生する問題はサポート対象外となります。

親トピック: エンタープライズ・デプロイメント用のKubernetesホスト・コンピュータの準備

DNSの設定

Kubernetesクラスタを作成した後、デプロイメントで使用されるアプリケーションURLおよびホストをポッドで解決できることを確認する必要があります。Kubernetesでは、'coreDNS'を使用してホスト名を解決します。すぐに使用できるこのDNSサービスは、内部Kubernetesポッド名の解決に使用されます。ただし、カスタム・エントリを含めるように拡張することもできます。

カスタム・エントリを含める方法は2つあります:
  • 個々のホスト・エントリをcoreDNSに追加する
  • アプリケーション・ドメインのcoreDNSに企業DNSサーバーを追加する

親トピック: エンタープライズ・デプロイメント用のKubernetesホスト・コンピュータの準備

CoreDNSへの個々のホスト・エントリの追加
個々のホスト・エントリをCoreDNSに追加するには:
  1. coredns_custom.yamlというカスタム・ホストで構成マップを作成します。たとえば:
    
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  example.server: |
      example.com {
            hosts {
            1.1.1.1 login.example.com
            1.1.1.2 prov.example.com
            1.1.1.3 iadadmin.example.com
            1.1.1.4 igdadmin.example.com
            1.1.1.5 igdinternal.example.com
            fallthrough
           }
      }
  2. ファイルを保存します。
  3. 次のコマンドを使用して、構成マップを作成します:
    kubectl create -f coredns_custom.yaml
  4. 次のコマンドを使用してcoreDNSを再起動します:
    kubectl rollout restart -n kube-system deploy coredns
    coreDNSポッドが問題なく再起動するようにするには、次のコマンドを使用します:
    kubectl get pods -n kube-system
    次のコマンドを使用して、カスタム構成がロードされていることを確認します:
    kubectl get configmaps --namespace=kube-system coredns-custom -o yaml
    エラーが発生した場合は、次のコマンドを使用してエラーを表示します:
    kubectl logs -n kube-system coredns--<ID>

    configmapを再度編集してエラーを修正します。

親トピック: DNSの設定

アプリケーション・ドメインのCoreDNSへの企業DNSサーバーの追加
CoreDNSがアプリケーション・ドメインの企業DNSサーバーにすべてのエントリを転送することを確認するには:
  1. coredns_custom.yamlというカスタムDNSサーバーで構成マップを作成します。たとえば:
    
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  example.server: |
    example.com {
      forward . <CORPORATE_DNS_IP_ADDRESS>
    }
  2. ファイルを保存します。
  3. 次のコマンドを使用して、構成マップを作成します:
    kubectl create -f coredns_custom.yaml
  4. 次のコマンドを使用してcoreDNSを再起動します:
    kubectl delete pod --namespace kube-system --selector k8s-app=kube-dns
    次のコマンドを使用して、corednsポッドが問題なく再起動することを確認します:
    kubectl get pods -n kube-system
    次のコマンドを使用して、カスタム構成がロードされていることを確認します:
    kubectl get configmaps --namespace=kube-system coredns-custom -o yaml
    エラーが発生した場合は、次のコマンドを使用してエラーを表示します:
    kubectl logs -n kube-system coredns--<ID>

    configmapを再度編集してエラーを修正します。

親トピック: DNSの設定

DNS解決の検証

ほとんどのコンテナには、行った構成変更が正しいことを確認できる組込みネットワーク・ツールがありません。変更を検証するもっとも簡単な方法は、インストールしたネットワーク・ツールで軽量コンテナを使用することです。たとえば、Alpineなどです。

Alpineは縮小版のbash環境です。次のようにコマンドを使用して、Alpineコンテナを起動できます:
kubectl run -i --tty --rm debug --image=docker.io/library/alpine:latest --restart=Never -- sh
このコマンドは、nslookupへのアクセスを提供し、次のコマンドを使用してホスト解決を確認できます:
nslookup login.example.com

親トピック: DNSの設定

NTP (時間)サーバーを使用するためのホストの構成

デプロイメント内のすべてのホストは同じ時間である必要があります。これを実現する最適な方法はNTPサーバーを使用することです。NTPサーバーを使用するようにホストを構成するには:

  1. 使用するNTPサーバーの名前を特定します。セキュリティ上の理由から、これらは社内秘にしてください。
  2. rootユーザーとしてホストにログインします。
  3. /etc/ntp.confファイルを編集して、時間サーバーのリストに含めます。編集後のファイルは次のようになります。
    server ntphost1.example.com
server ntphost2.example.com
  4. 次のコマンドを実行して、システム・クロックをNTPサーバーに同期化します。
    /usr/sbin/ntpdate ntpserver1.example.com
/usr/sbin/ntpdate ntpserver2.example.com
  5. 次のコマンドを使用してNTPクライアントを起動します。
    service ntpd start
  6. 日付コマンドを使用して時間が正しく設定されていることを確認します。
  7. サーバーが常にNTPサーバーを使用して時間を同期化していることを確認します。次のコマンドを使用して、再起動時にクライアントが起動するように設定します。
    chkconfig ntpd on

親トピック: エンタープライズ・デプロイメント用のKubernetesホスト・コンピュータの準備

エンタープライズ・デプロイメント用のファイル・システムの準備

エンタープライズ・デプロイメント用のファイル・システムの準備では、ローカルおよび共有記憶域の要件や、エンタープライズ・トポロジのインストール時および構成時における重要なディレクトリとファイルの場所の参照に使用される用語を理解する必要があります。

親トピック: オンプレミス・エンタープライズ・デプロイメントの準備

ファイル・システムの準備の概要

記憶域は、エンタープライズ・デプロイメントがわかりやすくなり、構成および管理が容易になるように設定することが重要です。

エンタープライズ・デプロイメントの記憶域の要件を十分に理解するには、「エンタープライズ・デプロイメントの記憶域の要件」を参照してください。

これらのファイル・システムをコンテナ内にマウントする以外に、次のボリュームを管理/デプロイメント・ホストにマウントする必要があります。管理ホストでは、ソフトウェアをデプロイする場所です。

表9-7 管理ホストのボリュームおよびマウント・ポイント

共有ボリューム名 マウント・ポイント
oudconfigpv /nfs_volumes/oudconfigpv
oudpv /nfs_volumes/oudpv
oudsmpv /nfs_volumes/oudsmpv
oigpv /nfs_volumes/oigpv
oampv /nfs_volumes/oampv
oiripv /idmpvs/oiripv
dingpv /idmpvs/dingpv
oaacredpv /nfs_volume/oaacredpv
oaaconfigpv /nfs_volume/oaaconfigpv
oaalogpv /nfs_volume/oaalogpv
oaavaultpv /nfs_volume/oaavaultpv

ノート: ファイルベースのボールトを使用する場合に必要です

docker_repo* /docker_repo

親トピック: エンタープライズ・デプロイメント用のファイル・システムの準備

ディザスタ・リカバリ環境の準備

ディザスタ・リカバリ環境は、プライマリ環境のレプリカで、プライマリ・リージョンとは別のリージョンに配置します。この環境は、プライマリ環境に障害が発生した場合にスイッチ・オーバーするスタンバイ環境です。

スタンバイ環境は別のクラスタに配置し、理想的にはデータ・センターも別にします。クラスタがアプリケーション専用の場合、2つ目のクラスタは、プライマリ・クラスタのミラーにする必要があり、ワーカー・ノードの数と仕様を同一にします。クラスタが、様々なアプリケーションに使用される多目的クラスタの場合は、スタンバイ・サイトに予備の容量が十分にあることを確認し、プライマリ・クラスタのアプリケーション・ワークロードをすべて実行できるようにします。

各Kubernetesクラスタで実行するオペレーティング・システムのバージョンとKubernetesのメジャー・リリースは同一にします。

ネットワークは次のようになります:

  • プライマリとスタンバイのデータベース・ネットワークが相互に通信するため、Data Guardデータベースの作成が簡単です。
  • プライマリとスタンバイのファイル・システム・ネットワークが相互に通信するため、ファイル・システム・データのレプリケーションが簡単です。クラスタ内でのレプリケーションを実現するためにRsyncプロセスを実行する必要がある場合、プライマリKubernetesワーカー・ネットワークは、スタンバイ・サイトのKubernetesワーカー・ネットワークと通信することが可能です。
  • グローバル・ロード・バランサにより、プライマリ・サイトとスタンバイ・サイト間のトラフィックが転送されます。このロード・バランサは、オンサイト通信に使用されるサイト固有のロード・バランサに依存しないことが多いです。
  • ロード・バランサで使用されるSSL証明書は、各ロード・バランサで同じであることが必要です。ロード・バランサによってサイトが切り替えられても、トラフィックに影響が出ないようにする必要があります。

親トピック: オンプレミス・エンタープライズ・デプロイメントの準備