LINSTOR ユーザーズガイド

最初にお読みください

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

このガイドは全体を通して、あなたがLINSTORと関連ツールの最新版を使っていると仮定します。

このガイドは次のように構成されています。

LINSTOR

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

LINSTORはLinuxシステムのストレージの構成管理システムです。クラスターノードのLVM論理ボリュームとZFS ZVOLを管理します。異なるノード間の複製にDRBDを利用し、ユーザとアプリケーションにブロックストレージデバイスを供給します。LINSTORはスナップショット、暗号化、bcacheを通してSSDのHDDバックアップデータのキャッシュを管理します。

1.1. 概念と用語

このセクションでは、LINSTORがどのように機能し、ストレージを展開するかを理解するために必要である基本的な概念と用語について説明します。このセクションは基礎から築く方法で構成されています。

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

linstor-controller

LINSTOR のセットアップでは、少なくとも1つのアクティブコントローラと1つ以上のサテライトが必要です。

linstor-controller には、クラスター全体のすべての構成情報を保持するデータベースに依存しています。それはクラスタ全体の情報を持ち必要なすべての決定を下します。LINSTOR には複数のコントローラーを使用できますが、アクティブにできるのは1つだけです。

linstor-satellite

linstor-satellite はローカルストレージを供給する、または、ストレージをサービスとして供給するすべてのノードで実行され、必要なすべての情報をコントローラから受け取ります。lvcreatedrbdadm がそこで実行され、ノードエージェントのように振る舞います。

linstor-client

linstor-client はコマンドラインのユーティリティで、システムにコマンドを発行したり、ステータスを取得したりします。

1.1.2. オブジェクト

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

ノード

ノードは、LINSTORクラスタに参加するサーバーまたはコンテナです。ノード属性は、次のものを定義します。

  • ノードが参加しているLINSTORクラスターを決定します

  • ノードの役割を設定します:Controller、Satellite、Auxiliary

  • NetInterface オブジェクトはノードの接続を定義します

NetInterface

名前が示すように、これはノードのネットワークインターフェースのインターフェース/アドレスを定義します。

Definitions

Definitions はオブジェクトの属性を定義します。それらはプロファイルまたはテンプレートと考えることができます。作成されるオブジェクトは、definition で定義されている設定を継承します。関連オブジェクトを作成する前に definition を定義する必要があります。例えば Resource を作成する前に ResourceDefinition を作成する必要があります。

StoragePoolDefinition
  • ストレージプールの名前を定義します

ResourceDefinition

ResourceDefinition は、リソースの以下の属性を定義します。

  • DRBDリソースの名前

  • リソースの接続に使用するDRBDのTCPポート

VolumeDefinition

VolumeDefinition は以下を定義します。

  • DRBDリソースのボリューム

  • ボリュームのサイズ

  • DRBDリソースのボリュームのボリューム番号

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

  • DRBDボリュームに関連付けられているDRBDデバイスで使用するマイナー番号

StoragePool

StoragePool は、LINSTORのコンテキストでストレージを識別し、以下を定義します:

  • 特定のノード上のストレージプールの構成

  • クラスタノード上のストレージプールで使用するストレージバックエンドドライバ(LVM, ZFSなど)

  • ストレージバックアップドライバに渡すパラメータとその設定

リソース

LINSTORは、DRBDだけでなく、より幅広いストレージテクノロジを管理するように機能拡張されました。 リソースは

  • ResourceDefinition 内で定義される DRBDリソースの配備を表します。

  • クラスタ内のノードにリソースを配備します

  • ノード上の ResourceDefinition の配備を定義します

ボリューム

ボリュームはリソースのサブセットです。リソースには複数のボリュームを含めることができます。たとえば、データベースをMySQLクラスタ内のログよりも低速のストレージに格納したい場合があります。

ボリュームを単一のリソースの下に置くことで、本質的にコンシステンシグループを作成します。ボリューム属性は、より詳細なレベルで属性を定義することもできます。

1.2. よりハイレベルな適用

LINSTORはDRBD管理をより便利にするものとして使われる一方で、よりハイレベルなソフトウェアスタックとしても使われます。例えば、Kubernetes、OpenStack、OpenNebula、Proxmoxなどが該当します。これらの環境でLINSTORを使用するには専用の各章を参照ください。

LINSTORのサウスバウンドドライバには、LVM、thinLVM、ZFSがあり、Swordfishのサポートも現在開発中です。

1.3. パッケージ

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

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

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

これらのパッケージについての詳細は Installable Components を参照ください。

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

1.4. FIPS Compliance

“This standard shall be used in designing and implementing cryptographic modules…​” — NIST’s FIPS 140-3 publication

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

1.5. インストール

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

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

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

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

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

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

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

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

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

LINBIT Manage Nodes スクリプトのダウンロード

クラスターノードを LINBIT に登録し、LINBIT のリポジトリを構成するには、最初にノードの管理ヘルパー スクリプトをダウンロードしてから、すべてのクラスターノードで次のコマンドを入力して実行します。

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

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

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

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

ノード管理スクリプト内の最終タスク

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

終了する前に、スクリプトは、さまざまなユースケースにインストールできるパッケージ案に関するメッセージを表示します。

DEB ベースのシステムでは、コンパイル済みの DRBD カーネルモジュールパッケージ、 drbd-module-$(uname -r) 、またはカーネルモジュールのソース バージョン、 drbd-dkms をインストールできます。どちらか一方のパッケージをインストールしますが、両方はインストールしないでください。

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

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

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

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

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

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

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

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

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

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

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

1.6. LINSTOR のアップグレード

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

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

外部データベースまたはetcdを使用する場合は、現在のデータベースを手動でバックアップして復元ポイントを作成することをお勧めします。

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.

1.7. コンテナ

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

LINBIT のコンテナー イメージ リポジトリ (http://drbd.io) は、LINBIT のお客様、または LINBIT のお客様の試用アカウントを通じてのみ利用できます。価格についての情報や試用開始するには こちら を参照ください。また、LINSTOR SDS のアップストリームプロジェクト Piraeus は LINBIT の顧客ではなくてもを使用できます。

画像にアクセスするには、まずLINBITカスタマーポータルの認証情報を使ってレジストリにログインする必要があります。

# docker login drbd.io

このリポジトリで利用可能なコンテナは以下です。

  • drbd.io/drbd9-rhel8

  • drbd.io/drbd9-rhel7

  • drbd.io/drbd9-sles15sp1

  • drbd.io/drbd9-bionic

  • drbd.io/drbd9-focal

  • drbd.io/linstor-csi

  • drbd.io/linstor-controller

  • drbd.io/linstor-satellite

  • drbd.io/linstor-client

ブラウザで http://drbd.io にアクセスすると、バージョン番号付きの利用可能なイメージの最新のリストを取得できます。レジストリのイメージ自体は “https” で提供されてますが、 “http” でホストにアクセスしてください。

LINSTOR サテライトにのみ必要なカーネルモジュールをロードするには、特権モードで drbd9-$dist コンテナを実行する必要があります。カーネルモジュールのコンテナは、モジュールをカスタマーリポジトリの LINBIT 公式パッケージから取得するか、出荷済みパッケージを使用するか、コンテナ内でソースからビルドします。ソースからビルドする場合、カーネルのヘッダ(kernel-devel )をホストにインストールする必要があります。カーネルモジュールのコンテナを実行する方法は4つあります。

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

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

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

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

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

# docker run -it --rm --privileged -v /lib/modules:/lib/modules \
  -v /usr/src:/usr/src:ro \
  drbd.io/drbd9-rhel7

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

# docker run -it --rm --privileged -v /lib/modules:/lib/modules \
  drbd.io/drbd9-rhel8

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

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

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

# docker run -it --rm --privileged -v /lib/modules:/lib/modules \
  -v /etc/yum.repos.d/linbit.repo:/etc/yum.repos.d/linbit.repo:ro \
  drbd.io/drbd9-rhel7
どちらの場合でも(ハッシュ+ディストリビューションまたは既存のリポジトリ設定をバインドマウント)、これらが設定されたノードから使用する必要があります。これらの設定に関してはサポートにお問い合わせください。
今のところ(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 \
  --privileged drbd.io/linstor-satellite
コンテナ化された drbd-utils がネットワークを通してホストカーネルと通信できるようにするには net=host が必要です。

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

# docker run -d --name=linstor-controller -p 3370:3370 drbd.io/linstor-controller

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

# docker run -it --rm -e LS_CONTROLLERS=<controller-host-IP-address> \
  drbd.io/linstor-client node list

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

デーモン化されたコンテナとイメージを停止して削除します。

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

1.8. クラスタの初期化

以下の手順がすべてのクラスタノードですでに実行されていると仮定します。

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

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

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

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

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

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

# systemctl enable --now linstor-controller

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

LINSTORコマンドラインクライアントを実行するときは、常にlinstor-controllerがどこで実行されているか知る必要があります。何も指定してないときは、IP 127.0.0.1 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 ファイルを作成して、以下のように追加することもできます。

[global]
controllers=alice

複数のlinstorコントローラが設定されている場合は、それらをカンマ区切りで指定します。linstor-clientはそれらをリストされた順番で試します。

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

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

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

# linstor node create bravo 10.43.70.3

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を起動します。

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

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

1.11. ストレージプール

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

ストレージを作成するために、LVM VGまたはZFS zPoolのどちらかを作成する必要があります。LINSTORストレージプール名とともに識別されるVGsやzPools名は、各ホストで別の名前にすることも可能ですが、すべてのノードで同じにすることを推奨します。

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

次にこれらは以下のコマンドでLINSTORに登録します。

# linstor storage-pool create lvm alpha pool_ssd vg_ssd
# linstor storage-pool create lvm bravo pool_ssd vg_ssd
ストレージプール名は ストレージプール定義 として参照されます。上記コマンドはストレージプール定義を暗黙的に作成します。 linstor storage-pool-definition list を使って確認できます。明示的にストレージプール定義を作成することも可能ですが、必須ではありません。

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

# linstor storage-pool list

またはショートバージョンを使います。

# linstor sp l

まだ動作中のリソースまたはスナップショットがアタッチされていて、ストレージプールの削除ができない場合は、対応方法のヒントが関連する list コマンドの status 項に表示されます(例: linstor resource list )。削除されたストレージプールの LINSTOR オブジェクトを手動で削除した後、再度 lost コマンドを実行することで、ストレージプールとその残りのオブジェクトを確実に削除することができます。

1.11.1. 障害ドメインを単一の下位デバイスに限定する

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

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

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 プールのシリアル番号を使用します。

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

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

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

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

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

リソースグループはリソース定義の親オブジェクトであり、リソースグループで行われたすべてのプロパティ変更はそのリソース定義の子によって継承されます。リソースグループは自動配置ルールの設定も可能で、このルールに依存するリソース定義を生成できます。

言いかえると、リソースグループは、それらから作成されるリソースの特性を定義するテンプレートのようなものです。これらの擬似テンプレートへの変更は、リソースグループから作成されたすべてのリソースにさかのぼって適用されます。

リソースグループを使用して、リソースのプロビジョニング方法を定義することは、 LINSTOR によってプロビジョニングするボリュームをデプロイするための事実上標準の方法と見なされます。resource-definitionvolume-definition から各 resource を作成する方法は、特別なシナリオでのみで使用してください。
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
  done

上記のコマンドを実行すると、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 より優先されます。

1.13. クラスターの構成

1.13.1. Available Storage Plug-ins

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

  • Thick LVM

  • 単一の thin プールの Thin LVM

  • Thick ZFS

  • Thin ZFS

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

以下の例では、500 GBのサイズをもつリソースを作成し、3つのクラスタノード間で複製されるというシナリオを紹介します。

最初に新しいリソースの定義を作成します。

# linstor resource-definition create backups

次にこのリソースをもつ新しいボリュームの定義を作成します。

# linstor volume-definition create backups 500G

volume-definition のサイズを変更したい場合は、次のようにして簡単に行うことができます。

# linstor volume-definition set-size backups 0 100G

パラメータ 0 は、リソース backups 内のボリュームの番号である。リソースは複数のボリュームを持つことができ、それらはボリューム番号で識別されるため、このパラメーターを指定する必要があります。この番号は、volume-definition をリストすることによって見つけることができます。

volume-definition のサイズは、リソースがない場合にのみ減らすことができます。増やす場合はデプロイされたリソースに対しても可能です。

ここまではLINSTORのデータベースにオブジェクトが作成されただけで、ストレージノードのLVには作成されていません。この後はLINSTORに配備作業を委任するか自分でやるか選択できます。

1.14.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

1.14.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はエラーメッセージとともにコマンドを拒否します。

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

# 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

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

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

同一人物に対する複製という制約のため、LINSTORは生成されたリソースをサテライトノード node-1 に配置しませんでした。 サテライトノード node-1 の補助ノードプロパティ testProperty の値は 0 であり、1 ではなかったからです。 0` であり、1 ではないためです。

list-properties` コマンドを使用すると、node-1 のノードプロパティを確認することができます。

# 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 コマンドでは有効ではありません。 これは、このコマンドはリソースをデプロイせず、後でデプロイするためのテンプレートを作成する だけだからです。

LINSTORレイヤーまたはストレージプールプロバイダによるリソースの自動配置の制約

引数 --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のストレージプール選択ストラテジーなど のストレージプール選択戦略などの要素を使用します。

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

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

1.15.1. リソース定義の削除

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

# linstor resource-definition delete <resource_definition_name>

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

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

1.15.2. リソースの削除

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

# linstor resource delete <node_name> <resource_name>

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

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

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

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

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

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

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

# linstor resource-group delete <resource_group_name>

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

ERROR:
Description:
    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. LINSTOR 応用タスク

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

デフォルトでは、LINSTOR クラスターは 1 つの LINSTOR コントローラーで構成されます。LINSTOR の高可用性を実現するには、コントローラーデータベースの複製されたストレージ、一度に 1 つだけがアクティブになる複数の LINSTOR コントローラー、および高可用性ストレージのマウント/アンマウントと LINSTOR コントローラーの開始/停止を処理するサービスマネージャーを提供する必要があります。

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

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

# linstor resource-definition create linstor_db # linstor
resource-definition drbd-options --on-no-quorum=io-error linstor_db #
linstor resource-definition drbd-options --auto-promote=no linstor_db #
linstor volume-definition create linstor_db 200M # linstor resource create
linstor_db -s pool1 --auto-place 3

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

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

# systemctl disable --now linstor-controller

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

[Mount]
# 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

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

2.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 を設定してください。

2.1.3. サービスの管理

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

[[promoter]]
id = "linstor_db"
[promoter.resources.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
[Service]
Environment=LS_KEEP_RES=linstor_db

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

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

2.2. DRBDクライアント

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

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

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

コンシステンシグループはDRBDの機能の1つです。LINSTORの主な機能の1つがDRBDを使用してストレージクラスタを管理することです。1つのリソース内の複数のボリュームがコンシステンシグループになります。

これは、1つのリソースで異なるボリュームに対する変更が他のサテライトでも同じ順番で複製されることを意味します。

したがって、リソース内の異なるボリュームに相互依存データがある場合は、タイミングを気にする必要はありません。

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

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

2.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’という名前のストレージプールを見つけられなかった というエラーメッセージを受け取ることを意味します。

2.5. DRBDを使わないLINSTOR

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",

次の表は、どのレイヤーの後にどの子レイヤーが続くかを示しています。

[cols=”>1,<5″]

Layer

Child layer

DRBD

CACHE, WRITECACHE, NVME, LUKS, STORAGE

CACHE

WRITECACHE, NVME, LUKS, STORAGE

WRITECACHE

CACHE, NVME, LUKS, STORAGE

NVME

CACHE, WRITECACHE, LUKS, STORAGE

LUKS

STORAGE

STORAGE

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

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

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

NVMe-oF はRDMA対応ネットワークでのみ動作し、NVMe-TCP はIPトラフィックを伝送できるすべてのネットワークで動作します。 NVMe-oF/NVMe-TCP の詳細については、https://www.linbit.com/en/nvme-linstor-swordfish/ を参照ください。

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

Ubuntu を使用していない場合は、OS にパッケージをインストールするための適切なコマンドを使用してください – SLES: zypper; RHEL-family: dnf
# apt install nvme-cli

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で問題が発生する可能性があります。

2.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 192.168.166.7 000af795789d

引数は次のとおりです。

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

  • 192.168.166.7 は提供された 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 10.43.7.185
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 192.168.166.7 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
ノードが linstor controller set-property StorDriver/Openflex/ApiHost 10.43.7.185 で指定されたものとは異なるホストの OpenFlex REST API にアクセスする場合、プロパティに対して常に LINSTOR の継承メカニズムを使用できます。つまり、必要なノードレベルで同じプロパティ linstor node set-property ofNode1 StorDriver/Openflex/ApiHost 10.43.8.185 を定義するだけです。

2.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 を使用すると、外部メタデータを保持するデバイスではなく、下位デバイスのみが書き込みキャッシュを使用します。

2.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 を使用すると、外部メタデータを保持するデバイスではなく、下位デバイスのみがキャッシュを使用します。

2.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 ストレージプロバイダーに対してのみ有効になっています。

2.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 を参照ください。

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

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

$ linstor node create-remote-spdk-target nodeName 192.168.1.110

これにより、コントローラーと同じマシンで実行されている新しいサテライトインスタンスが開始されます。この特別なサテライトは、リモート 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]
                                              [--external-locking]
                                              node_name name driver_pool_name

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

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

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

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

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

既存のノードの場合、次のように追加のネットインターフェイスが作成されます。

# linstor node interface create node-0 10G_nic 192.168.43.231

ネットインターフェイスは 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 the above methods can re-route DRBD traffic, and LINSTOR communication between the controller and satellite nodes, it is not possible through linstor commands only, to route LINSTOR controller-client traffic (commands that you issue from a LINSTOR client to the controller) through a specific NIC. To achieve this, you can either:

  1. LINSTORクライアントの使用 で説明されている方法で LINSTOR コントローラーを指定し、コントローラーとクライアントのトラフィックに使用する NIC を経由するように指定されたコントローラーへのルートを持つだけにする。

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

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

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

# linstor node interface create alpha nic1 192.168.43.221
# linstor node interface create alpha nic2 192.168.44.221
# linstor node interface create bravo nic1 192.168.43.222
# linstor node interface create bravo nic2 192.168.44.222

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

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

resource myResource {
  ...
  connection {
    path {
      host alpha address 192.168.43.221:7000;
      host bravo address 192.168.43.222:7000;
    }
    path {
      host alpha address 192.168.44.221:7000;
      host bravo address 192.168.44.222:7000;
    }
  }
}
ノードインタフェースの作成時にLINSTOR衛星トラフィックに使用するポート番号を指定できますが、DRBDリソース接続パスの作成時には、このポート番号は無視されます。代わりに、コマンドはポート番号を動的に割り当てます。

2.8. 暗号化ボリューム

LINSTORはDRBDボリュームの暗号化を透過的に扱うことができます。dm-cryptがストレージデバイスから提供されるストレージを暗号化するのに使われます。

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

暗号化の基本的な手順は以下になります。

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

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

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

2.8.1. 暗号化のコマンド

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

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

# 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
linstor-controllerが再起動したときは、コントローラにマスターパスフェーズを常に入力する必要があります。そうしないとLINSTORは暗号化されたボリュームをオープンしたり作成したりできません。

2.8.2. 自動パスフレーズ

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

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

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

[encrypt]
passphrase="example"

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

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

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

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

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

2.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> コマンドを使用して、クラスタからノードを削除します。

2.10.1. 複数のノードの退避

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

# linstor node set-property <node_name> AutoplaceTarget false

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

2.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 コマンドを使用できます。

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

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

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

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

# linstor snapshot create resource1 snap1

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

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

2.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) を参照ください。

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

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

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

# linstor snapshot rollback resource1 snap1

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

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

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

# linstor snapshot delete resource1 snap1

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

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

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

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

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

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

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

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

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

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

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

# linstor remote create linstor myRemote 192.168.0.15

さらに、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 \
--cluster-id <SOURCE_CLUSTER_ID> --passphrase <SOURCE_CONTROLLER_PASSPHRASE> <NAME> <URL>

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 \
--cluster-id <TARGET_CLUSTER_ID> --passphrase <TARGET_CONTROLLER_PASSPHRASE> <NAME> <URL>
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 オプションを指定した場合も同様です。

同じクラスター内へのスナップショットの転送

ソースノードとターゲットノードの両方に、デプロイされたスナップショット転送のリソースをもつ必要があります。さらに、ターゲットリソースを非アクティブ化する必要があります。

# 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

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

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

定期的なバックアップの配信は、3つのパートで構成されています。

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

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

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

LINSTORバックアップの配信は、LVMとZFSストレージプールにバックアップされたLINSTORリソースに対してのみ機能します。これは、LINSTORでスナップショットをサポートするストレージプールタイプであるためです。

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

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

最低限、このコマンドはバックアップ出荷スケジュールを作成するために、スケジュール名とフルバックアップ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)
cronスキーマは一重引用符または二重引用符で囲んでください。
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がどの程度の頻度でスナップショットを作成し、フルバックアップを出荷するかを記述しています。
増分cronスキーマを指定した場合、フルcronスキーマと重複しているため、両方のバックアップが同時に行われる場合、LINSTORはフルバックアップのみを作成し、出荷します。例えば、3時間ごとにフルバックアップを行い、1時間ごとに増分バックアップを行うように指定した場合、3時間ごとにLINSTORはフルバックアップのみを作成し出荷します。この理由から、増分バックアップとフルバックアップの出荷スケジュールの両方に同じcronスキーマを指定しても、増分バックアップは決して作成されないため、意味がありません。

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

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

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

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

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

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スナップショットを削除する場合、LINSTORはそれが予定されていたすべてを削除することができない場合があります。例えば、フルバックアップのスナップショット定義を削除した場合、後のフルバックアップのスケジュール配信時に、手動で削除したフルバックアップスナップショットに基づくインクリメンタルスナップショットが削除されないことがあります。

