gluster-swift (オブジェクトストア)

Red Hat OpenStack Platform のオブジェクトストアとして Red Hat Gluster Storage を使用することはサポートされなくなりました。

gstatus

Red Hat Gluster Storage 3.5 は gstatus をサポートしていません。

スタンドアロンの Red Hat Gluster Storageに対するHeketi

Heketiは、OpenShift Container Storageとの組み合わせでのみサポートされています。Red Hat Gluster Storageでの一般的な使用には対応していません。

Nagios Monitoring

Red Hat Gluster Storage 3.5 は Nagios による監視をサポートしていません。Red Hat Gluster Storage Web 管理が、Red Hat Storage Gluster クラスター用に推奨されるモニタリングツールになりました。

Red Hat Atomic Host

Red Hat Atomic Hostは、Red Hat Gluster Storage 3.5での使用はサポートされていません。

Red Hat Gluster Storage Console

Red Hat Gluster Storage Consoleは、Red Hat Gluster Storage 3.5での使用はサポートされていません。Red Hat Gluster Storage Web 管理が、Red Hat Storage Gluster クラスター用に推奨されるモニタリングツールになりました。

VDO (Virtual Disk Optimizer)

VDO (Virtual Disk Optimizer) ボリュームは、Red Hat Hyperconverged Infrastructure for Virtualization 2.0 デプロイメントの一部としてのみサポートされます。VDO は、他の Red Hat Gluster Storage デプロイメントではサポートされません。

gluster-NFS

Gluster-NFS は、Red Hat Gluster Storage 3.5 では非推奨です。Red Hat では Gluster-NFS の使用を推奨しておらず、Red Hat Gluster Storage 3.5以降での新規デプロイメントでのその使用をサポートしません。Red Hat Gluster Storage 3.5 にアップグレードした既存のデプロイメントは引き続きサポートされますが、ユーザーには NFS-Ganesha への移行を推奨します。この NFS-Ganesha は、「本リリースにおける最新情報」 で詳述されている強化された機能、追加のセキュリティ機能、およびパフォーマンスの改善を提供します。

Remote Direct Memory Access (RDMA)

RDMA をトランスポートプロトコルとして使用することは、Red Hat Gluster Storage 3.5 で非推奨となっています。Red Hat ではその使用を推奨しておらず、Red Hat Gluster Storage 3.5での新規デプロイメントをサポートしません。Red Hat Gluster Storage 3.5 にアップグレードした既存のデプロイメントは引き続きサポートされます。

階層化

階層化は、Red Hat Gluster Storage 3.5 では非推奨です。Red Hat ではその使用を推奨しておらず、Red Hat Gluster Storage 3.5での新規デプロイメントでの階層化をサポートしません。Red Hat Gluster Storage 3.5 にアップグレードした既存のデプロイメントは引き続きサポートされます。

RHGSサーバー用のRed Hat Enterprise Linux 6（RHEL 6）ベースのISOイメージ

Red Hat Gluster Storage 3.5 のリリースから、Red Hat Gluster Storage サーバー用の Red Hat Enterprise Linux 6 ベースの ISO イメージが含まれなくなりました。

Parallel NFS (pNFS)

Red Hat Gluster Storage 3.4 の時点で、Parallel NFS はサポートされておらず、テクノロジープレビューとして利用できなくなりました。安定性に影響を及ぼす、この機能の長期的な問題は、アップストリームで未解決のままです。この機能の使用に関する情報は、Red Hat Gluster Storage 3.4 から削除されましたが、テクノロジープレビューとして Parallel NFS を提供したリリースのドキュメントで引き続き参照できます。

Parallel NFS (pNFS)

Red Hat Gluster Storage 3.4 の時点で、Parallel NFS はサポートされておらず、テクノロジープレビューとして利用できなくなりました。安定性に影響を及ぼす、この機能の長期的な問題は、アップストリームで未解決のままです。この機能の使用に関する情報は、Red Hat Gluster Storage 3.4 から削除されましたが、テクノロジープレビューとして Parallel NFS を提供したリリースのドキュメントで引き続き参照できます。

glusterd に関連する問題

BZ#1567616

glusterd のいずれかが停止したときに enable-shared-storage オプションが無効になっていると、共有ストレージ操作が正常に行われます。ただし、enable-shared-storage 操作の有効化および無効化の要求は失敗します。

回避策: 以下のコマンドを実行し、この動作を解消します。

# gluster v delete gluster_shared_storage

# gluster v set all cluster.enable-shared-storage enable

BZ#1400092

I/O の実行中にレプリカ数を増やすために add-brick を実行すると、データが失われる可能性があります。

回避策: レプリカ数の増加がオフラインになることを確認します (例: クライアントがボリュームにアクセスすることなく)。

BZ#1417097

glusterd は、設定が遅い場合に初期化に時間がかかります。その結果、/etc/fstab エントリーがマウントされる際に、ノード上の glusterd がそのマウントに対応する準備ができず、glusterd マウントは失敗します。このため、ノードの再起動後に共有ストレージがマウントされない可能性があります。

回避策: ノードの再起動後に共有ストレージがマウントされていない場合は、glusterd が稼働中かどうかを確認し、共有ストレージボリュームを手動でマウントします。

BZ#1394138

