Red Hat Training

A Red Hat training course is available for Red Hat Gluster Storage

3.4 リリースノート

Red Hat Gluster Storage 3.4

Red Hat Gluster Storage 3.4 リリースノート

1 エディッション

Gluster Storage Documentation Team

Red Hat Customer Content Services

概要

本リリースノートでは、Red Hat Gluster Storage 3.4 で実装された改良点と追加機能の概要を説明します。

第1章 はじめに

Red Hat Gluster Storage は、エンタープライズ向けに柔軟かつアジャイルな非構造化データストレージを提供するソフトウェアで、スケールアウトした唯一のストレージソリューションです。Red Hat Gluster Storage は、データストレージとインフラストラクチャーを統合し、パフォーマンスを向上して、可用性および管理性を改善し、組織の課題やニーズに対応する機会を新たに提供しています。
GlusterFS は、Red Hat Gluster Storage の主要なビルディングブロックで、スタック可能なユーザー空間設計をベースとしており、さまざまなワークロードのために例外のパフォーマンスを提供できます。GlusterFS は、複数のネットワークインターフェースを通じてさまざまなストレージサーバーを集約し、これらをつなぎ合わせて単一の大きな並列ネットワークファイルシステムを形成します。POSIX と互換性のある GlusterFS サーバーは、XFS ファイルシステム形式で、ディスクにデータを保存します。これらのサーバーは、Network File System (NFS) および Server Message Block SMB (CIFS としても知られている) などの業界標準アクセスプロトコルを使用してアクセスされます。
オンプレミスの Red Hat Gluster Storage Server は、プライベートクラウドまたはデータセンターのデプロイメントで使用できます。Red Hat Gluster Storage は、コモディティーサーバーおよびストレージハードウェアにインストールできるため、強力かつ拡張性の高い、高可用性 NAS 環境になります。さらに、Red Hat Gluster Storage を Amazon Web Services (AWS)、Microsoft Azure、または Google Cloud と共にパブリッククラウドにデプロイすることもできます。これは、プライベートクラウドまたはデータセンターで可能なすべての機能をパブリッククラウドに提供します。そのためには、クラウドに非常にスケーラブルで高可用性の NAS を提供します。

Red Hat Gluster Storage Server for On-premises

Red Hat Gluster Storage Server for On-premises を使用すると、企業は製品サーバーおよびストレージハードウェアを使用して、仮想の、スケーラブルな、集中管理プールとして物理ストレージを扱うことができます。

Red Hat Gluster Storage Server for Public Cloud

Red Hat Gluster Storage Server for Public Cloud は、AWS、Microsoft Azure、および Google Cloud でスケーラブルな NAS をデプロイするための GlusterFS をパッケージ化しています。この強力なストレージサーバーは、これらのパブリッククラウドプロバイダーのユーザーに、可用性が高く、スケーラブルで仮想化された、集中管理プールを提供します。

第2章 本リリースで変更された内容

2.1. 本リリースにおける最新情報

本セクションでは、Red Hat Gluster Storage 3.4 リリースの主要機能および機能拡張を説明します。
SMB を使用してエクスポートした Red Hat Gluster Storage ボリュームが macOS クライアントにマウントできるようになりました。
SMB を使用してエクスポートされる Red Hat Gluster Storage ボリュームが macOS クライアントにマウントできるようになりました。
macOS でのユーザーアクセスおよびマウントの設定に関する詳細は、Red Hat Gluster Storage 3.4 『管理ガイド』 の「SMB」を参照してください。
基礎となる Red Hat Enterprise Linux バージョン間でのアップグレードのサポート
preupgrade-assistant を使用して gluster システムでオフラインアップグレードを実行することで、基礎となる Red Hat Enterprise Linux 6 を Red Hat Enterprise Linux 7 にアップグレードできるようになりました。
詳細は、Red Hat Gluster Storage 3.4 『インストールガイド』 の Upgrading Red Hat Gluster Storage to Red Hat Enterprise Linux 7 の章を参照してください。
リバランス操作をスキップしたファイルの特定
リバランス操作をスキップしたファイルを特定できます。今回のリリースまで、リバランスステータスは、失敗してスキップしたエントリーの ’count’ のみを示していました。今回のリリースで、ユーザーは、msgid 109126 を検索してスキップされたファイルの一覧を取得できるようになりました。
詳細は、Red Hat Gluster Storage 3.4 『管理ガイド』のDisplaying Rebalance Progress を参照してください。
ブリックでディスク領域を確保します。
管理者は、ブリックにディスク領域を予約できるようになりました。storage.reserve オプションは、gluster プロセス用に十分な領域を確保し、ディスクがいっぱいに達しないようにします。
詳細は、Red Hat Gluster Storage 3.4 『管理ガイド』 の Reserving Storage on a Volume を参照してください。
CLI から GFID スプリットブレインを解決する機能
GFID スプリットブレインは、新しい CLI コマンドを使用して自動的に分析および解決できます。
詳細は、Red Hat Gluster Storage 3.4 『管理ガイド』 の Recovering GFID Split-brain from the gluster CLI を参照してください。
remove-brick 操作の停止
remove-brick 操作の停止が完全にサポートされるようになりました。remove-brick 操作を開始していても、操作がまだコミットされていない場合は、操作を停止できます。remove-brick 操作中に移行されたファイルは、remove-brick 操作が停止したときに元のブリックに移行されません。
詳細は、Red Hat Gluster Storage 3.4 『管理ガイド』 の Stopping a remove-brick operation を参照してください。
読み取り専用ボリュームのマウント
読み取り専用パーミッションのボリュームのマウントが完全にサポートされるようになりました。ボリュームは、ボリュームまたはマウントポイントレベルで読み取り専用パーミッションでマウントできます。
ボリュームを読み取り専用としてマウントするには、ボリュームをマウントする際に ro オプションを指定します。 
# mount -t glusterfs -o ro hostname:volname mountpoint
ボリュームが読み取り専用パーミッションでのみマウントできるようにするには、そのボリュームをホストするストレージプールの Red Hat Gluster Storage サーバーで以下のコマンドを実行して、read-only ボリュームオプションを有効にします。 
# gluster volume set volname read-only enable
Native Client (FUSE) を使用したサブディレクトリーのマウント
Native Client を使用した gluster ボリュームのサブディレクトリーのマウントが完全にサポートされるようになりました。ユーザーが他のユーザーに属する情報を取得できるため、マウントしたボリューム全体への複数のアクセスを付与すると、セキュリティー上のリスクとなる可能性があります。サブディレクトリーをマウントすると、ユーザーはストレージの一部にのみアクセスできます。また、ユーザーの名前空間分離も提供するため、複数のユーザーが他のユーザーと名前空間の競合のリスクを生じさせることなくストレージにアクセスできます。
詳細は Red Hat Gluster Storage 3.4 『管理ガイド』 の Manually Mounting Sub-directories Using Native Client を参照してください。
Red Hat Gluster Storage Web Administration の approachrl-ansible によるファイアウォール設定の自動化
以前は、ファイアウォールを手動で設定することで、ファイアウォールの設定ミスが生じていました。今回のリリースにより、ファイアウォール設定が approachrl-ansible で自動化され、自動インストール時に適用されるようになります。これにより、その他の既存ルールに影響を与えずに Web 管理用に適切なファイアウォールルールを設定できるようになりました。
詳細は、Red Hat Gluster Storage 3.4 『管理ガイド』 の 2.4.Firewall Configuration の章を参照してください。
Red Hat Gluster Storage Web Administration で簡単に識別できるように、カスタムした、ユーザーフレンドリーなクラスター名の設定
以前のバージョンでは、クラスターは、ユーザーフレンドリーなクラスター名を設定できずにインポートされました。クラスターは UUID を使用して識別されていました。これにより、複数のクラスターが存在する場合に特定のクラスターの位置の特定と識別が困難になっていました。この新機能により、ユーザーはクラスターのインポート時にカスタマイズされたユーザーフレンドリーなクラスター名を指定して、Web 管理環境が管理するクラスターを簡単に識別できるようになりました。
Web Administration UI を使用したクラスターの管理解除
以前のバージョンでは、特定のクラスターの管理を解除する UI ベースの機能はありませんでした。今回のリリースにより、Web Administration インターフェースで利用可能な UI ベースの機能を使用して、特定のクラスターを管理解除できるようになりました。
詳細は、Red Hat Gluster Storage Web Administration 3.4 『モニタリングガイド』の3.1.Unmanaging Cluster を参照してください。

