LINSTOR ユーザーズガイド

Please Read This First

このガイドは、software-defined storage (SDS) ソリューションである LINSTOR® のリファレンスガイドおよびハンドブックとして使用することを目的としています。


This guide is organized as follows:

Introduction to LINSTOR

1. An Introduction to LINSTOR

To use LINSTOR® effectively, this “Introduction to LINSTOR” chapter provides an overview of the software, explains how it works and deploys storage, and introduces and explains important concepts and terms to help your understanding.

1.1. An Overview of LINSTOR

LINSTOR is an open source configuration management system, developed by LINBIT® for storage on Linux systems. It manages LVM logical volumes, ZFS ZVOLs, or both, on a cluster of nodes. It uses DRBD® for replication between different nodes and to provide block storage devices to users and applications. Some of its features include snapshots, encryption, and caching of HDD backed data in SSDs.

1.1.1. Where LINSTOR is Used

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.

1.1.2. LINSTOR Supported Storage and Related Technologies

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

  • LVM and LVM thin volumes

  • ZFS and ZFS thin volumes

  • File and FileThin (loop devices)

  • Diskless

  • Exos

  • SPDK (remote)

  • Microsoft Windows Storage Spaces and thin Storage Spaces

  • EBS (target and initiator)

  • Device mapper cache (dm-cache) and writecache (dm-writecache)

  • bcache

  • LUKS

  • DRBD

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

1.2. How LINSTOR Works

A working LINSTOR setup requires one active controller node that runs the LINSTOR controller software as a systemd service, linstor-controller.service. This is the LINSTOR control plane, where the LINSTOR controller node communicates with LINSTOR satellite nodes.

The setup also requires one or more satellite nodes that run the LINSTOR satellite software as a systemd service, linstor-satellite.service. The LINSTOR satellite service facilitates storage and related actions on the node, for example creating storage volumes to provide data storage to users and applications. However, satellite nodes do not have to provide physical storage to the cluster. For example, you can have diskless satellite nodes that participate in the LINSTOR cluster for DRBD quorum purposes.

It is also possible for a node to run both the LINSTOR controller and satellite services and act in a Combined role.

You can think of the storage technologies as implemented on LINSTOR satellite nodes, for example, DRBD replication, as the data plane. With LINSTOR, the control and data planes are separate and can function independently. This means, for example, that you can update the LINSTOR controller node or the LINSTOR controller software while your LINSTOR satellite nodes continue to provide (and replicate if using DRBD) storage to users and applications without interruption.

For convenience, a LINSTOR setup is often called a LINSTOR cluster in this guide, even though a valid LINSTOR setup can exist as an integration within another platform, such as Kubernetes.

Users can interact with LINSTOR by using either a CLI-based client or a graphical user interface (GUI). Both of these interfaces make use of the LINSTOR REST API. LINSTOR can integrate with other platforms and applications by using plugins or drivers that also make use of this API.

Communication between the LINSTOR controller and the REST API happens via TCP/IP and can be secured by using SSL/TLS.

The southbound drivers that LINSTOR uses to interface with physical storage are LVM, thinLVM and ZFS.

diagram of how LINSTOR works
Figure 1. How LINSTOR works

1.3. インストール可能コンポーネント

A LINSTOR setup has three installable components:

  • LINSTOR controller

  • LINSTOR satellite

  • LINSTOR user interfaces (LINSTOR client and LINBIT SDS GUI)

These installable components are either source code that you can compile, or else prebuilt packages, that you can use to install and run the software.

1.3.1. LINSTOR コントローラー

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.

1.3.2. LINSTOR サテライト

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.

1.3.3. LINSTOR User Interfaces

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.


The LINSTOR client, linstor, is a command line utility that you can use to issue commands to the active LINSTOR controller node. These commands can be action-oriented, such as commands that create or modify storage resources in your cluster, or they can be status commands to glean information about the current state of your LINSTOR cluster.

You can use the LINSTOR client either by entering linstor followed by valid commands and arguments, or in the client’s interactive mode, by entering linstor on its own.

You can find more information about using the LINSTOR client in the LINSTORクライアントの使用 section in this user’s guide.

Listing 1. The LINSTOR client in interactive mode
# linstor
Use "help <command>" to get help for a specific command.

Available commands:
- advise (adv)
- backup (b)
- controller (c)
- drbd-proxy (proxy)
- encryption (e)
- error-reports (err)
- exos
- file (f)
- help
- interactive
- key-value-store (kv)
- list-commands (commands, list)
- node (n)
- node-connection (nc)
- physical-storage (ps)
- remote
- resource (r)
- resource-connection (rc)
- resource-definition (rd)
- resource-group (rg)
- schedule (sched)
- snapshot (s)
- sos-report (sos)
- space-reporting (spr)
- storage-pool (sp)
- volume (v)
- volume-definition (vd)
- volume-group (vg)
LINBIT SDS Graphical User Interface

The LINBIT SDS graphical user interface (GUI) is a web-based GUI that you can use to work with LINSTOR. It can be a convenient way to navigate and get overview information about a LINSTOR cluster, or add, modify, or delete LINSTOR objects within a cluster. For example, you can add nodes, add or delete resources, or do other tasks.

You can find more information about using the GUI interface in the LINBIT SDS GUI chapter in this user’s guide.

image of the LINBIT SDS GUI dashboard within a web browser
Figure 2. The LINBIT SDS GUI dashboard

1.4. Internal Components

The internal components of LINSTOR are abstractions of the software code that are used to describe how LINSTOR works and how you use it. Examples of internal components would be LINSTOR objects, such as resources or storage pools. Although these are abstractions, you will interact with them in a very real way as you use either the LINSTOR client or GUI to deploy and manage storage.

Along the way, this section also introduces and explains core concepts and terms that you will need to familiarize yourself with to understand how LINSTOR works and how to use it.

1.4.1. LINSTOR Objects

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.


A resource is the LINSTOR object that represents consumable storage that is presented to applications and end users. If LINSTOR is a factory, then a resource is the finished product that it produces. Often, a resource is a DRBD replicated block device but it does not have to be. For example, a resource could be diskless to satisfy DRBD quorum requirements, or it could be an NVMe-oF or EBS initiator.

A resource has the following attributes:

  • The name of the node that the resource exists on

  • The resource definition that the resource belongs to

  • Configuration properties of the resource


A volume is the closest LINSTOR internal component to physical storage and is a subset of a resource. A resource can have multiple volumes. For example, you might want to have a database stored on slower storage than its transaction log in a MySQL cluster. To accomplish this by using LINSTOR, you could have one volume for the faster transaction log storage media and another for the slower database storage media, and have both under a single “MySQL” resource. By keeping multiple volumes under a single resource you are essentially creating a consistency group.

An attribute that you specify for a volume takes precedence over the same attribute if it is also specified “higher up” in the LINSTOR object hierarchy. This is because, again, a volume is the closest internal LINSTOR object to physical storage.


A Node is a server or container that participates in a LINSTOR cluster. The node object has the following attributes:

  • Name

  • IP address

  • TCP port

  • Node type (controller, satellite, combined, auxiliary)

  • Communication type (plain or SSL/TLS)

  • Network interface type

  • Network interface name

Storage Pool

A storage pool identifies storage that is assignable to other LINSTOR objects, such as LINSTOR resources, resource definitions, or resource groups, and can be consumed by LINSTOR volumes.

A storage pool defines:

  • The storage back-end driver to use for the storage pool on the cluster node, for example, LVM, thin-provisioned LVM, ZFS, and others

  • The node that the storage pool exists on

  • The storage pool name

  • Configuration properties of the storage pool

  • Additional parameters to pass to the storage pool’s back-end driver (LVM, ZFS, and others)

A List of LINSTOR Objects

LINSTOR has the following core objects:






















1.4.2. Definition and Group Objects

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.


Definitions define the attributes of an object. Objects created from a definition will inherit the configuration attributes defined in the definition. A definition must be created before you can create an associated child object. For example, you must create a resource definition prior to creating the corresponding resource.

There are two LINSTOR definition objects that you can create directly, by using the LINSTOR client: resource definitions and volume definitions.

Resource definition

Resource definitions can define the following attributes of a resource:

  • The resource group that the resource definition belongs to

  • The name of a resource (implicitly, by virtue of the resource definition’s name)

  • The TCP port to use for the resource’s connection, for example, when DRBD is replicating data

  • Other attributes such as a resource’s storage layers, peer slots, and external name.

Volume definition

Volume definitions can define the following:

  • The size of the storage volume

  • The volume number of the storage volume (because a resource can have multiple volumes)

  • ボリュームのメタデータプロパティ

  • The minor number to use for the DRBD device, if the volume is associated DRBD replicated storage

In addition to these definitions, LINSTOR has some indirect definitions: the storage pool definition, the snapshot definition, and the snapshot volume definition. LINSTOR creates these automatically when you create the respective object.


Groups are similar to definitions in that they are like profiles or templates. Where definitions apply to LINSTOR object instances, groups apply to object definitions. As the name implies, a group can apply to multiple object definitions, just as a definition can apply to multiple object instances. For example, you can have a resource group that defines resource attributes for a frequently needed storage use case. You can then use the resource group to easily spawn (create) multiple resources that need to have those attributes, without having to specify the attributes every time you create a resource.

Resource group

A resource group is a parent object of a resource definition where all property changes made on a resource group will be inherited by its resource definition children[1]. The resource group also stores settings for automatic placement rules and can spawn a resource definition depending on the stored rules.

A resource group defines characteristics of its resource definition child objects. A resource spawned from the resource group, or created from a resource definition that belongs to the resource group, will be a “grandchild” object of a resource group and the “child” of a resource definition. Every resource definition that you create will be a member of the default LINSTOR resource group, DfltRscGrp, unless you specify another resource group when creating the resource definition.

Changes to a resource group will be applied to all resources or resource definitions that were created from the resource group, retroactively, unless the same characteristic has been set on a child object, for example, a resource definition or resource that was created from the resource group.

All of this makes using resource groups a powerful tool to efficiently manage a large number of storage resources. Rather than creating or modifying individual resources, you can simply configure a resource group parent, and all the child resource objects will receive the configuration.

Volume group

Similarly, volume groups are like profiles or templates for volume definitions. A volume group must always reference a specific resource group. In addition, a volume group can define a volume number, and a “gross” volume size.

1.5. LINSTOR Object Hierarchy

As alluded to in previous subsections of this chapter, there is a concept of hierarchy among LINSTOR objects. Depending on the context, this can be described either as a parent-child relationship, or else as a higher-lower relationship where lower means closer to the physical storage layer[2].

A child object will inherit attributes that are defined on its parent objects, so long as the same attributes are not already defined on the child object. Similarly, a lower object will receive attributes that are set on higher objects, so long as the same attributes are not already defined on the lower object.

1.5.1. General Rules for Object Hierarchy in LINSTOR

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

  • A LINSTOR object can only receive or inherit attributes that can be set on that object.

  • Lower objects receive attributes set on higher objects.

  • An attribute set on a lower object takes precedence over the same attribute set on higher objects.

  • Child objects inherit attributes set on parent objects.

  • An attribute set on a child object takes precedence over the same attribute set on parent objects.

1.5.2. Using Diagrams to Show Relationships Between LINSTOR Objects

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.

Object hierarchy between controller
Figure 3. The hierarchical relationships between common LINSTOR objects

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

Object hierarchy between controller
Figure 4. The hierarchical relationships between common LINSTOR group objects on a controller 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.

Diagram 3
Figure 5. Higher-lower and parent-child relationships between LINSTOR objects

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.

Diagram 4
Figure 6. The hierarchical relationships between LINSTOR group and definition objects

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.

diagram of LINSTOR hierarchy and inheritance relationships
Figure 7. The hierarchy and inheritance relationships of common LINSTOR objects

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.

1.6. Using LINSTOR

After introducing LINSTOR and explaining its basic concepts and functions, the next chapters in this guide are how-to oriented and task-based. They provide instructions for using LINSTOR and its various components to solve meaningful real-world data storage problems.

Administering LINSTOR

2. 基本管理タスクとシステム設定

This is a how-to style chapter that covers basic LINSTOR administrative tasks, including installing LINSTOR and how to get started using LINSTOR.

2.1. Before Installing LINSTOR

Before you install LINSTOR, there are a few things that you should be aware of that might affect how you install LINSTOR.

2.1.1. パッケージ

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

  1. linstor-client にはコマンドラインのクライアントプログラムが含まれていて、通常すでにインストールされているpythonのみに依存しています。RHEL8 システムでは python をシンボリックリンクする必要があります。

  2. linstor-controllerlinstor-satellite の両方に、サービス用のsystemdユニットファイルが含まれています。それらは Java Runtime Environment (JRE) version 1.8 (headless) 以上に依存します。

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

If you have a LINBIT® support subscription, you will have access to certified binaries through LINBIT customer-only repositories.

2.1.2. FIPS Compliance

This standard shall be used in designing and implementing cryptographic modules…​

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:

  • HMAC-SHA2-512

  • PBKDF2

  • AES-128

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.

2.2. インストール

コンテナで LINSTOR を使用する場合は、このセクションをスキップして、以下の Containers セクションを使用してインストールしてください。

2.2.1. ボリュームマネージャーのインストール

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

2.2.2. LINBIT クラスターノードを管理するスクリプトの使用

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

  • クラスターノードをLINBITに登録する。

  • ノードを既存の LINBIT クラスターに参加させる。

  • ノードで LINBIT パッケージ リポジトリを有効にする。

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

Downloading the LINBIT Manage Node Script

To register your cluster nodes with LINBIT, and configure LINBIT’s repositories, first download and then run the manage node helper script by entering the following commands on all cluster nodes:

# curl -O
# chmod +x ./
# ./
root ユーザーとしてスクリプトを実行する必要があります。

このスクリプトは、[LINBIT カスタマーポータル] のユーザー名とパスワードの入力を求めます。資格情報を入力すると、スクリプトはアカウントに関連付けられたクラスターノードを一覧表示します (最初は何もありません)。

LINBIT パッケージ リポジトリの有効化

ノードを登録するクラスターを指定した後、プロンプトが表示されたら、スクリプトで登録データを JSON ファイルに書き込みます。次に、スクリプトは、有効または無効にできる LINBIT リポジトリのリストを表示します。 LINSTOR およびその他の関連パッケージは、drbd-9 リポジトリにあります。別の DRBD バージョンブランチを使用する必要がない限り、少なくともこのリポジトリを有効にする必要があります。


リポジトリの選択が完了したら、スクリプトのプロンプトに従って構成をファイルに書き込むことができます。次に、LINBIT の公開署名鍵をノードのキーリングにインストールすることに関する質問には必ず yes と答えてください。


On DEB based systems you can install a precompiled DRBD kernel module package, drbd-module-$(uname -r), or a source version of the kernel module, drbd-dkms. Install one or the other package but not both.

2.2.3. パッケージマネージャーを使用して LINSTOR をインストール

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

DEB ベースのパッケージマネージャーを使用している場合は、続行する前に apt update と入力してパッケージリポジトリリストを更新します。
LINSTOR ストレージ用の DRBD パッケージのインストール
DRBD なし で LINSTOR を使用する場合は、これらのパッケージのインストールをスキップできます。

LINSTOR を使用して DRBD 複製ストレージを作成できるようにする場合は、必要な DRBD パッケージをインストールする必要があります。ノードで実行している Linux ディストリビューションに応じて、ヘルパースクリプトが提案する DRBD 関連のパッケージをインストールします。スクリプトの推奨パッケージとインストールコマンドを確認する必要がある場合は、次のように入力できます。

# ./ --hints
LINSTOR パッケージのインストール

LINSTOR をコントローラーノードにインストールするには、パッケージマネージャーを使用して linbit-sds-controller パッケージをインストールします。

LINSTOR をサテライトノードにインストールするには、パッケージマネージャーを使用して linbit-sds-satellite パッケージをインストールします。

ノードがサテライトとコントローラー (Combined ロール) の両方になる場合は、両方のパッケージをインストールします。

2.2.4. ソースコードから LINSTOR をインストール

LINSTOR プロジェクトの GitHub ページは です。

LINBIT には、LINSTOR、DRBD などのソースコードのダウンロード可能なアーカイブファイルもあります。 から利用可能です。

2.3. LINSTOR のアップグレード

LINSTORはローリングアップグレードをサポートしておらず、コントローラとサテライトは同じバージョンでなければなりません。そうでない場合、コントローラはサテライトを VERSION_MISMATCH と認識して接続ができません。しかしこの場合はデータの同期には問題はありません。サテライトがコントローラに接続しなければ何もアクションを起こさず、DRBDの動作が中断することもありません。

組み込みのデフォルトH2データベースを使用していて、linstor-controllerパッケージがアップグレードされている場合は、デ ータベースの自動バックアップファイルがデフォルトの /var/lib/linstor ディレクトリに作成されます。このファイルは、何らかの理由でlinstor-controllerデータベースの移行が失敗した場合の適切な復元ポイントです。エラーをLINBITに 報告し、古いデータベースファイルを使って、以前のコントローラバージョンにダウングレードすることをお勧めします。


First, upgrade the linstor-controller and linstor-client packages on your controller host and then restart the linstor-controller. The controller should start and all of its clients should show OFFLINE(VERSION_MISMATCH). After that you can continue upgrading the linstor-satellite package on all satellite nodes and restart them, after a short reconnection time they should all show ONLINE again and your upgrade is finished.

2.4. コンテナ

LINSTORはコンテナとしても利用可能です。ベースイメージはLINBITのコンテナレジストリ にあります。

