1. 管理者ガイド
  2. ストアの構成の決定
  3. ストアのトポロジを変更するステップ

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

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

  1. トポロジ候補の作成

  2. トポロジ候補の変換

  3. トポロジ候補の表示

  4. トポロジ候補の検証

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

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

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

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

ストアを拡張するために可能な変換には、データの再配布、レプリケーション係数の増加および再均衡化があります。この詳細はトポロジ候補の変換で説明します。

ストレージ・ノードを削除することによって、現在のトポロジを縮小することもできます。トポロジの縮小を参照してください。

次の各項では、管理CLIを使用してストアの構成を変更するプロセスについて説明します。

トポロジ候補の作成

レプリケーション・ノードが存在する前に、初期デプロイのための最初のトポロジ候補を作成するには、topology createコマンドを使用します。topology createコマンドには、トポロジ名、プール名およびパーティション数が引数として必要です。

ノート:

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

次に例を示します。 

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 cloneコマンドのこのバリアントでは、次の引数を使用します。

  • -current

    現在デプロイされているトポロジをソースとして使用して、引数に名前が不要であることを指定します。

  • -name <to topology>

    トポロジ・クローンの名前。

次に例を示します。 

kv-> topology clone -current -name ClonedTopo
Created ClonedTopo

トポロジ候補の変換

最初にストアをデプロイした後は、現在のトポロジとは異なる別のトポロジ候補をデプロイすることによって、ストアを変更できます。このターゲット・トポロジは、次のコマンドを使用してトポロジ候補を変換し、ストアを拡張することによって生成されます。

  • topology redistribute

  • rebalance
  • change-repfactor

または、topology contractコマンドを使用して、ターゲット・トポロジ候補を縮小できます。

変換は、前の項で説明したトポロジ・ルールに従います。

topology rebalance, redistribute or change-repfactorコマンドは、追加的な、または変更済のストレージ・ノードが使用可能な場合、トポロジ候補への変更のみを実行できます。レプリケーション・ノードおよびパーティションの再調整には新規リソースが使用されるため、トポロジはトポロジ・ルールに従い、ストアでは読取りまたは書込みスループットが向上します。

ストアを拡張または縮小するシナリオを次に示します。

データ配布の増加

topology redistributeコマンドを使用して、データ配布を増加させ、書込みスループットを向上させます。redistributeコマンドが機能するのは、新規シャードに対して新規レプリケーション・ノードを作成できるように新規ストレージ・ノードが追加された場合のみとなります。新規シャードについては、システムによって新規シャード全体にパーティションが分散されるため、書込み操作を処理するレプリケーション・ノードが増加します。

次の例では、一連のストレージ・ノード(node04 — node07)を追加し、これらのノードにデータを再配布する処理を示します。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コマンドは、BostonPoolに追加した新規ストレージ・ノードの容量を組み込み、新規シャードを作成します。このコマンドでは、パーティションも新規シャードに移行されます。新規シャード数が現行シャード数以下の場合、topology redistributeコマンドは失敗します。

ノート:

混合シャードを含むストアに対してtopology redistributeコマンドを実行しないでください。混合シャード・ストアには、異なるソフトウェア・バージョンのOracle NoSQL Databaseで運用されているレプリケーション・ノードを持つシャードがあります。

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

  1. topology redistributeコマンドは、各シャードに対して新規レプリケーション・ノード(RN)を作成し、トポロジ・ルールに従ってストレージ・ノードにノードを割り当てます。新しいRNを作成する際、topologyコマンドは、トポロジ・ルールに準拠しながら使用可能なリソースを最適に使用するために、既存のRNを別のストレージ・ノードに移動する場合があります。

  2. topologyコマンドは、すべてのシャード間でパーティションを均等に分散します。移入されたシャード内のパーティションは、最もパーティションが少ないシャードに移動されます。

    コマンドで移動するパーティションを指定することはできません。

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

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

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

トポロジは、「ストアの構成の決定」に説明されているルールに従う必要があります。ストアの物理的特性に対する変更は、現在のストア・トポロジがそのルールに違反する原因となることがあります。たとえば、パフォーマンス・チューニング後に、ストレージ・ノード(SN)の容量を減らす必要があります。そのSNが最大許容数のレプリケーション・ノードをすでにホストしている場合、容量を減らすことで、ストアが容量ルールに準拠していない状態になります。topology rebalanceコマンドを使用する前にSNの容量を減らすには、ストレージ・ノードの容量についてchange-parametersコマンドを使用します。plan change-parametersを参照してください。

非準拠の構成は、topology rebalanceコマンドを使用して均衡化できます。このコマンドにはトポロジ候補名とストレージ・ノード・プール名が必要です。

トポロジを再均衡化する前に、topology validateコマンドを使用して、repTopoプランのトポロジ・ルールに対する違反を確認します。 

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

この場合、警告が予想されますが、トポロジの改善は必要ありません。ただし改良が必要な場合は、違反を修正するため、BostonPoolプール内のストレージ・ノードを使用して、topology rebalanceコマンドがレプリケーション・ノードを移動または作成します。このコマンドでは、どのような状況においても追加シャードは作成されません。シャードの容量を参照してください。 

kv-> topology rebalance -name repTopo -pool BostonPool
Rebalanced: repTopo

ストレージ・ノードが十分にないか、または割り当てられているストレージ・ディレクトリ・サイズが十分にない場合、topology rebalanceコマンドではすべての違反を修正できないことがあります。このようなケースでは、コマンドは可能なかぎり修正を行い、残りの問題についての警告を出します。

トポロジの縮小

topology contractコマンドを使用して、トポロジを縮小できます。このコマンドにはトポロジ候補名とストレージ・ノード・プール名が必要です。このコマンドでは、ストレージ・ノードの削除がサポートされており、レプリケーション・ノードの再配置、シャードの削除およびパーティションの移行によってトポロジを縮小します。

