1. データ・ストアのモニタリング
  2. ストアの監視
  3. ハードウェア・モニタリング
  4. サーバー

サーバー

ディスクの障害ほど一般的ではありませんが、特定のKVStoreのデプロイメントを構成するサービスのホストとなっているマシン(SN)のいずれかを管理者が交換する必要に迫られるのは珍しいことではありません。マシン全体の交換が発生する一般的なシナリオが2つあります。1つ目は、1つ以上のハードウェア・コンポーネントで障害が発生した場合です。障害が発生したコンポーネントを交換するより、単にマシン全体を交換したほうが便利で費用対効果に優れています。2つ目は、問題なく稼働しているマシンをより大型で堅牢なマシンにアップグレードする場合です。たとえば、ディスクの容量が大きく、パフォーマンス特性に優れたマシンです。この項で示す手順は、既存のマシンと交換する新規マシンの準備を整えるためのステップと、既存のマシンを廃棄するためのステップについて説明することを目的としています。

サーバー障害の検出およびNoSQLログ・イベントとの関連付け

Oracle NoSQL Databaseなどの分散では一般的に、ネットワークの停止とマシンの障害を区別することが困難です。レプリケーション・ノードへ到達できない場合、それがNoSQL DatabaseのHAコンポーネントによって検出され、イベントとして管理ログに記録されます。ただし、このログ・イベントをgrep検索すると、誤検出が生成されます。このため、JMXなどのシステム・モニタリング・パッケージを使用して、マシン/サーバー障害を検出することをお薦めします。

ノート:

ログ・ファイルが圧縮されている場合は、zgrepコマンドを使用して圧縮ログ・ファイルを検索できます。

サーバー障害の解決

2つの交換手順を次に示します。どちらの手順でも実質的に同じ結果がもたらされ、1つ以上のネットワーク・リストア・プロセスが実行されます(次を参照)。

最初に示す手順では、古いマシンをすべての利害関係者にとって元のマシンとまったく変わらないマシンと交換します。つまり、新規マシンは同じホスト名、IPアドレス、ポートおよびSN IDを持ちます。これに比べて2つ目の手順では、古いマシンをストアのトポロジから削除し、ホスト名、IPアドレス、SN idが異なる別のマシンのように見えるマシンと交換しますが、その動作は元のマシンと同じです。つまり、新規マシンは元のマシンと同じサービスを実行し、まったく同じデータを管理します。それが異なるネットワークおよびSN idで行われるだけです。したがって、最初のケースはハードウェアのみの交換であると考えることができます。つまり、ストアから見ると、元のSNが一時的に停止し、その後再開されたことになります。新しいハードウェアは、ストアのトポロジに反映されません。もう一方のケースでは、元のSNが削除され、異なるSNが元の役割を引き継ぎます。ストアの内容および動作は変わりませんが、ハードウェアの変更はストアの新しいトポロジに反映されます。

ストレージ・ノードを交換する際にどの手順を使用するかを決定する場合、その決定はストア管理者の裁量に委ねられます。管理者によっては、常に1つの手順のみを使用し、他の手順は使用しません。また、管理者が優先条件に基づいてポリシーを確立する場合もあります。たとえば、ハードウェアで障害が発生したためSNの交換を実行する必要があるときには1つ目の手順を使用し、問題なく稼働しているハードウェアをより新しくて優れたハードウェアにアップグレードするときには2つ目の手順を使用するというポリシーを想像してみてください。1つ目のケースの場合、障害が発生したSNは交換プロセスの間停止し、使用できません。2つ目のケースの場合、新規マシンの移行準備を整えている間、交換対象のマシンを稼働させて使用可能な状態にしておくことができます。その後、古いマシンを停止し、トポロジから除外できます。

用語の確認

Oracle NoSQL Databaseスタート・ガイドおよびOracle NoSQL Database管理者ガイドで導入された用語をいくつか確認しておくと役立ちます。これらのドキュメントから、KVStoreのプロセスを実行する物理マシンがストレージ・ノード(SN)と呼ばれていることを思い出してください。典型的なKVStoreデプロイメントは一般に、Oracle NoSQL Database KVStoreから提供されるプロセスおよびソフトウェア・サービスを実行する数多くのマシン(つまり数多くのSN)で構成されています。また、KVStoreソフトウェアを最初に特定のSNマシンで起動すると、「ストレージ・ノード・エージェント」(SNA)と呼ばれるプロセスが起動されることも思い出してください。次に、SNAを起動した後、KVStore管理CLIを使用してストアを構成し、「トポロジ」をデプロイします。その結果、SNAは「レプリケーション・ノード」と呼ばれる1つ以上の「サービス」(RNサービス)のライフサイクルを実行および管理するようになります。最後に、RNサービスを起動および管理するだけでなく、SNAはオプションで(構成に応じて)「管理」サービスと呼ばれる別のサービス・タイプも起動および管理します。

特定のKVStoreデプロイメントを構成するマシンと、ストアをインストールしてデプロイする際に各マシンで最初に起動されたSNAプロセスとを1対1で対応付けるため、このノートも含めOracle NoSQL Databaseドキュメントでは、SNAを実行しているマシンまたはSNAプロセス自体を参照する場合に「ストレージ・ノード」、「SN」、または「SNx」 (xは正の整数)という用語を区別なく使用していることがよくあります。用語を使用する特定のディスカッションの文脈から、概念が意図するものを明確にする必要があります。たとえば、マシンの障害やリカバリなどハードウェアの問題に関するディスカッションの一環としてSN3またはsn3という用語を使用した場合、その用語は、id値3が割り当てられ、ストアのトポロジで文字列sn3で識別されるSNAプロセスを実行中の物理ホスト・マシンを指します。その他の文脈、たとえば、ストアのソフトウェアの動作について説明している場合、SN3やsn3という用語は、関連付けられたマシンで実行中の実際のSNAプロセスを指します。

次のディスカッションには直接関係しませんが、万全を期すためだけでなく、どのSN交換手順を使用するかを決定しようとするときにその意味するところを理解しておくと役に立つことがあるため、次の用語を紹介します。

まず、Oracle NoSQL Databaseドキュメントから、各SNAによって起動および管理されるRNサービスが、ストアのトポロジで、それぞれのサービス識別番号(正の整数)と、そのサービスがメンバーとなっているレプリケーション・グループ(シャード)の識別番号とで表されることを思い出してください。たとえば、ある特定のストアのトポロジが特定のRNサービスを文字列rg3-rn2で参照しているとします。これは、idが2に等しくかつid 3のレプリケーション・グループ(シャード)のメンバーであるRNサービスを表します。特定のKVStoreクラスタの一部として動作している特定のSNマシンの容量は、そのSNホストにデプロイされたSNAプロセスによって開始および管理されるRNサービスの数です。したがって、特定のSNの容量が1の場合、1つのRNサービスのみがそのSNによって起動および管理されます。一方、たとえば容量が3の場合、3つのRNサービスがそのSNによって起動および管理され、各RNは通常、異なるレプリケーション・グループ(共有)に属します。

特定のKVStoreにデプロイされたSNホスト・マシンおよび常駐のSNAプロセスについて理解する必要がある概念として、「ゾーン」の概念と、ストレージ・ノードの「プール」の概念の2つがあります。どちらの概念も、ストアのSNをグループにまとめるためのメカニズムに対応しています。これを受けて、2つの概念の違いを次に示します。

デプロイメントでKVStoreを構成する際、ストレージ・ノードをデプロイする前に、ストアに対して少なくとも1つの「ゾーン」をデプロイする必要があります。次に、各SNAプロセスをデプロイする際、目的のホストを指定するだけでなく、前にデプロイされたゾーンの1つを指定する必要もありあます。このゾーンは、ストアのトポロジにおいて、そのSNA、およびそのSNAに管理されるサービスを「含む」ことになります。したがって、KVStoreのデプロイメント・プロセスでは、1つ以上のゾーンからなるストアが作成されます。このストアでは、ストレージ・ノードの別個のセットがそれらのゾーンの1つのみに属します(そのゾーンのメンバーとなります)。

ゾーンとは異なり、ストアに「デプロイ」するのではなく、ストア内に1つ以上のストレージ・ノードの「プール」を(オプションで)作成できます。そのような「プール」を作成すれば、デプロイ済のストレージ・ノードをそのプールおよび作成済の他のプールに「結合する」ように構成できます。つまり、ゾーン(この場合、ストアはデプロイされたSNの別々のセットを含む1つ以上のゾーンで構成されます)とは異なり、ストアを1つ以上の「プール」で構成することも可能で、その場合、特定のSNをどのプールに結合するか、またはいくつ結合するかに制限はありません。各ストアはAllStorageNodesという名前のデフォルトのプールを使用して自動的に構成され、デプロイされたすべてのストレージ・ノードがそのプールに結合されます。追加のプールの作成はオプションで、デプロイヤの裁量に任され、特定のストレージ・ノードをどのプールに結合するかの判断についても同様です。

