[openstack] openstack vm instance recovery (인스턴스 복구)
기억이 온전할때 정리를 했어야 했는데 시간이 많이 흘러 이제서야 정리한다.
(어디까지 나의 기억을 믿지 못해 적는 것이오니 이글을 보고 도움이 되실수도 있고 안되실 수도 있다)
잘못된 부분이 있거나 추가해야 할 부분이 있다면 언제든지 알려주시면 감사합니다. !! :)
openstack 을 운영하고 있던 중 정전에 따른 서버 down으로 instance 및 DB가 비정상적으로 종료 되면서 openstack 내 instance들이 정상적으로 동작하지 않는 현상이 발생하였다.
1. 상황
- 정전(비정상전원차단) 이 발생
- openstack controller, compute node들이 비정상적으로 shutdown
- 비정상 종료에 따른 디스크내 베드 섹터 발생
- maria DB의 innodb 깨짐
- VM Instance 정보 중 일부가 사라짐 ( 왜 사라졌는지는 아직도 미궁임)
2. 환경
- OS : ubuntu 16.04
- openstack version : newton
- 구성 : controller 1ea, compute node 4ea
- 비고 : 백업 구성은 되어 있지 않음
필자의 경우 복구 순서는 아래와 같다. (간략히 말하자면......)
1. 새로운 H/W 시스템에 openstack controller(NEW_Controller)를 설치한다.
2. 이전 시스템(OLD_Controller) 에서 openstck config 와 DB, image등을 백업한다. ( 백업이 되는데까지 백업한다. )
3. 백업된 DATA를 새로운 시스템(New_controller)에 업로드한다.
4. 새로운 시스템(New_controller)에서 mysql(maria db) 를 복구 한다.
5. DB를 기동하고 나머지 openstack 서비스 daemon는 stop 해준다.
6. DB내 Instance 필요 정보를 확인한다.
7. compute node로 이동하여 qemu-img tool을 이용하여 이미지는 복구한다.
8. 복구한 이미지는 복사 또는 업로드 하기 쉽게 converting 작업을 한다. (이미지 사이즈 축소 작업)
9. 새로운 controller (New_controller)에 복구한 이미지를 업로드 한다.
10. 이미지 업로드가 완료 되면 업로드 된 이미지를 이용하여 Instance 를 배포한다.
11. 정상적으로 배포가 되는지 확인하고 해당 Instance가 이상없으면 스냅샷 또는 이미지를 생성하여 다시 백업한다.
11-1. 정상적으로 배포가 되지 않을 경우 DB정보를 다시 한번 확인하면서 6번 부터 다시 진행한다.
위 순서로만 보면 간단해 보이지만 실제 진행을 해보면 작업 시간도 오래 걸리고 한번에 된다는 보장도 없는거 같다.
복구해본 결과 centos/rhel7계열에서는 복구가 대체로 쉬웠지만 그 이하 os version에서는 무언가의 특성을 타고 있어 정상적으로 동작하던 Instance의 정보와 정확히 일치 하지 않으면 복구가 제대로 되지 않은 현상이 있다.
이제는 단계별 기억이 받쳐주는 대로 상세하게 적어 본다.
Start.........!!!
Step 1. openstack controller node 설치(New_controller)
필자의 경우 필자 마음대로 만든 Install script가 있어 해당 script 를 통해 쉽게 install 하였다.
Controller 설치 과정은 Pass!!!!
Step 2. Old_Controller에서 DATA백업
백업 대상은 아래와 같다.
openstack daemon config 백업
: glance, nova, neutron, horizon 등
DB 백업 : /var/lib/mysql
DB Config 백업 : /etc/mysql/mariadb.conf.d/99-openstack.cnf
이미지 백업 : glance 에 업로드 하였던 이미지 파일 백업 (qcow2확장자 파일)
예시 )
Step 3. 백업 된 DATA를 New_Controller에 업로드 한다.
SCP를 이용해도 되고 USB를 이용해도 되고 사용하기 편한 방법을 이용하여 업로드한다.
Step 4. DB를 복구 한다.
DB복구 방법은 DB기동 실패 로그에 따라 달라진다. 필자의 경우 Innodb자체가 깨졌기 때문에 복구방법이 좀 까다로웠다.
DB복구 방법 참고 -> 작성중!!!
Step 5. 복구된 DB를 이용하여 DB를 기동한다.
# service mysql restart
Step 6. DB에 접속하여 DB 조회가 되는지 확인한다.
가장 중요한 nova/glance Database가 조회되어야 한다.
sql문 : select nova.image_ref,glance.id,glance.name,nova.display_name,nova.host,nova.uuid from instances as nova right join glance.images as glance ON nova.image_ref = glance.id where nova.display_name like "rhel%";
예시)
MariaDB [nova]> select nova.image_ref,glance.id,glance.name,nova.display_name,nova.host,nova.uuid from instances as nova right join glance.images as glance ON nova.image_ref = glance.id where nova.display_name like "rhel%";
+--------------------------------------+--------------------------------------+------------------+------------------+------------+--------------------------------------+
| image_ref | id | name | display_name | host | uuid |
+--------------------------------------+--------------------------------------+------------------+------------------+------------+--------------------------------------+
| 6e8fef9a-f86f-43f0-bca4-8dfeead8ba01 | 6e8fef9a-f86f-43f0-bca4-8dfeead8ba01 | rhel_7.6_default | rhel_7.6_default | devosnova4 | d49aec95-af4c-41cf-b57a-46788761b115 |
| db459642-0a22-436b-b837-15d47dff738e | db459642-0a22-436b-b837-15d47dff738e | rhel_7.3 | rhel_7.3_default | devosnova4 | baaeb63b-0fba-4264-a05d-e91a5c95f4a3 |
+--------------------------------------+--------------------------------------+------------------+------------------+------------+--------------------------------------+
** 쿼리문은 nova databases와 glance databases를 right조인하여 출력되도록 하였고 각 field의 정보는 아래와 같다.
- image_ref : 해당 Instance 가 참조하는 baseimage
- id : 해당 Instance의 Glance ID
- Name : Instance 가 사용하는 glance image name
- Display_name : openstack dashboard에서 보여지는 이름
- host : 해당 instance가 동작되고 있는 hostmachine(compute node)정보
- UUID : 해당 instance의 UUID
Step 7. 해당 host machine으로 접속하여 이미지 복구 작업을 진행한다. (여기서부터 작업이 복잡할 수 있다.)
7-1. ssh나 telnet 등으로 해당 Instance가 있는 동작되던 host machine으로 접속한다.
7-2./var/lib/nova/instances/ 하위에 복구하고자 하는 Instance의 UUID로 이동한다.
예를 들어 복구하는 instance의 UUID 가 "43160183-b9b1-4f9d-aa3e-526cbf0fdde9" 일 경우 아래와 같이 이동 및 확인 한다.
# cd /var/lib/nova/instances/43160183-b9b1-4f9d-aa3e-526cbf0fdde9
root@nova3:/var/lib/nova/instances/43160183-b9b1-4f9d-aa3e-526cbf0fdde9# ls -al
total 20181260
drwxr-xr-x 2 nova nova 54 1월 16 13:41 .
drwxr-xr-x 9 nova nova 309 2월 21 08:58 ..
-rw-r--r-- 1 libvirt-qemu kvm 1 1월 16 13:42 console.log
-rw-r--r-- 1 libvirt-qemu kvm 20665860096 2월 21 17:28 disk
-rw-r--r-- 1 nova nova 79 1월 16 13:36 disk.info
root@nova3:/var/lib/nova/instances/43160183-b9b1-4f9d-aa3e-526cbf0fdde9#
해당 경로에 가면 "disk"라는 파일이 있는데 이것이 실제 VM Instance들이 동작하는 파일이다.
"disk"파일을 qemu-img tool 로 확인을 해보면 "backing file"이라는 filed가 조회되는데
이때 backing file에 명시되는 파일이 복구하고자 하는 이미지의 base image인 셈이다.
root@nova3:/var/lib/nova/instances/43160183-b9b1-4f9d-aa3e-526cbf0fdde9# qemu-img info disk
image: disk
file format: qcow2
virtual size: 50G (53687091200 bytes)
disk size: 19G
cluster_size: 65536
backing file: /var/lib/nova/instances/_base/40ec4786433a98be5e8782ebe7564877f2d6a582
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
root@nova3:/var/lib/nova/instances/43160183-b9b1-4f9d-aa3e-526cbf0fdde9# ls -al /var/lib/nova/instances/_base/40ec4786433a98be5e8782ebe7564877f2d6a582
-rw-r--r-- 1 libvirt-qemu kvm 53687091200 2월 21 16:54 /var/lib/nova/instances/_base/40ec4786433a98be5e8782ebe7564877f2d6a582
root@nova3:/var/lib/nova/instances/43160183-b9b1-4f9d-aa3e-526cbf0fdde9#
"backing file" filed의 경로에 파일이 있는지가 여기서 제일 중요한데 없을 경우 이미지를 복구할 수가 없다.
(필자의 경우엔 없었음, 비슷한 이미지를 가지고 복구를 시도하였지만 booting 도중에 실패함.)
7-3 backing file 복구는 의외로 간단하다.
backing file의 이미지는 step 6단계에서 찾은 정보로 복구할수 있다.
(물론 이미지 파일이 존재한다는 가정하에 말이다.)
예시 ) base image가 "rhel_7.6_default.qcow2"일 경우
USAGE) # scp base_image_name.qcow2 root@hostmachine: backing_file_path_name
# scp rhel_7.6_default.qcow2 root@nova3:/var/lib/nova/instances/_base/40ec4786433a98be5e8782ebe7564877f2d6a582
7-4 Instance복구
"disk"라는 파일이 있는 곳에서 실행하거나 절대 경로를 입력해주면 된다.
USAGE) # qemu-img convert -f qcow2 -O qcow2 disk 새로저장될이미지.qcow2 -p
# qemu-img convert -f qcow2 -O qcow2 disk 새로저장될이미지.qcow2 -p
qemu-img convert라는 명령어 및 옵션을 이용하여 base image와 disk file을 merge하여 하나의 이미지 파일로 변환한다.
** qemu-img command에 대해서는 여기를 참고 한다. -> 작성중!!!!
Step 8. 복구 이미지 축소
생성된 이미지는 qcow2라는 확장자 파일로 생성된다. 이때 생성된 파일 사이즈가 클수 있고 파일 사이즈가 클경우 복사 및 업로드에 상당시간이 소요 될수 있으니 아래 방법으로 이미지 파일의 사이즈를 축소할 수 있다.
** qcow2파일에 따라 사이즈 축소가 잘 될수도 있고 안될 수도 있다. 이미 한번 사이즈 축소한 파일에 대해서는 축소가 미미하다.
USAGE ) qemu-img convert -O qcow2 -c INPUT_FILENAME.qcow2 OUTPUT_FILENANE.qcow2
예시 ) 사이즈 축소 전
# openstack@controller:~$ qemu-img info CentOS-6.8-1695.qcow2
image: CentOS-6.8-1695.qcow2
file format: qcow2
virtual size: 8.0G (8589934592 bytes)
disk size: 694M
cluster_size: 65536
Format specific information:
compat: 0.10
qemu-img tool을 이용한 이미지 사이즈 축소
# openstack@controller:~$ qemu-img convert -O qcow2 -c \
> CentOS-6.8-1695.qcow2 \
> output_CentOS-6.8-1695.qcow2
예시 ) 사이즈 축소 후
# openstack@controller:~$ qemu-img info output_CentOS-6.8-1695.qcow2
image: output_CentOS-6.8-1695.qcow2
file format: qcow2
virtual size: 8.0G (8589934592 bytes)
disk size: 252M
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
corrupt: false
Step 9. 이미지 업로드
7-4 에서 복구된 이미지 파일을 new_controller 장비로 복사/이동하고 glance image-create 명령어를 이용하여 해당 이미지를 업로드한다.
예시)
# source admin-openrc ## admin접속을 위한 환경변수를 로딩한다.(openstack 설치 참고)
(admin-openrc)# glance image-create \
> --name CentOS-6.8-1695 \
> --file output_CentOS-6.8-1695.qcow2 \
> --disk-format qcow2 \
> --container-format bare \
> --visibility public \
> --progress
[=============================>] 100%
+------------------+--------------------------------------+
| Property | Value |
+------------------+--------------------------------------+
| checksum | 405169b157989d437e24ddc6d44a9e41 |
| container_format | bare |
| created_at | 2019-02-22T00:38:05Z |
| disk_format | qcow2 |
| id | 06353799-b761-49e7-9936-d9ed21a8c04d |
| min_disk | 0 |
| min_ram | 0 |
| name | CentOS-6.8-1695 |
| owner | 5cde9e930378421a97e0c441f9681ac9 |
| protected | False |
| size | 265438720 |
| status | active |
| tags | [] |
| updated_at | 2019-02-22T00:38:06Z |
| virtual_size | None |
| visibility | public |
+------------------+--------------------------------------+
Step 10. Instance Deploy (인스턴스 배포)
openstack dashboard 또는 CLI환경에서 업로드한 이미지를 가지고 Instance를 생성한다.
(배포작업 생략)
Step 11. Instance상태 확인
Instance가 정상적으로 배포가 되어 접속이 가능한지 확인한다. 만에 정상적으로 booting이 되지 않고 있을 경우 backing file이 잘못된 것일 수 있으니 Step 6 부터 다시 진행한다.
작업을 마치며.....
운이 좋게 위에 방법으로 해결이 되었는지는 모르겠으나 몇일간의 검색과 복구 사례를 찾아 봤을때 쉽게 찾지 못하는 어려움이 많았다.
두서 없고 기억이 나는대로 적었지만 누군가에게 작은 도움이 되었으면 좋겠다.
혹시 라도 잘못된 부분이 있다면 언제든지 댓글을 달아 주십시요~~
위에 방법대로 할때 이해가 안되는 부분이 있을 경우에도 댓글 달아 주시면 필자가 알고 있는 선과 시간이 되는 선에서는 성실히 답변 달아 드리겠습니다. ~