ノート:

レプリケーション係数の削減は、現在、サポートされていません。また、管理の再配置はサポートされていません。管理が縮小されるストレージ・ノード上に存在する場合、縮小操作は失敗します。

次の例では、3つのストレージ・ノード(sn2、sn5およびsn8)を削除して、トポロジを縮小します。まず、pool clone commandを使用してプールをクローニングし、pool leave commandを使用してクローニングされたプールからストレージ・ノードを削除します。その後、トポロジは縮小されたプールを使用して、縮小およびデプロイされます。最後に、plan remove-snコマンドを使用して、ストレージ・ノードを削除できます。このコマンドを実行すると、ストレージ・ノードは削除される前に自動的に停止します。 

# Clone the existing Storage Node pool as to be contractedPool
kv-> pool clone -name contractedPool -from AllStorageNodes
Cloned pool contractedPool
kv-> pool leave -name contractedPool -sn sn2
Removed Storage Node(s) [sn2] from pool contractedPool
kv-> pool leave -name contractedPool -sn sn5
Removed Storage Node(s) [sn5] from pool contractedPool
kv-> pool leave -name contractedPool -sn sn8
Removed Storage Node(s) [sn8] from pool contractedPool

# Generate a contracted candidate topology
kv-> topology clone -current -name contractedTopology
Created contractedTopology
kv-> topology contract -name contractedTopology -pool contractedPool
Contracted: contractedTopology

# Deploy the contracted candidate topology as the real topology.
kv-> plan deploy-topology -name contractedTopology -wait
Executed plan 16, waiting for completion...
Plan 16 ended successfully

# Remove to-be-deleted SNs
kv-> plan remove-sn -sn sn2 -wait
Executed plan 17, waiting for completion...
Plan 17 ended successfully
kv-> plan remove-sn -sn sn5 -wait
Executed plan 18, waiting for completion...
Plan 18 ended successfully
kv-> plan remove-sn -sn sn8 -wait
Executed plan 19, waiting for completion...
Plan 19 ended successfully

トポロジ候補の表示

トポロジ候補またはデプロイ済トポロジの詳細は、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コマンドを使用してこの操作を実行します。このコマンドでは次の引数を使用します。

  • name

    トポロジを識別するための文字列。

  • 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プラン・フラグを使用してオーバーライドできます。–forceプランは慎重に使用してください。トポロジ・ルール違反が発生すると、多くの悪影響を及ぼすことがあります。

次の例は、プラン・デプロイメント前後のトポロジの違いを示します。最初のshow topology出力には、ゾーン1で実行される4つのストレージ・ノードがリストされ、1つのシャード(rg1)に300個のパーティションが格納されます。ストレージ・ノードsn5 —sn8が使用可能です。

プランのデプロイ後、show topology出力には、実行中としてストレージ・ノードsn5 — sn8がリストされます。別のシャードが存在し(rg2)、パーティションが2つのシャード間で分割され、それぞれに150のパーティションがあります。 

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 store mystore based upon
    topology sequence #470
300 partitions and 8 storage nodes
Time: 2018-09-28 06:57:10 UTC   Version: 18.3.2
See localhost:KVROOT/mystore/log/mystore_{0..N}.log for progress messages
Verify: Shard Status: healthy:2 writable-degraded:0 read-only:0 offline:0
Verify: Admin Status: healthy
Verify: Zone [name=Boston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
    RN Status: online:8 offline:0 maxDelayMillis:0 maxCatchupTimeSecs:0
Verify: == checking storage node sn1 ==
Verify: Storage Node [sn1] on node01:5000
    Zone: [name=Boston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
    Status: RUNNING
    Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
Verify:         Admin [admin1]          Status: RUNNING,MASTER
Verify:         Rep Node [rg1-rn1]      Status: RUNNING,MASTER ...
Verify: == checking storage node sn2 ==
Verify: Storage Node [sn2] on node02:5000
    Zone: [name=Boston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
    Status: RUNNING
    Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
Verify:         Rep Node [rg1-rn2]      Status: RUNNING,REPLICA ...
Verify: == checking storage node sn3 ==
Verify: Storage Node [sn3] on node03:5000
    Zone: [name=Boston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
    Status: RUNNING
    Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
Verify:         Rep Node [rg1-rn3]      Status: RUNNING,REPLICA ...
Verify: == checking storage node sn4 ==
Verify: Storage Node [sn4] on node04:5000
    Zone: [name=Boston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
    Status: RUNNING
    Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
Verify:         Rep Node [rg1-rn4]      Status: RUNNING,REPLICA ...
Verify: == checking storage node sn5 ==
Verify: Storage Node [sn5] on node05:5000
    Zone: [name=Boston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
    Status: RUNNING
    Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
Verify:         Rep Node [rg2-rn1]      Status: RUNNING,MASTER ...
Verify: == checking storage node sn6 ==
Verify: Storage Node [sn6] on node06:5000
    Zone: [name=Boston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
    Status: RUNNING
    Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
Verify:         Rep Node [rg2-rn2]      Status: RUNNING,REPLICA ...
Verify: == checking storage node sn7 ==
Verify: Storage Node [sn7] on node07:5000
    Zone: [name=Boston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
    Status: RUNNING
    Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
Verify:         Rep Node [rg2-rn3]      Status: RUNNING,REPLICA ...
Verify: == checking storage node sn8 ==
Verify: Storage Node [sn8] on node08:5000
    Zone: [name=Boston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
    Status: RUNNING
    Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
Verify:         Rep Node [rg2-rn4]      Status: RUNNING,REPLICA ...
Verification complete, no violations.