Lỗi gặp phải khi migrate Rabbitmq c ủa Openstack Nova
Lần trước bên team Sang đã migrate dịch vụ Nova sang một cụm Rabbitmq mới. Ban đầu, mọi thứ dường như khá đơn giản, nhưng lại có một vấn đề.
Lời giới thiệu
Nếu các bạn đã từng làm việc với OpenStack, các bạn bạn có thể biết rằng message queue mặc định cho OpenStack là Rabbitmq. Ngoài ra, nhiều dịch vụ OpenStack khác cũng sử dụng hàng đợi đó như Cinder, Octavia, Trove...
Mô hình
Vai trò của Rabbitmq trong Nova có thể được tóm tắt như sau:
Giả sử bạn có một cụm Rabbitmq đang chạy với 3 nodes: 10.237.5.11, 10.237.5.12 và 10.237.5.13.
Để đơn giản, bên team mình sẽ mở rộng cụm Rabbitmq bằng node mới với ip 10.237.5.14, và thay đổi config của Nova gọi đến node mới đó.
Áp config mới
Thử lần đầu
Chúng ta có thể dễ dàng nghĩ đến việc thay đổi điểm cuối của Nova bằng cách áp dụng một giá trị mới cho transport_url:
[DEFAULT]
transport_url = rabbit://rabbitmq_user:rabbit_password@10.237.5.14:5672
...
[oslo_messaging_notifications]
transport_url = rabbit://rabbitmq_user:rabbit_password@10.237.5.14:5672
Áp dụng những thay đổi này và khởi động lại tất cả các dịch vụ Nova, ngạc nhiên thay, những config trên không được áp dụng hoàn toàn! Một số process bên trong nova_api chạy nhưng không phải tất cả. Sang kiểm tra thử kết nối mạng trên một node Rabbitmq, Sang có thể thấy vẫn còn một số process chưa sử dụng endpoint mới:
$ ss -npt dst :5672 | grep "10.237.5.11:5672"
ESTAB 0 0 10.237.5.11:36378 10.237.5.11:5672 users:(("nova-scheduler",pid=23458,fd=14))
ESTAB 0 0 10.237.5.11:45110 10.237.5.11:5672 users:(("nova-scheduler",pid=23412,fd=14))
ESTAB 0 0 10.237.5.11:57906 10.237.5.11:5672 users:(("nova-scheduler",pid=23475,fd=14))
ESTAB 0 0 10.237.5.11:45406 10.237.5.11:5672 users:(("nova-scheduler",pid=23430,fd=14))
ESTAB 0 0 10.237.5.11:59714 10.237.5.11:5672 users:(("nova-scheduler",pid=23404,fd=14))
ESTAB 0 0 10.237.5.11:44712 10.237.5.11:5672 users:(("nova-api",pid=23466,fd=15))
ESTAB 0 0 10.237.5.11:36434 10.237.5.11:5672 users:(("nova-api",pid=23419,fd=15))
Và nếu các bạn giả định rằng cấu hình message queue của Nova đã "ăn", tắt Rabbitmq ở các node cũ (10.237.5.11-13), thì có khả năng mọi người sẽ gặp phải lỗi này:
2024-03-26 14:00:42.315 26 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: [Errno 104] Connection reset by peer
2024-03-26 14:00:42.321 26 ERROR oslo.messaging._drivers.impl_rabbit [-] Connection failed: [Errno 111] ECONNREFUSED (retrying in 0 seconds): error: [Errno 111] ECONNREFUSED
Hãy cẩn thận, khi bạn dừng các nút Rabbitmq cũ, nova_api và nova_scheduler sẽ không hoạt động đúng cách mặc dù cấu hình mới đã được thay đổi
Cách fix sau cùng
Sau một hồi tìm kiếm, team Sang phát hiện rằng nova_api không chỉ sử dụng cấu hình trong file config mà cả trong Cơ sở dữ liệu.
SELECT transport_url FROM `nova_api`.`cell_mappings`
Không ngạc nhiên khi nó vẫn ghi nhận giá trị cũ. Các bạn chỉ cần đổi nó và mọi thứ sẽ bình thường.