umount を実行せずに NFS-Ganesha HA クラスターからノードが削除されてから、そのノードのピアデタッチが実行されると、HA-Cluster のノードを削除しても、そのボリュームは /var/run/gluster/shared_storage/ の場所で引き続きアクセスできます。

注記

3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。

回避策: ピアをクラスターからデタッチした後に、そのピアの共有ストレージを手動でアンマウントします。

gdeploy に関連する問題

BZ#1408926

現在、gdeploy 設定ファイルでは、ssl_enable オプションは volume セクションの一部です。1 つのストレージプールの単一の gdeploy 設定ファイル内で複数のボリュームセクションが使用され、ssl_enable がすべてのボリュームセクションに設定されていると、SSL 操作は複数回実行されます。これにより、古いボリュームのマウントに失敗します。そのため、gdeploy 設定ファイルに 1 行で SSL を設定することはできません。

回避策: 1 つのストレージプールの 1 つの gdeploy 設定ファイルに複数のボリュームセクションがある場合は、変数 enable_ssl を 1 つのボリュームセクションのみに設定し、キーを以下のように設定します。'client.ssl'、値: 'on'、'server.ssl'、値: 'on'、'auth.ssl-allow'、値: comma separated SSL hostnames

Arbitrated ボリュームに関連する問題

BZ#1387494

現在、arbiter ボリュームのデータブリックが完全に消費されると、ENOSPC エラーで失敗せずに、新しいデータエントリーの作成がさらに rbiter ブリックで作成される可能性があります。ただし、クライアントは、マウントポイントで作成失敗エラーを正しく受信します。そのため、arbiter ブリックにはさらにエントリーが含まれる可能性があります。クライアントから rm -rf コマンドを実行すると、削除するファイルの一覧を取得するために databricks のいずれかに対して readdir 操作が実行されます。したがって、すべてのブリックでこれらのエントリーのみが削除されます。親ディレクトリーで rmdir コマンドを実行すると、データブリックでは成功しますが、その中にファイルがいくつかあるため、ENOTEMPTY エラーとともに arbiter で失敗します。

回避策: arbiter ブリックにディレクトリーが依然として含まれていて、マウントからの削除でエラーが発生しない場合は、ディレクトリーとその関連 GFID シンボリックリンクを手動で削除する必要があります。削除するディレクトリーにファイルが含まれている場合は、これらのファイルと関連する GFID ハードリンクを手動で削除する必要があります。

BZ#1388074

rm -rf コマンドの実行中にレプリカまたは arbiter サブボリュームがオフラインになるか、クライアントから切断された場合は、ブリックがオンラインに戻され、セルフ修復が完了したときに、ディレクトリーが再表示されることがあります。ユーザーがマウントから同じ名前のディレクトリーを作成しようとすると、この既存のディレクトリーをボリュームの他の DHT サブボリュームに修復する可能性があります。

回避策: マウントから削除が完了しませんでしたが、ブリックにディレクトリーが含まれている場合は、ディレクトリーとその関連 GFID symlink を手動で削除する必要があります。削除するディレクトリーにファイルが含まれている場合は、これらのファイルと関連する GFID ハードリンクを手動で削除する必要があります。

BZ#1361518

すべてのブリックでファイルを作成していても、arbiter ブリック上でのみ成功する場合、ファイルを使用するアプリケーションは失敗します。ただし、自己修復中に、このファイルは、データソースとマークされた Arbiter ブリックを使用して、データブリックに作成されます。データ自己修復は arbiter ブリックから実行すべきではないため、gluster volume heal volname info コマンドの出力にはエントリーが無限に一覧表示されます。

回避策: gluster volume heal volname info コマンドの出力に、ファイルの保留中のペナルダーが無期限に表示される場合には、以下の手順を実行して問題が永続化されているかどうかを確認します。

1. getfattr コマンドを使用して、以下を確認します。
   • trusted.afr.volname-client* xattrs はデータブリック上でゼロである場合
   • trusted.afr.volname-client* xattrs がデータの部分のみの arbiter brick でゼロ以外の場合。データ部分は最初の 4 バイトです。
     以下に例を示します。

     # getfattr -d -m . -e hex /bricks/arbiterbrick/file | grep trusted.afr.volname*
     getfattr: Removing leading '/' from absolute path names
     trusted.afr.volname-client-0=0x000000540000000000000000
     trusted.afr.volname-client-1=0x000000540000000000000000

2. コマンド出力が上記の状態と一致する場合は、以下のコマンドを使用して xattr を削除します。

   # for i in $(getfattr -d -m . -e hex /bricks/arbiterbrick/file |grep trusted.afr.volname*|cut -f1 -d'='); do  setfattr -x $i file; done

分散したボリュームに関連する問題

BZ#1766640

インサービスアップグレードの際に、古いバージョンのクライアントのI/Oが正しく動作するように、特別な処理が必要な場合があります。Red Hat Gluster Storage 3.3.1 のクライアントがバージョン 3.5 にアップグレードされる際に、分散したボリュームを持つサーバーはこの処理を行いません。

回避策:分散ボリュームを使用しており、クライアントが Red Hat Gluster Storage 3.3.1 にある場合、サーバーとクライアントをバージョン 3.5 に移行する際にオフライン アップグレードを実行します。

BZ#1735666

