- 1. Giới thiệu
- 2. Thách thức thứ nhất: Hệ thống không nguyên khối
- 3. Thách thức thứ hai: Openstack không đơn giản là Openstack
- 4. Thách thức thứ ba: Suy nghĩ ngoài khuôn khổ
- 5. Thách thức thứ tư: Yếu tố con người
- 6. Tài liệu tham khảo
Nếu trước đây bạn đã từng làm việc với nền tảng Cloud, thì bạn sẽ quen với bản chất phân tán và tách rời của hệ thống này. Một hệ thống phân tán dựa vào các microservices để thực hiện từng nhiệm vụ cụ thể, mỗi dịch vụ sẽ phơi bày ra REST API. Các microservices này nói chuyện với nhau thông qua một lớp tin nhắn thường là theo form như RabbitMQ hoặc QPID
Đây chính xác là cách mà Openstack hoạt động. Mỗi thành phần chính của Openstack (Keystone, Glance, Cinder, Neutron, Nova,vv) đều bày ra một REST endpoint, các thành phần và các thành phần con giao tiếp thông qua một tầng tin nhắn như là RabbitMQ. Lợi ích của các tiếp cận này đầu tiên là cho phép các lỗi được phân bổ đến các thành phần cụ thể, thứ hai là các nhà khai thác cơ sở hạ tầng Cloud có thể mở rộng quy mô dịch vụ theo chiều ngang và phân phối tải trọng một cách thông minh.
Hệ thống này có nhiều lợi ích to lớn, tuy nhiên cũng có nhiều thách thức: làm cách nào để giám sát các dịch vụ và quan trọng hơn: làm sao để xác định chính xác điểm gặp lỗi.
Sau đây, tôi sẽ xác định những thách thức với các trường hợp cụ thể của việc theo dõi dịch vụ Openstack và các giải pháp khả thi cho từng trường hợp cụ thể.
Tính chất không nguyên khối và tách biệt của Openstack thường được nhấn mạnh là một trong những ưu điểm chính của Openstack. Tuy nhiên, nó gây nên đáng kể khó khăn cho việc cố gắng giám sát trạng thái của dịch vụ như một khối. Trong một hệ thống phân tán, nơi mà mỗi thành phần đảm nhiệm một công việc cụ thể và mỗi thành phần được phân tán thêm thành các thành phần con. Do vậy có thể hiểu được khó khăn như thế nào khi xác định cụ thể được các phần mềm gặp lỗi.
Bước đầu tiên để vượt qua việc này là tìm hiểu về Cloud. Bạn cần xác định mối liên quan giữa các thành phần chính và sau đó, với mỗi một thành phần, cần cô lập các dịch vụ có thể gặp lỗi có thể ảnh hưởng đến dịch vụ tổng thể. Nói một cách đơn giản, bạn cần phải biết tất cả mọi thứ có biết về mối quan hệ giữa tất cả các thành phần trong Cloud
Với tư duy đó, bạn không chỉ giám sát trạng thái (Up hay Down) của mỗi thành phần, cần phải xác định các dịch vụ khác có thể bị ảnh hưởng như nào. Ví dụ: nếu Keystone chết, không ai có thể có được danh mục dịch vụ hoặc đăng nhập vào bất kỳ dịch vụ nào. Nhưng thường thì nó sẽ không ảnh hưởng đến máy ảo hoặc các dịch vụ Cloud được thiết lập khác (object storage, block storage, load balancers, vv) trừ khi các dịch vụ bị khởi động lại và Keystone vẫn chết. Tuy nhiên, nếu Apache chết thì Keystone hoặc các dịch vụ API tương tự khác cũng có thể bị ảnh hưởng nếu nó hoạt động qua Apache
Vì vậy, nền tảng giám sát hoặc giải pháp phải không chỉ có khả năng đánh giá tình trạng của từng dịch vụ, mà phải biết tương quan các dịch vụ khác để kiểm tra tác động trên toàn bộ hệ thống và gửi cảnh báo cho phù hợp.
Không chỉ là Openstack dựa trên Cloud, một hệ thống phân tán và tách rời. Nó cũng là một dàn giải pháp tạo ra tài nguyên trong hệ điều hành và các thiết bị khác bên trong hoặc liên quan đến hạ tầng cloud. Các tài nguyên này bao gồm máy ảo (Xen, KVM hoặc các phần mềm hypervisor khác), các volumes (Các máy chủ lưu trữ NFS, các nhóm Ceph, LVM SAN dựa trên LVM hoặc các backend lưu trữ khác), network (ports, bridges, networks, routers, load balancers, firewalls, VPNs, vv chạy với các thành phần cụ thể như iptables, kernel namespaces, HAProxy, Open vSwitch và nhiều thành phần con khác), các đĩa không bền vững (file Qcow2 nằm trong thư mục hệ điều hành) và nhiều hệ thống nhỏ khác.
Do đó, giải pháp theo dõi nên tính đến những thành phần cơ bản này. Mặc dù là các tài nguyên này có thể ít phức tạp hơn và ít bị hỏng hóc hơn. Khi các dịch vụ này down, các bản ghi logs bên trong các dịch vụ chính của Openstack có thể che giấu đi lí do chính. Chúng chỉ hiển thị kết quả của dịch vụ OpenStack bị ảnh hưởng. Không phải là nguyên nhân thực sự trên thiết bị hoặc phần mềm hệ điều hành thực sự gặp lỗi. Ví dụ, nếu libvirt gặp lỗi, Nova sẽ không thể triển khai một instance ảo. Nova-compute vẫn sẽ chạy nhưng instance sẽ lỗi (instance state: error) trong khi triển khai. Để phát hiện được việc này, cần giám sát libvirt cùng với nova-compute logs.
Do đó cần phải kiểm tra các mối quan hệ giữa các phần mềm cơ bản và các thành phần chính cũng như giám sát chuỗi kết thúc và xem xét các bài kiểm tra thống nhất cùng tất cả các dịch vụ. Bạn cần giám sát mọi thứ: storage, networking, hypervision layer, mỗi thành phần riêng biệt, và mối liên quan giữa chúng.
Cacti, Nagios, và Zabbix là những ví dụ điển hình của các giải pháp giám sát OpenSource. Các giải pháp này xác định một bộ các thông số cụ thể để xác định các vấn đề có thể xảy ra trên hệ điều hành. Tuy nhiên những gì họ không cung cấp là các thông số chuyên ngành cần thiết để xác định tình huống lỗi phức tạp hơn hoặc thậm chí là trạng thái của một dịch vụ.
Đây là nơi cần suy nghĩ vượt ra ngoài khuôn khổ. Bạn có thể thực hiện các số liệu kiểm tra chuyên biệt để xác định xem dịch vụ của bạn có ổn định, xuống cấp hay hoàn toàn hỏng
Một hệ thống phân tán như OpenStack, nơi mà mỗi dịch vụ chính phơi bày một REST API và cũng kết nối với một dịch vụ tin nhắn dựa trên TCP và dễ bị tắc nghẽn mạng, cạn kiệt connection-pool và các vấn đề liên quan khác. Nhiều dịch vụ liên quan kết nối với SQL dựa trên các cơ sở dữ liệu, có thể làm cạn kiệt max-connection-pool, nghĩa là các thông số giám sát của trạng thái kết nối phù hợp cần được thực hiện trong giải pháp giám sát để phát hiện các vấn đề liên quan đến kết nối có thể ảnh hưởng đến API. Hơn nữa, cli-tests có thể được xây dựng để kiểm tra trạng thái đầu cuối và đo thời gian phản hồi của nó, có thể chuyển đổi thành thông số có để biểu thị tình trạng thực sự của dịch vụ.
Mỗi giải pháp giám sát nói trên và hầu hết các bản thương mại hay giải pháp OpenSource có thể mở rộng với thông số chuyên dụng mà bạn có thể tự thiết kế.
Câu lệnh time OpenStack catalogue list có thể đo được thời gian phản hồi của Keystone API. Đánh giá phản hồi và tạo ra một trạng thái thất bại nhân tạo nếu câu trả lời không phải là điều mong đợi. Thêm vào đó, bạn có thể sử dụng các công cụ đơn giản như netstat hoặc ss để giám sát các trạng thái kết nối khác trong API endpoint của bạn và tăng khả năng hiển thị các vấn đề có thể xảy ra trong dịch vụ. Điều tương tự cũng có thể được thực hiện đối với các thành phần quan trọng của OpenStack Cloud phụ thuộc vào tin nhắn trung gian và các dịch vụ cơ sở dữ liệu. Lưu ý rằng các lỗi của tin nhắn trung gian có thể giết chết các dịch vụ trong OpenStack của bạn.
Quan trọng ở đây là đừng lười biếng, đừng phụ thuộc vào các thông số mặc định. Hãy làm với các số liệu liên quan đến dịch vụ của bạn.
Nhân tố con người xuất hiện trong mọi lĩnh vực. Tục ngữ có câu "Vụng múa chê đất lệch", thợ vụng thường đổ lỗi cho đồ nghề khi anh ta làm việc gì dở, nhưng nếu anh ta làm được việc gì thật là tốt thì đó lại là khả năng của anh ta, sự cố gắng của anh ta chứ không phải là do đồ nghề tốt. Nếu không có sự kiểm tra tỉ mỉ, một lỗi nhỏ sẽ không chỉ không được giải quyết mà nó còn có thể kéo theo nhiều lỗi khác. Bất cứ một sự cố nào diễn ra trong hệ thống cloud của bạn và cả những cảnh báo liên quan đều nên được lưu lại theo từng bước rõ ràng. Tất nhiên nó sẽ phải bao gồm cả những bước làm sao để phát hiện và sửa lỗi nữa.
Yếu tố con người vẫn rất đáng quan tâm ngay cả khi bạn có một hệ thống thông minh với những cỗ máy có trí tuệ nhân tạo có thể tự phát hiện và sửa lỗi phát sinh. Điều quan trọng cần nhớ là nếu bạn cung cấp cho hệ thống của bạn thông tin không chính xác hoặc không đầy đủ thì đầu ra cũng sẽ không chính xác hoặc không đầy đủ. Tóm lại, việc giám sát OpenStack không phải là khó khăn, điều quan trọng nhất là phải làm triệt để. Mỗi một dịch vụ và những tương tác mà nó thực hiện với mọi dịch vụ khác đều cần nhưng sự giám sát cẩn thận. Với một số TLC, bạn có thể dễ dàng giám sát hệ thống OpenStack.