マスター・アフィニティ・ゾーンの使用

マスター・アフィニティ・ゾーンを使用すると、クライアント・アプリケーションの書込みリクエストを処理するプライマリ・ゾーンを指定できます。

Oracle NoSQL Databaseではゾーンが使用されます。ゾーンによってKVStore全体が複製され、データ・ストアが分散されて複数の物理的な場所を横断してロードされます。ゾーンを使用すると、致命的なデータ損失や運用中断を回避できます。ゾーンは、多数のストレージ・ノード(SN)とレプリケーション・ノード(RN)で構成されます。概要マニュアルアーキテクチャを参照してください。

次の2種類のゾーンが存在します。

  • プライマリ・ゾーン — マスター・ノードとレプリケーション・ノードの両方をホストできますが、必須ではありません。データの読取りおよび書込みリクエストは、そのようなリクエストを処理するように構成されたプライマリ・ゾーンに移動します。

  • セカンダリ・ゾーン — マスター・ノードはありません。クライアント・アプリケーションからの読取りリクエストのみを処理します。

各シャードには1つのマスター・ノードがあり、これによってすべてのRNにデータを書き込むことができます。ゾーンのタイプに関係なく、すべてのゾーンでは、RNへのデータの書込みに最適なパフォーマンスを維持し、アプリケーション・データ・リクエストのためにRNからデータにアクセスするために、質の高いネットワーク接続を必要とします。

どのプライマリ・ゾーンがマスター・アフィニティを持つかを選択することで、特定のプライマリ・ゾーンに書込みリクエストを送信できるようにします。-master-affinityプロパティを設定することでそのような指定を確定する一方、デフォルトの–no-master-affinityプロパティを保持することで、ゾーンがマスター・アフィニティ・ゾーンではないことを指定します。–master-affinityプロパティを使用して、様々なシャードからのマスター・ノードをマスター・アフィニティ・ゾーンに編成することには、次のような利点があります。

  • マスター・アフィニティ・ゾーンは、シャードをまたぐ高需要の書込みリクエストを処理します。

  • マスター・ノードに障害が発生したとき、サービスの遅れはほとんどなしに、障害が発生したノードから、マスター・アフィニティ・ゾーンからの置換先に引き継ぐことができます。

  • マスター・アフィニティ・ゾーンのRNでは、標準の選択プロセスを実行して、失敗したマスター・ノードの役割を担うマスター・ノードを決定します。

マスター・アフィニティ・ゾーンを正常に使用するには、最も高需要のクライアント・アプリケーションに近接したゾーンの知識が必要になります。これにより、そのクライアント・アプリケーションは、マスター・アフィニティ・ゾーンのマスター・ノードとRNの両方によって予測的に処理されます。

マスター・アフィニティ・ゾーンの利点

マスター・アフィニティは、ゾーンのプロパティです。ゾーンは、マスター・アフィニティ・プロパティ(-master-affinity)を持つか、持たない(-no-master-affinity)かのいずれかになります。多くの場合、特定のプライマリ・ゾーンがマスター・アフィニティ・ゾーンになるように選択します。これは、ゾーンでクライアントの書込みリクエストを処理することが理想的であるためです。アプリケーション需要に近接し、それを処理するための高品質の通信能力のあるゾーンが候補になります。

マスター・アフィニティ・プロパティは、プライマリ・ゾーンにのみ設定できます。そのようにすると、マスター・アフィニティ・ゾーン内のノードのみがフェイルオーバー中にマスターになることができます。マスター・アフィニティ・ゾーンに1つ以上のマスター・ノードを配置することで、低遅延の書込みアクティビティと高可用性の両方がサポートされます。

通常、マスター・ノードに障害が発生すると、レプリケーション・ノード(RN)では新しいマスター・ノードを選択するための選択プロセスが開始されます。選択では、アルゴリズム的なアプローチによって、最新のデータを使用してRNを選択する基準などが使用されます。マスター・アフィニティ・ゾーンがある状態でマスター・ノードに障害が発生すると、類似するプロセスが実行されます。新しいマスター・ノードが存在する場合、書込みリクエストは自動的に新しいマスターに送信され、絶対整合性リクエストはマスター・アフィニティ・ゾーンの新しいマスターによって処理されます。

すべてのストレージ・ノード(SN)では、それ自体がマスター・アフィニティ・ゾーンの一部かどうかを判断できます。マスター・アフィニティ・ゾーンの一部でない場合、それらは、選択中に、潜在的なマスター・ノードとしてマスター・アフィニティ・ゾーンに転送されるRNをホストする候補がどのSNになるかを判断するために役立ちます。マスター・アフィニティ・ゾーンを選択してRNを割り当てると、現在のマスター・ノードに障害が発生した場合、次に適用可能なノードがその役割を担います。

マスター・アフィニティ・ゾーンの追加

マスター・アフィニティ・ゾーン・パラメータの説明と、その設定の効果を説明します。

