스토리지 가이드


Red Hat OpenStack Platform 8

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

OpenStack Documentation Team

초록

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

머리말

Red Hat OpenStack Platform(Red Hat OpenStack Platform)은 Red Hat Enterprise Linux를 기반으로 프라이빗 또는 퍼블릭 IaaS(Infrastructure-as-a-Service) 클라우드를 구축할 수 있는 기반을 제공합니다. 클라우드 지원 워크로드 개발을 위해 대규모 확장이 가능한 내결함성 플랫폼을 제공합니다.

이 가이드에서는 영구 스토리지를 생성하고 관리하는 절차에 대해 설명합니다. OpenStack 내에서 이 스토리지는 다음 세 가지 주요 서비스에서 제공합니다.

  • 블록 스토리지(openstack-cinder)
  • Object Storage(openstack-swift)
  • 공유 파일 시스템 스토리지(openstack-manila)는 현재 기술 프리뷰

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

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

참고

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

1장. OpenStack의 영구 스토리지 소개

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

반면 영구 스토리지는 실행 중인 인스턴스와 독립적으로 유지("persist")하도록 설계되었습니다. 이 스토리지는 다른 인스턴스에서 또는 특정 인스턴스의 수명 이상으로 재사용해야 하는 모든 데이터에 사용됩니다. OpenStack에서는 다음과 같은 유형의 영구 스토리지를 사용합니다.

volumes

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

볼륨은 백업 및 스냅샷을 통해 고유한 중복 및 재해 복구 기능도 제공합니다. 또한 보안을 강화하기 위해 볼륨을 암호화할 수도 있습니다. 볼륨에 대한 자세한 내용은 2장. 블록 스토리지 및 볼륨 을 참조하십시오.

참고

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

컨테이너

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

볼륨의 콘텐츠에는 인스턴스를 통해서만 액세스할 수 있지만 컨테이너 내부의 오브젝트에는 Object Storage REST API를 통해 액세스할 수 있습니다. 따라서 오브젝트 스토리지 서비스는 클라우드 내의 거의 모든 서비스에서 리포지토리로 사용할 수 있습니다. 예를 들어 데이터 처리 서비스(openstack-sahara)는 Object Storage 서비스를 통해 모든 바이너리, 데이터 입력, 데이터 출력 및 템플릿을 직접 관리할 수 있습니다.

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

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

각 스토리지 유형은 특정 스토리지 요구 사항을 충족하도록 설계되었습니다. 컨테이너는 광범위한 액세스를 위해 설계되었으며 모든 스토리지 유형 중에서 가장 높은 처리량, 액세스 및 내결함성을 제공합니다. 컨테이너 사용은 서비스에 더 많이 사용됩니다.

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

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

1.1. 확장성 및 백엔드

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

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

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

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

1.2. 접근성 및 관리

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

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

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

1.3. 보안

블록 스토리지 서비스는 볼륨 암호화를 통해 기본 데이터 보안을 제공합니다. 이렇게 하면 정적 키를 통해 암호화할 볼륨 유형을 구성할 수 있습니다. 그런 다음 키가 구성된 볼륨 유형에서 생성된 모든 볼륨을 암호화하는 데 사용됩니다. 자세한 내용은 2.2.5절. “정적 키를 사용하여 볼륨 암호화”를 참조하십시오.

반면 오브젝트 및 컨테이너 보안은 서비스 및 노드 수준에서 구성됩니다. 오브젝트 스토리지 서비스는 컨테이너 및 오브젝트에 대한 기본 암호화를 제공하지 않습니다. 오히려 Object Storage 서비스는 클라우드 내에서 접근성을 우선시하며 오브젝트 데이터를 보호하기 위해 클라우드의 네트워크 보안에만 의존합니다.

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

1.4. 중복 및 재해 복구

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

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

마지막으로 블록 스토리지 서비스에는 볼륨 복제 기능도 있습니다. 이를 통해 서로 콘텐츠를 복제하도록 볼륨을 구성하여 기본 중복성을 제공할 수 있습니다.

참고

볼륨 복제는 특정 타사 백엔드와 해당 드라이버를 통해서만 사용할 수 있습니다.

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

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

2장. 블록 스토리지 및 볼륨

블록 스토리지 서비스(openstack-cinder)는 모든 볼륨의 관리, 보안, 스케줄링 및 전체 관리를 관리합니다. 볼륨은 컴퓨팅 인스턴스의 기본 영구 스토리지 형태로 사용됩니다.

2.1. 백엔드

기본적으로 블록 스토리지 서비스는 LVM 백엔드를 볼륨의 리포지토리로 사용합니다. 이 백엔드는 테스트 환경에 적합하지만 엔터프라이즈 환경에 더 강력한 백엔드를 배포하는 것이 좋습니다.

환경에 Red Hat OpenStack Platform을 배포할 때 director를 사용하여 다시 명령합니다. 이렇게 하면 블록 스토리지 서비스(및 확장별 백엔드)를 포함하여 각 서비스를 올바르게 구성하는 데 도움이 됩니다. director에는 여러 개의 통합 백엔드 구성도 있습니다.

Red Hat OpenStack Platform은 Red Hat Ceph 및 NFS를 블록 스토리지 백엔드로 지원합니다. 둘 중 하나를 배포하는 방법에 대한 자세한 내용은 Director 설치 및 사용을 참조하십시오. 특히 중요한 요인은 다음과 같습니다.

타사 스토리지 공급자

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

Fujitsu ETERNUS 는 백엔드로 지원되지만 아직 Director에 통합되지 않습니다. 사용자 지정(통합되지 않은) 백엔드를 배포하는 방법에 대한 자세한 내용은 사용자 정의 블록 스토리지 백엔드 배포 가이드를 참조하십시오.

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

2.2. 블록 스토리지 서비스 관리

다음 절차에서는 필요에 맞게 Block Storage 서비스를 구성하는 방법을 설명합니다. 이러한 모든 절차에는 관리자 권한이 필요합니다.

2.2.1. 볼륨 유형을 사용한 그룹 볼륨 설정