前述した違いに加えて、ゾーンとプールを使用してストレージ・ノードのセットをグループ化する際に理解する必要がある概念上の違いもあります。物理的な境界を超えてストアのノードの論理的なグループを表すためにゾーンを使用することもできますが、デプロイヤは通常、ゾーンを実際の物理的な場所にマップします。たとえば、複数のSNAプロセスを1つのマシンにデプロイすることに問題はありませんが(この場合、各SNAは異なるゾーンにデプロイされます)、多くの場合、1つのSNAは1つのマシンにデプロイされ、ストアのゾーンは、各ゾーン内のSNマシンとともに、ある程度の障害分離を可能にする物理的な場所に対応するよう定義されます。たとえば、各ゾーンは建物の別のフロアや数マイル離れた(あるいは国内各地の)別の建物に対応するよう定義されることがあります。

ゾーンとプールが通常どのように使用されるかを比較してみましょう。1つのプールはすべてのゾーンのすべてのストレージ・ノードを表すことがあり、デフォルト・プールはそのようなプールの1つです。一方、複数のプールが指定されることもあります。プールとゾーンの間に関係がない場合もありますが、各プールがそれぞれ1つのゾーンに対応し、そのゾーンに属するノードのみを含む場合もあります。ストレージ・ノード・プールのセットをストアのゾーンに直接マップする理由が存在することもありますが、これはプールの主要な目的ではありません。ゾーンの目的は、ストレージ・ノードの物理的な場所を使用して、障害分離と地理的可用性の向上を可能にすることですが、プールの主要な目的は、特定の管理操作を適用する際、ストレージ・ノードのグループを参照するための便利なメカニズムを提供することです。つまり、プール引数を取る管理ストア操作を一度呼び出して、指定したプールに属するすべてのストレージ・ノードに対して目的の操作を適用できるため、操作を複数回(各ストレージ・ノードにつき1回)実行する必要はありません。

ゾーンに関連して理解する必要があるもう1つの用語は、レプリケーション係数(またはrf)です。ゾーンをKVStoreにデプロイするときは必ず、そのゾーンの「レプリケーション係数」を指定する必要があります。この係数は、関連付けられたゾーンのノードに書き込まれ、維持される各キー/値ペアのコピー(または「レプリカ」)の数を表します。「容量」は特定のマシンで管理するRNサービスの数を示すSN単位の概念ですが、「レプリケーション係数」はゾーン単位をスコープとする概念であり、関連付けられたゾーン内で作成および管理される各シャード(または「レプリケーション・グループ」)に属するRNサービスの数を決定するために使用されます。

最後に、「ネットワーク・リストア」は特定のRNサービスによって以前に書き込まれたすべてのデータをストアが自動的にリカバリするプロセスです。つまり、様々なSNで実行中の1つ以上のRNサービスからデータのレプリカを取得し、データベースをリストアするRNにそのデータを(ネットワークを介して)転送します。このプロセスがシステム・パフォーマンスに及ぼす可能性がある影響を理解することが重要です。このプロセスはかなりの時間がかかる場合があり、リストアされたRNのデータ・ストアを再移入している間、大量のネットワーク・トラフィックおよび負荷が発生することがあります。また、SN交換については、交換対象のSNの容量が1を超えていると、複数のネットワーク・リストアが実行されるため、これらの影響が拡大する場合があります。

前提

ここで2つの手順を示す際、簡略化のため、KVStoreが最初に3つのマシンにデプロイされ、その結果host-sn1、host-sn2、host-sn3という名前のホスト上にそれぞれsn1、sn2、sn3という3つのストレージ・ノードからなるクラスタが存在していることを前提としています。次のことを前提としています。

  • 各マシンには、/optおよび/disk1という名前のディスクがあります。各SNはその構成および管理データベースを/opt/ondb/var/kvrootに格納しますが、他の個別のディスクに書き込まれるデータを/disk1/ondb/dataに格納します。

  • KVStoreは各マシンの/opt/ondb/kvにインストールされています。つまり、KVHOME=/opt/ondb/kvとなります。

  • KVStoreは、KVROOT=/opt/ondb/var/kvrootでデプロイされます。

  • KVStoreは、example-storeという名前です。

  • Zone1という名前で、rf=3と構成された1つのゾーンがストアにデプロイされています。

  • 各SNはcapacity=1と構成されています。

  • 各SNをZone1という名前のゾーンにデプロイすると、各SNはsnpoolという名前のpoolに結合されます。

  • SNAサービスおよびRNサービスだけでなく、管理サービスも各マシンにデプロイされます。つまり、admin1がhost-sn1にデプロイされ、admin2がhost-sn2にデプロイされ、admin3がhost-sn3にデプロイされ、それぞれがポート13230でリスニングします。

前述の前提に反映された値など、特定の値を使用すると、各手順のステップを実行できます。この管理者を使用することで、これらのステップを一般化して独自の特定のデプロイメント・シナリオに拡張し、必要に応じて特定の環境に固有の値を置き換えることができます。

交換手順1: SNを同一のSNと交換する

ここで示す手順では、目的のSNをネットワークおよびSN idが同じマシンと交換する方法について説明します。この手順を実行する前に、次のような数多くの要件を満たす必要があります。

  • 管理サービスが実行中で、システム内のどこかでアクセス可能である必要があります。

  • 交換対象のSNのidを把握している必要があります。

  • 新しいSNを起動する前に、交換対象のSNは管理上の理由、または障害のために停止している必要があります。

交換対象のSNの現在の構成を管理サービスのデータベースから取得し、新しいSNでのインストール用にパッケージ化するには、管理サービスが必要です。このため、処理を進める前に、管理者は管理サービスの場所(ホスト名またはIPアドレス)と、そのサービスが要求をリスニングしているポートを把握している必要があります。また、このプロセスでは交換対象のSNのidが必要になるため、管理者は次の手順を開始する前にsn1、sn2、sn3など、その値も把握している必要があります。

最後に、交換対象のSNで障害が発生し、そのSNが停止している場合、前述の最後の要件は自動的に満たされます。一方、交換対象のSNが稼働している場合は、新しいSNを起動する前のある時点で古いSNを停止し、そのSNと交換先のSNが競合しないようにする必要があります。

管理サービスに関連する要件については、システムで管理サービスの複数のインスタンスが実行中である場合、次のステップでどのインスタンスを使用するかは重要ではなく、単に管理サービスが現在実行中であり、アクセス可能であることが重要です。つまり、交換対象のSNが稼働しているだけでなく管理サービスを実行している場合、その管理サービスを使用してそのSNの現在の構成を取得し、パッケージ化できます。しかし、なんらかの理由でそのSNで障害が発生した場合や、SNが停止するか、またはアクセスできなくなった場合は、そのSN上の管理サービスも停止したりアクセスできなくなります。つまり、次の手順ではシステム内の他のいずれかのSNで実行中の管理サービスを使用する必要があります。このような理由から、Oracle NoSQL Databaseドキュメントでは、管理者が複数の管理サービスをデプロイすることをお薦めしています。デプロイされた数が多ければ、クォーラムが失われる可能性が低くなります。

たとえば、ストアのデプロイ時に1つの管理サービスのみを指定し、そのサービスを交換対象のSNにデプロイしており、そのSNで障害が発生したりアクセスできなくなった場合、その唯一の管理サービスが失われるため、ここに示す手順を使用して問題のSNを交換するのは非常に困難であることは明らかです。複数の管理サービス(2つの管理サービスなど)をデプロイしたとしても、SNの障害のためにそのうちの1つの管理サービスでも障害が発生してクォーラムを失った場合には、稼働中の管理サービスは残るものの、管理サービスが問題のSNの交換に必要な役割を果たせるようにクォーラムをリカバリするための追加の作業が必要です。

前提の項の説明に従ってKVStoreがデプロイされたものとします。また、なんらかの理由でsn2マシン(ホスト名host-sn2)で障害が発生し、交換する必要があるものとします。管理者は、障害が発生したSNを同一の正常に稼働しているマシンと交換する場合、次の処理を実行します。

  1. なんらかの理由でhost-sn2が実行中である場合は停止します。

  2. host-sn1 (またはhost-sn3)にログインします。

  3. コマンドラインからgenerateconfigユーティリティを実行して、障害が発生したSN (sn2)の現在の構成を含むZIPファイルをsn2-config.zipという名前で生成します。 

    > java -Xmx64m -Xms64m \
       -jar /opt/ondb/kv/lib/kvstore.jar generateconfig \
       -host host-sn1 -port 13230 \
       -sn sn2 -target /tmp/sn2-config

    これにより、ファイル/tmp/sn2-config.zipが作成され、移入されます。

  4. 新規マシンを導入し、交換対象のマシンと同じネットワーク構成、特に同じホスト名とIPアドレスでプロビジョニングします。

  5. KVHOME=/opt/ondb/kvの新規マシンにKVStoreソフトウェアをインストールします。

  6. ディレクトリKVROOT=/opt/ondb/var/kvrootが存在する場合はこれが空であることを確認し、そうでない場合はこれを作成します。 

    > rm -rf /opt/ondb/var/kvroot
