topology

ストア・トポロジを操作するコマンドをカプセル化します。たとえば、ノードの再ディストリビューション/再均衡化、レプリケーション係数の変更などです。トポロジは、このコマンドを使用して作成および変更されます。次にplan deploy-topologyコマンドを使用してデプロイされます。詳細は、「plan deploy-topology」を参照してください。サブコマンドは次のとおりです。

• topology change-repfactor

• topology change-zone-arbiters

• topology change-zone-type

• topology clone

• topology contract

• topology create

• topology delete

• topology list

• topology preview

• topology rebalance

• topology redistribute

• topology validate

• topology view

topology change-repfactor

topology change-repfactor -name <name>  -pool <pool name>
    -zn <id> | -znname <name> -rf <replication factor> 

トポロジを変更して、指定されたゾーンのレプリケーション係数を新しい値に変更します。セカンダリ・ゾーンのレプリケーション係数は減らすことができますが、プライマリ・ゾーンのレプリケーション係数を減らすことは現在サポートされていません。

レプリケーション係数を増やすと、このコマンドでは、レプリケーション・ノードまたはアービタ・ノードを作成したり、指定したゾーン内のアービタ・ノードのみを削除できます。レプリケーション係数の変更に伴って、プライマリ・レプリケーション係数の合計が2に増加した場合に、ゾーンがアービタを許可するように構成されていると、そのゾーンにアービタが作成されます。レプリケーション係数の変更に伴って、プライマリ・レプリケーション係数の合計が2からそれより大きい数に増加した場合に、ゾーンにアービタが含まれていると、そのゾーンからアービタが削除されます。他のゾーンにアービタが含まれている場合に、トポロジからアービタを削除するには、トポロジのリバランスを行う必要があります。

レプリケーション係数の増加の詳細は、レプリケーション係数の増加を参照してください。

セカンダリ・ゾーンのレプリケーション係数を減らすと、このコマンドではゾーンからレプリケーション・ノードが削除されます。

セカンダリ・ゾーンを削除する場合は、そのセカンダリ・ゾーンのレプリケーション係数を減らしてゼロにする必要があります。

レプリケーション係数を減らしてゼロにしてから、次のステップを実行してセカンダリ・ゾーンを削除します。

1. plan remove-adminコマンドを使用して、ゾーン内の管理者を削除します。
2. plan remove-snコマンドを使用してゾーン内のストレージ・ノードを削除します。
3. plan remove-zoneコマンドを使用してゾーンを削除します。

topology change-zone-arbiters

topology change-zone-arbiters -name <name>
    {-zn <id> | -znname <name>}  {-arbiter | -no-arbiter}

トポロジを変更して、指定したゾーンのアービタ・ノード属性を変更します。

topology change-zone-master-affinity

topology change-zone-master-affinity -name <name>
    -zn <{-no-master-affinity | -master-affinity} 

既存のゾーンを指定して、そのゾーンのトポロジを–no-master-affinityまたは–master-affinityに変更します。たとえば:

topology change-zone-master-affinity -name new-topo -zn zn1 -no-master-affinity

このコマンドは、最初にトポロジをデプロイ(plan deploy-zone)した後に使用します。

topology change-zone-type

topology change-zone-type -name <name>
    {-zn <id> | -znname <name>} -type {primary | secondary} 

トポロジを変更して、指定されたゾーンのタイプを新しいタイプに変更します。

1つ以上のゾーンのタイプが変更され、結果として生成されたトポロジがplan deploy-topologyコマンドを使用してデプロイされる場合、次のルールが適用されます。

• プランは、プライマリ・ノードに変換されているセカンダリ・ノードがマスターに追い付くまで、最長5分間待機します。

• 各シャードのセカンダリ・ノードの定数が所定の時間内に追い付けなかった場合、プランは失敗し、遅延ゾーンおよびノードの詳細を出力します。この動作は、新たに追加されたプライマリ・ノードがマスターになれず、可用性に貢献できない時間を短縮するために役立ちます。

• このコマンドを正常に実行できるのは、定数が維持できる場合のみであるため、データが失われることはありません。

topology clone

topology clone -from <from topology> -name <to topology>

または

topology clone -current -name <to topology> 

