공유 파일 시스템 서비스용 CephFS 백엔드 가이드

Red Hat OpenStack Platform 16.1

Red Hat OpenStack Platform Overcloud에서 기본 CephFS를 사용하여 공유 파일 시스템 서비스 배포

OpenStack Documentation Team

초록

이 문서에서는 Red Hat OpenStack Platform 환경의 기본 CephFS(CephFS) 백엔드를 사용하여 Shared File Systems 서비스(manila)를 설치, 구성 및 확인하는 절차를 설명합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

1장. 소개

중요

이 문서는 기본 CephFS NAS 프로토콜을 통해 Red Hat OpenStack Platform Cloud에서 셀프 서비스 Shared File Systems 서비스(manila)를 제공하기 위해 기본 CephFS를 배포하고 사용하는 것과 관련이 있습니다. 이러한 유형의 배포를 위해서는 게스트 VM이 Ceph 공용 네트워크 및 인프라에 액세스해야 합니다. 일반 OpenStack Platform 배포에 적합하지 않은 허용 신뢰 모델이 필요하므로 신뢰할 수 있는 OpenStack Platform 테넌트로 기본 CephFS를 배포하는 것이 좋습니다.

일반적인 테넌트 신뢰 모델을 사용하는 일반적인 OpenStack Platform 배포의 경우 NFS 프로토콜을 통해 CephFS를 배포할 수 있습니다. 신뢰 모델에 대한 자세한 내용은 보안 고려 사항을 참조하십시오.

NFS를 통한 CephFS 사용에 대한 자세한 내용은 NFS 를 통해 CephFS를 사용하여 공유 파일 시스템 서비스 배포를 참조하십시오.

Shared File Systems 서비스(manila)를 사용하면 여러 계산 인스턴스, 베어 메탈 노드 또는 컨테이너가 사용할 수 있는 공유 파일 시스템을 프로비저닝할 수 있습니다.

CephFS는 통합 분산 스토리지 플랫폼인 Ceph의 확장성이 뛰어난 오픈 소스 분산 파일 시스템 구성 요소입니다. Ceph Storage는 RADOS(Reliable Autonomic Distributed Object Store)를 사용하여 오브젝트, 블록 및 파일 스토리지를 구현합니다. POSIX 호환 가능한 CephFS는 Ceph 스토리지 클러스터에 대한 파일 액세스를 제공합니다.

공유 파일 시스템 서비스를 사용하면 CephFS에 공유를 생성하고 기본 Ceph File System 프로토콜을 사용하여 액세스할 수 있습니다. 공유 파일 시스템 서비스는 OpenStack 내에서 이러한 공유의 라이프사이클을 관리합니다.

이 릴리스에서는 director가 오버클라우드에서 기본 CephFS 백엔드를 사용하여 공유 파일 시스템을 배포할 수 있습니다.

2장. 기본 드라이버가 있는 CephFS

CephFS 기본 드라이버는 OpenStack Shared File Systems 서비스(manila)와 Red Hat Ceph Storage를 결합합니다. RHOSP(Red Hat OpenStack) director를 사용하는 경우 컨트롤러 노드는 관리자, 메타데이터 서버(MDS), 모니터(MON) 및 공유 파일 시스템 서비스와 같은 Ceph 데몬을 호스팅합니다.

계산 노드는 하나 이상의 프로젝트를 호스팅할 수 있습니다. 다음 그래픽에 표시된 프로젝트(구 테넌트)에는 두 개의 NIC가 있는 회색 상자로 표시되는 사용자 관리 VM이 포함되어 있습니다. ceph 및 manila 데몬 프로젝트에 액세스하려면 공용 Ceph 스토리지 네트워크를 통해 데몬에 연결합니다. 이 네트워크에서 Ceph OSD(오브젝트 스토리지 데몬)에서 제공하는 스토리지 노드의 데이터에 액세스할 수 있습니다. 프로젝트 부팅 시 호스팅되는 인스턴스(VM)는 두 개의 NIC(스토리지 프로바이더 네트워크 전용)와 외부 프로바이더 네트워크의 프로젝트 소유 라우터 전용입니다.