> mkdir -p /opt/ondb/var/kvroot

  7. ZIPファイルをhost-sn1から新しいhost-snにコピーします。 

    > scp /tmp/sn2-config.zip host-sn2:/tmp

  8. 新しいhost-sn2で、コピーしたZIPファイルの内容をインストールします。 

    > unzip /tmp/sn2-config.zip -d /opt/ondb/var/kvroot

  9. インストールした古いsn2構成を使用して、新しいhost-sn2マシンでsn2ストレージ・ノードを再起動します。

    ノート:

    SNAを起動する前に、環境変更MALLOC_ARENA_MAXを1に設定します。MALLOC_ARENA_MAXを1に設定すると、メモリー使用量が指定されたヒープ・サイズに制限されます。 

    > nohup java -Xmx64m -Xms64m \
             -jar /opt/ondb/kv/lib/kvstore.jar start \
             -root /opt/ondb/var/kvroot \
             -config config.xml&

    これにより、SNA、RNおよび管理サービスの起動後、ネットワーク・リストアが開始され(時間がかかる可能性があります)、この新しいsn2で管理されるデータ・ストアが再移入されます。

交換手順2: 除外したSNの役割を新しいSNで引き継ぐ

ここで示す手順では、ネットワークおよびSN idがストア内の現在のすべてのSNとは異なり、そのSNの役割およびデータを引き継ぐことで現在のSNのいずれかと効果的に置き換え、新しいSNをデプロイする方法について説明します。前の手順と異なり、この2つ目の手順を実行するときに満たす必要がある唯一の前提条件は、管理サービスの稼働中のクォーラムが存在することです。また、前の手順では、交換先のSNの電源を入れる前に交換対象のSNを停止する必要がありましたが(2つのSNがidを共有するため)、この手順では、プロセスの移行ステップまで交換対象のSNを稼働させたままにし、最終的に交換先のSNが交換対象のSNの役割を引き継ぐことができます。このため、必要に応じて手順全体を通して交換対象のSNを停止できますが、交換先のSNの準備を整えている間も引き続き要求に対応できるように、そのSNを稼働させておくこともできます。

前提の項の説明に従ってKVStoreがデプロイされたものとします。また、sn2マシンは現在稼働中ですが、メモリーとディスクの容量が大きく、全体的なパフォーマンス特性に優れた新規マシンにアップグレードする必要があるものとします。次に、管理者は次の処理を実行します。

  1. Oracle NoSQL Databaseソフトウェアがインストールされ、デプロイ済のKVStore用の管理サービスを実行しているいずれかのマシンにネットワーク経由でアクセスできるマシンから管理CLIを起動して、それをその管理サービスに接続します。CLIが実行されているマシンは、交換対象のマシンを含め、ストアを構成するマシンのいずれか、または独立したクライアント・マシンになります。たとえば、管理CLIをsn1ストレージ・ノードで起動し、その同じsn1ホストで実行中の管理サービスにそのCLIを接続する場合、host-sn1という名前のホストのコマンド・プロンプトから次のように入力します。 

    > java -Xmx64m -Xms64m \
-jar /opt/ondb/kv/lib/kvstore.jar runadmin \
       -host host-sn1 -port 13230

  2. 起動した管理CLIからshow poolsコマンドを実行して、デプロイ後に新しいストレージ・ノードを結合する必要があるストレージ・ノードpoolを決定します。たとえば、次のようにします。 

    kv-> show pools

    初期の前提であれば、次のような出力が生成されます。 

    AllStorageNodes: sn1 sn2 sn3
snpool: sn1 sn2 sn3

    この出力から、新しいストレージ・ノードが結合されるプールの名前がsnpoolであり、すべてのストレージ・ノードがデプロイされたときにデフォルトで結合されるプールがAllStorageNodesという名前のプールであることがわかります。

  3. 起動した管理CLIからshow topologyコマンドを実行し、新しいストレージ・ノードをデプロイするときに使用するゾーンを決定します。たとえば、次のようにします。 

    kv-> show topology

    次のような出力が生成されます。 

    store=example-store numPartitions=300 sequence=308
  zn: id=1 name=Zone1 repFactor=3

  sn=[sn1] zn:[id=1 name=Zone1] host-sn1 capacity=1 RUNNING
    [rg1-rn1] RUNNING

  sn=[sn2] zn:[id=1 name=Zone1] host-sn2 capacity=1 RUNNING
    [rg1-rn2] RUNNING

  sn=[sn3] zn:[id=1 name=Zone1] host-sn3 capacity=1 RUNNING
    [rg1-rn3] RUNNING
  ........

    この出力から、新しいストレージ・ノードをデプロイするときに使用するゾーンのidは1であることがわかります。

  4. 新規マシンを導入し、現在、デプロイ済のKVStoreで認識されている各マシンとは異なるネットワーク構成でプロビジョニングします。たとえば、host-sn4などのホスト名、およびストアのメンバーに対して一意のIPアドレスを使用して、新規マシンをプロビジョニングします。

  5. KVHOME=/opt/ondb/kvの新規マシンにKVStoreソフトウェアをインストールします。

  6. 新しいストレージ・ノードのKVROOTディレクトリを作成します。たとえば、次のようにします。 

    > mkdir -p /opt/ondb/var/kvroot

  7. KVROOTとは別のディスクに新しいストレージ・ノードのデータ・ディレクトリを作成します。たとえば、次のようにします。 

    > mkdir -p /disk1/ondb/data

    ノート:

    交換先のSNのデータ・ディレクトリに使用されるパスは、交換対象のSNで使用されているパスと同じである必要があります。

  8. 新しいhost-sn4マシンのコマンド・プロンプトから、makebootconfigユーティリティ(『Oracle NoSQL Database管理者ガイド』の第2章「インストール構成」を参照)を使用して、前述の前提と整合性がある新しいストレージ・ノードの初期構成を作成します。たとえば、次のようにします。 

    > java -Xmx64m -Xms64m \
-jar /opt/ondb/kv/lib/kvstore.jar makebootconfig \
       -root /opt/ondb/var/kvroot \
       -port 13230  \
       -host host-sn4
       -harange 13232,13235 \
       -num_cpus 0  \
       -memory_mb 0 \
       -capacity 1  \
       -admindir /opt/ondb/var/admin \
       -admindirsize 3_gb \
       -storagedir /disk1/ondb/data \
       -rnlogdir /disk1/ondb/rnlog

    これにより、config.xmlという名前のファイルがKVROOT=/opt/ondb/var/kvrootに生成されます。

  9. 作成した構成を使用して、新しいhost-sn4マシンでKVStoreソフトウェア(SNAとそのマネージド・サービス)を起動します。たとえば、次のようにします。

    ノート:

    SNAを起動する前に、環境変更MALLOC_ARENA_MAXを1に設定します。MALLOC_ARENA_MAXを1に設定すると、メモリー使用量が指定されたヒープ・サイズに制限されます。 

    > nohup java -Xmx64m -Xms64m \
             -jar /opt/ondb/kv/lib/kvstore.jar start \
             -root /opt/ondb/var/kvroot \
             -config config.xml &

  10. 前述のshow topologyおよびshow poolsコマンドから収集されたsn2ストレージ・ノード(交換するSN)に関連付けられた情報を使用して、管理CLIで新しいストレージ・ノードをデプロイし、目的のプールに結合します。つまり、次のようにします。 

    kv-> plan deploy-sn -znname Zone1 -host host-sn4 -port 13230 -wait
