LINSTOR ユーザーズガイド

最初にお読みください

このガイドは、Software-Defined-Storage ソリューションである 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 を参照ください。

LINBITのサポートサブスクリプションをお持ちの場合は、私たちのリポジトリを通して認定バイナリにアクセスしてください。

1.4. インストール

コンテナでLINSTORを使用する場合は、このトピックを飛ばして、下記の「コンテナ」セクションを参照ください。

1.4.1. Ubuntu Linux

DRBDを使用して複製ストレージを作成したい場合は、 drbd-dkmsdrbd-utils をインストールする必要があります。これらのパッケージはすべてのノードにインストールする必要があります。また、ZFSかLVMのどちらかのボリュームマネージャを選択する必要があります。この例では、LVMを使用しています。

# apt install -y drbd-dkms drbd-utils lvm2

ノードがLINSTORコントローラ、サテライト、またはその両方(Combined)のどれであるかに応じて、そのノードに必要なパッケージが決まります。Combinedノードの場合、コントローラとサテライトの両方のLINSTORパッケージが必要になります。

Combinedノード

# apt install linstor-controller linstor-satellite  linstor-client

残りのノードをサテライトにする場合、以下のパッケージをインストールします。

# apt install linstor-satellite  linstor-client

1.4.2. SUSE Linux Enterprise Server

SLES High Availability Extension (HAE) にDRBDが含まれています。

SLESでは、DRBDは通常YaST2のソフトウェアインストールコンポーネントを介してインストールされます。 High Availabiltyパッケージにバンドルされています。

DRBDの最新モジュールをダウンロードすると、LVMツールも最新のものであるかどうかを確認できます。コマンドラインでインストールする場合、次のコマンドで最新のDRBDおよびLVMバージョンを入手できます。

# zypper install drbd lvm2

ノードがLINSTORコントローラ、サテライト、またはその両方(Combined)のどれであるかに応じて、そのノードに必要なパッケージが決まります。Combinedノードの場合、コントローラとサテライトの両方のLINSTORパッケージが必要になります。

Combinedノード

# zypper install linstor-controller linstor-satellite  linstor-client

残りのノードをサテライトにする場合、以下のパッケージをインストールします。

# zypper install linstor-satellite  linstor-client

1.4.3. CentOS

CentOS はリリース5以降、DRBD 8を含んでいます。DRBD 9に関しては、EPELと同様のソースを調べる必要があります。あるいは、LINBITとサポート契約をお持ちの場合は、RHEL 8リポジトリを利用できます。また、最新バージョンのLVMツールも確認できます。

LINSTOR で複製ストレージを使用する場合は、 DRBD 9 が必要です。これには、LINBITまたはサードパーティのいずれかの外部リポジトリを設定する必要があります。
# yum install drbd kmod-drbd lvm2

ノードがLINSTORコントローラ、サテライト、またはその両方(Combined)のどれであるかに応じて、そのノードに必要なパッケージが決まります。Combinedノードの場合、コントローラとサテライトの両方のLINSTORパッケージが必要になります。

RHEL 8システムでは、linstor-clientが機能するためにpython2をインストールする必要があります。

Combinedノード

# yum install linstor-controller linstor-satellite  linstor-client

残りのノードをサテライトにする場合、以下のパッケージをインストールします。

# yum install linstor-satellite  linstor-client

1.5. アップグレード

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

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

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

したがって、最初にコントローラホストの linstor-controllerlinstor-client パッケージをアップグレードし、 linstor-controller を再起動することで、すべてのクライアントが OFFLINE(VERSION_MISMATCH) を表示します。その後すべてのサテライトノードで linstor-satellite のアップグレードを続行して再起動することで、すべてのノードで再び ONLINE が表示され、アップグレードが完了します。

1.6. コンテナ

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

イメージにアクセスするには、まずレジストリにログインする必要があります(アカウントについては sales@linbit.com にお問い合わせください)。

# 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 -p 3376:3376 -p 3377:3377 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.7. クラスタの初期化

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

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

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

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

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

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

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

# systemctl enable --now linstor-controller

linstor-controllerサービスがインストール時に自動的に有効になる場合は、次のコマンドも使用できます。

# systemctl start linstor-controller

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

これは空のノードリストをエラーメッセージなしで表示します。

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.9. ノードをクラスタに追加する

次の手順ではノードを 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.10. ストレージプール

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.10.1. 下位デバイスごとのストレージプール

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

1.10.2. 物理ストレージコマンド

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

  • デバイスにはファイルシステムやその他の blkid マーカー( wipefs -a が必要な場合があります)がない

  • デバイスは 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.11. リソースグループ

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

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

リソースグループを使用して、リソースのプロビジョニング方法を定義することは、 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.12. クラスタ構成

1.12.1. 利用可能なストレージプラグイン

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

  • Thick LVM

  • 単一の thin プールの Thin LVM

  • Thick ZFS

  • Thin ZFS

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

以下の例では、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.13.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.13.2. 自動配備

オプション—​auto-placeに続く数値は複製の数を指定します。–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 の動作と同じにするには MaxFreeSpace の重みを 1 にし、残りの方針の重みを 0 にします。
0 でも負のスコアでも、ストレージプールが選択されるのを防ぐことはできず、後ほど考慮されるようになります。

最後に LINSTOR はすべての要件を満たすストレージプールの最適なグループを見つけようとします。このステップでは、他の自動配置の制限 --replicas-on-same, --replicas-on-different なども考慮されます。

これらの2つの引数 --replicas-on-same--replicas-on-differentAux/ 名前空間内のプロパティの名前を想定しています。次の例は、クライアントが自動的に testProperty の前に Aux/ 名前空間を付けることを示しています。

linstor resource-group create testRscGrp --replicas-on-same testProperty
SUCCESS:
Description:
    New resource group 'testRscGrp' created.
Details:
    Resource group 'testRscGrp' UUID is: 35e043cb-65ab-49ac-9920-ccbf48f7e27d

linstor resource-group list
+-----------------------------------------------------------------------------+
| ResourceGroup | SelectFilter                         | VlmNrs | Description |
|-============================================================================|
| DfltRscGrp    | PlaceCount: 2                        |        |             |
|-----------------------------------------------------------------------------|
| testRscGrp    | PlaceCount: 2                        |        |             |
|               | ReplicasOnSame: ['Aux/testProperty'] |        |             |
+-----------------------------------------------------------------------------+
すべてがうまくいくと、DRBDリソースがLINSTORによって作成されます。 lsblk コマンドでDRBDブロックデバイスを探すことで確認でき、 drbd0000 のように見えるはずです。

これでリソースのブロックデバイスをマウントしてLINSTORを使い始めることができるはずです。

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 コントローラー DB のリソースファイルを削除(および再生成)しないように LINSTOR サテライトサービスを構成することです。サービスファイルを直接編集するのではなく、 systemctl edit を使用してください。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はストレージプールのフォールバックを使用します。LINSTORは以下のオブジェクトに対してこの順番で問い合わせを行います。

  • ボリューム定義

  • リソース

  • リソース定義

  • ノード

どのオブジェクトも 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",

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

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 – CentOS:yum
# 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/UserName : REST ユーザ名を指定する

  • 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 と呼びます。

サテライトノードが作成されると最初の netifdefault という名前で暗黙に作られます。node create コマンドで --interface-name オプションを指定することにより、別の名前を与えることができます。

追加のNICは以下のようにして作られます。

# linstor node interface create alpha 100G_nic 192.168.43.221
# linstor node interface create alpha 10G_nic 192.168.43.231

NICはIPアドレスのみのよって識別され、名前は任意でありLinuxによって使用されるインターフェイス名には関連しません。NICはストレージプールに割り当てられますので、リソースがそのストレージプールに作成されるときは常にDRBDトラフィックはそのNICを介して行われます。

# linstor storage-pool set-property alpha pool_hdd PrefNic 10G_nic
# linstor storage-pool set-property alpha pool_ssd PrefNic 100G_nic

FIXME describe how to route the controller <-> client communication through a specific netif.

2.8. 暗号化ボリューム

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

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

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

  1. コントローラでユーザセキュリティを無効にする(これは認証が実装されたあとに廃止になる予定です)

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

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

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

2.8.1. ユーザセキュリティを無効にする

Linstorコントローラのユーザセキュリティを無効にする操作は、一度行えばその後はこれが継続します。手順は以下のとおりです。

  1. systemctl stop linstor-controller でLinstorコントローラを止める

  2. /usr/share/linstor-server/bin/Controller -c /etc/linstor -d でLinstorコントローラをデバッグモードで立ち上げる

  3. デバックコンソールで setSecLvl secLvl(NO_SECURITY) を入力する

  4. デバックシャットダウンコマンドの shutdown でlinstor-controllerを止める

  5. systemctl start linstor-controller でコントローラを再び起動する

2.8.2. 暗号化のコマンド

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

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.3. 自動パスフレーズ

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

これを使用するには、 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. スナップショットの管理

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

2.10.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.10.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.10.3. スナップショットへのロールバック

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

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

# linstor snapshot rollback resource1 snap1

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

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

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

# linstor snapshot delete resource1 snap1

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

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

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

スナップショット転送を手動で開始するには、次を使用します。

# linstor snapshot ship --from-node nodeSource --to-node nodeTarget --resource resource1

デフォルトでスナップショット転送は 12000-12999 の範囲の tcp ポートを使用します。この範囲を変更するには、プロパティ SnapshotShipping/TcpPortRange をコントローラーに設定します。

# 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.11. リソースのオプション設定

DRBDのオプションはLINSTORコマンドで設定します。LINSTORによって管理されていない /etc/drbd.d/global_common.conf のような構成ファイルは無視されます。以下のコマンドで使用法と有効なオプションが表示されます。

# linstor controller drbd-options -h
# linstor resource-definition drbd-options -h
# linstor volume-definition drbd-options -h
# linstor resource drbd-peer-options -h

例えばリソース名 backups のDRBDプロトコルを設定するには以下のようにします。

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

2.12. ディスクの追加と削除

LINSTOR はディスクレスとディスクを持つことの間でリソースを変換することができます。これは resource create に似た構文を持つ resource toggle-disk コマンドを使用します。

例えば ‘alpha’ 上にディスクレスリソース backups のディスクを追加するには以下のようにします。

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

このディスクを再び削除する:

# linstor resource toggle-disk alpha backups --diskless

2.12.1. ディスクの移行

冗長性を損なうことなくリソースをノード間で移動するには、LINSTOR のディスク移行機能を使用できます。最初にターゲットノードにディスクレスリソースを作成してから、–migrate-from オプションを使用してディスクを追加します。これは、データが新しいディスクに同期されるまで待機してから、ソースディスクを削除します。

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

# linstor resource create bravo backups --drbd-diskless
# linstor resource toggle-disk bravo backups --storage-pool pool_ssd --migrate-from alpha

2.13. LINSTORによるDRBD Proxy

LINSTORは、DRBD Proxyが接続するノード上で実行されることを期待しています。別のノードのDRBD Proxy経由の接続は、今のところサポートしていません。

ここでクラスタが、ローカルネットワーク内のノード ‘alpha’ と ‘bravo’ とリモートサイトの ‘charlie’ で構成され、各ノードに配備されるリソースは backups と仮定すると、DRBD Proxyを使用した ‘charlie’ への接続を有効にするには以下のようにします。

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

DRBD Proxyのオプションは、次のコマンドで設定できます。

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

LINSTORは遠隔地へのレプリケーション用にDRBD構成を自動的には最適化しないので、プロトコルなどのいくつかの構成オプションを設定することをお勧めします。

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

設定を最適化するには、LINBITにお問い合わせください。

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

LINSTOR は、上記の 2 つのノード間のプロキシ接続を自動的に有効にするように構成することもできます。この自動化のために、LINSTOR は最初に各ノードがどのサイトにあるかを知る必要があります。

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

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

# linstor controller set-property DrbdProxy/AutoEnable true

このプロパティは、node, resource-definition, resource, resource-connection レベルでも設定できます(左から右に優先順位が高くなります。つまり controller が優先順位が最も低いレベルです)。

この初期化手順が完了すると、新しく作成されたすべてのリソースは、そのピアリソースへの DRBD プロキシを有効にする必要があるかどうかを自動的にチェックします。

2.14. 外部データベース

LINSTORはPostgresqlやMariaDBのような外部データベースとともに動作させることもでき、バージョン 1.1.0 以降では ETCD キーバリューストアもサポートされています。

外部データベースを使用するには、構成するいくつかの追加手順があります。linstor で使用する DB/スキーマとユーザーを作成し、これを /etc/linstor/linstor.toml で設定する必要があります。

2.14.1. PostgreSQL

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

[db]
user = "linstor"
password = "linstor"
connection_url = "jdbc:postgresql://localhost/linstor"