스토리지 프로바이더 네트워크는 프로젝트에서 실행되는 VM을 공용 Ceph 스토리지 네트워크에 연결합니다. Ceph 공용 네트워크는 Ceph 오브젝트 스토리지 노드, 메타데이터 서버(MDS) 및 컨트롤러 노드에 대한 백엔드 액세스를 제공합니다.

기본 드라이버를 사용하여 CephFS는 클라이언트 및 서버와 협력하여 할당량을 적용하고 프로젝트 격리를 보장하며 보안을 보장합니다. 기본 드라이버를 사용하는 CephFS는 신뢰할 수 있는 최종 사용자가 프라이빗 클라우드에 있는 환경에서 원활하게 작동합니다. 이 구성을 사용하려면 사용자 제어 하에서 실행되고 있는 소프트웨어가 올바르게 작동해야 합니다.

CephFS nfs 토폴로지 기본 드라이버

2.1. 보안 고려 사항

기본 CephFS 백엔드에는 OpenStack Platform 테넌트에 대한 허용 신뢰 모델이 필요합니다. 이러한 신뢰 모델은 사용자가 OpenStack Platform에서 제공하는 서비스 뒤의 인프라에 직접 액세스할 수 없도록 의도적으로 차단하는 일반적인 OpenStack Platform 클라우드에 적합하지 않습니다.

기본 CephFS를 사용하면 공유 영역에 액세스하려면 사용자 컴퓨팅 인스턴스(VM)를 Ceph 공용 네트워크에 직접 연결해야 합니다. Ceph 인프라 서비스 데몬은 사용자 VM에 노출되는 Ceph 공용 네트워크에 배포됩니다. 사용자 VM에서 실행되는 CephFS 클라이언트는 Ceph 서비스 데몬과 협업하여 RADOS와 직접 상호 작용하여 파일 데이터 블록을 읽고 씁니다.

Shared File Systems(manila) 공유 크기를 적용하는 CephFS 할당량은 RHOSP(Red Hat OpenStack Platform) 사용자가 소유한 VM과 같이 클라이언트측에 적용됩니다. 사용자 VM의 클라이언트 측 소프트웨어 버전이 최신 상태가 아닐 수 있으므로 중요한 클라우드 인프라가 Ceph 서비스 포트를 대상으로 하는 악의적이거나 의도치 않게 해로운 소프트웨어에 취약해질 수 있습니다.

이러한 이유로 기본 CephFS를 신뢰할 수 있는 사용자가 최신 버전의 클라이언트 측 소프트웨어를 유지 관리하는 환경에서만 배포할 것을 권장합니다. 또한 사용자는 Ceph Storage 인프라에 영향을 줄 수 있는 VM에서 소프트웨어가 실행되지 않도록 해야 합니다.

신뢰할 수 없는 많은 사용자를 제공하는 일반적인 목적으로 RHOSP 배포의 경우 NFS를 통해 CephFS를 배포하는 것이 좋습니다. NFS를 통한 CephFS 사용에 대한 자세한 내용은 NFS 를 통해 CephFS를 사용하여 공유 파일 시스템 서비스 배포를 참조하십시오.

사용자는 클라이언트 측 소프트웨어를 최신 상태로 유지하지 못할 수 있으며 VM에서 해로운 소프트웨어를 제외하지 못할 수 있지만, NFS를 통해 CephFS를 사용하면 사용자는 Ceph 인프라 자체가 아닌 NFS 서버의 공용 측면만 액세스할 수 있습니다. NFS는 동일한 종류의 협업 클라이언트를 필요로 하지 않으며, 최악의 경우 사용자 VM 공격이 Ceph Storage 인프라를 손상시키지 않고 NFS 게이트웨이를 손상시킬 수 있습니다.

Red Hat은 다음과 같은 보안 조치를 권장합니다.

  • 스토리지 네트워크를 프로바이더 네트워크로 구성합니다.
  • 역할 기반 액세스 제어(RBAC) 정책을 적용하여 스토리지 프로바이더 네트워크를 보호합니다.
  • 기본 CephFS 백엔드에 대한 개인 공유 유형을 생성하고 신뢰할 수 있는 테넌트에만 노출합니다.

