管理ガイド
Red Hat Gluster Storage の設定および管理
概要
パート I. 前書き
第1章 前書き
1.1. Red Hat Gluster Storage について
1.2. glusterFS について
1.3. オンプレミスインストール
パート II. 概要
第2章 アーキテクチャーおよび概念
2.1. アーキテクチャー
図2.1 Red Hat Gluster Storage アーキテクチャー
2.2. オンプレミスアーキテクチャー
図2.2 Red Hat Gluster Storage for On-premises アーキテクチャー
2.3. ストレージの概念
- ブリック
- ストレージの 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 つの段階で構成されます。
- ディレクトリーのレイアウトを修正し、追加または削除されたサブボリュームに対応します。また、ディレクトリーを修復し、レイアウトの一貫性の有り無しを確認して、必要に応じて拡張属性でレイアウトを永続化します。また、すべてのサブボリュームで同じ属性がディレクトリーに同じになることを確認することもできます。
- cached-subvolume から hashed-subvolume にデータを移行します。
パート III. 設定および検証
第3章 Red Hat Gluster Storage に関する考慮事項
3.1. ファイアウォールおよびポートアクセス
3.1.1. ファイアウォールの設定
# iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 5667 -j ACCEPT # service iptables save
# 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 サービスと競合しないように注意してください。 | 111 | 111 | すべての設定 | RPC ポートマッパーおよび RPC バインド |
認証された SMB/CIFS クライアント | 139 および 445 | 137 および 138 | SMB/CIFS を使用したストレージの共有 | SMB/CIFS プロトコル |
認証された NFS クライアント | 2049 | 2049 | Gluster NFS または NFS-Ganesha を使用したストレージの共有 | NFS プロトコルを使用したエクスポート |
Samba-CTDB クラスターのすべてのサーバー | 4379 | - | SMB および Gluster NFS を使用したストレージの共有 | CTDB |
認証されたネットワークエンティティー | 24007 | - | すべての設定 | glusterd を使用した管理プロセス |
認証されたネットワークエンティティー | 55555 | - | すべての設定 |
Gluster イベントデーモン
以前のバージョンの Red Hat Gluster Storage から最新のバージョン 3.5.4 にアップグレードする場合、glusterevents デーモンに使用されるポートは、柔軟性のある範囲にあるように修正する必要があります。
|
NFSv3 クライアント | 662 | 662 | NFS-Ganesha および Gluster NFS を使用したストレージの共有 | statd |
NFSv3 クライアント | 32803 | 32803 | NFS-Ganesha および Gluster NFS を使用したストレージの共有 | NLM プロトコル |
マウント要求を送信する NFSv3 クライアント | - | 32769 | Gluster NFS を使用したストレージの共有 | Gluster NFS MOUNT プロトコル |
マウント要求を送信する NFSv3 クライアント | 20048 | 20048 | NFS-Ganesha を使用したストレージの共有 | NFS-Ganesha MOUNT プロトコル |
NFS クライアント | 875 | 875 | NFS-Ganesha を使用したストレージの共有 | NFS-Ganesha RQUOTA プロトコル(クォータ情報の取得) |
pacemaker/corosync クラスターのサーバー | 2224 | - | NFS-Ganesha を使用したストレージの共有 | pcsd |
pacemaker/corosync クラスターのサーバー | 3121 | - | NFS-Ganesha を使用したストレージの共有 | pacemaker_remote |
pacemaker/corosync クラスターのサーバー | - | 5404 および 5405 | NFS-Ganesha を使用したストレージの共有 | corosync |
pacemaker/corosync クラスターのサーバー | 21064 | - | NFS-Ganesha を使用したストレージの共有 | dlm |
認証されたネットワークエンティティー | 49152 - 49664 | - | すべての設定 | ブリック通信ポート必要なポートの合計数は、ノード上のブリックの数によって異なります。マシンのブリックごとに 1 つのポートが必要です。 |
Gluster クライアント | 1023 または 49152 | - | システムポートがすでにマシンで使用されている場合にのみ適用されます。 | ブリックとクライアントプロセス間の通信。 |
表3.2 NFS-Ganesha および Gluster NFS ストレージクライアントで以下のポートを開く
接続ソース | TCP ポート | UDP ポート | 推奨 | 用途 |
---|---|---|---|---|
NFSv3 サーバー | 662 | 662 | NFS-Ganesha および Gluster NFS を使用したストレージの共有 | statd |
NFSv3 サーバー | 32803 | 32803 | NFS-Ganesha および Gluster NFS を使用したストレージの共有 | NLM プロトコル |
3.2. 機能互換性サポート
表3.3 Red Hat Gluster Storage バージョンでサポートされる機能
機能 | バージョン |
---|---|
Arbiter ブリック | 3.2 |
Bitrot 検出 | 3.1 |
Erasure コーディング | 3.1 |
Google Compute Engine | 3.1.3 |
メタデータのキャッシュ | 3.2 |
Microsoft Azure | 3.1.3 |
NFS バージョン 4 | 3.1 |
SELinux | 3.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 ボリュームタイプ別にサポートされる機能
表3.5 クライアントプロトコルでサポートされる機能
機能 | FUSE | gluster-NFS | NFS-Ganesha | SMB |
---|---|---|---|---|
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 にアップグレードする新規デプロイメントおよび既存デプロイメントでサポートしません。
| はい | いいえ | いいえ | いいえ |
スナップショット | はい | はい | はい | はい |
スナップショットのクローン作成 | はい | はい | はい | はい |
階層化 (Tiering)(非推奨)
警告
階層化は、Red Hat Gluster Storage 3.5 では非推奨です。Red Hat ではこの使用を推奨しておらず、Red Hat Gluster Storage 3.5.3 にアップグレードする新規デプロイメントおよび既存デプロイメントでは階層化をサポートしません。
| はい | はい | 該当なし | 該当なし |
第4章 信頼できるストレージプールへのサーバーの追加
# firewall-cmd --get-active-zones
# firewall-cmd --zone=zone_name --add-service=glusterfs # firewall-cmd --zone=zone_name --add-service=glusterfs --permanent
4.1. 信頼できるストレージプールへのサーバーの追加
信頼できるストレージプールへの 3 台のサーバーの追加
前提条件
glusterd
サービスは、信頼できるストレージプールの追加を必要とするすべてのストレージサーバーで実行する必要があります。サービスの起動および停止の手順については、22章glusterd サービスの起動と停止 を参照してください。- 信頼されるストレージサーバーである
Server1
が起動します。 - ターゲットサーバーのホスト名は DNS で解決できる必要があります。
- サーバー 1 から gluster peer probe [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
- 以下のコマンドを使用して、すべてのサーバーからピアのステータスを確認します。
# 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)
# for peer in `gluster peer status | grep Hostname | awk -F':' '{print $2}' | awk '{print $1}'`; do clockdiff $peer; done
4.2. 信頼できるストレージプールからのサーバーの削除
信頼できるストレージプールからの 1 台のサーバーの削除
前提条件
- ストレージプールから削除される場合は、
glusterd
サービスがサーバーで実行している必要があります。サービスの起動および停止の手順については、22章glusterd サービスの起動と停止 を参照してください。 - ターゲットサーバーのホスト名は DNS で解決できる必要があります。
- gluster peer detach [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
- 以下のコマンドを使用して、すべてのサーバーからピアのステータスを確認します。
# 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章 ストレージボリュームの設定
ボリュームタイプ
- Distributed (分散)
- ファイルをボリューム内のブリックに分散します。スケーリングと冗長性の要件が重要ではないか、他のハードウェアやソフトウェア層により提供されるこのボリュームタイプを使用します。このボリュームタイプの補足情報は、「分散ボリュームの作成」 を参照してください。
- Replicated (レプリケート)
- ボリューム内のブリック間でファイルを複製します。高い可用性と信頼性が重要である環境では、このボリュームタイプを使用します。このボリュームタイプの補足情報は、「複製ボリュームの作成」 を参照してください。
- Distributed Replicated
- ファイルをボリューム内の複製されたブリックに分散します。高い信頼性と柔軟性が重要である環境では、このボリュームタイプを使用します。このボリュームタイプは、多くの環境で読み取りパフォーマンスが向上します。このボリュームタイプの補足情報は、「分散複製ボリュームの作成」 を参照してください。
- Arbitrated Replicated
- レプリカセットの 2 つのブリックでファイルを複製し、メタデータのみを 3 番目のブリックに複製します。一貫性が重要な環境でこのボリュームタイプを使用しますが、ベースとなるストレージ領域は非常に貴重です。このボリュームタイプの補足情報は、「Arbitrated Replicated ボリュームの作成」 を参照してください。
- Dispersed
- ボリュームのブリック全体でファイルのデータを分散します。無駄にする領域を最小元に抑える、信頼性の設定可能なレベルが必要なこのボリュームタイプを使用します。このボリュームタイプの補足情報は、「分散ボリュームの作成」 を参照してください。
- Distributed Dispersed
- 分散するサブボリューム全体でファイルのデータを分散します。無駄にする領域を最小元に抑える、信頼性の設定可能なレベルが必要なこのボリュームタイプを使用します。このボリュームタイプの補足情報は、「Distributed Dispersed ボリュームの作成」 を参照してください。
5.1. gdeploy を使用した Gluster Storage ボリュームの設定
- 複数のマシンへのバックエンドの設定は、ラップトップ/デスクトップから実行できます。これにより、信頼されているストレージプール内のノード数が増えると、時間が短縮され、スケールアップできるようになります。
- 設定するドライブを選択する柔軟性 (sd、vd、...)
- 論理ボリューム (LV) およびボリュームグループ (VG) の命名に柔軟性がある。
5.1.1. 使い始める
前提条件
- 以下のコマンドを実行して、信頼できるストレージプールの一部であるノードのパスフレーズなしの SSH 鍵を生成します。
# ssh-keygen -t rsa -N ''
- 以下のコマンドを実行して、gdeploy コントローラーとサーバー間のキーベースの SSH 認証アクセスを設定します。
# ssh-copy-id -i root@server
注記Red Hat Gluster Storage ノードを外部ノードではなくデプロイメントノードとして使用する場合は、インストールが実行される Red Hat Gluster Storage ノードにキーベースの SSH 認証を設定する必要があります。 - 以下のコマンドを実行して、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
- 以下のコマンドを実行して、
ansible
をインストールします。# yum install ansible
- 以下のことを確認する必要があります。
- デバイスは raw で未使用である必要があります
- デフォルトのシステムロケールは
en_US
に設定する必要がありますシステムロケールの詳細は、『Red Hat Enterprise Linux 7 システム管理者のガイド』の『システムロケールの設定』を参照してください。 - 複数のデバイスの場合は、
gdeploy
設定ファイルで複数のボリュームグループ、シンプール、および thinvol を使用します。
- 信頼できるストレージプールでのノードの使用
- 信頼できるストレージプールの外部にあるマシンの使用
クラスターでのノードの使用
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』を参照してください。
# yum install gdeploy
gdeploy
のインストールに関する詳細は、『Red Hat Gluster Storage 3.5 Installation Guide』の『Installing Ansible to Support Gdeploy』セクションを参照してください。
5.1.2. 信頼できるストレージプールの設定
/usr/share/doc/gdeploy/examples/gluster.conf.sample
# # 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
sample_volname
とし、指定の IP アドレスとバックエンドデバイスを、/dev/sdb
、/dev/sdc
、/dev/sdd
として、持つ 3 x 3 レプリカの信頼ストレージプールが作成されます。
# gdeploy -c txt.conf
/usr/share/doc/gdeploy/examples/gluster.conf.sample
で利用可能なテンプレートファイルを参照して、新しい設定ファイルを作成することができます。新規設定ファイルを呼び出すには、gdeploy -c /path_to_file/config.txt コマンドを実行します。
だけ
を設定する場合は、「バックエンドの設定 」 を参照してください。
のみ
を作成するには、「ボリュームの作成」 を参照してください。
のみ
をマウントする場合は、「クライアントのマウント」 を参照してください。
5.1.3. バックエンドの設定
/usr/share/doc/gdeploy/examples/gluster.conf.sample
- [backend-setup] モジュールの使用
- 物理ボリューム (PV)、ボリュームグループ (VG)、および論理ボリューム (LV) の個別作成
xfsprogs
パッケージをインストールする必要があります。
5.1.3.1. [backend-setup] モジュールの使用
- 汎用
- 特定
汎用
ディスク名がマシン全体で統一されている場合は、以下のようにバックエンドの設定を作成することができます。'hosts' セクション内のすべてのホストに対して、バックエンドが設定されます。
# # 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 つの設定ファイルでホスト固有の設定を非常に柔軟に実行することができます。
# # 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 のセットアップによるバックエンドの作成
[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
# # 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. ボリュームの作成
/usr/share/doc/gdeploy/examples/gluster.conf.sample
[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
複数のボリュームの作成
[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
[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
5.1.5. クライアントのマウント
/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] 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. 設定ファイル
- [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 がデフォルト設定として取得されます。このフィールドに有効な値は、
raid10
、raid6
、raid5
、jbod
です。以下に例を示します。[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 ユーザーであることが想定されます。
- mastervol: プライマリーボリュームの詳細の形式は以下のとおりです。
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 のデプロイ
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
# gdeploy -c txt.conf
必要なパッケージをインストールします。
必要なパッケージをインストールするには、設定ファイルに以下の情報を追加します。
[yum] action=install repolist= gpgcheck=no update=no packages=glusterfs-ganesha
# gdeploy -c txt.conf
5.1.8.2. サポートされるアクション
- クラスターの作成
- クラスターの破棄
- ノードの追加
- ノードの削除
- ボリュームのエクスポート
- ボリュームのエクスポート解除
- NFS Ganesha 設定の更新
クラスターの作成
このアクションにより、指定のボリューム上に最新の NFS-Ganesha の設定が作成されます。このアクションでは、設定ファイルの nfs-ganesha が以下の変数に対応します。
- ha-name: これは任意の変数です。デフォルトでは ganesha-ha-360 です。
- cluster-nodes: これは必須の引数です。この変数は、クラスターを構成するために使用されるクラスターノード名のコンマ区切り値を想定します。
- vip: これは必須引数です。この変数は、IP アドレスのコンマ区切りリストが必要です。これらは仮想 IP アドレスになります。
- volname: これは、設定で [volume] セクションが含まれている場合に任意の変数です。
[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
# gdeploy -c txt.conf
クラスターの破棄
このアクションの destroy-cluster クラスターは、NFS Ganesha を無効にします。これにより、1 つの変数 cluster-nodes
が許可されます。
[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 つの変数が許可されます。
nodes
: クラスターに追加する必要のあるコンマ区切りのホスト名の一覧を受け入れます。vip
: コンマ区切りの 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
# 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
ボリュームのエクスポート解除:
この操作により、ボリュームを unexport します。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 設定の更新
このアクションにより、config ブロックが設定ファイルに追加/削除され、クラスターで refresh-config
を実行します。
refresh-config
は以下の変数をサポートします。
- del-config-lines
- block-name
- volname
- ha-conf-dir
- update_config_lines
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
[hosts] host1-example.com host2-example.com [nfs-ganesha] action=refresh-config del-config-lines=client volname=ganesha
# gdeploy -c txt.conf
[hosts] host1-example.com host2-example.com [nfs-ganesha] action=refresh-config volname=ganesha
# gdeploy -c txt.conf
[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 のデプロイ
5.1.9.1. 前提条件
Subscription Manager のサブスクライブ
サブスクリプションマネージャーにサブスクライブし、Samba パッケージを取得してから詳細に進む必要があります。
[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-samba-for-rhel-7-server-rpms,rhel-7-server-ansible-2-rpms
[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 の有効化
- ボリューム作成時の Samba の有効化
既存のボリュームでの Samba の有効化
Red Hat Gluster Storage ボリュームがすでに存在する場合は、ユーザーはそのアクションを volume セクションで smb-setup
として指定する必要があります。gdeploy は各ホストの glusterd 設定ファイルを更新するため、クラスター内のすべてのホストについて言及する必要があります。
[hosts] 10.70.37.192 10.70.37.88 [volume] action=smb-setup volname=samba1 force=yes smb_username=smbuser smb_mountpoint=/mnt/smb
# gdeploy -c txt.conf
ボリューム作成時の Samba の有効化
ボリュームの作成時に Samba を設定している場合は、設定ファイルで smb
変数を yes に設定する必要があります。
[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
smb_username
と smb_mountpoint
が必要です。
5.1.9.3. 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 の有効化
5.1.10.1. ボリュームの作成および 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
# gdeploy -c txt.conf
5.1.10.2. 既存のボリュームで 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 ログファイル
/var/log
ディレクトリーではなく /home/username/.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. 暗号化したディスクについて
- 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. ブリックのフォーマットとマウント
5.3.1. ブリックの手動作成
- Red Hat は、ブリックに XFS ファイルシステムを使用した論理ボリュームのフォーマットをサポートします。
- Red Hat は、分散ボリューム(純粋分散、分散レプリカまたは分散/デペーパー)の異種サブボリュームサイズをサポートします。Red Hat では、同じサブボリュームのブリックについて異種ブリックサイズをサポートしません。たとえば、3 つの 10GiB のブリックが同じ複製に属し、3 つの 50 GiB と 100 GiB ブリックが同じ複製セットに属する限り、3 つの 10GiB ブリック、3 つの 50 GiB および 3 つの 100 GiB のブリックで、Distributed-Replicated 3x3 ボリュームを使用できます。このようにして、1 つのサブボリューム 10GiB、もう 1 つは 50GiB と 100GiB になります。分散ハッシュテーブルは、割り当てられた各サブボリュームに数のバランスを取り、サブボリュームがそのサイズに比例して一杯になるようにします。
5.3.1.1. シンプロビジョニングされた論理ボリュームの作成
- pvcreate コマンドを使用して、物理ボリューム(PV)を作成します。
# pvcreate --dataalignment alignment_value device
以下に例を示します。# pvcreate --dataalignment 1280K /dev/sdb
ここでは、/dev/sdb
がストレージデバイスです。デバイスに基づいて正しいdataalignment
オプションを使用します。詳細は、「ブリック設定」 を参照してください。注記デバイス名と調整値は、使用中のデバイスによって異なります。 - vgcreate コマンドを使用して、PV からボリュームグループ(VG)を作成します。
# vgcreate --physicalextentsize alignment_value volgroup device
以下に例を示します。# vgcreate --physicalextentsize 1280K rhs_vg /dev/sdb
- 以下のコマンドを使用して、シンプールを作成します。
# 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
--virtualsize
オプションおよび--thin
オプションを指定して、lvcreate コマンドを実行して、以前に作成したプールを使用するシンプロビジョニングされたボリュームを作成します。# lvcreate --virtualsize size --thin volgroup/poolname --name volname
以下に例を示します。# lvcreate --virtualsize 1G --thin rhs_vg/rhs_pool --name rhs_lv
シンプールには 1 つの LV のみを作成することが推奨されます。- 対応している XFS 設定を使用してブリックをフォーマットし、ブリックをマウントして、ブリックが正しくマウントされていることを確認します。Red Hat Gluster Storage のパフォーマンスを強化するには、ブリックをフォーマットする前に 19章パフォーマンスチューニング を読んでください。重要外部ログファイルでフォーマットされたブリックでは、スナップショットはサポートされません。mkfs.xfs コマンドで Red Hat Gluster Storage ブリックをフォーマットする場合は、
-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 で使用される拡張属性に対応します。 - # mkdir /mountpoint を実行して、ブリックをリンクするためのディレクトリーを作成します。
# mkdir /rhgs
/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
- mount /mountpoint を実行して、ブリックをマウントします。
- df -h コマンドを実行して、ブリックが正常にマウントされていることを確認します。
# df -h /dev/rhs_vg/rhs_lv 16G 1.2G 15G 7% /rhgs
- SElinux が有効になっている場合は、以下のコマンドを使用して作成したブリック用に手動で SELinux ラベルを設定する必要があります。
# semanage fcontext -a -t glusterd_brick_t /rhgs/brick1 # restorecon -Rv /rhgs/brick1
5.3.2. ボリュームのブログとしてサブディレクトリーを使用
/rhgs
ディレクトリーはマウントされたファイルシステムで、ボリュームを作成するブリックとして使用されます。ただし、場合によっては、マウントポイントが利用できない場合、/rhgs
ディレクトリーで書き込みは継続されますが、これは root ファイルシステム下にあります。
/bricks
としてマウントされます。ファイルシステムが利用できる状態になったら、/rhgs/brick1
という名前のディレクトリーを作成し、ボリュームの作成に使用します。1 つのマウントから複数のブリックが作成されていないことを確認します。このアプローチには、以下の利点があります。
/rhgs
ファイルシステムが利用できないと、システム内で利用可能な/rhgs/brick1
ディレクトリーがなくなりました。したがって、別の場所に書き込むことでデータ損失は発生しません。- これには、ネスト化に追加のファイルシステムは必要ありません。
- マウントされたファイルシステムに
brick1
サブディレクトリーを作成します。# mkdir /rhgs/brick1
すべてのノードで上記の手順を繰り返します。 - サブディレクトリーをブリックとして使用し、Red Hat Gluster Storage ボリュームを作成します。
# gluster volume create distdata01 ad-rhs-srv1:/rhgs/brick1 ad-rhs-srv2:/rhgs/brick2
- Red Hat Gluster Storage ボリュームを起動します。
# gluster volume start distdata01
- ボリュームのステータスを確認します。
# 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
# gluster volume create test-volume server1:/rhgs1/brick1 server2:/rhgs1/brick1 server1:/rhgs2/brick2 server2:/rhgs2/brick2
5.3.3. 削除されたボリュームからのブリックの再使用
5.3.4. 使用できないブリックのクリーニング
- ブリックの以前の既存データをすべて削除します(
.glusterfs
サブディレクトリーを含む)。 - # setfattr -x trusted.glusterfs.volume-id brick および # setfattr -x trusted.gfid brick を実行して、ブリックのルートから属性を削除します。
- # getfattr -d -m を実行してください。ボリュームに設定された属性を検証する brick。属性を書き留めておきます。
- # setfattr -x attribute brick を実行して、glusterFS ファイルシステムに関連する属性を削除します。分散ボリュームの
trusted.glusterfs.dht
属性は、削除する必要のある属性の例の 1 つです。
5.4. 分散ボリュームの作成
図5.1 分散ボリュームの図
- インサービスのアップグレードなし: アップグレード時に分散されるボリュームのみオフラインでなければなりません。
- 時折発生するディレクトリーエントリーと inode の一時的な不整合。
- I/O 操作は、ノードが利用不可または結果として生じるノードの障害によりブロックまたは失敗します。
- データの永久損失。
分散ボリュームの作成
前提条件
- 「信頼できるストレージプールへのサーバーの追加」 の説明に従って、信頼できるストレージプールが作成されている。
- 「ボリュームの起動」 の説明に従って、ボリュームを起動および停止する方法を理解している。
- 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
- # gluster volume start VOLNAME を実行してボリュームを起動します。
# gluster v start glustervol volume start: glustervol: success
- gluster volume info コマンドを実行して、必要に応じてボリューム情報を表示します。以下の出力は 例5.1「2 つのストレージサーバーを使用した分散ボリューム」 の結果です。
# 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. 複製ボリュームの作成
前提条件
- 「信頼できるストレージプールへのサーバーの追加」 の説明に従って、信頼できるストレージプールが作成されている。
- 「ボリュームの起動」 の説明に従って、ボリュームを起動および停止する方法を理解している。
5.5.1. 3 方向の複製ボリュームの作成
図5.2 3 方向の複製ボリュームの図
- 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
- # gluster volume start VOLNAME を実行してボリュームを起動します。
# gluster v start glustervol volume start: glustervol: success
- gluster volume info コマンドを実行して、必要に応じてボリューム情報を表示します。
5.5.2. ハードな複製ボリュームの作成
.shard
ディレクトリーに書き込まれ、GFID とパーツの順序を示す番号が付けられます。たとえば、ファイルが 4 つの部分に分割される場合、最初のパーツは GFID という名前で、通常どおり保存されます。他の 3 つの要素はそれぞれ GFID.1、GFID.2、および GFID.3 という名前です。これらは .shard
ディレクトリーに置かれ、ボリューム内のさまざまなブリック間で均等に分散されます。
5.5.2.1. サポート対象のユースケース
例5.4 例: 3 方向の複製されたシャードボリューム
- 『Red Hat Gluster Storage 管理ガイド』https://access.redhat.com/documentation/ja-JP/red_hat_gluster_storage/3.5/html/Administration_Guide/sect-Creating_Replicated_Volumes.html#Creating_Three-way_Replicated_Volumesで説明されているように、3 方向の複製ボリュームを設定します。
- ボリュームを起動する前に、ボリュームでシャード化を有効にします。
# gluster volume set test-volume features.shard enable
- ボリュームを起動し、これが想定通りに機能していることを確認します。
# 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. シャード化されたファイルのパーツの検索
# getfattr -d -m. -e hex path_to_file
# ls /rhgs/*/.shard -lh | grep GFID
5.6. 分散複製ボリュームの作成
前提条件
- 「信頼できるストレージプールへのサーバーの追加」 の説明に従って、信頼できるストレージプールが作成されている。
- 「ボリュームの起動」 の説明に従って、ボリュームを起動および停止する方法を理解している。
5.6.1. 3 方向の分散複製ボリュームの作成
図5.3 3 方向の分散複製ボリューム (3 方向の分散レプリケート) の図
- 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
- # gluster volume start VOLNAME を実行してボリュームを起動します。
# gluster v start glustervol volume start: glustervol: success
- gluster volume info コマンドを実行して、必要に応じてボリューム情報を表示します。
5.7. Arbitrated Replicated ボリュームの作成
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 ブリックをホストするノードのシステム要件
表5.1 物理マシンでの任意設定の要件
設定タイプ | 最小 CPU | 最小 RAM | NIC | Arbiter ブリックサイズ | 最大レイテンシー |
---|---|---|---|---|---|
専用 arbiter | 64 ビットクアッドコアプロセッサー (ソケット 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 を参照してください。
[e]
これは、aribiter ノードに関係なくすべてのノード間の最大ラウンドトリップレイテンシー要件です。ノード間のレイテンシーを確認するには、KCS#413623 を参照してください。
|
- 最低 4 vCPU
- 最低 16 GB RAM
- 1 TB から 4 TB の仮想ディスク
- 最大 5 ミリ秒レイテンシー
5.7.1.2. Arbiter 容量の要件
minimum arbiter brick size = 4 KB * ( size in KB of largest data brick in volume or replica set / average file size in KB)
minimum arbiter brick size = 4 KB * ( 1 TB / 2 GB ) = 4 KB * ( 1000000000 KB / 2000000 KB ) = 4 KB * 500 KB = 2000 KB = 2 MB
minimum arbiter brick size = 4 KB * ( size in KB of largest data brick in volume or replica set / shard block size in KB )
5.7.2. 判別ロジック
表5.2 現在のボリュームの状態に許可される操作
ボリュームの状態 | 判別動作 |
---|---|
すべてのブリックが利用可能です | すべてのファイル操作は許可されました。 |
arbiter および 1 データブリックが利用可能 |
arbiter が利用可能なデータノードに同意しない場合は、ENOTCONN で書き込み操作は失敗します (正しいブリックは利用できません)。他のファイル操作が許可されます。
arbiter のメタデータが利用可能なデータノードと合意している場合、すべてのファイル操作が許可されます。
|
Arbiter ダウン、データブリックが利用可能です | ファイル操作がすべて許可されます。Arbiter の記録が利用可能になると修復されます。 |
利用可能なのは 1 つのブリックだけです。 |
すべてのファイル操作は ENOTCONN で失敗します。
|
5.7.3. Arbitrated Replicated ボリュームの作成
# gluster volume create VOLNAME replica 3 arbiter 1 HOST1:DATA_BRICK1 HOST2:DATA_BRICK2 HOST3:ARBITER_BRICK3
# 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 ボリュームの作成
- 複数の Arbitrated Replicated ボリュームをチェーンします。これは、別のボリュームのデータブリックと同じノードの 1 つのボリュームに対して arbiter ブリックを配置して行います。チェーンは、メタデータのファイルサイズ (32 - 128 KiB から) に近くなる場合に書き込み負荷に便利です。これにより、1 つのディスクを経由するすべてのメタデータ I/O が回避されます。判別分散複製ボリュームでは、arbiter ブックを、別のレプリカサブボリュームのデータブリックと同じノードに配置することもできます。これらは同じデータを共有しないためです。
- 1 つの専用ノードで、複数のボリュームから arbiter ブリックを配置します。専用の arbiter ノードは、大きなファイルを使用した書き込みの高ワークロードおよび読み取りの高ワークロードに適しています。
例5.6 専用設定の例
# 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
例5.7 チェーン設定の例
# 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
5.7.5. 判別ボリュームへの変換
手順5.1 レプリカ 2 ボリュームの判別ボリュームへの変換
修復中ではないことを確認します。
# gluster volume heal VOLNAME info
保留中の修復エントリーが0
になるまで待ってから続行します。自己修復の無効化と停止
以下のコマンドを実行して、データ、メタデータ、エントリー自己修復デーモン、および自己修復デーモンを無効にします。# 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
ボリュームへの 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
クライアントの volfiles が更新するまで待ちます。
これには約 5 分かかります。ブリックが正常に追加されたことを確認します。
# gluster volume info VOLNAME # gluster volume status VOLNAME
自己修復を再度有効化
以下のコマンドを実行して、サーバーで自己修復を再度有効にします。# 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
すべてのエントリーが修復されていることを確認
# gluster volume heal VOLNAME info
保留中の秀句エントリーが0
になるまで待機して、すべての修復が正常に実行されるようにします。
手順5.2 レプリカ 3 ボリュームの判別ボリュームへの変換
修復中ではないことを確認します。
# gluster volume heal VOLNAME info
保留中の修復エントリーが0
になるまで待ってから続行します。ボリュームのレプリカ数を 2 に減らす
レプリカ数が 2 に削減されるように、ボリュームのすべてのサブボリュームからブリックを削除します。たとえば、2 つのサブボリュームにデータを分散するレプリカ 3 ボリュームでは、以下のコマンドを実行します。# gluster volume remove-brick VOLNAME replica 2 HOST:subvol1-brick-path HOST:subvol2-brick-path force
注記分散複製ボリュームでは、データはサブボリューム全体に分散され、サブボリュームのブリック全体に複製されます。つまり、ボリュームのレプリカ数を減らすには、すべてのサブボリュームからブリックを削除する必要があります。ブリックは、gluster volume info 出力で サブボリュームでグループ化されます。レプリカ数が 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
自己修復の無効化と停止
以下のコマンドを実行して、データ、メタデータ、エントリー自己修復デーモン、および自己修復デーモンを無効にします。# 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
ボリュームへの 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
クライアントの volfiles が更新するまで待ちます。
これには約 5 分かかります。各クライアントで以下のコマンドを実行して、これが完了したことを確認します。# grep -ir connected mount-path/.meta/graphs/active/volname-client-*/private
出力でconnected=1
に表示される回数は、クライアントに接続されたブリックの数になります。ブリックが正常に追加されたことを確認します。
# gluster volume info VOLNAME # gluster volume status VOLNAME
自己修復を再度有効化
以下のコマンドを実行して、サーバーで自己修復を再度有効にします。# 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
すべてのエントリーが修復されていることを確認
# gluster volume heal VOLNAME info
保留中の秀句エントリーが0
になるまで待機して、すべての修復が正常に実行されるようにします。
5.7.6. 判別ボリュームを 3 方向の複製ボリュームに変換
手順5.3 レプリカ 3 ボリュームへの判別ボリュームの変換
修復中ではないことを確認します。
# gluster volume heal VOLNAME info
保留中の修復エントリーが0
になるまで待ってから続行します。ボリュームからの arbiter ブックの削除
どのブリックが(arbiter)
と一覧表示されているかを確認し、ボリュームからそのブリックを削除します。# gluster volume info VOLNAME
# gluster volume remove-brick VOLNAME replica 2 HOST:arbiter-brick-path force
自己修復の無効化と停止
以下のコマンドを実行して、データ、メタデータ、エントリー自己修復デーモン、および自己修復デーモンを無効にします。# 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
ボリュームへの完全なブリックの追加
複製した各サブボリュームにブリックを追加して、ボリュームを変換します。# 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
クライアントの volfiles が更新するまで待ちます。
これには約 5 分かかります。ブリックが正常に追加されたことを確認します。
# gluster volume info VOLNAME # gluster volume status VOLNAME
自己修復を再度有効化
以下のコマンドを実行して、サーバーで自己修復を再度有効にします。# 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
すべてのエントリーが修復されていることを確認
# gluster volume heal VOLNAME info
保留中の秀句エントリーが0
になるまで待機して、すべての修復が正常に実行されるようにします。
5.7.7. 判別ボリュームの推奨事項の調整
- 専用の判別ノードの場合は、arbiter ブリックに JBOD を、データブリックには RAID6 を使用します。
- チェーンの arbiter ボリュームの場合は、データおよび判別ブリックの両方に同じ RAID6 ドライブを使用します。
5.8. 分散ボリュームの作成
図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 ブリック
- 「信頼できるストレージプールへのサーバーの追加」 の説明に従って、信頼できるストレージプールを作成します。
- 「ボリュームの起動」 の説明に従って、ボリュームを起動および停止する方法を理解している。
- gluster volume create コマンドを実行して、分散ボリュームを作成します。構文は # gluster volume create NEW-VOLNAME [disperse-data COUNT] [redundancy COUNT] [transport tcp | rdma (Deprecated) | tcp,rdma] NEW-BRICK... です。ディスパースボリュームの作成に必要なブリック数は、
disperse-data count
とredundancy count
の合計です。disperse-data
count
オプションは、分散するブリック数を除く、分散ボリュームの一部であるブリック数を指定します。たとえば、ブリックの合計数が 6 で、redundancy-count
が 2 の場合、分散データ数は 4(6 - 2 = 4) になります。disperse-data count
オプションが指定されず、redundancy count
オプションのみを指定すると、指定したブリックの合計数を排除して、disperse-data count
が自動的に計算されます。冗長性により、ボリュームの操作を中断することなく、失われたブリックの数を決定します。redundancy 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
- # 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
ボリュームオプションの詳細は、「ボリュームオプションの設定」 を参照してください。 - gluster volume info コマンドを実行して、必要に応じてボリューム情報を表示します。
5.9. Distributed Dispersed ボリュームの作成
- 冗長性レベル 2 の 6 つのブリックを含む複数の分散セット
- 冗長性レベル 2 の 10 個のブリックを含む複数の分散セット
- 冗長性レベル 3 の 11 個のブリックを含む複数の分散セット
- 冗長性レベル 4 の 12 個のブリックを含む複数の分散セット
- 冗長性レベル 4 の 20 個ブリックを含む複数の分散セット
- 「信頼できるストレージプールへのサーバーの追加」 の説明に従って、信頼できるストレージプールが作成されている。
- 「ボリュームの起動」 の説明に従って、ボリュームを起動および停止する方法を理解している。
図5.5 Distributed Dispersed ボリュームの図
- 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 個のブリックを作成します。 - # 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
ボリュームオプションの詳細は、「ボリュームオプションの設定」 を参照してください。 - gluster volume info コマンドを実行して、必要に応じてボリューム情報を表示します。
5.10. ボリュームの起動
# gluster v start glustervol volume start: glustervol: success
第6章 ボリュームへのアクセスの作成
storage.fips-mode-rchecksum
ボリュームオプションを有効にしないでください。
- ネイティブクライアント(「ネイティブクライアント」を参照)
- ネットワークファイルシステム(NFS)v3(「NFS」を参照)
- サーバーメッセージブロック(SMB)(「SMB」を参照)
6.1. クライアントサポート情報
6.1.1. クロスプロトコルデータアクセス
表6.1 クロスプロトコルデータアクセスマトリックス
SMB | Gluster NFS | NFS-Ganesha | ネイティブ FUSE | オブジェクト | |
---|---|---|---|---|---|
SMB | はい | いいえ | いいえ | いいえ | いいえ |
Gluster NFS(非推奨) | いいえ | はい | いいえ | いいえ | いいえ |
NFS-Ganesha | いいえ | いいえ | はい | いいえ | いいえ |
ネイティブ FUSE | いいえ | いいえ | いいえ | はい | Yes [a] |
6.1.2. クライアントオペレーティングシステムのプロトコルサポート
表6.2 クライアント OS プロトコルのサポート
クライアント OS | FUSE | Gluster NFS | NFS-Ganesha | SMB |
---|---|---|---|---|
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. トランスポートプロトコルのサポート
表6.3 トランスポートプロトコルのサポート
アクセスプロトコル | TCP | RDMA(非推奨) |
---|---|---|
FUSE | はい | はい |
SMB | はい | いいえ |
NFS | はい | はい |
6.2. ネイティブクライアント
- ネイティブクライアントパッケージのインストール
- Red Hat Gluster Storage ボリュームのマウント (手動および自動)
- Gluster Storage ボリュームが正常にマウントされていることを確認します。
- Red Hat Gluster Storage サーバーは、サーバーバージョンとネイティブクライアントの以前のバージョンと同じネイティブクライアントのバージョンをサポートします。リリースの一覧は、https://access.redhat.com/solutions/543123 を参照してください。
- Red Hat Gluster Storage 3.5 バッチ更新 7 以降、
glusterfs-6.0-62
以降のバージョンの glusterFS ネイティブクライアントを使用するには、Red Hat Enterprise Enterprise Linux (RHEL 8) をベースとする Red Hat Gluster Storage ではrh-gluster-3-client-for-rhel-8-x86_64-rpms
、RHEL 7 をベースとする Red Hat Gluster Storage ではrh-gluster-3-client-for-rhel-7-server-rpms
を必ず経由する必要があります。
表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.7 | 3.1、3.1.1、3.1.2 | 3.1, 3.0, 2.1* |
6.8 | 3.1.3 | 3.1.3 |
6.9 | 3.2 | 3.2, 3.1.3* |
6.9 | 3.3 | 3.3, 3.2 |
6.9 | 3.3.1 | 3.3.1, 3.3, 3.2 |
6.10 | 3.4 | 3.5*、3.4、3.3.z |
7.1 | 3.1、3.1.1 | 3.1.1, 3.1, 3.0 |
7.2 | 3.1.2 | 3.1.2, 3.1, 3.0 |
7.2 | 3.1.3 | 3.1.3 |
7.3 | 3.2 | 3.2, 3.1.3 |
7.4 | 3.2 | 3.2, 3.1.3 |
7.4 | 3.3 | 3.3, 3.2 |
7.4 | 3.3.1 | 3.3.1, 3.3, 3.2 |
7.5 | 3.3.1、3.4 | 3.3.z, 3.4.z |
7.6 | 3.3.1、3.4 | 3.3.z, 3.4.z |
7.7 | 3.5.1 | 3.4.z, 3.5.z |
7.8 | 3.5.2 | 3.4.z, 3.5.z |
7.9 | 3.5.3, 3.5.4, 3.5.5, 3.5.6, 3.5.7 | 3.4.z, 3.5.z |
8.1 | NA | 3.5 |
8.2 | 3.5.2 | 3.5.z |
8.3 | 3.5.3 | 3.5.z |
8.4 | 3.5.4 | 3.5.z |
8.5 | 3.5.5, 3.5.6 | 3.5.z |
8.6 | 3.5.7 | 3.5.z |
- Red Hat Gluster Storage 3.5 の場合、Red Hat は Red Hat Gluster Storage 3.4 および 3.5 クライアントのみをサポートします。
6.2.1. ネイティブクライアントのインストール
- コマンドラインを使用した、システムの Red Hat Subscription Management への登録およびサブスクライブ
- Web Interface を使用した、システムの Red Hat Subscription Management への登録およびサブスクライブ
コマンドラインを使用した、システムの Red Hat Subscription Management への登録およびサブスクライブ
前提条件
- Red Hat Gluster Storage エンタイトルメントのある Red Hat Subscription Manager アカウントのユーザー名およびパスワードを把握します。
- subscription-manager register コマンドを実行して、利用可能なプールを一覧表示します。適切なプールを選択し、Red Hat Subscription Manager のユーザー名とパスワードを入力して、システムを Red Hat Subscription Manager に登録します。
# subscription-manager register
- クライアントに応じて、以下のコマンドのいずれかを実行して正しいリポジトリーにサブスクライブします。
- 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を参照してください。 - システムが、必要なリポジトリーにサブスクライブされていることを確認します。
# yum repolist
Web Interface を使用した、システムの Red Hat Subscription Management への登録およびサブスクライブ
前提条件
- Red Hat Gluster Storage エンタイトルメントのある Red Hat Subsrciption Management (RHSM) アカウントのユーザー名およびパスワードを把握します。
- Red Hat Subscription Management (https://access.redhat.com/management) にログオンします。
- 画面上部の Systems リンクをクリックします。
- Red Hat Gluster Storage Native Client チャンネルを追加する必要のあるシステムの名前をクリックします。
- 画面の Subscribed Channels セクションで Alter Channel Subscriptions をクリックします。
- クライアントプラットフォームに応じて、
Red Hat Enterprise Linux 7 for x86_64
またはx86_64
またはRed Hat Enterprise Linux 5 for x86_64
のノードを展開します。 - Change Subscriptions ボタンをクリックし、変更を確定します。ページの更新時に Details タブを選択して、システムが適切なチャンネルにサブスクライブされていることを確認します。
ネイティブクライアントパッケージのインストール
前提条件
- yum install コマンドを実行して、ネイティブクライアントの RPM パッケージをインストールします。
# yum install glusterfs glusterfs-fuse
- Red Hat Enterprise 5.x クライアントシステムの場合は、modprobe コマンドを実行して、Red Hat Gluster Storage ボリュームをマウントする前に FUSE モジュールをロードします。
# modprobe fuse
起動時にモジュールの読み込みの詳細は、https://access.redhat.com/knowledge/solutions/47028 を参照してください。
6.2.2. ネイティブクライアントのアップグレード
gluster ボリュームをアンマウントします。
ネイティブクライアントをアップグレードする前に、gluster ボリュームをアンマウントします。# umount /mnt/glusterfs
クライアントをアップグレードします。
yum update コマンドを実行して、ネイティブクライアントをアップグレードします。# yum update glusterfs glusterfs-fuse
gluster ボリュームを再マウントします。
「Red Hat Gluster Storage ボリュームのマウント」 の説明に従って、ボリュームの再マウントを行います。
6.2.3. Red Hat Gluster Storage ボリュームのマウント
- クライアントは、サーバーと同じバージョンで、少なくともサーバーのバージョンが 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 -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 以上です。0
がlru-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
- ボリュームにマウントポイントが作成されていない場合は、mkdir コマンドを実行してマウントポイントを作成します。
# mkdir /mnt/glusterfs
- タスクサマリーの鍵をガイドとして使用し、mount -t glusterfs コマンドを実行します。
- Red Hat Gluster Storage ボリュームの場合:
# mount -t glusterfs server1:/test-volume /mnt/glusterfs
- Red Hat Gluster Storage ボリュームのサブディレクトリーの場合
# mount -t glusterfs server1:/test-volume/sub-dir /mnt/glusterfs
6.2.3.3. ボリュームの自動マウント
- テキストエディターで
/etc/fstab
ファイルを開きます。 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 を使用したサブディレクトリーの手動マウント
- また、名前空間分離も提供します。そのため、複数のユーザーが他のユーザーと名前空間の競合のリスクを生じさせることなくストレージにアクセスできます。
- マウントに障害が発生した場合に、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 ボリュームのテスト
前提条件
- mount コマンドを実行して、ボリュームが正常にマウントされたかどうかを確認します。
# mount server1:/test-volume on /mnt/glusterfs type fuse.glusterfs(rw,allow_other,default_permissions,max_read=131072
または、# 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
または、# mount server1:/test-volume/sub-dir.tcp on /mnt/glusterfs type fuse.glusterfs(rw,allow_other,default_permissions,max_read=131072
- df コマンドを実行して、ボリュームのすべてのブリックから集約されたストレージ領域を表示します。
# df -h /mnt/glusterfs Filesystem Size Used Avail Use% Mounted on server1:/test-volume 28T 22T 5.4T 82% /mnt/glusterfs
- cd コマンドを使用してマウントディレクトリーに移動し、コンテンツを一覧表示します。
# cd /mnt/glusterfs # ls
6.3. NFS
6.3.1. サポートマトリックス
表6.5 NFS サポートマトリックス
機能 | glusterFS NFS (NFSv3) | NFS-Ganesha (NFSv3) | NFS-Ganesha (NFSv4) |
---|---|---|---|
Root-squash | はい | はい | はい |
All-squash | いいえ | はい | はい |
サブディレクトリーのエクスポート | はい | はい | はい |
ロック | はい | はい | はい |
クライアントベースのエクスポートパーミッション | はい | はい | はい |
Netgroups | はい | はい | はい |
マウントプロトコル | UDP、TCP | UDP、TCP | TCP のみ |
NFS トランスポートプロトコル | TCP | UDP、TCP | TCP |
AUTH_UNIX | はい | はい | はい |
AUTH_NONE | はい | はい | はい |
AUTH_KRB | いいえ | はい | はい |
ACL | はい | いいえ | はい |
委譲 | 該当なし | 該当なし | いいえ |
高可用性 | Yes (特定の制限付き。詳細は、Setting up CTDB for NFSを参照してください | はい | はい |
マルチヘッド | はい | はい | はい |
Gluster RDMA ボリューム | はい | サポート対象外 | サポート対象外 |
DRC | サポート対象外 | はい | はい |
動的エクスポート | いいえ | はい | はい |
pseudofs | 該当なし | 該当なし | はい |
NFSv4.1 | 該当なし | 該当なし | はい |
- 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 (非推奨)
# mount -t nfs HOSTNAME:VOLNAME MOUNTPATH
# gluster volume set VOLNAME nfs.disable off
- nfs.acl ON を設定するには、以下のコマンドを実行します。
# gluster volume set VOLNAME nfs.acl on
- nfs.acl OFF を設定するには、以下のコマンドを実行します。
# gluster volume set VOLNAME nfs.acl off
# 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 の設定 (非推奨)
# firewall-cmd --get-active-zones
# firewall-cmd --zone=zone_name --add-port=4379/tcp # firewall-cmd --zone=zone_name --add-port=4379/tcp --permanent
6.3.2.1.1. 前提条件
- 古いバージョンの 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 のポートおよびファイアウォール情報
# 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 の設定
- 複製ボリュームを作成します。このボリュームは、ゼロバイトロックファイルのみをホストするため、最小サイズのブリックを選択します。複製ボリュームを作成するには、以下のコマンドを実行します。
# 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
- 以下のファイルの 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"
- ボリュームを起動します。
# gluster volume start ctdb
最初のプロセスの一環として、S29CTDBsetup.sh
スクリプトはすべての Red Hat Gluster Storage サーバーで実行され、マウント用に/etc/fstab
のエントリーを追加し、Gluster NFS サーバーのすべてのノードで/gluster/lock
にボリュームをマウントします。また、起動時に CTDB サービスの自動起動も有効にします。注記特別な CTDB ボリュームを停止すると、S29CTDB-teardown.sh スクリプトはすべての Red Hat Gluster Storage サーバーで実行し、マウント用に /etc/fstab のエントリーを削除し、/gluster/lock でボリュームをアンマウントします。 - /etc/sysconfig/ctdb ファイルが Gluster NFS サーバーとして使用されるすべてのノードに存在するかどうかを確認します。このファイルには、Red Hat Gluster Storage の推奨される CTDB 設定が含まれます。
- Gluster NFS サーバーとして使用されるすべてのノードに /etc/ctdb/nodes ファイルを作成し、これらのノードの IP をファイルに追加します。
10.16.157.0 10.16.157.3 10.16.157.6
ここに一覧表示される IP は、NFS サーバーのプライベート IP です。 - 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
- 以下のコマンドを実行して、すべてのノードで CTDB サービスを起動します。
# service ctdb start
6.3.2.2. Gluster NFS を使用した Red Hat Gluster Storage ボリュームのマウント (非推奨)
/etc/nfsmount.conf
の nfsmount.conf
ファイルのデフォルトバージョンとしてバージョン 3 を常に設定します。このファイルに以下のテキストを追加し ます。
Defaultvers=3
vers=3
を手動で追加します。
# mount nfsserver:export -o vers=3 /MOUNTPOINT
tcp,rdma
の場合は、ボリュームセットオプション nfs.transport-type
を使用して変更する可能性があります。
6.3.2.2.1. Gluster NFS を使用したボリュームの手動マウント (非推奨)
- ボリュームにマウントポイントが作成されていない場合は、mkdir コマンドを実行してマウントポイントを作成します。
# mkdir /mnt/glusterfs
- システムの適切な mount コマンドを実行します。
- Linux の場合
# mount -t nfs -o vers=3 server1:/test-volume /mnt/glusterfs
- Solaris の場合
# mount -o vers=3 nfs://server1:38467/test-volume /mnt/glusterfs
要求された 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 クライアントにより多くのパーミッションが付与される可能性があります。
- ボリュームにマウントポイントが作成されていない場合は、mkdir コマンドを実行してマウントポイントを作成します。
# mkdir /mnt/glusterfs
- システムの適切な mount コマンドを実行します。システムの 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 を使用したボリュームの自動マウント (非推奨)
/etc/auto.master
ファイルおよび /etc/auto.misc
ファイルを更新して、autofs サービスを再起動します。ユーザーまたはプロセスがディレクトリーにアクセスしようとするたびに、バックグラウンドでマウントされます。
- テキストエディターで
/etc/fstab
ファイルを開きます。 fstab
ファイルに次の設定を追加します。HOSTNAME|IPADDRESS:/VOLNAME /MOUNTDIR nfs defaults,_netdev, 0 0
上記のサーバー名例を使用すると、エントリーには以下の置換値が含まれます。server1:/test-volume /mnt/glusterfs nfs defaults,_netdev, 0 0
- テキストエディターで
/etc/fstab
ファイルを開きます。 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-dirs
をon
に設定すると、nfs.export-dir
オプションを指定することで、すべてのサブディレクトリー (nfs.export-dirs on
) をエクスポートしたり、個別にエクスポートしたサブディレクトリー (nfs.export-dirs off
) のみをエクスポートするのではなく、エクスポートするサブディレクトリーを 1 つ以上指定することができます。特定のサブディレクトリーをエクスポートするには、以下のコマンドを実行します。# 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 ボリュームのテスト
- mount コマンドを実行して、ボリュームが正常にマウントされたかどうかを確認します。
# mount server1:/test-volume on /mnt/glusterfs type nfs (rw,addr=server1)
- df コマンドを実行して、ボリュームのすべてのブリックから集約されたストレージ領域を表示します。
# df -h /mnt/glusterfs Filesystem Size Used Avail Use% Mounted on server1:/test-volume 28T 22T 5.4T 82% /mnt/glusterfs
- cd コマンドを使用してマウントディレクトリーに移動し、コンテンツを一覧表示します。
# cd /mnt/glusterfs # ls
注記NFS プロトコルの LOCK 機能はアドバイザリーで、複数のクライアントが同じボリュームにアクセスしている場合はロックを使用することが推奨されます。
6.3.2.3. Gluster NFS のトラブルシューティング (非推奨)
- 問: NFS クライアントの mount コマンドが RPC エラー: Program not registered で失敗します。このエラーは、以下のいずれかの理由で発生しています。
- 問: rpcbind サービスが NFS クライアントで実行されていない。原因としては、以下の理由があります。
- 問: NFS サーバーの glusterfsd は起動していますが、ログの nfsrpc- service: portmap registration of program failed エラーメッセージで初期化に失敗します。
- 問: ログファイルの Port is already in use メッセージで、NFS サーバーの起動に失敗します。
- 問: NFS サーバーが失敗し、以下のエラーが表示され、mount コマンドは失敗します。
- 問: showmount コマンドが clnt_create: RPC: Unable to receive エラーで失敗します。このエラーは、以下の理由で発生しています。
- 問: アプリケーションが Invalid argument または Value too large to define data type で失敗します
- 問: NFS サーバーを実行しているマシンを再起動すると、クライアントは、先に保持したロックの回収に失敗します。
- 問: ボリュームが正常にマウントされても、nfs.log に rpc actor failed to complete successfully エラーが表示されます。
- 問: mount コマンドは、No such file or directory で失敗します。
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 volume start VOLNAME
rpcbind
サービスが NFS クライアントで実行されていない。原因としては、以下の理由があります。
- portmap が実行していません。
- カーネルの NFS サーバーまたは glusterNFS サーバーの別のインスタンスが実行されています。
rpcbind
サービスを起動します。
# service rpcbind start
[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
- 以下のコマンドを実行して、NFS サーバーで rpcbind サービスを起動します。
# service rpcbind start
rpcbind サービスを起動したら、glusterFS NFS サーバーを再起動する必要があります。 - 同じマシンで実行している別の NFS サーバーを停止します。このようなエラーも、同じマシン上で別の NFS サーバーが実行されている場合にも見られますが、glusterFS NFS サーバーではありません。Linux システムでは、これはカーネルの NFS サーバーである可能性があります。解決するには、他の NFS サーバーを停止するか、マシン上で glusterFS NFS サーバーを実行しないようにします。カーネルの NFS サーバーを停止する前に、重要なサービスが、その NFS サーバーのエクスポートへのアクセスに依存しないようにしてください。Linux では、使用中のディストリビューションに応じて以下のコマンドのいずれかを使用して、カーネルの NFS サーバーを停止できます。
# service nfs-kernel-server stop # service nfs stop
- 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
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
- ファイアウォールがポートをブロックしている可能性があります。
- rpcbind が実行されていない可能性があります。
NFS.enable-ino32 <on | off>
off
になっており、NFS はデフォルトでは 64 ビットの inode 番号を返すことができます。
- デフォルトでは大きなファイルに対応していない 32 ビットマシン上で構築され、実行している。
- 64 ビットシステムで 32 ビット標準に構築されている。
-D_FILE_OFFSET_BITS=64
オン
の場合は、chkconfig nfslock off を実行して、システムの起動時に NSM クライアントを無効にします。これにより、問題が解決されます。
rpc actor failed to complete successfully
エラーが表示されます。
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 -t nfs -o vers=3,noacl server1:/test-volume /mnt/glusterfs
No such file or directory
で失敗します。
6.3.3. NFS Ganesha
6.3.3.1. NFS-Ganesha のサポートされる機能
高可用性 Active-Active NFS-Ganesha
高可用性のアクティブ/アクティブ環境で、特定のアプリケーションを実行している NFS-Ganesha サーバーに接続されている NFS-Ganesha サーバーがダウンすると、管理上の介入なしにアプリケーション/NFS クライアントは、別の NFS-Ganesha サーバーにシームレスに接続されます。
ボリュームの動的エクスポート
NFS-Ganesha は、エクスポートの追加または削除を動的にサポートします。動的エクスポートは DBus インターフェースにより管理されます。DBus は、システム管理およびピアツーピアアプリケーション通信用のシステムローカル IPC メカニズムです。
複数のエントリーのエクスポート
NFS-Ganesha では、複数の Red Hat Gluster Storage ボリュームまたはサブディレクトリーを同時にエクスポートすることができます。
擬似ファイルシステム
NFS-Ganesha は NFSv4 擬似ファイルシステムを作成して維持します。このシステムは、サーバー上のすべてのエクスポートしたオブジェクトへのシームレスなアクセスを提供します。
アクセス制御リスト
NFS-Ganesha NFSv4 プロトコルには、Windows で使用されるアクセス制御リスト (ACL) の統合サポートが含まれています。これらの ACL を使用して信頼側の識別や、その信頼側のアクセス権限の許可または拒否を指定できます。この機能はデフォルトでは無効になっています。
6.3.3.2. NFS Ganesha の設定
6.3.3.2.1. NFS-Ganesha のポートおよびファイアウォール情報
表6.6 NFS ポートの詳細
サービス | ポート番号 | プロトコル |
sshd | 22 | TCP |
rpcbind/portmapper | 111 | TCP/UDP |
NFS | 2049 | TCP/UDP |
mountd | 20048 | TCP/UDP |
NLM | 32803 | TCP/UDP |
RQuota | 875 | TCP/UDP |
statd | 662 | TCP/UDP |
pcsd | 2224 | TCP |
pacemaker_remote | 3121 | TCP |
corosync | 5404 および 5405 | UDP |
dlm | 21064 | TCP |
サービスポートの定義
nfs-ganesha クラスターのすべてのノードで以下のコマンドを実行して、上記のポートを使用するように statd サービスが設定されていることを確認します。
- Red Hat Enterprise Linux 7 では、以下のように /etc/sysconfig/nfs ファイルを編集します。
# sed -i '/STATD_PORT/s/^#//' /etc/sysconfig/nfs
注記この手順は、Red Hat Enterprise Linux 8 には適用されません。 - statd サービスを再起動します。Red Hat Enterprise Linux 7 の場合
# systemctl restart nfs-config # systemctl restart rpc-statd
注記この手順は、Red Hat Enterprise Linux 8 には適用されません。
- 以下のコマンドを使用して '/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
- サービスを再起動します。Red Hat Enterprise Linux 7 の場合
# systemctl restart nfs-config # systemctl restart rpc-statd # systemctl restart nfslock
- 以下のコマンドを使用して、最初のステップで設定したポートを開きます。
# 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
- 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 で、以下に挙げるファイアウォールサービスを有効にします。- 以下のコマンドを使用して、アクティブゾーンの一覧を取得します。
# firewall-cmd --get-active-zones
- アクティブなゾーンでファイアウォールサービスを許可し、以下のコマンドを実行します。
# 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 を実行するための前提条件
- エクスポートには Red Hat Gluster Storage ボリュームと NFS-Ganesha rpms がインストールされている必要があります。
- フェンシングエージェントが設定されていることを確認します。フェンシングエージェントの設定に関する詳細は、以下のドキュメントを参照してください。
- High Availability Add-On 管理ガイドのフェンシング設定セクション: https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/high_availability_add-on_administration/s1-fenceconfig-haaa
- High Availability Add-On Reference ガイドのフェンスデバイスセクション: https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-guiclustcomponents-haar#s2-guifencedevices-HAAR
注記高可用性で 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. クラスターサービスの設定
- 以下のコマンドを使用して Pacemaker サービスを有効にします。Red Hat Enterprise Linux 7 の場合:
# systemctl enable pacemaker.service
- 以下のコマンドを使用して pcsd サービスを起動します。Red Hat Enterprise Linux 7 の場合:
# systemctl start pcsd
注記- システムの再起動後にデフォルトで pcsd を起動するには、以下のコマンドを実行します。Red Hat Enterprise Linux 7 の場合
# systemctl enable pcsd
- 以下のコマンドを使用して、すべてのノードに ’hacluster’ ユーザーのパスワードを設定します。すべてのノードに同じパスワードを使用します。
# echo <password> | passwd --stdin hacluster
- ノード間でクラスター認証を行います。ここで、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
- root ユーザーのパスワードなしで鍵ベースの SSH 認証を、全 HA ノードで有効にする必要があります。次の手順を実行します。
- クラスターのいずれかのノード (node1) で、以下を実行します。
# ssh-keygen -f /var/lib/glusterd/nfs/secret.pem -t rsa -N ''
- すべてのノードについて以下のコマンドを実行して、生成された公開鍵を node1 からすべてのノード (node1 を含む) にデプロイします。
# ssh-copy-id -i /var/lib/glusterd/nfs/secret.pem.pub root@<node-ip/hostname>
- すべてのノードについて以下のコマンドを実行して、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/
- クラスターの設定の一環として、ポート 875 は Rquota サービスにバインドされます。このポートがすでに使用されている場合は、すべてのノードの /etc/ganesha/ganesha.conf ファイルで以下の行を変更して、このサービスに別のポートを割り当てます。
# Use a non-privileged port for RQuota Rquota_Port = 875;
6.3.3.2.4. ganesha-ha.conf ファイルの作成
- /var/run/gluster/shared_storage に nfs-ganesha という名前のディレクトリーを作成します。注記3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。
- ganesha.conf ファイルおよび ganesha ファイルを /etc/ganesha から /var/run/gluster/shared_storage/nfs-ganesha にコピーします。
# 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 を有効にします。
- 以下のコマンドを実行して 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 を手動で有効にする必要があります。
- NFS-Ganesha が起動に失敗します。
- NFS-Ganesha ポート 875 は利用不可です。
- ganesha.conf ファイルは /etc/ganesha/ganesha.conf にあります。
- RQUOTA を無効にするには、#Enable_RQUOTA 行のコメントを解除します。
- すべてのノードで nfs-ganesha サービスを再起動します。
# systemctl restart nfs-ganesha
6.3.3.2.6. NFS-Ganesha を使用したボリュームのエクスポートとエクスポート解除
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
# 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 エクスポートへのアクセス
- 以下のコマンドを実行して調整可能なパラメーターを設定します。
# 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
- 再起動時に調整可能なパラメーターを永続的にするには、以下のコマンドを実行します。
# 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
6.3.3.3.1. 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 モードでのエクスポートのマウント
# mount -t nfs -o vers=4 virtual_ip:/volname /mountpoint
# mount -t nfs -o vers=4 10.70.0.0:/testvol /mnt
# 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 サーバーのクライアントの検索
# dbus-send --type=method_call --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ClientMgr org.ganesha.nfsd.clientmgr.ShowClients
6.3.3.3.4. dbus を使用して 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
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_version
、CIDR_address
、CIDR_mask
および CIDR_proto
はクライアントの CIDR 表現の詳細です。また、uint32 anonymous_uid
、uint32 anonymous_gid
、uint32 expire_time_attr
、uint32 オプション
、および 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 設定の変更
6.3.3.4.1. ノードのクラスターへの追加
/var/lib/glusterd/nfs/secret.pem
SSH キーはすでに生成されているため、この手順を繰り返すことはできません。
# /usr/libexec/ganesha/ganesha-ha.sh --add <HA_CONF_DIR> <HOSTNAME> <NODE-VIP>
/run/gluster/shared_storage/nfs-ganesha
です。
# /usr/libexec/ganesha/ganesha-ha.sh --add /var/run/gluster/shared_storage/nfs-ganesha server16 10.00.00.01
6.3.3.4.2. クラスター内のノードの削除
# /usr/libexec/ganesha/ganesha-ha.sh --delete <HA_CONF_DIR> <HOSTNAME>
/run/gluster/shared_storage/nfs-ganesha
にあります。
# /usr/libexec/ganesha/ganesha-ha.sh --delete /var/run/gluster/shared_storage/nfs-ganesha server16
6.3.3.4.3. クラスター内のノードの置き換え
- クラスターからノードを削除します。「クラスター内のノードの削除」 を参照
- 同じホスト名で、ノードを作成します。「ホストマシンの同じホスト名への置き換え」を参照。注記新規ノードが古いノードと同じ名前を持つ必要はありません。
- ノードをクラスターに追加します。「ノードのクラスターへの追加」 を参照注記「NFS-Ganesha のポートおよびファイアウォール情報」 で説明したように、ファイアウォールサービスが有効にされており、「NFS-Ganesha を実行するための前提条件」 も満たされていることを確認します。
6.3.3.5. デフォルトのエクスポート設定の変更
/run/gluster/shared_storage/nfs-ganesha/exports/
にある対応するエクスポートファイルで必要なフィールドを編集または追加します。- 以下のコマンドを実行します。
# /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 - エクスポート設定を変更する必要があるボリュームの名前。
# 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 }
export.conf
ファイルにマイナーな変更を加える必要があります。
- 特定クライアントのパーミッションの提供
- NFSv4 ACL の有効化および無効化
- NFSv4 マウントに疑似パスを提供
- サブディレクトリーのエクスポート
6.3.3.5.1. 特定クライアントのパーミッションの提供
EXPORT
ブロックで指定したパラメーター値とパーミッションの値は、エクスポートしたボリュームをマウントするクライアントに適用されます。特定のクライアントに特定のパーミッションを提供するには、EXPORT
ブロック
内にクライアントブロックを追加します。
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 の有効化および無効化
Disable_ACL = false;
6.3.3.5.3. NFSv4 マウントに疑似パスを提供
Pseudo = "pseudo_path"; # NFSv4 pseudo path for this export. Eg: "/test_volume_pseudo"
6.3.3.5.4. サブディレクトリーのエクスポート
- サブディレクトリー用の個別のエクスポートファイルを作成します。
# 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 に変更します。Path
および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
- 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 に変更します。Path
および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 オプションの有効化
Squash = all_squash ; # To enable/disable root squashing
6.3.3.5.5. サブディレクトリーのエクスポート
- 設定ファイル (/var/run/gluster/shared_storage/nfs-ganesha/exports/file-name.conf) からエクスポートを解除する共有のエクスポート ID をメモします。
- 設定の削除:
- 設定ファイルを削除します(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 の設定
- すべてのマシンに 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 パッケージが依存パッケージとして更新されます。
- 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 の両方について、次の手順を実行します。 - すべてのシステムが DNS の FQDN で相互に解決できることを確認します。
/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
を参照してください。- NFS-server およびクライアントで、必要な変更を加えて /etc/idmapd.conf ファイルを更新します。以下に例を示します。
Domain = example.com
6.3.3.6.1. NFS-Ganesha サーバーの設定
- 以下のパッケージをインストールします。
# yum install nfs-utils # yum install rpcbind
- 関連する gluster および NFS-Ganesha の rpm をインストールします。詳細は『Red Hat Gluster Storage 3.5 Installation Guide』を参照してください。
- 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.
/etc/ganesha/ganesha.conf
ファイルを以下のように更新します。NFS_KRB5 { PrincipalName = nfs ; KeytabPath = /etc/krb5.keytab ; Active_krb5 = true ; }
- 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/ に変更されました。
- 非特権ユーザーを作成し、作成されるユーザーが中央のユーザーデータベースを介して UID に対して解決できるようにします。以下に例を示します。
# useradd guest
注記このユーザーのユーザー名は、NFS クライアント上のユーザー名と同じである必要があります。
6.3.3.6.2. NFS クライアントの設定
- 以下のパッケージをインストールします。
# yum install nfs-utils # yum install rpcbind
- 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.
- nfs-client.target サービスのステータスを確認し、起動していない場合は起動します。
# systemctl status nfs-client.target # systemctl start nfs-client.target # systemctl enable nfs-client.target
- 非特権ユーザーを作成し、作成されるユーザーが中央のユーザーデータベースを介して UID に対して解決できるようにします。以下に例を示します。
# useradd guest
注記このユーザーのユーザー名は、NFS-server にあるものと同じである必要があります。 - kerberos セキュリティータイプを指定してボリュームをマウントします。
# mount -t nfs -o sec=krb5 <host_name>:/testvolume /mnt
root ですべてのアクセスが付与される必要があります。以下に例を示します。マウントポイントにディレクトリーを作成し、root としてその他の操作がすべて成功する必要があります。# mkdir <directory name>
- ゲストユーザーとしてログインします。
# su - guest
kerberos チケットがないと、/mnt へのすべてのアクセスは拒否される必要があります。以下に例を示します。# su guest # ls ls: cannot open directory .: Permission denied
- ゲストの kerberos チケットを取得し、/mnt にアクセスします。
# kinit Password for guest@EXAMPLE.COM: # ls <directory created>
重要このチケットでは、一部のアクセスが /mnt にアクセスできる必要があります。"guest" にアクセスできないディレクトリーが NFS-server にある場合は、正しく動作するはずです。
6.3.3.7. NFS-Ganesha サービスがダウンタイム
- 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. フェイルオーバー時間の変更
表6.7
プロトコル | ファイル操作 |
NFSV3 |
|
NLM |
|
NFSV4 |
|
/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 パフォーマンスのチューニング
Dir_Chunk
パラメーターにより、インスタンスのチャンクでディレクトリーコンテンツを読み込むことができます。このパラメーターはデフォルトで有効になります。このパラメーターのデフォルト値は 128
です。このパラメーターの範囲は、1
から UINT32_MAX
です。このパラメーターを無効にするには、値を 0
に設定します。
手順6.1 NFS-Ganesha の場合の readdir パフォーマンスの設定
/etc/ganesha/ganesha.conf
ファイルを編集します。CACHEINODE
ブロックを見つけます。- ブロック内に
Dir_Chunk
パラメーターを追加します。CACHEINODE { Entries_HWMark = 125000; Chunks_HWMark = 1000; Dir_Chunk = 128; # Range:
1
toUINT32_MAX
,0
to disable } 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 原因を理解するようにしてください。以下の手順に従い、問題を修正します。
- カーネルおよび gluster nfs サービスが無効になっていることを確認します。
- ポート 875 が RQUOTA サービスに接続できることを確認します。
- ノードの再起動/シャットダウン後に、共有ストレージボリュームマウントがサーバーに存在することを確認します。存在しない場合は、以下のコマンドを実行して、共有ストレージボリュームを手動でマウントします。
# 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 原因を理解するようにしてください。以下の手順に従い、問題を修正します。
- ポート 875 を使用して、プロセスの PID を抽出するには、以下のコマンドを実行します。
netstat -anlp | grep 875
- ポート 875 を使用するプロセスが重要なシステムまたはユーザープロセスであるかどうかを判断します。
- プロセスの重要性に応じて、以下のいずれかを実行します。
- ポート 875 を使用するプロセスが重要なシステムまたはユーザーのプロセスである場合:
- すべてのノードの ‘/etc/ganesha/ganesha.conf’ ファイルで以下の行を変更して、別のポートをこのサービスに割り当てます。
# Use a non-privileged port for RQuota Rquota_Port = port_number;
- ポート番号を変更したら、以下のコマンドを実行します。
# semanage port -a -t mountd_port_t -p tcp port_number # semanage port -a -t mountd_port_t -p udp port_number
- 以下のコマンドを実行して NFS-Ganesha を再起動します。
systemctl restart nfs-ganesha
- ポート 875 を使用するプロセスが重要なシステムまたはユーザーのプロセスでない場合:
- ポート 875 を使用してプロセスを強制終了するには、以下のコマンドを実行します。
# kill pid;
前の手順で抽出したプロセス ID を使用します。 - 以下のコマンドを実行して、プロセスが強制終了され、ポート 875 が未使用であることを確認します。
# ps aux | grep pid;
- 以下のコマンドを実行して NFS-Ganesha を再起動します。
systemctl restart nfs-ganesha
- 必要に応じて、強制終了したプロセスを再起動します。
状況
NFS-Ganesha クラスターの設定に失敗します。
解決策
以下の手順に進む前に、すべての必須チェックを実行して root 原因を理解するようにしてください。
- カーネルおよび gluster nfs サービスが無効になっていることを確認します。
- pcs cluster auth コマンドが、ユーザー hacluster用の同じパスワードを持つすべてのノードで実行されていることを確認します。
- 共有ストレージがすべてのノードにマウントされていることを確認します。
- HA クラスターの名前が 15 文字を超えないようにしてください。
OMPING
を使用して UDP マルチキャストパケットが ping できることを確認します。- 仮想 IP がどの NIC にも割り当てられていないことを確認します。
状況
NFS-Ganesha は起動し、ボリュームのエクスポートに失敗します。
解決策
以下の手順に進む前に、すべての必須チェックを実行して root 原因を理解するようにしてください。以下の手順に従い、問題を修正します。
- 以下のコマンドを使用して、ボリュームが Started の状態であることを確認します。
# gluster volume status <volname>
- 以下のコマンドを実行して、サービスのステータスを確認します。
# service nfs-ganesha status # showmount -e localhost
- 以下のログを確認し、失敗の原因を確認します。
/var/log/ganesha/ganesha.log /var/log/ganesha/ganesha-gfapi.log /var/log/messages
- 以下のコマンドを使用して、dbus サービスが実行中であることを確認します。
# service messagebus status
- ボリュームが開始状態でない場合は、以下のコマンドを実行してボリュームを起動します。
# 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 原因を理解するようにしてください。以下の手順に従い、問題を修正します。
- クラスターに含まれるノードのいずれかから、以下のコマンドを実行します。
# ganesha-ha.sh --add <HA_CONF_DIR> <NODE-HOSTNAME> <NODE-VIP>
- gluster_shared_storage ボリュームが、追加する必要のあるノードにマウントさることを確認します。
- クラスターのすべてのノードが、追加する必要のあるノードから DNS を解決できることを確認します。
- 追加する必要のあるノード上の 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 で SMB を使用する要件」 に概説した要件を満たしていることを確認します。
- レプリケーションを使用するボリュームを共有する場合は、CTDB 「Samba への CTDB の設定」 を設定します。
- SMB を使用してボリュームを共有するように設定する。「SMB でのボリュームの共有」
- macOS クライアントにボリュームをマウントする場合には、「macOS ユーザーのアプレット作成コンテキストの設定」。
- ユーザーアクセスパーミッションを設定します(「非特権ユーザーの読み取り/書き込みアクセスの設定」)。
- クライアントに共有ボリュームをマウントします。
- 共有ボリュームが適切に機能していることを確認します。「設定の開始と検証」
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 の設定
前提条件
- 古いバージョンの 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 の設定
- 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
- 以下のファイルで、
META="all"
" のステートメントのall
を、すべて 新たに作成されたボリューム名に置き換えます (例:META="ctdb"
)。/var/lib/glusterd/hooks/1/start/post/S29CTDBsetup.sh /var/lib/glusterd/hooks/1/stop/pre/S29CTDB-teardown.sh
/etc/samba/smb.conf
ファイルで、全ノードの global セクションに以下の行を追加します。clustering=yes
- ボリュームを起動します。
# 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
でボリュームをアンマウントします。 /etc/crdb
ディレクトリーが Samba サーバーとして使用されるすべてのノードに存在することを確認します。このファイルには、Red Hat Gluster Storage に推奨される CTDB 設定情報が含まれます。- Samba サーバーとして使用されるすべてのノードに
/etc/ctdb/nodes
ファイルを作成し、これらのノードの IP アドレスをファイルに追加します。10.16.157.0 10.16.157.3 10.16.157.6
ここに一覧表示される IP アドレスは、Samba サーバーのプライベート IP アドレスです。 - 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
- すべてのノードで CTDB サービスを起動します。RHEL 7 および RHEL 8 で以下を実行します。
# systemctl start ctdb
RHEL 6 で以下を実行します。# service ctdb start
6.4.3. SMB でのボリュームの共有
/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 設定オプション
設定オプション | 必須? | デフォルト値 | 説明 |
---|---|---|---|
パス | はい | 該当なし | これは、共有している 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 を使用している場合は、以下を行います。
- SMB 固有のキャッシュを有効にします。
# gluster volume set VOLNAME performance.cache-samba-metadata on
汎用メタデータキャッシュを有効にしてパフォーマンスを向上させることもできます。詳細は、「ディレクトリー操作」 を参照してください。 - 各 Red Hat Gluster Storage ノードで
glusterd
サービスを再起動します。 - 適切なロックと I/O 一貫性を確認します。
# gluster volume set VOLNAME storage.batch-fsync-delay-usec 0
# gluster volume set <volname> performance.write-behind off
Samba-4.8.5-104 以降を使用している場合は、以下を行います。
- 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
が導入されました。 - 以下のコマンドを実行して、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 以降を使用している場合は、以下を行います。
- 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 ボリュームはmyvol
で、/mylocal
にマウントされる場合 /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 = yesvfs objects
パラメーター値をglusterfs_fuse
に編集しますvfs objects = glusterfs_fuse
- 以前に記録された FUSE マウントポイントに
path
パラメーター値を編集します。以下に例を示します。path = /MOUNTDIR
- 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 バージョンに対して以下を実行します。
- 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 --------- -------
- ユーザーが 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 ユーザーのアプレット作成コンテキストの設定
smb.conf
ファイルの[global]
セクションに以下の行を追加します。表示されるインデントレベルが必要なことに注意してください。fruit:aapl = yes ea support = yes
- 以下の行を
vfs_fruit
ファイルのボリュームのエクスポート設定ブロックに追加して、smb.conf
モジュールとその依存関係を読み込みます。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. 非特権ユーザーの読み取り/書き込みアクセスの設定
- 設定に基づいてすべての Samba サーバーにユーザーを追加します。
# adduser username
- すべての Samba サーバーの Samba ユーザーの一覧にユーザーを追加し、以下のコマンドを実行してパスワードを割り当てます。
# smbpasswd -a username
- その他の Samba サーバーから、FUSE プロトコルを使用してボリュームをマウントします。
# mount -t glusterfs -o acl ip-address:/volname /mountpoint
以下に例を示します。# mount -t glusterfs -o acl rhs-a:/repvol /mnt
- 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 でエクスポートしたボリュームの手動マウント
- クライアントに
cifs-utils
パッケージをインストールします。# yum install cifs-utils
- 構文の例を参考にして、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 ソフトウェアコンポーネントおよびバージョン』 を参照してください。 - サーバーで # 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 を使用したボリュームの手動マウント
- Windows Explorer で Tools → Map Network Drive… をクリックし、Map Network Drive 画面を開きます。
- ドライブドロップダウンリストを使用して、Drive を選択します。
- Folder テキストボックスで、サーバーと共有リソースのパスを次のフォーマットで指定します。\\SERVER_NAME\VOLNAME
- Finish をクリックしてプロセスを完了し、Windows Explorer でネットワークドライブを表示します。
- ネットワークドライブに移動し、正しくマウントされたことを確認します。
6.4.5.2.2. Microsoft Windows コマンドラインインターフェースを使用したボリュームの手動マウント
- Start → Run を クリックしてから
cmd
を入力します。 - net use z: \\SERVER_NAME\VOLNAME を入力します。z: は、共有ボリュームに割り当てるドライブ文字です。例: net use y: \\server1\test-volume
- ネットワークドライブに移動し、正しくマウントされたことを確認します。
6.4.5.3. macOS において SMB でエクスポートしたボリュームの手動マウント
前提条件
- Samba 設定で、SMB Apple Create Context を使用できることを確認します。
- 使用するユーザー名が、ボリュームの許可されたユーザーの一覧にあることを確認します。
手動マウントプロセス
- Finder で、Go > Connect to Server をクリックします。
- Server Address フィールドに、マウントするボリュームをホストする Red Hat Gluster Storage サーバーの IP アドレスまたはホスト名を入力します。
- Connect をクリックします。
- プロンプトが表示されたら、Registered User を選択して、有効なユーザー名とパスワードを使用してボリュームに接続します。必要に応じて、ユーザー名とパスワードを入力し、マウントするサーバーボリュームまたは共有フォルダーを選択します。今後コンピューターへの接続を容易にするには、Remember this password in my keychain を選択し、コンピューターのユーザー名とパスワードをキーチェーンに追加します。
6.4.5.4. Red Hat Enterprise Linux で SMB を使用してエクスポートしたボリュームの自動マウントの設定
- テキストエディターで
/etc/fstab
ファイルを開き、以下の詳細を含む行を追加します。\\HOSTNAME|IPADDRESS\SHARE_NAME MOUNTDIR cifs OPTIONS DUMP FSCK
OPTIONS コラムで、ユーザー名またはパスワードが含まれるファイルへのパスを指定して、credentials
オプションを指定するようにしてください。上記のサーバー名例を使用すると、エントリーには以下の置換値が含まれます。\\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 ソフトウェアコンポーネントおよびバージョン』 を参照してください。 - クライアントで # 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 でエクスポートしたボリュームの自動マウントの設定
- Windows Explorer で Tools → Map Network Drive… をクリックし、Map Network Drive 画面を開きます。
- ドライブドロップダウンリストを使用して、Drive を選択します。
- Folder テキストボックスで、サーバーと共有リソースのパスを次のフォーマットで指定します。\\SERVER_NAME\VOLNAME
- Reconnect at logon チェックボックスをクリックします。
- Finish をクリックしてプロセスを完了し、Windows Explorer でネットワークドライブを表示します。
- Windows Security 画面が表示されたら、ユーザー名とパスワードを入力して OK をクリックします。
- ネットワークドライブに移動し、正しくマウントされたことを確認します。
6.4.5.6. macOS で SMB でエクスポートしたボリュームの自動マウントの設定
- 「macOS において SMB でエクスポートしたボリュームの手動マウント」に記載のプロセスを使用して、ボリュームを手動でマウントします。
- Finder で、System Preferences > Users & Groups > Username > Login Items の順にクリックします。
- マウントされたボリュームをログイン項目一覧にドラッグします。起動時やログインするたびに、ドライブのウィンドウが開かないようにするには、Hide をオンにします。
6.4.6. 設定の開始と検証
設定の確認
- 以下のコマンドを使用して、CTDB が実行中であることを確認します。
# ctdb status # ctdb ip # ctdb ping -n all
- 仮想 IP のいずれかを使用して Red Hat Gluster Storage ボリュームをマウントします。
- # ctdb ip を実行して、VIP を提供する物理サーバーを見つけます。
- CTDB VIP サーバーをシャットダウンして、設定が正常に行われたことを確認します。仮想 IP を提供する Red Hat Gluster Storage サーバーがシャットダウンすると、数秒一時停止すると、I/O が再開します。
6.4.7. SMB 共有の無効化
すべてのボリュームに対する全ノードでの自動共有を停止するには、以下の手順を実施します。
- 権限が昇格されたすべての Red Hat Gluster Storage サーバーで、/var/lib/glusterd/hooks/1/start/post に移動します。
- S30samba-start.sh の名前を K30samba-start.sh に変更します。これらのスクリプトの詳細は、「13.2, Prepackaged Scripts」を参照してください。
1 つの特定ボリュームに対する全ノードでの自動共有を停止するには、次のコマンドを実行します。
- 以下のコマンドを実行して、ボリュームごとの自動 SMB 共有を無効にします。
# gluster volume set <VOLNAME> user.smb disable
6.4.8. Windows でのスナップショットへのアクセス
6.4.8.1. デスティネーションコピーの設定
vfs objects = shadow_copy2 glusterfs
表6.9 設定オプション
設定オプション | 必須? | デフォルト値 | 説明 |
---|---|---|---|
shadow:snapdir | はい | 該当なし | スナップショットが保持されるディレクトリーへのパス。snapdir の名前は .snaps にする必要があります。 |
shadow:basedir | はい | 該当なし | スナップショット元となるベースディレクトリーへのパス。basedir の値は / である必要があります。 |
shadow:sort | Optional | 分類されていない | サポートされる値は asc/desc です。このパラメーターにより、シャドウコピーディレクトリーをクライアントに送信する前にソートすることができます。これは、通常、unix ファイルシステムがアルファベット順でソートされないため、有益です。有効にすると、降順で指定されます。 |
shadow:localtime | Optional | UTC | これは、スナップショット名が UTC/GMT またはローカルタイムであることを示すオプションのパラメーターです。 |
shadow:format | はい | 該当なし | このパラメーターは、スナップショットの命名形式を指定します。形式は、str[fp]time が認識する変換仕様と互換性がある必要があります。デフォルト値は _GMT-%Y.%m.%d-%H.%M.%S です。 |
shadow:fixinodes | Optional | いいえ | shadow:fixinodes を有効にすると、このモジュールにより、ファイルパスのハッシュを使用して、スナップショットディレクトリー内のファイルの循環 inode 数が変更されます。これは、スナップショットが元のファイルと同じ device:inode 番号を持つスナップショットシステム (GPFS スナップショットの場合など) に必要です。このオプションを設定しないと、シャドウコピー UI の「restore」ボタンが共有違反で失敗します。 |
shadow:snapprefix | Optional | 該当なし | スナップショット名の接頭辞に一致する正規表現。Red Hat Gluster Storage は Basic Regular Expression (BRE) のみをサポートします。 |
shadow:delimiter | Optional | _GMT | 区切り文字は、shadow:snapprefix と shadow:format を分離するために使用されます。 |
[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
vfs objects = shadow_copy2 glusterfs_fuse
[gluster-vol0] comment = For samba share of volume vol0 vfs objects = shadow_copy2 glusterfs_fuse path = /MOUNTDIR read only = no guest ok = yes shadow:snapdir = /MOUNTDIR/.snaps shadow:basedir = /MOUNTDIR shadow:sort = desc shadow:snapprefix= ^S[A-Za-z0-9]*p$ shadow:format = _GMT-%Y.%m.%d-%H.%M.%S
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
サービスを起動または再起動します。RHEL 7 および RHEL 8 で systemctl [re]start smb を実行します。RHEL 6 で、service smb [re]start を実行します。- Samba の User Serviceable Snapshot (USS) を有効にします。詳細は、「ユーザーサービス可能なスナップショット」
6.4.8.2. スナップショットへのアクセス
- 以前のバージョンが必要なファイルまたはディレクトリーを右クリックします。
- Restore previous versions をクリックします。
- ダイアログボックスで、以前のバージョンのファイルの日付/時間を選択し、Open、Restore、または Copy を選択します。詳細は以下のようになります。Open: 必要なバージョンのファイルを読み取り専用モードで開きます。Restore: ファイルを選択したバージョンに戻します。Copy: ファイルを別の場所にコピーします。
図6.1 スナップショットへのアクセス
6.4.9. パフォーマンスチューニング
- メタデータキャッシングを有効にして、Red Hat Gluster Storage ボリュームの SMB アクセスのパフォーマンスを改善します。
- ディレクトリーリスティングのパフォーマンスの強化
- ファイル/ディレクトリー作成パフォーマンスの強化
6.4.9.1. メタデータキャッシングの有効化
- 以下のコマンドを実行し、メタデータのキャッシュおよびキャッシュの無効化を有効にします。
# gluster volume set <volname> group metadata-cache
これは group set オプションで、1 つのコマンドに複数のボリュームオプションを設定します。 - キャッシュ可能なファイル数を増やすには、以下のコマンドを実行します。
# gluster volume set <VOLNAME> network.inode-lru-limit <n>
N は 50000 に設定されます。ボリューム内のアクティブなファイルの数が非常に高い場合は、増やすことができます。この数字を増やすと、ブリックプロセスのメモリーフットプリントが増加します。
6.4.9.2. ディレクトリーリスティングのパフォーマンスの強化
- 以下のコマンドを実行して、
performance.readdir-ahead
オプションが有効になっているかどうかを確認します。# gluster volume get <VOLNAME> performance.readdir-ahead
performance.readdir-ahead
が有効になっていない場合は、以下のコマンドを実行します。# gluster volume set <VOLNAME> performance.readdir-ahead on
- 以下のコマンドを実行して
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. ファイル/ディレクトリー作成パフォーマンスの強化
- 以下のコマンドを実行して negative-lookup キャッシュを有効にします。
# gluster volume set <volname> group nl-cache volume set success
注記上記のコマンドは cache-invalidation も有効にし、タイムアウトを 10 分に増やします。
6.5. POSIX アクセス制御リスト
6.5.1. 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 は、ユーザーfred
に、/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 が、newbies
グループのユーザーが/mnt/harmful_script.sh
の実行を阻止します。o:
で始まるその他のユーザーのルール# setfacl -m o:perms file_path
たとえば、setfacl -m o:r /mnt/data/public は、/mnt/data/public directory
内のファイルを読み込むユーザー名またはグループパーミッションに関する特定のルールがないユーザーを許可します。- 実効権限マスクを使用して最大アクセスレベルを設定するルールでは、
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 は admin
が 、setfacl が実行される際に /etc
ディレクトリーで作成されたファイルへのアクセス権限を付与します。
6.5.2. getfacl で現在の ACL の確認
# getfacl file_path
# getfacl /mnt/gluster/data/test/sample.jpg # owner: antony # group: antony user::rw- group::rw- other::r--
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 が有効なボリュームのマウント
acl
マウントオプションを使用します。詳細は、「Red Hat Gluster Storage ボリュームのマウント」 を参照してください。
6.5.4. マウントされたボリュームでの ACL 有効化の確認
表6.10
クライアントタイプ | 確認方法 | 詳細情報 |
---|---|---|
ネイティブ FUSE | default_permissions オプションについて、mount コマンドの出力を確認します。
# mount | grep mountpoint
マウントされたボリュームの出力に
default_permissions が表示されると、そのボリュームでは ACL が有効になりません。
ps aux コマンドの出力で、gluster FUSE マウントプロセス (glusterfs) を確認します。
# 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 volume info volname コマンドの出力を確認します。
nfs.acl が出力に表示されると、そのボリュームで ACL が無効になっています。nfs.acl が表示されない場合は、ACL が有効になります (デフォルトの状態)。
クライアント側で、ボリュームの mount コマンドの出力を確認します。出力に
noacl が表示されると、マウントポイントで ACL が無効になります。出力に何も表示されない場合は、クライアントはサーバーが ACL を使用していることを確認し、サーバーサポートが有効な場合に ACL を使用します。
|
NFS に関する gluster volume set help の出力、または Red Hat Enterprise Linux 『Storage Administration Guide』 https://access.redhat.com/documentation/ja-JP/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/ja-JP/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-nfs.html を参照してください。
|
samba |
POSIX ACL は、Samba を使用して Red Hat Gluster Storage ボリュームにアクセスする際にデフォルトで有効になります。
| 詳細は、「SMB」 を参照してください。 |
6.6. クライアントオペレーティングシステムバージョンの確認
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 の前:
- チェックするボリュームの状態ダンプを実行します。
# gluster volume statedump volname
- 状態ダンプディレクトリーの特定
# gluster --print-statedumpdir
- 状態ダンプファイルを見つけ、クライアント情報について grep します。
# grep -A4 "identifier=client_ip" statedumpfile
第7章 Red Hat Gluster Storage と Windows Active Directory の統合
図7.1 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 ノードは、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/ja-jp/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
- 認証の設定
- Active Directory ドメインへの参加
- Active Directory およびサービスの検証/テスト
7.2.1. 認証の設定
- アクティブなディレクトリーに参加する前に、CTDB が設定されていることを確認してください。詳細は、『Red Hat Gluster Storage Administration Guide』 の 『Section 6.3.1 Setting up CTDB for Samba』 を参照してください。
- 変更を行う前に、設定および Samba のデータベース (ローカルおよび ctdb) のバックアップを取得することが推奨されます。
7.2.1.1. Samba の基本設定
autorid
です。tdb
などのユーザーおよびグループ ID を自動的に計算する他に、データベーストランザクションおよび読み取り操作の実行は少なくなり、セキュアな ID 履歴 (SID 履歴) をサポートするのに必要な要件であるため、Red Hat では、autorid
を推奨しています。
/etc/samba/smb.conf
はすべてのノードで同一であり、AD に関連するパラメーターを含める必要があります。その他に、ユーザーおよびグループ ID とグループ ID のマッピングをアクティブにするために、いくつかの設定が必要になります。
[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
ファイルで必要な完全な global
セクションです。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.conf
のnetbios aliases
パラメーターに追加できます。 - AD 環境では、通常 nmbd を実行する必要はありません。ただし、nmbd を実行する必要がある場合は、cluster addresses
smb.conf
オプションをクラスターのパブリック IP アドレスの一覧に設定するようにしてください。
7.2.1.2. ad
バックエンドを使用した代替設定
autorid
に加えて idmap_ad
モジュールを使用して、Samba 設定をさらに調整できます。idmap_ad
モジュールは、AD の特別な unix 属性から unix ID を読み取ります。これは、Samba および winbind が使用可能になる前に、AD ドメインの管理者が設定する必要があります。
idmap_ad
を使用できるようにするには、AD ドメイン管理者がこのような unix 拡張を使用するための AD ドメインを準備し、Samba サーバーにアクセスできるすべてのユーザーおよびグループに unix ID を割り当てる必要があります。
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 -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 の設定
/etc/nsswitch.conf
ファイルを編集します。ファイルに passwd データベースおよび group データベースの winbind エントリーが含まれていることを確認してください。以下に例を示します。
... passwd: files winbind group: files winbind ...
7.2.2. Active Directory ドメインへの参加
# onnode all systemctl start ctdb # onnode all systemctl stop winbind # onnode all systemctl stop smb
# 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 サービスへのアクセスを防ぐことができます。これらのサービスは稼働したままになる可能性がありますが、他の手段でそれらへのアクセスを防ぐ必要があります。
# 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.
# net ads dns register rhs-smb <PUBLIC IP 1> <PUBLIC IP 2> ...
rhs-smb
が指定のパブリック IP アドレスに解決するようになります。DNS 登録は、AD での認証にクラスターマシンアカウントを使用します。つまり、この操作は、結合が成功した後にのみ実行できます。
7.2.3. Active Directory およびサービスの検証/テスト
# onnode all systemctl start nmb # onnode all systemctl start winbind # onnode all systemctl start smb
# 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
以下の手順を実行して結合を確認します。
以下のコマンドを使用して、作成したマシンアカウントを使用して AD LDAP サーバーに認証できるかどうかを確認します。# net ads testjoin Join is OK
- 以下のコマンドを実行して、マシンアカウントの 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
- 以下のコマンドを実行して、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
以下の手順を実行して、winbind が正しく動作しているかどうかを確認します。
以下のコマンドを実行して、winbindd が AD への認証にマシンアカウントを使用できるかどうかを確認します。# wbinfo -t checking the trust secret for domain ADDOM via RPC calls succeeded
- 以下のコマンドを実行して、指定の名前を Windows SID に解決します。
# wbinfo --name-to-sid 'ADDOM\Administrator' S-1-5-21-2562125317-1564930587-1029132327-500 SID_USER (1)
- 以下のコマンドを実行して認証を確認します。
# 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
- 以下のコマンドを実行して、id-mapping が適切に機能しているかどうかを確認します。
# wbinfo --sid-to-uid <SID-OF-ADMIN> 1000000
- 以下のコマンドを実行して、winbind Name Service Switch モジュールが正しく機能していることを確認します。
# getent passwd 'ADDOM\Administrator' ADDOM\administrator:*:1000000:1000004::/home/ADDOM/administrator:/bin/false
- 以下のコマンドを実行して、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章 スナップショットの管理
図8.1 スナップショットのアーキテクチャー
クラッシュの一貫性
クラッシュの一貫性のあるスナップショットは、特定の時点でキャプチャーされます。クラッシュしたスナップショットが復元されると、データはスナップショットの取得時と同じになります。
注記現在、アプリケーションレベルの一貫性はサポートされていません。オンラインスナップショット
スナップショットはオンラインスナップショットであるため、スナップショットを作成しても、ファイルシステムとその関連データは引き続きクライアントで利用可能になります。
バリア
スナップショットの操作時に一部のファイル操作がブロックされるクラッシュの一貫性を保証するため、
これらのファイル操作は、スナップショットが完了するまでブロックされます。他のすべてのファイル操作は渡されます。タイムアウトの 2 分のデフォルト値は 2 分です。スナップショットが完了していない場合には、これらのファイル操作はアンロックされます。スナップショットの完了前にバリアが無効化されると、スナップショットの操作に失敗します。これは、スナップショットが一貫した状態になるようにするためです。
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/ja-jp/red_hat_enterprise_linux/7/html-single/logical_volume_manager_administration/index#LVM_components を参照してください。
推奨される設定
- 各ボリュームブリックについて、ボリュームとそのブリックスナップショット (シン) のスナップショットを含む専用のシンプールを作成します。現在のシン p 設計では、同じシンプールに異なる Red Hat Gluster Storage ボリュームのブリックを配置しないでください。これは、その他関連のないボリュームにおけるスナップショットの削除などのスナップショット操作のパフォーマンスが低下するためです。
- 推奨されるシンプールチャンクサイズは 256 KB です。顧客のワークロードの詳細情報がある場合は、例外がある場合もあります。
- 推奨されるプールメタデータサイズは、256KB 以上のチャンクサイズのシンプールサイズの 0.1% です。特別なケースでは、256 KB 未満のチャンクサイズを、シンプールサイズの 0.5% を使用します。
例
- pvcreate コマンドを使用して、物理ボリューム(PV)を作成します。
pvcreate /dev/sda1
デバイスに基づいて正しいdataalignment
アラインメントオプションを使用します。詳細は、「ブリック設定」 を参照 - 以下のコマンドを使用して PV からボリュームグループ (VG) を作成します。
vgcreate dummyvg /dev/sda1
- 以下のコマンドを使用して、シンプールを作成します。
# lvcreate --size 1T --thin dummyvg/dummypool --chunksize 256k --poolmetadatasize 16G --zero n
256 KB のチャンクサイズを使用して、サイズが 1 TB のシンプールが作成されます。最大プールメタデータサイズである 16 G が使用されます。 - 以下のコマンドを使用して、作成しておいたプールからシンプロビジョニングされたボリュームを作成します。
# lvcreate --virtualsize 1G --thin dummyvg/dummypool --name dummylv
- これには、ファイルシステム (XFS) を作成します。シン LV に XFS ファイルシステムを作成するには、推奨されるオプションを使用してください。以下に例を示します。
mkfs.xfs -f -i size=512 -n size=8192 /dev/dummyvg/dummylv
- この論理ボリュームをマウントし、マウントパスをブリックとして使用します。
mount /dev/dummyvg/dummylv /mnt/brick1
8.2. スナップショットの作成
- Red Hat Gluster Storage ボリュームが存在し、ボリュームが
Started
の状態である必要があります。 - ボリュームのブリックはすべて、独立したシン論理ボリューム (LV) 上にある必要があります。
- スナップショット名はクラスター内で一意である必要があります。
- n >= 3 の n 方向レプリケーションでない限り、ボリュームのすべてのブリックが稼働しているはずです。この場合は、クォーラムを満たす必要があります。詳細は、8章スナップショットの管理 を参照
- Rebalance、add-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 - スナップショット作成コマンドの挙動は、force オプションの有無にかかわらず同じになります。
- no-timestamp: デフォルトでは、タイムスタンプがスナップショット名に追加されます。タイムスタンプを追加しない場合は、no-timestamp を引数として渡します。
activate-on-create
パラメーターを enabled
に設定します。
# gluster snapshot create snap1 vol1 no-timestamp snapshot create: success: Snap snap1 created successfully
# gluster snapshot create snap1 vol1 snapshot create: success: Snap snap1_GMT-2015.07.20-10.02.33 created successfully
/var/run/gluster/snaps/<snap-volume-name>/brick<bricknumber>
としてマウントされます。
0888649a92ea45db8c00a615dfc5ea35
のスナップショットには、以下の 2 つのマウントポイントがあります。
/var/run/gluster/snaps/0888649a92ea45db8c00a615dfc5ea35/brick1 /var/run/gluster/snaps/0888649a92ea45db8c00a615dfc5ea35/brick2
# 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
8.3. スナップショットのクローン作成
# gluster snapshot clone <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% です。この設定は、自動削除機能と連携します。自動削除が有効な場合には、ボリュームのスナップショット数がこの制限を超える場合に最も古いスナップショットを削除します。自動削除が無効の場合、スナップショットは削除されませんが、ユーザーに警告メッセージが表示されます。auto-delete
: これにより、自動削除機能が有効または無効になります。デフォルトでは、自動削除は無効になっています。有効にすると、ボリュームのスナップショット数が 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. スナップショットのアクティブ化および非アクティブ化
# gluster snapshot activate <snapname> [force]
- snapname: アクティベートするクォータの名前。
- force: スナップショットボリュームのブリックの一部がダウンしている場合は、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
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 レプリケーションの設定がある場合は、以下の手順を実行してスナップショットを復元します。
- geo レプリケーションセッションを停止します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop
- セカンダリーボリュームを停止し、プライマリーボリュームを停止します。
# gluster volume stop VOLNAME
- セカンダリーボリュームおよびプライマリーボリュームのスナップショットを復元します。
# gluster snapshot restore snapname
- 最初にセカンダリーボリュームを起動し、次にプライマリーボリュームを起動します。
# gluster volume start VOLNAME
- geo レプリケーションセッションを開始します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start
- geo レプリケーションセッションを復元します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL resume
8.11. スナップショットへのアクセス
mount -t glusterfs <hostname>:/snaps/<snapname>/parent-VOLNAME /mount_point
- parent-VOLNAME: スナップショットを作成したボリューム名以下に例を示します。
# mount -t glusterfs myhostname:/snaps/snap1/test_vol /mnt
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. スナップショットスケジューラーのオプション
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"
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 add "Job1" "* * * * *" test_vol snap_scheduler: Successfully added snapshot schedule
Scheduled-Job1-test_vol_GMT-2015.06.19-09.47.01
スナップショットスケジュールの編集
既存のスナップショットスケジュールを編集するには、以下のコマンドを実行します。
snap_scheduler.py edit "Job Name" "Schedule" "Volume Name"
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"
# snap_scheduler.py delete Job1 snap_scheduler: Successfully deleted snapshot schedule
8.13. ユーザーサービス可能なスナップショット
test.txt
ファイルにアクセスするシナリオについて考えてみましょう。ホームディレクトリーにある仮想 .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
ディレクトリーにあります。
# mount -t nfs -o vers=3 server1:/test-vol /mnt/glusterfs
# mount -t glusterfs server1:/test-vol /mnt/glusterfs
.snaps
ディレクトリーは、ls コマンドまたは ls -a
オプションで一覧表示されない仮想ディレクトリーです。.snaps ディレクトリーには、指定したボリューム用に作成されたすべてのスナップショットが個別のディレクトリーとして含まれます。これらのスナップショットエントリーにはそれぞれ、スナップショットの取得時にユーザーがアクセスしている特定のディレクトリーのデータが含まれます。
- スナップショットの取得時にファイルが存在するフォルダーに移動します。たとえば、復元するマウントのルートディレクトリーに test.txt ファイルがある場合には、そのディレクトリーに移動します。
# cd /mnt/glusterfs
注記すべてのディレクトリーには virtual.snaps
ディレクトリーがあるため、ここから.snaps
ディレクトリーを入力できます。.snaps
は仮想ディレクトリーであるため、ls と ls -a コマンドは.snaps
ディレクトリーを一覧表示しません。以下に例を示します。# ls -a ....Bob John test1.txt test2.txt
.snaps
フォルダーに移動します。# cd .snaps
- ls コマンドを実行して、snaps の一覧を表示します。以下に例を示します。
# ls -p snapshot_Dec2014/ snapshot_Nov2014/ snapshot_Oct2014/ snapshot_Sept2014/
- ファイルを取得する必要があるスナップショットディレクトリーに移動します。以下に例を示します。
cd snapshot_Nov2014
# ls -p John/ test1.txt test2.txt
- ファイル/ディレクトリーを希望の場所にコピーします。
# cp -p test2.txt $HOME
8.13.3. Windows Client で CIFS を使用したスナップショットの表示および取得
.snaps
フォルダーで利用できます。.snaps
フォルダーは、次のコマンドを使用してボリュームで以下のオプションが ON
に設定されている場合のみ表示される非表示フォルダーです。
# gluster volume set volname features.show-snapshot-directory on
ON
に設定すると、以下の手順に従ってすべての Windows クライアントは .snaps
フォルダーにアクセスできます。
Folder
オプションで、Show hidden files, folders, and drives
オプションを有効にします。- CIFS 共有のルートに移動し、
.snaps
フォルダーを表示します。注記.snaps
フォルダーには、CIFS 共有のルートからのみアクセスでき、いずれのサブディレクトリーにもアクセスできません。 - スナップショットの一覧は、
.snaps
フォルダーにあります。必要なファイルにアクセスし、取得できるようになりました。
8.14. スナップショットのトラブルシューティング
状況
スナップショットの作成に失敗します。
ステップ 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)
- 以下のコマンドを実行して、デバイスに論理ボリュームプール名があるかどうかを確認します。
lvs device-name
以下に例を示します。# lvs -o pool_lv /dev/mapper/snap_lvgrp-snap_lgvol Pool snap_thnpool
Pool
フィールドが空の場合は、ブリックはシンプロビジョニングされません。 - ブリックがシンプロビジョニングされていることを確認し、スナップショットの作成コマンドを再試行します。
ステップ 2
以下の手順を実行して、ブリックがダウンしているかどうかを確認します。
- 以下のコマンドを実行して、ボリュームのステータスを確認します。
# gluster volume status VOLNAME
- ブリックがダウンしている場合は、以下のコマンドを実行してブリックを起動します。
# gluster volume start VOLNAME force
- ブリックが稼働中かどうかを確認するには、以下のコマンドを実行します。
# gluster volume status VOLNAME
- snapshot create コマンドを再試行します。
ステップ 3
以下の手順に従って、ノードがダウンしているかどうかを確認します。
- 以下のコマンドを実行して、ノードのステータスを確認します。
# gluster volume status VOLNAME
- ブリックがステータスに記載されていない場合は、以下のコマンドを実行します。
# gluster pool list
- 不足しているブリックをホストするノードのステータスが
Disconnected
の場合には、ノードの電源を切ります。 - snapshot create コマンドを再試行します。
ステップ 4
以下の手順に従い、リバランスが進行中かどうかを確認します。
- 以下のコマンドを実行して、リバランスのステータスを確認します。
gluster volume rebalance VOLNAME status
- リバランスが進行中であれば、それが完了するまで待ちます。
- snapshot create コマンドを再試行します。
状況
スナップショットの削除に失敗します。
ステップ 1
以下の手順を実行してサーバークォーラムを満たしているかどうかを確認します。
- 以下のコマンドを実行してピアのステータスを確認します。
# gluster pool list
- ノードがダウンし、クラスターがクォーラムでない場合は、ノードの電源をオンにします。
- クラスターがクォーラムにあることを確認するには、以下のコマンドを実行します。
# gluster pool list
- snapshot delete コマンドを再試行します。
状況
コミットフェーズ中に一部のノードでスナップショットの削除コマンドに失敗し、システムの整合性が保たれます。
解決策
- 削除コマンドに失敗したノードを特定します。この情報は、削除コマンドの出力で利用できます。以下に例を示します。
# 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
- 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 ソフトウェアコンポーネントおよびバージョン』 を参照してください。 - そのノードから
/var/lib/glusterd/snaps/ 内の特定の snaps
リポジトリーを削除します。以下に例を示します。# rm -rf /var/lib/glusterd/snaps/snapshot1
- 以下のコマンドを使用して、そのノードで 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 ソフトウェアコンポーネントおよびバージョン』 を参照してください。 - 1st ステップでコミットが特定に失敗したすべてのノードで 2 番目の、3 番目のステップ、および 4 番目のステップを繰り返します。
- スナップショットの削除を再試行します。以下に例を示します。
# gluster snapshot delete snapshot1
状況
スナップショットの復元に失敗します。
ステップ 1
以下の手順を実行してサーバークォーラムを満たしているかどうかを確認します。
- 以下のコマンドを実行してピアのステータスを確認します。
# gluster pool list
- ノードがダウンし、クラスターがクォーラムでない場合は、ノードの電源をオンにします。
- クラスターがクォーラムにあることを確認するには、以下のコマンドを実行します。
# gluster pool list
- スナップショットの復元コマンドを再試行します。
ステップ 2
以下の手順に従い、ボリュームが
Stop
状態かどうかを確認します。- 以下のコマンドを実行して、ボリューム情報を確認します。
# gluster volume info VOLNAME
- ボリュームが
Started
状態にある場合は、以下のコマンドを使用してボリュームを停止します。gluster volume stop VOLNAME
- スナップショットの復元コマンドを再試行します。
状況
スナップショットコマンドは失敗します。
ステップ 1
以下の手順に従い、オペレーティングシステムのバージョンに不一致があるかどうかを確認します。
- 以下のファイルを開き、操作バージョンを確認します。
/var/lib/glusterd/glusterd.info
operating-version
が 30000 未満の場合、クラスターが動作するバージョンでスナップショットコマンドはサポートされません。 - クラスター内の全ノードを Red Hat Gluster Storage 3.2 以降にアップグレードします。
- snapshot コマンドを再試行します。
状況
ローリングアップグレードの後に、スナップショット機能は機能しません。
解決策
スナップショットを有効にするには、クラスターで以下の変更を加える必要があります。
- 以下のコマンドを使用してボリュームを再起動します。
# gluster volume stop VOLNAME # gluster volume start VOLNAME
- すべてのノードで 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章 ディレクトリークォータの管理
9.1. クォータの有効化および無効化
# gluster volume quota VOLNAME enable
# gluster volume quota VOLNAME disable
quota-remove-xattr.sh
によってボリュームから削除されます。クリーンアッププロセスが実行中にクォータを再度有効にすると、クリーンアッププロセスでクォータを有効にする拡張属性が削除される可能性があります。これは、クォータアカウンティングに悪影響を及ぼすものです。
9.2. ディレクトリーにクォータを設定する前
- gluster volume quota コマンドで制限するディレクトリーを指定すると、ディレクトリーのパスは、ボリュームがマウントされるサーバーまたはクライアントのルートディレクトリーではなく、Red Hat Gluster Storage ボリュームのマウントポイントに対して相対的になります。つまり、Red Hat Gluster Storage ボリュームが
/mnt/glusterfs
にマウントされ、/mnt/glusterfs/dir
ディレクトリーに制限を設定する場合は、以下のように gluster volume quota コマンドを実行する際に/dir
をパスとして使用します。# gluster volume quota VOLNAME limit-usage /dir hard_limit
- gluster volume quota コマンドを実行する際に、レプリカセットごとに少なくとも 1 つのブリックが利用可能であることを確認します。gluster volume status コマンドの出力の
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. ディスク使用量の制限の設定
# gluster volume quota VOLNAME limit-usage path hard_limit
data
ボリュームの /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
# gluster volume quota data limit-usage / 1TB 75
/var/log/glusterfs/bricks/BRICKPATH.log
にあります。
# gluster volume quota data default-soft-limit 90
# gluster volume quota VOLNAME list
9.3.2. 現在のディスク使用量の制限の表示
# gluster volume quota VOLNAME list
# 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
# gluster volume quota VOLNAME list /<directory_name>
# 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 ユーティリティーを使用したクォータ制限情報の表示
quota-deem-statfs
パラメーターを on
に設定すると、代わりにハードクォータ制限をディスク領域の合計として表示するようにボリュームを設定することができます。
quota-deem-statfs
パラメーターを on
に設定するには、以下のコマンドを実行します。
# gluster volume set VOLNAME quota-deem-statfs on
quota-deem-statfs
が off
に設定されている場合にクライアントからのディスク使用量を表示します。
# df -hT /home Filesystem Type Size Used Avail Use% Mounted on server1:/test-volume fuse.glusterfs 400G 12G 389G 3% /home
on
に設定されている場合に、クライアントに表示されるディスク使用量を表示します。
# df -hT /home Filesystem Type Size Used Avail Use% Mounted on server1:/test-volume fuse.glusterfs 300G 12G 289G 4% /home
9.3.3. クォータチェック頻度 (タイムアウト) の設定
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
パラメーターは、ソフト制限に達した後に使用情報をログに記録する方法を設定します。以下のコマンドを使用して、alert-time
を設定できます。
# gluster volume quota VOLNAME alert-time time
1w
) です。
表9.1
時間の単位 | 形式 1 | 形式 2 |
---|---|---|
秒 | [integer]s | [integer]sec |
分 | [integer]m | [integer]min |
時間 | [integer]h | [integer]hr |
日 | [integer]d | [integer]days |
週 | [integer]w | [integer]wk |
# gluster volume quota test-vol alert-time 10m
# gluster volume quota test-vol alert-time 10days
9.3.5. ディスク使用量の制限の削除
# gluster volume quota VOLNAME remove DIR
# gluster volume quota test-volume remove /data volume quota : success
# gluster vol quota VOLNAME remove /
第10章 Geo レプリケーションの管理
10.1. Geo レプリケーションについて
- プライマリー: プライマリー Red Hat Gluster Storage ボリューム。
- セカンダリー: セカンダリー Red Hat Gluster Storage ボリューム。セカンダリーボリュームは、
remote-host::volname
などのリモートホストのボリュームにすることができます。
10.2. 複製されたボリュームと Geo レプリケーション
複製ボリューム | geo-レプリケーション |
---|---|
変更が両方の方向で同期されるように、レプリカセットのすべてのブリック間で機能します。 | プライマリーボリュームからセカンダリーボリュームにのみ機能します。 |
1 つの信頼済みストレージプール内のブリック間でデータをミラーリングします。 | 地理的に分散されている信頼できるストレージプール全体でデータをミラーリングします。 |
高可用性を提供します。 | 障害復旧用のデータバックアップを提供します。 |
同期レプリケーション: 各ファイル操作はすべてのブリックに適用されます。 | 非同期レプリケーション: ファイルの変更を定期的にチェックし、差分の検出時にそれらを同期します。 |
10.3. Geo レプリケーションへのデプロイの準備
10.3.1. Geo レプリケーションデプロイメントシナリオの展開
- LAN 上の geo レプリケーション
- WAN 上の geo レプリケーション
- インターネット上の geo レプリケーション
- 複数のサイトカスケード geo レプリケーション
10.3.2. geo レプリケーションデプロイメントの概要
- お使いの環境が最小システム要件と一致することを確認します。「前提条件」 を参照してください。
- 適切なデプロイメントシナリオを決定します。「Geo レプリケーションデプロイメントシナリオの展開」 を参照してください。
- プライマリーシステムとセカンダリーシステムで geo レプリケーションを開始します。
- 手動の方法は、「Geo レプリケーションの起動」 を参照してください。
- gdeploy メソッドは、「gdeploy を使用した地理レプリケーションセッションの制御」 『でジオレプリケーションセッションの開始』 を参照してください。
10.3.3. 前提条件
- プライマリーボリュームおよびセカンダリーボリュームは、同じバージョンの Red Hat Gluster Storage を使用する必要があります。
- セカンダリーボリュームのノードはプライマリーボリュームの一部にすることはできません。2 つの信頼済みストレージプールが必要です。
- 以下のコマンドを使用して、スレーブボリュームの
performance.quick-read
オプションを無効にします。[slave ~]# gluster volume set slavevol performance.quick-read off
- geo レプリケーションを設定する前に、すべてのプライマリーノードとセカンダリーノード間で時間を同期する必要があります。Red Hat は、ブリックとサーバー間で時刻を同期するようにネットワークタイムプロトコルサービスを設定し、時刻の同期エラーを回避することを推奨します。詳細は、「ネットワーク時刻プロトコルの設定」を参照してください。
- 「ポートアクセスの要件」 に記載されているポートから Geo レプリケーションに必要なポートを追加します。
- プライマリーボリュームの 1 つのノード(geo-replication create コマンドを実行するノード)とセカンダリーボリュームの 1 つのノード( geo-replication create コマンドを実行するノード)の間に、パスワードのないキーベースの SSH 認証が必要です。プライマリーノードで ssh-keygen (パスフレーズなし)を使用して、公開鍵および秘密鍵を作成します。
# ssh-keygen
以下のコマンドを使用して、公開鍵をセカンダリーノードにコピーします。# ssh-copy-id -i identity_file root@slave_node_IPaddress/Hostname
root 以外のジオレプリケーションセッションを設定する場合は、公開鍵をそれぞれのuser
の場所にコピーします。注記- パスワードのない鍵ベースの SSH 認証は、プライマリーノードからセカンダリーノードにのみ必要です。セカンダリーノードは、このレベルのアクセスを必要としません。 - ssh authorized_keys
ファイルがカスタムの場所に設定されていると、ssh-copy-id コマンドは機能しません。マスターから.ssh/id_rsa.pub
ファイルの内容をコピーし、Slave ノードのカスタム場所にある authorized_keys ファイルに貼り付ける必要があります。Gsyncd では、プライマリーノードのすべてのノード間でパスワードなしで、セカンダリークラスター内のすべてのノードへのキーベースの SSH 認証も必要になります。gluster system:: execute gsec_create コマンドは、プライマリー内のすべてのノードにsecret-pem
ファイルを作成し、SSH 認証接続を実装するために使用されます。geo-replication create コマンドの push-pem オプションは、これらの鍵をすべてのスレーブノードにプッシュします。
10.3.4. 環境の設定
- 「Geo レプリケーションセッションの環境の設定」 - この方法では、スレーブマウントは root ユーザーによって所有されます。
- 「セキュアな Geo レプリケーションセカンダリーの環境の設定」 - この方法は、スレーブマウントが通常のユーザーが所有するため、より安全です。
10.3.4.1. Geo レプリケーションセッションの環境の設定
Geo レプリケーションセッションの作成
- 一般的な
pem pub
ファイルを作成し、キーベースの SSH 認証接続が設定されているプライマリーノードで以下のコマンドを実行します。# 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 | +--------------+-------------+---------------+
- 以下のコマンドを使用して 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 オプションを使用して、失敗した検証を無視し、ジオレプリケーションセッションを作成できます。
- セカンダリーボリュームはデフォルトで読み取り専用モードになっています。ただし、フェイルオーバーの状況が発生した場合は、セッションが元のセカンダリーから元のプライマリーに送信されるため、元のプライマリーはデフォルトで読み取り専用になります。
- プライマリーボリュームおよびセカンダリーボリュームに対して共有ストレージを有効にします。
# gluster volume set all cluster.enable-shared-storage enable
共有ストレージについての詳細は、「共有ストレージボリュームの設定」 を参照してください。 - 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 の設定に関する詳細は、「メタボリュームの設定」 を参照してください。 - プライマリーノードで以下のコマンドを実行し、geo レプリケーションを起動します。以下に例を示します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start [force]
- 以下のコマンドを実行して、作成されたセッションのステータスを確認します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL status
10.3.4.2. セキュアな Geo レプリケーションセカンダリーの環境の設定
mountbroker
に依存します。適切な mountbroker's
アクセス制御ディレクティブで glusterd を設定するには、追加の手順を実行する必要があります。このプロセスの例を以下に示します。
- すべてのセカンダリーノードで、新しいグループを作成します。例:
geogroup
注記mountbroker
設定には、複数のグループを使用しないでください。複数のユーザーアカウントを作成できますが、グループは、root 以外のユーザーに対してすべて同じになる必要があります。 - すべてのセカンダリーノードで、権限のないアカウントを作成します。例:
geoaccount
geoaccount
をgeogroup
グループのメンバーとして追加します。 - Slave ノードのいずれかで以下のコマンドを実行し、mountbroker ルートディレクトリーおよびグループを設定します。
# gluster-mountbroker setup <MOUNT ROOT> <GROUP>
以下に例を示します。# gluster-mountbroker setup /var/mountbroker-root geogroup
- Slave ノードのいずれかで以下のコマンドを実行し、ボリュームおよびユーザーを mountbroker サービスに追加します。
# gluster-mountbroker add <VOLUME> <USER>
以下に例を示します。# gluster-mountbroker add slavevol geoaccount
- 以下のコマンドを実行して、設定のステータスを確認します。
# 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 のステータスが表示されます。 - すべての Slave ノードで
Glusterd
サービスを再起動します。# service glusterd restart
すべての Slave ノードで権限のないアカウントの補助 glusterFS マウントを設定したら、以下の手順に従って root 以外の geo レプリケーションセッションを設定します。 - マスターノードのいずれかからスレーブノードの 1 つで
user
鍵ベースの認証を設定します。たとえば、ユーザー geoaccount にキーベースの SSH 認証を設定するには、次のコマンドを実行します。# ssh-keygen # ssh-copy-id -i identity_file geoaccount@slave_node_IPaddress/Hostname
- プライマリーノードで以下のコマンドを実行し、共通の pem pub ファイルを作成します。ここでは、キーベースの SSH 認証接続がセカンダリーノードの
user
に設定されます。# gluster system:: execute gsec_create
- マスターノードで以下のコマンドを実行して、マスターとスレーブ間のジオレプリケーション関係を
user
へ実行します。以下に例を示します。# gluster volume geo-replication MASTERVOL geoaccount@SLAVENODE::slavevol create push-pem
複数のセカンダリーボリュームやアカウントが複数ある場合には、その特定のユーザーやボリュームを使用して地理的なレプリケーションセッションを作成します。以下に例を示します。# gluster volume geo-replication MASTERVOL geoaccount2@SLAVENODE::slavevol2 create push-pem
- プライマリーボリュームおよびセカンダリーボリュームに対して共有ストレージを有効にします。
# gluster volume set all cluster.enable-shared-storage enable
共有ストレージについての詳細は、「共有ストレージボリュームの設定」 を参照してください。 - 関係の作成に使用されるスレーブノードで、ユーザー名、マスターボリューム名、スレーブボリューム名を引数として root として
/usr/libexec/glusterfs/set_geo_rep_pem_keys.sh
を実行します。以下に例を示します。# /usr/libexec/glusterfs/set_geo_rep_pem_keys.sh geoaccount MASTERVOL SLAVEVOL_NAME
- 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 の設定に関する詳細は、「メタボリュームの設定」 を参照してください。 - プライマリーノードで以下のコマンドを実行して、セカンダリーユーザーとして geo レプリケーションを起動します。以下に例を示します。
# gluster volume geo-replication MASTERVOL geoaccount@SLAVENODE::slavevol start
- プライマリーノードで以下のコマンドを実行して、geo レプリケーションセッションのステータスを確認します。
# gluster volume geo-replication MASTERVOL geoaccount@SLAVENODE::slavevol status
セッションの削除後の mountbroker geo レプリケーションオプションの削除
mountbroker 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
# gluster volume geo-replication MASTERVOL geoaccount@SLAVENODE::slavevol status
geoaccount
は、権限のないユーザーアカウントの名前です。
10.3.5. メタボリュームの設定
gluster_shared_storage
は、内部での使用に使用される gluster ボリュームです。use_meta_volume
を true
に設定すると、ワーカーのフェイルオーバーを処理するのに役立つロックファイルを保管するために、geo レプリケーションを使用して共有ボリュームを使用できます。プライマリーボリュームでのノードの障害を効果的に処理するには、geo レプリケーションでこの共有ストレージをクラスターの全ノードで利用できるようにする必要があります。したがって、gluster_shared_storage
という名前の Gluster ボリュームがクラスターに作成され、クラスター内のすべてのノードで /var/run/gluster/shared_storage
にマウントするようにしてください。共有ストレージボリュームの設定についての詳細は、「共有ストレージボリュームの設定」 を参照してください。
- 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
rsync_full_access on
と rsync_client on
ブール値が geo レプリケーションで必要とされる rsync 中にファイル権限の問題を防ぐために、ON に設定されているようにします。
10.4. Geo レプリケーションの起動
10.4.1. Geo レプリケーションセッションの開始
- ホスト間で 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 レプリケーション デプロイメントの確認
# 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 レプリケーションステータス情報の表示
- geo レプリケーションセッションに関する情報をすべて表示するには、以下のコマンドを使用します。
# gluster volume geo-replication status [detail]
- 特定のプライマリーボリュームから geo レプリケーションセッションに関する情報を表示するには、以下のコマンドを使用します。
# gluster volume geo-replication MASTER_VOL status [detail]
- 特定の master-slave セッションの情報を表示するには、以下のコマンドを使用します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL status [detail]
重要データが完全に同期されている場合に、df コマンドの出力 (-h および -k を含む) とプライマリーボリュームおよびセカンダリーボリュームの inode の間に不一致が生じます。これは、changelog
ジャーナリングデータによる追加の inode とサイズ消費によるものです。これは、master
ボリュームのファイルシステムに加えた変更を追跡します。df コマンドを実行して同期のステータスを確認する代わりに、代わりに # gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL status detail ステータスの詳細を使用します。 - geo-replication status コマンドの出力は、以下の情報を提供します。
- Master Node: gluster volume info コマンドの出力に記載されているように、マスターノードとホスト名
- 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 レプリケーションセッションの設定
# 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
!
(感嘆符)を付けます。たとえば、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 and Passive Workers: アクティブなワーカーの数は、ボリューム設定に基づいています。分散ボリュームの場合、すべてのブリック (ワーカー) がアクティブになり、同期に参加します。ボリュームを複製または分散する場合、各複製/通知グループ (サブボリューム) の 1 つのワーカーがアクティブになり、同期に参加します。これにより、他のブリックからの競合を避けることができます。各複製/検出グループ (サブボリューム) の残りのワーカーはパッシブになります。アクティブなワーカーがダウンすると、同じ複製/検出されたグループからのパッシブワーカーの 1 つがアクティブなワーカーになります。
|
ignore_deletes | このオプションを true に設定すると、マスターで削除されたファイルはスレーブで削除操作をトリガーしません。その結果、セカンダリーはプライマリーのスーパーセットとして保持され、クラッシュや誤って削除された場合にプライマリーを復元するために使用できます。このオプションが false (ignore-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_options | rsync の追加オプション。たとえば、rsync 帯域幅の使用量 "--bwlimit=<value>" を制限することができます。 |
use_meta_volume [true | false] | Geo レプリケーションでメタボリュームを使用するには、このオプションを enable にします。デフォルトでは、このオプションは無効となっています。
注記
meta-volume の詳細は、「メタボリュームの設定」 を参照してください。
|
meta_volume_mnt PATH | メタボリュームマウントポイントのパス。 |
gfid_conflict_resolution [true | false] | 自動 GFID 競合解決機能により、プライマリーとセカンダリー間で GFID の競合を自動的に検出および修正できます。この設定オプションを使用すると、この機能を有効または無効にすることができます。デフォルトでは、このオプションは true です。 |
special_sync_mode |
セカンダリーからのデータの復旧をスピードアップします。geo レプリケーションに機能を追加して、インデックスオプションを有効にする前に作成したファイルを無視します。
フェイルオーバーまたはフェイルバックメカニズムの調整パラメーター:
None: gsyncd は通常どおりに動作します。
blind: gsyncd は xtime ペアと連携して、同期候補を特定します。
wrapup: 通常モードと同じですが、xtimes を孤立したファイルに割り当てません。
recover: ファイルは、スレーブで変更された場合にのみ転送されます。
注記
セカンダリー内のファイル数がプライマリーと同じであることを確認した後には、このモードを使用します。geo レプリケーションは、セカンダリーボリュームをプライマリーボリュームとして作成した後に作成されたファイルのみを同期します。
|
10.4.4.1. Geo-replication Checkpoints
10.4.4.1.1. Geo-replication Checkpoints について
10.4.4.1.2. Geo-replication Checkpoint 情報の設定と表示
- geo レプリケーションセッションでチェックポイントを設定するには、以下のコマンドを使用します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config checkpoint
[now|LABEL]
たとえば、Volume1
とstorage.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 status detail
- geo レプリケーションセッションのチェックポイントを削除するには、以下のコマンドを使用します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config '!checkpoint'
たとえば、Volume1
とstorage.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 レプリケーションセッションの停止
- ホスト間の 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 レプリケーションセッションを停止できない場合、コマンドは可能な限り多くのノードで geo レプリケーションセッションを停止します。force を使用すると、非アクティブなジオレプリケーションセッションも停止します。
# gluster volume geo-replication MASTER_VOL geoaccount@SLAVE_HOST::SLAVE_VOL stop
10.4.6. 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
- ボリュームの一部であるノードはオフラインです。
- 特定のノードで geo レプリケーションセッションを削除できない場合。
- プライマリーとセカンダリーの間の geo レプリケーションセッションがアクティブな場合でも、アクティブになります。
/var/lib/glusterd/geo-replication/
ディレクトリーから SSH キーを含む pem
ファイルを手動で削除できます。
# gluster volume geo-replication MASTER_VOL geoaccount@SLAVE_HOST::SLAVE_VOL delete reset-sync-time
10.5. gdeploy を使用した Geo レプリケーションの設定
10.5.1. gdeploy で root ユーザーとして geo レプリケーションを設定
- 一般的な pem pub ファイルの作成
- geo レプリケーションセッションの作成
- メタボリュームの設定
- geo レプリケーションセッションの開始
/usr/share/doc/gdeploy/examples/geo-replication.conf
手順10.1 gdeploy で root ユーザーとして geo レプリケーションを設定
- 以下の場所に、サンプル gdeploy 設定ファイルのコピーを作成します。
/usr/share/doc/gdeploy/examples/geo-replication.conf
- 以下のテンプレートを使用して、設定ファイルの 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]
- 設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf
[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 レプリケーションセッションの設定
- すべてのセカンダリーノードに対して特権のないアカウントを持つ新規グループの作成
- mountbroker の設定
- 一般的な pem pub ファイルの作成
- geo レプリケーションセッションの作成
- メタボリュームの設定
- geo レプリケーションセッションの開始
/usr/share/doc/gdeploy/examples/georep-secure.conf
手順10.2 gdeploy を使用したセキュアな geo レプリケーションセッションの設定
- 以下の場所に、サンプル gdeploy 設定ファイルのコピーを作成します。
/usr/share/doc/gdeploy/examples/georep-secure.conf
- 以下のテンプレートを使用して、設定ファイルの 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]
- 設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf
[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 を使用した地理レプリケーションセッションの制御
/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 を使用した地理レプリケーションセッションの制御
- 以下の場所に、必要な gdeploy サンプル設定ファイルのコピーを作成します。
/usr/share/doc/gdeploy/examples
- 以下のテンプレートを使用して、設定ファイルの 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 ユーザーであることが想定されます。 - 設定ファイルを変更したら、以下のコマンドを使用して設定を呼び出します。
# gdeploy -c txt.conf
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 レプリケーションの起動
- 一般的な
pem pub
ファイルを作成するために、キーベースの SSH 認証接続が設定されているプライマリーノードで以下のコマンドを実行します。# gluster system:: execute gsec_create
- 以下のコマンドを使用して geo レプリケーションセッションを作成します。スレーブノードで必要な
pem-file
設定を実行するには、push-pem とpem-file
オプションが必要です。# 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 の確認、有効なセカンダリーボリューム、およびセカンダリーで利用可能な領域の確認など、セカンダリーの検証を実行します。 - 共有ストレージボリュームの設定後に、新しいノードがクラスターに追加されると、共有ストレージはこのノードに自動的にマウントされません。このノードの共有ストレージ用に
/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/ に変更されました。共有ストレージボリュームの設定についての詳細は、「共有ストレージボリュームの設定」 を参照してください。 - 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 の設定に関する詳細は、「メタボリュームの設定」 を参照してください。 - ノードがセカンダリーに追加される場合は、以下のコマンドを使用して geo レプリケーションセッションを停止します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop
- 以下のコマンドを使用して、セカンダリーとプライマリー間の geo レプリケーションセッションを開始します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start force
- 以下のコマンドを使用して、作成したセッションのステータスを確認します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL status
警告以下のシナリオでは、チェックサムの不一致が発生する可能性があります。- ブリックを追加して、geo レプリケートされたボリュームを拡張する。
- geo レプリケーションの同期中にボリュームを拡張する。
- 新たに追加されたブリックがデータを同期するために 'ACTIVE' になる。
- 新しいブリックの自己修復が完了しない。
10.6.2. 既存ノードでの新規ブログの Geo レプリケーションの開始
10.6.3. 新規ボリュームの Geo レプリケーションの起動
前提条件
- プライマリーボリュームノードとセカンダリーボリュームノード間でパスワードアクセスがなくても、キーベースの SSH 認証が必要です。
- 以下のコマンドを使用して geo レプリケーションセッションを作成します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL create
以下に例を示します。# gluster volume geo-replication Volume1 storage.backup.com::slave-vol create
注記このコマンドは、有効なセカンダリー URL の確認、有効なセカンダリーボリューム、およびセカンダリーで利用可能な領域の確認など、セカンダリーの検証を実行します。 - 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 の設定に関する詳細は、「メタボリュームの設定」 を参照してください。 - 以下のコマンドを使用して、セカンダリーとプライマリー間の geo レプリケーションセッションを開始します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start
- 以下のコマンドを使用して、作成したセッションのステータスを確認します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL status
10.7. Cron ジョブとしての Geo レプリケーションのスケジューリング
- geo レプリケーションセッション (開始されている場合) を停止します。
- geo レプリケーションセッションを開始します。
- チェックマークを設定します。
- 完了するまでチェックポイントのステータスを確認します。
- チェックポイントが完了したら、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
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. 障害復旧
failover
の手順を実行できます。この場合、読み取りおよび書き込みを含むすべての I/O 操作は、現在プライマリーとして機能するセカンダリーで行われます。元のプライマリーがオンラインに戻ると、元のセカンダリーで failback
手順を実行し、元のプライマリーとの違いを同期できます。
10.8.1. フェイルオーバー: セカンダリーのプライマリーへのプロモート
- 以下のコマンドを実行して、セカンダリーボリュームで読み取り専用を無効にします。
# gluster volume set VOLNAME features.read-only off
- セカンダリーマシンで以下のコマンドを実行し、これをプライマリーにプロモートします。
# 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
10.8.2. フェイルバック: Master と Slave を元の状態に戻す
- 以下のコマンドを使用して、既存の geo-rep セッションを元のプライマリーから組織セカンダリーに停止します。
# gluster volume geo-replication ORIGINAL_MASTER_VOL ORIGINAL_SLAVE_HOST::ORIGINAL_SLAVE_VOL stop
force
以下に例を示します。# 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
- 新しいマスターとして、元のスレーブで新しいジオレプリケーションセッションを作成し、元のマスターを新しいスレーブとして force オプションを指定して作成します。geo レプリケーションセッションの作成に関する詳細は、以下を参照してください。
- 特別な同期モードを開始し、セカンダリーからのデータ復旧を迅速化します。このオプションは、
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
- 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
- 以下のコマンドを使用して、新しい 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
- 元のセカンダリーで 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
- チェックポイントの完了により、元のセカンダリーからのデータが元のプライマリーに復元されます。しかし、チェックポイントを設定する前に、セカンダリーで 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
- チェックポイントが完了したら、元のセカンダリーと元のプライマリーとの間で現在の 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
- 以下のコマンドを実行して、プライマリーボリュームで読み取り専用を無効にします。
# gluster volume set VOLNAME features.read-only off
- 以下のコマンドを実行して、セカンダリーボリュームをプライマリーボリュームとしてプロモートするように設定したオプションをリセットします。
# 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
- 以下のコマンドを使用して、元のプライマリーから 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 レプリケートボリュームのスナップショットの作成
# 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.
10.10. 例: カスケード geo レプリケーションの設定
- お使いの環境が、「前提条件」 に記載の最小システム要件と一致することを確認します。
- 適切なデプロイメントシナリオを決定します。デプロイメントシナリオの詳細は、「Geo レプリケーションデプロイメントシナリオの展開」 を参照してください。
- 環境を設定し、master-vol と monthlymaster-vol との間でジオプリケーションセッションを作成します。
- 一般的な pem pub ファイルを作成し、キーベースの SSH 認証接続が設定されているプライマリーノードで以下のコマンドを実行します。
# gluster system:: execute gsec_create
- 以下のコマンドを使用して geo レプリケーションセッションを作成します。push-pem オプションは、minutemaster ノードで必要な pem-file 設定を実行するために必要です。
# gluster volume geo-replication master-vol interimhost.com::interimmaster-vol create push-pem
- 以下のコマンドを実行して、作成されたセッションのステータスを確認します。
# gluster volume geo-replication master-vol interimhost::interimmaster-vol status
- geo レプリケーションのメタボリュームを設定します。
# gluster volume geo-replication master-vol interimhost.com::interimmaster-vol config use_meta_volume true
meta-volume の設定に関する詳細は、「メタボリュームの設定」 を参照してください。 - ホスト間の Geo-replication セッションを開始します。
# gluster volume geo-replication master-vol interimhost.com::interimmaster-vol start
このコマンドは、プライマリーボリュームの一部であるすべてのノードで、geo レプリケーションを開始します。プライマリーボリュームの一部であるノードがダウンしても、コマンドは正常に行われます。レプリカのペアでは、geo レプリケーションセッションはレプリカノードのいずれかでアクティブになりますが、他のレプリカノードでもパッシブになります。コマンドの実行後、セッションを初期化し、安定した状態になるまで数分の時間がかかる場合があります。 - 以下のコマンドを実行して、geo レプリケーションセッションのステータスを確認します。
# gluster volume geo-replication master-vol interimhost.com::interimmaster-vol status
- periodicmaster-vol と slave-vol との間に geo レプリケーションセッションを作成します。
- キーベースの SSH 認証接続が設定されている minutemaster プライマリーノードで以下のコマンドを実行して、共通の pem pub ファイルを作成します。
# gluster system:: execute gsec_create
- Periodicmaster ノードで、以下のコマンドを使用して geo レプリケーションセッションを作成します。セカンダリーノードで必要な pem-file を設定するには、push-pem オプションが必要です。
# gluster volume geo-replication interimmaster-vol slave_host.com::slave-vol create push-pem
- 以下のコマンドを実行して、作成されたセッションのステータスを確認します。
# gluster volume geo-replication interrimmaster-vol slave_host::slave-vol status
- geo レプリケーションのメタボリュームを設定します。
# gluster volume geo-replication interrimmaster-vol slave_host::slave-vol config use_meta_volume true
meta-volume の設定に関する詳細は、「メタボリュームの設定」 を参照してください。 - 以下のコマンドを実行して、interrimaster-vol と slave-vol 間で geo レプリケーションセッションを開始します。
# gluster volume geo-replication interrimmaster-vol slave_host.com::slave-vol start
- 以下を実行して、geo レプリケーションセッションのステータスを確認します。
# gluster volume geo-replication interrimmaster-vol slave_host.com::slave-vol status
10.11. 推奨されるプラクティス
時間を手動で設定
ブリックの時間を手動で変更する必要がある場合は、すべてのブリックに時間を設定する際には、geo レプリケーションセッションとインデックスを無効にする必要があります。ジオメトリー環境内のブリックはすべて、「Geo レプリケーションセッションの環境の設定」 で説明している同期の問題を回避するため、同じタイミングに設定する必要があります。ブリックは同時に動作しないか、geo レプリケーションが実行中の時間を変更すると、geo レプリケーションのインデックスが破損します。手動で時間を設定するのに推奨される方法は、以下の手順を使用することです。
Geo レプリケーション環境におけるブログ時の時間を手動で設定
- 以下のコマンドを使用して、プライマリーとセカンダリー間の geo レプリケーションを停止します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop
- 以下のコマンドを使用して、geo レプリケーションのインデックスを停止します。
# gluster volume set MASTER_VOL geo-replication.indexing off
- すべてのブリックに統一された時間を設定します。
- 以下のコマンドを使用して geo レプリケーションセッションを再起動します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start
パフォーマンスチューニング
次のオプションが設定されていると、geo レプリケーションのパフォーマンスが増えていることが確認されます。セカンダリーボリュームで、以下のコマンドを実行します。
# gluster volume set SLAVE_VOL batch-fsync-delay-usec 0
LAN を使用したリモートのセカンダリーに大きなボリュームを複製
リモートの場所にあるセカンダリーに大容量のボリュームを複製するには、ローカルエリアネットワーク (LAN) でローカルに初期レプリケーションを実行し、ディスクをリモートロケーションに物理的に転送することが役に立つ場合があります。これにより、低速で高コストの大きいエリアネットワーク (WAN) 接続で、ボリューム全体の最初のレプリケーションを行う必要がなくなります。以下の手順では、ローカルの地理レプリケーションセッションを設定し、ディスクを物理的にリモートの場所に転送し、WAN で ge レプリケーションを設定する方法を説明します。
初期の LAN を使用したリモートセカンダリーへの複製
- LAN に、geo レプリケーションセッションをローカルに作成します。ジオレプリケーションセッションの作成方法は、「Geo レプリケーションセッションの環境の設定」 を参照してください。重要セカンダリーボリュームの作成時にブリック/ディスクが指定されている順序を記憶する必要があります。この情報は、WAN 経由でリモートの geo レプリケーションセッションを設定する際に後で必要になります。
- プライマリーの初期データがセカンダリーボリュームに同期されていることを確認します。「Geo レプリケーションステータス情報の表示」 に示すように、sutatus コマンドを使用して同期のステータスを確認することができます。
- geo レプリケーションセッションを停止して削除します。geo レプリケーションセッションを停止して削除する方法は、「Geo レプリケーションセッションの停止」 および 「Geo レプリケーションセッションの削除」 を参照してください。重要
/var/lib/glusterd/geo-replication/
に古いファイルがないことを確認する必要があります。 - セカンダリーボリュームを停止して削除します。ボリュームの停止および削除についての詳細は、「ボリュームの停止」 および 「ボリュームの削除」 を参照してください。
- セカンダリーノードからディスクを削除し、リモートの場所に物理的に転送します。ボリューム内にディスクが指定されていた順序を忘れないようにしてください。
- リモートの場所で、ディスクをアタッチしてセカンダリーノードにマウントします。ファイルシステムまたは論理ボリュームマネージャーが認識され、マウント後にデータにアクセスできることを確認します。
- peer probe コマンドを使用して、スレーブに信頼できるストレージプールを設定します。信頼できるストレージプールの設定方法は、4章信頼できるストレージプールへのサーバーの追加 を参照してください。
- ブリックで glusterFS 関連の属性を削除します。これは、ボリュームを作成する前に行う必要があります。glusterFS 関連の属性を削除するには、以下のコマンドを実行します。
# for i in `getfattr -d -m . ABSOLUTE_PATH_TO_BRICK 2>/dev/null | grep trusted | awk -F = '{print $1}'`; do setfattr -x $i ABSOLUTE_PATH_TO_BRICK; done
以下のコマンドを実行して、ブリックにxattrs
がまだ設定されていないことを確認します。# getfattr -d -m . ABSOLUTE_PATH_TO_BRICK
- 信頼できるストレージプールを作成したら、LAN にあるときと同じ設定で Red Hat Gluster Storage ボリュームを作成します。ボリュームの作成方法は、5章ストレージボリュームの設定 を参照してください。重要必ず、LAN では以前と同じ順序でブリックを指定してください。ブリック順序の仕様に一致しないと、データの損失や破損につながる可能性があります。
- ボリュームを起動してマウントし、データがそのままでアクセス可能なかどうかを確認します。ボリュームの起動およびマウントに関する情報は、「ボリュームの起動」 および 6章ボリュームへのアクセスの作成 を参照してください。
- 環境を設定し、プライマリーからこのリモートセカンダリーに geo レプリケーションセッションを作成します。環境を設定し、geo レプリケーションセッションを作成する方法は、「Geo レプリケーションセッションの環境の設定」 を参照してください。
- プライマリーとリモートセカンダリーとの間で、geo レプリケーションセッションを開始します。geo レプリケーションセッションを開始する方法は、「Geo レプリケーションの起動」 を参照してください。
- status コマンドを使用してセッションのステータスを確認し、セッション内のすべてのノードが安定しているかどうかを確認します。status の詳細は、「Geo レプリケーションステータス情報の表示」 を参照してください。
10.12. Geo レプリケーションのトラブルシューティング
10.12.1. ログの変更による Geo レプリケーションパフォーマンスの調整
rollover-time
オプションは、変更ログが消費される速度を設定します。デフォルトのロールオーバー時間は 15 秒ですが、高速レートに設定できます。推奨されるロールオーバータイムは 10 - 15 秒です。rollover-time
オプションを変更するには、以下のコマンドを使用します。
# gluster volume set VOLNAME rollover-time 15
fsync-interval
オプションは、変更ログへの更新頻度がディスクに書き込まれるかどうかを判断します。デフォルトの間隔は 5 です。これは、変更ログの更新が発生すると同期的に書き込まれることを意味します。これは、geo レプリケーション環境でパフォーマンスに悪影響を与える可能性があります。fsync-interval
をゼロ以外の値に設定すると、更新を指定された間隔で非同期的にディスクに書き込みます。fsync-interval
オプションを変更するには、以下のコマンドを使用します。
# gluster volume set VOLNAME fsync-interval 5
10.12.2. エントリーでの明示的な同期のトリガー
# setfattr -n glusterfs.geo-rep.trigger-sync -v "1" <file-path>
10.12.3. 同期が完了していません
状況
geo レプリケーションのステータスは Stable
と表示されますが、データが完全に同期されていません。
解決策
データのフル同期は、インデックスを消去し、geo レプリケーションを再起動することで実行できます。geo レプリケーションを再起動した後、チェックサムを使用してデータの同期を開始します。これは、データセットで長期かつリソース集約的なプロセスである可能性があります。問題が解決しない場合は、Red Hat サポートにお問い合わせください。
10.12.4. ファイル同期の問題
状況
Geo レプリケーションステータスは Stable
と表示されますが、ディレクトリーとシンボリックリンクのみが同期されます。以下のようなエラーメッセージがログに表示されます。
[2011-05-02 13:42:13.467644] E [master:288:regjob] GMaster: failed to sync ./some_file`
解決策
Geo レプリケーションでは、ホストおよびリモートマシンで rsync
v3.0.0 以降が必要です。必要なバージョンの rsync
がインストールされているかどうかを確認します。
10.12.5. geo レプリケーションステータスが頻繁に Faulty
になる
状況
Geo-replication のステータスが Faulty
と表示され、以下のようなバックトレースが表示されます。
012-09-28 14:06:18.378859] E [syncdutils:131:log_raise_exception] <top>: FAIL: Traceback (most recent call last): File "/usr/local/libexec/glusterfs/python/syncdaemon/syncdutils.py", line 152, in twraptf(*aa) File "/usr/local/libexec/glusterfs/python/syncdaemon/repce.py", line 118, in listen rid, exc, res = recv(self.inf) File "/usr/local/libexec/glusterfs/python/syncdaemon/repce.py", line 42, in recv return pickle.load(inf) EOFError
解決策
これは通常、プライマリー gsyncd モジュールとセカンダリー gsyncd モジュール間の RPC 通信が破損していることを示しています。以下の前提条件を満たしていることを確認します。
- キーベースの SSH 認証がホストとリモートマシンの間で適切に設定されている。
- Fuse がマシンにインストールされている。geo-replication モジュールは、FUSE を使用してデータを同期するために Red Hat Gluster Storage ボリュームをマウントします。
10.12.6. 中間プライマリーが障害状態になる
状況
関心のある環境では、中間プライマリーは傷害状態であり、以下のようなメッセージがログにあります。
raise RuntimeError ("aborting on uuid change from %s to %s" % \ RuntimeError: aborting on uuid change from af07e07c-427f-4586-ab9f- 4bf7d299be81 to de6b5040-8f4e-4575-8831-c4f55bd41154
解決策
カスケード設定では、中間プライマリーは元のプライマリープライマリーに忠実です。上記のログメッセージは、geo レプリケーションモジュールがプライマリープライマリーが変更されたことを検知したことを示します。この変更が非推奨である場合は、中間プライマリーから開始されたセッションの volume-id
設定オプションを削除します。
10.12.7. リモート gsyncd が見つかりません
状況
プライマリーは不具合のある状態であり、以下のようなメッセージがログにあります。
[2012-04-04 03:41:40.324496] E [resource:169:errfail] Popen: ssh> bash: /usr/local/libexec/glusterfs/gsyncd: No such file or directory
解決策
geo レプリケーション用に SSH 接続を設定する手順が更新されました。「Geo レプリケーションセッションの環境の設定」 の説明通りに手順を使用する。
第11章 Red Hat Gluster Storage ボリュームの管理
11.1. ボリュームオプションの設定
# gluster volume info VOLNAME
# gluster volume set VOLNAME OPTION PARAMETER
test-volume
のパフォーマンスキャッシュサイズを指定するには、以下を 実行します。
# gluster volume set test-volume performance.cache-size 256MB volume set: success
# gluster volume reset VOLNAME OPTION_NAME
test-volume
changelog
オプションをリセットするには、次のコマンドを実行します。
# gluster volume reset test-volume changelog volume set: success
11.2. 複数のボリュームオプションの設定
グループ設定ファイルの作成
/var/lib/glusterd/groups/
ディレクトリーに新しいファイルを作成します。# touch /var/lib/glusterd/groups/filename
- ボリュームに設定するパラメーターと値をキーと値のペアとして作成したファイルに追加し、各パラメーターを新しい行に配置します。
domain1.key1=value1 domain1.key2=value2 domain2.key3=value3
以下に例を示します。changelog.changelog=on client.event-threads=6 cluster.brick-multiplex=on
ボリュームへの設定の追加
# gluster volume set volname group filename
# gluster volume set volume1 group virt # gluster volume set volume2 group virt # gluster volume set volume3 group dbgroup
11.3. サポートされるボリュームオプション
表11.1 ボリュームのオプション
オプション | 値の説明 | 許可される値 | デフォルト値 |
---|---|---|---|
auth.allow | ボリュームにアクセスできるクライアントの IP アドレスまたはホスト名。 | * を含むワイルドカードパターンを含む、有効なホスト名または IP アドレス。例: 192.168.1.* コンマで区切ったアドレスのリストは受け入れ可能ですが、1 つのホスト名を 256 文字を超えることはできません。 | * (すべて許可) |
auth.reject |
ボリュームへのアクセスが拒否された FUSE クライアントの IP アドレスまたはホスト名。NFS アクセス制御の場合は、代わりに
nfs.rpc-auth-* オプションを使用します。
auth.reject が優先され、auth.allow を上書きします。auth.allow と auth.reject に同じ IP アドレスが含まれる場合は、auth.reject を考慮します。
| * を含むワイルドカードパターンを含む、有効なホスト名または IP アドレス。例: 192.168.1.* コンマで区切ったアドレスのリストは受け入れ可能ですが、1 つのホスト名を 256 文字を超えることはできません。 | none (拒否なし) |
changelog | changelog トランスレーターがすべてのファイル操作を記録できるようにします。 | on | off | off |
client.event-threads | Red Hat Gluster Storage ノードにアクセスするクライアントプロセスで同時に処理されるネットワーク接続の数を指定します。 | 1 - 32 | 2 |
client.strict-locks | このオプションを有効にすると、POSIX ロックが保持されていれば、再接続後に保存された fds を再度開きません。したがって、これらの fds での後続の操作は失敗します。これは、クライアントが切断されたときに、許可されたロックのブリック消去としてより厳格なロックコンプライアンスに必要です。 | on | off | off |
重要 client.strict-locks オプションを有効にする前に、すべてのサーバーとクライアントを RHGS-3.5.5 にアップグレードします。
| |||
cluster.background-self-heal-count | 同時に発生する可能性がある最大の修復操作数。この数の過半数を超える要求は、cluster.heal-wait-queue-leng によって定義される長さがキューに保存されます。 | 0–256 | 8 |
cluster.brick-multiplex |
Red Hat Gluster Storage 3.3 以降で利用可能です。すべてのボリュームでブリック多重化を使用するかどうかを制御します。Red Hat は、ブリックマルチプレッシングを有効または無効にすると、ボリュームを再起動することを推奨します。
off (デフォルト) に設定すると、各ブリックには独自のプロセスがあり、独自のポートを使用します。on に設定すると、相互に互換性のあるブリックは同じプロセスとポートを使用します。これにより、ブリックメモリーごとの使用量とポートの消費が減ります。
ブリック互換性は、ボリュームの開始時に決定され、ブリック間で共有されるボリュームオプションにより異なります。多重化が有効な場合は、1 つのプロセスでグループ化されたブリックの互換性を維持するために、ボリューム設定が変更されるたびに再起動します。
| on | off | off |
cluster.consistent-metadata | on に設定すると、Automatic File Replication 機能の readdirp 関数は、ファイル/ディレクトリーの適切なコピー (修復しないコピー) を保持している限り、それぞれの読み取り子からメタデータを常にフェッチします。ただし、これにより、readdirps が関与するパフォーマンスが低下する可能性があります。
このオプションでは、ボリュームがクライアントに再マウントされる必要があります。
| on | off | off |
cluster.granular-entry-heal |
有効にすると、レプリカのブリックがダウンされている間に、ディレクトリーから作成、または削除されたエントリーに関するより詳細な情報を保存します。これは、特に多数のエントリーを持つディレクトリーがエントリーの作成または削除によって変更される場合に、ディレクトリーの自己修復に役立ちます。disable に設定すると、ディレクトリー内のどのエントリーを修復する必要があるかについての情報なしに、ディレクトリー修復の必要性情報を保存するため、変更を特定するにはディレクトリー全体が必要になります。
| enable | disable | enable |
重要
gluster volume set VOLNAME cluster.granular-entry-heal [enable | disable] コマンドは、ボリュームが Created 状態にある場合にのみ実行します。ボリュームが Created 以外の状態にある場合(例: Started 、Stopped など)、gluster volume heal VOLNAME granular-entry-heal [enable | disable] コマンドを実行して、granular-entry-heal オプションを有効または無効にします。
重要
新規デプロイメントおよび Red Hat Gluster Storage 3.5.4 にアップグレードする既存デプロイメントの場合、 cluster.granular-entry-heal オプションはデフォルトで複製ボリュームに対して有効になります。
| |||
cluster.heal-wait-queue-leng | cluster.background-self-heal-count と同等の修復操作がすでに進行中である heal 操作の最大要求数。このキューが満杯になると、それら修復リクエストは無視されます。 | 0-10000 | 128 |
cluster.lookup-optimize |
このオプションを
on に設定すると、ハッシュされたサブボリュームがルックアップの結果が返されない場合は、ハッシュのないサブボリュームを検索し、ネガティブルックアップが最適化されます。
既存のボリュームでは、アップグレード後に作成されたディレクトリーでルックアップの最適な動作が有効になります。リバランス操作は、ルックアップの最適化を使用するには、既存のすべてのディレクトリーで実行する必要があります。
新規ボリュームでは、ボリュームのルートを除き、lookup-optimize 動作がデフォルトで有効になります。ボリュームのルートの lookup-optimize を有効にするには、リバランス操作を実行します。
| on|off | on (Red Hat Gluster Storage 3.4 以降) |
cluster.max-bricks-per-process |
glusterfsd プロセスの 1 つのインスタンスで実行可能なブリックの最大数。
Red Hat Gluster Storage 3.4 Batch 2 Update の時点で、このオプションのデフォルト値が
250 に設定されます。これにより、コンテナーベースのワークロードのリソース使用状況をより適切に制御できます。以前のバージョンでは、デフォルト値は 0 で、ノード上のすべてのブリックに単一のプロセスを使用していました。
このオプションの値を更新しても、現在実行中のブリックには影響しません。ボリュームを再起動して、既存のブリックのこの設定を変更します。
| 0 からシステムの最大値 (1 以上の正の整数) | 250 |
cluster.min-free-disk | 空き領域を解放する必要があるディスク領域の割合を指定します。これは、単項以外のブリックに役立ちます。 | 必要な最小ディスクの空き容量の割合。 | 10% |
cluster.op-version | クラスターのオペレーティングバージョンを設定できます。op-version 番号はダウングレードできず、クラスター内のすべてのボリュームに設定されます。op-version は、gluster volume info コマンドの出力の一部として一覧表示されません。 | 30708 | 30712 | 31001 | 31101 | 31302 | 31303 | 31304 | 31305 | 31306 | 70200 | デフォルト値は、最初にインストールした Red Hat Gluster Storage バージョンによって異なります。Red Hat Gluster Storage 3.5 では、新しいデプロイメント用に値は 70200 に設定されます。 |
cluster.read-freq-threshold | 昇格/降格サイクルで読み取りの数を指定します。これは、昇格のために HOT をマークします。ヒット数がこの値よりも小さいファイルは COLD として考慮され、降格されます。 | 0-20 | 0 |
cluster.self-heal-daemon | レプリケートしたボリュームに対するプロアクティブな自己修復がアクティベートするかどうかを指定します。 | on | off | on |
cluster.server-quorum-ratio | 信頼できるストレージプールのクォーラムパーセンテージを設定します。 | 0 - 100 | >50% |
cluster.server-quorum-type | server に設定すると、指定したボリュームがサーバー側のクォーラムに参加できるようになります。server-side quorum を設定する方法は、「サーバー側のクォーラムの設定」を参照 | none | server | none |
cluster.quorum-count | 書き込みを許可するために使用できる必要があるブリックの最小数を指定します。これはボリュームごとに設定されます。このオプションは、書き込み動作を決定するために cluster.quorum-type オプションによって使用されます。 | 有効な値は、1 からレプリカセットのからブリックの数になります。 | null |
cluster.quorum-type | クライアントがボリュームへの書き込みを許可されるタイミングを決定します。client-side quorum を設定する方法は、「クライアント側クォーラムの設定」を参照 | none | fixed | auto | auto |
cluster.shd-max-threads | self-heal デーモンにより、各レプリカで並行して自己修復できるエントリーの数を指定します。 | 1 - 64 | 1 |
cluster.shd-max-threads | self-heal デーモンにより、各レプリカで並行して自己修復できるエントリーの数を指定します。 | 1 - 64 | 1 |
cluster.shd-wait-qlength | スレッドのいずれかが解放されるとすぐに起動するように、自己修復デーモンスレッドがキューに保持する必要のあるエントリーの数を指定します。この値は、次のエントリーセットを修復するために必要なメモリー自己修復デーモンプロセスのサイズに応じて変更する必要があります。 | 1 - 655536 | 1024 |
cluster.shd-wait-qlength | スレッドのいずれかが解放されるとすぐに起動するように、自己修復デーモンスレッドが分散サブボリュームのキューに保持する必要のあるエントリーの数を指定します。この値は、次のエントリーセットを修復するために必要なメモリー自己修復デーモンプロセスのサイズに応じて変更する必要があります。 | 1 - 655536 | 1024 |
cluster.tier-demote-frequency | tier デーモンが降格するファイルを確認する頻度を指定します。 | 1 - 172800 秒 | 3600 秒 |
cluster.tier-max-files | 特定のサイクルの任意の方向の移行が可能なファイルの最大数を指定します。 | 1-100000 ファイル | 10000 |
cluster.tier-max-mb | 特定のサイクルの任意の方向の移行が可能な最大 MB 数を指定します。 | 1 -100000 (100 GB) | 4000 MB |
cluster.tier-mode | cache モードに設定すると、ウォーターマークで指定されたとおりに、キャッシュが満杯かどうかに基づいてファイルをプロモートまたは降格します。test モードに設定すると、アクセスに基づいて定期的にファイルを降格またはプロモートします。 | test | cache | キャッシュ |
cluster.tier-promote-frequency | tier デーモンがファイルをプロモートする頻度を指定します。 | 1- 172800 秒 | 120 秒 |
cluster.use-anonymous-inode | 有効にすると、エントリー修復関連の問題を処理し、ディレクトリーの名前を効率的に修復します。 | on|off | on(Red Hat Gluster Storage 3.5.4 以降) |
cluster.use-compound-fops | 有効にすると、自動ファイルレプリケーションの一部として発生するトランザクションを書き込み、ネットワークラウンドトリップを削減し、パフォーマンスが向上します。 | on | off | off |
cluster.watermark-hi | プロモーションの上限ウォーターマーク。ホット層がこのパーセンテージを超える場合、昇格は発生せず、高い可能性で降格が発生します。 | 1- 99 % | 90% |
cluster.watermark-low | 基準の割合が低いhot layer が満杯でない場合は、昇格が発生し、降格は発生しません。これよりも大きい場合は、hot layer がどの程度完全なかに対比して昇格/降格が発生します。 | 1- 99 % | 75% |
cluster.write-freq-threshold | 昇格/降格サイクルにおいて、昇格のためにファイル HOT をマークする書き込みの数を指定します。この値よりも小さい書き込みヒットは COLD として考慮され、降格されます。 | 0-20 | 0 |
config.transport | ボリュームが通信をサポートするトランスポートのタイプを指定します。 | tcp OR rdma OR tcp,rdma | tcp |
diagnostics.brick-log-buf-size | タイムアウトまたはバッファーオーバーフローのいずれかがブリックで最初に発生するまで抑制できる一意のログメッセージの最大数。 | 0 および 20 (0 と 20 を含む) | 5 |
diagnostics.brick-log-flush-timeout | ログメッセージがバッファーされる期間。この期間。この間、ブリック上のロギングインフラストラクチャー (gluster または syslog ファイル) にフラッシュされます。 | 30 - 300 秒 (30 および 300 が含まれる) | 120 秒 |
diagnostics.brick-log-format | ログ形式を、メッセージ ID あり、またはブリックにメッセージなしでログを記録するように設定できます。 | no-msg-id | with-msg-id | with-msg-id |
diagnostics.brick-log-level | ブリックのログレベルを変更します。 | INFO | DEBUG | WARNING | ERROR | CRITICAL | NONE | TRACE | info |
diagnostics.brick-sys-log-level | このオプションに定義された値に応じて、定義されたレベルのログメッセージが syslog と brick ログファイルで生成されます。 | INFO | WARNING | ERROR | CRITICAL | CRITICAL |
diagnostics.client-log-buf-size | タイムアウトまたはバッファーオーバーフローのいずれかがクライアントで最初に発生するまで抑制できる一意のログメッセージの最大数。 | 0 および 20 (0 と 20 を含む) | 5 |
diagnostics.client-log-flush-timeout | ログメッセージがバッファーされる期間。この期間。この間、クライアント上のロギングインフラストラクチャー (gluster または syslog ファイル) にフラッシュされます。 | 30 - 300 秒 (30 および 300 が含まれる) | 120 秒 |
diagnostics.client-log-format | メッセージ ID またはクライアント上のメッセージなしでログに記録するようにログ形式を設定できます。 | no-msg-id | with-msg-id | with-msg-id |
diagnostics.client-log-level | クライアントのログレベルを変更します。 | INFO | DEBUG | WARNING | ERROR | CRITICAL | NONE | TRACE | info |
diagnostics.client-sys-log-level | このオプションに定義された値に応じて、定義されたレベルのログメッセージが syslog とクライアントログファイルで生成されます。 | INFO | WARNING | ERROR | CRITICAL | CRITICAL |
disperse.eager-lock | ファイルの操作を開始する前に、ロックがファイルに配置されます。ロックは、ファイル操作が完了するまでそのまま有効になります。ファイル操作が完了したら、eager-lock がオンになっても、ロック競合が検出されるまで、または 1 秒間同じクライアントからそのファイルに別の要求があるかどうかを確認するためにロックが残ります。eager-lock がオフになっていると、ファイル操作の完了直後にロックがリリースされ、一部の操作のパフォーマンスが改善されますが、アクセス効率が低下します。 | on | off | on |
disperse.other-eager-lock | このオプションは disperse.eager-lock オプションと同じですが、通常のファイルにのみ適用されます。複数のクライアントが特定のディレクトリーにアクセスする場合は、ボリュームに disperse.other-eager-lockoption を無効にすると、通常のファイルに対する I/O のパフォーマンス低下することなく、ディレクトリーアクセスのパフォーマンスを改善できます。 | on | off | on |
disperse.other-eager-lock-timeout | エントリーの新しい操作が受信されない場合、通常のエントリーのロックが保持される最大時間 (秒単位)。 | 0-60 | 1 |
disperse.shd-max-threads | self-heal デーモンによって、分散された各サブボリュームで並行して自己修復できるエントリーの数を指定します。 | 1 - 64 | 1 |
disperse.shd-wait-qlength | スレッドのいずれかが解放されるとすぐに起動するように、自己修復デーモンスレッドが分散サブボリュームのキューに保持する必要のあるエントリーの数を指定します。この値は、次のエントリーセットを修復するために必要なメモリー自己修復デーモンプロセスのサイズに応じて変更する必要があります。 | 1 - 655536 | 1024 |
features.ctr_link_consistency | Change Time Recorder トランスレーターにより、ハードリンクの更新を記録するクラッシュの一貫した方法を有効にします。データ操作によってレイテンシーが高まるように、クラッシュで録画すると、より多くのレイテンシーが発生します。 | on | off | off |
features.ctr-enabled | 階層化されたボリュームで Time Recorder (CTR) トランスレーターの変更を有効にします。このオプションは features.record-counters オプションと併用して、書き込みと読み取りの heat カウンターを記録します。 | on | off | on |
features.locks-notify-contention | このオプションを有効にすると、ロック要求が現在の許可されたロックと競合すると、即座にリリースするよう、ロックの現在の所有者に upcall 通知が送信されます。 | yes | no | はい |
features.locks-notify-contention-delay | この値は、同じ inode 上の upcall 競合通知間の最小時間 (秒単位) を指定します。この期間に複数のロックリクエストを受け取ると、upcall は 1 つだけ送信されます。 | 0-60 | 5 |
features.quota-deem-statfs (非推奨)
詳細は、9章ディレクトリークォータの管理 を参照してください。
| このオプションを on に設定すると、ファイルシステムのサイズを見積もる間にクォータ制限が考慮されます。この制限は、ファイルシステムの実際のサイズではなく合計サイズとして処理されます。 | on | off | on |
features.read-only | ボリューム全体を、そのボリュームにアクセスするすべてのクライアントに対して読み取り専用としてマウントするかどうかを指定します。 | on | off | off |
features.record-counters | enabled に設定すると、cluster.write-freq-thresholdand cluster.read-freq-thresholdoptions は、移行をトリガーする前に必要な特定のファイルへの書き込みおよび読み取り数を定義します。 | on | off | on |
features.shard | ボリュームでのシャード化を有効または無効にします。ボリュームの設定後に作成されたファイルに影響します。 | enable | disable | disable |
features.shard-block-size | シャードが有効な場合にファイルの部分の最大サイズを指定します。ボリュームの設定後に作成されたファイルに影響します。 | 512MB | 512MB |
geo-replication.indexing | マーカートランスレーターがボリュームの変更を追跡できるようにします。 | on | off | off |
network.ping-timeout | クライアントがサーバーからの応答を待つ時間。タイムアウトが発生すると、クライアントの代わりにサーバーによって保持されるすべてのリソースがクリーンアップされます。接続が再確立されたら、クライアントがサーバー上で操作を再開する前に、すべてのリソースを再実行する必要があります。また、ロックを取得し、ロックテーブルが更新されます。再接続は非常にコストのかかる操作なので、回避する必要があります。 | 42 秒 | 42 秒 |
nfs.acl | nfs.acl を無効にすると、NFSACL サイド帯域幅プロトコルのサポートが削除されます。これはデフォルトで有効になります。 | enable | disable | enable |
nfs.addr-namelookup | 受信クライアント接続の名前を検索するかどうかを指定します。一部の設定では、ネームサーバーが DNS クエリーに応答するために時間がかかりすぎる可能性があり、これによりマウント要求のタイムアウトが発生する可能性があります。このオプションを使用すると、アドレス認証中に名前の検索を無効にできます。名前検索を無効にすると、nfs.rpc-auth-*options でホスト名を使用できないことに注意してください。 | on | off | off |
nfs.disable | 個々のボリュームの NFS エクスポートを無効にするかどうかを指定します。 | on | off | off |
nfs.enable-ino32 | 64 ビットの inode 番号に対応していない nfs クライアントまたはアプリの場合は、このオプションを使用して、代わりに NFS が 32 ビットの inode 番号を返すようにします。デフォルトでは無効になっているため、NFS は 64 ビットの inode 番号を返します。この値はグローバルで、信頼できるストレージプール内のすべてのボリュームに適用されます。 | enable | disable | disable |
nfs.export-volumes | ボリューム全体のエクスポートを有効または無効にします。このオプションが無効で、nfs.export-diroption が有効になっている場合は、サブディレクトリーをエクスポートのみとして設定できます。 | on | off | on |
nfs.mount-rmtab | NFS クライアントの一覧およびマウントしたボリュームが含まれるキャッシュファイルへのパス。このファイルの場所をマウントした (すべてのストレージプールの glusterfs-fuse を使用)、ボリュームを使用するすべての NFS クライアントを、信頼済みプール全体に表示させます。このファイルのコンテンツは、showmount コマンドで取得できる情報を提供します。 | ディレクトリーへのパス | /var/lib/glusterd/nfs/rmtab |
nfs.mount-udp | MOUNT サイド帯域幅プロトコルの UDP トランスポートを有効にします。デフォルトでは UDP は有効ではなく、MOUNT は TCP 上でのみ使用できます。一部の NFS クライアント (Solaris、HP-UX など) は TCP 上の MOUNT に対応しておらず、nfs.mount-udpmakes を有効にすることで、Red Hat Gluster Storage が提供する NFS エクスポートを使用できます。 | disable | enable | disable |
nfs.nlm | デフォルトでは、Network Lock Manager (NLMv4) が有効になっています。このオプションは、NLM を無効にします。Red Hat では、このオプションを無効にすることは推奨していません。 | on|off | on |
nfs.port | glusterFS NFS をデフォルト以外のポートに関連付けます。 | 1025-60999 | 38465- 38467 |
nfs.ports-insecure | 非特権ポートからのクライアント接続を許可します。デフォルトでは、特権ポートのみが許可されます。これは、1 つのオプションを使用してすべてのエクスポートでセキュアでないポートを許可するためのグローバル設定です。 | on | off | off |
nfs.rdirplus | デフォルト値は、on です。このオプションをオフにすると、NFS は readdirp ではなく標準の readdir にフォールバックします。これを無効にすると、クライアントからルックアップおよび stat 要求が送信され、パフォーマンスに影響する可能性があります。 | on|off | on |
nfs.rpc-auth-allow IP_ADRESSES | サーバーへの接続を許可する IP アドレスのコンマ区切りリスト。デフォルトでは、すべてのクライアントが許可されます。 | IP アドレスのコンマ区切りリスト | accept all |
nfs.rpc-auth-reject IP_ADRESSES | サーバーへの接続が許可されていないアドレスのコンマ区切りリスト。デフォルトでは、すべての接続が許可されます。 | IP アドレスのコンマ区切りリスト | reject none |
nfs.server-aux-gids | これを有効にすると、NFS-server はボリュームにアクセスするユーザーのグループを解決します。NFSv3 は、RPC プロトコル (AUTH_UNIX/AUTH_SYS ヘッダー) によって 16 グループに制限されています。NFS- サーバーのグループを解決することで、この制限をバイパスできます。 | on|off | off |
nfs.transport-type | ブリックとの通信に GlusterFS NFS サーバーが使用するトランスポートを指定します。 | tcp OR rdma | tcp |
open-behind | オープン呼び出しを受信するたびに、正常な通知をアプリケーションに送信して、アプリケーションのデータを読み取る機能が改善されます。 | on | off | on |
performance.cache-max-file-size | io-cache トランスレーターによってキャッシュされる最大ファイルサイズを設定します。KB、MB、GB、TB、または PB の通常のサイズ記述子を使用して指定できます (例: 6 GB)。 | サイズ (バイト単位)、またはサイズ記述子を使用して指定します。 | 2 ^ 64-1 バイト |
performance.cache-min-file-size | io-cache トランスレーターによってキャッシュされる最小のファイルサイズを設定します。KB、MB、GB、TB、または PB の通常のサイズ記述子を使用して指定できます (例: 6 GB)。 | サイズ (バイト単位)、またはサイズ記述子を使用して指定します。 | 0 |
performance.cache-refresh-timeout | ファイルのキャッシュされたデータを保持する秒数。このタイムアウト後、データの再検証が実行されます。 | 0 - 61 秒 | 1 秒 |
performance.cache-size | 読み取りキャッシュのサイズ。 | サイズ (バイト単位)、またはサイズ記述子を使用して指定します。 | 32 MB |
performance.client-io-threads | 最大 16 個のスレッドを並行して使用できるようにすることで、分散 (erasure-coded) ボリュームの単一マウントポイントからの並列 I/O のパフォーマンスを向上させます。これを有効にすると、デフォルトで 1 スレッドが使用され、最大 16 までのスレッドがクライアントのワークロードで必要なとおりに作成されます。これは、分散されて分散されるボリュームに便利です。この機能は、分散、複製または分散されたボリュームには推奨されません。これは、複製されたボリューム種別および分散レプリケーションのボリューム種別でデフォルトで無効にされます。 | on | off | on (複製および分散されたボリュームを除く) |
performance.flush-behind | フラッシュファイルの操作がバックエンドファイルシステムに送信される前に、Write-behind トランスレーターがアプリケーションに成功を返して、バックグラウンドでフラッシュ操作を実行するかどうかを指定します。 | on | off | on |
performance.io-thread-count | I/O スレッドトランスレーターのスレッド数。 | 1 - 64 | 16 |
performance.lazy-open | このオプションを使用するには、open-behind を有効化する必要があります。必要なファイル操作が到達した場合にのみ、バックエンドでオープンを実行します (ファイル記述子への書き込み、ファイルのリンクの切断など)。このオプションが無効になっている場合は、アンワインドオープンの直後にバックエンドを開きます。 | Yes/No | はい |
performance.md-cache-timeout | メタデータキャッシュの更新時を制御する期間 (秒単位)。キャッシュの経過時間がこの期間を超える場合は、更新されます。キャッシュが更新されるたびに、その経過時間は 0 にリセットされます。 | 0-600 秒 | 1 秒 |
performance.nfs-strict-write-ordering | 書き込みが同じファイルまたは場所に関連しない場合でも、後で NFS の書き込みをオーバーラップしないようにするかどうかを指定します。 | on | off | off |
performance.nfs.flush-behind | フラッシュファイルの操作がバックエンドファイルシステムに送信される前に、(false) の成功をアプリケーションに返して、NFS の背景で write-behind トランスレーターがフラッシュ操作を実行するかどうかを指定します。 | on | off | on |
performance.nfs.strict-o-direct | NFS 上のファイルに対する I/O のキャッシュの影響を最小限に抑えるかどうかを指定します。このオプションが有効になり、O_DIRECT フラグを使用してファイル記述子が開かれると、そのファイル記述子に影響する書き込みでは、書き込みバックキャッシュが無効になります。このオプションが無効になっていると、O_DIRECT はキャッシュには影響しません。このオプションは、performance.write-behind が無効になっている場合は無視されます。 | on | off | off |
performance.nfs.write-behind-trickling-writes | NFS クライアントの write-behind トランスレーターの hardling-write ストラテジーを有効および無効にします。 | on | off | on |
performance.nfs.write-behind-window-size | 1 つのファイル、または NFS の場合は inode のサイズを指定します。 | 512 KB - 1 GB | 1 MB |
performance.quick-read | ボリュームでクイック読み取りトランスレーターを有効または無効にするには、以下を行います。 | on | off | on |
performance.rda-cache-limit | このオプションに指定された値は、readdir-ahead トランスレーターによって使用されるキャッシュの最大サイズです。この値はグローバルで、readdir-ahead によるメモリー消費の合計はこの値で制限されます (キャッシュされたディレクトリーの数/サイズに関係なく)。 | 0-1GB | 10MB |
performance.rda-request-size | このオプションに指定された値は、readdirp 応答でディレクトリーエントリーを保持するバッファーのサイズになります。 | 4KB-128KB | 128KB |
performance.resync-failed-syncs-after-fsync | fsync 操作が失敗する前に発行されたキャッシュ書き込みを同期した場合、このオプションで失敗した同期操作を再開するかどうかを設定します。 | on | off | off |
performance.strict-o-direct | ファイルに対する I/O のキャッシュの影響を最小限に抑えるかどうかを指定します。このオプションが有効になり、O_DIRECT フラグを使用してファイル記述子が開かれると、そのファイル記述子に影響する書き込みでは、書き込みバックキャッシュが無効になります。このオプションが無効になっていると、O_DIRECT はキャッシュには影響しません。このオプションは、performance.write-behind が無効になっている場合は無視されます。 | on | off | off |
performance.strict-write-ordering | 書き込みが同じファイルまたは場所に関連しない場合でも、後で書き込みをオーバーラップしないようにするかどうかを指定します。 | on | off | off |
performance.use-anonymous-fd | このオプションを使用するには、open-behind を有効化する必要があります。読み取り操作では、元のファイル記述子がオープンで、バックエンドで開かれていないときに匿名ファイル記述子を使用します。 | Yes | No | はい |
performance.write-behind | Write-behind トランスレーターを有効または無効にします。 | on | off | on |
performance.write-behind-trickling-writes | FUSE クライアントの write-behind トランスレーターの hardling-write ストラテジーを有効および無効にします。 | on | off | on |
performance.write-behind-window-size | 1 つのファイルまたは inode の書き込み動作バッファーのサイズを指定します。 | 512 KB - 1 GB | 1 MB |
rebal-throttle | リバランスプロセスは、パフォーマンスを向上させるために複数のファイル移行を処理するためにマルチスレッドで実行されます。複数のファイルシステムの移行では、ストレージシステムのパフォーマンスに重大な影響を与える可能性があります。スロットリングメカニズムは、管理するために提供されます。 | lazy、normal、ggressive | normal |
server.allow-insecure | 特権のないポートからの FUSE ベースのクライアント接続を許可します。デフォルトでは、ポートはセキュアでないポートからのメッセージを許可および拒否できることを意味します。無効にすると、特権ポートのみが許可されます。これは、1 つのオプションを使用してすべての FUSE ベースのエクスポートでセキュアでないポートを有効にするためのグローバル設定です。NFS アクセス制御に nfs.rpc-auth-* オプションを使用します。 | on | off | on |
server.anongid | root-squash が有効な場合に匿名ユーザーに使用される GID の値。root-squash を有効にすると、root GID (0) から受信したすべてのリクエストが匿名ユーザーの GID を持つように変更されます。 | 0 - 4294967295 | 65534 (この UID は nfsnobody としても知られています) |
server.anonuid | root-squash が有効な場合に匿名ユーザーに使用される UID の値。root-squash を有効にすると、root UID (0) から受信したすべてのリクエストが匿名ユーザーの UID になるよう変更されます。 | 0 - 4294967295 | 65534 (この UID は nfsnobody としても知られています) |
server.event-threads | Red Hat Gluster Storage ノードをホストするサーバープロセスで同時に処理されるネットワーク接続の数を指定します。 | 1 - 32 | 1 |
server.gid-timeout | キャッシュグループの有効期限が切れる必要がある期間 (秒単位)。これは、指定のユーザー (UID) が属するグループ (GID) が含まれるキャッシュです。このオプションは、server.manage-gids が有効な場合にのみ使用されます。 | 0-4294967295 秒 | 2 秒 |
server.manage-gids | サーバー側のグループを解決します。このオプションを有効にすると、クライアントによる RPC 呼び出しで送信されたグループを使用するのではなく、ユーザー (UID) がサーバー上で解決されます。このオプションを使用すると、プロトコルがサポートするものよりも大きなグループ一覧に所属するユーザーにパーミッションチェックを適用できます (約 93)。 | on|off | off |
server.root-squash | root ユーザーが root 権限を持たないようにするため、代わりに nfsnobody の特権を割り当てます。これにより、root ユーザーの権限が非表示になり、Red Hat Gluster Storage サーバー上の権限のないファイルを変更できません。このオプションは、glusterFS NFS プロトコルにのみ使用されます。 | on | off | off |
server.statedump-path | statedumpfiles を保存する必要のあるディレクトリーを指定します。 | /var/run/gluster (デフォルトインストール) | ディレクトリーへのパス |
ssl.crl-path | SSL 証明書失効リスト (CRL) を含むディレクトリーへのパスを指定します。このリストは、サーバーノードが、取り消された証明書のあるノードを停止し、クラスターにアクセスしないようにするのに役立ちます。 | CRL ファイルをホストするディレクトリーの絶対パス。 | null (デフォルト値なし。したがって、volume オプションを設定するまで空欄になります。) |
storage.fips-mode-rchecksum | 有効にすると、posix_rchecksum は FIPS 準拠の SHA256 チェックサムを使用し、それ以外の場合は MD5 を使用します。 | on | off | on |
警告
Red Hat Gluster Storage 3.4 以前を使用するクライアントを使用するボリュームで、 storage.fips-mode-rchecksum オプションを有効にしないでください。
| |||
storage.create-mask | 作成するファイルのパーミッションの最大セット (上限)。 | 0000 - 0777 | 0777 |
storage. create-directory-mask | 作成するディレクトリーに対するパーミッションの最大セット (上限) | 0000 - 0777 | 0777 |
storage.force-create-mode | 作成されるファイルのパーミッションの最小セット (下限)。 | 0000 - 0777 | 0000 |
storage.force-directory-mode | 作成されるディレクトリーのパーミッションの最小セット (下限)。 | 0000 - 0777 | 0000 |
重要
マスクと一致する強制モードの両方 ( create-directory-mask と force-directory-mode または create-mask と force-create-mode ) を同時に設定すると、計算されたファイルアクセスモードにおいて、動作は未定義になります。
| |||
storage.health-check-interval | ファイルシステムのヘルスチェックの時間間隔を秒単位で設定します。このパラメーターを 0 に設定すると無効にできます。ブリック上の POSIX トランスレーターは定期的なヘルスチェックを実行します。この確認に失敗すると、brick によりエクスポートされるファイルシステムは使用できず、ブリックプロセス (glusterfsd) が警告をログに記録して終了します。 | 0-4294967295 秒 | 30 秒 |
storage.health-check-timeout | aio_write がヘルスチェックに終了するまで待機する時間を秒単位で設定します。無効にするには 0 に設定します。 | 0-4294967295 秒 | 20 秒 |
storage.owner-gid | ボリュームのブリック用の GID を設定します。このオプションは、一部のアプリケーションが、ブリックを正しく機能させるのに特定の GID を持たせるのに場合に必要になる場合があります。例: QEMU 統合の場合、UID/GID は qemu:qemu である必要があります。つまり、107:107 (107 は qemu の UID および GID) です。 | -1 以上の整数。 | ブリックの GID は変更されません。これは -1 で表されます。 |
storage.owner-uid | ボリュームのブリック用の UID を設定します。このオプションは、一部のアプリケーションにブリックを正しく機能させるのに特定の UID を必要とする場合に必要になる場合があります。例: QEMU 統合の場合、UID/GID は qemu:qemu である必要があります。つまり、107:107 (107 は qemu の UID および GID) です。 | -1 以上の整数。 | ブリックの UID は変更されません。これは -1 で表されます。 |
storage.reserve |
POSIX トランスレーターには、ユーザーがブリックでディスク領域を予約できるオプションが含まれます。このオプションを使用すると、ブリックがほぼ満杯のときに、ユーザーがディスクまたはクラスターを拡張するのに十分な領域を確保できます。このオプションは、ディスクに
storage.reserve の割合/サイズまたはそれより少ない空き領域がある場合に、新規ファイル作成を防ぎます。
storage.reserve は、パーセンテージまたはMB/GB 形式のいずれかの値を受け入れます。このボリュームオプションを MB/GB から MB/GB に再設定するには、同じボリュームオプションを指定します。また、最新のセット値も考慮されます。
0 に設定すると、
storage.reserve が無効になります
|
0〜100% (パラメーターがパーセンテージの場合に適用可能)
または
nKB/MB/GB (サイズがパラメーターとして使用する場合は適用可能)、「n」は予約する必要がある正の整数です。
それぞれの例:
gluster volume set <vol-name> storage.reserve 15%
または
gluster volume set <vol-name> storage.reserve 100GB
| 1% (ブリックサイズの 1%) |
注記
storage.reserve オプションを MB/GB に設定する際には、ブリックサイズに注意してください。たとえば、volume オプションの値が >= ブリックのサイズである場合、ブリック全体が予約されます。
このオプションは、サブボリュームレベルで機能します。
| |||
transport.listen-backlog | キューに格納され、常に受け入れられるよう待機している、確立された TCP ソケット要求の最大数。 | 0 からシステムの最大値 | 1024 |
11.4. 読み取り専用でマウントされるボリュームの設定
# gluster volume set volname read-only enable
11.5. ボリュームのトランスポートタイプの設定
- 以下のコマンドを使用して、すべてのクライアントでボリュームをアンマウントします。
# umount mount-point
- 以下のコマンドを使用してボリュームを停止します。
# gluster volume stop volname
- 警告RDMA をトランスポートプロトコルとして使用することは、Red Hat Gluster Storage 3.5 で非推奨となっています。Red Hat ではこの使用を推奨しておらず、Red Hat Gluster Storage 3.5.3 にアップグレードする新規デプロイメントおよび既存デプロイメントでサポートしません。トランスポートタイプを変更します。たとえば、tcp と rdma の両方を有効にするには、followimg コマンドを実行します。
# gluster volume set volname config.transport tcp,rdma OR tcp OR rdma
- すべてのクライアントにボリュームをマウントします。たとえば、rdma トランスポートを使用してマウントするには、次のコマンドを使用します。
# mount -t glusterfs -o transport=rdma server1:/test-volume /mnt/glusterfs
11.6. ボリュームでのストレージの確保
# gluster volume set volname storage.reserve percentage
storage.reserve
オプションは、パーセント (%) の接尾辞値、または絶対単位 (KB、MB、GBなど) の接尾辞が付いた符号なし整数値のいずれかを取ります。オプションのデフォルト値は 1 % (ブリックサイズの 1 %) です。0 に設定すると、このオプションは無効になります。
11.7. ボリュームの拡張
ボリュームの拡張
- 信頼できるストレージプール内のサーバーから、以下のコマンドを使用して、新しいブリックを追加するサーバーをプローブします。
# gluster peer probe HOSTNAME
以下に例を示します。# gluster peer probe server5 Probe successful # gluster peer probe server6 Probe successful
- 以下のコマンドを使用してブリックを追加します。
# gluster volume add-brick VOLNAME NEW_BRICK
以下に例を示します。# gluster volume add-brick test-volume server5:/rhgs/brick5/ server6:/rhgs/brick6/ Add Brick successful
- 以下のコマンドを使用してボリューム情報を確認します。
# gluster volume info
コマンド出力には、以下のような情報が表示されます。Volume Name: test-volume Type: Distribute-Replicate Status: Started Number of Bricks: 6 Bricks: Brick1: server1:/rhgs/brick1 Brick2: server2:/rhgs/brick2 Brick3: server3:/rhgs/brick3 Brick4: server4:/rhgs/brick4 Brick5: server5:/rhgs/brick5 Brick6: server6:/rhgs/brick6
- ボリュームをリバランスして、ファイルが新しいブリックに配布されるようにします。「ボリュームのリバランス」 の説明に従って、リバランスコマンドを使用します。add-brick コマンドの後に、追加されたブリックの使用が向上されるように、rebalance を行う必要があります。
11.7.1. 階層化ボリュームの拡張
11.7.1.1. 折りたたまれた階層ボリュームの拡張
- 「ボリュームから階層の割り当て解除 (非推奨)」 の手順に従って階層をデタッチします。
- 信頼できるストレージプール内のサーバーから、以下のコマンドを使用して、新しいブリックを追加するサーバーをプローブします。
# gluster peer probe HOSTNAME
以下に例を示します。# gluster peer probe server5 Probe successful # gluster peer probe server6 Probe successful
- 以下のコマンドを使用してブリックを追加します。
# gluster volume add-brick VOLNAME NEW_BRICK
以下に例を示します。# gluster volume add-brick test-volume server5:/rhgs/brick5/ server6:/rhgs/brick6/
- ボリュームをリバランスして、ファイルが新しいブリックに配布されるようにします。「ボリュームのリバランス」 の説明に従って、リバランスコマンドを使用します。add-brick コマンドの後に、追加されたブリックの使用が向上されるように、rebalance を行う必要があります。
- 古い (展開済み) ブリックを使用して、階層をボリュームに再アタッチします。# gluster volume tier VOLNAME attach [replica COUNT] NEW-BRICK...重要層を再アタッチすると、利用可能なホットレイヤーを準備するために fix-layout という内部プロセスが内部で実行されます。このプロセスに時間がかかり、階層アクティビティーを開始するのに遅延が生じます。ブリックを再利用する場合は、階層化されるボリュームにアタッチする前に、既存のデータを明確に消去してください。
11.7.1.2. ホット階層ボリュームの拡張
- 「ボリュームから階層の割り当て解除 (非推奨)」 の手順に従って階層をデタッチします。
- 古い (展開済み) ブリックを使用して、階層をボリュームに再アタッチします。# gluster volume tier VOLNAME attach [replica COUNT] NEW-BRICK...以下に例を示します。
# gluster volume tier test-volume attach replica 3 server1:/rhgs/tier5 server2:/rhgs/tier6 server1:/rhgs/tier7 server2:/rhgs/tier8
重要層を再アタッチすると、利用可能なホットレイヤーを準備するために fix-layout という内部プロセスが内部で実行されます。このプロセスに時間がかかり、階層アクティビティーを開始するのに遅延が生じます。ブリックを再利用する場合は、階層化されるボリュームにアタッチする前に、既存のデータを明確に消去してください。
11.7.2. 分散型ボリュームまたは分散で分散されたボリュームの拡張
Dispersed
ボリュームに追加すると、Distributed-Dispersed
ボリュームに変換され、既存の分散ボリュームは分散されたサブボリュームとして処理されます。
- 信頼できるストレージプールのサーバーから、以下のコマンドを使用して、新しいブリックを追加するサーバーをプローブします。
# gluster peer probe HOSTNAME
以下に例を示します。# gluster peer probe server4 Probe successful # gluster peer probe server5 Probe successful # gluster peer probe server6 Probe successful
- 以下のコマンドを使用してブリックを追加します。
# gluster volume add-brick VOLNAME NEW_BRICK
以下に例を示します。# gluster volume add-brick test-volume server4:/rhgs/brick7 server4:/rhgs/brick8 server5:/rhgs/brick9 server5:/rhgs/brick10 server6:/rhgs/brick11 server6:/rhgs/brick12
- (オプション) ブリックを追加した後にボリューム情報を表示します。
# gluster volume info VOLNAME
以下に例を示します。# gluster volume info test-volume Volume Name: test-volume Type: Distributed-Disperse Volume ID: 2be607f2-f961-4c4b-aa26-51dcb48b97df Status: Started Snapshot Count: 0 Number of Bricks: 2 x (4 + 2) = 12 Transport-type: tcp Bricks: Brick1: server1:/rhgs/brick1 Brick2: server1:/rhgs/brick2 Brick3: server2:/rhgs/brick3 Brick4: server2:/rhgs/brick4 Brick5: server3:/rhgs/brick5 Brick6: server3:/rhgs/brick6 Brick7: server4:/rhgs/brick7 Brick8: server4:/rhgs/brick8 Brick9: server5:/rhgs/brick9 Brick10: server5:/rhgs/brick10 Brick11: server6:/rhgs/brick11 Brick12: server6:/rhgs/brick12 Options Reconfigured: transport.address-family: inet performance.readdir-ahead: on nfs.disable: on
- ボリュームをリバランスして、ファイルが新しいブリックに配布されるようにします。「ボリュームのリバランス」 の説明に従って、リバランスコマンドを使用します。add-brick コマンドの後に、追加されたブリックの使用が向上されるように、rebalance を行う必要があります。
11.7.3. 論理ボリュームの拡張
# gluster volume status # kill -9 brick-process-id
- 次のコマンドでブリックを使用して、すべてのボリュームを停止します。
# gluster volume stop VOLNAME
- lsblk コマンドを使用して、新規ディスクが表示されるかどうかを確認します。
# lsblk
- 以下のコマンドを実行して、新しい物理ボリュームを作成します。
# pvcreate /dev/PHYSICAL_VOLUME_NAME
- 以下のコマンドを使用して、物理ボリュームが作成されているかどうかを確認します。
# pvs
- 既存のボリュームグループを拡張します。
# vgextend VOLUME_GROUP_NAME /dev/PHYSICAL_VOLUME_NAME
- 以下のコマンドを使用してボリュームグループのサイズを確認し、新しい追加が反映されているかどうかを確認します。
# vgscan
- 作成したボリュームグループに、論理ボリュームを拡張するのに十分な領域があることを確認します。
vgdisplay VOLUME_GROUP_NAME
以下のコマンドを使用してファイルシステム名を取得します。# df -h
- 以下のコマンドを使用して、論理ボリュームを拡張します。
# lvextend -L+nG /dev/mapper/ LOGICAL_VOLUME_NAME-VOLUME_GROUP_NAME
シンプールの場合は、以下のコマンドを使用してプールを拡張します。# lvextend -L+nG VOLUME_GROUP_NAME/POOL_NAME
上記のコマンドでは、n が、拡張する GB の追加サイズになります。#lvdisplay コマンドを実行してプール名を取得します。以下のコマンドを使用して、論理ボリュームが拡張されているかどうかを確認します。# lvdisplay VOLUME_GROUP_NAME
- 以下のコマンドを実行して、拡張論理ボリュームに対応するようにファイルシステムを拡張します。
# xfs_growfs /dev/VOLUME_GROUP_NAME/LOGICAL_VOLUME_NAME
- 以下のコマンドを使用してファイルシステムを再マウントします。
# mount -o remount /dev/VOLUME_GROUP_NAME/LOGICAL_VOLUME_NAME /bricks/path_to_brick
- force オプションを指定して、すべてのボリュームを起動します。
# gluster volume start VOLNAME force
11.8. ボリュームの縮小
ボリュームの縮小
- 以下のコマンドを使用してブリックを削除します。
# gluster volume remove-brick VOLNAME BRICK start
以下に例を示します。# gluster volume remove-brick test-volume server2:/rhgs/brick2 start Remove Brick start successful
注記remove-brick コマンドがforce
で実行されるか、オプションなしで実行すると、ブリックのデータは glusterFS マウントポイントからアクセスできなくなります。start
オプションを使用すると、データは他のブリックに移行され、コミットに成功すると、削除されたブリック情報がボリューム設定から削除されます。データには依然としてブリックから直接アクセスできます。 - 以下のコマンドを使用して、削除ブリック操作のステータスを表示することができます。
# gluster volume remove-brick VOLNAME BRICK status
以下に例を示します。# gluster volume remove-brick test-volume server2:/rhgs/brick2 status Node Rebalanced size scanned failures skipped status run time -files in h:m:s ---------- --------- ------ ------ -------- ------ --------- -------- localhost 5032 43.4MB 27715 0 5604 completed 0:15:05 10.70.43.41 0 0Bytes 0 0 0 completed 0:08:18 volume rebalance: test-volume: success
- 以前の status コマンドで表示されるデータ移行が完了したら、以下のコマンドを実行してブリック削除をコミットします。
# gluster volume remove-brick VOLNAME BRICK commit
以下に例を示します。# gluster volume remove-brick test-volume server2:/rhgs/brick2 commit
- ブリックを削除したら、以下のコマンドを使用してボリューム情報を確認できます。
# gluster volume info
このコマンドは、以下のような情報を表示します。# gluster volume info Volume Name: test-volume Type: Distribute Status: Started Number of Bricks: 3 Bricks: Brick1: server1:/rhgs/brick1 Brick3: server3:/rhgs/brick3 Brick4: server4:/rhgs/brick4
11.8.1. Geo レプリケーションボリュームの縮小
- 以下のコマンドを使用してブリックを削除します。
# gluster volume remove-brick VOLNAME BRICK start
以下に例を示します。# gluster volume remove-brick MASTER_VOL MASTER_HOST:/rhgs/brick2 start Remove Brick start successful
注記remove-brick コマンドがforce
で実行されるか、オプションなしで実行すると、ブリックのデータは glusterFS マウントポイントからアクセスできなくなります。start
オプションを使用すると、データは他のブリックに移行され、コミットに成功すると、削除されたブリック情報がボリューム設定から削除されます。データには依然としてブリックから直接アクセスできます。 - Geo レプリケーション
config checkpoint
を使用して、そのブリックのすべてのデータがスレーブに同期されるようにします。- チェックポイントを設定して、データ同期のステータスを確認します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config checkpoint now
- 以下のコマンドを使用して、geo レプリケーションセッションのチェックポイント完了を確認します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL status detail
- 以下のコマンドを使用して、削除ブリック操作のステータスを表示することができます。
# gluster volume remove-brick VOLNAME BRICK status
以下に例を示します。# gluster volume remove-brick MASTER_VOL MASTER_HOST:/rhgs/brick2 status
- プライマリーとセカンダリーの間の geo レプリケーションセッションを停止します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop
- 以前の status コマンドで表示されるデータ移行が完了したら、以下のコマンドを実行してブリック削除をコミットします。
# gluster volume remove-brick VOLNAME BRICK commit
以下に例を示します。# gluster volume remove-brick MASTER_VOL MASTER_HOST:/rhgs/brick2 commit
- ブリックを削除したら、以下のコマンドを使用してボリューム情報を確認できます。
# gluster volume info
- ホスト間の geo レプリケーションセッションを開始します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start
11.8.2. 階層化されたボリュームの縮小
11.8.2.1. コールド階層ボリュームの縮小
- 「ボリュームから階層の割り当て解除 (非推奨)」 の手順に従って階層をデタッチします。
- 以下のコマンドを使用してブリックを削除します。
# gluster volume remove-brick VOLNAME BRICK start
以下に例を示します。# gluster volume remove-brick test-volume server2:/rhgs/brick2 start Remove Brick start successful
注記remove-brick コマンドがforce
で実行されるか、オプションなしで実行すると、ブリックのデータは glusterFS マウントポイントからアクセスできなくなります。start
オプションを使用すると、データは他のブリックに移行され、コミットに成功すると、削除されたブリック情報がボリューム設定から削除されます。データには依然としてブリックから直接アクセスできます。 - 以下のコマンドを使用して、削除ブリック操作のステータスを表示することができます。
# gluster volume remove-brick VOLNAME BRICK status
以下に例を示します。# gluster volume remove-brick test-volume server2:/rhgs/brick2 status Node Rebalanced-files size scanned failures status --------- ----------- ----------- ----------- ----------- ------------ localhost 16 16777216 52 0 in progress 192.168.1.1 13 16723211 47 0 in progress
- 以前の status コマンドで表示されるデータ移行が完了したら、以下のコマンドを実行してブリック削除をコミットします。
# gluster volume remove-brick VOLNAME BRICK commit
以下に例を示します。# gluster volume remove-brick test-volume server2:/rhgs/brick2 commit
- attach- tier コマンドは、必要なブリックのセットでのみ再実行します。# gluster volume tier VOLNAME attach [replica COUNT] BRICK...以下に例を示します。
# gluster volume tier test-volume attach replica 3 server1:/rhgs/tier1 server2:/rhgs/tier2 server1:/rhgs/tier3 server2:/rhgs/tier4
重要レイヤーをアタッチすると、fix-layout という内部プロセスは内部的に開始し、使用するホット層を準備します。このプロセスに時間がかかり、階層アクティビティーを開始するのに遅延が生じます。
11.8.2.2. ホット階層ボリュームの縮小
- 「ボリュームから階層の割り当て解除 (非推奨)」 の手順に従って階層をデタッチします。
- attach- tier コマンドは、必要なブリックのセットでのみ再実行します。# gluster volume tier VOLNAME attach [replica COUNT] brick...重要層を再アタッチすると、利用可能なホットレイヤーを準備するために fix-layout という内部プロセスが内部で実行されます。このプロセスに時間がかかり、階層アクティビティーを開始するのに遅延が生じます。
11.8.3. remove-brick 操作の停止
# gluster volume remove-brick VOLNAME BRICK stop
gluster volume remove-brick test-volume server1:/rhgs/brick1/ server2:/brick2/ stop Node Rebalanced-files size scanned failures skipped status run-time in secs ---- ------- ---- ---- ------ ----- ----- ------ localhost 23 376Bytes 34 0 0 stopped 2.00 rhs1 0 0Bytes 88 0 0 stopped 2.00 rhs2 0 0Bytes 0 0 0 not started 0.00 'remove-brick' process may be in the middle of a file migration. The process will be fully stopped once the migration of the file is complete. Please check remove-brick process for completion before doing any further brick related tasks on the volume.
11.9. ボリュームの移行
11.9.1. 分散ボリュームまたは複製ボリュームでのサブボリュームの置き換え
- 新しいブリックをボリュームに追加します。
# gluster volume add-brick VOLNAME [replica <COUNT>] NEW-BRICK
例11.1 ボリュームへのブリックの追加
# gluster volume add-brick test-volume server5:/rhgs/brick5 Add Brick successful
- 以下のコマンドを使用してボリューム情報を確認します。
# gluster volume info Volume Name: test-volume Type: Distribute Status: Started Number of Bricks: 5 Bricks: Brick1: server1:/rhgs/brick1 Brick2: server2:/rhgs/brick2 Brick3: server3:/rhgs/brick3 Brick4: server4:/rhgs/brick4 Brick5: server5:/rhgs/brick5
注記Distribute-replicate ボリュームの場合は、add-brick コマンドでレプリカ数を指定し、add-brick コマンドにレプリカ数と同じ数のブリックを指定する必要があります。 - サブボリュームから置き換えるブリックを削除します。
- 以下のコマンドを使用して remove-brick 操作を起動します。
# gluster volume remove-brick VOLNAME [replica <COUNT>] <BRICK> start
例11.2 分散ボリュームで削除操作の開始
# gluster volume remove-brick test-volume server2:/rhgs/brick2 start Remove Brick start successful
- 以下のコマンドを使用して remove-brick 操作のステータスを表示します。
# gluster volume remove-brick VOLNAME [replica <COUNT>] BRICK status
例11.3 remove-brick 操作のステータスの表示
# gluster volume remove-brick test-volume server2:/rhgs/brick2 status Node Rebalanced-files size scanned failures skipped status run-time in h:m:s ---- ------- ---- ---- ------ ----- ----- ------ server2 10045 204.9MB 73522 0 0 in progress 0:10:34 Estimated time left for rebalance to complete: 0:10:23
上記のコマンドを実行して remove-brick 操作のステータスの監視を保持します。上記の例では、リバランスの完了までの推定時間は 10 分です。status フィールドの値が remove-brick ステータスコマンドの出力でcomplete
に設定されている場合には、さらに次に進みます。 - 以下のコマンドを使用して remove-brick 操作をコミットします。
# gluster volume remove-brick VOLNAME [replica <COUNT>] <BRICK> commit
例11.4 ボリュームでの remove-brick 操作のコミット
# gluster volume remove-brick test-volume server2:/rhgs/brick2 commit
- 以下のコマンドを使用してボリューム情報を確認します。
# gluster volume info Volume Name: test-volume Type: Distribute Status: Started Number of Bricks: 4 Bricks: Brick1: server1:/rhgs/brick1 Brick3: server3:/rhgs/brick3 Brick4: server4:/rhgs/brick4 Brick5: server5:/rhgs/brick5
- ボリュームで remove-brick 操作をコミットした後に、ブリックの内容を確認します。残りファイルがある場合は、FUSE または NFS マウントでコピーします。
- サブボリュームのブリックに保留中のファイルがあるかどうかを確認します。ファイルとともに、アプリケーション固有の拡張属性をすべてコピーする必要があります。また、glusterFS は拡張属性を使用して内部データを保存することもできます。glusterFS が使用する拡張属性は、
trusted.glusterfs.*
、trusted.afr.*
、およびtrusted.gfid
形式です。上記以外の拡張属性もコピーする必要があります。アプリケーション固有の拡張属性をコピーし、上記と同様の効果を実現するには、以下のシェルスクリプトを使用します。構文:# copy.sh <glusterfs-mount-point> <brick>
例11.5 コード実行のための使用
マウントポイントが/mnt/glusterfs
で、ブリックパスが/rhgs/brick1
の場合は、以下のようにスクリプトを実行する必要があります。# copy.sh /mnt/glusterfs /rhgs/brick1
#!/bin/bash MOUNT=$1 BRICK=$2 for file in `find $BRICK ! -type d`; do rpath=`echo $file | sed -e "s#$BRICK\(.*\)#\1#g"` rdir=`dirname $rpath` cp -fv $file $MOUNT/$rdir; for xattr in `getfattr -e hex -m. -d $file 2>/dev/null | sed -e '/^#/d' | grep -v -E "trusted.glusterfs.*" | grep -v -E "trusted.afr.*" | grep -v "trusted.gfid"`; do key=`echo $xattr | cut -d"=" -f 1` value=`echo $xattr | cut -d"=" -f 2` setfattr $MOUNT/$rpath -n $key -v $value done done
- スプリットブレイン状態にあるファイルの一覧を特定するには、以下のコマンドを実行します。
# gluster volume heal test-volume info split-brain
- 上記のコマンドの出力にリストされているファイルがある場合は、レプリカセットのブリック全体でファイルを比較し、ブリックから不要なファイルを削除して、ファイルの正しいコピーを保持します。システム管理者による手動の介入は、正しいファイルのコピーを選択するために必要です。
11.9.2. Replicate または Distribute-replicate ボリュームの古いブログを新しいブログに置き換え
- 古いブリック (
server0:/rhgs/brick1
) を置き換える新しいブリック (server5:/rhgs/brick1
) が空であることを確認してください。すべてのブリックがオンラインであることを確認します。置き換える必要のあるブリックはオフライン状態になる可能性があります。 - replace-brick コマンドを
force
オプションを指定して実行します。# gluster volume replace-brick test-volume server0:/rhgs/brick1 server5:/rhgs/brick1 commit force volume replace-brick: success: replace-brick commit successful
- 新しいブリックがオンラインかどうかを確認します。
# gluster volume status Status of volume: test-volume Gluster process Port Online Pid --------------------------------------------------------- Brick server5:/rhgs/brick1 49156 Y 5731 Brick server1:/rhgs/brick1 49153 Y 5354 Brick server2:/rhgs/brick1 49154 Y 5365 Brick server3:/rhgs/brick1 49155 Y 5376
- 新たに追加したブリックのデータは自動的に修復されます。修復するデータ量によっては、時間がかかる可能性があります。ブリックを置き換えた後に修復情報を確認して、他のブリックを置き換えたり削除する前に、すべてのデータが修復されたことを確認することが推奨されます。
# gluster volume heal VOL_NAME info
以下に例を示します。# gluster volume heal test-volume info Brick server5:/rhgs/brick1 Status: Connected Number of entries: 0 Brick server1:/rhgs/brick1 Status: Connected Number of entries: 0 Brick server2:/rhgs/brick1 Status: Connected Number of entries: 0 Brick server3:/rhgs/brick1 Status: Connected Number of entries: 0
修復が完了したら、Number of entries
フィールドの値はゼロとして表示されます。
11.9.3. 古いブリックの分散ボリュームでの新しいブログの置き換え
- 変更を行う前に、ボリュームから削除するブリックの内容を確認してください。
# ls /mount/point/OLDBRICK file1 file2 ... file5
- 新しいブリックをボリュームに追加します。
# gluster volume add-brick VOLNAME NEWSERVER:NEWBRICK
- 古いブリックの削除を開始します。
# gluster volume remove-brick VOLNAME OLDSERVER:OLDBRICK start
- remove-brick status コマンドが削除が完了したことを示すまで待機します。
# gluster volume remove-brick VOLNAME BRICK status Rebalanced run time Node files size scanned failures skipped status in secs -------------------------------------------------------------------------------- localhost 5 20Bytes 15 0 0 completed 0.00
- 古いブリックの削除を終了します。
# gluster volume remove-brick VOLNAME OLDSERVER:OLDBRICK commit
- 削除されたブリックにあるすべてのファイルがボリュームに存在することを確認します。
11.9.4. 古いブリックを、Distributed-Dispersed ボリュームまたは分散ボリュームで新しいブログに置き換え
- 古いブリックを置き換える新しいブリックが空であることを確認します。置き換える必要のあるブリックはオフラインの状態にすることができますが、その他のすべてのブリックはオンラインである必要があります。
- replace-brick コマンドを
force
オプションを指定して実行します。# gluster volume replace-brick VOL_NAME old_brick_path new_brick_path commit force
以下に例を示します。# gluster volume replace-brick test-volume server1:/rhgs/brick2 server1:/rhgs/brick2new commit force volume replace-brick: success: replace-brick commit successful
追加する新しいブリックは同じサーバーから表示するか、新しいサーバーを追加してから新しいブリックを追加してください。 - 新しいブリックがオンラインかどうかを確認します。
# gluster volume status Status of volume: test-volume Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick server1:/rhgs/brick1 49187 0 Y 19927 Brick server1:/rhgs/brick2new 49188 0 Y 19946 Brick server2:/rhgs/brick3 49189 0 Y 19965 Brick server2:/rhgs/brick4 49190 0 Y 19984 Brick server3:/rhgs/brick5 49191 0 Y 20003 Brick server3:/rhgs/brick6 49192 0 Y 20022 NFS Server on localhost N/A N/A N N/A Self-heal Daemon on localhost N/A N/A Y 20043 Task Status of Volume test-volume ------------------------------------------------------------------------------ There are no active volume tasks
- 新たに追加したブリックのデータは自動的に修復されます。修復するデータ量によっては、時間がかかる可能性があります。ブリックを置き換えた後に修復情報を確認して、他のブリックを置き換えたり削除する前に、すべてのデータが修復されたことを確認することが推奨されます。
# gluster volume heal VOL_NAME info
以下に例を示します。# gluster volume heal test-volume info Brick server1:/rhgs/brick1 Status: Connected Number of entries: 0 Brick server1:/rhgs/brick2new Status: Connected Number of entries: 0 Brick server2:/rhgs/brick3 Status: Connected Number of entries: 0 Brick server2:/rhgs/brick4 Status: Connected Number of entries: 0 Brick server3:/rhgs/brick5 Status: Connected Number of entries: 0 Brick server3:/rhgs/brick6 Status: Connected Number of entries: 0
修復が完了したら、Number of entries
フィールドの値はゼロとして表示されます。 - Red Hat Gluster Storage 3.4 では、heal info コマンドの
summary
オプションが導入されました。このコマンドは、スプリットブレインで待機しているエントリーの統計と、修復中のエントリーを表示します。このコマンドはエントリー数のみを表示し、実際の file-names または gfids は出力されません。ボリュームの概要を取得するには、以下のコマンドを実行します。# gluster volume heal VOLNAME info summary
以下に例を示します。# gluster volume heal test-volume info summary Command output: Brick 192.168.2.8:/brick/1 Status: Connected Total Number of entries: 363 Number of entries in heal pending: 362 Number of entries in split-brain: 0 Number of entries possibly healing: 1
注記'summary' オプションは、'info' コマンドとは異なり、ブリックに関する詳細情報を提供します。概要情報は、’info’ コマンドと同じように取得されます。--xml パラメーターは、XML 形式の summary オプションの出力を提供します。# gluster volume heal test-volume info summary --xml <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <cliOutput> <healInfo< <bricks> <brick hostUuid="9105dd4b-eca8-4fdb-85b2-b81cdf77eda3"> <name>192.168.2.8:/brick/1</name> <status>Connected</status> <totalNumberOfEntries>363</totalNumberOfEntries> <numberOfEntriesInHealPending>362</numberOfEntriesInHealPending> <numberOfEntriesInSplitBrain>0</numberOfEntriesInSplitBrain> <numberOfEntriesPossiblyHealing>1</numberOfEntriesPossiblyHealing> </brick> </bricks> </healInfo> <opRet>0</opRet> <opErrno>0</opErrno> <opErrstr/> </cliOutput>
11.9.5. ボリュームでのブリックの再設定
- リセットするブリックがオフラインの時に依然としてクォーラムに達していることを確認します。
- 可能であれば、Red Hat は、I/O を停止し、ボリュームで 16 回の操作が保留していないことを確認することを推奨します。
- 以下のコマンドを実行して、リセットするブリックを強制終了します。
# gluster volume reset-brick VOLNAME HOSTNAME:BRICKPATH start
- 必要に応じてオフラインブリックを設定します。
- gluster volume infoで表示されるボリュームの
Volume-ID
が、オフラインブリックのVolume-ID
(ある場合)と一致していることを確認します。# gluster volume info VOLNAME # cat /var/lib/glusterd/vols/VOLNAME/VOLNAME.HOSTNAME.BRICKPATH.vol | grep volume-id
たとえば、以下の分散ボリュームでは、ボリューム ID
とボリューム ID
はどちらもab8a981a-a6d9-42f2-b8a5-0b28fe2c4548
です。# gluster volume info vol Volume Name: vol Type: Disperse Volume ID: ab8a981a-a6d9-42f2-b8a5-0b28fe2c4548 Status: Started Snapshot Count: 0 Number of Bricks: 1 x (4 + 2) = 6 Transport-type: tcp Bricks: Brick1: myhost:/brick/gluster/vol-1
# cat /var/lib/glusterd/vols/vol/vol.myhost.brick-gluster-vol-1.vol | grep volume-id option volume-id ab8a981a-a6d9-42f2-b8a5-0b28fe2c4548
- 再設定されたブリックをオンラインに戻します。これには 2 つのオプションがあります。
- 前のステップでブリックに
volume-id
がない場合は、以下のコマンドを実行します。# gluster volume reset-brick VOLNAME HOSTNAME:BRICKPATH HOSTNAME:BRICKPATH commit
- ブリックの
volume-id
がボリュームの識別子と一致する場合、Red Hat は操作が成功するようにforce
キーワードを追加することを推奨します。# gluster volume reset-brick VOLNAME HOSTNAME:BRICKPATH HOSTNAME:BRICKPATH commit force
11.10. ホストの置き換え
11.10.1. ホストマシンを別のホスト名に置き換える
server0.example.
com、代替のマシンをserver5.example.com
としています。復旧不可能な障害のあるブリックは server0.example.com:/rhgs/brick1
で、置き換えるブリックは server5.example.com:/rhgs/brick1
です。
- 以下のコマンドを実行してジオレプリケーションセッションを停止します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop force
- 既存のピアの 1 つから新規ピアをプローブし、これをクラスターで使用できるようにします。
# gluster peer probe server5.example.com
- 古いブリック
(server5.example.com:/rhgs/brick1)
を置き換える新しいブリック(server0.example.com:/rhgs/brick1)
が空であることを確認します。 - geo レプリケーションセッションが設定されている場合は、以下の手順を実行します。
- ssh キーを生成して、geo レプリケーションセッションを設定します。
# gluster system:: execute gsec_create
force
オプションを指定して、ジオレプリケーションセッションを再度作成して、新しいノードから Slave ノードにキーを配布します。# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL create push-pem force
- 共有ストレージボリュームの設定に成功すると、新しいノードがクラスターに置き換えられると、共有ストレージはこのノードに自動的にマウントされません。このノードの共有ストレージ用に
/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/ に変更されました。共有ストレージボリュームの設定についての詳細は、「共有ストレージボリュームの設定」 を参照してください。 - geo レプリケーションのメタボリュームを設定します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config use_meta_volume true
meta-volume の設定に関する詳細は、「メタボリュームの設定」 を参照してください。
- 以下のコマンドを使用して、
server0.example.com
のブリックパスを取得します。# gluster volume info <VOLNAME>
Volume Name: vol Type: Replicate Volume ID: 0xde822e25ebd049ea83bfaa3c4be2b440 Status: Started Snap Volume: no Number of Bricks: 1 x 2 = 2 Transport-type: tcp Bricks: Brick1: server0.example.com:/rhgs/brick1 Brick2: server1.example.com:/rhgs/brick1 Options Reconfigured: cluster.granular-entry-heal: on performance.readdir-ahead: on snap-max-hard-limit: 256 snap-max-soft-limit: 90 auto-delete: disable
server0.example.com
のブリックパスは/rhgs/brick1
です。これは、新たに追加したホストのブリック (server5.example.com
) に置き換える必要があります。 - たとえば、/rhs/brick が server5.example.com の XFS マウントポイントである場合は、server5.example.com に必須のブリックパスを作成します。
# mkdir /rhgs/brick1
- replace-brick コマンドを force オプションを指定して実行します。
# gluster volume replace-brick vol server0.example.com:/rhgs/brick1 server5.example.com:/rhgs/brick1 commit force volume replace-brick: success: replace-brick commit successful
- 新しいブリックがオンラインであることを確認します。
# gluster volume status Status of volume: vol Gluster process Port Online Pid Brick server5.example.com:/rhgs/brick1 49156 Y 5731 Brick server1.example.com:/rhgs/brick1 49153 Y 5354
- ボリュームで自己修復を開始します。修復プロセスのステータスは、以下のコマンドを実行すると確認できます。
# gluster volume heal VOLNAME
- 修復プロセスのステータスは、以下のコマンドを実行すると確認できます。
# gluster volume heal VOLNAME info
- 元のマシンを信頼できるプールから切断します。
# gluster peer detach (server) All clients mounted through the peer which is getting detached need 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
- 自己修復が完了したら、拡張属性がレプリカの他のブリックでゼロに設定されていることを確認します。
# getfattr -d -m. -e hex /rhgs/brick1 getfattr: Removing leading '/' from absolute path names #file: rhgs/brick1 security.selinux=0x756e636f6e66696e65645f753a6f626a6563745f723a66696c655f743a733000 trusted.afr.vol-client-0=0x000000000000000000000000 trusted.afr.vol-client-1=0x000000000000000000000000 trusted.gfid=0x00000000000000000000000000000001 trusted.glusterfs.dht=0x0000000100000000000000007ffffffe trusted.glusterfs.volume-id=0xde822e25ebd049ea83bfaa3c4be2b440
この例では、trusted.afr.vol-client-0
およびtrusted.afr.vol-client-1
の拡張属性の値がゼロになります。つまり、2 つのブリックのデータは同一であることを意味します。自己修復の完了後にこれらの属性がゼロにならないと、データが正しく同期されません。 force
オプションを使用してジオレプリケーションセッションを起動します。# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start force
11.10.2. ホストマシンの同じホスト名への置き換え
/var/lib/glusterd/glusterd.info
ファイルにあります。
- 以下のコマンドを実行してジオレプリケーションセッションを停止します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop force
- server0.example.com で
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 ソフトウェアコンポーネントおよびバージョン』 を参照してください。 - 以下のコマンドを実行して、Red Hat Gluster Storage Trusted Storage Pool から障害のあるホストの UUID (server0.example.com) を取得します。
# gluster peer status Number of Peers: 2 Hostname: server1.example.com Uuid: 1d9677dc-6159-405e-9319-ad85ec030880 State: Peer in Cluster (Connected) Hostname: server0.example.com Uuid: b5ab2ec3-5411-45fa-a30f-43bd04caf96b State: Peer Rejected (Connected)
障害が発生したホストの UUID はb5ab2ec3-5411-45fa-a30f-43bd04caf96b
です。 - 新しいホストの
glusterd.info
ファイルを編集し、前の手順で取得したホストのUUIDを含める。# cat /var/lib/glusterd/glusterd.info UUID=b5ab2ec3-5411-45fa-a30f-43bd04caf96b operating-version=30703
注記このノードの操作バージョンは、信頼できるストレージプールの他のノードと同じである必要があります。 - Red Hat Gluster Storage Trusted Storage Pool内の任意のホスト(例:server1.example.com)を選択し、そのUUIDを
glusterd.info
ファイルから取得します。# grep -i uuid /var/lib/glusterd/glusterd.info UUID=8cc6377d-0153-4540-b965-a4015494461c
- 直前の手順でホスト (server1.example.com) からピア情報ファイルを収集します。クラスターのホスト (server1.example.com) で以下のコマンドを実行します。
# cp -a /var/lib/glusterd/peers /tmp/
- 障害が発生したホスト (server0.example.com) に対応するピアファイルを
/tmp/peers
ディレクトリーから削除します。# rm /tmp/peers/b5ab2ec3-5411-45fa-a30f-43bd04caf96b
UUID は、手順 3 で取得した障害が発生したホストの UUID (server0.example.com) に対応することに注意してください。 - すべてのファイルをアーカイブし、それらを失敗したホスト (server0.example.com) にコピーします。
# cd /tmp; tar -cvf peers.tar peers
- 上記の作成されたファイルを新しいピアにコピーします。
# scp /tmp/peers.tar root@server0.example.com:/tmp
- 展開したコンテンツを
/var/lib/glusterd/peers
ディレクトリーにコピーします。新しく追加したホストで、同じ名前のホスト (server0.example.com)と IP アドレスで、以下のコマンドを実行します。# tar -xvf /tmp/peers.tar # cp peers/* /var/lib/glusterd/peers/
- 手順 5 で選択したノード (server1.example.com) 以外のクラスター内の他のホストを選択します。以下のコマンドを実行して、手順 5 で取得したホストの UUID に対応するピアファイルを新しいホスト (server0.example.com) にコピーします。
# scp /var/lib/glusterd/peers/<UUID-retrieved-from-step5> root@Example1:/var/lib/glusterd/peers/
glusterd
サービスを起動します。# systemctl start glusterd
- 新しいブリックに同じホスト名と同じパスがある場合には 「ボリュームでのブリックの再設定」 を参照して、複製されたボリュームのホスト名と異なるブリックパスがある場合は、「Replicate または Distribute-replicate ボリュームの古いブログを新しいブログに置き換え」 を参照してください。
- ボリュームを分散する場合には、新しいブリックにホスト名があり、異なるブリックパスがある場合には、「古いブリックを、Distributed-Dispersed ボリュームまたは分散ボリュームで新しいブログに置き換え」 を参照してください。
- 復元されたボリュームで自己修復操作を実行します。
# gluster volume heal VOLNAME
- gluster ボリュームの自己修復ステータスを表示するには、以下のコマンドを実行します。
# gluster volume heal VOLNAME info
- geo レプリケーションセッションが設定されている場合は、以下の手順を実行します。
- ssh キーを生成して、geo レプリケーションセッションを設定します。
# gluster system:: execute gsec_create
force
オプションを指定して、ジオレプリケーションセッションを再度作成して、新しいノードから Slave ノードにキーを配布します。# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL create push-pem force
- 共有ストレージボリュームの設定に成功すると、新しいノードがクラスターに置き換えられると、共有ストレージはこのノードに自動的にマウントされません。このノードの共有ストレージ用に
/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/ に変更されました。共有ストレージボリュームの設定についての詳細は、「共有ストレージボリュームの設定」 を参照してください。 - geo レプリケーションのメタボリュームを設定します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config use_meta_volume true
force
オプションを使用してジオレプリケーションセッションを起動します。# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start force
2 ノードの Red Hat Gluster Storage の信頼ストレージプールで、同じホスト名を持つホストの置き換え
ホスト server0.example.com を置き換える必要がある Red Hat Gluster Storage Trusted Storage Pool にホストが 2 つしかない場合は、以下の手順を実行します。
- 以下のコマンドを実行して geo レプリケーションセッションを停止します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop force
- server0.example.com で
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 ソフトウェアコンポーネントおよびバージョン』 を参照してください。 - 以下のコマンドを実行して、Red Hat Gluster Storage Trusted Storage Pool の別のピアから障害のあるホストの UUID (server0.example.com) を取得します。
# gluster peer status Number of Peers: 1 Hostname: server0.example.com Uuid: b5ab2ec3-5411-45fa-a30f-43bd04caf96b State: Peer Rejected (Connected)
障害が発生したホストの UUID はb5ab2ec3-5411-45fa-a30f-43bd04caf96b
です。 - 新しいホスト (server0.example.com) で
glusterd.info
ファイルを編集し、前の手順で取得したホストの UUID を追加します。# cat /var/lib/glusterd/glusterd.info UUID=b5ab2ec3-5411-45fa-a30f-43bd04caf96b operating-version=30703
注記このノードの操作バージョンは、信頼できるストレージプールの他のノードと同じである必要があります。 - 新たに作成したホスト (server0.example.com) に、他のホストの UUID の名前 (server1.example.com) の名前とともに、/var/lib/glusterd/peers/<uuid-of-other-peer を、新たに作成したホスト (server0.example.com) に作成します。ホストの UUID は、以下を使用して取得できます。
# gluster system:: uuid get
例11.6 ホストの UUID を取得する例
For example, # gluster system:: uuid get UUID: 1d9677dc-6159-405e-9319-ad85ec030880
この場合、他のピアの UUID は1d9677dc-6159-405e-9319-ad85ec030880
になります。 - 以下のコマンドを実行して、
/var/lib/glusterd/peers/1d9677dc-6159-405e-9319-ad85ec030880
を server0.example.com に作成します。# touch /var/lib/glusterd/peers/1d9677dc-6159-405e-9319-ad85ec030880
作成するファイルには以下の情報が含まれている必要があります。UUID=<uuid-of-other-node> state=3 hostname=<hostname>
- 前の手順で説明しているように、手順 12 から 18 までを実施します。
11.11. ボリュームのリバランス
# gluster volume rebalance VOLNAME start
# gluster volume rebalance test-volume start Starting rebalancing on volume test-volume has been successful
# gluster volume rebalance VOLNAME start force
# gluster volume rebalance test-volume start force Starting rebalancing on volume test-volume has been successful
11.11.1. リバランススロットリング
normal
モードで起動されます。ファイルの移行速度を調整するためにスロットリングモードを設定
# gluster volume set VOLNAME rebal-throttle lazy|normal|aggressive
# gluster volume set test-volume rebal-throttle lazy
11.11.2. リバランス中の表示
# gluster volume rebalance VOLNAME status
# gluster volume rebalance test-volume status Node Rebalanced size scanned failures skipped status run time -files in h:m:s ------------- ---------- ------ ------- -------- ------- ----------- -------- localhost 71962 70.3GB 380852 0 0 in progress 2:02:20 server1 70489 68.8GB 502185 0 0 in progress 2:02:20 server2 70704 69.0GB 507728 0 0 in progress 2:02:20 server3 71819 70.1GB 435611 0 0 in progress 2:02:20 Estimated time left for rebalance to complete : 2:50:24
表11.2 リバランスステータスの出力の説明
プロパティー名 | 説明 |
---|---|
ノード | ノードの名前。 |
Rebalanced-files | 正常に移行されたファイルの数。 |
size | 移行されたファイルの合計サイズ。 |
スキャン済み | ノード上でスキャンしたファイルの数。これには、移行したファイルが含まれます。 |
failures | エラーが原因で移行できなかったファイルの数。 |
skipped | さまざまなエラーや理由でスキップされたファイルの数。 |
status | ノードのリバランス操作のステータスは in progress 、completed 、および or failed です。 |
run time in h:m:s | プロセスがノードで実行されている時間。 |
>2 months
として表示されます。ユーザーは、後で再度確認することが推奨されます。
completed
とみなされます。以下に例を示します。
# gluster volume rebalance test-volume status Node Rebalanced size scanned failures skipped status run time -files in h:m:s ---------- ---------- ----- ------- -------- ------- ----------- -------- node2 0 0Bytes 0 0 0 completed 0:02:23 node3 234 737.8KB 3350 0 257 completed 0:02:25 node4 3 14.6K 71 0 6 completed 0:00:02 localhost 317 1.1MB 3484 0 155 completed 0:02:38 volume rebalance: test-volume: success
rebalance log
で利用できます。ログファイルからメッセージ ID を検索し、省略されたファイルの一覧を取得できます。
# grep -i 109126 /var/log/glusterfs/test-volume-rebalance.log [2018-03-15 09:14:30.203393] I [MSGID: 109126] [dht-rebalance.c:2715:gf_defrag_migrate_single_file] 0-test-volume-dht: File migration skipped for /linux-4.9.27/Documentation/ABI/stable/sysfs-fs-orangefs. [2018-03-15 09:14:31.262969] I [MSGID: 109126] [dht-rebalance.c:2715:gf_defrag_migrate_single_file] 0-test-volume-dht: File migration skipped for /linux-4.9.27/Documentation/ABI/stable/sysfs-devices. [2018-03-15 09:14:31.842631] I [MSGID: 109126] [dht-rebalance.c:2715:gf_defrag_migrate_single_file] 0-test-volume-dht: File migration skipped for /linux-4.9.27/Documentation/ABI/stable/sysfs-devices-system-cpu. [2018-03-15 09:14:33.733728] I [MSGID: 109126] [dht-rebalance.c:2715:gf_defrag_migrate_single_file] 0-test-volume-dht: File migration skipped for /linux-4.9.27/Documentation/ABI/testing/sysfs-bus-fcoe. [2018-03-15 09:14:35.576404] I [MSGID: 109126] [dht-rebalance.c:2715:gf_defrag_migrate_single_file] 0-test-volume-dht: File migration skipped for /linux-4.9.27/Documentation/ABI/testing/sysfs-bus-iio-frequency-ad9523. [2018-03-15 09:14:43.378480] I [MSGID: 109126] [dht-rebalance.c:2715:gf_defrag_migrate_single_file] 0-test-volume-dht: File migration skipped for /linux-4.9.27/Documentation/DocBook/kgdb.tmpl.
11.11.3. リバランス操作の停止
# gluster volume rebalance VOLNAME stop
# gluster volume rebalance test-volume stop Node Rebalanced size scanned failures skipped status run time -files in h:m:s ------------- ---------- ------- ------- -------- ------- ----------- -------- localhost 106504 104.0GB 558111 0 0 stopped 3:02:24 server1 102299 99.9GB 725239 0 0 stopped 3:02:24 server2 102264 99.9GB 737364 0 0 stopped 3:02:24 server3 106813 104.3GB 646581 0 0 stopped 3:02:24 Estimated time left for rebalance to complete : 2:06:38
11.12. 共有ストレージボリュームの設定
gluster_shared_storage
という名前の Gluster ボリュームが作成され、以下のボリュームセットオプションで容易になっています。
cluster.enable-shared-storage
enable
volume set オプションを有効にすると、
gluster_shared_storage
という名前の gluster ボリュームがクラスターに作成され、クラスター内のすべてのノードの/var/run/gluster/shared_storage
にマウントされます。注記3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。注記- このオプションは、クラスターにノードが 1 つだけ存在する場合や、クラスターに 1 つのノードのみがオンラインになっている場合には、有効にすることはできません。
- 作成されたボリュームはレプリカ 3 ボリュームです。これは、このオプションを有効にする際にクラスターでオンラインになっているノードの数によって異なり、これらのノードはそれぞれボリュームに参加します。ボリュームに参加するブリックパスは
/var/lib/glusterd/ss_brick
です。 - マウントエントリーは、
enable
の一部として/etc/fstab
にも追加されます。 - この機能を有効にする前に、クラスター内に
gluster_shared_storage
という名前のボリュームがないことを確認してください。このボリューム名は内部用にのみ予約されています。
共有ストレージボリュームの設定後に、新しいノードがクラスターに追加されると、共有ストレージはこのノードに自動的にマウントされません。このノードの共有ストレージ用に/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
disable
volume set オプションが無効になっていると、クラスターのすべてのノードで
gluster_shared_storage
ボリュームがアンマウントされ、ボリュームが削除されます。disable
の一部として/etc/fstab
からマウントエントリーも削除されます。
# gluster volume set all cluster.enable-shared-storage enable volume set: success
systemctl enable glusterfssharedstorage.service
11.13. ボリュームの停止
# gluster volume stop VOLNAME
# gluster volume stop test-volume
Stopping volume will make its data inaccessible. Do you want to continue? (y/n) y
Stopping volume test-volume has been successful
11.14. ボリュームの削除
/etc/fstab
ファイルから、このボリュームに関連するエントリーも削除してください。
# gluster volume delete VOLNAME
# gluster volume delete test-volume
Deleting volume will erase all information about the volume. Do you want to continue? (y/n) y
Deleting volume test-volume has been successful
11.15. スプリットブレインの管理
- データスプリットブレイン: スプリットブレインの下にあるファイルのコンテンツはレプリカのペアで異なり、自動修復はできません。Red Hat では、マウントポイントと CLI からデータスプリットブレインを解決できます。マウントポイントからデータスプリットブレインから回復する方法は、「 マウントポイントからのファイルスプリットブレインの復旧」 を参照してください。CLIS を使用してデータをスプリットブレインからリカバリーする方法は、「gluster CLI からのファイルスプリットブレインのリカバリー」 を参照してください。
- メタデータスプリットブレイン: ユーザー定義の拡張属性などのファイルのメタデータは異なり、自動修復はできません。データのスプリットブレインと同様に、メタデータスプリットブレインは、マウントポイントと CLI の両方から解決することもできます。マウントポイントからメタデータスプリットブレインから回復する方法は、「 マウントポイントからのファイルスプリットブレインの復旧」 を参照してください。CLI を使用してメタデータスプリットブレインから回復する方法は、「gluster CLI からのファイルスプリットブレインのリカバリー」 を参照してください。
- エントリースプリットブレイン: エントリースプリットブレインには、以下の 2 つのタイプを使用できます。
- GlusterFS 内部ファイル識別子または GFID スプリットブレイン: 異なるレプリカペアのファイルまたはディレクトリーの GFID が異なる場合に発生します。
- タイプ不一致のスプリットブレイン: レプリカのペアに保存されているファイル/ディレクトリーのタイプが異なるものの、同じ名前のファイルである場合に発生します。
Red Hat Gluster Storage 3.4 以降では、gluster CLI から GFID スプリットブレインを解決できます。詳細は、「gluster CLI からの GFID スプリットブレインのリカバリー」 を参照してください。バックエンドのファイルの内容を検査し、実際のコピー (ソース) を決定し、修復が自動的に行われるように適切な拡張属性を変更することで、スプリットブレインを手動で解決できます。
11.15.1. スプリットブレインの防止
11.15.1.1. サーバー側のクォーラムの設定
server
として設定して、特定のボリュームでクォーラムを有効にする必要があります。このボリュームオプションについての詳細は、「ボリュームオプションの設定」 を参照してください。
glusterd
サービスです。マシンの glusterd
サービスがクォーラムが満たされていないことを確認するたびに、ブリックがダウンし、データのスプリットブレインを防ぎます。ネットワーク接続が切断され、クォーラムが回復すると、ボリュームのブリックが元に戻ります。クォーラムがボリュームで満たされない場合、ボリューム設定またはピアの追加または割り当てを更新するコマンドは使用できません。どちらにも記載されているように、glusterd
サービスは実行されず、ダウンしている 2 つのマシン間のネットワーク接続は同等に処理されます。
# gluster volume set all cluster.server-quorum-ratio PERCENTAGE
# gluster volume set all cluster.server-quorum-ratio 51%
# gluster volume set VOLNAME cluster.server-quorum-type server
11.15.1.2. クライアント側クォーラムの設定
クライアント側のクォーラムオプション
- cluster.quorum-count
- 書き込みを許可するのに必要なブリックの最小数。これはボリュームごとに設定されます。有効な値は、レプリカセットの
1
からブリックの数になります。このオプションは、書き込み動作を決定するためにcluster.quorum-type
オプションによって使用されます。このオプションは、cluster.quorum-type =fixed
オプションと併用し、クォーラムに参加するためにアクティブなブリックの数を指定します。quorum-type がauto
の場合、このオプションには大きな影響はありません。 - cluster.quorum-type
- クライアントがボリュームへの書き込みを許可されるタイミングを決定します。有効な値は
fixed
およびauto
です。cluster.quorum-type
がfixed
の場合は、レプリカセットで利用可能なブリックの数がcluster.quorum-count
オプションの値以上であれば、書き込みが許可されます。cluster.quorum-type
がauto
の場合、レプリカセット内のブリックの 50% 以上が利用できる場合に書き込みが許可されます。一連のブリックを持つレプリカセットでは、ブリックの 50% が利用可能であれば、書き込みを続行するには、レプリカセットの最初のブリックが利用可能でなければなりません。3 方向のレプリケーション設定では、スプリットブレインを回避するためにcluster.quorum-type
をauto
に設定することが推奨されます。クォーラムを満たさないと、レプリカのペアは読み取り専用になります。
例11.7 クライアント側のクォーラム
A
にクライアント側のクォーラムが満たされないと、レプリカグループ A
のみが読み取り専用になります。レプリカグループ B
および C
を続行して、データの変更を可能にします。
cluster.quorum-type
および cluster.quorum-count
オプションを使用してクライアント側のクォーラムを設定します。
# gluster volume reset VOLNAME quorum-type
例: スプリットブレインのシナリオを回避するためにサーバー側およびクライアント側のクォーラムを設定
この例では、スプリットブレインのシナリオを回避するために、Distribute Replicate ボリュームでサーバー側およびクライアント側のクォーラムを設定する方法を説明します。この例の設定には、3 X 3(9 ブリック) の Distribute Replicate が設定されています。
# gluster volume info testvol Volume Name: testvol Type: Distributed-Replicate Volume ID: 0df52d58-bded-4e5d-ac37-4c82f7c89cfh Status: Created Number of Bricks: 3 x 3 = 9 Transport-type: tcp Bricks: Brick1: server1:/rhgs/brick1 Brick2: server2:/rhgs/brick2 Brick3: server3:/rhgs/brick3 Brick4: server4:/rhgs/brick4 Brick5: server5:/rhgs/brick5 Brick6: server6:/rhgs/brick6 Brick7: server7:/rhgs/brick7 Brick8: server8:/rhgs/brick8 Brick9: server9:/rhgs/brick9
# gluster volume set VOLNAME cluster.server-quorum-type server
# gluster volume set all cluster.server-quorum-ratio 51%
quorum-type
オプションを auto
に設定します。
# gluster volume set VOLNAME quorum-type auto
n
) が偶数の場合は、n/2
数はプライマリーブリックで構成される必要があり、稼働して実行する必要があります。n
が正の数の場合には、n/2
数にブリックを起動して実行できます。つまり、プライマリーブリックは起動せず、書き込みを許可するために稼働する必要があります。
11.15.2. ファイルスプリットブレインからのリカバリー
- マウントポイントからデータおよびメタデータの分割ブレインから回復する方法は、「 マウントポイントからのファイルスプリットブレインの復旧」 を参照してください。
- CLI を使用してデータおよびメタデータプリッとブレインから回復する方法は、「gluster CLI からのファイルスプリットブレインのリカバリー」 を参照してください。
11.15.2.1. マウントポイントからのファイルスプリットブレインの復旧
マウントポイントからスプリットブレインから復旧する手順
- 一連の getfattr および setfattr コマンドを使用して、ファイルのデータおよびメタデータのスプリットブレイン状態を検出し、マウントポイントからスプリットブレインを解決できます。重要このマウントのスプリットブレインのプロセスは、拡張属性のサポートを提供しないため、NFS マウントでは機能しません。この例では、test-volumeボリュームには、brick0、brick1、 brick2、brick3があります。
# gluster volume info test-volume Volume Name: test-volume Type: Distributed-Replicate Status: Started Number of Bricks: 2 x 2 = 4 Transport-type: tcp Bricks: Brick1: test-host:/rhgs/brick0 Brick2: test-host:/rhgs/brick1 Brick3: test-host:/rhgs/brick2 Brick4: test-host:/rhgs/brick3
ブリックのディレクトリー構造は以下のようになります。# tree -R /test/b? /rhgs/brick0 ├── dir │ └── a └── file100 /rhgs/brick1 ├── dir │ └── a └── file100 /rhgs/brick2 ├── dir ├── file1 ├── file2 └── file99 /rhgs/brick3 ├── dir ├── file1 ├── file2 └── file99
以下の出力では、ボリューム内の一部のファイルがスプリットブレインにあります。# gluster volume heal test-volume info split-brain Brick test-host:/rhgs/brick0/ /file100 /dir Number of entries in split-brain: 2 Brick test-host:/rhgs/brick1/ /file100 /dir Number of entries in split-brain: 2 Brick test-host:/rhgs/brick2/ /file99 <gfid:5399a8d1-aee9-4653-bb7f-606df02b3696> Number of entries in split-brain: 2 Brick test-host:/rhgs/brick3/ <gfid:05c4b283-af58-48ed-999e-4d706c7b97d5> <gfid:5399a8d1-aee9-4653-bb7f-606df02b3696> Number of entries in split-brain: 2
ファイルのデータまたはメタデータのスプリットブレインステータスを確認するには、以下を実行します。# getfattr -n replica.split-brain-status <path-to-file>
上記のコマンドは、ファイルがデータまたはメタデータのスプリットブレインにある場合に、mount から実行される情報を提供します。このコマンドはエントリー/タイプミスマッチスプリットブレインには適用されません。以下に例を示します。file100
はメタデータスプリットブレインにあります。file100
に対して上記のコマンドを実行すると、以下 が可能になります。# getfattr -n replica.split-brain-status file100 # file: file100 replica.split-brain-status="data-split-brain:no metadata-split-brain:yes Choices:test-client-0,test-client-1"
file1
はデータスプリットブレインにあります。# getfattr -n replica.split-brain-status file1 # file: file1 replica.split-brain-status="data-split-brain:yes metadata-split-brain:no Choices:test-client-2,test-client-3"
file99
は data と meta-data split-brain の両方にあります。# getfattr -n replica.split-brain-status file99 # file: file99 replica.split-brain-status="data-split-brain:yes metadata-split-brain:yes Choices:test-client-2,test-client-3"
dir
はentry/type-mismatch
スプリットブレインにありますが、前述のように、ファイルがentry/type-mismatch
スプリットブレインにある場合は、上記のコマンドは表示されません。したがって、コマンドはThe file is not under data or metadata split-brain
を表示します。エントリー/タイプミスマッチのスプリットブレインを解決する方法は、23章ファイルのスプリットブレインの手動リカバリー を参照してください。# getfattr -n replica.split-brain-status dir # file: dir replica.split-brain-status="The file is not under data or metadata split-brain"
file2
はあらゆる種類のスプリットブレインにはなりません。# getfattr -n replica.split-brain-status file2 # file: file2 replica.split-brain-status="The file is not under data or metadata split-brain"
データおよびメタデータのスプリットブレイン内のファイルを分析し、問題を解決します。
スプリットブレインのファイルのマウントから
cat
、getfattr
などの操作を実行すると、入出力エラーが発生します。このようなファイルをさらに分析するには、setfattr コマンドを使用できます。# setfattr -n replica.split-brain-choice -v "choiceX" <path-to-file>
このコマンドを使用すると、特定のブリックを選択してスプリットブレイン内のファイルにアクセスできます。以下に例を示します。file1
は data-split-brain にあり、ファイルから読み取ると、入出力エラーが発生します。# cat file1 cat: file1: Input/output error
file1 に提供されるスプリットブレインの選択肢はtest-client-2
およびtest-client-3
でした。test-client-2
を file1 の split-brain choice として設定すると、ファイルについてb2
から読み取りされます。# setfattr -n replica.split-brain-choice -v test-client-2 file1
これで、ファイルで操作を実行することができます。たとえば、ファイルの読み取り操作などです。# cat file1 xyz
同様に、他の選択肢からファイルを検査するには、replica.split-brain-choice
をtest-client-3
に設定します。誤った選択肢のエラーからファイルの検査を試みます。設定した split-brain-choice を元に戻すことができます。上記の setfattr コマンドは、拡張属性の値としてnone
で使用できます。以下に例を示します。# setfattr -n replica.split-brain-choice -v none file1
これで、ファイルでcat
操作を実行した場合、以前と同様に入出力エラーが発生します。# cat file cat: file1: Input/output error
スプリットブレインを解決するソースとして使用するブリックを決定したら、修復するように設定する必要があります。# setfattr -n replica.split-brain-heal-finalize -v <heal-choice> <path-to-file>
例# setfattr -n replica.split-brain-heal-finalize -v test-client-2 file1
上記のプロセスは、すべてのファイルでデータやメタデータのスプリットブレインを解決するために使用できます。ファイルでの split-brain-choice の設定ファイルに split-brain-choice を設定すると、ファイルは 5 分間のみ分析できます。ファイルの分析にかかる時間を増やす必要がある場合は、以下のコマンドを使用して timeout-in-minute 引数で必要な時間を設定します。# setfattr -n replica.split-brain-choice-timeout -v <timeout-in-minutes> <mount_point/file>
これはグローバルタイムアウトで、マウントが存在する限りすべてのファイルに適用されます。タイムアウトは、ファイルを検査するたびに設定する必要はありませんが、新しいマウントの場合は、初回起動時に再度設定する必要があります。add-brick や remove-brick などの操作が実行されると、このオプションは無効になります。注記fopen-keep-cache
FUSE マウントオプションが無効になっている場合は、次のコマンドを実行してファイルを検証する新しいreplica.split-brain-choice
を選択する前に毎回 inode を無効にする必要があります。# setfattr -n inode-invalidate -v 0 <path-to-file>
11.15.2.2. gluster CLI からのファイルスプリットブレインのリカバリー
- より大きなファイルをソースとしてを使用
- 最新の mtime をソースとして使用します。
- 1 つのレプリカを特定のファイルのソースとして使用します。
- すべてのファイルに対して、1 つのレプリカをソースとして使用します。注記
entry/type-mismatch
スプリットブレイン解決は CLI を使用してサポートされていません。entry/type-mismatch
のスプリットブレインを解決する方法は、23章ファイルのスプリットブレインの手動リカバリー を参照してください。
より大きなファイルをソースとして選択
このメソッドは、ファイル修復ごとに有用で、サイズが大きくなるとファイルがソースとして考慮されることが判断されます。
- 以下のコマンドを実行して、スプリットブレインにあるファイルの一覧を取得します。
# gluster volume heal VOLNAME info split-brain
Brick <hostname:brickpath-b1> <gfid:aaca219f-0e25-4576-8689-3bfd93ca70c2> <gfid:39f301ae-4038-48c2-a889-7dac143e82dd> <gfid:c3c94de2-232d-4083-b534-5da17fc476ac> Number of entries in split-brain: 3 Brick <hostname:brickpath-b2> /dir/file1 /dir /file4 Number of entries in split-brain: 3
コマンド出力から、スプリットブレインにあるファイルを特定します。ブリックからファイルで stat および md5 チェックサムを実行すると、ファイルサイズと md5 のチェックサムに違いがあります。以下は、ファイルの stat および md5 のチェックサム出力です。On brick b1: # stat b1/dir/file1 File: ‘b1/dir/file1’ Size: 17 Blocks: 16 IO Block: 4096 regular file Device: fd03h/64771d Inode: 919362 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-03-06 13:55:40.149897333 +0530 Modify: 2015-03-06 13:55:37.206880347 +0530 Change: 2015-03-06 13:55:37.206880347 +0530 Birth: - # md5sum b1/dir/file1 040751929ceabf77c3c0b3b662f341a8 b1/dir/file1 On brick b2: # stat b2/dir/file1 File: ‘b2/dir/file1’ Size: 13 Blocks: 16 IO Block: 4096 regular file Device: fd03h/64771d Inode: 919365 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-03-06 13:54:22.974451898 +0530 Modify: 2015-03-06 13:52:22.910758923 +0530 Change: 2015-03-06 13:52:22.910758923 +0530 Birth: - # md5sum b2/dir/file1 cb11635a45d45668a403145059c2a0d5 b2/dir/file1
ファイルのサイズと md5 チェックサムの違いが確認できます。 - ボリュームのルート (または) の gfid-string 表現から表示される完全なファイル名と共に以下のコマンドを実行します。このファイルは、heal info コマンドの出力に表示されます。
# gluster volume heal <VOLNAME> split-brain bigger-file <FILE>
以下に例を示します。# gluster volume heal test-volume split-brain bigger-file /dir/file1 Healed /dir/file1.
On brick b1: # stat b1/dir/file1 File: ‘b1/dir/file1’ Size: 17 Blocks: 16 IO Block: 4096 regular file Device: fd03h/64771d Inode: 919362 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-03-06 14:17:27.752429505 +0530 Modify: 2015-03-06 13:55:37.206880347 +0530 Change: 2015-03-06 14:17:12.880343950 +0530 Birth: - # md5sum b1/dir/file1 040751929ceabf77c3c0b3b662f341a8 b1/dir/file1 On brick b2: # stat b2/dir/file1 File: ‘b2/dir/file1’ Size: 17 Blocks: 16 IO Block: 4096 regular file Device: fd03h/64771d Inode: 919365 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-03-06 14:17:23.249403600 +0530 Modify: 2015-03-06 13:55:37.206880000 +0530 Change: 2015-03-06 14:17:12.881343955 +0530 Birth: - # md5sum b2/dir/file1 040751929ceabf77c3c0b3b662f341a8 b2/dir/file1
最新の mtime をソースとするファイルの選択
このメソッドはファイル修復ごとに有用で、最新の mtime を持つファイルをソースとして考慮する必要がある場合に役に立ちます。
- 以下のコマンドを実行して、スプリットブレインにあるファイルの一覧を取得します。
# gluster volume heal VOLNAME info split-brain
Brick <hostname:brickpath-b1> <gfid:aaca219f-0e25-4576-8689-3bfd93ca70c2> <gfid:39f301ae-4038-48c2-a889-7dac143e82dd> <gfid:c3c94de2-232d-4083-b534-5da17fc476ac> Number of entries in split-brain: 3 Brick <hostname:brickpath-b2> /dir/file1 /dir /file4 Number of entries in split-brain: 3
コマンド出力から、スプリットブレインにあるファイルを特定します。ブリックからファイルで stat および md5 チェックサムを実行すると、ファイルサイズと md5 のチェックサムに違いがあります。以下は、ファイルの stat および md5 のチェックサム出力です。On brick b1: stat b1/file4 File: ‘b1/file4’ Size: 4 Blocks: 16 IO Block: 4096 regular file Device: fd03h/64771d Inode: 919356 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-03-06 13:53:19.417085062 +0530 Modify: 2015-03-06 13:53:19.426085114 +0530 Change: 2015-03-06 13:53:19.426085114 +0530 Birth: - # md5sum b1/file4 b6273b589df2dfdbd8fe35b1011e3183 b1/file4 On brick b2: # stat b2/file4 File: ‘b2/file4’ Size: 4 Blocks: 16 IO Block: 4096 regular file Device: fd03h/64771d Inode: 919358 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-03-06 13:52:35.761833096 +0530 Modify: 2015-03-06 13:52:35.769833142 +0530 Change: 2015-03-06 13:52:35.769833142 +0530 Birth: - # md5sum b2/file4 0bee89b07a248e27c83fc3d5951213c1 b2/file4
md5 チェックサムと変更時間は相違点です。 - 以下のコマンドを実行します。
# gluster volume heal <VOLNAME> split-brain latest-mtime <FILE>
このコマンドでは、FILE は、ボリュームのルートで表示される完全なファイル名か、ファイルの gfid-string 表現のいずれかになります。以下に例を示します。# gluster volume heal test-volume split-brain latest-mtime /file4 Healed /file4
修復が完了したら、md5 チェックサム、ファイルサイズ、および両方のブリック時間が同じである必要があります。以下は、ファイル修復の完了後の stat および md5 checksums コマンドの出力例です。ブリックには、最新の mtime (brick b1) をソースとして持つことで、ファイルが修復されていることが分かります。On brick b1: # stat b1/file4 File: ‘b1/file4’ Size: 4 Blocks: 16 IO Block: 4096 regular file Device: fd03h/64771d Inode: 919356 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-03-06 14:23:38.944609863 +0530 Modify: 2015-03-06 13:53:19.426085114 +0530 Change: 2015-03-06 14:27:15.058927962 +0530 Birth: - # md5sum b1/file4 b6273b589df2dfdbd8fe35b1011e3183 b1/file4 On brick b2: # stat b2/file4 File: ‘b2/file4’ Size: 4 Blocks: 16 IO Block: 4096 regular file Device: fd03h/64771d Inode: 919358 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-03-06 14:23:38.944609000 +0530 Modify: 2015-03-06 13:53:19.426085000 +0530 Change: 2015-03-06 14:27:15.059927968 +0530 Birth: # md5sum b2/file4 b6273b589df2dfdbd8fe35b1011e3183 b2/file4
特定のファイルのソースとして 1 つのレプリカを選択する
このメソッドは、どのファイルをソースとして考慮するかを把握する場合に便利です。
- 以下のコマンドを実行して、スプリットブレインにあるファイルの一覧を取得します。
# gluster volume heal VOLNAME info split-brain
Brick <hostname:brickpath-b1> <gfid:aaca219f-0e25-4576-8689-3bfd93ca70c2> <gfid:39f301ae-4038-48c2-a889-7dac143e82dd> <gfid:c3c94de2-232d-4083-b534-5da17fc476ac> Number of entries in split-brain: 3 Brick <hostname:brickpath-b2> /dir/file1 /dir /file4 Number of entries in split-brain: 3
コマンド出力から、スプリットブレインにあるファイルを特定します。ブリックからファイルで stat および md5 チェックサムを実行すると、ファイルサイズと md5 のチェックサムに違いがあります。以下は、ファイルの stat および md5 のチェックサム出力です。On brick b1: stat b1/file4 File: ‘b1/file4’ Size: 4 Blocks: 16 IO Block: 4096 regular file Device: fd03h/64771d Inode: 919356 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-03-06 13:53:19.417085062 +0530 Modify: 2015-03-06 13:53:19.426085114 +0530 Change: 2015-03-06 13:53:19.426085114 +0530 Birth: - # md5sum b1/file4 b6273b589df2dfdbd8fe35b1011e3183 b1/file4 On brick b2: # stat b2/file4 File: ‘b2/file4’ Size: 4 Blocks: 16 IO Block: 4096 regular file Device: fd03h/64771d Inode: 919358 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-03-06 13:52:35.761833096 +0530 Modify: 2015-03-06 13:52:35.769833142 +0530 Change: 2015-03-06 13:52:35.769833142 +0530 Birth: - # md5sum b2/file4 0bee89b07a248e27c83fc3d5951213c1 b2/file4
ファイルのサイズと md5 チェックサムの違いが確認できます。 - 以下のコマンドを実行します。
# gluster volume heal <VOLNAME> split-brain source-brick <HOSTNAME:BRICKNAME> <FILE>
このコマンドでは、<HOSTNAME:BRICKNAME> に存在する FILE が、修復のソースとして取得されます。以下に例を示します。# gluster volume heal test-volume split-brain source-brick test-host:b1 /file4 Healed /file4
修復が完了したら、両方のブリックの md5 チェックサムとファイルサイズが同じである必要があります。以下は、ファイル修復の完了後の stat および md5 checksums コマンドの出力例です。On brick b1: # stat b1/file4 File: ‘b1/file4’ Size: 4 Blocks: 16 IO Block: 4096 regular file Device: fd03h/64771d Inode: 919356 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-03-06 14:23:38.944609863 +0530 Modify: 2015-03-06 13:53:19.426085114 +0530 Change: 2015-03-06 14:27:15.058927962 +0530 Birth: - # md5sum b1/file4 b6273b589df2dfdbd8fe35b1011e3183 b1/file4 On brick b2: # stat b2/file4 File: ‘b2/file4’ Size: 4 Blocks: 16 IO Block: 4096 regular file Device: fd03h/64771d Inode: 919358 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-03-06 14:23:38.944609000 +0530 Modify: 2015-03-06 13:53:19.426085000 +0530 Change: 2015-03-06 14:27:15.059927968 +0530 Birth: - # md5sum b2/file4 b6273b589df2dfdbd8fe35b1011e3183 b2/file4
全ファイルの 1 つのレプリカをソースとして選択
このメソッドは、特定のブリックをレプリカのペアのスプリットブレインファイルのソースとして使用する場合に便利です。
- 以下のコマンドを実行して、スプリットブレインにあるファイルの一覧を取得します。
# gluster volume heal VOLNAME info split-brain
コマンド出力から、スプリットブレインにあるファイルを特定します。 - 以下のコマンドを実行します。
# gluster volume heal <VOLNAME> split-brain source-brick <HOSTNAME:BRICKNAME>
このコマンドでは、このレプリカのスプリットブレインにあるすべてのファイルについて、<HOSTNAME:BRICKNAME> 修復のソースとして取得されます。以下に例を示します。# gluster volume heal test-volume split-brain source-brick test-host:b1
11.15.3. gluster CLI からの GFID スプリットブレインのリカバリー
- より大きなファイルをソースとしてを使用
- 最新の mtime をソースとして使用します。
- 1 つのレプリカを特定のファイルのソースとして使用します。
より大きなファイルをソースとして選択
このメソッドは、ファイル修復ごとに有用で、サイズが大きくなるとファイルがソースとして考慮されることが判断されます。
- 以下のコマンドを実行して、スプリットブレインにあるファイルのパスを取得します。
# gluster volume heal VOLNAME info split-brain
出力から、クライアントから実行されたファイル操作が入出力エラーで失敗したファイルを特定します。以下に例を示します。# gluster volume heal 12 info split-brain
Brick 10.70.47.45:/bricks/brick2/b0 /f5 / - Is in split-brain Status: Connected Number of entries: 2 Brick 10.70.47.144:/bricks/brick2/b1 /f5 / - Is in split-brain Status: Connected Number of entries: 2
上記のコマンドでは、12 がボリューム名、b0、b1 がブリックです。 - ファイルが GFID スプリットブレインにある場合は、ブリックで以下のコマンドを実行し、情報を取得します。getfattr コマンドは、ファイルの AFR changelog 拡張属性を取得および検証するために使用されます。
# getfattr -d -e hex -m. <path-to-file>
以下に例を示します。On brick /b0 # getfattr -d -m . -e hex /bricks/brick2/b0/f5 getfattr: Removing leading '/' from absolute path names # file: bricks/brick2/b0/f5 security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 trusted.afr.12-client-1=0x000000020000000100000000 trusted.afr.dirty=0x000000000000000000000000 trusted.gfid=0xce0a9956928e40afb78e95f78defd64f trusted.gfid2path.9cde09916eabc845=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6635 On brick /b1 # getfattr -d -m . -e hex /bricks/brick2/b1/f5 getfattr: Removing leading '/' from absolute path names # file: bricks/brick2/b1/f5 security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 trusted.afr.12-client-0=0x000000020000000100000000 trusted.afr.dirty=0x000000000000000000000000 trusted.gfid=0x9563544118653550e888ab38c232e0c trusted.gfid2path.9cde09916eabc845=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6635
ファイル f5 の GFID の相違点は、両方のブリックで異なります。ファイルサイズの相違点は、ブリックのファイルで stat コマンドを実行すると、ファイルサイズに違いがあります。以下は、b0 および b1 内の f5 ファイルの出力です。On brick /b0 # stat /bricks/brick2/b0/f5 File: ‘/bricks/brick2/b0/f5’ Size: 15 Blocks: 8 IO Block: 4096 regular file Device: fd15h/64789d Inode: 67113350 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:glusterd_brick_t:s0 Access: 2018-08-29 20:46:26.353751073 +0530 Modify: 2018-08-29 20:46:26.361751203 +0530 Change: 2018-08-29 20:47:16.363751236 +0530 Birth: - On brick /b1 # stat /bricks/brick2/b1/f5 File: ‘/bricks/brick2/b1/f5’ Size: 2 Blocks: 8 IO Block: 4096 regular file Device: fd15h/64789d Inode: 67111750 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:glusterd_brick_t:s0 Access: 2018-08-29 20:44:56.153301616 +0530 Modify: 2018-08-29 20:44:56.161301745 +0530 Change: 2018-08-29 20:44:56.162301761 +0530 Birth: -
- heal info コマンドの出力に表示されるボリュームのルートから表示されたように、完全なファイル名とともに以下のコマンドを実行します。
# gluster volume heal VOLNAME split-brain bigger-file FILE
以下に例を示します。# gluster volume heal12 split-brain bigger-file /f5 GFID split-brain resolved for file /f5
修復が完了したら、両方のブリックのファイルサイズは、サイズが大きいファイルと同じである必要があります。以下は、ファイル修復の完了後の getfattr コマンドの出力例です。On brick /b0 # getfattr -d -m . -e hex /bricks/brick2/b0/f5 getfattr: Removing leading '/' from absolute path names # file: bricks/brick2/b0/f5 security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 trusted.gfid=0xce0a9956928e40afb78e95f78defd64f trusted.gfid2path.9cde09916eabc845=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6635 On brick /b1 # getfattr -d -m . -e hex /bricks/brick2/b1/f5 getfattr: Removing leading '/' from absolute path names # file: bricks/brick2/b1/f5 security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 trusted.gfid=0xce0a9956928e40afb78e95f78defd64f trusted.gfid2path.9cde09916eabc845=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6635
最新の mtime をソースとするファイルの選択
このメソッドはファイル修復ごとに有用で、最新の mtime を持つファイルをソースとして考慮する必要がある場合に役に立ちます。
- 以下のコマンドを実行して、スプリットブレインにあるファイルの一覧を取得します。
# gluster volume heal VOLNAME info split-brain
出力から、クライアントから実行されたファイル操作が入出力エラーで失敗したファイルを特定します。以下に例を示します。# gluster volume heal 12 info split-brain
Brick 10.70.47.45:/bricks/brick2/b0 /f4 / - Is in split-brain Status: Connected Number of entries: 2 Brick 10.70.47.144:/bricks/brick2/b1 /f4 / - Is in split-brain Status: Connected Number of entries: 2
上記のコマンドでは、12 がボリューム名、b0、b1 がブリックです。 - バックエンドから実行される以下のコマンドは、ファイルが GFID スプリットブレインにある場合に情報を提供します。
# getfattr -d -e hex -m. <path-to-file>
以下に例を示します。On brick /b0 # getfattr -d -m . -e hex /bricks/brick2/b0/f4 getfattr: Removing leading '/' from absolute path names # file: bricks/brick2/b0/f4 security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 trusted.afr.12-client-1=0x000000020000000100000000 trusted.afr.dirty=0x000000000000000000000000 trusted.gfid=0xb66b66d07b315f3c9cffac2fb6422a28 trusted.gfid2path.364f55367c7bd6f4=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6634 On brick /b1 # getfattr -d -m . -e hex /bricks/brick2/b1/f4 getfattr: Removing leading '/' from absolute path names # file: bricks/brick2/b1/f4 security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 trusted.afr.12-client-0=0x000000020000000100000000 trusted.afr.dirty=0x000000000000000000000000 trusted.gfid=0x87242f808c6e56a007ef7d49d197acff trusted.gfid2path.364f55367c7bd6f4=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6634
ファイル f4 の GFID の相違点は、両方のブリックで異なります。ブリックからのファイルで stat コマンドを実行すると、変更時間に違いがあります。以下は、ブリック b0 および b1 内のファイル f4 の出力です。On brick /b0 # stat /bricks/brick2/b0/f4 File: ‘/bricks/brick2/b0/f4’ Size: 14 Blocks: 8 IO Block: 4096 regular file Device: fd15h/64789d Inode: 67113349 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:glusterd_brick_t:s0 Access: 2018-08-29 20:57:38.913629991 +0530 Modify: 2018-08-29 20:57:38.921630122 +0530 Change: 2018-08-29 20:57:38.923630154 +0530 Birth: - On brick /b1 # stat /bricks/brick2/b1/f4 File: ‘/bricks/brick2/b1/f4’ Size: 2 Blocks: 8 IO Block: 4096 regular file Device: fd15h/64789d Inode: 67111749 Links: 2 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Context: system_u:object_r:glusterd_brick_t:s0 Access: 2018-08-24 20:54:50.953217256 +0530 Modify: 2018-08-24 20:54:50.961217385 +0530 Change: 2018-08-24 20:54:50.962217402 +0530 Birth: -
- 以下のコマンドを実行します。
# gluster volume healVOLNAME split-brain latest-mtime FILE
以下に例を示します。# gluster volume heal 12 split-brain latest-mtime /f4 GFID split-brain resolved for file /f4
修復が完了したら、両方のブリックにあるファイルの GFID が同じである必要があります。以下は、ファイル修復の完了後の getfattr コマンドの出力例です。ブリックは、最新の mtime をソースとして使用することで、ファイルを修復していることが分かります。On brick /b0 # getfattr -d -m . -e hex /bricks/brick2/b0/f4 getfattr: Removing leading '/' from absolute path names # file: bricks/brick2/b0/f4 security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 trusted.gfid=0xb66b66d07b315f3c9cffac2fb6422a28 trusted.gfid2path.364f55367c7bd6f4=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6634 On brick /b1 # getfattr -d -m . -e hex /bricks/brick2/b1/f4 getfattr: Removing leading '/' from absolute path names # file: bricks/brick2/b1/f4 security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 trusted.gfid=0xb66b66d07b315f3c9cffac2fb6422a28 trusted.gfid2path.364f55367c7bd6f4=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6634
特定のファイルのソースとして 1 つのレプリカを選択する
このメソッドは、どのファイルをソースとして考慮するかを把握する場合に便利です。
- 以下のコマンドを実行して、スプリットブレインにあるファイルの一覧を取得します。
# gluster volume heal VOLNAME info split-brain
出力から、クライアントから実行されたファイル操作が入出力エラーで失敗したファイルを特定します。以下に例を示します。# gluster volume heal 12 info split-brain
Brick 10.70.47.45:/bricks/brick2/b0 /f3 / - Is in split-brain Status: Connected Number of entries: 2 Brick 10.70.47.144:/bricks/brick2/b1 /f3 / - Is in split-brain Status: Connected Number of entries: 2
上記のコマンドでは、12 がボリューム名、b0、b1 がブリックです。注記1 つのレプリカをソースオプションとして使用し、データ/メタデータスプリットブレインに対して実行できるように、CLI でファイルパスを指定しないことで、すべての GFID スプリットブレインを解決する方法はありません。GFID 分割ブレインの各ファイルについて、heal コマンドを個別に実行する必要があります。 - バックエンドから実行される以下のコマンドは、ファイルが GFID スプリットブレインにある場合に情報を提供します。
# getfattr -d -e hex -m. <path-to-file>
以下に例を示します。# getfattr -d -m . -e hex /bricks/brick2/b0/f3 On brick /b0 getfattr: Removing leading '/' from absolute path names # file: bricks/brick2/b0/f3 security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 trusted.afr.12-client-1=0x000000020000000100000000 trusted.afr.dirty=0x000000000000000000000000 trusted.gfid=0x9d542fb1b3b15837a2f7f9dcdf5d6ee8 trusted.gfid2path.364f55367c7bd6f4=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6634 On brick /b1 # getfattr -d -m . -e hex /bricks/brick2/b1/f3 getfattr: Removing leading '/' from absolute path names # file: bricks/brick2/b0/f3 security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 trusted.afr.12-client-1=0x000000020000000100000000 trusted.afr.dirty=0x000000000000000000000000 trusted.gfid=0xc90d9b0f65f6530b95b9f3f8334033df trusted.gfid2path.364f55367c7bd6f4=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6634
両方のブリック内の f3 ファイルの GFID の相違点が確認できます。 - 以下のコマンドを実行します。
# gluster volume heal VOLNAME split-brain source-brick HOSTNAME : export-directory-absolute-path FILE
このコマンドでは、HOSTNAME : export-directory-absolute-path にある FILE は、修復のソースとして取得されます。以下に例を示します。# gluster volume heal 12 split-brain source-brick 10.70.47.144:/bricks/brick2/b1 /f3 GFID split-brain resolved for file /f3
修復が完了したら、両方のブリックファイルの GFID は、サイズが大きいファイルと同じである必要があります。以下は、ファイル修復後の getfattr コマンドの出力例です。On brick /b0 # getfattr -d -m . -e hex /bricks/brick2/b0/f3 getfattr: Removing leading '/' from absolute path names # file: bricks/brick2/b0/f3 security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 trusted.gfid=0x90d9b0f65f6530b95b9f3f8334033df trusted.gfid2path.364f55367c7bd6f4=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6634 On brick /b1 # getfattr -d -m . -e hex /bricks/brick2/b1/f3 getfattr: Removing leading '/' from absolute path names # file: bricks/brick2/b1/f3 security.selinux=0x73797374656d5f753a6f626a6563745f723a676c7573746572645f627269636b5f743a733000 trusted.gfid=0x90d9b0f65f6530b95b9f3f8334033df trusted.gfid2path.364f55367c7bd6f4=0x30303030303030302d303030302d303030302d303030302d3030303030303030303030312f6634
注記ファイルの GFID を CLI オプションのある引数として使用して GFID スプリットブレインを解決することはできません。マウントポイントからソースとみなされるファイルの絶対パスである必要があります。source-brick オプションでは、データまたはメタデータの分割ブレインの解決中に、CLI でファイルパスを指定しないことで、すべての GFID スプリットブレインを解決する方法はありません。GFID 分割ブレインの各ファイルについて、使用するポリシーを指定して CLI を実行します。「distributed-replicated」ボリュームの「source-brick」オプションを使用した CLI を使用したディレクトリー GFID スプリットの解決は、すべてのボリュームで明示的に実行する必要があります。ディレクトリーはすべてのサブボリュームで作成され、ある特定のブリックを GFID スプリットブレインのソースとして使用し、そのサブボリュームのディレクトリーを修復します。この場合、他のサブボリュームは、他のサブボリュームのソースとして使用されていた以前のブリックと同じ GFID を持つブリックを使用して修復する必要があります。entry/type-mismatch
のスプリットブレインを解決する方法は、23章ファイルのスプリットブレインの手動リカバリー を参照してください。
11.15.4. レプリケーションボリュームでのセルフ取得のトリガー
マルチスレッドの自己修復
自己修復デーモンには、複数の修復を並行して処理できる機能があり、Replicate および Distribute-replicate ボリュームでサポートされます。ただし、ヒューズの数が増えると I/O パフォーマンスに影響が及ぶため、以下のオプションが提供されます。cluster.shd-max-threads
ボリュームオプションは、自己修復デーモンにより各レプリカで並行して自己修復できるエントリーの数を制御します。cluster.shd-wait-qlength
ボリュームオプションを使用して、自己修復デーモンスレッドが修復された状態ですぐに起動できるように、キューに格納する必要があるエントリーの数を設定できます。
- 修復が必要なファイルの一覧を表示するには、次のコマンドを実行します。
# gluster volume heal VOLNAME info
たとえば、修復が必要な test-volume 上のファイルの一覧を表示するには、以下を実行します。# gluster volume heal test-volume info Brick server1:/gfs/test-volume_0 Number of entries: 0 Brick server2:/gfs/test-volume_1 /95.txt /32.txt /66.txt /35.txt /18.txt /26.txt - Possibly undergoing heal /47.txt /55.txt /85.txt - Possibly undergoing heal ... Number of entries: 101
- 修復が必要なファイルでのみ自己修復をトリガーするには、以下を実行します。
# gluster volume heal VOLNAME
たとえば、test-volume で修復が必要なファイルで自己修復をトリガーするには、以下を実行します。# gluster volume heal test-volume Heal operation on volume test-volume has been successful
- ボリューム上のすべてのファイルで自己修復をトリガーするには、以下を実行します。
# gluster volume heal VOLNAME full
たとえば、test-volume のすべてのファイルで自己修復をトリガーするには、以下を実行します。# gluster volume heal test-volume full Heal operation on volume test-volume has been successful
- スプリットブレイン状態にあるボリュームのファイルの一覧を表示するには、以下を実行します。
# gluster volume heal VOLNAME info split-brain
たとえば、スプリットブレイン状態にある test-volume 上のファイルの一覧を表示するには、以下を実行します。# gluster volume heal test-volume info split-brain Brick server1:/gfs/test-volume_2 Number of entries: 12 at path on brick ---------------------------------- 2012-06-13 04:02:05 /dir/file.83 2012-06-13 04:02:05 /dir/file.28 2012-06-13 04:02:05 /dir/file.69 Brick server2:/gfs/test-volume_2 Number of entries: 12 at path on brick ---------------------------------- 2012-06-13 04:02:05 /dir/file.83 2012-06-13 04:02:05 /dir/file.28 2012-06-13 04:02:05 /dir/file.69 ...
11.16. 推奨される設定: 障害の発生したボリューム
ブリック設定
以下の表は、分散および分散されるボリューム向けの複数のサーバー/ディスク設定のブリックレイアウトの詳細を示しています。
表11.3 Dispersed および Distributed Dispersed ボリュームのブリック設定
冗長性レベル | サポートされる構成 | サブボリュームごとにサーバーごとのブリック | ノードの損失 | サブボリューム内の最大ブリック失敗数 | 互換性のあるサーバーノードの数 | サイズの増加 (ノードのなし) | サブボリュームの最小数 | 合計スピンドル | 許容される HDD 失敗の割合 |
---|---|---|---|---|---|---|---|---|---|
12 HDD シャーシ | |||||||||
2 | 4 + 2 | 2 | 1 | 2 | 3 | 3 | 6 | 36 | 33.33% |
1 | 2 | 2 | 6 | 6 | 12 | 72 | 33.33% | ||
2 | 8+2 | 2 | 1 | 2 | 5 | 5 | 6 | 60 | 20.00% |
1 | 2 | 2 | 10 | 10 | 12 | 120 | 20.00% | ||
3 | 8 + 3 | 1-2 | 1 | 3 | 6 | 6 | 6 | 72 | 25.00% |
4 | 8 + 4 | 4 | 1 | 4 | 3 | 3 | 3 | 36 | 33.33% |
2 | 2 | 4 | 6 | 6 | 6 | 72 | 33.33% | ||
1 | 4 | 4 | 12 | 12 | 12 | 144 | 33.33% | ||
4 | 16 + 4 | 4 | 1 | 4 | 5 | 5 | 3 | 60 | 20.00% |
2 | 2 | 4 | 10 | 10 | 6 | 120 | 20.00% | ||
1 | 4 | 4 | 20 | 20 | 12 | 240 | 20.00% | ||
24 HDD シャーシ | |||||||||
2 | 4 + 2 | 2 | 1 | 2 | 3 | 3 | 12 | 72 | 33.33% |
1 | 2 | 2 | 6 | 6 | 24 | 144 | 33.33% | ||
2 | 8+ 2 | 2 | 1 | 2 | 5 | 5 | 12 | 120 | 20.00% |
1 | 2 | 2 | 10 | 10 | 24 | 240 | 20.00% | ||
4 | 8 + 4 | 4 | 1 | 4 | 3 | 3 | 6 | 72 | 33.33% |
2 | 2 | 4 | 6 | 6 | 12 | 144 | 33.33% | ||
1 | 4 | 4 | 12 | 12 | 24 | 288 | 33.33% | ||
4 | 16 + 4 | 4 | 1 | 4 | 5 | 5 | 6 | 120 | 20.00% |
2 | 2 | 4 | 10 | 10 | 12 | 240 | 20.00% | ||
1 | 4 | 4 | 20 | 20 | 24 | 480 | 20.00% | ||
36 HDD シャーシ | |||||||||
2 | 4 + 2 | 2 | 1 | 2 | 3 | 3 | 18 | 108 | 33.33% |
1 | 2 | 2 | 6 | 6 | 36 | 216 | 33.33% | ||
2 | 8 + 2 | 2 | 1 | 1 | 5 | 5 | 18 | 180 | 20.00% |
1 | 2 | 2 | 10 | 10 | 36 | 360 | 20.00% | ||
3 | 8 + 3 | 1-2 | 1 | 3 | 6 | 6 | 19 | 216 | 26.39% |
4 | 8 + 4 | 4 | 1 | 4 | 3 | 3 | 9 | 108 | 33.33% |
2 | 2 | 4 | 6 | 6 | 18 | 216 | 33.33% | ||
1 | 4 | 4 | 12 | 12 | 36 | 432 | 33.33% | ||
4 | 16 + 4 | 4 | 1 | 4 | 5 | 5 | 9 | 180 | 20.00% |
2 | 2 | 4 | 10 | 10 | 18 | 360 | 20.00% | ||
1 | 4 | 4 | 20 | 20 | 36 | 720 | 20.00% | ||
60 HDD シャーシ | |||||||||
2 | 4 + 2 | 2 | 1 | 2 | 3 | 3 | 30 | 180 | 33.33% |
1 | 2 | 2 | 6 | 6 | 60 | 360 | 33.33% | ||
2 | 8 + 2 | 2 | 1 | 2 | 5 | 5 | 30 | 300 | 20.00% |
1 | 2 | 2 | 10 | 10 | 60 | 600 | 20.00% | ||
3 | 8 + 3 | 1-2 | 1 | 3 | 6 | 6 | 32 | 360 | 26.67% |
4 | 8 + 4 | 4 | 1 | 4 | 3 | 3 | 15 | 180 | 33.33% |
2 | 2 | 4 | 6 | 6 | 30 | 360 | 33.33% | ||
1 | 4 | 4 | 12 | 12 | 60 | 720 | 33.33% | ||
4 | 16 + 4 | 4 | 1 | 4 | 5 | 5 | 15 | 300 | 20.00% |
2 | 2 | 4 | 10 | 10 | 30 | 600 | 20.00% | ||
1 | 4 | 4 | 20 | 20 | 60 | 1200 | 20.00% |
例 1: 3 台のサーバーで 4+2 設定の無効化
この例では、3 台のサーバーのコンパクトな設定を説明し、各サーバーが 12 HDD シャーシに接続して分散ボリュームを作成します。この例では、各 HDD には単一のブリックが含まれていることが前提となります。
# gluster volume create test_vol disperse-data 4 redundancy 2 transport tcp server1:/rhgs/brick1 server1:/rhgs/brick2 server2:/rhgs/brick3 server2:/rhgs/brick4 server3:/rhgs/brick5 server3:/rhgs/brick6 --force
--force
パラメーターが必要な点に注意してください。各サーバーは 2 つのブリックを提供するため、各ブリックが別のサーバーによって提供された場合、サーバーがオフラインになる場合、この構成ではデータの可用性がより高くなります。
# gluster volume info test-volume Volume Name: test-volume Type: Disperse Status: Started Number of Bricks: 1 x (4 + 2) = 6 Transport-type: tcp Bricks: Brick1: server1:/rhgs/brick1 Brick2: server1:/rhgs/brick2 Brick3: server2:/rhgs/brick3 Brick4: server2:/rhgs/brick4 Brick5: server3:/rhgs/brick5 Brick6: server3:/rhgs/brick6
# gluster volume add-brick test_vol server1:/rhgs/brick7 server1:/rhgs/brick8 server2:/rhgs/brick9 server2:/rhgs/brick10 server3:/rhgs/brick11 server3:/rhgs/brick12
# gluster volume info test-volume Volume Name: test-volume Type: Distributed-Disperse Status: Started Number of Bricks: 2 x (4 + 2) = 12 Transport-type: tcp Bricks: Brick1: server1:/rhgs/brick1 Brick2: server1:/rhgs/brick2 Brick3: server2:/rhgs/brick3 Brick4: server2:/rhgs/brick4 Brick5: server3:/rhgs/brick5 Brick6: server3:/rhgs/brick6 Brick7: server1:/rhgs/brick7 Brick8: server1:/rhgs/brick8 Brick9: server2:/rhgs/brick9 Brick10: server2:/rhgs/brick10 Brick11: server3:/rhgs/brick11 Brick12: server3:/rhgs/brick12
例 2: 3 台のサーバーで 8+4 設定の無効化
以下の図は、表11.3「Dispersed および Distributed Dispersed ボリュームのブリック設定」 の行 3 の行 3 で説明したように、3 つのサーバーで分散された 8+4 設定を示しています。このコマンドでは、この設定の分散ボリュームを作成します。
# gluster volume create test_vol disperse-data 8 redundancy 4 transport tcp server1:/rhgs/brick1 server1:/rhgs/brick2 server1:/rhgs/brick3 server1:/rhgs/brick4 server2:/rhgs/brick1 server2:/rhgs/brick2 server2:/rhgs/brick3 server2:/rhgs/brick4 server3:/rhgs/brick1 server3:/rhgs/brick2 server3:/rhgs/brick3 server3:/rhgs/brick4 server1:/rhgs/brick5 server1:/rhgs/brick6 server1:/rhgs/brick7 server1:/rhgs/brick8 server2:/rhgs/brick5 server2:/rhgs/brick6 server2:/rhgs/brick7 server2:/rhgs/brick8 server3:/rhgs/brick5 server3:/rhgs/brick6 server3:/rhgs/brick7 server3:/rhgs/brick8 server1:/rhgs/brick9 server1:/rhgs/brick10 server1:/rhgs/brick11 server1:/rhgs/brick12 server2:/rhgs/brick9 server2:/rhgs/brick10 server2:/rhgs/brick11 server2:/rhgs/brick12 server3:/rhgs/brick9 server3:/rhgs/brick10 server3:/rhgs/brick11 server3:/rhgs/brick12 --force
--force
パラメーターが必要な点に注意してください。各サーバーには複数のブリックがあるため、別のサーバーで各ブリックが提供されている場合に、サーバーがオフラインの場合、この構成ではデータの可用性がより高くなります。
図11.1 8+4 分散ボリューム設定例
m
ブリックがあります (詳細は n = k+m
式の情報の 「分散ボリュームの作成」 セクションを参照)。サーバー S
の分散されたサブボリュームからm
のブリックを追加して、サーバー S
がダウンした場合には、データは利用できません。
S
(上記の図の単一列) がダウンすると、データの損失はありません。ただし、ハードウェアに障害が発生しても、別のノードが停止またはストレージデバイスの障害が即座になくなると、データがすぐに失われます。
例 3: 6 台のサーバーでの分散 4+2 設定
以下の図は、6 台のサーバーで分散した 4+2 の構成と、表11.3「Dispersed および Distributed Dispersed ボリュームのブリック設定」 の行 2 で説明されているように 12-disk-per-server 設定を持つ各サーバーを示しています。この設定用に分散ボリュームを作成するコマンド:
# gluster volume create test_vol disperse-data 4 redundancy 2 transport tcp server1:/rhgs/brick1 server2:/rhgs/brick1 server3:/rhgs/brick1 server4:/rhgs/brick1 server5:/rhgs/brick1 server6:/rhgs/brick1server1:/rhgs/brick2 server2:/rhgs/brick2 server3:/rhgs/brick2 server4:/rhgs/brick2 server5:/rhgs/brick2 server6:/rhgs/brick2 server1:/rhgs/brick3 server2:/rhgs/brick3 server3:/rhgs/brick3 server4:/rhgs/brick3 server5:/rhgs/brick3 server6:/rhgs/brick3 server1:/rhgs/brick4 server2:/rhgs/brick4 server3:/rhgs/brick4 server4:/rhgs/brick4 server5:/rhgs/brick4 server6:/rhgs/brick4 server1:/rhgs/brick5 server2:/rhgs/brick5 server3:/rhgs/brick5 server4:/rhgs/brick5 server5:/rhgs/brick5 server6:/rhgs/brick5 server1:/rhgs/brick6 server2:/rhgs/brick6 server3:/rhgs/brick6 server4:/rhgs/brick6 server5:/rhgs/brick6 server6:/rhgs/brick6 server1:/rhgs/brick7 server2:/rhgs/brick7 server3:/rhgs/brick7 server4:/rhgs/brick7 server5:/rhgs/brick7 server6:/rhgs/brick7 server1:/rhgs/brick8 server2:/rhgs/brick8 server3:/rhgs/brick8 server4:/rhgs/brick8 server5:/rhgs/brick8 server6:/rhgs/brick8 server1:/rhgs/brick9 server2:/rhgs/brick9 server3:/rhgs/brick9 server4:/rhgs/brick9 server5:/rhgs/brick9 server6:/rhgs/brick9 server1:/rhgs/brick10 server2:/rhgs/brick10 server3:/rhgs/brick10 server4:/rhgs/brick10 server5:/rhgs/brick10 server6:/rhgs/brick10 server1:/rhgs/brick11 server2:/rhgs/brick11 server3:/rhgs/brick11 server4:/rhgs/brick11 server5:/rhgs/brick11 server6:/rhgs/brick11 server1:/rhgs/brick12 server2:/rhgs/brick12 server3:/rhgs/brick12 server4:/rhgs/brick12 server5:/rhgs/brick12 server6:/rhgs/brick12
図11.2 4+2 分散ボリューム設定の例:
冗長性比較
以下のチャートは、サポートされるすべての分散ボリューム設定の冗長性の比較を示しています。
図11.3 冗長性比較の図
11.17. Replica および Disperse サブボリューム内の一貫した時間属性
11.17.1. 前提条件
11.17.2. 競合時間機能の有効化および無効化
# gluster volume set VOLNAME ctime on
# gluster volume set VOLNAME ctime off
11.17.3. 競合時間機能の利点
11.17.4. 拡張属性の形式
glusterfs.mdata = “<version – 8bits> <flags – 64bits> <ctime sec – 64bits> <ctime nsec – 64bits> <mtime sec - 64 bits> <mtime nsec-64 bits> <atime sec - 64 bits> <atime nsec - 64 bits>”
trusted.glusterfs.mdata=0x010000000000000000000000005cefab7b000000002bcb2587000000005cefab7b000000002bcb2587000000005cefab7b000000002b73964d
11.17.5. アップグレード
11.17.6. 制限
- アクセス時間 (atime) の更新はサポートされていません。サポートを有効にするには、「ctime.noatime」オプションを「off」に設定します。ただし、これを有効にすると、パフォーマンスが大幅に低下することになります。複製されたボリュームおよび分散されたボリュームは、あるサブボリュームからデータを読み取るため、そのサブボリュームの xattr 更新が行われ、atime 更新ごとにレプリカセットの他のサブボリュームに対する自己修復がトリガーされます。
- この機能では、時間属性オプション (noatime、realatime) を使用した gluster ボリュームのマウントはサポートされていません。
- この機能は、ディレクトリーのハッシュ化されたサブボリュームがダウンした場合にディレクトリーの一貫性を保証する訳ではありません。
- ディレクトリーの一覧が一貫性のない時間情報を報告する可能性があるため、この機能はディレクトリーの一覧またはメタデータに過剰な依存するワークロードではサポートされません。
第12章 Red Hat Gluster Storage ログの管理
log-file-name.epoch-time-stamp
に移動されます。message-ids でログメッセージが生成されるコンポーネントは、glusterFS 管理サービス、分散 Hash Table (DHT)、および Automatic File Replication (AFR) です。
12.1. ログローテーション
12.2. Red Hat Gluster Storage コンポーネントのログおよび場所
/var/log
ディレクトリーに配置されます。
表12.1
コンポーネント/サービス名 | ログファイルの場所 | 備考 |
---|---|---|
glusterd | /var/log/glusterfs/glusterd.log | サーバーごとに 1 つの glusterd ログファイルこのログファイルには、スナップショットとユーザーログも含まれます。 |
gluster コマンド | /var/log/glusterfs/cmd_history.log | このファイルに Red Hat Gluster Storage Trusted Storage Pool のノード上で実行される Gluster コマンドがログに記録されます。 |
ブリック | /var/log/glusterfs/bricks/<path extraction of brick path>.log | サーバーのブリックごとに 1 つのログファイル |
リバランス | /var/log/glusterfs/VOLNAME-rebalance.log | サーバーのボリュームごとに 1 つのログファイル |
自己修復デーオン | /var/log/glusterfs/glustershd.log | サーバーごとに 1 つのログファイル |
クォータ(非推奨)
詳細は、9章ディレクトリークォータの管理 を参照してください。
|
| サーバーごとに 1 つのログファイル (およびクォータマウントからボリュームごとに)。 |
Gluster NFS(非推奨) | /var/log/glusterfs/nfs.log | サーバーごとに 1 つのログファイル |
SAMBA Gluster | /var/log/samba/glusterfs-VOLNAME-<ClientIP>.log | クライアントが glusterFS サーバーノードにマウントすると、実際のログファイルまたはマウントポイントが見つからない可能性があります。このような場合は、glusterFS タイプのマウント操作のマウント出力を考慮する必要があります。 |
NFS - Ganesha | /var/log/ganesha/ganesha.log , /var/log/ganesha/ganesha-gfapi.log | サーバーごとに 1 つのログファイル |
FUSE マウント | /var/log/ glusterfs/<mountpoint path extraction>.log | |
Geo レプリケーション | /var/log/glusterfs/geo-replication/<master> /var/log/glusterfs/geo-replication-slaves | |
gluster volume heal VOLNAME info コマンド | /var/log/glusterfs/glfsheal-VOLNAME.log | コマンドの実行先のサーバーごとに 1 つのログファイル。 |
SwiftKrbAuth (非推奨) | /var/log/httpd/error_log | |
コマンドラインインターフェースのログ | /var/log/glusterfs/cli.log | このファイルは、コマンドラインインターフェース (CLI) で実行されるすべてのコマンドのログエントリーを取得します。 |
12.3. ログフォーマットの設定
# gluster volume set VOLNAME diagnostics.brick-log-format <value>
例12.1 with-msg-id
でログファイルを生成します。
# gluster volume set testvol diagnostics.brick-log-format with-msg-id
例12.2 no-msg-id
でログファイルを生成します。
# gluster volume set testvol diagnostics.brick-log-format no-msg-id
gluster volume set VOLNAME diagnostics.client-log-format <value>
例12.3 with-msg-id
でログファイルを生成します。
# gluster volume set testvol diagnostics.client-log-format with-msg-id
例12.4 no-msg-id
でログファイルを生成します。
# gluster volume set testvol diagnostics.client-log-format no-msg-id
glusterd
のログ形式を設定するには、以下を実行します。
# glusterd --log-format=<value>
例12.5 with-msg-id
でログファイルを生成します。
# glusterd --log-format=with-msg-id
例12.6 no-msg-id
でログファイルを生成します。
# glusterd --log-format=no-msg-id
以下も参照してください。
12.4. ログレベルの設定
INFO
に設定されている場合、CRITICAL
、ERROR
、WARNING
、および INFO
メッセージのみがログに記録されます。
- CRITICAL
- ERROR
- 警告
- INFO
- DEBUG
- TRACE
# gluster volume set VOLNAME diagnostics.brick-log-level <value>
例12.7 ブリックの警告にログレベルを設定します。
# gluster volume set testvol diagnostics.brick-log-level WARNING
# gluster volume set VOLNAME diagnostics.brick-sys-log-level <value>
例12.8 syslog レベルを、ブリックで警告に設定します。
# gluster volume set testvol diagnostics.brick-sys-log-level WARNING
# gluster volume set VOLNAME diagnostics.client-log-level <value>
例12.9 ログレベルをクライアントのエラーに設定します。
# gluster volume set testvol diagnostics.client-log-level ERROR
# gluster volume set VOLNAME diagnostics.client-sys-log-level <value>
例12.10 syslog レベルをクライアントでエラーに設定します。
# gluster volume set testvol diagnostics.client-sys-log-level ERROR
glusterd
のログレベルを永続的に設定するには
/etc/sysconfig/glusterd
ファイルを編集し、LOG_LEVEL
パラメーターの値を glusterd が使用するログレベルに設定します。
## Set custom log file and log level (below are defaults) #LOG_FILE='/var/log/glusterfs/glusterd.log' LOG_LEVEL='VALUE'
例12.11 ログレベルを glusterd
の WARNING に設定します。
glusterd
サービスファイルを編集します。Red Hat Enterprise 7(RHEL 7)および RHEL 8 では、glusterd
サービスファイルは/usr/lib/systemd/system/glusterd.service
で利用できます。RHEL 6 では、glusterd
サービスファイルは/etc/sysconfig/glusterd
で利用できます。重要Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。インストールガイドの『バージョンの詳細』表および『Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 を参照してください。LOG_LEVEL
変数を必要なデバッグレベルに変更します。## Set custom log file and log level (below are defaults) #LOG_FILE='/var/log/glusterfs/glusterd.log' LOG_LEVEL='WARNING'
- デーモンを再読み込みします。RHEL 7 および RHEL 8 で以下を実行します。
systemctl daemon-reload
RHEL 6 で以下を実行します。service glusterd reload
重要Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。インストールガイドの『バージョンの詳細』表および『Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 を参照してください。 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 ソフトウェアコンポーネントおよびバージョン』 を参照してください。
例12.12 ログレベルが ERROR で volume status を実行します。
# gluster --log-level=ERROR volume status
以下も参照してください。
12.5. 繰り返しログメッセージの抑制
log-flush-timeout
期間を設定し、log-buf-size
バッファーサイズオプションを定義して設定できます。
タイムアウト期間による繰り返しログメッセージの抑制
# gluster volume set VOLNAME diagnostics.brick-log-flush-timeout <value in seconds>
例12.13 ブリックにタイムアウト期間を設定する
# gluster volume set testvol diagnostics.brick-log-flush-timeout 200sec volume set: success
# gluster volume set VOLNAME diagnostics.client-log-flush-timeout <value in seconds>
例12.14 クライアントでのタイムアウト時間の設定
# gluster volume set testvol diagnostics.client-log-flush-timeout 180sec volume set: success
glusterd
のタイムアウト期間を設定するには、以下を実行します。
# glusterd --log-flush-timeout=<value in seconds>
例12.15 glusterd
でタイムアウト期間の設定
# glusterd --log-flush-timeout=60sec
バッファーサイズの定義による繰り返しログメッセージの抑制
タイムアウトまたはバッファーオーバーフローのいずれかがブリックで最初に発生するまで抑制できる一意のログメッセージの最大数。
# gluster volume set VOLNAME diagnostics.brick-log-buf-size <value>
例12.16 ブリックにバッファーサイズを設定
# gluster volume set testvol diagnostics.brick-log-buf-size 10 volume set: success
# gluster volume set VOLNAME diagnostics.client-log-buf-size <value>
例12.17 クライアントでのバッファーサイズの設定
# gluster volume set testvol diagnostics.client-log-buf-size 15 volume set: success
glusterd
にログバッファーサイズを設定するには、以下を実行します。
# glusterd --log-buf-size=<value>
例12.18 glusterd
にログバッファーサイズを設定
# glusterd --log-buf-size=10
以下も参照してください。
12.6. geo レプリケーションのログ
master-log-file
: マスターボリュームを監視するプロセスのログファイル。slave-log-file
: スレーブで変更を開始するプロセスのログファイル。master-gluster-log-file
: マスターボリュームの監視に geo レプリケーションモジュールが使用するメンテナンスマウントポイントのログファイル。Slave-gluster-log-file
: スレーブが Red Hat Gluster Storage ボリュームである場合、このログファイルはMaster-gluster-log-file
の一部になります。
12.6.1. Geo レプリケーションマスターログファイルの表示
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config log-file
# gluster volume geo-replication Volume1 example.com::slave-vol config log-file
12.6.2. Geo レプリケーションセカンダリーログファイルの表示
glusterd
がセカンダリーマシンで実行されている必要があります。
- プライマリーで以下のコマンドを実行し、session-owner の詳細を表示します。
# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config session-owner
以下に例を示します。# gluster volume geo-replication Volume1 example.com::slave-vol config session-owner 5f6e5200-756f-11e0-a1f0-0800200c9a66
- セカンダリーで、直前の手順で session-owner の値を指定して以下のコマンドを実行します。
# gluster volume geo-replication SLAVE_VOL config log-file /var/log/gluster/SESSION_OWNER:remote-mirror.log
以下に例を示します。# gluster volume geo-replication slave-vol config log-file /var/log/gluster/5f6e5200-756f-11e0-a1f0-0800200c9a66:remote-mirror.log
第13章 Managing Red Hat Gluster Storage Volume Life-Cycle Extensions
- ボリュームの作成
- ボリュームの起動
- ブリックの追加
- ブリックの削除
- ボリュームオプションのチューニング
- ボリュームの停止
- ボリュームの削除
13.1. スクリプトの場所
- /var/lib/glusterd/hooks/1/create/
- /var/lib/glusterd/hooks/1/delete/
- /var/lib/glusterd/hooks/1/start/
- /var/lib/glusterd/hooks/1/stop/
- /var/lib/glusterd/hooks/1/set/
- /var/lib/glusterd/hooks/1/add-brick/
- /var/lib/glusterd/hooks/1/remove-brick/
- ボリュームの起動
- --first=yes: ボリュームが最初に起動すると、
- --first=no。そうでない場合は、
- ボリュームの停止
- --last=yes: ボリュームが最後に停止する場合。
- --last=no (それ以外の場合に)
- ボリュームの設定
- -o key=valueすべてのキーについて、値は volume set コマンドで指定されます。
13.2. 事前にパッケージ化されたスクリプト
/var/lib/glusterd/hooks/1/start/post
および /var/lib/glusterd/hooks/1/stop/pre
で利用できます。デフォルトでは、スクリプトは有効です。
S30samba-start.sh
スクリプトは、以下を実行します。
- Samba 共有設定の詳細を
smb.conf
ファイルに追加します。 - FUSE を介してボリュームをマウントし、同じ場合は
/etc/fstab
のエントリーを追加します。 - Samba を再起動して、更新された設定で実行します。
S30samba-stop.sh
スクリプトは、以下を実行します。
smb.conf
ファイルから、ボリュームの Samba 共有の詳細を削除します。- FUSE マウントポイントをアンマウントし、
/etc/fstab
で対応するエントリーを削除します。 - Samba を再起動して、更新された設定で実行します。
第14章 BitRot の検出
- /var/log/glusterfs/bitd.log
- /var/log/glusterfs/scrub.log
14.1. BitRot デーモンの有効化および無効化
- gluster volume bitrotVOLNAMEenable
- 指定したボリュームの BitRot デーモンを有効にします。
- gluster volume bitrot VOLNAME disable
- 指定したボリュームの BitRot デーモンを無効にします。
14.2. BitRot 検出動作の変更
- gluster volume bitrot VOLNAME scrub ondemand
- スクラビングプロセスを開始し、スクラバーはすぐにファイルシステムのクローリングを開始します。オンデマンドのスクラビングが成功するまで、スクラバーが次の周波数サイクルを待機している 'Active (Idle)' のスクラバーを保持するようにします。オンデマンドのスクラビングでは、スクライバーが 'Paused' 状態であるか、すでに実行中である場合は機能しません。
- gluster volume bitrot VOLNAME scrub pause
- 指定されたボリュームでスクラビングプロセスを一時停止します。これにより、BitRot デーモンは停止しません。ボリュームチェックファイルの循環プロセスを停止します。
- gluster volume bitrot VOLNAME scrub resume
- 指定されたボリュームでスクラビングプロセスを再開します。これは BitRot デーモンを起動せず、ボリュームチェックファイルの循環プロセスを再起動することに注意してください。
- gluster volume bitrot VOLNAME scrub status
- このコマンドは、指定されたボリュームにおけるスクラブステータスの概要を出力します。これには、このボリュームのさまざまな設定の詳細とビット腐敗の場所およびスクラバーエラーログが含まれます。また、エラーについてスキャンした各ノードの詳細と、破損したオブジェクトの識別子も出力します。
- gluster volume bitrot VOLNAME scrub-throttle rate
- BitRot デーモンはファイルシステム全体をスクラビングするため、スクラビングはパフォーマンスに重大な影響を与える可能性があります。このコマンドは、ファイルおよびオブジェクトの検証速度を変更します。有効なレートは
lazy
、normal
、およびAggressive
です。デフォルトでは、スクラビャープロセスはlazy
モードで開始されます。 - gluster volume bitrot VOLNAME scrub-frequency frequency
- このコマンドは、BitRot デーモンが有効な場合にスクラブ操作を実行する頻度を変更します。有効なオプションは、
daily
、weekly
、biweekly
、monthly
、biweekly
のデフォルト値は、スクラビタープロセスが biweekly を実行するように設定されています。
14.3. 不正なファイルの復元
-oaux-gfid-mount
マウントオプションを使用してすべてのボリュームをマウントし、以下のコマンドを実行して各ボリュームで GFID からパス間の変換を有効にします。
# gluster volume set VOLNAME build-pgfid on
手順14.1 複製ボリュームからの誤ったファイルの復元
不正なファイルの識別子を書き留めます
scrub status コマンドの出力を確認して、破損したファイルの ID を確認します。# gluster volume bitrot VOLNAME scrub status Volume name: VOLNAME ... Node name: NODENAME ... Error count: 3 Corrupted objects: 5f61ade8-49fb-4c37-af84-c95041ff4bf5 e8561c6b-f881-499b-808b-7fa2bce190f7 eff2433f-eae9-48ba-bdef-839603c9434c
破損した各オブジェクトのパスを確認します。
GFID からパス間の翻訳を有効にした後に作成されたファイルについては、getfattr コマンドを使用して、破損したファイルのパスを確認します。# getfattr -n glusterfs.ancestry.path -e text /mnt/VOLNAME/.gfid/GFID ... glusterfs.ancestry.path="/path/to/corrupted_file"
GFID からパス間の翻訳が有効になる前に作成されたファイルについては、find コマンドを使用して、破損したファイルのパスと、識別している GFID に一致するインデックスファイルを確認します。# find /rhgs/brick*/.glusterfs -name GFID /rhgs/brick1/.glusterfs/path/to/GFID
# find /rhgs -samefile /rhgs/brick1/.glusterfs/path/to/GFID /rhgs/brick1/.glusterfs/path/to/GFID /rhgs/brick1/path/to/corrupted_file
破損したファイルを削除します。
getfattr または find コマンドで、パスの出力から破損したファイルを削除します。GFID ファイルを削除します。
/rhgs/brickN/.glusterfs
ディレクトリーから GFID ファイルを削除します。ファイルを復元します。
以下の手順に従って、破損したファイルを安全に復元します。メタデータキャッシュの無効化
メタデータキャッシュが有効な場合は、以下のコマンドを実行して無効にします。# gluster volume set VOLNAME stat-prefetch off
リカバリーマウントポイントの作成
リカバリープロセスに使用するマウントポイントを作成します。たとえば、/mnt/recovery
です。# mkdir /mnt/recovery
タイムアウトが無効になっているボリュームをマウントします。
# mount -t glusterfs -o attribute-timeout=0,entry-timeout=0 hostname:volume-path /mnt/recovery
ヒュージファイルおよびハードリンク
ファイルにアクセスし、それらのファイルへのハードリンクにアクセスします。たとえば、ファイルおよび修復に必要なハードリンクで stat コマンドを実行します。$ stat /mnt/recovery/corrupt-file
クライアントの自己修復を有効にしていない場合は、次のコマンドでボリュームを手動で修復する必要があります。# gluster volume heal VOLNAME
アンマウントして、必要に応じてリカバリーマウントポイントを削除します。
# umount /mnt/recovery # rmdir /mnt/recovery
オプション: メタデータキャッシュを再度有効にします。
メタデータキャッシュが以前に有効化されていた場合は、以下のコマンドを実行して再度有効にします。# gluster volume set VOLNAME stat-prefetch on
第15章 Glusterfind を使用した増分バックアップアシスタンス
15.1. Glusterfind 設定オプション
- Glusterfind Create
- Glusterfind Pre
- Glusterfind Post
- Glusterfind Query
- Glusterfind List
- Glusterfind Delete
Glusterfind Create
ボリューム内の特定インスタンスにセッションを作成するには、以下のコマンドを実行します。
# glusterfind create [-h] [--debug] [--force] <SessionName> <volname> [--reset-session-time]
# glusterfind create sess_vol1 vol1 Session sess_vol1 created with volume vol1
Glusterfind Pre
glusterfind Pre 操作の前に、すべてのノードがオンラインであることを確認します。変更したファイルおよびディレクトリーの一覧を取得して outfile に保存するには、以下のコマンドを実行します。
# glusterfind pre [-h] [--debug] [--no-encode] [--full] [--disable-partial] [--output-prefix OUTPUT_PREFIX] [--regenerate-outfile] [-N] [--tag-for-full-find TAG_FOR_FULL_FIND] [--type {f,d,both}] [--field-separator FIELD_SEPARATOR] <session> <volname> <outfile>
--help
OR -h
: コマンドのヘルプを表示します
--debug
: デバッグモードを有効にします。
--no-encode
: ファイルパスは、デフォルトで出力ファイルにエンコードされます。このオプションは、ファイルパスのエンコーディングを無効にします。
--full:
フル検索を実行します。
--disable-partial
: デフォルトで有効になっている partial-find 機能を無効にします。
--output-prefix OUTPUT_PREFIX
: outfile で指定したパス/名前へのプレフィックス。
--regenerate-outfile
: 新しい outfile を再生成し、最後の前のコマンドから生成した outfile を破棄します。
-N
OR --only-namespace-changes
: 名前空間の変更のみを一覧表示
--tag-for-full-find TAG_FOR_FULL_FIND
: 完全な検索操作中に生成されるファイル名のタグ接頭辞。デフォルト値は NEW
です。
--type {f,d,both}
: type: f、ファイルのみ。d、ディレクトリーのみ、default = both
--field-separator
: glusterfind 出力がフィールドを分離するために使用する文字/s を指定します。デフォルトでは、これは単一のスペースですが、ファイル名にスペースが含まれる場合は、glusterfind の出力を自動的に解析できるように区切り文字を変更することができます。
# glusterfind pre sess_vol1 vol1 /tmp/outfile.txt Generated output file /tmp/outfile.txt
NEW file1 NEW dir1%2Ffile2 MODIFY dir3%2Fdir4%2Ftest3 RENAME test1 dir1%2F%2Ftest1new DELETE test2
--no-encode
オプションを使用した出力例
NEW file1 NEW dir1/file2 MODIFY dir3/dir4/test3 RENAME test1 dir1/test1new DELETE test2
Glusterfind Post
以下のコマンドを実行すると、セッション時間が更新されます。
# glusterfind post [-h] [--debug] <SessionName> <volname>
# glusterfind post sess_vol1 vol1 Session sess_vol1 with volume vol1 updated
Glusterfind List
クラスターに存在するアクティブなセッションと対応するボリュームの一覧を表示するには、以下のコマンドを実行します。
# glusterfind list [-h] [--session SESSION] [--volume VOLUME] [--debug]
# glusterfind list SESSION VOLUME SESSION TIME -------------------------------------------------- sess_vol1 vol1 2015-06-22 22:22:53
Glusterfind Query
glusterfind query サブコマンドは、指定されたタイムスタンプに基づいて変更されたファイルのリストを提供します。これらのコマンドは、変更ログ情報を確認しません。バックアップソフトウェアが、glusterfind 外の独自のチェックポイントおよびタイムスタンプを維持している場合は、glusterfind query サブコマンドを使用します。glusterfind query サブコマンドは、以下のように使用できます。
# glusterfind query [-h] [--since-time SINCE_TIME] [--end-time END_TIME] [--no-encode] [--full] [--debug] [--disable-partial] [--output-prefix OUTPUT_PREFIX] [-N] [--tag-for-full-find TAG_FOR_FULL_FIND] [--type {f,d,both}] [--field-separator FIELD_SEPARATOR] volname outfile
--help
OR -h
: コマンドのヘルプを表示します
--since-time SINCE_TIME
: Linux エポックの日付 (1970-01-01 00:00:00 UTC) 以降、タイムスタンプを秒単位で想定します。現在の Linux エポック時間は echo $(date +'%s') コマンドを実行して判断できます。
--end-time END_TIME
: Linux エポックの日付 (1970-01-01 00:00:00 UTC) から、秒単位でタイムスタンプが想定されます。現在の Linux エポック時間は echo $(date +'%s') コマンドを実行して判断できます。
--no-encode
: ファイルパスは、デフォルトで出力ファイルにエンコードされます。このオプションは、ファイルパスのエンコーディングを無効にします。
--full:
フル検索を実行します。これは、--since-time
および --end-time
で使用できません。
--debug
: デバッグモードを有効にします。
--disable-partial
: デフォルトで有効になっている partial-find 機能を無効にします。
--output-prefix OUTPUT_PREFIX
: outfile で指定したパス/名前へのプレフィックス。
-N
OR --only-namespace-changes
: 名前空間の変更のみを一覧表示
--tag-for-full-find TAG_FOR_FULL_FIND
: 完全な検索操作中に生成されるファイル名のタグ接頭辞。デフォルト値は NEW
です。
--type {f,d,both}
: type: f、ファイルのみ。d、ディレクトリーのみ、default = both
--field-separator
: glusterfind 出力がフィールドを分離するために使用する文字/s を指定します。デフォルトでは、これは単一のスペースですが、ファイル名にスペースが含まれる場合は、glusterfind の出力を自動的に解析できるように区切り文字を変更することができます。
# glusterfind query volname --since-time timestamp1 --end-time timestamp2 output_file.txt
# glusterfind query volname --full output_file.txt
# glusterfind query volname --full --tag-for-full-find NEW output_file.txt
--field-separator
オプションを使用して、区切り文字を 1 つ以上の文字に設定できます。以下のコマンドは、フィールド区切り文字を ==
に設定します。
# gluster query volname --full output_file.txt --field-separator "=="
Glusterfind Delete
その特定のセッションに関連するセッション情報をすべて消去するには、以下のコマンドを実行します。
# glusterfind delete [-h] [--debug] <SessionName> <volname>
# glusterfind delete sess_vol1 vol1 Session sess_vol1 with volume vol1 deleted
15.1.1. 既存の Glusterfind セッションからのブログの追加または置き換え
# glusterfind create existing-session volname --force
第16章 階層化の管理 (非推奨)
ホット階層
ホット層は、より優れたサブボリューム (SSD など) を使用して作成された階層化ボリュームです。頻繁にアクセスされるデータは、最高のパフォーマンスと最も高価なホット層に配置されます。ホット層ボリュームは、分散ボリュームまたは分散レプリケーションのボリュームになります。
コールド階層
コールド層は、スピングディスクなどの低速なストレージを使用して作成された既存の Red Hat Gluster Storage ボリュームです。非アクティブなアクセスまたは頻度の低いコールド層にデータが配置されます。
データ移行
階層化は、ホットレイヤーとコールド層間でファイルを自動的に移行し、ストレージのパフォーマンスとリソースの使用を改善します。
16.1. アーキテクチャーの階層化 (非推奨)
図16.1 階層アーキテクチャー
16.2. 階層の主な利点 (非推奨)
- アクセスパターンに基づいてファイルの自動分類と移動
- 応答時間が短縮され、レイテンシーが短縮されます。
- I/O パフォーマンスの改善
- データストレージ効率の改善
- デプロイメントおよび運用コストの削減
16.3. 階層化制限 (非推奨)
- 階層化のためのネイティブクライアントサポートは、Red Hat Enterprise Linux バージョン 6.7、6.8、および 7.x クライアントに限定されます。階層化されたボリュームは、Red Hat Enterprise Linux 5.x クライアントではマウントできません。
- 階層は、
cache friendly
ワークロードでのみ機能します。キャッシュに階層ボリュームを割り当てると、不安定なワークロードのパフォーマンスが低下します。cache friendly
ワークロードでは、ほとんどの読み取りおよび書き込みは、データの合計量のサブセットにアクセスしています。また、このサブセットはホット階層に適合します。このサブセットは頻繁にのみ変更する必要があります。 - 階層機能は、Red Hat Enterprise Linux 7 ベースの Red Hat Gluster Storage でのみサポートされます。階層機能は、Red Hat Enterprise Linux 6 ベースの Red Hat Gluster Storage ではサポートされません。
- Fuse および gluster-nfs アクセスのみがサポートされます。階層化ボリュームへのサーバーメッセージブロック (SMB) および nfs-ganesha アクセスはサポートされません。
- 階層型ボリュームのスナップショットの作成がサポートされます。スナップショットのクローンは、階層化されたボリュームでは対応していません。
- tier detach commitまたはtier detach forceを実行すると、進行中のI/O操作が失敗し、Transport endpoint is not connectedエラーが発生することがありました。
- ハードリンクおよびソフトリンクを持つファイルは移行されません。
- POSIX ロックを取得したファイルは、すべてのロックがリリースされるまで移行されません。
- 階層型ボリュームでは、ブリックの追加、削除、およびリバランス操作はサポートされません。階層化されたボリュームの拡張に関する情報は、「階層化ボリュームの拡張」 を参照してください。階層化されたボリュームの縮小に関する情報は、「階層化されたボリュームの縮小 」 を参照してください。
16.4. ボリュームへの階層のアタッチ (非推奨)
- 以下のコマンドを実行して、階層をボリュームに接続します。# gluster volume tier VOLNAME attach [replica COUNT] NEW-BRICK...以下に例を示します。
# gluster volume tier test-volume attach replica 3 server1:/rhgs/brick5/b1 server2:/rhgs/brick6/b2 server1:/rhgs/brick7/b3 server2:/rhgs/brick8/b4
- gluster volume info コマンドを実行して、必要に応じてボリューム情報を表示します。コマンド出力には、以下のような情報が表示されます。
# gluster volume info test-volume Volume Name: test-volume Type: Tier Status: Started Number of Bricks: 8 Transport-type: tcp Hot Tier : Hot Tier Type : Distributed-Replicate Number of Bricks: 2 x 2 = 4 Brick1: server1:/rhgs/brick5/b1 Brick2: server2:/rhgs/brick6/b2 Brick3: server1:/rhgs/brick7/b3 Brick4: server2:/rhgs/brick8/b4 Cold Tier: Cold Tier Type : Distributed-Replicate Number of Bricks: 2 x 2 = 4 Brick5: server1:/rhgs/brick1/b5 Brick6: server2:/rhgs/brick2/b6 Brick7: server1:/rhgs/brick3/b7 Brick8: server2:/rhgs/brick4/b8 Options Reconfigured: cluster.watermark-low: 70 cluster.watermark-hi: 90 cluster.tier-demote-frequency: 45 cluster.tier-mode: cache features.ctr-enabled: on performance.readdir-ahead: on
16.4.1. Geo レプリケートボリュームへの階層の割り当て (非推奨)
performance.quick-read
オプションが有効で、階層化されたマスターボリュームからのジオレプリケーションが行われると、Slave マウントでクラッシュが確認されました。マスターボリュームが階層化されたボリュームの場合、以下のコマンドを使用して Slave ボリュームの performance.quick-read
オプションを無効にする必要があります。
# gluster volume set Slavevol performance.quick-read off
- 以下のコマンドを使用して、プライマリーとセカンダリー間の geo レプリケーションを停止します。# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop以下に例を示します。
# gluster volume geo-replication Volume1 example.com::slave-vol stop
- 以下のコマンドを使用して、階層をボリュームに接続します。# gluster volume tier VOLNAME attach [replica COUNT] NEW-BRICK...たとえば、レプリカ数が 2 の分散型階層ボリュームを作成するには、以下のコマンドを実行します。
# gluster volume tier test-volume attach replica 3 server1:/rhgs/brick1/b1 server2:/rhgs/brick2/b2 server1:/rhgs/brick3/b3 server2:/rhgs/brick4/b4
- 以下のコマンドを使用して geo レプリケーションセッションを再起動します。# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL startたとえば、以下のようになります。
# gluster volume geo-replication Volume1 example.com::slave-vol start
- 以下のコマンドを使用して、geo レプリケーションセッションが階層のブリックで開始されているかどうかを確認します。# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL status以下に例を示します。
# gluster volume geo-replication Volume1 example.com::slave-vol status
16.5. 階層化ボリュームの設定 (非推奨)
16.5.1. ウォーターマークの設定 (非推奨)
図16.2 階層化ウォーターマークの階層
16.5.2. Promote および Demote Frequency の設定 (非推奨)
16.5.3. 読み取りおよび書き込み頻度の設定 (非推奨)
HOT
がマークされます。この値よりも少ない読み取りまたは書き込みヒットのファイルはすべて COLD
と見なされ、降格されます。読み取り/書き込みアクセス数が設定されていない場合、デフォルトカウントは 0 に設定されます。
16.5.4. ターゲットデータサイズの設定 (非推奨)
cluster.tier-max-mb
数が設定されていない場合、デフォルトのデータサイズは 4000 MB に設定されます。
16.5.5. ライフサイクルごとのファイル数の設定 (非推奨)
cluster.tier-max-files
数が設定されていない場合、デフォルトのカウントは 10000 に設定されます。
16.6. ステータス情報の表示 (非推奨)
# gluster volume tier test-volume status Node Promoted files Demoted files Status --------- --------- --------- --------- localhost 1 5 in progress server1 0 2 in progress Tiering Migration Functionality: test-volume: success
16.7. ボリュームから階層の割り当て解除 (非推奨)
- 以下のコマンドを実行して、デタッチ層を開始します。# gluster volume tier VOLNAME detach start以下に例を示します。
# gluster volume tier test-volume detach start
- ステータスが complete と表示されるまで、デタッチ層のステータスを監視します。# gluster volume tier VOLNAME detach status以下に例を示します。
# gluster volume tier test-volume detach status Node Rebalanced-files size scanned failures skipped status run time in secs -------- ----------- ----------- ----------- ----------- ----------- ------------ -------------- localhost 0 0Bytes 0 0 0 completed 0.00 server1 0 0Bytes 0 0 0 completed 1.00 server2 0 0Bytes 0 0 0 completed 0.00 server1 0 0Bytes 0 0 0 completed server2 0 0Bytes 0 0 0 completed
注記一部のファイルは、POSIX ロックが保持されているなどのさまざまな理由で、デタッチ操作でコールド層に移行されない可能性があります。ホット階層ブリックのファイルの有無を確認し、手動でファイルを移動するか、(ファイルのロックを解除できるような) アプリケーションをオフにして、階層の停止/開始を再試行することができます。 - 前の status コマンドで階層が正常にデタッチされたら、以下のコマンドを実行して階層の割り当てを解除します。# gluster volume tier VOLNAME detach commit以下に例を示します。
# gluster volume tier test-volume detach commit Removing tier can result in data loss. Do you want to Continue? (y/n) y volume detach-tier commit: success Check the detached bricks to ensure all files are migrated. If files with data are found on the brick path, copy them via a gluster mount point before re-purposing the removed brick.
16.7.1. Geo レプリケーションボリュームの階層をデタッチ (非推奨)
- 以下のコマンドを実行して、デタッチ層を開始します。# gluster volume tier VOLNAME detach start以下に例を示します。
# gluster volume tier test-volume detach start
- ステータスが complete と表示されるまで、デタッチ層のステータスを監視します。# gluster volume tier VOLNAME detach status以下に例を示します。
# gluster volume tier test-volume detach status Node Rebalanced-files size scanned failures skipped status run time in secs -------- ----------- ----------- ----------- ----------- ----------- ------------ -------------- localhost 0 0Bytes 0 0 0 completed 0.00 server1 0 0Bytes 0 0 0 completed 1.00 server2 0 0Bytes 0 0 0 completed 0.00 server1 0 0Bytes 0 0 0 completed server2 0 0Bytes 0 0 0 completed
注記移動しなかったファイルの数もいくつかあります。このようなファイルはユーザーがロックしていて、デタッチ操作時にコールド層に移動するのを妨げている可能性があります。このようなファイルを確認する必要があります。このようなファイルが見つかると、手動でファイルを移動するか、アプリケーション (ファイルのロックを解除または切り離す) を無効にして再試行できます。 - geo レプリケーションセッションでチェックポイントを設定し、コールド層にあるすべてのデータがスレーブに同期されるようにします。geo レプリケーションチェックポイントの詳細は、 を「Geo-replication Checkpoints」参照してください。# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL config checkpoint now以下に例を示します。
# gluster volume geo-replication Volume1 example.com::slave-vol config checkpoint now
- 以下のコマンドを使用して、geo レプリケーションセッションのチェックポイント完了を確認します。# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL status detail
- 以下のコマンドを使用して、プライマリーとセカンダリー間の geo レプリケーションを停止します。# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL stop以下に例を示します。
# gluster volume geo-replication Volume1 example.com::slave-vol stop
- 以下のコマンドを使用して、階層の割り当て解除操作をコミットします。# gluster volume tier VOLNAME detach commit以下に例を示します。
# gluster volume tier test-volume detach commit Removing tier can result in data loss. Do you want to Continue? (y/n) y volume detach-tier commit: success Check the detached bricks to ensure all files are migrated. If files with data are found on the brick path, copy them via a gluster mount point before re-purposing the removed brick.
デタッチ層のコミットが完了したら、gluster volume info コマンドを実行して、ボリュームが階層ボリュームではなくなることを確認できます。 - 以下のコマンドを使用して geo レプリケーションセッションを再起動します。# gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL start以下に例を示します。
# gluster volume geo-replication Volume1 example.com::slave-vol start
パート V. 監視とチューニング
第17章 Red Hat Gluster Storage Gluster ワークロードの監視
17.1. ボリュームのプロファイリング
17.1.1. volume profile を用いたサーバーサイドボリュームプロファイリング
17.1.1.1. プローブの開始
# gluster volume profile test-volume start Starting volume profile on test has been successful
diagnostics.count-fop-hits: on diagnostics.latency-measurement: on
17.1.1.2. I/O 情報の表示
# gluster v profile glustervol info Brick: rhsqaci-vm33.lab.eng.blr.redhat.com:/bricks/brick0/1 ----------------------------------------------------------- Cumulative Stats: %-latency Avg-latency Min-Latency Max-Latency No. of calls Fop --------- ----------- ----------- ----------- ------------ ---- 0.00 0.00 us 0.00 us 0.00 us 11 RELEASE 0.00 0.00 us 0.00 us 0.00 us 238 RELEASEDIR 0.35 380.05 us 380.05 us 380.05 us 1 SETXATTR 0.40 107.73 us 5.50 us 413.31 us 4 OPENDIR 0.62 167.65 us 91.33 us 339.28 us 4 STATFS 0.86 187.42 us 28.50 us 534.96 us 5 GETXATTR 2.16 106.54 us 32.16 us 383.58 us 22 ENTRYLK 2.17 106.97 us 39.01 us 251.65 us 22 FLUSH 2.92 263.57 us 189.06 us 495.05 us 12 SETATTR 3.22 124.60 us 43.08 us 311.69 us 28 INODELK 3.41 616.76 us 319.27 us 1028.72 us 6 READDIR 10.11 997.03 us 413.73 us 3507.02 us 11 CREATE 73.79 256.58 us 50.02 us 924.61 us 312 LOOKUP Duration: 46537 seconds Data Read: 0 bytes Data Written: 0 bytes Interval 1 Stats: %-latency Avg-latency Min-Latency Max-Latency No. of calls Fop --------- ----------- ----------- ----------- ------------ ---- 0.00 0.00 us 0.00 us 0.00 us 11 RELEASE 0.00 0.00 us 0.00 us 0.00 us 4 RELEASEDIR 0.35 380.05 us 380.05 us 380.05 us 1 SETXATTR 0.40 107.73 us 5.50 us 413.31 us 4 OPENDIR 0.62 167.65 us 91.33 us 339.28 us 4 STATFS 0.86 187.42 us 28.50 us 534.96 us 5 GETXATTR 2.16 106.54 us 32.16 us 383.58 us 22 ENTRYLK 2.17 106.97 us 39.01 us 251.65 us 22 FLUSH 2.92 263.57 us 189.06 us 495.05 us 12 SETATTR 3.22 124.60 us 43.08 us 311.69 us 28 INODELK 3.41 616.76 us 319.27 us 1028.72 us 6 READDIR 10.11 997.03 us 413.73 us 3507.02 us 11 CREATE 73.79 256.58 us 50.02 us 924.61 us 312 LOOKUP Duration: 347 seconds Data Read: 0 bytes Data Written: 0 bytes Brick: rhsqaci-vm33.lab.eng.blr.redhat.com:/bricks/brick1/1 ----------------------------------------------------------- Cumulative Stats: %-latency Avg-latency Min-Latency Max-Latency No. of calls Fop --------- ----------- ----------- ----------- ------------ ---- 0.00 0.00 us 0.00 us 0.00 us 12 RELEASE 0.00 0.00 us 0.00 us 0.00 us 238 RELEASEDIR 0.14 146.24 us 146.24 us 146.24 us 1 OPEN 0.26 266.64 us 266.64 us 266.64 us 1 SETXATTR 0.26 67.88 us 2.50 us 243.52 us 4 OPENDIR 0.42 108.83 us 81.87 us 139.11 us 4 STATFS 0.98 201.26 us 82.36 us 306.38 us 5 GETXATTR 2.49 116.34 us 23.53 us 304.10 us 22 ENTRYLK 2.75 236.13 us 124.73 us 358.80 us 12 SETATTR 3.12 114.82 us 44.34 us 550.01 us 28 INODELK 3.17 142.00 us 23.16 us 388.56 us 23 FLUSH 4.37 748.73 us 324.70 us 1115.96 us 6 READDIR 6.57 614.44 us 364.94 us 807.17 us 11 CREATE 75.46 248.88 us 66.43 us 599.31 us 312 LOOKUP Duration: 46537 seconds Data Read: 0 bytes Data Written: 0 bytes
# gluster volume profile test-volume info nfs NFS Server : localhost ---------------------- Cumulative Stats: Block Size: 32768b+ 65536b+ No. of Reads: 0 0 No. of Writes: 1000 1000 %-latency Avg-latency Min-Latency Max-Latency No. of calls Fop --------- ----------- ----------- ----------- ------------ ---- 0.01 410.33 us 194.00 us 641.00 us 3 STATFS 0.60 465.44 us 346.00 us 867.00 us 147 FSTAT 1.63 187.21 us 67.00 us 6081.00 us 1000 SETATTR 1.94 221.40 us 58.00 us 55399.00 us 1002 ACCESS 2.55 301.39 us 52.00 us 75922.00 us 968 STAT 2.85 326.18 us 88.00 us 66184.00 us 1000 TRUNCATE 4.47 511.89 us 60.00 us 101282.00 us 1000 FLUSH 5.02 3907.40 us 1723.00 us 19508.00 us 147 READDIRP 25.42 2876.37 us 101.00 us 843209.00 us 1012 LOOKUP 55.52 3179.16 us 124.00 us 121158.00 us 2000 WRITE Duration: 7074 seconds Data Read: 0 bytes Data Written: 102400000 bytes Interval 1 Stats: Block Size: 32768b+ 65536b+ No. of Reads: 0 0 No. of Writes: 1000 1000 %-latency Avg-latency Min-Latency Max-Latency No. of calls Fop --------- ----------- ----------- ----------- ------------ ---- 0.01 410.33 us 194.00 us 641.00 us 3 STATFS 0.60 465.44 us 346.00 us 867.00 us 147 FSTAT 1.63 187.21 us 67.00 us 6081.00 us 1000 SETATTR 1.94 221.40 us 58.00 us 55399.00 us 1002 ACCESS 2.55 301.39 us 52.00 us 75922.00 us 968 STAT 2.85 326.18 us 88.00 us 66184.00 us 1000 TRUNCATE 4.47 511.89 us 60.00 us 101282.00 us 1000 FLUSH 5.02 3907.40 us 1723.00 us 19508.00 us 147 READDIRP 25.41 2878.07 us 101.00 us 843209.00 us 1011 LOOKUP 55.53 3179.16 us 124.00 us 121158.00 us 2000 WRITE Duration: 330 seconds Data Read: 0 bytes Data Written: 102400000 bytes
17.1.1.3. プローブの停止
# gluster volume profile test-volume stop Stopping volume profile on test has been successful
17.1.2. クライアント側のボリュームプロファイリング (FUSE のみ)
# setfattr -n trusted.io-stats-dump -v output_file_id mount_point
/var/run/gluster
ディレクトリーに多数のファイルが生成されます。output_file_id はファイル名全体ではなく、生成されたファイル名の一部として使用されます。
17.2. ボリュームトップコマンドの実行
17.2.1. Open File Descriptor 数および最大ファイル記述子数の表示
# gluster volume top test open brick server:/bricks/brick1/test list-cnt 10 Brick: server/bricks/brick1/test Current open fds: 2, Max open fds: 4, Max openfd time: 2020-10-09 05:57:20.171038 Count filename ======================= 2 /file222 1 /file1
17.2.2. 最も高いファイル読み取り呼び出しの表示
# gluster volume top testvol_distributed-dispersed read brick `hostname`:/bricks/brick1/testvol_distributed-dispersed_brick1/ list-cnt 10 Brick: server/bricks/brick1/testvol_distributed-dispersed_brick1 Count filename ======================= 9 /user11/dir1/dir4/testfile2.txt 9 /user11/dir1/dir1/testfile0.txt 9 /user11/dir0/dir4/testfile4.txt 9 /user11/dir0/dir3/testfile4.txt 9 /user11/dir0/dir1/testfile0.txt 9 /user11/testfile4.txt 9 /user11/testfile3.txt 5 /user11/dir2/dir1/testfile4.txt 5 /user11/dir2/dir1/testfile0.txt 5 /user11/dir2/testfile2.txt
17.2.3. 最も大きいファイル書き込み呼び出しの表示
# gluster volume top testvol_distributed-dispersed write brick `hostname`:/bricks/brick1/testvol_distributed-dispersed_brick1/ list-cnt 10 Brick: server/bricks/brick1/testvol_distributed-dispersed_brick1 Count filename ======================= 8 /user12/dir4/dir4/testfile3.txt 8 /user12/dir4/dir3/testfile3.txt 8 /user2/dir4/dir3/testfile4.txt 8 /user3/dir4/dir4/testfile1.txt 8 /user12/dir4/dir2/testfile3.txt 8 /user2/dir4/dir1/testfile0.txt 8 /user11/dir4/dir3/testfile4.txt 8 /user3/dir4/dir2/testfile2.txt 8 /user12/dir4/dir0/testfile0.txt 8 /user11/dir4/dir3/testfile3.txt
17.2.4. ディレクトリーで最も高いオープンコールの表示
# gluster volume top testvol_distributed-dispersed opendir brick `hostname`:/bricks/brick1/testvol_distributed-dispersed_brick1/ list-cnt 10 Brick: server/bricks/brick1/testvol_distributed-dispersed_brick1 Count filename ======================= 3 /user2/dir3/dir2 3 /user2/dir3/dir1 3 /user2/dir3/dir0 3 /user2/dir3 3 /user2/dir2/dir4 3 /user2/dir2/dir3 3 /user2/dir2/dir2 3 /user2/dir2/dir1 3 /user2/dir2/dir0 3 /user2/dir2
17.2.5. ディレクトリーでの最も高い読み取り呼び出しの表示
# gluster volume top testvol_distributed-dispersed readdir brick `hostname`:/bricks/brick1/testvol_distributed-dispersed_brick1/ list-cnt 10 Brick: server/bricks/brick1/testvol_distributed-dispersed_brick1 Count filename ======================= 4 /user6/dir2/dir3 4 /user6/dir1/dir4 4 /user6/dir1/dir2 4 /user6/dir1 4 /user6/dir0 4 /user13/dir1/dir1 4 /user3/dir4/dir4 4 /user3/dir3/dir4 4 /user3/dir3/dir3 4 /user3/dir3/dir1
17.2.6. 読み取りパフォーマンスの表示
server:/export/
で読み取りパフォーマンスを確認し、256 ブロックサイズを指定し、上位 10 件の結果を一覧表示するには、以下を実行します。
# gluster volume top testvol_distributed-dispersed read-perf bs 256 count 1 brick `hostname`:/bricks/brick1/testvol_distributed-dispersed_brick1/ list-cnt 10 Brick: server/bricks/brick1/testvol_distributed-dispersed_brick1 Throughput 10.67 MBps time 0.0000 secs MBps Filename Time ==== ======== ==== 0 /user2/dir3/dir2/testfile3.txt 2021-02-01 15:47:35.391234 0 /user2/dir3/dir2/testfile0.txt 2021-02-01 15:47:35.371018 0 /user2/dir3/dir1/testfile4.txt 2021-02-01 15:47:33.375333 0 /user2/dir3/dir1/testfile0.txt 2021-02-01 15:47:31.859194 0 /user2/dir3/dir0/testfile2.txt 2021-02-01 15:47:31.749105 0 /user2/dir3/dir0/testfile1.txt 2021-02-01 15:47:31.728151 0 /user2/dir3/testfile4.txt 2021-02-01 15:47:31.296924 0 /user2/dir3/testfile3.txt 2021-02-01 15:47:30.988683 0 /user2/dir3/testfile0.txt 2021-02-01 15:47:30.557743 0 /user2/dir2/dir4/testfile4.txt 2021-02-01 15:47:30.464017
17.2.7. 書き込みパフォーマンスの表示
server:/export/
で書き込みパフォーマンスを確認し、256 ブロックサイズを指定し、上位 10 件の結果を一覧表示するには、以下を実行します。
# gluster volume top testvol_distributed-dispersed write-perf bs 256 count 1 brick `hostname`:/bricks/brick1/testvol_distributed-dispersed_brick1/ list-cnt 10 Brick: server/bricks/brick1/testvol_distributed-dispersed_brick1 Throughput 3.88 MBps time 0.0001 secs MBps Filename Time ==== ======== ==== 0 /user12/dir4/dir4/testfile4.txt 2021-02-01 13:30:32.225628 0 /user12/dir4/dir4/testfile3.txt 2021-02-01 13:30:31.771095 0 /user12/dir4/dir4/testfile0.txt 2021-02-01 13:30:29.655447 0 /user12/dir4/dir3/testfile4.txt 2021-02-01 13:30:29.62920 0 /user12/dir4/dir3/testfile3.txt 2021-02-01 13:30:28.995407 0 /user2/dir4/dir4/testfile2.txt 2021-02-01 13:30:28.489318 0 /user2/dir4/dir4/testfile1.txt 2021-02-01 13:30:27.956523 0 /user2/dir4/dir3/testfile4.txt 2021-02-01 13:30:27.34337 0 /user12/dir4/dir3/testfile0.txt 2021-02-01 13:30:26.699984 0 /user3/dir4/dir4/testfile2.txt 2021-02-01 13:30:26.602165
17.3. ボリュームの一覧表示
# gluster volume list test-volume volume1 volume2 volume3
17.4. ボリューム情報の表示
# gluster volume info test-volume Volume Name: test-volume Type: Distribute Status: Created Number of Bricks: 4 Bricks: Brick1: server1:/rhgs/brick1 Brick2: server2:/rhgs/brick2 Brick3: server3:/rhgs/brick3 Brick4: server4:/rhgs/brick4
17.5. ノード情報の取得
get-state コマンドの実行
get-state コマンドは、ノードについての情報を指定されたファイルに出力し、さまざまな方法で呼び出すことができます。以下の表は、get-state コマンドで使用できるオプションを示しています。
# gluster get-state [odir path_to_output_dir] [file filename
] [detail|volumeoptions]
Usage: get-state [options]
表17.1 get-state コマンドのオプション
コマンド | 詳細 |
---|---|
gluster get-state | glusterd 状態情報は /var/run/gluster/glusterd_state_timestamp に保存されます。 |
gluster get-state file filename | glusterd の状態情報は、コマンドで指定した filename で /var/run/gluster/ ディレクトリーに保存されます。 |
gluster get-state odir directory file filename | glusterd の状態情報は、ディレクトリーと、コマンドで指定されたファイル名に保存されます。 |
gluster get-state detail | glusterd 状態情報は /var/run/gluster/glusterd_state_timestamp ファイルに保存され、ブリックごとに接続されたすべてのクライアントは出力に含まれます。 |
gluster get-state volumeoptions | glusterd 状態情報は /var/run/gluster/glusterd_state_timestamp ファイルに保存され、すべてのボリュームオプションの値が出力に含まれます。 |
サンプルでの出力の解釈
get-state コマンドを呼び出すと、glusterd で維持されているように、信頼できるストレージプールのノードレベルステータスを (現在は他のデーモンはサポートされません) コマンドで指定したファイルに反映する情報を保存します。デフォルトでは、出力は /var/run/gluster/glusterd_state_timestamp
ファイルにダンプされます。
表17.2 出力の説明
セクション | 詳細 |
---|---|
グローバル | glusterd の UUID と op-version を表示します。 |
グローバルオプション | ボリュームセットコマンドを使用して明示的に設定されているクラスター固有のオプションを表示します。 |
ピア | ホスト名や接続ステータスなど、ピアノード情報を表示します。 |
ボリューム | このノードで作成されたボリュームの一覧と、各ボリュームの詳細情報を表示します。 |
サービス | このノードで設定されているサービスとそのステータスを表示します。 |
Misc | ノードに関するその他の情報を表示します。たとえば、設定されたポートなどです。 |
# gluster get-state
glusterd state dumped to /var/run/gluster/glusterd_state_timestamp
[Global] MYUUID: 5392df4c-aeb9-4e8c-9001-58e984897bf6 op-version: 70200 [Global options] [Peers] Peer1.primary_hostname: output omitted Peer1.uuid: 19700669-dff6-4d9f-bf73-ca370c7dc462 Peer1.state: Peer in Cluster Peer1.connected: Connected Peer1.othernames: Peer2.primary_hostname: output omitted Peer2.uuid: 179d4a5d-0539-4c4e-91a4-2e5bebad25a9 Peer2.state: Peer in Cluster Peer2.connected: Connected Peer2.othernames: Peer3.primary_hostname: output omitted Peer3.uuid: 80c715a0-5b67-4e7d-8e6e-0449955d1f66 Peer3.state: Peer in Cluster Peer3.connected: Connected Peer3.othernames: Peer4.primary_hostname: output omitted Peer4.uuid: bed027c6-596f-43a1-b250-11e252a1c524 Peer4.state: Peer in Cluster Peer4.connected: Connected Peer4.othernames: Peer5.primary_hostname: output omitted Peer5.uuid: d7084399-d47c-4f36-991b-9bd2e9e52dd4 Peer5.state: Peer in Cluster Peer5.connected: Connected Peer5.othernames: [Volumes] Volume1.name: ecv6012 Volume1.id: e33fbc3e-9240-4024-975d-5f3ed8ce2540 Volume1.type: Distributed-Disperse Volume1.transport_type: tcp Volume1.status: Started Volume1.profile_enabled: 0 Volume1.brickcount: 18 Volume1.Brick1.path: output omitted:/gluster/brick1/ecv6012 Volume1.Brick1.hostname: output omitted Volume1.Brick2.path: output omitted:/gluster/brick1/ecv6012 Volume1.Brick2.hostname: output omitted Volume1.Brick3.path: output omitted:/gluster/brick1/ecv6012 Volume1.Brick3.hostname: output omitted Volume1.Brick3.port: 49152 Volume1.Brick3.rdma_port: 0 Volume1.Brick3.port_registered: 1 Volume1.Brick3.status: Started Volume1.Brick3.spacefree: 423360098304Bytes Volume1.Brick3.spacetotal: 427132190720Bytes Volume1.Brick4.path: output omitted:/gluster/brick1/ecv6012 Volume1.Brick4.hostname: output omitted Volume1.Brick5.path: output omitted:/gluster/brick1/ecv6012 Volume1.Brick5.hostname: output omitted Volume1.Brick6.path: output omitted:/gluster/brick1/ecv6012 Volume1.Brick6.hostname: output omitted Volume1.Brick7.path: output omitted:/gluster/brick2/ecv6012 Volume1.Brick7.hostname: output omitted Volume1.Brick8.path: output omitted:/gluster/brick2/ecv6012 Volume1.Brick8.hostname: output omitted Volume1.Brick9.path: output omitted:/gluster/brick2/ecv6012 Volume1.Brick9.hostname: output omitted Volume1.Brick9.port: 49153 Volume1.Brick9.rdma_port: 0 Volume1.Brick9.port_registered: 1 Volume1.Brick9.status: Started Volume1.Brick9.spacefree: 423832850432Bytes Volume1.Brick9.spacetotal: 427132190720Bytes Volume1.Brick10.path: output omitted:/gluster/brick2/ecv6012 Volume1.Brick10.hostname: output omitted Volume1.Brick11.path: output omitted:/gluster/brick2/ecv6012 Volume1.Brick11.hostname: output omitted Volume1.Brick12.path: output omitted:/gluster/brick2/ecv6012 Volume1.Brick12.hostname: output omitted Volume1.Brick13.path: output omitted:/gluster/brick3/ecv6012 Volume1.Brick13.hostname: output omitted Volume1.Brick14.path: output omitted:/gluster/brick3/ecv6012 Volume1.Brick14.hostname: output omitted Volume1.Brick15.path: output omitted:/gluster/brick3/ecv6012 Volume1.Brick15.hostname: output omitted Volume1.Brick15.port: 49154 Volume1.Brick15.rdma_port: 0 Volume1.Brick15.port_registered: 1 Volume1.Brick15.status: Started Volume1.Brick15.spacefree: 423877419008Bytes Volume1.Brick15.spacetotal: 427132190720Bytes Volume1.Brick16.path: output omitted:/gluster/brick3/ecv6012 Volume1.Brick16.hostname: output omitted Volume1.Brick17.path: output omitted:/gluster/brick3/ecv6012 Volume1.Brick17.hostname: output omitted Volume1.Brick18.path: output omitted:/gluster/brick3/ecv6012 Volume1.Brick18.hostname: output omitted Volume1.snap_count: 0 Volume1.stripe_count: 1 Volume1.replica_count: 1 Volume1.subvol_count: 3 Volume1.arbiter_count: 0 Volume1.disperse_count: 6 Volume1.redundancy_count: 2 Volume1.quorum_status: not_applicable Volume1.snapd_svc.online_status: Offline Volume1.snapd_svc.inited: true Volume1.rebalance.id: 00000000-0000-0000-0000-000000000000 Volume1.rebalance.status: not_started Volume1.rebalance.failures: 0 Volume1.rebalance.skipped: 0 Volume1.rebalance.lookedup: 0 Volume1.rebalance.files: 0 Volume1.rebalance.data: 0Bytes Volume1.time_left: 0 Volume1.gsync_count: 0 Volume1.options.server.event-threads: 8 Volume1.options.client.event-threads: 8 Volume1.options.disperse.shd-max-threads: 24 Volume1.options.transport.address-family: inet Volume1.options.storage.fips-mode-rchecksum: on Volume1.options.nfs.disable: on [Services] svc1.name: glustershd svc1.online_status: Online svc2.name: nfs svc2.online_status: Offline svc3.name: bitd svc3.online_status: Offline svc4.name: scrub svc4.online_status: Offline svc5.name: quotad svc5.online_status: Offline [Misc] Base port: 49152 Last allocated port: 49154
# gluster get-state volumeoptions
glusterd state dumped to /var/run/gluster/glusterd_state_timestamp
[Volume Options] Volume1.name: ecv6012 Volume1.options.count: 374 Volume1.options.value374: (null) Volume1.options.key374: features.cloudsync-product-id Volume1.options.value373: (null) Volume1.options.key373: features.cloudsync-store-id Volume1.options.value372: off Volume1.options.key372: features.cloudsync-remote-read Volume1.options.value371: off Volume1.options.key371: features.enforce-mandatory-lock Volume1.options.value370: (null) Volume1.options.key370: features.cloudsync-storetype Volume1.options.value369: on Volume1.options.key369: ctime.noatime Volume1.options.value368: off Volume1.options.key368: features.ctime Volume1.options.value367: off Volume1.options.key367: features.cloudsync Volume1.options.value366: off Volume1.options.key366: features.sdfs Volume1.options.value365: on Volume1.options.key365: disperse.parallel-writes Volume1.options.value364: Volume1.options.key364: delay-gen.enable Volume1.options.value363: 100000 Volume1.options.key363: delay-gen.delay-duration Volume1.options.value362: 10% Volume1.options.key362: delay-gen.delay-percentage Volume1.options.value361: off Volume1.options.key361: debug.delay-gen Volume1.options.value360: INFO Volume1.options.key360: cluster.daemon-log-level Volume1.options.value359: off Volume1.options.key359: features.selinux Volume1.options.value358: 2 Volume1.options.key358: cluster.halo-min-replicas Volume1.options.value357: 99999 Volume1.options.key357: cluster.halo-max-replicas Volume1.options.value356: 5 Volume1.options.key356: cluster.halo-max-latency Volume1.options.value355: 5 Volume1.options.key355: cluster.halo-nfsd-max-latency Volume1.options.value354: 99999 Volume1.options.key354: cluster.halo-shd-max-latency Volume1.options.value353: False Volume1.options.key353: cluster.halo-enabled Volume1.options.value352: 4 Volume1.options.key352: disperse.stripe-cache Volume1.options.value351: on Volume1.options.key351: disperse.optimistic-change-log Volume1.options.value350: 250 Volume1.options.key350: cluster.max-bricks-per-process Volume1.options.value349: 100 Volume1.options.key349: glusterd.vol_count_per_thread Volume1.options.value348: disable Volume1.options.key348: cluster.brick-multiplex Volume1.options.value347: 60 Volume1.options.key347: performance.nl-cache-timeout Volume1.options.value346: 10MB Volume1.options.key346: performance.nl-cache-limit Volume1.options.value345: false Volume1.options.key345: performance.nl-cache-positive-entry Volume1.options.value344: 10MB Volume1.options.key344: performance.rda-cache-limit Volume1.options.value343: 128KB Volume1.options.key343: performance.rda-high-wmark Volume1.options.value342: 4096 Volume1.options.key342: performance.rda-low-wmark Volume1.options.value341: 131072 Volume1.options.key341: performance.rda-request-size Volume1.options.value340: off Volume1.options.key340: performance.parallel-readdir Volume1.options.value339: off Volume1.options.key339: cluster.use-compound-fops Volume1.options.value338: 1 Volume1.options.key338: disperse.self-heal-window-size Volume1.options.value337: auto Volume1.options.key337: disperse.cpu-extensions Volume1.options.value336: 1024 Volume1.options.key336: disperse.shd-wait-qlength Volume1.options.value335: 1 Volume1.options.key335: disperse.shd-max-threads Volume1.options.value334: 5 Volume1.options.key334: features.locks-notify-contention-delay Volume1.options.value333: yes Volume1.options.key333: features.locks-notify-contention Volume1.options.value332: false Volume1.options.key332: features.locks-monkey-unlocking Volume1.options.value331: 0 Volume1.options.key331: features.locks-revocation-max-blocked Volume1.options.value330: false Volume1.options.key330: features.locks-revocation-clear-all Volume1.options.value329: 0 Volume1.options.key329: features.locks-revocation-secs Volume1.options.value328: on Volume1.options.key328: cluster.granular-entry-heal Volume1.options.value327: full Volume1.options.key327: cluster.locking-scheme Volume1.options.value326: 1024 Volume1.options.key326: cluster.shd-wait-qlength Volume1.options.value325: 1 Volume1.options.key325: cluster.shd-max-threads Volume1.options.value324: gfid-hash Volume1.options.key324: disperse.read-policy Volume1.options.value323: on Volume1.options.key323: dht.force-readdirp Volume1.options.value322: 600 Volume1.options.key322: cluster.heal-timeout Volume1.options.value321: 128 Volume1.options.key321: disperse.heal-wait-qlength Volume1.options.value320: 8 Volume1.options.key320: disperse.background-heals Volume1.options.value319: 60 Volume1.options.key319: features.lease-lock-recall-timeout Volume1.options.value318: off Volume1.options.key318: features.leases Volume1.options.value317: off Volume1.options.key317: ganesha.enable Volume1.options.value316: 60 Volume1.options.key316: features.cache-invalidation-timeout Volume1.options.value315: off Volume1.options.key315: features.cache-invalidation Volume1.options.value314: 120 Volume1.options.key314: features.expiry-time Volume1.options.value313: false Volume1.options.key313: features.scrub Volume1.options.value312: biweekly Volume1.options.key312: features.scrub-freq Volume1.options.value311: lazy Volume1.options.key311: features.scrub-throttle Volume1.options.value310: 100 Volume1.options.key310: features.shard-deletion-rate Volume1.options.value309: 16384 Volume1.options.key309: features.shard-lru-limit Volume1.options.value308: 64MB Volume1.options.key308: features.shard-block-size Volume1.options.value307: off Volume1.options.key307: features.shard Volume1.options.value306: (null) Volume1.options.key306: client.bind-insecure Volume1.options.value305: no Volume1.options.key305: cluster.quorum-reads Volume1.options.value304: enable Volume1.options.key304: cluster.disperse-self-heal-daemon Volume1.options.value303: off Volume1.options.key303: locks.mandatory-locking Volume1.options.value302: off Volume1.options.key302: locks.trace Volume1.options.value301: 25000 Volume1.options.key301: features.ctr-sql-db-wal-autocheckpoint Volume1.options.value300: 12500 Volume1.options.key300: features.ctr-sql-db-cachesize Volume1.options.value299: 300 Volume1.options.key299: features.ctr_lookupheal_inode_timeout Volume1.options.value298: 300 Volume1.options.key298: features.ctr_lookupheal_link_timeout Volume1.options.value297: off Volume1.options.key297: features.ctr_link_consistency Volume1.options.value296: off Volume1.options.key296: features.ctr-record-metadata-heat Volume1.options.value295: off Volume1.options.key295: features.record-counters Volume1.options.value294: off Volume1.options.key294: features.ctr-enabled Volume1.options.value293: 604800 Volume1.options.key293: cluster.tier-cold-compact-frequency Volume1.options.value292: 604800 Volume1.options.key292: cluster.tier-hot-compact-frequency Volume1.options.value291: on Volume1.options.key291: cluster.tier-compact Volume1.options.value290: 100 Volume1.options.key290: cluster.tier-query-limit Volume1.options.value289: 10000 Volume1.options.key289: cluster.tier-max-files Volume1.options.value288: 4000 Volume1.options.key288: cluster.tier-max-mb Volume1.options.value287: 0 Volume1.options.key287: cluster.tier-max-promote-file-size Volume1.options.value286: cache Volume1.options.key286: cluster.tier-mode Volume1.options.value285: 75 Volume1.options.key285: cluster.watermark-low Volume1.options.value284: 90 Volume1.options.key284: cluster.watermark-hi Volume1.options.value283: 3600 Volume1.options.key283: cluster.tier-demote-frequency Volume1.options.value282: 120 Volume1.options.key282: cluster.tier-promote-frequency Volume1.options.value281: off Volume1.options.key281: cluster.tier-pause Volume1.options.value280: 0 Volume1.options.key280: cluster.read-freq-threshold Volume1.options.value279: 0 Volume1.options.key279: cluster.write-freq-threshold Volume1.options.value278: disable Volume1.options.key278: cluster.enable-shared-storage Volume1.options.value277: off Volume1.options.key277: features.trash-internal-op Volume1.options.value276: 5MB Volume1.options.key276: features.trash-max-filesize Volume1.options.value275: (null) Volume1.options.key275: features.trash-eliminate-path Volume1.options.value274: .trashcan Volume1.options.key274: features.trash-dir Volume1.options.value273: off Volume1.options.key273: features.trash Volume1.options.value272: 120 Volume1.options.key272: features.barrier-timeout Volume1.options.value271: disable Volume1.options.key271: features.barrier Volume1.options.value270: off Volume1.options.key270: changelog.capture-del-path Volume1.options.value269: 120 Volume1.options.key269: changelog.changelog-barrier-timeout Volume1.options.value268: 5 Volume1.options.key268: changelog.fsync-interval Volume1.options.value267: 15 Volume1.options.key267: changelog.rollover-time Volume1.options.value266: ascii Volume1.options.key266: changelog.encoding Volume1.options.value265: {{ brick.path }}/.glusterfs/changelogs Volume1.options.key265: changelog.changelog-dir Volume1.options.value264: off Volume1.options.key264: changelog.changelog Volume1.options.value263: 51 Volume1.options.key263: cluster.server-quorum-ratio Volume1.options.value262: off Volume1.options.key262: cluster.server-quorum-type Volume1.options.value261: off Volume1.options.key261: config.gfproxyd Volume1.options.value260: off Volume1.options.key260: features.ctime Volume1.options.value259: 100 Volume1.options.key259: storage.max-hardlinks Volume1.options.value258: 0777 Volume1.options.key258: storage.create-directory-mask Volume1.options.value257: 0777 Volume1.options.key257: storage.create-mask Volume1.options.value256: 0000 Volume1.options.key256: storage.force-directory-mode Volume1.options.value255: 0000 Volume1.options.key255: storage.force-create-mode Volume1.options.value254: on Volume1.options.key254: storage.fips-mode-rchecksum Volume1.options.value253: 20 Volume1.options.key253: storage.health-check-timeout Volume1.options.value252: 1 Volume1.options.key252: storage.reserve Volume1.options.value251: : Volume1.options.key251: storage.gfid2path-separator Volume1.options.value250: on Volume1.options.key250: storage.gfid2path Volume1.options.value249: off Volume1.options.key249: storage.build-pgfid Volume1.options.value248: 30 Volume1.options.key248: storage.health-check-interval Volume1.options.value247: off Volume1.options.key247: storage.node-uuid-pathinfo Volume1.options.value246: -1 Volume1.options.key246: storage.owner-gid Volume1.options.value245: -1 Volume1.options.key245: storage.owner-uid Volume1.options.value244: 0 Volume1.options.key244: storage.batch-fsync-delay-usec Volume1.options.value243: reverse-fsync Volume1.options.key243: storage.batch-fsync-mode Volume1.options.value242: off Volume1.options.key242: storage.linux-aio Volume1.options.value241: 180 Volume1.options.key241: features.auto-commit-period Volume1.options.value240: relax Volume1.options.key240: features.retention-mode Volume1.options.value239: 120 Volume1.options.key239: features.default-retention-period Volume1.options.value238: on Volume1.options.key238: features.worm-files-deletable Volume1.options.value237: off Volume1.options.key237: features.worm-file-level Volume1.options.value236: off Volume1.options.key236: features.worm Volume1.options.value235: off Volume1.options.key235: features.read-only Volume1.options.value234: (null) Volume1.options.key234: nfs.auth-cache-ttl-sec Volume1.options.value233: (null) Volume1.options.key233: nfs.auth-refresh-interval-sec Volume1.options.value232: (null) Volume1.options.key232: nfs.exports-auth-enable Volume1.options.value231: 2 Volume1.options.key231: nfs.event-threads Volume1.options.value230: on Volume1.options.key230: nfs.rdirplus Volume1.options.value229: (1 * 1048576ULL) Volume1.options.key229: nfs.readdir-size Volume1.options.value228: (1 * 1048576ULL) Volume1.options.key228: nfs.write-size Volume1.options.value227: (1 * 1048576ULL) Volume1.options.key227: nfs.read-size Volume1.options.value226: 0x20000 Volume1.options.key226: nfs.drc-size Volume1.options.value225: off Volume1.options.key225: nfs.drc Volume1.options.value224: off Volume1.options.key224: nfs.server-aux-gids Volume1.options.value223: /sbin/rpc.statd Volume1.options.key223: nfs.rpc-statd Volume1.options.value222: /var/lib/glusterd/nfs/rmtab Volume1.options.key222: nfs.mount-rmtab Volume1.options.value221: off Volume1.options.key221: nfs.mount-udp Volume1.options.value220: on Volume1.options.key220: nfs.acl Volume1.options.value219: on Volume1.options.key219: nfs.nlm Volume1.options.value218: on Volume1.options.key218: nfs.disable Volume1.options.value217: Volume1.options.key217: nfs.export-dir Volume1.options.value216: read-write Volume1.options.key216: nfs.volume-access Volume1.options.value215: off Volume1.options.key215: nfs.trusted-write Volume1.options.value214: off Volume1.options.key214: nfs.trusted-sync Volume1.options.value213: off Volume1.options.key213: nfs.ports-insecure Volume1.options.value212: none Volume1.options.key212: nfs.rpc-auth-reject Volume1.options.value211: all Volume1.options.key211: nfs.rpc-auth-allow Volume1.options.value210: on Volume1.options.key210: nfs.rpc-auth-null Volume1.options.value209: on Volume1.options.key209: nfs.rpc-auth-unix Volume1.options.value208: 2049 Volume1.options.key208: nfs.port Volume1.options.value207: 16 Volume1.options.key207: nfs.outstanding-rpc-limit Volume1.options.value206: on Volume1.options.key206: nfs.register-with-portmap Volume1.options.value205: off Volume1.options.key205: nfs.dynamic-volumes Volume1.options.value204: off Volume1.options.key204: nfs.addr-namelookup Volume1.options.value203: on Volume1.options.key203: nfs.export-volumes Volume1.options.value202: on Volume1.options.key202: nfs.export-dirs Volume1.options.value201: 15 Volume1.options.key201: nfs.mem-factor Volume1.options.value200: no Volume1.options.key200: nfs.enable-ino32 Volume1.options.value199: (null) Volume1.options.key199: debug.error-fops Volume1.options.value198: off Volume1.options.key198: debug.random-failure Volume1.options.value197: (null) Volume1.options.key197: debug.error-number Volume1.options.value196: (null) Volume1.options.key196: debug.error-failure Volume1.options.value195: off Volume1.options.key195: debug.error-gen Volume1.options.value194: (null) Volume1.options.key194: debug.include-ops Volume1.options.value193: (null) Volume1.options.key193: debug.exclude-ops Volume1.options.value192: no Volume1.options.key192: debug.log-file Volume1.options.value191: no Volume1.options.key191: debug.log-history Volume1.options.value190: off Volume1.options.key190: debug.trace Volume1.options.value189: disable Volume1.options.key189: features.bitrot Volume1.options.value188: off Volume1.options.key188: features.inode-quota Volume1.options.value187: off Volume1.options.key187: features.quota Volume1.options.value186: off Volume1.options.key186: geo-replication.ignore-pid-check Volume1.options.value185: off Volume1.options.key185: geo-replication.ignore-pid-check Volume1.options.value184: off Volume1.options.key184: geo-replication.indexing Volume1.options.value183: off Volume1.options.key183: geo-replication.indexing Volume1.options.value182: off Volume1.options.key182: features.quota-deem-statfs Volume1.options.value181: 86400 Volume1.options.key181: features.alert-time Volume1.options.value180: 5 Volume1.options.key180: features.hard-timeout Volume1.options.value179: 60 Volume1.options.key179: features.soft-timeout Volume1.options.value178: 80% Volume1.options.key178: features.default-soft-limit Volume1.options.value171: off Volume1.options.key171: features.tag-namespaces Volume1.options.value170: off Volume1.options.key170: features.show-snapshot-directory Volume1.options.value169: .snaps Volume1.options.key169: features.snapshot-directory Volume1.options.value168: off Volume1.options.key168: features.uss Volume1.options.value167: true Volume1.options.key167: performance.global-cache-invalidation Volume1.options.value166: false Volume1.options.key166: performance.cache-invalidation Volume1.options.value165: true Volume1.options.key165: performance.force-readdirp Volume1.options.value164: off Volume1.options.key164: performance.nfs.io-threads Volume1.options.value163: off Volume1.options.key163: performance.nfs.stat-prefetch Volume1.options.value162: off Volume1.options.key162: performance.nfs.quick-read Volume1.options.value161: off Volume1.options.key161: performance.nfs.io-cache Volume1.options.value160: off Volume1.options.key160: performance.nfs.read-ahead Volume1.options.value159: on Volume1.options.key159: performance.nfs.write-behind Volume1.options.value158: off Volume1.options.key158: performance.client-io-threads Volume1.options.value157: on Volume1.options.key157: performance.stat-prefetch Volume1.options.value156: off Volume1.options.key156: performance.nl-cache Volume1.options.value155: on Volume1.options.key155: performance.quick-read Volume1.options.value154: on Volume1.options.key154: performance.open-behind Volume1.options.value153: on Volume1.options.key153: performance.io-cache Volume1.options.value152: off Volume1.options.key152: performance.readdir-ahead Volume1.options.value151: on Volume1.options.key151: performance.read-ahead Volume1.options.value150: on Volume1.options.key150: performance.write-behind Volume1.options.value149: inet Volume1.options.key149: transport.address-family Volume1.options.value148: 1024 Volume1.options.key148: transport.listen-backlog Volume1.options.value147: 9 Volume1.options.key147: server.keepalive-count Volume1.options.value146: 2 Volume1.options.key146: server.keepalive-interval Volume1.options.value145: 20 Volume1.options.key145: server.keepalive-time Volume1.options.value144: 42 Volume1.options.key144: server.tcp-user-timeout Volume1.options.value143: 2 Volume1.options.key143: server.event-threads Volume1.options.value142: (null) Volume1.options.key142: server.own-thread Volume1.options.value141: 300 Volume1.options.key141: server.gid-timeout Volume1.options.value140: on Volume1.options.key140: client.send-gids Volume1.options.value139: on Volume1.options.key139: server.dynamic-auth Volume1.options.value138: off Volume1.options.key138: server.manage-gids Volume1.options.value137: * Volume1.options.key137: auth.ssl-allow Volume1.options.value136: off Volume1.options.key136: server.ssl Volume1.options.value135: 64 Volume1.options.key135: server.outstanding-rpc-limit Volume1.options.value134: /var/run/gluster Volume1.options.key134: server.statedump-path Volume1.options.value133: 65534 Volume1.options.key133: server.anongid Volume1.options.value132: 65534 Volume1.options.key132: server.anonuid Volume1.options.value131: off Volume1.options.key131: server.all-squash Volume1.options.value130: off Volume1.options.key130: server.root-squash Volume1.options.value129: on Volume1.options.key129: server.allow-insecure Volume1.options.value128: 1 Volume1.options.key128: transport.keepalive Volume1.options.value127: (null) Volume1.options.key127: auth.reject Volume1.options.value126: * Volume1.options.key126: auth.allow Volume1.options.value125: 16384 Volume1.options.key125: network.inode-lru-limit Volume1.options.value124: (null) Volume1.options.key124: network.tcp-window-size Volume1.options.value123: 9 Volume1.options.key123: client.keepalive-count Volume1.options.value122: 2 Volume1.options.key122: client.keepalive-interval Volume1.options.value121: 20 Volume1.options.key121: client.keepalive-time Volume1.options.value120: 0 Volume1.options.key120: client.tcp-user-timeout Volume1.options.value119: 2 Volume1.options.key119: client.event-threads Volume1.options.value118: disable Volume1.options.key118: network.remote-dio Volume1.options.value117: off Volume1.options.key117: client.ssl Volume1.options.value116: (null) Volume1.options.key116: network.tcp-window-size Volume1.options.value115: 42 Volume1.options.key115: network.ping-timeout Volume1.options.value114: 1800 Volume1.options.key114: network.frame-timeout Volume1.options.value113: off Volume1.options.key113: features.encryption Volume1.options.value112: false Volume1.options.key112: performance.nl-cache-pass-through Volume1.options.value111: Volume1.options.key111: performance.xattr-cache-list Volume1.options.value110: off Volume1.options.key110: performance.md-cache-statfs Volume1.options.value109: true Volume1.options.key109: performance.cache-ima-xattrs Volume1.options.value108: true Volume1.options.key108: performance.cache-capability-xattrs Volume1.options.value107: false Volume1.options.key107: performance.cache-samba-metadata Volume1.options.value106: true Volume1.options.key106: performance.cache-swift-metadata Volume1.options.value105: 1 Volume1.options.key105: performance.md-cache-timeout Volume1.options.value104: false Volume1.options.key104: performance.md-cache-pass-through Volume1.options.value103: false Volume1.options.key103: performance.readdir-ahead-pass-through Volume1.options.value102: false Volume1.options.key102: performance.read-ahead-pass-through Volume1.options.value101: 4 Volume1.options.key101: performance.read-ahead-page-count Volume1.options.value100: false Volume1.options.key100: performance.open-behind-pass-through Volume1.options.value99: yes Volume1.options.key99: performance.read-after-open Volume1.options.value98: yes Volume1.options.key98: performance.lazy-open Volume1.options.value97: on Volume1.options.key97: performance.nfs.write-behind-trickling-writes Volume1.options.value96: 128KB Volume1.options.key96: performance.aggregate-size Volume1.options.value95: on Volume1.options.key95: performance.write-behind-trickling-writes Volume1.options.value94: off Volume1.options.key94: performance.nfs.strict-write-ordering Volume1.options.value93: off Volume1.options.key93: performance.strict-write-ordering Volume1.options.value92: off Volume1.options.key92: performance.nfs.strict-o-direct Volume1.options.value91: off Volume1.options.key91: performance.strict-o-direct Volume1.options.value90: 1MB Volume1.options.key90: performance.nfs.write-behind-window-size Volume1.options.value89: off Volume1.options.key89: performance.resync-failed-syncs-after-fsync Volume1.options.value88: 1MB Volume1.options.key88: performance.write-behind-window-size Volume1.options.value87: on Volume1.options.key87: performance.nfs.flush-behind Volume1.options.value86: on Volume1.options.key86: performance.flush-behind Volume1.options.value85: false Volume1.options.key85: performance.ctime-invalidation Volume1.options.value84: false Volume1.options.key84: performance.quick-read-cache-invalidation Volume1.options.value83: 1 Volume1.options.key83: performance.qr-cache-timeout Volume1.options.value82: 128MB Volume1.options.key82: performance.cache-size Volume1.options.value81: false Volume1.options.key81: performance.io-cache-pass-through Volume1.options.value80: false Volume1.options.key80: performance.iot-pass-through Volume1.options.value79: off Volume1.options.key79: performance.iot-cleanup-disconnected-reqs Volume1.options.value78: (null) Volume1.options.key78: performance.iot-watchdog-secs Volume1.options.value77: on Volume1.options.key77: performance.enable-least-priority Volume1.options.value76: 1 Volume1.options.key76: performance.least-prio-threads Volume1.options.value75: 16 Volume1.options.key75: performance.low-prio-threads Volume1.options.value74: 16 Volume1.options.key74: performance.normal-prio-threads Volume1.options.value73: 16 Volume1.options.key73: performance.high-prio-threads Volume1.options.value72: 16 Volume1.options.key72: performance.io-thread-count Volume1.options.value71: 32MB Volume1.options.key71: performance.cache-size Volume1.options.value70: Volume1.options.key70: performance.cache-priority Volume1.options.value69: 1 Volume1.options.key69: performance.cache-refresh-timeout Volume1.options.value68: 0 Volume1.options.key68: performance.cache-min-file-size Volume1.options.value67: 0 Volume1.options.key67: performance.cache-max-file-size Volume1.options.value66: 86400 Volume1.options.key66: diagnostics.stats-dnscache-ttl-sec Volume1.options.value65: 65535 Volume1.options.key65: diagnostics.fop-sample-buf-size Volume1.options.value64: json Volume1.options.key64: diagnostics.stats-dump-format Volume1.options.value63: 0 Volume1.options.key63: diagnostics.fop-sample-interval Volume1.options.value62: 0 Volume1.options.key62: diagnostics.stats-dump-interval Volume1.options.value61: 120 Volume1.options.key61: diagnostics.client-log-flush-timeout Volume1.options.value60: 120 Volume1.options.key60: diagnostics.brick-log-flush-timeout Volume1.options.value59: 5 Volume1.options.key59: diagnostics.client-log-buf-size Volume1.options.value58: 5 Volume1.options.key58: diagnostics.brick-log-buf-size Volume1.options.value57: (null) Volume1.options.key57: diagnostics.client-log-format Volume1.options.value56: (null) Volume1.options.key56: diagnostics.brick-log-format Volume1.options.value55: (null) Volume1.options.key55: diagnostics.client-logger Volume1.options.value54: (null) Volume1.options.key54: diagnostics.brick-logger Volume1.options.value53: CRITICAL Volume1.options.key53: diagnostics.client-sys-log-level Volume1.options.value52: CRITICAL Volume1.options.key52: diagnostics.brick-sys-log-level Volume1.options.value51: INFO Volume1.options.key51: diagnostics.client-log-level Volume1.options.value50: INFO Volume1.options.key50: diagnostics.brick-log-level Volume1.options.value49: off Volume1.options.key49: diagnostics.count-fop-hits Volume1.options.value48: off Volume1.options.key48: diagnostics.dump-fd-stats Volume1.options.value47: off Volume1.options.key47: diagnostics.latency-measurement Volume1.options.value46: yes Volume1.options.key46: cluster.full-lock Volume1.options.value45: none Volume1.options.key45: cluster.favorite-child-policy Volume1.options.value44: 128 Volume1.options.key44: cluster.heal-wait-queue-length Volume1.options.value43: no Volume1.options.key43: cluster.consistent-metadata Volume1.options.value42: on Volume1.options.key42: cluster.ensure-durability Volume1.options.value41: 1 Volume1.options.key41: cluster.post-op-delay-secs Volume1.options.value40: 1KB Volume1.options.key40: cluster.self-heal-readdir-size Volume1.options.value39: true Volume1.options.key39: cluster.choose-local Volume1.options.value38: (null) Volume1.options.key38: cluster.quorum-count Volume1.options.value37: auto Volume1.options.key37: cluster.quorum-type Volume1.options.value36: 1 Volume1.options.key36: disperse.other-eager-lock-timeout Volume1.options.value35: 1 Volume1.options.key35: disperse.eager-lock-timeout Volume1.options.value34: on Volume1.options.key34: disperse.other-eager-lock Volume1.options.value33: on Volume1.options.key33: disperse.eager-lock Volume1.options.value32: on Volume1.options.key32: cluster.eager-lock Volume1.options.value31: (null) Volume1.options.key31: cluster.data-self-heal-algorithm Volume1.options.value30: on Volume1.options.key30: cluster.metadata-change-log Volume1.options.value29: on Volume1.options.key29: cluster.data-change-log Volume1.options.value28: 1 Volume1.options.key28: cluster.self-heal-window-size Volume1.options.value27: 600 Volume1.options.key27: cluster.heal-timeout Volume1.options.value26: on Volume1.options.key26: cluster.self-heal-daemon Volume1.options.value25: off Volume1.options.key25: cluster.entry-self-heal Volume1.options.value24: off Volume1.options.key24: cluster.data-self-heal Volume1.options.value23: off Volume1.options.key23: cluster.metadata-self-heal Volume1.options.value22: 8 Volume1.options.key22: cluster.background-self-heal-count Volume1.options.value21: 1 Volume1.options.key21: cluster.read-hash-mode Volume1.options.value20: -1 Volume1.options.key20: cluster.read-subvolume-index Volume1.options.value19: (null) Volume1.options.key19: cluster.read-subvolume Volume1.options.value18: on Volume1.options.key18: cluster.entry-change-log Volume1.options.value17: (null) Volume1.options.key17: cluster.switch-pattern Volume1.options.value16: on Volume1.options.key16: cluster.weighted-rebalance Volume1.options.value15: (null) Volume1.options.key15: cluster.local-volume-name Volume1.options.value14: off Volume1.options.key14: cluster.force-migration Volume1.options.value13: off Volume1.options.key13: cluster.lock-migration Volume1.options.value12: normal Volume1.options.key12: cluster.rebal-throttle Volume1.options.value11: off Volume1.options.key11: cluster.randomize-hash-range-by-gfid Volume1.options.value10: trusted.glusterfs.dht Volume1.options.key10: cluster.dht-xattr-name Volume1.options.value9: (null) Volume1.options.key9: cluster.extra-hash-regex Volume1.options.value8: (null) Volume1.options.key8: cluster.rsync-hash-regex Volume1.options.value7: off Volume1.options.key7: cluster.readdir-optimize Volume1.options.value6: (null) Volume1.options.key6: cluster.subvols-per-directory Volume1.options.value5: off Volume1.options.key5: cluster.rebalance-stats Volume1.options.value4: 5% Volume1.options.key4: cluster.min-free-inodes Volume1.options.value3: 10% Volume1.options.key3: cluster.min-free-disk Volume1.options.value2: on Volume1.options.key2: cluster.lookup-optimize Volume1.options.value1: on Volume1.options.key1: cluster.lookup-unhashed
17.6. 現在のボリュームオプション設定の取得
17.6.1. 特定のボリューム種別の値の取得
# gluster volume get <VOLNAME> <key>
# gluster volume get test-vol nfs.disable Option Value ------ ----- nfs.disable on
17.6.2. ボリュームのすべてのオプションの取得
# gluster volume get <VOLNAME> all
# gluster volume get test-vol all Option Value ------ ----- cluster.lookup-unhashed on cluster.lookup-optimize on cluster.min-free-disk 10% cluster.min-free-inodes 5% cluster.rebalance-stats off cluster.subvols-per-directory (null) ....
17.6.3. すべてのグローバルオプションの取得
# gluster volume get all all
# gluster volume get all all Option Value ------ ----- cluster.server-quorum-ratio 51 cluster.enable-shared-storage disable cluster.op-version 70200 cluster.max-op-version 70200 cluster.brick-multiplex disable cluster.max-bricks-per-process 250 cluster.daemon-log-level INFO
17.7. statedump を使用した完全なボリュームの状態の表示
# gluster volume statedump VOLNAME [[nfs|quotad] [all|mem|iobuf|callpool|priv|fd|inode|history] | [client hostname:pid]]
17.7.1. サーバーからの情報の収集
- all
- 利用可能な状態情報をダンプします。
- mem
- ブリックのメモリー使用量とメモリープールの詳細をダンプします。
- iobuf
- ブリックの iobuf の詳細をダンプします。
- priv
- ロードされたトランスレーターのプライベート情報をダンプします。
- callpool
- ボリュームの保留中の呼び出しをダンプします。
- fd
- ボリュームのオープンファイル記述子テーブルをダンプします。
- inode
- ボリュームの inode テーブルをダンプします。
- history
- ボリュームのイベント履歴をダンプします。
data
ボリュームに関する利用可能な情報をすべて書き出すには、サーバーで以下のコマンドを実行します。
# gluster volume statedump data all
# gluster volume statedump data history
nfs
パラメーターが必要です。上記のパラメーターのいずれかと組み合わせることで、出力をフィルタリングできます。
# gluster volume statedump VOLNAME nfs all
quotad
パラメーターが必要です。以下のコマンドは、すべてのノードでクォータデーモンの状態を書き込みます。
# gluster volume statedump VOLNAME quotad
# kill -SIGUSR1 pid
17.7.2. クライアントからの情報の収集
# gluster volume statedump VOLNAME client hostname:pid
# gluster volume statedump VOLNAME client localhost:pid
# kill -SIGUSR1 pid
gluster
グループのメンバーであることを確認します。たとえば、gfapi アプリケーションがユーザー qemu により実行される場合は、以下のコマンドを実行して qemu が gluster グループに追加されていることを確認します。
# usermod -a -G gluster qemu
17.7.3. statedump 出力の場所の制御
/var/run/gluster
ディレクトリーに保存されます。出力ファイルの名前は、以下の規則に従って名前が付けられます。
- ブリックプロセスの場合、
brick_path.brick_pid.dump
- ボリュームのプロセスおよび kill コマンドの結果については、
glusterdump-glusterd_pid.dump.timestamp
です。
server.statedump-path
パラメーターを使用します。
# gluster volume set VOLNAME server.statedump-path PATH
17.8. ボリュームの状態の表示
- 詳細: ブリックに関する追加情報を表示します。
- クライアント: ボリュームに接続されたクライアントの一覧を表示します。
- mem: ブリックのメモリー使用量とメモリープールの詳細を表示します。
- inode: ボリュームの inode テーブルを表示します。
- fd: ボリュームのオープンファイル記述子の表を表示します。
- Callpool: ボリュームの保留中の呼び出しを表示します。
タイムアウト期間の設定
特定のボリュームの情報の取得を試みると、オリジネーター glusterd
が 120 秒よりも長い場合に CLI からタイムアウトし、他のすべての glusterd
から結果を集約し、CLI に報告し直すことができます。
--timeout
オプションを使用すると、コマンドが 120 秒でタイムアウトしないようにします。
# gluster volume status --timeout=500 VOLNAME inode
--timeout
オプションを使用することが推奨されます。
# gluster volume status test-volume Status of volume: test-volume Gluster process Port Online Pid ------------------------------------------------------------ Brick Server1:/rhgs/brick0/rep1 24010 Y 18474 Brick Server1:/rhgs/brick0/rep2 24011 Y 18479 NFS Server on localhost 38467 Y 18486 Self-heal Daemon on localhost N/A Y 18491
# gluster volume status all Status of volume: test Gluster process Port Online Pid ----------------------------------------------------------- Brick Server1:/rhgs/brick0/test 24009 Y 29197 NFS Server on localhost 38467 Y 18486 Status of volume: test-volume Gluster process Port Online Pid ------------------------------------------------------------ Brick Server1:/rhgs/brick0/rep1 24010 Y 18474 Brick Server1:/rhgs/brick0/rep2 24011 Y 18479 NFS Server on localhost 38467 Y 18486 Self-heal Daemon on localhost N/A Y 18491
# gluster volume status test-volume detail Status of volume: test-vol ------------------------------------------------------------------------------ Brick : Brick Server1:/rhgs/test Port : 24012 Online : Y Pid : 18649 File System : xfs Device : /dev/sda1 Mount Options : rw,relatime,user_xattr,acl,commit=600,barrier=1,data=ordered Inode Size : 256 Disk Space Free : 22.1GB Total Disk Space : 46.5GB Inode Count : 3055616 Free Inodes : 2577164
# gluster volume status test-volume clients Brick : Server1:/rhgs/brick0/1 Clients connected : 2 Hostname Bytes Read BytesWritten OpVersion -------- --------- ------------ --------- 127.0.0.1:1013 776 676 70200 127.0.0.1:1012 50440 51200 70200
# gluster volume status glustervol mem Memory status for volume : glustervol ---------------------------------------------- Brick : rhsqaci-vm33.lab.eng.blr.redhat.com:/bricks/brick0/1 Mallinfo -------- Arena : 11509760 Ordblks : 278 Smblks : 16 Hblks : 17 Hblkhd : 17350656 Usmblks : 0 Fsmblks : 1376 Uordblks : 3850640 Fordblks : 7659120 Keepcost : 121632 ---------------------------------------------- Brick : rhsqaci-vm44.lab.eng.blr.redhat.com:/bricks/brick0/1 Mallinfo -------- Arena : 11595776 Ordblks : 329 Smblks : 44 Hblks : 17 Hblkhd : 17350656 Usmblks : 0 Fsmblks : 4240 Uordblks : 3888928 Fordblks : 7706848 Keepcost : 121632 ---------------------------------------------- Brick : rhsqaci-vm32.lab.eng.blr.redhat.com:/bricks/brick0/1 Mallinfo -------- Arena : 9695232 Ordblks : 306 Smblks : 67 Hblks : 17 Hblkhd : 17350656 Usmblks : 0 Fsmblks : 5616 Uordblks : 3890736 Fordblks : 5804496 Keepcost : 121632
# gluster volume status test inode inode tables for volume test ---------------------------------------------- Brick : rhsqaci-vm35.lab.eng.blr.redhat.com:/bricks/brick1/test Connection 1: LRU limit : 16384 Active Inodes : 1000 LRU Inodes : 1 Purge Inodes : 0
# gluster volume status test-volume fd FD tables for volume test-volume ---------------------------------------------- Brick : Server1:/rhgs/brick0/1 Connection 1: RefCount = 0 MaxFDs = 128 FirstFree = 4 FD Entry PID RefCount Flags -------- --- -------- ----- 0 26311 1 2 1 26310 3 2 2 26310 1 2 3 26311 3 2 Connection 2: RefCount = 0 MaxFDs = 128 FirstFree = 0 No open fds Connection 3: RefCount = 0 MaxFDs = 128 FirstFree = 0 No open fds
# gluster volume status test-volume callpool Pending calls for volume test-volume ---------------------------------------------- Brick : Server1:/rhgs/brick0/1 Pending calls: 2 Call Stack1 UID : 0 GID : 0 PID : 26338 Unique : 192138 Frames : 7 Frame 1 Ref Count = 1 Translator = test-volume-server Completed = No Frame 2 Ref Count = 0 Translator = test-volume-posix Completed = No Parent = test-volume-access-control Wind From = default_fsync Wind To = FIRST_CHILD(this)->fops->fsync Frame 3 Ref Count = 1 Translator = test-volume-access-control Completed = No Parent = repl-locks Wind From = default_fsync Wind To = FIRST_CHILD(this)->fops->fsync Frame 4 Ref Count = 1 Translator = test-volume-locks Completed = No Parent = test-volume-io-threads Wind From = iot_fsync_wrapper Wind To = FIRST_CHILD (this)->fops->fsync Frame 5 Ref Count = 1 Translator = test-volume-io-threads Completed = No Parent = test-volume-marker Wind From = default_fsync Wind To = FIRST_CHILD(this)->fops->fsync Frame 6 Ref Count = 1 Translator = test-volume-marker Completed = No Parent = /export/1 Wind From = io_stats_fsync Wind To = FIRST_CHILD(this)->fops->fsync Frame 7 Ref Count = 1 Translator = /export/1 Completed = No Parent = test-volume-server Wind From = server_fsync_resume Wind To = bound_xl->fops->fsync
17.9. Red Hat Gluster Storage Trusted Storage Pool の問題のトラブルシューティング
17.9.1. Red Hat Gluster Storage Trusted Storage Pool でのネットワーク問題のトラブルシューティング
# ping -s 1600 '-Mdo'IP_ADDRESS local error: Message too long, mtu=1500
第18章 リソース使用状況の管理
手順18.1 Gluster デーモンの CPU 使用率の制御
control-cpu-load
スクリプトは、cgroup フレームワークを使用してプロセスの CPU クォータを設定して、Gluster デーモンの CPU 使用率を制御するユーティリティーを提供します。
- 以下のコマンドを使用して scripts フォルダーに移動します。
# cd /usr/share/glusterfs/scripts
- 以下のコマンドを使用して、必要な gluster デーモンの PID を確認します。
# ps -aef | grep daemon_name
出力は以下の形式になります。root 1565...output omitted...grep --color=auto daemon_name
この出力では、1565 はデーモンサービスの PID を表します。PID が異なるシステムやデーモンの異なるインスタンスで一致しないため、このプロセスを実行するたびに関連する PID を確認するようにしてください。 - 以下のコマンドを使用して
control-cpu-load
スクリプトを実行します。# sh control-cpu-load.sh
- システムで以下の入力を求めるプロンプトが出されたら、前の手順で取得したデーモンの PID を入力して
Enter
キーを押します。[root@XX-XX scripts]# sh control-cpu-load.sh Enter gluster daemon pid for which you want to control CPU. 1565
- システムに以下の入力を求めるプロンプトが出されたら、
y
と入力してEnter
キーを押します。If you want to continue the script to attach 1565 with new cgroup_gluster_1565 cgroup Press (y/n)?
- システムが以下の通知を要求したら、デーモンに割り当てるのに必要なクォータ値を入力して
Enter
キーを押します。Creating child cgroup directory 'cgroup_gluster_1565 cgroup' for daemon_name.service. Enter quota value in range [10,100]: 25
この例では、デーモンサービスのクォータ値は25
に設定されます。クォータ値が正常に設定されていると、システムは以下のメッセージが表示されます。Entered quota value is 25 Setting 25000 to cpu.cfs_quota_us for gluster_cgroup. Tasks are attached successfully specific to 1565 to cgroup_gluster_1565.
手順18.2 Gluster デーモンのメモリー使用量の制御
control-mem
スクリプトは、cgroup フレームワークを使用してプロセスのメモリー制限を設定して、Gluster デーモンのメモリー使用率を制御するユーティリティーを提供します。
- 以下のコマンドを使用して scripts フォルダーに移動します。
# cd /usr/share/glusterfs/scripts
- 以下のコマンドを使用して、必要な gluster デーモンの PID を確認します。
# ps -aef | grep daemon_name
出力は以下の形式になります。root 1565 1 0 Feb05 ? 00:09:17 /usr/sbin/glusterfs -s localhost --volfile-id gluster/daemon_name -p /var/run/gluster/daemon_name/daemon_name.pid -l /var/log/glusterfs/daemon_name.log -S /var/run/gluster/ed49b959a0dc9b2185913084e3b2b339.socket --xlator-option *replicate*.node-uuid=13dbfa1e-ebbf-4cee-a1ac-ca6763903c55 root 16766 14420 0 19:00 pts/0 00:00:00 grep --color=auto daemon_name
この出力では、1565 はデーモンサービスの PID を表します。 - 以下のコマンドを使用して
control-cpu-load
スクリプトを実行します。# sh control-mem.sh
- システムが以下の入力を要求したら、前の手順で取得したデーモンの PID を入力して
Enter
キーを押します。[root@XX-XX scripts]# sh control-mem.sh Enter gluster daemon pid for which you want to control CPU. 1565
この例では、1565 はデーモンサービスの PID を表します。デーモンサービスの PID は、システムによって異なる場合があります。 - システムが以下の入力を要求したら、
y
と入力してEnter
キーを押します。If you want to continue the script to attach daeomon with new cgroup. Press (y/n)?
システムは、以下の通知を要求します。Creating child cgroup directory 'cgroup_gluster_1565 cgroup' for daemon_name.service.
- システムが以下の入力を要求したら、デーモンに割り当てるのに必要なメモリー値を入力して
Enter
キーを押します。Enter Memory value in Mega bytes [100,8000000000000]:
この例では、メモリー値は5000
に設定されます。メモリー値が正しく設定されていると、システムは以下のメッセージを表示します。Entered memory limit value is 5000. Setting 5242880000 to memory.limit_in_bytes for /sys/fs/cgroup/memory/system.slice/daemon_name.service/cgroup_gluster_1565. Tasks are attached successfully specific to 1565 to cgroup_gluster_1565.
第19章 パフォーマンスチューニング
19.1. ディスクの設定
19.1.1. ハードウェア RAID
19.1.2. JBOD
pass-through
モードを使用して raw
ドライブをオペレーティングシステムに公開することで実証します。
19.2. ブリック設定
手順19.1 ブリック設定
LVM レイヤー
物理デバイスからブリックを作成する手順を以下に示します。物理デバイスで複数のブリックを作成する手順の概要を「『例: 以下の物理デバイスに複数のブリックを作成する』」を参照してください。- 物理ボリュームの作成pvcreate コマンドは、物理ボリュームの作成に使用されます。論理ボリュームマネージャーは、残りのデータをデータ部分として使用する一方で、その物理ボリュームの一部を使用できます。物理ボリュームの作成時に
--dataalignment
オプションを使用して、論理ボリュームマネージャー (LVM) 層で I/O を調整します。コマンドは、以下の形式で使用されます。# pvcreate --dataalignment alignment_value disk
JBOD の場合は、256K
の調整の値を使用します。ハードウェア RAID の場合は、RAID ストライプユニットのサイズをデータディスクの数で乗算して、調整値を取得する必要があります。RAID 6 設定で 12 個のディスクを使用すると、データディスクの数は 10 になります。その一方で、RAID 10 設定に 12 個ディスクを使用する場合は、データディスクの数は 6 になります。たとえば、以下のコマンドは、ストライプユニットサイズが 128 KiB の RAID 6 設定の 12 個のディスクに適しています。# pvcreate --dataalignment 1280k disk
以下のコマンドは、ストライプユニットサイズが 256 KiB の RAID 10 設定の 12 個のディスクに適しています。# pvcreate --dataalignment 1536k disk
--dataalignment
に以前に設定した物理ボリューム設定を表示するには、以下のコマンドを実行します。# pvs -o +pe_start /dev/sdb PV VG Fmt Attr PSize PFree 1st PE /dev/sdb lvm2 a-- 9.09t 9.09t 1.25m
- ボリュームグループの作成ボリュームグループは、vgcreate コマンドを使用して作成されます。ハードウェア RAID では、ボリュームグループで作成した論理ボリュームが基礎となる RAID ジオメトリーに合わせて確認するには、
-- pysicalextentsize
オプションを指定することが重要です。以下の形式で vgcreate コマンドを実行します。# vgcreate --physicalextentsize extent_size VOLGROUP physical_volume
extent_size は、RAID ストライプユニットのサイズをデータディスクの数で乗算して取得する必要があります。RAID 6 設定で 12 個のディスクを使用すると、データディスクの数は 10 になります。その一方で、RAID 10 設定に 12 個ディスクを使用する場合は、データディスクの数は 6 になります。たとえば、ストライプユニットサイズが 128 KB で、12 のディスク (10 データディスク) で、RAID-6 ストレージに以下のコマンドを実行します。# vgcreate --physicalextentsize 1280k VOLGROUP physical_volume
JBOD の場合は、以下の形式で vgcreate コマンドを使用します。# vgcreate VOLGROUP physical_volume
- シンプールの作成シンプールは、シン論理ボリューム (LV) とそのスナップショットボリューム (存在する場合) 用のストレージの共通のプールを提供します。以下のコマンドを実行して、特定のサイズのシンプールを作成します。
# lvcreate --thin VOLGROUP/POOLNAME --size POOLSIZE --chunksize CHUNKSIZE --poolmetadatasize METASIZE --zero n
以下のコマンドを実行して、デバイスの最大サイズのシンプールを作成することもできます。# lvcreate --thin VOLGROUP/POOLNAME --extents 100%FREE --chunksize CHUNKSIZE --poolmetadatasize METASIZE --zero n
シンプール作成で推奨されるパラメーター値
- poolmetadatasize
- 内部的には、シンプールには、シン LV およびスナップショットの (動的) 割り当てた領域を追跡するために使用される個別のメタデータデバイスが含まれています。上記のコマンドの
poolmetadatasize
オプションは、プールメタデータデバイスのサイズを示しています。メタデータ LV の最大許容サイズは 16 GiB です。Red Hat Gluster Storage は、サポートされている最大サイズのメタデータデバイスを作成することを推奨します。領域が懸念される場合は、最大数未満を割り当てることができますが、この場合はプールサイズの最小 0.5% を割り当てる必要があります。警告メタデータプールの容量が不足すると、データを作成できません。これには、メタデータプールのサイズを増やすか、メタデータ領域が不足しているボリュームからデータを移行するために必要なデータが含まれます。lvs -o+metadata_percent コマンドを使用してメタデータプールを監視し、領域が不足しないようにします。 - chunksize
- シンプールの作成時に指定する重要なパラメーターはチャンクサイズです。これは、割り当て単位です。優れたパフォーマンスを得るには、シンプールのチャンクサイズと、ベースとなるハードウェア RAID ストレージのパラメーターを選択し、連携するようにする必要があります。JBOD には、シンプールチャンクサイズ 256 KiB を使用します。RAID 6 ストレージでは、ストライプサイズ (stripe_unit サイズ * データディスク数 * データディスク数) が 1 MiB から 2 MiB までの値になるよう、ストライピングパラメーターを選択する必要があります。RAID 6 の完全なストライプサイズと一致するように、シンプールチャンクサイズを選択する必要があります。チャンクサイズを完全なストライプサイズに一致させると、シンプールの割り当てが RAID 6 のストライプと調整されるため、パフォーマンスが向上します。チャンクサイズを 2 MiB 未満に制限すると、スナップショットが使用される場合に過剰なコピーオン書き込みが行われるため、パフォーマンスの問題が発生する可能性が低減します。たとえば、ディスクが 12 個 (10 データディスク) ある RAID 6 の場合は、ストライプユニットサイズを 128 KiB として選択する必要があります。これにより、1280 KiB (1.25 MiB) のストライプサイズになります。次に、シンプールは、チャンクサイズ 1280 KiB で作成する必要があります。RAID 10 ストレージでは、推奨されるストライプユニットサイズは 256 KiB です。これは、シンプールのチャンクサイズとしても機能します。ワークロードでファイル書き込みまたは無作為な書き込みが使用される場合は、RAID 10 が推奨されます。この場合、スナップショットでコピーオンライトのオーバーヘッドを減らすため、シンプールのチャンクサイズはより適しています。デバイスのアドレス可能なストレージがデバイス自体よりも小さい場合は、推奨されるチャンクサイズを調整する必要があります。次の式を使用して調整係数を計算します。
adjustment_factor = device_size_in_tb / (preferred_chunk_size_in_kb * 4 / 64 )
調整係数を丸めます。次に、以下のコマンドを使用して新しいチャンクサイズを計算します。chunk_size = preferred_chunk_size * rounded_adjustment_factor
- ブロックのゼロ設定
- デフォルトでは、異なるブロックデバイス間のデータ漏えいを防ぐために、シンプールで新たにプロビジョニングされたチャンクはゼロになります。ファイルシステムでデータにアクセスしている Red Hat Gluster Storage の場合、
--zero n
オプションでパフォーマンスを向上させるために、このオプションをオフにすることができます。n
を置き換える必要がないことに注意してください。以下の例は、シンプールを作成する方法を示しています。# lvcreate --thin VOLGROUP/thin_pool --size 2T --chunksize 1280k --poolmetadatasize 16G --zero n
--extents 100%FREE
を使用して、メタデータプールの作成後にシンプールが利用可能な領域をすべて取得するようにすることもできます。# lvcreate --thin VOLGROUP/thin_pool --extents 100%FREE --chunksize 1280k --poolmetadatasize 16G --zero n
以下の例は、2 TB シンプールを作成する方法を示しています。# lvcreate --thin VOLGROUP/thin_pool --size 2T --chunksize 1280k --poolmetadatasize 16G --zero n
以下の例では、メタデータプールの作成後に残りの領域をすべて使用するシンプールを作成します。# lvcreate --thin VOLGROUP/thin_pool --extents 100%FREE --chunksize 1280k --poolmetadatasize 16G --zero n
- シン論理ボリュームの作成上記のようにシンプールを作成したら、シンプールにシンプロビジョニングされた論理ボリュームを作成し、Red Hat Gluster Storage ボリュームのブリック用のストレージとして機能します。
# lvcreate --thin --name LV_name --virtualsize LV_size VOLGROUP/thin_pool
- 例: 物理デバイスに複数のブリックを作成する上記のステップ (LVM レイヤー) は、物理デバイスに単一のブリックが作成されるケースを説明します。この例は、物理デバイスに複数のブリックを作成する必要がある場合に、この手順を調整する方法を示しています。注記以下の手順で、以下を前提としています。
- 同じ物理デバイスに 2 つのブリックを作成する必要があります。
- 1 つのブリックのサイズは 4 TiB で、もう 1 つは 2 TiB です。
- デバイスは
/dev/sdb
で、12 ディスクを持つ RAID-6 デバイスです。 - 12 ディスクの RAID-6 デバイスが、本章の推奨事項に従って作成されました。つまり、ストライプユニットサイズが 128 KiB になります。
- pvcreate を使用した 1 つの物理ボリュームの作成
# pvcreate --dataalignment 1280k /dev/sdb
- デバイスに 1 つのボリュームグループを作成します。
# vgcreate --physicalextentsize 1280k vg1 /dev/sdb
- 以下のコマンドを使用して、ブリックごとに個別のシンプールを作成します。
# lvcreate --thin vg1/thin_pool_1 --size 4T --chunksize 1280K --poolmetadatasize 16G --zero n
# lvcreate --thin vg1/thin_pool_2 --size 2T --chunksize 1280K --poolmetadatasize 16G --zero n
上記の例では、各シンプールのサイズは、そのサイズで作成されたブリックのサイズと同じになるよう選択されます。シンプロビジョニングでは、スペースを管理する方法が多数あり、本章ではこれらのオプションについては説明していません。 - 各ブリック用にシン論理ボリュームを作成する
# lvcreate --thin --name lv1 --virtualsize 4T vg1/thin_pool_1
# lvcreate --thin --name lv2 --virtualsize 2T vg1/thin_pool_2
- 本章の 『XFS Recommendations』 (次のステップ) に従って、各シン論理ボリュームにファイルシステムを作成してマウントします。
# mkfs.xfs options /dev/vg1/lv1
# mkfs.xfs options /dev/vg1/lv2
# mount options /dev/vg1/lv1 mount_point_1
# mount options /dev/vg1/lv2 mount_point_2
XFS の推奨事項
- XFS Inode サイズRed Hat Gluster Storage は拡張属性を多用するので、512 バイトの XFS inode サイズは、デフォルトの XFS inode サイズ 256 バイトよりも適切に機能します。したがって、Red Hat Gluster Storage ブリックをフォーマットする際に、XFS の inode サイズは 512 バイトに設定する必要があります。inode サイズを設定するには、以下の 『Logical Block Size for the Directory』 ディレクトリーの論理ブロックサイズセクションに示されるように、mkfs.xfs コマンドで -i size オプションを使用する必要があ ます。
- XFS RAID アライメントXFS ファイルシステムを作成する場合は、以下の形式で、基礎となるストレージのストライピングパラメーターを明示的に指定できます。
# mkfs.xfs other_options -d su=stripe_unit_size,sw=stripe_width_in_number_of_disks device
RAID 6 の場合は、ストライピングパラメーターを指定して、I/O がファイルシステムレイヤーに置かれていることを確認します。ディスクが 12 個ある RAID 6 ストレージの場合は、上記の推奨事項に従う必要があります。# mkfs.xfs other_options -d su=128k,sw=10 device
RAID 10 および JBOD の場合、-d su=<>,sw=<>
オプションは省略できます。デフォルトでは、XFS はシン p チャンクサイズおよびその他のパラメーターを使用してレイアウトの決定を行います。 - ディレクトリーの論理ブロックサイズXFS ファイルシステムでは、ファイルシステムの論理ブロックサイズよりも大きいファイルシステムのディレクトリーの論理ブロックサイズを選択できます。デフォルトの 4 K からディレクトリーの論理ブロックサイズを増やすと、ディレクトリー I/O が減少し、ディレクトリー操作のパフォーマンスが改善されます。ブロックサイズを設定するには、以下の出力例のように、
-n size
コマンドで mkfs.xfs オプションを使用する必要があります。以下は、inode およびブロックサイズのオプションに加えて、RAID 6 設定の出力例です。# mkfs.xfs -f -i size=512 -n size=8192 -d su=128k,sw=10 logical volume meta-data=/dev/mapper/gluster-brick1 isize=512 agcount=32, agsize=37748736 blks = sectsz=512 attr=2, projid32bit=0 data = bsize=4096 blocks=1207959552, imaxpct=5 = sunit=32 swidth=320 blks naming = version 2 bsize=8192 ascii-ci=0 log =internal log bsize=4096 blocks=521728, version=2 = sectsz=512 sunit=32 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0
- 割り当てストラテジーinode32 および inode64 は、XFS の一般的な割り当てストラテジーです。inode32 割り当てストラテジーを使用すると、XFS はすべての inode をディスクの最初の 1 TiB に配置します。ディスクが大きい場合、すべての inode は最初の 1 TiB で停止します。inode32 の割り当てストラテジーはデフォルトで使用されます。inode64 マウントオプションでは、inode は、ディスクシークを最小限に抑えるデータ付近に置き換わります。ファイルシステムのマウント時に割り当てストラテジーを inode64 に設定するには、以下の Access Time セクションに示されるように、mount コマンドで
-o inode64
オプションを使用する必要があります。 - Access Timeアプリケーションがファイルのアクセス時間を更新する必要がない場合は、ファイルシステムを常に
noatime
マウントオプションでマウントする必要があります。以下に例を示します。# mount -t xfs -o inode64,noatime <logical volume> <mount point>
この最適化により、ファイルの読み取り時に XFS inode の更新を避けることで、小規模ファイルの読み取りパフォーマンスが向上します。/etc/fstab entry for option E + F <logical volume> <mount point>xfs inode64,noatime 0 0
- 割り当てグループ各 XFS ファイルシステムは、割り当てグループと呼ばれるリージョンに分割されます。割り当てグループは ext3 のブロックグループと似ていますが、割り当てグループはブロックグループよりもはるかに大きく、ディスク局所性ではなくスケーラビリティーと並列処理に使用されます。割り当てグループのデフォルト割り当ては 1 TiB です。割り当てグループ数は、同時割り当てワークロードを維持するために十分な大きさである必要があります。mkfs.xfs コマンドで選択したケース割り当てグループの数のほとんどは、最適なパフォーマンスを提供します。ファイルシステムのフォーマット時に
mkfs.xfs
で選択した割り当てグループ数を変更しないでください。 - inode への領域割り当てのパーセンテージワークロードが非常に小さいファイル(ファイルサイズが 10 KB 未満)である場合は、ファイルシステムのフォーマット時に
maxpct
の値を10
に設定することが推奨されます。また、arbiter ブリックに必要な場合は maxpct 値を 100 に設定できます。
Red Hat Gluster Storage のパフォーマンスチューニングオプション
tuned プロファイルは、システムパラメーターを適切に調整することで、特定のユースケースのパフォーマンスを改善するために設計されています。Red Hat Gluster Storage には、ワークロードに適した tuned プロファイルが含まれています。これらのプロファイルは、Red Hat Enterprise Linux 6 および Red Hat Enterprise Linux 7 で利用できます。表19.1 異なるワークロードで推奨されるプロファイル
ワークロード プロファイル名 大規模なファイル、順次 I/O ワークロード rhgs-sequential-io
小さなファイルワークロード rhgs-random-io
ランダム I/O ワークロード rhgs-random-io
以前のバージョンの Red Hat Gluster Storage は、推奨される Red Hat Enterprise Linux 6 の tuned プロファイルrhs-high-throughput
およびrhs-virtualization
でした。これらのプロファイルは、引き続き 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 ソフトウェアコンポーネントおよびバージョン』 を参照してください。tuned プロファイルに含まれるチューニングを適用するには、Red Hat Gluster Storage ボリュームの作成後に以下のコマンドを実行します。# tuned-adm profile profile-name
以下に例を示します。# tuned-adm profile rhgs-sequential-io
ライトバックキャッシング
小規模なファイルおよび無作為な書き込みパフォーマンスについては、ストレージコントローラー内の不揮発性乱数アクセスメモリー (NVRAM) のライトバックキャッシュを強く推奨します。たとえば、通常の Dell および HP ストレージコントローラーにはこれがあります。NVRAM が有効になっていることを確認します。つまり、バッテリーが機能していることを確認します。NVRAM の有効化に関する詳細は、ハードウェアのドキュメントを参照してください。ディスクドライブでライトバックキャッシュを有効にしないでください。これは、書き込みが実際に書き込みを行う前に、ディスクドライブが書き込みが完了したと判断するポリシーです。その結果、電源障害時やメタデータの失われた際に、ディスクの書き込みキャッシュがそのデータが失われると、ファイルシステムの破損につながる可能性があります。
19.2.1. ノードごとに多数のブログ
ブログ多重化の設定
cluster.brick-multiplex
をon
に設定します。このオプションは、すべてのボリュームに影響します。# gluster volume set all cluster.brick-multiplex on
- ブリックマルチプレッシングを有効にするためにすべてのボリュームを再起動します。
# gluster volume stop VOLNAME # gluster volume start VOLNAME
19.2.2. ポート範囲の設定
glusterd.vol
ファイルを使用すると実現できます。base-port
および max-port
オプションは、ポート範囲を設定するために使用できます。デフォルトでは、base-port
は 49152 に設定され、max-port
は 60999 に設定されます。
base-port
および max-port
の範囲内で割り当てる空きポートで不足すると、新しいブリックおよびボリュームは起動に失敗します。
ポート範囲の設定
- すべてのノードで
glusterd.vol
ファイルを編集します。# vi /etc/glusterfs/glusterd.vol
#
およびbase-port
オプションに対応するコメントマーカーmax-port
を削除します。volume management type mgmt/glusterd option working-directory /var/lib/glusterd option transport-type socket,rdma option transport.socket.keepalive-time 10 option transport.socket.keepalive-interval 2 option transport.socket.read-fail-log off option ping-timeout 0 option event-threads 1 # option lock-timer 180 # option transport.address-family inet6 option base-port 49152 option max-port 60999 end-volume
base-port
およびmax-port
オプションでポート番号を定義します。option base-port 49152 option max-port 60999
glusterd.vol
ファイルを保存して、各 Red Hat Gluster Storage ノードでglusterd
サービスを再起動します。
19.3. ネットワーク
19.4. メモリー
19.4.1. 仮想メモリーのパラメーター
- vm.dirty_ratio
- vm.dirty_background_ratio
- ファイルが連続してある I/O ワークロードは、これらのパラメーターの値が高いという利点があります。
- 小さなファイルおよび無作為な I/O ワークロードの場合は、これらのパラメーター値を低く維持することを推奨します。
19.5. 小さなファイルパフォーマンスの機能拡張
Metadata-intensive workload
は、このようなワークロードを識別するために使用される用語です。ネットワークおよびストレージのパフォーマンスを最適化するために、いくつかのパフォーマンスが強化され、Red Hat Gluster Storage の信頼されるストレージプールの小さなファイルに対するスループットおよび応答時間の影響を最小限に抑えることができます。
rhgs-random-io
調整済みプロファイルをアクティベートします。
イベント処理のスレッドの設定
クライアントおよびサーバーコンポーネントの client.event-thread
および server.event-thread
の値を設定できます。たとえば、値を 4 に設定すると、4 つのネットワーク接続を同時に処理できます。
# gluster volume set VOLNAME client.event-threads <value>
例19.1 ボリュームにアクセスするクライアントのイベントスレッドの調整
# gluster volume set test-vol client.event-threads 4
# gluster volume set VOLNAME server.event-threads <value>
例19.2 ボリュームにアクセスするサーバーのイベントスレッドの調整
# gluster volume set test-vol server.event-threads 4
# gluster volume info VOLNAME
イベントスレッドを調整するためのベストプラクティス
ネットワーク接続からスレッド処理イベントの数を調整することで、Red Hat Gluster Storage スタックでパフォーマンスが低下することが確認できます。以下は、イベントスレッド値を調整するための推奨されるベストプラクティスです。
- 各スレッドは一度に接続を処理するため、ブリックプロセス (
glusterfsd
) またはクライアントプロセス(glusterfs
またはgfapi
)への接続よりもスレッドは推奨されていません。このため、クライアント上の接続数 (netstat コマンドを使用) を監視し、ブリックでイベントスレッド数に適した数になるように監視します。 - 利用可能な処理ユニットよりもイベントスレッド値が大きいと、これらのスレッドでコンテキストが再び切り替わることがあります。その結果、前の手順で重複排除した数を、利用可能な処理ユニットが推奨する数よりも小さい数値に減らすことができます。
- Red Hat Gluster Storage ボリュームに単一ノード上で実行中のブリックプロセスが多数ある場合は、前のステップで非推奨となったイベントスレッド番号を減らすことで、競合プロセスが十分な同時実行性を実現し、スレッド全体にわたるコンテキストスイッチを回避するのに役立ちます。
- 特定のスレッドが必要以上の CPU サイクルを消費すると、イベントスレッド数を増やすと、Red Hat Gluster Storage Server のパフォーマンスが向上します。
- 適切なイベントスレッド数を停止することに加え、ストレージノードの
server.outstanding-rpc-limit
を増やすと、ブリックプロセスの要求をキューに入れ、ネットワークキューで要求をアイドリングしないようにすることもできます。 - event-threads 値を調整する際にパフォーマンスを向上させる可能性がある別のパラメーターは、
performance.io-thread-count
(および関連するスレッドスレッド) を基礎となるファイルシステムで実際の IO 操作を実行するため、値を高く設定します。
19.5.1. 最適化機能の有効化
cluster.lookup-optimize
設定オプションは、DHT ルックアップの最適化を有効にします。このオプションを有効にするには、以下のコマンドを実行します。
# gluster volume set VOLNAME cluster.lookup-optimize <on/off>\
19.6. レプリケーション
19.7. ディレクトリー操作
- ディレクトリーの一覧表示 (再帰)
- ファイルの作成
- ファイルの削除
- ファイルの名前変更
19.7.1. メタデータキャッシングの有効化
- 以下のコマンドを実行し、メタデータのキャッシュおよびキャッシュの無効化を有効にします。
# gluster volume set <volname> group metadata-cache
これは group set オプションで、1 つのコマンドに複数のボリュームオプションを設定します。 - キャッシュ可能なファイル数を増やすには、以下のコマンドを実行します。
# gluster volume set <VOLNAME> network.inode-lru-limit <n>
N は 50000 に設定されます。ボリューム内のアクティブなファイルの数が非常に高い場合は、増やすことができます。この数字を増やすと、ブリックプロセスのメモリーフットプリントが増加します。
19.8. Red Hat Gluster Storage の LVM キャッシュ
19.8.1. LVM キャッシュの概要
19.8.1.1. LVM キャッシュ vs。DM キャッシュ
dm-cache
は、すべての I/O トランザクションに対応する Linux カーネルレベルの device-mapper サブシステムを参照します。ほとんどの操作では、デバイスマッパーの上によりシンプルな抽象化層として論理ボリュームマネージャー(LVM)を使用する管理インターフェースを使用します。したがって、lvmcache
は、dm-cache
サブシステムの抽象化レイヤーとして機能する LVM システムの一部になります。
19.8.1.2. LVM キャッシュ vs。Gluster 階層型ボリューム
19.8.1.3. Arbiter ブリック
19.8.1.4. ライトスルー vsライトバック
19.8.1.5. キャッシュフレンドリーワークロード
19.8.2. キャッシュデバイスのサイズと速度の選択
19.8.3. LVM キャッシュの設定
/dev/nvme0n1
などのデバイスファイルパスで提示されます。SATA/SAS デバイスは、/dev/sdb
などのデバイスパスを持ちます。以下の命名例を使用しています。
- 物理ボリューム (PV) 名:
/dev/nvme0n1
- ボリュームグループ (VG) 名:
GVG
- シンプール名:
GTP
- 論理ボリューム (LV) 名:
GLV
lvmcache(7)
を参照してください。
- 高速データデバイスの PV を作成します。
# pvcreate /dev/nvme0n1
- キャッシュする LV をホストする VG に高速データ PV を追加します。
# vgextend GVG /dev/nvme0n1
- 高速データデバイスからキャッシュプールを作成し、論理ボリュームのキャッシュ変換プロセス時にメタデータに必要な領域を予約します。
# lvcreate --type cache-pool -l 100%FREE -n cpool GVG /dev/nvme0n1
- 既存のデータシンプール LV をキャッシュ LV に変換します。
# lvconvert --type cache --cachepool GVG/cpool GVG/GTP
19.8.4. LVM キャッシュの管理
19.8.4.1. 既存のキャッシュプールモードの変更
# lvchange --cachemode writeback GVG/GTP_tdata
19.8.4.2. 設定の確認
# lsblk /dev/{sdb,nvme0n1} NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 9.1T 0 disk └─GVG-GTP_tdata_corig 253:9 0 9.1T 0 lvm └─GVG-GTP_tdata 253:3 0 9.1T 0 lvm └─GVG-GTP-tpool 253:4 0 9.1T 0 lvm ├─GVG-GTP 253:5 0 9.1T 0 lvm └─GVG-GLV 253:6 0 9.1T 0 lvm /mnt nvme0n1 259:0 0 745.2G 0 disk ├─GVG-GTP_tmeta 253:2 0 76M 0 lvm │ └─GVG-GTP-tpool 253:4 0 9.1T 0 lvm │ ├─GVG-GTP 253:5 0 9.1T 0 lvm │ └─GVG-GLV 253:6 0 9.1T 0 lvm /mnt ├─GVG-cpool_cdata 253:7 0 701.1G 0 lvm │ └─GVG-GTP_tdata 253:3 0 9.1T 0 lvm │ └─GVG-GTP-tpool 253:4 0 9.1T 0 lvm │ ├─GVG-GTP 253:5 0 9.1T 0 lvm │ └─GVG-GLV 253:6 0 9.1T 0 lvm /mnt ├─GVG-cpool_cmeta 253:8 0 48M 0 lvm │ └─GVG-GTP_tdata 253:3 0 9.1T 0 lvm │ └─GVG-GTP-tpool 253:4 0 9.1T 0 lvm │ ├─GVG-GTP 253:5 0 9.1T 0 lvm │ └─GVG-GLV 253:6 0 9.1T 0 lvm /mnt └─GVG-GTP_tdata_corig 253:9 0 9.1T 0 lvm └─GVG-GTP_tdata 253:3 0 9.1T 0 lvm └─GVG-GTP-tpool 253:4 0 9.1T 0 lvm ├─GVG-GTP 253:5 0 9.1T 0 lvm └─GVG-GLV 253:6 0 9.1T 0 lvm /mnt
lvs(8)
を参照してください。
# lvs -a -o name,vg_name,size,pool_lv,devices,cachemode,chunksize LV VG LSize Pool Devices CacheMode Chunk GLV GVG 9.10t GTP 0 GTP GVG <9.12t GTP_tdata(0) 8.00m [GTP_tdata] GVG <9.12t [cpool] GTP_tdata_corig(0) writethrough 736.00k [GTP_tdata_corig] GVG <9.12t /dev/sdb(0) 0 [GTP_tdata_corig] GVG <9.12t /dev/nvme0n1(185076) 0 [GTP_tmeta] GVG 76.00m /dev/nvme0n1(185057) 0 [cpool] GVG <701.10g cpool_cdata(0) writethrough 736.00k [cpool_cdata] GVG <701.10g /dev/nvme0n1(24) 0 [cpool_cmeta] GVG 48.00m /dev/nvme0n1(12) 0 [lvol0_pmspare] GVG 76.00m /dev/nvme0n1(0) 0 [lvol0_pmspare] GVG 76.00m /dev/nvme0n1(185050) 0 root vg_root 50.00g /dev/sda3(4095) 0 swap vg_root <16.00g /dev/sda3(0) 0
- CacheTotalBlocks
- CacheUsedBlocks
- CacheDirtyBlocks
- CacheReadHits
- CacheReadMisses
- CacheWriteHits
- CacheWriteMisses
# lvs -a -o devices,cachetotalblocks,cacheusedblocks, \ cachereadhits,cachereadmisses | egrep 'Devices|cdata' Devices CacheTotalBlocks CacheUsedBlocks CacheReadHits CacheReadMisses cpool_cdata(0) 998850 2581 1 192
19.8.4.3. キャッシュプールのデタッチ
# lvconvert --splitcache GVG/cpool
パート VI. セキュリティー
第20章 Red Hat Gluster Storage でのネットワーク暗号化の設定
- I/O 暗号化
- Red Hat Gluster Storage クライアントとサーバーとの間の I/O 接続の暗号化。
- 管理暗号化
- 信頼できるストレージプール内の管理 (
glusterd
) 接続の暗号化、およびglusterd
と NFS Ganesha または SMB クライアント間の暗号化。
/etc/ssl/glusterfs.pem
- システムの一意に署名された TLS 証明書が含まれる証明書ファイル。このファイルはシステムごとに一意で、他のシステムと共有しないでください。
/etc/ssl/glusterfs.key
- このファイルには、システムの固有の秘密鍵が含まれます。このファイルは、他のユーザーと共有しないでください。
/etc/ssl/glusterfs.ca
- このファイルには、証明書に署名した認証局 (CA) の証明書が含まれます。
glusterf.ca
ファイルは、信頼できるプール内のすべてのサーバーで同一でなければならないので、すべてのサーバーおよびクライアントの署名 CA の証明書が含まれている必要があります。すべてのクライアントには、すべてのサーバーの署名 CA の証明書が含まれる.ca
ファイルも必要です。Red Hat Gluster Storage は、システムと共に提供されるグローバル CA 証明書を使用しないので、独自の自己署名証明書を作成するか、証明書を作成して認証局が署名する必要があります。自己署名証明書を使用している場合、サーバーの CA ファイルは、すべてのサーバーとすべてのクライアントに関連する.pem
ファイルを連結したものです。クライアント CA ファイルは、全サーバーの証明書ファイルを連結したものです。 /var/lib/glusterd/secure-access
- このファイルは、管理暗号化に必要です。これにより、全サーバーの
glusterd
とクライアント間の接続との間の管理 (glusterd
) 接続の暗号化が有効になり、認証局が必要とする設定はすべて含まれます。すべてのサーバーのglusterd
サービスは、このファイルを使用して volfiles を取得し、クライアントに volfile 変更を通知します。このファイルは、全サーバーに存在し、管理暗号化が適切に機能するにはすべてのクライアントに存在する必要があります。これは空にすることができますが、ほとんどの設定には、認証局で必要な証明書の深さ (transport.socket.ssl-cert-depth
) を設定するには少なくとも 1 行必要です。
20.1. 証明書の準備
- 自己署名証明書
- 証明書の生成と署名
- 認証局 (CA) 署名付き証明書
- 証明書を生成し、その証明書に署名するようにリクエストします。
手順20.1 自己署名証明書の準備
各サーバーとクライアントの証明書の生成および署名
各サーバーおよびクライアントで以下の手順を実行します。このマシンの秘密鍵を生成する
# openssl genrsa -out /etc/ssl/glusterfs.key 2048
このマシンの自己署名証明書の生成
以下のコマンドは、デフォルトの 30 日ではなく、365 日で有効期限が切れる署名済み証明書を生成します。COMMONNAME の代わりにこのマシンの短縮名を指定します。これは通常、ホスト名、FQDN、または IP アドレスです。# openssl req -new -x509 -key /etc/ssl/glusterfs.key -subj "/CN=COMMONNAME" -days 365 -out /etc/ssl/glusterfs.pem
クライアント側の認証局一覧の生成
最初のサーバーから、すべてのサーバーの/etc/ssl/glusterfs.pem
ファイルをglusterfs.ca
という単一のファイルに連結し、このファイルをすべてのクライアントの/etc/ssl
ディレクトリーに置きます。たとえば、server1
から以下のコマンドを実行すると、2 つのサーバーの証明書 (.ca
ファイル) が含まれる認証局一覧 (.pem
ファイル) が作成され、認証局リスト (.ca
ファイル) を 3 つのクライアントにコピーします。# cat /etc/ssl/glusterfs.pem > /etc/ssl/glusterfs.ca # ssh user@server2 cat /etc/ssl/glusterfs.pem >> /etc/ssl/glusterfs.ca # scp /etc/ssl/glusterfs.ca client1:/etc/ssl/glusterfs.ca # scp /etc/ssl/glusterfs.ca client2:/etc/ssl/glusterfs.ca # scp /etc/ssl/glusterfs.ca client3:/etc/ssl/glusterfs.ca
サーバー側の
glusterfs.ca
ファイルの生成最初のサーバーから、すべてのクライアントからの証明書 (/etc/ssl/glusterfs.pem
ファイル) を直前の手順で生成した認証局一覧 (/etc/ssl/glusterfs.ca
ファイル) の最後に追加します。たとえば、server1
で以下のコマンドを実行し、3 つのクライアントの証明書 (.pem
ファイル) をserver1
の認証局リスト (.ca
ファイル) に追加してから、その認証局リスト (.ca
ファイル) を他のサーバーにコピーします。# ssh user@client1 cat /etc/ssl/glusterfs.pem >> /etc/ssl/glusterfs.ca # ssh user@client2 cat /etc/ssl/glusterfs.pem >> /etc/ssl/glusterfs.ca # ssh user@client3 cat /etc/ssl/glusterfs.pem >> /etc/ssl/glusterfs.ca # scp /etc/ssl/glusterfs.ca server2:/etc/ssl/glusterfs.ca
サーバー証明書の確認
サーバーの/etc/ssl
ディレクトリーで以下のコマンドを実行し、認証局の一覧に対してそのマシンの証明書を確認します。# openssl verify -verbose -CAfile glusterfs.ca glusterfs.pem
このコマンドの出力がglusterfs.pem: OK
の場合は、証明書が正しいこと。注記このプロセスは、自己署名のクライアント証明書には有効ではありません。
手順20.2 一般的な認証局証明書の準備
秘密鍵の生成
# openssl genrsa -out /etc/ssl/glusterfs.key 2048
証明書の署名リクエストを生成します。
以下のコマンドは、デフォルトの 30 日ではなく、365 日で期限切れになる証明書の証明書署名要求を生成します。COMMONNAME の代わりにこのマシンの短縮名を指定します。これは通常、ホスト名、FQDN、または IP アドレスです。# openssl req -new -sha256 -key /etc/ssl/glusterfs.key -subj '/CN=<COMMONNAME>' -days 365 -out glusterfs.csr
生成された glusterfs.csr ファイルを認証局に送信します。
認証局は、このマシンの署名済み証明書を a.pem
ファイル形式で、および a.ca
ファイル形式で認証局の証明書を提供します。認証局が提供する
.pem
ファイルを配置する。.pem
ファイルがglusterfs.pem
と呼ばれていることを確認します。このサーバーの/etc/ssl
ディレクトリーにこのファイルを置きます。認証局が提供する
.ca
ファイルを配置する.ca
ファイルがglusterfs.ca
という名前であることを確認します。すべてのサーバーの/etc/ssl
ディレクトリーに.ca
ファイルを配置します。証明書の確認
すべてのクライアントおよびサーバーの/etc/ssl
ディレクトリーで以下のコマンドを実行し、認証局の一覧に対してそのマシンの証明書を確認します。# openssl verify -verbose -CAfile glusterfs.ca glusterfs.pem
このコマンドの出力がglusterfs.pem: OK
の場合は、証明書が正しいこと。
20.2. 新しい信頼済みストレージプールのネットワーク暗号化の設定
20.2.1. 管理暗号化の有効化
手順20.3 サーバーでの管理暗号化の有効化
secure-access ファイルの作成および編集
新しい/var/lib/glusterd/secure-access
ファイルを作成します。デフォルト設定を使用している場合は、このファイルは空にすることができます。# touch /var/lib/glusterd/secure-access
認証局が正しく機能するには、SSL 証明書の深さ設定transport.socket.ssl-cert-depth
への変更が必要になる場合があります。この設定を編集するには、以下の行をsecure-access
ファイルに追加します。n は 認証局で必要な証明書深度に置き換えます。echo "option transport.socket.ssl-cert-depth n" > /var/lib/glusterd/secure-access
glusterd
の起動Red Hat Enterprise Linux 7 ベースのサーバーで、以下を実行します。# systemctl start glusterd
Red Hat Enterprise Linux 6 ベースのサーバーで、以下を実行します。# service glusterd start
重要Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。インストールガイドの『バージョンの詳細』表および『Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 を参照してください。ストレージ設定を継続します。
信頼できるストレージプールを設定し、ブリックをフォーマットし、ボリュームを作成してボリュームを作成し、通常の設定プロセスを実施します。詳しい情報は、4章信頼できるストレージプールへのサーバーの追加 および 5章ストレージボリュームの設定 を参照してください。
手順20.4 クライアントでの管理暗号化の有効化
前提条件
- このプロセスを実行する前に、信頼できるストレージプール、ブリック、およびボリュームを設定しておく必要があります。詳しい情報は、4章信頼できるストレージプールへのサーバーの追加 および 5章ストレージボリュームの設定 を参照してください。
secure-access ファイルの作成および編集
/var/lib/glusterd
ディレクトリーを作成し、新しい/var/lib/glusterd/secure-access
ファイルを作成します。デフォルト設定を使用している場合は、このファイルは空にすることができます。# touch /var/lib/glusterd/secure-access
認証局が正しく機能するには、SSL 証明書の深さ設定transport.socket.ssl-cert-depth
への変更が必要になる場合があります。この設定を編集するには、以下の行をsecure-access
ファイルに追加します。n は 認証局で必要な証明書深度に置き換えます。echo "option transport.socket.ssl-cert-depth n" > /var/lib/glusterd/secure-access
ボリュームの起動
サーバーで、ボリュームを起動します。# gluster volume start volname
ボリュームのマウント
ボリュームをマウントするプロセスは、クライアントが使用しているプロトコルによって異なります。次のコマンドは、ネイティブ FUSE プロトコルを使用して、testvol
という名前のボリュームをマウントします。# mount -t glusterfs server1:testvol /mnt/glusterfs
20.2.2. I/O 暗号化の有効化
手順20.5 I/O 暗号化の有効化
前提条件
- このプロセスを実行するには、ボリュームを設定していても起動していない。ボリュームの作成に関する詳細は、5章ストレージボリュームの設定 を参照してください。ボリュームを停止するには、以下のコマンドを実行します。
# gluster volume stop volname
許可するサーバーおよびクライアントを指定します
ボリュームにアクセスできるサーバーおよびクライアントの共通名の一覧を提供します。提供される共通名は、そのサーバーまたはクライアントのglusterfs.pem
ファイルの作成時に指定される共通名と同じである必要があります。# gluster volume set volname auth.ssl-allow 'server1,server2,client1,client2,client3'
これにより、キーをそのまま残す場合に追加のチェックが提供されますが、「クライアントの認証解除」 に示されているように、このリストからクライアントやサーバーを一時的に制限します。また、デフォルト値の*
も使用できます。これは、TLS 認証されたすべてのマシンがボリュームをマウントおよびアクセスできることを示します。ボリュームでの TLS/SSL の有効化
# gluster volume set volname client.ssl on # gluster volume set volname server.ssl on
ボリュームの起動
# gluster volume start volname
検証
ボリュームが承認済みのクライアントにマウントでき、権限のないクライアントがボリュームをマウントできないことを確認します。ボリュームをマウントするプロセスは、クライアントが使用しているプロトコルによって異なります。ボリュームをマウントするプロセスは、クライアントが使用しているプロトコルによって異なります。次のコマンドは、ネイティブ FUSE プロトコルを使用して、testvol
という名前のボリュームをマウントします。# mount -t glusterfs server1:testvol /mnt/glusterfs
20.3. 既存の信頼済みストレージプールのネットワーク暗号化の設定
20.3.1. I/O 暗号化の有効化
手順20.6 I/O 暗号化の有効化
すべてのクライアントからボリュームをアンマウントする
すべてのクライアントで以下のコマンドを実行して、ボリュームをアンマウントします。# umount mountpoint
ボリュームの停止
任意のサーバーから以下のコマンドを実行して、ボリュームを停止します。# gluster volume stop VOLNAME
許可するサーバーおよびクライアントを指定します
ボリュームにアクセスできるサーバーおよびクライアントの共通名の一覧を提供します。提供される共通名は、そのサーバーまたはクライアントのglusterfs.pem
ファイルの作成時に指定される共通名と同じである必要があります。# gluster volume set volname auth.ssl-allow 'server1,server2,client1,client2,client3'
これにより、キーをそのまま残す場合に追加のチェックが提供されますが、「クライアントの認証解除」 に示されているように、このリストからクライアントやサーバーを一時的に制限します。また、デフォルト値の*
も使用できます。これは、TLS 認証されたすべてのマシンがボリュームをマウントおよびアクセスできることを示します。ボリュームでの TLS/SSL 暗号化の有効化
任意のサーバーから以下のコマンドを実行し、TLS/SSL 暗号化を有効にします。# gluster volume set volname client.ssl on # gluster volume set volname server.ssl on
ボリュームの起動
# gluster volume start volname
検証
ボリュームが、承認されたクライアントにのみマウントできることを確認します。ボリュームをマウントするプロセスは、クライアントが使用しているプロトコルによって異なります。次のコマンドは、ネイティブ FUSE プロトコルを使用してボリュームをマウントします。このコマンドは、認証済みのクライアントで機能し、承認されていないクライアントでは機能しません。# mount -t glusterfs server1:/testvolume /mnt/glusterfs
20.4. 管理暗号化の有効化
前提条件
- 管理暗号化を有効にするには、ストレージサーバーがオフラインでなければなりません。このプロセスを開始する前に、ボリューム、アプリケーション、クライアント、およびその他のエンドユーザーに停止した期間をスケジュールします。スナップショットや地理レプリケーションなどの機能も、この障害の影響を受ける可能性があることに注意してください。
手順20.7 管理暗号化の有効化
暗号化を有効にする準備
すべてのクライアントからすべてのボリュームをアンマウントします。
そのクライアントにマウントされている各ボリュームについて、それぞれのクライアントで以下のコマンドを実行します。# umount mount-point
NFS Ganesha サービスまたは SMB サービスを停止します (使用している場合)。
任意の gluster サーバーで以下のコマンドを実行し、NFS-Ganesha を無効にします。# systemctl stop nfs-ganesha
任意の gluster サーバーで以下のコマンドを実行して、SMB を停止します。# systemctl stop ctdb
共有ストレージを使用している場合は、アンマウントします。
すべてのサーバーで以下のコマンドを実行し、共有ストレージをアンマウントします。# umount /var/run/gluster/shared_storage
注記3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。重要スナップショットや地理レプリケーションなどの共有ストレージを必要とする機能は、このプロセスが完了するまで機能しない場合があります。すべてのボリュームを停止
すべてのサーバーで以下のコマンドを実行し、共有ストレージボリュームを含む、すべてのボリュームを停止します。# for vol in `gluster volume list`; do gluster --mode=script volume stop $vol; sleep 2s; done
すべてのサーバーで gluster サービスを停止する
Red Hat Enterprise Linux 7 ベースのインストールの場合:# systemctl stop glusterd # pkill glusterfs
Red Hat Enterprise Linux 6 ベースのインストールの場合:# service glusterd stop # pkill glusterfs
重要Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。インストールガイドの『バージョンの詳細』表および『Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 を参照してください。
すべてのサーバーおよびクライアントに secure-access ファイルを作成して編集します。
新しい/var/lib/glusterd/secure-access
ファイルを作成します。デフォルト設定を使用している場合は、このファイルは空にすることができます。# touch /var/lib/glusterd/secure-access
認証局が正しく機能するには、SSL 証明書の深さ設定transport.socket.ssl-cert-depth
への変更が必要になる場合があります。この設定を編集するには、以下の行をsecure-access
ファイルに追加します。n は 認証局で必要な証明書深度に置き換えます。echo "option transport.socket.ssl-cert-depth n" > /var/lib/glusterd/secure-access
管理暗号化の設定後のクリーンアップ
すべてのサーバーで glusterd サービスを起動する
Red Hat Enterprise Linux 7 ベースのインストールの場合:# systemctl start glusterd
Red Hat Enterprise Linux 6 ベースのインストールの場合:# service glusterd start
重要Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。インストールガイドの『バージョンの詳細』表および『Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 を参照してください。すべてのボリュームを起動
任意のホストで以下のコマンドを実行し、共有ストレージを含むすべてのボリュームを起動します。# for vol in `gluster volume list`; do gluster --mode=script volume start $vol; sleep 2s; done
共有ストレージを使用している場合は、マウントします。
すべてのサーバーで以下のコマンドを実行して、共有ストレージをマウントします。# mount -t glusterfs hostname:/gluster_shared_storage /run/gluster/shared_storage
NFS Ganesha または SMB サービスを再起動します (使用している場合)。
任意の gluster サーバーで以下のコマンドを実行し、NFS-Ganesha を起動します。# systemctl start nfs-ganesha
任意の gluster サーバーで以下のコマンドを実行して SMB を起動します。# systemctl start ctdb
クライアントへのボリュームのマウント
ボリュームをマウントするプロセスは、クライアントが使用しているプロトコルによって異なります。次のコマンドは、ネイティブ FUSE プロトコルを使用してボリュームをマウントします。# mount -t glusterfs server1:/testvolume /mnt/glusterfs
20.5. ボリュームの拡張
20.5.1. 一般的な認証局が署名した証明書
前提条件
- このセクションの前に、「証明書の準備」 の手順を行ってください。
手順20.8 一般的な認証局署名証明書を使用するプールの拡張
一般的な認証局一覧をインポートします。
既存のサーバーから新しいサーバーの /etc/ssl/glusterfs.ca
ファイルを/etc/ssl
ディレクトリーにコピーします。管理暗号化の場合は、secure-access ファイルを作成および編集します。
新しい/var/lib/glusterd/secure-access
ファイルを作成します。デフォルト設定を使用している場合は、このファイルは空にすることができます。# touch /var/lib/glusterd/secure-access
認証局が正しく機能するには、SSL 証明書の深さ設定transport.socket.ssl-cert-depth
への変更が必要になる場合があります。この設定を編集するには、以下の行をsecure-access
ファイルに追加します。n は 認証局で必要な証明書深度に置き換えます。echo "option transport.socket.ssl-cert-depth n" > /var/lib/glusterd/secure-access
新しいサーバーで glusterd を開始
# systemctl start glusterd
許可するサーバーおよびクライアントを指定します
ボリュームにアクセスできるサーバーおよびクライアントの共通名の一覧を提供します。提供される共通名は、そのサーバーまたはクライアントのglusterfs.pem
ファイルの作成時に指定される共通名と同じである必要があります。# gluster volume set volname auth.ssl-allow 'server1,server2,client1,client2,client3'
これにより、キーをそのまま残す場合に追加のチェックが提供されますが、「クライアントの認証解除」 に示されているように、このリストからクライアントやサーバーを一時的に制限します。注記gluster volume set コマンドは、オプションの既存の値に追加されません。一覧に新しい名前を追加するには、gluster volume info コマンドを使用して既存の一覧を取得し、新しい名前を一覧に追加し、gluster volume set コマンドを使用してオプションを再度設定します。また、デフォルト値の*
も使用できます。これは、TLS 認証されたすべてのマシンがボリュームをマウントおよびアクセスできることを示します。新規サーバーへのボリュームの拡張
新しく信頼できるサーバーを使用して、既存のボリュームを拡張するには、「ボリュームの拡張」 の手順に従います。
20.5.2. 自己署名証明書
前提条件
- このプロセスでは、自己署名証明書が自動的に生成されず更新されないため、信頼済みストレージプールはオフラインでなければなりません。このプロセスを開始する前に、ボリューム、アプリケーション、クライアント、およびその他のエンドユーザーに停止した期間をスケジュールします。
手順20.9 自己署名証明書を使用するプールの拡張
新しいサーバー用の鍵と自己署名証明書の生成
「証明書の準備」 の手順に従い、秘密鍵と新しいサーバーの自己署名証明書を生成します。サーバー認証局リストファイルの更新
新規サーバーの/etc/ssl/glusterfs.pem
ファイルの内容を、信頼済みストレージプール内のすべての既存サーバーの/etc/ssl/glusterfs.ca
ファイルに追加します。クライアント認証局リストファイルの更新
信頼されたストレージプール内の、承認済みのクライアントで、新しいサーバーの/etc/ssl/glusterfs.pem
ファイルの内容を/etc/ssl/glusterfs.ca
ファイルに追加します。すべての gluster プロセスを停止する
すべてのサーバーで次のコマンドを実行します。# systemctl stop glusterd # pkill glusterfs
(オプション) 新しいサーバーでの管理暗号化の有効化
/var/lib/glusterd/secure-access
ファイルを既存のサーバーから新しいサーバーにコピーします。新しいサーバーで glusterd を開始
# systemctl start glusterd
許可するようにサーバーおよびクライアントを更新します。
任意のサーバーから以下のコマンドを実行し、ボリュームにアクセスできるサーバーおよびクライアントの共通名を指定します。提供される共通名は、そのサーバーまたはクライアントのglusterfs.pem
ファイルの作成時に指定される共通名と同じである必要があります。# gluster volume set volname auth.ssl-allow 'server1,server2,client1,client2,client3'
注記gluster volume set コマンドは、オプションの既存の値に追加されません。一覧に新しい名前を追加するには、gluster volume info コマンドを使用して既存の一覧を取得し、新しい名前を一覧に追加し、gluster volume set コマンドを使用してオプションを再度設定します。また、デフォルト値の*
も使用できます。これは、TLS 認証されたすべてのマシンがボリュームをマウントおよびアクセスできることを示します。既存のサーバーおよびクライアントで glusterfs プロセスを再起動する
すべてのクライアントで、すべてのボリュームをアンマウントします。
# umount mountpoint
いずれかのサーバーで、すべてのボリュームを停止する
# for vol in `gluster volume list`; do gluster --mode=script volume stop $vol; sleep 2s; done
すべてのサーバーで、glusterd を再起動します。
Red Hat Enterprise Linux 7 ベースのインストールの場合:# systemctl start glusterd
Red Hat Enterprise Linux 6 ベースのインストールの場合:# service glusterd start
重要Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。インストールガイドの『バージョンの詳細』表および『Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 を参照してください。任意のサーバーで、すべてのボリュームを起動します。
# gluster volume start volname
すべてのクライアントにボリュームをマウントします。
ボリュームをマウントするプロセスは、クライアントが使用しているプロトコルによって異なります。次のコマンドは、ネイティブ FUSE プロトコルを使用してボリュームをマウントします。# mount -t glusterfs server1:/test-volume /mnt/glusterfs
新規サーバーへのボリュームの拡張
新しく信頼できるサーバーを使用して、既存のボリュームを拡張するには、「ボリュームの拡張」 の手順に従います。
20.6. 新規クライアントの承認
20.6.1. 一般的な認証局が署名する証明書
手順20.10 CA 署名の証明書を使用した新規クライアントの承認
クライアントのキーの生成
クライアントで以下のコマンドを実行します。# openssl genrsa -out /etc/ssl/glusterfs.key 2048
証明書の署名リクエストを生成します。
以下のコマンドは、デフォルトの 30 日ではなく、365 日で期限切れになる証明書の証明書署名要求を生成します。COMMONNAME の代わりにこのマシンの短縮名を指定します。これは通常、ホスト名、FQDN、または IP アドレスです。# openssl req -new -sha256 -key /etc/ssl/glusterfs.key -subj '/CN=<COMMONNAME>' -days 365 -out glusterfs.csr
生成された glusterfs.csr ファイルを認証局に送信します。
認証局は、.pem
ファイルの形式でこのマシンの署名済み証明書を提供し、.ca
ファイルの形式で認証局の一覧を提供します。クライアントに提供される証明書ファイルを追加します。
認証局が提供する.pem
ファイルを、クライアントの/etc/ssl
ディレクトリーに置きます。.pem
ファイルがglusterfs.pem
と呼ばれていることを確認します。クライアントへの認証局リストの追加
既存のクライアントから新しいクライアントに/etc/ssl/glusterfs.ca
ファイルをコピーします。# scp existingclient/etc/ssl/glusterfs.ca newclient:/etc/ssl/glusterfs.ca
証明書の確認
/etc/ssl
ディレクトリーで以下のコマンドを実行して、認証局の一覧に対してそのマシンの証明書を確認します。# openssl verify -verbose -CAfile glusterfs.ca glusterfs.pem
このコマンドの出力がglusterfs.pem: OK
の場合は、証明書が正しいこと。管理暗号化を設定している場合は、管理暗号化を設定します。
クライアントで/var/lib/glusterd
ディレクトリーを作成し、新しい/var/lib/glusterd/secure-access
ファイルを作成します。デフォルト設定を使用している場合は、このファイルは空にすることができます。# touch /var/lib/glusterd/secure-access
認証局が正しく機能するには、SSL 証明書の深さ設定transport.socket.ssl-cert-depth
への変更が必要になる場合があります。この設定を編集するには、以下の行をsecure-access
ファイルに追加します。n は 認証局で必要な証明書深度に置き換えます。echo "option transport.socket.ssl-cert-depth n" > /var/lib/glusterd/secure-access
許可するサーバーおよびクライアントの一覧を更新します。
任意のサーバーから以下のコマンドを実行し、ボリュームにアクセスできるサーバーおよびクライアントの共通名を指定します。提供される共通名は、そのサーバーまたはクライアントのglusterfs.pem
ファイルの作成時に指定される共通名と同じである必要があります。# gluster volume set volname auth.ssl-allow 'server1,server2,client1,client2,client3'
注記gluster volume set コマンドは、オプションの既存の値に追加されません。一覧に新しい名前を追加するには、gluster volume info コマンドを使用して既存の一覧を取得し、新しい名前を一覧に追加し、gluster volume set コマンドを使用してオプションを再度設定します。また、デフォルト値の*
も使用できます。これは、TLS 認証されたすべてのマシンがボリュームをマウントおよびアクセスできることを示します。ボリュームの起動
# gluster volume start volname
検証
ボリュームが新規クライアントからマウントできることを確認します。ボリュームをマウントするプロセスは、クライアントが使用しているプロトコルによって異なります。次のコマンドは、ネイティブ FUSE プロトコルを使用してボリュームをマウントします。このコマンドは、認証済みのクライアントで機能し、承認されていないクライアントでは機能しません。# mount -t glusterfs server1:testvolume /mnt/glusterfs
20.6.2. 自己署名証明書
前提条件
- このプロセスでは、自己署名証明書が自動的に生成されず更新されないため、信頼済みストレージプールはオフラインでなければなりません。このプロセスを開始する前に、ボリューム、アプリケーション、クライアント、およびその他のエンドユーザーに停止した期間をスケジュールします。
手順20.11 自己署名証明書を使用した新規クライアントの承認
クライアントのキーの生成
クライアントで以下のコマンドを実行します。# openssl genrsa -out /etc/ssl/glusterfs.key 2048
クライアント用の自己署名証明書の生成
以下のコマンドは、デフォルトの 30 日ではなく、365 日で有効期限が切れる署名済み証明書を生成します。COMMONNAME の代わりにこのマシンの短縮名を指定します。これは通常、ホスト名、FQDN、または IP アドレスです。# openssl req -new -x509 -key /etc/ssl/glusterfs.key -subj "/CN=COMMONNAME" -days 365 -out /etc/ssl/glusterfs.pem
クライアントへの認証局リストの追加
既存のクライアントから新しいクライアントに/etc/ssl/glusterfs.ca
ファイルをコピーします。新しいクライアントから以下のコマンドを実行します。# scp existingclient:/etc/ssl/glusterfs.ca /etc/ssl/glusterfs.ca
新規サーバーの
glusterfs.ca
ファイルの生成任意のサーバーで、新しいクライアントの/etc/ssl/glusterfs.pem
ファイルの値をサーバーの/etc/ssl/glusterfs.ca
ファイルの最後に追加します。更新された/etc/ssl/glusterfs.ca
ファイルを、信頼できるストレージプール内の全サーバーの/etc/ssl
ディレクトリーに置きます。たとえば、いずれかのサーバーで以下のコマンドを実行すると、新しいクライアントからglusterfs.ca
ファイルで.pem
ファイルを更新してから、そのglusterfs.ca
ファイルをすべてのサーバーにコピーします。# ssh user@newclient cat /etc/ssl/glusterfs.pem >> /etc/ssl/glusterfs.ca # scp /etc/ssl/glusterfs.ca server1:/etc/ssl/glusterfs.ca # scp /etc/ssl/glusterfs.ca server2:/etc/ssl/glusterfs.ca
新しいクライアント上で管理暗号化を設定します (使用している場合)。
クライアントで/var/lib/glusterd
ディレクトリーを作成し、新しい/var/lib/glusterd/secure-access
ファイルを作成します。デフォルト設定を使用している場合は、このファイルは空にすることができます。# touch /var/lib/glusterd/secure-access
認証局が正しく機能するには、SSL 証明書の深さ設定transport.socket.ssl-cert-depth
への変更が必要になる場合があります。この設定を編集するには、以下の行をsecure-access
ファイルに追加します。n は 認証局で必要な証明書深度に置き換えます。echo "option transport.socket.ssl-cert-depth n" > /var/lib/glusterd/secure-access
許可するサーバーおよびクライアントの一覧を更新します。
任意のサーバーから以下のコマンドを実行し、ボリュームにアクセスできるサーバーおよびクライアントの共通名を指定します。提供される共通名は、そのサーバーまたはクライアントのglusterfs.pem
ファイルの作成時に指定される共通名と同じである必要があります。# gluster volume set volname auth.ssl-allow 'server1,server2,client1,client2,client3'
注記gluster volume set コマンドは、オプションの既存の値に追加されません。一覧に新しい名前を追加するには、gluster volume info コマンドを使用して既存の一覧を取得し、新しい名前を一覧に追加し、gluster volume set コマンドを使用してオプションを再度設定します。また、デフォルト値の*
も使用できます。これは、TLS 認証されたすべてのマシンがボリュームをマウントおよびアクセスできることを示します。ボリュームの起動
任意のサーバーから以下のコマンドを実行してボリュームを起動します。# gluster volume start volname
管理暗号化を使用する場合は、すべてのサーバーで glusterd を再起動します。
Red Hat Enterprise Linux 7 ベースのインストールの場合:# systemctl start glusterd
Red Hat Enterprise Linux 6 ベースのインストールの場合:# service glusterd start
重要Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。インストールガイドの『バージョンの詳細』表および『Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 を参照してください。検証
ボリュームが新規クライアントからマウントできることを確認します。ボリュームをマウントするプロセスは、クライアントが使用しているプロトコルによって異なります。次のコマンドは、ネイティブ FUSE プロトコルを使用してボリュームをマウントします。このコマンドは、認証済みのクライアントで機能し、承認されていないクライアントでは機能しません。# mount -t glusterfs server1:testvolume /mnt/glusterfs
20.7. クライアントの認証解除
- 許可された一覧から、承認されたクライアントを削除します。
- 証明書失効リスト (CRL) による SSL/TLS 証明書認証の取り消し
20.7.1. 許可された一覧から承認されたクライアントを削除するには、以下を行います。
手順20.12 許可された一覧からの認可されたクライアントの削除
現在認可されているクライアントおよびサーバーの一覧を表示
$ gluster volume get VOLNAME auth.ssl-allow
たとえば、次のコマンドを実行すると、3 つの承認されたサーバーと 5 つの承認されたクライアントがあります。$ gluster volume get sample_volname auth.ssl-allow server1,server2,server3,client1,client2,client3,client4,client5
出力から承認を解除するクライアントを削除します
たとえば、client2 および client4 を承認する場合は、文字列をコピーして、一覧からそれらのクライアントを削除します。server1,server2,server3,client1,client3,client5
承認されたクライアントとサーバーの新しい一覧を設定
auth.ssl-allow
の値を更新された文字列に設定します。$ gluster volume set VOLNAME auth.ssl-allow <list_of_systems>
たとえば、更新されたリストは 3 つのサーバーと 3 つのクライアントを表示します。$ gluster volume set sample_volname auth.ssl-allow server1,server2,server3,client1,client3,client5
20.7.2. SSL 証明書失効リストを使用した SSL/TLS 証明書認証の取り消し
ssl.crl-path
オプションを使用して、SSL 証明書失効リスト (CRL) を含むディレクトリーへのパスを指定できます。取り消された証明書の一覧を含むパスにより、サーバーノードが取り消された証明書を持つノードを停止できます。
$ gluster volume set vm-images ssl.crl-path /etc/ssl/
- CRL ファイルをディレクトリーにコピーします。
- CRL ファイルを含むディレクトリーに移動します。
c_rehash
ユーティリティーを使用した CRL ファイルへのコンピュートハッシュ$ c_rehash .
ハッシュとシンボリックリンクは、openssl-perl
RPM で利用可能なc_rehash
ユーティリティーを使用して実行できます。シンボリックリンクの名前は Common Name のハッシュである必要があります。詳細は、man ページの crl を参照してください。ssl.crl-path
ボリュームオプションを設定します。$ gluster volume set VOLNAME ssl.crl-path path-to-directory
path-to-directory は CRL ファイルをホストするディレクトリーの絶対パスである必要があります。
20.8. ネットワーク暗号化の無効化
手順20.13 I/O 暗号化の無効化
すべてのクライアントからボリュームのアンマウント
暗号化を無効にしておく必要のあるボリュームごとに、それぞれのクライアントで以下のコマンドを実行します。# umount /mountpoint
暗号化されたボリュームを停止する
すべてのサーバーで以下のコマンドを実行し、暗号化を無効にしておくべきボリュームを停止します。# gluster volume stop volname
サーバーおよびクライアント SSL の使用状況の無効化
暗号化を無効にしておく必要のあるボリュームごとに、以下のコマンドを実行します。# gluster volume set volname server.ssl off # gluster volume set volname client.ssl off
ボリュームの起動
# gluster volume start volname
クライアントへのボリュームのマウント
ボリュームをマウントするプロセスは、クライアントが使用しているプロトコルによって異なります。次のコマンドは、ネイティブ FUSE プロトコルを使用してボリュームをマウントします。# mount -t glusterfs server1:/testvolume /mnt/glusterfs
手順20.14 管理暗号化の無効化
すべてのクライアントからボリュームのアンマウント
暗号化を無効にしておく必要のあるボリュームごとに、それぞれのクライアントで以下のコマンドを実行します。# umount /mountpoint
すべてのノードで glusterd を停止する
Red Hat Enterprise Linux 7 ベースのインストールの場合:# systemctl stop glusterd
Red Hat Enterprise Linux 6 ベースのインストールの場合:# service glusterd stop
重要Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。インストールガイドの『バージョンの詳細』表および『Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 を参照してください。secure-access ファイルを削除
すべてのサーバーおよびクライアントで以下のコマンドを実行し、secure-access ファイルを削除します。暗号化を一時的に無効にしているだけであれば、ファイル名の名前を変更することができます。# rm -f /var/lib/glusterd/secure-access
すべてのノードで glusterd を起動する
Red Hat Enterprise Linux 7 ベースのインストールの場合:# systemctl start glusterd
Red Hat Enterprise Linux 6 ベースのインストールの場合:# service glusterd start
重要Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。インストールガイドの『バージョンの詳細』表および『Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 を参照してください。クライアントへのボリュームのマウント
ボリュームをマウントするプロセスは、クライアントが使用しているプロトコルによって異なります。次のコマンドは、ネイティブ FUSE プロトコルを使用してボリュームをマウントします。# mount -t glusterfs server1:/testvolume /mnt/glusterfs
パート VII. トラブルシューティング
第21章 一般的な問題の解決
21.1. ロックされたファイルの特定とロックの消去
- ボリュームで statedump を実行し、以下のコマンドを使用してロックされたファイルを表示します。# gluster volume statedump VOLNAMEたとえば、test-volume の statedump を表示するには、以下を実行します。
# gluster volume statedump test-volume Volume statedump successful
statedump ファイルは、./tmp
ディレクトリー内のブリックサーバーまたは server.statedump-path ボリュームオプションを使用して設定したディレクトリーに作成されます。ダンプファイルの命名規則は、brick-path.brick-pid.dump
です。 - 以下のコマンドを使用して、エントリーロックを消去します。# gluster volume clear-locks VOLNAME path kind granted entry basename以下は、エントリーロック(エントリーポイント)を示す statedump ファイルの内容の例です。これらのロックが古いロックであることを確認し、リソースを所有するリソースがないことを確認してください。
[xlator.features.locks.vol-locks.inode] path=/ mandatory=0 entrylk-count=1 lock-dump.domain.domain=vol-replicate-0 xlator.feature.locks.lock-dump.domain.entrylk.entrylk[0](ACTIVE)=type=ENTRYLK_WRLCK on basename=file1, pid = 714782904, owner=ffffff2a3c7f0000, transport=0x20e0670, , granted at Mon Feb 27 16:01:01 2012 conn.2.bound_xl./rhgs/brick1.hashsize=14057 conn.2.bound_xl./rhgs/brick1.name=/gfs/brick1/inode conn.2.bound_xl./rhgs/brick1.lru_limit=16384 conn.2.bound_xl./rhgs/brick1.active_size=2 conn.2.bound_xl./rhgs/brick1.lru_size=0 conn.2.bound_xl./rhgs/brick1.purge_size=0
たとえば、test-volume のfile1
でエントリーロックを消去するには、次のコマンドを実行します。# gluster volume clear-locks test-volume / kind granted entry file1 Volume clear-locks successful test-volume-locks: entry blocked locks=0 granted locks=1
- 以下のコマンドを使用して、inode ロックを消去します。# gluster volume clear-locks VOLNAME path kind granted inode range以下は、inode ロックがあることを示す statedump ファイルの内容です(inodelk)。これらのロックが古いロックであることを確認し、リソースを所有するリソースがないことを確認してください。
[conn.2.bound_xl./rhgs/brick1.active.1] gfid=538a3d4a-01b0-4d03-9dc9-843cd8704d07 nlookup=1 ref=2 ia_type=1 [xlator.features.locks.vol-locks.inode] path=/file1 mandatory=0 inodelk-count=1 lock-dump.domain.domain=vol-replicate-0 inodelk.inodelk[0](ACTIVE)=type=WRITE, whence=0, start=0, len=0, pid = 714787072, owner=00ffff2a3c7f0000, transport=0x20e0670, , granted at Mon Feb 27 16:01:01 2012
たとえば、test-volume のfile1
で inode ロックを削除するには、次のコマンドを実行します。# gluster volume clear-locks test-volume /file1 kind granted inode 0,0-0 Volume clear-locks successful test-volume-locks: inode blocked locks=0 granted locks=1
- 以下のコマンドを使用して、付与された POSIX ロックを削除します。# gluster volume clear-locks VOLNAME path kind granted posix range以下は、POSIX ロックが付与されていることを示す statedump ファイルの内容を示しています。これらのロックが古いロックであることを確認し、リソースを所有するリソースがないことを確認してください。
xlator.features.locks.vol1-locks.inode] path=/file1 mandatory=0 posixlk-count=15 posixlk.posixlk[0](ACTIVE)=type=WRITE, whence=0, start=8, len=1, pid = 23848, owner=d824f04c60c3c73c, transport=0x120b370, , blocked at Mon Feb 27 16:01:01 2012 , granted at Mon Feb 27 16:01:01 2012 posixlk.posixlk[1](ACTIVE)=type=WRITE, whence=0, start=7, len=1, pid = 1, owner=30404152462d436c-69656e7431, transport=0x11eb4f0, , granted at Mon Feb 27 16:01:01 2012 posixlk.posixlk[2](BLOCKED)=type=WRITE, whence=0, start=8, len=1, pid = 1, owner=30404152462d436c-69656e7431, transport=0x11eb4f0, , blocked at Mon Feb 27 16:01:01 2012 posixlk.posixlk[3](ACTIVE)=type=WRITE, whence=0, start=6, len=1, pid = 12776, owner=a36bb0aea0258969, transport=0x120a4e0, , granted at Mon Feb 27 16:01:01 2012 ...
たとえば、test-volume のfile1
で付与された POSIX ロックを消去するには、次のコマンドを実行します。# gluster volume clear-locks test-volume /file1 kind granted posix 0,8-1 Volume clear-locks successful test-volume-locks: posix blocked locks=0 granted locks=1 test-volume-locks: posix blocked locks=0 granted locks=1 test-volume-locks: posix blocked locks=0 granted locks=1
- 以下のコマンドを使用して、ブロックされた POSIX ロックを削除します。# gluster volume clear-locks VOLNAME path kind blocked posix range以下は、ブロックされた POSIX ロックがあることを示す statedump ファイルの内容の例です。これらのロックが古いロックであることを確認し、リソースを所有するリソースがないことを確認してください。
[xlator.features.locks.vol1-locks.inode] path=/file1 mandatory=0 posixlk-count=30 posixlk.posixlk[0](ACTIVE)=type=WRITE, whence=0, start=0, len=1, pid = 23848, owner=d824f04c60c3c73c, transport=0x120b370, , blocked at Mon Feb 27 16:01:01 2012 , granted at Mon Feb 27 16:01:01 posixlk.posixlk[1](BLOCKED)=type=WRITE, whence=0, start=0, len=1, pid = 1, owner=30404146522d436c-69656e7432, transport=0x1206980, , blocked at Mon Feb 27 16:01:01 2012 posixlk.posixlk[2](BLOCKED)=type=WRITE, whence=0, start=0, len=1, pid = 1, owner=30404146522d436c-69656e7432, transport=0x1206980, , blocked at Mon Feb 27 16:01:01 2012 posixlk.posixlk[3](BLOCKED)=type=WRITE, whence=0, start=0, len=1, pid = 1, owner=30404146522d436c-69656e7432, transport=0x1206980, , blocked at Mon Feb 27 16:01:01 2012 posixlk.posixlk[4](BLOCKED)=type=WRITE, whence=0, start=0, len=1, pid = 1, owner=30404146522d436c-69656e7432, transport=0x1206980, , blocked at Mon Feb 27 16:01:01 2012 ...
たとえば、test-volume のfile1
でブロックされた POSIX ロックを削除するには、次のコマンドを実行します。# gluster volume clear-locks test-volume /file1 kind blocked posix 0,0-1 Volume clear-locks successful test-volume-locks: posix blocked locks=28 granted locks=0 test-volume-locks: posix blocked locks=1 granted locks=0 No locks cleared.
- 以下のコマンドを実行して、POSIX ロックをすべて消去します。# gluster volume clear-locks VOLNAME path kind all posix range以下は、POSIX ロックがあることを示す statedump ファイルのサンプルコンテンツです。これらのロックが古いロックであることを確認し、リソースを所有するリソースがないことを確認してください。
[xlator.features.locks.vol1-locks.inode] path=/file1 mandatory=0 posixlk-count=11 posixlk.posixlk[0](ACTIVE)=type=WRITE, whence=0, start=8, len=1, pid = 12776, owner=a36bb0aea0258969, transport=0x120a4e0, , blocked at Mon Feb 27 16:01:01 2012 , granted at Mon Feb 27 16:01:01 2012 posixlk.posixlk[1](ACTIVE)=type=WRITE, whence=0, start=0, len=1, pid = 12776, owner=a36bb0aea0258969, transport=0x120a4e0, , granted at Mon Feb 27 16:01:01 2012 posixlk.posixlk[2](ACTIVE)=type=WRITE, whence=0, start=7, len=1, pid = 23848, owner=d824f04c60c3c73c, transport=0x120b370, , granted at Mon Feb 27 16:01:01 2012 posixlk.posixlk[3](ACTIVE)=type=WRITE, whence=0, start=6, len=1, pid = 1, owner=30404152462d436c-69656e7431, transport=0x11eb4f0, , granted at Mon Feb 27 16:01:01 2012 posixlk.posixlk[4](BLOCKED)=type=WRITE, whence=0, start=8, len=1, pid = 23848, owner=d824f04c60c3c73c, transport=0x120b370, , blocked at Mon Feb 27 16:01:01 2012 ...
たとえば、test-volume のfile1
にある POSIX ロックをすべて消去するには、次のコマンドを実行します。# gluster volume clear-locks test-volume /file1 kind all posix 0,0-1 Volume clear-locks successful test-volume-locks: posix blocked locks=1 granted locks=0 No locks cleared. test-volume-locks: posix blocked locks=4 granted locks=1
21.2. Gluster ボリュームからのファイルパスの取得
getfattr
ユーティリティーを使用します。getfattr
ユーティリティーを使用すると、gluster ボリュームブリックにあるファイルを特定できます。ファイル名が分からない場合でも、ファイルのパスを取得できます。
21.2.1. 既知の問題の取得
# getfattr -n trusted.glusterfs.pathinfo -e text <path_to_fuse_mount/filename>
# getfattr -n trusted.glusterfs.pathinfo -e text /mnt/fuse_mnt/File1 getfattr: Removing leading '/' from absolute path names # file: mnt/fuse_mnt/File1 trusted.glusterfs.pathinfo="(<DISTRIBUTE:testvol-dht> (<REPLICATE:testvol-replicate-0> <POSIX(/rhgs/brick1):tuxpad:/rhgs/brick1/File1> <POSIX(/rhgs/brick2):tuxpad:/rhgs/brick2/File1>))"
21.2.2. 不明なファイル名の取得
# getfattr -d -m. -e hex /path/to/file/on/the/brick
21.2.3. gfid 文字列を使用したファイルパスの取得
- Fuse は、aux-gfid オプションを指定してボリュームをマウントします。
# mount -t glusterfs -o aux-gfid-mount hostname:volume-name <path_to_fuse_mnt>
詳細は以下のようになります。path_to_fuse_mount: gluster ボリュームがマウントされる Fuse マウント。以下に例を示します。# mount -t glusterfs -o aux-gfid-mount 127.0.0.2:testvol /mnt/aux_mount
- ボリュームをマウントしたら、以下のコマンドを実行します。
# getfattr -n trusted.glusterfs.pathinfo -e text <path-to-fuse-mnt>/.gfid/<GFID string>
詳細は以下のようになります。path_to_fuse_mount: gluster ボリュームがマウントされる Fuse マウント。GFID 文字列: GFID 文字列。以下に例を示します。# getfattr -n trusted.glusterfs.pathinfo -e text /mnt/aux_mount/.gfid/80b0b164-2ea4-478b-a4cd-a9f76c1e6efd getfattr: Removing leading '/' from absolute path names # file: mnt/aux_mount/.gfid/80b0b164-2ea4-478b-a4cd-a9f76c1e6efd trusted.glusterfs.pathinfo="(<DISTRIBUTE:testvol-dht> (<REPLICATE:testvol-replicate-0> <POSIX(/rhgs/brick2):tuxpad:/rhgs/brick2/File1> <POSIX(/rhgs/brick1):tuxpad:/rhgs/brick1/File1>))
コマンド出力には、ブリックパス情報が <POSIX> のタグの下に表示されます。この出力例では、ファイルが複製されるため、2 つのパスが表示されます。
21.2.4. 分散ボリュームのセルフ修復の制御
- 以下のコマンドを使用して scripts ディレクトリーに移動します。
# cd /usr/share/glusterfs/scripts
- 以下のコマンドを使用して、self-heal デーモンの PID を確認します。
# ps -aef | grep glustershd
出力は以下の形式になります。root 1565 1 0 Feb05 ? 00:09:17 /usr/sbin/glusterfs -s localhost --volfile-id gluster/glustershd -p /var/run/gluster/glustershd/glustershd.pid -l /var/log/glusterfs/glustershd.log -S /var/run/gluster/ed49b959a0dc9b2185913084e3b2b339.socket --xlator-option *replicate*.node-uuid=13dbfa1e-ebbf-4cee-a1ac-ca6763903c55 root 16766 14420 0 19:00 pts/0 00:00:00 grep --color=auto glustershd
この出力では、1565 は selfheald サービスの PID を表します。 - 以下のコマンドを使用して
control-cpu-load
スクリプトを実行します。# sh control-cpu-load.sh
- システムが以下の入力を要求したら、前の手順で取得したセル修復デーモンの PID を入力して
Enter
キーを押します。[root@XX-XX scripts]# sh control-cpu-load.sh Enter gluster daemon pid for which you want to control CPU. 1565
- システムが以下の入力を要求したら、
y
と入力してEnter
キーを押します。If you want to continue the script to attach 1565 with new cgroup_gluster_1565 cgroup Press (y/n)?
この例では、1565 は selfheald サービスの PID を表します。selfheald サービスの PID は、システムによって異なる場合があります。 - システムが以下の入力を要求したら、セルフ修復デーモンに割り当てるのに必要なクォータ値を入力して
Enter
キーを押します。Creating child cgroup directory 'cgroup_gluster_1565 cgroup' for glustershd.service. Enter quota value in range [10,100]: 25
この例では、self-heal デーモンのクォータ値は25
に設定されます。注記Self-heal デーモンの推奨されるクォータの値は 25 です。ただし、クォータの値は実行時にユーザーが設定できます。クォータ値が正常に設定されている場合、システムは以下の通知を要求します。Entered quota value is 25 Setting 25000 to cpu.cfs_quota_us for gluster_cgroup. Tasks are attached successfully specific to 1565 to cgroup_gluster_1565.
21.3. glusterd
クラッシュの解決
glusterd
クラッシュが確認されます。
glusterd
は、Termination Signal またはSIGTERM
を受信します。- Red Hat Gluster Storage のアップグレード時の
Segmentation fault
のエラーメッセージ。 glusterd
サービスを停止しています。
glusterd
のシャットダウンパス中に発生するため、これらのクラッシュに機能は影響を与えません。
glusterd
クラッシュが永続化されている場合は、Red Hat サポートにお問い合わせください。
21.4. 停止/失敗したブリックの再起動
# gluster volume start VOLNAME force
21.5. グループ設定の非アクティブ化
metadata-cache
、nl-cache
、または samba
などのグループ設定を非アクティブにします。この手順に従って、グループを非アクティブにするために、グループ設定で設定したボリュームオプションをリセットします。
groups
ディレクトリーに移動します。# cd /var/lib/glusterd/groups
- グループプロファイルの内容を表示します。
# cat PROFILE_NAME
- グループプロファイルにある各ボリュームオプションをリセットします。
# gluster volume reset VOLNAME OPTION_NAME
パート VIII. 付録
第22章 glusterd サービスの起動と停止
glusterd
コマンドラインを使用すると、論理ボリュームは物理ハードウェアから切り離できます。切り離すことで、アプリケーションやサーバーのダウンタイムなしに、ストレージボリュームのサイズ調整、サイズ変更、および縮小を行うことができます。
glusterd
サービスは、信頼できるストレージプールのすべてのサーバーで自動的に起動します。また、必要に応じて、このサービスを手動で起動して停止することもできます。
- 以下のコマンドを実行して、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 ソフトウェアコンポーネントおよびバージョン』 を参照してください。 - 以下のコマンドを実行して、glusterd を手動で停止します。RHEL 7 および RHEL 8 で以下を実行します。
# systemctl stop glusterd
RHEL 6 で以下を実行します。# service glusterd stop
第23章 ファイルのスプリットブレインの手動リカバリー
- 以下のコマンドを実行して、スプリットブレインにあるファイルのパスを取得します。
# gluster volume heal VOLNAME info split-brain
コマンド出力から、クライアントから実行したファイル操作が Input/Output エラーで失敗したファイルを特定します。 - マウントポイントからスプリットブレインファイルを開くアプリケーションを閉じます。仮想マシンを使用している場合は、マシンの電源をオフにする必要があります。
- getfattr コマンドを使用して、ファイルの AFR changelog 拡張属性を取得して検証します。次に、スプリットブレインのタイプを特定し、ファイルの 'good copy' が含まれるブリックを決定します。
getfattr -d -m . -e hex <file-path-on-brick>
以下に例を示します。# getfattr -d -e hex -m. brick-a/file.txt #file: brick-a/file.txt security.selinux=0x726f6f743a6f626a6563745f723a66696c655f743a733000 trusted.afr.vol-client-2=0x000000000000000000000000 trusted.afr.vol-client-3=0x000000000200000000000000 trusted.gfid=0x307a5c9efddd4e7c96e94fd4bcdcbd1b
trusted.afr.VOLNAMEvolname-client-<subvolume-index> を持つ拡張属性は、ファイルの changelog を維持するために AFR によって使用されます。trusted.afr.VOLNAMEvolname-client-<subvolume-index> の値は、glusterFS クライアント (FUSE または NFS-server) プロセスにより計算されます。glusterFS クライアントがファイルまたはディレクトリーを変更すると、クライアントは各ブリックに問い合わせ、ブリックのレスポンスに従って changelog 拡張属性を更新します。subvolume-index は gluster volume info VOLNAME のbrick number - 1
です。以下に例を示します。# gluster volume info vol Volume Name: vol Type: Distributed-Replicate Volume ID: 4f2d7849-fbd6-40a2-b346-d13420978a01 Status: Created Number of Bricks: 4 x 2 = 8 Transport-type: tcp Bricks: brick1: server1:/rhgs/brick1 brick2: server1:/rhgs/brick2 brick3: server1:/rhgs/brick3 brick4: server1:/rhgs/brick4 brick5: server1:/rhgs/brick5 brick6: server1:/rhgs/brick6 brick7: server1:/rhgs/brick7 brick8: server1:/rhgs/brick8
上記の例では、以下のようになります。Brick | Replica set | Brick subvolume index ---------------------------------------------------------------------------- /rhgs/brick1 | 0 | 0 /rhgs/brick2 | 0 | 1 /rhgs/brick3 | 1 | 2 /rhgs/brick4 | 1 | 3 /rhgs/brick5 | 2 | 4 /rhgs/brick6 | 2 | 5 /rhgs/brick7 | 3 | 6 /rhgs/brick8 | 3 | 7 ```
ブリック内の各ファイルは、それ自体の変更ログと、そのブリックがレプリカセット内の他のすべてのブリックに存在するファイルを維持します。上記の例のボリュームでは、brick-a のすべてのファイルにはエントリーが 2 つ、それ自体には、そのレプリカペアにあるファイルのもう 1 つがエントリーになります。以下は、brick2 の changelog です。- trusted.afr.vol-client-0=0x000000000000000000000000 - is the changelog for itself (brick1)
- trusted.afr.vol-client-1=0x000000000000000000000000 - changelog for brick2 as seen by brick1
同様に、brick2 のすべてのファイルは以下のようになります。- trusted.afr.vol-client-0=0x000000000000000000000000 - changelog for brick1 as seen by brick2
- trusted.afr.vol-client-1=0x000000000000000000000000 - changelog for itself (brick2)
注記このファイルは、レプリカの他のブリックにのみエントリーを持ちません。たとえば、brick1
にはtrusted.afr.vol-client-1
が設定され、brick2
にはtrusted.afr.vol-client-0
だけが設定されます。changelog の解釈は、以下の説明と同じです。他のレプリカのペアでも同じ拡張が可能です。changelog (保留中の操作数) 値を解釈
各拡張属性には、24 進数の 16 進数の値があります。最初の 8 桁はデータの変更ログを表します。2 番目の 8 桁はメタデータの変更ログを表します。最後の 8 桁はディレクトリーエントリーの変更ログを表します。
同じ語を表す Pictally は以下の通りです。0x 000003d7 00000001 00000000110 | | | | | \_ changelog of directory entries | \_ changelog of metadata \ _ changelog of data
ディレクトリーの場合は、メタデータおよびエントリー変更ログは有効です。通常のファイルでは、データおよびメタデータの changelogs が有効となります。デバイスファイルなどの特別なファイルの場合は、メタデータの変更ログが有効になります。ファイルのスプリットブレインが発生すると、データスプリットブレインまたはメタデータスプリットブレインのいずれかになります。以下は、同じファイルにあるメタデータのスプリットブレインの例です。# getfattr -d -m . -e hex /rhgs/brick?/a getfattr: Removing leading '/' from absolute path names #file: rhgs/brick1/a trusted.afr.vol-client-0=0x000000000000000000000000 trusted.afr.vol-client-1=0x000003d70000000100000000 trusted.gfid=0x80acdbd886524f6fbefa21fc356fed57 #file: rhgs/brick2/a trusted.afr.vol-client-0=0x000003b00000000100000000 trusted.afr.vol-client-1=0x000000000000000000000000 trusted.gfid=0x80acdbd886524f6fbefa21fc356fed57
changelogs のスクラッチ
ファイル/rhgs/brick1/a
の changelog 拡張属性は以下のとおりです。trusted.afr.vol-client-0 are all zeros (0x00000000................)
の最初の 8 桁trusted.afr.vol-client-1
の最初の 8 桁は、すべてのゼロ (0x000003d7................) ではありません。そのため、/rhgs/brick-a/a
の changelog は、一部のデータ操作が、/rhgs/brick2/a
で失敗したことを示します。trusted.afr.vol-client-0 are all zeros (0x........00000000........)
の 2 番目の 8 桁と、trusted.afr.vol-client-1
の 2 番目の 8 桁がすべてゼロ (0x........00000001........) ではありません。そのため、/rhgs/brick1/a
の changelog は、一部のデータ操作が、/rhgs/brick2/a
で失敗したことを示します。
ファイル/rhgs/brick2/a
の changelog 拡張属性は以下のとおりです。- 最初の 8 桁の
trusted.afr.vol-client-0
は、すべてのゼロ(0x000003b0................)ではありません。trusted.afr.vol-client-1
の最初の 8 桁はすべて 0x00000000................ です。そのため、/rhgs/brick2/a
の changelog は、一部のデータ操作が、/rhgs/brick1/a
で失敗したことを示します。 trusted.afr.vol-client-0
の 2 番目の 8 桁は、ゼロ(0x........00000001........)trusted.afr.vol-client-1
の 2 番目の 8 桁はすべてゼロ(0x........00000000........)です。そのため、/rhgs/brick2/a
の changelog は、一部のデータ操作が、/rhgs/brick1/a
で失敗したことを示します。
ここでは、両方のコピーには、他のファイル上にないデータ、メタデータの変更があります。したがって、これはデータとメタデータのスプリットブレインです。正しいコピーの決定
ファイルの stat および getfattr の出力を検査して、保持するメタデータとファイルの内容を決定し、保持するデータを決定する必要があります。上記の例を続けるために、ここでは
/rhgs/brick1/a
のデータと/rhgs/brick2/a
のメタデータを保持しています。スプリットブレインを解決するための関連する changelogs のリセット
データスプリットブレインの解決
ファイルの changelog 拡張属性を、
/rhgs/brick1/a
で成功しているが /rhgs/brick-b/a で失敗したかのようにファイルを変更する必要があります。ただし、/rhgs/brick2/a
には、/rhgs/brick2/a
でデータ操作が成功したことを示す changelog はありませんが、/rhgs/brick1/a
で失敗します。/rhgs/brick2/a
の trusted.afr.vol-client-0 で changelog のデータ部分をリセットする必要があります。メタデータのスプリットブレインの解決
ファイルの変更ログ拡張属性は、/rhgs/brick2/a
で成功したものの、/rhgs/brick1/a
で失敗したかのように、ファイルの changelog 拡張属性を変更する必要があります。ただし、/rhgs/brick1/a
には、一部のメタデータ操作が/rhgs/brick1/a
で成功しても /rhgs /brick2/a で失敗したことを示す changelog を含めることはできません
。/rhgs/brick1/a
の trusted.afr.vol-client-1 の changelog のメタデータ部分をリセットする必要があります。以下のコマンドを実行して、拡張属性をリセットします。trusted.afr.vol-client-0 0x000003b00000000100000000
から0x000000000000000100000000
にするには、/rhgs/brick2/a
で以下のコマンドを実行します。# setfattr -n trusted.afr.vol-client-0 -v 0x000000000000000100000000 /rhgs/brick2/a
trusted.afr.vol-client-1 0x0000000000000000ffffffff
から0x000003d70000000000000000
にするには、/rhgs/brick1/a
で以下のコマンドを実行します。# setfattr -n trusted.afr.vol-client-1 -v 0x000003d70000000000000000 /rhgs/brick1/a
拡張属性をリセットすると、changelogs は以下のようになります。# getfattr -d -m . -e hex /rhgs/brick?/a getfattr: Removing leading '/' from absolute path names #file: rhgs/brick1/a trusted.afr.vol-client-0=0x000000000000000000000000 trusted.afr.vol-client-1=0x000003d70000000000000000 trusted.gfid=0x80acdbd886524f6fbefa21fc356fed57 #file: rhgs/brick2/a trusted.afr.vol-client-0=0x000000000000000100000000 trusted.afr.vol-client-1=0x000000000000000000000000 trusted.gfid=0x80acdbd886524f6fbefa21fc356fed57
ディレクトリーエントリーのスプリットブレインの解決
AFR には、ディレクトリーにスプリットブレインがある場合に、ディレクトリーに異なるエントリーを一貫してマージする機能があります。1 つのブリックディレクトリー
storage
にエントリー1
、2
があり、他のブリックに3
、4
のエントリーがある場合、AFR はディレクトリー内の全エントリーをマージして、同じディレクトリーに1, 2, 3, 4
エントリーを追加します。ただし、ディレクトリーのファイルが削除されたためスプリットブレインが発生した場合は、ファイルが再び削除される可能性があります。スプリットブレインの解決では、ファイル名が同じエントリーがあり、そのディレクトリーにgfid
が異なるエントリーが 1 つ以上ある場合、人間の介入が必要になります。以下に例を示します。brick-a
では、ディレクトリーには、gfid_x
を持つfile1
と、file2
の2つのエントリーがあります。brick-b
では、ディレクトリーには、gfid_y
を持つfile1
とfile3
の 2 つのエントリーがあります。ここでは、ブリック上のfile1
の gfid は異なります。このようなディレクトリーのスプリットブレインには、問題の解決に人間の介入が必要です。スプリットブレインを解消するためには、brick-a
のfile1
かbrick-b
のfile1
を削除する必要があります。さらに、対応するgfid-link
ファイルを削除する必要があります。gfid-link
ファイルは、ブリックのトップレベルディレクトリーにある .glusterfs
ディレクトリーにあります。ファイルの gfid が0x307a5c9efddd4e7c96e94fd4bcdcbd1b
(get fattr コマンドから受信した trusted.gfid 拡張属性)の場合、gfid-link ファイルは/rhgs/brick1/.glusterfs/30/7a/307a5c9efddd4e7c96e94fd4bcdcbd1b
にあります。警告gfiid-link
を削除する前に、そのブリックに存在するファイルへのハードリンクがないことを確認する必要があります。ハードリンクが存在する場合は、それらを削除する必要があります。 - 以下のコマンドを実行して自己修復をトリガーします。
# ls -l <file-path-on-gluster-mount>
または# gluster volume heal VOLNAME
付録A 改訂履歴
改訂履歴 | |||
---|---|---|---|
改訂 3.5-0 | Wed Oct 30 2019 | Red Hat Gluster Storage Documentation Team | |
|