2.2. サポートの制限

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

2.3. 非推奨の機能

以下の機能は、Red Hat Gluster Storage 3.4 では非推奨となり、後続のリリースでは非推奨とみなされます。機能の削除タイムフレームについての詳細は、個別の項目を確認します。
Red Hat Gluster Storage Console
Red Hat Gluster Storage 3.4 の時点で、既存の Red Hat Gluster Storage Console 管理インフラストラクチャーは、現在の Red Hat Gluster Storage 3.x からサポートされています。これは 2019 年 10 月 31 日に終了します。Red Hat Gluster Storage Web 管理が、Red Hat Storage Gluster クラスター用に推奨されるモニタリングツールになりました。
Red Hat Gluster Storage のライフサイクルの詳細は、「Red Hat Gluster Storage Life Cycle」を参照してください。
Red Hat Gluster Storage Web Administration Guide の場合は、『Red Hat Gluster Storage Web Administration Quick Start Guide』および『Red Hat Gluster Storage Web Administration Monitoring Guide』を参照してください。
Nagios Monitoring
Red Hat Gluster Storage 3.4 の時点で、Nagios は非推奨とみなされています。Nagios プラグインおよび Nagios サーバーは維持されなくなり、Red Hat Gluster Storage 3.4 のリリースで提供されません。Nagios は本リリースで引き続きサポートされますが、Red Hat では使用を推奨せず、今後のバージョンの Red Hat Gluster Storage でサポートを廃止する予定です。
Nagios は、gluster クラスターの結果のモニタリングおよび集約の機能に制限があるため、非推奨となりました。これらの制限は、Red Hat Gluster Storage Web の管理で対応しています。
Red Hat Gluster Storage ユーザーは、クラスターを監視するために Red Hat Gluster Storage Web 管理をセットアップする必要があります。Nagios で収集されるデータの移行パスはありません。
Red Hat Gluster Storage Web Administration Guide の場合は、『Red Hat Gluster Storage Web Administration Quick Start Guide』および『Red Hat Gluster Storage Web Administration Monitoring Guide』を参照してください。
gstatus コマンド
gstatus は非推奨となりました。gstatus コマンドは、Red Hat Gluster Storage クラスターおよびボリュームの正常性の概要を提供していました。Red Hat Gluster Storage クラスターおよびボリュームの正常性を表示するには、Web Administration 環境に統合されている Grafana ダッシュボードにアクセスします。
Parallel NFS (pNFS)
Red Hat Gluster Storage 3.4 の時点で、Parallel NFS はサポートされておらず、テクノロジープレビューとして利用できなくなりました。安定性に影響を及ぼす、この機能の長期的な問題は、アップストリームで未解決のままです。この機能の使用に関する情報は、Red Hat Gluster Storage 3.4 から削除されましたが、テクノロジープレビューとして Parallel NFS を提供したリリースのドキュメントで引き続き参照できます。

第3章 主なバグ修正

本章では、ユーザーに大きな影響を及ぼす Red Hat Gluster Storage の今回のリリースで修正されたバグについて説明します。
注記
ハイパーリンクの付いていない Bugzilla ID は、機密データが割り当てられている可能性のあるプライベートバグです。

arbiter

BZ#1401969
以前は、並行 I/O の実行中にブリックが特定の順序でダウンした場合に、arbiter ブリックがデータの修復のソースになっていました。これにより、arbiter ブリックにメタデータのみを保存するため、データが利用できなくなります。今回の修正により、arbiter ブリックがソースとしてマークされなくなりました。
BZ#1446125
SMB を使用してエクスポートされた Red Hat Gluster Storage ボリュームは、Finder で macOS クライアントにマウントできるようになりました。

bitrot

BZ#1519740
以前のバージョンでは、BitRot バージョンの内部拡張属性が AFR に渡され、ファイルで誤ったメタデータの自己修復が実行されていました。今回の修正により、属性がビットロットで除外されるようになりました。これにより、これらのサンプルとログファイル内の適切なメッセージを防ぎます。
BZ#1517463
scrub-throttle または scrub-frequency を設定すると、成功したすべての BitRot 操作 (enable、disable、または scrub オプション) の出力がボリュームビット rot として表示されます。srub-frequency は、ボリューム VOLUME_NAME に対して適切に FREQUENCY に設定されます。

common-ha

BZ#1226874
以前のリリースでは、設定が失敗しても、NFS-Ganesha 起動スクリプトは ganesha プロセスをクリーンアップしませんでした。したがって、’gluster nfs-ganesha enable’ コマンドが失敗しても、ganesha プロセスはノードで引き続き実行されていました。今回の修正により、’gluster nfs-ganesha enable’ コマンドが失敗し、プロセスがクリーンアップされる際に ganesha プロセスがノードで停止されるようになりました。

コア

BZ#1324531
以前のバージョンでは、trash ディレクトリー機能が無効でも、ユーザーはボリューム上に trash ディレクトリーを作成できました。ユーザーには、マウントポイントから trash ディレクトリーを削除するパーミッションがありませんでした。今回の修正により、trush ディレクトリー機能が有効になっている場合にのみ、trush ディレクトリーを作成できるようになりました。また、これにより、ユーザーは機能が無効であってもこのディレクトリーを削除できます。
BZ#1446046
ssl-cert-depth オプションパラメーターを設定するには、/etc/glusterfs/glusterd.vol に設定する必要がありますが、パッチパラメーター transport.socket.ssl-cert-depth の適用後は /var/lib/glusterd/secure-access で設定する必要があります。このパラメーターは、管理 Secure Sockets Layer が有効な場合にのみ役立ちます。
BZ#1484446
一部の gluster デーモン (glustershd など) は、大量のデータ/エントリーを修復している間に高い CPU およびメモリーを消費します。これは、control-cpu-load.sh スクリプトを実行して解決できます。このスクリプトは、gluster デーモンによる CPU およびメモリー消費の調整を行うためにグループを制御します。
BZ#1559886
以前では、クライアントのダンプ中に inode のディクショナリーが client_table ロック下で冗長にアクセスされていました。この動作により、gluster ボリュームのステータス inode が brick を停止していました。今回の修正により、client_table ロックの下にある inode ディクショナリーが冗長に設定されなくなりました。

disperse

BZ#1561733
以前のバージョンでは、lookup-optimize を有効にすると、特別なリバランス要求によって返された不完全なデータが原因で、一部のファイルが分散ボリューム上で移行されませんでした。今回の修正により、必要なデータがすべて転送され、すべてのファイルが移行されるようになりました。
BZ#1499865
この機能は、Erasure Coded ボリュームでの破棄操作のサポートを実装します。この操作を使用すると、ファイル内のブロックの割り当てを解除することができます。指定の範囲内で、部分的なフラグメントはゼロ化され、フラグメント全体が割り当てられます。
BZ#1459101
以前は、FOP が同じファイルのオフセットに重複しない範囲を変更することで、書き込み FOP のパフォーマンスに影響がありました。この動作により、特にブリックが遅いと、各 FOP の応答時間が長くなります。並列書き込み機能の実装により、FOP のパフォーマンスが大幅に向上しました。
BZ#1509830
自己修復時にブリックで xattr 更新操作を実行するように分散トランスレーターが最適化され、パフォーマンスが向上します。
BZ#1530519
Red Hat Gluster Storage 3.4 では、通常のファイルで eager-lock を有効にした新たなオプション ’other-eager-lock’ が導入されましたが、ディレクトリーアクセスでは無効になっています。以前では、ファイルアクセスのパフォーマンスを加速するために eager-lock オプションが使用されていました。ただし、このオプションが有効な場合は、ディレクトリーアクセスに問題が発生していました。
BZ#1555261
問題が原因で、ブリックを置き換えるか、オンラインで失敗したブリックの取得に失敗した後、自己修復による修復プロセスでの遅延が発生します。今回の修正により、保留中のすべてのファイルが完全に修復されるまで、自己修復をアクティブにできるようになりました。
BZ#1611151
ロック競合の遅延により、2 つのクライアントが EC ボリュームの同じディレクトリーにアクセスすると、Ls や 名前変更のようなエントリー fops が遅くなっていました。そのため、ディレクトリーやその他のエントリー操作のリストが遅くなっていました。この問題は、このバージョンの RHGS では解決されています。

