1. 管理者ガイド
  2. 構成
  3. データ・ストアの構成 - 高度なシナリオ
  4. 複数のゾーンでの構成

複数のゾーンでの構成

使用可能なすべての物理設備を最適に利用するには、複数のゾーンにデータ・ストアをデプロイします。複数のゾーンがあることで、1つのゾーンで障害が発生しても、障害を分離してデータの可用性を確保できます。各ゾーンには、すべてのシャードのコピーを含む完全なデータ・ストアのコピーがあります。この構成では、少なくとも1つのレプリカが各ゾーンに存在するため、データの一貫性保証を満たすことができるかぎり、読取りは常に可能です。データベースでクォーラムが維持されるかぎり、1つのゾーンが失われても書込みが発生する可能性があります。概要ガイドを参照してください。

各ゾーンに異なるレプリケーション係数を指定できます。レプリケーション係数は、次のいずれかとして定量化できます。

ゾーン・レプリケーション係数
ゾーンで保持されるコピー、つまりレプリカの数。
プライマリ・レプリケーション係数
すべてのプライマリ・ゾーン内のレプリカの合計数。このレプリケーション係数は、選択および承認に参加するレプリカの数を制御します。 プライマリ・レプリケーション係数およびその関連性の識別方法の詳細は、「レプリケーション係数」を参照してください。
セカンダリ・レプリケーション係数
すべてのセカンダリ・ゾーン内のレプリカの合計数。セカンダリ・レプリカは、追加の読取り専用データ・コピーを提供します。
ストア・レプリケーション係数
データ・ストア全体のレプリカの合計数。

物理的に近い場所にゾーンを配置することには、スループットの制限によるボトルネックを回避でき、選択とコミットの際の遅延が軽減されるという利点があります。

ノート:

ゾーンには、プライマリとセカンダリの2つのタイプがあります。

プライマリ・ゾーンには、マスターまたはレプリカとしてサービスできるノードが含まれます。ゾーンは、デフォルトではプライマリ・ゾーンとして作成されます。パフォーマンス向上のためには、プライマリ・ゾーンが効率的にマスター選択に参加および承認をコミットできるようにするため、低遅延ネットワークで接続している必要があります。プライマリ・ゾーンは、マスター・アフィニティ・ゾーンになることもできます。

セカンダリ・ゾーンには、レプリカとしてのみサービスできるノードが含まれています。セカンダリ・ゾーンを使用して離れた場所にあるデータに対する低遅延読取りアクセスを提供したり、冗長性または読取り機能を向上するためにデータの予備のコピーを保持できます。セカンダリ・ゾーンのノードはマスター選択に参加したり承認をコミットしたりしないため、セカンダリ・ゾーンは高遅延ネットワークで他のゾーンと接続することもできます。これは、余計な遅延がクリティカルな操作を妨害しないからです。

高いスループットで低遅延ネットワークを使用してプライマリ・ゾーンに接続することは、結果を改善し、パフォーマンスを向上します。一時的な中断がネットワーク・スループットを妨害せず、レプリケーションをサポートし、十分な信頼性を保つのに十分なスループットを接続が提供できているかぎりは、セカンダリ・ゾーンへの接続に高遅延ネットワークを使用できます。

ノート:

どのプライマリ・ゾーンでもマスター・ノードをホストできるため、スループットが制限されているか、高遅延のネットワーク・リンクを介してプライマリ・ゾーンに接続している場合、書込みパフォーマンスが低下する可能性があります。

次のステップでは、3つのプライマリ・ゾーンに6つのストレージ・ノードをデプロイするプロセスを示します。その後、すべてのゾーンで各シャードにレプリカがあることを確認できます。これで、ゾーンで障害が発生してもサービスを継続できます。6つすべてのストレージ・ノードにセキュア・データ・ストアを構成します。最初のストレージ・ノードでは、セキュリティが構成され、セキュリティを設定するために、セキュリティ・ディレクトリとそれに含まれるすべてのファイルが最初のストレージ・ノードから他のストレージ・ノードにコピーされます。

次の最初のストレージ・ノード(node01)のステップに従います。
  • 次のコマンドを実行します。
    java -jar $KVHOME/lib/kvstore.jar makebootconfig \
-root $KVROOT \
-port 5000 \
-host $KVHOST \
-harange 5010,5020 \
-store-security configure \
-capacity 1 \
-storagedir ${KVDATA}/disk1 \
-storagedirsize 5500-MB \
  • ストレージ・ノード・エージェントを起動します。
    java -jar $KVHOME/lib/kvstore.jar start -root $KVROOT &
  • 作成されたすべてのセキュリティ・ファイルのzipファイルを作成します。
    cd ; 
zip -r $HOME/security.zip $KVROOT/security; 
cd -
  • このノード(node01)から他の5つのノードに$HOME/security.zipをコピーします。
他の各ストレージ・ノード(node02、node03、node04、node05、node06)で次のステップに従います。
  • 最初のストレージ・ノード(node01)からコピーされたセキュリティ・ファイルを解凍します。
    cd; 