kv-> pool join -name snpool -sn sn4

    SNをプールに結合するには、SNを正常にデプロイし、デプロイしたSNのidを前述のsn4のようにpool joinコマンドに指定する必要があります。しかし、plan deploy-snコマンドを調査すると、デプロイ対象のSNに割り当てるidが指定されていないことがわかります。これは、新規にデプロイしたSNに割り当てるidを決定するのが管理者ではなくKVStore自体であるためです。このため、この手順を示すために使用した例では、当初3つのストレージ・ノードのみがデプロイされたものとして仮定した場合、次のストレージ・ノードをデプロイすると、最近デプロイしたSNに割り当てられたidの整数部分(sn3またはこの場合は3)が1だけ増分され、その結果を使用して、次にデプロイされるSNに割り当てるidを構築します。このため、sn4が前述のpool joinコマンドに指定するidであると仮定しました。ただし、割り当てられたidを確認する場合は、プールに結合する前にshow topologyコマンドを実行して、構築され、新規にデプロイしたSNに割り当てられたidを表示します。

  11. 移行処理を実行するときに古いSNを実行中にしないようにする必要があるため(次のステップを参照)、交換対象のSNがこの時点でまだ実行中である場合はプログラムで停止してから、電源を切り、関連付けられたマシンを切断します。この手ステップは、次のステップを実行する前のどの時点でも実行できます。このため、交換対象のSNを停止するには、そのSNをホストしているマシンのコマンド・プロンプトから次のように入力します。 

    > java -Xmx64m -Xms64m \
       -jar /opt/ondb/kv/lib/kvstore.jar stop \
       -root /opt/ondb/var/kvroot

    完了後、必要に応じて関連付けられたマシンの電源を切って切断できます。

  12. 新しいストレージ・ノードがデプロイされて目的のプールに結合され、交換対象のSNが実行中でなくなった後、管理CLIを使用してその古いSNを新しいSNに移行します。つまりこの場合、SNA、およびsn4に関連付けられたRNは、sn2に関連付けられ、対応するサービスがストアでそれまで果たしていた役割を引き継ぎます。また、sn2によってそれまで格納されたデータがネットワーク経由でsn4用のストレージ・ディレクトリに移動されます。その後このステップを実行するには、CLIから次のコマンドを実行します。 

    kv-> plan migrate-sn -from sn2 -to sn4 [-wait]

    前述のコマンドで、-wait引数はオプションです。-waitを使用した場合、コマンドは完全移行が完了するまで戻らず、移行対象のデータ量によっては長時間がかかる場合があります。-waitを指定しない場合、show plan -id <migration-plan-id>コマンドを使用して移行の進行状況を追跡することで、移行中に他の管理タスクを実行できます。

  13. 移行プロセスが完了したら、ストアのトポロジから古いSNを削除します。これは、管理CLIからplan remove-snコマンドを実行することで行います。たとえば、次のようになります。 

    kv-> plan remove-sn -sn sn2 -wait

    この時点で、ストアはその元の構造に似た構造になっています。ただし、sn2がそのノードのrg1-rn2サービスを介し、host-sn2という名前のホストに元々格納していたデータが現在、sn4ストレージ・ノードを(sn4が現在管理しているrg1-rn2という名前の移行サービスを介して) host-sn4に格納していることを除きます。

例

この項では、前述のSN交換手順で実践的な経験を得ることができる2つの例を示します。各例では、同じ初期構成を使用し、単一のディスクを搭載した単一のマシンを使用して3つのノードからなるKVStoreクラスタをシミュレートすることを目的としています。マシンで実際に障害が発生したり、マシンを物理的に交換することはありませんが、前に説明した手順のいずれかを使用してそのストレージ・ノードを交換すると、特定のSNによって格納されたクラスタおよびデータがどのように自動的にリカバリされるかを理解できます。

KVStoreが前提の項と同じようにデプロイされるとします。具体的には、KVStoreが当初sn1、sn2、sn3という名前の3つのストレージ・ノードを使用して、IPアドレスが文字列<host-ip>で表される単一のホストにデプロイされるものとします。この場合、どちらの例を実行するとしても、<host-ip>をホストの実際のIPアドレス(またはホスト名)に置き換えます。また、開発システムには通常、(前提の項の指定に従って) /disk1という名前のディスクが含まれないため、このようなディスクをプロビジョニングするのではなく、ストアに書き込まれたデータはそれぞれ/tmp/sn1/disk1、/tmp/sn2/disk1および/tmp/sn3/disk1に格納されるものとします。最後に、各ストレージ・ノードは同じホストで稼働するため、これらのストレージ・ノードがそのノードによって実行されるサービスおよび管理用の様々なポートで構成されているものとします。そうでない場合、他のすべての前提は前述の前提の項で説明されているとおりです。

設定

前述のように、初期構成および設定は次のどの例でも同じです。このため、まだ作成していない場合は、まず次のようにKVROOTディレクトリを作成します。 

> mkdir -p /opt/ondb/var/kvroot

次に、データ・ディスクをシミュレートするため、次のディレクトリを作成します。 

> mkdir -p /tmp/sn1/disk1/ondb/data
> mkdir -p /tmp/sn2/disk1/ondb/data
> mkdir -p /tmp/sn3/disk1/ondb/data

続いて、各ストレージ・ノードを実行している3つのマシンを表すWin_A、Win_B、Win_Cの3つのウィンドウを開きます。各ウィンドウで、makebootconfigコマンド(文字列<host-ip>は必ず実際のIPアドレスまたはホスト名に置き換えてください)を実行して、構成対象のSNごとに別の同じようなブート構成を作成します。

Win_Aの場合

java -Xmx64m -Xms64m \
-jar /opt/ondb/kv/lib/kvstore.jar makebootconfig \
     -root /opt/ondb/var/kvroot \
     -host <host-ip> \
     -config config1.xml \
     -port 13230 \
     -harange 13232,13235 \
     -memory_mb 100 \
     -capacity 1 \
     -admindir /opt/ondb/var/admin \
     -admindirsize 2000-Mb \
     -storagedir /tmp/sn1/disk1/ondb/data \
     -rnlogdir /tmp/sn1/disk1/ondb/rnlog

Win_Bの場合

java -Xmx64m -Xms64m \
-jar /opt/ondb/kv/lib/kvstore.jar makebootconfig \
     -root /opt/ondb/var/kvroot \
     -host <host-ip> \
     -config config2.xml \
     -port 13240 \
     -harange 13242,13245 \
     -memory_mb 100 \
     -capacity 1 \
     -admindir /opt/ondb/var/admin \
     -admindirsize 2000-Mb \
     -storagedir /tmp/sn1/disk2/ondb/data \
     -rnlogdir /tmp/sn1/disk2/ondb/rnlog

Win_Cの場合

java -Xmx64m -Xms64m \
-jar /opt/ondb/kv/lib/kvstore.jar makebootconfig \
     -root /opt/ondb/var/kvroot \
     -host <host-ip> \
     -config config3.xml \
     -port 13250 \
     -harange 13252,13255 \
     -memory_mb 100 \
     -capacity 1 \
     -admindir /opt/ondb/var/admin \
     -admindirsize 2000-Mb \
     -storagedir /tmp/sn1/disk3/ondb/data \
     -rnlogdir /tmp/sn1/disk3/ondb/rnlog

これにより、次の3つの構成ファイルが生成されます。 

/opt/ondb/var/kvroot
    /config1.xml
    /config2.xml
    /config3.xml

次に、各ウィンドウから生成した様々な構成を使用して、KVStoreストレージ・ノード・エージェント(SNA)の対応するインスタンスを起動します。これは、生成された特定の構成に基づいて、管理サービスおよびRNサービスを開始および管理します。

ノート:

SNAを起動する前に、環境変更MALLOC_ARENA_MAXを1に設定します。MALLOC_ARENA_MAXを1に設定すると、メモリー使用量が指定されたヒープ・サイズに制限されます。

Win_A

> nohup java -Xmx64m -Xms64m \
             -jar /opt/ondb/kv/lib/kvstore.jar start \
             -root /opt/ondb/var/kvroot \
             -config config1.xml &

Win_B

> nohup java -Xmx64m -Xms64m \
             -jar /opt/ondb/kv/lib/kvstore.jar start \
             -root /opt/ondb/var/kvroot \
             -config config2.xml &

Win_C

> nohup java -Xmx64m -Xms64m \
             -jar /opt/ondb/kv/lib/kvstore.jar start \
             -root /opt/ondb/var/kvroot \
             -config config3.xml &

最後に、任意のウィンドウ(Win_A、Win_B、Win_Cまたは新しいウィンドウ)からKVStore管理CLIを起動し、それを使用してストアを構成およびデプロイします。たとえば、前述のWin_Aに使用されている構成を使用して開始した管理サービスに接続されている管理CLIを起動するには、次のコマンドを実行します。 

> java -Xmx64m -Xms64m \
-jar /opt/ondb/kv/lib/kvstore.jar runadmin \
       -host <host-ip> -port 13230

ストアを構成およびデプロイするには、管理CLIプロンプトから次のコマンドを入力します(文字列<host-ip>は必ず実際のIPアドレスまたはホスト名に置き換えてください)。 

configure -name example-store
plan deploy-zone -name Zone1 -rf 3 -wait
plan deploy-sn -znname Zone1 -host <host-ip> -port 13230 -wait
plan deploy-admin -sn 1 -port 13231 -wait
pool create -name snpool
pool join -name snpool -sn sn1
plan deploy-sn -znname Zone1 -host <host-ip> -port 13240 -wait
plan deploy-admin -sn 2 -port 13241 -wait
pool join -name snpool -sn sn2
plan deploy-sn -znname Zone1 -host <host-ip> -port 13250 -wait
plan deploy-admin -sn 3 -port 13251 -wait
pool join -name snpool -sn sn3
change-policy -params "loggingConfigProps=oracle.kv.level=INFO;"
change-policy -params cacheSize=10000000
topology create -name store-layout -pool snpool -partitions 300
plan deploy-topology -name store-layout -plan-name RepNode-Deploy -wait

ノート:

前述のコマンドのリストでは、CLIのコマンド・プロンプト(kv->)を省いて、コマンドをCLIロード・スクリプトにカット・アンド・ペーストしやすくしています。