トポロジ変更操作に使用される新規のトポロジ候補を作成するために、既存のトポロジをクローニングします。

topology contract

topology contract -name <name> -pool <pool name>

指定したトポロジを変更してストレージ・ノードを縮小します。詳細は、「トポロジの縮小」を参照してください。

topology create

topology create -name <candidate name> -pool <pool name> [-json] 
    -partitions <num>

指定されたストレージ・プールを使用して、指定されたパーティション数の新規トポロジを作成します。

トポロジ候補名ではドル記号('$')を使用しないでください。名前に予約文字が含まれるトポロジの作成またはクローニングを試行すると、CLIによって警告が表示されます。

プライマリ・レプリケーション係数が2と等しい場合、topology createコマンドでは、アービタ・ノードのホストをサポートするゾーン内のストレージ・ノードにアービタ・ノードを割り当てます。トポロジのデプロイ中に、アービタ・ノードを分散するのに十分なストレージ・ノードが存在しない場合は、エラーが発行されます。レプリケーション・グループの他のメンバーが含まれていないストレージ・ノードでアービタ・ノードをホストすることで、アービタ・ノード分散が有効になります。

最初のトポロジ候補の作成の詳細は、「トポロジ候補の作成」を参照してください。

kv-> topology create -name mytopo -pool snpool -json -partitions 20
{
	"operation" : "topology create",
	"returnCode" : 5000,
	"description" : "Operation ends successfully",
	"returnValue" : {
		"store" : "mystore",
		"numPartitions" : 20,
		"sequence" : 32,
		"zone" : [ {
		"id" : "zn1",
		"name" : "1",
		"repfactor" : 1,
		"type" : "PRIMARY"
		}, {
	"id" : "zn2",
	"name" : "2",
	"repfactor" : 1,
	"type" : "PRIMARY"
	}, {
	"id" : "zn3",
	"name" : "3",
	"repfactor" : 1,
	"type" : "PRIMARY"
	} ],
	"sns" : [ {
	"id" : "sn1",
	"zone_id" : "zn1",
	"host" : "localhost",
	"port" : 20000,
	"capacity" : 1,
	"rns" : [ "rg1-rn1" ],
	"ans" : [ ]
	}, {
	"id" : "sn2",
	"zone_id" : "zn2",
	"host" : "localhost",
	"port" : 21000,
	"capacity" : 1,
	"rns" : [ "rg1-rn2" ],
	"ans" : [ ]
	}, {
	"id" : "sn3",
	"zone_id" : "zn3",
	"host" : "localhost",
	"port" : 22000,
	"capacity" : 1,
	"rns" : [ "rg1-rn3" ],
	"ans" : [ ]
	} ],
	"shards" : [ {
		"id" : "rg1",
		"numPartitions" : 20,
		"rns" : [ "rg1-rn1", "rg1-rn2", "rg1-rn3" ],
		"ans" : [ ]
		} ],
	"name" : "mytopo"
	}
}

topology delete

topology delete -name <name> 

トポロジを削除します。

topology list

topology list 

既存のトポロジを一覧表示します。

topology preview

topology preview -name <name> [-start <from topology>]

起動トポロジから指定されたターゲット・トポロジに移行するために実行される操作について説明します。-startが指定されていない場合、現行トポロジが使用されます。このコマンドは、新規トポロジをデプロイする前に使用する必要があります。

topology rebalance

topology rebalance -name <name> -pool <pool name>
    [-zn <id> | -znname <name>]

topoplogy rebalanceコマンドの目的

データ・ストアにおいては、topology rebalanceコマンドは、非コンプライアンス・トポロジをコンプライアンス・トポロジ状態に変更して、均衡のとれたトポロジにします。コンプライアンス・トポロジについては、そのトポロジが特定のルール・セットに従っていることを確認する必要があります。詳細は、「ストアの構成の決定」を参照してください。

topology rebalanceコマンドの引数は次のとおりです:

• -name: 均衡化するトポロジの名前。
• -pool: ストレージ・ノード・プールの名前。
• -zn <id>または-zname <name>: これらの引数はオプションであり、ゾーンのidまたはnameを指定できます。

  ノート:

  オプションの-znまたは-znameフラグが使用されている場合は、指定されたゾーンにあるストレージ・ノードのみが操作に使用されます。

