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 には、クラスター全体のすべての構成情報を保持するデータベースが含まれています。それはクラスタ全体の情報を持ち必要なすべての決定を下します。コントローラは、PacemakerとDRBDを使用してHAサービスとして配備されるのが一般的です。これは、システムの重要な部分だからです。 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はコンテナとしても利用可能です。ベースイメージはLINBITのコンテナレジストリ drbd.io にあります。

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

# docker login drbd.io

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

  • drbd.io/drbd9:rhel8

  • drbd.io/drbd9:rhel7

  • drbd.io/drbd9:bionic

  • drbd.io/linstor-csi

  • drbd.io/linstor-controller

  • drbd.io/linstor-satellite

  • drbd.io/linstor-client

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

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

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

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

  • ソースからビルドするために上記のいずれも行わない。

ハッシュとディストリビューションを指定する場合:

# 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
どちらの場合でも(ハッシュ+ディストリビューションまたは既存のリポジトリ設定をバインドマウント)、これらが設定されたノードから使用する必要があります。これらの設定に関してはサポートにお問い合わせください。

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

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

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

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

RHEL ベースのシステムでは /usr/lib をバインドマウントしないでください。Debian ベースのものはバインドマウントすることを忘れないでください。

今のところ(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.6. クラスタの初期化

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

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

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

  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.9. ストレージプール

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

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

1.10. リソースグループ

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

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

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

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

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

  • Thick LVM

  • 単一の thin プールの Thin LVM

  • Thick ZFS

  • Thin ZFS

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

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

オプション—​auto-placeに続く数値は複製の数を指定します。--storage-poolはストレージプール名を指定します。

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

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

  • 現在のユーザがアクセスできないすべてのノードとストレージプールは無視する。

  • すべてのディスクのないストレージプールは無視する

  • 十分な空き領域がないストレージプールは無視する

残ったストレージプールから、LINSTORが最も空き領域があるものを選択します。

すべてがうまくいくと、DRBDリソースがLINSTORによって作成されます。 lsblk コマンドでDRBDブロックデバイスを探すことで確認でき、 drbd0000 のように見えるはずです。

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

2. LINSTOR 応用タスク

2.1. DRBDクライアント

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

# linstor resource create delta backups --diskless

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-list の組み合わせのリストは以下の通りです。

  • drbd,luks,storage

  • drbd,storage

  • luks,storage

  • nvme,storage

  • storage

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-definiton 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.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がストレージデバイスから提供されるストレージを暗号化するのに使われます。

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

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

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

  3. layer-list に luks を追加する

  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.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はリソースが使用中でも一貫性のあるスナップショットが取れることを保証します。

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

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

外部データベースを使用するには、追加の構成手順が必要です。外部 SQL データベースは JDBC ドライバーをダウンロードして lib フォルダーにコピーする必要があります。ETCD は LINSTOR を正しく構成する必要があります。

2.12.1. Postgresql

Postgresql JDBCドライバは以下からダウンロードできます。

そして、 /usr/share/linstor-server/lib/ にコピーします

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

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

2.12.2. MariaDB/Mysql

MariaDB JDBCドライバは以下からダウンロードできます。

そして、 /usr/share/linstor-server/lib/ にコピーします

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_pcks8_pem = "client-key.pcks8"
## 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 がコントローラ、ノード bravo` と charlie がサテライトとします。

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

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


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

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

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

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

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

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

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

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

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

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

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

2.16. AutoQuorum Policies

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

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

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

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

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

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

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

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

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

2.17. ヘルプの利用

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

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

2.17.3. GitHub

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

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

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

3. Kubernetes で LINSTOR ボリューム

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

3.1. Kubernetesの概要

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

3.2. LINSTOR CSIプラグインの配備

CSIプラグインを配備するための手順は project’s github にあります。これにより linstor-csi-controller StatefulSet と linstor-csi-node DaemonSet が kube-system 名前空間で動作します。

NAME                       READY   STATUS    RESTARTS   AGE     IP              NODE
linstor-csi-controller-0   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.3. 基本的な構成と配備

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

Kubernetesを介して配備されるLINSTORボリュームの動作とプロパティの設定は、StorageClass を使用して行います。以下はボリュームを配備する最も簡単な 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"

次のコマンドで 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.4. スナップショット

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

Listing 4. my-first-linstor-snapshot-class.yaml
kind: VolumeSnapshotClass
apiVersion: snapshot.storage.k8s.io/v1alpha1
metadata:
  name: my-first-linstor-snapshot-class
  namespace: kube-system
snapshotter: io.drbd.linstor-csi

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

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

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

Listing 5. my-first-linstor-snapshot.yaml
apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshot
metadata:
  name: my-first-linstor-snapshot
spec:
  snapshotClassName: my-first-linstor-snapshot-class
  source:
    name: my-first-linstor-volume
    kind: PersistentVolumeClaim

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

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

最後にスナップショットから 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.5. ボリュームへのアクセス

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

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

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

3.6. 高度な設定

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

3.6.1. nodeList

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

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

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

例: nodeList: "node-a"

3.6.2. autoPlace

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

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

例: autoPlace: 2

例: autoPlace: 1

3.6.3. replicasOnSame

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

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

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

3.6.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.6.6. storagePool

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

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

例: storagePool: my-storage-pool

3.6.7. disklessStoragePool

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

例: disklessStoragePool: my-custom-diskless-pool

3.6.8. encryption

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

例: encryption: "true"

3.6.9. filesystem

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

例: filesystem: "xfs"

デフォルト: filesystem: "ext4"

3.6.10. fsOpts

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

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

例: fsOpts: "-b 2048"

3.6.11. mountOpts

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

例: mountOpts: "sync,noatime"

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

この章はhttps://github.com/LINBIT/linstor-proxmox.git[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プラグインのインストール

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のメジャーバージョンを指定します(例、"5")。

# wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add -
# PVERS=5 && 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.3. LINSTORの設定

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

4.4. 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ボリュームを使用できます。

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

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

4.5. コントローラの高可用性

これ以降の説明では、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

By default, at startup the linstor-satellite service deletes all of its resource files (.res) and regenerates them. This conflicts with the drbd services that needs these resource files to start the controller VM. It is good enough to first bring up the resources via drbd.service and ensure that the linstor-satellite.service, which brings up the controller resource never deletes the according res file. To make the necessary changes, you need to create a drop-in for the linstor-satellite.service via systemctl (do *not edit the file directly).

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

Of course adapt the name of the controller VM in the LS_KEEP_RES variable. Note that the value given is interpreted as regex, so you don’t need to specify the exact name.

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

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

# systemctl stop linstor-controller
# systemctl disable linstor-controller
# scp /var/lib/linstor/* root@10.43.7.254:/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にストレージプールを作成します。

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はリソースグループをサポートしています。リソースグループは、そのリソースグループにリンクされているすべてのリソースが共有する設定の一元化されたポイントです。

ここでは、データストアのリソースグループとボリュームグループを作成します。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 devstack@c-vol.service
sudo systemctl restart devstack@c-api.service
sudo systemctl restart devstack@c-sch.service

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 devstack@c-* | 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 パッケージをインストールするには、LINBITの drbd-9.0 リポジトリを有効にする必要があります。有効になったら、パッケージマネージャを使って linstor-docker-volume パッケージをインストールしてください。

# yum install linstor-docker-volume

  -- または --

# apt install linstor-docker-volume

あるいは、ソースからビルドしてインストールすることもできます。

# git clone https://github.com/LINBIT/linstor-docker-volume
# cd ./linstor-docker-volume
# make
  ..snip..
# make doc
  ..snip..
# make install
  ..snip..

インストールが完了したら systemdlinstor-docker-volume.socketlinstor-docker-volume.service を有効にして起動します。

# systemctl enable linstor-docker-volume.socket linstor-docker-volume.service --now

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

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

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

docker-volume.confman linstor-docker-volume にあるすべてのコマンドラインオプションを設定することも可能です。例えば:

# cat /etc/linstor/docker-volume.conf
[global]
storagepool = thin-lvm
fs = ext4
fsopts = -E discard
size = 100MB
replicas = 2
nodes = alpha,bravo,charlie
replicasnodes も定義されていない場合は、デフォルトの replicas が使用されます。これは2つのディスクフルの複製です。 replicasnodes の両方が定義されている場合、nodes が使用され replicas は無視されます。

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
$ root@cont: echo "foo" > /data/test.txt
$ root@cont: exit

ノードbravo上:

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

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

$ docker volume create -d linstor --opt hosts=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 hosts=alpha,bravo lsvol

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

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

7.4.6. 例6 - dockerでなくcurlを使う、開発者向け

$ curl --unix-socket /run/docker/plugins/linstor.sock \
          -X POST -H "Content-Type: application/json"
          -d '{"Name":"linstorvol"}' http://localhost/VolumeDriver.List

付録

8. DRBD Manage

DRBD Manage は 2018年の EoL に達し、LINSTOR に置き換えられます。

DRBD Manageは論理ボリューム(LVM)とDRBDの設定ファイルの管理を行う抽象化レイヤーです。DRBD Manageの機能には、DRBDボリュームの作成、リサイズ、削除が含まれます。 また、DRBD ManageはDRBD領域のスナップショット作成やボリューム作成も制御します。

この章では一般的なオペレーションでの管理作業を説明します。トラブルシューティングについては扱いません。トラブルシューティングについては[ch-troubleshooting]を参照ください。ストレージプラグインとして LVM を使用する場合は、LVM の設定 セクションを読んでから、ここに戻ってきてください。

8.1. DRBDManage から LINSTOR へリソースの移行

LINSTOR クライアントには、既存の DRBDManage ノードとリソースを LINSTOR クラスタに追加する移行スクリプトを生成できるサブコマンドが含まれています。移行はダウンタイムなしで実行できます。既存のリソースを移行する予定がない場合は、次のセクションに進んでください。

最初に確認することは、DRBDManage クラスターが正常な状態にあるかどうかです。 drbdmanage assignments の出力が問題なければ、 drbdmanage export-ctrlvol > ctrlvol.json で既存のクラスタデータベースをエクスポートすることができます。これを LINSTOR クライアントの入力として使うことができます。クライアントはただちにリソースを移行するのではなく、単にシェルスクリプトを生成するだけです。したがって、実際に実行する前に、移行アシスタントを複数回実行し、生成されたシェルスクリプトを確認/変更することができます。移行スクリプトの生成は linstor dm-migrate ctrlvol.json dmmmigrate.sh で開始します。 スクリプトはいくつかの質問をしてからシェルスクリプトを生成します。生成されたスクリプトを注意深く確認した後、DRBDManage をシャットダウンして、名前を変更しておきます。名前を変更しないと、 drbd-utils が DRBDManage と LINSTOR の両方の種類のリソースファイルを使用してしまいます。

もちろん 1 つのノードで linstor-controller サービスを開始し、すべてのノードで linstor-satellite サービスを開始する必要があります。

# drbdmanage shutdown -qc # on all nodes
# mv /etc/drbd.d/drbdctrl.res{,.dis} # on all nodes
# mv /etc/drbd.d/drbdmanage-resources.res{,.dis} # on all nodes
# bash dmmigrate.sh

8.2. クラスタの初期設定

前提として、以下の手順が すべての クラスタノードで行われている必要があります。

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

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

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

  4. drbdmanage と、その依存関係のあるパッケージがインストールされている。

サーバコンポーネントの開始が必要な場合は、DRBDmanageがDBusアクティベーションを使用して行います。手動では行わないでください。

まず最初に drbdmanage の設定ファイル( /etc/drbdmanaged.cfg )を確認し、設定ファイルで指定した名前の LVM ボリュームグループを作成します。以下の例ではデフォルト名の drbdpool を使用し, /dev/sda6/dev/sda7 からなるボリュームグループを作成しています。ボリュームグループの作成は、 すべての クラスタノードで行います。

# vgcreate drbdpool /dev/sda6 /dev/sda7

次に、クラスタ設定を全クラスタノードに配布するために使用する「コントロールボリューム」を作成します。ノードに複数のインターフェースがある場合は、DRBDが他のノードとの通信に使用するIPアドレスを指定する必要があります。そうでない場合にはIPアドレス指定は任意項目です。この作業は1つのノードで実行すれば十分です。

# drbdmanage init 10.43.70.2

LVMボリューム名は管理者の負担も減りますので、デフォルトのまま 'drbdpool' を使用するのがよいでしょう。何らかの理由で別の名前を使用する場合には、/etc/drbdmanaged.cfg で正しく drbdctrl-vg オプションが設定されているか確認してください。設定はクラスタ設定で説明します。

8.3. ノードの追加

クラスタへのノードの追加は簡単で、コマンドを1つ、パラメータを2つ付けて実行するだけです。

  1. パラメータの1つはノード名で、これは 必ず uname -n の出力結果と一致していなければなりません。

  2. ノードの IP アドレス。

注意

DNSが適切に設定されていれば、 drbdmanage はノード名に対するIPアドレスをタブ補完することができます。

# drbdmanage add-node bravo 10.43.70.3

コマンドが 'alpha' ノードで実行されたものとします。このとき 'root' ユーザーが ssh 経由で 'bravo' ノード上で 'root' ユーザーとしてコマンドが実行できれば、 'bravo' ノードは自動的にクラスタに参加します。

公開鍵認証で ssh ログインができない場合は、 drbdmanage は 'bravo' ノードをクラスタに参加させるコマンドを表示しますので、これを 'bravo' ノードで実行します。参加させたいノードで実行するためのコマンドは、いつでも drbdmanage で確認することができます。

# drbdmanage howto-join bravo
# drbdmanage join -p 6999 10.43.70.3 1 alpha 10.43.70.2 0 cOQutgNMrinBXb09A3io

8.3.1. DRBD Manageノードの種類

DRBD Manageが扱うノードは数種類あります。以下の図を見てください。

drbdmanage venn
Figure 5. DRBDのノードの種類

ノードに種類がある理由は次の通りです。現在はDRBD9/DRBD Manageクラスタは30ノード以下という制限があります。これは現在のDRBD9のレプリケーションするノード数に対する制限です。DRBD Manageはクラスタ情報の伝播にDRBDのボリュームを使用する(コントロールボリューム)ので、DRBD ManageはリソースごとにDRBD9のノード数の制限を受けます。

サテライトのコンセプトは、この制限をクラスタを以下のように分けることで緩和するものです。

  • コントロールノード: コントロールボリュームへ直接アクセスできる。

  • サテライトノード: 直接コントロールボリュームにアクセスすることはできないが、コントロールノードを通じてコントロールボリュームの内容を受け取ることができる。

1つのコントロールノードは複数のサテライトノードに応答しますが、1つのサテライトノードは1つのコントロールにのみ割り当てられます。当然サテライトノードもDRBD9のリソースを共有することができます。

コントロールノード には以下の特徴があります。

  • コントロールボリュームへ直接接続

  • 1つがリーダーの役割を担い、残りはサテライトノードの役割を担う。

  • 通常のコントロールノードであればローカルストレージを持つ

  • ピュアコントローラであればローカルストレージを持たない

サテライトノード には以下の特徴があります。

  • コントロールノードへの直接のアクセスは不可。TCP/IPを通じてクラスタ設定を受け取る。

  • 通常のサテライトノードであればローカルストレージを持つ

  • ピュアクライアントであればローカルストレージを持たない

satellitecluster
Figure 6. サテライトノードを使ったクラスタ構成

外部ノード には以下の特徴があります。

  • 完全にコントロールボリュームへのコネクションがなく(コントロールノードへのコネクション用TCP/IP経路がない)、ローカルストレージがない

  • 別の経路から設定ファイルを入手する( scp など)

  • このノードの使用方法が不明な場合は使用すべきではない

8.3.2. コントロールノードの追加

# drbdmanage add-node bravo 10.43.70.3

8.3.3. ピュアコントローラーノード追加

# drbdmanage add-node --no-storage bravo 10.43.70.3

8.3.4. サテライトノードの追加

これまでCharlieノードはクラスタに追加されていなかったものとします。以下のコマンドではCharlieを、alphaをコントロールノードとするサテライトノードとして追加しています。

# drbdmanage add-node --satellite charlie 10.43.70.4

8.3.5. ピュアクライアントノードの追加

# drbdmanage add-node --satellite --no-storage charlie 10.43.70.4

8.3.6. 外部ノードの追加

# drbdmanage add-node --external delta 10.43.70.5

8.4. クラスタ設定

DRBD Manageは、ログレベルや使用するストレージプラグイン(LVM、ThinLV、ThinPoolなど)の多くの設定を行うことができます。これらの設定は drbdmanage modify-config を実行すると表示されるエディタで行います。設定は何項目かに分けられます。[GLOBAL] セクションでオプション設定を行うと、この設定はクラスタ全体で有効になります。また、ノードごとやサイトごとの設定を行うことも可能です。ノードセクションは [Node:nodename] の後に書いていきます。もしオプション設定をグローバルセクションとノードセクションの両方に行った場合には、ノードセクションの設定が使用されます。

複数のノードを束ねて サイト として取り扱えます。'alpha' ノードを 'mysite' の一部にしたい場合は、alphaのノードセクションで 'site' オプションを指定してください。

# drbdmanage modify-config
[Node:alpha]
site = mysite

drbdmanage設定の [Site:] セクションを使用して指定することも可能です。基本的に 'loglevel' オプションのレベルは 'INFO' に設定しますが、 'mysite' サイトでは 'WARN' レベルに設定して、 'mysite' サイト内にあるalphaノードでは 'DEBUG' に設定したいとします。その場合には、以下のように記述します。

# drbdmanage modify-config
[GLOBAL]
loglevel = INFO

[Site:mysite]
loglevel = WARN

[Node:alpha]
site = mysite
loglevel = DEBUG

drbdmanage modify-config をオプションを付けずに実行すると、グローバル、サイトごと、ノードごとの設定ができます。 'modify-config' は特定ノード用に実行することも可能です。このノードごとのビューでは、ストレージプラグインの設定で説明しているストレージプラグインの設定のような特定の設定も可能です。

8.5. ストレージプラグインの設定

ストレージプラグインは ノード ごと に 'modify-config' サブコマンドで設定します。

'ThinLV' プラグインをノード 'bravo' に使用し、 'pool-name' オプションを 'mythinpool' にしたい場合には次のようにします。

# drbdmanage modify-config --node bravo
[GLOBAL]
loglevel = INFO

[Node:bravo]
storage-plugin = drbdmanage.storage.lvm_thinlv.LvmThinLv

[Plugin:ThinLV]
pool-name = mythinpool

8.5.1. LVM の設定

最近のバージョンの 'LVMツール' は、ファイルシステムのシグネチャ検出をサポートしています。ただ lvcreate の機能はディストリビューションの間で異なります。いくつかのものは --wipesignatures オプションをサポートし、また、いくつこのものは --yes オプションをサポートしています。しかし、一般的な強制フラグをサポートしているものはありません。lvcreate が既存のファイルシステムのシグネチャを検出すると、入力を促し処理を停止ししてしまいます。最近のバージョンの 'LVMツール' を使用している場合は、 /etc/lvm/lvm.conf に ` wipe_signatures_when_zeroing_new_lvs = 0` を設定してください。Drbdmanage自体は、作成されたブロックデバイスに対して wipefs を実行します。

If you use a version of 'LVM' where resources from snapshots are not activated, which we saw for the 'LvmThinPool' plugin, also set auto_set_activation_skip = 0 in /etc/lvm/lvm.conf.

8.5.2. ZFS の設定

ZFSでも同じ手順です。ZFSボリュームを使用するノードに 'storage-plugin' と同様の設定をします。ZFSはファイルシステムとしては扱われず、論理ボリュームマネージャーとして扱われるという点に注意ください。そのため下位デバイスがZFSボリュームのDRBDデバイスの上に、どのようなファイルシステムでも作成することができます。ZFSプラグインを使う場合には、すべてのDRBDリソースはZFS上に作成してあることが重要ですが、ノードがコントロールノードである場合には、コントロールボリューム用にLVMが必要です。

一般的な利用では以下の手順が必要です。

# zpool create drbdpool /dev/sdX /dev/sdY
# drbdmanage modify-config --node bravo
[Node:bravo]
storage-plugin = drbdmanage.storage.zvol2.Zvol2
現在はストレージプラグインの稼働中の変更は未対応です。 ワークフローは、ノードの追加、そのノードの設定の実施、ノードの使用、という流れになります。ログレベルなどの他の設定変更は稼働中でも問題ありません。

8.5.3. ストレージプラグインについての情報

DRBD Manageは以下のストレージプラグインに対応しています。

  • Thick LVM (drbdmanage.storage.lvm.Lvm);

  • Thin LVM with a single thin pool (drbdmanage.storage.lvm_thinlv.LvmThinLv)

  • Thin LVM with thin pools for each volume (drbdmanage.storage.lvm_thinpool.LvmThinPool)

  • Thick ZFS (drbdmanage.storage.zvol2.Zvol2)

  • Thin ZFS (drbdmanage.storage.zvol2_thinlv.ZvolThinLv2)

ZFSの場合、レガシープラグイン("2"なし)も存在します。新規ユーザー、および ZFS スナップショットを使用しなかったユーザーは、新しいバージョンに切り替えるべきです。ストレージプラグインの動的変更はこの特定のケースでサポートされています。

以下は各プラグインの長所と短所をまとめたものです。

Table 1. DRBD Manageストレージプラグイン比較表
Topic lvm.Lvm lvm_thinlv.LvmThinLv lvm_thinpool.LvmThinPool

Pools

the VG is the pool

a single Thin pool

one Thin pool for each volume

Free Space reporting

Exact

Free space goes down as per written data and snapshots, needs monitoring

Each pool carves some space out of the VG, but still needs to be monitored if snapshots are used

Allocation

Fully pre-allocated

thinly allocated, needs nearly zero space initially

Snapshots

 — not supported — 

Fast, efficient (copy-on-write)

Stability

Well established, known code, very stable

Some kernel versions have bugs re Thin LVs, destroying data

Recovery

Easiest - text editor, and/or lvm configuration archives in /etc/lvm/, in the worst case dd with offset/length

All data in one pool, might incur running thin_check across everything (needs CPU, memory, time)

Independent Pools, so not all volumes damaged at the same time, faster thin_check (less CPU, memory, time)

8.6. リソース/ボリュームの作成とデプロイ

3つのクラスタノードにレプリケートする '500 GB' の 'backups' リソースを作成するとします。 はじめに、各手順ごとに正式な手順を示します。次に手順をショートカットする方法を示します。

まず、新しいリソースを作成します。

# drbdmanage add-resource backups

次に、そのリソースの中に新しいボリュームを作成します。

# drbdmanage add-volume backups 500GB

最初の段階で 'add-resource' をしていなかった場合には、 drbdmanage はリソースが存在しないことを検知して作成します。

そして、3つのクラスタノードにリソースをデプロイします。

# drbdmanage deploy-resource backups 3

この場合、 drbdmanage は最も要件に合致する3ノードを選択します。デフォルトでは drbdpool 内に空きスペースがあるものから選ばれます。手動で任意のノードにリソースを割り当てる方法も次に説明します。

なお、新規リソース/ボリュームを複数ノードにデプロイする作業は頻繁にあるので、 drbdmanage には次のようなショートカットがあります。

# drbdmanage add-volume backups 500GB --deploy 3

手動デプロイは、特定ノードへ assign することで行えます。 'backups' リソースを 'bravo' と 'charlie' ノードにデプロイする場合には以下のようにします。

# drbdmanage add-volume backups 500GB
# drbdmanage assign-resource backups bravo
# drbdmanage assign-resource backups charlie

8.7. スナップショット管理

スナップショットを取得をするリソースがデプロイされているノード全てで ThinLV プラグインを使用している事が前提になります。ストレージプラグインの設定詳細についてはクラスタ設定を参照してください。

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

前のセクションで使用した例を使用します。 'alpha' 、 'bravo' 、 'charlie' 、 'delta' ノードがあり、最初の3つのノードに 'backups' リソースがデプロイされています。スナップショット名が 'snap_backups' で、 'bravo' と 'charlie' にスナップショットが欲しい場合は次のようにします。

# drbdmanage create-snapshot snap_backups backups bravo charlie

8.7.2. スナップショットのリストア

スナップショット名 'snap_backups' の内容を新規リソース 'res_backup_from_snap' にリストアしたい場合は次のようにします。

# drbdmanage restore-snapshot res_backup_from_snap backups snap_backups

このコマンドで 'res_backup_from_snap' という名前のリソースが作成されます。このリソースは自動的に、現在 'backups' リソースがデプロイされているノードにデプロイされます。

8.7.3. スナップショット削除

既存のスナップショットは次のようにして削除できます。

# drbdmanage remove-snapshot backups snap_backups

8.8. クラスタ状態の確認

Drbdmanage にはクラスタの状態を確認するための様々なコマンドがあります。 これらのコマンドには接頭語 'list-' が付き、様々なフィルタやソートのオプションがあります。'--groupby' オプションは様々な出力をグループ分けしたりソートするために使用します。'--show' オプションでは詳細な出力をすることができます。代表的な使い方を以下に示します。

# drbdmanage list-nodes
# drbdmanage list-volumes --groupby Size
# drbdmanage list-volumes --groupby Size --groupby Minor
# drbdmanage list-volumes --groupby Size --show Port

8.9. リソースのオプション設定をする

次の drbdsetup のオプションを設定することができます。

  1. net-options

  2. peer-device-options

  3. disk-options

  4. resource-options

加えて、DRBDイベントハンドラを設定することもできます。

リソースごとに 'common' セクションを設定するのと同じように、それらのコマンドを以下のようにして使うことができます。

max-buffers を 'backups' リソースに設定するのは次のようになります。

# drbdmanage net-options --max-buffers 2048 --resource backups

commonセクションにオプションを設定するのは次のようになります。

# drbdmanage net-options --max-buffers 2048 --common

さらに、すべてのオプションに '--unset-' を付けて使用することができます。max-buffers を 'backups' リソースから削除するには次のようにします。

# drbdmanage net-options --unset-max-buffers --resource backups

現在設定しているオプションは 'show-options' サブコマンドで表示することができます。

サイトごとに net-options を設定することも可能です。'alpha' と 'bravo' を 'first' サイトに、 'charlie' と 'delta' を 'second' サイトにするとします。さらに、2つのサイト内部ではDRBDのプロトコル 'C' を使用して、 'first' サイトと 'second' サイトの間ではプロトコル 'A' を使用するとします。この場合は次のようにして設定できます。

# drbdmanage modify-config
[Node:alpha]
site = first

[Node:bravo]
site = first

[Node:charlie]
site = second

[Node:delta]
site = second
# drbdmanage net-options --protocol C --sites 'first:first'
# drbdmanage net-options --protocol C --sites 'second:second'
# drbdmanage net-options --protocol A --sites 'first:second'

'--sites' パラメータには 'from:to' の構文が続きます。 'from' と 'to' は左右対称の構文です。'first:second' の設定は、同時に 'second:first' の設定も行います。

DRBDイベントハンドラは 'common' セクションとノードごとに設定できます。

# drbdmanage handlers --common --after-resync-target /path/to/script.sh
# drbdmanage handlers --common --unset-after-resync-target
# drbdmanage handlers --resource backups --after-resync-target /path/to/script.sh

8.10. DRBD Manageでのデータ再配置

データの再配置とは、利用可能なリソースの有効活用をするために、データの割り当てを移動することです。同様の例を<s-rebalance-workflow,manual workflow>> でも扱っています。

例えばデータを3ノードでレプリケーションするポリシーでは、構成するのに最低3台のサーバが必要です。

しかし、データ量が増えてくると、サーバ追加の必要性に迫られます。その際には、また新たに3台のサーバを購入する必要はなく、1つのノードだけを追加をしてデータを 再配置 することができます。

rebalance
Figure 7. DRBDデータ再配置

まず、新しいマシンをクラスタに追加します。コマンドはノードの追加 を参照してください。

次にリソースに新しいノードを追加します。

# drbdmanage assign <resource> <new-node>

(初期)同期が完了するまでしばらく待ちます。drbdadm status コマンドをリソース名をオプションにして使用すると状態を確認できます。

データがまだあるノードでは以下のようにステータス表示されます。

replication:SyncSource peer-disk:Inconsistent done:5.34

ターゲットノードでは SyncTarget の状態になります。

ターゲットのアサインが UpToDate になれば、そのノードにデータの完全な追加コピーが行われています。これで、他方のノードで既存のノードのリソース割り当てを解除できます。

# drbdmanage unassign <resource> <old-node>

さあ、これでデータの再配置が完了しました。

8.11. ヘルプ

もっとも簡単なDRBDmanageのサブコマンドの概要を知る方法はメインのman-page( man drbdmanage )を読むことです。

コマンドラインで使用できるコマンドをてっとり早く表示するには drbdmanage list とタイプします。

サブコマンド(例:list-nodes)のより詳しい情報は3つの方法で得られます。

# man drbdmanage-list-nodes
# drbdmanage list-nodes -h
# drbdmanage help list-nodes

'help' サブコマンドを使用するのは、特にDRBDmanageをインタラクティブモード(drbdmanage interactive)で使用している時に便利です。

DRBDmanageの最も便利な機能の1つは強力なタブ補完です。基本的にすべてのDRBDmanageが判別できる対象を補足することができます。(ノード名、IPアドレス、リソース名など) 以下に、補完の候補とその結果を示します。

# drbdmanage add-node alpha 1<tab> # completes the IP address if hostname can be resolved
# drbdmanage assign-resource b<tab> c<tab> # drbdmanage assign-resource backups charlie

そのままの状態でタブ補完ができない時には、以下のファイルを読み込んでください。

# source /etc/bash_completion.d/drbdmanage # or
# source /usr/share/bash_completion/completions/drbdmanage

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