3.2. 백업 및 마이그레이션

3.2.1. Red Hat Virtualization Manager 백업 및 복원

3.2.1.1. Red Hat Virtualization Manager 백업 - 개요

engine-backup 도구를 사용하여 Red Hat Virtualization Manager의 정기적 백업을 수행합니다. 툴은 엔진 데이터베이스와 구성 파일을 단일 파일로 백업하고 ovirt-engine 서비스를 중단하지 않고 실행할 수 있습니다.

3.2.1.2. engine-backup 명령의 구문

engine-backup 명령은 다음 두 가지 기본 모드 중 하나로 작동합니다.

# engine-backup --mode=backup

# engine-backup --mode=restore

이러한 두 모드는 백업 범위와 engine 데이터베이스의 다른 자격 증명을 지정할 수 있는 일련의 옵션에 의해 추가로 확장됩니다. 전체 옵션과 해당 기능을 보려면 engine-backup --help 를 실행합니다.

기본 옵션

--mode

명령이 백업 작업을 수행할지 또는 복원 작업을 수행할지 여부를 지정합니다. 사용 가능한 옵션은 backup (기본적으로 설정), 복원 및 확인 입니다. 확인 또는 복원 작업에 대한 모드 옵션을 정의해야 합니다.

--file

백업 모드로 저장되는 파일 경로 및 이름(예: file_name.backup)을 지정하고 복원 모드에서 백업 데이터로 읽을 파일을 지정합니다. 경로는 기본적으로 /var/lib/ovirt-engine-backup/ 로 정의됩니다.

--log

백업 또는 복원 작업의 로그가 기록되는 파일 경로 및 이름(예: log_file_name)을 지정합니다. 경로는 기본적으로 /var/log/ovirt-engine-backup/ 로 정의됩니다.

--scope

backup 또는 restore 작업의 범위를 지정합니다. 모든 데이터베이스 및 구성 데이터를 백업하거나 복원하는 방법은 네 가지입니다. files, to back up or restore only files on the system; db, to back up or restore only the Manager database; 및 dwhdb 데이터베이스만 백업하거나 복원하기 위해 모든 옵션이 있습니다.

동일한 engine-backup 명령에서 --scope 옵션을 여러 번 지정할 수 있습니다.

관리자 데이터베이스 옵션

다음 옵션은 복원 모드에서 engine-backup 명령을 사용하는 경우에만 사용할 수 있습니다. 아래 옵션 구문은 Manager 데이터베이스를 복원하는 데 적용됩니다. 데이터 웨어하우스 데이터베이스를 복원하는 데도 동일한 옵션이 있습니다. 데이터 웨어하우스 옵션 구문은 engine-backup --help 를 참조하십시오.

--provision-db: 복원할 Manager 데이터베이스 백업에 사용할 PostgreSQL 데이터베이스를 생성합니다. 이 옵션은 원격 호스트 또는 PostgreSQL 데이터베이스가 아직 구성되지 않은 새로운 설치에서 백업을 복원할 때 필수 옵션입니다. 이 옵션을 복원 모드에서 사용하면 기본적으로 --restore-permissions 옵션이 추가됩니다.
--provision-all-databases: 아카이브에 포함된 모든 메모리 덤프에 대한 데이터베이스를 생성합니다. 이 값을 활성화하면 기본값이 됩니다.
--change-db-credentials: 백업 자체에 저장된 자격 증명 이외의 자격 증명을 사용하여 Manager 데이터베이스를 복원하기 위한 대체 자격 증명을 지정할 수 있습니다. 이 옵션에 필요한 추가 매개변수는 engine-backup --help 를 참조하십시오.
--restore-permissions 또는 --no-restore-permissions: 데이터베이스 사용자의 권한을 복원하거나 복원하지 않습니다. 백업을 복원할 때 이러한 옵션 중 하나가 필요합니다. 복원 모드에서 --provision-* 옵션을 사용하면 기본적으로 --restore-permissions 가 적용됩니다.
참고
백업에 추가 데이터베이스 사용자에 대한 부여가 포함된 경우 --restore-permissions 및 --provision-db (또는 --provision-dwh-db) 옵션으로 백업을 복원하면 임의의 암호가 있는 추가 사용자가 생성됩니다. 추가 사용자가 복원된 시스템에 액세스해야 하는 경우 이러한 암호를 수동으로 변경해야 합니다. 백업에서 Red Hat Virtualization을 복원한 후 추가 데이터베이스 사용자에게 액세스 권한을 부여하는 방법을 참조하십시오.

3.2.1.3. engine-backup 명령으로 백업 생성

Manager가 활성화된 동안 engine-backup 명령을 사용하여 Red Hat Virtualization Manager를 백업할 수 있습니다. 백업할 항목을 지정하려면 다음 값 중 하나를 --scope 옵션에 추가합니다.

all: Manager에서 모든 데이터베이스 및 구성 파일의 전체 백업입니다. 이 설정은 --scope 옵션의 기본 설정입니다.
파일: 시스템의 파일 만 백업
db: Manager 데이터베이스만 백업
dwhdb: 데이터 웨어하우스 데이터베이스만 백업
cinderlibdb: Cinderlib 데이터베이스만 백업
grafanadb: Grafana 데이터베이스만 백업

--scope 옵션을 두 번 이상 지정할 수 있습니다.

추가 파일을 백업하도록 engine-backup 명령을 구성할 수도 있습니다. 백업하는 모든 항목을 복원합니다.

중요

Red Hat Virtualization Manager의 새로운 설치에 데이터베이스를 복원하려면 데이터베이스 백업만으로는 충분하지 않습니다. Manager는 구성 파일에 대한 액세스도 필요합니다. all 이외의 범위를 지정하는 경우 --scope=files 를 포함하거나 파일 시스템을 백업해야 합니다.

engine-backup 명령에 대한 전체 설명을 보려면 Manager 시스템에 engine-backup --help 를 입력하십시오.

절차

Manager 시스템에 로그인합니다.
백업을 생성합니다.
```
# engine-backup
```

다음 설정은 기본적으로 적용됩니다.

--scope=all

--mode=backup

이 명령은 /var/lib/ovirt-engine-backup/file_name.backup 에 백업을 생성하고 /var/log/ovirt-engine-backup/log_file_name 에 로그 파일을 생성합니다.

file_name.tar 을 사용하여 환경을 복원합니다.

다음 예제에서는 여러 가지 백업 시나리오를 보여줍니다.

예 3.1. 전체 백업

# engine-backup

예 3.2. 데이터베이스 백업 관리자

# engine-backup --scope=files --scope=db

예 3.3. 데이터 웨어하우스 데이터베이스 백업

# engine-backup --scope=files --scope=dwhdb

예 3.4. 백업에 특정 파일 추가

engine-backup 명령에 대한 구성 사용자 지정을 저장할 디렉터리를 만듭니다.
```
# mkdir -p /etc/ovirt-engine-backup/engine-backup-config.d
```
다음 내용을 사용하여 새 디렉터리에 ntp-chrony.sh 라는 텍스트 파일을 생성합니다.
```
BACKUP_PATHS="${BACKUP_PATHS}
/etc/chrony.conf
/etc/ntp.conf
/etc/ovirt-engine-backup"
```
engine-backup 명령을 실행할 때 --scope=files 를 사용합니다. 백업 및 복원에는 /etc/chrony.conf,/etc/ntp.conf, /etc/ovirt-engine-backup 이 포함됩니다.

3.2.1.4. engine-backup 명령을 사용하여 백업 복원

engine-backup 명령을 사용하여 백업을 복원하려면 복원 대상에 따라 백업을 생성하는 것보다 더 많은 단계가 필요합니다. 예를 들어 engine-backup 명령을 사용하여 Red Hat Virtualization의 기존 설치 위에 새로 설치한 Red Hat Virtualization 설치의 백업을 복원하고 로컬 또는 원격 데이터베이스를 사용할 수 있습니다.

중요

백업을 복원하는 데 사용되는 Red Hat Virtualization Manager 버전 (예: 4.4.8)은 백업을 생성하는 데 사용되는 Red Hat Virtualization Manager 버전 (예: 4.4.7) 이상이어야 합니다. Red Hat Virtualization 4.4.7부터 이 정책은 engine-backup 명령에 의해 엄격하게 적용됩니다. 백업 파일에 포함된 Red Hat Virtualization 버전을 보려면 백업 파일의 압축을 풀고 압축을 푼 파일의 루트 디렉터리에 있는 버전 파일의 값을 읽습니다.

3.2.1.5. 이전 설치로 백업 복원

engine-backup 명령을 사용하여 Red Hat Virtualization Manager의 새로운 설치로 백업을 복원할 수 있습니다. 다음 절차는 기본 운영 체제가 설치되어 있고 Red Hat Virtualization Manager에 필요한 패키지가 설치되었지만 engine-setup 명령이 아직 실행되지 않은 시스템에서 수행해야 합니다. 이 절차에서는 백업을 복원할 시스템에서 백업 파일 또는 파일에 액세스할 수 있다고 가정합니다.

절차

Manager 시스템에 로그인합니다. 엔진 데이터베이스를 원격 호스트에 복원하는 경우 에 로그인하고 해당 호스트에서 관련 작업을 수행해야 합니다. 마찬가지로 데이터 웨어하우스를 원격 호스트로 복원하는 경우에도 에 로그인하고 해당 호스트에서 관련 작업을 수행해야 합니다.
전체 백업 또는 데이터베이스 전용 백업을 복원합니다.
- 전체 백업을 복원하십시오.
```
# engine-backup --mode=restore --file=file_name --log=log_file_name --provision-db
```
  복원 모드에서 --provision-* 옵션을 사용하면 기본적으로 --restore-permissions 가 적용됩니다.
  데이터 웨어하우스가 전체 백업의 일부로 복원되는 경우 추가 데이터베이스를 프로비저닝합니다.
```
engine-backup --mode=restore --file=file_name --log=log_file_name --provision-db --provision-dwh-db
```
- 구성 파일과 데이터베이스 백업을 복원하여 데이터베이스 전용 백업을 복원합니다.
```
# engine-backup --mode=restore --scope=files --scope=db --file=file_name --log=log_file_name --provision-db
```
  위의 예제에서는 Manager 데이터베이스의 백업을 복원합니다.
```
# engine-backup --mode=restore --scope=files --scope=dwhdb --file=file_name --log=log_file_name --provision-dwh-db
```
  위의 예제에서는 데이터 웨어하우스 데이터베이스의 백업을 복원합니다.
  성공하면 다음 출력이 표시됩니다.
```
You should now run engine-setup.
Done.
```
다음 명령을 실행하고 프롬프트에 따라 복원된 관리자를 구성합니다.
```
# engine-setup
```

Red Hat Virtualization Manager가 백업에 보존된 버전으로 복원되었습니다. 새로운 Red Hat Virtualization 시스템의 정규화된 도메인 이름을 변경하려면 oVirt Engine Rename Tool 을 참조하십시오.

3.2.1.6. 기존 설치를 덮어쓰도록 백업 복원

engine-backup 명령을 사용하면 Red Hat Virtualization Manager가 이미 설치되어 설정된 머신에 백업을 복원할 수 있습니다. 이 기능은 환경을 백업하고 해당 환경에 대한 변경 사항을 수행한 다음 백업에서 환경을 복원하여 변경 사항을 취소하려는 경우에 유용합니다.

호스트 추가 또는 제거와 같은 백업이 수행되었으므로 환경의 변경 사항이 복원된 환경에 표시되지 않습니다. 이러한 변경 사항을 다시 실행해야 합니다.

절차

Manager 시스템에 로그인합니다.
구성 파일을 제거하고 Manager와 연결된 데이터베이스를 정리합니다.
```
# engine-cleanup
```
engine-cleanup 명령은 관리자 데이터베이스만 정리합니다. 데이터베이스를 삭제하거나 해당 데이터베이스를 소유한 사용자를 삭제하지 않습니다.
전체 백업 또는 데이터베이스 전용 백업을 복원합니다. 사용자와 데이터베이스가 이미 있으므로 새 데이터베이스를 만들거나 데이터베이스 자격 증명을 지정할 필요가 없습니다.
- 전체 백업을 복원하십시오.
```
# engine-backup --mode=restore --file=file_name --log=log_file_name --restore-permissions
```
- 구성 파일과 데이터베이스 백업을 복원하여 데이터베이스 전용 백업을 복원합니다.
```
# engine-backup --mode=restore --scope=files --scope=db --scope=dwhdb --file=file_name --log=log_file_name --restore-permissions
```
  참고
  Manager 데이터베이스만 복원하려면(예: 데이터 웨어하우스 데이터베이스가 다른 시스템에 있는 경우) --scope=dwhdb 매개 변수를 생략하면 됩니다.
  성공하면 다음 출력이 표시됩니다.
```
You should now run engine-setup.
Done.
```
Manager를 재구성합니다.
```
# engine-setup
```

3.2.1.7. 다른 인증 정보를 사용하여 백업 복원

engine-backup 명령은 Red Hat Virtualization Manager가 이미 설치 및 설정된 머신에 백업을 복원할 수 있지만 백업의 데이터베이스 자격 증명은 백업을 복원할 시스템의 데이터베이스와 다릅니다. 이 기능은 설치 백업을 수행하고 백업에서 다른 시스템으로 설치를 복원하려는 경우에 유용합니다.

중요

기존 설치를 덮어쓰도록 백업을 복원할 때는 engine- backup 명령을 사용하기 전에 engine -cleanup 명령을 실행하여 기존 설치를 정리해야 합니다. engine-cleanup 명령은 엔진 데이터베이스만 정리하며 데이터베이스를 삭제하거나 해당 데이터베이스를 소유한 사용자를 삭제하지 않습니다. 따라서 새 데이터베이스를 만들거나 데이터베이스 자격 증명을 지정할 필요가 없습니다. 그러나 엔진 데이터베이스의 소유자 자격 증명을 알 수 없는 경우 백업을 복원하기 전에 변경해야 합니다.

절차

Red Hat Virtualization Manager 시스템에 로그인합니다.
다음 명령을 실행하고 프롬프트에 따라 Manager의 구성 파일을 제거하고 Manager의 데이터베이스를 정리합니다.
```
# engine-cleanup
```
해당 사용자의 자격 증명을 알 수 없는 경우 엔진 데이터베이스의 소유자 암호를 변경합니다.
1. postgresql 명령줄을 입력합니다.
```
# su - postgres -c 'psql'
```
2. 엔진 데이터베이스를 소유한 사용자의 암호를 변경합니다.
```
postgres=# alter role user_name encrypted password 'new_password';
```
  필요한 경우 ovirt_engine_history 데이터베이스를 소유한 사용자에 대해 이 작업을 반복합니다.