一部のケースでは、カーネルのread-aheadとglusterのread-aheadの両方のメカニズムにより、連続した読み取り操作時に読み取られるデータ量が大幅に増加します。このような場合、特に分散したボリュームでは、連続した読み取りのパフォーマンスが著しく低下します。

この問題が発生した場合は、以下のコマンドを使用してglusterのread-aheadおよびio-cacheの動作を手動で無効にすることで、問題を回避できます。

# gluster volume set <volname> read-ahead off
# gluster volume set <volname> io-cache off

DHT (Dstribute) Translator に関連する問題

BZ#1136718

自動ファイルレプリケーション (AFR) の自己修復ファイルには、AFR 自己修復ファイルを含むブリックが修復操作でオフラインになると、部分的に修復されます。ブリックがオンラインに戻る前に部分的に修復されたファイルを移行すると、移行したファイルには正しくないデータが存在し、元のファイルが削除されます。

BZ#1760713

cluster.lookup-optimizeオプションが有効な場合に、リバランス後に名前の変更操作を実行すると、クライアントから一部のファイルにアクセスできなくなるという問題があります。

回避策:ボリュームのcluster.lookup-optimizeを無効にします。

# gluster volume set VOLNAME cluster.lookup-optimize off

レプリケーションに関連する問題 (AFR)

BZ#1426128

複製ボリュームでは、ファイルの作成時に gluster ボリュームスナップショットが作成されると、ファイルはレプリカの 1 つのブリックに存在しますが、スナップショットを作成したボリュームにその他のブリックが存在しない可能性があります。このため、このスナップショットを復元し、マウントからのディレクトリーで rm -rf dir コマンドを実行すると、ENOTEMPTY エラーで失敗する可能性があります。

回避策: rm -rf dir コマンドの実行中に ENOTEMPTY エラーが発生しても、ディレクトリーの ls コマンドの出力にエントリーが含まれない場合は、レプリカのバックエンドブリックを確認して、ファイルが一部のブリックに存在するかどうかを確認します。マウントからファイル名を指定して stat コマンドを実行し、レプリカのすべてのブリックに修復されるようにします。ファイルを完全に修復したら、rm -rf dir コマンドの実行に成功します。

BZ#1721355

ボリュームへの書き込み、およびgluster heal infoコマンドの情報の読み取りには、いずれもブロッキングロックが必要です。これは、ボリュームの書き込み負荷が高いときに、gluster heal infoを実行すると、既存のロックによってブロックされることを意味します。

回避策:クライアントからの書き込み操作の数を減らし、ロックの解放とgluster heal info操作の完了を支援します。

Gluster NFSに関する問題

古い NFS over UDP の問題

• nfs.mount-udp オプションを有効にする場合は、Linux でサブディレクトリー (nfs.export-dir オプションを使用してエクスポート) をマウントしている間に、-o proto=tcp オプションを使用してマウントする必要があります。UDP は、Gluster-NFS サーバー上のサブディレクトリーマウントには対応していません。
• nfs.mount-udp オプションはデフォルトで無効になっています。NFS を使用して Red Hat Gluster Storage ボリュームにマウントする場合は、Solaris で posix-locks を使用するように有効にする必要があります。

古いロックの問題

• fcntl ロック (NFS Lock Manager) は IPv6 では機能しません。
• NFS クライアントが NAT (ネットワークアドレス変換) ルーターまたはファイアウォールの背後にある場合、ロックの動作は予測できません。現在の NLM の実装では、クライアントの IP アドレスのネットワークアドレス移行が発生しないことを想定します。
• NFS Lock Manager が適切に機能するには、すべてのサーバーとクライアントに解決可能なホスト名があるようにする必要があります。つまり、サーバーはクライアント名を解決でき、クライアントはサーバーのホスト名を解決できる必要があります。

BZ#1413910

Red Hat Gluster Storage 3.2 以降では、すべてのボリュームで、nfs.disable オプションが明示的に on または off のいずれかに設定されます。作成される新規ボリュームのデフォルト値は on であるため、これらのボリュームは経由でエクスポートされません。Gluster NFS。バージョン 3.1.x 以前から作成されたスナップショットには、このボリュームオプションがありません。

回避策: ボリュームで以下のコマンドを実行します。

# gluster v set nfs.disable volname off

復元されたボリュームは、経由でエクスポートされません。Gluster NFS。

階層に関連する問題

BZ#1334262

gluster volume tier attach コマンドがタイムアウトすると、いずれかの状況になります。ボリュームが階層化ボリュームにならないか、階層デーモンが起動しません。

回避策: タイムアウトが確認されたら、以下を実行します。

1. ボリュームが階層化されたボリュームかどうかを確認します。
   • インストールされていない場合は、gluster volume tier attach コマンドを再実行します。
   • 存在する場合は次のステップに進みます。
2. 各サーバーに階層デーモンが作成されているかどうかを確認します。
   • 階層デーモンが作成されていない場合は、以下のコマンドを実行します。

     # gluster volume tier volname start

BZ#1303298

階層化されたボリュームのスナップショットにエントリーを一覧表示すると、一部のファイルに対する誤ったパーミッションが表示されます。これは、ユーザーサービス可能なスナップショット (USS) が実際のデータファイルではなく、コールド層内のファイルへのリンクの stat 情報を返すためです。これらのファイルは -----T パーミッションがあるように見えます。

