블록 스토리지 백업 가이드

Red Hat OpenStack Platform 16.2

Red Hat OpenStack Platform에서 블록 스토리지 백업 서비스 이해, 사용 및 관리

OpenStack Documentation Team

초록

이 문서에서는 Red Hat OpenStack Platform Block Storage(cinder) 백업 서비스를 배포하는 방법을 설명합니다. Red Hat OpenStack Platform director는 Red Hat Ceph Storage, NFS 및 Object Storage(swift)를 백엔드로 구성할 수 있습니다. Google Cloud Storage를 백업 백엔드로 구성할 수도 있습니다.

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

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

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

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

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

특정 문장, 단락 또는 코드 블록에 대한 직접 주석은 피드백 추가 DDF 기능을 사용하십시오.

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

1장. Red Hat OpenStack Platform 블록 스토리지 백업 서비스 개요

RHOSP(Red Hat OpenStack Platform)는 Red Hat Enterprise Linux를 기반으로 사설 또는 공용 IaaS(서비스로서의 인프라) 클라우드를 구축할 수 있는 기반을 제공합니다. 클라우드 지원 작업 부하를 개발하기 위한 확장 가능하고 내결함성을 갖춘 플랫폼입니다.

RHOSP 대시보드 또는 명령줄 클라이언트 방법을 사용하여 백업 서비스의 대부분의 기능을 관리할 수 있지만 명령줄을 사용하여 몇 가지 고급 절차를 실행해야 합니다.

참고

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

블록 스토리지 서비스(cinder)에는 Cinder 볼륨을 다양한 스토리지 백엔드로 백업하는 데 사용할 수 있는 수평 확장 가능한 백업 서비스가 포함되어 있습니다. 블록 스토리지 백업 서비스를 사용하여 전체 또는 증분 백업을 생성하고 복원할 수 있습니다. 서비스는 볼륨 배열과 독립적입니다.

RHOSP(Red Hat OpenStack Platform) director는 오버클라우드라는 전체 RHOSP 환경을 설치하고 관리하는 툴셋입니다. director에 대한 자세한 내용은 Director 설치 및 사용 가이드를 참조하십시오. 오버클라우드에는 블록 스토리지를 포함하여 최종 사용자에게 서비스를 제공하는 구성 요소가 포함되어 있습니다. 블록 스토리지 백업 서비스는 컨트롤러 노드에 배포하는 선택적 서비스입니다.

1.1. 백업 및 스냅샷

볼륨 백업은 볼륨 내용의 영구 복사본입니다. 볼륨 백업은 일반적으로 오브젝트 저장소로 생성되며, 기본적으로 OpenStack Object Storage 서비스(swift)를 통해 관리됩니다. Red Hat Ceph 및 NFS를 백업의 대체 백엔드로 사용할 수 있습니다.

볼륨 백업을 생성하면 모든 백업 메타데이터가 블록 스토리지 서비스 데이터베이스에 저장됩니다. cinder-backup 서비스는 백업에서 볼륨을 복원할 때 이 메타데이터를 사용합니다. 즉, 치명적인 데이터베이스 손실에서 복구를 수행할 때 블록 스토리지 서비스 데이터베이스의 원래 볼륨 백업 메타데이터가 손상되지 않은 경우 백업에서 볼륨을 복원하기 전에 먼저 Block Storage 서비스 데이터베이스를 복원해야 합니다. 치명적인 데이터베이스 손실 후에도 유지되도록 볼륨 백업의 하위 집합만 구성하려는 경우 백업 메타데이터를 내보낼 수도 있습니다. 그런 다음 REST API 또는 cinder 클라이언트를 사용하여 Block Storage 데이터베이스에 메타데이터를 다시 가져오고 볼륨 백업을 정상적으로 복원할 수 있습니다.

볼륨 백업은 스냅샷과 다릅니다. 백업은 볼륨에 포함된 데이터를 보존하고 스냅샷은 특정 시점의 볼륨 상태를 유지합니다. 기존 스냅샷이 있는 경우 볼륨을 삭제할 수 없습니다. 볼륨 백업은 데이터 손실을 방지하는 반면 스냅숏은 쉽게 복제할 수 있습니다. 이러한 이유로 스냅샷 백엔드는 복제 중 대기 시간을 최소화하기 위해 일반적으로 볼륨 백엔드와 함께 배치됩니다. 반대로 백업 리포지토리는 일반적으로 다른 노드 또는 다른 물리적 스토리지에 백엔드와 별도로 있습니다. 그러면 볼륨 백엔드에 발생할 수 있는 손상으로부터 백업 리포지토리가 보호됩니다.

볼륨 스냅샷에 대한 자세한 내용은 스토리지 가이드에서 볼륨 스냅샷 생성, 사용 또는 삭제 를 참조하십시오.

1.2. 볼륨 백업 워크플로

블록 스토리지 백업 서비스에서 백업을 수행하면 cinder API에서 대상 볼륨을 백업하라는 요청을 받습니다. 백업 서비스는 요청을 완료하고 백엔드에 콘텐츠를 저장합니다.

다음 다이어그램에서는 요청이 블록 스토리지(cinder) 서비스와 상호 작용하는 방법을 보여줍니다.

그림 1.1. 블록 스토리지 서비스로 백업 생성

OpenStack BlockStorage backup
  1. 클라이언트는 cinder API를 호출하여 Block Storage 볼륨을 백업하라는 요청을 발행합니다.
  2. cinder API 서비스는 HAProxy에서 요청을 수신하고 요청, 사용자 자격 증명 및 기타 정보를 검증합니다.
  3. SQL 데이터베이스에 백업 레코드를 만듭니다.
  4. AMQP를 통해 cinder-backup 서비스에 대한 비동기 RPC 호출을 만들어 볼륨을 백업합니다.
  5. ID가 있는 현재 백업 레코드를 API 호출자로 반환합니다.
  6. RPC create 메시지가 백업 서비스 중 하나에 도착합니다.
  7. cinder-backup 서비스는 get_backup_device 에 대한 동기 RPC 호출을 수행합니다.
  8. cinder-volume 서비스를 사용하면 올바른 장치가 호출자로 반환됩니다. 일반적으로 동일한 볼륨이지만 볼륨이 사용 중인 경우 서비스는 구성에 따라 임시 복제 볼륨 또는 임시 스냅샷을 반환합니다.
  9. cinder-backup 서비스는 소스 장치를 노출하기 위해 다른 동기 RPC를 cinder-volume 에 발행합니다.
  10. cinder-volume 서비스는 소스 장치(볼륨 또는 스냅샷)를 내보내고 매핑하고 적절한 연결 정보를 반환합니다.
  11. cinder-backup 서비스는 연결 정보를 사용하여 소스 볼륨을 연결합니다.
  12. cinder-backup 서비스는 백업 대상으로 데이터 전송을 시작하는 장치를 이미 연결된 백업 드라이버를 호출합니다.
  13. 볼륨은 Backup 호스트에서 분리됩니다.
  14. cinder-backup 서비스는 소스 장치의 연결을 해제하기 위해 동기 RPC를 cinder-volume 에 발행합니다.
  15. cinder-volume 서비스는 장치의 내보내기를 취소하고 제거합니다.
  16. 임시 볼륨 또는 임시 스냅샷이 생성된 경우 cinder-backupcinder-volume 을 호출하여 제거합니다.
  17. cinder-volume 서비스는 임시 볼륨을 제거합니다.
  18. 백업이 완료되면 데이터베이스에서 백업 레코드가 업데이트됩니다.

