스토리지 가이드

Red Hat OpenStack Platform 17.0

OpenStack에서 영구 스토리지 이해, 사용 및 관리

초록

이 가이드에서는 Red Hat OpenStack Platform 환경에서 영구 스토리지를 사용하고 관리하기 위한 다양한 절차에 대해 자세히 설명합니다. 또한 각 영구 스토리지 유형의 OpenStack 서비스를 구성하고 관리하기 위한 절차가 포함되어 있습니다.

접두부

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

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

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견을 보내 주십시오. Red Hat이 어떻게 더 나은지 알려주십시오.

직접 문서 피드백(DDF) 기능 사용

피드백 추가 DDF 기능을 사용하여 특정 문장, 단락 또는 코드 블록에 대한 직접 의견을 제출할 수 있습니다.

  1. 다중 페이지 HTML 형식으로 문서를 봅니다.
  2. 문서의 오른쪽 상단에 피드백 버튼이 표시되는지 확인합니다.
  3. 주석 처리하려는 텍스트 부분을 강조 표시합니다.
  4. 피드백 추가를 클릭합니다.
  5. 코멘트를 사용하여 피드백 추가 필드를 완료합니다.
  6. 선택 사항: 문서 팀이 문제에 대한 자세한 설명을 위해 연락을 드릴 수 있도록 이메일 주소를 추가합니다.
  7. Submit(제출)을 클릭합니다.

1장. RHOSP(Red Hat OpenStack Platform)의 영구 스토리지 소개

Red Hat OpenStack Platform 내에서 스토리지는 세 가지 주요 서비스로 제공됩니다.

  • Block Storage(openstack-cinder)
  • Object Storage(openstack-swift)
  • 공유 파일 시스템 스토리지(openstack-manila)

이러한 서비스는 다양한 유형의 영구 스토리지를 제공하며 각각 다른 사용 사례에서 고유한 이점 세트를 제공합니다. 이 가이드에서는 일반적인 엔터프라이즈 스토리지 요구 사항에 대한 각 요구 사항에 대한 적합성에 대해 설명합니다.

RHOSP 대시보드 또는 명령줄 클라이언트를 사용하여 클라우드 스토리지를 관리할 수 있습니다. 두 방법을 사용하여 대부분의 절차를 수행할 수 있습니다. 그러나 명령행에서만 고급 절차 중 일부를 완료할 수 있습니다. 이 가이드에서는 가능한 경우 대시보드에 대한 절차를 제공합니다.

참고

Red Hat OpenStack Platform에 대한 전체 문서 제품군은 Red Hat OpenStack Platform 설명서 를 참조하십시오.

중요

이 안내서에서는 RuntimeClass를 사용하여 일부 사용자 지정 서비스 설정을 적용하는 방법에 대해 설명합니다. 따라서 먼저 EgressIP 패키지를 설치해야 합니다.

# dnf install crudini -y

RHOSP는 임시영구 스토리지 두 가지 유형의 스토리지를 인식합니다. 임시 스토리지는 특정 Compute 인스턴스와만 연결된 스토리지입니다. 해당 인스턴스가 종료되면 임시 스토리지입니다. 이 유형의 스토리지는 인스턴스의 운영 체제 저장과 같은 기본 런타임 요구 사항에 유용합니다.

영구 스토리지는 실행 중인 인스턴스와 별도로 유지(영구)되도록 설계되었습니다. 이 스토리지는 다른 인스턴스 또는 특정 인스턴스의 수명을 초과하여 재사용해야 하는 모든 데이터에 사용됩니다. RHOSP에서는 다음 유형의 영구 스토리지를 사용합니다.

볼륨

OpenStack Block Storage 서비스(openstack-cinder)를 사용하면 사용자가 볼륨을 통해 블록 스토리지 장치에 액세스할 수 있습니다. 사용자는 일반 용도의 영구 스토리지로 임시 스토리지를 보강하기 위해 볼륨을 인스턴스에 연결할 수 있습니다. 볼륨을 분리하여 원하는 인스턴스에 다시 연결할 수 있으며 연결된 인스턴스를 통해서만 액세스할 수 있습니다.

또한 볼륨은 백업 및 스냅샷을 통해 고유한 중복성과 재해 복구 기능을 제공합니다. 또한 추가 보안을 위해 볼륨을 암호화할 수도 있습니다.

참고

임시 스토리지는 전혀 사용하지 않도록 인스턴스를 구성할 수도 있습니다. 이러한 경우 블록 스토리지 서비스는 이미지를 볼륨에 쓸 수 있습니다. 그러면 볼륨을 인스턴스의 부팅 가능한 루트 볼륨으로 사용할 수 있습니다.

컨테이너

OpenStack Object Storage 서비스(openstack-swift)는 미디어 파일, 대용량 데이터 세트 및 디스크 이미지와 같은 모든 종류의 정적 데이터 또는 바이너리 오브젝트를 저장하는 데 사용되는 완전히 분산된 스토리지 솔루션을 제공합니다. 오브젝트 스토리지 서비스는 컨테이너를 사용하여 이러한 오브젝트를 구성합니다.

볼륨 콘텐츠에는 인스턴스를 통해서만 액세스할 수 있지만 컨테이너 내부의 오브젝트는 오브젝트 스토리지 REST API를 통해 액세스할 수 있습니다. 따라서 클라우드 내의 거의 모든 서비스에서 오브젝트 스토리지 서비스를 리포지토리로 사용할 수 있습니다.

shares
공유 파일 시스템 서비스(openstack-manila)는 원격, 공유 가능한 파일 시스템 또는 공유를 쉽게 프로비저닝할 수 있는 수단을 제공합니다. 공유를 사용하면 클라우드 내의 프로젝트를 공개적으로 스토리지를 공유할 수 있으며 여러 인스턴스에서 동시에 사용할 수 있습니다.

각 스토리지 유형은 특정 스토리지 요구 사항을 해결하도록 설계되었습니다. 컨테이너는 광범위한 액세스를 위해 설계되었으며 모든 스토리지 유형 중에서 최고 처리량, 액세스 및 내결함성을 사용할 수 있습니다. 컨테이너 사용량은 서비스에 더 적합합니다.

반면 볼륨은 주로 인스턴스 소비에 사용됩니다. 컨테이너와 동일한 수준의 액세스 및 성능을 누릴 수는 없지만 더 큰 기능 세트를 보유하고 컨테이너보다 기본 보안 기능을 더 많이 사용합니다. 공유는 여러 인스턴스에서 사용할 수 있다는 점을 제외하고 이와 관련하여 볼륨과 비슷합니다.

다음 섹션에서는 특정 스토리지 기준의 컨텍스트에서 각 스토리지 유형의 아키텍처 및 기능 세트를 자세히 설명합니다.

1.1. 확장성 및 백엔드 스토리지

일반적으로 클러스터형 스토리지 솔루션은 더 큰 백엔드 확장성을 제공합니다. 예를 들어, Red Hat Ceph를 Block Storage(cinder) 백엔드로 사용하면 Ceph OSD(Object Storage Daemon) 노드를 추가하여 스토리지 용량 및 중복성을 확장할 수 있습니다. 블록 스토리지 및 Object Storage(swift) 서비스 모두 Red Hat Ceph Storage를 백엔드로 지원합니다.

블록 스토리지 서비스는 여러 스토리지 솔루션을 개별 백엔드로 사용할 수 있습니다. 백엔드 수준에서 더 많은 백엔드를 추가하고 서비스를 다시 시작하여 용량을 확장할 수 있습니다. 블록 스토리지 서비스에는 지원되는 백엔드 솔루션의 대규모 목록도 포함되어 있으며 일부는 추가 확장성 기능을 제공합니다.

기본적으로 오브젝트 스토리지 서비스는 구성된 스토리지 노드에서 파일 시스템을 사용하며 사용 가능한 공간을 많이 사용할 수 있습니다. 오브젝트 스토리지 서비스는 XFS 및 ext4 파일 시스템을 지원하며, 둘 다 사용 가능한 기본 블록 스토리지를 사용하도록 확장할 수 있습니다. 스토리지 노드에 스토리지 장치를 추가하여 용량을 확장할 수도 있습니다.

Shared File Systems(manila) 서비스는 별도의 스토리지 풀에서 스토리지를 지원하는 공유를 프로비저닝합니다. 일반적으로 타사 백엔드 서비스에서 관리하는 이 풀은 파일 시스템 수준에서 스토리지와 공유합니다. Shared File Systems 서비스는 NetApp 및 CephFS를 모두 사용할 수 있으며, 이 경우 프로비저닝된 공유가 스토리지에 사용할 수 있는 미리 생성된 볼륨의 스토리지 풀을 사용하도록 구성할 수 있습니다. 두 배포 중 하나에서 확장에는 풀에 볼륨을 더 많이 추가해야 합니다.

1.2. 스토리지 접근성 및 관리

볼륨은 인스턴스를 통해서만 사용되며 한 번에 하나의 인스턴스 내에서만 연결하고 마운트할 수 있습니다. 사용자는 볼륨의 스냅샷을 생성할 수 있으며, 이는 볼륨을 이전 상태로 복제하거나 복원하는 데 사용할 수 있습니다( 1.4절. “스토리지 중복 및 재해 복구”참조). 블록 스토리지 서비스를 사용하면 새 볼륨을 생성할 때 사용자가 쉽게 호출할 수 있는 볼륨 유형 (예: 크기 및 백엔드)을 집계할 수 있습니다. 이러한 유형은 사용자를 위해 다른 스토리지 계층을 생성할 수 있는 QoS( Quality-of-Service ) 사양과 더 연관될 수 있습니다.

볼륨처럼 공유는 인스턴스를 통해 사용됩니다. 그러나 공유는 인스턴스 내에서 직접 마운트할 수 있으며 대시보드 또는 CLI를 통해 연결할 필요가 없습니다. 또한 여러 인스턴스에서 동시에 공유를 마운트할 수 있습니다. 공유 파일 시스템 서비스는 공유 스냅샷 및 복제도 지원합니다. 설정을 집계하기 위해 공유 유형을 생성할 수도 있습니다(볼륨 유형과 유사함).

컨테이너의 오브젝트는 API를 통해 액세스할 수 있으며 클라우드 내의 인스턴스 및 서비스에 액세스할 수 있습니다. 이렇게 하면 서비스의 오브젝트 리포지토리로서 이상적입니다. 예를 들어 이미지 서비스(예:openstack-glance)는 오브젝트 스토리지 서비스에서 관리하는 컨테이너에 해당 이미지를 저장할 수 있습니다.

1.3. 스토리지 보안

Block Storage 서비스(cinder)는 볼륨 암호화를 통해 기본 데이터 보안을 제공합니다. 이 경우 정적 키를 통해 암호화하도록 볼륨 유형을 구성할 수 있습니다. 키는 구성된 볼륨 유형에서 생성된 모든 볼륨을 암호화하는 데 사용됩니다. 자세한 내용은 2.7절. “Block Storage 서비스(cinder) 볼륨 암호화”의 내용을 참조하십시오.

오브젝트 및 컨테이너 보안은 서비스 및 노드 수준에서 구성됩니다. Object Storage 서비스(swift)는 컨테이너 및 오브젝트에 대한 네이티브 암호화를 제공하지 않습니다. 오브젝트 스토리지 서비스는 클라우드 내 액세스 가능성을 우선 순위를 지정하므로, 개체 데이터를 보호하기 위해 클라우드 네트워크 보안에만 의존합니다.

Shared File Systems 서비스(manila)는 인스턴스 IP, 사용자 또는 그룹 또는 TLS 인증서 등 액세스 제한을 통해 공유를 보호할 수 있습니다. 또한 일부 공유 파일 시스템 서비스 배포는 공유 네트워크와 공유 간의 관계를 관리하기 위해 별도의 공유 서버를 사용할 수 있습니다. 일부 공유 서버는 지원하거나 추가 네트워크 보안이 필요합니다. 예를 들어, CIFS 공유 서버에는 LDAP, Active Directory 또는 Kerberos 인증 서비스를 배포해야 합니다.

이미지 서명 및 검증 및 메타데이터 정의(metadef) API 제한과 같은 이미지 서비스(glance)를 보호하는 방법에 대한 자세한 내용은 이미지 생성 및 관리 가이드의 이미지 서비스를 참조하십시오.

1.4. 스토리지 중복 및 재해 복구

블록 스토리지 서비스는 볼륨 백업 및 복원 기능을 제공하여 사용자 스토리지에 대한 기본 재해 복구 기능을 제공합니다. 백업을 통해 볼륨 콘텐츠를 보호할 수 있습니다. 또한 이 서비스는 스냅샷을 지원합니다. 복제 외에도 스냅샷은 이전 상태로 볼륨을 복원하는 데 유용합니다.

다중backend 환경에서는 백엔드 간에 볼륨을 마이그레이션할 수도 있습니다. 이는 유지 관리를 위해 오프라인 상태로 백엔드를 수행해야 하는 경우에 유용합니다. 백업은 일반적으로 데이터 보호를 위해 소스 볼륨과 별도의 스토리지 백엔드에 저장됩니다. 그러나 스냅샷은 소스 볼륨에 따라 달라지므로 스냅샷에서는 이 작업을 수행할 수 없습니다.

또한 블록 스토리지 서비스는 동시 스냅샷 생성을 위해 볼륨을 함께 그룹화할 수 있는 일관성 그룹 생성을 지원합니다. 이를 통해 여러 볼륨에서 더 높은 수준의 데이터 일관성을 유지할 수 있습니다. 자세한 내용은 2.9절. “Block Storage 서비스(cinder) 일관성 그룹”를 참조하십시오.

오브젝트 스토리지 서비스는 기본 제공 백업 기능을 제공하지 않습니다. 따라서 모든 백업을 파일 시스템 또는 노드 수준에서 수행해야 합니다. 그러나 이 서비스는 보다 강력한 중복성과 내결함성을 제공합니다. 오브젝트 스토리지 서비스의 가장 기본적인 배포도 오브젝트를 여러 번 복제합니다. dm-multipath 와 같은 페일오버 기능을 사용하여 중복성을 향상시킬 수 있습니다.

공유 파일 시스템 서비스는 공유에 대한 기본 제공 백업 기능을 제공하지 않지만 복제 및 복원을 위해 스냅샷을 생성할 수 있습니다.

2장. Block Storage 서비스(cinder) 구성

Block Storage 서비스(cinder)는 모든 볼륨의 관리, 보안, 스케줄링 및 전체 관리를 관리합니다. 볼륨은 Compute 인스턴스의 기본 영구 스토리지로 사용됩니다.

볼륨 백업에 대한 자세한 내용은 블록 스토리지 백업 가이드 를 참조하십시오.

중요

Block Storage 서비스(cinder) 및 파이버 채널(FC) 백엔드를 사용하는 모든 배포의 모든 컨트롤러 노드 및 컴퓨팅 노드에 HBA(Host Bus Adapter)를 설치해야 합니다.

2.1. 블록 스토리지 서비스 백엔드

Red Hat OpenStack Platform은 OpenStack Platform director를 사용하여 배포됩니다. 이렇게 하면 블록 스토리지 서비스(및 확장에 따라 백엔드)를 포함하여 각 서비스를 올바르게 구성하는 데 도움이 됩니다. director에는 여러 통합 백엔드 설정도 있습니다.

Red Hat OpenStack Platform은 Red Hat Ceph 및 NFS as Block Storage(cinder) 백엔드를 지원합니다. 기본적으로 Block Storage 서비스는 LVM 백엔드를 볼륨의 리포지토리로 사용합니다. 이 백엔드는 테스트 환경에 적합하지만 프로덕션 환경에서는 LVM이 지원되지 않습니다.

OpenStack을 사용한 Ceph 배포 방법에 대한 자세한 내용은 Deploying an Overcloud with Containerized Red Hat Ceph 를 참조하십시오.

오버클라우드에서 NFS 스토리지를 설정하는 방법에 대한 자세한 내용은 Advanced Overcloud Customization 가이드 의 NFS 스토리지 구성을 참조하십시오.

지원되는 타사 스토리지 어플라이언스를 사용하도록 Block Storage 서비스를 구성할 수도 있습니다. director에는 다양한 백엔드 솔루션을 쉽게 배포하는 데 필요한 구성 요소가 포함되어 있습니다.

지원되는 백엔드 어플라이언스 및 드라이버의 전체 목록은 Red Hat OpenStack Platform의 Component, Plug-In 및 Driver 지원을 참조하십시오. 모든 타사 백엔드 어플라이언스 및 드라이버에는 추가 배포 가이드가 있습니다. 적절한 배포 가이드를 검토하여 백엔드 어플라이언스 또는 드라이버에 플러그인이 필요한지 확인합니다. 타사 스토리지 어플라이언스 플러그인을 배포하는 방법에 대한 자세한 내용은 Advanced Overcloud Customization 가이드의 공급업체 플러그인 배포를 참조하십시오.

2.2. 고가용성을 위한 활성-활성 블록 스토리지

활성-수동 모드에서 블록 스토리지 서비스가 하이퍼컨버지드 배포에서 실패하면 노드 펜싱이 바람직하지 않습니다. 이는 노드 펜싱에서 스토리지를 불필요하게 재조정할 수 있기 때문입니다. Edge 사이트는 Pacemaker가 여전히 제어 사이트에 있지만 Pacemaker는 Pacemaker를 배포하지 않습니다. 대신 에지 사이트는 고가용성 하이퍼컨버지드 배포를 지원하기 위해 Block Storage 서비스를 활성-활성 구성에 배포합니다.

활성-활성 배포에서는 확장, 성능을 향상시키고 사용 가능한 모든 노드에서 워크로드를 분산하여 응답 시간을 줄입니다. 활성-활성 구성에 블록 스토리지 서비스를 배포하면 부분적인 네트워크 중단 및 단일 노드 하드웨어 오류 발생 시 관리 계층을 유지 관리하는 고가용성 환경이 생성됩니다. 활성-활성 배포를 통해 클러스터는 노드가 중단되는 동안 Block Storage 서비스를 계속 제공할 수 있습니다.

그러나 활성-활성 배포에서는 워크플로가 자동으로 다시 시작될 수 있습니다. 서비스가 중지되면 오류가 발생한 노드에서 실행 중인 개별 작업도 중단 중에 실패합니다. 이 경우 서비스가 다운되었는지 확인하고 진행 중인 작업을 수행한 리소스 정리를 시작합니다.

2.2.1. 활성-활성 블록 스토리지 활성화

cinder-volume-active-active.yaml 파일을 사용하면 Block Storage 서비스를 활성 상태로 배포할 수 있습니다. 이 파일을 통해 director는 Pacemaker 이외의 cinder-volume heat 템플릿을 사용하고 etcd 서비스를 DLM(Distributed Lock Manager)으로 배포에 추가합니다.

cinder-volume-active-active.yaml 파일은 CinderVolumeCluster 매개변수에 값을 할당하여 활성-활성 클러스터 이름도 정의합니다. CinderVolumeCluster 는 글로벌 블록 스토리지 매개 변수입니다. 따라서 동일한 배포에 클러스터형(활성-활성) 및 비 클러스터형 백엔드를 포함할 수 없습니다.

중요

현재 Block Storage에 대한 활성-활성 구성은 Ceph RADOS Block Device(RBD) 백엔드에서만 작동합니다. 여러 백엔드를 사용하려는 경우 모든 백엔드에서 활성-활성 구성을 지원해야 합니다. 활성-활성 구성을 지원하지 않는 백엔드가 배포에 포함된 경우 해당 백엔드를 스토리지에 사용할 수 없습니다. 활성-활성 배포에서는 활성-활성 구성을 지원하지 않는 백엔드에 데이터를 저장하면 데이터 손실이 발생할 수 있습니다.

사전 요구 사항

  • 성공적인 언더클라우드 설치 자세한 내용은 Director 설치 및 사용 의 언더클라우드에 director 설치를 참조하십시오.

절차

활성-활성 Block Storage 서비스 볼륨을 활성화하려면 오버클라우드 배포에 다음 환경 파일을 포함합니다.

-e /usr/share/openstack-tripleo-heat-templates/environments/cinder-volume-active-active.yaml

2.2.2. 활성-활성 블록 스토리지 구성을 위한 유지 관리 명령

활성-활성 구성을 배포한 후에는 API 버전 3.17 이상을 사용할 때 환경과 상호 작용하는 데 사용할 수 있는 몇 가지 명령이 있습니다.

사용자 목표

명령

클러스터 이름, 호스트, 영역, 상태, 상태, 비활성화 이유, 백엔드 상태 등 서비스 목록을 참조하십시오.

참고: Ceph 백엔드에 대해 director에서 배포하는 경우 기본 클러스터 이름은 tripleo@tripleo_ceph 입니다.

Cinder service-list

개별 서비스와 달리 클러스터 전체에 대한 자세한 및 요약 정보를 참조하십시오.

Cinder cluster-list

참고: 이 명령을 실행하려면 cinder API 마이크로버전 3.7 이상이 필요합니다.

특정 클러스터에 대한 자세한 정보를 참조하십시오.

Cinder cluster-show <cluster_name>

참고: 이 명령을 실행하려면 cinder API 마이크로버전 3.7 이상이 필요합니다.

비활성화된 서비스를 활성화합니다.

Cinder cluster-enable <cluster_name>

참고: 이 명령을 실행하려면 cinder API 마이크로버전 3.7 이상이 필요합니다.

클러스터형 서비스를 비활성화합니다.

Cinder cluster-disable <cluster_name>

참고: 이 명령을 실행하려면 cinder API 마이크로버전 3.7 이상이 필요합니다.

2.2.3. 볼륨 관리 및 관리 해제

관리 및 관리 메커니즘을 사용하면 버전 X+1을 사용하여 버전 X를 사용하여 한 서비스에서 다른 서비스로 볼륨을 이동할 수 있습니다. 두 서비스 모두 이 프로세스 중에 계속 실행됩니다.

API 버전 3.17 이상에서는 블록 스토리지 클러스터에서 관리할 수 있는 볼륨 및 스냅샷 목록을 확인할 수 있습니다. 이러한 목록을 보려면 cinder manageable-list 또는 cinder snapshot-manageable-list 와 함께 --cluster 인수를 사용합니다.

API 버전 3.16 이상에서는 cinder manage 명령에서 이전에 관리되지 않는 볼륨을 Block Storage 클러스터에 추가할 수 있도록 --cluster 인수를 사용할 수도 있습니다.

2.2.4. 클러스터형 서비스의 볼륨 마이그레이션

API 버전 3.16 이상에서는 cinder migratecinder-manage 명령에서 --cluster 인수를 수락하여 활성-활성 배포의 대상을 정의합니다.

Block Storage 클러스터형 서비스에서 볼륨을 마이그레이션하는 경우 인수가 상호 배타적이기 때문에 선택 사항인 --cluster 인수를 전달하고 호스트 위치 인수를 생략합니다.

2.2.5. 블록 스토리지 서비스 유지 관리 시작

모든 블록 스토리지 볼륨 서비스는 시작할 때 자체 유지 관리를 수행합니다. 클러스터에 여러 볼륨 서비스가 그룹화된 환경에서는 현재 실행되지 않는 서비스를 정리할 수 있습니다.

work-cleanup 명령은 서버 정리를 트리거합니다. 이 명령은 다음을 반환합니다.

  • 명령이 정리할 수 있는 서비스 목록입니다.
  • 명령에서 현재 클러스터에서 실행되지 않기 때문에 명령이 정리할 수 없는 서비스 목록입니다.
참고

work-cleanup 명령은 API 버전 3.24 이상을 실행하는 서버에서만 작동합니다.

사전 요구 사항

  • 성공적인 언더클라우드 설치 자세한 내용은 Director 설치 및 사용 의 언더클라우드에 director 설치를 참조하십시오.

절차

  1. 다음 명령을 실행하여 클러스터의 모든 서비스가 실행 중인지 확인합니다.

    $ cinder cluster-list --detailed

    또는 cluster show 명령을 실행합니다.

  2. 서비스가 실행되고 있지 않은 경우 다음 명령을 실행하여 해당 특정 서비스를 확인합니다.

    $ cinder service-list
  3. 다음 명령을 실행하여 서버 정리를 트리거합니다.

    $ cinder work-cleanup [--cluster <cluster-name>] [--host <hostname>] [--binary <binary>] [--is-up <True|true|False|false>] [--disabled <True|true|False|false>] [--resource-id <resource-id>] [--resource-type <Volume|Snapshot>]
    참고

    --cluster,--host, --binary 와 같은 필터를 사용하여 명령이 정리되는 항목을 정의합니다. 특정 리소스를 포함하여 클러스터 이름, 호스트 이름, 서비스 유형 및 리소스 유형을 필터링할 수 있습니다. 필터링을 적용하지 않으면 명령에서 정리할 수 있는 모든 항목을 정리하려고 합니다.

    다음 예제에서는 클러스터 이름으로 필터링합니다.

    $ cinder work-cleanup --cluster tripleo@tripleo_ceph

2.3. 볼륨 유형의 그룹 볼륨 구성

Red Hat OpenStack Platform을 사용하면 볼륨 유형을 생성할 수 있으므로 볼륨 유형에 연결된 설정을 적용할 수 있습니다. 볼륨 생성 중에 설정을 적용할 수 있습니다. 3.1절. “블록 스토리지 볼륨 생성” 을 참조하십시오. 볼륨 생성 후 설정을 적용할 수도 있습니다. 4.5절. “블록 스토리지 볼륨 retyping” 을 참조하십시오. 다음 목록은 볼륨 유형에 적용할 수 있는 몇 가지 관련 설정을 보여줍니다.

설정은 Extra Specs라는 키-값 쌍을 사용하여 볼륨 유형과 연결됩니다. 볼륨 생성 중에 볼륨 유형을 지정하면 Block Storage 스케줄러는 이러한 키-값 쌍을 설정으로 적용합니다. 여러 키-값 쌍을 동일한 볼륨 유형에 연결할 수 있습니다.

볼륨 유형은 다른 사용자에게 스토리지 계층을 제공하는 기능을 제공합니다. 특정 성능, 복원력 및 기타 설정을 키-값 쌍으로 볼륨 유형에 연결하면 계층별 설정을 다른 볼륨 유형에 매핑할 수 있습니다. 그런 다음 해당 볼륨 유형을 지정하여 볼륨을 생성할 때 계층 설정을 적용할 수 있습니다.

2.3.1. 백엔드 드라이버 기능 나열

사용 가능하고 지원되는 Extra Specs는 백엔드 드라이버에 따라 다릅니다. 유효한 Extra Specs 목록을 보려면 드라이버 설명서를 참조하십시오.

또는 Block Storage 호스트를 직접 쿼리하여 해당 드라이버에서 지원하는 올바른 표준 Extra Specs를 확인할 수 있습니다. 블록 스토리지 서비스를 호스팅하는 노드에 로그인(명령줄을 통해)하여 시작합니다.

사전 요구 사항

  • 성공적인 언더클라우드 설치 자세한 내용은 Director 설치 및 사용 의 언더클라우드에 director 설치를 참조하십시오.

절차

# cinder service-list

이 명령은 각 블록 스토리지 서비스 호스트(cinder-backup,cinder-scheduler, cinder-volume)가 포함된 목록을 반환합니다. 예를 들면 다음과 같습니다.

+------------------+---------------------------+------+---------
|      Binary      |            Host           | Zone |  Status ...
+------------------+---------------------------+------+---------
|  cinder-backup   |   localhost.localdomain   | nova | enabled ...
| cinder-scheduler |   localhost.localdomain   | nova | enabled ...
|  cinder-volume   | *localhost.localdomain@lvm* | nova | enabled ...
+------------------+---------------------------+------+---------

드라이버 기능(및 차례로 블록 스토리지 서비스의 지원되는 Extra Specs)을 확인하려면 다음을 실행합니다.

# cinder get-capabilities _VOLSVCHOST_

여기서 VOLSVCHOSTcinder-volume 의 호스트의 전체 이름입니다. 예를 들면 다음과 같습니다.

