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の 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

You can configure LINSTOR to encrypt storage volumes, by using LUKS (dm-crypt), as detailed in the Encrypted Volumes section of this user guide. Refer to the LUKS and dm-crypt projects for FIPS compliance status.

You can also configure LINSTOR to encrypt communication traffic between a LINSTOR satellite and a LINSTOR controller, by using SSL/TLS, as detailed in the Secure Satellite Connections section of this user guide.

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/ から利用可能です。

Before upgrading LINSTOR, you should back up the LINSTOR controller database. If you are using the embedded default H2 database and you upgrade the linstor-controller package, an automatic backup file of the database will be created in the default /var/lib/linstor directory. This file is a good restore point if a linstor-controller database migration should fail. It is recommended to report the error to LINBIT and restore the old database file and roll back to your previous controller version.

If you use any external database or etcd, make a manual backup of your current database, before upgrading LINSTOR. You can use this backup as a restore point if needed.

On RPM-based Linux distributions, LINSTOR services are not automatically restarted when you upgrade LINSTOR packages. For this reason, the upgrading process does not entail as much downtime for your LINSTOR services (LINSTOR control plane) as it might on other systems.

On all nodes, update applicable LINSTOR packages. Modify the command below to only update packages applicable to each node’s role in your LINSTOR cluster:

After updating LINSTOR packages on all nodes, as simultaneously as you can, restart the LINSTOR satellite service on all your satellite nodes, except for the actively running controller node if that node is in a combined role.

Next, restart the LINSTOR controller service on the node where the service is actively running. If that node is in a combined role, also update the LINSTOR satellite service, for example:

On DEB-based Linux systems, because LINSTOR services will restart automatically after installing an updated version, you will need to plan for more downtime of the LINSTOR control plane than on an RPM-based system.

First, upgrade the LINSTOR controller software on the active LINSTOR controller node.

Upgrading the software will automatically restart the controller service. At this point, if you enter a linstor node list command, output will show that your satellite nodes are in an OFFLINE(VERSION MISMATCH) state.

Next, update the LINSTOR client and satellite packages on nodes where those packages are installed. Modify the command below to only update packages applicable to each node’s role in your LINSTOR cluster:

Uprading the LINSTOR satellite software package on your satellite (and combined) nodes will automatically restart the LINSTOR satellite service on those nodes.

After upgrading all LINSTOR packages applicable to each node in your cluster, verify:

あるいは、/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 でオンラインの状態が表示されます。もちろん、サテライトプロセスは、コントローラがサテライトノードの存在を把握する前に開始される可能性があります。

他のサービスが必要なデバイスを作成する機会を待つようにしたい場合（つまり、起動後）、対応する .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 コマンドを入力します。

サテライトノードでサポートされているストレージプロバイダやストレージレイヤをリストアップするには、node info コマンドを使用することができます。クラスタ内でストレージオブジェクトを作成する前やトラブルシューティングの状況にある場合は、LINSTORを使用する前にそれを行ってください。

コマンドの出力には2つのテーブルが表示されます。最初のテーブルでは利用可能な LINSTOR storage provider バックエンドが表示されます。2番目のテーブルでは利用可能な LINSTOR storage layers が表示されます。両方のテーブルで、特定のノードがストレージプロバイダーまたはストレージレイヤーをサポートしているかどうかが示されます。プラス記号「+」は”サポートされています”を、マイナス記号「-」は”サポートされていません”を表します。

クラスターの例の出力は、以下のようなものに類似しているかもしれません。

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

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

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

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

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

Both the Exos and LVM2 storage providers offer the option of multiple server nodes directly connected to the storage array and drives. You can use the LINSTOR storage-pool create command option --shared-space when configuring a LINSTOR pool to use the same LVM2 volume group accessible by two or more nodes.

The following example shows using the LVM2 volume group UUID as the shared space identifier for a storage pool accessible by nodes alpha and bravo:

This example also uses the --external-locking option. By using this option, you tell LINSTOR not to use its internal locking mechanism for shared storage pools but rather use LVM’s mechanism in this example.

You can omit both the --shared option for vgcreate and the --external-locking option for linstor storage-pool create. If you do this, LINSTOR will use its own mechanism to take care that only one node in the same --shared-space grouping will use LVM. Using LINSTOR’s internal mechanism to lock LVM use will not however limit the access to single volumes. Neither LINSTOR’s nor LVM’s locking mechanism, for example, will limit DRBD I/O.

Exos pools will use the Exos pool serial number by default for the --shared-space identifier.

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 バージョンが、データベースバックアップを作成したバージョンよりも新しい場合、バックアップをインポートする際にデータはエクスポート時に使用されたバージョンのデータベーススキーマと同じで復元されます。その後、コントローラが再起動すると、データベースが古いスキーマであることを検知し、自動的にデータを現在のバージョンのスキーマに移行します。

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

This allows the user to convert, for example, from an etcd setup to an SQL based setup. There is no special command for converting the database format. You only have to specify the correct linstor.toml configuration file by using the --config-directory argument (or updating the default /etc/linstor/linstor.toml and specifying the database type that you want to use before importing). See the LINSTOR User Guide for more information about specifying a database type. Regardless of the type of database that the backup was created from, it will be imported in the database type that is specified in the linstor.toml configuration file.

高可用性ストレージを構成するためには、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オブジェクトの設定されたプロパティを確認できます。例えば：

以前に設定されたDRBDオプションを削除するには、オプション名の前に unset- を付けます。例えば:

同じ構文は、LINSTORリソース、リソース接続、またはノード接続上に設定された drbd-peer-options に適用されます。例えば::