マスター・アフィニティ・ゾーンの使用はオプションです。デフォルトでは、現在のリリースにアップグレードした後、すべてのゾーンが-no-master-affinityに設定されます。マスター・アフィニティを使用するには、ゾーン・プロパティを手動で変更します。マスター・アフィニティ・ゾーンのプロパティは、レプリケーション・ノード・マスターにのみ影響を与え、データベース管理マスターには影響を与えません。この項では、マスター・アフィニティ・ゾーンの使用方法と、それらが操作にどのような影響を与える可能性があるかについて説明します。

まず、どのゾーンがマスター・アフィニティを持つようにするかを選択します。選択したゾーンは、処理するアプリケーションに物理的に近接する必要があります。これにより、マスター・アフィニティ・ゾーンによって、最も低遅延の書込みパフォーマンスが提供されます。

たとえば、次のトポロジでは、シャードが2つ(2) (rg1およびrg2)、レプリケーション係数が3 (3)となり、2 * 3 KVSTOREとして記述され、rg2–rn1rg1–rn2はそれぞれzn1zn2のマスター・ノードです。

Storage Node [sn1] on localhost:5100 		Zone: [name=1 id=zn1 
type=PRIMARY allowArbiters=false 			Status: RUNNING
	Admin [admin1] 			Status: 			RUNNING,MASTER 
	Rep Node [rg1-rn1] 		Status: 			RUNNING,REPLICA 
	Rep Node [rg2-rn1] 		Status: 			RUNNING,MASTER 
Storage Node [sn2] on localhost:5200 		Zone: [name=2 id=zn2 
type=PRIMARY allowArbiters=false  			Status: RUNNING
	Admin [admin2] 			Status: 			RUNNING,REPLICA 
	Rep Node [rg1-rn2] 		Status: 			RUNNING,MASTER 
	Rep Node [rg2-rn2] 		Status: 			RUNNING,REPLICA 
Storage Node [sn3] on localhost:5300 		Zone: [name=3 id=zn3 
type=PRIMARY allowArbiters=false  			Status: RUNNING
	Admin [admin3] 			Status: 			RUNNING,REPLICA 
	Rep Node [rg1-rn3] 		Status: 			RUNNING,REPLICA 
	Rep Node [rg2-rn3] 		Status: 			RUNNING,REPLICA

次に、マスター・アフィニティを使用する前のゾーンを示します。プライマリ・ゾーン1および2のそれぞれのシャードには、マスター・ノード(rg1rg2)があります。

図4-1 マスター・アフィニティの前のゾーンの分散

図4-1の説明が続きます。
「図4-1 マスター・アフィニティの前のゾーンの分散」の説明

マスター・アフィニティの設定に最適なプライマリ・ゾーンを選択した後、–master-affinityプロパティを次のように設定します。

  • ゾーンを初めてデプロイするときには、plan deploy-zoneコマンドを使用します。

  • ゾーンをデプロイした後は、topology change-zone-master-affinityコマンドを使用します。

たとえば、master-affinityゾーン・プロパティを変更するために、ストアmystoreを構成する一部として使用されるplan deploy-zoneコマンドを次に示します。この例では、ゾーン2のmaster-affinityプロパティを設定します。

configure -name mystore
plan deploy-zone -name 1 -rf 1 -no-master-affinity -wait
plan deploy-zone -name 2 -rf 1 -master-affinity -wait
plan deploy-zone -name 3 -rf 1 -wait

ノート:

ゾーン2に対してマスター・アフィニティが有効である場合は、2つのシャードの両方のマスター・ノードがゾーン2に配置されます。

図4-2 マスター・アフィニティの後のゾーンの分散

図4-2の説明が続きます。
「図4-2 マスター・アフィニティの後のゾーンの分散」の説明

マスター・アフィニティ・ゾーン・ノードの喪失

マスター・アフィニティ・ゾーンでマスター・ノードに障害が発生した場合の処理について説明します。

初期設定後に、どのプライマリ・ゾーンをマスター・アフィニティ・ゾーンにするかを決定します。マスター・アフィニティ・ゾーンを使用すると、そのゾーン内のマスター・ノードへの書込みリクエストが最適化されます。ストレージ・ノード(SN)では、それ自体がマスター・アフィニティ・ゾーンの一部かどうかを検出できます。そのSN自体がゾーンの一部ではない場合、どのSNがマスター・アフィニティ・ゾーンの一部であるかが検出されます。

マスター・アフィニティ・ゾーン・マージ・ノードに障害が発生すると、RNによって、適用可能なノードがゾーン内に存在するかどうかが検出されます。たとえば、マスター・アフィニティ・ゾーンに別のマスター・ノードがある場合があります。別のマスター・ノードを使用できない場合、RNでは、最適な候補を選択するか、他のゾーンの適用可能なRNをマスター・ノードの検討対象としてマスター・アフィニティ・ゾーンに移行します。このようなゾーンの再割当ては、マスター・アフィニティ・ゾーンをサポートするために自動的に発生します。

最後に、RNでは、次のマスター・ノードになるノードを決定するために投票します。新しいマスター・ノードについての投票および決定においては、パフォーマンスが最大のRNのみがマスター・アフィニティ・ゾーン内のマスター・ノードになることができます。次のマスター・ノードが使用可能になると、Oracle NoSQLによって、すべての書込みリクエストおよび絶対整合性要件がそのマスターに送信されます。