1.3. 볼륨 복원 워크플로

다음 다이어그램에서는 사용자가 블록 스토리지 서비스(cinder) 백업을 복원하도록 요청할 때 발생하는 단계를 보여줍니다.

그림 1.2. 블록 스토리지 백업 복원

OpenStack BlockStorage restore
  1. 클라이언트는 CinderREST API를 호출하여 블록 스토리지 백업을 복원하라는 요청을 발행합니다.
  2. cinder API는 HAProxy에서 요청을 수신하고 요청, 사용자 자격 증명 및 기타 정보를 검증합니다.
  3. 요청에 기존 볼륨이 대상으로 포함되어 있지 않으면 API는 비동기 RPC 호출을 만들어 새 볼륨을 생성하고 볼륨의 상태를 사용할 수 있을 때까지 폴링합니다.
  4. cinder-scheduler 는 볼륨 서비스를 선택하고 RPC 호출을 만들어 볼륨을 생성합니다.
  5. 선택한 cinder-volume 서비스는 볼륨을 만듭니다.
  6. cinder-api 에서 볼륨을 사용할 수 있음을 탐지하면 데이터베이스에 백업 레코드가 생성됩니다.
  7. AMQP를 통해 백업 서비스에 대한 비동기 RPC 호출을 통해 백업을 복원합니다.
  8. 현재 볼륨 ID, 백업 ID 및 볼륨 이름을 API 호출자로 반환합니다.
  9. RPC create 메시지가 백업 서비스 중 하나에 도착합니다.
  10. cinder-backup 서비스는 cinder-volume 에 대한 동기 RPC 호출을 수행하여 대상 볼륨을 노출합니다.
  11. cinder-volume 서비스는 적절한 연결 정보를 반환하는 대상 볼륨을 내보내고 매핑합니다.
  12. cinder-backup 서비스는 연결 정보를 사용하여 소스 볼륨을 연결합니다.
  13. cinder-backup 서비스는 이미 연결된 장치로 드라이버를 호출하여 볼륨 대상으로 데이터 복원을 시작합니다.
  14. 볼륨은 백업 호스트에서 분리됩니다.
  15. cinder-backup 서비스는 소스 장치의 연결을 해제하기 위해 동기 RPC를 cinder-volume 에 발행합니다.
  16. cinder-volume 서비스는 장치의 내보내기를 취소하고 제거합니다.
  17. 백업이 완료되면 데이터베이스에서 Backup 레코드가 업데이트됩니다.

1.4. 클라우드 스토리지와 로컬 스토리지 비교

Google Cloud Storage 드라이버는 블록 스토리지 백업 서비스에서 지원하는 유일한 클라우드 드라이버입니다. 기본적으로 Google Cloud Storage 드라이버는 이러한 유형의 백업에 가장 많은 비용이 드는 스토리지 솔루션을 사용합니다.

성능을 최적화하도록 백업 서비스를 구성합니다. 예를 들어, Europe에서 백업을 생성하는 경우 백업 지역을 유럽으로 변경합니다. 백업 지역을 기본값인 US에서 변경하지 않으면 두 지역 간의 지리적 거리로 인해 성능이 느려질 수 있습니다.

참고

Google Cloud Storage에는 섹션 부록 A. Google Cloud Storage 구성 에 설명된 특수 구성이 필요합니다.

다음 표에는 상황에 따라 클라우드 스토리지 및 로컬 스토리지의 이점과 제한 사항이 나와 있습니다.

상황클라우드 스토리지로컬 스토리지

오프사이트 백업

클라우드 스토리지는 다른 회사의 데이터 센터에 있으므로 자동으로 오프사이트에 있습니다. 여러 위치에서 데이터에 액세스할 수 있습니다. 재해 복구를 위해 원격 복사를 사용할 수 있습니다.

추가 계획 및 비용 필요.

하드웨어 제어

다른 서비스의 가용성과 전문성에 의존합니다.

스토리지 하드웨어를 완전히 제어할 수 있습니다. 관리 및 전문 지식 필요.

비용 고려 사항

공급업체에서 사용하는 서비스에 따라 서로 다른 가격 정책이나 계층.

필요에 따라 하드웨어를 추가하는 것이 알려진 비용입니다.

네트워크 속도 및 데이터 액세스

전반적인 데이터 액세스 속도가 느리고 인터넷 액세스가 필요합니다. 속도와 대기 시간은 여러 요인에 따라 달라집니다.

빠르고 즉시 데이터에 대한 액세스. 인터넷 액세스가 필요하지 않습니다.

2장. 블록 스토리지 백업 서비스 배포

블록 스토리지 백업 서비스는 선택 사항입니다. 기본적으로 설치되지 않으므로 오버클라우드 배포에 추가해야 합니다.

사전 요구 사항

  • 기존 RHOSP(Red Hat OpenStack Platform) 설치.
  • 호환되는 백업 드라이버가 있는 사용 가능한 스토리지 소스: Object Storage(swift; 기본값), Ceph, NFS 또는 Google Cloud 스토리지.
참고

Google Cloud Storage에는 추가 구성이 필요합니다. 자세한 내용은 부록 A. Google Cloud Storage 구성의 내용을 참조하십시오.

2.1. 백업 서비스의 백엔드 스토리지 옵션 구성

기본값과 다른 백엔드를 사용하도록 백업 서비스를 구성할 수 있습니다. 이 절차에서는 cinder-backup.yaml 파일의 복사본과 매개변수 기본값을 수정하는 방법을 설명합니다.