前述のコマンドが完了すると(show plansを使用して各プランの完了を確認します)、ストアが稼働し、ストアへのデータ書込みの準備が整います。処理を進める前に、次に示すようなディレクトリが作成され、移入されていることを確認します。 

     - Win_A -                  - Win_B -                - Win_C -

  /opt/ondb/var/             /opt/ondb/var/             /opt/ondb/var/
      admin                      admin                       admin
/opt/ondb/var/kvroot      /opt/ondb/var/kvroot      /opt/ondb/var/kvroot
  log files                 log files                 log files
  /example-store            /example-store            /example-store
    /log                      /log                      /log
    /sn1                      /sn2                      /sn3
      config.xml                config.xml                config.xml
      /admin1                   /admin2                   /admin3
        /env                      /env                      /env

/tmp/sn1/disk1/ondb/data  /tmp/sn2/disk1/ondb/data /tmp/sn3/disk1/ondb/data
  /rg1-rn1                  /rg1-rn2                  /rg1-rn3
    /env                      /env                      /env
      00000000.jdb              00000000.jdb              00000000.jdb

デプロイ済のストアに対してrf=3、そのストア内の各SNに対してcapacity=1であるため、キー/値ペアが最初にストアに書き込まれるとき、ペアはrn1、rn2、rn3の各レプリケーション・ノードによってそれぞれの対応する00000000.jdbという名前のデータ・ファイルに格納されます。各レプリケーション・ノードは、rg1という名前のレプリケーション・グループ(またはシャード)のメンバーです。つまり、キー/値ペアは次に格納されます。 

/tmp/sn1/disk1/ondb/data/rg1-rn1/env/00000000.jdb
/tmp/sn2/disk1/ondb/data/rg1-rn2/env/00000000.jdb
/tmp/sn3/disk1/ondb/data/rg1-rn3/env/00000000.jdb

この時点で設定内の各ファイルには、キー/値ペアは含まれていません。データは、最も便利な方法でストアに書き込むことができます。しかし、これを行うための便利なユーティリティの1つに、KVStoreクライアント・シェル・ユーティリティがあります。これは、目的のストアに接続して、対話型コマンドによってキー/値ペアの入力や取得を行うコマンドライン・インタフェースを表示するプロセスです。KVStoreクライアント・シェルを起動するには、コマンド・ウィンドウから次を入力します(文字列<host-ip>は必ず実際のIPアドレスまたはホスト名に置き換えてください)。 

> java -Xmx64m -Xms64m \
       -jar /opt/ondb/kv/lib/kvstore.jar runadmin\
       -host <host-ip> -port 13230 -store example-store

kv-> get -all
  0 Record returned.

kv-> put -key /FIRST_KEY -value "HELLO WORLD"
  Put OK, inserted.

kv-> get -all
  /FIRST_KEY
  HELLO WORLD

キー/値ペアが各RNサービスによって格納されたことを確認するには、簡略的であまりプログラム的ではありませんが、それぞれのデータ・ファイルで文字列"HELLO WORLD"をgrepで検索する方法が簡単です。これは、ほとんどのLinuxシステムのバイナリ・ファイルに対して実行できます。このようにgrepコマンドを使用するのは、ほんの少量のデータで構成されている例では実践的です。 

> grep "HELLO WORLD" /tmp/sn1/disk1/ondb/data/rg1-rn1/env/00000000.jdb
  Binary file /tmp/sn1/disk1/ondb/data/rg1-rn1/env/00000000.jdb matches
> grep "HELLO WORLD" /tmp/sn2/disk1/ondb/data/rg1-rn2/env/00000000.jdb
  Binary file /tmp/sn2/disk1/ondb/data/rg1-rn2/env/00000000.jdb matches
> grep "HELLO WORLD" /tmp/sn3/disk1/ondb/data/rg1-rn3/env/00000000.jdb
  Binary file /tmp/sn3/disk1/ondb/data/rg1-rn3/env/00000000.jdb matches

前述の出力によると、ストアに書き込まれたキー/値ペアはシャードrg1に属する各RNサービス、つまりidが1に等しいレプリケーション・グループのメンバーである各RNサービス(rg1-rn1、rg1-rn2およびrg1-rn3)によって格納されています。特定のキーがどのシャードに関連付けられるかは、キーの値(特にキーの値のハッシュ)、およびストアによって保持されるシャードの数(この場合は1)によって異なります。また、この例には00000000.jdbという名前のログ・ファイルが示されていますが、これらのファイルは、対応するRNサービスにより書き込まれたデータを含むこのような(多数存在する可能性がある)ログ・ファイルの最初の一部にすぎません。時間の経過に伴って現在のログ・ファイルがその最大容量に達すると、書込み対象のすべての新しいデータを受信するために新規ファイルが作成されます。その新規ファイルには、前のファイルの接頭辞を増分することで前のファイルから導出された名前が付けられます。たとえば、00000997.jdb、00000998.jdb、00000999.jdb、00001000.jdb、00001001.jdbなどの名前がファイルに付与されます。

データがストアに書き込まれたところで、障害が発生したストレージ・ノードをシミュレートし、最初のSN交換手順の例を実行できます。

例1: 障害が発生したSNを同一のSNと交換する

障害が発生したストレージ・ノードをシミュレートするには、上で起動したストレージ・ノードのいずれかを選択し、その関連付けられたプロセスをプログラムで停止し、そのプロセスに関連付けられたすべてのファイルおよびディレクトリを削除します。たとえば、sn2が「障害の発生した」ストレージ・ノードであるとします。ただし、sn2ストレージ・ノードを停止する前に、まず(オプションで)デプロイ済のストアの一部として実行されているプロセスを次のように特定できます。

> jps -m
408 kvstore.jar start -root /opt/ondb/var/kvroot -config config1.xml
833 ManagedService -root /opt/ondb/var/kvroot -class Admin -service
BootstrapAdmin.13230 -config config1.xml
1300 ManagedService -root /opt/ondb/var/kvroot/example-store/sn1 -store
example-store -class RepNode -service rg1-rn1
....
563 kvstore.jar start -root /opt/ondb/var/kvroot -config config2.xml
1121 ManagedService -root /opt/ondb/var/kvroot/example-store/sn2
-store example-store -class Admin -service admin2
1362 ManagedService -root /opt/ondb/var/kvroot/example-store/sn2 
-store example-store -class RepNode -service rg1-rn2
....
718 kvstore.jar start -root /opt/ondb/var/kvroot -config config3.xml
1232 ManagedService -root /opt/ondb/var/kvroot/example-store/sn3 -store
example-store -class Admin -service admin3
1431 ManagedService -root /opt/ondb/var/kvroot/example-store/sn3 -store
example-store -class RepNode -service rg1-rn3
....

前述の出力は読みやすいように手動で順序を変更しました。実際には、リストの各プロセスはランダムな順序で出力される場合があります。ただし、例のデプロイメントの各SNは次の3つのプロセスに対応しています。

  • SNAプロセスは文字列kvstore.jar startで特徴付けられ、対応する構成ファイルで識別されます。たとえば、sn1はconfig1.xml、sn2はconfig2.xml、sn3はconfig3.xmlとなります。

  • 管理サービスは、文字列-class Adminと、-service BootstrapAdmin.<port>という形式の文字列または-service admin<id>という形式の文字列で特徴付けられます(次の説明を参照)。

  • RNサービスは、文字列-class RepNodeと、-service rg1-rn<id>という形式の文字列(<id>は1や2など)で特徴付けられ、そのRNサービスのホストとなっているSNにマップされます。ある特定のSNでそのSNのcapacityがN>1である場合、そのSNに対してリストには異なるRepNodeサービスを参照するN個のプロセスがあります。

ノート:

参考のため、文字列-service BootstrapAdmin.<port>を参照する前述のプロセス・リストの行について少し説明しておきます。SNAが起動し、-admin引数が構成に指定されていると、SNAは最初にブートストラップ管理と呼ばれるものを起動します。この例では3つすべてのストレージ・ノードの構成に-admin引数を指定したため、例の各SNAは対応するブートストラップ管理を起動します。前述のプロセス・リストでBootstrapAdminを参照するエントリが1つだけであることについて、次に説明します。

Oracle NoSQL Databaseでは少なくとも1つ以上の管理サービスのデプロイが必要になることを思い出してください。このような管理を2つ以上デプロイした場合、デプロイされた管理サービスはまずKVStore内の特別なロールを引き受けます。この例では、対応するストレージ・ノード・エージェントによって起動された3つのブートストラップ管理のいずれも、最初のデプロイ済管理サービスになることができます。ストアを構成し、ゾーンをデプロイした後、デプロイヤは起動したストレージ・ノードのいずれかを選択し、plan deploy-snコマンドを使用してそのストレージ・ノードをストア内の目的のゾーンにデプロイする必要があります。その最初のストレージ・ノードをデプロイした後、次にplan deploy-adminコマンドを使用してそのストレージ・ノードに対応する管理サービスをデプロイする必要があります。

