Language:
Format:

언더클라우드 및 컨트롤 플레인 노드 백업 및 복원

Red Hat OpenStack Platform 16.1

언더클라우드 및 오버클라우드 컨트롤 플레인 노드의 백업 생성 및 복원

초록

이 가이드에서는 언더클라우드 및 컨트롤 플레인 노드의 백업을 생성하고 복원하는 방법과 문제 백업 및 복원 방법을 설명합니다. Red Hat OpenStack Platform을 업그레이드하거나 업데이트할 때 백업이 필요합니다. 또한 문제의 경우 다운타임을 최소화하기 위해 환경에 대한 정기적인 백업을 선택적으로 생성할 수 있습니다.

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

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

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

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

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

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

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

1장. 언더클라우드 노드 백업

언더클라우드 노드를 백업하려면 백업 노드를 구성하고 언더클라우드 노드에 Relax-and- recovery 툴을 설치한 다음 백업 이미지를 생성합니다. 일반 환경 유지 관리의 일부로 백업을 생성할 수 있습니다.

또한 업데이트 또는 업그레이드를 수행하기 전에 언더클라우드 노드를 백업해야 합니다. 업데이트 또는 업그레이드 중에 오류가 발생하는 경우 백업을 사용하여 언더클라우드 노드를 이전 상태로 복원할 수 있습니다.

1.1. 지원되는 백업 형식 및 프로토콜

Undercloud 및 백업 및 복원 프로세스에서는 open-source 도구 Relax-and- recover(ReaR)를 사용하여 부팅 가능한 백업 이미지를 생성하고 복원합니다. back은 Bash로 작성되며 여러 이미지 형식과 다중 전송 프로토콜을 지원합니다.

다음 목록은 Red Hat OpenStack Platform에서 지원하는 백업 형식 및 프로토콜을 보여줍니다.

부팅 가능한 미디어 형식

파일 전송 프로토콜

SFTP
NFS

1.2. 백업 노드에 NFS 서버 설치 및 구성

백업 파일을 저장할 새 NFS 서버를 설치하고 구성할 수 있습니다. 백업 노드에 NFS 서버를 설치하고 구성하려면 인벤토리 파일을 생성하고 SSH 키를 설정한 다음 NFS 서버 옵션을 사용하여 openstack undercloud backup 명령을 실행합니다.

중요

NFS 또는 SFTP 서버를 이전에 설치 및 구성한 경우 이 절차를 완료할 필요가 없습니다. 백업할 노드에 ReaR을 설정할 때 서버 정보를 입력합니다.
기본적으로 Relax 및 Recover(ReaR) 구성에서는 NFS 서버의 IP 주소가 192.168.24.1 인 것으로 가정합니다. NFS 서버에 다른 IP 주소가 있는 경우 설정 ReaR 명령에 tripleo_backup_and_restore_nfs_server 매개변수를 추가합니다.

절차

언더클라우드 노드에서 언더클라우드 인증 정보를 가져옵니다.
```
[stack@undercloud ~]$ source stackrc
(undercloud) [stack@undercloud ~]$
```
언더클라우드 노드에서 백업 노드의 인벤토리 파일을 생성하고 <ip_address> 및 <user> 를 환경에 적용되는 값으로 교체합니다.
```
(undercloud) [stack@undercloud ~]$ cat <<'EOF'> ~/nfs-inventory.yaml
[BackupNode]
<backup_node> ansible_host=<ip_address> ansible_user=<user>
EOF
```

언더클라우드 노드에서 다음 Ansible 플레이북을 생성하고 <backup_node> 를 백업 노드의 호스트 이름으로 바꿉니다.

