[Openstack] Cinder 볼륨 생성시 error 상태가 발생하는 경우 조치

blog post 

 

Cinder 서비스를 통해 볼륨 생성 테스트를 진행하던 도중, 생성된 볼륨이 error 상태로 바뀌는 현상이 발생했습니다. 사실 해결 방법은 생각보다 간단했지만, 이를 알아내기가 쉽지 않았습니다. 제가 경험한 현상을 이번 포스트를 통해 공유합니다. 혹시 글을 보시고 같은 현상을 겪고 계신 분이라면 참고하시면 좋을 것 같습니다.

 

우선 저의 경우, 블록 스토리지 노드를 새로 구축 후, 볼륨 생성 테스트를 진행했습니다. 볼륨 생성 후 곧바로 상태를 확인해보니 아래와 같이 볼륨 상태가 곧바로 'error'로 변경된 것을 볼 수 있었습니다.

 

[root@Controller ~]# openstack volume create --size 1 disk01 
[root@Controller ~]# openstack volume list
+--------------------------------------+--------+--------+------+-------------+
| ID                                   | Name   | Status | Size | Attached to |
+--------------------------------------+--------+--------+------+-------------+
| 6e9e7b09-d427-4f49-896b-5ec5be5f82fd | disk01 | error  |    1 |             |
+--------------------------------------+--------+--------+------+-------------+

 

이후 /var/log/cinder/schelduler.log 를 통해 로그를 확인해 보니 아래와 같이 "volume service is down. (host: Storage@lvm)" 메시지를 확인할 수 있었습니다.

 

2020-02-26 16:32:07.203 85916 WARNING cinder.scheduler.host_manager [req-0295deeb-8671-4c49-8d58-5670de6ef7d5 - - - - -] volume service is down. (host: Storage@lvm)
2020-02-26 16:32:18.679 85916 WARNING cinder.scheduler.host_manager [req-9c7ba6a4-50c6-4a1a-8a5c-18c2d9647fbf c738d0412121495eaf80bece7a859a3d 9626ec30dfd74a1488e67b23aa19fa01 - default default] volume service is down. (host: Storage@lvm)
2020-02-26 16:32:18.680 85916 INFO cinder.scheduler.base_filter [req-9c7ba6a4-50c6-4a1a-8a5c-18c2d9647fbf c738d0412121495eaf80bece7a859a3d 9626ec30dfd74a1488e67b23aa19fa01 - default default] Filtering removed all hosts for the request with volume ID '90c2d706-f3d5-4375-bed1-4d8332894391'. Filter results: AvailabilityZoneFilter: (start: 0, end: 0), CapacityFilter: (start: 0, end: 0), CapabilitiesFilter: (start: 0, end: 0)
2020-02-26 16:32:18.680 85916 WARNING cinder.scheduler.filter_scheduler [req-9c7ba6a4-50c6-4a1a-8a5c-18c2d9647fbf c738d0412121495eaf80bece7a859a3d 9626ec30dfd74a1488e67b23aa19fa01 - default default] No weighed backend found for volume with properties: None
2020-02-26 16:32:18.681 85916 INFO cinder.message.api [req-9c7ba6a4-50c6-4a1a-8a5c-18c2d9647fbf c738d0412121495eaf80bece7a859a3d 9626ec30dfd74a1488e67b23aa19fa01 - default default] Creating message record for request_id = req-9c7ba6a4-50c6-4a1a-8a5c-18c2d9647fbf
2020-02-26 16:32:18.687 85916 ERROR cinder.scheduler.flows.create_volume [req-9c7ba6a4-50c6-4a1a-8a5c-18c2d9647fbf c738d0412121495eaf80bece7a859a3d 9626ec30dfd74a1488e67b23aa19fa01 - default default] Failed to run task cinder.scheduler.flows.create_volume.ScheduleCreateVolumeTask;volume:create: No valid backend was found. No weighed backends available: NoValidBackend: No valid backend was found. No weighed backends available

 

 

구축한 블록 스토리지 노드 상태를 확인해보니 state가 down 되었네요.

 

[root@Controller ~]# openstack volume service list                                       
                                                                                         
+------------------+-------------+------+---------+-------+----------------------------+
| Binary           | Host        | Zone | Status  | State | Updated At                 |
+------------------+-------------+------+---------+-------+----------------------------+
| cinder-scheduler | Controller  | nova | enabled | up    | 2020-02-26T07:27:05.000000 |
| cinder-volume    | Storage@lvm | nova | enabled | down  | 2020-02-26T05:52:08.000000 |
+------------------+-------------+------+---------+-------+----------------------------+

 

하지만 Cinder 스토리지는 정상적으로 잘 돌아가고 있습니다. cinder volume 서비스 상태도 아래와 같이 정상이구요.

 

