ストアは多数のストレージ・ノードで構成されます。各ストレージ・ノードは1つ以上のレプリケーション・ノードを、その容量値に基づいてホストできます。topologyという用語はレプリケーション・ノードのディストリビューションの説明に使用されます。トポロジは、使用可能なストレージ・ノードの数および容量、ストア内のパーティションの数や、ストアのゾーンのレプリケーション係数から導出されます。トポロジ・レイアウトも、ストアの可用性を最大化するための一連のルールによって管理されます。
すべてのトポロジが次のルールに従う必要があります。
同じシャードからのレプリケーション・ノードはそれぞれ異なるストレージ・ノードに配置する必要があります。このルールによって、1つのストレージ・ノードの障害が、1つのシャードに対する複数の場所の障害を引き起こすことが回避されます。
ストレージ・ノードに割り当てられたレプリケーション・ノードの数は、ストレージ・ノードの容量と同じかそれ以下にする必要があります。
1つのゾーンには各シャードからの1つ以上のレプリケーション・ノードが必要です。
ストアの初期構成、またはトポロジは、ストアの作成時に設定されます。後々、ストアのトポロジの変更が必要になる場合があります。この変更の理由はいくつかあります。
ストレージ・ノードの置換またはアップグレードが必要です。
読取りスループットを増やす必要があります。これを実現するには、レプリケーション係数を増やし、読取り専用リクエストのサービスに使用できるストアのデータのコピーをさらに作成します。
書込みスループットを増やす必要があります。各シャードには1つのマスター・ノードがあるため、ストア内データを多数のシャードに対して配布すると、書込み操作を実行できるノードがさらにストアに提供されます。
使用可能なストレージ・ノードの数または容量、もしくはゾーンのレプリケーション係数を変更することで、ストアの構成を変更します。ある構成から別の構成に変更するには、新規の初期トポロジを作成するか、既存のトポロジにcloneを行ってからそれをターゲット・トポロジに変更します。次に、このターゲット・トポロジをデプロイします。
ターゲット・トポロジのデプロイは、実行に時間がかかる可能性があり、必要な時間は移動対象のデータ量に比例します。デプロイの間、システムはトポロジを各ステップで更新します。このため、ユーザーによって明示的に作成されなかった中間トポロジは、ストアでは通過されます。
この章では構成の、つまりトポロジ的な変更がストアでどのように行われるかを説明します。
スナップショットの作成中は構成を変更しないでください。その逆も同様です。構成を変更する場合、まずスナップショットをバックアップとして作成してから変更を行うのが安全な方法です。スナップショットの作成の詳細は、「スナップショットの作成」を参照してください。
トポロジを変更する際は、次のステップを実行する必要があります。
新規トポロジの作成は反復的なプロセスである可能性があります。変更をデプロイする前に、各種のオプションを試して何が最適かを確認する場合があります。最後に、トポロジ候補を調べてそれが満足できるかどうかを判断します。満足できない場合は、さらに変換を適用するか、別のパラメータで最初からやり直します。トポロジ候補を表示および検証して、それが適切かどうかを判断できます。
可能な変換としてはデータの再配布、レプリケーション係数の増加、および再均衡化があります。この詳細は「トポロジ候補の変換」で説明します。
次の各項で、管理コマンドライン・インタフェースを使用してストアの構成を変更するプロセスについて順を追って説明します。
レプリケーション・ノードが存在する前に、初期デプロイのための最初のトポロジ候補を作成するには、topology createコマンドを使用します。topology createコマンドはトポロジ名、プール名およびパーティション数を引数として使用します。
次に例を示します。
kv-> topology create -name firstTopo -pool BostonPool -partitions 300 Created: firstTopo
この初期トポロジ候補は、さらに変換を行わなくても、plan deploy-topologyコマンドを使用してデプロイできます。
ストアがデプロイされた後、トポロジ候補はtopology cloneコマンドで作成されます。クローンのソースとしては別のトポロジ候補や、現行のデプロイ済トポロジが可能です。topology cloneコマンドでは次の引数を使用します。
-from <from topology>
ソースのトポロジ候補の名前。
-name <to topology>
クローンの名前。
次に例を示します。
kv-> topology clone -from topo -name CloneTopo Created CloneTopo
また、次の引数を使用するtopology createコマンドのバリアントもあります。
-current
指定された場合、現行のデプロイ済トポロジをソースとして使用します。
-name <to topology>
クローンの名前。
次に例を示します。
kv-> topology clone -current -name ClonedTopo Created ClonedTopo
初期デプロイ後は、現在有効なトポロジと異なるトポロジ候補をデプロイすることで、ストアは変更されます。このターゲット・トポロジは、topology redistribute, rebalance, or change-repfactorコマンドを使用してトポロジ候補を変換することで生成されます。
変換は、前の項で説明したトポロジ・ルールに従います。
topology rebalance, redistribute or change-repfactorコマンドは、追加的な、または変更済のストレージ・ノードが使用可能な場合、トポロジ候補への変更のみを実行できます。レプリケーション・ノードおよびパーティションの再調整には新規リソースが使用されるため、トポロジはトポロジ・ルールに従い、ストアでは読取りまたは書込みスループットが向上します。
ストアを拡張する場合のシナリオを次に示します。
書込みスループットを向上させるため、topology redistributeコマンドを使用してデータ配布を増加できます。redistributeコマンドは、新規シャードの作成を許可するために新規ストレージ・ノードが追加される場合のみ、機能します。パーティションは新規シャード全体に配布されるため、書込み操作のサービスを行うレプリケーション・ノードが増加します。
次の例では、ストレージ・ノードのセットの追加と、そのノードへのデータの再配布を示します。ゾーンのレプリケーション係数が4で、レプリケーション要件を満たすには新規パーティションに4つのノードが必要なため、この例では4つのノードが追加されます。
kv-> plan deploy-sn -zn zn1 -host node04 -port 5000 -wait Executed plan 7, waiting for completion... Plan 7 ended successfully kv-> plan deploy-sn -zn zn1 -host node05 -port 5000 -wait Executed plan 8, waiting for completion... Plan 8 ended successfully kv-> plan deploy-sn -zn zn1 -host node06 -port 5000 -wait Executed plan 9, waiting for completion... Plan 9 ended successfully kv-> plan deploy-sn -zn zn1 -host node07 -port 5000 -wait Executed plan 10, waiting for completion... Plan 10 ended successfully kv-> pool join -name BostonPool -sn sn4 Added Storage Node(s) [sn4] to pool BostonPool kv-> pool join -name BostonPool -sn sn5 Added Storage Node(s) [sn5] to pool BostonPool kv-> pool join -name BostonPool -sn sn6 Added Storage Node(s) [sn6] to pool BostonPool kv-> pool join -name BostonPool -sn sn7 Added Storage Node(s) [sn7] to pool BostonPool kv-> topology clone -current -name newTopo Created newTopo kv-> topology redistribute -name newTopo -pool BostonPool Redistributed: newTopo kv-> plan deploy-topology -name newTopo -wait Executed plan 11, waiting for completion... Plan 11 ended successfully
redistributeコマンドは追加された容量を使用して、新規シャードを作成し、それらのノードにパーティションを移行します。新規シャードの数が現行のシャード数を上回っていないと、コマンドは失敗します。
redistributeコマンドは、混合シャード・ストアに対しては発行しないでください。混合シャード・ストアには、異なるソフトウェア・バージョンのOracle NoSQL Databaseで運用されているレプリケーション・ノードを持つシャードがあります。
トポロジ候補を再配布する際にシステムは次のステップを実行します。
新規レプリケーション・ノードが各シャードに対して作成され、前述したトポロジ・ルールに従ってストレージ・ノードに割り当てられます。引き続きトポロジ・ルールに従うと同時に使用可能リソースを最大限に活用するため、既存のレプリケーション・ノードを別のストレージ・ノードに移動することが必要になる場合があります。
パーティションはすべてのシャード間で均等に配布されます。過密状態になったシャード内のパーティションは、最もパーティションが少ないシャードに移動されます。
移動されるパーティションは指定しません。
読取りスループットと可用性を向上させるため、topology change-repfactorコマンドを使用してレプリケーション係数を増加し、データのコピーをさらに作成できます。必要なノード数を得るために、レプリケーション・ノードがさらに各シャードに追加されます。新規のレプリケーション・ノードはシャード内の既存ノードから移入されます。ゾーン内のシャードはすべて同じレプリケーション係数を備えるため、シャードが多数存在する場合は、このコマンドで多数の新規ストレージ・ノードが成功することが求められます。
各自のレプリケーション係数およびその関連性の識別方法の詳細は、「レプリケーション係数」を参照してください。
次の例では、ストアのレプリケーション係数を4に増加します。管理者は新規ストレージ・ノードをデプロイし、それをストレージ・ノード・プールに追加します。次に既存のトポロジがクローニングされ、新規レプリケーション係数の4を使用するために変換されます。
kv-> plan deploy-sn -zn zn1 -host node08 -port 5000 -wait Executed plan 12, waiting for completion... Plan 12 ended successfully kv-> pool join -name BostonPool -sn sn8 Added Storage Node(s) [sn8] to pool BostonPool kv-> topology clone -current -name repTopo Created repTopo kv-> topology change-repfactor -name repTopo -pool BostonPool -rf 4 -zn zn1 Changed replication factor in repTopo kv-> plan deploy-topology -name repTopo -wait Executed plan 13, waiting for completion... Plan 13 ended successfully
change-repfactorコマンドは次の場合に失敗します。
新規レプリケーション係数が、現行レプリケーション係数と同じかそれ以下の場合。
ストレージ・ノード・プールで指定されたストレージ・ノードに、必要な新規レプリケーション・ノードをホストするための十分な容量がない場合。
トポロジは、「ストアの構成の決定」に説明されているルールに従う必要があります。ストアの物理的特性に対する変更は、ストアの現行トポロジがそのルールに違反する状態を引き起こすことがあります。たとえば、パフォーマンス・チューニング後に、ストレージ・ノードの容量を減らすような場合があります。そのノードがすでに最大許容数のレプリケーション・ノードをホストしている場合は、容量を減らすとストアが容量ルールに準拠していない状態になります。
非準拠の構成は、topology rebalanceコマンドを使用して均衡化できます。このコマンドにはトポロジ候補名とストレージ・ノード・プール名が必要です。
次の例では、トポロジ・ルールの違反についてrepTopoというトポロジ候補を調べます。この調査の結果、改良が必要ない場合はトポロジ候補は変更されません。ただし改良が必要な場合は、違反を修正するため、BostonPoolプール内のストレージ・ノードを使用して、topology rebalanceコマンドがレプリケーション・ノードを移動または作成します。コマンドはどの状況下でも追加シャードを作成しません。
kv-> topology rebalance -name repTopo -pool BostonPool Rebalanced: repTopo
数が不足しているストレージ・ノードがある場合、topology rebalanceコマンドはすべての違反を修正することができません。このようなケースでは、コマンドは可能なかぎり修正を行い、残りの問題についての警告を出します。
トポロジ候補またはデプロイ済トポロジの詳細は、topology viewコマンドを使用して表示できます。コマンドはトポロジ名を引数として使用します。topology viewコマンドによって、指定されたトポロジのストア名、パーティション数、シャード、レプリケーション係数、ホスト名および容量をすべて一度に表示できます。
次に例を示します。
kv-> topology view -name repTopo
store=mystore numPartitions=300 sequence=315
zn: id=zn1 name=Boston repFactor=4 type=PRIMARY
sn=[sn1] zn:[id=zn1 name=Boston] node01:5000 capacity=1
[rg1-rn1]
sn=[sn2] zn:[id=zn1 name=Boston] node02:5000 capacity=1
[rg1-rn2]
sn=[sn3] zn:[id=zn1 name=Boston] node03:5000 capacity=1
[rg1-rn3]
sn=[sn4] zn:[id=zn1 name=Boston] node04:5000 capacity=1
[rg1-rn4]
sn=[sn5] zn:[id=zn1 name=Boston] node05:5000 capacity=1
sn=[sn6] zn:[id=zn1 name=Boston] node06:5000 capacity=1
sn=[sn7] zn:[id=zn1 name=Boston] node07:5000 capacity=1
sn=[sn8] zn:[id=zn1 name=Boston] node08:5000 capacity=1
shard=[rg1] num partitions=300
[rg1-rn1] sn=sn1
[rg1-rn2] sn=sn2
[rg1-rn3] sn=sn3
[rg1-rn4] sn=sn4
トポロジ候補またはデプロイ済トポロジは、topology validateコマンドを使用して検証できます。topology validateコマンドはトポロジ名を引数として使用します。トポロジが指定されていない場合、現行トポロジが検証されます。検証では、「ストアの構成の決定」で説明されているトポロジ・ルールにトポロジ候補が準拠していることが確認されます。検証では"violations"と"notes"が生成されます。
violationsは問題を引き起こす可能性があり、調査が必要です。
notesは情報的で、問題になる可能性はあるが予測も可能であるという、構成上の目立つ差異を示します。
次に例を示します。
kv-> topology validate -name repTopo Validation for topology candidate "repTopo": 4 warnings. sn7 has 0 RepNodes and is under its capacity limit of 1 sn8 has 0 RepNodes and is under its capacity limit of 1 sn5 has 0 RepNodes and is under its capacity limit of 1 sn6 has 0 RepNodes and is under its capacity limit of 1
起動トポロジに関連して、指定されたトポロジ候補に対して行われる変更は、プレビューする必要があります。topology previewコマンドを使用してこの操作を実行します。このコマンドでは次の引数を使用します。
名前
トポロジを識別するための文字列。
start <from topology>
-startトポロジ名が指定されていない場合、現行トポロジが使用されます。このコマンドは、新規トポロジをデプロイする前に使用する必要があります。
次に例を示します。
kv-> topology clone -current -name redTopo Created redTopo kv-> topology redistribute -name redTopo -pool BostonPool Redistributed: redTopo kv-> topology preview -name redTopo Topology transformation from current deployed topology to redTopo: Create 1 shard Create 4 RNs Migrate 150 partitions shard rg2 4 new RNs: rg2-rn1 rg2-rn2 rg2-rn3 rg2-rn4 150 partition migrations kv-> topology validate -name redTopo Validation for topology candidate "redTopo": No problems
申し分のないトポロジ候補とともに、ストアを新規トポロジに移行するプランを生成および実行するために管理サービスを使用できます。
トポロジ候補は、plan deploy-topologyコマンドを使用してデプロイできます。このコマンドはトポロジ名を引数として使用します。
プランが実行中の間、プランの進行状況を監視できます。いくつかのオプションがあります。
プランは中断してから再試行したり、取り消すことができます。
その他の限られたプランは、継続した問題または障害に対処するため、変換プランの進行中に実行される場合があります。
デフォルトでplan deploy-topologyコマンドは、トポロジ・ルールの新たな違反が持ち込まれる場合は、トポロジ候補のデプロイを拒否します。この動作は、そのコマンドで-forceオプション・プラン・フラグを使用することでオーバーライドできます。
次に例を示します。
kv-> show topology
store=mystore numPartitions=300 sequence=315
zn: id=zn1 name=Boston repFactor=4 type=PRIMARY
sn=[sn1] zn=[id=zn1 name=Boston] node01:5000 capacity=1 RUNNING
[rg1-rn1] RUNNING
No performance info available
sn=[sn2] zn=[id=zn1 name=Boston] node02:5000 capacity=1 RUNNING
[rg1-rn2] RUNNING
No performance info available
sn=[sn3] zn=[id=zn1 name=Boston] node03:5000 capacity=1 RUNNING
[rg1-rn3] RUNNING
No performance info available
sn=[sn4] zn=[id=zn1 name=Boston] node04:5000 capacity=1 RUNNING
[rg1-rn4] RUNNING
No performance info available
sn=[sn5] zn=[id=zn1 name=Boston] node05:5000 capacity=1
sn=[sn6] zn=[id=zn1 name=Boston] node06:5000 capacity=1
sn=[sn7] zn=[id=zn1 name=Boston] node07:5000 capacity=1
sn=[sn8] zn=[id=zn1 name=Boston] node08:5000 capacity=1
shard=[rg1] num partitions=300
[rg1-rn1] sn=sn1
[rg1-rn2] sn=sn2
[rg1-rn3] sn=sn3
[rg1-rn4] sn=sn4
kv-> plan deploy-topology -name redTopo -wait
Executed plan 14, waiting for completion...
Plan 14 ended successfully
kv-> show topology
store=mystore numPartitions=300 sequence=470
zn: id=zn1 name=Boston repFactor=4 type=PRIMARY
sn=[sn1] zn:[id=zn1 name=Boston] node01:5000 capacity=1 RUNNING
[rg1-rn1] RUNNING
No performance info available
sn=[sn2] zn:[id=zn1 name=Boston] node02:5000 capacity=1 RUNNING
[rg1-rn2] RUNNING
No performance info available
sn=[sn3] zn:[id=zn1 name=Boston] node03:5000 capacity=1 RUNNING
[rg1-rn3] RUNNING
No performance info available
sn=[sn4] zn:[id=zn1 name=Boston] node04:5000 capacity=1 RUNNING
[rg1-rn4] RUNNING
No performance info available
sn=[sn5] zn:[id=zn1 name=Boston] node05:5000 capacity=1 RUNNING
[rg2-rn1] RUNNING
No performance info available
sn=[sn6] zn:[id=zn1 name=Boston] node06:5000 capacity=1 RUNNING
[rg2-rn2] RUNNING
No performance info available
sn=[sn7] zn:[id=zn1 name=Boston] node07:5000 capacity=1 RUNNING
[rg2-rn3] RUNNING
No performance info available
sn=[sn8] zn:[id=zn1 name=Boston] node08:5000 capacity=1 RUNNING
[rg2-rn4] RUNNING
No performance info available
shard=[rg1] num partitions=150
[rg1-rn1] sn=sn1
[rg1-rn2] sn=sn2
[rg1-rn3] sn=sn3
[rg1-rn4] sn=sn4
shard=[rg2] num partitions=150
[rg2-rn1] sn=sn5
[rg2-rn2] sn=sn6
[rg2-rn3] sn=sn7
[rg2-rn4] sn=sn8
ストアの現行トポロジは、verifyコマンドを使用して検証できます。verifyコマンドでは、現行のデプロイ済トポロジが、「ストアの構成の決定」で説明されているトポロジ・ルールに準拠していることが確認されます。
新規トポロジを調べてそれが満足できるかどうかを判断し、満足できない場合はさらに変換を適用するか、別のパラメータで最初からやり直します。
次に例を示します。
kv-> verify configuration
Verify: starting verification of mystore based upon topology sequence #470
300 partitions and 8 storage nodes.
Version: 12.1.3.0.0 Time: 2014-01-07 17:34:23 UTC
See localhost:KVROOT/mystore/log/mystore_{0..N}.log
for progress messages
Verify: == checking storage node sn1 ==
Verify: Storage Node [sn1] on node01:5000
Zone: [name=Boston id=zn1 type=PRIMARY] Status: RUNNING
Ver: 12cR1.3.0.0 2013-12-18 06:35:02 UTC Build id: 8e70b50c0b0e
Verify: Admin [admin1] Status: RUNNING
Verify: Rep Node [rg1-rn1] Status: RUNNING,MASTER at sequence ....
Verify: == checking storage node sn2 ==
Verify: Storage Node [sn2] on node02:5000
Zone: [name=Boston id=zn1 type=PRIMARY] Status: RUNNING
Ver: 12cR1.3.0.0 2013-12-18 06:35:02 UTC Build id: 8e70b50c0b0e
Verify: Rep Node [rg1-rn2] Status: RUNNING,REPLICA at sequence ....
Verify: == checking storage node sn3 ==
Verify: Storage Node [sn3] on node03:5000
Zone: [name=Boston id=zn1 type=PRIMARY] Status: RUNNING
Ver: 12cR1.3.0.0 2013-12-18 06:35:02 UTC Build id: 8e70b50c0b0e
Verify: Rep Node [rg1-rn3] Status: RUNNING,REPLICA at sequence ....
Verify: == checking storage node sn4 ==
Verify: Storage Node [sn4] on node04:5000
Zone: [name=Boston id=zn1 type=PRIMARY] Status: RUNNING
Ver: 12cR1.3.0.0 2013-12-18 06:35:02 UTC Build id: 8e70b50c0b0e
Verify: Rep Node [rg1-rn4] Status: RUNNING,REPLICA at sequence ....
Verify: == checking storage node sn5 ==
Verify: Storage Node [sn5] on node05:5000
Zone: [name=Boston id=zn1 type=PRIMARY] Status: RUNNING
Ver: 12cR1.3.0.0 2013-12-18 06:35:02 UTC Build id: 8e70b50c0b0e
Verify: Rep Node [rg2-rn1] Status: RUNNING,MASTER at sequence ....
Verify: == checking storage node sn6 ==
Verify: Storage Node [sn6] on node06:5000
Zone: [name=Boston id=zn1 type=PRIMARY] Status: RUNNING
Ver: 12cR1.3.0.0 2013-12-18 06:35:02 UTC Build id: 8e70b50c0b0e
Verify: Rep Node [rg2-rn2] Status: RUNNING,REPLICA at sequence ....
Verify: == checking storage node sn7 ==
Verify: Storage Node [sn7] on node07:5000
Zone: [name=Boston id=zn1 type=PRIMARY] Status: RUNNING
Ver: 12cR1.3.0.0 2013-12-18 06:35:02 UTC Build id: 8e70b50c0b0e
Verify: Rep Node [rg2-rn3] Status: RUNNING,REPLICA at sequence ....
Verify: == checking storage node sn8 ==
Verify: Storage Node [sn8] on node08:5000
Zone: [name=Boston id=zn1 type=PRIMARY] Status: RUNNING
Ver: 12cR1.3.0.0 2013-12-18 06:35:02 UTC Build id: 8e70b50c0b0e
Verify: Rep Node [rg2-rn4] Status: RUNNING,REPLICA at sequence ....
Verification complete, no violations.