절차

  1. /usr/share/openstack -tripleo-heat-templates/environments/ 디렉터리에 있는 cinder- backup.yaml 파일의 복사본을 다른 사용자 지정 템플릿과 동일한 위치에 저장합니다.

    cp /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml /home/stack/templates/cinder-backup-settings.yaml
  2. cinder-backup.yaml 파일의 사본에는 Pacemaker를 사용하여 블록 스토리지 백업 서비스의 OpenStack Object Storage(swift) 백엔드를 구성하는 기본 설정이 포함되어 있습니다. 백업에 사용하는 백엔드인 경우 이 파일을 변경할 필요가 없습니다. 대체 백엔드를 사용하는 경우 백업 백엔드에 따라 parameter_defaults 를 구성합니다.

    • Red Hat Ceph Storage를 사용하는 경우 다음과 같은 방법으로 parameter_defaults 를 구성합니다.

      • CinderBackupBackend: (필수) ceph
      • CinderBackupRbdPoolName: (선택 사항) 사용자 지정 RBD 풀 이름으로 설정합니다. 기본값: backups
    • NFS를 사용하는 경우 다음과 같은 방식으로 parameter_defaults 를 구성합니다.

      • CinderBackupBackend: (필수) nfs
      • CinderBackupNfsShare: (필수) 마운트하려는 NFS 공유로 설정합니다. 기본값은 비어 있습니다.
      • CinderBackupNfsMountOptions: (선택 사항) 필수 마운트 옵션으로 설정합니다.
  3. 파일에 변경 사항을 저장합니다.
  4. 백업 서비스를 활성화하고 이 구성을 적용하려면 다른 환경 파일과 함께 스택에 백업 설정 환경 파일을 추가하고 오버클라우드를 배포합니다.

    (undercloud) [stack@undercloud ~]$ openstack overcloud deploy --templates \
      -e [your environment files]
      -e /home/stack/templates/cinder-backup-settings.yaml

자세한 내용 및 추가 구성 옵션은 부록 A. Google Cloud Storage 구성 을 참조하십시오.

2.2. Google Cloud 구성을 사용하여 오버클라우드 배포

'/home/stack/templates/ 에 환경 파일을 생성한 후 오버클라우드를 배포한 다음 cinder-backup 서비스를 다시 시작합니다.

중요

Google Cloud Storage를 사용한 Cinder 백업은 더 이상 사용되지 않으며 다음 주요 릴리스에서 지원이 제거됩니다.

절차

  1. stack 사용자로 로그인합니다.
  2. 구성을 배포합니다.

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/cinder-backup-settings.yaml
    중요

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

  3. 배포가 완료된 후 cinder-backup 서비스를 다시 시작합니다.

자세한 내용은 Advanced Overcloud Customization 가이드의 Director 설치 및 사용 가이드의 오버클라우드 배포의 환경 파일 포함 을 참조하십시오.

3장. 블록 스토리지 백업 서비스 사용

블록 스토리지 백업 서비스를 사용하여 전체 또는 증분 백업을 수행하고 볼륨에 백업을 복원할 수 있습니다.

3.1. 전체 백업

cinder backup-create 명령은 기본적으로 볼륨의 전체 백업을 생성합니다. 액세스할 수 있는 볼륨의 백업을 생성할 수 있습니다. 즉, 관리 권한이 있는 사용자는 소유자에 관계없이 볼륨을 백업할 수 있습니다.

3.1.1. 전체 볼륨 백업 생성

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

참고

RHOSP(Red Hat OpenStack Platform) 버전 16 이전에는 cinder backup-create 명령에서 첫 번째 전체 Ceph 볼륨 백업을 Ceph Storage 백엔드에 생성한 후 증분 백업을 생성했습니다. RHOSP 버전 16 이상에서는 --incremental 옵션을 사용하여 증분 볼륨 백업을 생성해야 합니다. cinder backup-create 명령에 --incremental 옵션을 사용하지 않는 경우 기본 설정에서 전체 백업을 생성합니다. 자세한 내용은 3.2.3절. “증분 백업 수행”의 내용을 참조하십시오.

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

절차

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

    # cinder list
  2. 볼륨을 백업합니다.

    # cinder backup-create _VOLUME_

    백업할 볼륨의 ID 또는 표시 이름으로 교체합니다. 예를 들면 다음과 같습니다.

      +-----------+--------------------------------------+
      |  Property |                Value                 |
      +-----------+--------------------------------------+
      |     id    | e9d15fc7-eeae-4ca4-aa72-d52536dc551d |
      |    name   |                 None                 |
      | volume_id | 5f75430a-abff-4cc7-b74e-f808234fa6c5 |
      +-----------+--------------------------------------+

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

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

    # cinder backup-list
  4. 백업 항목의 Status(상태) 를 사용할 수 있으면 볼륨 백업 생성이 완료됩니다.

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

관리 권한이 있는 사용자는 Red Hat OpenStack Platform에서 관리하는 모든 볼륨을 백업할 수 있습니다. 관리자가 관리자가 관리자가 소유한 볼륨을 백업하면 기본적으로 볼륨 소유자로부터 백업이 숨겨집니다.

절차

  • 관리자는 다음 명령을 사용하여 볼륨을 백업하고 특정 테넌트에서 백업을 사용할 수 있습니다.

    # cinder --os-auth-url <KEYSTONEURL> --os-tenant-name <TENANTNAME> --os-username <USERNAME> --os-password <PASSWD> backup-create <VOLUME>

    환경 요구 사항에 따라 다음 변수를 교체합니다.

  • <TENANTNAME>은 백업을 사용 가능하게 만들 테넌트의 이름입니다.
  • <USERNAME> 및 <PASSWD>는 <TENANTNAME>에 있는 사용자의 사용자 이름 및 암호 자격 증명입니다.
  • <VOLUME>는 백업할 볼륨의 이름 또는 ID입니다.
  • <KEYSTONEURL>은 ID 서비스의 URL 엔드포인트이며, 일반적으로 http://IP:5000/v2입니다. 여기서 IP 는 ID 서비스 호스트의 IP 주소입니다. 이 작업을 수행할 때 결과 백업의 크기는 테넌트 admin의 할당량이 아닌 할당량에 대해 계산됩니다.

3.1.3. 볼륨 백업의 메타데이터 내보내기

블록 스토리지 데이터베이스에 심각한 손실이 발생한 경우에도 볼륨 백업을 복원할 수 있도록 볼륨 백업의 메타데이터를 내보내고 저장할 수 있습니다.

절차

  • 다음 명령을 실행합니다.

    # cinder backup-export _BACKUPID_

    <BACKUPID>를 볼륨 백업의 ID 또는 이름으로 바꿉니다.

    +----------------+------------------------------------------+
    |    Property    |                Value                     |
    +----------------+------------------------------------------+
    | backup_service |     cinder.backup.drivers.swift          |
    |   backup_url   | eyJzdGF0dXMiOiAiYXZhaWxhYmxlIiwgIm9iam...|
    |                | ...4NS02ZmY4MzBhZWYwNWUiLCAic2l6ZSI6IDF9 |
    +----------------+------------------------------------------+

