1. 管理者ガイド
  2. Oracle NoSQL Databaseの監視
  3. ハードウェアの監視
  4. サーバー

サーバー

障害が発生したディスクほど一般的ではありませんが、特定のKVStoreデプロイメント(SN)を構成するサービスをホストするいずれかのマシンを管理者が置き換えることが必要になることはよくあります。マシン全体の置換が発生する可能性のある一般的なシナリオは、2つあります。1つ目は、1つ以上のハードウェア・コンポーネントに障害が発生し、障害の発生したコンポーネントを置き換えるよりも、単にマシン全体を置き換える方が便利またはコスト効率が高い場合です。2つ目は、稼働中の正常なマシンを、より大きく堅牢なマシン(より大きいディスクとより高いパフォーマンス特性を備えたマシンなど)にアップグレードする場合です。この項で示す手順は、既存のマシンを置換するために新しいマシンを準備するためのステップ、および既存のマシンをリタイアさせるためのステップについて説明することを目的としています。

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

Oracle NoSQL Databaseなどの分散型の場合、通常、ネットワークの停止とマシンの障害を区別することは困難です。NoSQL DatabaseのHAコンポーネントは、レプリケーション・ノードにアクセスできないことを検出して、これをイベントとして管理ログに記録します。ただし、このログ・イベントを検索すると、偽陽性が発生します。そのため、マシン/サーバーの障害を検出するには、JMXなどのシステム監視パッケージを使用することをお薦めします。

サーバー障害の解決

次に、2つの置換手順について説明します。どちらの手順も基本的には同じ結果となり、1つ以上のネットワーク・リストア・プロセスが実行されます(次を参照)。

最初に示す手順では、古いマシンは(当事者全員にとって)元のマシンとまったく同じように見えるマシンに置き換えられます。つまり、新しいマシンのホスト名、IPアドレス、ポートおよびSN IDは同じになります。これを2番目の手順と比較すると、古いマシンはストアのトポロジから削除され、別のマシンのように見える(ホスト名、IPアドレス、SN IDが異なる)マシンに置き換えられますが、動作は置換元のマシンの動作と同じになります。つまり、新しいマシンは、元のマシンと同じサービスを実行し、元のマシンとまったく同じデータを管理しますが、ネットワークやSN IDが異なることになります。したがって、最初のケースは、ハードウェアのみの置換とみなすことができます。つまり、ストアの視点からは、元のSNが一時的に停止して再起動されたことになります。新しいハードウェアは、ストアのトポロジに反映されません。それ以外の場合、元のSNは削除され、別のSNが元のSNの任務を引き継ぎます。ストアのコンテンツと動作は変更されませんが、ハードウェアにおける変更はストアの新しいトポロジに反映されます。

ストレージ・ノードを置き換えるときに使用する手順を決定する場合、その決定はストア管理者の判断に任されます。管理者によっては、常にいずれかの手順のみを使用することを好み、もう一方の手順を使用しないことがあります。いくつかの優先基準に基づくポリシーを確立する管理者もあります。たとえば、ハードウェアに障害が発生したためにSN置換を実行する必要がある場合には常に最初の手順を採用するが、正常なハードウェアをより新しい/優れたハードウェアにアップグレードする場合には常に2番目の手順を採用するポリシーが考えられます。最初のケースでは、障害が発生したSNは停止され、置換プロセス中は使用できません。2番目のケースでは、移行のために新しいマシンを準備している間も、置換元のマシンは稼働して使用可能な状態のまま維持でき、移行後、古いマシンを停止してトポロジから削除できます。

用語の確認

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

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

後述の説明には直接関係ありませんが、次に用語を示します。これは、完全性のためだけでなく、どのSN置換手順を採用するかを決定するとき、これらの用語の関連性を理解しておくと役立つことがあるためです。

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

SNホスト・マシンおよび特定のKVStoreにデプロイされた常駐SNAプロセスに関して、理解する必要がある2つの概念は、ストレージ・ノードのゾーンの概念とプールの概念です。どちらの概念も、ストアのSNをグループに編成するために使用されるメカニズムに対応しています。その結果、2つの概念間の区別は、次に示すようになります。

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

ゾーンとは対照的に、ストアにデプロイするのではなく、1つ以上のストレージ・ノード・プールを(オプションで)ストア内に作成できます。このようなプールを作成した後、デプロイされている任意のストレージ・ノードを、そのプールおよび作成されたその他のプールに結合するように構成できます。つまり、デプロイされたSNの非結合セットを含む1つ以上のゾーンでストアが構成されるゾーンとは異なり、ストアは、特定のSNをどのプールにいくつ結合するかについて制限のない1つ以上のプールで構成することもできます。すべてのストアは、デプロイされたすべてのストレージ・ノードが結合される、AllStorageNodesという名前のデフォルト・プールで自動的に構成されます。追加プールの作成はオプションとなり、特定のストレージ・ノードをどのプールに結合するかに関する決定と同様に、デプロイヤの判断に任されます。

前述した相違点の他に、ゾーンおよびプールを使用してストレージ・ノードのセットをグループ化する際に理解しておく必要のある、概念上の追加の相違点もあります。ゾーンは、物理的な境界をまたいで、ストアのノードの論理グループを表すために使用できますが、通常、デプロイヤは、ゾーンを実際の物理的な場所にマップします。たとえば、単一マシンに複数のSNAプロセスをデプロイし、各SNAを異なるゾーンにデプロイすることは可能ですが、より一般的には、1つのSNAを単一マシンにデプロイし、ストアのゾーンおよび各ゾーン内のSNマシンは、通常、なんらかの形式の障害分離を提供する物理的な場所に対応するように定義します。たとえば、建物の個別のフロアまたは数マイル離れた(あるいは国境を越えた)個別の建物に対応するように、各ゾーンを定義できます。

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

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

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

