NFS バックエンドに CephFS を使用した Shared File Systems サービスのデプロイ

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/….) にしかアクセスできないので、プロジェクトデータパスの分離が確保されます。

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 はクライアントのリストを維持し、すべてのクライアントがロックを再要求すると、その時点で猶予期間を終了します。

ControllerStorageNFS カスタムロールにより、StorageNFS 分離ネットワークを設定します。このロールはデフォルトの Controller.yaml ロールファイルに類似していますが、StorageNFS ネットワークおよび CephNfs サービス (OS::TripleO::Services:CephNfs コマンドで表される) が追加されています。

cd /usr/share/openstack-tripleo-heat-templates/roles
diff Controller.yaml ControllerStorageNfs.yaml
	- StorageNFS
	- OS::TripleO::Services::CephNfs

[stack@undercloud ~]$ cd /usr/share/openstack-tripleo-heat-templates/roles
[stack@undercloud roles]$ diff Controller.yaml ControllerStorageNfs.yaml
16a17
> 	- StorageNFS
50a45
> 	- OS::TripleO::Services::CephNfs

openstack overcloud roles generate コマンドに関する情報は、Advanced Overcloud Customizationの Roles を参照してください。

openstack overcloud roles generate コマンドにより、-o 以降に指定したサービスが含まれるカスタム roles_data.yaml ファイルが作成されます。以下の例では、作成される roles_data.yaml ファイルには、ControllerStorageNfs、Compute、および CephStorage のサービスが含まれます。

コンポーザブルネットワークを使用して、カスタムネットワークを定義して、それを任意のロールに割り当てます。標準の network_data.yaml ファイルを使用する代わりに、network_data_ganesha.yaml ファイルを使用して StorageNFS コンポーザブルネットワークを設定することができます。これらのロールは、共に /usr/share/openstack-tripleo-heat-templates ディレクトリーから利用可能です。

network_data_ganesha.yaml ファイルには、StorageNFS 分離ネットワークを定義する追加のセクションが含まれます。デフォルトの設定がほとんどのインストールで機能しますが、YAML ファイルを編集してご自分のネットワーク設定 (VLAN ID、サブネット、その他の設定など) を追加する必要があります。

name: StorageNFS
enabled: true
vip: true
name_lower: storage_nfs
vlan: 70
ip_subnet: '172.17.0.0/20'
allocation_pools: [{'start': '172.17.0.4', 'end': '172.17.0.250'}]
ipv6_subnet: 'fd00:fd00:fd00:7000::/64'
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:7000::4', 'end': 'fd00:fd00:fd00:7000::fffe'}]

name: StorageNFS
enabled: true
vip: true
name_lower: storage_nfs
vlan: 70
ip_subnet: '172.17.0.0/20'
allocation_pools: [{'start': '172.17.0.4', 'end': '172.17.0.250'}]
ipv6_subnet: 'fd00:fd00:fd00:7000::/64'
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:7000::4', 'end': 'fd00:fd00:fd00:7000::fffe'}]

コンポーザブルネットワークについての詳しい情報は、オーバークラウドの高度なカスタマイズの コンポーザブルネットワーク を参照してください。

CephFS バックエンド manila-cephfsganesha-config.yaml を定義するための統合環境ファイルは /usr/share/openstack-tripleo-heat-templates/environments/ にあります。

manila-cephfsganesha-config.yaml 環境ファイルには、Shared File Systems サービス (manila) のデプロイメントに関する設定が含まれます。バックエンドのデフォルト設定は、ほとんどの環境で機能します。Shared File Systems サービスをデプロイする際に director が使用するデフォルト値を以下の例で示します。

cat /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml
# A Heat environment file which can be used to enable a
# a Manila CephFS-NFS driver backend.
resource_registry:
  OS::TripleO::Services::ManilaApi: ../deployment/manila/manila-api-container-puppet.yaml
  OS::TripleO::Services::ManilaScheduler: ../deployment/manila/manila-scheduler-container-puppet.yaml
  # Only manila-share is pacemaker managed:
  OS::TripleO::Services::ManilaShare: ../deployment/manila/manila-share-pacemaker-puppet.yaml
  OS::TripleO::Services::ManilaBackendCephFs: ../deployment/manila/manila-backend-cephfs.yaml
  # ceph-nfs (ganesha) service is installed and configured by ceph-ansible
  # but it's still managed by pacemaker
  OS::TripleO::Services::CephNfs: ../deployment/ceph-ansible/ceph-nfs.yaml

parameter_defaults:
  ManilaCephFSBackendName: cephfs
  ManilaCephFSDriverHandlesShareServers: false
  ManilaCephFSCephFSAuthId: 'manila'
  ManilaCephFSCephFSEnableSnapshots: false
  # manila cephfs driver supports either native cephfs backend - 'CEPHFS'
  # (users mount shares directly from ceph cluster), or nfs-ganesha backend -
  # 'NFS' (users mount shares through nfs-ganesha server)
  ManilaCephFSCephFSProtocolHelperType: 'NFS'