DRBDオプションまたはDRBDピアオプションを削除すると、オプションがデフォルト値に戻ります。オプションのデフォルト値については、 linstor <LINSTOR_object> drbd-options --help（または drbd-peer-options --help ）コマンドの出力を参照してください。DRBDオプションに関する情報は、 drbd.conf-9.0 のmanページも参照できます。 === LINSTORにおけるストレージの過剰割り当て

LINSTORサーバーバージョン1.26.0以降、LINSTORがオーバープロビジョニングストレージを制限する方法を制御することができるようになりました。これには MaxOversubscriptionRatio 、MaxFreeCapacityOversubscriptionRatio 、 MaxTotalCapacityOversubscriptionRatio の3つのLINSTORオブジェクトプロパティを使用します。これらのプロパティは、LINSTORストレージプールまたはLINSTORコントローラーオブジェクトのいずれかに設定できます。これらのプロパティをコントローラーレベルで設定すると、クラスター内のすべてのLINSTORストレージプールに影響します。ただし、同じプロパティが特定のストレージプールにも設定されている場合は、そのストレージプールにのみ影響します。この場合、ストレージプールに設定されたプロパティ値がコントローラに設定されたプロパティ値より優先されます。オーバーサブスクリプション比率の値を設定することで、LINSTORがストレージプールで行うオーバープロビジョニングを制御することができます。物理的に説明できないレベルにストレージのオーバープロビジョニングが達することを望まない場合に便利です。次のサブセクションでは、異なるオーバープロビジョニング制限プロパティについて説明します。 ==== 最大空き容量オーバープロビジョニング比率の設定

LINSTORサーバーのバージョン1.26.0より前では、薄膜プロビジョニングされたLVMボリュームまたはZFS zpoolでバックアップされた ストレージプールのオーバープロビジョニングを設定する際、ストレージプール内に残っている空き容量に基づいていました。 LINSTORサーバーのバージョン1.26.0以降では、このオーバープロビジョニングの方法はまだ可能です。 MaxFreeCapacityOversubscriptionRatio プロパティに値を設定することで、LINSTOR ストレージプールまたは LINSTOR コントローラのいずれかに、これを実行できます。この比率の値を設定すると、ストレージプール内の残りの空き容量は 比率値によって乗算され、これがストレージプールからプロビジョニングできる新しいボリュームの最大許容サイズとなります。

デフォルトで、MaxFreeCapacityOversubscriptionRatio の値は 20 になっています。

LINSTORサテライトノードクラスターにある3つのLINSTORサテライトノード（node-0からnode-2まで）上の my_thin_pool というLINSTORストレージプールの MaxFreeCapacityOversubscriptionRatio プロパティに異なる値を設定するには、以下のコマンドを入力してください:

もしすでにいくつかのストレージリソースをデプロイメントしており、ストレージプールには 10GiBの空き容量が残っている場合（ linstor storage-pool list を入力して表示される）、 そのストレージプールから新しいストレージリソースをプロビジョニングする際には、最大100GiBのボリュームをプロビジョニングできます。

新しいリソースグループから新しいLINSTORリソース（およびボリューム）を作成する前に、 LINSTORがそのリソースグループから設定できる最大ボリュームサイズをリストすることができます。 これを行うには、resource-group query-size-info コマンドを入力してください。たとえば、 DfltRscGrp リソースグループに関する情報を表示するには、次のコマンドを入力します。:

コマンドの出力には、指定されたリソースグループの値の表が表示されます。

LINSTORサーバーバージョン1.26.0以降、オーバープロビジョニングストレージを制限する別の方法が追加されました。LINSTORストレージプールまたはLINSTORコントローラーの MaxTotalCapacityOversubscriptionRatio の値を設定することで、LINSTORはストレージプールの総容量に基づいて、新しいボリュームの最大サイズを制限します。

これは、ストレージプール内に残っている空き容量に基づいて最大ボリュームサイズを制限する方法と比較して、オーバープロビジョニングを制限するよりもリラックスしている方法です。ストレージプール内でストレージをプロビジョニングし使用すると、空き容量が減少します。しかし、ストレージプールの総容量は、ストレージプールにバッキングストレージを追加しない限り変わりません。

デフォルトで、「MaxTotalCapacityOversubscriptionRatio」の値は20です。

異なる値を設定するには、クラスタ内の3つのLINSTORサテライトノード（ node-0 から node-2 まで）の my_thin_pool というLINSTORストレージプールの MaxTotalCapacityOversubscriptionRatio プロパティに対して、次のコマンドを入力してください：

もし、合計容量が10GiBの薄いプロビジョンの論理ボリュームでバックアップされた ストレージプールがある場合、そのストレージプールから作成した新しいストレージリソースは、 ストレージプールに残っている空き容量に関係なく、最大サイズが40GiBになります。

MaxOversubscriptionRatio プロパティをLINSTORストレージプールやLINSTORコントローラーオブジェクトのいずれかに設定した場合、それは MaxFreeCapacityOversubscriptionRatio および MaxTotalCapacityOversubscriptionRatio プロパティの両方の値として機能することができます。ただし、MaxOversubscriptionRatio プロパティは、他の2つのオーバーサブスクリプションプロパティのいずれかの値としてのみ機能しますが、他のプロパティが設定されていない場合です。デフォルトでは、MaxOversubscriptionRatio プロパティの値は20であり、他の2つのオーバーサブスクリプションプロパティのデフォルト値と同じです。

LINSTORコントローラーの MaxOversubscriptionRatio プロパティに異なる値を設定するには、例えば、次のコマンドを入力してください：

