管理ガイド

Red Hat Gluster Storage 3.5

Red Hat Gluster Storage の設定および管理

概要

Red Hat Gluster Storage Administration Guide では、オンプレミス型 Red Hat Gluster Storage の設定および管理について説明します。
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社の CTO、Chris Wright のメッセージを参照してください。

パート I. 前書き

第1章 はじめに

1.1. Red Hat Gluster Storage について

Red Hat Gluster Storage は、エンタープライズ向けに柔軟かつアジャイルな非構造化データストレージを提供するソフトウェアで、スケールアウトした唯一のストレージソリューションです。
Red Hat Gluster Storage は、データストレージとインフラストラクチャーの統合し、パフォーマンスを向上させ、可用性および管理容易性を強化して、広範囲に及ぶ組織のストレージに関する課題とニーズを満たします。
オンプレミスまたはパブリッククラウドに製品をインストールし、管理できます。

1.2. glusterFS について

glusterFS は、ネットワークで各種のストレージサーバーを集計し、それらを相互接続して 1 つの大きな並立ネットワークファイルシステムにします。スタック可能なユーザー空間設計に基づいて、さまざまなワークロードに対して例外的なパフォーマンスを提供し、Red Hat Gluster Storage の主要なビルディングブロックです。
POSIX と互換性のある glusterFS サーバー (XFS ファイルシステム形式を使用してディスクにデータを保存する) は、Network File System (NFS) や Server Message Block (SMB) (CIFS としても知られる) などの業界標準のアクセスプロトコルを使用してアクセスできます。

1.3. オンプレミスインストール

Red Hat Gluster Storage for On-Premise により、物理ストレージを仮想化され、スケーラブルで一元管理されたストレージの一元管理プールとして使用できます。
Red Hat Gluster Storage は、コモディティーサーバーにインストールできるため、強力かつ拡張性の高い、高可用性 NAS 環境になります。

パート II. 概要

第2章 アーキテクチャーおよび概念

本章では、Red Hat Gluster Storage のアーキテクチャーおよびストレージの概念の概要を説明します。

2.1. アーキテクチャー

Red Hat Gluster Storage 設計の中核となるのは、ストレージを設計するための全く新しい方法です。その結果、システムは、高いスケーラビリティ、高い回復力、さらなるパフォーマンスを発揮することができます。
スケールアウトシステムでは、データおよびメタデータの論理的および物理的な場所の追跡が最も大きな課題の 1 つとなります。多くの分散システムは、メタデータサーバーを作成してデータおよびメタデータの場所を追跡することで、この問題を解決します。従来のシステムは、より多くのファイル、サーバー、またはディスクを追加するため、中央のメタデータサーバーはパフォーマンスのボトルネックとなり、一元的な障害点となります。
その他の従来のストレージソリューションとは異なり、Red Hat Gluster Storage はメタデータサーバーを必要とせず、Elastic ハッシュアルゴリズムを使用してアルゴリズムでファイルを見つけます。このメタデータのないサーバーのアーキテクチャーにより、パフォーマンス、リニアスケーラビリティー、および信頼性が向上します。

図2.1 Red Hat Gluster Storage アーキテクチャー

Red Hat Gluster Storage アーキテクチャー

2.2. オンプレミスアーキテクチャー

Red Hat Gluster Storage for On-premises を使用すると、企業は製品ストレージハードウェアを使用して、仮想の、スケーラブルな、集中管理ストレージプールとして物理ストレージを扱うことができます。
ユーザーまたはグループを共有ストレージの論理ボリュームに分割することで、マルチテナンシーをサポートします。これにより、ユーザーはコストの高い、モノリシックの、デプロイが困難なストレージアレイに対する依存を削除することや、縮小および管理を行うことができます。
パフォーマンスに影響を与えずに、すぐに、さまざまなワークロードにキャパシティを追加できます。ストレージは、さまざまなワークロードで一元管理できるため、ストレージ効率が向上します。

図2.2 Red Hat Gluster Storage for On-premises アーキテクチャー

Red Hat Gluster Storage for On-premises アーキテクチャー
Red Hat Gluster Storage for On-premisese は、モジュール式でスタック可能な設計と、一意のメタデータなしのサーバーアーキテクチャーを備えたオープンソース分散ファイルシステムである glusterFS をベースにしています。このメタデータのないサーバーのアーキテクチャーにより、パフォーマンス、リニアスケーラビリティー、および信頼性が向上します。

2.3. ストレージの概念

以下は、『Red Hat Gluster Storage Administration Guide』 全体で使用されるファイルシステムおよびストレージに関する一般的な用語です。
ブリック
ストレージの glusterFS Basic ユニットで、信頼できるストレージプール内のサーバーのエクスポートディレクトリーで示されます。ブリックは、以下の形式でサーバーをエクスポートディレクトリーと組み合わせることで表現されます。
SERVER:EXPORT
以下は例になります。
myhostname:/exports/myexportdir/
ボリューム
ボリュームは、ブリックの論理コレクションです。Red Hat Gluster Storage 管理操作のほとんどは、ボリュームで行われます。
トランスレーター
トランスレーターは 1 つ以上のサブボリュームに接続し、それらのボリュームで操作を行い、サブボリューム接続を提供します。
サブボリューム
少なくとも 1 つのトランスレーターで処理された後のブリック。
Volfile
ボリューム (vol) ファイルは、Red Hat Gluster Storage で信頼されるストレージプールの動作を決定する設定ファイルです。高レベルでは GlusterFS には、サーバー、クライアント、および管理デーモンの 3 つのエンティティーがあります。これらのエンティティーにはそれぞれ独自のボリュームファイルがあります。サーバーおよびクライアントのボリュームファイルは、ボリュームの作成時に管理デーモンにより生成されます。
サーバーおよびクライアントの Vol ファイルは /var/lib/glusterd/vols/VOLNAME ディレクトリーにあります。管理デーモン vol ファイルは glusterd.vol という名前で/etc/glusterfs/ ディレクトリーにあります。
警告
Red Hat は管理デーモンで生成した vol ファイルに対応していない vol ファイルは、手動で /var/lib/glusterd で変更しないでください。
glusterd
glusterd は、信頼できるストレージプールのすべてのサーバーで実行する必要がある glusterFS 管理サービスです。
クラスター
リンクしたコンピューターの信頼できるプールが、1 つのコンピューティングリソースを再構築します。Red Hat Gluster Storage では、クラスターは信頼できるストレージプールとも呼ばれます。
クライアント
ボリュームをマウントするマシン (これはサーバーでもある可能性もあります)。
ファイルシステム
コンピューターファイルを保存して整理する手段。ファイルシステムは、コンピューターのオペレーティングシステムでストレージ、操作、取得のデータベースにファイルを編成します。
出典: wood
分散ファイルシステム
複数のクライアントが、信頼できるストレージプールのサーバー/ブリックに分散されるデータを同時にアクセスできるファイルシステム。複数の場所間でのデータ共有は、すべての分散ファイルシステムに基本となります。
Virtual File System (VFS)
VFS は、標準の Linux ファイルシステムに関連するすべてのシステムコールを処理するカーネルソフトウェア層です。これは、複数の種類のファイルシステムへの共通のインターフェースを提供します。
POSIX
Portable Operating System Interface (for Unix) (POSIX) は、アプリケーションプログラミングインターフェース (API) を定義するために IEEE が指定する関連標準ファミリーの名前であり、UNIX オペレーティングシステムのバリアントと互換性のあるソフトウェアのシェルおよびユーティリティーインターフェースです。Red Hat Gluster Storage は、完全に POSIX 互換のファイルシステムをエクスポートします。
メタデータ
メタデータは、他のデータに関する情報を提供するデータです。
FUSE
FUSE (File System in User space) では、Unix のようなオペレーティングシステムのロード可能なカーネルモジュールで、権限のないユーザーがカーネルコードを編集せずに独自のファイルシステムを作成できます。そのために、FUSE モジュールはカーネルインターフェースに「ブリッジ」のみを提供しながら、ユーザー空間でファイルシステムコードを実行することで実現できます。
出典: wood
geo レプリケーション
Geo レプリケーションは、LAN (Local Area Network)、Wide Area Network (WAN)、およびインターネットを介して、あるサイトから別のサイトに継続的に、非同期および増分レプリケーションサービスを提供します。
N-way レプリケーション
通常、Rous または Amazon Web Services Availability Zone 全体にデプロイされるローカル同期データレプリケーション。
ペタバイト
ペタバイトは、1 クアドリリアンバイト (1000 テラバイト) に相当する情報の単位です。ペタバイトの単位シンボルは PB です。接頭辞 peta-(P) は 1000 の累乗を示します。
1 PB = 1,000,000,000,000,000 B = 1000^5 B = 10^15 B.
1024 の対応する累乗には、バイナリーの接頭辞を使用する「pebibyte」(PiB) が使用されます。
出典: wood
RAID
RAID (Redundant Array of Independent Disks) は、冗長性によりストレージの信頼性を向上させるテクノロジーです。複数の低コストで信頼性が低いディスクドライブコンポーネントを、アレイ内のすべてのドライブが分離している論理ユニットに統合します。
RRDNS
Round Robin Domain Name Service (RRDNS) は、アプリケーションサーバー間で負荷を分散する方法です。RRDNS は、DNS サーバーのゾーンファイルに、同じ名前と異なる IP アドレスを使用して、複数のレコードを作成することで実装されます。
サーバー
データが格納されるファイルシステムをホストするマシン (仮想マシンまたはベアメタル)。
ブロックストレージ
ブロック特殊ファイル (ブロックデバイス) は、システムがブロック形式でデータを移動するデバイスに対応します。これらのデバイスノードは、多くの場合、ハードディスク、CD-ROM ドライブ、またはメモリーリージョンなどのアドレス可能なデバイスを表します。Red Hat Gluster Storage 3.4 以降では、ブロックストレージは OpenShift Container Storage converged および独立したモードのユースケースのみをサポートします。このユースケースには、gluster-block コマンドラインツールを使用して、ブロックストレージを作成して設定できます。詳細は、「Container-Native Storage for OpenShift Container Platform」を参照してください。
スケールアップストレージ
単一のディメンションでストレージデバイスの容量を増やします。たとえば、信頼できるストレージプールにディスクの容量を追加します。
スケールアウトストレージ
単一ディメンションのストレージデバイスの容量を増大します。たとえば、同じサイズのシステムを追加するか、または信頼されたストレージプールの CPU、ディスク容量、スループットを増大する、信頼されたストレージプールにサーバーを追加します。
信頼済みストレージプール
ストレージプールは、ストレージサーバーの信頼済みネットワークです。最初のサーバーを起動すると、ストレージプールはそのサーバーのみで構成されます。
名前空間
一意の識別子またはシンボルの論理グループを保持するために作成される抽象コンテナーまたは環境。Red Hat Gluster Storage の信頼されるストレージプールはそれぞれ、単一の名前空間を POSIX マウントポイントとして公開します。これには、信頼できるストレージプールのすべてのファイルが含まれます。
ユーザー空間
ユーザー空間で実行しているアプリケーションは、アクセスの調整にカーネルを使用する代わりにハードウェアと直接対話しません。ユーザー空間アプリケーションは、通常、カーネルスペースのアプリケーションよりも移植性があります。glusterFS はユーザー空間アプリケーションです。

分散ハッシュテーブル定義

ハッシュ化されたサブボリューム
ファイルまたはディレクトリー名がハッシュ化される Distributed Hash Table Translator サブボリューム。
キャッシュ化されたサブボリューム
ファイルのコンテンツが実際に存在する Distributed Hash Table Translator サブボリューム。ディレクトリーの場合、cached-subvolume の概念は関係ありません。これは、ハッシュ化/サブボリュームではないサブボリュームを指すために使われます。
Linkto-file
新規に作成されたファイルの場合、ハッシュ化およびキャッシュされたサブボリュームは同じです。名前変更 (名前つまりファイルのハッシュ化されたサブボリューム) のようなディレクトリーエントリー操作が、ファイルのデータ全体を新しいハッシュサブボリュームに移動する代わりにファイルで実行されると、新たにハッシュ化されたサブボリュームに同じ名前のファイルが作成されます。このファイルの目的は、データがあるノードへのポインターとしてのみ動作します。このファイルの拡張属性では、キャッシュされたサブボリュームの名前が保存されます。新たにハッシュ化されたサブボリューム上のこのファイル、linkto-file と呼ばれます。linkto ファイルは、ディレクトリー以外のエンティティーにのみ関連します。
ディレクトリーレイアウト
ディレクトリーレイアウトは、gluster ボリュームのファイルの保存場所を決定するのに役立ちます。
クライアントがファイルを作成または要求すると、DHT トランスレーターはファイルのパスをハッシュして整数を作成します。gluster サブボリューム内の各ディレクトリーは、整数が特定の範囲にあるファイルを保持しているため、指定したファイルのハッシュは gluster ボリュームの特定のサブボリュームにマッピングされます。ディレクトリーレイアウトは、すべてのサブボリュームで特定のディレクトリーに割り当てられる整数範囲を決定します。
ディレクトリーレイアウトはディレクトリーが最初に作成されたときに割り当てられます。また、ボリュームでリバランス操作を実行することで再割り当てできます。ディレクトリーの作成時にブリックまたはサブボリュームがオフラインの場合、リバランスが実行されるまでレイアウトの一部にはなりません。
ブリックがボリュームに追加された後にディレクトリーレイアウトを再計算するために、ボリュームをリバランスする必要があります。詳細は、「ボリュームのリバランス」 を参照してください。
レイアウトの修正
リバランスプロセス中に実行されるコマンド。
リバランスプロセス自体は、以下の 2 つの段階で構成されます。
  1. ディレクトリーのレイアウトを修正し、追加または削除されたサブボリュームに対応します。また、ディレクトリーを修復し、レイアウトの一貫性の有り無しを確認して、必要に応じて拡張属性でレイアウトを永続化します。また、すべてのサブボリュームで同じ属性がディレクトリーに同じになることを確認することもできます。
  2. cached-subvolume から hashed-subvolume にデータを移行します。

パート III. 設定および検証

第3章 Red Hat Gluster Storage に関する考慮事項

3.1. ファイアウォールおよびポートアクセス

Red Hat Gluster Storage が適切に機能するには、複数のポートへのアクセスが必要です。「ポートアクセスの要件」 で示されているように、ポートアクセスが利用可能であることを確認します。

3.1.1. ファイアウォールの設定

Red Hat Entperise Linux 6 と Red Hat Enterprise Linux 7 では、ファイアウォール設定ツールが異なります。
Red Hat Enterprise Linux 6 の場合は、iptables コマンドを使用してポートを開きます。
# iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 5667 -j ACCEPT
# service iptables save
重要
Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。『 インストールガイド』の「 『バージョンの詳細』 表」 『および「Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 」を参照してください。
Red Hat Enterprise Linux 7 では、デフォルトのポートが他のサービスで使用されていない場合は、通常はポートを開くのではなく、サービスを追加する方が容易になります。
# firewall-cmd --zone=zone_name --add-service=glusterfs
# firewall-cmd --zone=zone_name --add-service=glusterfs --permanent
ただし、デフォルトのポートがすでに使用されている場合は、以下のコマンドで特定のポートを開くことができます。
# firewall-cmd --zone=zone_name --add-port=port/protocol
# firewall-cmd --zone=zone_name --add-port=port/protocol --permanent
以下に例を示します。
# firewall-cmd --zone=public --add-port=5667/tcp
# firewall-cmd --zone=public --add-port=5667/tcp --permanent

3.1.2. ポートアクセスの要件

表3.1 すべてのストレージサーバーで以下のポートを開きます。

接続ソースTCP ポートUDP ポート推奨用途
有効な SSH キーを持つ認証されたネットワークエンティティー22-すべての設定geo レプリケーションを使用したリモートバックアップ
認証されたネットワークエンティティー。他の RPC サービスと競合しないように注意してください。111111すべての設定RPC ポートマッパーおよび RPC バインド
認証された SMB/CIFS クライアント139 および 445137 および 138SMB/CIFS を使用したストレージの共有SMB/CIFS プロトコル
認証された NFS クライアント20492049Gluster NFS または NFS-Ganesha を使用したストレージの共有NFS プロトコルを使用したエクスポート
Samba-CTDB クラスターのすべてのサーバー4379-SMB および Gluster NFS を使用したストレージの共有CTDB
認証されたネットワークエンティティー24007-すべての設定glusterd を使用した管理プロセス
認証されたネットワークエンティティー55555-すべての設定
Gluster イベントデーモン
以前のバージョンの Red Hat Gluster Storage から最新のバージョン 3.5.4 にアップグレードする場合、glusterevents デーモンに使用されるポートは、柔軟性のある範囲にあるように修正する必要があります。
NFSv3 クライアント662662NFS-Ganesha および Gluster NFS を使用したストレージの共有statd
NFSv3 クライアント3280332803NFS-Ganesha および Gluster NFS を使用したストレージの共有NLM プロトコル
マウント要求を送信する NFSv3 クライアント-32769Gluster NFS を使用したストレージの共有Gluster NFS MOUNT プロトコル
マウント要求を送信する NFSv3 クライアント2004820048NFS-Ganesha を使用したストレージの共有NFS-Ganesha MOUNT プロトコル
NFS クライアント875875NFS-Ganesha を使用したストレージの共有NFS-Ganesha RQUOTA プロトコル(クォータ情報の取得)
pacemaker/corosync クラスターのサーバー2224-NFS-Ganesha を使用したストレージの共有pcsd
pacemaker/corosync クラスターのサーバー3121-NFS-Ganesha を使用したストレージの共有pacemaker_remote
pacemaker/corosync クラスターのサーバー-5404 および 5405NFS-Ganesha を使用したストレージの共有corosync
pacemaker/corosync クラスターのサーバー21064-NFS-Ganesha を使用したストレージの共有dlm
認証されたネットワークエンティティー49152 - 49664-すべての設定ブリック通信ポート必要なポートの合計数は、ノード上のブリックの数によって異なります。マシンのブリックごとに 1 つのポートが必要です。
Gluster クライアント1023 または 49152-システムポートがすでにマシンで使用されている場合にのみ適用されます。ブリックとクライアントプロセス間の通信。

表3.2 NFS-Ganesha および Gluster NFS ストレージクライアントで以下のポートを開く

接続ソースTCP ポートUDP ポート推奨用途
NFSv3 サーバー662662NFS-Ganesha および Gluster NFS を使用したストレージの共有statd
NFSv3 サーバー3280332803NFS-Ganesha および Gluster NFS を使用したストレージの共有NLM プロトコル

3.2. 機能互換性サポート

Red Hat Gluster Storage は多くの機能をサポートします。ほとんどの機能は他の機能でサポートされますが、一部の例外があります。本セクションでは、Red Hat Gluster Storage のデプロイメントの計画に役立つ、サポートされている機能、および他の機能と互換性のある機能について分かりやすく説明します。
注記
インターネットプロトコルバージョン 6 (IPv6) のサポートは、Red Hat Hyperconverged Infrastructure for Virtualization 環境でのみ利用でき、Red Hat Gluster Storage スタンドアロン環境では使用できません。
以下の表の機能は、指定されたバージョン以降でサポートされています。

表3.3 Red Hat Gluster Storage バージョンでサポートされる機能

機能バージョン
Arbiter ブリック3.2
Bitrot 検出3.1
Erasure コーディング3.1
Google Compute Engine3.1.3
メタデータのキャッシュ3.2
Microsoft Azure3.1.3
NFS バージョン 43.1
SELinux3.1
シャード化3.2.0
スナップショット3.0
スナップショット、クローン作成3.1.3
スナップショット、ユーザーサービスが可能3.0.3
階層化 (Tiering)(非推奨)3.1.2
Volume Shadow Copy (VSS)3.1.3

表3.4 ボリュームタイプ別にサポートされる機能

ボリュームタイプシャード化階層化 (Tiering)(非推奨)クォータスナップショットgeo-レプリケーションBitrot
Arbitrated-Replicatedはいいいえはいはいはいはい
Distributed (分散)いいえはいはいはいはいはい
Distributed-Dispersedいいえはいはいはいはいはい
Distributed-Replicatedはいはいはいはいはいはい
Replicated (レプリケート)はいはいはいはいはいはい
シャード化該当なしいいえいいえいいえはいいいえ
階層化 (Tirered)(非推奨)いいえ該当なし限定的[a]限定的 [a]限定的 [a]限定的 [a]
[a] 詳細は、『 『Red Hat Gluster Storage 3.5 Administration Guide』』の「Tiering Limitations」を参照してください。

表3.5 クライアントプロトコルでサポートされる機能

機能FUSEgluster-NFSNFS-GaneshaSMB
Arbiterはいはいはいはい
Bitrot 検出はいはいいいえはい
dm-cacheはいはいはいはい
暗号化 (TLS-SSL)はいはいはいはい
Erasure コーディングはいはいはいはい
Export サブディレクトリーはいはいはい該当なし
geo-レプリケーションはいはいはいはい
クォータ(非推奨)
警告
QUOTA 機能の使用は、Red Hat Gluster Storage 3.5.3 では非推奨です。Red Hat ではこの機能の使用を推奨しておらず、Red Hat Gluster Storage 3.5.3 にアップグレードする新規デプロイメントおよび既存デプロイメントでサポートしません。
詳細は、9章ディレクトリークォータの管理 を参照してください。
はいはいはいはい
RDMA(非推奨)
警告
RDMA をトランスポートプロトコルとして使用することは、Red Hat Gluster Storage 3.5 で非推奨となっています。Red Hat ではこの使用を推奨しておらず、Red Hat Gluster Storage 3.5.3 にアップグレードする新規デプロイメントおよび既存デプロイメントでサポートしません。
Yesいいえいいえいいえ
スナップショットはいはいはいはい
スナップショットのクローン作成はいはいはいはい
階層化 (Tiering)(非推奨)
警告
階層化は、Red Hat Gluster Storage 3.5 では非推奨です。Red Hat ではこの使用を推奨しておらず、Red Hat Gluster Storage 3.5.3 にアップグレードする新規デプロイメントおよび既存デプロイメントでは階層化をサポートしません。
Yesはい該当なし該当なし

第4章 信頼できるストレージプールへのサーバーの追加

ストレージプールは、ストレージプールのネットワークです。
最初のサーバーを起動するとき、ストレージプールはそのサーバーのみで構成されます。ストレージプールに追加のストレージサーバーを追加するのは、実行中の信頼済みストレージサーバーの probe コマンドを使用して可能です。
重要
サーバーを信頼できるストレージプールに追加する前に、3章Red Hat Gluster Storage に関する考慮事項 で指定されたポートが開いていることを確認する必要があります。
Red Hat Enterprise Linux 7 では、以下のコマンドを使用して、ランタイムおよび永続モードのアクティブなゾーンで glusterFS ファイアウォールサービスを有効にします。
アクティブゾーンの一覧を取得するには、以下のコマンドを実行します。
# firewall-cmd --get-active-zones
アクティブなゾーンでファイアウォールサービスを許可するには、次のコマンドを実行します。
# firewall-cmd --zone=zone_name --add-service=glusterfs
# firewall-cmd --zone=zone_name --add-service=glusterfs --permanent
ファイアウォールの詳細情報は、『 Red Hat Enterprise Linux 7 セキュリティーガイド』: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_Firewalls.html の 『ファイアウォールの使用』 のセクションを参照してください。
注記
2 つの gluster コマンドが同じボリュームで同時に実行されると、以下のエラーが表示されます。
Another transaction is in progress. (別のトランザクションが進行中です)
Red Hat Gluster Storage のこの動作により、複数のコマンドがボリューム設定を同時に変更できなくなるため、一貫性が失われる可能性があります。このような実装は、Red Hat Gluster Storage コンソールや Red Hat Enterprise Virtualization Manager などのモニタリングフレームワークを使用する環境で一般的です。たとえば、Red Hat Gluster Storage が信頼する Storage Pool の 4 つのノードでは、gluster ボリュームのステータス VOLNAME コマンドが 2 つのノードから同時に実行されると、このメッセージが確認されます。

4.1. 信頼できるストレージプールへのサーバーの追加

Gluster ピアプローブ [server] コマンドを使用して、サーバーを信頼済みサーバープールに追加します。
注記
Red Hat Gluster Storage ノードの低いバージョンからより高いバージョンのノードのプローブはサポートされていません。

信頼できるストレージプールへの 3 台のサーバーの追加

ボリュームを構成する 3 つのストレージプールで構成される、信頼できるストレージプールを作成します。

前提条件

  • glusterd サービスは、信頼できるストレージプールの追加を必要とするすべてのストレージサーバーで実行する必要があります。サービスの起動および停止の手順については、22章glusterd サービスの起動と停止 を参照してください。
  • 信頼されるストレージサーバーである Server1 が起動します。
  • ターゲットサーバーのホスト名は DNS で解決できる必要があります。
  1. サーバー 1 から Gluster ピアプローブ [server] を実行して、信頼されるストレージプールにサーバーを追加します。
    注記
    • Server1 のセルフプロービングは、デフォルトで信頼されるストレージプールの一部であるため、エラーが発生します。
    • RDMA または RDMA のいずれかに、ストレージプールに TCP ボリュームが作成される場合は、Trusted Storage Pool のすべてのサーバーには RDMA デバイスが必要です。ピアプローブは、RDMA デバイスに割り当てられた IP/ホスト名を使用して実行する必要があります。
    # gluster peer probe server2
    Probe successful
    
    # gluster peer probe server3
    Probe successful
    
    # gluster peer probe server4
    Probe successful
  2. 以下のコマンドを使用して、すべてのサーバーからピアのステータスを確認します。
    # gluster peer status
      Number of Peers: 3
    
      Hostname: server2
      Uuid: 5e987bda-16dd-43c2-835b-08b7d55e94e5
      State: Peer in Cluster (Connected)
    
      Hostname: server3
      Uuid: 1e0ca3aa-9ef7-4f66-8f15-cbc348f29ff7
      State: Peer in Cluster (Connected)
    
      Hostname: server4
      Uuid: 3e0caba-9df7-4f66-8e5d-cbc348f29ff7
      State: Peer in Cluster (Connected)
重要
既存の信頼済みストレージプールにジオレプリケーションセッションがある場合、次に新しいサーバーを信頼できるストレージプールに追加したら、「新規に追加されたブリック、ノード、またはボリュームでの Geo レプリケーションの起動」 に記載の手順を実行します。
注記
以下のコマンドを使用して、時刻がすべての Gluster ノードで同期されていることを確認します。
# for peer in `gluster peer status | grep Hostname | awk -F':' '{print $2}' | awk '{print $1}'`; do clockdiff $peer; done

4.2. 信頼できるストレージプールからのサーバーの削除

警告
信頼されているストレージプールからピアをデタッチする前に、クライアントがノードを使用しないことを確認してください。backup-volfile-servers オプションを使用してバックアップサーバーがマウント時に設定されていない場合は、信頼できるストレージプールの別のサーバーの IP アドレスまたは FQDN を使用してクライアントにボリュームを再マウントし、不整合を回避します。
Gluster ピアデタッチ サーバー を実行して、ストレージプールからサーバーを削除します。

信頼できるストレージプールからの 1 台のサーバーの削除

信頼できるストレージプールからサーバーを 1 台削除し、ストレージプールのピアステータスを確認します。

前提条件

  • ストレージプールから削除される場合は、glusterd サービスがサーバーで実行している必要があります。サービスの起動および停止の手順については、22章glusterd サービスの起動と停止 を参照してください。
  • ターゲットサーバーのホスト名は DNS で解決できる必要があります。
  1. Gluster ピアデタッチ [server] を実行して、信頼できるストレージプールからサーバーを削除します。
    # gluster peer detach (server)
    All clients mounted through the peer which is getting detached needs to be remounted, using one of the other active peers in the trusted storage pool, this ensures that the client gets notification on any changes done on the gluster configuration and if the same has been done do you want to proceed? (y/n) y
    peer detach: success
  2. 以下のコマンドを使用して、すべてのサーバーからピアのステータスを確認します。
    # gluster peer status
    Number of Peers: 2
    
    Hostname: server2
    Uuid: 5e987bda-16dd-43c2-835b-08b7d55e94e5
    State: Peer in Cluster (Connected)
    
    Hostname: server3
    Uuid: 1e0ca3aa-9ef7-4f66-8f15-cbc348f29ff7
    

第5章 ストレージボリュームの設定

Red Hat Gluster Storage ボリュームは、ブリックの論理コレクションです。各ブリックは、信頼できるストレージプール内のサーバーのエクスポートディレクトリーです。Red Hat Gluster Storage Server の管理操作のほとんどは、ボリュームに対して実行されます。パフォーマンスを向上させるために Red Hat Gluster Storage を設定する方法は、を参照してください。 19章パフォーマンスチューニング
警告
Red Hat は、ブリックへのデータを直接書き込みすることをサポートしていません。ネイティブクライアントまたは NFS または SMB マウントを介してのみデータの読み取りおよび書き込みを行います。
注記
Red Hat Gluster Storage は IP over Infiniband (IPoIB) をサポートします。この機能をサポートするために、すべての Red Hat Gluster Storage サーバーおよびクライアントに Infiniband パッケージをインストールします。yum groupinstall "Infiniband Support" を実行して Infiniband パッケージをインストールします。

ボリュームタイプ

Distributed (分散)
ファイルをボリューム内のブリックに分散します。
スケーリングと冗長性の要件が重要ではないか、または他のハードウェアやソフトウェア層により提供されるこのボリュームタイプを使用します。
このボリューム種別に関する情報は、「分散ボリュームの作成」 を参照してください。
Replicated (レプリケート)
ボリューム内のブリック間でファイルを複製します。
高い可用性と信頼性が重要である環境では、このボリュームタイプを使用します。
このボリューム種別に関する情報は、「複製ボリュームの作成」 を参照してください。
Distributed Replicated
ファイルをボリューム内の複製されたブリックに分散します。
高い信頼性と柔軟性が重要である環境では、このボリュームタイプを使用します。このボリュームタイプは、多くの環境で読み取りパフォーマンスが向上します。
このボリューム種別に関する情報は、「分散複製ボリュームの作成」 を参照してください。
Arbitrated Replicated
レプリカセットの 2 つのブリックでファイルを複製し、メタデータのみを 3 番目のブリックに複製します。
一貫性が重要な環境でこのボリュームタイプを使用しますが、ベースとなるストレージ領域は非常に貴重です。
このボリューム種別に関する情報は、「Arbitrated Replicated ボリュームの作成」 を参照してください。
Dispersed
ボリュームのブリック全体でファイルのデータを分散します。
無駄にする領域を最小元に抑える、信頼性の設定可能なレベルが必要なこのボリュームタイプを使用します。
このボリューム種別に関する情報は、「分散ボリュームの作成」 を参照してください。
Distributed Dispersed
分散するサブボリューム全体でファイルのデータを分散します。
無駄にする領域を最小元に抑える、信頼性の設定可能なレベルが必要なこのボリュームタイプを使用します。
このボリューム種別に関する情報は、「Distributed Dispersed ボリュームの作成」 を参照してください。

5.1. gdeploy を使用した Gluster Storage ボリュームの設定

gdeploy ツールは、ブリックの作成、フォーマット、マウントのプロセスを自動化します。gdeploy では、『Section 5.4 Formatting and Mounting Bricks』 と 『Section 5.10 Creating Distributed Dispersed Volumes』 にリストされている手動の手順が自動化されています。
新しい信頼できるストレージプールを設定する場合は、複数のコマンドを手動で実行するとエラーになる可能性があるため、gdeploy が信頼されるストレージプールセットを使用することが推奨されます。
gdeploy を使用してブリックの作成を自動化する利点は次のとおりです。
  • 複数のマシンへのバックエンドの設定は、ラップトップ/デスクトップから実行できます。これにより、信頼されているストレージプール内のノード数が増えると、時間が短縮され、スケールアップできるようになります。
  • 設定するドライブを選択する柔軟性 (sd、vd、...)
  • 論理ボリューム (LV) およびボリュームグループ (VG) の命名に柔軟性がある。

5.1.1. 使い始める

前提条件

  1. 以下のコマンドを実行して、信頼できるストレージプールの一部であるノードのパスフレーズなしの SSH 鍵を生成します。
    # ssh-keygen -t rsa -N ''
  2. 以下のコマンドを実行して、gdeploy コントローラーとサーバー間のキーベースの SSH 認証アクセスを設定します。
    # ssh-copy-id -i root@server
    注記
    Red Hat Gluster Storage ノードを外部ノードではなくデプロイメントノードとして使用する場合は、インストールが実行される Red Hat Gluster Storage ノードにキーベースの SSH 認証を設定する必要があります。
  3. 以下のコマンドを実行して、Ansible のインストールに必要なリポジトリーを有効にします。
    Red Hat Enterprise Linux 8 の場合
    # subscription-manager repos --enable=ansible-2-for-rhel-8-x86_64-rpms
    Red Hat Enterprise Linux 7 の場合
    # subscription-manager repos --enable=rhel-7-server-ansible-2-rpms
  4. 以下のコマンドを実行して、ansible をインストールします。
    # yum install ansible
  5. 以下のことを確認する必要があります。
    • デバイスは raw で未使用である必要があります
    • デフォルトのシステムロケールは en_US に設定する必要があります
      システムロケールの詳細は、『『Red Hat Enterprise Linux 7 システム管理者のガイド』』の「『システムロケールの設定』」を参照してください。
    • 複数のデバイスの場合は、g deploy 設定ファイルで複数のボリュームグループ、シンプール、および thinvol を使用します。
詳細は、『『Red Hat Gluster Storage 3.5 Installation Guide』』の「Installing Ansible to Support Gdeploy」を参照してください。
gdeploy を使用して Red Hat Gluster Storage をデプロイする方法は 2 つあります。
  • 信頼できるストレージプールでのノードの使用
  • 信頼できるストレージプールの外部にあるマシンの使用

クラスターでのノードの使用

gdeploy パッケージは、Red Hat Gluster Storage の初期インストールの一部としてバンドルされます。

信頼できるストレージプールの外部にあるマシンの使用

Red Hat Gluster Storage が必要なチャンネルにサブスクライブされていることを確認する必要があります。詳細は、『『Red Hat Gluster Storage 3.5 Installation Guide』』の「『Subscribing to the Red Hat Gluster Storage Server Channels』」を参照してください。

以下のコマンドを実行して gdeploy をインストールします。
# yum install gdeploy

5.1.2. 信頼できるストレージプールの設定

信頼できるストレージプールの作成は不適切なタスクで、信頼できるストレージプールのノードほど複雑になります。gdeploy では、信頼できるストレージプールの設定には、設定ファイルのみを使用できます。gdeploy をインストールすると、設定ファイルのサンプルが以下に作成されます。
/usr/share/doc/gdeploy/examples/gluster.conf.sample
注記
信頼できるストレージプールは、バックエンドのセットアップ、ボリュームの作成、または 1 つの設定として合計するなど、各タスクを実行することによって作成できます。
たとえば、3 x 3 で複製されたボリュームの基本的な信頼できるストレージプールの場合、設定ファイルの設定詳細は以下のようになります。
3x3-volume-create.conf:
#
# Usage:
#       gdeploy -c 3x3-volume-create.conf
#
# This does backend setup first and then create the volume using the
# setup bricks.
#
#

[hosts]
10.70.46.13
10.70.46.17
10.70.46.21


# Common backend setup for 2 of the hosts.
[backend-setup]
devices=sdb,sdc,sdd
vgs=vg1,vg2,vg3
pools=pool1,pool2,pool3
lvs=lv1,lv2,lv3
mountpoints=/rhgs/brick1,/rhgs/brick2,/rhgs/brick3
brick_dirs=/rhgs/brick1/b1,/rhgs/brick2/b2,/rhgs/brick3/b3

# If backend-setup is different for each host
# [backend-setup:10.70.46.13]
# devices=sdb
# brick_dirs=/rhgs/brick1
#
# [backend-setup:10.70.46.17]
# devices=sda,sdb,sdc
# brick_dirs=/rhgs/brick{1,2,3}
#

[volume]
action=create
volname=sample_volname
replica=yes
replica_count=3
force=yes


[clients]
action=mount
volname=sample_volname
hosts=10.70.46.15
fstype=glusterfs
client_mount_points=/mnt/gluster
この設定では、指定した IP アドレスおよびバックエンドデバイスを /dev/sdb、/dev/sdc、/ dev/ sdd として、example _volname のボリューム名を持つ 3 つのレプリカで信頼されるストレージプールが作成されます。
設定可能な値の詳細は、を参照してください。 「設定ファイル」
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf
注記
/usr/share/doc/gdeploy/examples/gluster.conf.sample で利用可能なテンプレートファイルを参照して、新しい設定ファイルを作成することができます。新規設定ファイルを呼び出すには、g deploy -c /path_to_file/config.txt コマンドを実行します。
バックエンド のみ を設定する場合は、を参照してください。 「バックエンドの設定 」
ボリューム のみ を作成する場合は、を参照してください。 「ボリュームの作成」
クライアントのマウント だけ を表示するには、次のコマンドを実行します。 「クライアントのマウント」

5.1.3. バックエンドの設定

Gluster Storage ボリュームを設定するには、LVM thin-p をストレージディスクに設定する必要があります。信頼できるストレージプール内のマシン数が大きい場合、関連するコマンド数が大きい場合、注意してもエラーが発生するため、これらのタスクには時間がかかります。gdeploy では、バックエンドの設定には設定ファイルのみを使用できます。バックエンドは、新たに信頼されているストレージプールを設定する際に設定されます。これには、ボリュームを作成する前にブリックを設定する必要があります。gdeploy をインストールすると、設定ファイルのサンプルが以下に作成されます。
/usr/share/doc/gdeploy/examples/gluster.conf.sample
バックエンドを設定する方法は 2 つあります。
  • [backend-setup] モジュールの使用
  • 物理ボリューム (PV)、ボリュームグループ (VG)、および論理ボリューム (LV) の個別作成
注記
Red Hat Enterprise Linux 6 の場合は、gdeploy を使用してバックエンドブリックを設定する前に xfsprogs パッケージをインストールする必要があります。
重要
Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。『 インストールガイド』の「 『バージョンの詳細』 表」 『および「Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 」を参照してください。

5.1.3.1. [backend-setup] モジュールの使用

バックエンドの設定は、特定のマシンまたはすべてのマシンで実行できます。backend-setup モジュールは内部的に PV、VG、および LV を作成し、デバイスをマウントします。thin-p 論理ボリュームは、Red Hat によるパフォーマンス推奨事項に従って作成されます。
バックエンドは、以下のような要件に基づいて設定することができます。
  • 汎用
  • 特定

汎用

ディスク名がマシン全体で統一されている場合は、以下のようにバックエンドの設定を作成することができます。'hosts' セクション内のすべてのホストに対して、バックエンドが設定されます。

設定可能な値の詳細は、を参照してください。 「設定ファイル」
設定ファイルの例: Backend-setup-generic.conf
#
# Usage:
#       gdeploy -c backend-setup-generic.conf
#
# This configuration creates backend for GlusterFS clusters
#

[hosts]
10.70.46.130
10.70.46.32
10.70.46.110
10.70.46.77

# Backend setup for all the nodes in the `hosts' section. This will create
# PV, VG, and LV with gdeploy generated names.
[backend-setup]
devices=vdb

特定

ディスク名がクラスター内のマシンごとに異なる場合、バックエンドのセットアップは特定のディスク名を持つ特定のマシンに対して作成できます。gdeploy は、1 つの設定ファイルでホスト固有の設定を非常に柔軟に実行することができます。

設定可能な値の詳細は、を参照してください。 「設定ファイル」
設定ファイルの例: backend-setup-hostwise.conf
#
# Usage:
#       gdeploy -c backend-setup-hostwise.conf
#
# This configuration creates backend for GlusterFS clusters
#

[hosts]
10.70.46.130
10.70.46.32
10.70.46.110
10.70.46.77

# Backend setup for 10.70.46.77 with default gdeploy generated names for
# Volume Groups and Logical Volumes. Volume names will be GLUSTER_vg1,
# GLUSTER_vg2...
[backend-setup:10.70.46.77]
devices=vda,vdb

# Backend setup for remaining 3 hosts in the `hosts' section with custom names
# for Volumes Groups and Logical Volumes.
[backend-setup:10.70.46.{130,32,110}]
devices=vdb,vdc,vdd
vgs=vg1,vg2,vg3
pools=pool1,pool2,pool3
lvs=lv1,lv2,lv3
mountpoints=/rhgs/brick1,/rhgs/brick2,/rhgs/brick3
brick_dirs=/rhgs/brick1/b1,/rhgs/brick2/b2,/rhgs/brick3/b3

5.1.3.2. PV、VG、および LV のセットアップによるバックエンドの作成

バックエンドの設定をより細かくする必要がある場合は、pv、vg、および lv を個別に作成できます。LV モジュールは、VG 上に複数の LV を作成する柔軟性を提供します。たとえば、`backend-setup’モジュールは、デフォルトでシンプールをセットアップし、デフォルトのパフォーマンス推奨事項を適用します。ただし、複数の LV、シンプールとシックプールの組み合わせを必要とするような異なるユースケースがある場合は、`backend-setup’ は役に立ちません。これは、PV、VG、および LV モジュールを使用して実行できます。
設定可能な値の詳細は、を参照してください。 「設定ファイル」
以下の例は、1 つのボリュームグループに論理ボリュームを 4 つ作成する方法を示しています。この例では、シンとシックプール LV の作成の組み合わせを示しています。
[hosts]
10.70.46.130
10.70.46.32

[pv]
action=create
devices=vdb

[vg1]
action=create
vgname=RHS_vg1
pvname=vdb

[lv1]
action=create
vgname=RHS_vg1
lvname=engine_lv
lvtype=thick
size=10GB
mount=/rhgs/brick1

[lv2]
action=create
vgname=RHS_vg1
poolname=lvthinpool
lvtype=thinpool
poolmetadatasize=200MB
chunksize=1024k
size=30GB

[lv3]
action=create
lvname=lv_vmaddldisks
poolname=lvthinpool
vgname=RHS_vg1
lvtype=thinlv
mount=/rhgs/brick2
virtualsize=9GB

[lv4]
action=create
lvname=lv_vmrootdisks
poolname=lvthinpool
vgname=RHS_vg1
size=19GB
lvtype=thinlv
mount=/rhgs/brick3
virtualsize=19GB
既存の VG を拡張する例:
#
# Extends a given given VG. pvname and vgname is mandatory, in this example the
# vg `RHS_vg1' is extended by adding pv, vdd. If the pv is not alreay present, it
# is created by gdeploy.
#
[hosts]
10.70.46.130
10.70.46.32

[vg2]
action=extend
vgname=RHS_vg1
pvname=vdd

5.1.4. ボリュームの作成

ボリュームのセットアップには、ホスト名/IP とブリックの順序を慎重に選択し、エラーが送出される可能性があります。gdeploy は、このタスクを簡素化するのに役立ちます。gdeploy をインストールすると、設定ファイルのサンプルが以下に作成されます。
/usr/share/doc/gdeploy/examples/gluster.conf.sample
たとえば、4 x 3 の基本的な信頼できるストレージプールでは、ボリュームが複製されたボリュームの場合、設定ファイルの設定詳細は以下のようになります。
[hosts]
10.0.0.1
10.0.0.2
10.0.0.3
10.0.0.4

[volume]
action=create
volname=glustervol
transport=tcp,rdma
replica=yes
replica_count=3
brick_dirs=/glus/brick1/b1,/glus/brick1/b1,/glus/brick1/b1
force=yes
設定可能な値の詳細は、を参照してください。 「設定ファイル」
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf

複数のボリュームの作成

注記
gdeploy 2.0 から複数ボリュームを作成することしかサポートされません。この設定を試みる前に、gdeploy バージョンを確認してください。
1 つの設定で複数のボリュームを作成する場合は、[volume] モジュールに番号を指定する必要があります。たとえば、ボリュームが 2 つある場合、[volume1]、[volume2] の番号が付けられます。
vol-create.conf
[hosts]
10.70.46.130
10.70.46.32
10.70.46.16

[backend-setup]
devices=vdb,vdc,vdd,vde
mountpoints=/mnt/data{1-6}
brick_dirs=/mnt/data1/1,/mnt/data2/2,/mnt/data3/3,/mnt/data4/4,/mnt/data5/5,/mnt/data6/6

[volume1]
action=create
volname=vol-one
transport=tcp
replica=yes
replica_count=3
brick_dirs=/mnt/data1/1,/mnt/data2/2,/mnt/data5/5

[volume2]
action=create
volname=vol-two
transport=tcp
replica=yes
replica_count=3
brick_dirs=/mnt/data3/3,/mnt/data4/4,/mnt/data6/6
gdeploy 2.0 を使用すると、複数のボリュームオプションを設定してボリュームを作成できます。値と一致するキーの数。
[hosts]
10.70.46.130
10.70.46.32
10.70.46.16

[backend-setup]
devices=vdb,vdc
mountpoints=/mnt/data{1-6}

[volume1]
action=create
volname=vol-one
transport=tcp
replica=yes
replica_count=3
key=group,storage.owner-uid,storage.owner-gid,features.shard,features.shard-block-size,performance.low-prio-threads,cluster.data-self-heal-algorithm
value=virt,36,36,on,512MB,32,full
brick_dirs=/mnt/data1/1,/mnt/data3/3,/mnt/data5/5

[volume2]
action=create
volname=vol-two
transport=tcp
replica=yes
key=group,storage.owner-uid,storage.owner-gid,features.shard,features.shard-block-size,performance.low-prio-threads,cluster.data-self-heal-algorithm
value=virt,36,36,on,512MB,32,full
replica_count=3
brick_dirs=/mnt/data2/2,/mnt/data4/4,/mnt/data6/6
上記の設定では、複数のボリュームオプションを設定した 2 つのボリュームが作成されます。

5.1.5. クライアントのマウント

クライアントをマウントする場合は、マウントする必要のあるすべてのクライアントにログインする代わりに、gdeploy を使用してクライアントをリモートでマウントできます。gdeploy をインストールすると、設定ファイルのサンプルが以下に作成されます。
/usr/share/doc/gdeploy/examples/gluster.conf.sample
以下は、クライアントをマウントするための設定ファイルに対する変更例です。
[clients]
action=mount
hosts=10.70.46.159
fstype=glusterfs
client_mount_points=/mnt/gluster
volname=10.0.0.1:glustervol
注記
ファイルシステムの種類(fstype)が NFS の場合は、nfs-version と記載してください。デフォルトのバージョンは 3 です。
設定可能な値の詳細は、を参照してください。 「設定ファイル」
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf

5.1.6. ボリュームの設定

ボリュームは設定ファイルを使用して設定できます。ボリュームは、信頼できるストレージプールにログインせずに設定ファイルを使用してリモートで設定できます。設定ファイル内のセクションとオプションの詳細は、を参照してください。 「設定ファイル」

5.1.6.1. ブログの追加および削除

設定ファイルを変更して、ブリックを追加または削除できます。

ブログの追加

設定ファイルの [volume] セクションを変更して、ブリックを追加します。以下に例を示します。

[volume]
action=add-brick
volname=10.0.0.1:glustervol
bricks=10.0.0.1:/rhgs/new_brick
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf

ブリックの削除

設定ファイルの [volume] セクションを変更して、ブリックを削除します。以下に例を示します。

[volume]
action=remove-brick
volname=10.0.0.1:glustervol
bricks=10.0.0.2:/rhgs/brick
state=commit
state についての他のオプションは stop、start、および force です。
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf
設定可能な値の詳細は、を参照してください。 「設定ファイル」

5.1.6.2. ボリュームのリバランス

設定ファイルの [volume] セクションを変更して、ボリュームをリバランスします。以下に例を示します。
[volume]
action=rebalance
volname=10.70.46.13:glustervol
state=start
state 用の他のオプションは stop および fix-layout です。
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf
設定可能な値の詳細は、を参照してください。 「設定ファイル」

5.1.6.3. ボリュームの起動、停止、または削除

設定ファイルは、ボリュームの起動、停止、または削除が可能です。

ボリュームの起動

設定ファイルの [volume] セクションを変更してボリュームを起動します。以下に例を示します。

[volume]
action=start
volname=10.0.0.1:glustervol
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf

ボリュームの停止

設定ファイルの [volume] セクションを変更してボリュームを起動します。以下に例を示します。

[volume]
action=stop
volname=10.0.0.1:glustervol
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf

ボリュームの削除

設定ファイルの [volume] セクションを変更してボリュームを起動します。以下に例を示します。

[volume]
action=delete
volname=10.70.46.13:glustervol
設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf
設定可能な値の詳細は、を参照してください。 「設定ファイル」

5.1.7. 設定ファイル

設定ファイルには、gdeploy の設定変更に使用できるさまざまなオプションが含まれます。現在、以下のオプションがサポートされています。
  • [hosts]
  • [devices]
  • [disktype]
  • [diskcount]
  • [stripesize]
  • [vgs]
  • [pools]
  • [lvs]
  • [mountpoints]
  • [peer]
  • [clients]
  • [volume]
  • [backend-setup]
  • [pv]
  • [vg]
  • [lv]
  • [RH-subscription]
  • [yum]
  • [shell]
  • [update-file]
  • [service]
  • [script]
  • [firewalld]
  • [geo-replication]
オプションは、以下のリストで簡単に説明されています。
  • hosts

    これは、信頼できるストレージプール内のマシンの IP アドレスまたはホスト名が含まれる必須のセクションです。ホスト名または IP アドレスは別々の行に記載する必要があります。

    以下に例を示します。
    [hosts]
    10.0.0.1
    10.0.0.2
  • devices

    これは汎用セクションであり、[hosts] セクションに一覧表示されている全ホストに適用できます。ただし、[hostname] や [IP-address] などのホストのセクションが存在する場合は、[devices] などの一般的なセクションのデータは無視されます。ホスト固有のデータが優先されます。これは任意のセクションです。

    以下に例を示します。
    [devices]
    /dev/sda
    /dev/sdb
    注記
    バックエンドの設定時に、デバイスをこのセクションに一覧表示するか、ホスト固有のセクションに記載する必要があります。
  • disktype

    本セクションでは、バックエンドの設定中に使用されるディスク設定を指定します。gdeploy は、RAID 10、RAID 6、RAID 5、および JBOD 設定をサポートします。これは任意のセクションであり、このフィールドが空のままであれば、JBOD がデフォルト設定として取得されます。このフィールドに有効な値は、raid10raid6raid5jbod です。

    以下に例を示します。
    [disktype]
    raid6
  • diskcount

    本セクションでは、セットアップ内のデータディスクの数を指定します。RAID ディスクタイプが [disktype] の下に指定される場合、これは必須フィールドです。[disktype] が JBOD の場合、[diskcount] の値は無視されます。このパラメーターはホスト固有のものです。

    以下に例を示します。
    [diskcount]
    10
  • stripesize

    本セクションでは、stripe_unit サイズを KB 単位で指定します。

    ケース 1: [disktype] が JBOD で、指定の値は無視されます。
    ケース 2: [disktype] が RAID 5 または RAID 6 として指定されている場合、これは必須フィールドです。
    [disktype] RAID 10 の場合、デフォルト値は 256KB になります。Red Hat では、この値を変更することは推奨していません。その他の値を指定すると、以下の警告が表示されます。
    "Warning: We recommend a stripe unit size of 256KB for RAID 10"
    注記
    K、KB、M などのサフィックスを追加しないでください。このパラメーターはホストごとに固有で、hosts セクションに追加できます。
    以下に例を示します。
    [stripesize]
    128
  • vgs

    このセクションは、gdeploy 2.0 で非推奨となりました。gdeploy 2.0 の詳細は [backend-setup] を参照してください。本セクションでは、[devices] に一覧表示されているデバイスのボリュームグループ名を指定します。[vgs] セクションのボリュームグループ数は、[devices] 内のボリュームグループの数に一致する必要があります。ボリュームグループ名がない場合には、ボリュームグループはデフォルトで GLUSTER_vg{1, 2, 3, ...} という名前になります。

    以下に例を示します。
    [vgs]
    CUSTOM_vg1
    CUSTOM_vg2
  • プール

    このセクションは、gdeploy 2.0 で非推奨となりました。gdeploy 2.0 の詳細は [backend-setup] を参照してください。本セクションでは、[vgs] セクションに指定したボリュームグループのプール名を指定します。[pools] セクションに一覧表示されるプールの数は、[vgs] セクションのボリュームグループの数と一致する必要があります。プール名がない場合、プールの名前は GLUSTER_pool{1, 2, 3, ...} になります。

    以下に例を示します。
    [pools]
    CUSTOM_pool1
    CUSTOM_pool2
  • lvs

    このセクションは、gdeploy 2.0 で非推奨となりました。gdeploy 2.0 の詳細は [backend-setup] を参照してください。本セクションでは、[vgs] で指定したボリュームグループの論理ボリューム名を説明します。[lvs] セクションに一覧表示される論理ボリュームの数は、[vgs] に記載されているボリュームグループの数と一致する必要があります。論理ボリューム名が見つからない場合は、GLUSTER_lv{1, 2, 3, ...} という名前になります。

    以下に例を示します。
    [lvs]
    CUSTOM_lv1
    CUSTOM_lv2
  • mountpoints

    このセクションは、gdeploy 2.0 で非推奨となりました。gdeploy 2.0 の詳細は [backend-setup] を参照してください。本セクションでは、論理ボリュームのブリックマウントポイントを指定します。マウントポイントの数は、[lvs] で指定した論理ボリュームの数と一致している必要があります。マウントポイントを指定しないと、マウントポイントは /gluster/brick{1, 2, 3…} と名前になります。

    以下に例を示します。
    [mountpoints]
    /rhgs/brick1
    /rhgs/brick2
  • peer

    本セクションでは、Trusted Storage Pool Management (TSP) の設定を指定します。本セクションは、[hosts] セクションで指定されているすべてのホストをプローブして相互にプローブして、信頼できるストレージプールの作成、または信頼済みストレージプールからすべてのホストの割り当てを解除するのに役立ちます。本セクションの唯一のオプションは 'action' です。それらの値はプローブまたはデタッチのいずれかになります。

    以下に例を示します。
    [peer]
    action=probe
  • clients

    本セクションでは、作成した gluster ストレージボリュームをマウントするためにクライアントホストと client_mount_points を指定します。'action' オプションは、フレームワークに対して指定して、実行すべきアクションを決定します。オプションは 'mount' と 'unmount' です。Client hosts フィールドは必須です。マウントポイントを指定しないと、すべてのホストに対して /mnt/gluster としてデフォルトが使用されます。

    fstype オプションは、gluster ボリュームのマウント方法を指定します。デフォルトは glusterfs (FUSE mount) です。ボリュームは NFS としてマウントすることもできます。各クライアントには、異なるタイプのボリュームマウントを設定できます。これはコンマ区切りで指定する必要があります。以下のフィールドが含まれます。
    * action
    * hosts
    * fstype
    * client_mount_points
    以下に例を示します。
    [clients]
    action=mount
    hosts=10.0.0.10
    fstype=nfs
    options=vers=3
    client_mount_points=/mnt/rhs
  • ボリューム

    本セクションでは、ボリュームの設定オプションを指定します。このセクションでは、以下のフィールドが含まれます。

    * action
    * volname
    * transport
    * replica
    * replica_count
    * disperse
    * disperse_count
    * redundancy_count
    * force
    • 動作

      このオプションは、ボリューム内で実行する必要のあるアクションを指定します。選択肢は、[create, delete, add-brick, remove-brick] のようになります。

      create: これはボリュームを作成する場合に使用します。
      delete: delete オプションを使用すると、'volname' 以外のオプションはすべて無視されます。
      add-brick または remove-brick: add-brick または remove-brick が選択された場合は、ブリック名のコンマ区切りリスト (形式: <hostname>:<brick path>) で、追加のオプションブリックを指定します。remove-brick の場合は、state オプションも、ブックの削除後にボリュームの状態を指定する必要もあります。
    • volname

      このオプションは、ボリューム名を指定します。デフォルト名は glustervol です。

      注記
      • ボリュームの操作時、'hosts' セクションは省略できます。ただし、volname は <hostname>:<volname>⁠ の形式になります。hostname はクラスター内のノードのいずれかのホスト名 / IP です。
      • ボリュームの作成/使用/設定のみがサポートされます。
    • transport

      このオプションはトランスポートタイプを指定します。デフォルトは tcp です。オプションは、tcp または rdma (非推奨) または tcp,rdma です。

    • replica

      このオプションは、ボリュームのタイプが replica であるべきかどうかを指定します。オプションは yes と no で、デフォルトは no です。'replica' が yes の場合は、'replica_count' が提供されます。

    • disperse

      このオプションは、ボリュームのタイプが分散すべきかどうかを指定します。オプションは yes と no です。デフォルトは no です。

    • disperse_count

      このフィールドは、’disperse' が yes の場合でも任意です。指定しないと、コマンドラインで指定されたブリックの数は disperse_count の値として取得されます。

    • redundancy_count

      この値が指定されておらず、'disperse' が yes の場合、デフォルト値は計算され、最適な設定が生成されます。

    • force

      これはオプションのフィールドであり、ボリュームの作成時にボリューム作成を強制するために使用することができます。

    以下に例を示します。
    [volname]
    action=create
    volname=glustervol
    transport=tcp,rdma
    replica=yes
    replica_count=3
    force=yes
  • backend-setup

    gdeploy 2.0 で利用できます。本セクションでは、GlusterFS ボリュームで使用するバックエンドを設定します。複数の backend-setup を実行するには、[backend-setup1], [backend-setup2], ... のようにセクションに番号を付けることで、これらを行うことができます。

    backend-setup セクションは、以下の変数をサポートします。
    • devices: これは gdeploy 1.x の [pvs] セクションを置き換えます。devices 変数は、バックエンドの設定に使用する raw ディスクを一覧表示します。以下に例を示します。
      [backend-setup]
      devices=sda,sdb,sdc
      これは必須フィールドです。
    • dalign:
      Logical Volume Manager は、物理ボリュームの一部を使用してメタデータを格納できます。残りは、データ部分として使用されます。物理ボリュームの作成時に、dalign オプションを使用して、Logical Volume Manager (LVM) 層で I/O を調整します。以下に例を示します。
      [backend-setup]
      devices=sdb,sdc,sdd,sde
      dalign=256k
      JBOD の場合は、256K の調整の値を使用します。ハードウェア RAID の場合は、RAID ストライプユニットのサイズをデータディスクの数で乗算して、調整値を取得する必要があります。RAID 6 設定で 12 個のディスクを使用すると、データディスクの数は 10 になります。その一方で、RAID 10 設定に 12 個ディスクを使用する場合は、データディスクの数は 6 になります。
      以下の例は、ストライプユニットサイズが 128 KiB の RAID 6 設定の 12 個のディスクに適しています。
      [backend-setup]
      devices=sdb,sdc,sdd,sde
      dalign=1280k
      以下の例は、ストライプユニットサイズが 256 KiB の RAID 10 設定の 12 個のディスクに適しています。
      [backend-setup]
      devices=sdb,sdc,sdd,sde
      dalign=1536k
      dalign オプションの以前に設定した物理ボリューム設定を表示するには、pvs -o +pe_start device コマンドを実行します。以下は例になります。
      # pvs -o +pe_start /dev/sdb
      PV         VG   Fmt  Attr PSize PFree 1st PE
      /dev/sdb        lvm2 a--  9.09t 9.09t   1.25m
      PV セクションに dalign オプションを設定することもできます。
    • vgs: これは任意の変数です。この変数は、gdeploy 1.x の [vgs] セクションを置き換えます。vgs 変数には、ボリュームグループの作成時に使用される名前の一覧が表示されます。VG 名の数は、デバイス数と一致するか、空欄にする必要があります。gdeploy は、ボリュームグループの名前を生成します。以下に例を示します。
      [backend-setup]
      devices=sda,sdb,sdc
      vgs=custom_vg1,custom_vg2,custom_vg3
      custom_vg{1..3} などの vg には、パターンを 3 つ作成できます。
      [backend-setup]
      devices=sda,sdb,sdc
      vgs=custom_vg{1..3}
    • pool: これは任意の変数です。変数は、gdeploy 1.x の [pools] セクションに代わるものです。プールは、ボリュームのシンプール名を一覧表示します。
      [backend-setup]
      devices=sda,sdb,sdc
      vgs=custom_vg1,custom_vg2,custom_vg3
      pools=custom_pool1,custom_pool2,custom_pool3
      vg と同様に、シンプール名用にパターンを指定できます。例: custom_pool{1..3}
    • lvs: これは任意の変数です。この変数は、gdeploy 1.x の [lvs] セクションに代わるものです。lvs は、ボリュームの論理ボリューム名を一覧表示します。
      [backend-setup]
      devices=sda,sdb,sdc
      vgs=custom_vg1,custom_vg2,custom_vg3
      pools=custom_pool1,custom_pool2,custom_pool3
      lvs=custom_lv1,custom_lv2,custom_lv3
      LV のパターンは、vg と同様に利用できます。例: custom_lv{1..3}
    • mountpoints: この変数は、gdeploy 1.x の [mountpoints] セクションを非推奨にします。マウントポイントは、論理ボリュームをマウントする必要のあるマウントポイントを一覧表示します。マウントポイントの数は、論理ボリュームの数と同じでなければなりません。以下に例を示します。
      [backend-setup]
      devices=sda,sdb,sdc
      vgs=custom_vg1,custom_vg2,custom_vg3
      pools=custom_pool1,custom_pool2,custom_pool3
      lvs=custom_lv1,custom_lv2,custom_lv3
      mountpoints=/gluster/data1,/gluster/data2,/gluster/data3
    • SSD: キャッシュを追加する必要がある場合には、この変数が設定されます。たとえば、キャッシュ用に ssd を使用したバックアップ設定は以下のようになります。
      [backend-setup]
      ssd=sdc
      vgs=RHS_vg1
      datalv=lv_data
      cachedatalv=lv_cachedata:1G
      cachemetalv=lv_cachemeta:230G
      注記
      SSD の追加中にデータ LV の名前を指定する必要があります。datalv がすでに作成されていることを確認します。それ以外の場合は、以前の `backend-setup’ セクションのいずれかにこれを作成するようにしてください。
  • PV

    gdeploy 2.0 で利用できます。ユーザーがバックエンドのセットアップに対する制御を強化し、backend-setup セクションを使用しない場合は、pv、vg、および lv モジュールが使用されます。pv モジュールは、以下の変数をサポートします。

    • action: 必須'create' と 'resize' の 2 つの値をサポートします。
      例: 物理ボリュームの作成
      [pv]
      action=create
      devices=vdb,vdc,vdd
      例: 特定のホストでの物理ボリュームの作成
      [pv:10.0.5.2]
      action=create
      devices=vdb,vdc,vdd
    • devices: 必須pv の作成に使用するデバイスの一覧。
    • expand: action=resize の場合に使用します。
      例: すでに作成した pv の拡張
      [pv]
      action=resize
      devices=vdb
      expand=yes
    • shrink: action=resize の場合に使用します。
      例: すでに作成された pv の縮小
      [pv]
      action=resize
      devices=vdb
      shrink=100G
    • dalign:
      Logical Volume Manager は、物理ボリュームの一部を使用してメタデータを格納できます。残りは、データ部分として使用されます。物理ボリュームの作成時に、dalign オプションを使用して、Logical Volume Manager (LVM) 層で I/O を調整します。以下に例を示します。
      [pv]
      action=create
      devices=sdb,sdc,sdd,sde
      dalign=256k
      JBOD の場合は、256K の調整の値を使用します。ハードウェア RAID の場合は、RAID ストライプユニットのサイズをデータディスクの数で乗算して、調整値を取得する必要があります。RAID 6 設定で 12 個のディスクを使用すると、データディスクの数は 10 になります。その一方で、RAID 10 設定に 12 個ディスクを使用する場合は、データディスクの数は 6 になります。
      以下の例は、ストライプユニットサイズが 128 KiB の RAID 6 設定の 12 個のディスクに適しています。
      [pv]
      action=create
      devices=sdb,sdc,sdd,sde
      dalign=1280k
      以下の例は、ストライプユニットサイズが 256 KiB の RAID 10 設定の 12 個のディスクに適しています。
      [pv]
      action=create
      devices=sdb,sdc,sdd,sde
      dalign=1536k
      dalign オプションの以前に設定した物理ボリューム設定を表示するには、pvs -o +pe_start device コマンドを実行します。以下は例になります。
      # pvs -o +pe_start /dev/sdb
      PV         VG   Fmt  Attr PSize PFree 1st PE
      /dev/sdb        lvm2 a--  9.09t 9.09t   1.25m
      backend-setup セクションで dalign オプションを設定することもできます。
  • VG

    gdeploy 2.0 で利用できます。このモジュールは、ボリュームグループの作成および拡張に使用されます。vg モジュールは、以下の変数に対応します。

    • action - 作成または拡張のいずれかになります。
    • pvname - ボリュームの作成に使用する PV。複数の PV にはコンマ区切りの値を使用します。
    • vgname - vg の名前。名前が指定されない場合は、GLUSTER_vg がデフォルト名として使用されます。
    • 1 対 1 - yes に設定すると、pv と vg の間で 1 対 1 のマッピングが行われます。
    action を extend に設定すると、vg は指定した pv を組み込むように拡張されます。
    例 1: 2 つの PV を持つ images_vg という名前の vg を作成します。
    [vg]
    action=create
    vgname=images_vg
    pvname=sdb,sdc
    例 2: 2 つの PV を持つ rhgs_vg1 および rhgs_vg2 という名前の 2 つの vgs を作成します。
    [vg]
    action=create
    vgname=rhgs_vg
    pvname=sdb,sdc
    one-to-one=yes
    例 3: 指定したディスクを持つ既存の vg を拡張します。
    [vg]
    action=extend
    vgname=rhgs_images
    pvname=sdc
  • LV

    gdeploy 2.0 で利用できます。このモジュールは、論理ボリュームの作成、セットアップキャッシュ、変換に使用されます。lv モジュールは、以下の変数に対応します。

    action: アクション変数では、'create'、'setup-cache'、'convert'、および 'change' の 3 つの値を使用できます。アクションが ’create’ の場合は、以下のオプションがサポートされます。
    • lvname: 論理ボリュームの名前。これは任意のフィールドです。デフォルトは GLUSTER_lv です。
    • POOLNAME: thinpool ボリューム名。これは任意のフィールドです。デフォルトは GLUSTER_pool です。
    • lvtype: 作成する論理ボリュームのタイプ。許可される値は ’thin’ および ’thick’ です。これはオプションのフィールドで、デフォルトはシックです。
    • サイズ: 論理ボリュームのサイズデフォルトでは、vg で利用可能な領域をすべて取ります。
    • extent: エクステントサイズ、デフォルトは 100%FREE
    • force: lv create を強制し、質問は行いません。使用できる値は ’yes’、'no' です。これは任意のフィールドで、デフォルトは yes です。
    • vgname: 使用するボリュームグループの名前。
    • pvname: 使用する物理ボリュームの名前。
    • chunksize: スナップショット、キャッシュプール、およびシンプールに使用されるチャンクユニットのサイズ。デフォルトでは、これはキロバイト単位で指定されます。RAID 5 および 6 ボリュームの場合は、gdeploy は、ストライプサイズとディスク数を掛けてデフォルトのチャンクサイズを計算します。RAID 10 の場合、デフォルトのチャンクサイズは 256 KB です。詳細は、「ブリック設定」 を参照してください。
      警告
      Red Hat では、少なくともデフォルトのチャンクサイズを使用することを推奨しています。チャンクサイズが小さすぎて、ボリュームのメタデータの容量が不足すると、ボリュームはデータを作成できません。これには、メタデータプールのサイズを増やすか、メタデータ領域が不足しているボリュームからデータを移行するために必要なデータが含まれます。Red Hat は、論理ボリュームをモニタリングして、メタデータボリュームが完全に満杯になる前に、拡張またはストレージが作成されるようにすることを推奨します。
    • poolmetadatasize: プールのメタデータ論理ボリュームのサイズを設定します。可能な場合は、最大チャンクサイズ (16 GiB) を割り当てます。最大数未満に割り当てる場合は、プールサイズの 0.5% を割り当て、メタデータ領域が不足しないようにします。
      警告
      メタデータプールの容量が不足すると、データを作成できません。これには、メタデータプールのサイズを増やすか、メタデータ領域が不足しているボリュームからデータを移行するために必要なデータが含まれます。lvs -o+metadata_percent コマンドを使用してメタデータプールを監視し、領域が不足しないようにします。
    • Virtualsize: シンプロビジョニングされたデバイスまたは指定のサイズでスパースデバイスを作成します。
    • mkfs: 指定のタイプのファイルシステムを作成します。デフォルトは xfs を使用します。
    • mkfs-opts: mkfs のオプション。
    • mount: 論理ボリュームをマウントします。
    アクションが setup-cache の場合、以下のオプションがサポートされます。
    • SSD: ssd デバイスの名前。たとえば、キャッシュを設定する sda/vda/…。
    • vgname: ボリュームグループの名前。
    • pookname: プールの名前。
    • cache_meta_lv: dm-cache (カーネルドライバー) からの要件により、LVM はさらにキャッシュプール LV を 2 つのデバイス (キャッシュデータ LV およびキャッシュメタデータ LV) に分割します。ここで cache_meta_lv 名を指定します。
    • cache_meta_lvsize: キャッシュメタ LV のサイズ
    • cache_lv: キャッシュデータ lv の名前。
    • cache_lvsize: キャッシュデータのサイズ
    • force: 強制
    action が convert の場合は、以下のオプションがサポートされます。
    • lvtype: lv タイプ。使用できるオプションは thin および sibling です。
    • force: lvconvert を強制。デフォルトは yes です。
    • vgname: ボリュームグループの名前。
    • poolmetadata: キャッシュまたはシンプールメタデータ論理ボリュームを指定します。
    • cachemode: 許可される値 writeback、writethrough。デフォルトは writethrough です。
    • cachepool: 論理ボリュームをキャッシュ LV に変換する際に、この引数が必要です。cachepool の名前。
    • lvname: 論理ボリュームの名前。
    • chunksize: スナップショット、キャッシュプール、およびシンプールに使用されるチャンクユニットのサイズ。デフォルトでは、これはキロバイト単位で指定されます。RAID 5 および 6 ボリュームの場合は、gdeploy は、ストライプサイズとディスク数を掛けてデフォルトのチャンクサイズを計算します。RAID 10 の場合、デフォルトのチャンクサイズは 256 KB です。詳細は、「ブリック設定」 を参照してください。
      警告
      Red Hat では、少なくともデフォルトのチャンクサイズを使用することを推奨しています。チャンクサイズが小さすぎて、ボリュームのメタデータの容量が不足すると、ボリュームはデータを作成できません。Red Hat は、論理ボリュームをモニタリングして、メタデータボリュームが完全に満杯になる前に、拡張またはストレージが作成されるようにすることを推奨します。
    • poolmetadataspare: プールメタデータの予備の論理ボリュームの作成および保守をコントロールします。この論理ボリュームは、自動プール復旧に使用されます。
    • thinpool: 論理ボリュームをシンプールのデータボリュームに指定または変換します。ボリュームの名前またはパスを指定する必要があります。
    アクションが変更されると、以下のオプションがサポートされます。
    • lvname: 論理ボリュームの名前。
    • vgname: ボリュームグループの名前。
    • zero: シンプールにゼロ化モードを設定します。
    例 1: シン LV の作成
    [lv]
    action=create
    vgname=RHGS_vg1
    poolname=lvthinpool
    lvtype=thinpool
    poolmetadatasize=200MB
    chunksize=1024k
    size=30GB
    例 2: シック LV の作成
    [lv]
    action=create
    vgname=RHGS_vg1
    lvname=engine_lv
    lvtype=thick
    size=10GB
    mount=/rhgs/brick1
    複数の論理ボリュームがある場合は、[lv1], [lv2] … など、LV セクションに番号を付けることで LV を作成できます
  • RH-subscription

    gdeploy 2.0 で利用できます。このモジュールは、リポジトリーのサブスクライブ、サブスクライブ解除、添付、有効化などに使用されます。RH-subscription モジュールでは、以下の変数が許可されます。

    このモジュールは、リポジトリーのサブスクライブ、サブスクライブ解除、添付、有効化などに使用されます。RH-subscription モジュールでは、以下の変数が許可されます。
    アクションが register の場合は、以下のオプションがサポートされます。
    • Username/activationkey: ユーザー名または activationkey。
    • Password/activationkey: パスワードまたはアクティベーションキー
    • auto-attach: true/false
    • pool: プールの名前。
    • repos: サブスクライブします。
    • disable-repos: 無効にする名前を指定します。このオプションを空白のままにすると、すべてのリポジトリーが無効になります。
    • ignore_register_errors: no に設定すると、システム登録に失敗すると gdeploy が終了します。
    • アクションが attach-pool の場合、以下のオプションがサポートされます。
      pool: 割り当てるプール名
      ignore_attach_pool_errors: no に設定すると、attach-pool の失敗時に gdeploy に失敗します。
    • アクションが enable-repos の場合は、以下のオプションがサポートされます。
      repos: サブスクライブするコンマ区切りのリポジトリーの一覧。
      ignore_enable_errors: no に設定すると、enable-repos の失敗時に gdeploy に失敗します。
    • アクションが disable-repos の場合、以下のオプションがサポートされます。
      repos: サブスクライブするコンマ区切りのリポジトリーの一覧。
      ignore_disable_errors: no に設定すると、disable-repos が失敗すると gdeploy に失敗します。
    • action が unregister の場合は、システムの登録が解除されます。
      ignore_unregister_errors: no に設定すると、登録解除に失敗したときに gdeploy に失敗します。
    例 1: Red Hat サブスクリプションネットワークにサブスクライブします。
    [RH-subscription1]
    action=register
    username=qa@redhat.com
    password=<passwd>
    pool=<pool>
    ignore_register_errors=no
    例 2: すべてのリポジトリーを無効にします。
    [RH-subscription2]
    action=disable-repos
    repos=*
    例 3: 一部のリポジトリーの有効化
    [RH-subscription3]
    action=enable-repos
    repos=rhel-7-server-rpms,rh-gluster-3-for-rhel-7-server-rpms,rhel-7-server-rhev-mgmt-agent-rpms
    ignore_enable_errors=no
  • yum

    gdeploy 2.0 で利用できます。このモジュールは、yum モジュールで rpm パッケージのインストールまたは削除に使用され、インストール時にリポジトリーを追加することもできます。

    アクション変数では、'install' と 'remove' の 2 つの値が許可されます。
    アクションをインストールする場合、以下のオプションがサポートされます。
    • packages: インストールするパッケージのコンマ区切りリスト。
    • repos: 追加するリポジトリー。
    • gpgcheck: yes/no の値を指定する必要があります。
    • update: yum 更新を開始する必要があるかどうか。
    action が remove の場合は、1 つのオプションのみを指定する必要があります。
    • remove: 削除するパッケージのコンマ区切りリスト
    たとえば、以下のようになります。
    [yum1]
    action=install
    gpgcheck=no
    # Repos should be an url; eg: http://repo-pointing-glusterfs-builds
    repos=<glusterfs.repo>,<vdsm.repo>
    packages=vdsm,vdsm-gluster,ovirt-hosted-engine-setup,screen,xauth
    update=yes
    特定のホストにパッケージをインストールします。
    [yum2:host1]
    action=install
    gpgcheck=no
    packages=rhevm-appliance
  • シェル

    gdeploy 2.0 で利用できます。このモジュールにより、ユーザーはリモートノードでシェルコマンドを実行できます。

    現在シェルでは、値 execution を持つアクション変数を 1 つ提供します。有効なシェルコマンドを値として持つコマンド変数。
    以下のコマンドは、すべてのノードで vdsm-tool を実行します。
    [shell]
    action=execute
    command=vdsm-tool configure --force
  • update-file

    gdeploy 2.0 で利用可能。update-file モジュールでは、ユーザーはファイルのコピー、ファイルの行の編集、または新しい行をファイルに追加できます。action 変数はコピー、編集、または追加のいずれかになります。

    action 変数が copy に設定されている場合は、以下の変数がサポートされます。
    • src: コピー元のファイルのソースパス。
    • dest: ファイルのコピー先に対するリモートマシンの宛先パス。
    action 変数が edit に設定されている場合は、以下の変数がサポートされます。
    • dest: 編集する必要がある宛先ファイル名
    • replace: 置き換える行に一致する正規表現。
    • line: 置き換える必要があるテキスト。
    アクション変数を追加すると、以下の変数がサポートされます。
    • dest: 行を追加するリモートマシンのファイル。
    • line: ファイルに追加する必要があります。行はファイルの末尾に追加されます。
    例 1: ファイルをリモートマシンにコピーします。
    [update-file]
    action=copy
    src=/tmp/foo.cfg
    例 2: リモートマシンの行を編集します。以下の例では、allowed_hosts の行が allowed_hosts=host.redhat.com に置き換えられます。
    [update-file]
    action=edit
    replace=allowed_hosts
    line=allowed_hosts=host.redhat.com
    例 3: ファイルの末尾に行を追加する
    Red Hat Enterprise Linux 7 の場合
    [update-file]
    action=add
    dest=/etc/ntp.conf
    line=server clock.redhat.com iburst
    Red Hat Enterprise Linux 8 の場合:
    [update-file]
    action=add
    dest=/etc/chrony.conf
    line=server 0.rhel.pool.ntp.org iburst
  • サービス

    gdeploy 2.0 で利用できます。サービスモジュールを使用すると、ユーザーはサービスの起動、停止、再起動、リロード、有効化、または無効化を行うことができます。action 変数は、これらの値を指定します。

    action 変数が start、stop、restart、reload、enable のいずれかに設定されていると、変数 servicename は、開始および停止するサービスなどを指定します。
    • service: 起動するサービスの名前、停止など。
    Red Hat Enterprise Linux 7 の場合
    例: ntp デーモンを有効にして起動します。
    [service1]
    action=enable
    service=ntpd
    [service2]
    action=restart
    service=ntpd
    Red Hat Enterprise Linux 8 の場合:
    例: chrony デーモンを有効にして起動します。
    [service1]
    action=enable
    service=chrony
    [service2]
    action=restart
    service=chrony
  • script

    gdeploy 2.0 で利用可能。script モジュールでは、ユーザーはリモートマシンでスクリプト/バイナリーを実行できます。action 変数は execute に設定されます。ユーザーは、2 つの変数ファイルと引数を指定できます。

    • file: ローカルマシンで実行ファイル。
    • args: 上記のプログラムへの引数。
    例: ’hosts’ セクションに記載されているすべてのリモートノードで disable-multipath.sh を実行します。
    [script]
    action=execute
    file=/usr/share/ansible/gdeploy/scripts/disable-multipath.sh
  • firewalld

    gdeploy 2.0 で利用可能。firewalld モジュールでは、ユーザーはファイアウォールルールを操作することができます。action 変数は 'add' と 'delete' の 2 つの値をサポートします。追加および削除は、以下の変数もサポートします。

    • port/services: ファイアウォールに追加するポートまたはサービス。
    • permanent: エントリーを永続化するかどうか。使用できる値は true/false です。
    • zone: デフォルトゾーンは public です
    以下に例を示します。
    [firewalld]
    action=add
    ports=111/tcp,2049/tcp,54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,16514/tcp
    services=glusterfs
  • geo-replication

    gdeploy 2.0.2 で利用可能。geo-replication モジュールにより、ユーザーは geo レプリケーションセッション、制御の設定および geo レプリケーションセッションの検証を行うことができます。サポートされる変数を以下に示します。

    • action: ジオレプリケーションセッションに対して実行されるアクション。
      • create: geo レプリケーションセッションを作成します。
      • start: 作成した geo レプリケーションセッションを開始します。
      • stop: 開始した geo レプリケーションセッションを停止します。
      • pause: geo レプリケーションセッションを一時停止するには、次のコマンドを実行します。
      • resume: 一時停止した geo レプリケーションセッションを再開します。
      • delete: geo レプリケーションセッションを削除するには、次のコマンドを実行します。
    • georepuser: 実行されるアクションに使用するユーザー名
      重要
      georepuser 変数を省略すると、ユーザーは root ユーザーであることが想定されます。
    • Master vol: マスターボリューム の情報が以下の形式になります。
      Master_HostName:Master_VolName
    • slavevol: 以下の形式で、スレーブボリュームの詳細が表示されます。
      Slave_HostName:Slave_VolName
    • slavenodes - スレーブノードの IP アドレスを以下の形式で指定します。
      Slave1_IPAddress,Slave2_IPAddress
      重要
      セカンダリー IP アドレスはコンマ (,) で区切る必要があります。
    • force: 強制的にシステムがアクションを実行します。使用できる値は yes または no です。
    • Start: 設定ファイルに指定されたアクション を開始します。使用できる値は yes または no です。デフォルト値は yes です。
    以下は例になります。
    [geo-replication]
    action=create
    georepuser=testgeorep
    mastervol=10.1.1.29:mastervolume
    slavevol=10.1.1.25:slavevolume
    slavenodes=10.1.1.28,10.1.1.86
    force=yes
    start=yes

5.1.8. gdeploy を使用した NFS Ganesha のデプロイ

gdeploy は、gdeploy バージョン 2.0.2-35 からの Red Hat Gluster Storage 3.5 での NFS Ganesha のデプロイメントおよび設定をサポートしています。
NFS-Ganesha は、NFS プロトコルのユーザー空間ファイルサーバーです。NFS-Ganesha の詳細は、「https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html-single/administration_guide/#nfs_ganesha」を参照してください。

5.1.8.1. 前提条件

以下の前提条件を満たしていることを確認します。

Subscription Manager のサブスクライブ

続行する前に、サブスクリプションマネージャーにサブスクライブして、NFS Ganesha パッケージを取得する必要があります。

以下の詳細を設定ファイルに追加して、サブスクリプションマネージャーにサブスクライブします。
[RH-subscription1]
action=register
username=<user>@redhat.com
password=<password>
pool=<pool-id>
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

レポジトリーの有効化

必要なリポジトリーを有効にするには、設定ファイルに以下の情報を追加します。

[RH-subscription2]
action=enable-repos
repos=rhel-7-server-rpms,rh-gluster-3-for-rhel-7-server-rpms,rh-gluster-3-nfs-for-rhel-7-server-rpms,rhel-ha-for-rhel-7-server-rpms,rhel-7-server-ansible-2-rpms
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

ファイアウォールポートの有効化

ファイアウォールポートを有効にするには、設定ファイルに以下の情報を追加します。

[firewalld]
action=add
ports=111/tcp,2049/tcp,54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,16514/tcp
services=glusterfs,nlm,nfs,rpc-bind,high-availability,mountd,rquota
注記
NFS クライアントの UDP マウントが失敗しないようにするには、gdeploy の [firewalld] セクションにポート 2049/udp を追加します。
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

必要なパッケージをインストールします。

必要なパッケージをインストールするには、設定ファイルに以下の情報を追加します。

[yum]
action=install
repolist=
gpgcheck=no
update=no
packages=glusterfs-ganesha
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

5.1.8.2. サポートされるアクション

gdeploy の NFS Ganesha モジュールにより、ユーザーは以下の操作を実行できます。
  • クラスターの作成
  • クラスターの破棄
  • ノードの追加
  • ノードの削除
  • ボリュームのエクスポート
  • ボリュームのエクスポート解除
  • NFS Ganesha 設定の更新

クラスターの作成

このアクションにより、指定のボリューム上に最新の NFS-Ganesha の設定が作成されます。このアクションでは、設定ファイルの nfs-ganesha が以下の変数に対応します。

  • ha-name: これは任意の変数です。デフォルトでは ganesha-ha-360 です。
  • cluster-nodes: これは必須の引数です。この変数は、クラスターを構成するために使用されるクラスターノード名のコンマ区切り値を想定します。
  • vip: これは必須引数です。この変数は、IP アドレスのコンマ区切りリストが必要です。これらは仮想 IP アドレスになります。
  • volname: これは、設定で [volume] セクションが含まれている場合に任意の変数です。
たとえば、NFS-Ganesha クラスターを作成するには、設定ファイルに以下の情報を追加します。
[hosts]
host-1.example.com
host-2.example.com
host-3.example.com
host-4.example.com

[backend-setup]
devices=/dev/vdb
vgs=vg1
pools=pool1
lvs=lv1
mountpoints=/mnt/brick

[firewalld]
action=add
ports=111/tcp,2049/tcp,54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,16514/tcp,662/tcp,662/udp
services=glusterfs,nlm,nfs,rpc-bind,high-availability,mountd,rquota

[volume]
action=create
volname=ganesha
transport=tcp
replica_count=3
force=yes

#Creating a high availability cluster and exporting the volume
[nfs-ganesha]
action=create-cluster
ha-name=ganesha-ha-360
cluster-nodes=host-1.example.com,host-2.example.com,host-3.example.com,host-4   .example.com
vip=10.70.44.121,10.70.44.122
volname=ganesha
ignore_ganesha_errors=no
上記の例では、必要なパッケージがインストールされ、ボリュームが作成され、NFS-Ganesha が有効化されていることを前提とします。
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

クラスターの破棄

このアクションの destroy-cluster クラスターは、NFS Ganesha を無効にします。これにより、1 つの変数 cluster-nodes が許可されます

たとえば、NFS-Ganesha クラスターを破棄するには、設定ファイルに以下の情報を追加します。
[hosts]
host-1.example.com
host-2.example.com

# To destroy the high availability cluster

[nfs-ganesha]
action=destroy-cluster
cluster-nodes=host-1.example.com,host-2.example.com
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

ノードの追加

add-node アクションでは、3 つの変数が許可されます。

  • ノード: クラスターに追加する必要のあるコンマ区切りのホスト名のリストを受け入れます。
  • 仮想 IP: コンマ区切りの IP アドレス一覧を受け入れます。
  • cluster_nodes: NFS Ganesha クラスターのコンマ区切りノードの一覧を受け入れます。
たとえば、ノードを追加するには、設定ファイルに以下の情報を追加します。
[hosts]
host-1.example.com
host-2.example.com
host-3.example.com

[peer]
action=probe

[clients]
action=mount
volname=host-3.example.com:gluster_shared_storage
hosts=host-3.example.com
fstype=glusterfs
client_mount_points=/var/run/gluster/shared_storage/


[nfs-ganesha]
action=add-node
nodes=host-3.example.com
cluster_nodes=host-1.example.com,host-2.example.com
vip=10.0.0.33
注記
3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

ノードの削除

delete-node アクションは nodes という変数を 1 つ取ります。これは、NFS Ganesha クラスターから削除するノードまたはノードをコンマ区切りのリストで指定します。

以下に例を示します。
[hosts]
host-1.example.com
host-2.example.com
host-3.example.com
host-4.example.com

[nfs-ganesha]
action=delete-node
nodes=host-2.example.com

ボリュームのエクスポート

このアクションはボリュームをエクスポートします。export-volume アクションは 1 つの変数 volname をサポートします。

たとえば、ボリュームをエクスポートするには、設定ファイルに以下の情報を追加します。
[hosts]
host-1.example.com
host-2.example.com

[nfs-ganesha]
action=export-volume
volname=ganesha
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

ボリュームのエクスポート解除:

このアクションにより、ボリュームがエクスポート解除されます。export-volume アクションは 1 つの変数 volname をサポートします。

たとえば、ボリュームのエクスポートを解除するには、設定ファイルに以下の情報を追加します。
[hosts]
host-1.example.com
host-2.example.com

[nfs-ganesha]
action=unexport-volume
volname=ganesha
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

NFS Ganesha 設定の更新

このアクションは、設定ファイルに設定ブロックを追加/削除または追加し、クラスターで refresh-config を実行します。

アクション refresh-config は以下の変数をサポートします。
  • del-config-lines
  • block-name
  • volname
  • ha-conf-dir
  • update_config_lines
例 1: クライアントブロックを追加して refresh-config を実行するには、設定ファイルに以下の詳細を追加します。
注記
client ブロックの refresh-config にはいくつかの制限があります。
  • 1 つのクライアントでのみ動作します。
  • ユーザーは設定ブロックから行を削除できません
[hosts]
host1-example.com
host2-example.com

[nfs-ganesha]
action=refresh-config
# Default block name is `client'
block-name=client
config-block=clients = 10.0.0.1;|allow_root_access = true;|access_type = "RO";|Protocols = "2", "3";|anonymous_uid = 1440;|anonymous_gid = 72;
volname=ganesha
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf
例 2: 行を削除し、refresh-config を実行するには、設定ファイルに以下の詳細を追加します。
[hosts]
host1-example.com
host2-example.com


[nfs-ganesha]
action=refresh-config
del-config-lines=client
volname=ganesha
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf
例 3: ボリュームで refresh-config を実行するには、設定ファイルに以下の情報を追加します。
[hosts]
host1-example.com
host2-example.com


[nfs-ganesha]
action=refresh-config
volname=ganesha
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf
例 4: 行を変更し、refresh-config を実行するには、設定ファイルに以下の詳細を追加します。
[hosts]
host1-example.com
host2-example.com


[nfs-ganesha]
action=refresh-config
update_config_lines=Access_type = "RO";
#update_config_lines=Protocols = "4";
#update_config_lines=clients = 10.0.0.1;
volname=ganesha
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

5.1.9. gdeploy を使用した Samba / CTDB のデプロイ

サーバーメッセージブロック (SMB) プロトコルを使用して、サーバー上の SMB 共有として GlusterFS ボリュームにディレクトリーをエクスポートすることで、Red Hat Gluster Storage ボリュームにアクセスできます。Red Hat Gluster Storage では、Samba は SMB プロトコルを使用してボリュームを共有するために使用されます。

5.1.9.1. 前提条件

以下の前提条件を満たしていることを確認します。

Subscription Manager のサブスクライブ

サブスクリプションマネージャーにサブスクライブし、Samba パッケージを取得してから詳細に進む必要があります。

以下の詳細を設定ファイルに追加して、サブスクリプションマネージャーにサブスクライブします。
[RH-subscription1]
action=register
username=<user>@redhat.com
password=<password>
pool=<pool-id>
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

レポジトリーの有効化

必要なリポジトリーを有効にするには、設定ファイルに以下の情報を追加します。

Red Hat Enterprise Linux 7
[RH-subscription2]
action=enable-repos
repos=rhel-7-server-rpms,rh-gluster-3-for-rhel-7-server-rpms,rh-gluster-3-samba-for-rhel-7-server-rpms,rhel-7-server-ansible-2-rpms
Red Hat Enterprise Linux 8
[RH-subscription2]
action=enable-repos
rh-gluster-3-for-rhel-8-x86_64-rpms,ansible-2-for-rhel-8-x86_64-rpms,rhel-8-for-x86_64-baseos-rpms,rhel-8-for-x86_64-appstream-rpms,rhel-8-for-x86_64-highavailability-rpms,rh-gluster-3-samba-for-rhel-8-x86_64-rpms
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

ファイアウォールポートの有効化

ファイアウォールポートを有効にするには、設定ファイルに以下の情報を追加します。

[firewalld]
action=add
ports=54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,4379/tcp
services=glusterfs,samba,high-availability
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

必要なパッケージをインストールします。

必要なパッケージをインストールするには、設定ファイルに以下の情報を追加します。

[yum]
action=install
repolist=
gpgcheck=no
update=no
packages=samba,samba-client,glusterfs-server,ctdb
以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

5.1.9.2. Samba の設定

Samba は、以下の 2 つの方法で有効にできます。
  • 既存のボリュームでの Samba の有効化
  • ボリューム作成時の Samba の有効化

既存のボリュームでの Samba の有効化

Red Hat Gluster Storage ボリュームがすでに存在する場合は、ボリュームセクションで、アクションを smb-setup と記載する必要があります。gdeploy は各ホストの glusterd 設定ファイルを更新するため、クラスター内のすべてのホストについて言及する必要があります。

たとえば、既存のボリュームで Samba を有効にするには、設定ファイルに以下の情報を追加します。
[hosts]
10.70.37.192
10.70.37.88

[volume]
action=smb-setup
volname=samba1
force=yes
smb_username=smbuser
smb_mountpoint=/mnt/smb
注記
ホストが CTDB クラスターに含まれていないことを確認します。
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

ボリューム作成時の Samba の有効化

ボリュームの作成時に Samba を設定する場合は、設定ファイルで変数 smb を yes に設定する必要があります。

たとえば、ボリュームの作成時に Samba を有効にするには、設定ファイルに以下の情報を追加します。
[hosts]
10.70.37.192
10.70.37.88
10.70.37.65

[backend-setup]
devices=/dev/vdb
vgs=vg1
pools=pool1
lvs=lv1
mountpoints=/mnt/brick

[volume]
action=create
volname=samba1
smb=yes
force=yes
smb_username=smbuser
smb_mountpoint=/mnt/smb
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf
注記
Samba を有効にする場合は、smb_usernamesmb_mountpoint も、samba が acls を正しく設定する必要がある場合に必要になります。

5.1.9.3. CTDB の設定

CTDB を使用するには、CTDB ロックファイルを保護するために、別のボリュームを設定する必要があります。Red Hat は、レプリカ数が Samba サーバーとして使用されるサーバー数と同じになる複製ボリュームを推奨しています。
以下の設定ファイルは、Samba サーバーでもある 2 つのホストに CTDB ボリュームを設定します。
[hosts]
10.70.37.192
10.70.37.88
10.70.37.65

[volume]
action=create
volname=ctdb
transport=tcp
replica_count=3
force=yes

[ctdb]
action=setup
public_address=10.70.37.6/24 eth0,10.70.37.8/24 eth0
volname=ctdb
以下の例のように ctdb_nodes パラメーターを使用して、CTDB クラスターを別の IP アドレスを使用するように設定できます。
[hosts]
10.70.37.192
10.70.37.88
10.70.37.65

[volume]
action=create
volname=ctdb
transport=tcp
replica_count=3
force=yes

[ctdb]
action=setup
public_address=10.70.37.6/24 eth0,10.70.37.8/24 eth0
ctdb_nodes=192.168.1.1,192.168.2.5
volname=ctdb
以下のコマンドを使用して、設定を実行します。
# gdeploy -c txt.conf

5.1.10. ボリュームでの SSL の有効化

SSL が有効なボリュームを作成するか、gdeploy (v2.0.1) を使用して既存ボリュームで SSL を有効にすることができます。本セクションでは、SSL を有効にするために gdeploy 用に設定ファイルを書き込む方法を説明します。

5.1.10.1. ボリュームの作成および SSL の有効化

ボリュームを作成して SSL を有効にするには、設定ファイルに以下の情報を追加します。
[hosts]
10.70.37.147
10.70.37.47
10.70.37.13

[backend-setup]
devices=/dev/vdb
vgs=vg1
pools=pool1
lvs=lv1
mountpoints=/mnt/brick

[volume]
action=create
volname=vol1
transport=tcp
replica_count=3
force=yes
enable_ssl=yes
ssl_clients=10.70.37.107,10.70.37.173
brick_dirs=/data/1

[clients]
action=mount
hosts=10.70.37.173,10.70.37.107
volname=vol1
fstype=glusterfs
client_mount_points=/mnt/data
上記の例では、vol1 という名前のボリュームが作成され、SSL がこのファイルで有効になっています。gdeploy は自己署名証明書を作成します。
設定ファイルに詳細を追加したら、以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

5.1.10.2. 既存のボリュームで SSL を有効にする場合:

既存のボリュームで SSL を有効にするには、設定ファイルに以下の情報を追加します。
[hosts]
10.70.37.147
10.70.37.47

# It is important for the clients to be unmounted before setting up SSL
[clients1]
action=unmount
hosts=10.70.37.173,10.70.37.107
client_mount_points=/mnt/data

[volume]
action=enable-ssl
volname=vol2
ssl_clients=10.70.37.107,10.70.37.173

[clients2]
action=mount
hosts=10.70.37.173,10.70.37.107
volname=vol2
fstype=glusterfs
client_mount_points=/mnt/data
設定ファイルに詳細を追加したら、以下のコマンドを実行して設定ファイルを実行します。
# gdeploy -c txt.conf

5.1.11. Gdeploy ログファイル

gdeploy は、通常非特権ユーザーによって実行されるため、デフォルトで gdeploy ログファイルは、/ var/ log ディレクトリーではなく、/home/ユーザー名/.gdeploy/logs /gdeploy.log に書き込まれます。
ログの場所を変更するには、GDEPLOY_LOGFILE 環境変数の値として別の場所を設定します。たとえば、gdeploy ログの場所を、このセッションの /var/log/gdeploy/gdeploy.log に設定するには、以下のコマンドを実行します。
$ export GDEPLOY_LOGFILE=/var/log/gdeploy/gdeploy.log
これをこのユーザーのデフォルトログの場所として永続的に設定するには、そのユーザー用の /home/username/.bash_profile ファイルにある別の行と同じコマンドを追加します。

5.2. 暗号化したディスクについて

Red Hat Gluster Storage は、暗号化されたデバイスでデータアクセスを制限するためにブリックを作成する機能を提供します。暗号化したブリックを使用して、Red Hat Gluster Storage ボリュームを作成できます。
暗号化されたディスクの作成方法は、以下の製品ドキュメントを参照してください。
  • RHEL 6 の場合は、『『Red Hat Enterprise Linux 6 インストールガイド』』の「『ディスクの暗号化』」を参照してください。
    重要
    Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。『 インストールガイド』の「 『バージョンの詳細』 表」 『および「Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 」を参照してください。
  • RHEL 7 の場合は、『『Red Hat Enterprise Linux 7 セキュリティーガイド』』の「『暗号化』」を参照してください。
  • Red Hat は、RHEL 7.5 以降、システムの起動時に LUKS ディスクをリモートに有効にできる追加のコンポーネントを実装しています。これは、NBDE (Network Bound Disk Encryption) として呼び出されるようになりました。NBDE の詳細は、『『Red Hat Enterprise Linux 7 セキュリティーガイド』』の「『Configuring Automated Unlocking of Encrypted Volumes using Policy-Based Decryption』」を参照してください。
  • RHEL 8 の場合は、『『Red Hat Enterprise Linux 8 セキュリティーガイド』』の「『Encrypting Block Devices Using LUKS』」を参照してください。

5.3. ブリックのフォーマットとマウント

Red Hat Gluster Storage ボリュームを作成するには、ボリュームを構成するブリックを指定します。ボリュームを作成したら、ボリュームをマウントする前に起動する必要があります。

5.3.1. ブリックの手動作成

重要
  • Red Hat は、ブリックに XFS ファイルシステムを使用した論理ボリュームのフォーマットをサポートします。
  • Red Hat は、分散ボリューム(純粋分散、分散レプリカまたは分散/デペーパー)の異種サブボリュームサイズをサポートします。Red Hat では、同じサブボリュームのブリックについて異種ブリックサイズをサポートしません。
    たとえば、3 つのブリックが同じ複製に属し、同じ複製セットに属する限り、3 つのブリックが 10GiB の 3 GiB のブリックと 3 つのブリックを 100GiB のブリックに配置すると、分散レプリカの 3 つのボリュームが同じ複製セットに属し、100GiB と 100GiB のブリックが 100GiB のブリックに置くことができます。このようにして、1 つのサブボリューム 10GiB、もう 1 つは 50GiB と 100GiB になります。分散ハッシュテーブルは、割り当てられた各サブボリュームに数のバランスを取り、サブボリュームがそのサイズに比例して一杯になるようにします。

5.3.1.1. シンプロビジョニングされた論理ボリュームの作成

  1. pvcreate コマンドを使用して、物理ボリューム(PV)を作成します。
    # pvcreate --dataalignment alignment_value device
    以下は例になります。
    # pvcreate --dataalignment 1280K /dev/sdb
    ここでは、/dev/sdb がストレージデバイスです。
    デバイスに基づいて正しい データ アラインメントオプションを使用します。詳細はを参照してください。 「ブリック設定」
    注記
    デバイス名と調整値は、使用中のデバイスによって異なります。
  2. vgcreate コマンドを使用して、PV からボリュームグループ(VG)を作成します。
    # vgcreate --physicalextentsize alignment_value volgroup device
    以下は例になります。
    # vgcreate --physicalextentsize 1280K rhs_vg /dev/sdb
  3. 以下のコマンドを使用して、シンプールを作成します。
    # lvcreate --thin volgroup/poolname --size pool_sz --chunksize chunk_sz --poolmetadatasize metadev_sz --zero n
    
    以下は例になります。
    # lvcreate --thin rhs_vg/rhs_pool --size 2T --chunksize 1280K --poolmetadatasize 16G --zero n
    19章パフォーマンスチューニング を読んで chunksize および poolmetadatasize の適切な値を選択してください。
  4. --virtualsize オプションおよび -- thin オプションを指定して、lvcreate コマンドを実行して、以前に作成したプールを使用するシンプロビジョニングされたボリュームを作成します。
    # lvcreate --virtualsize size --thin volgroup/poolname --name volname
    以下は例になります。
    # lvcreate --virtualsize 1G --thin rhs_vg/rhs_pool --name rhs_lv
    シンプールには 1 つの LV のみを作成することが推奨されます。
  5. 対応している XFS 設定を使用してブリックをフォーマットし、ブリックをマウントして、ブリックが正しくマウントされていることを確認します。Red Hat Gluster Storage のパフォーマンスを強化するには、ブリックをフォーマットする前に 19章パフォーマンスチューニング を読んでください。
    重要
    外部ログファイルでフォーマットされたブリックでは、スナップショットはサポートされません。Red Hat Gluster Storage ブリックをフォーマットする場合は、mkfs.xfs コマンドで -l logdev=device オプションを使用しないでください。
    # mkfs.xfs -f -i size=512 -n size=8192 -d su=128k,sw=10 device
    DEVICE は、作成されたシン LV です。inode サイズは 512 バイトに設定され、Red Hat Gluster Storage で使用される拡張属性に対応します。
  6. # mkdir /mountpoint を実行して、ブリックをリンクするためのディレクトリーを作成します。
    # mkdir /rhgs
  7. /etc/fstab にエントリーを追加します。
    /dev/volgroup/volname /mountpoint  xfs rw,inode64,noatime,nouuid,x-systemd.device-timeout=10min  1 2
    以下は例になります。
    /dev/rhs_vg/rhs_lv /rhgs  xfs rw,inode64,noatime,nouuid,x-systemd.device-timeout=10min  1 2
  8. mount /mountpoint を実行して、ブリックをマウントします。
  9. df -h コマンドを実行して、ブリックが正常にマウントされていることを確認します。
    # df -h
    /dev/rhs_vg/rhs_lv   16G  1.2G   15G   7% /rhgs
  10. SElinux が有効になっている場合は、以下のコマンドを使用して作成したブリック用に手動で SELinux ラベルを設定する必要があります。
    # semanage fcontext -a -t glusterd_brick_t /rhgs/brick1
    # restorecon -Rv /rhgs/brick1

5.3.2. ボリュームのブログとしてサブディレクトリーを使用

XFS ファイルシステムを作成し、Red Hat Gluster Storage ボリュームを作成している間に、それらをブリックとして指示できます。マウントポイントが利用できない場合、データはアンマウントされたディレクトリーのルートファイルシステムに直接書き込まれます。
たとえば、/rhgs ディレクトリーはマウントしたファイルシステムであり、ボリューム作成のブリックとして使用されます。ただし、何らかの理由でマウントポイントが利用できない場合には、/rhgs ディレクトリーで書き込みが継続されますが、これはルートファイルシステム下にあります。
この問題を解決するには、以下の手順を行います。
Red Hat Gluster Storage の設定中に、XFS ファイルシステムを作成してマウントします。マウントしたら、サブディレクトリーを作成し、このサブディレクトリーをボリューム作成のブリックとして使用します。ここでは、XFS ファイルシステムが /bricks としてマウントされます。ファイルシステムが利用可能になると、/rhgs/brick1 という名前のディレクトリーを作成し、ボリュームの作成に使用します。1 つのマウントから複数のブリックが作成されていないことを確認します。このアプローチには、以下の利点があります。
  • /rhgs ファイルシステムが利用できなくなると、/rhgs/brick1 ディレクトリーがシステムで利用できることはなくなりました。したがって、別の場所に書き込むことでデータ損失は発生しません。
  • これには、ネスト化に追加のファイルシステムは必要ありません。
ボリュームを作成するために、サブディレクトリーをブリックとして使用するには、以下のコマンドを実行します。
  1. マウントされたファイルシステムに brick 1 サブディレクトリーを作成します。
    # mkdir /rhgs/brick1
    すべてのノードで上記の手順を繰り返します。
  2. サブディレクトリーをブリックとして使用し、Red Hat Gluster Storage ボリュームを作成します。
    # gluster volume create distdata01 ad-rhs-srv1:/rhgs/brick1
    ad-rhs-srv2:/rhgs/brick2
  3. Red Hat Gluster Storage ボリュームを起動します。
    # gluster volume start distdata01
  4. ボリュームのステータスを確認します。
    # gluster  volume status distdata01
注記
同じサーバーから複数のブリックを使用する場合は、ブリックが以下の形式でマウントされていることを確認します。以下に例を示します。
# df -h

/dev/rhs_vg/rhs_lv1   16G  1.2G   15G   7% /rhgs1
/dev/rhs_vg/rhs_lv2   16G  1.2G   15G   7% /rhgs2
各サーバーから 2 ブリックで分散ボリュームを作成します。以下に例を示します。
# gluster volume create test-volume server1:/rhgs1/brick1 server2:/rhgs1/brick1 server1:/rhgs2/brick2 server2:/rhgs2/brick2

5.3.3. 削除されたボリュームからのブリックの再使用

ブリックは削除されたボリュームから再利用できますが、いくつかの手順を再利用可能にする必要があります。
再フォーマット可能なファイルシステムによるブリック (最適な方法)
# mkfs.xfs -f -i size=512 デバイス を実行して、ブリックをサポートされる要件に合わせて再フォーマットし、新規ボリュームで即時に再利用できるようにします。
注記
ブリックが再フォーマットされると、すべてのデータが削除されます。
ブリックディレクトリーの親にあるファイルシステム
ファイルシステムを再フォーマットできない場合は、ブリックディレクトリー全体を削除して、もう一度作成します。

5.3.4. 使用できないブリックのクリーニング

ブリックに関連付けられたファイルシステムを再フォーマットできず、ブリックディレクトリーを削除できない場合は、以下の手順を実行します。
  1. ブリックの以前の既存データをすべて削除します( .glusterfs サブディレクトリーを含む)。
  2. # setfattr -x trusted.glusterfs.volume-id brick および # setfattr -x trusted.gfid brick を実行して、ブリックのルートから属性 を削除します
  3. # getfattr -d -m を実行してください。ボリュームに設定された属性を検証する ブリック。属性を書き留めておきます。
  4. # setfattr -x attribute brick を実行して、glusterFS ファイルシステムに関連する属性を削除します。
    分散ボリュームの trusted.glusterfs.dht 属性は、削除する必要のある属性の例の 1 つです。

5.4. 分散ボリュームの作成

このタイプのボリュームは、ファイルをボリュームのブリック全体に分散します。

図5.1 分散ボリュームの図

2 台のサーバーで構成される分散ボリュームの図。server1 ブリックに 2 つのファイルが表示され、1 つのファイルが server2 ブリックに表示されます。分散ボリュームは、1 つのマウントポイントに設定されます。
警告
分散ボリュームは、ボリュームのブリック全体に無作為に分散されるため、ディスクまたはサーバーの障害時に大きなデータ損失が発生する可能性があります。そのため、実稼働環境で使用する前にアーキテクチャーレビューが必要になります。
アーキテクチャーレビューについては、配布されるボリュームのみを使用するように Red Hat アカウントチームまでお問い合わせください。
冗長性が重要ではない場合や、他のハードウェアやソフトウェア層から提供される分散ボリュームのみを使用します。その他の場合は、分散レプリケーションのボリュームなど、冗長性を提供するボリューム種別の 1 つを使用します。
分散ボリュームのみの制限には、以下が含まれます。
  1. インサービスのアップグレードなし: アップグレード時に分散されるボリュームのみオフラインでなければなりません。
  2. 時折発生するディレクトリーエントリーと inode の一時的な不整合。
  3. I/O 操作は、ノードが利用不可または結果として生じるノードの障害によりブロックまたは失敗します。
  4. データの永久損失。

分散ボリュームの作成

Gluster volume create コマンドを使用して、異なるタイプのボリュームを作成し、gluster volume info コマンドでボリュームの作成が正常に行われたことを確認します。

前提条件

  1. gluster volume create コマンドを実行して、分散ボリュームを作成します。
    構文は gluster volume create NEW-VOLNAME [transport tcp | rdma(Deprecated)| tcp,rdma] NEW-BRICK です。
    transport のデフォルト値は tcp です。auth. allow や auth. reject などの他のオプションを渡すことができます。パラメーターの全一覧は、「ボリュームオプションの設定」 を参照してください。
    このオプションによりパフォーマンスが低下する可能性があるため、Red Hat では、分散ボリュームで performance.client-io-threads オプションを無効にすることを推奨します。以下のコマンドを実行して performance.client-io-threads を無効にします。
    # gluster volume set VOLNAME performance.client-io-threads off

    例5.1 2 つのストレージサーバーを使用した分散ボリューム

    # gluster v create glustervol server1:/rhgs/brick1 server2:/rhgs/brick1
    volume create: glutervol: success: please start the volume to access data

    例5.2 4 サーバーを使用した InfiniBand への分散ボリューム

    # gluster v create glustervol transport rdma server1:/rhgs/brick1 server2:/rhgs/brick1 server3:/rhgs/brick1 server4:/rhgs/brick1
    volume create: glutervol: success: please start the volume to access data
  2. # gluster volume start VOLNAME を実行してボリュームを起動します。
    # gluster v start glustervol
    volume start: glustervol: success
  3. Gluster ボリューム情報 コマンドを実行して、必要に応じてボリューム情報を表示します。
    # gluster volume info
    Volume Name: test-volume
    Type: Distribute
    Status: Created
    Number of Bricks: 2
    Transport-type: tcp
    Bricks:
    Brick1: server1:/rhgs/brick
    Brick2: server2:/rhgs/brick

5.5. 複製ボリュームの作成

複製ボリュームは、ボリューム内の複数のブリック間でファイルのコピーを作成します。高可用性および信頼性が高い環境で複製されたボリュームを使用します。
Gluster ボリュームを作成して異なるタイプのボリュームを作成しgluster ボリュームの情報を使用して、 ボリュームの作成に成功したことを確認します。

前提条件

警告
Red Hat は、Arbiter ブリックのない双方向レプリケーションとして、Red Hat Gluster Storage 3.4 で非推奨となったため、第 2 のレプリカを使用しない 2 方向レプリケーションの使用を推奨しません。この変更は、arbiter ブリックを使用しない複製されたボリュームと分散レプリカボリュームの両方に影響します。
arbiter ブリックのない双方向レプリケーションは、スプリットブレイン条件から十分な保護を提供しないため非推奨になりました。分散レプリケーションの設定でも、双方向レプリケーションでは、結合するノードを使用せずに競合するファイルの正しいコピーが選択されていることを確認できません。
ダミーノードは、この問題の仲介ソリューションとして使用できますが、Red Hat では、Arbiter ブリックなしで双方向レプリケーションを使用するボリュームがすべて、Arbitrated レプリケーションまたは 3 方向レプリケーションのいずれかを使用するように移行されることを強く推奨します。
任意のブリックなしで 2 方向の複製ボリュームを移行する手順は、『5.7.5 で調整されたボリュームで利用できます。Arbitrated ボリューム』 に変換されます。3 方向のレプリケーションに関する情報は、「3 方向の複製ボリュームの作成」 および 「3 方向の分散複製ボリュームの作成」 で参照できます。

5.5.1. 3 方向の複製ボリュームの作成

3 方向の複製ボリュームは、ボリューム内の複数のブリックに 3 つのファイルのコピーを作成します。ブリックの数は、複製されたボリュームのレプリカ数と同じである必要があります。サーバーおよびディスクの障害から保護するには、ボリュームのブリックを異なるサーバーから保護することを推奨します。
同期の 3 方向のレプリケーションが Red Hat Gluster Storage で完全にサポートされるようになりました。3 方向の複製されたボリュームは JBOD を使用することを推奨しますが、3 方向の複製ボリュームでハードウェア RAID を使用することもサポートされます。

図5.2 3 方向の複製ボリュームの図

3 方向の複製ボリュームの図
3 方向の複製ボリュームの作成
  1. gluster volume create コマンドを実行して、複製されたボリュームを作成します。
    構文は # gluster volume create NEW-VOLNAME [replica COUNT] [transport tcp | rdma(Deprecated)| tcp,rdma] NEW-BRICK です。
    transport のデフォルト値は tcp です。auth. allow や auth. reject などの他のオプションを渡すことができます。パラメーターの全一覧は、「ボリュームオプションの設定」 を参照してください。

    例5.3 3 つのストレージサーバーのある複製ボリューム

    ブリックを指定する順番により、ブリックが互いに複製される方法が決まります。たとえば、すべての n ブリックがあります。3 は レプリカ数でレプリカセットを形成します。これは、図5.2「3 方向の複製ボリュームの図」 で説明されています。
    # gluster v create glutervol data replica 3 transport tcp server1:/rhgs/brick1 server2:/rhgs/brick2 server3:/rhgs/brick3
    volume create: glutervol: success: please start the volume to access
  2. # gluster volume start VOLNAME を実行してボリュームを起動します。
    # gluster v start glustervol
    volume start: glustervol: success
  3. Gluster ボリューム情報 コマンドを実行して、必要に応じてボリューム情報を表示します。
重要
デフォルトでは、スプリットブレインのシナリオを最小限に抑えるために、クライアント側のクォーラムは 3 方向の複製ボリュームで有効にされます。クライアント側のクォーラムに関する詳細は、を参照してください。 「クライアント側クォーラムの設定」

5.5.2. ハードな複製ボリュームの作成

シャード化はファイルを小さな部分に分割し、それらをボリュームを構成するブリック全体に分散できるようにします。これはボリュームごとに有効になります。
シャードが有効にされると、ボリュームに書き込まれたファイルは分割されます。部分のサイズは、ボリュームの features.shard-block-size パラメーターの値によって異なります。最初のコンポーネントはブリックに書き込まれ、通常のファイルのような GFID が付与されます。後続の部分は、ボリュームのブリック間で均等に分散されます(シャードブリックはデフォルトで配布)されますが、そのブリックの .shard ディレクトリーに書き込まれ、GFID とパーツの順序を示す番号が付けられます。たとえば、ファイルが 4 つの部分に分割される場合、最初のパーツは GFID という名前で、通常どおり保存されます。他の 3 つの要素はそれぞれ GFID.1、GFID.2、および GFID.3 という名前です。これらは .shard ディレクトリーに置かれ、ボリューム内のさまざまなブリック間で均等に分散されます。
シャード化は、ボリュームのブリック全体にファイルを分散するため、ボリュームに個別のブリックサイズよりも大きいファイルを保管することができます。ファイルの断片は小さくなるため、修復操作は速くなり、geo レプリケーションのデプロイメントは、アグリゲートファイル全体を同期するのではなく、変更したファイルの断片を同期できます。
シャード化により、アドホック方式でボリュームにブリックを追加して、ボリュームの容量を増やすこともできます。

5.5.2.1. サポート対象のユースケース

シャード化には、サポートされるユースケースが 1 つあります。Red Hat Gluster Storage を Red Hat Enterprise Virtualization のストレージドメインとして提供し、ライブ仮想マシンイメージのストレージを提供します。シャード化は、以前の実装よりもパフォーマンスを大幅に向上するため、このユースケースでも必要であることに注意してください。
重要
クォータはシャード化と互換性がありません。
重要
シャード化は新規デプロイメントでのみサポートされます。現在この機能のアップグレードパスがないためです。

例5.4 例: 3 方向の複製されたシャードボリューム

  1. 『『Red Hat Gluster Storage 管理ガイドhttps://access.redhat.com/documentation/en-US/red_hat_gluster_storage/3.5/html/Administration_Guide/sect-Creating_Replicated_Volumes.html#Creating_Three-way_Replicated_Volumes』で説明されているように、3 方向の複製ボリュームを設定します。
  2. ボリュームを起動する前に、ボリュームでシャード化を有効にします。
    # gluster volume set test-volume features.shard enable
  3. ボリュームを起動し、これが想定通りに機能していることを確認します。
    # gluster volume test-volume start
    # gluster volume info test-volume

5.5.2.2. 設定オプション

シャード化はボリュームレベルで有効にされ、設定されます。設定オプションは以下のとおりです。
features.shard
指定されたボリュームでシャード化を有効または無効にします。有効な値は enable および disable です。デフォルトの値は disable です。
# gluster volume set volname features.shard enable
このコマンドは、このコマンドの実行時に作成されたファイルにのみ影響することに注意してください。このコマンドを実行する前に作成されたファイルは、以前の動作を維持します。
features.shard-block-size
シャードが有効な場合にファイルの最大サイズを指定します。このパラメーターでサポートされる値は 512MB です。
# gluster volume set volname features.shard-block-size 32MB
このコマンドは、このコマンドの実行時に作成されたファイルにのみ影響することに注意してください。このコマンドを実行する前に作成されたファイルは、以前の動作を維持します。

5.5.2.3. シャード化されたファイルのパーツの検索

シャード化を有効にする際に、機能していることを確認するか、または特定のファイルがボリューム全体にシャード化されている方法を確認する必要がある場合があります。
ファイルの一部を見つけるには、ファイルの GFID を確認する必要があります。ファイルの GFID を取得するには、以下を実行します。
# getfattr -d -m. -e hex path_to_file
GFID を取得したら、ブリックで以下のコマンドを実行して、このファイルがどのように配布されたかを確認します。
# ls /rhgs/*/.shard -lh | grep GFID

5.6. 分散複製ボリュームの作成

ストレージのスケーリングに必要な環境で分散レプリケートされたボリュームを使用し、信頼性が高くなっています。また、分散レプリケートされたボリュームは、ほとんどの環境で読み取りパフォーマンスも向上します。
注記
ブリックの数は、分散レプリケートされたボリュームのレプリカ数の倍数である必要があります。また、ブリックが指定されている順序は、データ保護に大きく影響します。付与される一覧の各 replica_count はレプリカセットを形成し、すべてのレプリカセットを分散セットに統合します。レプリカセットメンバーが同じノードに配置されていないことを確認するには、全サーバーで最初のブリックを一覧表示し、次に全サーバーに 2 番目のブリックが同じ順序で 2 番目のブリックを表示するなどを行います。

前提条件

5.6.1. 3 方向の分散複製ボリュームの作成

3 方向の複製分散ボリュームは、ボリューム内の複数のブリックに 3 つのファイルのコピーを配布し、作成します。ブリックの数は、複製されたボリュームのレプリカ数と同じである必要があります。サーバーおよびディスクの障害から保護するには、ボリュームのブリックを異なるサーバーから保護することを推奨します。
同時発生の 3 方向の分散レプリケーションが Red Hat Gluster Storage で完全にサポートされるようになりました。3 方向の分散複製ボリュームは JBOD を使用することが推奨されます。ただし、3 方向の分散複製ボリュームでのハードウェア RAID の使用もサポートされます。

図5.3 3 方向の分散複製ボリューム (3 方向の分散レプリケート) の図

3 方向の分散複製ボリューム (3 方向の分散レプリケート) の図
3 方向の分散複製ボリュームの作成
  1. gluster volume create コマンドを実行して、分散した複製ボリュームを作成します。
    構文は # gluster volume create NEW-VOLNAME [replica COUNT] [transport tcp | rdma(Deprecated)| tcp,rdma] NEW-BRICK です。
    transport のデフォルト値は tcp です。auth. allow や auth. reject などの他のオプションを渡すことができます。パラメーターの全一覧は、「ボリュームオプションの設定」 を参照してください。

    例5.5 3 方向のレプリケーションのある 6 つのノード分散複製ボリューム

    ブリックを指定する順番により、ブリックが互いに複製される方法が決まります。たとえば、最初の 3 ブリック。この 3 はレプリカ count で、複製セットを形成します。
    # gluster v create glustervol replica 3 transport tcp server1:/rhgs/brick1 server2:/rhgs/brick1 server3:/rhgs/brick1 server4:/rhgs/brick1 server5:/rhgs/brick1 server6:/rhgs/brick1
    volume create: glutervol: success: please start the volume to access data
  2. # gluster volume start VOLNAME を実行してボリュームを起動します。
    # gluster v start glustervol
    volume start: glustervol: success
  3. Gluster ボリューム情報 コマンドを実行して、必要に応じてボリューム情報を表示します。
重要
デフォルトでは、クライアント側のクォーラムは 3 方向の分散複製ボリュームで有効になります。スプリットブレインのシナリオを防ぐために、分散複製ボリュームでサーバー側のクォーラムを設定する必要もあります。クォーラムの設定に関する詳細は、「スプリットブレインの防止」 を参照してください。

5.7. Arbitrated Replicated ボリュームの作成

Arbitrated Replicated ボリュームには、ボリューム内のファイルの完全コピーが 2 つ含まれています。Arbitrated ボリュームには、ボリューム内の 2 つのデータブリックごとに追加の arbiter ブリックがあります。Arbiter ブリックはファイルデータを格納しません。ファイル名、構造、メタデータのみを格納します。Arbiter ブリックは、クライアントクォーラムを使用して arbiter のメタデータを他のノードのメタデータと比較し、ボリューム内の一貫性を確保し、スプリットブレインの条件を防ぎます。

Arbitrated Replicated ボリュームの利点

一貫性の向上
arbiter が設定されると、判別ロジックはクライアント側のクォーラムを auto モードで使用して、スプリットブレイン状態を引き起こすファイル操作を防ぎます。
必要なディスク容量が少なくなる
arbiter ブリックはファイル名とメタデータのみを保存するため、arbiter ブリックはボリューム内の他のブリックよりもはるかに小さくすることができます。
必要なノード数が少なくなります
あるボリュームの arbiter ブリックが含まれるノードは、別のボリュームのデータブリックを使用して設定できます。この「チェーン」の設定により、ストレージ全体の要件を満たすために、少ないノードを使用できます。
非推奨の双方向複製ボリュームからの容易な移行
Red Hat Gluster Storage は、Arbiter ブリックなしで双方向の複製ボリュームを、Arbitrated Replicated ボリュームに変換できます。詳細は、「判別ボリュームへの変換」 を参照してください。

Arbitrated Replicated ボリュームの制限

  • Arbitrated Replicated ボリュームは、arbiter ブリックのない双方向複製ボリュームよりも優れたデータの一貫性を提供します。ただし、Arbitrated Replicated ボリュームはメタデータのみを格納するため、arbiter ブリックのない双方向複製ボリュームと同じレベルの可用性を提供します。高可用性を実現するには、Arbitrated Replicated ボリュームの代わりに、3 方向の複製ボリュームを使用する必要があります。
  • 階層化は、仲裁された複製ボリュームと互換性がありません。
  • 判別ボリュームは、一度に 3 つのブリックのセットでのみ設定できます。Red Hat Gluster Storage は、arbiter ブリックをそのボリュームに追加することで、既存の双方向複製ボリュームを、Arbitrated Replicated ボリュームに変換できます。詳細は、「判別ボリュームへの変換」 を参照してください。

5.7.1. 判別ボリューム要件

本項では、サポートされる任意のボリュームデプロイメントの要件について説明します。

5.7.1.1. Arbiter ブリックをホストするノードのシステム要件

arbiter ブリックを含むノードの最低システム要件は、管理者が行う設定の選択によって異なります。専用 arbiter と連鎖的な Arbiter 設定の違いに関する詳細は、「複数の Arbitrated Replicated ボリュームの作成」 を参照してください。

表5.1 物理マシンでの任意設定の要件

設定タイプ最小 CPU最小 RAMNICArbiter ブリックサイズ最大レイテンシー
専用 arbiter64 ビットクアッドコアプロセッサー (ソケット 2 つ)8 GB[a]ストレージプールの他のノードに一致1 TB から 4 TB[b]5 ミリ秒[c]
チェーン abiterストレージプールの他のノードに一致1 TB から 4 TB[d]5 ミリ秒[e]
[a] ノード上の arbiter ブリックの数を組み合わせた容量によっては、RAM を増やす必要がある場合があります。
[b] arbiter およびデータブリックは、データと arbiter ブリックが異なるレプリカセットに属することであれば、同じデバイスに設定できます。Arbiter ボリュームのサイジングについての詳細は、「Arbiter 容量の要件」 を参照してください。
[c] これは、aribiter ノードに関係なくすべてのノード間の最大ラウンドトリップレイテンシー要件です。ノード間のレイテンシーを確認するには、KCS#413623 を参照してください。
[d] 1 つの RAIDed 物理デバイスに複数のブリックを作成できます。以下の製品ドキュメントを参照してください。 「ブリック設定」
[e] これは、aribiter ノードに関係なくすべてのノード間の最大ラウンドトリップレイテンシー要件です。ノード間のレイテンシーを確認するには、KCS#413623 を参照してください。
仮想マシンでの任意設定の要件は次のとおりです。
  • 最低 4 vCPU
  • 最低 16 GB RAM
  • 1 TB から 4 TB の仮想ディスク
  • 最大 5 ミリ秒レイテンシー

5.7.1.2. Arbiter 容量の要件

arbiter ブリックはファイル名とメタデータのみを保存するため、arbiter ブリックはボリュームまたはレプリカセット内の他のブリックよりもはるかに小さくすることができます。arbiter ブリックに必要なサイズは、ボリュームに格納されているファイルの数によって異なります。
推奨される最小 arbiter ブックサイズは、以下の式で計算できます。
minimum arbiter brick size = 4 KB * ( size in KB of largest data brick in volume or replica set / average file size in KB)
たとえば、2 つの 1 TB のデータブリックがあり、ファイルの平均サイズが 2 GB の場合は、以下の例のように arbiter ブリック 2 MB が最小サイズとして推奨されます。
minimum arbiter brick size  = 4 KB * ( 1 TB / 2 GB )
                            = 4 KB * ( 1000000000 KB / 2000000 KB )
                            = 4 KB * 500 KB
                            = 2000 KB
                            = 2 MB
シャードが有効で、shard-block-size が KB の平均ファイルサイズよりも小さい場合は、各シャードにもメタデータファイルが含まれるため、代わりに以下の式を使用する必要があります。
minimum arbiter brick size = 4 KB * ( size in KB of largest data brick in volume or replica set / shard block size in KB )
ボリュームに保存するファイルの数がわかる場合は、推奨される最小 Arbiter ブリックサイズは 4 KB のファイルの最大数になります。たとえば、ボリュームに 200,000 個ファイルを割り当てることが想定される場合は、Arbiter ブリックのサイズは 800,000 KB または 0.8 GB である必要があります。
また、Red Hat は、arbiter ブリックのサイズを増やす短期の必要性をなくすためにも、可能な場合はオーバープロビジョニングを推奨しています。また、maxpct の使用方法は、「 ブリック設定 」を参照してください。

5.7.2. 判別ロジック

判別ボリュームでは、ファイル操作が許可されているかは、ボリューム内のブリックの現在の状態によります。以下の表は、考えられるすべてのボリュームの状態での判別動作を示しています。

表5.2 現在のボリュームの状態に許可される操作

ボリュームの状態判別動作
すべてのブリックが利用可能ですすべてのファイル操作は許可されました。
arbiter および 1 データブリックが利用可能
arbiter が利用可能なデータノードに同意しない場合は、ENOTCONN で書き込み操作は失敗します (正しいブリックは利用できません)。他のファイル操作が許可されます。
arbiter のメタデータが利用可能なデータノードと合意している場合、すべてのファイル操作が許可されます。
Arbiter ダウン、データブリックが利用可能ですファイル操作がすべて許可されます。Arbiter の記録が利用可能になると修復されます。
利用可能なのは 1 つのブリックだけです。
すべてのファイル操作は ENOTCONN で失敗します。

5.7.3. Arbitrated Replicated ボリュームの作成

Arbitrated Replicated ボリュームを作成するコマンドの構文は以下のとおりです。
# gluster volume create VOLNAME replica 3 arbiter 1 HOST1:DATA_BRICK1 HOST2:DATA_BRICK2 HOST3:ARBITER_BRICK3
これにより、3 つの複製ブリックごとに 1 つの arbiter を持つボリュームが作成されます。arbiter は、3 つのブリックのセットのすべてのセットの最後のブリックです。
注記
このコマンドの構文は誤解を招く恐れがあります。このセットには、合計 3 つのブリックがあります。このコマンドは、全データを複製し、メタデータのみを複製する Arbiter ブックを 1 つ含むボリュームを作成します。
以下の例では、server3 および server6 のブリックは arbiter ブリックです。3 つのブリックのセットが複数提供されているため、arbiter ブリックを使用して分散複製ボリュームが作成されることに注意してください。
# gluster volume create testvol replica 3 arbiter 1 \
server1:/bricks/brick server2:/bricks/brick server3:/bricks/arbiter_brick \
server4:/bricks/brick server5:/bricks/brick server6:/bricks/arbiter_brick
# gluster volume info testvol
Volume Name: testvol
Type: Distributed-Replicate
Volume ID: ed9fa4d5-37f1-49bb-83c3-925e90fab1bc
Status: Created
Snapshot Count: 0
Number of Bricks: 2 x (2 + 1) = 6
Transport-type: tcp
Bricks:
Brick1: server1:/bricks/brick
Brick2: server2:/bricks/brick
Brick3: server3:/bricks/arbiter_brick (arbiter)
Brick1: server4:/bricks/brick
Brick2: server5:/bricks/brick
Brick3: server6:/bricks/arbiter_brick (arbiter)
Options Reconfigured:
cluster.granular-entry-heal: on
transport.address-family: inet
performance.readdir-ahead: on
nfs.disable: on

5.7.4. 複数の Arbitrated Replicated ボリュームの作成

複数の判別複製ボリュームを設定している場合、または複数のレプリカセットを持つ 1 つのボリュームを設定する場合は、以下のいずれかの手法を使用して合計ノードの数を減らすことができます。
  • 複数の Arbitrated Replicated ボリュームをチェーンします。これは、別のボリュームのデータブリックと同じノードの 1 つのボリュームに対して arbiter ブリックを配置して行います。チェーンは、メタデータのファイルサイズ (32 - 128 KiB から) に近くなる場合に書き込み負荷に便利です。これにより、1 つのディスクを経由するすべてのメタデータ I/O が回避されます。
    判別分散複製ボリュームでは、arbiter ブックを、別のレプリカサブボリュームのデータブリックと同じノードに配置することもできます。これらは同じデータを共有しないためです。
  • 1 つの専用ノードで、複数のボリュームから arbiter ブリックを配置します。専用の arbiter ノードは、大きなファイルを使用した書き込みの高ワークロードおよび読み取りの高ワークロードに適しています。

例5.6 専用設定の例

以下のコマンドは、firstvol と secondvol の 2 つの Arbitrated Replicated ボリュームを作成します。server3 には、両方のボリュームの arbiter ブリックが含まれます。
# gluster volume create firstvol replica 3 arbiter 1 server1:/bricks/brick server2:/bricks/brick server3:/bricks/arbiter_brick
# gluster volume create secondvol replica 3 arbiter 1 server4:/bricks/data_brick server5:/bricks/brick server3:/bricks/brick
専用の arbiter ノード設定
専用 arbiter ノード上の arbiter ブリックとともに、双方向 Arbitrated Replicated ボリュームを作成するために 5 台のサーバーにわたり設定された 2 つの gluster ボリューム。

例5.7 チェーン設定の例

以下のコマンドは、6 x (2 + 1) 設定の 6 台のサーバー間でチェーンされた 6 つのサブボリュームを持つ、Arbitrated Replicated ボリュームを設定します。
# gluster volume create arbrepvol replica 3 arbiter 1 server1:/bricks/brick1 server2:/bricks/brick1 server3:/bricks/arbiter_brick1 server2:/bricks/brick2 server3:/bricks/brick2 server4:/bricks/arbiter_brick2 server3:/bricks/brick3 server4:/bricks/brick3 server5:/bricks/arbiter_brick3 server4:/bricks/brick4 server5:/bricks/brick4 server6:/bricks/arbiter_brick4 server5:/bricks/brick5 server6:/bricks/brick5 server1:/bricks/arbiter_brick5 server6:/bricks/brick6 server1:/bricks/brick6 server2:/bricks/arbiter_brick6
6 x (2 + 1) Arbitrated Distributed-Replicated 設定
6 * (2 + 1) 判別分散複製設定を作成するための、6 台のサーバーにわたりチェーンされた 6 個の複製 gluster サブボリューム。

5.7.5. 判別ボリュームへの変換

複製されたボリュームを、複製された各サブボリュームに対して新しい arbiter ブリックを追加するか、レプリカブリックを arbiter ブリックに置き換えることで、複製されたボリュームに変換できます。

手順5.1 レプリカ 2 ボリュームの判別ボリュームへの変換

警告
geo レプリケーションが設定されている場合には、このプロセスを実行しないでください。Bug 1683893 で追跡されている競合状態があります。これは、geo レプリケーションが有効な場合にボリュームを変換する際にデータが失われます。
  1. 修復中ではないことを確認します。

    # gluster volume heal VOLNAME info
    保留中の修復エントリーが 0 になるまで待ってから続行します。
  2. 自己修復の無効化と停止

    以下のコマンドを実行して、データ、メタデータ、エントリー自己修復デーモン、および自己修復デーモンを無効にします。
    # gluster volume set VOLNAME cluster.data-self-heal off
    # gluster volume set VOLNAME cluster.metadata-self-heal off
    # gluster volume set VOLNAME cluster.entry-self-heal off
    # gluster volume set VOLNAME self-heal-daemon off
  3. ボリュームへの arbiter ブックの追加

    各複製サブボリュームに arbiter ブックを追加して、ボリュームを変換します。
    # gluster volume add-brick VOLNAME replica 3 arbiter 1 HOST:arbiter-brick-path
    たとえば、testvol と呼ばれる双方向で複製されたボリュームがあり、arbiter が使用する新しいブリックがある場合は、次のコマンドを使用して、ブリックを arbiter として追加できます。
    # gluster volume add-brick testvol replica 3 arbiter 1 server:/bricks/arbiter_brick
    既存の双方向分散型ボリュームがある場合、判別分散複製ボリュームに変換するには、各サブボリュームに新たなブリックが必要になります。以下に例を示します。
    # gluster volume add-brick testvol replica 3 arbiter 1 server1:/bricks/arbiter_brick1 server2:/bricks/arbiter_brick2
  4. クライアントの volfiles が更新するまで待ちます。

    これには約 5 分かかります。
  5. ブリックが正常に追加されたことを確認します。

    # gluster volume info VOLNAME
    # gluster volume status VOLNAME
  6. 自己修復を再度有効化

    以下のコマンドを実行して、サーバーで自己修復を再度有効にします。
    # gluster volume set VOLNAME cluster.data-self-heal on
    # gluster volume set VOLNAME cluster.metadata-self-heal on
    # gluster volume set VOLNAME cluster.entry-self-heal on
    # gluster volume set VOLNAME self-heal-daemon on
  7. すべてのエントリーが修復されていることを確認

    # gluster volume heal VOLNAME info
    保留中の秀句エントリーが 0 になるまで待機して、すべての修復が正常に実行されるようにします。

手順5.2 レプリカ 3 ボリュームの判別ボリュームへの変換

警告
geo レプリケーションが設定されている場合には、このプロセスを実行しないでください。Bug 1683893 で追跡されている競合状態があります。これは、geo レプリケーションが有効な場合にボリュームを変換する際にデータが失われます。
  1. 修復中ではないことを確認します。

    # gluster volume heal VOLNAME info
    保留中の修復エントリーが 0 になるまで待ってから続行します。
  2. ボリュームのレプリカ数を 2 に減らす

    レプリカ数が 2 に削減されるように、ボリュームのすべてのサブボリュームからブリックを削除します。たとえば、2 つのサブボリュームにデータを分散するレプリカ 3 ボリュームでは、以下のコマンドを実行します。
    # gluster volume remove-brick VOLNAME replica 2 HOST:subvol1-brick-path HOST:subvol2-brick-path force
    注記
    分散複製ボリュームでは、データはサブボリューム全体に分散され、サブボリュームのブリック全体に複製されます。つまり、ボリュームのレプリカ数を減らすには、すべてのサブボリュームからブリックを削除する必要があります。
    ブリックは、gluster ボリュームの情報出力で サブボリュームでグループ化されます。レプリカ数が 3 の場合は、最初の 3 つのブリックが最初のサブボリュームを形成し、次の 3 つのブリックは 2 番目のサブボリュームなどを形成します。
    # gluster volume info VOLNAME
    [...]
    Number of Bricks: 2 x 3 = 6
    Transport-type: tcp
    Bricks:
    Brick1: node1:/test1/brick
    Brick2: node2:/test2/brick
    Brick3: node3:/test3/brick
    Brick4: node1:/test4/brick
    Brick5: node2:/test5/brick
    Brick6: node3:/test6/brick
    [...]
    このボリュームでは、データは 2 つのサブボリュームに分散され、それぞれ 3 つのブリックで構成されます。最初のサブボリュームは、ブリック 1、2、および 3 で構成されます。2 つ目のサブボリュームは、ブリック 4、5、および 6 で構成されます。以下のコマンドを使用して各サブボリュームから 1 つのブリックを削除すると、必要に応じてレプリカ数を 2 に減らします。
    # gluster volume remove-brick VOLNAME replica 2 HOST:subvol1-brick-path HOST:subvol2-brick-path force
  3. 自己修復の無効化と停止

    以下のコマンドを実行して、データ、メタデータ、エントリー自己修復デーモン、および自己修復デーモンを無効にします。
    # gluster volume set VOLNAME cluster.data-self-heal off
    # gluster volume set VOLNAME cluster.metadata-self-heal off
    # gluster volume set VOLNAME cluster.entry-self-heal off
    # gluster volume set VOLNAME self-heal-daemon off
  4. ボリュームへの arbiter ブックの追加

    各複製サブボリュームに arbiter ブックを追加して、ボリュームを変換します。
    # gluster volume add-brick VOLNAME replica 3 arbiter 1 HOST:arbiter-brick-path
    たとえば、複製されたボリュームがある場合には、以下のコマンドを実行します。
    # gluster volume add-brick testvol replica 3 arbiter 1 server:/bricks/brick
    既存の分散複製のボリュームがある場合:
    # gluster volume add-brick testvol replica 3 arbiter 1 server1:/bricks/arbiter_brick1 server2:/bricks/arbiter_brick2
  5. クライアントの volfiles が更新するまで待ちます。

    これには約 5 分かかります。各クライアントで以下のコマンドを実行して、これが完了したことを確認します。
    # grep -ir connected mount-path/.meta/graphs/active/volname-client-*/private
    出力で connected=1 に表示される回数は、クライアントに接続されたブリックの数になります。
  6. ブリックが正常に追加されたことを確認します。

    # gluster volume info VOLNAME
    # gluster volume status VOLNAME
  7. 自己修復を再度有効化

    以下のコマンドを実行して、サーバーで自己修復を再度有効にします。
    # gluster volume set VOLNAME cluster.data-self-heal on
    # gluster volume set VOLNAME cluster.metadata-self-heal on
    # gluster volume set VOLNAME cluster.entry-self-heal on
    # gluster volume set VOLNAME self-heal-daemon on
  8. すべてのエントリーが修復されていることを確認

    # gluster volume heal VOLNAME info
    保留中の秀句エントリーが 0 になるまで待機して、すべての修復が正常に実行されるようにします。

5.7.6. 判別ボリュームを 3 方向の複製ボリュームに変換

判別ボリュームを、3 方向の複製ボリューム、または 3 方向の複製複製ボリュームに変換することができます。そのためには、複製された各サブボリュームの完全なブリックに arbiter ブリックを置き換えます。
警告
geo レプリケーションが設定されている場合には、このプロセスを実行しないでください。Bug 1683893 で追跡されている競合状態があります。これは、geo レプリケーションが有効な場合にボリュームを変換する際にデータが失われます。

手順5.3 レプリカ 3 ボリュームへの判別ボリュームの変換

  1. 修復中ではないことを確認します。

    # gluster volume heal VOLNAME info
    保留中の修復エントリーが 0 になるまで待ってから続行します。
  2. ボリュームからの arbiter ブックの削除

    どのブリックが (arbiter) と一覧表示されているかを確認し、ボリュームからそのブリックを削除します。
    # gluster volume info VOLNAME
    # gluster volume remove-brick VOLNAME replica 2 HOST:arbiter-brick-path force
  3. 自己修復の無効化と停止

    以下のコマンドを実行して、データ、メタデータ、エントリー自己修復デーモン、および自己修復デーモンを無効にします。
    # gluster volume set VOLNAME cluster.data-self-heal off
    # gluster volume set VOLNAME cluster.metadata-self-heal off
    # gluster volume set VOLNAME cluster.entry-self-heal off
    # gluster volume set VOLNAME self-heal-daemon off
  4. ボリュームへの完全なブリックの追加

    複製した各サブボリュームにブリックを追加して、ボリュームを変換します。
    # gluster volume add-brick VOLNAME replica 3 HOST:brick-path
    たとえば、既存の Arbitrated Replicated ボリュームがある場合には、以下のコマンドを実行します。
    # gluster volume add-brick testvol replica 3 server:/bricks/brick
    既存の判別分散複製ボリュームがある場合は、以下を実行します。
    # gluster volume add-brick testvol replica 3 server1:/bricks/brick1 server2:/bricks/brick2
  5. クライアントの volfiles が更新するまで待ちます。

    これには約 5 分かかります。
  6. ブリックが正常に追加されたことを確認します。

    # gluster volume info VOLNAME
    # gluster volume status VOLNAME
  7. 自己修復を再度有効化

    以下のコマンドを実行して、サーバーで自己修復を再度有効にします。
    # gluster volume set VOLNAME cluster.data-self-heal on
    # gluster volume set VOLNAME cluster.metadata-self-heal on
    # gluster volume set VOLNAME cluster.entry-self-heal on
    # gluster volume set VOLNAME self-heal-daemon on
  8. すべてのエントリーが修復されていることを確認

    # gluster volume heal VOLNAME info
    保留中の秀句エントリーが 0 になるまで待機して、すべての修復が正常に実行されるようにします。

5.7.7. 判別ボリュームの推奨事項の調整

判別ボリュームが使用されている場合は、Red Hat は以下を推奨します。
  • 専用の判別ノードの場合は、arbiter ブリックに JBOD を、データブリックには RAID6 を使用します。
  • チェーンの arbiter ボリュームの場合は、データおよび判別ブリックの両方に同じ RAID6 ドライブを使用します。
Arbiter ボリュームの使用に固有のパフォーマンスの強化に関する詳細は、19章パフォーマンスチューニング を参照してください。

5.8. 分散ボリュームの作成

分散ボリュームは、イレイジャーコーディングに基づいています。イレイジャーコーディング (EC) はデータ保護の手段で、データをフラグメントに分割し、冗長データで拡張およびエンコードして、複数の異なる場所に格納します。これにより、障害発生時に、1 つ以上のブリックに保存されているデータを復旧できます。データの損失なしに失敗する可能性のあるブリックの数は、冗長性数を設定することで設定されます。
分散ボリュームでは、複製ボリュームと比較してストレージ領域の使用量が少なくなります。これは、サイズが 2 の複製プールと同じですが、冗長性レベルが 2 に設定されている場合に 1 TB ではなく 1.5 TB が必要です。分散ボリュームでは、各ブリックはデータおよびパリティーまたは冗長性の一部を保存します。分散されるボリュームは、冗長性レベルに基づいてデータの損失を持続します。
重要
分散されるボリューム構成は、JBOD ストレージでのみサポートされます。詳細は、「JBOD」 を参照してください。

図5.4 障害の発生したボリューム図

障害の発生したボリューム図
イレイジャーコーディングが提供するデータ保護は、n = k + m という式で簡単に表示できます。ここで、n は ブリックの合計数です。復旧するには、任意の k ブリックを n ブリックから必要とします。つまり、障害を任意の m ブリックまで許容できます。今回のリリースで、以下の設定がサポートされるようになりました。
  • 冗長性レベル 2 (4 + 2) の 6 ブリック
  • 冗長性レベル 2 (8 + 2) の 10 ブリック
  • 冗長性レベル 3 (8 + 3) の 11 ブリック
  • 冗長性レベル 4 (8 + 4) の 12 ブリック
  • 冗長性レベル 4 (16 + 4) の 20 ブリック
フォールトトレランスを最適化するには、個別のサーバーに各ブリックを作成します。1 台のサーバーで複数のブリックを作成できますが、1 台のサーバーでのブリックの数が多いほど、1 台のサーバーが利用できなくなった場合に可用性と一貫性のリスクが高まります。
Gluster ボリュームを作成して異なるタイプのボリュームを作成しgluster ボリュームの情報を使用して、 ボリュームの作成に成功したことを確認します。
前提条件
重要
Red Hat は、Dispersed ボリュームを作成する前に、「分散ボリュームの作成」 で説明しているボリューム設定に関する推奨事項を確認することを推奨します。
分散ボリュームの作成
  1. gluster volume create コマンドを実行して、破棄されたボリュームを作成します。
    構文は # gluster volume create NEW-VOLNAME [disperse-data COUNT] [redundancy COUNT] [transport tcp | rdma(Deprecated)| tcp,rdma] NEW-BRICK.. です。
    ディスパースボリュームの作成に必要なブリック数は、ディスパースのデータ数と 冗長性 の合計です。
    disperse-data count オプションは、分散するブリック数を除く、分散ボリュームの一部であるブリック数を指定します。たとえば、ブリックの合計数が 6 で、redundancy -count が 2 の場合、分散データ数は 4(6 - 2 = 4)になります。disperse -data count オプションが指定されず、 冗長性 count オプションのみを指定すると、指定したブリックの合計数を排除して、分散データ数が自動的に計算されます
    冗長性により、ボリュームの操作を中断することなく、失われたブリックの数を決定します。冗長性数 が指定されていない場合は、設定をもとに自動的に最適な値に計算され、警告メッセージが表示されます。
    transport のデフォルト値は tcp です。auth. allow や auth. reject などの他のオプションを渡すことができます。パラメーターの全一覧は、「暗号化したディスクについて」 を参照してください。

    例5.8 6 台のストレージサーバーを使用した分散ボリューム

    # gluster v create glustervol disperse-data 4 redundancy 2 transport tcp server1:/rhgs1/brick1 server2:/rhgs2/brick2 server3:/rhgs3/brick3 server4:/rhgs4/brick4 server5:/rhgs5/brick5 server6:/rhgs6/brick6
    volume create: glutervol: success: please start the volume to access data
  2. # gluster volume start VOLNAME を実行してボリュームを起動します。
    # gluster v start glustervol
    volume start: glustervol: success
    重要
    open-behind ボリュームオプションは、デフォルトで有効になっています。SMB プロトコルを使用して分散されたボリュームにアクセスする場合、大きなファイルワークロードでパフォーマンスのボトルネックを防ぐために、open-behind ボリュームオプションを無効にする必要があります。以下のコマンドを実行して、open-behind ボリュームオプション を無効にします。
    # gluster volume set VOLNAME open-behind off
    open-behind ボリュームオプションの詳細は、を参照してください。 「ボリュームオプションの設定」
  3. Gluster ボリューム情報 コマンドを実行して、必要に応じてボリューム情報を表示します。

5.9. Distributed Dispersed ボリュームの作成

Distributed Dispersed ボリュームは、分散されるボリュームと同じイレイジャーコーディングの構成をサポートします。Distributed Dispersed ボリューム内のブリックの数は、(K+M) の倍数でなければなりません。今回のリリースで、以下の設定がサポートされるようになりました。
  • 冗長性レベル 2 の 6 つのブリックを含む複数の分散セット
  • 冗長性レベル 2 の 10 個のブリックを含む複数の分散セット
  • 冗長性レベル 3 の 11 個のブリックを含む複数の分散セット
  • 冗長性レベル 4 の 12 個のブリックを含む複数の分散セット
  • 冗長性レベル 4 の 20 個ブリックを含む複数の分散セット
重要
Distributed Dispersed ボリューム構成は、JBOD ストレージでのみサポートされます。詳細は、「JBOD」 を参照してください。
Gluster ボリュームを作成して異なるタイプのボリュームを作成しgluster ボリュームの情報を使用して、 ボリュームの作成に成功したことを確認します。
前提条件

図5.5 Distributed Dispersed ボリュームの図

Distributed Dispersed ボリュームの図
Distributed Dispersed ボリュームの作成
重要
Red Hat は、分散されていないボリュームを作成する前に、「推奨される設定: 障害の発生したボリューム」 に記載の分散ボリューム設定に関する推奨事項を確認することを推奨します。
  1. gluster volume create コマンドを実行して、破棄されたボリュームを作成します。
    構文は # gluster volume create NEW-VOLNAME disperse-data COUNT [redundancy COUNT] [transport tcp | rdma(Deprecated)| tcp,rdma] NEW-BRICK.です。
    transport のデフォルト値は tcp です。auth. allow や auth. reject などの他のオプションを渡すことができます。パラメーターの全一覧は、「ボリュームオプションの設定」 を参照してください。

    例5.9 6 台のストレージサーバーを使用した Distributed Dispersed Volume

    # gluster v create glustervol disperse-data 4 redundancy 2 transport tcp server1:/rhgs1/brick1 server2:/rhgs2/brick2 server3:/rhgs3/brick3 server4:/rhgs4/brick4 server5:/rhgs5/brick5 server6:/rhgs6/brick6 server1:/rhgs7/brick7 server2:/rhgs8/brick8 server3:/rhgs9/brick9 server4:/rhgs10/brick10 server5:/rhgs11/brick11 server6:/rhgs12/brick12
    volume create: glutervol: success: please start the volume to access data.
    上記の例は、図5.4「障害の発生したボリューム図」 で説明されています。例と例では、6 台のサーバーから 12 個のブリックを作成します。
  2. # gluster volume start VOLNAME を実行してボリュームを起動します。
    # gluster v start glustervol
    volume start: glustervol: success
    重要
    open-behind ボリュームオプションは、デフォルトで有効になっています。SMB プロトコルを使用して分散されたボリュームにアクセスする場合は、大きなファイルワークロードでパフォーマンスのボトルネックを防ぐために、open-behind ボリュームオプションを無効にする必要があります。以下のコマンドを実行して、open-behind ボリュームオプション を無効にします。
    # gluster volume set VOLNAME open-behind off
    open-behind ボリュームオプションの詳細は、を参照してください。 「ボリュームオプションの設定」
  3. Gluster ボリューム情報 コマンドを実行して、必要に応じてボリューム情報を表示します。

5.10. ボリュームの起動

ボリュームは、マウントされる前に起動する必要があります。
ボリュームを起動するには 、# gluster volume start VOLNAMEを実行します。
たとえば、test-volume を起動するには、以下を実行します。
# gluster v start glustervol
volume start: glustervol: success

第6章 ボリュームへのアクセスの作成

警告
Red Hat Gluster Storage 3.4 以前を使用するクライアントを使用するボリュームで、storage.fips-mode-rchecksum ボリュームオプションを有効にしないでください。
Red Hat Gluster Storage ボリュームは、さまざまな技術を使用してアクセスできます。

6.1. クライアントサポート情報

6.1.1. クロスプロトコルデータアクセス

ロックセマンティクスの違いにより、1 つの Red Hat Gluster Storage ボリュームには複数のプロトコルによる同時アクセスができません。同時アクセスに対する現在のサポートは、以下の表で定義されています。

表6.1 クロスプロトコルデータアクセスマトリックス

  SMB Gluster NFS NFS-Ganesha ネイティブ FUSE オブジェクト
SMB Yes いいえ いいえ いいえ No
Gluster NFS(非推奨) No はい いいえ いいえ No
NFS-Ganesha No いいえ はい いいえ No
ネイティブ FUSE No いいえ いいえ Yes Yes [a]

6.1.2. クライアントオペレーティングシステムのプロトコルサポート

以下の表は、サポートされているクライアントオペレーティングシステム内の各ファイルアクセスプロトコルのサポートレベルを示しています。

表6.2 クライアント OS プロトコルのサポート

クライアント OSFUSEGluster NFSNFS-GaneshaSMB
RHEL 5サポート対象外サポート対象外サポート対象外サポート対象外
RHEL 6サポートされています。RDMA (非推奨)サポート対象外サポートされています。
RHEL 7サポートされています。RDMA (非推奨)サポートされています。サポートされています。
RHEL 8サポートされています。サポート対象外サポートされています。サポートされています。
Windows Server 2008、2012、2016サポート対象外サポート対象外サポート対象外サポートされています。
Windows 7、8、10サポート対象外サポート対象外サポート対象外サポートされています。
Mac OS 10.15サポート対象外サポート対象外サポート対象外サポートされています。

6.1.3. トランスポートプロトコルのサポート

以下の表は、TCP/RDMA で対応しているアクセスプロトコルのサポートマトリックスを示しています。

表6.3 トランスポートプロトコルのサポート

アクセスプロトコル TCP RDMA(非推奨)
FUSEYes Yes
SMB Yes No
NFSYesYes
警告
RDMA をトランスポートプロトコルとして使用することは、Red Hat Gluster Storage 3.5 で非推奨となっています。Red Hat ではこの使用を推奨しておらず、Red Hat Gluster Storage 3.5.3 にアップグレードする新規デプロイメントおよび既存デプロイメントでサポートしません。
重要
Red Hat Gluster Storage では、特定のポートを開く必要があります。ファイアウォール設定が 3章Red Hat Gluster Storage に関する考慮事項 に記載されているポートへのアクセスを許可することを確認する必要があります。
Gluster ユーザーは、gluster インストールの一部として作成されます。gluster ユーザーの目的は、libgfapi ベースのアプリケーション (例: nfs-ganesha および glusterfs-coreutils) への特権アクセスを提供することです。アプリケーションの通常のユーザーの場合は、statedump ディレクトリーへの書き込みアクセスは制限されます。その結果、このディレクトリーに状態ダンプの書き込みを試みると失敗します。statedump ディレクトリーに書き込みできるようにするには、これらのアプリケーションで権限のあるアクセスが必要です。この場所に書き込むには、アプリケーションを実行するユーザーが gluster ユーザーグループに追加されていることを確認する必要があります。アプリケーションを追加したら、gluster プロセスを再起動して新しいグループを適用します。

6.2. ネイティブクライアント

ネイティブクライアントは、ユーザー空間で実行している FUSE ベースのクライアントです。高いレベルの同時実行性と書き込みパフォーマンスが必要な場合に、ネイティブクライアントを使用して Red Hat Gluster Storage ボリュームにアクセスすることが推奨されます。
本セクションでは、ネイティブクライアントを紹介し、以下を行う方法を説明します。
  • ネイティブクライアントパッケージのインストール
  • Red Hat Gluster Storage ボリュームのマウント (手動および自動)
  • Gluster Storage ボリュームが正常にマウントされていることを確認します。

表6.4 Red Hat Gluster Storage のサポートマトリックス

Red Hat Enterprise Linux のバージョン Red Hat Gluster Storage のバージョン ネイティブクライアントバージョン
6.5 3.0 3.0, 2.1*
6.6 3.0.2、3.0.3、3.0.4 3.0, 2.1*
6.73.1、3.1.1、3.1.23.1, 3.0, 2.1*
6.83.1.33.1.3
6.93.23.2, 3.1.3*
6.93.33.3, 3.2
6.93.3.13.3.1, 3.3, 3.2
6.103.43.5*、3.4、3.3.z
7.13.1、3.1.13.1.1, 3.1, 3.0
7.23.1.23.1.2, 3.1, 3.0
7.23.1.33.1.3
7.33.23.2, 3.1.3
7.43.23.2, 3.1.3
7.43.33.3, 3.2
7.43.3.13.3.1, 3.3, 3.2
7.53.3.1、3.43.3.z, 3.4.z
7.63.3.1、3.43.3.z, 3.4.z
7.73.5.13.4.z, 3.5.z
7.83.5.23.4.z, 3.5.z
7.93.5.3, 3.5.43.4.z, 3.5.z
8.1NA3.5
8.23.5.23.5.z
8.33.5.33.5.z
8.43.5.43.5.z
警告
Red Hat Gluster Storage 3.5 は、ネイティブクライアント 3.5 を使用する RHEL 6.x をサポートします。
警告
  • Red Hat Gluster Storage 3.5 の場合、Red Hat は Red Hat Gluster Storage 3.4 および 3.5 クライアントのみをサポートします。
リリースバージョンの詳細は、https://access.redhat.com/solutions/543123 を参照してください。

6.2.1. ネイティブクライアントのインストール

クライアントオペレーティングシステムのインストール後に、ターゲットシステムを Red Hat Network に登録し、Red Hat Enterprise Linux Server チャンネルにサブスクライブします。Red Hat Subscription Management にシステムを登録してサブスクライブする方法は 2 つあります。
  • コマンドラインを使用した、システムの Red Hat Subscription Management への登録およびサブスクライブ
  • Web Interface を使用した、システムの Red Hat Subscription Management への登録およびサブスクライブ
重要
すべてのクライアントが同じバージョンである必要があります。Red Hat は、クライアントをアップグレードする前にサーバーをアップグレードすることを強く推奨します。
注記
Red Hat Gluster Storage サーバーは、サーバーバージョンとネイティブクライアントの以前のバージョンと同じネイティブクライアントのバージョンをサポートします。リリースの一覧は、https://access.redhat.com/solutions/543123 を参照してください。

コマンドラインを使用した、システムの Red Hat Subscription Management への登録およびサブスクライブ

コマンドラインでシステムを登録し、正しいリポジトリーにサブスクライブします。

前提条件

  • Red Hat Gluster Storage エンタイトルメントのある Red Hat Subscription Manager アカウントのユーザー名およびパスワードを把握します。
  1. subscription-manager register コマンドを実行して、利用可能なプールを一覧表示します。適切なプールを選択し、Red Hat Subscription Manager のユーザー名とパスワードを入力して、システムを Red Hat Subscription Manager に登録します。
    # subscription-manager register
  2. クライアントに応じて、以下のコマンドのいずれかを実行して正しいリポジトリーにサブスクライブします。
    • Red Hat Enterprise Linux 8 クライアントの場合:
      # subscription-manager repos --enable=rh-gluster-3-client-for-rhel-8-x86_64-rpms
    • Red Hat Enterprise Linux 7.x クライアントの場合:
      # subscription-manager repos --enable=rhel-7-server-rpms --enable=rh-gluster-3-client-for-rhel-7-server-rpms
      注記
      以下のコマンドも使用できますが、Red Hat Gluster Storage では今後のリリースでこのリポジトリーのサポートが非推奨になる可能性があります。
      # subscription-manager repos --enable=rhel-7-server-rh-common-rpms
    • Red Hat Enterprise Linux 6.1 以降のクライアントの場合:
      # subscription-manager repos --enable=rhel-6-server-rpms --enable=rhel-6-server-rhs-client-1-rpms
    サブスクリプションの詳細は、「『Using and Configuring Red Hat Subscription Management』」の「Section 3.1 Registering and attaching a system from the Command Line」を参照してください。
  3. システムが、必要なリポジトリーにサブスクライブされていることを確認します。
    # yum repolist

Web Interface を使用した、システムの Red Hat Subscription Management への登録およびサブスクライブ

Web インターフェースを使用してシステムを登録し、正しいチャンネルにサブスクライブします。

前提条件

  • Red Hat Gluster Storage エンタイトルメントのある Red Hat Subsrciption Management (RHSM) アカウントのユーザー名およびパスワードを把握します。
  1. Red Hat Subscription Management (https://access.redhat.com/management) にログオンします。
  2. 画面上部の Systems リンクをクリックします。
  3. Red Hat Gluster Storage Native Client チャンネルを追加する必要のあるシステムの名前をクリックします。
  4. 画面の Subscribed Channels セクションで Alter Channel Subscriptions をクリックします。
  5. クライアントプラットフォームに応じて、Red Hat Enterprise Linux 7 for x86_64 または x86_64 または Red Hat Enterprise Linux 5 for x86_64 のノードを展開します。
  6. Change Subscriptions ボタンをクリックし、変更を確定します。
    ページの更新時に Details タブを選択して、システムが適切なチャンネルにサブスクライブされていることを確認します。

ネイティブクライアントパッケージのインストール

Red Hat Network からのネイティブクライアントパッケージのインストール
  1. yum install コマンドを実行して、ネイティブクライアントの RPM パッケージをインストールします。
    # yum install glusterfs glusterfs-fuse
  2. Red Hat Enterprise 5.x クライアントシステムの場合は、modprobe コマンドを実行して、Red Hat Gluster Storage ボリュームをマウントする前に FUSE モジュールをロードします。
    # modprobe fuse
    起動時にモジュールの読み込みの詳細は、https://access.redhat.com/knowledge/solutions/47028 を参照してください。

6.2.2. ネイティブクライアントのアップグレード

Native Client を更新する前に、に記載のチャネルにクライアントをサブスクライブします。 「ネイティブクライアントのインストール」
  1. gluster ボリュームをアンマウントします。

    ネイティブクライアントをアップグレードする前に、gluster ボリュームをアンマウントします。
    # umount /mnt/glusterfs
  2. クライアントをアップグレードします。

    yum update コマンドを実行して、ネイティブクライアントをアップグレードします。
    # yum update glusterfs glusterfs-fuse
  3. gluster ボリュームを再マウントします。

    「Red Hat Gluster Storage ボリュームのマウント」 の説明に従って、ボリュームの再マウントを行います。

6.2.3. Red Hat Gluster Storage ボリュームのマウント

ネイティブクライアントをインストールした後に、データにアクセスするために Red Hat Gluster Storage ボリュームがマウントされている必要があります。以下の 3 つの方法を使用できます。
ボリュームをマウントしたら、「マウントしたボリュームのテスト」 に記載されている手順でマウントされたボリュームをテストします。
注記
  • クライアントは、サーバーと同じバージョンで、少なくともサーバーのバージョンが 1 つ前のバージョンである必要があります。Red Hat Gluster Storage 3.5 では、推奨されるネイティブクライアントバージョンは 3.4.z および 3.5 である必要があります。その他のバージョンについては、「ネイティブクライアント」 を参照してください。
  • ボリュームの作成時に選択されるサーバー名は、クライアントマシンで解決できる必要があります。適切な /etc/hosts エントリーまたは DNS サーバーを使用して、サーバー名を IP アドレスに解決します。
  • インターネットプロトコルバージョン 6 (IPv6) のサポートは、Red Hat Hyperconverged Infrastructure for Virtualization 環境でのみ利用でき、Red Hat Gluster Storage スタンドアロン環境では使用できません。

6.2.3.1. マウントコマンドとオプション

mount -t glusterfs コマンドを使用する場合は、以下のオプションを使用できます。すべてのオプションはコンマで区切る必要があります。
# mount -t glusterfs -o backup-volfile-servers=volfile_server2:volfile_server3:.... ..:volfile_serverN,transport-type tcp,log-level=WARNING,reader-thread-count=2,log-file=/var/log/gluster.log server1:/test-volume /mnt/glusterfs
backup-volfile-servers=<volfile_server2>:<volfile_server3>:...:<volfile_serverN>
クライアントをマウントするバックアップ volfile サーバーの一覧。このオプションが Fuse クライアントのマウント時に指定すると、最初の volfile サーバーが失敗したときに、mount が正常に実行されるまで、backup-volfile-servers オプションで指定したサーバーは volfile サーバーとして使用され、クライアントをマウントします。
注記
このオプションは、以前は、無効になった backupvolfile-server として指定されています。
ログレベル
log-file で指定されるレベル以上の重大度メッセージのみをログに記録します。
log-file
指定のファイルにメッセージをログに記録します。
transport-type
FUSE クライアントがブリックとの通信に使用する必要なトランスポートタイプを指定します。ボリュームがトランスポートタイプが 1 つのみで作成された場合は、値の指定がない場合のデフォルトになります。tcp,rdma ボリュームの場合、tcp はデフォルトです。
dump-fuse
このマウントオプションは、glusterfs クライアント (fuse ユーザー空間サーバー) とカーネル間の Fuse トラフィックのダンプを作成します。glusterfs ボリュームをマウントするインターフェースは、CLI からの標準の mount(8) コマンドです。この機能は、マウントオプションでも有効になります。
# mount -t glusterfs -odump-fuse=filename hostname:/volname mount-path
以下に例を示します。
# mount -t glusterfs -odump-fuse=/dumpfile  10.70.43.18:/arbiter /mnt/arbiter
上記のコマンドは、dumpfile という名前のバイナリーファイルを生成します。
注記
fusedump は時間が長くなり、特にクライアントが負荷が大きい場合などです。そのため、これは通常の使用時に fusedump を実行するための意図されたユースケースではありません。これを使用して、診断目的で、特定のシナリオからダンプを取得することが推奨されます。
ダンプを停止するには、fusedump オプションを指定せずにボリュームをアンマウントおよび再マウントする必要があります。
ro
読み取り専用パーミッションでファイルシステムをマウントします。
acl
マウント時に POSIX アクセス制御リストを有効にします。詳細は、「マウントされたボリュームでの ACL 有効化の確認」 を参照してください。
background-qlen=n
FUSE が、後続のリクエストが拒否される前に、キューされる要求数 n を処理できるようにします。n のデフォルト値は 64 です。
enable-ino32
ファイルシステムが、64 ビットの inode の代わりに 32 ビットの inode を提示できるようにします。
reader-thread-count=n
FUSE が、I/O パフォーマンスが向上する可能性のあるリーダースレッドを n 個追加できるようにします。n のデフォルト値は 1 です。
lru-limit
この mount コマンドオプションは、inode の制限に達した後に、最近使用された(lru)の一覧から inode を消去します。
以下に例を示します。
# mount -olru-limit=NNNN -t glusterfs hostname:/volname /mnt/mountdir
NNNN は、正の整数です。NNNN のデフォルト値は 128k (131072) で、推奨される値は 20000 以上です。0lru-limit として指定すると、lru-list からの inode の無効化がないことを意味します。

6.2.3.2. ボリュームの手動マウント

Red Hat Gluster Storage ボリュームまたはサブディレクトリーの手動マウント

マウントポイントを作成し、必要に応じて以下のコマンドを実行します。
Red Hat Gluster Storage ボリュームの場合
mount -t glusterfs HOSTNAME|IPADDRESS:/VOLNAME /MOUNTDIR
Red Hat Gluster Storage ボリュームのサブディレクトリーの場合
mount -t glusterfs HOSTNAME|IPADDRESS:/VOLNAME/SUBDIRECTORY /MOUNTDIR
注記
mount コマンドで指定したサーバーは、ボリューム名を記述する glusterFS 設定 volfile の取得に使用されます。その後、クライアントは volfile で説明しているサーバーと直接通信します (マウントに使用されるサーバーには実際に含まれない場合があります)。
  1. ボリュームにマウントポイントが作成されていない場合は、mkdir コマンドを実行してマウントポイントを作成します。
    # mkdir /mnt/glusterfs
  2. タスクサマリーの鍵をガイドとして使用し、mount -t glusterfs コマンドを実行します。
    1. Red Hat Gluster Storage ボリュームの場合:
      # mount -t glusterfs server1:/test-volume /mnt/glusterfs
    2. Red Hat Gluster Storage ボリュームのサブディレクトリーの場合
      # mount -t glusterfs server1:/test-volume/sub-dir /mnt/glusterfs

6.2.3.3. ボリュームの自動マウント

ボリュームは、システムが起動するたびに自動的にマウントできます。
mount コマンドで指定したサーバーは、ボリューム名を記述する glusterFS 設定 volfile の取得に使用されます。その後、クライアントは volfile で説明しているサーバーと直接通信します (マウントに使用されるサーバーには実際に含まれない場合があります)。
ボリュームの自動マウント
サーバーの起動時に自動的に Red Hat Gluster Storage ボリュームをマウントします。
  1. テキストエディターで /etc/fstab ファイルを開きます。
  2. fstab ファイルに以下の設定を追加します。
    Red Hat Gluster Storage ボリュームの場合
    HOSTNAME|IPADDRESS:/VOLNAME /MOUNTDIR glusterfs defaults,_netdev 0 0
    Red Hat Gluster Storage ボリュームのサブディレクトリーの場合
    HOSTNAME|IPADDRESS:/VOLNAME/SUBDIRECTORY /MOUNTDIR glusterfs defaults,_netdev 0 0
    上記のサーバー名例を使用すると、エントリーには以下の置換値が含まれます。
    server1:/test-volume /mnt/glusterfs glusterfs defaults,_netdev 0 0
    または
    server1:/test-volume/subdir /mnt/glusterfs glusterfs defaults,_netdev 0 0
    トランスポートタイプを指定する場合は、以下の例を確認してください。
    server1:/test-volume /mnt/glusterfs glusterfs defaults,_netdev,transport=tcp 0 0
    または
    server1:/test-volume/sub-dir /mnt/glusterfs glusterfs defaults,_netdev,transport=tcp 0 0

6.2.3.4. Native Client を使用したサブディレクトリーの手動マウント

Red Hat Gluster Storage 3.x では、単一の Gluster ボリュームを異なるクライアントと共有でき、それらはすべて、ボリューム名前空間のサブセットのみをマウントできます。この機能は、すでにエクスポートされているボリュームのサブディレクトリーをエクスポートできる NFS サブディレクトリーマウント機能と似ています。この機能を使用して、特定のボリュームへの完全アクセスを制限することもできます。
サブディレクトリーをマウントすると、以下の利点があります。
  • また、名前空間分離も提供します。そのため、複数のユーザーが他のユーザーと名前空間の競合のリスクを生じさせることなくストレージにアクセスできます。
  • マウントに障害が発生した場合に、root ファイルシステムが満杯にならないようにします。
以下のいずれかのコマンドを実行すると、ネイティブクライアントを使用してサブディレクトリーをマウントできます。
# mount -t glusterfs hostname:/volname/subdir /mount-point
または
# mount -t glusterfs hostname:/volname -osubdir-mount=subdir /mount-point
以下に例を示します。
# gluster volume set test-vol auth.allow "/(192.168.10.*|192.168.11.*),/subdir1(192.168.1.*),/subdir2(192.168.8.*)”
上記の例では、以下のようになります。
  • auth.allow オプションは、auth .allow オプションの値として指定されたディレクトリーのみのマウントを許可します。
  • auth-allow の各グループはコンマ (,) で区切られます。
  • 各グループには、有効な IP アドレスを含む括弧 () で区切られたディレクトリーがあります。
  • すべてのサブディレクトリーは / で始まります。つまりボリュームへの相対パスではありませんが、すべてが絶対パスで、ボリュームのルートディレクトリーとして / を取得します。
注記
デフォルトでは、認証は * で、ボリュームの指定のサブディレクトリーはすべてのクライアントがマウントできます。

6.2.3.5. マウントしたボリュームのテスト

マウントした Red Hat Gluster Storage ボリュームのテスト

コマンドラインで、Red Hat Gluster Storage ボリュームが正常にマウントされていることを確認します。3 つのコマンドはすべて、一覧表示された順序で実行することが可能です。あるいは、ボリュームが正常にマウントされたことを確認するために独立して実行できます。
  1. mount コマンドを実行して、ボリュームが正常にマウントされたかどうかを確認します。
    # mount
    server1:/test-volume on /mnt/glusterfs type fuse.glusterfs(rw,allow_other,default_permissions,max_read=131072
    OR
    # mount
    server1:/test-volume/sub-dir on /mnt/glusterfs type fuse.glusterfs(rw,allow_other,default_permissions,max_read=131072
    ボリュームのマウント中に transport オプションを指定すると、マウントステータスにトランスポートタイプがボリューム名に追加されます。たとえば transport=tcp の場合は以下のようになります。
    # mount
    server1:/test-volume.tcp on /mnt/glusterfs type fuse.glusterfs(rw,allow_other,default_permissions,max_read=131072
    OR
    # mount
    server1:/test-volume/sub-dir.tcp on /mnt/glusterfs type fuse.glusterfs(rw,allow_other,default_permissions,max_read=131072
  2. df コマンドを実行して、ボリュームのすべてのブリックから集約されたストレージ領域を表示します。
    # df -h /mnt/glusterfs
    Filesystem           Size  Used  Avail  Use%  Mounted on
    server1:/test-volume  28T  22T   5.4T   82%   /mnt/glusterfs
  3. cd コマンドを使用してマウントディレクトリーに移動し、コンテンツを一覧表示します。
    # cd /mnt/glusterfs
    # ls

6.3. NFS

Red Hat Gluster Storage には、Gluster NFS と NFS-Ganesha の 2 つの NFS サーバー実装があります。Gluster NFS は NFSv3 プロトコルのみをサポートしますが、NFS-Ganesha は NFSv3 プロトコルおよび NFSv4 プロトコルに対応します。

6.3.1. サポートマトリックス

以下の表には、Red Hat Gluster Storage 3.1 以降の NFS サポートの機能マトリクスが含まれます。

表6.5 NFS サポートマトリックス

機能 glusterFS NFS (NFSv3) NFS-Ganesha (NFSv3) NFS-Ganesha (NFSv4)
Root-squash Yes はい Yes
All-squash Noはい Yes
サブディレクトリーのエクスポートYes はい Yes
ロックYes はい Yes
クライアントベースのエクスポートパーミッションYes はい Yes
NetgroupsYesはいYes
マウントプロトコルUDP、TCPUDP、TCPTCP のみ
NFS トランスポートプロトコルTCPUDP、TCPTCP
AUTH_UNIXYesはいYes
AUTH_NONEYesはいYes
AUTH_KRBNoはいYes
ACLYesいいえYes
委譲該当なし該当なしNo
高可用性Yes (特定の制限付き。詳細は、「Setting up CTDB for NFS」を参照してください)YesYes
マルチヘッドYesはいYes
Gluster RDMA ボリュームYesサポート対象外サポート対象外
DRCサポート対象外YesYes
動的エクスポートNoはいYes
pseudofs該当なし該当なしYes
NFSv4.1該当なし該当なしYes
注記
  • Red Hat では、kernel-NFS や Gluster NFS サーバーなど、他の NFS サーバーと NFS-Ganesha を実行することは推奨していません。
  • 指定のマシン/ホスト上で NFS-Ganesha、gluster-NFS、または kernel-NFS サーバーのうち 1 台のみを有効にすることができます。これは、すべての NFS 実装がポート 2049 を使用し、特定の時点でアクティブにすることができるためです。したがって、NFS-Ganesha を起動する前に kernel-NFS を無効にする必要があります。

6.3.2. Gluster NFS (非推奨)

警告
Gluster-NFS は、Red Hat Gluster Storage 3.5 では非推奨です。Red Hat では Gluster-NFS の使用を推奨しておらず、Red Hat Gluster Storage 3.5.3 にアップグレードする新規デプロイメントおよび既存デプロイメントでのその使用をサポートしません。
NFSv3 規格をサポートする Linux および他のオペレーティングシステムは、NFS を使用して Red Hat Gluster Storage ボリュームにアクセスできます。
注記
Red Hat Gluster Storage 3.2 以降では、GlusterFS サーバーは、作成される新規ボリュームについてデフォルトで無効にされます。必要に応じて、新しいボリュームで Gluster NFS サーバーを明示的に再起動できます。これは、以下のようにクライアントで「mount -t nfs"」コマンドを実行できます。
# mount -t nfs HOSTNAME:VOLNAME MOUNTPATH
サーバーノードのいずれかで以下を行います。
# gluster volume set VOLNAME nfs.disable off
ただし、Gluster NFS サーバーを使用した既存のボリュームは、Red Hat Gluster Storage 3.2 にアップグレードした後も影響を受けず、Gluster NFS サーバーを暗黙的に有効化します。
オペレーティングシステムでの NFSv3 標準の実装によっては、運用上の問題が発生する可能性があります。NFSv3 の使用時に問題が発生した場合は、Red Hat サポートに連絡し、Red Hat Gluster Storage クライアントのオペレーティングシステムの互換性と、NFSv3 に影響する既知の問題に関する情報を受け取ります。
NFS ACL v3 がサポートされています。これにより、NFS クライアントでの getfacl および setfacl 操作が可能になります。nfs.acl オプションを使用して、glusterFS NFS サーバーにアクセス制御リスト (ACL) の設定に、以下のオプションが提供されます。以下に例を示します。
  • nfs.acl ON を設定するには、以下のコマンドを実行します。
    # gluster volume set VOLNAME nfs.acl on
  • nfs.acl OFF を設定するには、以下のコマンドを実行します。
    # gluster volume set VOLNAME nfs.acl off
注記
ACL はデフォルトで ON です。
Red Hat Gluster Storage には Network Lock Manager (NLM) v4 が含まれています。NLM プロトコルにより、NFSv3 クライアントはネットワーク全体のファイルをロックできます。NLM は、NFSv3 マウントポイント上でアプリケーションが標準の fcntl() (POSIX) および flock() (BSD) ロック呼び出しを使用して、クライアント全体でアクセスを同期するようにするのに必要です。
本セクションでは、NFS を使用して Red Hat Gluster Storage ボリュームをマウントする方法を説明します (手動および自動の両方)。また、ボリュームが正常にマウントされたことを確認する方法を説明します。
重要
Red Hat Enterprise Linux 7 では、以下のコマンドを使用して、ランタイムおよび永続モードのアクティブなゾーンでファイアウォールサービスを有効にします。
アクティブゾーンの一覧を取得するには、以下のコマンドを実行します。
# firewall-cmd --get-active-zones
アクティブなゾーンでファイアウォールサービスを許可するには、次のコマンドを実行します。
# firewall-cmd --zone=zone_name --add-service=nfs --add-service=rpc-bind
# firewall-cmd --zone=zone_name --add-service=nfs --add-service=rpc-bind --permanent

6.3.2.1. Gluster NFS 用の CTDB の設定 (非推奨)

複製ボリューム環境では、Samba 共有に高可用性とロック同期を提供するように CTDB ソフトウェア (Cluster Trivial Database) を設定する必要があります。CTDB は、仮想 IP アドレス (VIP) およびハートビートサービスを追加して高可用性を提供します。
信頼されたストレージプールのノードに障害が発生した場合、CTDB により、障害が発生したノードがホストしていた仮想 IP アドレスを別のノードを引き継ぐことができます。これにより、提供されるサービスの IP アドレスが常に利用できるようになります。ただし、ロックはフェイルオーバーの一部として移行されません。
重要
Red Hat Enterprise Linux 7 では、以下のコマンドを使用して、ランタイムおよび永続モードのアクティブなゾーンで CTDB ファイアウォールサービスを有効にします。
アクティブゾーンの一覧を取得するには、以下のコマンドを実行します。
# firewall-cmd --get-active-zones
アクティブゾーンにポートを追加するには、次のコマンドを実行します。
# firewall-cmd --zone=zone_name --add-port=4379/tcp
# firewall-cmd --zone=zone_name --add-port=4379/tcp  --permanent
注記
Amazon Elastic Compute Cloud (EC2) は仮想 IP をサポートしないため、このソリューションとの互換性はありません。
6.3.2.1.1. 前提条件
Red Hat Gluster Storage Server に CTDB を設定する前に、以下の手順を実行します。
  • 古いバージョンの CTDB (バージョン <= ctdb1.x) がすでにある場合は、以下のコマンドを実行して CTDB を削除します。
    # yum remove ctdb
    古いバージョンを削除したら、最新の CTDB のインストールに進みます。
    注記
    最新の CTDB パッケージを取得するには、システムが samba チャンネルにサブスクライブしていることを確認してください。
  • 以下のコマンドを使用して、NFS サーバーとして使用されるすべてのノードに CTDB をインストールします。
    # yum install ctdb
  • CTDB は、デフォルトで TCP ポート 4379 を使用します。このポートが Red Hat Gluster Storage サーバー間でアクセスできることを確認します。
6.3.2.1.2. Gluster NFS のポートおよびファイアウォール情報
GNFS-Client マシンで次のコマンドを実行して、statd サービス、nlm サービス、および portmapper サービスが使用するポートを追加するように firewalld を設定します。
# firewall-cmd --zone=public --add-port=662/tcp --add-port=662/udp \
--add-port=32803/tcp --add-port=32769/udp \
--add-port=111/tcp --add-port=111/udp
# firewall-cmd --zone=public --add-port=662/tcp --add-port=662/udp \
--add-port=32803/tcp --add-port=32769/udp \
--add-port=111/tcp --add-port=111/udp --permanent
クライアントおよびサーバーマシンで以下の手順を実行します。
  • Red Hat Enterprise Linux 7 では、以下のように /etc/sysconfig/nfs ファイルを編集します。
    # sed -i '/STATD_PORT/s/^#//' /etc/sysconfig/nfs
    注記
    この手順は、Red Hat Enterprise Linux 8 には適用されません。
  • サービスを再起動します。
    • Red Hat Enterprise Linux 6 の場合:
      # service nfslock restart
      # service nfs restart
      重要
      Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。『 インストールガイド』の「 『バージョンの詳細』 表」 『および「Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 」を参照してください。
    • Red Hat Enterprise Linux 7 の場合:
      # systemctl restart nfs-config
      # systemctl restart rpc-statd
      # systemctl restart nfs-mountd
      # systemctl restart nfslock
      注記
      この手順は、Red Hat Enterprise Linux 8 には適用されません。
6.3.2.1.3. Red Hat Gluster Storage サーバーでの CTDB の設定
Red Hat Gluster Storage サーバーで CTDB を設定するには、以下の手順を実行します。
  1. 複製ボリュームを作成します。このボリュームは、ゼロバイトロックファイルのみをホストするため、最小サイズのブリックを選択します。複製ボリュームを作成するには、以下のコマンドを実行します。
    # gluster volume create volname replica n ipaddress:/brick path.......N times
    詳細は以下のようになります。
    N: Gluster NFS サーバーとして使用されるノード数。各ノードは、1 つのブリックをホストする必要があります。
    以下に例を示します。
    # gluster volume create ctdb replica 3 10.16.157.75:/rhgs/brick1/ctdb/b1 10.16.157.78:/rhgs/brick1/ctdb/b2 10.16.157.81:/rhgs/brick1/ctdb/b3
  2. 以下のファイルの META="all" ステートメントの「all」を、新たに作成したボリューム名に置き換えます。
    /var/lib/glusterd/hooks/1/start/post/S29CTDBsetup.sh
    /var/lib/glusterd/hooks/1/stop/pre/S29CTDB-teardown.sh
    以下に例を示します。
    META="all"
      to
    META="ctdb"
  3. ボリュームを起動します。
    # gluster volume start ctdb
    最初のプロセスの一環として、S 29CTDBsetup.sh スクリプトはすべての Red Hat Gluster Storage サーバーで実行され、マウント用に /etc/fstab のエントリーを追加し、Gluster NFS サーバーのすべてのノードで /gluster/lock にボリュームをマウントします。また、起動時に CTDB サービスの自動起動も有効にします。
    注記
    特別な CTDB ボリュームを停止すると、S29CTDB-teardown.sh スクリプトはすべての Red Hat Gluster Storage サーバーで実行し、マウント用に /etc/fstab のエントリーを削除し、/gluster/lock でボリュームをアンマウントします。
  4. /etc/sysconfig/ctdb ファイルが Gluster NFS サーバーとして使用されるすべてのノードに存在するかどうかを確認します。このファイルには、Red Hat Gluster Storage の推奨される CTDB 設定が含まれます。
  5. Gluster NFS サーバーとして使用されるすべてのノードに /etc/ctdb/nodes ファイルを作成し、これらのノードの IP をファイルに追加します。
    10.16.157.0
    10.16.157.3
    10.16.157.6
    ここに一覧表示される IP は、NFS サーバーのプライベート IP です。
  6. IP フェイルオーバーを必要とする Gluster NFS サーバーとして使用するすべてのノードで、/etc/ctdb/public_addresses ファイルを作成し、CTDB 作成すべき仮想 IP をこのファイルに追加します。これらの IP アドレスを以下の形式に追加します。
    <Virtual IP>/<routing prefix><node interface>
    以下に例を示します。
    192.168.1.20/24 eth0
    192.168.1.21/24 eth0
  7. 以下のコマンドを実行して、すべてのノードで CTDB サービスを起動します。
    # service ctdb start
注記
gNFS を備えた CTDB はノードレベルの高可用性のみを提供し、NFS サービスの障害は検出できません。したがって、ノードの稼働中に NFS サービスがダウンした場合、CTDB は高可用性を提供しません。

6.3.2.2. Gluster NFS を使用した Red Hat Gluster Storage ボリュームのマウント (非推奨)

以下の方法のいずれかを使用して、Red Hat Gluster Storage ボリュームをマウントできます。
注記
現在 GlusterFS NFS サーバーは、NFS プロトコルのバージョン 3 のみに対応します。優先オプションとして、/etc/nfsmount.conf の nfsmount.conf ファイルのデフォルトバージョンとしてバージョン 3 を常に設定します。このファイルに以下のテキストを追加し ます。
Defaultvers=3
ファイルが変更されない場合は、すべてのマウントコマンドに vers=3 を手動で追加します。
# mount nfsserver:export -o vers=3 /MOUNTPOINT
上記のセクションで説明されている GlusterFS での RDMA サポートは、ブリックと Fuse のマウント/GFAPI/NFS サーバー間の通信に関するものです。NFS カーネルクライアントは、引き続き tcp 経由で GlusterFS NFS サーバーと通信します。
1 種類のトランスポートでのみ作成されたボリュームの場合、GlusterFS NFS サーバーとブリック間の通信はそのトランスポートタイプを介して行われます。tcp の場合は、ボリューム セットオプション nfs.transport-type を使用して変更する可能性があります。
ボリュームをマウントしたら、で説明されている手順に従って、マウントされたボリュームをテストできます。「Gluster NFS を使用したマウントしたボリュームのテスト (非推奨)」
6.3.2.2.1. Gluster NFS を使用したボリュームの手動マウント (非推奨)
マウントポイントを作成し、mount コマンドを実行して、Gluster NFS を使用して Red Hat Gluster Storage ボリュームを手動でマウントします。
  1. ボリュームにマウントポイントが作成されていない場合は、mkdir コマンドを実行してマウントポイントを作成します。
    # mkdir /mnt/glusterfs
  2. システムの適切な マウント コマンドを実行します。
    Linux の場合
    # mount -t nfs -o vers=3 server1:/test-volume /mnt/glusterfs
    Solaris の場合
    # mount -o vers=3 nfs://server1:38467/test-volume /mnt/glusterfs
TCP を介した Gluster NFS を使用した Red Hat Gluster Storage ボリュームの手動マウント
マウントポイントを作成し、mount コマンドを実行して、TCP 上の Gluster NFS を使用して Red Hat Gluster Storage ボリュームを手動でマウントします。
注記
GlusterFS NFS サーバーは UDP をサポートしません。Solaris クライアントなどの NFS クライアントを、デフォルトで UDP を使用して接続すると、以下のメッセージが表示されます。
要求された NFS バージョンまたはトランスポートプロトコルはサポートされていません
nfs.mount-udp オプションは、マウントするためにサポートされています。デフォルトでは、これは無効にされています。以下は制限です。
  • nfs.mount-udp が有効になっている場合、NFSv3 に必要な MOUNT プロトコルは、UDP で MOUNT を必要とする NFS-clients からの要求を処理できます。これは、少なくとも一部のバージョンの Solaris、IBM AIX、および HP-UX に便利です。
  • 現在、UDP 上の MOUNT は、ボリュームへのサブディレクトリーのマウントをサポートしていません。server:/volume/subdir エクスポートのマウントは、TCP での MOUNT が使用される場合にのみ機能します。
  • UDP 上の MOUNT は、現在 TCP 上にある MOUNT の認証オプションをサポートしていません。nfs.mount-udp を有効にすると、nfs.rpc-auth- allow、nfs.rpc-auth- reject、nfs .export- dir などのさまざまな認証オプションよりも、NFS クライアントにより多くのパーミッションが付与される可能性があります。
  1. ボリュームにマウントポイントが作成されていない場合は、mkdir コマンドを実行してマウントポイントを作成します。
    # mkdir /mnt/glusterfs
  2. システムの適切な マウント コマンドを実行します。システムの TCP プロトコルオプションを指定します。
    Linux の場合
    # mount -t nfs -o vers=3,mountproto=tcp server1:/test-volume /mnt/glusterfs
    Solaris の場合
    # mount -o proto=tcp, nfs://server1:38467/test-volume /mnt/glusterfs
6.3.2.2.2. Gluster NFS を使用したボリュームの自動マウント (非推奨)
Red Hat Gluster Storage ボリュームは、システムが起動するたびに Gluster NFS を使用して自動的にマウントできます。
注記
Red Hat Gluster Storage は、以下のタスクの他に、Gluster NFS マウントを自動マウントする Linux、UNIX、および同様のオペレーティングシステムの標準方法をサポートします。
/etc/auto.master ファイルおよび /etc/auto.misc ファイルを更新して、autofs サービスを再起動します。ユーザーまたはプロセスがディレクトリーにアクセスしようとするたびに、バックグラウンドでマウントされます。
NFS を使用したボリュームの自動マウント
サーバー起動時に NFS を使用して Red Hat Gluster Storage ボリュームを自動的にマウントします。
  1. テキストエディターで /etc/fstab ファイルを開きます。
  2. fstab ファイルに次の設定を追加します。
    HOSTNAME|IPADDRESS:/VOLNAME /MOUNTDIR nfs defaults,_netdev, 0 0
    上記のサーバー名例を使用すると、エントリーには以下の置換値が含まれます。
    server1:/test-volume /mnt/glusterfs nfs defaults,_netdev, 0 0
TCP での NFS を使用したボリュームの自動マウント
サーバー起動時に TCP において NFS を使用して Red Hat Gluster Storage ボリュームを自動的にマウントします。
  1. テキストエディターで /etc/fstab ファイルを開きます。
  2. fstab ファイルに次の設定を追加します。
    HOSTNAME|IPADDRESS:/VOLNAME /MOUNTDIR nfs defaults,_netdev,mountproto=tcp 0 0
    上記のサーバー名例を使用すると、エントリーには以下の置換値が含まれます。
    server1:/test-volume /mnt/glusterfs nfs defaults,_netdev,mountproto=tcp 0 0
6.3.2.2.3. NFS を使用したサブディレクトリーの自動マウント (非推奨)
nfs.export-dir オプションおよび nfs.export-dirs オプションは、詳細な制御により、特定のクライアントがサブディレクトリーをマウントするか、許可することができます。これらのクライアントは、IP、ホスト名、または Classless Inter-Domain Routing (CIDR) 範囲のいずれかを使用して、サブディレクトリーマウント中に認証できます。
nfs.export-dirs
このオプションはデフォルトで有効になっています。これにより、個々のサブディレクトリーをエクスポートすることなく、エクスポートされたボリュームのサブディレクトリーをクライアントでマウントできます。これを有効にすると、全ボリュームのサブディレクトリーがすべてエクスポートされます。クライアントにマウントするには、サブディレクトリーを個別にエクスポートする必要があります。
すべてのボリュームでこのオプションを無効にするには、以下のコマンドを実行します。
# gluster volume set VOLNAME nfs.export-dirs off
nfs.export-dir
nfs.export-dirson に設定された場合、nfs.export-dir オプションでは、全サブディレクトリー(nfs.export-dirs on)をエクスポートする代わりに、エクスポートするサブディレクトリーを 1 つ以上指定できます。または、個別にエクスポートされたサブディレクトリー(nfs.export-dirs off)をエクスポートします。
特定のサブディレクトリーをエクスポートするには、以下のコマンドを実行します。
# gluster volume set VOLNAME nfs.export-dir subdirectory
サブディレクトリーパスは、ボリュームのルートのパスである必要があります。たとえば、6 つのサブディレクトリーを持つボリュームでは、最初の 3 つのサブディレクトリーをエクスポートするには、以下のコマンドを実行します。
# gluster volume set myvolume nfs.export-dir /dir1,/dir2,/dir3
また、ディレクトリーパスの後にそれらの詳細を括弧に追加することで、IP アドレス、ホスト名、または Classless Inter-Domain Routing (CIDR) 範囲に基づいてサブディレクトリーをエクスポートすることもできます。
# gluster volume set VOLNAME nfs.export-dir subdirectory(IPADDRESS),subdirectory(HOSTNAME),subdirectory(CIDR)
# gluster volume set myvolume nfs.export-dir /dir1(192.168.10.101),/dir2(storage.example.com),/dir3(192.168.98.0/24)
6.3.2.2.4. Gluster NFS を使用したマウントしたボリュームのテスト (非推奨)
Red Hat Gluster Storage ディレクトリーが正常にマウントされていることを確認できます。
マウントされたボリュームをテストする方法

マウントした Red Hat Gluster Storage ボリュームのテスト

コマンドラインで、Red Hat Gluster Storage ボリュームが正常にマウントされていることを確認します。3 つのコマンドはすべて、一覧表示された順序で実行することが可能です。あるいは、ボリュームが正常にマウントされたことを確認するために独立して実行できます。
  1. mount コマンドを実行して、ボリュームが正常にマウントされたかどうかを確認します。
    # mount
    server1:/test-volume on /mnt/glusterfs type nfs (rw,addr=server1)
  2. df コマンドを実行して、ボリュームのすべてのブリックから集約されたストレージ領域を表示します。
    # df -h /mnt/glusterfs
    Filesystem              Size Used Avail Use% Mounted on
    server1:/test-volume    28T  22T  5.4T  82%  /mnt/glusterfs
  3. cd コマンドを使用してマウントディレクトリーに移動し、コンテンツを一覧表示します。
    # cd /mnt/glusterfs
    # ls
    注記
    NFS プロトコルの LOCK 機能はアドバイザリーで、複数のクライアントが同じボリュームにアクセスしている場合はロックを使用することが推奨されます。

6.3.2.3. Gluster NFS のトラブルシューティング (非推奨)

問:
NFS クライアントの mount コマンドが RPC エラー: Program not registered で失敗します。このエラーは、以下のいずれかの理由で発生しています。
  • NFS サーバーが実行していない。以下のコマンドを使用してステータスを確認できます。
    # gluster volume status
  • ボリュームが起動していません。以下のコマンドを使用してステータスを確認できます。
    # gluster volume info
  • rpcbind が再起動します。rpcbind が実行されていることを確認するには、以下のコマンドを実行します。
    # ps ax| grep rpcbind
答:
  • NFS サーバーが実行していない場合は、以下のコマンドを使用して NFS サーバーを再起動します。
    # gluster volume start VOLNAME
  • ボリュームが起動していない場合は、以下のコマンドを使用してボリュームを起動します。
    # gluster volume start VOLNAME
  • rpcbind サーバーと NFS サーバーの両方が稼働している場合は、以下のコマンドを使用して NFS サーバーを再起動します。
    # Gluster volume stop VOLNAME
    # Gluster ボリューム起動 VOLNAME
問:
rpcbind サービスが NFS クライアントで実行されていない。原因としては、以下の理由があります。
  • portmap が実行していません。
  • カーネルの NFS サーバーまたは glusterNFS サーバーの別のインスタンスが実行されています。
答:
以下のコマンドを実行して rpcbind サービスを起動します。
# service rpcbind start
問:
NFS サーバーの glusterfsd は起動していますが、ログの nfsrpc- service: portmap registration of program failed エラーメッセージで初期化に失敗します。
答:
NFS の起動は成功しますが、NFS サービスの初期化により、クライアントがマウントポイントにアクセスできない可能性があります。このような状況は、ログファイルの以下のエラーメッセージから確認することができます。
[2010-05-26 23:33:47] E [rpcsvc.c:2598:rpcsvc_program_register_portmap] rpc-service: Could notregister with portmap
[2010-05-26 23:33:47] E [rpcsvc.c:2682:rpcsvc_program_register] rpc-service: portmap registration of program failed
[2010-05-26 23:33:47] E [rpcsvc.c:2695:rpcsvc_program_register] rpc-service: Program registration failed: MOUNT3, Num: 100005, Ver: 3, Port: 38465
[2010-05-26 23:33:47] E [nfs.c:125:nfs_init_versions] nfs: Program init failed
[2010-05-26 23:33:47] C [nfs.c:531:notify] nfs: Failed to initialize protocols
[2010-05-26 23:33:49] E [rpcsvc.c:2614:rpcsvc_program_unregister_portmap] rpc-service: Could not unregister with portmap
[2010-05-26 23:33:49] E [rpcsvc.c:2731:rpcsvc_program_unregister] rpc-service: portmap unregistration of program failed
[2010-05-26 23:33:49] E [rpcsvc.c:2744:rpcsvc_program_unregister] rpc-service: Program unregistration failed: MOUNT3, Num: 100005, Ver: 3, Port: 38465
  1. 以下のコマンドを実行して、NFS サーバーで rpcbind サービスを起動します。
    # service rpcbind start
    rpcbind サービスを起動したら、glusterFS NFS サーバーを再起動する必要があります。
  2. 同じマシンで実行している別の NFS サーバーを停止します。
    このようなエラーも、同じマシン上で別の NFS サーバーが実行されている場合にも見られますが、glusterFS NFS サーバーではありません。Linux システムでは、これはカーネルの NFS サーバーである可能性があります。解決するには、他の NFS サーバーを停止するか、マシン上で glusterFS NFS サーバーを実行しないようにします。カーネルの NFS サーバーを停止する前に、重要なサービスが、その NFS サーバーのエクスポートへのアクセスに依存しないようにしてください。
    Linux では、使用中のディストリビューションに応じて以下のコマンドのいずれかを使用して、カーネルの NFS サーバーを停止できます。
    # service nfs-kernel-server stop
    # service nfs stop
  3. glusterFS NFS サーバーを再起動します。
問:
ログファイルの Port is already in use メッセージで、NFS サーバーの起動に失敗します。
答:
このエラーは、同じマシン上ですでに glusterFS NFS サーバーが実行されている場合に発生する可能性があります。以下のエラー行が存在する場合、この状況はログファイルから確認することができます。
[2010-05-26 23:40:49] E [rpc-socket.c:126:rpcsvc_socket_listen] rpc-socket: binding socket failed:Address already in use
[2010-05-26 23:40:49] E [rpc-socket.c:129:rpcsvc_socket_listen] rpc-socket: Port is already in use
[2010-05-26 23:40:49] E [rpcsvc.c:2636:rpcsvc_stage_program_register] rpc-service: could not create listening connection
[2010-05-26 23:40:49] E [rpcsvc.c:2675:rpcsvc_program_register] rpc-service: stage registration of program failed
[2010-05-26 23:40:49] E [rpcsvc.c:2695:rpcsvc_program_register] rpc-service: Program registration failed: MOUNT3, Num: 100005, Ver: 3, Port: 38465
[2010-05-26 23:40:49] E [nfs.c:125:nfs_init_versions] nfs: Program init failed
[2010-05-26 23:40:49] C [nfs.c:531:notify] nfs: Failed to initialize protocols
本リリースでは、glusterFS NFS サーバーが同じマシン上で複数の NFS サーバーを実行することはサポートしていません。この問題を解決するには、glusterFS NFS サーバーのいずれかをシャットダウンする必要があります。
問:
NFS サーバーの失敗により、mount コマンドは失敗します。
答:
mount: mount to NFS server '10.1.10.11' failed: timed out (retrying).
提案されたソリューションを確認し、適用して問題を修正します。
  • NFS サーバーから DNS サーバーへの名前検索要求を無効にします。
    NFS サーバーは、逆引き DNS ルックアップを実行して、ボリュームファイルのホスト名とクライアント IP アドレスを照合して、NFS クライアントの認証を試行します。NFS サーバーが DNS サーバーに接続できない場合や、DNS サーバーが DNS 要求に応答するのに時間がかかりすぎる状況があります。この遅延により、NFS サーバーから NFS クライアントへの遅延が遅れてタイムアウトエラーが発生する可能性があります。
    NFS サーバーは、代わりに、認証用のクライアント IP アドレスのみに依存する DNS 要求を無効にする回避策を提供します。このような状況でマウントを成功させるには、以下のオプションを追加できます。
    option nfs.addr.namelookup off
    注記
    NFS サーバーを無効にすると、クライアントの認証が IP アドレスのみを使用するように強制されることに注意してください。ボリュームファイルの認証ルールがホスト名を使用する場合、これらの認証ルールが失敗し、クライアントのマウントに失敗します。
  • NFS クライアントが使用する NFS バージョンは、デフォルトではバージョン 3 とは異なります。
    GlusterFS NFS サーバーは、デフォルトで NFS プロトコルのバージョン 3 に対応します。最新の Linux カーネルでは、デフォルトの NFS バージョンが 3 から 4 に変更になりました。glusterFS NFS サーバーによって認識されないバージョン 4 のメッセージを使用しているため、クライアントマシンは glusterFS NFS サーバーに接続できない可能性があります。タイムアウトは、NFS クライアントがバージョン 3 を使用するように強制することで解決できます。この目的のために、vers オプションが使用されます。
    # mount nfsserver:export -o vers=3 /MOUNTPOINT
問:
showmount コマンドが clnt_create: RPC: Unable to receive エラーで失敗します。このエラーは、以下の理由で発生しています。
  • ファイアウォールがポートをブロックしている可能性があります。
  • rpcbind が実行されていない可能性があります。
答:
ファイアウォール設定を確認し、ポートマップ要求/応答および glusterFS NFS サーバーの要求/応答のポート 111 を開放します。glusterFS NFS サーバーは、38465、38466、および 38467 のポート番号で動作します。
問:
アプリケーションが Invalid argument または Value too large to define data type で失敗します
答:
通常、これら 2 つのエラーは、32 ビットの NFS クライアント、または 64 ビットの inode 番号または大きな多数のファイルに対応していないアプリケーションに対して発生します。
コマンドラインインターフェースで以下のオプションを使用して、代わりに glusterFS NFS が 32 ビットの inode 番号を返すようにします。
NFS.enable-ino32 <on | off>
このオプションはデフォルトでは off になっており、NFS はデフォルトでは 64 ビットの inode 番号を返すことができます。
このオプションでメリットとなるアプリケーションには、以下が含まれます。
  • デフォルトでは大きなファイルに対応していない 32 ビットマシン上で構築され、実行している。
  • 64 ビットシステムで 32 ビット標準に構築されている。
gcc で以下のフラグを使用して、ソースから再構築できるアプリケーションを再構築することが推奨されます。
-D_FILE_OFFSET_BITS=64
問:
NFS サーバーを実行しているマシンを再起動すると、クライアントは、先に保持したロックの回収に失敗します。
答:
NSM (Network Status Monitor) サービスデーモン (rpc.statd) は、gluster NFS サーバーの前に起動します。したがって、NSM はクライアントに通知を送信して、ロックを回収します。クライアントが回収要求を送信すると、NFS サーバーは開始していないため応答しません。したがって、クライアント要求は失敗します。
解決策: サーバーの起動時に NSM デーモンが起動しないようにします。
chkconfig --list nfslock を実行して、OS の起動時に NSM が設定されているかどうかを確認します。
エントリーのいずれかがオンの場合は 、chkconfig nfslock off を実行して、起動時に NSM クライアントを無効にします。これにより、問題は解決されます。
問:
ボリュームが正常にマウントされても、nfs.log に rpc actor failed to complete successfully エラーが表示されます。
答:
gluster NFS は NFS バージョン 3 のみをサポートします。バージョンが指定されていない場合に、nfs-utils がクライアントをマウントすると、バージョン 3 にフォールバックする前にバージョン 4 を使用してネゴシエートしようとします。サーバーログと nfs.log ファイルの両方におけるメッセージの原因です。
[2013-06-25 00:03:38.160547] W [rpcsvc.c:180:rpcsvc_program_actor] 0-rpc-service: RPC program version not available (req 100003 4)
[2013-06-25 00:03:38.160669] E [rpcsvc.c:448:rpcsvc_check_and_reply_error] 0-rpcsvc: rpc actor failed to complete successfully
この問題を解決するには、以下のように mount コマンドで NFS バージョン 3 および noacl オプションを宣言します。
# mount -t nfs -o vers=3,noacl server1:/test-volume /mnt/glusterfs
問:
mount コマンドは、No such file or directory で失敗します。
答:
ボリュームが存在しないため、この問題が発生します。

6.3.3. NFS Ganesha

NFS-Ganesha は NFSv3、NFSv4.0、および NFSv4.1 に対応する NFS プロトコルのユーザー空間ファイルサーバーです。
Red Hat Gluster Storage 3.5 は、Red Hat Enterprise Linux 7 の NFS-Ganesha のコミュニティーの V2.7 の安定したリリースでサポートされます。NFS-ganesha のさまざまなサポート対象機能については、「『Supported Features of NFS-Ganesha』」を参照してください。
注記
NFS-Ganesha をインストールするには、『『Red Hat Gluster Storage 3.5 Installation Guide』』の「『Deploying NFS-Ganesha on Red Hat Gluster Storage』」を参照してください。

6.3.3.1. NFS-Ganesha のサポートされる機能

以下の一覧で、NFS-Ganesha のサポートされる機能を簡単に説明します。

高可用性 Active-Active NFS-Ganesha

高可用性のアクティブ/アクティブ環境で、特定のアプリケーションを実行している NFS-Ganesha サーバーに接続されている NFS-Ganesha サーバーがダウンすると、管理上の介入なしにアプリケーション/NFS クライアントは、別の NFS-Ganesha サーバーにシームレスに接続されます。

クラスターのマルチヘッド NFS-Ganesha サーバー間のデータの一貫性は、Gluster の Upcall インフラストラクチャーを使用して実行されます。Gluster の Upcall インフラストラクチャーは、バックエンドファイルシステムで変更が検出される際に、対応する glusterfs クライアント (この場合は NFS-Ganesha サーバー) に通知を送信する汎用かつ拡張可能なフレームワークです。

ボリュームの動的エクスポート

NFS-Ganesha は、エクスポートの追加または削除を動的にサポートします。動的エクスポートは DBus インターフェースにより管理されます。DBus は、システム管理およびピアツーピアアプリケーション通信用のシステムローカル IPC メカニズムです。

複数のエントリーのエクスポート

NFS-Ganesha では、複数の Red Hat Gluster Storage ボリュームまたはサブディレクトリーを同時にエクスポートすることができます。

擬似ファイルシステム

NFS-Ganesha は NFSv4 擬似ファイルシステムを作成して維持します。このシステムは、サーバー上のすべてのエクスポートしたオブジェクトへのシームレスなアクセスを提供します。

アクセス制御リスト

NFS-Ganesha NFSv4 プロトコルには、Windows で使用されるアクセス制御リスト (ACL) の統合サポートが含まれています。これらの ACL を使用して信頼側の識別や、その信頼側のアクセス権限の許可または拒否を指定できます。この機能はデフォルトでは無効になっています。

注記
AUDIT および ALARM ACE タイプは現在サポートされていません。

6.3.3.2. NFS Ganesha の設定

NFS Ganesha を設定するには、これ以降のセクションに記載の手順に従います。
注記
gdeploy を使用して NFS-Ganesha を設定することもできます。これにより、以下の手順を自動化することができます。詳しくは、「NFS-Ganesha のデプロイ」を参照してください。
6.3.3.2.1. NFS-Ganesha のポートおよびファイアウォール情報
ポートおよびファイアウォールサービスを開くようにする必要があります。
以下の表には、NFS-Ganesha クラスター設定のポートの詳細をまとめています。

表6.6 NFS ポートの詳細

サービス ポート番号 プロトコル
sshd 22TCP
rpcbind/portmapper 111TCP/UDP
NFS 2049TCP/UDP
mountd 20048TCP/UDP
NLM 32803TCP/UDP
RQuota 875TCP/UDP
statd 662TCP/UDP
pcsd2224TCP
pacemaker_remote3121TCP
corosync5404 および 5405UDP
dlm21064TCP
注記
Red Hat Gluster Storage サービスのポートの詳細は、セクション 『3 の下に一覧表示されます。ポートアクセス 』 の確認

サービスポートの定義

nfs-ganesha クラスターのすべてのノードで以下のコマンドを実行して、上記のポートを使用するように statd サービスが設定されていることを確認します。

  1. Red Hat Enterprise Linux 7 では、以下のように /etc/sysconfig/nfs ファイルを編集します。
    # sed -i '/STATD_PORT/s/^#//' /etc/sysconfig/nfs
    注記
    この手順は、Red Hat Enterprise Linux 8 には適用されません。
  2. statd サービスを再起動します。
    Red Hat Enterprise Linux 7 の場合
    # systemctl restart nfs-config
    # systemctl restart rpc-statd
    注記
    この手順は、Red Hat Enterprise Linux 8 には適用されません。
注記
NFS クライアントが LOCK 機能を使用するには、LOCKD デーモンおよび STATD デーモンが使用するポートを設定し、クライアントマシンの firewalld 経由で開放する必要があります。
  1. 以下のコマンドを使用して '/etc/sysconfig/nfs' を編集します。
    # sed -i '/STATD_PORT/s/^#//' /etc/sysconfig/nfs
    # sed -i '/LOCKD_TCPPORT/s/^#//' /etc/sysconfig/nfs
    # sed -i '/LOCKD_UDPPORT/s/^#//' /etc/sysconfig/nfs
  2. サービスを再起動します。
    Red Hat Enterprise Linux 7 の場合
    # systemctl restart nfs-config
    # systemctl restart rpc-statd
    # systemctl restart nfslock
  3. 以下のコマンドを使用して、最初のステップで設定したポートを開きます。
    # firewall-cmd --zone=public --add-port=662/tcp --add-port=662/udp \
    --add-port=32803/tcp --add-port=32769/udp \
    --add-port=111/tcp --add-port=111/udp
    # firewall-cmd --zone=public --add-port=662/tcp --add-port=662/udp \
    --add-port=32803/tcp --add-port=32769/udp \
    --add-port=111/tcp --add-port=111/udp --permanent
  4. NFS クライアントの UDP マウントが失敗しないようにするには、以下のコマンドを実行して 2049 ポートを開くようにしてください。
    # firewall-cmd --zone=zone_name --add-port=2049/udp
    # firewall-cmd --zone=zone_name --add-port=2049/udp --permanent
  • ファイアウォールの設定

    Red Hat Enterprise Linux 7 で、以下に挙げるファイアウォールサービスを有効にします。
    1. 以下のコマンドを使用して、アクティブゾーンの一覧を取得します。
      # firewall-cmd --get-active-zones
    2. アクティブなゾーンでファイアウォールサービスを許可し、以下のコマンドを実行します。
      # firewall-cmd --zone=zone_name --add-service=nlm  --add-service=nfs  --add-service=rpc-bind  --add-service=high-availability --add-service=mountd --add-service=rquota
      
      # firewall-cmd --zone=zone_name  --add-service=nlm  --add-service=nfs  --add-service=rpc-bind  --add-service=high-availability --add-service=mountd --add-service=rquota --permanent
      
      # firewall-cmd --zone=zone_name --add-port=662/tcp --add-port=662/udp
      
      # firewall-cmd --zone=zone_name --add-port=662/tcp --add-port=662/udp --permanent
6.3.3.2.2. NFS-Ganesha を実行するための前提条件
お使いの環境で NFS-Ganesha を実行する前に、以下の前提条件を考慮してください。
  • エクスポートには Red Hat Gluster Storage ボリュームと NFS-Ganesha rpms がインストールされている必要があります。
  • フェンシングエージェントが設定されていることを確認します。フェンシングエージェントの設定に関する詳細は、以下のドキュメントを参照してください。
    注記
    高可用性で NFS Ganesha のインストール/設定に必要なノードの最小数は 3 で、サポートされるノードの最大数は 8 です。
  • 指定のマシン/ホスト上で NFS-Ganesha、gluster-NFS、または kernel-NFS サーバーのうち 1 台のみを有効にすることができます。これは、すべての NFS 実装がポート 2049 を使用し、特定の時点でアクティブにすることができるためです。したがって、NFS-Ganesha を起動する前に kernel-NFS を無効にする必要があります。
    以下のコマンドを使用して kernel-nfs を無効にします。

    Red Hat Enterprise Linux 7 の場合

    # systemctl stop nfs-server
    # systemctl disable nfs-server
    kernel-nfs が無効かどうかを確認するには、以下のコマンドを実行します。
    # systemctl status nfs-server
    サービスが停止状態になっているはずです。
    注記
    Gluster NFS は、NFS-Ganesha が有効になると自動的に停止します。
    nfs.disable の変数が 'off' に設定されているボリュームがない。
  • 「『Port/Firewall Information for NFS-Ganesha』」に記載のとおりポートを設定するようにしてください。
  • お使いの環境に応じて ganesha-ha.conf ファイルを編集します。
  • ganesha.conf ファイルに設定されている各サーバーについて、ネットワーク上の仮想 IP を確保します。これらの IP がホストの静的 IP とは異なること、信頼できるストレージプールまたはサブネット内の他の場所には使用されていないことを確認します。
  • クラスターのすべてのノードが DNS 解決可能であることを確認します。たとえば、/etc/hosts には、クラスター内のすべてのノードの詳細を入力できます。
  • SELinux が Enforcing モードにあることを確認します。
  • 以下のコマンドを使用して、すべてのマシンでネットワークサービスを起動します。
    Red Hat Enterprise Linux 7 の場合
    # systemctl start network
  • 以下のコマンドを実行して gluster 共有ボリュームを作成し、マウントします。
    # gluster volume set all cluster.enable-shared-storage enable
    volume set: success
    
    詳細はを参照してください。 「共有ストレージボリュームの設定」
  • /var/run/gluster/shared_storageの下に、nfs-ganesha という名前のディレクトリーを作成します。
    注記
    3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
  • ganesha.conf ファイルおよび ganesha-ha.conf ファイルを /etc/ganesha から /var/run/gluster/shared_storage/nfs-ganesha にコピーします。
  • 以下のコマンドを使用して、glusterfssharedstorage.service サービスを有効にします。
    systemctl enable glusterfssharedstorage.service
  • 以下のコマンドを使用して、nfs-ganesha サービスを有効にします。
    systemctl enable nfs-ganesha
6.3.3.2.3. クラスターサービスの設定
HA クラスターは、Pacemaker および Corosync を使用して維持されます。Pacemaker はリソースマネージャーを処理し、Corosync はクラスターの通信層を提供します。Pacemaker/Corosync の詳細は、Red Hat Enterprise Linux 7 ドキュメントの 『Clustering』 セクション: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/ を参照してください。
注記
クラスターのクォーラムを維持するために、3 つ以上のノードを使用して NFS Ganesha HA クラスターを設定することを推奨します。
  1. 以下のコマンドを使用して Pacemaker サービスを有効にします。
    Red Hat Enterprise Linux 7 の場合
    # systemctl enable pacemaker.service
  2. 以下のコマンドを使用して pcsd サービスを起動します。
    Red Hat Enterprise Linux 7 の場合
    # systemctl start pcsd
    注記
    • システムの再起動後にデフォルトで pcsd を起動するには、以下のコマンドを実行します。
      Red Hat Enterprise Linux 7 の場合
      # systemctl enable pcsd
  3. 以下のコマンドを使用して、すべてのノードに ’hacluster’ ユーザーのパスワードを設定します。すべてのノードに同じパスワードを使用します。
    # echo <password> | passwd --stdin hacluster
  4. ノード間でクラスター認証を行います。ここで、username は ’hacluster’ で、password は直前の手順で使用したものです。すべてのノードで以下のコマンドを実行してください。
    Red Hat Enterprise Linux 7 の場合:
    # pcs cluster auth <hostname1> <hostname2> ...
    Red Hat Enterprise Linux 8 の場合:
    # pcs host auth <hostname1> <hostname2> ...
    注記
    すべてのノードでノードを実行する際には、Ganesha-HA クラスターのすべてのノードのホスト名をコマンドに含める必要があります。
    たとえば、nfs1、nfs2、nfs3、および nfs4 の 4 つのノードクラスターで、すべてのノードで以下のコマンドを実行します。
    Red Hat Enterprise Linux 7 の場合:
    # pcs cluster auth nfs1 nfs2 nfs3 nfs4
    Username: hacluster
    Password:
    nfs1: Authorized
    nfs2: Authorized
    nfs3: Authorized
    nfs4: Authorized
    Red Hat Enterprise Linux 8 の場合:
    # pcs host auth nfs1 nfs2 nfs3 nfs4
    Username: hacluster
    Password:
    nfs1: Authorized
    nfs2: Authorized
    nfs3: Authorized
    nfs4: Authorized
  5. root ユーザーのパスワードなしで鍵ベースの SSH 認証を、全 HA ノードで有効にする必要があります。次の手順を実行します。
    1. クラスターのいずれかのノード (node1) で、以下を実行します。
      # ssh-keygen -f /var/lib/glusterd/nfs/secret.pem -t rsa -N ''
    2. すべてのノードについて以下のコマンドを実行して、生成された公開鍵を node1 からすべてのノード (node1 を含む) にデプロイします。
      # ssh-copy-id -i /var/lib/glusterd/nfs/secret.pem.pub root@<node-ip/hostname>
    3. すべてのノードについて以下のコマンドを実行して、Ganesha-HA クラスターのすべてのノードに node1 から ssh キーペアをコピーします。
      # scp -i /var/lib/glusterd/nfs/secret.pem /var/lib/glusterd/nfs/secret.* root@<node-ip/hostname>:/var/lib/glusterd/nfs/
  6. クラスターの設定の一環として、ポート 875 は Rquota サービスにバインドされます。このポートがすでに使用されている場合は、すべてのノードの /etc/ganesha/ganesha.conf ファイルで以下の行を変更して、このサービスに別のポートを割り当てます。
    # Use a non-privileged port for RQuota
    Rquota_Port = 875;
6.3.3.2.4. ganesha-ha.conf ファイルの作成
ganesha-ha.conf.sample は、Red Hat Gluster Storage のインストール時に /etc/ganesha に作成します。ファイルの名前を ganesha-ha.conf に変更し、お使いの環境に応じて変更を加えます。
  1. /var/run/gluster/shared_storage に nfs-ganesha という名前のディレクトリーを作成します。
    注記
    3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
  2. ganesha.conf ファイルおよび ganesha ファイルを /etc/ganesha から /var/run/gluster/shared_storage/nfs-ganesha にコピーします。
ganesha-ha.conf のサンプルファイル:
# Name of the HA cluster created.
# must be unique within the subnet
HA_NAME="ganesha-ha-360"
#
#
# You may use short names or long names; you may not use IP addresses.
# Once you select one, stay with it as it will be mildly unpleasant to clean
# up if you switch later on. Ensure that all names - short and/or long - are in
# DNS or /etc/hosts on all machines in the cluster.
#
# The subset of nodes of the Gluster Trusted Pool that form the ganesha HA
# cluster. Hostname is specified.
HA_CLUSTER_NODES="server1.lab.redhat.com,server2.lab.redhat.com,..."
#
# Virtual IPs for each of the nodes specified above.
VIP_server1="10.0.2.1"
VIP_server2="10.0.2.2"
#VIP_server1_lab_redhat_com="10.0.2.1"
#VIP_server2_lab_redhat_com="10.0.2.2"
....
....
注記
  • Pacemaker は、仮想 IP の作成を処理し、インターフェースを割り当てます。
  • 仮想 IP が同じネットワーク範囲にあることを確認します。
  • HA_CLUSTER_NODES がホスト名として指定されていることを確認します。IP アドレスを使用すると、クラスタリングに失敗します。
6.3.3.2.5. Gluster CLI を使用した NFS-Ganesha の設定

HA クラスターの設定

HA クラスターを設定するには、以下のコマンドを実行して NFS-Ganesha を有効にします。

  1. 以下のコマンドを実行して NFS-Ganesha を有効にします。
    # gluster nfs-ganesha enable
    注記
    NFS-Ganesha を有効または無効にする前に、NFS-Ganesha クラスターの一部であるすべてのノードが動作状態にしてください。
    以下に例を示します。
    # gluster nfs-ganesha enable
    Enabling NFS-Ganesha requires Gluster-NFS to be disabled across the trusted pool. Do you still want to continue?
     (y/n) y
    This will take a few minutes to complete. Please wait ..
    nfs-ganesha : success
    注記
    NFS-Ganesha を有効にした後に、rpcinfo -p が 662 とは異なる statd ポートを表示する場合、statd サービスを再起動します。
    Red Hat Enterprise Linux 7 の場合:
    # systemctl restart rpc-statd

    HA クラスターの破棄

    HA クラスターを破棄するには、以下のコマンドを実行します。

    # gluster nfs-ganesha disable
    以下に例を示します。
    # gluster nfs-ganesha disable
    Disabling NFS-Ganesha will tear down entire ganesha cluster across the trusted pool. Do you still want to continue?
    (y/n) y
    This will take a few minutes to complete. Please wait ..
    nfs-ganesha : success

    HA クラスターのステータスの確認

    HA クラスターのステータスを確認するには、以下のスクリプトを実行します。

    # /usr/libexec/ganesha/ganesha-ha.sh --status /var/run/gluster/shared_storage/nfs-ganesha
    注記
    3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
    以下は例になります。
    # /usr/libexec/ganesha/ganesha-ha.sh --status /var/run/gluster/shared_storage/nfs-ganesha
     Online: [ server1 server2 server3 server4 ]
    server1-cluster_ip-1 server1
    server2-cluster_ip-1 server2
    server3-cluster_ip-1 server3
    server4-cluster_ip-1 server4
    Cluster HA Status: HEALTHY
    
    注記
    • ノードが再起動した後に ganesha.nfsd サービスを手動で 再起動して、仮想 IP をフェイルバックさせることを推奨します。
    • NFS Ganesha を無効にしても、Gluster NFS はデフォルトで有効化されません。必要な場合は、GlusterFS を手動で有効にする必要があります。
注記
記載されている問題を回避するために、RQUOTA ポートを無効にするようにしてください。 「NFS Ganesha のトラブルシューティング」
  1. NFS-Ganesha が起動に失敗します。
  2. NFS-Ganesha ポート 875 は利用不可です。
RQUOTA ポートを無効にするには、以下の手順を実行します。
  1. ganesha.conf ファイルは /etc/ganesha/ganesha.conf にあります。
  2. RQUOTA を無効にするには、#Enable_RQUOTA 行のコメントを解除します。
  3. すべてのノードで nfs-ganesha サービスを再起動します。
    # systemctl restart nfs-ganesha
6.3.3.2.6. NFS-Ganesha を使用したボリュームのエクスポートとエクスポート解除
注記
NFS-Ganesha を有効にする前に、Red Hat Gluster Storage ボリュームを起動します。

NFS-Ganesha を使用したボリュームのエクスポート

Red Hat Gluster Storage ボリュームをエクスポートするには、以下のコマンドを実行します。

# gluster volume set <volname> ganesha.enable on
以下に例を示します。
# gluster vol set testvol ganesha.enable on
volume set: success

NFS-Ganesha を使用したボリュームのエクスポート解除

Red Hat Gluster Storage ボリュームのエクスポートを解除するには、以下のコマンドを実行します。

# gluster volume set <volname> ganesha.enable off
このコマンドは、他のエクスポートに影響を与えずに Red Hat Gluster Storage ボリュームをエクスポートします。
以下に例を示します。
# gluster vol set testvol ganesha.enable off
volume set: success
6.3.3.2.7. NFS-Ganesha ステータスの確認
ボリュームセットオプションのステータスを確認するには、以下のガイドラインに従います。
  • 以下のコマンドを実行して、NFS-Ganesha が起動しているかどうかを確認します。
    Red Hat Enterprise Linux-7 の場合
    # systemctl status nfs-ganesha
    以下に例を示します。
    # systemctl  status nfs-ganesha
       nfs-ganesha.service - NFS-Ganesha file server
       Loaded: loaded (/usr/lib/systemd/system/nfs-ganesha.service; disabled)
       Active: active (running) since Tue 2015-07-21 05:08:22 IST; 19h ago
       Docs: http://github.com/nfs-ganesha/nfs-ganesha/wiki
       Main PID: 15440 (ganesha.nfsd)
       CGroup: /system.slice/nfs-ganesha.service
                   └─15440 /usr/bin/ganesha.nfsd -L /var/log/ganesha/ganesha.log -f /etc/ganesha/ganesha.conf -N NIV_EVENT
       Jul 21 05:08:22 server1 systemd[1]: Started NFS-Ganesha file server.]
    
    
  • ボリュームがエクスポートされているかどうかを確認します。
    # showmount -e localhost
    以下に例を示します。
    # showmount -e localhost
    Export list for localhost:
    /volname (everyone)
  • ganesha.nfsd デーモンのログは /var/log/ganesha/ganesha.log に書き込まれます。予期しない動作が発生したときにログファイルを確認します。

6.3.3.3. NFS-Ganesha エクスポートへのアクセス

NFS-Ganesha エクスポートには、NFSv3 または NFSv4 いずれかのモードでマウントすることができます。これはアクティブ/アクティブの HA 設定であるため、マウント操作は任意のノードの仮想 IP から実行できます。
Red Hat Enterprise Linux 7 クライアントで生成されるすべてのワークロードで大きなファイルのパフォーマンスを改善するには、ボリュームをマウントする前に、以下の調整パラメーターを設定することが推奨されます。
  1. 以下のコマンドを実行して調整可能なパラメーターを設定します。
    # sysctl -w sunrpc.tcp_slot_table_entries=128
    # echo 128 > /proc/sys/sunrpc/tcp_slot_table_entries
    # echo 128 > /proc/sys/sunrpc/tcp_max_slot_table_entries
  2. 再起動時に調整可能なパラメーターを永続的にするには、以下のコマンドを実行します。
    # echo "options sunrpc tcp_slot_table_entries=128" >> /etc/modprobe.d/sunrpc.conf
    # echo "options sunrpc tcp_max_slot_table_entries=128" >>  /etc/modprobe.d/sunrpc.conf
注記
クラスターの NFS クライアントおよび NFS-Ganesha サーバーが、一意の host-names で DNS が解決でき、Network Lock Manager (NLM) プロトコルを介してファイルロックを使用するようにします。
6.3.3.3.1. NFSv3 モードでのエクスポートのマウント
NFSv3 モードでエクスポートをマウントするには、次のコマンドを実行します。
# mount -t nfs -o vers=3 virtual_ip:/volname /mountpoint
以下に例を示します。
mount -t nfs -o vers=3 10.70.0.0:/testvol /mnt
6.3.3.3.2. NFSv4 モードでのエクスポートのマウント
RHEL 7 クライアントで NFSv4 モードでエクスポートをマウントするには、次のコマンドを実行します。
# mount -t nfs -o vers=4 virtual_ip:/volname /mountpoint
以下に例を示します。
# mount -t nfs -o vers=4 10.70.0.0:/testvol /mnt
重要
RHEL 8 のデフォルトのバージョンは NFSv4.2 です。
RHEL 8 クライアントの特定の NFS バージョンにエクスポートをマウントするには、次のコマンドを実行します。
# mount -t nfs -o vers=4.0 or 4.1 virtual_ip:/volname /mountpoint
以下に例を示します。
# mount -t nfs -o vers=4.1 10.70.0.0:/testvol /mnt
6.3.3.3.3. dbus での NFS サーバーのクライアントの検索
NFS エクスポートをマウントしたクライアントの IP アドレスを表示するには、次のコマンドを実行します。
# dbus-send --type=method_call --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ClientMgr org.ganesha.nfsd.clientmgr.ShowClients
注記
NFS エクスポートがアンマウントされた場合や、クライアントがサーバーから切断されている場合は、コマンドの出力で更新までに数分の時間がかかる場合があります。
6.3.3.3.4. dbus を使用して NFS サーバーから認可されたクライアントリストおよびその他の情報の検索
認可されたクライアントのアクセスリストと、NFS サーバーから設定したその他のエクスポートオプションを表示するには、次のコマンドを実行します。
# dbus-send --type=method_call --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.DisplayExport uint16:Export_Id
このコマンドは ACL とともに、エクスポートボリュームのフルパス、擬似パス、タグなどの他の情報を取得します。完全パスと擬似パスは、エクスポートボリュームのマウントに使用されます。
dbus DisplayExport コマンドは、エクスポートボリュームのクライアント詳細を提供します。出力構文は以下のようになります。
uint16 export_id
string fullpath
string pseudopath
string tag
array[
  struct {
    string client_type
    int32 CIDR_version
    byte CIDR_address
    byte CIDR_mask
    int32 CIDR_proto
    uint32 anonymous_uid
    uint32 anonymous_gid
    uint32 expire_time_attr
    uint32 options
    uint32 set
    }
    struct {
      .
      .
      .
      }
      .
      .
      .
    ]
上記の出力では、client_type はクライアントの IP アドレス CIDR_versionCIDR_addressCIDR_mask および CIDR_proto はクライアントの CIDR 表現の詳細です。また、uint32 anonymous_uiduint32 anonymous_giduint32 expire_time_attruint32 オプション、および uint32 セットはクライアントパーミッションです。
以下に例を示します。
#dbus-send --type=method_call --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.DisplayExport uint16:2

method return time=1559209192.642525 sender=:1.5491 -> destination=:1.5510 serial=370 reply_serial=2
uint16 2
string "/mani1"
string "/mani1"
string ""
array [
  struct {
    string "10.70.46.107/32"
    int32 0
    byte 0
    byte 255
    int32 1
    uint32 1440
    uint32 72
    uint32 0
    uint32 52441250
    uint32 7340536
    }
  struct {
    string "10.70.47.152/32"
    int32 0
    byte 0
    byte 255
    int32 1
    uint32 1440
    uint32 72
    uint32 0
    uint32 51392994
    uint32 7340536
    }
  ]

6.3.3.4. NFS-Ganesha HA 設定の変更

既存の HA クラスターを変更し、エクスポートのデフォルト値を変更するには、/usr/libexec/ganesha/ にある ganesha-ha.sh スクリプトを使用します。
6.3.3.4.1. ノードのクラスターへの追加
ノードをクラスターに追加する前に、『Port Information for NFS-Ganesha』 で説明されているようにファイアウォールサービスが有効化され、『Pre-requisites to run NFS-Ganesha』 セクションで説明されている前提条件を満たしていることを確認してください。
注記
共有ストレージおよび /var/lib/glusterd/nfs/secret.pem SSH キーはすでに生成されているため、これらの手順は反復できません。
ノードをクラスターに追加するには、既存の NFS-Ganesha クラスターのいずれかのノードで以下のコマンドを実行します。
# /usr/libexec/ganesha/ganesha-ha.sh --add <HA_CONF_DIR> <HOSTNAME> <NODE-VIP>
詳細は以下のようになります。
HA_CONF_DIR: ganesha-ha.conf ファイルを含むディレクトリーパス。デフォルトでは、/run/gluster/shared_storage/nfs-ganesha です。
HOSTNAME: 追加する新規ノードのホスト名
NODE-VIP: 追加する新規ノードの仮想 IP。
以下に例を示します。
# /usr/libexec/ganesha/ganesha-ha.sh --add /var/run/gluster/shared_storage/nfs-ganesha server16 10.00.00.01
注記
3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
6.3.3.4.2. クラスター内のノードの削除
クラスターからノードを削除するには、既存の NFS-Ganesha クラスターのいずれかのノードで以下のコマンドを実行します。
# /usr/libexec/ganesha/ganesha-ha.sh --delete <HA_CONF_DIR> <HOSTNAME>
詳細は以下のようになります。
HA_CONF_DIR: ganesha-ha.conf ファイルを含むディレクトリーパス。デフォルトでは、/run/gluster/shared_storage/nfs-ganesha にあります。
HOSTNAME: 削除するノードのホスト名
以下に例を示します。
# /usr/libexec/ganesha/ganesha-ha.sh --delete /var/run/gluster/shared_storage/nfs-ganesha  server16
注記
3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
6.3.3.4.3. クラスター内のノードの置き換え
既存の NFS-Ganesha クラスターのノードを置き換えるには、以下の手順を実施します。
  1. クラスターからノードを削除します。参照 「クラスター内のノードの削除」
  2. 同じ hostname.Refer でノードを作成します。 「ホストマシンの同じホスト名への置き換え」
    注記
    新規ノードが古いノードと同じ名前を持つ必要はありません。
  3. ノードをクラスターに追加します。参照 「ノードのクラスターへの追加」
    注記
    「NFS-Ganesha のポートおよびファイアウォール情報」 で説明したように、ファイアウォールサービスが有効にされており、「NFS-Ganesha を実行するための前提条件」 も満たされていることを確認します。

6.3.3.5. デフォルトのエクスポート設定の変更

gluster CLI オプションを使用して、NFS-Ganesha 経由でボリュームをエクスポートまたはエクスポート解除することを推奨します。ただし、本項では、NFS-Ganesha で設定可能なパラメーターの変更について説明します。このようなパラメーターを変更するには、NFS-Ganesha を手動で起動する必要があります。
サポートされるエクスポートオプションは、man ページの ganesha-export-config 8 を参照してください。
デフォルトのエクスポート設定を変更するには、既存の ganesha クラスターのいずれかのノードで以下の手順を実行します。
  1. /run/gluster/shared_storage/nfs-ganesha/exports/ にある対応するエクスポートファイルにある必須フィールドを編集/追加します
  2. 以下のコマンドを実行します。
    # /usr/libexec/ganesha/ganesha-ha.sh --refresh-config <HA_CONF_DIR> <volname>
各オプションについての説明は以下のとおりです。
  • HA_CONF_DIR: ganesha-ha.conf ファイルを含むディレクトリーパス。デフォルトでは、/run/gluster/shared_storage/nfs-ganesha にあります。
  • volname - エクスポート設定を変更する必要があるボリュームの名前。
エクスポート設定ファイルのサンプル:
以下は、エントリーのエクスポートに必要なデフォルトのパラメーターセットです。ここで指定する値は、NFS-Ganesha の起動または停止に CLI オプションによって使用されるデフォルト値です。
# cat export.conf

EXPORT{
    Export_Id = 1 ;   # Export ID unique to each export
    Path = "volume_path";  # Path of the volume to be exported. Eg: "/test_volume"

    FSAL {
        name = GLUSTER;
        hostname = "10.xx.xx.xx";  # IP of one of the nodes in the trusted pool
        volume = "volume_name";     # Volume name. Eg: "test_volume"
    }

    Access_type = RW;     # Access permissions
    Squash = No_root_squash; # To enable/disable root squashing
    Disable_ACL = true;     # To enable/disable ACL
    Pseudo = "pseudo_path";     # NFSv4 pseudo path for this export. Eg: "/test_volume_pseudo"
    Protocols = "3”, “4" ;     # NFS protocols supported
    Transports = "UDP”, “TCP" ; # Transport protocols supported
    SecType = "sys";     # Security flavors supported
}
以降のセクションで、NFS-Ganesha を使用するさまざまな設定について説明します。予想される動作を確認するには、export.conf ファイルにマイナーな変更を加える必要があります。
  • 特定クライアントのパーミッションの提供
  • NFSv4 ACL の有効化および無効化
  • NFSv4 マウントに疑似パスを提供
  • サブディレクトリーのエクスポート
6.3.3.5.1. 特定クライアントのパーミッションの提供
EXPORT ブロックで指定したパラメーター値とパーミッションの値は、エクスポートしたボリュームをマウントするクライアントに適用されます。特定のクライアントに特定のパーミッションを提供するには、EXPORT ブロック 内にクライアントブロックを追加します。
たとえば、クライアント 10.00.00.01 に特定のパーミッションを割り当てるには、EXPORT ブロックに以下のブロックを追加します。
client {
        clients = 10.00.00.01;  # IP of the client.
        access_type = "RO"; # Read-only permissions
        Protocols = "3"; # Allow only NFSv3 protocol.
        anonymous_uid = 1440;
        anonymous_gid = 72;
  }
その他のクライアントはすべて、client ブロックで宣言されたパーミッションを継承します。
6.3.3.5.2. NFSv4 ACL の有効化および無効化
NFSv4 ACL を有効にするには、以下のパラメーターを編集します。
Disable_ACL = false;
注記
NFS クライアントは、NFS-Ganesha サーバーで ACL を有効化/無効化した後に、共有を再マウントする必要があります。
6.3.3.5.3. NFSv4 マウントに疑似パスを提供
NFSv4 擬似パスを設定するには、以下のパラメーターを編集します。
Pseudo = "pseudo_path"; # NFSv4 pseudo path for this export. Eg: "/test_volume_pseudo"
このパスは、NFSv4 モードでエクスポートエントリーをマウントするときに使用する必要があります。
6.3.3.5.4. サブディレクトリーのエクスポート
以下の 2 つの方法のいずれかに従って、NFS-ganesha にサブディレクトリーをエクスポートすることができます。
方法 1: 個別のエクスポートファイルを作成します。これにより、他の共有に接続された既存のクライアントを中断せずにサブディレクトリーの共有をエクスポートします。
  • サブディレクトリー用の個別のエクスポートファイルを作成します。
    # cat export.ganesha-dir.conf
            # WARNING : Using Gluster CLI will overwrite manual
            # changes made to this file. To avoid it, edit the
            # file and run ganesha-ha.sh --refresh-config.
            EXPORT{
                  Export_Id = 3;
                  Path = "/ganesha/dir";
                  FSAL {
                       name = GLUSTER;
                       hostname="localhost";
                      volume="ganesha";
                volpath="/dir";
                       }
                  Access_type = RW;
                  Disable_ACL = true;
                  Squash="No_root_squash";
                  Pseudo="/ganesha/dir";
                  Protocols = "3", "4";
                  Transports = "UDP","TCP";
                  SecType = "sys";
                 }
  • Export_ID を一意の未使用の ID に変更します。パスおよび Pseudoパラメーターを編集して、volpath エントリーをエクスポートファイルに追加します。
  • サブディレクトリーに新しいエクスポートファイルを作成した場合は、ganesha.conf ファイルにそのエクスポートファイルを追加する必要があります。
     %include "/var/run/gluster/shared_storage/nfs-ganesha/exports/export.<share-name>.conf"
    注記
    3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
    以下に例を示します。
                  %include "/var/run/gluster/shared_storage/nfs-ganesha/exports/export.ganesha.conf" --> Volume entry
                  %include >/var/run/gluster/shared_storage/nfs-ganesha/exports/export.ganesha-dir.conf" --> Subdir entry
  • 以下のスクリプトを実行して、他の共有に接続した既存のクライアントを中断せずにサブディレクトリー共有をエクスポートします。
    # /usr/libexec/ganesha/ganesha-ha.sh --refresh-config <HA_CONF_DIR> <share-name>
    以下に例を示します。
     /usr/libexec/ganesha/ganesha-ha.sh --refresh-config /run/gluster/shared_storage/nfs-ganesha/ ganesha-dir
方法 2: そのサブディレクトリーエントリーを含むボリュームエクスポートファイルを編集します。このメソッドは、親ボリュームではなく、サブディレクトリーのみをエクスポートします。
  • subdir エントリーでボリュームエクスポートファイルを編集します。
    以下に例を示します。
    # cat export.ganesha.conf
                  # WARNING : Using Gluster CLI will overwrite manual
                  # changes made to this file. To avoid it, edit the
                  # file and run ganesha-ha.sh --refresh-config.
                  EXPORT{
                        Export_Id = 4;
                        Path = "/ganesha/dir1";
                        FSAL {
                             name = GLUSTER;
                             hostname="localhost";
                            volume="ganesha";
                            volpath="/dir1";
                             }
                        Access_type = RW;
                        Disable_ACL = true;
                        Squash="No_root_squash";
                        Pseudo="/ganesha/dir1";
                        Protocols = "3", "4";
                        Transports = "UDP","TCP";
                        SecType = "sys";
                       }
  • Export_ID を一意の未使用の ID に変更します。パスおよび Pseudoパラメーターを編集して、volpath エントリーをエクスポートファイルに追加します。
  • 以下のスクリプトを実行して、他の共有に接続した既存のクライアントを中断せずにサブディレクトリー共有をエクスポートします。
    # /usr/libexec/ganesha/ganesha-ha.sh --refresh-config <HA_CONF_DIR> <share-name>
    以下に例を示します。
     /usr/libexec/ganesha/ganesha-ha.sh --refresh-config /run/gluster/shared_storage/nfs-ganesha/ ganesha
    注記
    同じエクスポートファイルに複数の EXPORT{} エントリーが含まれる場合は、ボリュームの再起動または nfs-ganesha サービスの再起動が必要です。
6.3.3.5.4.1. all_squash オプションの有効化
all_squash を有効にするには、以下のパラメーターを編集します。
Squash = all_squash ; # To enable/disable root squashing
6.3.3.5.5. サブディレクトリーのエクスポート
NFS-ganesha のサブディレクトリーは、以下の手順に従ってexported の外に置くことができます。
  1. 設定ファイル (/var/run/gluster/shared_storage/nfs-ganesha/exports/file-name.conf)からエクスポートを解除する共有のエクスポート ID をメモします。
  2. 設定の削除:
    • 設定ファイルを削除します(configraution ファイルがある場合)。
      # rm -rf /var/run/gluster/shared_storage/nfs-ganesha/exports/file-name.conf
    • /etc/ganesha/ganesha.conf から conf ファイルのエントリーを削除します。
      行を削除します。
      %include "/var/run/gluster/shared_storage/nfs-ganesha/export/export.conf
    • 以下のコマンドを実行します。
      # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.RemoveExport uint16:export_id
      上記のコマンドの Export_id は、手順 1 から取得したエクスポートエントリーである必要があります。

6.3.3.6. Kerberized NFS-Ganesha の設定

注記
NTP は、Red Hat Enterprise Linux 8 ではサポートされなくなりました。
Red Hat Enterprise Linux 8 の場合、chrony デーモンを設定するには、以下を参照してください。https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/using-chrony-to-configure-ntp
すべてのマシンで以下の手順を実行します。
  1. すべてのマシンに krb5-workstation パッケージおよび (RHEL 7) または chrony (RHEL 8) パッケージをインストールします。
    # yum install krb5-workstation
    Red Hat Enterprise Linux 7 の場合:
    # yum install ntpdate
    Red Hat Enterprise Linux 8 の場合:
    # dnf install chrony
    注記
    • krb5-libs パッケージが依存パッケージとして更新されます。
  2. RHEL 7 では、環境に応じて、有効なタイムサーバーに基づいて ntpdate を設定します。
    # echo <valid_time_server> >> /etc/ntp/step-tickers
    # systemctl enable ntpdate
    # systemctl start ntpdate
    RHEL 8 では、環境に応じて、有効なタイムサーバーに基づいて chrony を設定します。
      # vi /etc/chrony.conf
      # systemctl enable chrony
      # systemctl start chrony
    RHEL 7 と RHEL 8 の両方について、次の手順を実行します。
  3. すべてのシステムが DNS の FQDN で相互に解決できることを確認します。
  4. /etc/krb5.conf ファイルを設定し、適切な変更を追加します。以下は例になります。
    [logging]
      default = FILE:/var/log/krb5libs.log
      kdc = FILE:/var/log/krb5kdc.log
      admin_server = FILE:/var/log/kadmind.log
    
      [libdefaults]
      dns_lookup_realm = false
      ticket_lifetime = 24h
      renew_lifetime = 7d
      forwardable = true
      rdns = false
      default_realm = EXAMPLE.COM
      default_ccache_name = KEYRING:persistent:%{uid}
    
      [realms]
      EXAMPLE.COM = {
      kdc = kerberos.example.com
        admin_server = kerberos.example.com
      }
    
      [domain_realm]
      .example.com = EXAMPLE.COM
       example.com = EXAMPLE.COM
    注記
    ファイル設定の詳細は、man krb5.conf を参照してください。
  5. NFS-server およびクライアントで、必要な変更を加えて /etc/idmapd.conf ファイルを更新します。以下に例を示します。
    Domain = example.com
6.3.3.6.1. NFS-Ganesha サーバーの設定
NFS-Ganesha サーバーを設定するには、以下の手順を実施します。
注記
NFS-Ganesha サーバーをセットアップする前に、要件に基づいて KDC を設定するようにしてください。
  1. 以下のパッケージをインストールします。
    # yum install nfs-utils
    # yum install rpcbind
  2. 関連する gluster および NFS-Ganesha の rpm をインストールします。詳細は『『Red Hat Gluster Storage 3.5 Installation Guide』』を参照してください。
  3. Kerberos プリンシパルを作成し、NFS-Ganesha サーバーの krb5.keytab に追加します。
    $ kadmin
    $ kadmin: addprinc -randkey nfs/<host_name>@EXAMPLE.COM
    $ kadmin: ktadd nfs/<host_name>@EXAMPLE.COM
    以下は例になります。
    # kadmin
    Authenticating as principal root/admin@EXAMPLE.COM with password.
    Password for root/admin@EXAMPLE.COM:
    
    kadmin:  addprinc -randkey nfs/<host_name>@EXAMPLE.COM
    WARNING: no policy specified for nfs/<host_name>@EXAMPLE.COM; defaulting to no policy
    Principal "nfs/<host_name>@EXAMPLE.COM" created.
    
    
    kadmin:  ktadd nfs/<host_name>@EXAMPLE.COM
    Entry for principal nfs/<host_name>@EXAMPLE.COM with kvno2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
    Entry for principal nfs/<host_name>@EXAMPLE.COM with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
    Entry for principal nfs/<host_name>@EXAMPLE.COM with kvno 2, encryption type des3-cbc-sha1 added to keytab FILE:/etc/krb5.keytab.
    Entry for principal nfs/<host_name>@EXAMPLE.COM with kvno 2, encryption type arcfour-hmac added to keytab FILE:/etc/krb5.keytab.
    Entry for principal nfs/<host_name>@EXAMPLE.COM with kvno 2, encryption type camellia256-cts-cmac added to keytab FILE:/etc/krb5.keytab.
    Entry for principal nfs/<host_name>@EXAMPLE.COM with kvno 2, encryption type camellia128-cts-cmac added to keytab FILE:/etc/krb5.keytab.
    Entry for principal nfs/<host_name>@EXAMPLE.COM with kvno 2, encryption type des-hmac-sha1 added to keytab FILE:/etc/krb5.keytab.
    Entry for principal nfs/<host_name>@EXAMPLE.COM with kvno 2, encryption type des-cbc-md5 added to keytab FILE:/etc/krb5.keytab.
  4. /etc/ganesha/ganesha.conf ファイルを以下のように更新します。
    NFS_KRB5
    {
            PrincipalName = nfs ;
            KeytabPath = /etc/krb5.keytab ;
            Active_krb5 = true ;
    }
  5. nfs-ganesha が対応するさまざまな kerberos セキュリティーフレーバー (krb5、krb5i、および krb5p)に基づいて、適切なセキュリティー flavour を持つボリュームエクスポートファイル (/var/run/gluster/shared_storage/nfs-ganesha/exports) に 'SecType' パラメーターを設定します。
    注記
    3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
  6. 非特権ユーザーを作成し、作成されるユーザーが中央のユーザーデータベースを介して UID に対して解決できるようにします。以下に例を示します。
    # useradd guest
    注記
    このユーザーのユーザー名は、NFS クライアント上のユーザー名と同じである必要があります。
6.3.3.6.2. NFS クライアントの設定
以下の手順を実行して、NFS クライアントを設定します。
注記
Red Hat Enterprise Linux のセキュリティー保護のために NFS-clients を設定する方法は、『Red Hat Enterprise Linux 7 Storage Administration Guide』 の 『Section 8.8.2NFS Security を参照してください。
  1. 以下のパッケージをインストールします。
    # yum install nfs-utils
    # yum install rpcbind
  2. kerberos プリンシパルを作成し、クライアント側の krb5.keytab に追加します。以下に例を示します。
    # kadmin
    # kadmin: addprinc -randkey host/<host_name>@EXAMPLE.COM
    # kadmin: ktadd host/<host_name>@EXAMPLE.COM
    # kadmin
    Authenticating as principal root/admin@EXAMPLE.COM with password.
    Password for root/admin@EXAMPLE.COM:
    
    kadmin:  addprinc -randkey host/<host_name>@EXAMPLE.COM
    WARNING: no policy specified for host/<host_name>@EXAMPLE.COM; defaulting to no policy
    Principal "host/<host_name>@EXAMPLE.COM" created.
    
    kadmin:  ktadd host/<host_name>@EXAMPLE.COM
    Entry for principal host/<host_name>@EXAMPLE.COM with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
    Entry for principal host/<host_name>@EXAMPLE.COM with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
    Entry for principal host/<host_name>@EXAMPLE.COM with kvno 2, encryption type des3-cbc-sha1 added to keytab FILE:/etc/krb5.keytab.
    Entry for principal host/<host_name>@EXAMPLE.COM with kvno 2, encryption type arcfour-hmac added to keytab FILE:/etc/krb5.keytab.
    Entry for principal host/<host_name>@EXAMPLE.COM with kvno 2, encryption type camellia256-cts-cmac added to keytab FILE:/etc/krb5.keytab.
    Entry for principal host/<host_name>@EXAMPLE.COM with kvno 2, encryption type camellia128-cts-cmac added to keytab FILE:/etc/krb5.keytab.
    Entry for principal host/<host_name>@EXAMPLE.COM with kvno 2, encryption type des-hmac-sha1 added to keytab FILE:/etc/krb5.keytab.
    Entry for principal host/<host_name>@EXAMPLE.COM with kvno 2, encryption type des-cbc-md5 added to keytab FILE:/etc/krb5.keytab.
  3. nfs-client.target サービスのステータスを確認し、起動していない場合は起動します。
    # systemctl status nfs-client.target
    # systemctl start nfs-client.target
    # systemctl enable nfs-client.target
  4. 非特権ユーザーを作成し、作成されるユーザーが中央のユーザーデータベースを介して UID に対して解決できるようにします。以下に例を示します。
    # useradd guest
    注記
    このユーザーのユーザー名は、NFS-server にあるものと同じである必要があります。
  5. kerberos セキュリティータイプを指定してボリュームをマウントします。
    # mount -t nfs -o sec=krb5 <host_name>:/testvolume /mnt
    root ですべてのアクセスが付与される必要があります。
    以下に例を示します。
    マウントポイントにディレクトリーを作成し、root としてその他の操作がすべて成功する必要があります。
    # mkdir <directory name>
  6. ゲストユーザーとしてログインします。
    # su - guest
    kerberos チケットがないと、/mnt へのすべてのアクセスは拒否される必要があります。以下に例を示します。
    # su guest
    # ls
    ls: cannot open directory .: Permission denied
  7. ゲストの kerberos チケットを取得し、/mnt にアクセスします。
    # kinit
    Password for guest@EXAMPLE.COM:
    
    # ls
    <directory created>
    重要
    このチケットでは、一部のアクセスが /mnt にアクセスできる必要があります。"guest" にアクセスできないディレクトリーが NFS-server にある場合は、正しく動作するはずです。

6.3.3.7. NFS-Ganesha サービスがダウンタイム

高可用性のアクティブ/アクティブ環境で、特定のアプリケーションを実行している NFS-Ganesha サーバーに接続されている NFS-Ganesha サーバーがダウンすると、管理上の介入なしにアプリケーション/NFS クライアントは、別の NFS-Ganesha サーバーにシームレスに接続されます。ただし、別の NFS-Ganesha サーバーへの接続に遅延またはフェイルオーバー時間があります。この遅延は、フェイルオーバー時 (接続が元のノード/サーバーにリセットされる場合) にも発生する可能性があります。
以下の一覧では、NFS サーバーがサーバーの再起動を検出または再開するのにかかった時間を説明します。
  • ganesha.nfsd が終了した場合 (crashes、oomkill、admin kill)、これを検出し、ganesha クラスターを猶予する最大時間が 20sec で、pacemaker がフェイルオーバーに必要な時間がプラスされます。
    注記
    この時間は、サービスがダウンしているかを検出するのにかかった時間ですが、すべてのノードで以下のコマンドを使用して編集できます。
    # pcs resource op remove nfs-mon monitor
    # pcs resource op add nfs-mon monitor interval=<interval_period_value>
  • ノード全体が機能しなくなった場合 (ネットワークの障害を含む)、このダウンタイムは、pacemaker がノードがなくなったことを検知するために必要な合計時間、クラスターを正常に設定する時間、および障害の発生時間が発生する時間です。これは ~20 秒です。
  • そのため、max-fail-over 時間は約 20-22 秒であり、通常、平均時間は短くなります。つまり、NFS クライアントがサーバーの再起動を検出または再開するのにかかった時間は 20 - 22 秒です。
6.3.3.7.1. フェイルオーバー時間の変更
フェイルオーバー後、短い期間でクライアントが失われた OPEN/LOCK 状態を再利用しようとします。サーバーは、NFS 仕様に従って、この期間中に特定のファイル操作をブロックします。ブロックされたファイル操作は以下のとおりです。

表6.7

プロトコル ファイル操作
NFSV3
  • SETATTR
NLM
  • LOCK
  • UNLOCK
  • SHARE
  • UNSHARE
  • CANCEL
  • LOCKT
NFSV4
  • LOCK
  • LOCKT
  • OPEN
  • REMOVE
  • RENAME
  • SETATTR
注記
LOCK、SHARE、および UNSHARE は、回収が FALSE に設定された場合にのみブロックされます。
OPEN は、CLAIM_PREVIOUS または CLAIM_DELEGATE_PREV 以外の要求タイプで要求された場合にブロックされます。
猶予期間のデフォルト値は 90 秒です。この値は、/etc/ganesha/ganesha.conf ファイルに以下の行を追加すると変更できます。
NFSv4 {
Grace_Period=<grace_period_value_in_sec>;
}
/etc/ganesha/ganesha.conf ファイルを編集したら、すべてのノードで以下のコマンドを使用して NFS-Ganesha サービスを再起動します。

Red Hat Enterprise Linux 7 の場合

# systemctl restart nfs-ganesha

6.3.3.8. NFS-Ganesha 用 Readdir パフォーマンスのチューニング

NFS-Ganesha プロセスは、インスタンス内のディレクトリーのコンテンツ全体を読み取ります。このディレクトリーの並列操作は、readdir 操作が完了するまで一時停止されます。Red Hat Gluster Storage 3.5 では、Dir_Chunk パラメーターにより、インスタンスのチャンクでディレクトリーコンテンツを読み込むことができます。このパラメーターはデフォルトで有効になります。このパラメーターのデフォルト値は 128 です。このパラメーターの範囲は、1 から UINT32_MAX です。このパラメーターを無効にするには、値を 0 に設定します。

手順6.1 NFS-Ganesha の場合の readdir パフォーマンスの設定

  1. /etc/ganesha/ganesha.conf ファイルを編集します。
  2. CACHEINODE ブロックを見つけます。
  3. ブロック内に Dir_Chunk パラメーターを追加します。
    CACHEINODE {
            Entries_HWMark = 125000;
            Chunks_HWMark = 1000;
            Dir_Chunk = 128; # Range: 1 to UINT32_MAX, 0 無効にするには以下を行います。
    }
  4. ganesha.conf ファイルを保存して、すべてのノードで NFS-Ganesha サービスを再起動します。
    # systemctl restart nfs-ganesha

6.3.3.9. NFS Ganesha のトラブルシューティング

必須のチェック

発生したすべての問題/違反について、必ず以下のコマンドを実行します。

  • すべての前提条件を満たしていることを確認します。
  • 以下のコマンドを実行して、サービスのステータスを確認します。
    # service nfs-ganesha status
    # service pcsd status
    # service pacemaker status
    # pcs status
  • 以下のログを確認し、失敗の原因を確認します。
    /var/log/ganesha/ganesha.log
    /var/log/ganesha/ganesha-gfapi.log
    /var/log/messages
    /var/log/pcsd.log
    
  • 状況

    NFS-Ganesha が起動に失敗します。

    解決策

    以下の手順に進む前に、すべての必須チェックを実行して root 原因を理解するようにしてください。以下の手順に従い、問題を修正します。

    1. カーネルおよび gluster nfs サービスが無効になっていることを確認します。
    2. ポート 875 が RQUOTA サービスに接続できることを確認します。
    3. ノードの再起動/シャットダウン後に、共有ストレージボリュームマウントがサーバーに存在することを確認します。存在しない場合は、以下のコマンドを実行して、共有ストレージボリュームを手動でマウントします。
      # mount -t glusterfs <local_node's_hostname>:gluster_shared_storage /var/run/gluster/shared_storage
      注記
      3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
    詳しくは、「『Exporting and Unexporting Volumes through NFS-Ganesha.』」のセクションを参照してください。
  • 状況

    NFS-Ganesha ポート 875 は利用不可です。

    解決策

    以下の手順に進む前に、すべての必須チェックを実行して root 原因を理解するようにしてください。以下の手順に従い、問題を修正します。

    1. ポート 875 を使用して、プロセスの PID を抽出するには、以下のコマンドを実行します。
      netstat -anlp | grep 875
    2. ポート 875 を使用するプロセスが重要なシステムまたはユーザープロセスであるかどうかを判断します。
    3. プロセスの重要性に応じて、以下のいずれかを実行します。
      • ポート 875 を使用するプロセスが重要なシステムまたはユーザーのプロセスである場合:
        1. すべてのノードの ‘/etc/ganesha/ganesha.conf’ ファイルで以下の行を変更して、別のポートをこのサービスに割り当てます。
          # Use a non-privileged port for RQuota
          Rquota_Port = port_number;
        2. ポート番号を変更したら、以下のコマンドを実行します。
          # semanage port -a -t mountd_port_t -p tcp port_number
          # semanage port -a -t mountd_port_t -p udp port_number
        3. 以下のコマンドを実行して NFS-Ganesha を再起動します。
          systemctl restart nfs-ganesha
      • ポート 875 を使用するプロセスが重要なシステムまたはユーザーのプロセスでない場合:
        1. ポート 875 を使用してプロセスを強制終了するには、以下のコマンドを実行します。
          # kill pid;
          前の手順で抽出したプロセス ID を使用します。
        2. 以下のコマンドを実行して、プロセスが強制終了され、ポート 875 が未使用であることを確認します。
          # ps aux | grep pid;
        3. 以下のコマンドを実行して NFS-Ganesha を再起動します。
          systemctl restart nfs-ganesha
        4. 必要に応じて、強制終了したプロセスを再起動します。
  • 状況

    NFS-Ganesha クラスターの設定に失敗します。

    解決策

    以下の手順に進む前に、すべての必須チェックを実行して root 原因を理解するようにしてください。

    1. カーネルおよび gluster nfs サービスが無効になっていることを確認します。
    2. pcs cluster auth コマンドが、ユーザー hacluster用の同じパスワードを持つすべてのノードで実行されていることを確認します。
    3. 共有ストレージがすべてのノードにマウントされていることを確認します。
    4. HA クラスターの名前が 15 文字を超えないようにしてください。
    5. OMPING を使用して UDP マルチキャストパケットが ping できることを確認します。
    6. 仮想 IP がどの NIC にも割り当てられていないことを確認します。
  • 状況

    NFS-Ganesha は起動し、ボリュームのエクスポートに失敗します。

    解決策

    以下の手順に進む前に、すべての必須チェックを実行して root 原因を理解するようにしてください。以下の手順に従い、問題を修正します。

    1. 以下のコマンドを使用して、ボリュームが Started の状態であることを確認します。
      # gluster volume status <volname>
      
    2. 以下のコマンドを実行して、サービスのステータスを確認します。
      # service nfs-ganesha status
      # showmount -e localhost
    3. 以下のログを確認し、失敗の原因を確認します。
      /var/log/ganesha/ganesha.log
      /var/log/ganesha/ganesha-gfapi.log
      /var/log/messages
    4. 以下のコマンドを使用して、dbus サービスが実行中であることを確認します。
      # service messagebus status
    5. ボリュームが開始状態でない場合は、以下のコマンドを実行してボリュームを起動します。
      # gluster volume start <volname>
      ボリュームがボリュームの起動時にエクスポートされていない場合は、以下のコマンドを実行してボリュームを再度エクスポートします。
      # /usr/libexec/ganesha/dbus-send.sh /var/run/gluster/shared_storage on <volname>
      注記
      3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
  • 状況

    新規ノードを HA クラスターに追加すると失敗します。

    解決策

    以下の手順に進む前に、すべての必須チェックを実行して root 原因を理解するようにしてください。以下の手順に従い、問題を修正します。

    1. クラスターに含まれるノードのいずれかから、以下のコマンドを実行します。
      # ganesha-ha.sh --add <HA_CONF_DIR>  <NODE-HOSTNAME>  <NODE-VIP>
    2. gluster_shared_storage ボリュームが、追加する必要のあるノードにマウントさることを確認します。
    3. クラスターのすべてのノードが、追加する必要のあるノードから DNS を解決できることを確認します。
    4. 追加する必要のあるノード上の HA クラスターの各ホストに対して、以下のコマンドを実行します。
      Red Hat Enterprize Linux 7 の場合:
      # pcs cluster auth <hostname>
      Red Hat Enterprize Linux 8 の場合:
      # pcs host auth <hostname>
  • 状況

    nfs-ganesha HA クラスターの設定に失敗した場合に必要なクリーンアップ。

    解決策

    マシンを元の状態に復元するには、クラスターを構成する各ノードで以下のコマンドを実行します。

    # /usr/libexec/ganesha/ganesha-ha.sh --teardown /var/run/gluster/shared_storage/nfs-ganesha
    # /usr/libexec/ganesha/ganesha-ha.sh --cleanup /var/run/gluster/shared_storage/nfs-ganesha
    # systemctl stop nfs-ganesha
    注記
    3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
  • 状況

    パーミッションの問題。

    解決策

    デフォルトでは、CLI を使用して NFS-Ganesha を起動する場合は、root squash オプションが無効になります。パーミッションに問題が発生した場合は、エクスポートしたエントリーの unix パーミッションを確認してください。

6.4. SMB

サーバーの SMB 共有として Red Hat Gluster Storage ボリュームにディレクトリーをエクスポートすることで、Server Message Block (SMB) プロトコルを使用して Red Hat Gluster Storage ボリュームにアクセスできます。
本セクションでは、SMB 共有を有効にし、手動で SMB 共有を Microsoft Windows および macOS ベースのクライアントにマウントする方法、共有が正常にマウントされたことを確認する方法を説明します。
警告
パフォーマンストランスレーターを有効にすると、複数のクライアントが同じデータにアクセスすると、データの不整合が確認されます。データの不整合を回避するには、パフォーマンストランスレーターを無効にするか、このようなワークロードを回避してください。
以下に概説したプロセスに従います。概要の詳細は、本セクションの後半で説明します。

SMB 共有の設定の概要

  1. 「Red Hat Gluster Storage で SMB を使用する要件」 に概説した要件を満たしていることを確認します。
  2. レプリケーションを使用するボリュームを共有する場合は、CTDB 「Samba への CTDB の設定」 を設定します。
  3. SMB を使用してボリュームを共有するように設定する: 「SMB でのボリュームの共有」
  4. macOS クライアントにボリュームをマウントする場合には、「macOS ユーザーのアプレット作成コンテキストの設定」
  5. ユーザーアクセスパーミッションを設定します( 「非特権ユーザーの読み取り/書き込みアクセスの設定」 )。
  6. クライアントに共有ボリュームをマウントします。
  7. 共有ボリュームが適切に機能していることを確認します。 「設定の開始と検証」

6.4.1. Red Hat Gluster Storage で SMB を使用する要件

  • Samba は、Red Hat Gluster Storage で SMB プロトコルのサポートと相互運用性を維持するために必要です。また、SMB を使用して複製したボリュームを共有する場合は、CTDB が必要です。SMB サポートの正しいチャンネルへのサブスクライブ情報は、『Red Hat Gluster Storage 3.5 Installation Guide』 の Subscribing to the Red Hat Gluster Storage server channels を参照してください。
  • ランタイムおよび永続モードのアクティブなゾーンで Samba ファイアウォールサービスを有効にします。以下のコマンドは、Red Hat Enterprise Linux 7 をベースとするシステムを対象にしています。
    アクティブゾーンの一覧を取得するには、以下のコマンドを実行します。
    # firewall-cmd --get-active-zones
    アクティブなゾーンでファイアウォールサービスを許可するには、次のコマンドを実行します。
    # firewall-cmd --zone=zone_name --add-service=samba
    # firewall-cmd --zone=zone_name --add-service=samba  --permanent

6.4.2. Samba への CTDB の設定

SMB を使用してレプリケーションを使用するボリュームを共有する場合は、高可用性とロック同期を提供するように CTDB (Cluster Trivial Database) を設定する必要があります。
CTDB は、仮想 IP アドレス (VIP) およびハートビートサービスを追加して高可用性を提供します。信頼されたストレージプールのノードに障害が発生した場合、CTDB により、障害が発生したノードがホストしていた仮想 IP アドレスを別のノードを引き継ぐことができます。これにより、提供されるサービスの IP アドレスが常に利用できるようになります。
重要
Amazon Elastic Compute Cloud (EC2) は仮想 IP をサポートしないため、このソリューションとの互換性はありません。

前提条件

  • 古いバージョンの CTDB (バージョン <= ctdb1.x) がすでにある場合は、以下のコマンドを実行して CTDB を削除します。
    # yum remove ctdb
    古いバージョンを削除したら、最新の CTDB のインストールに進みます。
    注記
    最新の CTDB パッケージを取得するには、システムが samba チャンネルにサブスクライブしていることを確認してください。
  • 以下のコマンドを実行して、Samba サーバーとして使用されるすべてのノードに CTDB をインストールします。
    # yum install ctdb
  • Samba の CTDB ベースの高可用性環境では、ロックはフェイルオーバー時に移行されません。
  • ランタイムおよび永続モードのアクティブなゾーンで CTDB ファイアウォールサービスを有効にします。以下のコマンドは、Red Hat Enterprise Linux 7 をベースとするシステムを対象にしています。
    アクティブゾーンの一覧を取得するには、以下のコマンドを実行します。
    # firewall-cmd --get-active-zones
    アクティブゾーンにポートを追加するには、次のコマンドを実行します。
    # firewall-cmd --zone=zone_name --add-port=4379/tcp
    # firewall-cmd --zone=zone_name --add-port=4379/tcp  --permanent

ベストプラクティス

  • CTDB には、Gluster 内部ネットワークとは異なるブロードキャストドメインが必要です。Samba でエクスポートされた Gluster ボリュームにアクセスするために Windows クライアントが使用するネットワークは、内部の Gluster ネットワークとは異なります。これを実行できないと、ノード間に CTDB のフェイルオーバーがある場合や、Windows のファイル共有にアクセスするパフォーマンスが低下した場合に多すぎる可能性があります。
    たとえば、CTDB がネットワーク 192.168.10.X で実行されている誤った設定例を以下に示します。
    Status of volume: ctdb
    Gluster process                             TCP Port  RDMA Port  Online  Pid
    Brick node1:/rhgs/ctdb/b1                   49157     0          Y       30439
    Brick node2:/rhgs/ctdb/b1                   49157     0          Y       3827
    Brick node3:/rhgs/ctdb/b1                   49157     0          Y       89421
    Self-heal Daemon on localhost                N/A      N/A        Y       183026
    Self-heal Daemon on sesdel0207               N/A      N/A        Y       44245
    Self-heal Daemon on segotl4158               N/A      N/A        Y       110627
    
    cat ctdb_listnodes
    
    192.168.10.1
    192.168.10.2
    
    cat ctdb_ip
    Public IPs on node 0
    192.168.10.3 0
    
    注記
    ホスト名 node1、node2、および node3 は、ブリックを設定し、同じネットワーク 192.168.10.X の IP を解決するために使用されます。Windows クライアントは内部 Gluster ネットワークを使用してファイル共有にアクセスしているため、これは当てはまらないはずです。
  • また、CTDB ネットワークと Gluster 内部ネットワークは、別の物理インターフェースで実行する必要があります。Red Hat では、パフォーマンスを向上させるために 10GbE インターフェースを推奨します。
  • Gluster ネットワークおよび CTDB ネットワークに同じネットワーク帯域幅を使用することが推奨されます。異なるネットワーク速度を使用すると、パフォーマンスのボトルネックが生じる可能性があります。内部ネットワークと外部ネットワークの両方で同じネットワークトラフィックが予想されます。

Red Hat Gluster Storage サーバーでの CTDB の設定

  1. CTDB ロックファイルを格納するために、複製されたボリュームを新たに作成します。ロックファイルのサイズはゼロバイトであるため、小さいブリックを使用してください。
    複製されたボリュームを作成するには、以下のコマンドを実行します。N は、複製するノード数に置き換えます。
    # gluster volume create volname replica N ip_address_1:brick_path ... ip_address_N:brick_path
    以下に例を示します。
    # gluster volume create ctdb replica 3 10.16.157.75:/rhgs/brick1/ctdb/b1 10.16.157.78:/rhgs/brick1/ctdb/b2 10.16.157.81:/rhgs/brick1/ctdb/b3
  2. 以下のファイルで、META="all"" のステートメントの all を、すべて 新たに作成されたボリューム名に置き換えます (例: META="ctdb")。
    /var/lib/glusterd/hooks/1/start/post/S29CTDBsetup.sh
    /var/lib/glusterd/hooks/1/stop/pre/S29CTDB-teardown.sh
  3. /etc/samba/smb.conf ファイルで、全ノードの global セクションに以下の行を追加します。
    clustering=yes
  4. ボリュームを起動します。
    # gluster volume start ctdb
    S29CTDBsetup.sh スクリプトはすべての Red Hat Gluster Storage サーバーで実行され、マウント用に /etc/fstab のエントリーを追加し、Samba サーバーがあるすべてのノードで /gluster/lock にボリュームをマウントします。また、起動時に CTDB サービスの自動起動も有効にします。
    注記
    特別な CTDB ボリュームを停止すると、S29CTDB-teardown.sh スクリプトがすべての Red Hat Gluster Storage サーバーで実行され、マウント用に /etc/fstab のエントリーを削除し、/gluster/lock でボリュームをアンマウントします。
  5. Samba サーバーとして使用されるすべてのノードに /etc/ctdb ディレクトリー が存在することを確認します。このファイルには、Red Hat Gluster Storage に推奨される CTDB 設定情報が含まれます。
  6. Samba サーバーとして使用されるすべてのノードに /etc/ctdb/nodes ファイルを作成し、これらのノードの IP アドレスをファイルに追加します。
    10.16.157.0
    10.16.157.3
    10.16.157.6
    ここに一覧表示される IP アドレスは、Samba サーバーのプライベート IP アドレスです。
  7. Samba サーバーとして使用されるノードで、IP フェイルオーバーが必要なノードで /etc/ctdb/public_addresses ファイルを作成します。CTDB が作成する仮想 IP アドレスを以下の形式でファイルに追加します。
    VIP/routing_prefix network_interface
    以下に例を示します。
    192.168.1.20/24 eth0
    192.168.1.21/24 eth0
  8. すべてのノードで CTDB サービスを起動します。
    RHEL 7 および RHEL 8 で以下を実行します。
    # systemctl start ctdb
    RHEL 6 で以下を実行します。
    # service ctdb start

6.4.3. SMB でのボリュームの共有

このプロセスに従うと、Samba を実行するサーバーで設定された gluster ボリュームはすべて、ボリュームの起動時に自動的にエクスポートされます。
/etc/samba/smb.conf に追加されたデフォルトのボリューム共有については、以下の例を参照してください。
[gluster-VOLNAME]
comment = For samba share of volume VOLNAME
vfs objects = glusterfs
glusterfs:volume = VOLNAME
glusterfs:logfile = /var/log/samba/VOLNAME.log
glusterfs:loglevel = 7
path = /
read only = no
guest ok = yes
設定オプションについては、以下の表で説明されています。

表6.8 設定オプション

設定オプション 必須? デフォルト値 説明
パス Yes 該当なし これは、共有している gluster ボリュームのルートに相対的なパスを表します。したがって 、/ は gluster ボリュームのルートを表します。ボリュームのサブディレクトリーのエクスポートはサポートされており、パスの /subdir は、そのボリュームのサブディレクトリーのみをエクスポートします。
glusterfs:volume はい 該当なし 共有されるボリューム名。
glusterfs:logfile いいえ NULL vfs プラグインによって読み込まれる gluster モジュールによって使用されるログファイルへのパス。smb.conf に記載されている標準の Samba 変数の置き換え がサポートされます。
glusterfs:loglevel いいえ 7 このオプションは、gluster の client-log-level オプションと同等です。7 はデフォルト値で、INFO レベルに対応します。
glusterfs:volfile_server いいえ localhost ボリュームの volfile をフェッチするために接続される Gluster サーバー。値は空白区切り要素のリストで、各要素が unix+/path/to/socket/file または [tcp+]IP|hostname|\[IPv6\][:port]になります。
samba でボリュームを共有する手順は、選択した Samba のバージョンによって異なります。

以前のバージョンの Samba を使用している場合は、以下を行います。

  1. SMB 固有のキャッシュを有効にします。
    # gluster volume set VOLNAME performance.cache-samba-metadata on
    汎用メタデータキャッシュを有効にしてパフォーマンスを向上させることもできます。詳細は、「ディレクトリー操作」 を参照してください。
  2. 各 Red Hat Gluster Storage ノードで glusterd サービスを再起動します。
  3. 適切なロックと I/O 一貫性を確認します。
    # gluster volume set VOLNAME storage.batch-fsync-delay-usec 0
注記
RHEL ベースの Red Hat Gluster Storage が Samba で 3.5 バッチ更新 4 にアップグレードするには、既存のすべての samba ボリュームに対して、write-behind トランスレーターを手動で無効にする必要があります。
# gluster volume set <volname> performance.write-behind off

Samba-4.8.5-104 以降を使用している場合は、以下を行います。

  1. Samba 経由で gluster 共有としてエクスポートするには、以下のボリュームオプション user.cifs または user.smb のいずれかが必要です。
    user.cifs ボリュームオプションを有効にするには、以下のコマンドを実行します。
    # gluster volume set VOLNAME user.cifs enable
    user.smb を有効にするには、以下を実行します。
    # gluster volume set VOLNAME user.smb enable
    Red Hat Gluster Storage 3.4 では、Samba-CTDB 設定に必要なボリュームオプションを設定する group コマンド samba が導入されました。
  2. 以下のコマンドを実行して、Samba-CTDB のボリュームオプションを設定します。
    # gluster volume set VOLNAME group samba
    このコマンドは、Samba-CTDB 設定の以下のオプションを有効にします。
    • performance.readdir-ahead: on
    • performance.parallel-readdir: on
    • performance.nl-cache-timeout: 600
    • performance.nl-cache: on
    • performance.cache-samba-metadata: on
    • network.inode-lru-limit: 200000
    • performance.md-cache-timeout: 600
    • performance.cache-invalidation: on
    • features.cache-invalidation-timeout: 600
    • features.cache-invalidation: on
    • performance.stat-prefetch: on

Samba-4.9.8-109 以降を使用している場合は、以下を行います。

以下のステップは厳密にオプションであり、多数のクライアントがボリュームに接続されている環境や、複数のボリュームが使用されている環境で稼働します。
Red Hat Gluster Storage 3.5 では、対応する FUSE マウントパスからボリューム共有を設定するオプションの方法が導入されました。以下の手順は、クラスター内のすべてのノードで実行する必要があります。
  1. Samba 経由で Gluster ボリュームを共有するすべての Gluster ノードに、ネイティブ Gluster プロトコル Fuse を使用するローカルマウントがあります。FUSE で GlusterFS ボリュームをマウントし、詳細な手順のために FUSE マウントポイントを記録します。
    /etc/fstab にエントリーを追加します。
    localhost:/myvol /mylocal glusterfs defaults,_netdev,acl 0 0
    以下は例になります。
    localhost:/myvol 4117504 1818292 2299212 45% /mylocal
    gluster volume は myvol で、/mylocalにマウントされる場合
  2. /etc/samba/smb.confにある samba 共有設定ファイルを編集します。
    [gluster-VOLNAME]
    comment = For samba share of volume VOLNAME
    vfs objects = glusterfs
    glusterfs:volume = VOLNAME
    glusterfs:logfile = /var/log/samba/VOLNAME.log
    glusterfs:loglevel = 7
    path = /
    read only = no
    guest ok = yes
    • vfs objects パラメーター値を glusterfs_fuse に編集します
      vfs objects = glusterfs_fuse
    • 以前に記録された FUSE マウントポイントに path パラメーター値を編集します。以下に例を示します。
      path = /MOUNTDIR
  3. SELinux を Enforcing モードで使用して、SELinux ブール値 samba_share_fusefs をオンにします。
    # setsebool -P samba_share_fusefs on
注記
  • 作成される新規ボリュームは、デフォルトの vfs objects パラメーターを使用して自動的に設定されます。
  • samba 共有設定ファイルへの変更は、Gluster CLI を使用してボリュームが削除されるまで、ボリュームの再起動後も保持されます。
  • ボリューム VOLNAME で Gluster CLI 操作の一部として呼び出される Samba フックスクリプトは、[gluster-VOLNAME] という名前の Samba 共有でのみ動作します。つまり、フックスクリプトは、[VOLNAME] と呼ばれる samba 共有の samba 共有設定ファイルを削除したり、変更したりしません。

次に、すべての Samba バージョンに対して以下を実行します。

  1. SMB/CIFS 共有からボリュームにアクセスできることを確認します。
    # smbclient -L <hostname> -U%
    以下に例を示します。
    # smbclient -L rhs-vm1 -U%
    Domain=[MYGROUP] OS=[Unix] Server=[Samba 4.1.17]
    
         Sharename       Type      Comment
         ---------       ----      -------
         IPC$            IPC       IPC Service (Samba Server Version 4.1.17)
         gluster-vol1    Disk      For samba share of volume vol1
    Domain=[MYGROUP] OS=[Unix] Server=[Samba 4.1.17]
    
         Server               Comment
         ---------            -------
    
         Workgroup            Master
         ---------            -------
  2. ユーザーが SMB/CIFS 共有にアクセスできることを確認します。
    # smbclient //<hostname>/gluster-<volname> -U <username>%<password>
    以下に例を示します。
    # smbclient //10.0.0.1/gluster-vol1 -U root%redhat
    Domain=[MYGROUP] OS=[Unix] Server=[Samba 4.1.17]
    smb: \> mkdir test
    smb: \> cd test\
    smb: \test\> pwd
    Current directory is \\10.0.0.1\gluster-vol1\test\
    smb: \test\>

6.4.4. 共有ボリュームへのユーザーアクセスの設定

6.4.4.1. macOS ユーザーのアプレット作成コンテキストの設定

  1. 以下の行を smb.conf ファイルの [global] セクションに追加します。表示されるインデントレベルが必要なことに注意してください。
                fruit:aapl = yes
                ea support = yes
  2. smb.conf ファイルのボリュームのエクスポート設定ブロックに次の行を追加して、vfs _fruit モジュールとその依存関係を読み込みます。
    vfs objects = fruit streams_xattr glusterfs
    以下は例になります。
    [gluster-volname]
    comment = For samba share of volume smbshare
    vfs objects = fruit streams_xattr glusterfs
    glusterfs:volume = volname
    glusterfs:logfile = /var/log/samba/glusterfs-volname-fruit.%M.log
    glusterfs:loglevel = 7
    path = /
    read only = no
    guest ok = yes
    
    fruit:encoding = native

6.4.4.2. 非特権ユーザーの読み取り/書き込みアクセスの設定

  1. 設定に基づいてすべての Samba サーバーにユーザーを追加します。
    # adduser username
  2. すべての Samba サーバーの Samba ユーザーの一覧にユーザーを追加し、以下のコマンドを実行してパスワードを割り当てます。
    # smbpasswd -a username
  3. その他の Samba サーバーから、FUSE プロトコルを使用してボリュームをマウントします。
    # mount -t glusterfs -o acl ip-address:/volname /mountpoint
    以下は例になります。
    # mount -t glusterfs -o acl rhs-a:/repvol /mnt
  4. setfacl コマンドを使用して、ディレクトリーへのアクセスに必要なパーミッションを指定します。
    # setfacl -m user:username:rwx mountpoint
    以下は例になります。
    # setfacl -m user:cifsuser:rwx /mnt

6.4.5. SMB を使用したボリュームのマウント

6.4.5.1. Red Hat Enterprise Linux で SMB でエクスポートしたボリュームの手動マウント

  1. クライアントに cifs-utils パッケージをインストールします。
    # yum install cifs-utils
  2. 構文の例を参考にして、mount -t cifs を実行して、エクスポートした SMB 共有をマウントします。
    # mount -t cifs -o user=username,pass=password  //hostname/gluster-volname /mountpoint
    Red Hat Enterprise Linux 6 にボリュームをマウントする場合は、sec=ntlmssp パラメーターも必要になります。
    # mount -t cifs -o user=username,pass=password,sec=ntlmssp //hostname/gluster-volname /mountpoint
    以下は例になります。
    # mount -t cifs -o user=cifsuser,pass=redhat,sec=ntlmssp //server1/gluster-repvol /cifs
    重要
    Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。『 インストールガイド』の「 『バージョンの詳細』 表」 『および「Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 」を参照してください。
  3. サーバーで # smbstatus -S を実行して、ボリュームのステータスを表示します。
    Service        pid     machine             Connected at
    -------------------------------------------------------------------
    gluster-VOLNAME 11967   __ffff_192.168.1.60  Mon Aug  6 02:23:25 2012

6.4.5.2. Microsoft Windows で SMB でエクスポートしたボリュームの手動マウント

6.4.5.2.1. Microsoft Windows Explorer を使用したボリュームの手動マウント
  1. Windows Explorer で ToolsMap Network Drive… をクリックし、Map Network Drive 画面を開きます。
  2. ドライブドロップダウンリストを使用して、Drive を選択します。
  3. Folder テキストボックスで、サーバーと共有リソースのパスを次のフォーマットで指定します。\\SERVER_NAME\VOLNAME
  4. Finish をクリックしてプロセスを完了し、Windows Explorer でネットワークドライブを表示します。
  5. ネットワークドライブに移動し、正しくマウントされたことを確認します。
6.4.5.2.2. Microsoft Windows コマンドラインインターフェースを使用したボリュームの手動マウント
  1. StartRun を クリックしてから cmd を入力します。
  2. net use z: \\SERVER_NAME\VOLNAME を入力します 。z: は、共有ボリュームに割り当てるドライブの文字です。
    たとえば、net は y: \\server1\test-volume を使用します
  3. ネットワークドライブに移動し、正しくマウントされたことを確認します。

6.4.5.3. macOS において SMB でエクスポートしたボリュームの手動マウント

前提条件

  • Samba 設定で、SMB Apple Create Context を使用できることを確認します。
  • 使用するユーザー名が、ボリュームの許可されたユーザーの一覧にあることを確認します。

手動マウントプロセス

  1. Finder で、Go > Connect to Server をクリックします。
  2. Server Address フィールドに、マウントするボリュームをホストする Red Hat Gluster Storage サーバーの IP アドレスまたはホスト名を入力します。
  3. Connect をクリックします。
  4. プロンプトが表示されたら、Registered User を選択して、有効なユーザー名とパスワードを使用してボリュームに接続します。
    必要に応じて、ユーザー名とパスワードを入力し、マウントするサーバーボリュームまたは共有フォルダーを選択します。
    今後コンピューターへの接続を容易にするには、Remember this password in my keychain を選択し、コンピューターのユーザー名とパスワードをキーチェーンに追加します。
macOS へのボリュームのマウントに関する詳細は、アプレットのサポートに関するドキュメントを参照してください https://support.apple.com/en-in/guide/mac-help/mchlp1140/mac

6.4.5.4. Red Hat Enterprise Linux で SMB を使用してエクスポートしたボリュームの自動マウントの設定

  1. テキストエディターで /etc/fstab ファイルを開き、以下の詳細を含む行を追加します。
    \\HOSTNAME|IPADDRESS\SHARE_NAME MOUNTDIR cifs OPTIONS DUMP FSCK
    OPTIONS 列で、認証情報 オプションを指定するようにしてください。
    上記のサーバー名例を使用すると、エントリーには以下の置換値が含まれます。
    \\server1\test-volume /mnt/glusterfs cifs credentials=/etc/samba/passwd,_netdev 0 0
    Red Hat Enterprise Linux 6 にボリュームをマウントする場合は、sec=ntlmssp パラメーターも必要になります。以下に例を示します。
    \\server1\test-volume /mnt/glusterfs cifs credentials=/etc/samba/passwd,_netdev,sec=ntlmssp 0 0
    これらのオプションの詳細は、man ページの mount.cifs を参照してください。
    重要
    Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。『 インストールガイド』の「 『バージョンの詳細』 表」 『および「Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 」を参照してください。
  2. クライアントで # smbstatus -S を実行して、ボリュームのステータスを表示します。
    Service        pid     machine             Connected at
    -------------------------------------------------------------------
    gluster-VOLNAME 11967   __ffff_192.168.1.60  Mon Aug  6 02:23:25 2012

6.4.5.5. Microsoft Windows で SMB でエクスポートしたボリュームの自動マウントの設定

  1. Windows Explorer で ToolsMap Network Drive… をクリックし、Map Network Drive 画面を開きます。
  2. ドライブドロップダウンリストを使用して、Drive を選択します。
  3. Folder テキストボックスで、サーバーと共有リソースのパスを次のフォーマットで指定します。\\SERVER_NAME\VOLNAME
  4. Reconnect at logon チェックボックスをクリックします。
  5. Finish をクリックしてプロセスを完了し、Windows Explorer でネットワークドライブを表示します。
  6. Windows Security 画面が表示されたら、ユーザー名とパスワードを入力して OK をクリックします。
  7. ネットワークドライブに移動し、正しくマウントされたことを確認します。

6.4.5.6. macOS で SMB でエクスポートしたボリュームの自動マウントの設定

  1. 「macOS において SMB でエクスポートしたボリュームの手動マウント」 」に記載のプロセスを使用して、ボリュームを手動でマウントします。
  2. Finder で、System Preferences > Users & Groups > Username > Login Items の順にクリックします
  3. マウントされたボリュームをログイン項目一覧にドラッグします。
    起動時やログインするたびに、ドライブのウィンドウが開かないようにするには、Hide をオンにします。
macOS へのボリュームのマウントに関する詳細は、アプレットのサポートに関するドキュメントを参照してください https://support.apple.com/en-in/guide/mac-help/mchlp1140/mac

6.4.6. 設定の開始と検証

設定を開始して確認します。

設定の確認

シャットダウンサーバーの仮想 IP (VIP) アドレスが複製されたボリュームの別のサーバーに引き継がれることを確認します。
  1. 以下のコマンドを使用して、CTDB が実行中であることを確認します。
    # ctdb status
    # ctdb ip
    # ctdb ping -n all
  2. 仮想 IP のいずれかを使用して Red Hat Gluster Storage ボリュームをマウントします。
  3. # ctdb ip を実行して、VIP を提供する物理サーバーを見つけます。
  4. CTDB VIP サーバーをシャットダウンして、設定が正常に行われたことを確認します。
    仮想 IP を提供する Red Hat Gluster Storage サーバーがシャットダウンすると、数秒一時停止すると、I/O が再開します。

6.4.7. SMB 共有の無効化

すべてのボリュームに対する全ノードでの自動共有を停止するには、以下の手順を実施します。

  1. 権限が昇格されたすべての Red Hat Gluster Storage サーバーで、/var/lib/glusterd/hooks/1/start/post に移動します。
  2. S30samba-start.sh の名前を K30samba-start.sh に変更します。
    これらのスクリプトの詳細は、「13.2, Prepackaged Scripts」を参照してください。

1 つの特定ボリュームに対する全ノードでの自動共有を停止するには、次のコマンドを実行します。

  1. 以下のコマンドを実行して、ボリュームごとの自動 SMB 共有を無効にします。
    # gluster volume set <VOLNAME> user.smb disable

6.4.8. Windows でのスナップショットへのアクセス

スナップショットは、ボリュームの読み取り専用のポイントインタイムコピーです。Windows には、ボリューム Shadow-copy サービス (VSS としても知られる) を介してスナップショットを参照する組み込みメカニズムがあります。この機能を使用すると、最小限のステップで、以前のバージョンのファイルやフォルダーにアクセスできます。
注記
Shadow Copy (Volume Shadow-copy Service (VSS) とも呼ばれます) は、スナップショットの表示以外に、コンピューターファイルまたはボリュームのスナップショットを取得できる Microsoft Windows に含まれるテクノロジーです。現在、スナップショットの表示のみをサポートしています。このインターフェースを使用したスナップショットの作成はサポートされていません。

6.4.8.1. デスティネーションコピーの設定

シャドウコピーを設定するには、smb.conf ファイルで以下の設定を変更/編集する必要があります。smb.conf ファイルは etc/samba/smb.conf にあります。
注記
shadow_copy2 モジュールが smb.conf で有効になっていることを確認します。以下のパラメーターを vfs オブジェクトオプションに追加するには、以下を実行します。
以下に例を示します。
vfs objects = shadow_copy2 glusterfs

表6.9 設定オプション

設定オプション 必須? デフォルト値 説明
shadow:snapdir Yes 該当なし スナップショットが保持されるディレクトリーへのパス。snapdir の名前は .snaps にする必要があります。
shadow:basedir Yes 該当なしスナップショット元となるベースディレクトリーへのパス。basedir の値は / である必要があります。
shadow:sort Optional 分類されていない サポートされる値は asc/desc です。このパラメーターにより、シャドウコピーディレクトリーをクライアントに送信する前にソートすることができます。これは、通常、unix ファイルシステムがアルファベット順でソートされないため、有益です。有効にすると、降順で指定されます。
shadow:localtime Optional UTC これは、スナップショット名が UTC/GMT またはローカルタイムであることを示すオプションのパラメーターです。
shadow:format Yes 該当なし このパラメーターは、スナップショットの命名形式を指定します。形式は、str[fp]time が認識する変換仕様と互換性がある必要があります。デフォルト値は _GMT-%Y.%m.%d-%H.%M.%S です。
shadow:fixinodesOptionalNo shadow:fixinodes を有効にすると、このモジュールにより、ファイルパスのハッシュを使用して、スナップショットディレクトリー内のファイルの循環 inode 数が変更されます。これは、スナップショットが元のファイルと同じ device:inode 番号を持つスナップショットシステム (GPFS スナップショットの場合など) に必要です。このオプションを設定しないと、シャドウコピー UI の「restore」ボタンが共有違反で失敗します。
shadow:snapprefixOptional該当なしスナップショット名の接頭辞に一致する正規表現。Red Hat Gluster Storage は Basic Regular Expression (BRE) のみをサポートします。
shadow:delimiterOptional_GMT区切り文字は、shadow:snapprefix と shadow:format を分離するために使用されます。
以下は、smb.conf ファイルの例です。
[gluster-vol0]
comment = For samba share of volume vol0
vfs objects = shadow_copy2 glusterfs
glusterfs:volume = vol0
glusterfs:logfile = /var/log/samba/glusterfs-vol0.%M.log
glusterfs:loglevel = 3
path = /
read only = no
guest ok = yes
shadow:snapdir = /.snaps
shadow:basedir = /
shadow:sort = desc
shadow:snapprefix= ^S[A-Za-z0-9]*p$
shadow:format = _GMT-%Y.%m.%d-%H.%M.%S
上記の例では、シャドウコピーを有効にするために、上記のパラメーターを smb.conf ファイルに追加する必要があります。上記のオプションは必須ではありません。
シャドウコピーは、smb.conf エントリーに基づいてすべてのスナップショットをフィルターします。これは、基準に一致するスナップショットのみを表示します。上記の例では、スナップショット名は「S」で始まり、「p」で終了します。間のアルファベット数字も検索対象となります。たとえば、以下のスナップショットの一覧では、Windows が最初の 2 つのスナップショットを表示し、最後のスナップショットは無視されます。したがって、これらのオプションは、表示するスナップショットや表示しないものをフィルタリングするのに役立ちます。
Snap_GMT-2016.06.06-06.06.06
Sl123p_GMT-2016.07.07-07.07.07
xyz_GMT-2016.08.08-08.08.08
smb.conf ファイルを編集したら、以下の手順を実行してスナップショットのアクセスを有効にします。
  1. smb サービスを起動または再起動します。
    RHEL 7 および RHEL 8 で systemctl [re]start smb を実行します。
    RHEL 6 で、サービス smb [re]startを実行します。
  2. Samba の User Serviceable Snapshot (USS) を有効にします。詳細は、 「ユーザーサービス可能なスナップショット」

6.4.8.2. スナップショットへのアクセス

Windows システムでスナップショットにアクセスするには、以下の手順を実行します。
  1. 以前のバージョンが必要なファイルまたはディレクトリーを右クリックします。
  2. Restore previous versions をクリックします。
  3. ダイアログボックスで、以前のバージョンのファイルの日付/時間を選択し、OpenRestore、または Copy を選択します。
    詳細は以下のようになります。
    Open: 必要なバージョンのファイルを読み取り専用モードで開きます。
    Restore: ファイルを選択したバージョンに戻します。
    Copy: ファイルを別の場所にコピーします。

    図6.1 スナップショットへのアクセス

    スナップショットへのアクセス

6.4.9. パフォーマンスチューニング

本セクションでは、SMB 環境でシステムパフォーマンスを向上させる方法を説明します。さまざまな機能拡張タスクは、以下のように分類できます。
  • メタデータキャッシングを有効にして、Red Hat Gluster Storage ボリュームの SMB アクセスのパフォーマンスを改善します。
  • ディレクトリーリスティングのパフォーマンスの強化
  • ファイル/ディレクトリー作成パフォーマンスの強化
各詳細については、このセクションの後で説明します。

6.4.9.1. メタデータキャッシングの有効化

メタデータキャッシュを有効にして、ディレクトリー操作のパフォーマンスを改善します。以下に示す順序で、信頼できるストレージプールのいずれかのノードで以下のコマンドを実行します。
注記
ワークロードの大半が、複数のクライアントから同じファイルおよびディレクトリーのセットを同時に変更する場合は、メタデータキャッシュを有効にしても、必要なパフォーマンスが向上するとは限りません。
  1. 以下のコマンドを実行し、メタデータのキャッシュおよびキャッシュの無効化を有効にします。
    # gluster volume set <volname> group metadata-cache
    これは group set オプションで、1 つのコマンドに複数のボリュームオプションを設定します。
  2. キャッシュ可能なファイル数を増やすには、以下のコマンドを実行します。
    # gluster volume set <VOLNAME> network.inode-lru-limit <n>
    N は 50000 に設定されます。ボリューム内のアクティブなファイルの数が非常に高い場合は、増やすことができます。この数字を増やすと、ブリックプロセスのメモリーフットプリントが増加します。

6.4.9.2. ディレクトリーリスティングのパフォーマンスの強化

ファイル/ディレクトリー数は変更しませんが、ブリック/ノードの数がボリューム内で増加すると、ディレクトリーの一覧表示は遅くなります。並行 readdir ボリュームオプションを有効にすると、ディレクトリー一覧のパフォーマンスは、ボリューム内のノード/ブリックの数に依存しません。したがって、ボリュームのスケールが増えると、ディレクトリー一覧のパフォーマンスは低下しません。
注記
ボリュームの分散数が 2 以上でディレクトリーのサイズが少ない場合にのみ、パフォーマンスの向上を期待できます (< 3000 エントリー)。ボリュームが大きいほど (分散数) パフォーマンス上の利点が得られます。
並行 readdir を有効にするには、以下のコマンドを実行します。
  1. 以下のコマンドを実行して、 performance.readdir-ahead オプションが有効になっているかどうかを確認します。
    # gluster volume get <VOLNAME> performance.readdir-ahead
    performance.readdir-ahead が有効になっていない場合は、以下のコマンドを実行します。
    # gluster volume set <VOLNAME> performance.readdir-ahead on
  2. 以下のコマンドを実行して parallel-readdir オプションを有効にします。
    # gluster volume set <VOLNAME> performance.parallel-readdir on
    注記
    ボリュームに 50 を超えるブリックがある場合は、キャッシュサイズを 10Mb (デフォルト値) 以上に増やすことが推奨されます。
    # gluster volume set <VOLNAME> performance.rda-cache-limit <CACHE SIZE>

6.4.9.3. ファイル/ディレクトリー作成パフォーマンスの強化

ファイルを作成/名前変更する前に、ルックアップ (SMB の5-6) が送信され、ファイルがすでに存在するかどうかを確認します。可能な場合は、キャッシュからルックアップを提供して、SMB アクセス内の複数のレイヤーで、作成/名前変更のパフォーマンスを高めます。
  1. 以下のコマンドを実行して negative-lookup キャッシュを有効にします。
     # gluster volume set <volname> group nl-cache
       volume set success
    注記
    上記のコマンドは cache-invalidation も有効にし、タイムアウトを 10 分に増やします。

6.5. POSIX アクセス制御リスト

基本的な Linux ファイルシステムのパーミッションは、所有ユーザー、所有しているグループのメンバー、その他のすべてのユーザーの 3 つのユーザータイプに基づいて割り当てられます。POSIX アクセス制御リスト (ACL) は、管理者が、自分のユーザーおよびグループだけでなく、任意のユーザーおよびグループに基づいてファイルおよびディレクトリーのアクセス権限も設定できるようにすることで、このシステムの制限を回避します。
本セクションでは、アクセス制御リストを表示して設定する方法、およびこの機能を Red Hat Gluster Storage ボリュームで有効にする方法を説明します。ACL の仕組みの詳細については、『『Red Hat Enterprise Linux 7 システム管理者のガイド』』を参照してください。https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Access_Control_Lists.html

6.5.1. setfacl で ACL の設定

setfacl コマンドを使用すると、指定したファイルまたはディレクトリーの ACL を変更できます。-m サブコマンドでファイルのアクセスルールを追加するか、- x サブコマンドでファイルのアクセスルールを削除できます。基本的な構文は以下のとおりです。
# setfacl subcommand access_rule file_path
アクセスルールの構文は、ルールに従う必要があるロールによって異なります。
u: で始まるユーザーのルール
# setfacl -m u:user:perms file_path
たとえば、setfacl -m u:fred:rw /mnt/data ユーザーに、/ mnt/data ディレクトリーへの read および write アクセスを付与します。
setfacl -x u::w /works_in_progress/my _presentation.txt は、すべてのユーザーが /works_in_progress/my_presentation.txt ファイルに書き込むのを防ぎます(これらは POSIX が制御されるためです)。
グループのルールは g で始まります。
# setfacl -m g:group:perms file_path
たとえば、setfacl -m g:admins:rwx /etc/fstab は、admins グループ の読み取り、書き込み、および実行パーミッションを /etc/fstab ファイルに付与します。
setfacl -x g:newbies:x /mnt/harmful_script.sh が、new bies グループのユーザーが /mnt/harmful_script.sh の実行 を阻止します。
o: で始まるその他のユーザーのルール
# setfacl -m o:perms file_path
たとえば、setfacl -m o:r /mnt/data/public は、/ mnt/data/public ディレクトリーのファイル を読み取るユーザー名またはグループパーミッションに関する特定のルールがないユーザーを提供します。
実効権限マスクを使用して最大アクセスレベルを設定するルールでは、m から始まります。
# setfacl -m m:mask file_path
たとえば、setfacl -m m:r-x /mount/harmless_script.sh は、すべてのユーザーが /mount/harmless_script.sh ファイルへの読み取りおよび実行アクセスを許可します。
d: をルールの先頭に追加するか、- R オプションでルールを再帰的にして、ディレクトリーのデフォルト ACL を設定できます。たとえば、setfacl -Rm d:g:admins:rwx /etc/ etc は setfacl が実行される際に /etc ディレクトリーで作成されたファイルへのアクセス権限を付与します。

6.5.2. getfacl で現在の ACL の確認

getfacl コマンドを使用すると、ファイルまたはディレクトリーの現在の ACL を確認できます。このコマンドの構文は以下のとおりです。
# getfacl file_path
これにより、そのファイルの現在の ACL の概要が出力されます。以下に例を示します。
# getfacl /mnt/gluster/data/test/sample.jpg
# owner: antony
# group: antony
user::rw-
group::rw-
other::r--
ディレクトリーにデフォルトの ACL が設定されている場合は、以下のように接頭辞 default: が指定されます。
# getfacl /mnt/gluster/data/doc
# owner: antony
# group: antony
user::rw-
user:john:r--
group::r--
mask::r--
other::r--
default:user::rwx
default:user:antony:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

6.5.3. ACL が有効なボリュームのマウント

Native FUSE クライアントを使用して、ACL が有効になっているボリュームをマウントするには、acl マウントオプション を使用します。詳細は、「Red Hat Gluster Storage ボリュームのマウント」 を参照してください。
ACL は、NFS および SMB アクセスプロトコルを使用してマウントされているボリュームでデフォルトで有効になります。ACL が他のマウントボリュームで有効になっているかどうかを確認するには、「マウントされたボリュームでの ACL 有効化の確認」 を参照してください。

6.5.4. マウントされたボリュームでの ACL 有効化の確認

以下の表は、ボリュームがマウントされているクライアントのタイプに基づいて、マウントしたボリュームで ACL が有効になっていることを確認する方法を示しています。

表6.10

クライアントタイプ確認方法詳細情報
ネイティブ FUSE
default_permissions オプションについて、mount コマンドの出力を確認します。
# mount | grep mountpoint
マウントされたボリュームの出力に default_permissions が表示されると、そのボリュームでは ACL が有効になりません。
gluster FUSE マウントプロセス(glusterfs)の ps aux コマンドの出力を確認します。
# ps aux | grep gluster
root     30548  0.0  0.7 548408 13868 ?        Ssl  12:39   0:00 /usr/local/sbin/glusterfs --acl --volfile-server=127.0.0.2 --volfile-id=testvol /mnt/fuse_mnt
マウントされたボリュームの出力に --acl が表示されると、そのボリュームで ACL が有効になります。
詳細は、「ネイティブクライアント」 を参照してください。
Gluster ネイティブ NFS
サーバー側で、gluster ボリューム情報 volname コマンドの出力を確認します。nfs.acl が出力に表示されると、そのボリュームで ACL が無効になっています。nfs.acl が表示されない場合は、ACL が有効になります (デフォルトの状態)。
クライアント側で、マウント コマンドの出力でボリュームの出力を確認します。出力に noacl が表示されると、マウントポイントで ACL が無効になります。出力に何も表示されない場合は、クライアントはサーバーが ACL を使用していることを確認し、サーバーサポートが有効な場合に ACL を使用します。
NFS に関する Gluster ボリュームセットのヘルプ の出力を参照するか、Red Hat Enterprise Linux 『ストレージ管理ガイドを参照してください』。 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-nfs.html
NFS Ganesha
サーバー側で、ボリュームのエクスポート設定ファイル /run/gluster/shared_storage/nfs-ganesha/exports/export.volname.conf を確認します。Disable_ACL オプションを true に設定すると、ACL が無効になります。それ以外の場合は、そのボリュームに対して ACL が有効になります。
注記
NFS-Ganesha は NFSv4 プロトコルの標準化された ACL をサポートしますが、NFSv3 マウントに使用される NFSACL プロトコルはサポートしません。ACL を設定できるのは、NFSv4 のみです。
サーバーが ACL に対応している限り、クライアント側で NFSv4 ACL を無効にするオプションはありません。クライアントは、マウントポイントに ACL を設定できます。
詳細は、「NFS Ganesha」 を参照してください。クライアント側の設定は、Red Hat Enterprise Linux 『Storage Administration Guide』: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-nfs.html を参照してください。
samba
POSIX ACL は、Samba を使用して Red Hat Gluster Storage ボリュームにアクセスする際にデフォルトで有効になります。
詳細は、「SMB」 を参照してください。

6.6. クライアントオペレーティングシステムバージョンの確認

Red Hat Gluster Storage はバージョンによって異なる機能に対応しています。サーバーおよびクライアントは、操作バージョン番号または op-version を使用してサポートできる機能を特定します。cluster.op-version パラメーターは、サーバー側上のすべてのクラスターに必要な操作バージョンを設定します。各クライアントは、最小 (min-op-version) および最大 (max-op-version) でサポートされる操作バージョンで識別される一連のオペレーティングバージョンをサポートします。
以下のコマンドを実行して、特定のボリュームに接続されたクライアントのオペレーティングシステムバージョンを確認します。
Red Hat Gluster 3.2 以降
# gluster volume status volname clients
クラスター内ののボリュームに接続されたクライアントのオペレーティングバージョンを確認する場合は、ボリューム名の代わりに all を使用します。

Red Hat Gluster Storage 3.2 の前:

  1. チェックするボリュームの状態ダンプを実行します。
    # gluster volume statedump volname
  2. 状態ダンプディレクトリーの特定
    # gluster --print-statedumpdir
  3. 状態ダンプファイルを見つけ、クライアント情報について grep します。
    # grep -A4 "identifier=client_ip" statedumpfile

第7章 Red Hat Gluster Storage と Windows Active Directory の統合

本章では、Red Hat Gluster Storage ノードを既存の Windows Active Directory ドメインに統合するために必要なタスクについて説明します。以下の図は、Red Hat Gluster Storage を Windows Active Directory と統合するアーキテクチャーを説明しています。

図7.1 Active Directory の統合

Active Directory の統合
本セクションでは、アクティブなディレクトリードメインがインストールされていることを前提としています。設定の詳細に進む前に、以下のデータとその例と、前述したセクションで使用される例を記載しています。

表7.1 Active Directory 統合の情報

Information値の例
DNS ドメイン名 / レルムaddom.example.com
NetBIOS ドメイン名ADDOM
管理者アカウントの名前administrator
Red Hat Gluster Storage ノードrhs-srv1.addom.example.com, 192.168.56.10 rhs-srv2.addom.example.com, 192.168.56.11 rhs-srv3.addom.example.com, 192.168.56.12
クラスターの netbios 名RHS-SMB

7.1. 前提条件

統合する前に、既存の Red Hat Gluster Storage 環境で以下の手順を実行する必要があります。
  • 名前解決

    Red Hat Gluster Storage ノードは、DNS 経由で AD ドメインから名前を解決できる必要があります。同じコマンドで、以下のコマンドを使用できます。

    host dc1.addom.example.com
    ここで、om.example.com は AD ドメインで、dc1 はドメインコントローラーの名前になります。
    たとえば、静的ネットワーク設定の /etc/resolv.conf ファイルは以下のようになります。
    domain addom.example.com
    search addom.example.com
    nameserver 10.11.12.1 # dc1.addom.example.com
    nameserver 10.11.12.2 # dc2.addom.example.com
    この例では、ドメインコントローラーがドメインの DNS サーバーでもあることを前提としています。
  • Kerberos パッケージ

    kinit や klist などの kerberos クライアントユーティリティーを使用する場合は、以下のコマンドを使用して krb5-workstation を手動でインストールします。

    # yum -y install krb5-workstation
  • 時間サービスの同期

    各 Red Hat Gluster Storage ノードでタイムサービスと Windows Active Directory サーバーが同期されている必要があります。そうでないと、クロックのスキューにより Kerberos 認証が失敗する可能性があります。時間サービスが信頼できない環境では、Red Hat Gluster Storage ノードを Windows Server から時刻を同期するように設定することがベストプラクティスです。

    各 Red Hat Storage ノードで、RHEL 7 の場合は /etc/ntp.conf ファイルを編集するか、RHEL 8 の場合は /etc/chrony.conf ファイルを編集して、タイムが既知の、信頼できるタイムサービスから同期されるようにします。
    # Enable writing of statistics records.
    #statistics clockstats cryptostats loopstats peerstats
    server 0.rhel.pool.ntp.org iburst
    server 1.rhel.pool.ntp.org iburst
    
    driftfile /var/lib/chrony/drift
    makestep 1.0 3
    rtcsync
    logdir /var/log/chrony
    
    NTP または chrony デーモンを停止し、時間を更新し NTP または chrony デーモンを起動して、各 Red Hat Gluster Storage ノードで変更をアクティベートします。以下のコマンドを使用して、両方のサーバーで変更を確認します。
    RHEL 7 および RHEL 8 で 以下を実行します。
    # systemctl stop ntpd
    # systemctl start ntpd
    # systemctl stop chrony
    # systemctl start chrony
    RHEL 6 で以下を実行します。
    # service ntpd stop
    # service ntpd start
    # service chrony stop
    # service chrony stop
    RHEL 8 で chrony を使用する方法の詳細については、https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_basic_system_settings/using-chrony-to-configure-ntp を参照してください。
  • Samba パッケージ

    以下の Samba パッケージとその依存関係をインストールするようにしてください。

    • CTDB
    • samba
    • samba-client
    • samba-winbind
    • samba-winbind-modules

7.2. Integration

Red Hat Gluster Storage サーバーを Active Directory ドメインに統合するには、以下の一連の手順を実行します。
  1. 認証の設定
  2. Active Directory ドメインへの参加
  3. Active Directory およびサービスの検証/テスト

7.2.1. 認証の設定

クラスターを Active Directory ドメインに参加させるには、すべてのノードでいくつかのファイルを手動で編集する必要があります。
注記
  • アクティブなディレクトリーに参加する前に、CTDB が設定されていることを確認してください。詳細は、『Red Hat Gluster Storage Administration Guide』 の 『Section 6.3.1 Setting up CTDB for Samba』 を参照してください。
  • 変更を行う前に、設定および Samba のデータベース (ローカルおよび ctdb) のバックアップを取得することが推奨されます。

7.2.1.1. Samba の基本設定

Red Hat Gluster Storage 3.4 Batch 4 Update の時点で、新規デプロイメントに推奨される idmap 設定方法は autorid です。tdb などのユーザーおよびグループ ID を自動的に計算する他に、データベーストランザクションおよび読み取り操作の実行は少なくなり、セキュアな ID 履歴 (SID 履歴) をサポートするのに必要な要件であるため、Red Hat では、autorid を推奨しています。
警告
既存のデプロイメントでは idmap 設定を変更しないでください。これを実行するには、共有ファイルシステム内の全ファイルのパーミッションおよびアクセス制御リストの変更など、多数の変更が必要になります。これにより、ユーザーアクセスの問題が作成されない限り、多くの変更が必要になります。既存のデプロイメントの idmap 設定を変更する必要がある場合は、Red Hat サポートにお問い合わせください。
Samba 設定ファイル /etc/samba/smb.conf はすべてのノードで同一であり、AD に関連するパラメーターを含める必要があります。その他に、ユーザーおよびグループ ID とグループ ID のマッピングをアクティブにするために、いくつかの設定が必要になります。
以下の例は、AD 統合の最小 Samba 設定を示しています。
[global]
netbios name = RHS-SMB
workgroup = ADDOM
realm = addom.example.com
security = ads
clustering = yes
idmap config * : backend = autorid
idmap config * : range = 1000000-19999999
idmap config * : rangesize = 1000000

# -----------------RHS Options -------------------------
#
# The following line includes RHS-specific configuration options. Be careful with this line.

       include = /etc/samba/rhs-samba.conf

#=================Share Definitions =====================
警告
上記の例は、smb.conf ファイルで必要な完全な グローバル セクションです。ctdb ロックボリュームの開始または停止時に gluster メカニズムが設定を変更できないようにするため、本セクションに何も表示されないようにします。
netbios name は、すべてのクラスターノードで同じ名前を持つ必要がある 1 つのみで構成されます。Windows クライアントはその名前からのみクラスターにアクセスします (この短い形式または FQDN のいずれか)。個別ノードのホスト名(rhs-srv1、rhs-srv2、…)は netbios name パラメーターに使用することはできません。
注記
  • idmap range は使用可能な ID 番号および高テストの ID 番号を定義します。rangesize で指定されるオブジェクト数に対応するのに十分な大きさの範囲を指定します。
  • idmap rangesize は、各ドメイン範囲で利用可能な ID の数を指定します。この場合、ドメイン範囲ごとに 100 万の識別子があり、range パラメーターで合計 1,900 万の識別子があります。つまり、可能なドメイン範囲の合計は 1,900 万です。
  • 個別のホスト名を使用して特定のノードにアクセスできるようにする必要がある場合は、smb.confnetbios aliases パラメーターに追加できます。
  • AD 環境では、通常 nmbd を実行する必要はありません。ただし、nmbd を実行する必要がある場合は、クラスターアドレス smb.conf オプションをクラスターのパブリック IP アドレスの一覧に設定するようにしてください。

7.2.1.2. ad バックエンドを使用した代替設定

Active Directory ID を完全に制御する必要がある場合は、autorid に加えて idmap_ad モジュールを使用して、Samba 設定をさらに調整できます。idmap_ad モジュールは、AD の特別な unix 属性から unix ID を読み取ります。これは、Samba および winbind が使用可能になる前に、AD ドメインの管理者が設定する必要があります。
Samba が idmap_ad を使用できるようにするには、AD ドメイン管理者がこのような unix 拡張を使用するための AD ドメインを準備し、Samba サーバーにアクセスできるすべてのユーザーおよびグループに unix ID を割り当てる必要があります。
たとえば、以下は、ADDOM ドメインの idmap_ad バックエンドを使用する拡張 Samba 設定ファイルです。デフォルトの autorid バックエンドは、ADDOM ドメイン以外のドメインからすべてのオブジェクトを取得します。
[global]
netbios name = RHS-SMB
workgroup = ADDOM
realm = addom.example.com
security = ads
clustering = yes
idmap config * : backend = autorid
idmap config * : range = 1000000-1999999
idmap config ADDOM : backend = ad
idmap config ADDOM : range = 3000000-3999999
idmap config ADDOM : schema mode = rfc2307
winbind nss info = rfc2307

# -------------------RHS Options -------------------------------
#
# The following line includes RHS-specific configuration options. Be careful with this line.

       include = /etc/samba/rhs-samba.conf

#===================Share Definitions =========================
注記
  • idmap_ad 設定の範囲は、AD 設定により規定されています。これは、AD 管理者が取得する必要があります。
  • 異なる idmap 設定の範囲は重複しないようにしてください。
  • スキーマモードと winbind nss info 設定は同じ値である必要があります。ドメインがレベル 2003R2 以降である場合、rfc2307 は正しい値になります。古いドメインでは、sfu と sfu20 の値が追加されています。詳細は、idmap_ad および smb.conf の man ページを参照してください。

7.2.1.3. Samba 設定の確認

testparm コマンドを使用して、新しい設定ファイルをテストします。以下に例を示します。
# testparm -s
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Loaded services file OK.

Server role: ROLE_DOMAIN_MEMBER

# Global parameters
[global]
    workgroup = ADDOM
    realm = addom.example.com
    netbios name = RHS-SMB
    security = ADS
    clustering = Yes
    winbind nss info = rfc2307
    idmap config addom : schema mode = rfc2307
    idmap config addom : range = 3000000-3999999
    idmap config addom : backend = ad
    idmap config * : range = 1000000-1999999
    idmap config * : backend = autorid

7.2.1.4. nsswitch の設定

Samba 設定が完了したら、AD からマッピングユーザーおよびグループを使用するように Samba を有効にする必要があります。これは、winbind が認識しなければならないローカルの Name Service Switch (NSS) を介して実行されます。winbind NSS モジュールを使用するには、/etc/nsswitch.conf ファイルを編集します。ファイルに passwd データベースおよび グループ データベースの winbind エントリーが含まれていることを確認してください。以下は例になります。
...
passwd: files winbind
group: files winbind
...
これにより、winbind の使用が有効になり、Samba が AD に参加し、winbind が開始されたら、各クラスターノードでユーザーとグループ を表示させる 必要があります。

7.2.2. Active Directory ドメインへの参加

AD に参加する前に、マシンアカウント情報を CTDB 経由ですべてのクラスターノードで利用可能なデータベースファイルに保存できるように CTDB を起動する必要があります。その他に、その他の Samba サービスをすべて停止する必要があります。ノード間で root ユーザー用にパスワードが設定されていない鍵ベースの SSH 認証が使用されている場合は、onnode ツールを使用して、1 つのノードからすべてのノードでこれらのコマンドを実行できます。
RHEL 7 および RHEL 8 で 以下を実行します。
# onnode all systemctl start ctdb
# onnode all systemctl stop winbind
# onnode all systemctl stop smb
RHEL 6 で以下を実行します。
# onnode all service ctdb start
# onnode all service winbind stop
# onnode all service smb stop
注記
  • 設定で CTDB が Winbind と Samba を管理している場合は、上記の停止コマンドの前に実行するように一時的に無効にし、シャットダウン時に CTDB が正常でない状態にならないようにします。
    # onnode all ctdb event script disable legacy 49.winbind
    # onnode all ctdb event script disable legacy 50.samba
    
  • Red Hat Gluster Storage のバージョンによっては、selinux ポリシーのバグにより、'ctdb disablescript SCRIPT' が成功しない場合があります。この場合は、'chmod -x /etc/ctdb/events.d/SCRIPT' を root シェルの回避策として実行できます。
  • winbind および smb をシャットダウンすると、主に、この AD 統合中の SMB サービスへのアクセスを防ぐことができます。これらのサービスは稼働したままになる可能性がありますが、他の手段でそれらへのアクセスを防ぐ必要があります。
結合は、1 つのノードから net ユーティリティーから開始されます。
警告
以下の手順は、1 つのクラスターノードでのみ実行される必要があり、他のクラスターノードでは繰り返すことはできません。CTDB により、クラスター全体がこのステップに参加します。
# net ads join -U Administrator
Enter Administrator's password:
Using short domain name -- ADDOM
Joined 'RHS-SMB' to dns domain addom.example.com'
Not doing automatic DNS update in a clustered setup.
参加に成功すると、クラスターの IP アドレスとクラスターの netbios 名がネットワークで公開される必要があります。AD DNS サーバーに複数のパブリッククラスター IP アドレスを登録するには、net ユーティリティーを再度使用できます。
# net ads dns register rhs-smb <PUBLIC IP 1> <PUBLIC IP 2> ...
このコマンドを実行すると、DNS 名 rhs-smb が指定のパブリック IP アドレスに解決するようになります。DNS 登録は、AD での認証にクラスターマシンアカウントを使用します。つまり、この操作は、結合が成功した後にのみ実行できます。
クラスターの NetBIOS 名の登録は、nmbd サービスにより行われます。ホスト上の nmbd インスタンスが相互に登録を上書きしないようにするには、'cluster address' smb.conf オプションをクラスター全体のパブリックアドレスの一覧に設定する必要があります。

7.2.3. Active Directory およびサービスの検証/テスト

参加に成功すると、Samba および Winbind デーモンを起動できます。
次のコマンドを使用して、nmdb、winbind、およびsmbサービスを開始します。
RHEL 7 および RHEL 8 で 以下を実行します。
# onnode all systemctl start nmb
# onnode all systemctl stop winbind
# onnode all systemctl stop smb
RHEL 6 で以下を実行します。
# onnode all service nmb start
# onnode all service winbind start
# onnode all service smb start
注記
  • Winbind および Samba を管理する CTDB の機能を無効にした場合は、次のコマンドで再度有効にできます。
    # onnode all ctdb event script enable legacy 50.samba
    # onnode all ctdb event script enable legacy 49.winbind
  • 最新の ctdb-4.9.8-105.el7rhgs.x86_64 パッケージにより、ctdb 管理対象サービススクリプトのパスが変更されました。スクリプトファイルは、/usr/share/ctdb/events/legacy/ から有効化した後、/etc/ctdb/events/legacy/ で利用できます。
  • ctdb イベントスクリプトを有効にするには、以下のコマンドを実行します。
    ctdb event script enable legacy 49.winbind
  • すべてのノードで ctbd イベントスクリプトを有効にするには、以下のコマンドを実行します。
    # onnode all ctdb event script enable legacy 49.winbind
以下の検証手順を実行します。
  1. 以下の手順を実行して結合を確認します。

    以下のコマンドを使用して、作成したマシンアカウントを使用して AD LDAP サーバーに認証できるかどうかを確認します。
    # net ads testjoin
    Join is OK
  2. 以下のコマンドを実行して、マシンアカウントの LDAP オブジェクトを表示します。
    # net ads status -P
    objectClass: top
    objectClass: person
    objectClass: organizationalPerson
    objectClass: user
    objectClass: computer
    cn: rhs-smb
    distinguishedName: CN=rhs-smb,CN=Computers,DC=addom,DC=example,DC=com
    instanceType: 4
    whenCreated: 20150922013713.0Z
    whenChanged: 20151126111120.0Z
    displayName: RHS-SMB$
    uSNCreated: 221763
    uSNChanged: 324438
    name: rhs-smb
    objectGUID: a178177e-4aa4-4abc-9079-d1577e137723
    userAccountControl: 69632
    badPwdCount: 0
    codePage: 0
    countryCode: 0
    badPasswordTime: 130880426605312806
    lastLogoff: 0
    lastLogon: 130930100623392945
    localPolicyFlags: 0
    pwdLastSet: 130930098809021309
    primaryGroupID: 515
    objectSid: S-1-5-21-2562125317-1564930587-1029132327-1196
    accountExpires: 9223372036854775807
    logonCount: 1821
    sAMAccountName: rhs-smb$
    sAMAccountType: 805306369
    dNSHostName: rhs-smb.addom.example.com
    servicePrincipalName: HOST/rhs-smb.addom.example.com
    servicePrincipalName: HOST/RHS-SMB
    objectCategory: CN=Computer,CN=Schema,CN=Configuration,DC=addom,DC=example,DC=com
    isCriticalSystemObject: FALSE
    dSCorePropagationData: 16010101000000.0Z
    lastLogonTimestamp: 130929563322279307
    msDS-SupportedEncryptionTypes: 31
    
  3. 以下のコマンドを実行して、AD サーバーに関する一般的な情報を表示します。
    # net ads info
    LDAP server: 10.11.12.1
    LDAP server name: dc1.addom.example.com
    Realm: ADDOM.EXAMPLE.COM
    Bind Path: dc=ADDOM,dc=EXAMPLE,dc=COM
    LDAP port: 389
    Server time: Thu, 26 Nov 2015 11:15:04 UTC
    KDC server: 10.11.12.1
    Server time offset: -26
  4. 以下の手順を実行して、winbind が正しく動作しているかどうかを確認します。

    以下のコマンドを実行して、winbindd が AD への認証にマシンアカウントを使用できるかどうかを確認します。
    # wbinfo -t
    checking the trust secret for domain ADDOM via RPC calls succeeded
  5. 以下のコマンドを実行して、指定の名前を Windows SID に解決します。
    # wbinfo --name-to-sid 'ADDOM\Administrator'
    S-1-5-21-2562125317-1564930587-1029132327-500 SID_USER (1)
  6. 以下のコマンドを実行して認証を確認します。
    # wbinfo -a 'ADDOM\user'
    Enter ADDOM\user's password:
    plaintext password authentication succeeded
    Enter ADDOM\user's password:
    challenge/response password authentication succeeded
    または
    # wbinfo -a 'ADDOM\user%password'
    plaintext password authentication succeeded
    challenge/response password authentication succeeded
  7. 以下のコマンドを実行して、id-mapping が適切に機能しているかどうかを確認します。
    # wbinfo --sid-to-uid <SID-OF-ADMIN>
    1000000
  8. 以下のコマンドを実行して、winbind Name Service Switch モジュールが正しく機能していることを確認します。
    # getent passwd 'ADDOM\Administrator'
    ADDOM\administrator:*:1000000:1000004::/home/ADDOM/administrator:/bin/false
  9. 以下のコマンドを実行して、samba が winbind と NSS モジュールが正しく使用できるかどうかを確認します。
    # smbclient -L rhs-smb -U 'ADDOM\Administrator'
    Domain=[ADDOM] OS=[Windows 6.1] Server=[Samba 4.2.4]
    
            Sharename       Type      Comment
            ---------       ----      -------
            IPC$            IPC       IPC Service (Samba 4.2.4)
    Domain=[ADDOM] OS=[Windows 6.1] Server=[Samba 4.2.4]
    
            Server               Comment
            ---------            -------
            RHS-SMB         Samba 4.2.4
    
            Workgroup            Master
            ---------            -------
            ADDOM             RHS-SMB
    

パート IV. 管理

第8章 スナップショットの管理

Red Hat Gluster Storage スナップショット機能により、データの保護に使用できる Red Hat Gluster Storage ボリュームのポイントインタイムコピーを作成できます。ユーザーは、データの誤って削除、破損、または修正するために読み取り専用のスナップショットコピーに直接アクセスできます。

図8.1 スナップショットのアーキテクチャー

説明
スナップショットアーキテクチャーの図では、Red Hat Gluster Storage ボリュームは複数のブリック (Brick1 Brick2 など) で構成されており、1 つ以上のノードに分散され、各ブリックは独立したシン論理ボリューム (LV) で構成されます。ボリュームのスナップショットを取得すると、論理ボリュームのスナップショットを取得して別のブリックを作成します。brick1_s1 は、Brick1 の同じイメージです。同様に、各ブリックの同じイメージが作成され、新たに作成されたブリックが組み合わされてスナップショットボリュームを形成します。
スナップショットの機能は以下のとおりです。
  • クラッシュの一貫性

    クラッシュの一貫性のあるスナップショットは、特定の時点でキャプチャーされます。クラッシュしたスナップショットが復元されると、データはスナップショットの取得時と同じになります。

    注記
    現在、アプリケーションレベルの一貫性はサポートされていません。
  • オンラインスナップショット

    スナップショットはオンラインスナップショットであるため、スナップショットを作成しても、ファイルシステムとその関連データは引き続きクライアントで利用可能になります。

  • クォーラムベース

    クォーラム機能により、ブリックがダウンしている間は、ボリュームが良好な状態となります。n <= 2 の場合、n 方向レプリケーションに対してダウンしているブリックが満たされない場合、クォーラムは満たされません。n >= 3 の n 方向のレプリケーションでは、n が奇数の場合 m >= (n/2 +1) で、n が偶数の場合 m >=n/2で最初のブリックが up になります。クォーラムがスナップショットの作成を満たさないと失敗します。

  • バリア

    スナップショットの操作時に一部のファイル操作がブロックされるクラッシュの一貫性を保証するため、

    これらのファイル操作は、スナップショットが完了するまでブロックされます。他のすべてのファイル操作は渡されます。タイムアウトの 2 分のデフォルト値は 2 分です。スナップショットが完了していない場合には、これらのファイル操作はアンロックされます。スナップショットの完了前にバリアが無効化されると、スナップショットの操作に失敗します。これは、スナップショットが一貫した状態になるようにするためです。
注記
仮想マシンイメージをホストしている Red Hat Gluster Storage ボリュームのスナップショットを作成することは推奨されません。仮想マシンのハイパーバイザーによるサポートのスナップショットの取得は、このユースケースでより適しています。

8.1. 前提条件

この機能を使用する前に、以下の前提条件を満たしていることを確認してください。
  • スナップショットは、シンプロビジョニングされた LVM をベースにしています。ボリュームが LVM2 をベースとしていることを確認します。Red Hat Gluster Storage は、Red Hat Enterprise Linux 6.7 以降、Red Hat Enterprise Linux 7.1 以降、および Red Hat Enterprise Linux 8.2 以降のバージョンでサポートされています。これらすべてのバージョンの RedHat Enterprise Linux は、デフォルトで LVM2 に基づいています。詳細は、https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/thinprovisioned_volumes.html を参照してください。
    重要
    Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。『 インストールガイド』の「 『バージョンの詳細』 表」 『および「Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 」を参照してください。
  • 各ブリックは、シンプロビジョニングされた論理ボリューム (LV) でなければなりません。
  • ブリックを含む論理ボリュームには、ブリック以外のデータを含めることはできません。
  • Red Hat Gluster Storage 3.4 以降では、リニア LVM およびシン LV がサポートされています。詳細は、https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/logical_volume_manager_administration/index#LVM_components を参照してください。

推奨される設定

スナップショットの使用に推奨される設定を以下に示します。また、スナップショットのパフォーマンスを向上させるために、19章パフォーマンスチューニング を読める必要があります。
  • 各ボリュームブリックについて、ボリュームとそのブリックスナップショット (シン) のスナップショットを含む専用のシンプールを作成します。現在のシン p 設計では、同じシンプールに異なる Red Hat Gluster Storage ボリュームのブリックを配置しないでください。これは、その他関連のないボリュームにおけるスナップショットの削除などのスナップショット操作のパフォーマンスが低下するためです。
  • 推奨されるシンプールチャンクサイズは 256 KB です。顧客のワークロードの詳細情報がある場合は、例外がある場合もあります。
  • 推奨されるプールメタデータサイズは、256KB 以上のチャンクサイズのシンプールサイズの 0.1% です。特別なケースでは、256 KB 未満のチャンクサイズを、シンプールサイズの 0.5% を使用します。

デバイス /dev/sda1 からブリックを作成するには、次のコマンドを実行します。
  1. pvcreate コマンドを使用して、物理ボリューム(PV)を作成します。
    pvcreate /dev/sda1
    デバイスに基づいて正しい データ アラインメントオプションを使用します。詳細は、 「ブリック設定」
  2. 以下のコマンドを使用して PV からボリュームグループ (VG) を作成します。
    vgcreate dummyvg /dev/sda1
  3. 以下のコマンドを使用して、シンプールを作成します。
    # lvcreate --size 1T --thin dummyvg/dummypool --chunksize 256k --poolmetadatasize 16G  --zero n
    256 KB のチャンクサイズを使用して、サイズが 1 TB のシンプールが作成されます。最大プールメタデータサイズである 16 G が使用されます。
  4. 以下のコマンドを使用して、作成しておいたプールからシンプロビジョニングされたボリュームを作成します。
    # lvcreate --virtualsize 1G --thin dummyvg/dummypool --name dummylv
  5. これには、ファイルシステム (XFS) を作成します。シン LV に XFS ファイルシステムを作成するには、推奨されるオプションを使用してください。
    以下に例を示します。
    mkfs.xfs -f -i size=512 -n size=8192 /dev/dummyvg/dummylv
  6. この論理ボリュームをマウントし、マウントパスをブリックとして使用します。
    mount /dev/dummyvg/dummylv /mnt/brick1

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

スナップショットを作成する前に、以下の前提条件を満たしていることを確認してください。
  • Red Hat Gluster Storage ボリュームが存在し、ボリュームが Started の状態である必要があります。
  • ボリュームのブリックはすべて、独立したシン論理ボリューム (LV) 上にある必要があります。
  • スナップショット名はクラスター内で一意である必要があります。
  • n >= 3 の n 方向レプリケーションでない限り、ボリュームのすべてのブリックが稼働しているはずです。この場合は、クォーラムを満たす必要があります。詳細は、 8章スナップショットの管理
  • Rebalanceadd-brick など、その他のボリューム操作はボリュームで実行されているはずです。
  • ボリュームのスナップショットの合計数は Effective snap-max-hard-limit と同じにしないでください。詳細は、「『スナップショットの動作の設定』」を参照してください。
  • geo レプリケーションの設定がある場合は、以下のコマンドを実行して、geo レプリケーションを実行しているセッションを一時停止します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL pause
    以下に例を示します。
    # gluster volume geo-replication master-vol example.com::slave-vol pause
    Pausing geo-replication session between master-vol example.com::slave-vol has been successful
    プライマリーボリュームのスナップショットを作成してから、セカンダリーボリュームのスナップショットを作成してください。
ボリュームのスナップショットを作成するには、以下のコマンドを実行します。
# gluster snapshot create <snapname> <volname> [no-timestamp] [description <description>] [force]
詳細は以下のようになります。
  • snapname: 作成されるスナップショットの名前
  • VOLNAME(S): スナップショットが作成されるボリュームの名前。単一ボリュームのスナップショットの作成のみをサポートします。
  • description: これは、snap とともに保存される snap の説明を提供するのに使用できる任意のフィールドです。
  • force: ブリックがダウンすると、スナップショットの作成に失敗します。n >= 3 の n 方向の複製された Red Hat Gluster Storage ボリュームでは、一部のブリックがダウンしてもスナップショットが許可されるようになりました。この場合、クォーラムはチェックされます。クォーラムは、force オプションが指定される場合にのみチェックされます。それ以外の場合は、ブリックがダウンした場合にスナップショットの作成に失敗します。クォーラムの詳細は、「『概要』」のセクションを参照してください。
  • no-timestamp: デフォルトでは、タイムスタンプがスナップショット名に追加されます。タイムスタンプを追加しない場合は、no-timestamp を引数として渡します。
注記
スナップショットは、デフォルトでは作成時にアクティブ化されません。今後作成されるすべてのスナップショット作成に対してこの動作を有効にするには、activate-on-create パラメーターを enabled に設定します。
例 1:
# gluster snapshot create snap1 vol1 no-timestamp
snapshot create: success: Snap snap1 created successfully
例 2:
# gluster snapshot create snap1 vol1
snapshot create: success: Snap snap1_GMT-2015.07.20-10.02.33 created successfully
Red Hat Gluster Storage ボリュームのスナップショットは、読み取り専用の Red Hat Gluster Storage ボリュームを作成します。このボリュームは、元の / 親ボリュームと同じ設定になります。この新規作成されたスナップショットの ブリックは /var/run/gluster/snaps/<snap-volume-name>/brick<bricknumber> としてマウントされます。
たとえば、snap ボリューム名 0888649a92ea45db8c00a615dfc5ea35 のスナップショットには、以下の 2 つのマウントポイントがあります。
/var/run/gluster/snaps/0888649a92ea45db8c00a615dfc5ea35/brick1
/var/run/gluster/snaps/0888649a92ea45db8c00a615dfc5ea35/brick2
これらのマウントは、df コマンドまたは mount コマンドを使用して表示することもできます。
注記
スナップショットの作成後に geo レプリケーションを設定している場合は、以下のコマンドを実行して geo レプリケーションセッションを再開します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL resume
以下に例を示します。
# gluster volume geo-replication master-vol example.com::slave-vol resume
Resuming geo-replication session between master-vol example.com::slave-vol has been successful
ボリュームスナップショットを作成すると、LVM メタデータのコピーを含むブロックのスナップショットプールが作成されます。スナップショットを取得した後、新しいデータが gluster ボリュームに書き込まれると、スナップショットプールが上書きされ、その変更はメインの gluster ボリュームにコピーされます。その結果、スナップショットの作成後にデータが変更されると、スナップショットプールはより多くのメタデータ領域を消費します。

8.3. スナップショットのクローン作成

クローンまたは書き込み可能なスナップショットは、特定のスナップショットから作成される新しいボリュームです。
スナップショットのクローンを作成するには、以下のコマンドを実行します。
# gluster snapshot clone <clonename> <snapname>
詳細は以下のようになります。
clonename: 作成するクローンの名前 (クローン名) です。
snapname: クローンが作成されるスナップショットの名前です。
注記
  • スナップショットの復元とは異なり、スナップショットのクローン作成後も、元のスナップショットは保持されます。
  • スナップショットはアクティブ状態である必要があります。スナップショットのブックはすべて、クローンを実行する前に稼働状態でなければなりません。また、サーバーノードはクォーラムにある必要があります。
  • したがって、このクローンは、クローン (新しいボリューム) とスナップショット LVM が同じ LVM バックエンドを共有します。LVM の領域消費は、スナップショットから新しいボリューム (クローン) に分割されます。
以下に例を示します。
# gluster snapshot clone clone_vol snap1
snapshot clone: success: Clone clone_vol created successfully
新たにクローンしたスナップショットのステータスを確認するには、以下のコマンドを実行します。
# gluster vol info <clonename>
以下に例を示します。
# gluster vol info clone_vol

Volume Name: clone_vol
Type: Distribute
Volume ID: cdd59995-9811-4348-8e8d-988720db3ab9
Status: Created
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: 10.00.00.01:/var/run/gluster/snaps/clone_vol/brick1/brick3
Options Reconfigured:
performance.readdir-ahead: on
この例では、新規作成されるボリュームと同様に、クローンが Created 状態にあることが確認できます。このボリュームは、このボリュームを使用するように明示的に起動する必要があります。

8.4. 利用可能なスナップショットの一覧

特定のボリューム用に取得したすべてのスナップショットを一覧表示するには、以下のコマンドを実行します。
# gluster snapshot list [VOLNAME]
詳細は以下のようになります。
  • VOLNAME: これは任意のフィールドであり、指定されると、ボリュームに存在する全スナップショットのスナップショット名が一覧表示されます。
以下に例を示します。
# gluster snapshot list
snap3
# gluster snapshot list test_vol
No snapshots present

8.5. 利用可能なすべてのスナップショットの情報の取得

以下のコマンドは、取得したすべてのスナップショットの基本情報を提供します。デフォルトで、クラスター内のすべてのスナップショットの情報が表示されます。
# gluster snapshot info [(<snapname> | volume VOLNAME)]
詳細は以下のようになります。
  • snapname: これは任意のフィールドです。snapname を指定すると、指定したフロッピーに関する情報が表示されます。
  • VOLNAME: これは任意のフィールドです。VOLNAME を指定すると、指定したボリューム内のすべての snap に関する情報が提供が表示されます。
以下に例を示します。
# gluster snapshot info snap3
Snapshot                  : snap3
Snap UUID                 : b2a391ce-f511-478f-83b7-1f6ae80612c8
Created                   : 2014-06-13 09:40:57
Snap Volumes:

     Snap Volume Name          : e4a8f4b70a0b44e6a8bff5da7df48a4d
     Origin Volume name        : test_vol1
     Snaps taken for test_vol1      : 1
     Snaps available for test_vol1  : 255
     Status                    : Started

8.6. 利用可能なスナップショットのステータスの取得

このコマンドは、スナップショットの稼働ステータスを表示します。デフォルトで、クラスター内のすべてのスナップショットのステータスが表示されます。特定のボリュームに取得したすべてのスナップショットのステータスを確認するには、ボリューム名を指定します。
# gluster snapshot status [(<snapname> | volume VOLNAME)]
詳細は以下のようになります。
  • snapname: これは任意のフィールドです。snapname が指定されている場合には、指定した snap に関するステータスが表示されます。
  • VOLNAME: これは任意のフィールドです。VOLNAME が指定されている場合には、指定したボリューム内のすべての snap についてのステータスが表示されます。
以下に例を示します。
# gluster snapshot status snap3

Snap Name : snap3
Snap UUID : b2a391ce-f511-478f-83b7-1f6ae80612c8

     Brick Path        :
10.70.42.248:/var/run/gluster/snaps/e4a8f4b70a0b44e6a8bff5da7df48a4d/brick1/brick1
     Volume Group      :   snap_lvgrp1
     Brick Running     :   Yes
     Brick PID         :   1640
     Data Percentage   :   1.54
     LV Size           :   616.00m


     Brick Path        :
10.70.43.139:/var/run/gluster/snaps/e4a8f4b70a0b44e6a8bff5da7df48a4d/brick2/brick3
     Volume Group      :   snap_lvgrp1
     Brick Running     :   Yes
     Brick PID         :   3900
     Data Percentage   :   1.80
     LV Size           :   616.00m


     Brick Path        :
10.70.43.34:/var/run/gluster/snaps/e4a8f4b70a0b44e6a8bff5da7df48a4d/brick3/brick4
     Volume Group      :   snap_lvgrp1
     Brick Running     :   Yes
     Brick PID         :   3507
     Data Percentage   :   1.80
     LV Size           :   616.00m
注記
これは、アクティブ化されたスナップショットのステータスを表示します。

8.7. スナップショットの動作の設定

スナップショットの設定可能なパラメーターは以下のとおりです。
  • snap-max-hard-limit: ボリュームのスナップショット数がこの制限に達すると、スナップショットの作成は許可されません。範囲は 1 から 256 までです。この制限に達すると、スナップショットをさらに作成するためにスナップショットを削除する必要があります。この制限は、システムまたはボリュームごとに設定できます。システム制限とボリューム制限の両方が設定されている場合、有効な最大制限は 2 つの値の最も低い値になります。
  • snap-max-soft-limit: これはパーセンテージの値です。デフォルト値は 90% です。この設定は、自動削除機能と連携します。自動削除が有効な場合には、ボリュームのスナップショット数がこの制限を超える場合に最も古いスナップショットを削除します。自動削除が無効の場合、スナップショットは削除されませんが、ユーザーに警告メッセージが表示されます。
  • 自動削除: これにより、自動削除機能が有効または無効になります。デフォルトでは、自動削除は無効になっています。有効にすると、ボリュームのスナップショット数が snap-max-soft-limit を越える場合に最も古いスナップショットが削除されます。無効にするとスナップショットは削除されませんが、ユーザーに警告メッセージが表示されます。
  • activate-on-create: スナップショットは、デフォルトでは作成時にアクティブになりません。作成後にスナップショットをすぐにアクティブ化するには、activate-on-create パラメーターを enabled に設定します。すべてのボリュームは、この設定の影響を受けることに注意してください。
  • 設定値の表示

    ボリュームまたはクラスター全体の既存の設定値を表示するには、以下のコマンドを実行します。

    # gluster snapshot config [VOLNAME]
    各オプションについての説明は以下のとおりです。
    • VOLNAME: これは任意のフィールドです。設定値が表示されるボリュームの名前。
    ボリューム名を指定しないと、全ボリュームの設定値が表示されます。システム設定の詳細は、ボリューム名が指定されているかどうかに関係なく表示されます。
    以下に例を示します。
    # gluster snapshot config
    
    Snapshot System Configuration:
    snap-max-hard-limit : 256
    snap-max-soft-limit : 90%
    auto-delete : disable
    activate-on-create : disable
    
    Snapshot Volume Configuration:
    
    Volume : test_vol
    snap-max-hard-limit : 256
    Effective snap-max-hard-limit : 256
    Effective snap-max-soft-limit : 230 (90%)
    
    Volume : test_vol1
    snap-max-hard-limit : 256
    Effective snap-max-hard-limit : 256
    Effective snap-max-soft-limit : 230 (90%)
  • 設定値の変更

    既存の設定値を変更するには、以下のコマンドを実行します。

    # gluster snapshot config [VOLNAME] ([snap-max-hard-limit <count>] [snap-max-soft-limit <percent>]) | ([auto-delete <enable|disable>]) | ([activate-on-create <enable|disable>])
    各オプションについての説明は以下のとおりです。
    • VOLNAME: これは任意のフィールドです。設定値が変更されるボリュームの名前。ボリューム名が指定されていない場合には、コマンドを実行すると、システム制限が設定または変更します。
    • snap-max-hard-limit: システムまたは指定されたボリュームの最大ハード制限。
    • snap-max-soft-limit: システム用のソフト制限マーク。
    • auto-delete: 自動削除機能を有効または無効にします。デフォルトでは、自動削除は無効になっています。
    • activate-on-create: すべてのボリュームの activate-on-create 機能を有効または無効にします。デフォルトでは、activate-on-create は無効になっています。
    以下に例を示します。
    # gluster snapshot config test_vol snap-max-hard-limit 100
    Changing snapshot-max-hard-limit will lead to deletion of snapshots if
    they exceed the new limit.
    Do you want to continue? (y/n) y
    snapshot config: snap-max-hard-limit for test_vol set successfully

8.8. スナップショットのアクティブ化および非アクティブ化

アクティブなスナップショットにのみアクセスできます。詳細は、『Accessing Snapshot』 についてのセクションを参照してください。各スナップショットは Red Hat Gluster Storage ボリュームであるため、一部のリソースを消費します。スナップショットが必要ない場合は、スナップショットを無効にして必要に応じてアクティベートすることが適切です。スナップショットを有効にするには、以下のコマンドを実行します。
# gluster snapshot activate <snapname> [force]
各オプションについての説明は以下のとおりです。
  • snapname: アクティベートするクォータの名前。
  • 強制: スナップショットボリュームのブリックの一部がダウンしている場合は、force コマンドを使用して起動します。
以下に例を示します。
# gluster snapshot activate snap1
スナップショットを無効にするには、以下のコマンドを実行します。
# gluster snapshot deactivate <snapname>
各オプションについての説明は以下のとおりです。
  • snapname: 非アクティブ化するバッテリーの名前。
以下に例を示します。
# gluster snapshot deactivate snap1

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

スナップショットを削除する前に、以下の前提条件を満たしていることを確認してください。
  • 指定した名前のスナップショットが存在するはずです。
  • Red Hat Gluster Storage ノードはクォーラムである必要があります。
  • ボリューム操作 (add-brick、リバランスなど) は、スナップショットの元の / 親ボリュームで実行すべきではありません。
スナップショットを削除するには、以下のコマンドを実行します。
# gluster snapshot delete <snapname>
詳細は以下のようになります。
  • snapname: 削除するスナップショットの名前
以下に例を示します。
# gluster snapshot delete snap2
Deleting snap will erase all the information about the snap. Do you still want to continue? (y/n) y
snapshot delete: snap2: snap removed successfully
注記
スナップショットがボリュームに関連付けられている場合は、Red Hat Gluster Storage ボリュームは削除できません。ボリュームの削除を実行する前に、すべてのスナップショットを削除する必要があります。

8.9.1. 複数のスナップショットの削除

複数のスナップショットは、以下のいずれかのコマンドを使用して削除できます。
システムに存在するすべてのスナップショットを削除するには、以下のコマンドを実行します。
# gluster snapshot delete all
指定のボリュームに存在するスナップショットをすべて削除するには、以下のコマンドを実行します。
# gluster snapshot delete volume <volname>

8.10. スナップショットの復元

スナップショットを復元する前に、以下の前提条件を満たしていることを確認してください。
  • 指定したスナップショットが存在する必要があります。
  • スナップショットの元の / 親ボリュームは stop 状態である必要があります。
  • Red Hat Gluster Storage ノードはクォーラム(定足数)である必要があります。
  • ボリューム操作 (add-brick、リバランスなど) は、スナップショットの作成元または親ボリュームで実行すべきではありません。
    # gluster snapshot restore <snapname>
    詳細は以下のようになります。
    • snapname: 復元するスナップショットの名前
    以下に例を示します。
    # gluster snapshot restore snap1
    Snapshot restore: snap1: Snap restored successfully
    スナップショットを復元し、ボリュームが起動すると、以下のコマンドを実行して自己修復をトリガーします。
    # gluster volume heal VOLNAME full
    注記
    • スナップショットは復元後に削除されます。同じポイントに復元するには、スナップショットの復元後にスナップショットを明示的に作成します。
    • 作成元のボリュームのブリックパスを復元すると、そのパスが変更されます。fstab を使用して、作成元のボリュームのブリックをマウントする場合は、復元後に fstab エントリーを修正する必要があります。詳細は、https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/apcs04s07.html を参照してください。
  • クラスターで、スナップショットの status コマンドで、スナップショットに参加しているノードを特定します。以下は例になります。
     # gluster snapshot status snapname
    
        Snap Name : snapname
        Snap UUID : bded7c02-8119-491b-a7e1-cc8177a5a1cd
    
         Brick Path        :   10.70.43.46:/var/run/gluster/snaps/816e8403874f43a78296decd7c127205/brick2/brick2
         Volume Group      :   snap_lvgrp
         Brick Running     :   Yes
         Brick PID         :   8303
         Data Percentage   :   0.43
         LV Size           :   2.60g
    
    
         Brick Path        :   10.70.42.33:/var/run/gluster/snaps/816e8403874f43a78296decd7c127205/brick3/brick3
         Volume Group      :   snap_lvgrp
         Brick Running     :   Yes
         Brick PID         :   4594
         Data Percentage   :   42.63
         LV Size           :   2.60g
    
    
         Brick Path        :   10.70.42.34:/var/run/gluster/snaps/816e8403874f43a78296decd7c127205/brick4/brick4
         Volume Group      :   snap_lvgrp
         Brick Running     :   Yes
         Brick PID         :   23557
         Data Percentage   :   12.41
         LV Size           :   2.60g
    
    • 上記で特定されたノードで geo-replication リポジトリーが /var/lib/glusterd/snaps/snapname に存在するかどうかを確認します。リポジトリーがいずれかのノードにある場合、そのリポジトリーがクラスター全体で /var/lib/glusterd/snaps/snapname に同じファイルが存在することを確認してください。geo-replication リポジトリーがクラスター内のノードにない場合、これをノードの /var/lib/glusterd/snaps/snapname にコピーします。
    • 以下のコマンドを使用して、ボリュームのスナップショットを復元します。
      # gluster snapshot restore snapname

Geo レプリケーションボリュームのスナップショットの復元

geo レプリケーションの設定がある場合は、以下の手順を実行してスナップショットを復元します。

  1. geo レプリケーションセッションを停止します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop
  2. セカンダリーボリュームを停止し、プライマリーボリュームを停止します。
    # gluster volume stop VOLNAME
  3. セカンダリーボリュームおよびプライマリーボリュームのスナップショットを復元します。
    # gluster snapshot restore snapname
  4. 最初にセカンダリーボリュームを起動し、次にプライマリーボリュームを起動します。
    # gluster volume start VOLNAME
  5. geo レプリケーションセッションを開始します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start
    
  6. geo レプリケーションセッションを復元します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL resume
    

8.11. スナップショットへのアクセス

Red Hat Gluster Storage ボリュームのスナップショットには、FUSE マウントからしかアクセスできません。次のコマンドを使用して、スナップショットをマウントします。
mount -t glusterfs <hostname>:/snaps/<snapname>/parent-VOLNAME /mount_point
  • parent-VOLNAME: スナップショットを作成したボリューム名
    以下に例を示します。
    # mount -t glusterfs myhostname:/snaps/snap1/test_vol /mnt
Red Hat Gluster Storage スナップショットボリュームは読み取り専用であるため、このマウントでは書き込み操作は許可されません。スナップショットをマウントすると、スナップショットのコンテンツ全体が読み取り専用モードでアクセスできます。
注記
スナップショットボリュームの NFS および CIFS マウントはサポートされていません。
また、ユーザーサービス可能なスナップショットからスナップショットにアクセスすることもできます。詳細は、以下を参照してください。 「ユーザーサービス可能なスナップショット」
警告
Red Hat Gluster Storage Server がゲスト OS または FC/iSCSI SAN スナップショットとしてインストールされる仮想マシン/インスタンスのスナップショットなどの外部スナップショットはサポートされません。

8.12. スナップショットのスケジューリング

スナップショットスケジューラーは、設定されたスケジュール間隔に基づいてスナップショットを自動的に作成します。スナップショットは、設定した時間の間隔に基づいて、時間、月の特定の日、特定の月、一週間の特定の日で作成できます。以下のセクションでは、スナップショットのスケジューリングを詳細に説明します。

8.12.1. 前提条件

  • クラスターのすべてのノードでスナップショットスケジューラーを初期化するには、以下のコマンドを実行します。
    snap_scheduler.py init
    
    このコマンドは、snap_scheduler を初期化し、ローカルノードで実行中の crond でインターフェースします。これは、ノードからスケジューリング関連のコマンドを実行する前の最初の手順です。
    注記
    このコマンドは、スケジューリングに参加しているすべてのノードで実行する必要があります。他のオプションは、初期化が正常に完了した任意のノードとは別に実行できます。
  • gluster_shared_storage という名前の共有ストレージは、スケジューリング操作を調整するためにノード間で使用されます。この共有ストレージは、すべてのノードの /var/run/gluster/shared_storage にマウントされます。詳細は、以下を参照してください。 「共有ストレージボリュームの設定」
    注記
    3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
  • クラスター内のすべてのノードは、NTP またはその他のメカニズムを使用して同期する時間を持ちます。この機能は、この機能を機能させるためのハード要件です。
  • Red Hat Enterprise Linux 7.1 以降を使用している場合は、以下のコマンドを実行して cron_system_cronjob_use_shares ブール値を on に設定します。
    # setsebool -P cron_system_cronjob_use_shares on
    

8.12.2. スナップショットスケジューラーのオプション

注記
ヘルパースクリプトとコマンドを有効にするまでに 1 分間のレイテンシーがあります。したがって、現時点では、1 分間の粒度のスナップショットスケジュールをサポートしません。

Snapshot Scheduler の有効化

snap スケジューラーを有効にするには、以下のコマンドを実行します。

snap_scheduler.py enable
注記
スナップショットスケジューラーは、初期化後にデフォルトで無効になっています。
以下に例を示します。
# snap_scheduler.py enable
snap_scheduler: Snapshot scheduling is enabled

スナップショットスケジューラーの無効化

snap スケジューラーを有効にするには、以下のコマンドを実行します。

 snap_scheduler.py disable
以下に例を示します。
# snap_scheduler.py disable
snap_scheduler: Snapshot scheduling is disabled

スナップショットスケジューラーのステータスの表示

snap スケジューラーの現在のステータス (Enabled/Disabled) を表示するには、以下のコマンドを実行します。

snap_scheduler.py status
以下に例を示します。
# snap_scheduler.py status
snap_scheduler: Snapshot scheduling status: Disabled

スナップショットスケジュールの追加

スナップショットスケジュールを追加するには、以下のコマンドを実行します。

snap_scheduler.py add "Job Name" "Schedule" "Volume Name"
詳細は以下のようになります。
Job Name: この名前は、この特定のスケジュールを一意に識別し、編集/削除などの今後のイベントのこのスケジュールを参照するために使用できます。指定したジョブ名に対してスケジュールがすでに存在する場合、追加コマンドは失敗します。
schedule: スケジュールは crond が認識できる形式で許可されます。以下に例を示します。
Example of job definition:
.---------------- minute (0 - 59)
| .------------- hour (0 - 23)
| | .---------- day of month (1 - 31)
| | | .------- month (1 - 12) OR jan,feb,mar,apr ...
| | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
| | | | |
* * * * * user-name command to be executed
Volume name: スケジュールしたスナップショット操作が実行されるボリュームの名前
以下に例を示します。
# snap_scheduler.py add "Job1" "* * * * *" test_vol
snap_scheduler: Successfully added snapshot schedule
注記
スケジューラーが取得したスナップショットには、以下の命名規則があります。Scheduler-<Job Name>-<volume name>_<Timestamp>
以下に例を示します。
Scheduled-Job1-test_vol_GMT-2015.06.19-09.47.01

スナップショットスケジュールの編集

既存のスナップショットスケジュールを編集するには、以下のコマンドを実行します。

snap_scheduler.py edit "Job Name" "Schedule" "Volume Name"
詳細は以下のようになります。
Job Name: この名前は、この特定のスケジュールを一意に識別し、編集/削除などの今後のイベントのこのスケジュールを参照するために使用できます。指定したジョブ名に対してスケジュールがすでに存在する場合、追加コマンドは失敗します。
schedule: スケジュールは crond が認識できる形式で許可されます。以下に例を示します。
Example of job definition:
.---------------- minute (0 - 59)
| .------------- hour (0 - 23)
| | .---------- day of month (1 - 31)
| | | .------- month (1 - 12) OR jan,feb,mar,apr ...
| | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
| | | | |
* * * * * user-name command to be executed
ボリューム名: スナップショットのスケジュールを編集するボリュームの名前。
以下に例を示します。
# snap_scheduler.py edit "Job1" "*/5 * * * *" gluster_shared_storage
snap_scheduler: Successfully edited snapshot schedule

スナップショットスケジュールの一覧表示

既存のスナップショットスケジュールを一覧表示するには、以下のコマンドを実行します。

snap_scheduler.py list
以下に例を示します。
# snap_scheduler.py list
JOB_NAME         SCHEDULE         OPERATION        VOLUME NAME
--------------------------------------------------------------------
Job0                          * * * * *                Snapshot Create    test_vol

スナップショットスケジュールの削除

既存のスナップショットスケジュールを削除するには、以下のコマンドを実行します。

snap_scheduler.py delete "Job Name"
詳細は以下のようになります。
Job Name: この名前は削除する必要のある特定のスケジュールを一意に識別します。
以下に例を示します。
# snap_scheduler.py delete Job1
snap_scheduler: Successfully deleted snapshot schedule

8.13. ユーザーサービス可能なスナップショット

ユーザーサービス可能なスナップショットは、スナップショットを作成したボリュームに保存されているデータにアクセスし、簡単かつ簡単な方法です。この機能は、Red Hat Gluster Storage のコアスナップショット機能に基づいています。ユーザーサービス可能なスナップショット機能を使用すると、スナップショットボリュームのアクティブ化されたスナップショットにアクセスできます。
Home ディレクトリーにあるファイル test .txt に 2 カ月前および誤って削除されたファイル test.txt にアクセスしたいシナリオについて考えてみましょう。ホームディレクトリー内にある virtual .snaps ディレクトリーに移動して、cp コマンドを使用して test.txt ファイルを復旧できるようになりました。
注記
  • ユーザーサービス可能なスナップショットは、以前のスナップショットボリュームから一括データアクセスで推奨されるオプションではありません。このようなシナリオでは、スナップショットボリュームをマウントしてからデータにアクセスすることが推奨されます。詳細は、以下を参照してください。 8章スナップショットの管理
  • ユーザーサービススナップショットによって初期化される際にアクティブ化された各スナップショットボリュームは、メモリーを消費します。メモリーの多くは、gfapi や AFR などのさまざまなハウスキーピング構造によって消費されます。したがって、スナップショットによるメモリー消費量の合計は、ブリックの数も異なります。各ブリックは約 10 MB の領域を消費します。たとえば、4x3 レプリカの設定では、約 50 MB、6x3 設定の場合は約 90 MB になります。
    したがって、アクティブなスナップショットの数が増えると、スナップショットデーモン (snapd) の合計メモリーフットプリントも増えます。そのため、メモリー不足のシステムでは、アクティブなスナップショットが多すぎる場合にスナップショットデーモンが OOM で強制終了される可能性があります。

8.13.1. ユーザーサービス可能なスナップショットの有効化および無効化

ユーザーのサービス可能なスナップショットを有効にするには、以下のコマンドを実行します。
# gluster volume set VOLNAME features.uss enable
以下に例を示します。
# gluster volume set test_vol features.uss enable
volume set: success
スナップショットをアクティベートして、ユーザーサービス可能なスナップショットからアクセスします。
# gluster snapshot activate <snapshot-name>
ユーザーのサービス可能なスナップショットを無効にするには、以下のコマンドを実行します。
# gluster volume set VOLNAME features.uss disable
以下に例を示します。
# gluster volume set test_vol features.uss disable
volume set: success

8.13.2. NFS / FUSE を使用したスナップショットの表示および取得

ボリュームで利用可能なスナップショットごとに、ボリュームにアクセスできるすべてのユーザーには、ボリュームの読み取り専用ビューが表示されます。異なる時点からボリュームの読み取り専用ビューを使用して、ファイルを復元できます。ボリュームの各スナップショットは、マウントされたボリュームのすべてのディレクトリーの .snaps ディレクトリーにあります。
注記
スナップショットにアクセスするには、まずボリュームをマウントする必要があります。
NFS マウントの詳細は、「Gluster NFS を使用したボリュームの手動マウント (非推奨)」 を参照してください。以下のコマンドは例です。
# mount -t nfs -o vers=3 server1:/test-vol /mnt/glusterfs
FUSE マウントの詳細は、「ボリュームの手動マウント」 を参照してください。以下のコマンドは例です。
# mount -t glusterfs server1:/test-vol /mnt/glusterfs
.snaps ディレクトリーは、ls コマンドまたは ls -a オプションで一覧表示されない仮想ディレクトリーです。.snaps ディレクトリーには、指定したボリューム用に作成されたすべてのスナップショットが個別のディレクトリーとして含まれます。これらのスナップショットエントリーにはそれぞれ、スナップショットの取得時にユーザーがアクセスしている特定のディレクトリーのデータが含まれます。
スナップショットからファイルを表示または取得するには、以下の手順に従います。
  1. スナップショットの取得時にファイルが存在するフォルダーに移動します。たとえば、復元するマウントのルートディレクトリーに test.txt ファイルがある場合には、そのディレクトリーに移動します。
    # cd /mnt/glusterfs
    注記
    すべてのディレクトリーには virtual .snaps ディレクトリーがあるため、ここから .snaps ディレクトリーを入力できます。since .snaps は仮想ディレクトリーであるため、lsls -a コマンドは .snaps ディレクトリーを一覧表示しません。以下は例になります。
    # ls -a
          ....Bob  John  test1.txt  test2.txt
  2. .snaps フォルダーに移動します。
    # cd .snaps
  3. ls コマンドを実行して、snaps の一覧を表示します。
    以下は例になります。
     # ls -p
     snapshot_Dec2014/    snapshot_Nov2014/    snapshot_Oct2014/    snapshot_Sept2014/
  4. ファイルを取得する必要があるスナップショットディレクトリーに移動します。
    以下に例を示します。
    cd snapshot_Nov2014
    # ls -p
        John/  test1.txt  test2.txt
  5. ファイル/ディレクトリーを希望の場所にコピーします。
    # cp -p test2.txt  $HOME

8.13.3. Windows Client で CIFS を使用したスナップショットの表示および取得

ボリュームで利用可能なスナップショットごとに、ボリュームにアクセスできるすべてのユーザーには、ボリュームの読み取り専用ビューが表示されます。異なる時点からボリュームの読み取り専用ビューを使用して、ファイルを復元できます。ボリュームの各スナップショットは、CIFS 共有のルート 内のすべてのフォルダーの.snaps フォルダーで利用できます。.snaps フォルダーは、次のコマンドを使用してボリュームで以下のオプションが ON に設定されている場合のみ表示される非表示フォルダーです。
# gluster volume set volname features.show-snapshot-directory on
オプションを ON に設定すると、以下の手順に従ってすべての Windows クライアントは .snaps フォルダーにアクセスできます。
  1. Folder オプションで、非表示のファイル、フォルダー、ドライブの オプションを有効にします。
  2. CIFS 共有のルートに移動し、.snaps フォルダーを表示します。
    注記
    この .snaps フォルダーは CIFS 共有のルートでのみアクセスでき、サブフォルダーにはアクセスできません。
  3. スナップショットの一覧は、.snaps フォルダーにあります。必要なファイルにアクセスし、取得できるようになりました。
Samba を使用して Windows のスナップショットにアクセスすることもできます。詳細は、「Windows でのスナップショットへのアクセス」 を参照してください。

8.14. スナップショットのトラブルシューティング

  • 状況

    スナップショットの作成に失敗します。

    ステップ 1

    以下の手順で、ブリックがシンプロビジョニングされているかどうかを確認します。

    1. mount コマンドを実行して、ブリックパスにマウントされているデバイス名を確認します。以下は例になります。
      # mount
      /dev/mapper/snap_lvgrp-snap_lgvol on /rhgs/brick1 type xfs (rw)
      /dev/mapper/snap_lvgrp1-snap_lgvol1 on /rhgs/brick2 type xfs (rw)
    2. 以下のコマンドを実行して、デバイスに論理ボリュームプール名があるかどうかを確認します。
      lvs device-name
      以下に例を示します。
      #  lvs -o pool_lv /dev/mapper/snap_lvgrp-snap_lgvol
         Pool
         snap_thnpool
      
      
      
      Pool フィールドが空の場合は、ブリックはシンプロビジョニングされません。
    3. ブリックがシンプロビジョニングされていることを確認し、スナップショットの作成コマンドを再試行します。

    ステップ 2

    以下の手順を実行して、ブリックがダウンしているかどうかを確認します。

    1. 以下のコマンドを実行して、ボリュームのステータスを確認します。
      # gluster volume status VOLNAME
    2. ブリックがダウンしている場合は、以下のコマンドを実行してブリックを起動します。
      # gluster volume start VOLNAME force
    3. ブリックが稼働中かどうかを確認するには、以下のコマンドを実行します。
      # gluster volume status VOLNAME
    4. snapshot create コマンドを再試行します。

    ステップ 3

    以下の手順に従って、ノードがダウンしているかどうかを確認します。

    1. 以下のコマンドを実行して、ノードのステータスを確認します。
      # gluster volume status VOLNAME
    2. ブリックがステータスに記載されていない場合は、以下のコマンドを実行します。
      # gluster pool list
    3. 不足しているブリックをホストするノードのステータスが Disconnected の場合には、ノードの電源を切ります。
    4. snapshot create コマンドを再試行します。

    ステップ 4

    以下の手順に従い、リバランスが進行中かどうかを確認します。

    1. 以下のコマンドを実行して、リバランスのステータスを確認します。
      gluster volume rebalance VOLNAME status
    2. リバランスが進行中であれば、それが完了するまで待ちます。
    3. snapshot create コマンドを再試行します。
  • 状況

    スナップショットの削除に失敗します。

    ステップ 1

    以下の手順を実行してサーバークォーラムを満たしているかどうかを確認します。

    1. 以下のコマンドを実行してピアのステータスを確認します。
      # gluster pool list
    2. ノードがダウンし、クラスターがクォーラムでない場合は、ノードの電源をオンにします。
    3. クラスターがクォーラムにあることを確認するには、以下のコマンドを実行します。
      # gluster pool list
    4. snapshot delete コマンドを再試行します。
  • 状況

    コミットフェーズ中に一部のノードでスナップショットの削除コマンドに失敗し、システムの整合性が保たれます。

    解決策

    1. 削除コマンドに失敗したノードを特定します。この情報は、削除コマンドの出力で利用できます。以下に例を示します。
      # gluster snapshot delete snapshot1
      Deleting snap will erase all the information about the snap. Do you still want to continue? (y/n) y
      snapshot delete: failed: Commit failed on 10.00.00.02. Please check log file for details.
      Snapshot command failed
    2. delete コマンドが失敗するノードで、以下のコマンドを使用して glusterd を停止します。
      RHEL 7 および RHEL 8 で以下を実行します。
      # systemctl stop glusterd
      RHEL 6 で以下を実行します。
      # service glusterd stop
      重要
      Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。『 インストールガイド』の「 『バージョンの詳細』 表」 『および「Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 」を参照してください。
    3. そのノードから /var/lib/glusterd/snaps/ 内の特定の snaps リポジトリーを削除します。以下は例になります。
      # rm -rf /var/lib/glusterd/snaps/snapshot1
    4. 以下のコマンドを使用して、そのノードで glusterd を起動します。
      RHEL 7 および RHEL 8 で以下を実行します。
      # systemctl start glusterd
      RHEL 6 で以下を実行します。
      # service glusterd start.
      重要
      Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。『 インストールガイド』の「 『バージョンの詳細』 表」 『および「Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 」を参照してください。
    5. 1st ステップでコミットが特定に失敗したすべてのノードで 2 番目の、3 番目のステップ、および 4 番目のステップを繰り返します。
    6. スナップショットの削除を再試行します。以下に例を示します。
      # gluster snapshot delete snapshot1
  • 状況

    スナップショットの復元に失敗します。

    ステップ 1

    以下の手順を実行してサーバークォーラムを満たしているかどうかを確認します。

    1. 以下のコマンドを実行してピアのステータスを確認します。
      # gluster pool list
    2. ノードがダウンし、クラスターがクォーラムでない場合は、ノードの電源をオンにします。
    3. クラスターがクォーラムにあることを確認するには、以下のコマンドを実行します。
      # gluster pool list
    4. スナップショットの復元コマンドを再試行します。

    ステップ 2

    以下の手順に従い、ボリュームが Stop 状態かどうかを確認します。

    1. 以下のコマンドを実行して、ボリューム情報を確認します。
      # gluster volume info VOLNAME
    2. ボリュームが Started 状態にある場合は、以下のコマンドを使用してボリュームを停止します。
      gluster volume stop VOLNAME
    3. スナップショットの復元コマンドを再試行します。
  • 状況

    スナップショットコマンドは失敗します。

    ステップ 1

    以下の手順に従い、オペレーティングシステムのバージョンに不一致があるかどうかを確認します。

    1. 以下のファイルを開き、操作バージョンを確認します。
      /var/lib/glusterd/glusterd.info
      operating-version が 30000 未満の場合、クラスターが動作するバージョンでスナップショットコマンドはサポートされません。
    2. クラスター内の全ノードを Red Hat Gluster Storage 3.2 以降にアップグレードします。
    3. snapshot コマンドを再試行します。
  • 状況

    ローリングアップグレードの後に、スナップショット機能は機能しません。

    解決策

    スナップショットを有効にするには、クラスターで以下の変更を加える必要があります。

    1. 以下のコマンドを使用してボリュームを再起動します。
      # gluster volume stop VOLNAME
      # gluster volume start VOLNAME
    2. すべてのノードで glusterd サービスを再起動します。
      RHEL 7 および RHEL 8 で以下を実行します。
      # systemctl restart glusterd
      RHEL 6 で以下を実行します。
      # service glusterd restart
      重要
      Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。『 インストールガイド』の「 『バージョンの詳細』 表」 『および「Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 」を参照してください。

第9章 ディレクトリークォータの管理

警告
クォータは、Red Hat Gluster Storage 3.5 では非推奨とみなされます。Red Hat では使用を推奨しません。また、Red Hat Gluster Storage 3.5.3 へのアップグレード後の新規デプロイメントおよび既存のデプロイメントでクォータはサポートしません。
クォータを使用すると、ディレクトリーで使用するディスク領域に制限を設定できます。ストレージ管理者は、ディレクトリーおよびボリュームレベルでディスク領域の使用率を制御できます。これは、ユーティリティーの請求モデルの使用を容易にするために、クラウドデプロイメントで特に役立ちます。

9.1. クォータの有効化および無効化

ディスクの使用状況を制限するには、以下のコマンドを実行してボリュームでクォータの使用状況を有効にする必要があります。
# gluster volume quota VOLNAME enable
このコマンドは、ボリュームでクォータの動作のみを有効にします。デフォルトのディスク使用量は設定しません。
注記
クォータが有効な Gluster ボリュームでは、CPU およびメモリーの消費量は、さまざまな要因に基づいて加算されます。たとえば、ファイルシステムツリーの複雑さやプール内のブリック数、ファイルシステム全体でのクォータ制限数、およびファイルシステム全体でクォータバーサルタの頻度などが複雑になります。
ディスクの使用率制限の設定など、ボリュームでクォータの動作を無効にするには、以下のコマンドを実行します。
# gluster volume quota VOLNAME disable
重要
Red Hat Gluster Storage 3.1.1 以前のクォータを無効にする場合、以前に設定したすべての制限はクリーンアッププロセスである quota-remove-xattr.sh によってボリュームから削除されます。クリーンアッププロセスが実行中にクォータを再度有効にすると、クリーンアッププロセスでクォータを有効にする拡張属性が削除される可能性があります。これは、クォータアカウンティングに悪影響を及ぼすものです。

9.2. ディレクトリーにクォータを設定する前

ディレクトリーにクォータを設定する際に、保持する事項が複数あります。
  • Gluster ボリュームのクォータ コマンドで制限するディレクトリーを指定する場合、ディレクトリーのパスは Red Hat Gluster Storage ボリュームのマウントポイントに相対的となり、ボリュームがマウントされるサーバーまたはクライアントの root ディレクトリーではありません。つまり、Red Hat Gluster Storage ボリュームが /mnt/glusterfs にマウントされ、/ mnt/glusterfs/dir ディレクトリーに制限を配置する場合は、以下のように、gluster ボリュームクォータ コマンドを実行する際に /dir をパスとして使用します。
    # gluster volume quota VOLNAME limit-usage /dir hard_limit
  • Gluster ボリュームのクォータ コマンドを実行する際に、レプリカセットごとに少なくとも 1 つのブリックが利用可能であることを確認します。Gluster ボリュームステータス コマンドの出力の Online 列に Y が表示されている場合は、ブリックを使用できます。
    # gluster volume status VOLNAME
    Status of volume: VOLNAME
    Gluster process                        Port    Online   Pid
    ------------------------------------------------------------
    Brick arch:/export/rep1                24010   Y       18474
    Brick arch:/export/rep2                24011   Y       18479
    NFS Server on localhost                38467   Y       18486
    Self-heal Daemon on localhost          N/A     Y       18491

9.3. ディスク使用量の制限

9.3.1. ディスク使用量の制限の設定

特定のパフォーマンスレベルを実現するために、一定量の空き容量をシステムに確保する必要がある場合は、Red Hat Gluster Storage がボリュームまたはディレクトリーで消費する領域の量を制限する必要がある場合があります。
以下のコマンドを使用して、ディレクトリーの許可される合計サイズ、またはボリューム上で消費される合計容量を制限します。
# gluster volume quota VOLNAME limit-usage path hard_limit
たとえば、データボリュームの /dir ディレクトリーのサイズを 100 GB に制限するには、以下のコマンドを実行します。
# gluster volume quota data limit-usage /dir 100GB
これにより、/dir ディレクトリーと下のすべてのファイルおよびディレクトリーが累積的に 100 GB を超えるデータが含まれないようにします。
data ボリューム全体のサイズを 1 TB に制限するには、以下のようにボリュームのルートディレクトリーに 1 TB の制限を設定します。
# gluster volume quota data limit-usage / 1TB
ハード制限の割合をソフト制限に設定することもできます。ディレクトリーログのソフト制限を超えると、ディスクの使用を妨げるのではなく、警告が記録されます。たとえば、1TB のボリュームのハード制限の 75% にソフト制限を設定するには、以下のコマンドを実行します。
# gluster volume quota data limit-usage / 1TB 75
デフォルトでは、ブリックログは /var/log/glusterfs/bricks/BRICKPATH.log にあります。
デフォルトのソフト制限は 80% です。ただし、default- soft-limit サブコマンドを使用すると、ボリュームごとにデフォルトの ソフト制限を変更することができます。たとえば、データボリュームにデフォルトのソフト制限の 90% を設定するには、以下のコマンドを実行します。
# gluster volume quota data default-soft-limit 90
次に、以下のコマンドで新しい値が設定されていることを確認します。
# gluster volume quota VOLNAME list
デフォルトのソフト制限を変更しても、limit -usage サブコマンドで設定されたソフト制限は削除されません。

9.3.2. 現在のディスク使用量の制限の表示

ボリュームに現在設定されている制限をすべて表示するには、以下のコマンドを実行します。
# gluster volume quota VOLNAME list
たとえば、test-volume に設定されたクォータ制限を表示するには、以下を実行します。
# gluster volume quota test-volume list
Path        Hard-limit  Soft-limit   Used      Available
--------------------------------------------------------
/           50GB        75%          0Bytes    50.0GB
/dir        10GB        75%          0Bytes    10.0GB
/dir/dir2   20GB        90%          0Bytes    20.0GB
特定のディレクトリーの制限情報を表示するには、ディレクトリーパスを指定します。ディレクトリーのパスは、ボリュームがマウントされるサーバーまたはクライアントのルートディレクトリーではなく、Red Hat Gluster Storage ボリュームのマウントポイントに相対的です。
# gluster volume quota VOLNAME list /<directory_name>
たとえば、test-volume ボリュームの /dir ディレクトリーに設定した制限を表示するには、以下を実行します。
# gluster volume quota test-volume list /dir
Path  Hard-limit   Soft-limit   Used   Available
-------------------------------------------------
/dir   10.0GB          75%       0Bytes  10.0GB
複数のディレクトリーを一覧表示して、指定した各ディレクトリーにディスク制限情報を表示することもできます。以下に例を示します。
# gluster volume quota VOLNAME list DIR1  DIR2

9.3.2.1. df ユーティリティーを使用したクォータ制限情報の表示

デフォルトでは、ディスク使用量を報告する際には、df ユーティリティーはクォータ制限を考慮しません。つまり、ディレクトリーにアクセスするクライアントは、クォータでディレクトリーに割り当てられた合計領域ではなく、ボリュームで利用可能な合計領域を確認することを意味します。quota-deem-statfs パラメーターを on に設定すると、代わりにハードクォータ制限をディスク領域の合計として表示するようにボリュームを設定することができます。
quota-deem-statfs パラメーターを on に設定するには、以下のコマンドを実行します。
# gluster volume set VOLNAME quota-deem-statfs on
これにより、df が、クライアントのディスクスペースとしてハードクォータ制限を表示します。
以下の例は、quota-deem-statfsoff に設定されている場合にクライアントからのディスク使用量を表示します。
# df -hT /home
Filesystem           Type            Size  Used Avail Use% Mounted on
server1:/test-volume fuse.glusterfs  400G   12G  389G   3% /home
以下の例は、quota-deem-statfs が で設定されている場合に、クライアントに表示される ディスク使用量を表示します。
# df -hT /home
Filesystem            Type            Size  Used Avail Use% Mounted on
server1:/test-volume  fuse.glusterfs  300G   12G  289G   4% /home

9.3.3. クォータチェック頻度 (タイムアウト) の設定

ソフトおよびハードタイムアウトを指定することで、Red Hat Gluster Storage がディスク使用量をディスク使用量に対してチェックする頻度を設定できます。
soft-timeout パラメーターは、Red Hat Gluster Storage が使用中に容量をチェックする頻度を指定します。したがって、ディレクトリーまたはボリュームに設定したソフト制限の下にあります。デフォルトのソフトタイムアウト頻度は 60 秒ごとに設定されています。
別のソフトタイムアウトを指定するには、以下のコマンドを実行します。
# gluster volume quota VOLNAME soft-timeout seconds
hard-timeout パラメーターは、Red Hat Gluster Storage がディレクトリーまたはボリュームに設定されたソフト制限以上の使用量をチェックする頻度を指定します。デフォルトのハードタイムアウト頻度は 5 秒ごとにです。
別のハードタイムアウトを指定するには、以下のコマンドを実行します。
# gluster volume quota VOLNAME hard-timeout seconds
重要
ディスク使用量のエラーのマージンはシステムのワークロードに比例するため、ソフトタイムアウトおよびハードタイムアウトを設定する際に、システムおよびアプリケーションのワークロードを考慮してください。

9.3.4. ロギング頻度の設定 (アラート時間)

alert-time パラメーターは、ソフト制限に達した後に使用情報をログに記録する方法を設定します。以下のコマンドを使用して、アラート時間 を設定できます。
# gluster volume quota VOLNAME alert-time time
デフォルトでは、アラート時間は 1 週間 (1w) です。
コマンドの time パラメーターは、以下のいずれかの形式で使用できます。

表9.1

時間の単位 形式 1 形式 2
[integer]s [integer]sec
[integer]m [integer]min
時間 [integer]h [integer]hr
[integer]d [integer]days
[integer]w [integer]wk
[integer] は、指定する必要のある時間の単位の数です。任意の時間単位の形式のいずれかを使用できます。以下に例を示します。
以下のコマンドは、test-vol という名前のボリュームのロギング頻度を 10 分ごとに設定します。
# gluster volume quota test-vol alert-time 10m
ただし、以下のコマンドは test-vol という名前のボリュームのロギング頻度を 10 日ごとに設定します。
# gluster volume quota test-vol alert-time 10days

9.3.5. ディスク使用量の制限の削除

ディスクの使用を制限する必要がない場合は、以下のコマンドを実行してディレクトリーで使用制限を削除できます。
# gluster volume quota VOLNAME remove DIR
たとえば、test-volume/data ディレクトリー上のディスク制限の使用量を削除するには、次のコマンドを実行します。
# gluster volume quota test-volume remove /data
  volume quota : success
ボリューム全体のクォータを削除するには、以下のコマンドを実行します。
# gluster vol quota VOLNAME remove /
これにより制限は再帰的に削除されず、ボリューム全体の制限にのみ影響します。

第10章 Geo レプリケーションの管理

本セクションでは、geo レプリケーションを紹介し、さまざまなデプロイメントシナリオを説明します。また、geo レプリケーションおよびミラーリングの設定方法について説明します。

10.1. Geo レプリケーションについて

地理的なレプリケーションは、ローカルエリアネットワーク (LAN)、Internet Area Network (WAN)、およびインターネットを介して、あるサイトから別のサイトに分散され、継続的かつ非同期のレプリケーションサービスを提供します。
geo レプリケーションはプライマリー/セカンダリーモデルを使用します。ここでは、以下のパートナー間でレプリケーションとミラーリングが行われます。
  • プライマリー: プライマリー Red Hat Gluster Storage ボリューム。
  • セカンダリー: セカンダリー Red Hat Gluster Storage ボリューム。スレーブボリュームは、remote -host::volname などのリモートホストの ボリュームになります。

10.2. 複製されたボリュームと Geo レプリケーション

以下の表は、複製されたボリュームと地理的なレプリケーションの違いを示しています。
複製ボリューム geo-レプリケーション
変更が両方の方向で同期されるように、レプリカセットのすべてのブリック間で機能します。プライマリーボリュームからセカンダリーボリュームにのみ機能します。
1 つの信頼済みストレージプール内のブリック間でデータをミラーリングします。 地理的に分散されている信頼できるストレージプール全体でデータをミラーリングします。
高可用性を提供します。 障害復旧用のデータバックアップを提供します。
同期レプリケーション: 各ファイル操作はすべてのブリックに適用されます。 非同期レプリケーション: ファイルの変更を定期的にチェックし、差分の検出時にそれらを同期します。

10.3. Geo レプリケーションへのデプロイの準備

本セクションでは、geo レプリケーションのデプロイメントシナリオの概要、前提条件の一覧、geo レプリケーションセッションの環境の設定方法について説明します。

10.3.1. Geo レプリケーションデプロイメントシナリオの展開

Geo レプリケーションは、ローカルエリアネットワーク (LAN)、Internet Area Network (WAN)、およびインターネットを介して増分レプリケーションサービスを提供します。本セクションでは、以下を含む、geo レプリケーションの最も一般的なデプロイメントシナリオを説明します。
  • LAN 上の geo レプリケーション
  • WAN 上の geo レプリケーション
  • インターネット上の geo レプリケーション
  • 複数のサイトカスケード geo レプリケーション
LAN 上の geo レプリケーション
LAN 上の geo レプリケーション
WAN 上の geo レプリケーション
WAN 上の geo レプリケーション
インターネット上の geo レプリケーション
インターネット上の geo レプリケーション
マルチサイト geo レプリケーション
マルチサイト geo レプリケーション

10.3.2. geo レプリケーションデプロイメントの概要

geo レプリケーションをデプロイするには、以下の手順が必要です。
  1. お使いの環境が最小システム要件と一致することを確認します。「前提条件」 を参照してください。
  2. 適切なデプロイメントシナリオを決定します。「Geo レプリケーションデプロイメントシナリオの展開」 を参照してください。
  3. プライマリーシステムとセカンダリーシステムで geo レプリケーションを開始します。

10.3.3. 前提条件

以下は、geo レプリケーションをデプロイするための前提条件です。
これらの前提条件は、あるクラスターから別のクラスターに 1 回のみ実行される必要があるため、同じプライマリークラスターから同じセカンダリークラスターに複数のボリュームを同期する場合は、これらの前提条件を 1 回のみ実行する必要があります。
  • プライマリーボリュームおよびセカンダリーボリュームは、同じバージョンの Red Hat Gluster Storage を使用する必要があります。
  • セカンダリーボリュームのノードはプライマリーボリュームの一部にすることはできません。2 つの信頼済みストレージプールが必要です。
  • 以下のコマンドを使用して、スレーブボリュームの performance.quick-read オプションを無効にします。
    [slave ~]# gluster volume set slavevol performance.quick-read off
  • geo レプリケーションを設定する前に、すべてのプライマリーノードとセカンダリーノード間で時間を同期する必要があります。Red Hat は、ブリックとサーバー間で時刻を同期するようにネットワークタイムプロトコルサービスを設定し、時刻の同期エラーを回避することを推奨します。
    詳細は、「ネットワーク時刻プロトコルの設定」を参照してください。
  • 「ポートアクセスの要件」 に記載されているポートから Geo レプリケーションに必要なポートを追加します。
  • パスワードなしの鍵ベースの SSH 認証は、マスターボリュームの 1 つのノード( geo レプリケーションの作成 コマンドが実行されるノード)とスレーブボリュームの 1 つのノード( geo レプリケーションの作成 コマンドの実行時にスレーブ名に記載されるノード)が必要です。
    マスターノードで ssh-keygen (パスフレーズなしで)を使用して公開鍵および秘密鍵を作成します。
    # ssh-keygen
    以下のコマンドを使用して、公開鍵をセカンダリーノードにコピーします。
    # ssh-copy-id -i identity_file root@slave_node_IPaddress/Hostname
    root 以外のジオレプリケーションセッションを設定する場合は、公開鍵をそれぞれのユーザー場所にコピーし ます
    注記
    - パスワードのない鍵ベースの SSH 認証は、プライマリーノードからセカンダリーノードにのみ必要です。セカンダリーノードは、このレベルのアクセスを必要としません。
    - ssh authorized_keys ファイルがカスタムの場所に設定されていると、ssh-copy-id コマンドは機能しません。マスターから .ssh/id_rsa.pub ファイルの内容をコピーし、Slave ノードのカスタム場所にある authorized_keys ファイルに貼り付ける必要があります。
    Gsyncd では、プライマリーノードのすべてのノード間でパスワードなしで、セカンダリークラスター内のすべてのノードへのキーベースの SSH 認証も必要になります。gluster system:: を実行すると、gsec_create コマンドを実行すると、マスター内の全ノードに secret-pem ファイルを作成し、SSH 認証接続を実装するために使用されます。geo -replication create コマンドの push- pem オプションは、これらの鍵をすべてのスレーブノードにプッシュします。
    gluster system::execute gsec_create コマンドおよび push-pem コマンドの詳細は、「Geo レプリケーションセッションの環境の設定」 を参照してください。

10.3.4. 環境の設定

以下の方法で、geo レプリケーションセッションの環境を設定できます。

10.3.4.1. Geo レプリケーションセッションの環境の設定

Geo レプリケーションセッションの作成

  1. common pem pub ファイルを作成するには、キーベースの認証接続が設定されたマスターノードで以下のコマンドを実行します。
    # gluster system:: execute gsec_create
    または、鍵ベースの SSH 認証接続が設定されたマスターノードで以下のコマンドを実行して pem pub ファイルを作成できます。この代替コマンドは、すべてのマスターノードで Geo-rep セッション固有の ssh-keys を生成し、全ピアノードから公開鍵を収集します。また、コマンドのステータスの詳細なビューも提供します。
    # gluster-georep-sshkey generate
    
    +--------------+-------------+---------------+
    |     NODE     | NODE STATUS | KEYGEN STATUS |
    +--------------+-------------+---------------+
    |     node1    |          UP |            OK |
    |     node2    |          UP |            OK |
    |     node3    |          UP |            OK |
    |     node4    |          UP |            OK |
    |     node5    |          UP |            OK |
    |  localhost   |          UP |            OK |
    +--------------+-------------+---------------+
    
  2. 以下のコマンドを使用して geo レプリケーションセッションを作成します。スレーブノードで必要な pem- file 設定を実行するには、push -pem オプションが必要です。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL create push-pem [force]
    以下は例になります。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol create push-pem
    注記
    • このコマンドを実行するノードと、上記コマンドで指定されたセカンダリーホストの間に、キーベースの SSH 認証アクセスが必要です。このコマンドは、有効なセカンダリー URL の確認、有効なセカンダリーボリューム、およびセカンダリーで利用可能な領域の確認など、セカンダリーの検証を実行します。検証に失敗した場合は、force オプションを使用して、失敗した検証を無視し、ジオレプリケーションセッションを作成できます。
    • セカンダリーボリュームはデフォルトで読み取り専用モードになっています。ただし、フェイルオーバーの状況が発生した場合は、セッションが元のセカンダリーから元のプライマリーに送信されるため、元のプライマリーはデフォルトで読み取り専用になります。
  3. プライマリーボリュームおよびセカンダリーボリュームに対して共有ストレージを有効にします。
    # gluster volume set all cluster.enable-shared-storage enable
    共有ストレージについての詳細は、「共有ストレージボリュームの設定」 を参照してください。
  4. geo レプリケーションのメタボリュームを設定します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config use_meta_volume true
    以下は例になります。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol config use_meta_volume true
    meta-volume の設定に関する詳細は、「メタボリュームの設定」 を参照してください。
  5. プライマリーノードで以下のコマンドを実行し、geo レプリケーションを起動します。
    以下に例を示します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start [force]
  6. 以下のコマンドを実行して、作成されたセッションのステータスを確認します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL status

10.3.4.2. セキュアな Geo レプリケーションセカンダリーの環境の設定

geo レプリケーションは、権限のないアカウント (ゼロ以外の UID を持つユーザーアカウント) を使用した SSH を介した Red Hat Gluster Storage セカンダリーへのアクセスをサポートします。この方法はより安全で、セカンダリーを介してプライマリーの機能を最小限に抑えます。この機能は、権限のないセカンダリーアカウントのマウントを管理する glusterd の内部サービス mountbroker に依存します。適切な mountbroker's アクセス制御ディレクティブで glusterd を設定するには、追加の手順を実行する必要があります。このプロセスの例を以下に示します。
すべての Slave ノードで以下の手順を実行し、権限のないアカウントの補助 glusterFS マウントを設定します
  1. すべてのセカンダリーノードで、新しいグループを作成します。例: geogroup
    注記
    mountbroker 設定には、複数のグループを使用しないでください。複数のユーザーアカウントを作成できますが、グループは、root 以外のユーザーに対してすべて同じになる必要があります。
  2. すべてのセカンダリーノードで、権限のないアカウントを作成します。例: geoaccountgeoaccount geogroup グループのメンバーとして追加します。
  3. Slave ノードのいずれかで以下のコマンドを実行し、mountbroker ルートディレクトリーおよびグループを設定します。
    # gluster-mountbroker setup <MOUNT ROOT> <GROUP>
    以下に例を示します。
    # gluster-mountbroker setup /var/mountbroker-root geogroup
  4. Slave ノードのいずれかで以下のコマンドを実行し、ボリュームおよびユーザーを mountbroker サービスに追加します。
    # gluster-mountbroker add <VOLUME> <USER>
    以下に例を示します。
    # gluster-mountbroker add slavevol geoaccount
  5. 以下のコマンドを実行して、設定のステータスを確認します。
    # gluster-mountbroker status
    
         NODE    NODE STATUS                  MOUNT ROOT         GROUP              USERS
    --------------------------------------------------------------------------------------- localhost             UP   /var/mountbroker-root(OK)  geogroup(OK)  geoaccount(slavevol)
        node2             UP   /var/mountbroker-root(OK)  geogroup(OK)  geoaccount(slavevol)
    
    出力には、セカンダリークラスター内のすべてのピアノードの mountbroker のステータスが表示されます。
  6. すべての Slave ノードで Glusterd サービスを再起動します。
    # service glusterd restart
    すべての Slave ノードで権限のないアカウントの補助 glusterFS マウントを設定したら、以下の手順に従って root 以外の geo レプリケーションセッションを設定します。
  7. マスターノードのいずれかからスレーブノードの 1 つで ユーザーに 鍵ベースの認証を設定します。
    たとえば、ユーザー geoaccount にキーベースの SSH 認証を設定するには、次のコマンドを実行します。
    # ssh-keygen
    # ssh-copy-id -i identity_file geoaccount@slave_node_IPaddress/Hostname
  8. マスターノードで以下のコマンドを実行して、一般的な pem pub ファイルを作成します。ここでは、鍵ベースの SSH 認証接続はスレーブノードの ユーザー に設定されます。
    # gluster system:: execute gsec_create
  9. マスターノードで 以下のコマンドを実行して、マスターとスレーブ間のジオレプリケーション関係をユーザーへ実行します。
    以下に例を示します。
    # gluster volume geo-replication MASTERVOL geoaccount@SLAVENODE::slavevol create push-pem
    複数のセカンダリーボリュームやアカウントが複数ある場合には、その特定のユーザーやボリュームを使用して地理的なレプリケーションセッションを作成します。
    以下に例を示します。
    # gluster volume geo-replication MASTERVOL geoaccount2@SLAVENODE::slavevol2 create push-pem
  10. プライマリーボリュームおよびセカンダリーボリュームに対して共有ストレージを有効にします。
    # gluster volume set all cluster.enable-shared-storage enable
    共有ストレージについての詳細は、「共有ストレージボリュームの設定」 を参照してください。
  11. 関係の作成に使用されるスレーブノードで、ユーザー名、マスターボリューム名、スレーブボリューム名を引数として root として /usr/libexec/glusterfs/set_geo_rep_pem_keys.sh を実行します。
    以下に例を示します。
    # /usr/libexec/glusterfs/set_geo_rep_pem_keys.sh geoaccount MASTERVOL SLAVEVOL_NAME
  12. geo レプリケーションのメタボリュームを設定します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config use_meta_volume true
    以下は例になります。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol config use_meta_volume true
    meta-volume の設定に関する詳細は、「メタボリュームの設定」 を参照してください。
  13. プライマリーノードで以下のコマンドを実行して、セカンダリーユーザーとして geo レプリケーションを起動します。
    以下に例を示します。
    # gluster volume geo-replication MASTERVOL geoaccount@SLAVENODE::slavevol start
  14. プライマリーノードで以下のコマンドを実行して、geo レプリケーションセッションのステータスを確認します。
    # gluster volume geo-replication MASTERVOL geoaccount@SLAVENODE::slavevol status

セッションの削除後の mountbroker geo レプリケーションオプションの削除

mountbroker geo レプリケーションセッションが削除された後、mountbrokerユーザーごとにボリュームを削除する必要があります。

重要
マウントブローカーからボリュームを削除する前に、まずジオレプリケーションセッションを停止して削除する必要があります。詳細は、「Geo レプリケーションセッションの停止」 および を参照してください。 「Geo レプリケーションセッションの削除」
mountbrokerユーザーごとのボリュームを削除するには:
# gluster-mountbroker remove [--volume volume] [--user user]
以下に例を示します。
# gluster-mountbroker remove --volume slavevol --user geoaccount
# gluster-mountbroker remove --user geoaccount
# gluster-mountbroker remove --volume slavevol
削除するボリュームが mountbroker ユーザーの最後のボリュームである場合、ユーザーも削除されます。
重要
セキュアな geo レプリケーション設定がある場合は、コマンドで、権限のないユーザーアカウントをセカンダリーボリュームにプレフィックスを付ける必要があります。たとえば、geo レプリケーションのステータスコマンドを実行するには、以下のコマンドを実行します。
# gluster volume geo-replication MASTERVOL geoaccount@SLAVENODE::slavevol status
このコマンドでは、geoaccount は、権限のないユーザーアカウントの名前です。

10.3.5. メタボリュームの設定

meta-volume gluster_shared_storage は、内部での使用に使用される gluster ボリュームです。use_meta_volumetrue に設定すると、ワーカーのフェイルオーバーを処理するのに役立つロックファイルを保管するために、geo レプリケーションを使用して共有ボリュームを使用できます。プライマリーボリュームでのノードの障害を効果的に処理するには、geo レプリケーションでこの共有ストレージをクラスターの全ノードで利用できるようにする必要があります。したがって、gluster _shared_storage という名前の Gluster ボリュームがクラスターに作成され、クラスター内のすべてのノードで /var/run/gluster/shared_storage にマウントするようにしてください。共有ストレージボリュームの設定についての詳細は、「共有ストレージボリュームの設定」 を参照してください。
注記
3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
  • geo レプリケーションのメタボリュームを設定します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config use_meta_volume true
    以下に例を示します。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol config use_meta_volume true
重要
RHEL 8 で、rsync_full_access onrsync_client on ブール値が geo レプリケーションで必要とされる rsync 中にファイル権限の問題を防ぐために、ON に設定されているようにします。

10.4. Geo レプリケーションの起動

本セクションでは、ストレージ環境でジオメトリーを作成し、それが正常に動作していることを確認します。

10.4.1. Geo レプリケーションセッションの開始

重要
geo レプリケーションを開始する前に、geo レプリケーションセッションを作成する必要があります。詳細は、「Geo レプリケーションセッションの環境の設定」 を参照してください。
geo レプリケーションを開始するには、以下のコマンドの 1 つを使用します。
  • ホスト間で geo レプリケーションセッションを開始するには、次のコマンドを実行します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start
    以下は例になります。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol start
    Starting geo-replication session between Volume1 & storage.backup.com::slave-vol has been successful
    このコマンドは、プライマリーボリュームの一部であるすべてのノードで、geo レプリケーションを開始します。プライマリーボリュームの一部であるノードがダウンしても、コマンドは正常に行われます。レプリカのペアでは、geo レプリケーションセッションはレプリカノードのいずれかでアクティブになりますが、他のレプリカノードでもパッシブになります。
    コマンドの実行後、セッションを初期化し、安定した状態になるまで数分の時間がかかる場合があります。
    注記
    geo レプリケーションセッションを作成し、セカンダリーにすでにデータがある場合には、以下のエラーメッセージが表示されます。
    slave-node::slave is not empty. Please delete existing files in slave-node::slave and retry, or use force to continue without deleting the existing files. geo-replication command failed
  • ホスト間で geo レプリケーションセッションを 強制的 に開始するには、次のコマンドを実行します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start force
    以下は例になります。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol start force
    Starting geo-replication session between Volume1 & storage.backup.com::slave-vol has been successful
    このコマンドは、プライマリーボリュームの一部であるノードで、geo レプリケーションセッションを強制的に開始します。オンラインの状態で、プライマリーボリュームの一部で geo レプリケーションセッションが正常に起動できない場合、コマンドは可能な限り多くのノードで geo レプリケーションセッションを開始します。このコマンドは、セッションが破棄されているノードでジオメトリーセッションを再開始する際にも使用したり、開始していないノードでも使用することもできます。

10.4.2. 成功した Geo レプリケーション デプロイメントの確認

status コマンドを使用して、環境内の Geo-replication のステータスを確認できます。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL status
以下は例になります。
# gluster volume geo-replication Volume1 storage.backup.com::slave-vol status

10.4.3. Geo レプリケーションステータス情報の表示

status コマンドを使用すると、特定のジオレプリケーションセッション、master-slave セッション、またはすべてのジオレプリケーションセッションに関する情報を表示できます。ステータスの出力は、ノードとブリックレベルの情報の両方を提供します。
  • geo レプリケーションセッションに関する情報をすべて表示するには、以下のコマンドを使用します。
    # gluster volume geo-replication status [detail]
  • 特定のプライマリーボリュームから geo レプリケーションセッションに関する情報を表示するには、以下のコマンドを使用します。
    # gluster volume geo-replication MASTER_VOL 状態 [detail]
  • 特定の master-slave セッションの情報を表示するには、以下のコマンドを使用します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL ステータス [detail]
    重要
    データが完全に同期されている場合、df コマンドの出力(- h および -kを含む)と、マスターおよびスレーブボリュームの inode が一致しなくなります。これは、変更ログ ジャーナリングデータによる追加の inode およびサイズの消費が原因で発生します。これにより、マスターボリューム のファイルシステムで加えられた変更を追跡します。df コマンドを実行して同期のステータスを確認する代わりに、代わりに # gluster volume geo-replication MASTER_VOLSLAVE_ HOST ::SLAVE_VOL ステータスの詳細を使用します
  • geo-replication status コマンドの出力は、以下の情報を提供します。
    • マスターノード: Gluster ボリューム情報コマンドの出力に記載されているように、マスターノードと ホスト名
    • Master Vol: プライマリーボリューム名
    • Master Brick: ブリックのパス
    • Slave User: セカンダリーユーザー名
    • Slave: セカンダリーボリューム名
    • Slave Node: プライマリーワーカーが接続されているセカンダリーノードのIP アドレス/ホスト名。
    • Status: geo レプリケーションワーカーのステータスは以下のいずれかになります。
      • Initializing: これは Geo レプリケーションセッションの最初のフェーズで、異常が存在しないことを確認するため、1 分間この状態のままになります。
      • Created: geo レプリケーションセッションが作成されますが、開始されません。
      • Active: このノードの gsync デーモンはアクティブで、データを同期しています。
      • Passive: アクティブノードのレプリカペア。データの同期は、アクティブなノードで処理されます。したがって、このノードはデータと同期しません。
      • Faulty: geo レプリケーションセッションに問題が発生したため、さらに調査する必要があります。詳細は、「Geo レプリケーションのトラブルシューティング」 セクションを参照してください。
      • Stopped: geo レプリケーションセッションは停止しましたが、削除されていません。
    • Crawl Status: Crawl のステータスは以下のいずれかになります。
      • Changelog Crawl: changelog トランスレーターが変更ログを生成します。また、これは、データを同期するために gsyncd デーモンによって消費されています。
      • Hybrid Crawl: gsyncd デーモンは glusterFS ファイルシステムをマウントし、データを同期するために擬似変更ログを生成しています。
      • History Crawl: gsyncd デーモンはデータを同期するために changelogs トランスレーターが生成した履歴変更ログを使用します。
    • Last Synced: 最後の同期時間。
    • Entry: セッションごとの保留中のエントリー数 (CREATE、MKDIR、RENAME、UN7-4 など)。
    • Data: セッションごとに保留中の Data 操作の数。
    • Meta: セッションごとに保留中の Meta 操作の数。
    • Failures: 失敗の数。障害数がゼロを超える場合は、プライマリーブリックにエラーがないかログファイルを表示します。
    • Checkpoint Time: チェックポイントの日時を表示します (設定されている場合)。それ以外の場合は、N/A として表示されます。
    • Checkpoint Completed: チェックポイントのステータスを表示します。
    • Checkpoint Completion Time: Checkpoint が完了した場合の完了時間を表示します。それ以外の場合は、N/A として表示されます。

10.4.4. Geo レプリケーションセッションの設定

geo レプリケーションセッションを設定するには、次のコマンドを使用します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config [Name] [Value]
以下は例になります。
# gluster volume geo-replication Volume1 storage.backup.com::slave-vol config sync_method rsync
たとえば、すべてのオプションと値のペアの一覧を表示するには、次のコマンドを実行します。
# gluster volume geo-replication Volume1 storage.backup.com::slave-vol config
Geo-replication 設定オプションの設定を削除するには、オプションの前に ! (感嘆符)を付けます。たとえば、log-level をデフォルト値にリセットするには、次のコマンドを実行します。
# gluster volume geo-replication Volume1 storage.backup.com::slave-vol config '!log-level'
警告
クラスターのすべてのピアが Connected (online) 状態にある場合は、この設定変更を実行する必要があります。ピアがダウンした時に設定を変更すると、geo レプリケーションクラスターはノードがオンラインに戻ると一貫性のない状態になります。

設定可能な引数

以下の表は、geo レプリケーション設定の設定可能なオプションの概要を示しています。

オプション 説明
gluster_log_file LOGFILE geo レプリケーション glusterfs ログファイルへのパス。
gluster_log_level LOGFILELEVEL glusterfs プロセスのログレベル。
log_file LOGFILE geo レプリケーションログファイルへのパス。
log_level LOGFILELEVEL geo レプリケーションのログレベル。
changelog_log_level LOGFILELEVEL changelog のログレベル。デフォルトのログレベルは INFO に設定されます。
changelog_batch_size SIZEINBYTES バッチの changelog の合計サイズ。デフォルトのサイズは 727040 バイトです。
ssh_command COMMAND リモートマシンに接続するための SSH コマンド (デフォルトは SSH)。
sync_method NAME ファイルの同期方法の設定に使用するコマンド。利用可能なオプションは rsync または tarssh です。デフォルトは rsync です。tarssh では、セキュアシェルプロトコル上の tar を許可します。tarssh オプションを使用して、編集されていないファイルのワークロードを処理します。
注記
RHEL 8.3 以降では、sync_method を_tarssh_ として設定する前に、_tar_ パッケージをインストールするようにしてください。
# yum install tar
volume_id=UID 中間/セカンダリーノードの既存のプライマリー UID を削除するコマンド。
SECONDS のタイムアウト タイムアウト時間 (秒単位)。
sync_jobs N
sync-jobs の数は、各ワーカー内の同期スレッドの最大数 (同期のために ssh プロセス上の rsync プロセスまたは tar) を表します。ワーカーの数は、常にプライマリーボリューム内のブリックの数と等しくなります。たとえば、sync-jobs が 3 に設定された分散複製 (3 x 2) のボリュームは、全ノード/サーバーで合計 9 つの同期ジョブ (スレッド) になります。
Active および Passive Workers: アクティブなワーカーの数は、ボリューム設定に基づいています。分散ボリュームの場合、すべてのブリック (ワーカー) がアクティブになり、同期に参加します。ボリュームを複製または分散する場合、各複製/通知グループ (サブボリューム) の 1 つのワーカーがアクティブになり、同期に参加します。これにより、他のブリックからの競合を避けることができます。各複製/検出グループ (サブボリューム) の残りのワーカーはパッシブになります。アクティブなワーカーがダウンすると、同じ複製/検出されたグループからのパッシブワーカーの 1 つがアクティブなワーカーになります。
ignore_deletes このオプションを true に設定すると、マスターで削除されたファイルはスレーブで削除操作をトリガーしません。その結果、セカンダリーはプライマリーのスーパーセットとして保持され、クラッシュや誤って削除された場合にプライマリーを復元するために使用できます。このオプションが falseignore-deletes のデフォルト設定オプション)に設定すると、マスターで削除されたファイルはスレーブで削除操作をトリガーします。
checkpoint [LABEL|now] 指定のオプション LABEL でチェックポイントを設定します。このオプションが now に設定されていると、現在の時刻がラベルとして使用されます。
sync_acls [true | false]Acl を Slave クラスターと同期します。デフォルトでは、このオプションが有効になっています。
注記
geo レプリケーションは、rsync と同期エンジンとしてのみ同期でき、tarssh では同期エンジンとしては使用できません。
sync_xattrs [true | false]拡張属性を Slave クラスターと同期します。デフォルトでは、このオプションが有効になっています。
注記
geo レプリケーションは、拡張属性を同期エンジンとして rsync にのみ同期でき、tarssh に同期エンジンとしては使用できません。
log_rsync_performance [true | false]このオプションが enable に設定されている場合、geo レプリケーションはログファイルで rsync のパフォーマンスの記録を開始します。デフォルトでは、このオプションは無効となっています。
rsync_optionsrsync の追加オプション。たとえば、rsync 帯域幅の使用量 "--bwlimit=<value>" を制限することができます。
use_meta_volume [true | false]Geo レプリケーションでメタボリュームを使用するには、このオプション を有効にします。デフォルトでは、このオプションは無効となっています。
注記
meta-volume の詳細は、「メタボリュームの設定」 を参照してください。
meta_volume_mnt PATHメタボリュームマウントポイントのパス。
gfid_conflict_resolution [true | false] 自動 GFID 競合解決機能により、プライマリーとセカンダリー間で GFID の競合を自動的に検出および修正できます。この設定オプションを使用すると、この機能を有効または無効にすることができます。デフォルトでは、このオプションは true です。
special_sync_mode
セカンダリーからのデータの復旧をスピードアップします。geo レプリケーションに機能を追加して、インデックスオプションを有効にする前に作成したファイルを無視します。
フェイルオーバーまたはフェイルバックメカニズムの調整パラメーター:
なし: gsyncd は通常どおりに動作します。
blind: gsyncd は xtime ペアと連携して、同期候補を特定します。
wrapup: 通常モードと同じですが、xtimes を孤立したファイルに割り当てません。
recover: ファイルは、スレーブで変更された場合にのみ転送されます。
注記
セカンダリー内のファイル数がプライマリーと同じであることを確認した後には、このモードを使用します。geo レプリケーションは、セカンダリーボリュームをプライマリーボリュームとして作成した後に作成されたファイルのみを同期します。

10.4.4.1. Geo-replication Checkpoints

10.4.4.1.1. Geo-replication Checkpoints について
Geo レプリケーションデータ同期は非同期プロセスであるため、プライマリーに加えられた変更はセカンダリーにレプリケートするのに時間がかかる場合があります。セカンダリーへのデータのレプリケーションは、このようなネットワーク障害などのさまざまな問題によって中断される可能性があります。
Red Hat Gluster Storage は、geo レプリケーションチェックポイントを設定する機能を提供します。チェックポイントを設定することで、その時点でプライマリー上にあるデータがセカンダリーに複製されているかどうかを同期情報が利用できます。
10.4.4.1.2. Geo-replication Checkpoint 情報の設定と表示
  • geo レプリケーションセッションでチェックポイントを設定するには、以下のコマンドを使用します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL 設定チェックポイント [now|LABEL]
    たとえば、Volume1storage.backup.com:/data/remote_dir 間のチェックポイントを設定するには、次のコマンドを実行します。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol config checkpoint now
    geo-replication config updated successfully
    チェックポイントのラベルは、now を指定して現在の時間として設定するか以下のように特定のラベルを指定できます。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol config checkpoint NEW_ACCOUNTS_CREATED
    geo-replication config updated successfully.
  • geo レプリケーションセッションのチェックポイントの状態を表示するには、以下のコマンドを使用します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL ステータスの詳細
  • geo レプリケーションセッションのチェックポイントを削除するには、以下のコマンドを使用します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config '!checkpoint'
    たとえば、Volume1storage.backup.com::slave-vol 間のチェックポイントセットを削除するには、次のコマンドを実行します。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol config '!checkpoint'
    geo-replication config updated successfully

10.4.5. Geo レプリケーションセッションの停止

root ユーザーのジオレプリケーションセッションを停止するには、次のいずれかのコマンドを使用します。
  • ホスト間の geo レプリケーションセッションを停止するには、次のコマンドを実行します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop
    以下は例になります。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol stop
    Stopping geo-replication session between Volume1 & storage.backup.com::slave-vol has been successful
    注記
    以下の場合は、stop コマンドは失敗します。
    • ボリュームの一部であるノードはオフラインです。
    • 特定のノードで geo レプリケーションセッションを停止できない場合。
    • プライマリーとセカンダリーの間の geo レプリケーションセッションがアクティブではない場合。
  • ホスト間での geo レプリケーションセッションを 強制的 に停止するには、次のコマンドを実行します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop force
    以下は例になります。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol stop force
    Stopping geo-replication session between Volume1 & storage.backup.com::slave-vol has been successful
    ボリュームの一部であるノードがオフラインであっても、force を使用すると、マスターとスレーブ間のジオレプリケーションセッションが停止します。特定のノードで geo レプリケーションセッションを停止できない場合、コマンドは可能な限り多くのノードで geo レプリケーションセッションを停止します。force を使用すると、非アクティブなジオレプリケーションセッションも停止します。
root ユーザーのジオレプリケーションセッションを停止するには、次のコマンドを使用します。
# gluster volume geo-replication MASTER_VOL geoaccount@SLAVE_HOST::SLAVE_VOL stop

10.4.6. Geo レプリケーションセッションの削除

重要
geo レプリケーションセッションを削除する前に、まず geo レプリケーションセッションを停止する必要があります。詳細は、「Geo レプリケーションセッションの停止」 を参照してください。
root ユーザーの geo レプリケーションセッションを削除するには、次のコマンドを使用します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL delete reset-sync-time
reset-sync-time: geo-replication delete コマンドは、最後に同期した時間に関する情報を保持します。このため、同じ geo レプリケーションセッションが再作成されると、セッションを削除する前に同期が残された時点から同期が続行されます。削除したセッションの詳細を維持しないジオレプリケーションセッションの場合は、delete コマンドで reset-sync-time オプションを使用します。現在では、セッションが再作成されると、新しいセッションと同様に、最初から同期が開始されます。
以下は例になります。
# gluster volume geo-replication Volume1 storage.backup.com::slave-vol delete
geo-replication command executed successfully
注記
以下の場合に delete コマンドは失敗します。
  • ボリュームの一部であるノードはオフラインです。
  • 特定のノードで geo レプリケーションセッションを削除できない場合。
  • プライマリーとセカンダリーの間の geo レプリケーションセッションがアクティブな場合でも、アクティブになります。
重要
SSH キーは、geo レプリケーションセッションが削除されると、プライマリーおよびセカンダリーノードから削除されません。/var/lib/glusterd/geo-replication/ ディレクトリーから SSH キーを含む pem ファイルを手動で削除できます。
root ユーザーの geo レプリケーションセッションを削除するには、次のコマンドを使用します。
# gluster volume geo-replication MASTER_VOL  geoaccount@SLAVE_HOST::SLAVE_VOL delete reset-sync-time

10.5. gdeploy を使用した Geo レプリケーションの設定

本セクションでは、gdeploy を使用してストレージ環境の geo レプリケーションセッションを設定して、制御し、検証する方法を説明します。gdeploy ツールは、geo レプリケーションに関連する以下のプロセスを自動化します。

10.5.1. gdeploy で root ユーザーとして geo レプリケーションを設定

root ユーザーとして geo レプリケーションセッションを設定するには、以下を行う必要があります。
  1. 一般的な pem pub ファイルの作成
  2. geo レプリケーションセッションの作成
  3. メタボリュームの設定
  4. geo レプリケーションセッションの開始
gdeploy は、設定ファイルを 1 つ作成し、これらのタスクの自動化に役立ちます。gdeploy をインストールすると、設定ファイルのサンプルが以下の場所に作成されます。
/usr/share/doc/gdeploy/examples/geo-replication.conf

手順10.1 gdeploy で root ユーザーとして geo レプリケーションを設定

重要
「前提条件」 に記載の前提条件が完了していることを確認します。
  1. 以下の場所に、サンプル gdeploy 設定ファイルのコピーを作成します。
    /usr/share/doc/gdeploy/examples/geo-replication.conf
  2. 以下のテンプレートを使用して、設定ファイルの geo レプリケーションセクションに必要な情報を追加します。
    [geo-replication]
    action=create
    mastervol=Master_IP:Master_Volname
    slavevol=Slave_IP:Slave_Volname
    slavenodes=Slave_IP_1,Slave_IP_2 [Add all slave IP addresses. Each address followed by a comma (,)]
    force=yes [yes or no]
    start=yes [yes or no]
  3. 設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
    # gdeploy -c txt.conf
以下は、root ユーザーとして geo レプリケーションを設定する設定ファイルの変更例です。
[geo-replication]
action=create
mastervol=10.1.1.29:mastervolume
slavevol=10.1.1.25:slavesvolume
slavenodes=10.1.1.28,10.1.1.86
force=yes
start=yes
その他の利用可能な値の詳細は、を参照してください。 「設定ファイル」

10.5.2. gdeploy を使用したセキュアな geo レプリケーションセッションの設定

セキュアな geo レプリケーションセッションを設定するには、以下を行う必要があります。
  1. すべてのセカンダリーノードに対して特権のないアカウントを持つ新規グループの作成
  2. mountbroker の設定
  3. 一般的な pem pub ファイルの作成
  4. geo レプリケーションセッションの作成
  5. メタボリュームの設定
  6. geo レプリケーションセッションの開始
gdeploy は、設定ファイルを 1 つ作成し、これらのタスクの自動化に役立ちます。gdeploy をインストールすると、設定ファイルのサンプルが以下の場所に作成されます。
/usr/share/doc/gdeploy/examples/georep-secure.conf

手順10.2 gdeploy を使用したセキュアな geo レプリケーションセッションの設定

重要
「前提条件」 に記載の前提条件が完了していることを確認します。
  1. 以下の場所に、サンプル gdeploy 設定ファイルのコピーを作成します。
    /usr/share/doc/gdeploy/examples/georep-secure.conf
  2. 以下のテンプレートを使用して、設定ファイルの geo レプリケーションセクションに必要な情報を追加します。
    [geo-replication]
    action=create
    georepuser=User_Name [If the user is not present, gdeploy creates the geo-replication user.]
    mastervol=Master_IP:Master_Volname
    slavevol=Slave_IP:Slave_Volname
    slavenodes=Slave_IP_1,Slave_IP_2 [Add all slave IP addresses. Each address followed by a comma (,)]
    force=yes [yes or no]
    start=yes [yes or no]
  3. 設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
    # gdeploy -c txt.conf
以下は、安全な geo レプリケーションセッションを設定する設定ファイルの変更例です。
[geo-replication]
action=create
georepuser=testgeorep
mastervol=10.1.1.29:mastervolume
slavevol=10.1.1.25:slavesvolume
slavenodes=10.1.1.28,10.1.1.86
force=yes
start=yes
その他の利用可能な値の詳細は、を参照してください。 「設定ファイル」

10.5.3. gdeploy を使用した地理レプリケーションセッションの制御

gdeploy バージョン 2.0.2-35 は、Red Hat Gluster Storage 3.5 での地理レプリケーションセッションの制御をサポートします。gdeploy を使用すると、geo レプリケーションセッションを制御するために以下のアクションを実行できます。
gdeploy がインストールされている場合、設定ファイルのサンプルは /usr/share/doc/gdeploy/examples に作成されます。各アクションの設定ファイルのサンプルは、以下のとおりです。

表10.1 Geo レプリケーション設定ファイル名の gdeploy

Geo レプリケーションセッション制御 設定ファイル名
セッションの開始georep-start.conf
セッションの停止georep-stop.conf
セッションの一時停止georep-pause.conf
セッションの再開georep-resume.conf
セッションの削除georep-delete.conf

手順10.3 gdeploy を使用した地理レプリケーションセッションの制御

警告
geo レプリケーションセッションを作成してから制御する必要があります。詳細は、以下のいずれかを参照してください。
重要
「前提条件」 に記載の前提条件が完了していることを確認します。
  1. 以下の場所に、必要な gdeploy サンプル設定ファイルのコピーを作成します。
    /usr/share/doc/gdeploy/examples
  2. 以下のテンプレートを使用して、設定ファイルの geo レプリケーションセクションに必要な情報を追加します。
    [geo-replication]
    action=Action_Name
    georepuser=User_Name If georepuser variable is omitted, the user is assumed to be root user.
    mastervol=Master_IP:Master_Volname
    slavevol=Slave_IP:Slave_Volname
    slavenodes=Slave_IP_1,Slave_IP_2 [Add all slave IP addresses. Each address followed by a comma (,)]
    force=yes [yes or no]
    start=yes [yes or no]
    重要
    georepuser 変数を省略すると、ユーザーは root ユーザーであることが想定されます。
  3. 設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
    # gdeploy -c txt.conf
以下は、geo レプリケーションセッションを制御するための設定ファイルの変更例です。

geo レプリケーションセッションの開始

[geo-replication]
action=start
mastervol=10.1.1.29:mastervolume
slavevol=10.1.1.25:slavevolume

geo レプリケーションセッションの停止

[geo-replication]
action=stop
mastervol=10.1.1.29:mastervolume
slavevol=10.1.1.25:slavevolume
force=yes

geo レプリケーションセッションの一時停止

[geo-replication]
action=pause
mastervol=10.1.1.29:mastervolume
slavevol=10.1.1.25:slavevolume
force=yes

geo レプリケーションセッションの再開

[geo-replication]
action=resume
mastervol=10.1.1.29:mastervolume
slavevol=10.1.1.25:slavevolume
force=yes

geo レプリケーションセッションの削除

[geo-replication]
action=delete
mastervol=10.1.1.29:mastervolume
slavevol=10.1.1.25:slavevolume
force=yes
使用できる値の詳細は、を参照してください。 「設定ファイル」

10.6. 新規に追加されたブリック、ノード、またはボリュームでの Geo レプリケーションの起動

10.6.1. 新規ブリックまたは新規ノードの Geo レプリケーションの起動

geo レプリケーションセッションが実行され、新しいノードが信頼できるストレージプールに追加されるか、または信頼されているストレージプールの新たに追加されたノードからボリュームにブリックが追加された場合には、以下の手順を実行して新規ノードで geo レプリケーションデーモンを起動する必要があります。
  1. common pem pub ファイルを作成するには、キーベースの SSH 認証接続が設定されているマスターノードで以下のコマンドを実行します。
    # gluster system:: execute gsec_create
  2. 以下のコマンドを使用して geo レプリケーションセッションを作成します。スレーブノードで required pem- file 設定を実行するには、push -pem および force オプションが必要です。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL create push-pem force
    以下は例になります。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol create push-pem force
    注記
    このコマンドを実行するノードと、上記コマンドで指定されたセカンダリーホストの間に、キーベースの SSH 認証アクセスが必要です。このコマンドは、有効なセカンダリー URL の確認、有効なセカンダリーボリューム、およびセカンダリーで利用可能な領域の確認など、セカンダリーの検証を実行します。
  3. 共有ストレージボリュームの設定後に、新しいノードがクラスターに追加されると、共有ストレージはこのノードに自動的にマウントされません。このノードの共有ストレージ用に /etc/fstab エントリーは追加されません。このノードで共有ストレージを使用するには、以下のコマンドを実行します。
    # mount -t glusterfs <local node's ip>:gluster_shared_storage
    /var/run/gluster/shared_storage
    # cp /etc/fstab /var/run/gluster/fstab.tmp
    # echo "<local node's ip>:/gluster_shared_storage
    /var/run/gluster/shared_storage/ glusterfs defaults 0 0" >> /etc/fstab
    注記
    3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
    共有ストレージボリュームの設定についての詳細は、「共有ストレージボリュームの設定」 を参照してください。
  4. geo レプリケーションのメタボリュームを設定します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config use_meta_volume true
    以下は例になります。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol config use_meta_volume true
    meta-volume の設定に関する詳細は、「メタボリュームの設定」 を参照してください。
  5. ノードがセカンダリーに追加される場合は、以下のコマンドを使用して geo レプリケーションセッションを停止します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop
  6. 以下のコマンドを使用して、セカンダリーとプライマリー間の geo レプリケーションセッションを開始します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start force
  7. 以下のコマンドを使用して、作成したセッションのステータスを確認します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL status

10.6.2. 既存ノードでの新規ブログの Geo レプリケーションの開始

geo レプリケーションセッションを実行している信頼されたストレージプールの既存ノードのボリュームにブリックを追加すると、その特定ノードの geo レプリケーションデーモンは自動的に再起動されます。その後、新しいブリックは geo レプリケーションデーモンにより認識されます。これは自動化プロセスであり、設定変更は必要ありません。

10.6.3. 新規ボリュームの Geo レプリケーションの起動

プライマリークラスターに追加された新規ボリュームとセカンダリークラスターに追加された新規ボリュームとの間で geo レプリケーションセッションを作成して開始するには、以下の手順を実行する必要があります。

前提条件

  • プライマリーボリュームノードとセカンダリーボリュームノード間でパスワードアクセスがなくても、キーベースの SSH 認証が必要です。
  1. 以下のコマンドを使用して geo レプリケーションセッションを作成します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL create
    以下に例を示します。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol create
    注記
    このコマンドは、有効なセカンダリー URL の確認、有効なセカンダリーボリューム、およびセカンダリーで利用可能な領域の確認など、セカンダリーの検証を実行します。
  2. geo レプリケーションのメタボリュームを設定します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config use_meta_volume true
    以下は例になります。
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol config use_meta_volume true
    meta-volume の設定に関する詳細は、「メタボリュームの設定」 を参照してください。
  3. 以下のコマンドを使用して、セカンダリーとプライマリー間の geo レプリケーションセッションを開始します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start
  4. 以下のコマンドを使用して、作成したセッションのステータスを確認します。
    # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL status

10.7. Cron ジョブとしての Geo レプリケーションのスケジューリング

Cron は、時間、月、曜日の組み合わせ、タスクの繰り返し実行をスケジュールするために使用できるデーモンです。cron は、システムが継続的に ON であることを前提とします。タスクがスケジュールされているときにシステムが ON でない場合には、実行されません。必要時または低い I/O で実行される geo レプリケーションをスケジュールするためのスクリプトが提供されます。
Cron のインストールと Cron ジョブの設定の詳細は、『『Red Hat Enterprise Linux 7 システム管理者ガイド』』の「システムタスクの自動化」を参照してください。
geo レプリケーションセッションをスケジュールするための提供されるスクリプトは、以下を実行します。
  1. geo レプリケーションセッション (開始されている場合) を停止します。
  2. geo レプリケーションセッションを開始します。
  3. チェックマークを設定します。
  4. 完了するまでチェックポイントのステータスを確認します。
  5. チェックポイントが完了したら、geo レプリケーションセッションを停止します。

geo レプリケーションセッションの実行

必要に応じて geo レプリケーションセッションを実行するには、以下のスクリプトを実行します。

# python /usr/share/glusterfs/scripts/schedule_georep.py MASTERVOL SLAVEHOST SLAVEVOL
以下に例を示します。
# python /usr/share/glusterfs/scripts/schedule_georep.py Volume1 storage.backup.com slave-vol
以下のコマンドを実行してヘルプを表示します。
# python /usr/share/glusterfs/scripts/schedule_georep.py --help

cron ジョブのスケジュール設定

Cron を使用して自動的に実行するように geo レプリケーションをスケジュールするには、以下を実行します。

minute hour day month day-of-week directory_and_script-to-execute MASTERVOL SLAVEHOST SLAVEVOL >> log_file_for_script_output
たとえば、毎日 20:30 時間に地理レプリケーションを実行するには、以下のコマンドを実行します。
30 20 * * * root python /usr/share/glusterfs/scripts/schedule_georep.py --no-color Volume1 storage.backup.com slave-vol >> /var/log/glusterfs/schedule_georep.log 2>&1

10.8. 障害復旧

Red Hat Gluster Storage は、障害復旧のための geo レプリケーションおよびフェイルバック機能を提供します。プライマリーがオフラインの場合、セカンダリーがプライマリーを置き換えできるように failover の手順を実行できます。この場合、読み取りおよび書き込みを含むすべての I/O 操作は、現在プライマリーとして機能するセカンダリーで行われます。元のプライマリーがオンラインに戻ると、元のセカンダリーで failback 手順を実行し、元のプライマリーとの違いを同期できます。

10.8.1. フェイルオーバー: セカンダリーのプライマリーへのプロモート

プライマリーボリュームがオフラインの場合、セカンダリーボリュームをプライマリーにプロモートし、データアクセスのためにそのボリュームの使用を開始できます。
  1. 以下のコマンドを実行して、セカンダリーボリュームで読み取り専用を無効にします。
    # gluster volume set VOLNAME features.read-only off
  2. セカンダリーマシンで以下のコマンドを実行し、これをプライマリーにプロモートします。
    # gluster volume set VOLNAME geo-replication.indexing on
    # gluster volume set VOLNAME changelog on
    たとえば、以下のようになります。
    # gluster volume set slave-vol geo-replication.indexing on
     volume set: success
    # gluster volume set slave-vol changelog on
     volume set: success
I/O 操作にセカンダリーボリュームを使用するようにアプリケーションを設定できるようになりました。

10.8.2. フェイルバック: Master と Slave を元の状態に戻す

元のプライマリーがオンラインに戻ると、元のセカンダリーで以下の手順を実行し、元のプライマリーとの違いを同期できます。
  1. 以下のコマンドを使用して、既存の geo-rep セッションを元のプライマリーから組織セカンダリーに停止します。
    # gluster volume geo-replication  ORIGINAL_MASTER_VOL ORIGINAL_SLAVE_HOST::ORIGINAL_SLAVE_VOL 強制的に停止
    以下に例を示します。
    # gluster volume geo-replication  Volume1 storage.backup.com::slave-vol stop force
    Stopping geo-replication session between Volume1 and storage.backup.com::slave-vol has been successful
  2. 新しいマスターとして、元のスレーブで新しいジオレプリケーションセッションを作成し、元のマスターを新しいスレーブとして force オプションを指定して作成します。geo レプリケーションセッションの作成に関する詳細は、以下を参照してください。
  3. 特別な同期モードを開始し、セカンダリーからのデータ復旧を迅速化します。このオプションは、indexing オプションを有効にする前に作成したファイルを無視する geo レプリケーションに機能を追加します。このオプションを使用すると、geo レプリケーションは、Slave ボリュームをプライマリーボリュームとして作成した後に作成されたファイルのみを同期します。
    # gluster volume geo-replication ORIGINAL_SLAVE_VOL ORIGINAL_MASTER_HOST::ORIGINAL_MASTER_VOL config special-sync-mode recover
    以下に例を示します。
    # gluster volume geo-replication  slave-vol master.com::Volume1 config special-sync-mode recover
    geo-replication config updated successfully
    
  4. gfid-conflict-resolution オプションを無効にします。
    # gluster volume geo-replication ORIGINAL_SLAVE_VOL ORIGINAL_MASTER_HOST::ORIGINAL_MASTER_VOL config gfid-conflict-resolution false
    以下に例を示します。
    # gluster volume geo-replication slave-vol master.com::Volume1 config gfid-conflict-resolution false
    geo-replication config updated successfully
    
  5. 以下のコマンドを使用して、新しい geo レプリケーションセッションを開始します。
    # gluster volume geo-replication ORIGINAL_SLAVE_VOL ORIGINAL_MASTER_HOST::ORIGINAL_MASTER_VOL start
    以下に例を示します。
    # gluster volume geo-replication slave-vol master.com::Volume1 start
    Starting geo-replication session between slave-vol and master.com::Volume1 has been successful
    
  6. 元のセカンダリーで I/O 操作を停止し、チェックポイントを設定します。チェックポイントを設定することで、その時点でプライマリー上にあるデータがセカンダリーに複製されているかどうかを同期情報が利用できます。
    # gluster volume geo-replication ORIGINAL_SLAVE_VOL ORIGINAL_MASTER_HOST::ORIGINAL_MASTER_VOL config checkpoint now
    以下に例を示します。
    # gluster volume geo-replication slave-vol master.com::Volume1 config checkpoint now
    geo-replication config updated successfully
    
  7. チェックポイントの完了により、元のセカンダリーからのデータが元のプライマリーに復元されます。しかし、チェックポイントを設定する前に、セカンダリーで IO を停止したため、チェックポイントを完了するためにセカンダリーマウントを変更する必要があります。
    # touch orginial_slave_mount 
    # gluster volume geo-replication ORIGINAL_SLAVE_VOL ORIGINAL_MASTER_HOST::ORIGINAL_MASTER_VOL status detail
    以下に例を示します。
    # touch /mnt/gluster/slavevol
    # gluster volume geo-replication slave-vol master.com::Volume1 status detail
    
  8. チェックポイントが完了したら、元のセカンダリーと元のプライマリーとの間で現在の ge レプリケーションセッションを停止して削除します。
    # gluster volume geo-replication ORIGINAL_SLAVE_VOL ORIGINAL_MASTER_HOST::ORIGINAL_MASTER_VOL stop
    # gluster volume geo-replication ORIGINAL_SLAVE_VOL ORIGINAL_MASTER_HOST::ORIGINAL_MASTER_VOL delete
    以下に例を示します。
    # gluster volume geo-replication slave-vol master.com::Volume1 stop
    Stopping geo-replication session between slave-vol and master.com::Volume1 has been successful
    
    # gluster volume geo-replication slave-vol master.com::Volume1 delete
    geo-replication command executed successfully
    
  9. 以下のコマンドを実行して、プライマリーボリュームで読み取り専用を無効にします。
    # gluster volume set VOLNAME features.read-only off
  10. 以下のコマンドを実行して、セカンダリーボリュームをプライマリーボリュームとしてプロモートするように設定したオプションをリセットします。
    # gluster volume reset ORIGINAL_SLAVE_VOL geo-replication.indexing force
    # gluster volume reset ORIGINAL_SLAVE_VOL changelog
    以下に例を示します。
    # gluster volume reset slave-vol geo-replication.indexing force
    volume set: success
    
    # gluster volume reset slave-vol changelog
    volume set: success
    
  11. 以下のコマンドを使用して、元のプライマリーから geo-rep セッションを開始し、元のロールを再開します。
    # gluster volume geo-replication ORIGINAL_MASTER_VOL ORIGINAL_SLAVE_HOST::ORIGINAL_SLAVE_VOL start 
    # gluster volume geo-replication Volume1 storage.backup.com::slave-vol start
    Starting geo-replication session between slave-vol  and master.com::Volume1 been successful
    

10.9. Geo レプリケートボリュームのスナップショットの作成

Red Hat Gluster Storage スナップショット機能により、データの保護に使用できる Red Hat Gluster Storage ボリュームのポイントインタイムコピーを作成できます。Geo レプリケートのスナップショットを作成できます。
ジオレプリケーションのボリュームのスナップショットの作成、作成、復元の詳細は、8章スナップショットの管理 を参照してください。geo レプリケーションセッションがライブで作成されず、このシナリオでスナップショットの作成はサポートされないため、以下のエラーが表示されます。
# gluster snapshot create snap1 master
snapshot create: failed: geo-replication session is running for the volume master. Session needs to be stopped before taking a snapshot.
Snapshot command failed
.
スナップショットを作成する前に、geo レプリケーションセッションを一時停止して、スナップショットの作成後に geo レプリケーションセッションを再開する必要があります。地理的に複製されたボリュームの復元に関する情報は、「『スナップショットの管理』」を参照してください。

10.10. 例: カスケード geo レプリケーションの設定

本セクションでは、geo レプリケーションセッションを設定する手順を説明します。この例の設定には 3 つのボリュームがあり、ボリューム名は master-vol、monthmaster-vol、および slave-vol です。
  1. 環境が 「前提条件」 に記載の最小システム要件と一致していることを確認します。
  2. 適切なデプロイメントシナリオを決定します。デプロイメントシナリオの詳細は、「Geo レプリケーションデプロイメントシナリオの展開」 を参照してください。
  3. 環境を設定し、master-vol と monthlymaster-vol との間でジオプリケーションセッションを作成します。
    1. 一般的な pem pub ファイルを作成し、キーベースの SSH 認証接続が設定されているプライマリーノードで以下のコマンドを実行します。
      # gluster system:: execute gsec_create
    2. 以下のコマンドを使用して geo レプリケーションセッションを作成します。push-pem オプションは、minutemaster ノードで必要な pem-file 設定を実行するために必要です。
      # gluster volume geo-replication master-vol interimhost.com::interimmaster-vol create
      push-pem
    3. 以下のコマンドを実行して、作成されたセッションのステータスを確認します。
      # gluster volume geo-replication master-vol interimhost::interimmaster-vol status
  4. geo レプリケーションのメタボリュームを設定します。
    # gluster volume geo-replication master-vol interimhost.com::interimmaster-vol config use_meta_volume true