LINSTOR was originally developed to manage DRBD resources. While you can still use LINSTOR to make managing DRBD more convenient, LINSTOR has evolved and it is often integrated with software stacks higher up to provide persistent storage more easily and more flexibly than would otherwise be possible within those stacks.

LINSTOR can be used on its own or you can integrate it with other platforms, such as Kubernetes, OpenShift, OpenNebula, OpenStack, Proxmox VE, and others. LINSTOR runs on bare-metal on-premise hardware, or you can use it within virtual machines (VMs), containers, clouds, or hybrid environments.

LINSTOR can work with the following storage provider and related technologies:

By using LINSTOR, you can work with these technologies on their own or else in various meaningful combinations.

The linstor-controller service relies on a database that holds all the configuration information for the whole cluster. A node or container running the LINSTOR controller software is responsible for resource placement, resource configuration, and orchestration of any operational processes that require a view of the whole cluster.

Multiple controllers can be used for LINSTOR, for example, when setting up a highly available LINSTOR cluster, but only one controller can be active.

As mentioned earlier, the LINSTOR controller operates on a separate plane from the data plane that it manages. You can stop the controller service, update or reboot the controller node, and still have access to your data hosted on the LINSTOR satellite nodes. While you can still access and serve the data on your LINSTOR satellite nodes, without a running controller node, you will not be able to perform any LINSTOR status or management tasks on the satellite nodes.

The linstor-satellite service runs on each node where LINSTOR consumes local storage or provides storage to services. It is stateless and receives all the information it needs from the node or container running the LINSTOR controller service. The LINSTOR satellite service runs programs like lvcreate and drbdadm. It acts like an agent on a node or in a container that carries out instructions that it receives from the LINSTOR controller node or container.

When you need to interface with LINSTOR, you can send instructions to the active LINSTOR controller by using one of its user interfaces (UIs): the LINSTOR client, or the LINBIT SDS GUI.

Both of these UIs rely on the LINSTOR REST API.

LINSTOR takes an object-oriented approach to software-defined storage (SDS). LINSTOR objects are the end result that LINSTOR presents to the user or application to consume or build upon.

The most commonly used LINSTOR objects are explained below and a full list of objects follows.

While definitions and groups are also LINSTOR objects, they are a special kind. Definition and group objects can be thought of as profiles or templates. These template objects are used to create child objects that will inherit their parent object’s attributes. They might also have attributes that can affect child objects but are not attributes of the child objects themselves. These attributes could be things such as the TCP port to use for DRBD replication or the volume number that a DRBD resource should use.

The following are some general rules for object hierarchy in LINSTOR:

This section uses diagrams to represent the hierarchical relationships between some of the most frequently used LINSTOR objects. Because of the number of LINSTOR objects and their interconnectedness, multiple diagrams are shown first rather than a single diagram, to simplify the conceptualization.

The next diagram shows the relationships between LINSTOR group objects on a single satellite node.

While the two preceding diagrams show higher-lower relationships between common LINSTOR objects, you can also think of some LINSTOR objects as having parent-child relationships. The next diagram introduces this kind of relationship between LINSTOR objects by using a storage pool definition (parent object) and a storage pool (child object) as an example. A parent object can have multiple child objects, as shown in the following diagram.

Having introduced the concept of parent-child relationships in a conceptual diagram, the next diagram is a modified version of the second diagram with some of those relationships added for groups and definitions. This modified diagram also incorporates some of the higher-lower relationships that were shown in the first diagram.

The next diagram synthesizes the relationship concepts of the preceding diagrams while also introducing new LINSTOR objects related to snapshots and connections. With the many objects and criss-crossing lines, the reason for building up to this diagram should be apparent.

Even with its seeming complexity, the preceding diagram is still a simplification and not an all-encompassing representation of the possible relationships between LINSTOR objects. As listed earlier, there are more LINSTOR objects than are shown in the diagram^[3].

The good news is that you do not need to memorize the preceding diagram to work with LINSTOR. It could be useful to refer to though if you are trying to troubleshoot attributes that you have set on LINSTOR objects and their inheritance and effects on other LINSTOR objects in your cluster.

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

For further details about these packages see the Installable Components section above.

You can configure LINSTOR to encrypt storage volumes, by using LUKS (dm-crypt), as detailed in the Encrypted Volumes section of this user’s 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’s guide.

LINSTOR can also interface with Self-Encrypting Drives (SEDs) and you can use LINSTOR to initialize an SED drive. LINSTOR stores the drive’s password as a property that applies to the storage pool associated with the drive. LINSTOR encrypts the SED drive password by using the LINSTOR master passphrase that you must create first.

By default, LINSTOR uses the following cryptographic algorithms:

A FIPS compliant version of LINSTOR is available for the use cases mentioned in this section. If you or your organization require FIPS compliance at this level, please contact [email protected] for details.

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

On each host contributing storage, you need to create either an LVM volume group (VG) or a ZFS zPool. The VGs and zPools identified with one LINSTOR storage pool name may have different VG or zPool names on the hosts, but do yourself a favor, for coherency, use the same VG or zPool name on all nodes.

After creating a volume group on each of your nodes, you can create a storage pool that is backed by the volume group on each of your nodes, by entering the following commands:

ストレージプールを表示するには、次のようにします。

or using LINSTOR abbreviated notation:

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

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

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

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

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

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

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

If the --storage-pool option was provided, LINSTOR will create a storage pool with the given name.

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

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

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

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