コマンド例でプロパティ値を5に設定することで、10GiBのストレージプールを最大40GiBまで オーバープロビジョニングすることができます。

前述の通り、3つのオーバープロビジョニング制限 [LINSTOR] プロパティのデフォルト値はそれぞれ20です。ストレージプールとコントローラーの同じプロパティを設定した場合、そのストレージプールにおいてストレージプールに設定されているプロパティの値が優先されます。

MaxTotalCapacityOversubscriptionRatio または MaxFreeCapacityOversubscriptionRatio のどちらかが設定されていない場合、MaxOversubscriptionRatio の値が未設定のプロパティまたはプロパティの値として使用されます。

例えば、次のコマンドを考えてみましょう:

MaxTotalCapacityOversubscriptionRatio プロパティを3に設定したため、LINSTORは その値を使用します。MaxOversubscriptionRatio プロパティに設定した値ではなく MaxFreeCapacityOversubscriptionRatio プロパティを設定しなかったため、LINSTORは MaxOversubscriptionRatio プロパティに設定した値である4を MaxFreeCapacityOversubscriptionRatio プロパティに使用します。

リソース配置を決定する際、つまり、LINSTORがリソースをストレージプールに配置できるかどうかを決定する際、 LINSTORは2つの値を比較します: MaxTotalCapacityOversubscriptionRatio プロパティによって設定された比率に ストレージプールの総容量を乗じた値と、 MaxFreeCapacityOversubscriptionRatio プロパティによって設定された比率にストレージプールの利用可能な空き容量を乗じた値です。 LINSTORは、これら2つの計算値のうち小さい方を使用して、ストレージプールにリソースを 配置する十分なスペースがあるかどうかを判断します。

前のコマンドで設定された値と、ストレージプールの合計容量が10GiBである場合を考えて みましょう。また、ストレージプールに関連付けられたデプロイされたLINSTORリソースが ないと仮定し、ストレージプールの利用可能な空き容量も10GiBであるとします。

注意: この例は単純化されています。例えば、ストレージプールの背後にあるストレージプロバイダ （例: ZFSやLVM）によっては、デプロイされたリソースがないストレージプールでは、空き容量が 総容量と等しくないことがあります。これは、デプロイされたリソース以前に、ストレージ プロバイダのインフラストラクチャによるオーバーヘッドがストレージプールのスペースを 使用しているためです。

この例では、MaxTotalCapacityOversubscriptionRatio 3 が、総容量 10GiB に乗じた値が、 MaxFreeCapacityOversubscriptionRatio 4 が、空き容量 10GiB に乗じた値よりも 小さいです。ここで覚えておいてください、MaxFreeCapacityOversubscriptionRatio が 設定されていない場合、LINSTOR は MaxOversubscriptionRatio の値を使用します。

したがって、ストレージプールにバックアップされた新しいリソースをデプロイする際、LINSTORは 空き容量の計算ではなく合計容量の計算を使用して、ストレージプールの過剰割当を制限し、 新しいリソースを配置できるかどうかを決定します。ただし、ストレージリソースをさらに デプロイし、それらがデータで埋まると、ストレージプール内の利用可能な空きスペースが 減少します。そのため、LINSTORがストレージプールの過剰割当を制限するために合計容量の 計算を常に使用するわけではない可能性があります。その比率が空き容量の比率よりも 小さい場合でもです。

To move a resource between nodes without reducing redundancy at any point, you can use the LINSTOR disk migration feature. First, create a diskless resource on the target node, and then toggle the resource to diskful by using the --migrate-from option. This LINSTOR client operation will wait until the data has been synced to the new disk and then it will remove the source disk.

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

LINSTORは、上記のProxy接続を自動的に有効にするように設定することもできます。この自動化のために、LINSTORはまず、各ノードがどのサイトにあるかを知る必要があります。

Site プロパティは将来の機能で他のサイトベースの決定にも使用される可能性があるため、 DrbdProxy/AutoEnable も true に設定する必要があります。

このプロパティは、ノード、リソース定義、リソース、およびリソース接続のレベルにも 設定できます（優先度が低い方から右に向かって増加し、コントローラーが最も優先度が低い、 つまり最も優先度が低いレベルである左端に位置しています）。

この初期化ステップが完了すると、すべての新しく作成されたリソースは自動的に、 その相互リソースのいずれかにDRBD Proxyを有効にする必要があるかどうかをチェックします。

サンプルのPostgreSQLの linstor.toml は、次のようになります:

MariaDBのサンプル linstor.toml は以下のようになります:

注意: LINSTORのスキーマ/データベースは LINSTOR として作成されますので、MariaDBの接続文字列が 上記の例のように LINSTOR スキーマを参照していることを確認してください。

etcdは、あなたのLINSTORデータベースを分散させるのが簡単になる分散型のキー値ストアです。etcdドライバーは、LINSTORコントローラーパッケージにすでに含まれており、linstor.toml で設定するだけです。

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

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

LINSTORの管理タスクをよりアクセスしやすくし、Webフロントエンドでも利用できるようにするために、REST APIが作成されました。REST API はLINSTORコントローラーに組み込まれており、LINSTOR 0.9.13以降は linstor.toml 構成ファイルを通じて設定されています。

REST APIを使用したい場合、現在のドキュメントは次のリンクで見つけることができます: https://app.swaggerhub.com/apis-docs/Linstor/Linstor/

HTTP REST APIはHTTPSによってもセキュリティが確保されるように実行することができ、認証が必要な機能を使用する場合には強くお勧めします。そのためには、すべてのHTTPSトラフィックを暗号化するために使用される有効な証明書を含むJavaキーストアファイルを作成する必要があります。

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

