Cách tối ưu hóa hiệu suất của ClusterControl và các thành phần của nó

Giám sát và quản lý là rất quan trọng đối với bất kỳ môi trường sản xuất nào vì hiệu suất rất quan trọng. Giao diện người dùng chậm trễ hoặc không phản hồi, cảnh báo bị trễ và hết thời gian chờ cụm công việc khi máy chủ bị thiếu tài nguyên là tất cả những thứ có thể gây ra sự cố. Có nhiều cách để cải thiện hiệu suất của ClusterControl, đặc biệt nếu bạn đang quản lý nhiều cụm và mỗi cụm chứa nhiều nút. Blog này cung cấp một số mẹo điều chỉnh. Các điểm được xây dựng ở đây được lựa chọn dựa trên kinh nghiệm của chúng tôi đối với các vấn đề về hiệu suất được người dùng và khách hàng của chúng tôi báo cáo.

Như phần giới thiệu, ClusterControl bao gồm một số thành phần chính - một ứng dụng web (giao diện người dùng) dựa trên PHP và một số quy trình daemonized (phụ trợ). Những điều này tận dụng cơ sở dữ liệu MySQL / MariaDB để lưu trữ liên tục. Bạn đang kiểm soát hiệu quả cụm của mình từ ứng dụng web, cụm này sẽ được dịch thành một loạt các lệnh gọi quy trình được thực thi bởi các quy trình phụ trợ để quản lý và giám sát các cụm cơ sở dữ liệu của bạn.

Cơ sở dữ liệu MySQL

Các thành phần ClusterControl dựa trên cơ sở dữ liệu MySQL hoặc MariaDB làm kho lưu trữ liên tục để giám sát dữ liệu được thu thập từ các nút được quản lý và tất cả siêu dữ liệu ClusterControl (ví dụ:những công việc có trong hàng đợi, lịch sao lưu, trạng thái sao lưu, vân vân.). Theo mặc định, tập lệnh trình cài đặt sẽ cài đặt bất kỳ phiên bản nào có trong kho tiêu chuẩn của hệ điều hành. Sau đây là phiên bản MySQL / MariaDB đang được cài đặt bởi trình cài đặt:

• CentOS / Redhat 6 - MySQL 5.1

• CentOS / Redhat 7 - MariaDB 5.5

• Ubuntu 18.04 (Bionic) - MySQL 5.7

• Ubuntu 16.04 (Xenial) - MySQL 5.7

• Ubuntu 14.04 (Trusty) - MySQL 5.5

• Debian 9 (Stretch) - MySQL 5.5

• Debian 8 (Jessie) - MySQL 5.5

• Debian 7 (Wheezy) - MySQL 5.5

Tập lệnh trình cài đặt sẽ thực hiện một số điều chỉnh cơ bản như định cấu hình vị trí datadir, cổng MySQL, người dùng và kích thước vùng đệm InnoDB ở đầu giai đoạn cài đặt. Tuy nhiên, việc điều chỉnh có thể không phù hợp khi bạn đã nhập hoặc tạo thêm các cụm / nút. Với số lượng nút được giám sát và quản lý ngày càng tăng, ClusterControl sẽ sử dụng nhiều tài nguyên hơn và lớp cơ sở dữ liệu thường là nút thắt cổ chai đầu tiên mà người dùng gặp phải. Có thể cần một số điều chỉnh thêm để chứa tải đến.

ClusterControl đủ thông minh để phát hiện bất kỳ sự bất thường nào về hiệu suất bằng cách viết ra các dòng sau bên trong cmon_X.log (trong đó X là ID cụm):

2018-11-28 01:30:00 : (INFO) CmonSheetManager at 0x3839af0 loaded 70 values for key 'diskstat' between 2018-11-23 01:30:00 - 2018-11-28 01:30:0
0.
2018-11-28 01:30:00 : (INFO) SQL processing: 220.0000ms
2018-11-28 01:30:00 : (INFO) Parsing       : 0.0000ms
2018-11-28 01:30:00 : (INFO) Sum           : 220.0000ms