unzip -o security.zip -d /; 
cd -;
  • 次のコマンドを実行します。
    java -jar $KVHOME/lib/kvstore.jar makebootconfig \
-root $KVROOT \
-port 5000 \
-host $KVHOST \
-harange 5010,5020 \
-store-security enable \
-capacity 1 \
-storagedir ${KVDATA}/disk1 \
-storagedirsize 5500-MB \
  • ストレージ・ノード・エージェントを起動します。
    java -jar $KVHOME/lib/kvstore.jar start -root $KVROOT &
最初のストレージ・ノード(node01)から、次のステップを使用してデータ・ストアをデプロイします。
  • 管理CLIを起動します。$KVHOSTはnode01です。
    java -Xmx64m -Xms64m \
-jar  $KVHOME/lib/kvstore.jar runadmin \
-port 5000 -host $KVHOST
-security $KVROOT/security/client.security
  • データ・ストアに名前を付け、3つのプライマリ・ゾーンをデプロイします。
    configure -name MetroArea;
plan deploy-zone -name "Manhattan" -rf 1 -wait;
plan deploy-zone -name "JerseyCity" -rf 1 -wait;
plan deploy-zone -name "Queens" -rf 1 -wait;
  • 管理プロセスを持つ最初のストレージ・ノードをManhattanゾーンにデプロイします。
    plan deploy-sn -znname Manhattan -host node01 -port 5000 -wait;
plan deploy-admin -sn sn1 -wait;
    2番目のストレージ・ノードをマンハッタン・ゾーンにデプロイします。
    plan deploy-sn -znname Manhattan -host node02 -port 5000 -wait;
  • 管理プロセスを持つ最初のストレージ・ノードをJerseyCityゾーンにデプロイします。
    plan deploy-sn -znname JerseyCity -host node03 -port 5000 -wait;
plan deploy-admin -sn sn3 -wait;
    2番目のストレージ・ノードをJerseyCityゾーンにデプロイします。
    plan deploy-sn -znname JerseyCity -host node04 -port 5000 -wait;
  • 管理プロセスを持つ最初のストレージ・ノードをQueensゾーンにデプロイします。
    plan deploy-sn -znname Queens -host node05 -port 5000 -wait;
plan deploy-admin -sn sn5 -wait;
    2番目のストレージ・ノードをクイーンズ・ゾーンにデプロイします。
    plan deploy-sn -znname JerseyCity -host node06 -port 5000 -wait;
  • トポロジを作成してデプロイします。 
    topology create -name Topo1 -pool AllStorageNodes -partitions 300;
plan deploy-topology -name Topo1 -wait;
  • 「ユーザーの作成とリモート・アクセスによるセキュリティの構成」に記載されている手順に従って、複数のゾーン内のユーザーのアクセスを作成します。
  • show topologyコマンドを使用してサービス・ステータスを確認します。 
    kv-> show topology
    出力:
    store=MetroArea  numPartitions=100 sequence=117
  zn: id=zn1 name=Manhattan repFactor=1 type=PRIMARY 
   allowArbiters=false masterAffinity=false
  zn: id=zn2 name=JerseyCity repFactor=1 type=PRIMARY 
   allowArbiters=false masterAffinity=false
  zn: id=zn3 name=Queens repFactor=1 type=PRIMARY 
   allowArbiters=false masterAffinity=false

  sn=[sn1] zn:[id=zn1 name=Manhattan] node01:5000 capacity=1 RUNNING
    [rg1-rn1] RUNNING
          No performance info available
  sn=[sn2] zn:[id=zn1 name=Manhattan] node02:5000 capacity=1 RUNNING
    [rg2-rn1] RUNNING
          No performance info available
  sn=[sn3] zn:[id=zn2 name=JerseyCity] node03:5000 capacity=1 RUNNING
    [rg1-rn2] RUNNING
          No performance info available
  sn=[sn4] zn:[id=zn2 name=JerseyCity] node04:5000 capacity=1 RUNNING
    [rg2-rn2] RUNNING
          No performance info available
  sn=[sn5] zn:[id=zn3 name=Queens] node05:5000 capacity=1 RUNNING
    [rg1-rn3] RUNNING
          No performance info available
  sn=[sn6] zn:[id=zn3 name=Queens] node06:5000 capacity=1 RUNNING
    [rg2-rn3] RUNNING
          No performance info available

  numShards=2
  shard=[rg1] num partitions=50
    [rg1-rn1] sn=sn1
    [rg1-rn2] sn=sn3
    [rg1-rn3] sn=sn5
  shard=[rg2] num partitions=50
    [rg2-rn1] sn=sn2
    [rg2-rn2] sn=sn4
    [rg2-rn3] sn=sn6
  • すべてのゾーンの各シャードにレプリカがあることを確認します。 
    kv-> verify configuration
    出力:
    Verify: starting verification of store MetroArea 
