LINSTORはもともとDRBDリソースを管理するために開発されました。まだLINSTORを使用してDRBDを管理することができますが、LINSTORは進化し、より便利になったり、それらのスタック内で可能な範囲を超えてより簡単に永続ストレージを提供するために、しばしば上位のソフトウェアスタックと統合されています。

LINSTORは単体で使用することもできますし、Kubernetes、OpenShift、OpenNebula、OpenStack、Proxmox VEなどの他のプラットフォームと統合することも可能です。LINSTORは、オンプレミスのベアメタル環境で実行することもできますし、仮想マシン（VM）、コンテナ、クラウド、ハイブリッド環境でも利用することができます。

LINSTORは、次のストレージプロバイダーおよび関連技術と連携して動作することができます:

LINSTORを使用することで、これらのテクノロジーを単独で扱うか、またはさまざまな有益な組み合わせで使用することができます。

`linstor-controller`サービスは、クラスタ全体の構成情報を保持するデータベースに依存しています。LINSTORコントローラーソフトウェアを実行しているノードやコンテナは、リソース配置、リソース構成、およびクラスタ全体の状態を必要とするすべての運用プロセスのオーケストレーションを担当しています。

LINSTORでは複数のコントローラを使用することができます。たとえば、高可用性のLINSTORクラスタを設定する ときには、複数のコントローラを利用することができます。ただし、アクティブなコントローラは1つだけです。

前述のように、LINSTORコントローラーは、管理するデータプレーンとは別のプレーンで動作します。コントローラーサービスを停止し、コントローラーノードを更新または再起動しても、LINSTORサテライトノードにホストされているデータにアクセスできます。LINSTORサテライトノード上のデータには引き続きアクセスし、提供することができますが、実行中のコントローラーノードがないと、サテライトノードでのLINSTORの状態や管理タスクを実行することはできません。

`linstor-satellite`サービスは、LINSTORがローカルストレージを利用するか、サービスにストレージを提供する各ノードで実行されます。このサービスはステートレスであり、LINSTORコントローラーサービスを実行しているノードまたはコンテナから必要なすべての情報を受け取ります。 LINSTORサテライトサービスは、`lvcreate`や`drbdadm`などのプログラムを実行します。それは、LINSTORコントローラーノードまたはコンテナから受け取った命令を実行するノード上またはコンテナ内のエージェントのように機能します。

LINSTORとのインターフェースを行う必要がある場合、そのアクティブなLINSTORコントローラーに指示を送信するには、LINSTORクライアント、またはLINBIT SDS GUIのどちらかのユーザーインターフェース(UI)を使用できます。

これらのUIは、両方ともLINSTORのhttps://app.swaggerhub.com/apis-docs/Linstor/Linstor[REST API]に依存しています。

LINSTORは、ソフトウェア定義ストレージ（SDS）に対してオブジェクト指向のアプローチを取っています。LINSTORオブジェクトは、ユーザーやアプリケーションが利用するか、または拡張するためにLINSTORが提供する最終成果物です。

以下に、最も一般的に使用されるLINSTORのオブジェクトが説明されており、その後に全リストが続きます。

定義とグループもLINSTORオブジェクトですが、特別な種類です。定義とグループのオブジェクトは、プロファイルやテンプレートと考えることができます。これらのテンプレートオブジェクトは、親オブジェクトの属性を継承する子オブジェクトを作成するために使用されます。また、子オブジェクトに影響を与える可能性のある属性を持つこともありますが、それは子オブジェクト自体の属性ではありません。これらの属性には、たとえば、DRBDレプリケーションに使用するTCPポートや、DRBDリソースが使用するボリューム番号などが含まれる可能性があります。

次に、LINSTORにおけるオブジェクト階層の一般的なルールがいくつかあります：

このセクションでは、最も頻繁に使用されるLINSTORオブジェクト間の階層関係を表す図を使用しています。LINSTORオブジェクトの数とそれらの相互関係のため、概念化を簡素化するために、1つの図ではなく複数の図を最初に表示しています。

次の図は、単一のサテライトノード上でのLINSTORグループオブジェクト間の関係を示しています。

前の2つの図は、一般的なLINSTORオブジェクト間の上位下位の関係を示していますが、LINSTORオブジェクトの中には親子関係を持つものも考えられます。次の図では、ストレージプールの定義（親オブジェクト）とストレージプール（子オブジェクト）を例に、この種の関係が紹介されています。親オブジェクトは複数の子オブジェクトを持つことができます。そのような関係を示す図が以下に示されています。

概念図で親子関係の概念を導入した後、次の図は、グループや定義に一部の関係を追加した第2図の修正版です。この修正図には、最初の図で示された上位-下位の関係も一部取り入れられています。

次のダイアグラムは、以前のダイアグラムの関係性の概念を統合しつつ、スナップショットや接続に関連する新しいLINSTORオブジェクトを紹介しています。さまざまなオブジェクトと交差する線があるため、このダイアグラムへの構築の理由は明らかになるはずです。

前述の図は複雑なように見えますが、それでも簡略化されたものであり、LINSTORオブジェクト間の可能な関係のすべてを網羅しているわけではありません。前述したように、図に示されている以上に多くのLINSTORオブジェクトが存在します。[LINSTORは進化するソフトウェアであるため、特定のユースケースやコンテキストにおいては、オブジェクトのプロパティ階層が一般的なルールと異なることがある可能性があります。これらの場合には、文書で一般ルールへの例外に言及されます。]。

良いニュースは、LINSTORを扱う際に先行する図を暗記する必要がないということです。ただし、LINSTORオブジェクトに設定した属性、およびその他のLINSTORオブジェクトに対する継承と効果をトラブルシューティングしようとしている場合には参照すると役立つかもしれません。

LINSTOR は RPM と DEB 形式でパッケージングされています。

これらのパッケージについての詳細は インストール可能なコンポーネント を参照ください。

この標準は、暗号モジュールの設計および実装に使用されます。 — NIST’s FIPS 140-3 publication

LINSTORを設定して、このユーザーガイドの Encrypted Volumes セクションに詳細が記載されているように、LUKS (dm-crypt) を使用してストレージボリュームを暗号化することができます。 FIPS 規格に準拠しているかどうかについては、LUKSと dm-crypt プロジェクトを参照してください。

LINSTORを構成して、LINSTORサテライトとLINSTORコントローラー間の通信トラフィックをSSL/TLSを使用して暗号化することもできます。このユーザーガイドの安全なサテライト接続セクションで詳細に説明されています。

LINSTORは、Self-Encrypting Drives (SEDs) ともインターフェースでき、SED ドライブを初期化する際に LINSTOR を使用することができます。LINSTOR は、ドライブのパスワードをそのドライブに関連付けられたストレージプールに適用するプロパティとして保存します。LINSTOR は、まず作成しなければならない LINSTOR マスターパスフレーズ を使用して、SED ドライブのパスワードを暗号化します。

デフォルトでは、LINSTOR は以下の暗号アルゴリズムを使用します:

このセクションで述べられているユースケース向けに、FIPS準拠バージョンのLINSTORが利用可能です。もし貴方や貴組織がこのレベルのFIPSコンプライアンスを必要とする場合は、詳細について[email protected]までお問い合わせください。

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

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

LINBIT パッケージリポジトリを有効にすると、LINBIT ソフトウェアパッケージ、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/ から利用可能です。

あるいは、`/etc/linstor/linstor-client.conf`ファイルを作成し、`global`セクションに`controllers=`行を追加することもできます。

複数の LINSTOR コントローラーが構成されている場合は、それらをカンマ区切りのリストで指定するだけです。 LINSTOR クライアントは、リストされた順番でそれらを試します。

LINSTORのクライアントコマンドは、コマンドやサブコマンド、パラメータの最初の文字だけを入力することで、より速く便利に使用することができます。例えば、`linstor node list`を入力する代わりに、LINSTORの短縮コマンド`linstor n l`を入力することができます。

linstor commands`コマンドを入力すると、それぞれのコマンドの略記法と共に可能な LINSTOR クライアントコマンドのリストが表示されます。これらの LINSTOR クライアントコマンドのいずれかに `--help フラグを使用すると、コマンドのサブコマンドの略記法を取得できます。

