オブジェクトは、Kubernetes/OpenShift、複製ブロックデバイス(DRBD)、NVMeOFターゲットなどLINSTORがエンドユーザーまたはアプリケーションに提示する最終結果です。

LINSTOR を使用してストレージボリュームを作成するには、LVM または ZFS のいずれかのボリュームマネージャーをシステムにインストールする必要があります。

LINBIT のお客様は、LINBIT で作成されたヘルパースクリプトをダウンロードし、ノードで実行して次のことができます。

LINBIT パッケージリポジトリを有効にすると、LINBT ソフトウェアパッケージ、DRBD カーネルモジュール、およびクラスターマネージャーや OCF スクリプトなどのその他の関連ソフトウェアにアクセスできるようになります。その後、パッケージマネージャーを使用して、インストール済みパッケージの取得、インストール、および更新の管理を行うことができます。

ノードを登録し drbd-9 LINBIT パッケージリポジトリを有効にすると、DEB、RPM、または YaST2 ベースのパッケージマネージャーを使用して LINSTOR と関連コンポーネントをインストールできます。

LINSTOR プロジェクトの GitHub ページは https://github.com/LINBIT/linstor-server です。

LINBIT には、LINSTOR、DRBD などのソースコードのダウンロード可能なアーカイブファイルもあります。 https://linbit.com/linbit-software-download-page-for-linstor-and-drbd-linux-driver/ から利用可能です。

クラスタ内にホット修復機能を備えたストレージしか持たないクラスタでは、物理的な下位デバイスごとに1つのストレージプールを作成するモデルを選択するのもよいかもしれません。このモデルの利点は、障害ドメインを単一のストレージデバイスに限定することです。

Exos と LVM2 の両方のストレージプロバイダーは、ストレージアレイとドライブに直接接続された複数のサーバーノードのオプションを提供します。 LVM2 では、外部ロックサービス（lvmlockd）が、vgcreate で –shared オプションを使用して作成されたボリュームグループを管理します。 --shared-space は、2 つ以上のノードがアクセスできる同じ LVM2 ボリュームグループを使用するように LINSTOR プールを構成するときに使用できます。以下の例は、ノード alpha および bravo がアクセスできるプールの共有スペース ID として LVM2 ボリュームグループ UUID を使用する方法を示しています。

Exos プールは、共有スペース識別子にデフォルトで Exos プールのシリアル番号を使用します。

linstor-server 1.5.2 以降および最新の linstor-client では、LINSTOR はサテライト上に LVM/ZFS プールを作成できます。 linstor-client には、次のように可能なディスクをリストしてストレージプールを作成するためのコマンドがあります。ただし、LVM/ZFS プールは LINSTOR によって管理されないので、削除コマンドはありません。そのため削除はノードで手動で実行する必要があります。

これはサイズと回転方式 (SSD/磁気ディスク) でグループ化された使用可能なディスクのリストを表示します。

次のフィルターを通過するディスクのみが表示されます。

create-device-pool コマンドを使用して、ディスク上に LVM プールを作成し、LINSTOR のストレージプールとして直接追加することもできます。

--storage-pool オプションを指定した場合、LINSTOR は指定した名前で storage-pool を作成します。

その他のオプションとコマンドの使用法については、linstor-client のヘルプを参照ください。

LINSTORは以下のストレージプラグインをサポートしています。

resource create コマンドでリソース定義を指定したノードに明示的に割り当てることができます。

` linstor resource create –auto-place` または linstor resource-definition auto-place コマンドを使用すると、LINSTORにノードとストレージプールを選択させて、リソースをデプロイすることができます。このセクションでは、例として resource create --auto-place コマンドを使用します。 しかし、どちらのコマンドを使っても、同じ結果を得ることができます。

以下の例では、--auto-place オプションの後の値が、LINSTORにいくつのレプリカを持たせたいかを伝えています。storage-poolオプションは明らかでしょう。

ストレージプール名がはっきりしない場合、--storage-pool を省略できます。この場合、LINSTORが以下のルールに基づいてストレージプールを選択します。

残りのストレージプールは、さまざまな方針によって評価されます。 LINSTORには現在4つの方針があります。

MaxFreeSpace : この方針は、ストレージプールの残りの空き領域に 1:1 のレートでマップしますが、実際に割り当てられたスペースのみを考慮します（シンプロビジョニングされたストレージプールの場合、新しいリソースを作成しなくても時間とともに増加する可能性があります）。 MinReservedSpace : “MaxFreeSpace” と異なり、この方針では、予約済みのスペースが考慮されます。これは、シンボリュームが限界に達する前の拡張できるスペースです。予約済みスペースの合計がオーバープロビジョニングになって、ストレージプールの容量を超える可能性があります。 MinRscCount : 指定されたストレージプールで、単純にすでにデプロイされているリソース数をカウントします。 MaxThroughput : この方針では、ストレージプールの Autoplacer/MaxThroughput プロパティがスコアのベースになります（プロパティが存在しない場合は 0 ）。特定のストレージプールにデプロイされたすべてのボリュームは、ストレージプールの最大スループットから定義された sys/fs/blkio_throttle_read および sys/fs/blkio_throttle_write の値が差し引かれます。結果のスコアはマイナスになる可能性があります。

各方針のスコアは正規化され、重み付けされ、合計されます。この場合、最小化方針のスコアが最初に変換され、結果として得られるスコアの全体的な最大化が可能になります。

方針の重みは、以下のコマンドで設定することができます。

ストラテジー名は上記のとおりで、ウェイトは任意の10進数でよい。

最後に、LINSTORはすべての要件を満たすストレージプールのベストマッチングを見つけようとします。このステップでは、 --replicas-on-same, --replicas-on-different, --do-not-place-with, --do-not-place-with-regex, --layer-list, --providers などの自動配置に関する制限も考慮されます。

次のコマンドを使用してリソース定義を削除できます:

これにより、指定されたリソース定義が LINSTOR クラスター全体から削除されます。リソースはすべてのノードから削除され、リソース エントリは LINSTOR のデータベース テーブルから削除するようにマークされます。LINSTOR がすべてのノードからリソースを削除した後、リソース エントリは LINSTOR のデータベース テーブルから削除されます。

警告: リソース定義に既存のスナップショットがある場合、そのスナップショットを削除するまでリソース定義を削除できません。詳細は Removing a Snapshot を参照ください。

次のコマンドを使用してリソースを削除できます:

リソース定義の削除とは異なり、このコマンドは、指定したノード (複数可) から LINSTOR リソースのみを削除します。リソースはノードから削除され、リソースエントリは LINSTOR のデータベーステーブルから削除するようにマークされます。LINSTOR がノードからリソースを削除した後、リソースエントリは LINSTOR のデータベーステーブルから削除されます。

LINSTOR リソースを削除すると、リソースを削除するだけでなく、クラスターに影響を与える可能性があります。たとえば、リソースが DRBD レイヤーによってサポートされている場合、3 ノード クラスタ内の 1 つのノードからリソースを削除すると、リソースに存在するクォーラム関連の特定の DRBD オプションも削除される可能性があります。このようなリソースを 3 ノードクラスタ内のノードから削除すると、リソースは 3 ノード クラスタ内の 2 つのノードにのみデプロイされるため、クォーラムがなくなります。

「linstor resource delete」コマンドを実行して単一ノードからリソースを削除すると、次のような情報メッセージが表示される場合があります。

また、リソース定義の削除とは異なり、リソースのストレージプールのスナップショットが存在している間にリソースを削除できます。リソースのストレージプールの既存のスナップショットは保持されます。

次のコマンドを使用して、リソースグループを削除できます。

このコマンドは指定されたリソースグループを削除します。リソース定義が関連付けられていない場合のみ、リソースグループを削除できます。削除しない場合、LINSTOR は次のようなエラー メッセージを表示します。

リソースグループを削除できるようにこのエラーを解決するには、関連するリソース定義を削除するか、リソース定義を別の (既存の) リソースグループに移動します。