based upon topology sequence #117
100 partitions and 6 storage nodes
Time: 2024-04-05 10:41:15 UTC   Version: 24.1.11
See node01:
$KVROOT/MetroArea/log/MetroArea_{0..N}.log 
for progress messages
Verify: Shard Status: healthy:2 
writable-degraded:0 read-only:0 offline:0 total:2
Verify: Admin Status: healthy
Verify: Zone [name=Manhattan id=zn1 type=PRIMARY allowArbiters=false 
masterAffinity=false]   RN Status: online:2 read-only:0 offline:0
Verify: Zone [name=JerseyCity id=zn2 type=PRIMARY allowArbiters=false 
masterAffinity=false]   RN Status: online:2 read-only:0 offline:0 
maxDelayMillis:1 maxCatchupTimeSecs:0
Verify: Zone [name=Queens id=zn3 type=PRIMARY allowArbiters=false 
masterAffinity=false]   RN Status: online:2 read-only:0 offline:0 
maxDelayMillis:4 maxCatchupTimeSecs:0
Verify: == checking storage node sn1 ==
Verify: Storage Node [sn1] on node01:5000
Zone: [name=Manhattan id=zn1 type=PRIMARY allowArbiters=false 
masterAffinity=false]
Status: RUNNING   Ver: 24.1.11 2024-04-05 10:41:15 UTC  
Build id: c8998e4a8aa5 Edition: Enterprise
Verify: 	Admin [admin1]		Status: RUNNING,MASTER
Verify: 	Rep Node [rg1-rn1]	Status: RUNNING,MASTER 
sequenceNumber:1,261 haPort:5011 available storage size:31 GB
Verify: == checking storage node sn2 ==
Verify: Storage Node [sn2] on node02:5000    
Zone: [name=Manhattan id=zn1 type=PRIMARY 
allowArbiters=false masterAffinity=false]    
Status: RUNNING   Ver: 24.1.11 2024-04-05 10:41:15 UTC    
Build id: c8998e4a8aa5 Edition: Enterprise
Verify: 	Rep Node [rg2-rn1]	Status: RUNNING,MASTER 
sequenceNumber:1,236 haPort:5012 available storage size:31 GB
Verify: == checking storage node sn3 ==
Verify: Storage Node [sn3] on node03:5000    
Zone: [name=JerseyCity id=zn2 type=PRIMARY 
allowArbiters=false masterAffinity=false]    
Status: RUNNING   Ver: 24.1.11 2024-04-05 10:41:15 UTC  
Build id: c8998e4a8aa5 Edition: Enterprise
Verify: 	Admin [admin2]		Status: RUNNING,REPLICA
Verify: 	Rep Node [rg1-rn2]	Status: RUNNING,REPLICA 
sequenceNumber:1,261 haPort:5011 available storage size:31 GB 
delayMillis:1 catchupTimeSecs:0
Verify: == checking storage node sn4 ==
Verify: Storage Node [sn4] on node04:5000    
Zone: [name=JerseyCity id=zn2 type=PRIMARY 
allowArbiters=false masterAffinity=false]    
Status: RUNNING   Ver: 24.1.11 2024-04-05 10:41:15 UTC  
Build id: c8998e4a8aa5 Edition: Enterprise
Verify: 	Rep Node [rg2-rn2]	Status: RUNNING,REPLICA 
sequenceNumber:1,236 haPort:5012 available storage size:31 GB 
delayMillis:0 catchupTimeSecs:0
Verify: == checking storage node sn5 ==
Verify: Storage Node [sn5] on node05:5000    
Zone: [name=Queens id=zn3 type=PRIMARY 
allowArbiters=false masterAffinity=false]    
Status: RUNNING   Ver: 24.1.11 2024-04-05 10:41:15 UTC  
Build id: c8998e4a8aa5 Edition: Enterprise
Verify: 	Admin [admin3]		Status: RUNNING,REPLICA
Verify: 	Rep Node [rg1-rn3]	Status: RUNNING,REPLICA 
sequenceNumber:1,261 haPort:5011 available storage size:31 GB 
delayMillis:1 catchupTimeSecs:0
Verify: == checking storage node sn6 ==
Verify: Storage Node [sn6] on node06:5000    
Zone: [name=Queens id=zn3 type=PRIMARY 
allowArbiters=false masterAffinity=false]    
Status: RUNNING   Ver: 24.1.11 2024-04-05 10:41:15 UTC  
Build id: c8998e4a8aa5 Edition: Enterprise
Verify: 	Rep Node [rg2-rn3]	Status: RUNNING,REPLICA 
sequenceNumber:1,236 haPort:5012 available storage size:31 GB 
delayMillis:4 catchupTimeSecs:0

Verification complete, no violations.

上の例では、データ・ストアに6つのレプリケーション・ノード(2つのマスターおよび4つのレプリカ)を持つ3つのゾーン(zn1 = Manhattan、zn2 = JerseyCity、zn3=Queens)があります。これは、このトポロジは各シャード内に3つのレプリカがあるため可用性が高いだけでなく、1つのゾーンで障害が起こってもリカバリできることを意味します。ゾーンに障害が発生した場合、新しいマスターを選択するには残りの2つのゾーンで十分なため、サービスは中断することなく続行します。