Ceph가 개체 및/또는 블록 스토리지를 제공할 때 배포된 모니터, OSD, Rados Gateway(RGW) 및 관리자 서비스 외에도 CephFS에 Ceph 메타데이터 서비스(MDS)가 필요하며 NFS 프로토콜을 사용하는 기본 CephFS에 대한 게이트웨이로 필요합니다. (사용자를 향한 오브젝트 스토리지의 경우 RGW 서비스도 배포됩니다. 게이트웨이는 CephFS 클라이언트를 실행하여 Ceph 공용 네트워크에 액세스할 수 있으며 최종 사용자 제어가 아닙니다.

NFS-Ganesha는 자체 Docker 컨테이너에서 실행되며, Ceph 공용 네트워크 및 새 격리된 네트워크인 StorageNFS에 모두 인터페이스를 지정합니다. OpenStack director의 구성 가능 네트워크 기능은 이 네트워크를 배포하고 컨트롤러 노드에 연결하는 데 사용됩니다. 그런 다음 클라우드 관리자는 네트워크를 Neutron 공급자 네트워크로 구성합니다.

NFS-Ganesha는 Ceph 공용 네트워크를 통해 CephFS에 액세스하고 StorageNFS 네트워크의 주소를 사용하여 NFS 서비스를 바인딩합니다.

NFS 공유에 액세스하기 위해 스토리지 NFS 네트워크에 연결하는 추가 NIC를 사용하여 사용자 VM(nova 인스턴스)이 프로비저닝됩니다. CephFS 공유의 내보내기 위치는 StorageNFS 네트워크에서 NFS-Ganesha 서버 VIP를 사용하는 표준 NFS IP:<path > 튜플으로 표시됩니다. 사용자 VM에 대한 액세스 제어는 해당 네트워크의 사용자 VM IP를 사용하여 수행됩니다.

Neutron 보안 그룹은 테넌트 1에 속하는 사용자 VM이 StorageNFS 네트워크를 통해 테넌트 2에 속하는 사용자 VM에 액세스하지 못하도록 합니다. 테넌트는 동일한 CephFS 파일 시스템을 공유하지만 사용자 VM은 내보내기 트리의 파일에만 액세스할 수 있으므로 /path/to/share1/ …​. , /path/to/share2/…​.

OpenStack director가 Ceph 서비스 데몬을 시작하면 자체 HA(고가용성) 상태를 관리하며 일반적으로 이러한 데몬의 인스턴스가 여러 개 실행됩니다. 반면 이 릴리스에서는 하나의 NFS-Ganesha 인스턴스만 한 번에 파일 공유를 제공할 수 있습니다.

NFS 공유를 통한 CephFS 데이터 경로에서 단일 실패 지점을 방지하기 위해 NFS-Ganesha는 Pacemaker-Corosync 클러스터에서 관리하는 액티브-패시브 설정의 OpenStack 컨트롤러 노드에서 실행됩니다. NFS-Ganesha는 컨트롤러 노드에서 가상 서비스 IP 주소를 사용하는 가상 서비스로 작동합니다.

컨트롤러가 실패하거나 특정 컨트롤러 노드의 서비스가 실패하고 해당 노드에서 복구할 수 없는 경우 Pacemaker-Corosync는 동일한 가상 IP를 사용하여 다른 컨트롤러에서 새 NFS-Ganesha 인스턴스를 시작합니다. 기존 클라이언트 마운트는 공유의 내보내기 위치에 가상 IP를 사용하므로 보존됩니다.

실패 후 기본 NFS 마운트 옵션 설정과 NFS 4.1 이상을 사용하면 TCP 연결이 재설정되고 클라이언트가 다시 연결됩니다. I/O 작업은 장애 조치 중 응답을 일시적으로 중지하지만 실패하지 않습니다. 애플리케이션 I/O도 응답을 중지하지만 장애 조치(failover)가 완료된 후 다시 시작됩니다.Application I/O also stops responding, but resumes after failover completes.

새로운 연결, 새로운 lock-state 등은 서버가 클라이언트가 잠금을 회수할 때까지 대기할 때까지 최대 90초의 유예 기간이 될 때까지 거부됩니다. NFS-Ganesha는 클라이언트 목록을 유지하고 모든 클라이언트가 잠금을 회수한 경우 유예 기간을 일찍 종료합니다.

ControllerStorageNFS 사용자 지정 역할은 격리된 StorageNFS 네트워크를 설정하는 데 사용됩니다. 이 역할은 StorageNFS 네트워크 및 CephNfs 서비스( OS::TripleO::Services:CephNfs로 표시됨)를 추가하는 기본 Controller.yaml 역할 파일과 유사합니다.

[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 Guide 의 Roles 섹션 을 참조하십시오.

구성 가능 네트워크를 사용하면 사용자 지정 네트워크를 정의하고 모든 역할에 할당할 수 있습니다. 표준 network_data.yaml 파일을 사용하는 대신 network_data_ganesha.yaml 파일을 사용하여 StorageNFS 구성 가능 네트워크를 구성합니다. 이러한 두 역할은 모두 /usr/share/openstack-tripleo-heat-templates 디렉터리에서 사용할 수 있습니다.

network_data_ganesha.yaml 파일에는 격리된 StorageNFS 네트워크를 정의하는 추가 섹션이 포함되어 있습니다. 기본 설정은 대부분의 설치에서 작동하지만 VLAN ID, 서브넷 등 네트워크 설정을 추가하려면 YAML 파일을 계속 편집해야 합니다.

name: StorageNFS
enabled: true
vip: true
ame_lower: storage_nfs
vlan: 70
ip_subnet: '172.16.4.0/24'
allocation_pools: [{'start': '172.16.4.4', 'end': '172.16.4.250'}]
ipv6_subnet: 'fd00:fd00:fd00:7000::/64'
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:7000::10', 'end': 'fd00:fd00:fd00:7000:ffff:ffff:ffff:fffe'}]

구성 가능 네트워크에 대한 자세한 내용은 Advanced Overcloud Customization Guide 의 Composable Networks 사용 섹션을 참조하십시오.

CephFS 백엔드를 정의하는 통합 환경 파일은 언더클라우드 노드의 다음 경로에 있습니다.

/usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml

manila-cephfsganesha-config.yaml 환경 파일에는 공유 파일 시스템 서비스와 관련된 설정이 포함되어 있습니다. 백엔드 기본 설정은 대부분의 환경에서 작동해야 합니다. 이 예에서는 공유 파일 시스템 서비스를 배포할 때 director에서 사용하는 기본값을 보여줍니다.

[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: ../docker/services/manila-api.yaml
  OS::TripleO::Services::ManilaScheduler: ../docker/services/manila-scheduler.yaml
  # Only manila-share is pacemaker managed:
  OS::TripleO::Services::ManilaShare: ../docker/services/pacemaker/manila-share.yaml
  OS::TripleO::Services::ManilaBackendCephFs: ../puppet/services/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: ../docker/services/ceph-ansible/ceph-nfs.yaml

parameter_defaults:
  ManilaCephFSBackendName: cephfs 1
  ManilaCephFSDriverHandlesShareServers: false 2
  ManilaCephFSCephFSAuthId: 'manila' 3
  ManilaCephFSCephFSEnableSnapshots: false 4
  # 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 에서 설정한 값이 포함됩니다.

환경 파일에 대한 자세한 내용은 Advanced Overcloud Customization 가이드의 환경 파일 을 참조하십시오.

새 isolated StorageNFS 네트워크를 neutron-shared 공급자 네트워크에 매핑해야 합니다. Compute VM은 이 neutron 네트워크에 연결하여 NFS-Ganesha 게이트웨이에서 제공하는 공유 내보내기 위치에 액세스합니다.

공유 파일 시스템 서비스를 통한 네트워크 보안에 대한 자세한 내용은 보안 및 Hardening 가이드의 공유 파일 시스템 서비스 섹션을 참조하십시오.

이 명령을 사용하려면 다음을 수행합니다.

neutron 공유 공급자 네트워크에 해당 StorageNFSSubnet을 생성합니다. 서브넷이 언더클라우드의 storage_nfs_subnet과 동일하지만 이 서브넷의 할당 범위와 해당 언더클라우드 서브넷의 할당 범위가 겹치지 않는지 확인합니다. 이 서브넷은 NFS 공유를 제공하기 위해 전용되므로 게이트웨이가 필요하지 않습니다.

[stack@undercloud-0 ~]$ openstack subnet create --allocation-pool start=172.16.4.150,end=172.16.4.250 --dhcp --network StorageNFS --subnet-range 172.16.4.0/24 --gateway none StorageNFSSubnet
+-------------------+--------------------------------------+
| Field         	  | Value
+-------------------+--------------------------------------+
| allocation_pools  | 172.16.4.150-172.16.4.250
| cidr            	| 172.16.4.0/24
| created_at    	  | 2018-09-17T21:22:14Z
| description   	  |
| dns_nameservers   |
| enable_dhcp   	  | True
| gateway_ip    	  | None
| host_routes   	  |
| id            	  | 8c696d06-76b7-4d77-a375-fd2e71e3e480
| ip_version    	  | 4
| ipv6_address_mode | None
| ipv6_ra_mode  	  | None
| name          	  | StorageNFSSubnet
| network_id      	| cd272981-0a5e-4f3d-83eb-d25473f5176e
| project_id      	| 3ca3408d545143629cd0ec35d34aea9c
| revision_number   | 0
| segment_id    	  | None
| service_types 	  |
| subnetpool_id 	  | None
| tags          	  |
| updated_at    	  | 2018-09-17T21:22:14Z
+-------------------+--------------------------------------+

공유 파일 시스템 서비스를 사용하면 특정 설정으로 공유를 생성하는 데 사용할 수 있는 공유 유형을 정의할 수 있습니다. Block Storage 볼륨 유형과 같은 공유 유형이 작동합니다. 각 유형에는 연결된 설정(예: 추가 사양)이 있으며 공유 생성 중에 유형을 호출하는 경우 해당 설정이 적용됩니다.

OpenStack director에는 기본 공유 유형이 필요합니다. 사용자가 액세스할 수 있도록 클라우드를 열기 전에 이 기본 공유 유형을 만들어야 합니다. NFS가 있는 CephFS의 경우 manila type-create 명령을 사용합니다.

manila type-create default false

공유 유형에 대한 자세한 내용은 스토리지 가이드의 공유 유형 만들기 및 관리 섹션을 참조하십시오.