前提

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

  • 各マシンには、/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という名前になります。

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

  • 各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で実行されている管理サービスを次の手順で使用する必要があります。このため、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)の現在の構成を含むsn2-config.zipという名前の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. host-sn1から新しいhost-snにZIPファイルをコピーします。 

    > 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とは異なるネットワークおよびSN IDを持つ新しいSNをデプロイする方法について説明します。これにより、そのSNの任務とデータを引き継ぐことで、現在のSNの1つが実質的に置き換えられます。前述の手順とは異なり、この2番目の手順の実行時に満たす必要がある前提条件は、管理サービスの機能する定数が存在することのみです。また、前述の手順では、置換先SNの電源をオンにする前に、置換元SNを停止する必要があります(2つのSNでIDを共有しているため)。この場合、置換元SNは、プロセスの移行ステップ(置換先SNが置換元SNの任務を最後に引き継ぐステップ)まで稼働し続けます。したがって、必要に応じて、置換元SNを手順全体を通して停止できますが、置換先SNの準備中にリクエストの処理を続行できるように、そのSNを稼働したままにすることもできます。

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

  1. デプロイされたKVStoreの管理サービスを実行しているいずれかのマシンに対するネットワーク・アクセス権を持つ、Oracle NoSQL Databaseソフトウェアがインストールされているマシンから、管理CLIを起動し、該当の管理サービスに接続します。CLIを実行するマシンは、ストアを構成するマシンのいずれか(置換元のマシンも含む)、または別のクライアント・マシンにすることができます。たとえば、管理CLIがsn1ストレージ・ノードで起動され、そのCLIを同じsn1ホストで実行されている管理サービスに接続する必要がある場合、次のようなコマンドを、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

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

  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をpool joinコマンドで指定する必要があります(前述のsn4など)。ただし、plan deploy-snコマンドを検証すると、デプロイするSNに割り当てるIDが指定されていないことがわかります。これは、新しくデプロイされたSNに割り当てるIDを決定するのはKVStore自体(管理者ではなく)であるためです。したがって、この手順を示すために使用した例で、3つのストレージ・ノードのみが最初にデプロイされていたことを前提とした場合、次のストレージ・ノードをデプロイすると、システムでは、最近デプロイされたSN (この場合はsn3または3)に割り当てられたIDの整数コンポーネントを1つずつ増分し、その結果を使用して、デプロイされた次のSNに割り当てるIDを構成します。このため、上のpool joinコマンドに指定するIDは、sn4であると想定されます。ただし、割り当てられた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に移行します。これは、この場合、sn4に関連付けられたSNAおよび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

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

例

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

KVStoreが、前提の項と類似した方法でデプロイされていると想定します。具体的には、KVStoreが、最初にsn1、sn2およびsn3という名前の3つのストレージ・ノードを使用して、文字列<host-ip>で表される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

次に、Win_A、Win_BおよびWin_Cという3つのウィンドウを開きます。これらは、各ストレージ・ノードを実行する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ロード・スクリプトへの貼付けを容易にするために、CLIコマンド・プロンプト(kv->)は前述のコマンド・リストから除外されています。

前述のコマンドが完了したら(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

設定のこの時点で、各ファイルにはキー/値のペアは含まれません。データは、最も便利な方法でストアに書き込むことができます。しかし、この操作を非常に簡単に実行できるユーティリティとして、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を検索します。ほとんどの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>形式の文字列(後述の説明を参照)のいずれかによって特徴付けられます。

  • 文字列-class RepNodeおよび-service rg1-rn<id>形式の文字列で特徴付けられるRNサービス(<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つの管理サービスのデプロイメントが必要であることに注意してください。このような管理が複数デプロイされている場合、最初にデプロイされた管理が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
  ........

ここで、実際のIPアドレスまたはホスト名が文字列<host-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 2013-07-08 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でした。これら3つのSNがすべて同じKVROOTを使用してデプロイされたことで、sn1、sn2およびsn3の間で競合が発生し、これらのファイルに同じ名前が使用されたため、便宜上、このような処理が必要でした。この点を考慮して、上で実行されたgenerateconfigコマンドにより、config2.xmlではなく、新しいsn2の最上位の構成ファイルがデフォルト名(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
  ........

ここで、実際のIPアドレスまたはホスト名が文字列<host-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の任務の引継ぎ

この例では、既存の正常なストレージ・ノード(この場合はsn2)を、古いストレージ・ノードの任務を引き継ぐ新しいストレージ・ノードに置換/アップグレードするために、前述の2番目の置換手順が採用されています。前述したとおり、この例の前提および設定は、最初の例の前提および設定と同じです。したがって、以前に指定したとおりにこの例を設定した後、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は、手順の最後のステップまで稼働(リクエストを処理)したままとなることに注意してください。ただし、この例では、新しい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
  ........

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

次のステップ(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から次のコマンドを実行して、sn2のサービスおよびデータをsn4に移行します(文字列<host-ip>を実際のIPアドレスまたはホスト名に忘れずに置き換えてください)。 

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
  ........

ここでは、実際のIPアドレスまたはホスト名が文字列<host-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