distribute

BZ#1550315
以前は、分散ボリュームでは、停止、起動コマンドの実行後、または新しいブリックの追加時にディレクトリーのカスタム拡張属性値が正しく指定されていました。DHT は拡張属性値の同期に失敗しました。本リリースでは、ディレクトリーのカスタム xattrs の更新時に参照される新しいボリュームが導入されました。
BZ#1463114
省略されたファイルが、MSGID: 109126 でリバランスログに記録されるようになりました。ユーザーは、メッセージ ID を使用して省略されたファイルのリストを検索できます。
BZ#1550771
gluster ボリュームのディレクトリーの名前を変更すると、ボリュームのすべてのブリックのディレクトリーの名前が変更されます。1 つ以上のブリックで名前を変更すると、ブリックに古い名前と新しい名前の両方を持つディレクトリーがブリックに表示されます。これにより、これらのディレクトリーのコンテンツの一部がマウントポイントからアクセスできなくなります。今回の修正により、ブリックで失敗した場合にディレクトリーの名前変更操作がロールバックされるようになりました。
BZ#1118770
以前は、名前が変更されていたディレクトリーのルックアップにより、ボリュームに以前の名前および新しい名前の両方のディレクトリーが存在する可能性がありました。これにより、マウントポイントからこれらのディレクトリーのコンテンツにアクセスできなくなる可能性がありました。これを防ぐために、追加の同期が導入されました。
BZ#1392905
リバランスプロセス中に、ハードリンクがスキップ済みとマークされるのではなく、失敗と報告されていました。今回の修正により、リバランス操作中にスキップされた一覧に追加される代わりに、ハードリンク移行の失敗が認識されるようになりました。
BZ#1557365
今回の更新で、lookup-optimize オプションがデフォルトで有効化されるようになりました。このオプションはルックアップと作成パフォーマンスを向上します。
BZ#1577051
以前のバージョンでは、remove-brick プロセスでは、ルックアップの失敗時に不具合が現れていませんでした。残りのファイルについて remove-brick commit を実行する前に、使用停止を確認することが推奨されます。今回の修正により、remove brick のステータスに失敗数が表示されるようになりました。

eventsapi

BZ#1466122
以前のバージョンでは、gluster-events デーモンは、webhook が https が有効な場合に、登録済みの Webhook にイベントを送信できませんでした。今回の修正により、gluster-events デーモンは https が有効な場合に Webhook を登録するようになりました。
BZ#1466129
以前のバージョンでは、Gluster は Webhook にプッシュされたイベントに HMAC 署名 (ハッシュベースのメッセージ認証コード) を追加しませんでした。今回の修正により、gluster-event デーモンは HMAC トークンを生成し、これを Webhook に送信する間にこれを承認ヘッダーに追加するようになりました。

fuse

BZ#1508999
subdir がマウントされたクライアントでは、add-brick の実行時にディレクトリー構造を修復できません。これは、自己修復の実行中にサブディレクトリーの親ディレクトリーがわからないためです。これを修正するには、add-brick の後にいずれかのサーバーにボリュームをマウントし、ディレクトリーで自己修復操作を実行します。ユーザーの介入が必要ないように 'hook' スクリプトを使用してこれらのタスクを実行することができます。
BZ#1501013
以前のバージョンでは、Gluster は Webhook にプッシュされたイベントに HMAC 署名 (ハッシュベースのメッセージ認証コード) を追加しませんでした。今回の修正により、gluster-event デーモンは HMAC トークンを生成し、これを Webhook に送信する間にこれを承認ヘッダーに追加するようになりました。

geo-replication

BZ#1568655
以前のバージョンでは、シンボリックリンク (symlinks) が権限のないユーザーによってマスターボリュームの現在のディレクトリーに作成された場合、geo レプリケーションのスレーブボリュームへの同期に失敗していました。symlink でパーミッションを設定する代わりに、仮想ディレクトリー .gfid への symlink を逆参照するために使用され、geo レプリケーションは Operation not supported エラーで失敗しません。今回の修正により、geo レプリケーションはファイルのパーミッションを設定する際にシンボリックリンクを逆参照せず、権限のないユーザーが作成したシンボリックリンクを現在のディレクトリーに同期するようになりました。
BZ#1288115
Red Hat Gluster Storage 3.4 では、以下のコマンドを使用して、gluster ボリュームで読み取り専用アクセスを付与するオプションが提供されます。 
#gluster volume set VOLNAME features.read-only on
このオプションは、geo レプリケーション以外の他のクライアントでデータをスレーブボリュームに書き込む必要がある場合に、geo レプリケーションで有用です。
BZ#1468972
Red Gluster Gluster Storage 3.4 では、ログメッセージを改善するために、geo レプリケーションに構造化ロギングが導入されました。構造化ロギングを使用すると、ログメッセージを簡単に解析して必要な情報を取得できます。
BZ#1599037
以前のバージョンでは、geo レプリケーションが Faulty 状態から開始または復元されると、処理に必要な xsync changelogs が再生成されていました。stop または restart 操作の前に生成された同期されていない xsync の changelogs は処理されませんでした。これにより、inode および領域が使用されていました。今回のリリースにより、geo レプリケーションが再起動または Faulty 状態から回復するたびに同期されていない変更ログを処理しなくなり、領域と inode は消費されなくなりました。
BZ#1342785
以前は、シンボリックリンク (symlink) ファイルで所有権などのメタデータの変更により、Permission Denied エラーでクラッシュしていました。今回のリリースにより、geo レプリケーションがシンボリックリンクファイルのメタデータを同期するように修正され、symlink ファイルの所有権の変更がクラッシュせずに適切に複製されるようになりました。
BZ#1470967
geo レプリケーションは、GFID がプライマリーボリュームおよびセカンダリーボリュームで同じであることを想定します。ただし、geo レプリケーションは、すでに GFID を使用してファイルがすでに存在する場合にスレーブボリュームへのエントリーの同期に失敗しました。今回のリリースにより、GFID の不一致の失敗はマスターボリュームで確認して処理されるようになりました。
BZ#1498391
geo レプリケーションは changelog 機能を使用し、geo レプリケーションセッションの作成の一部として有効にします。ただし、changelog を無効にするコマンドは、既存の geo レプリケーションセッションについてユーザーに警告しませんでした。今回のリリースにより、changelog を無効にしている間に、geo レプリケーションセッションチェックが追加されました。したがって、changelog を無効にする際に、既存の geo レプリケーションセッションに関する警告が生成されます。
BZ#1503173
geo レプリケーションは、プライマリーとセカンダリーボリュームを内部でマウントしてデータを同期するため、マウントポイントをデバッグできませんでした。その結果、ユーザーはクライアントボリュームプロファイル情報の取得に失敗しました。今回の修正により、ユーザーが geo レプリケーションマウントポイントにアクセスするための 2 つの新しいオプションが導入されました。slave_access_mount (セカンダリーマウントポイント)、master_access_mount (プライマリーマウントポイント)。
BZ#1557297
以前は、geo レプリケーションは、権限のないユーザーが一時停止したり、再開したりすることができました。その結果、スナップショットの作成操作が失敗していました。今回のリリースにより、承認されていないユーザーによって地理レプリケーションセッションを一時停止または再開します。セッション作成者は制限され、Geo-replication session between USERNAME and SLAVE_HOSTNAME does not exist というエラーメッセージが表示されます。
BZ#1565399
以前のバージョンでは、シンボリックリンク (symlinks) が特権のないユーザーによってプライマリーボリュームの現在のディレクトリーを参照して作成された場合、geo レプリケーションのセカンダリーボリュームへの同期に失敗していました。symlink でパーミッションを設定する代わりに、仮想ディレクトリー .gfid を参照する symlink を逆参照し、エラーがオペレーションがサポートされないエラーで失敗していました。今回の修正により、geo レプリケーションはファイルのパーミッションを設定する際に symlinks を逆参照せず、権限のないユーザーが作成した symlink を現在のディレクトリーに同期するようになりました。
BZ#1601314
以前は、シンボリックリンク (symlink) を作成して名前を変更し、元のシンボリックリンクと同じ名前でディレクトリーを作成すると、同期においてファイルの順序が失われていました。これにより、名前を変更 (または symlink の名前変更) せずに、ディレクトリーが最初に同期されていました。これにより、geo レプリケーションが名前を変更したシンボリックリンクの同期に失敗することがありました。
今回のリリースにより、順不同のファイル名変更操作の処理中に、ファイル名がすでに存在する場合、ユーザーは GFID を使用してファイルの ID を確認し、それに応じて同期できるようになりました。

