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

Red Hat OpenStack Platform 16.2

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

초록

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

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

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

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

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

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

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

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

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

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

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

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

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

다음 목록은 ReaR을 사용하여 언더클라우드 및 컨트롤 플레인을 백업 및 복원할 때 Red Hat OpenStack Platform에서 지원하는 백업 형식 및 프로토콜을 보여줍니다.

부팅 가능한 미디어 형식
  • ISO
파일 전송 프로토콜
  • SFTP
  • NFS

1.2. 백업 스토리지 위치 구성

컨트롤 플레인 노드의 백업을 생성하기 전에 bar-vars.yaml 환경 파일에서 백업 스토리지 위치를 구성합니다. 이 파일은 백업 실행에 전달할 키-값 매개변수를 저장합니다.

절차

  1. bar-vars.yaml 파일에서 백업 스토리지 위치를 구성합니다.

    1. NFS 서버를 사용하는 경우 tripleo_backup_and_restore_server 매개변수를 추가하고 해당 값을 NFS 서버의 IP 주소로 설정합니다.

      tripleo_backup_and_restore_server: <ip_address>

      기본적으로 tripleo_backup_and_restore_server 매개변수 값은 192.168.24.1 입니다.

    2. SFTP 서버를 사용하는 경우 tripleo_backup_and_restore_output_url 매개변수를 추가하고 SFTP 서버의 URL 및 인증 정보 값을 설정합니다.

      tripleo_backup_and_restore_output_url: sftp://<user>:<password>@<backup_node>/
      tripleo_backup_and_restore_backup_url: iso:///backup/

      <user>, <password>, <backup_node> 를 백업 노드 URL 및 자격 증명으로 바꿉니다.

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

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

중요
  • NFS 또는 SFTP 서버를 이전에 설치 및 구성한 경우 이 절차를 완료할 필요가 없습니다. 백업할 노드에 ReaR을 설정할 때 서버 정보를 입력합니다.
  • 기본적으로 NFS 서버의 Relax 및 Recover(ReaR) IP 주소 매개변수는 192.168.24.1 입니다. 환경과 일치하는 IP 주소 값을 설정하려면 tripleo_backup_and_restore_server 매개변수를 추가해야 합니다.