次のコマンドを入力すると、リソース グループに関連付けられているリソース定義を見つけることができます。

高可用性ストレージを構成するには、LINSTOR 自体を使用します。これには、ストレージが LINSTOR の制御下にあり、たとえば新しいクラスターノードに簡単に拡張できるという利点があります。サイズが 200MB の新しいリソースを作成するだけです。これは次のようになります。ストレージプール名は環境に合わせて変更してください。

これ以降、リソース名は “linstor_db” であると仮定します。クラスターが自動クォーラム (自動クォーラムポリシー を参照) の対象になっていて io-error ポリシーを使用していることが重要です。また auto-promote を無効にします。

リソースが作成されたら、LINSTOR DB を新しいストレージに移動し systemd マウントサービスを作成します。後ほど drbd-reactor によって管理されるため、最初に現在のコントローラーを停止して無効にします。

/etc/systemd/system/var-lib-linstor.mount マウントファイルを linstor コントローラーのすべてのスタンバイノードにコピーします。繰り返しますが、これらのサービスを systemctl enable しないでください。これらは drbd-reactor によって管理されます。

次のステップは、”linstor_db” DRBD リソースにアクセスでき（DRBD ボリュームをマウントする必要があるため）、LINSTOR コントローラーになる可能性のあるすべてのノードに LINSTOR コントローラーをインストールすることです。コントローラが drbd-reactor によって管理されていることが重要なので、すべてのノードで linstor-controller.service が無効になっていることを確認してください。すべてのクラスターノードで systemctl disable linstor-controller を実行し、前の手順で現在実行しているノードを除くすべてのノードで systemctl stop linstor-controller を実行します。また、LINSTOR バージョン 1.14.0 以上を使用している場合、すべての潜在的なコントローラーノードで chattr +i /var/lib/linstor を設定してください。

マウントサービスと linstor-controller サービスの開始と停止には drbd-reactor を使用します。LINSTOR コントローラーになる可能性のあるすべてのノードにこのコンポーネントをインストールし、それらの /etc/drbd-reactor.d/linstor_db.toml 構成ファイルを編集します。次のような有効な promoter プラグインセクションが含まれている必要があります。

要件によっては on-stop-failure と stop-services-on-exit アクションを設定します。

その後 drbd-reactor を再起動し、構成したすべてのノードで有効にします。

systemctl status drbd-reactor` を実行して、ログに drbd-reactor サービスからの警告がないことを確認してください。 すでにアクティブなLINSTORコントローラがあるので、そのままの状態を維持することができます。 drbd-reactorctl status linstor_db` を実行して、linstor_dbターゲットユニットの状態をチェックします。

最後のステップですが、それでも重要なのは、LINSTORサテライトサービスの 起動時にLINSTORコントローラDBのリソースファイルを削除しない（そして再生成する） ように設定することです。サービスファイルを直接編集するのではなく、systemctl edit を 使用してください。LINSTORコントローラになる可能性があり、LINSTORサテライトでもある全てのノードでサービスファイルを編集してください。

この変更後、すべてのサテライトノードで systemctl restart linstor-satellite を実行する必要があります。

注意: LINSTORクライアントの使用 にあるように、LINSTORクライアントを 複数のコントローラで使用できるように設定し、 統合プラグイン（例えば、Proxmoxプラグイン）も複数のLINSTORコントローラに 対応するように設定されていることを確認してください。

NVMe-oF/NVMe-TCP により、LINSTOR はデータが NVMe ファブリックを介して格納されているリソースを持つノードにディスクレスリソースとして接続することができます。これにより、ネットワークを介してデータにアクセスすることで、ローカルストレージを使用せずにリソースをマウントできるという利点が得られます。この場合、LINSTORはDRBDを使用していないため、LINSTORによってプロビジョニングされたNVMeリソースは複製されず、データは1つのノードに格納されます。

LINSTORで NVMe-oF/NVMe-TCP を使用するには、サテライトとして機能し、リソースとして NVMe-oF/NVMe-TCP を使用するすべてのノードで nvme-cli パッケージをインストールする必要があります。

NVMe-oF/NVMe-TCP を使用するリソースを作成するには、resource-definition を作成するときに追加のパラメータを指定する必要があります。

デフォルトの NVMe-oF の代わりに NVMe-TCP を使用するには、次のプロパティを設定する必要があります。

プロパティ NVMe/TRType は、リソースグループまたはコントローラーレベルで設定することもできます。

次に、リソース用の volume-definition を作成します。

ノード上にリソースを作成する前に、データがローカルに格納される場所と、どのノードがネットワーク経由でそれにアクセスするかを確認します。

まず、データを保存するノードにリソースを作成します。

ネットワーク上でリソースデータにアクセスするノードでは、リソースをディスクレスとして定義する必要があります。

これでリソース nvmedata をノードの1つにマウントできます。

バージョン1.5.0 以降、LINSTOR で追加のレイヤー openflex を使用できます。LINSTOR の観点から見ると、 OpenFlex Composable Infrastructure は、LVM のようなストレージレイヤーとして機能する結合レイヤーの役割を果たします。また、割り当てられたスペースを NVMe ターゲットとして提供します。OpenFlex には REST API があり、LINSTOR で操作できます。

OpenFlex は LINSTOR ストレージと NVMeレイヤー の概念を組み合わせているため、LINSTOR は、ストレージプール用の新しいストレージドライバーと、前述の REST API を使用する専用の openflex レイヤーの両方に追加されました。

LINSTOR が OpenFlex-API と通信するためには、LINSTOR はいくつかの追加のプロパティを必要とします。これらのプロパティを controller レベルで一度設定することで、LINSTOR クラスター全体に反映できます。

これらが設定されたら、OpenFlex アーキテクチャの LINSTOR オブジェクトを作成できます。LINSTOR オブジェクトの OpenFlex オブジェクトへの理論的なマッピングは次のとおりです。OpenFlex ストレージプールは LINSTOR ストレージプールで表されます。LINSTOR ストレージプールの上の次のものはすでにノードであるため、LINSTOR ノードは OpenFlex ストレージデバイスを表します。ストレージデバイスの上の OpenFlex オブジェクトは LINSTOR によってマップされません。

NVMe を使用する場合、LINSTOR は NVMe ターゲットと NVMe イニシエーター側の両方で実行するように設計されています。 OpenFlex の場合、LINSTOR は OpenFlex によって完全に管理されるため、NVMeターゲット側で実行しません（実行する必要はありません）。LINSTOR は OpenFlex 対応物を表すためのノードとストレージプールを必要とするため、1.0.14 以降、特別なノードを作成するコマンドが LINSTOR クライアントに拡張されました。このコマンドは、追加で必要な構成データを受け入れるだけでなく、すでに実行中のコントローラインスタンスの他に “特別なサテライト” も起動します。この特別なサテライトは完全に LINSTOR で管理され、コントローラがシャットダウンするとシャットダウンされ、コントローラが起動すると再び起動されます。

OpenFlexストレージデバイスを表す “特別なサテライト” を作成するための新しいクライアントコマンドは次のとおりです。

引数は次のとおりです。

構成の最後のステップは、LINSTOR ストレージプールの作成です。

LINSTOR で必要なストレージプールをすべて作成したら、次の手順は、LINSTOR で NVMe リソースを使用する場合と同様です。以下は完全な例です。

DM-Writecache デバイスは、ストレージデバイスとキャッシュデバイスの2つのデバイスで構成されます。 LINSTORはそのような書き込みキャッシュデバイスをセットアップできますが、ストレージプールやキャッシュデバイスのサイズなどの追加情報が必要です。

例で設定されている2つのプロパティは必須ですが、コントローラレベルで設定することもできます。これは、 --layer-list に WRITECACHE が含まれるすべてのリソースのデフォルトとして機能します。ただし、 Writecache/PoolName は対応するノードに依存することに注意してください。ノードに pmempool という名前のストレージプールがない場合は、エラーメッセージが表示されます。