볼륨 백업 메타데이터는 backup_service 및 backup _url 값으로 구성됩니다.

3.1.4. 사용 중인 볼륨 백업

블록 스토리지 백엔드 스냅샷이 지원되는 경우 --force 옵션을 사용하여 사용 중인 볼륨의 백업을 생성할 수 있습니다.

참고

--force 옵션을 사용하려면 Block Storage 백엔드 스냅샷을 지원해야 합니다. 사용 중인 백엔드에 대한 설명서를 확인하여 스냅샷 지원을 확인할 수 있습니다.

--force 옵션을 사용하면 백업을 수행하기 전에 드라이브를 정지하지 않음을 인식합니다. 이 방법을 사용하면 충돌 일관성이 발생하지만 애플리케이션 일관성이 유지되지는 않습니다. 즉, 백업에 백업을 수행할 때 실행 중인 애플리케이션을 인식할 수 없습니다. 그러나 데이터는 손상되지 않습니다.

절차

  • 사용 중인 볼륨의 백업을 생성하려면 다음을 실행합니다.

    # cinder backup-create _VOLUME_ --incremental --force

3.1.5. 스냅샷 백업

스냅샷과 연결된 볼륨 ID를 사용하여 스냅샷에서 전체 백업을 생성할 수 있습니다.

절차

  1. cinder snapshot list를 사용하여 백업할 스냅샷의 스냅샷 ID를 찾습니다.

    # cinder snapshot-list --volume-id _VOLUME_ID_
  2. 스냅샷 이름이 지정된 경우 다음 예제를 사용하여 ID 를 찾을 수 있습니다.

    # cinder snapshot-show _SNAPSHOT_NAME_
  3. 스냅샷의 백업을 생성합니다.

    # cinder backup-create _VOLUME_ --snapshot-id=_SNAPSHOT_ID_
    참고

    --snapshot-id 옵션을 사용하면 NFS 볼륨의 스냅샷 기반 백업이 실패합니다. 이것은 확인된 문제입니다.

3.1.6. 에지 사이트에 백업 및 복원

에지 사이트 및 가용성 영역의 DCN(분산 계산 노드) 아키텍처에서 Block Storage 서비스(cinder) 볼륨을 백업하고 복원할 수 있습니다. cinder-backup 서비스는 AZ(중앙 가용 영역)에서 실행되며 백업은 중앙 AZ에 저장됩니다. 블록 스토리지 서비스는 DCN 사이트에 백업을 저장하지 않습니다.

사전 요구 사항

  • 중앙 사이트는 /usr/share/openstack -tripleo-heat-templates/environments에 있는 cinder- backup.yaml 환경 파일을 사용하여 배포됩니다. 자세한 내용은 블록 스토리지 백업 서비스 배포를 참조하십시오.
  • Block Storage 서비스(cinder) CLI를 사용할 수 있습니다.
  • 모든 사이트는 일반적인 openstack cephx 클라이언트 이름을 사용해야 합니다. 자세한 내용은 외부 액세스를 위한 Ceph 키 생성을 참조하십시오.

절차

  1. 첫 번째 DCN 사이트에 볼륨 백업을 생성합니다.

    $ cinder --os-volume-api-version 3.51 backup-create --name <volume_backup> --availability-zone <az_central> <edge_volume>
    • <volume_backup> 을 볼륨 백업의 이름으로 바꿉니다.
    • <az_central>cinder-backup 서비스를 호스팅하는 중앙 가용성 영역의 이름으로 바꿉니다.
    • <edge_volume> 을 백업할 볼륨 이름으로 교체합니다.

      참고

      Ceph 인증 키에 문제가 있는 경우 키 링이 호스트에서 컨테이너로 복사되도록 cinder-backup 컨테이너를 다시 시작해야 할 수 있습니다.

  2. 두 번째 DCN 사이트에서 백업을 새 볼륨으로 복원합니다.

    $ cinder --os-volume-api-version 3.51 create --availability-zone <az_2> --name <new_volume> --backup-id <volume_backup> <volume_size>
    • <az_2> 를 백업을 복원하려는 가용성 영역의 이름으로 바꿉니다.
    • <new_volume> 을 새 볼륨의 이름으로 바꿉니다.
    • <volume_backup> 을 이전 단계에서 생성한 볼륨 백업의 이름으로 바꿉니다.
    • <volume_size> 를 원래 볼륨의 크기보다 같거나 큰 값으로 바꿉니다.

3.2. 증분 백업

볼륨에 기존 백업이 있는 경우 블록 스토리지 백업 서비스를 사용하여 대신 증분 백업을 생성할 수 있습니다.

3.2.1. 성능 고려 사항

증분 및 데이터 압축과 같은 일부 백업 기능은 성능에 영향을 줄 수 있습니다. 볼륨의 모든 데이터를 전체 및 각 증분 백업에 대해 읽고 체크섬해야 하므로 증분 백업은 성능에 영향을 미칩니다.

비Ceph 백엔드에서 데이터 압축을 사용할 수 있습니다. 데이터 압축을 활성화하려면 추가 CPU 전원이 필요하지만 전체적으로 네트워크 대역폭과 스토리지 공간을 적게 사용합니다.

다중 경로 구성은 성능에도 영향을 미칩니다. 다중 경로를 활성화하지 않고 여러 볼륨을 연결하면 연결되지 않거나 전체 네트워크 기능이 없어 성능에 영향을 줄 수 있습니다.

고급 구성 옵션을 사용하여 압축을 활성화 또는 비활성화하고 프로세스 수를 정의하고 CPU 리소스를 추가할 수 있습니다. 자세한 내용은 B.1절. “고급 구성 옵션”의 내용을 참조하십시오.

3.2.2. 스냅샷에서 백업하는 영향

일부 백엔드는 스냅샷에서 백업 생성을 지원합니다. 이 기능을 지원하는 드라이버는 스냅샷을 볼륨에 복제하는 것보다 빠른 스냅샷을 직접 연결할 수 있습니다. 일반적으로 이 기능은 스냅샷에서 볼륨을 생성하는 추가 단계로 인해 성능에 영향을 줄 수 있습니다.

3.2.3. 증분 백업 수행

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

증분 백업은 NFS, Object Storage(swift) 및 Red Hat Ceph Storage 백업 리포지토리에서 완전 지원됩니다.

증분 백업은 마지막 전체 또는 증분 백업 이후 볼륨의 모든 변경 사항을 캡처합니다. 볼륨 크기가 시간이 지남에 따라 증가하므로 수많은 일반 볼륨 백업을 수행하는 것이 리소스 집약적일 수 있습니다. 증분 백업을 사용하면 정기적으로 볼륨에 대한 변경 사항을 캡처하고 리소스 사용을 최소화할 수 있습니다.