データ・ストアの物理特性に変更が加えられた場合は、不均衡になる可能性があります。次に例を示します:

• ストレージ・ノードの容量が増えたか減ったことで、それぞれ容量過剰または容量不足になる。
• ストレージ・ノード、レプリケーション・ノードのディスク・サイズに変化がある。
• アービタ・ノードが、トポロジでそれらがサポートされていない場合に存在する。
• アービタ・ノードが、トポロジでそれらがサポートされている場合に存在しない。
• レプリケーション係数ゼロのゾーンが存在するときに、アービタ・ノードが、レプリケーション係数がゼロより大きいゾーンに存在する。
• シャード構成に変化がある。たとえば、弾力性の変化が原因でシャード内のパーティションの数が変わるなどです。

このコマンドにより、物理的な変更によって発生した違反や注意事項を解決することでコンプライアンスが確保されます。これにより、アービタ・ノードとレプリケーション・ノードが追加、移動または削除されます。たとえば、topology rebalanceコマンドによって次のことが実行されます:

• ストレージ・ノードの新しい容量と一致するようにレプリケーション・ノードを移動します。
• 新しいトポロジでアービタ・ノードがサポートされており古いトポロジでサポートされていない場合は、アービタ・ノードを追加します。
• 古いトポロジでアービタ・ノードがサポートされており新しいトポロジでサポートされていない場合は、アービタ・ノードを削除します。
• アービタ・ノードがレプリケーション係数がゼロより大きいゾーンでホストされている場合は、それをレプリケーション係数ゼロのゾーンに移動します。
• シャード構成に変更があった場合にパーティション移行を開始します。

このコマンドを使用できるシナリオの詳細は、「topology rebalanceコマンドの使用方法」を参照してください。

verifyコマンドを使用することで、データ・ストアのトポロジを検証できます。詳細は、「ストアの検証」を参照してください。

verify configuration

ノート:

topology rebalanceコマンドは、物理特性の変化がなくトポロジが完全に準拠している場合は必要ありません。

topology rebalanceコマンドの使用方法

データ・ストアを最初にデプロイするときは、その構成(つまりトポロジ)を確立し、設定中に、リバランスの必要なくすべての要件を満たしてることを確認します。トポロジの物理特性(ストアの構成や容量など)に変更がある場合は、次のようにします:

1. verify configurationコマンドを実行して違反または検証ノートを表示します。
2. topology rebalanceコマンドを実行して非コンプライアンス・トポロジを修正します。

次に、topology rebalanceコマンドを使用すると違反や検証ノートを修正でき非コンプライアンス・トポロジからコンプライアンス・トポロジへの移行に役立つシナリオをいくつか示します。

• レプリケーション・ノード割当て違反:
  • コマンドplan change-parametersを使用してストレージ・ノードの定義済容量を変更し、そのすべてのレプリケーション・ノードをホストするのに不十分な値にすると、不均衡が発生し、容量が過剰になります。

    Verification violation: [sn1]  sn1 has 2 repNodes and is over its capacity limit of 1

  • ストレージ・ノードの容量がそれらでホストしているレプリケーション・ノードよりも多い場合は、データ・ストアでそのリソースが十分に利用されないため、容量が不足します。

    Verification note: [sn1]  sn1 has 0 RepNodes and is under its capacity limit of 1

    ノート:

    • topology rebalanceコマンドにより、十分に利用されていないストレージ・ノードから過剰利用されているストレージ・ノードにレプリケーション・ノードを移動することで、容量過剰と容量不足が解決されます。これにより、すべての利用可能リソースの使用が最適化されます。
    • 容量過剰の問題がない場合は、topology rebalanceコマンドによって容量不足を積極的に解決できません。反対に、容量不足の問題がない場合は、容量過剰を解決できません。