Keep-remoteオプションの設定

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

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

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

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

For example:

# linstor schedule list
╭──────────────────────────────────────────────────────────────────────────────────────╮
┊ Name                ┊ Full        ┊ Incremental ┊ KeepLocal ┊ KeepRemote ┊ OnFailure ┊
╞══════════════════════════════════════════════════════════════════════════════════════╡
┊ my-bu-schedule      ┊ 2 * * * *   ┊             ┊ 3         ┊ 2          ┊ SKIP      ┊
╰──────────────────────────────────────────────────────────────────────────────────────╯

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

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

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

2.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]

2.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リソースに適用されます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

linstor controller backup schedule decision flowchart

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

  1. リソース定義レベル

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

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

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

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

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

このコマンドは、どの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    ┊
╰───────────────────────────────────────────────────────────────────────────╯

2.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

2.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 192.168.222.10:7000;
            _remote_host ipv4 192.168.222.11:7000;
        }
        path {
            _this_host ipv4 192.168.121.46:7000;
            _remote_host ipv4 192.168.121.220:7000;
        }
        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.

2.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.

2.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                |
[...]
  [[s-linstor-unset-opts]]
==== 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.  [[s-linstor-toggle-disk]]
=== ディスクの追加と削除

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
  [[s-linstor-migrate-disk]]
==== ノード間でのディスクの移行

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
  [[s-linstor-proxy]]
=== LINSTOR を使用した DRBD プロキシの構成

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
Please contact LINBIT for assistance optimizing your configuration.

