マルチデータセンターをセットアップすることは、ディザスタリカバリプラン（DRP）の一般的なトポロジですが、この種の環境の実装にはいくつかの制限があります。
最初に、SSHアクセスを使用するか、VPNを構成して、データセンター間の通信を解決する必要があります。次に、（構成によっては）データベースクラスターに影響を与える可能性のあるレイテンシーが発生します。最後に、フェイルオーバーの実行方法について考える必要があります。マスターに障害が発生した場合、アプリケーションはリモートノードにアクセスできますか？
このブログでは、前述のすべてのポイントをカバーするPostgreSQLのマルチデータセンターセットアップを実装する方法を示します。そのうちのいくつかはClusterControlを使用しています。退屈になりすぎないように、2つに分けます。最初のパートでは、データセンター間の接続について説明します。 2つ目は、展開と構成自体に関するものなので、始めましょう！
アプリケーションがプライマリデータベースノードであるロードバランサーに接続されている場合、および1つのデータセンターに1つのスタンバイノード、DRの目的でセカンダリデータセンターに別のスタンバイノード。これは、マルチデータセンター環境を構築するための最小限のセットアップである可能性があります。ロードバランサーの使用を回避することはできますが、フェイルオーバーの場合は、アプリケーションを再構成して新しいマスターに接続する必要があります。これにより、ロードバランサーの使用を回避するか、2つ（各DCに1つ）を使用して単一障害を回避することもできます。障害点。
わかりやすくするために、例としてデータセンター1と2の両方にパブリックIPアドレスを割り当てましょう。
データセンター1では、パブリックネットワークは35.166.37.0/24なので、この方法で次のIPアドレスを割り当てましょう。
APP: 35.166.37.10
Load Balancer + ClusterControl: 35.166.37.11
Primary Node: 35.166.37.12
Standby 1 Node: 35.166.37.13データセンター2では、パブリックネットワークは18.197.23.0/24なので、次のようになります。
Standby 2 Node: 18.197.23.14最初の問題は、これである可能性があります。それらの間にVPNを構成できます。これが最も安全な方法である必要がありますが、前のブログでVPN構成について説明したように、できるだけ短くするために、秘密/公開キーを使用してSSHアクセスで接続します。 。
すべてのノードに「リモート」というユーザーを作成しましょう（ルートの使用を避けるため）：
$ useradd remote
$ passwd remote
Changing password for user remote.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.そして、それをsudoersファイルに追加して、特権を割り当てることができます：
$ visudo
remote ALL=(ALL) ALL次に、ロードバランサーサーバー（ClusterControlサーバーにもなります）で、新しいユーザーのキーペアを生成します。
$ su remote
$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/remote/.ssh/id_rsa):
Created directory '/home/remote/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/remote/.ssh/id_rsa.
Your public key has been saved in /home/remote/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:hgVe/unld9+r/Ynk1HM+t089A41bwxFlPYt5/q+ZyL8 [email protected]
The key's randomart image is:
+---[RSA 3072]----+
| . . .=|
| . + oo|
| . o o.o|
| o . . o+o.|
| . S o .oo= |
| . . o =.o|
| . .+.=*|
| [email protected]|
| o=EB/|
+----[SHA256]-----+
Now you will have a new directory in the home$ ssh-copy-id 35.166.37.12
/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/remote/.ssh/id_rsa.pub"
/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
[email protected]'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh '35.166.37.12'"
and check to make sure that only the key(s) you wanted were added.このコマンドは、公開鍵をauthorized_keysファイルのリモートノードにコピーするため、秘密鍵を使用してアクセスします。
次に、それらにアクセスしてみてください：
$ ssh 35.166.37.12ファイアウォールでSSHトラフィックが許可されていることを確認し、より安全にするために、既知のソース（35.166.37.0/24など）からのみ許可する必要があります。
たとえば、AWSを使用している場合は、35.166.37.0/24からSSHポートへのトラフィックを次のように許可する必要があります。
または、IPTABLESを使用している場合は、次のように実行する必要があります。
$ iptables -A INPUT -p tcp -s 35.166.37.0/24 --destination-port 22 -j ACCEPTもう少し安全にするために、デフォルトのSSHポートとは異なるSSHポートを使用することをお勧めします。また、fail2banなど、複数の失敗したアクセス試行を禁止するツールを使用すると便利な場合があります。
この時点で、すべてがうまくいけば、データセンター間でSSH通信が可能になるため、次のステップは、このブログの後半で説明するように、PostgreSQLクラスターをデプロイし、障害が発生した場合のフェイルオーバーを管理することです。