第1章 NFS バックエンドに CephFS を使用した Shared File Systems サービス


NFS バックエンドに Ceph File System (CephFS) を使用した Shared File Systems サービス (manila) により、ブロックストレージおよびオブジェクトストレージ用と同じ Ceph クラスターを使用して、NFS プロトコルを介したファイル共有を提供することができます。詳細は、Storage GuideShared File Systems service を参照してください。

注記

Red Hat OpenStack Platform の全ドキュメントスイートは Red Hat OpenStack Platform の製品ドキュメント で参照してください。

重要

Red Hat OpenStack Platform (RHOSP) 16.0 以降では、NFS バックエンドに CephFS を使用した RHOSP Shared File Systems サービスは、Red Hat Ceph Storage バージョン 4.1 以降との組み合わせがサポート対象の設定です。システムにインストールされている Ceph Storage のバージョンを確認する方法についての詳細は、What are the Red Hat Ceph Storage releases and corresponding Ceph package versions? を参照してください。

CephFS は、高度にスケーラブルな Ceph のオープンソース分散ファイルシステムのコンポーネントで、統一された分散ストレージプラットフォームです。Ceph は、Reliable Autonomic Distributed Object Store (RADOS) を使用してオブジェクトストレージ、ブロックストレージ、およびファイルストレージを実装します。POSIX に対応した CephFS は、Ceph ストレージクラスターへのファイルアクセスを提供します。

Shared File Systems サービスを使用して CephFS にファイル共有を作成し、NFS 4.1 を使用して NFS-Ganesha 経由でそのファイル共有にアクセスすることができます。NFS-Ganesha はファイル共有へのアクセスをコントロールし、NFS 4.1 プロトコルを使用してファイル共有をクライアントにエクスポートします。Shared File Systems サービスは、Red Hat OpenStack Platform (RHOSP) 内からこれらのファイル共有のライフサイクルを管理します。NFS バックエンドに CephFS を使用するようにサービスを設定した場合には、これらのファイル共有は CephFS クラスターから提供されますが、通常の NFS 共有として作成およびアクセスされます。

詳細は、Storage GuideShared File Systems service を参照してください。

1.1. Ceph File System のアーキテクチャー

Ceph File System (CephFS) は分散ファイルシステムで、NFS v4 プロトコルを使用する NFS-Ganesha (サポート対象) または CephFS ネイティブドライバーのいずれかと共に使用することができます。

1.1.1. ネイティブドライバーを使用する CephFS

CephFS ネイティブドライバーは、OpenStack Shared File Systems サービス (manila) と Red Hat Ceph Storage を結び付けます。Red Hat OpenStack (RHOSP) director を使用する場合、コントローラーノードはマネージャー、メタデータサーバー (MDS)、および モニター (MON) などの Ceph デーモンならびに Shared File Systems サービスをホストします。

コンピュートノードは 1 つまたは複数のプロジェクトをホストすることができます。以下の図で白い長方形で表されるプロジェクト (従来はテナントと呼ばれていた) には、ユーザー管理の仮想マシン (2 つの NIC を持つ灰色の長方形で表される) が含まれます。ceph および manila デーモンプロジェクトにアクセスするには、パブリック Ceph ストレージネットワーク経由でデーモンに接続します。このネットワーク上で、Ceph オブジェクトストレージデーモン (OSD) の提供するストレージノードに保管されたデータにアクセスすることができます。プロジェクトがホストするインスタンス (仮想マシン) は、2 つの NIC と共に起動します。1 つの NIC はストレージプロバイダーネットワーク専用で、2 つ目の NIC は外部プロバイダーネットワークに接続するためのプロジェクト所有のルーター専用です。

ストレージプロバイダーネットワークは、プロジェクト上で動作する仮想マシンをパブリック Ceph ストレージネットワークに接続します。Ceph パブリックネットワークは、Ceph オブジェクトストレージノード、メタデータサーバー (MDS)、およびコントローラーノードへのバックエンドアクセスを提供します。

ネイティブドライバーを使用する場合、CephFS では、クォータの適用、確実なプロジェクト間の分離、およびセキュリティー確保のために、クライアントおよびサーバーとの協調が必要になります。ネイティブドライバーを使用する CephFS は、プライベートクラウド上の信頼済みエンドユーザーが定義された環境で適切に機能します。この設定での協調および適切な動作のためには、ソフトウェアはユーザーの管理下で動作している必要があります。

cephfs nfs topology native driver

1.1.2. NFS バックエンドへの CephFS の使用

Shared File Systems サービス (manila) の NFS バックエンドに CephFS を使用する設定には、Ceph メタデータサーバー (MDS)、NFS バックエンドに CephFS を使用するためのゲートウェイ (NFS-Ganesha)、および Ceph クラスターサービスのコンポーネントが含まれます。Shared File Systems サービスの CephFS NFS ドライバーは、NFS-Ganesha ゲートウェイを使用して NFSv4 プロトコルによる CephFS ファイル共有へのアクセスを提供します。Ceph MDS サービスは、ファイルシステムのディレクトリーおよびファイル名を RADOS クラスターに保管されるオブジェクトにマッピングします。NFS ゲートウェイは、Ceph 等の異なるストレージバックエンドを使用して NFS ファイル共有を提供します。NFS-Ganesha サービスは、Ceph サービスと共にコントローラーノード上で実行されます。