samba

BZ#1379444
以前のバージョンでは、smb.conf ファイルに shadow_copy2 vfs オブジェクトが指定されている場合に、gluster ボリュームのサブディレクトリーの共有が、I/O エラーで失敗していました。これは、gluster ボリュームがリモートファイルシステムであるため発生していました。また、shadow_copy2 がローカルファイルシステムの共有パスのみを検出していました。今回の更新で、shadow:mountpath の値を / に強制し、マウントポイントの検出に関連するコードをスキップし、問題の発生を防ぐようになりました。今回の修正で、glusterfs vfs オブジェクトが、smb.conf ファイルの shadow_copy2 vfs オブジェクトの後に一覧表示されるようになりました。

NFS-ganesha

BZ#1480138
NFS-Ganesha は、ロック要求ごとに異なるファイル記述子を内部で使用します。クライアントが特定のファイル記述子を持つファイルを削除すると、同じファイル記述子を持つ同じファイルにアクセスしようとしている他のクライアントは、No such file or directory エラーを受け取ります。今回のリリースにより、ロックリクエストは、オープン呼び出しから取得した同じファイル記述子を使用し、ロック処理パスでの追加のオープン呼び出しが必要なくなりました。
BZ#1514615
NFS のバージョンを 3 および 4.0 に制限するために、NFSv4 ブロックが ganesha.conf ファイルに手動で追加されました。今回のリリースにより、これらのオプションは ganesha.conf ファイルにデフォルトとして追加されるようになりました。
BZ#1481040
現在、upcall ポーリングのデフォルトの間隔は 10 マイクロ秒です。スレッドの数が多いと、CPU の使用率が高くなります。今回のリリースにより、デフォルトのポーリング間隔が 100 ミリ秒 (100000 マイクロ秒) に増えました。これにより、CPU 使用率が減りました。
BZ#1545523
以前のバージョンでは、クライアントが create 呼び出しで SET_ATTR_MODE を要求すると、NFS サーバーは setattr 操作の事後作成の実行が必要でした。gluster NFS サーバーの場合、setattr 操作に使用される GFID は NULL であり、その結果 EINVAL エラーが生じました。今回のリリースにより、リンクされたノードから GFID を使用でき、SET_ATTR_MODE を使用した create 呼び出しを正常に実行できるようになりました。
BZ#1489378
今回のリリースにより、標準の readdir の代わりに強化された readdirp を有効にする USE_GLUSTER_XREADDIRPLUS オプションが導入されました。このオプションはデフォルトで有効になっています。このオプションをオフにすると、NFS は標準の readdir にフォールバックします。このオプションをオフにすると、クライアントからルックアップおよび stat 要求が送信され、パフォーマンスに影響する可能性があります。
BZ#1516699
Red Hat Gluster Storage 3.4 では、NFS-Ganesha ログファイルが /var/log/ganesha サブディレクトリーに移動しました。

glusterd

BZ#1449867
以前では、ノードの再起動時には、glusterd サービスの開始前にネットワークインターフェースが完全に機能しなくなると、glusterd が異なるピアのブリックアドレスを解決できず、glusterd サービスが開始できませんでした。今回のリリースにより、ネットワークインターフェースが完全に機能していなくても、glusterd の初期化に失敗しませんでした。
BZ#1599823
以前は、ボリューム作成操作時に、glusterd は、brick パスがすでに別のボリュームの一部であるかどうかを確認する際に、空の実際のパスを処理できませんでした。したがって、ボリュームの作成要求は失敗しました。今回のリリースで、パス比較ロジックが修正されました。今回のリリースより、glusterd は空のパスを処理し、ボリューム作成要求の失敗を回避できるようになりました。
BZ#1575539
Red Hat Gluster Storage 3.4 で、gluster ボリュームの geo レプリケーションステータス操作中に glusterd でメモリーリークが発生しました。
BZ#1369420
以前は、glusterd サービスを再起動すると、ポート 61000 の AVC 拒否メッセージが表示されていました。今回のリリースで、61000 未満の glusterd.vol に max-port を設定すると、AVC 拒否メッセージが表示されなくなります。
BZ#1529451
以前は、gluster volume status コマンドを複数回実行すると、glusterd プロセスによるメモリー消費量が過剰になっていました。今回のリリースで、この問題が修正されました。
BZ#1474745
Red Hat Gluster Storage 3.4 では、glusterd.vol に max-port の値を定義して、gluster ブックックが消費可能なポートの範囲を制御できます。

ロック

BZ#1507361
以前は、gluster volume clear-locks コマンドは取得したメモリーを完全に解放できませんでした。これにより、ブリックプロセスのメモリー使用率が徐々に増大していました。今回の修正により、clear-locks コマンドの実行時に関連するメモリーがリリースされるようになりました。
BZ#1510725
gluster volume clear-locks volname コマンドを使用してボリュームの古いロックを消去すると、ロックが破棄された後も、ロックへの参照の 1 つがメモリー内に留まります。クライアントから切断すると、無効なメモリーにアクセスし、クラッシュが発生します。今回のリリースにより、ロックへの最終参照が clear-locks コマンドの一部としてクリアされるため、操作によってメモリーアクセスが不合格になりました。
BZ#1495161
以前は、複数の POSIX ロックを使用するプロセス (gluster clear-locks コマンドとの組み合わせ) が原因で、ブリックプロセスでメモリーリークが発生していました。場合によっては、OOM killer エラーがトリガーされました。今回のリリースにより、トランスレーターに存在するリークに関連する問題が修正されました。

VDSM

BZ#1503070
VDSM パッケージがアップストリームバージョン 4.19 にアップグレードされ、以前のバージョンに対するバグ修正および機能拡張が数多く追加されました。今回の更新で、クラスターの互換バージョン 4.1 を持つ Red Hat Gluster Storage 3.4 ノードが Red Hat Virtualization によって管理されるようになりました。
BZ#1542859
VDSM からの応答に ’device’ フィールドが含まれていない場合、ovirt-engine はデータベースを更新しないため、ステータス情報が管理ポータルに表示されていました。今回の修正により、デバイスフィールドが VDSM 応答の一部であるようになり、brick ステータスが管理ポータルで正確に反映されるようになりました。

posix

BZ#1464350
POSIX トランスレーターが強化され、ユーザーはブリックでディスク領域を予約できるようになりました。ストレージの拡張やノード全体でデータのリバランスなど、一部の管理操作では、ディスク上に十分な作業領域が必要になります。storage.reserve オプションを使用すると、バックエンドブリックが満杯になる場合に、ユーザーがディスクまたはクラスターを拡張することができ、マウントポイントでの ENOSPC エラーを回避できます。
BZ#1620765
以前は、linkto ファイルに設定されている xattr の値が正しくないため、linkto ファイルの名前を変更できませんでした。これは、glusterfind が使用されているボリュームで確認されました。その結果、ボリュームで lookup-optimize オプションが有効になっていると、ファイルにアクセスできませんでした。今回の修正により、linkto ファイルに設定された xattr の値が変更を続行することができるようになりました。

