drbdpool/thinpoolOpenStackはGiBでストレージサイズを測定します。リリースから正式に利用可能になります。いう単一のPythonファイルです。OpenStackのインストール形態によっては、インストール先が異なります。Cinderノードの適切な場所にインストールします。LINSTOR用の新しいバックエンドタイプを作成OpenStackコマンドライン用に環境変数を設定した後、これらのコマンドをCinderノードから実行します。GUIまたはコマンドラインを使用して、LINSTORバックエンドの新しいCinderボリュームを作成できます。コマンドラインを使用してボリュームを作成する際には、以下のガイドを参考にしてください。ドライバに何らかの定期的なエラーがないかどうか確認してください。キーワードが正常であるか。ログ出力を停止します。テストボリュームを作成します。ボリュームを表示します。トランスポートプロトコルの選択CinderでDRBD/LINSTORを実行するには、主に2つの方法があります。使うこれらは排他的ではありません。複数のバックエンドを定義し、それらのうちのいくつかはiSCSIを使用し、他のものはDRBDプロトコルを使用できます。iSCSIトランスポートCinderボリュームをエクスポートするデフォルトの方法は、iSCSI経由です。これにより最大の互換性が得られます。iSCSIは、VMWare、Xen、HyperV、またはKVMなどのあらゆるハイパーバイザーで使用できます。欠点は、すべてのデータを(ユーザースペースの)iSCSIデーモンで処理するためにCinderノードに送信する必要があることです。これは、データがカーネル/ユーザスペース境界を通過する必要があることを意味し、パフォーマンスに影響を与えます。DRBD/LINSTORトランスポートDRBDをトランスポートプロトコルとして使用してVMにデータを送信する方法もあります。9[2]もCinderノードにインストールする必要があることを意味します。トランスポートを使用すると、現時点でKVMを搭載したLinuxホストでのみでの配備に制限されます。この解決策の1つの利点は、VMのストレージアクセス要求がDRBDカーネルモジュールを介してストレージノードに送信され、ストレージノードが割り当てられたLVに直接アクセスできることです。これは、データパス上にカーネル/ユーザスペースの遷移がないことを意味し、結果的にパフォーマンスが向上します。RDMA対応のハードウェアと組み合わせると、FCバックエンドに直接アクセスするVMとほぼ同じパフォーマンスが得られます。1つの利点は、DRBDのHAバックグラウンドから暗黙的に利益を得ることです。複数のストレージノードを使用すると、異なるネットワーク接続で使用できる可能性があり冗長性を意味し、単一障害点を回避します。Cinderドライバのデフォルトの設定オプションは、CinderノードがディスクレスLINSTORノードであることを前提としています。変更して、Cinderサービスを再起動してください。LINSTORセクションで、使用するトランスポートプロトコルを定義することができます。この章の冒頭で説明した初期設定では、DRBDトランスポートを使用するように設定されています。必要に応じて以下のように設定することができます。その後、Horizon[3]は、ボリューム作成時にこれらのストレージバックエンドを提供する必要があります。これは単にiSCSIドライバのエイリアスです。0.6.5以降が必要である。iSCSIは互換性重視の場合使用する。ボリュームでは注意する。管理されているDockerのLINSTORボリュームについて説明します。Linuxコンテナの形でアプリケーションを開発、出荷、および実行するためのプラットフォームです。使用をサポートします。LINSTORクラスタから永続的ボリュームをプロビジョニングするDockerコンテナ用のボリュームドライバです。リポジトリを有効にする必要があります。パッケージをインストールしてください。linstor-docker-volumeあるいは、ソースからビルドしてインストールすることもできます。有効にして起動します。pythonライブラリを介してLINSTORコントローラと通信する必要があるので、プラグインの設定ファイルでLINSTORコントローラノードの場所を指定する必要があります。あるすべてのコマンドラインオプションを設定することも可能です。これは2つのディスクフルの複製です。Pluginの使用例です。なるクラスターを想定しています。Manageは論理ボリューム(LVM)とDRBDの設定ファイルの管理を行う抽象化レイヤーです。Manageの機能には、DRBDボリュームの作成、リサイズ、削除が含まれます。ManageはDRBD領域のスナップショット作成やボリューム作成も制御します。この章では一般的なオペレーションでの管理作業を説明します。トラブルシューティングについては扱いません。トラブルシューティングについては[ch-troubleshooting]を参照ください。セクションを読んでから、ここに戻ってきてください。クラスタに追加する移行スクリプトを生成できるサブコマンドが含まれています。移行はダウンタイムなしで実行できます。既存のリソースを移行する予定がない場合は、次のセクションに進んでください。クラスターが正常な状態にあるかどうかです。既存のクラスタデータベースをエクスポートすることができます。クライアントの入力として使うことができます。クライアントはただちにリソースを移行するのではなく、単にシェルスクリプトを生成するだけです。したがって、実際に実行する前に、移行アシスタントを複数回実行し、生成されたシェルスクリプトを確認/変更することができます。スクリプトはいくつかの質問をしてからシェルスクリプトを生成します。シャットダウンして、名前を変更しておきます。両方の種類のリソースファイルを使用してしまいます。サービスを開始する必要があります。クラスタノードで行われている必要があります。DRBD9のカーネルモジュールがインストールされてロードされている。インストールされている。toolsがインストールされている。その依存関係のあるパッケージがインストールされている。サーバコンポーネントの開始が必要な場合は、DRBDmanageがDBusアクティベーションを使用して行います。手動では行わないでください。ボリュームグループを作成します。なるボリュームグループを作成しています。クラスタノードで行います。/dev/sda7次に、クラスタ設定を全クラスタノードに配布するために使用する「コントロールボリューム」を作成します。ノードに複数のインターフェースがある場合は、DRBDが他のノードとの通信に使用するIPアドレスを指定する必要があります。ない場合にはIPアドレス指定は任意項目です。この作業は1つのノードで実行すれば十分です。使用するのがよいでしょう。オプションが設定されているか確認してください。設定はクラスタ設定で説明します。ノードの追加クラスタへのノードの追加は簡単で、コマンドを1つ、パラメータを2つ付けて実行するだけです。出力結果と一致していなければなりません。ノード名に対するIPアドレスをタブ補完することができます。ノードで実行されたものとします。ノードは自動的にクラスタに参加します。確認することができます。Manageが扱うノードは数種類あります。以下の図を見てください。DRBDのノードの種類ノードに種類がある理由は次の通りです。Manageクラスタは30ノード以下という制限があります。これは現在のDRBD9のレプリケーションするノード数に対する制限です。ManageはリソースごとにDRBD9のノード数の制限を受けます。サテライトのコンセプトは、この制限をクラスタを以下のように分けることで緩和するものです。コントロールボリュームへ直接アクセスできる。直接コントロールボリュームにアクセスすることはできないが、コントロールノードを通じてコントロールボリュームの内容を受け取ることができる。1つのコントロールノードは複数のサテライトノードに応答しますが、1つのサテライトノードは1つのコントロールにのみ割り当てられます。サテライトノードもDRBD9のリソースを共有することができます。以下の特徴があります。コントロールボリュームへ直接接続1つがリーダーの役割を担い、残りはサテライトノードの役割を担う。以下の特徴があります。コントロールノードへの直接のアクセスは不可。TCP/IPを通じてクラスタ設定を受け取る。以下の特徴があります。サテライトノードの追加これまでCharlieノードはクラスタに追加されていなかったものとします。以下のコマンドではCharlieを、alphaをコントロールノードとするサテライトノードとして追加しています。Manageは、ログレベルや使用するストレージプラグイン(LVM、ThinLV、ThinPoolなど)の多くの設定を行うことができます。実行すると表示されるエディタで行います。設定は何項目かに分けられます。セクションでオプション設定を行うと、この設定はクラスタ全体で有効になります。ノードごとやサイトごとの設定を行うことも可能です。オプション設定をグローバルセクションとノードセクションの両方に行った場合には、ノードセクションの設定が使用されます。オプションを指定してください。セクションを使用して指定することも可能です。その場合には、以下のように記述します。オプションを付けずに実行すると、グローバル、サイトごと、ノードごとの設定ができます。特定ノード用に実行することも可能です。このノードごとのビューでは、ストレージプラグインの設定で説明しているストレージプラグインの設定のような特定の設定も可能です。サブコマンドで設定します。したい場合には次のようにします。ファイルシステムのシグネチャ検出をサポートしています。機能はディストリビューションの間で異なります。オプションをサポートしています。一般的な強制フラグをサポートしているものはありません。既存のファイルシステムのシグネチャを検出すると、入力を促し処理を停止ししてしまいます。