DATACOPY_STREAM_COPY_WAIT_PARAM の設定について
18 views
Skip to first unread message
yoshida
Aug 5, 2010, 2:45:49 AM8/5/10
to roma-user-japan
初めまして
吉田と申します。
先日からOSS の分散KVS の検証として、ROMA の検証を行っています。
現在障害発生時の動作について検証を行っていますが、不明な点があります。
以下の点について、ご教授頂けますでしょうか？
[状況]
4台構成のroma Server にデータをセット後に2台のServer に障害が発生すると一部のData がlost する。
[環境]
server は、dcache01 ～ dcacahe04 の4台構成
OS：CentOS 5.3
Roma Version：0.8.4
[手順]
1) dcache01 で、Routing Table を作成
./bin/mkroute dcache01_11211 dcache02_11211 dcache03_11211
dcache04_11211
2) 作成しRouting Table を各サーバに配布
3) romad プロセスの起動
./bin/romad dcache01 -p 11211 -d → 各Server で起動
4) roma に10000 件のデータをセット
5) dcache04 のromad をkill
6) roma 上のデータを確認 → 全データにアクセス可能
7) dcache03 のromad をkill
8) roma 上のデータを確認 → 1538件のデータがアクセス不可
(data = rc.get(key) とした時に、data にnil が返される)
[教えて頂きたい事]
roma の冗長化係数 (routing.redundant) は2に設定されているので、4台中2台のServer が使用可能であれば、全デー
タにアクセス可能と思われます。
以下のマニュアルを確認したところ、DATACOPY_STREAM_COPY_WAIT_PARAM パラメータで、ノード間のデータコピーのウェイ
トタイムを制御できる記載を見つけました。
http://code.google.com/p/roma-prj/wiki/Configuration_jp
上記マニュアルには、初期値として60*60*24*5 (5日) が設定されているように記載されており、冗長性を担保するためのデータコピーが完了
しないうちにノード障害が発生したためData lost が発生したと判断しました。
しかし、stat コマンドで上記パラメータの設定値を確認すると、「0.0001」 となっています。
0.8.0 のソースをDownload して、config.rb を確認しましたが、同様に0.0001 を設定していました。
そこで、以下の点についてお教え下さい。
1) DATACOPY_STREAM_COPY_WAIT_PARAM パラメータの値は何が正しいのでしょうか？
2) DATACOPY_STREAM_COPY_WAIT_PARAM パラメータの意味は、以下のどちらでしょうか？
1. ノード障害検出後にデータコピーを開始するまでの待機時間
2. Network 負荷を抑えるために、1単位のデータコピー完了後に次のデータコピーを開始するまでの待機時間
3) ノード障害発生時に、データのリバランス処理はどのようなタイミングで動作するのでしょうか？
吉田と申します。
先日からOSS の分散KVS の検証として、ROMA の検証を行っています。
現在障害発生時の動作について検証を行っていますが、不明な点があります。
以下の点について、ご教授頂けますでしょうか？
[状況]
4台構成のroma Server にデータをセット後に2台のServer に障害が発生すると一部のData がlost する。
[環境]
server は、dcache01 ～ dcacahe04 の4台構成
OS：CentOS 5.3
Roma Version：0.8.4
[手順]
1) dcache01 で、Routing Table を作成
./bin/mkroute dcache01_11211 dcache02_11211 dcache03_11211
dcache04_11211
2) 作成しRouting Table を各サーバに配布
3) romad プロセスの起動
./bin/romad dcache01 -p 11211 -d → 各Server で起動
4) roma に10000 件のデータをセット
5) dcache04 のromad をkill
6) roma 上のデータを確認 → 全データにアクセス可能
7) dcache03 のromad をkill
8) roma 上のデータを確認 → 1538件のデータがアクセス不可
(data = rc.get(key) とした時に、data にnil が返される)
[教えて頂きたい事]
roma の冗長化係数 (routing.redundant) は2に設定されているので、4台中2台のServer が使用可能であれば、全デー
タにアクセス可能と思われます。
以下のマニュアルを確認したところ、DATACOPY_STREAM_COPY_WAIT_PARAM パラメータで、ノード間のデータコピーのウェイ
トタイムを制御できる記載を見つけました。
http://code.google.com/p/roma-prj/wiki/Configuration_jp
上記マニュアルには、初期値として60*60*24*5 (5日) が設定されているように記載されており、冗長性を担保するためのデータコピーが完了
しないうちにノード障害が発生したためData lost が発生したと判断しました。
しかし、stat コマンドで上記パラメータの設定値を確認すると、「0.0001」 となっています。
0.8.0 のソースをDownload して、config.rb を確認しましたが、同様に0.0001 を設定していました。
そこで、以下の点についてお教え下さい。
1) DATACOPY_STREAM_COPY_WAIT_PARAM パラメータの値は何が正しいのでしょうか？
2) DATACOPY_STREAM_COPY_WAIT_PARAM パラメータの意味は、以下のどちらでしょうか？
1. ノード障害検出後にデータコピーを開始するまでの待機時間
2. Network 負荷を抑えるために、1単位のデータコピー完了後に次のデータコピーを開始するまでの待機時間
3) ノード障害発生時に、データのリバランス処理はどのようなタイミングで動作するのでしょうか？
jun
Aug 5, 2010, 8:34:12 AM8/5/10
to roma-user-japan
こんにちは、鳥居と申します。
まず最初に冗長度とデータロストについてです。
冗長度を２に設定し４台構成で２台を停止するとデータロストが発生します。
ROMA の設定が意味する冗長度は、コピーを含めたデータ数です。
冗長度が２の場合、データは２つのサーバに存在します。
従って、２つのサーバを停止した場合、両サーバに配置されたデータは失われます。
次に、DATACOPY_STREAM_COPY_WAIT_PARAM についてです。
マニュアルの記述が間違っており混乱を招いてしまいすみません。
DATACOPY_STREAM_COPY_WAIT_PARAM の意味は、
2. Network 負荷を抑えるために、1単位のデータコピー完了後に次のデータコピーを開始するまでの待機時間
です。更にストレージへの負荷を抑えることも目的の一つです。
従って初期値は、config.rb の 0.0001 が正しいです。
ちなみに、デフォルト５日を設定しているのは STORAGE_DELMARK_EXPTIME になります。
ROMA はノード間のデータコピー中における削除の一貫性を保つために delete コマンドの
処理でデータを消さずに削除マークを付けます。
このパラメータはその削除マークを完全に消去する時間になります。
以上です。よろしくお願いします。
まず最初に冗長度とデータロストについてです。
冗長度を２に設定し４台構成で２台を停止するとデータロストが発生します。
ROMA の設定が意味する冗長度は、コピーを含めたデータ数です。
冗長度が２の場合、データは２つのサーバに存在します。
従って、２つのサーバを停止した場合、両サーバに配置されたデータは失われます。
次に、DATACOPY_STREAM_COPY_WAIT_PARAM についてです。
マニュアルの記述が間違っており混乱を招いてしまいすみません。
DATACOPY_STREAM_COPY_WAIT_PARAM の意味は、
2. Network 負荷を抑えるために、1単位のデータコピー完了後に次のデータコピーを開始するまでの待機時間
です。更にストレージへの負荷を抑えることも目的の一つです。
従って初期値は、config.rb の 0.0001 が正しいです。
ちなみに、デフォルト５日を設定しているのは STORAGE_DELMARK_EXPTIME になります。
ROMA はノード間のデータコピー中における削除の一貫性を保つために delete コマンドの
処理でデータを消さずに削除マークを付けます。
このパラメータはその削除マークを完全に消去する時間になります。
以上です。よろしくお願いします。
yoshida
Aug 5, 2010, 10:26:57 PM8/5/10
to roma-user-japan
鳥居様、
早速のご回答、ありがとうございます。
冗長度設定の件、理解しました。
細かい事で恐縮ですが、以下の点について確認させて下さい。
1) DATACOPY_STREAM_COPY_WAIT_PARAM パラメータの単位は、「秒」でしょうか？
2) 以下のWeb の記事を読むと、サーバ障害が発生した時に残ったサーバで円を作り直す
処理「フェイルオーバー」機能があると記載されています。
http://ascii.jp/elem/000/000/143/143399/
この時に、残ったサーバで冗長化を担保するようなデータの再配分処理は行われない
のでしょうか？
また、別のタイミングでデータの再配分処理が行われるとしたら、それはどのような
タイミングでしょうか？
3) サーバ障害が発生して一部のデータについて冗長化の担保ができなくなった場合、
手動でデータの再配分処理を行わせて、再度冗長化を担保させる事は可能でしょうか？
可能な場合は、その方法をお教え下さい。
4) 以下のWeb の記事を読むと、Roma はデータを両隣のサーバにも保持させる3重化の設計に
なっているとあります。
http://www.atmarkit.co.jp/news/200812/01/rakuten.html
http://stream.itmedia.co.jp/enterprise/pdf/pdf_15_1235709300.pdf
3重化の構成はデフォルトではなく、推奨構成と言う認識で宜しいでしょうか？
因みに、4台構成で4重化の設定を行った場合でもget/set は正常に動作する事を確認
したので、最大値では無いようです。
以上、宜しくお願いします。
早速のご回答、ありがとうございます。
冗長度設定の件、理解しました。
細かい事で恐縮ですが、以下の点について確認させて下さい。
1) DATACOPY_STREAM_COPY_WAIT_PARAM パラメータの単位は、「秒」でしょうか？
2) 以下のWeb の記事を読むと、サーバ障害が発生した時に残ったサーバで円を作り直す
処理「フェイルオーバー」機能があると記載されています。
http://ascii.jp/elem/000/000/143/143399/
この時に、残ったサーバで冗長化を担保するようなデータの再配分処理は行われない
のでしょうか？
また、別のタイミングでデータの再配分処理が行われるとしたら、それはどのような
タイミングでしょうか？
3) サーバ障害が発生して一部のデータについて冗長化の担保ができなくなった場合、
手動でデータの再配分処理を行わせて、再度冗長化を担保させる事は可能でしょうか？
可能な場合は、その方法をお教え下さい。
4) 以下のWeb の記事を読むと、Roma はデータを両隣のサーバにも保持させる3重化の設計に
なっているとあります。
http://www.atmarkit.co.jp/news/200812/01/rakuten.html
http://stream.itmedia.co.jp/enterprise/pdf/pdf_15_1235709300.pdf
3重化の構成はデフォルトではなく、推奨構成と言う認識で宜しいでしょうか？
因みに、4台構成で4重化の設定を行った場合でもget/set は正常に動作する事を確認
したので、最大値では無いようです。
以上、宜しくお願いします。
jun
Aug 5, 2010, 11:26:26 PM8/5/10
to roma-user-japan
鳥居です。
> 1) DATACOPY_STREAM_COPY_WAIT_PARAM パラメータの単位は、「秒」でしょうか？
単位は秒になります。
>2) 以下のWeb の記事を読むと、サーバ障害が発生した時に残ったサーバで円を作り直す
> 処理「フェイルオーバー」機能があると記載されています。
> http://ascii.jp/elem/000/000/143/143399/
> この時に、残ったサーバで冗長化を担保するようなデータの再配分処理は行われない
> のでしょうか？
> また、別のタイミングでデータの再配分処理が行われるとしたら、それはどのような
> タイミングでしょうか？
>3) サーバ障害が発生して一部のデータについて冗長化の担保ができなくなった場合、
> 手動でデータの再配分処理を行わせて、再度冗長化を担保させる事は可能でしょうか？
> 可能な場合は、その方法をお教え下さい。
ROMA はサーバ障害を検知するとフェイルオーバします。
ご指摘の通りフェイルオーバ後は冗長度が低いデータが発生します。
冗長度低下の有無は telnet をして stats と入力することで確認できます。
下記の routing.short_vnodes の値が 0 の場合は冗長度低下はありません。
routing.short_vnodes 0
この数値が 0 以上の場合は、その個数のバーチャルノードに配置されたデータの
冗長度が低下しています。その場合は、手動で telnet し recover と入力します。
recover コマンドのタイミングでデータの再配分が行われます。
recover 中に stats を打って頂けると、routing.short_vnodes の値が減っていく
様子が観測できます。0 になると再配分は終了します。
再配分の起動を自動化する機能はありません。もしも自動化する場合は、ユーザによる監視
ツールで routing.short_vnodes 等の値をチェックし recover を入力する様な物を
作り込んでください。
>4) 以下のWeb の記事を読むと、Roma はデータを両隣のサーバにも保持させる3重化の設計に
> なっているとあります。
> http://www.atmarkit.co.jp/news/200812/01/rakuten.html
> http://stream.itmedia.co.jp/enterprise/pdf/pdf_15_1235709300.pdf
> 3重化の構成はデフォルトではなく、推奨構成と言う認識で宜しいでしょうか？
> 因みに、4台構成で4重化の設定を行った場合でもget/set は正常に動作する事を確認
> したので、最大値では無いようです。
これらの記事は OSS として公開する前に書かれたもので、その後アーキテクチャが変更されています。
大きな変更点としてはバーチャルノードと言う概念を導入したことにあります。
これはハッシュ空間を細かく分割し仮想的な複数のバケツを作り、そこにデータを配置する方式です。
stats コマンドで見た routing.short_vnodes の vnodes はバーチャルノードの数を意味しています。
上記の資料では前後のノードに冗長データを保持するように書かれておりますが、現在はバーチャル
ノード単位に異なる任意のサーバに冗長化されるようになりました。
冗長度の設定は mkroute で経路表を作成する段階で任意の冗長度が設定可能です。
良く使われそうな２をデフォルトとしています。
冗長度の最大値はございませんが、あまり多いとレイテンシが大きくなりますのでご注意ください。
ROMA のネットワーク処理は ruby のコンテキストスイッチの影響を回避するために
リアクタモデルを採用しております。このモデルはコマンドを１スレッドで処理するもので、
そのトレードオフとして冗長化が非同期に行われません。２～３がお勧めです。
以上、よろしくお願いします。
> 1) DATACOPY_STREAM_COPY_WAIT_PARAM パラメータの単位は、「秒」でしょうか？
>2) 以下のWeb の記事を読むと、サーバ障害が発生した時に残ったサーバで円を作り直す
> 処理「フェイルオーバー」機能があると記載されています。
> http://ascii.jp/elem/000/000/143/143399/
> この時に、残ったサーバで冗長化を担保するようなデータの再配分処理は行われない
> のでしょうか？
> また、別のタイミングでデータの再配分処理が行われるとしたら、それはどのような
> タイミングでしょうか？
>3) サーバ障害が発生して一部のデータについて冗長化の担保ができなくなった場合、
> 手動でデータの再配分処理を行わせて、再度冗長化を担保させる事は可能でしょうか？
> 可能な場合は、その方法をお教え下さい。
ご指摘の通りフェイルオーバ後は冗長度が低いデータが発生します。
冗長度低下の有無は telnet をして stats と入力することで確認できます。
下記の routing.short_vnodes の値が 0 の場合は冗長度低下はありません。
routing.short_vnodes 0
この数値が 0 以上の場合は、その個数のバーチャルノードに配置されたデータの
冗長度が低下しています。その場合は、手動で telnet し recover と入力します。
recover コマンドのタイミングでデータの再配分が行われます。
recover 中に stats を打って頂けると、routing.short_vnodes の値が減っていく
様子が観測できます。0 になると再配分は終了します。
再配分の起動を自動化する機能はありません。もしも自動化する場合は、ユーザによる監視
ツールで routing.short_vnodes 等の値をチェックし recover を入力する様な物を
作り込んでください。
>4) 以下のWeb の記事を読むと、Roma はデータを両隣のサーバにも保持させる3重化の設計に
> なっているとあります。
> http://www.atmarkit.co.jp/news/200812/01/rakuten.html
> http://stream.itmedia.co.jp/enterprise/pdf/pdf_15_1235709300.pdf
> 3重化の構成はデフォルトではなく、推奨構成と言う認識で宜しいでしょうか？
> 因みに、4台構成で4重化の設定を行った場合でもget/set は正常に動作する事を確認
> したので、最大値では無いようです。
大きな変更点としてはバーチャルノードと言う概念を導入したことにあります。
これはハッシュ空間を細かく分割し仮想的な複数のバケツを作り、そこにデータを配置する方式です。
stats コマンドで見た routing.short_vnodes の vnodes はバーチャルノードの数を意味しています。
上記の資料では前後のノードに冗長データを保持するように書かれておりますが、現在はバーチャル
ノード単位に異なる任意のサーバに冗長化されるようになりました。
冗長度の設定は mkroute で経路表を作成する段階で任意の冗長度が設定可能です。
良く使われそうな２をデフォルトとしています。
冗長度の最大値はございませんが、あまり多いとレイテンシが大きくなりますのでご注意ください。
ROMA のネットワーク処理は ruby のコンテキストスイッチの影響を回避するために
リアクタモデルを採用しております。このモデルはコマンドを１スレッドで処理するもので、
そのトレードオフとして冗長化が非同期に行われません。２～３がお勧めです。
以上、よろしくお願いします。
yoshida
Aug 6, 2010, 4:40:37 AM8/6/10
to roma-user-japan
鳥居様、
早速のご回答、ありがとうございます。
フェイルオーバー時にデータの再分配が行われない件、理解しました。
冗長化係数=2, 4Node 構成から以下の確認を行った結果、データの再分配処理が
問題なく動作する事 (データ・ロスが発生しない事) が確認できました。
・1つのromad プロセスをkill
・stat コマンドでrouting.short_vnodes の値を確認
・recover コマンド実行
・routing.short_vnodes が0 になるまで待機
・データチェック
・別のromad プロセスをkill
・stat コマンドでrouting.short_vnodes の値を確認
・recover コマンド実行
・routing.short_vnodes が0 になるまで待機
・データチェック
素早いご対応、本当にありがとうございます。
> ...
>
> もっと読む ≫
早速のご回答、ありがとうございます。
フェイルオーバー時にデータの再分配が行われない件、理解しました。
冗長化係数=2, 4Node 構成から以下の確認を行った結果、データの再分配処理が
問題なく動作する事 (データ・ロスが発生しない事) が確認できました。
・1つのromad プロセスをkill
・stat コマンドでrouting.short_vnodes の値を確認
・recover コマンド実行
・routing.short_vnodes が0 になるまで待機
・データチェック
・別のromad プロセスをkill
・stat コマンドでrouting.short_vnodes の値を確認
・recover コマンド実行
・routing.short_vnodes が0 になるまで待機
・データチェック
素早いご対応、本当にありがとうございます。
>
> もっと読む ≫
Reply all
Reply to author
Forward
0 new messages