In the following example, the value after the --auto-place option tells LINSTOR how many replicas you want to have. The --storage-pool option should be obvious.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

To backup the LINSTOR database to a new file named db_export in your home directory, enter the following commands:

After backing up the database, you can copy the backup file to a safe place.

The resulting database backup is a plain JSON document, containing not just the actual data, but also some metadata about when the backup was created, from which database, and other information.

Restoring the database from a previously made backup is similar to export-db from the previous section.

For example, to restore the previously made backup from the db_export file, enter the following commands:

You can only import a database from a previous backup if the currently installed version of LINSTOR is the same (or higher) version as the version that you created the backup from. If the currently installed LINSTOR version is higher than the version that the database backup was created from, when you import the backup the data will be restored with the same database scheme of the version used during the export. Then, the next time that the controller starts, the controller will detect that the database has an old scheme and it will automatically migrate the data to the scheme of the current version.

Since the exported database file contains some metadata, an exported database file can be imported into a different database type than it was exported from.

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’s 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.

For configuring the highly available (HA) storage, you can use LINSTOR itself. One of the benefits of having the storage under LINSTOR control is that you can easily extend the HA storage to new cluster nodes.

First, create a new resource that is 200MiB in size and set the necessary DRBD options, as shown in the example commands below. You will need to adapt the storage pool name to match an existing storage pool in your environment.

It is crucial that your cluster qualifies for auto-quorum and uses the io-error policy (see Section [s-linstor-auto-quorum]), and that auto-promote is disabled.

From now on it is assumed that the resource’s name is linstor_db. After creating the linstor_db resource, you can move the LINSTOR database to the new storage and create a systemd mount service. First, stop the current controller service and disable it, as it will be managed by DRBD Reactor later.

Next, create the systemd mount service.

Copy the /etc/systemd/system/var-lib-linstor.mount mount file to all the cluster nodes that you want to have the potential to run the LINSTOR controller service (standby controller nodes). Again, do not systemctl enable any of these services because DRBD Reactor will manage them.

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

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

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

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

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

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

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

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

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

To use NVMe-oF/NVMe-TCP with LINSTOR the package nvme-cli needs to be installed on every node which acts as a satellite and will use NVMe-oF/NVMe-TCP for a resource. For example, on a DEB-based system, to install the package, enter the following command:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

引数は次のとおりです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The first four commands in the example define a network interface (nic1 and nic2) for each node (alpha and bravo) by specifying the network interface’s IP address. The last two commands create network path entries in the DRBD .res file that LINSTOR generates. This is the relevant part of the resulting .res file:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For example:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The command above is equivalent to the following:

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

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

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

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

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

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

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

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. === ディスクの追加と削除

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

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

Remove this disk again:

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

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

LINSTOR 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 left-most, 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. === 外部データベースプロバイダー

It is possible to have LINSTOR working with an external database provider like PostgreSQL, MariaDB and since version 1.1.0 even etcd key value store is supported. To use an external database there are a few additional steps to configure. You have to create a DB/Schema and user to use for linstor, and configure this in the /etc/linstor/linstor.toml. ==== PostgreSQL

A sample PostgreSQL linstor.toml looks like this:

A sample MariaDB linstor.toml looks like this:

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

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

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

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. === サテライトへの安全な接続

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

The node setup looks like this:

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

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

Now just start controller and satellites and add the nodes with --communication-type SSL. === LDAP 認証の設定

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

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

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

The LINSTOR Controller will prompt you for the user’s password, in each of the above examples. You may 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. === Automatisms for DRBD Resources

This section details some of LINSTOR’s automatisms for DRBD resources. ==== 自動クォーラムポリシー

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

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

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

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

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

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

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

This feature uses the following properties to adapt the behaviour.

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

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

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. ==== Auto-Diskful and Related Options

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. ===== Setting the Auto-Diskful Option

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

If you deployed LINSTOR using Operator v2, you can upgrade LINBIT SDS by deploying the newer version of LINSTOR Operator.

To upgrade, change the tag referenced in the kustomization file:

Then, apply the kustomization.yaml file, by using the following kubectl command, and wait for the upgrade to complete:

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

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

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

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

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

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

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

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

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

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

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

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

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

OpenShift includes a fully configured monitoring stack. While most of the monitoring stack is only intended for OpenStack infrastructure, basic monitoring for LINBIT SDS is possible.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Version 5 of the plugin drops compatibility with the legacy configuration options “storagepool” and “redundancy”. Version 5 requires a “resourcegroup” option, and obviously a LINSTOR resource group. The old options should be removed from the configuration.

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

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

Version 6.0.0 of the plugin drops all code related to the redundancy setting. This is handled by LINSTOR resource groups (resourcegroup setting) for a very long time. No change should be required.

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

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

With version 6 PVE added additional parameters to some functions and rightfully reset their “APIAGE”. This means that old plugins, while actually usable as they don’t use any of these changed functions do not work anymore. Please upgrade to plugin version 5.2.1 at least.

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

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

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

You can then install the DRBD kernel module, DRBD utilities, and the LINSTOR Proxmox plugin by entering:

LINBIT provides a dedicated public repository for Proxmox VE users. This repository not only contains the Proxmox plugin, but the whole DRBD SDS stack including a DRBD SDS kernel module and user-space utilities.

You can add LINBIT’s public repository by entering the commands below, setting $PVERS to your Proxmox VE major version (for example, “7”, not “7.1”):

After adding the LINBIT package repository, you can install the Proxmox plugin and other necessary components (DRBD kernel module and utilities), by entering the following command: