Oracle Connection Manager 23ai - 考慮する必要があるもの (kubernetesのみではありません)
February 20, 2025 | 12 minute read※ 本記事は、Marcel Boermann-Pfeiferによる"Oracle Connection Manager 23ai - what needs to be considered (not only on kubernetes)"を翻訳したものです。
2025年2月21日
データベースは、オープン・ポートが1つのみのファイアウォールの背後に配置されていますか? クライアントとデータベース間の直接ネットワーク・ルーティングは望ましくないか、不可能ですか(IPv4とIPv6など)? それとも、データベース・オペレータとして、どのネットワークがどのデータベースにアクセスできるかについてルールを定義できるようにしますか? これらは、Oracle Connection Manager (CMAN)をすべてのOracle Database Enterprise Editionライセンスの一部として使用するための一般的なシナリオです。CMANを操作するには、いくつかの状況を考慮する必要があります。これは、Kubernetesに統合する際に特に顕著です。
Oracle Connection Managerは、インテリジェント・ネットワーク・プロキシとして機能し、Oracleデータベースとそのクライアントの間に配置されます。データベース環境では、プロキシ・クラシックのhaproxyおよびnginxよりもはるかに多くのことが可能です。これは、TCP-IPソケット・レイヤーにのみ対応できるためです。これは、前述のOracle Net (以前はSQL*NetまたはNet8と呼ばれていた)プロトコルが認識されず、それに応答できないためです:
- CMANを使用すると、クライアントは別のリスナーまたは別のポートに再接続する必要がなくなります。
多くの場合、このプロセスは、一見単純なデータベース接続の一部であり、ファイアウォールやその他の分離されたネットワークで問題が発生します。 - CMANはSSL終端を提供できます。暗号化されたネットワーク・アクセスを提供し、アドレス指定されたデータベースは暗号化されていないチャネルを介して通信し、たとえば分離された別のネットワークに配置されます。
- CMANは、独自の接続プールを持つデータベースへの接続数を減らすことができます。
- CMANは、接続フェイルオーバーに積極的に関与できます。
通常、クライアントは、停止時間によるデータベースの切り替えにもかかわらず、データベース・セッションを保持します。 - データベースまたはPDBを別のサーバーに移動すると、クライアント構成を適応させずに実行できます。
- データベースは、REMOTE_LISTENERと同じ方法でCMANに登録できます。
手動構成作業が削減されます。 - ポリシーでは、特定のデータベースにアクセスできるクライアントを定義できます。
これには、IPアドレス範囲とOracle Netサービス(データベース・サービス、extprocエージェント、ゲートウェイなど)が含まれます。 - バージョン23から、CMANにはリモート構成および管理用のREST APIがあります。
これは要求に応じてアクティブ化できます。デフォルトでは非アクティブ化されます。
CMANドキュメントには、「Traffic Directorモード」などの詳細な説明と機能がリストされています。
KubernetesでCMANを使用することに賛成する自発的な引数は何ですか?
- CMANは、バージョン23.5のコンテナ・イメージとしてcontainer-registry.oracle.comで使用できます。
インストール・スクリプトから手動でイメージを作成する必要はありません - ただし、github.com/oracleには正式なコンテナ・ビルド・スクリプトがあります。
独自のイメージの場合(例: hotfixesのため) - CMANは簡単に構成でき、実際には永続ボリュームは必要ありません。
構成ファイルcman.oraおよびSSL証明書で十分です。Kubernetesのコンテナに特に簡単に接続できます。コンテナごとの簡略化されたコミッションもcontainer-registry.oracle.comに記載されています。 - CMANは、ORDS、Observability Exporter、GoldenGateなど、いくつかのデータベース・サテライトの1つです。
同じ環境で運用できます。 - Kubernetesに含まれるクラスタウェアは、キャンセルされたコンテナを迅速に再起動し、自動ロード・バランシングと、コンテナ・レプリカによる可用性の向上を実現します。
ただし、セッション・アフィニティは必須です。では、難題に移りましょう。
KubernetesでCMANを使用することが(精神的に)難しい理由は何ですか?
- 純粋なマイクロサービスの教義によると、コンテナは、大量かついつでも起動および停止できるように「ステートレス」である必要があります。仮想マシンとデータベース全体をKubernetesで操作できるようになったため、この原則は軟化されています。そう言って、CMANはステートフルです。データベース・セッションを管理および保持します。CMANプロセスが終了し、コンテナとともに終了すると、データベース・セッションも失われます。これらは、前のロード・バランサで存続しているCMANコンテナによって再構築できますが、クライアントでエラー・メッセージが表示される可能性があります。したがって、CMANコンテナが他のノードに自発的に移動すること、または構成の変更後にコンテナが再起動されることを(Kubernetesの下だけでなく)防止する必要があります。しかし、これは簡単に実現できます。PriorityClassでは、コンテナを再起動せずに、preemptionPolicyおよびリモート制御による構成のライブ・リフレッシュを実行します。
- CMANはOracle Netプロトコルを使用し、HTTPまたはHTTPSを話しません。つまり、Kubernetesイングレスおよび純粋なHTTPゲートウェイは使用できませんが、次のことは可能です:
作成されたCMANサービスのタイプがClusterIPの場合は、ゲートウェイの設定(通常は、古い使い慣れたnginxに基づく)によってソケット・レベルで直接プロキシする必要があります(イングレスなし)。通常、ゲートウェイ自体はLoadBalancerタイプであり、これには次の文も適用されます:
作成されたCMANサービス(またはゲートウェイ)のタイプがLoadBalancerの場合、クラスタの前の外部ロード・バランサはソケット・レベルで機能する必要があります。Oracle Cloudでは、これは、通常のロード・バランサ・サービスではなく、ネットワーク・ロード・バランサ・サービスを使用することを意味します。これは、Kubernetesアノテーションなどで制御できます。
セッション・アフィニティは、複数のCMANコンテナが起動された場合など、クライアント・アドレスに基づいてロード・バランサで設定する必要があります。
作成されたCMANサービスのタイプがNodePortの場合、NodePortサービスの通常のデメリットを受け入れる以外に考慮する必要はありません。これらは、手動ロード・バランシングであり、クラスタ内の比較的少数の空きポートです。 - Kubernetesは、多くの場合、独自の内部オーバーレイ・ネットワーク(flannel)を使用します。結果として、前の段落で追加のルーティング、トンネルおよびプロキシが遅延を増やします。データベースの接続と操作には少し時間がかかります。Oracle CloudまたはCalicoネットワーキングのVCNネイティブ・ネットワーキングなど、より最新のネットワーク接続でKubernetesを構成して、各コンテナが独自の外部IPアドレスを受信し、プロキシおよびロード・バランサの数を多少減らすことをお薦めします。もちろん、これはKubernetesを使用しない構成でも適用されます。
- リモート管理用のCMAN RESTサービス(従属位置にあるもののHTTPSプロトコル)は、(まだ)コンテナでは機能しません。これは、CMANが起動時にコンテナ環境を認識したときにアクティブ化されません。構成変更の頻度が低い場合にコンテナを再起動する必要がないように、CMANプロセスに、操作中にその構成をリロードするように通知できます。これは、RESTインタフェースまたはドキュメントに示されているようにcontainer-registry.oracle.comで、コンテナに接続されたシェルおよびコマンドcmctl reloadを介して行われます。
まだ試しますか?
テストと試行を簡単に行い、デプロイメントを高速化するために、コンテナ、ボリューム、シークレット、関連サービス、および不要なイングレスを使用したデプロイメントに関する長い説明は不要です。Kubernetesパッケージ・マネージャ・ヘルムで簡単にインストールできる比較的便利なhelm chartを作成しました。一部の変数を含むテンプレートとしてKubernetes YAMLで構成されるhelmチャートのソース・コードも使用できます。
helmチャートをインストールするには、helmコマンドを使用して新しいチャート・リポジトリを追加します。kubectlコマンドを使用してKubernetesクラスタにすでにアクセスできる場合は、helmツールを使用できることが理想的です。統合されるリポジトリには、cloudbeaver、sqlcl、ordsなどの他のチャートが含まれています。これらのチャートは、年齢のために更新する必要があります。したがって、それらを無視するか、参照に使用してください。
$ helm repo add myorarepo https://ilfur.github.io/VirtualAnalyticRooms/
$ helm repo list
NAME URL
artifact-hub https://artifacthub.github.io/helm-charts/
bitnami https://charts.bitnami.com/bitnami
argo https://argoproj.github.io/argo-helm
myorarepo https://ilfur.github.io/VirtualAnalyticRooms/
$ helm show chart myorarepo/cman
apiVersion: v2
appVersion: 23.5.0.0
description: Oracle Connection Manager
icon: https://ilfur.github.io/VirtualAnalyticRooms/cman.png
name: cman
type: application
version: 1.0.4次に、cmanなどの新しいKubernetesネームスペースを作成します。
$ kubectl create namespace cman
namespace/cman createdチャートからパラメータ・ファイルvalues.yamlを取得して保存し、その中に示されているパラメータを状況に適応させます。
$ helm show values myorarepo/cman > values.yaml
$ vi values.yaml
次に、いくつかのコメントと1つまたは2つのToDoを含むvalues.yamlファイルからの抜粋を示します。最初の項では、CMANコンテナをKubernetesクラスタにロードします。
## Please provide a docker registry type secret and enter its name
## if needed, download the container image to Your location and specify that location here
image:
repository: container-registry.oracle.com/database/cman:23.5.0.0
pullPolicy: IfNotPresent
pullSecretName: oraregistry-secret
コンテナをダウンロードするには、Kubernetesクラスタでcontainer-registry.oracle.comにアクセスするためにインターネット・アクセスが必要です。コンテナ・イメージのダウンロードはパスワードで保護されています。まず、Oracle技術者アカウントでcontainer-registry.oracle.comにログインし、cman情報ページでライセンス契約を確認してください。
その後、しばらくコンテナを繰り返しダウンロードできるようになります。Kubernetesクラスタには、ここでoraregistry-secretという名前で指定したKubernetesシークレットでのダウンロード用のOracle技術者のユーザー名およびパスワードも必要です。helmチャートをインストールする前に、まずネームスペースcmanに対応するシークレットを作成してください。次に例を示します:
$ kubectl create secret docker-registry oraregistry-secret -n cman \
--docker-username=marcel.pfeifer@oracle.com \
--docker-password=myComplexPwd123 \
--docker-server=container-registry.oracle.com
secret/oraregistry-secret created
次の項では、CMANコンテナのネットワーク接続について説明します。前述のように、サービスがHTTPまたはHTTPSプロトコルと通信しないため、イングレスは定義されません。サービスのタイプをNodePortに設定すると、最速の結果が得られます。取得したIPアドレスは、ネットワーク外部からアクセスできるようになり、Oracle Netクライアントは接続文字列でこのアドレスを使用できます。
## For external access, if You have a LoadBalancer implementation installed, use the LoadBalancer type.
## Optionally, specify ClusterIP as type and configure Your Gateway to forward TCP traffic to the ClusterIP service.
## CMAN traffic is non-http, so please do not use an Ingress .
service:
type: LoadBalancer
port: 1521
ここで同様、タイプがLoadBalancerに設定されている場合は、ロード・バランサのIPアドレスを使用する必要があります。また、使用される外部ロード・バランサはHTTPロード・バランシングを動作させないでください。ただし、ソケット・レベルのままにする必要があります。
Oracle Cloudでは、対応する注釈をmetadataセクションのサービスに追加することで、これを実現できます:
metadata:
annotations:
oci.oraclecloud.com/load-balancer-type: nlb
LoadBalancerタイプを入力した場合、Helm Chartによってこの注釈が自動的に実行されます。Oracle Cloudにいない場合、この注釈は無害であり、効果はありません。次に、ログ・ファイルおよび構成の追加永続性のエントリを見てみましょう。ここではデフォルトでfalseに設定されています:
## if the toPVC param is set to false, no PVC is created and config and logs are gone on container restart.
## ideally, use an NFS type strage class for external shared acess and manipulation.
storage:
log:
toPVC: false
storageClass: rook-ceph-block
storage: 50Gi
config:
toPVC: false
storage: 1Gi
storageClass: rook-ceph-block
ログ情報および構成を永続的に格納する必要がありますか? コンテナ・ログにはすでにCMANの標準出力が含まれており、起動、構成およびアクセスがきわめて良好に表示されます。追加のトレース・ファイルを永続ボリューム(NFSなどの共有ファイル・システム)に格納できます。既存のstorageClassを指定してください。たとえば、Oracle Cloudのブロック・ボリュームの場合はoci-bv、使用可能な場合はrook-ceph-blockを指定してください。その後、外部からログ情報にアクセスすることもできます。CMAN構成にも同じことが当てはまります。通常、CMANが起動されるたびに、いわゆるConfigMapを介して構成が「shot in」されます。永続構成がボリュームにすでに存在する場合は、これが使用されます。ConfigMapは、cman.oraファイルの大部分を含むvalues.yamlファイルの次のセクションを介して入力されます:
## the initial configuration is copied to a ConfigMap.
## The NAME of the cman configuration is auto-generated, please do not specify that here.
initialConfig: |
(configuration=
(address=(protocol=tcp)(host=0.0.0.0)(port=1521))
(parameter_list =
(registration_invited_nodes=*)
(aso_authentication_filter=off)
(connection_statistics=yes)
(remote_admin=on)
(max_connections=256)
(idle_timeout=0)
(inbound_connect_timeout=0)
(log_level=user)
(session_timeout=0)
(outbound_connect_timeout=0)
(max_gateway_processes=16)
(min_gateway_processes=2)
(trace_timestamp=on)
(trace_filelen=1000)
(trace_fileno=5)
(trace_level=off)
(max_cmctl_sessions=4)
(event_group=init_and_term,memory_ops)
)
(rule_list=
(rule=
(src=*)(dst=*)(srv=*)(act=accept)
(action_list=(aut=off)(moct=0)(mct=0)(mit=0)(conn_stats=on))
)
)
)
この構成セクションにないのは、CMANの名前のみです。これは、ネットワーク・サービスの名前とネームスペースで構成され、helm chartによってまとめられるためです。ただし、これは、1つの内部ポート1521を持つCMANコンテナごとに1つのCMANのみが存在できることを意味します。複数のCMANを使用する場合は、複数のコンテナが必要です。ポート1521はどこにでも保持でき、各コンテナは独自のIPアドレスを取得し、重複はありません。
また、インストール中に作成されたConfigMap (kubectl edit configmap ... )を変更し、必要に応じてルーティング・ルールをさらに追加したり、自分でRESTサービスをアクティブ化することもできます。変更しないのは、CMANがリスニングしているIPアドレス0.0.0.0です。エントリ0.0.0.0は、任意のIPアドレスに対応します。Kubernetesのこのようなコンテナは、独自の内部IPアドレスを受信し、これは動的であり、ネットワーク・クライアントによって外部からもアクセスできません。ロード・バランサのIPアドレスを入力する必要がありますが、すでにそのままセキュアで分離されていると思います。
values.yamlファイルをニーズに適応させましたか。インストールを開始できます! これは、次のようなhelmインストール・コールによって行われます:
$ helm install my-cman myorarepo/cman --values values.yaml -n cman
NAME: my-cman
LAST DEPLOYED: Fri Dec 6 15:15:51 2024
NAMESPACE: cman
STATUS: deployed
REVISION: 1
TEST SUITE: None
インストールは、上記で作成した名前空間cmanで行われるべきです。ポッド、サービス、ConfigMapおよびその他のリソースは、非常に迅速にそこに表示されます:
$ kubectl get configmap -n cman
NAME DATA AGE
my-cman-config 4 3m40s
$ kubectl get service -n cman
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-cman-svc LoadBalancer 10.106.92.132 10.10.2.247 1521:30663/TCP 4m16s
$ kubectl get pod -n cman
NAME READY STATUS RESTARTS AGE
my-cman-cman-6c7d9945d-bd92t 1/1 Running 0 5m6s
運が良ければCMANが起動し、データベースの登録を開始できます。これは、CMANコンテナの標準ログ出力で確認できます:
$ kubectl logs pod/my-cman-cman-6c7d9945d-bd92t -n cman
Defaulted container "app" out of: app, init-config (init)
12-06-2024 15:15:53 UTC : : Creating /tmp/orod.log
sudo: unable to send audit message: Operation not permitted
sudo: unable to send audit message: Operation not permitted
12-06-2024 15:15:53 UTC : : Using the user defined cman.ora file=[/scripts/cman.ora]
12-06-2024 15:15:53 UTC : : Copying CMAN file to /u01/app/oracle/product/23ai/client_1/network/admin
12-06-2024 15:15:55 UTC : : Starting CMAN
CMCTL for Linux: Version 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on 06-DEC-2024 15:15:55
Copyright (c) 1996, 2024, Oracle. All rights reserved.
Current instance CMAN_my-cman-svc.cman.svc.cluster.local is not yet started
Connecting to (DESCRIPTION=(address=(protocol=tcp)(host=0.0.0.0)(port=1521)))
Starting Oracle Connection Manager instance CMAN_my-cman-svc.cman.svc.cluster.local. Please wait...
CMAN for Linux: Version 23.0.0.0.0 - for Oracle Cloud and Engineered Systems
Status of the Instance
----------------------
Instance name cman_my-cman-svc.cman.svc.cluster.local
Version CMAN for Linux: Version 23.0.0.0.0 - for Oracle Cloud and Engineered Systems
Start date 06-DEC-2024 15:15:56
Uptime 0 days 0 hr. 0 min. 9 sec
Num of gateways started 2
Average Load level 0
Log Level USER
Trace Level OFF
Instance Config file /u01/app/oracle/product/23ai/client_1/network/admin/cman.ora
Instance Log directory /u01/app/oracle/diag/netcman/my-cman-cman-6c7d9945d-bd92t/cman_my-cman-svc.cman.svc.cluster.local/alert
Instance Trace directory /u01/app/oracle/diag/netcman/my-cman-cman-6c7d9945d-bd92t/cman_my-cman-svc.cman.svc.cluster.local/trace
The command completed successfully.
12-06-2024 15:16:05 UTC : : Reloading CMAN
CMCTL for Linux: Version 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on 06-DEC-2024 15:16:05
Copyright (c) 1996, 2024, Oracle. All rights reserved.
Current instance CMAN_my-cman-svc.cman.svc.cluster.local is already started
Connecting to (DESCRIPTION=(address=(protocol=tcp)(host=0.0.0.0)(port=1521)))
The command completed successfully.
12-06-2024 15:16:05 UTC : : Checking CMAN Status
CMCTL for Linux: Version 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on 06-DEC-2024 15:16:05
Copyright (c) 1996, 2024, Oracle. All rights reserved.
Current instance CMAN_my-cman-svc.cman.svc.cluster.local is already started
Connecting to (DESCRIPTION=(address=(protocol=tcp)(host=0.0.0.0)(port=1521)))
Services Summary...
Proxy service "cmgw" has 1 instance(s).
Instance "cman", status READY, has 2 handler(s) for this service...
Handler(s):
"cmgw001" established:0 refused:0 current:0 max:256 state:ready
<machine: localhost, pid: 41>
(ADDRESS=(PROTOCOL=ipc)(KEY=#41.1)(KEYPATH=/var/tmp/.oracle_5432100))
"cmgw000" established:0 refused:0 current:0 max:256 state:ready
<machine: localhost, pid: 39>
(ADDRESS=(PROTOCOL=ipc)(KEY=#39.1)(KEYPATH=/var/tmp/.oracle_5432100))
Service "cmon" has 1 instance(s).
Instance "cman", status READY, has 1 handler(s) for this service...
Handler(s):
"cmon" established:1 refused:0 current:1 max:4 state:ready
<machine: localhost, pid: 33>
(ADDRESS=(PROTOCOL=ipc)(KEY=#33.1)(KEYPATH=/var/tmp/.oracle_5432100))
The command completed successfully.
12-06-2024 15:16:05 UTC : : cman [CMAN_my-cman-svc.cman.svc.cluster.local] started sucessfully
12-06-2024 15:16:05 UTC : : ################################################
12-06-2024 15:16:05 UTC : : CONNECTION MANAGER IS READY TO USE!
12-06-2024 15:16:05 UTC : : ################################################
12-06-2024 15:16:05 UTC : : cman started sucessfully
12-06-2024 15:15:53 UTC : : Using the user defined cman.ora file=[/scripts/cman.ora]
12-06-2024 15:15:53 UTC : : Copying CMAN file to /u01/app/oracle/product/23ai/client_1/network/admin
12-06-2024 15:15:55 UTC : : Starting CMAN
12-06-2024 15:16:05 UTC : : Reloading CMAN
12-06-2024 15:16:05 UTC : : Checking CMAN Status
12-06-2024 15:16:05 UTC : : cman [CMAN_my-cman-svc.cman.svc.cluster.local] started sucessfully
12-06-2024 15:16:05 UTC : : ################################################
12-06-2024 15:16:05 UTC : : CONNECTION MANAGER IS READY TO USE!
12-06-2024 15:16:05 UTC : : ################################################
12-06-2024 15:16:05 UTC : : cman started sucessfully
まずはコンテナを覗いてみましょう。シェルに接続し、ディレクトリを検索するか、構成を一度再ロードしてテストします。そのためには、kubectl get pod -n cmanと次のkubectl callで先ほど学習したポッドの名前が必要です:
$ kubectl exec -it my-cman-cman-6c7d9945d-bd92t -n cman -- /bin/bash
Defaulted container "app" out of: app, init-config (init)
[oracle@my-cman-cman-6c7d9945d-bd92t ~]$
あなたは今、コンテナの中にいます。lsnrctl statusを呼び出すと、現在、登録済データベースがないcmanサービスのみが存在することが表示されます。
また、ログが格納されているコンテナ内のディレクトリも確認できます。ORACLE_HOMEは常に/u01/app/oracle/product/23ai/client_1に設定されます。
$ lsnrctl status
LSNRCTL for Linux: Version 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on 06-DEC-2024 15:32:10
Copyright (c) 1991, 2024, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=0.0.0.0)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias cman_my-cman-svc.cman.svc.cluster.local
Version TNSLSNR for Linux: Version 23.0.0.0.0 - for Oracle Cloud and Engineered Systems
Start Date 06-DEC-2024 15:15:56
Uptime 0 days 0 hr. 16 min. 14 sec
Trace Level off
Security OFF
SNMP OFF
Listener Parameter File /u01/app/oracle/product/23ai/client_1/network/admin/cman.ora
Listener Log File /u01/app/oracle/diag/netcman/my-cman-cman-6c7d9945d-bd92t/cman_my-cman-svc.cman.svc.cluster.local/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=0.0.0.0)(PORT=1521)))
Services Summary...
Proxy service "cmgw" has 1 instance(s).
Instance "cman", status READY, has 2 handler(s) for this service...
Service "cmon" has 1 instance(s).
Instance "cman", status READY, has 1 handler(s) for this service...
The command completed successfully
[oracle@my-cman-cman-6c7d9945d-bd92t ~]$ echo $ORACLE_HOME
/u01/app/oracle/product/23ai/client_1
これをテストするには、対応するcmctlコマンドを使用してCMANの構成を再度読み込みます。作成したCMANの名前(lsnrctl statusコマンドからすでに学習したもの)に注意してください:
[oracle@my-cman-cman-6c7d9945d-bd92t ~]$ cmctl
CMCTL for Linux: Version 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on 06-DEC-2024 15:36:08
Copyright (c) 1996, 2024, Oracle. All rights reserved.
Welcome to CMCTL, type "help" for information.
CMCTL:CMAN_my-cman-cman-6c7d9945d-bd92t> admin cman_my-cman-svc.cman.svc.cluster.local
Current instance cman_my-cman-svc.cman.svc.cluster.local is already started
Connections refer to (DESCRIPTION=(address=(protocol=tcp)(host=0.0.0.0)(port=1521))).
The command completed successfully.
CMCTL:cman_my-cman-svc.cman.svc.cluster.local> reload
The command completed successfully.
CMCTL:cman_my-cman-svc.cman.svc.cluster.local> exit
[oracle@my-cman-cman-6c7d9945d-bd92t ~]$ exit
最後のテストの1つ: データベースをCMANに登録するには、そのREMOTE_LISTENERパラメータをCMANコンテナまたはそのロード・バランサのIPおよびポートに設定します。データベース・サービスがCMANに表示される場合、実際にはすでに成功しています。登録済データベースの名前をCMANから解決できる場合(つまり、登録とは逆方向)に指定します。これを機能させるには、対応するエントリがデータベースのLOCAL_LISTENERパラメータに存在する必要があります。たとえば、「localhost:1521」などのエントリは、まったく適切ではありません。
テスト目的でデータベースをCMANに登録するには、最初にCMANに割り当てられているロード・バランサ・アドレスを確認し、これをデータベースのREMOTE_LISTENERパラメータに入力する必要がありました。CMANサービスはLoadBalancerタイプであるため、10.10.2.247の外部IPアドレス(ロード・バランサのアドレス)が与えられました:
$ kubectl get service -n cman
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
my-cman-svc LoadBalancer 10.106.92.132 10.10.2.247 1521:30663/TCP 2d18h
その後、自分のデータベースまたは自分の選択したPDB (この場合はchroninと呼ばれます)にSYSユーザーとして接続し、データベース構成に解決可能なローカル・アドレスとリモート・アドレスを入力し、データベースをCMANとローカル・リスナーの両方に登録しました:
SQL> alter system set remote_listener='10.10.2.247:1521' sid='*' scope=both;
System altered.
SQL> alter system set local_listener='10.244.2.130:1521' sid='*' scope=both;
System altered.
SQL> alter system register ;
System altered.
その後、テスト環境でCMANコンテナのシェルを再度開き、データベース登録が成功したかどうかを確認しましたl:
$ kubectl exec -ti my-cman-cman-6c7d9945d-bd92t -n cman -- /bin/bash
Defaulted container "app" out of: app, init-config (init)
$ lsnrctl status
LSNRCTL for Linux: Version 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on 10-DEC-2024 10:58:33
Copyright (c) 1991, 2024, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=0.0.0.0)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias cman_my-cman-svc.cman.svc.cluster.local
Version TNSLSNR for Linux: Version 23.0.0.0.0 - for Oracle Cloud and Engineered Systems
Start Date 09-DEC-2024 12:34:36
Uptime 0 days 22 hr. 23 min. 57 sec
Trace Level admin
Security OFF
SNMP OFF
Listener Parameter File /u01/app/oracle/product/23ai/client_1/network/admin/cman.ora
Listener Log File /u01/app/oracle/diag/netcman/my-cman-cman-6c7d9945d-tw7jr/cman_my-cman-svc.cman.svc.cluster.local/alert/log.xml
Listener Trace File /u01/app/oracle/diag/netcman/my-cman-cman-6c7d9945d-tw7jr/cman_my-cman-svc.cman.svc.cluster.local/trace/cman_my-cman-svc_tnslsnr_206_139977477528512.trc
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=0.0.0.0)(PORT=1521)))
Services Summary...
Proxy service "cmgw" has 1 instance(s).
Instance "cman", status READY, has 2 handler(s) for this service...
Service "28da2fd09e0c0fcbe0638202f40a6fbf" has 1 instance(s).
Instance "ORCL1", status READY, has 1 handler(s) for this service...
Service "chronin" has 1 instance(s).
Instance "ORCL1", status READY, has 1 handler(s) for this service...
Service "cmon" has 1 instance(s).
Instance "cman", status READY, has 1 handler(s) for this service...
The command completed successfully
ここでは、PDB chroninのデータベース・サービスが正常に登録されていることがわかります。CMANがリモート・データベース・サービスを認識するようになりました。cmctlコマンド「show services」は、例のサービスchroninの背後にあるホスト名/IPアドレスと、その状態がready(ブロックされていない状態)など、詳細を一覧表示します:
$ cmctl
CMCTL for Linux: Version 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on 10-DEC-2024 11:23:25
Copyright (c) 1996, 2024, Oracle. All rights reserved.
Welcome to CMCTL, type "help" for information.
CMCTL> admin cman_my-cman-svc.cman.svc.cluster.local
Current instance cman_my-cman-svc.cman.svc.cluster.local is already started
Connections refer to (DESCRIPTION=(address=(protocol=tcp)(host=0.0.0.0)(port=1521))).
The command completed successfully.
CMCTL:cman_my-cman-svc.cman.svc.cluster.local> show services
Services Summary...
Proxy service "cmgw" has 1 instance(s).
Instance "cman", status READY, has 2 handler(s) for this service...
Handler(s):
"cmgw001" established:0 refused:0 current:0 max:256 state:ready
<machine: localhost, pid: 42>
(ADDRESS=(PROTOCOL=ipc)(KEY=#42.1)(KEYPATH=/var/tmp/.oracle_5432100))
"cmgw000" established:1 refused:0 current:0 max:256 state:ready
<machine: localhost, pid: 40>
(ADDRESS=(PROTOCOL=ipc)(KEY=#40.1)(KEYPATH=/var/tmp/.oracle_5432100))
Service "28da2fd09e0c0fcbe0638202f40a6fbf" has 1 instance(s).
Instance "ORCL1", status READY, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:1 refused:0 state:ready
REMOTE SERVER
(DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=tcp)(HOST=10.244.2.130)(PORT=1521)))
Service "chronin" has 1 instance(s).
Instance "ORCL1", status READY, has 1 handler(s) for this service...
Handler(s):
"DEDICATED" established:1 refused:0 state:ready
REMOTE SERVER
(DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=tcp)(HOST=10.244.2.130)(PORT=1521)))
Service "cmon" has 1 instance(s).
Instance "cman", status READY, has 1 handler(s) for this service...
Handler(s):
"cmon" established:5 refused:0 current:1 max:4 state:ready
<machine: localhost, pid: 34>
(ADDRESS=(PROTOCOL=ipc)(KEY=#34.1)(KEYPATH=/var/tmp/.oracle_5432100))
The command completed successfully.
クライアントがsqlplusを使用してロード・バランサのアドレスに接続し、登録されたサービスchroninが動作するようになりました:
$ sqlplus system@//10.10.2.247:1521/chronin
SQL*Plus: Release 21.0.0.0.0 - Production on Tue Dec 10 10:49:25 2024
Version 21.16.0.0.0
Copyright (c) 1982, 2022, Oracle. All rights reserved.
Enter password:
Last Successful login time: Mon Dec 09 2024 16:43:07 +00:00
Connected to:
Oracle Database 21c Enterprise Edition Release 21.0.0.0.0 - Production
Version 21.3.0.0.0
SQL>
接続があなたの環境でも機能する場合は、おめでとうございます。このブログはここまでです。
これが機能しない場合は、いくつかのヒントがあります。登録されたサービスが正しいホスト名を使用しているかどうか、およびデータベース・ホストのリスナーが登録を受け入れたかどうかを確認してください。cmctlのshow servicesコマンドでは、登録されたサービスが正しい接続文字列とともに表示され、データベース・ホストのlistener.logでは、ローカル・サービスの登録時にエラーがレポートされます。CMANに登録されているが、ローカル・リスナーに登録されていないサービスは、cmctlコマンド"show services"によってブロック済としてマークされます。ただし、ブロックされているサービスにはいくつかの理由があります。たとえば、構成で許可されていないプロトコル(tcpsの代わりにtcp)が使用されているなど、その他の可能性があります。
結論と展望
CMANのような単純なコンテナには、克服すべき2つのハードルがあります。その特殊なネットワーク構成と、存在しないステートレス性。サイズは小さいものの、データベース・システムとして貴重なものとして扱われる必要があります。つまり、障害から保護し、できるだけまれに再起動する必要があります。構成が小さすぎて、Kubernetesでも他の場所でもないため、SPOF (単一障害点)に発展してはいけません。CMANのリモート・メンテナンスの場合、機能的なRESTサービス・アクセスもコンテナで望まれます。しかし、コンテナはKubernetesの下で実行され、「データベース衛星」ORDS、GoldenGate、Observability Exporter、Coの組み合わせでその目的を達成します。標準のKubernetesネットワークでのレイテンシの増加に関する制限は、オーバーレイネットワークにもかかわらず、実際にはテストでは顕著ではありませんでした。他のOracleコンポーネントに関するその他のhelmチャートは、他のブログでフォローします。
そして、いつものように、楽しいテストをして試してみてください!
このテキストのリンクを使用:
Oracle Connection Manager 23aiのドキュメント
Sinan Petrus Toma氏によるConnection ManagerのVMベースのセットアップに関するブログ
container-registry.oracle.com上のConnection Manager 23aiコンテナ
Connection Managerのコンテナ・ビルド・スクリプト(github.com)
github.com上のConnection ManagerのHelm Chartソース・コード
Hiroyuki Yoshino
Product Release Manager in Japan