1. ラン・ブック
  2. ハードウェア・モニタリング
  3. ハードウェア障害のモニタリング

ハードウェア障害のモニタリング

Oracle NoSQL Databaseの環境をモニタリングする際に考慮する様々なハードウェアのシナリオ/障害がいくつかあります。次の各項では、ネットワーク、ディスクおよびマシンの障害のモニタリング、およびこれらの障害とOracle NoSQL Databaseのログ・イベントとの相関について説明します。最後に、これらの障害シナリオからのリカバリ方法について説明します。

ネットワーク

パケットの損失、ラウンド・トリップの平均レイテンシ、およびネットワーク使用率をモニタリングすると、Oracle NoSQL Databaseのパフォーマンスや継続的な機能に影響を与える可能性のあるクリティカルなネットワーク・アクティビティを垣間見ることができます。Oracle NoSQL Databaseには、2つの重要なタイプのネットワーク・アクティビティがあります。クライアント・ドライバは、TCP/IP経由のJava RMIを使用して、アプリケーションを実行しているマシンと、NoSQL Databaseクラスタのノードを実行しているマシンの間の通信を行います。次に、クラスタ内の各ノードが相互に通信できる必要があります。レプリケーション・ノードは、TCP/IP経由のJava RMIを利用するとともに、TCP/IP経由のストリームベースの通信も利用します。管理ノードおよびストレージ・ノード・エージェントは、TCP/IP経由のRMIのみを利用します。操作ストアが予測可能なレイテンシおよびスループットを確実に維持できるようにするには、これらすべてのノードが通信する際に使用するネットワークの状態をモニタリングすることが重要です。

Oracle NoSQL Databaseが依存するネットワーク・インタフェースの状態をモニタリングするには、次のツールを使用することをお薦めします。

  • Sar、ping、iptraf – これらのオペレーティング・システム・ツールは、失われたパケット数、ラウンド・トリップ・レイテンシ、ネットワーク使用率などの重要なネットワーク統計を表示します。pingをスクリプト方式で使用して、ラウンド・トリップ・レイテンシ・およびパケットの損失をモニタリングし、sarまたはiptrafをスクリプト方式で使用してネットワーク使用率をモニタリングすることをお薦めします。目安としては、ネットワーク使用率が80%を超えたらアラートを発生させます。

  • Oracle NoSQL Pingコマンド – pingコマンドは、クラスタの各ノードへの接続を試みます。このコマンドの実行方法およびスクリプト化方法については、CLIコマンド・リファレンスを参照してください。

ネットワーク障害とNoSQLログ・イベントの関連付け

NoSQL Databaseの実行時操作に影響するネットワーク障害は、最終的にJavaのランタイム例外のインスタンスとしてログに記録されます。ログ・ファイル・モニタリングを使用すると、クリティカル・イベントとして認識される次の例外文字列が正規表現のリストに追加されます。これらのイベントのタイムスタンプをあらゆるネットワーク・モニタリング・ツールのタイムスタンプと関連付ける方法が現在採用されています。

注意:

次に示す例外のいずれかでログ・ファイルを検索する際は、ログ・レベルをチェックし、SEVEREのログ・レベルのみが考慮されるようにすることも必要です。これらの例外はINFOレベルでログに記録されます。これは、アプリケーションでエラーが発生しないことを示します。

  • UnknownHostException – 不適切に構成されたNoSQL DatabaseまたはDNSエラーが原因で、NoSQL Database内のノードのDNS参照が失敗しました。NoSQLクラスタがしばらく動作した後にこのエラーが発生した場合、アプリケーションとDNSサーバーの間でネットワーク障害が発生したことを示します。

  • ConnectException – クライアント・ドライバがNoSQL Databaseノードへの接続を開くことができません。ノードが接続中のポートでリスニングしていないか、ポートがファイアウォールによってブロックされています。

  • ConnectIOException – クライアントとサーバーの間で発生する可能性のあるハンドシェーク・エラー、またはネットワーク・レイヤーからのI/Oエラーを示します。

  • MarshalException – ネットワーク・レイヤーから発生する可能性のあるI/Oエラーを示します。

  • UnmarshalException – ネットワーク・レイヤーから発生する可能性のあるI/Oエラーを示します。

  • NoSuchObjectException – ネットワーク・レイヤーから発生する可能性のあるI/Oエラーを示します。

  • RemoteException – ネットワーク・レイヤーから発生する可能性のあるI/Oエラーを示します。

