高可用性概要およびベスト・プラクティス

タスク7 - スタンバイNGINXリバース・プロキシの構成

GoldenGateのリバース・プロキシ機能を使用すると、Oracle GoldenGateデプロイメントに関連付けられたすべてのOracle GoldenGate Microservicesに対応する単一のアクセス先を使用できます。

リバース・プロキシを使用しないと、GoldenGateデプロイメント・マイクロサービスは、ホスト名またはIPアドレスと個別のポート番号で構成されるサービスごとに1つずつのURLを使用してアクセスされます。リバース・プロキシは、マイクロサービスに簡単にアクセスし、強化されたセキュリティと管理性を提供するために必須です。

このタスクを完了するには、次のステップを実行します。

ステップ7.1 - NGINXリバース・プロキシのインストール
ステップ7.2 - NGINX構成ファイルのプライマリ・システムからのコピー
ステップ7.3 - NGINXのサーバー証明書のインストール
ステップ7.4 - 新しいNGINX構成のテストとリロード
ステップ7.5 - GoldenGate NGINX構成ファイルの配布
ステップ7.6 - NGINXを管理するClusterwareリソースの作成

ステップ7.1 - NGINXリバース・プロキシのインストール

スタンバイ・システムで、「タスク8 - NGINXリバース・プロキシの構成」の「ステップ8.1 - NGINXリバース・プロキシ・サーバーのインストール」の手順に従って、NGINXをインストールします。

ステップ7.2 - NGINX構成ファイルのプライマリ・システムからのコピー

スタンバイ・システムのopcユーザーとして、プライマリからスタンバイ・データベース・システムにNGINX構成ファイルをコピーします。
```
[opc@standby_node_1 ~]$ scp 
primary_node_1.oracle.com:/etc/nginx/conf.d/ogg_<deployment_name>.conf
 /tmp
```
スタンバイ・システムのrootユーザーとして、NGINX構成ファイルをディレクトリ/tmpからディレクトリ/etc/nginx/conf.dへコピーします。
```
[opc@exastb-node1 ~]$ sudo su -
[root@exastb-node1 ~]# cp /tmp/ogg_<deployment_name>.conf /etc/nginx/conf.d
```

ステップ7.3 - NGINXのサーバー証明書のインストール

スタンバイ・システムはプライマリ・システムとは異なるVIP名/アドレスを使用するため、別のCA署名証明書が必要になります。続行する前に、システム管理者に連絡して、会社の標準に従ってサーバー証明書を作成または取得してください。VIPとサービス・マネージャのペアごとに、個別の証明書が必要です。

スタンバイ・システムのrootユーザーとして、ファイル権限400 (-r--------)のrootが所有する/etc/nginx/sslディレクトリでサーバーCA証明書とキー・ファイルをコピーします。
```
[opc@exastb-node1 ~]$ sudo su -
[root@exastb-node1 ~]# mkdir /etc/nginx/ssl
[root@exastb-node1 ~]# chmod 400 /etc/nginx/ssl
```
スタンバイ・システムのrootユーザーとして、証明書とキー・ファイルの正しいファイル名を、NGINX構成ファイルと同じファイル名と一致するように設定します。
```
[root@exastb-node1 ~]# grep
 ssl_certificate /etc/nginx/conf.d/ogg_<deployment_name>.conf
    ssl_certificate         /etc/nginx/ssl/server.chained.crt;
    ssl_certificate_key     /etc/nginx/ssl/server.key; 
```
ノート:

プライマリ・システムからコピーした複数のリバース・プロキシ構成ファイルをコピーした場合は、このプロセスをファイルごとに繰り返す必要があります。

CA署名付き証明書を使用する場合、ssl_certificate NGINXパラメータで指定した証明書には、1) CA署名付き証明書、2)中間証明書および3)ルート証明書を単一ファイルに含める必要があります。この順序は非常に重要です。そうしていないと、NGINXの起動は失敗して、エラー・メッセージが表示されます。

(SSL: error:0B080074:x509 certificate routines: X509_check_private_key:key values mismatch).

ルート証明書と中間証明書は、CA署名付き証明書プロバイダからダウンロードできます。

単一ファイルは次のコマンド例を使用して生成できます。
```
[root@exastb-node1 ~]# cat CA_signed_cert.crt intermediate.crt root.crt >
 /etc/nginx/ssl/server.chained.crt
```
ssl_certificate_keyファイルは、CA署名付き証明書をリクエストする際に必要になる証明書署名リクエスト(CSR)の作成時に生成されるキー・ファイルです。
スタンバイ・システムのrootユーザーとして、server_nameパラメータを、プライマリ・システムからコピーしたリバース・プロキシ構成ファイルの正しいVIP名に変更します。
```
[root@exastb-node1 ~]# vi /etc/nginx/conf.d/ogg_<deployment_name>.conf
# Before:
server_name             exapri-vip.oracle.com;
# After:
server_name             exastb-vip.oracle.com;
```

ステップ7.4 - 新しいNGINX構成のテストとリロード

VIPはプライマリ・データベース・サービスが実行されるまでスタンバイ・システムで実行されないため、/etc/sysctl.confファイルで設定する必要があるパラメータがあります。