keytool は生成されたキーストアファイルを保護するためのパスワードを要求し、LINSTOR コントローラーの設定に必要です。 linstor.toml ファイルには、次のセクションを追加する 必要があります。

linstor-controller を再起動し、HTTPS REST APIがポート3371で利用可能になります。

他の証明書をインポートする方法の詳細については、こちらをご覧ください。 https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html

重要: HTTPSアクセスを有効にした後、HTTP v1 REST APIへのすべてのリクエストは HTTPSリダイレクトにリダイレクトされます。 もし LINSTORのコントローラをLINSTOR設定のTOMLファイル (/etc/linstor/linstor.toml)で指定していない場合は、 LINSTORクライアント(linstor)を使用する際に異なる構文を使用する必要があります。 詳細は LINSTORクライアントの使用 に記載されています。

LINSTOR-Controllerは /health というHTTPパスも提供しており、コントローラがデータベースにアクセスでき、すべてのサービスが稼働している場合は単純にHTTPステータス200を返します。それ以外の場合は、HTTPエラーステータスコード500 内部サーバーエラー を返します。

LINSTOR コントローラーを LDAP (または LDAPS) を介してユーザーを認証するように構成した後、LINSTOR REST API に HTTPS を設定すると、次のように LINSTOR コマンドを入力する必要があります。

LDAP認証を設定した場合には、 LINSTOR REST API HTTPS も 構成する必要があります。そうでない場合は、linstor コマンドで --allow-insecure-path フラグを使用してHTTP経由でパスワード認証を明示的に有効にする必要があります。 これは、資格情報を平文で送信するため、安全で隔離された LAN以外では推奨されません。

LINSTORコントローラーは、上記の例のそれぞれでユーザーのパスワードを求めます。 必要に応じて、--password 引数を使用してユーザーのパスワードをコマンドラインで 入力することができます。その際は慎重に警告を受けることになります。

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

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

これは、linstor-controller, resource-group, および resource-definition LINSTORオブジェクトに適用できる DrbdOptions/auto-quorum プロパティを介して制御されます。 DrbdOptions/auto-quorum プロパティの受け入れられる値は disabled, suspend-io, および io-error です。

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

重要：DrbdOptions/auto-quorum ポリシーは、DrbdOptions/auto-quorum が無効にされていない場合、手動で設定されたプロパティを上書きします。

たとえば、リソースグループ名が my_ssd_group であるリソースグループのクォーラムポリシーを手動で設定する場合、以下のコマンドを使用します。

DRBDのクォーラム機能を完全に無効にすることをお勧めします。そのためには、 まず適切なLINSTORオブジェクトで DrbdOptions/auto-quorum を無効にし、 その後DRBDのクォーラム機能を適切に設定する必要があります。たとえば、my_ssd_group リソースグループで 完全にクォーラムを無効にするには、次のコマンドを使用してください。

注意: 上記のコマンドで DrbdOptions/Resource/on-no-quorum を空の値に設定すると、そのプロパティがオブジェクトから完全に削除されます。

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

この機能は、次のプロパティを使用して動作を適応させます。

LINSTORコントローラーがサテライトとの接続を失った場合、再接続を試みるだけでなく、 そのサテライト用のタイマーを開始します。そのタイマーが DrbdOptions/AutoEvictAfterTime を 超え、かつそのサテライト上のDRBDリソースへのすべてのDRBD接続が切断されると、 コントローラーは DrbdOptions/AutoEvictMaxDisconnectedNodes が達成されたかどうかを 確認します。もし、そうでない場合、および DrbdOptions/AutoEvictAllowEviction が 対象のノードでtrueの場合、サテライトはEVICTEDとマークされます。 同時にコントローラは、全てのDRBDリソースについて、リソースの数が まだ DrbdOptions/AutoEvictMinReplicaCount よりも多いかどうかを確認します。 もし多い場合、そのリソースはDELETEDとマークされます。もし成功しない場合、 対応するリソースグループの設定で自動配置が開始されます。自動配置が失敗した場合、 コントローラーは後で再度試行します。新しいノードの追加などの変更が行われることで、 別の結果が可能になるかもしれない場合があります。自動配置が必要なリソースは、 対応する自動配置が成功した場合にのみ削除マークが付けられます。

サテライトは自身を退去した場合、コントローラーとの接続を再確立することは できません。ノードが動作していても、手動で再接続を試みても失敗します。サテライトを 削除することもできません。サテライトは復元することができます。これにより、 サテライトからEVICTEDフラグが削除され、再度使用できるようになります。 以前に設定されたネットワークインターフェース、ストレージプール、プロパティ、 および同様のエンティティ、非DRBD関連のリソース、およびLINSTORが他の場所に自動配置できなかった リソースはまだサテライト上にあります。サテライトを復元するには、次のコマンドを使用してください:

そのノードにあった全てのもの、ノード自体も含めて全てを捨て去りたい場合は、 代わりに node lost コマンドを使用する必要があります。

LINSTORオブジェクトのさまざまなLINSTORオブジェクト（たとえば、リソース定義など）に対して、LINSTORが自動的に「ディスク不足」ノードを「ディスクフル」にするのをサポートし、その後適切なクリーンアップ操作を実行するように、LINSTOR auto-diskful および auto-diskful-allow-cleanup プロパティを設定できます。

この機能は、Diskless ノードがDRBDリソースの Primary 状態に指定された分数よりも長く残っている場合に便利です。これは、LINSTORで管理されたストレージを他のオーケストレーションやスケジューリングプラットフォーム（OpenStack、OpenNebulaなど）と統合するケースで発生する可能性があります。LINSTORと統合する一部のプラットフォームでは、ストレージボリュームがクラスタ内のどこで使用されるかを影響する手段がないかもしれません。