3장. 기본 CephFS 배포

RHOSP(Red Hat OpenStack Platform) 환경의 일반적인 기본 Ceph 파일 시스템(CephFS) 설치에는 다음과 같은 구성 요소가 포함됩니다.

  • 컨테이너화된 Ceph 메타데이터 서버(MDS), Ceph 모니터(MON) 및 Shared File Systems(manila) 서비스를 실행하는 RHOSP 컨트롤러 노드. 이러한 서비스 중 일부는 동일한 노드에 공존하거나 하나 이상의 전용 노드를 가질 수 있습니다.
  • Ceph Storage 노드에서 실행되는 컨테이너화된 오브젝트 스토리지 데몬(OSD)이 포함된 Ceph Storage 클러스터.
  • 클라이언트가 Ceph 서비스 데몬과 통신할 수 있는 Ceph 공용 네트워크 역할을 하는 격리된 스토리지 네트워크입니다. 이를 위해 사용자가 VM을 연결하고 CephFS 공유를 마운트할 수 있도록 스토리지 네트워크를 프로바이더 네트워크로 사용할 수 있습니다.
중요

Red Hat은 이러한 유형의 배포를 지원하지 않기 때문에 공유 파일 시스템 서비스(manila)를 CephFS 기본 드라이버와 함께 사용하여 Manila CSI를 통해 OpenShift Container Platform에 대한 공유를 제공할 수 없습니다. 자세한 내용은 Red Hat 지원팀에 문의하십시오.

Shared File Systems(manila) 서비스는 테넌트가 드라이버 모듈에서 이행하는 파일 시스템 공유를 요청할 수 있는 API를 제공합니다. Red Hat CephFS의 드라이버인 manila.share.drivers.cephfs.driver.CephFSDriver 를 사용하면 공유 파일 시스템 서비스에서 기본 CephFS를 백엔드로 사용할 수 있습니다.

director가 오버클라우드에 CephFS 백엔드를 사용하여 공유 파일 시스템 서비스를 배포할 때 필요한 데이터 센터 스토리지 네트워크를 자동으로 생성합니다. 그러나 오버클라우드에서 해당 스토리지 공급자 네트워크를 생성해야 합니다. 자세한 내용은 4장. 배포 후 구성 완료의 내용을 참조하십시오. 네트워크 계획에 대한 자세한 내용은 Director 설치 및 사용 가이드의 Overcloud 네트워크 참조하십시오.

노드의 /var/lib/config-data/puppet-generated/manila/etc/manila/manila.conf 파일을 편집하여 공유 파일 시스템 서비스를 수동으로 구성할 수 있지만 향후 오버클라우드 업데이트에서 Red Hat OpenStack Platform director가 설정을 덮어쓸 수 있습니다. Red Hat은 director가 관리하는 공유 파일 시스템 서비스 배포만 지원합니다.

이 섹션에서는 director가 관리하는 통합 배포에 기본 CephFS를 설치하는 방법에 대해 설명합니다.

3.1. 요구 사항

다음 요구 사항을 충족하는 경우 새로운 또는 기존 RHOSP(Red Hat OpenStack Platform) 환경으로 기본 CephFS 백엔드를 배포할 수 있습니다.

중요

기본 CephFS 백엔드가 있는 RHOSP Shared File Systems 서비스는 Red Hat Ceph Storage 버전 4.1 이상에서 사용할 수 있습니다. 시스템에 설치된 Ceph Storage 버전을 결정하는 방법에 대한 자세한 내용은 Red Hat Ceph Storage 릴리스 및 해당 Ceph 패키지 버전을 참조하십시오.

  • 컨트롤러 노드에 공유 파일 시스템 서비스를 설치합니다. 기본 동작입니다.
  • 공유 파일 시스템 서비스에 대해 CephFS 백엔드의 단일 인스턴스만 사용합니다.

3.2. 파일 공유

파일 공유는 공유 파일 시스템 서비스(manila), Ceph 파일 시스템(CephFS) 및 NFS를 통한 CephFS 간에 다르게 처리됩니다.

