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 にあります。

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

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

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

  1. ノード名は uname -n の出力と同じである必要がある。

  2. ノードのIPアドレスとともに以下を実行する。

# linstor node create bravo 10.43.70.3

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

# systemctl enable --now  linstor-satellite

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

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

ノードがコントローラでかつクラスタにストレージも供給する場合は、同様にlinstor-satelliteを起動します。

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

ストレージプールの VG/zPool で何らかの問題が発生した場合、たとえば、VG の名前が変更された、無効になった場合は、次のコマンドを使用して LINSTOR でストレージプールを削除できます。この機能は LINSTOR v0.9.13 以降で利用可能です。

# linstor storage-pool lost alpha pool_ssd

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

# linstor sp lo alpha pool_ssd

まだ動作中のリソースまたはスナップショットがアタッチされていて、ストレージプールの削除ができない場合は、対応方法のヒントが関連する 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/磁気ディスク) でグループ化された使用可能なディスクのリストを表示します。

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 にします。

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

0 でも負のスコアでも、ストレージプールが選択されるのを防ぐことはできず、後ほど考慮されるようになります。
すべてがうまくいくと、DRBDリソースがLINSTORによって作成されます。 lsblk コマンドでDRBDブロックデバイスを探すことで確認でき、 drbd0000 のように見えるはずです。

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

2. LINSTOR 応用タスク

2.1. DRBDクライアント

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

# linstor resource create delta backups --drbd-diskless
オプション --diskless は廃止されました。代わりに、 --drbd-diskless または --nvme-initiator を使用してください 。

2.2. 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.3. 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.4. 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.4.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もDBRDも使用せずにLINSTORリソースを作成したい場合は、 -l パラメータを storage だけに設定する必要があります。

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

# linstor volume-definition create nvmedata 500G

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

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

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

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

# linstor resource create beta nvmedata -d

-d パラメータはこのノード上にディスクレスとしてリソースを作成します。

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

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

2.4.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.4.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.4.4. Cache Layer

LINSTOR can also setup a DM-Cache device, which is very similar to the DM-Writecache from the previous section. The major difference is that a cache device is composed by three devices: one storage device, one cache device and one meta device. The LINSTOR properties are quite similar to those of the writecache but are located in the Cache namespace:

# 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/Size 1%

# linstor resource create node1 r1 --storage-pool lvmpool --layer-list CACHE,STORAGE
Instead of Writecache/PoolName (as when configuring the Writecache layer) the Cache layer’s only required property is called Cache/CachePool. The reason for this is that the Cache layer also has a Cache/MetaPool which can be configured separately or it defaults to the value of Cache/CachePool.

