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

ハードウェア障害の監視

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の場合は可動部品がないため、HDDより障害は発生しにくくなりますが、負荷が非常に高ければ同じように頻繁に障害が発生します。実際、このようなストアでノード(マシン)の数を非常に多くすると、ノードを構成する他のハードウェア・コンポーネントよりもはるかに高い確率で、ディスク障害がほぼ避けられない状況になることがあります。たとえば、このようなシステムに関連するディスクの障害発生頻度は、一般に、システムのマザー・ボードやメモリー・チップ、ネットワーク・インタフェース・カード(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が実行され、各Java VMでは、ストアで管理されているキー/値データのレプリケート済インスタンスを格納および取得する役割を担うソフトウェア・サービス(RNサービス)が実行されます。

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

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

たとえば、KVStoreが、複数ディスク・シナリオまたは単一ディスク・シナリオのいずれかで、デフォルトの場所を使用して(つまり、storagedirパラメータを指定せずに)デプロイされたものとします。この場合、どちらのシナリオにおいても、データは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 2のレプリケーション・グループに属するid 3のRNサービスは停止されます(rg2-rn3)。前述の手順を使用したときに停止される特定のRNサービスを判別するには、管理者は、どのマシンのどのディスクに障害が発生したか、またKVStoreのデプロイ中にどのようなディレクトリ構造が作成されたかを把握している必要があります。この特定のケースでは、管理者は、まず、標準のシステム・モニタリングおよび管理メカニズムを使用して、id 3のSNに対応するマシンでdisk2に障害が発生し、交換が必要であると判断しました。前に示したディレクトリ構造を前提とすると、このデプロイメントでは、ストアによりSN3マシンのdisk2の/disk2b/data/rg2-rn3/enの下にあるファイルを使用してレプリケート済データが書き込まれることがわかっています。その結果、管理者は、障害ディスクを交換する前に名前が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ロード・スクリプトへの貼付けを容易にするために、CLIコマンド・プロンプト(kv->)は前述のコマンド・リストから除外されています。

前述のコマンドが完了すると(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

この時点で、各ファイルにキー/値ペアは含まれていません。データは、最も便利な任意の方法でストアに書き込むことができます。しかし、この操作を非常に簡単に実行できるユーティリティとして、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データベースの場所から分離するような状況(デフォルトとは異なる)にも当てはまります。この場合は、レプリケート済データが別々の場所に格納されても、そのデータは同じ物理ディスクに格納されています。したがって、そのディスクに障害が発生した場合、手動で構成情報を交換ディスクに再インストールするまで、再起動しても構成情報は使用できません。