검색

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

download PDF

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

중요

블록 스토리지 서비스(cinder) 및 파이버 채널(FC) 백엔드를 사용하는 배포에 모든 컨트롤러 노드 및 컴퓨팅 노드에 HBA(호스트 버스 어댑터)를 설치해야 합니다.

2.2.1. 고가용성을 위한 액티브-액티브 배포

중요
활성-활성 모드는 에지 사이트의 DCN(Distributed Compute 노드) 아키텍처에서만 지원됩니다.

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

액티브-액티브 배포는 사용 가능한 모든 노드에서 워크로드를 분산하여 확장, 성능 및 응답 시간을 단축합니다. 블록 스토리지 서비스를 액티브-액티브 구성에 배포하면 부분적인 네트워크 중단 및 단일 또는 다중 노드 하드웨어 오류 중에 관리 계층을 유지 관리하는 고가용성 환경이 생성됩니다. 액티브-액티브 배포를 사용하면 클러스터가 노드 중단 중에 블록 스토리지 서비스를 계속 제공할 수 있습니다.

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

2.2.1.1. 고가용성을 위한 액티브-액티브 구성 활성화

cinder-volume-active-active.yaml 파일을 사용하면 블록 스토리지 서비스를 활성-활성 구성으로 배포할 수 있습니다. 이 파일을 사용하면 director에서 비 Pacemaker cinder-volume heat 템플릿을 사용하고 etcd 서비스를 DLM(Distributed Lock Manager)으로 배포에 추가합니다.

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

중요

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

절차

액티브-액티브 블록 스토리지 서비스 볼륨을 활성화하려면 오버클라우드 배포에 다음 환경 파일을 포함합니다.

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

2.2.1.2. 활성-활성 구성을 위한 유지 관리 명령

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

사용자 목표

명령

클러스터 이름, 호스트, 영역, 상태, 상태, 비활성화 이유 및 백엔드 상태와 같은 세부 정보를 포함하여 서비스 목록을 참조하십시오.

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

Cinder service-list

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

Cinder cluster-list

참고: 이 명령에는 3.7 이상의 Cinder API 마이크로버전이 필요합니다.

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

Cinder cluster-show <cluster_name>

참고: 이 명령에는 3.7 이상의 Cinder API 마이크로버전이 필요합니다.

비활성화된 서비스 활성화.

Cinder cluster-enable <cluster_name>

참고: 이 명령에는 3.7 이상의 Cinder API 마이크로버전이 필요합니다.

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

Cinder cluster-disable <cluster_name>

참고: 이 명령에는 3.7 이상의 Cinder API 마이크로버전이 필요합니다.

2.2.1.3. 볼륨 관리 및 관리 취소

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

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

API 버전 3.16 이상에서는 cinder manage 명령에서 선택적 --cluster 인수도 허용하므로 이전에 관리되지 않는 볼륨을 블록 스토리지 클러스터에 추가할 수 있습니다.

2.2.1.4. 클러스터된 서비스의 볼륨 마이그레이션

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

블록 스토리지 클러스터형 서비스에서 볼륨을 마이그레이션하는 경우 선택적 --cluster 인수를 전달하고 인수가 상호 배타적이므로 호스트 위치 인수를 생략합니다.

2.2.1.5. 서버 유지 관리 시작

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

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

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

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

절차

  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.2.2. 볼륨 유형을 사용하여 그룹 볼륨 설정

Red Hat OpenStack Platform을 사용하면 볼륨 유형에 연결된 설정을 적용할 수 있도록 볼륨 유형을 생성할 수 있습니다. 볼륨 생성 중에 설정을 적용할 수 있습니다. 볼륨 만들기를 참조하십시오. 볼륨을 생성한 후 설정을 적용할 수도 있습니다. 볼륨 유형 변경(볼륨 다시 입력)을 참조하십시오. 다음 목록은 볼륨 유형에 적용할 수 있는 관련된 몇 가지 설정을 보여줍니다.

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

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

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

참고

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

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

# 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.2.2.2. 볼륨 유형 생성 및 구성

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

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

참고

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

2.2.2.3. 볼륨 유형 편집

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

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

2.2.2.4. 볼륨 유형 삭제

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

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

기본적으로 모든 테넌트에서 모든 볼륨 유형을 사용할 수 있습니다. 개인용으로 표시하여 제한된 볼륨 유형을 생성할 수 있습니다. 이를 수행하려면 유형의 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.2.3. 블록 스토리지 서비스에 대한 내부 테넌트 생성 및 구성

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

내부 프로젝트를 구성하려면 먼저 cinder-internal 이라는 일반 프로젝트와 사용자를 생성합니다. 이를 수행하려면 컨트롤러 노드에 로그인하여 다음을 실행합니다.