공유 파일 시스템 서비스는 공유를 제공합니다. 이 공유는 개별 파일 시스템 네임스페이스이자 정의된 크기의 스토리지 단위입니다. 공유 파일 시스템 스토리지는 본질적으로 여러 클라이언트가 주어진 공유에 데이터를 연결, 읽기 및 쓸 수 있도록 허용하지만, 연결하기 전에 공유 파일 시스템 서비스 액세스 제어 API를 통해 각 클라이언트에 공유 액세스 권한을 부여해야 합니다.

CephFS에서는 공유가 정의된 할당량이 있는 디렉터리와 특정 스토리지 풀 또는 네임스페이스를 가리키는 레이아웃으로 간주됩니다. CephFS 할당량은 디렉터리의 크기를 공유 파일 시스템 서비스에서 생성하는 크기 공유로 제한합니다. Ceph 공유에 대한 액세스는 MDS 인증 기능에 따라 결정됩니다.

기본 CephFS에서는 CephFS 프로토콜을 통해 파일 공유를 프로비저닝하고 액세스합니다. 액세스 제어는 CephFS 사용자 이름을 사용하는 CephX 인증 체계를 사용하여 수행됩니다.

3.3. 기본 CephFS에서 사용하는 격리된 네트워크

기본 CephFS 배포에서는 director에서 Ceph 공용 네트워크로 배포된 격리된 스토리지 네트워크를 사용합니다. 클라이언트는 이 네트워크를 사용하여 다양한 Ceph 인프라 서비스 데몬과 통신합니다. 네트워크 격리에 대한 자세한 내용은 Advanced Overcloud Customization 가이드의 기본 네트워크 격리 를 참조하십시오.

3.4. ceph-ansible 패키지 설치

언더클라우드 노드에 설치할 ceph-ansible 패키지를 설치하여 컨테이너화된 Ceph를 배포합니다.

절차

  1. stack 사용자로 언더클라우드 노드에 로그인합니다.
  2. ceph-ansible 패키지를 설치합니다.

    [stack@undercloud-0 ~]$ sudo dnf install -y ceph-ansible
    [stack@undercloud-0 ~]$ sudo dnf list ceph-ansible
    ...
    Installed Packages
    ceph-ansible.noarch    4.0.23-1.el8cp      @rhelosp-ceph-4-tools

3.5. 환경 배포

환경을 배포할 준비가 되면 기본 CephFS 백엔드를 구성하는 데 필요한 사용자 지정 환경 및 역할과 함께 openstack overcloud deploy 명령을 사용합니다.

openstack overcloud deploy 명령에는 기타 필수 옵션 외에 다음 옵션이 있습니다.

동작옵션추가 정보

network _data.yaml을 사용하여 네트워크 구성을 지정합니다.

[filename] -n /usr/share/openstack-tripleo-heat-templates/network_data.yaml

사용자 지정 환경 파일을 사용하여 이 네트워크 데이터 환경 파일에 지정된 기본 네트워크의 값을 덮어쓸 수 있습니다. 격리된 네트워크를 사용할 때 사용할 수 있는 기본 네트워크 데이터 파일입니다. 간결성을 위해 openstack overcloud deploy 명령에서 이 파일을 생략할 수 있습니다.

ceph-ansible.yaml을 사용하여 Ceph 데몬 배포

-e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml

Deploying an Overcloud with Containerized Red Hat Ceph 가이드에서 오버클라우드 배포 시작 가이드

ceph-mds.yaml을 사용하여 Ceph 메타데이터 서버를 배포합니다.

-e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-mds.yaml

Deploying an Overcloud with Containerized Red Hat Ceph 가이드에서 오버클라우드 배포 시작 가이드

기본 CephFS 백엔드를 사용하여 manila 서비스를 배포합니다.

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

3.5.1절. “환경 파일”

다음 예제에서는 Ceph 클러스터, Ceph MDS, 기본 CephFS 백엔드 및 Ceph 클러스터에 필요한 네트워크를 배포하는 옵션이 포함된 openstack overcloud deploy 명령을 보여줍니다.

[stack@undercloud ~]$ openstack overcloud deploy \
...
-n /usr/share/openstack-tripleo-heat-templates/network_data.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml   \
-e /home/stack/network-environment.yaml  \
-e/usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml  \
-e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-mds.yaml  \
-e /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsnative-config.yaml