ネットワーク障害からのリカバリ

通常、NoSQL Databaseはネットワーク障害から再試行およびリカバリするため、データベース・レベルでの操作は必要ありません。ネットワーク障害のためにサービスのレベルが低下する可能性がありますが、ネットワーク・パーティションの障害によってNoSQL Databaseに障害が発生することはありません。

永続ストレージ

デプロイされたOracle NoSQL Databaseインスタンス(KVStoreと呼ばれることもあります)の管理中に発生する可能性がある最も一般的な障害シナリオの1つは、ディスクに障害が発生して交換が必要になるケースです。この場合のディスクは通常、ハード・ディスク・ドライブ(HDD)またはソリッド・ステート・ドライブ(SSD)です。HDDには、ストアで多数の書込みおよび読取りが実行され、ディスク上で膨大なバイト数が出入りしており、稼動し続ける多くの可動部品が採用されているため、ディスクの一部が簡単に摩耗および故障する可能性があります。SSDについては、稼働部品がないSSDはHDDより多少は破損しにくくなりますが、負荷が大きい環境下では、SSDも概して恒常的に障害が発生します。実際、このようなストアの規模が大きく、非常に多数のノードが含まれる場合、実質的にディスク障害が確実に発生するしきい値に到達します。この可能性は、ノードを構成する他のハードウェア・コンポーネントよりもはるかに高くなります。たとえば、そのようなシステムに関連するディスクは通常、システムのマザー・ボード、メモリー・チップ、さらにはネットワーク・インタフェース・カード(NIC)よりも頻繁に障害が発生します。

ディスク障害は非常に一般的であるため、ストアを継続的に動作させながら、障害が発生したディスクを交換するための明確な手順が用意されており、これにより、データの可用性が確保されます。

永続ストレージの障害の検出およびNoSQLログ・イベントへの関連付け

永続ストレージ・デバイスの障害を検出するために多くのベンダー固有のツールがあります。このマニュアルでは、ベンダー固有のメカニズムの推奨については触れません。ただし、障害が発生した永続ストレージ・デバイスを特定するために実行できる一般的な措置があります。

注意:

ログ・ファイル・モニタリングを使用すると、クリティカル・イベントとして認識される次の例外文字列が正規表現のリストに追加されます。これらのイベントのタイムスタンプをあらゆるストレージ・デバイス・モニタリング・ツールのタイムスタンプと関連付ける方法が現在採用されています。次に示す例外のいずれかでログ・ファイルを検索する際は、ログ・レベルをチェックし、SEVEREのログ・レベルのみが考慮されるようにすることも必要です。

  • /var/log/messages内のI/Oエラー – /var/log/messagesをモニタリングしてI/Oエラーが検出された場合、デバイスになんらかの問題があるために障害が発生する可能性があることを示します。

  • Smartctl – 可能な場合、smartctlツールは、永続ストレージ・デバイスの障害を検出し、障害の発生している特定のデバイスのシリアル番号を表示します。

  • EnvironmentFailureException – NoSQL Database (Berkeley DB Java Edition)のストレージ・レイヤーは、ストレージ・デバイスから検出されたJava IOExceptionsをEnvironmentFailureExceptionに変換します。この例外は、ログ・ファイルに書き込まれます。

ストレージ・デバイスの障害の解決

次の項では、2つの共通マシン構成用の手順について説明します。

KVStoreの実行中に障害が発生したディスクを交換する方法について理解するには、KVStoreによってどのようなデータがどこに格納されるかを確認します。これは、各マシンのディスク構成、ストアの容量やストレージ・ディレクトリの場所の構成方法によって異なります。ここで、KVStoreが3つのマシン(またはストレージ・ノード(SN))間で分散され、レプリケーション係数(RF)が3、各SNの容量が2、KVROOTが/opt/ondb/var/kvroot、ストア名が「store-name」に等しくなるよう構成されます。容量または各SNが2であるため、各マシンは2つのレプリケーション・ノード(RN)をホストします。つまり、各SNは2つのJava VMを実行し、それぞれが、ストアによって保持されているキー/値データのレプリケート済インスタンスを格納および取得するソフトウェア・サービス(RNサービス)を実行します。