• アービタ・ノード割当て違反:
  • レプリケーション係数2のプライマリ・ゾーンがあり、ストレージ・ノード容量とレプリケーション係数がゼロの新しいゾーンをデプロイするとします。この新しいゾーンでは、アービタ・ノードのみをホストできます。この場合は、アービタ・ノードが不十分であるため、違反が発生します。詳細は、概要ガイドのアービタ・ノードを参照してください。

    Verification violation: [rg1]  The shard rg1 does not have an Arbiter.

    topology rebalanceコマンドにより、他のレプリケーション・ノードとともに同じシャード内のアービタ・ノードを移動することで、この問題が解決されます。

  • トポロジでアービタ・ノードがすでにホストされている場合に、容量が1でアービタがfalseに設定されているストレージ・ノードを含む新しいゾーンをデプロイするとします。更新されたトポロジではアービタ・ノードをホストできないため、余分なアービタ・ノードがあることについて検証ノートが示されます。

    Verification note: [rg1]  Shard rg1 has an Arbiter when it should not.

    topology rebalanceコマンドにより、アービタ・ノードを同じシャード内の追加されたストレージ・ノードに置き換えることで、問題が解決されます。

  • トポロジにおいて、アービタ・ノードが、他のレプリケーション・ノードを含むゾーン内にあり、アービタ専用ゾーンと呼ばれるレプリケーション係数ゼロの別のゾーンが存在します。この違反は、そのアービタ・ノードをレプリケーション係数ゼロのゾーンに移動する必要があることを示しています。

    Verification violation: [rg1-an1]  rg1-an1 is hosted in zone zn1; a better zone host is zn2

    高可用性とパフォーマンス向上のために、topology rebalanceコマンドによって、そのアービタ・ノードがレプリケーション係数ゼロのゾーンに移動されます。

  • 最初にゾーン内のアービタを許可してから、アービタを拒否するようにその構成を変更した場合、verify configurationコマンドでは、引き続き、アービタがtrueに設定されている初期設定が示されます。

    Verification violation: [rg1-an1]  sn3 doesn't allow arbiters but hosts rg1-an1

    topology rebalanceコマンドによって、アービタ・ノードを削除しトポロジの構成を更新することで、その違反が修正されます。

• シャード内のストレージ・ノードのディスク構成が変更されている場合は、topology rebalanceコマンドによってパーティションの移行が開始されます。これにより、ディスク・サイズに比例してシャード間でパーティションの均衡がとられます。

  Verification note: [rg1]  rg1 should have 80 partitions if balanced, but has 50
  Verification note: [rg2]  rg2 should have 20 partitions if balanced, but has 50

  ノート:

  シャード内のストレージ・ノードの最小数が合計の半分より少ない場合は、topology rebalanceコマンドによってパーティションは移行されません。新規導入なしでパーティション分散の実行によってのみ違反または検証ノートが解決され、シャード内のすべてのレプリケーション・ノード上のディスク領域でその変更がサポートされている場合のみパーティションが移動されます。

ノート:

topology rebalanceの実行中は、データ・ストアのパフォーマンスが低下し、書込みクォーラムが失われる可能性が高くなります。クォーラムを参照してください。そのため、データ・ストアの休止時間中にtopology rebalance操作を実行する必要があります。

topology rebalanceコマンドにより、ほとんどの違反が解決されて非コンプライアンス・トポロジがコンプライアンス・トポロジに移行されます。しかしながら、最適な結果を得るには、一部の違反や検証ノートを手動で解決する必要があります。「違反と解決策の表」(表4-1)を参照してください。

非コンプライアンス・トポロジの均衡化の詳細は、「非コンプライアンス・トポロジの均衡化」を参照してください。

topology redistribute

topology redistribute -name <name> -pool <pool name> 

使用可能なリソースのより効率的な利用のためにリソースを再配布するため、指定されたトポロジを変更します。

書込みスループットを向上させるためのリソースの再配布の詳細は、「データ配布の増加」を参照してください。

topology validate

topology validate [-name <name>] 

指定されたトポロジを検証します。トポロジが指定されていない場合、現行トポロジが検証されます。検証ではviolationsとnotesが生成されます。

violationsは問題を引き起こす可能性があり、調査が必要です。

notesは情報的で、問題になる可能性がある、または予測が可能であるという、構成上の目立つ差異を示します。

詳細は、「トポロジ候補の検証」を参照してください。

topology view

topology view -name <name> 

指定されたトポロジの詳細を表示します。また、アービタ・ノード情報が使用可能であれば、その情報を表示します。