2.14.2. MariaDB/MySQL

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

[db]
user = "linstor"
password = "linstor"
connection_url = "jdbc:mariadb://localhost/LINSTOR?createDatabaseIfNotExist=true"
LINSTORの schema/database は LINSTOR として作成されます。よって、MariaDB の接続が LINSTOR schema を参照していることを確認してください。

2.14.3. ETCD

ETCD は、HA セットアップで LINSTOR データベースを簡単に分散させておくことができる分散 key-value ストアです。ETCD ドライバーはすでに LINSTOR-controller パッケージに含まれており、 linstor.toml で設定する必要があります。

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

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

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

2.15. LINSTOR REST-API

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

[http]
  enabled = true
  port = 3370
  listen_addr = "127.0.0.1"  # to disable remote access

REST-APIを使用する場合 https://app.swaggerhub.com/apis-docs/Linstor/Linstor/ から現在の資料を見つけることができます。

2.15.1. LINSTOR REST-API HTTPS

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

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

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 は生成されたキーストアファイルを安全にするためにパスワードを要求します。このファイルは LINSTOR コントローラの設定で必要になります。linstor.toml ファイルに次のセクションを追加します。

[https]
  keystore = "/path/to/keystore_linstor.jks"
  keystore_password = "linstor"

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

他の証明書をインポートする方法の詳細は、 https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html を参照ください。

HTTPS が有効な場合、HTTP /v1/ REST-API へのすべてのリクエストは HTTPS にリダイレクトされます。
LINSTOR REST-API HTTPS 制限付きクライアントアクセス

クライアントアクセスは、コントローラの SSL トラストストアを使用して制限できます。基本的には、クライアント用の証明書を作成し、それをトラストストアに追加します。クライアントは認証にこの証明書を使用します。

最初にクライアント証明書を作成します。

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"

次に、この証明書をコントローラのトラストストアにインポートします。

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

そして linstor.toml 設定ファイルのトラストストアを有効にします。

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

そしてコントローラを再起動することで、証明書なしではコントローラ API にアクセスできなくなります。

LINSTOR クライアントは PEM 形式の証明書が必要なので、使用する前に Java キーストア証明書を PEM 形式に変換する必要があります。

# 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

PEM ファイルのパスワードを常に入力しないようにするには、以下のようにします。

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

これでこの PEMファイルをクライアントで使用できるようになります。

linstor --certfile client1.pem node list

--certfile パラメータをクライアント設定ファイルに追加することもできます。詳細は LINSTORクライアントの使用 を参照してください。

2.16. ロギング

LINSTOR は SLF4JLogback を使用しています。これにより、LINSTOR はログレベル ERROR, WARN, INFO, DEBUG, TRACE (冗長性の順) を区別することができます。現在の LINSTOR バージョン (1.1.2) では、ログレベルを制御するために、ユーザーは次の4つの方法を使用できます(上から優先度順に並んでいます)。

  1. TRACE モードは、デバッグコンソールを使用して enabled または disabled にできます。

    Command ==> SetTrcMode MODE(enabled)
    SetTrcMode           Set TRACE level logging mode
    New TRACE level logging mode: ENABLED
  2. コントローラまたはサテライトを起動するときに、コマンドライン引数を渡すことができます。

    java ... com.linbit.linstor.core.Controller ... --log-level INFO
    java ... com.linbit.linstor.core.Satellite  ... --log-level INFO
  3. 推奨される場所は、構成ファイルの logging セクションです。デフォルトの設定ファイルの場所は、コントローラの場合は /etc/linstor/linstor.toml 、サテライトの場合は /etc/linstor/linstor_satellite.toml です。次のようにログレベルを構成します。

    [logging]
       level="INFO"
  4. LINSTOR は実装として Logback を使用しているため /usr/share/linstor-server/lib/logback.xml も使用できます。現在、このアプローチのみが、以下の例に示すように、さまざまなコンポーネントのさまざまなログレベルをサポートしています。

    <?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="INFO" additivity="false">
       <appender-ref ref="STDOUT" />
       <!-- <appender-ref ref="FILE" /> -->
     </logger>
     <logger name="LINSTOR/Satellite" level="INFO" additivity="false">
       <appender-ref ref="STDOUT" />
       <!-- <appender-ref ref="FILE" /> -->
     </logger>
     <root level="WARN">
       <appender-ref ref="STDOUT" />
       <!-- <appender-ref ref="FILE" /> -->
     </root>
    </configuration>

logback.xml の詳細は Logback Manual を参照してください。

上記の設定方法のいずれも使用されない場合、LINSTOR はデフォルトで INFO ログレベルになります。

2.17. 監視

LINSTOR 1.8.0 以降、 Prometheus /metrics HTTP パス がLINSTOR および JVM 固有の方法で提供されています。

/metrics パスは LINSTOR のレポートデータ量を減らすために 3 つの GET 引数もサポートします。

  • resource

  • storage_pools

  • error_reports

これらはすべてデフォルトで true であり、無効にするには、例えば error-report データの場合 http://localhost:3370/metrics?error_reports=false とします。

2.17.1. ヘルスチェック

LINSTOR-Controller は、コントローラーがデータベースにアクセスでき、すべてのサービスが稼働している場合に HTTP-Status 200 を返す /health HTTPパスも提供します。それ以外の場合は、HTTP エラーステータスコード 500 Internal Server Error が返されます。

2.18. サテライトへの安全な接続

LINSTOR でコントローラとサテライト間の接続に SSL セキュア TCP 接続を使用することができます。Java の SSL エンジンの動作について詳しく調査しなくても、Java の実行時環境の keytool を使用したコマンドラインの使用例を以下に示します。ここでは、 安全な接続を使用して 3 ノードのセットアップを構成する方法を示します。

ここで、ノード alpha がコントローラ、ノード bravocharlie がサテライトとします。

以下にキーストア設定を生成するコマンド例を示します。環境に合わせて変更してください。

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


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

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

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

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

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

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

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

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

# generate the satellite ssl config entry
echo '[netcom]
  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 root@bravo "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 root@charlie "cat > /etc/linstor/linstor_satellite.toml"

controller と satellites を起動し、--communication-type SSL でノードを追加してください。

2.19. DRBD リソースの自動化

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

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

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

これは、linstor-controllerresource-group、および resource-definition に適用できる DrbdOptions/auto-quorum プロパティで制御されます。 DrbdOptions/auto-quorum プロパティには、 disabledsuspend-io 、および io-error を設定できます。

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

DrbdOptions/auto-quorum のデフォルトのポリシーは quorum majority および on-no-quorum io-error です。 DRBDのクォーラム機能とその動作の詳細については、 DRBDユーザーズガイドのクォーラム を参照してください。
Drbdoptions/auto-quorum が有効な場合、 Drbdoptions/auto-quorum ポリシーは手動で設定されたプロパティを上書きします。

たとえば、 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 majority
# linstor resource-group set-property my_ssd_group DrbdOptions/Resource/on-no-quorum suspend-io

DRBDのクォーラム機能を完全に無効にすることもできます。これを行うには、まず適切なLINSTORオブジェクトで DrbdOptions/auto-quorum を無効にします。そしてここにDRBDクォーラム機能を設定します。例えば my_ssd_groupresource-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
上記のコマンドで DrbdOptions/Resource/on-no-quorum を空の値に設定すると、プロパティがオブジェクトから完全に削除されます。

2.19.2. 自動取り除き

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

この機能は、次のプロパティを使用して動作を調整します。

DrbdOptions/AutoEvictMinReplicaCount は、常に存在する必要があるレプリカの数を設定します。このプロパティをコントローラに設定してグローバルデフォルトを変更したり、特定の resource-definition または resource-group に設定して、その resource-definition または resource-group に対してのみ変更したりできます。このプロパティを空のままにすると、対応する resource-group の auto-place に設定された値が place-count に使用されます。

DrbdOptions/AutoEvictAfterTime は、取り除きがトリガーされる前にノードがオフラインにできる時間を分単位で示します。このプロパティをコントローラーで設定してグローバルデフォルトを変更することも、単一ノードで設定して別の動作を与えることもできます。このプロパティのデフォルト値は 60 分です。

DrbdOptions/AutoEvictMaxDisconnectedNodes は、(何らかの理由で)同時に到達できないノードの割合を設定します。指定された割合を超えるノードが同時にオフラインになっている場合、LINSTOR はコントローラーからの接続の問題を想定し、どのノードに対しても自動取り除きをトリガーしません。このプロパティはコントローラにのみ設定でき、0〜100 の値のみを受け入れます。デフォルト値は 34 です。auto-evict-feature をオフにする場合は、このプロパティを 0 に設定します。到達不能なサテライトの数に関係なく、常に自動取り除きをトリガーしたい場合は 100 に設定します。

DrbdOptions/AutoEvictAllowEviction は、ノードの取り除きを停止できる追加のプロパティです。これは、メンテナンスのためにノードをシャットダウンする必要がある場合など、さまざまな場合に役立ちます。このプロパティをコントローラーで設定してグローバルデフォルトを変更することも、単一ノードで設定して別の動作を与えることもできます。値として true と false を受け入れ、デフォルトではコントローラーで true に設定されます。このプロパティを使用して、コントローラーで false に設定することにより、自動取り除き機能をオフにできます。ただし、個々のノードに異なる値を既に設定している場合、これらの値はグローバルデフォルトよりも優先されるため、完全には機能しない可能性があります。

linstor-controller がサテライトへの接続を失うと、再接続を試みる以外に、そのサテライトのタイマーを開始します。そのタイマーが DrbdOptions/AutoEvictAfterTime を超え、そのサテライトの DRBD-resources へのすべての DRBD 接続が切断されると、コントローラーはすぐに DrbdOptions/AutoEvictMaxDisconnectedNodes に該当するかを確認します。該当しない場合でかつ、問題のノードに対して DrbdOptions/AutoEvictAllowEviction が true の場合、サテライトは EVICTED としてマークされます。同時に、コントローラーはすべての DRBD リソースについて、リソースの数が DrbdOptions/AutoEvictMinReplicaCount を満たすかどうかを確認します。満たす場合、問題のリソースは DELETED としてマークされます。満たさない場合、対応するリソースグループからの設定による自動配置が開始されます。自動配置が失敗した場合、新しいノードの追加など、別の結果を可能にする変更が発生したときに、コントローラーは後で再試行します。自動配置が必要なリソースは、対応する自動配置が成功した場合にのみ DELETED としてマークされます。

取り除かれたサテライト自体は、コントローラーとの接続を再確立できません。ノードが稼働している場合でも、手動での再接続は失敗します。また、正常に動作していても、サテライトを削除することはできません。取り除かれたノードを削除したい場合は node lost コマンドを使用する必要があります。ただし、サテライトは復元できます。サテライトから EVICTED フラグを削除することにより、再度使用できるようになります。以前に構成されたネットワークインターフェイス、ストレージプール、プロパティ、および同様のエンティティ、および DRBD に関連しないリソースと、他の場所に自動配置できなかったリソースは、引き続きサテライト上にあります。サテライトを復元するには以下を実行します。

# linstor node restore [nodename]

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

2.20. QoS設定

2.20.1. Sysfs

LINSTORは、次のSysfsの設定ができます。

SysFs Linstor property

/sys/fs/cgroup/blkio/blkio.throttle.read_bps_device

sys/fs/blkio_throttle_read

/sys/fs/cgroup/blkio/blkio.throttle.write_bps_device

sys/fs/blkio_throttle_write

/sys/fs/cgroup/blkio/blkio.throttle.read_iops_device

sys/fs/blkio_throttle_read_iops

/sys/fs/cgroup/blkio/blkio.throttle.write_iops_device

sys/fs/blkio_throttle_write_iops

LINSTOR ボリュームが複数の “stacked” ボリュームで構成されている場合(たとえば、外部メタデータを持つ DRBD には、下位(ストレージ)デバイス、メタデータデバイス、およびその DRBD デバイスの 3 つのデバイスがあります)、ボリュームの sys/fs/\* プロパティを設定することは、最下部のローカル “data” デバイスのみが対応する /sys/fs/cgroup/…​ 設定を受け取ります。つまり、この例の場合、下位デバイスのみが設定を受け取ります。リソース定義が nvme-target および nvme-initiator リソースを持つ場合、各ノードの最下部のデバイスの両方が設定を受け取ります。ターゲットの場合、最下部のデバイスは LVM または ZFS のボリュームになりますが、イニシエーターの場合、最下部のデバイスは接続された nvme デバイスになります。その上に他のどのレイヤーがスタックされているかは関係ありません。

2.21. ヘルプの利用

2.21.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.21.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.21.3. コミュニティの助けを借りる

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

2.21.4. GitHub

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

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

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