change- db-credentials 매개변수를 사용하여 전체 백업 또는 데이터베이스 전용 백업을 복원하여 새 데이터베이스의 자격 증명을 전달합니다. Manager에 로컬로 있는 데이터베이스의 database _location 은 localhost 입니다.
참고
다음 예제에서는 암호를 지정하지 않고 각 데이터베이스에 대해 --*password 옵션을 사용하여 각 데이터베이스의 암호를 묻는 메시지를 표시합니다. 또는 각 데이터베이스에 대해 --*passfile=password_file 옵션을 사용하여 대화형 프롬프트 없이도 engine-backup 도구에 암호를 안전하게 전달할 수 있습니다.
- 전체 백업을 복원하십시오.
```
# engine-backup --mode=restore --file=file_name --log=log_file_name --change-db-credentials --db-host=database_location --db-name=database_name --db-user=engine --db-password --no-restore-permissions
```
  데이터 웨어하우스가 전체 백업의 일부로 복원되는 경우 추가 데이터베이스에 대한 수정된 인증 정보를 포함합니다.
```
engine-backup --mode=restore --file=file_name --log=log_file_name --change-db-credentials --db-host=database_location --db-name=database_name --db-user=engine --db-password --change-dwh-db-credentials --dwh-db-host=database_location --dwh-db-name=database_name --dwh-db-user=ovirt_engine_history --dwh-db-password --no-restore-permissions
```
- 구성 파일과 데이터베이스 백업을 복원하여 데이터베이스 전용 백업을 복원합니다.
```
# engine-backup --mode=restore --scope=files --scope=db --file=file_name --log=log_file_name --change-db-credentials --db-host=database_location --db-name=database_name --db-user=engine --db-password --no-restore-permissions
```
  위의 예제에서는 Manager 데이터베이스의 백업을 복원합니다.
```
# engine-backup --mode=restore --scope=files --scope=dwhdb --file=file_name --log=log_file_name --change-dwh-db-credentials --dwh-db-host=database_location --dwh-db-name=database_name --dwh-db-user=ovirt_engine_history --dwh-db-password --no-restore-permissions
```
  위의 예제에서는 데이터 웨어하우스 데이터베이스의 백업을 복원합니다.
  성공하면 다음 출력이 표시됩니다.
```
You should now run engine-setup.
Done.
```
다음 명령을 실행하고 프롬프트에 따라 방화벽을 재구성하고 ovirt-engine 서비스가 올바르게 구성되었는지 확인합니다.
```
# engine-setup
```

3.2.1.8. 자체 호스팅 엔진 백업 및 복원

자체 호스팅 엔진을 백업하고 새로운 자체 호스팅 환경에서 복원할 수 있습니다. 환경을 다른 스토리지 유형의 새로운 자체 호스팅 엔진 스토리지 도메인으로 마이그레이션하는 등의 작업을 수행하려면 다음 절차를 사용하십시오.

배포 중에 백업 파일을 지정하면 자체 호스팅 엔진 스토리지 도메인과 함께 새 Manager 가상 시스템에 백업이 복원됩니다. 이전 관리자가 제거되고 기존의 자체 호스팅 엔진 스토리지 도메인의 이름이 변경되며 새 환경이 올바르게 작동하는지 확인한 후 수동으로 제거할 수 있습니다. 새 호스트에 배포하는 것이 좋습니다. 백업된 환경에 배포에 사용된 호스트가 있는 경우 새 환경의 충돌을 피하기 위해 복원된 데이터베이스에서 제거됩니다. 새 호스트에 배포하는 경우 고유한 이름을 호스트에 할당해야 합니다. 백업에 포함된 기존 호스트의 이름을 재사용하면 새 환경에서 충돌이 발생할 수 있습니다.

백업 및 복원 작업에는 다음과 같은 주요 작업이 포함됩니다.

이 절차에서는 액세스 권한이 있다고 가정하고 원래 관리자를 변경할 수 있습니다.

사전 요구 사항

관리자와 호스트에 대해 준비된 정규화된 도메인 이름입니다. 정방향 및 역방향 조회 레코드는 모두 DNS에 설정해야 합니다. 새 관리자는 원래 Manager와 동일한 정규화된 도메인 이름을 가져야 합니다.
원래 관리자는 최신 마이너 버전으로 업데이트해야 합니다. 백업을 복원하는 데 사용되는 Red Hat Virtualization Manager 버전 (예: 4.4.8)은 백업을 생성하는 데 사용되는 Red Hat Virtualization Manager 버전 (예: 4.4.7) 이상이어야 합니다. Red Hat Virtualization 4.4.7부터 이 정책은 engine-backup 명령에 의해 엄격하게 적용됩니다. 업그레이드 가이드에서 Red Hat Virtualization Manager 업데이트를 참조하십시오.
참고
백업을 복원해야 하지만 새 어플라이언스가 없으면 복원 프로세스가 일시 중지되고 SSH를 통해 임시 관리자 시스템에 로그인하고 필요에 따라 채널을 등록하고, 관리자 패키지를 업그레이드한 후 복원 프로세스를 다시 시작할 수 있습니다.
업데이트된 스토리지 버전과의 호환성을 보장하려면 데이터 센터 호환성 수준을 최신 버전으로 설정해야 합니다.
환경에는 하나 이상의 일반 호스트가 있어야 합니다. 이 호스트(및 기타 일반 호스트)는 SPM 역할 및 실행 중인 가상 시스템을 호스팅하도록 활성 상태로 유지됩니다. 일반 호스트가 아직 SPM이 아닌 경우 일반 호스트를 선택하고 Management Select as SPM(SPM 선택)을 클릭하여 백업을 만들기 전에 SPM 역할을 이동합니다.
일반 호스트를 사용할 수 없는 경우 다음 두 가지 방법으로 호스트를 추가할 수 있습니다.
- 노드에서 자체 호스팅 엔진 구성을 제거합니다(하지만 환경에서 노드를 제거하지 마십시오). 셀프 호스트 엔진 환경에서 호스트 제거를 참조하십시오.
- 새 일반 호스트를 추가합니다. Manager 호스트 작업에 표준 호스트 추가를 참조하십시오.

3.2.1.8.1. 원래 관리자 백업

engine-backup 명령을 사용하여 원래 관리자를 백업하고, 프로세스 중 언제라도 액세스할 수 있도록 백업 파일을 별도의 위치에 복사합니다.

engine-backup --mode=backup 옵션에 대한 자세한 내용은 관리 가이드의 Backing Up 및 Restoring the Red Hat Virtualization Manager 를 참조하십시오.

절차

셀프 호스트 엔진 노드 중 하나에 로그인하여 환경을 전역 유지 관리 모드로 이동합니다.
```
# hosted-engine --set-maintenance --mode=global
```
원래 관리자에 로그인하여 ovirt-engine 서비스를 중지합니다.
```
# systemctl stop ovirt-engine
# systemctl disable ovirt-engine
```
참고
원래 관리자가 실행되지 않도록 중지하는 것은 필수 사항이 아니지만 백업을 만든 후 환경을 변경하지 않도록 하는 것이 좋습니다. 또한 원래 관리자와 새 관리자가 기존 리소스를 동시에 관리하지 못하게 합니다.
engine-backup 명령을 실행하여 생성할 백업 파일의 이름과 백업 로그를 저장하도록 만들 로그 파일의 이름을 지정합니다.
```
# engine-backup --mode=backup --file=file_name --log=log_file_name
```
파일을 외부 서버에 복사합니다. 다음 예에서 storage.example.com 은 필요할 때까지 백업을 저장할 네트워크 스토리지 서버의 정규화된 도메인 이름이며 /backup/ 는 지정된 폴더 또는 경로입니다.
```
# scp -p file_name log_file_name storage.example.com:/backup/
```
다른 용도로 관리자 시스템이 필요하지 않은 경우 Red Hat 서브스크립션 관리자에서 등록 취소합니다.
```
# subscription-manager unregister
```
자체 호스팅 엔진 노드 중 하나에 로그인하고 원래 Manager 가상 머신을 종료합니다.
```
# hosted-engine --vm-shutdown
```

Manager를 백업한 후 새 자체 호스팅 엔진을 배포하고 새 가상 시스템에 백업을 복원합니다.

3.2.1.8.2. 새로운 자체 호스팅 엔진에서 백업 복원

새 호스트에서 hosted-engine 스크립트를 실행하고 --restore-from-file=path/to/file_name 옵션을 사용하여 배포 중에 Manager 백업을 복원합니다.

중요

iSCSI 스토리지를 사용하고 있고 iSCSI 대상에서 이니시에이터의 ACL에 따라 연결을 필터링하는 경우 STORAGE_DOMAIN_UNREACHABLE 오류로 배포가 실패할 수 있습니다. 이 문제를 방지하려면 자체 호스팅 엔진 배포를 시작하기 전에 iSCSI 구성을 업데이트해야 합니다.

기존 호스트에 재배포하는 경우 /etc/iscsi/initiatorname.iscsi 에서 호스트의 iSCSI 이니시에이터 설정을 업데이트해야 합니다. 이니시에이터 IQN은 이전에 iSCSI 타겟에 매핑된 것과 동일하거나 해당하는 경우 새 IQN으로 업데이트되어야 합니다.
새 호스트에 배포하는 경우 해당 호스트의 연결을 수락하도록 iSCSI 대상 구성을 업데이트해야 합니다.

IQN은 호스트 측(iSCSI 이니시에이터) 또는 스토리지 측(iSCSI 대상)에서 업데이트할 수 있습니다.

절차

백업 파일을 새 호스트에 복사합니다. 다음 예에서 host.example.com 은 호스트의 FQDN이며 /backup/ 는 지정된 폴더 또는 경로입니다.
```
# scp -p file_name host.example.com:/backup/
```
새 호스트에 로그인합니다.
Red Hat Virtualization Host에 배포하는 경우 ovirt-hosted-engine-setup 이 이미 설치되어 있으므로 이 단계를 건너뜁니다. Red Hat Enterprise Linux에 배포하는 경우 ovirt-hosted-engine-setup 패키지를 설치합니다.
```
# dnf install ovirt-hosted-engine-setup
```
네트워크 또는 터미널 중단 시 세션 손실을 방지하기 위해 tmux 창 관리자를 사용하여 스크립트를 실행합니다.
tmux 를 설치하고 실행합니다.
```
# dnf -y install tmux
# tmux
```
백업 파일의 경로를 지정하여 hosted-engine 스크립트를 실행합니다.
```
# hosted-engine --deploy --restore-from-file=backup/file_name
```
언제든지 스크립트를 이스케이프하려면 CTRL+D 를 사용하여 배포를 중단합니다.
Yes (예)를 선택하여 배포를 시작합니다.
네트워크를 구성합니다. 스크립트는 환경에 대한 관리 브리지로 사용할 수 있는 NIC를 탐지합니다.
가상 머신 설치에 사용자 지정 어플라이언스를 사용하려면 OVA 아카이브 경로를 입력합니다. 그렇지 않으면 RHV-M 어플라이언스를 사용하려면 이 필드를 비워 둡니다.
Manager의 루트 암호를 입력합니다.
root 사용자로 Manager에 로그인할 수 있는 SSH 공개 키를 입력하고 root 사용자에 대해 SSH 액세스를 활성화할지 여부를 지정합니다.
가상 시스템의 CPU 및 메모리 구성을 입력합니다.
Manager 가상 시스템의 MAC 주소를 입력하거나 무작위로 생성된 가상 시스템의 수락을 수락합니다. DHCP를 통해 Manager 가상 머신에 IP 주소를 제공하려면 이 MAC 주소에 유효한 DHCP 예약이 있는지 확인합니다. 배포 스크립트는 DHCP 서버를 구성하지 않습니다.
가상 시스템의 네트워킹 세부 정보를 입력합니다. 정적을 지정하는 경우 Manager의 IP 주소를 입력합니다.
중요
정적 IP 주소는 호스트와 동일한 서브넷에 속해야 합니다. 예를 들어 호스트가 10.1.1.0/24에 있는 경우 Manager 가상 시스템의 IP는 동일한 서브넷 범위(10.1.1.1-254/24)에 있어야 합니다.
Manager 가상 시스템 및 기본 호스트에 대한 항목을 가상 시스템의 /etc/hosts 파일에 추가할지 여부를 지정합니다. 호스트 이름을 확인할 수 있는지 확인해야 합니다.
SMTP 서버의 이름 및 TCP 포트 번호, 이메일 알림을 보내는 데 사용되는 이메일 주소 및 이러한 알림을 수신하기 위해 쉼표로 구분된 이메일 주소 목록을 제공합니다.
admin@internal 사용자의 암호를 입력하여 관리 포털에 액세스합니다.
이 스크립트는 가상 시스템을 생성합니다. RHV-M 어플라이언스를 설치해야 하는 경우 다소 시간이 걸릴 수 있습니다.
참고
필수 네트워크 또는 유사한 문제가 없어 호스트가 작동하지 않는 경우 배포가 일시 중지되고 다음과 같은 메시지가 표시됩니다.
```
[ INFO  ] You can now connect to https://<host name>:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up'
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file]
[ INFO  ] changed: [localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.<random>_he_setup_lock is removed, delete it once ready to proceed]
```
프로세스를 일시 중지하면 다음을 수행할 수 있습니다.
- 제공된 URL을 사용하여 관리 포털에 연결합니다.
- 상황을 평가하고 호스트가 작동하지 않는 이유를 확인하고 필요한 사항을 수정합니다. 예를 들어 이 배포가 백업에서 복원되고 호스트 클러스터에 필요한 네트워크가 포함된 백업이 네트워크를 구성하여 관련 호스트 NIC를 이러한 네트워크에 연결합니다.
- 모든 항목이 확인되고 호스트 상태가 Up 이면 위의 메시지에 표시된 잠금 파일을 제거합니다. 배포는 계속됩니다.
사용할 스토리지 유형을 선택합니다.
- NFS의 경우 버전, 전체 주소 및 스토리지의 경로 및 모든 마운트 옵션을 입력합니다.
  주의
  가상 시스템 데이터가 손실될 위험이 있으므로 기존의 자체 호스팅 엔진 스토리지 도메인의 마운트 지점을 새 스토리지 도메인에 사용하지 마십시오.