DM-Writecache に必要な4つの必須 パラメーターは、プロパティを介して設定されるか、LINSTORによって計算されます。上記のリンクにリストされているオプションのプロパティは、プロパティを介して設定することもできます。 Writecache/* プロパティキーのリストについては、 linstor controller set-property --help を参照ください。

外部メタデータを使用するようにDRBDを設定しているときに --layer-list DRBD、WRITECACHE、STORAGE を使用すると、外部メタデータを保持するデバイスではなく、下位デバイスのみが書き込みキャッシュを使用します。

LINSTOR は DM-Cache デバイスをセットアップすることもできます。これは前のセクションの DM-Writecache によく似ています。主な違いは、キャッシュデバイスが 3 つのデバイスで構成されていることです。1 つのストレージデバイス、1 つのキャッシュデバイス、1 つのメタデバイスです。LINSTOR プロパティは書き込みキャッシュのプロパティと非常に似ていますが、Cache 名前空間にあります。

Cache/* プロパティと省略されたプロパティのデフォルト値のリストについては linstor controller set-property --help を参照ください。

外部メタデータを使用するようにDRBDを設定しているときに --layer-list DRBD,CACHE,STORAGE を使用すると、外部メタデータを保持するデバイスではなく、下位デバイスのみがキャッシュを使用します。

ストレージレイヤーは、LVM、ZFS などのよく知られたボリュームマネージャーからの新しいデバイスを提供します。リソースがディスクレスである必要がある場合（そのタイプは専用の「ディスクレス」プロバイダータイプ）でも、すべてのレイヤーの組み合わせはストレージレイヤーに基づく必要があります。

プロバイダーのプロパティについては Storage Providers を参照ください。

一部のストレージプロバイダー用に、LINSTOR には特別なプロパティがあります。

リモート SPDK のストレージプールは、特別なサテライトでのみ作成できます。最初に次のコマンドを使用して新しいサテライトを開始する必要があります。

これにより、コントローラーと同じマシンで実行されている新しいサテライトインスタンスが開始されます。この特別なサテライトは、リモート SPDK プロキシに対してすべての REST ベースの RPC 通信を実行します。LINSTOR コマンドのヘルプメッセージが示すように、管理者はこの特別なサテライトを作成するときに設定を追加したい場合があります。

--api-* とそれに対応する --api-\*-env バージョンの違いは、 -env で終わるバージョンは、値を含む環境変数を検索することです。一方、 --api-\* バージョンは、LINSTOR プロパティに格納されている値を直接取得します。管理者は --api-pw をプレーンテキストで保存したくない場合があります。これは linstor node list-property <nodeName> などのコマンドで表示されてしまいます。

特別なサテライトが稼働し始めたら、実際のストレージプールを作成できます。

node_name は自明ですが、name は LINSTOR ストレージプールの名前であり、 driver_pool_name は SPDK 論理ボリュームストアを指定します。

この remotespdk ストレージプールが作成されると、残りの手順は NVMe を使用する場合と非常に似ています。最初に、単に “diskful” リソースでターゲットを作成し、2 番目のリソースは -nvme-initiator オプションを有効にして作成します。

DRBDのセットアップに 複数のネットワークパスを使用するには、PrefNic プロパティは十分ではありません。代わりに、次のように linstor node interface と linstor resource-connection path コマンドを使用する必要があります。

上記の例では、各ノードに2つのネットワークインタフェース(nic1とnic2)を定義しています。 最後の2つのコマンドは、生成されるDRBDの .res ファイルにネットワークパスのエントリを作成します。 これが生成された .res ファイルの関連する部分です。

以下にコマンドの詳細を示します。

LINSTORがボリュームを暗号化する前に、マスターパスフレーズを作ることが必要です。これには以下のlinstorコマンドを使用します。

crypt-create-passphrase はマスターパスフレーズを初期化するためにユーザの入力を待ちます。

マスターパスフレーズを変更したい場合は以下のコマンドで行います。

resource-definition またはリソース自体を作成するときに luks レイヤーを追加できますが、前者の方法は、resource-definition から作成されたすべてのリソースに自動的に適用されるため、推奨されます。

マスターパスフェーズを入力する（コントローラを再起動した後）には以下を使用します。

マスターパスフレーズの作成と再入力のプロセスを自動化することは可能です。

これを使用するには、 MASTER_PASSPHRASE という名前の環境変数、またはマスターパスフレーズを含む /etc/linstor/linstor.toml のエントリを作成する必要があります。

linstor.toml は以下のようになります。

これらのいずれかが設定されている場合、コントローラが起動されるたびに、マスターパスフレーズがすでに存在するかどうかがチェックされます。ない場合は、指定されたとおりに新しいマスターパスフレーズが作成されます。ある場合、コントローラはパスフレーズを入力します。

一部の退避ケースでは、特別な計画が必要になる場合があります。たとえば、複数のノードを退避する場合、LINSTOR のリソース自動配置に参加するノードから除外できます。これを行うには、退避する各ノードで次のコマンドを使用します。

これにより、退避しようとしているノードから、退避を計画している別のノードに LINSTOR がリソースを配置することがなくなります。

node evacuate コマンドをすでに実行して、完了したか、リソースがまだ “Evacuating” 状態にある場合は、 node restore コマンドを使用して、ノードから “Evacuating” 状態を削除できます。 node delete コマンドをまだ実行していない限り、これは機能します。

ノードを復元した後、以前に AutoplaceTarget プロパティ を “false” に設定した場合は node set-property <node_name> AutoplaceTarget true を使用する必要があります。このようにして、LINSTOR は再びリソースをノードに自動的に配置し、クラスター内のリソースに設定した配置カウントプロパティを満たすことができます。

リソース定義 ‘resource1’ がすでにどこかのノードにあると仮定すると、スナップショットは以下のコマンドで作成できます。

これはリソースが存在するすべてのノードでスナップショットを作成します。LINSTORはリソースが使用中でも一貫性のあるスナップショットが取れることを保証します。

resource-definition プロパティ AutoSnapshot/RunEvery を設定すると LINSTOR は X 分ごとに自動的にスナップショットを作成します。オプションのプロパティ AutoSnapshot/Keep を使用して、自動的に作成された古いスナップショットをクリーンアップできます。手動で作成されたスナップショットはクリーンアップ/削除されません。 AutoSnapshot/Keep が省略されている（または 0 以下）の場合、LINSTOR はデフォルトで最新の10個のスナップショットを保持します。

以下の手順では新しいリソースにスナップショットを復元します。オリジナルのリソースがそれが取られたノードからすでに削除されていても復元可能です。

最初にスナップショットに一致するボリュームをもつリソースを定義します。

この時点で必要に応じて追加の設定を適用します。それで準備ができたら、スナップショットを使ってリソースを作成します。

これにより、スナップショットが存在するすべてのノードに新しいリソースが作られます。リソースを作るノードも明示的に指定できます。詳細はヘルプ (linstor snapshot resource restore -h) を参照ください。

LINSTOR はリソースをスナップショット状態にロールバックできます。リソースが使用中のものはできません。つまり、どのノードにもマウントされていないものです。リソースが使用中の場合は、 こちら を検討してください。

ロールバックは次のようにして実行します。

リソースは最新のスナップショットにのみロールバックできます。古いスナップショットにロールバックするには、最初に途中のスナップショットを削除します。

スナップショットの削除は以下のコマンドで行います。

スナップショットは、LINSTOR ノード間または異なる LINSTOR クラスター間、および Amazon S3, min.io などの S3 ストレージに送信できます。

スナップショットを送受信するサテライトには、次のツールをインストールします。

LINSTORクライアントの schedule create コマンドを使用してバックアップ出荷スケジュールを作成し、cron 構文を使用してバックアップ配信の頻度を定義します。また、スケジュールに名前を付けるオプションを設定し、障害発生時の対応、ローカルとリモートのバックアップコピーの数、増分バックアップの配信をスケジュールするかどうかなど、バックアップ配信の様々な側面を定義する必要があります。

最低限、このコマンドはバックアップ出荷スケジュールを作成するために、スケジュール名とフルバックアップcronスキーマを必要とします。コマンドの例は次のようになります。

LINSTORクライアントの schedule modify コマンドを使用すると、バックアップの出荷スケジュールを変更することができます。 このコマンドの構文は schedule create コマンドの構文と同じです。schedule modify` コマンドで指定する名前は、すでに存在するバックアップスケジュールでなければなりません。コマンドのオプションで指定しないものは、既存の値を保持します。keep-local` または keep-remote オプションをデフォルト値に戻したい場合は、”all “に設定します。max-retries` オプションをデフォルトの値に戻したい場合は、”forever” に設定します。

物理ストレージは無限ではなく、リモートストレージにはコストがかかるため、スナップショットやバックアップの保存数に制限を設けるとよいでしょう。

keep-remote` と --keep-local の両オプションは、明らかな意味を持つので、特別な言及に値します。これらのオプションを使用すると、スナップショットやフルバックアップを何回保持するかを、ローカルのソースまたはリモートの宛先に指定することができます。

linstor schedule list` コマンドを使用すると、バックアップの配信スケジュールを一覧することができます。

For example:

LINSTORクライアントの schedule delete コマンドはバックアップされた配信予定LINSTORオブジェクトを完全に削除するコマンドです。このコマンドの唯一の引数は削除したいスケジュール名です。削除されたスケジュールが現在バックアップを作成または配信している場合、スケジュールされた出荷処理は停止されます。処理が停止した時点によっては、スナップショット、バックアップ、またはその両方が作成および配信されない可能性があります。

このコマンドは、以前に作成されたスナップショットや正常に配信されたバックアップには影響しません。これらは、手動で削除されるまで保持されます。

LINSTORクライアントの backup schedule enable コマンドを使用すると、以前に作成したバックアップ配信スケジュールを有効にすることができます。このコマンドは次のような構文になっています。

以前に有効にしたバックアップ配信スケジュールを無効にするには、LINSTORクライアントの backup schedule disable コマンドを使用します。このコマンドは次のような構文になります。

もし、上記の backup schedule enable コマンドの例のように、リソースグループかリソース定義のどちらかを指定するオプションを含めると、そのリソースグループかリソース定義に対してのみ、スケジュールを無効にします。

例えば、以前の backup schedule enable コマンドでリソースグループやリソース定義の指定を省略した場合、LINSTORはスナップショットを作成することができるすべてのリソースのバックアップ出荷をスケジュールすることになります。disableコマンドは、そのコマンドで指定されたリソースグループやリソース定義にのみ影響します。バックアップ出荷のスケジュールは、指定されたリソースグループまたはリソース定義以外のすべてのLINSTORリソースに適用されます。

バックアップスケジュール有効化コマンドと同様に、リソースグループもリソース定義も指定しない場合、LINSTORは配備されたすべてのLINSTORリソースのコントローラレベルでのバックアップ出荷スケジュールを無効化します。

linstor backup schedule delete` コマンドを使うと、スケジュール自体を削除することなく、指定したリソース定義やリソースグループをバックアップ出荷スケジュールからきめ細かく削除することができます。このコマンドは backup schedule disable コマンドと同じシンタックスと引数を持っています。リソースグループもリソース定義も指定しない場合、指定したバックアップ出荷スケジュールはコントローラーレベルで削除されます。

バックアップスケジュール削除コマンドは、LINSTORオブジェクトレベル、リソース定義、リソースグループ、またはコントローラレベル（どちらも指定されていない場合）からバックアップ出荷スケジュールとリモートのペアを*削除*する方法として考えると便利かもしれません。

backup schedule delete` コマンドは以前に作成されたスナップショットや正常にシッピングされたバックアップには影響を与えません。これらは手動で削除されるか、まだ適用可能な keep-local または keep-remote オプションの効果によって削除されるまで保持されます。

このコマンドは、複数のLINSTORオブジェクトレベルのバックアップスケジュールを無効にした後、粒度の細かい変更を行いたい場合に使用します。この場合、backup schedule enable コマンドは意図しない結果をもたらすかもしれません。

例えば、コントローラレベルで有効にしたバックアップスケジュールとリモートのペアがある場合 を考えてみましょう。このコントローラには、_myresgroup_というリソースグループがあり、その下に_resdef1_から_resdef9_といういくつかのリソース定義があります。メンテナンスのために、2つのリソース定義_resdef1_と_resdef2_のスケジュールを無効にします。その後、メンテナンスのために、_myresgroup_リソースグループのリソースグループレベルでバックアップ出荷スケジュールを無効にする必要があることに気づきました。

メンテナンスが完了し、_resdef3_から_resdef9_までのバックアップ出荷スケジュールを有効にできますが、_resdef1_と_resdef2_のバックアップ出荷を再開（有効）する準備がまだできていません。resdef3_から_resdef9_までの各リソース定義に対して個別にバックアップ配送を有効にするか、backup schedule delete コマンドを使用してリソースグループ_myresgroup_からバックアップ配送スケジュールを削除することができます。backup schedule delete` コマンドを使用すると、_resdef3_から_resdef9_のバックアップはコントローラレベルでバックアップ出荷スケジュールが有効になっているため再び出荷されますが、_resdef1_と_resdef2_はリソース定義レベルでバックアップ出荷スケジュールがまだ無効になっているため出荷されません。

メンテナンスが完了し、_resdef1_と_resdef2_のバックアップを出荷する準備ができたら、これら2つのリソース定義のバックアップ出荷スケジュールを削除して、コントローラレベルですべてのLINSTOR展開されたリソースのバックアップ出荷をスケジュールする、開始状態に戻すことができます。これを視覚化するために、 LINSTORコントローラがスケジュールされたバックアップの出荷を決定する方法 サブセクションにあるLINSTORがバックアップを出荷するかどうかを決定する方法についてのディシジョンツリー図を参照するとよいかもしれません。

LINSTORクライアントの schedule list-by-resource コマンドを使えば、リソースごとのバックアップスケジュールをリストアップすることができます。このコマンドはLINSTORリソースを表示し、バックアップの出荷スケジュールがどのように適用され、どのリモートに出荷されるかを表示します。もしリソースが出荷されていない場合は、このコマンドは表示されます。

リソースにschedule-remote-pairがあり、出荷されている場合、コマンド出力には、最後のバックアップがいつ出荷されたか、次のバックアップがいつ出荷される予定であるかが表示されます。また、次回のバックアップと前回のバックアップの出荷がフルバックアップかインクリメンタルバックアップかが表示されます。最後に、このコマンドは、増分バックアップ（もしあれば）およびフルバックアップの次の出荷予定日を表示します。

スケジュールリストバイリソースコマンドで --active-only フラグを使用すると、出荷されていないリソースをすべてフィルタリングすることができます。

LINSTORコントローラは、デプロイされたLINSTORリソースが特定のリモート宛先に特定のバックアップスケジュールで出荷されるかどうかを判断するために、以下のロジックを使用します。

図に示すように、有効または無効なバックアップ出荷スケジュールは、次の順序で効果を発揮します。

先行するレベルで有効または無効にされたバックアップ出荷スケジュールと遠隔地のペアは、後のレベルで同じスケジュールと遠隔地のペアの有効または無効の状態を上書きします。

LINSTORリソースがスケジュールされたバックアップ出荷によってどのような影響を受けるかを知るには、LINSTORクライアントの schedule list-by-resource-details コマンドを使用して指定したLINSTORリソースに対して行うことができます。

このコマンドは、どのLINSTORオブジェクト・レベルにおいて、バックアップ出荷スケジュールが設定されていない（空のセル）、有効、または無効であるかを示すテーブルを出力します。

このコマンドを使用すると、リソースのスケジュールバックアップの有効化、無効化、削除をどのレベルで変更する必要があるかを判断することができます。

出力例は次のようになります。

The LINSTOR resource object is an exception to the general syntax for setting DRBD options for LINSTOR objects. With the LINSTOR resource object, you can use the drbd-peer-options to set DRBD options at the connection level between the two nodes that you specify. Specifying drbd-peer-options for a LINSTOR resource object between two nodes is equivalent to using the`linstor resource-connection drbd-peer-options` for a resource between two nodes.

For example, to set the DRBD maximum buffer size to 8192 at a connection level, for a resource named backups, between two nodes, node-0 and node-1, enter:

The command above is equivalent to the following:

Indeed, when using the linstor --curl command to examine the two commands actions on the LINSTOR REST API, the output is identical:

The connection section of the LINSTOR-generated resource file backups.res on node-0 will look something like this:

You can use the drbd-peer-options argument to set DRBD options at a connection level, between two nodes, for example:

The preceding command would set the DRBD ping-timeout option to 29.9 seconds at a connection level between two nodes, node-0 and node-1.

You can verify a LINSTOR object’s set properties by using the list-properties command, for example:

To remove a previously set DRBD option, prefix the option name with unset-. For example:

The same syntax applies to any drbd-peer-options set either on a LINSTOR resource, resource connection, or node connection. For example:

LINSTOR can convert resources between diskless and having a disk. This is achieved with the resource toggle-disk command, which has syntax similar to resource create.

For instance, add a disk to the diskless resource backups on ‘alpha’:

Remove this disk again:

To move a resource between nodes without reducing redundancy at any point, LINSTOR’s disk migrate feature can be used. First create a diskless resource on the target node, and then add a disk using the --migrate-from option. This will wait until the data has been synced to the new disk and then remove the source disk.

For example, to migrate a resource backups from ‘alpha’ to ‘bravo’:

LINSTOR expects DRBD Proxy to be running on the nodes which are involved in the relevant connections. It does not currently support connections through DRBD Proxy on a separate node.

Suppose our cluster consists of nodes ‘alpha’ and ‘bravo’ in a local network and ‘charlie’ at a remote site, with a resource definition named backups deployed to each of the nodes. Then DRBD Proxy can be enabled for the connections to ‘charlie’ as follows:

The DRBD Proxy configuration can be tailored with commands such as:

LINSTOR does not automatically optimize the DRBD configuration for long-distance replication, so you will probably want to set some configuration options such as the protocol:

LINSTOR can also be configured to automatically enable the above mentioned Proxy connection between two nodes. For this automation, LINSTOR first needs to know on which site each node is.

As the Site property might also be used for other site-based decisions in future features, the DrbdProxy/AutoEnable also has to be set to true:

A sample PostgreSQL linstor.toml looks like this:

A sample MariaDB linstor.toml looks like this:

etcd is a distributed key-value store that makes it easy to keep your LINSTOR database distributed in a HA-setup. The etcd driver is already included in the LINSTOR-controller package and only needs to be configured in the linstor.toml.

More information about how to install and configure etcd can be found here: etcd docs

And here is a sample [db] section from the linstor.toml:

To make LINSTOR’s administrative tasks more accessible and also available for web-frontends a REST API has been created. The REST API is embedded in the linstor-controller and since LINSTOR 0.9.13 configured through the linstor.toml configuration file.

The HTTP REST API can also run secured by HTTPS and is highly recommended if you use any features that require authorization. To do so you have to create a Java keystore file with a valid certificate that will be used to encrypt all HTTPS traffic.

Here is a simple example on how you can create a self signed certificate with the keytool that is included in the Java Runtime:

keytool will ask for a password to secure the generated keystore file and is needed for the LINSTOR Controller configuration. In your linstor.toml file you have to add the following section:

Client access can be restricted by using a SSL/TLS truststore on the Controller. Basically you create a certificate for your client and add it to your truststore and the client then uses this certificate for authentication.

First create a client certificate:

Then we import this certificate to our controller truststore:

And enable the truststore in the linstor.toml configuration file:

Now restart the Controller and it will no longer be possible to access the controller API without a correct certificate.

The LINSTOR client needs the certificate in PEM format, so before we can use it we have to convert the java keystore certificate to the PEM format.

To avoid entering the PEM file password all the time it might be convenient to remove the password.

Now this PEM file can easily be used in the client:

It is possible to have the LINSTOR use SSL/TLS secure TCP connection between controller and satellite connections. Without going into further details on how Java’s SSL/TLS engine works we will give you command line snippets using the keytool from Java’s runtime environment on how to configure a three node setup using secure connections.

The node setup looks like this:

Node alpha is the just the controller. Node bravo and node charlie are just satellites.

Here are the commands to generate such a keystore setup, values should of course be edited for your environment.

You can configure LINSTOR to use LDAP authentication to limit access to the LINSTOR Controller. This feature is disabled by default but you can enable and configure it by editing the LINSTOR configuration TOML file. After editing the configuration file, you will need to restart the linstor-controller.service. An example LDAP section within the configuration file looks like this:

After configuring the LINSTOR Controller to authenticate users through LDAP (or LDAPS), and the LINSTOR REST API HTTPS, you will need to enter LINSTOR commands as follows:

If you have configured LDAP authentication without also configuring LINSTOR REST API HTTPS, you will need to explicitly enable password authentication over HTTP, by using the --allow-insecure-path flag with your linstor commands. This is not recommended outside of a secured and isolated LAN, as you will be sending credentials in plain text.

LINSTOR automatically configures quorum policies on resources when quorum is achievable. This means, whenever you have at least two diskful and one or more diskless resource assignments, or three or more diskful resource assignments, LINSTOR will enable quorum policies for your resources automatically.

Inversely, LINSTOR will automatically disable quorum policies whenever there are less than the minimum required resource assignments to achieve quorum.

This is controlled through the, DrbdOptions/auto-quorum, property which can be applied to the linstor-controller, resource-group, and resource-definition. Accepted values for the DrbdOptions/auto-quorum property are disabled, suspend-io, and io-error.

Setting the DrbdOptions/auto-quorum property to disabled will allow you to manually, or more granularly, control the quorum policies of your resources should you want to.

For example, to manually set the quorum policies of a resource-group named my_ssd_group, you would use the following commands:

You may want to disable DRBD’s quorum features completely. To do that, you would need to first disable DrbdOptions/auto-quorum on the appropriate LINSTOR object, and then set the DRBD quorum features accordingly. For example, use the following commands to disable quorum entirely on the my_ssd_group resource-group:

If a satellite is offline for a prolonged period of time, LINSTOR can be configured to declare that node as evicted. This triggers an automated reassignment of the affected DRBD resources to other nodes to ensure a minimum replica count is kept.

This feature uses the following properties to adapt the behaviour.

After the linstor-controller loses the connection to a satellite, aside from trying to reconnect, it starts a timer for that satellite. As soon as that timer exceeds DrbdOptions/AutoEvictAfterTime and all of the DRBD-connections to the DRBD-resources on that satellite are broken, the controller will check whether or not DrbdOptions/AutoEvictMaxDisconnectedNodes has been met. If it hasn’t, and DrbdOptions/AutoEvictAllowEviction is true for the node in question, the satellite will be marked as EVICTED. At the same time, the controller will check for every DRBD-resource whether the number of resources is still above DrbdOptions/AutoEvictMinReplicaCount. If it is, the resource in question will be marked as DELETED. If it isn’t, an auto-place with the settings from the corresponding resource-group will be started. Should the auto-place fail, the controller will try again later when changes that might allow a different result, such as adding a new node, have happened. Resources where an auto-place is necessary will only be marked as DELETED if the corresponding auto-place was successful.

The evicted satellite itself will not be able to reestablish connection with the controller. Even if the node is up and running, a manual reconnect will fail. It is also not possible to delete the satellite, even if it is working as it should be. The satellite can, however, be restored. This will remove the EVICTED-flag from the satellite and allow you to use it again. Previously configured network interfaces, storage pools, properties and similar entities as well as non-DRBD-related resources and resources that could not be autoplaced somewhere else will still be on the satellite. To restore a satellite, use

By setting the DrbdOptions/auto-diskful option on a LINSTOR resource definition , you are configuring the LINSTOR controller to make a Diskless DRBD resource Diskful if the resource has been in a DRBD Primary state for more than the specified number of minutes. After the specified number of minutes, LINSTOR will automatically use the resource toggle-disk command to toggle the resource state on the Diskless node, for the given resource.

To set this property, for example, on a LINSTOR resource definition named myres with a threshold of five minutes, enter the command:

To unset the LINSTOR auto-diskful option, enter:

これらのLINSTORプロパティは set-property コマンドを使用して設定することができ、次のオブジェクトに設定することができます：ボリューム、ストレージプール、リソース、コントローラ、またはノード。また、リソースグループ、ボリュームグループ、リソース定義、またはボリューム定義にこれらのQoSプロパティを設定することができます。 グループまたは定義にQoSプロパティを設定すると、そのグループまたは定義から作成されたリソースは、QoS設定を継承します。

次の例では、リソースグループを作成し、ボリュームグループを作成し、ボリュームグループにQoS設定を適用し、リソースグループからリソースをスポーンしています。検証コマンドを実行すると、スポーンされたリソースがQoS設定を継承していることがわかります。 この例では、_pool1_という名前の以前に作成されたLINSTORストレージプールを想定して使用します。この名前は、あなたの環境に存在するストレージプール名に置き換える必要があります。

生成されたリソースがQoS設定を継承していることを確認するには、ストレージプールにストレージを提供するノードで、対応するsysfsファイルの内容を表示します。

単一の LINSTOR ボリュームは、複数の DRBD デバイスで構成できます。たとえば、外部メタデータを含む DRBD には、データ (ストレージ) デバイス、メタデータ デバイス、および LINSTOR に提供される複合 DRBD デバイス (ボリューム) の 3 つの下位デバイスがあります。データデバイスとメタデータデバイスが異なる下位ディスクに対応している場合、そのような LINSTOR ボリュームに sysfs プロパティを設定すると、ローカルデータ (ストレージ) 下位デバイスのみが対応する /sys/fs/cgroup/blkio/ ファイルのプロパティ値を受け取ります。DRBD メタデータの下位デバイスや、LINSTOR で提供される複合下位デバイスは値を受け取りません。ただし、DRBD のデータとそのメタデータが同じ下位ディスクを共有する場合、QoS 設定はデータとメタデータ操作の両方のパフォーマンスに影響します。

LINSTOR リソース定義に nvme-target リソースと nvme-initiator リソースがある場合、各ノードの両方のデータ (ストレージ) 下位デバイスが sysfs プロパティ値を受け取ります。ターゲットの場合、データ下位デバイスは LVM または ZFS のいずれかのボリュームになりますが、イニシエータの場合、LUKS、NVMe、DRBD などの他の LINSTOR レイヤーに関係なく、データ下位デバイスは接続された nvme-device になります（ DRBDを使わないLINSTOR を参照ください）。

コマンドラインで利用可能なコマンドを確認するには linstor とタイプします。

サブコマンドのさらなる情報は次の２つの方法で確認できます。

LINSTOR がインタラクティブモード（ linstor interactive ）で動作しているときには ‘help’ サブコマンドはとても役にたちます。

LINSTORで役に立つ機能の１つに豊富なタブ補完機能があります。これはLINSTORが認識する基本的なすべてのオブジェクト（例えばノード名、IPアドレス、リソース名など）を完成させるために使用できます。以下の例では、いくつかの可能な補完とその結果を示します。

タブ補完機能が動作しない場合は以下のファイルをソースしてください。

zsh ユーザのためにlinstor-clientはzshタブ補完機能用のファイルを生成できます。これはコマンドと引数の基本的なサポート機能です。

何か問題が発生し、問題の原因を見つけるのに助けが必要な場合は、以下のコマンド使用します。

上記のコマンドは、コントローラーノードの /var/log/linstor/controller/ に新しい sos-report を作成します。または、以下のコマンドも使用できます。

これにより、新しい sos-report が作成され、さらにそのレポートがローカルマシンの現在の作業ディレクトリにダウンロードされます。

この sos-report には、いくつかのソース（Linstor-logs, dmesg, 外部ツールのバージョン, ip a, データベースダンプなど）からのログと有用なデバッグ情報が含まれています。これらの情報はノードごとにプレーンテキストで .tar.gz ファイルに保存されます。

コミュニティの助けを借りるには https://lists.linbit.com/listinfo/drbd-user にあるメーリングリストを購読してください。

バグや機能要求を提出するには、GitHubページ https://github.com/linbit を確認してください。

リモートインストールサービス、24時間365日のサポート、認定リポジトリへのアクセス、または機能開発をご希望の場合は、1-877-454-6248（1-877-4LINBIT）、International：43-1-8178292 -0 | [email protected] にお問い合わせください。

LINSTOR Operator v2 is deployed using kustomize tool, integrated with kubectl.

The Operator v1 is installed using a Helm v3 chart as follows:

LINSTORオペレーターは、いくつかの基本的なストレージセットアップを自動化できます。

This section describes the different options for enabling security features available when using this operator. The following guides assume the operator is installed using Helm

Helm チャートは、高度なユースケースのために、さらなるカスタマイズオプションのセットを提供します。

Prometheus を使って LINSTOR のコンポーネントを監視することができます。 オペレータは既存のコンポーネントに沿ってモニタリングコンテナをセットアップし、Service として利用できるようにします。

Prometheus Operator を使用する場合、Linstor オペレーターは ServiceMonitor インスタンスも設定します。 Piraeus 名前空間が有効 と仮定して、メトリックはオペレーターに関連付けられた Prometheus インスタンスによって自動的に収集されます。

メトリックのエクスポートを無効にするには operator.satelliteSet.monitoringImage を空の値に設定します。

オペレーターは、既存の LINSTOR を使用するようにサテライトと CSI プラグインを構成できます。これは、ストレージインフラストラクチャが Kubernetes クラスターから分離されている場合に役立ちます。ボリュームは Kubernetes ノードでディスクレスモードでプロビジョニングでき、ストレージノードが下位ディスクストレージを提供します。

LINSTOR コントローラーデプロイメントの作成をスキップし、既存の LINSTOR コントローラーを使用するように他のコンポーネントを構成するには、 helm install を実行するときに次のオプションを使用します。

すべての pod の準備が整うと、既存の LINSTOR 環境で Kubernetes クラスターノードがサテライトとして表示されます。

ストレージノードで既存のストレージプールを参照するストレージクラスを作成します。

ストレージクラスを使用してPVCを作成することで、新しいボリュームをプロビジョニングすることができます。ボリュームはまず、指定されたストレージプールを持つノード、つまりストレージインフラストラクチャにのみ配置されます。ポッドでボリュームを使用したい場合は、LINSTOR CSIがKubernetesノードにディスクレスリソースを作成し、ネットワーク経由でディスクフルリソースに接続します。

Kubernetes でコミュニティがサポートする LINSTOR デプロイメントのエディションは、Piraeus と呼ばれます。Piraeus プロジェクトに関しては オペレータ を参照ください。

次のストレージクラスには、プロビジョニングされたストレージを構成するために現在使用可能なすべてのパラメーターが含まれています。

csi.storage.k8s.io/fstype` パラメータは volumeMode.Fileystem PVC に作成するファイルシステムの種類を設定します。FileSystem` のPVCに作成するファイルシステムの種類を設定します。現在サポートされているのは次のとおりです。

autoPlace は、この StorageClass のボリュームが持つレプリカの量を決定する整数値です。例えば、autoPlace: "3" は３つの複製をもつボリュームを生成します。autoPlace と nodeList のどちらも設定されていない場合、１つのノード上にボリュームが生成されます。自動配備 を参照ください。

placementCount は autoPlace のエイリアスです。

この StorageClass に関連付けられた LINSTOR Resource Group (RG) 。設定されていない場合、新しい PVC ごとに新しい RG が作成されます。

storagePool は LINSTOR ストレージプール の名前で、新規に作成されたボリュームにストレージを供給するときに使用されます。

disklessStoragePool はオプションでノードが kubelets にディスクレス、すなわちクライアントとして割り当てられるようにするときに使用します。LINSTOR でカスタムディスクレスストレージプールが定義されている場合は、ここで指定します。

作成されたボリュームで使用するレイヤーのコンマ区切りのリスト。使用可能なレイヤーと順序は このセクション の後半に記述されています。

使用可能なボリュームスケジューラの 1 つから選択します。

ボリュームにアクセスできるノードを制御します。このオプションの値は、次の 2 つの異なる形式をとることができます。

encryption はオプションで、ボリュームを暗号化するかどうかを指定します。LINSTOR はこれが正しく動作するように適切に設定されている必要があります。

nodeList はボリュームが割り当てられるノードのリストです。ボリュームがそれぞれのノードに割り当てられそれらの間で複製が行われます。これはホスト名で１つのノードを指定できますが、 これには replicasOnSame を使うほうが柔軟性があります。

clientList は、割り当てられるディスクレスボリュームのノードのリストです。 nodeList と組み合わせて使用します。

replicasOnSame は自動配置選択ラベルとして使用される key または key=value アイテムのリストです。これは autoplace がストレージをプロビジョニングする場所を決定するために使用されます。これらのラベルは、LINSTOR ノードのプロパティに対応しています。

node-a が補助プロパティ zone=z1, role=backups で、 node-b が zone=z1 のみで構成されているような LINSTOR クラスターを想定した例でこの動作を調べてみましょう。

autoPlace: "1" と replicasOnSame: "zone=z1 role=backups" を持つ StorageClass を設定すると、この StorageClass から生成されるすべてのボリュームは node-a にプロビジョニングされます。これは LINSTOR クラスタ内ですべての key = value ペアを持つ唯一のノードだからです。これは、プロビジョニングに１つのノードを選択する最も柔軟な方法です。

autoPlace: "1" と replicasOnSame: "zone=z1" を持つ StorageClass を設定すると、ボリュームは node-a か node-b のどちらかにプロビジョニングされます。これは、両方が zone=z1 aux prop を持つからです。

autoPlace: "2" と replicasOnSame: "zone=z1 role=backups" を持つ StorageClass を設定すると、適切な補助プロパティを持つノードが2つ以上ないためプロビジョニングは失敗します。

autoPlace: "2" と replicasOnSame: "zone=z1" を持つ StorageClass を設定すると、ボリュームは node-a と node-b の両方にプロビジョニングされます。これは、両方が zone=z1 aux prop を持つからです。

値を指定せずにプロパティキーを使用して、特定の値を考慮しながら、すべてのレプリカが同じプロパティ値を持つノードに配置されるようにすることもできます。 4つのノードがあると仮定し node-a1 と node-a2 は zone=a で構成、 node-b1 と node-b2 は zone=b で構成されているとします。 autoPlace: "2" と replicasOnSame: "zone" を使用すると node-a1 と node-a2、または node-b1 と node-b2 のいずれかに配置されます。

replicasOnDifferent は replicasOnSame と同じように、考慮すべきプロパティのリストを取ります。 replicasOnDifferent の使用には 2 つのモードがあります。

ディスクフルリソースが割り当てられていないすべてのノードにディスクレスリソースを作成します。

正規表現と一致する名前のリソースを持つノードにリソースを配置しない。

fsOpts はオプションで、作成時にボリュームのファイルシステムに渡すオプションを指定します。

mountOpts はオプションで、マウント時にボリュームのファイルシステムに渡すオプションを指定します。

ボリュームを最初に使用する直前に呼び出される xfs_io に渡す追加の引数。

property.linstor.csi.linbit.com/ で始まるパラメータは StorageClass の Resource Group に設定される Linstor プロパティに変換されます。

たとえば DrbdOptions/auto-quorum を disabled に設定するには、次を使用します。

オプションの完全なリストは こちら で入手できます。

LINSTOR に渡す高度な DRBD オプション。たとえば、レプリケーションプロトコルを変更するには DrbdOptions/Net/protocol: "A" を使用します。

LINSTOR は、すべてではありませんが一部の Kubernetes ディストリビューションでボリュームスナップショット機能をサポートしています。

Kubernetes ディストリビューションがスナップショットをサポートしているかどうかを確認するには、次のコマンドを実行します。

Kubernetes ディストリビューションがスナップショットをサポートしていない場合は、Kubernetes Storage SIG から required components を手動で追加できます。 Piraeus team が提供する Helm Charts を使用してこれらのコンポーネントを追加することも可能です。

それで VolumeSnapshotClass を作成できます。

kubectl を使用して VolumeSnapshotClass を作成します。

次に上記で作成したボリュームのボリュームスナップショットを作成します。これは VolumeSnapshot を使用します。

kubectl を使用して VolumeSnapshot を作成します。

スナップショットの作成が成功したことを確認できます。

最後にスナップショットから PVC で新しいボリュームを作成します。

kubectl を使用して PVC を作成します。

次の例は、ボリュームのアクセスしやすさと局所性を最適化する一般的なシナリオを示しています。また、クラスター内のゾーン間でボリュームレプリカを分散する方法の例も含まれています。

LINSTOR オペレーターは、アップグレードする前にデータベースのバックアップを作成します。これにより、アップグレード中に問題が発生した場合に、以前の状態にロールバックできます。

オペレーターがバックアップを自動的に作成できない状況があります。これは、次の理由が考えられます。

一部のバージョンでは特別な手順が必要です。以下を参照ください。

etcd データベースのバックアップを作成し、それをコントロールホストに保存するには、次のコマンドを実行します。

これらのコマンドは kubectl を実行しているマシン上にファイル save.db を作成します。

次の手順は、Kubernetesと全く同じです。

LINSTORコンテナイメージには、LINBIT GUIがプリインストールされています。これをクラスタ上で公開するには、OpenShift Routeリソースを設定します。

GUIは https://linstor-op-cs-storage.apps.oc.example.com/ui/ でアクセスできるようになりました。

OpenShiftには、完全に設定された監視スタックが含まれています。モニタリングスタックのほとんどはOpenstackインフラストラクチャのみを対象としていますが、LINBIT SDSの基本的なモニタリングも可能となっています。

まず、 Red Hatドキュメント の手順に従って、OpenShiftでユーザー定義プロジェクトの監視が有効になっていることを確認します。

ユーザー定義プロジェクトの監視を有効にすると、LINSTOR Operatorは自動的にOpenShiftのPrometheusベースの監視スタックの存在を検出し、ServiceMonitor リソースを構成します。Prometheusインスタンスは、すべてのクラスタノードからDRBDとLINSTORのメトリックを取得します。

LINSTORを実行するには、すべてのNomadエージェントを次のように設定する必要があります。

LINSTOR コントローラは、レプリカのないサービスとして導入されます。どの時点においても、1つのクラスタ内で実行可能なLINSTOR コントローラは1つのみです。データベースへのアクセス権がある場合は、新しいノードでコントローラを再起動できます。詳細は 高可用性 LINSTOR クラスターの作成 を参照してください。

次の例では、データセンター dc1 で単一のLINSTORコントローラを起動するNomadジョブを作成し、外部データベースに接続します。

次のコマンドを実行して、ジョブを適用します。

Nomad で LINSTORサテライトは、Nomadのシステムジョブとしてデプロイされ、特権コンテナー内で実行されます。サテライトに加えて、このジョブはLINSTORで使用される他のカーネルモジュールとともにDRBDモジュールもロードします。

次の例では、Nomadジョブを作成して、データセンター dc1 のすべてのノードでLINSTORサテライトを開始します。

次のコマンドを実行して、ジョブを適用します。

linstor-controller および linstor-satellite ジョブが実行されたら、 linstor コマンドラインツールを使用してクラスタの設定を開始できます。

これは次のように実行できます。

いずれの場合も、 サテライトをクラスタに追加 および ストレージプールを作成 を実行する必要があります。たとえば、ノード nomad-01.example.com を追加してLVMシンストレージプールを構成するには、次のコマンドを実行します。

ジョブでボリュームを使用するには、ジョブ指定に volume および volume_mount スタンザを追加します。

基礎となるストレージプールドライバがスナップショットをサポートしていれば、LINSTORは既存のボリュームのスナップショットを作成できます。

次のコマンドは、ボリューム vol1 の snap1 という名前のスナップショットを作成します。

スナップショットを使用して、既存のボリュームにスナップショットのデータを事前に設定できます。

Version 7 of the plugin uses a LINSTOR controller API that is available from LINSTOR version 1.21.1 onwards. Make sure that your LINSTOR setup (controller and satellites) use at least that version.

プラグインのバージョン 5 では、構成オプション “storagepool” と “redundancy” はサポートされません。バージョン 5 では LINSTOR リソースグループである “resourcegroup” オプションが必須になります。古いオプションは構成から削除する必要があります。

LINSTOR の構成に関しては LINSTOR の構成 を参照してください。以下に典型的は例を示します。プールが “mypool” 、冗長性が 3 に設定される例です。

プールが “mypool” に、冗長性が 3 に設定されていると仮定します。

プラグインのバージョン 6.0.0 では redundancy 設定に関連するすべてのコードが削除されます。これは、非常に長い間、LINSTOR リソースグループ (resourcegroup 設定) によって処理されてます。変更は必要ありません。

LINSTOR によって管理される VM で LINSTOR コントローラを実行するための controllervm 設定はなくなりました。 drbd-reactor を使用して高可用性 LINSTOR コントローラを実現することをお勧めします。

設定 statuscache と preferlocal がデフォルトで有効になりました。

バージョン 6 で PVE は、一部の関数にパラメーターを追加し、それらの “APIAGE” をリセットしました。古いプラグインは、これらの変更された関数を使用しないため実際には機能しますが、使用できなくなります。少なくともプラグインバージョン 5.2.1 にアップグレードしてください。

Proxmox で LINSTOR を使用するには、DRBD カーネルモジュールをインストールする必要があります。DRBD9 カーネル モジュールは、カーネルモジュールソースパッケージ (drbd-dkms) としてインストールされます。したがって、LINBIT のリポジトリから DRBD カーネルモジュールをインストールする前に、Proxmox VE カーネルヘッダーパッケージ pve-headers をインストールする必要があります。この順序に従うことで、カーネル モジュールがカーネルに対して適切にビルドされるようになります。

最新の Proxmox カーネルをインストールする予定がない場合は、現在実行中のカーネルに一致するカーネル ヘッダーをインストールする必要があります (たとえば pve-headers-$(uname -r) )。この手順に従わなかった場合でも apt install --reinstall drbd-dkms コマンドで、現在のカーネルに対して drbd-dkms パッケージを再構築できます (事前にカーネル ヘッダーをインストールしている場合)。

LINBIT のお客様または評価アカウントをお持ちの場合は、ノードで LINBIT の drbd-9 リポジトリを有効にしてから、apt update コマンドを使用してリポジトリを更新できます。

次に、次のように入力して、DRBD カーネルモジュール、DRBD ユーティリティ、および LINSTOR Proxmox プラグインをインストールできます。

LINBIT は、Proxmox VE ユーザーに専用の公開リポジトリを提供します。このリポジトリには、Proxmox プラグインだけでなく、DRBD SDS カーネルモジュールとユーザー空間ユーティリティを含む DRBD SDS スタック全体が含まれています。

LINBIT のレポジトリは以下の操作で有効にできます。 “$PVERS” は Proxmox VE のメジャーバージョンを指定します(例 “7” であり “7.1” ではない)。

/etc/one/oned.conf の以下のセクションを変更します。

TM_MAD および DATASTORE_MAD セクションのドライバーのリストに linstor を追加します。

TM_MAD_CONF および DS_MAD_CONF セクションを新たに追加します。

これらの変更を行った後、OpenNebula サービスを再起動します。

フロントエンドノードは、LINSTOR を介してストレージノードおよびホストノードにコマンドを発行します。

ストレージノードは、VM のディスクイメージをローカルに保持します。

ホストノードは、インスタンス化された VM の実行を担当し、通常、必要なイメージ用のストレージを LINSTOR ディスクレスモードを介してネットワーク経由で接続します。

すべてのノードに DRBD9 と LINSTOR がインストールされている必要があります。このプロセスの詳細は DRBD9 のユーザーズガイド を参照ください。

両方の役割のすべての要件を満たす限り、フロントエンドノードとホストノードをプライマリロールに加えてストレージノードとして機能させることができます。

oneadmin ユーザーには、ストレージノードで mkfs コマンドへのパスワードなしsudoアクセス権が必要です。

ds.conf という名前のデータストア設定ファイルを作成し、 onedatastore ツールを使用して、その設定に基づいて新しいデータストアを作成します。相互に排他的な2つの配備オプション LINSTOR_AUTO_PLACE と LINSTOR_DEPLOYMENT_NODES があります。両方が設定されている場合、LINSTOR_AUTO_PLACE は無視されます。どちらのオプションでも、BRIDGE_LIST は LINSTOR クラスター内のすべてのストレージノードのスペース区切りリストである必要があります。

バージョン1.0.0以降、LINSTORはリソースグループをサポートしています。リソースグループは、そのリソースグループにリンクされているすべてのリソースが共有する設定の一元化されたポイントです。

データストアのリソースグループとボリュームグループを作成します。リソースグループ内でストレージプールを指定する必要があります。指定しないと、OpenNebula のスペースの監視が機能しません。ここでは2ノードの冗長性を持つものを作成し、作成された opennebula-storagepool を使用します。

LINSTOR プラグインを使用して OpenNebula データストアを追加します。

次の属性は非推奨であり、バージョン 2.0 で削除されました。

LINSTOR ドライバーはシステムデータストアとしても使用できます。構成は通常のデータストアとかなり似ていますが、いくつか相違があります。

また、新しいsysデータストアIDをイメージデータストア（COMMA区切り）の COMPATIBLE_SYS_DS に追加します。そうしないと、スケジューラはそれらを無視します。

揮発性ディスクを使用したライブマイグレーションが必要な場合は、KVMの --unsafe オプションを有効にする必要があります。https://docs.opennebula.org/5.8/deployment/open_cloud_host_setup/kvm_driver.html を参照してください。

新規インストールの場合、このセクションをスキップして LINSTOR ドライバをインストール に進んでください。

OpenStack Stein 以降、LINSTOR ドライバーは Cinder プロジェクトの一部です。ドライバはそのまま使用できますが、新しいバージョンで利用できる機能や修正が不足している可能性があります。安定バージョンの OpenStacks 更新ポリシーにより、ドライバーに対するほとんどの改善は、古い安定リリースにバックポートされません。

LINBIT は Cinder リポジトリーの フォーク をメンテナンスしています。ここには、サポートされている安定したバージョンにバックポートされた LINSTOR ドライバーのすべての改善が含まれています。現在、これらは次のとおりです。

LINSTOR Driver を有効にする正しい手順は、OpenStack ディストリビューションによって異なります。一般に python-linstor パッケージは、Cinder ボリュームサービスを実行しているすべてのホストにインストールする必要があります。次のセクションでは、一般的な OpenStack ディストリビューションへのインストール手順について説明します。