Ở trên đơn giản có nghĩa là phải mất 220 mili giây (Giá trị tổng) để tải 70 giá trị cho thành phần "diskstat", trong đó phần lớn thời gian xử lý đang diễn ra ở giai đoạn xử lý SQL và 0 mili giây để phân tích cú pháp tập hợp các kết quả SQL . Điều này kết luận rằng lớp SQL đã chiếm hầu hết thời gian xử lý khi ClusterControl cố gắng truy vấn tập dữ liệu.

Chúng tôi tin rằng hầu hết các truy vấn SQL được thực thi bởi ClusterControl đều được tối ưu hóa đúng cách cho một phiên bản MySQL duy nhất và sử dụng lập chỉ mục thích hợp. Nói một cách đơn giản, nếu bạn thấy những thứ như trên xuất hiện thường xuyên trong tệp nhật ký, thì một số cải tiến đối với lớp cơ sở dữ liệu là theo thứ tự, như được hiển thị trong các phần sau.

Điều chỉnh Kích thước Vùng đệm InnoDB

Kích thước vùng đệm là một thành phần quan trọng và phải được định cấu hình trước để cải thiện hiệu suất MySQL. Nó cho phép xử lý MySQL diễn ra bên trong bộ nhớ thay vì chạm vào đĩa. Một nguyên tắc chung đơn giản là kiểm tra tỷ lệ truy cập InnoDB và tìm dòng sau trong phần HỒ BƠI VÀ BỘ NHỚ:

Buffer pool hit rate 986 / 1000

Tỷ lệ truy cập 986/1000 cho thấy rằng trong số 1000 lần đọc hàng, nó có thể đọc hàng trong RAM 986 lần. 14 lần còn lại, nó phải đọc hàng dữ liệu từ đĩa. Nói một cách đơn giản, 1000/1000 là giá trị tốt nhất mà chúng tôi đang cố gắng đạt được ở đây, có nghĩa là dữ liệu được truy cập thường xuyên nằm gọn trong RAM.

Việc tăng giá trị innodb_buffer_pool_size sẽ giúp rất nhiều để có thêm không gian cho MySQL hoạt động. Tuy nhiên, hãy đảm bảo bạn có đủ tài nguyên RAM trước đó. Theo mặc định, ClusterControl phân bổ 50% RAM cho vùng đệm. Nếu máy chủ dành riêng cho ClusterControl, bạn thậm chí có thể đẩy nó lên giá trị cao hơn như 70%, miễn là bạn dành ít nhất 2GB RAM cho các quy trình và bộ nhớ đệm của hệ điều hành. Nếu bạn không thể phân bổ nhiều như vậy, tăng RAM là giải pháp duy nhất.

Việc thay đổi giá trị này yêu cầu khởi động lại MySQL (cũ hơn MySQL 5.7.5), do đó thứ tự khởi động lại dịch vụ chính xác sẽ là:

1. Sửa đổi giá trị innodb_buffer_pool_size bên trong my.cnf.
2. Dừng dịch vụ CMON.
3. Khởi động lại dịch vụ MySQL / MariaDB.
4. Bắt đầu dịch vụ CMON.

Hoặc chỉ cần khởi động lại máy chủ lưu trữ nếu bạn có thể đủ thời gian ngừng hoạt động lâu hơn.

Điều chỉnh max_connections

Theo mặc định, tập lệnh trình cài đặt sẽ định cấu hình giá trị max_connections lên đến 512. Điều này khá cao, mặc dù vậy, vì ClusterControl hầu như không đạt tổng cộng 200 kết nối, trừ khi máy chủ MySQL được chia sẻ với các ứng dụng khác hoặc bạn có hàng chục nút MySQL được ClusterControl giám sát (chúng ta đang nói về 30 nút và hơn thế nữa).

Giá trị max_connections cao gây lãng phí tài nguyên và việc điều chỉnh giá trị sẽ ảnh hưởng đến bộ nhớ tối đa được định cấu hình cho MySQL. Nếu nó lớn hơn RAM Hệ thống thì có khả năng quá trình Máy chủ MySQL sẽ kết thúc với ngoại lệ OOM, nếu tất cả các kết nối đều được sử dụng.