protocol

BZ#1319271
以前は、auth.allow または auth.reject オプションは、FQDN が指定されている場合にホスト名を値として受け入れませんでした。今回の修正により、これらのオプションは FQDN で指定された場合にホスト名を受け入れるようになりました。

quota

BZ#1414456
以前のバージョンでは、symlink リンクファイルに複数のハードリンクがある場合には、追加のパスが正しく設定されていませんでした。これにより、エントリーヒールが保留されていました。今回の修正により、複数のハードリンクを含むシンボリックリンクファイルのシナリオを処理することで、上位が生成されます。
BZ#1475779
以前では、ディレクトリーのクォータが add-brick の前にハード制限を超過している場合に、ディレクトリーは、add-brick 操作に修復したポストを与えられませんでした。その結果、新たに追加したブリックでは、ディレクトリー構造が不完全のままになっていました。今回の修正により、ディレクトリーは、生成されるクォータ制限に関係なく機能するようになりました。
BZ#1557551, BZ#1581231
以前のバージョンでは、クォータがボリュームで有効になっていた間、クォータ使用値はクライアントのマウントポイントからルックアップが実行されるまで list コマンドに更新されませんでした。このため、クロール操作を実施した後も、ファイルサイズの報告が正しくありませんでした。今回の修正により、クロール操作がすべてのファイルを検索し、使用される正確なクォータを報告するようになりました。
BZ#1511766
以前のバージョンでは、quota.conf ファイルの読み書き方法の制限により、ボリュームに 7712 を超える制限を設定することができませんでした。今回の修正により、1 つのボリュームに 65000 を超える制限を設定できるようになりました。

readdir-ahead

BZ#1463592
parallel-readdir ボリュームオプションはトランスレーターの一部ではありませんでした。このため、’parallel-readdir’ が有効な場合に、クライアントログに以下の警告メッセージが表示されました。「option 'parallel-readdir' is not recognized」。今回の修正により、parallel-readdir が readdir-ahead translator のオプションとして追加され、警告メッセージがクライアントログに表示されなくなりました。
BZ#1559884
gluster ボリュームに以下の組み合わせがある場合、readdir 操作を実行した後、一部のファイルがマウントポイントに 2 回表示されていました。以下のボリュームオプションの組み合わせにより、「performance.stat-prefetch off performance.readdir-ahead on performance.parallel-readdir on」エラーが発生していました。今回の修正により、readdir がマウントポイントで発行されても、単一ファイルに重複したエントリーが表示されなくなります。

replicate

BZ#1286820
Red Hat Gluster Storage 3.4 では、summary コマンドが導入されました。このコマンドは、スプリットブレインで待機しているエントリーの統計と、修復中のエントリーを表示します。
BZ#1413959
今回のリリースで、GFID スプリットブレインは、どのポリシー (brick、mtime、または size) を使用して CLI から解決できるようになりました。GFID 修復が必要なファイルの絶対パスを指定する必要があります。
BZ#1452915
以前は、heal disable コマンドを使用して修復デーモンを無効にした場合は、gluster volume heal volname コマンドを使用して修復を手動でトリガーする必要がありました。heal コマンドは、正しくないエラーメッセージや誤解を招くエラーメッセージが表示されていました。今回の修正により、無効なデーモンで手動修復をトリガーしようとすると、ユーザーに対し、修復をトリガーするためにはこのデーモンを有効にするように指示するエラーメッセージが表示されました。
BZ#1489876
レプリカ 2 ボリュームはスプリットブレインが発生する可能性があるため、Red Hat Gluster Storage 3.4 の今後のリリースで非推奨になります。したがって、レプリカ 2 ボリュームの作成時には、Abiter またはレプリカ 3 の設定を使用することを推奨する適切な警告メッセージが表示されます。
BZ#1501023
以前は、AFR が choose-local オプションの再設定を処理しないため、choose-local オプションの再設定に使用した volume-set コマンドが想定どおりに機能していませんでした。今回の修正により、AFR ハンドルが選択ローカルオプションを再設定するように適切な変更が加えられました。
BZ#1593865
glusterd は、後者のグラフが完全に初期化される前に、ホストに関連するリクエストを自己修復デーモンに送信できます。この場合、特定のデータ構造にアクセスしようとする際にクラッシュするために使用される自己修復デーモン。この修正により、自己修復デーモンがグラフを初期化する前に要求を受信すると、リクエストを無視します。
BZ#1361209
以前は、heal disable コマンドを使用して修復デーモンを無効にした場合は、gluster volume heal volname コマンドを使用して修復を手動でトリガーする必要がありました。heal コマンドは、正しくないエラーメッセージや誤解を招くエラーメッセージが表示されていました。今回の修正により、無効なデーモンで手動修復をトリガーしようとすると、ユーザーに対し、修復をトリガーするためにはこのデーモンを有効にするように指示するエラーメッセージが表示されました。
BZ#1470566
ユーザーは、クライアントで I/O が発生していない場合に、’gluster volume add-brick’ コマンドを実行することで、プレーンな分散ボリュームを分散複製ボリュームに変換できるようになりました。
BZ#1552414
レプリカ 3 ボリュームでは、複数のクライアントが、重複のないリージョンで同じファイルにデータを同時に書き込むと、スプリットブレインで終了する可能性がありました。新しい cluster.full-lock オプションを使用すると、ファイルロックを完全にできます。これにより、データの一貫性を維持し、スプリットブレインで終了しないようにすることができます。デフォルトでは、cluster.full-lock オプションは完全なファイルロックを取得するように設定され、必要に応じて範囲ロックを取得するように再設定できます。
BZ#1566336
以前は、レプリカ 3 ボリュームのブリックでファイル作成に成功すると、保留中の changelog がそのファイルの新しいエントリーマークの一部として設定されていました。エントリートランザクションがブリックのクォーラム数で失敗したため、親ファイルにはエントリー保留中の changelog が設定されていません。その結果、エントリートランザクションは修復情報の出力に一覧表示されますが、SHD クロールやインデックス修正では回復されません。今回の修正により、ブリックのクォーラム数でエントリートランザクションが失敗すると、トランザクションが成功したブリックの親ファイルにダーティーマークが設定されます。このアクションにより、次の SHD クローまたはインデックス修復の一部としてエントリーを修復できます。
BZ#1397798, BZ#1479335
glustershd などの一部の gluster デーモンは、修復するデータやエントリーが多くなると、CPU またはメモリーの消費量が高くなります。これにより、リソースの消費が遅くなっていました。今回の修正により、ユーザーは control-cpu-load.sh スクリプトを実行してリソースの低速な消費を解決できるようになりました。このスクリプトは、gluster デーモンの CPU およびメモリー消費を調整するコントロールグループを使用します。

rpc

BZ#1408354
この機能は、ソケットごとに TCP のキープアライブ機能タイミングを制御します。ユーザーがデプロイしたアプリケーションには、システムコールのレイテンシーに関する前提条件がありました。gluster をファイルシステムとして使用すると、既存のシステム呼び出しレイテンシーにさらにネットワークレイテンシーが加わります。これらの gluster オプションをユーザーが使えることで、TCP ソケットが切断として想定される許容範囲のネットワークレイテンシーを超えてアプリケーションを微調整するのに役立ちます。これらのオプションに割り当てられるデフォルト値は、そのようなオプションが明示的に設定されていない場合に、システムのデフォルトの値にすべての TCP ソケットを設定します。ユーザーが利用できる gluster ボリュームオプションは、以下のとおりです。
  • server.tcp-user-timeout
  • client.tcp-user-timeout
  • transport.socket.keepalive-interval
  • transport.socket.keepalive-count
  • server.tcp-user-timeout
これらのオプションは、TCP(7) man ページで説明されている同様のオプションと 1:1 の互換性があります。この機能により、より優れたユーザーエクスペリエンスが得られるようにアプリケーションの動作を微調整するメカニズムが提供されます。

