ライブラリ・バージョン12.1.3.0

第5章 ストアの構成の決定
前 |  | 次

## 第5章 ストアの構成の決定

ストアは多数のストレージ・ノードで構成されます。各ストレージ・ノードは1つ以上のレプリケーション・ノードを、その容量値に基づいてホストできます。`topology`という用語はレプリケーション・ノードのディストリビューションの説明に使用されます。トポロジは、使用可能なストレージ・ノードの数および容量、ストア内のパーティションの数や、ストアのゾーンのレプリケーション係数から導出されます。トポロジ・レイアウトも、ストアの可用性を最大化するための一連のルールによって管理されます。

すべてのトポロジが次のルールに従う必要があります。

1. 同じシャードからのレプリケーション・ノードはそれぞれ異なるストレージ・ノードに配置する必要があります。このルールによって、1つのストレージ・ノードの障害が、1つのシャードに対する複数の場所の障害を引き起こすことが回避されます。

2. ストレージ・ノードに割り当てられたレプリケーション・ノードの数は、ストレージ・ノードの容量と同じかそれ以下にする必要があります。

3. 1つのゾーンには各シャードからの1つ以上のレプリケーション・ノードが必要です。

ストアの初期構成、またはトポロジは、ストアの作成時に設定されます。後々、ストアのトポロジの変更が必要になる場合があります。この変更の理由はいくつかあります。

1. ストレージ・ノードの置換またはアップグレードが必要です。

2. 読取りスループットを増やす必要があります。これを実現するには、レプリケーション係数を増やし、読取り専用リクエストのサービスに使用できるストアのデータのコピーをさらに作成します。

3. 書込みスループットを増やす必要があります。各シャードには1つのマスター・ノードがあるため、ストア内データを多数のシャードに対して配布すると、書込み操作を実行できるノードがさらにストアに提供されます。

使用可能なストレージ・ノードの数または容量、もしくはゾーンのレプリケーション係数を変更することで、ストアの構成を変更します。ある構成から別の構成に変更するには、新規の初期トポロジを作成するか、既存のトポロジに`clone`を行ってからそれをターゲット・トポロジに変更します。次に、このターゲット・トポロジをデプロイします。

### 注意

ターゲット・トポロジのデプロイは、実行に時間がかかる可能性があり、必要な時間は移動対象のデータ量に比例します。デプロイの間、システムはトポロジを各ステップで更新します。このため、ユーザーによって明示的に作成されなかった中間トポロジは、ストアでは通過されます。

この章では構成の、つまりトポロジ的な変更がストアでどのように行われるかを説明します。

### 注意

スナップショットの作成中は構成を変更しないでください。その逆も同様です。構成を変更する場合、まずスナップショットをバックアップとして作成してから変更を行うのが安全な方法です。スナップショットの作成の詳細は、「スナップショットの作成」を参照してください。

## ストアのトポロジを変更するステップ

トポロジを変更する際は、次のステップを実行する必要があります。

1. トポロジ候補の作成

2. トポロジ候補の変換

3. トポロジ候補の表示

4. トポロジ候補の検証

5. トポロジ候補のプレビュー

6. トポロジ候補のデプロイ

7. ストアの現行トポロジの検証

新規トポロジの作成は反復的なプロセスである可能性があります。変更をデプロイする前に、各種のオプションを試して何が最適かを確認する場合があります。最後に、トポロジ候補を調べてそれが満足できるかどうかを判断します。満足できない場合は、さらに変換を適用するか、別のパラメータで最初からやり直します。トポロジ候補を表示および検証して、それが適切かどうかを判断できます。

可能な変換としてはデータの再配布、レプリケーション係数の増加、および再均衡化があります。この詳細は「トポロジ候補の変換」で説明します。

次の各項で、管理コマンドライン・インタフェースを使用してストアの構成を変更するプロセスについて順を追って説明します。

### トポロジ候補の作成

レプリケーション・ノードが存在する前に、初期デプロイのための最初のトポロジ候補を作成するには、`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で運用されているレプリケーション・ノードを持つシャードがあります。

トポロジ候補を再配布する際にシステムは次のステップを実行します。

1. 新規レプリケーション・ノードが各シャードに対して作成され、前述したトポロジ・ルールに従ってストレージ・ノードに割り当てられます。引き続きトポロジ・ルールに従うと同時に使用可能リソースを最大限に活用するため、既存のレプリケーション・ノードを別のストレージ・ノードに移動することが必要になる場合があります。

2. パーティションはすべてのシャード間で均等に配布されます。過密状態になったシャード内のパーティションは、最もパーティションが少ないシャードに移動されます。

3. 移動されるパーティションは指定しません。

#### レプリケーション係数の増加

読取りスループットと可用性を向上させるため、`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コマンドは次の場合に失敗します。

1. 新規レプリケーション係数が、現行レプリケーション係数と同じかそれ以下の場合。

2. ストレージ・ノード・プールで指定されたストレージ・ノードに、必要な新規レプリケーション・ノードをホストするための十分な容量がない場合。

#### 非コンプライアンス・トポロジの均衡化

トポロジは、「ストアの構成の決定」に説明されているルールに従う必要があります。ストアの物理的特性に対する変更は、ストアの現行トポロジがそのルールに違反する状態を引き起こすことがあります。たとえば、パフォーマンス・チューニング後に、ストレージ・ノードの容量を減らすような場合があります。そのノードがすでに最大許容数のレプリケーション・ノードをホストしている場合は、容量を減らすとストアが容量ルールに準拠していない状態になります。

非準拠の構成は、`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.

前 |  | 次
トラブルシューティング | ホーム | 第6章 既存のOracle NoSQL Databaseデプロイメントのアップグレード