※ 本記事は、Marcel Boermann-Pfeiferによる”Running GoldenGate 23ai on kubernetes“を翻訳したものです。
2024年10月16日
バージョン23ai以降、Oracle GoldenGateは、より洗練されたブラウザ・インタフェースと、構成、操作およびスクリプトの自動化のためのRESTサービスを備えたマイクロサービス・アーキテクチャを排他的にサポートしています。しかし、マイクロサービス・アーキテクチャの典型的な実行環境でGoldenGateを稼働させることは、テーマ的に適しているというだけではありません。
では、なぜGoldenGateがkubernetes上で動作するコンテナとして有用なのでしょうか？
- データ・ログを相互に交換する多数のGoldenGateインストールが迅速に発生する可能性があります。Postgres、Oracle、MySQL、SQL Server、DB2、BigDataタイプのシステム(MongoDB、Kafkaなど)のデータベース・タイプごとに1つのインストールが、各ケースに含まれる異なるドライバおよび抽出/アプリケーション・ロジックのために必要です。テスト環境を本番環境から切り離すこともできます。大々的に宣伝されているGoldenGate “Mesh”は、データ・センターの境界を越えて役立つだけではありません。
- GoldenGate 23ai “free” エディションには、データベース・パラメータ、ユーザーや認可、チェックポイント表、ハートビート表など、Oracleのデータベースに必要なすべてのチェックおよび設定を実行する非常に魅力的なウィザードが付属しています。様々なOracleデータベースの初期設定の“full use”インストールに加えて、“free”エディションを使用できます。
- GoldenGateの推奨ベスト・プラクティスの“advanced”インストールは、各コンテナですでに準備されており、独自のインフラストラクチャに統合できます。すべてのGoldenGateマイクロサービスは、nginxリバース・プロキシの背後にあるコンテナにグループ化され、SSL証明書は事前に生成および設定され、Kubernetesで簡単に独自の証明書に置き換えることができます。コンテナが起動されると、GoldenGate独自のデプロイメントが自動的に設定されます。つまり、ソフトウェアのインストールにデフォルト値が構成され、データ同期をすぐに設定できます。残りは、デプロイメント名と、必要なパスワードを持つ管理ユーザーを入力することです。
- バージョン23ai以降では、KubernetesでGoldenGateを実行する方が技術的にはるかに簡単です。古いバージョンではスワップ・メモリーが存在する必要があり、スワップ・メモリーがないと(完全に)起動できませんでした。新しいKubernetesバージョン(1.26以上)のみが、委託コンテナのスワップ・ストレージを提供しますが、当面は実験的な機能としてのみ提供されています。新しいGoldenGate 23aiバージョンは、スワップが使用できない場合に起動時に認識され、使用されません。
- Kubernetesクラスタは、確かに、そのクラスタ内で操作されるコンテナを監視するための一般的な環境を使用します。通常はPrometheus、Grafana、またはinfluxdbとGrafanaに基づいています。GoldenGate 23aiには、すでに測定されているメトリックをエクスポートして、既存の“mesh”から集中管理された監視システムにマージするオプションがあります。
KubernetesでGoldenGate 23aiを実行するにはどうすればよいですか?
いくつかの例の説明:
- “advanced”インストールを使用してコンテナ・イメージを作成
- 永続ストレージとネットワーク・アクセスによるKubernetesデプロイメントの定義
- 監視システムに接続し、メトリック・エクスポートをアクティブ化
“advanced”インストールを使用してコンテナ・イメージを作成
代替 1: Oracleは、公式のOracle Container Registryからダウンロードするためのすぐに使用できるコンテナ・イメージとして、GoldenGate “free”エディションを提供しています。
該当するWebサイト(https://container-registry.oracle.com/ords/ocr/ba/goldengate/goldengate-free)をご覧ください
dockerまたはpodmanの”pull”コマンドを使用してOracleからイメージを直接取得することも、ダウンロード後にこのイメージを独自のリポジトリに転送することもできます。
Kubernetesが“pull”を処理するため、必ずしも次のコマンドを実行する必要はありません。ただし、後でURLを書き留めておいてください。
# herunterladen podman pull container-registry.oracle.com/goldengate/goldengate-free:latest # umbenennen bzw. einen zusätzlichen tag anhängen podman tag container-registry.oracle.com/goldengate/goldengate-free:latest my-internal-registry.fancy.name/goldengate/goldengate-free:latest # hochladen podman push my-internal-registry.fancy.name/goldengate/goldengate-free:latest
GoldenGateの“free use” ライセンスは、無償で本番環境に使用することもできますが、すべてのプラガブル・データベースおよびコンテナ・データベースを含む、合計サイズが20 GB以下であるOracleデータベースに対してのみ使用できます。ただし、GoldenGate用にOracleデータベースを設定するための便利なウィザードもあります。ウィザードについては、このブログ記事で詳しく説明しています。
代替 2:
Oracleには、GoldenGate用に独自のdockerイメージを作成するための公式スクリプトが用意されています。これは、Postgres、DB2など、Oracle以外のデータベース・アクセス用のイメージの生成にも使用できます。
最初に、すべての可能なOracle製品のコンテナ・ビルド・スクリプトを任意のLinuxシステムにダウンロードします:
git clone https://github.com/oracle/docker-images cd docker-images/OracleGoldenGate/23
現在のサブディレクトリ「docker-images/OracleGoldenGate/23」には、イメージを作成し、それをコンテナとして動作させるための詳細な手順を含むREADME.mdファイルがあります。Kubernetesなし。でも、それについてはすぐに対処します。
最初に、Linux 64bit用の目的のGoldenGateソフトウェアをedelivery.oracle.comから.zipファイルとしてダウンロードします。これは、Oracle、Postgres、DB2などのバリエーションが必要かどうかによって異なります。「GoldenGate」を検索し、バージョン23.4、Linux 64bitおよびそれぞれのデータベース・システムを選択します。GoldenGate for BigData(Kafka、MongoDB、Snowflake、…)には、すでに23ではなくバージョン番号24.2.1があり、現在は「GoldenGate for Distributed Applications and Analytics」と呼ばれています。別の記事では、新しいトランザクション・マネージャmicroTXまたはotmmについても説明します。
ダウンロードしたファイルには、V1041909-01.zip (=GG4Postgres)、V1042871-01.zip (=GG4Oracle)、V1043063-01.zip (=GG4MySQL)などの名前が付いています。
ファイルを解凍せずにそのままにします。目的のファイルが作業ディレクトリ(docker-images/OracleGoldenGate/23)と同じディレクトリにあることを確認してください。
次に、ダウンロードした目的のzipをパラメータとして指定して、コンテナ・イメージを作成します。この例では、Oracleデータベース(V1042871-01.zip)にLinux 64BitでGoldenGate 23aiを使用します:
podman build --tag=oracle/goldengate_oracle:23.4 --build-arg INSTALLER=V1042871-01.zip .
数分間のソフトウェア・インストールまたはイメージの作成後、次のように独自のリポジトリにアップロードします:
podman tag oracle/goldengate_oracle:23.4 my-internal-registry.fancy.name/goldengate/goldengate_oracle:23.4 podman push my-internal-registry.fancy.name/goldengate/goldengate_oracle:23.4
Dockerbuildファイルと添付されたスクリプトをご覧ください。GoldenGateソフトウェアは、新しく作成されたユーザーoggとしてコンテナ内で実行されますが、起動スクリプト自体はrootユーザーとして実行され、nginxなどの追加プロセスがトリガーされます。
完了しました! 環境変数およびボリューム・マウントを使用して、GoldenGateコンテナ・イメージの1つをローカルで起動し、本格的な「advanced」インストールを構成できるようになりました。これを行う方法については、作業ディレクトリ内のREADME.mdを参照してください。しかし、Kubernetesなどの“real”ランタイム環境に直接行き、そこで私たちの手を試してみましょう。
永続ストレージとネットワーク・アクセスによるKubernetesデプロイメントの定義
ストレージ、環境変数およびネットワークに関する情報は、kubectl apply -f <filename>を使用してKubernetesクラスタに転送するYAMLファイルで提供されます。
提案番号1は、1つのPODのみでなく、GoldenGateコンテナのデプロイメントになります。たとえば、実行中のコンテナを新しいバージョンでローリング置換できるようにします。YAMLファイル(例: “gg-deploy.yaml“)は次のようになります:
dsfsdfapiVersion: apps/v1 kind: Deployment metadata: labels: app: goldengate_eastcoast instance: goldengate_oracle_23.4.0 name: goldengate-oracle-eastcoast namespace: goldengate spec: replicas: 1 selector: matchLabels: app: goldengate_eastcoast instance: goldengate_oracle_23.4.0 template: metadata: labels: app: goldengate_eastcoast instance: goldengate_oracle_23.4.0 spec: containers: - env: - name: OGG_DEPLOYMENT value: EastCoastDeployment - name: OGG_ADMIN valueFrom: secretKeyRef: key: oggadmin name: ogg-admin-secret - name: OGG_ADMIN_PWD valueFrom: secretKeyRef: key: oggadminpwd name: ogg-admin-secret image: container-registry.oracle.com/goldengate/goldengate-free:latest imagePullPolicy: IfNotPresent name: app ports: - containerPort: 443 name: ggate protocol: TCP volumeMounts: - mountPath: /u01/ogg/scripts name: u01 - mountPath: /u02 name: u02 - mountPath: /u03 name: u03 volumes: - name: u01 persistentVolumeClaim: claimName: ogg-oracle-eastcoast-u01-pvc - name: u02 persistentVolumeClaim: claimName: ogg-oracle-eastcoast-u02-pvc - name: u03 persistentVolumeClaim: claimName: ogg-oracle-eastcoast-u03-pvc
簡単に説明すると、次のようになります:
- デプロイメントは、ネームスペース”goldengate“で行われます。つまり、このデプロイメントが開始される前に作成する必要があります。
- container-registry.oracle.comの公式の“free”イメージがコンテナ・イメージとして使用されます。
- GoldenGateデプロイメントの必要な名前は”EastCoastDeployment“で、環境変数を介してコンテナに転送されます。
- 目的のユーザーとその目的のパスワードは直接指定されず、Kubernetesの「Secret」から取得されます。
- Kubernetesは、nginxリバースプロキシがリスニングしているコンテナへのSSLポート443を開きます。これにより、実行中のGoldenGateプロセスに内部的に転送され、必要に応じてHTTPヘッダーが設定されます。nginxはSSLトラフィックを終了します。つまり、GoldenGateで管理する証明書はありません。これはnginxとkubernetesによって行われます。
- ディレクトリ/u01、/u02および/u03はボリュームとしてマウントされます。構成、ログ・ファイル、tnsnames.oraおよびsqlnet.oraは、必要に応じて初期起動時に格納され、後でデータベース同期用の証跡ファイルが格納されます。別のボリュームは、Kubernetesに格納および更新された証明書を参照する/etc/nginx/certに含まれます。ただし、現時点では、on-the-flyで生成された自己署名証明書を使用しています。
ネームスペースを作成してデプロイメントを開始するために必要なコマンドを発行した場合…
kubectl create namespace goldengate kubectl apply -f gg-deploy.yaml // und prüfen, ob sich etwas tut kubectl get pods -n goldengate
…そして、私たちは何も起こっていないように見えることに気づきます。少なくともランニングpodはありません。Kubernetesは、secretを介して含まれるパスワードとリクエストされたストレージがまだ見つからないため、詳細情報を待機しています。対応するメッセージはイベント・ログ「kubectl get events -n goldengate」で確認できます。
目的のパスワードと目的のユーザー(ファイル名ogg-secret.yamlに同意する)を持つKubernetes Secretは、次のようになります。Kubernetes Secretは、Oracle Cloud、Hashicorp VaultなどのVaultサービスなどの外部Key Vaultソリューションを指す場合もあります:
apiVersion: v1 kind: Secret type: Opaque metadata: name: ogg-admin-secret namespace: goldengate stringData: oggadmin: oggadmin oggadminpwd: OGGadmin123!
次に、Kubernetesがボリュームを作成し、使用可能にしてデプロイメントにアタッチできるように、3つの永続ボリューム要求を取得します。このファイル名はogg-pvc.yamlです:
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ogg-oracle-eastcoast-u01-pvc namespace: goldengate spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi storageClassName: rook-ceph-block --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ogg-oracle-eastcoast-u03-pvc namespace: goldengate spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: rook-ceph-block --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ogg-oracle-eastcoast-u03-pvc namespace: goldengate spec: accessModes: - ReadWriteOnce resources: requests: storage: 50Gi storageClassName: rook-ceph-block
ここで使用されるストレージ・クラスとサイズは、議論の余地があります。ストレージ・クラスの指定を省略すると、デフォルトのストレージ・クラスが使用可能な場合は、そのクラスが使用されます。私の環境には、「rook-ceph-block」ストレージクラスがあり、これはOnPrem Kubernetesのかなり一般的なストレージ・ソリューションを指します。Oracle Cloudでは、これは「oracle-bv」(Oracle Block Volume)にするか、クラスタ内から選択するストレージ・クラスがいくつかあります。たとえば、低速および低コスト、高速および高コストなどです。
サイズ指定は十分です。何よりも、ログ用の十分な領域と、さらに重要なことはデータ同期証跡ファイルがあることです。生産性の高いデータベースでは、1時間当たり数ギガバイトの同期データが生成されることが多く、このデータに証跡ファイルの必要なストレージ時間(保存時間(通常は数日)を掛ける必要があります。
まだ行っていない場合は、2つのファイルを送信してKubernetesにその作業を任せます:
kubectl apply -f ogg-secret.yaml kubectl apply -f ogg-pvc.yaml kubectl get pvc -n goldengate NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE ogg-oracle-eastcoast-u01-pvc Bound pvc-0cb3936a-b782-45a8-8487-728a91b71b4d 10Gi RWO rook-ceph-block 7d1h ogg-oracle-eastcoast-u02-pvc Bound pvc-1c714fad-b6e1-49a0-9d52-3240a22a741a 10Gi RWO rook-ceph-block 7d1h ogg-oracle-eastcoast-u03-pvc Bound pvc-9315996b-2ab3-4002-baf0-a61d3cb9d059 10Gi RWO rook-ceph-block 7d1h kubectl get secret -n goldengate NAME TYPE DATA AGE ogg-admin-secret Opaque 2 7d1h kubectl get deployment -n goldengate NAME READY UP-TO-DATE AVAILABLE AGE goldengate-oracle-eastcoast 1/1 1 1 7d1h # Problem-Suche z.B. mit # kubectl get events -n goldengate # falls der Download nicht klappt oder die Volumes nicht angelegt werden
今のところ順調です。欠落しているのはネットワーク・アクセスのみです。唯一欠けているのはネットワークへのアクセスで、GoldenGate RESTサービスやユーザー・インターフェースにブラウザでアクセスするにはどうすればいいのでしょうか?
例 method 1:
一見残酷な方法は、「kubectl port-forward」を使用して、実行中のPODおよびトンネル・ポート443の現在の名前をローカル・コンピュータにリクエストすることです。迅速なテストに適していますが、通常はそれ以上のことはできません:
> kubectl get pod -n goldengate NAME READY STATUS RESTARTS AGE goldengate-oracle-eastcoast-5f9ffcd5dd-5qtds 1/1 Running 0 31h > kubectl port-forward goldengate-oracle-eastcoast-5f9ffcd5dd-5qtds -n goldengate 8443:443 & Forwarding from 127.0.0.1:8443 -> 443 Forwarding from [::1]:8443 -> 443 > curl https://127.0.0.1:8443 --insecure Handling connection for 8443 <html> <head><title>302 Found</title></head> <body> <center><h1>302 Found</h1></center> <hr><center>nginx/1.22.1</center> </body> </html>
このタイプの出力(GoldenGateコンテナ内でnginxによって生成された順方向)が表示される場合、アクセスは原則として機能し、ローカル・ブラウザで同じlocalhost URLにアクセスできます。GoldenGateログイン・ページにリダイレクトされます。
例 method 2:
ブラウザを介してGoldenGate UIに永続的にアクセスできるようにするには、いくつかの方法があります。基盤は常にKubernetesの「Service」リソースであり、コンテナへのポート転送とKubernetes内部ネットワークでの名前解決を担当します。このサービスがLoadBalancerタイプの場合は、クラスタ外部IPアドレスを受信し、ブラウザから直接アドレス指定できます。対応するサービス定義は次のようになります:
apiVersion: v1 kind: Service metadata: name: goldengate-oracle-eastcoast namespace: goldengate spec: ports: - port: 8888 protocol: TCP targetPort: 443 selector: app: goldengate_eastcoast instance: goldengate_oracle_23.4.0 type: LoadBalancer
サービスはポート8888を開き、コンテナ内でポート443 (SSL暗号化)に転送します。nginxで管理され、スクリプトによって生成される証明書が使用されます(コンテナの/etc/nginx/certの下にあります)。ポート80は、暗号化なしの純粋なHTTPであるtargetPort位置でも可能です。ここで定義されるサービスは、(ホスト、内部IPアドレスおよびreplicaの数に関係なく)“selector”フィールドの情報に対応するメタデータを持つすべてのコンテナにバインドされます。「kubectl get service」コマンドを使用すると、割り当てられた内部および外部IPアドレスを受信し、ブラウザで直接アクセスできます。正式なIPアドレスを割り当てるには時間がかかる場合があります。それまで、外部IPはPENDINGステータスのままです。
> kubectl get service goldengate-oracle-eastcoast -n goldengate NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE goldengate-oracle-eastcoast LoadBalancer 10.104.101.13 130.61.137.234 8888/TCP 9d
純粋なIPアドレスのかわりに、.nip.ioサービスの解決可能な名前アドレスは、テキスト目的で使用されることがよくあります。外部IPアドレス130.61.137.234は、ggeast.130.61.137.234.nip.ioなど、完全には任意ではなく、より意味のある名前になります。
例 method 3:
ただし、ルーティング・サービスは通常、いくつかの理由によりサービスの前に配置されます。外部のいくつかのIPアドレスのみを占有し、IP名またはURI(あるいはその両方)に基づいてKubernetesに各コンテナに転送し、内部ネットワーク・トラフィックを暗号化し、SSLを終了し、ログインをチェックしてアイデンティティを挿入し、ネットワーク監視などを可能にします。Kubernetes Ingressリソースのプロバイダとして機能する、または独自のルーティング実装を提供するistio、nginxなどのネットワーク・リソースは、事前にクラスタにインストールする必要があります。ここでは、説明できるが必ずしも実行可能ではないClusterIPサービスの例を示します。このサービスは、istioゲートウェイを介して転送されます。ルーティング構成は、istio VirtualServiceを作成することによって行われます。
apiVersion: v1
kind: Service
metadata:
name: goldengate-oracle-eastcoast
namespace: goldengate
spec:
ports:
- port: 8888
protocol: TCP
targetPort: 80
selector:
app: goldengate_eastcoast
instance: goldengate_oracle_23.4.0
type: ClusterIP
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: goldengate-oracle-eastcoast
namespace: goldengate
spec:
gateways:
- istio-system/http-istio-gateway
hosts:
- ggeast.141.147.33.99.nip.io
http:
- match:
- uri:
prefix: /
route:
- destination:
host: goldengate-oracle-eastcoast
port:
number: 8888
この例では、VirtualServiceは、istioゲートウェイが外部IPアドレス141.147.33.99を受信し、ルーティングにこのアドレスを使用しているという事実に依存しています。ホスト名ggeast.141.147.33.99.nip.ioへのすべてのリクエストは、goldengate-oracle-eastcoastという名前でここに入力されたGoldenGateサービスに転送されます。環境内のistioイングレス・ゲートウェイの外部IPアドレスを入力してもかまいません。これを見つけるには、kubectl get serviceを呼び出すだけです:
> kubectl get service -n istio-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-egressgateway ClusterIP 10.96.229.150 <none> 80/TCP,443/TCP,15443/TCP 188d istio-ingressgateway LoadBalancer 10.105.6.214 141.147.33.99 15021:31062/TCP,80:31127/TCP,443:32163/TCP,15012:30128/TCP,15443:30106/TCP 188d istiod ClusterIP 10.101.106.218 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 188d
istioゲートウェイ自体は、SSL暗号化と終了を引き継ぎ、すべてのネットワーク・トラフィックをGoldenGateコンテナ内の暗号化されていないポート80に転送できます。また、istioは内部ネットワーク・トラフィックの透過的なオンザフライ暗号化を可能にするため、個々のコンテナが暗号化自体を処理する必要がありません(istio自動インジェクションと呼ばれます)。SSL終端のあるistioゲートウェイの構成例は、次のようになります:
kind: Gateway name: http-istio-gateway namespace: istio-system spec: selector: istio: ingressgateway servers: - hosts: - '*' port: name: http number: 443 protocol: HTTPS tls: credentialName: istio-tls mode: SIMPLE
istioゲートウェイは、ポート443のすべてのリクエストに応答し、HTTPS経由で外部と通信します。SSL証明書は、istio-tlsと呼ばれるKubernetesの”secret”から取得され、cert-managerなどのkubernetesサービスによって生成および更新できます。適切なDestinationRulesなどの追加の構成がない場合、このゲートウェイは暗号化されていないコンテナまたはオンザフライで暗号化されたコンテナと通信します。
例 method 4:
新しいKubernetesバージョンでは、独自のイングレス・リソースが提供されます。これは、method 3の例のistio VirtualServiceと同様の方法で機能します。ただし、イングレスを実装するユーザー(istio、nginxまたは別のサービス)を選択することもできます。ここでも説明でき、必ずしも使用している環境で実行できるわけではない構成の例を示します。method 3の例と同じサービスがベースとして使用され、istioパッケージのインストールも想定されます。VirtualServiceのかわりに、IngressClassおよび最新状態のKubernetesイングレスがここで定義されます:
apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: istio spec: controller: istio.io/ingress-controller --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress namespace: goldengate spec: ingressClassName: istio rules: - host: ggeast.141.147.33.99.nip.io http: paths: - path: / pathType: Prefix backend: service: name: goldengate-oracle-eastcoast port: number: 8888 --- apiVersion: v1 kind: Service metadata: name: goldengate-oracle-eastcoast namespace: goldengate spec: ports: - port: 8888 protocol: TCP targetPort: 80 selector: app: goldengate_eastcoast instance: goldengate_oracle_23.4.0 type: ClusterIP
これは、ネットワークとストレージの配置と接続のためのものです。GoldenGateが実行され、アクセスできるようになったため、この記事はすでに終了しています。GoldenGateとOracle Identity Cloudなどのアイデンティティ管理システム(または、おそらくkeycloakとも)との統合は、別個のより詳細なトピックであり、GoldenGate P\product管理によるブログの例として説明されています。GoldenGateメッシュ・インストールと、GoldenGateコンテナが相互に接続して同期データを交換する方法も、別のブログ・エントリの一部です。しかし、どのような場合(GoldenGateを、Grafana、Prometheus and Coを使用したKubernetesの一般的なモニタリング・システムに統合する方法)でも強調する必要があります。
GoldenGateを(Kubernetes)監視システムに接続
GoldenGateインストールごとに、GoldenGateユーザー・インタフェースに組み込まれたパフォーマンス・メトリック・サービスが提供されます。これは、ディスクI/O、メモリー使用量、ネットワークI/O、影響を受ける表、データ操作、データ同期のラグなどの包括的なメトリックを示します。ただし、ここで表示できるのは、ユーザー・インタフェースが呼び出されてからの現在の値または値のみです。これは、JavaScript対応のブラウザのメイン・メモリーが不足するか、HTTPセッションが期限切れになる(どちらか早い方)までです。
監視環境のすべてのGoldenGateインストールを要約し、過去数日間の履歴データを表示するには、監視環境の統合が必要であり、もちろんGoldenGateでサポートされています。すべてのメトリックを外部監視システムに転送するには、少数の追加構成エントリのみが必要です。
ここでのメトリックの形式はstatsdで、メトリックはUDPプロトコルを介して、形式を処理できる名前付きコンテナに送信されます。たとえば、「influxDB」は、statsdデータ(telegraf)用のプラグインとGrafana分析ツールへのインタフェースを備えたデータベース・エンジンです。この方法については、GoldenGate Product Managementのブログ・エントリで説明します。次の例は、非常に類似したパスに従いますが、Prometheusデータベース、Grafana、およびstatsd形式からPrometheus形式(Prometheusプロジェクトの一部であるstatsd-exporter)への自動コンバータを使用した、よりクラシックなバリアント経由です。
原則として、抽出、レプリケート、接続、分散パスなどのアーティファクトを含むGoldenGate構成は、RESTサービス・コールを介して自動化およびスクリプト化できます。このようなRESTサービス・コールは、その後メトリック・エクスポートをアクティブ化するためにも必要です。まず、メトリック処理を含む既存の構成を読み取ります。選択したネットワーク接続に応じて、それに応じて使用されるURLを調整してください。デプロイメント名を含め、コール・パスは同じままです。ユーザー名とパスワードも、選択した環境と異なる必要があります:
> curl https://ggeast.141.147.33.99.nip.io/services/v2/deployments/EastCoastDeployment --insecure --user "oggadmin:OGGadmin123!"|jq
...
... jede Menge Output, aber auch Angaben zu Metriken wie:
"metrics": {
"servers": [
{
"protocol": "uds",
"socket": "PMSERVER.s",
"type": "pmsrvr"
}
],
"enabled": true
},
...
...
JSONドキュメントのメトリック部分をコピーし、インストールするメトリック・サービスの名前(statsd-exporter-service)を入力する新しいドキュメントを作成し、GoldenGateサーバーを再構成するためにPATCH文へのcurlコールを変更します。送信するRESTサービス・コールは次のようになります:
curl -X PATCH \
https://ggeast.141.147.33.99.nip.io/services/v2/deployments/EastCoastDeployment \
--user oggadmin:OGGadmin123! \
--insecure \
-H 'Cache-Control: no-cache' \
-d '{
"metrics": {
"servers": [
{
"protocol": "uds",
"socket": "PMSERVER.s",
"type": "pmsrvr"
},
{
"type":"statsd",
"host":"statsd-exporter-service"
}
],
"enabled": true
}
}'
次に、PODを削除してGoldenGateコンテナを再起動します。Kubernetesは新しいPODを自動的に再起動します。
> kubectl get pods -n goldengate NAME READY STATUS RESTARTS AGE goldengate-oracle-eastcoast-5f9ffcd5dd-5qtds 1/1 Running 1 4d6h > kubectl delete pod goldengate-oracle-eastcoast-5f9ffcd5dd-5qtds -n goldengate > kubectl get pods -n goldengate NAME READY STATUS RESTARTS AGE goldengate-oracle-eastcoast-5f9ffcd5dd-54f7t 1/1 Running 0 6s
詳細な情報がない場合、GoldenGateは、ポート8125のUDPプロトコルを介して、そのメトリックをKubernetesサービスのstatsd-exporter-serviceに送信するようになりました。このアドレスでコンテナが待機していないという事実は重要ではなく、エラーも発生しません。このタイプの許容範囲は、UDPプロトコルで一般的です。次に、statsd-exporterがインストールされていることと、メトリックを受信していることを確認します。
テストでは、個別のKubernetesデプロイメントが可能です。後で、statsd-exporterをいわゆるサイドカーとして設定し、GoldenGate PODの一部にすると、より意味があります。
次のデプロイメントおよび関連するサービスが考えられます:
apiVersion: apps/v1 kind: Deployment metadata: labels: app.kubernetes.io/instance: statsd-exporter app.kubernetes.io/name: statsd-exporter-prometheus name: statsd-exporter-prometheus namespace: goldengate spec: replicas: 1 selector: matchLabels: app.kubernetes.io/instance: statsd-exporter app.kubernetes.io/name: statsd-exporter-prometheus template: metadata: labels: app.kubernetes.io/instance: statsd-exporter app.kubernetes.io/name: statsd-exporter-prometheus spec: containers: - image: docker.io/prom/statsd-exporter:latest imagePullPolicy: Always args: ["--statsd.mapping-config", "/config/statsd-mapping.yaml", "--log.level", "debug"] name: app ports: - containerPort: 9102 name: http protocol: TCP - containerPort: 9125 name: push protocol: UDP volumeMounts: - mountPath: /config name: config volumes: - name: config configMap: defaultMode: 420 name: statsd-mapping-config --- apiVersion: v1 kind: Service metadata: labels: app.kubernetes.io/instance: statsd-exporter app.kubernetes.io/name: statsd-exporter-prometheus-service app: gg23ai-east name: statsd-exporter-service namespace: goldengate spec: ports: - port: 8125 protocol: UDP targetPort: 9125 name: push - port: 9102 protocol: TCP targetPort: 9102 name: http selector: app.kubernetes.io/instance: statsd-exporter app.kubernetes.io/name: statsd-exporter-prometheus type: ClusterIP
標準のstatssd-exporterコンテナは、UDPポート9125で(内部的に)リスニングします。GoldenGateは、デフォルトでそのメトリックをポート8125に送信します。サービス定義によって、2つのポートがリンクされます。指定したデバッグ・ログ・レベル・パラメータは後で削除できます。ただし、まず、GoldenGateのメトリックがコンテナに到着するかどうかを確認することが重要です。
別のファイル(statsd-mapping-configという名前のいわゆるConfigMap内)が欠落しており、メトリック・データを名前変更したり、目的の形式にマップするための通常不要な情報が含まれています。ただし、デフォルトは、ターゲット形式としてprometheusです。理想的には、メトリックは引き続き、GoldenGateドキュメントのfürstatsdメトリックにリストされているものと同じ名前と関数を持つ必要があります。ただし、例として、かなり空の構成ファイルをいくつかのコメントとともに提供します:
apiVersion: v1 kind: ConfigMap metadata: name: statsd-mapping-config namespace: goldengate data: statsd-mapping.yaml: |+ mappings: #- match: "statistics-replicat.*" # name: "gg_statistics_replicat" # labels: # type: "$1" #- match: "receiver-service-stats.*" # name: "gg_statistics_recsrvc" # labels: # type: "$1"
両方のYAML構成(デプロイメント、内部サービスおよびConfigMapを含む)がkubectl applyコールを使用してKubernetesクラスタに転送された場合は、コンテナが起動しているかどうか、およびメトリックがすでに到着しているかどうかを確認できます:
> kubectl get pods -n goldengate NAME READY STATUS RESTARTS AGE goldengate-oracle-eastcoast-5f9ffcd5dd-5qtds 1/1 Running 1 4d7h statsd-exporter-prometheus-845d75f7df-j9hbg 1/1 Running 1 4d6h > kubectl logs statsd-exporter-prometheus-845d75f7df-j9hbg -n goldengate ... ts=2024-09-09T15:38:16.242Z caller=listener.go:97 level=debug msg="Incoming line" proto=udp line="trail-input.io-read-count,deploymentName=EastCoastDeployment,deploymentId=7a56bbeb-3db4-4242-9420-6968e18c55a0,processType=replicat,processName=HRREP,trail-name=HR,trail-path=/u02/Deployment/var/lib/data:28556|g" ts=2024-09-09T15:38:16.242Z caller=listener.go:97 level=debug msg="Incoming line" proto=udp line="trail-input.io-read-bytes,deploymentName=EastCoastDeployment,deploymentId=7a56bbeb-3db4-4242-9420-6968e18c55a0,processType=replicat,processName=HRREP,trail-name=HR,trail-path=/u02/Deployment/var/lib/data:6211|g" ts=2024-09-09T15:38:16.242Z caller=listener.go:97 level=debug msg="Incoming line" proto=udp line="trail-input.trail-read-errors,deploymentName=EastCoastDeployment,deploymentId=7a56bbeb-3db4-4242-9420-6968e18c55a0,processType=replicat,processName=HRREP,trail-name=HR,trail-path=/u02/Deployment/var/lib/data:0|g" ts=2024-09-09T15:38:16.242Z caller=listener.go:97 level=debug msg="Incoming line" proto=udp line="trail-input.trail-times-at-eof,deploymentName=EastCoastDeployment,deploymentId=7a56bbeb-3db4-4242-9420-6968e18c55a0,processType=replicat,processName=HRREP,trail-name=HR,trail-path=/u02/Deployment/var/lib/data:28551|g" ts=2024-09-09T15:38:16.242Z caller=listener.go:97 level=debug msg="Incoming line" proto=udp line="trail-input.trail-lob-bytes,deploymentName=EastCoastDeployment,deploymentId=7a56bbeb-3db4-4242-9420-6968e18c55a0,processType=replicat,processName=HRREP,trail-name=HR,trail-path=/u02/Deployment/var/lib/data:0|g" ...
ここに示したログ・エントリは、すでに設定されており、同期プロセスHRREPと証跡HRを実行しています。ログには、基本サービスadminsrvr、distsrvrなどのCPU情報と値が少なくとも含まれている必要があります。statsd-exporterはポート9102を開き、HTTPコール(URIパス /metrics)を介して収集されたメトリックを配信します。これは、Prometheusがスクレイピング・プロセスに必要なインタフェースです。環境でPrometheusをKubernetesリソースとして設定した場合、スクレイピング構成ファイルに情報をフィードする必要はありませんが、statsd-exporterスクレイピングの実行方法に関する情報を含む一般的なServiceMonitorリソースで十分です。次のようになります:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
labels:
app: gg23ai-east
release: prometheus
name: goldengate-east-monitor
namespace: goldengate
spec:
endpoints:
- bearerTokenSecret:
key: ''
interval: 20s
port: http
relabelings:
- action: replace
sourceLabels:
- __meta_kubernetes_endpoints_label_app
targetLabel: instance
namespaceSelector: {}
selector:
matchLabels:
app.kubernetes.io/instance: statsd-exporter
app.kubernetes.io/name: statsd-exporter-prometheus-service
ここでは、使用している環境とは異なるオプション仕様がいくつか用意されています。たとえば、選択したPrometheusインストールでは、ServiceMonitorにメタデータ”release: prometheus”が必要です。そうしないと、無視されます。スクレイピング間隔(つまり、メトリックがPrometheusによって問い合せられる頻度)は20秒で、Prometheusデータベースで問合せ対象オブジェクトのコンテナ名(instanceと呼ばれるlabel)を入力するかわりに、metadatum appからgg23ai-eastの値が使用されます。
「kubectl apply」の後、メトリックはPrometheusのインストールにも届くはずです。
ServiceMonitorは統合されていますか? 「Prometheus – Status – Service Discovery」をご覧ください:
一般的なGoldenGateメトリックは認識可能ですか。「Graph」メニューからクイック検索すると、結果が返されます。たとえば、メトリックprocess_performance_cpu_timeを検索すると次のようになります:
これで、Grafanaでダッシュボードを作成すると、メトリックを履歴的に表示し、インストールごとにグループ化できます。ダウンロード可能なGoldenGateの公式Grafanaダッシュボードはありませんが、クイック・テストおよび例として(Grafana: Dashboards – New Button – import – upload JSON file)小規模な自己作成ダッシュボードを環境にインポートすることは歓迎されています。
ダッシュボードは、ここで説明する多くのYAMLファイルとともにパブリックgithubリポジトリにあります。
すべてが機能している場合は、データ同期が設定されると、次のものまたは同様のものが表示されます:
まとめ:
KubernetesのGoldenGate環境は、テストやトレーニングだけでなく、特に迅速に設定、構成、破棄できます。コンテナのGoldenGateは、nginxリバース・プロキシとSSLターミネーションを備えた「advanced」インストールで、Kubernetesで証明書をネイティブに統合し、必要に応じて非常に重要なネットワーク・アクセスを設定し、ネイティブ・モニタリング環境ですべてのデプロイメントを組み合わせるオプションを備えています。GoldenGateインストールを単一のSignOnサービスにリンクしたり、いわゆる分散パスを介してGoldenGateインストールを相互にリンクするなど、その他のトピックは開いたままです。それでも、データ・センターやクラウド移行、データウェアハウスの構築、ディザスタ・リカバリなどの様々なシナリオについて、データ同期を設定およびテストするための多数のインストラクション・ビデオおよび無料コースをご覧いただけます。いくつかのリンクを準備しました:
YouTubeでのGoldenGate Product Management
YouTubeでのGoldenGateに関するOracle Learning – 例. はじめに
Oracle LiveLabs on GoldenGate active-active sync
GoldenGate statsd監視方法 (githubでのinfluxdbのGrafanaダッシュボードを含みます)
GoldenGate nginxリバース・プロキシの設定
このブログ投稿のYAMLおよびGrafanaダッシュボードの例
いつものように、試してみて楽しんでください!