snapshot

1464150
GlusterFS は、デフォルトで /run/gluster/snaps の下に非アクティブなスナップショットをマウントするために使用されます。スナップショットのステータスコマンドは、非アクティブなスナップショットの関連情報を表示します。マウントが存在するため、スナップショットの削除中にボリュームのマウントを解除している間に、一部のプロセスがマウントに問題を引き起こす可能性があります。この機能により、GlusterFS が、非アクティブなスナップショットをマウントせず、スナップショットのステータスコマンド用の Volume Group フィールドに N/A(Deactivated Snapshot) のテキストが表示されません。

vulnerability

BZ#1601298
glusterfs サーバーが、trusted.io-stats-dump トランスレーターが使用する debug/io-stats 拡張属性のファイルパスを適切にサニタイズしないことが確認されました。攻撃者はこの脆弱性を使用してファイルを作成し、任意のコードを実行できます。これを悪用するにあたり、攻撃者は gluster ボリューム上のファイルの拡張属性を変更するのに十分なアクセスが必要です。
BZ#1601642
glusterfs サーバーは、server-rpc-fopc.c の関数により、alloca(3) を使用して固定サイズバッファーを割り当てることで、複数のスタックベースのバッファーオーバーフローに対して脆弱であることが発見されました。認証された攻撃者は、gluster ボリュームをマウントし、固定バッファーサイズで文字列を送信してクラッシュやコード実行を発生する可能性があります。
BZ#1610659
mknod(2) から派生した mknod 呼び出しにより、glusterfs サーバーノード上のデバイスを参照するファイルを作成できることが確認されました。認証された攻撃者は、これを使用して任意のデバイスを作成し、glusterfs サーバーノードに接続されているデバイスからデータを読み取ることができます。
BZ#1612658
glusterfs サーバーで gfs3_lookup_req を使用する RPC リクエストで不具合が発見されました。認証された攻撃者は、この脆弱性を使用して情報を漏えいし、gluster brick プロセスをクラッシュさせてリモートサービス拒否を実行する可能性があります。
BZ#1612659
glusterfs サーバーの gfs3_symlink_req を使用した RPC リクエストで不具合が発見されました。これにより、シンボリックリンク (symlink) の宛先が、gluster ボリューム外部のファイルパスを参照できるようになります。認証された攻撃者はこの脆弱性を利用してサーバー上のどこにでもポイントする任意のシンボリックリンクを作成し、glusterfs サーバーノードで任意のコードを実行する可能性があります。
BZ#1612660
glusterfs サーバーで gfs2_create_req を使用する RPC リクエストで不具合が発見されました。認証された攻撃者はこの脆弱性を利用して任意のファイルを作成し、glusterfs サーバーノードで任意のコードを実行する可能性があります。
BZ#1612664
glusterfs サーバーの gfs3_rename_req を使用した RPC リクエストで不具合が発見されました。認証された攻撃者は、この脆弱性を使用して、gluster ボリューム外部の宛先に書き込む可能性があります。
BZ#1613143
glusterfs サーバー処理でサポートされる gfs3_mknod_req を使用した RPC リクエストで不具合が発見されました。認証された攻撃者は、この脆弱性を使用してパストラバーサルを介して任意の場所にファイルを書き込み、glusterfs サーバーノードで任意のコードを実行する可能性があります。
BZ#1601657
glusterfs の dict.c:dict_unserialize 関数が鍵の長さの負の値を処理しない不具合が見つかりました。攻撃者はこの脆弱性を利用して、他の場所から、保存された dict 値へのメモリーを読み取ることができます。
BZ#1607617
攻撃者は、glusterfs FUSE による xattr リクエストを発行して、gluster brick プロセスをクラッシュさせ、リモートのサービス拒否を発生させる可能性があることが判明しました。gluster の多重化を有効にすると、複数のブリックボリュームと gluster ボリュームがクラッシュします。
BZ#1607618
glusterfs サーバーで情報公開の脆弱性が発見されました。攻撃者は、glusterfs FUSE による xattr リクエストを発行し、任意のファイルの存在を判断することが可能でした。

write-behind

BZ#1426042
performance.write-behind-trickling-writes および performance.nfs.write-behind-trickling-writes オプションにより、FUSE および NFS クライアントの write-behind トランスレーターの trickling-write ストラテジーが可能になります。

Web Administration

BZ#1590405
raterl-ansible はデフォルトで yum update を実行するため、関係するすべてのシステムが最新のパッケージで更新されます。したがって、OS とサービスの意図しないパッチが発生します。これは、実稼働システムには望ましくありません。
likelyrl-ansible による意図しないパッケージの更新を避けるには、Ansible Playbook から yum update 変数をドロップします。
BZ#1518525
以前のバージョンでは、Red Hat Gluster Storage Web Administration のインストール時に、サーバーに複数のアクティブな IP アドレスがある場合、teamrl-ansible は正しい IP アドレスを自動的に選択できず、インストールが失敗していました。このバージョンでは、インストール手順に従って、payrl-ansible に必要な変数をすべて設定する必要があります。
BZ#1563648
以前のバージョンでは、中央ストア (etcd) のオブジェクト詳細を維持する際の infra レベルで、各フィールドを個別に記述されることで、etcd に複数の REST API 呼び出しが発生していました。
オブジェクトを etcd に永続化するこの手法により、複数の REST API 呼び出しがトリガーされ、大量のネットワーク呼び出しが発生していました。また、これは、保存スレッドが依然としてデータを etcd に書き込む間、他のスレッドがオブジェクトの更新を試行する際に競合状態になるために使用されました。
パフォーマンスが改善され、競合状態から離れると、オブジェクト全体が単一の JSON にシリアライズされ、etcd に書き込まれます。etcd からオブジェクトの状態を読み取る間、この単一の JSON は読み取り、詳細を使用してオブジェクトを優先します。
その結果、etcd への各オブジェクトの読み取りおよび書き込み操作により、単一の REST API 呼び出しが可能になりました。また、システムのさまざまなフローで多くの問題を引き起こした重大な競合状態を回避します。
BZ#1512937
Grafana のホストレベルのダッシュボードには、ピアプローブの実行方法に関係なく、特定のストレージノードの FQDN および IP アドレスを持つ重複するホスト名が一覧表示されます。これにより、同じノードの重複データが時系列データと Grafana ダッシュボードに表示されていました。
今回の修正により、ホストレベルのダッシュボードおよびその他のダッシュボードは、Gluster クラスターの作成時にピアプローブに使用された 1 度のみホストの名前を表示するようになりました。
BZ#1514442
以前のバージョンでは、インポートクラスターが Web 管理インターフェースで失敗した場合、UI からインポートを再度開始する方法はありませんでした。ユーザーは、etcd の詳細をクリーンアップし、インポートを再度開始する必要がありました。その結果、同じクラスターのインポート試行が連続して失敗していました。
インポートクラスターの最新の変更と、クラスターとインポートの解除を行う市機能により、コンポーネントのインストールについてストレージノードで設定されたリポジトリーが無効なことで、クラスターに対してインポートクラスターが失敗しても、ユーザーはノードの問題を修正して、クラスターのインポートを再起動することができます。管理外のクラスター操作は、クラスターの管理を解除して再インポートできるため、このワークフローでも役立ちます。インポートジョブは、すべての必要なコンポーネントがすべてインストールされ、最初のラウンドの同期が完了した状態で実行されている場合にのみ正常に実行されます。いずれかのノードが同じ報告に失敗すると、クラスタージョブのインポートに失敗します。
今回の修正により、インポートが失敗すると、ユーザーは基礎となるノードで問題を修正し、クラスターの再インポートを実行できるようになりました。
BZ#1516417
以前のバージョンでは、Web 管理では、gluster 信頼済みストレージプールに追加された新規ストレージノードの検出または拡張を行えませんでした。そのため、Web 管理ではクラスターの初回のインポート後に新たに追加されるノードにメトリクスを提供することができませんでした。
今回の修正により、Web 管理は、gluster 信頼済みストレージプールに新規ノードが追加されると、既存の管理対象クラスターに新規ノードを検出し、拡張できるようになりました。
BZ#1549146
以前のバージョンでは、Grafana ダッシュボードは、パフォーマンスユニットがないさまざまなパフォーマンスパネルについて、現実的で現実的でない値を報告していました。現実的でない数字が表示されるパネルの一部は、週、IOPS、Throughput などでした。
今回の修正により、IOPS や Weeks Remaining パネルを含む Grafana パネルには、適切なパフォーマンスユニットとともにユーザーが理解できる実際の値が表示されるようになりました。さらに、Inode パネルは Grafana の brick-level およびボリュームレベルのダッシュボードから削除されました。
BZ#1516135
以前のバージョンでは、クラスターのいくつかのノードでは、laterl-gluster-integration のインストールの失敗が原因で部分的にインポートされたクラスターの管理を解除する方法はありませんでした。インポートに失敗したにもかかわらず、クラスターは、Web 管理によって正常にインポートされ、管理されているステータスを表示していました。
そのため、Web 管理インターフェースのクラスターの記述は、クラスターのすべてのピアが正常にインポートおよび報告されているわけではないため、正しくありませんでした。
今回の修正により、インポートジョブは、すべてのピアが実行中のピアが実行中の prorl-gluster-integration を報告し、データの同期の最初のラウンドが Web 管理環境で行われる場合にのみ、インポートジョブが終了とマークされるようになりました。管理対象でないクラスター機能を使用すると、影響を受けるクラスターは管理対象外になり、Web 管理環境でクラスターを再インポートする前に根本的な問題を修正できます。
インポートに失敗した場合には、基礎となるクラスターで問題を修正し、Web 管理環境で再インポートできます。
BZ#1519158
以前のバージョンでは、Web 管理インターフェースの Clusters ビューでは、Mozilla Firefox Web ブラウザーでクラスター属性をフィルターするフィルターボタンが応答しなくなっていました。この問題により、ユーザーは特定のクラスター属性に基づいてクラスタービューをフィルターできませんでした。
このブラウザーの問題は本リリースで修正され、Firefox でフィルターボタンが応答するようになりました。