- iSCSI의 경우 포털 세부 정보를 입력하고 자동 감지 목록에서 대상 및 LUN을 선택합니다. 배포 중에 하나의 iSCSI 대상만 선택할 수 있지만 다중 경로는 동일한 포털 그룹의 모든 포털을 연결하도록 지원됩니다.
  참고
  iSCSI 대상을 두 개 이상 지정하려면 셀프 호스트 엔진을 배포하기 전에 다중 경로를 활성화해야 합니다. 자세한 내용은 Red Hat Enterprise Linux DM Multipath 를 참조하십시오. 다양한 옵션으로 다중 경로를 설치하고 구성하는 스크립트를 생성하는 Multipath Helper 툴도 있습니다.
- Gluster 스토리지의 경우 전체 주소와 스토리지 경로 및 모든 마운트 옵션을 입력합니다.
  주의
  가상 시스템 데이터가 손실될 위험이 있으므로 기존의 자체 호스팅 엔진 스토리지 도메인의 마운트 지점을 새 스토리지 도메인에 사용하지 마십시오.
  중요
  복제본 1과 복제본 3 Gluster 스토리지만 지원됩니다. 다음과 같이 볼륨을 구성했는지 확인합니다.
  gluster volume set VOLUME_NAME group virt gluster volume set VOLUME_NAME performance.strict-o-direct on gluster volume set VOLUME_NAME network.remote-dio off gluster volume set VOLUME_NAME storage.owner-uid 36 gluster volume set VOLUME_NAME storage.owner-gid 36 gluster volume set VOLUME_NAME network.ping-timeout 30
- 파이버 채널의 경우 자동 감지 목록에서 LUN을 선택합니다. 호스트 버스 어댑터를 구성하고 연결해야 하며 LUN에 기존 데이터가 없어야 합니다. 기존 LUN을 재사용하려면 관리 가이드에서 LUN 재사용 을 참조하십시오.
Manager 디스크 크기를 입력합니다.
스크립트는 배포가 완료될 때까지 계속됩니다.
배포 프로세스는 관리자의 SSH 키를 변경합니다. 클라이언트 시스템이 SSH 오류 없이 새 관리자에 액세스할 수 있도록 하려면 원래 관리자에 액세스한 클라이언트 시스템에서 .ssh/known_hosts 파일에서 원래 관리자 항목을 제거하십시오.

배포가 완료되면 새 Manager 가상 시스템에 로그인하고 필요한 리포지토리를 활성화합니다.

3.2.1.8.3. Red Hat Virtualization Manager 리포지토리 활성화

Red Hat Subscription Manager에 관리자 시스템에 로그인하고 등록하고 Red Hat Virtualization Manager 서브스크립션을 연결한 다음 Manager 리포지토리를 활성화해야 합니다.

절차

시스템을 Content Delivery Network에 등록하고 메시지가 표시되면 고객 포털 사용자 이름과 암호를 입력합니다.
```
# subscription-manager register
```
참고
IPv6 네트워크를 사용하는 경우 IPv6 전환 메커니즘을 사용하여 콘텐츠 전달 네트워크 및 서브스크립션 관리자에게 액세스합니다.
Red Hat Virtualization Manager 서브스크립션 풀을 찾아 풀 ID를 기록합니다.
```
# subscription-manager list --available
```
풀 ID를 사용하여 서브스크립션을 시스템에 연결합니다.
```
# subscription-manager attach --pool=pool_id
```
참고
현재 첨부된 서브스크립션을 보려면 다음을 수행합니다.
```
# subscription-manager list --consumed
```
활성화된 리포지토리를 모두 나열하려면 다음을 수행합니다.
```
# dnf repolist
```

리포지토리를 구성합니다.

# subscription-manager repos \
    --disable='*' \
    --enable=rhel-8-for-x86_64-baseos-eus-rpms \
    --enable=rhel-8-for-x86_64-appstream-eus-rpms \
    --enable=rhv-4.4-manager-for-rhel-8-x86_64-rpms \
    --enable=fast-datapath-for-rhel-8-x86_64-rpms \
    --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms \
    --enable=openstack-16.2-cinderlib-for-rhel-8-x86_64-rpms \
    --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms

RHEL 버전을 8.6으로 설정합니다.
```
# subscription-manager release --set=8.6
```
pki-deps 모듈을 활성화합니다.
```
# dnf module -y enable pki-deps
```
postgresql 모듈 버전 12를 활성화합니다.
```
# dnf module -y enable postgresql:12
```
nodejs 모듈의 버전 14를 활성화합니다.
```
# dnf module -y enable nodejs:14
```
설치된 패키지를 동기화하여 사용 가능한 최신 버전으로 업데이트합니다.
```
# dnf distro-sync --nobest
```

추가 리소스

모듈 및 모듈 스트림에 대한 자세한 내용은 사용자 공간 구성 요소 설치, 관리 및 제거의 다음 섹션을 참조하십시오.

이제 Manager와 해당 리소스가 자체 호스팅 환경에서 실행됩니다. 자체 호스팅 엔진 구성을 업데이트하려면 Manager에 자체 호스팅 엔진 노드를 다시 설치해야 합니다. 표준 호스트는 영향을 받지 않습니다. 각 셀프 호스트 엔진 노드에 대해 다음 절차를 수행합니다.

3.2.1.8.4. 호스트 재설치

관리 포털에서 RHVH(Red Hat Virtualization Host) 및 Red Hat Enterprise Linux 호스트를 다시 설치합니다. 절차에는 호스트를 중지하고 다시 시작하는 작업이 포함됩니다.

주의

호스트 운영 체제를 설치하거나 다시 설치하는 경우 먼저 이러한 디스크를 실수로 초기화하지 않도록 호스트에 연결된 기존 비OS 스토리지를 분리하는 것이 좋습니다.

사전 요구 사항

클러스터의 마이그레이션이 활성화된 경우 가상 시스템은 클러스터의 다른 호스트로 자동 마이그레이션할 수 있습니다. 따라서 사용량이 상대적으로 낮은 상태에서 호스트를 다시 설치합니다.
클러스터에 호스트에서 유지 관리를 수행할 수 있는 메모리가 충분한지 확인합니다. 클러스터에 메모리가 없으면 가상 시스템 마이그레이션이 중단되고 실패합니다. 메모리 사용량을 줄이려면 호스트를 유지 관리로 이동하기 전에 일부 또는 모든 가상 시스템을 종료합니다.
재설치를 수행하기 전에 클러스터에 호스트가 두 개 이상 포함되어 있는지 확인합니다. 모든 호스트를 동시에 다시 설치하지 마십시오. 스토리지 풀 관리자(SPM) 작업을 수행하려면 하나의 호스트를 사용할 수 있어야 합니다.

절차

