はじめに
NSO はCDBを複数台のNSOインスタンスへ同期することで、冗長構成とすることが可能です。NSOのHA機能自体は、HA Framework APIをユーザが自身で使うことで、自由に実装することが可能です。tailf-hcc はそれを実装した一例であり、多くのお客様にご利用頂いておりますが、お客様が必要な機能をご自身で実装され運用されている場合もあります。
本投稿では、tailf-hcc パッケージを使用した冗長構成の操作方法について説明します。
tailf-hcc の動作
NSO のHAの仕組みを考える場合、NSOをデータベース製品と考えるとわかりやすくなります。他のデータベース製品などと同様、 Master側ノードのみにデータを書き込むことが可能で、他のSlaveノードに対しては読み込みのみが可能です。Masterノードへデータを書き込むと、そのトランザクションがSlaveノードへも複製され、結果としてSlaveノードのデータベースがMasterノードのデータベースと同期します。
tailf-hcc パッケージを使用した、冗長構成の設定方法については、以下の投稿をご確認下さい。
NSO: HA の設定方法について (tailf-hcc 編) - 概要
NSO: HA の設定方法について (tailf-hcc 編) - L2 の設定方法
NSO: HA の設定方法について (tailf-hcc 編) - L3 の設定方法
tailf-hcc パッケージでは、仕様として片方向のHAです。例えば Masterノードがダウンした場合、Slave ノードが Failover-master ロールとなり、動作を引き継ぎます。その後、当初のMasterノードをSlaveロールとして接続することが出来ますが、その場合には保護されません。つまり、その次の問題発生時にはシステムがダウンしてしまうことになりますので、出来るだけ早く、当初のMasterノードをMasterロールへ復帰させることが必要です。
また、各ノードにはデフォルトロールが設定されています。つまり、そのノードのロールがデフォルトロールとなっている状態が正常状態であり、それ以外の状態は異常となります。
ノードの状態
tailf-hcc では、以下の状態が定義されています。
- master
- slave
- failover-master
- none
正常時には master / slave ノードで構成され、master ノードがダウンした場合に、slave ノードが failover-master ノードへ昇格します。ha が無効化されている場合には、none ノードとなります。
failover-master ステータスは NSOが定義したものではなく、tailf-hcc パッケージ内でのみ使用されるものです。つまり、NSO側からみた場合には、failover-master は通常の master に見えます。
ステータス確認
コマンド: ha command status
admin@ncs# ha commands status
status nso1[master] connected nso2[slave]
admin@ncs#
自機が Master ノード (nso1) の場合に、上記のような出力となります。slave (nso2) がMasterに接続されていることがわかります。複数のSlaveをMasterに接続することが可能ですので、その場合は全てのノードについて出力されます。
接続・切断
コマンド:
接続: ha command activate
切断: ha command deactivate
root@ncs# ha commands activate
status activated
root@ncs#
root@ncs# ha commands deactivate
status deactivated
root@ncs#
自機のHAを有効化、無効化します。Master/Slave が構成されている場合に、Masterで deactivate を行うと、Switchoverが発生します。Slaveでdeactivate した場合には、Master との接続が切断されます。
Switchoverの実施
ノードのSwitchoverは、master ノードの HA が動作しなくなった場合に発生する他、意図的に master ノードを slave や none ステータスに変更した場合にも発生します。
Master ノードをSlave ロールへ変更する
コマンド:
ロールを slave に変更する: ha commands role-override role slave
admin@ncs# ha commands role-override role slave
status override
admin@ncs#
Master ノードで実施すると Slaveノードはそれを検知し、自動的にSlave ノードが Failover-master ロールへと昇格します。実施後、元Master ノードはSlave としてHAに組み込まれますので、新Masterでの変更は同期されます。ただし、この状態で更に障害が起こった場合でも、元Masterが引き継ぐことはありません。
Master ノードの HA を無効化する
root@ncs# ha commands deactivate
status deactivated
root@ncs#
Master ノードで実施すると、Slaveノードがそれを検知し、自動的にSlave ノードが Failover-master ロールへと昇格します。元Masterノードは none ロールへと移行し、新Masterでの変更は同期されません。
Dual Master
MasterノードとSlaveノードは、Keepaliveによりお互いに監視をしています。SlaveノードはMasterノードからの返事がなくなりますと、Masterがダウンしたと判断し、自身をFailover-Masterへと昇格させます。一方、MasterノードがSlaveノードの存在を確認できなくなりますと、HA動作を停止し、CDBの同期を停止単独で動作します。
この状態は Dual Masterといった状態となり、NSOのステータス上、どちらもMasterノードとなっています。CDBへのロックはされておらず、CLIからはどちらのNSOでも変更することが出来るようになっています。
NSOのNorthbound接続性は NSOサーバが設定する VIP によって作られています。当該ネットワーク上でARPを使用して、上位ルータがそれを認識しますが、VIPがサーバのインターフェースがダウンしているなどの場合はそれが失われるため、当初Masterノードが誤って操作されることはなく、新Masterが使用されることになりますため、問題とはなりません。
リカバリー
何らかの理由によりSwitchoverが発生した場合、それを復旧する必要があります。この際重要な事は、最新のデータは新Masterノードに存在するということです。その事を認識しないでリカバリーを行ってしまいますと、データ損失が発生するため、注意して下さい。
Slaveノードが Failover-masterとなる際、以下のアラームが発砲されます。
*** ALARM node-failure: HA connection lost. 'nso2' transitioning to HA MASTER role. When the problem has been fixed, role-override the old MASTER to SLAVE to prevent config loss, then role-revert all nodes. This will clear the alarm.
メッセージにもありますように、元Masterを Slave として一度HAに参加させ、元Master内のCDBを新Master（元Slave)のCDBに同期させることが必要です。
上で説明した、role-override を使用して、nso1 を slave に変更すると、以下の状態となります。
admin@ncs# ha commands status
status nso1[slave] connected nso2[master]
admin@ncs#
deactivate されている場合には、activate を実施する前に、role-override を実行して下さい。master としてactivate がされますと、VIPを宣言してしまうため、slave として HAを起動するほうが良いです。
その後、両方のノードを同時にデフォルトノードへ変更します。
コマンド: ha commands role-revert
admin@ncs# ha commands role-revert
status reverted
admin@ncs#
両方のノードで同時（出来るだけ）に実行することで、NSOのステータスは以下のようにもとに戻ります。
admin@ncs# ha commands status
status nso1[master] connected nso2[slave]
admin@ncs#