第4章 既知の問題

本章では、リリース時の既知の問題を紹介します。
注記
ハイパーリンクの付いていない Bugzilla ID は、機密データが割り当てられている可能性のあるプライベートバグです。

4.1. Red Hat Gluster Storage

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#1403767
NFS-Ganesha が設定されたマルチノードの設定において、設定に複数のボリュームがあり、そのノードがボリューム停止時と同時に再起動される場合、ノードが起動すると、ボリュームのステータスでは、本来停止であるべきところが起動済み状態として表示されます。
回避策: ボリュームのステータスが started を反映するノードで glusterd インスタンスを再起動すると、この問題は解決されます。
BZ#1417097
glusterd は、設定が遅い場合に初期化に時間がかかります。その結果、/etc/fstab エントリーがマウントされる際に、ノード上の glusterd がそのマウントに対応する準備ができず、glusterd マウントは失敗します。このため、ノードの再起動後に共有ストレージがマウントされない可能性があります。
回避策: ノードの再起動後に共有ストレージがマウントされていない場合は、glusterd が稼働中かどうかを確認し、共有ストレージボリュームを手動でマウントします。
BZ#1394138
umount を実行せずに NFS-Ganesha HA クラスターからノードが削除されてから、そのノードのピアデタッチが実行されると、HA-Cluster のノードを削除しても、そのボリュームは /var/run/gluster/shared_storage/ の場所で引き続きアクセスできます。
回避策: ピアをクラスターからデタッチした後に、そのピアの共有ストレージを手動でアンマウントします。

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

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

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

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

BZ#1426128
複製ボリュームでは、ファイルの作成時に gluster ボリュームスナップショットが作成されると、ファイルはレプリカの 1 つのブリックに存在しますが、スナップショットを作成したボリュームにその他のブリックが存在しない可能性があります。このため、このスナップショットを復元し、マウントからのディレクトリーで rm -rf dir コマンドを実行すると、ENOTEMPTY エラーで失敗する可能性があります。
回避策: rm -rf dir コマンドの実行中に ENOTEMPTY エラーが発生しても、ディレクトリーの ls コマンドの出力にエントリーが含まれない場合は、レプリカのバックエンドブリックを確認して、ファイルが一部のブリックに存在するかどうかを確認します。マウントからファイル名を指定して stat コマンドを実行し、レプリカのすべてのブリックに修復されるようにします。ファイルを完全に修復したら、rm -rf dir コマンドの実行に成功します。

gNFS に関連する問題

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#1561393
geo-rep セカンダリーボリュームで高速な読み込みパフォーマンス機能が有効にされている場合は、まれにキャッシュを無効にできなくなるため、古いデータを提供する可能性があります。これにより、古いデータが供給される可能性があるため、セカンダリーボリュームを読み取るアプリケーションに影響が及ぶ可能性があります。
回避策: セカンダリーボリュームで高速読み取りパフォーマンス機能を無効にします。 
# gluster vol set slave-vol-name quick-read off
高速読み取りパフォーマンス機能が無効になっていると、セカンダリーは古いデータを提供しなくなり、一貫性のあるデータを提供します。
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

replace-brick 操作に関連する問題

  • gluster volume replace-brick VOLNAME Brick New-Brick commit force コマンドを実行すると、その特定ボリュームのファイルシステム操作 (移動中のボリューム) は失敗します。
  • replace-brick 操作後、NFS マウントと FUSE マウントで stat 情報が異なります。これは、replace-brick 操作の実行時に内部のタイムスタンプが変更されたために発生します。

NFS に関連する問題

  • NFS サーバーを再起動すると、grace-period 機能内でロック解除が失敗する可能性があり、ロックが以前に保持されない可能性があります。
  • fcntl ロック (NFS Lock Manager) は IPv6 では機能しません。
  • NFS マウント -o nolock オプションを使用しない限り、glusterfs-NFS プロセスがすでに実行しているマシンで NFS マウントを実行することはできません。これは、glusterfs-nfs がすでに portmapper で NLM ポートを登録しているためです。
  • NFS クライアントが NAT (ネットワークアドレス変換) ルーターまたはファイアウォールの背後にある場合、ロックの動作は予測できません。現在の NLM の実装では、クライアントの IP アドレスのネットワークアドレス移行が発生しないことを想定します。
  • nfs.mount-udp オプションはデフォルトで無効になっています。NFS を使用して Red Hat Gluster Storage ボリュームにマウントする場合は、Solaris で posix-locks を使用するように有効にする必要があります。
  • nfs.mount-udp オプションを有効にする場合は、Linux でサブディレクトリー (nfs.export-dir オプションを使用してエクスポート) をマウントしている間に、-o proto=tcp オプションを使用してマウントする必要があります。UDP は、GlusterFS-NFS サーバー上のサブディレクトリーマウントには対応していません。
  • NFS Lock Manager が適切に機能するには、すべてのサーバーとクライアントに解決可能なホスト名があるようにする必要があります。つまり、サーバーはクライアント名を解決でき、クライアントはサーバーのホスト名を解決できる必要があります。