절차

  • 증분 볼륨 백업을 생성하려면 다음 명령에 --incremental 옵션을 사용합니다.

    # cinder backup-create _VOLUME_ --incremental

    백업할 볼륨의 ID 또는 표시 이름으로 교체합니다.

참고

이미 증분 백업이 있는 경우 전체 백업을 삭제할 수 없습니다. 전체 백업에 여러 증분 백업이 있는 경우 최신 백업만 삭제할 수 있습니다.

3.3. 백업 취소

백업을 취소하려면 관리자가 백업에서 강제로 삭제를 요청해야 합니다.

중요

Ceph 또는 RBD 백엔드를 사용하는 경우에는 이 작업이 지원되지 않습니다.

절차

  • 다음 명령을 실행합니다.

    # openstack volume backup delete --force <backup>

취소를 완료하고 백업이 백업 목록에 표시되지 않으면 백업이 성공적으로 취소될 때까지 약간의 지연이 발생할 수 있습니다. 백업이 성공적으로 취소되었는지 확인하려면 소스 리소스의 백업 상태가 중지됩니다.

참고

Red Hat OpenStack 버전 12 이전에는 스냅샷을 백업할 때도 백업 상태가 볼륨에 저장되었습니다. 따라서 스냅샷을 백업할 때 취소된 스냅샷의 모든 삭제 작업으로 인해 스냅샷이 여전히 매핑된 경우 오류가 발생할 수 있습니다. Red Hat OpenStack Platform 버전 13 이상에서는 지원되는 백업 드라이버에서 지속적인 복원 작업을 취소할 수 있습니다.

3.4. 테넌트 백업 할당량 보기 및 수정

일반적으로 대시보드를 사용하여 테넌트 스토리지 할당량(예: 테넌트에 포함될 수 있는 볼륨, 볼륨 스토리지, 스냅샷 또는 기타 운영 제한)을 수정할 수 있습니다. 그러나 대시보드를 사용하여 백업 할당량을 수정하는 기능은 아직 사용할 수 없습니다.

명령줄 인터페이스를 사용하여 백업 할당량을 수정해야 합니다.

절차

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

    # cinder quota-show TENANT_ID
  2. 특정 테넌트에서 생성할 수 있는 최대 백업(MAXNUM) 수를 업데이트하려면 다음 명령을 실행합니다.

    # cinder quota-update --backups MAXNUM TENANT_ID
  3. 특정 테넌트 내에서 모든 백업(MAXGB)의 최대 총 크기를 업데이트하려면 다음 명령을 실행합니다.

    # cinder quota-update --backup-gigabytes MAXGB TENANT_ID
  4. 특정 테넌트의 스토리지 할당량 사용량을 보려면 다음 명령을 실행합니다.

    # cinder quota-usage TENANT_ID

3.5. 백업에서 복원

데이터베이스 오류가 발생하거나 데이터 손실이 발생하는 다른 유형의 이벤트 후에는 생성한 백업을 사용하여 데이터를 복원합니다.

중요

Ceph RBD 드라이버를 사용하도록 cinder-backup 서비스를 구성하는 경우 RBD 기반 Block Storage(cinder) 백엔드에만 백업 볼륨을 복원할 수 있습니다.

3.5.1. 백업에서 볼륨 복원

백업에서 새 볼륨을 생성하려면 다음 단계를 완료합니다.

절차

  1. 사용하려는 볼륨 백업의 ID를 찾습니다.

    # cinder backup-list

    볼륨 ID가 복원할 볼륨의 ID와 일치하는지 확인합니다.

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

    # cinder backup-restore _BACKUP_ID_

    BACKUP_ID 를 사용하려는 볼륨 백업의 ID로 바꿉니다.

  3. 더 이상 백업이 필요하지 않은 경우 삭제하십시오.

    # cinder backup-delete _BACKUP_ID_
  4. 백업된 볼륨을 특정 유형의 볼륨에 복원해야 하는 경우 --volume 옵션을 사용하여 특정 볼륨에 백업을 복원합니다.

    # cinder backup-restore _BACKUP_ID --volume VOLUME_ID_
    참고

    암호화된 백업에서 볼륨을 복원하는 경우 대상 볼륨 유형도 암호화해야 합니다.

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

블록 스토리지 데이터베이스 손실이 발생하면 데이터베이스에 볼륨 백업 서비스에 필요한 메타데이터가 포함되어 있기 때문에 볼륨 백업을 복원할 수 없습니다. 그러나 볼륨 백업을 생성한 후에는 backup _service 및 backup_ url 값으로 구성된 메타데이터를 내보내고 저장할 수 있으므로 데이터베이스 손실이 발생하면 볼륨 백업을 복원할 수 있습니다. 자세한 내용은 3.1.1절. “전체 볼륨 백업 생성”에서 참조하십시오.

이 메타데이터를 내보내 저장한 경우 볼륨 백업을 복원할 수 있는 새 Block Storage 데이터베이스로 가져올 수 있습니다.

참고

증분 백업의 경우 내보낸 모든 데이터를 가져온 후 증분 백업 중 하나를 복원해야 합니다.

절차

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

    # cinder backup-import _backup_service_ _backup_url_

    backup_servicebackup_url 을 내보낸 메타데이터로 바꿉니다. 예를 들어 3.1.1절. “전체 볼륨 백업 생성” 에서 내보낸 메타데이터를 사용합니다.

    # cinder backup-import cinder.backup.drivers.swift eyJzdGF0dXMi...c2l6ZSI6IDF9
    +----------+--------------------------------------+
    | Property |                Value                 |
    +----------+--------------------------------------+
    |    id    | 77951e2f-4aff-4365-8c64-f833802eaa43 |
    |   name   |                 None                 |
    +----------+--------------------------------------+
  2. 메타데이터를 블록 스토리지 서비스 데이터베이스로 가져온 후 볼륨을 정상적으로 복원하고 3.5.1절. “백업에서 볼륨 복원” 를 참조하십시오.

3.5.3. 백업 복원 취소

백업 복원 작업을 취소하려면 백업 상태를 복원 하지 않고 변경합니다. 오류 상태를 사용하여 복원이 성공했는지 여부에 대한 혼란을 최소화할 수 있습니다. 또는 값을 available로 변경할 수 있습니다.

$ openstack volume backup set --state error BACKUP_ID
참고

백업 취소는 백업 드라이버가 백업을 취소하기 전에 상태 변경을 탐지해야 하므로 비동기 작업입니다. 대상 볼륨에서 상태가 available 로 변경되면 취소가 완료됩니다.

참고

현재 RBD 백업에서는 이 기능을 사용할 수 없습니다.

