IBM Cloud Docs
高可用性 (HA) 構成の同期化

高可用性 (HA) 構成の同期化

高可用性 (HA) ペアの 2 つの IBM Cloud® Virtual Router Appliance (VRA) は、両方のデバイスが同じような動作をするように、それらの構成が十分に同期されている必要があります。 この処理は configuration sync-maps を通して行われ、コンフィギュレーションのどの部分を同期させるかを選ぶことができる。 片方のマシンを変更すると、マークされたコンフィグがもう片方のデバイスにプッシュされる。

このプロセスにより、ローカルデバイスの実行中のコンフィギュレーションがリモートデバイスに同期され、保存される。 ただし、コミット・プロセスのステップとして、構成はローカル・デバイスに保存されません。

1つのシステムに固有のコンフィギュレーションを同期しないでください。 例えば、実際のIPアドレスとMACを同期させない。 system config-sync 構成ノード自体と service https ノードを同期化することはできません。

以下の例は、config-sync を示しています。

set system config-sync sync-map TEST rule 2 action include
set system config-sync sync-map TEST rule 2 location security firewall
set system config-sync remote-router 192.168.1.22 username vyatta
set system config-sync remote-router 192.168.1.22 password xxxxxx
set system config-sync remote-router 192.168.1.22 sync-map TEST

最初の 2 行は、実際の sync-map 自体を作成します。 ここで、security firewall の構成スタンザは、sync-map に設定されます。 その結果、コンフィグ・ノード内で行われた変更はすべてリモート・デバイスにプッシュされる。 しかし、security user に加えられた変更は、ルールにマッチしないので送信できません。 sync-map は、必要に応じて特定のもの、または一般として行うことができます。

次の 3 行は、リモート・ルーターの config-sync ユーザーとパスワード IP、およびプッシュする sync-map を指定します。 TEST のルールに合致する変更は、remote-router 192.168.1.22 に進み、ログイン情報を使用する。 バージョン 1801zf 以前では、REST の呼び出しが VRA API を使って実行されます。 したがって、HTTPS サーバーがリモート・ルーター上で実行中 (非ブロック化) でなければなりません。 前のリリースで生じていたパフォーマンスの問題に対処するために、バージョン 1908/1912 では、HTTPS の代わりに config-sync を使用するように netconf が書き直されています。 ポート 830 で相互に接続するためには、各 Vyatta ファイアウォール・ルールの allow とともに、以下の行が必要です。

set service netconf
set service ssh port 830
set service ssh port 22

IPsec VPNの事前共有シークレットなどのパスワードの設定を同期させるためには、スタンバイシステムには設定されている secrets グループがあり、config-sync ユーザーがそのグループに属している必要があります。

set system login group secrets
set system login user vyatta authentication plaintext-password '****'
set system login user vyatta group secrets

Config-sync は、変更をコミットするたびに発生します。 リモート・デバイスからエラー・メッセージが送信されているか注視してください。 構成が同期されていない場合は、再び作動可能になるようにリモート・デバイス上で修正する必要があります。

show config-sync difference というコマンドを使えば、設定の違いを見ることもできる。