フェイルオーバーの実行
定数が維持されている場合は、ストアが正常に実行しているため、何も行う必要はありません。
ゾーンが機能しなくなったが定数が失われた状況では、フェイルオーバーを実行するしかありません。
たとえば、ストアに2つのプライマリ・ゾーンManhattanとJerseyCityが構成され、ぞれぞれは専用の物理データ・センターにデプロイされているとします。
注意:
簡潔にするため、この例ではレプリケーション係数が2のストアを使用します。一般に、大半のアプリケーションで適正であり有効な開始点となるプライマリ・レプリケーション係数は3であり、これは、1つのプライマリ・ゾーンに障害が発生した場合、3つのレプリカにより書込み可用性が得られるためです。
さらに、Manhattanゾーンで障害が発生し、その結果、関連するすべてのストレージ・ノードで障害が発生し、定数が失われたとします。このケースでは、Manhattanのホスト・ハードウェアの損傷が修復不可能である場合、または問題の修復に時間がかかりすぎる場合に、フェイルオーバーの開始を選択できます。
この後のステップで、フェイルオーバー操作を実行する際の、障害の確認、ストレージ・ノードの分離、管理定数の削減について説明します。このプロセスにより、ゾーン障害の発生時にサービスを継続できます。
-
ストアに接続します。このためには、JerseyCityゾーンで実行している管理に接続します。
java -Xmx64m -Xms64m -jar KVHOME/lib/kvstore.jar \ runadmin -host jersey1 -port 6000 \ -security USER/security/admin.security
注意:
これは、リモート・アクセスでのセキュリティの構成に記載されているステップに従っていることを前提としています。
-
verify configuration
コマンドを使用して障害を確認します。kv-> verify configuration Connected to Admin in read-only mode Verify: starting verification of store mystore based upon topology sequence #207 200 partitions and 2 storage nodes. Time: 2018-09-28 06:57:10 UTC Version: 18.3.2 See jersey1:/kvroot/mystore/log/mystore_{0..N}.log for progress messages Verify: Shard Status: healthy:0 writable-degraded:0 read-only:1 offline:0 Verify: Admin Status: read-only Verify: Zone [name=Manhattan id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false] RN Status: online:0 offline:1 Verify: Zone [name=JerseyCity id=zn2 type=PRIMARY allowArbiters=false masterAffinity=false] RN Status: online:1 offline:0 Verify: == checking storage node sn1 == Verify: sn1: ping() failed for sn1 : Unable to connect to the storage node agent at host nyc1, port 5000, which may not be running; nested exception is: java.rmi.ConnectException: Connection refused to host: nyc1; nested exception is: java.net.ConnectException: Connection refused Verify: Storage Node [sn1] on nyc1:5000 Zone: [name=Manhattan id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false] UNREACHABLE Verify: admin1: ping() failed for admin1 : Unable to connect to the storage node agent at host nyc1, port 5000, which may not be running; nested exception is: java.rmi.ConnectException: Connection refused to host: nyc1; nested exception is: java.net.ConnectException: Connection refused Verify: Admin [admin1] Status: UNREACHABLE Verify: rg1-rn1: ping() failed for rg1-rn1 : Unable to connect to the storage node agent at host nyc1, port 5000, which may not be running; nested exception is: java.rmi.ConnectException: Connection refused to host: nyc1; nested exception is: java.net.ConnectException: Connection refused Verify: Rep Node [rg1-rn1] Status: UNREACHABLE Verify: == checking storage node sn2 == Verify: Storage Node [sn2] on jersey1:6000 Zone: [name=JerseyCity id=zn2 type=PRIMARY allowArbiters=false masterAffinity=false] Status: RUNNING Ver: 18.3.2 2018-09-17 09:33:45 UTC Build id: a72484b8b33c Verify: Admin [admin2] Status: RUNNING,MASTER (non-authoritative) Verify: Rep Node [rg1-rn2] Status: RUNNING,MASTER (non-authoritative) sequenceNumber:217 haPort:6003 available storage size:12 GB Verification complete, 4 violations, 0 notes found. Verification violation: [admin1] ping() failed for admin1 : Unable to connect to the storage node agent at host nyc1, port 5000,which may not be running; nested exception is: java.rmi.ConnectException: Connection refused to host: nyc1; nested exception is: java.net.ConnectException: Connection refused Verification violation: [rg1-rn1] ping() failed for rg1-rn1 : Unable to connect to the storage node agent at host nyc1, port 5000, which may not be running; nested exception is: java.rmi.ConnectException: Connection refused to host: nyc1; nested exception is: java.net.ConnectException: Connection refused Verification violation: [sn1] ping() failed for sn1 : Unable to connect to the storage node agent at host nyc1, port 5000, which may not be running; nested exception is: java.rmi.ConnectException: Connection refused to host: nyc1; nested exception is: java.net.ConnectException: Connection refused
このケースでは、ホストnyc1のストレージ・ノード・エージェントが使用できないことが確認されます。
-
ハード・ロールバックとデータ損失を防ぐために、機能していないノード(Manhattan)を他のシステムから分離します。機能しなくなったノードはすべて、構成が更新されるまでストアに再結合しないでください。
このためには、次を実行します。
-
ネットワークを物理的に切断するか、ファイアウォールを使用します。
-
機能しなくなったノードの起動シーケンスを変更して、SNAが開始しないようにします。
-
-
ストアに変更を加えるには、まず管理定数を減らす必要があります。このためには、
repair-admin-quorum
コマンドを使用して使用可能なプライマリ・ゾーンを指定します。kv-> repair-admin-quorum -znname JerseyCity Connected to admin in read-only mode Repaired admin quorum using admins: [admin2]
これで、一時的に定数を減らした状態で、残りの管理サービスを使用して管理手順を実行できるようになりました。
-
plan failover
コマンドを使用して、使用可能なゾーンを含むようにストアの構成を更新します。kv-> plan failover -znname \ JerseyCity -type primary \ -znname Manhattan -type offline-secondary -wait Executing plan 8, waiting for completion... Plan 8 ended successfully
plan failover
コマンドは、他のプランがまだ実行中である場合に実行すると失敗します。このプランを実行する前に、それらのプランを取り消すか中断する必要があります。たとえば、
topology redistribute
が進行中であるとします。plan failover
コマンドを実行すると、失敗します。これを成功させるには、まずtopology redistribute
コマンドを取り消すか中断する必要があります。このためには、最初に
show plans
コマンドを使用して、topology redistributeコマンドのプランIDを調べます。このケースでは9です。次に、plan cancel
コマンドを使用してtopology redistribute
コマンドを取り消します。kv-> plan cancel -id 9
フェイルオーバーを実行した後で、
ping
コマンドを使用して、Manhattanのゾーン・タイプがセカンダリに変更されていることを確認します。kv-> ping Pinging components of store mystore based upon topology sequence #208 200 partitions and 2 storage nodes Time: 2018-10-18 07:39:03 UTC Version: 18.3.2 Shard Status: healthy:0 writable-degraded:1 read-only:0 offline:0 Admin Status: writable-degraded Zone [name=Manhattan id=zn1 type=SECONDARY allowArbiters=false masterAffinity=false] RN Status: online:0 offline:1 Zone [name=JerseyCity id=zn2 type=PRIMARY allowArbiters=false masterAffinity=false] RN Status: online:1 offline:0 Storage Node [sn1] on nyc1:5000 Zone: [name=Manhattan id=zn1 type=SECONDARY allowArbiters=false masterAffinity=false] UNREACHABLE Admin [admin1] Status: UNREACHABLE Rep Node [rg1-rn1] Status: UNREACHABLE Storage Node [sn2] on jersey1:6000 Zone: [name=JerseyCity id=zn2 type=PRIMARY allowArbiters=false masterAffinity=false] Status: RUNNING Ver: 18.3.2 2018-09-17 09:33:45 UTC Build id: a72484b8b33c Admin [admin2] Status: RUNNING,MASTER Rep Node [rg1-rn2] Status: RUNNING,MASTER sequenceNumber:427 haPort:6011 available storage size:12 GB
-
フェイルオーバー操作はこれで完了です。ストアの書込み可用性は、ただ1つの使用可能なプライマリ・ゾーンであるゾーン2を使用して再び確立されています。ゾーン1はオフラインです。障害前にゾーン1から伝播されなかったデータは失われます。
注意:
このケースでは、ストアにデータの作業用コピーが1つしかないため、残存ゾーンで1つのノード障害が発生すると読取りと書込みのアクセスが妨げられます。永続的な障害の場合には、永続的なデータ損失が発生することがあります。
フェイルオーバーの原因となった問題が修正され、機能していなかったノード(Manhattan)の元のデータがまた使用可能になった場合は、スイッチオーバーを実行して元のノードにサービスを戻すことができます。これを行うには、次の項を参照してください。