[stack@undercloud ~]$ cat /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml
# A Heat environment file which can be used to enable a
# a Manila CephFS-NFS driver backend.
resource_registry:
  OS::TripleO::Services::ManilaApi: ../deployment/manila/manila-api-container-puppet.yaml
  OS::TripleO::Services::ManilaScheduler: ../deployment/manila/manila-scheduler-container-puppet.yaml
  # Only manila-share is pacemaker managed:
  OS::TripleO::Services::ManilaShare: ../deployment/manila/manila-share-pacemaker-puppet.yaml
  OS::TripleO::Services::ManilaBackendCephFs: ../deployment/manila/manila-backend-cephfs.yaml
  # ceph-nfs (ganesha) service is installed and configured by ceph-ansible
  # but it's still managed by pacemaker
  OS::TripleO::Services::CephNfs: ../deployment/ceph-ansible/ceph-nfs.yaml

parameter_defaults:
  ManilaCephFSBackendName: cephfs 

  ManilaCephFSDriverHandlesShareServers: false 

  ManilaCephFSCephFSAuthId: 'manila' 

  ManilaCephFSCephFSEnableSnapshots: false 

  # manila cephfs driver supports either native cephfs backend - 'CEPHFS'
  # (users mount shares directly from ceph cluster), or nfs-ganesha backend -
  # 'NFS' (users mount shares through nfs-ganesha server)
  ManilaCephFSCephFSProtocolHelperType: 'NFS'

parameter_defaults ヘッダーから設定が始まります。本セクションでは、設定を編集して resource_registry で設定したデフォルト値を上書きすることができます。これには、CephFS バックエンドのデフォルトを設定する OS::Tripleo::Services::ManilaBackendCephFs で定義した値も含まれます。

環境ファイルについての詳細は、Director のインストールと使用方法 の 環境ファイル を参照してください。

新しい StorageNFS 分離ネットワークを Networking (neutron) プロバイダーネットワークにマッピングする必要があります。NFS-Ganesha ゲートウェイの提供するファイル共有のエクスポート場所にアクセスするために、コンピュートノードの仮想マシンをネットワークにアタッチします。

Shared File Systems サービスのネットワークセキュリティーに関する情報は、セキュリティーおよび強化ガイド の Shared File System (Manila) の強化 を参照してください。

neutron 共有プロバイダーネットワークに対応する StorageNFSSubnet を作成します。サブネットが network_data.yml ファイルの storage_nfs ネットワーク定義と同じであることを確認し、StorageNFS サブネットと対応するアンダークラウドのサブネットの割り当て範囲が重複しないようにしてください。StorageNFS サブネットは NFS 共有の提供用であるため、ゲートウェイは必要ありません。

openstack subnet create --allocation-pool start=172.17.0.4,end=172.17.0.250 --dhcp --network StorageNFS --subnet-range 172.17.0.0/20 --gateway none StorageNFSSubnet

[stack@undercloud-0 ~]$ openstack subnet create --allocation-pool start=172.17.0.4,end=172.17.0.250 --dhcp --network StorageNFS --subnet-range 172.17.0.0/20 --gateway none StorageNFSSubnet

openstack subnet create --ip-version 6 --dhcp --network StorageNFS --subnet-range fd00:fd00:fd00:7000::/64 --gateway none --ipv6-ra-mode dhcpv6-stateful --ipv6-address-mode dhcpv6-stateful StorageNFSSubnet -f yaml

[stack@undercloud-0 ~]$ openstack subnet create --ip-version 6 --dhcp --network StorageNFS --subnet-range fd00:fd00:fd00:7000::/64 --gateway none --ipv6-ra-mode dhcpv6-stateful --ipv6-address-mode dhcpv6-stateful StorageNFSSubnet -f yaml

Shared File Systems サービスを使用して、ファイル共有の種別を定義することができます。これを使用して、特定の設定のファイル共有を作成することができます。ファイル共有の種別は、Block Storage のボリューム種別に類似した機能を持ちます。それぞれの種別には、追加の仕様などの関連する設定があります。ファイル共有の作成時に種別を呼び出すと、その設定が共有ファイルシステムに適用されます。

Red Hat OpenStack Platform (RHOSP) director を使用する場合、ユーザーにクラウドへのアクセスを許可する前に、デフォルトのファイル共有種別を作成する必要があります。NFS バックエンドに CephFS を使用する設定では、manila type-create コマンドを使用します。

manila type-create default false

$ manila type-create default false

ファイル共有種別に関する詳しい情報は、ストレージガイドの 共有タイプの作成 を参照してください。