あるデプロイメントで、マシン自体(SN)がそれぞれ3つのディスクで構成されており、別のデプロイメントでは、各SNがデータの書込みおよび読取りを行う単一のディスクのみを持っているとします。2番目(単一ディスク)のシナリオは、実験や「簡単な点検」の場合は問題ありませんが、本番環境では、ディスク障害や交換につながる可能性が高いため、この構成の使用はお薦めできません。特に、本番環境でデプロイヤが従う必要がある1つのルールとして、複数のRNサービスで同じディスクにデータを書き込むような構成はお薦めできません。ただし、デプロイヤがこのルールに反することを選択するような、一般的ではない状況が存在する可能性もあります。たとえば、(RAIDデバイスのように)ディスクの信頼性が非常に高く、高パフォーマンスで大容量であるために、このディスクを単一のRNサービスで使用すると、推奨される32GBヒープ制限を必ず超えてしまう場合などです。したがって、このような例外的な条件を満たすディスクで構成された環境でないかぎり、デプロイヤは常に、構成や管理のすべての情報、およびシステムで実行されている他のRNサービスにより格納されたデータとは別に、各RNサービスを専用のディスクで構成できるような環境を選びます。

以下に説明するように、各SNで複数のディスクを使用するようにKVStoreを構成するには、storagedirパラメータを採用して、使用可能な個別メディアを利用する必要があります。ここでは、複数ディスク・シナリオだけでなく単一ディスク・シナリオの説明においても、デプロイヤに対してstoragedirパラメータの使用をお薦めしています。ただし、単一ディスクの場合にこのパラメータを使用しても、(共通のデプロイメント・スクリプトを開発できるという点を除いて)デフォルトの場所を使用する場合と比較して大きな利点はありません。これを理解するために、まず、デフォルトのストレージの場所を使用する場合と、storagedirパラメータで指定したデフォルト以外の場所を使用する場合を比較してみます。

たとえば、(複数ディスク・シナリオまたは単一ディスク・シナリオで)デフォルトの場所を使用して(つまり、storagedirパラメータを指定せずに) KVStoreをデプロイしたとします。これは、どちらのシナリオにおいても、データはKVROOTの下(下の例では/opt/ondb/var/kvroot)に格納されることを意味します。どちらのシナリオでも、次のようなディレクトリ構造が作成され、移入されます。 

 - Machine 1 (SN1) -     - Machine 2 (SN2) -    - Machine 3 (SN3) -
/opt/ondb/var/kvroot   /opt/ondb/var/kvroot  /opt/ondb/var/kvroot
  log files             log files             log files
  /store-name           /store-name           /store-name
    /log                   /log                  /log
    /sn1                   /sn2                  /sn3
      config.xml             config.xml            config.xml
      /admin1                /admin2               /admin3
        /env                   /env                  /env

  /rg1-rn1                 /rg1-rn2                /rg1-rn3
    /env                     /env                    /env

  /rg2-rn1                 /rg2-rn2                /rg2-rn3
    /env                     /env                    /env

この構造を、KVStoreを複数ディスク・マシンにデプロイした場合に作成される構造と比較します(各マシンの3つのディスクの名前は/opt、/disk1および/disk2です)。makebootconfigユーティリティ(Oracle NoSQL Database管理者ガイドの第2章「インストール構成」を参照)を使用して、次のようなパラメータで初期ブート構成を作成したとします。 

> java -Xmx64m -Xms64m \
-jar KVHOME/lib/kvstore.jar makebootconfig \
       -root /opt/ondb/var/kvroot \
       -port 5000  \
       -host <host-ip>
       -harange 5010,5020 \
       -num_cpus 0  \
       -memory_mb 0 \
       -capacity 2  \
       -admindir /opt/ondb/var/admin \
       -storagedir /disk1/ondb/data \
       -storagedir /disk2/ondb/data \
       -rnlogdir /disk1/ondb/rnlog \
       -storagedir /disk2/ondb/rnlog

