1.3. Ceph 파일 시스템 아키텍처

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는 클라이언트 목록을 유지하고 모든 클라이언트가 잠금을 회수한 경우 유예 기간을 일찍 종료합니다.