주의

시작된 후 복원 작업이 취소되면 실제로 복원된 데이터 양을 알 수 없기 때문에 대상 볼륨이 사용되지 않습니다.

4장. 블록 스토리지 백업 서비스 문제 해결

백업 서비스에 발생하는 여러 문제를 일으키는 두 가지 일반적인 시나리오가 있습니다.

  • cinder-backup 서비스가 시작되면 구성된 백엔드에 연결되고 이를 백업 대상으로 사용합니다. 이 연결 문제로 인해 서비스가 실패할 수 있습니다.
  • 백업을 요청하면 백업 서비스가 볼륨 서비스에 연결하고 요청된 볼륨을 연결합니다. 이 연결 문제는 백업 시간 동안에만 명확하게 표시됩니다.

두 경우 모두 로그에 오류를 설명하는 메시지가 포함되어 있습니다.

로그 파일 및 서비스에 대한 자세한 내용은 로깅, 모니터링 및 문제 해결 가이드 의 OpenStack 서비스의 로그 파일 위치를 참조하십시오.

로그 위치 및 문제 해결 제안에 대한 자세한 내용은 로깅, 모니터링 및 문제 해결 가이드 의 Block Storage(cinder) 로그 파일을 참조하십시오.

4.1. 서비스 확인 중

서비스가 사용 가능한지 확인하고 로그 파일에서 오류 메시지가 있는지 확인하여 많은 문제를 진단할 수 있습니다.

서비스 상태를 확인한 후 cinder-backup.log 파일을 확인합니다. 블록 스토리지 백업 서비스 로그는 /var/log/containers/cinder]/cinder-backup.log 에 있습니다.

절차

  1. 볼륨에서 cinder show 명령을 실행하여 호스트가 저장되는지 확인합니다.

    # cinder show
  2. cinder service-list 명령을 실행하여 실행 중인 서비스를 확인합니다.

    # cinder service-list
    +------------------+--------------------+------+---------+-------+----------------------------+-----------------+
    | Binary           | Host               | Zone | Status  | State | Updated_at                 | Disabled Reason |
    +------------------+--------------------+------+---------+-------+----------------------------+-----------------+
    | cinder-backup    | hostgroup          | nova | enabled | up    | 2017-05-15T02:42:25.000000 | -               |
    | cinder-scheduler | hostgroup          | nova | enabled | up    | 2017-05-15T02:42:25.000000 | -               |
    | cinder-volume    | hostgroup@sas-pool | nova | enabled | down  | 2017-05-14T03:04:01.000000 | -               |
    | cinder-volume    | hostgroup@ssd-pool | nova | enabled | down  | 2017-05-14T03:04:01.000000 | -               |
    +------------------+--------------------+------+---------+-------+----------------------------+-----------------+
  3. 예상 서비스를 사용할 수 있는지 확인합니다.

4.2. 실패한 백업의 상태 쿼리

백업은 비동기식입니다. 블록 스토리지 백업 서비스는 유효하지 않은 볼륨 참조(실패)확인 또는 사용 중 또는 인스턴스에 연결된 볼륨과 같이 API 요청을 수신할 때 적은 수의 정적 점검을 수행합니다. 사용 중인 경우 --force 옵션을 사용해야 합니다.

참고

--force 옵션을 사용하면 I/O가 정지되지 않고 결과 볼륨 이미지가 손상될 수 있습니다.

API에서 요청을 수락하면 백업이 백그라운드에서 수행됩니다. 일반적으로 백업이 실패하거나 실패에 도달하는 경우에도 CLI는 즉시 반환됩니다. cinder 백업 API를 사용하여 백업 상태를 쿼리할 수 있습니다. 오류가 발생하면 로그를 검토하여 원인을 검색합니다.

4.3. Pacemaker를 사용하여 리소스 관리

기본적으로 Pacemaker는 블록 스토리지 백업 서비스를 배포합니다. Pacemaker는 정의된 Red Hat OpenStack Platform 클러스터 리소스 세트가 실행 중이고 사용 가능한지 확인하기 위해 가상 IP 주소, 컨테이너, 서비스 및 기타 기능을 클러스터의 리소스로 구성합니다. 클러스터의 서비스 또는 전체 노드가 실패하면 Pacemaker에서 리소스를 다시 시작하거나, 노드를 클러스터에서 가져오거나, 노드를 재부팅할 수 있습니다. 대부분의 서비스에 대한 요청은 HAProxy를 통해 이루어집니다.

문제 해결을 위해 Pacemaker를 사용하는 방법에 대한 자세한 내용은 High Availability Deployment and Usage 가이드의 Pacemaker를 사용하여 고가용성 서비스 관리를 참조하십시오.

부록 A. Google Cloud Storage 구성

Google Cloud Storage를 백업 백엔드로 사용하도록 블록 스토리지 서비스(cinder)를 구성하려면 다음 절차를 완료하십시오.

  1. Google 계정의 서비스 계정 자격 증명을 생성하고 다운로드합니다.

  2. 환경 파일을 생성하여 필요한 블록 스토리지 설정을 매핑합니다.

  3. 생성한 환경 파일을 사용하여 오버클라우드를 다시 배포합니다.

중요

Google Cloud Storage를 사용한 Cinder 백업은 더 이상 사용되지 않으며 다음 주요 릴리스에서 지원이 제거됩니다.

사전 요구 사항

  • 높은 권한이 있는 계정의 사용자 이름과 암호가 있습니다. 오버클라우드를 배포하기 위해 생성된 stack 사용자 계정을 사용할 수 있습니다. 자세한 내용은 Director 설치 및 사용 가이드를 참조하십시오.
  • Google Cloud Platform에 액세스할 수 있는 Google 계정이 있습니다. 블록 스토리지 서비스는 이 계정을 사용하여 Google Cloud에 액세스하고 백업을 저장합니다.

A.1. GCS 자격 증명 파일 생성

블록 스토리지 서비스(cinder)는 백업에 Google Cloud에 액세스하고 사용하기 위해 Google 자격 증명이 필요합니다. 서비스 계정 키를 생성하여 블록 스토리지 서비스에 이러한 자격 증명을 제공할 수 있습니다.