前述のようなブート構成では、各マシンに作成および移入されるディレクトリ構造は次のようになります。 

 - Machine 1 (SN1) -     - Machine 2 (SN2) -    - Machine 3 (SN3) -
/opt/ondb/var/kvroot   /opt/ondb/var/kvroot  /opt/ondb/var/kvroot
  log files             log files             log files
  /store-name           /store-name           /store-name
    /log                   /log                  /log
    /sn1                   /sn2                  /sn3
      config.xml             config.xml            config.xml
      /admin1                /admin2               /admin3
        /env                   /env                  /env

/disk1/ondb/data         /disk1/ondb/data        /disk1/ondb/data
  /rg1-rn1                 /rg1-rn2                /rg1-rn3
    /env                     /env                    /env

/disk2/ondb/data         /disk2/ondb/data        /disk2/ondb/data
  /rg2-rn1                 /rg2-rn2                /rg2-rn3
    /env                     /env                    /env

この場合、構成情報および管理データは、すべてのレプリケーション・データとは別の場所に格納されます。さらに、レプリケーション・データ自体は、個別の物理メディア上の各RNサービスに格納されます。つまり、各レプリケーション・グループ(またはシャード)の特定のメンバーによって格納されるデータは、グループの他のメンバーによって採用されたディスクとは別のディスクに格納されます。

注意:

前述のようにこれらの異なる場所にデータを格納すると、障害が分離されるため、通常はディスク置換が単純になり、時間も短縮されます。つまり、小さいディスクのほうが再移入にかかる時間が少ないため、小さいディスクの使用数を増やすことで、単一ディスク障害からのリカバリにかかる時間を大幅に短縮することが可能になります。ここだけでなく、Oracle NoSQL Database管理者ガイドの第2章「インストール構成」においても、前述したような個別の物理メディアまたはディスク・パーティションを利用する構成を強くお薦めしているのは、このような理由からです。

マシンに単一ディスクしか存在しない場合でも、デプロイヤは、複数ディスクの場合と同様の方法でstoragedirパラメータを使用して、レプリケートされたデータが格納される親ディレクトリとは別の親ディレクトリに構成データと管理データを格納できます。この方針はデフォルトではありませんが、単一ディスク・システムと複数ディスク・システムの間で簡単に共有できるデプロイメント・スクリプトを作成できるため、デフォルトの場所(KVROOT)を使用する方法よりも優先され、推奨手順とみなされることもあります。このデフォルトでない方針を採用するかどうかは単に選択肢の問題であり、複数ディスクの間で統一を図れること以外のメリットはありません。

したがって、単一ディスク・システムにこのような方針を適用しても、ディスク交換が簡単になるとはかぎりません。これは、その単一ディスクに障害が発生して交換が必要になった場合、RNにより書き込まれたすべてのデータが使用不可能になるだけでなく、構成(および管理)データも使用不可能になるためです。その結果、ディスクの交換後に(RN)リカバリ・プロセスで構成情報が必要になるため、以前に取得したバックアップからそのデータをリストアする必要があり、ディスク交換プロセスがはるかに複雑になることがあります。本番環境において一般に複数ディスク・システムが推奨されるのは、この理由からです。純粋にその使用方法が原因で、構成データやその他のシステム・データのみを格納するディスクよりもデータ・ディスクのほうが障害発生の確率がはるかに高いためです。

障害が発生した永続ストレージ・デバイスの交換手順

前述のstoragedirパラメータを使用して、KVStoreを(それぞれ3つのディスクで構成された)一連のマシンにデプロイしたとします。SN3のdisk2に障害が発生し、交換が必要になったとします。この場合、管理者は次の手順を実行します。

  1. 正常な管理サービスの1つを介して接続して、KVStore管理コマンドライン・インタフェース(CLI)を実行します。

  2. CLIから、次のコマンドを実行します。 

    kv-> plan stop-service-service rg2-rn3

    これによってサービスが停止します。その結果、システムがその特定サービスとの通信を試行する必要がなくなり、管理者がすでに認識している障害に関するエラーの出力量が減ります。

  3. OS、ディスク製造業者、ハードウェア・プラットフォームによって指定されている手順を使用して、disk2を削除します。

  4. 適切な手順を使用して、新しいディスクをインストールします。

  5. 以前と同じストレージ・ディレクトリ(つまり、/disk2/ondb/var/kvroot)になるように、新しいディスクをフォーマットします

  6. CLIから次のコマンドを実行します。verify configurationコマンドは、単に対象のRNが動作しているかを確認するためのものです。 

    kv-> plan start-service -service rg2-rn3 -wait