auto-diskfulオプションは、統合プラットフォームの操作に対して、あなたのコントロールを超えたアクションに対応するために、ストレージノードの役割を賢く委任する方法を提供します。

デバイスがI/Oエラーを発生させている場合、例えば物理的な障害が原因の場合、DRBDはこの状態を検出し、自動的にローカルディスクから切り離します。すべての読み込みおよび書き込みリクエストは、依然として健全なpeerに転送され、アプリケーションが中断することなく継続できます。

この自動切り離しは、drbdsetup events2ストリームに新しいイベントエントリを引き起こし、DRBDボリュームの状態を ‘UpToDate’ から Failed 最終的に Diskless に変更します。 LINSTORはこれらの状態変更を検出し、指定されたリソースに DrbdOptions/SkipDisk プロパティを自動的に True に設定します。 このプロパティにより、I/Oエラーを発生させるデバイスを持つノード上で実行されているLINSTORサテライトサービスが、すべての drbdadm adjust コマンドに --skip-disk をアタッチするようになります。

もし、このプロパティが設定されている場合、 linstor resource list コマンドもそれに応じて表示されます。

この場合、(R) はすでにプロパティがリソースに設定されていることを示しています。 プロパティ DrbdOptions/SkipDisk がリソースとノードレベルの両方に設定される場合、 インジケータは (R, N) に変更されます。

このプロパティはLINSTORによって自動的に有効になっていますが、I/Oエラーの原因を解決した後、 健全な UpToDate 状態に戻るためにプロパティを手動で削除する必要があります。

ノードレベルでプロパティを設定するには、例えば、以下のコマンドを入力してください:

指定されたLINSTORオブジェクトにプロパティが設定されているかを確認するには、 list-properties サブコマンドを使用できます。

コマンドの出力には、指定されたLINSTORオブジェクトのセットプロパティとその値のテーブルが 表示されます。

プロパティを解除するには、ストレージプール名を指定せずに、次の例のように同じコマンドを入力してください。

これらの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 プールを作成し、ホストへの追加設定は不要です:

他の種類のストレージプールも設定することができます。詳細は、以下のリンクを参照してください。upstreamの例。

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

LINBIT SDSをKubernetesにデプロイした後、この章の [s-kubernetes-basic-configuration-and-deployment], Operator v2デプロイメントにおけるDRBDモジュールローダーの設定:, Operator v2 デプロイメントにおいて DRBD レプリケーション用ホストネットワークを使用する セクションに進むか、または上流のPiraeusプロジェクトの tutorials を参照してください。 === LINSTOR Operator v1のデプロイメント

Operator v1 は、次のようにして Helm v3 チャートを使用してインストールされます:

INSTORコントローラーは、クラスターの状態を永続化するために直接Kubernetes APIを使用することができます。このバックエンドを有効にするには、次のオーバーライドファイルをチャートのインストール中に使用してください。:

ヒント：既存のetcdバックエンドを使用するクラスタを、Kubernetes APIバックエンドに移行することが可能です。移行手順については、charts.linstor.ioの移行手順を参照してください。 ==== 永続ストレージボリュームの作成

pv-hostpath Helmテンプレートを使用して、hostPath 永続ボリュームを作成できます。必要なだけ多くのPVを作成して、設定されたetcd replicas（デフォルトは1）を満たしてください。

nodes= オプションの中で、クラスターノード名に応じて hostPath 永続ボリュームを作成してください。

デフォルトでは、control-plane ノードごとに PV が作成されます。インストールコマンドに --set "nodes={<NODE0>,<NODE1>,<NODE2>}" を渡すことで、ストレージノードを手動で選択することができます。注意: ノードを参照する正しい値は、kubernetes.io/hostname ラベルの値です。すべてのノードの値をリストアップするには、kubectl get nodes -o custom-columns="Name:{.metadata.name},NodeName:{.metadata.labels['kubernetes\.io/hostname']}" を実行してください。 ==== 既存のデータベースの使用

LINSTORは既存のPostgreSQL、MariaDB、またはetcdデータベースに接続することができます。たとえば、次の構成でPostgreSQLインスタンスに接続する場合:

ヘルム・チャートは、次の内容をHelmインストールコマンドに追加することで、このデータベースをデプロイメントするためにetcdクラスターの代わりに構成することができます。

LINSTOR Operator v1は、LINSTORの基本的なストレージ設定を自動化できます。

LINSTORのコンポーネント間のデフォルト通信はTLSでセキュリティ保護されていません。これがセットアップに必要な場合は、次の3つの方法のいずれかを選択してください: // “cert-manager”は製品名なので元のケースを保持します

以下の例はすべて、次の sp-values.yaml ファイルを使用しています。お使いの環境や使用目的に合わせて自由に調整してください。詳細については、 [ストレージプールの作成の構成] を参照してください。