OpenStack을 사용하면 유형의 관련 설정을 적용할 수 있는 볼륨 유형을 만들 수 있습니다. 볼륨 생성(] 또는 그 이후에도 이러한 설정을 적용할 수 있습니다(xref:section-volume-retype[). 예를 들어 다음을 연결할 수 있습니다.

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

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

참고

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

2.2.1.1. 호스트 드라이버의 기능 나열

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

또는 Block Storage 호스트를 직접 쿼리하여 드라이버에서 지원하는 잘 정의된 표준 추가 사양을 확인할 수 있습니다. 블록 스토리지 서비스를 호스팅하는 노드에 (명령줄을 통해) 로그인하여 시작합니다. 다음은 다음과 같습니다.

# cinder service-list
Copy to Clipboard Toggle word wrap

이 명령은 각 블록 스토리지 서비스(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 ...
+------------------+---------------------------+------+---------
Copy to Clipboard Toggle word wrap

블록 스토리지 서비스의 드라이버 기능(및 차례로 지원되는 추가 사양)을 표시하려면 다음을 실행합니다.

# cinder get-capabilities VOLSVCHOST
Copy to Clipboard Toggle word wrap

여기서 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...
    +--------------------+------------------------------------------+
Copy to Clipboard Toggle word wrap

Backend 속성 열에는 설정할 수 있는 추가 사양 키 목록이 표시되지만 Value 열에는 유효한 해당 값에 대한 정보가 있습니다.

2.2.1.2. 볼륨 유형 생성 및 구성
  1. 대시보드에서 관리자 권한으로 Admin > Volumes > Volume Types 을 선택합니다.
  2. 볼륨 유형 만들기를 클릭합니다.
  3. 이름 필드에 볼륨 유형 이름을 입력합니다.
  4. 볼륨 유형 만들기를 클릭합니다. 새 유형이 Volume Types 테이블에 나타납니다.
  5. 볼륨 유형의 추가 사양 작업을 선택합니다.
  6. 생성 을 클릭하고 키와 값을 지정합니다. 키/값 쌍은 유효해야 합니다. 그러지 않으면 볼륨 생성 중 볼륨 유형을 지정하면 오류가 발생합니다.
  7. 생성을 클릭합니다. 이제 연결된 설정(키/값 쌍)이 Extra Specs 테이블에 표시됩니다.

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

참고

QOS 사양을 볼륨 유형에 연결할 수도 있습니다. 자세한 내용은 2.2.4.2절. “QOS 사양을 볼륨 유형과 연결” 을 참조하십시오.

2.2.1.3. 볼륨 유형 편집
  1. 대시보드에서 관리자 권한으로 Admin > Volumes > Volume Types 을 선택합니다.
  2. 볼륨 유형 표에서 볼륨 유형의 추가 사양 보기를 선택합니다.
  3. 이 페이지의 Extra Specs 표에서 다음을 수행할 수 있습니다.

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

볼륨 유형을 삭제하려면 Volume Types 테이블에서 해당 확인란을 선택하고 Delete Volume Types 을 클릭합니다.

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

기본적으로 모든 볼륨 유형은 모든 테넌트에 표시됩니다. 볼륨 유형 생성 중에 이 값을 재정의하고 비공개로 설정할 수 있습니다. 이렇게 하려면 유형의 Is_Public 플래그를 False 로 설정해야 합니다.

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

프라이빗 볼륨 유형을 생성하려면 다음을 실행합니다.

# cinder --os-volume-api-version 2 type-create --is-public false VTYPE
Copy to Clipboard Toggle word wrap

+ VTYPE 를 프라이빗 볼륨 유형의 이름으로 교체합니다.

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

# cinder --os-volume-api-version 2 type-list --all
Copy to Clipboard Toggle word wrap

이 명령은 공용 볼륨 유형과 프라이빗 볼륨 유형을 모두 나열하고 각 유형의 이름과 ID도 포함됩니다. 액세스를 제공하려면 볼륨 유형의 ID가 필요합니다.

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

# cinder --os-volume-api-version 2 type-access-add --volume-type VTYPEID --project-id TENANTID
Copy to Clipboard Toggle word wrap

다음과 같습니다.

  • VTYPEID 는 프라이빗 볼륨 유형의 ID입니다.
  • TENANTIDVTYPEID 에 대한 액세스 권한을 부여하는 프로젝트/테넌트의 ID입니다.

프라이빗 볼륨 유형에 액세스할 수 있는 테넌트를 보려면 다음을 실행합니다.

# cinder --os-volume-api-version 2 type-access-list --volume-type VTYPE
Copy to Clipboard Toggle word wrap

프라이빗 볼륨 유형의 액세스 목록에서 테넌트를 제거하려면 다음을 실행합니다.

# cinder --os-volume-api-version 2 type-access-remove --volume-type VTYPE --project-id TENANTID
Copy to Clipboard Toggle word wrap
참고

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

2.2.2. 블록 스토리지 서비스에 대한 내부 테넌트 생성 및 구성

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

내부 테넌트를 구성하려면 먼저 cinder-internal 이라는 일반 테넌트와 사용자를 만듭니다. 이렇게 하려면 컨트롤러 노드에 로그인하고 다음을 실행합니다.

# keystone tenant-create --name cinder-internal --enabled true --description "Block Storage Internal Tenant"
    +-------------+----------------------------------+
    |   Property  |              Value               |
    +-------------+----------------------------------+
    | description |  Block Storage Internal Tenant   |
    |   enabled   |               True               |
    |      id     | cb91e1fe446a45628bb2b139d7dccaef |
    |     name    |         cinder-internal          |
    +-------------+----------------------------------+
# keystone user-create --name cinder-internal
    +----------+----------------------------------+
    | Property |              Value               |
    +----------+----------------------------------+
    |  email   |                                  |
    | enabled  |               True               |
    |    id    | 84e9672c64f041d6bfa7a930f558d946 |
    |   name   |         cinder-internal          |
    | username |         cinder-internal          |
    +----------+----------------------------------+
Copy to Clipboard Toggle word wrap

테넌트 및 사용자를 생성하면 해당 ID가 표시됩니다. ID를 통해 테넌트와 사용자를 내부 테넌트로 모두 사용하도록 Block Storage 서비스를 구성합니다. 이렇게 하려면 각 블록 스토리지 노드에서 다음을 실행합니다.

# openstack-config --set /etc/cinder/cinder.conf DEFAULT cinder_internal_tenant_project_id TENANTID
# openstack-config --set /etc/cinder/cinder.conf DEFAULT cinder_internal_tenant_user_id USERID
Copy to Clipboard Toggle word wrap

TENANTIDUSERIDkeystone 을 통해 생성된 테넌트 및 사용자의 해당 ID로 바꿉니다. 예를 들어 위에서 제공한 ID를 사용할 수 있습니다.

# openstack-config --set /etc/cinder/cinder.conf DEFAULT cinder_internal_tenant_project_id cb91e1fe446a45628bb2b139d7dccaef
# openstack-config --set /etc/cinder/cinder.conf DEFAULT cinder_internal_tenant_user_id 84e9672c64f041d6bfa7a930f558d946
Copy to Clipboard Toggle word wrap

2.2.3. 이미지 볼륨 캐시 구성 및 활성화

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

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

Image-Volume 캐시는 여러 백엔드에서 지원합니다. 타사 백엔드를 사용하는 경우 Image-Volume 캐시 지원에 대한 자세한 내용을 참조하십시오.

참고

Image-Volume 캐시를 사용하려면 블록 스토리지 서비스에 대해 내부 테넌트 를 구성해야 합니다. 자세한 내용은 2.2.2절. “블록 스토리지 서비스에 대한 내부 테넌트 생성 및 구성”에서 참조하십시오.

블록 스토리지 노드에서 Image-Volume 캐시를 활성화하고 구성하려면 다음 명령을 실행합니다.

# openstack-config --set /etc/cinder/cinder.conf BACKEND image_volume_cache_enabled True
Copy to Clipboard Toggle word wrap

BACKEND 를 대상 백엔드의 이름(특히 volume_backend_name 값)으로 바꿉니다.

기본적으로 Image-Volume 캐시 크기는 백엔드에서만 제한됩니다. 최대 크기(MAXSIZE,GB)를 구성하려면 다음을 수행합니다.

# openstack-config --set /etc/cinder/cinder.conf BACKEND image_volume_cache_max_size_gb MAXSIZE
Copy to Clipboard Toggle word wrap

또는 최대 이미지 수(MAXNUMBER)를 설정할 수도 있습니다. 이렇게 하려면 다음을 수행합니다.

# openstack-config --set /etc/cinder/cinder.conf BACKEND image_volume_cache_max_count MAXNUMBER
Copy to Clipboard Toggle word wrap

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

Image-Volume 캐시를 구성한 후 Block Storage 서비스를 다시 시작합니다.

# openstack-service restart cinder
Copy to Clipboard Toggle word wrap

2.2.4. QoS (Quality-of-Service Specifications) 사용

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

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

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

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

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

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

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

    Expand
    표 2.1. 소비자 유형
    유형설명

    백엔드

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

    프론트 엔드

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

    둘 다

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

  5. 생성을 클릭합니다. 이제 새로운 QOS Specs 테이블이 QOS Specs 테이블에 나타납니다.
  6. QOS Specs 표에서 새 사양의 Specs 작업 관리를 선택합니다.
  7. 생성 을 클릭하고 키와 값을 지정합니다. 키/값 쌍은 유효해야 합니다. 그러지 않으면 볼륨 생성 중에 이 QOS 사양과 연결된 볼륨 유형을 지정할 수 없습니다.
  8. 생성을 클릭합니다. 이제 연결된 설정(키/값 쌍)이 키-값 쌍 테이블에 표시됩니다.
2.2.4.2. QOS 사양을 볼륨 유형과 연결

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

  1. 대시보드의 관리자로 관리자 > 볼륨 > 볼륨 유형을 선택합니다.
  2. 볼륨 유형 테이블에서 QOS 사양 연결 관리 작업을 선택합니다.
  3. QOS 사양을 연결할 QOS 사양에서 QOS 사양을 선택합니다.
  4. 연결을 클릭합니다. 선택한 QOS Spec가 편집된 볼륨 유형의 Associated QOS Spec 열에 표시됩니다.
2.2.4.3. 볼륨 유형에서 QOS 사양의 연결 해제
  1. 대시보드의 관리자로 관리자 > 볼륨 > 볼륨 유형을 선택합니다.
  2. 볼륨 유형 테이블에서 QOS 사양 연결 관리 작업을 선택합니다.
  3. QOS Spec to be associated 목록에서 None 을 선택합니다.
  4. 연결을 클릭합니다. 선택한 QOS Spec는 편집된 볼륨 유형의 Associated QOS Spec 열에 더 이상 없습니다.

2.2.5. 정적 키를 사용하여 볼륨 암호화

볼륨 암호화는 볼륨 백엔드가 손상되었거나 완전히 도난당하는 경우 기본 데이터 보호를 제공하는 데 도움이 됩니다. 암호화된 볼륨의 내용은 특정 키를 사용하여만 읽을 수 있습니다. 인스턴스가 암호화된 볼륨을 사용하려면 Compute 및 Block Storage 서비스를 모두 구성해야 합니다. 암호화를 사용하는 특정 볼륨 유형을 생성할 수도 있으며 이 볼륨 유형을 사용하여 생성된 모든 볼륨이 암호화됩니다.

이 섹션에서는 볼륨을 암호화하는 데 단일 키를 사용하도록 OpenStack 배포를 구성하는 방법을 설명합니다.

중요

현재 볼륨 암호화는 블록 장치에서 지원하는 볼륨에서만 지원됩니다. RBD와 같은 네트워크 연결 볼륨 또는 파일 기반 볼륨(예: NFS)의 암호화는 여전히 지원되지 않습니다.

2.2.5.1. 정적 키 구성

기본 볼륨 암호화를 구현하는 첫 번째 단계는 정적 키를 설정하는 것입니다. 이 키는 블록 스토리지 볼륨 서비스(즉, openstack-cinder-volume) 및 모든 Compute 서비스(openstack-nova-compute)에서 사용할 16진수 문자열이어야 합니다. 이 키를 사용하도록 두 서비스를 모두 구성하려면 두 서비스의 해당 구성 파일의 [keymgr] 섹션에서 키를 fixed_key 값으로 설정합니다.

  1. 명령줄에서 rootopenstack-cinder-volume 을 호스팅하는 노드에 로그인합니다.
  2. 정적 키를 설정합니다.

    # openstack-config --set /etc/cinder/cinder.conf keymgr fixed_key HEX_KEY
    Copy to Clipboard Toggle word wrap

    HEX_KEY 를 16자리 영숫자 16진수 키(예: 04d6b077d60e323711b37813b3a68a71)로 바꿉니다.

    openssl 명령을 사용하여 다음과 같이 키를 생성할 수 있습니다.

    # openssl rand -hex 16
    04d6b077d60e323711b37813b3a68a71
    Copy to Clipboard Toggle word wrap
    참고

    이 값은 안전해야 합니다.

  3. 블록 스토리지 볼륨 서비스를 다시 시작합니다.

    # openstack-service restart cinder-volume
    Copy to Clipboard Toggle word wrap
  4. openstack-nova-compute 를 호스팅하는 노드에 로그인하고 동일한 정적 키를 설정합니다.

    # openstack-config --set /etc/nova/nova.conf keymgr fixed_key HEX_KEY
    Copy to Clipboard Toggle word wrap
    참고

    컴퓨팅 노드( openstack-nova-compute를 호스팅하는 여러 노드)가 있는 경우 각 노드의 /etc/nova/nova.conf 에 동일한 정적 키를 설정해야 합니다.

  5. Compute 서비스를 다시 시작하십시오.

    # openstack-service restart nova-compute
    Copy to Clipboard Toggle word wrap
    참고

    마찬가지로 여러 컴퓨팅 노드에 정적 키를 설정하는 경우 각 노드에서 openstack-nova-compute 서비스를 다시 시작해야 합니다.

이 시점에서 Compute 및 Block Storage 볼륨 서비스 둘 다 동일한 정적 키를 사용하여 볼륨을 암호화/암호화할 수 있습니다. 즉, 새 인스턴스는 정적 키(HEX_KEY)로 암호화된 볼륨을 사용할 수 있습니다.

2.2.5.2. 볼륨 유형 암호화 구성

2.2.5.1절. “정적 키 구성” 에서 정적 키로 암호화된 볼륨을 생성하려면 암호화된 볼륨 유형이 필요합니다. 암호화된 볼륨 유형을 구성하려면 사용해야 하는 공급자 클래스, 암호 및 키 크기를 설정해야 합니다. 이렇게 하려면 다음을 실행합니다.

# cinder encryption-type-create --cipher aes-xts-plain64 --key_size BITSIZE --control_location front-end VOLTYPE nova.volume.encryptors.luks.LuksEncryptor
Copy to Clipboard Toggle word wrap

다음과 같습니다.

  • BITSIZE 는 키 크기(예: 512비트 키의 경우 512 비트)입니다.
  • VOLTYPE 은 암호화할 볼륨 유형의 이름입니다.

이 명령은 nova.volume.encryptors.luks.LuksEncryptor 공급자 클래스와 aes-xts-plain64 암호를 설정합니다. 이번 릴리스에서는 볼륨 암호화에 지원되는 유일한 클래스/시피어 구성입니다.

암호화된 볼륨 유형이 있으면 이를 호출하여 암호화된 볼륨을 자동으로 생성할 수 있습니다. 볼륨 유형 생성에 대한 자세한 내용은 ]을 참조하십시오. 특히 볼륨 생성 창의 유형 드롭다운 목록에서 암호화된 볼륨 유형을 선택합니다(xref:section-volumes_basic[참조).

Project > Compute > Volumes.에 있는 볼륨의 암호화된 볼륨에서 를 클릭하여 암호화에 대한 메타데이터를 볼 수 있습니다.

2.2.6. 볼륨을 여러 백엔드에 할당하는 방법 구성

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

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

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

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

필터 스케줄러를 구성하려면 다음을 수행합니다.

  1. FilterScheduler 를 활성화합니다.

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_driver cinder.scheduler.filter_scheduler.FilterScheduler
    Copy to Clipboard Toggle word wrap
  2. 활성화할 필터를 설정합니다.

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_default_filters AvailabilityZoneFilter,CapacityFilter,CapabilitiesFilter
    Copy to Clipboard Toggle word wrap
  3. 스케줄러에서 적절한 백엔드를 선택하는 방법을 구성합니다. 스케줄러를 원하는 경우:

    • 항상 사용 가능한 가장 많은 여유 공간이 있는 백엔드를 선택하려면 다음을 실행합니다.

      # openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_default_weighers AllocatedCapacityWeigher
      # openstack-config --set /etc/cinder/cinder.conf DEFAULT allocated_capacity_weight_multiplier -1.0
      Copy to Clipboard Toggle word wrap
    • 모든 적합한 백엔드 중에서 임의로 선택하려면 다음을 실행합니다.

      # openstack-config --set /etc/cinder/cinder.conf DEFAULT scheduler_default_weighers ChanceWeigher
      Copy to Clipboard Toggle word wrap
  4. Block Storage 스케줄러를 다시 시작하여 설정을 적용합니다.

    # openstack-service restart openstack-cinder-scheduler
    Copy to Clipboard Toggle word wrap

2.2.7. 백업 관리

다음 섹션에서는 블록 스토리지 서비스의 볼륨 백업 설정을 사용자 지정하는 방법을 설명합니다.

2.2.7.1. 테넌트의 Backup Quota 보기 및 수정

대부분의 테넌트 스토리지 할당량(볼륨, 볼륨 스토리지, 스냅샷 등)과 달리 백업 할당량은 아직 대시보드를 통해 수정할 수 없습니다.

백업 할당량은 명령줄 인터페이스를 통해서만 수정할 수 있습니다. 즉 cinder quota-update 명령을 통해 수정할 수 있습니다.

특정 테넌트(TENANTNAME)의 스토리지 할당량을 보려면 다음을 실행합니다.

# cinder quota-show TENANTNAME
Copy to Clipboard Toggle word wrap

특정 테넌트에서 만들 수 있는 최대 백업 수(MAXNUM)를 업데이트하려면 다음을 실행합니다.

# cinder quota-update --backups MAXNUM TENANTNAME
Copy to Clipboard Toggle word wrap

특정 테넌트 내에서 모든 백업의 최대 총 크기(MAXGB)를 업데이트하려면 다음을 실행합니다.

# cinder quota-update --backup-gigabytes MAXGB TENANTNAME
Copy to Clipboard Toggle word wrap

특정 테넌트의 스토리지 할당량 사용량을 보려면 다음을 실행합니다.

# cinder quota-usage TENANTNAME
Copy to Clipboard Toggle word wrap
2.2.7.2. 대시보드를 통해 볼륨 백업 관리 활성화

대시보드를 통해 볼륨 백업을 생성, 보기, 삭제 및 복원할 수 있습니다. 이러한 기능을 수행하려면 Project > Compute > Volumes > Volume Backups 탭으로 이동합니다.

그러나 볼륨 백업 탭은 기본적으로 활성화되어 있지 않습니다. 이를 활성화하려면 그에 따라 대시보드를 구성합니다.

  1. /etc/openstack-dashboard/local_settings 를 엽니다.
  2. 다음 설정을 검색합니다.

    OPENSTACK_CINDER_FEATURES = {
        'enable_backup': False,
    }
    Copy to Clipboard Toggle word wrap

    이 설정을 다음과 같이 변경합니다.

    OPENSTACK_CINDER_FEATURES = {
        'enable_backup': True,
    }
    Copy to Clipboard Toggle word wrap
  3. httpd 서비스를 다시 시작하여 대시보드를 다시 시작합니다.

    # systemctl restart httpd.service
    Copy to Clipboard Toggle word wrap
2.2.7.3. NFS 공유를 백업 리포지토리로 설정

기본적으로 블록 스토리지 서비스는 Object Storage 서비스를 백업용 리포지토리로 사용합니다. 대신 기존 NFS 공유를 백업 리포지토리로 사용하도록 Block Storage 서비스를 구성할 수 있습니다. 이렇게 하려면 다음을 수행합니다.

  1. 백업 서비스(openstack-cinder-backup)를 관리 권한이 있는 사용자로 호스팅하는 노드에 로그인합니다.
  2. NFS 백업 드라이버(cinder.backup.drivers.nfs)를 사용하도록 블록 스토리지 서비스를 구성합니다.

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_driver cinder.backup.drivers.nfs
    Copy to Clipboard Toggle word wrap
  3. 백업 리포지토리로 사용할 NFS 공유의 세부 정보를 설정합니다.

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_share NFSHOST:PATH
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    • NFSHOST 는 NFS 서버의 IP 주소 또는 호스트 이름입니다.
    • PATHNFSHOST 의 NFS 공유의 절대 경로입니다.
  4. NFS 공유에 대한 선택적 마운트 설정을 설정하려면 다음을 실행합니다.

    # openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_mount_options NFSMOUNTOPTS
    Copy to Clipboard Toggle word wrap

    여기서 NFSMOUNTOPTS 는 쉼표로 구분된 NFS 마운트 옵션 목록입니다(예: rw,sync). 지원되는 마운트 옵션에 대한 자세한 내용은 nfsmount도움말 페이지를 참조하십시오.

  5. 블록 스토리지 백업 서비스를 다시 시작하여 변경 사항을 적용합니다.

    # systemctl restart openstack-cinder-backup.service
    Copy to Clipboard Toggle word wrap
2.2.7.3.1. 다른 백업 파일 크기 설정

백업 서비스는 백업 파일 크기를 최대 백업 파일 크기로 제한합니다. 이 크기를 초과하는 볼륨을 백업하는 경우 결과 백업은 여러 청크로 나뉩니다. 기본 백업 파일 크기는 1.8GB입니다.

다른 백업 파일 크기를 설정하려면 다음을 실행합니다.

# openstack-config --set /etc/cinder/cinder.conf DEFAULT backup_file_size SIZE
Copy to Clipboard Toggle word wrap

SIZE 를 원하는 파일 크기(바이트)로 바꿉니다. 블록 스토리지 백업 서비스를 다시 시작하여 변경 사항을 적용합니다.

# systemctl restart openstack-cinder-backup.service
Copy to Clipboard Toggle word wrap

2.3. 기본 볼륨 사용량 및 구성

다음 절차에서는 기본 최종 사용자 볼륨 관리를 수행하는 방법을 설명합니다. 이러한 절차에는 관리 권한이 필요하지 않습니다.

2.3.1. 볼륨 생성

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

    Expand
    필드설명

    볼륨 이름

    볼륨 이름입니다.

    설명

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

    유형

    선택적 볼륨 유형( 2.2.1절. “볼륨 유형을 사용한 그룹 볼륨 설정”참조).

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

    크기(GB)

    볼륨 크기(GB 단위).

    가용성 영역

    호스트 집계와 함께 가용 영역(논리적 서버 그룹)은 OpenStack 내의 리소스를 분리하는 일반적인 방법입니다. 가용성 영역은 설치 중에 정의됩니다. 가용성 영역 및 호스트 집계에 대한 자세한 내용은 Red Hat OpenStack Platform 에서 사용 가능한 인스턴스 및 이미지 가이드 의 호스트 집계 관리를 참조하십시오.

  3. 볼륨 소스 지정:

    Expand
    소스설명

    소스 없음, 빈 볼륨

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

    스냅샷

    기존 스냅샷을 볼륨 소스로 사용합니다. 이 옵션을 선택하면 새 Use snapshot as a source list가 표시됩니다. 그런 다음 목록에서 스냅샷을 선택할 수 있습니다. 볼륨 스냅샷에 대한 자세한 내용은 2.3.8절. “볼륨 스냅샷 생성, 사용 또는 삭제” 을 참조하십시오.

    이미지

    기존 이미지를 볼륨 소스로 사용합니다. 이 옵션을 선택하면 새 Use image as a source list가 표시됩니다. 그런 다음 목록에서 이미지를 선택할 수 있습니다.

    volume

    기존 볼륨을 볼륨 소스로 사용합니다. 이 옵션을 선택하면 새 Use volume as a source list가 표시됩니다. 그런 다음 목록에서 볼륨을 선택할 수 있습니다.

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

나중에 볼륨의 유형을 변경할 수도 있습니다. 자세한 내용은 2.3.10절. “볼륨 유형 변경 (Volume Retyping)”의 내용을 참조하십시오.

2.3.2. 볼륨 생성에 백엔드 지정

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

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

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

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

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

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

2.3.4. 볼륨 삭제

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

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

2.3.5. 인스턴스에 볼륨 연결 및 분리

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

2.3.5.1. 인스턴스에 볼륨 연결
  1. 대시보드에서 Project > Compute > Volumes를 선택합니다.
  2. 볼륨의 파일 편집 작업을 선택합니다. 볼륨이 인스턴스에 연결되어 있지 않으면 Attach to Instance(인스턴스에 연결) 드롭다운 목록이 표시됩니다.
  3. Attach to Instance(인스턴스에 연결) 목록에서 볼륨을 연결할 인스턴스를 선택합니다.
  4. 볼륨 연결을 클릭합니다.
2.3.5.2. 인스턴스에서 볼륨 분리
  1. 대시보드에서 Project > Compute > Volumes를 선택합니다.
  2. 볼륨의 첨부 파일 관리 작업을 선택합니다. 볼륨이 인스턴스에 연결되어 있으면 첨부 테이블에 인스턴스 이름이 표시됩니다.
  3. 이 경우 Detach Volume (볼륨 분리)과 다음 대화 상자 화면을 클릭합니다.

2.3.6. 볼륨을 읽기 전용으로 설정

콘텐츠를 편집하도록 허용하지 않고 여러 사용자에게 단일 볼륨에 대한 공유 액세스 권한을 부여할 수 있습니다. 이렇게 하려면 다음 명령을 사용하여 볼륨을 읽기 전용 으로 설정합니다.

# cinder readonly-mode-update VOLUME true
Copy to Clipboard Toggle word wrap

VOLUME 을 대상 볼륨의 ID 로 바꿉니다.

읽기 전용 볼륨을 다시 읽기-쓰기로 설정하려면 다음을 실행합니다.

# cinder readonly-mode-update VOLUME false
Copy to Clipboard Toggle word wrap

2.3.7. 볼륨 소유자 변경

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

2.3.7.1. 명령줄에서 볼륨 전송
  1. 볼륨의 현재 소유자로 로그인합니다.
  2. 사용 가능한 볼륨을 나열합니다.

    # cinder list
    Copy to Clipboard Toggle word wrap
  3. 볼륨 전송을 시작합니다.

    # cinder transfer-create VOLUME
    Copy to Clipboard Toggle word wrap

    여기서 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 |
      +------------+--------------------------------------+
    Copy to Clipboard Toggle word wrap

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

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

    # cinder transfer-accept TRANSFERID TRANSFERKEY
    Copy to Clipboard Toggle word wrap

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

    # cinder transfer-accept 3f5dc551-c675-4205-a13a-d30f88527490 f03bf51ce7ead189
    Copy to Clipboard Toggle word wrap
참고

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

# cinder transfer-list
Copy to Clipboard Toggle word wrap
2.3.7.2. 대시보드를 사용하여 볼륨 전송

대시보드에서 볼륨 전송 만들기

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

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

    참고

    권한 부여 키는 볼륨 전송 화면에서만 사용할 수 있습니다. 권한 키가 손실되면 전송을 취소하고 새 권한 부여 키를 생성하기 위해 다른 전송을 생성해야 합니다.

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

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

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

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

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

2.3.8. 볼륨 스냅샷 생성, 사용 또는 삭제

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

참고

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

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

볼륨 백업에 대한 자세한 내용은 다음을 참조하십시오. 2.4.1절. “볼륨 백업 및 복원”

볼륨 스냅샷을 생성하려면 다음을 수행합니다.

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

Volume Snapshots 테이블에 표시되면 스냅샷에서 새 볼륨을 복제할 수 있습니다. 이렇게 하려면 스냅샷의 Create Volume (볼륨 만들기) 작업을 선택합니다. 볼륨 생성에 대한 자세한 내용은 2.3.1절. “볼륨 생성” 을 참조하십시오.

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

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

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

Red Hat Ceph를 OpenStack 배포의 백엔드로 사용하는 경우 백엔드에서 보호 되도록 스냅샷을 설정할 수 있습니다. OpenStack을 통해 보호된 스냅샷(대시보드 또는 cinder snapshot-delete 명령을 통해)을 삭제하려고 하면 실패합니다.

이 경우 먼저 Red Hat Ceph 백엔드 에서 스냅샷의 보호 해제를 설정합니다. 이후 OpenStack을 통해 정상적으로 스냅샷을 삭제할 수 있습니다.

관련 지침은 스냅 샷 보호 및 스냅샷 보호 해제를 참조하십시오.

2.3.9. 이미지 서비스에 볼륨 업로드

기존 볼륨을 이미지 서비스에 직접 이미지로 업로드할 수 있습니다. 이렇게 하려면 다음을 수행합니다.

  1. 대시보드에서 Project > Compute > Volumes를 선택합니다.
  2. 대상 볼륨의 이미지 업로드 작업을 선택합니다.
  3. 볼륨의 이미지 이름을 제공하고 목록에서 디스크 형식을 선택합니다.
  4. 업로드를 클릭합니다. QEMU 디스크 이미지 유틸리티는 사용자가 제공한 이름을 사용하여 선택한 형식의 새 이미지를 업로드합니다.

업로드된 이미지를 보려면 프로젝트 > 컴퓨팅 > 이미지를 선택합니다. 새 이미지가 Images 테이블에 나타납니다. 이미지를 사용하고 구성하는 방법에 대한 자세한 내용은 Red Hat OpenStack Platform 에서 인스턴스 및 이미지 가이드 의 이미지 관리를 참조하십시오.

2.3.10. 볼륨 유형 변경 (Volume Retyping)

볼륨 재타이핑은 볼륨 유형(및 차례로 해당 설정)을 기존 볼륨에 적용하는 프로세스입니다. 볼륨 유형에 대한 자세한 내용은 2.2.1절. “볼륨 유형을 사용한 그룹 볼륨 설정” 을 참조하십시오.

기존 볼륨 유형이 있는지 여부에 관계없이 볼륨을 다시 입력할 수 있습니다. 두 경우 모두 볼륨 유형의 Extra Specs를 볼륨에 적용할 수 있는 경우에만 다시 유형이 수행됩니다. 볼륨 재 타이핑은 다음과 같이 기존 볼륨에 사전 정의된 설정 또는 스토리지 속성을 적용하는 데 유용합니다.

관리자 권한이 없는 사용자는 소유한 볼륨만 다시 입력할 수 있습니다. 볼륨 재유형을 수행하려면 다음을 수행합니다.

  1. 대시보드에서 Project > Compute > Volumes를 선택합니다.
  2. 마이그레이션할 볼륨의 Actions 열에서 Change Volume Type 을 선택합니다.
  3. 볼륨 유형 변경 대화 상자에서 유형 드롭다운 목록에서 새 백엔드를 정의하는 대상 볼륨 유형을 선택합니다.

    참고

    볼륨을 다른 백엔드로 마이그레이션하는 경우 마이그레이션 정책 드롭다운 목록에서 On Demand 를 선택합니다. 자세한 내용은 2.4.2.1절. “백엔드 간 마이그레이션”의 내용을 참조하십시오.

  4. 볼륨 유형 변경을 클릭하여 마이그레이션을 시작합니다.

2.4. 고급 볼륨 구성

다음 절차에서는 고급 볼륨 관리 절차를 수행하는 방법을 설명합니다.

2.4.1. 볼륨 백업 및 복원

볼륨 백업은 볼륨 콘텐츠의 영구 사본입니다. 볼륨 백업은 일반적으로 오브젝트 저장소로 생성되며 기본적으로 Object Storage 서비스를 통해 관리됩니다. 그러나 백업에 대해 다른 리포지토리를 설정할 수 있습니다. OpenStack은 백업의 대체 백엔드로 Red Hat Ceph 및 NFS를 지원합니다.

볼륨 백업을 생성할 때 백업의 모든 메타데이터는 블록 스토리지 서비스의 데이터베이스에 저장됩니다. cinder 유틸리티는 백업에서 볼륨을 복원할 때 이 메타데이터를 사용합니다. 따라서 치명적인 데이터베이스 손실에서 복구할 때 백업에서 볼륨을 복원하기 전에 Block Storage 서비스의 데이터베이스를 먼저 복원해야 합니다. 또한 블록 스토리지 서비스 데이터베이스가 그대로 모든 원본 볼륨 백업 메타데이터로 복원되고 있다고 가정합니다.

치명적인 데이터베이스 손실 후에도 유지되도록 볼륨 백업 서브 세트만 구성하려면 백업의 메타데이터를 내보낼 수도 있습니다. 그런 다음 나중에 블록 스토리지 데이터베이스로 메타데이터를 다시 가져오고 볼륨 백업을 정상적으로 복원할 수 있습니다.

참고

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

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

볼륨 스냅샷에 대한 자세한 내용은 2.3.8절. “볼륨 스냅샷 생성, 사용 또는 삭제” 을 참조하십시오.

2.4.1.1. 전체 볼륨 백업 생성

볼륨을 백업하려면 cinder backup-create 명령을 사용합니다. 기본적으로 이 명령은 볼륨의 전체 백업을 생성합니다. 볼륨에 기존 백업이 있는 경우 대신 증분 백업을 생성하도록 선택할 수 있습니다(자세한 내용은 2.4.1.2절. “증분 볼륨 백업 생성” 참조).

액세스할 수 있는 볼륨 백업을 생성할 수 있습니다. 즉, 관리자 권한이 있는 사용자는 소유자와 관계없이 모든 볼륨을 백업할 수 있습니다. 자세한 내용은 2.4.1.1.1절. “관리자로 볼륨 백업 생성”의 내용을 참조하십시오.

  1. 백업할 볼륨의 ID 또는 표시 이름을 확인합니다.

    # cinder list
    Copy to Clipboard Toggle word wrap
  2. 볼륨을 백업합니다.

    # cinder backup-create VOLUME
    Copy to Clipboard Toggle word wrap

    VOLUME 을 백업하려는 볼륨의 ID 또는 Display Name 으로 바꿉니다. 예를 들면 다음과 같습니다.

      +-----------+--------------------------------------+
      |  Property |                Value                 |
      +-----------+--------------------------------------+
      |     id    | e9d15fc7-eeae-4ca4-aa72-d52536dc551d |
      |    name   |                 None                 |
      | volume_id | 5f75430a-abff-4cc7-b74e-f808234fa6c5 |
      +-----------+--------------------------------------+
    Copy to Clipboard Toggle word wrap
    참고

    결과 백업의 volume_id 는 소스 볼륨의 ID 와 동일합니다.

  3. 볼륨 백업 생성이 완료되었는지 확인합니다.

    # cinder backup-list
    Copy to Clipboard Toggle word wrap

    백업 항목의 Status사용할 수 있으면 볼륨 백업 생성이 완료됩니다.

이 시점에서 볼륨 백업의 메타데이터를 내보내고 저장할 수도 있습니다. 이를 통해 Block Storage 데이터베이스에 심각한 손실이 발생하더라도 볼륨 백업을 복원할 수 있습니다. 이렇게 하려면 다음을 실행합니다.

# cinder --os-volume-api-version 2 backup-export BACKUPID
Copy to Clipboard Toggle word wrap

여기서 CryostatID 는 볼륨 백업의 ID 또는 이름입니다. 예를 들면 다음과 같습니다.

+----------------+------------------------------------------+
|    Property    |                Value                     |
+----------------+------------------------------------------+
| backup_service |     cinder.backup.drivers.swift          |
|   backup_url   | eyJzdGF0dXMiOiAiYXZhaWxhYmxlIiwgIm9iam...|
|                | ...4NS02ZmY4MzBhZWYwNWUiLCAic2l6ZSI6IDF9 |
+----------------+------------------------------------------+
Copy to Clipboard Toggle word wrap

볼륨 백업 메타데이터는 backup_servicebackup_url 값으로 구성됩니다.

2.4.1.1.1. 관리자로 볼륨 백업 생성

관리 권한(예: 기본 관리자 계정)이 있는 사용자는 OpenStack에서 관리하는 모든 볼륨을 백업할 수 있습니다. 관리자가 관리자가 아닌 사용자가 소유한 볼륨을 백업하면 기본적으로 볼륨 소유자에서 백업이 숨겨집니다.

관리자는 여전히 볼륨을 백업 하고 특정 테넌트에서 백업을 사용할 수 있도록 할 수 있습니다. 이렇게 하려면 다음을 실행합니다.

# cinder --os-auth-url KEYSTONEURL --os-tenant-name TENANTNAME --os-username USERNAME --os-password PASSWD backup-create VOLUME
Copy to Clipboard Toggle word wrap

다음과 같습니다.

  • TENANTNAME 은 백업을 사용할 수 있도록 테넌트의 이름입니다.
  • USERNAMEPASSWDTENANTNAME 내에 있는 사용자의 사용자 이름/암호 자격 증명입니다.
  • VOLUME 은 백업하려는 볼륨의 이름 또는 ID입니다.
  • KEYSTONEURL 은 ID 서비스의 URL 끝점입니다(일반적으로 http://IP:5000/v2, 여기서 IP 는 ID 서비스 호스트의 IP 주소입니다).

이 작업을 수행할 때 결과 백업의 크기는 관리자 테넌트 대신 TENANTNAME 의 할당량에 따라 계산됩니다.

2.4.1.2. 증분 볼륨 백업 생성

기본적으로 cinder backup-create 명령은 볼륨의 전체 백업을 만듭니다. 그러나 볼륨에 기존 백업이 있는 경우 증분 백업을 생성하도록 선택할 수 있습니다.

증분 백업은 마지막 백업 이후의 볼륨 변경(전체 또는 증분)을 캡처합니다. 시간이 지남에 따라 볼륨의 크기가 증가함에 따라 볼륨의 크기가 많이 증가함에 따라 볼륨의 전체 백업을 수행해도 리소스가 많이 소요될 수 있습니다. 이와 관련하여 증분 백업을 사용하면 리소스 사용량을 최소화하면서 볼륨에 대한 정기적인 변경 사항을 캡처할 수 있습니다.

증분 볼륨 백업을 만들려면 --incremental 옵션을 사용합니다. 에서와 같이 :

# cinder backup-create VOLUME --incremental
Copy to Clipboard Toggle word wrap

VOLUME 을 백업하려는 볼륨의 ID 또는 Display Name 으로 바꿉니다. 증분 백업은 NFS 및 오브젝트 스토리지 백업 리포지토리에서 완전하게 지원됩니다.

참고

이미 증분 백업이 있는 경우 전체 백업을 삭제할 수 없습니다. 또한 전체 백업에 증분 백업이 여러 개 있는 경우 최신 백업만 삭제할 수 있습니다.In addition, if a full backup has multiple incremental backups, you can only delete the latest one.

주의

Red Hat Ceph Storage를 Block Storage(cinder) 볼륨 및 백업 모두에 대한 백엔드로 사용하는 경우 증분 백업을 수행하면 경고 없이 전체 백업이 수행됩니다. 알려진 문제입니다 (BZ#1463061).

2.4.1.3. 블록 스토리지 데이터베이스 손실 후 볼륨 복원

일반적으로 블록 스토리지 데이터베이스를 손실하면 볼륨 백업을 복원할 수 없습니다. 이는 Block Storage 데이터베이스에 볼륨 백업 서비스(openstack-cinder-backup)에 필요한 메타데이터가 포함되어 있기 때문입니다. 이 메타데이터는 볼륨 백업을 생성한 후 내보낼 수 있는 backup_servicebackup_url 값으로 구성됩니다( 2.4.1.1절. “전체 볼륨 백업 생성”에 표시됨).

이 메타데이터를 내보내고 저장한 경우 새 블록 스토리지 데이터베이스로 가져올 수 있습니다( 볼륨 백업을 복원할 수 있음).

  1. 관리 권한이 있는 사용자로 다음을 실행합니다.

    # cinder --os-volume-api-version 2 backup-import backup_service backup_url
    Copy to Clipboard Toggle word wrap

    여기서 backup_servicebackup_url 은 내보낸 메타데이터에서 가져온 것입니다. 예를 들어 2.4.1.1절. “전체 볼륨 백업 생성” 의 내보낸 메타데이터를 사용합니다.

    # cinder --os-volume-api-version 2 backup-import cinder.backup.drivers.swift eyJzdGF0dXMi...c2l6ZSI6IDF9
    +----------+--------------------------------------+
    | Property |                Value                 |
    +----------+--------------------------------------+
    |    id    | 77951e2f-4aff-4365-8c64-f833802eaa43 |
    |   name   |                 None                 |
    +----------+--------------------------------------+
    Copy to Clipboard Toggle word wrap
  2. 메타데이터를 블록 스토리지 서비스 데이터베이스로 가져온 후 볼륨을 정상적으로 복원할 수 있습니다( 2.4.1.4절. “백업에서 볼륨 복원”참조).
2.4.1.4. 백업에서 볼륨 복원
  1. 사용하려는 볼륨 백업의 ID 를 찾습니다.

    # cinder backup-list
    Copy to Clipboard Toggle word wrap

    볼륨 ID 는 복원하려는 볼륨의 ID와 일치해야 합니다.

  2. 볼륨 백업을 복원합니다.

    # cinder backup-restore BACKUP_ID
    Copy to Clipboard Toggle word wrap

    여기서 Cryostat_ ID는 사용하려는 볼륨 백업의 ID입니다.

  3. 더 이상 백업이 필요하지 않은 경우 삭제합니다.

    # cinder backup-delete BACKUP_ID
    Copy to Clipboard Toggle word wrap

2.4.2. 볼륨 마이그레이션

블록 스토리지 서비스를 사용하면 호스트 또는 백엔드 간에 볼륨을 마이그레이션할 수 있습니다. 현재 사용 중인 볼륨(인스턴스에 연결)을 마이그레이션할 수 있지만 스냅샷이 있는 볼륨은 마이그레이션할 수 없습니다.

호스트 간에 볼륨을 마이그레이션하는 경우 두 호스트 모두 동일한 백엔드에 있어야 합니다. 이렇게 하려면 다음을 수행합니다.

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

    참고

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

  4. 마이그레이션을 클릭하여 마이그레이션을 시작합니다.
2.4.2.1. 백엔드 간 마이그레이션

반면 백엔드 간에 볼륨을 마이그레이션하는 경우 볼륨 재연결이 필요합니다. 즉, 새 백엔드로 마이그레이션하려면 다음을 수행합니다.

  1. 새 백엔드를 별도의 대상 볼륨 유형에서 Extra Spec 로 지정해야 합니다.
  2. 대상 볼륨 유형에 정의된 기타 모든 추가 사양은 볼륨의 원래 볼륨 유형과 호환되어야 합니다.

자세한 내용은 ] 및 xref:section-specify-backend[ 를 참조하십시오.

백엔드를 Extra Spec로 정의할 때 volume_backend_nameKey 로 사용합니다. 해당 값은 블록 스토리지 구성 파일(/etc/cinder/cinder.conf)에 정의된 대로 백엔드의 이름이 됩니다. 이 파일에서 각 백엔드는 자체 섹션에 정의되어 있으며 해당 이름은 volume_backend_name 매개 변수에 설정됩니다.

대상 볼륨 유형에 백엔드가 정의되면 다시 타이핑 을 통해 볼륨을 해당 백엔드로 마이그레이션할 수 있습니다. 여기에는 대상 볼륨 유형을 볼륨에 다시 적용하여 새 백엔드 설정을 적용해야 합니다. 자세한 내용은 2.3.10절. “볼륨 유형 변경 (Volume Retyping)” 을 참조하십시오.

이렇게 하려면 다음을 수행합니다.

  1. 대시보드에서 Project > Compute > Volumes를 선택합니다.
  2. 마이그레이션할 볼륨의 Actions 열에서 Change Volume Type 을 선택합니다.
  3. 볼륨 유형 변경 대화 상자에서 유형 드롭다운 목록에서 새 백엔드를 정의하는 대상 볼륨 유형을 선택합니다.
  4. 마이그레이션 정책 드롭다운 목록에서 온 디맨드 를 선택합니다.
  5. 볼륨 유형 변경을 클릭하여 마이그레이션을 시작합니다.

3장. 오브젝트 스토리지 및 컨테이너

OpenStack Object Storage(openstack-swift)는 해당 오브젝트(데이터)를 컨테이너에 저장합니다. 이러한 오브젝트는 중첩될 수 없지만 파일 시스템의 디렉터리와 유사합니다. 컨테이너는 사용자가 모든 종류의 구조화되지 않은 데이터를 저장할 수 있는 쉬운 방법을 제공합니다. 예를 들어 오브젝트에는 사진, 텍스트 파일 또는 이미지가 포함될 수 있습니다. 저장된 오브젝트는 암호화되거나 압축되지 않습니다.

3.1. Object Storage 서비스 관리

다음 절차에서는 필요에 맞게 Object Storage 서비스를 추가로 사용자 지정하는 방법을 설명합니다.

3.1.1. 오브젝트 스토리지 서비스에 대한 삭제 코딩

삭제 코딩(EC)은 데이터가 조각으로 분할되고 중복된 데이터 조각으로 확장 및 인코딩되어 서로 다른 위치 또는 스토리지 미디어 세트에 저장되는 데이터 보호 방법입니다. 기존 복제보다 필요한 지속성을 얻기 위해 더 적은 양의 스토리지를 사용합니다. 복제 요인 3과 비교하면 신중하게 배포 시 50%의 비용 절감 효과를 얻을 수 있습니다. 그러나 워크로드에 따라 삭제 코딩으로 인해 성능이 저하될 수 있습니다.

Red Hat OpenStack Platform 8 릴리스에서는 삭제 코딩 지원이 오브젝트 스토리지 서비스의 기술 프리뷰로 제공됩니다. 기술 프리뷰로 표시된 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/ 을 참조하십시오.

오브젝트 스토리지 서비스에 대해 스토리지 정책으로 삭제 코딩이 지원됩니다. 스토리지 정책을 사용하면 여러 오브젝트 링을 생성하여 다양한 목적으로 클러스터를 분할할 수 있습니다. 삭제 코딩 및 복제 스토리지 정책에서 사용하는 장치를 분할하는 것이 좋습니다. 이렇게 하면 클러스터 동작을 더 쉽게 분석할 수 있습니다.

선택한 방향은 삭제 코딩 정책이 배포되는 이유에 따라 다릅니다. 몇 가지 고려 사항은 다음과 같습니다.

  • 기존 인프라의 레이아웃.
  • 전용 삭제 코딩 노드 추가 비용(또는 전용 삭제 코딩 장치만 해당).
  • 의도된 사용 모델.
3.1.1.1. Erasure Coding 구성

삭제 코딩 정책을 사용하려면 swift.conf 파일에 삭제 코딩 정책을 정의하고 관련 오브젝트 링을 구성합니다. 삭제 코딩 정책이 설정될 수 있는 방법의 예는 다음과 같습니다.

[storage-policy:2]
name = ec104
policy_type = erasure_coding
ec_type = jerasure_rs_vand
ec_num_data_fragments = 10
ec_num_parity_fragments = 4
ec_object_segment_size = 1048576
Copy to Clipboard Toggle word wrap

다음 표에서는 스토리지 정책의 용어를 설명합니다.

Expand
용어설명

name

이는 표준 스토리지 정책 매개변수입니다.

policy_type

이 값을 erasure_coding로 설정하여 삭제 코딩 정책임을 나타냅니다.

ec_type

선택한 PyECLib 백엔드에서 사용 가능한 옵션에 따라 이 값을 설정합니다. 사용할 삭제 코딩 체계를 지정합니다. 예를 들어 여기에 표시된 옵션은 Vandermonde Reed-Solomon 인코딩을 선택하는 반면 flat_xor_hd_3 옵션은 Flat-XOR 기반HD 조합 코드를 선택합니다. 자세한 내용은 PyECLib 페이지를 참조하십시오.

ec_num_data_fragments

데이터로 구성될 총 조각 수입니다.

ec_num_parity_fragments

패리티로 구성될 전체 조각 수입니다.

ec_object_segment_size

인코더/디코더에 세그먼트를 공급하기 전에 버퍼링될 데이터의 양입니다. 기본값은 1048576입니다.

PyECLib가 개체를 인코딩하면 N 조각으로 나눕니다. 구성 중에 데이터 조각의 수와 패리티 수를 아는 것이 중요합니다. 따라서 위의 예에서 PyECLib는 14개의 서로 다른 조각으로 개체를 분할하고, 그 중 10개는 실제 오브젝트 데이터로 구성되며, 4개는 패리티 데이터로 구성됩니다( ec_type에 따라 계산). 이러한 구성으로 시스템은 데이터가 손실되기 전에 4 개의 디스크 오류를 유지할 수 있습니다. 일반적으로 사용되는 다른 구성은 4+2(4개의 데이터 조각 및 2개 파트 조각 포함) 또는 8+3(데이터 조각 및 3 패리티 조각 포함)입니다.

참고

정책을 배포하고 해당 정책을 사용하여 오브젝트를 생성한 후에는 이러한 구성 옵션을 변경할 수 없습니다. 구성을 변경해야 하는 경우 새 정책을 생성하고 데이터를 새 컨테이너로 마이그레이션해야 합니다. 그러나 정책 인덱스가 정의되면 삭제할 수 없습니다. 정책을 종료해야 하는 경우 비활성화되지만 제거되지 않을 수 있습니다. 기존 정책에는 기본적으로 성능이 저하되지 않지만 약간의 관리 오버헤드가 있습니다.

3.1.1.2. 오브젝트 스토리지 링 구성

Object Storage는 Ring 이라는 데이터 구조를 사용하여 클러스터 전체에 파티션 공간을 배포합니다. 이 파티션 공간은 오브젝트 스토리지 서비스의 복제 시스템의 코어입니다. Object Storage 서비스를 사용하면 클러스터 전체에서 각 파티션을 빠르고 쉽게 동기화할 수 있습니다. Swift의 모든 구성 요소가 데이터와 상호 작용해야 하는 경우 각 복제본에 대해 사용 가능한 파티션을 확인하기 위해 Ring에서 빠른 조회가 로컬로 수행됩니다.

Object Storage 서비스에는 이미 다양한 유형의 데이터를 저장하는 세 개의 링이 있습니다. 계정 정보에는 컨테이너(계정 아래에 오브젝트를 구성하는 것이 편리합니다)와 오브젝트 복제본에 대한 다른 하나가 있습니다. 삭제 코드를 지원하기 위해 삭제 코드 청크를 저장하기 위해 생성된 추가 링이 있습니다.

예를 들어 일반적인 복제 링을 생성하려면 다음 명령을 사용합니다.

swift-ring-builder object-1.builder create 10 3 1
Copy to Clipboard Toggle word wrap

여기서 3은 복제본 수입니다.

삭제 코딩 오브젝트 링을 생성하려면 복제본 수 대신 조각 수를 사용해야 합니다. 예를 들면 다음과 같습니다.

swift-ring-builder object-1.builder create 10 14 1
Copy to Clipboard Toggle word wrap

여기서 14는 10개의 데이터 조각과 4 패리티 조각이 있는 10+4 구성을 위한 것입니다.

삭제 코딩 정책의 오브젝트 링에 사용할 장치를 결정할 때 성능에 미치는 영향을 고려하십시오. 배포 전에 구성을 위해 테스트 환경에서 일부 성능 벤치마킹을 실행하는 것이 좋습니다. swift.conf 에 삭제 코딩 정책을 구성하고 오브젝트 링을 생성한 후에는 지정된 정책 이름이 있는 컨테이너를 생성하고 정상적으로 상호 작용하여 애플리케이션이 삭제 코딩 사용을 시작할 수 있습니다.

3.1.2. 오브젝트 스토리지를 이미지 서비스의 백엔드로 설정

기본적으로 OpenStack 이미지 서비스는 이미지와 인스턴스 스냅샷을 /var/lib/glance/images/ 의 로컬 파일 시스템에 저장합니다. 또는 이미지 및 스냅샷을 오브젝트 스토리지 서비스(사용 가능한 경우)에 저장하도록 이미지 서비스를 구성할 수 있습니다.

이렇게 하려면 다음 절차를 수행합니다.

  1. 이미지 서비스(ID를 실행하는 컨트롤러 노드)를 실행하는 노드에 root로 로그인하고 OpenStack 인증 정보를 소싱합니다(일반적으로 openrc라는 파일임).

    # source ~/openrc
    Copy to Clipboard Toggle word wrap
  2. 이미지 서비스가 역할 admin 이 있는 테넌트 서비스 의 일부인지 확인합니다.

    # keystone user-role-list --user glance --tenant service
    Copy to Clipboard Toggle word wrap

    반환된 역할 중 하나는 admin 이어야 합니다.

  3. /etc/glance/glance.conf 파일을 열고 다음 행을 주석 처리합니다.

    ##### DEFAULT OPTIONS #####
    #default_store = file
    #filesystem_store_datadir = /var/lib/glance/images/
    Copy to Clipboard Toggle word wrap
  4. 동일한 파일에서 DEFAULT OPTIONS 섹션에 다음 행을 추가합니다.

    default_store = swift
    swift_store_auth_address = http://KEYSTONEIP:35357/v2.0/
    swift_store_user = service:glance
    swift_store_key = ADMINPW
    swift_store_create_container_on_put = True
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    • KEYSTONEIP 는 ID 서비스의 IP 주소이며,
    • ADMINPW/etc/glance/glance-api.conf 파일의 관리자 암호 속성 값입니다.
  5. 이미지 서비스를 다시 시작하여 변경 사항을 적용합니다.

    # systemctl restart openstack-glance-api
    # systemctl restart openstack-glance-registry
    Copy to Clipboard Toggle word wrap

이제 대시보드 또는 Glance를 통해 이미지 서비스에 업로드된 이미지를 glance 라는 오브젝트 스토리지 컨테이너에 저장해야 합니다. 이 컨테이너는 서비스 계정에 있습니다.

새로 생성된 이미지가 이미지 서비스에 저장되었는지 확인하려면 다음을 실행합니다.

# ls /var/lib/glance/images
Copy to Clipboard Toggle word wrap

대시보드 또는 glance image-list 에서 이미지가 활성 상태임을 보고하면 다음 명령을 실행하여 해당 이미지가 오브젝트 스토리지에 있는지 확인할 수 있습니다.

# swift --os-auth-url http://KEYSTONEIP:5000/v2.0 --os-tenant-name service --os-username glance --os-password ADMINPW list glance
Copy to Clipboard Toggle word wrap

3.2. 기본 컨테이너 관리

조직을 돕기 위해 의사 폴더는 오브젝트를 포함할 수 있는 논리 장치이며 중첩될 수 있습니다. 예를 들어, 이미지를 저장할 이미지 폴더를 생성할 수 있습니다. 이 폴더는 동영상 저장할 미디어 폴더입니다.

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

3.2.1. 컨테이너 생성

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

    Expand
    유형설명

    프라이빗

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

    퍼블릭

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

  4. 컨테이너 생성을 클릭합니다.

3.2.2. 컨테이너용 Pseudo 폴더 생성

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

3.2.3. 컨테이너 삭제

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

3.2.4. 오브젝트 업로드

실제 파일을 업로드하지 않으면 오브젝트는 여전히( 자리 표시자로) 생성되며 나중에 파일을 업로드하는 데 사용할 수 있습니다.

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

    • pseudo-folders는 / 문자(예: Images/myImage. Cryostat )를 사용하여 이름에 지정할 수 있습니다. 지정된 폴더가 없는 경우 오브젝트가 업로드될 때 생성됩니다.
    • 위치에 고유하지 않은 이름(즉, 오브젝트가 이미 존재하는 경우) 오브젝트의 콘텐츠를 덮어씁니다.
  5. 업로드를 클릭합니다.

3.2.5. 오브젝트 복사

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

    Expand
    필드설명

    대상 컨테이너

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

    경로

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

    대상 오브젝트 이름

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

  6. 개체 복사를 클릭합니다.

3.2.6. 오브젝트 삭제

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

4장. 파일 공유

중요

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

OpenStack의 공유 파일 시스템 서비스(openstack-manila)는 여러 인스턴스에서 사용할 수 있는 공유 파일 시스템을 쉽게 프로비저닝할 수 있는 수단을 제공합니다. 이전에는 OpenStack 사용자가 공유 파일 시스템을 수동으로 배포한 후 인스턴스에 마운트해야 했습니다. 반면 공유 파일 시스템 서비스를 사용하면 사전 구성된 스토리지 풀에서 공유를 쉽게 프로비저닝하여 안전하게 마운트할 수 있습니다. 이 풀은 필요에 따라 독립적으로 관리 및 확장할 수 있습니다.

OpenStack Shared File System 서비스를 사용하면 관리자가 OpenStack Block Storage 서비스에서 볼륨 유형을 사용하는 것과 동일한 방식으로 다양한 유형의 공유(즉, 공유 유형)에 대한 설정을 정의할 수 있습니다. 또한 공유 파일 시스템 서비스는 프로비저닝된 공유에 대한 액세스, 보안 및 스냅샷을 관리하는 수단도 제공합니다.

현재 공유 파일 시스템 서비스는 수동으로만 배포할 수 있습니다. 이를 수행하는 방법에 대한 자세한 내용은 공유 파일 시스템 서비스 설치(기술 프리뷰) 를 참조하십시오.

4.1. 공유 만들기 및 관리

이 섹션에서는 공유 파일 시스템 서비스 설치(기술 프리뷰) 및 OpenStack Shared File System Service(Manila) 에 설명된 대로 공유 파일 시스템 서비스를 수동으로 배포했다고 가정합니다. 따라서 이 시점에서 공유에는 NetApp 드라이버(manila.share.drivers.netapp.common.NetAppDriver)를 사용해야 합니다.

이 드라이버를 사용하면 다음 작업을 수행할 수 있습니다.

  • 공유를 만들고 삭제합니다.
  • 공유에 대한 액세스를 허용(읽기/쓰기)하거나 거부합니다.

공유를 만들기 전에 먼저 공유 유형을 생성해야 합니다. 일반적으로 이 단계는 정의된 백엔드에 대한 공유 유형 만들기에 설명된 대로 공유 파일 시스템 서비스 배포의 일부입니다.

다음 절차에서는 NetApp 백엔드가 있다고 가정합니다.

  • netapp이라는 공유 유형을 통해 호출할 수 있습니다.
  • NFS 공유 프로토콜을 지원합니다.

4.2. 공유 만들기

공유를 생성하려면 공유 파일 시스템 서비스 호스트에 로그인하고 다음을 실행합니다.

# manila create --share-type SHARETYPE --name SHARENAME PROTO GB
Copy to Clipboard Toggle word wrap

다음과 같습니다.

  • SHARETYPE 은 지정된 공유 유형과 연결된 설정을 적용합니다.
  • SHARENAME 은 공유의 이름입니다.
  • PROTO 는 사용하려는 공유 프로토콜입니다.
  • GB 는 공유 크기(GB)입니다.

예를 들어 netapp 백엔드를 사용하여 이름이 share-00인 1GB NFS 공유를 생성하려면 다음을 실행합니다.

# manila create --share-type netapp --name share-00 nfs 10
 +-------------------+--------------------------------------+
 | Property          | Value                                |
 +-------------------+--------------------------------------+
 | status            | creating                             |
 | description       | None                                 |
 | availability_zone | nova                                 |
 | share_network_id  | None                                 |
 | export_locations  | []                                   |
 | share_server_id   | None                                 |
 | host              | None                                 |
 | snapshot_id       | None                                 |
 | is_public         | False                                |
 | id                | d760eee8-1d91-48c4-8f9a-ad07072e17a2 |
 | size              | 10                                   |
 | name              | share-01                             |
 | share_type        | 8245657b-ab9e-4db1-8224-451c32d6b5ea |
 | created_at        | 2015-09-29T16:27:54.092272           |
 | export_location   | None                                 |
 | share_proto       | NFS                                  |
 | project_id        | a19dc7ec562c4ed48cea58d22eb0d3c7     |
 | metadata          | {}                                   |
 +-------------------+--------------------------------------+
Copy to Clipboard Toggle word wrap

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

공유가 생성되었는지 확인하려면 다음을 수행합니다.

# manila list
 +--------------------------------------+----------+-----+-----------+
 | ID                                   | Name     | ... | Status    ...
 +--------------------------------------+----------+-----+-----------+
 | d760eee8-1d91-48c4-8f9a-ad07072e17a2 | share-01 | ... | available ...
 +--------------------------------------+----------+-----+-----------+
Copy to Clipboard Toggle word wrap

manila list 명령은 공유의 내보내기 위치 도 표시합니다.

 +-------------------------------------------------------------+
 | Export location                                             ...
 +-------------------------------------------------------------+
 | 10.70.37.46:/manila-nfs-volume-01/share-d760eee8-1d91-...
 +-------------------------------------------------------------+
Copy to Clipboard Toggle word wrap

이 정보는 나중에 공유를 마운트할 때 사용됩니다 (4.5절. “인스턴스에 공유 마운트”).

4.4. 공유 액세스 부여

인스턴스에 공유를 마운트하려면 먼저 인스턴스에 공유에 대한 액세스 권한을 부여합니다.

# manila access-allow SHAREID IDENT IDENTKEY
Copy to Clipboard Toggle word wrap

다음과 같습니다.

  • SHAREID4.2절. “공유 만들기” 에서 생성된 공유의 ID입니다.
  • IDENT 는 파일 공유 서비스가 공유 사용자 또는 인스턴스를 인증하는 데 사용해야 하는 방법입니다.
  • IDENTKEYIDENT 로 선택하는 식별 방법에 따라 다릅니다.

    • cert: 이 방법은 TLS 인증서를 통해 인스턴스를 인증하는 데 사용됩니다.
    • user: 사용자 또는 그룹 이름으로 인증하는 데 사용합니다.
    • IP: 이를 사용하여 IP 주소를 통해 인스턴스를 인증합니다.

예를 들어 인스턴스에 읽기-쓰기 액세스 권한을 부여하려면(IP 10.70.36.85로 확인됨) 다음을 실행합니다.

# manila access-allow d760eee8-1d91-48c4-8f9a-ad07072e17a2 ip 10.70.36.85
 +--------------+--------------------------------------+
 | Property     | Value                                |
 +--------------+--------------------------------------+
 | share_id     | d760eee8-1d91-48c4-8f9a-ad07072e17a2 |
 | deleted      | False                                |
 | created_at   | 2015-09-29T16:35:33.862114           |
 | updated_at   | None                                 |
 | access_type  | ip                                   |
 | access_to    | 10.70.36.85                          |
 | access_level | rw                                   |
 | state        | new                                  |
 | deleted_at   | None                                 |
 | id           | b4e990d7-e9d1-4801-bcbe-a860fc1401d1 |
 +--------------+--------------------------------------+
Copy to Clipboard Toggle word wrap

공유에 대한 액세스에는 자체 ID(ACCESSID), b4e990d7-e9d1-4801-bcbe-a860fc1401d1 이 있습니다.

액세스 구성이 성공했는지 확인하려면 다음을 수행하십시오.

# manila access-list d760eee8-1d91-48c4-8f9a-ad07072e17a2
 +---------------------------+-----------+-----------+--------------+
 | id                        |access type|access to  | access level ...
 +---------------------------+-----------+-----------+--------------+
 |b4e990d7-e9d1-4801-bcbe-...|ip         |10.70.36.85| rw           ...
 +---------------------------+-----------+-----------+--------------+
Copy to Clipboard Toggle word wrap

4.5. 인스턴스에 공유 마운트

인스턴스를 인증하도록 공유를 구성한 후 공유를 마운트할 수 있습니다. 예를 들어, ]에서 xref:shares-access[ )의 인스턴스에 /mnt에 공유를 마운트하려면 인스턴스에 로그인하여 정상으로 마운트합니다.

# ssh root@10.70.36.85
# mount -t nfs -o vers=3 10.70.37.46:/manila-nfs-volume-01/share-d760eee8-1d91-48c4-8f9a-ad07072e17a2 /mnt
Copy to Clipboard Toggle word wrap

공유의 내보내기 정보를 보는 방법을 알아보려면 4.3절. “공유 및 내보내기 정보 나열” 를 참조하십시오.

인스턴스 내부에서 볼륨을 마운트할 때 마운트 지점의 공유에 쓸 수 있는지 확인합니다.

4.6. 공유에 대한 액세스 취소

이전에 부여한 공유 액세스 권한을 취소하려면 공유에 대한 액세스를 삭제해야 합니다.

# manila access-deny SHAREID ACCESSID
Copy to Clipboard Toggle word wrap

예를 들어 4.4절. “공유 액세스 부여” 에서 이전에 부여된 액세스 권한을 취소하려면 다음을 수행합니다.

# manila access-list d760eee8-1d91-48c4-8f9a-ad07072e17a2
 +---------------------------+-----------+-----------+--------------+
 | id                        |access type|access to  | access level ...
 +---------------------------+-----------+-----------+--------------+
 |b4e990d7-e9d1-4801-bcbe-...|ip         |10.70.36.85| rw           ...
 +---------------------------+-----------+-----------+--------------+
# manila access-deny d760eee8-1d91-48c4-8f9a-ad07072e17a2 b4e990d7-e9d1-4801-bcbe-a860fc1401d1
Copy to Clipboard Toggle word wrap

이때 인스턴스에서 더 이상 마운트된 공유를 사용할 수 없습니다.

4.7. 공유 삭제

공유를 삭제하려면 다음을 수행합니다.

# manila delete SHAREID
Copy to Clipboard Toggle word wrap

예를 들면 다음과 같습니다.

# manila delete d760eee8-1d91-48c4-8f9a-ad07072e17a2
Copy to Clipboard Toggle word wrap

법적 공지

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2026 Red Hat
맨 위로 이동