openstack overcloud deploy 명령에 대한 자세한 내용은 Director 설치 및 사용 가이드의 Deployment 명령 참조하십시오.

3.5.1. 환경 파일

기본 CephFS 백엔드를 정의하는 통합 환경 파일은 /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsnative-config.yaml 의 경로에 있습니다.

manila-cephfsnative-config.yaml 환경 파일에는 공유 파일 시스템 서비스 배포와 관련된 설정이 포함되어 있습니다. 백엔드 기본 설정은 대부분의 환경에서 작동해야 합니다.

이 예제에서는 공유 파일 시스템 서비스를 배포하는 동안 director에서 사용하는 기본값을 보여줍니다.

[stack@undercloud ~]$ cat /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsnative-config.yaml

# A Heat environment file which can be used to enable a
# a Manila CephFS Native 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

parameter_defaults:
  ManilaCephFSBackendName: cephfs 1
  ManilaCephFSDriverHandlesShareServers: false 2
  ManilaCephFSCephFSAuthId: 'manila' 3
  ManilaCephFSCephFSEnableSnapshots: true 4
  ManilaCephFSCephVolumeMode: '0755'  5
  # 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: 'CEPHFS'  6

parameter_defaults 헤더는 구성을 시작하는 것을 나타냅니다. 특히 이 헤더의 설정은 resource_registry 에 설정된 기본값을 재정의할 수 있습니다. 여기에는 CephFS 백엔드의 기본값을 설정하는 OS::Tripleo::Services::ManilaBackendCephFs 로 설정된 값이 포함됩니다.

1
ManilaCephFSBackendName 은 CephFS 백엔드의 manila 구성 이름을 설정합니다. 이 경우 기본 백엔드 이름은 cephfs 입니다.
2
ManilaCephFSDriverHandlesShareServers 는 공유 서버의 라이프사이클을 제어합니다. false로 설정하면 드라이버에서 라이프사이클을 처리하지 않습니다. 이 옵션은 CephFS 백엔드에 지원되는 유일한 옵션입니다.
3
ManilaCephFSCephFSAuthId 는 director에서 Ceph 클러스터에 액세스할 수 있도록 생성하는 Ceph 인증 ID를 정의합니다.
4
ManilaCephFSCephFSEnableSnapshots는 스냅샷 활성화를 제어합니다. 스냅샷은 Ceph Storage 4.1 이상에서 지원되지만 이 매개 변수의 기본값은 false 입니다. 드라이버가 snapshot_support 기능을 manila 스케줄러에 보고하도록 값을 true 로 설정할 수 있습니다.
5
ManilaCephFSCephVolumeMode 는 기본 CephFS 백엔드에서 생성된 manila 공유에 대해 설정할 UNIX 권한을 제어합니다. 기본값은 755 입니다.
6
기본 CephFS 드라이버를 사용하려면 ManilaCephFSCephFSProtocolHelperTypeCEPHFS 로 설정해야 합니다.

환경 파일에 대한 자세한 내용은 Director 설치 및 사용 가이드 의 환경 파일을 참조하십시오.

4장. 배포 후 구성 완료

NFS 공유를 만들고 사용자 액세스 권한을 부여하며 NFS 공유를 마운트하기 전에 배포 후 구성 작업을 완료해야 합니다.

  • 네트워킹 서비스(neutron) 스토리지 네트워크를 격리된 데이터 센터 스토리지 네트워크에 매핑합니다.
  • 사용자 지정 역할 기반 액세스 제어(RBAC)를 통해서만 스토리지 프로바이더 네트워크를 신뢰할 수 있는 테넌트에서만 사용할 수 있도록 합니다. 스토리지 공급자 네트워크를 전역적으로 공유하지 마십시오.
  • 개인 공유 유형을 만듭니다.
  • 신뢰할 수 있는 특정 테넌트에 대한 액세스 권한을 부여합니다.

이러한 단계를 완료하고 나면 테넌트 compute 인스턴스가 기본 CephFS 공유를 생성, 허용 및 마운트할 수 있습니다.

4.1. 스토리지 공급자 네트워크 생성