回避策: FUSE クライアントは、以下のオプションのいずれかを適用することで、この問題を回避できます。

• use-readdirp=no これは推奨されるオプションです。
• attribute-timeout=0
• entry-timeout=0

NFS クライアントは、noac オプションを適用して問題を回避できます。

BZ#1303045

NFS マウントで I/O 操作が進行中に層がアタッチされると、通常は 3 分から 5 分間、I/O が一時的に一時停止します。

回避策: I/O が 5 分以内に再開されない場合は、gluster volume start volname force コマンドを使用して中断せずに I/O を再開してください。

BZ#1273741

ハードリンクのあるファイルは、階層化ボリュームではプロモートされず、降格されません。

この問題に対する既知の回避策はありません。

BZ#1305490

階層移行とハードリンク作成間の競合状態により、File exists エラーでハードリンク操作が失敗し、クライアント上の Stale file handle メッセージを記録します。これは機能には影響しません。また、ファイルアクセスは期待どおりに機能します。

コールド層でハードリンクが作成された後でも、ホットレイヤーのデータにハードリンクが作成される前に、ファイルがコールド層に移行すると、この競合が発生します。このような場合、ホット層でハードリンクの作成を試みると失敗します。ただし、移行はコールド層のハードリンクをデータファイルに変換し、コールド層にすでにリンクがすでに存在するため、リンクが存在し、予想通りに機能します。

BZ#1277112

ホット層ストレージが満杯になると、コールド層ストレージに書き込みをリダイレクトしたり、データをフラッシュしたりせずに、ファイルの作成や既存のファイルへの新規書き込みなどの書き込み操作が、No space left on device で失敗します。

回避策: ホットレイヤーが完全に満杯になっていない場合は、書き込み操作を続行する前に次の CTR プロモート/降格サイクルを待つことで、この問題を回避できます。

ホット層が完全に一杯になると、管理者はホット層から安全な場所にファイルをコピーして、ホット層から元のファイルを削除して、ホット層の空き領域が解放されるまで待ってからファイルをコピーすることができます。

BZ#1278391

移行をトリガーする拡張属性を設定する領域がないため、ホット層からの移行は、ホット層がフル状態になると失敗します。

BZ#1283507

破損したファイルをプロモート用に特定して、ホット階層ストレージにプロモートできます。

まれに、BitRot スクラビターにより破損が見逃される可能性があります。これは 2 つの方法で発生する可能性があります。

1. チェックサムが作成される前にファイルが破損しているため、チェックサムが破損したファイルと一致して、BitRot スクラビターはファイルを破損と識別しません。
2. 正常なファイル用にチェックサムが作成され、ファイルが破損します。また、昇格用に識別されて、新しい (破損した) チェックサムが作成されるホット層に昇格される前に、破損したファイルがチェックサムに対して比較されません。

階層が使用中の場合、これらの識別されていない破損したファイルはヒートでき、ホット層にプロモートするために選択できます。破損したファイルがホット層に移行され、ホット層が複製されていない場合は、破損したファイルにアクセスしたり、コールド層に移行したりすることはできません。

BZ#1306917

User Serviceable Snapshot を有効にすると、階層の割り当ては成功しますが、attach tier 操作の実行中に進行中の I/O 操作が古いファイル処理エラーで失敗する可能性があります。

回避策: attach tier を実行する前に、ユーザーサービス可能なスナップショットを無効にします。attach tier に成功すると、User Serviceable Snapshots が有効になります。

スナップショットに関連する問題

BZ#1403169

スナップショットの取得中に NFS-ganesha が有効化され、そのスナップショットの復元中にそのスナップショットが無効化されるか、共有ストレージがダウンしたときに、スナップショットの復元に失敗します。

BZ#1403195

ブリックが起動してもすべてのトランスレーターが初期化されていないと、スナップショットの作成に失敗する可能性があります。

BZ#1169790

ボリュームが停止し、.snaps ディレクトリーにアクセスしようとすると、.snaps ディレクトリーのカーネル仮想ファイルシステム (VFS) キャッシュに負のキャッシュエントリーが作成されます。ボリュームをオンラインに戻した後、負のキャッシュエントリーが原因で ENOENT エラーで .snaps ディレクトリーへのアクセスに失敗します。

回避策: 以下のコマンドを実行して、カーネルの VFS キャッシュを削除します。

# echo 3 > /proc/sys/vm/drop_caches

これにより、一時的なパフォーマンスが低下する可能性があることに注意してください。

BZ#1174618

User Serviceable Snapshot 機能が有効で、ディレクトリーに既存の .snaps フォルダーがある場合、そのフォルダーにアクセスすると、予期しない動作が発生する可能性があります。

回避策: 既存の .snaps フォルダーの名前を別の名前で変更します。

BZ#1394229

ボリュームセット操作などのクライアントグラフの変更、スナップショットの復元など、最終的にボリュームをマウントするクライアントプロセスのメモリーシナリオが不足します。

BZ#1129675

glusterd が利用できない場合や、ノードが利用できない場合に、クラスターノードで スナップショットの復元を実行すると、以下のエラーが発生します。

• gluster volume heal vol-name info コマンドを実行すると、エラーメッセージ Transport endpoint not connected が表示されます。
• クライアントが glusterd サービスへの接続を試みると、エラーが発生します。