LINSTORノードを作成する際にIPアドレスを指定すると、ノードに任意の名前を付けることができます。LINSTORクライアントは、ノードを作成する際にこのことについてINFOメッセージを表示します。

LINSTORは自動的に作成されたノードの`uname –nodename`を検出し、後でDRBDリソースの構成に使用します。任意のノード名の代わりに、ほとんどの場合は自分自身や他の人を混乱させないよう、LINSTORノードを作成する際にはノードのホスト名を使用するのが適切です。

linstor node list コマンドを使用すると、LINSTOR は新しいノードがオフラインとしてマークされていることを表示します。その後、新しいノードで LINSTOR サテライトサービスを開始して有効にし、サービスが再起動時にも起動するようにしてください。

約10秒後には、`linstor node list`での状態がオンラインになります。もちろん、コントローラーが衛星ノードの存在を知る前に、衛星プロセスが開始されている可能性があります。

linstor-satellite が必要なデバイスを作成する機会が得られるまで（ブート後など）他のサービスを待機させたい場合は、対応する .service ファイルを更新し、Type=simple を Type=notify に変更します。

これにより、サテライトはコントローラーが接続し、必要なすべてのデータをサテライトに送信し、サテライトがデバイスの起動と実行を少なくとも1回試行するまで、systemd への READY=1 メッセージの送信を遅らせます。

LINSTORノードを作成する際に、ノードタイプを指定することもできます。ノードタイプは、あなたのLINSTORクラスタ内でノードが担う役割を示すラベルです。ノードタイプは、controller, auxiliary, combined, satellite のいずれかになります。例えば、LINSTORノードを作成して、それをコントローラーノードとサテライトノードとしてラベルを付ける場合は、次のコマンドを入力してください：

`–node-type`引数はオプションです。ノードを作成する際にノードタイプを指定しない場合、LINSTORは自動的にデフォルトのサテライトタイプを使用します。

ノードを作成した後で、割り当てられた LINSTOR ノードのタイプを変更したい場合は、linstor node modify --node-type コマンドを入力します。

各ストレージを提供するホスト上で、LVMのボリュームグループ（VG）またはZFSのzPoolを作成する必要があります。同じLINSTORストレージプール名で識別されるVGやzPoolは、各ホストで異なるVGやzPool名を持つかもしれませんが、整合性を保つために、すべてのノードで同じVGまたはzPool名を使用することをお勧めします。

各ノードにボリュームグループを作成した後、次のコマンドを入力することで、各ノードでボリュームグループにバックアップされたストレージプールを作成することができます。

ストレージプールの一覧を表示するには、次のコマンドを入力してください:

または、LINSTORの略記法を使用することもできます。

単一種類のストレージのみが存在し、ストレージデバイスのホットスワップが可能なクラスターでは、1つの物理バッキングデバイスごとに1つのストレージプールを作成するモデルを選択することがあります。このモデルの利点は、障害ドメインを1つのストレージデバイスに限定することです。

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

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

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

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

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

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

もし --storage-pool オプションが指定された場合、LINSTOR は指定された名前でストレージプールを作成します。

さらなるオプションや正確なコマンドの使用方法については、LINSTOR クライアントの --help テキストを参照してください。

いくつかのセットアップと構成を行うことで、異なるストレージプロバイダタイプのストレージプールを使用して LINSTOR リソースをバックアップすることができます。これはストレージプールのミキシングと呼ばれます。たとえば、1つのノードで LVM の厚み予約ボリュームを使用するストレージプールを持ち、別のノードで ZFS zpool を使用するスリム予約済みのストレージプールを持つことができます。

ほとんどの LINSTOR デプロイメントでは、リソースをバックアップするために均質なストレージプールが使用されるため、ストレージプールのミキシングはその機能が存在することを知っておくためにだけここで言及されています。 例えば、ストレージリソースを移行する際に便利な機能かもしれません。 異なるストレージプロバイダーのストレージプールを混在させる には、これに関する詳細や前提条件などが記載されていますので、そちらをご覧ください。

LINSTORは、執筆時点で以下のサポートされているストレージプラグインを持っています。

`resource create`コマンドを使用すると、リソース定義を名前付きノードに明示的に割り当てることができます。

リソースグループからリソースを作成（生成）する際、LINSTOR が自動的にノードとストレージプールを選択してリソースを展開することが可能です。このセクションで言及されている引数を使用して、リソースグループを作成または変更する際に制約を指定することができます。これらの制約は、リソースグループから展開されるリソースが自動的に配置される方法に影響を与えます。

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

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

警告: もしリソース定義に既存のスナップショットがある場合、そのリソース定義を削除することはできません。スナップショットを削除するまでリソース定義は削除できません。このガイドのスナップショットの削除セクションを参照してください。

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

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

LINSTORリソースを削除すると、リソースそのものを取り除くだけでなく、クラスタに対して影響を及ぼす可能性があります。たとえば、リソースがDRBDレイヤーでバックアップされている場合、3ノードのクラスターの1ノードからリソースを削除すると、リソースに関連する特定のクォーラム関連のDRBDオプションも削除される可能性があります。3ノードクラスターの1ノードからこのようなリソースを削除した後、そのリソースは3ノードクラスターの2ノードにのみ展開されるため、もはやクォーラムを持たなくなります。

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

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

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

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

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

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

LINSTORデータベースをホームディレクトリに`db_export`という新しいファイルにバックアップするために、次のコマンドを入力してください：

注意: 必要に応じて、linstor-database ユーティリティに --config-directory 引数を使用して LINSTOR 設定ディレクトリを指定できます。この引数を省略すると、デフォルトでユーティリティは /etc/linstor ディレクトリを使用します。

データベースのバックアップが完了したら、バックアップファイルを安全な場所にコピーしてください。

生成されたデータベースのバックアップは、実際のデータだけでなく、バックアップが作成された日時や、どのデータベースからであるかなどのメタデータも含まれた、単なるJSONドキュメントです。

以前に作成したバックアップからデータベースを復元する手順は、 前のセクション で説明した export-db と似ています。

たとえば、以前に作成したバックアップを`db_export`ファイルから復元する場合は、次のコマンドを入力してください。

以前のバックアップからデータベースをインポートする際には、現在インストールされているLINSTORのバージョンが、バックアップを作成したバージョンと同じかそれ以上である必要があります。もし現在の LINSTOR バージョンが、データベースバックアップを作成したバージョンよりも新しい場合、バックアップをインポートする際にデータはエクスポート時に使用されたバージョンのデータベーススキーマと同じで復元されます。その後、コントローラが再起動すると、データベースが古いスキーマであることを検知し、自動的にデータを現在のバージョンのスキーマに移行します。

エクスポートされたデータベースファイルにはいくつかのメタデータが含まれているため、エクスポートされたデータベースファイルは、エクスポート元とは異なるデータベースタイプにインポートすることができます。

これにより、例えば、etcdセットアップからSQLベースのセットアップに簡単に変換することができます。データベース形式を変換する特別なコマンドはありません。単に`–config-directory`引数を使用して正しい`linstor.toml`構成ファイルを指定するか（あるいは、デフォルトの`/etc/linstor/linstor.toml`を更新してインポートする前に使用したいデータベースタイプを指定する）だけです。データベースタイプの指定については、LINSTORユーザーガイドを参照してください。バックアップ元のデータベースのタイプにかかわらず、`linstor.toml`構成ファイルで指定されたデータベースタイプでインポートされます。

高可用性ストレージを構成するためには、LINSTOR自体を使用することができます。ストレージをLINSTORの管理下に置く利点の1つは、高可用性ストレージを新しいクラスターノードに簡単に拡張できることです。

linstor_db リソースを作成した後は、LINSTOR データベースを新しいストレージに移動し、systemd マウントサービスを作成することができます。まず、現在のコントローラーサービスを停止して無効にし、後で DRBD Reactor によって管理されるためです。

次に、systemdのマウントサービスを作成してください。