重要: LINBITのコンテナイメージリポジトリ (http://drbd.io) は、前述のおよび今後の kubectl create コマンドで使用されますが、LINBITのお客様またはLINBITの顧客試用アカウントを持っている方のみ利用可能です。 価格情報の確認やトライアルの開始についてはLINBITにお問い合わせください。 また、LINBITのお客様でなくても、LINSTOR SDSアップストリームプロジェクトであるPiraeusを利用することもできます。

sp-values.yaml を介してインストール時に定義されたLINSTORストレージプール、永続的な hostPath ボリューム、3つのetcdレプリカ、ホストカーネルのためにDRBDカーネルモジュールをコンパイルしてインストールします。

これはほとんどの基本的なデプロイメントに適しているはずです。 このデプロイメントでは、このコマンドをよりポータブルにするために、事前にコンパイルされたDRBDカーネルモジュールを使用していません。 事前にコンパイルされたバイナリを使用すると、より高速なインストールとデプロイメントが可能です。 Compile オプションを使用することは、大規模なKubernetesクラスターでの使用をお勧めしません。

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.

LINSTOR Operator v1 デプロイメント内のすべてのコンポーネントのハイアベイラビリティデプロイメントを作成するには、 アップストリームガイドを参照してください。デフォルト値は、コンポーネントを複数のレプリカにスケーリングすることで、レプリカが異なるノードに配置されるように選択されています。これにより、単一ノードの障害がサービスを中断しないようになっています。注意: LINBIT SDSをLINSTOR Operator v2 を使用してKubernetesに展開した場合、ハイアベイラビリティがデフォルトでデプロイメントに組み込まれています。 ===== 高可用性コントローラーを使用した高速ワークロードフェイルオーバー

ノードの障害が発生すると、Kubernetes はステートフルなワークロードの再スケジューリングに非常に慎重です。これは、ポッドが到達不能なノードから移動するのに15分以上かかる可能性があることを意味します。DRBD と LINSTOR が利用可能な情報を活用することで、このプロセスを大幅に高速化することが可能です。

LINSTOR ハイアベイラビリティ コントローラ（HA コントローラ）は、LINSTOR を使用してストレージを利用する状態を持つワークロードのフェイルオーバー プロセスを高速化します。少なくとも1つの DRBD リソースにアタッチされた任意の Pod を監視および管理します。

HAコントローラーが正しく機能するためには、少なくとも3つのレプリカ（または2つのレプリカ+1つのディスクレス・タイブレーカー）が必要です。レプリカ数を低く設定している場合、関連するポッドは無視され、より迅速なフェイルオーバーの対象とはなりません。

HAコントローラーはHelmチャートとしてパッケージ化されており、以下を使用してデプロイメントできます:

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.

HA コントローラーによるポッドの管理を除外するには、次の注釈をポッドに追加します:

etcdデータベースのバックアップ（LINSTOR Operator v1のDeploymentにおいて）を作成し、それを制御ホストに保存するには、以下のコマンドを入力してください:

これらのコマンドは、kubectl を実行しているマシンに save.db というファイルを作成します。 === LINSTORオペレーターを使用したデプロイ

オペレーターは、既存のLINSTORセットアップを使用するようにサテライトとCSIプラグインを構成できます。これは、ストレージインフラがKubernetesクラスタとは別である場合に役立ちます。ボリュームは、Kubernetesノード上でディスクレスモードでプロビジョニングされ、ストレージノードはバッキングディスクストレージを提供します。 ==== 外部LINSTORコントローラを使用したOperator v2のデプロイメント ===== LinstorCluster リソースの設定

外部で管理されたLINSTORクラスタを使用するには、YAML構成の LinstorCluster リソースにLINSTORコントローラのURLを指定し、デプロイメントに適用してください。次の例では、LINSTORコントローラは http://linstor-controller.example.com:3370 でアクセス可能です。

通常、ポッドネットワークはKubernetesクラスターの外部から到達できません。この場合、外部のLINSTORコントローラーはKubernetesクラスター内のサテライトと通信できません。そのため、サテライトがホストネットワーキングを使用するように設定する必要があります。

ホストネットワーキングを使用するには、次のYAML構成をデプロイメントに適用して、LinstorSatelliteConfiguration リソースをデプロイしてください:

helm install を実行する際に、LINSTORコントローラーデプロイメントの作成をスキップし、他のコンポーネントを既存のLINSTORコントローラーを使用するように設定するには、次のオプションを使用してください。

すべてのポッドが準備完了になると、LINSTORセットアップでKubernetesクラスターノードがサテライトとして表示されるはずです。

重要: コントローラーとストレージノードは、KubernetesノードがそれらのIPを使用して到達可能である必要があります。

ストレージノード上で既存のストレージプールを参照するストレージクラスを作成してください。

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

コントローラーポッドにはLINSTORクライアントが含まれており、LINSTORと直接やり取りすることが簡単になります。 実行例:

Kubernetesデプロイメント内でLINSTORクライアントコマンドを簡略化するために、kubectl-linstor ユーティリティを使用できます。このユーティリティは、上流のPiraeusデータストアプロジェクトから利用できます。それをダウンロードするには、次のコマンドをあなたのKubernetesコントロールプレーンノードで入力してください:

INPORTANT: もし貴方のデプロイメントがLINSTOR Operator v2を使用している場合、kubectl-linstor ユーティリティのバージョンを0.2.0以上にする必要があります。

ユーティリティをインストールするには、まずユーティリティを解凍し、解凍した実行ファイルを $PATH 内のディレクトリ (例: /usr/bin) に移動します。その後、kubectl-linstor を使用して完全な LINSTOR CLI にアクセスできます。

それはPVCへの参照も対応するLINSTORリソースに拡張します。

pod:[<namespace>/]<podname> 形式の参照を、そのポッドで使用されているリソースのリストに展開することも可能です。この機能は、問題の調査や高度な機能へのアクセスが必要な場合にのみ使用するべきです。ボリュームの作成などの通常の操作は、 Kubernetesの統合 を介して行うべきです。 === KubernetesでのLINBIT SDSストレージの始め方

全ての linstor-csi Pod が稼働していると、通常の Kubernetes ワークフローを使用してボリュームをプロビジョニングすることができます。.

Kubernetesを通じてデプロイされたLINSTORボリュームの挙動やプロパティを設定するには、Kubernetes StorageClassオブジェクトを使用します。

重要: resourceGroup パラメータは必須です。なぜなら、KubernetesのStorageClassオブジェクトはLINSTORリソースグループと一対一の対応関係があるため、通常は resourceGroup パラメータを一意であり、ストレージクラスの名前と同じにしたいと思うでしょう。

ここ以下に、ボリュームをデプロイするのに使用できる最もシンプルな実用的な StorageClass が示されています。

重要: 上記のYAML設定ファイルの例で storagePool の値が lvm-thin である必要があります。利用可能なLINSTORの StoragePool に一致するようにしてください。実行中の linstor-op-cs-controller ポッド内で linstor storage-pool list コマンドを使用するか、 kubectl-linstor ユーティリティ をインストールしている場合は kubectl linstor storage-pool list コマンドを使用して、ストレージプールの情報を一覧表示することができます。

次のコマンドを使用して、ストレージクラスを作成できます:

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:

次のコマンドで PersistentVolumeClaim を作成できます。

これにより、PersistentVolumeClaim が作成されますが、その時点ではボリュームは作成されません。 使用したストレージクラスは volumeBindingMode: WaitForFirstConsumer を指定していました。これは、ボリュームが作業負荷を開始するときにのみ作成されることを意味します。これにより、ボリュームが作業負荷と同じノードに配置されることが保証されます。

私たちの例では、PersistentVolumeClaim を参照してボリュームをマウントする単純な Pod を作成します。 .my-first-linstor-volume-pod.yaml

次のコマンドで Pod を作成できます。

kubectl describe pod fedora を実行することで、 ポッドのスケジューリング と ボリュームのアタッチメント が成功したことを確認できます。PersistentVolumeClaim を調査すると、今やボリュームにバインドされていることがわかります。

ボリュームを削除するには、いかなるポッドもそれを使用していないことを確認し、kubectl コマンドを使用して PersistentVolumeClaim を削除します。たとえば、作成したばかりのボリュームを削除するには、以下の2つのコマンドを実行します。なお、PersistentVolumeClaim を削除する前に、Pod がスケジュールされていない必要があります。

次のストレージクラスには、現在利用可能なすべてのパラメータが含まれています。.

いくつかの違いがあります。ストレージクラスの構成内でDRBDオプションを設定すると、これらのオプションはストレージクラスから作成される新しいボリュームにのみ影響します。これらのオプションは既存のボリュームには影響しません。さらに、ストレージクラスを単純に更新することはできないため、ストレージクラスの構成にDRBDオプションを追加する場合は、そのストレージクラスを削除して再作成する必要があります。また、LINSTORリソースグループオブジェクトでDRBDオプションを設定すると（linstor resource-group set-property <rg-name> DrbdOptions/<option-name>）、変更は将来のボリュームおよびリソースグループに属する既存のボリュームに影響します。

警告: LINSTORリソースグループにDRBDオプションを設定し、それがKubernetesストレージクラスにも対応している場合、次にボリュームが作成されるとき、CSIドライバーは、リソースグループ内にのみあるDRBDオプションの変更を元に戻します。この問題を解決するには、ストレージクラスでもDRBDオプションを設定する必要があります。

潜在的な落とし穴があるため、LINSTORコントローラーオブジェクトにDRBDオプションを設定する方が簡単です。コントローラーに設定されたDRBDオプションは、すべてのリソースグループ、リソース、およびボリュームに適用されます。これらのLINSTORオブジェクトのいずれかに同じオプションが設定されていない限りです。LINSTORオブジェクト階層に関する詳細については、 LINSTORのオブジェクト階層 セクションを参照してください。

以下のコマンドを入力することで、LINSTORコントローラオブジェクトに設定できるプロパティ（DRBDオプションを含む）をリストアップできます:

csi.storage.k8s.io/fstype パラメータは、 volumeMode: FileSystem PVCsの作成に使用するファイルシステムタイプを設定します。現在サポートされているのは以下の通りです：* ext4（デフォルト）* xfs ==== autoPlace

autoPlace は、この StorageClass のボリュームにレプリカがいくつ作成されるかを決定する整数です。たとえば autoPlace: "3" は、3つの複製を持つボリュームを生成します。autoPlace も nodeList も設定されていない場合、ボリュームは1つのノードに 自動的に配置 されます。重要: このオプションを使用する場合、 nodeList を使用しないでください。重要: ダブルクオーテーションを使用する必要があります。そうしないと Kubernetes は不正な StorageClass としてエラーを出力します。ヒント: このオプション（および自動配置動作に影響を与えるすべてのオプション）は、ボリュームの基礎ストレージがプロビジョニングされる LINSTOR ノードの数を変更し、どの kubelets からそのボリュームにアクセスできるかには直交しています。

placementCount は autoPlace のエイリアス

このStorageClassに関連付ける LINSTORリソースグループ（RG） 。設定されていない場合、新しいPVCごとに新しいRGが作成されます。 ==== storagePool

storagePool は、新しく作成されるボリュームにストレージを提供するために使用されるLINSTORの ストレージプール の名前です。 注意: この同じ storage pool で構成されたノードのみが 自動配置 の対象となります。同様に、nodeList を使用する StorageClasses の場合、そのリストに指定されたすべてのノードにこの storage pool が構成されている必要があります。 ==== disklessStoragePool

disklessStoragePool は、”ディスクレス”として linetets に割り当てられたLINSTORボリュームにのみ影響するオプションパラメータです。LINSTORでカスタムディスクレスストレージプールが定義されている場合、ここで指定します。

作成されたボリュームに使用するレイヤーのカンマ区切りのリスト。使用可能なレイヤーとその順序は、 このセクション の最後に記載されています。デフォルトは drbd,storage 。 ==== placementPolicy

利用可能なボリュームスケジューラのいずれかを選択します: * AutoPlaceTopology、デフォルト: Kubernetesからのトポロジ情報とユーザー定義の制約条件を使用します（[s-kubernetes-replicasonsame] および [s-kubernetes-replicasondifferent] を参照）。 * AutoPlace LINSTORの自動配置機能を使用し、 [s-kubernetes-replicasonsame] および [s-kubernetes-replicasondifferent] の影響を受けます。 * FollowTopology: CSIトポロジ情報を使用して、各 “preferred” ゾーンに少なくとも1つのボリュームを配置します。CSIトポロジが有効な場合のみ使用可能です。 * Manual: nodeList と clientList にリストされているノードのみを使用します。 * Balanced: 実験的 障害ドメイン全体にわたってボリュームを配置し、各選択されたノード上で最も使用されていないストレージプールを使用します。 ==== allowRemoteVolumeAccess

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

encryption は、ボリュームを暗号化するかどうかを決定するオプションパラメータです。 これが正常に機能するには、LINSTORはデプロイメントが 暗号化に設定 されている必要があります。 ==== nodeList

nodeList は、割り当てるボリュームのノードのリストです。これにより、ボリュームが各ノードに割り当てられ、それらの間でレプリケーションされます。ホスト名で単一ノードを選択するためにも使用できますが、単一ノードを選択するには replicasOnSame を使用する方が柔軟です。重要：このオプションを使用する場合は、 autoPlace を使用しないでください。ヒント：このオプションは、ボリュームの基礎ストレージがどのLINSTORノードにプロビジョニングされるかを決定し、これらのボリュームがアクセス可能になる kubelets は異なります。

clientList はディスクレスボリュームに割り当てるためのノードのリストです。 [s-kubernetes-nodelist] と併用して使用します。 ==== replicasOnSame

replicasOnDifferent は考慮するプロパティのリストを受け取り、replicasOnSame と同じです。replicasOnDifferent を使用する方法には2つのモードがあります。* 特定のノードにボリューム配置を防止する：+ プロパティに値が与えられた場合、そのプロパティ-値ペアが割り当てられているノードは最後に考慮されます。+ 例： replicasOnDifferent: "no-csi-volumes=true" は、 no-csi-volumes=true プロパティを持つノードにはボリュームを配置しない（autoPlace 設定を満たす他のノードが不足していない限り）。 * 同じキーの異なる値を持つノードにボリュームを分散配置する:
プロパティの値が指定されていない場合、LINSTORは可能であればそのプロパティの値が異なるノードにボリュームを配置します。 + 例: 4つのノードがあると仮定し、 node-a1 と node-a2 が zone=a で構成され、 node-b1 と node-b2 が zone=b で構成されているとします。 autoPlace: "2" および replicasOnDifferent: "zone" を持つ StorageClass を使用すると、LINSTORは node-a1 または node-a2 のいずれかに1つのレプリカを作成し、そして node-b1 または node-b2 のいずれかに1つのレプリカを作成します。

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

正規表現に一致する名前を持つリソースがあるノードにリソースを配置しないでください。 ==== fsOpts fsOpts は、作成時にボリュームのファイルシステムにオプションを渡すオプションパラメータです。 IMPORTANT: これらの値は選択したファイルシステムに固有です。 ==== mountOpts mountOpts は、マウント時にボリュームのファイルシステムにオプションを渡すオプションパラメータです。

xfs_io に渡す追加の引数は、ボリュームの最初の使用の直前に呼び出されます。 ==== property.linstor.csi.linbit.com/*

property.linstor.csi.linbit.com/ から始まるパラメータは、StorageClassに関連する リソースグループ に設定されたLINSTORプロパティに変換されます。

たとえば、 DrbdOptions/auto-quorum を disabled に設定する場合は、次のようにします:

フルなオプションの一覧は[こちら](https://app.swaggerhub.com/apis-docs/Linstor/Linstor/1.7.0#/developers/resourceDefinitionModify)で利用可能です。

注意: このオプションは非推奨となりました。より一般的な property.linstor.csi.linbit.com/* 形式を使用してください。LINSTORに渡すための高度なDRBDオプション。たとえば、レプリケーションプロトコルを変更するには、DrbdOptions/Net/protocol: "A" を使用します。 === スナップショット

スナップショットは特定の時点でボリュームの内容のコピーを作成します。このコピーはボリュームの内容を修正しても触れられずに残ります。例えば、データを変更や削除する前にバックアップを作成することができます。バックアップは復元方法がなければ役に立ちませんので、このセクションではスナップショットの作成方法と復元方法について説明します。例えば、データを誤って削除した場合などに備えてです。次のサブセクションでは、Operator v2デプロイメント内のスナップショットに関する手順が記載されています。Operator v1を使用してKubernetesでLINBIT SDSをデプロイした場合は、 [s-kubernetes-add-snaphot-support-v1] のサブセクションに進んでください。 ==== スナップショットとの使用

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コマンドを使用してアドレスを手動でリセットすることによって行うことができます。それぞれの方法について以下に説明します。

このセクションでは、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 オペレーターは、アップグレードする前にデータベースのバックアップを作成します。これにより、アップグレード中に問題が発生した場合に、以前の状態にロールバックできます。

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

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