2.13.4. 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.  [[s-linstor-external-database]]
=== 外部データベースプロバイダー
  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`.  [[s-postgresql]]
==== PostgreSQL

A sample PostgreSQL linstor.toml looks like this:

[db]
user = "linstor"
password = "linstor"
connection_url = "jdbc:postgresql://localhost/linstor"
  [[s-mariadb_mysql]]
==== MariaDB and MySQL

A sample MariaDB linstor.toml looks like this:

[db]
user = "linstor"
password = "linstor"
connection_url = "jdbc:mariadb://localhost/LINSTOR?createDatabaseIfNotExist=true"
  NOTE: 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.  [[s-etcd]]
==== 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:

[db]
## 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"
  [[s-linstor-controller-config]]
=== 複数の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:
https://github.com/LINBIT/linstor-server/blob/master/docs/linstor.toml-example[linstor.toml-example]

2.13.5. 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.

[http]
  enabled = true
  port = 3370
  listen_addr = "127.0.0.1"  # to disable remote access
  If you want to use the REST API the current documentation can be found on
the following link: https://app.swaggerhub.com/apis-docs/Linstor/Linstor/

2.13.6. 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:

[https]
  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:
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html
NOTE: When HTTPS is enabled, all requests to the HTTP /v1/ REST API will be
redirected to the HTTPS redirect.  [[s-rest-api-https-restricted-client]]
===== 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:

[https]
  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 <<s-using_the_linstor_client>> for more details.

2.14. 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:
https://github.com/LINBIT/linstor-server/blob/master/docs/linstor_satellite.toml-example[linstor_satellite.toml-example]

2.15. ロギング

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:

    [logging]
       level="TRACE"
  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
     https://logback.qos.ch/manual/configuration.html
    -->
     <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
       <!-- encoders are assigned the type
            ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
       <encoder>
         <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern>
       </encoder>
     </appender>
     <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
       <file>${log.directory}/linstor-${log.module}.log</file>
       <append>true</append>
       <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
         <Pattern>%d{yyyy_MM_dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</Pattern>
       </encoder>
       <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
         <FileNamePattern>logs/linstor-${log.module}.%i.log.zip</FileNamePattern>
         <MinIndex>1</MinIndex>
         <MaxIndex>10</MaxIndex>
       </rollingPolicy>
       <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
         <MaxFileSize>2MB</MaxFileSize>
       </triggeringPolicy>
     </appender>
     <logger name="LINSTOR/Controller" level="TRACE" additivity="false">
       <appender-ref ref="STDOUT" />
       <!-- <appender-ref ref="FILE" /> -->
     </logger>
     <logger name="LINSTOR/Satellite" level="TRACE" additivity="false">
       <appender-ref ref="STDOUT" />
       <!-- <appender-ref ref="FILE" /> -->
     </logger>
     <root level="WARN">
       <appender-ref ref="STDOUT" />
       <!-- <appender-ref ref="FILE" /> -->
     </root>
    </configuration>
      See the https://logback.qos.ch/manual/index.html[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

2.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`.  [[s-linstor-secure-connections]]
=== サテライトへの安全な接続

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 [email protected] mkdir /etc/linstor/ssl
scp alpha/* [email protected]:/etc/linstor/ssl/
ssh [email protected] mkdir /etc/linstor/ssl
scp bravo/* [email protected]:/etc/linstor/ssl/
ssh [email protected] mkdir /etc/linstor/ssl
scp charlie/* [email protected]:/etc/linstor/ssl/

# generate the satellite ssl config entry
echo '[netcom]
  type="ssl"
  port=3367
  server_certificate="ssl/keystore.jks"
  trusted_certificates="ssl/certificates.jks"
  key_password="linstor"
  keystore_password="linstor"
  truststore_password="linstor"
  ssl_protocol="TLSv1.2"
' | ssh [email protected] "cat > /etc/linstor/linstor_satellite.toml"

echo '[netcom]
  type="ssl"
  port=3367
  server_certificate="ssl/keystore.jks"
  trusted_certificates="ssl/certificates.jks"
  key_password="linstor"
  keystore_password="linstor"
  truststore_password="linstor"
  ssl_protocol="TLSv1.2"
' | ssh [email protected] "cat > /etc/linstor/linstor_satellite.toml"
  Now just start controller and satellites and add the nodes with
`--communication-type SSL`.  [[s-linstor-ldap-authentication]]
=== 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:

[ldap]
  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://ldap.example.com"

  # 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))"
  WARNING: It is highly recommended that you configure
<<s-linstor-rest-api-https,LINSTOR REST API HTTPS>> and LDAPS to protect
potentially sensitive traffic passing between the LINSTOR Controller and an
LDAP server.

2.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.  [[s-linstor-drbd-automatisms]]
=== Automatisms for DRBD Resources
  This section details some of LINSTOR's automatisms for DRBD resources.

2.15.3. 自動クォーラムポリシー

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
  NOTE: Setting `DrbdOptions/Resource/on-no-quorum` to an empty value in the
commands above deletes the property from the object entirely.

2.15.4. 自動取り除き

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.  [[s-linstor-auto-diskful]]
==== 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.  [[s-linstor-auto-diskful-setting]]
===== 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
  [[s-linstor-auto-diskful-setting-on-rg-or-controller]]
===== 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 [[s-linstor-auto-diskful-unsetting]]
===== Unsetting the Auto-Diskful Option

To unset the LINSTOR auto-diskful option, enter:

# linstor <controller|resource-definition|resource-group> set-property DrbdOptions/auto-diskful
  [[s-linstor-auto-diskful-allow-cleanup-setting]]
===== 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

cgroup/blkio/blkio.throttle.read_bps_device

sys/fs/blkio_throttle_read

cgroup/blkio/blkio.throttle.write_bps_device

sys/fs/blkio_throttle_write

cgroup/blkio/blkio.throttle.read_iops_device

sys/fs/blkio_throttle_read_iops

cgroup/blkio/blkio.throttle.write_iops_device

sys/fs/blkio_throttle_write_iops

2.15.5. 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

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

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

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

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

2.15.7. NVMe の QoS設定

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

2.16. ヘルプの利用

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

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

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

# linstor node list -h
# linstor help node list

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

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

# 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

2.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 ファイルに保存されます。

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

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

2.16.4. GitHub

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

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

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

3. Kubernetes で LINSTOR ボリューム

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

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

3.1. Kubernetesの概要

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

3.2. Kubernetes への LINSTOR のデプロイ

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

LINBIT’s container image repository (https://drbd.io), 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.

3.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 drbd.io 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.

Listing 1. kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: linbit-sds
resources:
  - https://github.com/LINBIT/linstor-operator-builder//deploy/default?ref=v2.0.1
generatorOptions:
  disableNameSuffixHash: true
secretGenerator:
  - name: drbdio-pull-secret
    type: kubernetes.io/dockerconfigjson
    literals:
      - .dockerconfigjson={"auths":{"drbd.io":{"username":"MY_LINBIT_USER","password":"MY_LINBIT_PASSWORD"}}}

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 a simple as creating a new LinstorCluster resource and waiting for the Operator to complete the setup:

$ kubectl create -f - <<EOF
apiVersion: piraeus.io/v1
kind: LinstorCluster
metadata:
  name: linstorcluster
spec: {}
EOF
$ 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
apiVersion: piraeus.io/v1
kind: LinstorSatelliteConfiguration
metadata:
  name: storage-pool
spec:
  storagePools:
    - name: pool1
      fileThinPool:
        directory: /var/lib/linbit-sds/pool1
EOF

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.

3.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:

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

    kubectl create secret docker-registry drbdiocred --docker-server=drbd.io \
      --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 を使用して、適切なカーネルモジュールインジェクタを選択します。

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

      operator.satelliteSet.kernelModuleInjectionImage=drbd.io/drbd9-rhel8:v9.1.8
    • ホストマシンに既に存在するモジュールのみを挿入します。モジュールが見つからない場合は、スキップされます。

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

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

    helm repo add linstor https://charts.linstor.io
    helm install linstor-op linstor/linstor

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

LINSTOR向けKubernetesバックエンド

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

Listing 2. k8s-backend.yaml
etcd:
  enabled: false
operator:
  controller:
    dbConnectionURL: k8s
現在、etcd バックエンドを持つ既存のクラスタから Kubernetes バックエンドへの移行できません。
永続ストレージボリュームの作成

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

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

helm repo add linstor https://charts.linstor.io
helm install linstor-etcd linstor/pv-hostpath

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

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

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

POSTGRES_DB: postgresdb
POSTGRES_USER: postgresadmin
POSTGRES_PASSWORD: admin123

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

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

3.2.3. ストレージの構成

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

ストレージプール作成の構成

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

$ kubectl get LinstorSatelliteSet.linstor.linbit.com linstor-op-ns -o yaml
kind: LinstorSatelliteSet
metadata:
..
spec:
  ..
  storagePools:
    lvmPools:
    - name: lvm-thick
      volumeGroup: drbdpool
    lvmThinPools:
    - name: lvm-thin
      thinVolume: thinpool
      volumeGroup: ""
    zfsPools:
    - name: my-linstor-zpool
      zPool: for-linstor
      thin: true
インストール時のストレージプール作成

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

まず、次のようなストレージ構成でファイルを作成します。

operator:
  satelliteSet:
    storagePools:
      lvmPools:
      - name: lvm-thick
        volumeGroup: drbdpool

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

helm install -f <file> linstor-op linstor/linstor
ストレージプール作成の構成

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

$ kubectl edit LinstorSatelliteSet.linstor.linbit.com <satellitesetname>

ストレージプールの構成は、上記の例のように更新できます。

物理デバイスの準備

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

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

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

  • 1 GiB 以上である。

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

  storagePools:
    lvmPools:
    - name: lvm-thick
      volumeGroup: drbdpool
      devicePaths:
      - /dev/vdb
    lvmThinPools:
    - name: lvm-thin
      thinVolume: thinpool
      volumeGroup: linstor_thinpool
      devicePaths:
      - /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 ベースストレージプールを作成 ( 未テスト )

3.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

このオプションが有効な場合、上記のセクションで指定されたシークレットには、2つの追加キーが含まれている必要があります。

  • 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を用いた鍵、証明書の生成

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

Helmのオーバーライドファイルで以下のオプションを設定します。

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

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"

秘密鍵を作成します。コントローラ用に2つ、全ノード用に1つ、全クライアント用に1つ作成します。

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 \
  subjectAltName=DNS:linstor-op-cs.default.svc)
最後のコマンドの linstor-op-cs.default.svc は create service 名と一致させる必要があります。Helm では、これは常に <release-name>-cs.<namespace>.svc になります。

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

kubectl create secret generic linstor-control --type=kubernetes.io/tls \
  --from-file=ca.crt=ca.crt --from-file=tls.crt=linstor-control.crt \
  --from-file=tls.key=linstor-control.key
kubectl create secret generic linstor-satellite --type=kubernetes.io/tls \
  --from-file=ca.crt=ca.crt --from-file=tls.crt=linstor-satellite.crt \
  --from-file=tls.key=linstor-satellite.key
kubectl create secret generic linstor-api --type=kubernetes.io/tls \
  --from-file=ca.crt=client-ca.crt --from-file=tls.crt=linstor-api.crt \
  --from-file=tls.key=linstor-api.key
kubectl create secret generic linstor-client --type=kubernetes.io/tls \
  --from-file=ca.crt=client-ca.crt --from-file=tls.crt=linstor-client.crt \
  --from-file=tls.key=linstor-client.key

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

linstorHttpsControllerSecret: linstor-api
linstorHttpsClientSecret: linstor-client
operator:
  controller:
    sslSecret: linstor-control
  satelliteSet:
    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 ファイルを使用しています。用途や環境に合わせて調整してください。詳細は <ストレージプール作成の構成> を参照ください。

operator:
  satelliteSet:
    storagePools:
      lvmThinPools:
      - name: lvm-thin
        thinVolume: thinpool
        volumeGroup: ""
        devicePaths:
        - /dev/sdb

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

警告:これは、テスト以外での使用は推奨されていません。
kubectl create secret docker-registry drbdiocred --docker-server=drbd.io \
  --docker-username=<YOUR_LOGIN> --docker-password=<YOUR_PASSWORD>
helm repo add linstor https://charts.linstor.io
helm install linstor-op linstor/linstor
これ以降 kubectl create コマンドで使用される LINBIT のコンテナーイメージリポジトリ (http://drbd.io) は、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-server=drbd.io \
  --docker-username=<YOUR_LOGIN> --docker-password=<YOUR_PASSWORD>
helm repo add linstor https://charts.linstor.io
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-server=drbd.io \
  --docker-username=<YOUR_LOGIN> --docker-email=<YOUR_EMAIL> --docker-password=<YOUR_PASSWORD>
helm repo add linstor https://charts.linstor.io
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=="linstor.csi.linbit.com")]}kubectl delete pvc --namespace {.metadata.namespace} {.metadata.name}{"\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 の現状に関しては こちら を参照ください。

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

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

以下の Helm チャートで使用される LINBIT のコンテナーイメージリポジトリ (http://drbd.io) は、LINBIT のお客様または LINBIT のお客様の試用アカウントを通じてのみ利用できます。価格についての情報や試用開始するには こちら を参照ください。また、LINSTOR SDS のアップストリームプロジェクト Piraeus は LINBIT の顧客ではなくてもを使用できます。
global:
  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
etcd:
  enabled: true
  persistentVolume:
    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)
  image:
    repository: gcr.io/etcd-development/etcd
    tag: v3.4.15
stork:
  enabled: false
  storkImage: docker.io/openstorage/stork:2.8.2
  schedulerImage: k8s.gcr.io/kube-scheduler-amd64
  schedulerTag: ""
  replicas: 1 (2)
  storkResources: {} # resources requirements for the stork plug-in containers (3)
  schedulerResources: {} # resource requirements for the kube-scheduler containers (3)
  podsecuritycontext: {}
csi:
  enabled: true
  pluginImage: "drbd.io/linstor-csi:v0.20.0"
  csiAttacherImage: k8s.gcr.io/sig-storage/csi-attacher:v4.0.0
  csiLivenessProbeImage: k8s.gcr.io/sig-storage/livenessprobe:v2.7.0
  csiNodeDriverRegistrarImage: k8s.gcr.io/sig-storage/csi-node-driver-registrar:v2.5.1
  csiProvisionerImage: k8s.gcr.io/sig-storage/csi-provisioner:v3.2.1
  csiSnapshotterImage: k8s.gcr.io/sig-storage/csi-snapshotter:v6.0.1
  csiResizerImage: k8s.gcr.io/sig-storage/csi-resizer:v1.6.0
  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/security.md
linstorHttpsClientSecret: "" # <- name of secret containing linstor client certificates+key. See docs/security.md
controllerEndpoint: "" # <- override to the generated controller endpoint. use if controller is not deployed via operator
psp:
  privilegedRole: ""
  unprivilegedRole: ""
operator:
  replicas: 1 # <- number of replicas for the operator deployment (2)
  image: "drbd.io/linstor-operator:v1.10.0"
  affinity: {} (4)
  tolerations: [] (4)
  resources: {} (3)
  customLabels: {}
  customAnnotations: {}
  podsecuritycontext: {}
  args:
    createBackups: true
    createMonitoring: true
  sidecars: []
  extraVolumes: []
  controller:
    enabled: true
    controllerImage: "drbd.io/linstor-controller:v1.20.0"
    dbConnectionURL: ""
    luksSecret: ""
    dbCertSecret: ""
    dbUseClientCert: false
    sslSecret: ""
    affinity: {} (4)
    httpBindAddress: ""
    httpsBindAddress: ""
    tolerations: (4)
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
    resources: {} (3)
    replicas: 1 (2)
    additionalEnv: [] (5)
    additionalProperties: {} (6)
    sidecars: []
    extraVolumes: []
    customLabels: {}
    customAnnotations: {}
  satelliteSet:
    enabled: true
    satelliteImage: "drbd.io/linstor-satellite:v1.20.0"
    storagePools: {}
    sslSecret: ""
    automaticStorageType: None
    affinity: {} (4)
    tolerations: [] (4)
    resources: {} (3)
    monitoringImage: "drbd.io/drbd-reactor:v0.9.0"
    monitoringBindAddress: ""
    mountDrbdResourceDirectoriesFromHost: false (10)
    kernelModuleInjectionImage: "drbd.io/drbd9-rhel7:v9.1.11"
    kernelModuleInjectionMode: ShippedModules
    kernelModuleInjectionAdditionalSourceDirectory: "" (8)
    kernelModuleInjectionResources: {} (3)
    kernelModuleInjectionExtraVolumeMounts: []
    additionalEnv: [] (5)
    sidecars: []
    extraVolumes: []
    customLabels: {}
    customAnnotations: {}
haController:
  enabled: false
  image: drbd.io/linstor-k8s-ha-controller:v0.3.0
  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 (ディレクトリ)

    すべてのファイルとディレクトリは、ホスト上にすでに存在している必要があります。

高可用性デプロイメント

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

3.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"" に設定します。

3.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 エンドポイント。 例えば http://linstor.storage.cluster:3370/

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

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

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

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: linstor-on-k8s
provisioner: linstor.csi.linbit.com
parameters:
  autoPlace: "3"
  storagePool: existing-storage-pool
  resourceGroup: linstor-on-k8s

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

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

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

3.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  ┊ 10.43.224.26:3366 (PLAIN)   ┊ Online ┊
┊ kube-node-02.test              ┊ SATELLITE  ┊ 10.43.224.27:3366 (PLAIN)   ┊ Online ┊
┊ kube-node-03.test              ┊ SATELLITE  ┊ 10.43.224.28:3366 (PLAIN)   ┊ Online ┊
┊ linstor-op-cs-controller-[...] ┊ CONTROLLER ┊ 172.24.116.114:3366 (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> 形式の参照をポッドで使用中のリソースリストへ展開します。

これは、問題を調査し、高度な機能にアクセスするためにのみ必要です。ボリュームの作成などの通常の操作は Kubernetes の操作 を参照ください。

3.4. 基本的な構成とデプロイメント

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

Kubernetes を介してデプロイされた LINSTOR ボリュームの動作とプロパティの構成は StorageClasses を使用して行います。

“resourceGroup” パラメータは必須です。通常、一意にしてストレージクラス名と同じにします。

以下は、ボリュームのデプロイに使用できる最も単純で実用的な StorageClass です。

Listing 3. linstor-basic-sc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  # The name used to identify this StorageClass.
  name: linstor-basic-storage-class
  # The name used to match this StorageClass with a provisioner.
  # linstor.csi.linbit.com is the name that the LINSTOR CSI plug-in uses to identify itself
provisioner: linstor.csi.linbit.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  # 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
  csi.storage.k8s.io/fstype: 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 4. my-first-linstor-volume-pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: my-first-linstor-volume
spec:
  storageClassName: linstor-basic-storage-class
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      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
metadata:
  name: fedora
  namespace: default
spec:
  containers:
  - name: fedora
    image: fedora
    command: [/bin/bash]
    args: ["-c", "while true; do sleep 10; done"]
    volumeMounts:
    - name: my-first-linstor-volume
      mountPath: /data
    ports:
    - containerPort: 80
  volumes:
  - name: my-first-linstor-volume
    persistentVolumeClaim:
      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ボリュームを削除する。

3.4.1. StorageClass で使用可能なパラメータ

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

linstor.csi.linbit.com/ はオプションですが、LINSTOR CSI 固有のパラメーターのプレフィックスとして推奨されます。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: full-example
provisioner: linstor.csi.linbit.com
parameters:
  # CSI related parameters
  csi.storage.k8s.io/fstype: xfs
  # LINSTOR parameters
  linstor.csi.linbit.com/autoPlace: "2"
  linstor.csi.linbit.com/placementCount: "2"
  linstor.csi.linbit.com/resourceGroup: "full-example"
  linstor.csi.linbit.com/storagePool: "my-storage-pool"
  linstor.csi.linbit.com/disklessStoragePool: "DfltDisklessStorPool"
  linstor.csi.linbit.com/layerList: "drbd storage"
  linstor.csi.linbit.com/placementPolicy: "AutoPlaceTopology"
  linstor.csi.linbit.com/allowRemoteVolumeAccess: "true"
  linstor.csi.linbit.com/encryption: "true"
  linstor.csi.linbit.com/nodeList: "diskful-a diskful-b"
  linstor.csi.linbit.com/clientList: "diskless-a diskless-b"
  linstor.csi.linbit.com/replicasOnSame: "zone=a"
  linstor.csi.linbit.com/replicasOnDifferent: "rack"
  linstor.csi.linbit.com/disklessOnRemaining: "false"
  linstor.csi.linbit.com/doNotPlaceWithRegex: "tainted.*"
  linstor.csi.linbit.com/fsOpts: "-E nodiscard"
  linstor.csi.linbit.com/mountOpts: "noatime"
  linstor.csi.linbit.com/postMountXfsOpts: "extsize 2m"
  # Linstor properties
  property.linstor.csi.linbit.com/*: <x>
  # DRBD parameters
  DrbdOptions/*: <x>

3.4.2. csi.storage.k8s.io/fstype

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

  • ext4 (デフォルト)

  • xfs

3.4.3. autoPlace

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

このオプションを使用する場合は、 nodeList を使用しないでください。
引用符を使用する必要があります。そうしないと、Kubernetes は不正な形式の StorageClass について文句を言います。
このオプション(および自動配置の動作に影響を与えるすべてのオプション)は、ボリューム用のストレージがプロビジョニングされるLINSTORノードの数を変更し、 kubelets からこれらのボリュームにアクセスできるようにします。

3.4.4. placementCount

placementCountautoPlace のエイリアスです。

3.4.5. resourceGroup

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

3.4.6. storagePool

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

これと同じ storage pool で構成されたノードのみが autoplacement に使用されます。同様に nodeList を使う StorageClasses ではそのリストで指定されたすべてのノードが storage pool を構成している必要があります。

3.4.7. disklessStoragePool

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

3.4.8. layerList

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

3.4.9. placementPolicy

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

  • AutoPlaceTopology (デフォルト): ユーザー提供の制約とともに、Kubernetesからのトポロジ情報を使用する(詳細は see replicasOnSamereplicasOnDifferent を参照)。

  • AutoPlace : LINSTOR autoplace を使う。 replicasOnSamereplicasOnDifferent の影響をうける。

  • FollowTopology: CSI トポロジ情報を使用して、各 “preferred” ゾーンに少なくとも 1 つのボリュームを配置します。CSI トポロジが有効になっている場合にのみ使用できます。

  • Manual: nodeListclientList にリストされているノードのみを使用する。

  • Balanced: 実験的 選択した各ノードで最も使用されていないストレージプールを使用して、障害のあるドメイン全体にボリュームを配置する。

3.4.10. allowRemoteVolumeAccess

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

  • "true" または "false" は、すべてのノードからのアクセス、またはディスクフルリソースを持つノードのみからのアクセスを許可します。

  • 高度なルール。ノードがボリュームにアクセスできる、より詳細なルールを可能にします。

    現在の実装では、同じラベルを共有するノードのボリュームへのアクセスを許可できます。たとえば、ディスクフルリソースと同じリージョンおよびゾーン内のすべてのノードからのアクセスを許可する場合は、次を使用できます。

    parameters:
      linstor.csi.linbit.com/allowRemoteVolumeAccess: |
        - fromSame:
          - topology.kubernetes.io/region
          - topology.kubernetes.io/zone

    複数のルールを指定でき、1 つのルールに一致するだけで割り当て可能になります。

3.4.11. encryption

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

3.4.12. nodeList

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

このオプションを使用する場合は autoPlace を使用しないでください。
このオプションは、ボリュームのストレージをどのLINSTORノード上でプロビジョニングするかを決定し、 kubelets からこれらのボリュームにアクセスできるようにします。

3.4.13. clientList

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

3.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 のいずれかに配置されます。

3.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 つのレプリカを作成します。

3.4.16. disklessOnRemaining

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

3.4.17. doNotPlaceWithRegex

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

3.4.18. fsOpts

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

これらの値は選択した filesystem 固有です。

3.4.19. mountOpts

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

3.4.20. postMountXfsOpts

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

3.4.21. property.linstor.csi.linbit.com/*

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

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

property.linstor.csi.linbit.com/DrbdOptions/auto-quorum: disabled

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

3.4.22. DrbdOptions/*: <x>

このオプションは非推奨です。より一般的な property.linstor.csi.linbit.com/* を使用してください。

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

3.5. スナップショット

スナップショット の作成とスナップショットからの新しいボリュームの作成は VolumeSnapshots, VolumeSnapshotClasses, と PVCs を使用して行われます。

3.5.1. スナップショットサポートの追加

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

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

$ kubectl get --raw /apis/snapshot.storage.k8s.io/v1
{"kind":"APIResourceList","apiVersion":"v1","groupVersion":"snapshot.storage.k8s.io/v1"...
$ # If your distribution does NOT support snapshots out of the box, you will get a different response:
$ kubectl get --raw /apis/snapshot.storage.k8s.io/v1
Error from server (NotFound): the server could not find the requested resource

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

Listing 5. Piraeus チャートを使用したスナップショットサポートの追加
$ kubectl create namespace snapshot-controller
$ helm repo add piraeus-charts https://piraeus.io/helm-charts/
$ helm install -n snapshot-controller snapshot-validation-webhook \
  piraeus-charts/snapshot-validation-webhook
$ helm install -n snapshot-controller snapshot-controller \
  piraeus-charts/snapshot-controller --wait

3.5.2. ボリュームスナップショットの使用

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

Listing 6. my-first-linstor-snapshot-class.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: my-first-linstor-snapshot-class
driver: linstor.csi.linbit.com
deletionPolicy: Delete

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

kubectl create -f my-first-linstor-snapshot-class.yaml

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

Listing 7. my-first-linstor-snapshot.yaml
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-first-linstor-snapshot
spec:
  volumeSnapshotClassName: my-first-linstor-snapshot-class
  source:
    persistentVolumeClaimName: my-first-linstor-volume

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

kubectl create -f my-first-linstor-snapshot.yaml

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

kubectl describe volumesnapshots.snapshot.storage.k8s.io my-first-linstor-snapshot
...
Spec:
  Source:
    Persistent Volume Claim Name:  my-first-linstor-snapshot
  Volume Snapshot Class Name:      my-first-linstor-snapshot-class
Status:
  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 8. my-first-linstor-volume-from-snapshot.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-first-linstor-volume-from-snapshot
spec:
  storageClassName: linstor-basic-storage-class
  dataSource:
    name: my-first-linstor-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

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

kubectl create -f my-first-linstor-volume-from-snapshot.yaml
スナップショットのS3ストレージへの保存

LINSTORはディザスターリカバリーのために、スナップショットをS3互換のストレージに保存することができます。これは特別なVolumeSnapshotClassを使用してKubernetesに統合されています。

---
kind: VolumeSnapshotClass
apiVersion: snapshot.storage.k8s.io/v1
metadata:
  name: linstor-csi-snapshot-class-s3
driver: linstor.csi.linbit.com
deletionPolicy: Retain
parameters:
  snap.linstor.csi.linbit.com/type: S3
  snap.linstor.csi.linbit.com/remote-name: backup-remote
  snap.linstor.csi.linbit.com/allow-incremental: "false"
  snap.linstor.csi.linbit.com/s3-bucket: snapshot-bucket
  snap.linstor.csi.linbit.com/s3-endpoint: s3.us-west-1.amazonaws.com
  snap.linstor.csi.linbit.com/s3-signing-region: us-west-1
  snap.linstor.csi.linbit.com/s3-use-path-style: "false"
  # Refer here to the secret that holds access and secret key for the S3 endpoint.
  # See below for an example.
  csi.storage.k8s.io/snapshotter-secret-name: linstor-csi-s3-access
  csi.storage.k8s.io/snapshotter-secret-namespace: storage
---
kind: Secret
apiVersion: v1
metadata:
  name: linstor-csi-s3-access
  namespace: storage
immutable: true
type: linstor.csi.linbit.com/s3-credentials.v1
stringData:
  access-key: access-key
  secret-key: secret-key

snap.linstor.csi.linbit.com/ パラメータの正確な意味については LINSTOR スナップショットガイド を確認してください。ログインに使用される認証情報は、上記の例で示すように、別のシークレットに保存されます。

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

既存のスナップショットからリストア

既存のスナップショットからの復元は、ディザスターリカバリーの重要なステップです。スナップショットは、リストアに使用する前にKubernetesに登録される必要があります。

復元すべきスナップショットがS3へのバックアップの一部である場合、LINSTOR “remote” を最初に設定します。

linstor remote create s3 backup-remote s3.us-west-1.amazonaws.com \
  snapshot-bucket us-west-1 access-key secret-key
linstor backup list backup-remote

登録するスナップショットは、リストアップされたスナップショットのうちの1つを指定します。

Kubernetesにスナップショットを登録するには、スナップショットのIDを参照するVolumeSnapshotContentと、コンテンツを参照するVolumeSnapshotの2つのリソースを作成します。

---
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: example-backup-from-s3
  namespace: project
spec:
  source:
    volumeSnapshotContentName: restored-snap-content-from-s3
  volumeSnapshotClassName: linstor-csi-snapshot-class-s3
---
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
  name: restored-snap-content-from-s3
spec:
  deletionPolicy: Delete
  driver: linstor.csi.linbit.com
  source:
    snapshotHandle: snapshot-id
  volumeSnapshotClassName: linstor-csi-snapshot-class-s3
  volumeSnapshotRef:
    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshot
    name: example-backup-from-s3
    namespace: project

適用すると、VolumeSnapshot は ready と表示され、その時点で PVC の dataSource として参照することができるようになります。

3.6. ボリュームのアクセスしやすさと局所性

LINSTOR ボリュームはローカルと ネットワーク経由 の両方でアクセスできます。CSI ドライバーは、コンシューマー用に選択されたノードでボリュームにアクセスできるようにします。ドライバーは、ボリュームの局所性の確保(コンシューマーは下位データと同じノードに配置される)と、アクセスを制限する(ノードのサブセットのみがネットワーク経由でボリュームにアクセスできる)オプションも提供します。

ボリュームの局所性は、ストレージクラスで volumeBindingMode: WaitForFirstConsumer を設定することで実現されます。これにより、Kubernetes と CSI ドライバーは、PVC を参照する最初のコンシューマー(ポッド)がスケジュールされるまで待機するように指示されます。次に、CSI ドライバーは、コンシューマーと同じノード上の下位データを使用してボリュームをプロビジョニングします。適切なストレージプールのないノードが選択された場合、アクセス可能なノードのセットから代替ノードが選択されます(以下を参照)。

ボリュームのアクセスしやすさは allowRemoteVolumeAccess パラメータ によって制御されます。CSI プラグインがボリュームを配置するときはいつでも、このパラメーターを調べてアクセス可能なノードのセットを取得します。これは、ネットワークを介して配置されたボリュームを共有できることを意味します。この情報は、PV のラベルセレクターを介して Kubernetes にも伝達されます。

3.6.1. ボリュームのアクセスしやすさと局所性の例

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

単一ゾーンの同種クラスター

クラスタは単一のゾーンにのみまたがっています。つまり、ノード間の遅延は低くなっています。クラスタは同種です。つまり、すべてのノードが同様に構成され、すべてのノードに独自のローカルストレージプールがあります。

Listing 9. example-storage-class.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: linstor-storage
provisioner: linstor.csi.linbit.com
volumeBindingMode: WaitForFirstConsumer (1)
parameters:
  linstor.csi.linbit.com/storagePool: linstor-pool (2)
  linstor.csi.linbit.com/placementCount: "2" (3)
  linstor.csi.linbit.com/allowRemoteVolumeAccess: "true" (4)
1 レイトボリュームバインディングを有効にします。これにより、可能であれば、最初に実行するポッドと同じノードに 1 つのレプリカが配置されます。
2 使用するストレージプールを設定します。
3 少なくとも 2 つのノードがデータを格納することを確証します。
4 レプリカのないノードでもボリュームの使用を許可します。すべてのノードが均等に接続されているため、パフォーマンスへの影響は小さいです。
マルチゾーン同種クラスター

単一ゾーンと同様に、同種のクラスターでは、すべてのノードが独自のローカルストレージプールで構成されます。クラスターは複数のゾーンにまたがり、異なるゾーンのノード間のレイテンシーが加わりました。低レイテンシーを考慮して、ローカルレプリカのボリュームへのアクセスを、レプリカを持つゾーンのみに制限する必要があります。同時に、データを複数のゾーンに分散させたいと考えています。

Listing 10. example-storage-class.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: linstor-storage
provisioner: linstor.csi.linbit.com
volumeBindingMode: WaitForFirstConsumer (1)
parameters:
  linstor.csi.linbit.com/storagePool: linstor-pool (2)
  linstor.csi.linbit.com/placementCount: "2" (3)
  linstor.csi.linbit.com/allowRemoteVolumeAccess: | (4)
    - fromSame:
      - topology.kubernetes.io/zone
  linstor.csi.linbit.com/replicasOnDifferent: topology.kubernetes.io/zone (5)
1 レイトボリュームバインディングを有効にします。これにより、可能であれば、最初に実行するポッドと同じノードに 1 つのレプリカが配置されます。
2 使用するストレージプールを設定します。
3 少なくとも 2 つのノードがデータを格納することを確証します。
4 ゾーンの内部ネットワークが高速で低遅延であるという前提で、レプリカと同じゾーンのノードでボリュームを使用できるようにします。
5 レプリカを異なるゾーンに配置します。
マルチリージョンクラスター

クラスターは複数のリージョンにまたがっています。リージョン間でデータを複製する遅延ペナルティを発生させたくないので、同じゾーンで複製します。

Listing 11. example-storage-class.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: linstor-storage
provisioner: linstor.csi.linbit.com
volumeBindingMode: WaitForFirstConsumer (1)
parameters:
  linstor.csi.linbit.com/storagePool: linstor-pool (2)
  linstor.csi.linbit.com/placementCount: "2" (3)
  linstor.csi.linbit.com/allowRemoteVolumeAccess: | (4)
    - fromSame:
      - topology.kubernetes.io/zone
  linstor.csi.linbit.com/replicasOnSame: topology.kubernetes.io/region (5)
1 レイトボリュームバインディングを有効にします。これにより、可能であれば、最初に実行するポッドと同じノードに 1 つのレプリカが配置されます。
2 使用するストレージプールを設定します。
3 少なくとも 2 つのノードがデータを格納することを確証します。
4 ゾーンの内部ネットワークが高速で低遅延であるという前提で、レプリカと同じゾーンのノードでボリュームを使用できるようにします。
5 レプリカを単一のリージョンのみに制限します。
外部ストレージを備えたクラスター

クラスターはローカルストレージのないノードのみで構成されています。ボリュームアクセスは、リモートボリュームアクセスを介して行う必要があります。

Listing 12. example-storage-class.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: linstor-storage
provisioner: linstor.csi.linbit.com
parameters:
  linstor.csi.linbit.com/storagePool: linstor-pool (1)
  linstor.csi.linbit.com/placementCount: "1" (2)
  linstor.csi.linbit.com/allowRemoteVolumeAccess: "true" (3)
1 使用するストレージプールを設定します。
2 ストレージホストが 1 つのみであると仮定して、追加のレプリカなしで 1 つのボリュームのみを配置します。
3 ワーカーノードが外部ストレージホストに接続できるようにします。

3.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 で利用できます。

3.8. LINSTOR スケジューラーを使用したボリューム局所性の最適化

LINBIT は Kubernetes スケジューラ用のオープンソースプラグインをメンテナンスしています。スケジューラは、ボリュームの現在の配置を考慮して、データの局所性を最適化します。可能であれば、接続されたボリュームのレプリカもホストするノードにポッドが割り当てられ、読み取り操作のレイテンシーが短縮されます。

スケジューラーは別のチャート artifacthub.io から利用できます。チャートは、後で Pod リソースを作成するときに使用できる新しいスケジューラーをデプロイします。

apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  schedulerName: linstor-scheduler (1)
  containers:
  - name: busybox
    image: busybox
    command: ["tail", "-f", "/dev/null"]
    volumeMounts:
    - name: my-first-linstor-volume
      mountPath: /data
    ports:
    - containerPort: 80
  volumes:
  - name: my-first-linstor-volume
    persistentVolumeClaim:
      claimName: "test-volume"
1 スケジューラの名前をポッドに追加します。

3.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:
  property.linstor.csi.linbit.com/DrbdOptions/auto-quorum: suspend-io
  property.linstor.csi.linbit.com/DrbdOptions/Resource/on-no-data-accessible: suspend-io
  property.linstor.csi.linbit.com/DrbdOptions/Resource/on-suspended-primary-outdated: force-secondary
  property.linstor.csi.linbit.com/DrbdOptions/Net/rr-conflict: retry-connect

Pod を HA コントローラーによる管理から除外するには、次のアノテーションを Pod に追加します。

$ kubectl annotate pod <podname> drbd.linbit.com/ignore-fail-over=""

3.10. Kubernetes でのノードの退避

リソースの LINSTOR ノードを退避させて、クラスター内の他のノードに配置する場合、そのプロセスは ノードの退避 で詳しく説明されています。 ただし、Kubernetes で LINSTOR ノードを退避させる前に、追加のアクションを実行する必要があります。

まず、ノードのワークロードを別のノードに移動します。これを行うには、次のコマンドを入力します。

# kubectl drain --ignore-daemonsets <node_name>

クラスターが正常に動作していることを確認したら ノードの退避 の手順を続行できます。

複数のノードの退避を計画している場合は、退避するすべてのノードで次のコマンドを入力します。

# linstor node set-property n1.k8s-mwa.at.linbit.com AutoplaceTarget false

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

3.11. Kubernetes での LINSTOR デプロイメントのアップグレード

Kubernets での LINSTOR デプロイメントは、Helm を使用して新しいリリースにアップグレードできます。

新しいリリースにアップグレードする前に、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
USER-SUPPLIED VALUES:
USER-SUPPLIED VALUES: null
drbdRepoCred: drbdiocred
operator:
  satelliteSet:
    kernelModuleInjectionImage: drbd.io/drbd9-rhel8:v9.0.28
    storagePools:
      lvmThinPools:
      - 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 のステータスセクションにエラーがリストされていないことを確認してください。

アップグレードプロセス中は、ボリュームのプロビジョニングとアタッチ/デタッチ操作が機能しない場合があります。既存のボリュームと pod ですでに使用されているボリュームは、中断することなく引き続き機能します。

3.11.1. 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 ".*.internal.linstor.linbit.com" | \
      xargs kubectl get crds -oyaml > crds.yaml
  3. 定義に加えて、実際のリソースもバックアップする必要があります。

    $ kubectl get crds | grep -o ".*.internal.linstor.linbit.com" | \
      xargs -i{} sh -c "kubectl get {} -oyaml > {}.yaml"
  4. --set IHaveBackedUpAllMyLinstorResources=true を使用して chart のアップグレードを実行し、上記の手順を実行したことを確認します。

LINSTOR データベースのバックアップからの復元

LINSTOR のアップグレード中に障害から回復する必要がある場合は、次の手順に従ってください。

  1. バックアップを準備します(バックアップがローカルマシンですでに利用可能な場合はスキップ)。

    $ # List the available backups
    $ kubectl get secret '-ocustom-columns=NAME:.metadata.name,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
    crds.yaml
    ....
  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 ".*.internal.linstor.linbit.com" | xargs --no-run-if-empty kubectl delete crds
  5. 古い LINSTOR CRD を適用します

    $ kubectl apply -f crds.yaml
  6. 古い LINSTOR リソースの状態を適用します

    $ kubectl apply -f *.internal.linstor.linbit.com.yaml
  7. 古い LINSTOR バージョンを使用してヘルムチャートを再適用します

    $ helm upgrade linstor-op charts/piraeus --set operator.controller.controllerImage=... --set operator.satelliteSet.satelliteImage=...

3.11.2. 特定のバージョンのアップグレード手順

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

v1.10 へのアップグレード

バージョン 1.10 では、ホストとコンテナー間で DRBD 構成を共有するオプションが導入されています。このオプションが必要な場合は、CRD を更新する必要があります。 Helm はチャートのアップグレード時に CRD をアップグレードしないため、代わりに次を実行してください。

$ helm repo update
$ helm pull linstor/linstor --untar
$ kubectl replace -f linstor/crds/
customresourcedefinition.apiextensions.k8s.io/linstorcontrollers.linstor.linbit.com replaced
customresourcedefinition.apiextensions.k8s.io/linstorcsidrivers.linstor.linbit.com replaced
customresourcedefinition.apiextensions.k8s.io/linstorsatellitesets.linstor.linbit.com 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/
customresourcedefinition.apiextensions.k8s.io/linstorcontrollers.linstor.linbit.com replaced
customresourcedefinition.apiextensions.k8s.io/linstorcsidrivers.linstor.linbit.com replaced
customresourcedefinition.apiextensions.k8s.io/linstorsatellitesets.linstor.linbit.com 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/
customresourcedefinition.apiextensions.k8s.io/linstorcontrollers.linstor.linbit.com replaced
customresourcedefinition.apiextensions.k8s.io/linstorcsidrivers.linstor.linbit.com replaced
customresourcedefinition.apiextensions.k8s.io/linstorsatellitesets.linstor.linbit.com 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/
customresourcedefinition.apiextensions.k8s.io/linstorcontrollers.linstor.linbit.com replaced
customresourcedefinition.apiextensions.k8s.io/linstorcsidrivers.linstor.linbit.com replaced
customresourcedefinition.apiextensions.k8s.io/linstorsatellitesets.linstor.linbit.com 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 を使用してリソースを編集し、値を drbd.io/drbd-reactor:v0.3.0 に設定して、監視を有効にします。
v1.4 へのアップグレード

このバージョンでは、etcd イメージの新しいデフォルトバージョンが導入されているため、etcd が永続ストレージを使用していることに特に注意してください。永続ストレージなしで etcd イメージをアップグレードすると、クラスターが壊れるので注意してください。

新しい Helm オプションを使用せずに既存のクラスターをアップグレードする場合、追加の手順は必要ありません。

新しく導入された additionalProperties および additionalEnv 設定を使用する場合は、インストールされている CustomResourceDefinitions を新しいバージョンに置き換える必要があります。Helm は chart upgrade で CRD をアップグレードしません。

$ helm pull linstor/linstor --untar
$ kubectl replace -f linstor/crds/
customresourcedefinition.apiextensions.k8s.io/linstorcontrollers.linstor.linbit.com replaced
customresourcedefinition.apiextensions.k8s.io/linstorcsidrivers.linstor.linbit.com replaced
customresourcedefinition.apiextensions.k8s.io/linstorsatellitesets.linstor.linbit.com replaced
v1.3 へのアップグレード

追加の手順は必要ありません。

v1.2 へのアップグレード

LINSTOR オペレーター v1.2 は Kubernetes 1.17 以降でサポートされています。古い Kubernetes ディストリビューションを使用している場合は、デフォルト設定を変更する必要がある場合があります。例えば [the CSI provisioner](https://kubernetes-csi.github.io/docs/external-provisioner.html) です。

CSI コンポーネントの更新時に既知の問題があります。pod は最新のイメージに更新されず、LinstorCSIDrivers リソースの errors セクションに DaemonSet の更新エラーが表示されます。この場合、 deployment/linstor-op-csi-controllerdaemonset/linstor-op-csi-node を手動で削除してください。それらはオペレーターによって再作成されます。

3.11.3. 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 を作成します。

4. Openshift での LINSTOR ボリューム

本章では、LINSTOR Operatorで管理し、 LINSTOR CSI plugin を使用してボリュームをプロビジョニングしたOpenShiftでのLINBIT SDSの使用方法を説明します。

OpenShift は、Red Hatが開発し、サポートするKubernetesの公式ディストリビューションです。OpenShiftの価値は、ネットワークのイングレスやモニタリングなど、他のオプションのコンポーネントを強力に統合し、すべてを管理するためのWeb UIで結びつけていることです。LINSTOR Operatorは、可能な限りこれらのコンポーネントと統合しています。

4.1. Openshift での LINSTOR のデプロイ

OpenShiftへのLINBIT SDSのデプロイは、他のKubernetesクラスタへのLINBIT SDSのデプロイと同様です。前提条件として、以下のものが必要です。

  • Helm がインストールされている。

  • oc ユーティリティで OpenShift クラスターにアクセスできる。

  • drbd.io にアクセスする LINBIT カスタマーポータルの資格がある。

LINBIT のコンテナー イメージ リポジトリ (http://drbd.io) は、LINBIT のお客様、>または LINBIT のお客様の試用アカウントを通じてのみ利用できます。価格についての情報や試用開始するには こちら を参照ください。また、LINSTOR SDS のアップストリームプロジェクト Piraeus は LINBIT の顧客ではなくてもを使用できます。

まず、LINBIT SDSの新規プロジェクトを作成し、 drbd.io の認証情報を設定する( $USERNAME$PASSWORD は LINBIT カスタマーポータルの資格に置き換えてください)。

$ oc new-project storage
Now using project "storage" on server ...
$ oc create secret docker-registry drbdiocred --docker-server=drbd.io --docker-username=$USERNAME --docker-password=$PASSWORD
secret/drbdiocred created

次に、Helmチャートのデフォルト値のいくつかを上書きするファイルを override.yaml という名前で作成します。

Listing 13. override.yaml
global:
  setSecurityContext: false (1)
etcd:
  enabled: false (2)
operator:
  controller:
    dbConnectionURL: k8s (3)
  satelliteSet:
    kernelModuleInjectionImage: drbd.io/drbd9-rhel8:v9.1.6 (4)
1 HelmはSecurityContextと衝突するすべてのPodに対して SecurityContext を設定します。
2 etcdの使用は、まだデフォルトですが、LINSTORのバックエンドである k8s に移行するため、段階的に廃止される予定です。新規にインストールする場合は、etcdを使用しないでください。
3 LINSTORの新しいバックエンドである k8s を使用します。LINSTORのクラスタの状態はKubernetes APIのCustomResourcesの中に格納されます。追加のデータベース設定は必要ありません。
4 OpenShiftは、Red Hat Enterprise Linux 8をベースに、同じLinuxカーネルを使用するRed Hat Core OS上で動作します。

必要に応じて override.yaml を追加修正します。使用可能なオプションは Kubernetes advanced deployment section に記載されています。

最後に、Helmを使ってLINBIT SDSをデプロイし、すべてのPodの環境がそろうまで待ちます。

$ helm install linstor-op linstor/linstor --values override.yaml
NAME: linstor-op
NAMESPACE: storage
STATUS: deployed
...
$ oc wait --for=condition=Ready pod --all
...
$ oc get pods
NAME                                         READY   STATUS    RESTARTS   AGE
linstor-op-cs-controller-6588445756-mh9vn    1/1     Running   0          5m48s
...

4.1.1. OpenShiftでLINBIT SDSを利用する

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

4.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-storage.apps.oc.example.com        linstor-op-cs  linstor-op-cs  edge         None

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

これにより、LINBIT GUIやLINSTOR APIへの外部からのアクセスが可能となる場合があります。 ルート上でクライアント側のTLS証明書を要求するなどして、許可されたユーザのみがアクセスできるようにする。

4.1.3. クラスタモニタリングの設定

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

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

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

4.2. OpenShiftでLINBIT SDS 連携

LINSTOR Controller podにはLINSTOR Clientが含まれており、LINSTORの対話型モードに簡単にアクセスすることができます。例えば:

$ oc exec -it deployment/linstor-op-cs-controller -- linstor interactive
LINSTOR ==> ...

これは、問題の調査や高度な機能へのアクセスにのみ必要なはずです。 ボリュームの作成など通常の操作は Kubernetes integration で行う必要があります。

5. NomadのLINSTORボリューム

この章では、LINSTORとDRBDを使用してNomadでボリュームをプロビジョニングする方法について説明します。

5.1. Nomad の紹介

Nomad は、コンテナとコンテナ化されていないアプリケーションをオンプレミスとクラウド上にデプロイして管理するための、シンプルで柔軟性のあるワークロードオーケストレーターです。

Nomad は Container Storage Interface(CSI) に準拠した plug-ins 経由のストレージボリュームのプロビジョニングをサポートします。

LINBIT は、CSIプラグインを drbd.io のコンテナイメージの形で配布しています。このプラグインは、Nomadクラスタに沿って、またはその内部にデプロイされたLINSTORクラスタと連携するように構成できます。

LINBIT のコンテナー イメージ リポジトリ (http://drbd.io) は、LINBIT のお客様、または LINBIT のお客様の試用アカウントを通じてのみ利用できます。価格についての情報や試用開始するには こちら を参照ください。また、LINSTOR SDS のアップストリームプロジェクト Piraeus は LINBIT の顧客ではなくてもを使用できます。

5.2. NomadにLINSTORの展開

この項では、Nomadで新しいLINSTORクラスタを展開および設定する方法について説明します。

LINSTORをノードに直接インストールする場合は、 LINSTOR のインストール を参照してください。このセクションをスキップして、 CSI ドライバのデプロイ に直接移動できます。

5.2.1. Nomadを準備する

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

  • docker driverをサポートし、特権コンテナの実行を許可します。

    特権コンテナーの実行を許可するには、以下のスニペットをNomadエージェント構成に追加して、Nomadを再起動します。

    Listing 14. /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 ディレクトリへのコンテナアクセスを許可する

    ホストボリュームを作成するには、以下のスニペットをNomadエージェント構成に追加し、Nomadを再起動します。

    Listing 15. /etc/nomad.d/host-volume-dev.hcl
    client {
      host_volume "dev" {
        path = "/dev"
      }
    }

5.2.2. LINSTORコントローラジョブの作成

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

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

Listing 16. 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 = "drbd.io/linstor-controller:v1.13.0" (4)

        auth { (5)
          username = "example"
          password = "example"
          server_address = "drbd.io"
        }

        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://postgres.internal.example.com/linstor"
      #  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 イメージを実行するように設定します。最新のイメージは drbd.io から入手できます。
:latest タグの使用は、バージョンの不一致や意図しないアップグレードにすぐにつながる可能性があるため、お勧めしません。
5 イメージを pull するときに使用する認証を設定します。 drbd.io から 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

次に、以下のスニペットをNomadエージェント構成に追加し、Nomadを再起動します。

Listing 17. /etc/nomad.d/host-volume-linstor-db.hcl
client {
  host_volume "linstor-db" {
    path = "/var/lib/linstor"
  }
}

次に、上記の例の linstor-controller.hcl に次のスニペットを追加し、構成テンプレートの connection_url オプションを変更します。

Listing 18. job > group
volume "linstor-db" {
  type = "host"
  source = "linstor-db"
}
Listing 19. job > group > task
volume_mount {
  volume = "linstor-db"
  destination = "/var/lib/linstor"
}

template {
  destination = "local/linstor.toml"
  data = <<EOH
    [db]
    user = "linstor"
    password = "linstor"
    connection_url = "jdbc:h2:/var/lib/linstor/linstordb"
  EOH
}

5.2.3. LINSTOR サテライトジョブの作成

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

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

Listing 20. 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 = "drbd.io/linstor-satellite:v1.13.0" (3)

        auth { (4)
          username = "example"
          password = "example"
          server_address = "drbd.io"
        }

        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 = "drbd.io/drbd9-rhel8:v9.0.29" (8)

        privileged = true (5)
        auth { (4)
          username = "example"
          password = "example"
          server_address = "drbd.io"
        }
      }

      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のサテライトイメージを実行するように設定します。最新のコンテナイメージは drbd.io から入手できます。サテライトイメージのバージョンは、コントローライメージのバージョンと一致している必要があります。
:latest タグの使用は、バージョンの不一致や意図しないアップグレードにすぐにつながる可能性があるため、お勧めしません。
4 イメージを pull するときに使用する認証を設定します。 drbd.io から pull する場合は、ここでLINBITの顧客ログインを使用する必要があります。プライベートレポジトリからの pull に関しては こちら を参照ください。
5 ストレージデバイスやDRBDを構成し、カーネルモジュールをロードするためには、コンテナーを特権モードで実行する必要があります。
6 サテライトはDRBDと通信する必要があるため、ホストネットワークで実行されているnetlinkインターフェースにアクセスする必要があります。
7 drbd-loader タスクはサテライトの開始時に1回実行され、DRBDやその他の有用なカーネルモジュールをロードします。
8 drbd-loader は、使用しているディストリビューションに固有のものです。使用可能なオプションは次のとおりです。
  • Ubuntu18.04(Bionic Beaver) 用の drbd.io/drbd9-bionic

  • Ubuntu20.04(Focal Fossa) 用の drbd.io/drbd9-focal

  • RHEL8 用の drbd.io/drbd9-rhel8

  • RHEL7 用の drbd.io/drbd9-rhel7

9 drbd-loader コンテナは環境変数で設定できます。 LB_HOW はコンテナにDRBDカーネルモジュールの挿入方法を指示します。使用可能なオプションは次のとおりです。
shipped_modules

コンテナに同梱されているパッケージ済みのRPMまたはDEBを使用します。

コンパイル

ソースからDRBDをコンパイルします。カーネルヘッダーへのアクセスが必要です(下記参照)。

deps_only

LINSTOR サテライトで使用される既存のモジュール(例えば dm_thin_pooldm_cache など)のみをロードするようにします。

10 drbd-loader コンテナがDRBDを構築したり、既存のモジュールをロードしたりするためには、ホストの /usr/src/lib/modules にアクセスできる必要があります。

これには、すべてのノードに追加のホストボリュームを設定する必要があります。次のスニペットをすべての Nomad エージェント構成に追加してから、Nomad を再起動する必要があります。

Listing 21. /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"

5.2.4. NomadでのLINSTORの設定

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

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

  • コンテナに入って nomad exec で直接 linstor-controller を実行する。

  • linstor-controller を実行しているホスト上で drbd.io/linstor-client コンテナを使用する。

    docker run -it --rm --net=host drbd.io/linstor-client node create
  • linstor-client パッケージを linstor-controller を実行しているホストにインストールします。

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

$ linstor node create nomad-01.example.com
$ linstor storage-pool create lvmthin nomad-01.example.com thinpool linstor_vg/thinpool
CSIドライバでは、サテライトにホスト名に基づいた名前を付ける必要があります。正確に言うと、サテライト名はノードのNomads attr.unique.hostname 属性と一致する必要があります。

5.3. LINSTOR CSIドライバのNomadへの配備

CSIドライバはシステムジョブとしてデプロイされます。つまり、クラスタ内のすべてのノードで実行されます。

次の例では、データセンター dc1 内のすべてのノードでLINSTOR CSIドライバを起動するNomadジョブを作成します。

Listing 22. 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 = "drbd.io/linstor-csi:v0.13.1" (3)

        auth { (4)
          username = "example"
          password = "example"
          server_address = "drbd.io"
        }

        args = [
          "--csi-endpoint=unix://csi/csi.sock",
          "--node=${attr.unique.hostname}", (5)
          "--linstor-endpoint=http://${NOMAD_UPSTREAM_ADDR_linstor_api}", (6)
          "--log-level=info"
        ]

        privileged = true (7)
      }

      csi_plugin { (8)
        id = "linstor.csi.linbit.com"
        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ドライバイメージを実行するように設定します。最新のイメージは drbd.io から入手できます。
:latest タグの使用は、バージョンの不一致や意図しないアップグレードにすぐにつながる可能性があるため、お勧めしません。
4 イメージを pull するときに使用する認証を設定します。 drbd.io から 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"

5.4. NomadでのLINSTORボリュームの使用

Nomadのボリュームは、 volume仕様 を使用して作成されます。

例として、次の指定では、2つのレプリカを持つ1GiBボリュームがLINSTORストレージプール thinpool から要求されます。

Listing 23. vol1.hcl
id = "vol1" (1)
name = "vol1" (2)

type = "csi"
plugin_id = "linstor.csi.linbit.com"

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は次のものをサポートします。
single-node-reader-only

一度に 1 つのノードに対してのみ読み取りアクセスを許可する

single-node-writer

一度に 1 つのノードに対してのみ読み取り/書き込みアクセスを許可する

multi-node-reader-only

複数のノードからの読み取り専用アクセスを許可する

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  linstor.csi.linbit.com  true         <none>
$ linstor resource list
╭──────────────────────────────────────────────────────────────────────────────────────────────╮
┊ ResourceName ┊ Node                 ┊ Port ┊ Usage  ┊ Conns ┊    State ┊ CreatedOn           ┊
╞══════════════════════════════════════════════════════════════════════════════════════════════╡
┊ vol1         ┊ nomad-01.example.com ┊ 7000 ┊ Unused ┊ Ok    ┊ UpToDate ┊ 2021-06-15 14:56:32 ┊
┊ vol1         ┊ nomad-02.example.com ┊ 7000 ┊ Unused ┊ Ok    ┊ UpToDate ┊ 2021-06-15 14:56:32 ┊
╰──────────────────────────────────────────────────────────────────────────────────────────────╯

5.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"
      }

      ...
    }
  }
}

5.4.2. ボリュームのスナップショットの作成

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

次のコマンドは、ボリューム 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        ┊ nomad-01.example.com, nomad-02.example.com ┊ 0: 1 GiB ┊ 2021-06-15 15:04:10 ┊ Successful ┊
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

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

$ cat vol2.hcl
id = "vol2"
name = "vol2"
snapshot_id = "snap1"

type = "csi"
plugin_id = "linstor.csi.linbit.com"
...

$ nomad volume create vol2.hcl
Created external volume vol2 with ID vol2

6. Proxmox VE での LINSTOR ボリューム

この章は LINSTOR Proxmox Plug-in にあるProxmox VEでのDRBDについて説明します。

6.1. Proxmox VE の紹介

Proxmox VE はKVM、Linuxコンテナ、HAとともに使われる簡単で、完全なサーバ仮想化環境を提供します。

‘linstor-proxmox’ は Proxmox 用の Perl プラグインで、LINSTOR と組み合わせて、複数の Proxmox VE ノードで VM ディスクを複製できます。データはすでに複数のノードにレプリケートされているため、中央の SAN を必要とせずに、ダウンタイムなしで数秒以内にアクティブな VM をライブ マイグレーションできます。

6.2. Proxmox のアップグレード

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

6.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.

6.2.2. プラグインのバージョン 4.x から 5.x へアップグレード

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

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
   controller 10.11.12.13
   resourcegroup drbdMypoolThree

6.2.3. プラグインのバージョン 5.x から 6.x へアップグレード

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

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

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

6.2.4. PVE のバージョン 5.x から 6.x へアップグレード

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

6.3. LINSTOR Proxmox プラグインのインストール

Proxmox で LINSTOR を使用するには、LINSTOR Proxmox プラグインをインストールする必要があります。

6.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 を参照ください。

6.3.2. LINBIT カスタマーリポジトリを使用して Proxmox プラグインをインストール

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

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

# apt install drbd-utils linstor-proxmox drbd-dkms
ノードを LINBIT に登録し、LINBIT リポジトリを有効にする手順については LINBIT クラスターノードを管理するスクリプトの使用 を参照してください。

6.3.3. LINBIT 公開リポジトリを使用して Proxmox プラグインをインストール

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

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

# wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add -
# PVERS=7 && echo "deb http://packages.linbit.com/public/ proxmox-$PVERS drbd-9" > \
/etc/apt/sources.list.d/linbit.list
# apt update && apt -y install linstor-proxmox

6.4. LINSTOR の構成

このガイドの残りの部分では クラスタの初期化 に基づいて LINSTOR クラスタが構成されていると仮定します。1 つのノードで “linstor-controller” を起動し、すべてのノードで “linstor-satellite” を起動します。”linstor-satellite” サービスには systemctl edit linstor-satellite.service で追加構成が必要です。

[Service]
Type=notify
TimeoutStartSec=infinity

バージョン 4.1.0 以降、このプラグインを使用する上で推奨する方法は、LINSTOR リソースグループと単一のボリュームグループを使用することです。 LINSTOR リソースグループについては リソースグループを使用した LINSTOR プロビジョニングされたボリュームのデプロイ を参照してください。必要なすべての LINSTOR 構成(冗長カウントなど)をリソースグループに設定する必要があります。

6.5. Proxmox プラグインの構成

最後の手順ではProxmox自身を設定します。これは /etc/pve/storage.cfg に以下のような設定を加えることで行います。

drbd: drbdstorage
   content images,rootdir
   controller 10.11.12.13
   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
   controller 10.11.12.13
   resourcegroup defaultpool

drbd: fastdrbd
   content images,rootdir
   controller 10.11.12.13
   resourcegroup ssd

drbd: slowdrbd
   content images,rootdir
   controller 10.11.12.13
   resourcegroup backup

これらの設定後、Web GUIでVMを作成し、ストレージとして “drbdstorage” もしくは他の定義されているプールを選択することでDRBDボリュームを使用できます。

プラグインのバージョン 5 以降、オプション “preferlocal yes” を設定できます。設定されている場合、プラグインは storage create コマンドを発行したノードでディスクフル割り当てを作成しようとします。このオプションを使用すると、可能であれば VM がローカルストレージを確実に取得できるようになります。このオプションがないと、VM はノード ‘A’ で起動するが、LINSTORはノード ‘B’ と ‘C’ にストレージを配置する可能性があります。これは、ノード ‘A’ がディスクレス割り当てで、引き続き機能しますが、ローカルストレージを使用することが望まれます。

注意: DRBDは現時点で raw ディスクフォーマットのみをサポートします。

この時点で、VMのライブマイグレーションができます。すべてのノード(ディスクレスノードでも)ですべてのデータにアクセスできるため、わずか数秒で完了します。 VMに負荷がかかっていて、ダーティメモリが常に多い場合は、全体的な処理に少し時間がかかることがあります。しかし、いずれの場合でも、ダウンタイムは最小限で、中断は全く見られません。

Table 1. テーブル構成オプション
Option Meaning

controller

LINSTOR コントローラーの IP (‘,’ で複数指定可能)

resourcegroup

新しい VM の展開を定義する LINSTOR リソースグループの名前

preferlocal

ローカルストレージ作成を好むかどうか (yes/no)

statuscache

ステータス情報がキャッシュされる秒単位の時間。0 はキャッシュがないことを意味します。数百のリソースを持つ巨大なクラスターで役立ちます。これを有効にするには /etc/pve/storage.cfg のすべての drbd ストレージに設定する必要があります

apicrt

クライアント証明書へのパス

apikey

クライアントの秘密鍵へのパス

apica

CA 証明書へのパス

6.6. コントローラの高可用性 (オプション構成)

LINSTOR を高可用性にするということは、LINSTOR コントローラーを高可用性にすることです。このステップはセクション 高可用性 LINSTOR クラスターの作成 で説明されています。

最後の(しかし重要な)ステップは、複数の LINSTOR コントローラーに接続できるように Proxmox プラグインを構成することです。応答した最初のものを使用するように、次のようにプラグインの controller セクションにコンマ区切りでコントローラーを指定します。

drbd: drbdstorage
   content images,rootdir
   controller 10.11.12.13,10.11.12.14,10.11.12.15
   resourcegroup defaultpool

7. OpenNebulaのLINSTORボリューム

この章では、OpenNebulaのDRBDについて LINSTOR ストレージドライバアドオン の使用法を説明します。

詳しいインストールと設定の手順は、ドライバのソースの README.md を参照ください。

7.1. OpenNebula の紹介

OpenNebula は、アドオンを使用してその機能を拡張できる、柔軟でオープンソースのクラウド管理プラットフォームです。

LINSTOR アドオンを使用すると、DRBD によってバックアップされ、DRBD プロトコルを介してネットワークに接続された高可用性イメージを持つ仮想マシンを配備できます。

7.2. OpenNebula アドオンのインストール

OpenNebula 用の LINSTOR ストレージアドオンのインストールには、動作中の OpenNebula クラスタと動作中の LINSTOR クラスタが必要です。

LINBITの顧客リポジトリにアクセスすることで、linstor-opennebula をインストールできます。

# apt install linstor-opennebula

または

# yum install linstor-opennebula

LINBITのパッケージにアクセスすることができない場合は、 OpenNebula LINSTOR アドオン GitHub ページ を確認してください。

LINSTORを使用したDRBDクラスタは、このマニュアルの指示に従ってインストールおよび設定できます。詳細は クラスタの初期化 を参照してください。

OpenNebulaとDRBDクラスタは、OpenNebulaのフロントエンドノードとホストノードを両方のクラスタに含める必要がありますが、これ以外は互いに独立にできます。

ホストノードは、仮想マシン・イメージがネットワークを介して接続されるためローカルの LINSTOR ストレージプールを必要としません [1]

7.3. 配備オプション

LINSTOR リソースグループ リソースグループの作成 を使用して構成することをお勧めします。以前の自動配置およびデプロイメントノードモードは非推奨です。

7.4. OpenNebula アドオンの構成

7.4.1. OpenNebula へのドライバーの追加

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

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

TM_MAD = [
    EXECUTABLE = "one_tm",
    ARGUMENTS = "-t 15 -d dummy,lvm,shared,fs_lvm,qcow2,ssh,vmfs,ceph,linstor"
]
DATASTORE_MAD = [
    EXECUTABLE = "one_datastore",
    ARGUMENTS  = "-t 15 -d dummy,fs,lvm,ceph,dev,iscsi_libvirt,vcenter,linstor -s shared,ssh,ceph,fs_lvm,qcow2,linstor"
]
linstorDATASTORE_MAD 引数で 2 回指定されます。

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

TM_MAD_CONF = [
    NAME = "linstor", LN_TARGET = "NONE", CLONE_TARGET = "SELF", SHARED = "yes", ALLOW_ORPHANS="yes",
    TM_MAD_SYSTEM = "ssh,shared", LN_TARGET_SSH = "NONE", CLONE_TARGET_SSH = "SELF", DISK_TYPE_SSH = "BLOCK",
    LN_TARGET_SHARED = "NONE", CLONE_TARGET_SHARED = "SELF", DISK_TYPE_SHARED = "BLOCK"
]
DS_MAD_CONF = [
    NAME = "linstor", REQUIRED_ATTRS = "BRIDGE_LIST", PERSISTENT_ONLY = "NO",
    MARKETPLACE_ACTIONS = "export"
]

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

7.4.2. ノードの構成

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

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

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

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

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

フロントエンドノードの構成

使用するコントロールノードがフロントエンドノードから到達可能であることを確認してください。ローカルで実行される LINSTOR コントローラーでは linstor node list を、リモートで実行する LINSTOR コントローラーでは linstor --controllers "<IP:PORT>" node list を使用することで簡単にテストできます。

ホストノードの構成

ホストノードでは、LINSTOR サテライトプロセスが実行され、フロントエンドノードおよびストレージノードと同じ LINSTOR クラスターのメンバーである必要があります。また、オプションでローカルにストレージを持つことができます。 oneadmin ユーザーがパスワードなしでホスト間で SSH できる場合、SSH システムデータストアでもライブマイグレーションを使用できます。

ストレージノードの構成

フロントエンドノードとホストノードのみが OpenNebula のインストールを必要としますが、oneadmin ユーザーはパスワードなしでストレージノードにアクセスできる必要があります。 oneadmin ユーザーアカウントを手動で構成する方法については、ディストリビューションの OpenNebula インストールガイドを参照してください。

ストレージノードは、シンLVMプラグインなどのスナップショットを作成できるドライバーで作成されたストレージプールを使用する必要があります。

LINSTOR 用のLVMを使用したシンプロビジョニングされたストレージのこの例では、各ストレージノードでLVMを使用してボリュームグループとthinLVを作成する必要があります。

以下は 2つの物理ボリューム (/dev/sdX と /dev/sdY) とボリュームグループおよびシンプールの一般名を使用したこの構成例です。 thinLVのメタデータボリュームを適切なサイズに設定してください。一度いっぱいになると、サイズ変更が困難になる場合があります。

pvcreate /dev/sdX /dev/sdY
vgcreate drbdpool /dev/sdX /dev/sdY
lvcreate -l 95%VG --poolmetadatasize 8g -T /dev/drbdpool/drbdthinpool

次に、これを下位ストレージとして使用して、LINSTOR にストレージプールを作成します。

ZFSストレージプールまたは thick-LVM を使用している場合は、LINSTOR_CLONE_MODEcopy を使わないと ZFS の親子スナップショットの関係のために、linstor リソースを削除するときに問題が発生します。

7.4.3. 管理アカウントの権限

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

oneadmin ALL=(root) NOPASSWD: /sbin/mkfs
Groups

ストレージへのアクセスとVMのインスタンス化に必要なデバイスとプログラムにアクセスするため、oneadmin に追加する必要があるグループを必ず検討してください。このアドオンの場合、イメージが保持されているDRBDデバイスにアクセスするには、oneadminユーザーがすべてのノードの disk グループに属している必要があります。

usermod -a -G disk oneadmin

7.4.4. 新しい LINSTOR データストアの作成

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

7.4.5. リソースグループの作成

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

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

linstor resource-group create OneRscGrp --place-count 2 --storage-pool opennebula-storagepool
linstor volume-group create OneRscGrp

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

cat >ds.conf <<EOI
NAME = linstor_datastore
DS_MAD = linstor
TM_MAD = linstor
TYPE = IMAGE_DS
DISK_TYPE = BLOCK
LINSTOR_RESOURCE_GROUP = "OneRscGrp"
COMPATIBLE_SYS_DS = 0
BRIDGE_LIST = "alice bob charlie"  #node names
EOI

onedatastore create ds.conf

7.4.6. プラグインの属性

LINSTOR_CONTROLLERS

LINSTOR コントローラープロセスがローカルで実行されていない場合、 LINSTOR_CONTROLLERS を使用して、コントローラーIPとポートのコンマ区切りリストを LINSTOR クライアントに渡すことができます。

LINSTOR_CONTROLLERS = "192.168.1.10:8080,192.168.1.11:6000"

LINSTOR_RESOURCE_GROUP

LINSTOR_RESOURCE_GROUP 属性は、OpenNebula データストアを LINSTOR リソースグループに関連付けるために使用されます。

7.4.7. 廃止された属性

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

LINSTOR_CLONE_MODE

LINSTOR は、使用するクローンモードを自動的に決定するようになりました。

LINSTOR は snapshotcopy の2つの異なるクローンモードをサポートしています。これらのモードは LINSTOR_CLONE_MODE 属性で設定されます。

デフォルトのモードは snapshot で、linstorスナップショットを使用し、このスナップショットから新しいリソースを復元します。このスナップショットはイメージのクローンになります。通常、スナップショットは最低限のコピーであるため、このモードは copy モードを使用するよりも高速です。

2番目のモードは copy モードで、元のサイズと同じサイズの新しいリソースを作成し、 dd でデータを新しいリソースにコピーします。このモードは snapshot よりも遅くなりますが、スナップショットメカニズムに依存しないため、より堅牢です。別のlinstorデータストアにイメージをクローンする場合にも使用されます。

LINSTOR_STORAGE_POOL

LINSTOR_STORAGE_POOL 属性は、データストアが使用するLINSTORストレージプールを選択するために使用されます。リソースグループが使用される場合、ストレージプールは自動選択フィルターオプションで選択できるため、この属性は必要ありません。

LINSTOR_AUTO_PLACE または LINSTOR_DEPLOYMENT_NODES が使用され、LINSTOR_STORAGE_POOL が設定されていない場合、LINSTORで DfltStorPool にフォールバックします。

LINSTOR_AUTO_PLACE

LINSTOR_AUTO_PLACE オプションは、冗長ストレージの個数を表し、1からストレージノードの総数の間の数値です。リソースは、冗長性の個数に基づいてストレージノードに自動的に割り当てられます。

LINSTOR_DEPLOYMENT_NODES

LINSTOR_DEPLOYMENT_NODES を使用すると、リソースが常に割り当てられるノードのグループを選択できます。ブリッジリストには、LINSTOR クラスター内のすべてのストレージノードがまだ含まれていることに注意してください。

7.4.8. システムデータストアとしての LINSTOR を構成

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

cat >system_ds.conf <<EOI
NAME = linstor_system_datastore
TM_MAD = linstor
TYPE = SYSTEM_DS
LINSTOR_RESOURCE_GROUP = "OneSysRscGrp"
BRIDGE_LIST = "alice bob charlie"  # node names
EOI

onedatastore create system_ds.conf

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

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

7.5. ライブマイグレーション

ライブマイグレーションは、SSH システムデータストアとnfs共有システムデータストアを使用してもサポートされます。

7.6. 空き容量の計算

空き容量は、リソースが自動的に配備されるか、ノードごとに配備されるかに応じて異なって計算されます。

ノードごとに配置されるデータストアでは、リソースが配備されているすべてのノードの最も制限的なストレージプールに基づいて空き領域がレポートされます。たとえば、総ストレージ容量の最小値を持つノードの容量を使用してデータストアの合計サイズを決定し、空き容量が最小のノードを使用してデータストアの残りの容量を決定します。

自動配置を使用するデータストアの場合、サイズと残りの領域は、LINSTORによって報告されたデータストアで使用される集約ストレージプールに基づいて決定されます。

8. OpenStackでのLINSTORボリューム

この章では、LINSTOR を使用して、Openstack 用の永続的で複製された高性能のブロックストレージをプロビジョニングする方法について説明します。

8.1. OpenStack の紹介

Openstack は、さまざまな個別のサービスで構成されています。ブロックストレージのプロビジョニングと管理を担当するサービスは Cinder と呼ばれます。コンピューティングインスタンスサービス Nova などの他の openstack サービスは、Cinder にボリュームをリクエストできます。その後、Cinder は、要求元のサービスがボリュームにアクセスできるようにします。

LINSTOR は、ボリュームドライバーを使用して Cinder と統合できます。ボリュームドライバーは、CinderAPI への呼び出しを LINSTOR コマンドに変換します。例えば Cinderにボリュームを要求すると、LINSTOR に新しいリソースが作成され、Cinder ボリュームのスナップショットは LINSTOR のスナップショットに変換されます。

8.2. OpenStack 用の LINSTOR のインストール

OpenStack ドライバーを使用する前に、DRBD と LINSTOR の初期インストールと構成を完了する必要があります。

この時点で、LINSTOR クライアントを使用してストレージクラスターノードを一覧表示できるはずです。

╭────────────────────────────────────────────────────────────────────────────╮
┊ Node                      ┊ NodeType  ┊ Addresses                 ┊ State  ┊
╞════════════════════════════════════════════════════════════════════════════╡
┊ cinder-01.openstack.test  ┊ COMBINED  ┊ 10.43.224.21:3366 (PLAIN) ┊ Online ┊
┊ cinder-02.openstack.test  ┊ COMBINED  ┊ 10.43.224.22:3366 (PLAIN) ┊ Online ┊
┊ storage-01.openstack.test ┊ SATELLITE ┊ 10.43.224.11:3366 (PLAIN) ┊ Online ┊
┊ storage-02.openstack.test ┊ SATELLITE ┊ 10.43.224.12:3366 (PLAIN) ┊ Online ┊
┊ storage-03.openstack.test ┊ SATELLITE ┊ 10.43.224.13:3366 (PLAIN) ┊ Online ┊
╰────────────────────────────────────────────────────────────────────────────╯

また、ノードごとに 1 つ以上の ストレージプール を構成する必要があります。このガイドでは、ストレージプールの名前が cinderpool であると仮定しています。LINSTOR は デフォルトで作成されたディスクレスストレージプールを含む、各ノードのストレージプールを一覧表示します。

$ linstor storage-pool list
╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
┊ StoragePool          ┊ Node                      ┊ Driver   ┊ PoolName        ┊ FreeCapacity ┊ TotalCapacity ┊ CanSnapshots ┊ State ┊
╞═════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╡
┊ DfltDisklessStorPool ┊ cinder-01.openstack.test  ┊ DISKLESS ┊                 ┊              ┊               ┊ False        ┊ Ok    ┊
┊ DfltDisklessStorPool ┊ cinder-02.openstack.test  ┊ DISKLESS ┊                 ┊              ┊               ┊ False        ┊ Ok    ┊
┊ DfltDisklessStorPool ┊ storage-01.openstack.test ┊ DISKLESS ┊                 ┊              ┊               ┊ False        ┊ Ok    ┊
┊ DfltDisklessStorPool ┊ storage-02.openstack.test ┊ DISKLESS ┊                 ┊              ┊               ┊ False        ┊ Ok    ┊
┊ DfltDisklessStorPool ┊ storage-03.openstack.test ┊ DISKLESS ┊                 ┊              ┊               ┊ False        ┊ Ok    ┊
┊ cinderpool           ┊ storage-01.openstack.test ┊ LVM_THIN ┊ ssds/cinderpool ┊      100 GiB ┊       100 GiB ┊ True         ┊ Ok    ┊
┊ cinderpool           ┊ storage-02.openstack.test ┊ LVM_THIN ┊ ssds/cinderpool ┊      100 GiB ┊       100 GiB ┊ True         ┊ Ok    ┊
┊ cinderpool           ┊ storage-03.openstack.test ┊ LVM_THIN ┊ ssds/cinderpool ┊      100 GiB ┊       100 GiB ┊ True         ┊ Ok    ┊
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

8.2.1. LINSTOR ドライバをアップグレード

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

1.x から 2.x へのアップグレード

ドライバーバージョン 2 は、実行時に ボリュームタイプ でこれらのオプションを管理するため、いくつかの静的構成オプションを削除しました。

Option in cinder.conf Status Replace with

linstor_autoplace_count

削除

ボリュームタイプで linstor:redundancy プロパティを使用します。フルクラスターレプリケーションで値 0 を使用することはサポートされていません。the LINSTOR autoplacer オプションを使用してください

linstor_controller_diskless

削除

置き換えは必要ありません。ドライバーは必要に応じて cinder ホスト上にディスクレスリソースを作成します

linstor_default_blocksize

削除

この設定は効果がありませんでした

linstor_default_storage_pool_name

非推奨

この設定は、将来のバージョンで削除するために非推奨になりました。代わりに、ボリュームタイプで linstor:storage_pool プロパティを使用してください

linstor_default_uri

非推奨

より適切な名前の linstor_uris に置き換えられました

linstor_default_volume_group_name

削除

ノードとストレージプールの作成は、ドライバーバージョン 2 で削除されました。OpenStack 用の LINSTOR のインストール を参照してください

linstor_volume_downsize_factor

削除

この設定は目的を果たさず、置き換えなしで削除されました

8.2.2. LINSTOR ドライバをインストール

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

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

OpenStack Release Included Version LINBIT Version LINBIT Branch

yoga

1.0.1

2.0.0

linstor/stable/yoga

xena

1.0.1

2.0.0

linstor/stable/xena

wallaby

1.0.1

2.0.0

linstor/stable/wallaby

victoria

1.0.1

2.0.0

linstor/stable/victoria

ussuri

1.0.1

2.0.0

linstor/stable/ussuri

train

1.0.0

2.0.0

linstor/stable/train

stein

1.0.0

2.0.0

linstor/stable/stein

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

DevStack でインストール

DevStack は、ラボ環境で OpenStack を試すのに最適な方法です。最新のドライバーを使用するには、次の DevStack 構成を使用します。

Listing 24. local.conf
# This ensures the LINSTOR Driver has access to the 'python-linstor' package.
#
# This is needed even if using the included driver!
USE_VENV=True
ADDITIONAL_VENV_PACKAGES=python-linstor

# This is required to select the LINBIT version of the driver
CINDER_REPO=https://github.com/LINBIT/openstack-cinder.git
# Replace linstor/stable/victoria with the reference matching your OpenStack release.
CINDER_BRANCH=linstor/stable/victoria
Kolla でインストール

Kolla は OpenStack コンポーネントをコンテナーにパッケージ化します。次に、例えば Kolla Ansible を使用してデプロイできます。kolla コンテナーで使用可能なカスタマイズオプションを利用して、LINSTOR ドライバーをセットアップできます。

必要な python-linstor パッケージがインストールされるようにするには、次のオーバーライドファイルを使用します。

Listing 25. template-override.j2
{% extends parent_template %}

# Cinder
{% set cinder_base_pip_packages_append = ['python-linstor'] %}

LINBIT バージョンのドライバーをインストールするには kolla-build.conf を更新します。

Listing 26. /etc/kolla/kolla-build.conf
[cinder-base]
type = git
location = https://github.com/LINBIT/openstack-cinder.git
# Replace linstor/stable/victoria with the reference matching your OpenStack release.
reference = linstor/stable/victoria

Cinder コンテナを再構築するには、次のコマンドを実行します。

# A private registry used to store the kolla container images
REGISTRY=deployment-registry.example.com
# The image namespace in the registry
NAMESPACE=kolla
# The tag to apply to all images. Use the release name for compatibility with kolla-ansible
TAG=victoria
kolla-build -t source --template-override template-override.j2 cinder --registry $REGISTRY --namespace $NAMESPACE --tag $TAG
Kolla Ansible デプロイメント

Kolla Ansible を使用して OpenStack をデプロイする場合は、次のことを確認する必要があります。

  • 上記のセクションで作成されたカスタム Cinder イメージは、Cinder サービスのデプロイメントが有効になっている場合に使用されます。

Listing 27. /etc/kolla/globals.yml
# use "source" images
kolla_install_type: source
# use the same registry as for running kolla-build above
docker_registry: deployment-registry.example.com
# use the same namespace as for running kolla-build above
docker_namespace: kolla
# deploy cinder block storage service
enable_cinder: "yes"
# disable verification of cinder back ends, kolla-ansible only supports a small subset of available back ends for this
skip_cinder_backend_check: True
# add the LINSTOR back end to the enabled back ends. For back end configuration see below
cinder_enabled_backends:
  - name: linstor-drbd

LINSTOR ドライバー構成は kolla-ansible のオーバーライドディレクトリの 1 つに配置できます。使用可能な構成オプションの詳細については、以下のセクションを参照してください。

Listing 28. /etc/kolla/config/cinder/cinder-volume.conf
[linstor-drbd]
volume_backend_name = linstor-drbd
volume_driver = cinder.volume.drivers.linstordrv.LinstorDrbdDriver
linstor_uris = linstor://cinder-01.openstack.test,linstor://cinder-02.openstack.test
OpenStack Ansible デプロイメント

OpenStack Ansible は、OpenStack 環境を構成およびデプロイするための Ansible プレイブックを提供します。これにより、デプロイメントをきめ細かくカスタマイズできるため、LINSTOR ドライバーを直接セットアップできます。

Listing 29. /etc/openstack_ansile/user_variables.yml
cinder_git_repo: https://github.com/LINBIT/openstack-cinder.git
cinder_git_install_branch: linstor/stable/victoria

cinder_user_pip_packages:
  - python-linstor

cinder_backends: (1)
  linstor-drbd:
   volume_backend_name: linstor-drbd
   volume_driver: cinder.volume.drivers.linstordrv.LinstorDrbdDriver
   linstor_uris: linstor://cinder-01.openstack.test,linstor://cinder-02.openstack.test
1 使用可能なバックエンドパラメータの詳細な説明は、以下のセクションにあります。
汎用 Cinder デプロイメント

他の形式の OpenStack デプロイメントの場合、このガイドでは一般的なヒントのみを提供できます。

LINSTOR ドライバーのバージョンを更新するには、インストールされた cinder ディレクトリを見つけてください。考えられるパスは次のとおりです。

/usr/lib/python*/dist-packages/cinder/
/usr/lib/python*/site-packages/cinder/