LINBIT’s container image repository ( is only available to LINBIT customers or through LINBIT customer trial accounts. Contact LINBIT for information on pricing or to begin a trial. Alternatively, you may use LINSTOR SDS’ upstream project named Piraeus, without being a LINBIT customer.


# docker login











An up-to-date list of available images with versions can be retrieved by opening in your browser. Be sure to browse the image repository through HTTP, although the registry’s images themselves are pulled through HTTPS, using the associated docker pull command.

To load the kernel module, needed only for LINSTOR satellites, you’ll need to run a drbd9-$dist container in privileged mode. The kernel module containers either retrieve an official LINBIT package from a customer repository, use shipped packages, or they try to build the kernel modules from source. If you intend to build from source, you need to have the according kernel headers (e.g., kernel-devel) installed on the host. There are four ways to execute such a module load container:

  • 出荷済みソースからビルドする。

  • 出荷済み/ビルド済みのカーネルモジュールの使用する。

  • LINBITノードのハッシュとディストリビューションを指定する。

  • 既存のリポジトリ設定をバインドマウントする。

ソースからビルドする場合(RHEL ベース):

# docker run -it --rm --privileged -v /lib/modules:/lib/modules \
  -v /usr/src:/usr/src:ro \

コンテナに同梱されているモジュールを使用した例、 /usr/srcバインドマウントしません :

# docker run -it --rm --privileged -v /lib/modules:/lib/modules \

ハッシュとディストリビューションを指定する場合: (あまり使わない):

# docker run -it --rm --privileged -v /lib/modules:/lib/modules \
  -e LB_DIST=rhel7.7 -e LB_HASH=ThisIsMyNodeHash \

既存のリポジトリ設定を使う場合 (あまり使わない):

# docker run -it --rm --privileged -v /lib/modules:/lib/modules \
  -v /etc/yum.repos.d/linbit.repo:/etc/yum.repos.d/linbit.repo:ro \
今のところ(DRBD9 バージョン 9.0.17 より前では)、ホストシステムにカーネルモジュールをロードするのではなく、コンテナ化された DRBD カーネルモジュールを使用する必要があります。コンテナを使用する場合は、DRBD カーネルモジュールをホストシステムにインストールしないでください。バージョン 9.0.17 リリース以降はホストシステムにいつも通りカーネルモジュールをインストールできますが、 usermode_helper = disabled パラメータ(例えば modprobe drbd usermode_helper=disabled )を使ってモジュールをロードする必要があります。

次に、デーモンとして特権モードで LINSTOR サテライトコンテナを実行します。

# docker run -d --name=linstor-satellite --net=host -v /dev:/dev \
コンテナ化された drbd-utils がネットワークを通してホストカーネルと通信できるようにするには net=host が必要です。

LINSTOR コントローラコンテナをデーモンとして実行するには、ホスト上のポート 3370, 3376, 3377 をコンテナにマッピングします。

# docker run -d --name=linstor-controller -p 3370:3370

コンテナ化された LINSTOR クラスタと対話するには、パッケージを介してシステムにインストールされた LINSTOR クライアント、またはコンテナ化された LINSTOR クライアントを使用することができます。 LINSTOR クライアントコンテナを使用するには

# docker run -it --rm -e LS_CONTROLLERS=<controller-host-IP-address> \ node list

これ以降は、LINSTOR クライアントを使用してクラスタを初期化し、一般的な LINSTOR パターンを使用してリソースの作成を開始します。


# docker stop linstor-controller
# docker rm linstor-controller

2.5. クラスタの初期化


  1. DRBD9カーネルモジュールがインストールされ、ロードされている。

  2. drbd-utils` がインストールされている。

  3. LVM` ツールがインストールされている。

  4. linstor-controller , linstor-satellite とその依存パッケージがインストールされている。

  5. linstor-clientlinstor-controller ノードにインストールされている。

コントローラがインストールされているホストで linstor-controller サービスを起動して有効にします。

# systemctl enable --now linstor-controller

2.6. LINSTORクライアントの使用

LINSTORコマンドラインクライアントを実行するときは、常にlinstor-controllerがどこで実行されているか知る必要があります。何も指定してないときは、IP port 3376 のローカルのlinstor-controllerを探しにいきます。そのため linstor-controller と同じホスト上で linstor-client を使います。

linstor-satellite はポート3366と3367を必要とします。 linstor-controller はポート3376と3377を必要とします。ファイアウォールでこれらのポートが許可されていることを確認してください。
# linstor node list

Output from this command should show you an empty list and not an error message.

linstor コマンドはどのマシンでも実行できます。ただし、クライアントにどのようにlinstor-controllerを探すか指定する必要があります。これはコマンドラインのオプションか、環境変数、またはグローバルファイルで指定できます。

# linstor --controllers=alice node list
# LS_CONTROLLERS=alice linstor node list

あるいは、 /etc/linstor/linstor-client.conf ファイルを作成して、以下のように追加することもできます。



linstor-clientコマンドは、パラメータの開始文字を書くだけで使える便利な方法があります。例えば: linstor node listlinstor n l

2.7. ノードをクラスタに追加する

次の手順ではノードを LINSTOR クラスタに追加します。

# linstor node create bravo

IP が省略された場合、クライアントは指定されたノード名をホスト名として自分で解決しようとします。

LINSTOR は、後で DRBD リソースに使用されるノードのローカル uname -n を自動的に検出します。

linstor node list を実行したとき、新しいノードはofflineとマークされています。ここで、以下のコマンドでlinstor-satelliteを起動し、有効にするとこで、再起動時も起動するようになります。

# systemctl enable --now  linstor-satellite

サービスがすでにデフォルトで有効になっていて再起動時に起動する場合は、 systemctl start linstor-satellite を使うこともできます。

10秒後に linstor node list がonlineになるのを見るでしょう。もちろんコントローラが認識する前にlinstor-satelliteがすでに起動されているときもあります。


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

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

2.8. ストレージプール

StoragePools はLINSTORでストレージを識別します。複数のノードからのストレージプールをグループ化するために単純に各ノードで同じ名前を使います。例えば1つの有効な方法としてすべてのSSDに1つの名前をつけ、すべてのHDDに別の名前をつけます。

2.8.1. ストレージプールの作成

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.

# vgcreate vg_ssd /dev/nvme0n1 /dev/nvme1n1 [...]

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:

# linstor storage-pool create lvm alpha pool_ssd vg_ssd
# linstor storage-pool create lvm bravo pool_ssd vg_ssd


# linstor storage-pool list

or using LINSTOR abbreviated notation:

# linstor sp l

2.8.2. Using Storage Pools To Confine Failure Domains to a Single Back-end Device


2.8.3. 複数のノードでストレージプールを共有する

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

# linstor storage-pool create lvm --external-locking \
  --shared-space O1btSy-UO1n-lOAo-4umW-ETZM-sxQD-qT4V87 \
  alpha pool_ssd shared_vg_ssd
# linstor storage-pool create lvm --external-locking \
  --shared-space O1btSy-UO1n-lOAo-4umW-ETZM-sxQD-qT4V87 \
  bravo pool_ssd shared_vg_ssd

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

2.8.4. Creating Storage Pools by Using the Physical Storage Command

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

# linstor physical-storage list

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


  • デバイスサイズは 1GiB より大きい

  • デバイスはルートデバイス(子はなし)例: /dev/vda, /dev/sda

  • The device does not have any file system or other blkid marker (wipefs -a might be needed).

  • デバイスは DRBD デバイスでない

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

# linstor physical-storage create-device-pool --pool-name lv_my_pool \
  LVMTHIN node_alpha /dev/vdc --storage-pool newpool

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

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

2.9. リソースグループを使用した LINSTOR プロビジョニングされたボリュームのデプロイ

Using resource groups to define how you would like your resources provisioned should be considered the de facto method for deploying volumes provisioned by LINSTOR. Chapters that follow which describe creating each resource from a resource-definition and volume-definition should only be used in special scenarios.

LINSTOR で resource-groups を使用しないことにした場合でも、 resource-definitionsvolume-definitions から作成されたすべてのリソースは ‘DfltRscGrp’ resource-group に作成されます。


# linstor resource-group create my_ssd_group --storage-pool pool_ssd --place-count 2
# linstor volume-group create my_ssd_group
# linstor resource-group spawn-resources my_ssd_group my_ssd_res 20G

上記のコマンドを実行すると ‘pool_ssd’ という名前のストレージプールに参加するノードから、2つに複製された 20GB ボリュームを持つ ‘my_ssd_res’ という名前のリソースが自動的にプロビジョニングされます。

より有効なパターンは、ユースケースが最適であると判断した設定でリソースグループを作成することです。もし一貫性のためボリュームの夜間オンライン検証を実行する必要があるというケースの場合、’verify-alg’ がすでに設定されたリソースグループを作成することで、グループから生成されるリソースは ‘verify-alg’ が事前設定されます。

# linstor resource-group create my_verify_group --storage-pool pool_ssd --place-count 2
# linstor resource-group drbd-options --verify-alg crc32c my_verify_group
# linstor volume-group create my_verify_group
# for i in {00..19}; do
    linstor resource-group spawn-resources my_verify_group res$i 10G

上記のコマンドを実行すると、20 個の 10GiB リソースが作成され、それぞれに ‘crc32c’, ‘verify-alg’ が事前設定されます。

resource-definition または volume-definition のオプションを設定することにより、リソースグループから生成される個々のリソースまたはボリュームの設定を調整できます。たとえば、上記の例の ‘res11’ が多数の小さなランダム書き込みを受信する非常にアクティブなデータベースで使用されている場合、その特定のリソースの ‘al-extents’ を増やすことができます。

# linstor resource-definition drbd-options --al-extents 6007 res11

生成された resource-group で既に構成されている resource-definition の設定を構成すると、resource-definition で設定された値は親 resource-group で設定された値を上書きします。たとえば、遅くなるがより安全な ‘sha256’ ハッシュアルゴリズム検証を使用することが ‘res11′ で必要な場合、’res11’ の resource-definition で ‘verify-alg’ を設定すると、resource-group の値が上書きされます。

# linstor resource-definition drbd-options --verify-alg sha256 res11
どの設定が階層で継承されるかのおおざっぱな目安は、リソースまたはボリュームにより近い設定が使われるというです。volume-definition_ 設定は volume-group 設定より優先され、 resource-definition 設定は resource-group より優先されます。

2.10. クラスターの構成

2.10.1. Available Storage Plug-ins


  • Thick LVM

  • 単一の thin プールの Thin LVM

  • Thick ZFS

  • Thin ZFS

2.11. リソース、ボリュームの作成と配備

You can use the LINSTOR create command to create various LINSTOR objects, such as resource definitions, volume definitions, and resources. Some of these commands are shown below.

In the following example scenario, assume that you have a goal of creating a resource named ‘backups’ with a size of ‘500GiB’ that is replicated among three cluster nodes.

First, create a new resource definition:

# linstor resource-definition create backups

Second, create a new volume definition within that resource definition:

# linstor volume-definition create backups 500G

If you want to resize (grow or shrink) the volume definition you can do that by specifying a new size with the set-size command:

# linstor volume-definition set-size backups 0 100G
The size of a volume definition can only be decreased if it has no associated resource. However, you can freely increase the size of a volume definition, even one having a deployed resource.

The parameter 0 is the number of the volume in the resource backups. You have to provide this parameter because resources can have multiple volumes that are identified by a so-called volume number. You can find this number by listing the volume definitions (linstor vd l). The list table will show volume numbers for the listed resources.

So far you have only created definition objects in LINSTOR’s database. However, not a single logical volume (LV) has been created on the satellite nodes. Now you have the choice of delegating the task of deploying resources to LINSTOR or else doing it yourself.

2.11.1. リソースを手動で配置する

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

# linstor resource create alpha backups --storage-pool pool_hdd
# linstor resource create bravo backups --storage-pool pool_hdd
# linstor resource create charlie backups --storage-pool pool_hdd

2.11.2. DRBD リソースの自動化

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

LINSTOR の resource-group create コマンドには --auto-place オプションがありません。なぜなら、このコマンドはリソースを配置するのではなく、後でリソースを配置(spawn)するためのテンプレートを作成するだけだからです。しかし、このセクションで説明する --auto-place オプションに付随する引数を resource-group create コマンドで使用することができます。このように使用すると、リソースグループからリソースを生成するときに、LINSTORは resource create --auto-place コマンドを使用した場合と同じようにリソースを配置します。
もし、クラスタ内のノード(またはストレージプール)が --auto-place コマンドの引数の制約を満たすことができない場合、LINSTORはエラーメッセージとともにコマンドを拒否します。

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.

# linstor resource create backups --auto-place 3 --storage-pool pool_hdd

ストレージプール名がはっきりしない場合、--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 の値が差し引かれます。結果のスコアはマイナスになる可能性があります。



linstor controller set-property Autoplacer/Weights/$name_of_the_strategy $weight


Autoplacerの動作を以前のLINSTORバージョンと互換性を保つために、重みが 1 の MaxFreeSpace を除いて、すべてのストラテジーのデフォルトの重みは0です。

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


do—​not-place-with <resource_name_to_avoid>` 引数は、指定した resource_name_to_avoid リソースがすでに配置されているノードに、LINSTOR がリソースを配置するのを避けるよう試みることを指定するものである。

引数 --do-not-place-with-regex <regular_expression> を使用すると、引数で指定した正規表現にマッチする名前のリソースが既に配置されているノードには、LINSTORはリソースを配置しないようにすることを指定することができます。この方法で、リソースの配置を避けようとする複数のリソースを指定することができます。



この機能は、LINSTORマネージドストレージを使用するKubernetes環境内でリソースの配置を制限しようとしている場合に、特に有用となります。例えば、Kubernetesのラベルに対応する補助ノードのプロパティを設定することができます。このユースケースの詳細については、「LINSTOR Volumes in Kubernetes」LINSTOR User’s Guide の章にある “replicasOnSame” sectionをご覧ください。

引数の --replicas-on-same--replicas-on-different は、 Aux/ 名前空間内のプロパティの名前を指定します。

次の例では、3つのLINSTORサテライトノードに、補助ノードプロパティ testProperty を設定します。次に、リソースグループ testRscGrp を作成し、プレースカウントを2、スポーンしたリソースを testProperty 値が 1 であるノードに配置するという制約を設定します。ボリュームグループの作成後、リソースグループからリソースを作成することができます。簡単のために、以下のコマンドの出力は表示されません。

# for i in {0,2}; do linstor node set-property --aux node-$i testProperty 1; done
# linstor node set-property --aux node-1 testProperty 0
# linstor resource-group create testRscGrp --place-count 2 --replicas-on-same testProperty=1
# linstor volume-group create testRscGrp
# linstor resource-group spawn-resources testRscGrp testResource 100M


# linstor resource list
| ResourceName      | Node   | Port | Usage  | Conns |    State | CreatedOn           |
| testResource      | node-0 | 7000 | Unused | Ok    | UpToDate | 2022-07-27 16:14:16 |
| testResource      | node-2 | 7000 | Unused | Ok    | UpToDate | 2022-07-27 16:14:16 |

Because of the --replicas-on-same constraint, LINSTOR did not place the spawned resource on satellite node node-1, because the value of its auxiliary node property, testProperty was 0 and not 1.

You can verify the node properties of node-1, by using the list-properties command:

# linstor node list-properties node-1
| Key              | Value   |
| Aux/testProperty | 0       |
| CurStltConnName  | default |
| NodeUname        | node-1  |

auto-place の値には、リソースのレプリカを配置する数を正の整数で指定する他に、既存のリソースのデプロイメントを拡張したい場合には、+1 という値も指定できます。この値を使用すると、リソースが作成されたリソースグループの --place-count がどのように設定されていても、LINSTOR は追加のレプリカを作成します。

例えば、先ほどの例で使用した testResource リソースのレプリカを追加でデプロイするには、 +1 という自動配置の値を使用します。まず、node-1 で補助ノードプロパティ testProperty1 に設定する必要があります。そうしないと、以前に設定した --replicas-on-same という制約により、LINSTOR はレプリカをデプロイすることができません。簡単のために、以下のコマンドのすべての出力は表示されません。

# linstor node set-property --aux node-1 testProperty 1
# linstor resource create --auto-place +1 testResource
# linstor resource list
| ResourceName      | Node   | Port | Usage  | Conns |    State | CreatedOn           |
| testResource      | node-0 | 7000 | Unused | Ok    | UpToDate | 2022-07-27 16:14:16 |
| testResource      | node-1 | 7000 | Unused | Ok    | UpToDate | 2022-07-28 19:27:30 |
| testResource      | node-2 | 7000 | Unused | Ok    | UpToDate | 2022-07-27 16:14:16 |

警告: +1 という値は resource-group create --place-count コマンドでは有効ではありません。 これは、このコマンドはリソースをデプロイせず、後でデプロイするためのテンプレートを作成する だけだからです。


引数 --layer-list または --providers の後に、LINSTOR のレイヤーまたはストレージプールプロバイダのカンマ区切りリスト (CSV) を指定すると、LINSTOR があなたのリソースを配置する場所に影響を与えることができます。CSVリストで指定できるレイヤーやストレージプールプロバイダーは、 --help オプションと --auto-place オプションを使用することで表示することができます。レイヤーの CSV リストは、指定したリソースの自動配置を、リストに適合するストレージを持つノードに制限します。例えば、my_luks_resource という既存のリソース定義がある場合、次のコマンドを考えてみてください。

# linstor resource create my_luks_resource --auto-place 3 --layer-list drbd,luks

このコマンドは、DRBDレイヤーをLUKSレイヤーでバックアップしたストレージプール (および暗黙のうちに「ストレージ」レイヤーでバックアップされた)を持つ、 3つのノードに展開されたリソースを作成します。CSVリストで指定するレイヤーの順序は 「トップダウン」で、リストの左側のレイヤーがその右側のレイヤーの上にあります。

引数 --providers を使用すると、リソースの自動配置を、指定した CSV リストに一致する ストレージプールのみに制限することができます。この引数を使用すると、デプロイされた リソースをバックアップするストレージプールを明示的に制御することができます。 例えば、クラスタ内に ZFSLVMLVM_THIN のストレージプールが混在している場合、 --providers LVM,LVM_THIN 引数を使用すると、 --auto-place オプションの使用時に、リソースを LVM または LVM_THIN ストレージプールにのみバックアップさせるように指定することが可能です。

--providers 引数のCSVリストでは、リストの要素の優先順位を指定することはできません。 要素の優先順位を指定しません。その代わりに、LINSTORは追加の --自動配置 制約のような要素を 使用します。LINSTORはリソースを配置する際に、追加の自動配置制約、利用可能な空き領域、 LINSTORのストレージプール選択ストラテジーなど のストレージプール選択戦略などの要素を使用します。

2.12. リソース、リソース定義、およびリソース グループの削除

削除したい LINSTOR オブジェクトの後に delete コマンドを使用して、LINSTOR リソース、リソース定義、およびリソース グループを削除できます。どのオブジェクトを削除するかによって、LINSTOR クラスターおよびその他の関連する LINSTOR オブジェクトに異なる影響があります。

2.12.1. リソース定義の削除


# linstor resource-definition delete <resource_definition_name>

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

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

2.12.2. リソースの削除


# linstor resource delete <node_name> <resource_name>

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

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

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

    Resource-definition property 'DrbdOptions/Resource/quorum' was removed as there are not enough resources for quorum
    Resource-definition property 'DrbdOptions/Resource/on-no-quorum' was removed as there are not enough resources for quorum


2.12.3. リソースグループの削除


# linstor resource-group delete <resource_group_name>

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

    Cannot delete resource group 'my_rg' because it has existing resource definitions.

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

# linstor resource-definition modify <resource_definition_name> \ --resource-group <another_resource_group_name>

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

# linstor resource-definition list

2.13. Backup and Restore Database

Since version 1.24.0, LINSTOR has a tool that you can use to export and import a LINSTOR database.

This tool has an executable file called /usr/share/linstor-server/bin/linstor-database. This executable has two subcommands, export-db and import-db. Both subcommands accept an optional --config-directory argument that you can use to specify the directory containing the linstor.toml configuration file.

To ensure a consistent database backup, take the controller offline by stopping the controller service as shown in the commands below, before creating a backup of the LINSTOR database.

2.13.1. Backing Up the Database

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

# systemctl stop linstor-controller # /usr/share/linstor-server/bin/linstor-database export-db ~/db_export # systemctl start linstor-controller
You can use the --config-directory argument with the linstor-database utility to specify a LINSTOR configuration directory if needed. If you omit this argument, the utility uses the /etc/linstor directory by default.

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

# cp ~/db_export <somewhere safe>

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.

2.13.2. Restoring the Database From a Backup

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:

# systemctl stop linstor-controller # /usr/share/linstor-server/bin/linstor-database import-db ~/db_export # systemctl start linstor-controller

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.

2.13.3. Converting Databases

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.

3. LINSTOR 応用タスク

3.1. 高可用性 LINSTOR クラスターの作成

By default a LINSTOR cluster consists of exactly one active LINSTOR controller node. Making LINSTOR highly available involves providing replicated storage for the controller database, multiple LINSTOR controller nodes where only one is active at a time, and a service manager (here DRBD Reactor) that takes care of mounting and unmounting the highly available storage as well as starting and stopping the LINSTOR controller service on nodes.

3.1.1. 高可用性ストレージの構成

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.

# linstor resource-definition create linstor_db # linstor rd drbd-options --auto-promote=no linstor_db # linstor rd drbd-options --quorum=majority linstor_db # linstor rd drbd-options --on-suspended-primary-outdated=force-secondary linstor_db # linstor rd drbd-options --on-no-quorum=io-error linstor_db # linstor rd drbd-options --on-no-data-accessible=io-error linstor_db # linstor rd drbd-options --rr-conflict=retry-connect linstor_db # linstor volume-definition create linstor_db 200M # linstor resource create linstor_db --storage-pool pool1 --auto-place 3

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.

# systemctl disable --now linstor-controller

Next, create the systemd mount service.

# cat << EOF > /etc/systemd/system/var-lib-linstor.mount
Description=Filesystem for the LINSTOR controller

# you can use the minor like /dev/drbdX or the udev symlink What=/dev/drbd/by-res/linstor_db/0 Where=/var/lib/linstor EOF

# mv /var/lib/linstor{,.orig} # mkdir /var/lib/linstor # chattr +i /var/lib/linstor # only if on LINSTOR >= 1.14.0 # drbdadm primary linstor_db # mkfs.ext4 /dev/drbd/by-res/linstor_db/0 # systemctl start var-lib-linstor.mount # cp -r /var/lib/linstor.orig/* /var/lib/linstor # systemctl start linstor-controller

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.

3.1.2. 複数のLINSTORコントローラー

次のステップは、”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 を設定してください。

3.1.3. サービスの管理

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

id = "linstor_db"
start = ["var-lib-linstor.mount", "linstor-controller.service"]

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

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

# systemctl restart drbd-reactor # systemctl enable drbd-reactor

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

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

# systemctl edit linstor-satellite

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

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

3.2. DRBDクライアント

--storage-pool の代わりに --drbd-diskless オプションを使うことで、ノード上に永続的なディスクレスのDRBDデバイスを持つことができます。これは、リソースがブロックデバイスとして表示され、既存のストレージデバイスなしでファイルシステムとしてマウントできることを意味します。リソースのデータは、同じリソースを持つ別のノード上にネットワークを介してアクセスされます。

# linstor resource create delta backups --drbd-diskless
オプション --diskless は非推奨です。代わりに --drbd-diskless を使ってください。 または --nvme-initiator を代わりに使ってください。

3.3. LINSTOR – DRBDコンシステンシグループ/マルチボリューム




LINSTORリソースに複数のボリュームを配備するには、同じ名前の volume-definitions を2つ作成する必要があります。

# linstor volume-definition create backups 500G # linstor volume-definition create backups 100G

3.4. 1つのリソースのボリュームを異なるストレージプールに配置

リソースをノードに配備する前のボリューム定義で StorPoolName プロパティを使うことで、1つのリソースから異なるストレージプールへのボリュームを作成できます。

# linstor resource-definition create backups # linstor volume-definition create backups 500G # linstor volume-definition create backups 100G # linstor volume-definition set-property backups 0 StorPoolName pool_hdd # linstor volume-definition set-property backups 1 StorPoolName pool_ssd # linstor resource create alpha backups # linstor resource create bravo backups # linstor resource create charlie backups
volume-definition create コマンドは --vlmnr オプションなしで 使用されるので、LINSTOR は 0 から始まるボリューム番号を割り当てます。 以下の2行では、0 と 1 は自動的に割り当てられたボリューム番号を参照しています。

ここで、’resource create’ コマンドは --storage-pool オプションを必要としません。 この場合、LINSTORは’fallback’ストレージプールを使用します。そのストレージプールを 見つけるために、LINSTORは以下のオブジェクトのプロパティを 以下の順序で問い合わせます。

  • Volume definition

  • Resource

  • Resource definition

  • Node

これらのオブジェクトのいずれにも StorPoolName プロパティが含まれていない場合、 コントローラは、ハードコードされた ‘DfltStorPool’ 文字列をストレージプールとして使用します。

これはまた、リソースをデプロイする前にストレージプールを定義し忘れた場合、 LINSTORは’DfltStorPool’という名前のストレージプールを見つけられなかった というエラーメッセージを受け取ることを意味します。


LINSTORはDRBDを使わずとも使用できます。 DRBDがなくても、LINSTORはLVMおよびZFS 下位ストレージプールからボリュームをプロビジョニングし、LINSTORクラスタ内の個々のノードにそれらのボリュームを作成できます。

現在LINSTORはLVMとZFSボリュームの作成をサポートしており、LUKS、DRBD、または NVMe-oF/NVMe-TCP の組み合わせをそれらのボリュームの上に重ねることもできます。

たとえば、Thin LVM 下位ストレージプールがクラスタ内で thin-lvm という名前で定義されているとします。

# linstor --no-utf8 storage-pool list
| StoragePool | Node      | Driver   | PoolName          | ... |
| thin-lvm    | linstor-a | LVM_THIN | drbdpool/thinpool | ... |
| thin-lvm    | linstor-b | LVM_THIN | drbdpool/thinpool | ... |
| thin-lvm    | linstor-c | LVM_THIN | drbdpool/thinpool | ... |
| thin-lvm    | linstor-d | LVM_THIN | drbdpool/thinpool | ... |

以下のコマンドで LINSTOR を使用してサイズが100Gバイトの Thin LVM を linstor-d 上に作成できます。

# linstor resource-definition create rsc-1
# linstor volume-definition create rsc-1 100GiB
# linstor resource create --layer-list storage \
          --storage-pool thin-lvm linstor-d rsc-1

以下で linstor-d に新しい Thin LVM ボリュームを確認できます。 linstorのリソースを --machine-reader フラグを付けてリストすることで LINSTORからデバイスパスを抽出することができます。

# linstor --machine-readable resource list | grep device_path
            "device_path": "/dev/drbdpool/rsc-1_00000",

ZFSまたはLVM下位ボリューム用のデフォルトの --layer-list オプションで ある DRBD をこのボリューム上に階層化したい場合は、代わりに以下の リソース作成パターンを使用します。

# linstor resource-definition create rsc-1
# linstor volume-definition create rsc-1 100GiB
# linstor resource create --layer-list drbd,storage \
          --storage-pool thin-lvm linstor-d rsc-1

linstor-d に Thin LVM を下位デバイスとするDRBDボリュームがあることが わかります。

# linstor --machine-readable resource list | grep -e device_path -e backing_disk
            "device_path": "/dev/drbd1000",
            "backing_disk": "/dev/drbdpool/rsc-1_00000",




Child layer












1つのレイヤーは、layer-list で1回しか使用できません。
luks レイヤの必要条件についての情報はこのユーザガイドの暗号化ボリュームの節を参照ください。

3.5.1. NVMe-oF/NVMe-TCP LINSTOR レイヤ

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

NVMe-oF only works on RDMA-capable networks and NVMe-TCP on networks that can carry IP traffic. You can use tools such as lshw or ethtool to verify the capabilities of your network adapters.

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:

# apt install nvme-cli
If you are not on a DEB-based system, use the suitable command for installing packages on your operating system, for example, on SLES: zypper; on RPM-based systems: dnf.

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

# linstor resource-definition create nvmedata -l nvme,storage
DRBDが使用されている場合、デフォルトでは -l(layer-stack) パラメータは drbd,storage に設定されています。 NVMeもDRBDも使用せずにLINSTORリソースを作成したい場合は、 -l パラメータを storage だけに設定する必要があります。

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

# linstor resource-definition set-property nvmedata NVMe/TRType tcp

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

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

# linstor volume-definition create nvmedata 500G



# linstor resource create alpha nvmedata --storage-pool pool_ssd


# linstor resource create beta nvmedata --nvme-initiator

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

ノードに複数のNICがある場合は、NVMe-of/NVME-TCP に対してそれらの間の経路を強制する必要があります。そうしないと、複数のNICで問題が発生する可能性があります。

3.5.2. OpenFlex™ Layer

バージョン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 クラスター全体に反映できます。

  • StorDriver/Openflex/ApiHost : API エントリポイントのホストまたは IP を指定する

  • StorDriver/Openflex/ApiPort : REST 呼び出しで使用される基本的な http://ip:port の port の部分を指定する

  • StorDriver/Openflex/UserPassword : REST ユーザのパスワードを指定する

これらが設定されたら、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 node create-openflex-target ofNode1 000af795789d


  • ofNode1 は標準の linstor node create コマンドでも使用されるノード名です。

  • は提供された NVMe デバイスにアクセスされるアドレスです。NVMe デバイスは専用のネットワークインターフェースによってアクセスされるため、このアドレスは、 StorDriver/Openflex/ApiHost プロパティで指定されたアドレスとは異なります。後者は管理 / REST API に使用されます。

  • 000af795789d はOpenFlexストレージデバイスの識別子です。

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

$ linstor storage-pool create openflex ofNode1 sp0 0
  • ofNode1sp0 は、LINSTORs create storage pool コマンドの場合と同様に、それぞれノード名とストレージプール名です。

  • 最後の 0 は以前に定義されたストレージデバイス内の OpenFlex ストレージプールの識別子です。

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

# set the properties once
linstor controller set-property StorDriver/Openflex/ApiHost
linstor controller set-property StorDriver/Openflex/ApiPort 80
linstor controller set-property StorDriver/Openflex/UserName myusername
linstor controller set-property StorDriver/Openflex/UserPassword mypassword

# create a node for openflex storage device "000af795789d"
linstor node create-openflex-target ofNode1 000af795789d

# create a usual linstor satellite. later used as nvme initiator
linstor node create bravo

# create a storage pool for openflex storage pool "0" within storage device "000af795789d"
linstor storage-pool create openflex ofNode1 sp0 0

# create resource- and volume-definition
linstor resource-definition create backupRsc
linstor volume-definition create backupRsc 10G

# create openflex-based nvme target
linstor resource create ofNode1 backupRsc --storage-pool sp0 --layer-list openflex

# create openflex-based nvme initiator
linstor resource create bravo backupRsc --nvme-initiator --layer-list openflex
In case a node should access the OpenFlex REST API through a different host than specified with
linstor controller set-property StorDriver/Openflex/ApiHost you can always use LINSTOR’s inheritance mechanism for properties. That means simply define the same property on the node-level you need it, i.e.
linstor node set-property ofNode1 StorDriver/Openflex/ApiHost

3.5.3. 書き込みキャッシュレイヤー

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

# linstor storage-pool create lvm node1 lvmpool drbdpool
# linstor storage-pool create lvm node1 pmempool pmempool

# linstor resource-definition create r1
# linstor volume-definition create r1 100G

# linstor volume-definition set-property r1 0 Writecache/PoolName pmempool
# linstor volume-definition set-property r1 0 Writecache/Size 1%

# linstor resource create node1 r1 --storage-pool lvmpool --layer-list WRITECACHE,STORAGE

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

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

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

3.5.4. キャッシュレイヤー

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

# linstor storage-pool create lvm node1 lvmpool drbdpool
# linstor storage-pool create lvm node1 pmempool pmempool

# linstor resource-definition create r1
# linstor volume-definition create r1 100G

# linstor volume-definition set-property r1 0 Cache/CachePool pmempool
# linstor volume-definition set-property r1 0 Cache/Cachesize 1%

# linstor resource create node1 r1 --storage-pool lvmpool --layer-list CACHE,STORAGE
Writecache レイヤーを構成する Writecache/PoolName と異なり、Cache レイヤーの唯一の必須プロパティは Cache/CachePool です。これは、Cache レイヤーの Cache/MetaPool は個別に設定するか、またはデフォルトで Cache/CachePool の値を設定するからです。

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

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

3.5.5. ストレージレイヤー

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

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

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

  • StorDriver/WaitTimeoutAfterCreate: LINSTOR が作成後にデバイスが表示されることを期待している場合(たとえば lvcreate, zfs create,…​ の呼び出し後)、LINSTOR はデフォルトで 500ms ごとにデバイスが表示されるのを待ちます。これらの 500ms は、このプロパティによってオーバーライドできます。

  • StorDriver/dm_stats: true に設定すると、LINSTOR は作成後に dmstats create $device を呼び出し、ボリュームの削除後に dmstats delete $device --allregions を呼び出します。現在、LVM および LVM_THIN ストレージプロバイダーに対してのみ有効になっています。

3.6. ストレージプロバイダー

LINSTOR にはいくつかのストレージプロバイダーがあります。最も使用されているのは LVM と ZFS です。しかし、これら 2 つのプロバイダーについても、シンプロビジョニングされた異なるサブタイプがすでに存在します。

  • Diskless: このプロバイダータイプには、Managing Network Interface Cards で説明されているように PrefNic などの LINSTOR プロパティで構成できるストレージプールがほとんどの場合必要です。

  • LVM / LVM-Thin: 管理者は、対応するストレージタイプを使用するために、LVM ボリュームグループまたはシンプール(”LV/thinpool” の形式)を指定する必要があります。これらのドライバーは、チューニング用に次のプロパティをサポートします。

    • StorDriver/LvcreateOptions: このプロパティの値は、LINSTOR が実行するすべての lvcreate …​ 呼び出しの LINSTOR 実行に追加されます。

  • ZFS / ZFS-Thin: 管理者は、LINSTOR が使用する ZPool を指定する必要があります。これらのドライバーは、チューニング用に次のプロパティをサポートします。 これらのドライバーは、調整のために次のプロパティをサポートします。

    • StorDriver/ZfscreateOptions: このプロパティの値は、LINSTOR が実行するすべての zfs create …​ 呼び出しの LINSTOR 実行に追加されます。

  • File / FileThin: 主にデモンストレーション/実験に使用されます。LINSTOR は基本的に、指定されたディレクトリにファイルをリザーブし、そのファイルの上に ループデバイス を構成します。

  • OpenFlex: この特別なストレージプロバイダーは現在、特別なサテライトで実行する必要があります。詳細は OpenFlex™ Layer を参照ください。

  • EXOS: この特別なストレージプロバイダーは現在、特別なサテライトで実行する必要があります。詳細は EXOS Integration を参照ください。

  • SPDK: 管理者は、LINSTOR が使用する論理ボリュームストアを指定する必要があります。このストレージプロバイダーの使用法は NVME Layer 使用を意味します。

    • Remote-SPDK: この特別なストレージプロバイダーは現在、特別なサテライトで実行する必要があります。詳細は Remote SPDK Provider を参照ください。

3.6.1. リモート SPDK プロバイダー

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

$ linstor node create-remote-spdk-target nodeName

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

$ linstor node create-remote-spdk-target -h
usage: linstor node create-remote-spdk-target [-h] [--api-port API_PORT]
                                              [--api-user API_USER]
                                              [--api-user-env API_USER_ENV]
                                              [--api-pw [API_PW]]
                                              [--api-pw-env API_PW_ENV]
                                              node_name api_host

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


$ linstor storage-pool create remotespdk -h
usage: linstor storage-pool create remotespdk [-h]
                                              [--shared-space SHARED_SPACE]
                                              node_name name driver_pool_name

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

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

3.7. ネットワークインターフェイスカードの管理

LINSTORはマシンの複数のネットワークインターフェイスカード(NIC)を扱えます。LINSTORでこれらは netif と呼びます。

サテライト ノードが作成されると、最初のネット インターフェイスが「default」という名前で暗黙的に作成されます。サテライトノードを作成するときに、node create コマンドの –interface-name オプションを使用して別の名前を付けることができます。


# linstor node interface create node-0 10G_nic

ネットインターフェイスは IP アドレスのみで識別されます。名前は任意であり、Linux で使用される NIC 名とは関係ありません。次に、ネットインターフェイスをノードに割り当てて、ノードの DRBD トラフィックが対応する NIC を介してルーティングされるようにします。

# linstor node set-property node-0 PrefNic 10G_nic
ストレージプールに「PrefNic」プロパティを設定することもできます。ストレージプールを使用するリソースからの DRBD トラフィックは、対応する NIC 経由でルーティングされます。ただし、ここで注意が必要です。ディスクレスストレージを必要とする DRBD リソース (たとえば、DRBD クォーラムの目的でタイブレーカーの役割を果たしているディスクレス ストレージ) は、「default」ネットインターフェイスの「PrefNic」プロパティを設定するまで、デフォルトのサテライトノードのネットインターフェイスを通過します。セットアップが複雑になる可能性があります。ノードレベルで「PrefNic」プロパティを設定する方がはるかに簡単で安全です。これにより、ディスクレスストレージプールを含む、ノード上のすべてのストレージプールが優先 NIC を使用します。

If you need to add an interface for only controller-satellite traffic, you can add an interface using the above node interface create command. Then you modify the connection to make it the active controller-satellite connection. For example, if you added an interface named 1G-satconn on all nodes, after adding the interface, you can then tell LINSTOR to use this interface for controller-satellite traffic by entering the following command:

# linstor node interface modify node-0 1G-satconn --active

You can verify this change by using the linstor node interface list node-0 command. Output from the command should show that the StltCon label applies to the 1G-satconn interface.

While this method routes DRBD traffic through a specified NIC, it is not possible through linstor commands only, to route LINSTOR controller-client traffic through a specific NIC, for example, commands that you issue from a LINSTOR client to the controller. To achieve this, you can either:

  • Specify a LINSTOR controller by using methods outlined in LINSTORクライアントの使用 and have the only route to the controller as specified be through the NIC that you want to use for controller-client traffic.

  • ip routeiptables などの Linux ツールを使用して、LINSTOR クライアントコントローラートラフィックのポート番号 3370 をフィルタリングし、特定の NIC を介してルーティングする。

3.7.1. LINSTORによる複数のDRBDパスの作成

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

# linstor node interface create alpha nic1
# linstor node interface create alpha nic2
# linstor node interface create bravo nic1
# linstor node interface create bravo nic2

# linstor resource-connection path create alpha bravo myResource path1 nic1 nic1
# linstor resource-connection path create alpha bravo myResource path2 nic2 nic2

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:

resource myResource {
  connection {
    path {
      host alpha address;
      host bravo address;
    path {
      host alpha address;
      host bravo address;
How Adding a New DRBD Path Affects the Default Path

The NIC that is first in order on a LINSTOR satellite node is named the default net interface. DRBD traffic traveling between two nodes that do not have an explicitly configured resource connection path will take an implicit path that uses the two nodes’ default net interfaces.

When you add a resource connection path between two nodes for a DRBD-backed resource, DRBD traffic between the two nodes will use this new path only, although a default network interface will still exist on each node. This may be significant if your new path uses different NICs than the implicit default path.

To use the default path again, in addition to any new paths, you will need to explicitly add it. For example:

# linstor resource-connection path create alpha bravo myResource path3 default default

Although the newly created path3 uses net interfaces that are named default on the two nodes, the path itself is not a default path because other paths exist, namely path1 and path2. The new path, path3, will just act as a third possible path, and DRBD traffic and path selection behavior will be as described in the next section.

Multiple DRBD Paths Behavior

The behavior of a multiple DRBD paths configuration will be different depending on the DRBD transport type. From the DRBD User’s Guide[4]:

“The TCP transport uses one path at a time. If the backing TCP connections get dropped, or show timeouts, the TCP transport implementation tries to establish a connection over the next path. It goes over all paths in a round-robin fashion until a connection gets established.

“The RDMA transport uses all paths of a connection concurrently and it balances the network traffic between the paths evenly.”

3.8. 暗号化ボリューム


dm-crypt を使用するには、サテライトを開始する前に cryptsetup がインストールされていることを確認してください。


  1. マスターパスフレーズを作成する

  2. layer-list に luks を追加します。すべてのプラグイン(Proxmoxなど)は、特に明記しない限り、最上位のレイヤーとして DRBD レイヤーを必要とすることに注意してください。

  3. コントローラが再起動した後はマスターパスフレーズを再入力する

3.8.1. 暗号化のコマンド



# linstor encryption create-passphrase

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


# linstor encryption modify-passphrase

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

# linstor resource-definition create crypt_rsc --layer-list luks,storage


# linstor encryption enter-passphrase

3.8.2. 自動パスフレーズ


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

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



マスターパスフレーズがすでに設定されていて、環境変数または linstor.toml で指定されたものと同じでない場合、コントローラはマスターパスフレーズを再入力できず、ユーザーがパスフレーズ間違って入力したかのように動作します。これは、自動パスフレーズなしでコントローラを起動した場合と同じで、コマンドを使用して、ユーザーからの手動入力によってのみ解決できます。
マスターパスフレーズが環境変数と linstor.toml の両方に設定されている場合、linstor.toml からのマスターパスフレーズのみが使用されます。

3.9. クラスター状態の確認

LINSTORにはクラスタの状態をチェックするいろいろなコマンドがあります。これらには ‘list’ サブコマンドを使用し、フィルターしたりソートしたりするいろいろなオプションを提供します。’–groupby’ オプションは出力のグルーピングとソートに使います。

# linstor node list
# linstor storage-pool list --groupby Size

3.10. ノードの退避

LINSTOR コマンド node evacuate を使用して、ノードのリソースを退避することができます。たとえば、クラスターからノードを削除する準備をしていて、ノードのリソースをクラスター内の他のノードに移動する必要がある場合です。ノードの退避に成功すると、ノードの LINSTOR ステータスは “Online” ではなく “EVACUATE” と表示され、LINSTOR リソースを持ちません。

LINSTOR が Kubernetes や OpenNebula などの別の環境内にデプロイされているノードを退避する場合は、リソースを退避する前に、ノードの LINSTOR でサポートされているワークロードをクラスター内の別のノードに移動する必要があります。Kubernetes 環境については Kubernetes でのノードの退避 を参照してください。OpenNebula の LINSTOR ノードの場合、ノードのリソースを退避する前に、ノードがホストする OpenNebula LINSTOR ベースの仮想マシンをクラスター内の別のノードにライブマイグレードする必要があります。


  1. 退避するノード上のリソースが “InUse” であるかどうかを確認します。 “InUse” ステータスは、リソースが DRBD Primary 状態です。ノードを正常に退避させるには、ノード上のリソースを “InUse” にしないでください。そうしないと、LINSTOR は退避中にノードから “InUse” リソースを削除できません。

  2. linstor node evacuate <node_name> を実行します。退避ノード上のリソースに適した代替ノードがない場合は、警告が表示されます。たとえば、3 つのノードがあり、1 つを退避したいが、リソースグループで配置数が 3 に設定されている場合、ノードが退避ノードからリソースを削除できないという警告が表示されます。

  3. ノードの linstor node list のステータスが、 “Online” ではなく、 “EVACUATE” であることを確認してください。

  4. linstor resource list コマンドを使用して、ノード上のリソースの “State” ステータスを確認します。ノードのリソース内のデータセットのサイズに応じて、しばらく同期アクティビティが表示されるはずです。

  5. linstor resource list --nodes <node_name> コマンドを使用して、ノード上の残りのリソースを一覧表示します。残っている場合は、同期が完了するのを待っているだけかどうかを確認します。

  6. linstor resource list コマンドを使用して、ノードにリソースがないことを確認します。

  7. linstor node delete node_name> コマンドを使用して、クラスタからノードを削除します。

3.10.1. 複数のノードの退避

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

# linstor node set-property <node_name> AutoplaceTarget false

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

3.10.2. 退避ノードの復元

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

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

node restore コマンドの実行時に LINSTOR がすでにリソースを退避している場合、退避されたリソースは自動的にノードに戻りません。 LINSTOR がまだリソースを退避中の場合、このプロセスは、LINSTOR が他のノードにリソースを配置するまで続行されます。以前復元されたノードにあったリソースを手動で「移動」する必要があります。これを行うには、最初に復元されたノードでリソースを作成し、次に LINSTOR がリソースを配置した別のノードからリソースを削除します。リソースが配置されているノードを表示するには resource list コマンドを使用できます。

3.11. スナップショットの管理

スナップショットはthin LVMとZFSストレージプールでサポートされています。

3.11.1. スナップショットの作成

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

# linstor snapshot create resource1 snap1


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

# linstor resource-definition set-property AutoSnapshot/RunEvery 15
# linstor resource-definition set-property AutoSnapshot/Keep 5

3.11.2. スナップショットの復元



# linstor resource-definition create resource2
# linstor snapshot volume-definition restore --from-resource resource1 \
  --from-snapshot snap1 --to-resource resource2


# linstor snapshot resource restore --from-resource resource1 \
  --from-snapshot snap1 --to-resource resource2

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

3.11.3. スナップショットへのロールバック

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


# linstor snapshot rollback resource1 snap1


3.11.4. スナップショットの削除


# linstor snapshot delete resource1 snap1

3.11.5. スナップショットの転送

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


  • zstd はデータが転送される前に圧縮するために必要です。

  • thin-send-recv は lvm-thin でデータを転送するために必要です。

これらのツールをインストールした後、サテライトを再起動する必要があります。そうしないと、LINSTOR はそれらを使用できなくなります。

LINSTOR クラスターでは、転送ターゲットの定義をリモートと呼びます。現在、リモートには LINSTOR リモートと S3 リモートの2種類があります。 LINSTOR リモートは、スナップショットを別の LINSTOR クラスターに送信するために使用されますが、S3 リモートは、スナップショットを AWS S3, または S3 互換オブジェクトストレージを使用するその他のサービスに送信するために使用されます。

リモートはパスワードなどの機密データを保存する必要があるため、何らかの方法で常に暗号化を有効にする必要があります。LINSTOR の暗号化設定は こちら を参照ください。

S3 リモートを作成するには、LINSTOR はエンドポイント(つまり、ターゲット S3 サーバーのURL)、ターゲットバケットの名前、S3 サーバーが存在するリージョン、およびアクセスキーとシークレットが必要です。アクセスキーを使用せずにコマンドを送信すると、プロンプトが表示されます。コマンドは次のようになります。

# linstor remote create s3 myRemote \
  my-bucket us-west-2 admin password
通常、LINSTOR は指定されたバケット( など)にアクセスするために、エンドポイントとバケットを使用して、仮想ホストスタイルの URL を作成します。この方法でのアクセスが許可されていない場合は --use-path-style 引数を追加して、パススタイルのアクセス(例:に変更できます。

LINSTOR リモートを作成するには、ターゲットクラスターのコントローラーの URL または IP アドレスのみが必要です。コマンドは次のようになります。

# linstor remote create linstor myRemote

さらに、LUKSベースの(暗号化された)バックアップを転送するには、コマンドに --passphrase, --cluster-id を追加する必要があります。これは、ターゲットクラスターのパスフレーズとクラスター ID を保存するために使用されます。2 つの LINSTOR クラスター間での LUKS ベースのバックアップの転送に関する詳細は こちら を参照ください。

ローカルクラスタに認識されているすべてのリモートを表示するには linstor remote list を、削除するには linstor remote delete myRemoteName を、変更する場合は linstor remote modify を使用します。

スナップショットの S3 への転送

スナップショットを S3 に送信するには、現在のクラスターが到達できる S3 リモートに、送信する必要のあるリソースを転送するだけです。次に、次のコマンドを使用して転送します。

# linstor backup create myRemote myRsc

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

特定のリモートのバックアップを確認するには linstor backup list myRemote を使用します。引数 --resource myRsc を使用して、特定のリソースのバックアップのみを表示するフィルターとして resource-name をコマンドに追加できます。 --other 引数を使用すると、LINSTOR がバックアップとして認識しないバケット内のエントリのみが表示されます。LINSTOR は常に特定の方法でバックアップに名前を付けます。リモート内のアイテムにこのスキーマに従って名前が付けられている限り、それは LINSTOR によって作成されたバックアップであると見なされます。したがって、このリストには他のすべてが表示されます。


  • linstor backup delete all myRemote : このコマンドは、バックアップであると認識されている、つまり期待されるネーミングスキーマに適合している限り、指定されたリモート上のすべての S3 オブジェクトを削除します。現在のクラスターによって作成されたバックアップのみを削除するオプション --cluster があります。

  • linstor backup delete id myRemote my-rsc_back_20210824_072543 : このコマンドは、指定されたリモートから単一のバックアップを削除します。つまり、ID はリソース名、自動生成されたスナップショット名(back_timestamp)、設定されていた場合はバックアップサフィックスで構成されます。オプション --prefix を使用すると、指定された ID で始まるすべてのバックアップを削除できます。オプション --cascade を使用すると、指定されたバックアップだけでなく、それに依存する他のすべての増分バックアップを削除します。

  • linstor backup delete filter myRemote …​ : このコマンドは、削除するバックアップの選択を指定するためのいくつかの異なる引数があります。 -t 20210914_120000 は 2021年9月14日の 12 時より前に作成されたすべてのバックアップを削除します。 -n myNode は指定されたノードによってアップロードされたすべてのバックアップを削除します。 -r myRsc は指定されたリソース名のすべてのバックアップを削除します。これらのフィルターは必要に応じて組み合わせることができます。最後に --cascade は選択したバックアップだけでなく、選択したバックアップのすべての増分バックアップを削除します。

  • linstor backup delete s3key myRemote randomPictureInWrongBucket : このコマンドは、指定された S3 キーを持つオブジェクトを検索し、何も考慮せずにそれを削除します。これは、リモートから非バックアップアイテムを削除するか、他の方法で削除できなくなった壊れたバックアップをクリーンアップするためにのみ使用します。このコマンドを使用して通常の動作中のバックアップを削除すると、そのバックアップが破損するため、注意してください。

--cascade オプションを持つすべてのコマンドは、明示的に指定しない限り、それに依存する増分バックアップを削除しません。
すべての linstor backup delete …​ コマンドには --dry-run オプションがあり、削除されるすべての S3 オブジェクトのリストが表示されます。これを使用して、削除してはならないものが誤って削除されることを防ぐことができます。

おそらく、バックアップを作成した後の最も重要なタスクは、バックアップを復元することです。そのために必要なのはリモートのみですが、既存のスナップショットやリソースを使用せずに既存のリソース定義に復元することもできます。コマンドには 2 つのオプションがあります。

# linstor backup restore myRemote myNode targetRsc --resource sourceRsc
# linstor backup restore myRemote myNode targetRsc --id sourceRsc_back_20210824_072543

--resource (-r) または --id のいずれかを使用する必要がありますが、両方を一緒に使用することはできません。 -r はこのオプションで指定されたリソースの最新のバックアップを復元するために使用されますが、--id は id で明示的に指定されたバックアップを復元するため、最新以外のバックアップを復元するために使用されます。

復元するバックアップに LUKS レイヤーが含まれている場合は --passphrase 引数が必要です。これを使用して、バックアップの元のクラスターのパスフレーズを設定し、LINSTOR がダウンロード後にボリュームを復号化し、再暗号化できるようになります。

バックアップの復元は、最後の完全バックアップから指定されたバックアップまでのすべてのスナップショットをダウンロードします。その後、スナップショットを新しいリソースに復元します。最後のステップをスキップする場合は --download-only オプションを追加します。

バックアップは、設定が正しい限り、アップロードしたクラスターだけでなく、任意のクラスターからダウンロードできます。具体的には、ターゲットリソースに既存のリソースまたはスナップショットを含めることはできず、使用するストレージプールには同じストレージプロバイダーが必要です。ターゲットノードのストレージプールの名前が、バックアップが作成されたクラスターの名前とまったく同じである場合、追加のアクションは必要ありません。名前が異なる場合は、オプション --storpool-rename を使用します。少なくとも 1 つの oldname=newname ペアが必要です。そのリストで名前が付けられていない元のバックアップのすべてのストレージプールについて、その名前はターゲットノードでまったく同じであると見なされます。

名前を変更する必要のあるストレージプールやダウンロードと復元されたリソースのサイズを正確に確認するには、コマンド linstor backup info myRemote …​ を使用できます。復元コマンドと同様に -r または --id のいずれかを指定する必要があり、これにより、同じ制限が追加されます。復元後にローカルストレージプールに残っているスペースを確認するには、引数 -n myNode を追加します。復元の場合と同様に、特定のノードのストレージプール名がバックアップの場合とまったく同じであると想定します。そうでない場合も、復元コマンドの場合と同様に --storpool-rename を使用します。

Shipping Snapshots Between Two LINSTOR Clusters

Shipping a snapshot directly between two LINSTOR clusters can be done with a LINSTOR remote as well as a resource definition with at least one diskful resource on the source side (where the shipping command is issued). On the target side, you need to create a LINSTOR remote with the cluster ID of the source (remote) cluster:

$ linstor remote create linstor --cluster-id <SOURCE_CLUSTER_ID> <NAME> <URL>
If you do not specify the cluster ID of your source cluster when you create a LINSTOR remote on your target cluster, you will receive an “Unknown Cluster” error when you try to ship a backup. To get the cluster ID of your source cluster, you can enter the command linstor controller list-properties|grep -i cluster from the source cluster.

In the remote create command shown above, <NAME> is an arbitrary name that you specify to identify the remote. <URL> is either the IP address of the source (remote) LINSTOR controller or its resolvable hostname. If you have configured a highly available LINSTOR controller, use its virtual IP address (VIP) or the VIP’s resolvable name.

Snapshot Shipping Within a Single LINSTOR Cluster

If you want to ship a snapshot inside the same cluster, you just need to create a LINSTOR remote that points to the local controller.

Specifying a LINSTOR Passphrase When Creating a Remote

When the snapshot that you want to ship contains a LUKS layer, the remote on the target cluster also needs the passphrase of the source cluster set when you create the remote. This is because the LINSTOR passphrase is used to encrypt the LUKS passphrase. To specify the source cluster’s LINSTOR passphrase when you create a LINSTOR remote on the target cluster, enter:

$ linstor --controllers <TARGET_CONTROLLER> remote create linstor \

For LINSTOR to LINSTOR snapshot shipping, you must also create a LINSTOR remote on the source cluster. For simplicity sake, although not strictly necessary, you can specify the target cluster’s LINSTOR passphrase when you create a LINSTOR remote for the target cluster on the source cluster, before you ship backups or snapshots. On the source cluster, enter:

$ linstor --controllers <SOURCE_CONTROLLER> remote create linstor \
If you are specifying a LINSTOR controller node (perhaps because you have a highly available controller), when creating a remote, you can specify the controller either by an IP address or a resolvable hostname.
Shipping a Backup of a LINSTOR Resource


# linstor backup ship myRemote localRsc targetRsc

さらに --source-node--target-node を使用して、バックアップを送信および受信するノードをそれぞれ指定できます。これらのノードが使用できない場合は、別のノードが自動的に選択されます。

targetRsc がすでにリモートクラスタにデプロイされているリソースである場合、 localRsc のバックアップ転送のスナップショットはリモートクラスタに転送されますが、リモートクラスタでは復元されません。 linstor backup ship コマンドで --download-only オプションを指定した場合も同様です。

Controlling How Many Shipments Are Active at the Same Time

There might be cases where an automated task (be it LINSTOR’s scheduled shipping or an external tool) starts too many shipments at once, leading to an overload of the network or some of the nodes sending the backups.

In a case like this the solution is to reduce the amount of shipments that can happen at the same time on the same node. This is done by using the property BackupShipping/MaxConcurrentBackupsPerNode. This property can be set either on the controller or on a specific node.

The expected value for this property is a number. Setting it to any negative number will be interpreted as “no limit”, while setting it to zero will result in this specific node not being eligible to ship any backups – or completely disabling backup shipping if the property is set to 0 on the controller.

Any other positive number is treated as a limit of concurrently active shippings per node. To determine which node will send a backup shipment, LINSTOR uses the following logic in the order shown:

  1. The node specified in the command (--source-node for shippings to another cluster, --node for shipping to S3 compatible storage) will ship the backup.

  2. The node that has the most available backup slots will ship the backup.

  3. If no node has an available backup slot, the shipment will be added to a queue and started as soon as a different shipment has finished which leads to a backup slot becoming available.



# linstor resource deactivate nodeTarget resource1
レイヤーリストに DRBD があるリソースを非アクティブ化すると、再びアクティブ化することはできません。ただし、DRBD リソースの正常に転送されたスナップショットは 新しいリソースで復元 できます。


# linstor snapshot ship --from-node nodeSource --to-node nodeTarget --resource resource1
snapshot ship コマンドは非推奨と見なされ、それで見つかったバグは修正されません。代わりに、リモートがローカルコントローラを指している状態で backup ship コマンドを使用してください。詳細は こちら を参照ください。

By default, the snapshot-shipping uses TCP ports from the range 12000-12999. To change this range, the property SnapshotShipping/TcpPortRange, which accepts a to-from range, can be set on the controller:

# linstor controller set-property SnapshotShipping/TcpPortRange 10000-12000

リソースは定期的に転送することもできます。これにはリソース定義で必須のプロパティ SnapshotShipping/TargetNode および SnapshotShipping/RunEvery を設定する必要があります。SnapshotShipping/SourceNode も設定できますが、省略した場合、LINSTOR は同じリソース定義のアクティブなリソースを選択します。

増分スナップショット転送を可能にするには、LINSTOR は少なくとも最後に転送されたスナップショットをターゲットノードに保持する必要があります。プロパティ SnapshotShipping/Keep は、LINSTOR が保持する必要があるスナップショットの数を指定するために使用できます。プロパティが設定されていない(または 0 以下)の場合、LINSTOR はデフォルトで最新の10個のスナップショットを保持します。

# linstor resource-definition set-property resource1 SnapshotShipping/TargetNode nodeTarget
# linstor resource-definition set-property resource1 SnapshotShipping/SourceNode nodeSource
# linstor resource-definition set-property resource1 SnapshotShipping/RunEvery 15
# linstor resource-definition set-property resource1 SnapshotShipping/Keep 5

3.12. 計画されたバックアップの配信

LINSTOR Controller バージョン 1.19.0 以降、LINSTOR クライアントバージョン 1.14.0 以降では、配置された LINSTOR リソースのスケジュールバックアップの配信を設定することができます。


  • バックアップと配信を行いたい1つまたは複数のLINSTORリソースからなるデータセット

  • バックアップの配信先(他のLINSTORクラスタまたはS3インスタンス)

  • バックアップを発行するタイミングを定義するスケジュール


3.12.1. バックアップの配信スケジュールを作成する

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


# linstor schedule create \
  --incremental-cron '* * * * *' \ (1)
  --keep-local 5 \ (2)
  --keep-remote 4 \ (3)
  --on-failure RETRY \ (4)
  --max-retries 10 \ (5)
  <schedule_name> \ (6)
  '* * * * *' # full backup cron schema (7)
1 指定された場合、増分cronスキーマは、増分バックアップを作成し、出荷する頻度を記述します。新しいインクリメンタルバックアップは、最新のフルバックアップに基づいて行われます。
2 The --keep-local option allows you to specify how many snapshots that a full backup is based upon should be kept at the local backup source. If unspecified, all snapshots will be kept. [OPTIONAL]
3 --keep-remote オプションは、リモートバックアップ先で保持するフルバックアップの数を指定することができます。このオプションはS3リモートバックアップ先でのみ機能します。なぜなら、クラスタノードが他のクラスタ内のノードからバックアップを削除することを許可したくないからです。削除されたフルバックアップに基づくすべての増分バックアップも、リモートディスティネーションで削除されます。指定しない場合、--keep-remote オプションはデフォルトで “all” になります。[OPTIONAL]
4 スケジュールされたバックアップの出荷が失敗した場合に、”RETRY “または “SKIP “のどちらを行うかを指定します。SKIP” が指定された場合、LINSTORは失敗を無視し、次に予定されているバックアップの配送を続行します。RETRY” が指定された場合、LINSTORは60秒待って、再度バックアップの配送を試みます。LINSTOR の schedule create コマンドは --on-failure オプションが与えられないと、デフォルトで “SKIP” になります。[OPTIONAL]
5 バックアップの出荷が失敗し、--on-failure RETRY オプションが指定された場合、バックアップの出荷を再試行する回数です。このオプションがない場合、LINSTORコントローラはスケジュールされたバックアップの出荷を、成功するまで無期限に再試行します。[OPTIONAL]
6 スケジュールリスト、修正、削除、有効、無効コマンドで後で参照できるように、バックアップスケジュールに付ける名前です。[REQUIRED]
7 このcronスキーマは、LINSTORがどの程度の頻度でスナップショットを作成し、フルバックアップを出荷するかを記述しています。

3.12.2. バックアップの配信スケジュールを変更する

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

3.12.3. Configuring the Number of Local Snapshots and Remote Backups to Keep


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


例えば、--keep-local=2 オプションが設定されている場合、バックアップの出荷スケジュールは、最初の実行時に、フルバックアップのためのスナップショットを作成することになります。次にスケジュールされたフルバックアップの出荷では、フルバックアップのための2番目のスナップショットを作成します。次のスケジュールされたフルバックアップの出荷では、フルバックアップのための3番目のスナップショットが作成されます。しかし今回は、正常に完了すると、LINSTORは最初の(最も古い)フルバックアップの出荷用スナップショットを削除します。もしスナップショットがこのフルバックアップに基づく増分バックアップのために作成された場合、それらはローカルソースノードから削除されます。次のフルバックアップの出荷が成功すると、LINSTORは2番目のフルバックアップのスナップショットとそれに基づくすべての増分スナップショットを削除し、これを繰り返すことで各バックアップの出荷が成功します。

If there are local snapshots remaining from failed shipments, these will be deleted first, even if they were created later.



上記の linstor schedule create コマンドの例のコールアウトで述べたように、 keep-remote オプションはS3リモートデスティネーションに対してのみ機能します。ここでは、このオプションがどのように機能するかの例を示します。keep-remote=2` オプションが設定されている場合、バックアップ出荷スケジュールは、最初の実行時に、フルバックアップ用のスナップショットを作成し、それをリモートデスティネーションに出荷します。次にスケジュールされたフルバックアップの出荷では、2番目のスナップショットが作成され、フルバックアップがリモートデスティネーションに出荷されます。次にスケジュールされたフルバックアップの出荷時に、3つ目のスナップショットが作成され、フルバックアップがリモートディスティネーションに出荷されます。今回はさらに、3つ目のスナップショットが正常に出荷された後、最初のフルバックアップがリモートディスティネーションから削除されます。フルバックアップの間に増分バックアップがスケジュールされていた場合、最初のフルバックアップから作成されたものはフルバックアップと一緒に削除されます。

このオプションは、リモート宛先のバックアップを削除するだけです。ローカル ソース ノードでのフル バックアップの基となったスナップショットは削除されません。

3.12.4. バックアップの配信スケジュールを記載する

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

For example:

# linstor schedule list
┊ Name                ┊ Full        ┊ Incremental ┊ KeepLocal ┊ KeepRemote ┊ OnFailure ┊
┊ my-bu-schedule      ┊ 2 * * * *   ┊             ┊ 3         ┊ 2          ┊ SKIP      ┊

3.12.5. バックアップした配信予定を削除する

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


3.12.6. バックアップの定期的な配信を可能にする

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

# linstor backup schedule enable \
  [--node source_node] \ (1)
  [--rg resource_group_name | --rd resource_definition_name] \ (2)
  remote_name \ (3)
  schedule_name (4)
1 これは特別なオプションで、可能であればスケジュールされたバックアップ配信のソースとして使用されるコントローラノードを指定することができます。もしこのオプションをコマンドから省略した場合、LINSTORはスケジュールされた配信が行われる時にソースノードを選択することになります。[OPTIONAL]
2 ここでは、バックアップ配信スケジュールを有効にするリソースグループまたはリソース定義のいずれか(ただし両方は不可)を設定できます。このオプションを省略すると、スナップショットを作成できるすべてのLINSTORリソースに対して、バックアップ配信スケジュールが有効になります。[OPTIONAL]
3 バックアップを配信するリモート宛先の名前です。[REQUIRED]
4 以前に作成されたバックアップ配信スケジュールの名前です。[REQUIRED]

3.12.7. バックアップの配信スケジュールを無効にする

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

# linstor backup schedule disable \
  [--rg resource_group_name | --rd resource_definition_name] \
  remote_name \ (3)
  schedule_name (4)

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

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


3.12.8. バックアップされた出荷予定のアスペクトを削除する

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


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がバックアップを出荷するかどうかを決定する方法についてのディシジョンツリー図を参照するとよいかもしれません。

上記の例では、メンテナンス終了後にリソースグループのバックアップ出荷を有効にした場合があります。この場合、リソース定義_resdef3_から_resdef9_についてはバックアップ出荷が再開されますが、リソース定義_resdef1_と_resdef2_についてはバックアップ出荷がまだ無効になっているため、引き続き出荷が行われません。すべてのメンテナンスが完了したら、_resdef1_と_resdef2_のバックアップ出荷スケジュールを削除してください。そうすると、リソースグループレベルでスケジュールとリモートのペアが有効になっているため、メンテナンス前と同じように、すべてのリソース定義でバックアップが出荷されるようになります。しかし、リソースグループレベルで有効化されたスケジュールは、コントローラレベルで適用された`schedule disable` コマンドを上書きするため、コントローラレベルで後の時点ですべてのスケジュールされた出荷をグローバルに停止するオプションは削除されます。

3.12.9. リソース別バックアップ出荷スケジュール一覧表

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

  • リソースにschedule-remote-pairのエントリーがないかどうか(空白のセル)

  • schedule-remote-pairの項目があるが、無効になっているかどうか(”disabled”)。

  • リソースがないため、schedule-remote-pairのエントリーが有効かどうかに関わらず、バックアップ出荷ができないかどうか(”undeployed”)


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

3.12.10. LINSTORコントローラがスケジュールされたバックアップの出荷を決定する方法


linstor controller backup schedule decision flowchart


  1. リソース定義レベル

  2. リソースグループレベル

  3. コントローラーレベル


3.12.11. スケジュールされたバックアップの出荷がリソースに与える影響の確認

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




# linstor schedule list-by-resource-details my_linstor_resource_name
┊ Remote   ┊ Schedule   ┊ Resource-Definition ┊ Resource-Group ┊ Controller ┊
┊ rem1     ┊ sch1       ┊ Disabled            ┊                ┊ Enabled    ┊
┊ rem1     ┊ sch2       ┊                     ┊ Enabled        ┊            ┊
┊ rem2     ┊ sch1       ┊ Enabled             ┊                ┊            ┊
┊ rem2     ┊ sch5       ┊                     ┊ Enabled        ┊            ┊
┊ rem3     ┊ sch4       ┊                     ┊ Disabled       ┊ Enabled    ┊

3.13. Setting DRBD Options for LINSTOR Objects

You can use LINSTOR commands to set DRBD options. Configurations in files that are not managed by LINSTOR, such as /etc/drbd.d/global_common.conf, will be ignored. The syntax for this command is generally:

# linstor <LINSTOR_object> drbd-options --<DRBD_option> <value> <LINSTOR_object_identifiers>

In the syntax above, <LINSTOR_ object_identifiers> is a placeholder for identifiers such as a node name, node names, or a resource name, or a combination of these identifiers.

For example, to set the DRBD replication protocol for a resource definition named backups, enter:

# linstor resource-definition drbd-options --protocol C backups

You can enter a LINSTOR object along with drbd-options and the --help, or -h, flag to show the command usage, available options, and the default value for each option. For example:

# linstor controller drbd-options -h

3.13.1. Setting DRBD Peer Options for LINSTOR Resources or Resource Connections

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:

# linstor resource drbd-peer-options --max-buffers 8192 node-0 node-1 backups

The command above is equivalent to the following:

# linstor resource-connection drbd-peer-options --max-buffers 8192 node-0 node-1 backups

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

# linstor --curl resource drbd-peer-options --max-buffers 8192 node-0 node-1 backups
curl -X PUT -H "Content-Type: application/json" -d '{"override_props": {"DrbdOptions/Net/max-buffers": "8192"}}' http://localhost:3370/v1/resource-definitions/backups/resource-connections/node-0/node-1

# linstor --curl resource-connection drbd-peer-options --max-buffers 8192 node-0 node-1 backups
curl -X PUT -H "Content-Type: application/json" -d '{"override_props": {"DrbdOptions/Net/max-buffers": "8192"}}' http://localhost:3370/v1/resource-definitions/backups/resource-connections/node-0/node-1

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

connection {
        _peer_node_id 1;
        path {
            _this_host ipv4;
            _remote_host ipv4;
        path {
            _this_host ipv4;
            _remote_host ipv4;
        net {
            max-buffers         8192;
            _name               "node-1";
If there are multiple paths between the two nodes, as in the example above, DRBD options that you set using the resource drbd-peer-options command will apply to all of them.

3.13.2. Setting DRBD Options for Node Connections

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

# linstor node-connection drbd-peer-options --ping-timeout 299 node-0 node-1

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.

3.13.3. Verifying Options for LINSTOR Objects

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

# linstor resource-definition list-properties backups
| Key                               | Value            |
| DrbdOptions/Net/protocol          | C                |

3.13.4. Removing DRBD Options from LINSTOR Objects

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

# linstor resource-definition drbd-options --unset-protocol backups

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

# linstor resource-connection drbd-peer-options --unset-max-buffers node-0 node-1 backups

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’:

# linstor resource toggle-disk alpha backups --storage-pool pool_ssd

Remove this disk again:

# linstor resource toggle-disk alpha backups --diskless

3.13.5. ノード間でのディスクの移行

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 resource create bravo backups --drbd-diskless
# linstor resource toggle-disk bravo backups --storage-pool pool_ssd --migrate-from alpha

3.14. Configuring DRBD Proxy Using LINSTOR

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

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

# linstor drbd-proxy enable alpha charlie backups
# linstor drbd-proxy enable bravo charlie backups

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

# linstor drbd-proxy options backups --memlimit 100000000
# linstor drbd-proxy compression zlib backups --level 9

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

# linstor resource-connection drbd-options alpha charlie backups --protocol A
# linstor resource-connection drbd-options bravo charlie backups --protocol A


3.14.1. DRBD プロキシを自動的に有効にする

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.

# linstor node set-property alpha Site A
# linstor node set-property bravo Site A
# linstor node set-property charlie Site B

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:

# linstor controller set-property DrbdProxy/AutoEnable 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:

user = "linstor"
password = "linstor"
connection_url = "jdbc:postgresql://localhost/linstor"

3.14.2. MariaDB and MySQL

A sample MariaDB linstor.toml looks like this:

user = "linstor"
password = "linstor"
connection_url = "jdbc:mariadb://localhost/LINSTOR?createDatabaseIfNotExist=true"
The LINSTOR schema/database is created as LINSTOR so verify that the MariaDB connection string refers to the LINSTOR schema, as in the example above. ==== etcd

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:

## only set user/password if you want to use authentication, only since LINSTOR 1.2.1
# user = "linstor"
# password = "linstor"

## for etcd
## do not set user field if no authentication required
connection_url = "etcd://etcdhost1:2379,etcdhost2:2379,etcdhost3:2379"

## if you want to use TLS, only since LINSTOR 1.2.1
# ca_certificate = "ca.pem"
# client_certificate = "client.pem"

## if you want to use client TLS authentication too, only since LINSTOR 1.2.1
# client_key_pkcs8_pem = "client-key.pkcs8"
## set client_key_password if private key has a password
# client_key_password = "mysecret"

3.15. 複数のLINSTORコントローラー

The LINSTOR Controller has a configuration file that is and has to be placed into the following path: /etc/linstor/linstor.toml. A recent configuration example can be found here: linstor.toml-example ==== LINSTOR REST API

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

  enabled = true
  port = 3370
  listen_addr = ""  # to disable remote access

If you want to use the REST API the current documentation can be found on the following link: ==== LINSTOR REST API HTTPS

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

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

keytool -keyalg rsa -keysize 2048 -genkey -keystore ./keystore_linstor.jks\
 -alias linstor_controller\
 -dname "CN=localhost, OU=SecureUnit, O=ExampleOrg, L=Vienna, ST=Austria, C=AT"

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

  keystore = "/path/to/keystore_linstor.jks"
  keystore_password = "linstor"

Now (re)start the linstor-controller and the HTTPS REST API should be available on port 3371. More information about how to import other certificates can be found here: NOTE: When HTTPS is enabled, all requests to the HTTP /v1/ REST API will be redirected to the HTTPS redirect. ===== LINSTOR REST-API HTTPS 制限付きクライアントアクセス

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

First create a client certificate:

keytool -keyalg rsa -keysize 2048 -genkey -keystore client.jks\
 -storepass linstor -keypass linstor\
 -alias client1\
 -dname "CN=Client Cert, OU=client, O=Example, L=Vienna, ST=Austria, C=AT"

Then we import this certificate to our controller truststore:

keytool -importkeystore\
 -srcstorepass linstor -deststorepass linstor -keypass linstor\
 -srckeystore client.jks -destkeystore trustore_client.jks

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

  keystore = "/path/to/keystore_linstor.jks"
  keystore_password = "linstor"
  truststore = "/path/to/trustore_client.jks"
  truststore_password = "linstor"

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

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

# Convert to pkcs12
keytool -importkeystore -srckeystore client.jks -destkeystore client.p12\
 -storepass linstor -keypass linstor\
 -srcalias client1 -srcstoretype jks -deststoretype pkcs12

# use openssl to convert to PEM
openssl pkcs12 -in client.p12 -out client_with_pass.pem

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

openssl rsa -in client_with_pass.pem -out client1.pem
openssl x509 -in client_with_pass.pem >> client1.pem

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

linstor --certfile client1.pem node list

The --certfile parameter can also added to the client configuration file, see LINSTORクライアントの使用 for more details. === LINSTOR Satellite の設定

The LINSTOR Satellite software has an optional configuration file that uses the TOML file syntax and has to be put into the following path /etc/linstor/linstor_satellite.toml. A recent configuration example can be found here: linstor_satellite.toml-example === ロギング

LINSTOR uses SLF4J with Logback as binding. This gives LINSTOR the possibility to distinguish between the log levels ERROR, WARN, INFO, DEBUG and TRACE (in order of increasing verbosity). In the current linstor version (1.1.2) the user has the following four methods to control the logging level, ordered by priority (first has highest priority):

  1. TRACE mode can be enabled or disabled using the debug console:

    Command ==> SetTrcMode MODE(enabled)
    SetTrcMode           Set TRACE level logging mode
    New TRACE level logging mode: ENABLED
  2. When starting the controller or satellite a command line argument can be passed:

    java ... com.linbit.linstor.core.Controller ... --log-level TRACE
    java ... com.linbit.linstor.core.Satellite  ... --log-level TRACE
  3. The recommended place is the logging section in the configuration file. The default configuration file location is /etc/linstor/linstor.toml for the controller and /etc/linstor/linstor_satellite.toml for the satellite. Configure the logging level as follows:

  4. As LINSTOR is using Logback as an implementation, /usr/share/linstor-server/lib/logback.xml can also be used. Currently only this approach supports different log levels for different components, like shown in the example below:

    <?xml version="1.0" encoding="UTF-8"?>
    <configuration scan="false" scanPeriod="60 seconds">
     Values for scanPeriod can be specified in units of milliseconds, seconds, minutes or hours
     <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
       <!-- encoders are assigned the type
            ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
         <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern>
     <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
       <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
         <Pattern>%d{yyyy_MM_dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</Pattern>
       <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
       <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
     <logger name="LINSTOR/Controller" level="TRACE" additivity="false">
       <appender-ref ref="STDOUT" />
       <!-- <appender-ref ref="FILE" /> -->
     <logger name="LINSTOR/Satellite" level="TRACE" additivity="false">
       <appender-ref ref="STDOUT" />
       <!-- <appender-ref ref="FILE" /> -->
     <root level="WARN">
       <appender-ref ref="STDOUT" />
       <!-- <appender-ref ref="FILE" /> -->

See the Logback Manual to find more details about logback.xml. When none of the configuration methods above is used LINSTOR will default to INFO log level. === 監視

Since LINSTOR 1.8.0, a Prometheus /metrics HTTP path is provided with LINSTOR and JVM specific exports.

The /metrics path also supports three GET arguments to reduce LINSTOR’s reported data:

  • resource

  • storage_pools

  • error_reports

These all default to true. To disable, for example error report data: http://localhost:3370/metrics?error_reports=false

3.15.1. ヘルスチェック

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.

# create directories to hold the key files
mkdir -p /tmp/linstor-ssl
cd /tmp/linstor-ssl
mkdir alpha bravo charlie

# create private keys for all nodes
keytool -keyalg rsa -keysize 2048 -genkey -keystore alpha/keystore.jks\
 -storepass linstor -keypass linstor\
 -alias alpha\
 -dname "CN=Max Mustermann, OU=alpha, O=Example, L=Vienna, ST=Austria, C=AT"

keytool -keyalg rsa -keysize 2048 -genkey -keystore bravo/keystore.jks\
 -storepass linstor -keypass linstor\
 -alias bravo\
 -dname "CN=Max Mustermann, OU=bravo, O=Example, L=Vienna, ST=Austria, C=AT"

keytool -keyalg rsa -keysize 2048 -genkey -keystore charlie/keystore.jks\
 -storepass linstor -keypass linstor\
 -alias charlie\
 -dname "CN=Max Mustermann, OU=charlie, O=Example, L=Vienna, ST=Austria, C=AT"

# import truststore certificates for alpha (needs all satellite certificates)
keytool -importkeystore\
 -srcstorepass linstor -deststorepass linstor -keypass linstor\
 -srckeystore bravo/keystore.jks -destkeystore alpha/certificates.jks

keytool -importkeystore\
 -srcstorepass linstor -deststorepass linstor -keypass linstor\
 -srckeystore charlie/keystore.jks -destkeystore alpha/certificates.jks

# import controller certificate into satellite truststores
keytool -importkeystore\
 -srcstorepass linstor -deststorepass linstor -keypass linstor\
 -srckeystore alpha/keystore.jks -destkeystore bravo/certificates.jks

keytool -importkeystore\
 -srcstorepass linstor -deststorepass linstor -keypass linstor\
 -srckeystore alpha/keystore.jks -destkeystore charlie/certificates.jks

# now copy the keystore files to their host destinations
ssh root@alpha mkdir /etc/linstor/ssl
scp alpha/* root@alpha:/etc/linstor/ssl/
ssh root@bravo mkdir /etc/linstor/ssl
scp bravo/* root@bravo:/etc/linstor/ssl/
ssh root@charlie mkdir /etc/linstor/ssl
scp charlie/* root@charlie:/etc/linstor/ssl/

# generate the satellite ssl config entry
echo '[netcom]
' | ssh root@bravo "cat > /etc/linstor/linstor_satellite.toml"

echo '[netcom]
' | ssh root@charlie "cat > /etc/linstor/linstor_satellite.toml"

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:

  enabled = true (1)

  # allow_public_access: if no authorization fields are given allow
  # users to work with the public context
  allow_public_access = false (2)

  # uniform resource identifier: LDAP URI to use
  # for example, "ldaps://hostname" (LDAPS) or "ldap://hostname" (LDAP)
  uri = "ldaps://"

  # distinguished name: {user} can be used as template for the user name
  dn = "uid={user}" (3)

  # search base for the search_filter field
  search_base = "dc=example,dc=com" (4)

  # search_filter: ldap filter to restrict users on memberships
  search_filter = "(&(uid={user})(memberof=ou=storage-services,dc=example,dc=com))" (5)
1 enabled is a Boolean value. Authentication is disabled by default.
2 allow_public_access is a Boolean value. If set to true, and LDAP authentication is enabled, then users will be allowed to work with the LINSTOR Controller’s public context. If set to false and LDAP authentication is enabled, then users without LDAP authenticating credentials will be unable to access the LINSTOR Controller for all but the most trivial tasks, such as displaying version or help information.
3 dn is a string value where you can specify the LDAP distiguished name to query the LDAP directory. Besides the user ID (uid), the string may consist of other distinguished name attributes, for example:
dn = "uid={user},ou=storage-services,o=ha,dc=example"
4 search_base is a string value where you can specify the starting point in the LDAP directory tree for the authentication query, for example:
search_base = "ou=storage-services"
5 search_filter is a string value where you can specify an LDAP object restriction for authentication, such as user and group membership, for example:
search_filter = "(&(uid={user})(memberof=ou=storage-services,dc=example,dc=com))"
It is highly recommended that you configure LINSTOR REST API HTTPS and LDAPS to protect potentially sensitive traffic passing between the LINSTOR Controller and an LDAP server.

3.15.2. 認証ユーザとしてのLINSTORコマンドの実行

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:

$ linstor --user <LDAP_user_name> <command>

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

$ linstor --allow-insecure-auth --user <LDAP_user_name> <command>

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.

The default policies for DrbdOptions/auto-quorum are quorum majority, and on-no-quorum io-error. For more information about DRBD’s quorum features and their behavior, please refer to the quorum section of the DRBD user’s guide.
The DrbdOptions/auto-quorum policies will override any manually configured properties if DrbdOptions/auto-quorum is not disabled.

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

# linstor resource-group set-property my_ssd_group DrbdOptions/auto-quorum disabled
# linstor resource-group set-property my_ssd_group DrbdOptions/Resource/quorum majority
# linstor resource-group set-property my_ssd_group DrbdOptions/Resource/on-no-quorum suspend-io

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:

# linstor resource-group set-property my_ssd_group DrbdOptions/auto-quorum disabled
# linstor resource-group set-property my_ssd_group DrbdOptions/Resource/quorum off
# linstor resource-group set-property my_ssd_group DrbdOptions/Resource/on-no-quorum
Setting DrbdOptions/Resource/on-no-quorum to an empty value in the commands above deletes the property from the object entirely. ==== 自動取り除き

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.

  • DrbdOptions/AutoEvictMinReplicaCount sets the number of replicas that should always be present. You can set this property on the controller to change a global default, or on a specific resource-definition or resource-group to change it only for that resource-definition or resource-group. If this property is left empty, the place-count set for the auto-placer of the corresponding resource-group will be used.

  • DrbdOptions/AutoEvictAfterTime describes how long a node can be offline in minutes before the eviction is triggered. You can set this property on the controller to change a global default, or on a single node to give it a different behavior. The default value for this property is 60 minutes.

  • DrbdOptions/AutoEvictMaxDisconnectedNodes sets the percentage of nodes that can be not reachable (for whatever reason) at the same time. If more than the given percent of nodes are offline at the same time, the auto-evict will not be triggered for any node , since in this case LINSTOR assumes connection problems from the controller. This property can only be set for the controller, and only accepts a value between 0 and 100. The default value is 34. If you want to turn the auto-evict-feature off, simply set this property to 0. If you want to always trigger the auto-evict, regardless of how many satellites are unreachable, set it to 100.

  • DrbdOptions/AutoEvictAllowEviction is an additional property that can stop a node from being evicted. This can be useful for various cases, for example if you need to shut down a node for maintenance. You can set this property on the controller to change a global default, or on a single node to give it a different behavior. It accepts true and false as values and per default is set to true on the controller. You can use this property to turn the auto-evict feature off by setting it to false on the controller, although this might not work completely if you already set different values for individual nodes, since those values take precedence over the global default.

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

# linstor node restore [nodename]

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 resource-definition set-property myres DrbdOptions/auto-diskful 5
Setting the Auto-Diskful Option on a Resource Group or Controller

You can also set the DrbdOptions/auto-diskful option on LINSTOR controller or resource-group objects. By setting the option at the controller level, the option will affect all LINSTOR resource definitions in your LINSTOR cluster that do not have this option set, either on the resource definition itself, or else on the resource group that you might have created the resource from. Setting the option on a LINSTOR resource group will affect all resource definitions that are spawned from the group, unless a resource definition has the option set on it. The order of priority, from highest to lowest, for the effect of setting the auto-diskful option is: – Resource definition – Resource group – Controller ===== Unsetting the Auto-Diskful Option

To unset the LINSTOR auto-diskful option, enter:

# linstor <controller|resource-definition|resource-group> set-property DrbdOptions/auto-diskful
Setting the Auto-Diskful-Allow-Cleanup Option

A companion option to the LINSTOR auto-diskful option is the DrbdOptions/auto-diskful-allow-cleanup option. You can set this option on the following LINSTOR objects: node, resource, resource definition, or resource group. The default value for this option is True, but the option has no effect unless the auto-diskful option has also been set. After LINSTOR has toggled a resource to Diskful, because the threshold number of minutes has passed where a Diskless node was in the Primary role for a resource, and after DRBD has synchronized the data to this previously Diskless and now Primary node, LINSTOR will remove the resource from any Secondary nodes when that action is necessary to fulfill a replica count constraint that the resource might have. This could be the case, for example, if you have specified a number of replicas for a resource by using the --auto-place option. [s-linstor-qos]] === QoS設定

LINSTOR implements QoS for managed resources by using sysfs properties that correspond to kernel variables related to block I/O operations. These sysfs properties can be limits on either bandwidth (bytes per second), or IOPS, or both. The sysfs files and their corresponding LINSTOR properties are as follows: [cols=”3,2″]

sysfs (/sys/fs/) LINSTOR Property









3.15.3. LINSTOR sysfsのプロパティを使ったQoSの設定

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


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

# linstor resource-group create qos_limited --storage-pool pool1 --place-count 3
# linstor volume-group create qos_limited
# linstor volume-group set-property qos_limited 0 sys/fs/blkio_throttle_write 1048576
# linstor resource-group spawn-resources qos_limited qos_limited_res 200M


# cat /sys/fs/cgroup/blkio/blkio.throttle.write_bps_device
252:4 1048576
QoS プロパティは継承されコピーされないため、 “parent” グループまたは定義から生成された “child” オブジェクトにはプロパティが表示されません。

3.15.4. 複数の DRBD デバイスを持つ LINSTOR ボリュームの QoS 設定

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

3.15.5. NVMe の QoS設定

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

3.16. ヘルプの利用

3.16.1. コマンドラインから確認

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


# linstor node list -h
# linstor help node list

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


# linstor node create alpha 1<tab> # ホスト名が解決できるとIPアドレスを補完します
# linstor resource create b<tab> c<tab> # linstorは backups, charlieリソースを補完します


# source /etc/bash_completion.d/linstor # または
# source /usr/share/bash_completion/completions/linstor

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

# linstor gen-zsh-completer > /usr/share/zsh/functions/Completion/Linux/_linstor

3.16.2. SOS レポート


# linstor sos-report create

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

# linstor sos-report download

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

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

3.16.3. コミュニティの助けを借りる

コミュニティの助けを借りるには にあるメーリングリストを購読してください。

3.16.4. GitHub

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

3.16.5. 有料のサポートと開発

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

4. Kubernetes で LINSTOR ボリューム

この章では、オペレーターによって管理され、 LINSTOR CSI plugin を使用してプロビジョニングされた KubernetesのLINSTORボリュームについて説明します。

この章では、LINSTOR と Kubernetes で可能なすべてのインストールオプションとさまざまな構成について詳しく説明します。テスト目的で「クイックスタート」に興味がある方、または参照用の例を探している方は、この章の終わり近くの Helm インストール例 を参照ください。

4.1. Kubernetesの概要

Kubernetes_は、コンテナオーケストレーターです。Kubernetes は、宣言した仕様に基づいてコンテナと関連サービスの動作を定義します。このガイドでは、Kubernetes オブジェクトの仕様を定義する AML ファイルを介して kubectl を使用することに焦点を当てます。

4.2. Kubernetes への LINSTOR のデプロイ

LINBITは、商用サポートのお客様向けにLINSTOR Operatorを提供しています。 Operatorは、DRBDのインストール、SatelliteとControllerポッドの管理など、Kubernetes上でのLINSTORの導入を容易にするものです。

LINBIT’s container image repository (, used by LINSTOR Operator, is only available to LINBIT customers or through LINBIT customer trial accounts. Contact LINBIT for information on pricing or to begin a trial. Alternatively, you may use LINSTOR SDS’ upstream project named Piraeus, without being a LINBIT customer.

LINSTOR Operator v2 is the recommended way of deploying LINBIT SDS for Kubernetes on new clusters. Users of existing Operator v1 deployments should continue to use their Helm deployments, skipping to the Operator v1 instructions.

4.2.1. Deploying LINSTOR Operator v2

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

Prerequisites for LINSTOR Operator v2

To deploy LINSTOR Operator v2, you need to meet the following prerequisites:

Creating the Operator

To deploy the Operator, create a kustomization.yaml file. This will declare your pull secret for and allow you to pull in the Operator deployment. The Operator will be deployed in a new namespace linbit-sds. Make sure to replace MY_LINBIT_USER and MY_LINBIT_PASSWORD with your own credentials. You can find the latest releases on

Listing 2. kustomization.yaml
kind: Kustomization
namespace: linbit-sds
  - (1)
  disableNameSuffixHash: true
  - name: drbdio-pull-secret
      - .dockerconfigjson={"auths":{"":{"username":"MY_LINBIT_USER","password":"MY_LINBIT_PASSWORD"}}} (2)
1 Replace with the latest release manifest from
2 Replace MY_LINBIT_USER and MY_LINBIT_PASSWORD with your credentials.

Then, apply the kustomization.yaml file, by using kubectl command, and wait for the Operator to start:

$ kubectl apply -k .
namespace/linbit-sds created
$ kubectl -n linbit-sds  wait pod --for=condition=Ready --all
pod/linstor-operator-controller-manager-6d9847d857-zc985 condition met

The Operator is now ready to deploy LINBIT SDS for Kubernetes.

Deploying LINBIT SDS for Kubernetes

Deploying LINBIT SDS for Kubernetes with the Operator is as simple as creating a new LinstorCluster resource and waiting for the Operator to complete the setup:

$ kubectl create -f - <<EOF
kind: LinstorCluster
  name: linstorcluster
spec: {}
$ kubectl wait pod --for=condition=Ready -n linbit-sds --timeout=3m --all
pod/ha-controller-4tgcg condition met
pod/k8s-1-26-10.test condition met
pod/linstor-controller-76459dc6b6-tst8p condition met
pod/linstor-csi-controller-75dfdc967d-dwdx6 condition met
pod/linstor-csi-node-9gcwj condition met
pod/linstor-operator-controller-manager-6d9847d857-zc985 condition met

By default, LINBIT SDS for Kubernetes does not configure any storage. To add storage, you can configure a LinstorSatelliteConfiguration, which the Operator uses to configure one or more satellites.

The following example creates a simple FILE_THIN pool and it does not require any additional set up on the host:

$ kubectl apply -f - <<EOF
kind: LinstorSatelliteConfiguration
  name: storage-pool
    - name: pool1
        directory: /var/lib/linbit-sds/pool1

Other types of storage pools can be configured as well. Please check the examples upstream.

Next Steps

After deploying LINBIT SDS for Kubernetes, you can continue with the guide for creating basic volumes, or refer to the available tutorials and how-to guides upstream.

4.2.2. Deploying LINSTOR Operator v1

If you plan to deploy LINSTOR Operator on a new cluster, you should use Operator v2.

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

  • 認証情報を含む kubernetes シークレットを作成します。

    kubectl create secret docker-registry drbdiocred \
      --docker-username=<YOUR_LOGIN> --docker-email=<YOUR_EMAIL> --docker-password=<YOUR_PASSWORD>

    このシークレットの名前は、Helm で指定されたものと一致する必要があります。デフォルトは drbdiocred です。

  • LINSTORデータベースのバックエンドを設定します。デフォルトでは、チャートはデータベースとしてetcdを設定します。Operator は、LINSTORが Kubernetes as datastore を直接使用するように設定することも可能です。etcd を使う場合は、etcd 用に永続的ストレージを設定します。

    • デフォルトの StorageClass で既存のストレージプロビジョナーを使用する。

    • hostPath ボリューム を使用する。

    • 基本的なテストのみで永続化を無効にします。これは以下の helm install コマンドに --set etcd.persistentVolume.enabled=false を追加することで実行できます。

  • ストレージの構成 を確認し、LINSTOR の基本的なストレージを構成してください。

  • デプロイメントの保護に関するセクション を参照して、必要に応じて設定します。

  • 最後のステップとして helm install コマンドで --set を使用して、適切なカーネルモジュールインジェクタを選択します。

    • 使用しているディストリビューションに応じてインジェクターを選択してください。 から、 drbd9-rhel7, drbd9-rhel8, …​ 等の最新バージョンを適宜選択します。drbd9-rhel8 イメージは、RHCOS(OpenShift) でも使用します。SUSE CaaS プラットフォームの場合、使用している CaaS プラットフォームのシステムと一致する SLES インジェクターを使用します( drbd9-sles15sp1 など)。例えば以下のようにします。
    • ホストマシンに既に存在するモジュールのみを挿入します。モジュールが見つからない場合は、スキップされます。

    • 他の方法で DRBD をインストールする場合は、カーネルモジュールインジェクションを無効にします。 DepsOnly により非推奨になりました。

  • 最後にすべてをセットアップする linstor-op という名前の Helm デプロイメントを作成します。

    helm repo add linstor
    helm install linstor-op linstor/linstor

    詳細なデプロイメントのカスタマイズについては、advanced deployment section を参照ください。


Controllerは、Kubernetes APIを直接使用して、クラスタの状態を永続化することができます。このバックエンドを有効にするには、チャートのインストール時に以下のオーバーライドファイルを使用します。

Listing 3. k8s-backend.yaml
  enabled: false
    dbConnectionURL: k8s
現在、etcd バックエンドを持つ既存のクラスタから Kubernetes バックエンドへの移行できません。

pv-hostpath Helm テンプレートを使用して、 hostPath 永続ボリュームを作成できます。構成された etcd の replicas を満たすために必要な数の PV を作成します(デフォルト1)。

nodePath = オプションでクラスターノード名を指定して hostPath 永続ボリュームを作成します。

helm repo add linstor
helm install linstor-etcd linstor/pv-hostpath

デフォルトで PV はすべての control-plane ノードに作成されます。インストールコマンドに --set "nodes={<NODE0>,<NODE1>,NODE2>}" を渡すことにより、ストレージノードを手動で選択できます。

ノードを参照するための正しい値は、 ラベルの値です。 kubectl get nodes -o custom-columns="Name:{},NodeName:{.metadata.labels['kubernetes\.io/hostname']}" を実行すると、全てのノードについてその値を一覧表示することができます。

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

POSTGRES_DB: postgresdb
POSTGRES_USER: postgresadmin

Helm のインストールコマンドに以下を追加することにより、etcd クラスターをデプロイする代わりにこのデータベースを使用するように Helm チャートを構成できます。

--set etcd.enabled=false --set "operator.controller.dbConnectionURL=jdbc:postgresql://postgres/postgresdb?user=postgresadmin&password=admin123"

4.2.3. ストレージの構成



LINSTOR オペレーターを使用して、LINSTOR ストレージプールを作成できます。作成は LinstorSatelliteSet リソースの制御下にあります。

$ kubectl get linstor-op-ns -o yaml
kind: LinstorSatelliteSet
    - name: lvm-thick
      volumeGroup: drbdpool
    - name: lvm-thin
      thinVolume: thinpool
      volumeGroup: ""
    - name: my-linstor-zpool
      zPool: for-linstor
      thin: true

インストール時の helm install を実行するときに operator.satelliteSet.storagePools の値を設定します。


      - name: lvm-thick
        volumeGroup: drbdpool

このファイルは、次のように helm インストールに渡すことができます。

helm install -f <file> linstor-op linstor/linstor

オペレーターがすでに構成されているクラスター(つまり、 helm install の後)では、次のようにして LinstorSatelliteSet 構成を編集できます。

$ kubectl edit <satellitesetname>



デフォルトでは、LINSTOR は、参照される VolumeGroups, ThinPools などが存在することを想定しています。 devicePaths:[] オプションを使用して、LINSTOR がプール用にデバイスを自動的に準備できるようにすることができます。自動構成の対象となるのは、次のようなブロックデバイスです。

  • ルートデバイス(パーティションなし)

  • パーティション情報を含まない。

  • 1 GiB 以上である。

デバイスの自動構成を有効にするには storagePools エントリに devicePaths キーを設定します。

    - name: lvm-thick
      volumeGroup: drbdpool
      - /dev/vdb
    - name: lvm-thin
      thinVolume: thinpool
      volumeGroup: linstor_thinpool
      - /dev/vdc
      - /dev/vdd

現在、このメソッドは LVM および LVMTHIN ストレージプールの作成をサポートしています。

LVM ストレージプールの設定

lvmPools エントリで利用可能なキーは以下のとおりです。

  • name LINSTOR ストレージプールの名前。必須

  • volumeGroup 作成する VG の名前。必須

  • devicePaths このプール用に構成するデバイス。認識されるには、空で 1GiB 以上ある。オプション

  • raidLevel LVM RAID レベル。オプション

  • vdo [VDO]を有効にする(サテライトに VDO ツールが必要)。オプション

  • vdoLogicalSizeKib 作成された VG のサイズ(VDO を使用することで下位デバイスよりも大きくなることが予想される)。オプション

  • vdoSlabSizeKib VDO のスラブサイズ。オプション

LVM Thin Poolの設定
  • name LINSTOR ストレージプールの名前。必須

  • volumeGroup シンプールに使用するVGです。 devicePaths を使用したい場合は、これを "" に設定します。 LINSTORではデバイスを準備する際にVG名を設定することができないため、これは必須です。 thinVolume シンプールの名前です。[必須]です。

  • devicePaths このプール用に構成するデバイス。認識されるには、空で 1GiB 以上ある。オプション

  • raidLevel LVM RAID レベル。オプション

LVMTHIN プール用に LINSTOR によって作成されたボリュームグループは、常にスキーム “linstor_$THINPOOL” に従います。
ZFS ストレージプールの設定
  • name LINSTOR ストレージプールの名前。必須

  • zPool 使用する zpool の名前。すべてのマシンにすでに存在している必要があります。必須

  • thin シンプロビジョニングを使用するには true, 使用しないなら false を設定する。必須

automaticStorageType の使用(非推奨)

すべての適切なデバイスは、すでに storagePools セクションを使用して準備している場合を除き operator.satelliteSet.automaticStorageType の値に従って準備されます。デバイスは、デバイス名に基づいてストレージプールに追加さ>れます(つまり、すべての /dev/nvme1 デバイスはプール autopool-nvme1 一部>になります)。

operator.satelliteSet.automaticStorageType の可能な値は次のとおりです。

  • None 自動セットアップなし(デフォルト)

  • LVM LVM(シック)ストレージプールを作成

  • LVMTHIN LVM thin ストレージプールを作成

  • ZFS ZFS ベースストレージプールを作成 ( 未テスト )

4.2.4. 安全なデプロイメント

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

既存の etcd インスタンスとの安全な通信

etcd インスタンスへの安全な通信は、kubernetes シークレットの形式で CA 証明書をオペレーターに提供することで有効にできます。シークレットには、PEM エンコードされた CA 証明書を値として持つキー ca.pem を含める必要があります。

次の引数を helm install に渡すことで、シークレットをコントローラーに渡すことができます。

--set operator.controller.dbCertSecret=<secret name>
証明書を使用した etcd での認証

TLS 証明書を使用して etcd データベースで認証する場合は、helm インストールで次のオプションを設定します。

--set operator.controller.dbUseClientCert=true


  • client.cert 認証のために etcd に提示される PEM 形式の証明書

  • client.key 上記のクライアント証明書と一致する PKCS8 形式の秘密鍵

鍵は openssl を使用して PKCS8 形式に変換できます。

openssl pkcs8 -topk8 -nocrypt -in client-key.pem -out client-key.pkcs8
LINSTOR コンポーネント間の安全な通信の設定

LINSTOR コンポーネント間のデフォルトの通信は TLS によって保護されていません。必要な場合は、次の手順に従い設定します。


cert-manager がクラスタにインストールされていることが必要です。


linstorSslMethod: cert-manager
linstorHttpsMethod: cert-manager
Generate Keys and Certificates Using Helm


linstorSslMethod: helm
linstorHttpsMethod: helm


openssl req -new -newkey rsa:2048 -days 5000 -nodes -x509 -keyout ca.key \
  -out ca.crt -subj "/CN=linstor-system"
openssl req -new -newkey rsa:2048 -days 5000 -nodes -x509 -keyout client-ca.key \
  -out client-ca.crt -subj "/CN=linstor-client-ca"


openssl genrsa -out linstor-control.key 2048
openssl genrsa -out linstor-satellite.key 2048
openssl genrsa -out linstor-client.key 2048
openssl genrsa -out linstor-api.key 2048


openssl req -new -sha256 -key linstor-control.key -subj "/CN=system:control" \
  -out linstor-control.csr
openssl req -new -sha256 -key linstor-satellite.key -subj "/CN=system:node" \
  -out linstor-satellite.csr
openssl req -new -sha256 -key linstor-client.key -subj "/CN=linstor-client" \
  -out linstor-client.csr
openssl req -new -sha256 -key linstor-api.key -subj "/CN=linstor-controller" \
  -out  linstor-api.csr
openssl x509 -req -in linstor-control.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out linstor-control.crt -days 5000 -sha256
openssl x509 -req -in linstor-satellite.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out linstor-satellite.crt -days 5000 -sha256
openssl x509 -req -in linstor-client.csr -CA client-ca.crt -CAkey client-ca.key \
  -CAcreateserial -out linstor-client.crt -days 5000 -sha256
openssl x509 -req -in linstor-api.csr -CA client-ca.crt -CAkey client-ca.key \
  -CAcreateserial -out linstor-api.crt -days 5000 -sha256 -extensions 'v3_req' \
  -extfile <(printf '%s\n' '[v3_req]' extendedKeyUsage=serverAuth \
最後のコマンドの linstor-op-cs.default.svc は create service 名と一致させる必要があります。Helm では、これは常に <release-name>-cs.<namespace>.svc になります。

コントローラとノードポッドに渡すことができるkubernetes シークレットを作成します。

kubectl create secret generic linstor-control \
  --from-file=ca.crt=ca.crt --from-file=tls.crt=linstor-control.crt \
kubectl create secret generic linstor-satellite \
  --from-file=ca.crt=ca.crt --from-file=tls.crt=linstor-satellite.crt \
kubectl create secret generic linstor-api \
  --from-file=ca.crt=client-ca.crt --from-file=tls.crt=linstor-api.crt \
kubectl create secret generic linstor-client \
  --from-file=ca.crt=client-ca.crt --from-file=tls.crt=linstor-client.crt \

作成したシークレットの名前を helm install に渡します。

linstorHttpsControllerSecret: linstor-api
linstorHttpsClientSecret: linstor-client
    sslSecret: linstor-control
    sslSecret: linstor-satellite
LINSTOR のパスフレーズを自動設定

LINSTOR は、暗号化された情報をサポートするために機密データを保存する必要があります。このデータはマスターパスフレーズによって保護されています。パスフレーズは、最初のチャートインストール時に自動的に生成されます。


kubectl create secret generic linstor-pass --from-literal=MASTER_PASSPHRASE=<password>

インストール時に、次の引数を helm コマンドに追加します。

--set operator.controller.luksSecret=linstor-pass
Helm インストール例

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

      - name: lvm-thin
        thinVolume: thinpool
        volumeGroup: ""
        - /dev/sdb

デフォルトのインストールです。これにより etcd KeyValue ストアの設定はされないことに注意してください。

kubectl create secret docker-registry drbdiocred \
  --docker-username=<YOUR_LOGIN> --docker-password=<YOUR_PASSWORD>
helm repo add linstor
helm install linstor-op linstor/linstor
これ以降 kubectl create コマンドで使用される LINBIT のコンテナーイメージリポジトリ ( は、LINBIT のお客様または LINBIT のお客様の試用アカウントを通じてのみ利用できます。価格についての情報や試用開始するには こちら を参照ください。また、LINSTOR SDS のアップストリームプロジェクト Piraeus は LINBIT の顧客ではなくてもを使用できます。

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

これは、ほとんどの基本的なデプロイメントに適しています。このデプロイメントでは、コマンドの移植性を高めるために、コンパイル済みの DRBD カーネルモジュールを使用していないことに注意してください。コンパイル済みのバイナリを使用すると、インストールとデプロイメントは速くなります。大規模な Kubernetes クラスターでの使用には、 Compile オプションの使用は推奨されません。

kubectl create secret docker-registry drbdiocred \
  --docker-username=<YOUR_LOGIN> --docker-password=<YOUR_PASSWORD>
helm repo add linstor
helm install linstor-etcd linstor/pv-hostpath --set "nodes={<NODE0>,<NODE1>,<NODE2>}"
helm install -f sp-values.yaml linstor-op linstor/linstor --set etcd.replicas=3 \
  --set operator.satelliteSet.kernelModuleInjectionMode=Compile

sp-values.yaml で定義された LINSTOR storage-pools, etcd の代わりに作成済みの Postgres DB(できればクラスター化), DRBD 用にコンパイル済みのカーネルモジュールを使用してインストールします。

この例の Postgres データベースは postgres という名前のサービスエンドポイントでアクセスできます。Postgres 自体は POSTGRES_DB = postgresdb, POSTGRES_USER = postgresadmin, および POSTGRES_PASSWORD = admin123 で構成されます。

kubectl create secret docker-registry drbdiocred \
  --docker-username=<YOUR_LOGIN> --docker-email=<YOUR_EMAIL> --docker-password=<YOUR_PASSWORD>
helm repo add linstor
helm install -f sp-values.yaml linstor-op linstor/linstor --set etcd.enabled=false \
  --set "operator.controller.dbConnectionURL=jdbc:postgresql://postgres/postgresdb?user=postgresadmin&password=admin123"
Helm デプロイメントの終了

重要なコンポーネントを誤って削除しないようにクラスターのストレージインフラストラクチャを保護するには、Helm デプロイメントを削除する前にいくつかの手動手順を実行します。

  1. LINSTOR コンポーネントによって管理されているすべてのボリューム要求を削除します。次のコマンドを使用して、LINSTOR が管理するボリューム要求のリストを取得できます。リストされたどのボリュームにも必要なデータが残っていないことを確認した後、生成された kubectl delete コマンドを使用してそれらを削除できます。

    $ kubectl get pvc --all-namespaces -o=jsonpath='{range .items[?(@.metadata.annotations.volume\.beta\.kubernetes\.io/storage-provisioner=="")]}kubectl delete pvc --namespace {.metadata.namespace} {}{"\n"}{end}'
    kubectl delete pvc --namespace default data-mysql-0
    kubectl delete pvc --namespace default data-mysql-1
    kubectl delete pvc --namespace default data-mysql-2
  2. LINSTOR コントローラーとサテライトリソースを削除します。

    LINSTOR サテライトとコントローラーのデプロイメントは、LinstorSatelliteSet リソースと LinstorController リソースによって制御されます。kubectl を使用して、デプロイメントに関連付けられているリソースを削除できます。

    kubectl delete linstorcontroller <helm-deploy-name>-cs
    kubectl delete linstorsatelliteset <helm-deploy-name>-ns


  3. Helm デプロイメントの終了

    すべての PVC を削除し、すべての LINSTOR ポッドが終了した場合、helm デプロイメントをアンインストールできます。

    helm uninstall linstor-op
    Helm の現在のポリシーにより、LinstorController および LinstorSatelliteSet という名前のカスタムリソース定義はコマンドによって削除されません。 CRD の Helm の現状に関しては こちら を参照ください。

4.2.5. 高度なデプロイメントオプション

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

以下の Helm チャートで使用される LINBIT のコンテナーイメージリポジトリ ( は、LINBIT のお客様または LINBIT のお客様の試用アカウントを通じてのみ利用できます。価格についての情報や試用開始するには こちら を参照ください。また、LINSTOR SDS のアップストリームプロジェクト Piraeus は LINBIT の顧客ではなくてもを使用できます。
  imagePullPolicy: IfNotPresent # empty pull policy means k8s default is used ("always" if tag == ":latest", "ifnotpresent" else) (1)
  setSecurityContext: true # Force non-privileged containers to run as non-root users
# Dependency charts
  enabled: true
    enabled: true
    storage: 1Gi
  replicas: 1 # How many instances of etcd will be added to the initial cluster. (2)
  resources: {} # resource requirements for etcd containers (3)
    tag: v3.4.15
  enabled: false
  schedulerTag: ""
  replicas: 1 (2)
  storkResources: {} # resources requirements for the stork plug-in containers (3)
  schedulerResources: {} # resource requirements for the kube-scheduler containers (3)
  podsecuritycontext: {}
  enabled: true
  pluginImage: ""
  csiAttacherWorkerThreads: 10 (9)
  csiProvisionerWorkerThreads: 10 (9)
  csiSnapshotterWorkerThreads: 10 (9)
  csiResizerWorkerThreads: 10 (9)
  controllerReplicas: 1 (2)
  nodeAffinity: {} (4)
  nodeTolerations: [] (4)
  controllerAffinity: {} (4)
  controllerTolerations: [] (4)
  enableTopology: true
  resources: {} (3)
  customLabels: {}
  customAnnotations: {}
  kubeletPath: /var/lib/kubelet (7)
  controllerSidecars: []
  controllerExtraVolumes: []
  nodeSidecars: []
  nodeExtraVolumes: []
priorityClassName: ""
drbdRepoCred: drbdiocred
linstorSslMethod: "manual" # <- If set to 'helm' or 'cert-manager' the certificates will be generated automatically
linstorHttpsMethod: "manual" # <- If set to 'helm' or 'cert-manager' the certificates will be generated automatically
linstorHttpsControllerSecret: "" # <- name of secret containing linstor server certificates+key. See docs/
linstorHttpsClientSecret: "" # <- name of secret containing linstor client certificates+key. See docs/
controllerEndpoint: "" # <- override to the generated controller endpoint. use if controller is not deployed via operator
  privilegedRole: ""
  unprivilegedRole: ""
  replicas: 1 # <- number of replicas for the operator deployment (2)
  image: ""
  affinity: {} (4)
  tolerations: [] (4)
  resources: {} (3)
  customLabels: {}
  customAnnotations: {}
  podsecuritycontext: {}
    createBackups: true
    createMonitoring: true
  sidecars: []
  extraVolumes: []
    enabled: true
    controllerImage: ""
    dbConnectionURL: ""
    luksSecret: ""
    dbCertSecret: ""
    dbUseClientCert: false
    sslSecret: ""
    affinity: {} (4)
    httpBindAddress: ""
    httpsBindAddress: ""
    tolerations: (4)
      - key:
        operator: Exists
        effect: NoSchedule
      - key:
        operator: Exists
        effect: NoSchedule
    resources: {} (3)
    replicas: 1 (2)
    additionalEnv: [] (5)
    additionalProperties: {} (6)
    sidecars: []
    extraVolumes: []
    customLabels: {}
    customAnnotations: {}
    enabled: true
    satelliteImage: ""
    storagePools: {}
    sslSecret: ""
    automaticStorageType: None
    affinity: {} (4)
    tolerations: [] (4)
    resources: {} (3)
    monitoringImage: ""
    monitoringBindAddress: ""
    kernelModuleInjectionImage: ""
    kernelModuleInjectionMode: ShippedModules
    kernelModuleInjectionAdditionalSourceDirectory: "" (8)
    kernelModuleInjectionResources: {} (3)
    kernelModuleInjectionExtraVolumeMounts: []
    additionalEnv: [] (5)
    sidecars: []
    extraVolumes: []
    customLabels: {}
    customAnnotations: {}
  enabled: false
  affinity: {} (4)
  tolerations: [] (4)
  resources: {} (3)
  replicas: 1 (2)
  customLabels: {}
  customAnnotations: {}
1 すべてのイメージのプルポリシーを設定します。
2 各コンポーネントのレプリカ数を制御します。
3 コンテナリソースのリクエストと制限を設定します。詳細は kubernetes ドキュメント を参照ください。 以下を除いて、ほとんどのコンテナは、最小限のリソースしか必要としません。
  • etcd.resources etcd docs を参照

  • operator.controller.resources700MiB のメモリが必要

  • operater.satelliteSet.resources700MiB のメモリが必要 operator.satelliteSet.kernelModuleInjectionResources カーネルモジュールをコンパイルする場合、1GiBのメモリが必要

4 AffinityとTolerationは、クラスタ上のどこにポッドがスケジュールされるかを決定します。詳細は kubernetes docs on affinity and toleration を参照ください。これは operator.satelliteSetcsi.node* の値に対して特に重要かもしれません。LINSTOR 永続ボリュームを使用してポッドをスケジュールするには、そのノードで実行中の LINSTOR satellite と LINSTOR CSI ポッドが必要です。
5 コントローラとサテライトポッドに渡す kubernetes シークレットを作成します。Linstor コントローラーとサテライトに渡す追加の環境変数を設定します。 コンテナ環境変数 と同じフォーマットを使用します。
6 Linstor コントローラーに追加のプロパティを設定します。単純な <property-key>: <value> マッピングを使用します。
7 Kubelet は、すべての CSI プラグインが独自の状態ディレクトリの特定のサブディレクトリにボリュームをマウントすることを想定しています。デフォルトでは、この状態ディレクトリは /var/lib/kubelet です。一部の Kubernetes ディストリビューションは異なるディレクトリを使用します。
  • microk8s: /var/snap/microk8s/common/var/lib/kubelet

8 カーネルモジュールのビルドに必要な、ホスト上のディレクトリ。Compile` インジェクションメソッドを使用する場合のみ必要です。デフォルトは /usr/src で、ほとんどのディストリビューションで実際のカーネルソースがここに格納されています。追加のディレクトリをマウントしない場合は、 "none" を使用します。
9 CSIドライバによって使用されるワーカスレッドの数を設定します。より高い値はLINSTORコントローラに多くの負荷を与え、一度に多くのボリュームを作成する際に不安定になる可能性があります。
10 true に設定すると、サテライトコンテナーには、ホスト OS からマウントされた次のファイルとディレクトリが含まれます。
  • /etc/drbd/drbd.conf (ファイル)

  • /etc/drbd.d (ディレクトリ)

  • /var/lib/drbd (ディレクトリ)

  • /var/lib/linstor.d (ディレクトリ)



すべてのコンポーネントの高可用性デプロイメントを作成するには アップストリームガイド を参照してください。デフォルト値は、複数のレプリカのコンポーネントが異なるノードに配置されるようにスケーリングが行われるように選択されています。これにより、単一ノードの障害によってサービスが中断されることはありません。

4.2.6. Prometheus による監視

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

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

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

LINSTOR コントローラー監視

Linstor コントローラーは、クラスター全体のメトリックをエクスポートします。メトリックは、パス /metrics を使用して、既存のコントローラーサービスにエクスポートされます。

DRBD リソース監視

すべてのサテライトは drbd-reactor を使用して DRBD から直接メトリックをエクスポートするセカンダリコンテナにバンドルされています。メトリックはポート 9942 で、ヘッドレスサービス <linstorsatelliteset-name>-monitoring という名前で提供されています。

監視コンテナを無効にする場合は、LinstorSatelliteSet リソースで monitoringImage"" に設定します。

4.2.7. LINSTORオペレーターを使用したデプロイ

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

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

  • operator.controller.enabled=false これにより LinstorController リソースを作成しなくなります。

  • operator.etcd.enabled=false Kubernetes では LINSTOR コントローラーが実行されないため、データベースは必要ありません。

  • controllerEndpoint=<url-of-linstor-controller> 既存の LINSTOR コントローラーの HTTP エンドポイント。 例えば

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

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


kind: StorageClass
  name: linstor-on-k8s
  autoPlace: "3"
  storagePool: existing-storage-pool
  resourceGroup: linstor-on-k8s

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

4.2.8. Piraeus オペレーターを使用したデプロイメント

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

4.3. Kubernetes で LINSTOR の操作

コントローラポッドには LINSTOR クライアントが含まれているため、LINSTOR と直接やり取りするのは簡単です。例えば:

kubectl exec deployment/linstor-op-cs-controller -- linstor storage-pool list

上記のコマンドへの便利なショートカットを使用する場合、 kubectl-linstor をダウンロードし kubectl と一緒にインストールしてください。 kubectl linstor を使用して Linstor CLI にアクセスできます。

$ kubectl linstor node list
┊ Node                           ┊ NodeType   ┊ Addresses                   ┊ State  ┊
┊ kube-node-01.test              ┊ SATELLITE  ┊ (PLAIN)   ┊ Online ┊
┊ kube-node-02.test              ┊ SATELLITE  ┊ (PLAIN)   ┊ Online ┊
┊ kube-node-03.test              ┊ SATELLITE  ┊ (PLAIN)   ┊ Online ┊
┊ linstor-op-cs-controller-[...] ┊ CONTROLLER ┊ (PLAIN) ┊ Online ┊

また参照を Linstor リソースにマッチする PVC に展開します。

$ kubectl linstor resource list -r pvc:my-namespace/demo-pvc-1 --all
pvc:my-namespace/demo-pvc-1 -> pvc-2f982fb4-bc05-4ee5-b15b-688b696c8526
┊ ResourceName ┊ Node              ┊ Port ┊ Usage  ┊ Conns ┊    State   ┊ CreatedOn           ┊
┊ pvc-[...]    ┊ kube-node-01.test ┊ 7000 ┊ Unused ┊ Ok    ┊   UpToDate ┊ 2021-02-05 09:16:09 ┊
┊ pvc-[...]    ┊ kube-node-02.test ┊ 7000 ┊ Unused ┊ Ok    ┊ TieBreaker ┊ 2021-02-05 09:16:08 ┊
┊ pvc-[...]    ┊ kube-node-03.test ┊ 7000 ┊ InUse  ┊ Ok    ┊   UpToDate ┊ 2021-02-05 09:16:09 ┊

また pod:[<namespace>/]<podname> 形式の参照をポッドで使用中のリソースリストへ展開します。

This should only be necessary for investigating problems and accessing advanced functionality. Regular operation such as creating volumes should be achieved through the Kubernetes integration.

4.4. 基本的な構成とデプロイメント

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

Kubernetes を介してデプロイされた LINSTOR ボリュームの動作とプロパティの構成は StorageClasses を使用して行います。

“resourceGroup” パラメータは必須です。通常、一意にしてストレージクラス名と同じにします。

以下は、ボリュームのデプロイに使用できる最も単純で実用的な StorageClass です。

Listing 4. linstor-basic-sc.yaml
kind: StorageClass
  # The name used to identify this StorageClass.
  name: linstor-basic-storage-class
  # The name used to match this StorageClass with a provisioner.
  # is the name that the LINSTOR CSI plug-in uses to identify itself
volumeBindingMode: WaitForFirstConsumer
  # LINSTOR will provision volumes from the drbdpool storage pool configured
  # On the satellite nodes in the LINSTOR cluster specified in the plug-in's deployment
  storagePool: "lvm-thin"
  resourceGroup: "linstor-basic-storage-class"
  # Setting a fstype is required for "fsGroup" permissions to work correctly.
  # Currently supported: xfs/ext4 xfs
上記の YAML 構成ファイルの例の storagePool の値 lvm-thin は利用可能な LINSTOR StoragePool と一致する必要があります。実行中の linstor-op-cs-controller ポッド内で実行される linstorstorage-pool list コマンドを使用して、ストレージプール情報を一覧表示できます。

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

kubectl create -f linstor-basic-sc.yaml

StorageClass が作成されたので、KubernetesとLINSTOR の両方に認識されるボリュームをプロビジョニングするために使用できる PersistentVolumeClaim を作成できます。

Listing 5. my-first-linstor-volume-pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
  name: my-first-linstor-volume
  storageClassName: linstor-basic-storage-class
    - ReadWriteOnce
      storage: 500Mi

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

kubectl create -f my-first-linstor-volume-pvc.yaml

これにより PersistentVolumeClaim が作成されますが、ボリュームはまだ作成されません。使用したストレージクラスは volumeBindingMode: WaitForFirstConsumer を指定しました。これは、ワークロードがボリュームの使用を開始したときにのみボリュームが作成されることを意味します。これにより、ボリュームがワークロードと同じノードに配置されます。

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

apiVersion: v1
kind: Pod
  name: fedora
  namespace: default
  - name: fedora
    image: fedora
    command: [/bin/bash]
    args: ["-c", "while true; do sleep 10; done"]
    - name: my-first-linstor-volume
      mountPath: /data
    - containerPort: 80
  - name: my-first-linstor-volume
      claimName: "my-first-linstor-volume"

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

kubectl create -f my-first-linstor-volume-pod.yaml

kubectl describe pod fedora を実行すると、 Pod スケジューリングとボリューム接続が成功したことを確認できます。 PersistentVolumeClaim を見ると、ボリュームにバインドされていることがわかります。

ボリュームを削除するにはpodがもう使われていないことを確認してから kubectl を使ってPersistentVolumeClaimを削除します。例えば、先ほど作成したボリュームを削除するには、以下のコマンドを実行します。ボリュームが削除される前にpodのスケジュールを解除します。

kubectl delete pod fedora # podをアンスケジュール。

kubectl get pod -w # podがアンスケジュールされるまで待つ

kubectl delete pvc my-first-linstor-volume # PersistentVolumeClaim、PersistentVolume、Linstorボリュームを削除する。

4.4.1. StorageClass で使用可能なパラメータ

次のストレージクラスには、プロビジョニングされたストレージを構成するために現在使用可能なすべてのパラメーターが含まれています。 はオプションですが、LINSTOR CSI 固有のパラメーターのプレフィックスとして推奨されます。
kind: StorageClass
  name: full-example
  # CSI related parameters xfs
  # LINSTOR parameters "2" "2" "full-example" "my-storage-pool" "DfltDisklessStorPool" "drbd storage" "AutoPlaceTopology" "true" "true" "diskful-a diskful-b" "diskless-a diskless-b" "zone=a" "rack" "false" "tainted.*" "-E nodiscard" "noatime" "extsize 2m"
  # Linstor properties*: <x>
  # DRBD parameters
  DrbdOptions/*: <x>

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

  • ext4 (デフォルト)

  • xfs

4.4.3. autoPlace

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

このオプションを使用する場合は、 nodeList を使用しないでください。
引用符を使用する必要があります。そうしないと、Kubernetes は不正な形式の StorageClass について文句を言います。
このオプション(および自動配置の動作に影響を与えるすべてのオプション)は、ボリューム用のストレージがプロビジョニングされるLINSTORノードの数を変更し、 kubelets からこれらのボリュームにアクセスできるようにします。

4.4.4. placementCount

placementCountautoPlace のエイリアスです。

4.4.5. resourceGroup

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

4.4.6. storagePool

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

これと同じ storage pool で構成されたノードのみが autoplacement に使用されます。同様に nodeList を使う StorageClasses ではそのリストで指定されたすべてのノードが storage pool を構成している必要があります。

4.4.7. disklessStoragePool

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

4.4.8. layerList

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

4.4.9. placementPolicy

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

  • AutoPlaceTopology (デフォルト): ユーザー提供の制約とともに、Kubernetesからのトポロジ情報を使用する(詳細は see replicasOnSamereplicasOnDifferent を参照)。

  • AutoPlace : LINSTOR autoplace を使う。 replicasOnSamereplicasOnDifferent の影響をうける。

  • FollowTopology: CSI トポロジ情報を使用して、各 “preferred” ゾーンに少なくとも 1 つのボリュームを配置します。CSI トポロジが有効になっている場合にのみ使用できます。

  • Manual: nodeListclientList にリストされているノードのみを使用する。

  • Balanced: 実験的 選択した各ノードで最も使用されていないストレージプールを使用して、障害のあるドメイン全体にボリュームを配置する。

4.4.10. allowRemoteVolumeAccess

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

  • "true" または "false" は、すべてのノードからのアクセス、またはディスクフルリソースを持つノードのみからのアクセスを許可します。

  • 高度なルール。ノードがボリュームにアクセスできる、より詳細なルールを可能にします。


    parameters: |
        - fromSame:

    複数のルールを指定でき、1 つのルールに一致するだけで割り当て可能になります。

4.4.11. encryption

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

4.4.12. nodeList

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

このオプションを使用する場合は autoPlace を使用しないでください。
このオプションは、ボリュームのストレージをどのLINSTORノード上でプロビジョニングするかを決定し、 kubelets からこれらのボリュームにアクセスできるようにします。

4.4.13. clientList

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

4.4.14. replicasOnSame

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

オペレーターは、Kubernetes ノードからのすべてのラベルを定期的に同期するため、それらをスケジューリング制約のキーとして使用できます。

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

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

このガイドは、LINSTOR CSI バージョン 0.10.0 以降を想定しています。 replicasOnSame および replicasOnDifferent で参照されるすべてのプロパティは、補助プロパティとして解釈されます。古いバージョンの LINSTOR CSI を使用している場合は、すべてのプロパティ名に Aux/ プレフィックスを追加する必要があります。したがって、 replicasOnSame: "zone=z1"replicasOnSame: "Aux/zone=z1" になります。 Aux/ を手動で追加すると、新しい LINSTOR CSI バージョンで引き続き機能します。

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

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

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

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

4.4.15. replicasOnDifferent

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

  • 特定のノードでのボリューム配置の防止:


    例: replicasOnDifferent: "no-csi-volumes=true"autoPlace 設定を満たすのに十分なノードが他にない限り、プロパティ no-csi-volumes=true を持つノードにボリュームを配置しません。

  • 同じキーの値が異なるノード間でボリュームを分散します。

    プロパティ値が指定されていない場合、LINSTOR は、可能であれば、そのプロパティの値が異なるノード間でボリュームを配置します。

    例: 4 つのノードがあると仮定し node-a1node-a2zone=a で、 node-b1node-b2zone=b で構成されているとします。 StorageClassautoPlace: "2" および replicasOnDifferent: "zone" で使用すると、LINSTOR は node-a1 または node-a2 のいずれかに 1 つのレプリカを作成し、 node-b1 または node-b2 のいずれかにもう 1 つのレプリカを作成します。

4.4.16. disklessOnRemaining


4.4.17. doNotPlaceWithRegex


4.4.18. fsOpts

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

これらの値は選択した filesystem 固有です。

4.4.19. mountOpts

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

4.4.20. postMountXfsOpts

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

4.4.21.* で始まるパラメータは StorageClass の Resource Group に設定される Linstor プロパティに変換されます。

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

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

4.4.22. DrbdOptions/*: <x>

このオプションは非推奨です。より一般的な* を使用してください。

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

4.5. スナップショット

スナップショット の作成とスナップショットからの新しいボリュームの作成は VolumeSnapshots, VolumeSnapshotClasses, と PVCs を使用して行われます。

4.5.1. スナップショットサポートの追加

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

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

$ kubectl get --raw /apis/
$ # If your distribution does NOT support snapshots out of the box, you will get a different response:
$ kubectl get --raw /apis/
Error from server (NotFound): the server could not find the requested resource

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

Listing 6. Piraeus チャートを使用したスナップショットサポートの追加
$ kubectl create namespace snapshot-controller
$ helm repo add piraeus-charts
$ helm install -n snapshot-controller snapshot-validation-webhook \
$ helm install -n snapshot-controller snapshot-controller \
  piraeus-charts/snapshot-controller --wait

4.5.2. ボリュームスナップショットの使用

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

Listing 7. my-first-linstor-snapshot-class.yaml
kind: VolumeSnapshotClass
  name: my-first-linstor-snapshot-class
deletionPolicy: Delete

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

kubectl create -f my-first-linstor-snapshot-class.yaml

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

Listing 8. my-first-linstor-snapshot.yaml
kind: VolumeSnapshot
  name: my-first-linstor-snapshot
  volumeSnapshotClassName: my-first-linstor-snapshot-class
    persistentVolumeClaimName: my-first-linstor-volume

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

kubectl create -f my-first-linstor-snapshot.yaml


kubectl describe my-first-linstor-snapshot
    Persistent Volume Claim Name:  my-first-linstor-snapshot
  Volume Snapshot Class Name:      my-first-linstor-snapshot-class
  Bound Volume Snapshot Content Name:  snapcontent-b6072ab7-6ddf-482b-a4e3-693088136d2c
  Creation Time:                       2020-06-04T13:02:28Z
  Ready To Use:                        true
  Restore Size:                        500Mi

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

Listing 9. my-first-linstor-volume-from-snapshot.yaml
apiVersion: v1
kind: PersistentVolumeClaim
  name: my-first-linstor-volume-from-snapshot
  storageClassName: linstor-basic-storage-class
    name: my-first-linstor-snapshot
    kind: VolumeSnapshot
    - ReadWriteOnce
      storage: 500Mi

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

kubectl create -f my-first-linstor-volume-from-snapshot.yaml


kind: VolumeSnapshotClass
  name: linstor-csi-snapshot-class-s3
deletionPolicy: Retain
parameters: S3 backup-remote "false" snapshot-bucket us-west-1 "false"
  # Refer here to the secret that holds access and secret key for the S3 endpoint.
  # See below for an example. linstor-csi-s3-access storage
kind: Secret
apiVersion: v1
  name: linstor-csi-s3-access
  namespace: storage
immutable: true
  access-key: access-key
  secret-key: secret-key パラメータの正確な意味については LINSTOR スナップショットガイド を確認してください。ログインに使用される認証情報は、上記の例で示すように、別のシークレットに保存されます。




復元すべきスナップショットがS3へのバックアップの一部である場合、LINSTOR “remote” を最初に設定します。

linstor remote create s3 backup-remote \
  snapshot-bucket us-west-1 access-key secret-key
linstor backup list backup-remote



kind: VolumeSnapshot
  name: example-backup-from-s3
  namespace: project
    volumeSnapshotContentName: restored-snap-content-from-s3
  volumeSnapshotClassName: linstor-csi-snapshot-class-s3
kind: VolumeSnapshotContent
  name: restored-snap-content-from-s3
  deletionPolicy: Delete
    snapshotHandle: snapshot-id
  volumeSnapshotClassName: linstor-csi-snapshot-class-s3
    kind: VolumeSnapshot
    name: example-backup-from-s3
    namespace: project

適用すると、VolumeSnapshot は ready と表示され、その時点で PVC の dataSource として参照することができるようになります。

4.6. ボリュームのアクセスしやすさと局所性

LINSTOR ボリュームはローカルと ネットワーク経由 の両方でアクセスできます。CSI ドライバーは、コンシューマー用に選択されたノードでボリュームにアクセスできるようにします。ドライバーは、ボリュームの局所性の確保(コンシューマーは下位データと同じノードに配置される)と、アクセスを制限する(ノードのサブセットのみがネットワーク経由でボリュームにアクセスできる)オプションも提供します。

ボリュームの局所性は、ストレージクラスで volumeBindingMode: WaitForFirstConsumer を設定することで実現されます。これにより、Kubernetes と CSI ドライバーは、PVC を参照する最初のコンシューマー(ポッド)がスケジュールされるまで待機するように指示されます。次に、CSI ドライバーは、コンシューマーと同じノード上の下位データを使用してボリュームをプロビジョニングします。適切なストレージプールのないノードが選択された場合、アクセス可能なノードのセットから代替ノードが選択されます(以下を参照)。

ボリュームのアクセスしやすさは allowRemoteVolumeAccess パラメータ によって制御されます。CSI プラグインがボリュームを配置するときはいつでも、このパラメーターを調べてアクセス可能なノードのセットを取得します。これは、ネットワークを介して配置されたボリュームを共有できることを意味します。この情報は、PV のラベルセレクターを介して Kubernetes にも伝達されます。

4.6.1. ボリュームのアクセスしやすさと局所性の例




Listing 10. example-storage-class.yaml
kind: StorageClass
  name: linstor-storage
volumeBindingMode: WaitForFirstConsumer (1)
parameters: linstor-pool (2) "2" (3) "true" (4)
1 レイトボリュームバインディングを有効にします。これにより、可能であれば、最初に実行するポッドと同じノードに 1 つのレプリカが配置されます。
2 使用するストレージプールを設定します。
3 少なくとも 2 つのノードがデータを格納することを確証します。
4 レプリカのないノードでもボリュームの使用を許可します。すべてのノードが均等に接続されているため、パフォーマンスへの影響は小さいです。


Listing 11. example-storage-class.yaml
kind: StorageClass
  name: linstor-storage
volumeBindingMode: WaitForFirstConsumer (1)
parameters: linstor-pool (2) "2" (3) | (4)
    - fromSame:
      - (5)
1 レイトボリュームバインディングを有効にします。これにより、可能であれば、最初に実行するポッドと同じノードに 1 つのレプリカが配置されます。
2 使用するストレージプールを設定します。
3 少なくとも 2 つのノードがデータを格納することを確証します。
4 ゾーンの内部ネットワークが高速で低遅延であるという前提で、レプリカと同じゾーンのノードでボリュームを使用できるようにします。
5 レプリカを異なるゾーンに配置します。


Listing 12. example-storage-class.yaml
kind: StorageClass
  name: linstor-storage
volumeBindingMode: WaitForFirstConsumer (1)
parameters: linstor-pool (2) "2" (3) | (4)
    - fromSame:
      - (5)
1 レイトボリュームバインディングを有効にします。これにより、可能であれば、最初に実行するポッドと同じノードに 1 つのレプリカが配置されます。
2 使用するストレージプールを設定します。
3 少なくとも 2 つのノードがデータを格納することを確証します。
4 ゾーンの内部ネットワークが高速で低遅延であるという前提で、レプリカと同じゾーンのノードでボリュームを使用できるようにします。
5 レプリカを単一のリージョンのみに制限します。


Listing 13. example-storage-class.yaml
kind: StorageClass
  name: linstor-storage
parameters: linstor-pool (1) "1" (2) "true" (3)
1 使用するストレージプールを設定します。
2 ストレージホストが 1 つのみであると仮定して、追加のレプリカなしで 1 つのボリュームのみを配置します。
3 ワーカーノードが外部ストレージホストに接続できるようにします。

4.7. LINSTOR アフィニティ コントローラ

ボリュームのアクセシビリティは、PersistentVolume (PV) の node affinity によって制御されます。このアフィニティは静的です。つまり、一度定義すると変更できません。

これは、厳密なアフィニティを使用する場合に問題になる可能性があります。PV は特定のノードに固定されていますが、ノードを削除または追加する必要がある場合があります。LINSTOR はボリュームを移動できますが (たとえば、これは kubernetes でノードを削除すると自動的に行われます)、PV アフィニティはこれを反映するように更新されません。

ここで、LINSTOR Affinity Controller の出番です。PV を監視し、それらのアフィニティを LINSTOR のボリュームの状態と比較します。それらが同期しなくなると、PV は更新されたバージョンに置き換えられます。

LINSTOR Affinity Controller は、Helm チャートにパッケージ化されています。 Operator と同じ名前空間にインストールする場合は、以下を実行するだけです。

$ helm repo update
$ helm install linstor-affinity-controller linstor/linstor-affinity-controller

チャートの追加オプションは upstream project で利用できます。

4.8. LINSTOR スケジューラーを使用したボリューム局所性の最適化

LINBIT は Kubernetes スケジューラ用のオープンソースプラグインをメンテナンスしています。スケジューラは、ボリュームの現在の配置を考慮して、データの局所性を最適化します。可能であれば、接続されたボリュームのレプリカもホストするノードにポッドが割り当てられ、読み取り操作のレイテンシーが短縮されます。

スケジューラーは別のチャート から利用できます。チャートは、後で Pod リソースを作成するときに使用できる新しいスケジューラーをデプロイします。

apiVersion: v1
kind: Pod
  name: busybox
  schedulerName: linstor-scheduler (1)
  - name: busybox
    image: busybox
    command: ["tail", "-f", "/dev/null"]
    - name: my-first-linstor-volume
      mountPath: /data
    - containerPort: 80
  - name: my-first-linstor-volume
      claimName: "test-volume"
1 スケジューラの名前をポッドに追加します。

4.9. 高可用性コントローラーを使用した高速ワークロードフェイルオーバー

ノードに障害が発生した場合、Kubernetes はステートフルワークロードの再スケジュールを非常に慎重に行います。これは、ポッドが到達不能なノードから移動されるまでに 15 分以上かかる可能性があることを意味します。DRBD と LINSTOR が利用できる情報により、このプロセスを大幅にスピードアップできます。

LINSTOR 高可用性コントローラー (HA コントローラー) は、ストレージに LINSTOR を使用して、ステートフル ワークロードのフェイルオーバー プロセスを高速化します。少なくとも 1 つの DRBD リソースにアタッチされている Pod を監視および管理します。

HA コントローラーが正しく機能するには、クォーラム、つまり少なくとも 3 つのレプリカ (または 2 つのレプリカと 1 つのディスクレス タイブレーカー) が必要です。使用するレプリカ数が少ない場合、アタッチされた Pod は無視され、より高速なフェイルオーバーの対象にはなりません。

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

$ helm repo update
$ helm install linstor-ha-controller linstor/linstor-ha-controller

クラスタで HA コントローラを使用している場合は、すべての StorageClass で追加のパラメータを設定できます。これらのパラメーターにより、ボリュームが誤って読み取り専用として再マウントされて、Pod の機能が低下することがなくなります。

parameters: suspend-io suspend-io force-secondary retry-connect

Pod を HA コントローラーによる管理から除外するには、次のアノテーションを Pod に追加します。

$ kubectl annotate pod <podname>""

4.10. Kubernetes でのノードの退避

リソースの LINSTOR ノードを退避させて、クラスター内の他のノードに配置する場合、そのプロセスは ノードの退避 で詳しく説明されています。 ただし、Kubernetes で LINSTOR ノードを退避させる前に、追加のアクションを実行する必要があります。


# kubectl drain --ignore-daemonsets <node_name>

クラスターが正常に動作していることを確認したら ノードの退避 の手順を続行できます。


# linstor node set-property AutoplaceTarget false

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

4.11. Kubernetes での LINSTOR デプロイメントのアップグレード

A LINSTOR deployment on Kubernetes can be upgraded to a new release.

During the upgrade process, attaching, detaching or provisioning of volumes will be paused. Existing volumes and volumes already in use by a pod will continue to work.

4.11.1. Upgrading LINSTOR Operator v2

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

During the upgrade process, the LINSTOR satellite pods will restart. This will stop replication of DRBD devices, freezing any writes on volumes, until the satellite pods are online again.

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

Listing 14. kustomization.yaml
kind: Kustomization
namespace: linbit-sds
  disableNameSuffixHash: true
- name: drbdio-pull-secret
  - .dockerconfigjson={"auths":{"":{"username":"MY_LINBIT_USER","password":"MY_LINBIT_PASSWORD"}}}

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

$ kubectl apply -k .
namespace/linbit-sds created
$ kubectl -n linbit-sds  wait pod --for=condition=Ready --all

4.11.2. Upgrading LINSTOR Operator v1

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

LINSTOR etcd デプロイメントを使用するアップグレードでは、永続ストレージを使用するために etcd が必要です。etcd が etcd.persistentVolume.enabled=true を使用してデプロイされた場合にのみ、これらの手順に従ってください。


  • LINSTOR オペレーターのデプロイメント

  • LINSTOR コントローラー

  • LINSTOR サテライト

  • LINSTOR CSI Driver

  • etcd

  • Stork

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

helm repo update
helm upgrade linstor-op linstor/linstor

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

# Retrieve the currently set options
$ helm get values linstor-op
drbdRepoCred: drbdiocred
      - devicePaths:
        - /dev/vdb
        name: thinpool
        thinVolume: thinpool
        volumeGroup: ""
# Save current options
$ helm get values linstor-op > orig.yaml
# modify values here as needed. for example selecting a newer DRBD image
$ vim orig.yaml
# Start the upgrade
$ helm upgrade linstor-op linstor/linstor -f orig.yaml

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

4.11.3. Kubernetes バックエンドを使用した LINSTOR クラスターのアップグレード

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


  • チャートまたはオペレーターのバージョンが古すぎます。自動バックアップは、バージョン 1.8.0 以降で使用できます。1.8.0 より前のバージョンからアップグレードする場合は、次のセクションの手動の手順に従ってください。

  • バックアップが大きすぎて、Kubernetes のシークレットに収まりません。この場合、LinstorController リソースのステータスフィールドにエラーが報告されます。作成したバックアップを安全な場所にコピーし、必要なシークレットを作成して、指示に従います。

    kubectl cp <linstor-operator-pod>:/run/linstor-backups/linstor-backup-<some-hash>.tar.gz <destination-path>
    kubectl create secret linstor-backup-<same-hash>
LINSTOR データベースのバックアップを作成

LINSTOR k8s データベースのバックアップを手動で作成する必要がある場合は、次の手順に従ってください。

  1. 現在のコントローラーを停止します。

    $ kubectl patch linstorcontroller linstor-op-cs '{"spec":{"replicas": 0}}'
    $ kubectl rollout status --watch deployment/linstor-op-cs-controller
  2. 次のコマンドは、すべての LINSTOR カスタムリソース定義の現在の状態を保存するファイル crds.yaml を作成します。

    $ kubectl get crds | grep -o ".*" | \
      xargs kubectl get crds -oyaml > crds.yaml
  3. 定義に加えて、実際のリソースもバックアップする必要があります。

    $ kubectl get crds | grep -o ".*" | \
      xargs -i{} sh -c "kubectl get {} -oyaml > {}.yaml"
  4. --set IHaveBackedUpAllMyLinstorResources=true を使用して chart のアップグレードを実行し、上記の手順を実行したことを確認します。

LINSTOR データベースのバックアップからの復元

LINSTOR のアップグレード中に障害から回復する必要がある場合は、次の手順に従ってください。

  1. バックアップを準備します(バックアップがローカルマシンですでに利用可能な場合はスキップ)。

    $ # List the available backups
    $ kubectl get secret ',FROM:metadata.annotations.linstor\.linbit\.com/backup-previous-version,CREATED-AT:.metadata.creationTimestamp'
    $ kubectl get secret linstor-backup-<backup-specific-hash> '-ogo-template=go-template={{index .data ".binaryData.backup.tar.gz" | base64decode}}' > linstor-backup.tar.gz
  2. バックアップを解凍します

    $ tar xvf linstor-backup.tar.gz
  3. 現在のコントローラーを停止します。

    $ kubectl patch linstorcontroller linstor-op-cs "{"spec":{"replicas": 0}}"
    $ kubectl rollout status --watch deployment/piraeus-op-cs-controller
  4. 既存のリソースを削除します

    $ kubectl get crds | grep -o ".*" | xargs --no-run-if-empty kubectl delete crds
  5. 古い LINSTOR CRD を適用します

    $ kubectl apply -f crds.yaml
  6. 古い LINSTOR リソースの状態を適用します

    $ kubectl apply -f *
  7. 古い LINSTOR バージョンを使用してヘルムチャートを再適用します

    $ helm upgrade linstor-op charts/piraeus --set operator.controller.controllerImage=... --set operator.satelliteSet.satelliteImage=...

4.11.4. 特定のバージョンのアップグレード手順


v1.10 へのアップグレード

バージョン 1.10 では、ホストとコンテナー間で DRBD 構成を共有するオプションが導入されています。このオプションが必要な場合は、CRD を更新する必要があります。 Helm はチャートのアップグレード時に CRD をアップグレードしないため、代わりに次を実行してください。

$ helm repo update
$ helm pull linstor/linstor --untar
$ kubectl replace -f linstor/crds/ replaced replaced replaced
v1.9 へのアップグレード

バージョン 1.9 では、デフォルトで <s-kubernetes-ha-controller,LINSTOR HA Controller>> デプロイメントが無効になっています。デプロイメントは、LINSTOR Operator チャートから移動しました。古いバージョンを引き続き使用する場合は、次の Helm コマンドを使用して再度有効にします。

helm upgrade linstor-op linstor/linstor ... --set haController.enabled=true

v1.6 以前から v1.9 にアップグレードする場合は、次のいずれかを行う必要があります。

  1. アップグレードする前に、マスターパスフレーズを作成する。

    $ kubectl create secret generic linstor-pass --from-literal=MASTER_PASSPHRASE=<password>
  2. または、最初に v1.7 にアップグレードすると、Helm によってマスターパスフレーズが自動的に作成されます。このパスフレーズは、次のように入力して後で表示できます。

    $ kubectl get secret linstor-op-passphrase \
    -ogo-template='{{ .data.MASTER_PASSPHRASE | base64decode }}'
v1.8 へのアップグレード
このアップグレードには K8s データベースの完全な再構築が必要なため、アップグレードに通常よりも時間がかかる場合があります。

バージョン 1.8 では、CSI ドライバーのログレベルとワーカースレッドの数を一元的に設定するための新しいオプションが導入されています。これらのオプションが必要な場合は、CRD を更新する必要があります。 Helm はチャートのアップグレード時に CRD をアップグレードしないため、代わりに次を実行してください。

$ helm repo update
$ helm pull linstor/linstor --untar
$ kubectl replace -f linstor/crds/ replaced replaced replaced

さらに 1.8 は SSL/TLS セットアップの動作を作り直します。 secure deployment section を確認し、これらのステップをもう一度やり直してください。

v1.6 以前から v1.8 にアップグレードする場合は、次のいずれかを行う必要があります。

  1. アップグレードする前に、マスターパスフレーズを作成する。

    $ kubectl create secret generic linstor-pass --from-literal=MASTER_PASSPHRASE=<password>
  2. または、最初に v1.7 にアップグレードすると、Helm によってマスターパスフレーズが自動的に作成されます。このパスフレーズは、次のように入力して後で表示できます。

    $ kubectl get secret linstor-op-passphrase \
    -ogo-template='{{ .data.MASTER_PASSPHRASE | base64decode }}'
v1.7 へのアップグレード


v1.6 へのアップグレード

このバージョンでは、デフォルトの /var/lib/kubelet とは異なる状態ディレクトリを使用する Kubernetes ディストリビューションをサポートするための新しいオプションが導入されています。注目すべきは /var/snap/microk8s/common/var/lib/kubelet を使用する microk8s です。これをサポートするには LinstorCSIDriver CRD に少し追加する必要がありました。Helm は chart のアップグレード時に CRD をアップグレードしないため、代わりに次を実行してください。

$ helm repo update
$ helm pull linstor/linstor --untar
$ kubectl replace -f linstor/crds/ replaced replaced replaced

新しい CRD を適用しないと、次のようなエラーが発生します。

Error: UPGRADE FAILED: error validating "": error validating data: ValidationError(LinstorCSIDriver.spec): unknown field "kubeletPath" in com.linbit.linstor.v1.LinstorCSIDriver.spec

以前に付属のスナップショットコントローラーを使用して VolumeSnapshot リソースを処理したことがある場合は、それを Piraeus プロジェクトによって提供される新しい chart に置き換える必要があります。 スナップショットセクション が更新され、スナップショットコントローラーをクラスターに追加する方法e 含まれるようになりました。

v1.5 へのアップグレード

このバージョンでは DRBD リソースの 監視 コンポーネントが導入されます。これには、新しいイメージと既存の LinstorSatelliteSet CRD の置き換えが必要です。 Helm は chart upgrade で CRD をアップグレードしません。代わりに、以下を実行してください。

$ helm repo update
$ helm pull linstor/linstor --untar
$ kubectl replace -f linstor/crds/ replaced replaced replaced

提供されている 監視機能 を使用する予定がない場合でも、上記の手順を適用する必要があります。そうしないと、次のようなエラーが発生します。

Error: UPGRADE FAILED: error validating "": error validating data: ValidationError(LinstorSatelliteSet.spec): unknown field "monitoringImage" in com.linbit.linstor.v1.LinstorSatelliteSet.spec
一部の Helm バージョンでは、CRD を交換した後でも監視イメージを設定できません。その場合、クラスター内の LinstorSatelliteSet は空の monitoringImage 値を表示します。 kubectl edit linstorsatellitesets を使用してリソースを編集し、値を に設定して、監視を有効にします。
v1.4 へのアップグレード

このバージョンでは、etcd イメージの新しいデフォルトバージョンが導入されているため、etcd が永続ストレージを使用していることに特に注意してください。永続ストレージなしで etcd イメージをアップグレードすると、クラスターが壊れるので注意してください。

新しい Helm オプションを使用せずに既存のクラスターをアップグレードする場合、追加の手順は必要ありません。

新しく導入された additionalProperties および additionalEnv 設定を使用する場合は、インストールされている CustomResourceDefinitions を新しいバージョンに置き換える必要があります。Helm は chart upgrade で CRD をアップグレードしません。

$ helm pull linstor/linstor --untar
$ kubectl replace -f linstor/crds/ replaced replaced replaced
v1.3 へのアップグレード


v1.2 へのアップグレード

LINSTOR オペレーター v1.2 は Kubernetes 1.17 以降でサポートされています。古い Kubernetes ディストリビューションを使用している場合は、デフォルト設定を変更する必要がある場合があります。例えば [the CSI provisioner]( です。

CSI コンポーネントの更新時に既知の問題があります。pod は最新のイメージに更新されず、LinstorCSIDrivers リソースの errors セクションに DaemonSet の更新エラーが表示されます。この場合、 deployment/linstor-op-csi-controllerdaemonset/linstor-op-csi-node を手動で削除してください。それらはオペレーターによって再作成されます。

4.11.5. etcd バックアップの作成

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

kubectl exec linstor-op-etcd-0 -- etcdctl snapshot save /tmp/save.db
kubectl cp linstor-op-etcd-0:/tmp/save.db save.db

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

5. Openshift での LINSTOR ボリューム

本章では、LINSTOR Operatorで管理し、 LINSTOR CSI plugin を使用してボリュームをプロビジョニングしたOpenShiftでのLINBIT SDSの使用方法を説明します。

OpenShift は、Red Hatが開発し、サポートするKubernetesの公式ディストリビューションです。OpenShiftの価値は、ネットワークのイングレスやモニタリングなど、他のオプションのコンポーネントを強力に統合し、すべてを管理するためのWeb UIで結びつけていることです。LINSTOR Operatorは、可能な限りこれらのコンポーネントと統合しています。

5.1. Openshift での LINSTOR のデプロイ

OpenShiftへのLINBIT SDSのデプロイは、他のKubernetesクラスタへのLINBIT SDSのデプロイと同様です。前提条件として、以下のものが必要です。

  • oc ユーティリティで OpenShift クラスターにアクセスできる。

  • にアクセスする LINBIT カスタマーポータルの資格がある。

LINBIT’s container image repository ( is only available to LINBIT customers or through LINBIT customer trial accounts. Contact LINBIT for information on pricing or to begin a trial. Alternatively, you can use the LINSTOR SDS upstream project, named Piraeus, without being a LINBIT customer.

First, create a new OpenShift project for LINBIT SDS which will also create a namespace for LINBIT SDS deployment:

$ oc new-project linbit-sds
Now using project "linbit-sds" on server ...

Next, create a file named kustomization.yaml to customize some of the deployment’s default values:

Listing 15. kustomization.yaml
kind: Kustomization
namespace: linbit-sds
  disableNameSuffixHash: true
  - name: drbdio-pull-secret
      - .dockerconfigjson={"auths":{"":{"username":"MY_LINBIT_USER","password":"MY_LINBIT_PASSWORD"}}} (1)
1 Replace MY_LINBIT_USER and MY_LINBIT_PASSWORD with your LINBIT customer portal credentials.
The YAML configuration manifest above is current at the time of writing. Refer to for the most up-to-date version or previous versions if needed.

You can make additional modifications to the kustomizaion.yaml file based on your preferences and needs. Possible options are discussed in the Kubernetes advanced deployment section.

Finally, deploy LINBIT SDS by applying the customized configuration, and wait until all pods are ready, by entering the following commands in the same directory as your kustomization.yaml:

$ oc apply -k . && \
oc wait --for=condition=ready pod --all -n linbit-sds --timeout=5m && \
oc get pods -n linbit-sds

Output should eventually show that a LINSTOR controller pod is up and running.

NAME                                                   READY   STATUS    RESTARTS   AGE
linstor-operator-controller-manager-59586c7bb5-qlfwb   1/1     Running   0          11s

After deploying the LINSTOR controller pod, enter the following command to complete the deployment of your LINBIT SDS in OpenShift cluster:

# oc apply -f - <<EOF
kind: LinstorCluster
  name: linstorcluster
spec: {}
# oc wait pod --for=condition=Ready -n linbit-sds --timeout=5m --all

Output should eventually show that your LINBIT SDS cluster pods are up and running.

NAME                                                   READY   STATUS    RESTARTS   AGE
ha-controller-6fl6b                                    1/1     Running   0          60s
ha-controller-c955w                                    1/1     Running   0          60s
ha-controller-v4mdr                                    1/1     Running   0          60s
kube-0                                                 2/2     Running   0          56s (1)
kube-1                                                 2/2     Running   0          56s (1)
kube-2                                                 2/2     Running   0          55s (1)
linstor-controller-779bffbc59-6jjzd                    1/1     Running   0          61s
linstor-csi-controller-8cd45658f-6f9t6                 7/7     Running   0          61s
linstor-csi-node-blgk8                                 3/3     Running   0          61s
linstor-csi-node-mn8p6                                 3/3     Running   0          61s
linstor-csi-node-pncpz                                 3/3     Running   0          61s
linstor-operator-controller-manager-59586c7bb5-qlfwb   1/1     Running   0          4m2s
1 These pods are the LINSTOR satellite node pods. The pod name reflects each node’s hostname.

5.1.1. OpenShiftでLINBIT SDSを利用する


5.1.2. LINBIT GUIアクセスの設定

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

$ oc create route edge --service linstor-op-cs
$ oc get route
NAME           HOST/PORT                                  PATH  SERVICES       PORT           TERMINATION  WILDCARD
linstor-op-cs        linstor-op-cs  linstor-op-cs  edge         None

GUIは でアクセスできるようになりました。

This might enable external access to LINBIT GUI and LINSTOR API. Ensure that only authorized users can access it, for example, by requiring client side TLS certificates on the route.

5.1.3. クラスタモニタリングの設定

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のメトリックを取得します。

5.2. OpenShiftでLINBIT SDS 連携

LINSTOR Controller podにはLINSTOR Clientが含まれており、LINSTORの対話型モードに簡単にアクセスすることができます。例えば:

$ oc exec -it deployment/linstor-op-cs-controller -- linstor interactive
LINSTOR ==> ...

This should only be necessary for investigating problems and accessing advanced functionality. Regular operation such as creating volumes should be achieved through the Kubernetes integration.

6. NomadのLINSTORボリューム


6.1. Nomad の紹介

Nomad は、コンテナとコンテナ化されていないアプリケーションをオンプレミスとクラウド上にデプロイして管理するための、シンプルで柔軟性のあるワークロードオーケストレーターです。

Nomad は Container Storage Interface(CSI) に準拠した plug-ins 経由のストレージボリュームのプロビジョニングをサポートします。

LINBIT は、CSIプラグインを のコンテナイメージの形で配布しています。このプラグインは、Nomadクラスタに沿って、またはその内部にデプロイされたLINSTORクラスタと連携するように構成できます。

LINBIT’s container image repository ( is only available to LINBIT customers or through LINBIT customer trial accounts. Contact LINBIT for information on pricing or to begin a trial. Alternatively, you may use LINSTOR SDS’ upstream project named Piraeus, without being a LINBIT customer.

6.2. NomadにLINSTORの展開


LINSTORをノードに直接インストールする場合は、 LINSTOR のインストール を参照してください。このセクションをスキップして、 CSI ドライバのデプロイ に直接移動できます。

6.2.1. Nomadを準備する


  • docker driverをサポートし、特権コンテナの実行を許可します。


    Listing 16. /etc/nomad.d/docker-privileged.hcl
    plugin "docker" {
      config {
        allow_privileged = true
  • コンテナネットワークのサポート。 Container Network Interface プラグインがインストールされていない場合は、ジョブネットワークで mode = "host" のみを使用できます。ほとんどの本番環境のセットアップでは、デフォルトのプラグインをインストールすることをお勧めします。

    plug-in release page に移動し、ディストリビューションに適したリリースアーカイブを選択して、/opt/cni/bin に解凍します。解凍する前にディレクトリを作成する必要があるかもしれません。

  • ホストボリュームを提供して、ホストの /dev ディレクトリへのコンテナアクセスを許可する


    Listing 17. /etc/nomad.d/host-volume-dev.hcl
    client {
      host_volume "dev" {
        path = "/dev"

6.2.2. LINSTORコントローラジョブの作成

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

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

Listing 18. linstor-controller.hcl
job "linstor-controller" {
  datacenters = ["dc1"] (1)
  type = "service"

  group "linstor-controller" {
    network {
      mode = "bridge"
      # port "linstor-api" { (2)
      #   static = 3370
      #   to = 3370
      # }

    service { (3)
      name = "linstor-api"
      port = "3370"

      connect {
        sidecar_service {}

      check {
        expose = true
        type = "http"
        name = "api-health"
        path = "/health"
        interval = "30s"
        timeout = "5s"

    task "linstor-controller" {
      driver = "docker"
      config {
        image = "" (4)

        auth { (5)
          username = "example"
          password = "example"
          server_address = ""

        mount {
          type = "bind"
          source = "local"
          target = "/etc/linstor"

      # template { (6)
      #  destination = "local/linstor.toml"
      #  data = <<EOH
      #    [db]
      #    user = "example"
      #    password = "example"
      #    connection_url = "jdbc:postgresql://"
      #  EOH
      # }

      resources {
        cpu    = 500 # 500 MHz
        memory = 700 # 700MB
1 dc1 はデータセンタ名に置き換えてください
2 これにより、ホストでポート 3370 の LINSTOR API が公開されます。
クラスタが Consul Connect で構成されていない場合は、このセクションのコメントを削除してください。
3 service ブロックは、サービスメッシュを介してL INSTOR API を他のジョブに公開するために使用されます。
クラスタが Consul Connect で構成されていない場合は、このセクションを削除してください。
4 LINSTOR Controller イメージを実行するように設定します。最新のイメージは から入手できます。
:latest タグの使用は、バージョンの不一致や意図しないアップグレードにすぐにつながる可能性があるため、お勧めしません。
5 イメージを pull するときに使用する認証を設定します。 から pull する場合は、ここでLINBITの顧客ログインを使用する必要があります。プライベートレポジトリからの pull に関しては こちら を参照ください。
6 このテンプレートは、LINSTORの任意の構成オプションを設定するために使用できます。この例では、LINSTORの外部データベースを構成します。詳細は LINSTOR データベースオプション こちら およびNomadテンプレート こちら を参照ください。


$ nomad job run linstor-controller.hcl
==> Monitoring evaluation "7d8911a7"
    Evaluation triggered by job "linstor-controller"
==> Monitoring evaluation "7d8911a7"
    Evaluation within deployment: "436f4b2d"
    Allocation "0b564c73" created: node "07754224", group "controller"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "7d8911a7" finished with status "complete"
LINSTOR データベースにホストボリュームを使用

外部データベースを設定せずにLINSTORを試したい場合は、LINSTOR 組み込みのファイルシステムベースのデータベースを利用できます。データベースを永続的にするには、データベースがホストボリュームに配置されていることを確認する必要があります。

ホストボリュームを使用すると、1つのノードのみでLINSTOR コントローラを実行できます。ノードが使用不可の場合は、LINSTOR クラスタも使用不可になります。代替策として、外部(高可用性)データベースを使用するか、 LINSTORクラスタをホストに直接導入 します。

LINSTOR データベース用のホストボリュームを作成するには、まず、必要な権限を持つディレクトリをホスト上に作成します。

$ mkdir -p /var/lib/linstor
$ chown -R 1000:0 /var/lib/linstor


Listing 19. /etc/nomad.d/host-volume-linstor-db.hcl
client {
  host_volume "linstor-db" {
    path = "/var/lib/linstor"

次に、上記の例の linstor-controller.hcl に次のスニペットを追加し、構成テンプレートの connection_url オプションを変更します。

Listing 20. job > group
volume "linstor-db" {
  type = "host"
  source = "linstor-db"
Listing 21. job > group > task
volume_mount {
  volume = "linstor-db"
  destination = "/var/lib/linstor"

template {
  destination = "local/linstor.toml"
  data = <<EOH
    user = "linstor"
    password = "linstor"
    connection_url = "jdbc:h2:/var/lib/linstor/linstordb"

6.2.3. LINSTOR サテライトジョブの作成

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

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

Listing 22. linstor-satellite.hcl
job "linstor-satellite" {
  datacenters = ["dc1"] (1)
  type = "system"

  group "satellite" {
    network {
      mode = "host"

    volume "dev" { (2)
      type = "host"
      source = "dev"

    task "linstor-satellite" {
      driver = "docker"

      config {
        image = "" (3)

        auth { (4)
          username = "example"
          password = "example"
          server_address = ""

        privileged = true (5)
        network_mode = "host" (6)

      volume_mount { (2)
        volume = "dev"
        destination = "/dev"

      resources {
        cpu    = 500 # 500 MHz
        memory = 500 # 500MB

    task "drbd-loader" {
      driver = "docker"
      lifecycle {
        hook = "prestart" (7)

      config {
        image = "" (8)

        privileged = true (5)
        auth { (4)
          username = "example"
          password = "example"
          server_address = ""

      env {
        LB_HOW = "shipped_modules" (9)

      volume_mount { (10)
        volume = "kernel-src"
        destination = "/usr/src"
      volume_mount { (10)
        volume = "modules"
        destination = "/lib/modules"

    volume "modules" { (10)
      type = "host"
      source = "modules"
      read_only = true

    volume "kernel-src" { (10)
      type = "host"
      source = "kernel-src"
      read_only = true
1 dc1 はデータセンタ名に置き換えてください
2 dev ホストボリュームは Nomadを準備する で作成されたボリュームであり、サテライトがホストブロックデバイスを管理できるようにします。
3 LINSTORのサテライトイメージを実行するように設定します。最新のコンテナイメージは から入手できます。サテライトイメージのバージョンは、コントローライメージのバージョンと一致している必要があります。
:latest タグの使用は、バージョンの不一致や意図しないアップグレードにすぐにつながる可能性があるため、お勧めしません。
4 イメージを pull するときに使用する認証を設定します。 から pull する場合は、ここでLINBITの顧客ログインを使用する必要があります。プライベートレポジトリからの pull に関しては こちら を参照ください。
5 ストレージデバイスやDRBDを構成し、カーネルモジュールをロードするためには、コンテナーを特権モードで実行する必要があります。
6 サテライトはDRBDと通信する必要があるため、ホストネットワークで実行されているnetlinkインターフェースにアクセスする必要があります。
7 drbd-loader タスクはサテライトの開始時に1回実行され、DRBDやその他の有用なカーネルモジュールをロードします。
8 drbd-loader は、使用しているディストリビューションに固有のものです。使用可能なオプションは次のとおりです。
  • Ubuntu18.04(Bionic Beaver) 用の

  • Ubuntu20.04(Focal Fossa) 用の

  • RHEL8 用の

  • RHEL7 用の

9 drbd-loader コンテナは環境変数で設定できます。 LB_HOW はコンテナにDRBDカーネルモジュールの挿入方法を指示します。使用可能なオプションは次のとおりです。





LINSTOR サテライトで使用される既存のモジュール(例えば dm_thin_pooldm_cache など)のみをロードするようにします。

10 drbd-loader コンテナがDRBDを構築したり、既存のモジュールをロードしたりするためには、ホストの /usr/src/lib/modules にアクセスできる必要があります。

これには、すべてのノードに追加のホストボリュームを設定する必要があります。次のスニペットをすべての Nomad エージェント構成に追加してから、Nomad を再起動する必要があります。

Listing 23. /etc/nomad.d/drbd-loader-volumes.hcl
client {
  host_volume "modules" {
    path = "/lib/modules"
    read_only = true
  host_volume "kernel-src" {
    path = "/usr/src"
    read_only = true


$ nomad job run linstor-satellite.hcl
==> Monitoring evaluation "0c07469d"
    Evaluation triggered by job "linstor-satellite"
==> Monitoring evaluation "0c07469d"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "0c07469d" finished with status "complete"

6.2.4. NomadでのLINSTORの設定

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


  • コンテナに入って nomad exec で直接 linstor-controller を実行する。

  • linstor-controller を実行しているホスト上で コンテナを使用する。

    docker run -it --rm --net=host node create
  • linstor-client パッケージを linstor-controller を実行しているホストにインストールします。

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

$ linstor node create
$ linstor storage-pool create lvmthin thinpool linstor_vg/thinpool
CSIドライバでは、サテライトにホスト名に基づいた名前を付ける必要があります。正確に言うと、サテライト名はノードのNomads attr.unique.hostname 属性と一致する必要があります。

6.3. LINSTOR CSIドライバのNomadへの配備


次の例では、データセンター dc1 内のすべてのノードでLINSTOR CSIドライバを起動するNomadジョブを作成します。

Listing 24. linstor-csi.hcl
job "linstor-csi" {
  datacenters = ["dc1"] (1)
  type = "system"

  group "csi" {
    network {
      mode = "bridge"

    service {
      connect {
        sidecar_service { (2)
          proxy {
            upstreams {
              destination_name = "linstor-api"
              local_bind_port  = 8080

    task "csi-plugin" {
      driver = "docker"
      config {
        image = "" (3)

        auth { (4)
          username = "example"
          password = "example"
          server_address = ""

        args = [
          "--node=${attr.unique.hostname}", (5)
          "--linstor-endpoint=http://${NOMAD_UPSTREAM_ADDR_linstor_api}", (6)

        privileged = true (7)

      csi_plugin { (8)
        id = ""
        type = "monolith"
        mount_dir = "/csi"

      resources {
        cpu    = 100 # 100 MHz
        memory = 200 # 200MB
1 dc1 はデータセンタ名に置き換えてください
2 sidecar_service スタンザは、 Consul Connect を使用して生成されたサービスメッシュの使用を可能にします。Nomadでこの機能を構成していない場合、または外部 LINSTOR コントローラーを使用している場合は、この構成をスキップできます。
3 LINSTOR CSIドライバイメージを実行するように設定します。最新のイメージは から入手できます。
:latest タグの使用は、バージョンの不一致や意図しないアップグレードにすぐにつながる可能性があるため、お勧めしません。
4 イメージを pull するときに使用する認証を設定します。 から pull する場合は、ここでLINBITの顧客ログインを使用する必要があります。プライベートレポジトリからの pull に関しては こちら を参照ください。
5 この引数は、CSIドライバがLINSTOR APIで自身を識別するために使用するノード名を設定します。デフォルトでは、これはノードのホスト名に設定されます。
6 この引数は、LINSTOR APIエンドポイントを設定します。consulサービスメッシュ(前述のNr.2を参照)を使用していない場合は、これをControllers APIエンドポイントに設定する必要があります。エンドポイントは、デプロイされているすべてのノードから到達可能である必要があります。
7 CSIドライバはマウントコマンドを実行する必要があるため、特権付きコンテナが必要です。
8 csi_plugin スタンザは、このタスクがCSIプラグインであることをNomadに通知します。Nomadエージェントは、ボリュームに対する要求をジョブコンテナーの1つに転送します。


$ nomad job run linstor-csi.hcl
==> Monitoring evaluation "0119f19c"
    Evaluation triggered by job "linstor-csi"
==> Monitoring evaluation "0119f19c"
    Evaluation status changed: "pending" -> "complete"
==> Evaluation "0119f19c" finished with status "complete"

6.4. NomadでのLINSTORボリュームの使用

Nomadのボリュームは、 volume仕様 を使用して作成されます。

例として、次の指定では、2つのレプリカを持つ1GiBボリュームがLINSTORストレージプール thinpool から要求されます。

Listing 25. vol1.hcl
id = "vol1" (1)
name = "vol1" (2)

type = "csi"
plugin_id = ""

capacity_min = "1GiB"
capacity_max = "1GiB"

capability {
  access_mode = "single-node-writer" (3)
  attachment_mode = "file-system" (4)

mount_options {
  fs_type = "ext4" (5)

parameters { (6)
  "resourceGroup" = "default-resource",
  "storagePool" = "thinpool",
  "autoPlace" = "2"
1 id は、Nomad でこのボリュームを参照するために使用されます。ジョブ指定の volume.source フィールドで使用されます。
2 name は、バックエンド(LINSTORなど)でボリュームを作成するときに使用されます。理想的には、これは id と一致し、有効なLINSTORリソース名です。名前が有効でない場合は、LINSTOR CSIによって互換性のあるランダムな名前が生成されます。
3 ボリュームがサポートする必要があるアクセスの種類。LINSTOR CSIは次のものをサポートします。

一度に 1 つのノードに対してのみ読み取りアクセスを許可する


一度に 1 つのノードに対してのみ読み取り/書き込みアクセスを許可する



4 file-system または block-device のいずれかです。
5 使用するファイルシステムを指定します。LINSTOR CSI は ext4xfs をサポートします。
6 LINSTOR CSI に渡す追加パラメータ。上記の例では、リソースが default-resource resource group の一部であることを要求しており、2つのレプリカをデプロイする必要があります。

使用可能なパラメータの完全なリストについては、 ストレージクラスで使用可能なパラメータ を参照ください。Kubernetes は Nomad と同様に CSI プラグインを使用します。


$ nomad volume create vol1.hcl
Created external volume vol1 with ID vol1
$ nomad volume status
Container Storage Interface
ID    Name  Plugin ID               Schedulable  Access Mode
vol1  vol1  true         <none>
$ linstor resource list
┊ ResourceName ┊ Node                 ┊ Port ┊ Usage  ┊ Conns ┊    State ┊ CreatedOn           ┊
┊ vol1         ┊ ┊ 7000 ┊ Unused ┊ Ok    ┊ UpToDate ┊ 2021-06-15 14:56:32 ┊
┊ vol1         ┊ ┊ 7000 ┊ Unused ┊ Ok    ┊ UpToDate ┊ 2021-06-15 14:56:32 ┊

6.4.1. ジョブでのボリュームの使用

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

job "example" {

  group "example" {
    volume "example-vol" {
      type = "csi"
      source = "vol1"
      attachment_mode = "file-system"
      access_mode = "single-node-writer"

    task "mount-example" {
      volume_mount {
        volume = "example-vol"
        destination = "/data"


6.4.2. ボリュームのスナップショットの作成


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

$ nomad volume snapshot create vol1 snap1
Snapshot ID  Volume ID  Size     Create Time  Ready?
snap1        vol1       1.0 GiB  None         true
$ linstor s l
┊ ResourceName ┊ SnapshotName ┊ NodeNames                                  ┊ Volumes  ┊ CreatedOn           ┊ State      ┊
┊ vol1         ┊ snap1        ┊, ┊ 0: 1 GiB ┊ 2021-06-15 15:04:10 ┊ Successful ┊


$ cat vol2.hcl
id = "vol2"
name = "vol2"
snapshot_id = "snap1"

type = "csi"
plugin_id = ""

$ nomad volume create vol2.hcl
Created external volume vol2 with ID vol2

7. Proxmox VE での LINSTOR ボリューム

この章は LINSTOR Proxmox Plug-in にあるProxmox VEでのDRBDについて説明します。

7.1. Proxmox VE の紹介

Proxmox VE はKVM、Linuxコンテナ、HAとともに使われる簡単で、完全なサーバ仮想化環境を提供します。

‘linstor-proxmox’ is a Perl plugin for Proxmox that, in combination with LINSTOR, allows you to replicate VM disks on several Proxmox VE nodes. This allows to live-migrate active VMs within a few seconds and with no downtime without needing a central SAN, as the data is already replicated to multiple nodes.

7.2. Proxmox のアップグレード

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

7.2.1. Upgrading Plug-in to 7.x

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.

7.2.2. プラグインのバージョン 4.x から 5.x へアップグレード

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 に設定されていると仮定します。

# linstor resource-group create --storage-pool=mypool --place-count=3 drbdMypoolThree
# linstor volume-group create drbdMypoolThree
# vi /etc/pve/storage.cfg
drbd: drbdstorage
   content images,rootdir
   resourcegroup drbdMypoolThree

7.2.3. プラグインのバージョン 5.x から 6.x へアップグレード

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 コントローラを実現することをお勧めします。

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

7.2.4. PVE のバージョン 5.x から 6.x へアップグレード

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.

7.3. LINSTOR Proxmox プラグインのインストール

To use LINSTOR in Proxmox, you will need to install the LINSTOR Proxmox plugin.

7.3.1. Proxmox VE カーネル ヘッダーのインストール

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

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

pve-headers パッケージをインストールする前に、Proxmox PVE リポジトリを APT ソースリスト /etc/apt/sources.list に追加し apt update と入力します。 the Proxmox wiki を参照ください。

7.3.2. LINBIT カスタマーリポジトリを使用して Proxmox プラグインをインストール

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

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

# apt install drbd-utils linstor-proxmox drbd-dkms
ノードを LINBIT に登録し、LINBIT リポジトリを有効にする手順については LINBIT クラスターノードを管理するスクリプトの使用 を参照してください。

7.3.3. LINBIT 公開リポジトリを使用して Proxmox プラグインをインストール

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”):

# wget -O /tmp/package-signing-pubkey.asc \
# gpg --yes -o /etc/apt/trusted.gpg.d/linbit-keyring.gpg --dearmor \
# PVERS=7 && echo "deb [signed-by=/etc/apt/trusted.gpg.d/linbit-keyring.gpg] \ proxmox-$PVERS drbd-9" > /etc/apt/sources.list.d/linbit.list

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:

# apt update && apt -y install drbd-dkms drbd-utils linstor-proxmox

7.4. LINSTOR の構成

このガイドの残りの部分では クラスタの初期化 に基づいて LINSTOR クラスタが構成されていると仮定します。1 つのノードで “linstor-controller” を起動し、すべてのノードで “linstor-satellite” を起動します。”linstor-satellite” サービスには systemctl edit linstor-satellite.service で追加構成が必要です。


The preferred way to use the plugin, starting from version 4.1.0, is through LINSTOR resource groups and a single volume group within every resource group. LINSTOR resource groups are described in リソースグループを使用した LINSTOR プロビジョニングされたボリュームのデプロイ. All the required LINSTOR configuration (e.g., redundancy count) has to be set on the resource group.

7.5. Proxmox プラグインの構成

最後の手順ではProxmox自身を設定します。これは /etc/pve/storage.cfg に以下のような設定を加えることで行います。

drbd: drbdstorage
   content images,rootdir
   resourcegroup defaultpool

“drbd” は固定で変更できません。これによりProxmoxにストレージとしてDRBDを使用することを宣言します。 “drbdstorage” は変更可能で、Web GUI上で表示されるDRBDストレージの場所を示する名前です。”content” は固定で変更できません。 “redundancy” (リソースグループで設定される) はクラスタ内に保つ複製数を指定します。推奨値は 2 または 3 です。例えば5ノードをもつクラスタの場合、すべのノードがデータの3つの複製にアクセスできます。”controller” はLINSTORコントローラが動作するノードのIPアドレスを指定します。同時に1つのノードだけがLINSTORコントローラとして設定できます。このノードは現在動作していなければならず、すでに動作していない場合は、他のノードでLINSTORコントローラを動作させ、IPアドレスを変更しなければなりません。


drbd: drbdstorage
   content images,rootdir
   resourcegroup defaultpool

drbd: fastdrbd
   content images,rootdir
   resourcegroup ssd

drbd: slowdrbd
   content images,rootdir
   resourcegroup backup

これらの設定後、Web GUIでVMを作成し、ストレージとして “drbdstorage” もしくは他の定義されているプールを選択することでDRBDボリュームを使用できます。

Starting from version 5 of the plugin, you can set the option “preferlocal yes”. If it is set, the plugin tries to create a diskful assignment on the node that issued the storage create command. With this option you can ensure that the VM gets local storage if possible. Without that option LINSTOR might place the storage on nodes ‘B’ and ‘C’, while the VM is initially started on node ‘A’. This would still work as node ‘A’ then would get a diskless assignment, but having local storage might be preferred.

注意: DRBDは現時点で raw ディスクフォーマットのみをサポートします。

この時点で、VMのライブマイグレーションができます。すべてのノード(ディスクレスノードでも)ですべてのデータにアクセスできるため、わずか数秒で完了します。 VMに負荷がかかっていて、ダーティメモリが常に多い場合は、全体的な処理に少し時間がかかることがあります。しかし、いずれの場合でも、ダウンタイムは最小限で、中断は全く見られません。

Table 1. テーブル構成オプション
Option Meaning


The IP of the LINSTOR controller (‘,’ separated list allowed)


The name of a LINSTOR resource group which defines the deployment of new VMs. As described above


Prefer to create local storage (yes/no). As decribed above


Time in seconds status information is cached, 0 means no extra cache. Relevant on huge clusters with hundreds of resources. This has to be set on all drbd storages in /etc/pve/storage.cfg to take effect.


Path to the client certificate


Path to the client private key


Path to the CA certificate

7.6. コントローラの高可用性 (オプション構成)

LINSTOR を高可用性にするということは、LINSTOR コントローラーを高可用性にすることです。このステップはセクション 高可用性 LINSTOR