절차

  1. 언더클라우드 노드에서 언더클라우드 인증 정보를 가져옵니다.

    [stack@undercloud ~]$ source stackrc
    (undercloud) [stack@undercloud ~]$
  2. 언더클라우드 노드에서 백업 노드의 인벤토리 파일을 생성합니다.

    (undercloud) [stack@undercloud ~]$ cat <<'EOF'> ~/nfs-inventory.yaml
    [BackupNode]
    <backup_node> ansible_host=<ip_address> ansible_user=<user>
    EOF

    <ip_address><user> 를 환경에 적용되는 값으로 바꿉니다.

  3. Undercloud 노드에서 백업 노드로 공용 SSH 키를 복사합니다.

    (undercloud) [stack@undercloud ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub <backup_node>

    <backup_node> 를 백업 노드의 경로 및 이름으로 바꿉니다.

  4. 백업 노드에서 NFS 서버를 구성합니다.

    (undercloud) [stack@undercloud ~]$ openstack undercloud backup --setup-nfs --extra-vars /home/stack/bar-vars.yaml --inventory /home/stack/nfs-inventory.yaml

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

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

사전 요구 사항

절차

  1. 언더클라우드 노드에서 언더클라우드 인증 정보를 가져옵니다.

    [stack@undercloud ~]$ source stackrc

    사용자 지정 스택 이름을 사용하는 경우 tripleo-ansible-inventory 명령에 --stack <stack_name> 옵션을 추가합니다.

  2. 이전에 수행하지 않은 경우 인벤토리 파일을 생성하고 tripleo-ansible-inventory 명령을 사용하여 모든 오버클라우드 노드의 호스트 및 변수가 포함된 정적 인벤토리 파일을 생성합니다.

    (undercloud) [stack@undercloud ~]$ tripleo-ansible-inventory \
    --ansible_ssh_user heat-admin \
    --static-yaml-inventory /home/stack/tripleo-inventory.yaml
  3. 언더클라우드 노드에 ReaR을 설치합니다.

    (undercloud) [stack@undercloud ~]$ openstack undercloud backup --setup-rear --extra-vars /home/stack/bar-vars.yaml --inventory /home/stack/tripleo-inventory.yaml
  4. 시스템에서 UEFI 부트 로더를 사용하는 경우 언더클라우드 노드에서 다음 단계를 수행합니다.

    1. 다음 툴을 설치합니다.

      $ sudo dnf install dosfstools efibootmgr
    2. USING_UEFI_BOOTLOADER 매개변수 값 01 로 교체하여 /etc/rear/local.conf 에 있는 ReaR 구성 파일에서 UEFI 백업을 활성화합니다.

1.5. 언더클라우드 노드의 독립 실행형 데이터베이스 백업 생성

Red Hat OpenStack Platform 환경을 13에서 16.2로 업그레이드하는 경우 언더클라우드 업그레이드를 수행한 후 언더클라우드 노드에서 Leapp 업그레이드 프로세스를 수행하기 전에 독립 실행형 데이터베이스 백업을 생성해야 합니다.

추가 데이터 보안을 제공하기 위해 필요에 따라 일상적인 백업 일정에 독립 실행형 언더클라우드 데이터베이스 백업을 포함할 수 있습니다. 언더클라우드 노드의 전체 백업에는 언더클라우드 노드의 데이터베이스 백업이 포함됩니다. 그러나 전체 언더클라우드 복원이 실패하면 전체 언더클라우드 백업의 데이터베이스 부분에 대한 액세스 권한이 손실될 수 있습니다. 이 경우 독립 실행형 언더클라우드 데이터베이스 백업에서 데이터베이스를 복구할 수 있습니다.

절차

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

    openstack undercloud backup --db-only

    db 백업 파일은 openstack-backup-mysql-<timestamp>.sql이라는 이름으로 /home/stack 에 저장됩니다.

1.6. 백업을 위한 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.7. 언더클라우드 노드 백업 생성

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

Red Hat OpenStack Platform 환경을 13에서 16.2로 업그레이드하는 경우 언더클라우드 업그레이드를 수행한 후 오버클라우드 노드에서 Leapp 업그레이드 프로세스를 수행하기 전에 별도의 데이터베이스 백업을 생성해야 합니다. 자세한 내용은 1.5절. “언더클라우드 노드의 독립 실행형 데이터베이스 백업 생성”의 내용을 참조하십시오.

사전 요구 사항

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. MySQL 루트 암호를 검색합니다.

    [stack@undercloud ~]$ PASSWORD=$(sudo /bin/hiera -c /etc/puppet/hiera.yaml mysql::server::root_password)
  3. 언더클라우드 노드의 데이터베이스 백업을 생성합니다.

    [stack@undercloud ~]$ sudo podman exec mysql bash -c "mysqldump -uroot -p$PASSWORD --opt --all-databases" | sudo tee /root/undercloud-all-databases.sql
  4. source 명령으로 언더클라우드 인증 정보를 가져옵니다.

    [stack@undercloud ~]$ source stackrc
  5. 이전에 수행하지 않은 경우 인벤토리 파일을 생성하고 tripleo-ansible-inventory 명령을 사용하여 모든 오버클라우드 노드의 호스트 및 변수가 포함된 정적 인벤토리 파일을 생성합니다.

    (undercloud) [stack@undercloud ~]$ tripleo-ansible-inventory \
    --ansible_ssh_user heat-admin \
    --static-yaml-inventory /home/stack/tripleo-inventory.yaml
  6. 언더클라우드 노드의 백업을 생성합니다.

    (undercloud) [stack@undercloud ~]$ openstack undercloud backup --inventory /home/stack/tripleo-inventory.yaml

1.8. cron으로 언더클라우드 노드 백업 예약

Ansible backup-and-restore 역할을 사용하여 ReaR으로 언더클라우드 노드의 백업을 예약할 수 있습니다. /var/log/rear-cron 디렉토리에서 로그를 볼 수 있습니다.

사전 요구 사항

절차

  1. 컨트롤 플레인 노드의 백업을 예약하려면 다음 명령을 실행합니다. 기본 일정은 자정의 남아 있는 토요일입니다.

    openstack undercloud backup --cron
  2. 선택 사항: 배포에 따라 예약된 백업을 사용자 지정합니다.

    • 기본 백업 일정을 변경하려면 tripleo_backup_and_restore_cron 매개변수에서 다른 cron 일정을 전달합니다.

      openstack undercloud backup --cron --extra-vars
      '{"tripleo_backup_and_restore_cron": "0 0 * * 0"}'
    • cron이 예약된 백업을 실행할 때 backup 명령에 추가된 추가 매개변수를 정의하려면 다음 예와 같이 tripleo_backup_and_restore_cron_extra 매개변수를 backup 명령에 전달합니다.

      openstack undercloud backup --cron --extra-vars '{"tripleo_backup_and_restore_cron_extra":"--extra-vars bar-vars.yaml --inventory /home/stack/tripleo-inventory.yaml"}'
    • 백업을 실행하는 기본 사용자를 변경하려면 다음 예와 같이 tripleo_backup_and_restore_restore_cron_user 매개변수를 backup 명령에 전달합니다.

      openstack undercloud backup --cron --extra-vars '{"tripleo_backup_and_restore_cron_user": "root"}

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

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

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

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

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

다음 목록은 ReaR을 사용하여 언더클라우드 및 컨트롤 플레인을 백업 및 복원할 때 Red Hat OpenStack Platform에서 지원하는 백업 형식 및 프로토콜을 보여줍니다.

부팅 가능한 미디어 형식
  • ISO
파일 전송 프로토콜
  • SFTP
  • NFS

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

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

중요
  • NFS 또는 SFTP 서버를 이전에 설치 및 구성한 경우 이 절차를 완료할 필요가 없습니다. 백업할 노드에 ReaR을 설정할 때 서버 정보를 입력합니다.
  • 기본적으로 NFS 서버의 Relax 및 Recover(ReaR) IP 주소 매개변수는 192.168.24.1 입니다. 환경과 일치하는 IP 주소 값을 설정하려면 tripleo_backup_and_restore_server 매개변수를 추가해야 합니다.

절차

  1. 언더클라우드 노드에서 언더클라우드 인증 정보를 가져옵니다.

    [stack@undercloud ~]$ source stackrc
    (undercloud) [stack@undercloud ~]$
  2. 언더클라우드 노드에서 백업 노드의 인벤토리 파일을 생성합니다.

    (undercloud) [stack@undercloud ~]$ cat <<'EOF'> ~/nfs-inventory.yaml
    [BackupNode]
    <backup_node> ansible_host=<ip_address> ansible_user=<user>
    EOF

    <ip_address><user> 를 환경에 적용되는 값으로 바꿉니다.

  3. Undercloud 노드에서 백업 노드로 공용 SSH 키를 복사합니다.

    (undercloud) [stack@undercloud ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub <backup_node>

    <backup_node> 를 백업 노드의 경로 및 이름으로 바꿉니다.

  4. 백업 노드에서 NFS 서버를 구성합니다.

    (undercloud) [stack@undercloud ~]$ openstack undercloud backup --setup-nfs --extra-vars /home/stack/bar-vars.yaml --inventory /home/stack/nfs-inventory.yaml

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

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

중요

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

사전 요구 사항

절차

  1. 언더클라우드 노드에서 언더클라우드 인증 정보를 가져옵니다.

    [stack@undercloud ~]$ source stackrc
  2. 이전에 수행하지 않은 경우 인벤토리 파일을 생성하고 tripleo-ansible-inventory 명령을 사용하여 모든 오버클라우드 노드의 호스트 및 변수가 포함된 정적 인벤토리 파일을 생성합니다.

    (undercloud) [stack@undercloud ~]$ tripleo-ansible-inventory \
    --ansible_ssh_user heat-admin \
    --static-yaml-inventory /home/stack/tripleo-inventory.yaml
  3. 컨트롤 플레인 노드에 ReaR을 설치합니다.

    (undercloud) [stack@undercloud ~]$ openstack overcloud backup --setup-rear --extra-vars /home/stack/bar-vars.yaml --inventory /home/stack/tripleo-inventory.yaml
  4. bar-vars.yaml 파일에서 백업 스토리지 위치를 구성합니다.

    1. 자체 NFS 서버를 설치하고 구성한 경우 tripleo_backup_and_restore_server 매개변수를 추가하고 값을 NFS 서버의 IP 주소로 설정합니다.

      tripleo_backup_and_restore_server: <ip_address>

      기본적으로 tripleo_backup_and_restore_server 매개변수 값은 192.168.24.1 입니다.

    2. SFTP 서버를 사용하는 경우 tripleo_backup_and_restore_output_url 매개변수를 추가하고 SFTP 서버의 URL 및 인증 정보 값을 설정합니다.

      tripleo_backup_and_restore_output_url: sftp://<user>:<password>@<backup_node>/
      tripleo_backup_and_restore_backup_url: iso:///backup/

      <user>, <password>, <backup_node> 를 백업 노드 URL 및 자격 증명으로 바꿉니다.

  5. 시스템에서 UEFI 부트 로더를 사용하는 경우 컨트롤 플레인 노드에서 다음 단계를 수행합니다.

    1. 다음 툴을 설치합니다.

      $ sudo dnf install dosfstools efibootmgr
    2. USING_UEFI_BOOTLOADER 매개변수 값 01 로 교체하여 /etc/rear/local.conf 에 있는 ReaR 구성 파일에서 UEFI 백업을 활성화합니다.

2.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 명령을 추가하여 인터페이스 이름을 설정할 수 있습니다. 네트워크 구성에 따라 매개변수에 명령을 추가할 수 있습니다.

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

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

사전 요구 사항

절차

  1. 각 컨트롤 플레인 노드에서 config-drive 파티션을 찾습니다.

    [stack@undercloud ~]$ lsblk
    NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
    vda    253:0    0   55G  0 disk
    ├─vda1 253:1    0    1M  0 part            1
    ├─vda2 253:2    0  100M  0 part /boot/efi
    └─vda3 253:3    0 54.9G  0 part /
    1
    config-drive 파티션은 마운트되지 않은 1M 파티션입니다.
  2. 각 컨트롤 플레인 노드에서 root 사용자로 각 노드의 config- drive 파티션을 백업합니다.

    [root@controller-x ~]# dd if=<config_drive_partition> of=/mnt/config-drive

    & lt;config_drive_partition >을 1 단계에 있는 config-drive 파티션의 이름으로 바꿉니다.

  3. 언더클라우드 노드에서 언더클라우드 인증 정보를 가져옵니다.

    [stack@undercloud ~]$ source stackrc
  4. 이전에 수행하지 않은 경우 tripleo-ansible-inventory 명령을 사용하여 모든 오버클라우드 노드의 호스트 및 변수가 포함된 정적 인벤토리 파일을 생성합니다.

    (undercloud) [stack@undercloud ~]$ tripleo-ansible-inventory \
    --ansible_ssh_user heat-admin \
    --static-yaml-inventory /home/stack/tripleo-inventory.yaml
  5. 컨트롤 플레인 노드의 백업을 생성합니다.

    (undercloud) [stack@undercloud ~]$ openstack overcloud backup --inventory /home/stack/tripleo-inventory.yaml

    백업 프로세스는 환경에 대한 서비스를 중단하지 않고 각 컨트롤 플레인 노드에서 순차적으로 실행됩니다.

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

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

사전 요구 사항

절차

  1. 컨트롤 플레인 노드의 백업을 예약하려면 다음 명령을 실행합니다. 기본 일정은 자정의 남아 있는 토요일입니다.

    openstack overcloud backup --cron
  2. 선택 사항: 배포에 따라 예약된 백업을 사용자 지정합니다.

    • 기본 백업 일정을 변경하려면 tripleo_backup_and_restore_cron 매개변수에서 다른 cron 일정을 전달합니다.

      openstack overcloud backup --cron --extra-vars
      '{"tripleo_backup_and_restore_cron": "0 0 * * 0"}'
    • cron이 예약된 백업을 실행할 때 backup 명령에 추가된 추가 매개변수를 정의하려면 다음 예와 같이 tripleo_backup_and_restore_cron_extra 매개변수를 backup 명령에 전달합니다.

      openstack overcloud backup --cron --extra-vars '{"tripleo_backup_and_restore_cron_extra":"--extra-vars bar-vars.yaml --inventory /home/stack/tripleo-inventory.yaml"}'
    • 백업을 실행하는 기본 사용자를 변경하려면 다음 예와 같이 tripleo_backup_and_restore_restore_cron_user 매개변수를 backup 명령에 전달합니다.

      openstack overcloud backup --cron --extra-vars '{"tripleo_backup_and_restore_cron_user": "root"}

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

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

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

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

중요

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

사전 요구 사항

절차

  1. 복원하려는 각 노드에서 /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 입니다.

  2. 동일한 노드에서 /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

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

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

사전 요구 사항

절차

  1. Undercloud 노드의 전원을 끕니다. 진행하기 전에 언더클라우드 노드의 전원이 완전히 꺼져 있는지 확인합니다.
  2. 백업 ISO 이미지로 Undercloud 노드를 부팅합니다.
  3. Relax-and- recovery 부팅 메뉴가 표시되면 recovery <undercloud_node> 를 선택합니다. <undercloud_node> 를 언더클라우드 노드 이름으로 교체합니다.

    참고

    시스템에서 UEFI를 사용하는 경우 Relax-and- recover (no Secure Boot) 옵션을 선택합니다.

  4. 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
  5. 노드의 전원을 끕니다.

    RESCUE <undercloud_node>:~ #  poweroff

    부팅 시 노드는 이전 상태를 재개합니다.

3.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 문서를 참조하십시오.

사전 요구 사항

절차

  1. 각 컨트롤 플레인 노드의 전원을 끕니다. 계속하기 전에 컨트롤 플레인 노드의 전원이 완전히 꺼져 있는지 확인합니다.
  2. 해당 백업 ISO 이미지로 각 컨트롤 플레인 노드를 부팅합니다.
  3. Relax-and- recovery 부팅 메뉴가 표시되면 각 컨트롤 플레인 노드에서 recovery <control_plane_node> 를 선택합니다. <control_plane_node> 를 해당 컨트롤 플레인 노드의 이름으로 바꿉니다.

    참고

    시스템에서 UEFI를 사용하는 경우 Relax-and- recover (no Secure Boot) 옵션을 선택합니다.

  4. 각 컨트롤 플레인 노드에서 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
  5. 명령줄 콘솔을 사용할 수 있으면 각 컨트롤 플레인 노드의 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>
  6. 노드의 전원을 끕니다.

    RESCUE <control_plane_node>:~ #  poweroff
  7. 부팅 시퀀스를 일반 부팅 장치로 설정합니다. 부팅 시 노드는 이전 상태를 재개합니다.
  8. 서비스가 올바르게 실행 중인지 확인하려면 pacemaker의 상태를 확인합니다. 컨트롤러 노드에 root 사용자로 로그인하고 다음 명령을 입력합니다.

    # pcs status
  9. Overcloud 상태를 보려면 OpenStack Integration Test Suite(tempest)를 사용합니다. 자세한 내용은 Integration Test Suite(tempest)를 사용하여 OpenStack 클라우드 검증 을 참조하십시오.

문제 해결

  • 다음 명령을 실행하여 pcs 상태로 표시되는 리소스 알람을 지웁니다.
 # pcs resource clean
  • 다음 명령을 실행하여 pcs 상태로 표시되는 STONITH 펜싱 작업 오류를 지웁니다.
# pcs resource clean
# pcs stonith history cleanup

3.4. Galera 클러스터 수동 복원

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

참고

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

절차

  1. Controller-0 에서 Galera 클러스터 가상 IP를 검색합니다.

    $ sudo hiera -c /etc/puppet/hiera.yaml mysql_vip
  2. 모든 컨트롤러 노드에서 가상 IP를 통해 데이터베이스 연결을 비활성화합니다.

    $ sudo iptables -I INPUT  -p tcp --destination-port 3306 -d $MYSQL_VIP  -j DROP
  3. Controller-0 에서 MySQL root 암호를 검색합니다.

    $ sudo hiera -c /etc/puppet/hiera.yaml mysql::server::root_password
  4. Controller-0 에서 Galera 리소스를 Unmanaged 모드로 설정합니다.

    $ sudo pcs resource unmanage galera-bundle
  5. 모든 컨트롤러 노드에서 MySQL 컨테이너를 중지합니다.

    $ sudo podman container stop $(sudo podman container ls --all --format "{{.Names}}" --filter=name=galera-bundle)
  6. 모든 컨트롤러 노드에서 현재 디렉터리를 이동합니다.

    $ sudo mv /var/lib/mysql /var/lib/mysql-save
  7. 모든 컨트롤러 노드에 새 디렉토리 /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
  8. 모든 컨트롤러 노드에서 MySQL 컨테이너를 시작합니다.

    $ sudo podman container start $(sudo podman container ls --all --format "{{ .Names }}" --filter=name=galera-bundle)
  9. 모든 컨트롤러 노드에서 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"
  10. 모든 컨트롤러 노드에서 데이터베이스를 시작합니다.

    $ 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" &
  11. 모든 컨트롤러 노드에서 .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"
  12. 모든 컨트롤러 노드에서 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;'"
  13. 모든 컨트롤러 노드에서 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"
  14. Controller-0 에서 백업 데이터베이스 파일을 /var/lib/MySQL 에 복사합니다.

    $ sudo cp $BACKUP_FILE /var/lib/mysql
    $ sudo cp $BACKUP_GRANT_FILE /var/lib/mysql
    참고

    이러한 파일의 경로는 /home/heat-admin/입니다.

  15. 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\"  "
  16. 모든 컨트롤러 노드에서 데이터베이스를 종료합니다.

    $ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}"    \
          --filter=name=galera-bundle) bash -c "mysqladmin shutdown"
  17. 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:// &
  18. 검증: Controller-0에서 클러스터 상태를 확인합니다.

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

    다음 메시지가 표시되는지 확인합니다. "Galera 클러스터 노드가 동기화됨", 그렇지 않으면 노드를 다시 생성해야 합니다.

  19. 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}'
  20. 나머지 각 컨트롤러 노드에서 데이터베이스를 시작하고 클러스터를 검증합니다.

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

      $ 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 &
    2. MYSQL 클러스터의 상태를 확인합니다.

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

      다음 메시지가 표시되는지 확인합니다. "Galera 클러스터 노드가 동기화됨", 그렇지 않으면 노드를 다시 생성해야 합니다.

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

    $ sudo podman exec $(sudo podman container ls --all --format "{{ .Names }}" --filter=name=galera-bundle) \
            /usr/bin/mysqladmin -u root shutdown
  22. 모든 컨트롤러 노드에서 다음 방화벽 규칙을 제거하여 가상 IP 주소를 통한 데이터베이스 연결을 허용합니다.

    $ sudo iptables -D  INPUT  -p tcp --destination-port 3306 -d $MYSQL_VIP  -j DROP
  23. 모든 컨트롤러 노드에서 MySQL 컨테이너를 다시 시작합니다.

    $ sudo podman container restart $(sudo podman container ls --all --format  "{{ .Names }}" --filter=name=galera-bundle)
  24. 모든 컨트롤러 노드에서 clustercheck 컨테이너를 다시 시작합니다.

    $ sudo podman container restart $(sudo podman container ls --all --format  "{{ .Names }}" --filter=name=clustercheck)
  25. Controller-0 에서 Galera 리소스를 관리 모드로 설정합니다.

    $ sudo pcs resource manage galera-bundle