3. Kubernetes で LINSTOR ボリューム

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

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

3.1. Kubernetesの概要

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

3.2. Kubernetes への LINSTOR のデプロイ

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

LINBIT は LINSTOR オペレーターを商用サポート顧客に提供します。オペレーターは、DRBD のインストール、サテライトポッドとコントローラポッドの管理、およびその他の関連機能により、LINSTOR を Kubernetes に簡単にデプロイできます。

オペレーター自体は、次のように Helm v3 チャートを使用してインストールされます。

  • 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 インスタンスのストレージを構成します。LINSTOR の etcd インスタンスを構成するためにいくつかオプションがあります。

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

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

    • Disable persistence, for basic testing only. This can be done by adding --set etcd.persistentVolume.enabled=false to the helm install command below.

  • ストレージの構成 を確認し、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.0.30
    • ホストマシンに既に存在するモジュールのみを挿入します。モジュールが見つからない場合は、スキップされます。

      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 etcd hostPath 永続化

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

By default, a PV is created on every control-plane node. You can manually select the storage nodes by passing --set "nodes={<NODE0>,<NODE1>,<NODE2>}" to the install command.

既存のデータベースの使用

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.2. ストレージの構成

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 ストレージプールの作成をサポートしています。

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

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

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

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

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

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

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

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

  • volumeGroup シンプールに使用する VG。 devicePaths を使用する場合は、これを "" に設定する必要があります。LINSTOR ではデバイスの準備時に VG 名を構成できないため、これが必要です。

  • thinVolume シンプールの名前。必須

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

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

LVMTHIN プール用に LINSTOR によって作成されたボリュームグループは、常にスキーム “linstor_$THINPOOL” に従います。
zfsPools 構成
  • 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.3. 安全なデプロイメント

このセクションでは、オペレーターを使用するときに使用できるセキュリティ機能を有効にするためのさまざまなオプションについて説明します。以下のガイドは 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 によって保護されていません。必要な場合は、次の手順に従い設定します。

  • 1 つはコントローラー用、もう 1 つはすべてのサテライト用に、Java キーストア形式で秘密鍵を作成します。

keytool -keyalg rsa -keysize 2048 -genkey -keystore satellite-keys.jks -storepass linstor -alias satellite -dname "CN=XX, OU=satellite, O=Example, L=XX, ST=XX, C=X"
keytool -keyalg rsa -keysize 2048 -genkey -keystore control-keys.jks -storepass linstor -alias control -dname "CN=XX, OU=control, O=Example, L=XX, ST=XX, C=XX"
  • 各コンポーネントが信頼できるよう公開鍵を伴うトラストストアを作成します。

  • コントローラはサテライトを信頼する必要があります。

  • ノードはコントローラーを信頼する必要があります。

    keytool -importkeystore -srcstorepass linstor -deststorepass linstor -srckeystore control-keys.jks -destkeystore satellite-trust.jks
    keytool -importkeystore -srcstorepass linstor -deststorepass linstor -srckeystore satellite-keys.jks -destkeystore control-trust.jks
  • コントローラとサテライトポッドに渡す kubernetes シークレットを作成します。

    kubectl create secret generic control-secret --from-file=keystore.jks=control-keys.jks --from-file=certificates.jks=control-trust.jks
    kubectl create secret generic satellite-secret --from-file=keystore.jks=satellite-keys.jks --from-file=certificates.jks=satellite-trust.jks
  • 作成したシークレットの名前を helm install に渡します。

    --set operator.satelliteSet.sslSecret=satellite-secret --set operator.controller.sslSecret=control-secret
現在、キーストアのパスワードを変更することはできません。LINSTOR はパスワードが linstor であると想定しています。これは LINSTOR の現在の制限です。
LINSTOR API の安全な通信の構成

さまざまなコンポーネントが REST インターフェースを介して LINSTOR コントローラーと通信する必要があります。このインターフェースは、自動的に認証を含む HTTPS を介して保護できます。HTTPS 認証が機能するためには、各コンポーネントが以下にアクセスする必要があります。

  • 秘密鍵

  • キーに基づく証明書

  • 他のコンポーネントが信頼できることを確認するために使用される信頼できる証明書

次のセクションでは、必要なすべてのコンポーネントの作成について説明します。

秘密鍵の作成

秘密鍵は Java の keytool を使用して作成できます。

keytool -keyalg rsa -keysize 2048 -genkey -keystore controller.pkcs12 -storetype pkcs12 -storepass linstor -ext san=dns:linstor-op-cs.default.svc -dname "CN=XX, OU=controller, O=Example, L=XX, ST=XX, C=X" -validity 5000
keytool -keyalg rsa -keysize 2048 -genkey -keystore client.pkcs12 -storetype pkcs12 -storepass linstor -dname "CN=XX, OU=client, O=Example, L=XX, ST=XX, C=XX" -validity 5000

クライアントは異なる形式の秘密鍵と証明書を必要とするため、変換する必要があります。

openssl pkcs12 -in client.pkcs12 -passin pass:linstor -out client.cert -clcerts -nokeys
openssl pkcs12 -in client.pkcs12 -passin pass:linstor -out client.key -nocerts -nodes
コントローラキーで指定されたエイリアス(つまり -ext san=dns:linstor-op-cs.default.svc )は、オペレーターが作成したサービス名と完全に一致する必要があります。 helm を使用する場合は、これは常に <release-name>-cs.<release-namespace>.svc の形式になります。
現在、キーストアのパスワードを変更することはできません。LINSTOR は、パスワードが linstor であると想定しています。これは LINSTOR の現在の制限です。
信頼できる証明書の作成

コントローラがクライアントを信頼するには、次のコマンドを使用してトラストストアを作成し、クライアント証明書をインポートします。

keytool -importkeystore -srcstorepass linstor -srckeystore client.pkcs12 -deststorepass linstor -deststoretype pkcs12 -destkeystore controller-trust.pkcs12

クライアントの場合、コントローラ証明書を別の形式に変換する必要があります。

openssl pkcs12 -in controller.pkcs12 -passin pass:linstor -out ca.pem -clcerts -nokeys
Kubernetes シークレットの作成

これで、コントローラとクライアントのシークレットを作成できます。

kubectl create secret generic http-controller --from-file=keystore.jks=controller.pkcs12 --from-file=truststore.jks=controller-trust.pkcs12
kubectl create secret generic http-client --from-file=ca.pem=ca.pem --from-file=client.cert=client.cert --from-file=client.key=client.key

シークレットの名前を helm install に渡して、すべてのクライアントが https を使用するように設定できます。

--set linstorHttpsControllerSecret=http-controller  --set linstorHttpsClientSecret=http-client
暗号化されたボリュームのパスフレーズを自動設定

Linstor は LUKS を使用して暗号化されたボリュームを作成するために使用できます。これらのボリュームを作成するときに使用されるパスフレーズは、シークレットを介して設定できます。

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

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 用にコンパイル済みのカーネルモジュールを使用してインストールします。さらに、この例では Stork スケジューラーを無効にします。

この例の 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" --set stork.enabled=false
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.4. 高度なデプロイメントオプション

helm チャートは、より高度な使用のための追加オプションを提供します。

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:
  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.6.5
  schedulerImage: k8s.gcr.io/kube-scheduler-amd64
  schedulerTag: ""
  replicas: 1 (2)
  storkResources: {} # resources requirements for the stork plugin containers (3)
  schedulerResources: {} # resource requirements for the kube-scheduler containers (3)
  podsecuritycontext: {}
csi:
  enabled: true
  pluginImage: "drbd.io/linstor-csi:v0.15.0"
  csiAttacherImage: k8s.gcr.io/sig-storage/csi-attacher:v3.3.0
  csiLivenessProbeImage: k8s.gcr.io/sig-storage/livenessprobe:v2.4.0
  csiNodeDriverRegistrarImage: k8s.gcr.io/sig-storage/csi-node-driver-registrar:v2.3.0
  csiProvisionerImage: k8s.gcr.io/sig-storage/csi-provisioner:v2.2.2
  csiSnapshotterImage: k8s.gcr.io/sig-storage/csi-snapshotter:v4.2.1
  csiResizerImage: k8s.gcr.io/sig-storage/csi-resizer:v1.3.0
  controllerReplicas: 1 (2)
  nodeAffinity: {} (4)
  nodeTolerations: [] (4)
  controllerAffinity: {} (4)
  controllerTolerations: [] (4)
  enableTopology: true
  resources: {} (3)
  kubeletPath: /var/lib/kubelet (7)
priorityClassName: ""
drbdRepoCred: drbdiocred
linstorHttpsControllerSecret: "" # <- name of secret containing linstor server certificates+key.
linstorHttpsClientSecret: "" # <- name of secret containing linstor client certificates+key.
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.6.0"
  affinity: {} (4)
  tolerations: [] (4)
  resources: {} (3)
  podsecuritycontext: {}
  controller:
    enabled: true
    controllerImage: "drbd.io/linstor-controller:v1.15.0"
    luksSecret: ""
    dbCertSecret: ""
    dbUseClientCert: false
    sslSecret: ""
    affinity: {} (4)
    tolerations: (4)
      - key: node-role.kubernetes.io/master
        operator: "Exists"
        effect: "NoSchedule"
    resources: {} (3)
    replicas: 1 (2)
    additionalEnv: [] (5)
    additionalProperties: {} (6)
  satelliteSet:
    enabled: true
    satelliteImage: "drbd.io/linstor-satellite:v1.15.0"
    storagePools: {}
    sslSecret: ""
    automaticStorageType: None
    affinity: {} (4)
    tolerations: [] (4)
    resources: {} (3)
    monitoringImage: "drbd.io/drbd-reactor:v0.4.4"
    kernelModuleInjectionImage: "drbd.io/drbd9-rhel7:v9.0.30"
    kernelModuleInjectionMode: ShippedModules
    kernelModuleInjectionResources: {} (3)
    additionalEnv: [] (5)
haController:
  enabled: true
  image: drbd.io/linstor-k8s-ha-controller:v0.2.0
  affinity: {} (4)
  tolerations: [] (4)
  resources: {} (3)
  replicas: 1 (2)
1 すべてのイメージのプルポリシーを設定します。
2 各コンポーネントのレプリカ数を制御します。
3 コンテナリソースのリクエストと制限を設定します。詳細は kubernetes ドキュメント を参照ください。以下を除いて、ほとんどのコンテナには最小限のリソースが必要です。
  • etcd.resources etcd docs を参照

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

  • operater.satelliteSet.resources700MiB のメモリが必要

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

4 Affinity と Toleration によって、ポッドがクラスター上でスケジュールされる場所が決まります。詳細は Affinity と Toleration に関する Kubernetes のドキュメント を参照ください。これは operator.satelliteSet および csi.node* の値にとって特に重要です。LINSTOR 永続ボリュームを使用してポッドをスケジュールするには、実行中の LINSTOR サテライトと LINSTOR CSI ポッドがノードに必要です。
5 Linstor コントローラーとサテライトに渡す追加の環境変数を設定します。 コンテナ環境変数 と同じフォーマットを使用します。
6 Linstor コントローラーに追加のプロパティを設定します。単純な <property-key>: <value> マッピングを使用します。
7 Kubelet expects every CSI plugin to mount volumes under a specific subdirectory of it’s own state directory. By default, this state directory is /var/lib/kubelet. Some Kubernetes distributions use a different directory:
  • microk8s: /var/snap/microk8s/common/var/lib/kubelet

高可用性デプロイメント

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

Prometheus による監視

Linstor Operator v1.5.0 以降 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.5. 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 を作成することにより、新しいボリュームをプロビジョニングできます。ボリュームは、最初に、指定されたストレージプールを持つノード、つまりストレージインフラストラクチャにのみ配置されます。pod でボリュームを使用する場合、LINSTOR CSI は Kubernetes ノードにディスクレスリソースを作成し、ネットワークを介してディスクリソースに接続します。

3.2.6. 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-85b4f757f5-kxdvn ┊ 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-2f982fb4-bc05-4ee5-b15b-688b696c8526 ┊ kube-node-01.test ┊ 7000 ┊ Unused ┊ Ok    ┊   UpToDate ┊ 2021-02-05 09:16:09 ┊
┊ pvc-2f982fb4-bc05-4ee5-b15b-688b696c8526 ┊ kube-node-02.test ┊ 7000 ┊ Unused ┊ Ok    ┊ TieBreaker ┊ 2021-02-05 09:16:08 ┊
┊ pvc-2f982fb4-bc05-4ee5-b15b-688b696c8526 ┊ 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 1. 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 plugin 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 plugin's deployment
  storagePool: "drbdpool"
  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

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

kubectl create -f linstor-basic-sc.yaml

StorageClass が作成されたので、KubernetesとLINSTOR の両方に認識されるボリュームをプロビジョニングするために使用できる PersistentVolumeClaim を作成できます。

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

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

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

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

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