# cinder get-capabilities localhost.localdomain@lvm
    +---------------------+-----------------------------------------+
    |     Volume stats    |                        Value            |
    +---------------------+-----------------------------------------+
    |     description     |                         None            |
    |     display_name    |                         None            |
    |    driver_version   |                        3.0.0            |
    |      namespace      | OS::Storage::Capabilities::localhost.loc...
    |      pool_name      |                         None            |
    |   storage_protocol  |                        iSCSI            |
    |     vendor_name     |                     Open Source         |
    |      visibility     |                         None            |
    | volume_backend_name |                         lvm             |
    +---------------------+-----------------------------------------+
    +--------------------+------------------------------------------+
    | Backend properties |                        Value             |
    +--------------------+------------------------------------------+
    |    compression     |      {u'type': u'boolean', u'description'...
    |        qos         |              {u'type': u'boolean', u'des ...
    |    replication     |      {u'type': u'boolean', u'description'...
    | thin_provisioning  | {u'type': u'boolean', u'description': u'S...
    +--------------------+------------------------------------------+

백엔드 속성 열에는 설정할 수 있는 Extra Spec Keys 목록이 표시되고 Value 열은 유효한 해당 값에 대한 정보를 제공합니다.

참고

사용 가능하고 지원되는 Extra Specs는 백엔드 드라이버에 따라 다릅니다. 유효한 Extra Specs 목록을 보려면 드라이버 설명서를 참조하십시오.

또는 Block Storage 호스트를 직접 쿼리하여 해당 드라이버에서 지원하는 올바른 표준 Extra Specs를 확인할 수 있습니다. 블록 스토리지 서비스를 호스팅하는 노드에 로그인(명령줄을 통해)하여 시작합니다. 그런 다음 다음을 수행합니다.

# cinder service-list

이 명령은 각 블록 스토리지 서비스 호스트(cinder-backup,cinder-scheduler, cinder-volume)가 포함된 목록을 반환합니다. 예를 들면 다음과 같습니다.

+------------------+---------------------------+------+---------
|      Binary      |            Host           | Zone |  Status ...
+------------------+---------------------------+------+---------
|  cinder-backup   |   localhost.localdomain   | nova | enabled ...
| cinder-scheduler |   localhost.localdomain   | nova | enabled ...
|  cinder-volume   | *localhost.localdomain@lvm* | nova | enabled ...
+------------------+---------------------------+------+---------

드라이버 기능(및 차례로 블록 스토리지 서비스의 지원되는 Extra Specs)을 확인하려면 다음을 실행합니다.

# cinder get-capabilities _VOLSVCHOST_

여기서 VOLSVCHOSTcinder-volume 의 호스트의 전체 이름입니다. 예를 들면 다음과 같습니다.

# cinder get-capabilities localhost.localdomain@lvm
    +---------------------+-----------------------------------------+
    |     Volume stats    |                        Value            |
    +---------------------+-----------------------------------------+
    |     description     |                         None            |
    |     display_name    |                         None            |
    |    driver_version   |                        3.0.0            |
    |      namespace      | OS::Storage::Capabilities::localhost.loc...
    |      pool_name      |                         None            |
    |   storage_protocol  |                        iSCSI            |
    |     vendor_name     |                     Open Source         |
    |      visibility     |                         None            |
    | volume_backend_name |                         lvm             |
    +---------------------+-----------------------------------------+
    +--------------------+------------------------------------------+
    | Backend properties |                        Value             |
    +--------------------+------------------------------------------+
    |    compression     |      {u'type': u'boolean', u'description'...
    |        qos         |              {u'type': u'boolean', u'des ...
    |    replication     |      {u'type': u'boolean', u'description'...
    | thin_provisioning  | {u'type': u'boolean', u'description': u'S...
    +--------------------+------------------------------------------+

백엔드 속성 열에는 설정할 수 있는 Extra Spec Keys 목록이 표시되고 Value 열은 유효한 해당 값에 대한 정보를 제공합니다.

2.3.2. 볼륨 유형 생성 및 구성

볼륨 유형에 연결된 설정을 적용할 수 있도록 볼륨 유형을 생성합니다. 볼륨 유형은 다른 사용자에게 스토리지 계층을 제공하는 기능을 제공합니다. 특정 성능, 복원력 및 기타 설정을 키-값 쌍으로 볼륨 유형에 연결하면 계층별 설정을 다른 볼륨 유형에 매핑할 수 있습니다. 그런 다음 해당 볼륨 유형을 지정하여 볼륨을 생성할 때 계층 설정을 적용할 수 있습니다.

사전 요구 사항

  • 성공적인 언더클라우드 설치 자세한 내용은 Director 설치 및 사용 의 언더클라우드에 director 설치를 참조하십시오.
  • 성공적인 오버클라우드 배포. 자세한 내용은 Director 설치 및 사용 에서 CLI 툴을 사용하여 기본 오버클라우드 생성 을 참조하십시오.
  • RHOSP(Red Hat OpenStack Platform) 대시보드(horizon)에 액세스합니다. 자세한 내용은 Director Installation and UsageOvercloud 배포 출력 을 참조하십시오.

절차

  1. 대시보드에서 admin 사용자로 Admin > Volumes > Volume Types 을 선택합니다.
  2. Create Volume Type 을 클릭합니다.
  3. 이름 필드에 볼륨 유형 이름을 입력합니다.
  4. Create Volume Type 을 클릭합니다. 새 유형이 볼륨 유형 표에 나타납니다.
  5. 볼륨 유형의 View Extra Specs 작업을 선택합니다.
  6. 생성 을 클릭하고 값을 지정합니다. 키-값 쌍이 유효해야 합니다. 그러지 않으면 볼륨 생성 중에 볼륨 유형을 지정하면 오류가 발생합니다.
  7. 생성을 클릭합니다. 이제 연결된 설정(키-값 쌍)이 Extra Specs 테이블에 표시됩니다.

기본적으로 모든 볼륨 유형은 모든 OpenStack 프로젝트에서 액세스할 수 있습니다. 제한된 액세스 권한으로 볼륨 유형을 생성해야 하는 경우 CLI를 통해 이 작업을 수행해야 합니다. 자세한 내용은 2.3.4절. “개인 볼륨 유형 생성 및 구성”에서 참조하십시오.

참고

QoS 사양을 볼륨 유형과 연결할 수도 있습니다. 자세한 내용은 2.6.3절. “QoS (Quality-of-Service) 사양을 볼륨 유형과 연결”의 내용을 참조하십시오.

2.3.3. 볼륨 유형 편집

대시보드에서 볼륨 유형을 편집하여 볼륨 유형의 Extra Specs 구성을 수정합니다.

사전 요구 사항

절차

  1. 대시보드에서 admin 사용자로 Admin > Volumes > Volume Types 을 선택합니다.
  2. Volume Types (볼륨 유형) 표에서 볼륨 유형의 View Extra Specs 작업을 선택합니다.
  3. 이 페이지의 Extra Specs 테이블에서 다음을 수행할 수 있습니다.

    • 볼륨 유형에 새 설정을 추가합니다. 이렇게 하려면 만들기를 클릭하고 볼륨 유형에 연결할 새 설정의 키/값 쌍을 지정합니다.
    • 설정의 편집 작업을 선택하여 볼륨 유형과 연결된 기존 설정을 편집합니다.
    • 추가 사양의 확인란을 선택하고 Delete Extra Specs in this 및 다음 대화 상자를 클릭하여 볼륨 유형과 관련된 기존 설정을 삭제합니다.

볼륨 유형을 삭제하려면 Volume Types (볼륨 유형) 표에서 해당 확인란을 선택하고 볼륨 유형 삭제를 클릭합니다.

2.3.4. 개인 볼륨 유형 생성 및 구성

기본적으로 모든 볼륨 유형은 모든 프로젝트에서 사용할 수 있습니다. 제한된 볼륨 유형을 프라이빗 으로 표시하여 생성할 수 있습니다. 이렇게 하려면 유형의 is-public 플래그를 false 로 설정합니다.

프라이빗 볼륨 유형은 특정 속성을 사용하여 볼륨에 대한 액세스를 제한하는 데 유용합니다. 일반적으로 이러한 설정은 특정 프로젝트에서만 사용할 수 있어야 하는 설정입니다. 예를 들면 테스트 중인 새 백엔드 또는 초고속 성능 구성이 포함됩니다.

사전 요구 사항

절차

$ cinder type-create --is-public false  <TYPE-NAME>

기본적으로 개인 볼륨 유형은 생성자에서만 액세스할 수 있습니다. 그러나 관리자 사용자는 다음 명령을 사용하여 개인 볼륨 유형을 찾아서 볼 수 있습니다.

$ cinder type-list --all

이 명령은 공용 볼륨 유형과 개인 볼륨 유형을 모두 나열하며 각각에 대한 이름과 ID도 포함합니다. 액세스 권한을 제공하려면 볼륨 유형의 ID가 필요합니다.

개인 볼륨 유형에 대한 액세스는 프로젝트 수준에서 부여됩니다. 프라이빗 볼륨 유형에 대한 프로젝트 액세스 권한을 부여하려면 다음을 실행합니다.

$ cinder  type-access-add --volume-type <TYPE-ID> --project-id <TENANT-ID>

개인 볼륨 유형에 액세스할 수 있는 프로젝트를 보려면 다음을 실행합니다.

$ cinder  type-access-list --volume-type <TYPE-ID>

개인 볼륨 유형의 액세스 목록에서 프로젝트를 제거하려면 다음을 실행합니다.

$ cinder  type-access-remove --volume-type <TYPE-ID> --project-id <TENANT-ID>
참고

기본적으로 관리 권한이 있는 사용자만 개인 볼륨 유형에 대한 액세스를 생성, 보기 또는 구성할 수 있습니다.

2.4. Block Storage 서비스(cinder)에 대한 내부 프로젝트 생성 및 구성

일부 블록 스토리지 기능(예: Image-Volume 캐시)에는 내부 테넌트를 구성해야 합니다. 블록 스토리지 서비스는 이 테넌트/프로젝트를 사용하여 일반 사용자에게 노출될 필요가 없는 블록 스토리지 항목을 관리합니다. 이러한 항목의 예로는 빈번한 볼륨 복제 또는 마이그레이션할 볼륨의 임시 사본을 위해 이미지가 캐시됩니다.

사전 요구 사항

절차

  1. 내부 프로젝트를 구성하려면 먼저 cinder-internal 이라는 일반 프로젝트와 사용자를 만듭니다. 이를 수행하려면 컨트롤러 노드에 로그인하고 다음을 실행합니다.
# openstack project create --enable --description "Block Storage Internal Project" cinder-internal
    +-------------+----------------------------------+
    |   Property  |              Value               |
    +-------------+----------------------------------+
    | description |  Block Storage Internal Tenant   |
    |   enabled   |               True               |
    |      id     | cb91e1fe446a45628bb2b139d7dccaef |
    |     name    |         cinder-internal          |
    +-------------+----------------------------------+
# openstack user create --project cinder-internal cinder-internal
    +----------+----------------------------------+
    | Property |              Value               |
    +----------+----------------------------------+
    |  email   |               None               |
    | enabled  |               True               |
    |    id    | 84e9672c64f041d6bfa7a930f558d946 |
    |   name   |         cinder-internal          |
    |project_id| cb91e1fe446a45628bb2b139d7dccaef |
    | username |         cinder-internal          |
    +----------+----------------------------------+

Extra Config 옵션을 추가하는 절차에서는 내부 프로젝트가 생성됩니다. 2.5절. “image-volume 캐시 구성” 을 참조하십시오.

2.5. image-volume 캐시 구성

블록 스토리지 서비스에는 이미지에서 볼륨을 생성할 때 사용할 수 있는 선택적 Image-Volume 캐시 가 있습니다. 이 캐시는 자주 사용하는 이미지에서 볼륨 생성 속도를 개선하도록 설계되었습니다. 이미지에서 볼륨을 생성하는 방법에 대한 자세한 내용은 3.1절. “블록 스토리지 볼륨 생성” 을 참조하십시오.

활성화된 경우 Image-Volume 캐시는 볼륨이 처음 생성될 때 이미지 사본을 저장합니다. 이 저장된 이미지는 다음에 이미지를 사용하여 볼륨을 생성할 때 성능을 향상시킬 수 있도록 블록 스토리지 백엔드에 로컬로 캐시됩니다. Image-Volume 캐시의 제한은 크기(GB), 이미지 수 또는 둘 다로 설정할 수 있습니다.

Image-Volume 캐시는 여러 백엔드에서 지원됩니다. 타사 백엔드를 사용하는 경우 이미지 볼륨 캐시 지원에 대한 자세한 내용은 해당 설명서를 참조하십시오.

참고

이미지 볼륨 캐시를 사용하려면 블록 스토리지 서비스에 대해 내부 테넌트 를 구성해야 합니다. 자세한 내용은 2.4절. “Block Storage 서비스(cinder)에 대한 내부 프로젝트 생성 및 구성”에서 참조하십시오.

사전 요구 사항

  • 성공적인 언더클라우드 설치 자세한 내용은 Director 설치 및 사용 의 언더클라우드에 director 설치를 참조하십시오.

절차

백엔드(BACKEND)에서 Image-Volume 캐시를 활성화 및 구성하려면 언더클라우드의 환경 파일의 ExtraConfig 섹션에 값을 추가합니다. 예를 들면 다음과 같습니다.

parameter_defaults:
  ExtraConfig:
    cinder::config::cinder_config:
      DEFAULT/cinder_internal_tenant_project_id:
        value: TENANTID
      DEFAULT/cinder_internal_tenant_user_id:
        value: USERID
      BACKEND/image_volume_cache_enabled: 1
        value: True
      BACKEND/image_volume_cache_max_size_gb:
        value: MAXSIZE 2
      BACKEND/image_volume_cache_max_count:
        value: MAXNUMBER 3
1
BACKEND 를 대상 백엔드의 이름(특히 volume_backend_name 값)으로 바꿉니다.
2
기본적으로 Image-Volume 캐시 크기는 백엔드에서만 제한됩니다. MAXSIZE 를 GB 단위로 변경합니다.
3
MAXNUMBER 를 사용하여 최대 이미지 수를 설정할 수도 있습니다.

블록 스토리지 서비스 데이터베이스는 타임스탬프를 사용하여 각 캐시된 이미지가 이미지를 생성하는 데 마지막으로 사용된 시기를 추적합니다. MAXSIZEMAXNUMBER 가 모두 설정된 경우 블록 스토리지 서비스는 필요에 따라 캐시된 이미지를 삭제하여 새 이미지를 만듭니다. 가장 오래된 타임스탬프가 있는 캐시된 이미지는 Image-Volume 캐시 제한이 충족될 때마다 먼저 삭제됩니다.

/home/stack/templates/ 에서 환경 파일을 생성한 후 stack 사용자로 로그인하고 다음을 실행하여 구성을 배포합니다.

$ openstack overcloud deploy --templates \
-e /home/stack/templates/<ENV_FILE>.yaml

여기서 ENV_FILE.yaml 은 이전에 ExtraConfig 설정이 추가된 파일의 이름입니다.

중요

오버클라우드를 생성할 때 추가 환경 파일을 전달한 경우 -e 옵션을 사용하여 여기에서 다시 전달하여 오버클라우드를 원치 않는 변경을 방지합니다.

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

2.6. Block Storage 서비스(cinder) QoS (Quality-of-Service)

여러 성능 설정을 하나의 QoS (Quality-of-Service 사양)에 매핑할 수 있습니다. 이렇게 하면 다양한 사용자 유형에 대한 성능 계층을 제공할 수 있습니다.

성능 설정은 볼륨 설정이 볼륨 유형과 연결된 방식과 유사하게 키-값 쌍으로 QOS Specs에 매핑됩니다. 그러나 QOS Specs는 다음과 같은 점에서 볼륨 유형과 다릅니다.

  • QOS Specs는 읽기/쓰기 작업을 디스크에 제한하는 성능 설정을 적용하는 데 사용됩니다. 사용 가능하고 지원되는 성능 설정은 스토리지 드라이버마다 다릅니다.

    백엔드에서 지원하는 QOS Specs를 확인하려면 백엔드 장치의 볼륨 드라이버 설명서를 참조하십시오.

  • 볼륨 유형은 볼륨에 직접 적용되지만 QOS Specs는 그렇지 않습니다. 대신 QOS Specs는 볼륨 유형과 연결되어 있습니다. 볼륨 생성 중에 볼륨 유형을 지정하면 볼륨 유형의 관련 QOS Specs에 매핑된 성능 설정도 적용됩니다.

기본 볼륨 QOS 값을 사용하여 볼륨별로 볼륨 성능 제한을 정의할 수 있습니다. 블록 스토리지 서비스는 다음 옵션을 지원합니다.

  • read_iops_sec
  • write_iops_sec
  • total_iops_sec
  • read_bytes_sec
  • write_bytes_sec
  • total_bytes_sec
  • read_iops_sec_max
  • write_iops_sec_max
  • total_iops_sec_max
  • read_bytes_sec_max
  • write_bytes_sec_max
  • total_bytes_sec_max
  • size_iops_sec

2.6.1. 서비스 품질 사양 생성 및 구성

관리자는 QOS Specs 테이블을 통해 QOS Specs를 만들고 구성할 수 있습니다. 두 개 이상의 키/값 쌍을 동일한 QOS Spec에 연결할 수 있습니다.

사전 요구 사항

절차

  1. 대시보드에서 admin 사용자로 Admin > Volumes > Volume Types 을 선택합니다.
  2. QOS Specs 표에서 Create QOS Specs를 클릭합니다.
  3. QOS Spec 의 이름을 입력합니다.
  4. Consumer 필드에서 QOS 정책을 적용해야 하는 위치를 지정합니다.

    표 2.1. 소비자 유형

    유형설명

    back-end

    QOS 정책은 블록 스토리지 백엔드에 적용됩니다.

    front-end

    QOS 정책은 Compute에 적용됩니다.

    둘 다

    QOS 정책은 블록 스토리지 및 컴퓨팅 모두에 적용됩니다.

  5. 생성을 클릭합니다. 이제 새 QOS Spec이 QOS Specs 테이블에 나타납니다.
  6. QOS Specs 테이블에서 새 사양의 Manage Specs 작업을 선택합니다.
  7. Create 를 클릭하고 Key and Value 를 지정합니다. 키-값 쌍이 유효해야 합니다. 그렇지 않으면 볼륨 생성 중에 이 QOS Spec와 연결된 볼륨 유형을 지정할 수 없습니다.

    예를 들어 읽기 제한 IOPS를 500 으로 설정하려면 다음 키/값 쌍을 사용합니다.

    read_iops_sec=500
  8. 생성을 클릭합니다. 이제 연결된 설정(키-값 쌍)이 Key-Value pairs 테이블에 표시됩니다.

2.6.2. 용량에서 파생된 서비스 품질 제한 설정

볼륨 유형을 사용하여 볼륨에서 용량 파생된 QoS(Quality-of-Service) 제한을 구현할 수 있습니다. 이를 통해 프로비저닝된 볼륨 크기에 따라 결정적 IOPS 처리량을 설정할 수 있습니다. 이렇게 하면 사용자에게 스토리지 리소스가 제공되는 방법이 간소화되어 사용자가 프로비저닝하는 볼륨 크기에 따라 사전 결정(및, 결과적으로 예측 가능한) 처리량 속도를 제공합니다.

특히 Block Storage 서비스를 사용하면 실제 프로비저닝된 크기에 따라 볼륨에 할당할 IOPS의 양을 설정할 수 있습니다. 이 처리량은 다음 QoS 키를 통해 GB당 IOPS로 설정됩니다.

read_iops_sec_per_gb
write_iops_sec_per_gb
total_iops_sec_per_gb

이러한 키를 사용하면 프로비저닝된 볼륨의 크기로 읽기, 쓰기 또는 총 IOPS를 설정할 수 있습니다. 예를 들어 볼륨 유형에서 read_iops_sec_per_gb=500 을 사용하는 경우 프로비저닝된 3GB 볼륨에 자동으로 IOPS가 1500으로 읽습니다.

용량 파생된 QoS 제한은 볼륨 유형별로 설정되고 일반 QoS 사양처럼 구성됩니다. 또한 이러한 제한은 기본 블록 스토리지 서비스에서 직접 지원되며 특정 드라이버에 의존하지 않습니다.

볼륨 유형에 대한 자세한 내용은 2.3절. “볼륨 유형의 그룹 볼륨 구성”2.3.2절. “볼륨 유형 생성 및 구성” 를 참조하십시오. QoS 사양을 설정하는 방법에 대한 자세한 내용은 2.6절. “Block Storage 서비스(cinder) QoS (Quality-of-Service)”

주의

용량 파생 QoS 제한이 있는 볼륨 유형을 적용하거나 볼륨 재유형을 수행할 때 제한은 적용되지 않습니다. 제한은 인스턴스에서 볼륨을 분리한 후에만 적용됩니다.

볼륨 re-typing에 대한 정보는 4.5절. “블록 스토리지 볼륨 retyping” 를 참조하십시오.

2.6.3. QoS (Quality-of-Service) 사양을 볼륨 유형과 연결

관리자는 Volume Types 테이블을 사용하여 QOS Spec을 기존 볼륨 유형과 연결할 수 있습니다.

사전 요구 사항

절차

  1. 대시보드의 관리자로 관리자 > 볼륨 > 볼륨 유형을 선택합니다.
  2. Volume Types (볼륨 유형) 표에서 유형 Manage QOS Spec association 작업을 선택합니다.
  3. QOS Spec to be associated (연결할 QOS Spec) 목록에서 QOS Spec를 선택합니다. 기존 볼륨 유형에서 QOS 사양의 연결을 끊으려면 None 을 선택합니다.
  4. Associate 를 클릭합니다. 선택한 QOS Spec가 편집된 볼륨 유형의 Associated QOS Spec 열에 표시됩니다.

2.7. Block Storage 서비스(cinder) 볼륨 암호화

볼륨 암호화는 볼륨 백엔드가 손상되거나 잘못된 경우 기본 데이터 보호 기능을 제공합니다. Compute 및 Block Storage 서비스가 모두 통합되어 인스턴스가 액세스를 읽고 암호화된 볼륨을 사용할 수 있도록 합니다. 볼륨 암호화를 사용하려면 Barbican을 배포해야 합니다.

중요
  • 파일 기반 볼륨(예: NFS)에서는 볼륨 암호화가 지원되지 않습니다.
  • 암호화된 볼륨에 암호화 데이터를 저장하는 데 추가 공간이 필요하므로 암호화되지 않은 볼륨을 동일한 크기의 암호화된 볼륨으로 다시 삭제할 수 없습니다. 암호화되지 않은 볼륨을 암호화하는 방법에 대한 자세한 내용은 암호화되지 않은 볼륨 암호화를 참조하십시오.

볼륨 암호화는 볼륨 유형을 통해 적용됩니다. 암호화된 볼륨 유형에 대한 자세한 내용은 2.7.2절. “CLI를 사용하여 블록 스토리지 서비스 볼륨 암호화 구성” 을 참조하십시오.

2.7.1. 대시보드를 사용하여 블록 스토리지 서비스 볼륨 암호화 구성

암호화된 볼륨을 생성하려면 먼저 암호화된 볼륨 유형이 필요합니다. 볼륨 유형을 암호화하려면 사용해야 하는 공급자 클래스, 암호 및 키 크기를 설정해야 합니다.

사전 요구 사항

절차

  1. 대시보드에서 admin 사용자로 Admin > Volumes > Volume Types 을 선택합니다.
  2. 암호화할 볼륨의 Actions (작업) 열에서 암호화 생성을 선택하여 Create Volume Type Encryption 마법사를 시작합니다.
  3. 여기서 볼륨 유형 암호화의 공급자,Control Location,Cipher, Key Size 설정을 구성합니다. Description (설명) 열은 각 설정을 설명합니다.

    중요

    아래 나열된 값은 공급자,Cipher키 크기에 대해 지원되는 유일한 옵션입니다.

    1. 공급자luks 를 입력합니다.
    2. Cipheraes-xts-plain64 를 입력합니다.
    3. 크기에 256 을 입력합니다.
  4. Create Volume Type Encryption 을 클릭합니다.

암호화된 볼륨 유형이 있으면 이를 호출하여 암호화된 볼륨을 자동으로 생성할 수 있습니다. 볼륨 유형 생성에 대한 자세한 내용은 2.3.2절. “볼륨 유형 생성 및 구성” 을 참조하십시오. 특히 볼륨 생성 창의 유형 드롭다운 목록에서 암호화된 볼륨 유형을 선택합니다.

CLI를 통해 암호화된 볼륨 유형을 구성하려면 2.7.2절. “CLI를 사용하여 블록 스토리지 서비스 볼륨 암호화 구성” 을 참조하십시오.

암호화된 볼륨 유형의 암호화 설정을 다시 구성할 수도 있습니다.

  1. 볼륨 유형의 Actions (작업) 열에서 Update Encryption (암호 업데이트)을 선택하여 Update Volume Type Encryption 마법사를 시작합니다.
  2. Project > Compute > Volumes 에서 Volumes 테이블의 Encrypted 열을 확인하여 볼륨이 암호화되었는지 확인합니다.
  3. 볼륨이 암호화되면 해당 열에서 Yes 를 클릭하여 암호화 설정을 확인합니다.

2.7.2. CLI를 사용하여 블록 스토리지 서비스 볼륨 암호화 구성

암호화된 볼륨을 생성하려면 먼저 암호화된 볼륨 유형이 필요합니다. 볼륨 유형을 암호화하려면 사용해야 하는 공급자 클래스, 암호 및 키 크기를 설정해야 합니다.

사전 요구 사항

절차

  1. 볼륨 유형을 생성합니다.

    $ cinder type-create encrypt-type
  2. 암호화 방식, 키 크기, 제어 위치, 공급자 설정을 구성합니다.

    $ cinder encryption-type-create --cipher aes-xts-plain64 --key-size 256 --control-location front-end encrypt-type luks
  3. 암호화된 볼륨을 생성합니다.

    $ cinder --debug create 1 --volume-type encrypt-type --name DemoEncVol

자세한 내용은 OpenStack Key Manager 가이드를 사용하여 시크릿 관리를 참조하십시오.

2.7.3. 볼륨 이미지 암호화 키 자동 삭제

블록 스토리지 서비스(cinder)는 암호화된 볼륨을 Image 서비스(glance)에 업로드할 때 키 관리 서비스(barbican)에 암호화 키를 생성합니다. 이렇게 하면 암호화 키와 저장된 이미지 사이에 1:1 관계가 생성됩니다.

암호화 키를 삭제하면 키 관리 서비스의 리소스가 무제한으로 소비되는 것을 방지할 수 있습니다. 블록 스토리지, 키 관리 및 이미지 서비스는 키 삭제를 포함하여 암호화된 볼륨의 키를 자동으로 관리합니다.

블록 스토리지 서비스는 볼륨 이미지에 두 개의 속성을 자동으로 추가합니다.

  • cinder_encryption_key_id - 키 관리 서비스에서 특정 이미지에 저장하는 암호화 키의 식별자입니다.
  • cinder_encryption_key_deletion_policy - Image 서비스에 이 이미지와 연결된 키를 삭제할지 여부를 알리는 정책입니다.
중요

이러한 속성의 값은 자동으로 할당됩니다. 의도하지 않은 데이터 손실을 방지하려면 이러한 값을 조정하지 마십시오.

볼륨 이미지를 생성할 때 Block Storage 서비스는 cinder_encryption_key_deletion_policy 속성을 on_image_deletion 으로 설정합니다. 볼륨 이미지를 삭제하면 cinder_encryption_key_deletion_policyon_image_deletion 인 경우 이미지 서비스에서 해당 암호화 키를 삭제합니다.

중요

Red Hat은 cinder_encryption_key_id 또는 cinder_encryption_key_deletion_policy 속성을 수동으로 조작하지 않는 것이 좋습니다. cinder_encryption_key_id 값으로 식별되는 암호화 키를 사용하는 경우 데이터가 손실될 수 있습니다.

2.8. Block Storage 볼륨 백엔드의 가용성 영역 배포

가용 영역은 클라우드 인스턴스 및 서비스를 그룹화하는 공급자 고유의 메서드입니다. director는 CinderXXXAvailabilityZone 매개 변수(여기서 XXX 가 특정 백엔드와 연결됨)를 사용하여 Block Storage 볼륨 백엔드에 대해 다른 가용성 영역을 구성합니다.

사전 요구 사항

절차

  1. 환경 파일에 다음 매개 변수를 추가하여 두 개의 가용성 영역을 생성합니다.

    parameter_defaults:
     CinderXXXAvailabilityZone: zone1
     CinderYYYAvailabilityZone: zone2

    XXXYYY 를 다음과 같이 지원되는 백엔드 값으로 바꿉니다.

    CinderISCSIAvailabilityZone
    CinderNfsAvailabilityZone
    CinderRbdAvailabilityZone
    참고

    /usr/share/openstack-tripleo-heat-templates/deployment/cinder/ 디렉터리에 올바른 백엔드의 백엔드와 연결된 heat 템플릿을 검색합니다.

    다음 예제에서는 rbd 가 영역 1인 두 개의 백엔드를 배포하고 iSCSI 는 영역 2입니다.

    parameter_defaults:
     CinderRbdAvailabilityZone: zone1
     CinderISCSIAvailabilityZone: zone2
  2. 오버클라우드를 배포하고 업데이트된 환경 파일을 포함합니다.

2.9. Block Storage 서비스(cinder) 일관성 그룹

Block Storage(cinder) 서비스를 사용하여 일관성 그룹을 설정하여 여러 볼륨을 단일 엔티티로 그룹화할 수 있습니다. 즉, 개별적으로 대신 여러 볼륨에서 동시에 작업을 수행할 수 있습니다. 일관성 그룹을 사용하여 여러 볼륨의 스냅샷을 동시에 생성할 수 있습니다. 즉, 해당 볼륨을 동시에 복원하거나 복제할 수 있습니다.

볼륨은 여러 일관성 그룹의 멤버가 될 수 있습니다. 그러나 일관성 그룹에 볼륨을 추가 한 후 볼륨을 삭제, 다시 입력 또는 마이그레이션할 수 없습니다.

2.9.1. 블록 스토리지 서비스 일관성 그룹 구성

기본적으로 Block Storage 보안 정책은 일관성 그룹 API를 비활성화합니다. 기능을 사용하기 전에 여기에서 활성화해야 합니다. Block Storage API 서비스를 호스팅하는 노드의 /etc/cinder/policy.json 파일의 관련 일관성 그룹 항목인 openstack-cinder-api 가 기본 설정을 나열합니다.

"consistencygroup:create" : "group:nobody",
"consistencygroup:delete": "group:nobody",
"consistencygroup:update": "group:nobody",
"consistencygroup:get": "group:nobody",
"consistencygroup:get_all": "group:nobody",
"consistencygroup:create_cgsnapshot" : "group:nobody",
"consistencygroup:delete_cgsnapshot": "group:nobody",
"consistencygroup:get_cgsnapshot": "group:nobody",
"consistencygroup:get_all_cgsnapshots": "group:nobody",

환경 파일에서 이러한 설정을 변경한 다음 openstack overcloud deploy 명령을 사용하여 오버클라우드에 배포해야 합니다. 다음에 오버클라우드를 배포할 때 변경 사항이 덮어쓰므로 JSON 파일을 직접 편집하지 마십시오.

사전 요구 사항

절차

  1. 환경 파일을 편집하고 parameter_defaults 섹션에 새 항목을 추가합니다. 이렇게 하면 컨테이너에서 항목이 업데이트되며 openstack overcloud deploy 명령을 사용하여 director에서 환경을 다시 배포할 때마다 해당 항목이 유지됩니다.
  2. CinderApiPolicies 를 사용하여 환경 파일에 새 섹션을 추가하여 일관성 그룹 설정을 설정합니다. JSON 파일의 기본 설정이 있는 동일한 parameter_defaults 섹션이 다음과 같이 표시됩니다.

    parameter_defaults:
      CinderApiPolicies: { \
         cinder-consistencygroup_create: { key: 'consistencygroup:create', value: 'group:nobody' }, \
         cinder-consistencygroup_delete: { key: 'consistencygroup:delete', value: 'group:nobody' },  \
         cinder-consistencygroup_update: { key: 'consistencygroup:update', value: 'group:nobody' }, \
         cinder-consistencygroup_get: { key: 'consistencygroup:get', value: 'group:nobody' }, \
         cinder-consistencygroup_get_all: { key: 'consistencygroup:get_all', value: 'group:nobody' }, \
         cinder-consistencygroup_create_cgsnapshot: { key: 'consistencygroup:create_cgsnapshot', value: 'group:nobody' }, \
         cinder-consistencygroup_delete_cgsnapshot: { key: 'consistencygroup:delete_cgsnapshot', value: 'group:nobody' }, \
         cinder-consistencygroup_get_cgsnapshot: { key: 'consistencygroup:get_cgsnapshot', value: 'group:nobody' }, \
         cinder-consistencygroup_get_all_cgsnapshots: { key: 'consistencygroup:get_all_cgsnapshots', value: 'group:nobody' }, \
     }
  3. 'group:nobody' 값에 따라 그룹이 이 기능을 사용할 수 없으므로 효과적으로 비활성화되지 않도록 합니다. 이를 활성화하려면 그룹을 다른 값으로 변경합니다.
  4. 보안을 강화하려면 일관성 그룹 API 및 볼륨 유형 관리 API에 대한 권한이 동일하도록 설정합니다. 볼륨 유형 관리 API는 기본적으로 동일한 /etc/cinder/policy.json_ 파일에서 "rule:admin_or_owner" 로 설정됩니다.

    "volume_extension:types_manage": "rule:admin_or_owner",
  5. 모든 사용자가 일관성 그룹을 사용할 수 있도록 하려면 사용자가 자체 일관성 그룹을 생성, 사용 및 관리할 수 있도록 API 정책 항목을 설정합니다. 이렇게 하려면 rule:admin_or_owner:를 사용합니다.

    CinderApiPolicies: { \
         cinder-consistencygroup_create: { key: 'consistencygroup:create', value: 'rule:admin_or_owner' }, \
         cinder-consistencygroup_delete: { key: 'consistencygroup:delete', value: 'rule:admin_or_owner' },  \
         cinder-consistencygroup_update: { key: 'consistencygroup:update', value: 'rule:admin_or_owner' }, \
         cinder-consistencygroup_get: { key: 'consistencygroup:get', value: 'rule:admin_or_owner' }, \
         cinder-consistencygroup_get_all: { key: 'consistencygroup:get_all', value: 'rule:admin_or_owner' }, \
         cinder-consistencygroup_create_cgsnapshot: { key: 'consistencygroup:create_cgsnapshot', value: 'rule:admin_or_owner' }, \
         cinder-consistencygroup_delete_cgsnapshot: { key: 'consistencygroup:delete_cgsnapshot', value: 'rule:admin_or_owner' }, \
         cinder-consistencygroup_get_cgsnapshot: { key: 'consistencygroup:get_cgsnapshot', value: 'rule:admin_or_owner' }, \
         cinder-consistencygroup_get_all_cgsnapshots: { key: 'consistencygroup:get_all_cgsnapshots', value: 'rule:admin_or_owner’ }, \
     }
  6. /home/stack/templates/ 에서 환경 파일을 생성한 경우 stack 사용자로 로그인하여 구성을 배포합니다.

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/<ENV_FILE>.yaml

    <ENV_FILE.yaml> 을 파일 이름으로 추가한 ExtraConfig 설정으로 변경합니다.

    중요

    오버클라우드를 생성할 때 추가 환경 파일을 전달한 경우 -e 옵션을 사용하여 오버클라우드를 원치 않는 변경을 방지하여 환경 파일을 다시 전달합니다.

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

2.9.2. 대시보드를 사용하여 블록 스토리지 일관성 그룹 생성

일관성 그룹 API를 활성화한 후 일관성 그룹을 생성할 수 있습니다.

사전 요구 사항

절차

  1. 대시보드에서 admin 사용자로 Project > Compute > Volumes > Volume Consistency Groups 를 선택합니다.
  2. Create Consistency Group 을 클릭합니다.
  3. 마법사의 일관성 그룹 정보 탭에 일관성 그룹에 대한 이름 및 설명을 입력합니다.In the Consistency Group Information tab of the wizard, enter a name and description for your consistency group. 그런 다음 가용성 영역을 지정합니다.
  4. 일관성 그룹에 볼륨 유형을 추가할 수도 있습니다. 일관성 그룹 내에서 볼륨을 생성할 때 Block Storage 서비스는 해당 볼륨 유형의 호환 설정을 적용합니다. 볼륨 유형을 추가하려면 사용 가능한 모든 볼륨 유형 목록에서 + 버튼을 클릭합니다.
  5. Create Consistency Group 을 클릭합니다. Volume Consistency Groups (볼륨 일관성 그룹) 테이블에 다음에 표시됩니다.

2.9.3. 대시보드를 사용하여 블록 스토리지 서비스 일관성 그룹 관리

RHOSP(Red Hat OpenStack Platform) 대시보드를 사용하여 블록 스토리지 볼륨의 일관성 그룹을 관리합니다.

사전 요구 사항

  • 성공적인 언더클라우드 설치 자세한 내용은 Director 설치 및 사용 의 언더클라우드에 director 설치를 참조하십시오.
  • 성공적인 오버클라우드 배포. 자세한 내용은 Director 설치 및 사용 에서 CLI 툴을 사용하여 기본 오버클라우드 생성 을 참조하십시오.
  • RHOSP(Red Hat OpenStack Platform) 대시보드(horizon)에 액세스합니다. 자세한 내용은 Director Installation and UsageOvercloud 배포 출력 을 참조하십시오.

절차

  1. 선택 사항: Action (작업) 열에서 Edit Consistency Group 을 선택하여 일관성 그룹의 이름 또는 설명을 변경할 수 있습니다.
  2. 대시보드에서 admin 사용자로 일관성 그룹에서 볼륨을 직접 추가하거나 제거하려면 프로젝트 > Compute > Volumes > Volume Consistency Groups 을 선택합니다.
  3. 구성할 일관성 그룹을 찾습니다. 일관성 그룹의 작업 열에서 볼륨 관리를 선택합니다. 그러면 Add/Remove Consistency Group Volumes 마법사가 실행됩니다.

    1. 일관성 그룹에 볼륨을 추가하려면 사용 가능한 모든 볼륨 목록에서 + 버튼을 클릭합니다.
    2. 일관성 그룹에서 볼륨을 제거하려면 선택한 볼륨 목록에서 - 버튼을 클릭합니다.
  4. Edit Consistency Group 을 클릭합니다.

2.9.4. Block Storage 서비스의 일관성 그룹 스냅샷 생성 및 관리

일관성 그룹에 볼륨을 추가한 후 이제 해당 그룹에서 스냅샷을 생성할 수 있습니다.

사전 요구 사항

절차

  1. openstack-cinder-api 를 호스팅하는 노드의 명령줄에서 admin 사용자로 로그인하여 다음을 입력합니다.

    # export OS_VOLUME_API_VERSION=2

    이렇게 하면 openstack-cinder-api 의 버전 2 를 사용하도록 클라이언트가 구성됩니다.

  2. 사용 가능한 모든 일관성 그룹 및 해당 ID를 나열합니다.

    # cinder consisgroup-list
  3. 일관성 그룹을 사용하여 스냅샷을 생성합니다.

    # cinder cgsnapshot-create --name <CGSNAPNAME> --description "<DESCRIPTION>" <CGNAMEID>

    교체:

    • <CGSNAPNAME> 스냅샷 이름과 함께 (선택 사항)
    • 스냅샷에 대한 설명이 있는 <DESCRIPTION&gt;(선택 사항).
    • <CGNAMEID> 는 일관성 그룹의 이름 또는 ID가 있습니다.
  4. 사용 가능한 모든 일관성 그룹 스냅샷을 표시합니다.

    # cinder cgsnapshot-list

2.9.5. 블록 스토리지 서비스 일관성 그룹 복제

일관성 그룹을 사용하여 사전 구성된 볼륨의 전체 배치를 동시에 생성할 수도 있습니다. 기존 일관성 그룹을 복제하거나 일관성 그룹 스냅샷을 복원하여 이 작업을 수행할 수 있습니다. 두 프로세스 모두 동일한 명령을 사용합니다.

사전 요구 사항

절차

  1. 기존 일관성 그룹을 복제하려면 다음을 수행합니다.

    # cinder consisgroup-create-from-src --source-cg <CGNAMEID> --name <CGNAME> --description "<DESCRIPTION>"

    교체:

    • <CGNAMEID> 는 복제하려는 일관성 그룹의 이름 또는 ID입니다.
    • <CGNAME> 은 일관성 그룹의 이름입니다(선택 사항).
    • <DESCRIPTION> 은 일관성 그룹에 대한 설명입니다(선택 사항).
  2. 일관성 그룹 스냅샷에서 일관성 그룹을 생성하려면 다음을 수행합니다.

    # cinder consisgroup-create-from-src --cgsnapshot <CGSNAPNAME> --name <CGNAME> --description "<DESCRIPTION>

    <CGSNAPNAME> 을 일관성 그룹을 생성하기 위해 사용하는 스냅샷의 이름 또는 ID로 바꿉니다.

2.10. 볼륨 생성을 위한 백엔드 지정

여러 블록 스토리지(cinder) 백엔드가 구성되어 있을 때마다 각 백엔드에 대한 볼륨 유형도 생성해야 합니다. 그런 다음 유형을 사용하여 생성된 볼륨에 사용할 백엔드를 지정할 수 있습니다. 볼륨 유형에 대한 자세한 내용은 2.3절. “볼륨 유형의 그룹 볼륨 구성” 을 참조하십시오.

볼륨을 생성할 때 백엔드를 지정하려면 유형 목록에서 해당 볼륨 유형을 선택합니다( 3.1절. “블록 스토리지 볼륨 생성”참조).

볼륨 생성 중에 백엔드를 지정하지 않으면 Block Storage 서비스에서 자동으로 해당 백엔드를 선택합니다. 기본적으로 서비스는 사용 가능한 여유 공간으로 백엔드를 선택합니다. 대신 사용 가능한 모든 백엔드 중에서 임의로 선택할 수 있도록 Block Storage 서비스를 구성할 수도 있습니다. 자세한 내용은 3.5절. “여러 백엔드에 볼륨 할당”의 내용을 참조하십시오.

2.11. 오버클라우드 노드에서 LVM2 필터링 활성화

특정 Block Storage 서비스(cinder) 백엔드와 함께 LVM2(Logical Volume Management) 볼륨을 사용하는 경우 RHOSP(Red Hat OpenStack Platform) 게스트 내에서 생성한 볼륨이 cinder-volume 또는 nova-compute 컨테이너를 호스팅하는 오버클라우드 노드에 표시될 수 있습니다. 이 경우 호스트의 LVM2 툴에서 OpenStack 게스트가 생성하는 LVM2 볼륨을 스캔하므로 Compute 또는 Controller 노드에서 다음과 같은 문제가 발생할 수 있습니다.

  • LVM에서 게스트의 볼륨 그룹 보기
  • LVM에서 중복 볼륨 그룹 이름 보고
  • LVM이 스토리지에 액세스 중이므로 볼륨 분리가 실패합니다.
  • LVM 문제 때문에 게스트를 부팅하지 못했습니다.
  • 게스트 시스템의 LVM은 실제로 존재하는 디스크가 누락되어 부분적인 상태입니다.
  • LVM이 있는 장치에서 Block Storage 서비스(cinder) 작업이 실패합니다.
  • Block Storage 서비스(cinder) 스냅샷이 올바르게 제거되지 못했습니다.
  • 실시간 마이그레이션 중 오류가 발생했습니다. /etc/multipath.conf 가 존재하지 않습니다.

이러한 잘못된 검사를 방지하고 호스트 노드에서 게스트 LVM2 볼륨을 분리하기 위해 오버클라우드를 배포하거나 업데이트할 때 LVMFilterEnabled heat 매개변수를 사용하여 필터를 활성화하고 구성할 수 있습니다. 이 필터는 활성 LVM2 볼륨을 호스팅하는 물리 장치 목록에서 계산됩니다. LVMFilterAllowlistLVMFilterDenylist 매개변수를 사용하여 블록 장치를 명시적으로 허용 및 거부할 수도 있습니다. 이 필터링을 전역적으로 특정 노드 역할 또는 특정 장치에 적용할 수 있습니다.

참고

이 기능은 이번 릴리스에서 기술 프리뷰로 제공되므로 Red Hat에서 완전히 지원되지 않습니다. 테스트 용도로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.

사전 요구 사항

절차

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. 언더클라우드 인증 정보 파일을 소싱합니다.

    $ source ~/stackrc
  3. 새 환경 파일을 생성하거나 기존 환경 파일을 수정합니다. 이 예에서는 새 파일 lvm2-filtering.yaml 을 생성합니다.

    $ touch ~/lvm2-filtering.yaml
  4. 환경 파일에 다음 매개변수를 포함합니다.

    parameter_defaults:
      LVMFilterEnabled: true

    LVM2 필터 구현을 추가로 사용자 지정할 수 있습니다. 예를 들어 컴퓨팅 노드에서만 필터링을 활성화하려면 다음 구성을 사용합니다.

    parameter_defaults:
      ComputeParameters:
        LVMFilterEnabled: true

    이러한 매개변수는 정규식도 지원합니다. 컴퓨팅 노드에서만 필터링을 활성화하고 /dev/sd 로 시작하는 모든 장치를 무시하려면 다음 구성을 사용합니다.

    parameter_defaults:
      ComputeParameters:
        LVMFilterEnabled: true
        LVMFilterDenylist:
          - /dev/sd.*
  5. openstack overcloud deploy 명령을 실행하고 LVM2 필터링 설정이 포함된 환경 파일과 오버클라우드 배포와 관련된 기타 환경 파일을 포함합니다.

    $ openstack overcloud deploy --templates \
    <environment-files> \
    -e lvm2-filtering.yaml

2.12. 다중 경로 구성

다중 경로를 사용하여 서버 노드와 스토리지 어레이 간의 여러 I/O 경로를 단일 장치로 구성하여 중복성을 생성하고 성능을 향상시킵니다. 새 오버클라우드 배포 및 기존 오버클라우드 배포에서 다중 경로를 구성할 수 있습니다.

그래픽은 cinder 다중 경로 I/O를 사용하여 구성된 Red Hat OpenStack Platform 배포의 논리 입력/출력 데이터 경로를 보여줍니다.

2.12.1. 새 배포에서 다중 경로 구성

새 오버클라우드 배포에서 다중 경로를 구성하려면 다음 절차를 완료합니다.

기존 오버클라우드 배포에서 다중 경로를 구성하는 방법에 대한 자세한 내용은 2.12.2절. “기존 배포에서 다중 경로 구성” 을 참조하십시오.

사전 요구 사항

절차

  1. 오버클라우드를 구성합니다.

    참고

    자세한 내용은 Director 설치 및 사용 가이드의 CLI 툴을 사용하여 기본 오버클라우드 구성을 참조하십시오.

  2. 다중 경로를 활성화하도록 heat 템플릿을 업데이트합니다.

    parameter_defaults:
      NovaLibvirtVolumeUseMultipath:  true
      NovaComputeOptVolumes:
        - /etc/multipath.conf:/etc/multipath.conf:ro
        - /etc/multipath/:/etc/multipath/:rw
      CinderVolumeOptVolumes:
        - /etc/multipath.conf:/etc/multipath.conf:ro
        - /etc/multipath/:/etc/multipath/:rw
  3. 선택 사항: Block Storage(cinder)를 Image 서비스(glance) 백엔드로 사용하는 경우 다음 단계도 완료해야 합니다.

    1. heat 템플릿에 다음 GlanceApiOptVolumes 구성을 추가합니다.

      parameter_defaults:
        GlanceApiOptVolumes:
          - /etc/multipath.conf:/etc/multipath.conf:ro
          - /etc/multipath/:/etc/multipath/:rw
    2. 다음과 같은 방법으로 ControllerExtraConfig 매개변수를 설정합니다.

      parameter_defaults:
        ControllerExtraConfig:
          glance::config::api_config:
            default_backend/cinder_use_multipath:
              value: true
      참고

      default_backendGlanceBackendID heat 템플릿 기본값이 모두 일치하는지 확인합니다.

  4. 구성된 모든 백엔드에 대해 use_multipath_for_image_xfertrue 로 설정합니다.

    parameter_defaults:
      ExtraConfig:
        cinder::config::cinder_config:
          <backend>/use_multipath_for_image_xfer:
            value: true
  5. 오버클라우드를 배포합니다.

    $ openstack overcloud deploy
    참고

    오버클라우드 매개 변수를 사용하여 오버클라우드 생성에 대한 자세한 내용은 Director 설치 및 사용 가이드 의 CLI 툴을 사용하여 오버클라우드 생성을 참조하십시오.

  6. 컨테이너가 실행되기 전에 모든 컨트롤러 및 컴퓨팅 노드에 다중 경로를 설치합니다.

    $ sudo dnf install -y device-mapper-multipath
    참고

    director는 첫 번째 부팅이 완료되고 코어 설정을 시작하기 전에 특정 노드 역할에 대한 사용자 정의 설정을 지원하기 위한 후크 세트를 제공합니다. 사용자 지정 오버클라우드 구성에 대한 자세한 내용은 Pre-Configuration을 참조하십시오. Advanced Overcloud Customization 가이드의 Specific Overcloud Roles

  7. 모든 컨트롤러 및 컴퓨팅 노드에서 다중 경로 데몬을 구성합니다.

    $ mpathconf --enable --with_multipathd y --user_friendly_names n --find_multipaths y
    참고

    예제 코드는 대부분의 환경에서 작동하는 기본 다중 경로 구성을 생성합니다. 그러나 일부 공급 업체가 하드웨어와 관련된 최적화된 구성을 보유하고 있기 때문에 스토리지 공급 업체에서 권장 사항을 확인하십시오. 멀티패스에 대한 자세한 내용은 장치 매퍼 다중 경로 구성 가이드를 참조하십시오.

  8. 파티션 생성을 방지하기 위해 모든 컨트롤러 및 컴퓨팅 노드에서 다음 명령을 실행합니다.

    $ sed -i "s/^defaults {/defaults {\n\tskip_kpartx yes/" /etc/multipath.conf
    참고

    skip_kpartxyes 로 설정하면 Compute 노드의 kpartx가 장치에 파티션을 자동으로 생성하지 않아 불필요한 장치 매퍼 항목이 방지됩니다. 구성 속성에 대한 자세한 내용은 장치 매퍼 다중 경로 구성 가이드의 DM-Multipath 구성 파일 수정을 참조하십시오.

  9. 모든 컨트롤러 및 컴퓨팅 노드에서 다중 경로 데몬을 시작합니다.

    $ systemctl enable --now multipathd

2.12.2. 기존 배포에서 다중 경로 구성

워크로드가 다중 경로 기능을 사용할 수 있도록 기존 배포에서 다중 경로를 구성합니다.

참고

기존 배포에서 다중 경로를 구성한 후 생성하는 새 워크로드는 기본적으로 다중 경로 인식입니다. 기존 워크로드가 있는 경우 인스턴스를 보류하고 보류 해제하여 이러한 인스턴스에서 다중 경로를 활성화해야 합니다.

새 오버클라우드 배포에서 다중 경로를 구성하는 방법에 대한 자세한 내용은 2.12.1절. “새 배포에서 다중 경로 구성” 을 참조하십시오.

사전 요구 사항

절차

  1. 다중 경로가 모든 컨트롤러 및 컴퓨팅 노드에 설치되어 있는지 확인합니다.

    $ rpm -qa | grep device-mapper-multipath
    
    device-mapper-multipath-0.4.9-127.el8.x86_64
    device-mapper-multipath-libs-0.4.9-127.el8.x86_64

    다중 경로가 설치되지 않은 경우 모든 컨트롤러 및 컴퓨팅 노드에 설치합니다.

    $ sudo dnf install -y device-mapper-multipath
  2. 모든 컨트롤러 및 컴퓨팅 노드에서 다중 경로 데몬을 구성합니다.

    $ mpathconf --enable --with_multipathd y --user_friendly_names n --find_multipaths y
    참고

    예제 코드는 대부분의 환경에서 작동하는 기본 다중 경로 구성을 생성합니다. 그러나 일부 공급 업체가 하드웨어와 관련된 최적화된 구성을 보유하고 있기 때문에 스토리지 공급 업체에서 권장 사항을 확인하십시오. 멀티패스에 대한 자세한 내용은 장치 매퍼 다중 경로 구성 가이드를 참조하십시오.

  3. 파티션 생성을 방지하기 위해 모든 컨트롤러 및 컴퓨팅 노드에서 다음 명령을 실행합니다.

    $ sed -i "s/^defaults {/defaults {\n\tskip_kpartx yes/" /etc/multipath.conf
    참고

    skip_kpartxyes 로 설정하면 Compute 노드의 kpartx가 장치에 파티션을 자동으로 생성하지 않아 불필요한 장치 매퍼 항목이 방지됩니다. 구성 속성에 대한 자세한 내용은 장치 매퍼 다중 경로 구성 가이드를 참조하십시오.

  4. 모든 컨트롤러 및 컴퓨팅 노드에서 다중 경로 데몬을 시작합니다.

    $ systemctl enable --now multipathd
  5. 다중 경로를 활성화하도록 heat 템플릿을 업데이트합니다.

    parameter_defaults:
      NovaLibvirtVolumeUseMultipath:  true
      NovaComputeOptVolumes:
        - /etc/multipath.conf:/etc/multipath.conf:ro
        - /etc/multipath/:/etc/multipath/:rw
      CinderVolumeOptVolumes:
        - /etc/multipath.conf:/etc/multipath.conf:ro
        - /etc/multipath/:/etc/multipath/:rw
  6. 선택 사항: Block Storage(cinder)를 Image 서비스(glance) 백엔드로 사용하는 경우 다음 단계도 완료해야 합니다.

    1. heat 템플릿에 다음 GlanceApiOptVolumes 구성을 추가합니다.

      parameter_defaults:
        GlanceApiOptVolumes:
          - /etc/multipath.conf:/etc/multipath.conf:ro
          - /etc/multipath/:/etc/multipath/:rw
    2. 다음과 같은 방법으로 ControllerExtraConfig 매개변수를 설정합니다.

      parameter_defaults:
        ControllerExtraConfig:
          glance::config::api_config:
            default_backend/cinder_use_multipath:
              value: true
      참고

      default_backendGlanceBackendID heat 템플릿 기본값이 모두 일치하는지 확인합니다.

  7. 구성된 모든 백엔드에 대해 use_multipath_for_image_xfertrue 로 설정합니다.

    parameter_defaults:
      ExtraConfig:
        cinder::config::cinder_config:
          <backend>/use_multipath_for_image_xfer:
            value: true
  8. 다음 명령을 실행하여 오버클라우드를 업데이트합니다.

    $ openstack overcloud deploy
    참고

    openstack overcloud deploy 명령을 실행하여 다중 경로를 설치하고 구성하는 경우 모든 환경 파일에 대해 --templates,--roles-file,-e 와 같은 오버클라우드를 배포하는 데 사용한 이전 역할 및 환경 파일을 모두 전달해야 합니다. 이전의 모든 역할 및 환경 파일을 전달하지 않으면 오버클라우드 배포에 문제가 발생할 수 있습니다. 오버클라우드 매개 변수 사용에 대한 자세한 내용은 Director 설치 및 사용 가이드 의 CLI 툴을 사용하여 오버클라우드 생성을 참조하십시오.

  9. 선택 사항: 다중 경로 기능을 사용하려는 배포에 기존 워크로드가 있는 경우 해당 인스턴스를 보류하고 해제해야 합니다.

    $ nova shelve <instance>
    $ nova unshelve <instance>
    • <instance> 를 보류 및 해제하려는 인스턴스의 ID로 바꿉니다.

      참고

      인스턴스를 다시 시작하면 다중 경로가 활성화되지 않습니다. 인스턴스를 보류하고 보류 해제해야 합니다.

2.12.3. 다중 경로 구성 확인

다음 절차에서는 새 또는 기존 오버클라우드 배포에서 다중 경로 구성을 확인하는 방법을 설명합니다.

사전 요구 사항

절차

  1. VM 생성.
  2. 암호화되지 않은 볼륨을 VM에 연결합니다.
  3. 인스턴스가 포함된 컴퓨팅 노드의 이름을 가져옵니다.

    $ nova show INSTANCE | grep OS-EXT-SRV-ATTR:host

    INSTANCE 를 부팅한 VM의 이름으로 교체합니다.

  4. 인스턴스의 virsh 이름을 검색합니다.

    $ nova show INSTANCE | grep instance_name

    INSTANCE 를 부팅한 VM의 이름으로 교체합니다.

  5. 컴퓨팅 노드의 IP 주소를 가져옵니다.

    $ . stackrc
    $ nova list | grep compute_name

    compute_namenova show INSTANCE 명령의 출력에서 name으로 바꿉니다.

  6. VM을 실행하는 컴퓨팅 노드에 SSH를 실행합니다.

    $ ssh heat-admin@COMPUTE_NODE_IP

    COMPUTE_NODE_IP 를 컴퓨팅 노드의 IP 주소로 바꿉니다.

  7. virsh를 실행하는 컨테이너에 로그인합니다.

    $ podman exec -it nova_libvirt /bin/bash
  8. 컴퓨팅 노드 인스턴스에 다음 명령을 입력하여 cinder 볼륨 호스트 위치에서 다중 경로를 사용하고 있는지 확인합니다.

    virsh domblklist VIRSH_INSTANCE_NAME | grep /dev/dm

    VIRSH_INSTANCE_NAMEnova show INSTANCE | grep instance_name 명령의 출력으로 바꿉니다.

    인스턴스에 /dev/dm- 이외의 값이 표시되면 연결은 비-multipath이며 nova he lve 및 nova unshelve 명령을 사용하여 연결 정보를 새로 고쳐야 합니다.

    $ nova shelve <instance>
    $ nova unshelve <instance>
    참고

    백엔드 유형이 두 개 이상인 경우 각 백엔드에서 반환하는 연결 정보가 다를 수 있으므로 모든 백엔드의 인스턴스 및 볼륨을 확인해야 합니다.

3장. Block Storage 서비스(cinder)를 사용하여 기본 작업 수행

Block Storage 볼륨을 오버클라우드의 Compute 인스턴스에 사용할 영구 스토리지의 기본 형식으로 생성하고 구성합니다. 볼륨을 생성하고, 볼륨을 인스턴스에 연결하고, 볼륨을 편집하고 크기를 조정하며, 볼륨 소유권을 수정합니다.

3.1. 블록 스토리지 볼륨 생성

오버클라우드에서 Compute 서비스(nova)로 시작하는 인스턴스의 영구 스토리지를 제공하는 볼륨을 생성합니다.

중요

프로젝트에 생성할 수 있는 기본 최대 볼륨 수는 10입니다.

사전 요구 사항

절차

  1. 대시보드에서 Project > Compute > Volumes 를 선택합니다.
  2. Create Volume 를 클릭하고 다음 필드를 편집합니다.

    필드설명

    볼륨 이름

    볼륨 이름입니다.

    설명

    선택 사항, 볼륨에 대한 간단한 설명입니다.

    유형

    선택적 볼륨 유형( 2.3절. “볼륨 유형의 그룹 볼륨 구성”참조하십시오.

    블록 스토리지 백엔드가 여러 개 있는 경우 이를 사용하여 특정 백엔드를 선택할 수 있습니다. 2.10절. “볼륨 생성을 위한 백엔드 지정”을 참조하십시오.

    크기(GB)

    볼륨 크기(GB). 암호화되지 않은 이미지에서 암호화된 볼륨을 생성하려면 암호화 데이터가 볼륨 데이터를 잘리지 않도록 볼륨 크기가 이미지 크기보다 큰지 확인해야 합니다.

    가용성 영역

    호스트 집계와 함께 가용성 영역(논리 서버 그룹)은 OpenStack 내에서 리소스를 분리하는 일반적인 방법입니다. 가용성 영역은 설치 중에 정의됩니다. 가용성 영역 및 호스트 집계에 대한 자세한 내용은 Configuring the Compute Service for Instance Creation 가이드의 호스트 집계 생성 및 관리를 참조하십시오.

  3. 볼륨 소스를 지정합니다.

    소스설명

    소스 없음, 빈 볼륨

    볼륨이 비어 있으며 파일 시스템 또는 파티션 테이블이 포함되지 않습니다.

    snapshot

    기존 스냅샷을 볼륨 소스로 사용합니다. 이 옵션을 선택하면 새 스냅샷 사용 목록이 열립니다. 목록에서 스냅샷을 선택할 수 있습니다. 암호화된 볼륨의 스냅샷에서 새 볼륨을 생성하려면 새 볼륨이 이전 볼륨보다 1GB 이상 커야 합니다. 볼륨 스냅샷에 대한 자세한 내용은 4.1절. “볼륨 스냅샷 생성, 사용 및 삭제” 을 참조하십시오.

    Image

    기존 이미지를 볼륨 소스로 사용합니다. 이 옵션을 선택하면 새 사용 스냅샷이 소스 목록으로 열립니다. 목록에서 이미지를 선택할 수 있습니다.

    볼륨

    기존 볼륨을 볼륨 소스로 사용합니다. 이 옵션을 선택하면 새 스냅샷 사용 목록이 열립니다. 목록에서 볼륨을 선택할 수 있습니다.

  4. Create Volume (볼륨 만들기)을 클릭합니다. 볼륨이 생성되면 Volumes 테이블에 이름이 표시됩니다.

나중에 볼륨 유형을 변경할 수도 있습니다. 자세한 내용은 4.5절. “블록 스토리지 볼륨 retyping”의 내용을 참조하십시오.

3.2. 볼륨 이름 또는 설명 편집

대시보드(horizon)에서 볼륨 이름 및 설명을 편집합니다.

사전 요구 사항

절차

  1. 대시보드에서 Project > Compute > Volumes 를 선택합니다.
  2. 볼륨의 Edit Volume (볼륨 편집) 버튼을 선택합니다.
  3. 필요에 따라 볼륨 이름 또는 설명을 편집합니다.
  4. Edit Volume 을 클릭하여 변경 사항을 저장합니다.
참고

암호화된 볼륨을 생성하려면 먼저 볼륨 암호화를 위해 특별히 볼륨 유형을 구성해야 합니다. 또한 동일한 정적 키를 사용하도록 Compute 및 Block Storage 서비스를 모두 구성해야 합니다. 볼륨 암호화 요구 사항을 설정하는 방법에 대한 자세한 내용은 2.7절. “Block Storage 서비스(cinder) 볼륨 암호화” 을 참조하십시오.

3.3. Block Storage 서비스 볼륨 크기 조정(extending)

볼륨의 스토리지 용량을 늘리기 위해 볼륨의 크기를 조정합니다.

참고

사용 중인 볼륨 크기를 조정하는 기능이 지원되지만 드라이버에 따라 다릅니다. RBD가 지원됩니다. 사용 중인 다중 연결 볼륨을 확장할 수 없습니다. 이 기능 지원에 대한 자세한 내용은 Red Hat 지원팀에 문의하십시오.

사전 요구 사항

절차

  1. 볼륨을 나열하여 확장할 볼륨의 ID를 검색합니다.

    $ cinder list
  2. 볼륨의 크기를 조정하려면 다음 명령을 실행하여 올바른 API 마이크로버전을 지정한 다음 볼륨 ID와 새 크기(이전 1보다 큰 값)를 매개변수로 전달합니다.

    $ OS_VOLUME_API_VERSION=<API microversion>
    $ cinder extend <volume ID> <size>

    <API 마이크로버전>, <volume ID>, <size>를 적절한 값으로 바꿉니다. 다음 예제를 가이드로 사용합니다.

    $ OS_VOLUME_API_VERSION=3.42
    $ cinder extend 573e024d-5235-49ce-8332-be1576d323f8 10

3.4. 블록 스토리지 서비스 볼륨 삭제

대시보드를 사용하여 더 이상 필요하지 않은 볼륨을 삭제합니다.

참고

기존 스냅샷이 있는 경우 볼륨을 삭제할 수 없습니다. 스냅샷을 삭제하는 방법에 대한 자세한 내용은 4.1절. “볼륨 스냅샷 생성, 사용 및 삭제” 을 참조하십시오.

사전 요구 사항

절차

  1. 대시보드에서 Project > Compute > Volumes 를 선택합니다.
  2. Volumes (볼륨) 표에서 삭제할 볼륨을 선택합니다.
  3. Delete Volumes (볼륨 삭제)를 클릭합니다.

3.5. 여러 백엔드에 볼륨 할당

블록 스토리지 서비스가 여러 백엔드를 사용하도록 구성된 경우 구성된 볼륨 유형을 사용하여 볼륨을 생성해야 하는 위치를 지정할 수 있습니다. 자세한 내용은 2.10절. “볼륨 생성을 위한 백엔드 지정”의 내용을 참조하십시오.

볼륨 생성 중에 지정하지 않으면 블록 스토리지 서비스에서 백엔드를 자동으로 선택합니다. Block Storage는 첫 번째 정의 백엔드를 기본값으로 설정합니다. 이 백엔드는 공간이 부족해질 때까지 사용됩니다. 이 시점에서 Block Storage는 두 번째 정의 백엔드를 기본값으로 설정합니다.

필요에 적합하지 않은 경우 필터 스케줄러를 사용하여 블록 스토리지에서 백엔드를 선택하는 방법을 제어할 수 있습니다. 이 스케줄러는 다음과 같이 다양한 필터를 사용하여 적합한 백엔드를 분류할 수 있습니다.

AvailabilityZoneFilter
요청된 볼륨의 가용성 영역 요구 사항을 충족하지 않는 모든 백엔드를 필터링합니다.
CapacityFilter
볼륨을 수용하기에 충분한 공간이 있는 백엔드만 선택합니다.
CapabilitiesFilter
볼륨에서 지정된 설정을 모두 지원할 수 있는 백엔드만 선택합니다.
InstanceLocality
동일한 노드에 로컬로 볼륨을 사용하도록 클러스터를 구성합니다.

사전 요구 사항

절차

  1. 다음 매개변수가 포함된 배포 명령에 환경 파일을 추가합니다.

    parameter_defaults:
      ControllerExtraConfig: # 1
        cinder::config::cinder_config:
          DEFAULT/scheduler_default_filters:
            value: 'AvailabilityZoneFilter,CapacityFilter,CapabilitiesFilter,InstanceLocality'
1
ControllerExtraConfig: 후크 및 해당 중첩 섹션을 기존 환경 파일의 parameter_defaults: 섹션에 추가할 수도 있습니다.

3.6. 인스턴스에 볼륨 연결

인스턴스는 영구 스토리지에 볼륨을 사용할 수 있습니다. 볼륨은 한 번에 하나의 인스턴스에만 연결할 수 있습니다. 인스턴스에 대한 자세한 내용은 이미지 생성 및 관리 가이드의 이미지 서비스를 참조하십시오.

사전 요구 사항

절차

  1. 대시보드에서 Project > Compute > Volumes 를 선택합니다.
  2. Edit attachment 작업을 선택합니다. 볼륨이 인스턴스에 연결되어 있지 않으면 Attach to Instance 드롭다운 목록이 표시됩니다.
  3. Attach to Instance(인스턴스에 연결) 목록에서 볼륨을 연결할 인스턴스를 선택합니다.
  4. Attach Volume 을 클릭합니다.

3.7. 인스턴스에서 볼륨 분리

인스턴스는 영구 스토리지에 볼륨을 사용할 수 있습니다. 볼륨은 한 번에 하나의 인스턴스에만 연결할 수 있습니다. 인스턴스에 대한 자세한 내용은 이미지 생성 및 관리 가이드의 이미지 서비스를 참조하십시오.

사전 요구 사항

절차

  1. 대시보드에서 Project > Compute > Volumes 를 선택합니다.
  2. 볼륨의 Manageattach 작업을 선택합니다. 볼륨이 인스턴스에 연결된 경우 인스턴스 이름이 6443 테이블에 표시됩니다.
  3. 대화 상자에서 vGPU Volume 을 클릭하고 다음 대화 상자를 클릭합니다.

3.8. 읽기 전용 볼륨 구성

볼륨은 실수로 데이터를 덮어쓰거나 삭제하지 않도록 읽기 전용으로 표시할 수 있습니다.

사전 요구 사항

절차

  • 볼륨을 읽기 전용으로 설정합니다.
# cinder readonly-mode-update <VOLUME-ID> true
  • 읽기 전용 볼륨을 다시 읽기-쓰기로 설정합니다.
# cinder readonly-mode-update <VOLUME-ID> false

3.9. CLI로 볼륨 소유자 변경

볼륨의 소유자를 변경하려면 볼륨 전송을 수행해야 합니다. 볼륨 전송은 볼륨의 소유자에 의해 시작되며 볼륨의 새 소유자가 양도한 후 볼륨의 소유권 변경이 완료됩니다.

사전 요구 사항

절차

  1. 볼륨의 현재 소유자로 로그인합니다.
  2. 사용 가능한 볼륨을 나열합니다.

    # cinder list
  3. 볼륨 전송을 시작합니다.

    # cinder transfer-create VOLUME

    여기서 VOLUME 은 전송하려는 볼륨의 이름 또는 ID 입니다. 예를 들면 다음과 같습니다.

      +------------+--------------------------------------+
      |  Property  |                Value                 |
      +------------+--------------------------------------+
      |  auth_key  |           f03bf51ce7ead189           |
      | created_at |      2014-12-08T03:46:31.884066      |
      |     id     | 3f5dc551-c675-4205-a13a-d30f88527490 |
      |    name    |                 None                 |
      | volume_id  | bcf7d015-4843-464c-880d-7376851ca728 |
      +------------+--------------------------------------+

    cinder transfer-create 명령은 볼륨의 소유권을 지우고 전송을 위한 idauth_key 를 생성합니다. 이러한 값을 에 제공하고, 에서 다른 사용자가 전송을 수락하고 볼륨의 새 소유자가 되도록 사용할 수 있습니다.

  4. 이제 새 사용자가 볼륨의 소유권을 요청할 수 있습니다. 이렇게 하려면 먼저 명령줄에서 로그인한 후 다음을 실행해야 합니다.

    # cinder transfer-accept TRANSFERID TRANSFERKEY

    여기서 TRANSFERIDTRANSFERKEYcinder transfer-create 명령에서 반환하는 idauth_key 값입니다. 예를 들면 다음과 같습니다.

    # cinder transfer-accept 3f5dc551-c675-4205-a13a-d30f88527490 f03bf51ce7ead189
참고

다음을 사용하여 사용 가능한 모든 볼륨 전송을 볼 수 있습니다.

# cinder transfer-list

3.10. 대시보드를 사용하여 볼륨 소유자 변경

볼륨의 소유자를 변경하려면 볼륨 전송을 수행해야 합니다. 볼륨 전송은 볼륨의 소유자에 의해 시작되며 볼륨의 새 소유자가 양도한 후 볼륨의 소유권 변경이 완료됩니다.

사전 요구 사항

절차

  1. 대시보드의 볼륨 소유자로 프로젝트 > 볼륨을 선택합니다.
  2. 전송할 볼륨의 Actions (작업) 열에서 전송 생성 을 선택합니다.
  3. 전송 생성 대화 상자에서 전송 의 이름을 입력하고 Create Volume Transfer 를 클릭합니다.

    볼륨 전송이 생성되고 Volume Transfer (볼륨 전송) 화면에서 전송 ID권한 키를 캡처하여 수신자 프로젝트로 보낼 수 있습니다.

    전송 이름, 전송ID , 권한 부여 키가 포함된 .txt 파일을 다운로드하려면 전송 자격 증명 다운로드 버튼을 클릭합니다.

    참고

    권한 부여 키는 Volume Transfer 화면에서만 사용할 수 있습니다. 권한 부여 키가 손실된 경우 전송을 취소하고 다른 전송을 생성하여 새 권한 키를 생성해야 합니다.

  4. Volume Transfer (볼륨 전송) 화면을 닫고 볼륨 목록으로 돌아갑니다.

    수신자 프로젝트에서 전송을 수락할 때까지 볼륨 상태가 awaiting-transfer 로 변경됩니다.

대시보드에서 볼륨 전송 수락

  1. 대시보드의 수신자 프로젝트 소유자로 프로젝트 > 볼륨을 선택합니다.
  2. Accept Transfer 를 클릭합니다.
  3. Accept Volume Transfer (볼륨 전송 수락) 대화 상자에서 전송 ID 와 볼륨 소유자에서 수신한 권한 부여 키를 입력하고 Accept Volume Transfer (볼륨 전송 수락)를 클릭합니다.

    이제 볼륨이 활성 프로젝트의 볼륨 목록에 표시됩니다.

4장. Block Storage 서비스(cinder)를 사용하여 고급 작업 수행

블록 스토리지 볼륨은 오버클라우드에서 Compute 인스턴스에 대한 영구 스토리지를 형성합니다. 볼륨의 고급 기능(예: 볼륨 스냅샷 사용, 볼륨 마이그레이션, 볼륨 리타이핑, 다중 경로 구성 등)을 구성합니다.

4.1. 볼륨 스냅샷 생성, 사용 및 삭제

볼륨 스냅샷을 생성하여 특정 시점의 볼륨 상태를 보존할 수 있습니다. 그런 다음 스냅샷을 사용하여 새 볼륨을 복제할 수 있습니다.

참고

볼륨 백업은 스냅샷과 다릅니다. 백업은 볼륨에 포함된 데이터가 보존되는 반면 스냅샷은 특정 시점의 볼륨 상태를 유지합니다. 기존 스냅샷이 있는 경우 볼륨을 삭제할 수 없습니다. 볼륨 백업에서는 데이터 손실을 방지하지만 스냅샷은 복제를 용이하게 합니다.

이러한 이유로 스냅샷 백엔드는 일반적으로 복제 중 대기 시간을 최소화하기 위해 볼륨 백엔드와 함께 배치됩니다. 백업 리포지토리는 일반적으로 다른 위치(예: 다른 노드, 물리적 스토리지 또는 일반적인 엔터프라이즈 배포의 지리적 위치)에 위치합니다. 이는 볼륨 백엔드에 발생할 수 있는 손상으로부터 백업 리포지토리를 보호하기 위한 것입니다.

볼륨 백업에 대한 자세한 내용은 블록 스토리지 백업 가이드 를 참조하십시오.

사전 요구 사항

절차

  1. 대시보드에서 Project > Compute > Volumes 를 선택합니다.
  2. 대상 볼륨의 Create Snapshot 작업을 선택합니다.
  3. 스냅샷 의 스냅샷 이름을 입력하고 Create a Volume Snapshot 을 클릭합니다. Volume Snapshots (볼륨 스냅샷) 탭에는 모든 스냅샷이 표시됩니다.

Volume Snapshots (볼륨 스냅샷) 테이블에 표시될 때 스냅샷에서 새 볼륨을 복제할 수 있습니다. 이를 위해 스냅샷의 Create Volume (볼륨 만들기) 작업을 선택합니다. 볼륨 생성에 대한 자세한 내용은 3.1절. “블록 스토리지 볼륨 생성” 을 참조하십시오.

중요

암호화된 볼륨의 스냅샷에서 새 볼륨을 생성하려면 새 볼륨이 이전 볼륨보다 1GB 이상인지 확인하십시오.

스냅샷을 삭제하려면 Delete Volume Snapshot (볼륨 스냅샷 삭제) 작업을 선택합니다.

OpenStack 배포에서 Red Hat Ceph 백엔드를 사용하는 경우 스냅샷 보안 및 문제 해결에 대한 자세한 내용은 4.10절. “Red Hat Ceph Storage 백엔드에서 보호 및 보호되지 않은 스냅샷” 를 참조하십시오.

참고

스냅샷에서 생성된 Block Storage 서비스(cinder)의 RADOS 블록 장치(RBD) 볼륨의 경우 CinderRbdFlattenVolumeFromSnapshot heat 매개변수를 사용하여 병합하고 스냅샷에 대한 종속성을 제거할 수 있습니다. CinderRbdFlattenVolumeFromSnapshottrue 로 설정하면 Block Storage 서비스가 RBD 볼륨을 병합하고 스냅샷에 대한 종속성을 제거하고 향후 모든 스냅샷을 병합합니다. 기본값은 false이며 cinder RBD 드라이버의 기본값이기도 합니다.

스냅샷을 병합하면 상위와의 잠재적인 블록 공유가 제거되고 백엔드에서 스냅샷 크기가 클수록 스냅샷 생성 시간이 늘어납니다.

4.2. 스냅샷에서 볼륨 복원

볼륨의 최신 스냅샷을 복구할 수 있습니다. 즉, 볼륨 데이터를 최신 스냅샷으로 인플레이스할 수 있습니다.

주의

볼륨의 최신 스냅샷을 복구하는 기능은 지원되지만 드라이버에 따라 다릅니다. 이 기능의 올바른 구현은 드라이버를 지원합니다. 이 기능 지원에 대한 자세한 내용은 드라이버 벤더에 문의하십시오.

제한 사항

  • 다중 연결 볼륨에서 revert-to-snapshot 기능을 사용하는 데 제한 사항이 있을 수 있습니다. 이 기능을 사용하기 전에 이러한 제한 사항이 적용되는지 확인하십시오.
  • 스냅샷을 만든 후에는 크기 조정(extend)하는 볼륨을 되돌릴 수 없습니다.
  • 연결 또는 사용 중인 볼륨에서 revert-to-snapshot 기능을 사용할 수 없습니다.

사전 요구 사항

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. overcloudrc 파일을 소싱합니다.

    [stack@undercloud ~] $ source overcloudrc
  3. 볼륨을 분리합니다.

    $ nova volume-detach <instance_id> <vol_id>

    <instance_id> 및 <vol_id>를 인스턴스의 ID와 되돌리려는 볼륨의 ID로 바꿉니다.

  4. 되돌릴 스냅샷의 ID 또는 이름을 찾습니다. 최신 스냅샷만 되돌릴 수 있습니다.

    $ cinder snapshot-list
  5. 스냅샷을 되돌립니다.

    $ cinder --os-volume-api-version=3.40 revert-to-snapshot  <snapshot_id or snapshot_name>

    <snapshot_id 또는 snapshot_name>을 ID 또는 스냅샷 이름으로 바꿉니다.

  6. 선택 사항: cinder snapshot-list 명령을 사용하여 되돌리는 볼륨이 되돌리는 상태에 있는지 확인할 수 있습니다.

    $  cinder snapshot-list
  7. 볼륨을 다시 연결합니다.

    $  nova volume-attach <instance_id> <vol_id>

    <instance_id> 및 <vol_id>를 인스턴스의 ID와 되돌리는 볼륨의 ID로 바꿉니다.

검증

  • 절차가 성공했는지 확인하려면 cinder list 명령을 사용하여 되돌리는 볼륨이 이제 available 상태인지 확인할 수 있습니다.

    $ cinder list
참고

Block Storage(cinder)를 부팅 가능한 루트 볼륨으로 사용한 경우 사용 가능한 상태가 아니므로 해당 볼륨에서 revert-to-snapshot 기능을 사용할 수 없습니다. 이 기능을 사용하려면 인스턴스가 종료된 경우 부팅 볼륨을 유지하려면 delete_on_termination=false (기본값) 속성을 사용하여 인스턴스가 부팅되어야 합니다. 스냅샷으로 되돌리려면 먼저 볼륨을 사용할 수 있도록 초기 인스턴스를 삭제해야 합니다. 그런 다음 이 파일을 취소하고 볼륨에서 새 인스턴스를 만들 수 있습니다.

4.3. Image 서비스(glance)에 볼륨 업로드

기존 볼륨을 이미지 서비스에 직접 업로드할 수 있습니다.

사전 요구 사항

절차

  1. 대시보드에서 Project > Compute > Volumes 를 선택합니다.
  2. 대상 볼륨의 Upload to Image 작업을 선택합니다.
  3. 볼륨의 이미지 이름을 입력하고 목록에서 Disk Format 을 선택합니다.
  4. 업로드를 클릭합니다.

업로드된 이미지를 보려면 Project > Compute > Images 를 선택합니다. 새 이미지가 Images (이미지) 테이블에 표시됩니다. 이미지 사용 및 구성 방법에 대한 자세한 내용은 이미지 생성 및 관리 가이드의 이미지 서비스를 참조하십시오.

4.4. 백엔드 간 볼륨 이동

다음과 같은 스토리지 백엔드에서 다른 스토리지 백엔드로 볼륨을 이동해야 하는 이유는 여러 가지가 있습니다.

  • 더 이상 지원되지 않는 스토리지 시스템을 폐기합니다.
  • 볼륨의 스토리지 클래스 또는 계층을 변경하려면 다음을 수행합니다.
  • 볼륨의 가용성 영역을 변경하려면 다음을 수행합니다.

Block Storage 서비스(cinder)를 사용하면 다음과 같은 방법으로 백엔드 간에 볼륨을 이동할 수 있습니다.

  • 다시 유형: 기본 정책을 사용하면 볼륨 소유자와 관리자가 볼륨을 다시 입력할 수 있습니다. 재유형 작업은 백엔드 간에 볼륨을 이동하는 가장 일반적인 방법입니다.
  • migrate: 기본 정책을 사용하면 관리자만 볼륨을 마이그레이션할 수 있습니다. 볼륨 마이그레이션은 제한적이며 배포 작동 방식에 대한 명확한 이해가 필요하기 때문에 특정 사용 사례에 대해 예약되어 있습니다. 자세한 내용은 4.8절. “CLI를 사용하여 백엔드 간 볼륨 마이그레이션”의 내용을 참조하십시오.

제한 사항

Red Hat은 AZ(가용성 영역) 내외에서 백엔드 간 볼륨 이동을 지원하지만 다음과 같은 제한 사항이 있습니다.

  • 이동할 수 있는 볼륨 또는 사용 중 상태가 있어야 합니다.
  • 사용 중인 볼륨에 대한 지원은 드라이버에 따라 다릅니다.
  • 볼륨에 스냅샷을 가질 수 없습니다.
  • 볼륨은 그룹 또는 일관성 그룹에 속할 수 없습니다.

4.4.1. 사용 가능한 볼륨 이동

모든 백엔드 간에 사용 가능한 볼륨을 이동할 수 있지만 성능은 사용하는 백엔드에 따라 달라집니다. 많은 백엔드가 마이그레이션을 지원합니다. 지원 마이그레이션을 위한 백엔드 지원에 대한 자세한 내용은 공급 업체에 문의하십시오.

지원이 지정된 마이그레이션은 볼륨 재유형 및 볼륨 마이그레이션 모두에서 작동합니다. 마이그레이션을 통해 백엔드는 소스 백엔드에서 대상 백엔드로 데이터 이동을 최적화하지만 두 백엔드는 동일한 벤더에서 가져와야 합니다.

참고

Red Hat은 다중 풀 백엔드를 사용하거나 RBD와 같은 단일 풀 백엔드에 대해 cinder 마이그레이션 작업을 사용하는 경우에만 백엔드 지원 마이그레이션을 지원합니다.

백엔드 간 보조 마이그레이션을 수행할 수 없는 경우 블록 스토리지 서비스는 일반 볼륨 마이그레이션을 수행합니다.

일반 볼륨 마이그레이션을 수행하려면 Block Storage(cinder) 서비스에서 데이터를 컨트롤러 노드로 이동하고 컨트롤러 노드에서 대상 볼륨으로 데이터를 이동하기 전에 두 백엔드의 볼륨을 모두 연결할 수 있어야 합니다. 블록 스토리지 서비스는 소스 및 대상 백엔드의 스토리지 유형에 관계없이 프로세스를 원활하게 수행합니다.

중요

일반 볼륨 마이그레이션을 수행하기 전에 적절한 대역폭이 있는지 확인합니다. 일반 볼륨 마이그레이션의 기간은 볼륨 크기에 직접적으로 비례하므로 마이그레이션을 지원하는 것보다 속도가 느려집니다.

4.4.2. 사용 중인 볼륨 이동

사용 중인 볼륨을 이동하기 위한 최적화된 또는 지원 옵션이 없습니다. 사용 중인 볼륨을 이동할 때 Compute 서비스(nova)는 하이퍼바이저를 사용하여 소스 백엔드의 볼륨에서 대상 백엔드의 볼륨으로 데이터를 전송해야 합니다. 이를 위해서는 볼륨이 사용 중인 인스턴스를 실행하는 하이퍼바이저와의 조정이 필요합니다.

Block Storage 서비스(cinder) 및 Compute 서비스가 함께 작동하여 이 작업을 수행합니다. 계산 서비스는 데이터가 컴퓨팅 노드를 통해 한 볼륨에서 다른 볼륨으로 복사되므로 대부분의 작업을 관리합니다.

중요

사용 중인 볼륨을 이동하기 전에 적절한 대역폭이 있는지 확인합니다. 이 작업의 기간은 볼륨 크기에 직접적으로 비례하므로 마이그레이션을 지원하는 것보다 성능이 느려집니다.

제한 사항

  • 사용 중인 다중 연결 볼륨은 두 개 이상의 nova 인스턴스에 연결된 동안에는 이동할 수 없습니다.
  • 블록 장치가 지원되지 않으므로 대상 백엔드의 스토리지 프로토콜을 iSCSI, Fibre Channel(FC) 및 RBD로 제한합니다.

4.5. 블록 스토리지 볼륨 retyping

볼륨 복제는 한 백엔드에서 다른 백엔드로 볼륨을 이동하는 표준 방법입니다. 작업을 수행하려면 관리자가 다른 백엔드에 적절한 볼륨 유형을 정의해야 합니다. 기본 정책을 사용하면 볼륨 소유자와 관리자가 볼륨을 다시 입력할 수 있습니다.

볼륨을 다시 입력할 때 볼륨 유형 및 해당 설정을 이미 존재하는 볼륨에 적용합니다. 볼륨 유형에 대한 자세한 내용은 2.3절. “볼륨 유형의 그룹 볼륨 구성” 을 참조하십시오.

새 볼륨 유형의 추가 사양을 기존 볼륨에 적용할 수 있는 제공된 볼륨을 다시 입력할 수 있습니다. 볼륨을 다시 입력하여 사전 정의된 설정 또는 스토리지 속성을 기존 볼륨에 적용할 수 있습니다(예:

  • 볼륨을 다른 백엔드로 이동하려면 다음을 수행합니다.
  • 볼륨의 스토리지 클래스 또는 계층을 변경하려면 다음을 수행합니다.
  • 복제와 같은 기능을 활성화하거나 비활성화하려면 다음을 수행합니다.

볼륨을 다시 제거해도 한 백엔드에서 다른 백엔드로 볼륨을 이동해야 하는 것은 아닙니다. 그러나 재타입을 완료하려면 볼륨을 이동해야하는 상황이 있습니다.

  • 새 볼륨 유형에 다른 volume_backend_name 이 정의되어 있습니다.
  • 현재 볼륨 유형의 volume_backend_name 은 정의되지 않으며 볼륨은 새 볼륨 유형의 volume_backend_name 에 의해 지정된 것과 다른 백엔드에 저장됩니다.

한 백엔드에서 다른 백엔드로 볼륨을 이동하는 경우 광범위한 시간과 리소스가 필요할 수 있습니다. 따라서 재유형에 데이터 이동이 필요한 경우 Block Storage 서비스는 기본적으로 데이터를 이동하지 않습니다. 다시 입력 요청의 일부로 마이그레이션 정책을 지정하여 명시적으로 허용하지 않는 한 작업이 실패합니다. 자세한 내용은 4.5.2절. “명령줄에서 볼륨 다시 생성”의 내용을 참조하십시오.

제한 사항

  • 모든 볼륨을 다시 입력할 수 없습니다. 백엔드 간 볼륨 이동에 대한 자세한 내용은 4.4절. “백엔드 간 볼륨 이동” 을 참조하십시오.
  • 암호화되지 않은 볼륨은 암호화된 볼륨 유형으로 다시 입력할 수 없지만 암호화된 볼륨은 암호화되지 않은 볼륨에 다시 입력할 수 있습니다.
  • 암호화된 볼륨에 암호화 데이터를 저장하는 데 추가 공간이 필요하므로 암호화되지 않은 볼륨을 동일한 크기의 암호화된 볼륨으로 다시 삭제할 수 없습니다. 암호화되지 않은 볼륨을 암호화하는 방법에 대한 자세한 내용은 암호화되지 않은 볼륨 암호화를 참조하십시오.
  • 관리자 권한이 없는 사용자는 소유한 볼륨만 다시 입력할 수 있습니다.

4.5.1. 대시보드 UI에서 볼륨 다시 생성

대시보드 UI를 사용하여 볼륨을 다시 입력합니다.

중요

암호화된 볼륨에 암호화 데이터를 저장하는 데 추가 공간이 필요하므로 암호화되지 않은 볼륨을 동일한 크기의 암호화된 볼륨으로 다시 삭제할 수 없습니다. 암호화되지 않은 볼륨을 암호화하는 방법에 대한 자세한 내용은 암호화되지 않은 볼륨 암호화를 참조하십시오.

사전 요구 사항

절차

  1. 대시보드에서 Project > Compute > Volumes 를 선택합니다.
  2. 마이그레이션할 볼륨의 Actions 열에서 볼륨 유형 변경을 선택합니다.
  3. 볼륨 유형 변경 대화 상자에서 대상 볼륨 유형을 선택하고 유형 목록에서 새 백엔드를 정의합니다.
  4. 볼륨을 다른 백엔드로 마이그레이션하는 경우 Migration Policy (마이그레이션 정책) 목록에서 온 디맨 드를 선택합니다. 자세한 내용은 4.4절. “백엔드 간 볼륨 이동”의 내용을 참조하십시오.
  5. 볼륨 유형 변경을 클릭하여 마이그레이션을 시작합니다.

4.5.2. 명령줄에서 볼륨 다시 생성

대시보드 UI 절차와 유사하게 명령줄에서 볼륨을 다시 입력할 수 있습니다.

중요

암호화된 볼륨에 암호화 데이터를 저장하는 데 추가 공간이 필요하므로 암호화되지 않은 볼륨을 동일한 크기의 암호화된 볼륨으로 다시 삭제할 수 없습니다. 암호화되지 않은 볼륨을 암호화하는 방법에 대한 자세한 내용은 암호화되지 않은 볼륨 암호화를 참조하십시오.

사전 요구 사항

절차

  1. 다음 명령을 입력하여 볼륨을 다시 입력합니다.

    $ cinder retype <volume name or id> <new volume type name>
  2. 다시 유형 작업에 하나의 백엔드에서 다른 백엔드로 볼륨을 이동해야 하는 경우 블록 스토리지 서비스에는 특정 플래그가 필요합니다.

    $ cinder retype --migration-policy on-demand <volume name or id> <new volume type name>

4.6. 여러 인스턴스에 볼륨 연결

볼륨 다중 연결에서는 여러 인스턴스에서 블록 스토리지 볼륨에 대한 동시 읽기/쓰기 액세스를 제공합니다. Ceph RBD 드라이버가 지원됩니다.

주의

다중 연결 또는 클러스터 인식 파일 시스템을 사용하여 여러 인스턴스에서 쓰기 작업을 관리해야 합니다. 이렇게 하지 않으면 데이터 손상이 발생합니다.

다중 연결 볼륨의 제한

  • Block Storage(cinder) 백엔드에서 다중 연결 볼륨을 지원해야 합니다. 지원되는 백엔드에 대한 자세한 내용은 Red Hat 지원에 문의하십시오.
  • Block Storage(cinder) 드라이버가 다중 연결 볼륨을 지원해야 합니다. 벤더 플러그인에 대한 다중 연결이 지원되는지 확인하려면 Red Hat 지원에 문의하십시오. 공급 업체 플러그인의 인증에 대한 자세한 내용은 다음 위치를 참조하십시오.

  • 읽기 전용 다중 연결 볼륨은 지원되지 않습니다.
  • 다중 연결 볼륨의 실시간 마이그레이션을 사용할 수 없습니다.
  • 다중 연결 볼륨의 암호화는 지원되지 않습니다.
  • 다중 연결 볼륨은 Bare Metal Provisioning 서비스(ironic) virt 드라이버에서 지원되지 않습니다. 다중 연결 볼륨은 libvirt virt 드라이버에서만 지원됩니다.
  • 다중 연결 유형에서 다중 연결 유형으로 연결된 볼륨을 다시 입력할 수 없으며 다중 연결 유형에 다중 연결 유형을 다시 입력할 수 없습니다.
  • 연결된 볼륨 마이그레이션 중에 여러 읽기 쓰기 연결이 있는 다중 연결 볼륨은 소스 또는 대상 볼륨으로 사용할 수 없습니다.
  • 보류된 오프로드 인스턴스에 다중 연결 볼륨을 연결할 수 없습니다.

4.6.1. 다중 연결 볼륨 유형 생성

여러 인스턴스에 볼륨을 연결하려면 볼륨 추가 사양에서 multiattach 플래그를 <is> True 로 설정합니다. 다중 연결 볼륨 유형을 생성할 때 볼륨은 플래그를 상속하고 다중 연결 볼륨이 됩니다.

참고

기본적으로 새 볼륨 유형을 생성하는 것은 admin 전용 작업입니다.

사전 요구 사항

절차

  1. 다음 명령을 실행하여 다중 연결 볼륨 유형을 생성합니다.

    $ cinder type-create multiattach
    $ cinder type-key multiattach set multiattach="<is> True"
    참고

    이 절차에서는 다중 연결을 지원하는 모든 백엔드에 볼륨을 생성합니다. 따라서 다중 연결을 지원하는 두 개의 백엔드가 있는 경우 스케줄러는 생성 시 사용 가능한 공간을 기반으로 사용할 백엔드를 결정합니다.

  2. 다음 명령을 실행하여 백엔드를 지정합니다.

    $ cinder type-key multiattach set volume_backend_name=<backend_name>

4.6.2. 다중 연결 볼륨 retyping

볼륨을 다시 입력하여 다중 연결을 수행할 수 있거나 다중 연결 가능 볼륨을 다시 입력하여 여러 인스턴스에 연결할 수 있도록 할 수 있습니다. 그러나 볼륨을 사용하지 않고 해당 상태가 사용 가능한 경우에만 다시 지정할 수 있습니다.

다중 연결 볼륨을 연결할 때 일부 하이퍼바이저는 캐싱을 비활성화할 때와 같은 특별한 고려 사항이 필요합니다. 현재 연결된 볼륨을 전체 시간을 계속 연결하는 동안 안전하게 업데이트할 수 있는 방법은 없습니다. 여러 인스턴스에 연결된 볼륨을 다시 입력하려고 하면 다시 실행되지 않습니다.

4.6.3. 다중 연결 볼륨 생성

다중 연결 볼륨 유형을 생성한 후 다중 연결 볼륨을 생성합니다.

사전 요구 사항

절차

  1. 다음 명령을 실행하여 다중 연결 볼륨을 생성합니다.

    $ cinder create <volume_size> --name <volume_name> --volume-type multiattach
  2. 다음 명령을 실행하여 볼륨이 다중 연결을 수행할 수 있는지 확인합니다. 볼륨이 다중 연결 가능인 경우 multiattach 필드는 True 와 동일합니다.

    $ cinder show <vol_id> | grep multiattach
    
    | multiattach | True |

이제 볼륨을 여러 인스턴스에 연결할 수 있습니다. 자세한 내용은 인스턴스에 볼륨 연결을 참조하십시오.

4.7. 대시보드를 사용하여 백엔드 간 볼륨 마이그레이션

Block Storage 서비스(cinder)를 사용하면 AZ(고가용성 영역) 내에 있는 백엔드 간에 볼륨을 마이그레이션할 수 있습니다. 이는 볼륨을 한 백엔드에서 다른 백엔드로 이동하는 가장 일반적인 방법입니다. 기본 정책을 사용하면 관리자만 볼륨을 마이그레이션할 수 있습니다. 기본 정책을 변경하지 마십시오.

고도로 사용자 지정된 배포 또는 스토리지 시스템을 폐기해야 하는 상황에서는 관리자가 볼륨을 마이그레이션할 수 있습니다. 두 가지 사용 사례에서는 여러 스토리지 시스템이 동일한 volume_backend_name 을 공유하거나 정의되지 않습니다.

제한 사항

  • 볼륨을 복제할 수 없습니다.
  • 대상 백엔드는 볼륨의 현재 백엔드와 달라야 합니다.
  • 기존 볼륨 유형은 새 백엔드에 유효해야 합니다. 즉, 다음 사항이 true여야 합니다.

    • 볼륨 유형에는 extra specs에 backend_volume_name 이 정의되어 있지 않아야 합니다. 그렇지 않으면 두 블록 스토리지 백엔드 모두 동일한 backend_volume_name 을 사용하여 구성해야 합니다.
    • 두 백엔드 모두 씬 프로비저닝 지원, 씩 프로비저닝 지원 또는 기타 기능 구성과 같은 볼륨 유형에 구성된 동일한 기능을 지원해야 합니다.
참고

한 백엔드에서 다른 백엔드로 볼륨을 이동하려면 광범위한 시간과 리소스가 필요할 수 있습니다. 자세한 내용은 4.4절. “백엔드 간 볼륨 이동”의 내용을 참조하십시오.

사전 요구 사항

절차

  1. 대시보드에서 Admin > Volumes 를 선택합니다.
  2. 마이그레이션할 볼륨의 Actions (작업) 열에서 Migrate Volume 을 선택합니다.
  3. Migrate Volume (볼륨 마이그레이션) 대화 상자의 Destination Host (대상 호스트) 드롭다운 목록에서 대상 호스트를 선택합니다.

    참고

    호스트 마이그레이션에 대한 드라이버 최적화를 바이패스하려면 Force Host Copy 확인란을 선택합니다.

  4. 마이그레이션을 클릭하여 마이그레이션을 시작합니다.

4.8. CLI를 사용하여 백엔드 간 볼륨 마이그레이션

Block Storage 서비스(cinder)를 사용하면 AZ(고가용성 영역) 내에 있는 백엔드 간에 볼륨을 마이그레이션할 수 있습니다. 이는 볼륨을 한 백엔드에서 다른 백엔드로 이동하는 가장 일반적인 방법입니다. 기본 정책을 사용하면 관리자만 볼륨을 마이그레이션할 수 있습니다. 기본 정책을 변경하지 마십시오.

고도로 사용자 지정된 배포 또는 스토리지 시스템을 폐기해야 하는 상황에서는 관리자가 볼륨을 마이그레이션할 수 있습니다. 두 가지 사용 사례에서는 여러 스토리지 시스템이 동일한 volume_backend_name 을 공유하거나 정의되지 않습니다.

제한 사항

  • 볼륨을 복제할 수 없습니다.
  • 대상 백엔드는 볼륨의 현재 백엔드와 달라야 합니다.
  • 기존 볼륨 유형은 새 백엔드에 유효해야 합니다. 즉, 다음 사항이 true여야 합니다.

    • 볼륨 유형에는 extra specs에 backend_volume_name 이 정의되어 있지 않아야 합니다. 그렇지 않으면 두 블록 스토리지 백엔드 모두 동일한 backend_volume_name 을 사용하여 구성해야 합니다.
    • 두 백엔드 모두 씬 프로비저닝 지원, 씩 프로비저닝 지원 또는 기타 기능 구성과 같은 볼륨 유형에 구성된 동일한 기능을 지원해야 합니다.
참고

한 백엔드에서 다른 백엔드로 볼륨을 이동하려면 광범위한 시간과 리소스가 필요할 수 있습니다. 자세한 내용은 4.4절. “백엔드 간 볼륨 이동”의 내용을 참조하십시오.

사전 요구 사항

절차

  1. 다음 명령을 입력하여 대상 백엔드의 이름을 검색합니다.

    $ cinder get-pools --detail
    
    Property                      | Value
    
    ...
    
    | name                        | localdomain@lvmdriver-1#lvmdriver-1
    | pool_name                   | lvmdriver-1
    
    ...
    
    | volume_backend_name         | lvmdriver-1
    
    ...
    
    Property                      | Value
    
    ...
                                                          |
    | name                        | localdomain@lvmdriver-2#lvmdriver-1
    | pool_name                   | lvmdriver-1
    
    ...
    
    | volume_backend_name         | lvmdriver-1
    
    ...

    백엔드 이름은 host@volume_backend_name#pool 을 사용합니다.

    예제 출력에는 블록 스토리지 서비스에 두 개의 LVM 백엔드가 노출됩니다. localdomain@lvmdriver-1#lvmdriver-1localdomain@lvmdriver-2#lvmdriver-1. 두 백엔드 모두 동일한 volume_backend_name,lvmdriver-1 을 공유합니다.

  2. 다음 명령을 입력하여 하나의 백엔드에서 다른 백엔드로 볼륨을 마이그레이션합니다.

    $ cinder migrate <volume id or name> <new host>

4.9. 암호화되지 않은 볼륨 암호화

암호화되지 않은 볼륨을 암호화하려면 암호화되지 않은 볼륨을 백업한 다음 암호화된 새 볼륨으로 복원하거나 암호화되지 않은 볼륨에서 Glance 이미지를 만든 다음 이미지에서 새 암호화된 볼륨을 생성해야 합니다.

사전 요구 사항

  • 암호화할 암호화되지 않은 볼륨입니다.

절차

  1. cinder-backup 서비스를 사용할 수 있는 경우 현재 암호화되지 않은 볼륨을 백업합니다.

    cinder backup-create <unencrypted_volume>
    • <unencrypted_volume> 을 암호화되지 않은 볼륨의 이름 또는 ID로 바꿉니다.
  2. 새로 암호화된 볼륨을 생성합니다.

    cinder create <encrypted_volume_size> --volume-type <encrypted_volume_type>
    • <encrypted_volume_size> 를 새 볼륨의 크기(GB)로 바꿉니다. 암호화 메타데이터를 수용하려면 이 값은 암호화되지 않은 볼륨 크기보다 커야 합니다.
    • <encrypted_volume_type> 을 필요한 암호화 유형으로 바꿉니다.
  3. 암호화되지 않은 볼륨의 백업을 새 암호화된 볼륨으로 복원합니다.

    cinder backup-restore <backup> --volume <encrypted_volume>
    • <backup> 을 암호화되지 않은 볼륨 백업의 이름 또는 ID로 바꿉니다.
    • <encrypted_volume> 을 새 암호화된 볼륨의 ID로 바꿉니다.

cinder-backup 서비스를 사용할 수 없는 경우 upload-to-image 명령을 사용하여 암호화되지 않은 볼륨의 이미지를 만든 다음 이미지에서 새 암호화된 볼륨을 만듭니다.

  1. 암호화되지 않은 볼륨의 Glance 이미지를 만듭니다.

    cinder upload-to-image <unencrypted_volume> <new_image>
    • <unencrypted_volume> 을 암호화되지 않은 볼륨의 이름 또는 ID로 바꿉니다.
    • <new_image> 를 새 이미지의 이름으로 바꿉니다.
  2. 이미지보다 1GB 큰 이미지에서 새 볼륨을 생성합니다.

    cinder volume create --size <size> --volume-type luks --image <new_image> <encrypted_volume_name>
    • <size> 를 새 볼륨의 크기로 바꿉니다. 이 값은 암호화되지 않은 이전 볼륨의 크기보다 1GB 커야 합니다.
    • <new_image> 를 암호화되지 않은 볼륨에서 생성한 이미지 이름으로 바꿉니다.
    • <encrypted_volume_name> 을 새 암호화된 볼륨의 이름으로 바꿉니다.

4.10. Red Hat Ceph Storage 백엔드에서 보호 및 보호되지 않은 스냅샷

RHOSP(Red Hat OpenStack Platform) 배포의 백엔드로 RHCS(Red Hat Ceph Storage)를 사용하는 경우 스냅샷을 백엔드에서 보호 하도록 설정할 수 있습니다. 삭제에 실패하여 RHOSP 대시보드 또는 cinder snapshot-delete 명령을 통해 보호된 스냅샷을 삭제하지 마십시오.

이 경우 먼저 RHCS 백엔드에서 스냅샷을 보호 해제 로 설정합니다. 그런 다음 RHOSP를 통해 정상적으로 스냅샷을 삭제할 수 있습니다.

추가 리소스

5장. Object Storage 서비스(swift) 구성

Red Hat OpenStack Platform Object Storage(swift)는 해당 오브젝트 또는 데이터를 컨테이너에 저장합니다. 컨테이너는 파일 시스템의 디렉터리와 유사하지만 중첩할 수 없습니다. 컨테이너는 사용자가 모든 종류의 구조화되지 않은 데이터를 쉽게 저장할 수 있는 방법을 제공합니다. 예를 들어, 오브젝트에는 images, text files 또는 images가 포함될 수 있습니다. 저장된 오브젝트는 압축되지 않습니다.

5.1. 오브젝트 스토리지 링

Object Storage 서비스(swift)는 링이라는 데이터 구조를 사용하여 클러스터 전체에 파티션 공간을 분산합니다. 이 파티션 공간은 오브젝트 스토리지 서비스의 데이터 지속성 엔진의 핵심입니다. 링을 사용하면 오브젝트 스토리지 서비스가 클러스터 전체의 각 파티션을 빠르고 쉽게 동기화할 수 있습니다.

링에는 Object Storage 파티션에 대한 정보와 파티션이 다른 노드 및 디스크에 배포되는 방법이 포함되어 있습니다. 오브젝트 스토리지 구성 요소가 데이터와 상호 작용할 때 링에서 빠른 조회를 수행하여 각 오브젝트에 대해 가능한 파티션을 결정합니다.

오브젝트 스토리지 서비스에는 다음 유형의 데이터를 저장하기 위한 세 개의 링이 있습니다.

  • 계정 정보
  • 계정에서 오브젝트를 쉽게 구성하기 위해 컨테이너
  • 오브젝트 복제본

5.1.1. 클러스터 상태 확인

Object Storage 서비스는 장기적인 데이터 가용성, 지속성 및 지속성을 보장하기 위해 백그라운드에서 많은 프로세스를 실행합니다. 예를 들면 다음과 같습니다.

  • 감사자는 지속적으로 데이터베이스 및 오브젝트 파일을 다시 읽고 체크섬을 사용하여 비교하여 자동 비트로 이동이 없는지 확인합니다. 체크섬과 더 이상 일치하지 않는 데이터베이스 또는 개체 파일은 격리되며 해당 노드에서 읽을 수 없습니다. 그런 다음 복제자는 다른 복제본 중 하나를 복사하여 로컬 복사본을 다시 사용할 수 있도록 합니다.
  • 디스크 또는 노드를 교체하거나 개체가 격리될 때 개체 및 파일이 사라질 수 있습니다. 이러한 상황이 발생하면 복제자는 누락된 오브젝트 또는 데이터베이스 파일을 다른 노드 중 하나로 복사합니다.

오브젝트 스토리지 서비스에는 모든 노드에서 데이터를 수집하고 전체 클러스터 상태를 확인하는 swift-recon 이라는 툴이 포함되어 있습니다.

절차

  1. 컨트롤러 노드 중 하나에 로그인합니다.
  2. 다음 명령을 실행합니다.

    [root@overcloud-controller-2 ~]# sudo podman exec -it -u swift swift_object_server /usr/bin/swift-recon -arqlT --md5
    
    ======================================================================--> Starting reconnaissance on 3 hosts (object)
    ======================================================================[2018-12-14 14:55:47] Checking async pendings
    [async_pending] - No hosts returned valid data.
    ======================================================================[2018-12-14 14:55:47] Checking on replication
    [replication_failure] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3
    [replication_success] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3
    [replication_time] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3
    [replication_attempted] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3
    Oldest completion was 2018-12-14 14:55:39 (7 seconds ago) by 172.16.3.186:6000.
    Most recent completion was 2018-12-14 14:55:42 (4 seconds ago) by 172.16.3.174:6000.
    ======================================================================[2018-12-14 14:55:47] Checking load averages
    [5m_load_avg] low: 1, high: 2, avg: 2.1, total: 6, Failed: 0.0%, no_result: 0, reported: 3
    [15m_load_avg] low: 2, high: 2, avg: 2.6, total: 7, Failed: 0.0%, no_result: 0, reported: 3
    [1m_load_avg] low: 0, high: 0, avg: 0.8, total: 2, Failed: 0.0%, no_result: 0, reported: 3
    ======================================================================[2018-12-14 14:55:47] Checking ring md5sums
    3/3 hosts matched, 0 error[s] while checking hosts.
    ======================================================================[2018-12-14 14:55:47] Checking swift.conf md5sum
    3/3 hosts matched, 0 error[s] while checking hosts.
    ======================================================================[2018-12-14 14:55:47] Checking quarantine
    [quarantined_objects] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3
    [quarantined_accounts] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3
    [quarantined_containers] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3
    ======================================================================[2018-12-14 14:55:47] Checking time-sync
    3/3 hosts matched, 0 error[s] while checking hosts.
    ======================================================================
  3. 선택 사항: --all 옵션을 사용하여 추가 출력을 반환합니다.

    이 명령은 다음 데이터에 대해 링의 모든 서버를 쿼리합니다.

    • 비동기 보류 중: 클러스터 로드가 너무 높으며 프로세스에서 데이터베이스 파일을 충분히 빠르게 업데이트할 수 없는 경우 일부 업데이트가 비동기적으로 수행됩니다. 이 숫자는 시간이 지남에 따라 감소합니다.
    • 복제 지표: 복제 타임 스탬프를 검토합니다. 전체 복제 통과는 몇 가지 오류와 함께 자주 발생합니다. 예를 들어 6개월 전의 타임스탬프가 있는 이전 항목은 노드의 복제가 지난 6개월 동안 완료되지 않았음을 나타냅니다.
    • 링 md5sums: 이렇게 하면 모든 링 파일이 모든 노드에서 일관되게 유지됩니다.
    • Swift.conf md5sums: 이렇게 하면 모든 구성 파일이 모든 노드에서 일관되게 유지됩니다.
    • 격리된 파일: 모든 노드에 대해 no, or very few, quarantined 파일이 있어야 합니다.
    • time-sync: 모든 노드를 동기화해야 합니다.

5.1.2. 링 파티션 전원 증가

링 power는 계정, 컨테이너 또는 오브젝트와 같은 리소스가 매핑되는 파티션을 결정합니다. 파티션은 리소스가 백엔드 파일 시스템에 저장되는 경로에 포함됩니다. 따라서 파티션 전원을 변경하려면 백엔드 파일 시스템의 새 경로로 리소스를 재배치해야 합니다.

많이 채워지는 클러스터에서 재배치 프로세스는 시간이 오래 걸립니다. 다운타임을 방지하기 위해 클러스터가 여전히 작동하는 동안 리소스를 재배치합니다. 데이터에 대한 액세스 권한을 일시적으로 손실하거나 복제 및 감사와 같은 프로세스의 성능을 손상시키지 않고 이 작업을 수행해야 합니다. 링 파티션 전력 증가에 대한 지원이 필요한 경우 Red Hat 지원에 문의하십시오.

5.1.3. 사용자 정의 링

스토리지 용량에 대한 기술 발전 및 수요가 증가함에 따라 사용자 정의 링을 생성하는 것은 기존 Object Storage 클러스터를 업데이트하는 방법입니다.

클러스터에 새 노드를 추가하면 원래 노드와 다른 특성이 다를 수 있습니다. 사용자 지정 조정을 사용하지 않으면 새 노드의 용량이 더 많이 사용되지 않을 수 있습니다. 또는 링에서 가중치가 변경되면 데이터 분산이 불명해질 수 있으므로 안전성이 저하될 수 있습니다.

자동화는 향후 기술 추세에 부합하지 않을 수 있습니다. 예를 들어 현재 사용 중인 일부 이전 Object Storage 클러스터는 SSD를 사용하기 전에 시작됩니다.

링 빌더는 클러스터의 확장 및 기술이 진화할 때 오브젝트 스토리지를 관리하는 데 도움이 됩니다. 사용자 정의 링을 만드는 데 도움이 필요한 경우 Red Hat 지원팀에 문의하십시오.

5.2. Object Storage 서비스 사용자 지정

RHOSP(Red Hat OpenStack Platform) 환경의 요구 사항에 따라 배포 성능을 최적화하기 위해 Object Storage 서비스(swift)의 기본 설정을 사용자 지정해야 할 수 있습니다.

5.2.1. fast-post 구성

기본적으로 개체 스토리지 서비스는 메타데이터의 일부가 변경될 때마다 오브젝트 전체를 복사합니다. 이 기능은 fast-post 기능을 사용하여 이를 방지할 수 있습니다. 빠른 게시 기능은 여러 큰 오브젝트의 콘텐츠 유형을 변경할 때 시간을 절약합니다.

빠른 게시 기능을 활성화하려면 Object Storage 프록시 서비스에서 object_post_as_copy 옵션을 비활성화합니다.

절차

  1. swift_params.yaml 을 편집합니다.

    cat > swift_params.yaml << EOF
    parameter_defaults:
        ExtraConfig:
          swift::proxy::copy::object_post_as_copy: False
    EOF
  2. 오버클라우드를 배포하거나 업데이트할 때 매개변수 파일을 포함합니다.

    openstack overcloud deploy [... previous args ...] -e swift_params.yaml

5.2.2. 유휴 시 암호화 활성화

기본적으로 Object Storage 서비스(swift)에 업로드된 오브젝트는 암호화되지 않습니다. 이로 인해 파일 시스템에서 직접 개체에 액세스할 수 있습니다. 디스크가 삭제되기 전에 제대로 지워지지 않으면 보안 위험이 발생할 수 있습니다.

OpenStack Key Manager(barbican)를 사용하여 유휴 상태의 swift 오브젝트를 암호화할 수 있습니다. 자세한 내용은 유휴 시 swift 오브젝트 암호화를 참조하십시오.

5.2.3. 독립 실행형 Object Storage 클러스터 배포

구성 가능 역할 개념을 사용하여 최소한의 추가 서비스(예: Keystone, HAProxy)를 사용하여 독립 실행형 Object Storage 서비스(swift) 클러스터를 배포할 수 있습니다. roles_data 파일 생성 섹션에는 역할에 대한 정보가 있습니다.

절차

  1. /usr/share/openstack-tripleo-heat-templates 에서 roles_data.yaml 을 복사합니다.
  2. 새 파일을 편집합니다.
  3. Aodh*, Ceilometer*, Ceph*, Cinder*, Glance*, Heat*, Ironic*, Manila*, Mistral*, Nova*, Octavia*, Swift*와 같은 불필요한 컨트롤러 역할을 제거합니다.
  4. roles_data.yaml 내에서 ObjectStorage 역할을 찾습니다.
  5. 이 역할을 동일한 파일 내의 새 역할에 복사하고 ObjectProxy 라는 이름을 지정합니다.
  6. 이 역할의 SwiftStorageSwiftProxy 로 바꿉니다.

    아래 roles_data.yaml 예제 파일은 샘플 역할을 보여줍니다.

    - name: Controller
      description: |
    	Controller role that has all the controller services loaded and handles
    	Database, Messaging and Network functions.
      CountDefault: 1
      tags:
    	- primary
    	- controller
      networks:
    	- External
    	- InternalApi
    	- Storage
    	- StorageMgmt
    	- Tenant
      HostnameFormatDefault: '%stackname%-controller-%index%'
      ServicesDefault:
    	- OS::TripleO::Services::AuditD
    	- OS::TripleO::Services::CACerts
    	- OS::TripleO::Services::CertmongerUser
    	- OS::TripleO::Services::Clustercheck
    	- OS::TripleO::Services::Docker
    	- OS::TripleO::Services::Ec2Api
    	- OS::TripleO::Services::Etcd
    	- OS::TripleO::Services::HAproxy
    	- OS::TripleO::Services::Keepalived
    	- OS::TripleO::Services::Kernel
    	- OS::TripleO::Services::Keystone
    	- OS::TripleO::Services::Memcached
    	- OS::TripleO::Services::MySQL
    	- OS::TripleO::Services::MySQLClient
    	- OS::TripleO::Services::Ntp
    	- OS::TripleO::Services::Pacemaker
    	- OS::TripleO::Services::RabbitMQ
    	- OS::TripleO::Services::Securetty
    	- OS::TripleO::Services::Snmp
    	- OS::TripleO::Services::Sshd
    	- OS::TripleO::Services::Timezone
    	- OS::TripleO::Services::TripleoFirewall
    	- OS::TripleO::Services::TripleoPackages
    	- OS::TripleO::Services::Vpp
    
    - name: ObjectStorage
      CountDefault: 1
      description: |
    	Swift Object Storage node role
      networks:
    	- InternalApi
    	- Storage
    	- StorageMgmt
      disable_upgrade_deployment: True
      ServicesDefault:
    	- OS::TripleO::Services::AuditD
    	- OS::TripleO::Services::CACerts
    	- OS::TripleO::Services::CertmongerUser
    	- OS::TripleO::Services::Collectd
    	- OS::TripleO::Services::Docker
    	- OS::TripleO::Services::FluentdClient
    	- OS::TripleO::Services::Kernel
    	- OS::TripleO::Services::MySQLClient
    	- OS::TripleO::Services::Ntp
    	- OS::TripleO::Services::Securetty
    	- OS::TripleO::Services::SensuClient
    	- OS::TripleO::Services::Snmp
    	- OS::TripleO::Services::Sshd
    	- OS::TripleO::Services::SwiftRingBuilder
    	- OS::TripleO::Services::SwiftStorage
    	- OS::TripleO::Services::Timezone
    	- OS::TripleO::Services::TripleoFirewall
    	- OS::TripleO::Services::TripleoPackages
    
    - name: ObjectProxy
      CountDefault: 1
      description: |
    	Swift Object proxy node role
      networks:
    	- InternalApi
    	- Storage
    	- StorageMgmt
      disable_upgrade_deployment: True
      ServicesDefault:
    	- OS::TripleO::Services::AuditD
    	- OS::TripleO::Services::CACerts
    	- OS::TripleO::Services::CertmongerUser
    	- OS::TripleO::Services::Collectd
    	- OS::TripleO::Services::Docker
    	- OS::TripleO::Services::FluentdClient
    	- OS::TripleO::Services::Kernel
    	- OS::TripleO::Services::MySQLClient
    	- OS::TripleO::Services::Ntp
    	- OS::TripleO::Services::Securetty
    	- OS::TripleO::Services::SensuClient
    	- OS::TripleO::Services::Snmp
    	- OS::TripleO::Services::Sshd
    	- OS::TripleO::Services::SwiftRingBuilder
    	- OS::TripleO::Services::SwiftProxy
    	- OS::TripleO::Services::Timezone
    	- OS::TripleO::Services::TripleoFirewall
    	- OS::TripleO::Services::TripleoPackages
  7. 새 역할을 포함하여 일반 openstack deploy 명령을 사용하여 오버클라우드를 배포합니다.

    openstack overcloud deploy --templates -r roles_data.yaml -e [...]

5.2.4. 외부 SAN 디스크 사용

기본적으로 RHOSP(Red Hat OpenStack Platform) director가 Object Storage 서비스(swift)를 배포하는 경우 Object Storage는 독립 로컬 디스크를 사용하도록 구성 및 최적화됩니다. 이 구성을 사용하면 워크로드가 모든 디스크에 분산되어 노드 장애 또는 기타 시스템 문제 중 성능에 미치는 영향을 최소화할 수 있습니다.

유사한 성능 저하 이벤트에서 단일 SAN을 사용하는 환경은 모든 LUN에서 성능이 저하될 수 있습니다. Object Storage 서비스는 SAN 디스크를 사용하는 환경의 성능 문제를 완화할 수 없습니다.

따라서 Red Hat은 성능 및 디스크 공간 요구 사항을 충족하기 위해 Object Storage에 추가 로컬 디스크를 사용하는 것이 좋습니다. 자세한 내용은 특정 Red Hat OpenStack Platform 서비스 배포 권장 사항 가이드의 Object Storage 서비스(swift)에 대한 구성 권장 사항을 참조하십시오.

오브젝트 스토리지에 외부 SAN을 사용하려면 사례별로 평가를 수행해야 합니다. 자세한 내용은 Red Hat 지원에 문의하십시오.

중요

오브젝트 스토리지용으로 외부 SAN을 사용하도록 선택하는 경우 다음 조건을 유의하십시오.

  • 오브젝트 스토리지 서비스는 기본적으로 Telemetry 데이터 및 Image 서비스(glance) 이미지를 저장합니다. Glance 이미지에는 더 많은 디스크 공간이 필요하지만 성능 관점에서 볼 때 Glance 이미지를 저장하는 경우 원격 분석 데이터를 저장하는 것보다 성능이 저하됩니다. 원격 분석 데이터를 저장 및 처리하려면 성능이 향상되어야 합니다. Red Hat은 오브젝트 스토리지에 외부 SAN을 사용함으로써 발생하는 성능과 관련된 문제를 지원하지 않습니다.
  • Red Hat은 핵심 오브젝트 스토리지 서비스 외부에서 발생하는 문제에 대한 지원을 제공하지 않습니다. 고가용성 및 성능 지원이 필요한 경우 스토리지 벤더에 문의하십시오.
  • Red Hat은 오브젝트 스토리지 서비스로 SAN 솔루션을 테스트하지 않습니다. 타사 제품의 호환성, 지침 및 지원에 대한 자세한 내용은 스토리지 벤더에 문의하십시오.
  • 배포를 통해 성능 요구 사항을 평가하고 테스트하는 것이 좋습니다. SAN 배포가 테스트, 지원 및 성능 요구 사항을 충족하는지 확인하려면 스토리지 벤더에 문의하십시오.

절차

  • 이 템플릿은 오브젝트 스토리지에 두 개의 장치(/dev/mapper/vdb/dev/mapper/octets )를 사용하는 방법의 예입니다.

    parameter_defaults:
      SwiftMountCheck: true
      SwiftUseLocalDir: false
      SwiftRawDisks: {"vdb": {"base_dir":"/dev/mapper/"}, "vdc": {"base_dir":"/dev/mapper/"}}

5.3. 새 Object Storage 노드 추가

새 Object Storage(swift) 노드를 클러스터에 추가하려면 노드 수를 늘리고 링을 업데이트하고 변경 사항을 동기화해야 합니다. 다음 예제 절차에서는 3개의 노드를 4개로 늘립니다.

절차

  1. stack 사용자로 언더클라우드 노드에 로그인하고 stackrc 자격 증명 파일을 가져옵니다.

    $ source ~/stackrc
  2. ObjectStorageCount 매개변수를 사용하여 오브젝트 스토리지 수를 1씩 늘립니다. 일반적으로 이 매개변수는 노드 수가 포함된 환경 파일인 node-info.yaml 파일에 있습니다.

    parameter_defaults:
      ObjectStorageCount: 4
  3. node-info.yaml 파일의 ObjectStorageIPs 매개변수에 새 노드의 IP 주소를 추가합니다.

    ObjectStorageIPs: <ip_address>
  4. 환경 파일(예: hostname-map.yaml )을 생성하고 새 스토리지 노드의 호스트 이름을 HostnameMap 매개변수에 추가합니다.

    parameter_defaults:
      HostnameMap:
        overcloud-objectstorage-4: overcloud-objectstorage-4
  5. 새 노드에 대한 하드웨어 및 전원 관리 정보를 노드 정의 템플릿에 추가합니다. 노드 정의 템플릿은 초기 오버클라우드 구성 중에 오버클라우드 노드를 등록하기 위해 수동으로 생성한 파일입니다. 예를 들어 템플릿은 /home/stack/nodes.json 일 수 있습니다. 다음 예제에서는 템플릿이 YAML 파일인 경우에도 JSON 형식을 사용하지만 YAML 포맷 및 속성에 따라 정보를 추가합니다. 노드 정의 템플릿에 대한 자세한 내용은 Director 설치 및 사용 가이드 의 오버클라우드 노드 등록을 참조하십시오.

    "ports":[
    "bb:bb:bb:bb:bb:bb"
    ],
    "name":"node01",
    "cpu":"4",
    "memory":"6144",
    "disk":"40",
    "arch":"x86_64",
    "pm_type":"pxe_ipmitool",
    "pm_user":"admin",
    "pm_password":"p@55w0rd!",
    "pm_addr":"192.168.24.205"
  6. 새 노드에 대한 기능 정보를 노드 정의 템플릿에 추가합니다.

    "capabilities": "profile:swift-storage,boot_option:local,boot_mode:uefi,node:objectstorage-4",
  7. 노드를 오버클라우드로 가져와서 노드에서 인트로스펙션을 수행합니다.

    $ openstack overcloud node import ~/nodes.yaml
    $ openstack overcloud node introspect objectstorage-4 --provide
  8. 새 노드에 root 디스크 일련 번호를 추가합니다.

    $ openstack baremetal introspection data save objectstorage-4 | jq ".inventory.disks"
    $ openstack baremetal node set --property root_device='{"serial": "<disk_serial_num>"}' <node_UUID>

    새 노드에 따라 < disk_serial_num > 및 < node_UUID >를 바꿉니다.

  9. 해당 환경과 관련된 기타 환경 파일과 함께 배포 명령에 새 노드 구성이 포함된 파일을 포함합니다.

    $ openstack overcloud deploy \
    --templates \
    …
    -e <existing_overcloud_environment_files> \
    -e node-info.yaml \
    -e hostname-map.yaml \

5.3.1. 오브젝트 스토리지 링 업데이트 및 재조정

Object Storage 서비스(swift)는 언더클라우드에 링 파일 사본을 저장하여 새 스토리지 노드를 배포하고 기존 Controller 및 Object Storage 노드를 교체합니다. 이 사본을 사용하여 오버클라우드 링 파일을 수정하고 노드에 배포합니다.

절차

  1. stack 사용자로 언더클라우드에 로그인하고 stackrc 자격 증명 파일을 가져옵니다.

    $ source ~/stackrc
  2. 다음 디렉터리를 생성합니다.

    $ mkdir temp && cd temp/
  3. 오버클라우드 링 빌더 파일을 새 디렉터리로 다운로드합니다.

    $ openstack object save overcloud-swift-rings swift-rings.tar.gz
  4. 링을 추출합니다.

    $ tar xzvf swift-rings.tar.gz
  5. 원래 버전의 링을 백업할 디렉터리를 생성합니다.

    $ mkdir backup && cp swift-rings.tar.gz backup/

    오브젝트 스토리지 링 파일은 etc/swift 폴더에 있습니다.

  6. 장치 세부 정보에 따라 다음 변수의 값을 수집합니다.

    • <device_name>:

      $ openstack baremetal introspection data save <node_name> | jq ".inventory.disks"
    • <node_ip>:

       openstack server show <node_name>
    • < port > 기본 포트는 600x 입니다. 기본값을 변경한 경우 적용 가능한 포트를 사용합니다.
    • < builder_file& gt;단계 3의 빌더 파일 이름입니다.
    • <weight &gt ; 및 <zone > 변수는 사용자 정의입니다.
  7. swift-ring-builder 를 사용하여 새 노드를 기존 링으로 추가하고 업데이트합니다. 장치 세부 정보에 따라 변수를 교체합니다.

    $ swift-ring-builder etc/swift/<builder_file> add <zone>-<node_ip>:<port>/<device_name> <weight>
  8. 수정된 링 파일을 언더클라우드의 오브젝트 스토리지 서비스에 업로드합니다.

    $ tar cvzf swift-rings.tar.gz etc/
    $ openstack object create overcloud-swift-rings swift-rings.tar.gz

5.3.2. 노드 변경 및 데이터 마이그레이션

새 링 파일을 올바른 폴더에 복사한 후 변경된 링 파일을 Object Storage(swift) 컨테이너에 전달해야 합니다.

중요
동시에 모든 데이터를 마이그레이션하지 마십시오. 데이터를 10% 증분으로 마이그레이션합니다. 예를 들어 소스 장치의 가중치를 90.0과 대상 장치의 weight를 10.0으로 구성합니다. 그런 다음 소스 장치의 가중치를 80.0 및 20.0으로 구성합니다. 프로세스를 완료할 때까지 계속 데이터를 점진적으로 마이그레이션합니다. 마이그레이션 중에 모든 데이터를 동시에 이동하는 경우 이전 데이터는 소스 장치에 있지만 링은 모든 복제본의 새 대상 장치를 가리킵니다. 복제자가 모든 데이터를 대상 장치로 이동할 때까지 데이터에 액세스할 수 없습니다.
중요

마이그레이션하는 동안 오브젝트 스토리지 링은 데이터의 위치를 다시 할당한 다음 복제자는 데이터를 새 위치로 이동합니다. 클러스터 활동이 증가하면 로드 증가로 인해 복제 프로세스가 느려집니다. 클러스터가 클수록 복제 전달을 완료하는 데 시간이 길어집니다. 이는 예상 동작이지만 클라이언트가 현재 재배치 중인 데이터에 액세스하는 경우 로그 파일에 404 오류가 발생할 수 있습니다. 프록시에서 새 위치에서 데이터를 검색하려고 하지만 데이터가 아직 새 위치에 있지 않은 경우 swift-proxy 는 로그 파일에 404 오류를 보고합니다.

마이그레이션이 점진적이면 프록시는 이동되지 않고 오류가 발생하지 않는 복제본에 액세스합니다. 그리고 프록시가 대체 복제본에서 데이터를 검색하려고 하면 로그 파일의 404 오류가 해결됩니다. 복제 프로세스가 진행 중인지 확인하려면 복제 로그를 참조하십시오. 오브젝트 스토리지 서비스는 5분마다 복제 로그를 발행합니다.

절차

  1. 다음 예와 유사한 스크립트를 사용하여 언더클라우드 노드에서 지정된 컨트롤러 노드로 링 파일을 배포하고 해당 노드에서 Object Storage 서비스 컨테이너를 다시 시작합니다.

    cd etc/swift/
    for j in 8 11 23; do
      ssh heat-admin@192.168.24."$j" "rm *.ring.gz"
      for i in account.ring.gz container.ring.gz object.ring.gz; do
        scp $i heat-admin@192.168.24."$j":~/
        ssh heat-admin@192.168.24."$j" "sudo cp -f "$i" /var/lib/config-data/puppet-generated/swift/etc/swift/"
        ssh heat-admin@192.168.24."$j" "sudo chown root:root /var/lib/config-data/puppet-generated/swift/etc/swift/"$i""
        ssh heat-admin@192.168.24."$j" "sudo restorecon /var/lib/config-data/puppet-generated/swift/etc/swift/"$i""
      done
      ssh heat-admin@192.168.24."$j" "rm *.builder"
      for i in account.builder container.builder object.builder; do
        scp $i heat-admin@192.168.24."$j":~/
        ssh heat-admin@192.168.24."$j" "cat "$i" | sudo tee  /var/lib/config-data/puppet-generated/swift/etc/swift/"$i" >/dev/null"
      done
      ssh heat-admin@192.168.24."$j" 'for k in `sudo podman ps --format "{{.Names}}" | grep swift`; do sudo podman restart $k; done'
    done
    cd ../../
  2. 데이터가 새 디스크로 이동되고 있는지 확인하려면 새 스토리지 노드에서 다음 명령을 실행합니다.

    $  sudo grep -i replication  /var/log/container/swift/swift.log

5.4. Object Storage 노드 제거

Object Storage(swift) 노드를 제거하는 방법은 두 가지가 있습니다. 클러스터의 복잡성 또는 포함된 데이터 수량에 따라 다음 옵션 중 하나를 선택합니다.

5.4.1. 한 작업에서 Object Storage 노드 제거

이 방법을 사용하여 소량의 데이터가 있는 효율적인 기반 클러스터에서 노드를 제거합니다. 다음 예제 절차에서는 4개의 노드를 3개로 줄입니다.

절차

  1. stack 사용자로 언더클라우드에 로그인하고 stackrc 자격 증명 파일을 가져옵니다.

    $ source ~/stackrc
  2. ObjectStorageCount 매개변수를 사용하여 오브젝트 스토리지 수를 1로 줄입니다. 일반적으로 이 매개변수는 노드 수가 포함된 환경 파일인 node-info.yaml에 있습니다.

    parameter_defaults:
      ObjectStorageCount: 3
  3. node-info.yaml 파일의 ObjectStorageIPs 매개변수에서 제거한 노드의 IP 주소를 삭제합니다.

    ObjectStorageIPs: <ip_address>
  4. 환경 파일(예: remove-object-node.yaml )을 생성합니다. 이 파일은 사용자가 지정하는 Object Storage 노드를 식별하고 삭제합니다. 다음 예제 콘텐츠는 overcloud-objectstorage-1 을 삭제하도록 지정합니다.

    parameter_defaults:
      ObjectStorageRemovalPolicies:
        [{'resource_list': ['1']}]
  5. 배포 명령에 node-info.yamlremove-object-node.yaml 파일을 모두 포함합니다.

    $ openstack overcloud deploy \
    --templates \
    …
    -e <existing_overcloud_environment_files> \
    -e node-info.yaml \
    -e remove-object-node.yaml \
    …

    director가 오버클라우드에서 Object Storage 노드를 삭제하고 오버클라우드에서 나머지 노드를 업데이트하여 노드 삭제를 적용합니다.

  6. 활성 노드를 나열하여 올바른 노드가 제거되었는지 확인합니다.

    $ openstack server list
  7. 언더클라우드 노드에서 remove-object-node.yaml 파일을 삭제하여 향후 재배포에 포함되지 않습니다.

    $ rm <file_path>/remove-object-node.yaml

5.4.2. 링을 변경하여 오브젝트 스토리지 노드를 점진적으로 제거

노드를 제거하는 동안 스토리지 네트워크에 미치는 영향을 최소화해야 하거나 클러스터에 대량의 데이터가 포함된 경우 이 방법을 사용합니다. 스토리지 링을 변경하여 제거할 노드의 디스크 가중치를 줄이려면 먼저 사전 요구 사항에 나열된 절차를 완료합니다. 다음 예제에서는 4에서 3으로 노드를 줄입니다.

사전 요구 사항

절차

  1. stack 사용자로 언더클라우드에 로그인하고 stackrc 자격 증명 파일을 가져옵니다.

    $ source ~/stackrc
  2. ObjectStorageCount 매개변수를 사용하여 오브젝트 스토리지 수를 1로 줄입니다. 일반적으로 이 매개변수는 노드 수가 포함된 환경 파일인 node-info.yaml에 있습니다.

    parameter_defaults:
      ObjectStorageCount: 3
  3. node-info.yaml 파일의 ObjectStorageIPs 매개변수에서 제거한 노드의 IP 주소를 삭제합니다.

    ObjectStorageIPs: <ip_address>
  4. 환경 파일(예: remove-object-node.yaml )을 생성합니다. 이 파일은 사용자가 지정하는 Object Storage 노드를 식별하고 삭제합니다. 다음 예제 콘텐츠는 overcloud-objectstorage-1 을 삭제하도록 지정합니다.

    parameter_defaults:
      ObjectStorageRemovalPolicies:
        [{'resource_list': ['1']}]
  5. 배포 명령에 node-info.yamlremove-object-node.yaml 파일을 모두 포함합니다.

    $ openstack overcloud deploy \
    --templates \
    …
    -e <existing_overcloud_environment_files> \
    -e node-info.yaml \
    -e remove-object-node.yaml \
    …

    director가 오버클라우드에서 Object Storage 노드를 삭제하고 오버클라우드에서 나머지 노드를 업데이트하여 노드 삭제를 적용합니다.

  6. 활성 노드를 나열하여 올바른 노드가 제거되었는지 확인합니다.

    $ openstack server list
  7. 언더클라우드 노드에서 remove-object-node.yaml 파일을 삭제하여 향후 재배포에 포함되지 않습니다.

    $ rm <file_path>/remove-object-node.yaml

5.5. Object Storage 노드 교체

이 섹션에서는 클러스터의 무결성에 영향을 주지 않고 Object Storage 노드를 교체하는 방법을 설명합니다. 다음 예제에서는 세 개의 노드로 이루어진 Object Storage 클러스터에서 노드를 overcloud-objectstorage-1 노드를 교체합니다. 이 절차의 목표는 노드를 하나 추가한 다음 overcloud-objectstorage-1 노드를 삭제하는 것입니다. overcloud-objectstorage-1 노드가 새로운 노드로 대체됩니다.

절차

  1. ObjectStorageCount 매개변수를 사용하여 Object Storage 수를 늘립니다. 일반적으로 이 매개변수는 노드 수가 포함된 환경 파일인 node-info.yaml에 있습니다.

    parameter_defaults:
      ObjectStorageCount: 4

    ObjectStorageCount 매개변수는 해당 환경의 Object Storage 노드 수를 정의합니다. 이 예제에서는 Object Storage 노드의 수량을 3에서 4로 확장합니다.

  2. 업데이트된 ObjectStorageCount 매개변수를 사용하여 배포 명령을 실행합니다.

    $ source ~/stackrc
    (undercloud) $ openstack overcloud deploy --templates -e node-info.yaml <environment_files>

    배포 명령이 완료되면 오버클라우드에 추가 Object Storage 노드가 포함됩니다.

  3. 데이터를 새 노드에 복제합니다. 노드(이 경우 overcloud-objectstorage-1)를 삭제하기 전에 replication pass가 새 노드에서 완료될 때까지 기다립니다. /var/log/swift/swift.log 파일 전송 복제 진행 상태를 확인합니다. 전달이 완료되면 Object Storage 서비스에서 다음 예제와 비슷한 항목을 로그에 기록해야 합니다.

    Mar 29 08:49:05 localhost *object-server: Object replication complete.*
    Mar 29 08:49:11 localhost *container-server: Replication run OVER*
    Mar 29 08:49:13 localhost *account-server: Replication run OVER*
  4. 링에서 이전 노드를 삭제하려면 ObjectStorageCount 매개변수를 줄여 이전 노드를 제거합니다. 이 예제에서는 ObjectStorageCount 매개변수를 3으로 줄입니다.

    parameter_defaults:
      ObjectStorageCount: 3
  5. remove-object-node.yaml이라는 새 환경 파일을 생성합니다. 이 파일은 지정된 Object Storage 노드를 식별하고 삭제합니다. 다음 콘텐츠는 overcloud-objectstorage-1을 삭제하도록 지정합니다.

    parameter_defaults:
      ObjectStorageRemovalPolicies:
        [{'resource_list': ['1']}]
  6. 배포 명령에 node-info.yamlremove-object-node.yaml 파일을 모두 포함합니다.

    (undercloud) $ openstack overcloud deploy --templates -e node-info.yaml <environment_files> -e remove-object-node.yaml

director가 오버클라우드에서 Object Storage 노드를 삭제하고 오버클라우드에서 나머지 노드를 업데이트하여 노드 삭제를 적용합니다.

중요

오버클라우드를 처음 생성할 때의 모든 환경 파일과 옵션을 포함합니다. 여기에는 컴퓨팅 이외의 노드에 대한 동일한 확장 매개변수가 포함됩니다.

5.6. 오브젝트 스토리지 서비스의 기본 컨테이너 관리

Object Storage 서비스(swift)의 조직에 도움이 되도록 의사 폴더를 사용할 수 있습니다. 이러한 폴더는 개체를 포함하고 중첩될 수 있는 논리 장치입니다. 예를 들어 이미지를 저장할 이미지 폴더와 이미지를 저장할 미디어 폴더를 만들 수 있습니다.

각 프로젝트에서 하나 이상의 컨테이너를 생성하고 각 컨테이너에서 하나 이상의 오브젝트 또는 의사 폴더를 생성할 수 있습니다.

5.6.1. 오브젝트 스토리지 서비스에서 컨테이너 생성

대시보드를 사용하여 컨테이너를 만듭니다.

절차

  1. 대시보드에서 프로젝트 > 오브젝트 저장소 > 컨테이너를 선택합니다.
  2. 컨테이너 생성을 클릭합니다.
  3. 컨테이너 이름을 지정하고 Container Access 필드에서 다음 중 하나를 선택합니다.

    유형설명

    private

    현재 프로젝트의 사용자에게 액세스를 제한합니다.

    public

    공용 URL을 사용하는 모든 사용자에게 API 액세스를 허용합니다. 그러나 대시보드에서 프로젝트 사용자는 다른 프로젝트의 공용 컨테이너 및 데이터를 볼 수 없습니다.

  4. 컨테이너 생성을 클릭합니다.
  5. 선택 사항: 새 컨테이너는 기본 스토리지 정책을 사용합니다. 예를 들어 기본 정책 및 삭제 코딩을 활성화하는 다른 정책과 같이 여러 스토리지 정책이 정의되어 있는 경우 기본이 아닌 스토리지 정책을 사용하도록 컨테이너를 구성할 수 있습니다.

    # swift post -H "X-Storage-Policy:<policy>" <container_name>

    <policy> 를 컨테이너에서 사용할 정책의 이름 또는 별칭으로 바꾸고 <container_name> 을 컨테이너 이름으로 교체합니다.

5.6.2. 오브젝트 스토리지 서비스에서 컨테이너의 의사 폴더 생성

대시보드를 사용하여 컨테이너의 의사 폴더를 생성합니다.

절차

  1. 대시보드에서 프로젝트 > 오브젝트 저장소 > 컨테이너를 선택합니다.
  2. pseudo 폴더를 추가할 컨테이너 이름을 클릭합니다.
  3. Pseudo-folder 만들기를 클릭합니다.
  4. Pseudo-folder Name 필드에 이름을 지정하고 Create 를 클릭합니다.

5.6.3. 오브젝트 스토리지 서비스에서 컨테이너 삭제

대시보드를 사용하여 컨테이너를 삭제합니다.

절차

  1. 대시보드에서 프로젝트 > 오브젝트 저장소 > 컨테이너를 선택합니다.
  2. 컨테이너 섹션에서 컨테이너 검색하고 모든 오브젝트가 삭제되었는지 확인합니다. 자세한 내용은 오브젝트 삭제를 참조하십시오.
  3. 컨테이너 화살표 메뉴에서 컨테이너 삭제를 선택합니다.
  4. Delete Container (컨테이너 삭제)를 클릭하여 컨테이너 제거를 확인합니다.

5.6.4. 오브젝트 스토리지 서비스에 오브젝트 업로드

실제 파일을 업로드하지 않으면 나중에 파일을 업로드하는 데 사용할 수 있는 자리 표시자로 오브젝트가 계속 생성됩니다.

절차

  1. 대시보드에서 프로젝트 > 오브젝트 저장소 > 컨테이너를 선택합니다.
  2. 업로드된 오브젝트를 배치하려는 컨테이너 이름을 클릭합니다. 컨테이너에 pseudo 폴더가 이미 있는 경우 해당 이름을 클릭할 수 있습니다.
  3. 파일을 찾아 오브젝트 업로드 를 클릭합니다.
  4. 오브젝트 이름 필드에 이름을 지정합니다.

    • / 문자를 사용하여 이름에 의사 폴더를 지정할 수 있습니다(예: Images/myImage.tempest ). 지정된 폴더가 없는 경우 오브젝트를 업로드할 때 생성됩니다.
    • 위치(즉, 개체가 이미 존재하는 이름)는 오브젝트의 내용을 덮어씁니다.
  5. 업로드 오브젝트 를 클릭합니다.

5.6.5. 오브젝트 스토리지 서비스 내에서 오브젝트 복사

대시보드를 사용하여 오브젝트를 복사합니다.

절차

  1. 대시보드에서 프로젝트 > 오브젝트 저장소 > 컨테이너를 선택합니다.
  2. 오브젝트의 컨테이너 또는 폴더의 이름을 클릭하여 오브젝트를 표시합니다.
  3. 업로드 오브젝트 를 클릭합니다.
  4. 복사할 파일을 찾아 화살표 메뉴에서 복사합니다.
  5. 다음을 지정합니다.

    필드설명

    대상 컨테이너

    새 오브젝트의 대상 컨테이너입니다.

    경로

    대상 컨테이너의 pseudo-폴더. 폴더가 없는 경우 생성됩니다.

    대상 오브젝트 이름

    새 오브젝트의 이름입니다. 위치에 고유하지 않은 이름을 사용하는 경우(즉, 개체가 이미 존재하는 경우) 오브젝트의 이전 콘텐츠를 덮어씁니다.

  6. Copy Object 를 클릭합니다.

5.6.6. 오브젝트 스토리지 서비스에서 오브젝트 삭제

대시보드를 사용하여 오브젝트를 삭제합니다.

절차

  1. 대시보드에서 프로젝트 > 오브젝트 저장소 > 컨테이너를 선택합니다.
  2. 오브젝트를 찾아 화살표 메뉴에서 Delete Object 를 선택합니다.
  3. Delete Object (오브젝트 삭제)를 클릭하여 오브젝트가 제거되었는지 확인합니다.

6장. Shared File Systems 서비스(manila) 구성

Shared File Systems 서비스(manila)를 사용하면 여러 컴퓨팅 인스턴스, 베어 메탈 노드 또는 컨테이너가 사용할 수 있는 공유 파일 시스템을 프로비저닝할 수 있습니다. 클라우드 관리자는 공유 서비스를 준비하고 최종 사용자가 공유를 생성하고 관리할 수 있도록 공유 유형을 생성합니다.

사전 요구 사항

  • 최종 사용자에게는 공유 파일 시스템 서비스를 사용하려면 하나 이상의 공유 유형이 필요합니다.
  • driver_handles_share_servers=False 인 백엔드의 경우 클라우드 관리자는 공유 파일 시스템 백엔드에서 동적으로 필요하지 않은 네트워킹을 미리 구성합니다.
  • NFS 백엔드를 통한 CephFS의 경우 클라우드 관리자는 격리된 네트워크 및 환경 인수가 있는 RHOSP(Red Hat OpenStack Platform) director와 사용자 지정 network_data 파일을 배포하여 NFS 내보내기를 위한 격리된 StorageNFS 네트워크를 생성합니다. 배포 후 오버클라우드를 사용하기 전에 관리자는 데이터 센터의 격리된 스토리지 NFS 네트워크에 매핑되는 해당 네트워킹 서비스(neutron) 스토리지 NFS 공유 공급자 네트워크를 생성합니다.
  • Compute 인스턴스가 이 공유 공급자 네트워크에 연결하려면 사용자가 추가 neutron 포트를 추가해야 합니다.

6.1. 공유 파일 시스템 서비스 백엔드

클라우드 관리자가 RHOSP(Red Hat OpenStack Platform) director를 사용하여 Shared File Systems 서비스(manila)를 배포하는 경우 다음과 같은 지원되는 백엔드 중 하나 이상을 선택할 수 있습니다.

지원되는 백엔드 어플라이언스 및 드라이버의 전체 목록은 RHEL OpenStack Platform의 구성 요소, 플러그인 및 드라이버 지원을 참조하십시오.

6.1.1. 다중 백엔드 사용

백엔드는 파일 시스템을 내보낼 공유 파일 시스템 서비스(manila) 드라이버와 페어링된 스토리지 시스템 또는 기술입니다. 공유 파일 시스템 서비스에는 작동을 위해 하나 이상의 백엔드가 필요합니다. 많은 경우 백엔드 한 개이면 충분합니다. 그러나 단일 공유 파일 시스템 서비스 설치에서 여러 백엔드를 사용할 수도 있습니다.

중요

현재 RHOSP(Red Hat OpenStack Platform)는 공유 파일 시스템 서비스 배포에 동일한 백엔드의 여러 인스턴스를 지원하지 않습니다. 예를 들어 동일한 배포 내의 백엔드로 두 개의 Ceph Storage 클러스터를 추가할 수 없습니다. 선택한 백엔드는 이기종이어야 합니다. NFS를 통한 CephFS 기본 및 CephFS는 다른 프로토콜의 백엔드 중 하나로 간주됩니다.

공유 파일 시스템 서비스의 스케줄러는 공유 생성 요청에 대한 대상 백엔드를 결정합니다. 공유 파일 시스템 서비스의 단일 백엔드는 여러 스토리지 풀을 노출할 수 있습니다.

여러 백엔드를 구성하면 스케줄러는 하나의 스토리지 풀을 선택하여 구성된 모든 백엔드에서 노출되는 모든 풀에서 리소스를 생성합니다. 이는 최종 사용자로부터 추상화됩니다. 최종 사용자는 클라우드 관리자가 노출하는 기능만 표시됩니다.

6.1.2. 다중 백엔드 배포

기본적으로 표준 공유 파일 시스템 배포 환경 파일에는 단일 백엔드가 있습니다. 다음 예제 절차에 따라 Shared File Systems 서비스(manila)에 여러 백엔드를 추가하고 CephFS-Ganesha 및 NetApp 백엔드가 있는 환경을 배포합니다.

사전 요구 사항

  • 백엔드는 적어도 두 개 이상입니다.
  • 백엔드에 사용자 지정 컨테이너가 필요한 경우 표준 Shared File Systems 서비스 컨테이너 대신 Red Hat Ecosystem Catalog 의 컨테이너를 사용해야 합니다. 예를 들어, Ceph와 함께 Dell EMC 유니티 스토리지 시스템 백엔드를 사용하려면 카탈로그에서 Dell EMC Unity 컨테이너를 선택합니다.

절차

  1. 스토리지 사용자 지정 YAML 파일을 생성합니다. 이 파일은 환경에 적합한 값을 제공하거나 재정의하는 데 사용할 수 있습니다.

    $ vi /home/stack/templates/storage_customizations.yaml
  2. 여러 백엔드를 활성화하는 등 덮어쓰기를 포함하도록 스토리지 사용자 지정 YAML 파일을 구성합니다.

    parameter_defaults:
      ManilaEnabledShareProtocols:
        - NFS
      ManilaNetappLogin: '<login_name>'
      ManilaNetappPassword: '<password>'
      ManilaNetappServerHostname: '<netapp-hostname>'
      ManilaNetappVserver: ‘<netapp-vserver>’
      ManilaNetappDriverHandlesShareServers: 'false'
    참고

    ManilaEnabledShareProtocols 매개변수에 대한 자세한 내용은 6.1.4절. “허용된 NAS 프로토콜 덮어쓰기” 을 참조하십시오.

  3. openstack overcloud deploy 명령에서 백엔드 템플릿을 지정합니다. 예제 구성을 사용하면 NFS 백엔드를 통해 NetApp 백엔드와 CephFS를 사용하여 공유 파일 시스템 서비스를 사용할 수 있습니다.

    $ openstack overcloud deploy \
      --timeout 100 \
      --stack overcloud \
      --templates /usr/share/openstack-tripleo-heat-templates \
      -n /usr/share/openstack-tripleo-heat-templates/network_data_ganesha.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-mds.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
      -r /home/stack/templates/roles/roles_data.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/manila-cephfsganesha-config.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/manila-netapp-config.yaml \
    -e /home/stack/templates/storage_customizations.yaml \
    
    ...
    참고

    배포 명령에 대한 자세한 내용은 Director Installation and Usage 를 참조하십시오.

6.1.3. 다중 백엔드 배포 확인

manila service-list 명령을 사용하여 백엔드가 성공적으로 배포되었는지 확인합니다. 여러 백엔드에서 상태 점검을 사용하면 백엔드 중 하나가 응답하지 않는 경우에도 ping 테스트에서 응답을 반환하므로 배포를 확인하는 안정적인 방법이 아닙니다.

절차

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. overcloudrc 인증 정보 파일을 소싱합니다.

    $ source ~/overcloudrc
  3. 공유 파일 시스템 서비스 백엔드 목록을 확인합니다.

    $ manila service-list
    
    +----+--------+--------+------+---------+-------+----------------------------+
    | Id | Binary | Host | Zone | Status | State | Updated_at |
    +----+--------+--------+------+---------+-------+----------------------------+
    | 2 | manila-scheduler | hostgroup | nova | enabled | up | 2021-03-24T16:49:09.000000 |
    | 5 | manila-share | hostgroup@cephfs | nova | enabled | up | 2021-03-24T16:49:12.000000 |
    | 8 | manila-share | hostgroup@tripleo_netapp | nova | enabled | up | 2021-03-24T16:49:06.000000 |

    성공적으로 배포된 각 백엔드의 상태가 enabled 로 표시되고 상태가 up 으로 표시됩니다.

6.1.4. 허용된 NAS 프로토콜 덮어쓰기

공유 파일 시스템 서비스는 NFS, CIFS 또는CEPHFS와 같은 많은 NAS(네트워크 연결 스토리지) 프로토콜 중 하나로 공유를 내보낼 수 있습니다. 기본적으로 공유 파일 시스템 서비스는 배포의 백엔드에서 지원하는 모든 NAS 프로토콜을 활성화합니다.

RHOSP(Red Hat OpenStack Platform) 관리자는 ManilaEnabledShareProtocols 매개변수를 재정의하고 클라우드에서 허용하려는 프로토콜만 나열할 수 있습니다.

예를 들어 배포의 백엔드가 NFS와 CIFS를 모두 지원하는 경우 기본값을 재정의하고 하나의 프로토콜만 활성화할 수 있습니다.

절차

  1. 언더클라우드 호스트에 stack 사용자로 로그인합니다.
  2. overcloudrc 인증 정보 파일을 소싱합니다.
  3. 스토리지 사용자 지정 YAML 파일을 생성합니다. 이 파일은 환경에 적합한 값을 제공하거나 재정의하는 데 사용할 수 있습니다.

    $ vi /home/stack/templates/storage_customizations.yaml
  4. 원하는 값으로 ManilaEnabledShareProtocols 매개변수를 구성합니다.

    parameter_defaults:
      ManilaEnabledShareProtocols:
        - NFS
        - CEPHFS
  5. -e 옵션을 사용하여 openstack overcloud deploy 에 새 콘텐츠가 포함된 환경 파일을 포함합니다. 배포와 관련된 기타 모든 환경 파일을 포함해야 합니다.

    	openstack overcloud deploy \
    	...
    	-e /home/stack/templates/storage_customizations.yaml
    참고

    배포에서 설정의 유효성을 검사하지 않습니다. 할당하는 NAS 프로토콜은 공유 파일 시스템 서비스 배포의 백엔드에서 지원해야 합니다.

6.1.5. 백엔드 기능 보기

Shared File Systems 서비스(manila)의 스케줄러 구성 요소는 용량, 프로비저닝 구성, 배치 힌트, 백엔드 스토리지 시스템 드라이버가 탐지하고 노출하는 기능과 같은 여러 요인에 따라 지능형 배치 결정을 내립니다.

절차

  • 다음 명령을 실행하여 사용 가능한 기능을 확인합니다.

    $ manila pool-list --detail
    +------------------------------------+----------------------------+
    | Property                           | Value                      |
    +------------------------------------+----------------------------+
    | name                               | hostgroup@cephfs#cephfs    |
    | pool_name                          | cephfs                     |
    | total_capacity_gb                  | 1978                       |
    | free_capacity_gb                   | 1812                       |
    ...
    | driver_handles_share_servers       | False                      |
    | snapshot_support                   | True                       |
    | create_share_from_snapshot_support | False                      |
    | revert_to_snapshot_support         | False                      |
    | mount_snapshot_support             | False                      |
    ...
    +------------------------------------+----------------------------+
    +------------------------------------+-----------------------------------+
    | Property                           | Value                             |
    +------------------------------------+-----------------------------------+
    | name                               | hostgroup@tripleo_netapp#aggr1_n1 |
    | pool_name                          | aggr1_n1                          |
    | total_capacity_gb                  | 6342.1                            |
    | free_capacity_gb                   | 6161.99                           |
    ...
    | driver_handles_share_servers       | False                             |
    | mount_snapshot_support             | False                             |
    | replication_type                   | None                              |
    | replication_domain                 | None                              |
    | sg_consistent_snapshot_support     | host                              |
    | ipv4_support                       | True                              |
    | ipv6_support                       | False                             |
    +------------------------------------+-----------------------------------+
    +------------------------------------+-----------------------------------+
    | Property                           | Value                             |
    +------------------------------------+-----------------------------------+
    | name                               | hostgroup@tripleo_netapp#aggr1_n2 |
    | pool_name                          | aggr1_n2                          |
    | total_capacity_gb                  | 6342.1                            |
    | free_capacity_gb                   | 6209.26                           |
    ...
    | snapshot_support                   | True                              |
    | create_share_from_snapshot_support | True                              |
    | revert_to_snapshot_support         | True                              |
    | driver_handles_share_servers       | False                             |
    | mount_snapshot_support             | False                             |
    | replication_type                   | None                              |
    | replication_domain                 | None                              |
    | sg_consistent_snapshot_support     | host                              |
    | ipv4_support                       | True                              |
    | ipv6_support                       | False                             |
    +------------------------------------+-----------------------------------+

관련 정보

배치 결정에 영향을 주기 위해 관리자로서 공유 유형과 추가 사양을 사용할 수 있습니다. 공유 유형에 대한 자세한 내용은 공유 유형 만들기를 참조하십시오.

6.2. 공유 유형 생성

공유 유형은 배치 결정을 수행하기 위해 공유 파일 시스템 서비스 스케줄러에 대한 힌트 역할을 합니다. RHOSP(Red Hat OpenStack Platform) director는 default라는 기본 공유 유형으로 공유 파일 시스템 서비스를 구성하지만 공유 유형을 생성하지는 않습니다.

중요
최종 사용자에게는 공유 파일 시스템 서비스를 사용하려면 하나 이상의 공유 유형이 필요합니다.

절차

  1. 오버클라우드를 배포한 후 다음 명령을 클라우드 관리자로 실행하여 공유 유형을 생성합니다.

    # manila type-create default <spec_driver_handles_share_servers>

    <spec_driver_handles_share_servers> 매개변수는 부울 값입니다.

    • NFS 또는 기본 CephFS를 통한 CephFS의 경우 값은 false입니다.
    • 다른 백엔드의 경우 값은 true 또는 false일 수 있습니다. <spec_driver_handles_share_servers> 를 설정하여 Manila<backend>DriverHandlesShareServers 매개변수 값과 일치시킵니다. 예를 들어 NetApp 백엔드를 사용하는 경우 매개변수는 ManilaNetappDriverHandlesShareServers 라고 합니다.
  2. 기본 공유 유형에 사양을 추가하거나 구성된 여러 백엔드에 사용할 추가 공유 유형을 생성합니다. 예를 들어 CephFS 백엔드와 NetApp driver_handles_share_servers=True 백엔드를 사용하는 추가 공유 유형을 선택하도록 기본 공유 유형을 구성합니다.

    (overcloud) [stack@undercloud-0 ~]$ manila type-create default false --extra-specs share_backend_name='cephfs'
    (overcloud) [stack@undercloud-0 ~]$ manila type-create netapp true --extra-specs share_backend_name='tripleo_netapp'
참고

기본적으로 공유 유형은 공용이므로 모든 Cloud 프로젝트에서 볼 수 있지만 특정 프로젝트 내에서 사용할 수 있도록 개인 공유 유형을 만들 수 있습니다. 개인 공유 유형을 설정하거나 추가 공유 유형 옵션을 설정하는 방법에 대한 자세한 내용은 보안 및 강화 가이드를 참조하십시오.

6.2.1. 공유 유형의 공통 기능

공유 유형은 공유의 공통 기능을 정의합니다. 공유 유형의 일반적인 기능을 검토하여 공유로 수행할 수 있는 작업을 파악합니다.

표 6.1. 공유 유형 기능

기능설명

driver_handles_share_servers

true 또는 false

공유 네트워크를 사용하여 공유를 생성할 수 있는 권한을 부여합니다.

snapshot_support

true 또는 false

공유의 스냅샷을 생성할 수 있는 권한을 부여합니다.

create_share_from_snapshot_support

true 또는 false

공유 스냅샷의 복제본을 생성할 수 있는 권한을 부여합니다.

revert_to_snapshot_support

true 또는 false

공유를 최신 스냅샷으로 되돌릴 수 있는 권한을 부여합니다.

mount_snapshot_support

true 또는 false

스냅샷을 내보내고 마운트할 수 있는 권한을 부여합니다.

replication_type

dr

재해 복구를 위해 복제본을 생성할 수 있는 권한을 부여합니다. 한 번에 하나의 활성 내보내기만 허용됩니다.

읽기 가능

읽기 전용 복제본을 만들 수 있는 권한을 부여합니다. 한 번에 하나의 쓰기 가능한 활성 내보내기만 허용됩니다.

쓰기 가능

읽기/쓰기 복제본을 생성할 수 있는 권한을 부여합니다. 공유당 한 번에 여러 개의 활성 내보내기가 허용됩니다.

availability_zones

하나 이상의 가용성 영역 목록

나열된 가용성 영역에서만 공유를 생성할 수 있는 권한을 부여합니다.

6.2.2. 공유 유형 검색

클라우드 사용자는 공유를 생성할 때 공유 유형을 지정해야 합니다.

절차

  1. 사용 가능한 공유 유형을 검색합니다.

    $ manila type-list

    명령 출력에는 공유 유형의 이름과 ID가 나열됩니다.

6.3. 공유 생성

데이터를 읽고 쓸 공유를 만듭니다.

공유를 생성하려면 다음과 유사한 명령을 사용합니다.

$ manila create [--share-type <sharetype>] [--name <sharename>] proto GB

다음 값을 바꿉니다.

  • sharetype 은 지정된 공유 유형과 관련된 설정을 적용합니다.

    • 선택 사항: 지정되지 않은 경우 기본 공유 유형이 사용됩니다.
  • sharename 은 공유의 이름입니다.

    • 선택 사항: 공유에는 이름이 있을 필요가 없으며 고유해야 하는 이름은 아닙니다.
  • Proto 는 사용하려는 공유 프로토콜입니다.

    • NFS를 사용하는 CephFS의 경우 protonfs 입니다.
    • CephFS 기본의 경우 protocephfs 입니다.
    • NetApp 및 Dell EMC 스토리지 백엔드의 경우 protonfs 또는 cifs 입니다.
  • GB 는 공유 크기(GB)입니다.

예를 들어 6.2절. “공유 유형 생성” 에서 클라우드 관리자는 CephFS 백엔드를 선택하는 기본 공유 유형과 NetApp 백엔드를 선택하는 netapp 이라는 다른 공유 유형을 생성했습니다.

절차

  1. 예제 공유 유형을 사용하여 CephFS NFS 백엔드에 share-01 이라는 10GB NFS 공유를 생성합니다. 이 예에서는 NFS와 함께 CephFS를 사용합니다.

    (user) [stack@undercloud-0 ~]$ manila create --name share-01 nfs 10
  2. 선택 사항: NetApp 백엔드에 share-02 라는 20GB NFS 공유를 생성합니다.

    (user) [stack@undercloud-0 ~]$ manila create --name share-02 --share-type netapp --share-network mynet nfs 20

6.3.1. 공유 나열 및 정보 내보내기

공유가 생성되었는지 확인하려면 다음 단계를 완료합니다.

절차

  1. 공유를 나열합니다.

    (user) [stack@undercloud-0 ~]$ manila list
    
    +--------------------------------------+----------+-----+-----------+           | ID                                   | Name     | ... | Status    ...
    +--------------------------------------+----------+-----+-----------+
    | 8c3bedd8-bc82-4100-a65d-53ec51b5fe81 | share-01 | ... | available ...
    +--------------------------------------+----------+-----+-----------+
  2. 공유의 내보내기 위치를 확인합니다.

    (user) [stack@undercloud-0 ~]$ manila share-export-location-list share-01
    
     +------------------------------------------------------------------
     | Path
     |  172.17.5.13:/volumes/_nogroup/e840b4ae-6a04-49ee-9d6e-67d4999fbc01
     +------------------------------------------------------------------
  3. 공유의 매개변수를 확인합니다.

    manila share-export-location-show <id>
    참고

    이 정보는 6.6.2절. “공유 마운트” 에서 공유를 마운트하는 데 사용됩니다.

6.4. 공유 파일 시스템용 네트워킹

공유 파일 시스템은 네트워크를 통해 액세스할 수 있습니다. 최종 사용자 클라이언트가 RHOSP(Red Hat OpenStack Platform) 가상 머신, 베어 메탈 서버 및 컨테이너에서 실행되는 워크로드에 공유를 연결할 수 있도록 클라우드에 네트워킹을 계획하는 것이 중요합니다.

최종 사용자에게 필요한 보안 및 격리 수준에 따라 관리자는 driver_handles_share_servers 매개변수를 true 또는 false로 설정할 수 있습니다.

driver_handles_share_servers 매개변수를 true로 설정하면 서비스가 분리된 공유 서버의 도움말을 사용하여 최종 사용자 정의 공유 네트워크에 공유를 내보낼 수 있습니다.

driver_handles_share_servers 매개변수가 true인 경우 사용자는 셀프 서비스 공유 네트워크에서 워크로드를 프로비저닝할 수 있습니다. 이렇게 하면 전용 네트워크 세그먼트에서 해당 공유를 완전히 격리된 NAS 파일 서버에서 내보낼 수 있습니다.

최종 사용자가 사용하는 공유 네트워크는 생성할 수 있는 프라이빗 프로젝트 네트워크와 같을 수 있습니다. 관리자는 이러한 격리된 네트워크를 매핑하는 물리적 네트워크가 스토리지 인프라로 확장되도록 해야 합니다.

또한 프로젝트 네트워크의 네트워크 세그멘테이션 스타일도 사용된 스토리지 시스템에서 지원되어야 합니다. NetApp ONTAP 및 Dell EMC PowerMax, Unity 및 VNX와 같은 스토리지 시스템은 GEN서 또는 VXLAN과 같은 가상 오버레이 분할 스타일을 지원하지 않습니다.

또는 최상위 스위치에서 오버레이 네트워킹을 종료하고 VLAN과 같은 프로젝트 네트워크에 대해 보다 원시적인 네트워킹 형식을 사용할 수 있습니다. 또 다른 대안은 공유 공급자 네트워크의 VLAN 세그먼트를 허용하거나 이미 스토리지 시스템에 연결된 기존 세그먼트 네트워크에 대한 액세스를 제공하는 것입니다.

driver_handles_share_servers 매개변수를 false로 설정하면 사용자가 자체 공유 네트워크에 공유를 생성할 수 없습니다. 대신 클라우드 관리자가 구성한 네트워크에 클라이언트를 연결해야 합니다.

driver_handles_share_servers 매개변수가 false인 경우 director는 전용 공유 스토리지 네트워크를 생성할 수 있습니다. 예를 들어 표준 director 템플릿을 사용하여 기본 CephFS 백엔드를 배포할 때 director는 Storage 라는 공유 공급자 네트워크를 생성합니다. NFS 백엔드를 통해 CephFS를 배포할 때 공유 공급자 네트워크는 StorageNFS 라고 합니다. 최종 사용자가 공유에 액세스하려면 클라이언트를 공유 스토리지 네트워크에 연결해야 합니다.

모든 공유 파일 시스템 스토리지 드라이버가 두 작업 모드를 모두 지원하는 것은 아닙니다. 어떤 모드를 선택하든 이 서비스는 하드 데이터 경로 멀티 테넌시 격리를 보장합니다.

하드 네트워크 경로 멀티 테넌시 격리를 제공하여 테넌트 워크로드에 셀프 서비스 모델의 일부로 보장하는 경우 driver_handles_share_servers 드라이버 모드를 지원하는 백엔드와 함께 배포해야 합니다.

공유에 대한 네트워크 연결에 대한 자세한 내용은 다음을 참조하십시오. 6.4.1절. “공유에 대한 네트워크 연결 확인”

6.4.1. 공유에 대한 네트워크 연결 확인

파일 공유에 연결해야 하는 클라이언트에는 해당 공유에 대한 내보내기 위치 중 하나 이상의 네트워크에 연결되어 있어야 합니다.

네트워크 플러그인 사용을 포함하여 공유 파일 시스템 서비스로 네트워킹을 구성하는 방법에는 여러 가지가 있습니다.

공유 유형의 driver_handles_share_servers 매개변수가 true인 경우 클라우드 사용자는 컴퓨팅 인스턴스가 연결되는 네트워크의 세부 정보로 공유 네트워크를 생성한 다음 공유를 생성할 때 참조할 수 있습니다.

공유 유형의 driver_handles_share_servers 매개변수가 false인 경우 클라우드 사용자가 컴퓨팅 인스턴스를 공유 스토리지 네트워크에 연결해야 합니다.

공유 네트워크에 대한 네트워크 연결을 구성하고 확인하는 방법에 대한 자세한 내용은 6.4.2절. “공유 영역에 액세스하기 위해 공유 네트워크에 연결” 을 참조하십시오.

6.4.2. 공유 영역에 액세스하기 위해 공유 네트워크에 연결

driver_handles_share_servers 매개변수가 false인 경우 관리자가 사용 가능한 공유 공급자 네트워크로 공유를 내보냅니다. 최종 사용자는 Compute 인스턴스와 같은 클라이언트를 공유 공급자 네트워크에 연결하여 공유에 액세스해야 합니다.

이 예제 절차에서는 공유 공급자 네트워크를 StorageNFS라고 합니다. StorageNFS는 director가 NFS 백엔드를 통해 CephFS와 함께 공유 파일 시스템 서비스를 배포할 때 구성됩니다. 클라우드 관리자가 사용 가능한 네트워크에 연결하려면 유사한 단계를 수행하십시오.

참고

예제 절차에서는 클라이언트의 IP 주소 제품군 버전이 중요하지 않습니다. 이 절차의 단계에서는 IPv4 주소 지정을 사용하지만 단계는 IPv6과 동일합니다.

절차

  1. 패킷이 포트를 송신할 수 있지만 연결되지 않은 연결에서 수신 패킷을 허용하지 않는 스토리지 NFS 포트에 대한 보안 그룹을 만듭니다.

    (user) [stack@undercloud-0 ~]$ openstack security group create no-ingress -f yaml
    created_at: '2018-09-19T08:19:58Z'
    description: no-ingress
    id: 66f67c24-cd8b-45e2-b60f-9eaedc79e3c5
    name: no-ingress
    project_id: 1e021e8b322a40968484e1af538b8b63
    revision_number: 2
    rules: 'created_at=''2018-09-19T08:19:58Z'', direction=''egress'', ethertype=''IPv4'',
     id=''6c7f643f-3715-4df5-9fef-0850fb6eaaf2'', updated_at=''2018-09-19T08:19:58Z''
    
     created_at=''2018-09-19T08:19:58Z'', direction=''egress'', ethertype=''IPv6'',                                                          id=''a8ca1ac2-fbe5-40e9-ab67-3e55b7a8632a'', updated_at=''2018-09-19T08:19:58Z'''
    updated_at: '2018-09-19T08:19:58Z'
  2. no-ingress 보안 그룹에서 적용되는 보안을 사용하여 StorageNFS 네트워크에 포트를 만듭니다.

    (user) [stack@undercloud-0 ~]$ openstack port create nfs-port0 --network StorageNFS --security-group no-ingress -f yaml
    
    admin_state_up: UP
    allowed_address_pairs: ''
    binding_host_id: null
    binding_profile: null
    binding_vif_details: null
    binding_vif_type: null
    binding_vnic_type: normal
    created_at: '2018-09-19T08:03:02Z'
    data_plane_status: null
    description: ''
    device_id: ''
    device_owner: ''
    dns_assignment: null
    dns_name: null
    extra_dhcp_opts: ''
    fixed_ips: ip_address='172.17.5.160', subnet_id='7bc188ae-aab3-425b-a894-863e4b664192'
    id: 7a91cbbc-8821-4d20-a24c-99c07178e5f7
    ip_address: null
    mac_address: fa:16:3e:be:41:6f
    name: nfs-port0
    network_id: cb2cbc5f-ea92-4c2d-beb8-d9b10e10efae
    option_name: null
    option_value: null
    port_security_enabled: true
    project_id: 1e021e8b322a40968484e1af538b8b63
    qos_policy_id: null
    revision_number: 6
    security_group_ids: 66f67c24-cd8b-45e2-b60f-9eaedc79e3c5
    status: DOWN
    subnet_id: null
    tags: ''
    trunk_details: null
    updated_at: '2018-09-19T08:03:03Z'
    참고

    StorageNFSSubnet 은 IP 주소 172.17.5.160을 nfs-port0 에 할당했습니다.

  3. Compute 인스턴스에 nfs-port0 을 추가합니다.

    (user) [stack@undercloud-0 ~]$ openstack server add port instance0 nfs-port0
    (user) [stack@undercloud-0 ~]$ openstack server list -f yaml
    - Flavor: m1.micro
      ID: 0b878c11-e791-434b-ab63-274ecfc957e8
      Image: manila-test
      Name: demo-instance0
      Networks: demo-network=172.20.0.4, 10.0.0.53; StorageNFS=172.17.5.160
      Status: ACTIVE

    개인 및 유동 주소 외에도 Compute 인스턴스에는 스토리지 NFS 네트워크의 IP 주소가 172.17.5.160인 포트에 할당됩니다. 이 포트에는 해당 공유에 대한 액세스가 부여될 때 NFS 공유를 마운트하는 데 사용할 수 있습니다.

    참고

    Compute 인스턴스에서 네트워킹 구성을 조정하고 Compute 인스턴스에 대한 서비스를 다시 시작하여 이 주소와 인터페이스를 활성화해야 할 수 있습니다.

6.4.3. 네트워크와 인스턴스 간 IPv6 인터페이스 구성

공유가 내보낸 공유 네트워크가 IPv6 주소 지정을 사용하는 경우 보조 인터페이스에서 DHCPv6에 문제가 발생할 수 있습니다. 인스턴스에서 IPv6 인터페이스를 수동으로 구성하려면 다음 절차를 사용하십시오. 자세한 내용은 BZ#1859695 를 참조하십시오.

사전 요구 사항

  • 공유 네트워크에 연결하여 공유에 액세스합니다.

절차

  1. 인스턴스에 로그인합니다.
  2. IPv6 인터페이스 주소를 구성합니다.

    $ ip address add fd00:fd00:fd00:7000::c/64 dev eth1
  3. 인터페이스를 활성화합니다.

    $ ip link set dev eth1 up
  4. 공유의 내보내기 위치에 있는 IPv6 주소를 ping하여 인터페이스 연결을 테스트합니다.

    $ ping -6  fd00:fd00:fd00:7000::21
  5. 또는 Telnet을 통해 NFS 서버에 연결할 수 있는지 확인합니다.

    $ dnf install -y telnet
    $ telnet fd00:fd00:fd00:7000::21 2049

6.5. 공유 액세스 권한 부여

컴퓨팅 인스턴스와 같은 클라이언트에 공유를 마운트하려면 먼저 다음과 유사한 명령을 사용하여 공유에 대한 클라이언트 액세스 권한을 부여해야 합니다.

# manila access-allow <share> <accesstype> --access-level <accesslevel>  <clientidentifier>

다음 값을 바꿉니다.

  • share - 6.3절. “공유 생성” 에서 생성된 공유의 공유 이름 또는 ID입니다.
  • accesstype - 공유에서 요청할 액세스 유형입니다. 일부 유형은 다음과 같습니다.

    • user: 사용자 또는 그룹 이름으로 인증하는 데 사용합니다.
    • ip: IP 주소를 통해 인스턴스를 인증하는 데 사용합니다.
    • rootfs : 네이티브 CephFS 클라이언트 이름에서 인증하는 데 사용합니다.

      참고

      액세스 유형은 공유 프로토콜에 따라 다릅니다. NFS 공유의 경우 ip 액세스 유형만 허용됩니다. CIFS의 경우 사용자 액세스 유형이 적합합니다. 기본 CephFS 공유의 경우 RuntimeClass를 사용해야 합니다.

  • AccessLevel - 선택 사항, 기본값은 rw

    • RW: 공유에 대한 읽기-쓰기 액세스.
    • ro: 공유에 대한 읽기 전용 액세스입니다.
  • clientidentifier - 액세스 유형에 따라 다릅니다.

    • ip accesstype 에 IP 주소를 사용합니다.
    • 사용자 액세스 유형 에는 CIFS 사용자 또는 그룹을 사용합니다.
    • rootfs 액세스 유형에 사용자 이름 문자열을 사용합니다.

6.5.1. 공유에 대한 액세스 권한 부여

사용자가 공유에서 데이터를 읽고 데이터에 쓸 수 있도록 최종 사용자 클라이언트에 공유에 대한 액세스 권한을 부여해야 합니다.

이 절차를 사용하여 인스턴스의 IP 주소를 통해 클라이언트 컴퓨팅 인스턴스에 NFS 공유에 대한 액세스 권한을 부여합니다. CNF 공유 및 CephFS 공유에 대한 stderr 규칙의 사용자 규칙은 유사한 패턴을 따릅니다. uservGPU 액세스 유형을 사용하면 원하는 경우 여러 클라이언트에서 동일한 clientidentifier 를 사용할 수 있습니다.

참고

예제 절차에서는 클라이언트의 IP 주소 제품군 버전이 중요하지 않습니다. 이 절차의 단계에서는 IPv4 주소 지정을 사용하지만 단계는 IPv6과 동일합니다.

절차

  1. 공유를 마운트하려는 클라이언트 컴퓨팅 인스턴스의 IP 주소를 검색합니다. 공유에 연결할 수 있는 네트워크에 해당하는 IP 주소를 선택해야 합니다. 이 예에서는 StorageNFS 네트워크의 IP 주소입니다.

    (user) [stack@undercloud-0 ~]$ openstack server list -f yaml
    - Flavor: m1.micro
      ID: 0b878c11-e791-434b-ab63-274ecfc957e8
      Image: manila-test
      Name: demo-instance0
      Networks: demo-network=172.20.0.4, 10.0.0.53;
      StorageNFS=172.17.5.160
      Status: ACTIVE
    
    (user) [stack@undercloud-0 ~]$ manila access-allow share-01 ip 172.17.5.160
    참고

    공유에 대한 액세스에는 자체 ID(accessid)가 있습니다.

    +-----------------+---------------------------------------+
    | Property        | Value                                 |
    +-----------------+---------------------------------------+
    | access_key      | None
    | share_id        | db3bedd8-bc82-4100-a65d-53ec51b5cba3
    | created_at      | 2018-09-17T21:57:42.000000
    | updated_at      | None
    | access_type     | ip
    | access_to       | 172.17.5.160
    | access_level    | rw
    | state           | queued_to_apply
    | id              | 875c6251-c17e-4c45-8516-fe0928004fff
    +-----------------+---------------------------------------+
  2. 액세스 구성이 성공했는지 확인합니다.

    (user) [stack@undercloud-0 ~]$ manila access-list share-01
    
    +--------------+-------------+--------------+--------------+--------+ ...
    | id           | access_type | access_to    | access_level | state  | ...
    +--------------+-------------+--------------+--------------+--------+
    | 875c6251-... | ip          | 172.17.5.160 | rw       	   | active | ...
    +--------------+------------+--------------+--------------+---------+ ...

6.5.2. 공유에 대한 액세스 권한 취소

공유 소유자는 어떠한 이유로든 공유에 대한 액세스를 취소할 수 있습니다. 공유에 대한 이전에 생성된 액세스를 취소하려면 다음 단계를 완료합니다.

절차

  1. 공유에 대한 액세스 권한 취소:

    # manila access-deny <share> <accessid>
    참고

    <share> 를 공유 이름 또는 공유 ID로 바꿉니다.

    예를 들면 다음과 같습니다.

    (user) [stack@undercloud-0 ~]$ manila access-list share-01
    +--------------+-------------+--------------+--------------+--------+
    | id           | access_type | access_to    | access_level | state  | ...
    +--------------+-------------+--------------+--------------+--------+ ...
    | 875c6251-... | ip          | 172.17.5.160 | rw       	   | active | ...
    +--------------+-------------+--------------+--------------+--------+
    
    (user) [stack@undercloud-0 ~]$ manila access-deny share-01 875c6251-c17e-4c45-8516-fe0928004fff
    
    (user) [stack@undercloud-0 ~]$ manila access-list share-01
    
    +--------------+------------+--------------+--------------+--------+ ...
    | id           | access_type| access_to    | access_level | state  | ...
    +--------------+------------+--------------+--------------+--------+ ...
    +--------------+------------+--------------+--------------+--------+ ...
참고

읽기-쓰기 권한이 있는 기존 클라이언트가 있는 경우 공유에 대한 액세스를 취소하고 클라이언트가 읽기 전용 권한을 갖도록 하려면 읽기 전용 규칙을 추가해야 합니다.

6.6. 컴퓨팅 인스턴스에 공유 마운트

클라이언트에 대한 액세스 권한을 부여하면 공유를 마운트하고 사용할 수 있습니다. 클라이언트에 대한 네트워크 연결이 있는 한 모든 유형의 클라이언트에서 공유에 액세스할 수 있습니다.

가상 컴퓨팅 인스턴스에 NFS 공유를 마운트하는 데 사용되는 단계는 베어 메탈 컴퓨팅 인스턴스에 NFS 공유를 마운트하는 단계와 유사합니다. OpenShift 컨테이너에 공유를 마운트하는 방법에 대한 자세한 내용은 OpenShift Container Platform 제품 설명서 를 참조하십시오.

참고

다른 프로토콜의 클라이언트 패키지를 공유를 마운트하는 Compute 인스턴스에 설치해야 합니다. 예를 들어 NFS를 통해 CephFS를 사용하는 공유 파일 시스템 서비스의 경우 NFS 클라이언트 패키지에서 NFS 4.1을 지원해야 합니다.

6.6.1. 공유 내보내기 위치 나열

공유를 마운트할 수 있도록 공유의 내보내기 위치를 검색합니다.

절차

  1. 공유의 내보내기 위치를 검색합니다.

    (user) [stack@undercloud-0 ~]$ manila share-export-location-list share-01

    여러 내보내기 위치가 있는 경우 기본 메타데이터 필드의 값이 True인 값을 선택합니다. 기본 위치가 없는 경우 내보내기 위치를 사용할 수 있습니다.

6.6.2. 공유 마운트

클라이언트에 공유를 마운트하여 데이터 액세스를 활성화합니다.

공유 액세스 생성 및 부여에 대한 자세한 내용은 다음 절차를 참조하십시오.

절차

  1. 인스턴스에 로그인하고 다음 명령을 실행합니다.

    (user) [stack@undercloud-0 ~]$ openstack server ssh demo-instance0 --login root
    # hostname
    demo-instance0
  2. 내보내기 위치를 사용하여 IPv4 네트워크에 공유를 마운트합니다.

    # mount -t nfs -v  172.17.5.13:/volumes/_nogroup/e840b4ae-6a04-49ee-9d6e-67d4999fbc01 /mnt

6.7. 공유 삭제

Shared File Systems 서비스(manila)는 데이터를 삭제하지 못하도록 보호 기능을 제공하지 않습니다. 공유 파일 시스템 서비스는 클라이언트가 연결되어 있는지 또는 워크로드가 실행 중인지 여부를 확인하지 않습니다. 공유를 삭제하면 해당 공유를 검색할 수 없습니다.

경고
공유를 삭제하기 전에 데이터를 백업하십시오.

절차

  1. 공유를 삭제합니다.

    # manila delete <share>
    참고

    예제 명령에서 <share>는 공유 이름 또는 공유 ID일 수 있습니다.

    예를 들면 다음과 같습니다.

    # manila delete share-01

6.8. 공유 파일 시스템 서비스에서 기본 할당량 변경

알림없이 시스템 용량이 소진되지 않도록 클라우드 관리자는 할당량을 구성할 수 있습니다. 할당량은 운영 제한입니다.

6.8.1. 할당량 나열

클라우드 관리자는 manila quota-show 명령을 사용하여 프로젝트 또는 사용자의 할당량을 나열할 수 있습니다. 선택적 --user 매개변수를 포함하는 경우 지정된 프로젝트에서 이 사용자에 대한 할당량을 볼 수 있습니다. 이 매개변수를 생략하면 지정된 프로젝트에 대한 할당량이 표시됩니다.

할당량을 업데이트하고 삭제할 수 있습니다. 공유, 스냅샷, GB, 스냅샷- 기가바이트, 공유 네트워크, share_groups,share_group_snapshots, share-type 할당량을 업데이트할 수 있습니다.

절차

  1. usage 문을 보려면 다음 명령을 실행합니다.

    # manila help quota-show
    # manila help quota-update
    # manila help quota-delete

6.9. 장애 문제 해결

공유 그룹 생성 또는 공유 그룹 생성과 같은 Shared File Systems(manila) 작업이 최종 사용자로 비동기적으로 실패하는 경우 명령 줄에서 오류에 대한 자세한 내용을 확인할 수 있습니다.

6.9.1. 생성 생성 또는 공유 그룹 오류 생성

이 예에서 최종 사용자의 목표는 여러 가상 시스템에서 소프트웨어 라이브러리를 호스트하는 것입니다. 이 예제에서는 명령줄을 사용하여 사용자 지원 메시지를 검색하는 방법을 설명하기 위해 의도적으로 두 가지 공유 생성 실패를 도입합니다.

절차

  1. 공유를 생성하려면 공유를 보유할 일부 기능을 지정하는 공유 유형을 사용할 수 있습니다. 클라우드 관리자는 공유 유형을 생성할 수 있습니다. 사용 가능한 공유 유형을 확인합니다.

    clouduser1@client:~$ manila type-list
    +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+
    | ID                                   | Name        | visibility | is_default | required_extra_specs                 | optional_extra_specs                       | Description |
    +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+
    | 1cf5d45a-61b3-44d1-8ec7-89a21f51a4d4 | dhss_false  | public     | YES        | driver_handles_share_servers : False | create_share_from_snapshot_support : True  | None        |
    |                                      |             |            |            |                                      | mount_snapshot_support : False             |             |
    |                                      |             |            |            |                                      | revert_to_snapshot_support : False         |             |
    |                                      |             |            |            |                                      | snapshot_support : True                    |             |
    | 277c1089-127f-426e-9b12-711845991ea1 | dhss_true   | public     | -          | driver_handles_share_servers : True  | create_share_from_snapshot_support : True  | None        |
    |                                      |             |            |            |                                      | mount_snapshot_support : False             |             |
    |                                      |             |            |            |                                      | revert_to_snapshot_support : False         |             |
    |                                      |             |            |            |                                      | snapshot_support : True                    |             |
    +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+

    이 예에서는 두 가지 공유 유형을 사용할 수 있습니다.

  2. driver_handles_share_servers=True 기능을 지정하는 공유 유형을 사용하려면 공유를 내보낼 공유 네트워크를 생성해야 합니다. 사설 프로젝트 네트워크에서 공유 네트워크를 만듭니다.

    clouduser1@client:~$ openstack subnet list
    +--------------------------------------+---------------------+--------------------------------------+---------------------+
    | ID                                   | Name                | Network                              | Subnet              |
    +--------------------------------------+---------------------+--------------------------------------+---------------------+
    | 78c6ac57-bba7-4922-ab81-16cde31c2d06 | private-subnet      | 74d5cfb3-5dd0-43f7-b1b2-5b544cb16212 | 10.0.0.0/26         |
    | a344682c-718d-4825-a87a-3622b4d3a771 | ipv6-private-subnet | 74d5cfb3-5dd0-43f7-b1b2-5b544cb16212 | fd36:18fc:a8e9::/64 |
    +--------------------------------------+---------------------+--------------------------------------+---------------------+
    
    clouduser1@client:~$ manila share-network-create --name mynet --neutron-net-id 74d5cfb3-5dd0-43f7-b1b2-5b544cb16212 --neutron-subnet-id 78c6ac57-bba7-4922-ab81-16cde31c2d06
    +-------------------+--------------------------------------+
    | Property          | Value                                |
    +-------------------+--------------------------------------+
    | network_type      | None                                 |
    | name              | mynet                                |
    | segmentation_id   | None                                 |
    | created_at        | 2018-10-09T21:32:22.485399           |
    | neutron_subnet_id | 78c6ac57-bba7-4922-ab81-16cde31c2d06 |
    | updated_at        | None                                 |
    | mtu               | None                                 |
    | gateway           | None                                 |
    | neutron_net_id    | 74d5cfb3-5dd0-43f7-b1b2-5b544cb16212 |
    | ip_version        | None                                 |
    | cidr              | None                                 |
    | project_id        | cadd7139bc3148b8973df097c0911016     |
    | id                | 0b0fc320-d4b5-44a1-a1ae-800c56de550c |
    | description       | None                                 |
    +-------------------+--------------------------------------+
    
    clouduser1@client:~$ manila share-network-list
    +--------------------------------------+-------+
    | id                                   | name  |
    +--------------------------------------+-------+
    | 6c7ef9ef-3591-48b6-b18a-71a03059edd5 | mynet |
    +--------------------------------------+-------+
  3. 공유를 생성합니다.

    clouduser1@client:~$ manila create nfs 1 --name software_share --share-network mynet --share-type dhss_true
    +---------------------------------------+--------------------------------------+
    | Property                              | Value                                |
    +---------------------------------------+--------------------------------------+
    | status                                | creating                             |
    | share_type_name                       | dhss_true                            |
    | description                           | None                                 |
    | availability_zone                     | None                                 |
    | share_network_id                      | 6c7ef9ef-3591-48b6-b18a-71a03059edd5 |
    | share_server_id                       | None                                 |
    | share_group_id                        | None                                 |
    | host                                  |                                      |
    | revert_to_snapshot_support            | False                                |
    | access_rules_status                   | active                               |
    | snapshot_id                           | None                                 |
    | create_share_from_snapshot_support    | False                                |
    | is_public                             | False                                |
    | task_state                            | None                                 |
    | snapshot_support                      | False                                |
    | id                                    | 243f3a51-0624-4bdd-950e-7ed190b53b67 |
    | size                                  | 1                                    |
    | source_share_group_snapshot_member_id | None                                 |
    | user_id                               | 61aef4895b0b41619e67ae83fba6defe     |
    | name                                  | software_share                       |
    | share_type                            | 277c1089-127f-426e-9b12-711845991ea1 |
    | has_replicas                          | False                                |
    | replication_type                      | None                                 |
    | created_at                            | 2018-10-09T21:12:21.000000           |
    | share_proto                           | NFS                                  |
    | mount_snapshot_support                | False                                |
    | project_id                            | cadd7139bc3148b8973df097c0911016     |
    | metadata                              | {}                                   |
    +---------------------------------------+--------------------------------------+
  4. 공유 상태를 확인합니다.

    clouduser1@client:~$ manila list
    +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+
    | ID                                   | Name           | Size | Share Proto | Status | Is Public | Share Type Name | Host | Availability Zone |
    +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+
    | 243f3a51-0624-4bdd-950e-7ed190b53b67 | software_share | 1    | NFS         | error  | False     | dhss_true       |      | None              |
    +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+

    이 예에서는 공유 생성 중에 오류가 발생했습니다.

  5. 사용자 지원 메시지를 보려면 message-list 명령을 실행합니다. --resource-id 를 사용하여 찾을 특정 공유를 필터링합니다.

    clouduser1@client:~$ manila message-list
    +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
    | ID                                   | Resource Type | Resource ID                          | Action ID | User Message                                                                                             | Detail ID | Created At                 |
    +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
    | 7d411c3c-46d9-433f-9e21-c04ca30b209c | SHARE         | 243f3a51-0624-4bdd-950e-7ed190b53b67 | 001       | allocate host: No storage could be allocated for this share request, Capabilities filter didn't succeed. | 008       | 2018-10-09T21:12:21.000000 |
    +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+

    User Message (사용자 메시지) 열에서 기능 불일치로 인해 공유 파일 시스템 서비스가 공유를 생성하지 못했습니다.

  6. 더 많은 메시지 정보를 보려면 message-show 명령을 실행한 다음 message-list 명령의 메시지 ID를 입력합니다.

    clouduser1@client:~$ manila message-show 7d411c3c-46d9-433f-9e21-c04ca30b209c
    +---------------+----------------------------------------------------------------------------------------------------------+
    | Property      | Value                                                                                                    |
    +---------------+----------------------------------------------------------------------------------------------------------+
    | request_id    | req-0a875292-6c52-458b-87d4-1f945556feac                                                                 |
    | detail_id     | 008                                                                                                      |
    | expires_at    | 2018-11-08T21:12:21.000000                                                                               |
    | resource_id   | 243f3a51-0624-4bdd-950e-7ed190b53b67                                                                     |
    | user_message  | allocate host: No storage could be allocated for this share request, Capabilities filter didn't succeed. |
    | created_at    | 2018-10-09T21:12:21.000000                                                                               |
    | message_level | ERROR                                                                                                    |
    | id            | 7d411c3c-46d9-433f-9e21-c04ca30b209c                                                                     |
    | resource_type | SHARE                                                                                                    |
    | action_id     | 001                                                                                                      |
    +---------------+----------------------------------------------------------------------------------------------------------+
  7. 클라우드 사용자는 사용 가능한 공유 유형을 검토할 수 있도록 공유 유형을 통해 기능을 확인할 수 있습니다. 두 공유 유형 간의 차이점은 driver_handles_share_servers 의 값입니다.

    clouduser1@client:~$ manila type-list
    +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+
    | ID                                   | Name        | visibility | is_default | required_extra_specs                 | optional_extra_specs                       | Description |
    +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+
    | 1cf5d45a-61b3-44d1-8ec7-89a21f51a4d4 | dhss_false  | public     | YES        | driver_handles_share_servers : False | create_share_from_snapshot_support : True  | None        |
    |                                      |             |            |            |                                      | mount_snapshot_support : False             |             |
    |                                      |             |            |            |                                      | revert_to_snapshot_support : False         |             |
    |                                      |             |            |            |                                      | snapshot_support : True                    |             |
    | 277c1089-127f-426e-9b12-711845991ea1 | dhss_true   | public     | -          | driver_handles_share_servers : True  | create_share_from_snapshot_support : True  | None        |
    |                                      |             |            |            |                                      | mount_snapshot_support : False             |             |
    |                                      |             |            |            |                                      | revert_to_snapshot_support : False         |             |
    |                                      |             |            |            |                                      | snapshot_support : True                    |             |
    +--------------------------------------+-------------+------------+------------+--------------------------------------+--------------------------------------------+-------------+
  8. 사용 가능한 다른 공유 유형으로 공유를 생성합니다.

    clouduser1@client:~$ manila create nfs 1 --name software_share --share-network mynet --share-type dhss_false
    +---------------------------------------+--------------------------------------+
    | Property                              | Value                                |
    +---------------------------------------+--------------------------------------+
    | status                                | creating                             |
    | share_type_name                       | dhss_false                           |
    | description                           | None                                 |
    | availability_zone                     | None                                 |
    | share_network_id                      | 6c7ef9ef-3591-48b6-b18a-71a03059edd5 |
    | share_group_id                        | None                                 |
    | revert_to_snapshot_support            | False                                |
    | access_rules_status                   | active                               |
    | snapshot_id                           | None                                 |
    | create_share_from_snapshot_support    | True                                 |
    | is_public                             | False                                |
    | task_state                            | None                                 |
    | snapshot_support                      | True                                 |
    | id                                    | 2d03d480-7cba-4122-ac9d-edc59c8df698 |
    | size                                  | 1                                    |
    | source_share_group_snapshot_member_id | None                                 |
    | user_id                               | 5c7bdb6eb0504d54a619acf8375c08ce     |
    | name                                  | software_share                       |
    | share_type                            | 1cf5d45a-61b3-44d1-8ec7-89a21f51a4d4 |
    | has_replicas                          | False                                |
    | replication_type                      | None                                 |
    | created_at                            | 2018-10-09T21:24:40.000000           |
    | share_proto                           | NFS                                  |
    | mount_snapshot_support                | False                                |
    | project_id                            | cadd7139bc3148b8973df097c0911016     |
    | metadata                              | {}                                   |
    +---------------------------------------+--------------------------------------+

    이 예에서 두 번째 공유 생성 시도가 실패합니다.

  9. 사용자 지원 메시지 보기:

    clouduser1@client:~$ manila list
    +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+
    | ID                                   | Name           | Size | Share Proto | Status | Is Public | Share Type Name | Host | Availability Zone |
    +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+
    | 2d03d480-7cba-4122-ac9d-edc59c8df698 | software_share | 1    | NFS         | error  | False     | dhss_false      |      | nova              |
    | 243f3a51-0624-4bdd-950e-7ed190b53b67 | software_share | 1    | NFS         | error  | False     | dhss_true       |      | None              |
    +--------------------------------------+----------------+------+-------------+--------+-----------+-----------------+------+-------------------+
    
    clouduser1@client:~$ manila message-list
    +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
    | ID                                   | Resource Type | Resource ID                          | Action ID | User Message                                                                                             | Detail ID | Created At                 |
    +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
    | ed7e02a2-0cdb-4ff9-b64f-e4d2ec1ef069 | SHARE         | 2d03d480-7cba-4122-ac9d-edc59c8df698 | 002       | create: Driver does not expect share-network to be provided with current configuration.                  | 003       | 2018-10-09T21:24:40.000000 |
    | 7d411c3c-46d9-433f-9e21-c04ca30b209c | SHARE         | 243f3a51-0624-4bdd-950e-7ed190b53b67 | 001       | allocate host: No storage could be allocated for this share request, Capabilities filter didn't succeed. | 008       | 2018-10-09T21:12:21.000000 |
    +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+

    서비스에서는 사용한 공유 유형 공유 네트워크가 필요하지 않습니다.

  10. 관리자에게 문의하지 않으면 관리자가 개인 neutron 네트워크로 직접 공유를 지원하는 스토리지 백엔드를 사용할 수 없습니다. share-network 매개변수 없이 공유를 생성합니다.

    clouduser1@client:~$ manila create nfs 1 --name software_share --share-type dhss_false
    +---------------------------------------+--------------------------------------+
    | Property                              | Value                                |
    +---------------------------------------+--------------------------------------+
    | status                                | creating                             |
    | share_type_name                       | dhss_false                           |
    | description                           | None                                 |
    | availability_zone                     | None                                 |
    | share_network_id                      | None                                 |
    | share_group_id                        | None                                 |
    | revert_to_snapshot_support            | False                                |
    | access_rules_status                   | active                               |
    | snapshot_id                           | None                                 |
    | create_share_from_snapshot_support    | True                                 |
    | is_public                             | False                                |
    | task_state                            | None                                 |
    | snapshot_support                      | True                                 |
    | id                                    | 4d3d7fcf-5fb7-4209-90eb-9e064659f46d |
    | size                                  | 1                                    |
    | source_share_group_snapshot_member_id | None                                 |
    | user_id                               | 5c7bdb6eb0504d54a619acf8375c08ce     |
    | name                                  | software_share                       |
    | share_type                            | 1cf5d45a-61b3-44d1-8ec7-89a21f51a4d4 |
    | has_replicas                          | False                                |
    | replication_type                      | None                                 |
    | created_at                            | 2018-10-09T21:25:40.000000           |
    | share_proto                           | NFS                                  |
    | mount_snapshot_support                | False                                |
    | project_id                            | cadd7139bc3148b8973df097c0911016     |
    | metadata                              | {}                                   |
    +---------------------------------------+--------------------------------------+
  11. 공유가 성공적으로 생성되었는지 확인합니다.

    clouduser1@client:~$ manila list
    +--------------------------------------+----------------+------+-------------+-----------+-----------+-----------------+------+-------------------+
    | ID                                   | Name           | Size | Share Proto | Status    | Is Public | Share Type Name | Host | Availability Zone |
    +--------------------------------------+----------------+------+-------------+-----------+-----------+-----------------+------+-------------------+
    | 4d3d7fcf-5fb7-4209-90eb-9e064659f46d | software_share | 1    | NFS         | available | False     | dhss_false      |      | nova              |
    | 2d03d480-7cba-4122-ac9d-edc59c8df698 | software_share | 1    | NFS         | error     | False     | dhss_false      |      | nova              |
    | 243f3a51-0624-4bdd-950e-7ed190b53b67 | software_share | 1    | NFS         | error     | False     | dhss_true       |      | None              |
    +--------------------------------------+----------------+------+-------------+-----------+-----------+-----------------+------+-------------------+
  12. 공유 및 지원 메시지를 삭제합니다.

    clouduser1@client:~$ manila message-list
    +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
    | ID                                   | Resource Type | Resource ID                          | Action ID | User Message                                                                                             | Detail ID | Created At                 |
    +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
    | ed7e02a2-0cdb-4ff9-b64f-e4d2ec1ef069 | SHARE         | 2d03d480-7cba-4122-ac9d-edc59c8df698 | 002       | create: Driver does not expect share-network to be provided with current configuration.                  | 003       | 2018-10-09T21:24:40.000000 |
    | 7d411c3c-46d9-433f-9e21-c04ca30b209c | SHARE         | 243f3a51-0624-4bdd-950e-7ed190b53b67 | 001       | allocate host: No storage could be allocated for this share request, Capabilities filter didn't succeed. | 008       | 2018-10-09T21:12:21.000000 |
    +--------------------------------------+---------------+--------------------------------------+-----------+----------------------------------------------------------------------------------------------------------+-----------+----------------------------+
    
    clouduser1@client:~$ manila delete 2d03d480-7cba-4122-ac9d-edc59c8df698 243f3a51-0624-4bdd-950e-7ed190b53b67
    clouduser1@client:~$ manila message-delete ed7e02a2-0cdb-4ff9-b64f-e4d2ec1ef069 7d411c3c-46d9-433f-9e21-c04ca30b209c
    
    clouduser1@client:~$ manila message-list
    +----+---------------+-------------+-----------+--------------+-----------+------------+
    | ID | Resource Type | Resource ID | Action ID | User Message | Detail ID | Created At |
    +----+---------------+-------------+-----------+--------------+-----------+------------+
    +----+---------------+-------------+-----------+--------------+-----------+------------+

6.9.2. 공유 마운트 오류 디버깅

공유를 마운트할 때 문제가 발생하는 경우 다음 확인 단계를 사용하여 문제의 근본 원인을 확인합니다.

절차

  1. 공유에 대한 액세스 제어 목록이 올바른지 확인하여 클라이언트에 해당하는 규칙이 올바르고 성공적으로 적용되었는지 확인합니다.

    $ manila access-list share-01

    성공적인 규칙에서는 state 속성이 active 와 동일합니다.

  2. share type 매개변수가 driver_handles_share_servers=False 로 구성된 경우 내보내기 위치에서 호스트 이름 또는 IP 주소를 복사하고 ping하여 NAS 서버에 대한 연결을 확인합니다.

    # ping -c 1 172.17.5.13
    PING 172.17.5.13 (172.17.5.13) 56(84) bytes of data.
    64 bytes from 172.17.5.13: icmp_seq=1 ttl=64 time=0.048 ms--- 172.17.5.13 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 7.851/7.851/7.851/0.000 ms
    If using the NFS protocol, you may verify that the NFS server is ready to respond to NFS rpcs on the proper port:
    # rpcinfo -T tcp -a 172.17.5.13.8.1 100003 4
    program 100003 version 4 ready and waiting
    참고

    IP 주소는 NFS 서비스 포트 2049를 나타내는 두 개의 8진수(8.1)를 추가하는 범용 주소 형식(uaddr)으로 작성됩니다.

이러한 확인 단계가 실패하면 네트워크 연결 문제가 있거나 공유 파일 시스템 백엔드 스토리지에 실패할 수 있습니다. 로그를 수집하고 Red Hat 지원에 문의하십시오.