Để kiểm tra điều này, chỉ cần tìm trạng thái MySQL max_used_connections. Sau đây là kết nối tối đa mà MySQL từng đạt được trên một nút ClusterControl giám sát 2 cụm với tổng cộng 6 nút MySQL:

mysql> SHOW STATUS like 'max_used_connections';
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 43    |
+----------------------+-------+

Giá trị tốt để bắt đầu là Max_used_connections x 2 và tăng dần nếu giá trị này liên tục tăng. Việc sửa đổi biến max_connections có thể được thực hiện động thông qua câu lệnh SET GLOBAL.

Sử dụng tệp socket MySQL

Theo mặc định, tập lệnh trình cài đặt sẽ tự động định cấu hình giá trị máy chủ sau bên trong mọi tệp cấu hình cơ sở dữ liệu ClusterControl:

Ở trên sẽ buộc máy khách MySQL kết nối qua mạng TCP, giống như kết nối với máy chủ MySQL từ xa mặc dù ClusterControl đang chạy trên cùng một máy chủ với máy chủ MySQL. Chúng tôi chủ ý định cấu hình nó theo cách này để đơn giản hóa quá trình cài đặt vì hầu hết mọi nền tảng HĐH đều định cấu hình trước tệp socket MySQL theo cách khác nhau, điều này giúp giảm đáng kể tỷ lệ cài đặt thất bại.

Thay đổi giá trị thành "localhost" sẽ buộc khách hàng sử dụng tệp ổ cắm MySQL Unix thay thế:

Trên các hệ thống dựa trên Unix, các chương trình MySQL xử lý tên máy chủ localhost một cách đặc biệt, theo cách có thể khác với những gì bạn mong đợi so với các chương trình dựa trên mạng khác. Đối với các kết nối đến máy chủ cục bộ, các chương trình MySQL cố gắng kết nối với máy chủ cục bộ bằng cách sử dụng tệp ổ cắm Unix. Điều này xảy ra ngay cả khi tùy chọn --port hoặc -P được đưa ra để chỉ định số cổng.

Sử dụng tệp ổ cắm MySQL UNIX an toàn hơn nhiều và sẽ cắt giảm chi phí mạng. Nó luôn được đề xuất qua TCP. Tuy nhiên, bạn cần đảm bảo rằng tệp socket được định cấu hình chính xác. Nó phải tồn tại trên các chỉ thị sau bên trong my.cnf và mọi tệp tùy chọn MySQL trên nút ClusterControl, ví dụ:

[mysqld]
socket=/var/lib/mysql/mysql.sock

[client]
socket=/var/lib/mysql/mysql.sock

[mysql]
socket=/var/lib/mysql/mysql.sock

[mysqldump]
socket=/var/lib/mysql/mysql.sock

Thay đổi tệp socket cũng sẽ yêu cầu khởi động lại MySQL và CMON. Nếu bạn đang sử dụng "localhost", thì bạn có thể thêm một số tùy chọn cấu hình bổ sung như bỏ qua mạng =1, để ngăn việc chấp nhận các kết nối từ xa. Hình ảnh ClusterControl Docker của chúng tôi đang sử dụng phương pháp này để khắc phục hạn chế trong docker-proxy khi liên kết trên các cổng.

OpenSSH với SSSD

ClusterControl sử dụng giao thức SSH làm kênh giao tiếp chính để quản lý và giám sát các nút từ xa. Các cấu hình OpenSSH mặc định khá ổn và sẽ hoạt động trong hầu hết các trường hợp. Tuy nhiên, trong một số môi trường mà SSH được tích hợp với các công cụ nâng cao bảo mật khác như SElinux hoặc Daemon Dịch vụ Bảo mật Hệ thống (SSSD), nó có thể mang lại tác động đáng kể đến hiệu suất SSH.

