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ベースのストレージソリューションを実装する方法について取り扱った章があります。これらは LINSTROR 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
-
Exos [DEPRECATED]
-
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 コントローラー
linstor-controller サービスは、クラスタ全体の構成情報を保持するデータベースに依存しています。LINSTORコントローラーソフトウェアを実行しているノードやコンテナは、リソース配置、リソース構成、およびクラスタ全体の状態を必要とするすべての運用プロセスのオーケストレーションを担当しています。
LINSTORでは複数のコントローラを使用することができます。たとえば、 高可用性のLINSTORクラスタを設定する ときには、複数のコントローラを利用することができます。ただし、アクティブなコントローラは1つだけです。
前述のように、LINSTORコントローラーは、管理するデータプレーンとは別のプレーンで動作します。コントローラーサービスを停止し、コントローラーノードを更新または再起動しても、LINSTORサテライトノードにホストされているデータにアクセスできます。LINSTORサテライトノード上のデータには引き続きアクセスし、提供することができますが、実行中のコントローラーノードがないと、サテライトノードでのLINSTORの状態や管理タスクを実行することはできません。
1.3.2. LINSTOR サテライト
linstor-satellite サービスは、LINSTORがローカルストレージを利用するか、サービスにストレージを提供する各ノードで実行されます。このサービスはステートレスであり、LINSTORコントローラーサービスを実行しているノードまたはコンテナから必要なすべての情報を受け取ります。 LINSTORサテライトサービスは、lvcreate や`drbdadm` などのプログラムを実行します。それは、LINSTORコントローラーノードまたはコンテナから受け取った命令を実行するノード上またはコンテナ内のエージェントのように機能します。
1.3.3. LINSTOR User Interfaces
LINSTORとのインターフェースを行う必要がある場合、そのアクティブなLINSTORコントローラーに指示を送信するには、LINSTORクライアント、またはLINBIT SDS GUIのどちらかのユーザーインターフェース(UI)を使用できます。
これらのUIは、両方ともLINSTORの REST API に依存しています。
LINSTOR Client
「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) - exos - 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 Graphical User Interface
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には間接的な定義もいくつかあります：[the storage pool definition], [the snapshot definition], そして [the snapshot volume definition]。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はローリングアップグレードをサポートしていません。コントローラーとサテライトは同じバージョンである必要があり、さもなければコントローラーは VERSION_MISMATCH でサテライトを破棄します。しかし、これは問題ではありません。なぜなら、サテライトはコントローラーに接続されていない限り、どんなアクションも行いませんし、DRBDも決して妨げられることはありません。
もし組み込みのデフォルト H2 データベースを使用しており、linstor-controller パッケージがアップグレードされると、自動的にデータベースのバックアップファイルがデフォルトの /var/lib/linstor ディレクトリに作成されます。このファイルは、linstor-controller のデータベースの移行が何らかの理由で失敗した場合の良い復元ポイントです。その場合は、LINBIT にエラーを報告し、古いデータベースファイルを復元して前のコントローラーバージョンに戻すことが推奨されています。
外部データベースや etcd を使用する場合は、現在のデータベースのバックアップを手動で取ることをお勧めします。これにより、リストアポイントを持つことができます。
まず、コントローラーホスト上の linstor-controller と linstor-client パッケージをアップグレードし、その後 linstor-controller を再起動してください。コントローラーは起動し、すべてのクライアントが OFFLINE(VERSION_MISMATCH) を表示するはずです。その後、すべてのサテライトノードで linstor-satellite パッケージをアップグレードし、再起動してください。短い再接続時間の後、すべてのノードが再び ONLINE を表示するはずで、これでアップグレードが完了します。
2.4. コンテナ
LINSTORはコンテナとしても利用可能です。ベースイメージはLINBITのコンテナレジストリ drbd.io にあります。
| LINBITのコンテナイメージリポジトリ（http://drbd.io）は、LINBITの顧客またはLINBITの顧客トライアルアカウントを持っている方のみが利用できます。価格情報を入手したりトライアルを開始するには、LINBITにお問い合わせしてください。また、LINBITの顧客でなくても、LINSTOR SDSのアップストリームプロジェクトであるPiraeusを使用することができます。 |
画像にアクセスするには、まずLINBITカスタマーポータルの認証情報を使ってレジストリにログインする必要があります。
# docker login drbd.io
このリポジトリで利用可能なコンテナは以下です。
-
drbd.io/drbd9-rhel8
-
drbd.io/drbd9-rhel7
-
drbd.io/drbd9-sles15sp1
-
drbd.io/drbd9-bionic
-
drbd.io/drbd9-focal
-
drbd.io/linstor-csi
-
drbd.io/linstor-controller
-
drbd.io/linstor-satellite
-
drbd.io/linstor-client
利用可能なイメージとバージョンの最新リストは、ブラウザで http://drbd.io を開くことで取得できます。イメージリポジトリをHTTPで閲覧してください。ただし、レジストリのイメージ自体は関連する docker pull コマンドを使用してHTTPS経由で取得されます。
カーネルモジュールをロードするには、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
約10秒後には、linstor node list でオンラインの状態が表示されます。もちろん、サテライトプロセスは、コントローラがサテライトノードの存在を把握する前に開始される可能性があります。
コントローラをホストしているノードが LINSTOR クラスタにストレージを提供する必要がある場合、そのノードをノードとして追加し、linstor-satellite サービスも開始する必要があります。
|
他のサービスが必要なデバイスを作成する機会を待つようにしたい場合（つまり、起動後）、対応する .service ファイルを更新し、Type=simple を Type=notify に変更することができます。
これにより、サテライトはコントローラーが接続し、必要なすべてのデータをサテライトに送信し、サテライトがデバイスの起動と実行を少なくとも1回試行するまで、systemd への READY=1 メッセージの送信を遅らせます。
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|" ] この設定は、LVMにDRBDデバイスをスキャンやオープンの試行から拒否するよう指示します。このフィルタを設定しない場合、CPU負荷の増加やLVM操作の停滞が発生する可能性があります。 |
# 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. 複数のノードでストレージプールを共有する
ExosとLVM2のストレージプロバイダーの両方とも、ストレージアレイやドライブに直接接続された複数のサーバーノードのオプションを提供しています。LVM2では、外部ロッキングサービス（lvmlockd）が、vgcreate で --shared オプションを使用して作成されたボリュームグループを管理します。--shared-space は、LINSTORプールを構成する際に、2つ以上のノードからアクセス可能な同じLVM2ボリュームグループを使用するために使用できます。以下の例は、ノードアルファとブラボーからアクセス可能なプールの共有スペース識別子としてLVM2ボリュームグループのUUIDを使用する方法を示しています。
# linstor storage-pool create lvm --external-locking \ --shared-space O1btSy-UO1n-lOAo-4umW-ETZM-sxQD-qT4V87 \ alpha pool_ssd shared_vg_ssd # linstor storage-pool create lvm --external-locking \ --shared-space O1btSy-UO1n-lOAo-4umW-ETZM-sxQD-qT4V87 \ bravo pool_ssd shared_vg_ssd
Exos プールは、共有スペース識別子にデフォルトで Exos プールのシリアル番号を使用します。
linstor-server v1.26.0のリリース時点では、LINSTORのためのExos統合は非推奨となっています。
|
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
| Since version 1.8.0, LINSTOR supports shrinking volume definition size, even for deployed resources, if the resource’s storage layers support it. Use caution when shrinking volume definition sizes for resources with data. Data loss can occur if you do not take cautionary measures such as making backups and shrinking the file system on top of the volume first. |
パラメータ 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に対して、提供された引数で指定した正規表現に一致する名前のリソースが既にデプロイされているノードにはリソースを配置しないように指定することができます。このようにして、配置を避けるために複数のリソースを指定することができます。
補助ノードプロパティを用いたリソース自動配置の制約付け
リソースの自動配置は、指定した補助ノードプロパティを持つノードにリソースを配置する（または配置しない）ように制約することができます。
| この機能は、LINSTORマネージドストレージを使用するKubernetes環境内でリソースの配置を制限しようとしている場合に、特に有用となります。例えば、Kubernetesのラベルに対応する補助ノードのプロパティを設定することができます。このユースケースの詳細については、「LINSTOR Volumes in Kubernetes」LINSTOR User’s Guide の章にある “replicasOnSame” section をご覧ください。 |
引数の --replicas-on-same と --replicas-on-different は、 Aux/ 名前空間内のプロパティの名前を指定します。
次の例は、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 だったからです。
node-1 のノードのプロパティを、 list-properties コマンドを使用して確認することができます。
# 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レイヤーまたはストレージプールプロバイダによるリソースの自動配置の制約
[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
このリソースグループから後で作成する可能性のあるリソースは、 ストレージプールを持つ3つのノードに展開され、DRBD レイヤーでバックアップされた LUKS レイヤー (および暗黙的に “ストレージ” レイヤーでバックアップされています) です。 CSV リストで指定するレイヤーの順序は、”上から下” であり、リスト内の左側に位置するレイヤーが 右側のレイヤーの上に配置されます。
--providers 引数は、指定されたCSVリストに一致するストレージプールにのみ自動リソース配置を制約するために使用できます。この引数を使用すると、展開されるリソースをバックアップするストレージプールを明示的に制御できます。たとえば、クラスターに ZFS、LVM、LVM_THIN のストレージプールが混在している場合、--providers LVM,LVM_THIN 引数を使用することで、--place-count オプションを使用してリソースが 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 | +-------------------------------------------------------------------------------------+
警告: +1 という値は resource-group create --place-count コマンドでは有効ではありません。
これは、このコマンドはリソースをデプロイせず、後でデプロイするためのテンプレートを作成する
だけだからです。
2.13. リソース、リソース定義、およびリソース グループの削除
削除したい LINSTOR オブジェクトの後に delete コマンドを使用して、LINSTOR リソース、リソース定義、およびリソース グループを削除できます。どのオブジェクトを削除するかによって、LINSTOR クラスターおよびその他の関連する LINSTOR オブジェクトに異なる影響があります。
2.13.1. リソース定義の削除
次のコマンドを使用してリソース定義を削除できます:
# linstor resource-definition delete <resource_definition_name>
これにより、指定されたリソース定義が LINSTOR クラスター全体から削除されます。リソースはすべてのノードから削除され、リソース エントリは LINSTOR のデータベース テーブルから削除するようにマークされます。LINSTOR がすべてのノードからリソースを削除した後、リソース エントリは LINSTOR のデータベース テーブルから削除されます。
警告: もしリソース定義に既存のスナップショットがある場合、そのリソース定義を削除することはできません。スナップショットを削除するまでリソース定義は削除できません。このガイドの スナップショットの削除 セクションを参照してください。
2.13.2. リソースの削除
次のコマンドを使用してリソースを削除できます:
# linstor resource delete <node_name> <resource_name>
リソース定義の削除とは異なり、このコマンドは、指定したノード (複数可) から LINSTOR リソースのみを削除します。リソースはノードから削除され、リソースエントリは LINSTOR のデータベーステーブルから削除するようにマークされます。LINSTOR がノードからリソースを削除した後、リソースエントリは LINSTOR のデータベーステーブルから削除されます。
LINSTORリソースを削除すると、リソースそのものを取り除くだけでなく、クラスタに対して影響を及ぼす可能性があります。たとえば、リソースがDRBDレイヤーでバックアップされている場合、3ノードのクラスターの1ノードからリソースを削除すると、リソースに関連する特定のクォーラム関連のDRBDオプションも削除される可能性があります。3ノードクラスターの1ノードからこのようなリソースを削除した後、そのリソースは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.13.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.14. データベースのバックアップと復元
バージョン1.24.0以降、LINSTORにはLINSTORデータベースをエクスポートおよびインポートするためのツールがあります。
このツールには、/usr/share/linstor-server/bin/linstor-database という実行可能ファイルがあります。この実行可能ファイルには、export-db と import-db という2つのサブコマンドがあります。両方のサブコマンドは、linstor.toml 構成ファイルが含まれているディレクトリを指定するために使用できるオプショナルな --config-directory 引数を受け入れます。
重要: 一貫したデータベースのバックアップを確保するために、LINSTORデータベースのバックアップを作成する前に、以下のコマンドに示すように、コントローラーサービスを停止させることでコントローラーをオフラインにしてください。
2.14.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.14.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.14.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 \ --rr-conflict=retry-connect \ 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]] id = "linstor_db" [promoter.resources.linstor_db] start = ["var-lib-linstor.mount", "linstor-controller.service"]
要件に応じて、on-stop-failure アクションを設定し、stop-services-on-exit を設定することも考慮してください。
その後 drbd-reactor を再起動し、構成したすべてのノードで有効にします。
# systemctl restart drbd-reactor # systemctl enable drbd-reactor
drbd-reactor サービスからの警告がログにないことを確認するには、systemctl status drbd-reactor を実行してください。既にアクティブなLINSTORコントローラーがあるため、状況はそのまま維持されます。drbd-reactorctl status linstor_db を実行して、linstor_dbターゲットユニットの健康状態を確認してください。
最後に、重要なのは、LINSTORサテライトサービスを設定して、起動時にLINSTORコントローラーDBのリソースファイルを削除（そして再生成）しないようにすることです。サービスファイルを直接編集せず、systemctl edit を使用してください。LINSTORコントローラーとなる可能性があるすべてのノード、かつLINSTORサテライトでもあるノードでサービスファイルを編集してください。
# systemctl edit linstor-satellite [Service] Environment=LS_KEEP_RES=linstor_db
この変更を行った後、全てのサテライトノードで systemctl restart linstor-satellite を実行する必要があります。
注意: LINSTOR クライアントの使用 というセクションで説明されているように、複数のコントローラに使用するように LINSTOR クライアントを構成することを確認し、また、Proxmox プラグインなどの統合プラグインも複数の LINSTOR コントローラに対応するように構成しているか確認してください。
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は以下の順序で以下のオブジェクトのプロパティをクエリします:
-
Volume definition
-
Resource
-
Resource definition
-
Node
もし、それらのオブジェクトのどれもが 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 --no-utf8 storage-pool list +--------------------------------------------------------------+ | StoragePool | Node | Driver | PoolName | ... | |--------------------------------------------------------------| | thin-lvm | linstor-a | LVM_THIN | drbdpool/thinpool | ... | | thin-lvm | linstor-b | LVM_THIN | drbdpool/thinpool | ... | | thin-lvm | linstor-c | LVM_THIN | drbdpool/thinpool | ... | | thin-lvm | linstor-d | LVM_THIN | drbdpool/thinpool | ... | +--------------------------------------------------------------+
次のコマンドを使用して、linstor-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",
次の表は、どのレイヤーの後にどの子レイヤーが続くかを示しています。
[cols=”>1,<5″] |
Layer |
Child layer |
DRBD |
CACHE, WRITECACHE, NVME, LUKS, STORAGE |
CACHE |
WRITECACHE, NVME, LUKS, STORAGE |
WRITECACHE |
CACHE, NVME, LUKS, STORAGE |
NVME |
CACHE, WRITECACHE, LUKS, STORAGE |
LUKS |
STORAGE |
STORAGE |
– |
| 1つの層は、層リストに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デバイス を構成します。
-
Exos [廃止されました]: この特別なストレージプロバイダは現在「特別なサテライト」上で実行する必要があります。EXOS Integration 章を参照してください。
-
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 10G_nic 192.168.43.231
ネットインターフェイスは IP アドレスのみで識別されます。名前は任意であり、Linux で使用される NIC 名とは関係ありません。次に、ネットインターフェイスをノードに割り当てて、ノードの DRBD トラフィックが対応する NIC を介してルーティングされるようにします。
# linstor node set-property node-0 PrefNic 10G_nic
| ストレージプールに「PrefNic」プロパティを設定することもできます。ストレージプールを使用するリソースからの DRBD トラフィックは、対応する NIC 経由でルーティングされます。ただし、ここで注意が必要です。ディスクレスストレージを必要とする DRBD リソース (たとえば、DRBD クォーラムの目的でタイブレーカーの役割を果たしているディスクレス ストレージ) は、「default」ネットインターフェイスの「PrefNic」プロパティを設定するまで、デフォルトのサテライトノードのネットインターフェイスを通過します。セットアップが複雑になる可能性があります。ノードレベルで「PrefNic」プロパティを設定する方がはるかに簡単で安全です。これにより、ディスクレスストレージプールを含む、ノード上のすべてのストレージプールが優先 NIC を使用します。 |
必要なのは、 コントローラー-サテライト通信 のためのインターフェースを追加することです。上記の node interface create コマンドを使用してインターフェースを追加できます。その後、接続を修正して、アクティブなコントローラー-サテライト接続にします。たとえば、すべてのノードに 1G-satconn という名前のインターフェースを追加した場合、インターフェースを追加した後に、次のコマンドを入力してLINSTORにこのインターフェースをコントローラー-サテライト通信に使用するよう指示できます。
# linstor node interface modify node-0 1G-satconn --active
この変更を確認するためには、linstor node interface list node-0 コマンドを使用してください。コマンドの出力には、StltCon ラベルが 1G-satconn インターフェースに適用されていることが表示されるはずです。
この方法では指定された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 リソースを持ちません。
| LINSTOR が Kubernetes や OpenNebula などの別の環境内にデプロイされているノードを退避する場合は、リソースを退避する前に、ノードの LINSTOR でサポートされているワークロードをクラスター内の別のノードに移動する必要があります。Kubernetes 環境については Kubernetes でのノードの退避 を参照してください。OpenNebula の LINSTOR ノードの場合、ノードのリソースを退避する前に、ノードがホストする OpenNebula LINSTOR ベースの仮想マシンをクラスター内の別のノードにライブマイグレードする必要があります。 |
次の手順でノードを退避します。
-
退避するノード上のリソースが “InUse” であるかどうかを確認します。 “InUse” ステータスは、リソースが DRBD Primary 状態です。ノードを正常に退避させるには、ノード上のリソースを “InUse” にしないでください。そうしないと、LINSTOR は退避中にノードから “InUse” リソースを削除できません。
-
linstor node evacuate <node_name>を実行します。退避ノード上のリソースに適した代替ノードがない場合は、警告が表示されます。たとえば、3 つのノードがあり、1 つを退避したいが、リソースグループで配置数が 3 に設定されている場合、ノードが退避ノードからリソースを削除できないという警告が表示されます。 -
ノードの
linstor node listのステータスが、 “Online” ではなく、 “EVACUATE” であることを確認してください。 -
linstor resource listコマンドを使用して、ノード上のリソースの「状態」ステータスを確認してください。ノードのリソースに含まれるデータセットのサイズに応じて、しばらくの間同期が行われる活動が見られるはずです。 -
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 resource1 snap1
リソースは、最新のスナップショットにのみロールバックできます。古いスナップショットに戻すには、まず中間のスナップショットを削除してください。
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 オプションを指定した場合も同様です。
|
3.12.4. Snapshot Shipping Within a Single LINSTOR Cluster
同じクラスタ内でスナップショットを転送したい場合は、単純にローカルコントローラを指す 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. Configuring the Number of Local Snapshots and Remote Backups to Keep
物理ストレージは無限ではなく、リモートストレージにはコストがかかるため、スナップショットやバックアップの保存数に制限を設けるとよいでしょう。
--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ページも参照できます。
=== LINSTORにおけるストレージの過剰割り当て
LINSTORサーバーバージョン1.26.0以降、LINSTORがオーバープロビジョニングストレージを制限する方法を制御することができるようになりました。これには MaxOversubscriptionRatio 、MaxFreeCapacityOversubscriptionRatio 、 MaxTotalCapacityOversubscriptionRatio の3つのLINSTORオブジェクトプロパティを使用します。これらのプロパティは、LINSTORストレージプールまたはLINSTORコントローラーオブジェクトのいずれかに設定できます。これらのプロパティをコントローラーレベルで設定すると、クラスター内のすべてのLINSTORストレージプールに影響します。ただし、同じプロパティが特定のストレージプールにも設定されている場合は、そのストレージプールにのみ影響します。この場合、ストレージプールに設定されたプロパティ値がコントローラに設定されたプロパティ値より優先されます。オーバーサブスクリプション比率の値を設定することで、LINSTORがストレージプールで行うオーバープロビジョニングを制御することができます。物理的に説明できないレベルにストレージのオーバープロビジョニングが達することを望まない場合に便利です。次のサブセクションでは、異なるオーバープロビジョニング制限プロパティについて説明します。
==== 最大空き容量オーバープロビジョニング比率の設定
LINSTORサーバーのバージョン1.26.0より前では、薄膜プロビジョニングされたLVMボリュームまたはZFS zpoolでバックアップされた
ストレージプールのオーバープロビジョニングを設定する際、ストレージプール内に残っている空き容量に基づいていました。
LINSTORサーバーのバージョン1.26.0以降では、このオーバープロビジョニングの方法はまだ可能です。
MaxFreeCapacityOversubscriptionRatio プロパティに値を設定することで、LINSTOR ストレージプールまたは LINSTOR
コントローラのいずれかに、これを実行できます。この比率の値を設定すると、ストレージプール内の残りの空き容量は
比率値によって乗算され、これがストレージプールからプロビジョニングできる新しいボリュームの最大許容サイズとなります。
デフォルトで、MaxFreeCapacityOversubscriptionRatio の値は 20 になっています。
LINSTORサテライトノードクラスターにある3つのLINSTORサテライトノード（node-0からnode-2まで）上の 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.14.5. 最大総容量のオーバープロビジョニング比率の設定
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.14.6. オーバープロビジョニングのための最大オーバーサブスクリプション比率の設定
MaxOversubscriptionRatio プロパティをLINSTORストレージプールやLINSTORコントローラーオブジェクトのいずれかに設定した場合、それは MaxFreeCapacityOversubscriptionRatio および MaxTotalCapacityOversubscriptionRatio プロパティの両方の値として機能することができます。ただし、MaxOversubscriptionRatio プロパティは、他の2つのオーバーサブスクリプションプロパティのいずれかの値としてのみ機能しますが、他のプロパティが設定されていない場合です。デフォルトでは、MaxOversubscriptionRatio プロパティの値は20であり、他の2つのオーバーサブスクリプションプロパティのデフォルト値と同じです。
LINSTORコントローラーの MaxOversubscriptionRatio プロパティに異なる値を設定するには、例えば、次のコマンドを入力してください：
# linstor controller set-property MaxOversubscriptionRatio 5
コマンド例でプロパティ値を5に設定することで、10GiBのストレージプールを最大40GiBまで オーバープロビジョニングすることができます。
3.14.7. 複数のオーバー・プロビジョニング・プロパティにおける値の設定が及ぼす影響
前述の通り、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.15. ディスクの追加と削除
LINSTORは、ディスクレスとディスク搭載のリソースを変換することができます。これは、resource toggle-disk コマンドによって実現され、構文は resource create に類似しています。
例えば ‘alpha’ 上にディスクレスリソース backups のディスクを追加するには以下のようにします。
# linstor resource toggle-disk alpha backups --storage-pool pool_ssd
Remove this disk again:
# linstor resource toggle-disk alpha backups --diskless
3.15.1. ノード間でのディスクの移行
リソースを冗長性を減らすことなくノード間で移動するには、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.16. LINSTOR を使用したDRBD Proxy 設定
LINSTORは、DRBD Proxyが接続するノード上で実行されることを期待しています。別のノードのDRBD Proxy経由の接続は、今のところサポートしていません。
クラスターは、ローカルネットワーク内にノード ‘alpha’ と ‘bravo’、リモートサイトにノード ‘charlie’ が存在し、それぞれのノードに backups というリソース定義がデプロイされているとします。その後、DRBD Proxy を ‘charlie’ への接続に有効にすることができます。
# linstor drbd-proxy enable alpha charlie backups # linstor drbd-proxy enable bravo charlie backups
DRBD Proxyの設定は、次のようなコマンドでカスタマイズすることができます。
# linstor drbd-proxy options backups --memlimit 100000000 # linstor drbd-proxy compression zlib backups --level 9
LINSTORは、長距離レプリケーションのためのDRBD構成を自動的に最適化しませんので、 おそらくプロトコルなどのいくつかの構成オプションを設定したいと思うでしょう。
# linstor resource-connection drbd-options alpha charlie backups --protocol A # linstor resource-connection drbd-options bravo charlie backups --protocol A
LINBITに連絡して、構成の最適化に関する支援を受けてください。
3.16.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.17. 外部データベースプロバイダー
LINSTORはPostgresqlやMariaDBのような外部データベースとともに動作させることもでき、バージョン 1.1.0 以降では etcd キーバリューストアもサポートされています。
外部データベースを使用するには、設定する追加手順がいくつかあります。linstorで使用するためのDB/スキーマとユーザーを作成し、/etc/linstor/linstor.toml でこれを設定する必要があります。
3.17.1. PostgreSQL
サンプルのPostgreSQLの linstor.toml は、次のようになります:
[db] user = "linstor" password = "linstor" connection_url = "jdbc:postgresql://localhost/linstor"
3.17.2. MariaDB
MariaDBのサンプル linstor.toml は以下のようになります:
[db] user = "linstor" password = "linstor" connection_url = "jdbc:mariadb://localhost/LINSTOR?createDatabaseIfNotExist=true"
注意: LINSTORのスキーマ/データベースは LINSTOR として作成されますので、MariaDBの接続文字列が
上記の例のように LINSTOR スキーマを参照していることを確認してください。
3.17.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.18. 複数のLINSTORコントローラー
LINSTORコントローラーには、以下のパスに配置される必要がある設定ファイルがあります： /etc/linstor/linstor.toml。
最新の構成例はこちらで見つけることができます: linstor.toml-example
3.18.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.18.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
コントローラーの設定に必要です。 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のコントローラをLINSTOR設定のTOMLファイル
(/etc/linstor/linstor.toml)で指定していない場合は、
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.19. LINSTOR Satellite の設定
LINSTOR Satelliteソフトウェアには、TOMLファイル形式を使用したオプションの設定ファイルがあり、次のパスに配置する必要があります：/etc/linstor/linstor_satellite.toml
最近の構成例は次のとおりです: linstor_satellite.toml-example
3.20. ロギング
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クライアントを使用してロギングレベルを変更した場合、 ノードが再起動するなどのデプロイメントで、設定は持続しません。
-
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.21. 監視
LINSTOR 1.8.0 以降、 Prometheus /metrics HTTP パス がLINSTOR および JVM 固有の方法で提供されています。
/metrics パスは LINSTOR のレポートデータ量を減らすために 3 つの GET 引数もサポートします。
-
resource -
storage_pools -
error_reports
これらはすべてデフォルトで true であり、無効にするには、例えば error-report
データの場合 http://localhost:3370/metrics?error_reports=false とします。
3.22. サテライトへの安全な接続
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.23. 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コントローラーと LDAPサーバー間を通過する LINSTOR REST API HTTPS およびLDAPSを構成することを強くお勧めします。
3.23.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コントローラーは、上記の例のそれぞれでユーザーのパスワードを求めます。
必要に応じて、--password 引数を使用してユーザーのパスワードをコマンドラインで
入力することができます。その際は慎重に警告を受けることになります。
3.24. DRBDリソースの自動化
このセクションでは、LINSTORがDRBDリソースのために持つ自動化機能の詳細を説明しています。
3.24.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のクォーラム機能およびその動作に関する詳細については、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.24.2. 自動取り除き
サテライトが長期間オフラインになっている場合、LINSTOR は、そのノードを Evictedと宣言するように構成できます。これにより、影響を受ける DRBD リソースが他のノードに自動的に再割り当てされ、最小のレプリカ数が維持されるようになります。
この機能は、次のプロパティを使用して動作を適応させます。
-
DrbdOptions/AutoEvictMinReplicaCountは常に存在すべきレプリカの数を設定します。 このプロパティは、コントローラー上でグローバルデフォルトを変更するか、 特定のリソース定義やリソースグループでのみそのリソース定義やリソースグループの ために変更するために設定できます。このプロパティが空の場合、対応するリソース グループのAutoplacerに設定されたプレースカウントが使用されます。 -
DrbdOptions/AutoEvictAfterTimeは、追い出しがトリガーされる前にノードが オフラインのままでいることができる時間を分単位で記述します。このプロパティは、 コントローラ上でグローバルなデフォルトを変更するために設定したり、異なる動作を 与えるために単一のノード上で設定したりできます。このプロパティのデフォルト値は60分です。 -
DrbdOptions/AutoEvictMaxDisconnectedNodesは、同時に到達不能になることが できるノードの割合を設定します（どんな理由であれ）。指定された割合以上の ノードが同時にオフラインになると、コントローラからの接続問題と見なされるため、 この場合、オート追い出しはトリガーされません。このプロパティはコントローラにのみ設定でき、 値は0から100の間でしか受け入れられません。デフォルト値は34です。オート追い出し機能を オフにしたい場合は、単純にこのプロパティを0に設定してください。 どれだけのサテライトが到達不能であっても常にオート追い出しを トリガーしたい場合は、100に設定してください。 -
DrbdOptions/AutoEvictAllowEvictionは、ノードが追い出されるのを防ぐ追加プロパティです。 これは、例えばメンテナンスのためにノードをシャットダウンする必要がある場合など、 さまざまなケースで役立ちます。コントローラ上でこのプロパティを設定してグローバルなデフォルトを 変更するか、個々のノードで異なる動作をさせるために設定することができます。 このプロパティは、値としてtrueとfalseを受け入れ、デフォルトではコントローラ上でtrueに設定されています。 コントローラ上でこれをfalseに設定することで、自動追い出し機能をオフにすることが できますが、個々のノードに異なる値をすでに設定している場合、これは完全に機能しないかもしれません。 なぜなら、その値がグローバルデフォルトより優先されるからです。
LINSTORコントローラーがサテライトとの接続を失った場合、再接続を試みるだけでなく、
そのサテライト用のタイマーを開始します。そのタイマーが DrbdOptions/AutoEvictAfterTime を
超え、かつそのサテライト上のDRBDリソースへのすべてのDRBD接続が切断されると、
コントローラーは DrbdOptions/AutoEvictMaxDisconnectedNodes が達成されたかどうかを
確認します。もし、そうでない場合、および DrbdOptions/AutoEvictAllowEviction が
対象のノードでtrueの場合、サテライトはEVICTEDとマークされます。
同時にコントローラは、全てのDRBDリソースについて、リソースの数が
まだ DrbdOptions/AutoEvictMinReplicaCount よりも多いかどうかを確認します。
もし多い場合、そのリソースはDELETEDとマークされます。もし成功しない場合、
対応するリソースグループの設定で自動配置が開始されます。自動配置が失敗した場合、
コントローラーは後で再度試行します。新しいノードの追加などの変更が行われることで、
別の結果が可能になるかもしれない場合があります。自動配置が必要なリソースは、
対応する自動配置が成功した場合にのみ削除マークが付けられます。
サテライトは自身を退去した場合、コントローラーとの接続を再確立することは できません。ノードが動作していても、手動で再接続を試みても失敗します。サテライトを 削除することもできません。サテライトは復元することができます。これにより、 サテライトからEVICTEDフラグが削除され、再度使用できるようになります。 以前に設定されたネットワークインターフェース、ストレージプール、プロパティ、 および同様のエンティティ、非DRBD関連のリソース、およびLINSTORが他の場所に自動配置できなかった リソースはまだサテライト上にあります。サテライトを復元するには、次のコマンドを使用してください:
# linstor node restore [nodename]
そのノードにあった全てのもの、ノード自体も含めて全てを捨て去りたい場合は、
代わりに node lost コマンドを使用する必要があります。
3.24.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 オプションを設定する効果の優先順位は、最も高いものから最も低いものまで次の通りです。
-
Resource definition – Resource group – Controller
自動ディスク割り当てオプションの解除
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.24.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 コマンドもそれに応じて表示されます。
╭──────────────────────────────────────────────────────────────────────────────────────────────╮ ┊ 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.25. 外部 DRBD メタデータの使用
デフォルトでは、LINSTOR は DRBD リソースを作成する際に 内部の DRBD メタデータ を使用します。 もし 外部の DRBD メタデータ を使用したい場合は、クラスタ内の LINSTOR ストレージプールの名前を StorPoolNameDrbdMeta プロパティに設定することで可能です。
StorPoolNameDrbdMeta プロパティを、以下の LINSTOR オブジェクトに設定できます。優先度の増加順にリストされています。
-
node–resource-group–resource-definition–resource–volume-group–volume-definition
たとえば、ノードレベルでプロパティを設定すると、優先順位の高いすべてのLINSTORオブジェクトに適用されます。ただし、プロパティがより高い優先順位のLINSTORオブジェクトにも設定されている場合、適用可能なDRBDリソースに対して最も優先度の高いLINSTORオブジェクトに設定されたプロパティ値が優先されます。
LINSTORを使用して新しいDRBDリソースを作成する際に、StorPoolNameDrbdMeta プロパティがDRBDリソースに適用される場合、プロパティを設定するLINSTORオブジェクトに基づいて、LINSTORはストレージプール内に2つの新しい論理ボリュームを作成します。1つはリソースデータのストレージ用であり、2つ目はリソースのDRBDメタデータを格納するためのものです。
StorPoolNameDrbdMeta プロパティを設定、変更、または削除しても、既存の LINSTOR で管理されている DRBD リソースに影響はありません。
3.25.1. 外部 DRBD メタデータ LINSTOR プロパティの設定
ノードレベルでプロパティを設定するには、例えば、以下のコマンドを入力してください:
# linstor node set-property <node-name> StorPoolNameDrbdMeta <storage-pool-name>
3.25.2. 外部 DRBD メタデータ LINSTOR プロパティの一覧化
指定されたLINSTORオブジェクトにプロパティが設定されているかを確認するには、 list-properties サブコマンドを使用できます。
# linstor node list-properties node-0
コマンドの出力には、指定されたLINSTORオブジェクトのセットプロパティとその値のテーブルが 表示されます。
╭─────────────────────────────────────╮ ┊ Key ┊ Value ┊ ╞═════════════════════════════════════╡ [...] ┊ StorPoolNameDrbdMeta ┊ my_thin_pool ┊ ╰─────────────────────────────────────╯
3.26. QoS設定
LINSTORは、ブロックI/O操作に関連するカーネル変数に対応するsysfsプロパティを使用して、管理されたリソースのためのQoSを実装します。これらのsysfsプロパティは、帯域幅（1秒あたりのバイト数）、またはIOPS、またはその両方の制限になりえます。
sysfsファイルとそれに対応するLINSTORのプロパティは以下の通りです。
[cols=”3,2″] |
sysfs ( |
LINSTOR Property |
|
|
|
|
|
|
|
|
3.26.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.26.2. 複数の DRBD デバイスを持つ LINSTOR ボリュームの QoS 設定
単一の LINSTOR ボリュームは、複数の DRBD デバイスで構成できます。たとえば、外部メタデータを含む DRBD には、データ (ストレージ) デバイス、メタデータ デバイス、および LINSTOR に提供される複合 DRBD デバイス (ボリューム) の 3 つの下位デバイスがあります。データデバイスとメタデータデバイスが異なる下位ディスクに対応している場合、そのような LINSTOR ボリュームに sysfs プロパティを設定すると、ローカルデータ (ストレージ) 下位デバイスのみが対応する /sys/fs/cgroup/blkio/ ファイルのプロパティ値を受け取ります。DRBD メタデータの下位デバイスや、LINSTOR で提供される複合下位デバイスは値を受け取りません。ただし、DRBD のデータとそのメタデータが同じ下位ディスクを共有する場合、QoS 設定はデータとメタデータ操作の両方のパフォーマンスに影響します。
3.26.3. NVMe の QoS設定
LINSTORのリソース定義に nvme-target と nvme-initiator リソースがある場合、各ノードの両方のデータ（ストレージ）バッキングデバイスは、sysfsプロパティの値を受け取ります。ターゲットの場合、データバッキングデバイスは、LVMまたはZFSのいずれかのボリュームになります。一方、イニシエータの場合、データバッキングデバイスは、接続されている nvme-device になります。その際、LUKS、NVMe、DRBDなど、その上にある他のLINSTORレイヤーがあっても関係ありません（詳細は DRBDを使わないLINSTOR を参照）。
3.27. ヘルプの利用
3.27.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.27.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.27.3. コミュニティの助けを借りる
コミュニティからの支援を受けるには、こちらのDRBDユーザーメーリングリストに登録してください: https://lists.linbit.com/listinfo/drbd-user
3.27.5. 有料のサポートと開発
必要に応じてリモートインストールサービス、24時間365日のサポート、認定リポジトリへのアクセス、または機能開発を購入したい場合は、お問い合わせください。お問い合わせ先: +1-877-454-6248 (1-877-4LINBIT)、国際番号: +43-1-8178292-0、メール: [email protected]
GUIでLINSTORを管理
4. LINBIT SDS GUI
LINBIT SDS GUIは、現在テクノロジープレビュー段階にあるLINSTOR®クライアントの代替品です。このコンポーネントはプロプライエタリであり、利用するにはLINBIT®の顧客専用リポジトリにアクセスする必要があります。
4.2. LINSTOR SDS GUI のインストール
LINSTOR コントローラーと同じノードに LINSTOR GUI パッケージをインストールし linstor-controller サービスを再起動します。
yum/dnf ベースのディストリビューションでは、次の方法でソフトウェアをインストールできます。
yum install linstor-guiapt ベースのディストリビューションでは、次の方法でソフトウェアをインストールします。
apt install linstor-guiKubernetes では、LINSTOR SDS GUI は linstor-controller v1.15.0 以降組み込まれています。
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.4.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 に信頼されていること、そしてその逆も確認してください。次のシェル関数は、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
上流のピレウスプロジェクトのリファレンスドキュメントには、TLSに関連するすべての利用可能な LinstorCluster および LinstorSatelliteConfiguration リソースオプションが表示されます。
LINSTOR APIのTLSの設定
このセクションでは、LINSTOR APIのTLS設定方法について説明します。このAPIは、LINSTORコントローラーによって提供され、CSIドライバーやオペレータ自体などのクライアントによって使用され、LINSTORクラスターを制御します。
このセクションの指示に従うには、以下に慣れている必要があります:
-
Editing
LinstorClusterresources -
Using either cert-manager or OpenSSL to create TLS certificates
cert-managerを使用してキーと証明書のプロビジョニング
この方法には、クラスター内の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を使用してTLSでLINSTOR APIを保護するために必要な手順が完了しました。 TLSが機能していることを確認するには、 Verifying LINSTOR API TLS Configuration セクションにスキップしてください。
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サーバー用の1つとLINSTOR APIクライアント用の1つの新しいキーを作成してください。
# 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設定の検証
APIが実行され、TLSでセキュリティが確保されていることを、HTTPSエンドポイントに手動で curl コマンドを使用して接続することで検証できます。
# 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。
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ノード接続の状態を制御します。 ==== LINSTORオペレータv2をデプロイメントした後の次のステップ
LINBIT SDSをKubernetesにデプロイした後、この章の [s-kubernetes-basic-configuration-and-deployment], Operator v2デプロイメントにおけるDRBDモジュールローダーの設定:, Operator v2 デプロイメントにおいて DRBD レプリケーション用ホストネットワークを使用する セクションに進むか、または上流のPiraeusプロジェクトの tutorials を参照してください。 === LINSTOR Operator v1のデプロイメント
<<s-kubernetes-deploy-linstor-operator-v2, Operator v2>>. LINSTOR Operator v2 を既にデプロイメント済みの場合は、このセクションをスキップし、 <<s-kubernetes-deploy-external-controller>> から始まるこの章の他のトピックに進んでください。
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>
この秘密の名前は、デフォルトで
drbdiocredとHelmの値で指定されたものと一致しなければなりません。 -
LINSTORのデータベースバックエンドを構成します。デフォルトでは、このチャートはデータベースバックエンドとしてetcdを構成します。オペレータはLINSTORを データストアとしてKubernetesを 直接使用するようにも設定することができます。etcdの経路を選択する場合は、それに対して永続ストレージを構成する必要があります。
-
既存のストレージプロビジョナーをデフォルトの
StorageClassと共に使用してください。 -
永続化を無効にしてください。基本的なテストのみに使用してください。以下の
helm installコマンドに--set etcd.persistentVolume.enabled=falseを追加することで実現できます。
-
-
ストレージガイド を読んで、LINSTORの基本ストレージセットアップを構成してください。
-
セキュリティのデプロイメントを保護するセクション を読み、必要に応じて構成してください。
-
最終段階で、
helm installコマンドで--setを使用して適切なカーネルモジュールインジェクタを選択します。-
使用しているディストリビューションに応じてインジェクターを選択してください。適切なバージョンを、
drbd9-rhel7、drbd9-rhel8、その他のいずれかから、 http://drbd.io/ で最新バージョンを選択してください。drbd9-rhel8イメージは、RHCOS（OpenShift）でも使用する必要があります。SUSE CaaS Platformの場合は、使用しているCaaS Platformのベースシステムに一致するSLESのインジェクターを使用してください（例：drbd9-sles15sp1）。例：operator.satelliteSet.kernelModuleInjectionImage=drbd.io/drbd9-rhel8:v9.1.8
-
ホストマシンに既に存在するモジュールのみを挿入します。モジュールが見つからない場合は、スキップされます。.
operator.satelliteSet.kernelModuleInjectionMode=DepsOnly
-
D他の手段でDRBDをインストールする場合は、カーネルモジュールのインジェクションを無効にしてください。
DepsOnlyによって非推奨設定されています。operator.satelliteSet.kernelModuleInjectionMode=None
-
-
最後にすべてをセットアップする
linstor-opという名前の Helm デプロイメントを作成します。helm repo add linstor https://charts.linstor.io helm install linstor-op linstor/linstor
デプロイメントのさらなるカスタマイゼーションについては、 advanced deployment section で議論されています。 ==== LINSTOR向けKubernetesバックエンド
INSTORコントローラーは、クラスターの状態を永続化するために直接Kubernetes APIを使用することができます。このバックエンドを有効にするには、次のオーバーライドファイルをチャートのインストール中に使用してください。:
etcd:
enabled: false
operator:
controller:
dbConnectionURL: k8sヒント：既存のetcdバックエンドを使用するクラスタを、Kubernetes APIバックエンドに移行することが可能です。移行手順については、charts.linstor.ioの移行手順を参照してください。 ==== 永続ストレージボリュームの作成
pv-hostpath Helmテンプレートを使用して、hostPath 永続ボリュームを作成できます。必要なだけ多くのPVを作成して、設定されたetcd replicas（デフォルトは1）を満たしてください。
nodes= オプションの中で、クラスターノード名に応じて hostPath 永続ボリュームを作成してください。
helm repo add linstor https://charts.linstor.io helm install linstor-etcd linstor/pv-hostpath
デフォルトでは、control-plane ノードごとに PV が作成されます。インストールコマンドに --set "nodes={<NODE0>,<NODE1>,<NODE2>}" を渡すことで、ストレージノードを手動で選択することができます。注意: ノードを参照する正しい値は、kubernetes.io/hostname ラベルの値です。すべてのノードの値をリストアップするには、kubectl get nodes -o custom-columns="Name:{.metadata.name},NodeName:{.metadata.labels['kubernetes\.io/hostname']}" を実行してください。
==== 既存のデータベースの使用
LINSTORは既存のPostgreSQL、MariaDB、またはetcdデータベースに接続することができます。たとえば、次の構成で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.3.8. Operator v1でのストレージの設定
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は参照されたVolumeGroups、ThinPoolsなどが存在することを想定しています。devicePaths: [] オプションを使用すると、LINSTORにデバイスをプールのために自動的に準備させることができます。自動構成の対象となるのは、次のようなブロックデバイスです：
-
ルートデバイス（パーティションなし）
-
パーティション情報が含まれていない
-
1Gバイトを超える容量
デバイスの自動構成を有効にするには、storagePools エントリーの devicePaths キーを設定します。
storagePools:
lvmPools:
- name: lvm-thick
volumeGroup: drbdpool
devicePaths:
- /dev/vdb
lvmThinPools:
- name: lvm-thin
thinVolume: thinpool
volumeGroup: linstor_thinpool
devicePaths:
- /dev/vdc
- /dev/vdd現在、このメソッドは LVM および LVMTHIN ストレージプールの作成をサポートしています。
LVM ストレージプールの設定
lvmPools エントリの利用可能なキーは次の通りです。* name LINSTORストレージプールの名前。[必須] * volumeGroup 作成するVGの名前。[必須] * devicePaths このプールに構成するデバイス。認識されるには空であり、1GiB以上でなければなりません。[オプション] * raidLevel LVMレイドレベル。[オプション] * vdo VDOの有効化（サテライトにVDOツールが必要）。[オプション] * vdoLogicalSizeKib 作成されるVGのサイズ（VDOを使用してバッキングデバイスより大きいことが予想されます）。[オプション] * vdoSlabSizeKib VDOのスラブサイズ。[オプション] [VDO]: https://www.redhat.com/en/blog/look-vdo-new-linux-compression-layer
LVM Thin Poolの設定
-
name: LINSTOR ストレージプールの名前。[必須] *volumeGroup: シンプールに使用するVG。devicePathsを使用する場合は、これを`””`に設定する必要があります。これは、デバイスの準備時には、LINSTORがVG名の構成を許可していないためです。[必須] *thinVolume: シンプールの名前。[必須] *devicePaths: このプールに構成するデバイス。認識されるには空であり、1GiB以上である必要があります。[オプション] *raidLevel: LVMのRAIDレベル。[オプション] 注意: LINSTORがLVMシンプール用に作成するボリュームグループは常に”linstor_$THINPOOL”の形式になります。
ZFS ストレージプールの設定
-
nameLINSTORストレージプールの名前。[必須] *zPool使用するzpoolの名前。すべてのマシンにすでに存在している必要があります。[必須] *thinスリンプロビジョニングを使用する場合はtrue、それ以外はfalse。[必須]
automaticStorageType の使用（非推奨）
すべての適格なデバイスは、すでに storagePools セクションを使用して準備されていない限り、 operator.satelliteSet.automaticStorageType の値に従って準備されます。デバイスはデバイス名に基づいてストレージプールに追加されます（つまり、すべての /dev/nvme1 デバイスは autopool-nvme1 プールの一部となります）。operator.satelliteSet.automaticStorageType の可能な値は以下の通りです： * None: 自動設定なし（デフォルト） * LVM: LVM（厚い）ストレージプールを作成 * LVMTHIN: LVMスリム型ストレージプールを作成 * ZFS: ZFSベースのストレージプールを作成（未検証）
==== オペレーター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つの追加キーを含める必要があります。
-
client.certは、認証のためにetcdに提示されるPEM形式の証明書です。 -
client.keyは上記のクライアント証明書に対応する、PKCS8形式のプライベートキーです。
鍵は openssl を使用して PKCS8 形式に変換できます。
openssl pkcs8 -topk8 -nocrypt -in client-key.pem -out client-key.pkcs8
5.3.9. オペレーターv1デプロイメントにおけるLINSTORコンポーネント間のセキュアな通信の設定
LINSTORのコンポーネント間のデフォルト通信はTLSでセキュリティ保護されていません。これがセットアップに必要な場合は、次の3つの方法のいずれかを選択してください: // “cert-manager”は製品名なので元のケースを保持します
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を使用する場合、常に <リリース名>-cs.<ネームスペース>.svc となります。
|
コントローラーとノードのポッドに渡すことができるKubernetesのシークレットを作成してください。
kubectl create secret generic linstor-control --type=kubernetes.io/tls \ --from-file=ca.crt=ca.crt --from-file=tls.crt=linstor-control.crt \ --from-file=tls.key=linstor-control.key kubectl create secret generic linstor-satellite --type=kubernetes.io/tls \ --from-file=ca.crt=ca.crt --from-file=tls.crt=linstor-satellite.crt \ --from-file=tls.key=linstor-satellite.key kubectl create secret generic linstor-api --type=kubernetes.io/tls \ --from-file=ca.crt=client-ca.crt --from-file=tls.crt=linstor-api.crt \ --from-file=tls.key=linstor-api.key kubectl create secret generic linstor-client --type=kubernetes.io/tls \ --from-file=ca.crt=client-ca.crt --from-file=tls.crt=linstor-client.crt \ --from-file=tls.key=linstor-client.key
作成したシークレットの名前を helm install に渡します。
linstorHttpsControllerSecret: linstor-api
linstorHttpsClientSecret: linstor-client
operator:
controller:
sslSecret: linstor-control
satelliteSet:
sslSecret: linstor-satellite作成したシークレットの名前を helm install に渡します。
===== LINSTOR のパスフレーズを自動設定
LINSTORは暗号化された情報をサポートするために機密データを保存する必要があります。このデータはマスターパスフレーズによって保護されています。パスフレーズは最初のチャートインストール時に自動的に生成されます。
カスタムのパスフレーズを使用したい場合は、それを秘密情報に保存してください。
kubectl create secret generic linstor-pass --from-literal=MASTER_PASSPHRASE=<password>
インストール時に、次の引数を helm コマンドに追加します:
--set operator.controller.luksSecret=linstor-pass
5.3.10. 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
重要: LINBITのコンテナイメージリポジトリ (http://drbd.io) は、前述のおよび今後の kubectl create コマンドで使用されますが、LINBITのお客様またはLINBITの顧客試用アカウントを持っている方のみ利用可能です。 価格情報の確認やトライアルの開始についてはLINBITにお問い合わせください。 また、LINBITのお客様でなくても、LINSTOR SDSアップストリームプロジェクトであるPiraeusを利用することもできます。
sp-values.yaml を介してインストール時に定義されたLINSTORストレージプール、永続的な hostPath ボリューム、3つのetcdレプリカ、ホストカーネルのためにDRBDカーネルモジュールをコンパイルしてインストールします。
これはほとんどの基本的なデプロイメントに適しているはずです。 このデプロイメントでは、このコマンドをよりポータブルにするために、事前にコンパイルされたDRBDカーネルモジュールを使用していません。 事前にコンパイルされたバイナリを使用すると、より高速なインストールとデプロイメントが可能です。 Compile オプションを使用することは、大規模なKubernetesクラスターでの使用をお勧めしません。
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ストレージプールでインストールを行い、既に作成されたPostgreSQL DB（できればクラスタ化されたもの）を使用し、etcdの代わりに既にコンパイルされた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.3.11. Helm デプロイメントの終了
クラスターのストレージインフラストラクチャを誤って重要なコンポーネントを削除することを防ぐために、Helmのデプロイメントを削除する前にいくつかの手動手順を実行する必要があります。
1.LINSTORコンポーネントで管理されているすべてのボリュームクレームを削除します。LINSTORによって管理されているボリュームクレームのリストを取得するためには、次のコマンドを使用できます。リストされたボリュームのいずれも必要なデータを保持していないことを確認した後、生成された kubectl delete コマンドを使用して削除できます。
+
$ kubectl get pvc --all-namespaces -o=jsonpath='{range .items[?(@.metadata.annotations.volume\.beta\.kubernetes\.io/storage-provisioner=="linstor.csi.linbit.com")]}kubectl delete pvc --namespace {.metadata.namespace} {.metadata.name}{"\n"}{end}'
kubectl delete pvc --namespace default data-mysql-0
kubectl delete pvc --namespace default data-mysql-1
kubectl delete pvc --namespace default data-mysql-2
+ 警告: これらのボリュームを一旦削除すると、回復できません。
-
LINSTORコントローラーとサテライトリソースを削除してください。
LINSTORのサテライトやコントローラの展開は、
LinstorSatelliteSetリソースとLinstorControllerリソースで制御されます。デプロイメントに関連するリソースは、kubectlを使用して削除することができます。kubectl delete linstorcontroller <helm-deploy-name>-cs kubectl delete linstorsatelliteset <helm-deploy-name>-ns
短い待機後、コントローラーとサテライトポッドは終了すべきです。実行が継続する場合は、エラーの確認が可能です（それらは関連するすべてのポッドが終了した後にのみ削除されます）。
-
Helmデプロイメントを削除してください。
すべての PVC を削除し、すべての LINSTOR ポッドが終了した場合、Helm デプロイメントをアンインストールできます。
helm uninstall linstor-op
+ NOTE: ヘルムの現行ポリシーにより、
LinstorControllerと`LinstorSatelliteSet` という名前のカスタムリソース定義は、このコマンドでは削 除されません。 ヘルムがCRDに関する現在の立場に関する詳細情報は、 こちら で確認できます。 ==== Operator v1のための高度なデプロイメントオプション
Helmチャートは、高度なユースケースのためのさらなるカスタマイズオプションを提供します。
重要: LINBITのコンテナイメージリポジトリ（http://drbd.io）は、以下のHelmチャートで使用されており、LINBITのお客様またはLINBITの顧客試用アカウントを通じてのみ利用可能です。 価格情報や試用を始めるためのLINBITへのお問い合わせ。あるいは、LINBITのお客様でなくても使用できる、LINSTOR SDSのアップストリームプロジェクトである Piraeusを使用することもできます。
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 | コンテナのリソース要求と制限を設定します。詳細は[「kubernetes.io/docs/tasks/configure-pod-container/assign-cpu-resource」(Kubernetesのドキュメント)]を参照してください。
ほとんどのコンテナは、最小限のリソースが必要ですが、例外があります:
|
| 4 | アフィニティと寛容度は、ポッドがクラスター上でスケジュールされる場所を決定します。アフィニティと寛容度に関する Kubernetes ドキュメントは、 Kubernetes docs on affinity and toleration を参照してください。これは、operator.satelliteSet および csi.node* の値に特に重要かもしれません。LINSTOR永続ボリュームを使用してポッドをスケジュールする場合、ノードには実行中の LINSTOR サテライトと LINSTOR CSI ポッドが必要です。 |
| 5 | LINSTOR コントローラおよび [satellites] に渡す追加の環境変数を設定します。
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.3.12. Operator v1における高可用性デプロイメント
LINSTOR Operator v1 デプロイメント内のすべてのコンポーネントのハイアベイラビリティデプロイメントを作成するには、 アップストリームガイドを参照してください。デフォルト値は、コンポーネントを複数のレプリカにスケーリングすることで、レプリカが異なるノードに配置されるように選択されています。これにより、単一ノードの障害がサービスを中断しないようになっています。注意: LINBIT SDSをLINSTOR Operator v2 を使用してKubernetesに展開した場合、ハイアベイラビリティがデフォルトでデプロイメントに組み込まれています。 ===== 高可用性コントローラーを使用した高速ワークロードフェイルオーバー
ノードの障害が発生すると、Kubernetes はステートフルなワークロードの再スケジューリングに非常に慎重です。これは、ポッドが到達不能なノードから移動するのに15分以上かかる可能性があることを意味します。DRBD と LINSTOR が利用可能な情報を活用することで、このプロセスを大幅に高速化することが可能です。
LINSTOR ハイアベイラビリティ コントローラ（HA コントローラ）は、LINSTOR を使用してストレージを利用する状態を持つワークロードのフェイルオーバー プロセスを高速化します。少なくとも1つの DRBD リソースにアタッチされた任意の Pod を監視および管理します。
HAコントローラーが正しく機能するためには、少なくとも3つのレプリカ（または2つのレプリカ+1つのディスクレス・タイブレーカー）が必要です。レプリカ数を低く設定している場合、関連するポッドは無視され、より迅速なフェイルオーバーの対象とはなりません。
HAコントローラーはHelmチャートとしてパッケージ化されており、以下を使用してデプロイメントできます:
$ helm repo update $ helm install linstor-ha-controller linstor/linstor-ha-controller
クラスターでHAコントローラーを使用している場合、すべてのStorageClassesに追加パラメータを設定できます。これらのパラメータにより、ボリュームが誤って読み取り専用で再マウントされることが防がれ、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.3.13. etcdデータベースのバックアップ
etcdデータベースのバックアップ（LINSTOR Operator v1のDeploymentにおいて）を作成し、それを制御ホストに保存するには、以下のコマンドを入力してください:
kubectl exec linstor-op-etcd-0 -- etcdctl snapshot save /tmp/save.db
kubectl cp linstor-op-etcd-0:/tmp/save.db save.dbオペレーターは、既存のLINSTORセットアップを使用するようにサテライトとCSIプラグインを構成できます。これは、ストレージインフラがKubernetesクラスタとは別である場合に役立ちます。ボリュームは、Kubernetesノード上でディスクレスモードでプロビジョニングされ、ストレージノードはバッキングディスクストレージを提供します。
==== 外部LINSTORコントローラを使用したOperator v2のデプロイメント
===== 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
通常、ポッドネットワークはKubernetesクラスターの外部から到達できません。この場合、外部のLINSTORコントローラーはKubernetesクラスター内のサテライトと通信できません。そのため、サテライトがホストネットワーキングを使用するように設定する必要があります。
ホストネットワーキングを使用するには、次のYAML構成をデプロイメントに適用して、LinstorSatelliteConfiguration リソースをデプロイしてください:
apiVersion: piraeus.io/v1
kind: LinstorSatelliteConfiguration
metadata:
name: host-network
spec:
podTemplate:
spec:
hostNetwork: true
外部のLINSTORコントローラー構成を検証
あなたがKubernetesデプロイメントを外部のLINSTORコントローラを使用するように正しく設定したかどうかを確認する方法は、以下を確認することによって行うことができます:
-
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.3.14. 外部のLINSTORコントローラーを使用した Operator v1 のデプロイメント
helm install を実行する際に、LINSTORコントローラーデプロイメントの作成をスキップし、他のコンポーネントを既存のLINSTORコントローラーを使用するように設定するには、次のオプションを使用してください。
-
operator.controller.enabled=falseThis disables creation of theLinstorControllerresource -
operator.etcd.enabled=falseSince no LINSTOR controller will run on Kubernetes, no database is required. -
controllerEndpoint=<url-of-linstor-controller>The HTTP endpoint of the existing LINSTOR controller. For example: http://linstor.storage.cluster:3370/`
すべてのポッドが準備完了になると、LINSTORセットアップでKubernetesクラスターノードがサテライトとして表示されるはずです。
重要: コントローラーとストレージノードは、KubernetesノードがそれらのIPを使用して到達可能である必要があります。
ストレージノード上で既存のストレージプールを参照するストレージクラスを作成してください。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: linstor-on-k8s
provisioner: linstor.csi.linbit.com
parameters:
autoPlace: "3"
storagePool: existing-storage-pool
resourceGroup: linstor-on-k8sストレージクラスを使用してPVCを作成することで、新しいボリュームをプロビジョニングできます。ボリュームはまず、与えられたストレージプール（つまり、ストレージインフラストラクチャ）を持つノードにのみ配置されます。ポッドでボリュームを使用したい場合は、LINSTOR CSIがKubernetesノード上にディスクレスリソースを作成し、ネットワークを介してディスクフルリソースにアタッチします。 === Kubernetes で LINSTOR の操作
コントローラーポッドにはLINSTORクライアントが含まれており、LINSTORと直接やり取りすることが簡単になります。 実行例:
kubectl exec deploy/linstor-controller -- linstor storage-pool list
5.3.15. 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 | kubectl-linstor リリースページ に示されているように、シェル変数 KL_VERS を kubectl-linstor ユーティリティの最新リリース バージョンに設定します。 |
| 2 | シェル変数 KL_ARCH を、デプロイメントに適合して、ユーティリティの利用可能なリリースでサポートされているアーキテクチャに設定してください。 |
INPORTANT: もし貴方のデプロイメントが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> 形式の参照を、そのポッドで使用されているリソースのリストに展開することも可能です。この機能は、問題の調査や高度な機能へのアクセスが必要な場合にのみ使用するべきです。ボリュームの作成などの通常の操作は、 Kubernetesの統合 を介して行うべきです。
=== 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 コマンドを使用して、ストレージプールの情報を一覧表示することができます。
次のコマンドを使用して、ストレージクラスを作成できます:
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 を参照してボリュームをマウントする単純な Pod を作成します。 .my-first-linstor-volume-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: fedora
namespace: default
spec:
containers:
- name: fedora
image: fedora
command: [/bin/bash]
args: ["-c", "while true; do sleep 10; done"]
volumeMounts:
- name: my-first-linstor-volume
mountPath: /data
ports:
- containerPort: 80
volumes:
- name: my-first-linstor-volume
persistentVolumeClaim:
claimName: "my-first-linstor-volume"次のコマンドで Pod を作成できます。
kubectl create -f my-first-linstor-volume-pod.yaml
kubectl describe pod fedora を実行することで、 ポッドのスケジューリング と ボリュームのアタッチメント が成功したことを確認できます。PersistentVolumeClaim を調査すると、今やボリュームにバインドされていることがわかります。
ボリュームを削除するには、いかなるポッドもそれを使用していないことを確認し、kubectl コマンドを使用して PersistentVolumeClaim を削除します。たとえば、作成したばかりのボリュームを削除するには、以下の2つのコマンドを実行します。なお、PersistentVolumeClaim を削除する前に、Pod がスケジュールされていない必要があります。
kubectl delete pod fedora # unschedule the pod. 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.3.16. StorageClass で使用可能なパラメータ
次のストレージクラスには、現在利用可能なすべてのパラメータが含まれています。.
linstor.csi.linbit.com/ は、LINSTOR CSI 特有のパラメーターに対してオプションですが、推奨されています。
|
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: full-example
provisioner: linstor.csi.linbit.com
parameters:
# CSI related parameters
csi.storage.k8s.io/fstype: xfs
# LINSTOR parameters
linstor.csi.linbit.com/autoPlace: "2"
linstor.csi.linbit.com/placementCount: "2"
linstor.csi.linbit.com/resourceGroup: "full-example"
linstor.csi.linbit.com/storagePool: "my-storage-pool"
linstor.csi.linbit.com/disklessStoragePool: "DfltDisklessStorPool"
linstor.csi.linbit.com/layerList: "drbd storage"
linstor.csi.linbit.com/placementPolicy: "AutoPlaceTopology"
linstor.csi.linbit.com/allowRemoteVolumeAccess: "true"
linstor.csi.linbit.com/encryption: "true"
linstor.csi.linbit.com/nodeList: "diskful-a diskful-b"
linstor.csi.linbit.com/clientList: "diskless-a diskless-b"
linstor.csi.linbit.com/replicasOnSame: "zone=a"
linstor.csi.linbit.com/replicasOnDifferent: "rack"
linstor.csi.linbit.com/disklessOnRemaining: "false"
linstor.csi.linbit.com/doNotPlaceWithRegex: "tainted.*"
linstor.csi.linbit.com/fsOpts: "-E nodiscard"
linstor.csi.linbit.com/mountOpts: "noatime"
linstor.csi.linbit.com/postMountXfsOpts: "extsize 2m"
# Linstor properties
property.linstor.csi.linbit.com/*: <x>
# DRBD parameters
DrbdOptions/*: <x>5.3.17. KubernetesでストレージリソースのためのDRBDオプションを設定する
<<s-kubernetes-sc-parameters,>> セクションに示されているように、ストレージクラスの構成内でDRBDオプションを設定できます。ストレージクラスのKubernetesオブジェクトとその名前付きLINSTORリソースグループ（`resourceGroup` パラメータ）との一対一の対応関係のため、ストレージクラスの構成内でDRBDオプションを設定することは、LINSTORリソースグループに対するDRBDオプションの設定と似ています。
いくつかの違いがあります。ストレージクラスの構成内でDRBDオプションを設定すると、これらのオプションはストレージクラスから作成される新しいボリュームにのみ影響します。これらのオプションは既存のボリュームには影響しません。さらに、ストレージクラスを単純に更新することはできないため、ストレージクラスの構成にDRBDオプションを追加する場合は、そのストレージクラスを削除して再作成する必要があります。また、LINSTORリソースグループオブジェクトでDRBDオプションを設定すると（linstor resource-group set-property <rg-name> DrbdOptions/<option-name>）、変更は将来のボリュームおよびリソースグループに属する既存のボリュームに影響します。
警告: LINSTORリソースグループにDRBDオプションを設定し、それがKubernetesストレージクラスにも対応している場合、次にボリュームが作成されるとき、CSIドライバーは、リソースグループ内にのみあるDRBDオプションの変更を元に戻します。この問題を解決するには、ストレージクラスでもDRBDオプションを設定する必要があります。
潜在的な落とし穴があるため、LINSTORコントローラーオブジェクトにDRBDオプションを設定する方が簡単です。コントローラーに設定されたDRBDオプションは、すべてのリソースグループ、リソース、およびボリュームに適用されます。これらのLINSTORオブジェクトのいずれかに同じオプションが設定されていない限りです。LINSTORオブジェクト階層に関する詳細については、 LINSTORのオブジェクト階層 セクションを参照してください。
以下のコマンドを入力することで、LINSTORコントローラオブジェクトに設定できるプロパティ（DRBDオプションを含む）をリストアップできます:
# kubectl exec -n linbit-sds deployment/linstor-controller -- \ linstor controller set-property --help
Kubernetes内のLINSTORコントローラーにDRBDオプションを設定する
Kubernetesデプロイメントにおいて、LINSTORコントローラ上のDRBDオプションを設定するには、`LinstorCluster`configurationを編集します。例えば、すべての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オプションを設定することができます。これは、LinstorNodeConnection構成を編集することで行います。LinstorCluster 構成の編集と適用手順は前のセクションで説明されているものと似ています。
ノード接続レベルで設定されたDRBDオプションは、コントローラーレベルやサテライトノードレベルで設定されたDRBDオプションよりも優先されます。ノード接続レベルで設定されたDRBDオプションは、コントローラーレベルやサテライトノードレベルで設定されたDRBDオプションよりも優先されます。
次は、2つのことを行う例となるノード接続構成の例です。
-
異なる地理的領域、例えば、2つのデータセンターにあるノードのペアを選択してください。
-
DRBDが選択基準を満たすノード間のノードレベル接続でprotocol 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
NOTE: ノード接続 `selector` の仕様についての詳細については、 <<https://github.com/piraeusdatastore/piraeus-operator/blob/v2/docs/reference/linstornodeconnection.md#specselector[upstream Piraeus project]>> 内のドキュメントを参照してください。 [[s-kubernetes-drbd-options-setting-on-satellite]] ===== KubernetesにおけるLINSTORサテライトノードでのDRBDオプションの設定
Kubernetes内のLINSTORサテライトノードでDRBDオプションを設定することができます。これは、Kubernetes LinstorSatelliteConfiguration 設定を編集することで行います。 LinstorCluster または LinstorNodeConnection 設定を編集および適用する手順は、前のセクションで説明されているものと似ています。
サテライトノードレベルで設定されたDRBDオプションは、コントローラーレベルで設定されたDRBDオプションよりも優先されます。
DRBDのオプションを設定して、LINSTORがノードを自動的に追い出さないようにするには、次の設定ファイルを使用することができます。ただし、自動追い出し機能を無効にしたいノードに '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ストレージプールに対して、LINSTORプロパティ（DRBDオプションではない）を指定することもできます。
この例の設定は、あなたのKubernetesデプロイメント内のすべてのLINSTORサテライトノードに適用されます。ただし、 [s-kubernetes-drbd-options-setting-on-satellite] 内の設定例と同様に、特定のノードのみを選択することも可能です。詳細については、アップストリームPiraeusプロジェクトのドキュメント[documentation in the upstream Piraeus project] (https://github.com/piraeusdatastore/piraeus-operator/blob/v2/docs/reference/linstorsatelliteconfiguration.md#linstorsatelliteconfiguration) を参照してください。
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.3.18. csi.storage.k8s.io/fstype
csi.storage.k8s.io/fstype パラメータは、 volumeMode: FileSystem PVCsの作成に使用するファイルシステムタイプを設定します。現在サポートされているのは以下の通りです：* ext4（デフォルト）* xfs
==== autoPlace
autoPlace は、この StorageClass のボリュームにレプリカがいくつ作成されるかを決定する整数です。たとえば autoPlace: "3" は、3つの複製を持つボリュームを生成します。autoPlace も nodeList も設定されていない場合、ボリュームは1つのノードに 自動的に配置 されます。重要: このオプションを使用する場合、 nodeList を使用しないでください。重要: ダブルクオーテーションを使用する必要があります。そうしないと Kubernetes は不正な StorageClass としてエラーを出力します。ヒント: このオプション（および自動配置動作に影響を与えるすべてのオプション）は、ボリュームの基礎ストレージがプロビジョニングされる LINSTOR ノードの数を変更し、どの kubelets からそのボリュームにアクセスできるかには直交しています。
5.3.19. placementCount
placementCount は autoPlace のエイリアス
5.3.20. resourceGroup
このStorageClassに関連付ける LINSTORリソースグループ（RG） 。設定されていない場合、新しいPVCごとに新しいRGが作成されます。
==== storagePool
storagePool は、新しく作成されるボリュームにストレージを提供するために使用されるLINSTORの ストレージプール の名前です。 注意: この同じ storage pool で構成されたノードのみが 自動配置 の対象となります。同様に、nodeList を使用する StorageClasses の場合、そのリストに指定されたすべてのノードにこの storage pool が構成されている必要があります。
==== disklessStoragePool
disklessStoragePool は、”ディスクレス”として linetets に割り当てられたLINSTORボリュームにのみ影響するオプションパラメータです。LINSTORでカスタムディスクレスストレージプールが定義されている場合、ここで指定します。
5.3.21. layerList
作成されたボリュームに使用するレイヤーのカンマ区切りのリスト。使用可能なレイヤーとその順序は、 このセクション の最後に記載されています。デフォルトは drbd,storage 。
==== placementPolicy
利用可能なボリュームスケジューラのいずれかを選択します: * AutoPlaceTopology、デフォルト: Kubernetesからのトポロジ情報とユーザー定義の制約条件を使用します（[s-kubernetes-replicasonsame] および [s-kubernetes-replicasondifferent] を参照）。 * AutoPlace LINSTORの自動配置機能を使用し、 [s-kubernetes-replicasonsame] および [s-kubernetes-replicasondifferent] の影響を受けます。 * FollowTopology: CSIトポロジ情報を使用して、各 “preferred” ゾーンに少なくとも1つのボリュームを配置します。CSIトポロジが有効な場合のみ使用可能です。 * Manual: nodeList と clientList にリストされているノードのみを使用します。 * Balanced: 実験的 障害ドメイン全体にわたってボリュームを配置し、各選択されたノード上で最も使用されていないストレージプールを使用します。
==== allowRemoteVolumeAccess
ボリュームにアクセス可能なノードを制御します。このオプションの値には、2つの異なる形式があります。
-
シンプルな`”true”`または`”false”`は、すべてのノードからのアクセスを許可するか、ディスクリソースを持つノードのみを許可するかを決定します。
-
より細かいルールを許可し、どのノードがボリュームにアクセスできるかを制御できる高度なルール。
現在の実装では、同じラベルを共有するノードに対してボリュームへのアクセスを許可することができます。たとえば、ディスクフルリソースと同じ地域およびゾーンのすべてのノードからのアクセスを許可したい場合は、次のようにします:
parameters: linstor.csi.linbit.com/allowRemoteVolumeAccess: | - fromSame: - topology.kubernetes.io/region - topology.kubernetes.io/zone
encryption は、ボリュームを暗号化するかどうかを決定するオプションパラメータです。 これが正常に機能するには、LINSTORはデプロイメントが 暗号化に設定 されている必要があります。
==== nodeList
nodeList は、割り当てるボリュームのノードのリストです。これにより、ボリュームが各ノードに割り当てられ、それらの間でレプリケーションされます。ホスト名で単一ノードを選択するためにも使用できますが、単一ノードを選択するには replicasOnSame を使用する方が柔軟です。重要：このオプションを使用する場合は、 autoPlace を使用しないでください。ヒント：このオプションは、ボリュームの基礎ストレージがどのLINSTORノードにプロビジョニングされるかを決定し、これらのボリュームがアクセス可能になる kubelets は異なります。
5.3.22. clientList
clientList はディスクレスボリュームに割り当てるためのノードのリストです。 [s-kubernetes-nodelist] と併用して使用します。
==== replicasOnSame
5.3.23. replicasOnDifferent
replicasOnDifferent は考慮するプロパティのリストを受け取り、replicasOnSame
と同じです。replicasOnDifferent を使用する方法には2つのモードがあります。* 特定のノードにボリューム配置を防止する：+
プロパティに値が与えられた場合、そのプロパティ-値ペアが割り当てられているノードは最後に考慮されます。+ 例：
replicasOnDifferent: "no-csi-volumes=true" は、 no-csi-volumes=true
プロパティを持つノードにはボリュームを配置しない（autoPlace 設定を満たす他のノードが不足していない限り）。
* 同じキーの異なる値を持つノードにボリュームを分散配置する:
プロパティの値が指定されていない場合、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.3.26. postMountXfsOpts
property.linstor.csi.linbit.com/ から始まるパラメータは、StorageClassに関連する リソースグループ に設定されたLINSTORプロパティに変換されます。
たとえば、 DrbdOptions/auto-quorum を disabled に設定する場合は、次のようにします:
property.linstor.csi.linbit.com/DrbdOptions/auto-quorum: disabled
5.3.27. DrbdOptions/*: <x>
注意: このオプションは非推奨となりました。より一般的な property.linstor.csi.linbit.com/* 形式を使用してください。LINSTORに渡すための高度なDRBDオプション。たとえば、レプリケーションプロトコルを変更するには、DrbdOptions/Net/protocol: "A" を使用します。
=== スナップショット
スナップショットは特定の時点でボリュームの内容のコピーを作成します。このコピーはボリュームの内容を修正しても触れられずに残ります。例えば、データを変更や削除する前にバックアップを作成することができます。バックアップは復元方法がなければ役に立ちませんので、このセクションではスナップショットの作成方法と復元方法について説明します。例えば、データを誤って削除した場合などに備えてです。次のサブセクションでは、Operator v2デプロイメント内のスナップショットに関する手順が記載されています。Operator v1を使用してKubernetesでLINBIT SDSをデプロイした場合は、 [s-kubernetes-add-snaphot-support-v1] のサブセクションに進んでください。 ==== スナップショットとの使用
Before you can add snapshot support within a LINBIT SDS deployment, you need to meet the following environment prerequisites:
-
Your cluster has a storage pool supporting snapshots. LINSTOR supports snapshots for
LVM_THIN,ZFSandZFS_THINpools. Snapshots are also supported onFILE_THINpools backed by a file system withreflinkssupport, such as XFS or Btrfs. -
You have a
StorageClass,PersistentVolumeClaim, andDeploymentthat uses a storage pool that supports snapshots. -
Your cluster has a CSI snapshotter (
snapshot-controller) deployed. To verify if it is already deployed, you can enter the following command:$ 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
もしコマンドからの出力が空の場合は、以下のコマンドを入力してスナップショットコントローラをデプロイできます:
$ kubectl apply -k https://github.com/kubernetes-csi/external-snapshotter//client/config/crd $ 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.3.28. スナップショットの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.4. ボリュームのアクセシビリティとローカリティ
これはDRBDボリュームにのみ適用され、関連ドキュメントが更新された場合はセクションが変更される可能性があります。 LINSTORボリュームは通常、 [s-drbd_clients、ネットワーク越しに] ローカルおよびアクセス可能です。 CSIドライバーは、ボリュームが消費者向けに選択されたノードでアクセス可能であることを保証します。 ドライバーには、ボリュームの局所性（消費者がバッキングデータと同じノードに配置される）およびアクセシビリティの制限（ネットワーク越しにボリュームにアクセスできるノードのサブセットのみ）を保証するオプションも用意されています。
ボリュームの局所性は、ストレージクラスで volumeBindingMode: WaitForFirstConsumer を設定することで実現されます。これにより、Kubernetes と CSI ドライバーは、PVC を参照する最初のコンシューマー（ポッド）がスケジュールされるまで待機するように指示されます。次に、CSI ドライバーは、コンシューマーと同じノード上の下位データを使用してボリュームをプロビジョニングします。適切なストレージプールのないノードが選択された場合、アクセス可能なノードのセットから代替ノードが選択されます（以下を参照）。
ボリュームのアクセシビリティは、allowRemoteVolumeAccess パラメータによって制御されます。CSIプラグインがボリュームを配置する必要がある場合、このパラメータが参照されて、「アクセス可能」ノードの一覧を取得します。これにより、ノード間でネットワークを介して配置されたボリュームを共有できるようになります。この情報はまた、PVのラベルセレクターを使用してKubernetesに伝播されます。
5.4.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 つのノードがデータを格納することを確証します。 |
同一ゾーン内のノード上でレプリカとしてボリュームを使用することを許可します。前提として、ゾーン内ネットワーキングが高速かつ低遅延であると仮定します。
| 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: | (4)
- fromSame:
- topology.kubernetes.io/zone
linstor.csi.linbit.com/replicasOnSame: topology.kubernetes.io/region (5)
| 1 | 遅延ボリュームバインディングを有効にします。可能な場合、最初の消費ポッドと同じノードにレプリカを配置します。 |
| 2 | 使用するストレージプールを設定します。 |
| 3 | 少なくとも 2 つのノードがデータを格納することを確証します。 |
同一ゾーン内のノード上でレプリカとしてボリュームを使用することを許可します。前提として、ゾーン内ネットワーキングが高速かつ低遅延であると仮定します。
| 1 | レプリカを単一のリージョンのみに制限します。 |
外部ストレージを備えたクラスター
クラスターはローカルストレージのないノードのみで構成されています。ボリュームアクセスは、リモートボリュームアクセスを介して行う必要があります。
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 | 私たちのワーカーノードは、外部ストレージホストに接続することが許可される必要があります。 |
5.5. 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.6. Volume Locality Optimization
To ensure that pods are scheduled on nodes with local replicas of data, to reduce latency for read operations, you can take the following steps:
-
Use a StorageClass with
volumeBindingMode: WaitForFirstConsumer. 2. SetallowRemoteVolumeAccess: "false"in the StorageClass parameters.
Optionally, you can also deploy the [LINSTOR Affinity Controller](https://artifacthub.io/packages/helm/piraeus-charts/linstor-affinity-controller).
5.7. Operator v2デプロイメントにおけるDRBDモジュールローダーの設定:
このセクションの手順に従うには、LinstorSatelliteConfiguration リソースの編集に慣れている必要があります。
|
DRBDモジュールローダーは、LINBIT SDSにおいてDRBDカーネルモジュールを利用可能にし、Kubernetesでの他の便利なカーネルモジュールの読み込みを行うコンポーネントです。このセクションでは、LINSTOR Operator v2デプロイメント内で、DRBDカーネルモジュールローダーのさまざまな側面を構成する方法について説明します。
提供されている場合、DRBDカーネルモジュール以外にも、以下のモジュールがロードされます:
[cols=”1,1″] |
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.7.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.7.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.7.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.8. Operator v2 デプロイメントにおいて DRBD レプリケーション用ホストネットワークを使用する
このセクションの手順では、ホストネットワークを使用してDRBDレプリケーショントラフィックを行う方法について説明します。
デフォルトでは、DRBDはコンテナネットワークを使用してボリュームデータを複製します。これにより、さらなる構成を行わずに幅広い範囲のクラスタで複製が機能することを保証します。また、NetworkPolicy の使用を可能にし、DRBDトラフィックへの未認可アクセスをブロックすることができます。ポッドのネットワークインターフェースはポッドのライフサイクルに結び付いているため、LINSTORサテライトポッドが再起動されると、DRBDは一時的に複製を中断することを意味します。
ホストネットワークを使用すると、DRBDレプリケーションはLINSTORサテライトポッドとは独立して動作するため、一方通行とは異なります。ホストネットワークは、コンテナネットワークよりもパフォーマンスが向上する場合があります。デメリットとしては、関連ポート間でノード間の接続性を手動で確保する必要があります。
このセクションの手順に従うには、LinstorSatelliteConfiguration リソースの編集に慣れている必要があります。
|
5.8.1. ホストネットワークを使用するように DRBD レプリケーションを構成する
デフォルトのコンテナネットワークからホストネットワークに切り替えて DRBD レプリケーションを行うことはいつでも可能です。既存の DRBD リソースはその後、ホストネットワークインターフェイスを使用するように再構成されます。
サテライトのホストネットワークを設定するには、次のYAML構成をデプロイメントに適用してください。
apiVersion: piraeus.io/v1
kind: LinstorSatelliteConfiguration
metadata:
name: host-network
spec:
podTemplate:
spec:
hostNetwork: trueサテライトポッドが再作成されると、ホストネットワークを使用します。既存の DRBD リソースは、コンテナネットワーク上の IP アドレスではなく、ホストネットワーク上の新しい IP アドレスを使用するように再構成されます。
5.8.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.9. 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.10. 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.11. Prometheus による監視
KubernetesでのLINSTORデプロイメントは、Prometheus monitoring stackと統合する可能性を提供します。https://prometheus.io/[Prometheus] を使用して、Kubernetes内のLINSTORおよび関連コンポーネントを監視できます。この監視ソリューションは、あなたの目的に合わせて設定可能であり、Prometheusスクレイプメトリクス用のGrafanaダッシュボードやアラートルールの設定、イベントのアラートを受け取る機能などを含んでいます。
Prometheusモニタリングは、LINSTORとの統合を設定:
-
LINSTORおよびDRBD状態のメトリクス収集。
-
クラスターの状態に基づくアラート
-
Grafanaダッシュボード
LINSTORをKubernetesデプロイメント内でモニタリングするために、以下の点に精通している必要があります:
5.11.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.11.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.12. Kubernetes での LINSTOR デプロイメントのアップグレード
KubernetesでのLINSTORデプロイメントは新しいリリースにアップグレードすることが可能です。同様に、Kubernetesでの既存のLINSTOR Operator v1デプロイメントをOperator v2デプロイメントにアップグレードすることも可能です。
| アップグレードプロセス中は、ボリュームのアタッチ、デタッチ、またはプロビジョニングが一時停止されます。既存のボリュームや既にポッドで使用されているボリュームは引き続き機能します。 |
5.12.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.4.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をアップグレード:
<<s-kubernetes-creating-operator-helm,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.12.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.12.3. LINSTORオペレーターv1からLINSTORオペレーターv2へのアップグレード:
既存のKubernetes内のLINBIT SDSデプロイメントを、LINSTOR Operator v1デプロイメントからOperator v2デプロイメントにアップグレードするには、こちらの移行手順に従うことができます。
このアップグレードを行う際に、LINSTORサテライトポッドにアタッチされている既存のストレージボリュームに影響を与えずに行うことが可能です。ただし、Operator v2デプロイメントへのマイグレーション中は、新しいボリュームを作成したり、既存のボリュームをアタッチまたはデタッチすることはできません。新しいデプロイメントを展開するまでです。
5.12.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.12.5. 特定のバージョンのアップグレード手順
一部のバージョンでは特別な手順が必要です。以下を参照ください。
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セットアップの仕組みが再構築されました。 [s-kubernetes-securing-deployment-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®顧客ポータルの資格情報。
| LINBITのコンテナイメージリポジトリ（http://drbd.io）は、LINBITの顧客かLINBITの顧客トライアルアカウントを通じてのみ利用可能です。価格情報を取得したりトライアルを開始するには、LINBITにお問い合わせしてください。あるいは、LINBITの顧客でなくても、LINSTOR SDSのアップストリームプロジェクトであるPiraeusを使用することもできます。 |
最初に、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 ==> ...
これは、問題の調査や高度な機能へのアクセスにのみ必要なはずです。 ボリュームの作成など通常の操作は Kubernetes integration で行う必要があります。
7. NomadのLINSTORボリューム
この章では、LINSTORとDRBDを使用してNomadでボリュームをプロビジョニングする方法について説明します。
7.1. Nomad の紹介
Nomad は、コンテナとコンテナ化されていないアプリケーションをオンプレミスとクラウド上にデプロイして管理するための、シンプルで柔軟性のあるワークロードオーケストレーターです。
Nomad は Container Storage Interface(CSI) に準拠した plug-ins 経由のストレージボリュームのプロビジョニングをサポートします。
LINBIT は、CSIプラグインを drbd.io のコンテナイメージの形で配布しています。このプラグインは、Nomadクラスタに沿って、またはその内部にデプロイされたLINSTORクラスタと連携するように構成できます。
| LINBIT のコンテナー イメージ リポジトリ (http://drbd.io) は、LINBIT のお客様、または LINBIT のお客様の試用アカウントを通じてのみ利用できます。価格についての情報や試用開始するには こちら を参照ください。また、LINSTOR SDS のアップストリームプロジェクト Piraeus は LINBIT の顧客ではなくてもを使用できます。 |
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 | LINSTOR Controller イメージを実行するように設定します。最新のイメージは drbd.io から入手できます。
|
||
| 5 | イメージを pull するときに使用する認証を設定します。 drbd.io から pull する場合は、ここでLINBITの顧客ログインを使用する必要があります。プライベートレポジトリからの pull に関しては こちら を参照ください。 |
||
| 6 | このテンプレートは、LINSTORの任意の構成オプションを設定するために使用できます。この例では、LINSTORの外部データベースを構成します。詳細は LINSTOR データベースオプション こちら およびNomadテンプレート こちら を参照ください。 |
次のコマンドを実行して、ジョブを適用します。
$ nomad job run linstor-controller.hcl
==> Monitoring evaluation "7d8911a7"
Evaluation triggered by job "linstor-controller"
==> Monitoring evaluation "7d8911a7"
Evaluation within deployment: "436f4b2d"
Allocation "0b564c73" created: node "07754224", group "controller"
Evaluation status changed: "pending" -> "complete"
==> Evaluation "7d8911a7" finished with status "complete"LINSTOR データベースにホストボリュームを使用
外部データベースを設定せずにLINSTORを試したい場合は、LINSTOR 組み込みのファイルシステムベースのデータベースを利用できます。データベースを永続的にするには、データベースがホストボリュームに配置されていることを確認する必要があります。
| ホストボリュームを使用すると、1つのノードのみでLINSTOR コントローラを実行できます。ノードが使用不可の場合は、LINSTOR クラスタも使用不可になります。代替策として、外部(高可用性)データベースを使用するか、 LINSTORクラスタをホストに直接導入 します。 |
LINSTOR データベース用のホストボリュームを作成するには、まず、必要な権限を持つディレクトリをホスト上に作成します。
$ mkdir -p /var/lib/linstor
$ chown -R 1000:0 /var/lib/linstor次に、以下のスニペットをNomadエージェント構成に追加し、Nomadを再起動します。
/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 | LINSTORのサテライトイメージを実行するように設定します。最新のコンテナイメージは drbd.io から入手できます。サテライトイメージのバージョンは、コントローライメージのバージョンと一致している必要があります。
|
||
| 4 | イメージを pull するときに使用する認証を設定します。 drbd.io から pull する場合は、ここでLINBITの顧客ログインを使用する必要があります。プライベートレポジトリからの pull に関しては こちら を参照ください。 |
||
| 5 | ストレージデバイスやDRBDを構成し、カーネルモジュールをロードするためには、コンテナーを特権モードで実行する必要があります。 | ||
| 6 | サテライトはDRBDと通信する必要があるため、ホストネットワークで実行されているnetlinkインターフェースにアクセスする必要があります。 | ||
| 7 | drbd-loader タスクはサテライトの開始時に1回実行され、DRBDやその他の有用なカーネルモジュールをロードします。 |
||
| 8 | drbd-loader は、使用しているディストリビューションに固有のものです。使用可能なオプションは次のとおりです。
|
||
| 9 | drbd-loader コンテナは環境変数で設定できます。 LB_HOW はコンテナにDRBDカーネルモジュールの挿入方法を指示します。使用可能なオプションは次のとおりです。
|
||
| 10 | drbd-loader コンテナがDRBDを構築したり、既存のモジュールをロードしたりするためには、ホストの /usr/src と /lib/modules にアクセスできる必要があります。
これには、すべてのノードに追加のホストボリュームを設定する必要があります。次のスニペットをすべての Nomad エージェント構成に追加してから、Nomad を再起動する必要があります。 Listing 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|" ] この設定は、LVMにDRBDデバイスをスキャンやオープンの試行から拒否するよう指示します。このフィルタを設定しない場合、CPU負荷の増加やLVM操作の停滞が発生する可能性があります。 |
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 | LINSTOR CSIドライバイメージを実行するように設定します。最新のイメージは drbd.io から入手できます。
|
||
| 4 | イメージを pull するときに使用する認証を設定します。 drbd.io から pull する場合は、ここでLINBITの顧客ログインを使用する必要があります。プライベートレポジトリからの pull に関しては こちら を参照ください。 |
||
| 5 | この引数は、CSIドライバがLINSTOR APIで自身を識別するために使用するノード名を設定します。デフォルトでは、これはノードのホスト名に設定されます。 | ||
| 6 | この引数は、LINSTOR APIエンドポイントを設定します。consulサービスメッシュ(前述のNr.2を参照)を使用していない場合は、これをControllers APIエンドポイントに設定する必要があります。エンドポイントは、デプロイされているすべてのノードから到達可能である必要があります。 | ||
| 7 | CSIドライバはマウントコマンドを実行する必要があるため、特権付きコンテナが必要です。 | ||
| 8 | csi_plugin スタンザは、このタスクがCSIプラグインであることをNomadに通知します。Nomadエージェントは、ボリュームに対する要求をジョブコンテナーの1つに転送します。 |
次のコマンドを実行して、ジョブを適用します。
$ nomad job run linstor-csi.hcl
==> Monitoring evaluation "0119f19c"
Evaluation triggered by job "linstor-csi"
==> Monitoring evaluation "0119f19c"
Evaluation status changed: "pending" -> "complete"
==> Evaluation "0119f19c" finished with status "complete"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
╭──────────────────────────────────────────────────────────────────────────────────────────────╮
┊ 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 は、KVM、Linuxコンテナ、および高可用性（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 Repositoryをご存知であれば、LINBITもProxmox VEと一緒に使用するための公開リポジトリを提供しています。このリポジトリにはProxmoxプラグインだけでなく、DRBD、LINSTOR、およびすべてのユーザースペースユーティリティーを含むLINBIT SDSスタック全体が含まれています。
| これはホームラボ、テスト、および非プロダクション利用には素晴らしいオプションとなりますが、LINBITはこれらのパッケージを顧客リポジトリと同じ厳格な基準でメンテナンスしていません。本番環境のデプロイメントには、公式LINBIT顧客リポジトリの使用が推奨されています。 |
以下のコマンドを入力して、LINBITの公式リポジトリを追加できます。$PVERSをProxmox VEの メジャーバージョン （たとえば、「8」ではなく「8.1」）に設定してください。
# wget -O /tmp/linbit-keyring.deb \ https://packages.linbit.com/public/linbit-keyring.deb # dpkg -i /tmp/linbit-keyring.deb # PVERS=8 && echo "deb [signed-by=/etc/apt/trusted.gpg.d/linbit-keyring.gpg] \ http://packages.linbit.com/public/ proxmox-$PVERS drbd-9" > /etc/apt/sources.list.d/linbit.list # apt update
8.3. Proxmoxプラグインのインストール
適切なLINBITパッケージリポジトリを構成した後、次のコマンドを入力することで、Proxmoxプラグインや他の必要なコンポーネント（DRBDカーネルモジュールやユーティリティ）をインストールすることができます。
# apt -y install drbd-dkms drbd-utils linstor-proxmox
8.4. LINSTOR の構成
このガイドの残りの部分は、 クラスタの初期化 で説明されているように構成されたLINSTORクラスターがあることを前提としています。1つのノードで linstor-controller サービスを開始し、すべてのノードで linstor-satellite サービスを開始してください。linstor-satellite サービスには追加の設定が必要です。これは、 systemctl edit linstor-satellite.service を入力して行うことができます。
[Service] Type=notify TimeoutStartSec=infinity
バージョン4.1.0からのプラグインの推奨使用方法は、LINSTORリソースグループと、それぞれのリソースグループ内に1つのボリュームグループを介して行うことです。LINSTORリソースグループについては、 リソースグループを使用した LINSTOR プロビジョニングされたボリュームのデプロイ で説明されています。たとえば、データ複製数など、すべての必須のLINSTOR設定はリソースグループに設定する必要があります。
|
LINSTORをLVMとDRBDと一緒に使用する場合、LVMのグローバル設定ファイル（ global_filter = [ "r|^/dev/drbd|" ] この設定は、LVMにDRBDデバイスをスキャンやオープンの試行から拒否するよう指示します。このフィルタを設定しない場合、CPU負荷の増加やLVM操作の停滞が発生する可能性があります。 |
8.5. Proxmoxプラグインの設定
最後のステップは、Proxmox自体の構成を提供することです。これは、/etc/pve/storage.cfg ファイルに以下のような内容を持つエントリを追加することで行うことができます。
drbd: drbdstorage content images,rootdir controller 10.11.12.13 resourcegroup defaultpool
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.5.1. Proxmoxで使用する複数のLINSTORリソースグループを構成する
異なるストレージプールに関連付けられた異なるリソースグループを使用する構成は、次のように見えるかもしれません:
drbd: drbdstorage content images,rootdir controller 10.11.12.13 resourcegroup defaultpool drbd: fastdrbd content images,rootdir controller 10.11.12.13 resourcegroup ssd drbd: slowdrbd content images,rootdir controller 10.11.12.13 resourcegroup backup
この構成を行った後、Proxmox web GUIを使用して、”drbdstorage“を選択することで、または他の定義済みのプールである”fastdrbd“や”slowdrbd“をストレージ場所として選択することで、VMを作成することができます。
プラグインのバージョン5から、オプション preferlocal yes を設定することができます。このオプションを設定すると、そのストレージ作成コマンドを発行したノードにディスクフルのアサインメントを作成しようとします。このオプションを使用すると、可能な限りVMにローカルストレージを確保することができます。オプションを指定しない場合、LINSTORはストレージをノード ‘B’ と ‘C’ に配置する可能性があり、VMは最初にノード ‘A’ で起動されるかもしれません。その場合、ノード ‘A’ はディスクレスのアサインメントを受けることになりますが、ローカルストレージを持つことが望ましいかもしれません。
この時点で、VMをライブマイグレーションしようとすることができます。すべてのデータがすべてのノードでアクセス可能であり、ディスクのないノードでも、わずか数秒で完了します。VMが負荷の下にある場合や、常に大量のRAMが汚れている場合、全体のプロセスには少し時間がかかるかもしれません。しかし、いずれの場合も、ダウンタイムは最小限に抑えられ、操作上の中断は一切ないはずです。
| Option | Meaning |
|---|---|
|
The IP of the LINSTOR controller (‘,’ separated list allowed) |
|
The name of a LINSTOR resource group which defines the deployment of new VMs. As described above |
|
Prefer to create local storage (yes/no). As described above |
|
Time in seconds status information is cached, 0 means no extra cache. Relevant on huge clusters with hundreds of resources. This has to be set on all |
|
Set this temporarily to |
|
Path to the client certificate |
|
Path to the client private key |
|
Path to the CA certificate |
8.6. Proxmoxで高可用性のあるLINSTORコントローラーを構成する
LINSTORの高可用性を実現するには、LINSTORコントローラーを高可用性にすることが重要です。 これについては、 高可用性 LINSTOR クラスターの作成 で説明されています。 これは、ProxmoxとのLINSTOR統合をより障害耐性のあるものにすることができるオプションの構成です。
リンクされたセクションの手順を完了した後、最後であり重要なステップは、Proxmoxプラグインを構成して異なるLINSTORコントローラに接続できるようにすることです。プラグインは最初に回答を受け取ったコントローラを使用します。Proxmoxで異なるLINSTORコントローラを構成するには、プラグインの controller セクションにコントローラノードのIPアドレスのカンマ区切りリストを追加することで設定します。例えば、:
drbd: drbdstorage content images,rootdir controller 10.11.12.13,10.11.12.14,10.11.12.15 resourcegroup defaultpool
別の方法として、OCFリソースエージェントである ocf:heartbeat:IPaddr2 を使用して、DRBD Reactorのプロモータープラグインのサービス開始リストに追加することで、LINSTORコントローラー用の仮想IP（VIP）アドレスを構成することがあります。これを行うと、controller パラメーターの値としてそのVIPアドレスを指定できます。
8.7. Cloud-init イメージの保存場所
Cloud-init VM イメージはわずか数MBのサイズで、Proxmox は必要に応じてそれらを生成できます。これは、cloud-init イメージに保存された設定が Proxmox そのものにクラスタ全体で保存されているため可能となります。これにより、Proxmox はローカルストレージ（例えば、LVM）をそのようなイメージに使用できます。クラウドイメージが存在しないノードで VM が起動されると、保存された設定からそのクラウドイメージが生成されます。
DRBDストレージにcloud-initイメージを保存することもできますが、それは利益にはつながりません。cloud-initイメージをローカルストレージに保存することで十分です。
8.8. 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.9. 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.10. LINSTOR Proxmox プラグインのアップグレード
このセクションでは、既存の linstor-proxmox プラグインのインストールをアップグレードする際に注意すべき変更や必要なアクションについて説明します。
新規インストールを行う必要がある場合は、このセクションをスキップし、 LINSTOR Proxmox プラグインのインストール を続行してください。
8.10.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.10.2. プラグインを7.xにアップグレード
プラグインのバージョン7では、LINSTORコントローラAPIを使用しており、LINSTORバージョン1.21.1以降から利用可能です。LINSTORのセットアップ（コントローラーとサテライト）が少なくともそのバージョンを使用していることを確認してください。
8.10.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 # vi /etc/pve/storage.cfg drbd: drbdstorage content images,rootdir controller 10.11.12.13 resourcegroup drbdMypoolThree
8.10.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 は、アドオンを使用してその機能を拡張できる、柔軟でオープンソースのクラウド管理プラットフォームです。
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 ディスクレスモードを介してネットワーク経由で接続します。
すべてのノードに DRBD9 と LINSTOR がインストールされている必要があります。このプロセスの詳細は DRBD9 のユーザーズガイド を参照ください。
両方の役割のすべての要件を満たす限り、フロントエンドノードとホストノードをプライマリロールに加えてストレージノードとして機能させることができます。
フロントエンドノードの構成
フロントエンドノードから通信を行いたいコントロールノードが到達可能であることを確認してください。 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|" この設定は、LVMにDRBDデバイスをスキャンやオープンの試行から拒否するよう指示します。このフィルタを設定しない場合、CPU負荷の増加やLVM操作の停滞が発生する可能性があります。 |
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 は、実行時に ボリュームタイプ でこれらのオプションを管理するため、いくつかの静的構成オプションを削除しました。
Option in cinder.conf |
Status | Replace with |
|---|---|---|
|
削除 |
ボリュームタイプで |
|
削除 |
置き換えは必要ありません。ドライバーは必要に応じて 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/2024.2 with the reference matching your OpenStack release. CINDER_BRANCH=linstor/stable/2024.2
Kolla でインストール
Kolla は OpenStack コンポーネントをコンテナーにパッケージ化します。次に、例えば Kolla Ansible を使用してデプロイできます。kolla コンテナーで使用可能なカスタマイズオプションを利用して、LINSTOR ドライバーをセットアップできます。
必要な python-linstor パッケージがインストールされるようにするには、次のオーバーライドファイルを使用します。
{% extends parent_template %}
# Cinder
{% set cinder_base_pip_packages_append = ['python-linstor'] %}LINBIT バージョンのドライバーをインストールするには kolla-build.conf を更新します。
[cinder-base] type = git location = https://github.com/LINBIT/openstack-cinder.git # Replace linstor/stable/2024.2 with the reference matching your OpenStack release. reference = linstor/stable/2024.2
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=2024.2
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/2024.2 cinder_user_pip_packages: - python-linstor cinder_backends: (1) linstor-drbd: volume_backend_name: linstor-drbd volume_driver: cinder.volume.drivers.linstordrv.LinstorDrbdDriver linstor_uris: linstor://cinder-01.openstack.test,linstor://cinder-02.openstack.test
| 1 | 使用可能なバックエンドパラメータの詳細な説明は、以下のセクションにあります。 |
汎用 Cinder デプロイメント
他の形式の OpenStack デプロイメントの場合、このガイドでは一般的なヒントのみを提供できます。
LINSTOR ドライバーのバージョンを更新するには、インストールされた cinder ディレクトリを見つけてください。考えられるパスは次のとおりです。
/usr/lib/python*/dist-packages/cinder/ /usr/lib/python*/site-packages/cinder/
LINSTOR ドライバーは、cinder ディレクトリにある linstordrv.py というファイルです。
$CINDER_PATH/volume/drivers/linstordrv.py
ドライバを更新するには、ファイルを LINBIT リポジトリのファイルに置き換えます
RELEASE=linstor/stable/2024.2 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ハイパーバイザーがデプロイメントの対象として制限されます。 -
接続しているボリュームと使用中のボリュームのサイズ変更は完全には機能しません。サイズ変更自体は成功していますが、サービスは再起動するまで VM にサイズ変更を伝えません。
-
マルチアタッチ（複数の VM に同じボリュームをアタッチする）はサポートされていません。
-
暗号化されたボリューム は、DRBD デバイスの udev ルールが設定されている場合にのみ機能します。
udevルールはdrbd-utilsパッケージの一部であるか、独自のdrbd-udevパッケージの中にあります。
iSCSI トランスポートプロトコルを使用
Cinder ボリュームをエクスポートするデフォルトの方法は、iSCSI 経由です。これにより最大の互換性が得られます。iSCSI は、VMWare、Xen、HyperV、または KVM などのあらゆるハイパーバイザーで使用できます。
欠点は、すべてのデータを（ユーザースペースの）iSCSI デーモンで処理するためにCinder ノードに送信する必要があることです。これは、データがカーネル/ユーザスペース境界を通過する必要があることを意味し、パフォーマンスに影響を与えます。
もう1つの欠点は、単一障害点になりうる点です。iSCSI デーモンを実行している Cinder ノードがクラッシュすると、他のノードはボリュームにアクセスできなくなります。これを軽減するために自動フェイルオーバー用に Cinder を構成する方法はいくつかありますが、かなりの労力が必要です。
ドライバーバージョン2.0.0より前では、Cinderホストは各ボリュームのローカルレプリカにアクセスする必要があります。これは、linstor_controller_diskless=True`を設定するか、 `linstor_autoplace_count=0 を使用することで実現できます。新しいドライバーバージョンでは、そのようなボリュームを必要に応じて作成します。
|
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-
正規表現に一致する名前のリソースを持つノードにリソースを配置しないでください。
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. 例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. 例2 – ホスト指定で1つのディスクフル割り当て、2つのディスクレスノード
$ docker volume create -d linbit/linstor-docker-volume --opt nodes=bravo lsvol
11.4.3. 例3 – どこかに1つのディスクフル割り当て、2つのディスクレスノード
$ docker volume create -d linbit/linstor-docker-volume --opt replicas=1 lsvol
11.4.4. 例4 – ホスト指定で2つのディスクフル割り当て、charlie はディスクレス
$ docker volume create -d linbit/linstor-docker-volume --opt nodes=alpha,bravo lsvol
11.4.5. 例5 – どこかに2つのディスクフル割り当て、1つのディスクレスノード
$ docker volume create -d linbit/linstor-docker-volume --opt replicas=2 lsvol
11.4.6. 例6 – Docker swarm manager ノードからのサービスで LINSTOR ボリュームを使用する
$ docker service create \
--mount type=volume,src=lsvol,dst=/data,volume-driver=linbit/linstor-docker-volume \
--name swarmsrvc busybox sh -c "while true; do sleep 1000s; done"
Dockerサービスは -v または --volume の構文を受け付けません。代わりに --mount の構文を使用する必要があります。Dockerの run はどちらの構文も受け付けます。
|
12. 高可用性のNFS、iSCSI、またはNVMe-oFストレージ用のLINSTORゲートウェイ
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|" ] この設定は、LVMに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）またはLinux向けのジェネリックSCSIターゲットサブシステム（SCST）のいずれかを使用することができます。
LIOは、Linuxカーネルコミュニティが選んだiSCSI実装であり、メインラインのLinuxカーネルに含まれるSCSIターゲットサブシステムです。
SCSTは、LINBIT®が開発したVSANソリューションを含む多くのiSCSIアプライアンスで使用されている成熟したiSCSI実装です（バージョン0.17.0以降）。
オプションA: LIO
TargetCLIは、LIOターゲットを管理するために使用されるインタラクティブシェルです。LIOは、Linuxカーネルに2.6.38から含まれているSCSIターゲットであり、そのユーティリティや依存関係のインストールは比較的簡単です。
RPMベースのシステムでは、パッケージマネージャーを使用して targetcli パッケージをインストールしたり、DEBベースのシステムでは targetcli-fb パッケージをインストールしたりすることができます。
オプションB: SCST
SCSTプロジェクトは、カーネル空間のコア、デバイスハンドラ、ターゲットドライバ、および scstadmin ユーザースペースユーティリティで構成されており、これらすべてはソースからビルドすることができます。プロジェクトのGitHubリポジトリにある手順に従うことでビルドできます。
以下のインストール手順に従うことで、SCSTをLINSTOR Gatewayと共に使用するために必要なすべてのコンポーネントをインストールします。
| このセクションのすべてのノードでコマンドを入力して実行してください。以下の手順は、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カーネルモジュールをロードするための必要な設定を作成し、そして iscs-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へのNFSサポートをインストール
LINSTOR GatewayでNFSサポートを利用するには、すべてのクラスターノードにNFSユーティリティをインストールする必要があります。
RPMベースのシステムでは nfs-utils パッケージを、DEBベースのシステムでは nfs-common パッケージをインストールしてください。
正しいNFSパッケージを全てのLINSTORサテライトノードにインストールした後、次のコマンドを入力してsystemdユニットファイルを再読み込みしてください。
# systemctl daemon-reload
systemdでは、NFSサーバーサービスを有効にすべきではありません。なぜなら、それはDRBD Reactorがサービスを管理する能力と競合する可能性があるからです。nfs-server サービスを無効にし、次のコマンドを使用して無効になっていることを確認してください。
# systemctl disable nfs-server --now # systemctl status nfs-server
上記の status コマンドの出力に、サービスが「非アクティブ」と「無効」にリストされていることを確認してください。
● 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はプロジェクトのGitHub pageにオープンソースのLINSTOR Gatewayコードを維持しています。
| LINSTOR Gatewayは、LINSTORコントローラーノードとの通信にLINSTORクライアントを使用します。そのため、LINSTOR GatewayをLINSTORクライアントがLINSTORコントローラーノードと通信するように構成されている場所にインストールする必要があります。LINSTORクラスターについては、LINSTORクライアントの構成について詳しくは、LINSTORユーザーガイドのLINSTORクライアントの構成を参照してください。 |
12.2.1. LINSTORのGateway サーバーコンポーネントのインストール
LINSTOR Gatewayには、サーバーコンポーネントがあります。このコンポーネントは、クラスター内のノードのバックグラウンドで実行する必要があります。通常、これはLINSTORクライアントがインストールされたノードであり、おそらくLINSTORコントローラーノードとなるでしょう。ただし、たとえば 高可用性LINSTORコントローラ を構成している場合は、クラスタ内の複数のノードにインストールすることもできます。ただし、LINSTORコントローラーと同じノードでLINSTORクライアントを実行する必要はありません。LINSTOR Gatewayサーバー上のLINSTORクライアントが、たとえばLINSTORクライアント設定ファイル（ /etc/linstor/linstor-client.conf ）内の controllers= 行を使用して、LINSTORコントローラーにアクセスする方法を「知っている」場合は、同じノードで実行する必要はありません。
ノードに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
12.3. 要件が満たされているか確認
LINSTOR Gatewayを使用する前の最終手順として、前のセクションで概説された前提条件を満たしているか確認してください。
12.3.1. コンポーネントがインストールされているか確認する
次の手順に従って、LINSTORゲートウェイコンポーネントの検証を行う前提で、既に前のセクションで説明されているように、ストレージプール、リソースグループ、およびボリュームグループを含む 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クラスタが正しく初期化されていることを、以下のコマンドの出力と比較することで確認してください。
すべてのLINSTORノードがサテライトまたは結合タイプとしてリストされており、DRBDクォーラムをサポートするために三つ以上のノードを持っていることを確認してください。
# linstor node list ╭────────────────────────────────────────────────────────────╮ ┊ 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でバックアップされたストレージプールが含まれることを確認してください。
# linstor storage-pool list ╭─────────────────────────────────────────────────────────[...]─────────╮ ┊ StoragePool ┊ Node ┊ Driver ┊ PoolName ┊ [...] ┊ State ┊ ╞═════════════════════════════════════════════════════════[...]═════════╡ [...] ┊ lvmpool ┊ LINSTOR1 ┊ LVM ┊ lvpool ┊ [...] ┊ Ok ┊ ┊ lvmpool ┊ LINSTOR2 ┊ LVM ┊ lvpool ┊ [...] ┊ Ok ┊ ┊ lvmpool ┊ LINSTOR3 ┊ LVM ┊ lvpool ┊ [...] ┊ Ok ┊ ╰─────────────────────────────────────────────────────────[...]─────────╯
少なくとも1つのストレージプールを使用するLINSTORリソースグループを作成したことを確認してください。また、各リソースグループに対応するボリュームグループがあることも確認してください。
# linstor resource-group list ╭────────────────────────────────────────────────────────────────╮ ┊ 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 ┊ ┊ ┊ ╰────────────────────────────────────────────────────────────────╯ # linstor volume-group list iscsi_group ╭──────────────────╮ ┊ VolumeNr ┊ Flags ┊ ╞══════════════════╡ ┊ 0 ┊ ┊ ╰──────────────────╯ # linstor volume-group list nfs_group ╭──────────────────╮ ┊ VolumeNr ┊ Flags ┊ ╞══════════════════╡ ┊ 0 ┊ ┊ ╰──────────────────╯ # linstor volume-group list nvmeof_group ╭──────────────────╮ ┊ VolumeNr ┊ Flags ┊ ╞══════════════════╡ ┊ 0 ┊ ┊ ╰──────────────────╯
12.4. LINSTOR Gatewayを使用してiSCSIターゲットを作成
環境の準備が完了したら、iSCSI論理ユニット（LU）の作成を開始できます。すべてのiSCSI関連アクションを管理するために、linstor-gateway コマンドラインユーティリティを使用します。
iscsi サブコマンドに関する詳細情報については、linstor-gateway iscsi help を使用してください。
|
以下のコマンドを入力すると、LINSTORクラスタ内に新しいDRBDリソースが作成されます。LINSTOR Gatewayは、指定されたLINSTORリソースグループ iscsi_group からリソースをデプロイします。このコマンドは、iSCSIターゲットの高可用性を有効にするためのDRBD Reactor構成ファイルも作成します。LINSTORリソース名は、iSCSI資格情報名（IQN）のコロンの後に指定したものになります。以下のコマンドの場合、リソース名は example になります。
# linstor-gateway iscsi create iqn.2019-08.com.linbit:example 172.16.16.97/24 1G \ --username=foo --password=bar --resource-group=iscsi_group
上記のコマンドを入力した後、指定したユーザー名とパスワードを使用して CHAP 認証が有効になっている 1GiB の iSCSI ターゲットが作成されます。指定した IP アドレスで iSCSI ターゲットにアクセスできるようになります。このターゲットは、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 delete -i iqn.2021-04.com.linbit:lun4 -l 4
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. Creating Multiple NFS Exports by Using LINSTOR Gateway
もしクラスターにすでに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-oFリソースを表示するには、linstor-gateway nvme list コマンドを入力します。
# linstor-gateway nvme list +------------------+-------------------+---------------+-----------+---------------+ | 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. LINSTOR Exosの統合
linstor-server v1.26.0のリリース時点では、LINSTORのためのExos統合は非推奨となっています。
|
Seagateの Exos ストレージマネージャは、LINSTOR®によって管理される大きなブロックデバイスとして構成することができます。これにより、ローカルドライブのように利用できますが、これによって同じプールから複数のサーバー間でLINSTORリソースを同時に共有することができません。
LINSTORとExosの統合により、複数のサーバーノードが同一のExosプールで提供されるLINSTORリソースを割り当て、接続することができます。 そのため、SSD/HDD階層化、SSDキャッシング、スナップショット、シンプロビジョニングなど、Exosのストレージ管理機能のすべてがLINSTORリソースやKubernetes Storage Classで利用可能になります。
設定後、LINSTORは2つのExosコントローラのうち1つを介してサーバーノードに提示されるLUNとしてResourceレプリカを動的にマッピングします。
Exosコントローラーは安全なネットワークAPIによって管理されているため、LINSTORは適切なネットワーキングとユーザー名とパスワードの組み合わせで設定されなければなりません。以下の図はLINSTORクラスターとExosエンクロージャーの関係を示しています。
| マルチホストの設定では、最大8台のLINSTORノードを48Gbit SASリンクで直接接続し、低レイテンシーと高スループットを実現します。 |
ロードバランシングとサーバーのフェイルオーバーはLINSTORによって管理、有効化され、ボリューム作成はExosハードウェアRAIDエンジンによって処理されます。
LINSTORのExosストレージプロバイダは、Exos REST-APIとのネイティブな統合を提供しています。
このセクションでは、Exosの統合を有効にし、LINSTORがExosエンクロージャーでバックアップされたストレージを管理するための設定方法を説明します。
Exosストレージシステムには、あらゆるエンタープライズストレージのニーズに対応する豊富な構成オプションが用意されています。使いやすさを最大限に高めるために、このガイドは次のデフォルトおよび前提条件に基づいています。
-
デュアルコントローラ:Exosシステムコントローラはアクティブ/アクティブであり、自動フェイルオーバー機能を備えています。完全にサポートするには、両方のコントローラのIPアドレスをLINSTORプロパティでも構成する必要があります。
-
デュアルExosプール:プールAのデータがコントローラAを介してアクセスされる場合、最適なパフォーマンスが得られます。ノードが同じコントローラのコントローラAとコントローラBの両方に接続されている場合、LINSTORはLinuxマルチパスを構成し、最適なルートを検出します。
-
Exos Pool Serial Numbers:Exosプールが作成されると、一意のシリアル番号が受信されます。各プールは、ExosエンクロージャとLINSTOR間のリンクを作成するために、LINSTORの下位ストレージとして構成する必要があります。この情報により、LINSTORはExosプールAまたはプールBを参照しているかどうかを把握できます。
-
Exosプールの作成 – 管理者は、LINSTORの構成を行う前にExosプールAとBを作成する必要があります。この時点で、thin provisioning、auto tiering、およびスナップショットのオプションなど、Exosの機能を選択します。
-
エンクロージャ内のレプリカ – Exosシステムには、冗長なコントローラー、電源供給装置、およびドライブへの通信パスが備わっています。一部の管理者は、リソースのレプリカが同じエンクロージャに保存されないようにしたい場合があります。その場合、管理者は、それぞれのエンクロージャから1つのExosプールメンバーのみが構成された複数のLINSTORプールを作成する必要があります。
13.1. LINSTORのストレージプロバイダとしてのExosプロパティ
LINSTORのExosとのネイティブな統合は、LINSTORコントローラにいくつかのプロパティを設定し、以下のセクションで説明するように、Exosエンクロージャに固有の適切なLINSTORオブジェクトを作成することによって構成されます。
次の表の情報は、Exosエンクロージャから取得する必要があります。この情報は、後続のサブセクションで適切なLINSTORコントローラのプロパティおよびLINSTORオブジェクトを移入するために使用されます。
| Exos Information | Description | Placeholder in Command Examples |
|---|---|---|
Exos Enclosure Name |
管理者によって一意に選択された特定のExosエンクロージャー |
|
Controller Hostname |
コントローラーの1つのDNS解決可能なホスト名 |
|
Controller IP |
コントローラのIPアドレス |
|
REST-API Username |
指定されたエンクロージャーの下にあるすべてのExosコントローラーのREST-APIのユーザー名 |
|
REST-API Password |
特定のエンクロージャーの下にあるすべてのExosコントローラーのREST-APIのパスワード |
|
Exos Pool Serial Number |
LINSTORプールのメンバーになるExosプールのシリアル番号 |
|
13.2. LINSTOR Exosの統合
LINSTORのサーバノードおよび複数のExosストレージシステムのトポロジーの構成手順は、次のとおりです。
-
グローバルまたはユニークなExosコントローラのユーザ名とパスワードを設定します。
-
ExosエンクロージャーおよびコントローラーネットワークIDを定義します。
-
物理SASケーブル接続に一致するノードとエンクロージャ間のプールマッピングを作成します。
13.2.1. ステップ1:Exosユーザ名とパスワード
ユーザー名とパスワードは、システム管理者がExosシステムをどのように展開したかに応じて、各Exosエンクロージャに対して一意にするか、またはすべてのエンクロージャに対して共通にすることができます。特定のExosコントローラに対して設定されていない場合は、デフォルトのExosユーザー名とパスワードが使用されます。デフォルトは次のように設定されています。
デフォルトは次のように設定されています。
# linstor exos set-defaults --username <exos_rest_name> # linstor exos set-defaults --password <exos_rest_pass>
一意のユーザー名とパスワードExosコントローラの場合、次のように設定されます。
# linstor controller set-property
StorDriver/Exos/<exos_encl_name>/username <exos_rest_name>
# linstor controller set-property
StorDriver/Exos/<exos_encl_name>/Password <exos_rest_pass>
この方法で入力されたパスワードは、 get-defaults を使用するとプレーンテキストとして表示されます。
|
上記のコマンドを使用すると、LINSTORはパスワードを平文でLINSTORのプロパティに保存し、簡単な linstor controller list-properties コマンドで見ることができます。環境変数の下に隠すことができ、UsernameEnv または PasswordEnv（または両方）プロパティを使用することができます。これにより、LINSTORは実際のユーザー名とパスワードを環境変数で検索するようになります。次の例に示すように：
| LINSTORは環境変数を変更せず、読み取りのみを行います。ストレージ管理者は、env-varsが正しく設定されていることを確認する必要があります。 |
# echo $EXOS_PW
mySecretPassword
# linstor controller set-property \
StorDriver/Exos/<exos_encl_name>/PasswordEnv EXOS_PW
両方のプロパティバージョン(つまり Password と PasswordEnv )が設定されている場合は、環境以外のバージョンが優先されます。
| 環境変数が設定される前にサテライトが開始された場合、新しい環境変数を表示するにはサテライトを再起動する必要があります。 |
13.2.2. ExosエンクロージャーおよびコントローラーネットワークIDを定義します。
LINSTORでExosエンクロージャを登録するには、次のように create コマンドを使います。
# linstor exos create <exos_encl_name> <exos_ctrl_a_ip> [<exos_ctrl_b_ip>]
特別な --username または --password が指定されていない場合は、上記のデフォルトが使用されます。
コントローラーのDNS名とIPアドレスは互いに交換して使用することができます。
LINSTOR内でExosエンクロージャを参照するためにDNSで解決できないホスト名を使用したい場合、<exos_hostname>の代わりに任意の名前を使用できます。ただし、エンクロージャのIPアドレスも指定する必要があります: linstor node create <desired_name> <enclosure_ip>
|
次の例を使用して、現在のコントローラ設定を作成および検査します。
|==================================================================| # linstor exos create Alpha 172.16.16.12 172.16.16.13 # linstor exos list +------------------------------------------------------------------+ | Enclosure | Ctrl A IP | Ctrl B IP | Health | Health Reason | | Alpha | 172.16.16.12 | 172.16.16.13 | OK | | +------------------------------------------------------------------+
より詳細なビューを表示するには、LINSTORコントローラやLINSTORノードに対して、
Exos 関連のプロパティを確認する必要があります。
# linstor controller list-properties | grep Exos | StorDriver/Exos/Alpha/A/IP | 172.16.16.12 | | StorDriver/Exos/Alpha/B/IP | 172.16.16.13 |
13.2.3. ステップ３: ノードにエンクロージャとプールのマッピングの作成
LINSTORサテライトノードは、通常どおり作成できます。
# linstor node create <satellite_hostname>
ストレージプールはLINSTORでも従来通り作成することができます。ただし、以前に登録されたExosエンクロージャの名前とExosプールのシリアル番号を指定する必要があります。
# linstor storage-pool create exos \ <satellite_hostname> <linstor_pool_name> <exos_encl_name> <exos_pool_sn>
linstor_pool_nameは、LINSTOR デプロイメントに対して(ほぼ)任意の 一意のストリングに設定できます。
次に、ExosエンクロージャAlpha内のExosプールを2つのサテライトノードにマッピングする例を示します。
# linstor storage-pool create exos \ node1 poolA Alpha 00c0ff29a5f5000095a2075d01000000 # linstor storage-pool create exos \ node2 poolA Alpha 00c0ff29a5f5000095a2075d01000000
exos ストレージプールを作成した後、LINSTOR Satellite は指定されたExos
エンクロージャ内の接続ポートをスキャンします。ケーブル接続されている場合、
これらのポートは次のコマンドにリストされます。
# linstor exos map -p +----------------------------------------------+ | Node Name | Enclosure Name | Connected Ports | |==============================================| | node1 | Alpha | A0, B0 | | node2 | Alpha | A1, B1 | +----------------------------------------------+
プール構成は次のように表示します。
hr01u09:~ # linstor sp list -s poolA -p +----------------------------------------------------------------------------------------------+ | StoragePool | Node | Driver | PoolName | FreeCapacity | ... | |==============================================================================================| | poolA | node1 | EXOS | Alpha_00c0ff29a5f5000095a2075d01000000 | 581 TiB | ... | | poolA | node2 | EXOS | Alpha_00c0ff29a5f5000095a2075d01000000 | 581 TiB | ... | +----------------------------------------------------------------------------------------------+
使用可能なすべてのExosコマンドの詳細な説明は、組み込みヘルプで参照できます。
# linstor exos -h
13.3. Exosストレージプールによってバックアップされるリソースの作成
Exos でバックアップされたストレージプールからの LINSTOR リソースの作成は LINSTOR resource groups またはより詳細な resource-definition, volume-definition, resource creation ワークフローを説明する各セクションなど、LINSTORユーザーガイドの他のセクションで説明されている通常の LINSTOR 使用パターンに従います。
14. CloudStackにおけるLINSTORボリューム
この章では、LINSTOR®を使用して、Apache CloudStack内でバックエンドとして使用できるボリュームをプロビジョニングする方法について説明します。CloudStackのプライマリストレージは、CloudStack内のホストで実行されている仮想マシン（VM）の仮想ディスクを格納します。LINBIT®が開発したCloudStackプラグインは、LINSTORをCloudStackと統合します。LINSTORをCloudStackと統合する利点は、柔軟に管理できる高可用性のプライマリストレージを提供する手段となることです。
| 現時点では、CloudStack用のLINSTORプラグインは、KVMハイパーバイザーで使用するためのボリュームのプロビジョニングにのみ使用できます。 |
CloudStackの設定と展開は複雑な作業となります。本番用の展開は、ユーザーに使用可能な状態になるまでに数週間から数か月かかる場合があります。一方、仮想環境での基本的なテスト展開は数時間で設定可能かもしれません。この章では、CloudStackにLINSTORを統合する関連する側面に焦点を当て、一般的な概要を提供します。この章の手順には、 CloudStackのドキュメント からの手順やベストプラクティスの推奨事項を補完する必要があります。
| 本番環境への展開前に、CloudStackのドキュメントやその他の章、LINSTORユーザーガイド におけるセキュリティ、ファイアウォール、リソースプロビジョニングの指示に注意を払う必要があります。 |
| この章では、LINSTORユーザーガイドの他の部分と同様に、単語「ノード」が使用されています。ほとんどの場合、ノードはCloudStackの「ホスト」と同等と考えていただいて構いません。 |
14.1. CloudStackの紹介
CloudStackのドキュメントには次のように書かれています。「Apache CloudStackはオープンソースのインフラストラクチャ・サービス（IaaS）プラットフォームで、ストレージ、ネットワーク、コンピュータのリソースプールを管理およびオーケストレーションして、公共またはプライベートのIaaSコンピュートクラウドを構築します」
14.2. CloudStackとLINSTORの展開のための環境の準備
CloudStackを使用するためにLINSTORを展開する前に、いくつかの準備手順を踏む必要があります。
14.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|" ]
この設定は、LVMにDRBDデバイスをスキャンやオープンの試行から拒否するよう指示します。このフィルタを設定しない場合、CPU負荷の増加やLVM操作の停滞が発生する可能性があります。
-
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
14.3.1. リソースの作成の検証
LINSTORをインストールしてストレージプールとストレージレイヤーでバックアップされたリソースグループを作成した後、ストレージリソースを作成できることをテストしてください。これは、作成したリソースグループからリソースを生成することで行うことができます。
| CloudStackのセットアップのベストプラクティス は、プライマリストレージのマウントポイント（およびそれをバックアップするLINSTORリソース）が「6TBを超えない」ことを推奨しています。 |
# 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 | +----------------------------------------------------------------------------------+
14.4. CloudStackのインストール
LINSTORをインストールして準備した後に、CloudStackをインストールして構成することができます。前述の通り、これらの手順は、テストおよび説明目的で素早くCloudStackをセットアップするための方法として考えてください。本番環境に展開する前に、詳細な手順とベストプラクティスの推奨事項については、[CloudStackのドキュメント](http://docs.cloudstack.apache.org/en/latest/)を参照してください。
14.4.1. MySQLのインストール
まず、CloudStackのデータベースに必要なMySQLサーバーインスタンスをインストールしてください。
Ubuntu上では次のように入力してください：
# apt install -y mysql-server
RHELの場合は:
# dnf install -y mysql-server
14.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 は、 CloudStackインストールガイド に指定されている max_connections の値です。必要に応じてこの値を変更することができます。 |
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サービスを再起動してください。
14.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
14.5. CloudStackのインストールと設定
一般的なCloudStackのインストールおよび設定手順については以下に従います。環境によっては特定の要件や変更があるかもしれませんので、 CloudStack Installation Guide の手順も参照してください。
14.5.1. CloudStackのインストール
公式なCloudStackリリースは常にソースコード形式で提供されますが、便宜上、cloudstack.orgでコミュニティが作成したDEBおよびRPMパッケージが利用可能です。
-
Ubuntu DEBリポジトリ: http://download.cloudstack.org/ubuntu
-
EL8 RPM repository: http://download.cloudstack.org/el/8/
-
EL7 RPM repository: http://download.cloudstack.org/el/7/
インストールに必要なパッケージを見つけてダウンロードするには、上記のリンクに従ってください。ダウンロードしたパッケージの整合性を確認する際には、CloudStackの署名キーを使用することを忘れないでください。詳細はこちらの リンク に記載されています。
または、CloudStackのリポジトリをLinuxディストリビューションに適した方法で設定し、その後、ディストリビューションのパッケージマネージャを使用してパッケージを取得してインストールするために、 こちら の手順に従うこともできます。
CloudStackリポジトリを追加した後、パッケージマネージャのリポジトリリストを更新してからパッケージをインストールする必要があるかもしれません。
CloudStackの管理ノードには、次のパッケージをインストールしてください。
-
cloudstack-management -
cloudstack-common -
cloudstack-ui
他のクラスターノードには、cloudstack-agent パッケージをインストールしてください。
14.5.2. CloudStackデータベースの初期化:
必要なCloudStackパッケージをインストールした後、CloudStackデータベースを初期化してください。
テストのために、マネジメントノードに次のコマンドを入力することができます:
# cloudstack-setup-databases cloud:cloud --deploy-as=root:nonsense -i <node_name>
ここにある cloud: の後ろや nonsense は、適宜変更できるパスワードです。
本番環境への展開では、CloudStack インストールガイド>の 詳細な手順に従ってください。
14.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
14.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
14.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
14.7.2. CloudStack管理サービスの再起動
必要なセットアップと準備設定を行った後に、「cloudstack-management」サービスを再起動してください。
# systemctl restart cloudstack-management
CloudStackの初期データベースセットアップの進捗状況は、次のように入力してフォローすることができます:
# journalctl -u cloudstack-management -f
14.7.3. CloudStackのUIにログインする
しばらく経った後、CloudStackの管理UIにログインできるようになるはずです。マネジメントノードの解決可能なホスト名が node-0 であるとした場合、クラスター内のコンピューターのウェブブラウザに以下のURLを入力してください：http://node-0:8080/client。
CloudStack UI ポータルのログインページにアクセスしたら、デフォルトのユーザー名 admin とデフォルトのパスワード password を使用してポータルにログインしてください。
ログインに成功すると、CloudStack UI は「CloudStackへようこそ」というページを表示します。
14.7.4. CloudStackの初期設定ウィザードを実行する
CloudStackのセットアップを継続するには、初期化ウィザードを起動して設定を行います。ウィザードを起動するには、「インストールを続行」ボタンをクリックしてください。
ウィザードは最初に、管理者ユーザーのデフォルトパスワードを変更するように促します。パスワードを変更した後、ウィザードの手順に従って、ゾーン、ネットワーク、およびリソースの詳細を構成することができます。各セットアップステップで環境とニーズに応じてフィールドを入力してください。CloudStackの初期化に関する詳細は、こちらで見つけることができます。
以下のフィールドは、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のダッシュボードに戻ります。
14.8. CloudStackにおける次のステップを踏む
LINSTORをCloudStackで使用するために設定したら、他のタスクに移ることができます。例えば、CloudStackのVMをホストするためのホストの追加に進むことができます。http://docs.cloudstack.apache.org/en/4.17.1.0/adminguide/hosts.html#adding-hosts [ホストの追加]
LINBITは、LINSTORとCloudStackを3つのノードVMクラスターに展開するデモンストレーション動画も公開しています。動画は[こちら](https://www.youtube.com/watch?v=hI_kTlsbNeU)でご覧いただけます。
14.9. クラウドスタックにおける高可用性とLINSTORボリューム
HA-enabled instancesによると、KVMハイパーバイザーの場合、スプリットブレイン状況から安全なのはHA有効化されたホストだけです。HA有効化されたホストは、「アウトオブバンド管理」と呼ばれるIPMIの機能を持つ必要があります。
そのドキュメンテーションは、KVM インスタンスが NFS や iSCSI ストレージ上にある場合には正しいです。インスタンスの仮想ディスクが LINSTOR 上にある場合、HA が有効化されたホストは必要なく、推奨されません。”out-of-band management” は必要ありませんし、IPMI も不要です。CloudStack の “VM-HA” が十分で安全です。
DRBDに組み込まれたクォーラム機構とLINSTORによって有効化されたこの機構は、スプリットブレインが発生しないように防止します。
14.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を失ったプライマリノードの回復 セクションの詳細を参照してください。
15. Oracle Linux Virtualization Manager における LINSTOR ボリューム
この章では、LINSTOR®を使用して、Oracle Linux Virtualization Manager向けに永続的でレプリケーションされた高性能ブロックストレージをプロビジョニングする方法について説明します。
15.1. オラクルLinux仮想化マネージャーへの導入:
Oracle Linux Virtualization Manager (OLVM)は、oVirtに基づくサーバー仮想化管理プラットフォームです。これは、Oracle Linuxに基づいたカーネルベースの仮想マシン（KVM）環境を構成、管理、監視することができます。
OLVMはLINSTORと統合できる複数のストレージ技術をサポートしています。
-
iSCSI や NFS ストレージは共有ストレージ用に使用されます。このセットアップでは、すべての OLVM ノードが、iSCSI または NFS を使用してストレージボリュームをエクスポートするサービスホストに接続します。ここで、LINSTOR Gateway は、複製された DRBD ボリュームに基づいて iSCSI ターゲットと NFS エクスポートを作成および管理し、高可用性を実現するのに役立ちます。
-
Managed Block Storage はOLVMで利用可能な別の機能です。VM用のディスクは、サービスホスト上のストレージプールからではなく、別々のボリュームとして管理されます。これにより、サービスホストが追加するパフォーマンスのオーバーヘッドを避けながら、ボリュームをVMに 直接アタッチすることが可能になります。
15.2. OLVMストレージのためにLINSTOR Gatewayを使用する
<<ch-linstor-gateway,LINSTOR Gateway>> は、高可用性の iSCSI ターゲットや NFS エクスポートを作成し、OLVM がデータ領域として利用できます。すべてのボリュームアクセスは、ボリュームをエクスポートしている LINSTOR Gateway ホストを介してルーティングされます。ボリュームアクセスには、ストレージ領域を使用するすべての VM による読み取りと書き込みが含まれます。
必要な前提条件は、次の通りです:
-
LINSTOR Cluster が動作し、 High Availability が有効になっています。
-
動作している LINSTOR Gateway のインストール。
| LINSTORとLINSTOR Gatewayは、OLVMと同じノードで実行する必要はありません。ただし、GatewayノードがOLVMホストからアクセス可能である必要があります。 |
15.2.1. LINSTORゲートウェイをデータドメインに使用中
データドメインはOLVMのVMの主要なストレージです。LINSTOR Gatewayを使用すると、iSCSIターゲットとNFSエクスポートの両方を作成して、OLVMでデータドメインとして使用できます。
linstor-gateway コマンドを使用して、iSCSIまたはNFSエクスポートを作成します。OLVMノードからアクセス可能なサービスIPを選択してください。次の例では、60GBのiSCSIエクスポートを 192.168.0.100 で、および50GBのNFSエクスポートを 192.168.0.101:/srv/gateway-exports/nfs-data で利用できるようにします。
$ linstor-gateway iscsi create iqn.2019-08.com.linbit:data-domain 192.168.0.100/24 60G Created iSCSI target 'iqn.2019-08.com.linbit:data-domain' $ linstor-gateway nfs create nfs-data 192.168.0.101/24 50G Created export 'nfs-data' at 192.168.0.101:/srv/gateway-exports/nfs-data
ストレージドメインを構成するには、OLVM管理ポータルに移動し、「ストレージ > ドメイン」ページを開きます。新しいストレージドメインのために名前を選択して、「新しいドメイン」をクリックします。次に、ドメイン機能（ データ または ISO ）と一致するストレージタイプ（ iSCSI または NFS ）を選択します。構成を完了するために必要な接続パラメーターを入力してください。
15.2.2. LINSTOR Gatewayを使用して、OLVM Self-Hosted Engineをデプロイする。
LINSTOR Gateway iSCSI Targetsは、OLVM self-hosted engineをデプロイする際に使用される初期データドメインを作成するために使用できます。
セルフホステッドエンジンのために、VMに不利な干渉のリスクを減らすために別のデータドメインを使用してください。管理VM用に少なくとも60GBのiSCSIターゲットを作成してください。次の例では、60GBのボリュームが iqn.2019-08.com.linbit:olvm-engine としてエクスポートされ、IPアドレス 192.168.0.200 で利用可能です。セットアップに適した値にIPアドレスとiSCSIターゲット名を変更してください。
$ linstor-gateway iscsi create iqn.2019-08.com.linbit:engine-data 192.168.0.200/24 60G
OLVMセルフホステッドエンジンのセットアップ中に、マネージャー仮想マシンのストレージの詳細を提供するように求められます。 ストレージタイプの iscsi とIPアドレス 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ターゲットがOLVMのデータ領域として追加されます。VMには別々のデータ領域を使用して、自己ホストエンジンのストレージと干渉を避けてください。
15.3. LINSTOR Cinderを使用して、管理されたブロックストレージを利用
OLVMは、LINSTOR Cinder ドライバを使用するように構成できます。これにより、LINSTOR が管理するボリュームをVMホストに直接アタッチすることが可能です。LINSTOR Gateway を使用するのとは異なり、ストレージアクセスとレプリケーションは、VMが実行されているホストから直接行われます。
LINSTOR Cinderを使用するには、OLVMの設定に追加の手順が複数必要です。
-
全ての OLVM ホスト、エンジンホストを含む、LINBIT に登録し、
ovirtリポジトリを有効にする必要があります:# curl -O https://my.linbit.com/linbit-manage-node.py # chmod +x ./linbit-manage-node.py # ./linbit-manage-node.py ... 1) pacemaker-2(Disabled) 2) ovirt(Enabled) 3) drbd-9.0(Disabled) 4) drbd-9(Enabled) ... -
OLVMホストおよび管理エンジンは、LINSTORクラスターの一部である必要があります。すべてのホストに
linstor-satelliteサービスがインストールおよび構成されていることを確認してください。 -
OLVM では、
CinderLibサポートを有効にする必要があります。これはデフォルトで無効になっています。有効にするには、エンジンホストでengine-setupを実行してください。$ engine-setup --reconfigure-optional-components ... --== PRODUCT OPTIONS ==-- Configure Cinderlib integration (Currently in tech preview) (Yes, No) [No]: Yes ...
-
エンジンホストは、インストールされている
python3-cinder-commonのLINBITバージョンを持っている必要があります。このバージョン番号にはlinbit1という文字列が含まれています。$ dnf install --enablerepo=ovirt python3-cinder-common $ dnf list --installed python3-cinder-common Installed Packages python3-cinder-common.noarch 1:17.2.0-1.el8.linbit1 @linbit-ovirt
-
エンジンホストには
linstor-cinderパッケージをインストールする必要があります。$ dnf install --enablerepo=ovirt linstor-cinder
-
すべてのOLVMホストには、
vdsmとpython3-osbrickのLINBITバージョンがインストールされている必要があります。これは、バージョン番号にlinbit1の文字列が含まれていることで識別できます。$ dnf install --enablerepo=ovirt vdsm python3-os-brick $ dnf list --installed vdsm python3-os-brick Installed Packages python3-os-brick.noarch 4.0.4-1.el8.linbit1 @linbit-ovirt vdsm.x86_64 4.40.100.2-1.0.13.el8.linbit1 @linbit-ovirt
LINSTOR Cinderを管理ブロックストレージ用に構成するには、OLVM管理ポータルに移動し、「Storage > Domains」ページを開きます。 New Domain をクリックし、ドメイン機能を「管理ブロックストレージ」に設定します。名前を選択し、次のドライバオプションを設定します。
Driver Option |
Value |
|
|
|
URL of the LINSTOR Controller Endpoint(s). Separate multiple endpoints by using a comma ( |
|
LINSTOR resource group to use. Volumes created in this data domain will inherit all settings on the resource group. |
| OLVM 4.4では、VMポータルから管理ブロックストレージを使用してVMを作成することはできません。デプロイメントポータルを通じてのみ可能です。 |