kv-> verify configuration

  7. リカバリ済のRNデータ・ファイルの内容(つまり、/disk2/ondb/var/kvroot/rg2-rn3/env/*.jdb )が想定どおりであることを確認します。

ステップ2で、idが3でid2のレプリケーション・グループに属するRNサービスは停止されます(rg2-rn3)。前述の手順を使用したときに停止される特定のRNサービスを判別するために、管理者は、どのマシンのどのディスクに障害が発生したかに関する知識、およびKVStoreのデプロイ中に作成されたディレクトリ構造に関する知識を組み合せます。この場合、管理者はまず標準システムのモニタリングおよび管理メカニズムを使用して、idが3のSNに対応するマシンでdisk2に障害が発生し、交換が必要であると判断します。前に示したディレクトリ構造を前提とすると、管理者には、このデプロイメントではストアにより、/disk2b/data/rg2-rn3/enの下にあるファイルを使用して、SN3マシンのdisk2にレプリケート済データが書き込まれることがわかっています。その結果、管理者は、障害ディスクを交換する前に、名前がrg2-rn3のRNサービスを停止する必要があると判断しました。

ステップ6でverify configurationコマンドを実行したときに、すでに停止していたRNサービスが正常に再起動された場合、このコマンドの出力にはサービスが正常に動作中であると示されますが、再起動されたRNでそのRNのデータが新しいディスクに完全に再移入されたとはかぎりません。これは、障害発生前にディスクに存在していたデータ量によっては、ディスクですべてのデータをリカバリするのに非常に時間がかかることがあるためです。新しいディスクへの再移入中に、追加のネットワーク・トラフィックおよび負荷が発生することがあります。

最後に、ステップ7は単なる健全性チェックであるため、オプションです。つまり、RNサービスが正常に再起動され、verify configurationコマンドでRNが正常であると報告された場合、このコマンドの結果は、ディスク交換が成功したことを示す十分な証拠とみなされます。前述のように、新しいディスクで一部のデータがまだ使用可能になっていなくても、リカバリ対象のRNのレプリケーション・グループ(シャード)の他のメンバーはそのデータを引き続き使用でき、そのデータは最終的に、想定どおり新しいディスクにレプリケートされて使用可能になります。

例

次に、前述のディスク交換のステップを使用して実践的な経験を得ることができる例を示します。この例は、単一ディスクを含む単一マシンを使用して複数ディスク・シナリオをシミュレートすることを目的としています。したがって、ディスクに実際に障害が発生したり、ディスクを物理的に交換することはありません。それでもなお、ディスクの交換時にデータが自動的にリカバリされる仕組みを把握できます。

簡略化のために、KVStoreが/opt/ondb/kvの下にインストールされており(つまり、KVHOME=/opt/ondb/kv)、さらにKVROOT=/opt/ondb/var/kvrootであるとします。つまり、まだこのディレクトリを作成していない場合は作成します。 

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

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

> mkdir -p /tmp/sn1/disk1/ondb/data
> mkdir -p /tmp/sn1/disk2/ondb/data

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

> mkdir -p /tmp/sn3/disk1/ondb/data
> mkdir -p /tmp/sn3/disk2/ondb/data

次に、3つのウィンドウ(Win_A、Win_BおよびWin_C)を開きます。これらは3台のマシン(SN)を表します。各ウィンドウでmakebootconfigコマンドを実行し、構成する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 2 \
     -admindir /opt/ondb/var/admin \
     -storagedir /tmp/sn1/disk1/ondb/data \
     -storagedir /tmp/sn1/disk2/ondb/data

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 2 \
     -admindir /opt/ondb/var/admin \
     -storagedir /tmp/sn2/disk1/ondb/data \
     -storagedir /tmp/sn2/disk2/ondb/data

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 2    \
     -admindir /opt/ondb/var/admin \
     -storagedir /tmp/sn3/disk1/ondb/data \
     -storagedir /tmp/sn3/disk2/ondb/data

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

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

生成された別々の構成を使用して、各ウィンドウからKVStoreストレージ・ノード・エージェント(SNA)の対応するインスタンスを起動します。

注意:

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を使用してストアを構成およびデプロイします。

管理CLIを起動するには、次のコマンドを実行します。 

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

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

configure -name store-name
plan deploy-zone -name Zone1 -rf 3 -wait
plan deploy-sn -zn 1 -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 -zn 1 -host <host-ip> -port 13240 -wait
plan deploy-admin -sn 2 -port 13241 -wait
pool join -name snpool -sn sn2
plan deploy-sn -zn 1 -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 100
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/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

キー/値ペアは、ストアに書き込まれるときに、特定のレプリケーション・グループ(シャード)に属する00000000.jdbという名前の(rf=3)ファイルそれぞれに格納されます。たとえば、単一のキー/値ペアがストアに書き込まれるとき、そのペアは次のいずれかのファイルに格納されます。 

/tmp/sn1/disk2/ondb/data/rg2-rn1/env/00000000.jdb
/tmp/sn2/disk2/ondb/data/rg2-rn2/env/00000000.jdb
/tmp/sn3/disk2/ondb/data/rg2-rn3/env/00000000.jdb

あるいは、次のファイルに書き込まれます。 

/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シェルを起動するには、ウィンドウから次のように入力します。

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

kv-> get -all
  0 Record returned.

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

kv-> get -all
  /FIRST_KEY
  HELLO WORLD

キー/値ペアがどのファイルに格納されていたかを判別するには、文字列"HELLO WORLD"をgrepで検索する方法が簡単です。これは、ほとんどのLinuxシステムのバイナリ・ファイルで動作します。このようにgrepコマンドを使用するのは、ほんの少量のデータで構成されている例では実践的です。 

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

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

上の例では、ストアに書き込まれたキー/値ペアは、2番目のシャードに属する各RNに格納されています。つまり、各RNは、idが2のレプリケーション・グループ(rg2-rn1、rg2-rn2およびrg2-rn3)のメンバーです。

注意:

ある特定のキーがどのシャードに関連付けられているかは、キーの値(具体的にはキーの値のハッシュ)と、ストアで管理されているシャードの数によって決まります。また、この例には00000000.jdbという名前のログ・ファイルが示されていますが、これらのファイルは、対応するRNサービスにより書き込まれたデータを含むこのような(多数存在する可能性がある)ログ・ファイルの最初の一部にすぎません。

現在のログ・ファイルが最大容量に達すると、書き込まれる新しいデータをすべて格納するための新しいファイルが作成されます。その新規ファイルには、前のファイルの接頭辞を増分することで前のファイルから導出された名前が付けられます。たとえば、00000997.jdb、00000998.jdb、00000999.jdb、00001000.jdb、00001001.jdbなどの名前がファイルに付与されます。

データがストアに書き込まれた後は、障害ディスクをシミュレートし、ディスク交換プロセスを実行できるようになります。障害ディスクをシミュレートするには、コマンド・ウィンドウから、キー/値ペアが書き込まれたストレージ・ディレクトリの1つを選択して、そのストレージ・ディレクトリを削除します。次に例を示します。 

> rm -rf /tmp/sn3/disk2

この時点で、SN3のログ・ファイルを調べると、例外が繰り返し記録されていることがわかります。次のようになります。 

> tail /opt/ondb/var/kvroot/store-name/log/sn3_0.log

rg2-rn3: ProcessMonitor: java.lang.IllegalStateException: Error occurred
accessing statistic log file
  /tmp/sn3/disk2/ondb/data/rg2-rn3/env/je.stat.csv.
.......

しかし、クライアント・シェルを使用して、以前に格納されたキー/値ペアを取得する場合、ストアは動作を継続し、書き込まれたデータも引き続き使用可能です。次のようになります。 

kvshell-> get -all
  /FIRST_KEY
  HELLO WORLD

これで、ディスク交換プロセスを実行できるようになります。KVStore管理CLIが実行されているコマンド・ウィンドウから、次のコマンドを実行します(前述のステップ2)。 

kv-> plan stop-service -service rg2-rn3
  Executed plan 9, waiting for completion...
  Plan 9 ended successfully

kv-> verify configuration
  .........
  Rep Node [rg2-rn3] Status: UNREACHABLE

停止したRNサービスを再起動しようとすると、失敗します。このことは、SN3のログ(file/opt/ondb/var/kvroot/store-name/log/sn3_0.log)の内容を確認するとわかります。このファイルの内容は、サービスの再起動が繰り返し試行されたが、ディレクトリがないため(つまり、障害ディスクが原因で)、サービスの起動を試行するたびに失敗して、プロセスがERROR状態になったことを示しています。 

kv-> show plans
  1 Deploy Zone (1) SUCCEEDED
  ......
  9 Stop RepNodes (9) SUCCEEDED
  10 Start RepNodes (10) ERROR

ここで、ディスクを交換する必要があります。ディスクの交換をシミュレートするために、交換ディスクをインストールしてフォーマットしたと同じ結果にする目的で、rg2-rn3の元の親ディレクトリを作成する必要があります。 

> mkdir -p /tmp/sn3/disk2/ondb/data

ディスクが交換されたことになるため、管理CLIからRNサービスの再起動が成功します。 

kv-> plan start-service -service rg2-rn3 -wait
  Executed plan 11, waiting for completion...
  Plan 11 ended successfully

kv-> verify configuration
  .........
  Rep Node [rg2-rn3] Status: RUNNING,REPLICA at sequence
  number 327 haPort:13254

データのリカバリが正常に完了したことを確認するには、再度"HELLO WORLD"をgrepで検索します。 

> grep "HELLO WORLD" /tmp/sn3/disk2/ondb/data/rg2-rn3/env/00000000.jdb
  Binary file /tmp/sn3/disk2/ondb/data/rg2-rn3/env/00000000.jdb matches

前述のディスク交換プロセスは、複数ディスクの場合よりデフォルト(および拡大解釈して単一ディスク)の場合のほうが複雑になる可能性があります。その理由を確認するために、デフォルトのストレージ・ディレクトリを使用して上の例を実行してみます。つまり、上のmakebootconfigコマンドの呼出しからstoragedirパラメータを削除します。これにより、ディレクトリ構造は次のようになります。 

/opt/ondb/var/kvroot   /opt/ondb/var/kvroot  /opt/ondb/var/kvroot
  log files              log files             log files
  /store-name            /store-name           /store-name
    /log                   /log                  /log
    /sn1                   /sn2                  /sn3
      config.xml             config.xml            config.xml
      /rg1-rn1               /rg1-rn2              /rg1-rn3
      /rg2-rn1               /rg2-rn2              /rg2-rn3

同様の例で、この場合の障害ディスクをシミュレートするために、ディレクトリ/opt/ondb/var/kvroot/sn3 (/admin3データベース、/rg1-rn3データベースおよび/rg2-rn3データベースの親)を削除します。

このディレクトリにはSN3の構成も含まれていることに注意することが重要です。SN3の構成情報はレプリケーション・ノード・データベースと同じ親(同じディスクに格納された情報と類似している)に含まれているため、前の例で行ったように障害ディスクが交換されると、SN3の構成は使用不可能になるため、RNサービスの再起動を試行すると失敗します。レプリケート済データはディスクの交換時にシステム内の他のノードから自動的にリカバリできますが、SNの構成情報は自動的にリカバリできません。このデータは、以前にバックアップしたコピーから手動でリストアする必要があります。このことは、別々のstoragedirパラメータを使用してKVROOTを各RNデータベースの場所から分離する、デフォルトでない単一ディスクの場合にも当てはまります。この場合は、レプリケート済データが別々の場所に格納されても、そのデータは同じ物理ディスクに格納されています。したがって、そのディスクに障害が発生した場合、手動で構成情報を交換ディスクに再インストールするまで、再起動しても構成情報は使用できません。