次のチャンネルに、DRBDの開発者も参加しています。and#clusterlabs.IRCを使って、DRBDの改善を提案したり、開発者レベルの議論をすることもあります。内容を提供してください。これらの情報がない場合には回答は困難です。公式twitterアカウントLINBITはツイッターをやっています。ハッシュタグをお使いください。資料DRBDの開発者により作成されたDRBD一般やDRBDの特定の機能についての文書が公開されています。その一部を次に示します。その他の資料Wikipediaにはhttp://en.wikipedia.org/wiki/DRBD[DRBDの記事]があります。websiteに、高可用性クラスタでDRBDを活用するための有益な情報があります。最近の変更この付録はDRBD9.0以前のバージョンからアップグレードするユーザー向けです。DRBDの設定と挙動についての重要な変更点を説明します。コネクションDRBD9では3台以上のノードでもデータのレプリケーションが可能です。そのためDRBDボリュームのスタック利用はもはや(可能ではありますが)推奨しません。client)として利用する事が可能になりました。最小限の情報のみを表示。再同期の同期元/先が複数の対向ノードに。スクリプトを無用にするものです。詳細はリソースの自動プロモーションを参照してください。パフォーマンスの向上DRBD9はパフォーマンスの面でも目覚ましく向上しました。ハードウェアによっては最大で100倍高速になります。8.3以前からの新しい概念です。DRBD8.4より前はリソースには1つのブロックデバイスだけしか設定できませんでしたので、DRBDデバイスとリソースには1対1の関係でした。DRBD8.4からは複数ボリューム(それぞれが1つのブロックデバイスと対応する)が、1つのレプリケーションコネクションを共有します。このレプリケーションコネクションが、1つのリソースに対応します。この結果、挙動においていくつか必要な変更点があります。udevシンボリックリンクの変更DRBDのudev統合スクリプトは個々のブロックデバイスノードを示すシンボリックリンクを管理します。ディレクトリにあります。追加することで更新する必要があります。参照されていれば、変更は必要ありません。設定上の構文の変更点このセクションでは構成における構文の変更点について扱います。パーサーは8.4より前の構文も受け付けて、内部で自動的に現在の構文に変換します。DRBD9の新機能を使わないのであれば、これまでの構文に変更を加える必要はありません。DRBD9自体は古い構文に対応していないので、新しい構文を使用することをお勧めします。多くのブール型設定オプションに対応しています。8.4より前の構文では、これらのブール型オプションは以下のようになっていました。{no-md-flushes;}}これには設定上の問題がありました。構成セクションにブール型変数を設定したいとき、その後で個々のリソースを上書きしていました。セクションからでも、これらオプションが操作しやすくなっています。セクションが使用できましたが、8.4では廃止されました。セクションに移動しました。8.4の構文では次のようになります。セクションではなくて単独で記載する必要がありました。DRBD8.4でこの変則がなくなりました。...}対応するDRBD8.4での設定は以下のようになります。セクションを導入しました。オプションは、このセクションに移動しました。オプションも同様にこのセクションに移動しました。...}対応するDRBD8.4での設定は以下のようになります。8.4より前では、リソースがオンラインまたはアクティブの状態では、レプリケーションプロトコルの変更は不可能でした。行わなければなりませんでした。8.4では即座にレプリケーションプロトコルの変更が行えます。一時的に接続を通常の同期レプリケーションから非同期レプリケーションのモードに変更することができます。8.4より前では、リソースがオンラインやアクティブの状態ではシングルプライマリからデュアルプライマリに変更したり戻したりする事はできませんでした。両ノードで実行する必要がありました。8.4ではオンラインで変更が行えます。このために、デュアルプライマリモードが一時的または永続的であることは区別されません。リソースがオンライン中にデュアルプライマリに変更する場合は、一時的なデュアルプライマリモードを参照してください。構文を使わなければなりませんでした。引き渡すオプションが使えるようになりました。<resource>古い構文もまだサポートされますが、使わないことを強くお勧めします。指定する必要があります。このため、リソースの同期を開始するために、次のコマンドは使えません。<resource>代わりに次のようなコマンドをご使用ください。いくつかのデフォルト値が更新されました。以前のデフォルト値の127は1237に変更になりました。これによりメタデータのディスク書き込み作業量の現象によるパフォーマンスの向上が可能になりました。この変更によりプライマリノードのクラッシュ時の再同期時間が長くなります。これはギガビットイーサネットと高帯域幅のレプリケーションリンクの一般化が関係しています。8.4ではデフォルトで有効になっています。クイック同期ビットマップ中のデータ転送量を大きく減らします。8.4ではデフォルトでI/Oスタックの上位レイヤにI/Oエラーを伝えない(detach))設定です。以前のバージョンではI/Oエラーを伝える(pass-on)設定でしたが、置き換わりました。ディスク状態に遷移し、対向ノードからのデータを提供します。8.4ではデフォルトで有効です。デフォルト設定は次の構成のようになっています。(前のバージョンでは255)これは理論的な限界であり、本番環境で使い切ることはないでしょう。OpenstackでのDRBDボリューム本章では永続的で冗長化され、しかも高性能なブロックストレージとしてDRBDをOpenstackで使用する方法について説明します。Openstack概要Openstackそれ自体は様々な個々のサービスから構成されています。DRBDと関連があるものは主にCinderとNovaの2つです。コンピュートサービスです。Novaは仮想マシンがボリュームを利用するための管理もします。DRBDストレージボリュームには2通りの方法でアクセスできます。iSCSIプロトコルを使用する方法(互換性最大)と、DRBDクライアント機能を使う方法(Openstackプロジェクトへ提出済)です。これら2つの方法の違いの詳細についてはトランスポートプロトコルの選択をご参照ください。ドライバはLibertyリリースからOpenstackのメインストリームになっています。これを動かすノードでdrbdmanageとDRBD9をインストールする必要があります。使用しているOpenstackによってパスやユーザー名等に少々違いがあります。次のように設定します。クラス名(最後の箇所)とファイルのパスから構成されます。[DEFAULT]enabled_backends=drbd-1[drbd-1]volume_driver=cinder.volume.drivers.drbdmanagedrv.DrbdManageIscsiDrivervolume_backend_name=DRBD-Manageddrbdmanage_redundancy=1iSCSIとDRBDトランスポートモードを使用の際にはトランスポートプロトコルの選択を参照のうえで選択してください。あわせて他の設定項目もご参照ください。バックエンド登録をします。サービスにユーザーがアクセスできるようにします。ファイルに以下を追加して拡張します。(USERをユーザ名で置き換えます。send_destination="org.drbd.drbdmanaged"/></policy>以上です。サービスを再起動すれば、DRBDボリュームが作成できます。下位デバイスの設定で、詳細な動作を調整するための、いくつかの追加設定を行うことができます。各ボリュームが2箇所に置かれます。レプリケーションが1回行われます。使用可能な空き容量が減ったとみなされます。2以上のデータのコピーを指定できます。上限の数はDRBD9と定義しているストレージホストの数によって制限されます。デフォルトでは各ボリュームはCinderコントローラーノードにマッピングされたDRBDクライアントを使用します。iSCSIエクスポートに使用する他に、デバッグ用途にも役立ちます。ような追加設定をすることができます。各ボリュームのリサイズ時、スナップショットまたは(新規またはスナップショットからの両方での)リソースの作成時の動作を設定します。以下のようなJSONブロックとして解析可能な文字列です。'60'}使用可能なポリシーや設定アイテムの詳細はデプロイを保留するポリシープラグインを参照してください。PythonのJSONパーサは厳密なものです。一例としてはシングルクォートの使用が必要です。JSONの仕様と制限によく注意してください。この目的で使用できる次のようなプラグインもあります。drbdmanage_resource_plugin、drbdmanage_snapshot_plugin。各新規作成ボリュームのDRBDの設定に使用できます。これらこれらには有効なデフォルト値がありますので、上書きしたい場合には再度追加を忘れないでください。これらはJSONブロックとして構文解析されます。デフォルトでは次のようになっています。ハイパーコンバージド構成のパフォーマンス最適化で使用します。設定は下位デバイスごとに行うことができます。トランスポートプロトコルの選択CinderでDRBDを動作させるには2つの方法があります。iSCSIエクスポート経由でアクセスするDRBDプロトコルを使って接続するこれらは排他的なものではありません。複数の下位デバイスがあるときには、ある下位デバイスはiSCSIを使って、他のものはDRBDプロトコルを使うといった事も可能です。iSCSIトランスポートCinderボリュームのエクスポートはデフォルトではiSCSI経由になっています。この場合には互換性が非常に高い長所があります。iSCSIはVMWare、Xen、HyperV、KVMなどすべてのハイパーバイザで使用することができます。欠点は、すべてのデーターがCinderノードに送信されますが、処理がユーザー空間のiSCSIデーモンによって行われるために、データがカーネルとユーザスペースの境界を通過する際の遷移でパフォーマンス低下が起きることです。DRBDトランスポートもう一つの方法は、DRBDプロトコルを使用して仮想マシンにデータを取得する方法です。DRBD9[21]はNovaノードにもインストールしてある必要があり、そのため現時点ではKVMが使用できるLinuxという制限があります。この方法の長所の一つは、仮想マシンによるストレージアクセス要求はDRBDカーネルモジュールを通じてストレージノードに送信され、直接割り当てられたLVにアクセスできる点です。カーネルとユーザー空間の遷移が起きないので、高いパフォーマンスを得ることができます。RDMAが使用できるハードウェアを使用すれば、仮想マシンがFC接続で直接下位デバイスにアクセスしているのと同等のパフォーマンスを得ることができます。DRBDの持つHA対策ソフトウェアというバックグラウンドが持つ長所を生かすことができます。複数ノード間で異なるネットワークコネクションを持つ事がきますので、単一障害点を回避して冗長性をもたせることができます。manageクラスタとしてのハイパーバイザーノードが必要です。nodes"で稼働させることができると、ハイパーバイザーノードの要求はDRBD9のカーネルモジュールとユーザー空間ツールだけになります。ストレージの節で使用するボリュームドライバを定義することができます。異なる下位デバイスの設定では異なるドライバを使用できます。2重の冗長性のiSCSI下位デバイス、2重の冗長性のDRBD下位デバイス、3重のDRBD下位デバイスを同時に定義することもできます。ボリューム作成時にこれらのストレージ下位デバイスを提供します、2つのドライバに使用ができる設定アイテムは、iSCSI用volume_driver=cinder.volume.drivers.drbdmanagedrv.DrbdManageIscsiDriverおよびDRBD用volume_driver=cinder.volume.drivers.drbdmanagedrv.DrbdManageDrbdDriver古いクラス名の"DrbdManageDriver"は、互換性の観点で残しており、単純なiSCSIドライバのエイリアスになっています。空き容量の通知Cinderドライバが報告する空き容量は、drbdmanage_redundancyの設定を使用してDRBDマネージから取得します。この時、このレプリケーションカウントで作成することができる最大ボリューム1つのサイズを返します。10個のストレージノードが各々1TiBの空き容量であり、冗長カウントが3であれば1TiBが返されます。ボリュームの割り当てを行っても、十分な空き容量のあるノードが3つ以上あるので、空き容量として返される値は変更されません。3の場合は10GiBが返されます。2の場合は15GiBが返されます。manageのストレージバックエンドに依存して)、またCinderボリュームから取得したスナップショットであるかによって複雑になります。詳細な情報についてはシンプロビジョニングについてのOpenstac仕様を参照ください。ストレージドライバアドオン]を通じたDRBDの使用について説明します。詳細なインストール手順や設定手順はドライバソースのhttps://github.com/OpenNebula/addon-drbdmanage/blob/master/README.md[README.md]を参照ください。OpenNebula概要OpenNebulaはアドオンで機能の拡張ができるオープンソースのクラウド管理プラットフォームです。Manageアドオンは、DRBDが下位デバイスとなってアタッチされた高可用性仮想マシンをDRBDトランスポートを通じてネットワーク上にデプロイします。Manageクラスタが必要です。Installation]を参照してください。Manageを使ったDRBDクラスタのインストールと設定は本書の[s-dm-init-cluster]を参照してください。OpenNebulaとDRBDクラスタは以下の例外を除いて互いに独立したものとすることができます。OpenNebulaのフロントエンドとホストノードは両クラスタに参加する必要がある。Manageのコントロールボリュームのローカルコピーを持っている必要がある。(DRBDトランスポート参照)。これらの機能はDRBDを既存のOpenNebulaクラスタへの追加手順を簡略化します。Manageクラスタに追加することもできます。ファイルを参照してください。Manageアドオンはcountおよびratioのデプロイポリシーにも対応しています。(デプロイを保留するポリシープラグイン参照)デフォルトではドライバは1つのアサインが有効になればデプロイが成功したと判断します。下にある設定ファイルを通じて使用されます。テンプレートで設定したポリシーは、設定ファイルで書かれた内容によって上書きされます。ライブマイグレーションライブマイグレーションは(この機能が有効になっていれば)、DRBDトランスポート経由でのローカルコピーを含まない全ノードへのイメージのアタッチに対応しています。これによって追加のストレージスペースを要せずクラスタ内の全ノードで使用可能になります。Manageを直接使ってアサインする必要があります。これは任意のVMをライブマイグレーション対象として後に有効になるハイパーバイザにコールドマイグレーションすることでも実現できます。あるかによって異なって計算されます。使用するデータストアでは、空き領域はリソースがデプロイされているノードのうち最も制限されているリソースプールにもとづいて通知されます。合計ストレージ容量が最小のノードの容量がデータストアの総容量の決定に使用され、最も少ない空き容量が残りのデータストアの空き容量に使用されます。使用するデータストアでは、容量と残りスペースはクラスタの合計ストレージを冗長レベルで割った容量にもとづいて決定されます。1つのノードに残っている空き容量よりも大きなが通知されることもあります。新規インストールの各100GiBの2ノードのストレージで冗長レベル1のクラスタであれば、200GiBのボリュームを使用できるノードがなくても、空き容量は200GiBになります。ドライバは新規イメージ作成時にこれを決定することができ、またユーザーに通知します。Dockerボリュームプラグイン]を使用したDRBDの使用方法を説明します。Docker概説Dockerは開発者やシステム管理者向けの、アプリケーションのビルドや、販売、実行環境を提供するオープンソースプラットフォーム(Linuxコンテナ)です。systemdがソケットを開いたデーモンです。Manageのリソースを管理します。Dockerボリュームプラグインをインストールする方法は、基本的に次の3通りあります。