Please see linstor controller set-property --help for a list of Cache/* property-keys and default values for omitted properties.

Using --layer-list DRBD,CACHE,STORAGE while having DRBD configured to use external metadata, only the backing device will use a cache, not the device holding the external metadata.

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

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.6. 暗号化ボリューム

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

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

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

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

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

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

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

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

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

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

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

[encrypt]
passphrase="example"

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

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

2.7. クラスタの状態をチェック

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

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

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

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

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

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

# linstor snapshot create resource1 snap1

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

Setting the resource-definition property AutoSnapshot/RunEvery LINSTOR will automatically create snapshots every X minute. The optional property AutoSnapshot/Keep can be used to clean-up old snapshots which were created automatically. No manually created snapshot will be cleaned-up / deleted. If AutoSnapshot/Keep is omitted (or ⇐ 0), LINSTOR will keep the last 10 snapshots by default.

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

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

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

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

# linstor snapshot rollback resource1 snap1

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

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

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

# linstor snapshot delete resource1 snap1

2.8.5. Shipping a snapshot

Both, the source as well as the target node have to have the resource for snapshot shipping deployed. Additionally, the target resource has to be deactivated.

# linstor resource deactivate nodeTarget resource1
Deactivating a resource with DRBD in its layer-list can NOT be reactivated again. However, a successfully shipped snapshot of a DRBD resource can still be restored into a new resource.

To manually start the snapshot-shipping, use:

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

A resource can also be periodically shipped by setting the mandatory properties SnapshotShipping/TargetNode as well as SnapshotShipping/RunEvery on the resource-definition. SnapshotShipping/SourceNode can also be set, but if omitted LINSTOR will choose an active resource of the same resource-definition.

To allow incremental snapshot-shipping, LINSTOR has to keep at least the last shipped snapshot on the target node. The property SnapshotShipping/Keep can be used to specify how many snapshots LINSTOR should keep. If the property is not set (or ⇐ 0) LINSTOR will keep the last 10 shipped snapshots by default.

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

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

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.10.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.11. 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.11.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.12. 外部データベース

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

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

2.12.1. Postgresql

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

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

2.12.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.12.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.13. 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.13.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.14. ロギング

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. 推奨される場所は /etc/linstor/linstor.toml ファイルの logging セクションです。

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

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

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

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

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

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

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.17. QoS設定

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

LINSTORボリュームが複数の “スタック” ボリュームで構成されている場合(たとえば、外部メタデータを持つDRBDには、バッキング(ストレージ)デバイス、メタデータデバイス、結果のDRBDデバイスの3つのデバイスがあります)、 sys/fs/* ボリュームのプロパティ、すべて 影響を受けるデバイスは、対応する /sys/fs/cgroup/…​ 設定を受け取ります。

2.18. ヘルプの利用

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

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

2.18.3. GitHub

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

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

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

3. Kubernetes で LINSTOR ボリューム

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

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 ボリューム を使用する。

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

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

    • 使用可能なデバイスからストレージプールを作成します。 シンプルな構成には こちら がおすすめです。

    • 既存の LVM セットアップからストレージプールを作成します。こちら を参照ください。

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

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

      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

    Further deployment customization is discussed in the advanced deployment section

LINSTOR etcd hostPath 永続化

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

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

helm repo add linstor https://charts.linstor.io
helm install linstor-etcd linstor/pv-hostpath --set "nodes={<NODE0>,<NODE1>,<NODE2>}"

etcd の永続化はデフォルトで有効です。

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

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 オペレーターは、サテライトのデバイスを自動的に構成できます。自動構成の対象となるのは、以下のブロックデバイスです。

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

  • 1 GiB 以上である。

Any such device will be prepared according to the value of operator.satelliteSet.automaticStorageType. Devices are added to a storage pool based on the device name (i.e. all /dev/nvme1 devices will be part of the pool nvme1)

The possible values for operator.satelliteSet.automaticStorageType are:

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

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

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

  • ZFS ZFS ベースストレージプールを作成

ストレージプールの構成

The operator installed by helm can be used to create storage pools. Creation is under control of the LinstorSatelliteSet resource:

$ kubectl get LinstorSatelliteSet <satelliteSet> -o yaml
kind: LinstorSatelliteSet
metadata:
..
spec:
  ..
  storagePools:
    lvmPools:
    - name: lvm-thick
      volumeGroup: drbdpool
    lvmThinPools:
    - name: lvm-thin
      thinVolume: thinpool
      volumeGroup: drbdpool

ストレージプールを構成するには2つの方法があります。

インストール時

At install time, by setting the value of operator.satelliteSet.storagePools when running helm install.

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

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

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

helm install linstor-op linstor/linstor -f <file> ..
インストール後

On a cluster with the operator already configured (i.e. after helm install), you can edit the SatelliteSet configuration like this:

$ kubectl edit LinstorSatelliteSet <satelliteSet>

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

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 によって保護されていません。必要な場合は、次の手順に従い設定します。

  • Create private keys in the java keystore format, one for the controller, one for all satellites:

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"
  • 各コンポーネントが信頼できるよう公開鍵を伴うトラストストアを作成します。

  • Controller needs to trust the satellites

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

    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
  • Create kubernetes secrets that can be passed to the controller and satellite pods

    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 デプロイメントの終了

重要なコンポーネントを誤って削除しないようにクラスターのストレージインフラストラクチャを保護するには、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 コントローラーとサテライトリソースを削除します。

    Deployment of LINSTOR satellite and controller is controlled by the LinstorSatelliteSet and LinstorController resources. You can delete the resources associated with your deployment using kubectl

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

    しばらくすると、コントローラーとサテライトポッドが終了します。終了しない場合は、上記のリソースのエラーを確認します(関連付けられているすべてのポッドが終了した後でのみ削除されます)

  3. Helm デプロイメントの削除

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

    helm uninstall linstor-op
    Due to the Helm’s current policy, the Custom Resource Definitions named LinstorController and LinstorSatelliteSet will not be deleted by the command. More information regarding Helm’s current position on CRD’s can be found here.

3.2.4. Upgrades from older deployments

If you are already running a previous version (before v1.0.0) of linstor-operator, you need to follow the upstream guide. We tried to stay compatible and lower the burden of upgrading as much as possible, but some manual steps may still be required.

3.2.5. Advanced deployment options

The helm charts provide a set of further customization options for advanced use cases.

global:
  imagePullPolicy: IfNotPresent # empty pull policy means k8s default is used ("always" if tag == ":latest", "ifnotpresent" else) (1)
# 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.9
csi-snapshotter:
  enabled: true # <- enable to add k8s snapshotting CRDs and controller. Needed for CSI snapshotting
  image: quay.io/k8scsi/snapshot-controller:v2.1.0
  replicas: 1 (2)
  resources: {} # resource requirements for the cluster snapshot controller. (3)
stork:
  enabled: true
  storkImage: docker.io/linbit/stork:latest
  schedulerImage: gcr.io/google_containers/kube-scheduler-amd64
  replicas: 1 (2)
  storkResources: {} # resources requirements for the stork plugin containers (3)
  schedulerResources: {} # resource requirements for the kube-scheduler containers (3)
csi:
  enabled: true
  pluginImage: "drbd.io/linstor-csi:v0.9.1"
  csiAttacherImage: quay.io/k8scsi/csi-attacher:v2.2.0
  csiNodeDriverRegistrarImage: quay.io/k8scsi/csi-node-driver-registrar:v1.3.0
  csiProvisionerImage: quay.io/k8scsi/csi-provisioner:v1.6.0
  csiSnapshotterImage: quay.io/k8scsi/csi-snapshotter:v2.1.0
  csiResizerImage: quay.io/k8scsi/csi-resizer:v0.5.0
  controllerReplicas: 1 (2)
  nodeAffinity: {} (4)
  nodeTolerations: [] (4)
  controllerAffinity: {} (4)
  controllerTolerations: [] (4)
  resources: {} (3)
priorityClassName: ""
drbdRepoCred: drbdiocred # <- Specify the kubernetes secret name here
linstorHttpsControllerSecret: "" # <- name of secret containing linstor server certificates+key. See docs/security.md
linstorHttpsClientSecret: "" # <- name of secret containing linstor client certificates+key. See docs/security.md
operator:
  replicas: 1 # <- number of replicas for the operator deployment (2)
  image: "drbd.io/linstor-operator:v1.0.0-rc1"
  resources: {} (3)
  controller:
    controllerImage: "drbd.io/linstor-controller:v1.7.3"
    luksSecret: ""
    dbCertSecret: ""
    dbUseClientCert: false
    sslSecret: ""
    affinity: {} (4)
    tolerations: [] (4)
    resources: {} (3)
  satelliteSet:
    satelliteImage: "drbd.io/linstor-satellite:v1.7.3"
    storagePools: null
    sslSecret: ""
    automaticStorageType: None
    affinity: {} (4)
    tolerations: [] (4)
    resources: {} (3)
    kernelModuleInjectionImage: "drbd.io/drbd9-rhel7:v9.0.24"
    kernelModuleInjectionMode: ShippedModules
    kernelModuleInjectionResources: {} (3)
1 Sets the pull policy for all images.
2 Controls the number of replicas for each component.
3 Set container resource requests and limits. See the kubernetes docs. Most containers need a minimal amount of resources, except for:
  • etcd.resources See the etcd docs

  • operator.controller.resources Around 700MiB memory is required

  • operater.satelliteSet.resources Around 700MiB memory is required

  • operator.satelliteSet.kernelModuleInjectionResources If kernel modules are compiled, 1GiB of memory is required.

4 Affinity and toleration determine where pods are scheduled on the cluster. See the kubernetes docs on affinity and toleration. This may be especially important for the operator.satelliteSet and csi.node* values. To schedule a pod using a LINSTOR persistent volume, the node requires a running LINSTOR satellite and LINSTOR CSI pod.

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

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

3.3. Kubernetes で LINSTOR の操作

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

kubectl exec linstor-op-cs-controller-<deployment-info> -- linstor storage-pool list

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

3.4. LINSTOR CSIプラグインのデプロイメント

オペレーター Helm チャートは LINSTOR CSI プラグインをデプロイするため、Helm チャートを使用した場合は、このセクションをスキップできます。

If you are integrating LINSTOR using a different method, you will need to install the LINSTOR CSI plugin. Instructions for deploying the CSI plugin can be found on the project’s github. This will result in a linstor-csi-controller Deployment and a linstor-csi-node DaemonSet running in the kube-system namespace.

NAME                           READY   STATUS    RESTARTS   AGE     IP              NODE
linstor-csi-controller-ab789   5/5     Running   0          3h10m   191.168.1.200   kubelet-a
linstor-csi-node-4fcnn         2/2     Running   0          3h10m   192.168.1.202   kubelet-c
linstor-csi-node-f2dr7         2/2     Running   0          3h10m   192.168.1.203   kubelet-d
linstor-csi-node-j66bc         2/2     Running   0          3h10m   192.168.1.201   kubelet-b
linstor-csi-node-qb7fw         2/2     Running   0          3h10m   192.168.1.200   kubelet-a
linstor-csi-node-zr75z         2/2     Running   0          3h10m   192.168.1.204   kubelet-e

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

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

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

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

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

Listing 1. linstor-basic-sc.yaml
apiVersion: storage.k8s.io/v1beta1
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
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"

DRBD オプションは、パラメーターセクションでも設定できます。有効なキーは LINSTOR REST-API (e.g., DrbdOptions/Net/allow-two-primaries: "yes") で定義されています。

次のコマンドで 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
  annotations:
    # This line matches the PersistentVolumeClaim with our StorageClass
    # and therefore our provisioner.
    volume.beta.kubernetes.io/storage-class: linstor-basic-storage-class
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

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

kubectl create -f my-first-linstor-volume-pvc.yaml

これは Kubernetes に認識されている PersistentVolumeClaim を作成し、それに PersistentVolume がバインドされます。さらにLINSTORは linstor-basic-storage-class StorageClass で定義された設定に従ってこのボリュームを作成します。 LINSTORボリュームの名前は csi- という接頭辞が付いたUUIDになります。このボリュームは通常の linstor resource list で見ることができます。一度ボリュームが作成されたら、それを pod にアタッチすることができます。以下の pod 仕様はFedoraコンテナを作成し、ビジーウェイトするので、アンスケジュールされません。

Listing 3. my-first-linstor-volume-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: fedora
  namespace: default
spec:
  containers:
  - name: fedora
    image: fedora
    command: [/bin/bash]
    args: ["-c", "while true; do sleep 10; done"]
    volumeMounts:
    - name: my-first-linstor-volume
      mountPath: /data
    ports:
    - containerPort: 80
  volumes:
  - name: my-first-linstor-volume
    persistentVolumeClaim:
      claimName: "my-first-linstor-volume"

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

kubectl create -f my-first-linstor-volume-pod.yaml

kubectl describe pod fedora を実行することで Pod がスケジュールされ、ボリュームが正しく割り当てられたのを確認できます。

ボリュームを削除するには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.6. スナップショット

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

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

LINSTOR はボリュームのスナップショット機能をサポートしています。これは現在ベータ版です。これを使用するには、クラスター全体のスナップショットコントローラーをインストールする必要があります。これは、クラスタープロバイダーによって行われるか、LINSTOR チャートを使用できます。

デフォルトでは、LINSTOR チャートは独自のスナップショットコントローラーをインストールします。これにより、場合によっては競合が発生する可能性があります。

  • クラスターにはすでにスナップショットコントローラーがある

  • クラスターが最小バージョンの要件を満たしていない (>= 1.17)

このような場合、スナップショットコントローラーのインストールを無効にすることができます。

--set csi-snapshotter.enabled=false

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

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

Listing 4. my-first-linstor-snapshot-class.yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
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/v1beta1
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.7. ボリュームへのアクセス

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

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

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

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

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

The next Stork release will include the LINSTOR driver by default. In the meantime, you can use a custom-built Stork container by LINBIT which includes a LINSTOR driver, available on Docker Hub

3.8.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.9. 高度な設定

KubernetesのLinstorボリュームのすべての構成は、上で使用したサンプルのように_StorageClass_ のパラメータ経由で設定されます。以下に利用可能なオプションの詳細を示します。

3.9.1. nodeList

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

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

例: nodeList: "node-a node-b node-c"

例: nodeList: "node-a"

3.9.2. autoPlace

autoPlace はこの StorageClass が持つボリュームの複製数を指定します。例えば、 autoPlace: 3 は3つの複製をもつボリュームを生成します。 autoPlace または nodeList が指定されていない場合は、1つのノード上にボリュームが生成されます。自動配備 を参照ください。

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

例: autoPlace: 2

例: autoPlace: 1

3.9.3. replicasOnSame

replicasOnSame は、 autoplace がストレージをプロビジョニングする場所を決定するために使用されるときは必須の自動配置選択ラベルで、 key = value のペアのリストです。これらのラベルは、LINSTORノードの aux prop に対応しています。キーと値の名前はどちらもユーザー定義で任意です。LINSTORクラスタ node-a が aux props zone=z1role=backups , node-bzone=z1 のみを持つと仮定します。

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

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

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

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

例: replicasOnSame: "zone=z1 role=backups"

3.9.4. replicasOnDifferent

replicasOnDifferent は自動配置選択として避けるための key=value のペアのリストです。 replicasOnSame の逆のものです。

例: replicasOnDifferent: "no-csi-volumes=true"

3.9.5. localStoragePolicy

localStoragePolicy はボリュームトポロジを通して、どの LINSTOR Satellite ボリュームを割り当てるべきか、そして Kubernetes がどこからボリュームにアクセスするかを決定します。各オプションの動作については、後ほど詳しく説明します。

nodeList を指定すると、localStoragePolicy に関係なく、ボリュームはそれらのノード上に作成されます。ただし、アクセスに関するレポートでは説明どおりになります。
StorageClassvolumeBindingMode:WaitForFirstConsumer を設定する必要があります。また、kubelet 上で実行している LINSTOR Satellite は、 required または preferred が正しく動作するように、その StorageClass で構成されているボリュームのディスクフル配置をサポートできる必要があります。
PodStatefulSet の spec で affinity を設定している場合、 topologyKey:"kubernetes.io/hostname" ではなく topologyKey:"linbit.com/hostname" を使用してください。

例: localStoragePolicy: required

ignore (デフォルト)

localStoragePolicyignore に設定されている場合、通常の自動配置が autoplace, replicasOnSame, replicasOnDifferent に基づいて行われます。 ボリュームの場所は、Kubernetes での Pod スケジューリングに影響を与えず、ボリュームが Pod がスケジュールされた kubelet にローカルでない場合でも、ネットワークを介してアクセスされます。

required

localStoragePolicyrequired に設定されていると、Kubernetes は設定に従って Pod をスケジュールしたい場所のリストを報告します。プラグインはその設定に従ってボリュームのプロビジョニングを試みます。プロビジョニングされるボリューム数の合計は autoplace に基づいています。

すべての設定が試行されたが、正常に割り当てられたボリュームがない場合、ボリュームの作成は失敗します。

複製が複数ある場合、すべての設定が試行され、少なくとも1つが成功したときに、まだプロビジョニングされる複製が残っている場合、 autoplace が残りのボリュームに動作が適用されます。

このオプションを設定すると、Kubernetes は kubelet にローカルに存在しないボリュームはその kubelet からアクセスできないと見なします。

preferred

localStoragePolicypreferred に設定されている場合、ボリューム配置の動作は、設定を満たすことができなかった場合でも、ボリュームの作成は失敗しないという点を除いて required と同じです。ボリュームへのアクセスは ignore に設定した場合と同じになります。

3.9.6. storagePool

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

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

例: storagePool: my-storage-pool

3.9.7. disklessStoragePool

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

例: disklessStoragePool: my-custom-diskless-pool

3.9.8. encryption

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

例: encryption: "true"

3.9.9. filesystem

filesystem は下位のブロックボリュームのファイルシステムを指定するためのオプションパラメータです。現在サポートされているオプションは xfsext4 です。

例: filesystem: "xfs"

デフォルト: filesystem: "ext4"

3.9.10. fsOpts

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

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

例: fsOpts: "-b 2048"

3.9.11. mountOpts

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

例: mountOpts: "sync,noatime"

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

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

4.1. Proxmox VE概要

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

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

4.2. アップグレード

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

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

4.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のメジャーバージョンを指定します(例、”6″ であり “6.1” ではない)。

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

4.4. LINSTORの設定

このガイドの残りの部分では クラスタの初期化 に基づいて LINSTOR クラスタが構成されていると仮定します。また、各ノードを “Combined” ノードとして設定し、 1 つのノードで “linstor-controller” を起動し、すべてのノードで “linstor-satellite” を起動します。また、バージョン 4.1.0 以降、このプラグインを使用する上で推奨する方法は、LINSTOR リソースグループと単一のボリュームグループを使用することです。 LINSTOR リソースグループについてはリソースグループ を参照してください。必要なすべての LINSTOR 構成(冗長カウントなど)をリソースグループに設定する必要があります。

4.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に負荷がかかっていて、ダーティメモリが常に多い場合は、全体的な処理に少し時間がかかることがあります。しかし、いずれの場合でも、ダウンタイムは最小限で、中断は全く見られません。

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

このセクションでは、コントローラーを高可用性にする方法を説明しますが、これは必須ではありません。始める前にセクション全体を読んでから、複雑さが増していること、および制限がそれに見合うかどうかを判断してください。別な方法として、LINSTORコントローラーデータベースの定期的なバックアップを取り、現在のコントローラーが修復不可能な場合に、残りのサテライトの1つでデータベースバックアップを使用して(一時的な)コントローラーを起動することのほうが、より良い結果が得られることもあります。

これ以降の説明では、LINSTORの設定 に基づいてLINSTORとProxmoxプラグインがすでにインストールされていると仮定します。

基本的な考え方は、ProxmoxとそのHA機能によって管理されるVM内でLINSTORコントローラを起動するということです。このVMのストレージはLINSTORによって管理されるDRBDに存在します。

最初の手順はVMのストレージを割り当てることです。通常の方法でVMを作成し、OSの選択時にどのメディアも選択しません。ハードディスクはもちろんDRBD上に (“drbdstorage”) 作成します。ディスクスペースは2GBで十分でメモリは1GBを選択します。これらはLINBITがカスタマーに供給するアプライアンスの最小の構成要件です。もし独自のコントローラVMを設定し、リソースに成約がない場合はこれらの最小値を増やしてください。以下の例ではコントローラVMはID100で作成されたと仮定しますが、他のVMを作成した後にこのVMを作成する場合でも問題はありません。

LINBITは作成したストレージを実装するために使うことができるアプライアンスをカスタマーに供給しています。アプライアンスを動作させるためには、最初にシリアルポートを作成する必要があります。ハードウェアをクリックし、追加で、シリアルポートを選択してください。

pm add serial1 controller vm
Figure 1. シリアルポートの追加

すべてがうまくいくと、VMの定義は以下のようになります。

pm add serial2 controller vm
Figure 2. シリアルポート付きのVM

次の手順ではVMアプライアンスをVMディスクストレージにコピーします。これは qemu-img で行います。

VM IDを適切なものに変更するようにしてください。
# qemu-img dd -O raw if=/tmp/linbit-linstor-controller-amd64.img \
  of=/dev/drbd/by-res/vm-100-disk-1/0

この後、VMを起動しProxmox VNCビューワ経由でVMに接続することができます。デフォルトのユーザ名とパスワードはどちらも “linbit” です。デフォルトのssh設定を維持しているので、これらのユーザ名とパスワードでsshログインできません。ログインを有効にする場合は、/etc/ssh/sshd_config でこれらを有効にしsshサービスを再起動してください。このVMは “Ubuntu Bionic” をベースにしているので、/etc/netplan/config.yaml でネットワークの設定(スタティックIPなど)が変更できます。その後、VMにsshできるようになります。

pm ssh controller vm
Figure 3. LINBIT LINSTORコントローラアプライアンス

次の手順で、コントローラVMを既存のクラスタに追加します。

# linstor node create --node-type Controller \
  linstor-controller 10.43.7.254
コントローラVMは他のVMと比較して、Proxmoxストレージプラグインによって特別な方法で扱われるので、PVE HAがVMを開始する前に、すべてのホストがそのVMのストレージにアクセスできるようにします。そうでないとVMを開始できません。詳細は以下を参照ください。

我々のテストクラスタでは、コントローラVMディスクがDRBDストレージに作成され、1つのホストに割り当てられました(割り当てを確認するには linstor resource list を使用)。そして、 linstor resource create で他のノードにもリソースを追加しました。4つのノードで構成されているラボでは、すべてのノードにリソース割り当てを行いましたが、ディスクレスでの割り当てでも問題ありません。経験則として、冗長数を “3” (それ以上はあまり使われない)に保ち、残りはディスクレスに割り当てます。

この特殊なVMのストレージは、なんらかの方法ですべてのPVEホストで有効になっていなければならいので、すべてのノードで drbd.service を実行し有効にします(この段階ではLINSTORによって制御されていない)。

# systemctl enable drbd
# systemctl start drbd

デフォルトでは linstor-satellite サービスは起動時にすべてのリソースファイル (*.res) を削除し、再度それらを作成します。これはコントローラVMをスタートするために、これらを必要とする drbd サービスと競合しますが、 drbd.service で最初にリソースを UP し、その後コントローラの関連する res ファイルを削除しない linstor-satellite.service をスタートすることで対応できます。systemctl を通してサービスファイルを編集してください(ファイルを直接編集しないでください)。

systemctl edit linstor-satellite
[Service]
Environment=LS_KEEP_RES=vm-100-disk
[Unit]
After=drbd.service

もちろん、 LS_KEEP_RES 変数でコントローラーVMの名前を指定します。指定された値は正規表現として解釈されるため、正確な名前を指定する必要はありません。

linstor-satellite.service を再起動することを忘れないでください。

最後の手順として、既存のコントローラから新しいコントローラに切り替えます。既存のコントローラを止めて、LINSTORコントローラデータベースをVMホストにコピーします。

# systemctl stop linstor-controller
# systemctl disable linstor-controller
# scp /var/lib/linstor/* [email protected]:/var/lib/linstor/

最後にコントローラVMのコントローラを有効にします。

# systemctl start linstor-controller # in the VM
# systemctl enable linstor-controller # in the VM

正しく動作しているか確認するには、PVE ホストで linstor --controllers=10.43.7.254 node list でコントローラのVMに対してクラスタノードを問い合わせることです。ここで “OFFLINE” と表示されることは問題ありません。この表示方法は将来より適切なものに変更される可能性があります。

最後に重要なこととして、 /etc/pve/storage.cfg に “controlervm” を追加し、controller のIPアドレスをVMのIPアドレスに変更する必要があります。

drbd: drbdstorage
   content images,rootdir
   resourcegroup defaultpool
   controller 10.43.7.254
   controllervm 100

ここで “controllervm” の追加設定に注意してください。この設定は、DRBDストレージの他のVMと異なる方法でコントローラVMを処理するようPVEに指示することで、とても重要です。具体的には、コントローラVMの処理にLINSTORストレージプラグインを使用せず、代わりに他の方法を使用するようPVEに指示します。この理由は、単にLINSTORがこの段階では利用できないからです。コントローラVMが起動して実行されると、PVEホストはLINSTORストレージプラグインを使用してDRBDストレージに格納されている残りの仮想マシンを起動することができます。 “controllervm” の設定で正しいVM IDを設定してください。この例では、コントローラVMに割り当てられたID “100” が設定されます。

また、コントローラVMが常に動作していて、定期的に(通常はLINSTORクラスタに変更を加えたときに)バックアップを取っていることを確認することはとても重要です。VMがなくなってバックアップがない場合は、LINSTORクラスタをゼロから再作成する必要があります。

VMを誤って削除してしまうのを防ぐには、PVE GUIのVMの “Options” タブを開いて、 “Protection” を有効にします。仮にVMを誤って削除してしまった場合でも、そのような要求はストレージプラグインによって無視されるため、VMディスクはLINSTORクラスタから削除されません。したがって、以前と同じIDでVMを再作成することができます(PVEでVM構成ファイルを再作成し、古いVMで使用されているものと同じDRBDストレージデバイスを割り当てるだけです)。プラグインは “OK” を返し、古いデータの古いVMを再び使用できます。コントローラVMを削除しないようにし、必要に応じたプロテクトをするようにしてください。

VMによって実行されるコントローラを設定しましたので、VMの1つのインスタンスが常に実行されているようにします。これにはProxmoxのHA機能を使用します。VMをクリックし “More” から “Manage HA” を選択します。以下のパラメータをコントローラVM用に設定します。

pm manage ha controller vm
Figure 4. コントローラVMのHA設定

Proxmoxクラスタで動作しているノードがあれば、コントローラVMはどこで実行されてもよく、現在動作しているノードがシャットダウン、もしくは停止してしまった場合、Proxmox HAは他のノードでコントローラVMが起動されるのを保証します。コントローラVMのIPアドレスはもちろん変更されてはなりません。このような場合がないよう、管理者の責任として正しく設定しておきます(例えば、静的IPアドレスの設定、ブリッジインターフェースのDHCPを介して同じIPアドレスを割り振るなど)。

LINSTORクラスタの専用ネットワークを使用している場合、PVEホストで構成されたネットワークインターフェイスがブリッジとして構成されているか確認する必要があります。それらがダイレクトインタフェース(eth0、eth1など)として設定されている場合、クラスタ内の残りのLINSTORノードと通信するようにコントローラVM vNICを設定することはできません。ブリッジインターフェイスだけが設定できます。

この設定で完全には扱えない1つの制限に、すべてのクラスタノードが再起動する、クラスタ全体の停止(例えば、共通電源障害)があります。Proxmoxはその点でかなり制限されています。VMに対して “HA Feature” を有効にし、 “Start and Shutdown Order” で制約を定義することはできます。しかし、両者は完全に分離されています。従って、コントローラVMを起動してから、他のすべてのVMを起動することを保証するのは困難です。

コントローラVMが起動するまでProxmoxプラグイン自身でVMの起動を遅らせる回避策というのは可能かもしれません。すなわち、プラグインがコントローラVMを起動するように要求された場合はそのようにする、そうでなければ、待機し、コントローラにpingを送るという方法です。一見良いアイデアのようですが、シリアライズされた並列でないVM起動環境では動作しません。コントローラVMが起動するようスケジュールされる前にあるVMが起動されなければならないような環境です。これは明らかにデッドロックを引き起こします。

Proxmox側といろいろなオプションを話し合っていますが、今回示した方法は通常の使用法では価値があり、特にpacemakerの設定の複雑さと比較して価値があると考えます。クラスタ全体が同時にダウンしないこのようなシナリオでは、管理者はProxmox HAサービスがコントローラVMを起動するまで待つだけでよく、その後、すべてのVMが自動的に起動されます。VMはコマンドラインで手動またはスクリプトで起動することができます。

5. OpenNebulaのLINSTORボリューム

この章では、OpenNebulaのDRBDについて LINSTOR storage driver addon の使用法を説明します。

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

5.1. OpenNebulaの概要

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

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

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

5.3. 配備オプション

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

5.4. 構成

5.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 サービスを再起動します。

5.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 リソースを削除するときに問題が発生します。

5.4.3. Oneadminのアクセス権

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

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

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

usermod -a -G disk oneadmin

5.4.4. 新しいLinstorデータストアの作成

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

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

5.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データストアにイメージをクローンする場合にも使用されます。

5.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クラスター内のすべてのストレージノードがまだ含まれていることに注意してください。

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

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

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

5.6. 空き容量の計算

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

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

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

6. OpenStackでのLINSTORボリューム

この章では、永続的で複製された高性能ブロックストレージであるDRBDの LINSTOR ドライバ についてOpenstackでの使用法を説明します。

6.1. Openstackの概要

Openstackは幅広い個別のサービスで構成されています。DRBDに最も関連性の高い2つは、CinderとNovaです。 Cinder はブロックストレージサービスです。 Nova はVMで使用可能なボリュームを作成する計算ノードサービスです。

OpenStackのLINSTORドライバは、DRBD/LINSTORクラスタを管理し、OpenStack環境、特にNova computeインスタンス内で使用されます。LINSTORでサポートされているCinderボリュームは、DRBD/LINSTORのすべての機能をシームレスに提供し、OpenStackはすべての配備と管理を実行できます。ドライバは、OpenStackが永続的なLINSTORボリュームの作成と削除、ボリュームスナップショットとローボリュームイメージの管理と配備を可能にします。

カーネル特有のDRBDプロトコルをレプリケーションに使用する以外に、LINSTORドライバでは、LINSTORクラスタでiSCSIを使用して最大の互換性を得ることができます。これら2つのオプションの詳細については、 トランスポートプロトコルの選択 を参照ください。

6.2. OpenstackのLINSTORインストレーション

OpenStackドライバをインストールする前に、DRBDとLINSTORの初期インストールと設定を完了する必要があります。クラスタ内の各LINSTORノードにもストレージプールが定義されている必要があります。 LINSTORのインストールに関する詳細は、 こちら を参照ください。

6.2.1. UbuntuでLINSTORクラスタをすばやく設定する方法について

LINSTORコントローラノードとしてCinderノードにDRBDとLINSTORをインストール
# まず、サポート契約のLINBITリポジトリを設定します

# DRBDとLINSTORパッケージをインストールします
sudo apt update
sudo apt install -y drbd-dkms lvm2
sudo apt install -y linstor-controller linstor-satellite linstor-client
sudo apt install -y drbdtop

# LINSTORコントローラとサテライトの両方を開始します
systemctl enable linstor-controller.service
systemctl start linstor-controller.service
systemctl enable linstor-satellite.service
systemctl start linstor-satellite.service

# ディスクレスコントローラの場合は、次の2つの 'sudo' コマンドはスキップします

# ディスクフルコントローラの場合は、DRBD/LINSTOR のバックエンドストレージをボリュームグループ 'drbdpool' として作成します。このとき適切なボリューム (/dev/vdb) を指定します
sudo vgcreate drbdpool /dev/vdb

# 'drbdpool' に論理ボリューム 'thinpool' を作成します
# 適切なボリュームサイズ (64G) を指定します
sudo lvcreate -L 64G -T drbdpool/thinpool
OpenStackはGiBでストレージサイズを測定します。
LINSTORクラスタの他のノードにDRBDとLINSTORをインストール
# まず、サポート契約のLINBITリポジトリを設定します

# DRBDとLINSTORパッケージをインストールします
sudo apt update
sudo apt install -y drbd-dkms lvm2
sudo apt install -y linstor-satellite
sudo apt install -y drbdtop

# LINSTOR サテライトサービスだけを開始します
systemctl enable linstor-satellite.service
systemctl start linstor-satellite.service

# DRBD/LINSTOR のバックエンドストレージをボリュームグループ 'drbdpool' として作成します。このとき適切なボリューム (/dev/vdb) を指定します
sudo vgcreate drbdpool /dev/vdb

# 'drbdpool' に論理ボリューム 'thinpool' を作成します
# 適切なボリュームサイズ (64G) を指定します
sudo lvcreate -L 64G -T drbdpool/thinpool
最後に、Cinderノードから、LINSTOR サテライトノードとストレージプールを作成
# LINSTOR クラスタを作成し、ノードのうち1つに Cinder ノードを含めます
# ノード毎にノード名、IPアドレス、ボリュームタイプ(ディスクレス)、
# ボリュームの場所 (drbdpool/thinpool) を指定します

# コントローラノードはコントローラとサテライトの combined ノードとして作成します
linstor node create cinder-node-name 192.168.1.100 --node-type Combined

# サテライトノードを作成します
linstor node create another-node-name 192.168.1.101
# LINSTOR クラスタにさらにサテライトがある場合は繰り返します

# 各ノードで LINSTOR ストレージプールを作成します
# ノードごとにノード名、IPアドレス
# ストレージプール名 (DfltStorPool),
# ボリュームタイプ (diskless / lvmthin) とノードタイプ(Combined) を指定します

# Cinder コントローラでディスクレスコントローラノードを作成します
linstor storage-pool create diskless cinder-node-name DfltStorPool

# ディスクフルサテライトノードを作成します
linstor storage-pool create lvmthin another-node-name DfltStorPool drbdpool/thinpool
# LINSTOR クラスタにさらにサテライトがある場合は繰り返します

6.2.2. LINSTORドライバファイルをインストール

linstorドライバ は OpenStack Stein リリースから正式に利用可能になります。最新リリースは LINBIT OpenStack Repo にあります。 linstordrv.py という単一のPythonファイルです。OpenStackのインストール形態によっては、インストール先が異なります。

ドライバ(linstordrv.py)をOpenStack Cinderノードの適切な場所にインストールします。

Devstackの場合:

/opt/stack/cinder/cinder/volume/drivers/linstordrv.py

Ubuntuの場合:

/usr/lib/python2.7/dist-packages/cinder/volume/drivers/linstordrv.py

RDO Packstackの場合:

/usr/lib/python2.7/site-packages/cinder/volume/drivers/linstordrv.py

6.3. LINSTORのCinder構成

6.3.1. /etc/cinder/ 内のCinder設定ファイル cinder.conf を次のように編集

enabled_backendsに ‘linstor’ を追加してLINSTORドライバを有効
[DEFAULT]
...
enabled_backends=lvm, linstor
...
cinder.confの最後に次の設定オプションを追加
[linstor]
volume_backend_name = linstor
volume_driver = cinder.volume.drivers.linstordrv.LinstorDrbdDriver
linstor_default_volume_group_name=drbdpool
linstor_default_uri=linstor://localhost
linstor_default_storage_pool_name=DfltStorPool
linstor_default_resource_size=1
linstor_volume_downsize_factor=4096

6.3.2. ドライバ用のPythonのPythonライブラリを更新

sudo pip install google --upgrade
sudo pip install protobuf --upgrade
sudo pip install eventlet --upgrade

6.3.3. LINSTOR用の新しいバックエンドタイプを作成

OpenStackコマンドライン用に環境変数を設定した後、これらのコマンドをCinderノードから実行します。

cinder type-create linstor
cinder type-key linstor set volume_backend_name=linstor

6.3.4. 最後にCinderサービスを再起動

Devstackの場合:

sudo systemctl restart [email protected]
sudo systemctl restart [email protected]
sudo systemctl restart [email protected]

RDO Packstackの場合:

sudo systemctl restart openstack-cinder-volume.service
sudo systemctl restart openstack-cinder-api.service
sudo systemctl restart openstack-cinder-scheduler.service

フルOpenStackの場合:

sudo systemctl restart cinder-volume.service
sudo systemctl restart cinder-api.service
sudo systemctl restart cinder-scheduler.service

6.3.5. 適切なインストールを確認

Cinderサービスを再起動すると、Horizon GUIまたはコマンドラインを使用して、LINSTORバックエンドの新しいCinderボリュームを作成できます。コマンドラインを使用してボリュームを作成する際には、以下のガイドを参考にしてください。

# ドライバに何らかの定期的なエラーがないかどうか確認してください。
# 特にデータベースに関連付けられている 'ERROR' キーワードが正常であるか。
# Ctrl-C でログ出力を停止します。
sudo systemctl -f -u [email protected]* | grep error

# LINSTOR テストボリュームを作成します。ボリュームが作成された後、volume list
# コマンドは1つの新しい Cinder ボリュームを表示します。 'linstor' コマンドは
# Cinder ボリュームのクラスタバッキング内に実際のリソースノードを表示します
openstack volume create --type linstor --size 1 --availability-zone nova linstor-test-vol
openstack volume list
linstor resource list

6.3.6. 追加設定

More to come

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

CinderでDRBD/LINSTORを実行するには、主に2つの方法があります。

これらは排他的ではありません。複数のバックエンドを定義し、それらのうちのいくつかはiSCSIを使用し、他のものはDRBDプロトコルを使用できます。

6.4.1. iSCSIトランスポート

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

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

6.4.2. DRBD/LINSTORトランスポート

DRBDをトランスポートプロトコルとして使用してVMにデータを送信する方法もあります。これは DRBD 9[2] を参照ください。]もCinderノードにインストールする必要があることを意味します。

OpenStackはLinuxのみで機能するため、DRBD/LINSTOR トランスポートを使用すると、現時点でKVMを搭載したLinuxホストでのみでの配備に制限されます。

この解決策の1つの利点は、VMのストレージアクセス要求がDRBDカーネルモジュールを介してストレージノードに送信され、ストレージノードが割り当てられたLVに直接アクセスできることです。これは、データパス上にカーネル/ユーザスペースの遷移がないことを意味し、結果的にパフォーマンスが向上します。 RDMA対応のハードウェアと組み合わせると、FCバックエンドに直接アクセスするVMとほぼ同じパフォーマンスが得られます。

もう1つの利点は、DRBDのHAバックグラウンドから暗黙的に利益を得ることです。複数のストレージノードを使用すると、異なるネットワーク接続で使用できる可能性があり冗長性を意味し、単一障害点を回避します。

Cinderドライバのデフォルトの設定オプションは、CinderノードがディスクレスLINSTORノードであることを前提としています。ノードがディスクフルノードの場合は、 ‘linstor_controller_diskless = True’ を ‘linstor_controller_diskless = False’ に変更して、Cinderサービスを再起動してください。

6.4.3. トランスポートプロトコルの設定

cinder.conf のLINSTORセクションで、使用するトランスポートプロトコルを定義することができます。この章の冒頭で説明した初期設定では、DRBDトランスポートを使用するように設定されています。必要に応じて以下のように設定することができます。その後、Horizon[3]は、ボリューム作成時にこれらのストレージバックエンドを提供する必要があります。

  • LINSTORでiSCSIを使用するには:

        volume_driver=cinder.volume.drivers.drbdmanagedrv.DrbdManageIscsiDriver
  • LINSTORでDRBDカーネルモジュールを使用するには:

        volume_driver=cinder.volume.drivers.drbdmanagedrv.DrbdManageDrbdDriver

互換性の理由から古いクラス名 “DrbdManageDriver” は当面維持されます。これは単にiSCSIドライバのエイリアスです。

要約:

  • LINSTOR Cinderドライバ0.1.0以降とLINSTOR 0.6.5以降が必要である。

  • DRBD transport protocol を 推奨。iSCSIは互換性重視の場合使用する。

  • ディスク容量が不足しないように、特に Thin ボリュームでは注意する。

7. DockerのLINSTORボリューム

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

7.1. Dockerの概要

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

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

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

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

# docker plugin install linbit/linstor-docker-volume

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

7.4. 使用例

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

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

ノードalpha上:

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

ノードbravo上:

$ docker run -it --rm --name=cont \
             -v lsvol:/data --volume-driver=linstor busybox sh
$ [email protected]: cat /data/test.txt
  foo
$ [email protected]: exit
$ docker volume rm lsvol

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

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

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

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

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

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

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

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

1. ホストがストレージノードでもある場合は、イメージのローカルコピーを使用できます
2. LINSTORをCinderノードにインストールする必要があります。 [s-openstack-linstor-drbd-external-NOTE
3. OpenStack GUI