インスタンスは、少なくとも 2 つの NIC と共に起動します。1 つの NIC はプロジェクトのルーターに接続され、2 つ目の NIC は StorageNFS ネットワークに接続され、そこから直接 NFS-Ganesha ゲートウェイに接続されます。インスタンスは、NFS プロトコルを使用してファイル共有をマウントします。Ceph OSD ノードがホストする CephFS ファイル共有は、NFS ゲートウェイを通じて提供されます。

NFS-Ganesha により、ユーザーのインスタンスは MDS および他の Ceph サービスに直接アクセスしなくなるので、セキュリティーが向上します。インスタンスは、Ceph デーモンに直接アクセスしません。

cephfs nfs topology nfs driver

ce-client-access-CephFS-architect']

1.1.2.1. Ceph サービスとクライアントアクセス

Ceph がオブジェクトストレージおよびブロックストレージを提供する際にデプロイされるモニター、OSD、Rados Gateway (RGW)、およびマネージャーサービスに加えて、CephFS には Ceph メタデータサービス (MDS) が必要です。また、NFS プロトコルを使用するネイティブ CephFS へのゲートウェイとして NFS-Ganesha サービスが必要です。ユーザーが直接アクセスできるオブジェクトストレージの場合には、RGW サービスもデプロイされます。ゲートウェイは Ceph パブリックネットワークにアクセスするために CephFS クライアントを実行し、エンドユーザーではなくシステムの管理下に置かれます。

NFS-Ganesha は、Ceph パブリックネットワークおよび新たな分離ネットワーク (StorageNFS) の両方とインターフェイスする専用のコンテナー内で実行されます。Red Hat OpenStack Platform (RHOSP) director のコンポーザブルネットワーク機能が、この分離ネットワークをデプロイしてコントローラーノードに接続します。クラウド管理者はネットワークを Networking (neutron) プロバイダーネットワークとして設定することができます。

NFS-Ganesha は Ceph パブリックネットワークを通じて CephFS にアクセスし、StorageNFS ネットワーク上のアドレスを使用してその NFS サービスをバインドします。

NFS 共有にアクセスするためには、StorageNFS ネットワークに接続される新たな NIC と共に、ユーザー仮想マシン (Compute (nova) インスタンス) をプロビジョニングします。CephFS ファイル共有のエクスポート場所は、StorageNFS ネットワーク上の NFS-Ganesha サーバーの仮想 IP を使用する標準的な NFS IP:<path> タプルとして表示されます。ネットワークはユーザー仮想マシンの IP アドレスを使用して、NFS 共有でのアクセス制御を行います。

Networking (neutron) セキュリティーグループが、プロジェクト 1 に属するユーザー仮想マシンが StorageNFS ネットワークを通じてプロジェクト 2 に属するユーザー仮想マシンにアクセスするのを防ぎます。プロジェクトは同じ CephFS ファイルシステムを共有しますが、ユーザー仮想マシンはエクスポートツリー下のファイル (/path/to/share1/…., /path/to/share2/….) にしかアクセスできないので、プロジェクトデータパスの分離が確保されます。

1.1.2.2. NFS バックエンドに CephFS を使用した Shared File Systems サービスの耐障害性

Red Hat OpenStack Platform (RHOSP) director が Ceph サービスデーモンを起動すると、これらのデーモンは自己の高可用性 (HA) 状態を管理し、一般的に、これらのデーモン用に複数のインスタンスが実行されます。これとは対照的に、本リリースでは、ファイル共有を提供することのできる NFS-Ganesha 用インスタンスは、常に 1 つだけです。

NFS バックエンドに CephFS を使用したファイル共有では、データパスに単一障害点が生じるのを避けるために、NFS-Ganesha はアクティブ/パッシブ設定 (Pacemaker-Corosync クラスターが管理) の RHOSP コントローラーノード上で実行されます。NFS-Ganesha は、複数のコントローラーノードに渡って仮想サービス IP アドレスを持つ仮想サービスとして機能します。

コントローラーノードに障害が発生した、あるいは特定のコントローラーノード上のサービスに障害が発生し、そのノードで復帰できない場合には、Pacemaker-Corosync は同じ仮想 IP アドレスを使用して新たな NFS-Ganesha インスタンスを別のコントローラーノード上で起動します。既存クライアントのマウントはファイル共有のエクスポート場所の仮想 IP アドレスを使用するので、これらのマウントは維持されます。

デフォルトの NFS マウントオプション設定および NFS 4.1 以降を使用している場合には、障害発生後に TCP 接続がリセットされ、クライアントが再接続されます。フェイルオーバー中は I/O 操作が一時的に応答しなくなりますが、機能は失われません。アプリケーション I/O も応答しなくなりますが、フェイルオーバーが完了すると処理が再開されます。

最大 90 秒の猶予期間 (クライアントがロックを再要求するのをサーバーが待機する期間) が経過するまで、新規接続や新たなロック状態などは拒否されます。NFS-Ganesha はクライアントのリストを維持し、すべてのクライアントがロックを再要求すると、その時点で猶予期間を終了します。

注記

猶予期間のデフォルト値は 90 秒です。この値を変更するには、NFSv4 Grace_Period 設定オプションを編集します。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る