[root@Storage ~]# systemctl status openstack-cinder-volume
● openstack-cinder-volume.service - OpenStack Cinder Volume Server
   Loaded: loaded (/usr/lib/systemd/system/openstack-cinder-volume.service; enabled; vendor preset: disabled)
   Active: active (running) since 수 2020-02-26 14:49:21 KST; 1 months 13 days ago
 Main PID: 11973 (cinder-volume)
   CGroup: /system.slice/openstack-cinder-volume.service
           ├─11973 /usr/bin/python2 /usr/bin/cinder-volume --config-file /usr/share/cinder/cinder-dist.conf -...
           └─11996 /usr/bin/python2 /usr/bin/cinder-volume --config-file /usr/share/cinder/cinder-dist.conf -...

 

 

다시한번 scheduler 로그를 유심히 살펴보던 중, 이상한 점을 발견할 수 있습니다. 로깅 날짜가 2020년 2월 16일...

 

 

시스템 날짜를 살펴보니 date가 한참 과거네요.

 

[root@Controller ~]# date
2020. 02. 26. (수) 16:52:17 KST

 

chronyc 명령을 사용하여 양쪽 노드를 현재 시간과 동기화 해줍니다.

 

//Controller node
[root@Controller ~]# chronyc -a makestep
200 OK
[root@Controller ~]# date
2020. 04. 10. (금) 17:09:54 KST

//Storage node
[root@Storage ~]# chronyc -a makestep
200 OK
[root@Storage ~]# date
2020. 04. 10. (금) 17:10:05 KST

 

 다음으로 컨트롤러 노드에서 cinder 관련 서비스 재시작해 봅니다.

 

[root@Controller ~]# systemctl restart openstack-cinder-api openstack-cinder-scheduler   

 

 볼륨 서비스 state가 정상적으로 up 된 것을 확인할 수 있습니다.

 

[root@Controller ~]# openstack volume service list
+------------------+-------------+------+---------+-------+----------------------------+
| Binary           | Host        | Zone | Status  | State | Updated At                 |
+------------------+-------------+------+---------+-------+----------------------------+
| cinder-scheduler | Controller  | nova | enabled | up    | 2020-04-10T08:22:07.000000 |
| cinder-volume    | Storage@lvm | nova | enabled | up    | 2020-04-10T08:22:03.000000 |
+------------------+-------------+------+---------+-------+----------------------------+

 

볼륨을 다시 생성해 보면, 

 

[root@Controller ~]# openstack volume create --size 1 disk01

 

정상적으로 생성도 되고 인스턴스에 attach 되는 것까지 볼 수 있습니다.

 

[root@Controller ~]# openstack volume list
+--------------------------------------+--------+--------+------+---------------------------------------------------------------+
| ID                                   | Name   | Status | Size | Attached to                                                   |
+--------------------------------------+--------+--------+------+---------------------------------------------------------------+
| 5aebd31b-9c5b-4ecd-800b-b63a75d74beb | disk01 | in-use |    1 | Attached to 98c1920c-1de6-4aac-bca3-0c2a2f6bad2e on /dev/vdb  |
+--------------------------------------+--------+--------+------+---------------------------------------------------------------+

 

그러면 왜 갑자기 시간 동기화가 되지 않았을까요?

 

원인은 VMWare 때문이었습니다. 저는 Compute 노드를 제외한 Controller, Network, Storage노드는 노드 자체를 VMWare 가상머신으로 생성하여 사용하고 있습니다. 이 노드들은 오픈스택을 사용할 때를 제외하면 Suspend를 걸어두는데, 이게 화근이었네요. 당시 날짜로 멈춰버리기 때문에 시간이 동기화되지 않았던 것이었습니다. 이러한 방식이 물론 일반적인 상황은 아닙니다.

 

하지만 그럼에도 불구하고, 컴퓨트 노드의 nova 서비스와는 문제 없이 연결이 잘 되는 것을 볼 수 있었습니다. 컴퓨트 노드는 물리 PC이고 이 PC는 24시간 동작 중이기 때문에 컨트롤러 노드와 더 많은 시간 차가 나죠. 인스턴스도 잘 동작하고 있었습니다. 오히려 스토리지 노드의 경우, 컨트롤러 노드와 함께 suspend를 걸어두기 때문에 시간 차이가 크게 나지 않았습니다. 이러한 부분에서 미루어 짐작해 보면, cinder volume 서비스의 경우, nova 서비스와 비교했을 때 시간 동기화 부분을 중요하게 보고 있다고 예상해 볼 수 있을 것 같습니다. 정확한 부분은 아니기 때문에 좀 더 연구해 봐야겠습니다.