回避策: 全ノードおよび対応する glusterd サービスが実行中の場合にのみ、スナップショットを復元します。以下のコマンドを実行して glusterd を起動します。

# service glusterd start

BZ#1118780

ディレクトリーの名前変更中に作成されたスナップショットの復元では (ディレクトリーはハッシュ化サブボリュームで名前変更されていますが、すべてのサブボリュームに変更されています)、古いディレクトリーと新しいディレクトリーがともに存在し、同じ GFID を持ちます。これにより、不整合が生じ、それらのディレクトリー内のファイルへのアクセスが問題が発生する可能性があります。

DHT では、ディレクトリーの名前を変更 (ソース、宛先) が最初にハッシュ化されたサブボリュームで実行し、成功すると残りのサブボリュームで行われます。この時点で、ソースディレクトリーと宛先ディレクトリーの両方が同じ GFID のボリュームに存在します。宛先は、ハッシュ化されたサブボリュームの宛先にあり、ソースは残りの部分にあります。現時点では、(ソースまたは宛先のいずれかでの) 並行ルックアップにより、ディレクトリーがまだ存在していないサブボリュームに、ディレクトリーが作成される可能性があります (ハッシュにはソースディレクトリーエントリー、残りのサブディレクトリーには宛先ディレクトリーエントリー)。したがって、同じ GFID を持つディレクトリーエントリーは source と destination の 2 つになります。

BZ#1236149

ノード/ブリックがダウンすると、force オプションを指定しても snapshot create コマンドが失敗します。これは想定される動作です。

BZ#1240227

LVM における LUKS 暗号化には現在対応していません。

BZ#1246183

User Serviceable Snapshots は、Erasure Coded (EC) ボリュームではサポートされていません。

Geo レプリケーションに関連する問題

BZ#1393362

gluster ボリュームのリバランスが進行中にジオメトリーセッションが作成されると、geo レプリケーションによってスレーブボリュームに同期している一部のファイル/ディレクトリーが欠落する可能性があります。これは、リバランスによるファイルの内部移動が原因で生じます。

回避策: マスターボリュームのリバランスが進行中であれば、geo レプリケーションのセッションを作成しないでください。

BZ#1344861

マスタークラスターで 1 つ以上のノードがダウンすると、geo レプリケーション設定が変更されます。このため、ダウンしたノードには、ノードの起動時に古い設定が適用されます。

回避策: 全ノードが起動すると、Geo レプリケーションの設定コマンドを再度実行します。これにより、プライマリークラスターのすべてのノードには同じ Geo レプリケーション設定オプションが含まれます。

BZ#1293634

プライマリーボリュームが階層化されると、geo レプリケーションが適用されたストレージのパフォーマンスが向上します。これにより、階層化されたボリュームで geo レプリケーションのパフォーマンスが低下します。

BZ#1302320

ファイルの昇格中に、リバランス操作はスティッキービットと suid/sgid ビットを設定します。通常、移行が完了するとこれらのビットが削除されます。移行が完了する前にファイルで readdirp が呼び出されると、これらのビットは削除されず、クライアントで適用されません。

ビットの適用中に rsync が発生すると、ビットは宛先と同期され、宛先でアクセスに障害が発生しないように、ビットがファイルに適用されます。これは、geo レプリケーションが適用された設定でも発生する可能性がありますが、リバランスプロセスが継続的であるため、階層化の可能性が高まります。

BZ#1102524

Geo レプリケーションワーカーは障害状態になり、再開時に再起動します。これは、再起動時には通常通りに機能しますが、再開まで同期するのに時間がかかります。

BZ#1238699

Changelog History API は、ブリックパスのセッションが同じままになることを想定します。ただし、スナップショットの復元時に、ブリックパスが変更されます。これにより、履歴 API が失敗し、geo-rep が Faulty に変わります。

回避策:

1. スナップショットの復元後に、プライマリーボリュームおよびセカンダリーボリュームが停止していることを確認します。
2. htime ディレクトリー (プライマリーボリューム) のバックアップを作成します。

   cp -a <brick_htime_path> <backup_path>

   注記

   拡張属性を保持するには、-a オプションの指定が重要です。
   以下に例を示します。

   cp -a /var/run/gluster/snaps/a4e2c4647cf642f68d0f8259b43494c0/brick0/b0/.glusterfs/changeslogs/htime  /opt/backup_htime/brick0_b0

3. 以下のコマンドを実行して、htime ファイルの OLD パスを新しいブリックパスに置き換えます。ここでの OLD_BRICK_PATH は現在のボリュームのブリックパスで、NEW_BRICK_PATH はスナップショットの復元 後 のブリックパスになります。

   # find <new_brick_htime_path> - name 'HTIME.*' -print0  | \
   xargs -0 sed -ci 's|<OLD_BRICK_PATH>|<NEW_BRICK_PATH>|g'

   以下に例を示します。

   # find /var/run/gluster/snaps/a4e2c4647cf642f68d0f8259b43494c0/brick0/b0/.glusterfs/changelogs/htime/ -name 'HTIME.*' -print0  | \
   xargs -0 sed -ci 's|/bricks/brick0/b0/|/var/run/gluster/snaps/a4e2c4647cf642f68d0f8259b43494c0/brick0/b0/|g'

