トポロジ

前提条件

Oracle SOA Suite Kubernetesエンタープライズ・デプロイメント・ガイド(EDG)のトポロジの最も関連性の高い前提条件は、データベース層とWeb層に関連しています。一般的なオンプレミス本番システムでは、ハイエンド・データベース(RAC、RAC+DG、Exadata、Autonomous Databaseなど)をKubernetesクラスタから除外し、その層を個別に管理します。これは、データベースがアプリケーション層をホストするKubernetesクラスタとは別に実行されることを意味します。データベースのプロビジョニングおよび構成プロセスは、Oracle SOA Suite Kubernetes設定の範囲外です。通常は、異なるチームによって管理および保守されます。『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』では、RCUおよびデータ・ソースの作成に使用する必要があるのは、スキャン・アドレスとデータベース・サービスのみです。同様に、非武装地帯(DMZ)は影響を受けない可能性が高くなっています。ロード・バランサ(LBR)への顧客投資は十分に統合され、セキュリティとDMZのポリシーが適切に確立されています。DMZでのHTTPプロキシの使用が標準になりました。また、シングル・サインオン(OAMなど)はしばらくの間保持され、Kubernetesクラスタの一部としてよりもWeb層で最適に対処されます。

総所有コストを理由に、Kubernetesコントロール・プレーンはstacked etcdを使用します。外部etcdも可能ですが、RAFTプロトコルの信頼性を考慮すると、このオプションでは、etcdシステムをホストするためだけに、かなりの量の追加設定作業と3つの追加ノードが必要です。

トポロジ図

図10-1 トポロジ

階層の説明

コントロール・プレーン

コントロール・プレーンは、Kubernetes APIサーバーがデプロイされ、ロード・バランサによってフロントエンド処理される3つのノードで構成されます。LBRは、Oracle SOA Suiteとコントロール・プレーン自体の両方に必要な仮想IPアドレス(VIP)および仮想サーバー(VS)を公開します(ただし、内部のみのVSも使用できます)。災害からの保護に備えて、このURLはサイトまたはデータ・センターに依存しない必要があります。コントロール・プレーンおよびワーカー・ノードは、このホスト名を正しく解決できる必要があります。IPは使用しないでください。前提条件の項で説明したように、etcd層はkube-apiサーバーにスタックされます。各コントロール・プレーン・ノードは、ローカルのetcdマウントを指すKubernetes kube-api、kube-controller、kube-schedulerなどのインスタンスを実行します。etcdは、DBFS、NFSおよびローカル・ファイル・システム上のMaximum Availability Architecture (MAA)チームによってテストされています。Oracle SOA Suiteシステムの2つのオプション間では、パフォーマンスに大きな違いはありませんでした。ただし、この決定では、同じクラスタ内の他のアプリケーションによる使用状況に応じて、各顧客ケースで追加の分析が必要になる場合があります。DBFSでetcdを直接使用すると、etcdをセカンダリ・データ・センターに直接送信でき、DBテクノロジを使用して以前のバージョンのコントロール・プレーンにすばやくフラッシュバックできます。ただし、etcdと推奨されないデータベースとの間に依存関係が作成されます。ただし、etcdスナップショットをDBFSに配置して、セカンダリ・リージョンへのコピーの継続的な送信を簡素化し、Data Guardに残すことができます。次のオプションは、顧客のニーズに応じて適用可能な場合と可能でない場合があります:

etcdをルートまたはローカル・ボリュームに配置し、信頼できるネットワークを介して通常のrsyncでスナップショットを送信します。
etcdをNFSに配置し、信頼できるネットワークを介して通常のrsyncでスナップショットを送信します。
etcdをNFSまたはローカル・ボリュームに配置し、スナップショットをDBFSにコピーしてセカンダリに送信します。
アプリケーション層。

アプリケーション層

SOA (コンポジット)およびWebLogic (ear、jar、war)上のOracle SOA Suite内部アプリケーションおよびカスタム・デプロイメントは、Kubernetesクラスタ内の3つのワーカー・ノードで実行されます。Kubernetesでの一般的な割当てでは、WebLogic管理サーバーを最初のノードに配置し、Oracle SOA SuiteクラスタまたはService Busクラスタ(あるいはその両方)の各サーバーを他の2つのノードに配置します。これは、ワークロード、kubeコントローラおよびスケジューラの決定によって異なる場合があります。