(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_nfs_setup.yaml
# Playbook
# Substitute <backup_node> with the host name of your backup node.
- become: true
  hosts: <backup_node>
  name: Setup NFS server for ReaR
  roles:
  - role: backup-and-restore
EOF

Undercloud 노드에서 백업 노드로 공용 SSH 키를 복사합니다.
```
(undercloud) [stack@undercloud ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub <backup_node>
```
<backup_node> 를 백업 노드의 경로 및 이름으로 바꿉니다.

언더클라우드 노드에서 다음 ansible-playbook 명령을 입력하여 백업 노드를 구성합니다.

(undercloud) [stack@undercloud ~]$ ansible-playbook \
    -v -i ~/nfs-inventory.yaml \
    --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \
    --become \
    --become-user root \
    --tags bar_setup_nfs_server \
    ~/bar_nfs_setup.yaml

1.3. 언더클라우드 노드에 ReaR 설치

언더클라우드 노드의 백업을 생성하기 전에 언더클라우드에 Relax 및 Recovery(ReaR)를 설치하고 구성합니다.

사전 요구 사항

백업 노드에 NFS 또는 SFTP 서버가 설치 및 구성되어 있습니다. 새 NFS 서버 생성에 대한 자세한 내용은 1.2절. “백업 노드에 NFS 서버 설치 및 구성” 을 참조하십시오.

절차

언더클라우드 노드에서 언더클라우드 인증 정보를 가져오고 tripleo-ansible-inventory 명령을 사용하여 모든 오버클라우드 노드의 호스트 및 변수가 포함된 정적 인벤토리 파일을 생성합니다.
```
[stack@undercloud ~]$ source stackrc
(undercloud) [stack@undercloud ~]$ tripleo-ansible-inventory \
--ansible_ssh_user heat-admin \
--static-yaml-inventory /home/stack/tripleo-inventory.yaml
```
사용자 지정 스택 이름을 사용하는 경우 tripleo-ansible-inventory 명령에 --stack <stack_name> 옵션을 추가합니다.

언더클라우드 노드에서 다음 Ansible 플레이북을 생성합니다.

(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_rear_setup-undercloud.yaml
# Playbook
# Installing and configuring ReaR on the undercloud node
- become: true
  hosts: undercloud
  name: Install ReaR
  roles:
  - role: backup-and-restore
EOF

다음 옵션 중 하나를 선택하십시오.

NFS를 사용하는 경우 다음 Ansible 명령을 입력하여 언더클라우드 노드에 ReaR을 설치합니다.

(undercloud) [stack@undercloud ~]$ ansible-playbook \
    -v -i ~/tripleo-inventory.yaml \
    --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \
    --become \
    --become-user root \
    -e tripleo_backup_and_restore_nfs_server=<nfs-ip> \
    --tags bar_setup_rear \
    ~/bar_rear_setup-undercloud.yaml

SFTP를 사용하는 경우 다음 Ansible 명령을 입력하여 언더클라우드 노드에 ReaR을 설치합니다.

(undercloud) [stack@undercloud ~]$ ansible-playbook \
    -v -i ~/tripleo-inventory.yaml \
    --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \
    --become \
    --become-user root \
    -e tripleo_backup_and_restore_output_url=sftp://<user>:<password>@<backup_node_ip>/ \
    -e tripleo_backup_and_restore_backup_url=iso:///backup/ \
    --tags bar_setup_rear \
    ~/bar_rear_setup-undercloud.yaml

시스템에서 UEFI 부트 로더를 사용하는 경우 언더클라우드 노드에서 다음 단계를 수행합니다.
1. 다음 툴을 설치합니다.
```
$ sudo dnf install dosfstools efibootmgr
```
2. USING_UEFI_BOOTLOADER 매개변수 값 0 을 1 로 교체하여 /etc/rear/local.conf 에 있는 ReaR 구성 파일에서 UEFI 백업을 활성화합니다.

1.4. 백업을 위한 OVS(Open vSwitch) 인터페이스 구성

환경에서 OVS(Open vSwitch) 브리지를 사용하는 경우 언더클라우드 또는 컨트롤 플레인 노드의 백업을 생성하기 전에 OVS 인터페이스를 수동으로 구성해야 합니다. 복원 프로세스는 이 정보를 사용하여 네트워크 인터페이스를 복원합니다.

절차

/etc/rear/local.conf 파일에서 다음 형식으로 NETWORKING_PREPARATION_COMMANDS 매개변수를 추가합니다.
```
NETWORKING_PREPARATION_COMMANDS=('<command_1>' '<command_2>' ...')
```
<command_1> 및 <command_2> 를 네트워크 인터페이스 이름 또는 IP 주소를 구성하는 명령으로 바꿉니다. 예를 들어 ip link add br-ctlplane type bridge 명령을 추가하여 컨트롤 플레인 브리지 이름을 구성하거나 ip link set eth0 up 명령을 추가하여 인터페이스 이름을 설정할 수 있습니다. 네트워크 구성에 따라 매개변수에 명령을 추가할 수 있습니다.

1.5. 언더클라우드 노드 백업 생성

언더클라우드 노드의 백업을 생성하려면 backup-and-restore Ansible 역할을 사용합니다. 그런 다음 노드가 손상되거나 액세스할 수 없는 경우 백업을 사용하여 언더클라우드 노드를 이전 상태로 복원할 수 있습니다. Undercloud 노드의 백업에는 Undercloud 노드에서 실행되는 데이터베이스의 백업이 포함됩니다.

사전 요구 사항

백업 노드에 NFS 또는 SFTP 서버가 설치 및 구성되어 있습니다. 새 NFS 서버 생성에 대한 자세한 내용은 1.2절. “백업 노드에 NFS 서버 설치 및 구성” 을 참조하십시오.
언더클라우드 노드에 ReaR이 설치되어 있습니다. 자세한 내용은 1.3절. “언더클라우드 노드에 ReaR 설치”의 내용을 참조하십시오.
네트워크 인터페이스에 OVS 브리지를 사용하는 경우 OVS 인터페이스를 구성했습니다. 자세한 내용은 1.4절. “백업을 위한 OVS(Open vSwitch) 인터페이스 구성”의 내용을 참조하십시오.

절차

stack 사용자로 언더클라우드에 로그인합니다.

MySQL 루트 암호를 검색합니다.

[stack@undercloud ~]$ PASSWORD=$(sudo /bin/hiera -c /etc/puppet/hiera.yaml mysql::server::root_password)

언더클라우드 노드의 데이터베이스 백업을 생성합니다.

[stack@undercloud ~]$ sudo podman exec mysql bash -c "mysqldump -uroot -p$PASSWORD --opt --all-databases" | sudo tee /root/undercloud-all-databases.sql

언더클라우드 인증 정보를 소싱합니다.
```
[stack@undercloud ~]$ source stackrc
```

언더클라우드 노드에서 다음 Ansible 플레이북을 생성합니다.

(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_rear_create_restore_images-undercloud.yaml
# Playbook
# Using ReaR on the undercloud node.
- become: true
  hosts: undercloud
  name: Create the recovery images for the undercloud
  roles:
  - role: backup-and-restore
EOF

언더클라우드 노드의 백업을 생성하려면 다음 ansible-playbook 명령을 입력합니다.

(undercloud) [stack@undercloud ~]$ ansible-playbook \
    -v -i ~/tripleo-inventory.yaml \
    --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \
    --become \
    --become-user root \
    --tags bar_create_recover_image \
    ~/bar_rear_create_restore_images-undercloud.yaml

2장. 컨트롤 플레인 노드 백업

컨트롤 플레인 노드를 백업하려면 백업 노드를 구성하고 컨트롤 플레인 노드에 Relax-and- recovery 툴을 설치하고 백업 이미지를 생성합니다. 일반 환경 유지 관리의 일부로 백업을 생성할 수 있습니다.

업데이트 또는 업그레이드를 수행하기 전에 컨트롤 플레인 노드를 백업해야 합니다. 업데이트 또는 업그레이드 중에 오류가 발생하는 경우 백업을 사용하여 컨트롤 플레인 노드를 이전 상태로 복원할 수 있습니다. 일반 환경 유지보수의 일부로 백업을 생성할 수도 있습니다.

2.1. 지원되는 백업 형식 및 프로토콜

다음 목록은 Red Hat OpenStack Platform에서 지원하는 백업 형식 및 프로토콜을 보여줍니다.

부팅 가능한 미디어 형식

파일 전송 프로토콜

SFTP
NFS

2.2. 백업 노드에 NFS 서버 설치 및 구성

중요

NFS 또는 SFTP 서버를 이전에 설치 및 구성한 경우 이 절차를 완료할 필요가 없습니다. 백업할 노드에 ReaR을 설정할 때 서버 정보를 입력합니다.
기본적으로 Relax 및 Recover(ReaR) 구성에서는 NFS 서버의 IP 주소가 192.168.24.1 인 것으로 가정합니다. NFS 서버에 다른 IP 주소가 있는 경우 설정 ReaR 명령에 tripleo_backup_and_restore_nfs_server 매개변수를 추가합니다.

절차

언더클라우드 노드에서 언더클라우드 인증 정보를 가져옵니다.
```
[stack@undercloud ~]$ source stackrc
(undercloud) [stack@undercloud ~]$
```
언더클라우드 노드에서 백업 노드의 인벤토리 파일을 생성하고 <ip_address> 및 <user> 를 환경에 적용되는 값으로 교체합니다.
```
(undercloud) [stack@undercloud ~]$ cat <<'EOF'> ~/nfs-inventory.yaml
[BackupNode]
<backup_node> ansible_host=<ip_address> ansible_user=<user>
EOF
```

언더클라우드 노드에서 다음 Ansible 플레이북을 생성하고 <backup_node> 를 백업 노드의 호스트 이름으로 바꿉니다.

(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_nfs_setup.yaml
# Playbook
# Substitute <backup_node> with the host name of your backup node.
- become: true
  hosts: <backup_node>
  name: Setup NFS server for ReaR
  roles:
  - role: backup-and-restore
EOF

Undercloud 노드에서 백업 노드로 공용 SSH 키를 복사합니다.
```
(undercloud) [stack@undercloud ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub <backup_node>
```
<backup_node> 를 백업 노드의 경로 및 이름으로 바꿉니다.

언더클라우드 노드에서 다음 ansible-playbook 명령을 입력하여 백업 노드를 구성합니다.

(undercloud) [stack@undercloud ~]$ ansible-playbook \
    -v -i ~/nfs-inventory.yaml \
    --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \
    --become \
    --become-user root \
    --tags bar_setup_nfs_server \
    ~/bar_nfs_setup.yaml

2.3. 컨트롤 플레인 노드에 ReaR 설치

컨트롤 플레인 노드의 백업을 생성하기 전에 각 컨트롤 플레인 노드에 Relax 및 Recovery(ReaR)를 설치하고 구성합니다.

중요

알려진 문제로 인해 컨트롤러 노드가 다운된 경우에도 오버클라우드 노드의 ReaR 백업이 계속됩니다. ReaR 백업을 실행하기 전에 모든 컨트롤러 노드가 실행 중인지 확인합니다. 향후 RHOSP(Red Hat OpenStack Platform) 릴리스에 대한 수정 사항이 예정되어 있습니다. 자세한 내용은 BZ#2077335 - 하나의 컨트롤러에 연결할 수 없는 경우에도 오버클라우드 ctlplane을 계속 백업합니다.

사전 요구 사항

백업 노드에 NFS 또는 SFTP 서버가 설치 및 구성되어 있습니다. 새 NFS 서버 생성에 대한 자세한 내용은 2.2절. “백업 노드에 NFS 서버 설치 및 구성” 을 참조하십시오.

절차

언더클라우드 노드에서 다음 Ansible 플레이북을 생성합니다.
```
(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_rear_setup-controller.yaml
# Playbook
# Install and configuring ReaR on the control plane nodes
- become: true
  hosts: Controller
  name: Install ReaR
  roles:
  - role: backup-and-restore
EOF
```
참고
구성 가능한 역할로 컨트롤 플레인 노드를 배포한 경우 호스트 유형 컨트롤러를 컨트롤 플레인의 노드 유형으로 교체합니다. 예를 들어 데이터베이스, 메시징 및 네트워킹을 별도의 노드에 배포한 경우 ControllerOpenstack,Database,Messaging,Networker 를 입력합니다.

다음 옵션 중 하나를 선택하십시오.

NFS를 사용하고 NFS 서버의 IP 주소가 언더클라우드 노드의 기본값 192.168.24.1 인 경우 다음 Ansible 명령을 입력하여 컨트롤 플레인 노드에 ReaR을 설치합니다.

(undercloud) [stack@undercloud ~]$ ansible-playbook \
    -v -i ~/tripleo-inventory.yaml \
    --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \
    --become \
    --become-user root \
    --tags bar_setup_rear \
    ~/bar_rear_setup-controller.yaml

SFTP를 사용하고 NFS 서버의 IP 주소가 기본값 192.168.24.1 이 아닌 경우 다음 Ansible 명령을 입력하여 컨트롤 플레인 노드에 ReaR을 설치합니다.

(undercloud) [stack@undercloud ~]$ ansible-playbook \
    -v -i ~/tripleo-inventory.yaml \
    --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \
    --become \
    --become-user root \
    -e tripleo_backup_and_restore_nfs_server=<nfs_ip> \
    --tags bar_setup_rear \
    ~/bar_rear_setup-controller.yaml

<nfs_ip> 를 NFS 서버의 IP 주소로 바꿉니다.

SFTP를 사용하는 경우 다음 Ansible 명령을 입력하여 컨트롤 플레인 노드에 ReaR 설치를 수행합니다.

(undercloud) [stack@undercloud ~]$ ansible-playbook \
    -v -i ~/tripleo-inventory.yaml \
    --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \
    --become \
    --become-user root \
    -e tripleo_backup_and_restore_output_url=sftp://<user>:<password>@<backup_node_ip>/ \
    -e tripleo_backup_and_restore_backup_url=iso:///backup/ \
    --tags bar_setup_rear \
    ~/bar_rear_setup-undercloud.yaml

시스템에서 UEFI 부트 로더를 사용하는 경우 컨트롤 플레인 노드에서 다음 단계를 수행합니다.
1. 다음 툴을 설치합니다.
```
$ sudo dnf install dosfstools efibootmgr
```
2. USING_UEFI_BOOTLOADER 매개변수 값 0 을 1 로 교체하여 /etc/rear/local.conf 에 있는 ReaR 구성 파일에서 UEFI 백업을 활성화합니다.

2.4. 백업을 위한 OVS(Open vSwitch) 인터페이스 구성

절차

/etc/rear/local.conf 파일에서 다음 형식으로 NETWORKING_PREPARATION_COMMANDS 매개변수를 추가합니다.
```
NETWORKING_PREPARATION_COMMANDS=('<command_1>' '<command_2>' ...')
```
<command_1> 및 <command_2> 를 네트워크 인터페이스 이름 또는 IP 주소를 구성하는 명령으로 바꿉니다. 예를 들어 ip link add br-ctlplane type bridge 명령을 추가하여 컨트롤 플레인 브리지 이름을 구성하거나 ip link set eth0 up 명령을 추가하여 인터페이스 이름을 설정할 수 있습니다. 네트워크 구성에 따라 매개변수에 명령을 추가할 수 있습니다.

2.5. 컨트롤 플레인 노드의 백업 생성

컨트롤 플레인 노드의 백업을 생성하려면 backup-and-restore Ansible 역할을 사용합니다. 그런 다음 백업을 사용하여 노드가 손상되거나 액세스할 수 없는 경우 컨트롤 플레인 노드를 이전 상태로 복원할 수 있습니다. 컨트롤 플레인 노드의 백업에는 컨트롤 플레인 노드에서 실행되는 데이터베이스의 백업이 포함됩니다.

사전 요구 사항

백업 노드에 NFS 또는 SFTP 서버가 설치 및 구성되어 있습니다. 새 NFS 서버 생성에 대한 자세한 내용은 2.2절. “백업 노드에 NFS 서버 설치 및 구성” 을 참조하십시오.
컨트롤 플레인 노드에 ReaR이 설치되어 있어야 합니다. 자세한 내용은 2.3절. “컨트롤 플레인 노드에 ReaR 설치”의 내용을 참조하십시오.
네트워크 인터페이스에 OVS 브리지를 사용하는 경우 OVS 인터페이스를 구성했습니다. 자세한 내용은 2.4절. “백업을 위한 OVS(Open vSwitch) 인터페이스 구성”의 내용을 참조하십시오.

절차

각 컨트롤 플레인 노드에서 root 사용자로 각 노드의 config- drive 파티션을 백업합니다.
```
[root@controller-x ~]$ dd if=<config_drive_partition> of=/mnt/config-drive
```

언더클라우드 노드에서 다음 Ansible 플레이북을 생성합니다.

(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_rear_create_restore_images-controller.yaml
# Playbook
# Using ReaR on the control plane nodes.
- become: true
  hosts: ceph_mon
  name: Backup ceph authentication
  tasks:
    - name: Backup ceph authentication role
      include_role:
        name: backup-and-restore
        tasks_from: ceph_authentication
      tags:
      -  bar_create_recover_image
- become: true
  hosts: Controller
  name: Create the recovery images for the control plane
  roles:
  - role: backup-and-restore
EOF

언더클라우드 노드에서 다음 ansible-playbook 명령을 입력하여 컨트롤 플레인 노드의 백업을 생성합니다.

(undercloud) [stack@undercloud ~]$ ansible-playbook \
    -v -i ~/tripleo-inventory.yaml \
    --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \
    --become \
    --become-user root \
    --tags bar_create_recover_image \
    ~/bar_rear_create_restore_images-controller.yaml

2.6. cron을 사용하여 컨트롤 플레인 노드 백업 예약

중요

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

Ansible backup -and-restore 역할을 사용하여 ReaR로 컨트롤 플레인 노드의 백업을 생성하도록 cron 작업을 구성할 수 있습니다. /var/log/rear-cron 디렉토리에서 로그를 볼 수 있습니다.

사전 요구 사항

백업 노드에 NFS 또는 SFTP 서버가 설치 및 구성되어 있습니다. 새 NFS 서버 생성에 대한 자세한 내용은 1.2절. “백업 노드에 NFS 서버 설치 및 구성” 을 참조하십시오.
언더클라우드 및 컨트롤 플레인 노드에 ReaR이 설치되어 있어야 합니다. 자세한 내용은 2.3절. “컨트롤 플레인 노드에 ReaR 설치”의 내용을 참조하십시오.
백업을 저장할 수 있는 디스크 공간이 백업 위치에 충분히 있습니다.

절차

언더클라우드 노드에서 다음 명령을 입력하여 백업 스크립트를 생성합니다.

[stack@undercloud ~]$ cat <<'EOF' > /home/stack/execute-rear-cron.sh

#!/bin/bash

OWNER="stack"
TODAY=`date +%Y%m%d`
FILE="/var/log/rear-cron.${TODAY}"
sudo touch ${FILE}
sudo chown ${OWNER}:${OWNER} ${FILE}

CURRENTTIME=`date`
echo "[$CURRENTTIME] rear start" >> ${FILE}
source /home/stack/stackrc && /usr/bin/openstack overcloud backup 2>&1 >> ${FILE}
CURRENTTIME=`date`
echo "[$CURRENTTIME] rear end" >> ${FILE}
EOF

/home/stack/execute-rear-cron.sh 스크립트에 대한 실행 가능 권한을 설정합니다.
```
[stack@undercloud ~]$ chmod 755 /home/stack/execute-rear-cron.sh
```
crontab -e 명령으로 crontab 파일을 편집하고 선택한 편집기를 사용하여 다음 cron 작업을 추가합니다. 변경 사항을 파일에 저장해야 합니다.
```
[stack@undercloud ~]# $ crontab -e
#adding the following line
0 0 * * * /home/stack/execute-rear-cron.sh
```
/home/stack/execute-rear-cron.sh 스크립트는 stack 사용자가 자정에 의해 실행되도록 예약되었습니다.
cron 작업이 예약되었는지 확인하려면 다음 명령을 입력합니다.
```
[stack@undercloud ~]$ crontab -l
```
명령 출력에는 예약된 cron 작업이 표시됩니다.
```
0 0 * * * /home/stack/execute-rear-cron.sh
```

3장. 구성 가능 역할을 사용하는 컨트롤 플레인 노드 백업

사용자 지정 역할이라고도 하는 구성 가능 역할을 사용하여 컨트롤 플레인을 배포하는 경우 구성 가능 역할 구성에 따라 각 노드 유형을 캡처하도록 백업 프로세스를 구성합니다. 컨트롤 플레인 노드를 백업하려면 백업 노드를 구성하고 컨트롤 플레인 노드에 Relax-and- recovery 툴을 설치하고 백업 이미지를 생성합니다.

3.1. 지원되는 백업 형식 및 프로토콜

다음 목록은 Red Hat OpenStack Platform에서 지원하는 백업 형식 및 프로토콜을 보여줍니다.

부팅 가능한 미디어 형식

파일 전송 프로토콜

SFTP
NFS

3.2. 백업 노드에 NFS 서버 설치 및 구성

중요

NFS 또는 SFTP 서버를 이전에 설치 및 구성한 경우 이 절차를 완료할 필요가 없습니다. 백업할 노드에 ReaR을 설정할 때 서버 정보를 입력합니다.
기본적으로 Relax 및 Recover(ReaR) 구성에서는 NFS 서버의 IP 주소가 192.168.24.1 인 것으로 가정합니다. NFS 서버에 다른 IP 주소가 있는 경우 설정 ReaR 명령에 tripleo_backup_and_restore_nfs_server 매개변수를 추가합니다.

절차

언더클라우드 노드에서 언더클라우드 인증 정보를 가져옵니다.
```
[stack@undercloud ~]$ source stackrc
(undercloud) [stack@undercloud ~]$
```
언더클라우드 노드에서 백업 노드의 인벤토리 파일을 생성하고 <ip_address> 및 <user> 를 환경에 적용되는 값으로 교체합니다.
```
(undercloud) [stack@undercloud ~]$ cat <<'EOF'> ~/nfs-inventory.yaml
[BackupNode]
<backup_node> ansible_host=<ip_address> ansible_user=<user>
EOF
```

언더클라우드 노드에서 다음 Ansible 플레이북을 생성하고 <backup_node> 를 백업 노드의 호스트 이름으로 바꿉니다.

(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_nfs_setup.yaml
# Playbook
# Substitute <backup_node> with the host name of your backup node.
- become: true
  hosts: <backup_node>
  name: Setup NFS server for ReaR
  roles:
  - role: backup-and-restore
EOF

Undercloud 노드에서 백업 노드로 공용 SSH 키를 복사합니다.
```
(undercloud) [stack@undercloud ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub <backup_node>
```
<backup_node> 를 백업 노드의 경로 및 이름으로 바꿉니다.

언더클라우드 노드에서 다음 ansible-playbook 명령을 입력하여 백업 노드를 구성합니다.

(undercloud) [stack@undercloud ~]$ ansible-playbook \
    -v -i ~/nfs-inventory.yaml \
    --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \
    --become \
    --become-user root \
    --tags bar_setup_nfs_server \
    ~/bar_nfs_setup.yaml

3.3. 컨트롤 플레인 노드에 ReaR 설치

컨트롤 플레인 노드의 백업을 생성하기 전에 각 컨트롤 플레인 노드에 Relax 및 Recovery(ReaR)를 설치하고 구성합니다.

중요

사전 요구 사항

백업 노드에 NFS 또는 SFTP 서버가 설치 및 구성되어 있습니다. 새 NFS 서버 생성에 대한 자세한 내용은 3.2절. “백업 노드에 NFS 서버 설치 및 구성” 을 참조하십시오.

절차

언더클라우드 노드에서 다음 Ansible 플레이북을 생성합니다.
```
(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_rear_setup-controller.yaml
# Playbook
# Install and configuring ReaR on the control plane nodes
- become: true
  hosts: Controller
  name: Install ReaR
  roles:
  - role: backup-and-restore
EOF
```
참고
구성 가능한 역할로 컨트롤 플레인 노드를 배포한 경우 호스트 유형 컨트롤러를 컨트롤 플레인의 노드 유형으로 교체합니다. 예를 들어 데이터베이스, 메시징 및 네트워킹을 별도의 노드에 배포한 경우 ControllerOpenstack,Database,Messaging,Networker 를 입력합니다.

다음 옵션 중 하나를 선택하십시오.

(undercloud) [stack@undercloud ~]$ ansible-playbook \
    -v -i ~/tripleo-inventory.yaml \
    --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \
    --become \
    --become-user root \
    --tags bar_setup_rear \
    ~/bar_rear_setup-controller.yaml

SFTP를 사용하고 NFS 서버의 IP 주소가 기본값 192.168.24.1 이 아닌 경우 다음 Ansible 명령을 입력하여 컨트롤 플레인 노드에 ReaR을 설치합니다.

(undercloud) [stack@undercloud ~]$ ansible-playbook \
    -v -i ~/tripleo-inventory.yaml \
    --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \
    --become \
    --become-user root \
    -e tripleo_backup_and_restore_nfs_server=<nfs_ip> \
    --tags bar_setup_rear \
    ~/bar_rear_setup-controller.yaml

<nfs_ip> 를 NFS 서버의 IP 주소로 바꿉니다.

SFTP를 사용하는 경우 다음 Ansible 명령을 입력하여 컨트롤 플레인 노드에 ReaR 설치를 수행합니다.

(undercloud) [stack@undercloud ~]$ ansible-playbook \
    -v -i ~/tripleo-inventory.yaml \
    --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \
    --become \
    --become-user root \
    -e tripleo_backup_and_restore_output_url=sftp://<user>:<password>@<backup_node_ip>/ \
    -e tripleo_backup_and_restore_backup_url=iso:///backup/ \
    --tags bar_setup_rear \
    ~/bar_rear_setup-undercloud.yaml

시스템에서 UEFI 부트 로더를 사용하는 경우 컨트롤 플레인 노드에서 다음 단계를 수행합니다.
1. 다음 툴을 설치합니다.
```
$ sudo dnf install dosfstools efibootmgr
```
2. USING_UEFI_BOOTLOADER 매개변수 값 0 을 1 로 교체하여 /etc/rear/local.conf 에 있는 ReaR 구성 파일에서 UEFI 백업을 활성화합니다.

3.4. 백업을 위한 OVS(Open vSwitch) 인터페이스 구성

절차

/etc/rear/local.conf 파일에서 다음 형식으로 NETWORKING_PREPARATION_COMMANDS 매개변수를 추가합니다.
```
NETWORKING_PREPARATION_COMMANDS=('<command_1>' '<command_2>' ...')
```
<command_1> 및 <command_2> 를 네트워크 인터페이스 이름 또는 IP 주소를 구성하는 명령으로 바꿉니다. 예를 들어 ip link add br-ctlplane type bridge 명령을 추가하여 컨트롤 플레인 브리지 이름을 구성하거나 ip link set eth0 up 명령을 추가하여 인터페이스 이름을 설정할 수 있습니다. 네트워크 구성에 따라 매개변수에 명령을 추가할 수 있습니다.

3.5. 구성 가능한 역할을 사용하는 컨트롤 플레인 노드의 백업 생성

구성 가능한 역할을 사용하는 컨트롤 플레인 노드의 백업을 생성하려면 backup-and-restore Ansible 역할을 사용합니다. 그런 다음 백업을 사용하여 노드가 손상되거나 액세스할 수 없는 경우 컨트롤 플레인 노드를 이전 상태로 복원할 수 있습니다. 컨트롤 플레인 노드의 백업에는 컨트롤 플레인 노드에서 실행되는 데이터베이스의 백업이 포함됩니다.

사전 요구 사항

백업 노드에 NFS 또는 SFTP 서버가 설치 및 구성되어 있습니다. 새 NFS 서버 생성에 대한 자세한 내용은 3.2절. “백업 노드에 NFS 서버 설치 및 구성” 을 참조하십시오.
컨트롤 플레인 노드에 ReaR이 설치되어 있어야 합니다. 자세한 내용은 3.3절. “컨트롤 플레인 노드에 ReaR 설치”의 내용을 참조하십시오.
네트워크 인터페이스에 OVS 브리지를 사용하는 경우 OVS 인터페이스를 구성했습니다. 자세한 내용은 3.4절. “백업을 위한 OVS(Open vSwitch) 인터페이스 구성”의 내용을 참조하십시오.

절차

각 컨트롤러 노드에서 각 노드의 config- drive 파티션을 백업합니다.
```
[heat-admin@controller-x ~]$ mkdir /mnt/config-drive
[heat-admin@controller-x ~]$ dd if=<config_drive_partition> of=/mnt/config-drive
```
참고
컨트롤러 노드에서만 이 단계를 수행해야 합니다.

언더클라우드 노드에서 다음 Ansible 플레이북을 생성합니다.

(undercloud) [stack@undercloud ~]$ cat <<'EOF' > ~/bar_rear_create_restore_images-controller.yaml
# Playbook
# Using ReaR on the Contorl-Plane - Composable Roles

- become: true
  hosts: ControllerOpenstack,Database,Messaging,Networker
  name: Stop service management
  tasks:
    - include_role:
        name: backup-and-restore
        tasks_from: ../backup/tasks/service_manager_pause
      when:
       - tripleo_backup_and_restore_service_manager

- become: true
  hosts: Database
  name: Database Backup
  tasks:
    - include_role:
        name: backup-and-restore
        tasks_from: ../backup/tasks/db_backup

- become: true
  hosts: pacemaker
  name: Backup pacemaker configuration
  tasks:
    - include_role:
        name: backup-and-restore
        tasks_from: pacemaker_backup

- become: true
  hosts: ControllerOpenstack,Database,Messaging,Networker
  name: Create recovery images with ReaR
  tasks:
    - include_role:
        name: backup-and-restore
        tasks_from: ../backup/tasks/main

- become: true
  hosts: pacemaker
  name: Enabled pacemaker
  tasks:
    - name: Enable pacemaker
      command: pcs cluster start --all
      when: enabled_galera
      run_once: true
      tags:
       - bar_create_recover_image

- become: true
  hosts: Database
  name: Restart galera
  tasks:
    - name: unPause database container
      command: "{{ tripleo_container_cli }} unpause {{ tripleo_backup_and_restore_mysql_container }}"
      when:
       - tripleo_container_cli is defined
        - not enabled_galera
        - tripleo_backup_and_restore_mysql_container is defined
      tags:
       - bar_create_recover_image

- become: true
  hosts: ControllerOpenstack,Database,Messaging,Networker
  name: Unpause everything
  tasks:
    - name: Gather Container Service Name
      shell: |
       set -o pipefail
        /usr/bin/{{ tripleo_container_cli }} ps -a --filter='status=paused' --format '{{ '{{' }}.Names {{ '}}' }} '
      register: container_services
      changed_when: container_services.stdout is defined
      tags:
       - bar_create_recover_image

    - name: Unpause containers for database backup.
      command: "{{ tripleo_container_cli }} unpause {{ item }}"
      with_items: "{{ container_services.stdout_lines }}"
      when: tripleo_container_cli is defined
      tags:
       - bar_create_recover_image

언더클라우드 노드에서 다음 ansible-playbook 명령을 입력하여 컨트롤 플레인 노드의 백업을 생성합니다.
중요
스택을 작동하지 마십시오. pacemaker 클러스터와 컨테이너를 중지하면 Compute 노드로 컨트롤 플레인 서비스가 일시적으로 중단됩니다. 또한 네트워크 연결, Ceph 및 NFS 또는 SFTP 데이터 플레인 서비스가 중단됩니다. 이 절차의 마지막 단계에 따라 인스턴스를 생성하거나, 인스턴스를 마이그레이션하거나, 요청을 인증하거나, pacemaker 클러스터 및 컨테이너가 서비스로 돌아갈 때까지 클러스터의 상태를 모니터링할 수 없습니다.
```
(undercloud) [stack@undercloud ~]$ ansible-playbook \
    -v -i ~/tripleo-inventory.yaml \
    --extra="ansible_ssh_common_args='-o StrictHostKeyChecking=no'" \
    --become \
    --become-user root \
    --tags bar_create_recover_image \
    ~/bar_rear_create_restore_images-controller.yaml
```

3.6. cron을 사용하여 컨트롤 플레인 노드 백업 예약

중요

사전 요구 사항

백업 노드에 NFS 또는 SFTP 서버가 설치 및 구성되어 있습니다. 새 NFS 서버 생성에 대한 자세한 내용은 1.2절. “백업 노드에 NFS 서버 설치 및 구성” 을 참조하십시오.
언더클라우드 및 컨트롤 플레인 노드에 ReaR이 설치되어 있어야 합니다. 자세한 내용은 2.3절. “컨트롤 플레인 노드에 ReaR 설치”의 내용을 참조하십시오.
백업을 저장할 수 있는 디스크 공간이 백업 위치에 충분히 있습니다.

절차

언더클라우드 노드에서 다음 명령을 입력하여 백업 스크립트를 생성합니다.

[stack@undercloud ~]$ cat <<'EOF' > /home/stack/execute-rear-cron.sh

#!/bin/bash

OWNER="stack"
TODAY=`date +%Y%m%d`
FILE="/var/log/rear-cron.${TODAY}"
sudo touch ${FILE}
sudo chown ${OWNER}:${OWNER} ${FILE}

CURRENTTIME=`date`
echo "[$CURRENTTIME] rear start" >> ${FILE}
source /home/stack/stackrc && /usr/bin/openstack overcloud backup 2>&1 >> ${FILE}
CURRENTTIME=`date`
echo "[$CURRENTTIME] rear end" >> ${FILE}
EOF

/home/stack/execute-rear-cron.sh 스크립트에 대한 실행 가능 권한을 설정합니다.
```
[stack@undercloud ~]$ chmod 755 /home/stack/execute-rear-cron.sh
```
crontab -e 명령으로 crontab 파일을 편집하고 선택한 편집기를 사용하여 다음 cron 작업을 추가합니다. 변경 사항을 파일에 저장해야 합니다.
```
[stack@undercloud ~]# $ crontab -e
#adding the following line
0 0 * * * /home/stack/execute-rear-cron.sh
```
/home/stack/execute-rear-cron.sh 스크립트는 stack 사용자가 자정에 의해 실행되도록 예약되었습니다.
cron 작업이 예약되었는지 확인하려면 다음 명령을 입력합니다.
```
[stack@undercloud ~]$ crontab -l
```
명령 출력에는 예약된 cron 작업이 표시됩니다.
```
0 0 * * * /home/stack/execute-rear-cron.sh
```

3.7. 추가 리소스

구성 가능 서비스 및 사용자 정의 역할

4장. 언더클라우드 및 컨트롤 플레인 노드 복원

언더클라우드 또는 컨트롤 플레인 노드가 손상되거나 업데이트 또는 업그레이드 중에 오류가 발생하면 백업에서 이전 상태로 언더클라우드 또는 오버클라우드 컨트롤 플레인 노드를 복원할 수 있습니다. 복원 프로세스가 공동 배치된 Ceph 모니터가 있는 Galera 클러스터 또는 노드를 자동으로 복원하지 못하면 이러한 구성 요소를 수동으로 복원할 수 있습니다.

4.1. 복원 프로세스를 위해 Ceph 모니터가 있는 컨트롤 플레인 준비

배치된 Ceph 모니터로 컨트롤 플레인을 복원하기 전에 Ceph 모니터 백업 파일을 노드 파일 시스템에 마운트하는 스크립트를 생성하고 ReaR이 백업 파일을 찾는 데 사용하는 스크립트를 생성하여 환경을 준비합니다.

중요

/var/lib/ceph 디렉토리를 백업할 수 없는 경우 Red Hat 기술 지원 팀에 문의하여 ceph-mon 인덱스를 다시 빌드해야 합니다. 자세한 내용은 Red Hat 기술 지원 팀을 참조하십시오.

사전 요구 사항

언더클라우드 노드 백업을 생성했습니다. 자세한 내용은 1.5절. “언더클라우드 노드 백업 생성”의 내용을 참조하십시오.
컨트롤 플레인 노드의 백업을 생성했습니다. 자세한 내용은 2.5절. “컨트롤 플레인 노드의 백업 생성”의 내용을 참조하십시오.
백업 노드에 액세스할 수 있습니다.
네트워크 인터페이스에 OVS 브리지를 사용하는 경우 NETWORKING_PREPARATION_COMMANDS 매개변수에서 설정한 네트워크 구성 정보에 액세스할 수 있습니다. 자세한 내용은 1.4절. “백업을 위한 OVS(Open vSwitch) 인터페이스 구성” 의 내용을 참조하십시오.

절차

복원하려는 각 노드에서 /usr/share/rear/setup/default/011_backup_ceph.sh 스크립트를 생성하고 다음 콘텐츠를 추가합니다.
```
mount -t <file_type> <device_disk> /mnt/local
cd /mnt/local
[ -d "var/lib/ceph" ] && tar cvfz /tmp/ceph.tar.gz var/lib/ceph --xattrs --xattrs-include='.' --acls
cd /
umount <device_disk>
```
<file_type> 및 <device_disk> 를 백업 파일의 유형 및 위치로 바꿉니다. 일반적으로 파일 유형은 xfs 이며 위치는 /dev/vda2 입니다.

동일한 노드에서 /usr/share/rear/wrapup/default/501_restore_ceph.sh 스크립트를 만들고 다음 콘텐츠를 추가합니다.

if [ -f "/tmp/ceph.tar.gz" ]; then
  rm -rf /mnt/local/var/lib/ceph/*
  tar xvC /mnt/local -f /tmp/ceph.tar.gz var/lib/ceph --xattrs --xattrs-include='.'
fi

추가 리소스

4.2절. “언더클라우드 노드 복원”
4.3절. “컨트롤 플레인 노드 복원”

4.2. 언더클라우드 노드 복원

ReaR을 사용하여 생성한 백업 ISO 이미지를 사용하여 언더클라우드 노드를 이전 상태로 복원할 수 있습니다. 백업 ISO 이미지는 백업 노드에서 찾을 수 있습니다. 부팅 가능한 ISO 이미지를 DVD로 굽거나 iLO(Integrated Lights-Out) 원격 액세스를 통해 언더클라우드 노드에 다운로드합니다.

사전 요구 사항

언더클라우드 노드 백업을 생성했습니다. 자세한 내용은 2.5절. “컨트롤 플레인 노드의 백업 생성”의 내용을 참조하십시오.
백업 노드에 액세스할 수 있습니다.
네트워크 인터페이스에 OVS 브리지를 사용하는 경우 NETWORKING_PREPARATION_COMMANDS 매개변수에서 설정한 네트워크 구성 정보에 액세스할 수 있습니다. 자세한 내용은 1.4절. “백업을 위한 OVS(Open vSwitch) 인터페이스 구성” 의 내용을 참조하십시오.

절차

Undercloud 노드의 전원을 끕니다. 진행하기 전에 언더클라우드 노드의 전원이 완전히 꺼져 있는지 확인합니다.
백업 ISO 이미지로 Undercloud 노드를 부팅합니다.
Relax-and- recovery 부팅 메뉴가 표시되면 recovery <undercloud_node> 를 선택합니다. <undercloud_node> 를 언더클라우드 노드 이름으로 교체합니다.
참고
시스템에서 UEFI를 사용하는 경우 Relax-and- recover (no Secure Boot) 옵션을 선택합니다.
root 사용자로 로그인하여 노드를 복원합니다.
다음 메시지가 표시됩니다.
```
Welcome to Relax-and-Recover. Run "rear recover" to restore your system!
RESCUE <undercloud_node>:~ # rear recover
```
언더클라우드 노드 복원 프로세스가 완료되면 콘솔에 다음 메시지가 표시됩니다.
```
Finished recovering your system
Exiting rear recover
Running exit tasks
```
노드의 전원을 끕니다.
```
RESCUE <undercloud_node>:~ #  poweroff
```
부팅 시 노드는 이전 상태를 재개합니다.

4.3. 컨트롤 플레인 노드 복원

업데이트 또는 업그레이드 중에 오류가 발생하면 ReaR을 사용하여 생성한 백업 ISO 이미지를 사용하여 컨트롤 플레인 노드를 이전 상태로 복원할 수 있습니다. 컨트롤 플레인을 복원하려면 상태 일관성을 보장하기 위해 모든 컨트롤 플레인 노드를 복원해야 합니다.

백업 ISO 이미지는 백업 노드에서 찾을 수 있습니다. 부팅 가능한 ISO 이미지를 DVD로 굽거나 iLO(Integrated Lights-Out) 원격 액세스를 통해 언더클라우드 노드에 다운로드합니다.

참고

Red Hat은 OVS(Open vSwitch) 및 기본 OVN(Open Virtual Network)과 같은 기본 SDN을 사용하여 Red Hat OpenStack Platform 백업을 지원합니다. 타사 SDN에 대한 자세한 내용은 타사 SDN 문서를 참조하십시오.

사전 요구 사항

다음 옵션 중 하나를 선택하십시오.
- 구성 가능한 역할 없이 컨트롤 플레인 노드의 백업을 생성했습니다. 자세한 내용은 2.5절. “컨트롤 플레인 노드의 백업 생성”의 내용을 참조하십시오.
- 구성 가능한 역할을 사용하는 컨트롤 플레인 노드의 백업을 생성했습니다. 자세한 내용은 3.5절. “구성 가능한 역할을 사용하는 컨트롤 플레인 노드의 백업 생성”의 내용을 참조하십시오.
백업 노드에 액세스할 수 있습니다.
네트워크 인터페이스에 OVS 브리지를 사용하는 경우 NETWORKING_PREPARATION_COMMANDS 매개변수에서 설정한 네트워크 구성 정보에 액세스할 수 있습니다. 자세한 내용은 2.4절. “백업을 위한 OVS(Open vSwitch) 인터페이스 구성” 의 내용을 참조하십시오.

절차

각 컨트롤 플레인 노드의 전원을 끕니다. 계속하기 전에 컨트롤 플레인 노드의 전원이 완전히 꺼져 있는지 확인합니다.
해당 백업 ISO 이미지로 각 컨트롤 플레인 노드를 부팅합니다.
Relax-and- recovery 부팅 메뉴가 표시되면 각 컨트롤 플레인 노드에서 recovery <control_plane_node> 를 선택합니다. <control_plane_node> 를 해당 컨트롤 플레인 노드의 이름으로 바꿉니다.
참고
시스템에서 UEFI를 사용하는 경우 Relax-and- recover (no Secure Boot) 옵션을 선택합니다.
각 컨트롤 플레인 노드에서 root 사용자로 로그인하여 노드를 복원합니다.
다음 메시지가 표시됩니다.
```
Welcome to Relax-and-Recover. Run "rear recover" to restore your system!
RESCUE <control_plane_node>:~ # rear recover
```
컨트롤 플레인 노드 복원 프로세스가 완료되면 콘솔에 다음 메시지가 표시됩니다.
```
Finished recovering your system
Exiting rear recover
Running exit tasks
```
명령줄 콘솔을 사용할 수 있는 경우 각 컨트롤 플레인 노드의 config- drive 파티션을 복원하십시오.
```
# once completed, restore the config-drive partition (which is ISO9660)
RESCUE <control_plane_node>:~ $ dd if=/mnt/local/mnt/config-drive of=<config_drive_partition>
```
참고
구성 가능한 역할을 사용하여 컨트롤 플레인을 배포한 경우 컨트롤러 노드에서만 이 단계를 수행합니다.

노드의 전원을 끕니다.

RESCUE <control_plane_node>:~ #  poweroff

부팅 시퀀스를 일반 부팅 장치로 설정합니다. 부팅 시 노드는 이전 상태를 재개합니다.
서비스가 올바르게 실행 중인지 확인하려면 pacemaker의 상태를 확인합니다. 컨트롤러 노드에 root 사용자로 로그인하고 다음 명령을 입력합니다.
```
# pcs status
```
Overcloud 상태를 보려면 OpenStack Integration Test Suite(tempest)를 사용합니다. 자세한 내용은 Integration Test Suite(tempest)를 사용하여 OpenStack 클라우드 검증 을 참조하십시오.

문제 해결

다음 명령을 실행하여 pcs 상태로 표시되는 리소스 알람을 지웁니다.

 # pcs resource clean

다음 명령을 실행하여 pcs 상태로 표시되는 STONITH 펜싱 작업 오류를 지웁니다.

# pcs resource clean
# pcs stonith history cleanup

4.4. Galera 클러스터 수동 복원

Galera 클러스터가 복원 절차의 일부로 복원되지 않으면 Galera를 수동으로 복원해야 합니다.

참고

이 절차에서는 하나의 컨트롤러 노드에서 일부 단계를 수행해야 합니다. 절차를 진행하는 것과 동일한 컨트롤러 노드에서 다음 단계를 수행해야 합니다.

절차

Controller-0 에서 Galera 클러스터 가상 IP를 검색합니다.
```
$ sudo hiera -c /etc/puppet/hiera.yaml mysql_vip
```
모든 컨트롤러 노드에서 가상 IP를 통해 데이터베이스 연결을 비활성화합니다.
```
$ sudo iptables -I INPUT  -p tcp --destination-port 3306 -d $MYSQL_VIP  -j DROP
```

Controller-0 에서 MySQL root 암호를 검색합니다.

$ sudo hiera -c /etc/puppet/hiera.yaml mysql::server::root_password

Controller-0 에서 Galera 리소스를 Unmanaged 모드로 설정합니다.
```
$ sudo pcs resource unmanage galera-bundle
```

모든 컨트롤러 노드에서 MySQL 컨테이너를 중지합니다.

$ sudo podman container stop $(sudo podman container ls --all --format "{{.Names}}" --filter=name=galera-bundle)

모든 컨트롤러 노드에서 현재 디렉터리를 이동합니다.
```
$ sudo mv /var/lib/mysql /var/lib/mysql-save
```

모든 컨트롤러 노드에 새 디렉토리 /var/lib/mysq 를 생성합니다.

$ sudo mkdir /var/lib/mysql
$ sudo chown 42434:42434 /var/lib/mysql
$ sudo chcon -t container_file_t /var/lib/mysql
$ sudo chmod 0755 /var/lib/mysql
$ sudo chcon -r object_r /var/lib/mysql
$ sudo chcon -u system_u /var/lib/mysql

모든 컨트롤러 노드에서 MySQL 컨테이너를 시작합니다.

$ sudo podman container start $(sudo podman container ls --all --format "{{ .Names }}" --filter=name=galera-bundle)

모든 컨트롤러 노드에서 MySQL 데이터베이스를 생성합니다.

$ sudo podman exec -i $(sudo podman container ls --all --format "{{ .Names }}" \
      --filter=name=galera-bundle) bash -c "mysql_install_db --datadir=/var/lib/mysql --user=mysql --log_error=/var/log/mysql/mysql_init.log"

모든 컨트롤러 노드에서 데이터베이스를 시작합니다.

$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \
      --filter=name=galera-bundle) bash -c "mysqld_safe --skip-networking --wsrep-on=OFF --log-error=/var/log/mysql/mysql_safe.log" &

모든 컨트롤러 노드에서 .my.cnf Galera 구성 파일을 이동합니다.

$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \
      --filter=name=galera-bundle) bash -c "mv /root/.my.cnf /root/.my.cnf.bck"

모든 컨트롤러 노드에서 Galera root 암호를 재설정합니다.

$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}"  \
      --filter=name=galera-bundle) bash -c "mysql -uroot -e'use mysql;update user set password=PASSWORD(\"$ROOTPASSWORD\")where User=\"root\";flush privileges;'"

모든 컨트롤러 노드에서 Galera 컨테이너 내부에 .my.cnf Galera 구성 파일을 복원합니다.

$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}"   \
      --filter=name=galera-bundle) bash -c "mv /root/.my.cnf.bck /root/.my.cnf"

Controller-0 에서 백업 데이터베이스 파일을 /var/lib/MySQL 에 복사합니다.
```
$ sudo cp $BACKUP_FILE /var/lib/mysql
$ sudo cp $BACKUP_GRANT_FILE /var/lib/mysql
```
참고
이러한 파일의 경로는 /home/heat-admin/입니다.

Controller-0 에서 MySQL 데이터베이스를 복원합니다.

$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}"    \
--filter=name=galera-bundle) bash -c "mysql -u root -p$ROOT_PASSWORD < \"/var/lib/mysql/$BACKUP_FILE\"  "

$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}"    \
--filter=name=galera-bundle) bash -c "mysql -u root -p$ROOT_PASSWORD < \"/var/lib/mysql/$BACKUP_GRANT_FILE\"  "

모든 컨트롤러 노드에서 데이터베이스를 종료합니다.

$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}"    \
      --filter=name=galera-bundle) bash -c "mysqladmin shutdown"

Controller-0 에서 부트스트랩 노드를 시작합니다.

$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}"  --filter=name=galera-bundle) \
        /usr/bin/mysqld_safe --pid-file=/var/run/mysql/mysqld.pid --socket=/var/lib/mysql/mysql.sock --datadir=/var/lib/mysql \
        --log-error=/var/log/mysql/mysql_cluster.log  --user=mysql --open-files-limit=16384 \
        --wsrep-cluster-address=gcomm:// &

검증: Controller-0에서 클러스터 상태를 확인합니다.
```
$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \
         --filter=name=galera-bundle) bash -c "clustercheck"
```
다음 메시지가 표시되는지 확인합니다. "Galera 클러스터 노드가 동기화됨", 그렇지 않으면 노드를 다시 생성해야 합니다.

Controller-0 에서 구성에서 클러스터 주소를 검색합니다.

$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \
--filter=name=galera-bundle) bash -c "grep wsrep_cluster_address /etc/my.cnf.d/galera.cnf" | awk '{print $3}'

나머지 각 컨트롤러 노드에서 데이터베이스를 시작하고 클러스터를 검증합니다.

데이터베이스를 시작합니다.

$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \
      --filter=name=galera-bundle) /usr/bin/mysqld_safe --pid-file=/var/run/mysql/mysqld.pid --socket=/var/lib/mysql/mysql.sock \
      --datadir=/var/lib/mysql --log-error=/var/log/mysql/mysql_cluster.log  --user=mysql --open-files-limit=16384 \
      --wsrep-cluster-address=$CLUSTER_ADDRESS &

MYSQL 클러스터의 상태를 확인합니다.
```
$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" \
         --filter=name=galera-bundle) bash -c "clustercheck"
```
다음 메시지가 표시되는지 확인합니다. "Galera 클러스터 노드가 동기화됨", 그렇지 않으면 노드를 다시 생성해야 합니다.

모든 컨트롤러 노드에서 MySQL 컨테이너를 중지합니다.

$ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" --filter=name=galera-bundle) \
        /usr/bin/mysqladmin -u root shutdown

모든 컨트롤러 노드에서 다음 방화벽 규칙을 제거하여 가상 IP 주소를 통한 데이터베이스 연결을 허용합니다.
```
$ sudo iptables -D  INPUT  -p tcp --destination-port 3306 -d $MYSQL_VIP  -j DROP
```

모든 컨트롤러 노드에서 MySQL 컨테이너를 다시 시작합니다.

$ sudo podman container restart $(sudo podman container ls --all --format  "{{ .Names }}" --filter=name=galera-bundle)

모든 컨트롤러 노드에서 clustercheck 컨테이너를 다시 시작합니다.

$ sudo podman container restart $(sudo podman container ls --all --format  "{{ .Names }}" --filter=name=clustercheck)

Controller-0 에서 Galera 리소스를 관리 모드로 설정합니다.
```
$ sudo pcs resource manage galera-bundle
```

검증

서비스가 올바르게 실행 중인지 확인하려면 pacemaker의 상태를 확인합니다.
```
$ sudo pcs status
```
Overcloud 상태를 보려면 OpenStack Integration Test Suite(tempest)를 사용합니다. 자세한 내용은 Integration Test Suite(tempest)를 사용하여 OpenStack 클라우드 검증 을 참조하십시오.
특정 노드 관련 문제가 의심되는 경우 cluster check를 사용하여 클러스터 상태를 확인하십시오.
```
$ sudo podman exec clustercheck /usr/bin/clustercheck
```

4.5. 수동으로 언더클라우드 노드 데이터베이스 복원

언더클라우드 복원 프로세스의 일부로 언더클라우드 데이터베이스를 복원하지 않으면 데이터베이스를 수동으로 복원할 수 있습니다. 이전에 독립 실행형 데이터베이스 백업을 생성한 경우에만 데이터베이스를 복원할 수 있습니다.

사전 요구 사항

언더클라우드 데이터베이스 백업을 생성했습니다. 언더클라우드 데이터베이스 백업에 대한 자세한 내용은 1.5절. “언더클라우드 노드 백업 생성” 을 참조하십시오.

절차

director 언더클라우드 노드에 root 사용자로 로그인합니다.

모든 tripleo 서비스를 중지합니다.

[root@director ~]# systemctl  stop  tripleo_*

다음 명령을 입력하여 서버에서 실행 중인 컨테이너가 없는지 확인합니다.
```
[root@director ~]# podman ps
```
컨테이너가 실행 중인 경우 다음 명령을 입력하여 컨테이너를 중지합니다.
```
[root@director ~]# podman stop <container_name>
```

현재 /var/lib/mysql 디렉터리의 백업을 생성한 다음 디렉터리를 삭제합니다.

[root@director ~]# cp -a /var/lib/mysql /var/lib/mysql_bck
[root@director ~]# rm -rf /var/lib/mysql

데이터베이스 디렉터리를 다시 생성하고 새 디렉터리의 SELinux 속성을 설정합니다.

[root@director ~]# mkdir /var/lib/mysql
[root@director ~]# chown 42434:42434 /var/lib/mysql
[root@director ~]# chmod 0755 /var/lib/mysql
[root@director ~]# chcon -t container_file_t /var/lib/mysql
[root@director ~]# chcon -r object_r /var/lib/mysql
[root@director ~]# chcon -u system_u /var/lib/mysql

mariadb 이미지의 로컬 태그를 생성합니다. <image_id> 및 <undercloud.ctlplane.example.com> 을 사용자 환경에 적용할 수 있는 값으로 바꿉니다.

[root@director ~]# podman images | grep mariadb
<undercloud.ctlplane.example.com>:8787/rh-osbs/rhosp16-openstack-mariadb                 	16.2_20210322.1   <image_id>   3 weeks ago   718 MB

[root@director ~]# podman tag <image_id> mariadb

[root@director ~]# podman images | grep maria
localhost/mariadb                                                                         	latest        	<image_id>   3 weeks ago   718 MB
<undercloud.ctlplane.example.com>:8787/rh-osbs/rhosp16-openstack-mariadb                 	16.2_20210322.1   <image_id>   3 weeks ago   718 MB

/var/lib/mysql 디렉터리를 컨테이너로 초기화합니다.

[root@director ~]# podman run --net=host -v /var/lib/mysql:/var/lib/mysql localhost/mariadb mysql_install_db --datadir=/var/lib/mysql --user=mysql

데이터베이스로 가져올 데이터베이스 백업 파일을 복사합니다.
```
[root@director ~]# cp /root/undercloud-all-databases.sql /var/lib/mysql
```

데이터베이스 서비스를 시작하여 데이터를 가져옵니다.

[root@director ~]# podman run --net=host -dt -v /var/lib/mysql:/var/lib/mysql  localhost/mariadb  /usr/libexec/mysqld

데이터를 가져오고 max_allowed_packet 매개변수를 구성합니다.

컨테이너에 로그인하여 구성합니다.

[root@director ~]# podman exec -it <container_id> /bin/bash
    ()[mysql@5a4e429c6f40 /]$ mysql -u root -e "set global max_allowed_packet = 1073741824;"
    ()[mysql@5a4e429c6f40 /]$ mysql -u root < /var/lib/mysql/undercloud-all-databases.sql
    ()[mysql@5a4e429c6f40 /]$ mysql -u root -e 'flush privileges'
    ()[mysql@5a4e429c6f40 /]$ exit
    exit

컨테이너를 중지합니다.

[root@director ~]# podman stop <container_id>

실행 중인 컨테이너가 없는지 확인합니다.

[root@director ~]# podman ps
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES
[root@director ~]#

모든 tripleo 서비스를 다시 시작하십시오.
```
[root@director ~]# systemctl start multi-user.target
```

법적 공지

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.

Select Your Language

Infrastructure and Management

Cloud Computing

Storage

Runtimes

Integration and Automation

언더클라우드 및 컨트롤 플레인 노드 백업 및 복원

언더클라우드 및 오버클라우드 컨트롤 플레인 노드의 백업 생성 및 복원

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

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

1장. 언더클라우드 노드 백업

1.1. 지원되는 백업 형식 및 프로토콜

1.2. 백업 노드에 NFS 서버 설치 및 구성

1.3. 언더클라우드 노드에 ReaR 설치

1.4. 백업을 위한 OVS(Open vSwitch) 인터페이스 구성

1.5. 언더클라우드 노드 백업 생성

2장. 컨트롤 플레인 노드 백업

2.1. 지원되는 백업 형식 및 프로토콜

2.2. 백업 노드에 NFS 서버 설치 및 구성

2.3. 컨트롤 플레인 노드에 ReaR 설치

2.4. 백업을 위한 OVS(Open vSwitch) 인터페이스 구성

2.5. 컨트롤 플레인 노드의 백업 생성

2.6. cron을 사용하여 컨트롤 플레인 노드 백업 예약

3장. 구성 가능 역할을 사용하는 컨트롤 플레인 노드 백업

3.1. 지원되는 백업 형식 및 프로토콜

3.2. 백업 노드에 NFS 서버 설치 및 구성

3.3. 컨트롤 플레인 노드에 ReaR 설치

3.4. 백업을 위한 OVS(Open vSwitch) 인터페이스 구성

3.5. 구성 가능한 역할을 사용하는 컨트롤 플레인 노드의 백업 생성

3.6. cron을 사용하여 컨트롤 플레인 노드 백업 예약

3.7. 추가 리소스

4장. 언더클라우드 및 컨트롤 플레인 노드 복원

4.1. 복원 프로세스를 위해 Ceph 모니터가 있는 컨트롤 플레인 준비

4.2. 언더클라우드 노드 복원

4.3. 컨트롤 플레인 노드 복원

4.4. Galera 클러스터 수동 복원

4.5. 수동으로 언더클라우드 노드 데이터베이스 복원

법적 공지

Language and Page Formatting Options

언더클라우드 및 컨트롤 플레인 노드 백업 및 복원

언더클라우드 및 오버클라우드 컨트롤 플레인 노드의 백업 생성 및 복원

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

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

1장. 언더클라우드 노드 백업

1.1. 지원되는 백업 형식 및 프로토콜

1.2. 백업 노드에 NFS 서버 설치 및 구성

1.3. 언더클라우드 노드에 ReaR 설치

1.4. 백업을 위한 OVS(Open vSwitch) 인터페이스 구성

1.5. 언더클라우드 노드 백업 생성

2장. 컨트롤 플레인 노드 백업

2.1. 지원되는 백업 형식 및 프로토콜

2.2. 백업 노드에 NFS 서버 설치 및 구성

2.3. 컨트롤 플레인 노드에 ReaR 설치

2.4. 백업을 위한 OVS(Open vSwitch) 인터페이스 구성

2.5. 컨트롤 플레인 노드의 백업 생성

2.6. cron을 사용하여 컨트롤 플레인 노드 백업 예약

3장. 구성 가능 역할을 사용하는 컨트롤 플레인 노드 백업

3.1. 지원되는 백업 형식 및 프로토콜

3.2. 백업 노드에 NFS 서버 설치 및 구성

3.3. 컨트롤 플레인 노드에 ReaR 설치

3.4. 백업을 위한 OVS(Open vSwitch) 인터페이스 구성

3.5. 구성 가능한 역할을 사용하는 컨트롤 플레인 노드의 백업 생성

3.6. cron을 사용하여 컨트롤 플레인 노드 백업 예약

3.7. 추가 리소스

4장. 언더클라우드 및 컨트롤 플레인 노드 복원

4.1. 복원 프로세스를 위해 Ceph 모니터가 있는 컨트롤 플레인 준비

4.2. 언더클라우드 노드 복원

4.3. 컨트롤 플레인 노드 복원

4.4. Galera 클러스터 수동 복원

4.5. 수동으로 언더클라우드 노드 데이터베이스 복원

법적 공지