4. 復元されたボリュームで、プライマリーボリュームおよびセカンダリーボリュームおよび Geo レプリケーションセッションを開始します。ステータスは Active に更新する必要があります。

自己修復に関連する問題

BZ#1240658

バックエンドのレプリカペアのブリックからファイルが誤って削除され、gluster volume heal VOLNAME full を実行すると、ファイルが修復されない可能性があります。

回避策: クライアント (マウント) からファイルでルックアップを実行します。これにより、修復がトリガーされます。

BZ#1173519

既存のファイルに書き込みを行い _AVAILABLE_BRICK_SPACE_ をチェックすると、書き込みは I/O エラーで失敗します。

回避策: cluster.min-free-disk オプションを使用します。nGB までのファイルを頻繁に書き込む場合は、min-free-disk を n より大きい mGB 値に設定できます。

たとえば、ファイルサイズが 5 GB で、これが書き込むファイルサイズの上限である場合は、min-free-disk を 8 GB に設定することを検討してください。これにより、ファイルが利用可能な十分な容量を持つブリックに書き込まれます (存在する場合)。

# gluster v set _VOL_NAME_ min-free-disk 8GB

NFS-Ganesha に関連する問題

再起動後にロック解除ができないことがあります。

NFS サーバーを再起動すると、grace-period 機能内でロック解除が失敗する可能性があり、ロックが以前に保持されない可能性があります。

BZ#1570084

nfs-ganesha の起動を開始する前にボリュームがエクスポートされる場合は、ボリュームのエクスポートに使用される dbus コマンドは失敗します。

回避策: nfs-ganesha プロセスを再起動してボリュームをエクスポートします。

BZ#1535849

NFS-Ganesha の場合、キャッシュエントリー用に作成されたメモリーは解放されずに再利用されます。たとえば、「foo」ファイルがあり、「foo」の異なるクライアントキャッシュエントリーから削除しても、そのファイルは存在します。その結果、NFS-Ganesha が使用するメモリーはキャッシュが満杯になるまで増大します。

BZ#1461114

ノードを既存の Ganesha クラスターに追加する際に、以下のエラーメッセージが断続的に表示されます。

Error: Some nodes had a newer tokens than the local node. Local node's tokens were updated. Please repeat the authentication if needed

Error: Unable to communicate with pcsd

回避策: 既知の機能への影響がないため、これらのメッセージは無視しても問題ありません。

BZ#1402308

ganesha クラスターの設定後に ifdown が実行された場合、Corosync サービスがクラッシュします。これは HA 機能に影響を与える可能性があります。

BZ#1416371

NFS-ganesha サーバーでエクスポートされるボリュームで gluster volume stop 操作が失敗した場合、コマンドが失敗するにもかかわらず、ボリュームがいくつかのノードでエクスポートされない可能性が高くなります。これにより、NFS-ganesha クラスター全体で一貫性のない状態になります。

回避策: クラスターを通常の状態に復元するには、以下を実行します。

• ボリュームがエクスポートされないノードを特定します。
• 以下の dbus コマンドを使用して、ボリュームを手動で再エクスポートします。

  # dbus-send --print-reply --system --dest=org.ganesha.nfsd /org/ganesha/nfsd/ExportMgr org.ganesha.nfsd.exportmgr.AddExport string:/var/run/gluster/shared_storage/nfs-ganesha/exports/export.<volname>.conf string:""EXPORT(Path=/<volname>)"""

  注記

  3.5 Batch Update 3 のリリースにより、共有ストレージのマウントポイントが /var/run/gluster/ から /run/gluster/ に変更されました。

BZ#1398280

PCS リソースのいずれかが失敗した状態にある場合、ティアダウン完了には多くの時間がかかります。このため、gluster nfs-ganesha disable コマンドはタイムアウトします。

回避策: gluster nfs-ganesha disable がタイムアウトが発生した場合には、pcs status を実行し、リソースが失敗した状態にあるかどうかを確認します。次に、以下のコマンドを使用して、そのリソースのクリーンアップを実行します。

# pcs resource --cleanup <resource id>

gluster nfs-ganesha disableコマンドを再実行してください。

BZ#1328581

ファイルを削除すると、nfs-ganesha プロセスは、削除されたエントリーでルックアップを実行して、リンクが存在する場合は属性を更新します。このため、ファイルが削除されると ENOENT で検索に失敗し、gfapi.log に誤解を招くログメッセージが発生します。

これは想定される動作であり、機能の問題はありません。このような場合、ログメッセージは無視する必要があります。

BZ#1259402

vdsmd サービスと abrt サービスが相互にインストールされると、vdsmd は /proc/sys/kernel/core_pattern ファイルの abrt コアダンプ設定を上書きします。これにより、NFS-Ganesha がコアダンプを生成するのを防ぎます。

回避策: /etc/vdsm/vdsm.conf ファイルで core_dump_enable を false に設定してコアダンプを無効にし、abrt-ccpp サービスを再起動します。

# systemctl restart abrt-ccpp

BZ#1257548

IP フェイルオーバーをトリガーする nfs-ganesha サービスモニタースクリプトは、10 秒ごとに定期的に実行されます。デフォルトでは、glusterFS サーバーの ping-timeout (到達できないクライアントのロックがフラッシュされる後) は 42 秒です。IP フェイルオーバー後に、一部のロックは glusterFS サーバープロセスでクリーンアップされません。したがって、NFS クライアントによるロック状態の回収に失敗します。

