1. 管理者ガイド
  2. 可用性、フェイルオーバーおよびスイッチオーバーの操作
  3. フェイルオーバーおよびスイッチオーバーの操作
  4. フェイルオーバーの実行

フェイルオーバーの実行

定数が維持されている場合は、ストアが正常に実行しているため、何も行う必要はありません。

ゾーンが機能しなくなったが定数が失われた状況では、フェイルオーバーを実行するしかありません。

たとえば、ストアに2つのプライマリ・ゾーンManhattanとJerseyCityが構成され、ぞれぞれは専用の物理データ・センターにデプロイされているとします。

ノート:

簡潔にするため、この例ではレプリケーション係数が2のストアを使用します。一般に、大半のアプリケーションで適正であり有効な開始点となるプライマリ・レプリケーション係数は3であり、これは、1つのプライマリ・ゾーンに障害が発生した場合、3つのレプリカにより書込み可用性が得られるためです。

さらに、Manhattanゾーンで障害が発生し、その結果、関連するすべてのストレージ・ノードで障害が発生し、定数が失われたとします。このケースでは、Manhattanのホスト・ハードウェアの損傷が修復不可能である場合、または問題の修復に時間がかかりすぎる場合に、フェイルオーバーの開始を選択できます。

この後のステップで、フェイルオーバー操作を実行する際の、障害の確認、ストレージ・ノードの分離、管理定数の削減について説明します。このプロセスにより、ゾーン障害の発生時にサービスを継続できます。

  1. ストアに接続します。このためには、JerseyCityゾーンで実行している管理に接続します。 

    java -Xmx64m -Xms64m -jar KVHOME/lib/kvstore.jar \
runadmin -host jersey1 -port 6000 \
-security USER/security/admin.security

    ノート:

    これは、リモート・アクセスでのセキュリティの構成に記載されているステップに従っていることを前提としています。

  2. 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のストレージ・ノード・エージェントが使用できないことが確認されます。

  3. ハード・ロールバックとデータ損失を防ぐために、機能していないノード(Manhattan)を他のシステムから分離します。機能しなくなったノードはすべて、構成が更新されるまでストアに再結合しないでください。

    このためには、次を実行します。

    • ネットワークを物理的に切断するか、ファイアウォールを使用します。

    • 機能しなくなったノードの起動シーケンスを変更して、SNAが開始しないようにします。

  4. ストアに変更を加えるには、まず管理定数を減らす必要があります。このためには、repair-admin-quorumコマンドを使用して使用可能なプライマリ・ゾーンを指定します。 

    kv-> repair-admin-quorum -znname JerseyCity
Connected to admin in read-only mode
Repaired admin quorum using admins: [admin2]

    これで、一時的に定数を減らした状態で、残りの管理サービスを使用して管理手順を実行できるようになりました。

  5. 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

  6. フェイルオーバー操作はこれで完了です。ストアの書込み可用性は、ただ1つの使用可能なプライマリ・ゾーンであるゾーン2を使用して再び確立されています。ゾーン1はオフラインです。障害前にゾーン1から伝播されなかったデータは失われます。

    ノート:

    このケースでは、ストアにデータの作業用コピーが1つしかないため、残存ゾーンで1つのノード障害が発生すると読取りと書込みのアクセスが妨げられます。永続的な障害の場合には、永続的なデータ損失が発生することがあります。

フェイルオーバーの原因となった問題が修正され、機能していなかったノード(Manhattan)の元のデータがまた使用可能になった場合は、スイッチオーバーを実行して元のノードにサービスを戻すことができます。これを行うには、次の項を参照してください。