검증

  1. 서비스가 올바르게 실행 중인지 확인하려면 pacemaker의 상태를 확인합니다.

    $ sudo pcs status
  2. Overcloud 상태를 보려면 OpenStack Integration Test Suite(tempest)를 사용합니다. 자세한 내용은 Integration Test Suite(tempest)를 사용하여 OpenStack 클라우드 검증 을 참조하십시오.
  3. 특정 노드 관련 문제가 의심되는 경우 cluster check를 사용하여 클러스터 상태를 확인하십시오.

    $ sudo podman exec clustercheck /usr/bin/clustercheck

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

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

사전 요구 사항

절차

  1. director 언더클라우드 노드에 root 사용자로 로그인합니다.
  2. 모든 tripleo 서비스를 중지합니다.

    [root@director ~]# systemctl  stop  tripleo_*
  3. 다음 명령을 입력하여 서버에서 실행 중인 컨테이너가 없는지 확인합니다.

    [root@director ~]# podman ps

    컨테이너가 실행 중인 경우 다음 명령을 입력하여 컨테이너를 중지합니다.

    [root@director ~]# podman stop <container_name>
  4. 현재 /var/lib/mysql 디렉터리의 백업을 생성한 다음 디렉터리를 삭제합니다.

    [root@director ~]# cp -a /var/lib/mysql /var/lib/mysql_bck
    [root@director ~]# rm -rf /var/lib/mysql
  5. 데이터베이스 디렉터리를 다시 생성하고 새 디렉터리의 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
  6. 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
  7. /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
  8. 데이터베이스로 가져올 데이터베이스 백업 파일을 복사합니다.

    [root@director ~]# cp /root/undercloud-all-databases.sql /var/lib/mysql
  9. 데이터베이스 서비스를 시작하여 데이터를 가져옵니다.

    [root@director ~]# podman run --net=host -dt -v /var/lib/mysql:/var/lib/mysql  localhost/mariadb  /usr/libexec/mysqld
  10. 데이터를 가져오고 max_allowed_packet 매개변수를 구성합니다.

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

      [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
    2. 컨테이너를 중지합니다.

      [root@director ~]# podman stop <container_id>
    3. 실행 중인 컨테이너가 없는지 확인합니다.

      [root@director ~]# podman ps
      CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES
      [root@director ~]#
  11. 모든 tripleo 서비스를 다시 시작하십시오.

    [root@director ~]# systemctl start multi-user.target

법적 공지

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