その最初の管理サービスをデプロイするまで、他のストレージ・ノードまたは管理はデプロイできません。最初のSN (この場合はsn1)を実行しているマシンにその最初の管理サービスをデプロイすると、そのマシンで実行中のブートストラップ管理は引き続き稼働し、ストア内の最初の管理サービスのロールを引き受けます。このような理由から、BootstrapAdmin.<port>プロセスは引き続きプロセス・リストに記載されます。一方、次に説明するように、他のストレージ・ノードに関連付けられたプロセスはBootstrapAdmin.<port>ではなくadmin2およびadmin3で識別されます。他のストレージ・ノード(および管理サービス)をデプロイできるのは、この最初の管理サービスをデプロイした後のみです。

他のストレージ・ノードのデプロイ時に、このような各ストレージ・ノードに関連付けられたBootstrapAdminプロセスは停止し、RMIレジストリから削除されます。これは、これらの追加のストレージ・ノードではブートストラップ管理が必要ないためです。ブートストラップ管理の存在は、関連付けられたストレージ・ノード・エージェントが必要に応じて最初の管理サービスのホストとなることができることを示します。ただし、最初のストレージ・ノードをデプロイし、その対応するブートストラップ管理が最初の管理ロールを引き受けると、他のストレージ・ノードはその最初の管理のホストとなることができなくなります。そのため、追加の各ストレージ・ノードのデプロイ時に、対応するBootstrapAdminプロセスが停止します。また、ストアのデプロイ後のある時点で、BootstrapAdminを参照するその最初のプロセスの停止と再起動が行われた場合、新しいプロセスが、他の管理プロセスと同じように、プロセス・リスト内で文字列-class Adminとともに識別されます。

最後に、ストアは1つの管理サービスのみでデプロイできますが、複数の管理サービスを稼働させて可用性を高めることをお薦めします。デプロイされる管理の数は、SNで障害が発生してもクォーラムが失われる可能性がほとんどない十分な数にしてください。このため、この例で示すように、追加の各ストレージ・ノードをデプロイした後(および対応するブートストラップ管理を停止した後)、新しい管理サービスをデプロイしてください。これは最初の管理サービスと調整しながら、保持される管理情報をレプリケートします。したがって、前述のプロセス・リストのsn1に関連付けられた管理サービスはBootstrapAdmin (最初の管理サービス)であると識別され、他の管理サービスは単にadmin2およびadmin3であると識別されます。

このため、「障害が発生した」ストレージ・ノードをシミュレートするには、sn2を停止します。そのためには、コマンド・プロンプトで次のように入力します。 

> java -Xmx64m -Xms64m \
       -jar /opt/ondb/kv/lib/kvstore.jar stop \
       -root /opt/ondb/var/kvroot \
       -config config2.xml

オプションで、jpsコマンドを使用して残りのプロセスを調べます。つまり、次のようにします。 

> jps -m

408 kvstore.jar start -root /opt/ondb/var/kvroot
-config config1.xml
833 ManagedService -root /opt/ondb/var/kvroot
-class Admin -service BootstrapAdmin.13230 -config config1.xml
1300 ManagedService -root /opt/ondb/var/kvroot/
example-store/sn1 -store example-store -class RepNode -service rg1-rn1
....
718 kvstore.jar start -root /opt/ondb/var/
kvroot -config config3.xml
1232 ManagedService -root /opt/ondb/var/kvroot/example-store/
sn3 -store example-store -class Admin -service admin3
1431 ManagedService -root /opt/ondb/var/kvroot/example-store/
sn3 -store example-store -class RepNode -service rg1-rn3
....

以前にsn2に関連付けられたプロセスは実行されなくなります。次に、sn2プロセスは停止しているため、関連付けられたファイルを次のように削除できます。 

> rm -rf /tmp/sn2/disk1/ondb/data/rg1-rn2
> rm -rf /opt/ondb/var/kvroot/example-store/sn2

> rm -f /opt/ondb/var/kvroot/config2.xml
> rm -f /opt/ondb/var/kvroot/config2.xml.log
> rm -f /opt/ondb/var/kvroot/snaboot_0.log.1*

> rm -r /opt/ondb/var/kvroot/example-store/log/admin2*
> rm -r /opt/ondb/var/kvroot/example-store/log/rg1-rn2*
> rm -r /opt/ondb/var/kvroot/example-store/log/sn2*
> rm -r /opt/ondb/var/kvroot/example-store/log/config.rg1-rn2
> rm -r /opt/ondb/var/kvroot/example-store/log/example-store_0.*.1*

接尾辞部分に1が含まれている前述のファイル(たとえば、snaboot_0.log.1、example-store_0.log.1、example-store_0.perf.1、example-store_0.stat.1など)がsn2ストレージ・ノードに関連付けられています。

次に、前述のコマンドを実行して、sn2がデプロイされた「マシン」の致命的な障害をシミュレートします。sn2に関連付けられた構成およびデータは、この時点で完全に使用できなくなり、「新しい」(およびこの例では同一の) sn2ストレージ・ノードのデプロイによってのみリカバリ可能です。これを確認するには、前に開始した管理CLIから、次のようにshow topologyコマンドを実行します。 

kv-> show topology

次のような出力が生成されます。 

store=example-store numPartitions=300 sequence=308
  zn: id=1 name=Zone1 repFactor=3

  sn=[sn1] zn:[id=1 name=Zone1] <host-ip> capacity=1 RUNNING
    [rg1-rn1] RUNNING

  sn=[sn2] zn:[id=1 name=Zone1] <host-ip> capacity=1 UNREACHABLE
    [rg1-rn2] UNREACHABLE

  sn=[sn3] zn:[id=1 name=Zone1] <host-ip> capacity=1 RUNNING
    [rg1-rn3] RUNNING
  ........

文字列<host-ip>のかわりに実際のIPアドレスまたはホスト名が表示されます。sn2がこの時点でUNREACHABLEであることを確認してください。

この時点で、SN交換手順の最初の2つのステップはすでに実行されています。つまり、sn2プロセスが停止し、その関連するファイルが削除されたため、ストアの他のノードから見ると、対応する「マシン」はアクセス不可能で、実質的に「停止」したことになります(ステップ1)。また、このシミュレーションでは単一のマシンを使用しているため、sn1 (およびsn3)ホストにすでにログインしています(ステップ2)。このため、この時点で手順のステップ3を実行できます。つまり、ストアの残りの問題なく稼働しているノードのいずれかからsn2構成を取得するには、それらの残りのいずれかのノード用のポートを使用して次のコマンドを実行します(文字列<host-ip>は必ず実際のIPアドレスまたはホスト名に置き換えてください)。 

> java -Xmx64m -Xms64m \
       -jar /opt/ondb/kv/lib/kvstore.jar generateconfig \
       -host <host-ip> -port 13230 \ 
       -sn sn2 -target /tmp/sn2-config

前述のコマンドによって想定どおりのzipファイルが生成されたことを確認します。 

> ls -al /tmp/sn2-config.zip
-rw-rw-r-- 1 <group> <owner> 2651 2024-04-05 12:53 /tmp/sn2-config.zip

/tmp/sn2-config.zipの内容は次のようになります。 

> unzip -t /tmp/sn2-config.zip

Archive: /tmp/sn2-config.zip
testing: kvroot/config.xml  OK
testing: kvroot/example-store/sn2/config.xml  OK
testing: kvroot/example-store/security.policy  OK
testing: kvroot/security.policy  OK
No errors detected in compressed data of /tmp/sn2-config.zip

次に、この例は単一のマシンで実行しているため、SN交換手順のステップ4、5、6、7はすでに実行されています。このため、次に実行するステップは、次のように、生成したZIPファイルの内容をインストールすることです。 

> unzip /tmp/sn2-config.zip -d /opt/ondb/var

これは、kvroot/security.policyおよびkvroot/example-store/security.policyをそのファイルの同一バージョンで上書きします。

ストアを最初にデプロイしたとき、最上位の各構成ファイルの名前は同じではありませんでした。つまり、sn1はconfig1.xml、最初にデプロイされたsn2はconfig2.xml、sn3はconfig3.xmlです。これが必要になるのは、便宜上、同じKVROOTを使用して3つすべてのSNをデプロイした結果、sn1、sn2、sn3の間で競合が発生して、それらのファイルに同じ名前が使用されたためです。これを念頭に、上記で実行したgenerateconfigコマンドは新しいsn2の最上位の構成ファイルをconfig2.xmlではなくデフォルト名(config.xml)で生成することを確認してください。config2.xmlとconfig.xmlのどちらの名前もストアの他のノードの構成ファイル名に対して一意であるため、いずれの名前も次のステップで使用できます(次を参照)。ただし、sn2を最初にデプロイした方法との整合性を確保するため、交換先をデプロイするときにも元のファイル名を使用します。このため、次のステップに進む前に、次のようにkvroot/config.xmlファイルの名前をkvroot/config2.xmlに変更します。 