# openstack project create --enable --description "Block Storage Internal Tenant" 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.2.4절. “Image-Volume 캐시 구성 및 활성화”의 내용을 참조하십시오.

2.2.4. Image-Volume 캐시 구성 및 활성화

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

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

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

참고

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

백엔드(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 를 사용하여 최대 이미지 수를 설정할 수도 있습니다.

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

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

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

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

중요

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

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

2.2.5. 서비스 품질 사양 사용

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

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

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

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

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

2.2.5.1. 기본 볼륨 서비스 품질

기본 볼륨 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.2.5.2. QOS 사양 생성 및 구성

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

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

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

    back-end

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

    front-end

    컴퓨팅에 QOS 정책이 적용됩니다.

    모두

    QOS 정책은 블록 스토리지와 계산 모두에 적용됩니다.

  5. 생성을 클릭합니다. 이제 새로운 QOS 사양이 QOS Specs 테이블에 표시됩니다.
  6. QOS Specs 테이블에서 새 사양의 Manage Specs 작업을 선택합니다.
  7. Create(만들기)를 클릭하고 Key (키)와 Value (값)를 지정합니다. 키-값 쌍이 유효해야 합니다. 그렇지 않으면 볼륨을 생성하는 동안 이 QOS 사양과 연결된 볼륨 유형을 지정할 수 없습니다.

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

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

2.2.5.3. 용량 기반 QoS 제한 설정

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

특히 블록 스토리지 서비스를 사용하면 실제 프로비저닝된 크기에 따라 볼륨에 할당할 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.2.2절. “볼륨 유형을 사용하여 그룹 볼륨 설정”2.2.2.2절. “볼륨 유형 생성 및 구성” 을 참조하십시오. QoS 사양을 설정하는 방법에 대한 지침은 2.2.5절. “서비스 품질 사양 사용” 참조하십시오.

주의

용량 파생 QoS 제한이 있는 볼륨 유형(또는 볼륨 재입력)을 연결된 볼륨에 적용하면 제한이 적용되지 않습니다. 제한은 인스턴스에서 볼륨을 분리한 후에만 적용됩니다.

볼륨 다시 입력에 대한 자세한 내용은 2.3.16절. “볼륨 다시 입력” 을 참조하십시오.

2.2.5.4. QOS 사양과 볼륨 유형 연결

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

  1. 대시보드의 관리자로 Admin > Volumes > Volume Types 를 선택합니다.
  2. Volume Types(볼륨 유형) 테이블에서 유형 Manage QOS Spec Association(QOS 사양 연결 관리) 작업을 선택합니다.
  3. 연결할 QOS 사양에서 QOS 사양을 선택합니다.
  4. Associate(연결)를 클릭합니다. 이제 선택한 QOS 사양이 편집된 볼륨 유형의 Associated QOS Spec 열에 표시됩니다.

2.2.5.5. 볼륨 유형에서 QOS 사양의 연결을 끊습니다

  1. 대시보드의 관리자로 Admin > Volumes > Volume Types 를 선택합니다.
  2. Volume Types(볼륨 유형) 테이블에서 유형 Manage QOS Spec Association(QOS 사양 연결 관리) 작업을 선택합니다.
  3. 연결할 QOS 사양에서 None 을 선택합니다.
  4. Associate(연결)를 클릭합니다. 선택한 QOS 사양은 편집된 볼륨 유형의 Associated QOS Spec 열에 더 이상 없습니다.

2.2.6. 볼륨 암호화 구성

볼륨 암호화는 볼륨 백엔드가 손상되거나 도난된 경우 기본 데이터 보호를 제공합니다. 계산 및 블록 스토리지 서비스가 모두 통합되어 인스턴스가 암호화된 볼륨을 읽고 사용할 수 있습니다. 볼륨 암호화를 사용하려면 Key Manager 서비스(barbican)를 배포해야 합니다.

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

볼륨 암호화는 볼륨 유형을 사용하여 적용됩니다. 암호화된 볼륨 유형에 대한 자세한 내용은 2.2.6.1절. “대시보드를 통해 볼륨 유형 암호화 구성” 을 참조하십시오.

2.2.6.1. 대시보드를 통해 볼륨 유형 암호화 구성

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

  1. 대시보드에서 admin 사용자로 Admin > Volumes > Volume Types (볼륨 유형)를 선택합니다.
  2. 암호화할 볼륨의 Actions(작업) 열에서 Create Encryption(암호화 만들기)을 선택하여 Create Volume Type Encryption (볼륨 유형 암호화 생성) 마법사를 시작합니다.
  3. 여기에서 볼륨 유형암호화프로바이더,제어 위치, 암호 및 키 크기 설정을 구성합니다. Description(설명 ) 열은 각 설정을 설명합니다.

    중요

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

    1. Provider (공급업체)에 luks 를 입력합니다.
    2. Cipher 에 aes-xts-plain64 를 입력합니다.
    3. 키 크기에 256 을 입력합니다.
  4. Create Volume Type(볼륨 유형 암호화 만들기)을 클릭합니다.

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

CLI를 통해 암호화된 볼륨 유형을 구성하려면 2.2.6.2절. “CLI를 통해 볼륨 유형 암호화 구성” 을 참조하십시오.

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

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

2.2.6.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

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

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

암호화 키 삭제는 키 관리 서비스의 무제한 리소스 사용을 방지합니다. 블록 스토리지, 키 관리 및 이미지 서비스는 키 삭제를 포함하여 암호화된 볼륨에 대한 키를 자동으로 관리합니다.

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

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

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

볼륨 이미지를 생성할 때 블록 스토리지 서비스는 cinder_encryption_key_deletion_policy 속성을 on_ image_deletion 으로 설정합니다. 볼륨 이미지를 삭제하면 cinder_encryption_key_deletion_policy가 on_image_deletion 과 같은 경우 이미지 서비스에서 해당 암호화 키를 삭제합니다.

중요

Red Hat은 cinder_encryption_key _id 또는 cinder_encryption_key_ deletion_policy 속성을 수동으로 조작하는 것을 권장하지 않습니다. 다른 용도로 cinder_encryption_key_id 값으로 식별된 암호화 키를 사용하는 경우 데이터 손실 위험이 있습니다.

자세한 내용은 OpenStack 키 관리자로 시크릿 관리 가이드를 참조하십시오.

2.2.7. 볼륨이 여러 백엔드에 할당되는 방법 설정

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

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

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

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

필터 스케줄러를 구성하려면 다음을 포함하는 배포에 환경 파일을 추가합니다.

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

2.2.8. 가용성 영역 배포

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

절차

블록 스토리지 볼륨 백엔드에 대해 다른 가용 영역을 배포하려면 다음을 수행합니다.

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

    parameter_defaults:
     CinderXXXAvailabilityZone: zone1
     CinderYYYAvailabilityZone: zone2

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

    CinderISCSIAvailabilityZone
    CinderNfsAvailabilityZone
    CinderRbdAvailabilityZone
    참고

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

    다음 예제에서는 두 개의 백엔드를 배포합니다. 여기서 rbd 는 zone 1이고 iSCSI 는 zone 2입니다.

    parameter_defaults:
     CinderRbdAvailabilityZone: zone1
     CinderISCSIAvailabilityZone: zone2
  2. Overcloud를 배포하고 업데이트된 환경 파일을 포함합니다.

2.2.9. 일관성 그룹 구성 및 사용

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

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

2.2.9.1. 일관성 그룹 설정

기본적으로 블록 스토리지 보안 정책은 일관성 그룹 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 명령을 사용하여 오버클라우드에 배포해야 합니다. Overcloud가 다음에 배포될 때 변경 사항이 덮어쓰기되므로 JSON 파일을 직접 편집하지 마십시오.

절차

  1. 환경 파일을 편집하고 parameters _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 설치 및 사용 가이드 의 CLI 툴을 사용하여 Overcloud 생성을 참조하십시오.

2.2.9.2. 일관성 그룹 생성

일관성 그룹 API를 활성화하면 일관성 그룹 생성을 시작할 수 있습니다.

절차

  1. 대시보드에서 관리자로 Project > Compute > Volumes > Volume Consistency Groups 를 선택합니다.
  2. Create Consistency Group (영구 그룹 만들기)을 클릭합니다.
  3. 마법사의 Consistency Group Information(Consistency 그룹 정보 ) 탭에서 일관성 그룹에 대한 이름 및 설명을 입력합니다. 그런 다음 해당 가용 영역을 지정합니다.
  4. 일관성 그룹에 볼륨 유형을 추가할 수도 있습니다. 일관성 그룹 내에서 볼륨을 생성하면 블록 스토리지 서비스가 이러한 볼륨 유형에서 호환되는 설정을 적용합니다. 볼륨 유형을 추가하려면 사용 가능한 모든 볼륨 유형 목록에서 + 버튼을 클릭합니다.
  5. Create Consistency Group (영구 그룹 만들기)을 클릭합니다. Volume Consistency Groups (볼륨 일관성 그룹) 테이블에 다음이 표시됩니다.

2.2.9.3. 일관성 그룹 관리

절차

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

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

2.2.9.4. 일관성 그룹 스냅샷 생성 및 관리

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

절차

  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> (선택 사항).
    • 일관성 그룹의 이름 또는 ID가 있는 <CGNAMEID> 입니다.
  4. 사용 가능한 모든 일관성 그룹 스냅샷 목록을 표시합니다.

    # cinder cgsnapshot-list

2.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로 바꿉니다.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.