LINSTOR ユーザーズガイド
はじめにお読みください
このガイドは、software-defined storage (SDS) ソリューションである LINSTOR® のリファレンスガイドおよびハンドブックとして使用することを目的としています。
| このガイドは全体を通して、あなたがLINSTORと関連ツールの最新版を使っていると仮定します。 |
このガイドは次のように構成されています。
-
LINSTORの紹介 は、LINSTORの基本的な概要であり、LINSTORの概念や用語の説明を提供しています。
-
基本管理タスクとシステム設定 ではLINSTORの基本的な機能を扱い、一般的な管理作業を使用するための方法を提供します。この章ではそれ以外に、LINSTORの基本設定を配備するためのステップバイステップのガイドとして使用できます。
-
LINSTOR 応用タスク では、さまざまな高度で重要な LINSTOR タスクや構成を示しており、より複雑な方法で LINSTOR を使用できます。
-
GUIを使用したLINSTORの管理 は、LINBIT®の顧客に提供されているLINSTORクラスターを管理するためのグラフィカルクライアントアプローチに関する情報です。
-
LINSTOR Integrations には、 Kubernetes 、 Proxmox VE 、 OpenNebula 、 Docker 、 OpenStack などのさまざまなプラットフォームやテクノロジーと組み合わせて、LINSTORベースのストレージソリューションを実装する方法について取り扱った章があります。これらは LINSTOR API を使用しています。
LINSTORについて
1. LINSTORの紹介
LINSTOR®を効果的に使用するためには、この「LINSTORの概要」章がソフトウェアの概要を提供し、その動作方法やストレージの展開方法を説明し、重要な概念や用語を紹介して説明することで、理解を助けます。
1.1. LINSTORの概要
LINBIT社が開発したオープンソースの構成管理システム、LINSTORは、Linuxシステム上のストレージを管理します。このシステムは、ノードのクラスター上でLVM論理ボリュームやZFS ZVOLを管理し、異なるノード間での複製にDRBDを使用してユーザーやアプリケーションにブロックストレージデバイスを提供します。スナップショット、暗号化、HDDバックアップデータのSSDへのキャッシングなど、いくつかの機能があります。
1.1.1. LINSTOR はどこで使用されているのか
LINSTORはもともとDRBDリソースを管理するために開発されました。まだLINSTORを使用してDRBDを管理することができますが、LINSTORは進化し、より便利になったり、それらのスタック内で可能な範囲を超えてより簡単に永続ストレージを提供するために、しばしば上位のソフトウェアスタックと統合されています。
LINSTORは単体で使用することもできますし、Kubernetes、OpenShift、OpenNebula、OpenStack、Proxmox VEなどの他のプラットフォームと統合することも可能です。LINSTORは、オンプレミスのベアメタル環境で実行することもできますし、仮想マシン（VM）、コンテナ、クラウド、ハイブリッド環境でも利用することができます。
1.1.2. LINSTORがサポートするストレージと関連技術
LINSTORは、次のストレージプロバイダーおよび関連技術と連携して動作することができます:
-
LVM and LVM thin volumes
-
ZFS and ZFS thin volumes
-
File and FileThin (loop devices)
-
Diskless
-
SPDK (remote)
-
Microsoft Windows Storage Spacesおよびthin Storage Spaces
-
EBS (target and initiator)
-
Device mapper cache (
dm-cache) とwritecache (dm-writecache) -
bcache
-
LUKS
-
DRBD
LINSTORを使用することで、これらのテクノロジーを単独で扱うか、またはさまざまな有益な組み合わせで使用することができます。
1.2. LINSTORの動作原理
機能するLINSTORセットアップには、linstor-controller.service というsystemdサービスとして実行されるアクティブなコントローラーノードが1つ必要です。これはLINSTORコントロールプレーンであり、LINSTORコントローラーノードがLINSTORサテライトノードと通信する場所です。
セットアップには、LINSTORサテライトソフトウェアをsystemdサービスとして実行する1つ以上のサテライトノードが必要です。LINSTORサテライトサービスは、ノード上でストレージや関連アクションを容易にします。たとえば、ユーザーやアプリケーションにデータストレージを提供するためにストレージボリュームを作成することができます。ただし、サテライトノードはクラスタに物理ストレージを提供する必要はありません。例えば、DRBDクォーラムの目的でLINSTORクラスタに参加する「ディスクレス」サテライトノードを持つことができます。
| ノードがLINSTORコントローラーとサテライトサービスの両方を実行し、”Combined”の役割を果たすことも可能です。 |
ストレージ技術は、例えばDRBDレプリケーションなどとして実装されたLINSTORサテライトノード上で考えることができます。LINSTORでは、コントロールとデータ面が分離されており、独立して機能することができます。つまり、例えばLINSTORコントローラーノードやLINSTORコントローラーソフトウェアを更新する際も、LINSTORサテライトノードはユーザーやアプリケーションに中断することなくストレージを提供し（およびDRBDを使用してレプリケートする場合は）、機能を維持することができます。
このガイドでは、便宜上、LINSTORセットアップはしばしば「LINSTORクラスター」と呼ばれますが、有効なLINSTORセットアップは、Kubernetesなどの他のプラットフォーム内で統合として存在することがあります。
ユーザーは、CLIベースのクライアントやグラフィカルユーザーインタフェース（GUI）を使用してLINSTORとやり取りすることができます。これらのインタフェースは、LINSTOR REST APIを利用しています。また、LINSTORは、このAPIを使用するプラグインやドライバを利用して、他のプラットフォームやアプリケーションと統合することができます。
LINSTORコントローラーとREST API間の通信はTCP/IPを介して行われ、SSL/TLSを使用してセキュリティを確保することができます。
LINSTORが物理ストレージとやり取りするために使用する南行きのドライバーは、LVM、thinLVM、およびZFSです。
1.3. インストール可能なコンポーネント
LINSTORのセットアップには、インストール可能なコンポーネントが3つあります：
-
LINSTOR controller
-
LINSTOR satellite
-
LINSTOR user interfaces (LINSTOR client and LINBIT SDS GUI)
これらのインストール可能なコンポーネントは、コンパイルできるソースコードであるか、または事前にビルドされたパッケージであり、ソフトウェアをインストールして実行するために使用できます。
1.3.1. LINSTOR controller
linstor-controller サービスは、クラスタ全体の構成情報を保持するデータベースに依存しています。LINSTORコントローラーソフトウェアを実行しているノードやコンテナは、リソース配置、リソース構成、およびクラスタ全体の状態を必要とするすべての運用プロセスのオーケストレーションを担当しています。
LINSTORでは複数のコントローラを使用することができます。たとえば、 高可用性のLINSTORクラスタを設定する ときには、複数のコントローラを利用することができます。ただし、アクティブなコントローラは1つだけです。
前述のように、LINSTORコントローラーは、管理するデータプレーンとは別のプレーンで動作します。コントローラーサービスを停止し、コントローラーノードを更新または再起動しても、LINSTORサテライトノードにホストされているデータにアクセスできます。LINSTORサテライトノード上のデータには引き続きアクセスし、提供することができますが、実行中のコントローラーノードがないと、サテライトノードでのLINSTORの状態や管理タスクを実行することはできません。
1.3.2. LINSTOR satellite
linstor-satellite サービスは、LINSTORがローカルストレージを利用するか、サービスにストレージを提供する各ノードで実行されます。このサービスはステートレスであり、LINSTORコントローラーサービスを実行しているノードまたはコンテナから必要なすべての情報を受け取ります。 LINSTORサテライトサービスは、lvcreate や`drbdadm` などのプログラムを実行します。それは、LINSTORコントローラーノードまたはコンテナから受け取った命令を実行するノード上またはコンテナ内のエージェントのように機能します。
1.3.3. LINSTOR ユーザーインターフェース
LINSTORとのインターフェースを行う必要がある場合、そのアクティブなLINSTORコントローラーに指示を送信するには、LINSTORクライアント、またはLINBIT SDS GUIのどちらかのユーザーインターフェース(UI)を使用できます。
これらのUIは、両方ともLINSTORの REST API に依存しています。
LINSTOR クライアント
「linstor」というLINSTORクライアントは、アクティブなLINSTORコントローラーノードにコマンドを送信するためのコマンドラインユーティリティです。これらのコマンドは、クラスタ内のストレージリソースを作成または変更するようなアクション指向のコマンドである場合もありますし、LINSTORクラスタの現在の状態に関する情報を収集するためのステータスコマンドである場合もあります。
LINSTORクライアントは、有効なコマンドと引数を続けて入力することで使用することもできますし、クライアントの対話モードでは、単に linstor と入力することで使用することができます。
LINSTORクライアントの使用方法に関する詳細情報は、このユーザーガイドのLINSTORクライアントの使用 セクションで見つけることができます。
# linstor Use "help <command>" to get help for a specific command. Available commands: - advise (adv) - backup (b) - controller (c) - drbd-proxy (proxy) - encryption (e) - error-reports (err) - file (f) - help - interactive - key-value-store (kv) - list-commands (commands, list) - node (n) - node-connection (nc) - physical-storage (ps) - remote - resource (r) - resource-connection (rc) - resource-definition (rd) - resource-group (rg) - schedule (sched) - snapshot (s) - sos-report (sos) - space-reporting (spr) - storage-pool (sp) - volume (v) - volume-definition (vd) - volume-group (vg) LINSTOR ==>
LINBIT SDS グラフィカルユーザーインターフェース
LINBIT SDSのグラフィカルユーザーインターフェース(GUI)は、LINSTORと連携して使用できるWebベースのGUIです。これは、LINSTORクラスターに関する概要情報を取得したり、クラスター内のLINSTORオブジェクトを追加、変更、削除したりする便利な方法となります。例えば、ノードを追加したり、リソースを追加・削除したり、その他のタスクを実行したりすることができます。
このユーザーガイドでは、GUIインターフェースの使用方法については、 LINBIT SDS GUIチャプター で詳細をご覧いただけます。
1.4. 内部コンポーネント
LINSTORの内部コンポーネントは、LINSTORがどのように機能し、どのように使用するかを表現するために使用されるソフトウェアコードの抽象化です。内部コンポーネントの例として、LINSTORオブジェクトであるリソースやストレージプールが挙げられます。これらは抽象化されていますが、LINSTORクライアントまたはGUIを使用してストレージを展開し管理する際に、非常に現実的な方法でそれらとやり取りします。
このセクションでは、LINSTORの動作原理や使用方法を理解するために必要な基本概念や用語を紹介し、説明しています。
1.4.1. LINSTOR オブジェクト
LINSTORは、ソフトウェア定義ストレージ（SDS）に対してオブジェクト指向のアプローチを取っています。LINSTORオブジェクトは、ユーザーやアプリケーションが利用するか、または拡張するためにLINSTORが提供する最終成果物です。
以下に、最も一般的に使用されるLINSTORのオブジェクトが説明されており、その後に全リストが続きます。
リソース
リソースとは、アプリケーションやエンドユーザーに提示される消費可能なストレージを表すLINSTORオブジェクトのことです。LINSTORが工場であるならば、リソースはそれが生産する製品です。多くの場合、リソースはDRBD複製ブロックデバイスですが、必ずしもそうである必要はありません。例えば、DRBDのクォーラム要件を満たすためにディスクレスなリソースであったり、NVMe-oFやEBSイニシエータである場合もあります。
リソースは以下の属性を持っています：
-
リソースが存在するノードの名前
-
そのリソースが属するリソース定義
-
リソースの構成プロパティ
ボリューム
ボリュームは、物理ストレージに最も近いLINSTORの内部コンポーネントであり、リソースのサブセットです。1つのリソースに複数のボリュームを持つことができます。例えば、MySQLクラスターの中で、データベースをトランザクションログよりも遅いストレージに保存したい場合があります。LINSTORを使用してこれを実現するためには、より高速なトランザクションログストレージメディア用の1つのボリュームと、より遅いデータベースストレージメディア用の別のボリュームを持ち、どちらも単一の「MySQL」リソースの下に配置します。1つのリソースの下に複数のボリュームを保持することで、実質的にコンシステンシーグループを作成しています。
ボリュームに指定した属性は、LINSTORオブジェクト階層の上位で同じ属性が指定されている場合よりも優先されます。これは、再度述べるように、ボリュームが物理ストレージに最も近い内部的なLINSTORオブジェクトであるためです。
ノード
Nodeとは、LINSTORクラスタに参加するサーバーまたはコンテナのことです。Nodeオブジェクトには、以下の属性があります。
-
名前
-
IP アドレス
-
TCP ポーと
-
ノードタイプ (controller, satellite, combined, auxiliary)
-
コミュニケーション型 (plain or SSL/TLS)
-
ネットワークインターフェース型
-
ネットワークインターフェース名
ストレージプール
ストレージプールは、他のLINSTORオブジェクト（LINSTORリソース、リソース定義、またはリソースグループ）に割り当てることができるストレージを識別し、LINSTORボリュームによって利用されることができます。
ストレージプール定義
-
クラスターノード上のストレージプールに使用するストレージバックエンドドライバーは、例えば、LVM、スリムプロビジョニングされたLVM、ZFS、その他です。
-
ストレージプールが存在するノード
-
ストレージプール名
-
ストレージプールの構成プロパティ
-
ストレージプールのバックエンドドライバー（LVM、ZFS、その他）に渡す追加パラメータ
LINSTORオブジェクトのリスト
LINSTORには次のコアオブジェクトがあります：
EbsRemote |
ResourceConnection |
SnapshotVolumeDefinition |
ExternalFile |
ResourceDefinition |
StorPool |
KeyValueStore |
ResourceGroup |
StorPoolDefinition |
LinstorRemote |
S3Remote |
Volume |
NetInterface |
Schedule |
VolumeConnection |
Node |
Snapshot |
VolumeDefinition |
NodeConnection |
SnapshotDefinition |
VolumeGroup |
Resource |
SnapshotVolume |
1.4.2. 定義とグループオブジェクト
定義とグループもLINSTORオブジェクトですが、特別な種類です。定義とグループのオブジェクトは、プロファイルやテンプレートと考えることができます。これらのテンプレートオブジェクトは、親オブジェクトの属性を継承する子オブジェクトを作成するために使用されます。また、子オブジェクトに影響を与える可能性のある属性を持つこともありますが、それは子オブジェクト自体の属性ではありません。これらの属性には、たとえば、DRBDレプリケーションに使用するTCPポートや、DRBDリソースが使用するボリューム番号などが含まれる可能性があります。
Definitions
Definitions はオブジェクトの属性を定義します。定義から作成されたオブジェクトは、定義された構成属性を継承します。子オブジェクトを作成する前に、その関連する定義を作成する必要があります。例えば、対応するリソースを作成する前に、リソースの定義を作成する必要があります。
LINSTORクライアントを使用して直接作成できる2つのLINSTOR定義オブジェクトがあります。リソースの定義とボリュームの定義です。
- リソースの定義
-
リソースの定義では、リソースの以下の属性を定義できます。
-
リソース定義が所属するリソースグループ
-
リソースの名前（暗黙的に、リソース定義の名前によって）
-
リソースの接続に使用するTCPポートは、たとえば、DRBDがデータをレプリケートしている場合に使用されます。
-
リソースの保存層、ピアスロット、外部名などの他の属性。
-
- ボリューム定義
-
ボリューム定義は次のように定義することができます:
-
ストレージ容量のサイズ
-
保存ボリュームのボリューム番号（リソースに複数のボリュームがある場合があるため）
-
ボリュームのメタデータのプロパティ
-
DRBDレプリケーションストレージに関連付けられたボリュームに使用するマイナーナンバー
-
これらの定義に加えて、LINSTORにはいくつかの間接的な定義があります。それは、ストレージプール定義、スナップショット定義、およびスナップショットボリューム定義です。LINSTORは、対応するオブジェクトを作成する際にこれらを自動的に作成します。
グループ
グループは、プロファイルやテンプレートのような役割を持つため、定義と似ています。定義はLINSTORオブジェクトのインスタンスに適用されるのに対して、グループはオブジェクトの定義に適用されます。名前が示す通り、1つのグループは複数のオブジェクト定義に適用でき、1つの定義が複数のオブジェクトインスタンスに適用できるという点で類似しています。たとえば、頻繁に必要なストレージユースケースのためのリソース属性を定義するリソースグループを持つことができます。その後、そのリソースグループを使用して、その属性を持つ複数のリソースを簡単に生成（作成）できます。リソースを作成するたびに属性を指定する必要がなくなります。
- リソースグループ
-
リソースグループは、リソース定義の親オブジェクトであり、リソースグループ上で行われたすべてのプロパティ変更は、そのリソース定義の子供たちに引き継がれます。リソースグループ上で行われたプロパティの変更は、対応する
.resリソースファイルに反映されることになります。ただし、親で行われたプロパティ変更は子オブジェクト（リソース定義またはリソースLINSTORオブジェクト）にコピーされないため、子オブジェクト自体はそのプロパティを持ちません。変更はオブジェクトの子供に影響しますが、プロパティ自体は親に残ります。リソースグループには、自動配置ルールの設定も保存され、保存されたルールに基づいてリソース定義を生成することもできます。リソースグループは、そのリソース定義の子オブジェクトの特性を定義します。リソースグループから生成されるリソース、またはリソースグループに属するリソース定義から作成されるリソースは、リソースグループの「孫」オブジェクトであり、リソース定義の「子」オブジェクトとなります。リソース定義を作成するたびに、指定しない限り、デフォルトのLINSTORリソースグループである
DfltRscGrpのメンバーとなります。リソースグループへの変更は、リソースグループから作成されたすべてのリソースやリソース定義に遡及して適用されます。ただし、同じ特性が子オブジェクト（例: リソース定義やリソース）に設定されている場合は、その特性は適用されません。
これにより、リソースグループを使用することは、多数のストレージリソースを効率的に管理するための強力なツールとなります。個々のリソースを作成または修正する代わりに、リソースグループの親を構成するだけで、すべての子リソースオブジェクトに構成が適用されます。
- ボリュームグループ
-
同様に、ボリュームグループはボリュームの定義のためのプロファイルやテンプレートのようなものです。ボリュームグループは常に特定のリソースグループを参照しなければなりません。さらに、ボリュームグループはボリューム番号と「総」ボリュームサイズを定義することができます。
1.5. LINSTORのオブジェクト階層
この章の前のサブセクションでほのめかされた通り、LINSTORオブジェクトには階層概念が存在します。文脈によっては、これを親子関係として説明することもできますし、上位と下位の関係として説明することもできます。ここで下位とは、物理ストレージレイヤーに近いことを意味します[注: 物理ストレージは、例えば「ディスクレス」ノードのように、特定のノードに存在しない場合があります。ここでの「物理ストレージ」レイヤーは、LINSTORにおけるオブジェクトの階層構造を概念化するための架空のものです。]。
子要素は、親要素に定義された属性を継承しますが、子要素で既に定義されている場合を除きます。同様に、下位要素は、上位要素に設定された属性を受け取りますが、下位要素で既に定義されている場合を除きます。
1.5.1. LINSTORにおけるオブジェクト階層の一般的なルール
次に、LINSTORにおけるオブジェクト階層の一般的なルールがいくつかあります：
-
LINSTORオブジェクトは、そのオブジェクトに設定できる属性のみを受け取るか継承できます。
-
上位のオブジェクトに設定された属性は、下位のオブジェクトにも引き継がれます。
-
下位オブジェクトに設定された属性は、上位オブジェクトに設定された同じ属性より優先されます。
-
子オブジェクトは、親オブジェクトに設定されている属性を継承します。
-
子オブジェクトに設定された属性は、親オブジェクトに設定された同じ属性よりも優先されます。
1.5.2. LINSTORオブジェクト間の関係を示すための図を使用する
このセクションでは、最も頻繁に使用されるLINSTORオブジェクト間の階層関係を表す図を使用しています。LINSTORオブジェクトの数とそれらの相互関係のため、概念化を簡素化するために、1つの図ではなく複数の図を最初に表示しています。
次の図は、単一のサテライトノード上でのLINSTORグループオブジェクト間の関係を示しています。
前の2つの図は、一般的なLINSTORオブジェクト間の上位下位の関係を示していますが、LINSTORオブジェクトの中には親子関係を持つものも考えられます。次の図では、ストレージプールの定義（親オブジェクト）とストレージプール（子オブジェクト）を例に、この種の関係が紹介されています。親オブジェクトは複数の子オブジェクトを持つことができます。そのような関係を示す図が以下に示されています。
概念図で親子関係の概念を導入した後、次の図は、グループや定義に一部の関係を追加した第2図の修正版です。この修正図には、最初の図で示された上位-下位の関係も一部取り入れられています。
次のダイアグラムは、以前のダイアグラムの関係性の概念を統合しつつ、スナップショットや接続に関連する新しいLINSTORオブジェクトを紹介しています。さまざまなオブジェクトと交差する線があるため、このダイアグラムへの構築の理由は明らかになるはずです。
前述の図は複雑なように見えますが、それでも簡略化されたものであり、LINSTORオブジェクト間の可能な関係のすべてを網羅しているわけではありません。前述したように、図に示されている以上に多くのLINSTORオブジェクトが存在します。[LINSTORは進化するソフトウェアであるため、特定のユースケースやコンテキストにおいては、オブジェクトのプロパティ階層が一般的なルールと異なることがある可能性があります。これらの場合には、文書で一般ルールへの例外に言及されます。]。
良いニュースは、LINSTORを扱う際に先行する図を暗記する必要がないということです。ただし、LINSTORオブジェクトに設定した属性、およびその他のLINSTORオブジェクトに対する継承と効果をトラブルシューティングしようとしている場合には参照すると役立つかもしれません。
LINSTORクラスターの管理
2. 基本管理タスクとシステム設定
これは、基本的なLINSTOR®管理タスクについて説明する「ハウツー」スタイルの章で、LINSTORのインストール方法やLINSTORの使用を始める方法がカバーされています。
2.1. LINSTORをインストールする前に
LINSTORをインストールする前に、LINSTORのインストール方法に影響を与える可能性があるいくつかのことを認識しておく必要があります。
2.1.1. パッケージ
LINSTOR は RPM と DEB 形式でパッケージングされています。
-
linstor-clientにはコマンドラインクライアントプログラムが含まれています。通常、これはすでにインストールされているPythonに依存しています。RHEL 8システムでは、pythonへのシンボリックリンクが必要になります。 -
linstor-controllerとlinstor-satelliteは、サービスのためのsystemdユニットファイルを含んでいます。これらは、Java実行環境（JRE）バージョン1.8（headless）以上に依存しています。
これらのパッケージについての詳細は インストール可能なコンポーネント を参照ください。
| LINBIT（R）サポート契約をお持ちであれば、LINBIT顧客専用リポジトリを通じて認定されたバイナリにアクセスできます。 |
2.1.2. FIPSコンプライアンス
この標準は、暗号モジュールの設計および実装に使用されます。 — NIST’s FIPS 140-3 publication
LINSTORを設定して、このユーザーガイドの Encrypted Volumes セクションに詳細が記載されているように、LUKS (dm-crypt) を使用してストレージボリュームを暗号化することができます。 FIPS 規格に準拠しているかどうかについては、LUKSと dm-crypt プロジェクトを参照してください。
LINSTORを構成して、LINSTORサテライトとLINSTORコントローラー間の通信トラフィックをSSL/TLSを使用して暗号化することもできます。このユーザーガイドの 安全なサテライト接続 セクションで詳細に説明されています。
LINSTORは、Self-Encrypting Drives (SEDs) ともインターフェースでき、SED ドライブを初期化する際に LINSTOR を使用することができます。LINSTOR は、ドライブのパスワードをそのドライブに関連付けられたストレージプールに適用するプロパティとして保存します。LINSTOR は、まず作成しなければならない LINSTOR マスターパスフレーズ を使用して、SED ドライブのパスワードを暗号化します。
デフォルトでは、LINSTOR は以下の暗号アルゴリズムを使用します:
-
HMAC-SHA2-512
-
PBKDF2
-
AES-128
このセクションで述べられているユースケース向けに、FIPS準拠バージョンのLINSTORが利用可能です。もし貴方や貴組織がこのレベルのFIPSコンプライアンスを必要とする場合は、詳細について[email protected]までお問い合わせください。
2.2. インストール
| コンテナで LINSTOR を使用する場合は、このセクションをスキップして、以下の Containers セクションを使用してインストールしてください。 |
2.2.1. ボリュームマネージャーのインストール
LINSTOR を使用してストレージボリュームを作成するには、LVM または ZFS のいずれかのボリュームマネージャーをシステムにインストールする必要があります。
2.2.2. LINBIT クラスターノードを管理するスクリプトの使用
LINBIT®のお客様であれば、LINBITが作成したヘルパースクリプトをダウンロードしてノード上で実行することができます。
-
クラスターノードをLINBITに登録する。
-
ノードを既存の LINBIT クラスターに参加させる。
-
ノードで LINBIT パッケージ リポジトリを有効にする。
LINBIT パッケージリポジトリを有効にすると、LINBIT ソフトウェアパッケージ、DRBD® カーネルモジュール、およびクラスタマネージャや OCF スクリプトなどの関連ソフトウェアにアクセスできるようになります。その後、パッケージマネージャを使用して、パッケージの取得、インストール、および更新済みパッケージの管理を行うことができます。
LINBIT Manage Node スクリプトをダウンロードします。
LINBITにクラスターノードを登録し、LINBITのリポジトリを構成するには、まず全てのクラスターノードで以下のコマンドを入力して、ノード管理ヘルパースクリプトをダウンロードして実行してください。
# curl -O https://my.linbit.com/linbit-manage-node.py # chmod +x ./linbit-manage-node.py # ./linbit-manage-node.py
root ユーザーとしてスクリプトを実行する必要があります。
|
このスクリプトは、 LINBIT カスタマーポータル のユーザー名とパスワードの入力を求めます。資格情報を入力すると、スクリプトはアカウントに関連付けられたクラスターノードを一覧表示します (最初は何もありません)。
LINBIT パッケージ リポジトリの有効化
ノードを登録するクラスターを指定した後、プロンプトが表示されたら、スクリプトで登録データを JSON ファイルに書き込みます。次に、スクリプトは、有効または無効にできる LINBIT リポジトリのリストを表示します。 LINSTOR およびその他の関連パッケージは、drbd-9 リポジトリにあります。別の DRBD バージョンブランチを使用する必要がない限り、少なくともこのリポジトリを有効にする必要があります。
ノード管理スクリプト内の最終タスク
リポジトリの選択が完了したら、スクリプトのプロンプトに従って構成をファイルに書き込むことができます。次に、LINBIT の公開署名鍵をノードのキーリングにインストールすることに関する質問には必ず yes と答えてください。
スクリプトが終了する前に、異なるユースケースに応じてインストールできるさまざまなパッケージを提案するメッセージが表示されます。
DEBベースのシステムでは、事前にコンパイルされたDRBDカーネルモジュールパッケージである drbd-module-$(uname -r) 、またはカーネルモジュールのソースバージョンである drbd-dkms をインストールすることができます。どちらか一方のパッケージをインストールしてくださいが、両方をインストールしないでください。
|
2.2.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
2.2.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/ から利用可能です。
2.3. LINSTOR のアップグレード
LINSTORはローリングアップグレードをサポートしていません。クラスター内で稼働するLINSTORのコントローラーとサテライトサービスは、同一のバージョンである必要があります。そうでない場合、コントローラーは VERSION_MISMATCH としてそのサテライトを切断します。これは修正が必要な状況ですが、データにリスクが及ぶことはありません。サテライトノードはコントローラーノードに接続されていない限り、いかなるアクションも実行しません。また、LINSTORはデータプレーンとコントロールプレーンが分離されているため、この状態がDRBDのデータレプリケーションを妨げることはありません。
2.3.1. アップグレード前のコントローラーデータベースのバックアップ
LINSTORをアップグレードする前に、LINSTORコントローラーのデータベースをバックアップしてください。デフォルトの組み込みH2データベースを使用している場合、linstor-controller`パッケージをアップグレードすると、データベースの自動バックアップファイルがデフォルトの/var/lib/linstor`ディレクトリに作成されます。`linstor-controller`のデータベース移行に失敗した際、このファイルは有効な復元ポイントになります。その場合はLINBITにエラーを報告し、古いデータベースファイルを復元して、以前のコントローラーバージョンにロールバックすることをお勧めします。
外部データベースまたはetcdを使用している場合は、LINSTORをアップグレードする前に現在のデータベースの手動バックアップを作成してください。必要に応じて、このバックアップをリストアポイントとして使用できます。
2.3.2. LINSTOR のアップグレード
RPMベースのLinuxディストリビューションでは、LINSTORパッケージのアップグレード時にLINSTORサービスが自動的に再起動されることはありません。そのため、アップグレードに伴うLINSTORサービス（LINSTORコントロールプレーン）のダウンタイムは、他のシステムほど発生しません。
すべてのノードで、該当するLINSTORパッケージを更新してください。LINSTORクラスター内での各ノードの役割に応じたパッケージのみが更新されるよう、以下のコマンドを適宜変更してください。
dnf update -y linstor-client linstor-controller linstor-satellite
全ノードでLINSTORパッケージをアップデートした後、すべてのサテライトノードでLINSTORサテライトサービスを可能な限り同時に再起動してください。ただし、現在稼働中のコントローラーノードが「コンバインド（統合）」ロールである場合は、そのノードを除いてください。
systemctl restart linstor-satellite
次に、サービスがアクティブに稼働しているノードでLINSTORコントローラーサービスを再起動します。そのノードのロールが「combined（混合）」である場合は、LINSTORサテライトサービスも更新してください。以下に例を示します。
systemctl restart linstor-satellite linstor-controller
| クラスター内でLINSTORコントローラーサービスを高可用化している場合は、候補となるすべてのLINSTORコントローラーノードで`linstor-controller`パッケージを更新する必要があります。ただし、LINSTORコントローラーサービスを再起動する必要があるのは、現在サービスが稼働しているノードのみです。 |
2.3.3. DEBベースのLinuxでのLINSTORのアップグレード
DEBベースのLinuxシステムでは、アップデート版のインストール後にLINSTORサービスが自動的に再起動されるため、RPMベースのシステムよりも、LINSTORコントロールプレーンのダウンタイムを長く見積もる必要があります。
まず、アクティブなLINSTORコントローラーノード上でLINSTORコントローラーソフトウェアをアップグレードしてください。
apt install -y --only-upgrade linstor-controller
| クラスター内でLINSTORコントローラーサービスを高可用化している場合は、LINSTORコントローラーの候補となるすべてのノードで`linstor-controller`パッケージを更新する必要があります。 |
ソフトウェアをアップグレードすると、コントローラーサービスが自動的に再起動します。この時点で`linstor node list`コマンドを実行すると、サテライトノードの状態が`OFFLINE(VERSION MISMATCH)`と表示されます。
次に、LINSTORのクライアントおよびサテライトのパッケージがインストールされているノードで、それらのパッケージを更新してください。LINSTORクラスターにおける各ノードの役割に合わせて、以下のコマンドを修正し、該当するパッケージのみを更新するようにしてください。
apt install -y --only-upgrade linstor-client linstor-satellite
サテライト（および兼用）ノードの LINSTOR satellite ソフトウェアパッケージをアップグレードすると、それらのノード上の LINSTOR satellite サービスは自動的に再起動されます。
2.3.4. LINSTORノードタイプの指定
クラスター内の各ノードに適用されるすべてのLINSTORパッケージをアップグレードした後、次の点を確認してください：
-
LINSTORクライアントを実行しているすべてのノードにおいて、
linstor --versionコマンドを実行すると、期待されるLINSTORクライアントのソフトウェアバージョン番号が表示されます。 -
linstor controller versionコマンドの出力には、期待される LINSTOR コントローラーのソフトウェアバージョンが表示されます。LINSTOR コントローラーサービスを高可用性化（HA構成）している場合は、パッケージマネージャーの照会コマンド（dnf info linstor-controllerまたはapt show linstor-controller）を使用して、コントローラー候補となる各ノードにインストールされているソフトウェアバージョンを確認する必要があります。 -
linstor node listコマンドの出力には、すべての LINSTOR サテライトノードがOnline状態であることが表示されます。インストールされている LINSTOR サテライトのソフトウェアバージョンがコントローラーのバージョンと一致しないノードがある場合、LINSTOR コントローラーサービスはversion mismatchというエラーメッセージをログ（journalctl -xeu linstor-controller）に出力します。その際、linstor node listコマンドの出力では、該当するノードはOFFLINE(VERSION MISMATCH)状態として表示されます。
2.4. コンテナ
LINSTORはコンテナとしても利用可能です。ベースイメージはLINBITのコンテナレジストリ drbd.io にあります。
| The LINBIT container image repository (https://drbd.io) 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 can use LINSTOR SDS’ upstream project named Piraeus, without being a LINBIT customer. |
画像にアクセスするには、まず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
You can find an up-to-date list of available images with versions at https://drbd.io.
カーネルモジュールをロードするには、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
| 両方の場合（ハッシュ＋配布、およびリポジトリのバインドマウント）で、ハッシュまたはリポジトリの構成は、特別な属性が設定されたノードからである必要があります。この属性を設定するためには、LINBITのカスタマーサポートに連絡してください。 |
現時点(つまり、DRBD 9 バージョン “9.0.17” より前)では、ホストシステムにカーネルモジュールをロードするのではなく、コンテナ化されたDRBDカーネルモジュールを使用する必要があります。コンテナを使用する場合は、ホストシステムに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
2.5. クラスタの初期化
LINSTORクラスタを初期化する前に、 すべて のクラスタノードで以下の前提条件を満たす必要があります。
-
DRBD9カーネルモジュールがインストールされ、ロードされている。
-
drbd-utilsパッケージがインストールされています。 -
LVMツールがインストールされている。 -
linstor-controllerまたはlinstor-satelliteパッケージとそれに必要な依存関係が適切なノードにインストールされています。 -
linstor-clientはlinstor-controllerノードにインストールされている。
コントローラがインストールされているホストで linstor-controller サービスを起動して有効にします。
# systemctl enable --now linstor-controller
2.6. LINSTORクライアントの使用
LINSTORコマンドラインクライアントを実行する際には、linstor-controller サービスが実行されているクラスターノードを指定する必要があります。これを指定しない場合、クライアントはIPアドレス 127.0.0.1 、ポート 3370 で待機しているローカルで実行されている linstor-controller サービスにアクセスしようとします。そのため、 linstor-controller と同じホスト上で linstor-client を使用してください。
linstor-satellite.サービスにはTCPポート3366と3367が必要です。linstor-controller.サービスにはTCPポート3370が必要です。ファイアウォールでこれらのポートが許可されていることを確認してください。
|
# linstor node list
このコマンドの出力は、空のリストが表示されるべきであり、エラーメッセージではありません。
linstor.コマンドを他のマシンでも使用することができますが、その際にはクライアントに LINSTOR コントローラの場所を教える必要があります。これは、コマンドラインオプションとして指定するか、環境変数を使用することで指定できます。
# linstor --controllers=alice node list # LS_CONTROLLERS=alice linstor node list
もし、 LINSTORコントローラのREST APIへのHTTPSアクセス を設定しており、LIINSTORクライアントがコントローラにHTTPS経由でアクセスする場合は、以下の構文を使用する必要があります：
# linstor --controllers linstor+ssl://<controller-node-name-or-ip-address> # LS_CONTROLLERS=linstor+ssl://<controller-node-name-or-ip-address> linstor node list
2.6.1. LINSTORの構成ファイルでコントローラを指定する
あるいは、/etc/linstor/linstor-client.conf ファイルを作成し、global セクションに controllers= 行を追加することもできます。
[global] controllers=alice
複数の LINSTOR コントローラーが構成されている場合は、それらをカンマ区切りのリストで指定するだけです。 LINSTOR クライアントは、リストされた順番でそれらを試します。
2.6.2. LINSTOR クライアントの省略記法を使用する
LINSTORのクライアントコマンドは、コマンドやサブコマンド、パラメータの最初の文字だけを入力することで、より速く便利に使用することができます。例えば、 linstor node list を入力する代わりに、LINSTORの短縮コマンド linstor n l を入力することができます。
linstor commands コマンドを入力すると、それぞれのコマンドの略記法と共に可能な LINSTOR クライアントコマンドのリストが表示されます。これらの LINSTOR クライアントコマンドのいずれかに --help フラグを使用すると、コマンドのサブコマンドの略記法を取得できます。
2.7. ノードをクラスタに追加する
LINSTORクラスターを初期化した後、次のステップはクラスターにノードを追加することです。
# linstor node create bravo 10.43.70.3
IPアドレスを省略した場合、前述の例で bravo と指定されたノード名を LINSTOR クライアントがホスト名として解決しようと試みます。ホスト名が、LINSTOR コントローラーサービスが実行されているシステムからのネットワーク上のホストに解決されない場合、ノードの作成を試みた際に LINSTOR はエラーメッセージを表示します。
Unable to resolve ip address for 'bravo': [Errno -3] Temporary failure in name resolution
2.8. クラスター内のノードをリストアップします。
以下のコマンドを入力して、追加したノードを含むLINSTORクラスターのノードをリストアップできます：
# linstor node list
コマンドの出力には、LINSTORクラスター内のノードが一覧表示され、ノードに割り当てられたノードタイプ、ノードのIPアドレスとLINSTOR通信に使用されるポート、およびノードの状態などの情報が表示されます。
╭────────────────────────────────────────────────────────────╮ ┊ Node ┊ NodeType ┊ Addresses ┊ State ┊ ╞════════════════════════════════════════════════════════════╡ ┊ bravo ┊ SATELLITE ┊ 10.43.70.3:3366 (PLAIN) ┊ Offline ┊ ╰────────────────────────────────────────────────────────────╯
2.8.1. LINSTORノードの命名
LINSTORノードを作成する際にIPアドレスを指定すると、ノードに任意の名前を付けることができます。LINSTORクライアントは、ノードを作成する際にこのことについてINFOメッセージを表示します。
[...] 'arbitrary-name' and hostname 'node-1' doesn't match.
LINSTORは自動的に作成されたノードの uname --nodename を検出し、後でDRBDリソースの構成に使用します。任意のノード名の代わりに、ほとんどの場合は自分自身や他の人を混乱させないよう、LINSTORノードを作成する際にはノードのホスト名を使用するのが適切です。
2.8.2. LINSTORサテライトノードの起動と有効化
linstor node list コマンドを使用すると、LINSTOR は新しいノードがオフラインとしてマークされていることを表示します。その後、新しいノードで LINSTOR サテライトサービスを開始して有効にし、サービスが再起動時にも起動するようにしてください。
# systemctl enable --now linstor-satellite
トラブルシューティングやLINSTORのアップグレード時を除き、通常はサテライトサービスを開始または停止する必要はありません。しかし、UUIDの不一致など、一部の致命的なエラーが発生した場合には、これらの操作が必要になることがあります。linstor-server バージョン 1.31.3 以降では、LINSTORが致命的なエラーに遭遇した場合、終了コード 70 でシャットダウンすることで自動的に復旧を試みます。これにより、linstor-satellite.service ユニットファイルの設定に基づいて、systemdがLINSTORサテライトサービスを自動的に再起動します。
|
サテライトサービスを起動して有効化すると、約10秒後に linstor node list のステータスが「online」と表示されるようになります。もちろん、コントローラーがサテライトノードの存在を認識する前に、サテライトプロセスが開始されていることもあります。
コントローラをホストしているノードが LINSTOR クラスタにストレージを提供する必要がある場合、そのノードをノードとして追加し、linstor-satellite サービスも開始する必要があります。
|
2.8.3. LINSTORノードタイプの指定
LINSTORノードを作成する際に、ノードタイプを指定することもできます。ノードタイプは、あなたのLINSTORクラスタ内でノードが担う役割を示すラベルです。ノードタイプは、controller, auxiliary, combined, satellite のいずれかになります。例えば、LINSTORノードを作成して、それをコントローラーノードとサテライトノードとしてラベルを付ける場合は、次のコマンドを入力してください：
# linstor node create bravo 10.43.70.3 --node-type combined
--node-type 引数はオプションです。ノードを作成する際にノードタイプを指定しない場合、LINSTORは自動的にデフォルトのサテライトタイプを使用します。
ノードを作成した後で、割り当てられた LINSTOR ノードのタイプを変更したい場合は、linstor node modify --node-type コマンドを入力します。
2.8.4. サポートされているストレージプロバイダーとストレージレイヤーの一覧
サテライトノードでサポートされているストレージプロバイダやストレージレイヤをリストアップするには、node info コマンドを使用することができます。クラスタ内でストレージオブジェクトを作成する前やトラブルシューティングの状況にある場合は、LINSTORを使用する前にそれを行ってください。
# linstor node info
コマンドの出力には2つのテーブルが表示されます。最初のテーブルでは利用可能な LINSTOR storage provider バックエンドが表示されます。2番目のテーブルでは利用可能な LINSTOR storage layers が表示されます。両方のテーブルで、特定のノードがストレージプロバイダーまたはストレージレイヤーをサポートしているかどうかが示されます。プラス記号「+」は”サポートされています”を、マイナス記号「-」は”サポートされていません”を表します。
クラスターの例の出力は、以下のようなものに類似しているかもしれません。
linstor node info コマンドの例の出力2.9. ストレージプール
ストレージプール は、LINSTORのコンテキストでストレージを識別します。複数のノードからストレージプールをグループ化するには、単純に各ノードで同じ名前を使用します。例えば、すべてのSSDには1つの名前を、すべてのHDDには別の名前を指定するのが有効なアプローチです。
2.9.1. ストレージプールの作成
各ストレージを提供するホスト上で、LVMのボリュームグループ（VG）またはZFSのzPoolを作成する必要があります。同じLINSTORストレージプール名で識別されるVGやzPoolは、各ホストで異なるVGやzPool名を持つかもしれませんが、整合性を保つために、すべてのノードで同じVGまたはzPool名を使用することをお勧めします。
|
LINSTOR を LVM および DRBD と一緒に使用する場合、LVM グローバル設定ファイル (RHEL では global_filter = [ "r|^/dev/drbd|", "r|^/dev/mapper/[lL]instor|" ] This setting tells LVM to reject DRBD and other devices created or set up by LINSTOR from operations such as scanning or opening attempts. In some cases, not setting this filter might lead to increased CPU load or stuck LVM operations. |
# vgcreate vg_ssd /dev/nvme0n1 /dev/nvme1n1 [...]
各ノードにボリュームグループを作成した後、次のコマンドを入力することで、各ノードでボリュームグループにバックアップされたストレージプールを作成することができます。
# linstor storage-pool create lvm alpha pool_ssd vg_ssd # linstor storage-pool create lvm bravo pool_ssd vg_ssd
ストレージプールの一覧を表示するには、次のコマンドを入力してください:
# linstor storage-pool list
または、LINSTORの略記法を使用することもできます。
# linstor sp l
2.9.2. ストレージプールを使用して、障害領域を単一のバックエンドデバイスに制限する
単一種類のストレージのみが存在し、ストレージデバイスのホットスワップが可能なクラスターでは、1つの物理バッキングデバイスごとに1つのストレージプールを作成するモデルを選択することがあります。このモデルの利点は、障害ドメインを1つのストレージデバイスに限定することです。
2.9.3. 複数のノードでストレージプールを共有する
LVM2ストレージプロバイダーは、複数のサーバーノードをストレージアレイやドライブに直接接続する構成を提供しています。2つ以上のノードからアクセス可能な同一のLVM2ボリュームグループを使用するようにLINSTORプールを構成する場合、LINSTORの`storage-pool create`コマンドで`–shared-space`オプションを使用できます。
| LINSTORストレージプールのバックエンドとして使用されているボリュームグループ内で論理ボリュームを変更または作成すべきではないのと同様に、共有ボリュームグループに対してこれらの操作を行わないことはさらに重要です。LINSTORによってLVMコマンドの調整が行われている共有ボリュームグループに対して、例えばインタラクティブシェルからLVMコマンドを実行すると、不整合な情報が出力されたり、LVMメタデータが破壊されたりする恐れがあります。起動時などにおけるLVM論理ボリュームの自動アクティブ化も、この警告の対象となります。これらの操作は絶対に行わないでください。このような場合には、抽象化されたLINSTORオブジェクトを介して、LINSTORでLVM論理ボリュームを管理するようにしてください。 |
以下の例では、ノード alpha および bravo からアクセス可能なストレージプールの共有スペース識別子として、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
この例では --external-locking オプションも使用しています。このオプションを指定することで、共有ストレージプールに対して LINSTOR 内部の排他制御機構を使用せず、代わりに LVM の機構を使用するように指示します。
LVM2では、外部ロックサービス（lvmlockd）が、vgcreate`コマンドの–shared`オプションを使用して作成されたボリュームグループを管理します。LINSTORの`–external-locking`オプションを使用するには、LINSTORストレージプールの基盤となるLVMボリュームグループを`vgcreate`コマンドで作成する際に、LVMの`–shared`オプションを指定しておく必要があります。
|
vgcreate`の–shared`オプションと、linstor storage-pool create`の–external-locking`オプションは、いずれも省略可能です。これらを省略した場合、LINSTORは独自のメカニズムを使用して、同じ`–shared-space`グループ内の1つのノードのみがLVMを使用するように制御します。ただし、LINSTORの内部メカニズムによるLVM使用のロックは、個別のボリュームへのアクセスを制限するものではありません。例えば、LINSTORおよびLVMのいずれのロックメカニズムも、DRBDのI/Oを制限することはありません。
2.9.4. 物理ストレージコマンドを使用してストレージプールを作成する
linstor-server 1.5.2および最新の linstor-client から、LINSTORはサテライト上でLVM/ZFSプールを作成することができます。 LINSTORクライアントには、可能なディスクをリストアップしストレージプールを作成するための以下のコマンドがありますが、このようなLVM/ZFSプールはLINSTORによって管理されず、削除コマンドもないため、そのような処理はノード上で手動で行う必要があります。
# linstor physical-storage list
これはサイズと回転方式 (SSD/磁気ディスク) でグループ化された使用可能なディスクのリストを表示します。
次のフィルターを通過するディスクのみが表示されます。
-
デバイスのサイズは1GiBより大きい必要があります。
-
そのデバイスはルートデバイス（子を持たない）、例えば、
/dev/vda,/dev/sdaです。 -
そのデバイスにはファイルシステムや他の
blkidマーカーがありません（wipefs -aが必要かもしれません）。 -
そのデバイスはDRBDデバイスではありません。
create-device-pool コマンドを使用すると、ディスクにLVMプールを作成し、それを直接ストレージプールとしてLINSTORに追加することができます。
# linstor physical-storage create-device-pool --pool-name lv_my_pool \ LVMTHIN node_alpha /dev/vdc --storage-pool newpool
もし --storage-pool オプションが指定された場合、LINSTOR は指定された名前でストレージプールを作成します。
さらなるオプションや正確なコマンドの使用方法については、LINSTOR クライアントの --help テキストを参照してください。
2.9.5. ストレージプールの混合
いくつかのセットアップと構成を行うことで、異なる ストレージプロバイダ タイプのストレージプールを使用して LINSTOR リソースをバックアップすることができます。これはストレージプールのミキシングと呼ばれます。たとえば、1つのノードで LVM の厚み予約ボリュームを使用するストレージプールを持ち、別のノードで ZFS zpool を使用するスリム予約済みのストレージプールを持つことができます。
ほとんどの LINSTOR デプロイメントでは、リソースをバックアップするために均質なストレージプールが使用されるため、ストレージプールのミキシングはその機能が存在することを知っておくためにだけここで言及されています。 例えば、ストレージリソースを移行する際に便利な機能かもしれません。 異なるストレージプロバイダーのストレージプールを混在させる には、これに関する詳細や前提条件などが記載されていますので、そちらをご覧ください。
2.10. リソースグループを使用した LINSTOR プロビジョニングされたボリュームのデプロイ
LINSTOR によってプロビジョニングされたボリュームを展開する際に、リソースグループを使用してリソースのプロビジョニング方法を定義することは、デファクトスタンダードと考えられるべきです。その後の章では、特別なシナリオでのみ使用すべきである、リソース定義とボリューム定義から各々のリソースを作成する方法について説明しています。
| LINSTORクラスターでリソースグループを作成および使用しない場合でも、リソース定義およびボリューム定義から作成されたすべてのリソースは、’DfltRscGrp’リソースグループに存在します。 |
リソースグループを使用してリソースをデプロイする簡単なパターンは次のようになります。
# 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’ という名前のストレージプールに参加するノードから、２つに複製された 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
上記のコマンドは、各々が crc32c の verify-alg が事前に設定された20個の 10GiB リソースが作成される結果となります。
Promoterは、リソースグループから生成された個々のリソースやボリュームの設定を調整することができます。これは、対応するリソース定義やボリューム定義のLINSTORオブジェクトにオプションを設定することで行います。たとえば、前述の例から res11 が、多くの小さなランダムライトを受け取る非常にアクティブなデータベースで使用されている場合、その特定のリソースの al-extents を増やしたい場合があります。
# linstor resource-definition drbd-options --al-extents 6007 res11
リソース定義内で設定を構成すると、その設定が生成元のリソースグループで既に構成されている場合、リソース定義で設定された値が親リソースグループで設定された値を上書きします。たとえば、同じ res11 が、その検証により遅いがより安全な sha256 ハッシュアルゴリズムを使用する必要がある場合、res11 のリソース定義で verify-alg を設定すると、リソースグループで設定された値が上書きされます。
# linstor resource-definition drbd-options --verify-alg sha256 res11
| リソースやボリュームに設定が継承される階層における基本ルールは、リソースやボリュームに「近い」値が優先されます。ボリュームの定義設定はボリュームグループの設定より優先され、リソースの定義設定はリソースグループの設定より優先されます。 |
2.12. リソース、ボリュームの作成と配備
LINSTORの create コマンドを使用すると、リソースの定義、ボリュームの定義、およびリソースなど、さまざまなLINSTORオブジェクトを作成できます。以下にいくつかのこれらのコマンドが示されています。
次の例のシナリオでは、backups という名前のリソースを作成し、そのサイズを500GiBに設定し、3つのクラスタノード間で複製することを目標とします。
まず、新しいリソース定義を作成してください。
# linstor resource-definition create backups
次に、そのリソース定義内に新しいボリューム定義を作成してください。
# linstor volume-definition create backups 500G
もしボリューム定義をリサイズ（拡大または縮小）したい場合は、set-size コマンドで新しいサイズを指定することで行うことができます。
# linstor volume-definition set-size backups 0 100G
| バージョン1.8.0以降、LINSTORはボリューム定義サイズの縮小をサポートしています。リソースのストレージレイヤーが対応していれば、デプロイ済みのリソースであっても縮小が可能です。データが存在するリソースのボリューム定義サイズを縮小する際は、細心の注意を払ってください。バックアップの作成や、事前にボリューム上のファイルシステムを縮小するなどの予防措置を講じない場合、データ消失が発生する恐れがあります。 |
パラメータ 0 はリソース backups におけるボリュームの番号です。このパラメータを指定する必要があります。それは、リソースには複数のボリュームが存在し、それらはいわゆる「ボリューム番号」で識別されるからです。この番号は、ボリューム定義の一覧 (linstor vd l) を取得して見つけることができます。一覧テーブルには、リソースのボリュームに対する番号が表示されます。
現時点では、LINSTORのデータベースには定義オブジェクトのみが作成されています。しかし、まだ1つもサテライトノード上に論理ボリューム（LV）が作成されていません。これからは、LINSTORにリソースの展開タスクを委任するか、自分で行うかを選択できます。
2.12.1. リソースを手動で配置する
resource create コマンドを使用すると、リソース定義を名前付きノードに明示的に割り当てることができます。
# linstor resource create alpha backups --storage-pool pool_hdd # linstor resource create bravo backups --storage-pool pool_hdd # linstor resource create charlie backups --storage-pool pool_hdd
2.12.2. DRBD リソースの自動化
リソースグループからリソースを作成（生成）する際、LINSTOR が自動的にノードとストレージプールを選択してリソースを展開することが可能です。このセクションで言及されている引数を使用して、リソースグループを作成または変更する際に制約を指定することができます。これらの制約は、リソースグループから展開されるリソースが自動的に配置される方法に影響を与えます。
リソースグループ配置数の自動管理
LINSTORバージョン1.26.0以降、リソースグループに設定された配置数を維持しようとする、定期的なLINSTORタスクが存在します。そのリソースグループに属するすべての展開済みLINSTORリソースに対してです。これには、デフォルトのLINSTORリソースグループとその配置数も含まれます。
もし、この挙動を無効にしたい場合は、LINSTOR コントローラー、リソースが属する LINSTOR リソースグループ、またはリソース定義それ自体にある BalanceResourcesEnabled プロパティを false に設定してください。LINSTOR のオブジェクト階層のため、リソースグループにプロパティを設定した場合は、それが LINSTOR コントローラーのプロパティ値を上書きします。同様に、リソース定義にプロパティを設定した場合は、そのリソース定義が属するリソースグループのプロパティ値を上書きします。
この機能に関連する他の追加プロパティも、LINSTORコントローラで設定できます：
BalanceResourcesInterval-
デフォルトでは、バランスリソース配置タスクがトリガーされるLINSTORコントローラーレベルの間隔は、3600秒（1時間）です。
BalanceResourcesGracePeriod-
新しいリソース（作成または生成後）がバランス調整から無視される秒数。デフォルトでは、寛容期間は3600秒（1時間）です。
Placement count
リソースグループを作成または変更する際に --place-count <replica_count> 引数を使用することで、クラスタ内の何ノードに LINSTOR がリソースグループから作成されたディスクリソースを配置するかを指定できます。
|
不可能な配置制約を持つリソースグループを作成する
リソースグループを作成または変更し、LINSTORが満たすことが不可能な配置数やその他の制約を指定することができます。たとえば、クラスターに3つのノードしかないのに配置数を ERROR:
Description:
Not enough available nodes
[...]
|
ストレージプール配置
次の例では、--place-count オプションの後の値は、いくつのレプリカを持ちたいかを LINSTOR に伝えます。--storage-pool オプションは明らかであるべきです。
# linstor resource-group create backups --place-count 3 --storage-pool pool_hdd
明らかでないことは、--storage-pool オプションを省略することができるということです。これを行うと、リソースグループからリソースを作成（生成）する際に、LINSTORは独自にストレージプールを選択することができます。選択は以下のルールに従います：
-
現在のユーザがアクセスできないすべてのノードとストレージプールは無視する。
-
すべてのディスクレスストレージプールは無視する
-
十分な空き領域がないストレージプールは無視する
残りのストレージプールは異なる戦略で評価されます。
MaxFreeSpace-
この戦略は評価を1:1でストレージプールの残りの空き容量に割り当てます。ただし、この戦略は実際に割り当てられた空間のみを考慮しています（スリムプロビジョニングされたストレージプールの場合、新しいリソースを作成せずに時間と共に増える可能性があります）。
MinReservedSpace-
「MaxFreeSpace」とは異なり、この戦略では予約空間が考慮されます。つまり、薄いボリュームが限界に達する前に成長できる空間です。予約空間の合計がストレージプールの容量を超える場合があり、これはオーバープロビジョニングと呼ばれます。
MinRscCount-
与えられたストレージプールに既に展開されているリソースの数を単純に数える
MaxThroughput-
この戦略では、ストレージプールの
Autoplacer/MaxThroughputプロパティがスコアの基準となります。ただし、このプロパティが存在しない場合は、スコアは 0 になります。与えられたストレージプールに展開されたすべてのボリュームは、定義されたsys/fs/blkio_throttle_readおよびsys/fs/blkio_throttle_writeプロパティの値を、ストレージプールの最大スループットから引きます。計算されたスコアは負の値になる可能性があります。
各方針のスコアは正規化され、重み付けされ、合計されます。この場合、最小化方針のスコアが最初に変換され、結果として得られるスコアの全体的な最大化が可能になります。
指定したストレージプールを明示しないリソースの作成時に、どのストレージプールを LINSTOR がリソース配置用に選択するかを影響させるために、戦略の重みを設定することができます。これは、LINSTOR コントローラーオブジェクトに以下のプロパティを設定することで行います。重みは任意の10進数値にすることができます。
linstor controller set-property Autoplacer/Weights/MaxFreeSpace <weight> linstor controller set-property Autoplacer/Weights/MinReservedSpace <weight> linstor controller set-property Autoplacer/Weights/MinRscCount <weight> linstor controller set-property Autoplacer/Weights/MaxThroughput <weight>
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に対して、提供された引数で指定した正規表現に一致する名前のリソースが既にデプロイされているノードにはリソースを配置しないように指定することができます。このようにして、配置を避けるために複数のリソースを指定することができます。
補助ノードプロパティを用いたリソース自動配置の制約付け
リソースの自動配置は、指定した補助ノードプロパティを持つノードにリソースを配置する（または配置しない）ように制約することができます。
この機能は、いくつかの異なるシナリオで役立ちます。その1つが、LINSTORで管理されたストレージを使用するKubernetes環境において、リソースの配置を制限したい場合です。例えば、Kubernetesのラベルに対応する補助的なノードプロパティを設定するといった使い方が考えられます。このユースケースの詳細については、『LINSTORユーザーガイド』の「KubernetesにおけるLINSTORボリューム」の章にある「replicasOnSame」セクションを参照してください。
--x-replicas-on-different 引数を使用すると、自動リソース配置に制約を加えることができます。これは、ストレッチクラスター構成などのように、LINSTORを使用して複数のデータセンターにわたるストレージリソースを管理する場合に便利です。この引数は --replicas-on-same や --replicas-on-different 引数とは指定形式が異なるため、詳細については後の専用セクション ディザスタリカバリに向けた、異なるノードへのリソース自動配置の実現 で解説します。
引数の --replicas-on-same と --replicas-on-different は、 Aux/ 名前空間内のプロパティの名前を指定します。
--x-replicas-on-different`コマンドオプションは、補助プロパティが設定されていないLINSTORオブジェクトも「異なる」ものとして扱います。例えば、5つのサテライトノードで構成されるクラスターにおいて、ノード1と2の補助プロパティ`site`の値が`dc1、ノード3と4の`site`の値が`dc2`であり、ノード5に補助プロパティが設定されていない場合、3つの「異なる」ノードグループが存在することになります。
|
次の例は、3つの LINSTOR サテライトノードに補助ノードプロパティ testProperty を設定しています。次に、配置カウントが2であり、testProperty の値が 1 であるノードにリソースを配置する制約を持つリソースグループ testRscGrp を作成します。ボリュームグループを作成した後、リソースグループからリソースを生成することができます。ここでは、次のコマンドの出力は簡潔に示されていません。
# 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
コマンドの出力には、リソースの一覧と、LINSTORがリソースを配置したノードが表示されます。
╭─────────────────────────────────────────────────────────────────────────────────────╮ ┊ 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 ┊ ╰─────────────────────────────────────────────────────────────────────────────────────╯
--replicas-on-same 制約により、LINSTORは作成されたリソースをサテライトノード node-1 に配置しませんでした。これは、補助ノードプロパティ testProperty の値が 1 ではなく 0 であったためです。
list-properties コマンドを使用して、node-1 のノードプロパティを確認できます。
# linstor node list-properties node-1 ╭────────────────────────────╮ ┊ Key ┊ Value ┊ ╞════════════════════════════╡ ┊ Aux/testProperty ┊ 0 ┊ ┊ CurStltConnName ┊ default ┊ ┊ NodeUname ┊ node-1 ┊ ╰────────────────────────────╯
オートプレースメントのプロパティを解除する
リソースグループに設定した自動配置プロパティを解除するには、次のコマンド構文を使用できます。
# linstor resource-group modify <resource-group-name> --<autoplacement-property>
あるいは、次のように --<autoplacement-property> 引数に続けて空の文字列を指定することもできます。
# linstor resource-group modify <resource-group-name> --<autoplacement-property> ''
例えば、前の例で設定した testRscGrp の --replicas-on-same 自動配置プロパティを解除するには、次のコマンドを入力します：
# linstor resource-group modify testRscGrp --replicas-on-same
ディザスタリカバリに向けた、異なるノードへのリソース自動配置の実現
各種LINSTORオブジェクトの作成または変更時に`–x-replicas-on-different`引数を使用することで、LINSTORがリソースを異なるLINSTORノードグループに自動的に配置するように設定できます。ここでは、補助プロパティの異なる値がそれぞれ異なるグループを表します。この引数は以下の形式をとります：
--x-replicas-on-different <auxiliary-property-name> <positive-integer>
この正の整数値は、指定された補助プロパティに同じ値を持つノードに対して、LINSTORが配置できるリソースレプリカの最大数です。
この機能の最も一般的なユースケースは、高可用性のために常に少なくとも2つのローカルリソースレプリカを確保し、災害復旧のために1つのオフサイトリソースレプリカを確保することです。例えば、物理的な場所によって各ノードにラベルを付けるために、ストレッチクラスター構成のLINSTORクラスターに対して、次のように補助プロパティ site を設定したと仮定します：
╭──────────────────────────────────────────────────────────────────╮ ┊ Node ┊ NodeType ┊ Addresses ┊ AuxProps ┊ State ┊ ╞══════════════════════════════════════════════════════════════════╡ ┊ linstor-ctrl-0 ┊ CONTROLLER ┊ [...] ┊ ┊ Online ┊ ┊ linstor-sat-0 ┊ SATELLITE ┊ [...] ┊ Aux/site=dc1 ┊ Online ┊ ┊ linstor-sat-1 ┊ SATELLITE ┊ [...] ┊ Aux/site=dc1 ┊ Online ┊ ┊ linstor-sat-2 ┊ SATELLITE ┊ [...] ┊ Aux/site=dc2 ┊ Online ┊ ┊ linstor-sat-3 ┊ SATELLITE ┊ [...] ┊ Aux/site=dc2 ┊ Online ┊ ┊ linstor-sat-4 ┊ SATELLITE ┊ [...] ┊ Aux/site=dc2 ┊ Online ┊ ╰──────────────────────────────────────────────────────────────────╯
さらに、5つすべてのサテライトノード上で、同じ LINSTOR ストレージプールに関連付けられたリソースグループ myrg を作成済みであると想定します。次のコマンドを入力して新しいリソース myres を作成し、LINSTOR が2つのレプリカを一方のサイトに、3つ目のレプリカを別の site に確実に配置するようにできます。
linstor resource-group spawn \ --x-replicas-on-different site 2 \ --place-count 3 \ myrg myres 200G
LINSTORがリソースを作成した後、linstor resource list --resource myres コマンドを実行すると、以下のような出力が表示されることがあります。
╭─────────────────────────────────────────────────────────────────────────────────────╮ ┊ ResourceName ┊ Node ┊ Layers ┊ Usage ┊ Conns ┊ State ┊ CreatedOn ┊ ╞═════════════════════════════════════════════════════════════════════════════════════╡ ┊ myres ┊ linstor-sat-0 ┊ DRBD,STORAGE ┊ Unused ┊ Ok ┊ UpToDate ┊ [...] ┊ ┊ myres ┊ linstor-sat-1 ┊ DRBD,STORAGE ┊ Unused ┊ Ok ┊ UpToDate ┊ [...] ┊ ┊ myres ┊ linstor-sat-2 ┊ DRBD,STORAGE ┊ Unused ┊ Ok ┊ UpToDate ┊ [...] ┊ ╰─────────────────────────────────────────────────────────────────────────────────────╯
myres リソースを作成する際、LINSTOR が dc1 または dc2 ノードのいずれかに配置できるリソースレプリカの最大数に 2 を指定し、さらにプレイスカウントに 3 を指定することで、LINSTOR が 3 つのリソースレプリカを配置することを確実にします。これにより、ローカルの高可用性のために 1 つの site に 2 つのリソースがまとめて配置され、災害復旧の目的で 3 つ目のレプリカがオフサイトに配置されます。
--x-replicas-on-different と --place-count の数値の組み合わせは、他にも可能です。しかし、適切な選択を行う必要があります。例えば、前述の LINSTOR クラスターの例で myres リソースを作成する際に、--x-replicas-on-different site 1 と --place-count 3 を指定した場合、LINSTOR はリソースの作成を拒否し、”Not enough available nodes” というエラーメッセージを表示します。
--x-replicas-on-different $X 1 を指定した場合の配置結果は、--replicas-on-different $X を指定した場合とまったく同じになります。
|
ここでのノードラベリング（補助プロパティの使用による）と、補助プロパティの値が異なるノードに対してLINSTORが最大1つのリソースレプリカを配置するという制約に加え、3つのリソースレプリカを配置するように求めていることは、LINSTORに対して不可能なことを要求していることを意味します。
実装上、--x-replicas-on-different コマンドは、補助プロパティが設定されていない LINSTOR オブジェクトを「異なる」とみなすことに注意してください。これは --replicas-on-different オプションの動作についても同様です。例えば、次のような LINSTOR クラスターを考えてみましょう。
╭──────────────────────────────────────────────────────────────────╮ ┊ Node ┊ NodeType ┊ Addresses ┊ AuxProps ┊ State ┊ ╞══════════════════════════════════════════════════════════════════╡ ┊ linstor-ctrl-0 ┊ CONTROLLER ┊ [...] ┊ ┊ Online ┊ ┊ linstor-sat-0 ┊ SATELLITE ┊ [...] ┊ Aux/site=dc1 ┊ Online ┊ ┊ linstor-sat-1 ┊ SATELLITE ┊ [...] ┊ Aux/site=dc1 ┊ Online ┊ ┊ linstor-sat-2 ┊ SATELLITE ┊ [...] ┊ Aux/site=dc2 ┊ Online ┊ ┊ linstor-sat-3 ┊ SATELLITE ┊ [...] ┊ Aux/site=dc2 ┊ Online ┊ ┊ linstor-sat-4 ┊ SATELLITE ┊ [...] ┊ Aux/site=dc2 ┊ Online ┊ ┊ linstor-sat-5 ┊ SATELLITE ┊ [...] ┊ ┊ Online ┊ ┊ linstor-sat-6 ┊ SATELLITE ┊ [...] ┊ ┊ Online ┊ ╰──────────────────────────────────────────────────────────────────╯
先ほど言及した「impossible」コマンドを使用してリソース myres を作成しようとすると、今回はそのコマンドが成功します。
linstor resource-group spawn \ --x-replicas-on-different site 1 \ --place-count 3 \ myrg myres 200G
指定された制約を満たすリソース配置の成功例は、以下の通りです。
╭─────────────────────────────────────────────────────────────────────────────────────╮ ┊ ResourceName ┊ Node ┊ Layers ┊ Usage ┊ Conns ┊ State ┊ CreatedOn ┊ ╞═════════════════════════════════════════════════════════════════════════════════════╡ ┊ myres ┊ linstor-sat-0 ┊ DRBD,STORAGE ┊ Unused ┊ Ok ┊ UpToDate ┊ [...] ┊ ┊ myres ┊ linstor-sat-2 ┊ DRBD,STORAGE ┊ Unused ┊ Ok ┊ UpToDate ┊ [...] ┊ ┊ myres ┊ linstor-sat-5 ┊ DRBD,STORAGE ┊ Unused ┊ Ok ┊ UpToDate ┊ [...] ┊ ╰─────────────────────────────────────────────────────────────────────────────────────╯
linstor-sat-5 ノードに site 補助プロパティが設定されていなかったため、--x-replicas-on-different 制約の観点では、そのノードは別のグループに属するものとしてカウントされました。この例のクラスターでは、site 補助プロパティに関して、dc1、dc2、および一部のノードで補助プロパティが設定されていないグループという、3つの異なるノードグループが存在します。このため、LINSTOR は --x-replicas-on-different 制約を満たしつつ、--place-count 制約も満たして3つのリソースを配置することができました。
LINSTORレイヤーまたはストレージプールプロバイダによるリソースの自動配置の制約
[Promoter] は、--layer-list または --providers 引数を指定することができます。その後に、LINSTOR がリソースを配置する際に影響を与える、LINSTOR のレイヤーやストレージプールプロバイダーのコンマで区切られた値（CSV）リストを指定します。CSV リストに指定できる可能なレイヤーやストレージプールプロバイダーは、--auto-place オプションを使用して --help オプションと共に表示することができます。レイヤーの CSV リストは、特定のリソースグループに対して自動的なリソース配置を制約し、あなたのリストに準拠したストレージを持つノードに制限します。次のコマンドを考えてみてください：
# linstor resource-group create my_luks_rg --place-count 3 --layer-list drbd,luks
このリソースグループから後で作成（spawn）するリソースは、LUKSレイヤーを基盤とするDRBDレイヤー（および暗黙的な「ストレージ」レイヤー）によって構成されるストレージプールを持つ3つのノードにデプロイされます。CSVリストで指定するレイヤーの順序は「トップダウン」であり、リストの左側にあるレイヤーがその右側にあるレイヤーの上位となります。
--providers 引数を使用すると、リソースの自動配置を、指定されたCSVリストに一致するストレージプールのみに制限できます。この引数を使用することで、デプロイされるリソースのバッキングとなるストレージプールを明示的に制御できます。例えば、クラスター内に ZFS、LVM、および LVM_THIN のストレージプールが混在する環境において、--place-count オプションを使用する際に --providers LVM,LVM_THIN 引数を使用することで、リソースが LVM または LVM_THIN のいずれかのストレージプールによってのみバッキングされるように指定できます。
--providers 引数の CSV リストは、リスト要素の優先順位を指定するものではありません。その代わりに、LINSTOR はリソースを配置する際、以前に説明した追加の配置制約、利用可能な空き容量、LINSTOR のストレージプール選択戦略などの要素を使用します。
|
リソースを作成する際に、それらを自動的に配置する
リソースを作成する標準的な方法は、リソースグループを使用してテンプレートを作成し、そこからリソースを生成することですが、 resource create コマンドを使用して直接リソースを作成することもできます。このコマンドを使用すると、LINSTOR がストレージクラスター内でリソースを配置する方法に影響を与える引数を指定することも可能です。
resource create コマンドを使用する際に指定できる引数は、resource-group create コマンドに影響を与える引数と同じですが、配置回数引数を除きます。resource create コマンドで --auto-place <replica_count> 引数を指定するのは、resource-group create コマンドで --place-count <replica_count> 引数を指定するのと同じです。
既存のリソースデプロイメントを拡張するためのAuto-placeの使用
プロモーターの名前以外に、リソースグループとリソース 作成 コマンドの配置数引数の間にもう1つ違いがあります。 リソースの作成 コマンドでは、既存のリソース展開を拡張したい場合に --auto-place 引数と一緒に値 +1 も指定できます。
この値を使用することで、LINSTORは、リソースが作成されたリソースグループに設定されている --place-count が何であるかに関係なく、追加のレプリカを作成します。
例えば、前の例で使用されていた testResource リソースの追加レプリカを展開するために --auto-place +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 ┊ ╰─────────────────────────────────────────────────────────────────────────────────────╯
resource-group create --place-count コマンドに +1 という値は指定できません。これは、このコマンドがリソースをデプロイするものではなく、後でデプロイを行うためのテンプレートを作成するのみであるためです。
|
2.13. ストレージボリュームへのファイルシステムの作成
利便性を高めるため、ストレージリソースとボリュームをデプロイした後に LINSTOR サテライトノード上で mkfs コマンドを実行してファイルシステムを作成する代わりに、LINSTOR にファイルシステムを自動で作成させることができます。これを行うには、linstor resource-group set-property サブコマンドを使用して Filesystem/Type キーに ext4 または xfs のいずれかを設定してから、そのリソースグループからリソースを作成します。追加の Filesystem プロパティを設定することで、ファイルシステムの所有者やグループを指定したり、LINSTOR がバックグラウンドで実行する mkfs コマンドにファイルシステム固有の追加パラメータを渡したりすることも可能です。
例えば、nfs-rg という名前の LINSTOR リソースグループがある場合、次の一連のコマンドは、nfs-res という名前のリソースの LINSTOR ストレージボリューム上に XFS ファイルシステムを作成します。
linstor resource-group set-property nfs-rg FileSystem/Type xfs (1) linstor resource-group set-property nfs-rg FileSystem/User nobody (2) linstor resource-group set-property nfs-rg FileSystem/Group nobody (2) linstor resource-group spawn-resources nfs-rg nfs-res 100G
| 1 | ext4 または xfs のいずれかを指定できます。 |
| 2 | プロパティが設定されていない場合、デフォルトは root です。 |
resource-group list-property コマンドを入力して、リソースグループのプロパティを確認します。例：
linstor resource-group list-properties nfs-rg
出力には設定されたプロパティが表示されます：
╭─────────────────────────────────────╮ ┊ Key ┊ Value ┊ ╞═════════════════════════════════════╡ ┊ FileSystem/Group ┊ nobody ┊ ┊ FileSystem/Type ┊ xfs ┊ ┊ FileSystem/User ┊ nobody ┊ ╰─────────────────────────────────────╯
サテライトノードで`blkid`コマンドを使用することで、LINSTORがストレージボリューム上にファイルシステムを作成したことを確認できます。
[...] /dev/drbd1004: UUID="[...]" TYPE="xfs" [...]
サテライトノードのディレクトリにDRBDデバイスをマウントした後、`ls -l`コマンドを使用して所有権情報を表示できます。例：
drwxrwxrwx. 2 nobody nobody 6 Sep 26 18:56 data
2.13.1. リモートを作成する際にLINSTORのパスフレーズを指定します。
FileSystem/Type、FileSystem/User、および FileSystem/Group キーのほかに、FileSystem/MkfsParams を使用して、LINSTOR がストレージボリューム上にファイルシステムを作成する際に mkfs コマンドへ渡す追加のパラメータを指定できます。たとえば、LINSTOR が作成するファイルシステムにラベルを付与することが可能です。
linstor resource-group set-property nfs-rg FileSystem/MkfsParams '-L nfs-data'
その他の指定可能なパラメータについては、`mkfs.ext4`および`mkfs.xfs`のマニュアルページを参照してください。
2.14. リソース、リソース定義、およびリソース グループの削除
削除したい LINSTOR オブジェクトの後に delete コマンドを使用して、LINSTOR リソース、リソース定義、およびリソース グループを削除できます。どのオブジェクトを削除するかによって、LINSTOR クラスターおよびその他の関連する LINSTOR オブジェクトに異なる影響があります。
2.14.1. リソース定義の削除
次のコマンドを使用してリソース定義を削除できます:
# linstor resource-definition delete <resource_definition_name>
これにより、指定されたリソース定義がLINSTORクラスター全体から削除されます。リソースはすべてのノードから削除され、リソースエントリはLINSTORのデータベーステーブルから削除対象としてマークされます。LINSTORがすべてのノードからリソースを削除した後、そのリソースエントリがLINSTORのデータベーステーブルから削除されます。
| リソース定義に既存のスナップショットがある場合、それらのスナップショットを削除するまで、そのリソース定義を削除することはできません。本ガイドの スナップショットの削除 セクションを参照してください。 |
2.14.2. リソースの削除
次のコマンドを使用してリソースを削除できます:
# linstor resource delete <node_name> <resource_name>
リソース定義を削除する場合とは異なり、このコマンドは指定したノード（または複数のノード）から LINSTOR リソースを削除するだけです。リソースはノードから削除され、リソースエントリは LINSTOR のデータベーステーブルから削除対象としてマークされます。LINSTOR がノードからリソースを削除した後、そのリソースエントリは LINSTOR のデータベーステーブルから削除されます。
LINSTORリソースを削除することは、単にリソースを削除する以上の影響をクラスターに及ぼす可能性があります。例えば、リソースがDRBDレイヤーで構成されている場合、3ノードクラスターの1つのノードからリソースを削除すると、そのリソースに設定されていた特定のクォーラム関連のDRBDオプションも（もし存在していれば）削除される可能性があります。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
リソース定義の削除とは異なり、リソースのストレージプールのスナップショットが存在している状態でも、リソースを削除することができます。リソースのストレージプールにある既存のスナップショットはすべてそのまま保持されます。
2.14.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.15. データベースのバックアップと復元
バージョン1.24.0以降、LINSTORにはLINSTORデータベースをエクスポートおよびインポートするためのツールがあります。
このツールには、/usr/share/linstor-server/bin/linstor-database という実行可能ファイルがあります。この実行可能ファイルには、export-db と import-db という2つのサブコマンドがあります。両方のサブコマンドは、linstor.toml 構成ファイルが含まれているディレクトリを指定するために使用できるオプショナルな --config-directory 引数を受け入れます。
| データベースバックアップの整合性を確保するため、LINSTORデータベースのバックアップを作成する前に、以下のコマンドに示すようにコントローラサービスを停止してコントローラをオフラインにしてください。 |
2.15.1. データベースのバックアップ
LINSTORデータベースをホームディレクトリに db_export という新しいファイルにバックアップするために、次のコマンドを入力してください：
# systemctl stop linstor-controller # /usr/share/linstor-server/bin/linstor-database export-db ~/db_export # systemctl start linstor-controller
必要に応じて、linstor-database ユーティリティで --config-directory 引数を使用して LINSTOR 設定ディレクトリを指定できます。この引数を省略した場合、ユーティリティはデフォルトで /etc/linstor ディレクトリを使用します。
|
データベースのバックアップが完了したら、バックアップファイルを安全な場所にコピーしてください。
# cp ~/db_export <somewhere safe>
作成されたデータベースバックアップはプレーンなJSONドキュメントであり、実際のデータだけでなく、バックアップの作成日時や作成元のデータベース、その他の情報などのメタデータも含まれています。
2.15.2. バックアップからデータベースを復元する
以前に作成したバックアップからデータベースを復元する手順は、 前のセクション で説明した export-db と似ています。
たとえば、以前に作成したバックアップを db_export ファイルから復元する場合は、次のコマンドを入力してください。
# systemctl stop linstor-controller # /usr/share/linstor-server/bin/linstor-database import-db ~/db_export # systemctl start linstor-controller
以前のバックアップからデータベースをインポートする際には、現在インストールされているLINSTORのバージョンが、バックアップを作成したバージョンと同じかそれ以上である必要があります。もし現在の LINSTOR バージョンが、データベースバックアップを作成したバージョンよりも新しい場合、バックアップをインポートする際にデータはエクスポート時に使用されたバージョンのデータベーススキーマと同じで復元されます。その後、コントローラが再起動すると、データベースが古いスキーマであることを検知し、自動的にデータを現在のバージョンのスキーマに移行します。
2.15.3. データベースの変換
エクスポートされたデータベースファイルにはいくつかのメタデータが含まれているため、エクスポートされたデータベースファイルは、エクスポート元とは異なるデータベースタイプにインポートすることができます。
これにより、例えば etcd 構成から SQL ベースの構成へ変換することが可能になります。データベース形式を変換するための特別なコマンドは必要ありません。--config-directory 引数を使用して適切な linstor.toml 設定ファイルを指定するか、デフォルトの /etc/linstor/linstor.toml を更新して、インポート前に使用したいデータベースタイプを指定するだけです。データベースタイプの指定方法についての詳細は、LINSTOR ユーザガイド を参照してください。バックアップがどのデータベースタイプで作成されたかに関わらず、データは linstor.toml 設定ファイルで指定されたデータベースタイプとしてインポートされます。
3. LINSTOR 応用タスク
3.1. 高可用性 LINSTOR クラスターの作成
デフォルトでは、LINSTORクラスタはひとつだけアクティブなLINSTORコントローラノードから構成されます。LINSTORを高可用性にするためには、コントローラデータベースの複製ストレージを提供し、複数のLINSTORコントローラノードを設けて、常にひとつだけがアクティブとなるようにします。さらに、サービスマネージャ（ここではDRBD Reactor）が、高可用性ストレージのマウントやアンマウント、ノード上でのLINSTORコントローラサービスの起動と停止を管理します。
3.1.1. 高可用性を持つLINSTORデータベースストレージの設定
高可用性ストレージを構成するためには、LINSTOR自体を使用することができます。ストレージをLINSTORの管理下に置く利点の1つは、高可用性ストレージを新しいクラスターノードに簡単に拡張できることです。
HA LINSTORデータベースストレージリソースのためのリソースグループを作成する
まず、後でLINSTORデータベースをバックアップするリソースをスポーンするために使用する、linstor-db-grp という名前のリソースグループを作成してください。環境内の既存のストレージプール名に合わせて、ストレージプール名を適応させる必要があります。
# linstor resource-group create \ --storage-pool my-thin-pool \ --place-count 3 \ --diskless-on-remaining true \ linstor-db-grp
次に、リソースグループに必要な DRBD オプションを設定します。リソースグループから起動したリソースは、これらのオプションを継承します。
# linstor resource-group drbd-options \ --auto-promote=no \ --quorum=majority \ --on-suspended-primary-outdated=force-secondary \ --on-no-quorum=io-error \ --on-no-data-accessible=io-error \ linstor-db-grp
重要：クラスタが自動クォーラムを取得し、io-error ポリシーを使用していること（セクション 自動クォーラムポリシー 参照）、および auto-promote が無効になっていることが重要です。
|
3.1.2. LINSTORデータベースをHAストレージに移行する
linstor_db リソースを作成した後は、LINSTOR データベースを新しいストレージに移動し、systemd マウントサービスを作成することができます。まず、現在のコントローラーサービスを停止して無効にし、後で DRBD Reactor によって管理されるためです。
# systemctl disable --now linstor-controller
次に、systemdのマウントサービスを作成してください。
# 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 がそれらを管理するからです。
3.1.3. 複数のLINSTORコントローラー
次のステップは、linstor_db DRBDリソースにアクセス権があるすべてのノードに LINSTOR コントローラをインストールすることです（DRBDボリュームをマウントする必要があるため、および潜在的な LINSTOR コントローラにしたいため）。 コントローラが drbd-reactor によって管理されていることが重要なので、すべてのノードで linstor-controller.service が無効になっていることを確認してください！ 確実であるために、すべてのクラスタノードで systemctl disable linstor-controller を実行し、前のステップから現在実行されているノードを除くすべてのノードで systemctl stop linstor-controller を実行してください。また、LINSTORのバージョンが1.14.0以上である場合、潜在的なコントローラノードすべてにて chattr +i /var/lib/linstor が設定されているかどうかも確認してください。
3.1.4. サービスの管理
マウントサービスや linstor-controller サービスを開始または停止するには、DRBD Reactor を使用してください。このコンポーネントを、LINSTORコントローラになりうるすべてのノードにインストールし、それらの /etc/drbd-reactor.d/linstor_db.toml 構成ファイルを編集します。有効な昇格プラグインのセクションが次のように含まれている必要があります：
[[promoter]] [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コントローラーDBのリソースファイルを削除（および再生成）しないようにLINSTORサテライトサービスを設定することです。サービスファイルを直接編集せず、systemctl edit を使用してください。LINSTORコントローラーになる可能性があり、かつLINSTORサテライトでもあるすべてのノードで、このサービスファイルを編集してください。
# systemctl edit linstor-satellite [Service] Environment=LS_KEEP_RES=linstor_db
この変更を行った後、全てのサテライトノードで systemctl restart linstor-satellite を実行する必要があります。
| 注意: LINSTOR クライアントの使用 というセクションで説明されているように、複数のコントローラに使用するように LINSTOR クライアントを構成することを確認し、また、Proxmox プラグインなどの統合プラグインも複数の LINSTOR コントローラに対応するように構成しているか確認してください。 |
3.2. DRBDクライアント
--storage-pool オプションの代わりに --drbd-diskless オプションを使用することで、ノード上に永続的にディスクレスな DRBD デバイスを持つことができます。つまり、そのリソースはブロックデバイスとして表示され、既存のストレージデバイスがなくてもファイルシステムにマウントすることができます。リソースのデータは、同じリソースを持つ他のノードを介してネットワーク経由でアクセスされます。
# linstor resource create delta backups --drbd-diskless
注意: --diskless オプションは非推奨となりました。代わりに --drbd-diskless または --nvme-initiator コマンドを使用してください。
|
3.3. LINSTOR – DRBDコンシステンシグループ/マルチボリューム
いわゆる一貫性グループとは、DRBDの機能のひとつです。LINSTORの主な機能のひとつは、DRBDを用いたストレージクラスタを管理することなので、このユーザーガイドで言及されています。1つのリソース内の複数のボリュームが一貫性グループを形成します。
これは、1つのリソースで異なるボリュームに対する変更が他のサテライトでも同じ順番で複製されることを意味します。
したがって、リソース内の異なるボリュームに相互依存データがある場合は、タイミングを気にする必要はありません。
LINSTORリソースに複数のボリュームを配備するには、同じ名前の volume-definitions を2つ作成する必要があります。
# linstor volume-definition create backups 500G # linstor volume-definition create backups 100G
3.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は以下の順序で以下のオブジェクトのプロパティをクエリします:
-
ボリューム定義
-
リソース
-
リソース定義
-
ノード
もし、それらのオブジェクトのどれもが StorPoolName プロパティを含んでいない場合、コントローラーはストレージプールとしてハードコードされた ‘DfltStorPool’ 文字列にフォールバックします。
これはつまり、リソースを展開する前にストレージプールを定義するのを忘れた場合、’DfltStorPool’ という名前のストレージプールが見つからないというエラーメッセージが LINSTOR から表示されることを意味します。
3.5. DRBDを使わないLINSTOR
LINSTORはDRBDを使わずとも使用できます。 DRBDがなくても、LINSTORはLVMおよびZFS 下位ストレージプールからボリュームをプロビジョニングし、LINSTORクラスタ内の個々のノードにそれらのボリュームを作成できます。
現在LINSTORはLVMとZFSボリュームの作成をサポートしており、LUKS、DRBD、または NVMe-oF/NVMe-TCP の組み合わせをそれらのボリュームの上に重ねることもできます。
例えば、LINSTORクラスターで定義されたThin LVMをバックエンドストレージプールとして持っていると仮定します。このストレージプールの名前は thin-lvm です。
# linstor 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-d 上に100GiBのThin LVMを作成するには、LINSTORを使用できます：
# 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-readable フラグを設定して linstor リソースをリストアップしてください。
# linstor --machine-readable resource list | grep device_path
"device_path": "/dev/drbdpool/rsc-1_00000",
もし、このボリューム上にDRBDをレイヤー化したい場合、ZFSやLVMでバックアップされたボリュームに対してLINSTORでのデフォルト --layer-list オプションはどうなるか疑問に思うことでしょう。その場合、以下のようなリソース作成パターンを使用します：
# linstor resource-definition create rsc-1
# linstor volume-definition create rsc-1 100GiB
# linstor resource create --layer-list drbd,storage \
--storage-pool thin-lvm linstor-d rsc-1
その後、linstor-d 上の新しい Thin LVM が DRBD ボリュームをバックアップしていることがわかります。
# linstor --machine-readable resource list | grep -e device_path -e backing_disk
"device_path": "/dev/drbd1000",
"backing_disk": "/dev/drbdpool/rsc-1_00000",
次の表は、どのレイヤーの後にどの子レイヤーが続くかを示しています。
| Layer | Child layer |
|---|---|
DRBD |
CACHE, WRITECACHE, NVME, LUKS, STORAGE |
CACHE |
WRITECACHE, NVME, LUKS, STORAGE |
WRITECACHE |
CACHE, NVME, LUKS, STORAGE |
NVME |
CACHE, WRITECACHE, LUKS, STORAGE |
LUKS |
STORAGE |
STORAGE |
– |
| 1つの層は、層リストに1度しか出現できません。 |
luks レイヤの必要条件についての情報はこのユーザガイドの暗号化ボリュームの節を参照ください。
|
3.5.1. NVMe-oF/NVMe-TCP LINSTOR レイヤ
NVMe-oF/NVMe-TCPによって、LINSTORはディスクレスリソースを NVMe ファブリックを介してデータが保存されている同じリソースを持つノードに接続することが可能となります。これにより、リソースをローカルストレージを使用せずにマウントすることができ、データにはネットワーク経由でアクセスします。LINSTORはこの場合にDRBDを使用しておらず、そのためLINSTORによってプロビジョニングされたNVMeリソースはレプリケーションされません。データは1つのノードに保存されます。
NVMe-oFはRDMAに対応したネットワークでのみ動作し、NVMe-TCPはIPトラフィックを運ぶことができるネットワークで動作します。ネットワークアダプタの機能を確認するためには、lshw や ethtool などのツールを使用できます。
|
LINSTORとNVMe-oF/NVMe-TCPを使用するには、サテライトとして機能し、リソースにNVMe-oF/NVMe-TCPを使用する各ノードに nvme-cli パッケージをインストールする必要があります。例えば、DEBベースのシステムでは、次のコマンドを入力してパッケージをインストール します：
# apt install nvme-cli
DEBベースのシステムでない場合は、お使いのオペレーティングシステムに適したパッケージをインストールするためのコマンドを使用してください。例えば、SLESでは zypper 、RPMベースのシステムでは dnf を使用します。
|
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 は、リソースグループまたはコントローラーレベルで設定することもできます。
次に、リソースのためのボリューム定義を作成してください。
# 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で問題が発生する可能性があります。 |
3.5.2. 書き込みキャッシュレイヤー
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つのプロパティは必須ですが、WRITECACHE を持つすべてのリソースに対してデフォルトとして機能するコントローラーレベルでも設定することができます。ただし、Writecache/PoolName は対応するノードを指します。ノードに pmempool というストレージプールがない場合、エラーメッセージが表示されます。
DM-Writecache による必須の4つのパラメータは、プロパティを介して設定されるか、LINSTORによって解決されます。前述のリンクに記載されているオプションのプロパティは、同様にプロパティを介して設定できます。linstor controller set-property --help を参照して、Writecache/* プロパティキーのリストを確認してください。
外部メタデータを使用するようにDRBDを設定しているときに --layer-list DRBD、WRITECACHE、STORAGE を使用すると、外部メタデータを保持するデバイスではなく、下位デバイスのみが書き込みキャッシュを使用します。
3.5.3. キャッシュレイヤー
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 の値を設定するからです。
|
linstor controller set-property --help を参照し、Cache/* プロパティのキーと、省略されたプロパティのデフォルト値の一覧を確認してください。
外部メタデータを使用するようにDRBDを設定しているときに --layer-list DRBD,CACHE,STORAGE を使用すると、外部メタデータを保持するデバイスではなく、下位デバイスのみがキャッシュを使用します。
3.5.4. ストレージレイヤー
ストレージレイヤーは、LVM、ZFS などのよく知られたボリュームマネージャーからの新しいデバイスを提供します。リソースがディスクレスである必要がある場合（そのタイプは専用の「ディスクレス」プロバイダータイプ）でも、すべてのレイヤーの組み合わせはストレージレイヤーに基づく必要があります。
プロバイダとその特性のリストについては、 ストレージプロバイダ を参照してください。
一部のストレージプロバイダー用に、LINSTOR には特別なプロパティがあります。
StorDriver/WaitTimeoutAfterCreate-
LINSTORは、デバイスが作成された後に登場することを期待しています（たとえば、
lvcreateやzfs createの呼び出しの後など）。LINSTORは、デフォルトでデバイスが登場するのを500ミリ秒待ちます。これらの500ミリ秒は、このプロパティによって上書きすることができます。 StorDriver/dm_stats-
trueに設定されている場合、LINSTORはボリュームの作成後にdmstats create $deviceを呼び出し、削除後にはdmstats delete $device --allregionsを呼び出します。現在は、LVMおよびLVM_THINストレージプロバイダーのみが有効です。
3.6. ストレージプロバイダー
LINSTOR にはいくつかのストレージプロバイダーがあります。最も使用されているのは LVM と ZFS です。しかし、これら 2 つのプロバイダーについても、シンプロビジョニングされた異なるサブタイプがすでに存在します。
-
Diskless: このプロバイダータイプには、 Managing Network Interface Cards で説明されているように
PrefNicなどの LINSTOR プロパティで構成できるストレージプールがほとんどの場合必要です。 -
LVM / LVM-Thin: 管理者は、対応するストレージタイプを使用するために LVM ボリュームグループまたは thin-pool (“LV/thinpool” の形式で) を指定することが期待されています。これらのドライバは、以下のプロパティを微調整するためのサポートを提供しています。
-
StorDriver/LvcreateOptions: このプロパティの値は、LINSTOR が実行するすべてのlvcreate …呼び出しの LINSTOR 実行に追加されます。
-
-
ZFS / ZFS-Thin: 管理者は、LINSTORが使用すべきZPoolを指定することが期待されています。これらのドライバは、微調整用に以下のプロパティをサポートしています。
-
StorDriver/ZfscreateOptions: このプロパティの値は、LINSTOR が実行するすべてのzfs create …呼び出しの LINSTOR 実行に追加されます。
-
-
File / FileThin: 主にデモンストレーションや実験に使用されます。LINSTORは指定されたディレクトリにファイルを確保し、そのファイルの上に loopデバイス を構成します。
-
SPDK: 管理者は、LINSTORが使用するべき論理ボリュームストアを指定する必要があります。このストレージプロバイダの使用は、 NVME Layer の使用を意味します。
-
Remote-SPDK: この特別なストレージプロバイダーは現在「特別なサテライト」上で実行する必要があります。詳細については Remote SPDK Provider を参照してください。
-
3.6.1. 異なるストレージプロバイダーのストレージプールを混在させる
LINSTORリソースは通常、1つの ストレージプロバイダ タイプで構成されるストレージプールによってバックアップされますが、LINSTORリソースをバックアップするために異なるタイプのストレージプールを使用することも可能です。これを混合ストレージプールと呼びます。これはストレージリソースの移行時に便利かもしれませんが、いくつかの影響をもたらす可能性があります。混合ストレージプールの構成前に、このセクションを注意深く読んでください。
ストレージプールを混在させるための前提条件:
ストレージプールを混在させるには、次の前提条件があります。
-
LINSTOR version 1.27.0 or later
-
LINSTOR satellite nodes need to have DRBD version 9.2.7 (or 9.1.18 if on the 9.1 branch) or later
-
LINSTORプロパティ
AllowMixingStoragePoolDriverが、LINSTORコントローラ、リソースグループ、またはリソース定義のLINSTORオブジェクトレベルでtrueに設定されています。
LINSTORのオブジェクト階層のため、LINSTORコントローラオブジェクトに AllowMixingStoragePoolDriver プロパティを設定すると(linstor controller set-property AllowMixingStoragePoolDriver true）、そのプロパティは、 false に設定されているリソースグループやリソース定義を除くすべてのLINSTORリソースに適用されます。
|
ストレージプールが混在していると見なされる場合:
次のいずれかの基準を満たす場合、LINSTOR はセットアップをストレージプールの混合として考慮します。
-
ストレージプールには異なる領域サイズがあります。例えば、デフォルトではLVMの領域サイズは4MiBですが、ZFS（バージョン2.2.0以降）の領域サイズは16KiBです。
-
ストレージプールには、例えば完全な初期同期や日0ベースの部分同期など、異なるDRBD初期同期戦略があります。
zfsおよびzfsthinストレージプロバイダーがバックアップされたストレージプールを一緒に使用すると、それぞれが初期日0ベースの部分DRBD同期戦略を使用しているため、この基準を満たさないでしょう。
ストレージプールの混合の結果:
複数のストレージプールを組み合わせてバックアップするLINSTORリソースを作成する際は、LINSTORの機能に影響を及ぼす可能性があります。例えば、lvm と `lvmthin `ストレージプールを混在させると、そのような組み合わせでバックアップされた任意のリソースは、厚いリソースと見なされます。これが、LINSTORがストレージプールの混在を許可する仕組みです。
これには、 zfs と zfsthin ストレージプールを組み合わせる例が挙げられます。LINSTORは、 zfs と zfsthin ストレージプールを組み合わせてもストレージプールを混在させたとは考えません。なぜなら、これらの2つのストレージプールは同じ拡張サイズを持ち、両方のストレージプールが同じDRBD初期同期戦略であるday 0ベースの部分同期を使用するためです。
3.6.2. リモート 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」リソースを作成し、 --nvme-initiator オプションを有効にした2つ目のリソースを作成します。
3.7. ネットワークインターフェイスカードの管理
LINSTORは1台のマシン内で複数のネットワークインターフェイスカード（NICs）を扱うことができます。LINSTORの用語ではこれらは「net interfaces」と呼ばれています。
| サテライト ノードが作成されると、最初のネット インターフェイスが「default」という名前で暗黙的に作成されます。サテライトノードを作成するときに、node create コマンドの –interface-name オプションを使用して別の名前を付けることができます。 |
既存のノードの場合、次のように追加のネットインターフェイスが作成されます。
# linstor node interface create node-0 nic_10G 192.168.43.231
ネットワークインターフェースはIPアドレスのみによって識別されます。その名前は任意であり、Linuxで使用されるNIC名とは関係ありません。LINSTORのネットワークインターフェース名は任意ですが、いくつかの命名制限があります。
-
3文字以上
-
最大32文字
-
英字（大文字・小文字を区別しない）またはアンダースコア（
_）で始まる必要があります。 -
使用可能な文字は、英数字、アンダースコア（
_）、およびハイフン（-）です。
ネットワークインターフェースを作成後、それをノードに割り当てることで、そのノードのDRBDトラフィックが対応するNICを経由してルーティングされるようになります。
# linstor node set-property node-0 PrefNic nic_10G
| ストレージプールに「PrefNic」プロパティを設定することもできます。ストレージプールを使用するリソースからの DRBD トラフィックは、対応する NIC 経由でルーティングされます。ただし、ここで注意が必要です。ディスクレスストレージを必要とする DRBD リソース (たとえば、DRBD クォーラムの目的でタイブレーカーの役割を果たしているディスクレス ストレージ) は、「default」ネットインターフェイスの「PrefNic」プロパティを設定するまで、デフォルトのサテライトノードのネットインターフェイスを通過します。セットアップが複雑になる可能性があります。ノードレベルで「PrefNic」プロパティを設定する方がはるかに簡単で安全です。これにより、ディスクレスストレージプールを含む、ノード上のすべてのストレージプールが優先 NIC を使用します。 |
コントローラーとサテライト間の通信専用のインターフェースを追加する必要がある場合は、前述の node interface create コマンドを使用してインターフェースを追加できます。次に、その接続設定を変更して、アクティブなコントローラー・サテライト間接続にします。例えば、すべてのノードに satconn_1G という名前のインターフェースを追加した場合、追加後に次のコマンドを入力することで、LINSTORがこのインターフェースをコントローラー・サテライト間の通信に使用するように設定できます。
# linstor node interface modify node-0 satconn_1G --active
この変更は、`linstor node interface list node-0`コマンドを使用して確認できます。コマンドの出力には、`satconn_1G`インターフェースに`StltCon`ラベルが適用されていることが表示されるはずです。
この方法では指定されたNICを介してDRBDトラフィックをルーティングしますが、例えば、LINSTORクライアントからコントローラに発行するコマンドなど、LINSTORコントローラークライアント間のトラフィックを特定のNICを介してルーティングすることは、linstor コマンドだけでは不可能です。これを実現するためには、次のいずれかの方法を取ることができます:
-
LINSTORクライアントの使用方法 に記載されている方法を使用して、LINSTORコントローラーを特定し、コントローラーへの唯一のルートを、コントローラーとクライアント間の通信に使用したいNICを通じて指定してください。
-
ip routeやiptablesなどの Linux ツールを使用して、LINSTOR クライアントコントローラートラフィックのポート番号 3370 をフィルタリングし、特定の NIC を介してルーティングする。
3.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
例では、最初の4つのコマンドは、各ノード（alpha と bravo）にネットワークインターフェース（nic1 と nic2）を定義し、ネットワークインターフェースのIPアドレスを指定しています。最後の2つのコマンドは、LINSTORが生成する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リソース接続パスを作成する際に無視されます。その代わり、コマンドは動的にポート番号を割り当て、ポート番号7000から増分して割り当てます。LINSTORがポートを動的に割り当てる際に使用するポート番号範囲を変更したい場合は、LINSTORコントローラーオブジェクトの TcpPortAutoRange プロパティを設定することができます。詳細については、linstor controller set-property --help を参照してください。デフォルトの範囲は7000から7999です。
|
新しい DRBD パスを追加するとデフォルトパスにどのように影響するか.
LINSTORサテライトノード上で最初に順番に配置されたNICは、「default」ネットインターフェースと名前が付けられています。具体的に構成されたリソース接続パスを持たない2つのノード間を移動するDRBDトラフィックは、この「default」ネットインターフェースを使用する暗黙的な経路を取ります。
二つのノード間にDRBDをバックエンドとするリソースの接続パスを追加すると、二つのノード間のDRBDトラフィックはこの新しいパスのみを使用します。ただし、 デフォルト のネットワークインターフェースはそれぞれのノードに依然として存在します。新しいパスが暗黙のデフォルトパスとは異なるNICを使用している場合、これは重要なポイントとなります。
デフォルトのパスを再度使用するには、追加で新しいパスに加えて、明示的にそれを追加する必要があります。例えば、
# linstor resource-connection path create alpha bravo myResource path3 default default
新たに作成された path3 は、両ノードで default という名前のネットワークインターフェースを使用していますが、このパス自体は他のパス、つまり path1 と path2 が存在するため、デフォルトパスではありません。新しいパス path3 は単に第三の可能なパスとして機能し、DRBDのトラフィックとパス選択の動作は次のセクションで説明されている通りになります。
複数のDRBDパスの動作
複数の DRBD パス構成の動作は、利用する DRBD トランスポートのタイプによって異なります。DRBD ユーザーガイド[1]に詳細が記載されています。
TCPトランスポートは1度に1つのパスを使用します。 もしバックグラウンドのTCP接続が切断されたり、タイムアウトを示した場合、TCPトランスポートの実装は次のパス上で接続を確立しようとします。 すべてのパスをラウンドロビン方式で通り、接続が確立されるまで続きます。
RDMA転送は接続のすべてのパスを同時に使用し、パス間のネットワークトラフィックを均等に分散します。
3.8. 暗号化ボリューム
LINSTORはDRBDボリュームの暗号化を透過的に扱うことができます。dm-cryptがストレージデバイスから提供されるストレージを暗号化するのに使われます。
dm-crypt を使用するには、’cryptsetup’ がインストールされていることを、サテライトを起動する前に確認してください。
|
暗号化の基本的な手順は以下になります。
-
マスターパスフレーズを作成する
-
luksをレイヤーリストに追加してください。すべてのプラグイン（例：Proxmox）は、明示的に他に指定しない限り、DRBDレイヤーを最上位のレイヤーとして必要とします。 -
コントローラが再起動した後はマスターパスフレーズを再入力する
3.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は暗号化されたボリュームをオープンしたり作成したりできません。 |
3.8.2. 自動パスフレーズ
マスターパスフレーズの作成と再入力のプロセスを自動化することは可能です。
これを使用するには、 MASTER_PASSPHRASE という名前の環境変数、またはマスターパスフレーズを含む /etc/linstor/linstor.toml のエントリを作成する必要があります。
linstor.toml は以下のようになります。
[encrypt] passphrase="example"
もしどちらかが設定されている場合、コントローラーが起動する度にマスターパスフレーズがすでに存在するかどうかをチェックします。もし存在しない場合は、指定された通りに新しいマスターパスフレーズを作成します。存在する場合は、コントローラーはパスフレーズを入力します。
マスターパスフレーズが既に設定されており、その環境変数や linstor.toml で指定されているものと異なる場合、コントローラーはマスターパスフレーズを再入力できず、ユーザーが間違ったパスフレーズを入力したかのように反応します。これは、コントローラーが自動的なパスフレーズなしで起動された場合と同じコマンドを使用して、ユーザーが手動で入力することでのみ解決できます。
|
マスターパスフレーズが環境変数と linstor.toml の両方に設定されている場合、linstor.toml からのマスターパスフレーズのみが使用されます。
|
3.9. クラスター状態の確認
LINSTORは、クラスタの状態を確認するためのさまざまなコマンドを提供しています。これらのコマンドは、’list’の接頭辞で始まり、その後にさまざまなフィルタリングやソートオプションを使用することができます。’–groupby’オプションを使用して、出力を複数の次元でグループ化および並べ替えることができます。
# linstor node list # linstor storage-pool list --groupby Size
3.10. ノードの退避
LINSTOR コマンド node evacuate を使用して、ノードのリソースを退避することができます。たとえば、クラスターからノードを削除する準備をしていて、ノードのリソースをクラスター内の他のノードに移動する必要がある場合です。ノードの退避に成功すると、ノードの LINSTOR ステータスは “Online” ではなく “EVACUATE” と表示され、LINSTOR リソースを持ちません。
| KubernetesやOpenNebulaなどの別の環境にLINSTORがデプロイされているノードを退避させる場合、リソースを退避させる前に、そのノードにあるLINSTORを使用したワークロードをクラスター内の別のノードに移動するか、各リソースのレプリカ数を1つ減らす必要があります。Kubernetes環境における特別な手順や注意事項については、Kubernetes でのノードの退避セクションを参照してください。OpenNebulaのLINSTORノードの場合は、リソースを退避させる前に、そのノードがホストしているLINSTORベースのOpenNebula仮想マシンを、クラスター内の別のノードへライブマイグレーションさせる必要があります。 |
次の手順でノードを退避します。
-
退避するノード上のリソースが “InUse” であるかどうかを確認します。 “InUse” ステータスは、リソースが DRBD Primary 状態です。ノードを正常に退避させるには、ノード上のリソースを “InUse” にしないでください。そうしないと、LINSTOR は退避中にノードから “InUse” リソースを削除できません。
-
linstor node evacuate <node_name>を実行します。退避対象のノード上のリソースに対して適切な代替ノードがない場合、警告が表示されます。例えば、3つのノードがある環境で1つのノードを退避させようとした際、リソースグループの配置数が3に設定されていると、警告が表示され、退避対象ノードからリソースを削除できなくなります。これは、退避対象ノード上のリソースレプリカを現在のレプリカ数を維持したまま再割り当てするためには、退避対象ノードのリソースを構成するLINSTORストレージプールに参加しているノードが、クラスター内に少なくとももう1つ必要になるためです。 -
ノードの
linstor node listのステータスが、 “Online” ではなく、 “EVACUATE” であることを確認してください。 -
linstor resource listコマンドを使用して、ノード上のリソースの「状態」ステータスを確認してください。ノードのリソースに含まれるデータセットのサイズに応じて、しばらくの間同期が行われる活動が見られるはずです。 -
linstor resource list --nodes <node_name>コマンドを使用して、ノード上の残りのリソースを一覧表示します。残っている場合は、同期が完了するのを待っているだけかどうかを確認します。 -
linstor resource listコマンドを使用して、ノードにリソースがないことを確認します。 -
linstor node delete node_name>コマンドを使用して、クラスタからノードを削除します。
3.10.1. 複数のノードの退避
一部の避難ケースでは特別な計画が必要になることがあります。たとえば、複数のノードを避難させる場合、LINSTORのリソース自動配置機能からノードを除外する必要があります。避難させたい各ノードで次のコマンドを使用することでこれを実行できます。
# linstor node set-property <node_name> AutoplaceTarget false
これにより、退避しようとしているノードから、退避を計画している別のノードに LINSTOR がリソースを配置することがなくなります。
3.10.2. 退避ノードの復元
もしすでに完了しているか、まだリソースが「Evacuating」状態にある node evacuate コマンドを実行している場合、node restore コマンドを使用してノードから「Evacuating」状態を削除することができます。これは、まだ node delete コマンドを実行していない場合に機能します。
ノードを復元した後は、前に AutoplaceTarget プロパティを “false” に設定していた場合は、node set-property <node_name> AutoplaceTarget true コマンドを使用する必要があります。これにより、LINSTORは再度リソースを自動的にノードに配置して、クラスター内のリソースに設定した配置数のプロパティを満たすことができます。
node restore コマンドを実行する際にLINSTORがすでにリソースを避難させている場合、避難されたリソースは自動的にノードに戻りません。 LINSTORがまだリソースを避難中の場合、この過程は続行され、LINSTORがリソースを他のノードに配置するまで続きます。 元のノードに以前配置されていたリソースを手動で「移動」する必要があります。これは、まず復元されたノードにリソースを作成し、その後、LINSTORがそれらを配置した可能性のある他のノードからリソースを削除することで行います。 resource list コマンドを使用して、どのノードにリソースが配置されているかを確認できます。
|
3.11. リソースのスナップショットとバックアップの取り扱い
LINSTORは、thin LVMまたはZFSストレージプールでバックアップされたリソースのスナップショットを取ることをサポートしています。スナップショットを作成して転送することで、LINSTORリソースを他のストレージにバックアップすることができます。これは、S3ストレージまたは別の（または同じ）LINSTORクラスタ内のストレージにバックアップする際に有用です。以下のサブセクションでは、スナップショットとバックアップの作業に関連するさまざまな側面について説明します。
3.11.1. スナップショットの作成
ノードに配置された’resource1’という名前のリソースを想定して、そのリソースのスナップショットを作成するには、次のコマンドを入力してください。
# linstor snapshot create resource1 snap1
これにより、リソースが存在するすべてのノードでスナップショットが作成されます。LINSTORは、リソースがアクティブに使用されている場合でも、一貫したスナップショットを作成します。
リソース定義のプロパティ 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
3.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 --help）。
3.11.3. スナップショットへのロールバック
LINSTORはリソースをスナップショットの状態に巻き戻すことができます。リソースは使用中であってはいけません。つまり、リソースはどのノードにもマウントされていてはいけません。もしリソースが使用中であれば、代わりに スナップショットを復元する ことで目標を達成できるかどうか考えてください。
ロールバックは次のようにして実行します。
# linstor snapshot rollback <resource-name> <snapshot-name>
LINSTORバージョン1.31.2以降のスナップショットロールバック機能は、以前のバージョンとは動作が異なります。以前のLINSTORバージョンでは、リソースを保持するすべてのディスクフル（diskful）ノードにスナップショットが存在する場合にのみ、そのスナップショットからリソースをロールバックすることができました。例えば、2つのノードにディスクフルでデプロイされているリソースのスナップショットを作成した後に、別のノードへそのリソースを追加でデプロイした場合、以前作成したスナップショットからロールバックすることはできなくなっていました。ロールバックを試みても、新しいノードにスナップショットが存在しないためロールバックできないというエラーメッセージが表示されていました。
LINSTORバージョン1.31.2以降では、スナップショットのロールバック後に、新しいノードが空のリソースを作成して他のディスクありノードからデータを同期できるようになったため、この制限は存在しません。しかし、この新しい挙動には直感に反する副作用があります。スナップショットを持つリソースを特定のノードから削除した後に、そのスナップショットからロールバックを行うと、リソースを削除したノードを含め、そのリソースのディスクありノード上でリソースが復元されます。この副作用により、リソースが想定よりも多くのノードに配置される結果となる場合がありますが、ロールバック後、LINSTORの定期的な「リソースバランス調整タスク（balance resource task）」によって、クラスター内のディスクありリソースの数は最終的にリソースの配置数（placement count）通りに復元されます。
3.12. スナップショットの転送
スナップショットを送受信するサテライトには、次のツールをインストールします。
-
zstdはデータが転送される前に圧縮するために必要です。 -
LVMのthinプロビジョニングボリュームを使用する際には、データを転送するために
thin-send-recvが必要です。
| これらのツールをインストールした後は、サテライトノード(またはノード)を再起動する必要があります。そうしないと、LINSTORはこれらのツールを使用できません。 |
3.12.1. スナップショット形式の配送リモートとの作業
LINSTORクラスターでは、スナップショットの転送先をリモートと呼びます。現在、スナップショットを転送する際に使用できる2つの異なる種類のリモートがあります: LINSTORリモートとS3リモート。 LINSTORリモートは、スナップショットを別のLINSTORクラスターや同じLINSTORクラスター内に転送するために使用されます。 S3リモートは、スナップショットをAWS S3、MinIO、またはS3互換のオブジェクトストレージを使用する他のサービスに転送するために使用されます。 リモート上に転送されたスナップショットはバックアップとも呼ばれます。
| リモートはパスワードなどの機密データを保存する必要があるため、リモートをどのように使用するかにかかわらず、いつでも暗号化を有効にする必要があります。LINSTORの暗号化の設定方法はこちらに記載されています。 |
S3リモートの作成
S3リモートを作成するには、LINSTORはエンドポイントの情報（つまり、対象となるS3サーバーのURL）、対象バケットの名前、S3サーバーが存在する地域、およびバケットにアクセスするために使用するアクセスキーとシークレットキーが必要です。シークレットキーを追加せずにコマンドを送信すると、入力を求めるプロンプトが表示されます。コマンドは次のようになります:
# linstor remote create s3 myRemote s3.us-west-2.amazonaws.com \ my-bucket us-west-2 admin password
通常、LINSTORはエンドポイントとバケットを使用して、与えられたバケットへのアクセスに仮想ホスト形式を使用したURLを作成します（例：my-bucket.s3.us-west-2.amazonaws.com）。もし設定がこの方法でのアクセスを許可していない場合は、s3.us-west-2.amazonaws.com/my-bucket のようなパス形式でアクセスするようにリモートを変更し、--use-path-style 引数を追加してLINSTORがパラメータを適切に組み合わせるようにします。
|
LINSTOR リモートの作成
LINSTORリモートを作成するには、リモートの名前とターゲットクラスタのコントローラのURLまたはIPアドレスを指定するだけです。例として、次のようなコマンドがあります：
# linstor remote create linstor myRemote 192.168.0.15
2つのLINSTORクラスタ間、または同じLINSTORクラスタ内でスナップショットを転送するには、ソースクラスタに対象クラスタを指すリモートを作成するだけでなく、対象クラスタでもソースクラスタを指すLINSTORリモートを作成する必要があります。これは、未知のソースからのバックアップ転送を受け入れないようにするためです。対象クラスタでこのようなリモートを作成するには、remote create コマンドに追加の引数としてソースクラスタのクラスタIDを指定します。詳細については、 LINSTOR へのスナップショットの送信 を参照してください。
リモートの一覧表示、変更、削除
ローカルクラスタに知られているすべてのリモートを表示するには、 linstor remote list を使用します。 リモートを削除するには、linstor remote delete myRemoteName を使用します。 既存のリモートを変更する必要がある場合は、 linstor remote modify を使用して変更してください。
リモートを作成する際にLINSTORのパスフレーズを指定します。
欲しいスナップショットにLUKSのレイヤーが含まれている場合、ターゲットクラスターのリモートでも、リモートを作成する際にソースクラスターのパスフレーズが必要です。これは、LUKSのパスフレーズを暗号化するためにLINSTORのパスフレーズが使用されるためです。ターゲットクラスターでLINSTORリモートを作成する際にソースクラスターのLINSTORのパスフレーズを指定するには、入力してください。
$ linstor --controllers <TARGET_CONTROLLER> remote create linstor \ --cluster-id <SOURCE_CLUSTER_ID> --passphrase <SOURCE_CONTROLLER_PASSPHRASE> <NAME> <URL>
LINSTORからLINSTORスナップショットの転送を行うには、ソースクラスタにもLINSTORリモートを作成する必要があります。簡単のため、厳密には必須ではありませんが、バックアップやスナップショットを転送する前に、ソースクラスタでターゲットクラスタのLINSTORパスフレーズを指定することができます。ソースクラスタで、次のように入力してください:
$ linstor --controllers <SOURCE_CONTROLLER> remote create linstor \ --cluster-id <TARGET_CLUSTER_ID> --passphrase <TARGET_CONTROLLER_PASSPHRASE> <NAME> <URL>
| もしあなたが 高可用性コントローラ を所有しているために、LINSTORコントローラノードを指定する場合、リモートを作成する際には、コントローラをIPアドレスまたは解決可能なホスト名で指定できます。 |
3.12.2. S3リモートへのスナップショットの送信
スナップショットをS3リモートに送信するには、つまり、リソースのバックアップをS3リモートに作成するには、現在のクラスタがアクセスできるS3リモートを指定し、送信するリソースを指定するだけです。次のコマンドは、リソース myRsc のスナップショットを作成し、指定したS3リモート myRemote に送信します:
# linstor backup create myRemote myRsc
もし、このリソースのバックアップをこのリモートに転送するのが初めてでなく、以前のバックアップのスナップショットがまだ削除されていない場合、差分バックアップが転送されます。フルバックアップを強制的に作成するには、コマンドに --full 引数を追加してください。特定のノードにバックアップを転送させることも可能で、--node myNode を使用しますが、指定されたノードが利用できないかリソースのディスクがない場合は、別のノードが選択されます。
3.12.3. LINSTOR リモートにスナップショットを送信する
リモート LINSTOR を指定することで、2つの LINSTOR クラスター間でスナップショットを転送することができます。リモートの LINSTOR へのスナップショット転送には、少なくとも1つのディスクフル リソースがソース側に必要です（つまり、転送コマンドを実行する側）。
LINSTORターゲットクラスター用のリモートの作成:
LINSTOR ターゲットクラスタにスナップショットを送信する前に、ターゲット側で LINSTOR リモートを作成 し、ソースクラスタのクラスタIDをリモートとして指定する必要があります。
$ linstor remote create linstor --cluster-id <SOURCE_CLUSTER_ID> <NAME> <URL>
ソースクラスタのクラスターIDを指定しないで、ターゲットクラスターでLINSTORリモートを作成すると、バックアップを転送しようとするときに「不明なクラスター」エラーが発生します。ソースクラスタのクラスターIDを取得するには、ソースクラスタからコマンド linstor controller list-properties | grep -i cluster を入力してください。
|
| もし、 LUKSレイヤー を持つリソースのスナップショットを作成して配信する必要がある場合は、リモートを作成する際にパスフレーズを指定する必要があります。 |
上記に示す remote create コマンドでは、<NAME> はリモートを識別するために指定する任意の名前です。<URL> は、ソース（リモート）の LINSTOR コントローラーのIPアドレスまたはその解決可能なホスト名です。もし高可用性の LINSTOR コントローラーを構成している場合は、その仮想IPアドレス（VIP）またはVIPの解決可能な名前を使用してください。
LINSTOR へのスナップショットの送信
ソースのLINSTORクラスタからリソースのスナップショットを作成し、それをターゲットのLINSTORクラスタに送信するには、次のコマンドを入力してください。
# linstor backup ship myRemote localRsc targetRsc
このコマンドは、基本的にはローカルリソースをターゲットのLINSTORリモートにバックアップするものです。
さらに、--source-node を使用して送信するノードを指定し、--target-node を使用してバックアップを受信するノードを指定することができます。これらのノードが利用できない場合、LINSTORコントローラーは自動的に異なるノードを選択します。
targetRsc がすでにリモートクラスタにデプロイされているリソースである場合、 localRsc のバックアップ転送のスナップショットはリモートクラスタに転送されますが、リモートクラスタでは復元されません。 linstor backup ship コマンドで --download-only オプションを指定した場合も同様です。
|
LINSTOR へのスナップショットの送信
WAN経由でリモートのLINSTORクラスターにバックアップスナップショットを転送する場合、バックアップを送信するLINSTORサテライトノード上でノードネットワークインターフェースを作成する必要があります。このノードネットワークインターフェースは、サテライトノードがリモートクラスターに到達するために使用するNICに対応している必要があります。コマンドの例は以下の通りです。
# linstor node interface create <node-name> <net-interface-name> <remote-cluster-wan-ip>
`<remote-cluster-wan-ip>`は、リモートのLINSTORコントローラーノードのWAN IPアドレスになります。
バックアップを転送する際は、--target-net-if 引数を使用して、リモートLINSTORクラスターのWAN IPアドレスを持つ、作成済みのネットワークインターフェースを指定してください。コマンド構成の例は以下の通りです。
# linstor backup ship myRemote localRsc targetRsc --target-net-if <net-interface-name>
3.12.4. 単一のLINSTORクラスター内でのスナップショット転送
同じクラスタ内でスナップショットを転送したい場合は、単純にローカルコントローラを指す LINSTOR リモートを作成する必要があります。例えば、LINSTOR コントローラにログインしている場合は、次のコマンドを入力します。
# linstor remote create linstor --cluster-id <CLUSTER_ID> <NAME> localhost
その後、 LINSTORリモートにスナップショットを送る 手順に従うことができます。
3.12.5. リモート上のバックアップを一覧表示します。
特定のS3リモートに存在するバックアップを表示するには、linstor backup list myS3Remote を使用します。リソース名をコマンドに追加して、特定のリソースのバックアップのみを表示するフィルターとして使用するには、引数 --resource myRsc を使用します。--other 引数を使用すると、LINSTORがバックアップとして認識しないバケット内のエントリのみが表示されます。LINSTORは常にバックアップを特定の方法で命名します。リモートのアイテムがこのスキーマに従って命名されている場合は、それがLINSTORによって作成されたバックアップであると推定されるため、このリストにはそれ以外のすべてが表示されます。
LINSTORリモートに存在するバックアップを表示するには、LINSTORターゲットクラスターで linstor snapshot list コマンドを使用します。
3.12.6. リモート上のバックアップを削除する
バックアップの削除に関しては、いくつかのオプションがあります。
-
linstor backup delete all myRemote: このコマンドは、バックアップであると認識されている、つまり期待されるネーミングスキーマに適合している限り、指定されたリモート上のすべての S3 オブジェクトを削除します。現在のクラスターによって作成されたバックアップのみを削除するオプション--clusterがあります。 -
linstor backup delete id myRemote my-rsc_back_20210824_072543: このコマンドは、指定されたリモートから単一のバックアップを削除します。つまり、指定されたIDを持つバックアップであり、リソース名、自動生成されたスナップショット名（back_timestamp）、および設定されている場合はbackup-suffixから構成されます。オプション--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 オブジェクトのリストが表示されます。これを使用して、削除してはならないものが誤って削除されることを防ぐことができます。
|
3.12.7. リモートからバックアップを復元する
バックアップを作成した後におそらく最も重要なタスクは、それを復元することでしょう。S3リモートからバックアップを復元するには、linstor backup restore コマンドを使用できます。
このコマンドを使用すると、バックアップを復元するためのS3リモートの名前、ターゲットノードの名前、およびノード上の復元先リソースの名前を指定します。リソース名が既存のリソース定義と一致しない場合、LINSTORはリソース定義とリソースを作成します。
さらに、バックアップを持つリモート上のリソースの名前を指定する必要があります。これは、--resource または --id 引数のいずれかを使用して行いますが、両方を使用することはできません。
--resource オプションを使用することで、指定したリソースの最新バックアップを復元することができます。例えば、以下のようになります。
# linstor backup restore myRemote myNode targetRsc --resource sourceRsc
--id オプションを使用することで、指定した正確なバックアップを復元することができます。たとえば、最新以外のリソースのバックアップを復元する場合などです。バックアップのIDを取得するには、 バックアップ一覧 を参照してください。
# linstor backup restore myRemote myNode targetRsc --id sourceRsc_back_20210824_072543
LINSTOR (S3以外) リモートにスナップショットを送信する際、--download-only オプションを使用しない限り、またはターゲットリソースに少なくとも1つのレプリカがある場合を除いて、スナップショットは即座にターゲット（リモート）クラスターの指定されたリソースに復元されます。
|
バックアップをリソースに復元すると、LINSTOR は指定したバックアップ（--id オプションを使用する場合）まで、または最新のバックアップまでのリソースの最後の完全バックアップから全てのスナップショットをダウンロードします。これらのスナップショットをダウンロードした後、LINSTOR はスナップショットを新しいリソースに復元します。backup restore コマンドに --download-only オプションを追加することで、スナップショットを新しいリソースに復元せずにスキップすることもできます。
LINSTORは、正しくセットアップされていれば、アップロードしたクラスタだけでなく、他のクラスタからもバックアップを復元するためにダウンロードできます。具体的には、対象リソースには既存のリソースやスナップショットが存在していてはならず、使用されるストレージプールは同じストレージプロバイダである必要があります。対象ノードのストレージプールがバックアップを作成したクラスタと全く同じ名前であれば、追加の操作は不要です。ただし、ノードに異なるストレージプール名がある場合は、 バックアップの復元 コマンドに --storpool-rename オプションを使用する必要があります。このオプションでは、少なくとも1つの oldname=newname ペアが期待されます。元のバックアップのすべてのストレージプールがそのリストに記載されていない場合、LINSTORは対象ノード上でストレージプールの名前がまったく同じであると仮定します。
正確にどのストレージプールをリネームする必要があり、ダウンロードと復元リソースのサイズがどれくらいになるかを知るには、linstor backup info myRemote … コマンドを使用します。リストアコマンドと同様に、--resource または --id オプションを指定する必要があります。backup info コマンドで使用する際、これらのオプションには backup restore コマンドで使用する際と同じ制限があります。リストア後にローカルストレージプールに残る空き容量を示すには、引数 -n myNode を追加します。実際のリストア操作と同様に、backup info コマンドは、対象ノードとソースノードのストレージプール名が完全に一致していると仮定します。そうでない場合は、リストアコマンドと同様に --storpool-rename オプションを使用できます。
LUKS レイヤーがあるバックアップの復元
バックアップを復元する際にLUKS層が含まれている場合、--passphrase 引数が必要です。この引数を使うと、バックアップ元のクラスターのパスフレーズを設定する必要があります。これにより、LINSTORがダウンロード後にボリュームを復号化し、ローカルのパスフレーズで再度暗号化できるようになります。
同時にアクティブな出荷がいくつあるかを制御する
自動化されたタスク（LINSTORの定期的なシッピングまたは外部ツール）が一度に余りにも多くの出荷を開始し、ネットワークやバックアップを送信するノードのいくつかが過負荷になる可能性があるケースがあります。
このような場合の解決策は、同じノードで同時に発生できる出荷量を減らすことです。これは、BackupShipping/MaxConcurrentBackupsPerNode プロパティを使用して行われます。このプロパティは、コントローラーまたは特定のノードで設定することができます。
このプロパティの期待値は数字です。 これを負の数に設定すると、「制限なし」として解釈されますが、ゼロに設定すると、この特定のノードがバックアップを出荷する資格がなくなります。また、コントローラーでこのプロパティを0に設定すると、バックアップ出荷が完全に無効になります。
他のどんな正の数も、ノードごとの同時アクティブな出荷の上限として扱われます。 バックアップ出荷を送信するノードを決定するために、LINSTORは以下のロジックを以下の順序で使用します:
-
コマンドで指定されたノード（別のLINSTORクラスタに送信する場合は
--source-node、S3互換ストレージに送信する場合は--node）がバックアップを送信します。 -
最も利用可能なバックアップスロットを持つノードがバックアップを転送します。
-
もしノードに空きのバックアップスロットがない場合、出荷はキューに追加され、別の出荷が終了してバックアップスロットが利用可能になるとすぐに開始されます。
同じクラスター内へのスナップショットの転送
同じ LINSTOR クラスタ内の別のノードにスナップショットを転送する前に、お使いの LINSTOR クラスタの ID を指定する LINSTOR リモートオブジェクトを作成する必要があります。お使いの LINSTOR クラスタの ID を取得し、そのようなリモートを作成する手順については、 スナップショットを転送する方法 セクションを参照してください。例として、次のコマンドがあります。
# linstor remote create linstor self 127.0.0.1 --cluster-id <LINSTOR_CLUSTER_ID>
self は、あなたが指定したユーザー定義の LINSTOR リモートの任意の名前です。必要に応じて異なる名前を指定することができます。
|
ソースノードとターゲットノードの両方にスナップショット転送用のリソースを展開している必要があります。さらに、ターゲットリソースは非アクティブ化されている必要があります。
# linstor resource deactivate nodeTarget resource1
| DRBDでリソースを非アクティブ化した後、そのレイヤーリスト内のリソースを再度アクティブ化することはできません。ただし、DRBDリソースの正常にシップされたスナップショットは、新しいリソースに 復元することができます。スナップショットのシップを手動で開始するには、次のようにします： |
# linstor backup ship self localRsc targetRsc
snapshot ship コマンドは非推奨とされており、それに関するバグは修正されません。同じLINSTORクラスタ内でスナップショットを送信するには、ローカルコントローラを指すリモートを使用して、上記の例に示されているように backup ship コマンドを使用してください。LINSTORクラスタをリモートとして構成する詳細については、 LINSTOR リモートにスナップショットを送信する セクションを参照してください。
|
デフォルトでは、スナップショット送信機能は TCP ポートを 12000 から 12999 の範囲で使用します。この範囲を変更するには、コントローラーに設定できる SnapshotShipping/TcpPortRange プロパティを設定します。
# linstor controller set-property SnapshotShipping/TcpPortRange 10000-12000
リソースは定期的に出荷することも可能です。これを実現するには、リソース定義に SnapshotShipping/TargetNode および SnapshotShipping/RunEvery のプロパティを設定することが必須です。SnapshotShipping/SourceNode も設定できますが、省略した場合、LINSTORは同じリソース定義のアクティブなリソースを選択します。
増分スナップショット転送を可能にするには、LINSTOR は少なくとも最後に転送されたスナップショットをターゲットノードに保持する必要があります。プロパティ SnapshotShipping/Keep は、LINSTOR が保持する必要があるスナップショットの数を指定するために使用できます。プロパティが設定されていない（または 0 以下）の場合、LINSTOR はデフォルトで最新の10個のスナップショットを保持します。
# linstor resource-definition set-property resource1 SnapshotShipping/TargetNode nodeTarget # linstor resource-definition set-property resource1 SnapshotShipping/SourceNode nodeSource # linstor resource-definition set-property resource1 SnapshotShipping/RunEvery 15 # linstor resource-definition set-property resource1 SnapshotShipping/Keep 5
3.13. 計画されたバックアップの配信
LINSTOR Controller バージョン 1.19.0 以降、LINSTOR クライアントバージョン 1.14.0 以降では、配置された LINSTOR リソースのスケジュールバックアップの配信を設定することができます。
定期的なバックアップの配信は、3つのパートで構成されています。
-
バックアップと配信を行いたい1つまたは複数のLINSTORリソースからなるデータセット
-
バックアップの配信先（他のLINSTORクラスタまたはS3インスタンス）
-
バックアップを発行するタイミングを定義するスケジュール
| LINSTORのバックアップ転送は、LINSTORでサポートされているスナップショット機能を持つthin-provisioned LVMおよびZFSストレージプールでバックアップされた展開済みLINSTORリソースにのみ適用されます。 |
3.13.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スキーマを指定しても、増分バックアップは決して作成されないため、意味がありません。 |
3.13.2. バックアップの配信スケジュールを変更する
LINSTORクライアントの schedule modify コマンドを使用すると、バックアップの出荷スケジュールを変更することができます。 このコマンドの構文は schedule create コマンドの構文と同じです。schedule modify` コマンドで指定する名前は、すでに存在するバックアップスケジュールでなければなりません。コマンドのオプションで指定しないものは、既存の値を保持します。keep-local` または keep-remote オプションをデフォルト値に戻したい場合は、”all “に設定します。max-retries` オプションをデフォルトの値に戻したい場合は、”forever” に設定します。
3.13.3. ローカルスナップショットとリモートバックアップの保持数の設定
物理ストレージは無限ではなく、リモートストレージにはコストがかかるため、スナップショットやバックアップの保存数に制限を設けるとよいでしょう。
--keep-remote オプションと --keep-local オプションの両方が特筆すべきであり、その影響は明らかでない部分もあります。これらのオプションを使用すると、ローカルソースまたはリモート先のいずれかに保存されるスナップショットや完全バックアップの数を指定します。
ローカル保持オプションの設定:
例えば、--keep-local=2 オプションが設定されている場合、バックアップの出荷スケジュールは、最初の実行時に、フルバックアップのためのスナップショットを作成することになります。次にスケジュールされたフルバックアップの出荷では、フルバックアップのための2番目のスナップショットを作成します。次のスケジュールされたフルバックアップの出荷では、フルバックアップのための3番目のスナップショットが作成されます。しかし今回は、正常に完了すると、LINSTORは最初の（最も古い）フルバックアップの出荷用スナップショットを削除します。もしスナップショットがこのフルバックアップに基づく増分バックアップのために作成された場合、それらはローカルソースノードから削除されます。次のフルバックアップの出荷が成功すると、LINSTORは2番目のフルバックアップのスナップショットとそれに基づくすべての増分スナップショットを削除し、これを繰り返すことで各バックアップの出荷が成功します。
| もし失敗した出荷から残っているローカルスナップショットがある場合、それらは、後から作成されたものであっても、最初に削除されます。 |
バックアップ配信スケジュールを有効にしている場合、後から手動で LINSTOR スナップショットを削除した場合、LINSTOR は削除すべきすべてを削除できない可能性があります。例えば、フルバックアップスナップショットの定義を削除した場合、後でフルバックアップの予定された配信で、手動で削除したフルバックアップスナップショットに基づく増分スナップショットが削除されないかもしれません。
保持リモートオプションの設定
上記の linstor schedule create コマンドの例のコールアウトで述べたように、 keep-remote オプションはS3リモートデスティネーションに対してのみ機能します。ここでは、このオプションがどのように機能するかの例を示します。keep-remote=2` オプションが設定されている場合、バックアップ出荷スケジュールは、最初の実行時に、フルバックアップ用のスナップショットを作成し、それをリモートデスティネーションに出荷します。次にスケジュールされたフルバックアップの出荷では、2番目のスナップショットが作成され、フルバックアップがリモートデスティネーションに出荷されます。次にスケジュールされたフルバックアップの出荷時に、3つ目のスナップショットが作成され、フルバックアップがリモートディスティネーションに出荷されます。今回はさらに、3つ目のスナップショットが正常に出荷された後、最初のフルバックアップがリモートディスティネーションから削除されます。フルバックアップの間に増分バックアップがスケジュールされていた場合、最初のフルバックアップから作成されたものはフルバックアップと一緒に削除されます。
| このオプションは、リモート宛先のバックアップを削除するだけです。ローカル ソース ノードでのフル バックアップの基となったスナップショットは削除されません。 |
3.13.4. バックアップの配信スケジュールを記載する
linstor schedule list` コマンドを使用すると、バックアップの配信スケジュールを一覧することができます。
For example:
# linstor schedule list ╭──────────────────────────────────────────────────────────────────────────────────────╮ ┊ Name ┊ Full ┊ Incremental ┊ KeepLocal ┊ KeepRemote ┊ OnFailure ┊ ╞══════════════════════════════════════════════════════════════════════════════════════╡ ┊ my-bu-schedule ┊ 2 * * * * ┊ ┊ 3 ┊ 2 ┊ SKIP ┊ ╰──────────────────────────────────────────────────────────────────────────────────────╯
3.13.5. バックアップした配信予定を削除する
LINSTORクライアントの schedule delete コマンドはバックアップされた配信予定LINSTORオブジェクトを完全に削除するコマンドです。このコマンドの唯一の引数は削除したいスケジュール名です。削除されたスケジュールが現在バックアップを作成または配信している場合、スケジュールされた出荷処理は停止されます。処理が停止した時点によっては、スナップショット、バックアップ、またはその両方が作成および配信されない可能性があります。
このコマンドは、以前に作成されたスナップショットや正常に配信されたバックアップには影響しません。これらは、手動で削除されるまで保持されます。
3.13.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] |
3.13.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リソースのコントローラレベルでのバックアップ出荷スケジュールを無効化します。
3.13.8. バックアップされた出荷予定のアスペクトを削除する
linstor backup schedule delete` コマンドを使うと、スケジュール自体を削除することなく、指定したリソース定義やリソースグループをバックアップ出荷スケジュールからきめ細かく削除することができます。このコマンドは backup schedule disable コマンドと同じシンタックスと引数を持っています。リソースグループもリソース定義も指定しない場合、指定したバックアップ出荷スケジュールはコントローラーレベルで削除されます。
バックアップスケジュール削除 コマンドは、指定されたLINSTORオブジェクトレベル（リソース定義、リソースグループ、または特定されていない場合はコントローラーレベル）からバックアップ配送スケジュールリモートペアを削除する方法として考えると役立つかもしれません。
backup schedule delete` コマンドは以前に作成されたスナップショットや正常にシッピングされたバックアップには影響を与えません。これらは手動で削除されるか、まだ適用可能な keep-local または keep-remote オプションの効果によって削除されるまで保持されます。
このコマンドは、複数のLINSTORオブジェクトレベルのバックアップスケジュールを無効にした後、粒度の細かい変更を行いたい場合に使用します。この場合、backup schedule enable コマンドは意図しない結果をもたらすかもしれません。
たとえば、コントローラーレベルで有効にしたバックアップスケジュール-リモートペアを持つシナリオを考えてみましょう。 このコントローラーには、myresgroup という名前のリソースグループがあり、その下に resdef1 から resdef9 までの複数のリソース定義があります。 メンテナンスのために、おそらく resdef1 と resdef2 の2つのリソース定義のスケジュールを無効にします。 その後、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-remote ペアがリソースグループレベルで有効になっていたからです。しかし、これによりコントローラーレベルで後で全体的にスケジュールされた運送を停止するオプションが削除されます。なぜなら、リソースグループレベルで有効になっているスケジュールが、コントローラーレベルで適用された `schedule disable コマンドを上書きするからです。
|
3.13.9. リソース別バックアップ出荷スケジュール一覧表
LINSTORクライアントの schedule list-by-resource コマンドを使えば、リソースごとのバックアップスケジュールをリストアップすることができます。このコマンドはLINSTORリソースを表示し、バックアップの出荷スケジュールがどのように適用され、どのリモートに出荷されるかを表示します。もしリソースが出荷されていない場合は、このコマンドは表示されます。
-
リソースにschedule-remote-pairのエントリーがないかどうか（空白のセル）
-
schedule-remote-pairの項目があるが、無効になっているかどうか（”disabled”）。
-
リソースがないため、schedule-remote-pairのエントリーが有効かどうかに関わらず、バックアップ出荷ができないかどうか（”undeployed”)
リソースにschedule-remote-pairがあり、出荷されている場合、コマンド出力には、最後のバックアップがいつ出荷されたか、次のバックアップがいつ出荷される予定であるかが表示されます。また、次回のバックアップと前回のバックアップの出荷がフルバックアップかインクリメンタルバックアップかが表示されます。最後に、このコマンドは、増分バックアップ（もしあれば）およびフルバックアップの次の出荷予定日を表示します。
スケジュールリストバイリソースコマンドで --active-only フラグを使用すると、出荷されていないリソースをすべてフィルタリングすることができます。
3.13.10. LINSTORコントローラがスケジュールされたバックアップの出荷を決定する方法
LINSTORコントローラは、デプロイされたLINSTORリソースが特定のリモート宛先に特定のバックアップスケジュールで出荷されるかどうかを判断するために、以下のロジックを使用します。
図に示すように、有効または無効なバックアップ出荷スケジュールは、次の順序で効果を発揮します。
-
リソース定義レベル
-
リソースグループレベル
-
コントローラーレベル
先行するレベルで有効または無効にされたバックアップ出荷スケジュールと遠隔地のペアは、後のレベルで同じスケジュールと遠隔地のペアの有効または無効の状態を上書きします。
3.13.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 ┊ ╰───────────────────────────────────────────────────────────────────────────╯
3.14. LINSTORオブジェクトに対するDRBDオプションの設定:
LINSTORコマンドを使用して、DRBDのオプションを設定することができます。/etc/drbd.d/global_common.confなど、LINSTORで管理されていないファイルに設定された構成は無視されます。このコマンドの構文は一般的には次のようになります:
# linstor <LINSTOR_object> drbd-options --<DRBD_option> <value> <LINSTOR_object_identifiers>
上記の構文では、<LINSTOR_ object_identifiers> はノード名、ノード名、リソース名、またはこれらの識別子の組み合わせなど、識別子のプレースホルダとして使われています。
例えば、backups というリソース定義に対して DRBD レプリケーションプロトコルを設定するには、次のように入力します：
# linstor resource-definition drbd-options --protocol C backups
drbd-options コマンドに --help または -h フラグを付けて LINSTOR オブジェクトを入力すると、コマンドの使用方法や利用可能なオプション、そして各オプションのデフォルト値が表示されます。たとえば、次のようになります：
# linstor controller drbd-options -h
3.14.1. LINSTORリソースまたはリソース接続に対するDRBDピアオプションの設定
LINSTOR リソースオブジェクトは、一般的な LINSTOR オブジェクトの DRBD オプション設定の構文の例外です。この LINSTOR リソースオブジェクトでは、指定した2つのノード間の接続レベルで DRBD オプションを設定するために drbd-peer-options を使用できます。2つのノード間で LINSTOR リソースオブジェクトの drbd-peer-options を指定することは、2つのノード間でリソースの linstor resource-connection drbd-peer-options を使用するのと同等です。
例えば、2つのノード「node-0」と「node-1」の間で名前が「backups」のリソースに対して接続レベルでDRBDの最大バッファサイズを8192に設定する場合は、次のように入力します:
# linstor resource drbd-peer-options --max-buffers 8192 node-0 node-1 backups
上記のコマンドは、次の操作と等価です。
# linstor resource-connection drbd-peer-options --max-buffers 8192 node-0 node-1 backups
実際に、linstor --curl コマンドを使用して、LINSTOR REST API上での2つのコマンドの動作を調べると、出力はまったく同じです。
# 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
node-0 上のLINSTORが生成したリソースファイル backups.res の接続部分は、以下のようになります。
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";
}
}
上記の例のように2つのノード間に複数のパスがある場合、resource drbd-peer-options コマンドを使用して設定する DRBD オプションはすべてのパスに適用されます。
|
3.14.2. リソースのオプション設定ノード間接続のためのDRBDオプションの設定
drbd-peer-options 引数を使用して、2つのノード間で DRBD オプションを接続レベルで設定することができます。例えば、
# linstor node-connection drbd-peer-options --ping-timeout 299 node-0 node-1
前のコマンドは、2つのノード、node-0 と node-1 の間の接続レベルで、DRBDの ping-timeout オプションを29.9秒に設定します。
3.14.3. LINSTORオブジェクトの検証オプションを確認します。
list-properties コマンドを使用して、LINSTORオブジェクトの設定されたプロパティを確認できます。例えば：
# linstor resource-definition list-properties backups ╭──────────────────────────────────────────────────────╮ ┊ Key ┊ Value ┊ ╞══════════════════════════════════════════════════════╡ ┊ DrbdOptions/Net/protocol ┊ C ┊ [...]
3.14.4. LINSTORオブジェクトからDRBDオプションを削除する
以前に設定したDRBDオプションを削除するには、オプション名の先頭に unset- を付けます。例：
# linstor resource-definition drbd-options --unset-protocol backups
同じ構文は、LINSTORリソース、リソース接続、またはノード接続上に設定された drbd-peer-options に適用されます。例えば:
# linstor resource-connection drbd-peer-options --unset-max-buffers node-0 node-1 backups
DRBDオプションまたはDRBDピアオプションを削除すると、そのオプションはデフォルト値に戻ります。オプションのデフォルト値については、linstor <LINSTOR_object> drbd-options --help (または drbd-peer-options --help) コマンドの出力を参照してください。また、DRBDオプションに関する情報は、drbd.conf-9.0 のmanページでも確認できます。
3.15. LINSTORにおけるストレージの過剰割り当て
LINSTOR サーバーバージョン 1.26.0 以降、3 つの LINSTOR オブジェクトプロパティ（MaxOversubscriptionRatio、MaxFreeCapacityOversubscriptionRatio、MaxTotalCapacityOversubscriptionRatio）を使用して、LINSTOR がストレージのオーバープロビジョニングを制限する方法を制御できるようになりました。これらのプロパティは、LINSTOR ストレージプールまたは LINSTOR コントローラーオブジェクトのいずれかに設定できます。コントローラーレベルでこれらのプロパティを設定すると、特定のストレージプールに同じプロパティが設定されていない限り、クラスター内のすべての LINSTOR ストレージプールに影響します。この場合、ストレージプールに設定されたプロパティ値が、コントローラーに設定されたプロパティ値よりも優先されます。
オーバーサブスクリプション比率（over subscription ratios）の値を設定することで、ストレージプールに対して行えるオーバープロビジョニングをLINSTORがどのように制限するかを制御できます。これは、必要が生じた際に物理的に対応できないレベルまでストレージのオーバープロビジョニングが進んでしまうのを避けたい場合に有用です。
以下のサブセクションでは、さまざまなオーバープロビジョニング制限プロパティについて説明します。
3.15.1. 最大空き容量オーバープロビジョニング比率の設定
1.26.0より前のLINSTORサーバーのバージョンでは、シンプロビジョニングされたLVMボリュームまたはZFS zpoolをバックエンドとするストレージプールのオーバープロビジョニング設定は、ストレージプールに残っている空き容量に基づいていました。1.26.0以降のLINSTORサーバーのバージョンでも、このオーバープロビジョニングの方法は引き続き利用可能です。これは、LINSTORストレージプールまたはLINSTORコントローラーのいずれかに MaxFreeCapacityOversubscriptionRatio プロパティの値を設定することで行います。この比率の値を設定すると、ストレージプールの残りの空き容量にその比率の値を乗じたものが、そのストレージプールから新たにプロビジョニングできるボリュームの最大許容サイズとなります。
デフォルトでは、MaxFreeCapacityOversubscriptionRatio の値は 20 です。
クラスター内の node-0 から node-2 までの3つの LINSTOR サテライトノード上にある、my_thin_pool という名前の LINSTOR ストレージプールに対して MaxFreeCapacityOversubscriptionRatio プロパティに異なる値を設定するには、次のコマンドを入力します。
# for node in node-{0..2}; do \
linstor storage-pool set-property $node my_thin_pool MaxFreeCapacityOversubscriptionRatio 10
done
すでにいくつかのストレージリソースをデプロイ済みで、ストレージプールの空き容量が残り10GiBである場合（linstor storage-pool list を実行することで表示されます）、そのストレージプールから新しいストレージリソースをプロビジョニングする際、最大で100GiBのボリュームをプロビジョニングできます。
リソースグループから新しいLINSTORリソース（およびボリューム）を生成する前に、そのリソースグループからLINSTORがプロビジョニングを許可する最大ボリュームサイズを確認できます。これを行うには、`resource-group query-size-info`コマンドを入力します。例えば、`DfltRscGrp`リソースグループに関する情報を表示するには、次のコマンドを入力します：
# linstor resource-group query-size-info DfltRscGrp
コマンドの出力には、指定されたリソースグループの値のテーブルが表示されます：
╭───────────────────────────────────────────────────────────────────╮ ┊ MaxVolumeSize ┊ AvailableSize ┊ Capacity ┊ Next Spawn Result ┊ ╞═══════════════════════════════════════════════════════════════════╡ ┊ 99.72 GiB ┊ 9.97 GiB ┊ 9.97 GiB ┊ my_thin_pool on node-0 ┊ ┊ ┊ ┊ ┊ my_thin_pool on node-2 ┊ ╰───────────────────────────────────────────────────────────────────╯
3.15.2. 最大総容量のオーバープロビジョニング比率の設定
LINSTORサーバーバージョン1.26.0以降、オーバープロビジョニングストレージを制限する別の方法が追加されました。LINSTORストレージプールまたはLINSTORコントローラーの MaxTotalCapacityOversubscriptionRatio の値を設定することで、LINSTORはストレージプールの総容量に基づいて、新しいボリュームの最大サイズを制限します。
これは、ストレージプール内に残っている空き容量に基づいて最大ボリュームサイズを制限する方法と比較して、オーバープロビジョニングを制限するよりもリラックスしている方法です。ストレージプール内でストレージをプロビジョニングし使用すると、空き容量が減少します。しかし、ストレージプールの総容量は、ストレージプールにバッキングストレージを追加しない限り変わりません。
デフォルトで、「MaxTotalCapacityOversubscriptionRatio」の値は20です。
異なる値を設定するには、クラスタ内の3つのLINSTORサテライトノード（ node-0 から node-2 まで）の my_thin_pool というLINSTORストレージプールの MaxTotalCapacityOversubscriptionRatio プロパティに対して、次のコマンドを入力してください：
# for node in node-{0..2}; do \
linstor storage-pool set-property $node my_thin_pool MaxTotalCapacityOversubscriptionRatio 4
done
もし、合計容量が10GiBの薄いプロビジョンの論理ボリュームでバックアップされたストレージプールがある場合、そのストレージプールから作成した新しいストレージリソースは、ストレージプールに残っている空き容量に関係なく、最大サイズが40GiBになります。
3.15.3. オーバープロビジョニングのための最大オーバーサブスクリプション比率の設定
MaxOversubscriptionRatio プロパティをLINSTORストレージプールやLINSTORコントローラーオブジェクトのいずれかに設定した場合、それは MaxFreeCapacityOversubscriptionRatio および MaxTotalCapacityOversubscriptionRatio プロパティの両方の値として機能することができます。ただし、MaxOversubscriptionRatio プロパティは、他の2つのオーバーサブスクリプションプロパティのいずれかの値としてのみ機能しますが、他のプロパティが設定されていない場合です。デフォルトでは、MaxOversubscriptionRatio プロパティの値は20であり、他の2つのオーバーサブスクリプションプロパティのデフォルト値と同じです。
LINSTORコントローラーの MaxOversubscriptionRatio プロパティに異なる値を設定するには、例えば、次のコマンドを入力してください：
# linstor controller set-property MaxOversubscriptionRatio 5
コマンド例でプロパティ値を5に設定することで、10GiBのストレージプールを最大40GiBまでオーバープロビジョニングすることができます。
3.15.4. 複数のオーバー・プロビジョニング・プロパティにおける値の設定が及ぼす影響
前述の通り、3つのオーバープロビジョニング制限 [LINSTOR] プロパティのデフォルト値はそれぞれ20です。ストレージプールとコントローラーの同じプロパティを設定した場合、そのストレージプールにおいてストレージプールに設定されているプロパティの値が優先されます。
MaxTotalCapacityOversubscriptionRatio または MaxFreeCapacityOversubscriptionRatio のどちらかが設定されていない場合、MaxOversubscriptionRatio の値が未設定のプロパティまたはプロパティの値として使用されます。
例えば、次のコマンドを考えてみましょう:
# for node in node-{0..2}; do \
linstor storage-pool set-property $node my_thin_pool MaxOversubscriptionRatio 4
done
# for node in node-{0..2}; do \
linstor storage-pool set-property $node my_thin_pool MaxTotalCapacityOversubscriptionRatio 3
done
MaxTotalCapacityOversubscriptionRatio プロパティを 3 に設定したため、LINSTOR は MaxOversubscriptionRatio プロパティに設定された値ではなく、その値を当該プロパティに使用します。また、MaxFreeCapacityOversubscriptionRatio プロパティを設定しなかったため、LINSTOR は MaxOversubscriptionRatio プロパティに設定した値である 4 を、MaxFreeCapacityOversubscriptionRatio プロパティに使用します。
リソースの配置を決定する際、つまりLINSTORがリソースをストレージプールに配置できるかどうかを判断する際、LINSTORは2つの値を比較します。それは、MaxTotalCapacityOversubscriptionRatio プロパティで設定された比率にストレージプールの総容量を乗じた値と、MaxFreeCapacityOversubscriptionRatio プロパティで設定された比率にストレージプールの利用可能な空き容量を乗じた値です。LINSTORは、計算されたこれら2つの値のうち低い方を使用して、ストレージプールにリソースを配置するための十分なスペースがあるかどうかを判断します。
先行するコマンドによって設定された値を考慮し、ストレージプールの総容量が10GiBである場合を想定します。また、そのストレージプールに関連付けられたデプロイ済みのLINSTORリソースが存在せず、ストレージプールの利用可能な空き容量も10GiBであると仮定します。
| この例は単純化されています。ストレージプールを支えるストレージプロバイダー（例えばZFSやLVMなど）によっては、リソースがデプロイされていない状態であっても、ストレージプールの空き容量が合計容量と等しくならない場合があります。これは、リソースをデプロイする前であっても、ストレージプールのスペースを消費するストレージプロバイダーのインフラによるオーバーヘッドが発生する可能性があるためです。 |
この例では、MaxTotalCapacityOversubscriptionRatio の 3 に合計容量 10GiB を乗じた値が、MaxFreeCapacityOversubscriptionRatio の 4 に空き容量 10GiB を乗じた値よりも小さくなっています。ここで、MaxFreeCapacityOversubscriptionRatio が設定されていないため、LINSTOR は MaxOversubscriptionRatio の値を使用することに注意してください。
したがって、ストレージプールをバックエンドとする新しいリソースをデプロイする際、LINSTORはストレージプールのオーバープロビジョニングを制限し、新しいリソースを配置できるかどうかを判断するために、空き容量に基づく計算ではなく、総容量に基づく計算を使用します。しかし、ストレージリソースのデプロイが進み、それらがデータで満たされるにつれて、ストレージプールの利用可能な空き容量は減少します。このため、総容量の比率が空き容量の比率よりも小さい場合でも、LINSTORがストレージプールのオーバープロビジョニングを制限するために常に総容量に基づく計算を使用するとは限りません。
3.16. リソースのdiskful/diskless状態の切り替え
LINSTORは、リソースが物理ストレージを実体として持つ（ディスクフル）か、あるいは物理ストレージを持たず、代わりにネットワーク経由で他のピアノードに対してI/O操作を行う（ディスクレス）かを変更できます。`resource toggle-disk`コマンドを使用することで、リソースをディスクフルとディスクレスの間で切り替えることができます。このコマンドの構文は`resource create`と同様です。
| 概念的には、これはiSCSIやNVMe-oF接続ストレージにおける「ターゲット」（ディスクあり）と「イニシエータ」（ディスクレス）の関係に似ています。 |
例えば、ノード「alpha」上のディスクレスリソース「backups」に対し、ストレージプールオプションによって指定されるバッキングストレージ上に物理レプリカを作成するには、次のコマンドを入力します。
# linstor resource toggle-disk alpha backups --storage-pool pool_ssd
リソースをディスクレス状態に戻すには、次のコマンドを入力してください。
# linstor resource toggle-disk alpha backups --diskless
3.16.1. 失敗したディスク切り替え操作によりスタックしたリソースの復旧
LINSTORリソースのトグル操作は、バックエンドストレージの問題やLINSTORサテライトサービスの切断などが原因で、失敗することがあります。その際、リソースがトグル状態のまま「スタック」してしまうことがあります。LINSTORバージョン1.34.0以降、リソースがスタックした場合に、失敗したディスクのトグル操作を再試行またはキャンセルすることが可能になりました。
失敗したtoggle-disk操作の根本原因を解決した後、元の`resource toggle-disk`コマンドを再入力することで、操作を再試行できます。あるいは、「反対」のコマンドを入力することで、失敗した操作をキャンセルすることも可能です。例えば、先に示した`linstor resource toggle-disk –diskless`コマンドが途中でスタックした場合、`linstor resource toggle-disk –storage-pool pool_ssd`コマンドを入力してキャンセルします。逆に、ディスクレスリソースをディスクあり（diskful）の状態に切り替えようとしてスタックした場合は、`linstor resource toggle-disk –diskless`コマンドを入力して操作をキャンセルします。
3.16.2. リソースを別のノードへ移行する
リソースを冗長性を減らすことなくノード間で移動するには、LINSTORのディスク移行機能を使用できます。まず、対象のノードにディスクレスリソースを作成し、その後 --migrate-from オプションを使用してディスクを追加します。これにより、データが新しいディスクに同期されるまで待機し、その後ソースディスクを削除します。
例えば、リソースの backup を alpha から bravo に移行するには、次のようにします。
# linstor resource create bravo backups --drbd-diskless # linstor resource toggle-disk bravo backups --storage-pool pool_ssd --migrate-from alpha
3.17. LINSTOR を使用したDRBD Proxy 設定
LINSTORは、DRBD Proxyが接続するノード上で実行されることを期待しています。別のノードのDRBD Proxy経由の接続は、今のところサポートしていません。
クラスターは、ローカルネットワーク内にノード ‘alpha’ と ‘bravo’、リモートサイトにノード ‘charlie’ が存在し、それぞれのノードに backups というリソース定義がデプロイされているとします。その後、DRBD Proxy を ‘charlie’ への接続に有効にすることができます。
# linstor drbd-proxy enable alpha charlie backups # linstor drbd-proxy enable bravo charlie backups
DRBD Proxyの設定は、次のようなコマンドでカスタマイズすることができます。
# linstor drbd-proxy options backups --memlimit 100000000 # linstor drbd-proxy compression zlib backups --level 9
LINSTORは遠距離レプリケーション向けにDRBD設定を自動的に最適化しません。そのため、プロトコルなどの設定オプションをいくつか設定することになるでしょう：
# linstor resource-connection drbd-peer-options alpha charlie backups --protocol A # linstor resource-connection drbd-peer-options bravo charlie backups --protocol A
LINBITに連絡して、構成の最適化に関する支援を受けてください。
3.17.1. DRBD プロキシを自動的に有効にする
LINSTORは、上記のProxy接続を自動的に有効にするように設定することもできます。この自動化のために、LINSTORはまず、各ノードがどのサイトにあるかを知る必要があります。
# linstor node set-property alpha Site A # linstor node set-property bravo Site A # linstor node set-property charlie Site B
`Site`プロパティは将来の機能において他のサイトベースの決定にも使用される可能性があるため、`DrbdProxy/AutoEnable`も`true`に設定する必要があります：
# linstor controller set-property DrbdProxy/AutoEnable true
このプロパティは、ノード、リソース定義、リソース、およびリソース接続のレベルにも設定できます（優先度が低い方から右に向かって増加し、コントローラーが最も優先度が低い、つまり最も優先度が低いレベルである左端に位置しています）。
この初期化ステップが完了すると、すべての新しく作成されたリソースは自動的に、その相互リソースのいずれかにDRBD Proxyを有効にする必要があるかどうかをチェックします。
3.18. 外部データベースプロバイダー
LINSTORはPostgresqlやMariaDBのような外部データベースとともに動作させることもでき、バージョン 1.1.0 以降では etcd キーバリューストアもサポートされています。
外部データベースを使用するには、設定する追加手順がいくつかあります。linstorで使用するためのDB/スキーマとユーザーを作成し、/etc/linstor/linstor.toml でこれを設定する必要があります。
3.18.1. PostgreSQL
サンプルのPostgreSQLの linstor.toml は、次のようになります:
[db] user = "linstor" password = "linstor" connection_url = "jdbc:postgresql://localhost/linstor"
3.18.2. MariaDB
MariaDBのサンプル linstor.toml は以下のようになります:
[db] user = "linstor" password = "linstor" connection_url = "jdbc:mariadb://localhost/LINSTOR?createDatabaseIfNotExist=true"
注意: LINSTORのスキーマ/データベースは LINSTOR として作成されますので、MariaDBの接続文字列が上記の例のように LINSTOR スキーマを参照していることを確認してください。
|
3.18.3. etcd
etcdは、あなたのLINSTORデータベースを分散させるのが簡単になる分散型のキー値ストアです。etcdドライバーは、LINSTORコントローラーパッケージにすでに含まれており、linstor.toml で設定するだけです。
etcd のインストールおよび構成方法の詳細については、 etcd docs を参照ください。
以下は linstor.toml のサンプル [db] セクションです。
[db] ## only set user/password if you want to use authentication, only since LINSTOR 1.2.1 # user = "linstor" # password = "linstor" ## for etcd ## do not set user field if no authentication required connection_url = "etcd://etcdhost1:2379,etcdhost2:2379,etcdhost3:2379" ## if you want to use TLS, only since LINSTOR 1.2.1 # ca_certificate = "ca.pem" # client_certificate = "client.pem" ## if you want to use client TLS authentication too, only since LINSTOR 1.2.1 # client_key_pkcs8_pem = "client-key.pkcs8" ## set client_key_password if private key has a password # client_key_password = "mysecret"
3.19. 複数のLINSTORコントローラー
LINSTORコントローラーには、以下のパスに配置される必要がある設定ファイルがあります： /etc/linstor/linstor.toml。
The default configuration file is written with all available options (commented out) when the LINSTOR controller is first initialized.
3.19.1. LINSTOR REST API
LINSTORの管理タスクをよりアクセスしやすくし、Webフロントエンドでも利用できるようにするために、REST APIが作成されました。REST API はLINSTORコントローラーに組み込まれており、LINSTOR 0.9.13以降は linstor.toml 構成ファイルを通じて設定されています。
[http] enabled = true port = 3370 listen_addr = "127.0.0.1" # to disable remote access
REST APIを使用する場合は、最新のドキュメントを以下のリンクから参照できます：https://app.swaggerhub.com/apis-docs/Linstor/Linstor/
3.19.2. LINSTOR REST API HTTPS
HTTP REST APIはHTTPSによってもセキュリティが確保されるように実行することができ、認証が必要な機能を使用する場合には強くお勧めします。そのためには、すべてのHTTPSトラフィックを暗号化するために使用される有効な証明書を含むJavaキーストアファイルを作成する必要があります。
以下は Javaランタイムに含まれている keytool を使って自己署名証明書を作成する方法の簡単な例です。
keytool -keyalg rsa -keysize 2048 -genkey -keystore ./keystore_linstor.jks\ -alias linstor_controller\ -dname "CN=localhost, OU=SecureUnit, O=ExampleOrg, L=Vienna, ST=Austria, C=AT"
keytool は、生成されたキーストアファイルを保護するためのパスワードを要求します。これは LINSTOR Controller の設定に必要です。linstor.toml ファイルに、以下のセクションを追加する必要があります：
[https] keystore = "/path/to/keystore_linstor.jks" keystore_password = "linstor"
linstor-controller を（再）起動すると、HTTPS REST API がポート 3371 で利用可能になります。
他の証明書をインポートする方法の詳細については、こちらをご覧ください。 https://docs.oracle.com/javase/8/docs/technotes/tools/unix/keytool.html
HTTPSアクセスを有効にした後、HTTP v1 REST APIへのすべてのリクエストはHTTPSにリダイレクトされます。LINSTOR設定TOMLファイル（/etc/linstor/linstor.toml）でLINSTORコントローラーを指定していない場合は、LINSTORクライアントの使用 で説明されているように、LINSTORクライアント（linstor）を使用する際に異なる構文を使用する必要があります。
|
LINSTOR REST-API HTTPS 制限付きクライアントアクセス
コントローラー上で SSL/TLS 信頼ストアを使用することで、クライアントアクセスを制限することができます。基本的に、クライアント用の証明書を作成して信頼ストアに追加し、その証明書をクライアントが認証に使用するようにします。
最初にクライアント証明書を作成します。
keytool -keyalg rsa -keysize 2048 -genkey -keystore client.jks\ -storepass linstor -keypass linstor\ -alias client1\ -dname "CN=Client Cert, OU=client, O=Example, L=Vienna, ST=Austria, C=AT"
次に、この証明書をコントローラのトラストストアにインポートします。
keytool -importkeystore\ -srcstorepass linstor -deststorepass linstor -keypass linstor\ -srckeystore client.jks -destkeystore trustore_client.jks
そして linstor.toml 設定ファイルのトラストストアを有効にします。
[https] keystore = "/path/to/keystore_linstor.jks" keystore_password = "linstor" truststore = "/path/to/trustore_client.jks" truststore_password = "linstor"
ここで、Controllerを再起動してください。その後、正しい証明書がないとController APIにアクセスできなくなります。
LINSTORクライアントはPEM形式の証明書が必要ですので、使用する前に、Javaのキーストア証明書をPEM形式に変換する必要があります。
# Convert to pkcs12 keytool -importkeystore -srckeystore client.jks -destkeystore client.p12\ -storepass linstor -keypass linstor\ -srcalias client1 -srcstoretype jks -deststoretype pkcs12 # use openssl to convert to PEM openssl pkcs12 -in client.p12 -out client_with_pass.pem
PEMファイルのパスワードを入力する手間を省くためには、パスワードを削除すると便利かもしれません。
openssl rsa -in client_with_pass.pem -out client1.pem openssl x509 -in client_with_pass.pem >> client1.pem
これでこの PEMファイルをクライアントで使用できるようになります。
linstor --certfile client1.pem node list
--certfile パラメーターはクライアント構成ファイルにも追加できます。詳細については、 LINSTORクライアントの使用 を参照してください。
3.20. LINSTOR Satellite サービスの設定
LINSTOR Satelliteソフトウェアには、TOMLファイル形式を使用したオプションの設定ファイルがあり、次のパスに配置する必要があります：/etc/linstor/linstor_satellite.toml
最近の構成例は次のとおりです: linstor_satellite.toml-example
3.21. ロギング
LINSTORは、バインディングとして logback を使用してhttps://www.slf4j.org/[SLF4J]を利用しています。 これにより、LINSTORはログレベル ERROR, WARN, INFO, DEBUG, TRACE（詳細度の増加順）を区別することが可能となります。ログレベルを設定するさまざまな方法は、優先順に並べると以下の通りです（最初のものが最も優先度が高いです）:
-
. LINSTOR client バージョン1.20.1以降、
controller set-log-levelコマンドを使用して、 LINSTORの実行設定で使用されるログレベルを変更できます。このコマンドにはさまざまな引数を 使用できます。詳細については、コマンドの--helpテキストを参照してください。例えば、 LINSTORコントローラーとすべてのサテライトでログレベルをTRACEに設定するには、 次のコマンドを入力してください:$ linstor controller set-log-level --global TRACE
特定のノードでLINSTORのログレベルを変更するには、LINSTORクライアント（バージョン1.20.1以降）のコマンド
node set-log-levelを使用できます。LINSTORクライアントを使用して行ったログレベルの変更は、ノードの再起動など、LINSTORサービスの再起動後には保持されません。 -
TRACEモードは、デバッグコンソールを使用してenabledまたはdisabledにできます。Command ==> SetTrcMode MODE(enabled) SetTrcMode Set TRACE level logging mode New TRACE level logging mode: ENABLED
-
コントローラまたはサテライトを起動するときに、コマンドライン引数を渡すことができます。
java ... com.linbit.linstor.core.Controller ... --log-level TRACE java ... com.linbit.linstor.core.Satellite ... --log-level TRACE
-
推奨される場所は、設定ファイルの
loggingセクションです。デフォルトの設定ファイルの場所は、コントローラーが/etc/linstor/linstor.toml、サテライトが/etc/linstor/linstor_satellite.tomlです。ログレベルを以下のように設定します。[logging] level="TRACE"
-
LINSTORは実装としてlogbackを使用しているため、
/usr/share/linstor-server/lib/logback.xmlを使用することも可能です。現在、以下の例に示すように、コンポーネントごとに異なるログレベルをサポートしているのはこの方法のみです。<?xml version="1.0" encoding="UTF-8"?> <configuration scan="false" scanPeriod="60 seconds"> <!-- Values for scanPeriod can be specified in units of milliseconds, seconds, minutes or hours https://logback.qos.ch/manual/configuration.html --> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <!-- encoders are assigned the type ch.qos.logback.classic.encoder.PatternLayoutEncoder by default --> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</pattern> </encoder> </appender> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${log.directory}/linstor-${log.module}.log</file> <append>true</append> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <Pattern>%d{yyyy_MM_dd HH:mm:ss.SSS} [%thread] %-5level %logger - %msg%n</Pattern> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <FileNamePattern>logs/linstor-${log.module}.%i.log.zip</FileNamePattern> <MinIndex>1</MinIndex> <MaxIndex>10</MaxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <MaxFileSize>2MB</MaxFileSize> </triggeringPolicy> </appender> <logger name="LINSTOR/Controller" level="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 logback manual to find more details about logback.xml.
上記の設定方法のいずれも使用されない場合、LINSTOR はデフォルトで INFO ログレベルになります。
3.22. 監視
LINSTOR 1.8.0 以降、 Prometheus /metrics HTTP パス がLINSTOR および JVM 固有の方法で提供されています。
/metrics パスは LINSTOR のレポートデータ量を減らすために 3 つの GET 引数もサポートします。
-
リソース -
ストレージプール
-
エラーレポート
これらはすべてデフォルトで true です。無効にするには、例えばエラーレポートデータの場合、http://localhost:3370/metrics?error_reports=false を使用してください。
3.23. サテライトへの安全な接続
LINSTORを使用してコントローラーとサテライトの間にSSL/TLSセキュアTCP接続を確立することが可能です。JavaのSSL/TLSエンジンの動作の詳細については触れませんが、安全な接続を使用するために、Javaの実行環境に含まれる keytool を使用したコマンドラインのスニペットを以下に示します。3ノードのセットアップをセキュア接続で構成する方法をご紹介します。
ノードの設定は次のようになります。
ノード alpha はコントローラーです。ノード bravo とノード charlie はサテライトです。
以下にキーストア設定を生成するコマンド例を示します。環境に合わせて変更してください。
# create directories to hold the key files mkdir -p /tmp/linstor-ssl cd /tmp/linstor-ssl mkdir alpha bravo charlie # create private keys for all nodes keytool -keyalg rsa -keysize 2048 -genkey -keystore alpha/keystore.jks\ -storepass linstor -keypass linstor\ -alias alpha\ -dname "CN=Max Mustermann, OU=alpha, O=Example, L=Vienna, ST=Austria, C=AT" keytool -keyalg rsa -keysize 2048 -genkey -keystore bravo/keystore.jks\ -storepass linstor -keypass linstor\ -alias bravo\ -dname "CN=Max Mustermann, OU=bravo, O=Example, L=Vienna, ST=Austria, C=AT" keytool -keyalg rsa -keysize 2048 -genkey -keystore charlie/keystore.jks\ -storepass linstor -keypass linstor\ -alias charlie\ -dname "CN=Max Mustermann, OU=charlie, O=Example, L=Vienna, ST=Austria, C=AT" # import truststore certificates for alpha (needs all satellite certificates) keytool -importkeystore\ -srcstorepass linstor -deststorepass linstor -keypass linstor\ -srckeystore bravo/keystore.jks -destkeystore alpha/certificates.jks keytool -importkeystore\ -srcstorepass linstor -deststorepass linstor -keypass linstor\ -srckeystore charlie/keystore.jks -destkeystore alpha/certificates.jks # import controller certificate into satellite truststores keytool -importkeystore\ -srcstorepass linstor -deststorepass linstor -keypass linstor\ -srckeystore alpha/keystore.jks -destkeystore bravo/certificates.jks keytool -importkeystore\ -srcstorepass linstor -deststorepass linstor -keypass linstor\ -srckeystore alpha/keystore.jks -destkeystore charlie/certificates.jks # now copy the keystore files to their host destinations ssh root@alpha mkdir /etc/linstor/ssl scp alpha/* root@alpha:/etc/linstor/ssl/ ssh root@bravo mkdir /etc/linstor/ssl scp bravo/* root@bravo:/etc/linstor/ssl/ ssh root@charlie mkdir /etc/linstor/ssl scp charlie/* root@charlie:/etc/linstor/ssl/ # generate the satellite ssl config entry echo '[netcom] type="ssl" port=3367 server_certificate="ssl/keystore.jks" trusted_certificates="ssl/certificates.jks" key_password="linstor" keystore_password="linstor" truststore_password="linstor" ssl_protocol="TLSv1.2" ' | ssh root@bravo "cat > /etc/linstor/linstor_satellite.toml" echo '[netcom] type="ssl" port=3367 server_certificate="ssl/keystore.jks" trusted_certificates="ssl/certificates.jks" key_password="linstor" keystore_password="linstor" truststore_password="linstor" ssl_protocol="TLSv1.2" ' | ssh root@charlie "cat > /etc/linstor/linstor_satellite.toml"
それでは、コントローラーとサテライトを起動し、--communication-type SSL を指定してノードを追加します。
3.24. LDAP 認証の設定
LINSTORを設定して、LINSTORコントローラへのアクセスを制限するためにLDAP認証を使用することができます。 この機能はデフォルトで無効になっていますが、LINSTOR構成TOMLファイルを編集して有効にし、構成できます。 構成ファイルを編集した後は、linstor-controller.service を再起動する必要があります。 構成ファイル内のLDAPセクションの例は次のようになります:
[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 username
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 は真偽値です。デフォルトでは認証が無効になっています。 |
| 2 | allow_public_access は真偽値です。trueに設定されていてLDAP認証が有効になっている場合、ユーザーはLINSTOR Controllerの公開コンテキストで作業することができます。falseに設定されていてLDAP認証が有効になっている場合、LDAP認証情報を持たないユーザーはバージョンやヘルプ情報の表示など些細なタスク以外でLINSTOR Controllerにアクセスすることができません。 |
| 3 | dn は、LDAPディレクトリをクエリするためのLDAP識別名を指定することができる文字列値です。ユーザーID（uid）に加え、その文字列には他の識別名属性が含まれることがあります。例えば、
dn = "uid={user},ou=storage-services,o=ha,dc=example"
|
| 4 | search_base は、認証クエリのLDAPディレクトリツリーにおける開始ポイントを指定することができる文字列値です。例えば:
search_base = "ou=storage-services" |
| 5 | search_filter は、ユーザーおよびグループのメンバーシップなどの認証のためのLDAPオブジェクトの制限を指定できる文字列値です。 例えば、以下のようなものがあります:
search_filter = "(&(uid={user})(memberof=ou=storage-services,dc=example,dc=com))"
|
| LINSTOR ControllerとLDAPサーバーの間を通過する機密性の高いトラフィックを保護するため、LINSTOR REST API HTTPSとLDAPSを構成することを強く推奨します。 |
3.24.1. 認証ユーザとしてのLINSTORコマンドの実行
LINSTOR コントローラーを LDAP (または LDAPS) を介してユーザーを認証するように構成した後、LINSTOR REST API に HTTPS を設定すると、次のように LINSTOR コマンドを入力する必要があります。
$ linstor --user <LDAP_user_name> <command>
LDAP認証を設定した場合には、 LINSTOR REST API HTTPS も構成する必要があります。そうでない場合は、linstor コマンドで `–allow-insecure-path`フラグを使用してHTTP経由でパスワード認証を明示的に有効にする必要があります。これは、資格情報を平文で送信するため、安全で隔離されたLAN以外では推奨されません。
$ linstor --allow-insecure-auth --user <LDAP_user_name> <command>
上記の各例において、LINSTOR Controller はユーザーのパスワード入力を求めます。オプションとして --password 引数を使用し、コマンドラインでユーザーのパスワードを指定することも可能ですが、その方法に伴うすべての注意喚起に留意してください。
3.25. DRBDリソースの自動化
このセクションでは、LINSTORがDRBDリソースのために持つ自動化機能の詳細を説明しています。
3.25.1. 自動クォーラムポリシー
LINSTORは、リソースにクォーラムポリシーを自動的に構成します（クォーラムが利用可能な場合）。つまり、少なくとも2つのディスクフルと1つ以上のディスクレスリソースがある場合、または3つ以上のディスクフルリソースがある場合 、LINSTORはリソースのクォーラムポリシーを自動的に有効にします。
逆に、LINSTORは、クォーラムを使用するのに必要な最低限のリソース割り当てを満たさない場合は、クォーラムポリシーを自動的に無効にします。
これは、linstor-controller, resource-group, および resource-definition LINSTORオブジェクトに適用できる DrbdOptions/auto-quorum プロパティを介して制御されます。 DrbdOptions/auto-quorum プロパティの受け入れられる値は disabled, suspend-io, および io-error です。
DrbdOptions/auto-quorum プロパティを disabled に設定すると、リソースのクォーラムポリシーを手動で、必要に応じてより詳細に制御できます。
DrbdOptions/auto-quorum のデフォルトポリシーは、quorum majority および on-no-quorum io-error です。DRBDのクォーラム機能とその動作の詳細については、https://linbit.com/drbd-user-guide/drbd-guide-9_0-en/#s-feature-quorum[_DRBD ユーザーズガイド_のクォーラムセクション]を参照してください。
|
DrbdOptions/auto-quorum が無効化されていない場合、DrbdOptions/auto-quorum ポリシーは手動で設定されたプロパティを上書きします。
|
たとえば、リソースグループ名が my_ssd_group であるリソースグループのクォーラムポリシーを手動で設定する場合、以下のコマンドを使用します。
# linstor resource-group set-property my_ssd_group DrbdOptions/auto-quorum disabled # linstor resource-group set-property my_ssd_group DrbdOptions/Resource/quorum majority # linstor resource-group set-property my_ssd_group DrbdOptions/Resource/on-no-quorum suspend-io
DRBDのクォーラム機能を完全に無効化したい場合があります。そのためには、まず適切なLINSTORオブジェクトで DrbdOptions/auto-quorum を無効にし、その上でDRBDのクォーラム機能を適切に設定する必要があります。例えば、my_ssd_group リソースグループでクォーラムを完全に無効にするには、以下のコマンドを使用します。
# linstor resource-group set-property my_ssd_group DrbdOptions/auto-quorum disabled # linstor resource-group set-property my_ssd_group DrbdOptions/Resource/quorum off # linstor resource-group set-property my_ssd_group DrbdOptions/Resource/on-no-quorum
上記のコマンドで DrbdOptions/Resource/on-no-quorum を空の値に設定すると、そのプロパティはオブジェクトから完全に削除されます。
|
3.25.2. 自動取り除き
サテライトが長期間オフラインになっている場合、LINSTOR は、そのノードを Evictedと宣言するように構成できます。これにより、影響を受ける DRBD リソースが他のノードに自動的に再割り当てされ、最小のレプリカ数が維持されるようになります。
この機能は、次のプロパティを使用して動作を適応させます。
-
DrbdOptions/AutoEvictMinReplicaCountは、常に維持されるべきレプリカの数を設定します。このプロパティをコントローラーで設定してグローバルなデフォルト値を変更することも、特定のリソース定義またはリソースグループで設定して、そのリソース定義またはリソースグループに対してのみ変更を適用することも可能です。このプロパティが空のままの場合、対応するリソースグループの Autoplacer に設定されているプレイスカウントが使用されます。 -
DrbdOptions/AutoEvictAfterTimeは、エビクションがトリガーされるまでにノードがオフラインでいられる時間を分単位で指定します。このプロパティをコントローラーに設定してグローバルなデフォルト値を変更することも、特定のノードに設定して異なる動作をさせることも可能です。このプロパティのデフォルト値は60分です。 -
DrbdOptions/AutoEvictMaxDisconnectedNodesは、同時に（理由を問わず）到達不能になっても許容されるノードの割合（パーセント）を設定します。指定された割合以上のノードが同時にオフラインになった場合、LINSTORはコントローラー側からの接続の問題であると判断するため、どのノードに対しても自動エビクト（auto-evict）はトリガーされません。このプロパティはコントローラーに対してのみ設定可能で、0から100までの値を受け付けます。デフォルト値は34です。自動エビクト機能をオフにするには、このプロパティを0に設定してください。到達不能なサテライト（satellite）の数に関わらず常に自動エビクトをトリガーしたい場合は、100に設定します。 -
DrbdOptions/AutoEvictAllowEvictionは、ノードがエビクトされるのを防ぐことができる追加のプロパティです。これは、メンテナンスのためにノードをシャットダウンする必要がある場合など、さまざまなケースで役立ちます。このプロパティをコントローラーに設定してグローバルなデフォルト値を変更したり、個別のノードに設定して異なる動作をさせたりすることができます。値としてtrueとfalseを受け入れ、デフォルトではコントローラー上でtrueに設定されています。コントローラーでfalseに設定することで自動エビクト機能をオフにできますが、すでに個別のノードに異なる値を設定している場合、それらの値がグローバルなデフォルト値よりも優先されるため、完全には機能しない可能性があります。
LINSTORコントローラーがサテライトとの接続を失うと、再接続を試みるだけでなく、そのサテライトに対するタイマーを開始します。そのタイマーが DrbdOptions/AutoEvictAfterTime を超え、かつそのサテライト上のDRBDリソースへのすべてのDRBD接続が切断されると、コントローラーは DrbdOptions/AutoEvictMaxDisconnectedNodes に達しているかどうかを確認します。達していない場合、かつ該当するノードで DrbdOptions/AutoEvictAllowEviction がtrueであれば、そのサテライトはEVICTEDとマークされます。同時に、コントローラーはすべてのDRBDリソースについて、リソース数が依然として DrbdOptions/AutoEvictMinReplicaCount を上回っているかを確認します。上回っている場合、該当するリソースはDELETEDとマークされます。上回っていない場合は、対応するリソースグループの設定を使用してauto-placeが開始されます。auto-placeに失敗した場合、コントローラーは、新しいノードの追加など、異なる結果をもたらす可能性のある変更が発生した際に後ほど再試行します。auto-placeが必要なリソースについては、対応するauto-placeが成功した場合にのみDELETEDとマークされます。
追放（evicted）されたサテライト自体は、コントローラーとの接続を再確立することができません。ノードが稼働していても、手動での再接続は失敗します。また、サテライトが正常に動作していても、削除することはできません。しかし、サテライトは復旧させることができます。これにより、サテライトから EVICTED フラグが削除され、再び使用できるようになります。以前に設定されたネットワークインターフェース、ストレージプール、プロパティや同様のエンティティ、DRBDに関連しないリソース、および LINSTOR が他の場所に自動配置できなかったリソースは、引き続きサテライト上に残ります。サテライトを復旧するには、次のコマンドを使用します：
# linstor node restore [nodename]
そのノード自体を含め、かつてそのノード上に存在していたすべてのものを破棄したい場合は、代わりに node lost コマンドを使用する必要があります。
3.25.3. オートディスクフルと関連オプション
LINSTORオブジェクトのさまざまなLINSTORオブジェクト（たとえば、リソース定義など）に対して、LINSTORが自動的に「ディスク不足」ノードを「ディスクフル」にするのをサポートし、その後適切なクリーンアップ操作を実行するように、LINSTOR auto-diskful および auto-diskful-allow-cleanup プロパティを設定できます。
この機能は、Diskless ノードがDRBDリソースの Primary 状態に指定された分数よりも長く残っている場合に便利です。これは、LINSTORで管理されたストレージを他のオーケストレーションやスケジューリングプラットフォーム（OpenStack、OpenNebulaなど）と統合するケースで発生する可能性があります。LINSTORと統合する一部のプラットフォームでは、ストレージボリュームがクラスタ内のどこで使用されるかを影響する手段がないかもしれません。
auto-diskfulオプションは、統合プラットフォームの操作に対して、あなたのコントロールを超えたアクションに対応するために、ストレージノードの役割を賢く委任する方法を提供します。
自動ディスク上書きオプションの設定
DrbdOptions/auto-diskful オプションをLINSTORリソース定義に設定することで、リソースが指定された分数よりも長い間DRBDの Primary 状態にある場合、LINSTORコントローラは Diskless DRBDリソースを Diskful にするように構成されます。指定された分数が経過すると、LINSTORは指定されたリソースに対して Diskless ノードでリソースの状態を切り替えるために resource toggle-disk コマンド を自動的に使用します。
このプロパティを設定するには、例えば、5分の閾値を持つ myres というLINSTORリソース定義に対して、次のコマンドを入力してください。
# linstor resource-definition set-property myres DrbdOptions/auto-diskful 5
リソースグループまたはコントローラにおけるAuto-Diskfulオプションの設定
DrbdOptions/auto-diskful オプションをLINSTORの controller または resource-group オブジェクトにも設定できます。コントローラーレベルでオプションを設定すると、そのオプションは、このオプションが設定されていないLINSTORクラスター内のすべてのLINSTORリソース定義に影響します。リソース定義自体またはリソースグループでこのオプションを設定していない場合、またはリソースを作成したリソースグループで設定しない場合です。
LINSTORリソースグループにオプションを設定すると、グループから生成されるすべてのリソース定義に影響が及びますが、リソース定義にそのオプションが設定されている場合は影響がありません。
auto-diskful オプションを設定する効果の優先順位は、最も高いものから最も低いものまで次の通りです。
-
リソース定義
-
リソースグループ
-
コントローラー
自動ディスク割り当てオプションの解除
LINSTORの auto-diskful オプションを無効にするには、次を入力してください:
# linstor <controller|resource-definition|resource-group> set-property DrbdOptions/auto-diskful
auto-diskful-allow-cleanupオプションの設定
LINSTORの auto-diskful オプションの補助オプションとして、 DrbdOptions/auto-diskful-allow-cleanup オプションがあります。
このオプションは、次のLINSTORオブジェクトに設定できます：ノード、リソース、リソース定義、またはリソースグループ。このオプションのデフォルト値は True ですが、auto-diskful オプションが設定されていない限り、このオプションは効果がありません。
LINSTORがリソースをディスクフル(state= Diskful )に切り替えた後、リソースの プライマリ ロールにディスクレスノードが一定時間以上割り当てられた場合、そしてそれが DRBD によって以前の ディスクレス ノード（現在は プライマリ ノード）にデータが同期された後、リソースが任意の セカンダリ ノードから削除される瞬間、リソースが持つレプリカ数の制約を満たすためにそのアクションが必要になった際に、LINSTORはそのリソースを削除します。このようなケースが発生する可能性があり、たとえば、--auto-place オプションを使用してリソースに対してレプリカ数を指定した場合です。
3.25.4. SkipDisk
デバイスがI/Oエラーを発生させている場合、例えば物理的な障害が原因の場合、DRBDはこの状態を検出し、自動的にローカルディスクから切り離します。すべての読み込みおよび書き込みリクエストは、依然として健全なpeerに転送され、アプリケーションが中断することなく継続できます。
この自動切り離しは、drbdsetup events2ストリームに新しいイベントエントリを引き起こし、DRBDボリュームの状態を ‘UpToDate’ から Failed 最終的に Diskless に変更します。 LINSTORはこれらの状態変更を検出し、指定されたリソースに DrbdOptions/SkipDisk プロパティを自動的に True に設定します。 このプロパティにより、I/Oエラーを発生させるデバイスを持つノード上で実行されているLINSTORサテライトサービスが、すべての drbdadm adjust コマンドに --skip-disk をアタッチするようになります。
もし、このプロパティが設定されている場合、 linstor resource list コマンドもそれに応じて表示されます。
# linstor r l ╭──────────────────────────────────────────────────────────────────────────────────────────────╮ ┊ ResourceName ┊ Node ┊ Port ┊ Usage ┊ Conns ┊ State ┊ CreatedOn ┊ ╞══════════════════════════════════════════════════════════════════════════════════════════════╡ ┊ rsc ┊ bravo ┊ 7000 ┊ Unused ┊ Ok ┊ UpToDate, Skip-Disk (R) ┊ 2024-03-18 11:48:08 ┊ ╰──────────────────────────────────────────────────────────────────────────────────────────────╯
この場合、(R) はすでにプロパティがリソースに設定されていることを示しています。プロパティ DrbdOptions/SkipDisk がリソースレベルとノードレベルの両方に設定された場合、インジケーターは (R, N) に変わります。
このプロパティはLINSTORによって自動的に有効になっていますが、I/Oエラーの原因を解決した後、健全な UpToDate 状態に戻るためにプロパティを手動で削除する必要があります。
# linstor resource set-property bravo rsc DrbdOptions/SkipDisk
3.26. 外部 DRBD メタデータの使用
デフォルトでは、LINSTOR は DRBD リソースを作成する際に 内部の DRBD メタデータ を使用します。 もし 外部の DRBD メタデータ を使用したい場合は、クラスタ内の LINSTOR ストレージプールの名前を StorPoolNameDrbdMeta プロパティに設定することで可能です。
StorPoolNameDrbdMeta プロパティを、以下の LINSTOR オブジェクトに設定できます。優先度の増加順にリストされています。
-
ノード -
リソースグループ
-
リソース定義
-
リソース -
ボリュームグループ -
ボリューム定義
たとえば、ノードレベルでプロパティを設定すると、優先順位の高いすべてのLINSTORオブジェクトに適用されます。ただし、プロパティがより高い優先順位のLINSTORオブジェクトにも設定されている場合、適用可能なDRBDリソースに対して最も優先度の高いLINSTORオブジェクトに設定されたプロパティ値が優先されます。
LINSTORを使用して新しいDRBDリソースを作成する際に、StorPoolNameDrbdMeta プロパティがDRBDリソースに適用される場合、プロパティを設定するLINSTORオブジェクトに基づいて、LINSTORはストレージプール内に2つの新しい論理ボリュームを作成します。1つはリソースデータのストレージ用であり、2つ目はリソースのDRBDメタデータを格納するためのものです。
StorPoolNameDrbdMeta プロパティを設定、変更、または削除しても、既存の LINSTOR で管理されている DRBD リソースに影響はありません。
3.26.1. 外部 DRBD メタデータ LINSTOR プロパティの設定
ノードレベルでプロパティを設定するには、例えば、以下のコマンドを入力してください:
# linstor node set-property <node-name> StorPoolNameDrbdMeta <storage-pool-name>
3.26.2. 外部 DRBD メタデータ LINSTOR プロパティの一覧化
指定されたLINSTORオブジェクトにプロパティが設定されているかを確認するには、 list-properties サブコマンドを使用できます。
# linstor node list-properties node-0
コマンドの出力には、指定されたLINSTORオブジェクトのセットプロパティとその値のテーブルが表示されます。
╭─────────────────────────────────────╮ ┊ Key ┊ Value ┊ ╞═════════════════════════════════════╡ [...] ┊ StorPoolNameDrbdMeta ┊ my_thin_pool ┊ ╰─────────────────────────────────────╯
3.27. QoS設定
LINSTORは、ブロックI/O操作に関連するカーネル変数に対応するsysfsプロパティを使用して、管理されたリソースのためのQoSを実装します。これらのsysfsプロパティは、帯域幅（1秒あたりのバイト数）、またはIOPS、またはその両方の制限になりえます。
sysfsファイルとそれに対応するLINSTORのプロパティは以下の通りです。
sysfs (/sys/fs/) |
LINSTOR Property |
|---|---|
|
|
|
|
|
|
|
|
3.27.1. 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” オブジェクトにはプロパティが表示されません。 |
3.27.2. 複数の DRBD デバイスを持つ LINSTOR ボリュームの QoS 設定
単一の LINSTOR ボリュームは、複数の DRBD デバイスで構成できます。たとえば、外部メタデータを含む DRBD には、データ (ストレージ) デバイス、メタデータ デバイス、および LINSTOR に提供される複合 DRBD デバイス (ボリューム) の 3 つの下位デバイスがあります。データデバイスとメタデータデバイスが異なる下位ディスクに対応している場合、そのような LINSTOR ボリュームに sysfs プロパティを設定すると、ローカルデータ (ストレージ) 下位デバイスのみが対応する /sys/fs/cgroup/blkio/ ファイルのプロパティ値を受け取ります。DRBD メタデータの下位デバイスや、LINSTOR で提供される複合下位デバイスは値を受け取りません。ただし、DRBD のデータとそのメタデータが同じ下位ディスクを共有する場合、QoS 設定はデータとメタデータ操作の両方のパフォーマンスに影響します。
3.27.3. NVMe の QoS設定
LINSTORのリソース定義に nvme-target と nvme-initiator リソースがある場合、各ノードの両方のデータ（ストレージ）バッキングデバイスは、sysfsプロパティの値を受け取ります。ターゲットの場合、データバッキングデバイスは、LVMまたはZFSのいずれかのボリュームになります。一方、イニシエータの場合、データバッキングデバイスは、接続されている nvme-device になります。その際、LUKS、NVMe、DRBDなど、その上にある他のLINSTORレイヤーがあっても関係ありません（詳細は DRBDを使わないLINSTOR を参照）。
3.28. ヘルプの利用
3.28.1. コマンドラインから確認
コマンドラインで利用可能なコマンドを簡単にリストアップする方法は、linstor と入力することです。
サブコマンドに関する追加情報（例：ノードの一覧表示）は、2つの方法で取得できます:
# linstor node list -h # linstor help node list
LINSTOR がインタラクティブモード（ linstor interactive ）で動作しているときには ‘help’ サブコマンドはとても役にたちます。
LINSTORの最も有用な機能の一つは、豊富なタブ補完機能です。これを使って、LINSTORが知っているほぼすべてのオブジェクトの補完が可能です。たとえば、ノード名、IPアドレス、リソース名などが挙げられます。以下の例では、いくつかの補完の可能性とその結果が示されています:
# linstor node create alpha 1<tab> # ホスト名が解決できるとIPアドレスを補完します # linstor resource create b<tab> c<tab> # linstorは backups, charlieリソースを補完します
LINSTOR クライアントをインストールしてもタブ補完が機能しない場合は、適切なファイルをソースに指定してみてください:
# source /etc/bash_completion.d/linstor # または # source /usr/share/bash_completion/completions/linstor
Zシェルユーザー向けに、linstor-client コマンドはZシェルコンパイルファイルを生成できます。このファイルには、コマンドや引数の補完に基本的なサポートが備わっています。
# linstor gen-zsh-completer > /usr/share/zsh/functions/Completion/Linux/_linstor
3.28.2. SOSレポートの作成
何か問題が発生して原因を特定する必要がある場合は、次のコマンドを入力してください:
# linstor sos-report create
上記のコマンドは、コントローラーノードの /var/log/linstor/controller ディレクトリに新しい sos-report を作成します。別の方法として、以下のコマンドを入力することもできます:
# linstor sos-report download
このコマンドを実行すると、新しいSOSレポートが作成され、そのレポートがあなたのローカルマシンのカレントディレクトリにダウンロードされます。
このSOSレポートには、複数の情報源（LINSTORログ、dmesg 、LINSTORで使用される外部ツールのバージョン、ip a 、データベースのダンプなど）からのログと有用なデバッグ情報が含まれています。これらの情報は、各ノードごとにプレーンテキスト形式で .tar.gz ファイルに保存されます。
3.28.3. コミュニティの助けを借りる
For help from the community of LINBIT software users, visit the LINBIT community forum: https://forums.linbit.com
3.28.5. 有料のサポートと開発
必要に応じてリモートインストールサービス、24時間365日のサポート、認定リポジトリへのアクセス、または機能開発を購入したい場合は、お問い合わせください。お問い合わせ先: +1-877-454-6248 (1-877-4LINBIT)、国際番号: +43-1-8178292-0、メール: [email protected]
LINSTOR管理のためのLINBIT GUIの使用
4. LINBIT GUI
LINBIT GUI は、LINSTOR® CLI クライアントに代わるオープンソースのグラフィカルな選択肢です。LINBIT GUI を使用することで、Web ブラウザからアクセス可能な便利なグラフィカル管理コンソールを通じて、LINSTOR クラスターを管理できます。
4.1. 前提条件
LINBIT GUIをインストールして使用するには、以下が必要になります。
-
LINBITの顧客用またはパブリックリポジトリへのアクセスが必要です。さもなければ、プロジェクトの オープンソースのコードベース を使用して、LINBIT GUIをソースからビルドする必要があります。
-
LINSTOR コントローラーインスタンスの実行と動作環境
4.2. LINSTOR GUI のインストール
クラスター内のLINSTORコントローラーノードに linstor-gui パッケージをインストールし、 linstor-controller サービスを再起動してください。クラスター内でLINSTORコントローラーサービスを高可用化している場合は、そのサービスを実行する可能性がある他のノードにも linstor-gui パッケージをインストールしてください。
RPMベースのディストリビューションにLINBIT GUIをインストールするには、次のコマンドを入力します：
dnf install -y linstor-guiDEBベースのディストリビューションにLINBIT GUIをインストールするには、次のコマンドを入力します：
apt install -y linstor-guiKubernetesデプロイメントにおけるLINSTORでは、linstor-controller v1.15.0からLINBIT GUIが標準機能として組み込まれています。
LINSTOR統合
5. Kubernetes で LINSTOR ボリューム
この章では、オペレータによって管理され、 LINSTOR CSIプラグインを使用してプロビジョニングされた ボリュームを使用する方法について、Kubernetes(K8s)でLINSTOR®の使用方法について説明します。
この章では、LINSTORとKubernetesを使用したすべてのインストールオプションや可能な構成について詳細に説明しています。この章は説明的なコメントから始まり、その後展開手順に移ります。その後、Kubernetes展開内でストレージを構成するためにLINSTORを始める手順が示されています。その後、スナップショットやモニタリングなどのより高度なトピックや構成について説明されています。
5.1. Kubernetesの概要
Kubernetes は、コンテナオーケストレーターです。Kubernetes は、宣言した仕様に基づいてコンテナと関連サービスの動作を定義します。このガイドでは、Kubernetes オブジェクトの仕様を定義する AML ファイルを介して kubectl を使用することに焦点を当てます。
5.2. Kubernetes への LINSTOR のデプロイ
LINBITは、商用サポートの顧客向けにLINSTOR Operatorを提供しています。このOperatorは、DRBDをインストールし、サテライトおよびコントローラーポッドを管理し、その他関連する機能を提供することで、Kubernetes上でのLINSTORの展開を容易にします。
| LINBITのコンテナイメージリポジトリ（https://drbd.io）、LINSTOR Operatorによって使用されていますが、LINBITの顧客またはLINBIT顧客トライアルアカウントを通じてのみ利用可能です。[価格情報の取得やトライアルの開始については、LINBITにお問い合わせください。https://linbit.com/contact-us/]また、LINBITの顧客でなくても、LINSTOR SDSのアップストリームプロジェクトである[Piraeus]（https://github.com/piraeusdatastore/piraeus-operator）を使用することもできます。 |
LINSTOR Operator v2は、新しいクラスタにLINBIT SDSをKubernetesに展開する推奨方法です。 既存のOperator v1の展開を使用しているユーザーは、引き続きHelmの展開を使用し、 Operator v1の展開手順 にスキップしてください。
5.3. LINSTOR Operator v2 のデプロイメント
LINSTOR Operator v2を展開する際は、Kustomizeツールを使用し、kubectl と統合するか、あるいはHelmとLINBITのHelmチャートを使用することができます。
| もしすでにあなたのクラスターにLINSTOR Operator v1がデプロイされている場合、KubernetesでLINBIT SDSデプロイメントをOperator v2にアップグレードすることができます。詳細な手順は、charts.linstor.ioで確認できます。 |
5.3.1. Kustomizeを使用してオペレーターv2を作成する
オペレータを展開するには、kustomization.yaml ファイルを作成してください。これにより、drbd.io のプルシークレットを宣言し、オペレータの展開を許可します。オペレータは新しい名前空間 linbit-sds に展開されます。 MY_LINBIT_USER と MY_LINBIT_PASSWORD をご自身の認証情報に置き換えてください。最新リリースはcharts.linstor.ioで確認できます。
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: linbit-sds
resources:
- https://charts.linstor.io/static/v2.10.0.yaml (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"}}} (2)| 1 | リンクから最新のリリースマニフェストに置き換えてください: charts.linstor.io |
| 2 | MY_LINBIT_USER と MY_LINBIT_PASSWORD を、あなたの my.linbit.com の認証情報で置き換えてください。 |
次に、kubectl コマンドを使用して kustomization.yaml ファイルを適用し、オペレーターの開始を待ちます:
$ 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
オペレーターはLINBIT SDS for Kubernetes を展開する準備が整いました。
5.3.2. コマンドラインツールを使用して、LINBIT SDS for Kubernetes をデプロイ
KubernetesでのLINBIT SDSのオペレーターv2をデプロイするのは、新しい`LinstorCluster` リソースを作成して、オペレーターがセットアップを完了するのを待つだけで簡単です:
$ 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
出力には、待機条件が満たされ、LINBIT SDSポッドが起動して実行されていることが最終的に表示されるはずです。
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
5.3.3. Helmを使用してオペレーターv2を作成する
Helmを使用してLINSTOR Operator v2を作成するには、まず次のコマンドを入力して`linstor` Helmチャートリポジトリを追加してください:
$ MY_LINBIT_USER=<my-linbit-customer-username> $ MY_LINBIT_PASSWORD=<my-linbit-customer-password> $ helm repo add linstor https://charts.linstor.io
次に、次のコマンドを入力して、LINSTOR Operator v2をインストールしてください:
$ helm install linstor-operator linstor/linstor-operator \ --namespace linbit-sds \ --create-namespace \ --set imageCredentials.username=$MY_LINBIT_USER \ --set imageCredentials.password=$MY_LINBIT_PASSWORD \ --wait
5.3.4. Helmを使用してLINBIT SDS for Kubernetesをデプロイする
コマンドの出力により、Operator v2 がインストールされたことが確認できたら、Helm を使用して linbit-sds チャートをインストールして LINBIT SDS をデプロイできます:
$ helm install -n linbit-sds linbit-sds linstor/linbit-sds
この最終的な helm install コマンドの出力には、成功メッセージが表示されるべきです。
[...] LinstorCluster: linbit-sds Successfully deployed! [...]
5.3.5. オペレーターv2を使用したストレージの設定
デフォルトでは、LINBIT SDS for Kubernetesはストレージを構成しません。ストレージを追加するには、Operatorが1つ以上のサテライトを構成するために使用する「LinstorSatelliteConfiguration」を構成できます。
次の例は、シンプルな FILE_THIN プールを作成し、ホストへの追加設定は不要です:
$ 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
他の種類のストレージプールも設定することができます。詳細は、以下のリンクを参照してください。upstreamの例。
5.3.6. オペレーターv2デプロイメントのセキュリティ化
キーと証明書に基づく暗号化を設定することで、例えば、LINSTORのサテライトノードとLINSTORコントローラーノード、またはLINSTORクライアントとLINSTOR API間など、特定のLINSTORコンポーネント間の通信をより安全にすることができます。
LINSTORコントローラーとサテライト間のTLSの設定
サテライトノードとLINSTORコントローラー間のトラフィックをセキュアにするためには、cert-managerまたはOpenSSLを使用してTLSを構成して、トラフィックを暗号化するTLS証明書を作成することができます。
cert-manager を使用してキーと証明書をプロビジョニングする
この方法を使用するには、クラスター内で機能するcert-managerのデプロイメントが必要です。キーと証明書をプロビジョニングする別の方法については、以下の OpenSSL セクションを参照してください。
LINSTORコントローラーとサテライトはお互いを信頼する必要があります。そのため、これらのコンポーネントには証明書機関（CA）だけが必要です。新しいcert-managerリンクを作成するために、デプロイメントに以下のYAML構成を適用してください：Issuerリソース:
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: ca-bootstrapper
namespace: linbit-sds
spec:
selfSigned: { }
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: linstor-internal-ca
namespace: linbit-sds
spec:
commonName: linstor-internal-ca
secretName: linstor-internal-ca
duration: 87600h # 10 years
isCA: true
usages:
- signing
- key encipherment
- cert sign
issuerRef:
name: ca-bootstrapper
kind: Issuer
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: linstor-internal-ca
namespace: linbit-sds
spec:
ca:
secretName: linstor-internal-ca次に、新しい発行者リソースを構成し、LINSTORオペレーターがコントローラーおよびサテライトのトラフィックを暗号化するために必要な証明書を提供できるように、次のYAML構成を適用してください:
---
apiVersion: piraeus.io/v1
kind: LinstorCluster
metadata:
name: linstorcluster
spec:
internalTLS:
certManager:
name: linstor-internal-ca
kind: Issuer
---
apiVersion: piraeus.io/v1
kind: LinstorSatelliteConfiguration
metadata:
name: internal-tls
spec:
internalTLS:
certManager:
name: linstor-internal-ca
kind: Issuerデプロイメントに上記の設定を適用した後、 TLSトラフィックの暗号化が機能している ことを確認できます。
OpenSSLを使用してキーと証明書をプロビジョニング
もしあなたが上記の Provisioning Keys and Certificates By Using cert-manager セクションを完了した場合、このセクションをスキップして Verifying TLS Configuration セクションに進むことができます。
この方法はコマンドライン上で openssl プログラムを必要とします。
最初に、新しいキーと自己署名証明書を使用して新しいCAを作成します。暗号化アルゴリズムや有効期限などのオプションを、デプロイメントの要件に合わせて変更することができます。
# openssl req -new -newkey rsa:4096 -days 3650 -nodes -x509 \ -subj "/CN=linstor-internal-ca" \ -keyout ca.key -out ca.crt
次に、新しいキーを2つ作成してください。1つはLINSTORコントローラ用、もう1つはすべてのサテライト用です:
# openssl genrsa -out controller.key 4096 # openssl genrsa -out satellite.key 4096
次に、前に作成したCAによって署名され、有効期限が10年の各キーのための証明書を作成してください:
# openssl req -new -sha256 -key controller.key -subj "/CN=linstor-controller" -out controller.csr # openssl req -new -sha256 -key satellite.key -subj "/CN=linstor-satellite" -out satellite.csr # openssl x509 -req -in controller.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -out controller.crt -days 3650 -sha256 # openssl x509 -req -in satellite.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -out satellite.crt -days 3650 -sha256
次に、作成したキーと証明書からKubernetesのシークレットを作成してください:
# kubectl create secret generic linstor-controller-internal-tls -n linbit-sds \ --type=kubernetes.io/tls --from-file=ca.crt=ca.crt --from-file=tls.crt=controller.crt \ --from-file=tls.key=controller.key # kubectl create secret generic linstor-satellite-internal-tls -n linbit-sds \ --type=kubernetes.io/tls --from-file=ca.crt=ca.crt --from-file=tls.crt=satellite.crt \ --from-file=tls.key=satellite.key
最後に、Operatorリソースを新たに作成されたシークレットを参照するように設定し、次のYAML構成をデプロイメントに適用してください:
---
apiVersion: piraeus.io/v1
kind: LinstorCluster
metadata:
name: linstorcluster
spec:
internalTLS:
secretName: linstor-controller-internal-tls
---
apiVersion: piraeus.io/v1
kind: LinstorSatelliteConfiguration
metadata:
name: internal-tls
spec:
internalTLS:
secretName: linstor-satellite-internal-tlsTLS設定の検証
LINSTORコントローラと サテライト トラフィックの暗号化を構成した後、kubectl linstor node list コマンドの出力を調べることで、LINSTORコントローラとサテライト間の安全なTLS接続を確認できます。TLSが有効になっている場合、出力にはアクティブなサテライトアドレスの横に (SSL) が表示されます。
# kubectl linstor node list ╭─────────────────────────────────────────────────────────────────────╮ ┊ Node ┊ NodeType ┊ Addresses ┊ State ┊ ╞═════════════════════════════════════════════════════════════════════╡ ┊ node01.example.com ┊ SATELLITE ┊ 10.116.72.142:3367 (SSL) ┊ Online ┊ ┊ node02.example.com ┊ SATELLITE ┊ 10.127.183.140:3367 (SSL) ┊ Online ┊ ┊ node03.example.com ┊ SATELLITE ┊ 10.125.97.50:3367 (SSL) ┊ Online ┊ ╰─────────────────────────────────────────────────────────────────────╯
| 上記のコマンドは、KubernetesでのLINSTORクライアントコマンドの入力を簡略化するために、`kubectl-linstor`コマンドを使用します。このツールは、LINSTORクライアントコマンド入力の簡略化に記載されている手順に従ってインストールできます。 |
出力に (SSL) ではなく (PLAIN) と表示されている場合、TLS設定が正常に適用されなかったことを示しています。LinstorCluster および LinstorSatellite リソースのステータスを確認してください。
出力に (SSL) と表示されているにもかかわらず、ノードがオフラインのままの場合、これは通常、証明書が相手側から信頼されていないことを示しています。コントローラーの tls.crt がサテライトの ca.crt によって信頼されているか、またその逆も同様に確認してください。以下のシェル関数は、あるTLS証明書が別の証明書によって信頼されているかどうかを素早く確認する方法を提供します：
function k8s_secret_trusted_by() {
kubectl get secret -n linbit-sds \
-ogo-template='{{ index .data "tls.crt" | base64decode }}' \
"$1" > $1.tls.crt
kubectl get secret -n linbit-sds \
-ogo-template='{{ index .data "ca.crt" | base64decode }}' \
"$2" > $2.ca.crt
openssl verify -CAfile $2.ca.crt $1.tls.crt
}
# k8s_secret_trusted_by satellite-tls controller-tls
TLS暗号化が適切に設定されていれば、上記の関数を実行した際の出力は以下のようになります。
satellite-tls.tls.crt: OK
Reference documentation from the upstream Piraeus project shows all available LinstorCluster and LinstorSatelliteConfiguration resources options related to TLS.
LINSTOR APIのTLSの設定
このセクションでは、LINSTOR APIに対してTLSをセットアップする方法について説明します。LINSTOR controllerによって提供されるこのAPIは、CSI DriverやOperator自体などのクライアントがLINSTORクラスターを制御するために使用されます。
このセクションの手順に従うには、以下の内容を理解している必要があります。
-
LinstorClusterリソースの編集 -
cert-managerまたはOpenSSLのいずれかを使用してTLS証明書を作成する
cert-manager を使用してキーと証明書をプロビジョニングする
この方法では、クラスター内で動作する cert-manager デプロイメントが必要です。鍵と証明書をプロビジョニングする別の方法については、以下の OpenSSL セクションを参照してください。
TLSを使用する場合、LINSTOR APIは認証にクライアント証明書を使用します。これらの証明書専用に独立したCAを用意することが推奨されます。これを行うには、まず以下のYAML設定をデプロイメントに適用して、証明書発行者を作成します。
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: ca-bootstrapper
namespace: linbit-sds
spec:
selfSigned: { }
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: linstor-api-ca
namespace: linbit-sds
spec:
commonName: linstor-api-ca
secretName: linstor-api-ca
duration: 87600h # 10 years
isCA: true
usages:
- signing
- key encipherment
- cert sign
issuerRef:
name: ca-bootstrapper
kind: Issuer
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: linstor-api-ca
namespace: linbit-sds
spec:
ca:
secretName: linstor-api-ca
次に、この発行者を設定して、オペレーターが必要な証明書を提供できるようにし、次の設定を適用してください。
---
apiVersion: piraeus.io/v1
kind: LinstorCluster
metadata:
name: linstorcluster
spec:
apiTLS:
certManager:
name: linstor-api-ca
kind: Issuer
これで、cert-manager を使用して LINSTOR API を TLS で保護するために必要な手順は完了です。TLS が動作していることを確認するには、LINSTOR API の TLS 設定の検証 セクションに進んでください。
OpenSSLを使用してキーと証明書をプロビジョニング
この方法では、コマンドラインに openssl プログラムが必要です。鍵と証明書をプロビジョニングする別の方法については、上記の cert-manager セクションを参照してください。
まず、新しい鍵と自己署名証明書を使用して、新しい認証局（CA）を作成します。デプロイの要件に合わせて、暗号化アルゴリズムや有効期限などのオプションを変更できます。
# openssl req -new -newkey rsa:4096 -days 3650 -nodes -x509 \ -subj "/CN=linstor-api-ca" \ -keyout ca.key -out ca.crt
次に、LINSTOR APIサーバー用と、すべてのLINSTOR APIクライアント用の2つの新しいキーを作成します。
# openssl genrsa -out api-server.key 4096 # openssl genrsa -out api-client.key 4096
次に、サーバーのための証明書を作成します。クライアントが異なる短縮されたサービス名を使用する可能性があるため、複数のサブジェクト名を指定する必要があります。
# cat /etc/ssl/openssl.cnf > api-csr.cnf # cat >> api-csr.cnf <<EOF [ v3_req ] subjectAltName = @alt_names [ alt_names ] DNS.0 = linstor-controller.linbit-sds.svc.cluster.local DNS.1 = linstor-controller.linbit-sds.svc DNS.2 = linstor-controller EOF # openssl req -new -sha256 -key api-server.key \ -subj "/CN=linstor-controller" -config api-csr.cnf \ -extensions v3_req -out api-server.csr # openssl x509 -req -in api-server.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -config api-csr.cnf \ -extensions v3_req -out api-server.crt \ -days 3650 -sha256
クライアント証明書について、1つのサブジェクト名を設定するだけで十分です。
# openssl req -new -sha256 -key api-client.key \ -subj "/CN=linstor-client" -out api-client.csr # openssl x509 -req -in api-client.csr \ -CA ca.crt -CAkey ca.key -CAcreateserial \ -out api-client.crt \ -days 3650 -sha256
次に、作成したキーと証明書からKubernetesのシークレットを作成してください:
# kubectl create secret generic linstor-api-tls -n linbit-sds \ --type=kubernetes.io/tls --from-file=ca.crt=ca.crt --from-file=tls.crt=api-server.crt \ --from-file=tls.key=api-server.key # kubectl create secret generic linstor-client-tls -n linbit-sds \ --type=kubernetes.io/tls --from-file=ca.crt=ca.crt --from-file=tls.crt=api-client.crt \ --from-file=tls.key=api-client.key
最後に、オペレータのリソースを新しく作成したシークレットを参照するように設定してください。シンプルにするため、すべてのコンポーネントに同じクライアントシークレットを設定することができます。
apiVersion: piraeus.io/v1
kind: LinstorCluster
metadata:
name: linstorcluster
spec:
apiTLS:
apiSecretName: linstor-api-tls
clientSecretName: linstor-client-tls
csiControllerSecretName: linstor-client-tls
csiNodeSecretName: linstor-client-tls
LINSTOR APIのTLS設定の検証
`curl`コマンドを使用してHTTPSエンドポイントに手動で接続することで、APIがTLSで保護され、正常に動作していることを確認できます。
# kubectl exec -n linbit-sds deploy/linstor-controller -- \ curl --key /etc/linstor/client/tls.key \ --cert /etc/linstor/client/tls.crt \ --cacert /etc/linstor/client/ca.crt \ https://linstor-controller.linbit-sds.svc:3371/v1/controller/version
コマンドが成功した場合、APIはHTTPSを使用しており、クライアントは自分の証明書を使用してコントローラに接続できるようになっています。コマンドの出力は、次のような内容が表示されるはずです:
{"version":"1.20.2","git_hash":"58a983a5c2f49eb8d22c89b277272e6c4299457a","build_time":"2022-12-14T14:21:28+00:00","rest_api_version":"1.16.0"}%
コマンドの出力にエラーが表示された場合、クライアント証明書がAPIシークレットに信頼されているか、その逆も確認してください。次のシェル関数は、1つのTLS証明書が別のTLS証明書に信頼されているかを簡単に確認する方法を提供します。
function k8s_secret_trusted_by() {
kubectl get secret -n linbit-sds \
-ogo-template='{{ index .data "tls.crt" | base64decode }}' \
"$1" > $1.tls.crt
kubectl get secret -n linbit-sds \
-ogo-template='{{ index .data "ca.crt" | base64decode }}' \
"$2" > $2.ca.crt
openssl verify -CAfile $2.ca.crt $1.tls.crt
}
# k8s_secret_trusted_by satellite-tls controller-tls
TLS暗号化が適切に設定されていれば、上記の関数を実行した際の出力は以下のようになります。
satellite-tls.tls.crt: OK
別の問題は、予期していないサービス名を使用している証明書を使用しているAPIエンドポイントかもしれません。この問題に対する典型的なエラーメッセージは、次のようになります：
curl: (60) SSL: no alternative certificate subject name matches target host name 'linstor-controller.piraeus-datastore.svc'
この場合、証明書をプロビジョニングする際に、正しいサブジェクト名を指定していることを確認してください。
この場合、証明書をプロビジョニングする際に正しいサブジェクト名を指定しているか確認してください。利用可能なすべてのオプションは、アップストリームのPiraeusプロジェクトによる LinstorCluster のリファレンスドキュメント（LinstorCluster）に記載されています。
LINSTORのパスフレーズ作成
LINSTORは、ボリュームの暗号化やバックアップ用のアクセス資格情報の保存といった操作にパスフレーズを使用できます。
KubernetesデプロイメントでLINSTORのパスフレーズを構成するには、参照されるシークレットがオペレーター（デフォルトでは`linbit-sds`）と同じネームスペースに存在し、MASTER_PASSPHRASE エントリを持っている必要があります。
以下のYAML設定例では、.spec.linstorPassphraseSecret 用にパスフレーズ example-passphrase を設定します。
| デプロイには別のパスフレーズを選択してください。 |
--- apiVersion: v1 kind: Secret metadata: name: linstor-passphrase namespace: linbit-sds data: # CHANGE THIS TO USE YOUR OWN PASSPHRASE! # Created by: echo -n "example-passphrase" | base64 MASTER_PASSPHRASE: ZXhhbXBsZS1wYXNzcGhyYXNl --- apiVersion: piraeus.io/v1 kind: LinstorCluster metadata: name: linstorcluster spec: linstorPassphraseSecret: linstor-passphrase
5.3.7. Operator v2 デプロイメントにおける CustomResourceDefinitions の使用
LINSTOR Operator v2のデプロイメントでは、LINSTOR関連のKubernetes CustomResourceDefinitions (CRDs) を変更することでクラスターの状態を変更したり、リソースのステータスを確認したりできます。これらのリソースの概要リストは以下の通りです。詳細については、アップストリームのPiraeusプロジェクトのAPIリファレンス（以下の各リソースにリンクされています）を参照してください。
LinstorCluster-
このリソースは、LINSTORクラスターの状態およびKubernetesとの統合を制御します。
LinstorSatelliteConfiguration-
このリソースはLINSTORサテライトの状態を制御し、オプションでノードのサブセットのみに適用することもできます。
LinstorSatellite-
このリソースは、単一のLINSTORサテライトの状態を制御します。このリソースは直接変更することを意図しておらず、一致するすべての
LinstorSatelliteConfigurationリソースをマージすることによって、LINSTOR Operatorによって作成されます。 LinstorNodeConnection-
このリソースはLINSTORノード接続の状態を制御します。
5.3.8. LINSTORオペレータv2をデプロイメントした後の次のステップ
Kubernetes 用の LINBIT SDS をデプロイした後は、本章の KubernetesでのLINBIT SDSストレージの始め方、Operator v2デプロイメントにおけるDRBDモジュールローダーの設定:、Operator v2 デプロイメントにおいて DRBD レプリケーション用ホストネットワークを使用する セクションに進むか、アップストリームの Piraeus プロジェクトで利用可能な チュートリアル を参照してください。
5.4. LINSTOR Operator v1のデプロイメント
| 新しいクラスターに LINSTOR Operator をデプロイする予定がある場合は、Operator v2 を使用してください。すでに LINSTOR Operator v2 をデプロイ済みの場合は、このセクションをスキップして、LINSTORオペレーターを使用したデプロイ から始まる本章の他のトピックに進んでください。 |
Operator v1は、次のようにHelm v3チャートを使用してインストールされます：
-
my.linbit.com の認証情報を含む Kubernetes シークレットを作成します：
kubectl create secret docker-registry drbdiocred --docker-server=drbd.io \ --docker-username=<YOUR_LOGIN> --docker-email=<YOUR_EMAIL> --docker-password=<YOUR_PASSWORD>
このシークレットの名前は、Helm値で指定されたものと一致する必要があります。デフォルトは
drbdiocredです。 -
LINSTORのデータベースバックエンドを設定します。デフォルトでは、チャートはetcdをデータベースバックエンドとして設定します。オペレーターは、LINSTORが直接 データストアとしてKubernetes を使用するように設定することも可能です。etcdを使用する場合は、そのための永続ストレージを設定する必要があります：
-
デフォルトの
StorageClassを持つ既存のストレージプロビジョナーを使用する。 -
永続化を無効にします（基本的なテスト目的のみ）。これは、以下の
helm installコマンドに--set etcd.persistentVolume.enabled=falseを追加することで行えます。
-
-
ストレージガイドを読み、LINSTOR向けの基本的なストレージ設定を構成してください。
-
デプロイメントのセキュリティ保護に関するセクションを読み、必要に応じて設定を行ってください。
-
最後のステップで、
helm installコマンドの--setを使用して適切なカーネルモジュールインジェクターを選択してください。-
Choose the injector according to the distribution you are using. Select the latest version from one of
drbd9-rhel7,drbd9-rhel8, and others, shown as available when browsing the LINBIT container registry. Thedrbd9-rhel8image should also be used for RHCOS (OpenShift). For the SUSE CaaS Platform use the SLES injector that matches the base system of the CaaS Platform you are using, such asdrbd9-sles15sp1. For example: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
デプロイのさらなるカスタマイズについては、高度なデプロイのセクションで説明されています。
5.4.1. LINSTOR向けKubernetesバックエンド
LINSTORコントローラーは、クラスターの状態を永続化するためにKubernetes APIを直接使用できます。このバックエンドを有効にするには、チャートのインストール中に以下のオーバーライドファイルを使用してください。
etcd:
enabled: false
operator:
controller:
dbConnectionURL: k8s| charts.linstor.ioにある移行手順に従うことで、etcdバックエンドを使用している既存のクラスターをKubernetes APIバックエンドへ移行することが可能です。 |
5.4.2. 永続ストレージボリュームの作成
pv-hostpath Helm テンプレートを使用して、hostPath 永続ボリュームを作成できます。設定された etcd の replicas 数（デフォルトは 1）を満たすために必要な数だけ PV を作成してください。
hostPath 永続ボリュームを作成します。その際、nodes= オプションにはクラスターのノード名を適宜置き換えて指定してください：
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']}" を実行することで、すべてのノードの値を一覧表示できます。
|
5.4.3. 既存のデータベースの使用
LINSTORは既存のPostgreSQL、MariaDB、またはetcdデータベースに接続することができます。たとえば、次の構成でPostgreSQLインスタンスに接続する場合:
POSTGRES_DB: postgresdb POSTGRES_USER: postgresadmin POSTGRES_PASSWORD: admin123
ヘルム・チャートは、次の内容をHelmインストールコマンドに追加することで、このデータベースをデプロイメントするためにetcdクラスターの代わりに構成することができます。
--set etcd.enabled=false --set "operator.controller.dbConnectionURL=jdbc:postgresql://postgres/postgresdb?user=postgresadmin&password=admin123"
5.4.4. オペレーターv2を使用したストレージの設定
LINSTOR Operator v1は、LINSTORの基本的なストレージ設定を自動化できます。
ストレージプール作成の構成
LINSTOR Operatorは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は参照されている VolumeGroup や ThinPool などが存在することを想定しています。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 エントリで利用可能なキーは以下の通りです：
-
nameLINSTORストレージプールの名前。[必須] -
volumeGroup作成するVGの名前。[必須] -
devicePathsこのプールに設定するデバイス。認識されるためには、空であり、かつ1GiB以上である必要があります。[オプション] -
raidLevelLVMのRAIDレベル。[任意] -
vdo[VDO]を有効にします (サテライトにVDOツールが必要です)。[オプション] -
vdoLogicalSizeKib作成された VG のサイズ（VDO を使用することで、バッキングデバイスよりも大きくなることが期待されます）。[任意] -
vdoSlabSizeKibVDOのスラブサイズ。[任意]
LVM Thin Poolの設定
-
nameLINSTORストレージプールの名前。[必須] -
volumeGroupシンプールに使用するVG（ボリュームグループ）。devicePathsを使用する場合は、これを""に設定する必要があります。これは、LINSTORがデバイスの準備においてVG名の構成を許可していないためです。thinVolumeシンプールの名前。[必須] -
devicePathsこのプールに設定するデバイス。認識されるためには、空であり、かつ1GiB以上である必要があります。[オプション] -
raidLevelLVMのRAIDレベル。[任意]
| LVM thin poolのためにLINSTORによって作成されるボリュームグループは、常に「linstor_$THINPOOL」というスキームに従います。 |
ZFS ストレージプールの設定
-
nameLINSTORストレージプールの名前。[必須] -
zPool使用するzpoolの名前。すべてのマシンにあらかじめ存在している必要があります。[必須] -
thinシンプロビジョニングを使用する場合はtrue、それ以外の場合はfalseを指定します。[必須]
automaticStorageType の使用（非推奨）
storagePools セクションを使用してすでに準備されている場合を除き、対象となる すべて のデバイスは operator.satelliteSet.automaticStorageType の値に従って準備されます。デバイスはデバイス名に基づいてストレージプールに追加されます（つまり、すべての /dev/nvme1 デバイスは autopool-nvme1 プールの一部となります）。
operator.satelliteSet.automaticStorageType に指定可能な値:
-
None自動セットアップなし (デフォルト) -
LVMLVM (thick) ストレージプールを作成する -
LVMTHINLVMシンストレージプールを作成する -
ZFSZFSベースのストレージプールを作成する（未テスト）
5.4.5. オペレーターv1デプロイメントのセキュリティ確保
このセクションでは、KubernetesでHelmを使用してLINSTOR Operator v1をデプロイ（using Helm) する際に利用可能なセキュリティ機能を有効にするためのさまざまなオプションについて説明します。
既存の etcd インスタンスとの安全な通信
etcd インスタンスへのセキュアな通信は、Kubernetes シークレットの形式で CA 証明書をオペレーターに提供することで有効にできます。このシークレットには、PEM エンコードされた CA 証明書を値とするキー ca.pem が含まれている必要があります。
helm install に次の引数を渡すことで、シークレットをコントローラーに渡すことができます。
--set operator.controller.dbCertSecret=<secret name>
証明書を使用した etcd での認証
etcd データベースでTLS証明書を使用して認証する場合は、Helmのインストール時に次のオプションを設定する必要があります:
--set operator.controller.dbUseClientCert=true
このオプションが有効な場合、上記のセクションで指定されたシークレットには、2つの追加キーが含まれている必要があります。
-
etcdへの認証のために提示される PEM 形式の証明書client.cert -
上記のクライアント証明書に対応する、PKCS8形式の
client.key秘密鍵。
openssl を使用して、鍵を PKCS8 形式に変換できます：
openssl pkcs8 -topk8 -nocrypt -in client-key.pem -out client-key.pkcs8
5.4.6. オペレーターv1デプロイメントにおけるLINSTORコンポーネント間のセキュアな通信の設定
LINSTORコンポーネント間のデフォルトの通信は、TLSで保護されていません。セットアップでこれが必要な場合は、3つの方法のいずれかを選択してください。
cert-managerを用いた鍵、証明書の生成
クラスターにインストールするには、 cert-manager が必要です。
以下のオプションをHelmのオーバーライドファイルに設定してください。
linstorSslMethod: cert-manager
linstorHttpsMethod: cert-managerHelmを使用してキーと証明書を生成
以下のオプションを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 は、作成されたサービス名と一致させる必要があります。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-satelliteLINSTOR のパスフレーズを自動設定
LINSTORは、暗号化された情報をサポートするために機密データを保存する必要があります。このデータはマスターパスフレーズによって保護されます。パスフレーズは、初回のチャートインストール時に自動的に生成されます。
カスタムパスフレーズを使用する場合は、Secretに保存してください：
kubectl create secret generic linstor-pass --from-literal=MASTER_PASSPHRASE=<password>
インストール時に、次の引数を helm コマンドに追加します:
--set operator.controller.luksSecret=linstor-pass
5.4.7. Operator v1に対するHelmインストールの例
以下の例はすべて、次の sp-values.yaml ファイルを使用しています。お使いの環境や使用目的に合わせて自由に調整してください。詳細については、 [ストレージプールの作成の構成] を参照してください。
operator:
satelliteSet:
storagePools:
lvmThinPools:
- name: lvm-thin
thinVolume: thinpool
volumeGroup: ""
devicePaths:
- /dev/sdb
| デフォルトインストール。これにより、バックエンドの etcd キーバリューストアの永続化は設定されません。 |
| これはテスト以外の用途での使用は推奨されません。 |
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
The LINBIT container image repository (https://drbd.io), used in the previous and upcoming kubectl create commands, 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 can use the LINSTOR SDS upstream project named Piraeus, without being a LINBIT customer.
|
sp-values.yaml を通じてインストール時に定義される LINSTOR ストレージプール、永続的な 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 ストレージプールを使用し、etcd ではなく作成済みの PostgreSQL DB（できればクラスター化されたもの）を使用し、DRBD にはコンパイル済みのカーネルモジュールを使用します。
この特定の例におけるPostgreSQLデータベースは、postgres`という名前のサービスエンドポイントを介してアクセス可能です。PostgreSQL自体は、`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"5.4.8. Helm デプロイメントの終了
クラスターのストレージインフラストラクチャを保護し、重要なコンポーネントを誤って削除することを防ぐため、Helmデプロイメントを削除する前にいくつかの手動の手順を実行する必要があります。
-
LINSTORコンポーネントによって管理されているすべてのボリュームクレームを削除してください。次のコマンドを使用して、LINSTORによって管理されているボリュームクレームの一覧を取得できます。
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
リストされたボリュームに、必要なデータがもう残っていないことを確認したら、出力に表示された生成済みの
kubectl deleteコマンドを使用して削除できます。これらのボリュームは、一度削除されると復元できません。 -
LINSTORコントローラーとサテライト間のTLSの設定
LINSTOR satellite および controller のデプロイは、
LinstorSatelliteSetおよびLinstorControllerリソースによって制御されます。kubectlを使用して、デプロイに関連するリソースを削除できます。kubectl delete linstorcontroller <helm-deploy-name>-cs kubectl delete linstorsatelliteset <helm-deploy-name>-ns
少し待つと、コントローラーとサテライトのPodが終了するはずです。もし稼働し続ける場合は、上記のリソースにエラーがないか確認してください（これらは、関連するすべてのPodが終了した後にのみ削除されます）。
-
Helm デプロイメントの終了
すべてのPVCを削除し、すべてのLINSTORポッドが終了した場合は、Helmデプロイメントをアンインストールできます。
helm uninstall linstor-op
Helmの現在のポリシーにより、 LinstorControllerおよびLinstorSatelliteSetという名前のカスタムリソース定義は、このコマンドでは削除されません。CRDに関するHelmの現在の見解についての詳細は、https://helm.sh/docs/chart_best_practices/custom_resource_definitions/#method-1-let-helm-do-it-for-you[こちら]を参照してください。
5.4.9. Operator v1のための高度なデプロイメントオプション
Helmチャートは、高度なユースケース向けにさらなるカスタマイズオプションを提供します。
| The LINBIT container image repository (https://drbd.io), used in the Helm chart below, 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 can use the LINSTOR SDS upstream project named Piraeus, without being a LINBIT customer. |
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: registry.k8s.io/kube-scheduler
schedulerTag: ""
replicas: 1 (2)
storkResources: {} # resources requirements for the stork plugin containers (3)
schedulerResources: {} # resource requirements for the kube-scheduler containers (3)
podsecuritycontext: {}
csi:
enabled: true
pluginImage: "drbd.io/linstor-csi:v1.1.0"
csiAttacherImage: registry.k8s.io/sig-storage/csi-attacher:v4.3.0
csiLivenessProbeImage: registry.k8s.io/sig-storage/livenessprobe:v2.10.0
csiNodeDriverRegistrarImage: registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.8.0
csiProvisionerImage: registry.k8s.io/sig-storage/csi-provisioner:v3.5.0
csiSnapshotterImage: registry.k8s.io/sig-storage/csi-snapshotter:v6.2.1
csiResizerImage: registry.k8s.io/sig-storage/csi-resizer:v1.8.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.4"
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.23.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.23.0"
storagePools: {}
sslSecret: ""
automaticStorageType: None
affinity: {} (4)
tolerations: [] (4)
resources: {} (3)
monitoringImage: "drbd.io/drbd-reactor:v1.2.0"
monitoringBindAddress: ""
kernelModuleInjectionImage: "drbd.io/drbd9-rhel7:v9.1.14"
kernelModuleInjectionMode: ShippedModules
kernelModuleInjectionAdditionalSourceDirectory: "" (8)
kernelModuleInjectionResources: {} (3)
kernelModuleInjectionExtraVolumeMounts: []
mountDrbdResourceDirectoriesFromHost: "" (10)
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 | コンテナのリソース要求と制限を設定します。https://kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource/[Kubernetesドキュメント]を参照してください。
ほとんどのコンテナが必要とするリソースは最小限ですが、以下は例外です：
|
| 4 | アフィニティとトレレーションは、ポッドがクラスター内のどこにスケジュールされるかを決定します。詳細は アフィニティとトレレーションに関するKubernetesドキュメントを参照してください。これは、operator.satelliteSet および csi.node* の値において特に重要となる場合があります。LINSTORの永続ボリュームを使用するポッドをスケジュールするには、そのノードで LINSTOR satellite と LINSTOR CSI ポッドが実行されている必要があります。 |
| 5 | LINSTOR controllerおよびsatelliteに渡す追加の環境変数を設定します。https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/[コンテナの env 値]と同じ形式を使用します。 |
| 6 | LINSTORコントローラーに追加のプロパティを設定します。<property-key>: <value> のシンプルなマッピングを想定しています。 |
| 7 | kubeletは、すべてのCSIプラグインが、それ自体のステートディレクトリの特定のサブディレクトリ配下にボリュームをマウントすることを想定しています。デフォルトでは、このステートディレクトリは /var/lib/kubelet です。一部のKubernetesディストリビューションでは、異なるディレクトリが使用されています。
|
| 8 | カーネルモジュールのビルドに必要なホスト上のディレクトリ。Compile インジェクションメソッドを使用する場合にのみ必要です。デフォルトは /usr/src で、これはほとんどのディストリビューションで実際のカーネルソースが格納されている場所です。追加のディレクトリをマウントしない場合は "none" を使用してください。 |
| 9 | CSIドライバーが使用するワーカースレッドの数を設定します。値を大きくするとLINSTORコントローラーへの負荷が高まり、多数のボリュームを同時に作成する際に不安定になる可能性があります。 |
| 10 | trueに設定すると、サテライトコンテナにはホストオペレーティングシステムから以下のファイルとディレクトリがマウントされます。
|
5.4.10. Operator v1における高可用性デプロイメント
LINSTOR Operator v1 デプロイメント内のすべてのコンポーネントで高可用性デプロイメントを作成するには、https://github.com/piraeusdatastore/piraeus-operator/blob/b00fd34/doc/scheduling.md[upstream guide] を参照してください。デフォルト値は、コンポーネントを複数のレプリカにスケーリングした際にレプリカが確実に異なるノードに配置されるように選択されています。これにより、単一ノードの障害によってサービスが中断されないことが保証されます。
| LINSTOR Operator v2を使用してLINBIT SDSをKubernetesにデプロイした場合、デフォルトでデプロイメントに高可用性が組み込まれています。 |
高可用性コントローラーを使用した高速ワークロードフェイルオーバ
ノード障害が発生した際、Kubernetesはステートフルなワークロードの再スケジューリングに対して非常に保守的です。これは、到達不能なノードからPodが移動されるまでに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-connectHA コントローラーによるポッドの管理を除外するには、次の注釈をポッドに追加します:
$ kubectl annotate pod <podname> drbd.linbit.com/ignore-fail-over=""
5.5. LINSTORオペレーターを使用したデプロイ
オペレーターは、既存のLINSTORセットアップを使用するようにサテライトとCSIプラグインを構成できます。これは、ストレージインフラストラクチャがKubernetesクラスターから分離されている場合に役立ちます。ストレージノードがバッキングディスクストレージを提供する一方で、ボリュームをKubernetesノード上にディスクレスモードでプロビジョニングできます。
5.5.1. 外部LINSTORコントローラを使用したOperator v2のデプロイメント
このセクションの手順では、Operator v2 LINBIT SDS デプロイメントを、Kubernetes 外で管理している既存の LINBIT SDS クラスターに接続する方法について説明します。
このセクションの手順を進めるには、LinstorCluster リソースの編集に精通している必要があります。
LinstorCluster リソースの設定
外部で管理されているLINSTORクラスターを使用するには、YAML設定の`LinstorCluster`リソースでLINSTORコントローラーのURLを指定し、それをデプロイメントに適用します。以下の例では、LINSTORコントローラーは`http://linstor-controller.example.com:3370`でアクセス可能です。
apiVersion: piraeus.io/v1
kind: LinstorCluster
metadata:
name: linstorcluster
spec:
externalController:
url: http://linstor-controller.example.com:3370
| コントローラーにホスト名とドメインの代わりにIPアドレスを指定することもできます。 |
LINSTOR サテライトのホストネットワーキングを構成する
通常、PodネットワークはKubernetesクラスターの外部からアクセスできません。この場合、外部のLINSTORコントローラーはKubernetesクラスター内のサテライトと通信することができません。そのため、サテライトがホストネットワークを使用するように設定する必要があります。
ホストネットワークを使用するには、以下のYAML設定をデプロイメントに適用して、`LinstorSatelliteConfiguration`リソースをデプロイします。
apiVersion: piraeus.io/v1
kind: LinstorSatelliteConfiguration
metadata:
name: host-network
spec:
podTemplate:
spec:
hostNetwork: true外部のLINSTORコントローラー構成を検証
外部LINSTORコントローラーを使用するようにKubernetesデプロイメントが正しく設定されていることは、以下の内容を確認することで検証できます。
-
LinstorClusterリソースのAvailable条件は、外部LINSTORコントローラーの期待されるURLを報告します：$ kubectl get LinstorCluster -ojsonpath='{.items[].status.conditions[?(@.type=="Available")].message}{"\n"}' Controller 1.20.3 (API: 1.16.0, Git: 8d19a891df018f6e3d40538d809904f024bfe361) reachable at 'http://linstor-controller.example.com:3370' -
linstor-csi-controllerデプロイメントは期待されるURLを使用します:$ kubectl get -n linbit-sds deployment linstor-csi-controller \ -ojsonpath='{.spec.template.spec.containers[?(@.name=="linstor-csi")].env[?(@.name=="LS_CONTROLLERS")].value}{"\n"}' http://linstor-controller.example.com:3370 -
linstor-csi-nodeデプロイメントは期待されるURLを使用します。$ kubectl get -n linbit-sds daemonset linstor-csi-node \ -ojsonpath='{.spec.template.spec.containers[?(@.name=="linstor-csi")].env[?(@.name=="LS_CONTROLLERS")].value}{"\n"}' http://linstor-controller.example.com:3370 -
KubernetesノードはLINSTORコントローラー上でサテライトノードとして登録されています:
$ kubectl get nodes -owide NAME STATUS ROLES AGE VERSION INTERNAL-IP [...] k8s-1-26-10.test Ready control-plane 22m v1.26.3 192.168.122.10 [...] [...]
上記コマンドの出力からノード名を取得した後、LINSTORコントローラーノードでLINSTOR
node listコマンドを入力して、ノード名がLINSTORサテライトであることも確認してください。$ linstor node list ╭─────────────────────────────────────────────────────────────────────╮ ┊ Node ┊ NodeType ┊ Addresses ┊ State ┊ ╞═════════════════════════════════════════════════════════════════════╡ ┊ k8s-1-26-10.test ┊ SATELLITE ┊ 192.168.122.10:3366 (PLAIN) ┊ Online ┊ [...]
5.5.2. 外部のLINSTORコントローラーを使用した Operator v1 のデプロイメント
LINSTORコントローラーのデプロイ作成をスキップし、既存のLINSTORコントローラーを使用するように他のコンポーネントを構成するには、helm install の実行時に以下のオプションを使用してください。
-
operator.controller.enabled=falseこれにより、LinstorControllerリソースの作成が無効になります。 -
operator.etcd.enabled=falseKubernetes上でLINSTORコントローラーが実行されないため、データベースは不要です。 -
controllerEndpoint=<url-of-linstor-controller>既存のLINSTORコントローラーのHTTPエンドポイントです。例:http://linstor.storage.cluster:3370/
すべてのPodがReady状態になった後、KubernetesクラスターのノードがLINSTORセットアップ内のサテライトとして表示されるはずです。
| Kubernetesノードは、コントローラーノードおよびストレージノードからIPを使用して到達可能である必要があります。 |
ストレージノード上の既存のストレージプールを参照するストレージクラスを作成します。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: linstor-on-k8s
provisioner: linstor.csi.linbit.com
parameters:
autoPlace: "3"
storagePool: existing-storage-pool
resourceGroup: linstor-on-k8sストレージクラスを使用してPVCを作成することで、新しいボリュームをプロビジョニングできます。ボリュームはまず、指定されたストレージプール、つまりストレージインフラストラクチャが存在するノードにのみ配置されます。Podでボリュームを使用する場合、LINSTOR CSIはKubernetesノード上にディスクレスリソースを作成し、ネットワーク経由でディスクフルリソースにアタッチします。
5.6. Kubernetes で LINSTOR の操作
コントローラーポッドにはLINSTORクライアントが含まれており、LINSTORと直接やり取りすることが簡単になります。実行例:
kubectl exec deploy/linstor-controller -- linstor storage-pool list
5.6.1. LINSTORクライアントコマンドエントリの簡略化
Kubernetesデプロイメント内でLINSTORクライアントコマンドを簡略化するために、kubectl-linstor ユーティリティを使用できます。このユーティリティは、上流のPiraeusデータストアプロジェクトから利用できます。それをダウンロードするには、次のコマンドをあなたのKubernetesコントロールプレーンノードで入力してください:
# KL_VERS=0.3.0 (1) # KL_ARCH=linux_amd64 (2) # curl -L -O \ https://github.com/piraeusdatastore/kubectl-linstor/releases/download/v$KL_VERS/kubectl-linstor_v"$KL_VERS"_$KL_ARCH.tar.gz
| 1 | シェル変数 KL_VERS を、https://github.com/piraeusdatastore/kubectl-linstor/releases[kubectl-linstor リリースページ]に記載されている kubectl-linstor ユーティリティの最新リリースバージョンに設定します。 |
| 2 | シェル変数 KL_ARCH を、ご使用のデプロイメントに適しており、かつユーティリティの利用可能なリリースでサポートされているアーキテクチャに設定してください。 |
デプロイメントで LINSTOR Operator v2 を使用している場合、kubectl-linstor ユーティリティのバージョン 0.2.0 以降を使用する必要があります。
|
tarアーカイブのアセット名は、時間の経過とともに変更される可能性があります。上記のコマンドを使用してアセットをダウンロードする際に問題が発生した場合は、kubectl-linstor リリースページ で目的のアセットの命名規則を確認するか、あるいはリリースページから目的のアセットを手動でダウンロードしてください。
|
ユーティリティをインストールするには、まずファイルを展開し、展開された実行ファイルを $PATH 内のディレクトリ（例: /usr/bin）に移動します。そうすることで、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 ┊ ╰────────────────────────────────────────────────────────────────────────────────────╯
それはPVCへの参照も対応するLINSTORリソースに拡張します。
$ 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> 形式の参照を、その Pod が使用しているリソースの一覧に展開します。
This should only be necessary for investigating problems and accessing advanced functionality. Regular operation such as creating volumes should be achieved through the Kubernetes integration.
5.7. KubernetesでのLINBIT SDSストレージの始め方
すべての linstor-csi Pod が起動して実行状態になれば、通常のKubernetesワークフローを使用してボリュームをプロビジョニングできます。
Kubernetesを通じてデプロイされるLINSTORボリュームの動作やプロパティの設定は、Kubernetes StorageClass オブジェクトを使用して行われます。
resourceGroup パラメータは必須です。Kubernetes StorageClassオブジェクトはLINSTORリソースグループと一対一で対応しているため、通常は 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 plugin uses to identify itself
provisioner: linstor.csi.linbit.com
volumeBindingMode: WaitForFirstConsumer
parameters:
# LINSTOR will provision volumes from the drbdpool storage pool configured
# On the satellite nodes in the LINSTOR cluster specified in the plugin's deployment
storagePool: "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 ポッド内で実行する linstor storage-pool list コマンドを使用するか、kubectl-linstor ユーティリティ をインストールしている場合は kubectl linstor storage-pool list コマンドを使用して確認できます。
|
次のコマンドで Pod を作成できます。
kubectl create -f linstor-basic-sc.yaml
ストレージクラスが作成されたので、KubernetesとLINSTORの両方で認識されるボリュームをプロビジョニングするための永続ボリューム要求（PVC）を作成できるようになりました。
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を参照してボリュームをマウントする、シンプルなPodを作成します。
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 を削除します。例えば、作成したばかりのボリュームを削除するには、次の2つのコマンドを実行します。なお、PersistentVolumeClaim が削除される前に、Pod がアンスケジューリングされている必要があることに注意してください。
kubectl delete pod fedora # ポッドをスケジュール解除します。 kubectl get pod -w # wait for pod to be unscheduled kubectl delete pvc my-first-linstor-volume # remove the PersistentVolumeClaim, the PersistentVolume, and the LINSTOR Volume.
5.7.1. StorageClass で使用可能なパラメータ
以下のストレージクラスには、プロビジョニングされたストレージを構成するために現在利用可能なパラメータが含まれています。このストレージクラス構成に示されているパラメータキーの値は例示に過ぎません。この構成に示されている以外にも、これらのキーに使用できる値がある場合があります。例えば、監視や追跡機能の一部が失われる代わりに、パフォーマンスの向上と物理デバイスの「摩耗」を抑えるために、linstor.csi.linbit.com/mountOpts キーを "noatime,nodiratime" に設定することもできます。
linstor.csi.linbit.com/ は LINSTOR CSI 固有のパラメータに使用するオプションですが、推奨されるプレフィックスです。パラメータキーは大文字と小文字を区別しませんが、慣例としてローワーキャメルケースで表記されています。
|
mountOpts パラメータキーには、一般的な mount オプション、またはファイルシステム（ext4 または XFS）固有のオプションのいずれかを指定できます。
|
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 # or ext4
# 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: "-K" # or other `mkfs` options, refer to `man mkfs`
linstor.csi.linbit.com/mountOpts: "noatime" # or other `mount` or file system specific options
linstor.csi.linbit.com/postMountXfsOpts: "extsize 2m"
linstor.csi.linbit.com/xReplicasOnDifferent: |
topology.kubernetes.io/region: 2
topology.kubernetes.io/zone: 1
# Linstor properties
property.linstor.csi.linbit.com/*: <x>
# DRBD parameters
DrbdOptions/*: <x>
xReplicasOnDifferent パラメータキーの YAML マップは例示目的で示されていますが、replicasOnSame および replicasOnDifferent のキーや値と衝突します。そのため、これは使用可能な設定ではありません。
|
5.7.2. KubernetesでストレージリソースのためのDRBDオプションを設定する
StorageClass で使用可能なパラメータ セクションで示されているように、ストレージクラスの設定内でDRBDオプションを設定できます。KubernetesのStorageClassオブジェクトと、指定された名前のLINSTORリソースグループ（resourceGroup パラメータ）は1対1で対応しているため、ストレージクラス設定内でDRBDオプションを設定することは、LINSTORリソースグループに対してDRBDオプションを設定することと同様です。
いくつかの違いがあります。ストレージクラスの設定内でDRBDオプションを設定した場合、それらのオプションはそのストレージクラスから作成される新しいボリュームにのみ適用されます。既存のボリュームには影響しません。さらに、ストレージクラスを単純に更新することはできないため、ストレージクラスの設定にDRBDオプションを追加する場合は、一度削除してから再作成する必要があります。LINSTORのリソースグループオブジェクト（linstor resource-group set-property <rg-name> DrbdOptions/<option-name>）でDRBDオプションを設定した場合、変更はそのリソースグループに属する将来のボリュームおよび既存のボリュームの両方に適用されます。
| Kubernetesのストレージクラスにも対応するLINSTORのリソースグループでDRBDオプションを設定した場合、ストレージクラス側でもそのDRBDオプションを設定していない限り、次にボリュームが作成される際に、CSIドライバーはリソースグループのみに行われたDRBDオプションの変更を元に戻します。 |
ここには潜在的な落とし穴があるため、LINSTORコントローラーオブジェクトでDRBDオプションを設定する方が簡単です。コントローラーに設定されたDRBDオプションは、それらのLINSTORオブジェクトのいずれかに同じオプションを個別に設定していない限り、すべてのリソースグループ、リソース、およびボリュームに適用されます。LINSTORオブジェクトの階層構造の詳細については、LINSTORのオブジェクト階層 セクションを参照してください。
次のコマンドを入力することで、DRBDオプションを含む、LINSTORコントローラーオブジェクトに設定可能なプロパティの一覧を表示できます：
# kubectl exec -n linbit-sds deployment/linstor-controller -- \ linstor controller set-property --help
Kubernetes内のLINSTORコントローラーにDRBDオプションを設定する
Kubernetes デプロイメントにおいて LINSTOR コントローラーで DRBD オプションを設定するには、LinstorCluster 設定を編集します。例えば、すべての DRBD トラフィックに対してトランスポート暗号化を設定するには：
apiVersion: piraeus.io/v1
kind: LinstorCluster
metadata:
name: linstorcluster
spec:
properties:
# This one will be set on the controller, verify with: linstor controller list-properties
# Enable TLS for all resources by default
- name: "DrbdOptions/Net/tls"
value: "yes"
LinstorCluster 構成を編集した後、kubectl apply -f <configuration-file> を入力してデプロイメントに適用してください。
KubernetesにおけるLINSTORノード接続におけるDRBDオプションの設定
KubernetesにおけるLINSTORノード接続のDRBDオプションは、Kubernetesの LinstorNodeConnection 設定を編集することで設定できます。手順は、前節で説明した LinstorCluster 設定の編集および適用方法と同様です。
ノード接続レベルで設定されたDRBDオプションは、コントローラーレベルおよびサテライトノードレベルで設定されたDRBDオプションよりも優先されます。
以下は、2つのことを行うノード接続設定の例です。
-
異なる地理的リージョン（例：2つのデータセンター）に存在するノードのペア（定義上、ノード接続は2つのノードを接続します）を選択してください。
-
選択基準に一致するノード間のノードレベルの接続において、DRBDが プロトコル A (非同期レプリケーション) を使用するようにDRBDオプションを設定します。
apiVersion: piraeus.io/v1
kind: LinstorNodeConnection
metadata:
name: cross-region
spec:
selector:
# Select pairs of nodes (A, B) where A is in a different region than node B.
- matchLabels:
- key: topology.kubernetes.io/region
op: NotSame
properties:
# This property will be set on the node connection, verify with:
# linstor node-connection list-properties <node1> <node2>
# Configure DRBD protocol A between regions for reduced latency
- name: DrbdOptions/Net/protocol
value: A
ノード接続の selector 仕様の詳細については、上流の Piraeus プロジェクト内のドキュメントを参照してください。
|
KubernetesにおけるLINSTORサテライトノードでのDRBDオプションの設定
Kubernetes上のLINSTORサテライトノードにおけるDRBDオプションは、Kubernetesの LinstorSatelliteConfiguration 設定を編集することで設定できます。手順は、前のセクションで説明した LinstorCluster や LinstorNodeConnection 設定の編集および適用方法と同様です。
サテライトノードレベルで設定されたDRBDオプションは、コントローラーレベルで設定されたDRBDオプションよりも優先されます。
LINSTORによるノードの自動的な追い出しを防止するDRBDオプションを設定するには、自動追い出し機能を無効化したいノードに under-maintenance ラベルを付与した上で、以下の設定ファイルを使用してください。これはノードのシステムメンテナンス期間中に役立つ場合があります。
apiVersion: piraeus.io/v1
kind: LinstorSatelliteConfiguration
metadata:
name: nodes-under-maintenance
spec:
nodeSelector:
under-maintenance: "yes"
properties:
- name: DrbdOptions/AutoEvictAllowEviction
value: "false"
Kubernetes上のLINSTORストレージプールにおけるLINSTORプロパティの設定
さらに、以下の設定例に示すように、LINSTORサテライトノード上に存在するLINSTORストレージプールに対して、（DRBDオプションではなく）LINSTORプロパティを指定することもできます。
この例の構成は、Kubernetesデプロイメント内のすべてのLINSTORサテライトノードに適用されます。しかし、KubernetesにおけるLINSTORサテライトノードでのDRBDオプションの設定の構成例と同様に、構成内で特定のノードのみを選択することも可能です。詳細は アップストリームのPiraeusプロジェクトのドキュメント を参照してください。
apiVersion: piraeus.io/v1
kind: LinstorSatelliteConfiguration
spec:
storagePools:
- name: pool1
lvmThinPool: {}
properties:
# This one will be set on the storage pool, verify with:
# linstor storage-pool list-properties <node> <pool>
# Set the oversubscription ratio on the storage pool to 1, i.e. no oversubscription.
- name: MaxOversubscriptionRatio
value: "1"
5.7.3. csi.storage.k8s.io/fstype
csi.storage.k8s.io/fstype パラメータは、volumeMode: FileSystem の PVC に対して作成するファイルシステムの種類を設定します。現在サポートされているのは以下の通りです。
-
ext4(default) -
xfs
5.7.4. autoPlace
autoPlace は、この StorageClass のボリュームが持つレプリカの数を決定する整数です。例えば、autoPlace: "3" は3重のレプリケーションを持つボリュームを作成します。autoPlace と nodeList のどちらも設定されていない場合、ボリュームは1つのノードに 自動的に配置 されます。
このオプションを使用する場合、nodeList を使用してはいけません。
|
| 引用符を使用する必要があります。そうしないと、Kubernetesは StorageClass の形式が正しくないとしてエラーを返します。 |
| このオプション（および自動配置の動作に影響するすべてのオプション）は、ボリュームの基盤となるストレージがプロビジョニングされるLINSTORノードの数を変更するものであり、どの kubelets からそれらのボリュームにアクセスできるかということとは独立しています。 |
5.7.5. placementCount
placementCount は autoPlace のエイリアス
5.7.6. resourceGroup
この StorageClass に関連付ける LINSTOR Resource Group (RG) です。設定されていない場合、新しい PVC ごとに新しい RG が作成されます。
5.7.7. storagePool
storagePool は、新しく作成されるボリュームにストレージを提供するために使用される LINSTOR ストレージプール の名前です。
5.7.8. disklessStoragePool
disklessStoragePool は、”ディスクレス”として linetets に割り当てられたLINSTORボリュームにのみ影響するオプションパラメータです。LINSTORでカスタムディスクレスストレージプールが定義されている場合、ここで指定します。
5.7.9. layerList
作成するボリュームに使用するレイヤーをカンマ区切りのリストで指定します。利用可能なレイヤーとその順序については、このセクションの最後の方で説明されています。デフォルトは drbd,storage です。
5.7.10. placementPolicy
このキーはボリュームスケジューラを選択します。AutoPlaceTopology は、デフォルトのボリュームスケジューラです。このスケジューラは、Kubernetes からのトポロジ情報と、ユーザーが指定した制約（replicasOnSame および replicasOnDifferent を参照）を組み合わせて使用します。
| 他のボリュームスケジューラも存在する可能性がありますが、それらは実験的かつサポート対象外であるため、ドキュメントには記載されていません。 |
5.7.11. allowRemoteVolumeAccess
ボリュームがどのノードでアクセス可能かを制御します。このオプションの値は、2つの異なる形式を取ることができます。
-
単純な
"true"または"false"によって、すべてのノード、あるいは diskful リソースを持つノードのみからのアクセスを許可します。 -
どのノードがボリュームにアクセスできるかについて、より詳細なルール設定を可能にする高度なルール。
現在の実装では、同じラベルを共有するノードに対してボリュームへのアクセスを許可できます。例えば、diskfulリソースと同じリージョンおよびゾーン内にあるすべてのノードからのアクセスを許可したい場合は、次のように記述できます。
parameters: linstor.csi.linbit.com/allowRemoteVolumeAccess: | - fromSame: - topology.kubernetes.io/region - topology.kubernetes.io/zone複数のルールを指定できます。これらのルールは加算的に適用され、ノードはいずれか1つのルールに一致すれば割り当て可能になります。
5.7.12. encryption
encryption は、ボリュームを暗号化するかどうかを決定するオプションのパラメータです。これが正しく機能するためには、LINSTORが 暗号化用に設定 されている必要があります。
5.7.13. nodeList
nodeList は、ボリュームが割り当てられるノードのリストです。これにより、ボリュームが各ノードに割り当てられ、それらすべての間でレプリケートされます。これはホスト名によって単一のノードを選択するためにも使用できますが、単一のノードを選択するには replicasOnSame を使用する方がより柔軟です。
このオプションを使用する場合、autoPlace を使用してはいけません。
|
| このオプションは、どのLINSTORノード上でボリュームの基盤となるストレージをプロビジョニングするかを決定するものであり、どの kubelets からこれらのボリュームにアクセスできるかとは独立しています。 |
5.7.14. clientList
clientList は、ディスクレスボリュームを割り当てるノードのリストです。nodeList と組み合わせて使用します。
5.7.15. replicasOnSame
replicasOnSame は、ストレージをどこにプロビジョニングするかを決定するために autoPlace が使用される際、自動配置の選択ラベルとして使用される key または key=value 項目のリストです。これらのラベルは 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 ペアをすべて備えた唯一のノードだからです。これは、プロビジョニング用に単一のノードを選択するための最も柔軟な方法です。
このガイドは、LINSTOR CSI バージョン 0.10.0 以降を前提としています。replicasOnSame および replicasOnDifferent で参照されるすべてのプロパティは、補助プロパティ（auxiliary properties）として解釈されます。旧バージョンの LINSTOR CSI を使用している場合は、すべてのプロパティ名に Aux/ プレフィックスを追加する必要があります。そのため、replicasOnSame: "zone=z1" は replicasOnSame: "Aux/zone=z1" となります。手動で Aux/ を使用する方法は、新しいバージョンの LINSTOR CSI でも引き続き機能します。
|
StorageClass を autoPlace: "1" および replicasOnSame: "zone=z1" で設定すると、node-a と node-b はどちらも zone=z1 という aux prop を持っているため、ボリュームはいずれかのノードにプロビジョニングされます。
StorageClass を autoPlace: "2" および replicasOnSame: "zone=z1 role=backups" で構成すると、適切な補助プロパティを持つノードが2つ以上存在しないため、プロビジョニングに失敗します。
autoPlace: "2" および replicasOnSame: "zone=z1" を指定して StorageClass を構成した場合、node-a と node-b はどちらも zone=z1 という auxプロパティを持っているため、ボリュームはこれら両方のノードにプロビジョニングされます。
特定の値を指定せずにプロパティキーのみを使用することで、特定の値を考慮しつつ、すべてのレプリカが同じプロパティ値を持つノードに配置されるようにすることもできます。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 のいずれかに配置されます。
5.7.16. 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が設定されていると仮定します。autoPlace: "2"およびreplicasOnDifferent: "zone"を指定した StorageClass を使用すると、LINSTORはnode-a1またはnode-a2のいずれかに1つのレプリカを作成し、かつnode-b1またはnode-b2のいずれかに1つのレプリカを作成します。
5.7.18. doNotPlaceWithRegex
Do not place the resource on a node which has a resource with a name matching the regular expression.
5.7.22. 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
5.7.23. DrbdOptions/*: <x>
このオプションは非推奨です。より汎用的な property.linstor.csi.linbit.com/* 形式を使用してください。
|
LINSTORに渡す高度なDRBDオプション。例えば、レプリケーションプロトコルを変更するには、DrbdOptions/Net/protocol: "A" を使用します。
5.8. スナップショット
スナップショットは、特定の時点におけるボリューム内容のコピーを作成します。このコピーは、ボリュームの内容に変更を加えても影響を受けずに保持されます。これにより、たとえばデータの変更や削除を行う前に、データのバックアップを作成することが可能になります。
バックアップは、復元する方法がなければ意味がないため、本セクションではスナップショットの作成方法と、例えばデータを誤って削除した場合などの復元方法について説明します。
5.8.1. スナップショットとの使用
LINBIT SDS デプロイメントにスナップショットのサポートを追加する前に、以下の環境の前提条件を満たす必要があります。
-
あなたのクラスターには、スナップショットをサポートするストレージプールがあります。LINSTORは、
LVM_THIN、ZFS、および`ZFS_THIN`プールでのスナップショットをサポートしています。スナップショットは、XFSやBtrfsなど、`reflinks`をサポートするファイルシステムをバックエンドに持つ`FILE_THIN`プールでもサポートされています。 -
スナップショットをサポートするストレージプールを使用する
StorageClass、PersistentVolumeClaim、およびDeploymentがあります。 -
お使いのクラスターには、Kubernetes でスナップショットを作成するために必要な CRD が備わっています。これらがデプロイされていることを確認するには、次のコマンドを入力してください。
$ kubectl api-resources --api-group=snapshot.storage.k8s.io -oname
出力は以下のような形式にしてください。
volumesnapshotclasses.snapshot.storage.k8s.io volumesnapshotcontents.snapshot.storage.k8s.io volumesnapshots.snapshot.storage.k8s.io
コマンドの出力が空の場合は、次のコマンドを入力して必要な CRD をデプロイできます。
$ kubectl apply -k https://github.com/kubernetes-csi/external-snapshotter//client/config/crd
-
クラスターには CSI スナップショット (link:
snapshot-controller) がデプロイされています。CSI スナップショットがすでにデプロイされていることを確認するには、次のコマンドを入力します。$ kubectl get pods -A | grep snapshot-controller
バニラ以外の Kubernetes フレーバーを使用している場合、そのフレーバーではスナップショットコントローラーの名前が異なっている可能性があるため、 grepコマンドで使用する正規表現を変更する必要があるかもしれません。出力は以下のような形式にしてください。
kube-system snapshot-controller-[...] 1/1 Running 7 (22m ago) 7d20h kube-system snapshot-controller-[...] 1/1 Running 7 (22m ago) 7d20h
snapshot-controllerはレプリカセットとしてデプロイされているため、出力には複数のsnapshot-controllerポッドが表示されます。コマンドの出力が空の場合は、次のコマンドを入力してスナップショットコントローラーをデプロイできます。$ kubectl apply -k https://github.com/kubernetes-csi/external-snapshotter//deploy/kubernetes/snapshot-controller
スナップショットの作成
ボリュームスナップショットを作成するには、まずボリュームスナップショットクラス (VolumeSnapshotClass) を作成する必要があります。このボリュームスナップショットクラスでは、linstor.csi.linbit.com プロビジョナーを指定し、スナップショットのクリーンアップポリシーを Delete に設定します。これは、Kubernetesリソースを削除すると、LINSTOR内のスナップショットも削除されることを意味します。
次のコマンドを入力することで、ボリュームスナップショットクラスを作成できます。
$ kubectl apply -f - <<EOF apiVersion: snapshot.storage.k8s.io/v1 kind: VolumeSnapshotClass metadata: name: linbit-sds-snapshots driver: linstor.csi.linbit.com deletionPolicy: Delete EOF
スナップショットを作成するには、VolumeSnapshot リソースを作成します。VolumeSnapshot リソースは、スナップショット互換の PersistentVolumeClaim リソースと、先ほど作成した VolumeSnapshotClass を参照する必要があります。例えば、次のコマンドを入力することで、data-volume という名前の PVC のスナップショット（data-volume-snapshot-1 という名前）を作成できます。
$ kubectl apply -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: data-volume-snapshot-1
spec:
volumeSnapshotClassName: linbit-sds-snapshots
source:
persistentVolumeClaimName: data-volume
EOF
スナップショットの作成を検証中
以下のコマンドを入力することで、スナップショットの作成を確認できます:
$ kubectl wait volumesnapshot --for=jsonpath='{.status.readyToUse}'=true data-volume-snapshot-1
volumesnapshot.snapshot.storage.k8s.io/data-volume-snapshot-1 condition met
$ kubectl get volumesnapshot data-volume-snapshot-1
出力は、以下のような形式でボリュームスナップショットリソースに関する情報の表を表示する必要があります。
NAME READYTOUSE SOURCEPVC SOURCESNAPSHOTCONTENT RESTORESIZE SNAPSHOTCLASS data-volume-snapshot-1 true data-volume 1Gi linbit-sds-snapshots
次のコマンドを入力することで、LINSTORにおけるスナップショットをさらに検証できます:
$ kubectl -n linbit-sds exec deploy/linstor-controller -- linstor snapshot list
出力は以下のようなテーブルを表示する必要があります:
╭─────────────────────────────────────────────────────────────────────────────────────────╮ ┊ ResourceName ┊ SnapshotName ┊ NodeNames ┊ Volumes ┊ CreatedOn ┊ State ┊ ╞═════════════════════════════════════════════════════════════════════════════════════════╡ ┊ pvc-[...] ┊ snapshot-[...] ┊ kube-0 ┊ 0: 1 GiB ┊ 2023-02-13 15:36:18 ┊ Successful ┊ ╰─────────────────────────────────────────────────────────────────────────────────────────╯
スナップショットの復元
スナップショットを復元するには、復元するボリュームスナップショット用の新しい PVC を作成する必要があります。この例では、既存の data-volume という名前の PVC をスナップショットに基づいた新しいバージョンに置き換えます。
最初に、data-volume PVC を使用しているデプロイメントを停止してください。この例では、デプロイメントの名前は volume-logger です。
$ kubectl scale deploy/volume-logger --replicas=0 deployment.apps "volume-logger" deleted $ kubectl rollout status deploy/volume-logger deployment "volume-logger" successfully rolled out
次に、PVCを削除します。スナップショットリソースがまだ残っているので、これは安全な操作です。
$ kubectl delete pvc/data-volume persistentvolumeclaim "data-volume" deleted
次に、以前に作成したスナップショットを参照して新しいPVCを作成します。これにより、参照されたスナップショットのデータを使用するボリュームが作成されます。
kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: data-volume
spec:
storageClassName: linbit-sds-storage
resources:
requests:
storage: 1Gi
dataSource:
apiGroup: snapshot.storage.k8s.io
kind: VolumeSnapshot
name: data-volume-snapshot-1
accessModes:
- ReadWriteOnce
EOF
data-volume という新しいボリュームを前のボリュームと同じ名前にしたため、単に Deployment を再度スケールアップすれば、新しいポッドが復元されたボリュームを使用し始めます。
$ kubectl scale deploy/volume-logger --replicas=1 deployment.apps/volume-logger scaled
5.8.2. スナップショットの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-keysnap.linstor.csi.linbit.com/ パラメータの正確な意味については、 スナップショットの転送 セクションの手順書を参照してください。ログインに使用される資格情報は、上記の例に示されているように、別個のシークレットに保存されています。
上記のストレージクラスを参照してスナップショットを作成すると、スナップショットが自動的に構成された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 として参照できます。
5.9. ボリュームのアクセシビリティとローカリティ
これはDRBDボリュームにのみ適用され、関連ドキュメントが更新された場合はセクションが変更される可能性があります。 LINSTORボリュームは通常、 [s-drbd_clients、ネットワーク越しに] ローカルおよびアクセス可能です。 CSIドライバーは、ボリュームが消費者向けに選択されたノードでアクセス可能であることを保証します。 ドライバーには、ボリュームの局所性（消費者がバッキングデータと同じノードに配置される）およびアクセシビリティの制限（ネットワーク越しにボリュームにアクセスできるノードのサブセットのみ）を保証するオプションも用意されています。
ボリュームの局所性は、ストレージクラスで volumeBindingMode: WaitForFirstConsumer を設定することで実現されます。これにより、Kubernetes と CSI ドライバーは、PVC を参照する最初のコンシューマー（ポッド）がスケジュールされるまで待機するように指示されます。次に、CSI ドライバーは、コンシューマーと同じノード上の下位データを使用してボリュームをプロビジョニングします。適切なストレージプールのないノードが選択された場合、アクセス可能なノードのセットから代替ノードが選択されます（以下を参照）。
ボリュームのアクセシビリティは、allowRemoteVolumeAccess パラメータによって制御されます。CSIプラグインがボリュームを配置する必要がある場合、このパラメータが参照されて、「アクセス可能」ノードの一覧を取得します。これにより、ノード間でネットワークを介して配置されたボリュームを共有できるようになります。この情報はまた、PVのラベルセレクターを使用してKubernetesに伝播されます。
5.9.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 | 遅延ボリュームバインディングを有効にします。可能な場合、最初の消費ポッドと同じノードにレプリカを配置します。 |
| 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 | 遅延ボリュームバインディングを有効にします。可能な場合、最初の消費ポッドと同じノードにレプリカを配置します。 |
| 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 | 遅延ボリュームバインディングを有効にします。可能な場合、最初の消費ポッドと同じノードにレプリカを配置します。 |
| 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台しかない場合、追加のレプリカなしで単一のボリュームのみを配置できます。 |
| 3 | 私たちのワーカーノードは、外部ストレージホストに接続することが許可される必要があります。 |
5.10. ReadWriteMany ボリュームアクセス
LINSTOR Operator バージョン 2.10.0 以降、LINSTOR CSI ドライバーを使用して ReadWriteMany (RWX) PVC を直接作成できるようになりました。この機能により、複数のポッドが LINSTOR をバックエンドとする同一の永続ボリュームに対して、同時にマウントおよび書き込みを行うことが可能になります。
内部的には、RWXボリュームアクセスモードはNFSとDRBD Reactorを使用しています。NFSが使用されるため、I/Oパフォーマンスは本来よりも低下します。
| LINSTORのRWXボリュームアクセスモードはDRBD Reactorを使用するため、DRBDクォーラムの要件を満たすように、3ノード以上で構成されるLINSTORクラスターを使用することが推奨されます。DRBD Reactorは、高可用性サービスを管理するためにDRBDクォーラム機能を利用します。 |
5.10.1. RWXアクセスを使用したPVCの作成
LINSTORベースのKubernetesストレージクラスからRWX PVCを作成するには、PVCオブジェクトの spec でストレージクラス名と ReadWriteMany アクセスモードを指定します。例えば以下のようになります：
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: demo-rwx-pvc-0 spec: storageClassName: linstor-csi-lvm-thin-r3 accessModes: - ReadWriteMany [...]
このYAML設定で指定する storageClassName は、3ノード以上のLINSTORクラスターにおいて、autoPlace パラメータの値に2以上を指定しているものである必要があります。
|
5.10.2. KubernetesにおけるRWXボリュームの考慮事項
DRBDクォーラムの要件を満たすLINSTORクラスターや、最小オートプレースメント値が2のストレージクラスを使用するという既に述べた推奨事項に加えて、KubernetesでRWXボリュームを使用する際には他にも考慮すべき事項があります。これらの考慮事項は、LINSTORストレージクラスパラメータに関連しています。
RWX ボリュームで使用する予定の LINSTOR ストレージクラスで、fsOpts (mkfs) オプションを指定できます。指定した fsOpts オプションは、LINSTOR Operator が NFS シェアとしてエクスポートするファイルシステムに適用されます。ファイルシステムのタイプは、ストレージクラス設定内の fstype パラメータを使用して指定します。
| RWX PVCをプロビジョニングするLINSTORストレージクラスでは、`mountOpts`を使用しないでください。これは、LINSTOR Operatorが、アクセスを必要とする各Kubeletに対して、変更すべきではない理想的な（独自の設計思想に基づいた）マウントオプションを使用してNFSエクスポートをマウントするためです。 |
3ノード未満のクラスターにおけるRWXボリュームアクセスの使用
DRBD quorum機能を利用可能なLINSTORクラスターを使用することが強く推奨されますが、3ノード未満のクラスターにおいてRWXボリュームアクセスをデプロイすることも可能です。この場合、バッキングストレージクラスの設定において、DRBD quorumオプションの値を手動で majority に設定する必要があります。
[...] parameters: DrbdOptions/Resource/quorum: majority [...]
2ノードクラスターにおいてパラメータ値を majority に設定することは、クラスター内でHA RWXボリュームを稼働させるために、両方のノードがネットワーク経由で接続されている必要があることを意味します。これを設定しない場合、3ノード未満のクラスターでは値がデフォルトで off になります。例えば、2ノードクラスターで設定がデフォルト値の off のままだと、どちらのノードもいつでも昇格できてしまうため、スプリットブレインの発生や手動での介入、およびダウンタイムにつながる可能性があります。
| 3ノード未満のクラスターでもRWXボリュームを構成することは可能ですが、DRBDクォーラムの条件を満たすクラスター（最小3ノード）でLINSTORを使用することが、常に好ましく、推奨されます。 |
5.11. 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 で利用可能です。
5.12. LINSTOR スケジューラーを使用したボリューム局所性の最適化
ポッドがデータのローカルレプリカを持つノードにスケジュールされるようにし、読み取り操作のレイテンシを削減するには、以下の手順を実行します。
-
volumeBindingMode: WaitForFirstConsumerを設定した StorageClass を使用してください。 -
StorageClassのパラメータで
allowRemoteVolumeAccess: "false"を設定してください。
任意で、[LINSTOR Affinity Controller](https://artifacthub.io/packages/helm/piraeus-charts/linstor-affinity-controller)をデプロイすることもできます。
5.13. Operator v2デプロイメントにおけるDRBDモジュールローダーの設定:
このセクションの手順に従うには、LinstorSatelliteConfiguration リソースの編集に慣れている必要があります。
|
DRBDモジュールローダーは、LINBIT SDSにおいてDRBDカーネルモジュールを利用可能にし、Kubernetesでの他の便利なカーネルモジュールの読み込みを行うコンポーネントです。このセクションでは、LINSTOR Operator v2デプロイメント内で、DRBDカーネルモジュールローダーのさまざまな側面を構成する方法について説明します。
提供されている場合、DRBDカーネルモジュール以外にも、以下のモジュールがロードされます:
| Module | Purpose |
|---|---|
|
dependency for DRBD |
|
LINSTOR NVME layer |
|
LINSTOR when using loop devices as backing disks |
|
LINSTOR writecache layer |
|
LINSTOR cache layer |
|
LINSTOR thin-provisioned storage |
|
LINSTOR Snapshots |
|
LINSTOR encrypted volumes |
5.13.1. DRBDモジュールローダーの無効化
いくつかの状況下では、DRBDモジュールローダーを完全に無効にする必要がある場合があります。たとえば、イミュータブルなオペレーティングシステムを使用していて、DRBDや他のモジュールがホスト設定の一部としてロードされている場合などです。
DRBDモジュールローダーを完全に無効にするには、次のYAML構成をデプロイメントに適用してください:
apiVersion: piraeus.io/v1
kind: LinstorSatelliteConfiguration
metadata:
name: no-loader
spec:
podTemplate:
spec:
initContainers:
- name: drbd-module-loader
$patch: delete5.13.2. 異なるDRBDモジュールローダーバージョンの選択:
デフォルトでは、Operatorはホストのオペレーティングシステムに一致するDRBDモジュールローダーを見つけようとします。Operatorは、Kubernetesの Node リソースの .status.nodeInfo.osImage フィールドを調査することでホストディストリビューションを判別します。自動マッピングが成功しない場合や異なるモジュールローディング要件がある場合は、ユーザー定義のイメージを使用できます。
次のYAML構成は、選択したDRBDモジュールローダーのイメージをユーザー定義のイメージ example.com/drbd-loader:v9 で上書きします。
apiVersion: piraeus.io/v1
kind: LinstorSatelliteConfiguration
metadata:
name: custom-drbd-module-loader-image
spec:
podTemplate:
spec:
initContainers:
- name: drbd-module-loader
image: example.com/drbd-loader:v9drbd.io は、LINBITの顧客のみが利用可能で、以下のモジュールローダーコンテナイメージを維持しています。
| Image | Distribution |
|---|---|
|
Amazon Linux 2 |
|
Ubuntu 18.04 |
|
Ubuntu 20.04 |
|
Ubuntu 22.04 |
|
Red Hat Enterprise Linux 7 |
|
Red Hat Enterprise Linux 8 |
|
Red Hat Enterprise Linux 9 |
自分自身のディストリビューション用のモジュールローダーイメージを作成する必要がある場合は、上流のPiraeusプロジェクトで利用可能な [the container source files] [コンテナのソースファイル] にアクセスすることができます。詳細はリンク:https://github.com/piraeusdatastore/piraeus/tree/master/dockerfiles/drbd-driver-loader をご参照ください。
5.13.3. モジュールローダーがDRBDカーネルモジュールをロードする方法の変更
デフォルトでは、DRBDモジュールローダーはソースからカーネルモジュールをビルドしようとします。モジュールローダーは、イメージに含まれるDEBやRPMパッケージからモジュールを読み込むように構成することもでき、また、完全にDRBDの読み込みをスキップすることもできます。
DRBDモジュールローダーの動作を変更するには、LB_HOW 環境変数を、以下の表に示されている適切な値に設定してください。
LB_HOW |
Module Loader Behavior |
|---|---|
|
The default value. Builds the DRBD module from source and tries to load all optional modules from the host. |
|
Searches for |
|
Only tries to load the optional modules. No DRBD module will be loaded. |
LB_HOW 環境変数を設定した後、デプロイメントに以下のYAML構成を適用してください。メタデータセクション内の名前に基づいて、以下の例は LB_HOW 環境変数が deps_only に設定されている場合に使用されます。
apiVersion: piraeus.io/v1
kind: LinstorSatelliteConfiguration
metadata:
name: no-drbd-module-loader
spec:
podTemplate:
spec:
initContainers:
- name: drbd-module-loader
env:
- name: LB_HOW
value: deps_only5.14. Operator v2 デプロイメントにおいて DRBD レプリケーション用ホストネットワークを使用する
このセクションの手順では、ホストネットワークを使用してDRBDレプリケーショントラフィックを行う方法について説明します。
デフォルトでは、DRBDはコンテナネットワークを使用してボリュームデータを複製します。これにより、さらなる構成を行わずに幅広い範囲のクラスタで複製が機能することを保証します。また、NetworkPolicy の使用を可能にし、DRBDトラフィックへの未認可アクセスをブロックすることができます。ポッドのネットワークインターフェースはポッドのライフサイクルに結び付いているため、LINSTORサテライトポッドが再起動されると、DRBDは一時的に複製を中断することを意味します。
ホストネットワークを使用すると、DRBDレプリケーションはLINSTORサテライトポッドとは独立して動作するため、一方通行とは異なります。ホストネットワークは、コンテナネットワークよりもパフォーマンスが向上する場合があります。デメリットとしては、関連ポート間でノード間の接続性を手動で確保する必要があります。
このセクションの手順に従うには、LinstorSatelliteConfiguration リソースの編集に慣れている必要があります。
|
5.14.1. ホストネットワークを使用するように DRBD レプリケーションを構成する
デフォルトのコンテナネットワークからホストネットワークに切り替えて DRBD レプリケーションを行うことはいつでも可能です。既存の DRBD リソースはその後、ホストネットワークインターフェイスを使用するように再構成されます。
サテライトのホストネットワークを設定するには、次のYAML構成をデプロイメントに適用してください。
apiVersion: piraeus.io/v1
kind: LinstorSatelliteConfiguration
metadata:
name: host-network
spec:
podTemplate:
spec:
hostNetwork: trueサテライトポッドが再作成されると、ホストネットワークを使用します。既存の DRBD リソースは、コンテナネットワーク上の IP アドレスではなく、ホストネットワーク上の新しい IP アドレスを使用するように再構成されます。
5.14.2. コンテナーネットワークを使用するためのDRBDレプリケーションの設定
ホストネットワークからコンテナーネットワークに戻す際には、DRBDで使用される構成されたピアアドレスを手動でリセットする必要があります。この作業は、すべてのノードを再起動するか、各ノードで drbdadm CLIコマンドを使用してアドレスを手動でリセットすることによって行うことができます。それぞれの方法について以下に説明します。
ホストからコンテナネットワークへのDRBDレプリケーション切り替えのためにノードを再起動します。
最初に、hostNetwork: true を設定した LinstorSatelliteConfiguration を削除する必要があります。次の kubectl コマンドを入力することでこれを行うことができます：
$ kubectl delete linstorsatelliteconfigurations.piraeus.io host-network linstorsatelliteconfiguration.piraeus.io "host-network" deleted
次に、各クラスターノードを順次または一度にすべて再起動します。一般的に、再起動したノードと再起動していないノードの間でレプリケーションは機能しません。 再起動していないノードはホストネットワークアドレスを引き続き使用し、これらは通常、コンテナネットワークから到達できません。
全てのノードが再起動された後、全てのリソースはコンテナネットワークを使用するように構成され、全ての DRBD 接続が再度接続されるはずです。
DRBD管理ツールを使用して、ホストからコンテナネットワークへのDRBDレプリケーションの切り替え
| この手順中は、新しいボリュームやスナップショットが作成されないように注意してください。さもないと、コンテナネットワークへの移行がすべてのリソースに適用されない可能性があります。 |
まず、drbdadm suspend-io all コマンドを使用してすべてのDRBDレプリケーションを一時停止し、すべてのDRBDボリュームI/O操作を一時停止する必要があります。各LINSTORサテライトポッドでコマンドを一度入力してください。
$ kubectl exec ds/linstor-satellite.node1.example.com -- drbdadm suspend-io all $ kubectl exec ds/linstor-satellite.node2.example.com -- drbdadm suspend-io all $ kubectl exec ds/linstor-satellite.node3.example.com -- drbdadm suspend-io all
次に、すべてのノードですべてのDRBD接続を切断してください。
$ kubectl exec ds/linstor-satellite.node1.example.com -- drbdadm disconnect --force all $ kubectl exec ds/linstor-satellite.node2.example.com -- drbdadm disconnect --force all $ kubectl exec ds/linstor-satellite.node3.example.com -- drbdadm disconnect --force all
次に、すべてのDRBD接続パスを安全にリセットできます。これにより、各ノード上の接続がコンテナネットワークに移動できます。
$ kubectl exec ds/linstor-satellite.node1.example.com -- drbdadm del-path all $ kubectl exec ds/linstor-satellite.node2.example.com -- drbdadm del-path all $ kubectl exec ds/linstor-satellite.node3.example.com -- drbdadm del-path all
最後に、hostNetwork: true を設定した LinstorSatelliteConfiguration リソース構成を削除します。これにより、コンテナネットワークを使用する新しいLINSTORサテライトポッドが作成されます。
$ kubectl delete linstorsatelliteconfigurations.piraeus.io host-network linstorsatelliteconfiguration.piraeus.io "host-network" deleted
ポッドが再作成され、LINSTORのサテライトが オンライン になった後、DRBDリソースは再構成され、I/O操作が再開されます。
5.15. Kubernetes でのノードの退避
リソースの LINSTOR ノードを退避させて、クラスター内の他のノードに配置する場合、そのプロセスは ノードの退避 で詳しく説明されています。 ただし、Kubernetes で LINSTOR ノードを退避させる前に、追加のアクションを実行する必要があります。
最初に、新しいKubernetesのワークロードがそのノードにスケジュールされないように防止し、その後にノードのワークロードを別のノードに移動します。次のコマンドを入力することでこれを行うことができます:
# kubectl cordon <node_name> # kubectl drain --ignore-daemonsets <node_name>
クラスターが期待通りに動作していることを確認した後、 ノードの退避 の手順に従って続行できます。
複数のノードの退避を計画している場合は、退避するすべてのノードで次のコマンドを入力します。
# linstor node set-property n1.k8s-mwa.at.linbit.com AutoplaceTarget false
これにより、退避しようとしているノードから、退避を計画している別のノードに LINSTOR がリソースを配置することがなくなります。
5.16. KubernetesでのLINSTORノードの削除
KubernetesクラスタからLINSTORストレージノードを削除する前に、ノードにデプロイされたLINSTORリソースやKubernetesワークロードがない必要があります。ノードからリソースとワークロードを削除するには、 Kubernetes でのノードの退避 セクションの手順に従うことができます。
代わりに、LINSTOR Operatorにノードの避難を処理させても良いです。これを行うには、いくつかの準備手順を踏む必要があります。
まず、次の例のように、Kubernetesクラスタから削除したいノードに marked-for-deletion のラベルを適用するために kubectl を使用してください。
# kubectl label nodes <node-name> marked-for-deletion=
あなたはラベル名の最後に等号（=）を追加する必要があります。
|
次に、適用したラベルを持つノードに LINSTOR リソースをデプロイしないように、linstorcluster Kubernetes リソースを構成します。これを行うには、リソースを編集し、以下の例に示す行を含む内容に置き換えます（… 行を含む）。key を、以前にノードに適用したラベルに一致するように変更してください。
# kubectl edit linstorclusters linstorcluster
...
spec:
nodeAffinity:
nodeSelectorTerms:
- matchExpressions:
- key: marked-for-deletion
operator: DoesNotExist
これらの手順を実行すると、LINSTOR Operator は自動的に対応する LinstorSatellite リソースを削除します。これにより、そのノード上の LINSTOR サテライト サービスが停止しますが、LINSTOR が node evacuate 操作を実行し、ノード上にリソースがもう存在しない場合にのみ停止します。次のコマンドを入力して、Operator がノードを避難させるのを待ちます:
# kubectl wait linstorsatellite/<node> --for=condition=EvacuationCompleted
これには時間がかかることがあります。また、’kubectl describe linstorsatellite/<node>’ を使用して、避難プロセスの状況の更新を取得することもできます。
オペレーターがノードを避難させた後、以下のコマンドを入力してノードを削除できます:
# kubectl delete node <node-name>
5.17. Prometheus による監視
KubernetesでのLINSTORデプロイメントは、Prometheus monitoring stackと統合する可能性を提供します。https://prometheus.io/[Prometheus] を使用して、Kubernetes内のLINSTORおよび関連コンポーネントを監視できます。この監視ソリューションは、あなたの目的に合わせて設定可能であり、Prometheusスクレイプメトリクス用のGrafanaダッシュボードやアラートルールの設定、イベントのアラートを受け取る機能などを含んでいます。
Prometheusモニタリングは、LINSTORとの統合を設定:
-
LINSTORおよびDRBD状態のメトリクス収集。
-
クラスターの状態に基づくアラート
-
Grafanaダッシュボード
LINSTORをKubernetesデプロイメント内でモニタリングするために、以下の点に精通している必要があります:
5.17.1. Operator v2 デプロイメントでのPrometheusを使用したモニタリングの設定
このセクションでは、LINSTOR Operator v2のKubernetesにおけるPrometheusを用いたモニタリングの設定方法について説明します。LINSTOR Operator v1デプロイメントの場合は、 Operator v1 デプロイメントでの Prometheusによるモニタリング セクションの手順を参照してください。
LINSTOR Operator v2 デプロイメント向けの Prometheus Operator のデプロイメント
| もしすでに運用中のプロメテウスオペレーターのデプロイメントがある場合は、このセクションの手順をスキップしてください。 |
KubernetesでPrometheusモニタリングインテグレーションをデプロイするには、Prometheus Operatorをデプロイする必要があります。これを行う簡単な方法は、Prometheusコミュニティが提供するHelmチャートを使用することです。
最初に、以下のコマンドを入力して、HelmチャートリポジトリをローカルのHelm構成に追加してください:
# helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
その後、リンクをデプロイしてください:https://artifacthub.io/packages/helm/prometheus-community/kube-prometheus-stack[kube-prometheus-stack] チャート。このチャートは、クラスターにPrometheus、Alertmanager、およびGrafanaをセットアップします。全ての名前空間で監視とアラートのルールを検索するように構成してください:
# helm install \ --create-namespace -n monitoring prometheus prometheus-community/kube-prometheus-stack \ --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false \ --set prometheus.prometheusSpec.podMonitorSelectorNilUsesHelmValues=false \ --set prometheus.prometheusSpec.ruleSelectorNilUsesHelmValues=false
デフォルトでは、デプロイメントは kube-system および独自のネームスペース内のリソースのみ監視します。LINSTOR は通常、異なるネームスペースで展開されるため、Prometheus にこのネームスペースを監視するよう構成する必要があります。上記の例では、異なる *NilUsesHelmValues パラメータを false に設定することでこれが達成されます。
|
LINSTOR用のPrometheus監視とアラートルールのデプロイメント
Prometheus Operatorのデプロイメントを作成し、すべての名前空間を監視するように構成した後、LINSTOR用の監視およびアラートリソースを適用してください。これは、kustomize または helm ユーティリティを使用して行うことができます。
デプロイメントにKustomizeを使用して、Prometheusの監視とアラートルールを展開する方法
kustomize ユーティリティを使用してLINSTOR用のPrometheus監視とアラートルールをデプロイするには、LINBITがGitHubでホストしている kustomization 構成を適用できます。次のコマンドを入力してください：
# kubectl apply -k \ "https://github.com/linbit/linstor-operator-builder//config/monitoring?ref=v2"
|
KubernetesでのLINSTORデプロイメントにSSL/TLSを設定している場合、監視構成の異なるバージョンを適用する必要があります。 これは、次のコマンドを入力することで行うことができます: kubectl apply -k \ "https://github.com/linbit/linstor-operator-builder//config/monitoring-with-api-tls?ref=v2" |
デプロイメントに監視構成を適用した結果、次の内容が表示されるはずです:
configmap/linbit-sds-dashboard created podmonitor.monitoring.coreos.com/linstor-satellite created prometheusrule.monitoring.coreos.com/linbit-sds created servicemonitor.monitoring.coreos.com/linstor-controller created
Helmを使用してPrometheusモニタリングおよびアラートルールをデプロイ
Helmを使用している場合、linbit-sds チャートで監視を有効にすることで、KubernetesデプロイメントにPrometheusモニタリングをデプロイできます。次のコマンドは、Prometheusモニタリング付きの新しいLINSTORをKubernetesデプロイメントにインストールし、または既存のHelmでインストールされたデプロイメントをアップグレードしてPrometheusモニタリングを有効にします:
# helm repo update linstor && \ helm upgrade --install linbit-sds linstor/linbit-sds \ --set monitoring.enabled=true
kustomize デプロイメント方法とは異なり、通常のそしてSSL/TLS対応のLINSTORデプロイメントに対して同じ helm upgrade --install コマンドを使用することができます。Helmデプロイメントは自動で正しいエンドポイントを設定します。
|
上記コマンドの出力には、linbit-sds チャートが正常にデプロイされたことが表示されるはずです。
監視デプロイメントの検証
デプロイメント内で監視構成が機能していることを確認するには、ローカルのPrometheus、Alertmanager、およびGrafanaのウェブコンソールをチェックすることができます。
プロメテウスWebコンソールデプロイメントの検証
最初に、Prometheusウェブコンソールにアクセスするために、Prometheusウェブコンソールサービスをローカルポート9090に転送してください。:
# kubectl port-forward -n monitoring services/prometheus-kube-prometheus-prometheus 9090:9090
もし localhost 以外のシステムからPrometheusインスタンスにアクセスする必要がある場合は、前述のコマンドに --address 0.0.0.0 引数を追加する必要があるかもしれません。
|
次に、Webブラウザで http://localhost:9090/graph を開き、 linstor_info と drbd_version のメトリクスを表示してください。例えば、それぞれのメトリクスを検索フィールドに入力して、実行ボタンをクリックします。
linstor_info Prometheusメトリック
drbd_version Prometheus メトリックプロメテウス・アラートマネージャーのWebコンソールデプロイメントを検証
以下のコマンドを入力して、Prometheus Alertmanagerサービスをローカルポート9093にフォワードし、Alertmanagerコンソールを表示:
# kubectl port-forward -n monitoring services/prometheus-kube-prometheus-alertmanager 9093:9093
Prometheus Alertmanagerインスタンスに localhost 以外からアクセスする必要がある場合は、前のコマンドに --address 0.0.0.0 引数を追加する必要があるかもしれません。
|
次に、ウェブブラウザーで http://localhost:9093 を開いてください。Alertmanagerコンソールでは、デプロイメント用のアラートグループの項目付きリストが表示されます。その中には linbit-sds ネームスペース用のアラートグループも含まれています。
アラートが発生し、Alertmanagerコンソールに表示されることを確認できます。テストしたいアラートに適用可能なイベントを引き起こすコマンドを実行することで。たとえば、DRBDリソースを切断することができます。これにより、 drbdResourceSuspended アラートが発生します。これをテストするために、linbit-sds ネームスペースで実行されている名前が kube-0 であるLINSTORサテライトポッドを持っていると仮定し、サテライトが my-res というDRBDリソースのセカンダリロールにある場合、次のコマンドを入力してください：
# kubectl exec -it -n linbit-sds kube-0 -- drbdadm disconnect --force my-res
アラートをテストする際に使用するイベントのタイプには注意してください、特に本番システムで。上記の drbdadm disconnect コマンドは、切断するリソースのセカンダリロールを持つサテライトノードポッドで実行する場合は安全です。サテライトノードポッドがどのリソースロール状態にあるかは、drbdadm status <resource-name> コマンドを使用して確認できます。
|
my-res DRBDリソースが切断状態にある際のアラートPrometheus Alertmanagerのウェブコンソールが、あなたが引き起こしたイベントに関連する新しいアラートを表示していることを確認した後、デプロイメントを以前の状態に戻す必要があります。前述の drbdadm disconnect の例については、次のコマンドを入力してください:
# kubectl exec -it -n linbit-sds kube-0 -- drbdadm connect my-res
kube-0 サテライトノードポッドが my-res DRBD リソースに再度接続されていることを、drbdadm status コマンドを入力して確認できます:
# kubectl exec -it -n linbit-sds kube-0 -- drbdadm status my-res
コマンドの出力は、リソースがディスクがいっぱいで、かつ接続されたすべてのノードで最新の状態であることを示す必要があります。
my-res role:Secondary
disk:UpToDate
kube-1 role:Secondary
peer-disk:Diskless
kube-2 role:Secondary
peer-disk:UpToDate
Grafana WebコンソールとLINBIT SDSダッシュボードのデプロイメントを検証
GrafanaコンソールとLINBIT SDSダッシュボードを表示するには、まずGrafanaサービスをローカルポート3000に転送し、次のコマンドを入力します:
# kubectl port-forward -n monitoring services/prometheus-grafana 3000:http-web
localhost 以外のシステムからGrafanaインスタンスにアクセスする必要がある場合は、前のコマンドに --address 0.0.0.0 引数を追加する必要があります。
|
次に、Webブラウザを開いて http://localhost:3000 にアクセスしてログインしてください。もし前述の例でデプロイメントを使用している場合は、ユーザー名を admin 、パスワードを prom-operator としてGrafanaインスタンスにログインしてください。ログインしたら、デフォルトパスワード以外のパスワードに変更してください（http://192.168.121.20:3000/profile/password）。
提供されているダッシュボード (http://localhost:3000/dashboards) から “LINBIT SDS” を選択し、LINSTORデプロイメントの健康状態の概要、さまざまなメトリクスや統計を表示してください。
5.17.2. Operator v1 デプロイメントでの Prometheusによるモニタリング
Operator v1デプロイメントでは、オペレーターは既存のコンポーネントに沿ってモニタリングコンテナをセットアップし、それらを Service として利用可能にします。
Prometheus Operator を使用する場合、Linstor オペレーターは ServiceMonitor インスタンスも設定します。 Piraeus 名前空間が有効 と仮定して、メトリックはオペレーターに関連付けられた Prometheus インスタンスによって自動的に収集されます。
メトリックのエクスポートを無効にするには operator.satelliteSet.monitoringImage を空の値に設定します。
Operator v1 デプロイメントにおける LINSTOR コントローラーのモニタリング
LINSTORコントローラーはクラスタ全体のメトリクスをエクスポートします。 メトリクスは既存のコントローラーサービスでエクスポートされ、パス /metrics を使用しています。
Operator v1 デプロイでの DRBD リソースの監視
すべてのサテライトは drbd-reactor を使用して DRBD から直接メトリックをエクスポートするセカンダリコンテナにバンドルされています。メトリックはポート 9942 で、ヘッドレスサービス <linstorsatelliteset-name>-monitoring という名前で提供されています。
LinstorSatelliteSet リソース内で、監視コンテナを無効にする場合は、monitoringImage を \"\" に設定してください。
5.18. Kubernetes での LINSTOR デプロイメントのアップグレード
KubernetesでのLINSTORデプロイメントは新しいリリースにアップグレードすることが可能です。同様に、Kubernetesでの既存のLINSTOR Operator v1デプロイメントをOperator v2デプロイメントにアップグレードすることも可能です。
| アップグレードプロセス中は、ボリュームのアタッチ、デタッチ、またはプロビジョニングが一時停止されます。既存のボリュームや既にポッドで使用されているボリュームは引き続き機能します。 |
5.18.1. LINSTOR Operator v2 へのアップグレード
LINSTORをOperator v2を使用してデプロイした場合、LINBIT SDSをアップグレードするには、新しいバージョンのLINSTOR Operatorをデプロイすることができます。
| アップグレードプロセス中、LINSTORのサテライトポッドが再起動します。これにより、DRBDデバイスのレプリケーションが停止し、サテライトポッドが再度オンラインになるまでボリュームへの書き込みが一時停止します。 |
LINBIT SDSのアップグレード方法は、元のデプロイメント方法によって異なります。
kustomize を使用してLINSTOR Operator v2をアップグレード:
LINBIT SDSを kustomize を使用してデプロイメントした場合、kustomization.yaml ファイル内のリソースリンクを変更して新しいLINSTOR Operatorバージョンにアップグレードしてください。
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: linbit-sds
resources:
- https://charts.linstor.io/static/v2.10.0.yaml (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"}}} (2)| 1 | リンクから最新のリリースマニフェストに置き換えてください: charts.linstor.io |
| 2 | MY_LINBIT_USER と MY_LINBIT_PASSWORD を、あなたの my.linbit.com の認証情報で置き換えてください。 |
次の kubectl コマンドを使用して kustomization.yaml ファイルを適用し、アップグレードが完了するのを待ちます:
$ kubectl apply -k . namespace/linbit-sds applied [...] $ kubectl -n linbit-sds wait pod --for=condition=Ready --all pod/linstor-operator-controller-manager-6d9847d857-zc985 condition met [...]
Helmを使用してLINSTOR Operator v2をアップグレード:
Helm を使用してLINBIT SDSをデプロイメントした場合、linstor-operator Helmチャートをアップグレードすることで新しいオペレーター バージョンにアップグレードしてください。
$ helm repo update [...] Update Complete. ⎈Happy Helming!⎈ $ helm install linstor-operator linstor/linstor-operator --wait Release "linstor-operator" has been upgraded. Happy Helming! [...]
5.18.2. LINSTOR Operator v1 のアップグレード
新しいリリースにアップグレードする前に、LINSTORデータベースの最新バックアップがあることを確認してください。LINSTOR Chartにパッケージ化されたetcdデータベースを使用している場合は、 こちら を参照してください。
| LINSTORのetcdデプロイメントを使用したアップグレードでは、etcdが永続ストレージを使用する必要があります。 etcd.persistentVolume.enabled=true を使用してetcdがデプロイされている場合にのみ、これらの手順に従ってください。 |
アップグレードは、次のコンポーネントを新しいバージョンに更新します。
-
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 のステータスセクションにエラーがリストされていないことを確認してください。
5.18.3. LINSTORオペレーターv1からv2へのアップグレード:
既存のKubernetes内のLINBIT SDSデプロイメントを、LINSTOR Operator v1デプロイメントからOperator v2デプロイメントにアップグレードするには、こちらの移行手順に従うことができます。
このアップグレードを行う際に、LINSTORサテライトポッドにアタッチされている既存のストレージボリュームに影響を与えずに行うことが可能です。ただし、Operator v2デプロイメントへのマイグレーション中は、新しいボリュームを作成したり、既存のボリュームをアタッチまたはデタッチすることはできません。新しいデプロイメントを展開するまでです。
5.18.4. 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 データベースのバックアップを手動で作成する必要がある場合は、次の手順に従ってください。
-
現在のコントローラーを停止します。
$ 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=...
5.18.5. 特定のバージョンのアップグレード手順
一部のバージョンでは特別な手順が必要です。以下を参照ください。
v2.1 へのアップグレード
通常、v2.10へのアップグレードに追加の手順は必要ありません。
LINSTOR Affinity ControllerをHelmを使用して個別にインストールしていた場合、それはもう不要です。現在はOperatorがLINBIT SDSの一部としてLINSTOR Affinity Controllerをデプロイします。
v2.9 へのアップグレード
通常、v2.9へのアップグレードに追加の手順は必要ありません。
このバージョンでは、LinstorSatelliteリソースを削除した際のデフォルトの動作が変更されました。オペレーターは、デフォルトでノードの退避を行わなくなりました。代わりに、LINSTOR Satelliteは変更されないままとなります。以前の動作を復元するには、以下のリソースを作成してください。
apiVersion: piraeus.io/v1
kind: LinstorSatelliteConfiguration
metadata:
name: satellite-deletion-policy
spec:
deletionPolicy: EvacuateLINBIT SDSコンポーネントをコントロールプレーンノードでも起動するというデフォルトの動作が変更されました。デフォルトでは、LINBIT SDSは node-role.kubernetes.io/control-plane:NoSchedule または node-role.kubernetes.io/master:NoSchedule のテイントが付与されたノードでは実行されなくなります。以前の動作に戻すには、LinstorClusterリソースに以下の変更を加えてください：
apiVersion: piraeus.io/v1
kind: LinstorCluster
metadata:
name: linstorcluster
spec:
tolerations:
- key: node-role.kubernetes.io/control-plane
effect: NoSchedule
operator: Exists
- key: node-role.kubernetes.io/worker
effect: NoSchedule
operator: Existsv2.7 へのアップグレード
通常は、追加の手順は不要です。
LINSTORサテライトは、ホスト上のLVM構成を自動的に検出するようになりました。サテライトの /etc/lvm/lvm.conf ファイルを対象としたパッチは、調整が必要になる可能性があります。
v2.4 へのアップグレード
追加の手順は必要ありません。
LINSTORサテライトは今やDaemonSetリソースを介して管理されています。satellite`ポッドリソースを対象とする任意のパッチは、自動的に同等のDaemonSetリソースパッチに変換されます。ポッドリストでは、新しい `linstor-satellite 接頭辞を使用してこれらのポッドを見ることができます。
v2.3 へのアップグレード
バージョンv2.3では、デフォルトのデプロイメントから NetworkPolicy リソースが削除されました。既存の NetworkPolicy リソースをクリーンアップするには、次のコマンドを実行してください:
$ kubectl delete networkpolicy -n linbit-sds satellite
v2.2 へのアップグレード
バージョンv2.2では、初回のデプロイメントにおいてcert-managerへの依存関係が取り除かれました。既存の Certificate リソースをクリーンアップするには、以下のコマンドを実行してください：
$ kubectl delete certificate -n linbit-sds linstor-operator-serving-cert
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ドライバーのログレベルとワーカースレッドの数を一元的に設定するための新しいオプションが導入されました。これらのオプションが必要な場合は、CRDsを更新する必要があります。Helmはチャートのアップグレード時にCRDsをアップグレードしないため、次のコマンドを入力してください:
$ 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セットアップの仕組みが再構築されました。 オペレーターv1デプロイメントのセキュリティ確保 セクションを参照して、これらの手順をもう一度確認してください。
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ディストリビューションをサポートする新しいオプションが導入されています。顕著な例としてはmicrok8sが挙げられ、/var/snap/microk8s/common/var/lib/kubelet を使用しています。これをサポートするために、LinstorCSIDriver 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
新しい 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はチャートのアップグレード時に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 Operator 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 を手動で削除してください。それらはオペレーターによって再作成されます。
6. Openshift での LINSTOR ボリューム
この章では、LINSTOR® Operatorによって管理され、 LINSTOR CSIプラグイン を使用してプロビジョニングされたボリュームを使用したOpenShiftにおけるLINBIT SDSの使用方法について説明しています。
OpenShift は、Kubernetesの公式Red Hat開発およびサポート配布物です。OpenShiftの価値は、ネットワークイングレスやモニタリングなど通常はオプションのコンポーネントを強力に統合し、それらをWeb UIで管理できるところにあります。LINSTOR Operatorは可能な限りこれらのコンポーネントと統合します。
6.1. Openshift での LINSTOR のデプロイ
OpenShiftへのLINBIT SDSのデプロイは、他のKubernetesクラスタへのLINBIT SDSのデプロイと同様です。前提条件として、以下のものが必要です。
-
ocユーティリティで OpenShift クラスターにアクセスできる。 -
drbd.ioへアクセスするためのLINBIT®顧客ポータルの資格情報。
| The LINBIT container image repository (https://drbd.io) 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 can use the LINSTOR SDS upstream project, named Piraeus, without being a LINBIT customer. |
最初に、LINBIT SDSのための新しいOpenShiftプロジェクトを作成し、LINBIT SDSのデプロイメントのための名前空間も作成します。
$ oc new-project linbit-sds Now using project "linbit-sds" on server ...
次に、kustomization.yaml というファイルを作成して、デプロイメントのデフォルト値をカスタマイズします。
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: linbit-sds
resources:
- https://charts.linstor.io/static/v2.1.1.yaml
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"}}} (1)| 1 | MY_LINBIT_USER と MY_LINBIT_PASSWORD をLINBITのカスタマーポータルの認証情報に置き換えてください。 |
| 上記のYAML構成マニフェストは、執筆時点での最新のものです。必要に応じて、最新バージョンまたは以前のバージョンは https://charts.linstor.io を参照してください。 |
kustomization.yaml ファイルを、好みや必要に応じて追加の変更を加えることができます。可能なオプションについては、 Kubernetes advanced deployment section で議論されています。
最後に、カスタマイズされた構成を適用してLINBIT SDSをデプロイし、kustomization.yaml と同じディレクトリに以下のコマンドを入力して、すべてのポッドが準備完了になるまで待ちます。
$ oc apply -k . && \ oc wait --for=condition=ready pod --all -n linbit-sds --timeout=5m && \ oc get pods -n linbit-sds
出力には、最終的にはLINSTORコントローラーポッドが起動して実行中であることが表示されるはずです。
NAME READY STATUS RESTARTS AGE linstor-operator-controller-manager-59586c7bb5-qlfwb 1/1 Running 0 11s
LINSTORコントローラーポッドをデプロイした後、次のコマンドを入力して、OpenShiftクラスターでLINBIT SDSのデプロイメントを完了してください。
# oc apply -f - <<EOF
apiVersion: piraeus.io/v1
kind: LinstorCluster
metadata:
name: linstorcluster
spec: {}
EOF
# oc wait pod --for=condition=Ready -n linbit-sds --timeout=5m --all
出力は最終的に、あなたのLINBIT SDSクラスターポッドが稼働していることを示すべきです。
NAME READY STATUS RESTARTS AGE ha-controller-6fl6b 1/1 Running 0 60s ha-controller-c955w 1/1 Running 0 60s ha-controller-v4mdr 1/1 Running 0 60s kube-0 2/2 Running 0 56s (1) kube-1 2/2 Running 0 56s (1) kube-2 2/2 Running 0 55s (1) linstor-controller-779bffbc59-6jjzd 1/1 Running 0 61s linstor-csi-controller-8cd45658f-6f9t6 7/7 Running 0 61s linstor-csi-node-blgk8 3/3 Running 0 61s linstor-csi-node-mn8p6 3/3 Running 0 61s linstor-csi-node-pncpz 3/3 Running 0 61s linstor-operator-controller-manager-59586c7bb5-qlfwb 1/1 Running 0 4m2s
| 1 | これらのポッドはLINSTORサテライトノードのポッドです。ポッド名は各ノードのホスト名を反映しています。 |
6.1.2. LINBIT GUIアクセスの設定
LINSTORコンテナイメージには、LINBIT GUIがプリインストールされています。これをクラスタ上で公開するには、OpenShift Routeリソースを設定します。
$ oc create route edge --service linstor-controller $ oc get route NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD linstor-controller linstor-controller-linbit-sds.apps.example.com linstor-controller api edge None
GUI は https://linstor-controller-linbit-sds.apps.oc.example.com/ui/ でアクセスできるようになりました。
| これにより、LINBIT GUIとLINSTOR APIへの外部アクセスが可能になるかもしれません。デプロイメントにおいて、たとえば、ルートにクライアント側TLS証明書を要求することで、認証されたユーザーのみがアクセスできるようにしてください。 |
6.1.3. クラスタモニタリングの設定
OpenShift には、完全に構成されたモニタリングスタックが含まれています。モニタリングスタックのほとんどはOpenStackインフラストラクチャ専用ですが、LINBIT SDSの基本的なモニタリングが可能です。
まず、 Red Hatドキュメント の手順に従って、OpenShiftでユーザー定義プロジェクトの監視が有効になっていることを確認します。
ユーザー定義プロジェクトの監視が有効になると、LINSTOR Operator は自動的にOpenShiftのPrometheusベースの監視スタックの存在を検出し、ServiceMonitor リソースを構成します。Prometheus インスタンスは、すべてのクラスターノードから DRBD® と LINSTOR のメトリクスをスクレイプします。
6.2. OpenShiftでLINBIT SDS 連携
LINSTOR Controller podにはLINSTOR Clientが含まれており、LINSTORの対話型モードに簡単にアクセスすることができます。例えば:
$ oc exec -it deployment/linstor-controller -- linstor interactive LINSTOR ==> ...
This should only be necessary for investigating problems and accessing advanced functionality. Regular operation such as creating volumes should be achieved through the Kubernetes integration.
7. NomadのLINSTORボリューム
この章では、LINSTORとDRBDを使用してNomadでボリュームをプロビジョニングする方法について説明します。
7.1. Nomad の紹介
Nomad は、コンテナとコンテナ化されていないアプリケーションをオンプレミスとクラウド上にデプロイして管理するための、シンプルで柔軟性のあるワークロードオーケストレーターです。
Nomad は Container Storage Interface(CSI) に準拠した plug-ins 経由のストレージボリュームのプロビジョニングをサポートします。
LINBIT® distributes a CSI plugin in the form of container images from drbd.io. The plugin can be configured to work with a LINSTOR cluster that is deployed along or inside a Nomad cluster.
| The LINBIT container image repository (https://drbd.io) 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. |
7.2. NomadにLINSTORの展開
この項では、Nomadで新しいLINSTORクラスタを展開および設定する方法について説明します。
| LINSTORをノードに直接インストールする場合は、 LINSTOR のインストール を参照してください。このセクションをスキップして、 CSI ドライバのデプロイ に直接移動できます。 |
7.2.1. Nomadを準備する
LINSTORを実行するには、すべてのNomadエージェントを次のように設定する必要があります。
-
docker driverをサポートし、特権コンテナの実行を許可します。
特権コンテナーの実行を許可するには、以下のスニペットをNomadエージェント構成に追加して、Nomadを再起動します。
Listing 15. /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 16. /etc/nomad.d/host-volume-dev.hclclient { host_volume "dev" { path = "/dev" } }
7.2.2. LINSTORコントローラジョブの作成
LINSTOR コントローラは、レプリカのないサービスとして導入されます。どの時点においても、1つのクラスタ内で実行可能なLINSTOR コントローラは1つのみです。データベースへのアクセス権がある場合は、新しいノードでコントローラを再起動できます。詳細は 高可用性 LINSTOR クラスターの作成 を参照してください。
次の例では、データセンター dc1 で単一のLINSTORコントローラを起動するNomadジョブを作成し、外部データベースに接続します。
linstor-controller.hcljob "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 | This sets the LINSTOR Controller image to run. The latest images are available from 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を再起動します。
/etc/nomad.d/host-volume-linstor-db.hclclient {
host_volume "linstor-db" {
path = "/var/lib/linstor"
}
}次に、上記の例の linstor-controller.hcl に次のスニペットを追加し、構成テンプレートの connection_url オプションを変更します。
job > groupvolume "linstor-db" {
type = "host"
source = "linstor-db"
}job > group > taskvolume_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
}7.2.3. LINSTOR サテライトジョブの作成
Nomad で LINSTORサテライトは、Nomadのシステムジョブとしてデプロイされ、特権コンテナー内で実行されます。サテライトに加えて、このジョブはLINSTORで使用される他のカーネルモジュールとともにDRBDモジュールもロードします。
次の例では、Nomadジョブを作成して、データセンター dc1 のすべてのノードでLINSTORサテライトを開始します。
linstor-satellite.hcljob "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 | This sets the LINSTOR Satellite image to run. The latest images are available from drbd.io. The satellite image version has to match the version of the controller image.
|
||
| 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 22.
/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"7.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|
LINSTOR を LVM および DRBD と一緒に使用する場合、LVM グローバル設定ファイル (RHEL では global_filter = [ "r|^/dev/drbd|", "r|^/dev/mapper/[lL]instor|" ] This setting tells LVM to reject DRBD and other devices created or set up by LINSTOR from operations such as scanning or opening attempts. In some cases, not setting this filter might lead to increased CPU load or stuck LVM operations. |
CSIドライバでは、サテライトにホスト名に基づいた名前を付ける必要があります。正確に言うと、サテライト名はノードのNomads attr.unique.hostname 属性と一致する必要があります。
|
7.3. LINSTOR CSIドライバのNomadへの配備
CSIドライバはシステムジョブとしてデプロイされます。つまり、クラスタ内のすべてのノードで実行されます。
次の例では、データセンター dc1 内のすべてのノードでLINSTOR CSIドライバを起動するNomadジョブを作成します。
linstor-csi.hcljob "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 | This sets the LINSTOR CSI Driver image to run. The latest images are available from 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"7.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`コマンドを入力することで、Nomadボリュームの作成時に新しいLINSTORリソースが作成されたことを確認することもできます。
出力は以下のようになります。
╭──────────────────────────────────────────────────────────────────────────────────────────────╮
┊ 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 ┊
╰──────────────────────────────────────────────────────────────────────────────────────────────╯7.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"
}
...
}
}
}7.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 vol28. Proxmox VE での LINSTOR ボリューム
この章では、 LINSTOR Proxmox Plugin を使用して、Proxmox Virtual Environment（VE）にLINSTOR®とDRBD®を統合する方法について説明します。この章のセクションでは、LINSTOR Proxmoxプラグインの インストール, 設定, および アップグレード の方法について説明します。
8.1. Proxmox VE の紹介
Proxmox VE is an easy to use, complete server virtualization environment with KVM, Linux Containers, and high availability (HA).
linstor-proxmox は、LINSTORと連携してProxmoxで使用するストレージプラグインであり、クラスタ内の複数のProxmox VEノード間で仮想ディスクイメージやコンテナボリュームをDRBDでバックアップしながら複製することができます。LINSTORをProxmoxに統合することで、集中型SANを必要とせずに、ダウンタイムなしでアクティブなVMを数秒でライブマイグレーションすることが可能です。また、LINSTORはProxmoxで 高可用性 などの共有ストレージ機能も提供します。
8.2. LINSTOR Proxmox プラグインのインストール
このセクションでは、LINSTOR Proxmoxプラグインのインストール方法について説明します。プラグインを既にインストールしており、新しいバージョンにアップグレードする必要がある場合は、 LINSTOR Proxmox プラグインのアップグレード セクションを参照してください。
8.2.1. Proxmox VE カーネル ヘッダーのインストール
ProxmoxでLINSTORを使用するには、DRBDカーネルモジュールをインストールする必要があります。DRBD 9カーネルモジュールはカーネルモジュールソースパッケージ（ drbd-dkms ）としてインストールされます。したがって、LINBIT®リポジトリからDRBDカーネルモジュールをインストールする前に、Proxmox VEカーネルヘッダーパッケージである proxmox-default-headers をインストールする必要があります。この手順に従うことで、カーネルモジュールがお使いのカーネル向けに正しくビルドされます。
最新のProxmoxカーネルをインストールする予定がない場合は、現在実行中のカーネルに一致するカーネルヘッダーをインストールする必要があります（たとえば、proxmox-headers-$(uname -r)）。この手順を行わなかった場合や既に異なるカーネルヘッダーをインストールしてしまった場合は、apt install --reinstall drbd-dkms コマンドを入力して、drbd-dkms パッケージを現在のカーネルに対して再構築することができます。
Proxmoxの pve-enterprise または pve-no-subscription リポジトリをAPTソースリスト /etc/apt/sources.list に設定し、apt update を入力してから proxmox-headers-$(uname -r) パッケージをインストールする必要があります。手順については、 Proxmox wiki を参照してください。
|
8.2.2. Proxmox用にLINBIT顧客リポジトリを構成する
もしLINBITの顧客であるか、評価アカウントをお持ちの場合、LINBITの drbd-9 リポジトリをノードに有効化し、apt update コマンドを使用してリポジトリを更新することができます。
| ノードを LINBIT に登録し、LINBIT リポジトリを有効にする手順については LINBIT クラスターノードを管理するスクリプトの使用 を参照してください。 |
8.2.3. ProxmoxのためのLINBIT公式リポジトリの設定
Proxmox VE No-Subscriptionリポジトリをご存知であれば、LINBITもProxmox VEで使用するための公開リポジトリを提供しています。このリポジトリには、LINSTOR Proxmoxプラグインだけでなく、DRBD、LINSTOR、およびすべてのユーザ空間ユーティリティを含むLINBIT SDSスタック全体が含まれています。
| これはホームラボ、テスト、および非プロダクション利用には素晴らしいオプションとなりますが、LINBITはこれらのパッケージを顧客リポジトリと同じ厳格な基準でメンテナンスしていません。本番環境のデプロイメントには、公式LINBIT顧客リポジトリの使用が推奨されています。 |
以下のコマンドを入力することで、LINBITの公開リポジトリを追加できます。
# wget -O /tmp/linbit-keyring.deb \ https://packages.linbit.com/public/linbit-keyring.deb # dpkg -i /tmp/linbit-keyring.deb # source /etc/os-release && PVERS=$(( VERSION_ID - 4 )) # echo "deb [signed-by=/etc/apt/trusted.gpg.d/linbit-keyring.gpg] \ https://packages.linbit.com/public/ proxmox-$PVERS drbd-9" > /etc/apt/sources.list.d/linbit.list # apt update
| Proxmoxのバージョンは、Debian（ProxmoxのベースOS）のバージョンから4を引いたものになります。 |
8.3. LINSTOR の構成
The rest of this guide assumes that you have a LINSTOR cluster configured as described in クラスタの初期化. Start the linstor-controller service on one node, and the linstor-satellite service on all nodes.
バージョン4.1.0からのプラグインの推奨使用方法は、LINSTORリソースグループと、それぞれのリソースグループ内に1つのボリュームグループを介して行うことです。LINSTORリソースグループについては、 リソースグループを使用した LINSTOR プロビジョニングされたボリュームのデプロイ で説明されています。たとえば、データ複製数など、すべての必須のLINSTOR設定はリソースグループに設定する必要があります。
|
LINSTORをLVMとDRBDと一緒に使用する場合、LVMのグローバル設定ファイル（ global_filter = [ "r|^/dev/drbd|", "r|^/dev/mapper/[lL]instor|" ] This setting tells LVM to reject DRBD and other devices created or set up by LINSTOR from operations such as scanning or opening attempts. In some cases, not setting this filter might lead to increased CPU load or stuck LVM operations. |
8.4. Proxmoxプラグインの設定
最後のステップは、Proxmox自体の構成を提供することです。これは、/etc/pve/storage.cfg ファイルに以下のような内容を持つエントリを追加することで行うことができます。
drbd: drbdstorage resourcegroup defaultpool content images,rootdir controller 10.11.12.13
| Proxmoxのストレージ設定ファイル内のストレージエントリは、必ず空行で区切らなければなりません。 |
drbd エントリは固定されています。これはProxmoxにDRBDをストレージバックエンドとして使用するように指示するため、変更は許可されません。ただし、drbd エントリの値である drbdstorage は自由に変更できます。これはPVE web GUIでDRBDストレージを特定するために表示されるフレンドリーな名前として使用されます。
content エントリも修正済みなので、変更しないでください。 バッキングLINSTORリソースグループに対する 配置数 を指定することで、データの冗長性を構成できます。 これにより、データのレプリカがクラスタ内にいくつ保存されるかを指定できます。 セットアップに応じて、配置数オプションを2つまたは3つに設定することをお勧めします。 DRBDディスクレスアタッチメント機能により、データはすべてのノードからアクセスできます。たとえ一部のノードがデータのローカルコピーを持っていなくてもです。 例えば、5ノードクラスタでは、どこに保存されているかに関係なく、全ノードがデータの3つのコピーにアクセスできます。
controller パラメータは、LINSTORコントローラーサービスを実行しているノードのIPに設定する必要があります。クラスタ内のノードはいつも1つだけLINSTORコントローラーサービスを実行できます。そのノードが故障した場合、別のノードでLINSTORコントローラーサービスを開始し、controller パラメータの値を新しいノードのIPアドレスに変更する必要があります。また、 LINSTORコントローラー自体を高可用性 にすることも可能です。クラスタ内でLINSTORコントローラーを高可用性にすることで、controller パラメータに複数のIPアドレスを指定するか、LINSTORコントローラーの仮想IPアドレスを指定するオプションがあります。
resourcegroup パラメーターは、Proxmox内のDRBDバックエンドストレージに関連付けたいLINSTORリソースグループの名前を指定します。
8.4.1. Proxmoxで使用する複数のLINSTORリソースグループを構成する
異なるストレージプールに関連付けられた異なるリソースグループを使用する構成は、次のように見えるかもしれません:
drbd: drbdstorage resourcegroup defaultpool content images,rootdir controller 10.11.12.13 drbd: fastdrbd resourcegroup ssd content images,rootdir controller 10.11.12.13 drbd: slowdrbd resourcegroup backup content images,rootdir controller 10.11.12.13
この構成を行った後、Proxmox web GUIを使用して、”drbdstorage“を選択することで、または他の定義済みのプールである”fastdrbd“や”slowdrbd“をストレージ場所として選択することで、VMを作成することができます。
プラグインのバージョン5以降、`preferlocal`オプションを`yes`または`no`に設定できるようになりました。デフォルトでは、このオプションは`yes`に設定されています。`preferlocal yes`オプションが設定されている場合、プラグインはストレージ作成コマンドを発行したノード上にdiskfulなアサインメントを作成しようと試みます。このデフォルト設定により、可能な限りVMがローカルストレージを使用できるようになります。
このオプションを no に設定すると、VMが最初にノード ‘A’ で起動される一方で、LINSTORはストレージをノード ‘B’ や ‘C’ に配置する可能性があります。ノード ‘A’ にはディスクレス（diskless）の割り当てが行われるため、これでも動作はしますが、ほとんどの場合、ローカルの高速なストレージを利用することが好まれるため、デフォルト設定は yes になっています。
この時点で、VMをライブマイグレーションしようとすることができます。すべてのデータがすべてのノードでアクセス可能であり、ディスクのないノードでも、わずか数秒で完了します。VMが負荷の下にある場合や、常に大量のRAMが汚れている場合、全体のプロセスには少し時間がかかるかもしれません。しかし、いずれの場合も、ダウンタイムは最小限に抑えられ、操作上の中断は一切ないはずです。
| オプション | 意味 |
|---|---|
|
LINSTOR コントローラの IP（カンマ区切りのリストが可能） |
|
新しい VM のデプロイを定義する LINSTOR リソースグループの名前。上記の説明通り |
|
ローカルストレージの作成を優先するかどうか（yes/no）。上記の説明通り |
|
ステータス情報をキャッシュする時間（秒単位）。0 は追加のキャッシュなしを意味します。数百のリソースを持つ大規模なクラスターに関連します。有効にするには、 |
|
LVM などの外部ストレージから DRBD/LINSTOR へのストレージマイグレーションを許可するために、これを一時的に |
|
クライアント証明書へのパス |
|
クライアントの秘密鍵へのパス |
|
CA 証明書へのパス |
8.5. Proxmoxで高可用性のあるLINSTORコントローラーを構成する
LINSTORの高可用性を実現するには、LINSTORコントローラーを高可用性にすることが重要です。 これについては、 高可用性 LINSTOR クラスターの作成 で説明されています。 これは、ProxmoxとのLINSTOR統合をより障害耐性のあるものにすることができるオプションの構成です。
リンクされたセクションの手順を完了した後、最後であり重要なステップは、Proxmoxプラグインを構成して異なるLINSTORコントローラに接続できるようにすることです。プラグインは最初に回答を受け取ったコントローラを使用します。Proxmoxで異なるLINSTORコントローラを構成するには、プラグインの controller セクションにコントローラノードのIPアドレスのカンマ区切りリストを追加することで設定します。例えば、:
drbd: drbdstorage resourcegroup defaultpool content images,rootdir controller 10.11.12.13,10.11.12.14,10.11.12.15
別の方法として、OCFリソースエージェントである ocf:heartbeat:IPaddr2 を使用して、DRBD Reactorのプロモータープラグインのサービス開始リストに追加することで、LINSTORコントローラー用の仮想IP（VIP）アドレスを構成することがあります。これを行うと、controller パラメーターの値としてそのVIPアドレスを指定できます。
8.6. Cloud-init イメージの保存場所
Cloud-init VM イメージはわずか数MBのサイズで、Proxmox は必要に応じてそれらを生成できます。これは、cloud-init イメージに保存された設定が Proxmox そのものにクラスタ全体で保存されているため可能となります。これにより、Proxmox はローカルストレージ（例えば、LVM）をそのようなイメージに使用できます。クラウドイメージが存在しないノードで VM が起動されると、保存された設定からそのクラウドイメージが生成されます。
DRBDストレージにcloud-initイメージを保存することもできますが、それは利益にはつながりません。cloud-initイメージをローカルストレージに保存することで十分です。
8.7. Proxmoxにおける仮想マシンイメージの命名とLINSTOR
LINSTOR Proxmoxプラグインのバージョン8から、VMディスクイメージの名前はPVE内では pm-12cf742a_101 のようになり、LINSTORとDRBD内では pm-12cf742a のようになります。これは静的なプレフィックス (pm-)、UUIDの8文字、そしてPVEレベルではアンダースコア (_101) で区切られたVMIDが含まれます。以前のプラグインのバージョンでは、VMディスクイメージの名前は vm-101-disk-1 のようでした。プラグインをバージョン8以降にアップグレードすると、以前の命名スキームを使用しているVMをクローンした場合、クローンされたディスクイメージはバージョン8の命名スキームになります。
8.8. ProxmoxのストレージをLINSTORを使ってDRBDに移行する方法
時には、既存のProxmoxデータをDRBDバックアップストレージに移行したい場合があります。このセクションでは、これを行うために必要な手順について詳しく説明します。たとえば、既存のLVMやZFSバックアップProxmoxデータを移行する場合などです。既にProxmoxデータがDRBDバックアップストレージにある場合は、これらの手順は不要です。例えば、VMを1つのDRBDバックアップストレージから別のDRBDバックアップストレージにライブ移行する場合などです。
| これらの指示では、LINSTOR Proxmoxプラグインのバージョン8以上が必要です。 |
Proxmox VMがオンラインの状態で、VMディスクイメージなどのデータを移行したい場合は、特定のDRBDストレージ向けに /etc/pve/storage.cfg ストレージ設定ファイルで exactsize yes を 一時的 に設定し、非DRBDバックアップストレージからDRBDバックアップストレージにディスクを移行できます。作業が完了したら、storage.cfg 設定ファイルから exactsize オプションを削除してください。exactsize オプションが有効にしたLINSTORプロパティは、ディスクが再度アクティブ化された際に削除されます（ただし、ディスクが現在アクティブな場合は削除されません）。移行後にすべてのアクティブなディスクからプロパティを削除したい場合、または余分な安全策を取りたい場合は、以下のようなコマンドを実行できます：
# linstor -m --output-version v1 rd l | \
jq '.[][].name' | \
xargs -I {} linstor rd sp {} DrbdOptions/ExactSize False
8.9. LINSTOR Proxmox プラグインのアップグレード
このセクションでは、既存の linstor-proxmox プラグインのインストールをアップグレードする際に注意すべき変更や必要なアクションについて説明します。
新規インストールを行う必要がある場合は、このセクションをスキップし、 LINSTOR Proxmox プラグインのインストール を続行してください。
8.9.1. プラグイン バージョン 8.x へのアップグレード
このプラグインのバージョンアップには、LINSTOR 1.27.0以上が必要です。
このLINSTOR Proxmoxプラグインのこのバージョンでは、LINSTORとDRBDバックエンドストレージで作成されたVMイメージの新しい命名スキームが導入されました。旧バージョンのプラグインからの既存のVMは、プラグインのバージョン8でも引き続き動作します。命名スキームの変更には、ユーザーが新しい命名スキームに慣れること以外に、ユーザーの介入は必要ありません。
名前付け方に関する詳細は、 Proxmoxにおける仮想マシンイメージの命名とLINSTOR で確認できます。
プラグインのバージョン8までは、外部ストレージ（例:LVM）からLINSTORおよびDRBDバックエンドストレージへのデータ（例:VMディスクイメージ）の移行はオフラインでのみ可能でした。プラグインのバージョン8からは、データをオンラインで移行できます。詳細については、 ProxmoxのストレージをLINSTORを使ってDRBDに移行する方法 を参照してください。
8.9.2. プラグインバージョン 7.x へのアップグレード
プラグインのバージョン7では、LINSTORコントローラAPIを使用しており、LINSTORバージョン1.21.1以降から利用可能です。LINSTORのセットアップ（コントローラーとサテライト）が少なくともそのバージョンを使用していることを確認してください。
8.9.3. プラグインのバージョンを4.xから5.xへアップグレードする
プラグインのバージョン5では、従来の構成オプションである storagepool と redundancy との互換性がなくなります。バージョン5では 必ず resourcegroup オプションが必要であり、明らかにLINSTORリソースグループも必要です。古いオプションは構成から削除されるべきです。
LINSTORの設定方法は、セクション LINSTOR の構成 に記載されており、典型的な例が続きます。次の例では、storagepool が mypool に設定され、 redundancy が3に設定されていると仮定されています。
# linstor resource-group create --storage-pool=mypool --place-count=3 drbdMypoolThree # linstor volume-group create drbdMypoolThree
次に、Proxmoxのストレージ設定ファイル /etc/pve/storage.cfg を編集します。LINSTOR管理（およびDRBDレプリケーション）ストレージのエントリを追加し、環境に合わせて設定値を変更してください。
drbd: drbdstorage resourcegroup drbdMypoolThree content images,rootdir controller 10.11.12.13
| Proxmoxのストレージ設定ファイル内では、ストレージエントリは必ず空行で区切らなければなりません。 |
8.9.4. プラグインのバージョンを 5.x から 6.x にアップグレードする
プラグインのバージョン6.0.0では、redundancy 設定に関連するすべてのコードを削除しました。この設定は非常に長い間LINSTORのリソースグループ(resourcegroup 設定)によって処理されています。変更は必要ありません。
LINSTOR によって管理される VM で LINSTOR コントローラを実行するための controllervm 設定はなくなりました。 drbd-reactor を使用して高可用性 LINSTOR コントローラを実現することをお勧めします。
設定 statuscache と preferlocal がデフォルトで有効になりました。
9. OpenNebulaのLINSTORボリューム
この章では、 LINSTOR® ストレージドライバーアドオン を使用したOpenNebulaにおけるDRBD®について説明します。
詳しいインストールと設定の手順は、ドライバのソースの README.md を参照ください。
9.1. OpenNebula の紹介
OpenNebula is a flexible and open source cloud management platform which allows its functionality to be extended using add-ons.
LINSTOR アドオンを使用すると、DRBD によってバックアップされ、DRBD プロトコルを介してネットワークに接続された高可用性イメージを持つ仮想マシンを配備できます。
9.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 ストレージプールを必要としません [2] 。
9.3. 配備オプション
LINSTOR リソースグループ リソースグループの作成 を使用して構成することをお勧めします。以前の自動配置およびデプロイメントノードモードは非推奨です。
9.4. OpenNebula アドオンの構成
OpenNebula LINSTORアドオンの設定手順は次の通りです:
-
OpenNebulaの設定にOpenNebula LINSTOR ドライバを追加する
-
クラスターノードの構成:
-
oneadminユーザーの正しい権限を設定する: -
LINSTOR OpenNebulaイメージデータストアの作成:
-
ストレージリソースをデプロイするためのLINSTORリソースグループを作成します。
-
オプションのLINSTORプラグイン属性の設定:
-
LINSTORをOpenNebulaシステムのデータストアとして構成する:
9.5. 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"
]
DATASTORE_MAD 引数設定で ‘linstor’ を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 サービスを再起動します。
9.5.1. ノードの構成
フロントエンドノードは、LINSTOR を介してストレージノードおよびホストノードにコマンドを発行します。
ストレージノードは、VM のディスクイメージをローカルに保持します。
ホストノードは、インスタンス化された VM の実行を担当し、通常、必要なイメージ用のストレージを LINSTOR ディスクレスモードを介してネットワーク経由で接続します。
すべてのノードに DRBD 9 と LINSTOR がインストールされている必要があります。インストールプロセスの詳細は、https://linbit.com/drbd-user-guide/drbd-guide-9_0-en/#p-build-install-configure[DRBD 9] および LINSTOR のユーザガイドに詳しく説明されています。
両方の役割のすべての要件を満たす限り、フロントエンドノードとホストノードをプライマリロールに加えてストレージノードとして機能させることができます。
フロントエンドノードの構成
フロントエンドノードから通信を行いたいコントロールノードが到達可能であることを確認してください。 linstor node list は、ローカルで実行中のLINSTORコントローラー向けの方法であり、 linstor --controllers "<IP:PORT>" node list は、リモートで実行中のLINSTORコントローラー向けのテスト方法です。
ホストノードの構成
ホストノードは、それらに実行されているLINSTORサテライトプロセスを持ち、フロントエンドおよびストレージノードと同じLINSTORクラスタのメンバーである必要があり、オプションでローカルにストレージを持っていることができます。もし`oneadmin` ユーザがパスワードを使用せずにホスト間でSSH経由で接続できる場合、SSHシステムデータストアでもライブマイグレーションが可能です。
ストレージノードの構成
フロントエンドノードとホストノードのみが OpenNebula のインストールを必要としますが、oneadmin ユーザーはパスワードなしでストレージノードにアクセスできる必要があります。 oneadmin ユーザーアカウントを手動で構成する方法については、ディストリビューションの OpenNebula インストールガイドを参照してください。
ストレージノードは、シンLVMプラグインなどのスナップショットを作成できるドライバーで作成されたストレージプールを使用する必要があります。
|
LINSTOR を LVM および DRBD と一緒に使用する場合、LVM グローバル設定ファイル (RHEL では global_filter = [ "r|^/dev/drbd|", "r|^/dev/mapper/[lL]instor|" ] This setting tells LVM to reject DRBD and other devices created or set up by LINSTOR from operations such as scanning or opening attempts. In some cases, not setting this filter might lead to increased CPU load or stuck LVM operations. |
2つの物理デバイス（ /dev/sdX と /dev/sdY ）が与えられた場合、以下の例は、LVMコマンドを使用して、LINSTORストレージプールまたは複数のプールをバックアップするために、スレンダー・プロビジョニング・ストレージを準備する方法を示しています。この例では、ボリュームグループとスレンダー・プールのための一般的な名前が使用されています。
pvcreate /dev/sdX /dev/sdY vgcreate drbdpool /dev/sdX /dev/sdY lvcreate -l 95%VG --poolmetadatasize 8g -T /dev/drbdpool/drbdthinpool
thin-provisioned logical volume のメタデータスペースを適切なサイズに設定してください。なぜなら、それがいっぱいになるとリサイズが難しくなる可能性があるからです。そのため、LVMのthin-provisioned logical volumesの監視や自動拡張を構成することも検討していただくと良いでしょう。詳細については、man lvmthin の「Size of pool metadata LV」セクションを参照してください。
|
次に、バッキングストレージとして /dev/drbdpool/drbdthinpool デバイスを使用して、LINSTOR ストレージプールまたは複数のストレージプールを作成します。
9.5.2. 管理アカウントの権限
oneadmin 、「クラウド管理者」と呼ばれるユーザーアカウントは、ストレージノード上で mkfs コマンドへのパスワードレス sudo アクセス権を持つ必要があります。
oneadmin ALL=(root) NOPASSWD: /sbin/mkfs
9.5.3. 新しい LINSTOR データストアの作成
ds.conf という名前のデータストア設定ファイルを作成し、 onedatastore ツールを使用して、その設定に基づいて新しいデータストアを作成します。相互に排他的な2つの配備オプション LINSTOR_AUTO_PLACE と LINSTOR_DEPLOYMENT_NODES があります。両方が設定されている場合、LINSTOR_AUTO_PLACE は無視されます。どちらのオプションでも、BRIDGE_LIST は LINSTOR クラスター内のすべてのストレージノードのスペース区切りリストである必要があります。
9.5.4. リソースグループの作成
バージョン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
9.5.5. プラグインの属性
9.5.6. 廃止された属性
次の属性は非推奨であり、バージョン 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 にフォールバックします。
9.5.7. システムデータストアとしての LINSTOR を構成
LINSTOR ドライバーはシステムデータストアとしても使用できます。構成は通常のデータストアとかなり似ていますが、いくつか相違があります。
cat >system_ds.conf <<EOI NAME = linstor_system_datastore TM_MAD = linstor TYPE = SYSTEM_DS DISK_TYPE = BLOCK LINSTOR_RESOURCE_GROUP = "OneSysRscGrp" BRIDGE_LIST = "alice bob charlie" # node names EOI onedatastore create system_ds.conf
COMPATIBLE_SYS_DS に新しいシステムデータストアIDを追加して、イメージデータストア（カンマで区切って）に追加してください。さもないと、スケジューラーはそれらを無視します。
揮発性ディスクを使用したライブマイグレーションが必要な場合は、KVMの --unsafe オプションを有効にする必要があります。https://docs.opennebula.org/5.8/deployment/open_cloud_host_setup/kvm_driver.html を参照してください。
9.7. 空き容量の計算
空き容量は、リソースが自動的に配備されるか、ノードごとに配備されるかに応じて異なって計算されます。
ノードごとに配置されるデータストアでは、リソースが配備されているすべてのノードの最も制限的なストレージプールに基づいて空き領域がレポートされます。たとえば、総ストレージ容量の最小値を持つノードの容量を使用してデータストアの合計サイズを決定し、空き容量が最小のノードを使用してデータストアの残りの容量を決定します。
自動配置を使用するデータストアの場合、サイズと残りの領域は、LINSTORによって報告されたデータストアで使用される集約ストレージプールに基づいて決定されます。
10. OpenStackでのLINSTORボリューム
この章では、LINSTOR®を使用して、OpenStack向けに永続的でレプリケーションされた高性能ブロックストレージをプロビジョニングする方法について説明します。
10.1. OpenStack の紹介
OpenStackは様々な個々のサービスで構成されています；ブロックストレージのプロビジョニングと管理を担当するサービスは、Cinder と呼ばれています。他のOpenStackサービス、例えばコンピュートインスタンスサービス Nova は、Cinderからボリュームをリクエストすることができます。Cinderはその後、リクエストされたサービスにボリュームを利用可能にします。
LINSTOR は、ボリュームドライバーを使用して Cinder と統合できます。ボリュームドライバーは、CinderAPI への呼び出しを LINSTOR コマンドに変換します。例えば Cinderにボリュームを要求すると、LINSTOR に新しいリソースが作成され、Cinder ボリュームのスナップショットは LINSTOR のスナップショットに変換されます。
10.2. OpenStack 用の LINSTOR のインストール
OpenStackドライバーを使用する前に、DRBD®とLINSTORの初期インストールと構成が完了している必要があります。
-
インストールガイドの詳細は こちら を参照ください。また以下も参照ください。
この時点で、LINSTOR クライアントを使用してストレージクラスターノードを一覧表示できるはずです。
$ linstor node list
╭────────────────────────────────────────────────────────────────────────────╮
┊ 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 ┊
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯10.2.1. LINSTOR ドライバをアップグレード
新規インストールの場合、このセクションをスキップして LINSTOR ドライバをインストール に進んでください。
1.x から 2.x へのアップグレード
ドライバーバージョン 2 は、実行時に ボリュームタイプ でこれらのオプションを管理するため、いくつかの静的構成オプションを削除しました。
cinder.conf 内のオプション |
ステータス | 置き換え |
|---|---|---|
|
削除 |
ボリュームタイプの |
|
削除 |
置き換えは不要です。ドライバーは必要に応じて Cinder ホスト上にディスクレスリソースを作成します。 |
|
削除 |
この設定は効果がありませんでした。 |
|
非推奨 |
この設定は将来のバージョンで削除される予定のため非推奨です。代わりにボリュームタイプの |
|
非推奨 |
より適切な名称の |
|
削除 |
ノードおよびストレージプールの作成機能は、ドライバーバージョン 2 で完全に削除されました。OpenStack 用の LINSTOR のインストール を参照してください。 |
|
削除 |
この設定には目的がなく、代替なしで削除されました。 |
10.2.2. LINSTOR ドライバをインストール
OpenStack Stein 以降、LINSTOR ドライバーは Cinder プロジェクトの一部です。ドライバはそのまま使用できますが、新しいバージョンで利用できる機能や修正が不足している可能性があります。安定バージョンの OpenStacks 更新ポリシーにより、ドライバーに対するほとんどの改善は、古い安定リリースにバックポートされません。
LINBIT（R）は、すべての改良がサポートされている安定版にバックポートされた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 |
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/2025.1 with the reference matching your OpenStack release. CINDER_BRANCH=linstor/stable/2025.1 # Resizing of volumes using the DRBD transport requires updates to Nova and os-brick: NOVA_REPO=https://github.com/LINBIT/openstack-nova.git OS_BRICK_REPO=https://github.com/LINBIT/openstack-os-brick.git NOVA_BRANCH=linstor/stable/2025.1 OS_BRICK_BRANCH=linstor/stable/2025.1 LIBS_FROM_GIT=os-brick
Kolla でインストール
Kolla は OpenStack コンポーネントをコンテナーにパッケージ化します。次に、例えば Kolla Ansible を使用してデプロイできます。kolla コンテナーで使用可能なカスタマイズオプションを利用して、LINSTOR ドライバーをセットアップできます。
必要な python-linstor パッケージがインストールされるようにするには、次のオーバーライドファイルを使用します。
{% extends parent_template %}
# Cinder
{% set cinder_base_pip_packages_append = ['python-linstor'] %}
# Nova
# Replace linstor/stable/2025.1 with the reference matching your OpenStack release.
{% set openstack_base_pip_packages_append = ['git+https://github.com/LINBIT/openstack-os-brick.git@linstor/stable/2025.1'] %}
{% block openstack_base_override_upper_constraints %}
RUN {{ macros.upper_constraints_remove("os-brick") }}
{% endblock %}LINBIT バージョンのドライバーをインストールするには kolla-build.conf を更新します。
[cinder-base] type = git location = https://github.com/LINBIT/openstack-cinder.git # Replace linstor/stable/2025.1 with the reference matching your OpenStack release. reference = linstor/stable/2025.1 [nova-base] type = git location = https://github.com/LINBIT/openstack-nova.git # Replace linstor/stable/2025.1 with the reference matching your OpenStack release. reference = linstor/stable/2025.1
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=2025.1
kolla-build -t source --template-override template-override.j2 cinder --registry $REGISTRY --namespace $NAMESPACE --tag $TAGKolla 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-drbdLINSTOR ドライバー構成は 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/2025.1 cinder_user_pip_packages: - python-linstor nova_git_repo: https://github.com/LINBIT/openstack-nova.git nova_git_install_branch: linstor/stable/2025.1 nova_user_pip_packages: - git+https://github.com/LINBIT/openstack-os-brick.git@linstor/stable/2025.1 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/2025.1 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__
10.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 | Deprecated in 2.0.0, use ボリュームタイプ instead. リソース配置時に使用するストレージプール。作成されたすべてのディスクリソースに適用されます。デフォルトは DfltStorPool です。 |
||
| 7 | 2.0.0 で非推奨になったので、代わりに volume types を使用してください。特定のボリュームに対して作成する複製数。値が 0 の場合、すべてのノードに複製が作成されます。デフォルトは 0 です。 |
||
| 8 | 2.0.0 で削除されたため、ボリュームはドライバによってオンデマンドで作成されます。 true に設定されている場合、Cinder コントローラホストに少なくとも 1 つの (ディスクレス) レプリカがデプロイされることを確認します。これはISCSI トランスポートに役立ちます。デフォルトは true です。 |
||
| 9 | ここでは、より一般的な Cinder オプションを指定できます。たとえば、iSCSI コネクタの場合は target_helper = tgtadm です。 |
| 複数の LINSTOR バックエンドを構成して、それぞれに異なる名前と構成オプションを選択することもできます。 |
LINSTOR バックエンドを構成した後、それも有効にする必要があります。これを cinder.conf の有効なバックエンドのリストに追加し、オプションでデフォルトのバックエンドとして設定します。
[DEFAULT] ... default_volume_type = linstor-drbd-volume enabled_backends = lvm,linstor-drbd ...
最後のステップとして、Cinder 構成を変更した場合、またはドライバー自体を更新した場合は、必ず Cinder サービスを再起動してください。サービスを再起動する方法については、OpenStack ディストリビューションのドキュメントを確認してください。
10.3.1. トランスポートプロトコルの選択
Cinder のトランスポートプロトコルは、クライアント（たとえば、nova-compute）が実際のボリュームにアクセスする方法です。LINSTOR を使用すると、異なるトランスポートを使用する 2 つの異なるドライバーを選択できます。
-
cinder.volume.drivers.linstordrv.LinstorDrbdDriver: トランスポートプロトコルとして DRBD を使用 -
cinder.volume.drivers.linstordrv.LinstorIscsiDriver: トランスポートプロトコルとして iSCSI を使用
トランスポートプロトコルとして DRBD を使用
LinstorDrbdDriver は、クライアント（つまり、nova-compute）がリクエストを発行したノードでボリュームの複製がローカルで利用できるようにすることで機能します。これはすべての compute ノードが同じ LINSTOR クラスターの一部である LINSTOR サテライトを実行している場合にのみ機能します。
このオプションの利点は次のとおりです。
-
セットアップが完了すると、Cinder ホストはデータパスに関与しなくなります。ボリュームへのすべての読み書きは、構成された対向ノード間でのレプリケーションを処理するローカル DRBD モジュールによって処理されます。
-
Cinder ホストはデータパスに関与していないため、Cinder サービスが中断しても、すでに接続されているボリュームには影響しません。
既知の制限:
-
すべてのホストとハイパーバイザーが DRBD ボリュームの使用をサポートしているわけではありません。Linux ホストと
kvmハイパーバイザーがデプロイメントの対象として制限されます。 -
アタッチ済みで使用中のボリュームのリサイズは、デフォルトの nova パッケージで動作します。リサイズ自体は成功しますが、compute サービスは再起動するまでその変更を VM に反映しません。
LINBITは、 Novaコンピュートサービス および os-brick の依存関係に対して更新されたソースを提供しています。更新されたソースを使用することで、DRBDトランスポートを使用したアタッチ済みボリュームのリサイズが可能になります。 -
マルチアタッチ（複数の VM に同じボリュームをアタッチする）はサポートされていません。
-
暗号化されたボリューム は、DRBD デバイスの udev ルールが設定されている場合にのみ機能します。
udevルールはdrbd-utilsパッケージの一部であるか、独自のdrbd-udevパッケージの中にあります。
iSCSI トランスポートプロトコルを使用
Cinder ボリュームをエクスポートするデフォルトの方法は、iSCSI 経由です。これにより最大の互換性が得られます。iSCSI は、VMWare、Xen、HyperV、または KVM などのあらゆるハイパーバイザーで使用できます。
欠点は、すべてのデータを（ユーザースペースの）iSCSI デーモンで処理するためにCinder ノードに送信する必要があることです。これは、データがカーネル/ユーザスペース境界を通過する必要があることを意味し、パフォーマンスに影響を与えます。
もう1つの欠点は、単一障害点になりうる点です。iSCSI デーモンを実行している Cinder ノードがクラッシュすると、他のノードはボリュームにアクセスできなくなります。これを軽減するために自動フェイルオーバ用に Cinder を構成する方法はいくつかありますが、かなりの労力が必要です。
ドライバーバージョン2.0.0より前では、Cinderホストは各ボリュームのローカルレプリカにアクセスする必要があります。これは、linstor_controller_diskless=True`を設定するか、 `linstor_autoplace_count=0 を使用することで実現できます。新しいドライバーバージョンでは、そのようなボリュームを必要に応じて作成します。
|
10.3.2. LINSTOR バックエンドのステータスを確認
すべてのバックエンドが稼働していることを確認するには、OpenStack コマンドラインを使用できます。
$ openstack volume service list
╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
┊ Binary ┊ Host ┊ Zone ┊ Status ┊ State ┊ Updated At ┊
╞═════════════════════════════════════════════════════════════════════════════════════════════════════════════════╡
┊ cinder-scheduler ┊ cinder-01.openstack.test ┊ nova ┊ enabled ┊ up ┊ 2021-03-10T12:24:37.000000 ┊
┊ cinder-volume ┊ cinder-01.openstack.test@linstor-drbd ┊ nova ┊ enabled ┊ up ┊ 2021-03-10T12:24:34.000000 ┊
┊ cinder-volume ┊ cinder-01.openstack.test@linstor-iscsi ┊ nova ┊ enabled ┊ up ┊ 2021-03-10T12:24:35.000000 ┊
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯Horizon GUI をデプロイしている場合は、代わりに Admin > System Information > Block Storage Service を確認してください。
上記の例では、すべての構成済みのサービスが「有効」であり、「稼働中」です。何か問題がある場合は、Cinder Volumeサービスのログを調査してください。
10.4. LINSTOR の新しいボリュームタイプを作成
Cinder を使用してボリュームを作成する前に、ボリュームタイプを作成する必要があります。これは、コマンドラインから実行できます。
# Create a volume using the default back end
$ openstack volume type create default
╭────────────────────────────────────────────────────╮
┊ Field ┊ Value ┊
╞════════════════════════════════════════════════════╡
┊ description ┊ None ┊
┊ id ┊ 58365ffb-959a-4d91-8821-5d72e5c39c26 ┊
┊ is_public ┊ True ┊
┊ name ┊ default ┊
╰────────────────────────────────────────────────────╯
# Create a volume using a specific back end
$ openstack volume type create --property volume_backend_name=linstor-drbd linstor-drbd-volume
╭────────────────────────────────────────────────────╮
┊ Field ┊ Value ┊
╞════════════════════════════════════════════════════╡
┊ description ┊ None ┊
┊ id ┊ 08562ea8-e90b-4f95-87c8-821ac64630a5 ┊
┊ is_public ┊ True ┊
┊ name ┊ linstor-drbd-volume ┊
┊ properties ┊ volume_backend_name='linstor-drbd' ┊
╰────────────────────────────────────────────────────╯あるいは Horizon GUI でボリュームタイプを作成することもできます。Admin > Volume > Volume Types から “Create Volume Type” をクリックします。 volume_backend_name を “Extra Specs” として追加することで、バックエンドを割り当てることができます。
10.4.1. ボリュームタイプの詳細設定
各ボリュームタイプは、Horizon GUI で呼び出されるプロパティまたは “Extra Specs” を追加することでカスタマイズできます。
コマンドラインでボリュームタイプにプロパティを追加するには、次を使用します。
openstack volume type set linstor_drbd_b --property linstor:redundancy=5
または GUI で Admin > Volume > Volume Types から プロパティを設定することもできます。 Actions 列で、ドロップダウンメニューを開き View Extra Specs ボタンをクリックします。これにより、プロパティの作成、編集、削除に使用できるダイアログが開きます。
使用可能なボリュームタイプのプロパティ
linstor:diskless_on_remaining-
自動配置後、選択されていないノードにディスクレスレプリカを作成する。
linstor:do_not_place_with_regex-
Do not place the resource on a node which has a resource with a name matching the regular expression.
linstor:layer_list-
リソースを適用するためのレイヤーのコンマ区切りリスト。空の場合、デフォルトはDRBD、Storageです。
linstor:provider_list-
使用するプロバイダーのコンマ区切りリスト。空の場合、LINSTOR は適切なプロバイダーを自動的に選択します。
linstor:redundancy-
作成するレプリカの数。デフォルトは 2 です。
linstor:replicas_on_different-
自動配置を使用してストレージをプロビジョニングする場所を決定するときに、自動配置選択ラベルとして使用される key または key=value アイテムのコンマ区切りのリスト。
linstor:replicas_on_same-
自動配置を使用してストレージをプロビジョニングする場所を決定するときに、自動配置選択ラベルとして使用される key または key=value アイテムのコンマ区切りのリスト。
linstor:storage_pool-
自動配置時に使用するストレージプールのコンマ区切りリスト。
linstor:property:<key>-
キーの前に
linstor:property:が付いている場合、そのキーは LINSTOR プロパティとして解釈されます。プロパティはボリュームタイプ用に作成された Resource Group に設定されます。OpenStack では、プロパティ名に
/を使用できません。LINSTOR プロパティ名に/が含まれている場合は:に置き換えます。例: quorum policy を変更するには
DrbdOptions/auto-quorumを設定する必要があります。これは OpenStack のlinstor:property:DrbdOptions/auto-quorumプロパティを設定することで実行できます。
10.5. ボリュームの使用
ボリュームタイプを構成したら、それを使用して新しいボリュームのプロビジョニングを開始できます。
たとえば、コマンドラインで単純な 1Gb ボリュームを作成するには、次のコマンドを使用できます。
openstack volume create --type linstor-drbd-volume --size 1 \
--availability-zone nova linstor-test-vol
openstack volume list
/etc/cinder/cinder.conf に default_volume_type = linstor-drbd-volume を設定した場合、上記の openstack volume create … コマンドから --type linstor-drbd-volume を省略できます。
|
10.6. トラブルシューティング
このセクションでは、LINSTOR ボリュームとスナップショットの使用で問題が発生した場合の対処方法について説明します。
10.6.1. Horizon でエラーメッセージを確認する
すべてのボリュームとスナップショットには、Horizon ダッシュボードにメッセージタブがあります。エラーが発生した場合は、メッセージのリストを調査の出発点として使用することができます。エラーが発生した場合の一般的なメッセージの例:
バックエンドストレージからボリュームを作成します: ドライバーがボリュームの作成に失敗しました。
このメッセージは、新しいボリュームの作成中にエラーが発生したことを示しています。詳細については、Cinderボリュームサービスのログを確認してください。
schedule allocate volume:Could not find any available weighted backend.
このエラーメッセージが唯一のものである場合、これはCinderスケジューラがボリュームを作成するために適したボリュームバックエンドを見つけられなかったことを意味します。これはおそらく以下の理由によるものです:
-
ボリュームバックエンドはオフラインです。 LINSTOR バックエンドのステータスを確認 を参照してください。
-
ボリュームのバックエンドには、リクエストを満たすための十分な空き容量がありません。要求された容量が利用可能かどうかを確認するには、
cinder get-pools --detailとlinstor storage-pool listの出力を確認してください。
11. DockerのLINSTORボリューム
この章では、 LINSTOR Docker Volume Pluginによって管理されるDocker内のLINSTOR®ボリュームについて説明します。
11.1. Docker の概要
Docker は、Linuxコンテナの形式でアプリケーションを開発、配布、実行するためのプラットフォームです。データの永続化が必要な状態を持つアプリケーション向けに、Dockerは永続的な ボリューム と ボリュームドライバ の使用をサポートしています。
LINSTOR Docker Volume Plugin は、LINSTORクラスタから永続的ボリュームをプロビジョニングするDockerコンテナ用のボリュームドライバです。
11.2. Docker用のLINSTORプラグインをインストールする:
LINBIT®が提供する linstor-docker-volume プラグインをインストールするには、動作するLINSTORクラスターが必要です。その後、プラグインはパブリックなDocker Hubからインストールできます。
# docker plugin install linbit/linstor-docker-volume --grant-all-permissions
--grant-all-permissions フラグは、プラグインを正常にインストールするために必要なすべての権限を自動的に付与します。これらを手動で承認したい場合は、上記のコマンドからフラグを省略してください。
|
暗黙のうちに :latest というタグは最新の amd64 バージョンです。現在は対応するタグで arm64 用にもビルドしています。armw64 プラグインをインストールするには、次のコマンドを入力してください：
# docker plugin install linbit/linstor-docker-volume:arm64 --grant-all-permissions
11.3. Docker用のLINSTORプラグインの設定
プラグインがLINSTOR Pythonライブラリを使用してLINSTOR Controllerソフトウェアと通信する必要があるため、プラグインにはその構成ファイルでLINSTORコントローラーノードの場所を指定する必要があります。
# cat /etc/linstor/docker-volume.conf [global] controllers = linstor://hostnameofcontroller
もっと詳しい例を挙げると、次のようになります。
# cat /etc/linstor/docker-volume.conf [global] storagepool = thin-lvm fs = ext4 fsopts = -E discard size = 100MB replicas = 2
11.4. DockerでLINSTORプラグインを使用する
以下は、LINSTOR Docker Volume プラグインの使用例のいくつかです。 以下では、3つのノード（alpha、bravo、charlie）からなるクラスタが想定されています。
11.4.1. 典型的なdockerパターン
ノードalpha上:
$ docker volume create -d linbit/linstor-docker-volume \
--opt fs=xfs --opt size=200 lsvol
$ docker run -it --rm --name=cont \
-v lsvol:/data --volume-driver=linbit/linstor-docker-volume busybox sh
$ root@cont: echo "foo" > /data/test.txt
$ root@cont: exit
ノードbravo上:
$ docker run -it --rm --name=cont \
-v lsvol:/data --volume-driver=linbit/linstor-docker-volume busybox sh
$ root@cont: cat /data/test.txt
foo
$ root@cont: exit
$ docker volume rm lsvol
11.4.2. ホスト指定で1つのディスクフル割り当て、2つのディスクレスノード
$ docker volume create -d linbit/linstor-docker-volume --opt nodes=bravo lsvol
11.4.3. どこかに1つのディスクフル割り当て、2つのディスクレスノード
$ docker volume create -d linbit/linstor-docker-volume --opt replicas=1 lsvol
11.4.4. ホスト指定で2つのディスクフル割り当て、charlie はディスクレス
$ docker volume create -d linbit/linstor-docker-volume --opt nodes=alpha,bravo lsvol
11.4.5. どこかに2つのディスクフル割り当て、1つのディスクレスノード
$ docker volume create -d linbit/linstor-docker-volume --opt replicas=2 lsvol
11.4.6. Docker swarm manager ノードからのサービスで LINSTOR ボリュームを使用する
$ docker service create \
--mount type=volume,src=lsvol,dst=/data,volume-driver=linbit/linstor-docker-volume \
--name swarmsrvc busybox sh -c "while true; do sleep 1000s; done"
Dockerサービスは -v または --volume の構文を受け付けません。代わりに --mount の構文を使用する必要があります。Dockerの run はどちらの構文も受け付けます。
|
12. 高可用なNFS、iSCSI、またはNVMe-oFストレージのためのLINSTOR Gateway
LINSTOR Gateway は、LINSTOR®とDRBD Reactorを裏で使用して高可用性のNVMe-oFターゲット、iSCSIターゲット、またはNFSエクスポートを作成および管理するために使用できるオープンソースソフトウェアです。
この章では、ソフトウェアのインストール方法と使用方法に焦点を当てています。ソフトウェアの説明的な概要、そのコンポーネント、アーキテクチャ、および動作方法について理解するには、Understanding LINSTOR Gateway ガイドを読むことが重要です。
12.1. LINSTOR Gateway の要件
LINSTOR Gatewayを使用する前に、初期化済みのLINSTORクラスターを用意する必要があります。このクラスターには、DRBD Reactor、NVMe-oF、NFS、iSCSIのユーティリティがインストールおよび構成されている必要があります。DRBD Reactorには、最低でも3ノードのクラスターが必要ですが、そのうちの2ノードだけがディスクを持っていれば十分です。第3のノードはディスクレスであっても構いません。これによりコストを節約でき、DRBD®クォーラムウィットネスとしての役割を果たすだけです。この役割には、Raspberry Piなどの低消費電力のシングルボードコンピューターのような基本的なハードウェアでさえ十分です。次のセクションでは、LINSTOR Gatewayのインストール要件を満たす方法が詳細に説明されています。さらなる情報については、 DRBDユーザーガイド を参照してください。
12.1.1. LINSTORゲートウェイのためのLINSTORクラスタの準備
LINSTOR Gatewayを使用する前に、LINSTORクラスタを設定する必要があります。LINSTORのインストールおよびLINSTORクラスタの初期化に関する詳細情報は、 LINSTORユーザーガイド を参照してください。
LINSTORクラスターをインストールおよび初期化した後、LINSTORストレージプール、リソースグループ、およびボリュームグループを作成する必要があります。これらのLINSTORオブジェクトは、LINSTOR Gatewayで作成するターゲットとエクスポートをバックアップします。LINSTORストレージプールの詳細については、LINSTORユーザーガイド の ストレージプール セクションを参照してください。
このセクションの残りの部分では、3ノードのLINSTORクラスターにLINSTORゲートウェイの前提条件を設定するための例のコマンドを示しています。
|
LINSTOR を LVM および DRBD と一緒に使用する場合、LVM グローバル設定ファイル (RHEL では global_filter = [ "r|^/dev/drbd|", "r|^/dev/mapper/[lL]instor|" ] この設定により、LVMはLINSTORによって作成または構成されたDRBDなどのデバイスを、スキャンやオープン試行といった操作の対象から除外します。このフィルターを設定しない場合、CPU負荷の増大やLVM操作のスタックが発生する可能性があります。 |
各ノードに、物理デバイス /dev/sdb を使用するLVMベースのストレージプールを作成してください。
linstor physical-storage create-device-pool --pool-name lvpool LVM LINSTOR1 /dev/sdb \ --storage-pool lvmpool linstor physical-storage create-device-pool --pool-name lvpool LVM LINSTOR2 /dev/sdb \ --storage-pool lvmpool linstor physical-storage create-device-pool --pool-name lvpool LVM LINSTOR3 /dev/sdb \ --storage-pool lvmpool
作成したストレージプールによってバックアップされたLINSTORリソースグループとボリュームグループを作成してください。
linstor resource-group create iscsi_group \ --storage-pool lvmpool \ --place-count 2 linstor resource-group create nfs_group \ --storage-pool lvmpool \ --place-count 3 linstor resource-group create nvme_group \ --storage-pool lvm \ --place-count 2
linstor volume-group create iscsi_group linstor volume-group create nfs_group linstor volume-group create nvmeof_group
LINSTOR Gateway は、各サテライトノードの LINSTOR サテライトサービスの構成を変更する必要があります。これを行うには、/etc/linstor/linstor_satellite.toml 構成ファイルを編集または作成し、以下の内容を追加してください:
[files]
allowExtFiles = [
"/etc/systemd/system",
"/etc/systemd/system/linstor-satellite.service.d",
"/etc/drbd-reactor.d"
]
ノード上に /etc/linstor ディレクトリが存在しない場合は、まずそれを作成する必要があるかもしれません。
|
サテライト構成への変更を保存した後、変更を読み込むために全ノードでサテライトサービスを再起動してください。
systemctl restart linstor-satellite
12.1.2. 高可用性のLINSTOR Gatewayリソースを作成するためのDRBD Reactorの利用
DRBD Reactorは、LINSTOR Gatewayクラスター内のiSCSI、NFS、またはNVMe-oFリソースを統括するオープンソースのデーモンです。クラスター内のすべてのLINSTORサテライトノードにDRBD Reactorをインストールし、DRBD Reactorサービスを有効にする必要があります。
DRBD Reactorのインストールと構成オプションの詳細については、「DRBD®ユーザーガイド 」のDRBD Reactor章を参照してください。LINSTOR Gatewayと連携してDRBD Reactorをセットアップする手順は、パッケージマネージャーを使用してDRBD Reactorをインストールしたことを前提としています。 DRBD ReactorをDRBD Reactor GitHubプロジェクトからのオープンソースコードのインストールについては、README ファイルやGitHubリポジトリ内のその他のドキュメントを参照してください。
DRBD Reactorサービスの有効化と起動
すべてのクラスターのLINSTORサテライトノードにDRBD Reactorをインストールした後、すべてのノードでDRBD Reactorサービスを開始して有効にしてください。
systemctl enable --now drbd-reactor
DRBD Reactorの設定を変更後に自動的に再読み込みするように構成する
全てのLINSTORサテライトノードでDRBD Reactorサービスを有効にし、起動するだけでなく、DRBD Reactorが自動的に構成の変更時に再読み込みされるように設定する必要があります。これを行うには、全てのDRBD Reactorノードで以下のコマンドを入力してください:
cp /usr/share/doc/drbd-reactor/examples/drbd-reactor-reload.{path,service} \
/etc/systemd/system/
systemctl enable --now drbd-reactor-reload.path
12.1.3. NVMe-oF、iSCSI、およびNFSユーティリティのインストール
LINSTOR Gatewayがさまざまなターゲットやエクスポートを構成できるようにするためには、さまざまなパッケージやユーティリティをインストールして構成する必要があります。後続のサブセクションでは、これを行う方法について説明しています。
NVMe-oFユーティリティのインストール
LINSTOR Gatewayを使用してNVMe-oFターゲットを作成および管理する場合、すべてのノードにNVMe-oFコマンドラインインターフェースをインストールする必要があります。
RPMベースのシステムでは、nvmetcli パッケージをインストールします。DEBベースのシステムでは、nvme-cli パッケージをインストールします。
iSCSIスタックと依存関係の選択とインストール
LINSTOR Gatewayのデプロイメントでは、通常、iSCSIの実装として Linux-IO (LIO) または Generic SCSI Target Subsystem for Linux (SCST) のいずれかを使用します。
LIOは、Linuxカーネルコミュニティが選んだiSCSI実装であり、メインラインのLinuxカーネルに含まれるSCSIターゲットサブシステムです。
SCSTは、LINBIT®が開発したVSANソリューションを含む多くのiSCSIアプライアンスで使用されている成熟したiSCSI実装です（バージョン0.17.0以降）。
LINSTOR GatewayではLIOまたはSCSTのいずれかを使用することが推奨されていますが、iSCSIターゲットの実装としてiSCSI Enterprise Target (IET) または SCSI Target Framework (STGT) を使用することも可能です。
LINSTOR Gatewayのインストール
LIOは、Linuxカーネル 2.6.38から標準で含まれているSCSIターゲットであり、そのユーティリティや依存関係のインストールを比較的容易に行うことができます。
TargetCLIは、LIOターゲットを管理するための対話型シェルです。LIO iSCSI実装を使用する場合、LINSTOR Gatewayの一部の操作でTargetCLIが必要になります。TargetCLIをインストールするには、パッケージマネージャーを使用して、RPMベースのシステムでは`targetcli`パッケージを、DEBベースのシステムでは`targetcli-fb`パッケージをインストールしてください。
LINSTOR Gatewayを使用して高可用性iSCSIターゲットを作成するためのLIO iSCSI実装要件を満たしていることを確認するには、LINSTOR Gatewayをインストールした後、次のコマンドを入力してください。
linstor-gateway check-health --iscsi-backends lio-t
コマンドの出力結果は、LIO iSCSIの要件が満たされていることを示している必要があります。
[...] [✓] iSCSI [...]
LINSTOR Gatewayのインストール
SCSTプロジェクトは、カーネル空間のコア、デバイスハンドラ、ターゲットドライバ、および scstadmin ユーザースペースユーティリティで構成されており、これらすべてはソースからビルドすることができます。プロジェクトのソースコードリポジトリにある手順に従うことでビルドできます。
以下のインストール手順に従うことで、SCSTをLINSTOR Gatewayと共に使用するために必要なすべてのコンポーネントをインストールします。
| LINSTOR Gateway用のSCSTをインストールするには、以降のすべてのコマンドを全ノードで入力し、実行してください。以下の手順は、Red Hat Enterprise Linux (RHEL) へのインストールを想定したものです。DEBベースのシステムでSCSTのインストールと設定を行う場合は、コマンドを適宜調整する必要があります。 |
ELRepoは、標準のRHELディストリビューションのリポジトリに含まれていないEnterprise Linuxパッケージ用のRPMリポジトリで、DKMSをインストールするために必要です。また、SCSTのRPMパッケージをビルドするために開発ツールや他の依存関係もインストールする必要があります。
dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm dnf groupinstall -y "Development Tools" dnf install -y kernel-devel perl perl-Data-Dumper perl-ExtUtils-MakeMaker rpm-build dkms git
ビルド依存関係をインストールした後は、SCSTパッケージをビルドしてインストールすることができます。
git clone https://github.com/SCST-project/scst cd scst/ make rpm-dkms cd ~/ dnf install -y /usr/src/packages/RPMS/x86_64/scst*
最後に、以下のコマンドを入力して、SCSTカーネルモジュールをロードするための必要な設定を作成し、そして iscsi-scst サービス用のsystemdユニットファイルを作成してください。
echo -n "" > /etc/modules-load.d/scst.conf for m in iscsi-scst scst scst_vdisk; do echo $m >> /etc/modules-load.d/scst.conf modprobe $m done cat << EOF > /etc/systemd/system/iscsi-scst.service [Unit] Description=iSCSI SCST Target Daemon Documentation=man:iscsi-scstd(8) After=network.target Before=scst.service Conflicts=shutdown.target [Service] EnvironmentFile=-/etc/sysconfig/scst PIDFile=/var/run/iscsi-scstd.pid ExecStartPre=/sbin/modprobe iscsi-scst ExecStart=/sbin/iscsi-scstd $ISCSID_OPTIONS [Install] WantedBy=multi-user.target EOF
SCSTカーネルモジュールのロードと iscsi-scst サービス用のsystemdユニットファイルの作成が完了したら、新しいユニットファイルを含めてsystemdユニットファイルを再読み込みし、作成した iscsi-scst サービスを有効化して起動してください。
systemctl daemon-reload systemctl enable --now iscsi-scst
LINSTOR Gatewayを使用して高可用なiSCSIターゲットを作成するためのSCST iSCSI要件を満たしているか確認するには、LINSTOR Gatewayをインストールした後、次のコマンドを入力します。
linstor-gateway check-health --iscsi-backends scst
コマンドの出力結果において、SCST iSCSIの要件が満たされていることが示される必要があります。
LINSTOR GatewayへのNFSサポートをインストール
LINSTOR GatewayでNFSサポートを利用するには、すべてのクラスターノードにNFSユーティリティをインストールする必要があります。
RPMベースのシステムでは nfs-utils パッケージを、DEBベースのシステムでは nfs-common パッケージをインストールしてください。
正しいNFSパッケージを全てのLINSTORサテライトノードにインストールした後、次のコマンドを入力してsystemdユニットファイルを再読み込みしてください。
systemctl daemon-reload
DRBD Reactorによるサービス管理と競合するため、systemdでNFSサーバーサービスを有効にしないでください。`nfs-server`サービスを無効化した後、以下のコマンドを使用してステータスを確認してください。
systemctl disable nfs-server --now systemctl status nfs-server
上記の status コマンドの出力に、サービスが「inactive」と「disabled」にリストされていることを確認してください。
● nfs-server.service - NFS server and services Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; disabled; preset: disabled) Active: inactive (dead)
12.2. LINSTOR Gatewayのインストール
前提条件がインストールおよび設定されていることを確認した後、LINSTOR Gatewayをインストールすることができます。
LINBITのお客様であれば、LINBITのカスタマーリポジトリから linstor-gateway パッケージをインストールするためにパッケージマネージャを使用してLINSTOR Gatewayをインストールできます。ソフトウェアをオープンソースコードからビルドする必要がある場合は、LINBITはプロジェクトのソースコードリポジトリにオープンソースのLINSTOR Gatewayコードを維持しています。
12.2.1. LINSTORのGateway サーバーコンポーネントのインストール
LINSTOR Gatewayには、クラスター内で稼働しているLINSTORコントローラーサービスへの到達方法を「認識している」ノード上でバックグラウンド実行する必要があるサーバーコンポーネントがあります。通常、これはLINSTORコントローラーノード自体が該当します。高可用性（HA）構成のLINSTORコントローラーを構成している場合は、LINSTORコントローラーサービスが実行される可能性のあるクラスター内のすべてのノードに、LINSTOR Gatewayのサーバーコンポーネントをインストールする必要があります。
| LINSTOR Gatewayサーバーのデプロイ構成の選択肢に関する詳細については、『Understanding LINSTOR Gateway』ユーザーガイドの クラスターのアーキテクチャ セクションを参照してください。 |
ノードにLINSTORゲートウェイサーバーをインストールするには、systemdサービスを使用できます。LINSTORクライアントと同じノードに /etc/systemd/system/linstor-gateway.service というファイルを作成し、以下の内容をコピーしてサービスを作成してください。
[Unit] Description=LINSTOR Gateway After=network.target [Service] ExecStart=/usr/sbin/linstor-gateway server --addr ":8080" [Install] WantedBy=multi-user.target
次に、新しく作成したサービスを含めるためにsystemdユニットファイルを再読み込みし、その後LINSTOR Gatewayサービスを起動して有効化してください。
systemctl daemon-reload systemctl enable --now linstor-gateway
LINSTORのGateway サーバーコンポーネントのインストール
LINSTOR Gateway サーバーデーモンは、TOMLファイルを使用して設定できます。デフォルトでは、アプリケーションは /etc/linstor-gateway/linstor-gateway.toml にある設定ファイルを参照します。LINSTOR Gateway CLIクライアントを使用する際に --config /path/to/config コマンドラインフラグを追加することで、この設定を上書きすることができます。
設定ファイルでは、LINSTOR GatewayがLINSTORコントローラーサービスを参照する場所を指定できます。デフォルトでは localhost:3370 が使用されます。これが、LINSTOR GatewayサーバーをLINSTORコントローラーサービスと同じノードにインストールすることを前述の通り推奨した理由です。
以下は、LINSTORコントローラーノードの候補をIPアドレスで指定する設定ファイルの例です。
[linstor] controllers = ["10.10.1.1", "10.10.1.2", "10.10.1.3"]
12.3. LINSTOR Gateway の要件
LINSTOR Gatewayを使用する前の最終手順として、前のセクションで概説された前提条件を満たしているか確認してください。
12.3.1. コンポーネントがインストールされているか確認する
LINSTOR Gatewayを使用する前に、必要なすべての構成要素がインストールされていることを確認してください。以下のLINSTOR Gatewayの構成要素を確認する手順は、ストレージプール、リソースグループ、ボリュームグループを備えたLINSTORクラスターのインストールと設定がすでに完了していることを前提としています。
初期化されたLINSTORクラスターに加えて、すべてのノードには以下のパッケージが必要です:
-
linstor-client -
drbd-reactor -
nvmetcli -
もしiSCSIを実装する際にLIOを使用しているなら、
targetcli(RPM)またはtargetcli-fb(DEB)を使用してください。 -
nfs-utils(RPM) ornfs-common(DEB) -
nfs-server(RPM) ornfs-kernel-server(DEB) -
resource-agents
LINSTOR Gatewayは、ノードから実行するユーティリティを提供し、事前に必要なツールが存在するかを自動的に確認する機能を提供します。このユーティリティを使用するには、次のコマンドをLINSTORコントローラーノードに入力してください:
linstor-gateway check-health
コマンドの出力は、すべての必要なコンポーネントをインストールした場合に、以下の出力のようなものが表示されます。エラーが報告された場合は、先に進む前にエラーを解決する必要があります。
[✓] LINSTOR [✓] drbd-reactor [✓] Resource Agents [✓] iSCSI [✓] NVMe-oF [✓] NFS
特定のデータストアの実装を使用しない場合、そのデータストアのコンポーネントをクラスターにインストールしないことは許容されます。たとえば、LINSTOR Gatewayを使用してNVMe-oFをバックエンドとするデータストアを作成および管理する場合には、iSCSIおよびNFSのコンポーネントのインストールを省略することができます。この場合、LINSTOR Gatewayのヘルスチェックユーティリティを実行すると、iSCSIおよびNFSのコンポーネントが不足していると報告されますが、ユースケースには問題ありません。
12.3.2. LINSTORクラスタ初期化の確認
LINSTORクライアントのいくつかの list コマンドを実行し、その出力を以下の出力例と比較することで、LINSTORクラスターが正しく初期化されたことを確認できます。
linstor node list コマンドを実行して、すべての LINSTOR ノードが satellite または combined タイプとして表示されていること、および DRBD クォーラムを維持するために3つ（またはそれ以上）のノードが存在することを確認してください。
╭────────────────────────────────────────────────────────────╮ ┊ Node ┊ NodeType ┊ Addresses ┊ State ┊ ╞════════════════════════════════════════════════════════════╡ ┊ LINSTOR1 ┊ COMBINED ┊ 172.16.16.111:3366 (PLAIN) ┊ Online ┊ ┊ LINSTOR2 ┊ SATELLITE ┊ 172.16.16.112:3366 (PLAIN) ┊ Online ┊ ┊ LINSTOR3 ┊ SATELLITE ┊ 172.16.16.113:3366 (PLAIN) ┊ Online ┊ ╰────────────────────────────────────────────────────────────╯
LINSTORのストレージプールリストコマンドの出力にLVMまたはZFSでバックアップされたストレージプールが含まれることを確認してください。
╭─────────────────────────────────────────────────────────[...]─────────╮ ┊ StoragePool ┊ Node ┊ Driver ┊ PoolName ┊ [...] ┊ State ┊ ╞═════════════════════════════════════════════════════════[...]═════════╡ [...] ┊ lvmpool ┊ LINSTOR1 ┊ LVM ┊ lvpool ┊ [...] ┊ Ok ┊ ┊ lvmpool ┊ LINSTOR2 ┊ LVM ┊ lvpool ┊ [...] ┊ Ok ┊ ┊ lvmpool ┊ LINSTOR3 ┊ LVM ┊ lvpool ┊ [...] ┊ Ok ┊ ╰─────────────────────────────────────────────────────────[...]─────────╯
linstor resource-group list コマンドを実行して、ストレージプールを使用するLINSTORリソースグループが少なくとも1つ作成されていることを確認してください。
╭────────────────────────────────────────────────────────────────╮ ┊ ResourceGroup ┊ SelectFilter ┊ VlmNrs ┊ Description ┊ ╞════════════════════════════════════════════════════════════════╡ ┊ DfltRscGrp ┊ PlaceCount: 2 ┊ ┊ ┊ ╞┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╡ ┊ iscsi_group ┊ PlaceCount: 2 ┊ 0 ┊ ┊ ┊ ┊ StoragePool(s): lvmpool ┊ ┊ ┊ ╞┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╡ ┊ nvmeof_group ┊ PlaceCount: 2 ┊ 0 ┊ ┊ ┊ ┊ StoragePool(s): lvmpool ┊ ┊ ┊ ╞┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╡ ┊ nfs_group ┊ PlaceCount: 3 ┊ 0 ┊ ┊ ┊ ┊ StoragePool(s): lvmpool ┊ ┊ ┊ ╰────────────────────────────────────────────────────────────────╯
また、各リソースグループに対応するボリュームグループがあることも確認してください。
for vg in {iscsi,nfs,nvmeof}_group; do
linstor volume-group list "$vg"
done
出力は以下の通りです。
╭──────────────────╮ ┊ VolumeNr ┊ Flags ┊ ╞══════════════════╡ ┊ 0 ┊ ┊ ╰──────────────────╯ ╭──────────────────╮ ┊ VolumeNr ┊ Flags ┊ ╞══════════════════╡ ┊ 0 ┊ ┊ ╰──────────────────╯ ╭──────────────────╮ ┊ VolumeNr ┊ Flags ┊ ╞══════════════════╡ ┊ 0 ┊ ┊ ╰──────────────────╯
12.4. LINSTOR Gatewayを使用してiSCSIターゲットを作成
環境の準備が完了したら、iSCSI論理ユニット（LU）の作成を開始できます。すべてのiSCSI関連アクションを管理するために、linstor-gateway コマンドラインユーティリティを使用します。
iscsi サブコマンドに関する詳細情報については、linstor-gateway iscsi help を使用してください。
|
必要なLIO iSCSIコンポーネントがインストールされていることを前提として、次のコマンドを実行すると、LINSTORクラスター内の高可用なDRBDリソースをバックエンドとする新しいiSCSIターゲットが作成されます。
linstor-gateway iscsi create iqn.2019-08.com.linbit:example 172.16.16.97/24 1G \ --implementation lio-t \ --username=foo \ --password=bar \ --resource-group=iscsi_group
lio-t を、使用したい（かつ必要なコンポーネントをインストール済みの）iSCSI ターゲット実装に置き換えてください。実装タイプには iet、lio、lio-t、scst、tgt のいずれかを指定できます。例えば、SCST iSCSI 実装を使用し、かつ 必要なコンポーネントをインストール済み の場合は、--implementation scst オプションを使用してください。iSCSI ターゲット実装タイプを指定しない場合は、インストール済みのコンポーネントと OCF iSCSITarget リソースエージェント のロジックに基づいて自動的に選択されます。ただし、リソースエージェントによって選択されるデフォルトの実装が、必ずしも希望するものになるとは限りません。
|
この`iscsi create`コマンドを実行すると、LINSTOR Gatewayは指定されたLINSTORリソースグループ`iscsi_group`からリソースをデプロイします。また、このコマンドはiSCSIターゲットの高可用性を有効にするためのDRBD Reactor設定ファイルも作成します。LINSTORのリソース名は、iSCSI修飾名（IQN）のコロンの後に指定した名前（この例では`example`）になります。
一連のコマンドが完了すると、指定したユーザー名とパスワードでCHAP認証が有効になった1GiBのiSCSIターゲットが作成されます。このiSCSIターゲットは、指定したIPアドレスから検出可能です。このターゲットは、LINSTORによって管理されるDRBDデバイスをバックエンドとして使用します。コマンドによって生成されたDRBD Reactorの設定ファイルは、各ノードの /etc/drbd-reactor.d/ ディレクトリで確認できます。
linstor-gateway iscsi list コマンドを使用して、LINSTOR Gateway で作成された iSCSI リソースを一覧表示できます。
コマンドの出力には、クラスタ内の iSCSI リソースを一覧表示するテーブルが表示されます。
╭───────────────────────────────────────────────────────────────────────────────────────────╮ ┊ IQN ┊ Service IP ┊ Service state ┊ LUN ┊ LINSTOR state ┊ ╞═══════════════════════════════════════════════════════════════════════════════════════════╡ ┊ iqn.2019-08.com.linbit:example ┊ 172.16.16.97/24 ┊ Started ┊ 1 ┊ OK ┊ ╰───────────────────────────────────────────────────────────────────────────────────────────╯
drbd-reactorctl status コマンドを使用して、ノード上でDRBDリアクターの状態を確認できます。
|
12.5. iSCSIターゲットの削除
以下のコマンドを入力すると、iSCSIターゲットがDRBD ReactorおよびLINSTORクラスターから削除されます:
linstor-gateway iscsi delete iqn.2019-08.com.linbit:example
12.6. NFS エクスポートの作成
クラスター内にHA NFSエクスポートを作成するには、単一のLINSTOR Gatewayコマンドを入力するだけです。この単一のコマンドにより、クラスター内に新しいLINSTORリソースが作成されます。次に続く例のコマンドでは、リソースは nfstest という名前になります。LINSTORは指定されたリソースグループ nfs_group を使用して、リソースを展開するためのテンプレートとして機能します。このコマンドは、NFSエクスポートを高可用性にするDRBD Reactor構成ファイルも作成します。
linstor-gateway nfs create nfstest 172.16.16.99/32 1G \ --allowed-ips=172.16.16.0/24 \ --filesystem ext4 \ --resource-group=nfs_group
|
linstor resource-group set-property nfs_group FileSystem/Type ext4 この設定は、リソースグループごとに一度だけ行う必要があります。そして、それは LINSTOR Gateway の NFS エクスポートのために専用に作成されたリソースグループにのみ適用されます。 |
nfs create コマンドが実行を完了した後、allowed-ips コマンド引数で指定されたネットワーク内のNFSクライアントがエクスポートされたファイルシステムをマウントできる1GiBのNFSエクスポートが作成されます。クライアントは、この例ではコマンドで指定したIPアドレス 172.16.16.99 を使用して、NFSエクスポートをホストするNFSサーバーにアクセスできます。このIPアドレスは仮想IP（VIP）アドレスです。LINSTORのサテライトノードがNFSエクスポートをアクティブにホストしているかに関わらず、許可されたネットワーク内のNFSクライアントはVIPアドレスを使用してNFSサーバーにアクセスできます。
LINSTOR Gatewayで作成されたエクスポートは、LINSTORによって管理されるDRBDデバイスでバックアップされます。各LINSTORサテライトノードの /etc/drbd-reactor.d/ ディレクトリに、LINSTOR Gatewayで作成されたDRBDリアクターの設定ファイルが見つかります。
linstor-gateway nfs list コマンドを入力することで、LINSTOR Gateway が作成したNFSリソースを一覧表示できます。
| リマインダーとして、クラスタ内で単一のNFSエクスポートを作成するには、LINSTOR Gatewayのみを使用できます。 |
コマンドの出力には、クラスタ内のLINSTOR Gatewayで作成されたNFSエクスポートに関連する情報の表が表示されます。
╭────────────────────────────────────────────────────────────────────────────────────────────────╮
┊ Resource ┊ Service IP ┊ Service state ┊ NFS export ┊ LINSTOR state ┊
╞════════════════════════════════════════════════════════════════════════════════════════════════╡
┊ nfstest ┊ 172.16.16.99/32 ┊ Started (node-1) ┊ /srv/gateway-exports/nfstest ┊ OK ┊
╰────────────────────────────────────────────────────────────────────────────────────────────────╯
DRBD Reactorの状態は、drbd-reactorctl status コマンドで確認することができます。
|
12.7. NFS エクスポートの削除
次のコマンドは、DRBD ReactorからのNFSエクスポートとLINSTORクラスターを削除します:
linstor-gateway nfs delete -r nfstest
12.7.1. LINSTOR Gatewayを使用した追加のNFSエクスポートの作成
もしクラスターにすでにLINSTOR Gateway が作成したNFSエクスポートがある場合、制限[3]が発生します。、別の nfs create コマンドを使用して別のNFSエクスポートを作成 することはできません。
複数のNFSエクスポートを作成する必要がある場合は、事前に計画を立てて、単一の nfs create コマンドでこれらのエクスポートを作成する必要があります。最初（かつ唯一の）LINSTOR Gateway nfs create コマンドに複数の「ボリュームサイズ」引数を指定することで、複数のNFSエクスポートを作成することができます。例えば、次のコマンドとなります：
linstor-gateway nfs create example 172.16.16.99/24 20G 40G
このコマンドを入力すると、linstor-gateway nfs list コマンドの出力に示されているように、2つのエクスポートを持つNFSサービスが作成されます。
╭──────────────────────────────────────────────────────────────────────────────────────────────────────╮
┊ Resource ┊ Service IP ┊ Service state ┊ NFS export ┊ LINSTOR state ┊
╞══════════════════════════════════════════════════════════════════════════════════════════════════════╡
┊ example ┊ 172.16.16.99/24 ┊ Started (node-1) ┊ /srv/gateway-exports/example/vol1 ┊ OK ┊
┊ ┊ ┊ Started (node-1) ┊ /srv/gateway-exports/example/vol2 ┊ OK ┊
╰──────────────────────────────────────────────────────────────────────────────────────────────────────╯12.8. NVMe-oFターゲットの作成
linstor-gateway コマンドラインユーティリティは、すべてのNVMe-oFターゲット関連の操作を管理するために使用されます。
linstor-gateway nvme help コマンドを使用して、nvme サブコマンドの詳細情報を確認できます。
|
以下のコマンドを入力すると、指定された名前 linbit:nvme:vol0 とリソースグループ nvme_group を持つ新しいLINSTORクラスタ内のDRBDリソースが作成されます。このコマンドは、NVMe-oFターゲットの高可用性を可能にするためのDRBDリアクター構成ファイルも作成します。
linstor-gateway nvme create linbit:nvme:vol0 \ 172.16.16.98/24 2G \ --resource-group nvme_group
コマンドの実行が完了すると、クラスター内に作成された高可用性2GiB NVMe-oFターゲットが、コマンドで指定されたIPアドレスで検出可能になります。各LINSTORサテライトノードの /etc/drbd-reactor.d/ ディレクトリに、LINSTOR Gatewayによって作成されたDRBD Reactorの構成ファイルが見つかります。
`linstor-gateway nvme list`コマンドを実行することで、LINSTOR Gatewayを使用して作成したNVMe-oFリソースを一覧表示できます。出力には、NVMe-oFリソースとそれに関連する情報が表形式で表示されます。
╭──────────────────────────────────────────────────────────────────────────────────╮ ┊ NQN ┊ Service IP ┊ Service state ┊ Namespace ┊ LINSTOR state ┊ ╞══════════════════════════════════════════════════════════════════════════════════╡ ┊ linbit:nvme:vol0 ┊ 172.16.16.98/24 ┊ Started ┊ 1 ┊ OK ┊ ╰──────────────────────────────────────────────────────────────────────────────────╯
DRBD Reactorの状態は、drbd-reactorctl status コマンドで確認することができます。
|
13. CloudStackにおけるLINSTORボリューム
この章では、LINSTOR®を使用して、Apache CloudStack内でバックエンドとして使用できるボリュームをプロビジョニングする方法について説明します。CloudStackのプライマリストレージは、CloudStack内のホストで実行されている仮想マシン（VM）の仮想ディスクを格納します。LINBIT®が開発したCloudStackプラグインは、LINSTORをCloudStackと統合します。LINSTORをCloudStackと統合する利点は、柔軟に管理できる高可用性のプライマリストレージを提供する手段となることです。
| 現時点では、CloudStack用のLINSTORプラグインは、KVMハイパーバイザーで使用するためのボリュームのプロビジョニングにのみ使用できます。 |
Setting up and deploying CloudStack can be a complex task. A production-ready deployment can take several weeks to months before it is ready for users. A basic test deployment in a virtual environment can be set up in a few hours perhaps. This chapter will deal only with aspects related to integrating LINSTOR in CloudStack and should be considered a general overview. You should supplement instructions in this chapter with instructions and best practice recommendations from the CloudStack documentation.
| 本番環境へのデプロイ前に、CloudStackのドキュメントおよび『LINSTORユーザーガイド』の他の章にある、セキュリティ、ファイアウォール、リソースプロビジョニングに関する指示事項を確認してください。 |
| この章では、LINSTORユーザーガイドの他の部分と同様に、単語「ノード」が使用されています。ほとんどの場合、ノードはCloudStackの「ホスト」と同等と考えていただいて構いません。 |
13.1. CloudStackの紹介
CloudStackのドキュメントには次のように書かれています。「Apache CloudStackはオープンソースのインフラストラクチャ・サービス（IaaS）プラットフォームで、ストレージ、ネットワーク、コンピュータのリソースプールを管理およびオーケストレーションして、公共またはプライベートのIaaSコンピュートクラウドを構築します」
13.2. CloudStackとLINSTORの展開のための環境の準備
CloudStackを使用するためにLINSTORを展開する前に、いくつかの準備手順を踏む必要があります。
13.3. CloudStack用のLINSTORのインストールと準備
LINSTORプラグインは、Apache CloudStackバージョン4.16.1以降に含まれています。LINSTORをサポートするためには、他に何もインストールする必要はありません。CloudStackバージョン4.16.0およびそれ以前は、LINSTORプラグインをサポートしていません。
| CloudStack v4.17.0において、1つのプルリクエストが正しくマージされず、CloudStack初期化ウィザードのUIにバグが発生しました。詳細は[こちら](https://github.com/apache/cloudstack/pull/6481)でご確認いただけます。もしv4.17ブランチを使用している場合は、現在の段階ではv4.17.1をインストールすることが推奨されています。 |
クラスタ内のストレージ提供ノードに LINSTOR をインストールするには、 『LINSTOR ユーザーガイド』のインストール手順 に従ってください。
インストール手順の基本的な概要は次の通りです：
-
使用するストレージレイヤー（たとえば ZFS や LVM）に必要なパッケージをインストールしてください。以下の手順では、LINSTOR にバッキングストレージレイヤーとして ZFS を使用します。
LINSTOR を LVM および DRBD と一緒に使用する場合、LVM グローバル設定ファイル (RHEL では
/etc/lvm/lvm.conf) のglobal_filter値を次のように設定します。global_filter = [ "r|^/dev/drbd|", "r|^/dev/mapper/[lL]instor|" ]
This setting tells LVM to reject DRBD and other devices created or set up by LINSTOR from operations such as scanning or opening attempts. In some cases, not setting this filter might lead to increased CPU load or stuck LVM operations.
-
LINBITの顧客であれば、LINBITのリポジトリから必要なLINSTORパッケージ（DRBD®カーネルモジュール、
linbit-sds-controller、linbit-sds-satelliteパッケージ）をインストールしてください。それ以外の場合は、ソースコードからビルドする必要があります。 -
multipathdデーモンを再起動してください。systemctl restart multipathd
-
ノード上で、LINSTOR ControllerとLINSTOR Satelliteのサービスを有効にして起動してください。
# systemctl enable --now linstor-controller # systemctl enable --now linstor-satellite
-
LINSTOR にノードを追加してください。
linstor node create <node_host_name>
-
参加ノード全てに新しい LINSTOR ストレージプールを作成してください。例えば、ZFSプールが
zfs_storageとしてある場合、以下を入力してDfltStorPoolという名前のストレージプールを作成します:# linstor storage-pool create zfs <node_host_name> DfltStorPool zfs_storage
-
CloudStack用に使用されるLINSTORリソースグループを作成します。
cloudstackという名前のリソースグループを作成し、クラスタの2つのノードに配置します。次のように入力してください:# linstor resource-group create cloudstack --place-count 2 --storage-pool DfltStorPool
-
コマンドを入力して、リソースグループからLINSTORボリュームグループを作成してください。
# linstor volume-group create cloudstack
13.3.1. リソース作成の検証作業後のクリーンアップ
LINSTORをインストールしてストレージプールとストレージレイヤーでバックアップされたリソースグループを作成した後、ストレージリソースを作成できることをテストしてください。これは、作成したリソースグループからリソースを生成することで行うことができます。
| The CloudStack setup best practices recommend that a primary storage mount point (and therefore the LINSTOR resource that backs it) “should not exceed 6TB in size.” |
# linstor resource-group spawn cloudstack testres 1GiB
リンストアのリソースグループを作成し、クラウドスタック上に1GiBのtestresを生成します。
# linstor resource list ╭──────────────────────────────────────────────────────────────────────────────────╮ ┊ ResourceName ┊ Node ┊ Port ┊ Usage ┊ Conns ┊ State ┊ CreatedOn ┊ ╞══════════════════════════════════════════════════════════════════════════════════╡ ┊ testres ┊ node-0 ┊ 7000 ┊ Unused ┊ Ok ┊ UpToDate ┊ 2022-11-10 20:12:30 ┊ ┊ testres ┊ node-1 ┊ 7000 ┊ Unused ┊ Ok ┊ UpToDate ┊ 2022-11-10 20:12:30 ┊ ┊ testres ┊ node-2 ┊ 7000 ┊ Unused ┊ Ok ┊ TieBreaker ┊ 2022-11-10 20:12:29 ┊ ╰──────────────────────────────────────────────────────────────────────────────────╯
13.4. CloudStackのインストール
After installing and preparing LINSTOR, you can install and configure CloudStack. As disclaimed previously, you should take these instructions as a way to setup CloudStack quickly for testing and illustrative purposes. Refer to CloudStack documentation for detailed instructions and best practice recommendations, before deploying into production.
13.4.1. MySQLのインストール
まず、CloudStackのデータベースに必要なMySQLサーバーインスタンスをインストールしてください。
Ubuntu上では次のように入力してください：
# apt install -y mysql-server
RHELの場合は:
# dnf install -y mysql-server
13.4.2. CloudStack データベースの設定:
MySQLサーバーパッケージをインストールした後、次の内容で /etc/mysql/conf.d/cloudstack.cnf というCloudStackデータベース構成ファイルを作成してください。
[mysqld] innodb_rollback_on_timeout=1 innodb_lock_wait_timeout=600 max_connections=350 (1) log-bin=mysql-bin binlog-format = 'ROW'
| 1 | 350 is the max_connections value specified in the CloudStack installation guide. You can change this value depending on your needs. |
Ubuntu 16.04以降のシステムでバイナリログを使用する場合は、.cnf データベース設定ファイルで server_id を指定する必要があります。例えば、以下のように設定します：
[mysqld] server_id = 1 innodb_rollback_on_timeout=1 innodb_lock_wait_timeout=600 max_connections=350 log-bin=mysql-bin binlog-format = 'ROW'
その後、systemctl restart mysql を入力してMySQLサービスを再起動してください。
13.4.3. セカンダリストレージ用のNFSのインストール
次に、CloudStackのセカンダリストレージ用にNFSをインストールして設定します。これは、CloudStackの管理ノードとなるノードだけで行う必要があります。CloudStackは、VMのためのオペレーティングシステムイメージやVMデータのスナップショットなどを保存するためにセカンダリストレージを使用します。
NFSをインストールするには、Ubuntuで次のように入力します:
# apt install -y nfs-kernel-server
RHELの場合は:
# dnf install -y nfs-utils
NFSサーバーをインストールした後、次のコマンドを入力してCloudStackのセカンダリストレージ用のNFSエクスポートを作成してください。
# mkdir -p /export/secondary # echo "/export *(rw,async,no_root_squash,no_subtree_check)" >> /etc/exports # exportfs -a
次に、NFSサーバーサービスを有効にして起動します。
# systemctl enable --now nfs-server
13.5. CloudStackのインストールと設定
General CloudStack installation and configuration instructions follow. As your environment might have specific needs or variations, you should also reference the instructions in the CloudStack Installation Guide.
13.5.1. CloudStackのインストール
公式なCloudStackリリースは常にソースコード形式で提供されますが、便宜上、cloudstack.orgでコミュニティが作成したDEBおよびRPMパッケージが利用可能です。
-
Ubuntu DEB repository: https://download.cloudstack.org/ubuntu
-
EL8 RPM repository: https://download.cloudstack.org/el/8/
-
EL7 RPM repository: https://download.cloudstack.org/el/7/
インストールに必要なパッケージを見つけてダウンロードするには、上記のリンクに従ってください。ダウンロードしたパッケージの整合性を確認する際には、CloudStackの署名キーを使用することを忘れないでください。詳細はこちらの リンク に記載されています。
Alternatively, you can follow instructions here to configure the CloudStack repository appropriate to your Linux distribution and then pull and install packages by using your distribution’s package manager.
CloudStackリポジトリを追加した後、パッケージマネージャのリポジトリリストを更新してからパッケージをインストールする必要があるかもしれません。
CloudStackの管理ノードには、次のパッケージをインストールしてください。
-
cloudstack-management -
cloudstack-common -
cloudstack-ui
他のクラスターノードには、cloudstack-agent パッケージをインストールしてください。
13.5.2. CloudStackデータベースの初期化:
必要なCloudStackパッケージをインストールした後、CloudStackデータベースを初期化してください。
テストのために、マネジメントノードに次のコマンドを入力することができます:
# cloudstack-setup-databases cloud:cloud --deploy-as=root:nonsense -i <node_name>
ここにある cloud: の後ろや nonsense は、適宜変更できるパスワードです。
For production deployments, follow the more detailed instructions in the CloudStack Installation Guide.
13.6. CloudStack システム仮想マシンイメージテンプレートのインストール
CloudStackは、機能の一部のためにシステムVMをいくつか実行する必要があります。CloudStack VMテンプレートイメージをダウンロードし、その後CloudStackスクリプトを実行して、展開されるさまざまなシステムVMに必要なイメージを準備します。CloudStack管理ノードで以下のコマンドを入力してください。
# CS_VERSION=4.17 # CS_VERSION_PATCH=4.17.1 # wget https://download.cloudstack.org/systemvm/$CS_VERSION/systemvmtemplate-$CS_VERSION_PATCH-kvm.qcow2.bz2 # /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt \ -m /export/secondary \ -f systemvmtemplate-$CS_VERSION_PATCH=-kvm.qcow2.bz2 \ -h kvm -o localhost -r cloud -d cloud
13.7. CloudStackで使用するためのKVMハイパーバイザーホストの設定
現在、LINSTORのCloudStackプラグインはKVMハイパーバイザーホストのみをサポートしています。次に続く手順は、CloudStackのインストールをKVMハイパーバイザーホストで構成するためのものです。
CloudStack VMをホストするクラスター内のすべてのノードに libvirt 構成を追加するには、次のコマンドを入力してください:
# cat << EOF >> /etc/libvirt/libvirtd.conf listen_tls = 0 listen_tcp = 1 tcp_port = "16509" auth_tcp = "none" # not suitable for production mdns_adv = 0 EOF
すべてのハイパーバイザーノードで libvirtd サービスを再起動してください。
# systemctl restart libvirtd
13.7.1. AppArmorの設定:
もしUbuntu Linux上でCloudStackを実行しており、AppArmorが有効になっている場合は、次の手順を実行してください:
# ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/ # ln -s /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper /etc/apparmor.d/disable/ # apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd # apparmor_parser -R /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
13.7.2. CloudStack管理サービスの再起動
必要なセットアップと準備設定を行った後に、「cloudstack-management」サービスを再起動してください。
# systemctl restart cloudstack-management
CloudStackの初期データベースセットアップの進捗状況は、次のように入力してフォローすることができます:
# journalctl -u cloudstack-management -f
13.7.3. CloudStackのUIにログインする
しばらく経った後、CloudStackの管理UIにログインできるようになるはずです。マネジメントノードの解決可能なホスト名が node-0 であるとした場合、クラスター内のコンピューターのウェブブラウザに以下のURLを入力してください：http://node-0:8080/client。
CloudStack UI ポータルのログインページにアクセスしたら、デフォルトのユーザー名 admin とデフォルトのパスワード password を使用してポータルにログインしてください。
ログインに成功すると、CloudStack UI は「CloudStackへようこそ」というページを表示します。
13.7.4. CloudStackの初期設定ウィザードを実行する
CloudStackのセットアップを継続するには、初期化ウィザードを起動して設定を行います。ウィザードを起動するには、「インストールを続行」ボタンをクリックしてください。
The wizard will first prompt you to change the default password for the administrator user. After changing the password, you can continue through the wizard steps to configure a zone, network, and resources details. Complete the fields in each setup step according to your environment and needs. More details about initializing CloudStack can be found here.
以下のフィールドは、CloudStackにおけるすべてのLINSTORのユースケースに共通します:
-
Zone details:
-
Hypervisor: KVM
-
-
Add resources, IP Address step:
-
Host Name: <host_name_of_cluster_node_that_will_host_VMs>
-
Username: root
-
Password: <root_password_that_you_configured_previously_for_the_host>
-
-
Add resources, Primary Storage step:
-
Protocol: Linstor
-
Server: <IP_address_of_LINSTOR_controller_node>
-
Resource Group: <LINSTOR_resource_group_name_that_you_configured_previously>
-
以前にセカンダリストレージのためにNFSエクスポートを設定したことに基づいて、”リソースの追加、セカンダリストレージ” ステップで提示されるフィールドを以下のように入力してください。
-
Provider: NFS
-
IP Address: <IP_address_of_NFS_server> # should be the CloudStack management node
-
Path: <NFS_mount_point> #
/export/secondary, as configured previously
「リソースを追加」フィールドに入力を完了し、「次へ」ボタンをクリックすると、ウィザードは「ゾーンの起動が準備完了です」というメッセージを表示します。その後、「ゾーンを起動」ボタンをクリックしてください。
| 「ランチゾーン」プロセスの「ホストの追加」ステップは、しばらく時間がかかるかもしれません。 |
ゾーンが追加されると、ウィザードが「ゾーンの作成が完了しました」というメッセージを表示します。その後、「ゾーンを有効にする」ボタンをクリックできます。もう一度「成功」の通知が表示されると、CloudStack UIのダッシュボードに戻ります。
13.8. CloudStackにおける次のステップを踏む
After configuring LINSTOR for use in CloudStack you can move onto other tasks, such as adding hosts to host your CloudStack VMs.
LINBITは、LINSTORとCloudStackを3つのノードVMクラスターに展開するデモンストレーション動画も公開しています。動画は[こちら](https://www.youtube.com/watch?v=hI_kTlsbNeU)でご覧いただけます。
13.9. クラウドスタックにおける高可用性とLINSTORボリューム
The CloudStack documentation on HA-enabled instances explains that in case of KVM hypervisors, only HA-enabled hosts are safe from split-brain situations. HA-enabled hosts need to have the ability of “out-of-band management” which is IPMI.
そのドキュメンテーションは、KVM インスタンスが NFS や iSCSI ストレージ上にある場合には正しいです。インスタンスの仮想ディスクが LINSTOR 上にある場合、HA が有効化されたホストは必要なく、推奨されません。”out-of-band management” は必要ありませんし、IPMI も不要です。CloudStack の “VM-HA” が十分で安全です。
DRBDに組み込まれたクォーラム機構とLINSTORによって有効化されたこの機構は、スプリットブレインが発生しないように防止します。
13.9.1. 説明と理由
CloudStackがハイパーバイザとの接触を失った場合、CloudStackは運用の継続を確保するためのプロセスを開始します。具体的には、失われたハイパーバイザで実行中だった仮想マシンを別の利用可能なハイパーバイザノードで自動的に再起動します。このプロセスは、停止時間を最小限に抑え、CloudStack環境のスムーズな運用を保証するよう設計されています。
考慮すべき可能性のケースが2つあります。1つのケースでは、CloudStackがハイパーバイザーへの接続を失っていますが、DRBDはまだそのハイパーバイザーへのネットワーク接続を持っています。この場合、ハイパーバイザーホスト上で実行されているVMはまだストレージボリュームにアクセスできます。そのため、DRBDは、別のハイパーバイザーホストでKVMプロセスを起動しようとする試みを拒否し、open() システムコールに失敗することになります。
その他の場合では、DRBDもそのハイパーバイザーへの接続を失い、残りのノードは該当のDRBDリソースに対してクォーラムを持っています。この場合、DRBDはCloudStackが残りのノードの1つでKVMプロセスを開始することを許可します。これは、到達不能なハイパーバイザーがそのDRBDデバイスでクォーラムを失ったことが確実であるためです。その後、DRBDは孤立したハイパーバイザー上のDRBDストレージデバイスで実行されているVMのI/Oを停止します。したがって、到達不能なホストがネットワークから孤立したが、他のサービスやプロセスに影響を与えなかった場合（例えば、再起動によるハイパーバイザーの喪失など）、失われたハイパーバイザーで実行されているVMインスタンスは凍結したI/O状態のままとなります。
このような状況からの自動回復の詳細については、DRBDユーザーガイド の Quorumを失ったプライマリノードの回復 セクションの詳細を参照してください。
14. Oracle VirtualizationにおけるLINSTORストレージドメイン
OracleのWebサイトによると、Oracle Virtualizationは、Oracle Linuxベースの「KVM仮想化および管理機能を提供するエンタープライズグレードのサーバー仮想化ソリューション」です。Oracle Linux Virtualization Manager (OLVM)は、Oracle Virtualizationソリューションにおける管理プラットフォームです。
この章では、LINSTOR®を使用して、Oracle Linux Virtualization Manager向けに永続的でレプリケーションされた高性能ブロックストレージをプロビジョニングする方法について説明します。
14.1. オラクルLinux仮想化マネージャーへの導入:
OLVMは、oVirtをベースとした仮想化管理プラットフォームです。Oracle Linux上で動作するKernel-based Virtual Machine (KVM)ホストの構成、管理、および監視を行うことができます。
OLVMにおいて、データ・ドメインは仮想マシンのディスク・イメージ、ISOファイル、およびスナップショット用の一元化されたストレージを提供します。OLVMは、ストレージ・ドメインとも呼ばれる複数「タイプ」のデータ・ドメインをサポートしており、これらはLINSTORと統合することができます：
-
iSCSIまたはNFS: LINSTOR Gatewayを使用すると、LINSTORをバックエンドとした高可用なiSCSIターゲットおよびNFSエクスポートを作成・管理できます。
-
Managed block storage: 各仮想ディスクが共有ストレージプールからではなく、独自のボリュームとしてプロビジョニングされるOLVMストレージドメインです。これにより、LINSTORで管理されたボリュームをOLVM内の仮想マシンに直接アタッチできるようになり、パフォーマンスが向上し、iSCSIやNFSストレージの制限を回避できます。
14.2. OLVM向けLINSTOR Gatewayの準備
LINSTOR Gatewayを使用すると、OLVMでデータドメインとして使用するためのiSCSIターゲットやNFSエクスポートを作成できます。すべてのボリュームアクセスは、ボリュームをエクスポートしているLINSTOR Gatewayホストを経由してルーティングされます。ボリュームアクセスには、実行中の仮想マシンからのすべてのI/Oや、データドメインをアクティブに使用しているその他のプロセスが含まれます。
前提条件として、以下が必要になります：
-
稼働中の LINSTORクラスター
-
完了した LINSTOR Gateway のインストール
LINSTOR（およびLINSTOR Gateway）は、OLVMと同じノード（ハイパーコンバージド）にデプロイすることも、OLVM環境外の別のノード（非ハイパーコンバージド）にデプロイすることも可能です。
|
14.3. LINSTOR Gateway を使用した OLVM データドメインの作成
linstor-gateway コマンドを使用して、iSCSI または NFS エクスポートを作成します。OLVM 環境から到達可能な仮想 IP (VIP) アドレスを選択してください。クライアントはこのアドレスを経由して、iSCSI ターゲットや NFS エクスポートにアクセスすることになります。
以下の例では、VIPアドレス 192.168.0.100 を使用して、100 GiBのLUNを持つiSCSIターゲットを作成します。
linstor-gateway iscsi create iqn.2019-08.com.linbit:data-domain 192.168.0.100/24 100G
iSCSI作成コマンドを入力すると、LINSTOR GatewayがiSCSIターゲットを正常に作成したことが出力に表示されます。:
Created iSCSI target 'iqn.2019-08.com.linbit:data-domain'
次の例では、192.168.0.101:/srv/gateway-exports/nfs-data で利用可能な 100 GiB の NFS エクスポートを作成します。
linstor-gateway nfs create nfs-data 192.168.0.101/24 100G
NFS作成コマンドを入力すると、LINSTOR GatewayがNFSエクスポートを正常に作成したことが出力に表示されます。
Created export 'nfs-data' at 192.168.0.101:/srv/gateway-exports/nfs-data
データドメインは、https://engine-fqdn/ovirt-engine/ で利用可能な管理ポータルを通じて OLVM に追加する必要があります。
OLVMで Storage に移動し、Domains をクリックします。Storage Domains ペインで New Domain をクリックし、次の手順に従います。
-
Storage Type ドロップダウンリストから iSCSI または NFS を選択します。
-
新しいデータドメインの名前を選択してください。
-
設定を完了するために、必要な接続パラメータを入力してください。
-
OK をクリック
14.3.1. LINSTOR Gatewayを使用して、OLVM Self-Hosted Engineをデプロイする。
LINSTOR Gateway iSCSI ターゲットは、OLVM self-hosted engine のデータドメインを作成するために使用できます。
| iSCSIデータドメインは、セルフホストエンジンVMが独占的に使用するための専用iSCSIターゲットである必要があります。 |
セルフホストエンジンのVMストレージとして使用するために、少なくとも74 GiB以上のiSCSIターゲットを作成してください。次の例では、100 GiBのボリュームを iqn.2019-08.com.linbit:olvm-engine としてエクスポートし、VIPアドレス 192.168.0.200 で利用可能にします。VIPアドレスとiSCSIターゲット名は、環境に応じた適切な値に変更してください。
linstor-gateway iscsi create iqn.2019-08.com.linbit:engine-data 192.168.0.200/24 100G
OLVMセルフホステッドエンジンのデプロイメント中に、セルフホステッドエンジンVMのストレージに関する詳細情報の入力を求められます。ストレージタイプ iscsi とVIPアドレス 192.168.0.200 を入力するだけで、その他の情報はすべて自動的に検出されます。
Please specify the storage you would like to use (glusterfs, iscsi, fc,
nfs)[nfs]: iscsi
Please specify the iSCSI portal IP address: 192.168.0.200
Please specify the iSCSI portal port [3260]:
Please specify the iSCSI discover user:
Please specify the iSCSI discover password:
Please specify the iSCSI portal login user:
Please specify the iSCSI portal login password:
The following targets have been found:
[1] iqn.2019-08.com.linbit:engine-data
TPGT: 1, portals:
192.168.0.200:3260
Please select a target (1) [1]: 1
Please select the destination LUN (1) [1]:
セットアップの完了後、iSCSIターゲットはiSCSIデータ・ドメインとしてOLVMに追加されます。
14.4. LINSTORによるマネージド型ブロックストレージ・データドメインの作成
| OLVMにマネージドブロックストレージを追加する前に、まずiSCSIまたはNFSのマスターデータドメインを追加する必要があります。 |
LINSTORは、マネージド・ブロック・ストレージ（MBS）データドメインの使用を可能にするOLVM用のCinderlibドライバーを提供します。
OLVMとLINSTORでマネージド・ブロック・ストレージ・ドメインを使用する場合：
-
各仮想ディスクイメージは、一意のLINSTORリソースと1対1で対応します。
-
OLVMボリュームのUUIDは、対応するLINSTORリソース名に含まれています。
|
マネージドブロックストレージを使用するには、OLVMおよびLINSTORで追加の設定が必要です：
-
OLVMエンジンホストを含むすべてのKVMホストは、`ovirt`および`drbd-9`リポジトリを有効にした状態で、LINBITに登録されている必要があります。
-
すべてのKVMホストはLINSTORクラスターノードである必要があり、各ホストはLINSTORサテライトノードとして構成されている必要があります。
-
OLVMでCinderlib統合を有効にする必要があります。この機能は、OLVMエンジンのデプロイプロセス中に明示的に有効にしない限り、無効になっています。OLVMエンジンのデプロイ後に有効にするには、エンジンホストで
engine-setupを実行してください：engine-setup --reconfigure-optional-components
プロンプトが表示されたら Yes と入力してください。
--== PRODUCT OPTIONS ==-- Configure Cinderlib integration (Currently in tech preview) (Yes, No) [No]: Yes
-
エンジンホストに
linstor-cinderパッケージをインストールする必要があります：$ dnf install -y --enablerepo=ovirt linstor-cinder
マネージドブロックストレージデータドメインは、https://engine-fqdn/ovirt-engine/ でアクセス可能なOLVM管理ポータルから追加する必要があります。
OLVMで、*Storage*に移動し、*Domains*をクリックします。*Storage Domains*ペインで、*New Domain*をクリックし、以下の手順に従ってマネージドブロックストレージデータドメインを追加します。
-
Domain Function ドロップダウンリストから Managed Block Storage を選択してください。
-
新しいデータドメインの名前を
linstor-cinderに設定します。 -
以下のドライバーオプションを使用してください：
Property Value Description volume_driverlinstor_cinder.LinstorDrbdDriverSpecifies the use of the LINSTOR Cinder driver for managed block storage.
linstor_urislinstor://linstor-controller-ip-addressURL of the LINSTOR controller endpoint(s). Separate multiple endpoints by using a comma (
,).linstor_default_resource_group_nameDfltRscGrpLINSTOR resource group to use. Volumes created in this data domain will inherit all settings from the resource group.
DfltRscGrpは LINSTOR におけるデフォルトのリソースグループです。ほとんどの場合、LINSTOR を OLVM 環境のストレージ要件により適合させるために、たとえばrg_cinderのような リソースグループ を作成する必要があります。
| OLVMでは、管理対象ブロック・ストレージ・ボリュームを持つ仮想マシンの作成は、管理ポータルからのみ行えます。VMポータルは、管理対象ブロック・ストレージ・データ・ドメイン内での新規ボリュームの作成をサポートしていません。 |