Compute(컴퓨팅) Hosts(호스트 ) 를 클릭하고 호스트를 선택합니다.
Management(관리 Maintenance (유지 관리) 및 OK (확인)를 클릭합니다.
Installation Reinstall (재설치)을 클릭합니다. 그러면 Install Host(호스트 설치) 창이 열립니다.
Hosted Engine(호스팅 엔진 ) 탭을 클릭하고 드롭다운 목록에서 DEPLOY (배포)를 선택합니다.
OK(확인 )를 클릭하여 호스트를 다시 설치합니다.

호스트를 다시 설치하고 해당 상태가 Up 으로 돌아간 후 가상 시스템을 호스트로 다시 마이그레이션할 수 있습니다.

중요

Red Hat Virtualization Host를 Red Hat Virtualization Manager에 등록하고 다시 설치한 후 관리 포털에 Install Failed (설치 실패) 상태로 잘못 표시될 수 있습니다. Management(관리 Activate (활성화) 를 클릭하면 호스트가 Up 상태로 변경되고 사용할 준비가 됩니다.

자체 호스팅 엔진 노드를 다시 설치한 후 노드 중 하나에서 다음 명령을 실행하여 새 환경의 상태를 확인할 수 있습니다.

# hosted-engine --vm-status

복원하는 동안 기존의 자체 호스팅 엔진 스토리지 도메인의 이름이 변경되었지만 복원에 문제가 있는 경우 새 환경에서 제거되지 않았습니다. 환경이 정상적으로 실행 중인지 확인한 후 기존의 자체 호스팅 엔진 스토리지 도메인을 제거할 수 있습니다.

3.2.1.8.5. 스토리지 도메인 제거

데이터 센터에 가상화된 환경에서 제거하려는 스토리지 도메인이 있습니다.

절차

Storage(스토리지 Domains (도메인) 를 클릭합니다.
스토리지 도메인을 유지 관리 모드로 이동하고 분리합니다.
1. 스토리지 도메인의 이름을 클릭합니다. 그러면 세부 정보 보기가 열립니다.
2. Data Center(데이터 센터 ) 탭을 클릭합니다.
3. Maintenance(유지 관리 )를 클릭한 다음 OK(확인 )를 클릭합니다.
4. Detach(분리) 를 클릭한 다음 OK(확인 )를 클릭합니다.
Remove(제거)를 클릭합니다.
선택적으로 Format Domain(형식 도메인)을 선택합니다. 즉, 스토리지 콘텐츠가 손실됩니다! 도메인의 내용을 지우려면 확인란을 선택합니다.
OK(확인)를 클릭합니다.

스토리지 도메인은 환경에서 영구적으로 제거됩니다.

3.2.1.9. 기존 백업에서 자체 호스팅 엔진 복구

복구할 수 없는 문제로 인해 자체 호스팅 엔진을 사용할 수 없는 경우 문제가 발생하기 전에 수행한 백업을 사용하여 새로운 자체 호스팅 환경에서 복원할 수 있습니다(사용 가능한 경우).

자체 호스팅 엔진을 복원하려면 다음과 같은 주요 작업이 포함됩니다.

이 절차에서는 원래 관리자에 대한 액세스 권한이 없고 새 호스트에서 백업 파일에 액세스할 수 있다고 가정합니다.

사전 요구 사항

관리자와 호스트에 대해 준비된 정규화된 도메인 이름입니다. 정방향 및 역방향 조회 레코드는 모두 DNS에 설정해야 합니다. 새 관리자는 원래 Manager와 동일한 정규화된 도메인 이름을 가져야 합니다.

3.2.1.9.1. 새로운 자체 호스팅 엔진에서 백업 복원

새 호스트에서 hosted-engine 스크립트를 실행하고 --restore-from-file=path/to/file_name 옵션을 사용하여 배포 중에 Manager 백업을 복원합니다.

중요

기존 호스트에 재배포하는 경우 /etc/iscsi/initiatorname.iscsi 에서 호스트의 iSCSI 이니시에이터 설정을 업데이트해야 합니다. 이니시에이터 IQN은 이전에 iSCSI 타겟에 매핑된 것과 동일하거나 해당하는 경우 새 IQN으로 업데이트되어야 합니다.
새 호스트에 배포하는 경우 해당 호스트의 연결을 수락하도록 iSCSI 대상 구성을 업데이트해야 합니다.

IQN은 호스트 측(iSCSI 이니시에이터) 또는 스토리지 측(iSCSI 대상)에서 업데이트할 수 있습니다.

절차

백업 파일을 새 호스트에 복사합니다. 다음 예에서 host.example.com 은 호스트의 FQDN이며 /backup/ 는 지정된 폴더 또는 경로입니다.
```
# scp -p file_name host.example.com:/backup/
```
새 호스트에 로그인합니다.
Red Hat Virtualization Host에 배포하는 경우 ovirt-hosted-engine-setup 이 이미 설치되어 있으므로 이 단계를 건너뜁니다. Red Hat Enterprise Linux에 배포하는 경우 ovirt-hosted-engine-setup 패키지를 설치합니다.
```
# dnf install ovirt-hosted-engine-setup
```
네트워크 또는 터미널 중단 시 세션 손실을 방지하기 위해 tmux 창 관리자를 사용하여 스크립트를 실행합니다.
tmux 를 설치하고 실행합니다.
```
# dnf -y install tmux
# tmux
```
백업 파일의 경로를 지정하여 hosted-engine 스크립트를 실행합니다.
```
# hosted-engine --deploy --restore-from-file=backup/file_name
```
언제든지 스크립트를 이스케이프하려면 CTRL+D 를 사용하여 배포를 중단합니다.
Yes (예)를 선택하여 배포를 시작합니다.
네트워크를 구성합니다. 스크립트는 환경에 대한 관리 브리지로 사용할 수 있는 NIC를 탐지합니다.
가상 머신 설치에 사용자 지정 어플라이언스를 사용하려면 OVA 아카이브 경로를 입력합니다. 그렇지 않으면 RHV-M 어플라이언스를 사용하려면 이 필드를 비워 둡니다.
Manager의 루트 암호를 입력합니다.
root 사용자로 Manager에 로그인할 수 있는 SSH 공개 키를 입력하고 root 사용자에 대해 SSH 액세스를 활성화할지 여부를 지정합니다.
가상 시스템의 CPU 및 메모리 구성을 입력합니다.
Manager 가상 시스템의 MAC 주소를 입력하거나 무작위로 생성된 가상 시스템의 수락을 수락합니다. DHCP를 통해 Manager 가상 머신에 IP 주소를 제공하려면 이 MAC 주소에 유효한 DHCP 예약이 있는지 확인합니다. 배포 스크립트는 DHCP 서버를 구성하지 않습니다.
가상 시스템의 네트워킹 세부 정보를 입력합니다. 정적을 지정하는 경우 Manager의 IP 주소를 입력합니다.
중요
정적 IP 주소는 호스트와 동일한 서브넷에 속해야 합니다. 예를 들어 호스트가 10.1.1.0/24에 있는 경우 Manager 가상 시스템의 IP는 동일한 서브넷 범위(10.1.1.1-254/24)에 있어야 합니다.
Manager 가상 시스템 및 기본 호스트에 대한 항목을 가상 시스템의 /etc/hosts 파일에 추가할지 여부를 지정합니다. 호스트 이름을 확인할 수 있는지 확인해야 합니다.
SMTP 서버의 이름 및 TCP 포트 번호, 이메일 알림을 보내는 데 사용되는 이메일 주소 및 이러한 알림을 수신하기 위해 쉼표로 구분된 이메일 주소 목록을 제공합니다.
admin@internal 사용자의 암호를 입력하여 관리 포털에 액세스합니다.
이 스크립트는 가상 시스템을 생성합니다. RHV-M 어플라이언스를 설치해야 하는 경우 다소 시간이 걸릴 수 있습니다.
참고
필수 네트워크 또는 유사한 문제가 없어 호스트가 작동하지 않는 경우 배포가 일시 중지되고 다음과 같은 메시지가 표시됩니다.
```
[ INFO  ] You can now connect to https://<host name>:6900/ovirt-engine/ and check the status of this host and eventually remediate it, please continue only when the host is listed as 'up'
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : include_tasks]
[ INFO  ] ok: [localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Create temporary lock file]
[ INFO  ] changed: [localhost]
[ INFO  ] TASK [ovirt.ovirt.hosted_engine_setup : Pause execution until /tmp/ansible.<random>_he_setup_lock is removed, delete it once ready to proceed]
```
프로세스를 일시 중지하면 다음을 수행할 수 있습니다.
- 제공된 URL을 사용하여 관리 포털에 연결합니다.
- 상황을 평가하고 호스트가 작동하지 않는 이유를 확인하고 필요한 사항을 수정합니다. 예를 들어 이 배포가 백업에서 복원되고 호스트 클러스터에 필요한 네트워크가 포함된 백업이 네트워크를 구성하여 관련 호스트 NIC를 이러한 네트워크에 연결합니다.
- 모든 항목이 확인되고 호스트 상태가 Up 이면 위의 메시지에 표시된 잠금 파일을 제거합니다. 배포는 계속됩니다.
사용할 스토리지 유형을 선택합니다.
- NFS의 경우 버전, 전체 주소 및 스토리지의 경로 및 모든 마운트 옵션을 입력합니다.
  주의
  가상 시스템 데이터가 손실될 위험이 있으므로 기존의 자체 호스팅 엔진 스토리지 도메인의 마운트 지점을 새 스토리지 도메인에 사용하지 마십시오.
- iSCSI의 경우 포털 세부 정보를 입력하고 자동 감지 목록에서 대상 및 LUN을 선택합니다. 배포 중에 하나의 iSCSI 대상만 선택할 수 있지만 다중 경로는 동일한 포털 그룹의 모든 포털을 연결하도록 지원됩니다.
  참고
  iSCSI 대상을 두 개 이상 지정하려면 셀프 호스트 엔진을 배포하기 전에 다중 경로를 활성화해야 합니다. 자세한 내용은 Red Hat Enterprise Linux DM Multipath 를 참조하십시오. 다양한 옵션으로 다중 경로를 설치하고 구성하는 스크립트를 생성하는 Multipath Helper 툴도 있습니다.
- Gluster 스토리지의 경우 전체 주소와 스토리지 경로 및 모든 마운트 옵션을 입력합니다.
  주의
  가상 시스템 데이터가 손실될 위험이 있으므로 기존의 자체 호스팅 엔진 스토리지 도메인의 마운트 지점을 새 스토리지 도메인에 사용하지 마십시오.
  중요
  복제본 1과 복제본 3 Gluster 스토리지만 지원됩니다. 다음과 같이 볼륨을 구성했는지 확인합니다.
  gluster volume set VOLUME_NAME group virt gluster volume set VOLUME_NAME performance.strict-o-direct on gluster volume set VOLUME_NAME network.remote-dio off gluster volume set VOLUME_NAME storage.owner-uid 36 gluster volume set VOLUME_NAME storage.owner-gid 36 gluster volume set VOLUME_NAME network.ping-timeout 30
- 파이버 채널의 경우 자동 감지 목록에서 LUN을 선택합니다. 호스트 버스 어댑터를 구성하고 연결해야 하며 LUN에 기존 데이터가 없어야 합니다. 기존 LUN을 재사용하려면 관리 가이드에서 LUN 재사용 을 참조하십시오.
Manager 디스크 크기를 입력합니다.
스크립트는 배포가 완료될 때까지 계속됩니다.
배포 프로세스는 관리자의 SSH 키를 변경합니다. 클라이언트 시스템이 SSH 오류 없이 새 관리자에 액세스할 수 있도록 하려면 원래 관리자에 액세스한 클라이언트 시스템에서 .ssh/known_hosts 파일에서 원래 관리자 항목을 제거하십시오.

배포가 완료되면 새 Manager 가상 시스템에 로그인하고 필요한 리포지토리를 활성화합니다.

3.2.1.9.2. Red Hat Virtualization Manager 리포지토리 활성화

절차

시스템을 Content Delivery Network에 등록하고 메시지가 표시되면 고객 포털 사용자 이름과 암호를 입력합니다.
```
# subscription-manager register
```
참고
IPv6 네트워크를 사용하는 경우 IPv6 전환 메커니즘을 사용하여 콘텐츠 전달 네트워크 및 서브스크립션 관리자에게 액세스합니다.
Red Hat Virtualization Manager 서브스크립션 풀을 찾아 풀 ID를 기록합니다.
```
# subscription-manager list --available
```
풀 ID를 사용하여 서브스크립션을 시스템에 연결합니다.
```
# subscription-manager attach --pool=pool_id
```
참고
현재 첨부된 서브스크립션을 보려면 다음을 수행합니다.
```
# subscription-manager list --consumed
```
활성화된 리포지토리를 모두 나열하려면 다음을 수행합니다.
```
# dnf repolist
```

리포지토리를 구성합니다.

# subscription-manager repos \
    --disable='*' \
    --enable=rhel-8-for-x86_64-baseos-eus-rpms \
    --enable=rhel-8-for-x86_64-appstream-eus-rpms \
    --enable=rhv-4.4-manager-for-rhel-8-x86_64-rpms \
    --enable=fast-datapath-for-rhel-8-x86_64-rpms \
    --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms \
    --enable=openstack-16.2-cinderlib-for-rhel-8-x86_64-rpms \
    --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms

RHEL 버전을 8.6으로 설정합니다.
```
# subscription-manager release --set=8.6
```
pki-deps 모듈을 활성화합니다.
```
# dnf module -y enable pki-deps
```
postgresql 모듈 버전 12를 활성화합니다.
```
# dnf module -y enable postgresql:12
```
nodejs 모듈의 버전 14를 활성화합니다.
```
# dnf module -y enable nodejs:14
```
설치된 패키지를 동기화하여 사용 가능한 최신 버전으로 업데이트합니다.
```
# dnf distro-sync --nobest
```

추가 리소스

모듈 및 모듈 스트림에 대한 자세한 내용은 사용자 공간 구성 요소 설치, 관리 및 제거의 다음 섹션을 참조하십시오.

3.2.1.9.3. 호스트 재설치

주의

사전 요구 사항

클러스터의 마이그레이션이 활성화된 경우 가상 시스템은 클러스터의 다른 호스트로 자동 마이그레이션할 수 있습니다. 따라서 사용량이 상대적으로 낮은 상태에서 호스트를 다시 설치합니다.
클러스터에 호스트에서 유지 관리를 수행할 수 있는 메모리가 충분한지 확인합니다. 클러스터에 메모리가 없으면 가상 시스템 마이그레이션이 중단되고 실패합니다. 메모리 사용량을 줄이려면 호스트를 유지 관리로 이동하기 전에 일부 또는 모든 가상 시스템을 종료합니다.
재설치를 수행하기 전에 클러스터에 호스트가 두 개 이상 포함되어 있는지 확인합니다. 모든 호스트를 동시에 다시 설치하지 마십시오. 스토리지 풀 관리자(SPM) 작업을 수행하려면 하나의 호스트를 사용할 수 있어야 합니다.

절차

Compute(컴퓨팅) Hosts(호스트 ) 를 클릭하고 호스트를 선택합니다.
Management(관리 Maintenance (유지 관리) 및 OK (확인)를 클릭합니다.
Installation Reinstall (재설치)을 클릭합니다. 그러면 Install Host(호스트 설치) 창이 열립니다.
Hosted Engine(호스팅 엔진 ) 탭을 클릭하고 드롭다운 목록에서 DEPLOY (배포)를 선택합니다.
OK(확인 )를 클릭하여 호스트를 다시 설치합니다.

호스트를 다시 설치하고 해당 상태가 Up 으로 돌아간 후 가상 시스템을 호스트로 다시 마이그레이션할 수 있습니다.

중요

자체 호스팅 엔진 노드를 다시 설치한 후 노드 중 하나에서 다음 명령을 실행하여 새 환경의 상태를 확인할 수 있습니다.

# hosted-engine --vm-status

3.2.1.9.4. 스토리지 도메인 제거

데이터 센터에 가상화된 환경에서 제거하려는 스토리지 도메인이 있습니다.

절차

Storage(스토리지 Domains (도메인) 를 클릭합니다.
스토리지 도메인을 유지 관리 모드로 이동하고 분리합니다.
1. 스토리지 도메인의 이름을 클릭합니다. 그러면 세부 정보 보기가 열립니다.
2. Data Center(데이터 센터 ) 탭을 클릭합니다.
3. Maintenance(유지 관리 )를 클릭한 다음 OK(확인 )를 클릭합니다.
4. Detach(분리) 를 클릭한 다음 OK(확인 )를 클릭합니다.
Remove(제거)를 클릭합니다.
선택적으로 Format Domain(형식 도메인)을 선택합니다. 즉, 스토리지 콘텐츠가 손실됩니다! 도메인의 내용을 지우려면 확인란을 선택합니다.
OK(확인)를 클릭합니다.

스토리지 도메인은 환경에서 영구적으로 제거됩니다.

3.2.1.10. 기존 백업에서 자체 호스팅 엔진 덮어쓰기

자체 호스팅 엔진에 액세스할 수 있지만 데이터베이스 손상이나 롤백하기 어려운 구성 오류와 같은 문제가 발생하는 경우 문제를 시작한 백업을 사용하여 환경을 이전 상태로 복원할 수 있습니다(사용 가능한 경우).

자체 호스팅 엔진의 이전 상태를 복원하려면 다음 단계를 수행해야 합니다.

engine-backup --mode=restore 옵션에 대한 자세한 내용은 Manager 백업 및 복원을 참조하십시오.

3.2.1.10.1. 글로벌 유지 관리 모드 활성화

Manager 가상 시스템에서 설정 또는 업그레이드 작업을 수행하기 전에 자체 호스팅 엔진 환경을 전역 유지 관리 모드에 배치해야 합니다.

절차

셀프 호스트 엔진 노드 중 하나에 로그인하고 글로벌 유지 관리 모드를 활성화합니다.
```
# hosted-engine --set-maintenance --mode=global
```
계속하기 전에 환경이 글로벌 유지 관리 모드에 있는지 확인합니다.
```
# hosted-engine --vm-status
```
클러스터가 전역 유지 관리 모드에 있음을 나타내는 메시지가 표시되어야 합니다.

3.2.1.10.2. 기존 설치를 덮어쓰도록 백업 복원

절차

Manager 시스템에 로그인합니다.
구성 파일을 제거하고 Manager와 연결된 데이터베이스를 정리합니다.
```
# engine-cleanup
```
engine-cleanup 명령은 관리자 데이터베이스만 정리합니다. 데이터베이스를 삭제하거나 해당 데이터베이스를 소유한 사용자를 삭제하지 않습니다.
전체 백업 또는 데이터베이스 전용 백업을 복원합니다. 사용자와 데이터베이스가 이미 있으므로 새 데이터베이스를 만들거나 데이터베이스 자격 증명을 지정할 필요가 없습니다.
- 전체 백업을 복원하십시오.
```
# engine-backup --mode=restore --file=file_name --log=log_file_name --restore-permissions
```
- 구성 파일과 데이터베이스 백업을 복원하여 데이터베이스 전용 백업을 복원합니다.
```
# engine-backup --mode=restore --scope=files --scope=db --scope=dwhdb --file=file_name --log=log_file_name --restore-permissions
```
  참고
  Manager 데이터베이스만 복원하려면(예: 데이터 웨어하우스 데이터베이스가 다른 시스템에 있는 경우) --scope=dwhdb 매개 변수를 생략하면 됩니다.
  성공하면 다음 출력이 표시됩니다.
```
You should now run engine-setup.
Done.
```
Manager를 재구성합니다.
```
# engine-setup
```

3.2.1.10.3. 전역 유지 관리 모드 비활성화

절차

Manager 가상 시스템에 로그인하여 종료합니다.
자체 호스팅 엔진 노드 중 하나에 로그인하고 글로벌 유지 관리 모드를 비활성화합니다.
```
# hosted-engine --set-maintenance --mode=none
```
글로벌 유지 관리 모드를 종료하면 ovirt-ha-agent가 Manager 가상 시스템을 시작한 다음 Manager가 자동으로 시작됩니다. Manager가 시작하는 데 최대 10분이 걸릴 수 있습니다.
환경이 실행 중인지 확인합니다.
```
# hosted-engine --vm-status
```
나열된 정보에는 Engine Status 가 포함됩니다. Engine 상태 값은 다음과 같아야 합니다.
```
{"health": "good", "vm": "up", "detail": "Up"}
```
참고
가상 머신이 여전히 부팅되고 Manager가 아직 시작되지 않은 경우 Engine 상태는 다음과 같습니다.
```
{"reason": "bad vm status", "health": "bad", "vm": "up", "detail": "Powering up"}
```
이 경우 몇 분 기다렸다가 다시 시도합니다.

환경이 다시 실행되면 중지된 모든 가상 시스템을 시작하고 환경의 리소스가 예상대로 작동하는지 확인할 수 있습니다.

3.2.2. 별도의 머신으로 데이터 software software to a Separate Machine으로 마이그레이션

이 섹션에서는 데이터 웨어하우스 데이터베이스 및 서비스를 Red Hat Virtualization Manager 시스템에서 별도의 시스템으로 마이그레이션하는 방법에 대해 설명합니다. 별도의 시스템에서 데이터 웨어하우스 서비스를 호스팅하면 각 개별 시스템의 부하가 줄어들고 CPU 및 메모리 리소스를 다른 프로세스와 공유하여 발생할 수 있는 충돌을 방지합니다.

참고

Red Hat은 이러한 구성 요소를 서로 별도의 시스템에 설치할 수 있더라도 데이터 웨어하우스 데이터베이스, 데이터 웨어하우스 서비스 및 Grafana 모두에만 설치할 수 있도록 지원합니다.

다음과 같은 마이그레이션 옵션이 있습니다.

Manager 시스템에서 데이터 웨어하우스 서비스를 마이그레이션하고 기존 데이터 웨어하우스 데이터베이스(ovirt_engine_history)와 연결할 수 있습니다.
Manager 시스템에서 데이터 웨어하우스 데이터베이스를 마이그레이션한 다음 데이터 웨어하우스 서비스를 마이그레이션할 수 있습니다.

3.2.2.1. 별도의 머신으로 데이터 웨어하우스 데이터베이스 마이그레이션

데이터 웨어하우스 서비스를 마이그레이션하기 전에 데이터 웨어하우스 데이터베이스(ovirt_engine_history)를 마이그레이션합니다. engine-backup 을 사용하여 데이터베이스 백업을 생성하고 새 데이터베이스 시스템에서 복원합니다. engine -backup 에 대한 자세한 내용을 보려면 engine-backup --help 를 실행합니다.

참고

새 데이터베이스 서버에 Red Hat Enterprise Linux 8이 설치되어 있어야 합니다.

새 데이터베이스 서버에서 필요한 리포지토리를 활성화합니다.

3.2.2.1.1. Red Hat Virtualization Manager 리포지토리 활성화

Red Hat Subscription Manager에 데이터 웨어하우스 시스템에 로그인하고 등록하고 Red Hat Virtualization Manager 서브스크립션을 연결한 다음 Manager 리포지토리를 활성화해야 합니다.

절차

시스템을 Content Delivery Network에 등록하고 메시지가 표시되면 고객 포털 사용자 이름과 암호를 입력합니다.
```
# subscription-manager register
```
참고
IPv6 네트워크를 사용하는 경우 IPv6 전환 메커니즘을 사용하여 콘텐츠 전달 네트워크 및 서브스크립션 관리자에게 액세스합니다.
Red Hat Virtualization Manager 서브스크립션 풀을 찾아 풀 ID를 기록합니다.
```
# subscription-manager list --available
```
풀 ID를 사용하여 서브스크립션을 시스템에 연결합니다.
```
# subscription-manager attach --pool=pool_id
```
참고
현재 첨부된 서브스크립션을 보려면 다음을 수행합니다.
```
# subscription-manager list --consumed
```
활성화된 리포지토리를 모두 나열하려면 다음을 수행합니다.
```
# dnf repolist
```

리포지토리를 구성합니다.

# subscription-manager repos \
    --disable='*' \
    --enable=rhel-8-for-x86_64-baseos-eus-rpms \
    --enable=rhel-8-for-x86_64-appstream-eus-rpms \
    --enable=rhv-4.4-manager-for-rhel-8-x86_64-rpms \
    --enable=fast-datapath-for-rhel-8-x86_64-rpms \
    --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms \
    --enable=openstack-16.2-cinderlib-for-rhel-8-x86_64-rpms \
    --enable=rhceph-4-tools-for-rhel-8-x86_64-rpms

RHEL 버전을 8.6으로 설정합니다.
```
# subscription-manager release --set=8.6
```
postgresql 모듈 버전 12를 활성화합니다.
```
# dnf module -y enable postgresql:12
```
nodejs 모듈의 버전 14를 활성화합니다.
```
# dnf module -y enable nodejs:14
```
설치된 패키지를 동기화하여 사용 가능한 최신 버전으로 업데이트합니다.
```
# dnf distro-sync --nobest
```

추가 리소스

모듈 및 모듈 스트림에 대한 자세한 내용은 사용자 공간 구성 요소 설치, 관리 및 제거의 다음 섹션을 참조하십시오.

3.2.2.1.2. 별도의 머신으로 데이터 웨어하우스 데이터베이스 마이그레이션

절차

Manager에서 데이터 웨어하우스 데이터베이스 및 구성 파일의 백업을 생성합니다.

# engine-backup --mode=backup --scope=grafanadb --scope=dwhdb --scope=files --file=file_name --log=log_file_name

Manager의 백업 파일을 새 시스템으로 복사합니다.
```
# scp /tmp/file_name root@new.dwh.server.com:/tmp
```
새 시스템에 engine-backup 을 설치합니다.
```
# dnf install ovirt-engine-tools-backup
```

PostgreSQL 서버 패키지를 설치합니다.

# dnf install postgresql-server postgresql-contrib

PostgreSQL 데이터베이스를 초기화하고, postgresql 서비스를 시작한 다음, 이 서비스가 부팅 시 시작되는지 확인합니다.
```
# su - postgres -c 'initdb'
# systemctl enable postgresql
# systemctl start postgresql
```
새 시스템에서 데이터 웨어하우스 데이터베이스를 복원합니다. file_name 은 Manager에서 복사한 백업 파일입니다.
```
# engine-backup --mode=restore --scope=files --scope=grafanadb --scope=dwhdb --file=file_name --log=log_file_name --provision-dwh-db
```
복원 모드에서 --provision-* 옵션을 사용하면 기본적으로 --restore-permissions 가 적용됩니다.

데이터 웨어하우스 데이터베이스는 이제 Manager가 호스팅되는 별도의 시스템에서 호스팅됩니다. 데이터 웨어하우스 데이터베이스를 복원한 후 프롬프트에서 engine-setup 명령을 실행하도록 지시합니다. 이 명령을 실행하기 전에 데이터 웨어하우스 서비스를 마이그레이션합니다.

3.2.2.2. 별도의 머신으로 데이터 웨어하우스 서비스 마이그레이션

Red Hat Virtualization Manager에 설치 및 구성된 데이터 웨어하우스 서비스를 별도의 시스템으로 마이그레이션할 수 있습니다. 별도의 시스템에서 데이터 웨어하우스 서비스를 호스팅하면 Manager 시스템의 부하를 줄이는 데 도움이 됩니다.

이 절차에서는 데이터 웨어하우스 서비스만 마이그레이션합니다.

데이터 웨어하우스 서비스를 마이그레이션하기 전에 데이터 웨어하우스 데이터베이스(ovirt_engine_history)를 마이그레이션하려면 데이터장 데이터베이스를 분리 머신으로 마이그레이션을 참조하십시오.

참고

사전 요구 사항

동일한 시스템에 Manager 및 Data 웨어하우스를 설치하고 구성해야 합니다.
새 데이터 웨어하우스 시스템을 설정하려면 다음이 있어야 합니다.
- Manager의 /etc/ovirt-engine/engine.conf.d/10-setup-database.conf 파일의 암호입니다.
- 데이터 웨어하우스 시스템에서 관리자 데이터베이스 시스템의 TCP 포트 5432로 액세스할 수 있습니다.
- Manager의 /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf 파일에서 데이터 웨어하우스 데이터베이스의 사용자 이름과 암호.
  데이터 웨어하우스 데이터베이스를 분리 머신으로 마이그레이션하는 데 설명된 절차를 사용하여 ovirt_engine_history 데이터베이스 를 마이그레이션하면 해당 시스템에 데이터베이스 설정 중에 정의한 이러한 자격 증명이 포함됩니다.

이 시나리오를 설치하려면 다음 네 가지 단계가 필요합니다.

새 데이터 웨어하우스 머신 설정
Manager 시스템에서 데이터 installer 서비스 중지
새 데이터 저장소 머신 구성
Manager 시스템에서 데이터 installer 패키지 비활성화

3.2.2.2.1. 새 데이터 웨어하우스 머신 설정

Red Hat Virtualization 리포지토리를 활성화하고 Red Hat Enterprise Linux 8 시스템에 데이터 웨어하우스 설치 패키지를 설치합니다.

필요한 리포지토리를 활성화합니다.

시스템을 Content Delivery Network에 등록하고 메시지가 표시되면 고객 포털 사용자 이름과 암호를 입력합니다.
```
# subscription-manager register
```
Red Hat Virtualization Manager 서브스크립션 풀을 찾아 풀 ID를 기록합니다.
```
# subscription-manager list --available
```
풀 ID를 사용하여 서브스크립션을 시스템에 연결합니다.
```
# subscription-manager attach --pool=pool_id
```

리포지토리를 구성합니다.

# subscription-manager repos \
    --disable='*' \
    --enable=rhel-8-for-x86_64-baseos-eus-rpms \
    --enable=rhel-8-for-x86_64-appstream-eus-rpms \
    --enable=rhv-4.4-manager-for-rhel-8-x86_64-rpms \
    --enable=fast-datapath-for-rhel-8-x86_64-rpms \
    --enable=jb-eap-7.4-for-rhel-8-x86_64-rpms

# subscription-manager release --set=8.6

pki-deps 모듈을 활성화합니다.
```
# dnf module -y enable pki-deps
```
현재 설치된 모든 패키지가 최신 상태인지 확인합니다.
```
# dnf upgrade --nobest
```
ovirt-engine-dwh-setup 패키지를 설치합니다.
```
# dnf install ovirt-engine-dwh-setup
```

3.2.2.2.2. 관리자 시스템에서 데이터 웨어하우스 서비스 중지

절차

데이터 웨어하우스 서비스를 중지합니다.
```
# systemctl stop ovirt-engine-dwhd.service
```
데이터베이스가 원격 시스템에서 호스팅되는 경우 postgres.conf 파일을 편집하여 액세스 권한을 수동으로 부여해야 합니다. /var/lib/pgsql/data/postgresql.conf 파일을 편집하고 다음과 일치하도록 listen_addresses 행을 수정합니다.
```
listen_addresses = '*'
```
행이 없거나 주석 처리된 경우 수동으로 추가합니다.
데이터베이스가 Manager 시스템에서 호스팅되고 Red Hat Virtualization Manager를 새로 설정하는 동안 구성된 경우 기본적으로 액세스 권한이 부여됩니다.
postgresql 서비스를 다시 시작하십시오.
```
# systemctl restart postgresql
```

3.2.2.2.3. 새 데이터 웨어하우스 머신 구성

이 섹션에 표시된 옵션 또는 설정의 순서는 환경에 따라 다를 수 있습니다.

ovirt_engine_history 데이터베이스와 데이터 웨어하우스 서비스를 모두 동일한 시스템으로 마이그레이션하는 경우 다음을 실행하십시오. 그렇지 않으면 다음 단계를 진행합니다.

# sed -i '/^ENGINE_DB_/d' \
        /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/10-setup-database.conf

# sed -i \
     -e 's;^\(OVESETUP_ENGINE_CORE/enable=bool\):True;\1:False;' \
     -e '/^OVESETUP_CONFIG\/fqdn/d' \
     /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

올바른 값으로 engine-setup 으로 다시 생성되도록 apache/grafana PKI 파일을 제거하십시오.

# rm -f \
  /etc/pki/ovirt-engine/certs/apache.cer \
  /etc/pki/ovirt-engine/certs/apache-grafana.cer \
  /etc/pki/ovirt-engine/keys/apache.key.nopass \
  /etc/pki/ovirt-engine/keys/apache-grafana.key.nopass \
  /etc/pki/ovirt-engine/apache-ca.pem \
  /etc/pki/ovirt-engine/apache-grafana-ca.pem

engine-setup 명령을 실행하여 시스템에서 데이터 웨어하우스 구성을 시작합니다.
```
# engine-setup
```
Enter 를 눌러 자동으로 감지된 호스트 이름을 승인하거나 대체 호스트 이름을 입력한 후 Enter 키를 누릅니다.
```
Host fully qualified DNS name of this server [autodetected host name]:
```
Enter 를 눌러 방화벽을 자동으로 구성하거나 No 를 입력하고 Enter 를 눌러 기존 설정을 유지 관리합니다.
```
Setup can automatically configure the firewall on this system.
Note: automatic configuration of the firewall may overwrite current settings.
Do you want Setup to configure the firewall? (Yes, No) [Yes]:
```
방화벽을 자동으로 구성하도록 선택하고 방화벽 관리자가 활성화되지 않은 경우 지원되는 옵션 목록에서 선택한 방화벽 관리자를 선택하라는 메시지가 표시됩니다. 방화벽 관리자 이름을 입력하고 Enter 키를 누릅니다. 이는 하나의 옵션만 나열되는 경우에도 적용됩니다.

관리자에 대해 정규화된 도메인 이름과 암호를 입력합니다. Enter 를 눌러 서로 필드의 기본값을 적용합니다.

Host fully qualified DNS name of the engine server []: engine-fqdn
Setup needs to do some actions on the remote engine server. Either automatically, using ssh as root to access it, or you will be prompted to manually perform each such action.
Please choose one of the following:
1 - Access remote engine server using ssh as root
2 - Perform each action manually, use files to copy content around
(1, 2) [1]:
ssh port on remote engine server [22]:
root password on remote engine server engine-fqdn: password

Manager 데이터베이스 시스템의 FQDN 및 암호를 입력합니다. Enter 를 눌러 서로 필드의 기본값을 적용합니다.

Engine database host []: manager-db-fqdn
Engine database port [5432]:
Engine database secured connection (Yes, No) [No]:
Engine database name [engine]:
Engine database user [engine]:
Engine database password: password

설치 설정을 확인합니다.

Please confirm installation settings (OK, Cancel) [OK]:

데이터 웨어하우스 서비스가 이제 원격 시스템에 구성되어 있습니다. Manager 시스템에서 데이터 웨어하우스 서비스를 비활성화합니다.

3.2.2.2.4. 관리자 시스템에서 데이터 웨어하우스 서비스 비활성화

사전 요구 사항

Manager 시스템의 Grafana 서비스가 비활성화되어 있습니다.
```
# systemctl disable --now grafana-server.service
```

절차

Manager 시스템에서 Manager를 다시 시작합니다.
```
# service ovirt-engine restart
```

다음 명령을 실행하여 /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf 파일을 수정하고 옵션을 False로 설정합니다.

# sed -i \
     -e 's;^\(OVESETUP_DWH_CORE/enable=bool\):True;\1:False;' \
     -e 's;^\(OVESETUP_DWH_CONFIG/remoteEngineConfigured=bool\):True;\1:False;' \
     /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

# sed -i \
     -e 's;^\(OVESETUP_GRAFANA_CORE/enable=bool\):True;\1:False;' \
     /etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf

데이터 웨어하우스 서비스를 비활성화합니다.
```
# systemctl disable ovirt-engine-dwhd.service
```

데이터 웨어하우스 파일을 제거합니다.

# rm -f /etc/ovirt-engine-dwh/ovirt-engine-dwhd.conf.d/*.conf /var/lib/ovirt-engine-dwh/backups/*

데이터 웨어하우스 서비스는 이제 Manager와 별도의 시스템에서 호스팅됩니다.

3.2.3. 백업 스토리지 도메인을 사용하여 가상 머신 백업 및 복원

3.2.3.1. 백업 스토리지 도메인 설명

백업 스토리지 도메인은 재해 복구, 마이그레이션 또는 기타 백업/복원 사용 모델을 위해 백업 및 복원을 위해 가상 머신 및 가상 머신 템플릿을 저장 및 마이그레이션하는 데 특히 사용할 수 있습니다. 백업 도메인은 백업 도메인의 모든 가상 시스템이 전원 다운 상태라는 점에서 백업이 아닌 도메인과 다릅니다. 가상 시스템은 백업 도메인에서 실행할 수 없습니다.

데이터 스토리지 도메인을 백업 도메인으로 설정할 수 있습니다. Manage Domain(도메인 관리) 대화 상자에서 확인란을 선택하거나 선택 취소하여 이 설정을 활성화하거나 비활성화할 수 있습니다. 이 설정은 해당 스토리지 도메인의 모든 가상 시스템이 중지된 후에만 활성화할 수 있습니다.

백업 도메인에 저장된 가상 머신을 시작할 수 없습니다. 관리자는 이 작업을 차단하고 백업을 무효화할 수 있는 기타 모든 작업을 차단합니다. 그러나 가상 시스템의 디스크가 백업 도메인의 일부가 아닌 경우 백업 도메인에 저장된 템플릿을 기반으로 가상 머신을 실행할 수 있습니다.

다른 유형의 스토리지 도메인과 마찬가지로 데이터 센터에 백업 도메인을 연결하거나 분리할 수 있습니다. 따라서 백업 저장 외에도 백업 도메인을 사용하여 데이터 센터 간에 가상 시스템을 마이그레이션할 수 있습니다.

이점

내보내기 도메인이 아닌 백업 도메인을 사용하는 몇 가지 이유는 다음과 같습니다.

하나의 내보내기 도메인과 달리 데이터 센터에 여러 백업 스토리지 도메인을 가질 수 있습니다.
백업 및 재해 복구에 사용할 백업 스토리지 도메인을 전용으로 지정할 수 있습니다.
가상 머신, 템플릿 또는 스냅샷의 백업을 백업 스토리지 도메인으로 전송할 수 있습니다.
내보내기 도메인보다 백업 도메인을 사용하면 다수의 가상 시스템, 템플릿 또는 OVF 파일을 마이그레이션하는 속도가 훨씬 빠릅니다.
백업 도메인은 내보내기 도메인보다 디스크 공간을 더 효율적으로 사용합니다.
백업 도메인은 파일 스토리지(NFS, Gluster) 및 블록 스토리지(Fiber Channel 및 iSCSI)를 모두 지원합니다. 이는 파일 스토리지만 지원하는 내보내기 도메인과 대조됩니다.
제한 사항을 고려하여 스토리지 도메인의 백업 설정을 동적으로 활성화 및 비활성화할 수 있습니다.

제한 사항

백업 도메인의 모든 가상 시스템 또는 템플릿은 동일한 도메인에 모든 디스크가 있어야 합니다.
스토리지 도메인의 모든 가상 시스템의 전원을 꺼야 백업 도메인으로 설정할 수 있습니다.
이렇게 하면 디스크의 데이터를 조작할 수 있기 때문에 백업 도메인에 저장된 가상 시스템을 실행할 수 없습니다.
메모리 볼륨은 활성 가상 머신에서만 지원되므로 백업 도메인이 메모리 볼륨의 대상이 될 수 없습니다.
백업 도메인에서 가상 머신을 미리 볼 수 없습니다.
가상 머신을 백업 도메인으로 실시간 마이그레이션할 수 없습니다.
백업 도메인을 마스터 도메인이 되도록 설정할 수 없습니다.
자체 호스팅 엔진의 도메인을 백업 도메인으로 설정할 수 없습니다.
default 스토리지 도메인을 백업 도메인으로 사용하지 마십시오.

3.2.3.2. 데이터 스토리지 도메인을 백업 도메인으로 설정

사전 요구 사항

스토리지 도메인의 가상 시스템 또는 템플릿에 속하는 모든 디스크는 동일한 도메인에 있어야 합니다.
도메인의 모든 가상 시스템의 전원을 꺼야 합니다.

절차

관리 포털에서 Storage Domains (스토리지 도메인)를 선택합니다.
새 스토리지 도메인을 생성하거나 기존 스토리지 도메인을 선택하고 Manage Domain(도메인 관리 )을 클릭합니다. Manage Domains(도메인 관리) 대화 상자가 열립니다.
Advanced Parameters(고급 매개 변수 )에서 Backup(백업 ) 확인란을 선택합니다.

도메인은 이제 백업 도메인입니다.

3.2.3.3. 백업 도메인을 사용하여 가상 머신 또는 스냅샷 백업 또는 복원

전원이 꺼진 가상 시스템 또는 스냅샷을 백업할 수 있습니다. 그런 다음, 동일한 데이터 센터에 백업을 저장하고 필요에 따라 복원하거나 다른 데이터 센터로 마이그레이션할 수 있습니다.

절차: 가상 머신 백업

백업 도메인을 생성합니다. 스토리지 도메인 설정을 백업 도메인 백업 도메인으로 설정합니다.
백업할 가상 머신을 기반으로 새 가상 머신을 생성합니다.
- 스냅샷을 백업하려면 먼저 스냅샷에서 가상 시스템을 만듭니다. 가상 머신 관리 가이드의 스냅샷에서 가상 머신 생성을 참조하십시오.
- 가상 시스템을 백업하려면 먼저 가상 시스템을 복제합니다. 가상 머신 관리 가이드에서 가상 머신 복제를 참조하십시오. 계속하기 전에 복제본의 전원이 꺼져 있는지 확인합니다.
새 가상 시스템을 백업 도메인으로 내보냅니다. 가상 머신 관리 가이드에서 데이터 도메인으로 가상 머신 내보내기 를 참조하십시오.

절차: 가상 머신 복원

가상 시스템 백업을 저장하는 백업 스토리지 도메인이 데이터 센터에 연결되어 있는지 확인합니다.
백업 도메인에서 가상 시스템을 가져옵니다. 데이터 도메인에서 가상 머신 가져오기를 참조하십시오.

관련 정보

3.2.4. 백업 및 복원 API를 사용하여 가상 머신 백업 및 복원

3.2.4.1. 백업 및 복원 API

백업 및 복원 API는 가상 머신의 전체 또는 파일 수준 백업 및 복원을 수행할 수 있는 기능 컬렉션입니다. API는 라이브 스냅샷 및 REST API와 같은 Red Hat Virtualization의 여러 구성 요소를 결합하여 독립 소프트웨어 공급자가 제공하는 백업 소프트웨어가 포함된 가상 머신에 연결할 수 있는 임시 볼륨을 생성하고 작업합니다.

지원되는 타사 백업 벤더는 Red Hat Virtualization 에코시스템 을 참조하십시오.

3.2.4.2. 가상 머신 백업

백업 및 복원 API를 사용하여 가상 머신을 백업합니다. 이 절차에서는 백업할 가상 시스템과 백업을 관리하는 소프트웨어를 설치하는 가상 시스템이 두 개 있다고 가정합니다.

절차

REST API를 사용하여 백업할 가상 머신의 스냅샷을 생성합니다.
```
POST /api/vms/{vm:id}/snapshots/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<snapshot>
    <description>BACKUP</description>
</snapshot>
```
참고
- 여기서 {vm:id} 를 스냅샷이 있는 가상 시스템의 VM ID로 바꿉니다. 이 ID는 관리 포털 및 VM 포털의 New Virtual Machine(새 가상 시스템) 및 Edit Virtual Machine(가상 시스템 편집 ) 창의 General(일반 ) 탭에서 사용할 수 있습니다.
- 가상 시스템의 스냅샷을 저장하면 현재 구성 데이터가 구성 특성의 data 속성에 스냅샷 아래의 초기화 에 저장됩니다.
중요
공유 가능 또는 직접 LUN 디스크에 따라 디스크 스냅샷을 가져올 수 없습니다.
스냅샷 아래의 data 속성에서 가상 머신의 구성 데이터를 검색합니다.
```
GET /api/vms/{vm:id}/snapshots/{snapshot:id} HTTP/1.1
All-Content: true
Accept: application/xml
Content-type: application/xml
```
참고
- 여기에서 {vm:id} 를 이전에 만든 가상 시스템의 ID로 바꿉니다. {snapshot:id} 를 스냅샷 ID로 바꿉니다.
- All-Content: true 헤더를 추가하여 응답에서 추가 OVF 데이터를 검색합니다. XML 응답의 OVF 데이터는 VM 구성 요소 <initialization><configuration> 내에 있습니다. 나중에 이 데이터를 사용하여 가상 시스템을 복원합니다.

스냅샷 ID를 가져옵니다.

GET /api/vms/{vm:id}/snapshots/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

스냅샷의 디스크 ID를 식별합니다.

GET /api/vms/{vm:id}/snapshots/{snapshot:id}/disks HTTP/1.1
Accept: application/xml
Content-type: application/xml

올바른 인터페이스 유형(예: virtio_scsi)을 사용하여 백업 가상 머신에 액티브 디스크 연결로 스냅샷을 연결합니다.
```
POST /api/vms/{vm:id}/diskattachments/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<disk_attachment>
	<active>true</active>
	<interface>_virtio_scsi_</interface>
	<disk id="{disk:id}">
	<snapshot id="{snapshot:id}"/>
	</disk>
</disk_attachment>
```
참고
여기에서 {vm:id} 를 이전에 스냅샷이 아닌 백업 가상 시스템의 ID로 바꿉니다. {disk:id} 를 디스크 ID로 바꿉니다. {snapshot:id} 를 스냅샷 ID로 바꿉니다.
백업 가상 시스템에서 백업 소프트웨어를 사용하여 스냅샷 디스크의 데이터를 백업합니다.
백업 가상 머신에서 스냅샷 디스크 연결을 제거합니다.
```
DELETE /api/vms/{vm:id}/diskattachments/{snapshot:id} HTTP/1.1
Accept: application/xml
Content-type: application/xml
```
참고
여기에서 {vm:id} 를 이전에 스냅샷이 아닌 백업 가상 시스템의 ID로 바꿉니다. {snapshot:id} 를 스냅샷 ID로 바꿉니다.
선택적으로 스냅샷을 삭제합니다.
```
DELETE /api/vms/{vm:id}/snapshots/{snapshot:id} HTTP/1.1
Accept: application/xml
Content-type: application/xml
```
참고
여기에서 {vm:id} 를 이전에 만든 가상 시스템의 ID로 바꿉니다. {snapshot:id} 를 스냅샷 ID로 바꿉니다.

별도의 가상 시스템에 설치된 백업 소프트웨어를 사용하여 고정 지점에서 가상 머신의 상태를 백업했습니다.

3.2.4.3. 가상 머신 복원

백업 및 복원 API를 사용하여 백업된 가상 머신을 복원합니다. 이 절차에서는 이전 백업을 관리하는 데 사용한 소프트웨어가 설치된 백업 가상 시스템이 있다고 가정합니다.

절차

관리 포털에서 백업을 복원할 유동 디스크를 생성합니다. 유동 디스크를 생성하는 방법에 대한 자세한 내용은 가상 디스크 생성을 참조하십시오.
백업 가상 머신에 디스크를 연결합니다.
```
POST /api/vms/{vm:id}/disks/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<disk id="{disk:id}">
</disk>
```
참고
여기에서 {vm:id} 를 이전에 스냅샷이 아닌 이 백업 가상 시스템의 ID로 바꿉니다. {disk:id} 를 가상 머신을 백업하는 동안 얻은 디스크 ID로 바꿉니다.
백업 소프트웨어를 사용하여 백업을 디스크에 복원합니다.
백업 가상 머신에서 디스크를 분리합니다.
```
DELETE /api/vms/{vm:id}/disks/{disk:id} HTTP/1.1
Accept: application/xml
Content-type: application/xml

<action>
    <detach>true</detach>
</action>
```
참고
여기에서 {vm:id} 를 이전에 스냅샷이 아닌 이 백업 가상 시스템의 ID로 바꿉니다. {disk:id} 를 디스크 ID로 바꿉니다.

복원 중인 가상 머신의 구성 데이터를 사용하여 새 가상 머신을 생성합니다.

POST /api/vms/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<vm>
    <cluster>
        <name>cluster_name</name>
    </cluster>
    <name>_NAME_</name>
      <initialization>
      <configuration>
  <data>
  <!-- omitting long ovf data -->
  </data>
      <type>ovf</type>
      </configuration>
      </initialization>
    ...
</vm>

참고

가상 시스템을 생성하는 동안 ovf의 값을 재정의하려면 초기화 요소 전후에 요소를 재정의합니다. 초기화 요소 내에 없습니다.

새 가상 머신에 디스크를 연결합니다.
```
POST /api/vms/{vm:id}/disks/ HTTP/1.1
Accept: application/xml
Content-type: application/xml

<disk id="{disk:id}">
</disk>
```
참고
여기에서 {vm:id} 를 이전에 스냅샷이 있는 가상 머신이 아닌 새 가상 시스템의 ID로 바꿉니다. {disk:id} 를 디스크 ID로 바꿉니다.

백업 및 복원 API를 사용하여 생성된 백업을 사용하여 가상 머신을 복원했습니다.

3.2.5. 증분 백업 및 복원 API를 사용하여 가상 머신 백업 및 복원

3.2.5.1. 증분 백업 및 복원 API

Red Hat Virtualization은 임시 스냅샷 없이 QCOW2 또는 RAW 가상 디스크의 전체 백업 또는 QCOW 2 가상 디스크의 증분 백업 백업에 사용할 수 있는 증분 백업 API를 제공합니다. 백업 중인 가상 디스크가 QCOW2인지 RAW인지 여부에 관계없이 RAW 형식으로 데이터가 백업됩니다. RAW 게스트 데이터와 RAW 또는 QCOW2 디스크를 복원할 수 있습니다. 증분 백업 API는 RHV REST API의 일부입니다. 실행 중이거나 그렇지 않은 가상 머신을 백업할 수 있습니다.

개발자는 API를 사용하여 백업 애플리케이션을 개발할 수 있습니다.

기능

백업은 Backup 및 Restore API를 사용할 때보다 더 간단하고 빠르고 강력합니다. 증분형 백업 API를 사용하면 백업 애플리케이션과의 통합이 향상되고 기본 디스크 형식에 관계없이 RAW 게스트 데이터를 백업하고 복원하는 새로운 지원이 제공됩니다.

잘못된 비트맵으로 인해 백업이 실패하는 경우 백업 체인에서 특정 checkpoint를 제거할 수 있습니다. 전체 백업을 실행할 필요는 없습니다.

제한 사항:

QCOW2 형식의 디스크만 RAW 형식 디스크가 아닌 증분적으로 백업할 수 있습니다. 백업 프로세스는 백업된 데이터를 RAW 형식으로 저장합니다.
RAW 형식으로 백업된 데이터만 복원할 수 있습니다.
증분 복원은 백업 시 스냅샷 복원을 지원하지 않으며, 증분 복원은 백업 시 스냅샷의 볼륨 또는 이미지의 구조가 아닌 데이터만 복원합니다. 이 제한은 다른 시스템의 백업 솔루션에서 일반적입니다.
일반적으로 백업 솔루션과 마찬가지로 증분 복원은 백업 시 스냅샷의 볼륨 또는 이미지의 구조가 아닌 데이터만 복원합니다.
가상 시스템의 불명확한 종료 원인으로 인해 디스크의 비트맵이 무효화되어 전체 백업 체인이 무효화될 수 있습니다. 잘못된 비트맵을 사용하여 증분 백업을 복원하면 가상 머신 데이터가 손상됩니다.
백업을 시작하는 것 외에 잘못된 비트맵을 감지할 방법은 없습니다. 디스크에 잘못된 비트맵이 포함된 경우 작업이 실패합니다.

다음 표에서는 증분 백업을 지원하는 디스크 구성을 설명합니다.

참고

관리 포털을 사용하여 디스크를 생성할 때 스토리지 유형, 프로비저닝 유형 및 증분 백업의 활성화 또는 비활성화 여부를 설정합니다. 이러한 설정에 따라 관리자는 가상 디스크 형식을 결정합니다.

표 3.1. 증분 백업에 지원되는 디스크 구성
스토리지 유형	프로비저닝 유형	증분 백업이..	가상 디스크 형식은...
블록	씬	enabled	qcow2
블록	사전 할당됨	enabled	qcow2 (preallocated)
file	씬	enabled	qcow2
file	사전 할당됨	enabled	qcow2 (preallocated)
블록	씬	비활성화됨	qcow2
블록	사전 할당됨	비활성화됨	원시 (사전 할당됨)
file	씬	비활성화됨	raw (sparse)
file	사전 할당됨	비활성화됨	원시 (사전 할당됨)
network	해당 없음	비활성화됨	원시
LUN	해당 없음	비활성화됨	원시

3.2.5.1.1. 증분 백업 흐름

증분 백업 API를 사용하는 백업 애플리케이션은 증분 백업을 위해 이미 활성화된 가상 머신 디스크를 백업하려면 다음 시퀀스를 따라야 합니다.

백업 애플리케이션은 REST API를 사용하여 백업에 포함되어야 하는 가상 시스템 디스크를 찾습니다. QCOW2 형식의 디스크만 포함됩니다.
백업 애플리케이션은 전체 백업 또는 증분 백업을 시작합니다. API 호출은 가상 시스템 ID, 선택적 이전 체크포인트 ID 및 백업할 디스크 목록을 지정합니다. API 호출에서 이전 checkpoint ID를 지정하지 않으면 각 디스크의 현재 상태에 따라 지정된 디스크의 모든 데이터를 포함하는 전체 백업이 시작됩니다.
엔진은 백업을 위해 가상 시스템을 준비합니다. 가상 시스템은 백업 중에 계속 실행될 수 있습니다.
백업 애플리케이션은 엔진에서 백업을 시작할 준비가 되었다고 보고할 때까지 엔진의 백업 상태를 폴링합니다.
백업을 시작할 준비가 되면 백업 애플리케이션에서 백업에 포함된 모든 디스크에 대해 이미지 전송 오브젝트를 생성합니다.
백업 애플리케이션은 모든 이미지 전송에 대해 ovirt-imageio 에서 변경된 블록 목록을 가져옵니다. 변경 목록을 사용할 수 없는 경우 백업 애플리케이션에 오류가 발생합니다.
백업 애플리케이션은 ovirt-imageio 에서 변경된 블록을 RAW 형식으로 다운로드하여 백업 미디어에 저장합니다. 변경된 블록 목록을 사용할 수 없는 경우 백업 애플리케이션을 대체하여 전체 디스크를 복사할 수 있습니다.
백업 애플리케이션은 모든 이미지 전송을 완료합니다.
백업 애플리케이션은 REST API를 사용하여 백업을 완료합니다.

3.2.5.1.2. 증분 복원 흐름

증분 백업 API를 사용하는 백업 애플리케이션은 다음 시퀀스에 따라 백업된 가상 머신 디스크를 복원해야 합니다.

사용자는 백업 애플리케이션을 사용하여 사용 가능한 백업을 기반으로 복원 지점을 선택합니다.
백업 애플리케이션에서는 복원된 데이터를 보유할 기존 디스크가 있는 새 디스크 또는 스냅샷을 생성합니다.
백업 애플리케이션은 모든 디스크에 대해 업로드 이미지 전송을 시작하여 형식을 지정하는 것은 raw 입니다. 이를 통해 RAW 데이터를 QCOW2 디스크에 업로드할 때 형식 변환이 가능합니다.
백업 애플리케이션은 API를 사용하여 이 복원 지점에 포함된 데이터를 imageio 로 전송합니다.
백업 애플리케이션은 이미지 전송을 완료합니다.

3.2.5.1.3. 증분 백업 및 복원 API 작업

증분 백업 및 복원 API는 Red Hat Virtualization REST API 가이드에 설명되어 있습니다. 백업 및 복원 흐름에는 다음 작업이 필요합니다.

3.2.5.1.4. 새 가상 디스크에서 증분 백업 활성화

가상 디스크에 대해 증분 백업을 활성화하여 증분 백업에 포함된 대로 표시합니다. 디스크를 추가할 때 REST API 또는 관리 포털을 사용하여 모든 디스크에 대해 증분 백업을 활성화할 수 있습니다. 전체 백업을 사용하여 또는 이전과 동일한 방식으로 증분 백업에 활성화되지 않은 기존 디스크를 백업할 수 있습니다.

참고

관리자는 증분 백업에 디스크를 활성화할 필요가 없지만 활성화된 디스크를 추적하도록 활성화할 수 있습니다.

증분 백업에는 QCOW2로 디스크를 포맷해야 하므로 RAW 형식 대신 QCOW2 형식을 사용하십시오.

절차

새 가상 디스크를 추가합니다. 자세한 내용은 가상 디스크 생성을 참조하십시오.
디스크를 구성할 때 Enable Incremental Backup (분산 백업 사용) 확인란을 선택합니다.

추가 리소스

API를 사용하여 디스크의 증분 백업을 활성화합니다.

3.2.5.1.5. 기존 RAW 가상 디스크에서 증분 백업 활성화

RAW 형식의 디스크에는 증분 백업이 지원되지 않으므로 증분 백업을 사용하려면 RAW 형식 디스크에 QCOW2 형식 계층이 있어야 합니다. 스냅샷을 생성하면 QCOW2 계층이 생성되므로 스냅샷이 생성되는 지점에서 스냅샷에 포함된 모든 디스크에서 증분 백업을 활성화합니다.

주의

디스크의 기본 계층에서 RAW 형식을 사용하는 경우 마지막 스냅샷을 삭제하고 최상위 QCOW2 계층을 기본 계층으로 병합하여 디스크를 RAW 형식으로 변환하여 설정된 경우 증분 백업을 비활성화합니다. 증분 백업을 다시 활성화하려면 이 디스크를 포함한 새 스냅샷을 만들 수 있습니다.

절차

관리 포털에서 Compute(컴퓨팅) Virtual Machines(가상 시스템) 를 클릭합니다.
가상 머신을 선택하고 Disks (디스크) 탭을 클릭합니다.
Edit(편집) 버튼을 클릭합니다. 디스크 편집 대화 상자가 열립니다.
Enable Incremental Backup 확인란을 선택합니다.

추가 리소스

API를 사용하여 디스크의 증분 백업 활성화

3.2.5.1.6. 증분 백업 활성화

REST API 요청을 사용하여 가상 머신 디스크의 증분 백업을 활성화할 수 있습니다.

절차

새 디스크에 대해 증분 백업을 활성화합니다. 예를 들어 ID가 123 인 가상 머신의 새 디스크의 경우 이 요청을 보냅니다.
```
POST /ovirt-engine/api/vms/123/diskattachments
```
요청 본문에는 다음과 같이 디스크 오브젝트의 일부로 incremental 로 설정된 백업이 포함되어야 합니다.
```
<disk_attachment>
    …
    <disk>
       …
       <backup>incremental</backup>
       …
    </disk>
</disk_attachment>
```

응답은 다음과 같습니다.

<disk_attachment>
    …
    <disk href="/ovirt-engine/api/disks/456" id="456"/>
    …
</disk_attachment>

추가 리소스

RHV용 REST API 가이드 의 DiskBackup 열거 형

3.2.5.1.7. 증분 백업에 활성화된 디스크 찾기

지정된 가상 머신의 경우 backup 속성에 따라 필터링된 증분 백업에 활성화된 디스크를 나열할 수 있습니다.

절차

가상 머신에 연결된 디스크를 나열합니다. 예를 들어 ID가 123 인 가상 머신의 경우 이 요청을 보냅니다.
```
GET /ovirt-engine/api/vms/123/diskattachments
```
응답에는 모든 disk_attachment 오브젝트가 포함되며, 각 오브젝트에는 하나 이상의 디스크 오브젝트가 포함됩니다. 예를 들면 다음과 같습니다.
```
<disk_attachments>
    <disk_attachment>
       …
       <disk href="/ovirt-engine/api/disks/456" id="456"/>
       …
    </disk_attachment>
    …
</disk_attachments>
```
디스크 서비스를 사용하여 이전 단계의 디스크 속성을 확인합니다. 예를 들어 ID 456 이 있는 디스크의 경우 다음 요청을 보냅니다.
```
GET /ovirt-engine/api/disks/456
```
응답에는 디스크의 모든 속성이 포함됩니다. 백업 은 none 또는 증분식 으로 설정됩니다. 예를 들면 다음과 같습니다.
```
<disk href="/ovirt-engine/api/disks/456" id="456">
    …
    <backup>incremental</backup>
    …
</disk>
```

추가 리소스

3.2.5.1.8. 전체 백업 시작

전체 백업 후 결과 검사점 ID를 다음 증분 백업의 시작 지점으로 사용할 수 있습니다.After a full backup you can use the resulting checkpoint ID as the start point in the next incremental backup.

실행 중인 가상 머신을 백업할 때 프로세스는 백업 중인 디스크와 동일한 스토리지 도메인에 스크래치 디스크를 생성합니다. 백업 프로세스에서는 이 디스크를 생성하여 백업 중에 실행 중인 가상 시스템에 새 데이터를 작성할 수 있습니다. 이 스크래치 디스크는 백업 중에 관리 포털에서 확인할 수 있습니다. 백업이 완료되면 자동으로 삭제됩니다.

전체 백업을 시작하려면 본문을 사용한 요청 호출이 필요하며 응답이 포함됩니다.

절차

백업할 가상 시스템을 지정하는 요청을 전송합니다. 예를 들어 ID가 123 인 가상 머신을 다음과 같이 지정합니다.
```
POST /ovirt-engine/api/vms/123/backups
```
요청 본문에서 백업할 디스크를 지정합니다. 예를 들어 ID 456 으로 디스크의 전체 백업을 시작하려면 다음 요청 본문을 보냅니다.
```
<backup>
    <disks>
       <disk id="456" />
       …
    </disks>
</backup>
```
응답 본문은 다음과 유사해야 합니다.
```
<backup id="789">
    <disks>
       <disk id="456" />
       …
       …
    </disks>
    <status>initializing</status>
    <creation_date>
</backup>
```
응답에는 다음이 포함됩니다.
- 백업 ID
- 백업의 상태: 백업이 초기화 중임을 나타냅니다.
상태가 준비될 때까지 백업을 폴링합니다. 응답에는 to_checkpoint_id 가 포함됩니다. 이 ID를 기록해 두고 다음 증분 백업에서 from_checkpoint_id 에 사용합니다.

추가 리소스

RHV 의 REST API 가이드에 VmBackups 서비스 방법추가

3.2.5.1.9. 증분 백업 시작

지정된 가상 디스크에 대해 전체 백업이 완료되면 해당 디스크에 마지막 백업 이후의 변경 사항만 포함하는 후속 증분 백업입니다. 최신 백업의 to_checkpoint_id 값을 요청 본문의 from_checkpoint_id 값으로 사용합니다.

증분 백업 또는 혼합 백업을 시작하려면 본문을 사용한 요청 호출이 필요하며 응답이 포함됩니다.

절차

백업할 가상 시스템을 지정하는 요청을 전송합니다. 예를 들어 ID가 123 인 가상 머신을 다음과 같이 지정합니다.
```
POST /ovirt-engine/api/vms/123/backups
```
요청 본문에서 백업할 디스크를 지정합니다. 예를 들어 ID 456 가 있는 디스크의 증분 백업을 시작하려면 다음 요청 본문을 보냅니다.
```
<backup>
    <from_checkpoint_id>previous-checkpoint-uuid</from_checkpoint_id>
    <disks>
       <disk id="456" />
       …
    </disks>
</backup>
```
참고
요청 본문에서 이전 확인 지점에 포함되지 않은 디스크를 포함하는 경우 요청은 이 디스크의 전체 백업도 실행합니다. 예를 들어 ID 789 가 있는 디스크는 아직 백업되지 않았습니다. 위의 요청 본문에 전체 백업을 추가하려면 다음과 같은 요청 본문을 보냅니다.
```
<backup>
    <from_checkpoint_id>previous-checkpoint-uuid</from_checkpoint_id>
    <disks>
       <disk id="456" />
       <disk id="789" />
       …
    </disks>
</backup>
```
응답 본문은 다음과 유사해야 합니다.
```
<backup id="101112">
<from_checkpoint_id>previous-checkpoint-uuid</from_checkpoint_id>
<to_checkpoint_id>new-checkpoint-uuid</to_checkpoint_id>
    <disks>
       <disk id="456" />
       <disk id="789" />
       …
       …
    </disks>
    <status>initializing</status>
    <creation_date>
</backup>
```
응답에는 다음이 포함됩니다.
- 백업 ID입니다.
- 백업에 포함된 디스크의 ID입니다.
- 백업이 초기화 중임을 나타내는 상태입니다.
상태가 준비될 때까지 백업을 폴링합니다. 응답에는 to_checkpoint_id 가 포함됩니다. 이 ID를 기록해 두고 다음 증분 백업에서 from_checkpoint_id 에 사용합니다.

추가 리소스

RHV용 REST API 가이드에 VmBackups 서비스의 메서드를추가합니다 .

3.2.5.1.10. 백업에 대한 정보 가져오기

새 증분 백업을 시작하는 데 사용할 수 있는 백업에 대한 정보를 가져올 수 있습니다.

VmBackups 서비스의 목록 방법은 백업에 대한 다음 정보를 반환합니다.

백업한 각 디스크의 ID입니다.
백업의 시작 및 끝 검사점의 ID입니다.
백업에 포함된 각 디스크에 대해 백업의 디스크 이미지 ID입니다.
백업의 상태입니다.
백업이 생성된 날짜입니다.

<status> 값이 준비되면 응답에는 다음 증분 백업에서 <from_checkpoint_id>로 사용해야 하는 <to_checkpoint_id>가 포함되고 디스크 다운로드를 시작하여 가상 머신 스토리지를 백업할 수 있습니다.

절차

ID가 123인 가상 머신의 ID 456이 있는 백업에 대한 정보를 얻으려면 다음과 같은 요청을 보냅니다.
```
GET /ovirt-engine/api/vms/456/backups/123
```
응답에는 ID 456이 포함된 백업과 <from_checkpoint_id> 999 및 <to_checkpoint_id> 666가 포함됩니다. 백업에 포함된 디스크는 <link> 요소에서 참조됩니다.
```
<backup id="456">
    <from_checkpoint_id>999</from_checkpoint_id>
    <to_checkpoint_id>666</to_checkpoint_id>
    <link href="/ovirt-engine/api/vms/456/backups/123/disks" rel="disks"/>
    <status>ready</status>
    <creation_date>
</backup>
```

추가 리소스

VmBackups 서비스의 메서드 나열

3.2.5.1.11. 백업의 디스크에 대한 정보 가져오기

백업의 각 디스크에 사용된 백업 모드를 포함하여 백업의 일부인 디스크에 대한 정보를 가져올 수 있습니다. 이는 백업을 다운로드하는 데 사용하는 모드를 결정하는 데 도움이 됩니다.

VmBackupDisks 서비스의 목록 방법은 백업에 대한 다음 정보를 반환합니다.

백업한 각 디스크의 ID와 이름입니다.
백업에 포함된 각 디스크에 대해 백업의 디스크 이미지 ID입니다.
디스크 형식입니다.
디스크에서 지원하는 백업 동작입니다.
디스크에 대해 가져온 백업 유형(전체/부위)입니다.

절차

ID가 123인 가상 머신의 ID 456이 있는 백업에 대한 정보를 얻으려면 다음과 같은 요청을 보냅니다.

GET /ovirt-engine/api/vms/456/backups/123/disks

응답에는 ID 789가 있는 디스크와 디스크 이미지의 ID가 555입니다.

<disks>
    <disk id="789">
        <name>vm1_Disk1</name>
        <actual_size>671744</actual_size>
        <backup>incremental</backup>
        <backup_mode>full</backup_mode>
        <format>cow</format>
        <image_id>555</image_id>
        <qcow_version>qcow2_v3</qcow_version>
        <status>locked</status>
        <storage_type>image</storage_type>
        <total_size>0</total_size>
    </disk>
</disks>

추가 리소스

VmBackupDisks 서비스의 메서드 나열

3.2.5.1.12. 백업 종료

백업을 완료하면 백업을 종료하고, 리소스를 잠금 해제하고, 정리 작업을 수행합니다. 최종 백업 서비스 방법 사용

절차

ID가 123 인 가상 머신에서 ID 456 이 있는 디스크 백업을 종료하려면 다음과 같은 요청을 보냅니다.
```
POST /vms/123/backups/456/finalize
```

추가 리소스

REST API 가이드에서 POST 종료.

3.2.5.1.13. 증분 백업을 위한 이미지 전송 오브젝트 생성

백업을 다운로드할 준비가 되면 백업 애플리케이션에서 증분 백업에 대한 전송을 시작하는 imagetransfer 오브젝트를 생성해야 합니다.

이미지 전송 오브젝트를 생성하려면 본문이 있는 요청 호출이 필요합니다.

절차

다음과 같은 요청을 보냅니다.
```
POST /ovirt-engine/api/imagetransfers
```
요청 본문에서 다음 매개변수를 지정합니다.
- 디스크 ID.
- 백업 ID.
- 다운로드할 디스크 세트의 방향.
- 디스크 형식을 raw 로 설정합니다.
예를 들어 디스크 ID가 123 이고 백업 ID가 456 인 디스크의 백업을 전송하려면 다음 요청 본문을 보냅니다.
```
<image_transfer>
    <disk id="123"/>
    <backup id="456"/>
    <direction>download</direction>
    <format>raw</format>
</image_transfer>
```

추가 리소스

RHV 의 REST API 가이드에서 이미지 전송 오브젝트를 생성하는 방법을추가합니다 .

3.2.5.1.14. 증분 복원을 위한 이미지 전송 오브젝트 생성

증분 백업 API를 사용하여 백업된 원시 데이터를 QCOW2 형식의 디스크에 복원하려면 백업 애플리케이션에서 imagetransfer 오브젝트를 생성해야 합니다.

전송 형식이 raw 이고 기본 디스크 형식이 QCOW2이면 업로드된 데이터는 스토리지에 쓸 때 즉시 QCOW2 형식으로 변환됩니다. QCOW2 디스크에서 RAW 디스크로 데이터를 업로드하는 것은 지원되지 않습니다.

이미지 전송 오브젝트를 생성하려면 본문이 있는 요청 호출이 필요합니다.

절차

다음과 같은 요청을 보냅니다.
```
POST /ovirt-engine/api/imagetransfers
```
요청 본문에서 다음 매개변수를 지정합니다.
- 디스크 ID 또는 스냅샷 ID.
- 업로드할 디스크 세트의 방향입니다.
- 디스크 형식을 raw 로 설정합니다.
예를 들어 디스크 ID가 123 인 디스크의 백업을 전송하려면 다음 요청 본문을 보냅니다.
```
<image_transfer>
    <disk id="123"/>
    <direction>upload</direction>
    <format>raw</format>
</image_transfer>
```

추가 리소스

RHV 의 REST API 가이드에서 이미지 전송 오브젝트를 생성하는 방법을추가합니다 .

3.2.5.1.15. 가상 머신의 체크 포인트 나열

요청 호출을 보내면 각 검사 지점에 대한 정보를 포함하여 가상 시스템의 모든 checkpoints를 나열할 수 있습니다.

절차

가상 시스템을 지정하는 요청을 전송합니다. 예를 들어 ID가 123 인 가상 머신을 다음과 같이 지정합니다.
```
GET /vms/123/checkpoints/
```

응답에는 모든 가상 시스템 체크포인트가 포함됩니다. 각 검사 지점에는 다음 정보가 포함됩니다.

검사점의 디스크입니다.
부모 검사점의 ID입니다.
검사점 생성 날짜입니다.
속한 가상 머신입니다.

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

<parent_id>, <creation_date> and the virtual machine it belongs to <vm>:
<checkpoints>
    <checkpoint id="456">
         <link href="/ovirt-engine/api/vms/vm-uuid/checkpoints/456/disks" rel="disks"/>
         <parent_id>parent-checkpoint-uuid</parent_id>
         <creation_date>xxx</creation_date>
         <vm href="/ovirt-engine/api/vms/123" id="123"/>
    </checkpoint>
</checkpoints>

추가 리소스

RHV의 REST API 가이드에 가상 시스템 체크포인트를 나열하는방법을 나열합니다.

3.2.5.1.16. 가상 머신의 특정 checkpoint 나열

요청 호출을 보내 가상 머신의 특정 검사 지점에 대한 정보를 나열할 수 있습니다.

절차

가상 시스템을 지정하는 요청을 전송합니다. 예를 들어 ID가 123 이고 검사점 ID 456 이 있는 가상 머신을 다음과 같이 지정합니다.
```
GET /vms/123/checkpoints/456
```

응답에는 체크포인트에 대한 다음 정보가 포함됩니다.

검사점의 디스크입니다.
부모 검사점의 ID입니다.
검사점 생성 날짜입니다.
속한 가상 머신입니다.

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

<checkpoint id="456">
     <link href="/ovirt-engine/api/vms/vm-uuid/checkpoints/456/disks" rel="disks"/>
     <parent_id>parent-checkpoint-uuid</parent_id>
     <creation_date>xxx</creation_date>
     <vm href="/ovirt-engine/api/vms/123" id="123"/>
</checkpoint>

추가 리소스

RHV의 REST API 가이드에 가상 시스템 체크포인트를 나열하는방법을 나열합니다.

3.2.5.1.17. checkpoint 제거

DELETE 요청을 보내 가상 머신의 checkpoint를 제거할 수 있습니다. 실행 여부에 관계없이 가상 머신의 checkpoint를 제거할 수 있습니다.

절차

가상 시스템 및 checkpoint를 지정하는 요청을 전송합니다. 예를 들어 ID가 123 인 가상 머신과 ID 456 이 있는 검사점을 지정합니다.
```
DELETE /vms/123/checkpoints/456/
```

추가 리소스

VmCheckpoint 방법 제거

3.2.5.1.18. imageio API를 사용하여 백업 데이터 전송

이미지 전송 API는 이미지 전송을 시작하고 중지합니다. 결과적으로 전송 URL이 표시됩니다.

imageio API를 사용하여 전송 URL에서 데이터를 전송합니다.

imageio API 사용에 대한 전체 정보는 ovirt-imageio Images API 참조를 참조하십시오.

표 3.2. 증분 백업 및 복원에 사용되는 Imageio Image API 방법
API 요청	설명	Imageio Image API 참조 섹션
`OPTIONS /images/{ticket-id} HTTP/1.1`	서버에서 지원하는 기능을 확인하기 위해 서버 옵션을 가져옵니다.	옵션보기
`GET /images/{ticket-id}/extents`	디스크 이미지 콘텐츠 및 할당 또는 증분 백업 중에 변경된 블록에 대한 정보를 가져옵니다. 이 정보를 확장 영역 정보라고 합니다.	추가 정보
`GET /images/{ticket-id}/extent?context=dirty`	이미지 전송을 수행하는 프로그램은 백업에서 변경 사항을 다운로드해야 합니다. 이러한 변경 사항은 더티 확장 영역으로 알려져 있습니다. 변경 사항을 다운로드하려면 다음과 같은 요청을 보냅니다.	EXTENT S→ 예제→ 더티 확장 요청보기
`PUT /images/{ticket-id}`	백업 애플리케이션에서는 복원된 데이터를 보유할 기존 디스크가 있는 새 디스크 또는 스냅샷을 생성합니다.	PUT보기

추가 리소스

Red Hat Virtualization Python SDK에는 백업 전송을 시작하는 데 사용할 수 있는 몇 가지 구현 예제가 포함되어 있습니다.

3.2. 백업 및 마이그레이션

3.2.1. Red Hat Virtualization Manager 백업 및 복원

3.2.1.1. Red Hat Virtualization Manager 백업 - 개요

3.2.1.2. engine-backup 명령의 구문

3.2.1.3. engine-backup 명령으로 백업 생성

3.2.1.4. engine-backup 명령을 사용하여 백업 복원

3.2.1.5. 이전 설치로 백업 복원

3.2.1.6. 기존 설치를 덮어쓰도록 백업 복원

3.2.1.7. 다른 인증 정보를 사용하여 백업 복원

3.2.1.8. 자체 호스팅 엔진 백업 및 복원

3.2.1.8.1. 원래 관리자 백업

3.2.1.8.2. 새로운 자체 호스팅 엔진에서 백업 복원

3.2.1.8.3. Red Hat Virtualization Manager 리포지토리 활성화

3.2.1.8.4. 호스트 재설치

3.2.1.8.5. 스토리지 도메인 제거

3.2.1.9. 기존 백업에서 자체 호스팅 엔진 복구

3.2.1.9.1. 새로운 자체 호스팅 엔진에서 백업 복원

3.2.1.9.2. Red Hat Virtualization Manager 리포지토리 활성화

3.2.1.9.3. 호스트 재설치

3.2.1.9.4. 스토리지 도메인 제거

3.2.1.10. 기존 백업에서 자체 호스팅 엔진 덮어쓰기

3.2.1.10.1. 글로벌 유지 관리 모드 활성화

3.2.1.10.2. 기존 설치를 덮어쓰도록 백업 복원

3.2.1.10.3. 전역 유지 관리 모드 비활성화

3.2.2. 별도의 머신으로 데이터 software software to a Separate Machine으로 마이그레이션

3.2.2.1. 별도의 머신으로 데이터 웨어하우스 데이터베이스 마이그레이션

3.2.2.1.1. Red Hat Virtualization Manager 리포지토리 활성화

3.2.2.1.2. 별도의 머신으로 데이터 웨어하우스 데이터베이스 마이그레이션

3.2.2.2. 별도의 머신으로 데이터 웨어하우스 서비스 마이그레이션

3.2.2.2.1. 새 데이터 웨어하우스 머신 설정

3.2.2.2.2. 관리자 시스템에서 데이터 웨어하우스 서비스 중지

3.2.2.2.3. 새 데이터 웨어하우스 머신 구성

3.2.2.2.4. 관리자 시스템에서 데이터 웨어하우스 서비스 비활성화

3.2.3. 백업 스토리지 도메인을 사용하여 가상 머신 백업 및 복원

3.2.3.1. 백업 스토리지 도메인 설명

3.2.3.2. 데이터 스토리지 도메인을 백업 도메인으로 설정

3.2.3.3. 백업 도메인을 사용하여 가상 머신 또는 스냅샷 백업 또는 복원

3.2.4. 백업 및 복원 API를 사용하여 가상 머신 백업 및 복원

3.2.4.1. 백업 및 복원 API

3.2.4.2. 가상 머신 백업

3.2.4.3. 가상 머신 복원

3.2.5. 증분 백업 및 복원 API를 사용하여 가상 머신 백업 및 복원

3.2.5.1. 증분 백업 및 복원 API

3.2.5.1.1. 증분 백업 흐름

3.2.5.1.2. 증분 복원 흐름

3.2.5.1.3. 증분 백업 및 복원 API 작업

3.2.5.1.4. 새 가상 디스크에서 증분 백업 활성화

3.2.5.1.5. 기존 RAW 가상 디스크에서 증분 백업 활성화

3.2.5.1.6. 증분 백업 활성화

3.2.5.1.7. 증분 백업에 활성화된 디스크 찾기

3.2.5.1.8. 전체 백업 시작

3.2.5.1.9. 증분 백업 시작

3.2.5.1.10. 백업에 대한 정보 가져오기

3.2.5.1.11. 백업의 디스크에 대한 정보 가져오기

3.2.5.1.12. 백업 종료

3.2.5.1.13. 증분 백업을 위한 이미지 전송 오브젝트 생성

3.2.5.1.14. 증분 복원을 위한 이미지 전송 오브젝트 생성

3.2.5.1.15. 가상 머신의 체크 포인트 나열

3.2.5.1.16. 가상 머신의 특정 checkpoint 나열

3.2.5.1.17. checkpoint 제거

3.2.5.1.18. imageio API를 사용하여 백업 데이터 전송

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links