LINSTOR ドライバーは、cinder ディレクトリにある linstordrv.py というファイルです。

$CINDER_PATH/volume/drivers/linstordrv.py

ドライバを更新するには、ファイルを LINBIT リポジトリのファイルに置き換えます

RELEASE=linstor/stable/victoria
curl -fL "https://raw.githubusercontent.com/LINBIT/openstack-cinder/$RELEASE/cinder/volume/drivers/linstordrv.py" > $CINDER_PATH/volume/drivers/linstordrv.py

登録されたものを更新するには、Python キャッシュを削除する必要がある場合もあります。

rm -rf $CINDER_PATH/volume/drivers/__pycache__

8.3. Cinder 用の LINSTOR バックエンドを構成

LINSTOR ドライバーを使用するには、Cinder ボリュームサービスを構成します。Cinder 構成ファイルを編集してから、Cinder ボリュームサービスを再起動することで構成できます。

ほとんどの場合、Cinder 構成ファイルは /etc/cinder/cinder.conf にあります。一部のデプロイメントでは、このファイルを事前に編集できます。詳細は上記のセクションを参照してください。

LINSTOR を使用して新しいボリュームバックエンドを構成するには、次のセクションを cinder.conf に追加します。

[linstor-drbd]
volume_backend_name = linstor-drbd (1)
volume_driver = cinder.volume.drivers.linstordrv.LinstorDrbdDriver (2)
linstor_uris = linstor://cinder-01.openstack.test,linstor://cinder-02.openstack.test (3)
linstor_trusted_ca = /path/to/trusted/ca.cert (4)
linstor_client_key = /path/to/client.key (5)
linstor_client_cert = /path/to/client.cert (5)
# Deprecated or removed in 2.0.0
linstor_default_storage_pool_name = cinderpool (6)
linstor_autoplace_count = 2 (7)
linstor_controller_diskless = true (8)
# non-linstor-specific options
... (9)
ここで説明するパラメーターは、Linbit が提供する最新のリリースに基づいています。 OpenStack に含まれているドライバーは、これらのパラメーターのすべてをサポートしているとは限りません。詳細は OpenStack ドライバーのドキュメント を参照ください。
1 ボリュームバックエンド名。 Cinder 構成で一意である必要があります。セクション全体で同じ名前を共有する必要があります。この名前は enabled_backends 設定の cinder.conf で、および新しいボリュームタイプを作成するときに再び参照されます。
2 使用する LINSTOR ドライバーのバージョン。2 つのオプションがあります。
  • cinder.volume.drivers.linstordrv.LinstorDrbdDriver

  • cinder.volume.drivers.linstordrv.LinstorIscsiDriver

    どのドライバーを使用するかは LINSTOR のセットアップと要件によって異なります。各選択肢の詳細は 以下のセクション を参照ください。

3 LINSTOR コントローラーの URL。 Linstor 高可用性 を利用するために、複数のコントローラーを指定できます。設定されていない場合、デフォルトは linstor://localhost です。
2.0.0 より前のバージョンのドライバーでは、このオプションは linstor_default_uri と呼ばれます。
4 HTTPS が有効の場合、 指定された証明書を使用して LINSTOR コントローラーの信頼性を検証します。
5 HTTPS が有効の場合、 指定されたキーと証明書が、認証のために LINSTOR コントローラーで使用されます。
6 2.0.0 で非推奨になったので、代わりに volume types を使用してください。リソースを配置するときに使用するストレージプール。作成されたすべてのディスクフルリソースに๰