격리된 새 스토리지 네트워크를 네트워킹(neutron) 프로바이더 네트워크에 매핑해야 합니다. 계산 VM은 네트워크에 연결하여 기본 CephFS 공유 내보내기 위치에 액세스합니다.

공유 파일 시스템 서비스를 사용한 네트워크 보안에 대한 자세한 내용은 보안 및 강화 가이드에서 공유 파일 시스템 서비스 강화를 참조하십시오.

절차

openstack network create 명령은 neutron 네트워크의 구성을 정의합니다.

  1. 언더클라우드 노드에서 다음 명령을 입력합니다.

    [stack@undercloud ~]$ source ~/overcloudrc
  2. 언더클라우드 노드에서 storage 네트워크를 생성합니다.

    (overcloud) [stack@undercloud-0 ~]$ openstack network create Storage --provider-network-type vlan --provider-physical-network datacentre --provider-segment 30

    다음 옵션을 사용하여 이 명령을 입력할 수 있습니다.

    • tripleo-heat -templates에서 NeutronBridgeMappings를 통해 br-isolated 브리지에 대한 다른 태그를 설정하지 않는 한 --provider-physical-network 옵션의 경우 기본값 datacentre 를 사용합니다.
    • provider -segment 옵션의 경우 네트워크 환경 파일에서 스토리지 격리된 네트워크에 대해 설정된 값을 사용합니다. 이 파일을 사용자 지정하지 않은 경우 기본 환경 파일은 /usr/share/openstack-tripleo-heat-templates/network_data.yaml 입니다. Storage network 값과 연결된 VLAN은 격리된 네트워크 정의를 수정하지 않는 한 30 입니다.
    • provider -network-type 옵션의 경우 vlan 값을 사용합니다.

4.2. 스토리지 공급자 네트워크 구성

Neutron 공급자 네트워크에 해당하는 StorageSubnet 을 생성합니다. 서브넷이 언더클라우드의 storage_subnet 에 대해 동일하고 스토리지 서브넷 및 해당 Undercloud 서브넷의 할당 범위가 겹치지 않는지 확인합니다.

요구 사항

  • 할당 풀의 시작 및 종료 IP 범위
  • 서브넷 IP 범위

절차

  1. 언더클라우드 노드에서 다음 명령을 입력합니다.

    [stack@undercloud ~]$ source ~/overcloudrc
  2. sample 명령을 사용하여 네트워크를 프로비저닝합니다. 환경에 맞게 값을 업데이트합니다.

    (overcloud) [stack@undercloud-0 ~]$ openstack subnet create \
    --allocation-pool start=172.17.3.10,end=172.17.3.149 \
    --dhcp \
    --network Storage \
    --subnet-range 172.17.3.0/24 \
    --gateway none StorageSubnet
    • allocation -pool 옵션의 경우 start=172.17.3.10,end=172.17.3.149 IP 값을 네트워크의 IP 값으로 바꿉니다.
    • subnet -range 옵션의 경우 172.17.3.0/24 서브넷 범위를 네트워크의 서브넷 범위로 바꿉니다.

4.3. 스토리지 공급자 네트워크에 대한 역할 기반 액세스 제어 구성

스토리지 네트워크를 사용할 수 있는 신뢰할 수 있는 테넌트 또는 프로젝트를 식별한 후 Networking 서비스(neutron)를 통해 RBAC(역할 기반 액세스 제어) 규칙을 구성합니다.

요구 사항

스토리지 네트워크에 액세스해야 하는 프로젝트의 이름

절차

  1. 언더클라우드 노드에서 다음 명령을 입력합니다.

    [stack@undercloud ~]$ source ~/overcloudrc
  2. 액세스 권한이 필요한 프로젝트를 확인합니다.

    (overcloud) [stack@undercloud-0 ~]$ openstack project list
    +----------------------------------+---------+
    | ID                               | Name    |
    +----------------------------------+---------+
    | 06f1068f79d2400b88d1c2c33eacea87 | demo    |
    | 5038dde12dfb44fdaa0b3ee4bfe487ce | service |
    | 820e2d9c956644c2b1530b514127fd0d | admin   |
    +----------------------------------+---------+
  3. 원하는 프로젝트를 사용하여 네트워크 RBAC 규칙을 생성합니다.

    (overcloud) [stack@undercloud-0 ~]$ openstack network rbac create \
    --action access_as_shared Storage \
    --type network \
    --target-project demo

    스토리지 네트워크에 액세스해야 하는 모든 프로젝트에 대해 이 단계를 반복합니다.

