Tìm hiểu kiến trúc và cách các thành phần của nova làm việc với nhau

Luồng hoạt động khi tạo một instance

  1. Người dùng cuối(có thể là Dashboard, CLI hay qua API) gửi thông tin đăng nhập tới Keystone để xác thực. Sau khi Keystone xác thực được thông tin đăng nhập của người dùng, trả về cho người dùng hay trình duyệt một auth-token. Người dùng sau đó sẽ sử dụng token này cho những lần request tiếp theo đến các dịch vụ trong Openstack.
  2. User sử dụng auth-token để gửi yêu cầu tạo máy ảo đến Nova-API.
  3. Nova-API lấy auth-token từ yêu cầu của người dùng, gửi đến Keystone để xác thực xem auth-token đã hết hạn chưa và user có quyền là gì.
  4. Keystone trả về kết quả xác thực và ủy quyền của auth-token về cho Nova-API.
  5. Nếu Token được xác thực và có quyền tạo máy ảo, Nova sẽ bắt đầu tạo máy ảo(tương đương câu lệnh nova boot). Nova API sẽ gửi yêu cầu ghi thông tin của máy ảo đến nova-conductor.
  6. Nova conductor gọi đến db để ghi thông tin máy ảo đang tạo.
  7. Sau đó Nova-API sẽ gửi yêu cầu đến Nova-scheduler để lên lịch tạo máy ảo.

  8. Nova-Scheduler sẽ tìm compute host trong DB và chọn compute host theo filter và weight. Sau khi chọn được compute host, scheduler gửi yêu cầu theo RPC message đến compute host được chọn.

  9. Nova lấy thông tin máy ảo cần tạo từ DB bằng cách gửi yêu cầu đến nova-conductor.
  10. Sau khi lấy được thông tin máy ảo, Nova biết máy ảo sử dụng image nào, từ đó thực hiện yêu cầu đến glane, glance xác thực token, trả về nova-compute url của image muốn sử dụng
  11. Nova compute tải image từ Glance về compute host.
  12. Nova compute gửi yêu cầu tạo các thông tin cơ bản về network cho máy ảo đến Neutron. Neutron xác thực token, và gửi lại các thông tin vể network cho máy ảo về Nova compute.
  13. Nova compute gửi yêu cầu tới Cinder để tạo và thiết lập thông tin để gán volume vào máy ảo. Sau đó nó gửi thông tin về cho Nova compute về volume.
  14. Với các thông tin từ các dịch vụ khác nhau, Nova compute thực hiện yêu cầu đến Hypervisor để tạo máy ảo.

Hoạt động giữa các thành phần trong Nova sử dụng tin nhắn AMQP

Muốn quản trị được Openstack, nên tìm hiểu các công nghệ mà nó sử dụng thay vì chỉ tìm hiểu làm sao sử dụng được Openstack. Một trong những công nghệ quan trọng trong Openstack cloud là AMQP.

AMQP - Advanced Message Queuing Protocol là công nghệ nhắn tin được Openstack cloud lựa chọn. AMQP broker, mặc định là RabbitMQ, đứng giữa bất kì hai thành phần nào trong của Nova và cho phép chúng có thể giao tiếp với nhau thông qua một giao tiếp lỏng lẻo(loosely coupled communication). Cụ thể, các thành phần của Nova sử dụng RPC(Remote Procedure Calls) để giao tiếp với nhau. Vì được xây dựng trên mô hình public/subscribe nên nó có thể đạt được một số lợi ích sau:

Nova thực thiện RPC ( Cả kiểu hai chiều(gửi và nhận cuộc gọi) và một chiều với tên gọi lần lượt là rpc.call và rpc.cast) thông qua AMQP. Mỗi thành phần của Nova(như Scheduler, Compute,…) tạo hai queues(hàng đợi) mỗi khi khởi tạo, một hàng đợi sẽ cho phép tin nhắn với lables(routing key- được dùng để xác định host nào sẽ nhận được một bản copy của image) NODE-TYPE.NODE-ID(ví dụ compute.hostname) và cái còn lại sẽ chấp nhận tin nhắn với lable là NODE-TYPE.

Nova RPC Mapping

Mô hình dưới đây mô tả các phần nội bộ của một broker(RabbitMQ) khi mà một máy ảo được tạo và chia sẻ trên Openstack cloud. Mọi thành phần của Nova đều kết nối với message broker và phụ thuộc vào tính chất của thành phần này, nó có thể sẽ là Invoker(người tạo và gửi cuộc gọi) hoặc là Worker(người nhận). Hai khái niệm Invoker và Worker không thực sự tồn tại trong mô hình của Nova, ở đây ta sử dụng nó để mô tả trừu tượng các thành phần. Invoker là thành phần gửi tin nhắn trong hệ thống xếp hàng thông qua hai thao tác: 1) rpc.callvà ii) rpc.cast; Công nhân là một thành phần nhận tin nhắn từ hệ thống xếp hàng và trả lời tương ứng với các rpc.callhoạt động.

Các thành phần trong hình trên:

RPC calls

Sơ đồ dưới đây mô tả luồng tin nhắn trong hoạt động của rpc.call:

  1. Một Topic Publisher sẽ được khởi tạo và gửi tin nhắn đế hệ thống hàng đợi: ngay lập tức sau hoạt động publishing, một Direct consumer được khởi tạo để đợi tin nhắn phản hồi.
  2. Khi mà tin nhắn được gửi đi bởi exchange, nó được lấy bởi Topic Consumer mà được quyết định bởi routing key và truyền cho worker phụ trách công việc.
  3. Khi sử lý công việc xong, một Direct Publisher được phân bổ để gửi tin nhắn phản hồi đến hệ thống hàng chờ.
  4. Khi tin nhắn phản hồi được gửi đi bởi exchange, nó được lấy về bởi Direct Consumer được quyết định bởi routing key sau đó gửi cho Invoker.

RPC Cast

Sơ đồ dưới đây mô tả luồn tin nhắn trong hoạt động một rpc.cast:

  1. Một Topic Publisher sẽ được khởi tạo và gửi tin nhắn đế hệ thống hàng đợi
  2. Khi mà tin nhắn được gửi đi bởi exchange, nó được lấy bởi Topic Consumer mà được quyết định bởi routing key và truyền cho worker phụ trách công việc.

Luồng trạng thái của một máy ảo trên Openstack.

Sơ đồ dưới đây môt tả luồng các trạng thái mà máy ảo có thể có.

Mọi trong sơ đồ trên, mọi trạng thái đều có thể chuyển thành DELETED và ERROR.

Các câu lệnh khả dụng với các trạng thái của máy ảo.

|Trạng thái máy ảo | Câu lệnh có thể thực hiện | |——————|—————————| | Paused | unpause| | Suspended | remuse | | Active | set admin password, suspend, pause, rescue, rebuild, soft delete, delete, backup, snapshot, stop, reboot, resize, revert resize, confirm resize | | Shutoff | suspend, pause, rescue, rebuild, soft delete, delete, backup, start, snapshot, stop, reboot, resize, revert resize, confirm resize | | Rescued | unrescue, pause | | Stopped | rescue, delete, start | | Soft Deleted | force delete, restore | | Error | soft delete, delete | | Building | delete | | Rescued | delete, stop, reboot |

Tài liệu tham khảo