スタンバイ・システムのopcユーザーとして、次に示すパラメータをファイル/etc/sysctl.confに追加します。
```
[opc@exastb-node1 ~]$ sudo vi /etc/sysctl.conf
# allow processes to bind to the non-local address
net.ipv4.ip_nonlocal_bind = 1
```

スタンバイ・システムのopcユーザーとして、/etc/sysctl.confファイルを配布します。

[opc@exastb-node1 ~]$ /usr/local/bin/dcli -g ~/dbs_group -l opc
 -d /tmp -f /etc/sysctl.conf
[opc@exastb-node1 ~]$ /usr/local/bin/dcli -g ~/dbs_group -l opc sudo
 cp /tmp/sysctl.conf /etc/sysctl.conf

スタンバイ・システムのopcユーザーとして、変更した構成をリロードします。
```
[opc@exastb-node1 ~]$ /usr/local/bin/dcli -g ~/dbs_group -l opc sudo sysctl
 -p /etc/sysctl.conf 
```
スタンバイ・システムのopcユーザーとして、NGINX構成ファイルを検証し、構成のエラーを検出します。ファイルにエラーがある場合は、次のコマンドでエラーが報告されます。
```
[opc@exastb-node1 ~]$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginxconf test is successful
```
スタンバイ・システムのopcユーザーとして、NGINXを新しい構成で再起動します。
```
[opc@exastb-node1 ~]$ sudo systemctl restart nginx
```

ステップ7.5 - GoldenGate NGINX構成ファイルの配布

GoldenGateサービス・マネージャ用のすべてのリバース・プロキシ構成ファイルを作成すると、そのファイルをすべてのデータベース・ノードにコピーする必要があります。

スタンバイ・システムのopc OSユーザーとして、すべてのデータベース・ノードにNGINX構成ファイルを配布します。

[opc@exastb-node1 ~]$ sudo tar fczP nginx_conf.tar
 /etc/nginx/conf.d/ /etc/nginx/ssl/
[opc@exastb-node1 ~]$ /usr/local/bin/dcli -g ~/dbs_group -l opc
 -d /tmp -f nginx_conf.tar
[opc@exastb-node1 ~]$ /usr/local/bin/dcli -g ~/dbs_group -l opc
 sudo tar fxzP /tmp/nginx_conf.tar

スタンバイ・システムのopc OSユーザーとして、新しい構成ファイルのコピー先にしたすべてのノードで新しいNGINX構成をテストします。

[opc@exastb-node1 ~]$ /usr/local/bin/dcli -g ~/dbs_group -l opc sudo nginx -t
 
exastb-node1: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
exastb-node1: nginx: configuration file /etc/nginx/nginx.conf test is successful
exastb-node2: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
exastb-node2: nginx: configuration file /etc/nginx/nginx.conf test is successful

スタンバイ・システムのopc OSユーザーとして、新しい構成をロードするために、すべてのノードでNGINXを再起動します。
```
[opc@exastb-node1 ~]$ /usr/local/bin/dcli -g ~/dbs_group -l opc
 sudo systemctl restart nginx
```

ステップ7.6 - NGINXを管理するClusterwareリソースの作成

Oracle Clusterwareは、NGINXリバース・プロキシの起動を制御して、GoldenGateデプロイメントの起動前に自動的にリバース・プロキシを起動できるようにする必要があります。

スタンバイ・システムのgrid OSユーザーとして、次のコマンドを使用して、基盤となるネットワークCRSリソースに依存するNGINXリソースの作成に必要なネットワークCRSリソース名を取得します。
```
[opc@exastb-node1 ~]$ sudo su - grid
[grid@exastb-node1 ~]$ crsctl stat res -w "TYPE == ora.network.type"|grep NAME
NAME=ora.net1.network
```

スタンバイ・システムのrootユーザーとして、次のサンプル・コマンドを使用して、NGINXを管理するClusterwareリソースを作成します。HOSTING_MEMBERSおよびCARDINALITYは環境に合致するように置き換えます。

[opc@exastb-node1 ~]$ sudo su -

[root@exastb-node1 ~]# $(grep ^crs_home /etc/oracle/olr.loc | cut -d=
 -f2)/bin/crsctl add resource nginx -type generic_application -attr
 "ACL='owner:root:rwx,pgrp:root:rwx,other::r--,group:oinstall:r-x,user:oracle:rwx',
EXECUTABLE_NAMES=nginx,START_PROGRAM='/bin/systemctl start -f nginx',
STOP_PROGRAM='/bin/systemctl stop -f nginx',
CHECK_PROGRAMS='/bin/systemctl status nginx' ,
START_DEPENDENCIES='hard(ora.net1.network) pullup(ora.net1.network)', 
STOP_DEPENDENCIES='hard(intermediate:ora.net1.network)', RESTART_ATTEMPTS=0, 
HOSTING_MEMBERS='<exastb-node1, exastb-node2>', CARDINALITY=2"

この例で作成したNGINXリソースは、指定のデータベース・ノード(HOSTING_MEMBERSで指定)で同時に実行されます。これは、複数のGoldenGateサービス・マネージャのデプロイメントが構成されていて、それらがデータベース・ノード間で独立して移動できる場合にお薦めします。