ボリュームを削除するには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 で使用可能なパラメータ

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

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
  autoPlace: "2"
  placementCount: "2"
  resourceGroup: "full-example"
  storagePool: "my-storage-pool"
  disklessStoragePool: "DfltDisklessStorPool"
  layerList: "drbd storage"
  placementPolicy: "AutoPlaceTopology"
  allowRemoteVolumeAccess: "true"
  encryption: "true"
  nodeList: "diskful-a diskful-b"
  clientList: "diskless-a diskless-b"
  replicasOnSame: "zone=a"
  replicasOnDifferent: "rack"
  disklessOnRemaining: "false"
  doNotPlaceWithRegex: "tainted.*"
  fsOpts: "nodiscard"
  mountOpts: "noatime"
  postMountXfsOpts: "extsize 2m"
  # Linstor properties
  property.linstor.csi.linbit.com/*: <x>
  # DRBD parameters
  DrbdOptions/*: <x>

3.4.2. csi.storage.k8s.io/fstype

volumeMode: FileSystem PVC 用に作成するファイルシステムタイプを設定します。現在サポートされているのは次のとおりです。

  • ext4 (デフォルト)

  • xfs

3.4.3. autoPlace

autoPlace はこの StorageClass が持つボリュームの複製数を指定します。例えば、 autoPlace: "3" は3つの複製をもつボリュームを生成します。 autoPlace または nodeList が指定されていない場合は、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, the default: Use topology information from Kubernetes together with user provided constraints (see replicasOnSame and replicasOnDifferent).

  • AutoPlace Use LINSTOR autoplace, influenced by replicasOnSame and replicasOnDifferent

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

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

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

3.4.10. allowRemoteVolumeAccess

ボリュームへのリモートアクセスを無効にします。これは、ボリュームは、作成時に選択されたノードの初期セットからのみアクセスできることを意味します。ポッドを正しいノードに配置するには、CSI トポロジ処理が必要です。

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 ノードのプロパティに対応しています。

The operator periodically synchronizes all labels from Kubernetes Nodes, so you can use them as keys for scheduling constraints.

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. スナップショット

スナップショット の作成とスナップショットから新規ボリュームを作成するには VolumeSnapshot, VolumeSnapshotClass, PVC を通して行われます。

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

LINSTOR supports the volume snapshot feature, which is configured in some, but not all Kubernetes distributions.

To check if your Kubernetes distribution supports snapshots out of the box, run the following command:

$ 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

In case your Kubernetes distribution does not support snapshots, you can manually add the required components from the Kubernetes Storage SIG. For convenience, you can use Helm Charts provided by the Piraeus team to add these components.

Listing 3. Adding snapshot support using the Piraeus Charts
$ 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 4. 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 5. 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 6. 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

3.6. ボリュームへのアクセス

LINSTORボリュームは通常、ローカルか クライアント としてアクセスされます。

Pod がその基礎となるストレージが存在する kubelet にスケジュールされている場合、デフォルトでCSIプラグインはボリュームを直接接続します。しかしPod スケジューリングは現在ボリュームがローカルかどうか考慮に入れていません。 replicasOnSame パラメータで、ローカルに接続されたボリュームが必要な場合、ストレージをプロビジョニングできる場所を制限できます。

このデフォルトの動作を変更するには placementPolicy を参照ください。

3.7. Stork を使用したボリューム局所性最適化

Stork は、Kubernetes のスケジューラ拡張プラグインであり、ストレージドライバーは、Kubernetes スケジューラーに新しいポッドを配置する場所に関するヒントを与え、ストレージパフォーマンスのために最適な場所に配置できるようにします。プロジェクトの詳細については、 GitHub ページ 参照ください。

次の Stork リリースには、デフォルトで LINSTOR ドライバーが含まれます。それまでの間は Docker ハブで利用可能 から LINBIT によってカスタム構築された LINSTOR ドライバー を含む Stork コンテナを使用できます。

3.7.1. Stork の使用

デフォルトでは、オペレーターは Stork に必要なコンポーネントをインストールし、Kubernetes に stork という新しいスケジューラーを登録します。この新しいスケジューラを使用して、ポッドをボリュームの近くに配置できます。

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
spec:
  schedulerName: stork (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 スケジューラの名前をポッドに追加します。

スケジューラのデプロイメントは以下で無効にできます。

--set stork.enabled=false

3.8. 高可用性コントローラーを使用した高速ワークロードフェイルオーバー

LINSTOR 高可用性コントローラー(HA コントローラー)は、ストレージに LINSTOR を使用して、ステートフルワークロードのフェイルオーバープロセスを高速化します。デフォルトでデプロイされ、複数のレプリカにスケーリングされます。

$ kubectl get pods -l app.kubernetes.io/name=linstor-op-ha-controller
NAME                                       READY   STATUS    RESTARTS   AGE
linstor-op-ha-controller-f496c5f77-fr76m   1/1     Running   0          89s
linstor-op-ha-controller-f496c5f77-jnqtc   1/1     Running   0          89s
linstor-op-ha-controller-f496c5f77-zcrqg   1/1     Running   0          89s

ノードに障害が発生した場合、Kubernetes はステートフルワークロードの再スケジュールを非常に慎重に行います。これは、ポッドが到達不能なノードから移動されるまでに 15 分以上かかる可能性があることを意味します。DRBD と LINSTOR が利用できる情報により、このプロセスを大幅にスピードアップできます。

HA コントローラーは、以下に対して高速フェイルオーバーを有効にします。

  • DRBD でバックアップされた PersistentVolumes を使用するポッド。DRBD リソースは、クォーラム機能を使用する必要があります。LINSTOR は、少なくとも 3 つのノードを持つクラスター内の 2 つ以上のレプリカを持つボリュームに対してこれを自動的に構成します。

  • ワークロードが、2 つのインスタンスが同時に外部リソースを使用しようとした場合に、競合状態につながる可能性のある方法で外部リソースを使用していないとき。 DRBD は、1 つのインスタンスのみがストレージへの書き込みアクセス権を持つことができることを保証できますが、外部リソースに対して同じ保証を提供することはできません。

  • ポッドに linstor.csi.linbit.com/on-storage-lost: remove ラベルが付いている。

3.8.1. サンプル

次の StatefulSet は、HA コントローラーを使用してポッドのフェイルオーバーを管理します。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-stateful-app
spec:
  serviceName: my-stateful-app
  selector:
    matchLabels:
      app.kubernetes.io/name: my-stateful-app
  template:
    metadata:
      labels:
        app.kubernetes.io/name: my-stateful-app
        linstor.csi.linbit.com/on-storage-lost: remove (1)
    ...
1 ラベルは、StatefulSet ではなくポッドテンプレートに適用されます。ポッドが kubectl get pods -l linstor.csi.linbit.com/on-storage-lost=remove の出力に表示される場合、ラベルは正しく適用さています。

セットをデプロイし、ポッドが開始するのを待ちます。

$ kubectl get pod -o wide
NAME                                        READY   STATUS              RESTARTS   AGE     IP                NODE                    NOMINATED NODE   READINESS GATES
my-stateful-app-0                           1/1     Running             0          5m      172.31.0.1        node01.ha.cluster       <none>           <none>

次に、ノードの 1 つが到達不能になります。その後まもなく、Kubernetes はノードを NotReady としてマークします

$ kubectl get nodes
NAME                    STATUS     ROLES     AGE    VERSION
master01.ha.cluster     Ready      master    12d    v1.19.4
master02.ha.cluster     Ready      master    12d    v1.19.4
master03.ha.cluster     Ready      master    12d    v1.19.4
node01.ha.cluster       NotReady   compute   12d    v1.19.4
node02.ha.cluster       Ready      compute   12d    v1.19.4
node03.ha.cluster       Ready      compute   12d    v1.19.4

約 45 秒後、ポッドは HA コントローラーによって削除され、StatefulSet によって再作成されます。

$ kubectl get pod -o wide
NAME                                        READY   STATUS              RESTARTS   AGE     IP                NODE                    NOMINATED NODE   READINESS GATES
my-stateful-app-0                           0/1     ContainerCreating   0          3s      172.31.0.1        node02.ha.cluster       <none>           <none>
$ kubectl get events --sort-by=.metadata.creationTimestamp -w
...
0s          Warning   ForceDeleted              pod/my-stateful-app-0                                                                   pod deleted because a used volume is marked as failing
0s          Warning   ForceDetached             volumeattachment/csi-d2b994ff19d526ace7059a2d8dea45146552ed078d00ed843ac8a8433c1b5f6f   volume detached because it is marked as failing
...

3.9. 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.9.1. 特定のバージョンのアップグレード手順

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

Upgrade to v1.6

This versions introduces a new option to support Kubernetes distributions which use different state directories than the default of /var/lib/kubelet. A notable example is microk8s, which uses /var/snap/microk8s/common/var/lib/kubelet. To support this, a small addition to the LinstorCSIDriver CRD was necessary. As Helm does not upgrade CRDs on chart upgrade, instead please run:

$ 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

If you do not apply the new CRDs, you will get errors like the following:

Error: UPGRADE FAILED: error validating "": error validating data: ValidationError(LinstorCSIDriver.spec): unknown field "kubeletPath" in com.linbit.linstor.v1.LinstorCSIDriver.spec

If you previously used the included snapshot-controller to process VolumeSnapshot resources, you should replace it with the new charts provided by the Piraeus project. The section on snapshots has been updated to include instructions on how you can add the snapshot-controller to your cluster.

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.9.2. 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 CSI プラグイン を使用してプロビジョニングされたボリュームによって管理された Openshift での LINSTOR の使用法について説明します。

4.1. Openshift の概要

OpenShift は、RedHat が公式に開発およびサポートする Kubernetes のディストリビューションです。

Red Hat の Openshift の価値の一部は、デフォルトの標準 Web コンソールに加えて、サポートされ認定されたイメージとオペレーターの独自のレジストリーが含まれていることです。この章では、これらのツールを使用して LINSTOR オペレーターをインストールする方法について説明します。

4.2. Openshift での LINSTOR のデプロイ

4.2.1. 始める前に

LINBITは、RedHat マーケットプレイスを介して認定された LINSTOR オペレーターを提供します。オペレーターは、DRBD のインストール、 サテライトとコントローラー pod の管理、およびその他の関連機能により、Kubernetes への LINSTOR のデプロイを容易にします。

オペレーター自体は Red Hat Marketplace から利用可能です。

ヘルムチャートを介したデプロイとは異なり、認定された Openshift オペレーターは必要な etcd クラスターをデプロイしません。これは事前に自分で展開する必要があります。これは operatorhub.io で入手できる etcd オペレーターを介して行います。

etcd デプロイメントには何らかのタイプの永続ストレージを使用することをお勧めします。デフォルトの StorageClass で既存のストレージプロビジョナーを使用するか、単に hostPath ボリュームを使用します。

ストレージガイド を読んで LINSTOR の基本的なストレージ設定を構成してください。

安全なデプロイメント を読んで、必要に応じて構成してください。

4.2.2. オペレーター pod のデプロイ

etcd とストレージが構成されたら、LINSTOR オペレーターをインストールする準備が整いました。 LINSTOR オペレーターは、Openshift Web コンソールの左側のコントロールペインから見つけることができます。 “Operators” セクションを展開し、 “OperatorHub” を選択します。ここから、LINSTOR オペレーターを見つける必要があります。 “LINSTOR” で検索するか、 “Marketplace” オペレーターのみでフィルタリングします。

LINSTOR オペレーターは、デプロイされているのと同じ名前空間(OwnNamsespace)内にあるイベントを監視し、カスタムリソースのみのを管理できます。つまり、LINSTOR コントローラー、LINSTOR サテライト、および LINSTOR CSI ドライバー pod はすべて、LINSTOR オペレーター pod と同じ名前空間でデプロイする必要があります。

マーケットプレイスで LINSTOR オペレーターを見つけたら、 “Install” ボタンをクリックして、他のオペレーターと同じようにインストールします。

この時点で、実行中の pod は 1 つだけです。オペレーター pod です。

次に、残りの提供された API を構成する必要があります。

4.2.3. LINSTOR コントローラーのデプロイ

ここで Openshift Web コンソールの左側のコントロールペインに再び移動します。 “Operators” セクションを展開しますが、今回は “Installed Operators” を選択します。 “Linstor Operator” のエントリを見つけて、右側の “Provided APIs” 列から “LinstorController” を選択します。

ここで “No Operands Found” というページが表示され、右側に “Create LinstorController” という大きなボタンが表示されます。 “Create LinstorController” ボタンをクリックします。

ここでは、LINSTOR コントローラーを構成するためのオプションが表示されます。 Web フォームビューまたは YAML ビューの選択するビューに関係なく、 dbConnectionURL が etcd デプロイメントから提供されるエンドポイントと一致することを確認してください。それ以外は、通常、たいていの用途でデフォルトで問題ありません。

最後に “Create” を押すと、linstor-controller pod が実行されているのがわかります。

4.2.4. LINSTOR サテライトのデプロイ

次に、Satellites セットをデプロイする必要があります。前と同じように、Openshift Web コンソールの左側のコントロールペインに移動します。 “Operators” セクションを展開し、 “Installed Operators” を選択します。 “Linstor Operator” のエントリを見つけて、右側の “Provided APIs” 列から “LinstorSatelliteSet” を選択します。

ここから、”No Operands Found” というページが表示され、右側に “Create LinstorSatelliteSet” という大きなボタンが表示されます。 “Create LinstorSatelliteSet” ボタンをクリックします。

ここでは、LINSTOR Satellites を構成するためのオプションが表示されます。 Web フォームビューまたは YAML ビューのいずれかで、最初に気付くオプションの 1 つは、 automaticStorageType です。 “NONE” に設定されている場合は、後のステップでストレージプールを自分で構成することを忘れないでください。

もう 1 つのオプションは、 kernelModuleInjectionMode です。通常、 環境に合わせてビルドする “Compile” を選択しますが、 “ShippedModules” を選択すると、コンパイル済みのカーネルモジュールがすべてのワーカーノードにインストールされるため、より素早く展開できます。

controllerEndpoint が kubernetes エンドポイントで利用可能なものと一致することを確認してください。通常、デフォルトで正しいです。

以下はマニフェストの例です。

apiVersion: linstor.linbit.com/v1
kind: LinstorSatelliteSet
metadata:
  name: linstor
  namespace: default
spec:
  satelliteImage: ''
  automaticStorageType: LVMTHIN
  drbdRepoCred: ''
  kernelModuleInjectionMode: Compile
  controllerEndpoint: 'http://linstor:3370'
  priorityClassName: ''
status:
  errors: []

最後に “Create” を押すと、すべてのワーカーノードで実行されている linstor-node pod が表示されます。

4.2.5. LINSTOR CSI ドライバーのデプロイ

残りの最後の pod は CSI と LINSTOR の間のレイヤーをブリッジする CSI pod です。前と同じように、Openshift Web コンソールの左側のコントロールペインに移動します。 “Operators” セクションを展開し、 “Installed Operators” を選択します。 “Linstor Operator” のエントリを見つけて、右側の “Provided APIs” 列から “LinstorCSIDriver” を選択します。

ここから、 “No Operands Found” というページが表示され、右側に “Create LinstorCSIDriver” という大きなボタンが表示されます。 “Create LinstorCSIDriver” ボタンをクリックします。

ここでも、オプションが表示されます。 controllerEnpoint が正しいことを確認してください。それ以外は、ほとんどのユースケースでデフォルトで問題ありません。

最後に “Create” を押します。これで、単一の “linstor-csi-controller” pod と、すべてのワーカーノードに “linstor-csi-node” pod が表示されます。

4.3. Openshift での LINSTOR の操作

コントローラ pod には LINSTOR クライアントが含まれているため、LINSTOR を直接操作するのは簡単です。例えば:

oc exec deployment/linstor-controller -- linstor storage-pool list

これは、問題を調査し、高度な機能にアクセスする場合にのみ必要です。ボリュームの作成などの通常の操作は、Kubernetes integration を介して実行する必要があります。

4.4. 構成とデプロイメント

オペレーターと必要なすべての pod がデプロイされると、ボリュームのプロビジョニングは通常の Kubernetes ワークフローに従います。

詳細は 基本的な構成とデプロイメント を参照ください。

4.5. 追加コンポーネントのデプロイ

Helm デプロイメントと比較した場合、一部の追加コンポーネントは LINSTOR オペレーターの OperatorHub バージョンに含まれていません。最も注目すべきは、Etcd のセットアップと STORK integration に関してです。

Etcd は、OperatorHub で利用可能な Etcd オペレーターを使用してデプロイできます。

4.5.1. Stork

STORK をデプロイするには、https://charts.linstor.io/deploy/stork.yaml で入手可能な単一の YAML デプロイメントを使用できます。YAML をダウンロードし、 MY-STORK-NAMESPACE のすべてのインスタンスを STORK の目的の名前空間に置き換えます。 また、 MY-LINSTOR-URL をコントローラーの URL に置き換える必要があります。この値は LinstorController リソースを作成 したときに選択した name によって異なります。デフォルトで、これは http://linstor.<operator-namespace>.svc:3370 になります。

YAML を Openshift に適用するには、コマンドラインから oc apply -f <filename> を実行します。または Openshift Web コンソールの右上にある “Import YAML” オプションを使用します。

4.5.2. 高可用性コントローラー

高可用性コントローラー をデプロイするには https://charts.linstor.io/deploy/ha-controller.yaml で入手可能な単一のYAMLデプロイメントを使用します。

YAML をダウンロードして、以下を置き換えます。

YAML を Openshift に適用するには、コマンドラインから oc apply -f <filename> を実行します。または Openshift Web コンソールの右上にある “Import YAML” オプションを使用します。

4.5.3. openshift で Helm を使用したデプロイ

openshift では、Helm を使用して LINSTOR オペレーターをデプロイすることもできます。 詳細は Kubernetes guide 参照ください。Openshift では、Helm チャートのデフォルト値の一部を変更する必要があります。

永続性のためにホストパスボリュームで Etcd を使用することを選択した場合( こちら を参照)、selinux の再ラベル付けを有効にする必要があります。これを行うには --set selinux=truepv-hostpath インストールコマンドに渡します。

LINSTOR オペレーターチャート自体については、以下の値を変更する必要があります。

global:
  setSecurityContext: false (1)
csi-snapshotter:
  enabled: false (2)
stork:
  schedulerTag: v1.18.6 (3)
etcd:
  podsecuritycontext:
    supplementalGroups: [1000] (4)
operator:
  satelliteSet:
    kernelModuleInjectionImage: drbd.io/drbd9-rhel8:v9.0.25 (5)
1 Openshift は SCCs を使用してセキュリティコンテキストを管理します。
2 クラスター全体の CSI スナップショットコントローラーは、Openshift によって既にインストールされています。
3 Openshift では KubernetesScheduler のバージョン自動検出が失敗するため、手動で設定する必要があります。タグは、Openshift の Kubernetes リリースと一致する必要はありません。
4 Helm を使用してデプロイされた Etcd を使用し、 pv-hostpath チャートを使用する場合、永続ボリュームにアクセスするには、Etcd をグループ 1000 のメンバーとして実行する必要があります。
5 RHEL8 カーネルインジェクターは RHCOS もサポートします。

ストレージプール構成、HA デプロイメントなど他にも変更な可能な設定があります。詳細は Kubernetes guide を参照ください。

5. NomadのLINSTORボリューム

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

5.1. Nomadの概要

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

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

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

5.2. NomadにLINSTORの展開

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

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

5.2.1. Nomadを準備する

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

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

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

    Listing 7. /etc/nomad.d/docker-privileged.hcl
    plugin "docker" {
      config {
        allow_privileged = true
      }
    }
  • コンテナネットワークのサポート。 Container Network Interface プラグインがインストールされていない場合は、ジョブネットワークで mode = "host" のみを使用できます。ほとんどの本番環境のセットアップでは、デフォルトのプラグインをインストールすることをお勧めします。

    plugin release page に移動し、ディストリビューションに適したリリースアーカイブを選択して、/opt/cni/bin に解凍します。解凍する前にディレクトリを作成する必要があるかもしれません。

  • ホストボリュームを提供して、ホストの /dev ディレクトリへのコンテナアクセスを許可する

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

    Listing 8. /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 9. 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コントローライメージが実行されるように設定されます。最新のイメージは 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"
Linstorsデータベースにホストボリュームを使用する

外部データベースを設定せずにLINSTORを試したい場合は、Linstors組み込みのファイルシステムベースのデータベースを利用できます。データベースを永続的にするには、データベースがホストボリュームに配置されていることを確認する必要があります。

ホストボリュームを使用すると、1つのノードのみでLINSTOR コントローラを実行できます。ノードが使用不可の場合は、LINSTOR クラスタも使用不可になります。代替策として、外部(高可用性)データベースを使用するか、 LINSTORクラスタをホストに直接導入 します。

LINSTOR データベース用のホストボリュームを作成するには、まず、必要な権限を持つディレクトリをホスト上に作成します。

$ mkdir -p /var/lib/linstor
$ chown -R 1000:0 /var/lib/linstor

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

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

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

Listing 11. job > group
volume "linstor-db" {
  type = "host"
  source = "linstor-db"
}
Listing 12. 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サテライトジョブを作成する

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

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

Listing 13. 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 14. /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 15. 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 16. 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 Plugin にあるProxmox VEでのDRBDについて説明します。

6.1. Proxmox VE概要

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

‘linstor-proxmox’がProxmox用のPerlプラグインで、Proxmox VEの複数のノードでVMディスクの複製にLINSTORとともに使われます。これにより実行中のVMのライブマイグレーションが無停止でかつ中央にSANディスクを用意せずに数秒で完了します。これはデータがすでに複数のノードに複製をされているからです。

6.2. アップグレード

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

6.2.1. 4.x から 5.x へ

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

LINSTOR の構成に関しては LINSTORの設定 を参照してください。以下に典型的は例を示します。プールが “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.2. 5.x から 6.x へ

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

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

LINBITはProxmox VEユーザのために専用のレポジトリを公開しています。ここにはProxmoxプラグインだけでなくDRBD SDSカーネルモジュールやユーザスペースユーティリティを含むすべてのDRBD SDSスタックが含まれます。

DRBD9のカーネルモジュールは dkms パッケージとして( drbd-dkms )インストールされるので、LINBITのレポジトリからインストールする前に pve-headers パッケージをインストールします。これに従うことでカーネルモジュールがこの環境用に構築されることが保証されます。最新のProxmoxカーネルでない場合は、現在のカーネルのバージョンに合う( pve-headers-$(uname -r) )カーネルヘッダーをインストールする必要があります。あるいは、現在のカーネルに対してdkmsパッケージを再構築する(ヘッダーをインストールする必要あります)必要がある場合は、apt install --reinstall drbd-dkms を実行します。

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/proxmox/ proxmox-$PVERS drbd-9" > \
	/etc/apt/sources.list.d/linbit.list
# apt update && apt install linstor-proxmox

6.4. LINSTORの設定

このガイドの残りの部分では クラスタの初期化 に基づいて LINSTOR クラスタが構成されていると仮定します。1 つのノードで “linstor-controller” を起動し、すべてのノードで “linstor-satellite” を起動します。また、バージョン 4.1.0 以降、このプラグインを使用する上で推奨する方法は、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 storage driver addon の使用法を説明します。

詳しいインストールと設定の手順は、ドライバのソースの 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のパッケージにアクセスすることができない場合は、 GitHubページ を確認してください。

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

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

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

7.3. 配備オプション

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

7.4. 構成

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"

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のアクセス権

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. OpenNebula リソースグループ

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

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

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

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_CLONE_MODE

Linstorは2つの異なるクローンモードをサポートし、 LINSTOR_CLONE_MODE 属性を介して設定します。

  • snapshot

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

  • copy

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

7.4.7. 廃止された属性

次の属性は非推奨であり、1.0.0リリース後のバージョンでは削除されます。

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

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

rocky

n/a

n/a

n/a

queens

n/a

n/a

n/a

pike

n/a

n/a

n/a

Linstor Driver を有効にする正しい手順は、OpenStack ディストリビューションによって異なります。一般に python-linstor パッケージは、Cinder ボリュームサービスを実行しているすべてのホストにインストールする必要があります。次のセクションでは、一般的な OpenStack ディストリビューションへのインストール手順について説明します。

DevStack

DevStack は、ラボ環境で OpenStack を試すのに最適な方法です。最新のドライバーを使用するには、次の DevStack 構成を使用します。

Listing 17. 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 18. template-override.j2
{% extends parent_template %}

# Cinder
{% set cinder_base_pip_packages_append = ['python-linstor'] %}

LINBIT バージョンのドライバーをインストールするには kolla-build.conf を更新します。

Listing 19. /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 20. /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 backends, kolla-ansible only supports a small subset of available backends for this
skip_cinder_backend_check: True
# add the LINSTOR backend to the enabled backends. For backend configuration see below
cinder_enabled_backends:
  - name: linstor-drbd

Linstor ドライバー構成は kolla-ansible のオーバーライドディレクトリの 1 つに配置できます。使用可能な構成オプションの詳細については、以下のセクションを参照してください。

Listing 21. /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 22. /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/python3.6/dist-packages/cinder/
/usr/lib/python3.6/site-packages/cinder/
/usr/lib/python2.7/dist-packages/cinder/
/usr/lib/python2.7/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 を使用してください。リソースを配置するときに使用するストレージプール。作成されたすべてのディスクフルリソースに適用されます。デフォルトは DfltStorPool です。
7 2.0.0 で非推奨になったので、代わりに volume types を使用してください。特定のボリュームに対して作成する複製数。値が 0 の場合、すべてのノードに複製が作成されます。デフォルトは 0 です。
8 2.0.0 で削除され、ボリュームはドライバーによって必要に応じて作成されます。true に設定すると、少なくとも 1 つの(ディスクレス)複製が Cinder コントローラーホストにデプロイされることを保証します。これは、iSCSIトランスポートに役立ちます。デフォルトは true です。
9 ここでは、より一般的な Cinder オプションを指定できます。たとえば、iSCSI コネクタの場合は target_helper = tgtadm です。
複数の Linstor バックエンドを構成して、それぞれに異なる名前と構成オプションを選択することもできます。

Linstor バックエンドを構成した後、それも有効にする必要があります。これを cinder.conf の有効なバックエンドのリストに追加し、オプションでデフォルトのバックエンドとして設定します。

[DEFAULT]
...
default_volume_type = linstor-drbd-volume
enabled_backends = lvm,linstor-drbd
...

最後のステップとして、Cinder 構成を変更した場合、またはドライバー自体を更新した場合は、必ず Cinder サービスを再起動してください。サービスを再起動する方法については、OpenStack ディストリビューションのドキュメントを確認してください。

8.3.1. トランスポートプロトコルの選択

Cinder のトランスポートプロトコルは、クライアント(たとえば、nova-compute)が実際のボリュームにアクセスする方法です。Linstor を使用すると、異なるトランスポートを使用する 2 つの異なるドライバーを選択できます。

  • cinder.volume.drivers.linstordrv.LinstorDrbdDriver : トランスポートプロトコルとして DRBD を使用

  • cinder.volume.drivers.linstordrv.LinstorIscsiDriver : トランスポートプロトコルとして iSCSI を使用

トランスポートプロトコルとして DRBD を使用

LinstorDrbdDriver は、クライアント(つまり、nova-compute)がリクエストを発行したノードでボリュームの複製がローカルで利用できるようにすることで機能します。これはすべての compute ノードが同じ Linstor クラスターの一部である Linstor サテライトを実行している場合にのみ機能します。

このオプションの利点は次のとおりです。

  • セットアップが完了すると、Cinder ホストはデータパスに関与しなくなります。ボリュームへのすべての読み書きは、構成された対向ノード間でのレプリケーションを処理するローカル DRBD モジュールによって処理されます。

  • Cinder ホストはデータパスに関与していないため、Cinder サービスが中断しても、すでに接続されているボリュームには影響しません。

既知の制限:
  • すべてのホストとハイパーバイザーが DRBD ボリュームの使用をサポートしているわけではありません。Linux ホストと kvm ハイパーバイザーがデプロイメントの対象として制限されます。

  • 接続しているボリュームと使用中のボリュームのサイズ変更は完全には機能しません。サイズ変更自体は成功していますが、サービスは再起動するまで VM にサイズ変更を伝えません。

  • マルチアタッチ(複数の VM に同じボリュームをアタッチする)はサポートされていません。

  • 暗号化されたボリューム は、DRBD デバイスの udev ルールが設定されている場合にのみ機能します。

    udev ルールは drbd-utils パッケージの一部であるか、独自の drbd-udev パッケージの中にあります。
iSCSI トランスポートプロトコルを使用

Cinder ボリュームをエクスポートするデフォルトの方法は、iSCSI 経由です。これにより最大の互換性が得られます。iSCSI は、VMWare、Xen、HyperV、または KVM などのあらゆるハイパーバイザーで使用できます。

欠点は、すべてのデータを(ユーザースペースの)iSCSI デーモンで処理するためにCinder ノードに送信する必要があることです。これは、データがカーネル/ユーザスペース境界を通過する必要があることを意味し、パフォーマンスに影響を与えます。

もう1つの欠点は、単一障害点になりうる点です。iSCSI デーモンを実行している Cinder ノードがクラッシュすると、他のノードはボリュームにアクセスできなくなります。これを軽減するために自動フェイルオーバー用に Cinder を構成する方法はいくつかありますが、かなりの労力が必要です。

2.0.0 より前のバージョンのドライバーでは、Cinder ホストはすべてのボリュームのローカルレプリカにアクセスする必要があります。これは linstor_controller_diskless=True を設定するか linstor_autoplace_count=0 を使用することで実現できます。新しいバージョンのドライバーは、必要に応じてそのようなボリュームを作成します。

8.3.2. Linstor バックエンドのステータスを確認

すべてのバックエンドが稼働していることを確認するには、OpenStack コマンドラインを使用できます。

$ openstack volume service list
+------------------+----------------------------------------+------+---------+-------+----------------------------+
| Binary           | Host                                   | Zone | Status  | State | Updated At                 |
+------------------+----------------------------------------+------+---------+-------+----------------------------+
| cinder-scheduler | cinder-01.openstack.test               | nova | enabled | up    | 2021-03-10T12:24:37.000000 |
| cinder-volume    | cinder-01.openstack.test@linstor-drbd  | nova | enabled | up    | 2021-03-10T12:24:34.000000 |
| cinder-volume    | cinder-01.openstack.test@linstor-iscsi | nova | enabled | up    | 2021-03-10T12:24:35.000000 |
+------------------+----------------------------------------+------+---------+-------+----------------------------+

Horizon GUI をデプロイしている場合は、代わりに Admin > System Information > Block Storage Service を確認してください。

上記の例では、構成されているすべてのサービスが enabledup になっています。問題がある場合は、Cinder ボリュームサービスのログを確認してください。

8.4. Linstor の新しいボリュームタイプを作成

Cinder を使用してボリュームを作成する前に、ボリュームタイプを作成する必要があります。これは、コマンドラインから実行できます。

# Create a volume using the default backend
$ openstack volume type create default
+-------------+--------------------------------------+
| Field       | Value                                |
+-------------+--------------------------------------+
| description | None                                 |
| id          | 58365ffb-959a-4d91-8821-5d72e5c39c26 |
| is_public   | True                                 |
| name        | default                              |
+-------------+--------------------------------------+
# Create a volume using a specific backend
$ openstack volume type create --property volume_backend_name=linstor-drbd linstor-drbd-volume
+-------------+--------------------------------------+
| Field       | Value                                |
+-------------+--------------------------------------+
| description | None                                 |
| id          | 08562ea8-e90b-4f95-87c8-821ac64630a5 |
| is_public   | True                                 |
| name        | linstor-drbd-volume                  |
| properties  | volume_backend_name='linstor-drbd'   |
+-------------+--------------------------------------+

あるいは Horizon GUI でボリュームタイプを作成することもできます。Admin > Volume > Volume Types から “Create Volume Type” をクリックします。 volume_backend_name を “Extra Specs” として追加することで、バックエンドを割り当てることができます。

8.4.1. ボリュームタイプの詳細設定

各ボリュームタイプは、Horizon GUI で呼び出されるプロパティまたは “Extra Specs” を追加することでカスタマイズできます。

コマンドラインでボリュームタイプにプロパティを追加するには、次を使用します。

openstack volume type set linstor_drbd_b --property linstor:redundancy=5

または GUI で Admin > Volume > Volume Types から プロパティを設定することもできます。 Actions 列で、ドロップダウンメニューを開き View Extra Specs ボタンをクリックします。これにより、プロパティの作成、編集、削除に使用できるダイアログが開きます。

使用可能なボリュームタイプのプロパティ
linstor:diskless_on_remaining

自動配置後、選択されていないノードにディスクレスレプリカを作成する。

linstor:do_not_place_with_regex

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

linstor:layer_list

リソースを適用するためのレイヤーのコンマ区切りリスト。空の場合、デフォルトはDRBD、Storageです。

linstor:provider_list

使用するプロバイダーのコンマ区切りリスト。空の場合、LINSTOR は適切なプロバイダーを自動的に選択します。

linstor:redundancy

作成するレプリカの数。デフォルトは 2 です。

linstor:replicas_on_different

自動配置を使用してストレージをプロビジョニングする場所を決定するときに、自動配置選択ラベルとして使用される key または key=value アイテムのコンマ区切りのリスト。

linstor:replicas_on_same

自動配置を使用してストレージをプロビジョニングする場所を決定するときに、自動配置選択ラベルとして使用される key または key=value アイテムのコンマ区切りのリスト。

linstor:storage_pool

自動配置時に使用するストレージプールのコンマ区切りリスト。

linstor:property:*

キーの前に linstor:property: が付いている場合、そのキーは LINSTOR プロパティとして解釈されます。プロパティはボリュームタイプ用に作成された Resource Group に設定されます。

例: quorum policy を変更するには DrbdOptions/auto-quorum を設定する必要があります。これは linstor:property:DrbdOptions/auto-quorum プロパティを設定することで実行できます。

8.5. ボリュームの使用

ボリュームタイプを構成したら、それを使用して新しいボリュームのプロビジョニングを開始できます。

たとえば、コマンドラインで単純な 1Gb ボリュームを作成するには、次のコマンドを使用できます。

openstack volume create --type linstor-drbd-volume --size 1 --availability-zone nova linstor-test-vol
openstack volume list
/etc/cinder/cinder.confdefault_volume_type = linstor-drbd-volume を設定した場合、上記の openstack volume create …​ コマンドから --type linstor-drbd-volume を省略できます。

8.6. トラブルシューティング

このセクションでは、Linstor ボリュームとスナップショットの使用で問題が発生した場合の対処方法について説明します。

8.6.1. Horizon でエラーメッセージを確認する

すべてのボリュームとスナップショットには、Horizon ダッシュボードに Messages タブがあります。エラーが発生した場合は、メッセージのリストをさらに調査するための開始点として使用できます。以下はエラーの場合によくあるメッセージです。

create volume from backend storage:Driver failed to create the volume.

新しいボリュームの作成中にエラーが発生しました。詳細については、Cinder ボリュームサービスログを確認してください。

schedule allocate volume:Could not find any available weighted backend.

これが唯一のエラーメッセージである場合、Cinder スケジューラがボリュームの作成に適したボリュームバックエンドを見つけられなかったことを意味します。これは以下の理由が考えられます。

  • ボリュームバックエンドはオフラインである。詳細は Linstor バックエンドのステータスを確認 を参照ください。

  • ボリュームバックエンドには、リクエストを満たすのに十分な空き容量がありません。 cinder get-pools—​detaillinstor storage-pool list の出力をチェックして、リクエストされた容量が使用可能であることを確認します。

8.6.2. Cinder ボリュームサービスの確認

Linstor ドライバーは、Cinder ボリュームサービスの一部として呼び出されます。

Distribution Log location or command

DevStack

journalctl -u devstack@c-vol

8.6.3. Compute サービスログの確認

一部の問題は Cinder サービスログに記録されませんが、ボリュームの実際のコンシューマー、おそらく Compute サービス(Nova)に記録されます。ボリュームサービスと同様に、確認するホストと正確な場所は、Openstack ディストリビューションによって異なります。

Distribution Log location or command

DevStack

journalctl -u devstack@n-cpu

9. DockerのLINSTORボリューム

この章では LINSTOR Docker Volume Plugin で管理されているDockerのLINSTORボリュームについて説明します。

9.1. Dockerの概要

Docker は、Linuxコンテナの形でアプリケーションを開発、出荷、および実行するためのプラットフォームです。データの永続化を必要とするステートフルアプリケーションのために、Dockerは永続的な volumesvolume_drivers の使用をサポートします。

LINSTOR Docker Volume Plugin は、LINSTORクラスタから永続的ボリュームをプロビジョニングするDockerコンテナ用のボリュームドライバです。

9.2. Dockerインストール用のLINSTORプラグイン

LINBITが提供する linstor-docker-volume プラグインをインストールするには、稼働中の LINSTOR クラスターが必要です。その後、プラグインはパブリック Docker ハブからインストールできます。

# docker plugin install linbit/linstor-docker-volume --grant-all-permissions
--grant-all-permissions フラグは、プラグインを正常にインストールするために必要なすべての権限を自動的に受け入れます。これらを手動で受け入れる場合は、上記のコマンドからフラグを省略してください。

The implicit :latest tag is the latest amd64 version. We currently also build for arm64 with the according tag. Installing the arm64 plugin looks like this:

# docker plugin install linbit/linstor-docker-volume:arm64 --grant-all-permissions

9.3. Docker設定用のLINSTORプラグイン

プラグインはLINSTOR pythonライブラリを介してLINSTORコントローラと通信する必要があるので、プラグインの設定ファイルでLINSTORコントローラノードの場所を指定する必要があります。

# cat /etc/linstor/docker-volume.conf
[global]
controllers = linstor://hostnameofcontroller

詳しくは次のようになります。

# cat /etc/linstor/docker-volume.conf
[global]
storagepool = thin-lvm
fs = ext4
fsopts = -E discard
size = 100MB
replicas = 2

9.4. 使用例

以下は、LINSTOR Docker Volume Pluginの使用例です。以下では、3つのノード (alpha, bravo, charlie) からなるクラスターを想定しています。

9.4.1. 例1 – 典型的なdockerパターン

ノードalpha上:

$ docker volume create -d linbit/linstor-docker-volume \
        --opt fs=xfs --opt size=200 lsvol
$ docker run -it --rm --name=cont \
        -v lsvol:/data --volume-driver=linbit/linstor-docker-volume busybox sh
$ root@cont: echo "foo" > /data/test.txt
$ root@cont: exit

ノードbravo上:

$ docker run -it --rm --name=cont \
        -v lsvol:/data --volume-driver=linbit/linstor-docker-volume busybox sh
$ root@cont: cat /data/test.txt
  foo
$ root@cont: exit
$ docker volume rm lsvol

9.4.2. 例2 – ホスト指定で1つのディスクフル割り当て、2つのディスクレスノード

$ docker volume create -d linbit/linstor-docker-volume --opt nodes=bravo lsvol

9.4.3. 例3 – どこかに1つのディスクフル割り当て、2つのディスクレスノード

$ docker volume create -d linbit/linstor-docker-volume --opt replicas=1 lsvol

9.4.4. 例4 – ホスト指定で2つのディスクフル割り当て、charlie はディスクレス

$ docker volume create -d linbit/linstor-docker-volume --opt nodes=alpha,bravo lsvol

9.4.5. 例5 – どこかに2つのディスクフル割り当て、1つのディスクレスノード

$ docker volume create -d linbit/linstor-docker-volume --opt replicas=2 lsvol

9.4.6. 例6 – Docker swarm manager ノードからのサービスで LINSTOR ボリュームを使用する

$ docker service create \
        --mount type=volume,src=lsvol,dst=/data,volume-driver=linbit/linstor-docker-volume \
        --name swarmsrvc busybox sh -c "while true; do sleep 1000s; done"
Docker services do not accept the -v or --volume syntax, you must use the --mount syntax. Docker run will accept either syntax.

10. LINSTOR ゲートウェイを使用した高可用性ストレージのエクスポート

LINSTOR ゲートウェイ は、LINSTORとPacemakerを活用して、可用性の高いiSCSIターゲットと NFSエクスポートを管理します。ストレージプールとリソースグループを含むLINSTORの設定、 およびCorosyncとPacemakerのプロパティは、このツールを使用するための前提条件です。

10.1. 要件

10.1.1. LINSTOR

LINSTOR ゲートウェイを操作するにはLINSTOR クラスタが必要です。LINSTORコントローラをpacemakerリソースとして実行することを 強くお薦め します。これは手動で構成する必要があります。このようなリソースは次のようになります:(オプション)

primitive p_linstor-controller systemd:linstor-controller \
        op start interval=0 timeout=100s \
        op stop interval=0 timeout=100s \
        op monitor interval=30s timeout=100s

iSCSIとNFSの両方について、LINSTORゲートウェイの storage pool , resource group 、および volume group が存在する必要があります。では、やってみましょう。

物理デバイス /dev/sdb を使用して、3つのノードにストレージプールを作成します。

linstor physical-storage create-device-pool --pool-name lvpool LVM LINSTOR1 /dev/sdb --storage-pool lvmpool
linstor physical-storage create-device-pool --pool-name lvpool LVM LINSTOR2 /dev/sdb --storage-pool lvmpool
linstor physical-storage create-device-pool --pool-name lvpool LVM LINSTOR3 /dev/sdb --storage-pool lvmpool

また、リソースグループとボリュームグループも必要です。

linstor rg c iSCSI_group --storage-pool lvmpool --place-count 2
linstor rg c nfs_group --storage-pool lvmpool --place-count 3
linstor vg c iSCSI_group
linstor vg c nfs_group

ストレージプール、リソースグループ、およびボリュームグループの作成の詳細については、 LINSTOR user guide を参照してください。

10.1.2. Pacemaker

LINSTOR ゲートウェイが稼働しているマシンでは、正常に機能するCorosync/Pacemaker クラスタが必要です。LINSTOR ゲートウェイを実行するには、 drbd-attr リソースエージェントが必要です。これは、Ubuntuベースのディストリビューション用のLINBITの drbd-utils パッケージ、あるいはRHEL/CentOS用のdrbd-pacemakerパッケージに含まれています。LINSTOR Gatewayは、LINSTORコントローラリソースを除き、必要なすべてのPacemakerリソースと制約を自動的に設定します。

10.1.3. iSCSI & NFS

LINSTOR Gatewayは、iSCSI統合にPacemakerのリソースエージェント ocf::heartbeat:iSCSITarget を使用します。iSCSI統合にはiSCSIインプリメンテーションをインストールする必要があります。 targetcli の使用をお薦めします。

iSCSIの場合は、targetcliをインストールしてください。

yum install targetcli

nfsの場合、nfs-serverを有効にして自動起動する必要があります。

systemctl enable --now nfs-server

10.2. 準備

まず、すべてのコンポーネントが使用可能であることを確認します。このガイドでは、LINSTORクラスタがすでにインストールおよび構成されていることを前提としています。linstor-iscsiまたはlinstor-nfsを使用する前に、ボリュームグループ、ストレージプール、リソースグループを定義する必要があります。

ツールはサーバに存在する必要があります。

  • linstor-client (LINSTORクラスターの管理)

  • drbd-attr resource agent (Debian/Ubuntu の drbd-utils の一部、および他の Linux ディストリビューション用の drbd-pacemaker の一部)

  • targetcli (iSCSI 用)

  • nfs-utils, nfs-server

  • Pacemaker クライアント用のpcsまたはcrmshコマンド(iSCSIまたはnfsターゲットのステータスの確認)。

10.3. クラスターのチェック

LINSTORクラスタのステータスを以下で確認する。

[root@LINSTOR1 ~]# linstor n l
╭────────────────────────────────────────────────────────────╮
┊ Node     ┊ NodeType  ┊ Addresses                  ┊ State  ┊
╞════════════════════════════════════════════════════════════╡
┊ LINSTOR1 ┊ COMBINED  ┊ 172.16.16.111:3366 (PLAIN) ┊ Online ┊
┊ LINSTOR2 ┊ SATELLITE ┊ 172.16.16.112:3366 (PLAIN) ┊ Online ┊
┊ LINSTOR3 ┊ SATELLITE ┊ 172.16.16.113:3366 (PLAIN) ┊ Online ┊
╰────────────────────────────────────────────────────────────╯

次のコマンドを使用して、LINSTORストレージプールリストをチェックします。

root@LINSTOR1 ~]# linstor sp l
╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
┊ StoragePool          ┊ Node     ┊ Driver   ┊ PoolName ┊ FreeCapacity ┊ TotalCapacity ┊ CanSnapshots ┊ State ┊
╞═════════════════════════════════════════════════════════════════════════════════════════════════════════════╡
┊ DfltDisklessStorPool ┊ LINSTOR1 ┊ DISKLESS ┊          ┊              ┊               ┊ False        ┊ Ok    ┊
┊ DfltDisklessStorPool ┊ LINSTOR2 ┊ DISKLESS ┊          ┊              ┊               ┊ False        ┊ Ok    ┊
┊ DfltDisklessStorPool ┊ LINSTOR3 ┊ DISKLESS ┊          ┊              ┊               ┊ False        ┊ Ok    ┊
┊ lvmpool              ┊ LINSTOR1 ┊ LVM      ┊ lvpool   ┊    10.00 GiB ┊     10.00 GiB ┊ False        ┊ Ok    ┊
┊ lvmpool              ┊ LINSTOR2 ┊ LVM      ┊ lvpool   ┊    10.00 GiB ┊     10.00 GiB ┊ False        ┊ Ok    ┊
┊ lvmpool              ┊ LINSTOR3 ┊ LVM      ┊ lvpool   ┊    10.00 GiB ┊     10.00 GiB ┊ False        ┊ Ok    ┊
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

LINSTORリソースグループリスト( linstor vg c iscsi_group を使用してボリュームグループを作るのを忘れないでください)

[root@LINSTOR1 ~]# linstor rg l
╭────────────────────────────────────────────────────────────────╮
┊ ResourceGroup ┊ SelectFilter            ┊ VlmNrs ┊ Description ┊
╞════════════════════════════════════════════════════════════════╡
┊ DfltRscGrp    ┊ PlaceCount: 2           ┊        ┊             ┊
╞┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╡
┊ iscsi_group   ┊ PlaceCount: 2           ┊ 0      ┊             ┊
┊               ┊ StoragePool(s): lvmpool ┊        ┊             ┊
╞┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╡
┊ nfs_group     ┊ PlaceCount: 3           ┊ 0      ┊             ┊
┊               ┊ StoragePool(s): lvmpool ┊        ┊             ┊
╰────────────────────────────────────────────────────────────────╯

stonithをチェックして無効にします。Stonithはクラスタのノードをフェンシングするテクニックです。ここには3つのノードがあるため、フェンシングの代わりにクォーラムが使用します。

pcs property set stonith-enabled=false
pcs property show

Pacemakerクラスタが正常かチェックする

[root@LINSTOR1 ~]# pcs status
Cluster name: LINSTOR
Cluster Summary:
  * Stack: corosync
  * Current DC: LINSTOR1 (version 2.0.5.linbit-1.0.el7-ba59be712) - partition with quorum
  * Last updated: Wed Mar 24 21:24:10 2021
  * Last change:  Wed Mar 24 21:24:01 2021 by root via cibadmin on LINSTOR1
  * 3 nodes configured
  * 0 resource instances configured

Node List:
  * Online: [ LINSTOR1 LINSTOR2 LINSTOR3 ]

Full List of Resources:
  * No resources

Daemon Status:
  corosync: active/enabled
  pacemaker: active/enabled
  pcsd: active/enabled

10.4. iSCSIターゲットの設定

すべてが良好に見えます。最初にiSCSI LUNの作成を開始します。すべてのiSCSI関連アクションにlinstor-iscsiツールが使用されます。詳細は、 linstor-iscsi ヘルプ を参照ください。最初に、指定された名前で指定されたリソースグループを使用して、LINSTORシステム内に新しいリソースを作成します。その後、必要なすべての順序および位置制約を含むリソースプリミティブをPacemakerクラスタ内に作成します。Pacemakerプリミティブの先頭には p_ が付き、リソース名とリソースタイプの接尾記号が入ります。

linstor-iscsi create --iqn=iqn.2021-04.com.linbit:lun4 --ip=172.16.16.101/24 --username=foo --lun=4 --password=bar --resource-group=iSCSI_group --size=1G

このコマンドは、指定されたユーザー名とパスワードを使用して、 iSCSI_group DRBDリソースグループに1G iSCSIディスクを作成します。linstor-iscsiによってpacemaker リソースが自動的に作成されます。”pcs status” コマンドを使用してpacemaker リソースをチェックできます。

[root@LINSTOR1 ~]# linstor-iscsi list
+-----------------------------+-----+---------------+-----------+--------------+---------+
|             IQN             | LUN | Pacemaker LUN | Pacemaker | Pacemaker IP | LINSTOR |
+-----------------------------+-----+---------------+-----------+--------------+---------+
| iqn.2020-06.com.linbit:lun4 |   4 |       ✓       |     ✓     |      ✓       |    ✓    |
+-----------------------------+-----+---------------+-----------+--------------+---------+

10.5. iSCSIターゲットの削除

次のコマンドは、pacemakerおよびLINSTORクラスタからiSCSIターゲットを削除します。

linstor-iscsi delete -i iqn.2021-04.com.linbit:lun4 -l 4

10.6. NFSエクスポートの設定

NFS エクスポートを作成する前に、使用されるファイルシステムが EXT4 であることを LINSTOR に通知する必要があります。これを行うには、次のように入力するだけで、NFSリソースのリソースグループにプロパティを適用します。

linstor rg set-property nfs_group FileSystem/Type ext4

次のコマンドは、クラスタ内にNFSエクスポートを作成します。最初に、指定された名前で指定されたリソースグループを使用して、LINSTORシステム内に新しいリソースを作成します。その後、必要なすべての順序およびロケーション制約を含むリソースプリミティブがPacemakerクラスタに作成されます。Pacemakerには接頭辞p_が付き、リソース名とリソースタイプの接尾辞が含まれます。

linstor-nfs create --resource=nfstest --service-ip=172.16.16.102/32 --allowed-ips=172.16.16.0/24 --resource-group=nfs_group --size=1G

次のコマンドを使用すると、nfsエクスポートを簡単に一覧表示できます。

[root@LINSTOR1 ~]# LINSTOR-nfs list
+---------------+------------------+-----------------------+------------+------------+
| Resource name | LINSTOR resource | Filesystem mountpoint | NFS export | Service IP |
+---------------+------------------+-----------------------+------------+------------+
| nfstest       |        ✓         |           ✓           |     ✓      |     ✓      |
+---------------+------------------+-----------------------+------------+------------+

10.7. NFS エクスポートの削除

次のコマンドは、pacemakerおよびLINSTORクラスタからnfsエクスポートを削除します。

[root@LINSTOR1 ~]# linstor-nfs delete -r nfstest

11. LINSTOR EXOSの統合

Seagate社の EXOS ストレージマネージャーは、ローカルドライブのようにLINSTORで管理される1つの大きなブロックデバイスとして構成することができますが、これでは同じプール外の複数のサーバー間でLINSTORリソースを同時に共有できなくなります。

LINSTORとEXOSの統合により、複数のサーバーノードが同一のEXOSプールで提供されるLINSTORリソースを割り当て、接続することができます。 そのため、SSD/HDD階層化、SSDキャッシング、スナップショット、シンプロビジョニングなど、EXOSのストレージ管理機能のすべてがLINSTORリソースやKubernetes Storage Classで利用可能になります。

設定後、LINSTORは2つのEXOSコントローラのうち1つを介してサーバーノードに提示されるLUNとしてResourceレプリカを動的にマッピングします。

EXOSコントローラはセキュアなネットワークAPIで管理されているため、LINSTORは適切なネットワークとユーザー名/パスワードの組み合わせで設定する必要があります。 以下の図は、LINSTORクラスタとEXOSエンクロージャの関係を示しています。

EXOS統合
マルチホストの設定では、最大8台のLINSTORノードを48Gbit SASリンクで直接接続し、低レイテンシーと高スループットを実現します。

ロードバランシングとサーバーのフェイルオーバーはLINSTORによって管理、有効化され、ボリューム作成はEXOSハードウェアRAIDエンジンによって処理されます。

LINSTORのEXOSストレージプロバイダは、EXOS REST-APIとのネイティブな統合を提供しています。

このセクションでは、EXOSの統合を有効にし、LINSTORがEXOSエンクロージャーでバックアップされたストレージを管理するための設定方法を説明します。

EXOSストレージシステムには、あらゆるエンタープライズストレージのニーズに対応する豊富な構成オプションが用意されています。使いやすさを最大限に高めるために、このガイドは次のデフォルトおよび前提条件に基づいています。

  1. デュアルコントローラ:EXOSシステムコントローラはアクティブ/アクティブであり、自動フェイルオーバー機能を備えています。完全にサポートするには、両方のコントローラのIPアドレスをLINSTORプロパティでも構成する必要があります。

  2. デュアルEXOSプール:プールAのデータがコントローラAを介してアクセスされる場合、最適なパフォーマンスが得られます。ノードが同じコントローラのコントローラAとコントローラBの両方に接続されている場合、LINSTORはLinuxマルチパスを構成し、最適なルートを検出します。

  3. EXOS Pool Serial Numbers:EXOSプールが作成されると、一意のシリアル番号が受信されます。各プールは、EXOSエンクロージャとLINSTOR間のリンクを作成するために、LINSTORの下位ストレージとして構成する必要があります。この情報により、LINSTORはEXOSプールAまたはプールBを参照しているかどうかを把握できます。

  4. EXOSプールの作成:管理者は、LINSTORを構成する前にEXOSプールAおよびBを作成する必要があります。この時点では、シンプロビジョニング、自動階層化、スナップショットオプションなどのEXOS機能が選択されています。

  5. エンクロージャ内のレプリカ-EXOSシステムには、冗長コントローラ、電源装置およびドライブへの通信パスがあります。管理者によっては、リソースレプリカを同じエンクロージャに格納しないことを希望する場合があります。この場合、管理者は、各エンクロージャから1つのEXOSプールメンバーのみで構成された複数のLINSTORプールを作成する必要があります。

11.1. LINSTORのストレージプロバイダとしてのEXOSプロパティ

LINSTORのEXOSとのネイティブな統合は、LINSTORコントローラにいくつかのプロパティを設定し、以下のセクションで説明するように、EXOSエンクロージャに固有の適切なLINSTORオブジェクトを作成することによって構成されます。

次の表の情報は、EXOSエンクロージャから取得する必要があります。この情報は、後続のサブセクションで適切なLINSTORコントローラのプロパティおよびLINSTORオブジェクトを移入するために使用されます。

Table 2. 必要な情報
EXOS Information Description Placeholder in Command Examples

EXOS Enclosure Name

管理者によって一意に選択された特定のEXOSエンクロージャー

<exos_encl_name>

Controller Hostname

コントローラーの1つのDNS解決可能なホスト名

<exos_ctrlr_name>

Controller IP

コントローラのIPアドレス

<exos_ctrlr_ip>

REST-API Username

指定されたエンクロージャーの下にあるすべてのEXOSコントローラーのREST-APIのユーザー名

<exos_rest_user>

REST-API Password

特定のエンクロージャーの下にあるすべてのEXOSコントローラーのREST-APIのパスワード

<exos_rest_pass>

EXOS Pool Serial Number

LINSTORプールのメンバーになるEXOSプールのシリアル番号

<exos_pool_sn>

11.2. 設定手順

LINSTORのサーバノードおよび複数のEXOSストレージシステムのトポロジーの構成手順は、次のとおりです。

  1. グローバルまたはユニークなEXOSコントローラのユーザ名とパスワードを設定します。

  2. EXOSエンクロージャーおよびコントローラーネットワークIDを定義します。

  3. 物理SASケーブル接続に一致するノードとエンクロージャ間のプールマッピングを作成します。

11.2.1. ステップ1:EXOSユーザ名とパスワード

ユーザー名とパスワードは、システム管理者がEXOSシステムをどのように展開したかに応じて、各EXOSエンクロージャに対して一意にするか、またはすべてのエンクロージャに対して共通にすることができます。特定のEXOSコントローラに対して設定されていない場合は、デフォルトのEXOSユーザー名とパスワードが使用されます。デフォルトは次のように設定されています。

# linstor exos set-defaults --username <exos_rest_name>
# linstor exos set-defaults --password <exos_rest_pass>

一意のユーザー名とパスワードEXOSコントローラの場合、次のように設定されます。

# linstor controller set-property
    StorDriver/Exos/<exos_encl_name>/username <exos_rest_name>
# linstor controller set-property
    StorDriver/Exos/<exos_encl_name>/Password <exos_rest_pass>
この方法で入力されたパスワードは、 get-defaults を使用するとプレーンテキストとして表示されます。

上記のコマンドを使用すると、LINSTORはパスワードをクリアテキストでLINSTORのプロパティに格納し、単純な linstor controller list-properties コマンドで表示できます。これを環境変数の下に隠し、 UsernameEnv および/または PasswordEnv プロパティを使用できます。これにより、LINSTORは次の例に示すように、実際のユーザー名/パスワードを環境変数で検索するように指示されます。

LINSTORは環境変数を変更せず、読み取りのみを行います。ストレージ管理者は、env-varsが正しく設定されていることを確認する必要があります。
# echo $EXOS_PW
mySecretPassword
# linstor controller set-property \
    StorDriver/Exos/<exos_encl_name>/PasswordEnv EXOS_PW

両方のプロパティバージョン(つまり PasswordPasswordEnv )が設定されている場合は、環境以外のバージョンが優先されます。

環境変数が設定される前にサテライトが開始された場合、新しい環境変数を表示するにはサテライトを再起動する必要があります。

11.2.2. ステップ2:EXOSエンクロージャーおよびコントローラーIDの定義

LINSTORでEXOSエンクロージャを登録するには、次のように create コマンドを使います。

# linstor exos create <exos_encl_name> <exos_ctrl_a_ip> [<exos_ctrl_b_ip>]

特別な --username または --password が指定されていない場合は、上記のデフォルトが使用されます。

コントローラのDNS名とIPアドレスは、同じ意味で使用できます。

DNSで解決できないホスト名を使用してLINSTOR内のEXOSエンクロージャを参照したい場合は、 <exos_hostname> の代わりに任意の名前を使用できますが、エンクロージャのIPアドレスも指定する必要があります。linstor node create<desired_name><enclosure_ip>

次の例を使用して、現在のコントローラ設定を作成および検査します。

|==================================================================|
# linstor exos create Alpha 172.16.16.12 172.16.16.13
# linstor exos list
+------------------------------------------------------------------+
| Enclosure | Ctrl A IP    | Ctrl B IP    | Health | Health Reason |
| Alpha     | 172.16.16.12 | 172.16.16.13 | OK     |               |
+------------------------------------------------------------------+

より詳細なビューを表示するには、LINSTORコントローラやLINSTORノードに対して、 Exos 関連のプロパティを確認する必要があります。

# linstor controller list-properties | grep Exos
| StorDriver/Exos/Alpha/A/IP                | 172.16.16.12         |
| StorDriver/Exos/Alpha/B/IP                | 172.16.16.13         |

11.2.3. ステップ3: ノードにエンクロージャとプールのマッピングの作成

LINSTORサテライトノードは、通常どおり作成できます。

# linstor node create <satellite_hostname>

ストレージプールは、LINSTORでは通常どおりに作成することもできます。 以前に登録されたEXOSエンクロージャの名前とEXOSプールのシリアル番号のみを 指定する必要があります。

# linstor storage-pool create exos \
  <satellite_hostname> <linstor_pool_name> <exos_encl_name> <exos_pool_sn>

linstor_pool_nameは、LINSTOR デプロイメントに対して(ほぼ)任意の 一意のストリングに設定できます。

次に、EXOSエンクロージャAlpha内のEXOSプールを2つのサテライトノードにマッピングする例を示します。

# linstor storage-pool create exos \
   node1 poolA Alpha 00c0ff29a5f5000095a2075d01000000
# linstor storage-pool create exos \
   node2 poolA Alpha 00c0ff29a5f5000095a2075d01000000

exos ストレージプールを作成した後、LINSTOR Satellite は指定されたEXOS エンクロージャ内の接続ポートをスキャンします。ケーブル接続されている場合、 これらのポートは次のコマンドにリストされます。

# linstor exos map -p
+----------------------------------------------+
| Node Name | Enclosure Name | Connected Ports |
|==============================================|
| node1     | Alpha          | A0, B0          |
| node2     | Alpha          | A1, B1          |
+----------------------------------------------+

プール構成は次のように表示します。

hr01u09:~ # linstor sp list -s poolA -p
+----------------------------------------------------------------------------------------------+
| StoragePool | Node  | Driver   | PoolName                               | FreeCapacity | ... |
|==============================================================================================|
| poolA       | node1 | EXOS     | Alpha_00c0ff29a5f5000095a2075d01000000 |      581 TiB | ... |
| poolA       | node2 | EXOS     | Alpha_00c0ff29a5f5000095a2075d01000000 |      581 TiB | ... |
+----------------------------------------------------------------------------------------------+

使用可能なすべてのEXOSコマンドの詳細な説明は、組み込みヘルプで参照できます。

# linstor exos -h

11.3. EXOSストレージプールによってバックアップされるリソースの作成

EXOS でバックアップされたストレージプールからの LINSTOR リソースの作成は LINSTOR resource groups またはより詳細な resource-definition, volume-definition, resource creation ワークフローを説明する各セクションなど、LINSTORユーザーガイドの他のセクションで説明されている通常の LINSTOR 使用パターンに従います。

12. LINSTOR Web UI

LINSTOR Web UI is a LINSTOR client alternative, currently in Technology Preview phase. This component is proprietary and users need to have access to LINBIT customer only repositories in order to be able to use it.

12.1. Prerequisites

  • Access to LINBIT’s customer repositories.

  • Running and working LINSTOR controller instance.

12.2. Installation

Install LINSTOR Web UI package on the same node as the LINSTOR controller and restart the linstor-controller service.

On yum/dnf based distribution you can install the software via:

yum install linstor-gui

On apt based distributions you install the software via:

apt install linstor-gui

On Kubernetes LINSTOR Web UI is a built-in feature since linstor-controller v1.15.0.

12.3. Administration

Open your web browser and navigate to http://CONTROLLER_IP:3370/ui/ (the last / is mandatory) to manage your LINSTOR cluster.


1. ホストがストレージノードでもある場合は、イメージのローカルコピーを使用できます