> mv /opt/ondb/var/kvroot/config.xml /opt/ondb/var/kvroot/config2.xml

最後に、最初のSN交換手順の最後のステップを実行できます。つまり、古いsn2構成を使用して、「新規」で同一のsn2を起動します。

ノート:

SNAを起動する前に、環境変更MALLOC_ARENA_MAXを1に設定します。MALLOC_ARENA_MAXを1に設定すると、メモリー使用量が指定されたヒープ・サイズに制限されます。 

> nohup java -Xmx64m -Xms64m \
             -jar /opt/ondb/kv/lib/kvstore.jar start \
             -root /opt/ondb/var/kvroot \
             -config config2.xml &

確認

sn2が正常に交換されたことを確認するには、まず管理CLIから次のようにshow topologyコマンドを実行します。 

kv-> show topology

次のような出力が生成されます。 

store=example-store numPartitions=300 sequence=308
  zn: id=1 name=Zone1 repFactor=3

  sn=[sn1] zn:[id=1 name=Zone1] <host-ip> capacity=1 RUNNING
    [rg1-rn1] RUNNING

  sn=[sn2] zn:[id=1 name=Zone1] <host-ip> capacity=1 RUNNING
    [rg1-rn2] RUNNING

  sn=[sn3] zn:[id=1 name=Zone1] <host-ip> capacity=1 RUNNING
    [rg1-rn3] RUNNING
  ........

文字列<host-ip>のかわりに実際のIPアドレスまたはホスト名が表示されます。sn2がこの時点で再びRUNNINGになっていることを確認してください。

show topologyコマンドを実行するだけでなく、削除されていたsn2ディレクトリ構造が再作成され、再移入されたことも確認できます。つまり、次のようなディレクトリおよびファイルが再度存在します。 

/opt/ondb/var/kvroot
  ....
  config2.xml*
  ....
  /example-store
    /log
      ....
      admin2*
      rg1-rn2*
      sn2*
      config.rg1-rn2
      ....
    /sn2
      config.xml
      /admin2
        /env

/tmp/sn2/disk1/ondb/data
  /rg1-rn2
    /env
      00000000.jdb

最後に、元のsn2に格納されていたデータがリカバリされたことを確認します。 

> grep "HELLO WORLD" /tmp/sn2/disk1/ondb/data/rg1-rn2/env/00000000.jdb
  Binary file /tmp/sn2/disk1/ondb/data/rg1-rn2/env/00000000.jdb matches

例2: 新しいSNで既存のSNの役割を引き継ぐ

この例では、前に説明した2つ目の交換手順を使用して、問題なく稼働している既存のストレージ・ノード(この場合はsn2)を新しいストレージ・ノードに交換/アップグレードし、古いストレージ・ノードの役割を引き継がせます。前に示したように、この例の前提および設定は最初の例の前提および設定と同じです。このため、以前に指定したようにこの例を設定した後、sn1ストレージ・ノードに関連付けられた管理サービスに接続されている管理CLIを起動します。つまり、文字列<host-ip>を実際のIPアドレスまたはホスト名に置き換えたうえで、次のコマンドを実行します。 

> java -Xmx64m -Xms64m \
-jar /opt/ondb/kv/lib/kvstore.jar runadmin \
       -host <host-ip> -port 13230

次に、起動した管理CLIから、show poolsおよびshow topologyコマンドを次のように実行します。 

kv-> show pools
kv-> show topology

それぞれ次のような出力が生成されます。 

AllStorageNodes: sn1 sn2 sn3
snpool: sn1 sn2 sn3

および 

store=example-store numPartitions=300 sequence=308
  zn: id=1 name=Zone1 repFactor=3

  sn=[sn1] zn: [id=1 name=Zone1] host-sn1 capacity=1 RUNNING
    [rg1-rn1] RUNNING

  sn=[sn2] zn:[id=1 name=Zone1] host-sn2 capacity=1 RUNNING
    [rg1-rn2] RUNNING

  sn=[sn3] zn:[id=1 name=Zone1] host-sn3 capacity=1 RUNNING
    [rg1-rn3] RUNNING
  ........

ノート:

この時点で、結合するプールはsnpoolという名前で、デプロイ先のゾーンのidは1です。

次に、新旧のSNが別の物理マシンで動作する本番環境では、通常、手順の最後のステップまで古いSNを稼働させたままにする(要求に対応する)ことを思い出してください。この例では、新旧のSNは単一のマシンで動作し、見た目上、別のマシンおよびファイル・システムであるかのようにシミュレートしています。このため、この例で次に実行するステップは、次のコマンドを実行してsn2ストレージ・ノードをプログラムで停止することです。 

> java -Xmx64m -Xms64m \
       -jar /opt/ondb/kv/lib/kvstore.jar stop \
       -root /opt/ondb/var/kvroot \
       -config config2.xml

sn2ストレージ・ノードを停止した後、(オプションで) show topologyコマンドを実行すると、sn2ストレージ・ノードがRUNNINGではなくUNREACHABLEになっていながら、ノードがトポロジから明示的に削除されるまで引き続きトポロジで参照されることを確認できます(次を参照)。たとえば、管理CLIから次のコマンドを実行します。 

kv-> show topology

次のような出力が生成されます。 

store=example-store numPartitions=300 sequence=308
  zn: id=1 name=Zone1 repFactor=3

  sn=[sn1] zn:[id=1 name=Zone1] host-sn1 capacity=1 RUNNING
    [rg1-rn1] RUNNING

  sn=[sn2] zn:[id=1 name=Zone1] host-sn2 capacity=1 UNREACHABLE
    [rg1-rn2] UNREACHABLE

  sn=[sn3] zn:[id=1 name=Zone1] host-sn3 capacity=1 RUNNING
    [rg1-rn3] RUNNING
  ........

この時点で、交換先である新しいsn4ストレージ・ノードの準備を始めることができます。つまり、この例では単一のマシンが新旧両方のSNのホストとなっているため、手順のステップ4、5、6はすでに完了しています。

次のステップ(7)に関して、この手順を使用する際、ステップ7では交換先のSNのデータ・ディレクトリのパスが交換対象のSNで使用されているパスと同じである必要があることを思い出してください。ただしこの例では、各SNによって格納されたデータの場所に同じディスクおよびファイル・システムを使用しています。このため、ステップ7で新しいsn4ストレージ・ノード用に作成するストレージ・ディレクトリはすでに存在し、古いsn2ストレージ・ノードによってすでに移入されています。したがって、この例のシミュレーション環境でステップ7を実行し、確認(次を参照)をサポートするには、上でsn2を停止した後、そのノードで使用されているストレージ・ディレクトリの名前を変更して、ステップ7でsn4用にプロビジョニングする必要があるストレージ・ディレクトリの領域を確保します。コマンドラインで次のように入力します。 

> mv /tmp/sn2 /tmp/sn2_old

ノート:

この名前変更ステップはこの例でのみ実行し、本番環境で実行することはありません。

次に、sn4が使用するストレージ・ディレクトリをプロビジョニングします。指定するパスは、sn2で使用されているストレージ・ディレクトリの元のパスと同じである必要があります。つまり、次のようになります。 

> mkdir -p /tmp/sn2/disk1/ondb/data

交換先のSNの準備を整えるときに次に実行するステップは、makebootconfigコマンド(文字列<host-ip>を必ず実際のIPアドレスまたはホスト名に置き換えてください)を実行して、新しいストレージ・ノードのブート構成を生成することです。 

java -Xmx64m -Xms64m \
-jar /opt/ondb/kv/lib/kvstore.jar makebootconfig \
     -root /opt/ondb/var/kvroot \
     -host <host-ip> \
     -config config4.xml \
     -port 13260 \
     -harange 13262,13265 \
     -memory_mb 100 \
     -capacity 1 \
     -admindir /opt/ondb/var/admin \
     -admindirsize 2000 MB \
     -storagedir /tmp/sn2/disk1/ondb/data \
     -rnlogdir /tmp/sn2/disk1/ondb/rnlog

新しいストレージ・ノードの構成ファイル/opt/ondb/var/kvroot/config4.xmlが生成されます。

前述の構成の作成後、その新しい構成を使用してKVStoreストレージ・ノード・エージェント(SNA)の新しいインスタンスをそのマネージド・サービスとともに起動します。つまり、次のようにします。

ノート:

SNAを起動する前に、環境変更MALLOC_ARENA_MAXを1に設定します。MALLOC_ARENA_MAXを1に設定すると、メモリー使用量が指定されたヒープ・サイズに制限されます。 

> nohup java -Xmx64m -Xms64m \
             -jar /opt/ondb/kv/lib/kvstore.jar start \
             -root /opt/ondb/var/kvroot \
             -config config4.xml &

前述のコマンドを実行した後、管理CLIを使用して次のコマンド(文字列<host-ip>を実際のIPアドレスまたはホスト名に置き換えます)を実行することで、新しいストレージ・ノードをデプロイします。 

kv-> plan deploy-sn -znname Zone1 -host <host-ip> -port 13260 -wait