Chúng tôi đã thấy nhiều trường hợp mà số lượng kết nối SSH ngày càng tăng được thiết lập cho mỗi nút được quản lý và cuối cùng, cả máy chủ ClusterControl và tất cả các nút được quản lý đều sử dụng tối đa bộ nhớ hệ thống của chúng bằng các kết nối SSH. Trong một số trường hợp, chỉ khởi động lại toàn bộ hệ thống bình thường hàng đêm trên máy chủ ClusterControl mới có thể giải quyết được sự cố.

Nếu bạn đang chạy cơ sở hạ tầng của mình với Daemon Dịch vụ Bảo mật Hệ thống (SSSD), bạn nên nhận xét dòng sau bên trong cấu hình máy khách OpenSSH tại / etc / ssh / ssh_config trên nút ClusterControl:

#ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

Ở trên sẽ bỏ qua việc sử dụng SSSD để quản lý khóa máy chủ, khóa này sẽ do ứng dụng khách OpenSSH xử lý.

Bắt đầu từ ClusterControl 1.7.0, bạn có một tùy chọn để sử dụng công cụ giám sát dựa trên tác nhân với Prometheus. Với tính năng giám sát dựa trên tác nhân, ClusterControl không sử dụng SSH để lấy mẫu các chỉ số máy chủ, có thể quá mức trong một số môi trường.

Hệ thống tệp và phân vùng

Bộ điều khiển ClusterControl ghi mục nhập mới vào tệp nhật ký của nó gần như mỗi giây cho mọi cụm. Đối với những người muốn tận dụng khả năng ghi tuần tự trên đĩa và muốn tiết kiệm chi phí, bạn có thể sử dụng đĩa trục chính cho mục đích này. Sửa đổi dòng sau bên trong tất cả cmon_X.cnf:

logfile=/new/partition/log/cmon_X.log

Thay thế X bằng ID cụm và khởi động lại dịch vụ CMON để áp dụng các thay đổi.

Nếu bạn đang sử dụng ClusterControl làm kho lưu trữ sao lưu, bạn nên phân bổ đủ dung lượng ổ đĩa trên một phân vùng riêng biệt không phải là phân vùng gốc. Sẽ tốt hơn nếu phân vùng nằm trên hệ thống tệp được nối mạng hoặc theo nhóm để dễ dàng gắn với các nút được nhắm mục tiêu khi thực hiện thao tác khôi phục. Chúng tôi đã gặp trường hợp các bản sao lưu được tạo đã ăn hết dung lượng ổ đĩa của phân vùng chính, cuối cùng ảnh hưởng đến ClusterControl và các thành phần của nó.

Cập nhật

ClusterControl có chu kỳ phát hành ngắn - ít nhất một bản phát hành chính mới mỗi quý trong năm cộng với các bản vá bảo trì hàng tuần (chủ yếu là các bản sửa lỗi - nếu có). Lý do là ClusterControl hỗ trợ nhiều nhà cung cấp và phiên bản cơ sở dữ liệu, hệ điều hành và nền tảng phần cứng. Thường có những thứ mới được giới thiệu và những thứ cũ không còn được cung cấp từ những thứ được cung cấp. ClusterControl phải cập nhật tất cả các thay đổi do các nhà cung cấp ứng dụng đưa ra và luôn tuân theo phương pháp hay nhất.

Chúng tôi khuyến nghị người dùng luôn sử dụng phiên bản ClusterControl mới nhất (dễ dàng nâng cấp) cùng với trình duyệt web mới nhất (được xây dựng và thử nghiệm trên Google Chrome và Mozilla Firefox), vì chúng tôi rất có thể đang tận dụng các tính năng mới có sẵn trong phiên bản mới nhất.

Lời kết

Nếu bạn có bất kỳ câu hỏi nào hoặc gặp bất kỳ sự cố hoặc sự cố nào về độ chậm khi sử dụng ClusterControl, vui lòng liên hệ với chúng tôi qua kênh hỗ trợ của chúng tôi. Chúng tôi rất hoan nghênh các đề xuất và phản hồi.

Chúc bạn điều chỉnh vui vẻ!