回避策: nfs-ganesha サービスモニター期間 (デフォルトは 10s) を、Gluster サーバーの ping-timeout (デフォルトの 42) 期間に設定することを推奨します。

したがって、以下のコマンドを使用してネットワークの ping-timeout を減らす必要があります。

# gluster volume set <volname> network.ping-timeout <ping_timeout_value>

以下のコマンドを使用して、nfs-service モニターの間隔を増やします。

# pcs resource op remove nfs-mon monitor

# pcs resource op add nfs-mon monitor interval=<interval_period_value> timeout=<timeout_value>

BZ#1470025

PCS クラスター IP リソースは、NFS-Ganesha HA クラスターで VIP のフェイルオーバー/フェイルバック中に FAILED 状態になる場合があります。その結果、VIP にアクセスできなくなると、マウントの失敗やシステムのフリーズが生じます。

回避策: 以下のコマンドを使用して、障害が発生したリソースを消去します。

# pcs resource cleanup resource-id

BZ#1474716

再起動後に、systemd は NFS-Ganesha が STARTED 状態にあると解釈する場合があります (実行されていない場合)。

回避策: NFS-Ganesha プロセスを手動で起動します。

BZ#1473280

gluster nfs-ganesha disable コマンドを実行すると、NFS-Ganesha サービスが停止します。エクスポート前のエントリーの場合には、NFS-Ganesha は FAILED 状態になります。

回避策: 失敗後に NFS-Ganesha プロセスを再起動して、以下のコマンドを再度実行します。

# gluster nfs-ganesha disable

Red Hat Gluster Storage ボリュームに関連する問題

BZ#1286050

ボリュームでは、読み取り操作および書き込み操作が進行中で、同時にリバランス操作が実行され、そのボリュームで remove-brick 操作が実行されると、rm -rf コマンドはいくつかのファイルで失敗します。

BZ#1224153

ブリックプロセスがなくなると、BitD は対応するブリックとの通信に使用されるソケットから読み込みを試みます。失敗すると、BitD はログファイルに障害を記録します。これにより、多くのメッセージがログファイルに置かれ、ソケットからの読み取りに失敗し、ログファイルのサイズが増えます。

BZ#1227672

指定のオブジェクトがクリーンな状態か破損しているかを確認するには、ファイルシステム (オブジェクト) の正常なスクラブが必要になります。ファイルが破損し、ファイルシステムでスクラブが実行されていない場合は、I/O の実行時に適切なコピーを保持するブリックがオフラインであった場合に、破損したオブジェクトが複製される可能性があります。

回避策: 修復中に破損をオンデマンドでオブジェクトが確認する必要があります。

Samba に関連する問題

BZ#1329718

スナップショットボリュームは読み取り専用です。すべてのスナップショットは、.snaps ディレクトリー内のディレクトリーとして利用できます。スナップショットは読み取り専用ですが、スナップショットのディレクトリー属性は、スナップショットボリュームのディレクトリー属性と同じで、読み取り/書き込みが可能です。これにより、Windows はスナップショットディレクトリーが読み取り/書き込みと仮定されるため、混乱を生じさせる可能性があります。ファイルプロパティーの Restore previous version オプションでは、open オプションを指定できます。対応するスナップショットからファイルを開きます。ファイルを開いても一時ファイル (Microsoft Word ファイルなど) も作成すると、オープンは失敗します。これは、スナップショットボリュームが読み取り専用であるため、一時ファイルの作成に失敗するためです。

回避策: このようなファイルを、直接開くのではなく、別の場所にコピーします。

BZ#1322672

vdsm と abrt の ccpp アドオンが相互にインストールされると、vdsmd は /proc/sys/kernel/core_pattern で abrt のコアダンプ設定を上書きします。これにより、vdsmd が設定した新しいコアダンプの場所での SELinux 検索拒否により、Samba がコアダンプを生成できなくなります。

回避策:以下の手順を実行してください。

1. /etc/vdsm/vdsm.conf でコアダンプを無効にします。

   core_dump_enable = false

2. abrt-ccpp サービスおよび smb サービスを再起動します。

   # systemctl restart abrt-ccpp
   # systemctl restart smb

BZ#1282452

ctdb2.5-debuginfo パッケージは現在 samba-debuginfo パッケージと競合するため、ctdb2.5-debuginfo がインストールされていると、ctdb バージョン 4 へのアップグレードは失敗します。

回避策: ctdb バージョン 4 にアップグレードする前に、ctdb2.5-debuginfo パッケージを手動で削除します。必要に応じて、アップグレード後に samba-debuginfo をインストールします。

SELinux に関連する問題

BZ#1256635

Red Hat Gluster Storage は現在、SELinux ラベル付きのマウントをサポートしていません。

