追加の管理プロセスの作成

すべてのストレージ・ノードをデプロイしたので、deploy-adminプランを使用して他の管理プロセスを追加できるようになりました。ユーザーは、適切な数の管理を作成する必要があります。

この段階では、1つの管理プロセスがストアにデプロイされています。ここまで、ストア構成を続行するにはこれで十分でした。ただし、ストアの信頼性を高めるには、それぞれ異なるストレージ・ノードで実行される複数の管理プロセスをデプロイする必要があります。こうすることで、1つのSNが到達不能になり、管理プロセスが終了しても、ストアの管理を続行できます。複数の管理プロセスがある場合、管理プロセスを実行しているSNが失われた場合に、ストアの監視を続行することもできます。

plan deploy-adminコマンドを使用して、先ほどデプロイしたノードに管理プロセスを作成します。このコマンドには、show topologyコマンドから取得できるストレージ・ノードIDが必要です。

kv-> show topology
store=MyStore  numPartitions=100 sequence=104
  zn: id=zn1 name=MyRTZone repFactor=1 type=PRIMARY allowArbiters=false masterAffinity=false
  sn=[sn1] zn:[id=zn1 name=MyRTZone] MyHost:5000 capacity=1 RUNNING
  [rg1-rn1] RUNNING
  single-op avg latency=9.420646 ms   
  multi-op avg latency=0.40270275 ms
  numShards=1
  shard=[rg1] num partitions=100
  [rg1-rn1] sn=sn1
kv-> plan deploy-admin -sn sn1 -wait
Executed plan 3, waiting for completion...
Plan 3 ended successfully 

ストアにおける通常のデータ操作には管理は必要ありませんが、DDL操作などの様々な管理操作を実行するために必要です。たとえば、表の作成や変更、ユーザーとロールに関するセキュリティ操作などです。管理サービスを常に使用可能な状態にしておくことが非常に重要です。

管理クォーラムに関する考慮事項

管理サービスの完全な可用性が実現するかどうかは、特定の時間に使用可能な合計管理サービスのクォーラムが確保されているかどうかによって異なります。管理操作のクォーラムを確保することは、シャード内のRNのクォーラムを確保することと似ています。RNの場合はレプリケーション係数によって、サービスの維持が可能な、障害のあるメンバーの数が制御されます。たとえば、次の表は、レプリケーション係数が3の場合に、障害の数がどのように可用性に影響するかを示しています。

障害の数	可用性
0	完全
1	完全
2	読取り専用
3	なし

管理についても、同様の障害と可用性の値が存在します。ストア・レプリケーション係数を使用して、必要な管理の数を決定することをお薦めします。つまり、管理サービスにおける可用性と障害の関係は、ストアにおけるデータ操作と障害の関係と同じであるということです。使用する管理の数を(一般的なレプリケーション係数と同じ) 3未満にすることや、非常に大きい数または偶数の管理を使用することはお薦めしません。

管理では、レプリケーション・ノードと同じ数のデータ・レプリケーションを実行するため、多数の管理を作成すると、すべてのレプリカにデータをレプリケートする必要があるマスター管理の負荷が増大します。すべてのSNに管理を割り当てることは(その規則性から)便利なように思われますが、これによって非常に多数の管理が作成される場合は特にお薦めしません。

ストア・レプリケーション係数と同様に、偶数のレプリカを使用した場合、クォーラム(合計数の多数派)を確保するために過半数が必要となるため、可用性の低下につながります。たとえば、レプリケーション係数が4の場合の障害と可用性の振る舞いは次のようになります。

障害の数	可用性
0	完全
1	完全
2	読取り専用
3	読取り専用
4	なし

つまり、レプリケーション係数が4の場合、単一の障害は許容され、グループは完全な可用性を維持できます。さらに、高いRF値を指定しても障害発生時に利点がないことに加え、障害が発生する可能性があるノードが1つ増えたので、クォーラムを失う可能性が増大します。ここで説明しているレプリケーション係数は、プライマリ・ゾーンに関連付けられているプライマリ・ノードのためのものです。セカンダリ・ゾーンを持つストアの場合、セカンダリ・ゾーン内のノードはクォーラムに含められません。

ゾーン内の使用可能な管理

適切なゾーン内での管理の可用性を確保することは、もう1つの重要な考慮事項です。ストアに複数のプライマリ・ゾーンがある場合、ゾーンは可用性を高めるように設定されていると考えられます。この場合、管理にも同じ配置を反映する必要があります。各ゾーンに、ゾーンのレプリケーション係数と同じ数の管理を作成することをお薦めします。レプリケーション・ノードではシャード内のすべてのノードが読取り操作を処理できることとは異なり、管理操作には管理マスターのみが対応します(マスターがない場合を除く)。したがって、セカンダリ・ゾーンに管理を配置することは、ほとんどの場合、障害リカバリをサポートするためにのみ役立ちます。

たとえば、ストアにプライマリ・ゾーンとセカンダリ・ゾーンがあり、すべてのプライマリ・ゾーンが失われた場合、管理者はrepair-admin-quorumコマンドとplan failoverコマンドを使用し、セカンダリ・ゾーンをプライマリ・ゾーンに変換することで操作を再開できます。ただし、これらの操作は管理ノードが使用可能な場合にのみ発生できます。このため、セカンダリ・ゾーンを持つストアでは、セカンダリ・ゾーンに管理を含める必要があります。