LINSTOR ユーザーズガイド
最初にお読みください
このガイドは、software-defined storage (SDS) ソリューションである LINSTOR® のリファレンスガイドおよびハンドブックとして使用することを目的としています。
このガイドは全体を通して、あなたがLINSTORと関連ツールの最新版を使っていると仮定します。 |
このガイドは次のように構成されています。
-
基本管理タスクとシステム設定 ではLINSTORの基本的な機能を扱い、一般的な管理作業を使用するための方法を提供します。この章ではそれ以外に、LINSTORの基本設定を配備するためのステップバイステップのガイドとして使用できます。
-
LINSTOR 応用タスク では LINSTORをより複雑な方法で設定する、高度で重要なLINSTORタスクと設定が用意されています。
-
Kubernetes で LINSTOR ボリューム, Proxmox VE での LINSTOR ボリューム, OpenNebulaのLINSTORボリューム, OpenStackでのLINSTORボリューム, DockerのLINSTORボリューム では LINSTOR の API を使用して、Kubernetes、PROXMOX、Openebula、Openstack、およびDockerで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つだけです。
1.1.2. オブジェクト
オブジェクトは、Kubernetes/OpenShift、複製ブロックデバイス(DRBD)、NVMeOFターゲットなどLINSTORがエンドユーザーまたはアプリケーションに提示する最終結果です。
ノード
ノードは、LINSTORクラスタに参加するサーバーまたはコンテナです。ノード属性は、次のものを定義します。
-
ノードが参加しているLINSTORクラスターを決定します
-
ノードの役割を設定します:Controller、Satellite、Auxiliary
-
NetInterface オブジェクトはノードの接続を定義します
Definitions
Definitions はオブジェクトの属性を定義します。それらはプロファイルまたはテンプレートと考えることができます。作成されるオブジェクトは、definition で定義されている設定を継承します。関連オブジェクトを作成する前に definition を定義する必要があります。例えば Resource を作成する前に ResourceDefinition を作成する必要があります。
- StoragePoolDefinition
-
-
ストレージプールの名前を定義します
-
- ResourceDefinition
-
ResourceDefinition は、リソースの以下の属性を定義します。
-
DRBDリソースの名前
-
リソースの接続に使用するDRBDのTCPポート
-
- VolumeDefinition
-
VolumeDefinition は以下を定義します。
-
DRBDリソースのボリューム
-
ボリュームのサイズ
-
DRBDリソースのボリュームのボリューム番号
-
ボリュームのメタデータプロパティ
-
DRBDボリュームに関連付けられているDRBDデバイスで使用するマイナー番号
-
StoragePool
StoragePool は、LINSTORのコンテキストでストレージを識別し、以下を定義します:
-
特定のノード上のストレージプールの構成
-
クラスタノード上のストレージプールで使用するストレージバックエンドドライバ(LVM, ZFSなど)
-
ストレージバックアップドライバに渡すパラメータとその設定
1.2. よりハイレベルな適用
LINSTORはDRBD管理をより便利にするものとして使われる一方で、よりハイレベルなソフトウェアスタックとしても使われます。例えば、Kubernetes、OpenStack、OpenNebula、Proxmoxなどが該当します。これらの環境でLINSTORを使用するには専用の各章を参照ください。
LINSTORのサウスバウンドドライバには、LVM、thinLVM、ZFSがあり、Swordfishのサポートも現在開発中です。
1.3. パッケージ
LINSTOR は RPM と DEB 形式でパッケージングされています。
-
linstor-client にはコマンドラインのクライアントプログラムが含まれていて、通常すでにインストールされているpythonのみに依存しています。RHEL8 システムでは python をシンボリックリンクする必要があります。
-
linstor-controller と linstor-satellite の両方に、サービス用のsystemdユニットファイルが含まれています。それらは Java Runtime Environment (JRE) version 1.8 (headless) 以上に依存します。
これらのパッケージについての詳細は Installable Components を参照ください。
If you have a support subscription to LINBIT®, you will have access to our certified binaries through our repositories. |
1.4. FIPS Compliance
“This standard shall be used in designing and implementing cryptographic modules…” — NIST’s FIPS 140-3 publication
You can configure LINSTOR to encrypt storage volumes, by using LUKS
(dm-crypt
), as detailed in the Encrypted
Volumes section of this user’s guide. Refer to the LUKS and dm-crypt
projects for FIPS compliance status.
You can also configure LINSTOR to encrypt communication traffic between a LINSTOR satellite and a LINSTOR controller, by using SSL/TLS, as detailed in the Secure Satellite Connections section of this user’s guide.
LINSTOR can also interface with Self-Encrypting Drives (SEDs) and you can use LINSTOR to initialize an SED drive. LINSTOR stores the drive’s password as a property that applies to the storage pool associated with the drive. LINSTOR encrypts the SED drive password by using the LINSTOR master passphrase that you must create first.
By default, LINSTOR uses the following cryptographic algorithms:
-
HMAC-SHA2-512
-
PBKDF2
-
AES-128
A FIPS compliant version of LINSTOR is available for the use cases mentioned in this section. If you or your organization require FIPS compliance at this level, please contact [email protected] for details.
1.5. インストール
コンテナで LINSTOR を使用する場合は、このセクションをスキップして、以下の Containers セクションを使用してインストールしてください。 |
1.5.1. ボリュームマネージャーのインストール
LINSTOR を使用してストレージボリュームを作成するには、LVM または ZFS のいずれかのボリュームマネージャーをシステムにインストールする必要があります。
1.5.2. LINBIT クラスターノードを管理するスクリプトの使用
LINBIT のお客様は、LINBIT で作成されたヘルパースクリプトをダウンロードし、ノードで実行して次のことができます。
-
クラスターノードをLINBITに登録する。
-
ノードを既存の LINBIT クラスターに参加させる。
-
ノードで LINBIT パッケージ リポジトリを有効にする。
LINBIT パッケージリポジトリを有効にすると、LINBT ソフトウェアパッケージ、DRBD カーネルモジュール、およびクラスターマネージャーや OCF スクリプトなどのその他の関連ソフトウェアにアクセスできるようになります。その後、パッケージマネージャーを使用して、インストール済みパッケージの取得、インストール、および更新の管理を行うことができます。
LINBIT Manage Nodes スクリプトのダウンロード
クラスターノードを LINBIT に登録し、LINBIT のリポジトリを構成するには、最初にノードの管理ヘルパー スクリプトをダウンロードしてから、すべてのクラスターノードで次のコマンドを入力して実行します。
# curl -O https://my.linbit.com/linbit-manage-node.py # chmod +x ./linbit-manage-node.py # ./linbit-manage-node.py
root ユーザーとしてスクリプトを実行する必要があります。
|
このスクリプトは、https://my.linbit.com/[LINBIT カスタマーポータル] のユーザー名とパスワードの入力を求めます。資格情報を入力すると、スクリプトはアカウントに関連付けられたクラスターノードを一覧表示します (最初は何もありません)。
LINBIT パッケージ リポジトリの有効化
ノードを登録するクラスターを指定した後、プロンプトが表示されたら、スクリプトで登録データを JSON
ファイルに書き込みます。次に、スクリプトは、有効または無効にできる LINBIT リポジトリのリストを表示します。 LINSTOR
およびその他の関連パッケージは、drbd-9
リポジトリにあります。別の DRBD
バージョンブランチを使用する必要がない限り、少なくともこのリポジトリを有効にする必要があります。
ノード管理スクリプト内の最終タスク
リポジトリの選択が完了したら、スクリプトのプロンプトに従って構成をファイルに書き込むことができます。次に、LINBIT の公開署名鍵をノードのキーリングにインストールすることに関する質問には必ず yes と答えてください。
終了する前に、スクリプトは、さまざまなユースケースにインストールできるパッケージ案に関するメッセージを表示します。
DEB ベースのシステムでは、コンパイル済みの DRBD カーネルモジュールパッケージ、 drbd-module-$(uname -r)
、またはカーネルモジュールのソース バージョン、 drbd-dkms
をインストールできます。どちらか一方のパッケージをインストールしますが、両方はインストールしないでください。
|
1.5.3. パッケージマネージャーを使用して LINSTOR をインストール
ノードを登録し drbd-9
LINBIT パッケージリポジトリを有効にすると、DEB、RPM、または YaST2
ベースのパッケージマネージャーを使用して LINSTOR と関連コンポーネントをインストールできます。
DEB ベースのパッケージマネージャーを使用している場合は、続行する前に apt update と入力してパッケージリポジトリリストを更新します。
|
LINSTOR ストレージ用の DRBD パッケージのインストール
DRBD なし で LINSTOR を使用する場合は、これらのパッケージのインストールをスキップできます。 |
LINSTOR を使用して DRBD 複製ストレージを作成できるようにする場合は、必要な DRBD パッケージをインストールする必要があります。ノードで実行している Linux ディストリビューションに応じて、ヘルパースクリプトが提案する DRBD 関連のパッケージをインストールします。スクリプトの推奨パッケージとインストールコマンドを確認する必要がある場合は、次のように入力できます。
# ./linbit-manage-node.py --hints
1.5.4. ソースコードから LINSTOR をインストール
LINSTOR プロジェクトの GitHub ページは https://github.com/LINBIT/linstor-server です。
LINBIT には、LINSTOR、DRBD などのソースコードのダウンロード可能なアーカイブファイルもあります。 https://linbit.com/linbit-software-download-page-for-linstor-and-drbd-linux-driver/ から利用可能です。
1.6. LINSTOR のアップグレード
LINSTORはローリングアップグレードをサポートしておらず、コントローラとサテライトは同じバージョンでなければなりません。そうでない場合、コントローラはサテライトを
VERSION_MISMATCH
と認識して接続ができません。しかしこの場合はデータの同期には問題はありません。サテライトがコントローラに接続しなければ何もアクションを起こさず、DRBDの動作が中断することもありません。
組み込みのデフォルトH2データベースを使用していて、linstor-controllerパッケージがアップグレードされている場合は、デ
ータベースの自動バックアップファイルがデフォルトの /var/lib/linstor
ディレクトリに作成されます。このファイルは、何らかの理由でlinstor-controllerデータベースの移行が失敗した場合の適切な復元ポイントです。エラーをLINBITに
報告し、古いデータベースファイルを使って、以前のコントローラバージョンにダウングレードすることをお勧めします。
外部データベースまたはetcdを使用する場合は、現在のデータベースを手動でバックアップして復元ポイントを作成することをお勧めします。
First, upgrade the linstor-controller
and linstor-client
packages on
your controller host and then restart the linstor-controller
. The
controller should start and all of its clients should show
OFFLINE(VERSION_MISMATCH)
. After that you can continue upgrading the
linstor-satellite
package on all satellite nodes and restart them, after a
short reconnection time they should all show ONLINE
again and your upgrade
is finished.
1.7. コンテナ
LINSTORはコンテナとしても利用可能です。ベースイメージはLINBITのコンテナレジストリ drbd.io
にあります。
LINBIT のコンテナー イメージ リポジトリ (http://drbd.io) は、LINBIT のお客様、または LINBIT のお客様の試用アカウントを通じてのみ利用できます。価格についての情報や試用開始するには こちら を参照ください。また、LINSTOR SDS のアップストリームプロジェクト Piraeus は LINBIT の顧客ではなくてもを使用できます。 |
画像にアクセスするには、まずLINBITカスタマーポータルの認証情報を使ってレジストリにログインする必要があります。
# docker login drbd.io
このリポジトリで利用可能なコンテナは以下です。
-
drbd.io/drbd9-rhel8
-
drbd.io/drbd9-rhel7
-
drbd.io/drbd9-sles15sp1
-
drbd.io/drbd9-bionic
-
drbd.io/drbd9-focal
-
drbd.io/linstor-csi
-
drbd.io/linstor-controller
-
drbd.io/linstor-satellite
-
drbd.io/linstor-client
ブラウザで http://drbd.io にアクセスすると、バージョン番号付きの利用可能なイメージの最新のリストを取得できます。レジストリのイメージ自体は “https” で提供されてますが、 “http” でホストにアクセスしてください。
LINSTOR サテライトにのみ必要なカーネルモジュールをロードするには、特権モードで drbd9-$dist
コンテナを実行する必要があります。カーネルモジュールのコンテナは、モジュールをカスタマーリポジトリの LINBIT
公式パッケージから取得するか、出荷済みパッケージを使用するか、コンテナ内でソースからビルドします。ソースからビルドする場合、カーネルのヘッダ(kernel-devel
)をホストにインストールする必要があります。カーネルモジュールのコンテナを実行する方法は4つあります。
-
出荷済みソースからビルドする。
-
出荷済み/ビルド済みのカーネルモジュールの使用する。
-
LINBITノードのハッシュとディストリビューションを指定する。
-
既存のリポジトリ設定をバインドマウントする。
ソースからビルドする場合(RHEL ベース):
# docker run -it --rm --privileged -v /lib/modules:/lib/modules \ -v /usr/src:/usr/src:ro \ drbd.io/drbd9-rhel7
コンテナに同梱されているモジュールを使用した例、 /usr/src
は バインドマウントしません :
# docker run -it --rm --privileged -v /lib/modules:/lib/modules \ drbd.io/drbd9-rhel8
ハッシュとディストリビューションを指定する場合: (あまり使わない):
# docker run -it --rm --privileged -v /lib/modules:/lib/modules \ -e LB_DIST=rhel7.7 -e LB_HASH=ThisIsMyNodeHash \ drbd.io/drbd9-rhel7
既存のリポジトリ設定を使う場合 (あまり使わない):
# docker run -it --rm --privileged -v /lib/modules:/lib/modules \ -v /etc/yum.repos.d/linbit.repo:/etc/yum.repos.d/linbit.repo:ro \ drbd.io/drbd9-rhel7
どちらの場合でも(ハッシュ+ディストリビューションまたは既存のリポジトリ設定をバインドマウント)、これらが設定されたノードから使用する必要があります。これらの設定に関してはサポートにお問い合わせください。 |
今のところ(DRBD9 バージョン 9.0.17 より前では)、ホストシステムにカーネルモジュールをロードするのではなく、コンテナ化された DRBD
カーネルモジュールを使用する必要があります。コンテナを使用する場合は、DRBD
カーネルモジュールをホストシステムにインストールしないでください。バージョン 9.0.17
リリース以降はホストシステムにいつも通りカーネルモジュールをインストールできますが、 usermode_helper = disabled
パラメータ(例えば modprobe drbd usermode_helper=disabled )を使ってモジュールをロードする必要があります。
|
次に、デーモンとして特権モードで LINSTOR サテライトコンテナを実行します。
# docker run -d --name=linstor-satellite --net=host -v /dev:/dev \ --privileged drbd.io/linstor-satellite
コンテナ化された drbd-utils がネットワークを通してホストカーネルと通信できるようにするには net=host が必要です。
|
LINSTOR コントローラコンテナをデーモンとして実行するには、ホスト上のポート 3370
, 3376
, 3377
をコンテナにマッピングします。
# docker run -d --name=linstor-controller -p 3370:3370 drbd.io/linstor-controller
コンテナ化された LINSTOR クラスタと対話するには、パッケージを介してシステムにインストールされた LINSTOR クライアント、またはコンテナ化された LINSTOR クライアントを使用することができます。 LINSTOR クライアントコンテナを使用するには
# docker run -it --rm -e LS_CONTROLLERS=<controller-host-IP-address> \ drbd.io/linstor-client node list
これ以降は、LINSTOR クライアントを使用してクラスタを初期化し、一般的な LINSTOR パターンを使用してリソースの作成を開始します。
デーモン化されたコンテナとイメージを停止して削除します。
# docker stop linstor-controller # docker rm linstor-controller
1.8. クラスタの初期化
以下の手順がすべてのクラスタノードですでに実行されていると仮定します。
-
DRBD9カーネルモジュールがインストールされ、ロードされている。
-
drbd-utils` がインストールされている。
-
LVM` ツールがインストールされている。
-
linstor-controller
,linstor-satellite
とその依存パッケージがインストールされている。 -
linstor-client
はlinstor-controller
ノードにインストールされている。
コントローラがインストールされているホストで linstor-controller サービスを起動して有効にします。
# systemctl enable --now linstor-controller
1.9. LINSTORクライアントの使用
LINSTORコマンドラインクライアントを実行するときは、常にlinstor-controllerがどこで実行されているか知る必要があります。何も指定してないときは、IP
127.0.0.1
port 3376
のローカルのlinstor-controllerを探しにいきます。そのため
linstor-controller
と同じホスト上で linstor-client
を使います。
linstor-satellite はポート3366と3367を必要とします。 linstor-controller
はポート3376と3377を必要とします。ファイアウォールでこれらのポートが許可されていることを確認してください。
|
# linstor node list
Output from this command should show you an empty list and not an error message.
linstor
コマンドはどのマシンでも実行できます。ただし、クライアントにどのようにlinstor-controllerを探すか指定する必要があります。これはコマンドラインのオプションか、環境変数、またはグローバルファイルで指定できます。
# linstor --controllers=alice node list # LS_CONTROLLERS=alice linstor node list
あるいは、 /etc/linstor/linstor-client.conf
ファイルを作成して、以下のように追加することもできます。
[global] controllers=alice
複数のlinstorコントローラが設定されている場合は、それらをカンマ区切りで指定します。linstor-clientはそれらをリストされた順番で試します。
linstor-clientコマンドは、パラメータの開始文字を書くだけで使える便利な方法があります。例えば: linstor node list
→ linstor n l
|
1.10. ノードをクラスタに追加する
次の手順ではノードを LINSTOR クラスタに追加します。
# linstor node create bravo 10.43.70.3
IP が省略された場合、クライアントは指定されたノード名をホスト名として自分で解決しようとします。
LINSTOR は、後で DRBD リソースに使用されるノードのローカル uname -n
を自動的に検出します。
linstor node list
を実行したとき、新しいノードはofflineとマークされています。ここで、以下のコマンドでlinstor-satelliteを起動し、有効にするとこで、再起動時も起動するようになります。
# systemctl enable --now linstor-satellite
サービスがすでにデフォルトで有効になっていて再起動時に起動する場合は、 systemctl start linstor-satellite
を使うこともできます。
10秒後に linstor node list
がonlineになるのを見るでしょう。もちろんコントローラが認識する前にlinstor-satelliteがすでに起動されているときもあります。
ノードがコントローラでかつクラスタにストレージも供給する場合は、同様にlinstor-satelliteを起動します。 |
linstor-satellite が必要なデバイスを作成する機会が得られるまで(ブート後など)他のサービスを待機させたい場合は、対応する
.service ファイルを更新し、Type=simple
を Type=notify
に変更します。
これにより、サテライトはコントローラーが接続し、必要なすべてのデータをサテライトに送信し、サテライトがデバイスの起動と実行を少なくとも1回試行するまで、systemd
への READY=1
メッセージの送信を遅らせます。
1.11. ストレージプール
StoragePools はLINSTORでストレージを識別します。複数のノードからのストレージプールをグループ化するために単純に各ノードで同じ名前を使います。例えば1つの有効な方法としてすべてのSSDに1つの名前をつけ、すべてのHDDに別の名前をつけます。
ストレージを作成するために、LVM VGまたはZFS zPoolのどちらかを作成する必要があります。LINSTORストレージプール名とともに識別されるVGsやzPools名は、各ホストで別の名前にすることも可能ですが、すべてのノードで同じにすることを推奨します。
# vgcreate vg_ssd /dev/nvme0n1 /dev/nvme1n1 [...]
次にこれらは以下のコマンドでLINSTORに登録します。
# linstor storage-pool create lvm alpha pool_ssd vg_ssd # linstor storage-pool create lvm bravo pool_ssd vg_ssd
ストレージプール名は ストレージプール定義 として参照されます。上記コマンドはストレージプール定義を暗黙的に作成します。 linstor
storage-pool-definition list
を使って確認できます。明示的にストレージプール定義を作成することも可能ですが、必須ではありません。
|
ストレージプールを表示するには、次のようにします。
# linstor storage-pool list
またはショートバージョンを使います。
# linstor sp l
まだ動作中のリソースまたはスナップショットがアタッチされていて、ストレージプールの削除ができない場合は、対応方法のヒントが関連する list コマンドの
status 項に表示されます(例: linstor resource list
)。削除されたストレージプールの LINSTOR
オブジェクトを手動で削除した後、再度 lost コマンドを実行することで、ストレージプールとその残りのオブジェクトを確実に削除することができます。
1.11.1. 障害ドメインを単一の下位デバイスに限定する
クラスタ内にホット修復機能を備えたストレージしか持たないクラスタでは、物理的な下位デバイスごとに1つのストレージプールを作成するモデルを選択するのもよいかもしれません。このモデルの利点は、障害ドメインを単一のストレージデバイスに限定することです。
1.11.2. 複数のノードでストレージプールを共有する
Exos と LVM2 の両方のストレージプロバイダーは、ストレージアレイとドライブに直接接続された複数のサーバーノードのオプションを提供します。
LVM2 では、外部ロックサービス(lvmlockd)が、vgcreate で –shared
オプションを使用して作成されたボリュームグループを管理します。 --shared-space
は、2 つ以上のノードがアクセスできる同じ LVM2
ボリュームグループを使用するように LINSTOR プールを構成するときに使用できます。以下の例は、ノード alpha および bravo
がアクセスできるプールの共有スペース ID として LVM2 ボリュームグループ UUID を使用する方法を示しています。
# linstor storage-pool create lvm --external-locking \ --shared-space O1btSy-UO1n-lOAo-4umW-ETZM-sxQD-qT4V87 \ alpha pool_ssd shared_vg_ssd # linstor storage-pool create lvm --external-locking \ --shared-space O1btSy-UO1n-lOAo-4umW-ETZM-sxQD-qT4V87 \ bravo pool_ssd shared_vg_ssd
Exos プールは、共有スペース識別子にデフォルトで Exos プールのシリアル番号を使用します。
1.11.3. ストレージプールの作成
linstor-server 1.5.2 以降および最新の linstor-client では、LINSTOR はサテライト上に LVM/ZFS プールを作成できます。 linstor-client には、次のように可能なディスクをリストしてストレージプールを作成するためのコマンドがあります。ただし、LVM/ZFS プールは LINSTOR によって管理されないので、削除コマンドはありません。そのため削除はノードで手動で実行する必要があります。
# linstor physical-storage list
これはサイズと回転方式 (SSD/磁気ディスク) でグループ化された使用可能なディスクのリストを表示します。
次のフィルターを通過するディスクのみが表示されます。
-
デバイスサイズは 1GiB より大きい
-
デバイスはルートデバイス(子はなし)例:
/dev/vda
,/dev/sda
-
The device does not have any file system or other
blkid
marker (wipefs -a
might be needed). -
デバイスは DRBD デバイスでない
create-device-pool
コマンドを使用して、ディスク上に LVM プールを作成し、LINSTOR
のストレージプールとして直接追加することもできます。
# linstor physical-storage create-device-pool --pool-name lv_my_pool \ LVMTHIN node_alpha /dev/vdc --storage-pool newpool
--storage-pool
オプションを指定した場合、LINSTOR は指定した名前で storage-pool を作成します。
その他のオプションとコマンドの使用法については、linstor-client のヘルプを参照ください。
1.12. リソースグループを使用した LINSTOR プロビジョニングされたボリュームのデプロイ
リソースグループはリソース定義の親オブジェクトであり、リソースグループで行われたすべてのプロパティ変更はそのリソース定義の子によって継承されます。リソースグループは自動配置ルールの設定も可能で、このルールに依存するリソース定義を生成できます。
言いかえると、リソースグループは、それらから作成されるリソースの特性を定義するテンプレートのようなものです。これらの擬似テンプレートへの変更は、リソースグループから作成されたすべてのリソースにさかのぼって適用されます。
リソースグループを使用して、リソースのプロビジョニング方法を定義することは、 LINSTOR によってプロビジョニングするボリュームをデプロイするための事実上標準の方法と見なされます。resource-definition と volume-definition から各 resource を作成する方法は、特別なシナリオでのみで使用してください。 |
LINSTOR で resource-groups を使用しないことにした場合でも、 resource-definitions と volume-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.14. リソース、ボリュームの作成と配備
以下の例では、500 GBのサイズをもつリソースを作成し、3つのクラスタノード間で複製されるというシナリオを紹介します。
最初に新しいリソースの定義を作成します。
# linstor resource-definition create backups
次にこのリソースをもつ新しいボリュームの定義を作成します。
# linstor volume-definition create backups 500G
volume-definition のサイズを変更したい場合は、次のようにして簡単に行うことができます。
# linstor volume-definition set-size backups 0 100G
パラメータ 0
は、リソース backups
内のボリュームの番号である。リソースは複数のボリュームを持つことができ、それらはボリューム番号で識別されるため、このパラメーターを指定する必要があります。この番号は、volume-definition
をリストすることによって見つけることができます。
volume-definition のサイズは、リソースがない場合にのみ減らすことができます。増やす場合はデプロイされたリソースに対しても可能です。 |
ここまではLINSTORのデータベースにオブジェクトが作成されただけで、ストレージノードのLVには作成されていません。この後はLINSTORに配備作業を委任するか自分でやるか選択できます。
1.14.1. リソースを手動で配置する
resource create
コマンドでリソース定義を指定したノードに明示的に割り当てることができます。
# linstor resource create alpha backups --storage-pool pool_hdd # linstor resource create bravo backups --storage-pool pool_hdd # linstor resource create charlie backups --storage-pool pool_hdd
1.14.2. DRBD リソースの自動化
` linstor resource create –auto-place` または linstor resource-definition
auto-place
コマンドを使用すると、LINSTORにノードとストレージプールを選択させて、リソースをデプロイすることができます。このセクションでは、例として
resource create --auto-place
コマンドを使用します。 しかし、どちらのコマンドを使っても、同じ結果を得ることができます。
LINSTOR の resource-group create コマンドには --auto-place
オプションがありません。なぜなら、このコマンドはリソースを配置するのではなく、後でリソースを配置(spawn)するためのテンプレートを作成するだけだからです。しかし、このセクションで説明する
--auto-place オプションに付随する引数を resource-group create
コマンドで使用することができます。このように使用すると、リソースグループからリソースを生成するときに、LINSTORは resource create
--auto-place コマンドを使用した場合と同じようにリソースを配置します。
|
もし、クラスタ内のノード(またはストレージプール)が --auto-place
コマンドの引数の制約を満たすことができない場合、LINSTORはエラーメッセージとともにコマンドを拒否します。
|
以下の例では、--auto-place
オプションの後の値が、LINSTORにいくつのレプリカを持たせたいかを伝えています。storage-poolオプションは明らかでしょう。
# linstor resource create backups --auto-place 3 --storage-pool pool_hdd
ストレージプール名がはっきりしない場合、--storage-pool
を省略できます。この場合、LINSTORが以下のルールに基づいてストレージプールを選択します。
-
現在のユーザがアクセスできないすべてのノードとストレージプールは無視する。
-
すべてのディスクレスストレージプールは無視する
-
十分な空き領域がないストレージプールは無視する
残りのストレージプールは、さまざまな方針によって評価されます。 LINSTORには現在4つの方針があります。
MaxFreeSpace
: この方針は、ストレージプールの残りの空き領域に 1:1
のレートでマップしますが、実際に割り当てられたスペースのみを考慮します(シンプロビジョニングされたストレージプールの場合、新しいリソースを作成しなくても時間とともに増加する可能性があります)。
MinReservedSpace
: “MaxFreeSpace”
と異なり、この方針では、予約済みのスペースが考慮されます。これは、シンボリュームが限界に達する前の拡張できるスペースです。予約済みスペースの合計がオーバープロビジョニングになって、ストレージプールの容量を超える可能性があります。
MinRscCount
: 指定されたストレージプールで、単純にすでにデプロイされているリソース数をカウントします。
MaxThroughput
: この方針では、ストレージプールの Autoplacer/MaxThroughput
プロパティがスコアのベースになります(プロパティが存在しない場合は 0
)。特定のストレージプールにデプロイされたすべてのボリュームは、ストレージプールの最大スループットから定義された
sys/fs/blkio_throttle_read
および sys/fs/blkio_throttle_write
の値が差し引かれます。結果のスコアはマイナスになる可能性があります。
各方針のスコアは正規化され、重み付けされ、合計されます。この場合、最小化方針のスコアが最初に変換され、結果として得られるスコアの全体的な最大化が可能になります。
方針の重みは、以下のコマンドで設定することができます。
linstor controller set-property Autoplacer/Weights/$name_of_the_strategy $weight
ストラテジー名は上記のとおりで、ウェイトは任意の10進数でよい。
Autoplacerの動作を以前のLINSTORバージョンと互換性を保つために、重みが 1 の MaxFreeSpace
を除いて、すべてのストラテジーのデフォルトの重みは0です。
|
0点でもマイナス点でも、ストレージプールが選択されるのを妨げることはありません。これらのスコアを持つストレージプールは、後で検討されるだけです。 |
最後に、LINSTORはすべての要件を満たすストレージプールのベストマッチングを見つけようとします。このステップでは、
--replicas-on-same
, --replicas-on-different
, --do-not-place-with
,
--do-not-place-with-regex
, --layer-list
, --providers
などの自動配置に関する制限も考慮されます。
リソースを自動的に配置するときのリソースの併置の回避
do—not-place-with <resource_name_to_avoid>` 引数は、指定した
resource_name_to_avoid
リソースがすでに配置されているノードに、LINSTOR
がリソースを配置するのを避けるよう試みることを指定するものである。
引数 --do-not-place-with-regex <regular_expression>
を使用すると、引数で指定した正規表現にマッチする名前のリソースが既に配置されているノードには、LINSTORはリソースを配置しないようにすることを指定することができます。この方法で、リソースの配置を避けようとする複数のリソースを指定することができます。
補助ノードプロパティを用いたリソース自動配置の制約付け
リソースの自動配置は、指定した補助ノードプロパティを持つノードにリソースを配置する(または配置しない)ように制約することができます。
この機能は、LINSTORマネージドストレージを使用するKubernetes環境内でリソースの配置を制限しようとしている場合に、特に有用となります。例えば、Kubernetesのラベルに対応する補助ノードのプロパティを設定することができます。このユースケースの詳細については、「LINSTOR Volumes in Kubernetes」LINSTOR User’s Guide の章にある “replicasOnSame” sectionをご覧ください。 |
引数の --replicas-on-same
と --replicas-on-different
は、 Aux/
名前空間内のプロパティの名前を指定します。
次の例では、3つのLINSTORサテライトノードに、補助ノードプロパティ testProperty
を設定します。次に、リソースグループ
testRscGrp
を作成し、プレースカウントを2、スポーンしたリソースを testProperty
値が 1
であるノードに配置するという制約を設定します。ボリュームグループの作成後、リソースグループからリソースを作成することができます。簡単のために、以下のコマンドの出力は表示されません。
# for i in {0,2}; do linstor node set-property --aux node-$i testProperty 1; done # linstor node set-property --aux node-1 testProperty 0 # linstor resource-group create testRscGrp --place-count 2 --replicas-on-same testProperty=1 # linstor volume-group create testRscGrp # linstor resource-group spawn-resources testRscGrp testResource 100M
以下のコマンドで、生成されたリソースの配置を確認することができます。
|=====================================================================================| # linstor resource list +-------------------------------------------------------------------------------------+ | ResourceName | Node | Port | Usage | Conns | State | CreatedOn | | testResource | node-0 | 7000 | Unused | Ok | UpToDate | 2022-07-27 16:14:16 | | testResource | node-2 | 7000 | Unused | Ok | UpToDate | 2022-07-27 16:14:16 | +-------------------------------------------------------------------------------------+
同一人物に対する複製という制約のため、LINSTORは生成されたリソースをサテライトノード node-1
に配置しませんでした。
サテライトノード node-1
の補助ノードプロパティ testProperty
の値は 0
であり、1
ではなかったからです。
0` であり、1
ではないためです。
list-properties` コマンドを使用すると、node-1
のノードプロパティを確認することができます。
# linstor node list-properties node-1 +----------------------------+ | Key | Value | |============================| | Aux/testProperty | 0 | | CurStltConnName | default | | NodeUname | node-1 | +----------------------------+
オートプレイスによる既存のリソース配置の拡張
auto-place
の値には、リソースのレプリカを配置する数を正の整数で指定する他に、既存のリソースのデプロイメントを拡張したい場合には、+1
という値も指定できます。この値を使用すると、リソースが作成されたリソースグループの --place-count
がどのように設定されていても、LINSTOR は追加のレプリカを作成します。
例えば、先ほどの例で使用した testResource
リソースのレプリカを追加でデプロイするには、 +1
という自動配置の値を使用します。まず、node-1
で補助ノードプロパティ testProperty
を 1
に設定する必要があります。そうしないと、以前に設定した --replicas-on-same
という制約により、LINSTOR
はレプリカをデプロイすることができません。簡単のために、以下のコマンドのすべての出力は表示されません。
# linstor node set-property --aux node-1 testProperty 1 # linstor resource create --auto-place +1 testResource # linstor resource list +----+ | ResourceName | Node | Port | Usage | Conns | State | CreatedOn | |=====================================================================================| | testResource | node-0 | 7000 | Unused | Ok | UpToDate | 2022-07-27 16:14:16 | | testResource | node-1 | 7000 | Unused | Ok | UpToDate | 2022-07-28 19:27:30 | | testResource | node-2 | 7000 | Unused | Ok | UpToDate | 2022-07-27 16:14:16 | +-------------------------------------------------------------------------------------+
警告: +1
という値は resource-group create --place-count
コマンドでは有効ではありません。
これは、このコマンドはリソースをデプロイせず、後でデプロイするためのテンプレートを作成する
だけだからです。
LINSTORレイヤーまたはストレージプールプロバイダによるリソースの自動配置の制約
引数 --layer-list
または --providers
の後に、LINSTOR
のレイヤーまたはストレージプールプロバイダのカンマ区切りリスト (CSV) を指定すると、LINSTOR
があなたのリソースを配置する場所に影響を与えることができます。CSVリストで指定できるレイヤーやストレージプールプロバイダーは、 --help
オプションと --auto-place
オプションを使用することで表示することができます。レイヤーの CSV
リストは、指定したリソースの自動配置を、リストに適合するストレージを持つノードに制限します。例えば、my_luks_resource
という既存のリソース定義がある場合、次のコマンドを考えてみてください。
# linstor resource create my_luks_resource --auto-place 3 --layer-list drbd,luks
このコマンドは、DRBDレイヤーをLUKSレイヤーでバックアップしたストレージプール (および暗黙のうちに「ストレージ」レイヤーでバックアップされた)を持つ、 3つのノードに展開されたリソースを作成します。CSVリストで指定するレイヤーの順序は 「トップダウン」で、リストの左側のレイヤーがその右側のレイヤーの上にあります。
引数 --providers
を使用すると、リソースの自動配置を、指定した CSV リストに一致する
ストレージプールのみに制限することができます。この引数を使用すると、デプロイされた
リソースをバックアップするストレージプールを明示的に制御することができます。
例えば、クラスタ内に ZFS
、LVM
、LVM_THIN
のストレージプールが混在している場合、
--providers LVM,LVM_THIN
引数を使用すると、 --auto-place
オプションの使用時に、リソースを LVM
または LVM_THIN
ストレージプールにのみバックアップさせるように指定することが可能です。
--providers 引数のCSVリストでは、リストの要素の優先順位を指定することはできません。
要素の優先順位を指定しません。その代わりに、LINSTORは追加の --自動配置 制約のような要素を
使用します。LINSTORはリソースを配置する際に、追加の自動配置制約、利用可能な空き領域、
LINSTORのストレージプール選択ストラテジーなど のストレージプール選択戦略などの要素を使用します。
|
1.15. リソース、リソース定義、およびリソース グループの削除
削除したい LINSTOR オブジェクトの後に delete
コマンドを使用して、LINSTOR リソース、リソース定義、およびリソース
グループを削除できます。どのオブジェクトを削除するかによって、LINSTOR クラスターおよびその他の関連する LINSTOR
オブジェクトに異なる影響があります。
1.15.1. リソース定義の削除
次のコマンドを使用してリソース定義を削除できます:
# linstor resource-definition delete <resource_definition_name>
これにより、指定されたリソース定義が LINSTOR クラスター全体から削除されます。リソースはすべてのノードから削除され、リソース エントリは LINSTOR のデータベース テーブルから削除するようにマークされます。LINSTOR がすべてのノードからリソースを削除した後、リソース エントリは LINSTOR のデータベース テーブルから削除されます。
警告: リソース定義に既存のスナップショットがある場合、そのスナップショットを削除するまでリソース定義を削除できません。詳細は Removing a Snapshot を参照ください。
1.15.2. リソースの削除
次のコマンドを使用してリソースを削除できます:
# linstor resource delete <node_name> <resource_name>
リソース定義の削除とは異なり、このコマンドは、指定したノード (複数可) から LINSTOR リソースのみを削除します。リソースはノードから削除され、リソースエントリは LINSTOR のデータベーステーブルから削除するようにマークされます。LINSTOR がノードからリソースを削除した後、リソースエントリは LINSTOR のデータベーステーブルから削除されます。
LINSTOR リソースを削除すると、リソースを削除するだけでなく、クラスターに影響を与える可能性があります。たとえば、リソースが DRBD レイヤーによってサポートされている場合、3 ノード クラスタ内の 1 つのノードからリソースを削除すると、リソースに存在するクォーラム関連の特定の DRBD オプションも削除される可能性があります。このようなリソースを 3 ノードクラスタ内のノードから削除すると、リソースは 3 ノード クラスタ内の 2 つのノードにのみデプロイされるため、クォーラムがなくなります。
「linstor resource delete」コマンドを実行して単一ノードからリソースを削除すると、次のような情報メッセージが表示される場合があります。
INFO: Resource-definition property 'DrbdOptions/Resource/quorum' was removed as there are not enough resources for quorum INFO: Resource-definition property 'DrbdOptions/Resource/on-no-quorum' was removed as there are not enough resources for quorum
また、リソース定義の削除とは異なり、リソースのストレージプールのスナップショットが存在している間にリソースを削除できます。リソースのストレージプールの既存のスナップショットは保持されます。
1.15.3. リソースグループの削除
次のコマンドを使用して、リソースグループを削除できます。
# linstor resource-group delete <resource_group_name>
このコマンドは指定されたリソースグループを削除します。リソース定義が関連付けられていない場合のみ、リソースグループを削除できます。削除しない場合、LINSTOR は次のようなエラー メッセージを表示します。
ERROR: Description: Cannot delete resource group 'my_rg' because it has existing resource definitions.
リソースグループを削除できるようにこのエラーを解決するには、関連するリソース定義を削除するか、リソース定義を別の (既存の) リソースグループに移動します。
# linstor resource-definition modify <resource_definition_name> \ --resource-group <another_resource_group_name>
次のコマンドを入力すると、リソース グループに関連付けられているリソース定義を見つけることができます。
# linstor resource-definition list
2. LINSTOR 応用タスク
2.1. 高可用性 LINSTOR クラスターの作成
デフォルトでは、LINSTOR クラスターは 1 つの LINSTOR コントローラーで構成されます。LINSTOR の高可用性を実現するには、コントローラーデータベースの複製されたストレージ、一度に 1 つだけがアクティブになる複数の LINSTOR コントローラー、および高可用性ストレージのマウント/アンマウントと LINSTOR コントローラーの開始/停止を処理するサービスマネージャーを提供する必要があります。
2.1.1. 高可用性ストレージの構成
高可用性ストレージを構成するには、LINSTOR 自体を使用します。これには、ストレージが LINSTOR の制御下にあり、たとえば新しいクラスターノードに簡単に拡張できるという利点があります。サイズが 200MB の新しいリソースを作成するだけです。これは次のようになります。ストレージプール名は環境に合わせて変更してください。
# linstor resource-definition create linstor_db # linstor resource-definition drbd-options --on-no-quorum=io-error linstor_db # linstor resource-definition drbd-options --auto-promote=no linstor_db # linstor volume-definition create linstor_db 200M # linstor resource create linstor_db -s pool1 --auto-place 3
これ以降、リソース名は “linstor_db” であると仮定します。クラスターが自動クォーラム (自動クォーラムポリシー を参照) の対象になっていて io-error
ポリシーを使用していることが重要です。また auto-promote
を無効にします。
リソースが作成されたら、LINSTOR DB を新しいストレージに移動し systemd
マウントサービスを作成します。後ほど drbd-reactor
によって管理されるため、最初に現在のコントローラーを停止して無効にします。
# systemctl disable --now linstor-controller # cat << EOF > /etc/systemd/system/var-lib-linstor.mount [Unit] Description=Filesystem for the LINSTOR controller [Mount] # you can use the minor like /dev/drbdX or the udev symlink What=/dev/drbd/by-res/linstor_db/0 Where=/var/lib/linstor EOF # mv /var/lib/linstor{,.orig} # mkdir /var/lib/linstor # chattr +i /var/lib/linstor # only if on LINSTOR >= 1.14.0 # drbdadm primary linstor_db # mkfs.ext4 /dev/drbd/by-res/linstor_db/0 # systemctl start var-lib-linstor.mount # cp -r /var/lib/linstor.orig/* /var/lib/linstor # systemctl start linstor-controller
/etc/systemd/system/var-lib-linstor.mount
マウントファイルを linstor コントローラーのすべてのスタンバイノードにコピーします。繰り返しますが、これらのサービスを systemctl enable
しないでください。これらは drbd-reactor
によって管理されます。
2.1.2. 複数のLINSTORコントローラー
次のステップは、”linstor_db” DRBD リソースにアクセスでき(DRBD ボリュームをマウントする必要があるため)、LINSTOR
コントローラーになる可能性のあるすべてのノードに LINSTOR コントローラーをインストールすることです。コントローラが drbd-reactor
によって管理されていることが重要なので、すべてのノードで linstor-controller.service
が無効になっていることを確認してください。すべてのクラスターノードで systemctl disable linstor-controller
を実行し、前の手順で現在実行しているノードを除くすべてのノードで systemctl stop linstor-controller
を実行します。また、LINSTOR バージョン 1.14.0 以上を使用している場合、すべての潜在的なコントローラーノードで chattr +i
/var/lib/linstor
を設定してください。
2.1.3. サービスの管理
マウントサービスと linstor-controller サービスの開始と停止には drbd-reactor
を使用します。LINSTOR
コントローラーになる可能性のあるすべてのノードにこのコンポーネントをインストールし、それらの
/etc/drbd-reactor.d/linstor_db.toml
構成ファイルを編集します。次のような有効な promoter
プラグインセクションが含まれている必要があります。
[[promoter]] id = "linstor_db" [promoter.resources.linstor_db] start = ["var-lib-linstor.mount", "linstor-controller.service"]
要件によっては on-stop-failure
と stop-services-on-exit
アクションを設定します。
その後 drbd-reactor
を再起動し、構成したすべてのノードで有効にします。
# systemctl restart drbd-reactor # systemctl enable drbd-reactor
systemctl status drbd-reactor` を実行して、ログに drbd-reactor
サービスからの警告がないことを確認してください。
すでにアクティブなLINSTORコントローラがあるので、そのままの状態を維持することができます。
drbd-reactorctl status linstor_db` を実行して、linstor_dbターゲットユニットの状態をチェックします。
最後のステップですが、それでも重要なのは、LINSTORサテライトサービスの
起動時にLINSTORコントローラDBのリソースファイルを削除しない(そして再生成する)
ように設定することです。サービスファイルを直接編集するのではなく、systemctl edit
を
使用してください。LINSTORコントローラになる可能性があり、LINSTORサテライトでもある全てのノードでサービスファイルを編集してください。
# systemctl edit linstor-satellite [Service] Environment=LS_KEEP_RES=linstor_db
この変更後、すべてのサテライトノードで systemctl restart linstor-satellite
を実行する必要があります。
注意: LINSTORクライアントの使用 にあるように、LINSTORクライアントを 複数のコントローラで使用できるように設定し、 統合プラグイン(例えば、Proxmoxプラグイン)も複数のLINSTORコントローラに 対応するように設定されていることを確認してください。
2.2. DRBDクライアント
--storage-pool
の代わりに --drbd-diskless
オプションを使うことで、ノード上に永続的なディスクレスのDRBDデバイスを持つことができます。これは、リソースがブロックデバイスとして表示され、既存のストレージデバイスなしでファイルシステムとしてマウントできることを意味します。リソースのデータは、同じリソースを持つ別のノード上にネットワークを介してアクセスされます。
# linstor resource create delta backups --drbd-diskless
オプション --diskless は非推奨です。代わりに --drbd-diskless を使ってください。
または --nvme-initiator を代わりに使ってください。
|
2.3. LINSTOR – DRBDコンシステンシグループ/マルチボリューム
コンシステンシグループはDRBDの機能の1つです。LINSTORの主な機能の1つがDRBDを使用してストレージクラスタを管理することです。1つのリソース内の複数のボリュームがコンシステンシグループになります。
これは、1つのリソースで異なるボリュームに対する変更が他のサテライトでも同じ順番で複製されることを意味します。
したがって、リソース内の異なるボリュームに相互依存データがある場合は、タイミングを気にする必要はありません。
LINSTORリソースに複数のボリュームを配備するには、同じ名前の volume-definitions を2つ作成する必要があります。
# linstor volume-definition create backups 500G # linstor volume-definition create backups 100G
2.4. 1つのリソースのボリュームを異なるストレージプールに配置
リソースをノードに配備する前のボリューム定義で StorPoolName
プロパティを使うことで、1つのリソースから異なるストレージプールへのボリュームを作成できます。
# linstor resource-definition create backups # linstor volume-definition create backups 500G # linstor volume-definition create backups 100G # linstor volume-definition set-property backups 0 StorPoolName pool_hdd # linstor volume-definition set-property backups 1 StorPoolName pool_ssd # linstor resource create alpha backups # linstor resource create bravo backups # linstor resource create charlie backups
volume-definition create コマンドは --vlmnr オプションなしで
使用されるので、LINSTOR は 0 から始まるボリューム番号を割り当てます。
以下の2行では、0 と 1 は自動的に割り当てられたボリューム番号を参照しています。
|
ここで、’resource create’ コマンドは --storage-pool
オプションを必要としません。
この場合、LINSTORは’fallback’ストレージプールを使用します。そのストレージプールを
見つけるために、LINSTORは以下のオブジェクトのプロパティを
以下の順序で問い合わせます。
-
Volume definition
-
Resource
-
Resource definition
-
Node
これらのオブジェクトのいずれにも StorPoolName
プロパティが含まれていない場合、
コントローラは、ハードコードされた ‘DfltStorPool’ 文字列をストレージプールとして使用します。
これはまた、リソースをデプロイする前にストレージプールを定義し忘れた場合、 LINSTORは’DfltStorPool’という名前のストレージプールを見つけられなかった というエラーメッセージを受け取ることを意味します。
2.5. DRBDを使わないLINSTOR
LINSTORはDRBDを使わずとも使用できます。 DRBDがなくても、LINSTORはLVMおよびZFS 下位ストレージプールからボリュームをプロビジョニングし、LINSTORクラスタ内の個々のノードにそれらのボリュームを作成できます。
現在LINSTORはLVMとZFSボリュームの作成をサポートしており、LUKS、DRBD、または NVMe-oF/NVMe-TCP の組み合わせをそれらのボリュームの上に重ねることもできます。
たとえば、Thin LVM 下位ストレージプールがクラスタ内で thin-lvm
という名前で定義されているとします。
# linstor --no-utf8 storage-pool list +--------------------------------------------------------------+ | StoragePool | Node | Driver | PoolName | ... | |--------------------------------------------------------------| | thin-lvm | linstor-a | LVM_THIN | drbdpool/thinpool | ... | | thin-lvm | linstor-b | LVM_THIN | drbdpool/thinpool | ... | | thin-lvm | linstor-c | LVM_THIN | drbdpool/thinpool | ... | | thin-lvm | linstor-d | LVM_THIN | drbdpool/thinpool | ... | +--------------------------------------------------------------+
以下のコマンドで LINSTOR を使用してサイズが100Gバイトの Thin LVM を
linstor-d
上に作成できます。
# linstor resource-definition create rsc-1 # linstor volume-definition create rsc-1 100GiB # linstor resource create --layer-list storage \ --storage-pool thin-lvm linstor-d rsc-1
以下で linstor-d
に新しい Thin LVM ボリュームを確認できます。
linstorのリソースを --machine-reader
フラグを付けてリストすることで
LINSTORからデバイスパスを抽出することができます。
# linstor --machine-readable resource list | grep device_path "device_path": "/dev/drbdpool/rsc-1_00000",
ZFSまたはLVM下位ボリューム用のデフォルトの --layer-list
オプションで
ある DRBD をこのボリューム上に階層化したい場合は、代わりに以下の
リソース作成パターンを使用します。
# linstor resource-definition create rsc-1 # linstor volume-definition create rsc-1 100GiB # linstor resource create --layer-list drbd,storage \ --storage-pool thin-lvm linstor-d rsc-1
linstor-d
に Thin LVM を下位デバイスとするDRBDボリュームがあることが
わかります。
# linstor --machine-readable resource list | grep -e device_path -e backing_disk "device_path": "/dev/drbd1000", "backing_disk": "/dev/drbdpool/rsc-1_00000",
次の表は、どのレイヤーの後にどの子レイヤーが続くかを示しています。
[cols=”>1,<5″] |
Layer |
Child layer |
DRBD |
CACHE, WRITECACHE, NVME, LUKS, STORAGE |
CACHE |
WRITECACHE, NVME, LUKS, STORAGE |
WRITECACHE |
CACHE, NVME, LUKS, STORAGE |
NVME |
CACHE, WRITECACHE, LUKS, STORAGE |
LUKS |
STORAGE |
STORAGE |
– |
1つのレイヤーは、layer-list で1回しか使用できません。 |
luks レイヤの必要条件についての情報はこのユーザガイドの暗号化ボリュームの節を参照ください。
|
2.5.1. NVMe-oF/NVMe-TCP LINSTOR レイヤ
NVMe-oF/NVMe-TCP により、LINSTOR はデータが NVMe ファブリックを介して格納されているリソースを持つノードにディスクレスリソースとして接続することができます。これにより、ネットワークを介してデータにアクセスすることで、ローカルストレージを使用せずにリソースをマウントできるという利点が得られます。この場合、LINSTORはDRBDを使用していないため、LINSTORによってプロビジョニングされたNVMeリソースは複製されず、データは1つのノードに格納されます。
NVMe-oF はRDMA対応ネットワークでのみ動作し、NVMe-TCP はIPトラフィックを伝送できるすべてのネットワークで動作します。 NVMe-oF/NVMe-TCP の詳細については、https://www.linbit.com/en/nvme-linstor-swordfish/ を参照ください。 |
LINSTORで NVMe-oF/NVMe-TCP を使用するには、サテライトとして機能し、リソースとして NVMe-oF/NVMe-TCP
を使用するすべてのノードで nvme-cli
パッケージをインストールする必要があります。
Ubuntu を使用していない場合は、OS にパッケージをインストールするための適切なコマンドを使用してください – SLES: zypper ;
RHEL-family: dnf
|
# apt install nvme-cli
NVMe-oF/NVMe-TCP を使用するリソースを作成するには、resource-definition を作成するときに追加のパラメータを指定する必要があります。
# linstor resource-definition create nvmedata -l nvme,storage
DRBDが使用されている場合、デフォルトでは -l(layer-stack) パラメータは drbd,storage に設定されています。
NVMeもDRBDも使用せずにLINSTORリソースを作成したい場合は、 -l パラメータを storage だけに設定する必要があります。
|
デフォルトの NVMe-oF の代わりに NVMe-TCP を使用するには、次のプロパティを設定する必要があります。
# linstor resource-definition set-property nvmedata NVMe/TRType tcp
プロパティ NVMe/TRType
は、リソースグループまたはコントローラーレベルで設定することもできます。
次に、リソース用の volume-definition を作成します。
# linstor volume-definition create nvmedata 500G
ノード上にリソースを作成する前に、データがローカルに格納される場所と、どのノードがネットワーク経由でそれにアクセスするかを確認します。
まず、データを保存するノードにリソースを作成します。
# linstor resource create alpha nvmedata --storage-pool pool_ssd
ネットワーク上でリソースデータにアクセスするノードでは、リソースをディスクレスとして定義する必要があります。
# linstor resource create beta nvmedata --nvme-initiator
これでリソース nvmedata
をノードの1つにマウントできます。
ノードに複数のNICがある場合は、NVMe-of/NVME-TCP に対してそれらの間の経路を強制する必要があります。そうしないと、複数のNICで問題が発生する可能性があります。 |
2.5.2. OpenFlex™ Layer
バージョン1.5.0 以降、LINSTOR で追加のレイヤー openflex
を使用できます。LINSTOR の観点から見ると、
OpenFlex
Composable Infrastructure は、LVM
のようなストレージレイヤーとして機能する結合レイヤーの役割を果たします。また、割り当てられたスペースを NVMe
ターゲットとして提供します。OpenFlex には REST API があり、LINSTOR で操作できます。
OpenFlex は LINSTOR ストレージと NVMeレイヤー の概念を組み合わせているため、LINSTOR
は、ストレージプール用の新しいストレージドライバーと、前述の REST API を使用する専用の openflex
レイヤーの両方に追加されました。
LINSTOR が OpenFlex-API と通信するためには、LINSTOR はいくつかの追加のプロパティを必要とします。これらのプロパティを
controller
レベルで一度設定することで、LINSTOR クラスター全体に反映できます。
-
StorDriver/Openflex/ApiHost
: API エントリポイントのホストまたは IP を指定する -
StorDriver/Openflex/ApiPort
: REST 呼び出しで使用される基本的なhttp://ip:port
の port の部分を指定する -
StorDriver/Openflex/UserPassword
: REST ユーザのパスワードを指定する
これらが設定されたら、OpenFlex アーキテクチャの LINSTOR オブジェクトを作成できます。LINSTOR オブジェクトの OpenFlex オブジェクトへの理論的なマッピングは次のとおりです。OpenFlex ストレージプールは LINSTOR ストレージプールで表されます。LINSTOR ストレージプールの上の次のものはすでにノードであるため、LINSTOR ノードは OpenFlex ストレージデバイスを表します。ストレージデバイスの上の OpenFlex オブジェクトは LINSTOR によってマップされません。
NVMe を使用する場合、LINSTOR は NVMe ターゲットと NVMe イニシエーター側の両方で実行するように設計されています。 OpenFlex の場合、LINSTOR は OpenFlex によって完全に管理されるため、NVMeターゲット側で実行しません(実行する必要はありません)。LINSTOR は OpenFlex 対応物を表すためのノードとストレージプールを必要とするため、1.0.14 以降、特別なノードを作成するコマンドが LINSTOR クライアントに拡張されました。このコマンドは、追加で必要な構成データを受け入れるだけでなく、すでに実行中のコントローラインスタンスの他に “特別なサテライト” も起動します。この特別なサテライトは完全に LINSTOR で管理され、コントローラがシャットダウンするとシャットダウンされ、コントローラが起動すると再び起動されます。
OpenFlexストレージデバイスを表す “特別なサテライト” を作成するための新しいクライアントコマンドは次のとおりです。
$ linstor node create-openflex-target ofNode1 192.168.166.7 000af795789d
引数は次のとおりです。
-
ofNode1
は標準のlinstor node create
コマンドでも使用されるノード名です。 -
192.168.166.7
は提供された NVMe デバイスにアクセスされるアドレスです。NVMe デバイスは専用のネットワークインターフェースによってアクセスされるため、このアドレスは、StorDriver/Openflex/ApiHost
プロパティで指定されたアドレスとは異なります。後者は管理 / REST API に使用されます。 -
000af795789d
はOpenFlexストレージデバイスの識別子です。
構成の最後のステップは、LINSTOR ストレージプールの作成です。
$ linstor storage-pool create openflex ofNode1 sp0 0
-
ofNode1
とsp0
は、LINSTORs create storage pool コマンドの場合と同様に、それぞれノード名とストレージプール名です。 -
最後の
0
は以前に定義されたストレージデバイス内の OpenFlex ストレージプールの識別子です。
LINSTOR で必要なストレージプールをすべて作成したら、次の手順は、LINSTOR で NVMe リソースを使用する場合と同様です。以下は完全な例です。
# set the properties once linstor controller set-property StorDriver/Openflex/ApiHost 10.43.7.185 linstor controller set-property StorDriver/Openflex/ApiPort 80 linstor controller set-property StorDriver/Openflex/UserName myusername linstor controller set-property StorDriver/Openflex/UserPassword mypassword # create a node for openflex storage device "000af795789d" linstor node create-openflex-target ofNode1 192.168.166.7 000af795789d # create a usual linstor satellite. later used as nvme initiator linstor node create bravo # create a storage pool for openflex storage pool "0" within storage device "000af795789d" linstor storage-pool create openflex ofNode1 sp0 0 # create resource- and volume-definition linstor resource-definition create backupRsc linstor volume-definition create backupRsc 10G # create openflex-based nvme target linstor resource create ofNode1 backupRsc --storage-pool sp0 --layer-list openflex # create openflex-based nvme initiator linstor resource create bravo backupRsc --nvme-initiator --layer-list openflex
ノードが linstor controller set-property StorDriver/Openflex/ApiHost
10.43.7.185 で指定されたものとは異なるホストの OpenFlex REST API にアクセスする場合、プロパティに対して常に
LINSTOR の継承メカニズムを使用できます。つまり、必要なノードレベルで同じプロパティ linstor node set-property
ofNode1 StorDriver/Openflex/ApiHost 10.43.8.185 を定義するだけです。
|
2.5.3. 書き込みキャッシュレイヤー
DM-Writecache デバイスは、ストレージデバイスとキャッシュデバイスの2つのデバイスで構成されます。 LINSTORはそのような書き込みキャッシュデバイスをセットアップできますが、ストレージプールやキャッシュデバイスのサイズなどの追加情報が必要です。
# linstor storage-pool create lvm node1 lvmpool drbdpool # linstor storage-pool create lvm node1 pmempool pmempool # linstor resource-definition create r1 # linstor volume-definition create r1 100G # linstor volume-definition set-property r1 0 Writecache/PoolName pmempool # linstor volume-definition set-property r1 0 Writecache/Size 1% # linstor resource create node1 r1 --storage-pool lvmpool --layer-list WRITECACHE,STORAGE
例で設定されている2つのプロパティは必須ですが、コントローラレベルで設定することもできます。これは、 --layer-list
に
WRITECACHE
が含まれるすべてのリソースのデフォルトとして機能します。ただし、 Writecache/PoolName
は対応するノードに依存することに注意してください。ノードに pmempool
という名前のストレージプールがない場合は、エラーメッセージが表示されます。
DM-Writecache
に必要な4つの必須
パラメーターは、プロパティを介して設定されるか、LINSTORによって計算されます。上記のリンクにリストされているオプションのプロパティは、プロパティを介して設定することもできます。
Writecache/*
プロパティキーのリストについては、 linstor controller set-property --help
を参照ください。
外部メタデータを使用するようにDRBDを設定しているときに --layer-list DRBD、WRITECACHE、STORAGE
を使用すると、外部メタデータを保持するデバイスではなく、下位デバイスのみが書き込みキャッシュを使用します。
2.5.4. キャッシュレイヤー
LINSTOR は
DM-Cache
デバイスをセットアップすることもできます。これは前のセクションの DM-Writecache によく似ています。主な違いは、キャッシュデバイスが 3
つのデバイスで構成されていることです。1 つのストレージデバイス、1 つのキャッシュデバイス、1 つのメタデバイスです。LINSTOR
プロパティは書き込みキャッシュのプロパティと非常に似ていますが、Cache
名前空間にあります。
# linstor storage-pool create lvm node1 lvmpool drbdpool # linstor storage-pool create lvm node1 pmempool pmempool # linstor resource-definition create r1 # linstor volume-definition create r1 100G # linstor volume-definition set-property r1 0 Cache/CachePool pmempool # linstor volume-definition set-property r1 0 Cache/Cachesize 1% # linstor resource create node1 r1 --storage-pool lvmpool --layer-list CACHE,STORAGE
Writecache レイヤーを構成する Writecache/PoolName と異なり、Cache レイヤーの唯一の必須プロパティは
Cache/CachePool です。これは、Cache レイヤーの Cache/MetaPool は個別に設定するか、またはデフォルトで
Cache/CachePool の値を設定するからです。
|
Cache/*
プロパティと省略されたプロパティのデフォルト値のリストについては linstor controller set-property
--help
を参照ください。
外部メタデータを使用するようにDRBDを設定しているときに --layer-list DRBD,CACHE,STORAGE
を使用すると、外部メタデータを保持するデバイスではなく、下位デバイスのみがキャッシュを使用します。
2.5.5. ストレージレイヤー
ストレージレイヤーは、LVM、ZFS などのよく知られたボリュームマネージャーからの新しいデバイスを提供します。リソースがディスクレスである必要がある場合(そのタイプは専用の「ディスクレス」プロバイダータイプ)でも、すべてのレイヤーの組み合わせはストレージレイヤーに基づく必要があります。
プロバイダーのプロパティについては Storage Providers を参照ください。
一部のストレージプロバイダー用に、LINSTOR には特別なプロパティがあります。
-
StorDriver/WaitTimeoutAfterCreate
: LINSTOR が作成後にデバイスが表示されることを期待している場合(たとえばlvcreate
,zfs create
,… の呼び出し後)、LINSTOR はデフォルトで 500ms ごとにデバイスが表示されるのを待ちます。これらの 500ms は、このプロパティによってオーバーライドできます。 -
StorDriver/dm_stats
:true
に設定すると、LINSTOR は作成後にdmstats create $device
を呼び出し、ボリュームの削除後にdmstats delete $device --allregions
を呼び出します。現在、LVM および LVM_THIN ストレージプロバイダーに対してのみ有効になっています。
2.6. ストレージプロバイダー
LINSTOR にはいくつかのストレージプロバイダーがあります。最も使用されているのは LVM と ZFS です。しかし、これら 2 つのプロバイダーについても、シンプロビジョニングされた異なるサブタイプがすでに存在します。
-
Diskless: このプロバイダータイプには、Managing Network Interface Cards で説明されているように
PrefNic
などの LINSTOR プロパティで構成できるストレージプールがほとんどの場合必要です。 -
LVM / LVM-Thin: 管理者は、対応するストレージタイプを使用するために、LVM ボリュームグループまたはシンプール(”LV/thinpool” の形式)を指定する必要があります。これらのドライバーは、チューニング用に次のプロパティをサポートします。
-
StorDriver/LvcreateOptions
: このプロパティの値は、LINSTOR が実行するすべてのlvcreate …
呼び出しの LINSTOR 実行に追加されます。
-
-
ZFS / ZFS-Thin: 管理者は、LINSTOR が使用する ZPool を指定する必要があります。これらのドライバーは、チューニング用に次のプロパティをサポートします。 これらのドライバーは、調整のために次のプロパティをサポートします。
-
StorDriver/ZfscreateOptions
: このプロパティの値は、LINSTOR が実行するすべてのzfs create …
呼び出しの LINSTOR 実行に追加されます。
-
-
File / FileThin: 主にデモンストレーション/実験に使用されます。LINSTOR は基本的に、指定されたディレクトリにファイルをリザーブし、そのファイルの上に ループデバイス を構成します。
-
OpenFlex: この特別なストレージプロバイダーは現在、特別なサテライトで実行する必要があります。詳細は OpenFlex™ Layer を参照ください。
-
EXOS: この特別なストレージプロバイダーは現在、特別なサテライトで実行する必要があります。詳細は EXOS Integration を参照ください。
-
SPDK: 管理者は、LINSTOR が使用する論理ボリュームストアを指定する必要があります。このストレージプロバイダーの使用法は NVME Layer 使用を意味します。
-
Remote-SPDK: この特別なストレージプロバイダーは現在、特別なサテライトで実行する必要があります。詳細は Remote SPDK Provider を参照ください。
-
2.6.1. リモート SPDK プロバイダー
リモート SPDK のストレージプールは、特別なサテライトでのみ作成できます。最初に次のコマンドを使用して新しいサテライトを開始する必要があります。
$ linstor node create-remote-spdk-target nodeName 192.168.1.110
これにより、コントローラーと同じマシンで実行されている新しいサテライトインスタンスが開始されます。この特別なサテライトは、リモート SPDK プロキシに対してすべての REST ベースの RPC 通信を実行します。LINSTOR コマンドのヘルプメッセージが示すように、管理者はこの特別なサテライトを作成するときに設定を追加したい場合があります。
$ linstor node create-remote-spdk-target -h usage: linstor node create-remote-spdk-target [-h] [--api-port API_PORT] [--api-user API_USER] [--api-user-env API_USER_ENV] [--api-pw [API_PW]] [--api-pw-env API_PW_ENV] node_name api_host
--api-*
とそれに対応する --api-\*-env
バージョンの違いは、 -env
で終わるバージョンは、値を含む環境変数を検索することです。一方、 --api-\*
バージョンは、LINSTOR
プロパティに格納されている値を直接取得します。管理者は --api-pw
をプレーンテキストで保存したくない場合があります。これは linstor
node list-property <nodeName>
などのコマンドで表示されてしまいます。
特別なサテライトが稼働し始めたら、実際のストレージプールを作成できます。
$ linstor storage-pool create remotespdk -h usage: linstor storage-pool create remotespdk [-h] [--shared-space SHARED_SPACE] [--external-locking] node_name name driver_pool_name
node_name
は自明ですが、name
は LINSTOR ストレージプールの名前であり、 driver_pool_name
は
SPDK 論理ボリュームストアを指定します。
この remotespdk ストレージプールが作成されると、残りの手順は NVMe を使用する場合と非常に似ています。最初に、単に
“diskful” リソースでターゲットを作成し、2 番目のリソースは -nvme-initiator
オプションを有効にして作成します。
2.7. ネットワークインターフェイスカードの管理
LINSTORはマシンの複数のネットワークインターフェイスカード(NIC)を扱えます。LINSTORでこれらは netif
と呼びます。
サテライト ノードが作成されると、最初のネット インターフェイスが「default」という名前で暗黙的に作成されます。サテライトノードを作成するときに、node create コマンドの –interface-name オプションを使用して別の名前を付けることができます。 |
既存のノードの場合、次のように追加のネットインターフェイスが作成されます。
# linstor node interface create node-0 10G_nic 192.168.43.231
ネットインターフェイスは IP アドレスのみで識別されます。名前は任意であり、Linux で使用される NIC 名とは関係ありません。次に、ネットインターフェイスをノードに割り当てて、ノードの DRBD トラフィックが対応する NIC を介してルーティングされるようにします。
# linstor node set-property node-0 PrefNic 10G_nic
ストレージプールに「PrefNic」プロパティを設定することもできます。ストレージプールを使用するリソースからの DRBD トラフィックは、対応する NIC 経由でルーティングされます。ただし、ここで注意が必要です。ディスクレスストレージを必要とする DRBD リソース (たとえば、DRBD クォーラムの目的でタイブレーカーの役割を果たしているディスクレス ストレージ) は、「default」ネットインターフェイスの「PrefNic」プロパティを設定するまで、デフォルトのサテライトノードのネットインターフェイスを通過します。セットアップが複雑になる可能性があります。ノードレベルで「PrefNic」プロパティを設定する方がはるかに簡単で安全です。これにより、ディスクレスストレージプールを含む、ノード上のすべてのストレージプールが優先 NIC を使用します。 |
If you need to add an interface for only controller-satellite traffic, you
can add an interface using the above node interface create
command. Then
you modify the connection to make it the active controller-satellite
connection. For example, if you added an interface named 1G-satconn
on all
nodes, after adding the interface, you can then tell LINSTOR to use this
interface for controller-satellite traffic by entering the following
command:
# linstor node interface modify node-0 1G-satconn --active
You can verify this change by using the linstor node interface list node-0
command. Output from the command should show that the StltCon
label
applies to the 1G-satconn
interface.
While the above methods can re-route DRBD traffic, and LINSTOR communication
between the controller and satellite nodes, it is not possible through
linstor
commands only, to route LINSTOR controller-client traffic
(commands that you issue from a LINSTOR client to the controller) through a
specific NIC. To achieve this, you can either:
-
LINSTORクライアントの使用 で説明されている方法で LINSTOR コントローラーを指定し、コントローラーとクライアントのトラフィックに使用する NIC を経由するように指定されたコントローラーへのルートを持つだけにする。
-
ip route
やiptables
などの Linux ツールを使用して、LINSTOR クライアントコントローラートラフィックのポート番号 3370 をフィルタリングし、特定の NIC を介してルーティングする。
2.7.1. LINSTORによる複数のDRBDパスの作成
DRBDのセットアップに
複数のネットワークパスを使用するには、PrefNic
プロパティは十分ではありません。代わりに、次のように linstor node interface
と linstor
resource-connection path
コマンドを使用する必要があります。
# linstor node interface create alpha nic1 192.168.43.221 # linstor node interface create alpha nic2 192.168.44.221 # linstor node interface create bravo nic1 192.168.43.222 # linstor node interface create bravo nic2 192.168.44.222 # linstor resource-connection path create alpha bravo myResource path1 nic1 nic1 # linstor resource-connection path create alpha bravo myResource path2 nic2 nic2
上記の例では、各ノードに2つのネットワークインタフェース(nic1とnic2)を定義しています。 最後の2つのコマンドは、生成されるDRBDの
.res
ファイルにネットワークパスのエントリを作成します。 これが生成された .res
ファイルの関連する部分です。
resource myResource { ... connection { path { host alpha address 192.168.43.221:7000; host bravo address 192.168.43.222:7000; } path { host alpha address 192.168.44.221:7000; host bravo address 192.168.44.222:7000; } } }
ノードインタフェースの作成時にLINSTOR衛星トラフィックに使用するポート番号を指定できますが、DRBDリソース接続パスの作成時には、このポート番号は無視されます。代わりに、コマンドはポート番号を動的に割り当てます。 |
2.8. 暗号化ボリューム
LINSTORはDRBDボリュームの暗号化を透過的に扱うことができます。dm-cryptがストレージデバイスから提供されるストレージを暗号化するのに使われます。
dm-crypt を使用するには、サテライトを開始する前に cryptsetup がインストールされていることを確認してください。
|
暗号化の基本的な手順は以下になります。
-
マスターパスフレーズを作成する
-
layer-list に
luks
を追加します。すべてのプラグイン(Proxmoxなど)は、特に明記しない限り、最上位のレイヤーとして DRBD レイヤーを必要とすることに注意してください。 -
コントローラが再起動した後はマスターパスフレーズを再入力する
2.8.1. 暗号化のコマンド
以下にコマンドの詳細を示します。
LINSTORがボリュームを暗号化する前に、マスターパスフレーズを作ることが必要です。これには以下のlinstorコマンドを使用します。
# linstor encryption create-passphrase
crypt-create-passphrase
はマスターパスフレーズを初期化するためにユーザの入力を待ちます。
マスターパスフレーズを変更したい場合は以下のコマンドで行います。
# linstor encryption modify-passphrase
resource-definition またはリソース自体を作成するときに luks
レイヤーを追加できますが、前者の方法は、resource-definition から作成されたすべてのリソースに自動的に適用されるため、推奨されます。
# linstor resource-definition create crypt_rsc --layer-list luks,storage
マスターパスフェーズを入力する(コントローラを再起動した後)には以下を使用します。
# linstor encryption enter-passphrase
linstor-controllerが再起動したときは、コントローラにマスターパスフェーズを常に入力する必要があります。そうしないとLINSTORは暗号化されたボリュームをオープンしたり作成したりできません。 |
2.8.2. 自動パスフレーズ
マスターパスフレーズの作成と再入力のプロセスを自動化することは可能です。
これを使用するには、 MASTER_PASSPHRASE
という名前の環境変数、またはマスターパスフレーズを含む
/etc/linstor/linstor.toml
のエントリを作成する必要があります。
linstor.toml
は以下のようになります。
[encrypt] passphrase="example"
これらのいずれかが設定されている場合、コントローラが起動されるたびに、マスターパスフレーズがすでに存在するかどうかがチェックされます。ない場合は、指定されたとおりに新しいマスターパスフレーズが作成されます。ある場合、コントローラはパスフレーズを入力します。
マスターパスフレーズがすでに設定されていて、環境変数または linstor.toml
で指定されたものと同じでない場合、コントローラはマスターパスフレーズを再入力できず、ユーザーがパスフレーズ間違って入力したかのように動作します。これは、自動パスフレーズなしでコントローラを起動した場合と同じで、コマンドを使用して、ユーザーからの手動入力によってのみ解決できます。
|
マスターパスフレーズが環境変数と linstor.toml の両方に設定されている場合、linstor.toml
からのマスターパスフレーズのみが使用されます。
|
2.9. クラスター状態の確認
LINSTORにはクラスタの状態をチェックするいろいろなコマンドがあります。これらには ‘list’ サブコマンドを使用し、フィルターしたりソートしたりするいろいろなオプションを提供します。’–groupby’ オプションは出力のグルーピングとソートに使います。
# linstor node list # linstor storage-pool list --groupby Size
2.10. ノードの退避
LINSTOR コマンド node evacuate
を使用して、ノードのリソースを退避することができます。たとえば、クラスターからノードを削除する準備をしていて、ノードのリソースをクラスター内の他のノードに移動する必要がある場合です。ノードの退避に成功すると、ノードの
LINSTOR ステータスは “Online” ではなく “EVACUATE” と表示され、LINSTOR リソースを持ちません。
LINSTOR が Kubernetes や OpenNebula などの別の環境内にデプロイされているノードを退避する場合は、リソースを退避する前に、ノードの LINSTOR でサポートされているワークロードをクラスター内の別のノードに移動する必要があります。Kubernetes 環境については Kubernetes でのノードの退避 を参照してください。OpenNebula の LINSTOR ノードの場合、ノードのリソースを退避する前に、ノードがホストする OpenNebula LINSTOR ベースの仮想マシンをクラスター内の別のノードにライブマイグレードする必要があります。 |
次の手順でノードを退避します。
-
退避するノード上のリソースが “InUse” であるかどうかを確認します。 “InUse” ステータスは、リソースが DRBD Primary 状態です。ノードを正常に退避させるには、ノード上のリソースを “InUse” にしないでください。そうしないと、LINSTOR は退避中にノードから “InUse” リソースを削除できません。
-
linstor node evacuate <node_name>
を実行します。退避ノード上のリソースに適した代替ノードがない場合は、警告が表示されます。たとえば、3 つのノードがあり、1 つを退避したいが、リソースグループで配置数が 3 に設定されている場合、ノードが退避ノードからリソースを削除できないという警告が表示されます。 -
ノードの
linstor node list
のステータスが、 “Online” ではなく、 “EVACUATE” であることを確認してください。 -
linstor resource list
コマンドを使用して、ノード上のリソースの “State” ステータスを確認します。ノードのリソース内のデータセットのサイズに応じて、しばらく同期アクティビティが表示されるはずです。 -
linstor resource list --nodes <node_name>
コマンドを使用して、ノード上の残りのリソースを一覧表示します。残っている場合は、同期が完了するのを待っているだけかどうかを確認します。 -
linstor resource list
コマンドを使用して、ノードにリソースがないことを確認します。 -
linstor node delete node_name>
コマンドを使用して、クラスタからノードを削除します。
2.10.1. 複数のノードの退避
一部の退避ケースでは、特別な計画が必要になる場合があります。たとえば、複数のノードを退避する場合、LINSTOR のリソース自動配置に参加するノードから除外できます。これを行うには、退避する各ノードで次のコマンドを使用します。
# linstor node set-property <node_name> AutoplaceTarget false
これにより、退避しようとしているノードから、退避を計画している別のノードに LINSTOR がリソースを配置することがなくなります。
2.10.2. 退避ノードの復元
node evacuate
コマンドをすでに実行して、完了したか、リソースがまだ “Evacuating” 状態にある場合は、 node
restore
コマンドを使用して、ノードから “Evacuating” 状態を削除できます。 node delete
コマンドをまだ実行していない限り、これは機能します。
ノードを復元した後、以前に AutoplaceTarget
プロパティ を “false” に設定した場合は node set-property
<node_name> AutoplaceTarget true
を使用する必要があります。このようにして、LINSTOR
は再びリソースをノードに自動的に配置し、クラスター内のリソースに設定した配置カウントプロパティを満たすことができます。
node restore コマンドの実行時に LINSTOR がすでにリソースを退避している場合、退避されたリソースは自動的にノードに戻りません。
LINSTOR がまだリソースを退避中の場合、このプロセスは、LINSTOR
が他のノードにリソースを配置するまで続行されます。以前復元されたノードにあったリソースを手動で「移動」する必要があります。これを行うには、最初に復元されたノードでリソースを作成し、次に
LINSTOR がリソースを配置した別のノードからリソースを削除します。リソースが配置されているノードを表示するには resource list
コマンドを使用できます。
|
2.11. スナップショットの管理
スナップショットはthin LVMとZFSストレージプールでサポートされています。
2.11.1. スナップショットの作成
リソース定義 ‘resource1’ がすでにどこかのノードにあると仮定すると、スナップショットは以下のコマンドで作成できます。
# linstor snapshot create resource1 snap1
これはリソースが存在するすべてのノードでスナップショットを作成します。LINSTORはリソースが使用中でも一貫性のあるスナップショットが取れることを保証します。
resource-definition プロパティ AutoSnapshot/RunEvery
を設定すると LINSTOR は X
分ごとに自動的にスナップショットを作成します。オプションのプロパティ AutoSnapshot/Keep
を使用して、自動的に作成された古いスナップショットをクリーンアップできます。手動で作成されたスナップショットはクリーンアップ/削除されません。
AutoSnapshot/Keep
が省略されている(または 0 以下)の場合、LINSTOR
はデフォルトで最新の10個のスナップショットを保持します。
# linstor resource-definition set-property AutoSnapshot/RunEvery 15 # linstor resource-definition set-property AutoSnapshot/Keep 5
2.11.2. スナップショットの復元
以下の手順では新しいリソースにスナップショットを復元します。オリジナルのリソースがそれが取られたノードからすでに削除されていても復元可能です。
最初にスナップショットに一致するボリュームをもつリソースを定義します。
# linstor resource-definition create resource2 # linstor snapshot volume-definition restore --from-resource resource1 \ --from-snapshot snap1 --to-resource resource2
この時点で必要に応じて追加の設定を適用します。それで準備ができたら、スナップショットを使ってリソースを作成します。
# linstor snapshot resource restore --from-resource resource1 \ --from-snapshot snap1 --to-resource resource2
これにより、スナップショットが存在するすべてのノードに新しいリソースが作られます。リソースを作るノードも明示的に指定できます。詳細はヘルプ
(linstor snapshot resource restore -h
) を参照ください。
2.11.3. スナップショットへのロールバック
LINSTOR はリソースをスナップショット状態にロールバックできます。リソースが使用中のものはできません。つまり、どのノードにもマウントされていないものです。リソースが使用中の場合は、 こちら を検討してください。
ロールバックは次のようにして実行します。
# linstor snapshot rollback resource1 snap1
リソースは最新のスナップショットにのみロールバックできます。古いスナップショットにロールバックするには、最初に途中のスナップショットを削除します。
2.11.5. スナップショットの転送
スナップショットを送受信するサテライトには、次のツールをインストールします。
-
zstd
はデータが転送される前に圧縮するために必要です。 -
thin-send-recv
は lvm-thin でデータを転送するために必要です。
これらのツールをインストールした後、サテライトを再起動する必要があります。そうしないと、LINSTOR はそれらを使用できなくなります。 |
リモート
LINSTOR クラスターでは、転送ターゲットの定義をリモートと呼びます。現在、リモートには LINSTOR リモートと S3 リモートの2種類があります。 LINSTOR リモートは、スナップショットを別の LINSTOR クラスターに送信するために使用されますが、S3 リモートは、スナップショットを AWS S3, min.io または S3 互換オブジェクトストレージを使用するその他のサービスに送信するために使用されます。
リモートはパスワードなどの機密データを保存する必要があるため、何らかの方法で常に暗号化を有効にする必要があります。LINSTOR の暗号化設定は こちら を参照ください。 |
S3 リモートを作成するには、LINSTOR はエンドポイント(つまり、ターゲット S3 サーバーのURL)、ターゲットバケットの名前、S3 サーバーが存在するリージョン、およびアクセスキーとシークレットが必要です。アクセスキーを使用せずにコマンドを送信すると、プロンプトが表示されます。コマンドは次のようになります。
# linstor remote create s3 myRemote s3.us-west-2.amazonaws.com \ my-bucket us-west-2 admin password
通常、LINSTOR は指定されたバケット(my-bucket.s3.us-west-2.amazonaws.com
など)にアクセスするために、エンドポイントとバケットを使用して、仮想ホストスタイルの URL を作成します。この方法でのアクセスが許可されていない場合は
--use-path-style 引数を追加して、パススタイルのアクセス(例:
s3.us-west-2.amazonaws.com/my-bucket)に変更できます。
|
LINSTOR リモートを作成するには、ターゲットクラスターのコントローラーの URL または IP アドレスのみが必要です。コマンドは次のようになります。
# linstor remote create linstor myRemote 192.168.0.15
さらに、LUKSベースの(暗号化された)バックアップを転送するには、コマンドに --passphrase
, --cluster-id
を追加する必要があります。これは、ターゲットクラスターのパスフレーズとクラスター ID を保存するために使用されます。2 つの LINSTOR
クラスター間での LUKS ベースのバックアップの転送に関する詳細は こちら を参照ください。
ローカルクラスタに認識されているすべてのリモートを表示するには linstor remote list
を、削除するには linstor
remote delete myRemoteName
を、変更する場合は linstor remote modify
を使用します。
スナップショットの S3 への転送
スナップショットを S3 に送信するには、現在のクラスターが到達できる S3 リモートに、送信する必要のあるリソースを転送するだけです。次に、次のコマンドを使用して転送します。
# linstor backup create myRemote myRsc
このコマンドは、リソースのスナップショットを作成し、指定されたリモートに転送します。このリソースのバックアップを(そのリモートに)転送するのが初めてではなく、前のバックアップのスナップショットがまだ削除されていない場合は、増分バックアップが転送されます。フルバックアップの作成を強制するには、コマンドに
--full
引数を追加します。 --node myNode
を使用して特定のノードにバックアップを転送することもできますが、指定したノードが使用できない場合、またはリソースがディスクレスしかない場合は、別のノードが選択されます。
特定のリモートのバックアップを確認するには linstor backup list myRemote
を使用します。引数 --resource
myRsc
を使用して、特定のリソースのバックアップのみを表示するフィルターとして resource-name をコマンドに追加できます。
--other
引数を使用すると、LINSTOR がバックアップとして認識しないバケット内のエントリのみが表示されます。LINSTOR
は常に特定の方法でバックアップに名前を付けます。リモート内のアイテムにこのスキーマに従って名前が付けられている限り、それは LINSTOR
によって作成されたバックアップであると見なされます。したがって、このリストには他のすべてが表示されます。
バックアップの削除に関しては、いくつかのオプションがあります。
-
linstor backup delete all myRemote
: このコマンドは、バックアップであると認識されている、つまり期待されるネーミングスキーマに適合している限り、指定されたリモート上のすべての S3 オブジェクトを削除します。現在のクラスターによって作成されたバックアップのみを削除するオプション--cluster
があります。 -
linstor backup delete id myRemote my-rsc_back_20210824_072543
: このコマンドは、指定されたリモートから単一のバックアップを削除します。つまり、ID はリソース名、自動生成されたスナップショット名(back_timestamp)、設定されていた場合はバックアップサフィックスで構成されます。オプション--prefix
を使用すると、指定された ID で始まるすべてのバックアップを削除できます。オプション--cascade
を使用すると、指定されたバックアップだけでなく、それに依存する他のすべての増分バックアップを削除します。 -
linstor backup delete filter myRemote …
: このコマンドは、削除するバックアップの選択を指定するためのいくつかの異なる引数があります。-t 20210914_120000
は 2021年9月14日の 12 時より前に作成されたすべてのバックアップを削除します。-n myNode
は指定されたノードによってアップロードされたすべてのバックアップを削除します。-r myRsc
は指定されたリソース名のすべてのバックアップを削除します。これらのフィルターは必要に応じて組み合わせることができます。最後に--cascade
は選択したバックアップだけでなく、選択したバックアップのすべての増分バックアップを削除します。 -
linstor backup delete s3key myRemote randomPictureInWrongBucket
: このコマンドは、指定された S3 キーを持つオブジェクトを検索し、何も考慮せずにそれを削除します。これは、リモートから非バックアップアイテムを削除するか、他の方法で削除できなくなった壊れたバックアップをクリーンアップするためにのみ使用します。このコマンドを使用して通常の動作中のバックアップを削除すると、そのバックアップが破損するため、注意してください。
--cascade オプションを持つすべてのコマンドは、明示的に指定しない限り、それに依存する増分バックアップを削除しません。
|
すべての linstor backup delete … コマンドには --dry-run オプションがあり、削除されるすべての S3
オブジェクトのリストが表示されます。これを使用して、削除してはならないものが誤って削除されることを防ぐことができます。
|
おそらく、バックアップを作成した後の最も重要なタスクは、バックアップを復元することです。そのために必要なのはリモートのみですが、既存のスナップショットやリソースを使用せずに既存のリソース定義に復元することもできます。コマンドには 2 つのオプションがあります。
# linstor backup restore myRemote myNode targetRsc --resource sourceRsc # linstor backup restore myRemote myNode targetRsc --id sourceRsc_back_20210824_072543
--resource (-r)
または --id
のいずれかを使用する必要がありますが、両方を一緒に使用することはできません。 -r
はこのオプションで指定されたリソースの最新のバックアップを復元するために使用されますが、--id
は id
で明示的に指定されたバックアップを復元するため、最新以外のバックアップを復元するために使用されます。
復元するバックアップに LUKS レイヤーが含まれている場合は --passphrase
引数が必要です。これを使用して、バックアップの元のクラスターのパスフレーズを設定し、LINSTOR
がダウンロード後にボリュームを復号化し、再暗号化できるようになります。
バックアップの復元は、最後の完全バックアップから指定されたバックアップまでのすべてのスナップショットをダウンロードします。その後、スナップショットを新しいリソースに復元します。最後のステップをスキップする場合は
--download-only
オプションを追加します。
バックアップは、設定が正しい限り、アップロードしたクラスターだけでなく、任意のクラスターからダウンロードできます。具体的には、ターゲットリソースに既存のリソースまたはスナップショットを含めることはできず、使用するストレージプールには同じストレージプロバイダーが必要です。ターゲットノードのストレージプールの名前が、バックアップが作成されたクラスターの名前とまったく同じである場合、追加のアクションは必要ありません。名前が異なる場合は、オプション
--storpool-rename
を使用します。少なくとも 1 つの oldname=newname
ペアが必要です。そのリストで名前が付けられていない元のバックアップのすべてのストレージプールについて、その名前はターゲットノードでまったく同じであると見なされます。
名前を変更する必要のあるストレージプールやダウンロードと復元されたリソースのサイズを正確に確認するには、コマンド linstor backup
info myRemote …
を使用できます。復元コマンドと同様に -r
または --id
のいずれかを指定する必要があり、これにより、同じ制限が追加されます。復元後にローカルストレージプールに残っているスペースを確認するには、引数 -n
myNode
を追加します。復元の場合と同様に、特定のノードのストレージプール名がバックアップの場合とまったく同じであると想定します。そうでない場合も、復元コマンドの場合と同様に
--storpool-rename
を使用します。
Shipping Snapshots Between Two LINSTOR Clusters
Shipping a snapshot directly between two LINSTOR clusters can be done with a LINSTOR remote as well as a resource definition with at least one diskful resource on the source side (where the shipping command is issued). On the target side, you need to create a LINSTOR remote with the cluster ID of the source (remote) cluster:
$ linstor remote create linstor --cluster-id <SOURCE_CLUSTER_ID> <NAME> <URL>
If you do not specify the cluster ID of your source cluster when you create
a LINSTOR remote on your target cluster, you will receive an “Unknown
Cluster” error when you try to ship a backup. To get the cluster ID of your
source cluster, you can enter the command linstor controller
list-properties|grep -i cluster from the source cluster.
|
In the remote create
command shown above, <NAME>
is an arbitrary name
that you specify to identify the remote. <URL>
is either the IP address of
the source (remote) LINSTOR controller or its resolvable hostname. If you
have configured a highly available LINSTOR controller, use its virtual IP
address (VIP) or the VIP’s resolvable name.
Snapshot Shipping Within a Single LINSTOR Cluster
If you want to ship a snapshot inside the same cluster, you just need to create a LINSTOR remote that points to the local controller.
Specifying a LINSTOR Passphrase When Creating a Remote
When the snapshot that you want to ship contains a LUKS layer, the remote on the target cluster also needs the passphrase of the source cluster set when you create the remote. This is because the LINSTOR passphrase is used to encrypt the LUKS passphrase. To specify the source cluster’s LINSTOR passphrase when you create a LINSTOR remote on the target cluster, enter:
$ linstor --controllers <TARGET_CONTROLLER> remote create linstor \ --cluster-id <SOURCE_CLUSTER_ID> --passphrase <SOURCE_CONTROLLER_PASSPHRASE> <NAME> <URL>
For LINSTOR to LINSTOR snapshot shipping, you must also create a LINSTOR remote on the source cluster. For simplicity sake, although not strictly necessary, you can specify the target cluster’s LINSTOR passphrase when you create a LINSTOR remote for the target cluster on the source cluster, before you ship backups or snapshots. On the source cluster, enter:
$ linstor --controllers <SOURCE_CONTROLLER> remote create linstor \ --cluster-id <TARGET_CLUSTER_ID> --passphrase <TARGET_CONTROLLER_PASSPHRASE> <NAME> <URL>
If you are specifying a LINSTOR controller node (perhaps because you have a highly available controller), when creating a remote, you can specify the controller either by an IP address or a resolvable hostname. |
Shipping a Backup of a LINSTOR Resource
バックアップを出荷するコマンドは
# linstor backup ship myRemote localRsc targetRsc
さらに --source-node
と --target-node
を使用して、バックアップを送信および受信するノードをそれぞれ指定できます。これらのノードが使用できない場合は、別のノードが自動的に選択されます。
targetRsc
がすでにリモートクラスタにデプロイされているリソースである場合、 localRsc
のバックアップ転送のスナップショットはリモートクラスタに転送されますが、リモートクラスタでは復元されません。 linstor backup ship
コマンドで --download-only
オプションを指定した場合も同様です。
同じクラスター内へのスナップショットの転送
ソースノードとターゲットノードの両方に、デプロイされたスナップショット転送のリソースをもつ必要があります。さらに、ターゲットリソースを非アクティブ化する必要があります。
# linstor resource deactivate nodeTarget resource1
レイヤーリストに DRBD があるリソースを非アクティブ化すると、再びアクティブ化することはできません。ただし、DRBD リソースの正常に転送されたスナップショットは 新しいリソースで復元 できます。 |
スナップショット転送を手動で開始するには、次を使用します。
# linstor snapshot ship --from-node nodeSource --to-node nodeTarget --resource resource1
snapshot ship
コマンドは非推奨と見なされ、それで見つかったバグは修正されません。代わりに、リモートがローカルコントローラを指している状態で backup ship
コマンドを使用してください。詳細は こちら を参照ください。
|
By default, the snapshot-shipping uses TCP ports from the range
12000-12999. To change this range, the property
SnapshotShipping/TcpPortRange
, which accepts a to-from range, can be set
on the controller:
# linstor controller set-property SnapshotShipping/TcpPortRange 10000-12000
リソースは定期的に転送することもできます。これにはリソース定義で必須のプロパティ SnapshotShipping/TargetNode
および
SnapshotShipping/RunEvery
を設定する必要があります。SnapshotShipping/SourceNode
も設定できますが、省略した場合、LINSTOR は同じリソース定義のアクティブなリソースを選択します。
増分スナップショット転送を可能にするには、LINSTOR
は少なくとも最後に転送されたスナップショットをターゲットノードに保持する必要があります。プロパティ SnapshotShipping/Keep
は、LINSTOR が保持する必要があるスナップショットの数を指定するために使用できます。プロパティが設定されていない(または 0
以下)の場合、LINSTOR はデフォルトで最新の10個のスナップショットを保持します。
# linstor resource-definition set-property resource1 SnapshotShipping/TargetNode nodeTarget # linstor resource-definition set-property resource1 SnapshotShipping/SourceNode nodeSource # linstor resource-definition set-property resource1 SnapshotShipping/RunEvery 15 # linstor resource-definition set-property resource1 SnapshotShipping/Keep 5
2.12. 計画されたバックアップの配信
LINSTOR Controller バージョン 1.19.0 以降、LINSTOR クライアントバージョン 1.14.0 以降では、配置された LINSTOR リソースのスケジュールバックアップの配信を設定することができます。
定期的なバックアップの配信は、3つのパートで構成されています。
-
バックアップと配信を行いたい1つまたは複数のLINSTORリソースからなるデータセット
-
バックアップの配信先(他のLINSTORクラスタまたはS3インスタンス)
-
バックアップを発行するタイミングを定義するスケジュール
LINSTORバックアップの配信は、LVMとZFSストレージプールにバックアップされたLINSTORリソースに対してのみ機能します。これは、LINSTORでスナップショットをサポートするストレージプールタイプであるためです。 |
2.12.1. バックアップの配信スケジュールを作成する
LINSTORクライアントの schedule create
コマンドを使用してバックアップ出荷スケジュールを作成し、cron
構文を使用してバックアップ配信の頻度を定義します。また、スケジュールに名前を付けるオプションを設定し、障害発生時の対応、ローカルとリモートのバックアップコピーの数、増分バックアップの配信をスケジュールするかどうかなど、バックアップ配信の様々な側面を定義する必要があります。
最低限、このコマンドはバックアップ出荷スケジュールを作成するために、スケジュール名とフルバックアップcronスキーマを必要とします。コマンドの例は次のようになります。
# linstor schedule create \ --incremental-cron '* * * * *' \ (1) --keep-local 5 \ (2) --keep-remote 4 \ (3) --on-failure RETRY \ (4) --max-retries 10 \ (5) <schedule_name> \ (6) '* * * * *' # full backup cron schema (7)
cronスキーマは一重引用符または二重引用符で囲んでください。 |
1 | 指定された場合、増分cronスキーマは、増分バックアップを作成し、出荷する頻度を記述します。新しいインクリメンタルバックアップは、最新のフルバックアップに基づいて行われます。 |
2 | The --keep-local option allows you to specify how many snapshots that a
full backup is based upon should be kept at the local backup source. If
unspecified, all snapshots will be kept. [OPTIONAL] |
3 | --keep-remote
オプションは、リモートバックアップ先で保持するフルバックアップの数を指定することができます。このオプションはS3リモートバックアップ先でのみ機能します。なぜなら、クラスタノードが他のクラスタ内のノードからバックアップを削除することを許可したくないからです。削除されたフルバックアップに基づくすべての増分バックアップも、リモートディスティネーションで削除されます。指定しない場合、--keep-remote
オプションはデフォルトで “all” になります。[OPTIONAL] |
4 | スケジュールされたバックアップの出荷が失敗した場合に、”RETRY “または “SKIP “のどちらを行うかを指定します。SKIP”
が指定された場合、LINSTORは失敗を無視し、次に予定されているバックアップの配送を続行します。RETRY”
が指定された場合、LINSTORは60秒待って、再度バックアップの配送を試みます。LINSTOR の schedule create コマンドは
--on-failure オプションが与えられないと、デフォルトで “SKIP” になります。[OPTIONAL] |
5 | バックアップの出荷が失敗し、--on-failure RETRY
オプションが指定された場合、バックアップの出荷を再試行する回数です。このオプションがない場合、LINSTORコントローラはスケジュールされたバックアップの出荷を、成功するまで無期限に再試行します。[OPTIONAL] |
6 | スケジュールリスト、修正、削除、有効、無効コマンドで後で参照できるように、バックアップスケジュールに付ける名前です。[REQUIRED] |
7 | このcronスキーマは、LINSTORがどの程度の頻度でスナップショットを作成し、フルバックアップを出荷するかを記述しています。 |
増分cronスキーマを指定した場合、フルcronスキーマと重複しているため、両方のバックアップが同時に行われる場合、LINSTORはフルバックアップのみを作成し、出荷します。例えば、3時間ごとにフルバックアップを行い、1時間ごとに増分バックアップを行うように指定した場合、3時間ごとにLINSTORはフルバックアップのみを作成し出荷します。この理由から、増分バックアップとフルバックアップの出荷スケジュールの両方に同じcronスキーマを指定しても、増分バックアップは決して作成されないため、意味がありません。 |
2.12.2. バックアップの配信スケジュールを変更する
LINSTORクライアントの schedule modify
コマンドを使用すると、バックアップの出荷スケジュールを変更することができます。
このコマンドの構文は schedule create
コマンドの構文と同じです。schedule modify`
コマンドで指定する名前は、すでに存在するバックアップスケジュールでなければなりません。コマンドのオプションで指定しないものは、既存の値を保持します。keep-local`
または keep-remote
オプションをデフォルト値に戻したい場合は、”all “に設定します。max-retries`
オプションをデフォルトの値に戻したい場合は、”forever” に設定します。
2.12.3. Configuring the Number of Local Snapshots and Remote Backups to Keep
物理ストレージは無限ではなく、リモートストレージにはコストがかかるため、スナップショットやバックアップの保存数に制限を設けるとよいでしょう。
keep-remote` と --keep-local
の両オプションは、明らかな意味を持つので、特別な言及に値します。これらのオプションを使用すると、スナップショットやフルバックアップを何回保持するかを、ローカルのソースまたはリモートの宛先に指定することができます。
Keep-localオプションの設定
例えば、--keep-local=2
オプションが設定されている場合、バックアップの出荷スケジュールは、最初の実行時に、フルバックアップのためのスナップショットを作成することになります。次にスケジュールされたフルバックアップの出荷では、フルバックアップのための2番目のスナップショットを作成します。次のスケジュールされたフルバックアップの出荷では、フルバックアップのための3番目のスナップショットが作成されます。しかし今回は、正常に完了すると、LINSTORは最初の(最も古い)フルバックアップの出荷用スナップショットを削除します。もしスナップショットがこのフルバックアップに基づく増分バックアップのために作成された場合、それらはローカルソースノードから削除されます。次のフルバックアップの出荷が成功すると、LINSTORは2番目のフルバックアップのスナップショットとそれに基づくすべての増分スナップショットを削除し、これを繰り返すことで各バックアップの出荷が成功します。
If there are local snapshots remaining from failed shipments, these will be deleted first, even if they were created later. |
バックアップ配信スケジュールを有効にし、後で手動でLINSTORスナップショットを削除する場合、LINSTORはそれが予定されていたすべてを削除することができない場合があります。例えば、フルバックアップのスナップショット定義を削除した場合、後のフルバックアップのスケジュール配信時に、手動で削除したフルバックアップスナップショットに基づくインクリメンタルスナップショットが削除されないことがあります。
Keep-remoteオプションの設定
上記の linstor schedule create
コマンドの例のコールアウトで述べたように、 keep-remote
オプションはS3リモートデスティネーションに対してのみ機能します。ここでは、このオプションがどのように機能するかの例を示します。keep-remote=2`
オプションが設定されている場合、バックアップ出荷スケジュールは、最初の実行時に、フルバックアップ用のスナップショットを作成し、それをリモートデスティネーションに出荷します。次にスケジュールされたフルバックアップの出荷では、2番目のスナップショットが作成され、フルバックアップがリモートデスティネーションに出荷されます。次にスケジュールされたフルバックアップの出荷時に、3つ目のスナップショットが作成され、フルバックアップがリモートディスティネーションに出荷されます。今回はさらに、3つ目のスナップショットが正常に出荷された後、最初のフルバックアップがリモートディスティネーションから削除されます。フルバックアップの間に増分バックアップがスケジュールされていた場合、最初のフルバックアップから作成されたものはフルバックアップと一緒に削除されます。
このオプションは、リモート宛先のバックアップを削除するだけです。ローカル ソース ノードでのフル バックアップの基となったスナップショットは削除されません。 |
2.12.4. バックアップの配信スケジュールを記載する
linstor schedule list` コマンドを使用すると、バックアップの配信スケジュールを一覧することができます。
For example:
# linstor schedule list ╭──────────────────────────────────────────────────────────────────────────────────────╮ ┊ Name ┊ Full ┊ Incremental ┊ KeepLocal ┊ KeepRemote ┊ OnFailure ┊ ╞══════════════════════════════════════════════════════════════════════════════════════╡ ┊ my-bu-schedule ┊ 2 * * * * ┊ ┊ 3 ┊ 2 ┊ SKIP ┊ ╰──────────────────────────────────────────────────────────────────────────────────────╯
2.12.5. バックアップした配信予定を削除する
LINSTORクライアントの schedule delete
コマンドはバックアップされた配信予定LINSTORオブジェクトを完全に削除するコマンドです。このコマンドの唯一の引数は削除したいスケジュール名です。削除されたスケジュールが現在バックアップを作成または配信している場合、スケジュールされた出荷処理は停止されます。処理が停止した時点によっては、スナップショット、バックアップ、またはその両方が作成および配信されない可能性があります。
このコマンドは、以前に作成されたスナップショットや正常に配信されたバックアップには影響しません。これらは、手動で削除されるまで保持されます。
2.12.6. バックアップの定期的な配信を可能にする
LINSTORクライアントの backup schedule enable
コマンドを使用すると、以前に作成したバックアップ配信スケジュールを有効にすることができます。このコマンドは次のような構文になっています。
# linstor backup schedule enable \ [--node source_node] \ (1) [--rg resource_group_name | --rd resource_definition_name] \ (2) remote_name \ (3) schedule_name (4)
1 | これは特別なオプションで、可能であればスケジュールされたバックアップ配信のソースとして使用されるコントローラノードを指定することができます。もしこのオプションをコマンドから省略した場合、LINSTORはスケジュールされた配信が行われる時にソースノードを選択することになります。[OPTIONAL] |
2 | ここでは、バックアップ配信スケジュールを有効にするリソースグループまたはリソース定義のいずれか(ただし両方は不可)を設定できます。このオプションを省略すると、スナップショットを作成できるすべてのLINSTORリソースに対して、バックアップ配信スケジュールが有効になります。[OPTIONAL] |
3 | バックアップを配信するリモート宛先の名前です。[REQUIRED] |
4 | 以前に作成されたバックアップ配信スケジュールの名前です。[REQUIRED] |
2.12.7. バックアップの配信スケジュールを無効にする
以前に有効にしたバックアップ配信スケジュールを無効にするには、LINSTORクライアントの backup schedule disable
コマンドを使用します。このコマンドは次のような構文になります。
# linstor backup schedule disable \ [--rg resource_group_name | --rd resource_definition_name] \ remote_name \ (3) schedule_name (4)
もし、上記の backup schedule enable
コマンドの例のように、リソースグループかリソース定義のどちらかを指定するオプションを含めると、そのリソースグループかリソース定義に対してのみ、スケジュールを無効にします。
例えば、以前の backup schedule enable
コマンドでリソースグループやリソース定義の指定を省略した場合、LINSTORはスナップショットを作成することができるすべてのリソースのバックアップ出荷をスケジュールすることになります。disableコマンドは、そのコマンドで指定されたリソースグループやリソース定義にのみ影響します。バックアップ出荷のスケジュールは、指定されたリソースグループまたはリソース定義以外のすべてのLINSTORリソースに適用されます。
バックアップスケジュール有効化コマンドと同様に、リソースグループもリソース定義も指定しない場合、LINSTORは配備されたすべてのLINSTORリソースのコントローラレベルでのバックアップ出荷スケジュールを無効化します。
2.12.8. バックアップされた出荷予定のアスペクトを削除する
linstor backup schedule delete`
コマンドを使うと、スケジュール自体を削除することなく、指定したリソース定義やリソースグループをバックアップ出荷スケジュールからきめ細かく削除することができます。このコマンドは
backup schedule disable
コマンドと同じシンタックスと引数を持っています。リソースグループもリソース定義も指定しない場合、指定したバックアップ出荷スケジュールはコントローラーレベルで削除されます。
バックアップスケジュール削除コマンドは、LINSTORオブジェクトレベル、リソース定義、リソースグループ、またはコントローラレベル(どちらも指定されていない場合)からバックアップ出荷スケジュールとリモートのペアを*削除*する方法として考えると便利かもしれません。
backup schedule delete` コマンドは以前に作成されたスナップショットや正常にシッピングされたバックアップには影響を与えません。これらは手動で削除されるか、まだ適用可能な keep-local または keep-remote オプションの効果によって削除されるまで保持されます。
このコマンドは、複数のLINSTORオブジェクトレベルのバックアップスケジュールを無効にした後、粒度の細かい変更を行いたい場合に使用します。この場合、backup
schedule enable
コマンドは意図しない結果をもたらすかもしれません。
例えば、コントローラレベルで有効にしたバックアップスケジュールとリモートのペアがある場合 を考えてみましょう。このコントローラには、_myresgroup_というリソースグループがあり、その下に_resdef1_から_resdef9_といういくつかのリソース定義があります。メンテナンスのために、2つのリソース定義_resdef1_と_resdef2_のスケジュールを無効にします。その後、メンテナンスのために、_myresgroup_リソースグループのリソースグループレベルでバックアップ出荷スケジュールを無効にする必要があることに気づきました。
メンテナンスが完了し、_resdef3_から_resdef9_までのバックアップ出荷スケジュールを有効にできますが、_resdef1_と_resdef2_のバックアップ出荷を再開(有効)する準備がまだできていません。resdef3_から_resdef9_までの各リソース定義に対して個別にバックアップ配送を有効にするか、backup
schedule delete
コマンドを使用してリソースグループ_myresgroup_からバックアップ配送スケジュールを削除することができます。backup schedule
delete`
コマンドを使用すると、_resdef3_から_resdef9_のバックアップはコントローラレベルでバックアップ出荷スケジュールが有効になっているため再び出荷されますが、_resdef1_と_resdef2_はリソース定義レベルでバックアップ出荷スケジュールがまだ無効になっているため出荷されません。
メンテナンスが完了し、_resdef1_と_resdef2_のバックアップを出荷する準備ができたら、これら2つのリソース定義のバックアップ出荷スケジュールを削除して、コントローラレベルですべてのLINSTOR展開されたリソースのバックアップ出荷をスケジュールする、開始状態に戻すことができます。これを視覚化するために、 LINSTORコントローラがスケジュールされたバックアップの出荷を決定する方法 サブセクションにあるLINSTORがバックアップを出荷するかどうかを決定する方法についてのディシジョンツリー図を参照するとよいかもしれません。
上記の例では、メンテナンス終了後にリソースグループのバックアップ出荷を有効にした場合があります。この場合、リソース定義_resdef3_から_resdef9_についてはバックアップ出荷が再開されますが、リソース定義_resdef1_と_resdef2_についてはバックアップ出荷がまだ無効になっているため、引き続き出荷が行われません。すべてのメンテナンスが完了したら、_resdef1_と_resdef2_のバックアップ出荷スケジュールを削除してください。そうすると、リソースグループレベルでスケジュールとリモートのペアが有効になっているため、メンテナンス前と同じように、すべてのリソース定義でバックアップが出荷されるようになります。しかし、リソースグループレベルで有効化されたスケジュールは、コントローラレベルで適用された`schedule disable` コマンドを上書きするため、コントローラレベルで後の時点ですべてのスケジュールされた出荷をグローバルに停止するオプションは削除されます。 |
2.12.9. リソース別バックアップ出荷スケジュール一覧表
LINSTORクライアントの schedule list-by-resource
コマンドを使えば、リソースごとのバックアップスケジュールをリストアップすることができます。このコマンドはLINSTORリソースを表示し、バックアップの出荷スケジュールがどのように適用され、どのリモートに出荷されるかを表示します。もしリソースが出荷されていない場合は、このコマンドは表示されます。
-
リソースにschedule-remote-pairのエントリーがないかどうか(空白のセル)
-
schedule-remote-pairの項目があるが、無効になっているかどうか(”disabled”)。
-
リソースがないため、schedule-remote-pairのエントリーが有効かどうかに関わらず、バックアップ出荷ができないかどうか(”undeployed”)
リソースにschedule-remote-pairがあり、出荷されている場合、コマンド出力には、最後のバックアップがいつ出荷されたか、次のバックアップがいつ出荷される予定であるかが表示されます。また、次回のバックアップと前回のバックアップの出荷がフルバックアップかインクリメンタルバックアップかが表示されます。最後に、このコマンドは、増分バックアップ(もしあれば)およびフルバックアップの次の出荷予定日を表示します。
スケジュールリストバイリソースコマンドで --active-only
フラグを使用すると、出荷されていないリソースをすべてフィルタリングすることができます。
2.12.10. LINSTORコントローラがスケジュールされたバックアップの出荷を決定する方法
LINSTORコントローラは、デプロイされたLINSTORリソースが特定のリモート宛先に特定のバックアップスケジュールで出荷されるかどうかを判断するために、以下のロジックを使用します。

図に示すように、有効または無効なバックアップ出荷スケジュールは、次の順序で効果を発揮します。
-
リソース定義レベル
-
リソースグループレベル
-
コントローラーレベル
先行するレベルで有効または無効にされたバックアップ出荷スケジュールと遠隔地のペアは、後のレベルで同じスケジュールと遠隔地のペアの有効または無効の状態を上書きします。
2.12.11. スケジュールされたバックアップの出荷がリソースに与える影響の確認
LINSTORリソースがスケジュールされたバックアップ出荷によってどのような影響を受けるかを知るには、LINSTORクライアントの schedule
list-by-resource-details
コマンドを使用して指定したLINSTORリソースに対して行うことができます。
このコマンドは、どのLINSTORオブジェクト・レベルにおいて、バックアップ出荷スケジュールが設定されていない(空のセル)、有効、または無効であるかを示すテーブルを出力します。
このコマンドを使用すると、リソースのスケジュールバックアップの有効化、無効化、削除をどのレベルで変更する必要があるかを判断することができます。
出力例は次のようになります。
# linstor schedule list-by-resource-details my_linstor_resource_name ╭───────────────────────────────────────────────────────────────────────────╮ ┊ Remote ┊ Schedule ┊ Resource-Definition ┊ Resource-Group ┊ Controller ┊ ╞═══════════════════════════════════════════════════════════════════════════╡ ┊ rem1 ┊ sch1 ┊ Disabled ┊ ┊ Enabled ┊ ┊ rem1 ┊ sch2 ┊ ┊ Enabled ┊ ┊ ┊ rem2 ┊ sch1 ┊ Enabled ┊ ┊ ┊ ┊ rem2 ┊ sch5 ┊ ┊ Enabled ┊ ┊ ┊ rem3 ┊ sch4 ┊ ┊ Disabled ┊ Enabled ┊ ╰───────────────────────────────────────────────────────────────────────────╯
2.13. Setting DRBD Options for LINSTOR Objects
You can use LINSTOR commands to set DRBD options. Configurations in files
that are not managed by LINSTOR, such as /etc/drbd.d/global_common.conf
,
will be ignored. The syntax for this command is generally:
# linstor <LINSTOR_object> drbd-options --<DRBD_option> <value> <LINSTOR_object_identifiers>
In the syntax above, <LINSTOR_ object_identifiers>
is a placeholder for
identifiers such as a node name, node names, or a resource name, or a
combination of these identifiers.
For example, to set the DRBD replication protocol for a resource definition
named backups
, enter:
# linstor resource-definition drbd-options --protocol C backups
You can enter a LINSTOR object along with drbd-options
and the --help
,
or -h
, flag to show the command usage, available options, and the default
value for each option. For example:
# linstor controller drbd-options -h
2.13.1. Setting DRBD Peer Options for LINSTOR Resources or Resource Connections
The LINSTOR resource object is an exception to the general syntax for
setting DRBD options for LINSTOR objects. With the LINSTOR resource object,
you can use the drbd-peer-options
to set DRBD options at the connection
level between the two nodes that you specify. Specifying drbd-peer-options
for a LINSTOR resource object between two nodes is equivalent to using
the`linstor resource-connection drbd-peer-options` for a resource between
two nodes.
For example, to set the DRBD maximum buffer size to 8192 at a connection
level, for a resource named backups
, between two nodes, node-0
and
node-1
, enter:
# linstor resource drbd-peer-options --max-buffers 8192 node-0 node-1 backups
The command above is equivalent to the following:
# linstor resource-connection drbd-peer-options --max-buffers 8192 node-0 node-1 backups
Indeed, when using the linstor --curl
command to examine the two commands
actions on the LINSTOR REST API, the output is identical:
# linstor --curl resource drbd-peer-options --max-buffers 8192 node-0 node-1 backups curl -X PUT -H "Content-Type: application/json" -d '{"override_props": {"DrbdOptions/Net/max-buffers": "8192"}}' http://localhost:3370/v1/resource-definitions/backups/resource-connections/node-0/node-1 # linstor --curl resource-connection drbd-peer-options --max-buffers 8192 node-0 node-1 backups curl -X PUT -H "Content-Type: application/json" -d '{"override_props": {"DrbdOptions/Net/max-buffers": "8192"}}' http://localhost:3370/v1/resource-definitions/backups/resource-connections/node-0/node-1
The connection section of the LINSTOR-generated resource file backups.res
on node-0
will look something like this:
connection { _peer_node_id 1; path { _this_host ipv4 192.168.222.10:7000; _remote_host ipv4 192.168.222.11:7000; } path { _this_host ipv4 192.168.121.46:7000; _remote_host ipv4 192.168.121.220:7000; } net { [...] max-buffers 8192; _name "node-1"; } }
If there are multiple paths between the two nodes, as in the example above,
DRBD options that you set using the resource drbd-peer-options command
will apply to all of them.
|
2.13.2. Setting DRBD Options for Node Connections
You can use the drbd-peer-options
argument to set DRBD options at a
connection level, between two nodes, for example:
# linstor node-connection drbd-peer-options --ping-timeout 299 node-0 node-1
The preceding command would set the DRBD ping-timeout
option to 29.9
seconds at a connection level between two nodes, node-0
and node-1
.
2.13.3. Verifying Options for LINSTOR Objects
You can verify a LINSTOR object’s set properties by using the
list-properties
command, for example:
|======================================================| # linstor resource-definition list-properties backups +------------------------------------------------------+ | Key | Value | | DrbdOptions/Net/protocol | C | [...]
[[s-linstor-unset-opts]] ==== Removing DRBD Options from LINSTOR Objects
To remove a previously set DRBD option, prefix the option name with unset-
. For
example:
# linstor resource-definition drbd-options --unset-protocol backups
The same syntax applies to any drbd-peer-options
set either on a LINSTOR resource, resource
connection, or node connection. For example:
# linstor resource-connection drbd-peer-options --unset-max-buffers node-0 node-1 backups
Removing a DRBD option or DRBD peer option will return the option to its default value. Refer to the `linstor <LINSTOR_object> drbd-options --help` (or `drbd-peer-options --help`) command output for the default values of options. You can also refer to the `drbd.conf-9.0` man page to get information about DRBD options. [[s-linstor-toggle-disk]] === ディスクの追加と削除
LINSTOR can convert resources between diskless and having a disk.
This is achieved with the resource toggle-disk
command,
which has syntax similar to resource create
.
For instance, add a disk to the diskless resource backups
on ‘alpha’:
# linstor resource toggle-disk alpha backups --storage-pool pool_ssd
Remove this disk again:
# linstor resource toggle-disk alpha backups --diskless
[[s-linstor-migrate-disk]] ==== ノード間でのディスクの移行
To move a resource between nodes without reducing redundancy at any point,
LINSTOR’s disk migrate feature can be used.
First create a diskless resource on the target node,
and then add a disk using the --migrate-from
option.
This will wait until the data has been synced to the new disk and then remove
the source disk.
For example, to migrate a resource backups
from ‘alpha’ to ‘bravo’:
# linstor resource create bravo backups --drbd-diskless # linstor resource toggle-disk bravo backups --storage-pool pool_ssd --migrate-from alpha
[[s-linstor-proxy]] === LINSTOR を使用した DRBD プロキシの構成
LINSTOR expects DRBD Proxy to be running on the nodes which are involved in the relevant connections. It does not currently support connections through DRBD Proxy on a separate node.
Suppose our cluster consists of nodes ‘alpha’ and ‘bravo’ in a local network
and ‘charlie’ at a remote site, with a resource definition named backups
deployed to each of the nodes. Then DRBD Proxy can be enabled for the
connections to ‘charlie’ as follows:
# linstor drbd-proxy enable alpha charlie backups # linstor drbd-proxy enable bravo charlie backups
The DRBD Proxy configuration can be tailored with commands such as:
# linstor drbd-proxy options backups --memlimit 100000000 # linstor drbd-proxy compression zlib backups --level 9
LINSTOR does not automatically optimize the DRBD configuration for long-distance replication, so you will probably want to set some configuration options such as the protocol:
# linstor resource-connection drbd-options alpha charlie backups --protocol A # linstor resource-connection drbd-options bravo charlie backups --protocol A
Please contact LINBIT for assistance optimizing your configuration.
2.13.4. DRBD プロキシを自動的に有効にする
LINSTOR can also be configured to automatically enable the above mentioned Proxy connection between two nodes. For this automation, LINSTOR first needs to know on which site each node is.
# linstor node set-property alpha Site A # linstor node set-property bravo Site A # linstor node set-property charlie Site B
As the Site
property might also be used for other site-based decisions in
future features, the DrbdProxy/AutoEnable
also has to be set to true
:
# linstor controller set-property DrbdProxy/AutoEnable true
This property can also be set on node, resource-definition, resource and resource-connection level (from left to right in increasing priority, whereas the controller is the left-most, that is, the least prioritized level). Once this initialization steps are completed, every newly created resource will automatically check if it has to enable DRBD proxy to any of its peer-resources. [[s-linstor-external-database]] === 外部データベースプロバイダー It is possible to have LINSTOR working with an external database provider like PostgreSQL, MariaDB and since version 1.1.0 even etcd key value store is supported. To use an external database there are a few additional steps to configure. You have to create a DB/Schema and user to use for linstor, and configure this in the `/etc/linstor/linstor.toml`. [[s-postgresql]] ==== PostgreSQL
A sample PostgreSQL linstor.toml
looks like this:
[db] user = "linstor" password = "linstor" connection_url = "jdbc:postgresql://localhost/linstor"
[[s-mariadb_mysql]] ==== MariaDB and MySQL
A sample MariaDB linstor.toml
looks like this:
[db] user = "linstor" password = "linstor" connection_url = "jdbc:mariadb://localhost/LINSTOR?createDatabaseIfNotExist=true"
NOTE: The LINSTOR schema/database is created as `LINSTOR` so verify that the MariaDB connection string refers to the `LINSTOR` schema, as in the example above. [[s-etcd]] ==== etcd
etcd is a distributed key-value store that makes it easy to keep your LINSTOR database distributed in a HA-setup.
The etcd driver is already included in the LINSTOR-controller package and only needs to be configured in the linstor.toml
.
More information about how to install and configure etcd can be found here: etcd docs
And here is a sample [db] section from the linstor.toml
:
[db] ## only set user/password if you want to use authentication, only since LINSTOR 1.2.1 # user = "linstor" # password = "linstor" ## for etcd ## do not set user field if no authentication required connection_url = "etcd://etcdhost1:2379,etcdhost2:2379,etcdhost3:2379" ## if you want to use TLS, only since LINSTOR 1.2.1 # ca_certificate = "ca.pem" # client_certificate = "client.pem" ## if you want to use client TLS authentication too, only since LINSTOR 1.2.1 # client_key_pkcs8_pem = "client-key.pkcs8" ## set client_key_password if private key has a password # client_key_password = "mysecret"
[[s-linstor-controller-config]] === 複数のLINSTORコントローラー The LINSTOR Controller has a configuration file that is and has to be placed into the following path: `/etc/linstor/linstor.toml`. A recent configuration example can be found here: https://github.com/LINBIT/linstor-server/blob/master/docs/linstor.toml-example[linstor.toml-example]
2.13.5. LINSTOR REST API
To make LINSTOR’s administrative tasks more accessible and also available for web-frontends a
REST API has been created. The REST API is embedded in the linstor-controller
and since LINSTOR 0.9.13 configured through the linstor.toml
configuration file.
[http] enabled = true port = 3370 listen_addr = "127.0.0.1" # to disable remote access
If you want to use the REST API the current documentation can be found on the following link: https://app.swaggerhub.com/apis-docs/Linstor/Linstor/
2.13.6. LINSTOR REST API HTTPS
The HTTP REST API can also run secured by HTTPS and is highly recommended if you use any features that require authorization. To do so you have to create a Java keystore file with a valid certificate that will be used to encrypt all HTTPS traffic.
Here is a simple example on how you can create a self signed certificate with the keytool
that is included
in the Java Runtime:
keytool -keyalg rsa -keysize 2048 -genkey -keystore ./keystore_linstor.jks\ -alias linstor_controller\ -dname "CN=localhost, OU=SecureUnit, O=ExampleOrg, L=Vienna, ST=Austria, C=AT"
keytool
will ask for a password to secure the generated keystore file and is needed for the
LINSTOR Controller configuration.
In your linstor.toml
file you have to add the following section:
[https] keystore = "/path/to/keystore_linstor.jks" keystore_password = "linstor"
Now (re)start the `linstor-controller` and the HTTPS REST API should be available on port 3371. More information about how to import other certificates can be found here: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html NOTE: When HTTPS is enabled, all requests to the HTTP /v1/ REST API will be redirected to the HTTPS redirect. [[s-rest-api-https-restricted-client]] ===== LINSTOR REST-API HTTPS 制限付きクライアントアクセス
Client access can be restricted by using a SSL/TLS truststore on the Controller. Basically you create a certificate for your client and add it to your truststore and the client then uses this certificate for authentication.
First create a client certificate:
keytool -keyalg rsa -keysize 2048 -genkey -keystore client.jks\ -storepass linstor -keypass linstor\ -alias client1\ -dname "CN=Client Cert, OU=client, O=Example, L=Vienna, ST=Austria, C=AT"
Then we import this certificate to our controller truststore:
keytool -importkeystore\ -srcstorepass linstor -deststorepass linstor -keypass linstor\ -srckeystore client.jks -destkeystore trustore_client.jks
And enable the truststore in the linstor.toml
configuration file:
[https] keystore = "/path/to/keystore_linstor.jks" keystore_password = "linstor" truststore = "/path/to/trustore_client.jks" truststore_password = "linstor"
Now restart the Controller and it will no longer be possible to access the controller API without a correct certificate.
The LINSTOR client needs the certificate in PEM format, so before we can use it we have to convert the java keystore certificate to the PEM format.
# Convert to pkcs12 keytool -importkeystore -srckeystore client.jks -destkeystore client.p12\ -storepass linstor -keypass linstor\ -srcalias client1 -srcstoretype jks -deststoretype pkcs12 # use openssl to convert to PEM openssl pkcs12 -in client.p12 -out client_with_pass.pem
To avoid entering the PEM file password all the time it might be convenient to remove the password.
openssl rsa -in client_with_pass.pem -out client1.pem openssl x509 -in client_with_pass.pem >> client1.pem
Now this PEM file can easily be used in the client:
linstor --certfile client1.pem node list
The `--certfile` parameter can also added to the client configuration file, see <<s-using_the_linstor_client>> for more details.
2.14. LINSTOR Satellite の設定
The LINSTOR Satellite software has an optional configuration file that uses the TOML file syntax and has to be put into the following path `/etc/linstor/linstor_satellite.toml`. A recent configuration example can be found here: https://github.com/LINBIT/linstor-server/blob/master/docs/linstor_satellite.toml-example[linstor_satellite.toml-example]
2.15. ロギング
LINSTOR uses SLF4J with Logback as binding. This gives
LINSTOR the possibility to distinguish between the log levels ERROR
, WARN
, INFO
, DEBUG
and TRACE
(in order of increasing verbosity). In the current linstor version (1.1.2) the user has the following
four methods to control the logging level, ordered by priority (first has highest priority):
-
TRACE
mode can beenabled
ordisabled
using the debug console:Command ==> SetTrcMode MODE(enabled) SetTrcMode Set TRACE level logging mode New TRACE level logging mode: ENABLED
-
When starting the controller or satellite a command line argument can be passed:
java ... com.linbit.linstor.core.Controller ... --log-level TRACE java ... com.linbit.linstor.core.Satellite ... --log-level TRACE
-
The recommended place is the
logging
section in the configuration file. The default configuration file location is/etc/linstor/linstor.toml
for the controller and/etc/linstor/linstor_satellite.toml
for the satellite. Configure the logging level as follows:[logging] level="TRACE"
-
As LINSTOR is using Logback as an implementation,
/usr/share/linstor-server/lib/logback.xml
can also be used. Currently only this approach supports different log levels for different components, like shown in the example below:<?xml version="1.0" encoding="UTF-8"?> <configuration scan="false" scanPeriod="60 seconds"> <!-- Values for scanPeriod can be specified in units of milliseconds, seconds, minutes or hours https://logback.qos.ch/manual/configuration.html --> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <!-- encoders are assigned the type ch.qos.logback.classic.encoder.PatternLayoutEncoder by default --> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern> </encoder> </appender> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${log.directory}/linstor-${log.module}.log</file> <append>true</append> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <Pattern>%d{yyyy_MM_dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</Pattern> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <FileNamePattern>logs/linstor-${log.module}.%i.log.zip</FileNamePattern> <MinIndex>1</MinIndex> <MaxIndex>10</MaxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <MaxFileSize>2MB</MaxFileSize> </triggeringPolicy> </appender> <logger name="LINSTOR/Controller" level="TRACE" additivity="false"> <appender-ref ref="STDOUT" /> <!-- <appender-ref ref="FILE" /> --> </logger> <logger name="LINSTOR/Satellite" level="TRACE" additivity="false"> <appender-ref ref="STDOUT" /> <!-- <appender-ref ref="FILE" /> --> </logger> <root level="WARN"> <appender-ref ref="STDOUT" /> <!-- <appender-ref ref="FILE" /> --> </root> </configuration>
See the https://logback.qos.ch/manual/index.html[Logback Manual] to find more details about `logback.xml`. When none of the configuration methods above is used LINSTOR will default to `INFO` log level.
=== 監視
Since LINSTOR 1.8.0, a Prometheus /metrics
HTTP path is provided with LINSTOR and JVM specific
exports.
The /metrics
path also supports three GET arguments to reduce LINSTOR’s reported data:
-
resource
-
storage_pools
-
error_reports
These all default to true
. To disable, for example error report data: http://localhost:3370/metrics?error_reports=false
2.15.1. ヘルスチェック
The LINSTOR-Controller also provides a `/health` HTTP path that will simply return HTTP-Status 200 if the controller can access its database and all services are up and running. Otherwise it will return HTTP error status code 500 `Internal Server Error`. [[s-linstor-secure-connections]] === サテライトへの安全な接続
It is possible to have the LINSTOR use SSL/TLS secure TCP connection between controller and satellite connections.
Without going into further details on how Java’s SSL/TLS engine works we will give you
command line snippets using the keytool
from Java’s runtime environment on how to configure
a three node setup using secure connections.
The node setup looks like this:
Node alpha
is the just the controller.
Node bravo
and node charlie
are just satellites.
Here are the commands to generate such a keystore setup, values should of course be edited for your environment.
# create directories to hold the key files mkdir -p /tmp/linstor-ssl cd /tmp/linstor-ssl mkdir alpha bravo charlie # create private keys for all nodes keytool -keyalg rsa -keysize 2048 -genkey -keystore alpha/keystore.jks\ -storepass linstor -keypass linstor\ -alias alpha\ -dname "CN=Max Mustermann, OU=alpha, O=Example, L=Vienna, ST=Austria, C=AT" keytool -keyalg rsa -keysize 2048 -genkey -keystore bravo/keystore.jks\ -storepass linstor -keypass linstor\ -alias bravo\ -dname "CN=Max Mustermann, OU=bravo, O=Example, L=Vienna, ST=Austria, C=AT" keytool -keyalg rsa -keysize 2048 -genkey -keystore charlie/keystore.jks\ -storepass linstor -keypass linstor\ -alias charlie\ -dname "CN=Max Mustermann, OU=charlie, O=Example, L=Vienna, ST=Austria, C=AT" # import truststore certificates for alpha (needs all satellite certificates) keytool -importkeystore\ -srcstorepass linstor -deststorepass linstor -keypass linstor\ -srckeystore bravo/keystore.jks -destkeystore alpha/certificates.jks keytool -importkeystore\ -srcstorepass linstor -deststorepass linstor -keypass linstor\ -srckeystore charlie/keystore.jks -destkeystore alpha/certificates.jks # import controller certificate into satellite truststores keytool -importkeystore\ -srcstorepass linstor -deststorepass linstor -keypass linstor\ -srckeystore alpha/keystore.jks -destkeystore bravo/certificates.jks keytool -importkeystore\ -srcstorepass linstor -deststorepass linstor -keypass linstor\ -srckeystore alpha/keystore.jks -destkeystore charlie/certificates.jks # now copy the keystore files to their host destinations ssh [email protected] mkdir /etc/linstor/ssl scp alpha/* [email protected]:/etc/linstor/ssl/ ssh [email protected] mkdir /etc/linstor/ssl scp bravo/* [email protected]:/etc/linstor/ssl/ ssh [email protected] mkdir /etc/linstor/ssl scp charlie/* [email protected]:/etc/linstor/ssl/ # generate the satellite ssl config entry echo '[netcom] type="ssl" port=3367 server_certificate="ssl/keystore.jks" trusted_certificates="ssl/certificates.jks" key_password="linstor" keystore_password="linstor" truststore_password="linstor" ssl_protocol="TLSv1.2" ' | ssh [email protected] "cat > /etc/linstor/linstor_satellite.toml" echo '[netcom] type="ssl" port=3367 server_certificate="ssl/keystore.jks" trusted_certificates="ssl/certificates.jks" key_password="linstor" keystore_password="linstor" truststore_password="linstor" ssl_protocol="TLSv1.2" ' | ssh [email protected] "cat > /etc/linstor/linstor_satellite.toml"
Now just start controller and satellites and add the nodes with `--communication-type SSL`. [[s-linstor-ldap-authentication]] === LDAP 認証の設定
You can configure LINSTOR to use LDAP authentication to limit access to the LINSTOR Controller.
This feature is disabled by default but you can enable and configure it by editing the
LINSTOR configuration TOML file. After editing the configuration file, you will need to restart
the linstor-controller.service
. An example LDAP section within the configuration file looks
like this:
[ldap] enabled = true (1) # allow_public_access: if no authorization fields are given allow # users to work with the public context allow_public_access = false (2) # uniform resource identifier: LDAP URI to use # for example, "ldaps://hostname" (LDAPS) or "ldap://hostname" (LDAP) uri = "ldaps://ldap.example.com" # distinguished name: {user} can be used as template for the user name dn = "uid={user}" (3) # search base for the search_filter field search_base = "dc=example,dc=com" (4) # search_filter: ldap filter to restrict users on memberships search_filter = "(&(uid={user})(memberof=ou=storage-services,dc=example,dc=com))" (5)
1 | enabled is a Boolean value. Authentication is disabled by default. |
2 | allow_public_access is a Boolean value. If set to true, and LDAP authentication is
enabled, then users will be allowed to work with the LINSTOR Controller’s public context. If
set to false and LDAP authentication is enabled, then users without LDAP authenticating
credentials will be unable to access the LINSTOR Controller for all but the most trivial tasks,
such as displaying version or help information. |
3 | dn is a string value where you can specify the LDAP distiguished name to query the LDAP
directory. Besides the user ID (uid ), the string may consist of other distinguished name
attributes, for example:
dn = "uid={user},ou=storage-services,o=ha,dc=example" |
4 | search_base is a string value where you can specify the starting point in the LDAP
directory tree for the authentication query, for example:
search_base = "ou=storage-services" |
5 | search_filter is a string value where you can specify an LDAP object restriction for
authentication, such as user and group membership, for example:
search_filter = "(&(uid={user})(memberof=ou=storage-services,dc=example,dc=com))" WARNING: It is highly recommended that you configure <<s-linstor-rest-api-https,LINSTOR REST API HTTPS>> and LDAPS to protect potentially sensitive traffic passing between the LINSTOR Controller and an LDAP server. |
2.15.2. 認証ユーザとしてのLINSTORコマンドの実行
After configuring the LINSTOR Controller to authenticate users through LDAP (or LDAPS), and the LINSTOR REST API HTTPS, you will need to enter LINSTOR commands as follows:
$ linstor --user <LDAP_user_name> <command>
If you have configured LDAP authentication without also configuring LINSTOR REST API
HTTPS, you will need to explicitly enable password authentication over HTTP, by using the --allow-insecure-path
flag with your linstor
commands. This is not recommended outside of a secured and isolated LAN, as you will be sending credentials in plain text.
$ linstor --allow-insecure-auth --user <LDAP_user_name> <command>
The LINSTOR Controller will prompt you for the user's password, in each of the above examples. You may optionally use the `--password` argument to supply the user's password on the command line, with all the warnings of caution that would go along with doing so. [[s-linstor-drbd-automatisms]] === Automatisms for DRBD Resources This section details some of LINSTOR's automatisms for DRBD resources.
2.15.3. 自動クォーラムポリシー
LINSTOR automatically configures quorum policies on resources when quorum is achievable. This means, whenever you have at least two diskful and one or more diskless resource assignments, or three or more diskful resource assignments, LINSTOR will enable quorum policies for your resources automatically.
Inversely, LINSTOR will automatically disable quorum policies whenever there are less than the minimum required resource assignments to achieve quorum.
This is controlled through the, DrbdOptions/auto-quorum
, property which
can be applied to the linstor-controller, resource-group, and
resource-definition. Accepted values for the
DrbdOptions/auto-quorum
property are disabled
, suspend-io
, and
io-error
.
Setting the DrbdOptions/auto-quorum
property to disabled
will
allow you to manually, or more granularly, control the quorum policies
of your resources should you want to.
The default policies for DrbdOptions/auto-quorum are quorum
majority , and on-no-quorum io-error . For more information about DRBD’s
quorum features and their behavior, please refer to the
quorum section of the DRBD user’s guide.
|
The DrbdOptions/auto-quorum policies will override any
manually configured properties if DrbdOptions/auto-quorum is not disabled.
|
For example, to manually set the quorum policies of a resource-group
named my_ssd_group
, you would use the following commands:
# linstor resource-group set-property my_ssd_group DrbdOptions/auto-quorum disabled # linstor resource-group set-property my_ssd_group DrbdOptions/Resource/quorum majority # linstor resource-group set-property my_ssd_group DrbdOptions/Resource/on-no-quorum suspend-io
You may want to disable DRBD’s quorum features completely. To do that,
you would need to first disable DrbdOptions/auto-quorum
on the
appropriate LINSTOR object, and then set the DRBD quorum features
accordingly. For example, use the following commands to disable quorum
entirely on the my_ssd_group
resource-group:
# linstor resource-group set-property my_ssd_group DrbdOptions/auto-quorum disabled # linstor resource-group set-property my_ssd_group DrbdOptions/Resource/quorum off # linstor resource-group set-property my_ssd_group DrbdOptions/Resource/on-no-quorum
NOTE: Setting `DrbdOptions/Resource/on-no-quorum` to an empty value in the commands above deletes the property from the object entirely.
2.15.4. 自動取り除き
If a satellite is offline for a prolonged period of time, LINSTOR can be configured to declare that node as evicted. This triggers an automated reassignment of the affected DRBD resources to other nodes to ensure a minimum replica count is kept.
This feature uses the following properties to adapt the behaviour.
-
DrbdOptions/AutoEvictMinReplicaCount
sets the number of replicas that should always be present. You can set this property on the controller to change a global default, or on a specific resource-definition or resource-group to change it only for that resource-definition or resource-group. If this property is left empty, the place-count set for the auto-placer of the corresponding resource-group will be used. -
DrbdOptions/AutoEvictAfterTime
describes how long a node can be offline in minutes before the eviction is triggered. You can set this property on the controller to change a global default, or on a single node to give it a different behavior. The default value for this property is 60 minutes. -
DrbdOptions/AutoEvictMaxDisconnectedNodes
sets the percentage of nodes that can be not reachable (for whatever reason) at the same time. If more than the given percent of nodes are offline at the same time, the auto-evict will not be triggered for any node , since in this case LINSTOR assumes connection problems from the controller. This property can only be set for the controller, and only accepts a value between 0 and 100. The default value is 34. If you want to turn the auto-evict-feature off, simply set this property to 0. If you want to always trigger the auto-evict, regardless of how many satellites are unreachable, set it to 100. -
DrbdOptions/AutoEvictAllowEviction
is an additional property that can stop a node from being evicted. This can be useful for various cases, for example if you need to shut down a node for maintenance. You can set this property on the controller to change a global default, or on a single node to give it a different behavior. It accepts true and false as values and per default is set to true on the controller. You can use this property to turn the auto-evict feature off by setting it to false on the controller, although this might not work completely if you already set different values for individual nodes, since those values take precedence over the global default.
After the linstor-controller loses the connection to a satellite, aside from trying to
reconnect, it starts a timer for that satellite. As soon as that timer exceeds
DrbdOptions/AutoEvictAfterTime
and all of the DRBD-connections to the DRBD-resources
on that satellite are broken, the controller will check whether or not
DrbdOptions/AutoEvictMaxDisconnectedNodes
has been met. If it hasn’t, and
DrbdOptions/AutoEvictAllowEviction
is true for the node in question, the satellite
will be marked as EVICTED. At the same time, the controller will check for every DRBD-resource whether
the number of resources is still above DrbdOptions/AutoEvictMinReplicaCount
. If it is,
the resource in question will be marked as DELETED. If it isn’t, an auto-place with the settings
from the corresponding resource-group will be started. Should the auto-place fail, the
controller will try again later when changes that might allow a different result, such
as adding a new node, have happened. Resources where an auto-place is necessary will only be
marked as DELETED if the corresponding auto-place was successful.
The evicted satellite itself will not be able to reestablish connection with the controller. Even if the node is up and running, a manual reconnect will fail. It is also not possible to delete the satellite, even if it is working as it should be. The satellite can, however, be restored. This will remove the EVICTED-flag from the satellite and allow you to use it again. Previously configured network interfaces, storage pools, properties and similar entities as well as non-DRBD-related resources and resources that could not be autoplaced somewhere else will still be on the satellite. To restore a satellite, use
# linstor node restore [nodename]
Should you want to instead throw everything that once was on that node, including the node itself, away, you need to use the `node lost` command instead. [[s-linstor-auto-diskful]] ==== Auto-Diskful and Related Options You can set the LINSTOR `auto-diskful` and `auto-diskful-allow-cleanup` properties for various LINSTOR objects, for example, a resource definition, to have LINSTOR help automatically make a _Diskless_ node _Diskful_ and perform appropriate cleanup actions afterwards. This is useful when a _Diskless_ node has been in a _Primary_ state for a DRBD resource for more than a specified number of minutes. This could happen in cases where you integrate LINSTOR managed storage with other orchestrating and scheduling platforms, such as OpenStack, OpenNebula, and others. On some platforms that you integrate LINSTOR with, you might not have a way to influence where in your cluster a storage volume will be used. The auto-diskful options give you a way to use LINSTOR to sensibly delegate the roles of your storage nodes in response to an integrated platform's actions that are beyond your control. [[s-linstor-auto-diskful-setting]] ===== Setting the Auto-Diskful Option
By setting the DrbdOptions/auto-diskful
option on a LINSTOR resource definition , you are
configuring the LINSTOR controller to make a Diskless DRBD resource Diskful if the resource
has been in a DRBD Primary state for more than the specified number of minutes. After the
specified number of minutes, LINSTOR will automatically use the
resource toggle-disk
command to toggle the resource state on the
Diskless node, for the given resource.
To set this property, for example, on a LINSTOR resource definition named myres
with a
threshold of five minutes, enter the command:
# linstor resource-definition set-property myres DrbdOptions/auto-diskful 5
[[s-linstor-auto-diskful-setting-on-rg-or-controller]] ===== Setting the Auto-Diskful Option on a Resource Group or Controller You can also set the `DrbdOptions/auto-diskful` option on LINSTOR `controller` or `resource-group` objects. By setting the option at the controller level, the option will affect all LINSTOR resource definitions in your LINSTOR cluster that do not have this option set, either on the resource definition itself, or else on the resource group that you might have created the resource from. Setting the option on a LINSTOR resource group will affect all resource definitions that are spawned from the group, unless a resource definition has the option set on it. The order of priority, from highest to lowest, for the effect of setting the `auto-diskful` option is: - Resource definition - Resource group - Controller [[s-linstor-auto-diskful-unsetting]] ===== Unsetting the Auto-Diskful Option
To unset the LINSTOR auto-diskful
option, enter:
# linstor <controller|resource-definition|resource-group> set-property DrbdOptions/auto-diskful
[[s-linstor-auto-diskful-allow-cleanup-setting]] ===== Setting the Auto-Diskful-Allow-Cleanup Option A companion option to the LINSTOR `auto-diskful` option is the `DrbdOptions/auto-diskful-allow-cleanup` option. You can set this option on the following LINSTOR objects: node, resource, resource definition, or resource group. The default value for this option is `True`, but the option has no effect unless the `auto-diskful` option has also been set. After LINSTOR has toggled a resource to _Diskful_, because the threshold number of minutes has passed where a _Diskless_ node was in the _Primary_ role for a resource, and after DRBD has synchronized the data to this previously _Diskless_ and now _Primary_ node, LINSTOR will remove the resource from any _Secondary_ nodes when that action is necessary to fulfill a replica count constraint that the resource might have. This could be the case, for example, if you have specified a number of replicas for a resource by using the `--auto-place` option. [s-linstor-qos]] === QoS設定 LINSTOR implements QoS for managed resources by using sysfs properties that correspond to kernel variables related to block I/O operations. These sysfs properties can be limits on either bandwidth (bytes per second), or IOPS, or both. The sysfs files and their corresponding LINSTOR properties are as follows: [cols="3,2"]
sysfs (/sys/fs/ ) |
LINSTOR Property |
---|---|
|
|
|
|
|
|
|
|
2.15.5. LINSTOR sysfsのプロパティを使ったQoSの設定
これらのLINSTORプロパティは set-property
コマンドを使用して設定することができ、次のオブジェクトに設定することができます:ボリューム、ストレージプール、リソース、コントローラ、またはノード。また、リソースグループ、ボリュームグループ、リソース定義、またはボリューム定義にこれらのQoSプロパティを設定することができます。
グループまたは定義にQoSプロパティを設定すると、そのグループまたは定義から作成されたリソースは、QoS設定を継承します。
グループまたは定義に対して行われた設定は、グループまたは定義から作成された既存のリソースと新しいリソースの両方に影響します。 |
次の例では、リソースグループを作成し、ボリュームグループを作成し、ボリュームグループにQoS設定を適用し、リソースグループからリソースをスポーンしています。検証コマンドを実行すると、スポーンされたリソースがQoS設定を継承していることがわかります。 この例では、_pool1_という名前の以前に作成されたLINSTORストレージプールを想定して使用します。この名前は、あなたの環境に存在するストレージプール名に置き換える必要があります。
# linstor resource-group create qos_limited --storage-pool pool1 --place-count 3 # linstor volume-group create qos_limited # linstor volume-group set-property qos_limited 0 sys/fs/blkio_throttle_write 1048576 # linstor resource-group spawn-resources qos_limited qos_limited_res 200M
生成されたリソースがQoS設定を継承していることを確認するには、ストレージプールにストレージを提供するノードで、対応するsysfsファイルの内容を表示します。
# cat /sys/fs/cgroup/blkio/blkio.throttle.write_bps_device 252:4 1048576
QoS プロパティは継承されコピーされないため、 “parent” グループまたは定義から生成された “child” オブジェクトにはプロパティが表示されません。 |
2.15.6. 複数の DRBD デバイスを持つ LINSTOR ボリュームの QoS 設定
単一の LINSTOR ボリュームは、複数の DRBD デバイスで構成できます。たとえば、外部メタデータを含む DRBD には、データ (ストレージ)
デバイス、メタデータ デバイス、および LINSTOR に提供される複合 DRBD デバイス (ボリューム) の 3
つの下位デバイスがあります。データデバイスとメタデータデバイスが異なる下位ディスクに対応している場合、そのような LINSTOR ボリュームに
sysfs プロパティを設定すると、ローカルデータ (ストレージ) 下位デバイスのみが対応する /sys/fs/cgroup/blkio/
ファイルのプロパティ値を受け取ります。DRBD メタデータの下位デバイスや、LINSTOR
で提供される複合下位デバイスは値を受け取りません。ただし、DRBD のデータとそのメタデータが同じ下位ディスクを共有する場合、QoS
設定はデータとメタデータ操作の両方のパフォーマンスに影響します。
2.15.7. NVMe の QoS設定
LINSTOR リソース定義に nvme-target
リソースと nvme-initiator
リソースがある場合、各ノードの両方のデータ
(ストレージ) 下位デバイスが sysfs プロパティ値を受け取ります。ターゲットの場合、データ下位デバイスは LVM または ZFS
のいずれかのボリュームになりますが、イニシエータの場合、LUKS、NVMe、DRBD などの他の LINSTOR
レイヤーに関係なく、データ下位デバイスは接続された nvme-device
になります( DRBDを使わないLINSTOR
を参照ください)。
2.16. ヘルプの利用
2.16.1. コマンドラインから確認
コマンドラインで利用可能なコマンドを確認するには linstor
とタイプします。
サブコマンドのさらなる情報は次の2つの方法で確認できます。
# linstor node list -h # linstor help node list
LINSTOR がインタラクティブモード( linstor interactive
)で動作しているときには ‘help’
サブコマンドはとても役にたちます。
LINSTORで役に立つ機能の1つに豊富なタブ補完機能があります。これはLINSTORが認識する基本的なすべてのオブジェクト(例えばノード名、IPアドレス、リソース名など)を完成させるために使用できます。以下の例では、いくつかの可能な補完とその結果を示します。
# linstor node create alpha 1<tab> # ホスト名が解決できるとIPアドレスを補完します # linstor resource create b<tab> c<tab> # linstorは backups, charlieリソースを補完します
タブ補完機能が動作しない場合は以下のファイルをソースしてください。
# source /etc/bash_completion.d/linstor # または # source /usr/share/bash_completion/completions/linstor
zsh ユーザのためにlinstor-clientはzshタブ補完機能用のファイルを生成できます。これはコマンドと引数の基本的なサポート機能です。
# linstor gen-zsh-completer > /usr/share/zsh/functions/Completion/Linux/_linstor
2.16.2. SOS レポート
何か問題が発生し、問題の原因を見つけるのに助けが必要な場合は、以下のコマンド使用します。
# linstor sos-report create
上記のコマンドは、コントローラーノードの /var/log/linstor/controller/
に新しい sos-report
を作成します。または、以下のコマンドも使用できます。
# linstor sos-report download
これにより、新しい sos-report が作成され、さらにそのレポートがローカルマシンの現在の作業ディレクトリにダウンロードされます。
この sos-report には、いくつかのソース(Linstor-logs, dmesg
, 外部ツールのバージョン, ip a
,
データベースダンプなど)からのログと有用なデバッグ情報が含まれています。これらの情報はノードごとにプレーンテキストで .tar.gz
ファイルに保存されます。
2.16.3. コミュニティの助けを借りる
コミュニティの助けを借りるには https://lists.linbit.com/listinfo/drbd-user にあるメーリングリストを購読してください。
2.16.4. GitHub
バグや機能要求を提出するには、GitHubページ https://github.com/linbit を確認してください。
2.16.5. 有料のサポートと開発
リモートインストールサービス、24時間365日のサポート、認定リポジトリへのアクセス、または機能開発をご希望の場合は、1-877-454-6248(1-877-4LINBIT)、International:43-1-8178292 -0 | [email protected] にお問い合わせください。
3. Kubernetes で LINSTOR ボリューム
この章では、オペレーターによって管理され、 LINSTOR CSI plugin を使用してプロビジョニングされた KubernetesのLINSTORボリュームについて説明します。
この章では、LINSTOR と Kubernetes で可能なすべてのインストールオプションとさまざまな構成について詳しく説明します。テスト目的で「クイックスタート」に興味がある方、または参照用の例を探している方は、この章の終わり近くの Helm インストール例 を参照ください。
3.1. Kubernetesの概要
Kubernetes_は、コンテナオーケストレーターです。Kubernetes
は、宣言した仕様に基づいてコンテナと関連サービスの動作を定義します。このガイドでは、Kubernetes オブジェクトの仕様を定義する AML
ファイルを介して kubectl
を使用することに焦点を当てます。
3.2. Kubernetes への LINSTOR のデプロイ
LINBITは、商用サポートのお客様向けにLINSTOR Operatorを提供しています。 Operatorは、DRBDのインストール、SatelliteとControllerポッドの管理など、Kubernetes上でのLINSTORの導入を容易にするものです。
LINBIT’s container image repository (https://drbd.io), used by LINSTOR Operator, is only available to LINBIT customers or through LINBIT customer trial accounts. Contact LINBIT for information on pricing or to begin a trial. Alternatively, you may use LINSTOR SDS’ upstream project named Piraeus, without being a LINBIT customer. |
LINSTOR Operator v2 is the recommended way of deploying LINBIT SDS for Kubernetes on new clusters. Users of existing Operator v1 deployments should continue to use their Helm deployments, skipping to the Operator v1 instructions.
3.2.1. Deploying LINSTOR Operator v2
LINSTOR Operator v2 is deployed using
kustomize
tool, integrated with kubectl
.
Prerequisites for LINSTOR Operator v2
To deploy LINSTOR Operator v2, you need to meet the following prerequisites:
-
Install
cert-manager
. You can quickly installcert-manager
by applying its static manifests:kubectl apply -f https://github.com/cert-manager/cert-manager/releases/latest/download/cert-manager.yaml
-
Have your my.linbit.com credentials ready.
Creating the Operator
To deploy the Operator, create a kustomization.yaml
file. This will
declare your pull secret for drbd.io
and allow you to pull in the Operator
deployment. The Operator will be deployed in a new namespace linbit-sds
.
Make sure to replace MY_LINBIT_USER
and MY_LINBIT_PASSWORD
with your own
credentials.
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: linbit-sds
resources:
- https://github.com/LINBIT/linstor-operator-builder//deploy/default?ref=v2.0.1
generatorOptions:
disableNameSuffixHash: true
secretGenerator:
- name: drbdio-pull-secret
type: kubernetes.io/dockerconfigjson
literals:
- .dockerconfigjson={"auths":{"drbd.io":{"username":"MY_LINBIT_USER","password":"MY_LINBIT_PASSWORD"}}}
Then, apply the kustomization.yaml
file, by using kubectl
command, and
wait for the Operator to start:
$ kubectl apply -k . namespace/linbit-sds created ... $ kubectl -n linbit-sds wait pod --for=condition=Ready --all pod/linstor-operator-controller-manager-6d9847d857-zc985 condition met
The Operator is now ready to deploy LINBIT SDS for Kubernetes.
Deploying LINBIT SDS for Kubernetes
Deploying LINBIT SDS for Kubernetes with the Operator is a simple as
creating a new LinstorCluster
resource and waiting for the Operator to
complete the setup:
$ kubectl create -f - <<EOF apiVersion: piraeus.io/v1 kind: LinstorCluster metadata: name: linstorcluster spec: {} EOF $ kubectl wait pod --for=condition=Ready -n linbit-sds --timeout=3m --all pod/ha-controller-4tgcg condition met pod/k8s-1-26-10.test condition met pod/linstor-controller-76459dc6b6-tst8p condition met pod/linstor-csi-controller-75dfdc967d-dwdx6 condition met pod/linstor-csi-node-9gcwj condition met pod/linstor-operator-controller-manager-6d9847d857-zc985 condition met
ストレージの構成
By default, LINBIT SDS for Kubernetes does not configure any storage. To add
storage, you can configure a LinstorSatelliteConfiguration
, which the
Operator uses to configure one or more satellites.
The following example creates a simple FILE_THIN
pool and it does not
require any additional set up on the host:
$ kubectl apply -f - <<EOF apiVersion: piraeus.io/v1 kind: LinstorSatelliteConfiguration metadata: name: storage-pool spec: storagePools: - name: pool1 fileThinPool: directory: /var/lib/linbit-sds/pool1 EOF
Other types of storage pools can be configured as well. Please check the examples upstream.
Next Steps
After deploying LINBIT SDS for Kubernetes, you can continue with the guide for creating basic volumes, or refer to the available tutorials and how-to guides upstream.
3.2.2. Deploying LINSTOR Operator v1
If you plan to deploy LINSTOR Operator on a new cluster, you should use Operator v2. |
The Operator v1 is installed using a Helm v3 chart as follows:
-
my.linbit.com 認証情報を含む kubernetes シークレットを作成します。
kubectl create secret docker-registry drbdiocred --docker-server=drbd.io \ --docker-username=<YOUR_LOGIN> --docker-email=<YOUR_EMAIL> --docker-password=<YOUR_PASSWORD>
このシークレットの名前は、Helm で指定されたものと一致する必要があります。デフォルトは
drbdiocred
です。 -
LINSTORデータベースのバックエンドを設定します。デフォルトでは、チャートはデータベースとしてetcdを設定します。Operator は、LINSTORが Kubernetes as datastore を直接使用するように設定することも可能です。etcd を使う場合は、etcd 用に永続的ストレージを設定します。
-
デフォルトの
StorageClass
で既存のストレージプロビジョナーを使用する。 -
hostPath
ボリューム を使用する。 -
基本的なテストのみで永続化を無効にします。これは以下の
helm install
コマンドに--set etcd.persistentVolume.enabled=false
を追加することで実行できます。
-
-
ストレージの構成 を確認し、LINSTOR の基本的なストレージを構成してください。
-
デプロイメントの保護に関するセクション を参照して、必要に応じて設定します。
-
最後のステップとして
helm install
コマンドで--set
を使用して、適切なカーネルモジュールインジェクタを選択します。-
使用しているディストリビューションに応じてインジェクターを選択してください。 http://drbd.io/ から、
drbd9-rhel7
,drbd9-rhel8
, … 等の最新バージョンを適宜選択します。drbd9-rhel8 イメージは、RHCOS(OpenShift) でも使用します。SUSE CaaS プラットフォームの場合、使用している CaaS プラットフォームのシステムと一致する SLES インジェクターを使用します(drbd9-sles15sp1
など)。例えば以下のようにします。operator.satelliteSet.kernelModuleInjectionImage=drbd.io/drbd9-rhel8:v9.1.8
-
ホストマシンに既に存在するモジュールのみを挿入します。モジュールが見つからない場合は、スキップされます。
operator.satelliteSet.kernelModuleInjectionMode=DepsOnly
-
他の方法で DRBD をインストールする場合は、カーネルモジュールインジェクションを無効にします。
DepsOnly
により非推奨になりました。operator.satelliteSet.kernelModuleInjectionMode=None
-
-
最後にすべてをセットアップする
linstor-op
という名前の Helm デプロイメントを作成します。helm repo add linstor https://charts.linstor.io helm install linstor-op linstor/linstor
詳細なデプロイメントのカスタマイズについては、advanced deployment section を参照ください。
LINSTOR向けKubernetesバックエンド
Controllerは、Kubernetes APIを直接使用して、クラスタの状態を永続化することができます。このバックエンドを有効にするには、チャートのインストール時に以下のオーバーライドファイルを使用します。
etcd:
enabled: false
operator:
controller:
dbConnectionURL: k8s
現在、etcd バックエンドを持つ既存のクラスタから Kubernetes バックエンドへの移行できません。 |
永続ストレージボリュームの作成
pv-hostpath
Helm テンプレートを使用して、 hostPath
永続ボリュームを作成できます。構成された etcd の
replicas
を満たすために必要な数の PV を作成します(デフォルト1)。
nodePath =
オプションでクラスターノード名を指定して hostPath
永続ボリュームを作成します。
helm repo add linstor https://charts.linstor.io helm install linstor-etcd linstor/pv-hostpath
デフォルトで PV はすべての control-plane
ノードに作成されます。インストールコマンドに --set
"nodes={<NODE0>,<NODE1>,NODE2>}"
を渡すことにより、ストレージノードを手動で選択できます。
ノードを参照するための正しい値は、kubernetes.io/hostname ラベルの値です。 kubectl get nodes -o
custom-columns="Name:{.metadata.name},NodeName:{.metadata.labels['kubernetes\.io/hostname']}"
を実行すると、全てのノードについてその値を一覧表示することができます。
|
既存のデータベースの使用
LINSTOR は既存の PostgreSQL、MariaDB、etcd データベースに接続できます。たとえば、次の構成は PostgresSQL インスタンスの場合です。
POSTGRES_DB: postgresdb POSTGRES_USER: postgresadmin POSTGRES_PASSWORD: admin123
Helm のインストールコマンドに以下を追加することにより、etcd クラスターをデプロイする代わりにこのデータベースを使用するように Helm チャートを構成できます。
--set etcd.enabled=false --set "operator.controller.dbConnectionURL=jdbc:postgresql://postgres/postgresdb?user=postgresadmin&password=admin123"
3.2.3. ストレージの構成
LINSTORオペレーターは、いくつかの基本的なストレージセットアップを自動化できます。
ストレージプール作成の構成
LINSTOR オペレーターを使用して、LINSTOR ストレージプールを作成できます。作成は LinstorSatelliteSet リソースの制御下にあります。
$ kubectl get LinstorSatelliteSet.linstor.linbit.com linstor-op-ns -o yaml
kind: LinstorSatelliteSet
metadata:
..
spec:
..
storagePools:
lvmPools:
- name: lvm-thick
volumeGroup: drbdpool
lvmThinPools:
- name: lvm-thin
thinVolume: thinpool
volumeGroup: ""
zfsPools:
- name: my-linstor-zpool
zPool: for-linstor
thin: true
インストール時のストレージプール作成
インストール時の helm install を実行するときに operator.satelliteSet.storagePools
の値を設定します。
まず、次のようなストレージ構成でファイルを作成します。
operator:
satelliteSet:
storagePools:
lvmPools:
- name: lvm-thick
volumeGroup: drbdpool
このファイルは、次のように helm インストールに渡すことができます。
helm install -f <file> linstor-op linstor/linstor
ストレージプール作成の構成
オペレーターがすでに構成されているクラスター(つまり、 helm install
の後)では、次のようにして LinstorSatelliteSet
構成を編集できます。
$ kubectl edit LinstorSatelliteSet.linstor.linbit.com <satellitesetname>
ストレージプールの構成は、上記の例のように更新できます。
物理デバイスの準備
デフォルトでは、LINSTOR は、参照される VolumeGroups, ThinPools などが存在することを想定しています。
devicePaths:[]
オプションを使用して、LINSTOR
がプール用にデバイスを自動的に準備できるようにすることができます。自動構成の対象となるのは、次のようなブロックデバイスです。
-
ルートデバイス(パーティションなし)
-
パーティション情報を含まない。
-
1 GiB 以上である。
デバイスの自動構成を有効にするには storagePools
エントリに devicePaths
キーを設定します。
storagePools:
lvmPools:
- name: lvm-thick
volumeGroup: drbdpool
devicePaths:
- /dev/vdb
lvmThinPools:
- name: lvm-thin
thinVolume: thinpool
volumeGroup: linstor_thinpool
devicePaths:
- /dev/vdc
- /dev/vdd
現在、このメソッドは LVM および LVMTHIN ストレージプールの作成をサポートしています。
LVM ストレージプールの設定
lvmPools
エントリで利用可能なキーは以下のとおりです。
-
name
LINSTOR ストレージプールの名前。必須 -
volumeGroup
作成する VG の名前。必須 -
devicePaths
このプール用に構成するデバイス。認識されるには、空で 1GiB 以上ある。オプション -
raidLevel
LVM RAID レベル。オプション -
vdo
[VDO]を有効にする(サテライトに VDO ツールが必要)。オプション -
vdoLogicalSizeKib
作成された VG のサイズ(VDO を使用することで下位デバイスよりも大きくなることが予想される)。オプション -
vdoSlabSizeKib
VDO のスラブサイズ。オプション
LVM Thin Poolの設定
-
name
LINSTOR ストレージプールの名前。必須 -
volumeGroup
シンプールに使用するVGです。devicePaths
を使用したい場合は、これを""
に設定します。 LINSTORではデバイスを準備する際にVG名を設定することができないため、これは必須です。thinVolume
シンプールの名前です。[必須]です。 -
devicePaths
このプール用に構成するデバイス。認識されるには、空で 1GiB 以上ある。オプション -
raidLevel
LVM RAID レベル。オプション
LVMTHIN プール用に LINSTOR によって作成されたボリュームグループは、常にスキーム “linstor_$THINPOOL” に従います。 |
ZFS ストレージプールの設定
-
name
LINSTOR ストレージプールの名前。必須 -
zPool
使用する zpool の名前。すべてのマシンにすでに存在している必要があります。必須 -
thin
シンプロビジョニングを使用するにはtrue
, 使用しないならfalse
を設定する。必須
automaticStorageType
の使用(非推奨)
すべての適切なデバイスは、すでに storagePools
セクションを使用して準備している場合を除き
operator.satelliteSet.automaticStorageType
の値に従って準備されます。デバイスは、デバイス名に基づいてストレージプールに追加さ>れます(つまり、すべての /dev/nvme1
デバイスはプール
autopool-nvme1
一部>になります)。
operator.satelliteSet.automaticStorageType
の可能な値は次のとおりです。
-
None
自動セットアップなし(デフォルト) -
LVM
LVM(シック)ストレージプールを作成 -
LVMTHIN
LVM thin ストレージプールを作成 -
ZFS
ZFS ベースストレージプールを作成 ( 未テスト )
3.2.4. 安全なデプロイメント
This section describes the different options for enabling security features available when using this operator. The following guides assume the operator is installed using Helm
既存の etcd インスタンスとの安全な通信
etcd
インスタンスへの安全な通信は、kubernetes シークレットの形式で CA
証明書をオペレーターに提供することで有効にできます。シークレットには、PEM エンコードされた CA 証明書を値として持つキー ca.pem
を含める必要があります。
次の引数を helm install
に渡すことで、シークレットをコントローラーに渡すことができます。
--set operator.controller.dbCertSecret=<secret name>
証明書を使用した etcd
での認証
TLS 証明書を使用して etcd
データベースで認証する場合は、helm インストールで次のオプションを設定します。
--set operator.controller.dbUseClientCert=true
このオプションが有効な場合、上記のセクションで指定されたシークレットには、2つの追加キーが含まれている必要があります。
-
client.cert
認証のためにetcd
に提示される PEM 形式の証明書 -
client.key
上記のクライアント証明書と一致する PKCS8 形式の秘密鍵
鍵は openssl
を使用して PKCS8 形式に変換できます。
openssl pkcs8 -topk8 -nocrypt -in client-key.pem -out client-key.pkcs8
cert-managerを用いた鍵、証明書の生成
cert-manager がクラスタにインストールされていることが必要です。
Helmのオーバーライドファイルで以下のオプションを設定します。
linstorSslMethod: cert-manager
linstorHttpsMethod: cert-manager
Generate Keys and Certificates Using Helm
Helmのオーバーライドファイルで以下のオプションを設定します。
linstorSslMethod: helm
linstorHttpsMethod: helm
鍵や証明書の手動生成
認証局用の秘密鍵と自己署名証明書を作成します。
openssl req -new -newkey rsa:2048 -days 5000 -nodes -x509 -keyout ca.key \ -out ca.crt -subj "/CN=linstor-system" openssl req -new -newkey rsa:2048 -days 5000 -nodes -x509 -keyout client-ca.key \ -out client-ca.crt -subj "/CN=linstor-client-ca"
秘密鍵を作成します。コントローラ用に2つ、全ノード用に1つ、全クライアント用に1つ作成します。
openssl genrsa -out linstor-control.key 2048 openssl genrsa -out linstor-satellite.key 2048 openssl genrsa -out linstor-client.key 2048 openssl genrsa -out linstor-api.key 2048
コントローラーとノードの信頼できる証明書を作成します。
openssl req -new -sha256 -key linstor-control.key -subj "/CN=system:control" \ -out linstor-control.csr openssl req -new -sha256 -key linstor-satellite.key -subj "/CN=system:node" \ -out linstor-satellite.csr openssl req -new -sha256 -key linstor-client.key -subj "/CN=linstor-client" \ -out linstor-client.csr openssl req -new -sha256 -key linstor-api.key -subj "/CN=linstor-controller" \ -out linstor-api.csr openssl x509 -req -in linstor-control.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -out linstor-control.crt -days 5000 -sha256 openssl x509 -req -in linstor-satellite.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -out linstor-satellite.crt -days 5000 -sha256 openssl x509 -req -in linstor-client.csr -CA client-ca.crt -CAkey client-ca.key \ -CAcreateserial -out linstor-client.crt -days 5000 -sha256 openssl x509 -req -in linstor-api.csr -CA client-ca.crt -CAkey client-ca.key \ -CAcreateserial -out linstor-api.crt -days 5000 -sha256 -extensions 'v3_req' \ -extfile <(printf '%s\n' '[v3_req]' extendedKeyUsage=serverAuth \ subjectAltName=DNS:linstor-op-cs.default.svc)
最後のコマンドの linstor-op-cs.default.svc は create service 名と一致させる必要があります。Helm
では、これは常に <release-name>-cs.<namespace>.svc になります。
|
コントローラとノードポッドに渡すことができるkubernetes シークレットを作成します。
kubectl create secret generic linstor-control --type=kubernetes.io/tls \ --from-file=ca.crt=ca.crt --from-file=tls.crt=linstor-control.crt \ --from-file=tls.key=linstor-control.key kubectl create secret generic linstor-satellite --type=kubernetes.io/tls \ --from-file=ca.crt=ca.crt --from-file=tls.crt=linstor-satellite.crt \ --from-file=tls.key=linstor-satellite.key kubectl create secret generic linstor-api --type=kubernetes.io/tls \ --from-file=ca.crt=client-ca.crt --from-file=tls.crt=linstor-api.crt \ --from-file=tls.key=linstor-api.key kubectl create secret generic linstor-client --type=kubernetes.io/tls \ --from-file=ca.crt=client-ca.crt --from-file=tls.crt=linstor-client.crt \ --from-file=tls.key=linstor-client.key
作成したシークレットの名前を helm install
に渡します。
linstorHttpsControllerSecret: linstor-api
linstorHttpsClientSecret: linstor-client
operator:
controller:
sslSecret: linstor-control
satelliteSet:
sslSecret: linstor-satellite
LINSTOR のパスフレーズを自動設定
LINSTOR は、暗号化された情報をサポートするために機密データを保存する必要があります。このデータはマスターパスフレーズによって保護されています。パスフレーズは、最初のチャートインストール時に自動的に生成されます。
カスタムパスフレーズを使用する場合は、シークレットに保存します。
kubectl create secret generic linstor-pass --from-literal=MASTER_PASSPHRASE=<password>
インストール時に、次の引数を helm コマンドに追加します。
--set operator.controller.luksSecret=linstor-pass
Helm インストール例
以下のすべての例では、次の sp-values.yaml
ファイルを使用しています。用途や環境に合わせて調整してください。詳細は
<ストレージプール作成の構成> を参照ください。
operator: satelliteSet: storagePools: lvmThinPools: - name: lvm-thin thinVolume: thinpool volumeGroup: "" devicePaths: - /dev/sdb
デフォルトのインストールです。これにより etcd KeyValue ストアの設定はされないことに注意してください。
警告:これは、テスト以外での使用は推奨されていません。 |
kubectl create secret docker-registry drbdiocred --docker-server=drbd.io \ --docker-username=<YOUR_LOGIN> --docker-password=<YOUR_PASSWORD> helm repo add linstor https://charts.linstor.io helm install linstor-op linstor/linstor
これ以降 kubectl create コマンドで使用される LINBIT のコンテナーイメージリポジトリ (http://drbd.io)
は、LINBIT のお客様または LINBIT のお客様の試用アカウントを通じてのみ利用できます。価格についての情報や試用開始するには
こちら を参照ください。また、LINSTOR SDS
のアップストリームプロジェクト
Piraeus は LINBIT
の顧客ではなくてもを使用できます。
|
sp-values.yaml
で定義された LINSTOR storage-pools, 永続的な hostPath ボリューム, 3 つの
etcd レプリカ, ホストカーネル用にコンパイルされた DRBD カーネルモジュールを使用してインストールします。
これは、ほとんどの基本的なデプロイメントに適しています。このデプロイメントでは、コマンドの移植性を高めるために、コンパイル済みの DRBD
カーネルモジュールを使用していないことに注意してください。コンパイル済みのバイナリを使用すると、インストールとデプロイメントは速くなります。大規模な
Kubernetes クラスターでの使用には、 Compile
オプションの使用は推奨されません。
kubectl create secret docker-registry drbdiocred --docker-server=drbd.io \ --docker-username=<YOUR_LOGIN> --docker-password=<YOUR_PASSWORD> helm repo add linstor https://charts.linstor.io helm install linstor-etcd linstor/pv-hostpath --set "nodes={<NODE0>,<NODE1>,<NODE2>}" helm install -f sp-values.yaml linstor-op linstor/linstor --set etcd.replicas=3 \ --set operator.satelliteSet.kernelModuleInjectionMode=Compile
sp-values.yaml
で定義された LINSTOR storage-pools, etcd の代わりに作成済みの Postgres
DB(できればクラスター化), DRBD 用にコンパイル済みのカーネルモジュールを使用してインストールします。
この例の Postgres データベースは postgres
という名前のサービスエンドポイントでアクセスできます。Postgres 自体は
POSTGRES_DB = postgresdb
, POSTGRES_USER = postgresadmin
, および
POSTGRES_PASSWORD = admin123
で構成されます。
kubectl create secret docker-registry drbdiocred --docker-server=drbd.io \ --docker-username=<YOUR_LOGIN> --docker-email=<YOUR_EMAIL> --docker-password=<YOUR_PASSWORD> helm repo add linstor https://charts.linstor.io helm install -f sp-values.yaml linstor-op linstor/linstor --set etcd.enabled=false \ --set "operator.controller.dbConnectionURL=jdbc:postgresql://postgres/postgresdb?user=postgresadmin&password=admin123"
Helm デプロイメントの終了
重要なコンポーネントを誤って削除しないようにクラスターのストレージインフラストラクチャを保護するには、Helm デプロイメントを削除する前にいくつかの手動手順を実行します。
-
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
これらのボリュームは、いったん削除されると復元できません。 -
LINSTOR コントローラーとサテライトリソースを削除します。
LINSTOR サテライトとコントローラーのデプロイメントは、LinstorSatelliteSet リソースと LinstorController リソースによって制御されます。kubectl を使用して、デプロイメントに関連付けられているリソースを削除できます。
kubectl delete linstorcontroller <helm-deploy-name>-cs kubectl delete linstorsatelliteset <helm-deploy-name>-ns
しばらくすると、コントローラーとサテライトポッドが終了します。終了しない場合は、上記のリソースのエラーを確認します(関連付けられているすべてのポッドが終了した後でのみ削除されます)
-
Helm デプロイメントの終了
すべての PVC を削除し、すべての LINSTOR ポッドが終了した場合、helm デプロイメントをアンインストールできます。
helm uninstall linstor-op
Helm の現在のポリシーにより、LinstorController および LinstorSatelliteSet という名前のカスタムリソース定義はコマンドによって削除されません。 CRD の Helm の現状に関しては こちら を参照ください。
3.2.5. 高度なデプロイメントオプション
Helm チャートは、高度なユースケースのために、さらなるカスタマイズオプションのセットを提供します。
以下の Helm チャートで使用される LINBIT のコンテナーイメージリポジトリ (http://drbd.io) は、LINBIT のお客様または LINBIT のお客様の試用アカウントを通じてのみ利用できます。価格についての情報や試用開始するには こちら を参照ください。また、LINSTOR SDS のアップストリームプロジェクト Piraeus は LINBIT の顧客ではなくてもを使用できます。 |
global:
imagePullPolicy: IfNotPresent # empty pull policy means k8s default is used ("always" if tag == ":latest", "ifnotpresent" else) (1)
setSecurityContext: true # Force non-privileged containers to run as non-root users
# Dependency charts
etcd:
enabled: true
persistentVolume:
enabled: true
storage: 1Gi
replicas: 1 # How many instances of etcd will be added to the initial cluster. (2)
resources: {} # resource requirements for etcd containers (3)
image:
repository: gcr.io/etcd-development/etcd
tag: v3.4.15
stork:
enabled: false
storkImage: docker.io/openstorage/stork:2.8.2
schedulerImage: k8s.gcr.io/kube-scheduler-amd64
schedulerTag: ""
replicas: 1 (2)
storkResources: {} # resources requirements for the stork plug-in containers (3)
schedulerResources: {} # resource requirements for the kube-scheduler containers (3)
podsecuritycontext: {}
csi:
enabled: true
pluginImage: "drbd.io/linstor-csi:v0.20.0"
csiAttacherImage: k8s.gcr.io/sig-storage/csi-attacher:v4.0.0
csiLivenessProbeImage: k8s.gcr.io/sig-storage/livenessprobe:v2.7.0
csiNodeDriverRegistrarImage: k8s.gcr.io/sig-storage/csi-node-driver-registrar:v2.5.1
csiProvisionerImage: k8s.gcr.io/sig-storage/csi-provisioner:v3.2.1
csiSnapshotterImage: k8s.gcr.io/sig-storage/csi-snapshotter:v6.0.1
csiResizerImage: k8s.gcr.io/sig-storage/csi-resizer:v1.6.0
csiAttacherWorkerThreads: 10 (9)
csiProvisionerWorkerThreads: 10 (9)
csiSnapshotterWorkerThreads: 10 (9)
csiResizerWorkerThreads: 10 (9)
controllerReplicas: 1 (2)
nodeAffinity: {} (4)
nodeTolerations: [] (4)
controllerAffinity: {} (4)
controllerTolerations: [] (4)
enableTopology: true
resources: {} (3)
customLabels: {}
customAnnotations: {}
kubeletPath: /var/lib/kubelet (7)
controllerSidecars: []
controllerExtraVolumes: []
nodeSidecars: []
nodeExtraVolumes: []
priorityClassName: ""
drbdRepoCred: drbdiocred
linstorSslMethod: "manual" # <- If set to 'helm' or 'cert-manager' the certificates will be generated automatically
linstorHttpsMethod: "manual" # <- If set to 'helm' or 'cert-manager' the certificates will be generated automatically
linstorHttpsControllerSecret: "" # <- name of secret containing linstor server certificates+key. See docs/security.md
linstorHttpsClientSecret: "" # <- name of secret containing linstor client certificates+key. See docs/security.md
controllerEndpoint: "" # <- override to the generated controller endpoint. use if controller is not deployed via operator
psp:
privilegedRole: ""
unprivilegedRole: ""
operator:
replicas: 1 # <- number of replicas for the operator deployment (2)
image: "drbd.io/linstor-operator:v1.10.0"
affinity: {} (4)
tolerations: [] (4)
resources: {} (3)
customLabels: {}
customAnnotations: {}
podsecuritycontext: {}
args:
createBackups: true
createMonitoring: true
sidecars: []
extraVolumes: []
controller:
enabled: true
controllerImage: "drbd.io/linstor-controller:v1.20.0"
dbConnectionURL: ""
luksSecret: ""
dbCertSecret: ""
dbUseClientCert: false
sslSecret: ""
affinity: {} (4)
httpBindAddress: ""
httpsBindAddress: ""
tolerations: (4)
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
- key: node-role.kubernetes.io/control-plane
operator: Exists
effect: NoSchedule
resources: {} (3)
replicas: 1 (2)
additionalEnv: [] (5)
additionalProperties: {} (6)
sidecars: []
extraVolumes: []
customLabels: {}
customAnnotations: {}
satelliteSet:
enabled: true
satelliteImage: "drbd.io/linstor-satellite:v1.20.0"
storagePools: {}
sslSecret: ""
automaticStorageType: None
affinity: {} (4)
tolerations: [] (4)
resources: {} (3)
monitoringImage: "drbd.io/drbd-reactor:v0.9.0"
monitoringBindAddress: ""
mountDrbdResourceDirectoriesFromHost: false (10)
kernelModuleInjectionImage: "drbd.io/drbd9-rhel7:v9.1.11"
kernelModuleInjectionMode: ShippedModules
kernelModuleInjectionAdditionalSourceDirectory: "" (8)
kernelModuleInjectionResources: {} (3)
kernelModuleInjectionExtraVolumeMounts: []
additionalEnv: [] (5)
sidecars: []
extraVolumes: []
customLabels: {}
customAnnotations: {}
haController:
enabled: false
image: drbd.io/linstor-k8s-ha-controller:v0.3.0
affinity: {} (4)
tolerations: [] (4)
resources: {} (3)
replicas: 1 (2)
customLabels: {}
customAnnotations: {}
1 | すべてのイメージのプルポリシーを設定します。 |
2 | 各コンポーネントのレプリカ数を制御します。 |
3 | コンテナリソースのリクエストと制限を設定します。詳細は
kubernetes
ドキュメント を参照ください。
以下を除いて、ほとんどのコンテナは、最小限のリソースしか必要としません。
|
4 | AffinityとTolerationは、クラスタ上のどこにポッドがスケジュールされるかを決定します。詳細は
kubernetes docs on
affinity and toleration を参照ください。これは operator.satelliteSet と csi.node*
の値に対して特に重要かもしれません。LINSTOR 永続ボリュームを使用してポッドをスケジュールするには、そのノードで実行中の LINSTOR
satellite と LINSTOR CSI ポッドが必要です。 |
5 | コントローラとサテライトポッドに渡す kubernetes シークレットを作成します。Linstor コントローラーとサテライトに渡す追加の環境変数を設定します。 コンテナ環境変数 と同じフォーマットを使用します。 |
6 | Linstor コントローラーに追加のプロパティを設定します。単純な <property-key>: <value> マッピングを使用します。 |
7 | Kubelet は、すべての CSI
プラグインが独自の状態ディレクトリの特定のサブディレクトリにボリュームをマウントすることを想定しています。デフォルトでは、この状態ディレクトリは
/var/lib/kubelet です。一部の Kubernetes ディストリビューションは異なるディレクトリを使用します。
|
8 | カーネルモジュールのビルドに必要な、ホスト上のディレクトリ。Compile` インジェクションメソッドを使用する場合のみ必要です。デフォルトは
/usr/src で、ほとんどのディストリビューションで実際のカーネルソースがここに格納されています。追加のディレクトリをマウントしない場合は、
"none" を使用します。 |
9 | CSIドライバによって使用されるワーカスレッドの数を設定します。より高い値はLINSTORコントローラに多くの負荷を与え、一度に多くのボリュームを作成する際に不安定になる可能性があります。 |
10 | true に設定すると、サテライトコンテナーには、ホスト OS からマウントされた次のファイルとディレクトリが含まれます。
|
高可用性デプロイメント
すべてのコンポーネントの高可用性デプロイメントを作成するには アップストリームガイド を参照してください。デフォルト値は、複数のレプリカのコンポーネントが異なるノードに配置されるようにスケーリングが行われるように選択されています。これにより、単一ノードの障害によってサービスが中断されることはありません。
3.2.6. Prometheus による監視
Prometheus を使って LINSTOR のコンポーネントを監視することができます。
オペレータは既存のコンポーネントに沿ってモニタリングコンテナをセットアップし、Service
として利用できるようにします。
Prometheus Operator を使用する場合、Linstor
オペレーターは ServiceMonitor
インスタンスも設定します。
Piraeus
名前空間が有効 と仮定して、メトリックはオペレーターに関連付けられた Prometheus インスタンスによって自動的に収集されます。
メトリックのエクスポートを無効にするには operator.satelliteSet.monitoringImage
を空の値に設定します。
LINSTOR コントローラー監視
Linstor コントローラーは、クラスター全体のメトリックをエクスポートします。メトリックは、パス
/metrics
を使用して、既存のコントローラーサービスにエクスポートされます。
DRBD リソース監視
すべてのサテライトは drbd-reactor
を使用して
DRBD から直接メトリックをエクスポートするセカンダリコンテナにバンドルされています。メトリックはポート 9942 で、ヘッドレスサービス
<linstorsatelliteset-name>-monitoring
という名前で提供されています。
監視コンテナを無効にする場合は、LinstorSatelliteSet リソースで monitoringImage
を ""
に設定します。
3.2.7. LINSTORオペレーターを使用したデプロイ
オペレーターは、既存の LINSTOR を使用するようにサテライトと CSI プラグインを構成できます。これは、ストレージインフラストラクチャが Kubernetes クラスターから分離されている場合に役立ちます。ボリュームは Kubernetes ノードでディスクレスモードでプロビジョニングでき、ストレージノードが下位ディスクストレージを提供します。
LINSTOR コントローラーデプロイメントの作成をスキップし、既存の LINSTOR コントローラーを使用するように他のコンポーネントを構成するには、
helm install
を実行するときに次のオプションを使用します。
-
operator.controller.enabled=false
これによりLinstorController
リソースを作成しなくなります。 -
operator.etcd.enabled=false
Kubernetes では LINSTOR コントローラーが実行されないため、データベースは必要ありません。 -
controllerEndpoint=<url-of-linstor-controller>
既存の LINSTOR コントローラーの HTTP エンドポイント。 例えばhttp://linstor.storage.cluster:3370/
すべての pod の準備が整うと、既存の LINSTOR 環境で Kubernetes クラスターノードがサテライトとして表示されます。
kubernetes ノードは、コントローラーとストレージノードが IP を使用して到達可能である必要があります。 |
ストレージノードで既存のストレージプールを参照するストレージクラスを作成します。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: linstor-on-k8s
provisioner: linstor.csi.linbit.com
parameters:
autoPlace: "3"
storagePool: existing-storage-pool
resourceGroup: linstor-on-k8s
ストレージクラスを使用してPVCを作成することで、新しいボリュームをプロビジョニングすることができます。ボリュームはまず、指定されたストレージプールを持つノード、つまりストレージインフラストラクチャにのみ配置されます。ポッドでボリュームを使用したい場合は、LINSTOR CSIがKubernetesノードにディスクレスリソースを作成し、ネットワーク経由でディスクフルリソースに接続します。
3.2.8. Piraeus オペレーターを使用したデプロイメント
Kubernetes でコミュニティがサポートする LINSTOR デプロイメントのエディションは、Piraeus と呼ばれます。Piraeus プロジェクトに関しては オペレータ を参照ください。
3.3. Kubernetes で LINSTOR の操作
コントローラポッドには LINSTOR クライアントが含まれているため、LINSTOR と直接やり取りするのは簡単です。例えば:
kubectl exec deployment/linstor-op-cs-controller -- linstor storage-pool list
上記のコマンドへの便利なショートカットを使用する場合、
kubectl-linstor
をダウンロードし kubectl
と一緒にインストールしてください。 kubectl linstor
を使用して Linstor CLI
にアクセスできます。
$ kubectl linstor node list ╭────────────────────────────────────────────────────────────────────────────────────╮ ┊ Node ┊ NodeType ┊ Addresses ┊ State ┊ ╞════════════════════════════════════════════════════════════════════════════════════╡ ┊ kube-node-01.test ┊ SATELLITE ┊ 10.43.224.26:3366 (PLAIN) ┊ Online ┊ ┊ kube-node-02.test ┊ SATELLITE ┊ 10.43.224.27:3366 (PLAIN) ┊ Online ┊ ┊ kube-node-03.test ┊ SATELLITE ┊ 10.43.224.28:3366 (PLAIN) ┊ Online ┊ ┊ linstor-op-cs-controller-[...] ┊ CONTROLLER ┊ 172.24.116.114:3366 (PLAIN) ┊ Online ┊ ╰────────────────────────────────────────────────────────────────────────────────────╯
また参照を Linstor リソースにマッチする PVC に展開します。
$ kubectl linstor resource list -r pvc:my-namespace/demo-pvc-1 --all pvc:my-namespace/demo-pvc-1 -> pvc-2f982fb4-bc05-4ee5-b15b-688b696c8526 ╭─────────────────────────────────────────────────────────────────────────────────────────────╮ ┊ ResourceName ┊ Node ┊ Port ┊ Usage ┊ Conns ┊ State ┊ CreatedOn ┊ ╞═════════════════════════════════════════════════════════════════════════════════════════════╡ ┊ pvc-[...] ┊ kube-node-01.test ┊ 7000 ┊ Unused ┊ Ok ┊ UpToDate ┊ 2021-02-05 09:16:09 ┊ ┊ pvc-[...] ┊ kube-node-02.test ┊ 7000 ┊ Unused ┊ Ok ┊ TieBreaker ┊ 2021-02-05 09:16:08 ┊ ┊ pvc-[...] ┊ kube-node-03.test ┊ 7000 ┊ InUse ┊ Ok ┊ UpToDate ┊ 2021-02-05 09:16:09 ┊ ╰─────────────────────────────────────────────────────────────────────────────────────────────╯
また pod:[<namespace>/]<podname>
形式の参照をポッドで使用中のリソースリストへ展開します。
これは、問題を調査し、高度な機能にアクセスするためにのみ必要です。ボリュームの作成などの通常の操作は Kubernetes の操作 を参照ください。
3.4. 基本的な構成とデプロイメント
すべての linstor-csi Pod が稼働したら、通常のKubernetesワークフローを使用してボリュームをプロビジョニングできます。
Kubernetes を介してデプロイされた LINSTOR ボリュームの動作とプロパティの構成は StorageClasses を使用して行います。
“resourceGroup” パラメータは必須です。通常、一意にしてストレージクラス名と同じにします。 |
以下は、ボリュームのデプロイに使用できる最も単純で実用的な StorageClass です。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
# The name used to identify this StorageClass.
name: linstor-basic-storage-class
# The name used to match this StorageClass with a provisioner.
# linstor.csi.linbit.com is the name that the LINSTOR CSI plug-in uses to identify itself
provisioner: linstor.csi.linbit.com
volumeBindingMode: WaitForFirstConsumer
parameters:
# LINSTOR will provision volumes from the drbdpool storage pool configured
# On the satellite nodes in the LINSTOR cluster specified in the plug-in's deployment
storagePool: "lvm-thin"
resourceGroup: "linstor-basic-storage-class"
# Setting a fstype is required for "fsGroup" permissions to work correctly.
# Currently supported: xfs/ext4
csi.storage.k8s.io/fstype: xfs
上記の YAML 構成ファイルの例の storagePool の値 lvm-thin は利用可能な LINSTOR StoragePool
と一致する必要があります。実行中の linstor-op-cs-controller ポッド内で実行される linstorstorage-pool
list コマンドを使用して、ストレージプール情報を一覧表示できます。
|
次のコマンドで StorageClass を作成できます。
kubectl create -f linstor-basic-sc.yaml
StorageClass が作成されたので、KubernetesとLINSTOR の両方に認識されるボリュームをプロビジョニングするために使用できる PersistentVolumeClaim を作成できます。
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: my-first-linstor-volume
spec:
storageClassName: linstor-basic-storage-class
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 500Mi
次のコマンドで PersistentVolumeClaim を作成できます。
kubectl create -f my-first-linstor-volume-pvc.yaml
これにより PersistentVolumeClaim が作成されますが、ボリュームはまだ作成されません。使用したストレージクラスは
volumeBindingMode: WaitForFirstConsumer
を指定しました。これは、ワークロードがボリュームの使用を開始したときにのみボリュームが作成されることを意味します。これにより、ボリュームがワークロードと同じノードに配置されます。
この例では、PersistentVolumeClaim を参照してマウントまたはボリューム化する単純なポッドを作成します。 .my-first-linstor-volume-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: fedora
namespace: default
spec:
containers:
- name: fedora
image: fedora
command: [/bin/bash]
args: ["-c", "while true; do sleep 10; done"]
volumeMounts:
- name: my-first-linstor-volume
mountPath: /data
ports:
- containerPort: 80
volumes:
- name: my-first-linstor-volume
persistentVolumeClaim:
claimName: "my-first-linstor-volume"
次のコマンドで Pod を作成できます。
kubectl create -f my-first-linstor-volume-pod.yaml
kubectl describe pod fedora
を実行すると、 Pod スケジューリングとボリューム接続が成功したことを確認できます。
PersistentVolumeClaim を見ると、ボリュームにバインドされていることがわかります。
ボリュームを削除するにはpodがもう使われていないことを確認してから kubectl
を使ってPersistentVolumeClaimを削除します。例えば、先ほど作成したボリュームを削除するには、以下のコマンドを実行します。ボリュームが削除される前にpodのスケジュールを解除します。
kubectl delete pod fedora # podをアンスケジュール。 kubectl get pod -w # podがアンスケジュールされるまで待つ kubectl delete pvc my-first-linstor-volume # PersistentVolumeClaim、PersistentVolume、Linstorボリュームを削除する。
3.4.1. StorageClass で使用可能なパラメータ
次のストレージクラスには、プロビジョニングされたストレージを構成するために現在使用可能なすべてのパラメーターが含まれています。
linstor.csi.linbit.com/ はオプションですが、LINSTOR CSI 固有のパラメーターのプレフィックスとして推奨されます。
|
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: full-example
provisioner: linstor.csi.linbit.com
parameters:
# CSI related parameters
csi.storage.k8s.io/fstype: xfs
# LINSTOR parameters
linstor.csi.linbit.com/autoPlace: "2"
linstor.csi.linbit.com/placementCount: "2"
linstor.csi.linbit.com/resourceGroup: "full-example"
linstor.csi.linbit.com/storagePool: "my-storage-pool"
linstor.csi.linbit.com/disklessStoragePool: "DfltDisklessStorPool"
linstor.csi.linbit.com/layerList: "drbd storage"
linstor.csi.linbit.com/placementPolicy: "AutoPlaceTopology"
linstor.csi.linbit.com/allowRemoteVolumeAccess: "true"
linstor.csi.linbit.com/encryption: "true"
linstor.csi.linbit.com/nodeList: "diskful-a diskful-b"
linstor.csi.linbit.com/clientList: "diskless-a diskless-b"
linstor.csi.linbit.com/replicasOnSame: "zone=a"
linstor.csi.linbit.com/replicasOnDifferent: "rack"
linstor.csi.linbit.com/disklessOnRemaining: "false"
linstor.csi.linbit.com/doNotPlaceWithRegex: "tainted.*"
linstor.csi.linbit.com/fsOpts: "-E nodiscard"
linstor.csi.linbit.com/mountOpts: "noatime"
linstor.csi.linbit.com/postMountXfsOpts: "extsize 2m"
# Linstor properties
property.linstor.csi.linbit.com/*: <x>
# DRBD parameters
DrbdOptions/*: <x>
3.4.2. csi.storage.k8s.io/fstype
csi.storage.k8s.io/fstype` パラメータは volumeMode.Fileystem
PVC
に作成するファイルシステムの種類を設定します。FileSystem`
のPVCに作成するファイルシステムの種類を設定します。現在サポートされているのは次のとおりです。
-
ext4
(デフォルト) -
xfs
3.4.3. autoPlace
autoPlace
は、この StorageClass のボリュームが持つレプリカの量を決定する整数値です。例えば、autoPlace:
"3"
は3つの複製をもつボリュームを生成します。autoPlace
と nodeList
のどちらも設定されていない場合、1つのノード上にボリュームが生成されます。自動配備 を参照ください。
このオプションを使用する場合は、 nodeList を使用しないでください。 |
引用符を使用する必要があります。そうしないと、Kubernetes は不正な形式の StorageClass について文句を言います。 |
このオプション(および自動配置の動作に影響を与えるすべてのオプション)は、ボリューム用のストレージがプロビジョニングされるLINSTORノードの数を変更し、 kubelets からこれらのボリュームにアクセスできるようにします。 |
3.4.4. placementCount
placementCount
は autoPlace
のエイリアスです。
3.4.5. resourceGroup
この StorageClass に関連付けられた LINSTOR Resource Group (RG) 。設定されていない場合、新しい PVC ごとに新しい RG が作成されます。
3.4.6. storagePool
storagePool
は LINSTOR ストレージプール
の名前で、新規に作成されたボリュームにストレージを供給するときに使用されます。
これと同じ storage pool で構成されたノードのみが autoplacement に使用されます。同様に nodeList を使う StorageClasses ではそのリストで指定されたすべてのノードが storage pool を構成している必要があります。 |
3.4.7. disklessStoragePool
disklessStoragePool
はオプションでノードが kubelets
にディスクレス、すなわちクライアントとして割り当てられるようにするときに使用します。LINSTOR
でカスタムディスクレスストレージプールが定義されている場合は、ここで指定します。
3.4.8. layerList
作成されたボリュームで使用するレイヤーのコンマ区切りのリスト。使用可能なレイヤーと順序は このセクション の後半に記述されています。
3.4.9. placementPolicy
使用可能なボリュームスケジューラの 1 つから選択します。
-
AutoPlaceTopology
(デフォルト): ユーザー提供の制約とともに、Kubernetesからのトポロジ情報を使用する(詳細は see replicasOnSame と replicasOnDifferent を参照)。 -
AutoPlace
: LINSTOR autoplace を使う。 replicasOnSame と replicasOnDifferent の影響をうける。 -
FollowTopology
: CSI トポロジ情報を使用して、各 “preferred” ゾーンに少なくとも 1 つのボリュームを配置します。CSI トポロジが有効になっている場合にのみ使用できます。 -
Manual
:nodeList
とclientList
にリストされているノードのみを使用する。 -
Balanced
: 実験的 選択した各ノードで最も使用されていないストレージプールを使用して、障害のあるドメイン全体にボリュームを配置する。
3.4.10. allowRemoteVolumeAccess
ボリュームにアクセスできるノードを制御します。このオプションの値は、次の 2 つの異なる形式をとることができます。
-
"true"
または"false"
は、すべてのノードからのアクセス、またはディスクフルリソースを持つノードのみからのアクセスを許可します。 -
高度なルール。ノードがボリュームにアクセスできる、より詳細なルールを可能にします。
現在の実装では、同じラベルを共有するノードのボリュームへのアクセスを許可できます。たとえば、ディスクフルリソースと同じリージョンおよびゾーン内のすべてのノードからのアクセスを許可する場合は、次を使用できます。
parameters: linstor.csi.linbit.com/allowRemoteVolumeAccess: | - fromSame: - topology.kubernetes.io/region - topology.kubernetes.io/zone
複数のルールを指定でき、1 つのルールに一致するだけで割り当て可能になります。
3.4.11. encryption
encryption
はオプションで、ボリュームを暗号化するかどうかを指定します。LINSTOR
はこれが正しく動作するように適切に設定されている必要があります。
3.4.12. nodeList
nodeList
はボリュームが割り当てられるノードのリストです。ボリュームがそれぞれのノードに割り当てられそれらの間で複製が行われます。これはホスト名で1つのノードを指定できますが、
これには replicasOnSame を使うほうが柔軟性があります。
このオプションを使用する場合は autoPlace を使用しないでください。 |
このオプションは、ボリュームのストレージをどのLINSTORノード上でプロビジョニングするかを決定し、 kubelets からこれらのボリュームにアクセスできるようにします。 |
3.4.13. clientList
clientList
は、割り当てられるディスクレスボリュームのノードのリストです。 nodeList
と組み合わせて使用します。
3.4.14. replicasOnSame
replicasOnSame
は自動配置選択ラベルとして使用される key
または key=value
アイテムのリストです。これは
autoplace
がストレージをプロビジョニングする場所を決定するために使用されます。これらのラベルは、LINSTOR ノードのプロパティに対応しています。
オペレーターは、Kubernetes ノードからのすべてのラベルを定期的に同期するため、それらをスケジューリング制約のキーとして使用できます。 |
node-a
が補助プロパティ zone=z1
, role=backups
で、 node-b
が zone=z1
のみで構成されているような LINSTOR クラスターを想定した例でこの動作を調べてみましょう。
autoPlace: "1"
と replicasOnSame: "zone=z1 role=backups"
を持つ
StorageClass を設定すると、この StorageClass から生成されるすべてのボリュームは node-a
にプロビジョニングされます。これは LINSTOR クラスタ内ですべての key = value
ペアを持つ唯一のノードだからです。これは、プロビジョニングに1つのノードを選択する最も柔軟な方法です。
このガイドは、LINSTOR CSI バージョン 0.10.0 以降を想定しています。 replicasOnSame および
replicasOnDifferent で参照されるすべてのプロパティは、補助プロパティとして解釈されます。古いバージョンの LINSTOR CSI
を使用している場合は、すべてのプロパティ名に Aux/ プレフィックスを追加する必要があります。したがって、 replicasOnSame:
"zone=z1" は replicasOnSame: "Aux/zone=z1" になります。 Aux/ を手動で追加すると、新しい
LINSTOR CSI バージョンで引き続き機能します。
|
autoPlace: "1"
と replicasOnSame: "zone=z1"
を持つ StorageClass
を設定すると、ボリュームは node-a
か node-b
のどちらかにプロビジョニングされます。これは、両方が zone=z1
aux
prop を持つからです。
autoPlace: "2"
と replicasOnSame: "zone=z1 role=backups"
を持つ
StorageClass を設定すると、適切な補助プロパティを持つノードが2つ以上ないためプロビジョニングは失敗します。
autoPlace: "2"
と replicasOnSame: "zone=z1"
を持つ StorageClass
を設定すると、ボリュームは node-a
と node-b
の両方にプロビジョニングされます。これは、両方が zone=z1
aux
prop を持つからです。
値を指定せずにプロパティキーを使用して、特定の値を考慮しながら、すべてのレプリカが同じプロパティ値を持つノードに配置されるようにすることもできます。
4つのノードがあると仮定し node-a1
と node-a2
は zone=a
で構成、 node-b1
と node-b2
は
zone=b
で構成されているとします。 autoPlace: "2"
と replicasOnSame: "zone"
を使用すると
node-a1
と node-a2
、または node-b1
と node-b2
のいずれかに配置されます。
3.4.15. replicasOnDifferent
replicasOnDifferent
は replicasOnSame
と同じように、考慮すべきプロパティのリストを取ります。 replicasOnDifferent
の使用には 2 つのモードがあります。
-
特定のノードでのボリューム配置の防止:
プロパティに値が指定されている場合、そのプロパティと値のペアが割り当てられているノードが最後に考慮されます。
例:
replicasOnDifferent: "no-csi-volumes=true"
はautoPlace
設定を満たすのに十分なノードが他にない限り、プロパティno-csi-volumes=true
を持つノードにボリュームを配置しません。 -
同じキーの値が異なるノード間でボリュームを分散します。
プロパティ値が指定されていない場合、LINSTOR は、可能であれば、そのプロパティの値が異なるノード間でボリュームを配置します。
例: 4 つのノードがあると仮定し
node-a1
とnode-a2
はzone=a
で、node-b1
とnode-b2
はzone=b
で構成されているとします。 StorageClass をautoPlace: "2"
およびreplicasOnDifferent: "zone"
で使用すると、LINSTOR はnode-a1
またはnode-a2
のいずれかに 1 つのレプリカを作成し、node-b1
またはnode-b2
のいずれかにもう 1 つのレプリカを作成します。
3.4.21. property.linstor.csi.linbit.com/*
property.linstor.csi.linbit.com/
で始まるパラメータは StorageClass の
Resource Group に設定される Linstor プロパティに変換されます。
たとえば DrbdOptions/auto-quorum
を disabled
に設定するには、次を使用します。
property.linstor.csi.linbit.com/DrbdOptions/auto-quorum: disabled
オプションの完全なリストは こちら で入手できます。
3.4.22. DrbdOptions/*: <x>
このオプションは非推奨です。より一般的な property.linstor.csi.linbit.com/* を使用してください。
|
LINSTOR に渡す高度な DRBD オプション。たとえば、レプリケーションプロトコルを変更するには
DrbdOptions/Net/protocol: "A"
を使用します。
3.5. スナップショット
スナップショット の作成とスナップショットからの新しいボリュームの作成は VolumeSnapshots, VolumeSnapshotClasses, と PVCs を使用して行われます。
3.5.1. スナップショットサポートの追加
LINSTOR は、すべてではありませんが一部の Kubernetes ディストリビューションでボリュームスナップショット機能をサポートしています。
Kubernetes ディストリビューションがスナップショットをサポートしているかどうかを確認するには、次のコマンドを実行します。
$ kubectl get --raw /apis/snapshot.storage.k8s.io/v1 {"kind":"APIResourceList","apiVersion":"v1","groupVersion":"snapshot.storage.k8s.io/v1"... $ # If your distribution does NOT support snapshots out of the box, you will get a different response: $ kubectl get --raw /apis/snapshot.storage.k8s.io/v1 Error from server (NotFound): the server could not find the requested resource
Kubernetes ディストリビューションがスナップショットをサポートしていない場合は、Kubernetes Storage SIG から required components を手動で追加できます。 Piraeus team が提供する Helm Charts を使用してこれらのコンポーネントを追加することも可能です。
$ kubectl create namespace snapshot-controller $ helm repo add piraeus-charts https://piraeus.io/helm-charts/ $ helm install -n snapshot-controller snapshot-validation-webhook \ piraeus-charts/snapshot-validation-webhook $ helm install -n snapshot-controller snapshot-controller \ piraeus-charts/snapshot-controller --wait
3.5.2. ボリュームスナップショットの使用
それで VolumeSnapshotClass を作成できます。
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: my-first-linstor-snapshot-class
driver: linstor.csi.linbit.com
deletionPolicy: Delete
kubectl
を使用して VolumeSnapshotClass を作成します。
kubectl create -f my-first-linstor-snapshot-class.yaml
次に上記で作成したボリュームのボリュームスナップショットを作成します。これは VolumeSnapshot を使用します。
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: my-first-linstor-snapshot
spec:
volumeSnapshotClassName: my-first-linstor-snapshot-class
source:
persistentVolumeClaimName: my-first-linstor-volume
kubectl
を使用して VolumeSnapshot を作成します。
kubectl create -f my-first-linstor-snapshot.yaml
スナップショットの作成が成功したことを確認できます。
kubectl describe volumesnapshots.snapshot.storage.k8s.io my-first-linstor-snapshot ... Spec: Source: Persistent Volume Claim Name: my-first-linstor-snapshot Volume Snapshot Class Name: my-first-linstor-snapshot-class Status: Bound Volume Snapshot Content Name: snapcontent-b6072ab7-6ddf-482b-a4e3-693088136d2c Creation Time: 2020-06-04T13:02:28Z Ready To Use: true Restore Size: 500Mi
最後にスナップショットから PVC で新しいボリュームを作成します。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-first-linstor-volume-from-snapshot
spec:
storageClassName: linstor-basic-storage-class
dataSource:
name: my-first-linstor-snapshot
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 500Mi
kubectl
を使用して PVC を作成します。
kubectl create -f my-first-linstor-volume-from-snapshot.yaml
スナップショットのS3ストレージへの保存
LINSTORはディザスターリカバリーのために、スナップショットをS3互換のストレージに保存することができます。これは特別なVolumeSnapshotClassを使用してKubernetesに統合されています。
---
kind: VolumeSnapshotClass
apiVersion: snapshot.storage.k8s.io/v1
metadata:
name: linstor-csi-snapshot-class-s3
driver: linstor.csi.linbit.com
deletionPolicy: Retain
parameters:
snap.linstor.csi.linbit.com/type: S3
snap.linstor.csi.linbit.com/remote-name: backup-remote
snap.linstor.csi.linbit.com/allow-incremental: "false"
snap.linstor.csi.linbit.com/s3-bucket: snapshot-bucket
snap.linstor.csi.linbit.com/s3-endpoint: s3.us-west-1.amazonaws.com
snap.linstor.csi.linbit.com/s3-signing-region: us-west-1
snap.linstor.csi.linbit.com/s3-use-path-style: "false"
# Refer here to the secret that holds access and secret key for the S3 endpoint.
# See below for an example.
csi.storage.k8s.io/snapshotter-secret-name: linstor-csi-s3-access
csi.storage.k8s.io/snapshotter-secret-namespace: storage
---
kind: Secret
apiVersion: v1
metadata:
name: linstor-csi-s3-access
namespace: storage
immutable: true
type: linstor.csi.linbit.com/s3-credentials.v1
stringData:
access-key: access-key
secret-key: secret-key
snap.linstor.csi.linbit.com/
パラメータの正確な意味については
LINSTOR スナップショットガイド
を確認してください。ログインに使用される認証情報は、上記の例で示すように、別のシークレットに保存されます。
スナップショット作成時に上記のストレージクラスを参照すると、設定したS3ストレージにスナップショットが自動的にアップロードされるようになります。
既存のスナップショットからリストア
既存のスナップショットからの復元は、ディザスターリカバリーの重要なステップです。スナップショットは、リストアに使用する前にKubernetesに登録される必要があります。
復元すべきスナップショットがS3へのバックアップの一部である場合、LINSTOR “remote” を最初に設定します。
linstor remote create s3 backup-remote s3.us-west-1.amazonaws.com \ snapshot-bucket us-west-1 access-key secret-key linstor backup list backup-remote
登録するスナップショットは、リストアップされたスナップショットのうちの1つを指定します。
Kubernetesにスナップショットを登録するには、スナップショットのIDを参照するVolumeSnapshotContentと、コンテンツを参照するVolumeSnapshotの2つのリソースを作成します。
---
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: example-backup-from-s3
namespace: project
spec:
source:
volumeSnapshotContentName: restored-snap-content-from-s3
volumeSnapshotClassName: linstor-csi-snapshot-class-s3
---
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
name: restored-snap-content-from-s3
spec:
deletionPolicy: Delete
driver: linstor.csi.linbit.com
source:
snapshotHandle: snapshot-id
volumeSnapshotClassName: linstor-csi-snapshot-class-s3
volumeSnapshotRef:
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
name: example-backup-from-s3
namespace: project
適用すると、VolumeSnapshot は ready
と表示され、その時点で PVC の dataSource
として参照することができるようになります。
3.6. ボリュームのアクセスしやすさと局所性
LINSTOR ボリュームはローカルと ネットワーク経由 の両方でアクセスできます。CSI ドライバーは、コンシューマー用に選択されたノードでボリュームにアクセスできるようにします。ドライバーは、ボリュームの局所性の確保(コンシューマーは下位データと同じノードに配置される)と、アクセスを制限する(ノードのサブセットのみがネットワーク経由でボリュームにアクセスできる)オプションも提供します。
ボリュームの局所性は、ストレージクラスで volumeBindingMode: WaitForFirstConsumer
を設定することで実現されます。これにより、Kubernetes と CSI ドライバーは、PVC
を参照する最初のコンシューマー(ポッド)がスケジュールされるまで待機するように指示されます。次に、CSI
ドライバーは、コンシューマーと同じノード上の下位データを使用してボリュームをプロビジョニングします。適切なストレージプールのないノードが選択された場合、アクセス可能なノードのセットから代替ノードが選択されます(以下を参照)。
ボリュームのアクセスしやすさは
allowRemoteVolumeAccess
パラメータ によって制御されます。CSI
プラグインがボリュームを配置するときはいつでも、このパラメーターを調べてアクセス可能なノードのセットを取得します。これは、ネットワークを介して配置されたボリュームを共有できることを意味します。この情報は、PV
のラベルセレクターを介して Kubernetes にも伝達されます。
3.6.1. ボリュームのアクセスしやすさと局所性の例
次の例は、ボリュームのアクセスしやすさと局所性を最適化する一般的なシナリオを示しています。また、クラスター内のゾーン間でボリュームレプリカを分散する方法の例も含まれています。
単一ゾーンの同種クラスター
クラスタは単一のゾーンにのみまたがっています。つまり、ノード間の遅延は低くなっています。クラスタは同種です。つまり、すべてのノードが同様に構成され、すべてのノードに独自のローカルストレージプールがあります。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: linstor-storage
provisioner: linstor.csi.linbit.com
volumeBindingMode: WaitForFirstConsumer (1)
parameters:
linstor.csi.linbit.com/storagePool: linstor-pool (2)
linstor.csi.linbit.com/placementCount: "2" (3)
linstor.csi.linbit.com/allowRemoteVolumeAccess: "true" (4)
1 | レイトボリュームバインディングを有効にします。これにより、可能であれば、最初に実行するポッドと同じノードに 1 つのレプリカが配置されます。 |
2 | 使用するストレージプールを設定します。 |
3 | 少なくとも 2 つのノードがデータを格納することを確証します。 |
4 | レプリカのないノードでもボリュームの使用を許可します。すべてのノードが均等に接続されているため、パフォーマンスへの影響は小さいです。 |
マルチゾーン同種クラスター
単一ゾーンと同様に、同種のクラスターでは、すべてのノードが独自のローカルストレージプールで構成されます。クラスターは複数のゾーンにまたがり、異なるゾーンのノード間のレイテンシーが加わりました。低レイテンシーを考慮して、ローカルレプリカのボリュームへのアクセスを、レプリカを持つゾーンのみに制限する必要があります。同時に、データを複数のゾーンに分散させたいと考えています。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: linstor-storage
provisioner: linstor.csi.linbit.com
volumeBindingMode: WaitForFirstConsumer (1)
parameters:
linstor.csi.linbit.com/storagePool: linstor-pool (2)
linstor.csi.linbit.com/placementCount: "2" (3)
linstor.csi.linbit.com/allowRemoteVolumeAccess: | (4)
- fromSame:
- topology.kubernetes.io/zone
linstor.csi.linbit.com/replicasOnDifferent: topology.kubernetes.io/zone (5)
1 | レイトボリュームバインディングを有効にします。これにより、可能であれば、最初に実行するポッドと同じノードに 1 つのレプリカが配置されます。 |
2 | 使用するストレージプールを設定します。 |
3 | 少なくとも 2 つのノードがデータを格納することを確証します。 |
4 | ゾーンの内部ネットワークが高速で低遅延であるという前提で、レプリカと同じゾーンのノードでボリュームを使用できるようにします。 |
5 | レプリカを異なるゾーンに配置します。 |
マルチリージョンクラスター
クラスターは複数のリージョンにまたがっています。リージョン間でデータを複製する遅延ペナルティを発生させたくないので、同じゾーンで複製します。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: linstor-storage
provisioner: linstor.csi.linbit.com
volumeBindingMode: WaitForFirstConsumer (1)
parameters:
linstor.csi.linbit.com/storagePool: linstor-pool (2)
linstor.csi.linbit.com/placementCount: "2" (3)
linstor.csi.linbit.com/allowRemoteVolumeAccess: | (4)
- fromSame:
- topology.kubernetes.io/zone
linstor.csi.linbit.com/replicasOnSame: topology.kubernetes.io/region (5)
1 | レイトボリュームバインディングを有効にします。これにより、可能であれば、最初に実行するポッドと同じノードに 1 つのレプリカが配置されます。 |
2 | 使用するストレージプールを設定します。 |
3 | 少なくとも 2 つのノードがデータを格納することを確証します。 |
4 | ゾーンの内部ネットワークが高速で低遅延であるという前提で、レプリカと同じゾーンのノードでボリュームを使用できるようにします。 |
5 | レプリカを単一のリージョンのみに制限します。 |
外部ストレージを備えたクラスター
クラスターはローカルストレージのないノードのみで構成されています。ボリュームアクセスは、リモートボリュームアクセスを介して行う必要があります。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: linstor-storage
provisioner: linstor.csi.linbit.com
parameters:
linstor.csi.linbit.com/storagePool: linstor-pool (1)
linstor.csi.linbit.com/placementCount: "1" (2)
linstor.csi.linbit.com/allowRemoteVolumeAccess: "true" (3)
1 | 使用するストレージプールを設定します。 |
2 | ストレージホストが 1 つのみであると仮定して、追加のレプリカなしで 1 つのボリュームのみを配置します。 |
3 | ワーカーノードが外部ストレージホストに接続できるようにします。 |
3.7. LINSTOR アフィニティ コントローラ
ボリュームのアクセシビリティは、PersistentVolume (PV) の node affinity によって制御されます。このアフィニティは静的です。つまり、一度定義すると変更できません。
これは、厳密なアフィニティを使用する場合に問題になる可能性があります。PV は特定のノードに固定されていますが、ノードを削除または追加する必要がある場合があります。LINSTOR はボリュームを移動できますが (たとえば、これは kubernetes でノードを削除すると自動的に行われます)、PV アフィニティはこれを反映するように更新されません。
ここで、LINSTOR Affinity Controller の出番です。PV を監視し、それらのアフィニティを LINSTOR のボリュームの状態と比較します。それらが同期しなくなると、PV は更新されたバージョンに置き換えられます。
LINSTOR Affinity Controller は、Helm チャートにパッケージ化されています。 Operator と同じ名前空間にインストールする場合は、以下を実行するだけです。
$ helm repo update $ helm install linstor-affinity-controller linstor/linstor-affinity-controller
チャートの追加オプションは upstream project で利用できます。
3.8. LINSTOR スケジューラーを使用したボリューム局所性の最適化
LINBIT は Kubernetes スケジューラ用のオープンソースプラグインをメンテナンスしています。スケジューラは、ボリュームの現在の配置を考慮して、データの局所性を最適化します。可能であれば、接続されたボリュームのレプリカもホストするノードにポッドが割り当てられ、読み取り操作のレイテンシーが短縮されます。
スケジューラーは別のチャート artifacthub.io から利用できます。チャートは、後で Pod リソースを作成するときに使用できる新しいスケジューラーをデプロイします。
apiVersion: v1
kind: Pod
metadata:
name: busybox
spec:
schedulerName: linstor-scheduler (1)
containers:
- name: busybox
image: busybox
command: ["tail", "-f", "/dev/null"]
volumeMounts:
- name: my-first-linstor-volume
mountPath: /data
ports:
- containerPort: 80
volumes:
- name: my-first-linstor-volume
persistentVolumeClaim:
claimName: "test-volume"
1 | スケジューラの名前をポッドに追加します。 |
3.9. 高可用性コントローラーを使用した高速ワークロードフェイルオーバー
ノードに障害が発生した場合、Kubernetes はステートフルワークロードの再スケジュールを非常に慎重に行います。これは、ポッドが到達不能なノードから移動されるまでに 15 分以上かかる可能性があることを意味します。DRBD と LINSTOR が利用できる情報により、このプロセスを大幅にスピードアップできます。
LINSTOR 高可用性コントローラー (HA コントローラー) は、ストレージに LINSTOR を使用して、ステートフル ワークロードのフェイルオーバー プロセスを高速化します。少なくとも 1 つの DRBD リソースにアタッチされている Pod を監視および管理します。
HA コントローラーが正しく機能するには、クォーラム、つまり少なくとも 3 つのレプリカ (または 2 つのレプリカと 1 つのディスクレス タイブレーカー) が必要です。使用するレプリカ数が少ない場合、アタッチされた Pod は無視され、より高速なフェイルオーバーの対象にはなりません。
HA コントローラーは Helm チャートとしてパッケージ化されており、以下を使用してデプロイできます。
$ helm repo update $ helm install linstor-ha-controller linstor/linstor-ha-controller
クラスタで HA コントローラを使用している場合は、すべての StorageClass で追加のパラメータを設定できます。これらのパラメーターにより、ボリュームが誤って読み取り専用として再マウントされて、Pod の機能が低下することがなくなります。
parameters:
property.linstor.csi.linbit.com/DrbdOptions/auto-quorum: suspend-io
property.linstor.csi.linbit.com/DrbdOptions/Resource/on-no-data-accessible: suspend-io
property.linstor.csi.linbit.com/DrbdOptions/Resource/on-suspended-primary-outdated: force-secondary
property.linstor.csi.linbit.com/DrbdOptions/Net/rr-conflict: retry-connect
Pod を HA コントローラーによる管理から除外するには、次のアノテーションを Pod に追加します。
$ kubectl annotate pod <podname> drbd.linbit.com/ignore-fail-over=""
3.10. Kubernetes でのノードの退避
リソースの LINSTOR ノードを退避させて、クラスター内の他のノードに配置する場合、そのプロセスは ノードの退避 で詳しく説明されています。 ただし、Kubernetes で LINSTOR ノードを退避させる前に、追加のアクションを実行する必要があります。
まず、ノードのワークロードを別のノードに移動します。これを行うには、次のコマンドを入力します。
# kubectl drain --ignore-daemonsets <node_name>
クラスターが正常に動作していることを確認したら ノードの退避 の手順を続行できます。
複数のノードの退避を計画している場合は、退避するすべてのノードで次のコマンドを入力します。
# linstor node set-property n1.k8s-mwa.at.linbit.com AutoplaceTarget false
これにより、退避しようとしているノードから、退避を計画している別のノードに LINSTOR がリソースを配置することがなくなります。
3.11. Kubernetes での LINSTOR デプロイメントのアップグレード
Kubernets での LINSTOR デプロイメントは、Helm を使用して新しいリリースにアップグレードできます。
新しいリリースにアップグレードする前に、LINSTOR データベースの最新のバックアップがあることを確認する必要があります。LINSTOR チャートにパッケージ化された etcd データベースを使用している場合は、こちら を参照ください。
LINSTOR etcd デプロイメントを使用するアップグレードでは、永続ストレージを使用するために etcd が必要です。etcd が
etcd.persistentVolume.enabled=true を使用してデプロイされた場合にのみ、これらの手順に従ってください。
|
アップグレードは、次のコンポーネントを新しいバージョンに更新します。
-
LINSTOR オペレーターのデプロイメント
-
LINSTOR コントローラー
-
LINSTOR サテライト
-
LINSTOR CSI Driver
-
etcd
-
Stork
一部のバージョンでは特別な手順が必要です。 こちら を参照ください。LINSTOR オペレーターの新しいバージョンにアップグレードするための主なコマンドは次のとおりです。
helm repo update helm upgrade linstor-op linstor/linstor
初期インストールでカスタマイズを使用した場合は、同じオプションを helm upgrade
に渡します。現在使用されているオプションは、Helm
から取得できます。
# Retrieve the currently set options $ helm get values linstor-op USER-SUPPLIED VALUES: USER-SUPPLIED VALUES: null drbdRepoCred: drbdiocred operator: satelliteSet: kernelModuleInjectionImage: drbd.io/drbd9-rhel8:v9.0.28 storagePools: lvmThinPools: - devicePaths: - /dev/vdb name: thinpool thinVolume: thinpool volumeGroup: "" # Save current options $ helm get values linstor-op > orig.yaml # modify values here as needed. for example selecting a newer DRBD image $ vim orig.yaml # Start the upgrade $ helm upgrade linstor-op linstor/linstor -f orig.yaml
これにより、新しい pod のロールアウトがトリガーされます。少し待つと、すべての pod が実行され、準備が整います。LinstorControllers、LinstorSatelliteSets、および LinstorCSIDrivers のステータスセクションにエラーがリストされていないことを確認してください。
アップグレードプロセス中は、ボリュームのプロビジョニングとアタッチ/デタッチ操作が機能しない場合があります。既存のボリュームと pod ですでに使用されているボリュームは、中断することなく引き続き機能します。 |
3.11.1. Kubernetes バックエンドを使用した LINSTOR クラスターのアップグレード
LINSTOR オペレーターは、アップグレードする前にデータベースのバックアップを作成します。これにより、アップグレード中に問題が発生した場合に、以前の状態にロールバックできます。
オペレーターがバックアップを自動的に作成できない状況があります。これは、次の理由が考えられます。
-
チャートまたはオペレーターのバージョンが古すぎます。自動バックアップは、バージョン 1.8.0 以降で使用できます。1.8.0 より前のバージョンからアップグレードする場合は、次のセクションの手動の手順に従ってください。
-
バックアップが大きすぎて、Kubernetes のシークレットに収まりません。この場合、
LinstorController
リソースのステータスフィールドにエラーが報告されます。作成したバックアップを安全な場所にコピーし、必要なシークレットを作成して、指示に従います。kubectl cp <linstor-operator-pod>:/run/linstor-backups/linstor-backup-<some-hash>.tar.gz <destination-path> kubectl create secret linstor-backup-<same-hash>
LINSTOR データベースのバックアップを作成
LINSTOR k8s データベースのバックアップを手動で作成する必要がある場合は、次の手順に従ってください。
-
現在のコントローラーを停止します。
$ kubectl patch linstorcontroller linstor-op-cs '{"spec":{"replicas": 0}}' $ kubectl rollout status --watch deployment/linstor-op-cs-controller
-
次のコマンドは、すべての LINSTOR カスタムリソース定義の現在の状態を保存するファイル
crds.yaml
を作成します。$ kubectl get crds | grep -o ".*.internal.linstor.linbit.com" | \ xargs kubectl get crds -oyaml > crds.yaml
-
定義に加えて、実際のリソースもバックアップする必要があります。
$ kubectl get crds | grep -o ".*.internal.linstor.linbit.com" | \ xargs -i{} sh -c "kubectl get {} -oyaml > {}.yaml"
-
--set IHaveBackedUpAllMyLinstorResources=true
を使用して chart のアップグレードを実行し、上記の手順を実行したことを確認します。
LINSTOR データベースのバックアップからの復元
LINSTOR のアップグレード中に障害から回復する必要がある場合は、次の手順に従ってください。
-
バックアップを準備します(バックアップがローカルマシンですでに利用可能な場合はスキップ)。
$ # List the available backups $ kubectl get secret '-ocustom-columns=NAME:.metadata.name,FROM:metadata.annotations.linstor\.linbit\.com/backup-previous-version,CREATED-AT:.metadata.creationTimestamp' $ kubectl get secret linstor-backup-<backup-specific-hash> '-ogo-template=go-template={{index .data ".binaryData.backup.tar.gz" | base64decode}}' > linstor-backup.tar.gz
-
バックアップを解凍します
$ tar xvf linstor-backup.tar.gz crds.yaml ....
-
現在のコントローラーを停止します。
$ kubectl patch linstorcontroller linstor-op-cs "{"spec":{"replicas": 0}}" $ kubectl rollout status --watch deployment/piraeus-op-cs-controller
-
既存のリソースを削除します
$ kubectl get crds | grep -o ".*.internal.linstor.linbit.com" | xargs --no-run-if-empty kubectl delete crds
-
古い LINSTOR CRD を適用します
$ kubectl apply -f crds.yaml
-
古い LINSTOR リソースの状態を適用します
$ kubectl apply -f *.internal.linstor.linbit.com.yaml
-
古い LINSTOR バージョンを使用してヘルムチャートを再適用します
$ helm upgrade linstor-op charts/piraeus --set operator.controller.controllerImage=... --set operator.satelliteSet.satelliteImage=...
3.11.2. 特定のバージョンのアップグレード手順
一部のバージョンでは特別な手順が必要です。以下を参照ください。
v1.10 へのアップグレード
バージョン 1.10 では、ホストとコンテナー間で DRBD 構成を共有するオプションが導入されています。このオプションが必要な場合は、CRD を更新する必要があります。 Helm はチャートのアップグレード時に CRD をアップグレードしないため、代わりに次を実行してください。
$ helm repo update $ helm pull linstor/linstor --untar $ kubectl replace -f linstor/crds/ customresourcedefinition.apiextensions.k8s.io/linstorcontrollers.linstor.linbit.com replaced customresourcedefinition.apiextensions.k8s.io/linstorcsidrivers.linstor.linbit.com replaced customresourcedefinition.apiextensions.k8s.io/linstorsatellitesets.linstor.linbit.com replaced
v1.9 へのアップグレード
バージョン 1.9 では、デフォルトで <s-kubernetes-ha-controller,LINSTOR HA Controller>> デプロイメントが無効になっています。デプロイメントは、LINSTOR Operator チャートから移動しました。古いバージョンを引き続き使用する場合は、次の Helm コマンドを使用して再度有効にします。
helm upgrade linstor-op linstor/linstor ... --set haController.enabled=true
v1.6 以前から v1.9 にアップグレードする場合は、次のいずれかを行う必要があります。
-
アップグレードする前に、マスターパスフレーズを作成する。
$ kubectl create secret generic linstor-pass --from-literal=MASTER_PASSPHRASE=<password>
-
または、最初に v1.7 にアップグレードすると、Helm によってマスターパスフレーズが自動的に作成されます。このパスフレーズは、次のように入力して後で表示できます。
$ kubectl get secret linstor-op-passphrase \ -ogo-template='{{ .data.MASTER_PASSPHRASE | base64decode }}'
v1.8 へのアップグレード
このアップグレードには K8s データベースの完全な再構築が必要なため、アップグレードに通常よりも時間がかかる場合があります。 |
バージョン 1.8 では、CSI ドライバーのログレベルとワーカースレッドの数を一元的に設定するための新しいオプションが導入されています。これらのオプションが必要な場合は、CRD を更新する必要があります。 Helm はチャートのアップグレード時に CRD をアップグレードしないため、代わりに次を実行してください。
$ helm repo update $ helm pull linstor/linstor --untar $ kubectl replace -f linstor/crds/ customresourcedefinition.apiextensions.k8s.io/linstorcontrollers.linstor.linbit.com replaced customresourcedefinition.apiextensions.k8s.io/linstorcsidrivers.linstor.linbit.com replaced customresourcedefinition.apiextensions.k8s.io/linstorsatellitesets.linstor.linbit.com replaced
さらに 1.8 は SSL/TLS セットアップの動作を作り直します。 secure deployment section を確認し、これらのステップをもう一度やり直してください。
v1.6 以前から v1.8 にアップグレードする場合は、次のいずれかを行う必要があります。
-
アップグレードする前に、マスターパスフレーズを作成する。
$ kubectl create secret generic linstor-pass --from-literal=MASTER_PASSPHRASE=<password>
-
または、最初に v1.7 にアップグレードすると、Helm によってマスターパスフレーズが自動的に作成されます。このパスフレーズは、次のように入力して後で表示できます。
$ kubectl get secret linstor-op-passphrase \ -ogo-template='{{ .data.MASTER_PASSPHRASE | base64decode }}'
v1.6 へのアップグレード
このバージョンでは、デフォルトの /var/lib/kubelet
とは異なる状態ディレクトリを使用する Kubernetes
ディストリビューションをサポートするための新しいオプションが導入されています。注目すべきは
/var/snap/microk8s/common/var/lib/kubelet
を使用する microk8s です。これをサポートするには
LinstorCSIDriver
CRD に少し追加する必要がありました。Helm は chart のアップグレード時に CRD
をアップグレードしないため、代わりに次を実行してください。
$ helm repo update $ helm pull linstor/linstor --untar $ kubectl replace -f linstor/crds/ customresourcedefinition.apiextensions.k8s.io/linstorcontrollers.linstor.linbit.com replaced customresourcedefinition.apiextensions.k8s.io/linstorcsidrivers.linstor.linbit.com replaced customresourcedefinition.apiextensions.k8s.io/linstorsatellitesets.linstor.linbit.com replaced
新しい CRD を適用しないと、次のようなエラーが発生します。
Error: UPGRADE FAILED: error validating "": error validating data: ValidationError(LinstorCSIDriver.spec): unknown field "kubeletPath" in com.linbit.linstor.v1.LinstorCSIDriver.spec
以前に付属のスナップショットコントローラーを使用して VolumeSnapshot
リソースを処理したことがある場合は、それを Piraeus
プロジェクトによって提供される新しい chart に置き換える必要があります。 スナップショットセクション が更新され、スナップショットコントローラーをクラスターに追加する方法e 含まれるようになりました。
v1.5 へのアップグレード
このバージョンでは DRBD リソースの 監視
コンポーネントが導入されます。これには、新しいイメージと既存の LinstorSatelliteSet
CRD の置き換えが必要です。 Helm は
chart upgrade で CRD をアップグレードしません。代わりに、以下を実行してください。
$ helm repo update $ helm pull linstor/linstor --untar $ kubectl replace -f linstor/crds/ customresourcedefinition.apiextensions.k8s.io/linstorcontrollers.linstor.linbit.com replaced customresourcedefinition.apiextensions.k8s.io/linstorcsidrivers.linstor.linbit.com replaced customresourcedefinition.apiextensions.k8s.io/linstorsatellitesets.linstor.linbit.com replaced
提供されている 監視機能 を使用する予定がない場合でも、上記の手順を適用する必要があります。そうしないと、次のようなエラーが発生します。
Error: UPGRADE FAILED: error validating "": error validating data: ValidationError(LinstorSatelliteSet.spec): unknown field "monitoringImage" in com.linbit.linstor.v1.LinstorSatelliteSet.spec
一部の Helm バージョンでは、CRD を交換した後でも監視イメージを設定できません。その場合、クラスター内の LinstorSatelliteSet
は空の monitoringImage 値を表示します。 kubectl edit linstorsatellitesets
を使用してリソースを編集し、値を drbd.io/drbd-reactor:v0.3.0 に設定して、監視を有効にします。
|
v1.4 へのアップグレード
このバージョンでは、etcd イメージの新しいデフォルトバージョンが導入されているため、etcd が永続ストレージを使用していることに特に注意してください。永続ストレージなしで etcd イメージをアップグレードすると、クラスターが壊れるので注意してください。
新しい Helm オプションを使用せずに既存のクラスターをアップグレードする場合、追加の手順は必要ありません。
新しく導入された additionalProperties
および additionalEnv
設定を使用する場合は、インストールされている
CustomResourceDefinitions を新しいバージョンに置き換える必要があります。Helm は chart upgrade で CRD
をアップグレードしません。
$ helm pull linstor/linstor --untar $ kubectl replace -f linstor/crds/ customresourcedefinition.apiextensions.k8s.io/linstorcontrollers.linstor.linbit.com replaced customresourcedefinition.apiextensions.k8s.io/linstorcsidrivers.linstor.linbit.com replaced customresourcedefinition.apiextensions.k8s.io/linstorsatellitesets.linstor.linbit.com replaced
v1.2 へのアップグレード
LINSTOR オペレーター v1.2 は Kubernetes 1.17 以降でサポートされています。古い Kubernetes ディストリビューションを使用している場合は、デフォルト設定を変更する必要がある場合があります。例えば [the CSI provisioner](https://kubernetes-csi.github.io/docs/external-provisioner.html) です。
CSI コンポーネントの更新時に既知の問題があります。pod は最新のイメージに更新されず、LinstorCSIDrivers リソースの
errors
セクションに DaemonSet の更新エラーが表示されます。この場合、
deployment/linstor-op-csi-controller
と daemonset/linstor-op-csi-node
を手動で削除してください。それらはオペレーターによって再作成されます。
4. Openshift での LINSTOR ボリューム
本章では、LINSTOR Operatorで管理し、 LINSTOR CSI plugin を使用してボリュームをプロビジョニングしたOpenShiftでのLINBIT SDSの使用方法を説明します。
OpenShift は、Red Hatが開発し、サポートするKubernetesの公式ディストリビューションです。OpenShiftの価値は、ネットワークのイングレスやモニタリングなど、他のオプションのコンポーネントを強力に統合し、すべてを管理するためのWeb UIで結びつけていることです。LINSTOR Operatorは、可能な限りこれらのコンポーネントと統合しています。
4.1. Openshift での LINSTOR のデプロイ
OpenShiftへのLINBIT SDSのデプロイは、他のKubernetesクラスタへのLINBIT SDSのデプロイと同様です。前提条件として、以下のものが必要です。
-
Helm がインストールされている。
-
oc
ユーティリティで OpenShift クラスターにアクセスできる。 -
drbd.io
にアクセスする LINBIT カスタマーポータルの資格がある。
LINBIT のコンテナー イメージ リポジトリ (http://drbd.io) は、LINBIT のお客様、>または LINBIT のお客様の試用アカウントを通じてのみ利用できます。価格についての情報や試用開始するには こちら を参照ください。また、LINSTOR SDS のアップストリームプロジェクト Piraeus は LINBIT の顧客ではなくてもを使用できます。 |
まず、LINBIT SDSの新規プロジェクトを作成し、 drbd.io
の認証情報を設定する( $USERNAME
と $PASSWORD
は LINBIT カスタマーポータルの資格に置き換えてください)。
$ oc new-project storage Now using project "storage" on server ... $ oc create secret docker-registry drbdiocred --docker-server=drbd.io --docker-username=$USERNAME --docker-password=$PASSWORD secret/drbdiocred created
次に、Helmチャートのデフォルト値のいくつかを上書きするファイルを override.yaml
という名前で作成します。
global:
setSecurityContext: false (1)
etcd:
enabled: false (2)
operator:
controller:
dbConnectionURL: k8s (3)
satelliteSet:
kernelModuleInjectionImage: drbd.io/drbd9-rhel8:v9.1.6 (4)
1 | HelmはSecurityContextと衝突するすべてのPodに対して SecurityContext を設定します。 |
2 | etcdの使用は、まだデフォルトですが、LINSTORのバックエンドである k8s
に移行するため、段階的に廃止される予定です。新規にインストールする場合は、etcdを使用しないでください。 |
3 | LINSTORの新しいバックエンドである k8s を使用します。LINSTORのクラスタの状態はKubernetes
APIのCustomResourcesの中に格納されます。追加のデータベース設定は必要ありません。 |
4 | OpenShiftは、Red Hat Enterprise Linux 8をベースに、同じLinuxカーネルを使用するRed Hat Core OS上で動作します。 |
必要に応じて override.yaml
を追加修正します。使用可能なオプションは
Kubernetes advanced deployment section
に記載されています。
最後に、Helmを使ってLINBIT SDSをデプロイし、すべてのPodの環境がそろうまで待ちます。
$ helm install linstor-op linstor/linstor --values override.yaml NAME: linstor-op NAMESPACE: storage STATUS: deployed ... $ oc wait --for=condition=Ready pod --all ... $ oc get pods NAME READY STATUS RESTARTS AGE linstor-op-cs-controller-6588445756-mh9vn 1/1 Running 0 5m48s ...
4.1.2. LINBIT GUIアクセスの設定
LINSTORコンテナイメージには、LINBIT GUIがプリインストールされています。これをクラスタ上で公開するには、OpenShift Routeリソースを設定します。
$ oc create route edge --service linstor-op-cs $ oc get route NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD linstor-op-cs linstor-op-cs-storage.apps.oc.example.com linstor-op-cs linstor-op-cs edge None
GUIは https://linstor-op-cs-storage.apps.oc.example.com/ui/
でアクセスできるようになりました。
これにより、LINBIT GUIやLINSTOR APIへの外部からのアクセスが可能となる場合があります。 ルート上でクライアント側のTLS証明書を要求するなどして、許可されたユーザのみがアクセスできるようにする。 |
4.1.3. クラスタモニタリングの設定
OpenShiftには、完全に設定された監視スタックが含まれています。モニタリングスタックのほとんどはOpenstackインフラストラクチャのみを対象としていますが、LINBIT SDSの基本的なモニタリングも可能となっています。
まず、 Red Hatドキュメント の手順に従って、OpenShiftでユーザー定義プロジェクトの監視が有効になっていることを確認します。
ユーザー定義プロジェクトの監視を有効にすると、LINSTOR
Operatorは自動的にOpenShiftのPrometheusベースの監視スタックの存在を検出し、ServiceMonitor
リソースを構成します。Prometheusインスタンスは、すべてのクラスタノードからDRBDとLINSTORのメトリックを取得します。
4.2. OpenShiftでLINBIT SDS 連携
LINSTOR Controller podにはLINSTOR Clientが含まれており、LINSTORの対話型モードに簡単にアクセスすることができます。例えば:
$ oc exec -it deployment/linstor-op-cs-controller -- linstor interactive LINSTOR ==> ...
これは、問題の調査や高度な機能へのアクセスにのみ必要なはずです。 ボリュームの作成など通常の操作は Kubernetes integration で行う必要があります。
5. NomadのLINSTORボリューム
この章では、LINSTORとDRBDを使用してNomadでボリュームをプロビジョニングする方法について説明します。
5.1. Nomad の紹介
Nomad は、コンテナとコンテナ化されていないアプリケーションをオンプレミスとクラウド上にデプロイして管理するための、シンプルで柔軟性のあるワークロードオーケストレーターです。
Nomad は Container Storage Interface(CSI) に準拠した plug-ins 経由のストレージボリュームのプロビジョニングをサポートします。
LINBIT は、CSIプラグインを drbd.io のコンテナイメージの形で配布しています。このプラグインは、Nomadクラスタに沿って、またはその内部にデプロイされたLINSTORクラスタと連携するように構成できます。
LINBIT のコンテナー イメージ リポジトリ (http://drbd.io) は、LINBIT のお客様、または LINBIT のお客様の試用アカウントを通じてのみ利用できます。価格についての情報や試用開始するには こちら を参照ください。また、LINSTOR SDS のアップストリームプロジェクト Piraeus は LINBIT の顧客ではなくてもを使用できます。 |
5.2. NomadにLINSTORの展開
この項では、Nomadで新しいLINSTORクラスタを展開および設定する方法について説明します。
LINSTORをノードに直接インストールする場合は、 LINSTOR のインストール を参照してください。このセクションをスキップして、 CSI ドライバのデプロイ に直接移動できます。 |
5.2.1. Nomadを準備する
LINSTORを実行するには、すべてのNomadエージェントを次のように設定する必要があります。
-
docker driverをサポートし、特権コンテナの実行を許可します。
特権コンテナーの実行を許可するには、以下のスニペットをNomadエージェント構成に追加して、Nomadを再起動します。
Listing 14. /etc/nomad.d/docker-privileged.hclplugin "docker" { config { allow_privileged = true } }
-
コンテナネットワークのサポート。 Container Network Interface プラグインがインストールされていない場合は、ジョブネットワークで
mode = "host"
のみを使用できます。ほとんどの本番環境のセットアップでは、デフォルトのプラグインをインストールすることをお勧めします。plug-in release page に移動し、ディストリビューションに適したリリースアーカイブを選択して、/opt/cni/bin に解凍します。解凍する前にディレクトリを作成する必要があるかもしれません。
-
ホストボリュームを提供して、ホストの
/dev
ディレクトリへのコンテナアクセスを許可するホストボリュームを作成するには、以下のスニペットをNomadエージェント構成に追加し、Nomadを再起動します。
Listing 15. /etc/nomad.d/host-volume-dev.hclclient { host_volume "dev" { path = "/dev" } }
5.2.2. LINSTORコントローラジョブの作成
LINSTOR コントローラは、レプリカのないサービスとして導入されます。どの時点においても、1つのクラスタ内で実行可能なLINSTOR コントローラは1つのみです。データベースへのアクセス権がある場合は、新しいノードでコントローラを再起動できます。詳細は 高可用性 LINSTOR クラスターの作成 を参照してください。
次の例では、データセンター dc1
で単一のLINSTORコントローラを起動するNomadジョブを作成し、外部データベースに接続します。
job "linstor-controller" {
datacenters = ["dc1"] (1)
type = "service"
group "linstor-controller" {
network {
mode = "bridge"
# port "linstor-api" { (2)
# static = 3370
# to = 3370
# }
}
service { (3)
name = "linstor-api"
port = "3370"
connect {
sidecar_service {}
}
check {
expose = true
type = "http"
name = "api-health"
path = "/health"
interval = "30s"
timeout = "5s"
}
}
task "linstor-controller" {
driver = "docker"
config {
image = "drbd.io/linstor-controller:v1.13.0" (4)
auth { (5)
username = "example"
password = "example"
server_address = "drbd.io"
}
mount {
type = "bind"
source = "local"
target = "/etc/linstor"
}
}
# template { (6)
# destination = "local/linstor.toml"
# data = <<EOH
# [db]
# user = "example"
# password = "example"
# connection_url = "jdbc:postgresql://postgres.internal.example.com/linstor"
# EOH
# }
resources {
cpu = 500 # 500 MHz
memory = 700 # 700MB
}
}
}
}
1 | dc1 はデータセンタ名に置き換えてください |
||
2 | これにより、ホストでポート 3370 の LINSTOR API が公開されます。
|
||
3 | service ブロックは、サービスメッシュを介してL INSTOR API を他のジョブに公開するために使用されます。
|
||
4 | LINSTOR Controller イメージを実行するように設定します。最新のイメージは drbd.io
から入手できます。
|
||
5 | イメージを pull するときに使用する認証を設定します。 drbd.io から pull
する場合は、ここでLINBITの顧客ログインを使用する必要があります。プライベートレポジトリからの pull に関しては
こちら を参照ください。 |
||
6 | このテンプレートは、LINSTORの任意の構成オプションを設定するために使用できます。この例では、LINSTORの外部データベースを構成します。詳細は LINSTOR データベースオプション こちら およびNomadテンプレート こちら を参照ください。 |
次のコマンドを実行して、ジョブを適用します。
$ nomad job run linstor-controller.hcl
==> Monitoring evaluation "7d8911a7"
Evaluation triggered by job "linstor-controller"
==> Monitoring evaluation "7d8911a7"
Evaluation within deployment: "436f4b2d"
Allocation "0b564c73" created: node "07754224", group "controller"
Evaluation status changed: "pending" -> "complete"
==> Evaluation "7d8911a7" finished with status "complete"
LINSTOR データベースにホストボリュームを使用
外部データベースを設定せずにLINSTORを試したい場合は、LINSTOR 組み込みのファイルシステムベースのデータベースを利用できます。データベースを永続的にするには、データベースがホストボリュームに配置されていることを確認する必要があります。
ホストボリュームを使用すると、1つのノードのみでLINSTOR コントローラを実行できます。ノードが使用不可の場合は、LINSTOR クラスタも使用不可になります。代替策として、外部(高可用性)データベースを使用するか、 LINSTORクラスタをホストに直接導入 します。 |
LINSTOR データベース用のホストボリュームを作成するには、まず、必要な権限を持つディレクトリをホスト上に作成します。
$ mkdir -p /var/lib/linstor
$ chown -R 1000:0 /var/lib/linstor
次に、以下のスニペットをNomadエージェント構成に追加し、Nomadを再起動します。
client {
host_volume "linstor-db" {
path = "/var/lib/linstor"
}
}
次に、上記の例の linstor-controller.hcl
に次のスニペットを追加し、構成テンプレートの connection_url
オプションを変更します。
job > group
volume "linstor-db" {
type = "host"
source = "linstor-db"
}
job > group > task
volume_mount {
volume = "linstor-db"
destination = "/var/lib/linstor"
}
template {
destination = "local/linstor.toml"
data = <<EOH
[db]
user = "linstor"
password = "linstor"
connection_url = "jdbc:h2:/var/lib/linstor/linstordb"
EOH
}
5.2.3. LINSTOR サテライトジョブの作成
Nomad で LINSTORサテライトは、Nomadのシステムジョブとしてデプロイされ、特権コンテナー内で実行されます。サテライトに加えて、このジョブはLINSTORで使用される他のカーネルモジュールとともにDRBDモジュールもロードします。
次の例では、Nomadジョブを作成して、データセンター dc1
のすべてのノードでLINSTORサテライトを開始します。
job "linstor-satellite" {
datacenters = ["dc1"] (1)
type = "system"
group "satellite" {
network {
mode = "host"
}
volume "dev" { (2)
type = "host"
source = "dev"
}
task "linstor-satellite" {
driver = "docker"
config {
image = "drbd.io/linstor-satellite:v1.13.0" (3)
auth { (4)
username = "example"
password = "example"
server_address = "drbd.io"
}
privileged = true (5)
network_mode = "host" (6)
}
volume_mount { (2)
volume = "dev"
destination = "/dev"
}
resources {
cpu = 500 # 500 MHz
memory = 500 # 500MB
}
}
task "drbd-loader" {
driver = "docker"
lifecycle {
hook = "prestart" (7)
}
config {
image = "drbd.io/drbd9-rhel8:v9.0.29" (8)
privileged = true (5)
auth { (4)
username = "example"
password = "example"
server_address = "drbd.io"
}
}
env {
LB_HOW = "shipped_modules" (9)
}
volume_mount { (10)
volume = "kernel-src"
destination = "/usr/src"
}
volume_mount { (10)
volume = "modules"
destination = "/lib/modules"
}
}
volume "modules" { (10)
type = "host"
source = "modules"
read_only = true
}
volume "kernel-src" { (10)
type = "host"
source = "kernel-src"
read_only = true
}
}
}
1 | dc1 はデータセンタ名に置き換えてください |
||
2 | dev ホストボリュームは Nomadを準備する
で作成されたボリュームであり、サテライトがホストブロックデバイスを管理できるようにします。 |
||
3 | LINSTORのサテライトイメージを実行するように設定します。最新のコンテナイメージは drbd.io
から入手できます。サテライトイメージのバージョンは、コントローライメージのバージョンと一致している必要があります。
|
||
4 | イメージを pull するときに使用する認証を設定します。 drbd.io から pull
する場合は、ここでLINBITの顧客ログインを使用する必要があります。プライベートレポジトリからの pull に関しては
こちら を参照ください。 |
||
5 | ストレージデバイスやDRBDを構成し、カーネルモジュールをロードするためには、コンテナーを特権モードで実行する必要があります。 | ||
6 | サテライトはDRBDと通信する必要があるため、ホストネットワークで実行されているnetlinkインターフェースにアクセスする必要があります。 | ||
7 | drbd-loader タスクはサテライトの開始時に1回実行され、DRBDやその他の有用なカーネルモジュールをロードします。 |
||
8 | drbd-loader は、使用しているディストリビューションに固有のものです。使用可能なオプションは次のとおりです。
|
||
9 | drbd-loader コンテナは環境変数で設定できます。 LB_HOW
はコンテナにDRBDカーネルモジュールの挿入方法を指示します。使用可能なオプションは次のとおりです。
|
||
10 | drbd-loader コンテナがDRBDを構築したり、既存のモジュールをロードしたりするためには、ホストの /usr/src と
/lib/modules にアクセスできる必要があります。
これには、すべてのノードに追加のホストボリュームを設定する必要があります。次のスニペットをすべての Nomad エージェント構成に追加してから、Nomad を再起動する必要があります。 Listing 21. /etc/nomad.d/drbd-loader-volumes.hcl
|
次のコマンドを実行して、ジョブを適用します。
$ nomad job run linstor-satellite.hcl
==> Monitoring evaluation "0c07469d"
Evaluation triggered by job "linstor-satellite"
==> Monitoring evaluation "0c07469d"
Evaluation status changed: "pending" -> "complete"
==> Evaluation "0c07469d" finished with status "complete"
5.2.4. NomadでのLINSTORの設定
linstor-controller
および linstor-satellite
ジョブが実行されたら、 linstor
コマンドラインツールを使用してクラスタの設定を開始できます。
これは次のように実行できます。
-
コンテナに入って
nomad exec
で直接linstor-controller
を実行する。 -
linstor-controller
を実行しているホスト上でdrbd.io/linstor-client
コンテナを使用する。docker run -it --rm --net=host drbd.io/linstor-client node create
-
linstor-client
パッケージをlinstor-controller
を実行しているホストにインストールします。
いずれの場合も、 サテライトをクラスタに追加 および
ストレージプールを作成 を実行する必要があります。たとえば、ノード nomad-01.example.com
を追加してLVMシンストレージプールを構成するには、次のコマンドを実行します。
$ linstor node create nomad-01.example.com
$ linstor storage-pool create lvmthin nomad-01.example.com thinpool linstor_vg/thinpool
CSIドライバでは、サテライトにホスト名に基づいた名前を付ける必要があります。正確に言うと、サテライト名はノードのNomads
attr.unique.hostname 属性と一致する必要があります。
|
5.3. LINSTOR CSIドライバのNomadへの配備
CSIドライバはシステムジョブとしてデプロイされます。つまり、クラスタ内のすべてのノードで実行されます。
次の例では、データセンター dc1
内のすべてのノードでLINSTOR CSIドライバを起動するNomadジョブを作成します。
job "linstor-csi" {
datacenters = ["dc1"] (1)
type = "system"
group "csi" {
network {
mode = "bridge"
}
service {
connect {
sidecar_service { (2)
proxy {
upstreams {
destination_name = "linstor-api"
local_bind_port = 8080
}
}
}
}
}
task "csi-plugin" {
driver = "docker"
config {
image = "drbd.io/linstor-csi:v0.13.1" (3)
auth { (4)
username = "example"
password = "example"
server_address = "drbd.io"
}
args = [
"--csi-endpoint=unix://csi/csi.sock",
"--node=${attr.unique.hostname}", (5)
"--linstor-endpoint=http://${NOMAD_UPSTREAM_ADDR_linstor_api}", (6)
"--log-level=info"
]
privileged = true (7)
}
csi_plugin { (8)
id = "linstor.csi.linbit.com"
type = "monolith"
mount_dir = "/csi"
}
resources {
cpu = 100 # 100 MHz
memory = 200 # 200MB
}
}
}
}
1 | dc1 はデータセンタ名に置き換えてください |
||
2 | sidecar_service スタンザは、 Consul Connect
を使用して生成されたサービスメッシュの使用を可能にします。Nomadでこの機能を構成していない場合、または外部 LINSTOR
コントローラーを使用している場合は、この構成をスキップできます。 |
||
3 | LINSTOR CSIドライバイメージを実行するように設定します。最新のイメージは drbd.io から入手できます。
|
||
4 | イメージを pull するときに使用する認証を設定します。 drbd.io から pull
する場合は、ここでLINBITの顧客ログインを使用する必要があります。プライベートレポジトリからの pull に関しては
こちら を参照ください。 |
||
5 | この引数は、CSIドライバがLINSTOR APIで自身を識別するために使用するノード名を設定します。デフォルトでは、これはノードのホスト名に設定されます。 | ||
6 | この引数は、LINSTOR APIエンドポイントを設定します。consulサービスメッシュ(前述のNr.2を参照)を使用していない場合は、これをControllers APIエンドポイントに設定する必要があります。エンドポイントは、デプロイされているすべてのノードから到達可能である必要があります。 | ||
7 | CSIドライバはマウントコマンドを実行する必要があるため、特権付きコンテナが必要です。 | ||
8 | csi_plugin
スタンザは、このタスクがCSIプラグインであることをNomadに通知します。Nomadエージェントは、ボリュームに対する要求をジョブコンテナーの1つに転送します。 |
次のコマンドを実行して、ジョブを適用します。
$ nomad job run linstor-csi.hcl
==> Monitoring evaluation "0119f19c"
Evaluation triggered by job "linstor-csi"
==> Monitoring evaluation "0119f19c"
Evaluation status changed: "pending" -> "complete"
==> Evaluation "0119f19c" finished with status "complete"
5.4. NomadでのLINSTORボリュームの使用
Nomadのボリュームは、 volume仕様 を使用して作成されます。
例として、次の指定では、2つのレプリカを持つ1GiBボリュームがLINSTORストレージプール thinpool
から要求されます。
id = "vol1" (1)
name = "vol1" (2)
type = "csi"
plugin_id = "linstor.csi.linbit.com"
capacity_min = "1GiB"
capacity_max = "1GiB"
capability {
access_mode = "single-node-writer" (3)
attachment_mode = "file-system" (4)
}
mount_options {
fs_type = "ext4" (5)
}
parameters { (6)
"resourceGroup" = "default-resource",
"storagePool" = "thinpool",
"autoPlace" = "2"
}
1 | id は、Nomad でこのボリュームを参照するために使用されます。ジョブ指定の volume.source フィールドで使用されます。 |
2 | name は、バックエンド(LINSTORなど)でボリュームを作成するときに使用されます。理想的には、これは id
と一致し、有効なLINSTORリソース名です。名前が有効でない場合は、LINSTOR CSIによって互換性のあるランダムな名前が生成されます。 |
3 | ボリュームがサポートする必要があるアクセスの種類。LINSTOR CSIは次のものをサポートします。
|
4 | file-system または block-device のいずれかです。 |
5 | 使用するファイルシステムを指定します。LINSTOR CSI は ext4 と xfs をサポートします。 |
6 | LINSTOR CSI に渡す追加パラメータ。上記の例では、リソースが default-resource
resource group
の一部であることを要求しており、2つのレプリカをデプロイする必要があります。
使用可能なパラメータの完全なリストについては、 ストレージクラスで使用可能なパラメータ を参照ください。Kubernetes は Nomad と同様に CSI プラグインを使用します。 |
ボリュームを作成するには、次のコマンドを実行します。
$ nomad volume create vol1.hcl
Created external volume vol1 with ID vol1
$ nomad volume status
Container Storage Interface
ID Name Plugin ID Schedulable Access Mode
vol1 vol1 linstor.csi.linbit.com true <none>
$ linstor resource list
╭──────────────────────────────────────────────────────────────────────────────────────────────╮
┊ ResourceName ┊ Node ┊ Port ┊ Usage ┊ Conns ┊ State ┊ CreatedOn ┊
╞══════════════════════════════════════════════════════════════════════════════════════════════╡
┊ vol1 ┊ nomad-01.example.com ┊ 7000 ┊ Unused ┊ Ok ┊ UpToDate ┊ 2021-06-15 14:56:32 ┊
┊ vol1 ┊ nomad-02.example.com ┊ 7000 ┊ Unused ┊ Ok ┊ UpToDate ┊ 2021-06-15 14:56:32 ┊
╰──────────────────────────────────────────────────────────────────────────────────────────────╯
5.4.1. ジョブでのボリュームの使用
ジョブでボリュームを使用するには、ジョブ指定に volume
および volume_mount
スタンザを追加します。
job "example" {
...
group "example" {
volume "example-vol" {
type = "csi"
source = "vol1"
attachment_mode = "file-system"
access_mode = "single-node-writer"
}
task "mount-example" {
volume_mount {
volume = "example-vol"
destination = "/data"
}
...
}
}
}
5.4.2. ボリュームのスナップショットの作成
基礎となるストレージプールドライバがスナップショットをサポートしていれば、LINSTORは既存のボリュームのスナップショットを作成できます。
次のコマンドは、ボリューム vol1
の snap1
という名前のスナップショットを作成します。
$ nomad volume snapshot create vol1 snap1
Snapshot ID Volume ID Size Create Time Ready?
snap1 vol1 1.0 GiB None true
$ linstor s l
╭────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
┊ ResourceName ┊ SnapshotName ┊ NodeNames ┊ Volumes ┊ CreatedOn ┊ State ┊
╞════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╡
┊ vol1 ┊ snap1 ┊ nomad-01.example.com, nomad-02.example.com ┊ 0: 1 GiB ┊ 2021-06-15 15:04:10 ┊ Successful ┊
╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
スナップショットを使用して、既存のボリュームにスナップショットのデータを事前に設定できます。
$ cat vol2.hcl
id = "vol2"
name = "vol2"
snapshot_id = "snap1"
type = "csi"
plugin_id = "linstor.csi.linbit.com"
...
$ nomad volume create vol2.hcl
Created external volume vol2 with ID vol2
6. Proxmox VE での LINSTOR ボリューム
この章は LINSTOR Proxmox Plug-in にあるProxmox VEでのDRBDについて説明します。
6.1. Proxmox VE の紹介
Proxmox VE はKVM、Linuxコンテナ、HAとともに使われる簡単で、完全なサーバ仮想化環境を提供します。
‘linstor-proxmox’ は Proxmox 用の Perl プラグインで、LINSTOR と組み合わせて、複数の Proxmox VE ノードで VM ディスクを複製できます。データはすでに複数のノードにレプリケートされているため、中央の SAN を必要とせずに、ダウンタイムなしで数秒以内にアクティブな VM をライブ マイグレーションできます。
6.2. Proxmox のアップグレード
新規インストールの場合はこのセクションをスキップして LINSTOR Proxmox プラグインのインストール に進んでください。
6.2.1. Upgrading Plug-in to 7.x
Version 7 of the plugin uses a LINSTOR controller API that is available from LINSTOR version 1.21.1 onwards. Make sure that your LINSTOR setup (controller and satellites) use at least that version.
6.2.2. プラグインのバージョン 4.x から 5.x へアップグレード
プラグインのバージョン 5 では、構成オプション “storagepool” と “redundancy” はサポートされません。バージョン 5 では LINSTOR リソースグループである “resourcegroup” オプションが必須になります。古いオプションは構成から削除する必要があります。
LINSTOR の構成に関しては LINSTOR の構成 を参照してください。以下に典型的は例を示します。プールが “mypool” 、冗長性が 3 に設定される例です。
プールが “mypool” に、冗長性が 3 に設定されていると仮定します。
# linstor resource-group create --storage-pool=mypool --place-count=3 drbdMypoolThree # linstor volume-group create drbdMypoolThree # vi /etc/pve/storage.cfg drbd: drbdstorage content images,rootdir controller 10.11.12.13 resourcegroup drbdMypoolThree
6.2.3. プラグインのバージョン 5.x から 6.x へアップグレード
プラグインのバージョン 6.0.0 では redundancy
設定に関連するすべてのコードが削除されます。これは、非常に長い間、LINSTOR
リソースグループ (resourcegroup
設定) によって処理されてます。変更は必要ありません。
LINSTOR によって管理される VM で LINSTOR コントローラを実行するための controllervm
設定はなくなりました。
drbd-reactor
を使用して高可用性 LINSTOR コントローラを実現することをお勧めします。
設定 statuscache
と preferlocal
がデフォルトで有効になりました。
6.3. LINSTOR Proxmox プラグインのインストール
Proxmox で LINSTOR を使用するには、LINSTOR Proxmox プラグインをインストールする必要があります。
6.3.1. Proxmox VE カーネル ヘッダーのインストール
Proxmox で LINSTOR を使用するには、DRBD カーネルモジュールをインストールする必要があります。DRBD9 カーネル
モジュールは、カーネルモジュールソースパッケージ (drbd-dkms
) としてインストールされます。したがって、LINBIT のリポジトリから
DRBD カーネルモジュールをインストールする前に、Proxmox VE カーネルヘッダーパッケージ pve-headers
をインストールする必要があります。この順序に従うことで、カーネル モジュールがカーネルに対して適切にビルドされるようになります。
最新の Proxmox カーネルをインストールする予定がない場合は、現在実行中のカーネルに一致するカーネル ヘッダーをインストールする必要があります
(たとえば pve-headers-$(uname -r)
)。この手順に従わなかった場合でも apt install --reinstall
drbd-dkms
コマンドで、現在のカーネルに対して drbd-dkms
パッケージを再構築できます (事前にカーネル
ヘッダーをインストールしている場合)。
pve-headers パッケージをインストールする前に、Proxmox PVE リポジトリを APT ソースリスト
/etc/apt/sources.list に追加し apt update と入力します。
the
Proxmox wiki を参照ください。
|
6.3.2. LINBIT カスタマーリポジトリを使用して Proxmox プラグインをインストール
LINBIT のお客様または評価アカウントをお持ちの場合は、ノードで LINBIT の drbd-9
リポジトリを有効にしてから、apt
update
コマンドを使用してリポジトリを更新できます。
次に、次のように入力して、DRBD カーネルモジュール、DRBD ユーティリティ、および LINSTOR Proxmox プラグインをインストールできます。
# apt install drbd-utils linstor-proxmox drbd-dkms
ノードを LINBIT に登録し、LINBIT リポジトリを有効にする手順については LINBIT クラスターノードを管理するスクリプトの使用 を参照してください。 |
6.3.3. LINBIT 公開リポジトリを使用して Proxmox プラグインをインストール
LINBIT は、Proxmox VE ユーザーに専用の公開リポジトリを提供します。このリポジトリには、Proxmox プラグインだけでなく、DRBD SDS カーネルモジュールとユーザー空間ユーティリティを含む DRBD SDS スタック全体が含まれています。
LINBIT のレポジトリは以下の操作で有効にできます。 “$PVERS” は Proxmox VE のメジャーバージョンを指定します(例 “7” であり “7.1” ではない)。
# wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add - # PVERS=7 && echo "deb http://packages.linbit.com/public/ proxmox-$PVERS drbd-9" > \ /etc/apt/sources.list.d/linbit.list # apt update && apt -y install linstor-proxmox
6.4. LINSTOR の構成
このガイドの残りの部分では クラスタの初期化 に基づいて LINSTOR クラスタが構成されていると仮定します。1
つのノードで “linstor-controller” を起動し、すべてのノードで “linstor-satellite”
を起動します。”linstor-satellite” サービスには systemctl edit linstor-satellite.service
で追加構成が必要です。
[Service] Type=notify TimeoutStartSec=infinity
バージョン 4.1.0 以降、このプラグインを使用する上で推奨する方法は、LINSTOR リソースグループと単一のボリュームグループを使用することです。 LINSTOR リソースグループについては リソースグループを使用した LINSTOR プロビジョニングされたボリュームのデプロイ を参照してください。必要なすべての LINSTOR 構成(冗長カウントなど)をリソースグループに設定する必要があります。
6.5. Proxmox プラグインの構成
最後の手順ではProxmox自身を設定します。これは /etc/pve/storage.cfg
に以下のような設定を加えることで行います。
drbd: drbdstorage content images,rootdir controller 10.11.12.13 resourcegroup defaultpool
“drbd” は固定で変更できません。これによりProxmoxにストレージとしてDRBDを使用することを宣言します。 “drbdstorage” は変更可能で、Web GUI上で表示されるDRBDストレージの場所を示する名前です。”content” は固定で変更できません。 “redundancy” (リソースグループで設定される) はクラスタ内に保つ複製数を指定します。推奨値は 2 または 3 です。例えば5ノードをもつクラスタの場合、すべのノードがデータの3つの複製にアクセスできます。”controller” はLINSTORコントローラが動作するノードのIPアドレスを指定します。同時に1つのノードだけがLINSTORコントローラとして設定できます。このノードは現在動作していなければならず、すでに動作していない場合は、他のノードでLINSTORコントローラを動作させ、IPアドレスを変更しなければなりません。
異なるリソースグループで異なるストレージプールを使用する構成は、次のようになります。
drbd: drbdstorage content images,rootdir controller 10.11.12.13 resourcegroup defaultpool drbd: fastdrbd content images,rootdir controller 10.11.12.13 resourcegroup ssd drbd: slowdrbd content images,rootdir controller 10.11.12.13 resourcegroup backup
これらの設定後、Web GUIでVMを作成し、ストレージとして “drbdstorage” もしくは他の定義されているプールを選択することでDRBDボリュームを使用できます。
プラグインのバージョン 5 以降、オプション “preferlocal yes” を設定できます。設定されている場合、プラグインは storage create コマンドを発行したノードでディスクフル割り当てを作成しようとします。このオプションを使用すると、可能であれば VM がローカルストレージを確実に取得できるようになります。このオプションがないと、VM はノード ‘A’ で起動するが、LINSTORはノード ‘B’ と ‘C’ にストレージを配置する可能性があります。これは、ノード ‘A’ がディスクレス割り当てで、引き続き機能しますが、ローカルストレージを使用することが望まれます。
この時点で、VMのライブマイグレーションができます。すべてのノード(ディスクレスノードでも)ですべてのデータにアクセスできるため、わずか数秒で完了します。 VMに負荷がかかっていて、ダーティメモリが常に多い場合は、全体的な処理に少し時間がかかることがあります。しかし、いずれの場合でも、ダウンタイムは最小限で、中断は全く見られません。
Option | Meaning |
---|---|
|
LINSTOR コントローラーの IP (‘,’ で複数指定可能) |
|
新しい VM の展開を定義する LINSTOR リソースグループの名前 |
|
ローカルストレージ作成を好むかどうか (yes/no) |
|
ステータス情報がキャッシュされる秒単位の時間。0 はキャッシュがないことを意味します。数百のリソースを持つ巨大なクラスターで役立ちます。これを有効にするには |
|
クライアント証明書へのパス |
|
クライアントの秘密鍵へのパス |
|
CA 証明書へのパス |
6.6. コントローラの高可用性 (オプション構成)
LINSTOR を高可用性にするということは、LINSTOR コントローラーを高可用性にすることです。このステップはセクション 高可用性 LINSTOR クラスターの作成 で説明されています。
最後の(しかし重要な)ステップは、複数の LINSTOR コントローラーに接続できるように Proxmox
プラグインを構成することです。応答した最初のものを使用するように、次のようにプラグインの controller
セクションにコンマ区切りでコントローラーを指定します。
drbd: drbdstorage content images,rootdir controller 10.11.12.13,10.11.12.14,10.11.12.15 resourcegroup defaultpool
7. OpenNebulaのLINSTORボリューム
この章では、OpenNebulaのDRBDについて LINSTOR ストレージドライバアドオン の使用法を説明します。
詳しいインストールと設定の手順は、ドライバのソースの README.md を参照ください。
7.1. OpenNebula の紹介
OpenNebula は、アドオンを使用してその機能を拡張できる、柔軟でオープンソースのクラウド管理プラットフォームです。
LINSTOR アドオンを使用すると、DRBD によってバックアップされ、DRBD プロトコルを介してネットワークに接続された高可用性イメージを持つ仮想マシンを配備できます。
7.2. OpenNebula アドオンのインストール
OpenNebula 用の LINSTOR ストレージアドオンのインストールには、動作中の OpenNebula クラスタと動作中の LINSTOR クラスタが必要です。
LINBITの顧客リポジトリにアクセスすることで、linstor-opennebula をインストールできます。
# apt install linstor-opennebula
または
# yum install linstor-opennebula
LINBITのパッケージにアクセスすることができない場合は、 OpenNebula LINSTOR アドオン GitHub ページ を確認してください。
LINSTORを使用したDRBDクラスタは、このマニュアルの指示に従ってインストールおよび設定できます。詳細は クラスタの初期化 を参照してください。
OpenNebulaとDRBDクラスタは、OpenNebulaのフロントエンドノードとホストノードを両方のクラスタに含める必要がありますが、これ以外は互いに独立にできます。
ホストノードは、仮想マシン・イメージがネットワークを介して接続されるためローカルの LINSTOR ストレージプールを必要としません [1] 。
7.3. 配備オプション
LINSTOR リソースグループ リソースグループの作成 を使用して構成することをお勧めします。以前の自動配置およびデプロイメントノードモードは非推奨です。
7.4. OpenNebula アドオンの構成
7.4.1. OpenNebula へのドライバーの追加
/etc/one/oned.conf
の以下のセクションを変更します。
TM_MAD
および DATASTORE_MAD
セクションのドライバーのリストに linstor を追加します。
TM_MAD = [ EXECUTABLE = "one_tm", ARGUMENTS = "-t 15 -d dummy,lvm,shared,fs_lvm,qcow2,ssh,vmfs,ceph,linstor" ]
DATASTORE_MAD = [ EXECUTABLE = "one_datastore", ARGUMENTS = "-t 15 -d dummy,fs,lvm,ceph,dev,iscsi_libvirt,vcenter,linstor -s shared,ssh,ceph,fs_lvm,qcow2,linstor" ]
linstor は DATASTORE_MAD 引数で 2 回指定されます。
|
TM_MAD_CONF および DS_MAD_CONF セクションを新たに追加します。
TM_MAD_CONF = [ NAME = "linstor", LN_TARGET = "NONE", CLONE_TARGET = "SELF", SHARED = "yes", ALLOW_ORPHANS="yes", TM_MAD_SYSTEM = "ssh,shared", LN_TARGET_SSH = "NONE", CLONE_TARGET_SSH = "SELF", DISK_TYPE_SSH = "BLOCK", LN_TARGET_SHARED = "NONE", CLONE_TARGET_SHARED = "SELF", DISK_TYPE_SHARED = "BLOCK" ]
DS_MAD_CONF = [ NAME = "linstor", REQUIRED_ATTRS = "BRIDGE_LIST", PERSISTENT_ONLY = "NO", MARKETPLACE_ACTIONS = "export" ]
これらの変更を行った後、OpenNebula サービスを再起動します。
7.4.2. ノードの構成
フロントエンドノードは、LINSTOR を介してストレージノードおよびホストノードにコマンドを発行します。
ストレージノードは、VM のディスクイメージをローカルに保持します。
ホストノードは、インスタンス化された VM の実行を担当し、通常、必要なイメージ用のストレージを LINSTOR ディスクレスモードを介してネットワーク経由で接続します。
すべてのノードに DRBD9 と LINSTOR がインストールされている必要があります。このプロセスの詳細は DRBD9 のユーザーズガイド を参照ください。
両方の役割のすべての要件を満たす限り、フロントエンドノードとホストノードをプライマリロールに加えてストレージノードとして機能させることができます。
フロントエンドノードの構成
使用するコントロールノードがフロントエンドノードから到達可能であることを確認してください。ローカルで実行される LINSTOR コントローラーでは
linstor node list
を、リモートで実行する LINSTOR コントローラーでは linstor --controllers
"<IP:PORT>" node list
を使用することで簡単にテストできます。
ホストノードの構成
ホストノードでは、LINSTOR サテライトプロセスが実行され、フロントエンドノードおよびストレージノードと同じ LINSTOR
クラスターのメンバーである必要があります。また、オプションでローカルにストレージを持つことができます。 oneadmin
ユーザーがパスワードなしでホスト間で SSH できる場合、SSH システムデータストアでもライブマイグレーションを使用できます。
ストレージノードの構成
フロントエンドノードとホストノードのみが OpenNebula のインストールを必要としますが、oneadmin ユーザーはパスワードなしでストレージノードにアクセスできる必要があります。 oneadmin ユーザーアカウントを手動で構成する方法については、ディストリビューションの OpenNebula インストールガイドを参照してください。
ストレージノードは、シンLVMプラグインなどのスナップショットを作成できるドライバーで作成されたストレージプールを使用する必要があります。
LINSTOR 用のLVMを使用したシンプロビジョニングされたストレージのこの例では、各ストレージノードでLVMを使用してボリュームグループとthinLVを作成する必要があります。
以下は 2つの物理ボリューム (/dev/sdX と /dev/sdY) とボリュームグループおよびシンプールの一般名を使用したこの構成例です。 thinLVのメタデータボリュームを適切なサイズに設定してください。一度いっぱいになると、サイズ変更が困難になる場合があります。
pvcreate /dev/sdX /dev/sdY vgcreate drbdpool /dev/sdX /dev/sdY lvcreate -l 95%VG --poolmetadatasize 8g -T /dev/drbdpool/drbdthinpool
次に、これを下位ストレージとして使用して、LINSTOR にストレージプールを作成します。
ZFSストレージプールまたは thick-LVM を使用している場合は、LINSTOR_CLONE_MODE の copy を使わないと ZFS
の親子スナップショットの関係のために、linstor リソースを削除するときに問題が発生します。
|
7.4.3. 管理アカウントの権限
oneadmin
ユーザーには、ストレージノードで mkfs
コマンドへのパスワードなしsudoアクセス権が必要です。
oneadmin ALL=(root) NOPASSWD: /sbin/mkfs
7.4.4. 新しい LINSTOR データストアの作成
ds.conf という名前のデータストア設定ファイルを作成し、 onedatastore
ツールを使用して、その設定に基づいて新しいデータストアを作成します。相互に排他的な2つの配備オプション LINSTOR_AUTO_PLACE と
LINSTOR_DEPLOYMENT_NODES があります。両方が設定されている場合、LINSTOR_AUTO_PLACE
は無視されます。どちらのオプションでも、BRIDGE_LIST は LINSTOR
クラスター内のすべてのストレージノードのスペース区切りリストである必要があります。
7.4.5. リソースグループの作成
バージョン1.0.0以降、LINSTORはリソースグループをサポートしています。リソースグループは、そのリソースグループにリンクされているすべてのリソースが共有する設定の一元化されたポイントです。
データストアのリソースグループとボリュームグループを作成します。リソースグループ内でストレージプールを指定する必要があります。指定しないと、OpenNebula
のスペースの監視が機能しません。ここでは2ノードの冗長性を持つものを作成し、作成された opennebula-storagepool
を使用します。
linstor resource-group create OneRscGrp --place-count 2 --storage-pool opennebula-storagepool linstor volume-group create OneRscGrp
LINSTOR プラグインを使用して OpenNebula データストアを追加します。
cat >ds.conf <<EOI NAME = linstor_datastore DS_MAD = linstor TM_MAD = linstor TYPE = IMAGE_DS DISK_TYPE = BLOCK LINSTOR_RESOURCE_GROUP = "OneRscGrp" COMPATIBLE_SYS_DS = 0 BRIDGE_LIST = "alice bob charlie" #node names EOI onedatastore create ds.conf
7.4.6. プラグインの属性
7.4.7. 廃止された属性
次の属性は非推奨であり、バージョン 2.0 で削除されました。
LINSTOR_CLONE_MODE
LINSTOR は、使用するクローンモードを自動的に決定するようになりました。
LINSTOR は snapshot
と copy
の2つの異なるクローンモードをサポートしています。これらのモードは
LINSTOR_CLONE_MODE
属性で設定されます。
デフォルトのモードは snapshot
で、linstorスナップショットを使用し、このスナップショットから新しいリソースを復元します。このスナップショットはイメージのクローンになります。通常、スナップショットは最低限のコピーであるため、このモードは
copy
モードを使用するよりも高速です。
2番目のモードは copy
モードで、元のサイズと同じサイズの新しいリソースを作成し、 dd
でデータを新しいリソースにコピーします。このモードは snapshot
よりも遅くなりますが、スナップショットメカニズムに依存しないため、より堅牢です。別のlinstorデータストアにイメージをクローンする場合にも使用されます。
LINSTOR_STORAGE_POOL
LINSTOR_STORAGE_POOL
属性は、データストアが使用するLINSTORストレージプールを選択するために使用されます。リソースグループが使用される場合、ストレージプールは自動選択フィルターオプションで選択できるため、この属性は必要ありません。
LINSTOR_AUTO_PLACE
または LINSTOR_DEPLOYMENT_NODES
が使用され、LINSTOR_STORAGE_POOL
が設定されていない場合、LINSTORで DfltStorPool
にフォールバックします。
7.4.8. システムデータストアとしての LINSTOR を構成
LINSTOR ドライバーはシステムデータストアとしても使用できます。構成は通常のデータストアとかなり似ていますが、いくつか相違があります。
cat >system_ds.conf <<EOI NAME = linstor_system_datastore TM_MAD = linstor TYPE = SYSTEM_DS LINSTOR_RESOURCE_GROUP = "OneSysRscGrp" BRIDGE_LIST = "alice bob charlie" # node names EOI onedatastore create system_ds.conf
また、新しいsysデータストアIDをイメージデータストア(COMMA区切り)の COMPATIBLE_SYS_DS
に追加します。そうしないと、スケジューラはそれらを無視します。
揮発性ディスクを使用したライブマイグレーションが必要な場合は、KVMの --unsafe
オプションを有効にする必要があります。https://docs.opennebula.org/5.8/deployment/open_cloud_host_setup/kvm_driver.html
を参照してください。
7.6. 空き容量の計算
空き容量は、リソースが自動的に配備されるか、ノードごとに配備されるかに応じて異なって計算されます。
ノードごとに配置されるデータストアでは、リソースが配備されているすべてのノードの最も制限的なストレージプールに基づいて空き領域がレポートされます。たとえば、総ストレージ容量の最小値を持つノードの容量を使用してデータストアの合計サイズを決定し、空き容量が最小のノードを使用してデータストアの残りの容量を決定します。
自動配置を使用するデータストアの場合、サイズと残りの領域は、LINSTORによって報告されたデータストアで使用される集約ストレージプールに基づいて決定されます。
8. OpenStackでのLINSTORボリューム
この章では、LINSTOR を使用して、Openstack 用の永続的で複製された高性能のブロックストレージをプロビジョニングする方法について説明します。
8.1. OpenStack の紹介
Openstack は、さまざまな個別のサービスで構成されています。ブロックストレージのプロビジョニングと管理を担当するサービスは Cinder と呼ばれます。コンピューティングインスタンスサービス Nova などの他の openstack サービスは、Cinder にボリュームをリクエストできます。その後、Cinder は、要求元のサービスがボリュームにアクセスできるようにします。
LINSTOR は、ボリュームドライバーを使用して Cinder と統合できます。ボリュームドライバーは、CinderAPI への呼び出しを LINSTOR コマンドに変換します。例えば Cinderにボリュームを要求すると、LINSTOR に新しいリソースが作成され、Cinder ボリュームのスナップショットは LINSTOR のスナップショットに変換されます。
8.2. OpenStack 用の LINSTOR のインストール
OpenStack ドライバーを使用する前に、DRBD と LINSTOR の初期インストールと構成を完了する必要があります。
-
インストールガイドの詳細は こちら を参照ください。また以下も参照ください。
この時点で、LINSTOR クライアントを使用してストレージクラスターノードを一覧表示できるはずです。
╭────────────────────────────────────────────────────────────────────────────╮
┊ Node ┊ NodeType ┊ Addresses ┊ State ┊
╞════════════════════════════════════════════════════════════════════════════╡
┊ cinder-01.openstack.test ┊ COMBINED ┊ 10.43.224.21:3366 (PLAIN) ┊ Online ┊
┊ cinder-02.openstack.test ┊ COMBINED ┊ 10.43.224.22:3366 (PLAIN) ┊ Online ┊
┊ storage-01.openstack.test ┊ SATELLITE ┊ 10.43.224.11:3366 (PLAIN) ┊ Online ┊
┊ storage-02.openstack.test ┊ SATELLITE ┊ 10.43.224.12:3366 (PLAIN) ┊ Online ┊
┊ storage-03.openstack.test ┊ SATELLITE ┊ 10.43.224.13:3366 (PLAIN) ┊ Online ┊
╰────────────────────────────────────────────────────────────────────────────╯
また、ノードごとに 1 つ以上の ストレージプール
を構成する必要があります。このガイドでは、ストレージプールの名前が cinderpool
であると仮定しています。LINSTOR は
デフォルトで作成されたディスクレスストレージプールを含む、各ノードのストレージプールを一覧表示します。
$ linstor storage-pool list
╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
┊ StoragePool ┊ Node ┊ Driver ┊ PoolName ┊ FreeCapacity ┊ TotalCapacity ┊ CanSnapshots ┊ State ┊
╞═════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╡
┊ DfltDisklessStorPool ┊ cinder-01.openstack.test ┊ DISKLESS ┊ ┊ ┊ ┊ False ┊ Ok ┊
┊ DfltDisklessStorPool ┊ cinder-02.openstack.test ┊ DISKLESS ┊ ┊ ┊ ┊ False ┊ Ok ┊
┊ DfltDisklessStorPool ┊ storage-01.openstack.test ┊ DISKLESS ┊ ┊ ┊ ┊ False ┊ Ok ┊
┊ DfltDisklessStorPool ┊ storage-02.openstack.test ┊ DISKLESS ┊ ┊ ┊ ┊ False ┊ Ok ┊
┊ DfltDisklessStorPool ┊ storage-03.openstack.test ┊ DISKLESS ┊ ┊ ┊ ┊ False ┊ Ok ┊
┊ cinderpool ┊ storage-01.openstack.test ┊ LVM_THIN ┊ ssds/cinderpool ┊ 100 GiB ┊ 100 GiB ┊ True ┊ Ok ┊
┊ cinderpool ┊ storage-02.openstack.test ┊ LVM_THIN ┊ ssds/cinderpool ┊ 100 GiB ┊ 100 GiB ┊ True ┊ Ok ┊
┊ cinderpool ┊ storage-03.openstack.test ┊ LVM_THIN ┊ ssds/cinderpool ┊ 100 GiB ┊ 100 GiB ┊ True ┊ Ok ┊
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
8.2.1. LINSTOR ドライバをアップグレード
新規インストールの場合、このセクションをスキップして LINSTOR ドライバをインストール に進んでください。
1.x から 2.x へのアップグレード
ドライバーバージョン 2 は、実行時に ボリュームタイプ でこれらのオプションを管理するため、いくつかの静的構成オプションを削除しました。
Option in cinder.conf |
Status | Replace with |
---|---|---|
|
削除 |
ボリュームタイプで |
|
削除 |
置き換えは必要ありません。ドライバーは必要に応じて cinder ホスト上にディスクレスリソースを作成します |
|
削除 |
この設定は効果がありませんでした |
|
非推奨 |
この設定は、将来のバージョンで削除するために非推奨になりました。代わりに、ボリュームタイプで |
|
非推奨 |
より適切な名前の |
|
削除 |
ノードとストレージプールの作成は、ドライバーバージョン 2 で削除されました。OpenStack 用の LINSTOR のインストール を参照してください |
|
削除 |
この設定は目的を果たさず、置き換えなしで削除されました |
8.2.2. LINSTOR ドライバをインストール
OpenStack Stein 以降、LINSTOR ドライバーは Cinder プロジェクトの一部です。ドライバはそのまま使用できますが、新しいバージョンで利用できる機能や修正が不足している可能性があります。安定バージョンの OpenStacks 更新ポリシーにより、ドライバーに対するほとんどの改善は、古い安定リリースにバックポートされません。
LINBIT は Cinder リポジトリーの フォーク をメンテナンスしています。ここには、サポートされている安定したバージョンにバックポートされた LINSTOR ドライバーのすべての改善が含まれています。現在、これらは次のとおりです。
OpenStack Release | Included Version | LINBIT Version | LINBIT Branch |
---|---|---|---|
|
1.0.1 |
2.0.0 |
|
|
1.0.1 |
2.0.0 |
|
|
1.0.1 |
2.0.0 |
|
|
1.0.1 |
2.0.0 |
|
|
1.0.1 |
2.0.0 |
|
|
1.0.0 |
2.0.0 |
|
|
1.0.0 |
2.0.0 |
LINSTOR Driver を有効にする正しい手順は、OpenStack ディストリビューションによって異なります。一般に
python-linstor
パッケージは、Cinder
ボリュームサービスを実行しているすべてのホストにインストールする必要があります。次のセクションでは、一般的な OpenStack
ディストリビューションへのインストール手順について説明します。
DevStack でインストール
DevStack は、ラボ環境で OpenStack を試すのに最適な方法です。最新のドライバーを使用するには、次の DevStack 構成を使用します。
# This ensures the LINSTOR Driver has access to the 'python-linstor' package. # # This is needed even if using the included driver! USE_VENV=True ADDITIONAL_VENV_PACKAGES=python-linstor # This is required to select the LINBIT version of the driver CINDER_REPO=https://github.com/LINBIT/openstack-cinder.git # Replace linstor/stable/victoria with the reference matching your OpenStack release. CINDER_BRANCH=linstor/stable/victoria
Kolla でインストール
Kolla は OpenStack コンポーネントをコンテナーにパッケージ化します。次に、例えば Kolla Ansible を使用してデプロイできます。kolla コンテナーで使用可能なカスタマイズオプションを利用して、LINSTOR ドライバーをセットアップできます。
必要な python-linstor
パッケージがインストールされるようにするには、次のオーバーライドファイルを使用します。
{% extends parent_template %}
# Cinder
{% set cinder_base_pip_packages_append = ['python-linstor'] %}
LINBIT バージョンのドライバーをインストールするには kolla-build.conf
を更新します。
[cinder-base] type = git location = https://github.com/LINBIT/openstack-cinder.git # Replace linstor/stable/victoria with the reference matching your OpenStack release. reference = linstor/stable/victoria
Cinder コンテナを再構築するには、次のコマンドを実行します。
# A private registry used to store the kolla container images
REGISTRY=deployment-registry.example.com
# The image namespace in the registry
NAMESPACE=kolla
# The tag to apply to all images. Use the release name for compatibility with kolla-ansible
TAG=victoria
kolla-build -t source --template-override template-override.j2 cinder --registry $REGISTRY --namespace $NAMESPACE --tag $TAG
Kolla Ansible デプロイメント
Kolla Ansible を使用して OpenStack をデプロイする場合は、次のことを確認する必要があります。
-
上記のセクションで作成されたカスタム Cinder イメージは、Cinder サービスのデプロイメントが有効になっている場合に使用されます。
# use "source" images
kolla_install_type: source
# use the same registry as for running kolla-build above
docker_registry: deployment-registry.example.com
# use the same namespace as for running kolla-build above
docker_namespace: kolla
# deploy cinder block storage service
enable_cinder: "yes"
# disable verification of cinder back ends, kolla-ansible only supports a small subset of available back ends for this
skip_cinder_backend_check: True
# add the LINSTOR back end to the enabled back ends. For back end configuration see below
cinder_enabled_backends:
- name: linstor-drbd
LINSTOR ドライバー構成は kolla-ansible のオーバーライドディレクトリの 1 つに配置できます。使用可能な構成オプションの詳細については、以下のセクションを参照してください。
[linstor-drbd] volume_backend_name = linstor-drbd volume_driver = cinder.volume.drivers.linstordrv.LinstorDrbdDriver linstor_uris = linstor://cinder-01.openstack.test,linstor://cinder-02.openstack.test
OpenStack Ansible デプロイメント
OpenStack Ansible は、OpenStack 環境を構成およびデプロイするための Ansible プレイブックを提供します。これにより、デプロイメントをきめ細かくカスタマイズできるため、LINSTOR ドライバーを直接セットアップできます。
cinder_git_repo: https://github.com/LINBIT/openstack-cinder.git cinder_git_install_branch: linstor/stable/victoria cinder_user_pip_packages: - python-linstor cinder_backends: (1) linstor-drbd: volume_backend_name: linstor-drbd volume_driver: cinder.volume.drivers.linstordrv.LinstorDrbdDriver linstor_uris: linstor://cinder-01.openstack.test,linstor://cinder-02.openstack.test
1 | 使用可能なバックエンドパラメータの詳細な説明は、以下のセクションにあります。 |
汎用 Cinder デプロイメント
他の形式の OpenStack デプロイメントの場合、このガイドでは一般的なヒントのみを提供できます。
LINSTOR ドライバーのバージョンを更新するには、インストールされた cinder ディレクトリを見つけてください。考えられるパスは次のとおりです。
/usr/lib/python*/dist-packages/cinder/ /usr/lib/python*/site-packages/cinder/
LINSTOR ドライバーは、cinder ディレクトリにある linstordrv.py
というファイルです。
$CINDER_PATH/volume/drivers/linstordrv.py
ドライバを更新するには、ファイルを LINBIT リポジトリのファイルに置き換えます
RELEASE=linstor/stable/victoria curl -fL "https://raw.githubusercontent.com/LINBIT/openstack-cinder/$RELEASE/cinder/volume/drivers/linstordrv.py" > $CINDER_PATH/volume/drivers/linstordrv.py
登録されたものを更新するには、Python キャッシュを削除する必要がある場合もあります。
rm -rf $CINDER_PATH/volume/drivers/__pycache__
8.3. Cinder 用の LINSTOR バックエンドを構成
LINSTOR ドライバーを使用するには、Cinder ボリュームサービスを構成します。Cinder 構成ファイルを編集してから、Cinder ボリュームサービスを再起動することで構成できます。
ほとんどの場合、Cinder 構成ファイルは /etc/cinder/cinder.conf
にあります。一部のデプロイメントでは、このファイルを事前に編集できます。詳細は上記のセクションを参照してください。
LINSTOR を使用して新しいボリュームバックエンドを構成するには、次のセクションを cinder.conf
に追加します。
[linstor-drbd] volume_backend_name = linstor-drbd (1) volume_driver = cinder.volume.drivers.linstordrv.LinstorDrbdDriver (2) linstor_uris = linstor://cinder-01.openstack.test,linstor://cinder-02.openstack.test (3) linstor_trusted_ca = /path/to/trusted/ca.cert (4) linstor_client_key = /path/to/client.key (5) linstor_client_cert = /path/to/client.cert (5) # Deprecated or removed in 2.0.0 linstor_default_storage_pool_name = cinderpool (6) linstor_autoplace_count = 2 (7) linstor_controller_diskless = true (8) # non-linstor-specific options ... (9)
ここで説明するパラメーターは、Linbit が提供する最新のリリースに基づいています。 OpenStack に含まれているドライバーは、これらのパラメーターのすべてをサポートしているとは限りません。詳細は OpenStack ドライバーのドキュメント を参照ください。 |
1 | ボリュームバックエンド名。 Cinder 構成で一意である必要があります。セクション全体で同じ名前を共有する必要があります。この名前は
enabled_backends 設定の cinder.conf で、および新しいボリュームタイプを作成するときに再び参照されます。 |
||
2 | 使用する LINSTOR ドライバーのバージョン。2 つのオプションがあります。
|
||
3 | LINSTOR コントローラーの URL。 Linstor 高可用性
を利用するために、複数のコントローラーを指定できます。設定されていない場合、デフォルトは linstor://localhost です。
|
||
4 | HTTPS が有効の場合、 指定された証明書を使用して LINSTOR コントローラーの信頼性を検証します。 | ||
5 | HTTPS が有効の場合、 指定されたキーと証明書が、認証のために LINSTOR コントローラーで使用されます。 | ||
6 | 2.0.0 で非推奨になったので、代わりに volume types を使用してください。リソースを配置するときに使用するストレージプール。作成されたすべてのディスクフルリソースに |