kubernetesでのGoldenGate 23aiの実行

※ 本記事は、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ダッシュボードの例

いつものように、試してみて楽しんでください!