Red Hat OpenStack Platform 백업 및 복원
Director 언더클라우드 백업 및 복원
초록
1장. 언더클라우드 백업 및 복원
이 가이드에서는 Red Hat OpenStack Platform director에서 사용된 언더클라우드를 백업하는 방법을 설명합니다. 언더클라우드는 일반적으로 OpenStack 환경을 배포 및 관리하는 데 사용되는 단일 물리적 노드(VM에서 director를 실행하는 2-노드 pacemaker 클러스터를 사용하여 고가용성 옵션이 있음)입니다.
1.1. 백업 고려 사항
데이터 손실 및 시스템 다운 타임을 최소화하기 위해 강력한 백업 및 복구 정책을 공식화하십시오. 백업 전략을 결정할 때 다음 질문에 대답해야 합니다.
- 데이터 손실에서 얼마나 신속하게 복구해야합니까? 데이터 손실이 전혀 없을 수 없는 경우 백업 사용 외에도 배포 전략에 고가용성을 포함해야 합니다. 물리적 백업 미디어를 가져오는 데 걸리는 시간(사용되는 경우 오프사이트 위치 포함) 및 복원 작업에 사용할 수 있는 보관 드라이브 수를 고려해야 합니다.
- 몇 개의 백업을 유지해야 합니까? 데이터를 저장해야 하는 기간에 영향을 미치는 법률 및 규제 요구 사항을 고려해야 합니다.
- 백업이 오프 사이트에서 유지되어야 합니까? 백업 미디어 오프사이트를 저장하면 물리적 위치에 심각한 영향을 미칠 위험이 완화됩니다.
- 백업을 얼마나 자주 테스트해야 합니까? 강력한 백업 전략에는 백업 데이터의 정기적인 복원 테스트가 포함됩니다. 이를 통해 올바른 데이터가 여전히 백업되고 있고 백업 또는 복원 프로세스 중에 손상이 발생하지 않는지 확인하는 데 도움이 될 수 있습니다. 이러한 드릴은 실제 재해 복구 조건에서 수행되고 있다고 가정해야 합니다.
- 백업하려면 어떻게 해야 합니까? 다음 섹션에서는 구성 요소에 대한 데이터베이스 및 파일 시스템 백업 및 백업 복구에 대한 정보를 설명합니다.
1.2. Undercloud 노드의 고가용성
언더클라우드 노드에 권장되는 HA(고가용성) 옵션을 자유롭게 고려할 수 있습니다. Red Hat은 이에 대한 특정 요구 사항을 규정하지 않습니다. 예를 들어, Red Hat Enterprise Virtualization(Red Hat Enterprise Virtualization) 내에서 Undercloud 노드를 고가용성 가상 시스템으로 실행하는 것이 좋습니다. 또한 필수 서비스에 HA를 제공하는 Pacemaker가 있는 물리 노드를 사용할 수도 있습니다.
Undercloud 노드의 고가용성에 접근할 때 환경에 가장 적합한 솔루션 설명서 및 모범 사례를 참조해야 합니다.
1.3. 언더클라우드 백업
전체 언더클라우드 백업에는 다음 데이터베이스 및 파일이 포함되어 있습니다.
- 언더클라우드 노드의 모든 MariaDB 데이터베이스
- 언더클라우드의 MariaDB 설정 파일(데이터베이스를 정확하게 복원할 수 있음)
- /var/lib/glance/images의 모든 Glance 이미지 데이터
- /srv/node의 모든 swift 데이터
- stack 사용자 홈 디렉터리의 모든 데이터: /home/stack
- /opt/stack의 모든 데이터
root 사용자로 다음 명령을 실행하여 언더클라우드 노드의 데이터를 undercloud-backup-[timestamp].tar.gz 라는 파일로 덤프합니다.
백업 프로세스를 수행하기 전에 사용 가능한 디스크 공간이 충분한지 확인합니다. tarball은 최소 3.5GB가 될 것으로 예상될 수 있지만 이는 더 클 수 있습니다.
# mysqldump --opt --all-databases > /root/undercloud-all-databases.sql # tar -czf undercloud-backup-`date +%F`.tar.gz /root/undercloud-all-databases.sql /etc/my.cnf.d/server.cnf /var/lib/glance/images /srv/node /home/stack /etc/keystone/ssl /opt/stack
1.4. 완료된 백업 확인
복원 프로세스를 실행하고 검증하여 완료된 백업 프로세스의 성공 여부를 확인할 수 있습니다. 백업에서 복원하는 방법에 대한 자세한 내용은 다음 섹션을 참조하십시오.
2장. Restore
이 섹션에서는 Red Hat OpenStack Platform Director에서 사용한 언더클라우드를 복원하는 방법을 설명합니다.
2.1. 언더클라우드 복원
다음 복원 프로세스에서는 실패한 언더클라우드 노드를 복구하고 있으며 처음부터 다시 설치해야 합니다. 하드웨어 레이아웃이 동일하고 시스템의 호스트 이름과 언더클라우드 설정도 동일합니다.
시스템이 설치되고 상태가 되면 director를 설치하고 실행하는 데 필요한 모든 서브스크립션/repositories를 다시 활성화합니다. root 사용자로 다음 명령을 실행합니다.
1. mariadb 서버를 설치합니다.
# yum install -y mariadb-server
2. MariaDB 구성 파일 및 데이터베이스 백업을 복원한 다음 MariaDB 서버를 시작하고 백업 데이터를 로드합니다.
a. root 사용자로 MariaDB 파일을 복원합니다.
# tar -xzC / -f undercloud-backup-$DATE.tar.gz etc/my.cnf.d/server.cnf # tar -xzC / -f undercloud-backup-$DATE.tar.gz root/undercloud-all-databases.sql
b. /etc/my.cnf.d/server.cnf 를 편집하고 bind-address
항목을 주석 처리합니다.
c. mariadb 서비스를 시작합니다.
# systemctl start mariadb # cat /root/undercloud-all-databases.sql | mysql
d. 특정 권한을 정리합니다. 나중에 다시 생성할 수 있습니다.
# for i in ceilometer glance heat ironic keystone neutron nova ; do mysql -e "drop user $i" ; done # mysql -e 'flush privileges'
3. stack 사용자 계정을 생성합니다.
# sudo useradd stack # sudo passwd stack # specify a password # echo "stack ALL=(root) NOPASSWD:ALL" | sudo tee -a /etc/sudoers.d/stack # sudo chmod 0440 /etc/sudoers.d/stack
4. stack 사용자 홈 디렉터리를 복원합니다.
# tar -xzC / -f undercloud-backup-$DATE.tar.gz home/stack
5. swift 및 glance 기본 패키지를 설치한 다음 데이터를 복원합니다.
# yum install -y openstack-glance openstack-swift # tar -xzC / -f undercloud-backup-$DATE.tar.gz srv/node var/lib/glance/images
6. 데이터가 올바른 사용자가 소유하고 있는지 확인합니다.
# chown -R swift: /srv/node # chown -R glance: /var/lib/glance/images
7. HAproxy SSL 인증서를 복원하십시오.
# tar -xzC / -f undercloud-backup-$DATE.tar.gz etc/keystone/ssl # semanage fcontext -a -t etc_t "/etc/keystone/ssl(/.*)?" # restorecon -R /etc/keystone/ssl
8. stack 사용자로 언더클라우드 설치를 다시 실행하여 stack 사용자 홈 디렉터리에서 실행합니다.
# su - stack $ sudo yum install -y python-tripleoclient
9. 호스트 이름이 /etc/hosts 에 올바르게 설정되어 있는지 확인합니다.
10. 언더클라우드를 다시 설치합니다.
$ openstack undercloud install
2.2. 복원된 언더클라우드를 오버클라우드에 다시 연결
위의 단계를 완료하면 언더클라우드에서 오버클라우드에 대한 연결을 자동으로 복원할 수 있습니다. 노드는 몇 초마다 발행된 간단한 HTTP 요청을 사용하여 보류 중인 작업에 대해 Orchestration(heat)을 계속 폴링합니다.
2.3. 완료된 복원 확인
다음 명령을 사용하여 새로 복원된 환경의 상태 점검을 수행합니다.
2.3.1. ID 서비스(Keystone) 작업 확인
이 단계에서는 사용자 목록을 쿼리하여 ID 서비스 작업의 유효성을 검사합니다.
# source overcloudrc # keystone user-list
컨트롤러에서 실행하는 경우 이 명령의 출력에는 사용자 환경에서 생성된 사용자 목록이 포함되어야 합니다. 이 작업은 keystone이 실행 중이고 사용자 요청을 성공적으로 인증하는 방법을 보여줍니다. 예를 들면 다음과 같습니다.
# keystone user-list +----------------------------------+------------+---------+----------------------+ | id | name | enabled | email | +----------------------------------+------------+---------+----------------------+ | 9e47bb53bb40453094e32eccce996828 | admin | True | root@localhost | | 9fe2466f88cc4fa0ba69e59b47898829 | ceilometer | True | ceilometer@localhost | | 7a40d944e55d422fa4e85daf47e47c42 | cinder | True | cinder@localhost | | 3d2ed97538064f258f67c98d1912132e | demo | True | | | 756e73a5115d4e9a947d8aadc6f5ac22 | glance | True | glance@localhost | | f0d1fcee8f9b4da39556b78b72fdafb1 | neutron | True | neutron@localhost | | e9025f3faeee4d6bb7a057523576ea19 | nova | True | nova@localhost | | 65c60b1278a0498980b2dc46c7dcf4b7 | swift | True | swift@localhost | +----------------------------------+------------+---------+----------------------+
2.3.2. OpenStack 서비스 확인
openstack-status 명령을 실행하여 OpenStack 서비스의 상태를 확인합니다.
# openstack-status