わずかなオーバヘッドが追加されますが、これは1%未満だと予測されます。ローカルディスクに書き込むだけのときと比べて約7%レイテンシが増加することになります。CPUのキャッシュミス、コンテキストスイッチなど、他にも待ち時間に影響する要因があります。一般的にマーケティングでは数字が小さくなったとは書かないものです。ような事を言うためIOPsは作られました。言い方を換えれば、IOPsとレイテンシは相互的なものです。レイテンシの測定で書いた方法は、純粋にシーケンシャルのシングルスレッドのIOロードのIOPsごとのレイテンシです。一方で、よくある他のドキュメントでは、見栄えのいい数字を出すために多重並行処理でのIOPsを使用している[14]という事を覚えておいてください。いったトリックを使うのなら、どんなIOPsにでもできます。そのため、シリアルのシングルスレッドでのレイテンシを敬遠しないでください。するなどの設定をしてください。した数字はデータベースに多数のクライアントからのコネクションが同時にあった場合など以外には、意味がないという事を覚えておいてください。CPUマスクの設定DRBDでは、カーネルスレッドの明示的なCPUマスクを設定できます。これは、CPUサイクルがDRBDと競合するアプリケーションの場合に特に役立ちます。CPUマスクは数字で、バイナリ表現の最下位ビットが第1のCPUを表し、その次のビットが第2のCPUを表します。ビットマスクの設定ビットは、対応するCPUがDRBDによって使用されていることを示し、クリアされたビットは使用されていないことを示します。)は、DRBDが第1のCPUだけを使用することを示します。)はDRBDが第3と第4のCPUを使用することを示します。次に、リソースのCPUマスク設定の例を示します。...}DRBDとこれを使用するアプリケーションとのCPU競合を最小限に抑えるためには、もちろん、DRBDが使用していないCPUだけをアプリケーションが使用するように設定する必要があります。一部のアプリケーションは、DRBD自体と同様に設定ファイルでこの設定を行うことができます。コマンドを呼び出す必要があります。複数のDRBDスレッドに同一のL2/L3キャッシュを使わせることは意味があります。CPU番号の物理パーティショニングとの関連付けは必要ありません。使うとトポロジーの概要を確認することができます。ネットワークMTUの変更レプリケーションネットワークの最大転送ユニット(MTU)サイズをデフォルトの1500バイトよりも大きくすることにはメリットがあります。MTUは、次のコマンドを使用して変更できます。DRBDのレプリケーションに使用するネットワークインタフェース名を指定します。I/Oスケジューラに指定する方がDRBDのレイテンシを小さくできることがあります。通常はCFQがデフォルトで有効になっています。仮想ファイルシステムを使用できます。<device>はDRBDが使用する下位デバイスです。スケジューラを有効にするには、次のコマンドを使用します。/sys/block/<device>/queue/scheduler次の値も設定することにより、さらに待ち時間を短縮できます。フロントマージを無効にします。deadlineを150ミリ秒にします(デフォルトは500ms)。/sys/block/<device>/queue/iosched/read_expire書き込みI/Oデッドラインを1500ミリ秒にします(デフォルトは3000ms)。/sys/block/<device>/queue/iosched/write_expire上記の値の変更により待ち時間が大幅に改善した場合は、システム起動時に自動的に設定されるようにしておくと便利です。設定ファイルでこの設定を行うことができます。オプションを渡します。背景情報を取り上げます。これは、DRBDの背景について関心のあるユーザーが対象です。DRBD開発者が参考にできるほど深い内容には踏み込んでいません。開発者の方は資料に記載の文章やDRBDのソースコードを参照してください。DRBDメタデータDRBDはレプリケートするデータに関するさまざまな情報を専用の領域に格納しています。メタデータには次のようなものがあります。格納する場所はリソースごとに設定できます。内部メタデータ内部メタデータを使用するようにリソースを設定すると、DRBDはメタデータを実際の本稼働データと同じ下位レベルの物理デバイスに格納します。領域がメタデータを格納するための領域として確保されます。メリットメタデータは実際のデータと密接にリンクされているため、ハードディスクに障害が発生しても、管理者は特に何かする必要はありません。メタデータは実際のデータとともに失われ、ともに復元されます。デメリットRAIDセットではなく、下位レベルデバイスが唯一の物理ハードディスクの場合は、内部メタデータが原因で書き込みスループットが低下することがあります。アプリケーションによる書き込み要求の実行により、DRBDのメタデータの更新が引き起こされる場合があります。メタデータがハードディスクの同じ磁気ディスクに格納されている場合は、書き込み処理によって、ハードディスクの書き込み/読み取りヘッドが2回余分に動作することになります。ない場合、DRBDリソースの作成時に、新しく作成されるメタデータによって下位レベルデバイスの末尾のデータが上書きされ、既存のファイルが破損します。以下のいずれかの方法でこれを避けることができます。下位レベルデバイスを拡張します。ボリューム管理機能を使用します。対応するボリュームグループに有効な空き領域が必要です。ハードウェアストレージソリューションを使用することもできます。下位レベルデバイスの既存のファイルシステムを縮小します。実行できない場合があります。代わりに外部メタデータを使用します。下位レベルデバイスをどの程度拡張するか、またはファイルシステムをどの程度縮小するかについては、メタデータサイズの見積りを参照してください。外部メタデータ外部メタデータは、本稼働データを格納するものとは異なる個別の専用ブロックデバイスに格納します。メリット一部の書き込み処理では、外部メタデータを使用することにより、待ち時間をいくらか短縮できます。デメリットメタデータが実際の本稼働データに密接にリンクされません。ハードウェア障害により本稼働データだけが破損したか、DRBDメタデータは破損しなかった場合、手動による介入が必要です。生き残ったノードから切り替えるディスクに、手動でデータの完全同期を行う必要があります。該当する場合には、外部メタデータ使用する以外の選択肢はありません。データが格納されており、この既存デバイスを拡張することができず、デバイスの既存のファイルシステムが縮小をサポートしていない。デバイスのメタデータを格納する専用ブロックデバイスが必要とするサイズにについては、メタデータサイズの見積りを参照してください。外部メータデータは少なくとも1MBのデバイスサイズを必要とします。メタデータサイズの見積り次の式を使用して、DRBDのメタデータに必要な領域を正確に計算できます。セクタ単位のデータデバイスサイズです。実行して取得できます。220または10242)実際には、次の計算で得られる大まかな見積りで十分です。この式では、単位はセクタではなくメガバイトである点に注意してください。(GI)を使用してレプリケートされたデータの「世代」を識別します。これはDRBDの内部メカニズムで、次のような目的で使用されます。(2つのノードが誤って接続されたものではないこと確認する)。部分的な再同期で十分か判断する。スプリットブレインを検出する。開始としてマークを付けます。デバイスの初期フル同期。切断したリソースがプライマリロールに切り替わる。プライマリロールのリソースが切断する。なると、両方のノードの現在のデータ世代が同一になります。現在はノードのロール(プライマリ/セカンダリ)を表すために最下位ビットを使用しています。そのため、同じデータ世代であってもあるノードでは最下位ビットが異なることがあります。データ世代は8バイトで定義される、全体でユニークな識別子(UUID)です。世代識別子タプルDRBDでは、現在と履歴のデータ世代についての情報がローカルリソースメタデータに格納されます。カレントUUIDこれは、ローカルノードからみた最新のデータ世代の世代識別子です。なり完全に同期されると、両ノードのカレントUUIDが同一になります。ビットマップUUIDリモードホストごとに変更を追跡しているオンディスクのビットマップの世代のUUIDです。オンディスク同期ビットマップ自体と同様に、リモートホストと切断されてい場合のみ意味を持ちます。履歴UUID現在のものより以前のデータ世代の識別子で、リモートホストごとに1スロットです。ノードが対向ノードへのコネクションを失うと、DRBDは次のようにしてローカルの世代識別子を変更します。新規データ世代の開始時に変化するGIタプルプライマリが新しいデータ世代用の新規UUIDを作ります。カレントUUIDになります。カレントUUIDはビットマップが変更を追跡している世代を参照します。したがって、これがプライマリノードの新しいビットマップUUIDになります。セカンダリノードではGIタプルは変化しません。再同期が完了すると、同期対象は同期元のGIタプルをすべて適用します。同期元は元のUUIDを維持し、新しいUUIDは作成しません。世代識別子とDRBDの状態ノード間の接続が確立すると、2つのノードは現在入手可能な世代識別子を交換し、それに従って処理を続行します。結果は次のようにいくつか考えられます。両ノードのカレントUUIDが空の場合ローカルノードと対向ノードの両方でカレントUUIDが空の状態です。新規に構成され、初回フル同期が完了していない場合は、通常この状態です。同期が開始していないため、手動で開始する必要があります。対向ノードのカレントUUIDが空で、自身は空でない場合です。これは、ローカルノードを同期元とした初期フル同期が進行中であることを表します。その後ローカルノードを同期元とした同期が始まります。逆の場合(ローカルのカレントUUIDが空で、対向ノードが空でない場合)は、DRBDは同様のステップをとります。ローカルノードが同期先になります。カレントUUIDが等しい場合ローカルのカレントUUIDと対向ノードのカレントUUIDが空でなく、同じ値を持っている状態です。両ノードがともにセカンダリで、通信切断中にどのノードもプライマリにならなかったことを表します。この状態では同期は必要ありません。ビットマップUUIDが対向ノードのカレントUUIDと一致する場合ローカルノードのビットマップUUIDが対向ノードのカレントUUIDと一致し、対向ノードのビットマップUUIDが空の状態です。これは、ローカルノードがプライマリで動作している間にセカンダリノードが停止して再起動したときに生じる正常な状態です。これは、リモートノードは決してプライマリにならず、ずっと同じデータ世代にもとづいて動作していたことを意味します。この場合、ローカルノードを同期元とする通常のバックグラウンド再同期が開始します。ビットマップがローカルノードのカレントUUIDと一致する状態の場合は、これはローカルノードの再起動に伴う正常な状態です。ローカルノードを同期先とする通常のバックグラウンド再同期が開始します。カレントUUIDが対向ノードの履歴UUIDと一致する場合ローカルノードのカレントUUIDが対向ノードの履歴UUIDのうちの1つと一致する状態です。これは過去のある時点では同じデータを持っていたが、現在は対向ノードが最新のデータを持ち、しかし対向ノードのビットマップUUIDが古くなって使用できない状態です。通常の部分同期では不十分なため、ローカルノードを同期元とするフル同期が開始します。DRBDはデバイス全体を非同期状態とし、ローカルノードを同期先とするバックグラウンドでのフル再同期を始めます。逆の場合(ローカルノードの履歴UUIDのうち1つが対向ノードのカレントUUIDと一致する)、DRBDは同様のステップを行いますが、ローカルノードが同期元となります。ビットマップUUIDが一致し、カレントUUIDが一致しない場合ローカルノードのカレントUUIDが対向ノードのカレントUUIDと異なるが、ビットマップUUIDは一致する状態はスプリットブレインです。データ世代は同じ親を持っています。この場合、設定されていればDRBDがスプリットブレイン自動回復ストラテジが実行されます。設定されていない場合、DRBDはノード間の通信を切断し、手動でスプリットブレインが解決されるまで待機します。これもスプリットブレインで、しかも過去に同一のデータ状態であったという保証もありません。したがって、自動回復ストラテジが構成されていても役に立ちません。DRBDはノード間通信を切断し、手動でスプリットブレインが解決されるまで待機します。最後は、DRBDが2つのノードのGIタプルの中に一致するものを1つも検出できない場合です。data"という警告をログに書き込んでコネクションを切断します。これは、相互にまったく関連のない2つのクラスタノードが誤って接続された場合に備えるDRBDの機能です。書き込み操作中に、DRBDは書き込み操作をローカルの下位ブロックデバイスに転送するだけでなく、ネットワークを介して送信します。実用的な目的で、この2つの操作は同時に実行されます。タイミングがランダムな場合は、書込み操作が完了しても、ネットワークを介した転送がまだ始まっていないといった状況が発生する可能性があります。その逆の場合もあります。この状況で、アクティブなノードに障害が発生してフェイルオーバが始まると、このデータブロックのノード間の同期は失われます。障害が発生したノードにはクラッシュ前にデータブロックが書き込まれていますが、レプリケーションはまだ完了していません。そのため、ノードが回復しても、このブロックは回復後の同期のデータセット中から取り除かれる必要があります。なくば、クラッシュしたノードは生き残ったノードに対して「先書き」状態となり、レプリケーションストレージの「オール・オア・ナッシング」の原則に違反してしまいます。これはDRBDだけでなく、実際、すべてのレプリケーションストレージの構成で問題になります。バージョン0.6以前のDRBDを含む他の多くのストレージソリューションでは、アクティブなノードに障害が発生した場合、回復後にそのノードを改めてフル同期する必要があります。バージョン0.7以降のDRBDは、これとは異なるアプローチを採用しています。アクティビティログ(AL)は、メタデータ領域にに格納され、「最近」書き込まれたブロックを追跡します。アクティブモードだったノードに一時的な障害が発生し、同期が行われる場合は、デバイス全体ではなくALでハイライトされたホットエクステントだけが同期されます。(それに加えて現在アクティブな対向ノードのビットマップのマークされたブロックも)これによって、アクティブなノードがクラッシュしたときの同期時間を大幅に短縮できます。アクティブエクステントアクティビティログの設定可能なパラメータに、アクティブエクステントの数があります。アクティブエクステントは4MiB単位でプライマリのクラッシュ後に再送されるデータ量に追加されます。このパラメータは、次の対立する2つの状況の折衷案としてご理解ください。大量のアクティビティログを記録すれば書き込みスループットが向上します。新しいエクステントがアクティブになるたびに、古いエクステントが非アクティブにリセットされます。この移行には、メタデータ領域への書き込み操作が必要です。アクティブエクステントの数が多い場合は、古いアクティブエクステントはめったにスワップアウトされないため、メタデータの書き込み操作が減少し、その結果パフォーマンスが向上します。アクティブエクステントが少ない場合アクティビティログが小さい場合は、アクティブなノードが障害から回復した後の同期時間が短くなります。アクティビティログの適切なサイズの選択エクステントの数は所定の同期速度における適切な同期時間にもとづいて定義します。アクティブエクステントの数は次のようにして算出できます。秒単位のターゲットの同期時間です。求めるアクティブエクステントの数です。スループット速度が200MiByte/秒のI/Oサブシステムがあり、同期速度(R)が60MiByte/sに設定されているとします。4分または240秒を維持する必要があります。同期速度とターゲット同期時間にもとづくアクティブエクステントの計算(例)また、最後に付け加えると、DRBD9ではデータを他のセカンダリノードへ同期させるので、セカンダリノードでもALを維持する必要があります。クイック同期ビットマップクイック同期ビットマップはDRBDが各対向ノードがリソースごとに使用する内部データ構造で、同期ブロック(両方のノードで同一)または非同期ブロックを追跡します。ビットマップはノード間通信が切断しているときのみ使われます。クイック同期ビットマップでは、1ビットが4KiBチャンクのオンディスクデータを表します。ビットがクリアされていれば、対応するブロックが対向ノードと同期しています。切断以降、ブロックに書き込まれていないということです。逆に、ビットがセットされていればブロックが変更されているため、接続が再確立したらすぐに再同期を行う必要があります。スタンドアロンノードでディスクにデータが書き込まれると、クイック同期ビットマップへの書き込みも始まります。ディスクへの同期的なI/Oは負荷が大きいため、実際にはメモリ上のビットマップのビットがセットされます。アクティビティログが期限切れになってブロックがコールドになると、メモリ上のビットマップがディスクに書き込まれます。ビットマップをディスクにフラッシュします。