FUSE マウントでは、現在 SELinux はサブタイプでファイルシステムを区別できないため、異なる FUSE ファイルシステム (BZ#1291606) を区別することはできません。つまり、Red Hat Gluster Storage のクライアント固有のポリシーは定義できず、SELinux は Red Hat Gluster Storage が追跡するファイルのクライアント側の拡張属性を安全に変換することができません。

BZ#1269584 の一部として、NFS-Ganesha マウントの回避策が進行中です。BZ#1269584 が完了すると、SELinux ラベル付きサポートを含む、NFS バージョン 4.2 の Red Hat Gluster Storage のサポートが有効になります。

BZ#1291194 , BZ#1292783

現在の SELinux ポリシーは、ctdb の 49.winbind イベントスクリプトが smbcontrol の実行を阻止します。パブリック IP アドレスがノードから移動されると、winbind で整合性のない状態が発生することがあります。これは、winbind が、その IP アドレスを介して接続を破棄することができないためです。

シャード化に関連する問題

BZ#1332861

シャード化は、基礎となるファイルシステムからの書き込みとして毎回ブロック数の差異に依存し、その数をシャード化されたファイルの既存のブロック数に追加します。ただし、ブロックの XFS の予測事前割り当てにより、予測事前割り当てで xfs が提示した書き込み後のシャードのブロック数が、実際に書き込まれたブロック数よりも大きくなる可能性があるため、この計算は適切ではありません。

このため、シャード化されたファイルの block-count は、ディスク上で消費されるブロックの数よりも大きくなるように示される可能性があります。その結果、du -sh などのコマンドが、ファイルが使用する物理ブロックの数よりも高いサイズを報告する可能性があります。

一般的な問題

GFID 不一致によりエラーが発生する

ファイルおよびディレクトリーが異なるバックエンドに GFID と異なる場合は、glusterFS クライアントがハングしたり、エラーを表示する可能性があります。この問題の詳細は、Red Hat サポートにお問い合わせください。

BZ#1236025

スナップショットの復元におけるファイルおよびディレクトリーのタイムスタンプが変更され、適切な変更ログの読み取りに失敗します。glusterfind pre は、historical changelogs not available というエラーで失敗します。スナップショットの復元後に既存の glusterfind セッションが機能しなくなります。

回避策: 既存の glusterfind セッションから必要な情報を収集し、セッションを削除し、スナップショットの復元を実行してから glusterfind セッションを新たに作成します。

BZ#1573083

storage.reserve の制限に到達し、ディレクトリーが作成されると、ディレクトリーの作成が ENOSPC エラーで失敗し、ディレクトリーの検索で ESTALE エラーが発生します。したがって、ファイル操作が完了しません。

回避策: 回避策はありません。

BZ#1260119

glusterfind コマンドは、クラスターのいずれかのノードから実行する必要があります。クラスターのすべてのノードが、コマンド開始したノードの known_hosts 一覧に追加されていない場合は、glusterfind create コマンドがハングします。

回避策: ローカルノードを含め、ピアのすべてのホストを known_hosts に追加します。

BZ#1127178

レプリカブリックがオンラインに戻る場合は、自己修復が保留している可能性があります。ブリックで rm -rf コマンドを実行すると、Directory not empty というエラーメッセージで失敗します。

回避策: 保留中の自己修復がないときに操作を再試行します。

BZ#1460629

rm -rf コマンドが、シンクブリックからのファイルパージに関与する保留中の自己修復エントリーを持つ親ディレクトリーで実行される場合、ディレクトリーおよびファイルはシンクのブリックから削除されない可能性があります。rm -rf の readdir はソースブリックから提供されるため、エントリー修復保留中のファイルはシンクブリックから削除されません。このようなファイルで修復保留中のデータまたはメタデータは、問題が解決されるまで heal-info コマンドの出力に表示されます。

回避策: ファイルおよび親ディレクトリーがその他のブリックに存在しない場合は、シンクブリックから削除します。これにより、それらが次の 'heal-info' 出力に一覧表示されなくなります。

BZ#1462079

クライアントのホスト値が正しくないなどの理由で失敗した場合でも、Statedumpは成功を報告します。

# gluster volume statedump volume client not-a-host:port

回避策: hostの値が正しいか確認してください。

Red Hat Gluster Storage AMI に関する問題

BZ#1267209

redhat-storage-server パッケージは、Red Hat Enterprise Linux 7 AMI イメージの Red Hat Gluster Storage Server 3 にデフォルトでインストールされません。

回避策: yum を使用してこのパッケージを手動でインストールすることを強く推奨します。

# yum install redhat-storage-server

redhat-storage-server パッケージは主に /etc/redhat-storage-release ファイルを提供し、ストレージノードの環境を設定します。パッケージは主に /etc/redhat-storage-release ファイルを提供し、ストレージノードの環境を設定します。

Red Hat Gluster Storage Web 管理に関連する問題

BZ#1622461

etcd を停止したり、Web Administration サーバーノード自体をシャットダウンしたりすることで発生する可能性のある中央ストア (etcd) が停止すると、すべての Web Administration サービスは etcd の到達可能性に関する例外を報告します。その結果、etcd に到達できなくなるため、Web 管理サービスがクラッシュします。

回避策: etcd が返されたら、Web Administration サービスを再起動します。

コンテキストに関係なく表示されるデータセンター内の全イメージ

Red Hat Gluster Storage サーバーノードと Red Hat Enterprise Virtualization Hypervisor が同じデータセンターにある場合は、仮想マシンの作成時やストレージドメインを追加する際に、両タイプのサーバーが選択できるように一覧表示されます。Red Hat は、Red Hat Gluster Storage サーバーノード用に別のデータセンターを作成することを推奨します。