절차

  1. Google 계정으로 Google 개발자 콘솔(http://console.developers.google.com)에 로그인합니다.
  2. Credentials(자격 증명 ) 탭을 클릭하고 Create credentials (자격 증명 생성) 드롭다운 메뉴에서 서비스 계정 키를 선택합니다.
  3. Create service account(서비스 계정 만들기) 키 화면의 서비스 계정 드롭다운 메뉴에서 블록 스토리지 서비스를 사용할 서비스 계정을 선택합니다.
  4. 동일한 화면의 Key type(키 유형) 섹션에서 JSON 을 선택하고 Create(생성 )를 클릭합니다. 그런 다음 브라우저가 키를 기본 다운로드 위치로 다운로드합니다.
  5. 파일을 열고 project_id 매개변수의 값을 확인합니다.

    {
      "type": "service_account",
      "project_id": "*cloud-backup-1370*",
    ...
  6. GCS JSON 자격 증명 사본을 /home/stack/templates/Cloud-Backup.json 에 저장합니다.

    중요
    파일의 이름을 Cloud-Backup.json 으로 지정하고 파일 이름을 변경하지 마십시오. 이 JSON 파일은 A.2절. “cinder-backup-gcs.yaml생성” 의 절차의 일부로 생성하는 cinder-backup-gcs.yaml 파일과 동일한 디렉터리 위치에 있어야 합니다.

A.2. cinder-backup-gcs.yaml생성

제공된 예제 파일을 사용하여 cinder-backup-gcs.yaml 파일을 만듭니다.

참고

예제(및 파일에서)에 사용된 공백과 형식은 중요합니다. 공백이 변경되면 파일이 예상대로 작동하지 않을 수 있습니다.

절차

  1. 아래 텍스트를 복사하여 새 파일에 붙여넣습니다. 파일 내용을 수정하지 마십시오.

    heat_template_version: rocky
    
    description: >
      Post-deployment for configuration cinder-backup to GCS
    
    parameters:
      servers:
        type: json
      DeployIdentifier:
        type: string
    
    resources:
      CinderBackupGcsExtraConfig:
        type: OS::Heat::SoftwareConfig
        properties:
          group: script
          config:
            str_replace:
              template: |
                #!/bin/bash
                GCS_FILE=/var/lib/config-data/puppet-generated/cinder/etc/cinder/Cloud-Backup.json
                HOSTNAME=$(hostname -s)
                for NODE in $(hiera -c /etc/puppet/hiera.yaml cinder_backup_short_node_names | tr -d '[]",'); do
                  if [ $NODE == $HOSTNAME ]; then
                    cat <<EOF > $GCS_FILE
                GCS_JSON_DATA
                EOF
                    chmod 0640 $GCS_FILE
                    chown root:42407 $GCS_FILE
                  fi
                done
              params:
                GCS_JSON_DATA: {get_file: Cloud-Backup.json}
    
      CinderBackupGcsDeployment:
        type: OS::Heat::SoftwareDeploymentGroup
        properties:
          servers:  {get_param: servers}
          config: {get_resource: CinderBackupGcsExtraConfig}
          actions: ['CREATE','UPDATE']
          input_values:
            deploy_identifier: {get_param: DeployIdentifier}
  2. 파일을 /home/stack/templates/cinder-backup-gcs.yaml 로 저장합니다.

A.3. Google Cloud 설정을 사용하여 환경 파일 생성

블록 스토리지 서비스(cinder)에 적용할 설정을 포함하도록 환경 파일을 만듭니다. 이 경우 환경 파일은 볼륨 백업을 Google 클라우드에 저장하도록 블록 스토리지 서비스를 구성합니다. 환경 파일에 대한 자세한 내용은 Director 설치 및 사용 가이드를 참조하십시오.

다음 예제 환경 파일을 사용하고 Cloud-Backup.json 파일에 나열된 프로젝트 ID로 backup_gcs_project_id 를 업데이트합니다. backup_gcs_bucket_location 위치를 미국에서 해당 위치에 가까운 위치로 변경할 수도 있습니다.

Google Cloud Backup Storage 백업 백엔드의 구성 옵션 목록은 표 A.1. “Google Cloud Storage 백업 백엔드 구성 옵션” 을 참조하십시오.

절차

  1. 아래 환경 파일 예제를 복사합니다. 공백 사용을 유지합니다.
  2. 콘텐츠를 새 파일 /home/stack/templates/cinder-backup-settings.yaml 에 붙여넣습니다.
  3. backup_gcs_project_id 의 값을 cloud-backup-1370 에서 Cloud-Backup.json 파일에 나열된 프로젝트 ID로 변경합니다.
  4. 파일을 저장합니다.

환경 파일 예

환경 파일에서 각 설정을 정의합니다. 사용 가능한 구성 옵션을 선택하려면 표 A.1. “Google Cloud Storage 백업 백엔드 구성 옵션” 을 사용합니다.

resource_registry:
  OS::TripleO::Services::CinderBackup: /usr/share/openstack-tripleo-heat-templates/deployment/cinder/cinder-backup-pacemaker-puppet.yaml
  # For non-pcmk managed implementation
  # OS::TripleO::Services::CinderBackup: /usr/share/openstack-tripleo-heat-templates/deployment/cinder/cinder-backup-container-puppet.yaml
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/cinder-backup-gcs.yaml

parameter_defaults:
  CinderBackupBackend: swift
  ExtraConfig:
    cinder::backup::swift::backup_driver: cinder.backup.drivers.gcs.GoogleBackupDriver
    cinder::config::cinder_config:
      DEFAULT/backup_gcs_credential_file:
        value: /etc/cinder/Cloud-Backup.json
      DEFAULT/backup_gcs_project_id:
        value: cloud-backup-1370
      DEFAULT/backup_gcs_bucket:
        value: cinder-backup-gcs
      DEFAULT/backup_gcs_bucket_location:
        value: us

표 A.1. Google Cloud Storage 백업 백엔드 구성 옵션

PARAMDefaultCONFIG 설명

backup_gcs_project_id

 

필수 항목입니다. 사용 중인 서비스 계정의 프로젝트 ID이며 A.1절. “GCS 자격 증명 파일 생성” 서비스 계정 키의 project_id 에 포함됩니다.

backup_gcs_credential_file

 

A.1절. “GCS 자격 증명 파일 생성” 에서 생성한 서비스 계정 키 파일의 절대 경로입니다.

backup_gcs_bucket

 

사용하려는 GCS 버킷 또는 오브젝트 스토리지 리포지토리는 존재하지 않을 수도 있습니다. 존재하지 않는 버킷을 지정하면 Google Cloud Storage 백업 드라이버를 생성하여 여기에서 지정하는 이름을 할당합니다. 자세한 내용은 버킷 및 버킷 이름 요구 사항을 참조하십시오.

backup_gcs_bucket_location

us

GCS 버킷의 위치입니다. 이 값은 backup_gcs_bucket 에서 존재하지 않는 버킷을 지정하는 경우에만 사용됩니다. 이 경우 Google Cloud Storage 백업 드라이버는 이를 GCS 버킷 위치로 지정합니다.

backup_gcs_object_size

52428800

GCS 백업 오브젝트의 크기(바이트)입니다.

backup_gcs_block_size

32768

증분 백업에 대해 변경 사항이 추적되는 크기(바이트)입니다. 이 값은 backup_gcs_object_size 값의 배수여야 합니다.

backup_gcs_user_agent

gcscinder

GCS API의 HTTP 사용자 에이전트 문자열입니다.

backup_gcs_reader_chunk_size

2097152

GCS 오브젝트는 이 크기의 청크로 다운로드됩니다(바이트).

backup_gcs_writer_chunk_size

2097152

GCS 개체는 이 크기의 청크로 바이트로 업로드됩니다. 파일을 단일 청크로 업로드하려면 값 -1을 사용합니다.

backup_gcs_num_retries

3

시도할 재시도 횟수입니다.

backup_gcs_storage_class

니어라인

GCS 버킷의 스토리지 클래스입니다. 이 값은 backup_gcs_bucket 에서 존재하지 않는 버킷을 지정하는 경우에만 사용됩니다. 이 경우 Google Cloud Storage 백업 드라이버는 이를 GCS 버킷 스토리지 클래스로 지정합니다. 자세한 내용은 스토리지 클래스를 참조하십시오.

backup_gcs_retry_error_codes

429

GCS 오류 코드 목록입니다.

backup_gcs_enable_progress_timer

True

볼륨 백업 중에 주기적으로 진행률 알림을 보내는 타이머를 활성화하거나 비활성화하는 부울입니다(ceilometer). 이는 기본적으로 활성화되어 있습니다(True).

주의

새 버킷을 생성할 때 Google Cloud Storage는 선택한 스토리지 클래스(backup_gcs_storage_class)에 따라 요금을 청구합니다. default NEARLINE 클래스는 백업 서비스에 적합합니다.

주의

버킷을 생성한 후에는 버킷 위치 또는 클래스를 편집할 수 없습니다. 자세한 내용은 버킷 스토리지 클래스 또는 위치 관리를 참조하십시오.

A.4. 오버클라우드 배포

/home/stack/templates/ 에 환경 파일을 생성한 경우 오버클라우드를 배포한 다음 cinder-backup 서비스를 다시 시작합니다.

절차

  1. stack 사용자로 로그인합니다.
  2. 구성을 배포합니다.

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/cinder-backup-settings.yaml
    중요

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

  3. 배포가 완료된 후 cinder-backup 서비스를 다시 시작합니다.

자세한 내용은 Advanced Overcloud Customization 가이드의 Director 설치 및 사용 가이드 의 Overcloud Creation 에서 환경 파일 포함 섹션을 참조하십시오.

부록 B. 고급 블록 스토리지 구성

director가 배포하기 전에 cinder.conf 파일에서 블록 스토리지 서비스와 백업 서비스를 구성했습니다. cinder.conf 의 값이 오케스트레이션(heat) 템플릿에 상응하는 것이 없는 경우 사용자 지정 환경 파일을 사용하여 director에 값을 전달할 수 있습니다. 사용자 지정 환경 파일의 parameter_defaults 섹션에 있는 ExtraConfig 섹션에 값을 추가합니다(예: cinder-backup-settings.yaml 파일).

B.1. 고급 구성 옵션

ExtraConfig 를 사용하면 모든 노드의 클러스터에 hiera 구성을 추가할 수 있습니다. 이러한 설정은 전용 백업 노드에 포함되어 있습니다. 그러나 Extra Config 대신 ControllerExtraConfig 를 사용한 경우 설정이 전용 백업 노드가 아닌 컨트롤러 노드에 설치됩니다.

cinder .conf 파일의 DEFAULT 섹션에서 설정을 위해 DEFAULT /[cinder.conf 설정] 을 대체할 수 있습니다. 다음 예제에서는 ExtraConfig 항목이 YAML 파일에 표시되는 방법을 보여줍니다.

parameter_defaults:
 ExtraConfig:
   cinder::config::cinder_config:
     DEFAULT/backup_compression_algorithm:
       value: None

표 B.1에는 백업 관련 샘플 옵션이 나열되어 있습니다.

표 B.1. 블록 스토리지 백업 서비스 구성 옵션

옵션유형기본값설명

backup_service_inithost_offload

선택 사항

True

백업 서비스를 시작하는 동안 보류 중인 백업 삭제 오프로드. false인 경우 백업 서비스는 보류 중인 모든 백업이 삭제될 때까지 다운됩니다.

use_multipath_for_image_xfer

선택 사항

False

백업 및 복원 절차 중에 사용 가능한 경우 다중 경로를 사용하여 볼륨을 연결합니다. 이는 이미지에서 볼륨 생성, 일반 콜드 마이그레이션 및 기타 작업과 같은 모든 cinder 연결 작업에 영향을 미칩니다.

num_volume_device_scan_tries

선택 사항

3

대상을 다시 검사하여 연결 중에 볼륨을 찾을 수 있는 최대 횟수입니다.

backup_workers

선택 사항

1

실행할 백업 프로세스 수입니다. 압축을 사용하여 여러 동시 백업 또는 복원을 실행하면 성능이 크게 향상됩니다.

backup_native_threads_pool_size

선택 사항

60

백업의 기본 스레드 풀 크기입니다. 대부분의 백업 드라이버는 이에 크게 의존합니다. 이 옵션을 사용하지 않는 특정 드라이버의 값을 줄일 수 있습니다.

backup_share

필수 항목

 

HOST:_EXPORT_PATH_로 설정합니다.

backup_container

선택 사항

없음

(문자열) 백업에 사용할 사용자 정의 디렉토리입니다.

backup_enable_progress_timer

선택 사항

True

백엔드 스토리지에 볼륨을 백업할 때 타이머를 활성화하거나 비활성화(false)하여 원격 분석 서비스(ceilometer)로 주기적으로 진행 알림을 보냅니다.

backup_mount_options

선택 사항

 

backup_share에 지정된 NFS 내보내기를 마운트할 때 지정할 수 있는 쉼표로 구분된 옵션 목록입니다.

backup_mount_point_base

선택 사항

$state_path/backup_mount

(문자열) NFS 공유의 마운트 지점이 포함된 기본 디렉터리입니다.

backup_compression_algorithm

선택 사항

zlib

백업 데이터를 리포지토리에 전송할 때 사용할 압축 알고리즘입니다. 유효한 값은 zlib,bz2None 입니다.

backup_file_size

선택 사항

1999994880

이 값보다 큰 cinder 볼륨의 데이터는 백업 리포지토리에 여러 파일로 저장됩니다. 이 옵션은 backup_sha_block_size_bytes의 배수여야 합니다.

backup_sha_block_size_bytes

선택 사항

32768

디지털 서명 계산을 위한 Cinder 볼륨 블록 크기

법적 공지

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