$ kubectl get pods -A -o wide | grep soa
soans         soaedgdomain-adminserver                         1/1     Running     0          19h   10.244.3.127   olk8-w1   <none>           <none>
soans         soaedgdomain-create-soa-infra-domain-job-6pq9z   0/1     Completed   0          67d   10.244.4.2     olk8-w2   <none>           <none>
soans         soaedgdomain-soa-server1                         1/1     Running     0          22h   10.244.5.161   olk8-w3   <none>           <none>
soans         soaedgdomain-soa-server2                         1/1     Running     0          22h   10.244.4.178   olk8-w2   <none>           <none>

アプリケーション層は、RACデータベースのスキャン・アドレスを解決できるように、Kubernetes DNSポッドに大きく依存しています。

永続ボリュームのデュアル構成は、Oracle SOA Suiteドメイン構成の単一障害点を回避するために使用されます。高可用性を実現するために、2つの別々のNFSデバイスが使用されます。「冗長永続ボリュームの構成」を参照してください。

内部Oracle SOA SuiteおよびService Busクラスタでは、オンプレミス・システムに規定されている構成のベスト・プラクティスの一部が使用されます。『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド14c (14.1.2.0)』を参照してください:

自動サービス移行は、Java Message Service (JMS)およびJava Transaction API (JTA)サービスに使用されます。
すべての永続ストアはJDBC永続ストアです。
ノード・マネージャは、管理対象サーバーのヘルスをモニターするために使用されます。

オンプレミスのエンタープライズ・デプロイメントには大きな違いがあります。最も関連性の高いものは次のとおりです:

WebLogic Kubernetes Operatorは、WebLogic管理コンソールまたはWLSTではなく、管理対象サーバーのライフサイクルを管理するために使用されます。
スケール・アウト手順は、Kubernetesクラスタに基づいています。
WebLogic管理サーバーでは、独自/個別のWebLogicドメイン・ディレクトリは使用されません。
リスニング・アドレスとホスト名はすぐに使用できる「仮想」であり、災害からの保護を検討する際には大きな利点があります。
OHS/DMZ層は、異なるノードで使用可能な正確なノード・ポートを使用して、バックエンドのWebLogicクラスタおよび管理サーバーにルーティングします。

外部サブシステム: LBR、OHSおよびデータベース

Oracle SOA Suiteは、外部アーティファクト(フロントエンドLBR、OHS/DMZプロキシ、データベースおよび外部オーセンティケータ)と相互作用します。

LBRは、kube-apiへのルーティングと、標準のOracle SOA Suiteフロント・エンドとしての両方に使用されます。
フロントエンドLBR Oracle SOA Suite構成は、オンプレミス・システムと同じです。詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド14c』を参照してください。
kube-apiアクセスの場合、LBRはlayer4 (TCP)リスナーを使用します。このリスナーは、バックエンド・コントロール・プレーン・ノードに転送します。ノート: ホスト名を使用し、IPアドレスを避けてください。
データベース層は、JMS/JTA永続ストア、OPSSおよびMDS情報をホストするRACデータベースで構成されます。このRACデータベースの設定は、これらの手順の範囲外です。SOAクラスタのデータベース・サービス、プロセスおよびDB構成のすべての標準MAAベスト・プラクティスは、Kubernetesに適用されます。詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド14c』を参照してください。
外部認証プロバイダは、Oracle SOA Suite EDGプロシージャの説明に従って使用できます。
標準のオンプレミスのOracle SOA Suiteデプロイメントと同様に、OAMを使用したOHSによるシングル・サインオンが可能です。
OHSは、SOAクラスタ、OSBクラスタおよび管理サーバーの正確なノード・ポートにルーティングします。これは、Oracle SOA Suiteが公開するサービスがほとんどなく、システムのライフサイクルによってほとんど変更されないという事実に基づいています。これにより、イングレスおよび追加のサード・パーティ・コントローラに対するオーバーヘッドと依存関係も回避されます。OHS構成は、標準のオンプレミス構成に似ていますが、動的サーバー・リストを無効にし、各クラスタの正確なノード・ポートを持つワーカー・ノードのリストを使用する点が異なります。