4.4. 기본 공유 유형 구성

공유 파일 시스템 서비스를 사용하여 특정 설정으로 공유를 생성하는 데 사용할 수 있는 공유 유형을 정의할 수 있습니다. 공유 유형은 블록 스토리지 볼륨 유형처럼 작동합니다. 각 유형에는 추가 사양과 같은 설정이 연결되어 있습니다. 공유 생성 중에 유형을 호출할 때 설정이 공유 파일 시스템에 적용됩니다.

신뢰할 수 없는 사용자에 대해 기본 CephFS 백엔드를 보호하려면 기본 공유 유형을 만들지 않는 것이 좋습니다. 기본 공유 유형이 없는 경우 사용자는 공유 유형을 지정해야 하며 신뢰할 수 있는 사용자는 독점적인 액세스 권한이 있는 사용자 지정 개인 공유 유형을 사용할 수 있습니다.

신뢰할 수 없는 테넌트에 대한 기본 공유 유형을 생성해야 하는 경우 기본 CephFS 백엔드에서 프로비저닝을 중지할 수 있습니다.

절차

  1. 언더클라우드 노드에서 다음 명령을 입력합니다.

    [stack@undercloud ~]$ source ~/overcloudrc
  2. 공유 유형에 추가 사양을 설정합니다.

    (overcloud) [stack@undercloud-0 ~] manila type-create default False
    (overcloud) [stack@undercloud-0 ~] manila type-key default set share_backend_name='cephfs’
  3. 사설 공유 유형을 생성하고 이 공유 유형에 대한 액세스 권한을 신뢰할 수 있는 테넌트를 제공합니다.

    (overcloud) [stack@undercloud-0 ~]$ manila type-create --is-public false nativecephfstype false
    (overcloud) [stack@undercloud-0 ~]$ manila type-key nativecephfstype set share_backend_name='cephfs'
    (overcloud) [stack@undercloud-0 ~]$ manila type-access-add nativecephfstype <trusted_tenant_project_id>

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

5장. 기본 CephFS 백엔드 배포 확인

기본 CephFS를 Shared File Systems 서비스(manila)의 백엔드로 배포하면 다음과 같은 새로운 요소가 오버클라우드 환경에 추가됩니다.

  • 스토리지 공급자 네트워크
  • 컨트롤러 노드의 Ceph MDS 서비스

기본 CephFS와 함께 공유 파일 시스템 서비스를 사용하는 방법에 대한 자세한 내용은 스토리지 가이드의 공유 파일 시스템 서비스를 참조하십시오.

클라우드 관리자는 서비스 사용자가 사용할 수 있도록 하기 전에 기본 CephFS 환경의 안정성을 확인해야 합니다.

사전 요구 사항

5.1. 격리된 스토리지 네트워크 생성 확인

기본 CephFS를 공유 파일 시스템 서비스 백엔드로 배포하는 데 사용되는 network_data.yaml 파일은 스토리지 VLAN을 생성합니다. 다음 절차를 사용하여 스토리지 VLAN이 성공적으로 생성되었는지 확인합니다.

절차

  1. 오버클라우드의 컨트롤러 노드 중 하나에 로그인합니다.
  2. 연결된 네트워크를 확인하고 network_data.yaml 파일에 설정된 VLAN이 있는지 확인합니다.

    $ ip a
    8: vlan30: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
        link/ether 52:9c:82:7a:d4:75 brd ff:ff:ff:ff:ff:ff
        inet 172.17.3.144/24 brd 172.17.3.255 scope global vlan30
           valid_lft forever preferred_lft forever
        inet6 fe80::509c:82ff:fe7a:d475/64 scope link
           valid_lft forever preferred_lft forever

5.2. Ceph MDS 서비스 확인