/etc/systemd/system/var-lib-linstor.mount マウントファイルを、LINSTORコントローラーサービス（スタンバイコントローラーノード）を実行する可能性があるすべてのクラスターノードにコピーしてください。再度強調しますが、これらのサービスのいずれも systemctl enable しないでください。なぜなら、DRBD Reactor がそれらを管理するからです。

次のステップは、linstor_db DRBDリソースにアクセス権があるすべてのノードに LINSTOR コントローラをインストールすることです（DRBDボリュームをマウントする必要があるため、および潜在的な 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 構成ファイルを編集します。有効な昇格プラグインのセクションが次のように含まれている必要があります：

要件に応じて、on-stop-failure アクションを設定し、stop-services-on-exit を設定することも考慮してください。

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

`drbd-reactor`サービスからの警告がログにないことを確認するには、`systemctl status 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`パッケージをインストールする必要があります。例えば、DEBベースのシステムでは、次のコマンドを入力してパッケージをインストール します：

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

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

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

次に、リソースのためのボリューム定義を作成してください。

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

まず、データを保存するノード上にリソースを作成してください。

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

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

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

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

DM-Writecache による必須の4つのパラメータは、プロパティを介して設定されるか、LINSTORによって解決されます。前述のリンクに記載されているオプションのプロパティは、同様にプロパティを介して設定できます。linstor controller set-property --help を参照して、Writecache/* プロパティキーのリストを確認してください。

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

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

linstor controller set-property --help を参照し、Cache/* プロパティのキーと、省略されたプロパティのデフォルト値の一覧を確認してください。

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

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

プロバイダとその特性のリストについては、ストレージプロバイダ を参照してください。

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

LINSTORリソースは通常、1つのストレージプロバイダタイプで構成されるストレージプールによってバックアップされますが、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」リソースを作成し、–nvme-initiator`オプションを有効にした2つ目のリソースを作成します。

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

例では、最初の4つのコマンドは、各ノード（alpha`と`bravo）にネットワークインターフェース（nic1`と`nic2）を定義し、ネットワークインターフェースのIPアドレスを指定しています。最後の2つのコマンドは、LINSTORが生成するDRBDの`.res`ファイルにネットワークパスエントリを作成します。これが生成された`.res`ファイルの該当部分です。

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

LINSTORがボリュームを暗号化する前に、マスターパスフレーズを作成する必要があります。これはLINSTORクライアントで行うことができます。

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

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

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

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

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

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

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

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

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

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

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

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

ノードに配置された’resource1’という名前のリソースを想定して、そのリソースのスナップショットを作成するには、次のコマンドを入力してください。

これにより、リソースが存在するすべてのノードでスナップショットが作成されます。LINSTORは、リソースがアクティブに使用されている場合でも、一貫したスナップショットを作成します。

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

次の手順によって、スナップショットを新しいリソースに復元することができます。元のリソースがスナップショットを取得したノードから削除されていた場合でも、この操作は可能です。

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

必要に応じて追加の構成を適用できる段階になります。それから、準備ができたら、スナップショットを基にリソースを作成します。

この操作により、スナップショットが存在するすべてのノードに新しいリソースが配置されます。リソースを配置するノードを明示的に選択することもできます。詳細はヘルプを参照してください（linstor snapshot resource restore --help）。

LINSTORはリソースをスナップショットの状態に巻き戻すことができます。リソースは使用中であってはいけません。つまり、リソースはどのノードにもマウントされていてはいけません。もしリソースが使用中であれば、代わりにスナップショットを復元することで目標を達成できるかどうか考えてください。

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

リソースは、最新のスナップショットにのみロールバックできます。古いスナップショットに戻すには、まず中間のスナップショットを削除してください。

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

LINSTORクラスターでは、スナップショットの転送先を「リモート」と呼びます。現在、スナップショットを転送する際に使用できる2つの異なるタイプのリモートがあります。LINSTORリモートとS3リモートです。LINSTORリモートは、スナップショットを異なるLINSTORクラスターにまたは同じLINSTORクラスター内に転送するために使用されます。S3リモートは、スナップショットをAWS S3、MinIO、またはS3互換のオブジェクトストレージを使用する他のサービスに転送するために使用されます。リモートに転送されたスナップショットはバックアップとも呼ばれます。

スナップショットをS3リモートに送信するには、つまり、リソースのバックアップをS3リモートに作成するには、現在のクラスタがアクセスできるS3リモートを指定し、送信するリソースを指定するだけです。次のコマンドは、リソース`myRsc`のスナップショットを作成し、指定したS3リモート`myRemote`に送信します:

もし、このリソースのバックアップをこのリモートに転送するのが初めてでなく、以前のバックアップのスナップショットがまだ削除されていない場合、差分バックアップが転送されます。フルバックアップを強制的に作成するには、コマンドに --full 引数を追加してください。特定のノードにバックアップを転送させることも可能で、--node myNode を使用しますが、指定されたノードが利用できないかリソースのディスクがない場合は、別のノードが選択されます。

リモート LINSTOR を指定することで、2つの LINSTOR クラスター間でスナップショットを転送することができます。リモートの LINSTOR へのスナップショット転送には、少なくとも1つのディスクフル リソースがソース側に必要です（つまり、転送コマンドを実行する側）。

同じクラスタ内でスナップショットを転送したい場合は、単純にローカルコントローラを指す LINSTOR リモートを作成する必要があります。例えば、LINSTOR コントローラにログインしている場合は、次のコマンドを入力します。

その後、LINSTORリモートにスナップショットを送る手順に従うことができます。

特定のS3リモートに存在するバックアップを表示するには、linstor backup list myS3Remote`を使用します。リソース名をコマンドに追加して、特定のリソースのバックアップのみを表示するフィルターとして使用するには、引数–resource myRsc`を使用します。`–other`引数を使用すると、LINSTORがバックアップとして認識しないバケット内のエントリのみが表示されます。LINSTORは常にバックアップを特定の方法で命名します。リモートのアイテムがこのスキーマに従って命名されている場合は、それがLINSTORによって作成されたバックアップであると推定されるため、このリストにはそれ以外のすべてが表示されます。

LINSTORリモートに存在するバックアップを表示するには、LINSTORターゲットクラスターで`linstor snapshot list`コマンドを使用します。

バックアップの削除に関しては、いくつかのオプションがあります。

バックアップを作成した後におそらく最も重要なタスクは、それを復元することでしょう。S3リモートからバックアップを復元するには、`linstor backup restore`コマンドを使用できます。

このコマンドを使用すると、バックアップを復元するためのS3リモートの名前、ターゲットノードの名前、およびノード上の復元先リソースの名前を指定します。リソース名が既存のリソース定義と一致しない場合、LINSTORはリソース定義とリソースを作成します。

さらに、バックアップを持つリモート上のリソースの名前を指定する必要があります。これは、--resource`または–id`引数のいずれかを使用して行いますが、両方を使用することはできません。

`–resource`オプションを使用することで、指定したリソースの最新バックアップを復元することができます。例えば、以下のようになります。

`–id`オプションを使用することで、指定した正確なバックアップを復元することができます。たとえば、最新以外のリソースのバックアップを復元する場合などです。バックアップのIDを取得するには、バックアップ一覧を参照してください。

バックアップをリソースに復元すると、LINSTOR は指定したバックアップ（--id オプションを使用する場合）まで、または最新のバックアップまでのリソースの最後の完全バックアップから全てのスナップショットをダウンロードします。これらのスナップショットをダウンロードした後、LINSTOR はスナップショットを新しいリソースに復元します。backup restore コマンドに --download-only オプションを追加することで、スナップショットを新しいリソースに復元せずにスキップすることもできます。

LINSTORは、正しくセットアップされていれば、アップロードしたクラスタだけでなく、他のクラスタからもバックアップを復元するためにダウンロードできます。具体的には、対象リソースには既存のリソースやスナップショットが存在していてはならず、使用されるストレージプールは同じストレージプロバイダである必要があります。対象ノードのストレージプールがバックアップを作成したクラスタと全く同じ名前であれば、追加の操作は不要です。ただし、ノードに異なるストレージプール名がある場合は、バックアップの復元`コマンドに–storpool-rename`オプションを使用する必要があります。このオプションでは、少なくとも1つの`oldname=newname`ペアが期待されます。元のバックアップのすべてのストレージプールがそのリストに記載されていない場合、LINSTORは対象ノード上でストレージプールの名前がまったく同じであると仮定します。

正確にどのストレージプールをリネームする必要があり、ダウンロードと復元リソースのサイズがどれくらいになるかを知るには、linstor backup info myRemote …​ コマンドを使用します。リストアコマンドと同様に、--resource または --id オプションを指定する必要があります。backup info コマンドで使用する際、これらのオプションには backup restore コマンドで使用する際と同じ制限があります。リストア後にローカルストレージプールに残る空き容量を示すには、引数 -n myNode を追加します。実際のリストア操作と同様に、backup info コマンドは、対象ノードとソースノードのストレージプール名が完全に一致していると仮定します。そうでない場合は、リストアコマンドと同様に --storpool-rename オプションを使用できます。

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 までの複数のリソース定義があります。 メンテナンスのために、おそらく resdef1 と resdef2 の2つのリソース定義のスケジュールを無効にします。 その後、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オブジェクト・レベルにおいて、バックアップ出荷スケジュールが設定されていない（空のセル）、有効、または無効であるかを示すテーブルを出力します。

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

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

LINSTOR リソースオブジェクトは、一般的な LINSTOR オブジェクトの DRBD オプション設定の構文の例外です。この LINSTOR リソースオブジェクトでは、指定した2つのノード間の接続レベルで DRBD オプションを設定するために drbd-peer-options を使用できます。2つのノード間で LINSTOR リソースオブジェクトの drbd-peer-options を指定することは、2つのノード間でリソースの linstor resource-connection drbd-peer-options を使用するのと同等です。

例えば、2つのノード「node-0」と「node-1」の間で名前が「backups」のリソースに対して接続レベルでDRBDの最大バッファサイズを8192に設定する場合は、次のように入力します:

上記のコマンドは、次の操作と等価です。

実際に、`linstor –curl`コマンドを使用して、LINSTOR REST API上での2つのコマンドの動作を調べると、出力はまったく同じです。

`node-0`上のLINSTORが生成したリソースファイル`backups.res`の接続部分は、以下のようになります。

drbd-peer-options 引数を使用して、2つのノード間で DRBD オプションを接続レベルで設定することができます。例えば、

前のコマンドは、2つのノード、`node-0`と`node-1`の間の接続レベルで、DRBDの`ping-timeout`オプションを29.9秒に設定します。

`list-properties`コマンドを使用して、LINSTORオブジェクトの設定されたプロパティを確認できます。例えば：

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:

Removing a DRBD option or DRBD peer option will return the option to its default value. Refer to the linstor <LINSTOR_object> drbd-options --help (or drbd-peer-options --help) command output for the default values of options. You can also refer to the drbd.conf-9.0 man page to get information about DRBD options. === Over Provisioning Storage in LINSTOR

Since LINSTOR server version 1.26.0, it is possible to control how LINSTOR limits over provisioning storage by using three LINSTOR object properties: MaxOversubscriptionRatio, MaxFreeCapacityOversubscriptionRatio, and MaxTotalCapacityOversubscriptionRatio. You can set these properties on either a LINSTOR storage pool or a LINSTOR controller object. Setting these properties at the controller level will affect all LINSTOR storage pools in the cluster, unless the same property is also set on a specific storage pool. In this case, the property value set on the storage pool will take precedence over the property value set on the controller. By setting values for over subscription ratios, you can control how LINSTOR limits the over provisioning that you can do with your storage pools. This might be useful in cases where you do not want over provisioning of storage to reach a level that you cannot account for physically, if you needed to. The following subsections discuss the different over provisioning limiting properties. ==== Configuring a Maximum Free Capacity Over Provisioning Ratio

In LINSTOR server versions before 1.26.0, configuring over provisioning of a storage pool backed by a thin-provisioned LVM volume or ZFS zpool was based on the amount of free space left in the storage pool. In LINSTOR server versions from 1.26.0, this method of over provisioning is still possible. You do this by setting a value for the MaxFreeCapacityOversubscriptionRatio property on either a LINSTOR storage pool or the LINSTOR controller. When you configure a value for this ratio, the remaining free space in a storage pool is multiplied by the ratio value and this becomes the maximum allowed size for a new volume that you can provision from the storage pool.

By default, the MaxFreeCapacityOversubscriptionRatio has a value of 20.

To configure a different value for the MaxFreeCapacityOversubscriptionRatio property on a LINSTOR storage pool named my_thin_pool on three LINSTOR satellite nodes in a cluster, named node-0 through node-2, enter the following command:

If you had already deployed some storage resources and the storage pool had 10GiB free capacity remaining (shown by entering linstor storage-pool list), then when provisioning a new storage resource from the storage pool, you could at most provision a 100GiB volume.

Before spawning new LINSTOR resources (and volumes) from a resource group, you can list the maximum volume size that LINSTOR will let you provision from the resource group. To do this, enter a resource-group query-size-info command. For example, to list information about the DfltRscGrp resource group, enter the following command:

Output from the command will show a table of values for the specified resource group:

Since LINSTOR server version 1.26.0, there is an additional way that you can limit over provisioning storage. By setting a value for the MaxTotalCapacityOversubscriptionRatio on either a LINSTOR storage pool or LINSTOR controller, LINSTOR will limit the maximum size of a new volume that you can deploy from a storage pool, based on the total capacity of the storage pool.

This is a more relaxed way to limit over provisioning, compared to limiting the maximum volume size based on the amount of free space that remains in a storage pool. As you provision and use more storage in a storage pool, the free space decreases. However, the total capacity of a storage pool does not change, unless you add more backing storage to the storage pool.

By default, the MaxTotalCapacityOversubscriptionRatio has a value of 20.

To configure a different value for the MaxTotalCapacityOversubscriptionRatio property on a LINSTOR storage pool named my_thin_pool on three LINSTOR satellite nodes in a cluster, named node-0 through node-2, enter the following command:

If you had a storage pool backed by a thin-provisioned logical volume that had a total capacity of 10GiB, then each new storage resource that you created from the storage pool could have a maximum size of 40GiB, regardless of how much free space remained in the storage pool.

If you set the MaxOversubscriptionRatio property on either a LINSTOR storage pool or LINSTOR controller object, it can act as the value for both the MaxFreeCapacityOversubscriptionRatio and MaxTotalCapacityOversubscriptionRatio properties. However, the MaxOversubscriptionRatio property will only act as the value for either of the other two over subscription properties if the other property is not set. By default, the value for the MaxOversubscriptionRatio property is 20, the same as the default values for the other two over subscription properties.

To configure a different value for the MaxOversubscriptionRatio property on a LINSTOR controller, for example, enter the following command:

By setting the property value to 5 in the command example, you would be able to over provision a 10GiB storage pool, for example, by up to 40GiB.

As previously mentioned, the default value for each of the three over provisioning limiting LINSTOR properties is 20. If you set the same property on a storage pool and the controller, then the value of the property set on the storage pool takes precedence for that storage pool.

If either MaxTotalCapacityOversubscriptionRatio or MaxFreeCapacityOversubscriptionRatio is not set, the value of MaxOversubscriptionRatio is used as the value for the unset property or properties.

For example, consider the following commands:

Because you set the MaxTotalCapacityOversubscriptionRatio property to 3, LINSTOR will use that value for the property, rather than the value that you set for the MaxOversubscriptionRatio property. Because you did not set the MaxFreeCapacityOversubscriptionRatio property, LINSTOR will use the value that you set for the MaxOversubscriptionRatio property, 4, for the MaxFreeCapacityOversubscriptionRatio property.

When determining resource placement, that is, when LINSTOR decides whether or not a resource can be placed in a storage pool, LINSTOR will compare two values: the ratio set by the MaxTotalCapacityOversubscriptionRatio property multiplied by the total capacity of the storage pool, and the ratio set by the MaxFreeCapacityOversubscriptionRatio property multiplied by the available free space of the storage pool. LINSTOR will use the lower of the two calculated values to determine whether the storage pool has enough space to place the resource.

Consider the case of values set by earlier commands and given a total capacity of 10GiB for the storage pool. Also assume that there are no deployed LINSTOR resources associated with the storage pool and that the available free space of the storage pool is also 10GiB.

In this example, MaxTotalCapacityOversubscriptionRatio, 3, multiplied by the total capacity, 10GiB, is less than the MaxFreeCapacityOversubscriptionRatio, 4, multiplied by the free capacity, 10GiB. Remember here that because the MaxFreeCapacityOversubscriptionRatio is unset, LINSTOR uses the MaxOversubscriptionRatio value.

Therefore, when deploying a new resource backed by the storage pool, LINSTOR would use the total capacity calculation, rather than the free capacity calculation, to limit over provisioning the storage pool and determine whether a new resource can be placed. However, as you deploy more storage resources and they fill up with data, the available free space in the storage pool will decrease. For this reason, it might not always be the case that LINSTOR will use the total capacity calculation to limit over provisioning the storage pool, even though its ratio is less that the free capacity ratio.

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.

例えば、リソースの backup を alpha から bravo に移行するには、次のようにします。

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:

This property can also be set on node, resource-definition, resource and resource-connection level (from left to right in increasing priority, whereas the controller is the leftmost, that is, the least prioritized level).

Once this initialization steps are completed, every newly created resource will automatically check if it has to enable DRBD Proxy to any of its peer-resources.

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.

etcd のインストールおよび構成方法の詳細については、 etcd docs を参照ください。

以下は linstor.toml のサンプル [db] セクションです。

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.

If you want to use the REST API the current documentation can be found on the following link: https://app.swaggerhub.com/apis-docs/Linstor/Linstor/

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.

以下は Javaランタイムに含まれている keytool を使って自己署名証明書を作成する方法の簡単な例です。

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:

Now (re)start the linstor-controller and the HTTPS REST API should be available on port 3371.

More information about how to import other certificates can be found here: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html

The LINSTOR-Controller also provides a /health HTTP path that will simply return HTTP-Status 200 if the controller can access its database and all services are up and running. Otherwise it will return HTTP error status code 500 Internal Server Error.

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.

The LINSTOR Controller will prompt you for the user’s password, in each of the above examples. You can optionally use the --password argument to supply the user’s password on the command line, with all the warnings of caution that would go along with doing so.

LINSTORは、リソースにクォーラムポリシーを自動的に構成します（クォーラムが利用可能な場合）。つまり、少なくとも2つのディスクフルと1つ以上のディスクレスリソースがある場合、または3つ以上のディスクフルリソースがある場合 、LINSTORはリソースのクォーラムポリシーを自動的に有効にします。

逆に、LINSTORは、クォーラムを使用するのに必要な最低限のリソース割り当てを満たさない場合は、クォーラムポリシーを自動的に無効にします。

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

DrbdOptions/auto-quorum プロパティを disabled に設定すると、リソースのクォーラムポリシーを手動で、必要に応じてより詳細に制御できます。

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

You might 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:

サテライトが長期間オフラインになっている場合、LINSTOR は、そのノードを Evictedと宣言するように構成できます。これにより、影響を受ける DRBD リソースが他のノードに自動的に再割り当てされ、最小のレプリカ数が維持されるようになります。

This feature uses the following properties to adapt the behavior.

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 has not, 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, non-DRBD-related resources, and resources that LINSTOR could not autoplace somewhere else will still be on the satellite. To restore a satellite, use the following command:

Should you want to instead throw everything that once was on that node, including the node itself, away, you need to use the node lost command instead.

You can set the LINSTOR auto-diskful and auto-diskful-allow-cleanup properties for various LINSTOR objects, for example, a resource definition, to have LINSTOR help automatically make a Diskless node Diskful and perform appropriate cleanup actions afterwards.

This is useful when a Diskless node has been in a Primary state for a DRBD resource for more than a specified number of minutes. This could happen in cases where you integrate LINSTOR managed storage with other orchestrating and scheduling platforms, such as OpenStack, OpenNebula, and others. On some platforms that you integrate LINSTOR with, you might not have a way to influence where in your cluster a storage volume will be used.

The auto-diskful options give you a way to use LINSTOR to sensibly delegate the roles of your storage nodes in response to an integrated platform’s actions that are beyond your control.

If a device is throwing I/O errors, for example, due to physical failure, DRBD detects this state and automatically detaches from the local disk. All read and write requests are forwarded to a still healthy peer, allowing the application to continue without interruption.

This automatic detaching causes new event entries in the drbdsetup events2 stream, changing the state of a DRBD volume from UpToDate to Failed and finally to Diskless. LINSTOR detects these state changes, and automatically sets the DrbdOptions/SkipDisk property to True on the given resource. This property causes the LINSTOR satellite service running on the node with the device throwing I/O errors to attach a --skip-disk to all drbdadm adjust commands.

If this property is set, the linstor resource list command also shows it accordingly:

The (R) in this case already states that the property is set on the resource. The indicator would change to (R, N) if the property DrbdOptions/SkipDisk were to be set on the resource and on node levels.

Although this property is automatically enabled by LINSTOR, after you resolve the cause of the I/O errors, you need to manually remove the property to get back to a healthy UpToDate state:

To set the property at the node level, for example, enter the following command:

To verify that the property is set on a specified LINSTOR object, you can use the list-properties subcommand.

Output from the command will show a table of set properties and their values for the specified LINSTOR object.

To unset the property, enter the same command but do not specify a storage pool name, as in the following example:

これらの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のいずれかのボリュームになります。一方、イニシエータの場合、データバッキングデバイスは、接続されている`nvme-device`になります。その際、LUKS、NVMe、DRBDなど、その上にある他のLINSTORレイヤーがあっても関係ありません（詳細はDRBDを使わないLINSTORを参照）。

コマンドラインで利用可能なコマンドを簡単にリストアップする方法は、`linstor`と入力することです。

サブコマンドに関する追加情報（例：ノードの一覧表示）は、2つの方法で取得できます:

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

LINSTORの最も有用な機能の一つは、豊富なタブ補完機能です。これを使って、LINSTORが知っているほぼすべてのオブジェクトの補完が可能です。たとえば、ノード名、IPアドレス、リソース名などが挙げられます。以下の例では、いくつかの補完の可能性とその結果が示されています:

LINSTOR クライアントをインストールしてもタブ補完が機能しない場合は、適切なファイルをソースに指定してみてください:

Zシェルユーザー向けに、`linstor-client`コマンドはZシェルコンパイルファイルを生成できます。このファイルには、コマンドや引数の補完に基本的なサポートが備わっています。

何か問題が発生して原因を特定する必要がある場合は、次のコマンドを入力してください:

上記のコマンドは、コントローラーノードの`/var/log/linstor/controller`ディレクトリに新しい sos-report を作成します。別の方法として、以下のコマンドを入力することもできます:

このコマンドを実行すると、新しいSOSレポートが作成され、そのレポートがあなたのローカルマシンのカレントディレクトリにダウンロードされます。

このSOSレポートには、複数の情報源（LINSTORログ、dmesg、LINSTORで使用される外部ツールのバージョン、ip a、データベースのダンプなど）からのログと有用なデバッグ情報が含まれています。これらの情報は、各ノードごとにプレーンテキスト形式で`.tar.gz`ファイルに保存されます。

コミュニティからの支援を受けるには、こちらのDRBDユーザーメーリングリストに登録してください: https://lists.linbit.com/listinfo/drbd-user

バグを報告したり機能のリクエストを提出したりするには、LINBITのGitHubページをご覧ください。https://github.com/linbit

必要に応じてリモートインストールサービス、24時間365日のサポート、認定リポジトリへのアクセス、または機能開発を購入したい場合は、お問い合わせください。お問い合わせ先: +1-877-454-6248 (1-877-4LINBIT)、国際番号: +43-1-8178292-0、メール: [email protected]

オペレータを展開するには、`kustomization.yaml`ファイルを作成してください。これにより、`drbd.io`のプルシークレットを宣言し、オペレータの展開を許可します。オペレータは新しい名前空間`linbit-sds`に展開されます。`MY_LINBIT_USER`と`MY_LINBIT_PASSWORD`をご自身の認証情報に置き換えてください。最新リリースはcharts.linstor.ioで確認できます。

次に、`kubectl`コマンドを使用して`kustomization.yaml`ファイルを適用し、オペレーターの開始を待ちます:

オペレーターはLINBIT SDS for Kubernetes を展開する準備が整いました。

KubernetesでのLINBIT SDSのオペレーターv2をデプロイするのは、新しい`LinstorCluster`リソースを作成して、オペレーターがセットアップを完了するのを待つだけで簡単です:

出力には、待機条件が満たされ、LINBIT SDSポッドが起動して実行されていることが最終的に表示されるはずです。

Helmを使用してLINSTOR Operator v2を作成するには、まず次のコマンドを入力して`linstor` Helmチャートリポジトリを追加してください:

次に、次のコマンドを入力して、LINSTOR Operator v2をインストールしてください:

コマンドの出力により、Operator v2 がインストールされたことが確認できたら、Helm を使用して linbit-sds チャートをインストールして LINBIT SDS をデプロイできます:

この最終的な helm install コマンドの出力には、成功メッセージが表示されるべきです。

デフォルトでは、LINBIT SDS for Kubernetesはストレージを構成しません。ストレージを追加するには、Operatorが1つ以上のサテライトを構成するために使用する「LinstorSatelliteConfiguration」を構成できます。

次の例は、シンプルな`FILE_THIN`プールを作成し、ホストへの追加設定は不要です:

他の種類のストレージプールも設定することができます。詳細は、以下のリンクを参照してください。https://github.com/piraeusdatastore/piraeus-operator/blob/v2/docs/reference/linstorsatelliteconfiguration.md#specstoragepools[upstreamの例]。

キーと証明書に基づく暗号化を設定することで、例えば、LINSTORのサテライトノードとLINSTORコントローラーノード、またはLINSTORクライアントとLINSTOR API間など、特定のLINSTORコンポーネント間の通信をより安全にすることができます。

After deploying LINBIT SDS for Kubernetes, you can continue with the [s-kubernetes-basic-configuration-and-deployment], Operator v2デプロイメントにおけるDRBDモジュールローダーの設定:, Operator v2 デプロイメントにおいて DRBD レプリケーション用ホストネットワークを使用する sections in this chapter, or refer to the available tutorials in the upstream Piraeus project. === LINSTOR Operator v1のデプロイメント

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

The LINSTOR controller can use the Kubernetes API directly to persist its cluster state. To enable this back end, use the following override file during the chart installation:

You can use the pv-hostpath Helm templates to create hostPath persistent volumes. Create as many PVs as needed to satisfy your configured etcd replicas (default 1).

Create the hostPath persistent volumes, substituting cluster node names accordingly in the nodes= option:

By default, a PV is created on every control-plane node. You can manually select the storage nodes by passing --set "nodes={<NODE0>,<NODE1>,<NODE2>}" to the install command. NOTE: The correct value to reference the node is the value of the kubernetes.io/hostname label. You can list the value for all nodes by running kubectl get nodes -o custom-columns="Name:{.metadata.name},NodeName:{.metadata.labels['kubernetes\.io/hostname']}" ==== 既存のデータベースの使用

LINSTOR can connect to an existing PostgreSQL, MariaDB or etcd database. For instance, for a PostgreSQL instance with the following configuration:

The Helm chart can be configured to use this database rather than deploying an etcd cluster, by adding the following to the Helm install command:

The LINSTOR Operator v1 can automate some basic storage set up for LINSTOR.

The default communication between LINSTOR components is not secured by TLS. If this is needed for your setup, choose one of three methods: // “cert-manager” is a product name so keep the original case

All the below examples use the following sp-values.yaml file. Feel free to adjust this for your uses and environment. See [Configuring storage pool creation] for further details.

Install with LINSTOR storage-pools defined at install through sp-values.yaml, persistent hostPath volumes, three etcd replicas, and by compiling the DRBD kernel modules for the host kernels.

This should be adequate for most basic deployments. Note that this deployment is not using the pre-compiled DRBD kernel modules just to make this command more portable. Using the pre-compiled binaries will make for a much faster install and deployment. Using the Compile option would not be suggested for use in a large Kubernetes clusters.

Install with LINSTOR storage-pools defined at install through sp-values.yaml, use an already created PostgreSQL DB (preferably clustered), rather than etcd, and use already compiled kernel modules for DRBD.

The PostgreSQL database in this particular example is reachable through a service endpoint named postgres. PostgreSQL itself is configured with POSTGRES_DB=postgresdb, POSTGRES_USER=postgresadmin, and POSTGRES_PASSWORD=admin123

To protect the storage infrastructure of the cluster from accidentally deleting vital components, it is necessary to perform some manual steps before deleting a Helm deployment.

The Helm charts provide a set of further customization options for advanced use cases.

To create a high-availability deployment of all components within a LINSTOR Operator v1 deployment, consult the upstream guide The default values are chosen so that scaling the components to multiple replicas ensures that the replicas are placed on different nodes. This ensures that a single node failures will not interrupt the service. NOTE: If you have deployed LINBIT SDS in Kubernetes by using the LINSTOR Operator v2, high availability is built into the deployment by default. ===== 高可用性コントローラーを使用した高速ワークロードフェイルオーバー

When node failures occur, Kubernetes is very conservative in rescheduling stateful workloads. This means it can take more than 15 minutes for Pods to be moved from unreachable nodes. With the information available to DRBD and LINSTOR, this process can be sped up significantly.

The LINSTOR High Availability Controller (HA Controller) speeds up the failover process for stateful workloads using LINSTOR for storage. It monitors and manages any Pod that is attached to at least one DRBD resource.

For the HA Controller to work properly, you need quorum, that is at least three replicas (or two replicas + one diskless tiebreaker). If using lower replica counts, attached Pods will be ignored and are not eligible for faster failover.

The HA Controller is packaged as a Helm chart, and can be deployed using:

If you are using the HA Controller in your cluster you can set additional parameters in all StorageClasses. These parameters ensure that the volume is not accidentally remounted as read-only, leading to degraded Pods.

To exempt a Pod from management by the HA Controller, add the following annotation to the Pod:

To create a backup of the etcd database (in LINSTOR Operator v1 deployments) and store it on your control host, enter the following commands:

These commands will create a file save.db on the machine you are running kubectl from. === LINSTORオペレーターを使用したデプロイ

The Operator can configure the satellites and CSI plugin to use an existing LINSTOR setup. This can be useful in cases where the storage infrastructure is separate from the Kubernetes cluster. Volumes can be provisioned in diskless mode on the Kubernetes nodes while the storage nodes will provide the backing disk storage. ==== 外部LINSTORコントローラを使用したOperator v2のデプロイメント ===== `LinstorCluster`リソースの設定

To use an externally managed LINSTOR cluster, specify the URL of the LINSTOR controller in the LinstorCluster resource in a YAML configuration and apply it to your deployment. In the following example, the LINSTOR controller is reachable at http://linstor-controller.example.com:3370.

Normally the pod network is not reachable from outside the Kubernetes cluster. In this case the external LINSTOR controller would not be able to communicate with the satellites in the Kubernetes cluster. For this reason, you need to configure your satellites to use host networking.

To use host networking, deploy a LinstorSatelliteConfiguration resource by applying the following YAML configuration to your deployment:

To skip the creation of a LINSTOR controller deployment and configure the other components to use your existing LINSTOR controller, use the following options when running helm install:

After all pods are ready, you should see the Kubernetes cluster nodes as satellites in your LINSTOR setup.

Create a storage class referencing an existing storage pool on your storage nodes.

You can provision new volumes by creating PVCs using your storage class. The volumes will first be placed only on nodes with the given storage pool, that is, your storage infrastructure. Once you want to use the volume in a pod, LINSTOR CSI will create a diskless resource on the Kubernetes node and attach over the network to the diskful resource. === Kubernetes で LINSTOR の操作

The controller pod includes a LINSTOR Client, making it easy to interact directly with LINSTOR. For example:

To simplify entering LINSTOR client commands within a Kubernetes deployment, you can use the kubectl-linstor utility. This utility is available from the upstream Piraeus datastore project. To download it, enter the following commands on your Kubernetes control plane node:

To install the utility, first extract it and then move the extracted executable file to a directory in your $PATH, for example, /usr/bin. Then you can use kubectl-linstor to get access to the complete LINSTOR CLI.

It also expands references to PVCs to the matching LINSTOR resource.

It also expands references of the form pod:[<namespace>/]<podname> into a list resources in use by the pod. This should only be necessary for investigating problems and accessing advanced functionality. Regular operation such as creating volumes should be achieved through the Kubernetes integration. === KubernetesでのLINBIT SDSストレージの始め方

Once all linstor-csi Pods are up and running, you can provision volumes using the usual Kubernetes workflows.

Configuring the behavior and properties of LINSTOR volumes deployed through Kubernetes is accomplished using Kubernetes StorageClass objects.

Here below is the simplest practical StorageClass that can be used to deploy volumes:

You can create the storage class with the following command:

Now that your storage class is created, you can now create a persistent volume claim (PVC) which can be used to provision volumes known both to Kubernetes and LINSTOR:

You can create the PersistentVolumeClaim with the following command:

This will create a PersistentVolumeClaim, but no volume will be created just yet. The storage class we used specified volumeBindingMode: WaitForFirstConsumer, which means that the volume is only created once a workload starts using it. This ensures that the volume is placed on the same node as the workload.

For our example, we create a simple Pod, which mounts or volume by referencing the PersistentVolumeClaim. .my-first-linstor-volume-pod.yaml

You can create the Pod with the following command:

Running kubectl describe pod fedora can be used to confirm that Pod scheduling and volume attachment succeeded. Examining the PersistentVolumeClaim, we can see that it is now bound to a volume.

To remove a volume, verify that no pod is using it and then delete the PersistentVolumeClaim using the kubectl command. For example, to remove the volume that we just made, run the following two commands, noting that the Pod must be unscheduled before the PersistentVolumeClaim will be removed:

The following storage class contains all currently available parameters to configure the provisioned storage.

As shown in the StorageClass で使用可能なパラメータ section, you can set DRBD options within a storage class configuration. Because of the one-to-one correspondence between a StorageClass Kubernetes object and its named LINSTOR resource group (resourceGroup parameter), setting DRBD options within a storage class configuration is similar to setting DRBD options on the LINSTOR resource group.

There are some differences. If you set DRBD options within a storage class configuration, these options will only affect new volumes that are created from the storage class. The options will not affect existing volumes. Furthermore, because you cannot just update the storage class, you will have to delete it and create it again if you add DRBD options to the storage class’s configuration. If you set DRBD options on the LINSTOR resource group object (linstor resource-group set-property <rg-name> DrbdOptions/<option-name>), changes will affect future and existing volumes belonging to the resource group.

Because of the potential pitfalls here, it is simpler to set DRBD options on the LINSTOR controller object. DRBD options set on the controller will apply to all resources groups, resources, and volumes, unless you have also set the same options on any of those LINSTOR objects. Refer to the LINSTORのオブジェクト階層 section for more details about LINSTOR object hierarchy.

You can list the properties, including DRBD options, that you can set on the LINSTOR controller object by entering the following command:

The csi.storage.k8s.io/fstype parameter sets the file system type to create for volumeMode: FileSystem PVCs. Currently supported are: * ext4 (default) * xfs ==== autoPlace

autoPlace is an integer that determines the amount of replicas a volume of this StorageClass will have. For example, autoPlace: "3" will produce volumes with three-way replication. If neither autoPlace nor nodeList are set, volumes will be automatically placed on one node. IMPORTANT: If you use this option, you must not use nodeList. IMPORTANT: You have to use quotes, otherwise Kubernetes will complain about a malformed StorageClass. TIP: This option (and all options which affect auto-placement behavior) modifies the number of LINSTOR nodes on which the underlying storage for volumes will be provisioned and is orthogonal to which kubelets those volumes will be accessible from.

placementCount is an alias for autoPlace

The LINSTOR Resource Group (RG) to associate with this StorageClass. If not set, a new RG will be created for each new PVC. ==== storagePool

storagePool is the name of the LINSTOR storage pool that will be used to provide storage to the newly-created volumes. CAUTION: Only nodes configured with this same storage pool with be considered for auto-placement. Likewise, for StorageClasses using nodeList all nodes specified in that list must have this storage pool configured on them. ==== disklessStoragePool

disklessStoragePool is an optional parameter that only affects LINSTOR volumes that are assigned as “diskless” to kubelets, that is, as clients. If you have a custom diskless storage pool defined in LINSTOR, you will specify that here.

A comma-separated list of layers to use for the created volumes. The available layers and their order are described towards the end of this section. Defaults to drbd,storage ==== placementPolicy

Select from one of the available volume schedulers: * AutoPlaceTopology, the default: Use topology information from Kubernetes together with user provided constraints (see [s-kubernetes-replicasonsame] and [s-kubernetes-replicasondifferent]). * AutoPlace Use the LINSTOR auto-placement feature, influenced by [s-kubernetes-replicasonsame] and [s-kubernetes-replicasondifferent] * FollowTopology: Use CSI Topology information to place at least one volume in each “preferred” zone. Only usable if CSI Topology is enabled. * Manual: Use only the nodes listed in nodeList and clientList. * Balanced: EXPERIMENTAL Place volumes across failure domains, using the least used storage pool on each selected node. ==== allowRemoteVolumeAccess

Control on which nodes a volume is accessible. The value for this option can take two different forms:

encryption is an optional parameter that determines whether to encrypt volumes. LINSTOR must be configured for encryption for this to work properly. ==== nodeList

nodeList is a list of nodes for volumes to be assigned to. This will assign the volume to each node and it will be replicated among all of them. This can also be used to select a single node by hostname, but it’s more flexible to use replicasOnSame to select a single node. IMPORTANT: If you use this option, you must not use autoPlace. TIP: This option determines on which LINSTOR nodes the underlying storage for volumes will be provisioned and is orthogonal from which kubelets these volumes will be accessible.

clientList is a list of nodes for diskless volumes to be assigned to. Use in conjunction with [s-kubernetes-nodelist]. ==== replicasOnSame

replicasOnDifferent takes a list of properties to consider, same as replicasOnSame. There are two modes of using replicasOnDifferent: * Preventing volume placement on specific nodes: + If a value is given for the property, the nodes which have that property-value pair assigned will be considered last. + Example: replicasOnDifferent: "no-csi-volumes=true" will place no volume on any node with property no-csi-volumes=true unless there are not enough other nodes to fulfill the autoPlace setting. * Distribute volumes across nodes with different values for the same key: + If no property value is given, LINSTOR will place the volumes across nodes with different values for that property if possible. + Example: Assuming there are 4 nodes, node-a1 and node-a2 are configured with zone=a. node-b1 and node-b2 are configured with zone=b. Using a StorageClass with autoPlace: "2" and replicasOnDifferent: "zone", LINSTOR will create one replica on either node-a1 or node-a2 and one replica on either node-b1 or node-b2.

Create a diskless resource on all nodes that were not assigned a diskful resource.

Do not place the resource on a node which has a resource with a name matching the regular expression. ==== fsOpts fsOpts`は、作成時にボリュームのファイルシステムにオプションを渡すオプションパラメータです。 IMPORTANT: これらの値は選択したファイルシステムに固有です。 ==== `mountOpts `mountOpts`は、マウント時にボリュームのファイルシステムにオプションを渡すオプションパラメータです。

Extra arguments to pass to xfs_io, which gets called before right before first use of the volume. ==== property.linstor.csi.linbit.com/*

Parameters starting with property.linstor.csi.linbit.com/ are translated to LINSTOR properties that are set on the Resource Group associated with the StorageClass.

For example, to set DrbdOptions/auto-quorum to disabled, use:

The full list of options is available here

Snapshots create a copy of the volume content at a particular point in time. This copy remains untouched when you make modifications to the volume content. This, for example, enables you to create backups of your data before performing modifications or deletions on your data. Because a backup is useless unless you have a way to restore it, this section describes how to create a snapshot, and how to restore it, for example, in the case of accidental deletion of your data. The next subsection contains instructions around snapshots within Operator v2 deployments. If you have deployed LINBIT SDS in Kubernetes by using Operator v1, skip ahead to the [s-kubernetes-add-snaphot-support-v1] subsection. ==== スナップショットとの使用

Before you can add snapshot support within a LINBIT SDS deployment, you need to meet the following environment prerequisites:

LINSTORは、災害復旧のためにS3互換ストレージ上にスナップショットを保存することができます。これは、特別なVolumeSnapshotClassを使用してKubernetesに統合されています:

snap.linstor.csi.linbit.com/ パラメータの正確な意味については、スナップショットの転送 セクションの手順書を参照してください。ログインに使用される資格情報は、上記の例に示されているように、別個のシークレットに保存されています。

上記のストレージクラスを参照してスナップショットを作成すると、スナップショットが自動的に構成されたS3ストレージにアップロードされます。

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

いくつかの状況下では、DRBDモジュールローダーを完全に無効にする必要がある場合があります。たとえば、イミュータブルなオペレーティングシステムを使用していて、DRBDや他のモジュールがホスト設定の一部としてロードされている場合などです。

DRBDモジュールローダーを完全に無効にするには、次のYAML構成をデプロイメントに適用してください:

デフォルトでは、Operatorはホストのオペレーティングシステムに一致するDRBDモジュールローダーを見つけようとします。Operatorは、Kubernetesの`Node`リソースの`.status.nodeInfo.osImage`フィールドを調査することでホストディストリビューションを判別します。自動マッピングが成功しない場合や異なるモジュールローディング要件がある場合は、ユーザー定義のイメージを使用できます。

次のYAML構成は、選択したDRBDモジュールローダーのイメージをユーザー定義のイメージ example.com/drbd-loader:v9 で上書きします。

`drbd.io`は、LINBITの顧客のみが利用可能で、以下のモジュールローダーコンテナイメージを維持しています。

自分自身のディストリビューション用のモジュールローダーイメージを作成する必要がある場合は、上流のPiraeusプロジェクトで利用可能な[the container source files][コンテナのソースファイル]にアクセスすることができます。詳細はリンク:https://github.com/piraeusdatastore/piraeus/tree/master/dockerfiles/drbd-driver-loader をご参照ください。

デフォルトでは、DRBDモジュールローダーはソースからカーネルモジュールをビルドしようとします。モジュールローダーは、イメージに含まれるDEBやRPMパッケージからモジュールを読み込むように構成することもでき、また、完全にDRBDの読み込みをスキップすることもできます。

DRBDモジュールローダーの動作を変更するには、`LB_HOW`環境変数を、以下の表に示されている適切な値に設定してください。

`LB_HOW`環境変数を設定した後、デプロイメントに以下のYAML構成を適用してください。メタデータセクション内の名前に基づいて、以下の例は`LB_HOW`環境変数が`deps_only`に設定されている場合に使用されます。

デフォルトのコンテナネットワークからホストネットワークに切り替えて DRBD レプリケーションを行うことはいつでも可能です。既存の DRBD リソースはその後、ホストネットワークインターフェイスを使用するように再構成されます。

サテライトのホストネットワークを設定するには、次のYAML構成をデプロイメントに適用してください。

サテライトポッドが再作成されると、ホストネットワークを使用します。既存の DRBD リソースは、コンテナネットワーク上の IP アドレスではなく、ホストネットワーク上の新しい IP アドレスを使用するように再構成されます。

ホストネットワークからコンテナーネットワークに戻す際には、DRBDで使用される構成されたピアアドレスを手動でリセットする必要があります。この作業は、すべてのノードを再起動するか、各ノードで drbdadm CLIコマンドを使用してアドレスを手動でリセットすることによって行うことができます。それぞれの方法について以下に説明します。

[[s-kubernetes-drbd-replication-switching-from-host-to-container-network-node-rebooting-v2 ===== ホストからコンテナネットワークへのDRBDレプリケーション切り替えのためにノードを再起動します。

最初に、hostNetwork: true を設定した LinstorSatelliteConfiguration を削除する必要があります。次の kubectl コマンドを入力することでこれを行うことができます：

次に、各クラスターノードを順次または一度にすべて再起動します。一般的に、再起動したノードと再起動していないノードの間でレプリケーションは機能しません。 再起動していないノードはホストネットワークアドレスを引き続き使用し、これらは通常、コンテナネットワークから到達できません。

全てのノードが再起動された後、全てのリソースはコンテナネットワークを使用するように構成され、全ての DRBD 接続が再度接続されるはずです。

[[s-kubernetes-drbd-replication-switching-from-host-to-container-network-node-drbdadm-v2 ===== DRBD管理ツールを使用して、ホストからコンテナネットワークへのDRBDレプリケーションの切り替え

まず、`drbdadm suspend-io all`コマンドを使用してすべてのDRBDレプリケーションを一時停止し、すべてのDRBDボリュームI/O操作を一時停止する必要があります。各LINSTORサテライトポッドでコマンドを一度入力してください。

次に、すべてのノードですべてのDRBD接続を切断してください。

次に、すべてのDRBD接続パスを安全にリセットできます。これにより、各ノード上の接続がコンテナネットワークに移動できます。

最後に、`hostNetwork: true`を設定した`LinstorSatelliteConfiguration`リソース構成を削除します。これにより、コンテナネットワークを使用する新しいLINSTORサテライトポッドが作成されます。

ポッドが再作成され、LINSTORのサテライトが オンライン になった後、DRBDリソースは再構成され、I/O操作が再開されます。

このセクションでは、LINSTOR Operator v2のKubernetesにおけるPrometheusを用いたモニタリングの設定方法について説明します。LINSTOR Operator v1デプロイメントの場合は、Operator v1 デプロイメントでの Prometheusによるモニタリングセクションの手順を参照してください。

Operator v1デプロイメントでは、オペレーターは既存のコンポーネントに沿ってモニタリングコンテナをセットアップし、それらを Service として利用可能にします。

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

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

LINSTORをOperator v2を使用してデプロイした場合、LINBIT SDSをアップグレードするには、新しいバージョンのLINSTOR Operatorをデプロイすることができます。

LINBIT SDSのアップグレード方法は、元のデプロイメント方法によって異なります。

新しいリリースにアップグレードする前に、LINSTORデータベースの最新バックアップがあることを確認してください。LINSTOR Chartにパッケージ化されたetcdデータベースを使用している場合は、こちらを参照してください。

アップグレードは、次のコンポーネントを新しいバージョンに更新します。

一部のバージョンでは特別な手順が必要です。 こちら を参照ください。LINSTOR オペレーターの新しいバージョンにアップグレードするための主なコマンドは次のとおりです。

初期インストールでカスタマイズを使用した場合は、同じオプションを helm upgrade に渡します。現在使用されているオプションは、Helm から取得できます。

これにより、新しい pod のロールアウトがトリガーされます。少し待つと、すべての pod が実行され、準備が整います。LinstorControllers、LinstorSatelliteSets、および LinstorCSIDrivers のステータスセクションにエラーがリストされていないことを確認してください。

既存のKubernetes内のLINBIT SDSデプロイメントを、LINSTOR Operator v1デプロイメントからOperator v2デプロイメントにアップグレードするには、こちらの移行手順に従うことができます。

このアップグレードを行う際に、LINSTORサテライトポッドにアタッチされている既存のストレージボリュームに影響を与えずに行うことが可能です。ただし、Operator v2デプロイメントへのマイグレーション中は、新しいボリュームを作成したり、既存のボリュームをアタッチまたはデタッチすることはできません。新しいデプロイメントを展開するまでです。

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

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

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

次の手順は、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サテライトを開始します。