NoSQL Databaseのランタイム操作に影響を与えるネットワーク障害は、最終的にJavaランタイム例外のインスタンスとして記録されます。ログ・ファイル監視を使用して、クリティカル・イベントとして認識する必要のある正規表現のリストに次の例外文字列を追加できます。これらのイベントのタイムスタンプと任意のネットワーク監視ツールのタイムスタンプとの関連付けが使用されています。

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

永続ストレージ・デバイスの障害を検出するためのベンダー固有ツールや、同様の機能を実行するSNMP監視エージェントが多数あります。このドキュメントでは、ベンダー固有のメカニズムやSNMPベースの監視メカニズムをお薦めしていません。ただし、障害のある永続ストレージ・デバイスを特定するために実行できる一般的な手順がいくつかあります。

次の各項では、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パラメータで指定したデフォルト以外の場所を使用する場合とを比較してみます。

たとえば、(複数ディスク・シナリオまたは単一ディスク・シナリオで)デフォルトの場所を使用して(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 -jar KVHOME/lib/kvstore.jar makebootconfig \
-root /opt/ondb/var/kvroot \
-port 5000  \
-admin 5001 \
-host <host-ip>
-harange 5010,5020 \
-num_cpus 0  \
-memory_mb 0 \
-capacity 2  \
-storagedir /disk1/ondb/data \
-storagedir /disk2/ondb/data

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

 - 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サービスによって別々の物理メディアに格納されます。つまり、各レプリケーション・グループ(またはシャード)のあるメンバーによって格納されるデータは、グループの他のメンバーによって採用されたディスクとは別のディスクに格納されます。

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

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

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

手順2で、id2のレプリケーション・グループに属する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 -jar /opt/ondb/kv/lib/kvstore.jar makebootconfig \
-root /opt/ondb/var/kvroot \
-host <host-ip> \
-config config1.xml \
-port 13230 \
-harange 13232,13235 \
-admin 13231 \
-memory_mb 100 \
-capacity 2 \
-storagedir /tmp/sn1/disk1/ondb/data \
-storagedir /tmp/sn1/disk2/ondb/data

Win_B

java -jar /opt/ondb/kv/lib/kvstore.jar makebootconfig \
-root /opt/ondb/var/kvroot \
-host <host-ip> \
-config config2.xml \
-port 13240 \
-harange 13242,13245 \
-admin 13241 \
-memory_mb 100 \
-capacity 2 \
-storagedir /tmp/sn2/disk1/ondb/data \
-storagedir /tmp/sn2/disk2/ondb/data

Win_C

java -jar /opt/ondb/kv/lib/kvstore.jar makebootconfig \
-root /opt/ondb/var/kvroot \
-host <host-ip> \
-config config3.xml \
-port 13250 \
-harange 13252,13255 \
-admin 13251 \
-memory_mb 100 \
-capacity 2    \
-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)の対応するインスタンスを起動します。

Win_A

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

Win_B

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

Win_C

> nohup java -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 -jar /opt/ondb/kv/lib/kvstore.jar runadmin-host <host-ip>
-port 13230

管理CLIプロンプトからストアを構成およびデプロイします。

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

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

この時点で、各ファイルにキー/値ペアは含まれていません。データは、最も便利な任意の方法でストアに書き込むことができます。しかし、これを行うための便利なユーティリティの1つに、KVStoreクライアント・シェル・ユーティリティがあります。これは、目的のストアに接続して、対話型コマンドによってキー/値ペアの入力や取得を行うコマンドライン・インタフェースを表示するプロセスです。KVStoreシェルを起動するには、ウィンドウから次のように入力します。

> java -jar /opt/ondb/kv/lib/kvcli.jar \
-host <host-ip> -port 13230 -store store-name

kvshell-> get -all
0 Record returned.

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

kvshell-> 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)のメンバーです。

現在のログ・ファイルが最大容量に達すると、書き込まれる新しいすべてのデータを格納するための新しいファイルが作成されます。その新規ファイルには、前のファイルの接頭辞を増分することで前のファイルから導出された名前が付けられます。たとえば、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 Datacenter (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
      /admin1                /admin2               /admin3
      /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データベースの場所から分離する、デフォルトでない単一ディスクの場合にも当てはまります。この場合は、レプリケート済データが別々の場所に格納されても、そのデータは同じ物理ディスクに格納されています。したがって、そのディスクに障害が発生した場合、手動で構成情報を交換ディスクに再インストールするまで、再起動しても構成情報は使用できません。