systemctl status 명령을 사용하여 Ceph MDS 서비스 상태를 확인합니다.

절차

  • MDS 컨테이너의 상태를 확인하려면 모든 컨트롤러 노드에서 다음 명령을 입력합니다.

    $ systemctl status ceph-mds<@CONTROLLER-HOST>

    예제:

$ systemctl status ceph-mds@controller-0.service

ceph-mds@controller-0.service - Ceph MDS
   Loaded: loaded (/etc/systemd/system/ceph-mds@.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2018-09-18 20:11:53 UTC; 6 days ago
 Main PID: 65066 (conmon)
   Tasks: 16 (limit: 204320)
   Memory: 38.2M
   CGroup: /system.slice/system-ceph\x2dmds.slice/ceph-mds@controller-0.service
         └─60921 /usr/bin/podman run --rm --net=host --memory=32000m --cpus=4 -v
/var/lib/ceph:/var/lib/ceph:z -v /etc/ceph:/etc/ceph:z -v
/var/run/ceph:/var/run/ceph:z -v /etc/localtime:/etc/localtime:ro>

5.3. Ceph 클러스터 상태 확인

Ceph 클러스터 상태를 확인하려면 다음 단계를 완료합니다.

절차

  1. 모든 컨트롤러 노드에 로그인합니다.
  2. Ceph 모니터 데몬에서 다음 명령을 입력합니다.

    $ sudo podman exec ceph-mon-controller-0 ceph -s
      cluster:
        id:     670dc288-cd36-4772-a4fc-47287f8e2ebf
        health: HEALTH_OK
    
      services:
        mon: 3 daemons, quorum controller-1,controller-2,controller-0 (age 14h)
        mgr: controller-1(active, since 8w), standbys: controller-0, controller-2
        mds: cephfs:1 {0=controller-2=up:active} 2 up:standby
        osd: 15 osds: 15 up (since 8w), 15 in (since 8w)
    
      task status:
        scrub status:
            mds.controller-2: idle
    
      data:
        pools: 6 pools, 192 pgs
        objects: 309 objects, 1.6 GiB
        usage: 21 GiB used, 144 GiB / 165 GiB avail
        pgs: 192 active+clean
    참고

    대기 모드에는 활성 MDS와 두 개의 MDS가 있습니다.

  3. Ceph File System의 자세한 상태를 보려면 다음 명령을 입력합니다.

    $ sudo ceph fs ls
    
    name: cephfs metadata pool: manila_metadata, data pools: [manila_data]
    참고

    이 예제 출력에서 cephfs 는 director가 공유 파일 시스템 서비스를 통해 사용자가 생성하는 CephFS 공유를 호스팅하기 위해 생성하는 Ceph 파일 시스템의 이름입니다.

5.4. manila-share 서비스 상태 확인

다음 단계를 완료하여 manila-share 서비스의 상태를 확인합니다.

절차

  1. 컨트롤러 노드 중 하나에서 다음 명령을 입력하여 openstack-manila-share 가 시작되었는지 확인합니다.

    $ sudo pcs status resources | grep manila
    
    * Container bundle: openstack-manila-share [cluster.common.tag/rhosp16-openstack-manila-share:pcmklatest]:
    * openstack-manila-share-podman-0	(ocf::heartbeat:podman):	Started controller-0

5.5. manila-api 서비스 확인 스케줄러 승인 및 서비스 공유

다음 단계를 완료하여 manila-api 서비스가 스케줄러를 승인하고 서비스를 공유하는지 확인합니다.

절차

  1. 언더클라우드에 로그인합니다.
  2. 다음 명령을 실행합니다.

    $ source /home/stack/overcloudrc
  3. 다음 명령을 입력하여 manila-scheduler 및 manila- share 가 활성화되어 있는지 확인합니다.

    $ manila service-list
    
    | Id | Binary          | Host             | Zone | Status | State | Updated_at |
    
    | 2 | manila-scheduler | hostgroup        | nova | enabled | up | 2018-08-08T04:15:03.000000 |
    | 5 | manila-share | hostgroup@cephfs | nova | enabled | up | 2018-08-08T04:15:03.000000 |

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
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, the Red Hat 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 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.