OpenStack Virtual Machine on Ceph Crash After Power Loss [Part 1]

OpenStack Virtual Machine on Ceph Crash After Power Loss [Part 1]

Câu chuyện lần này là về việc các máy ảo trên Cloud OpenStack của chúng tôi luôn bị crash khi compute node đột ngột bị restart khi chập chờn nguồn điện cấp hay lỗi phần cứng.

  • Ceph: Jewel & Mimic
  • OpenStack: Queens & Rocky

Quả thực, lúc đầu tôi nghĩ là do cache của rbd trên compute node vì nghĩ compute node tắt đột ngột quá là file system bị lỗi chăng. Nhưng lỗi kiểu này thì bình thường fsck là xong ấy thế mà lại không áp dụng để fix được. Chúng tôi đã thử tăng giảm cache để thử nghiệm vì nghĩ chắc mình chưa tuning gì nên nó lởm, cũng vẫn không được!

Sau đó, tôi có tham khảo anh em trong cộng đồng OpenInfra tại Việt Nam và các trang mailing list về Ceph cũng như OpenStack thì được biết là rất nhiều người gặp lỗi này và cũng chưa có câu trả lời thỏa đáng.

Bẵng đi một thời gian vì task dồn đống nên tôi chưa nghiên cứu tiếp được. Trong lúc này, chúng tôi sử dụng cách rebuild object-map của Ceph image cho mỗi lần compute bị đột tử và nó hiệu quả ^^

[[email protected] ~]# rbd object-map rebuild volumes/volume-5bd54eb9-b181-4d10-b6cd-8ae6841edcf5
Object Map Rebuild: 100% complete...done.

Dạo gần đây, tôi tìm hiểu thêm thì được biết anh em sử dụng OpenShift, Ceph container hay Rock cũng bị và một cách để tránh việc lỗi này là disable exclusive-lock của image. Chợt nhớ ra là OpenStack cũng tạo Ceph image và enable exclusive-lock. Tôi quyết định bắt tay ngay vào việc debug và tìm hiểu xem OpenStack và Ceph thì có gì đặc biệt, kết quả như sau:

Trước khi reset compute node từ giao diện quản trị

[[email protected] ~]# rbd object-map rebuild volumes/volume-5bd54eb9-b181-4d10-b6cd-8ae6841edcf5
Object Map Rebuild: 100% complete...done.
[[email protected] ~]# rbd lock ls vms/0cab75e6-5cb0-46ff-a8ac-872f1a5c6023_disk
There is 1 exclusive lock on this image.
Locker           ID                  Address
client.247961907 auto 94049029718016 10.240.201.139:0/2548741492

Reset compute node, máy ảo bị crash, kể cả hard reboot cũng không giải quyết được –> Lúc này lock của image vẫn y chang như cũ.

Thực hiện remove lock và hard reboot –> Máy ảo hoạt động trở lại bình thường

rbd lock rm vms/0cab75e6-5cb0-46ff-a8ac-872f1a5c6023_disk "auto 94541455753216" client.247662578

Ngoài ra, lock của các Ceph image (hay OpenStack volume) cũng thay đổi mỗi khi soft/hard reboot máy ảo OpenStack.

Trước và sau khi hard reboot

Trước[[email protected] ~]# rbd lock ls vms/45a318d6-17b3-49ad-a5f0-8c69a5c5667c_disk\
There is 1 exclusive lock on this image.
Locker           ID                  Address
client.247695590 auto 94122114498560 10.240.201.139:0/214440748
Sau[[email protected] ~]# rbd lock ls vms/45a318d6-17b3-49ad-a5f0-8c69a5c5667c_disk
There is 1 exclusive lock on this image.
Locker           ID                  Address
client.248021391 auto 93872108527616 10.240.201.139:0/72018164

Trước và sau khi soft reboot

Trước[[email protected] ~]# rbd lock ls vms/45a318d6-17b3-49ad-a5f0-8c69a5c5667c_disk
There is 1 exclusive lock on this image.
Locker           ID                  Address
client.248021391 auto 93872108527616 10.240.201.139:0/72018164
Sau[[email protected] ~]# rbd lock ls vms/45a318d6-17b3-49ad-a5f0-8c69a5c5667c_disk
There is 1 exclusive lock on this image.
Locker           ID                  Address
client.247698080 auto 94867447029760 10.240.201.139:0/1055129882

Tới đây, có thể thấy với các trường hợp bình thường, OpenStack hoàn toàn có thể điều khiển để release lock cũ và cấp phát lock mới. Đối với trường hợp compute node bị lỗi, chúng ta có thể kiểm soát vấn đề bằng cách thực hiện xóa bỏ lock cũ đi bằng tay và reboot máy ảo, máy ảo sẽ hoạt động lại bình thường.

[[email protected] ~]# rbd lock rm vms/0cab75e6-5cb0-46ff-a8ac-872f1a5c6023_disk "auto 94541455753216" client.247662578

Vậy nguyên nhân gốc đã được tìm ra, tuy nhiên OpenStack đã làm gì để xử lý trường hợp này và cần chỉnh sửa cấu hình ra sao để việc remove lock là hoàn toàn tự động khi compute node đột ngột reboot? Bài đã hơi dài nên các vấn đề này tôi xin được đề cập ở phần 2.

Posted on