前述のとおり、sn3は最近デプロイされたストレージ・ノードに(ストアによって)割り当てられたidであるため、次にデプロイされるストレージ・ノード(つまり前述のコマンドによってデプロイされるストレージ・ノード)にはその割当てidとしてsn4が付与されます。前述のsn4ストレージ・ノードをデプロイした後、(オプションで)管理CLIからshow poolsコマンドを実行すると、新しいストレージ・ノードがAllStorageNodesという名前のデフォルトのプールに結合されたことを確認できます。たとえば、次のようにします。 

kv-> show pools

次のような出力が生成されます。 

AllStorageNodes: sn1 sn2 sn3 sn4
snpool: sn1 sn2 sn3

デプロイ時点で、sn4はAllStorageNodesという名前のプールには結合されましたが、snpoolという名前のプールにはまだ結合されていません。

次に、sn4ストレージ・ノードを正常にデプロイした後、CLIを使用して次のようにsnpoolという名前のプールに結合します。 

kv-> pool join -name snpool -sn sn4

新しいストレージ・ノードをデプロイし、snpoolという名前のプールに結合した後、(オプションで)管理CLIを使用してshow topologyコマンド、show poolsコマンドを順に実行すると、新しいストレージ・ノードがストアにデプロイされ、snpoolという名前のプールに結合されたことを確認できます。たとえば、次のようにします。 

kv-> show topology 
kv-> show pools

初期の前提であれば、次のような出力が生成されます。 

store=example-store numPartitions=300 sequence=308
  zn: id=1 name=Zone1 repFactor=3

  sn=[sn1] zn:[id=1 name=Zone1] host-sn1 capacity=1 RUNNING
    [rg1-rn1] RUNNING

  sn=[sn2] zn:[id=1 name=Zone1] host-sn2 capacity=1 UNREACHABLE
    [rg1-rn2] UNREACHABLE

  sn=[sn3] zn:[id=1 name=Zone1] host-sn3 capacity=1 RUNNING
    [rg1-rn3] RUNNING

  sn=[sn4] zn:[id=1 name=Zone1] host-sn4 capacity=1 RUNNING
  ........

および 

AllStorageNodes: sn1 sn2 sn3 sn4
snpool: sn1 sn2 sn3 sn4

前述の出力は、sn4ストレージ・ノードが正常にデプロイされ(RUNNING)、snpoolという名前のプールのメンバーになったことを示しています。ただし、これにはまだsn4に対応するRNサービスが含まれていません。このようなサービスは、sn2がsn4に移行されるまでストアのトポロジには表示されません(次を参照)。

この時点では、sn4ストレージ・ノードをデプロイしてsnpoolという名前のプールに結合し、古いsn2ストレージ・ノードを停止すると、sn4はsn2の役割を引き継ぐ準備が整ったことになります。このためには、管理CLIから次のコマンド(文字列<host-ip>は必ず実際のIPアドレスまたはホスト名に置き換えてください)を実行して、sn2サービスおよびデータをsn4に移行します。 

kv-> plan migrate-sn -from sn2 -to sn4 -wait

sn2をsn4に移行した後、(オプションで)再度show topologyコマンドを実行すると、rg1-rn2サービスがsn2からsn4に移動してRUNNINGになっていることを確認できます。つまり、次のようにします。 

kv-> show topology 

store=example-store numPartitions=300 sequence=308
  zn: id=1 name=Zone1 repFactor=3

  sn=[sn1] zn:[id=1 name=Zone1] host-sn1 capacity=1 RUNNING
    [rg1-rn1] RUNNING

  sn=[sn2] zn:[id=1 name=Zone1] host-sn2 capacity=1 UNREACHABLE

  sn=[sn3] zn:[id=1 name=Zone1] host-sn3 capacity=1 RUNNING
    [rg1-rn3] RUNNING

  sn=[sn4] zn:[id=1 name=Zone1] host-sn4 capacity=1 RUNNING
    [rg1-rn2] RUNNING
  ........

最後に、移行プロセスが完了した後、古いsn2ストレージ・ノードをストアのトポロジから削除します。そのためには、管理CLIから次のようにplan remove-snコマンドを実行します。 

kv-> plan remove-sn -sn sn2 -wait

確認

sn2がsn4に正常に交換/アップグレードされたことを確認するには、まず、前述のとおり管理CLIから次のようにshow topologyコマンドを実行します。 

kv-> show topology

出力は次のようになります。 

store=example-store numPartitions=300 sequence=308
  zn: id=1 name=Zone1 repFactor=3

  sn=[sn1] zn:[id=1 name=Zone1] <host-ip> capacity=1 RUNNING
    [rg1-rn1] RUNNING

  sn=[sn3] zn:[id=1 name=Zone1] <host-ip> capacity=1 RUNNING
    [rg1-rn3] RUNNING

  sn=[sn4] zn:[id=1 name=Zone1] <host-ip> capacity=1 RUNNING
    [rg1-rn2] RUNNING
  ........

ここで、文字列<host-ip>のかわりに実際のIPアドレスまたはホスト名が表示されます。また、sn2ではなくsn4のみが出力に表示されます。

show topologyコマンドを実行するだけでなく、想定どおりのsn4ディレクトリ構造が作成されて移入されていること、つまり次のようなディレクトリおよびファイルが存在することも確認できます。 

/opt/ondb/var/kvroot
  ....
  config4.xml
  ....
  /example-store
    /log
      ....
      sn4*
      ....
    /sn4
      config.xml
      /admin2
        /env

/tmp/sn2/disk1/ondb/data
  /rg1-rn2
    /env
      00000000.jdb

また、sn2によって格納されていたデータがsn4に移行されたことを確認できます。つまり、次のようにします。 

> grep "HELLO WORLD" /tmp/sn2/disk1/ondb/data/rg1-rn2/env/00000000.jdb
  Binary file /tmp/sn2/disk1/ondb/data/rg1-rn2/env/00000000.jdb matches

ノート:

sn2は停止してトポロジから削除されましたが、この例でsn2が作成して移入したデータ・ファイルは削除されませんでした。それらは、/tmp/sn2_oldディレクトリに移動されました。このため、古いsn2ストレージ・ディレクトリおよびデータ・ファイルには引き続きアクセスできます。次のようになります。 

/tmp/sn2_old/disk1/ondb/data
  /rg1-rn2
    /env
      00000000.jdb

また、元のキー/値ペアは引き続き古いsn2データ・ファイルに存在します。次のようになります。 

> grep "HELLO WORLD" \
  /tmp/sn2_old/disk1/ondb/data/rg1-rn2/env/00000000.jdb
  Binary file 
  /tmp/sn2_old/disk1/ondb/data/rg1-rn2/env/00000000.jdb
  matches

最後に実行できる確認ステップは、新しいsn4ストレージ・ノードが古いsn2ストレージ・ノードの役割を引き継いだことを示すためのものです。このステップでは、新しいキー/値ペアをストアに書き込み、sn2を交換する前にはsn1、sn3、sn2で元々そうであったように新しいペアがsn1、sn3、sn4のデータ・ファイルに書き込まれていることを確認します。このステップを実行するために、最初のキー/値ペアを当初挿入したとき、設定での説明と同じ方法でKVStoreクライアント・シェル・ユーティリティを使用できます。つまり、次を実行できます(<host-ip>文字列は必ず実際のIPアドレスまたはホスト名に置き換えてください)。 

> java -Xmx64m -Xms64m \
-jar /opt/ondb/kv/lib/kvstore.jar runadmin\
       -host <host-ip> -port 13230 -store example-store

kv-> get -all
  /FIRST_KEY
  HELLO WORLD

kv-> put -key /SECOND_KEY -value "HELLO WORLD 2"
  Put OK, inserted.

kv-> get -all
  /SECOND_KEY
  HELLO WORLD 2
  /FIRST_KEY
  HELLO WORLD

挿入の実行後、grepコマンドを使用して、新しいキー/値ペアがsn1、sn3、sn4によって書き込まれたことを確認します。古いsn2データ・ファイルには引き続き最初のキー/値ペアのみが含まれています。つまり、次のようになります。 

> grep "HELLO WORLD 2" /tmp/sn1/dsk1/ondb/data/rg1-rn1/env/00000000.jdb
  Binary file /tmp/sn1/disk1/ondb/data/rg1-rn1/env/00000000.jdb matches
> grep "HELLO WORLD 2" /tmp/sn2/dsk1/ondb/data/rg1-rn2/env/00000000.jdb
  Binary file /tmp/sn2/disk1/ondb/data/rg1-rn2/env/00000000.jdb matches
> grep "HELLO WORLD 2" /tmp/sn3/dsk1/ondb/data/rg1-rn3/env/00000000.jdb
  Binary file /tmp/sn3/disk1/ondb/data/rg1-rn3/env/00000000.jdb matches
> grep "HELLO WORLD 2"
       /tmp/sn2_old/dsk1/ondb/data/rg1-rn2/env/00000000.jdb