NFS-Ganesha に関連する問題

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#1330218
異なるクライアント (NFSv3 および NFSv4 クライアントの両方) がボリュームにアクセスしている場合、ノードのシャットダウンにより、NFSv4 クライアントが事後の仮想 IP フェイルオーバーの復元に長い時間がかかることが確認できます。
回避策: アクセスプロトコル (NFSv3 または NFSv4) アクセスに異なる仮想 IP を使用します。
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>)"""
BZ#1381416
変更しているディレクトリーに READDIR が発行されると、要求の一部として送信されたクッキーがすでに削除される可能性があります。このような場合、サーバーは BAD_COOKIE エラーを返します。このため、このようなエラーを処理しない一部のアプリケーション (ボニア test-suite など) はエラーが発生する可能性があります。
これは NFS サーバーの想定される動作で、このようなエラーを修正するにはアプリケーションを修正する必要があります。
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 がコアダンプを生成するのを防ぎます。
回避策: core_dump_enable ファイルで /etc/vdsm/vdsm.conf を 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

オブジェクトストアに関連する問題

  • Unified File および Object Storage の使用中に、GET コマンドおよび PUT コマンドは大規模なファイルで失敗します。
    回避策: プロキシー、コンテナー、およびオブジェクトサーバーの設定ファイルで node_timeout=60 変数を設定する必要があります。

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

BZ#1578703
inode が多数あると、inode ステータスダンプ中に、この反復が長期間ロックされる可能性があります。この動作により、inode ステータスダンプでクライアントコマンドのタイムアウトが発生します。
回避策: 以下のコマンドを実行して、’inode status’ を実行する際に LRU inode を減らします。
小さい値に設定します。 
# gluster v set v1 inode-lru-limit 256
inode ダンプを作成します。 
# gluster v status v1 inode
以前の値に設定します。 
# gluster v set v1 inode-lru-limit 16384
BZ#1286050
ボリュームでは、読み取り操作および書き込み操作が進行中で、同時にリバランス操作が実行され、そのボリュームで remove-brick 操作が実行されると、rm -rf コマンドはいくつかのファイルで失敗します。
BZ#1224153
ブリックプロセスがなくなると、BitD は対応するブリックとの通信に使用されるソケットから読み込みを試みます。失敗すると、BitD はログファイルに障害を記録します。これにより、多くのメッセージがログファイルに置かれ、ソケットからの読み取りに失敗し、ログファイルのサイズが増えます。
BZ#1224162
RPC 対話層で処理されない競合により、ブリックダウンの通知により、データ構造が破損する可能性があります。これにより、NULL ポインターアクセスと segfault が発生する可能性があります。
回避策: Bitrot デーモン (bitd) がクラッシュすると (segfault)、volume start VOLNAME force を使用してクラッシュしたノードで 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#1300572
Linux CIFS クライアントのバグにより、現在 Linux から Red Hat Gluster Storage への SMB2.0+ 接続が適切に動作しません。Linux から Red Hat Gluster Storage への SMB1 接続と、対応のプロトコルとのすべての接続は、引き続き機能します。
回避策: 実用的な場合には、Linux CIFS マウントを SMB バージョン 1 に制限します。最も簡単な方法は、vers mount オプションを指定しないことです。デフォルト設定では SMB バージョン 1 のみを使用するためです。Linux CIFS のマウントを SMB1 に制限することは実用的ではない場合は、smb.conf ファイルで aio read size を 0 に設定して、Samba の非同期 I/O を無効にします。非同期 I/O を無効にすると、他のクライアントのパフォーマンスに影響する可能性があります。
BZ#1282452
ctdb パッケージは現在 samba-debuginfo パッケージと競合するため、ctdb2.5-debuginfo がインストールされていると、ctdb2.5-debuginfo バージョン 4 へのアップグレードは失敗します。
回避策: ctdb バージョン 4 にアップグレードする前に、ctdb2.5-debuginfo パッケージを手動で削除します。必要に応じて、アップグレード後に samba-debuginfo をインストールします。
BZ#1164778
smb.conf の Gluster ボリュームの共有セクションで管理者が実行する変更は、ボリュームの再起動時にデフォルトの Gluster フックスクリプト設定に置き換えられます。
回避策: ボリュームの再起動後に、管理者は全ノードで再度変更を実行する必要があります。

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#1520882, BZ#1568758
多数のシャードが大規模なファイルで削除されると、シャードトランスレーターは同期的にすべてのシャードに対して非リンク操作を並行して送信します。このアクションにより、トランスレーターが複製された状態で、.shard ディレクトリーのロックを並行して取得します。
しばらくすると、ロックの変換に多数のロックが累積され、一致する可能性のあるロックの検索が遅くなるため、完了までに数分かかることがあります。この動作によりタイムアウトが発生して切断されたり、ファイルの削除の後続失敗が発生して、.shard ディレクトリー下に古いシャードが残されます。
回避策: シャードのブロックサイズを 64 MB で、shard-block-size が低いほどタイムアウトの可能性が高くなります。
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#1578308
md-cache および readdir-ahead にキャッシュされる古くなった統計は、アプリケーションからの書き込み操作で更新できません。その結果、アプリケーションは、正常に完了した書き込みを反映しない統計からサイズなどの書き込み操作の影響を認識しません。
回避策: performance.stat-prefetch オプションおよび performance.readdir-ahead オプションにチェックを入れると、アプリケーションは古い統計を受信しなくなります。
BZ#1260119
glusterfind コマンドは、クラスターのいずれかのノードから実行する必要があります。クラスターのすべてのノードが、コマンド開始したノードの known_hosts 一覧に追加されていない場合は、glusterfind create コマンドがハングします。
回避策: ローカルノードを含め、ピアのすべてのホストを known_hosts に追加します。
BZ#1058032
仮想マシンの移行時に、イメージが共有ファイルシステムにあり、必要な所有権がないため、仮想マシンがディスクにアクセスできないことを検出しない限り、libvirt はゲストイメージの所有権を変更します。
回避策: 移行前に、仮想マシンの電源をオフにします。移行が完了したら、VM ディスクイメージ (107:107) の所有権を復元し、仮想マシンを起動します。
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 host:port
回避策: コマンドで host:port が正しいことを確認します。
作成される statedump ファイルは、gfapi アプリケーションを実行しているホストの /var/run/gluster に配置されます。

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 サービスを再起動します。

4.2. Red Hat Gluster Storage と Red Hat Enterprise Virtualization の統合

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

第5章 テクノロジープレビュー

本章では、本リリースで利用可能なテクノロジープレビュー機能の一覧を紹介します。
現在、テクノロジープレビュー機能は Red Hat Gluster Storage サブスクリプションサービスではサポートされていませんが、機能的に完全ではないことがあるため、通常は実稼働環境には適していません。ただし、この機能はお客様の利便性のために含まれており、機能により多くの公開を提供します。
テクノロジープレビューの機能は、本番環境以外の環境で役に立ちます。また、完全にサポートされる前に、テクノロジープレビュー機能に関するフィードバックおよび機能についてのご提案をお寄せください。重大度の高いセキュリティー問題に対するエラータが提供されます。
テクノロジープレビュー機能の開発中に、追加コンポーネントがテスト用に一般利用可能になる場合があります。Red Hat では、今後のリリースでテクノロジープレビュー機能が完全にサポートされる予定です。
注記
Red Hat Enterprise Linux 6.10 および 7.5 のテクノロジープレビュー機能はすべて、Red Hat Gluster Storage 3.4 のテクノロジープレビュー機能として考慮されています。Red Hat Enterprise Linux 6.10 で利用可能なテクノロジープレビュー機能の詳細は、『『Red Hat Enterprise Linux 6.10 テクニカルノート』』の「テクノロジープレビュー機能」の章を参照してください。Red Hat Enterprise Linux 7.5 の場合は、「テクノロジープレビュー機能」を参照してください。

5.1. SMB マルチチャネル

マルチチャンネルは、クライアントが複数のトランスポート接続を認証された SMB セッションにバインドできるようにする SMB バージョン 3 機能です。これにより、Windows 8 以降および Windows Server 2012 以降を実行しているクライアントのフォールトトレランスおよびスループットが向上します。
詳細は、「SMB3 Multi-Channel with Samba on Red Hat Gluster Storage (テクノロジープレビュー)」を参照してください。

付録A 改訂履歴

改訂履歴
改訂 3.4-2Thu Oct 04 2018Red Hat Gluster Storage Documentation Team
第 3 章および 4 章のバグの説明、修正/回避策
改訂 3.4-1Tue Sep 04 2018Red Hat Gluster Storage Documentation Team
Red Hat Gluster Storage 3.4 リリースの更新

法律上の通知

Copyright © 2018 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License.本書、または変更済みのバージョンを配布する場合は、Red Hat, Inc. にコンテンツの帰属を提供し、元のリンクを提供する必要があります。If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent.Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission.We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.