Jak zoptymalizować wydajność ClusterControl i jego komponentów?

Monitorowanie i zarządzanie mają kluczowe znaczenie dla każdego środowiska produkcyjnego, ponieważ wydajność ma znaczenie. Powolne interfejsy użytkownika, które są opóźnione lub nie reagują, opóźnione alerty i przekroczenia limitu czasu zadań klastra, gdy serwer jest pozbawiony zasobów, to wszystko rzeczy, które mogą powodować problemy. Istnieją sposoby na poprawę wydajności ClusterControl, zwłaszcza jeśli zarządzasz wieloma klastrami, a każdy klaster zawiera wiele węzłów. Ten blog zawiera kilka wskazówek dotyczących strojenia. Omówione tutaj punkty są wybierane w oparciu o nasze doświadczenie w zakresie problemów z wydajnością zgłaszanych przez naszych użytkowników i klientów.

Na wstępie, ClusterControl składa się z kilku głównych komponentów - aplikacji webowej (frontend) opartej na PHP oraz szeregu demonizowanych procesów (backend). Wykorzystują one bazę danych MySQL/MariaDB do trwałego przechowywania. Skutecznie kontrolujesz swój klaster z aplikacji internetowej, co zostanie przełożone na serię wywołań procesów wykonywanych przez procesy zaplecza w celu zarządzania i monitorowania klastrów baz danych.

Baza danych MySQL

Komponenty ClusterControl opierają się na bazie danych MySQL lub MariaDB jako trwałym magazynie do monitorowania danych zebranych z zarządzanych węzłów i wszystkich metadanych ClusterControl (np. jakie zadania znajdują się w kolejce, harmonogramy tworzenia kopii zapasowych, statusy kopii zapasowych, itp.). Domyślnie skrypt instalacyjny zainstaluje dowolną wersję pochodzącą ze standardowego repozytorium systemu operacyjnego. Poniżej znajduje się wersja MySQL/MariaDB instalowana przez instalator:

• 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

Skrypt instalacyjny wykonałby kilka podstawowych zmian, takich jak konfiguracja lokalizacji datadir, portu MySQL, użytkownika i rozmiaru puli buforów InnoDB na początku etapu instalacji. Jednak dostrajanie może nie być odpowiednie po zaimportowaniu lub utworzeniu większej liczby klastrów/węzłów. Przy zwiększonej liczbie węzłów, które mają być monitorowane i zarządzane, ClusterControl zużywa więcej zasobów, a warstwa bazy danych jest zwykle pierwszym wąskim gardłem, na jakie napotykają użytkownicy. Może być potrzebne dalsze dostrojenie, aby ograniczyć przychodzące obciążenie.

ClusterControl jest wystarczająco inteligentny, aby wykryć wszelkie anomalie wydajności, zapisując następujące wiersze w cmon_X.log (gdzie X to identyfikator klastra):

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

Powyższe oznacza po prostu, że załadowanie 70 wartości dla komponentu „diskstat” zajęło 220 ms (wartość sumy), gdzie większość czasu przetwarzania miała miejsce na etapie przetwarzania SQL, a 0 ms do przeanalizowania zbioru wyników SQL Z tego wynika, że ​​warstwa SQL zajęła większość czasu przetwarzania, gdy ClusterControl próbował wysłać zapytanie do zestawu danych.

Uważamy, że większość zapytań SQL wykonywanych przez ClusterControl jest odpowiednio zoptymalizowana dla pojedynczej instancji MySQL i używa odpowiedniego indeksowania. Mówiąc najprościej, jeśli widzisz, że coś takiego jak powyżej pojawia się regularnie w pliku dziennika, pewne ulepszenia warstwy bazy danych są w porządku, jak pokazano w poniższych sekcjach.

Dostrajanie rozmiaru puli buforów InnoDB

Rozmiar puli buforów jest ważnym składnikiem i musi być skonfigurowany z góry, aby poprawić wydajność MySQL. Pozwala to na przetwarzanie MySQL w pamięci zamiast uderzania w dysk. Prostą praktyczną zasadą jest sprawdzenie współczynnika trafień InnoDB i wyszukanie następującej linii w sekcji pula buforów i pamięci:

Buffer pool hit rate 986 / 1000

Współczynnik trafień wynoszący 986 / 1000 wskazuje, że z 1000 odczytów wierszy był w stanie odczytać wiersz w pamięci RAM 986 razy. Pozostałe 14 razy musiał odczytać wiersz danych z dysku. Mówiąc najprościej, 1000 / 1000 to najlepsza wartość, jaką staramy się tutaj osiągnąć, co oznacza, że ​​często używane dane w pełni mieszczą się w pamięci RAM.

Zwiększenie wartości innodb_buffer_pool_size znacznie pomoże uzyskać więcej miejsca dla MySQL do pracy. Jednak wcześniej upewnij się, że masz wystarczające zasoby pamięci RAM. Domyślnie ClusterControl przydziela 50% pamięci RAM do puli buforów. Jeśli host jest dedykowany dla ClusterControl, możesz nawet zwiększyć jego wartość, np. 70%, pod warunkiem, że oszczędzisz co najmniej 2 GB pamięci RAM na procesy i pamięci podręczne systemu operacyjnego. Jeśli nie możesz przydzielić tak dużo, zwiększenie pamięci RAM jest jedynym rozwiązaniem.

Zmiana tej wartości wymaga ponownego uruchomienia MySQL (starszego niż MySQL 5.7.5), dlatego poprawna kolejność ponownego uruchomienia usługi będzie następująca:

1. Zmodyfikuj wartość innodb_buffer_pool_size wewnątrz my.cnf.
2. Zatrzymaj usługę CMON.
3. Zrestartuj usługę MySQL/MariaDB.
4. Uruchom usługę CMON.

Lub po prostu zrestartuj hosta, jeśli możesz sobie pozwolić na dłuższy przestój.

Dostrajanie max_connections

Domyślnie skrypt instalacyjny skonfiguruje wartość max_connections do 512. Jest to dość wysoka wartość, choć rozsądna, ponieważ ClusterControl ledwo osiąga łącznie 200 połączeń, chyba że serwer MySQL jest współdzielony z innymi aplikacjami lub masz dziesiątki węzłów MySQL monitorowanych przez ClusterControl (mówimy o 30 węzłach i więcej).

Wysoka wartość max_connections marnuje zasoby, a dostosowanie wartości wpłynie na maksymalną pamięć skonfigurowaną dla MySQL. Jeśli jest większa niż systemowa pamięć RAM, istnieje szansa, że ​​proces MySQL Server zakończy się z wyjątkiem OOM, jeśli wszystkie połączenia są używane.

Aby to sprawdzić, po prostu spójrz na stan max_used_connections MySQL. Poniżej przedstawiono maksymalne połączenia, jakie kiedykolwiek osiągnął MySQL w węźle ClusterControl, który monitoruje 2 klastry z łącznie 6 węzłami MySQL:

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

Dobrą wartością na początek jest Max_used_connections x 2 i stopniowo ją zwiększaj, jeśli wartość stale rośnie. Modyfikację zmiennej max_connections można przeprowadzić dynamicznie za pomocą instrukcji SET GLOBAL.

Korzystanie z pliku gniazda MySQL

Domyślnie skrypt instalacyjny automatycznie skonfiguruje następującą wartość hosta w każdym pliku konfiguracyjnym bazy danych ClusterControl:

Powyższe zmusi klienta MySQL do łączenia się przez sieć TCP, podobnie jak połączenie ze zdalnym hostem MySQL, chociaż ClusterControl działa na tym samym serwerze, co serwer MySQL. Celowo skonfigurowaliśmy go w ten sposób, aby uprościć proces instalacji, ponieważ prawie każda platforma systemu operacyjnego wstępnie konfiguruje plik gniazda MySQL w inny sposób, co znacznie zmniejsza wskaźnik niepowodzeń instalacji.

Zmiana wartości na „localhost” wymusi na kliencie użycie pliku gniazda MySQL Unix:

W systemach opartych na systemie Unix programy MySQL traktują nazwę hosta localhost w specjalny sposób, w sposób, który prawdopodobnie różni się od oczekiwanego w porównaniu z innymi programami opartymi na sieci. W przypadku połączeń z hostem lokalnym programy MySQL próbują połączyć się z serwerem lokalnym przy użyciu pliku gniazda uniksowego. Dzieje się tak, nawet jeśli podano opcję --port lub -P w celu określenia numeru portu.

Korzystanie z pliku gniazda MySQL UNIX jest znacznie bezpieczniejsze i odetnie obciążenie sieci. Jest to zawsze zalecane przez TCP. Musisz jednak upewnić się, że plik gniazda jest poprawnie skonfigurowany. Musi istnieć w następujących dyrektywach wewnątrz my.cnf i wszystkich plikach opcji MySQL w węźle ClusterControl, na przykład:

[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

Zmiana pliku gniazda będzie również wymagać ponownego uruchomienia MySQL i CMON. Jeśli używasz "localhost", możesz dodać kilka dodatkowych opcji konfiguracyjnych, takich jak skip-networking=1, aby zapobiec akceptowaniu połączeń zdalnych. Nasz obraz Docker ClusterControl wykorzystuje to podejście, aby przezwyciężyć ograniczenia w docker-proxy podczas wiązania portów.

OpenSSH z SSSD

ClusterControl wykorzystuje protokół SSH jako główny kanał komunikacji do zarządzania i monitorowania zdalnych węzłów. Domyślne konfiguracje OpenSSH są całkiem przyzwoite i powinny działać w większości przypadków. Jednak w niektórych środowiskach, w których SSH jest zintegrowany z innymi narzędziami zwiększającymi bezpieczeństwo, takimi jak SElinux lub System Security Services Daemon (SSSD), może to mieć znaczący wpływ na wydajność SSH.

Widzieliśmy wiele przypadków, w których stale rosnąca liczba połączeń SSH nawiązywanych z każdym z zarządzanych węzłów i ostatecznie zarówno serwer ClusterControl, jak i wszystkie węzły zarządzane maksymalizują pamięć systemową za pomocą połączeń SSH. W niektórych przypadkach, tylko normalne, pełne ponowne uruchomienie systemu co noc na serwerze ClusterControl może rozwiązać problem.

Jeśli używasz swojej infrastruktury z demonem System Security Services Daemon (SSSD), zaleca się skomentowanie następującego wiersza w konfiguracji klienta OpenSSH w /etc/ssh/ssh_config w węźle ClusterControl:

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

Powyższe spowoduje pominięcie używania SSSD do zarządzania kluczem hosta, który będzie obsługiwany przez klienta OpenSSH.

Począwszy od ClusterControl 1.7.0, masz możliwość korzystania z narzędzia monitorowania opartego na agentach z Prometheusem. W przypadku monitorowania opartego na agencie ClusterControl nie używa protokołu SSH do próbkowania metryk hosta, które w niektórych środowiskach mogą być nadmierne.

System plików i partycjonowanie

Kontroler ClusterControl zapisuje nowy wpis w swoim pliku dziennika prawie co sekundę dla każdego klastra. Dla tych, którzy chcą skorzystać z tego sekwencyjnego zapisu na dysku i chcą zaoszczędzić na kosztach, można użyć do tego celu dysku z wrzecionem. Zmodyfikuj następujący wiersz wewnątrz wszystkich cmon_X.cnf:

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

Zastąp X identyfikatorem klastra i uruchom ponownie usługę CMON, aby zastosować zmiany.

Jeśli używasz ClusterControl jako repozytorium kopii zapasowych, zaleca się przydzielenie wystarczającej ilości miejsca na dysku na osobnej partycji innej niż partycja główna. Lepiej jest, jeśli partycja znajduje się w sieciowym lub klastrowym systemie plików, co ułatwia montowanie z docelowymi węzłami podczas wykonywania operacji przywracania. Widzieliśmy przypadki, w których utworzone kopie zapasowe pochłaniały całe miejsce na dysku głównej partycji, ostatecznie wpływając na ClusterControl i jego komponenty.

Bądź na bieżąco

ClusterControl ma krótki cykl wydawniczy — co najmniej jedno nowe główne wydanie co kwartał oraz cotygodniowe łatki konserwacyjne (głównie poprawki błędów - jeśli są). Powodem jest to, że ClusterControl obsługuje wielu dostawców i wersje baz danych, systemy operacyjne i platformy sprzętowe. Często wprowadzane są nowe rzeczy, a stare są odrzucane w stosunku do tego, co jest zapewnione. ClusterControl musi nadążyć za wszystkimi zmianami wprowadzanymi przez dostawców aplikacji i za każdym razem postępować zgodnie z najlepszymi praktykami.

Zalecamy użytkownikom, aby zawsze używali najnowszej wersji ClusterControl (uaktualnienie jest łatwe) wraz z najnowszą przeglądarką internetową (zbudowaną i przetestowaną w Google Chrome i Mozilla Firefox), ponieważ najprawdopodobniej korzystamy z nowe funkcje dostępne w najnowszej wersji.

Ostateczne myśli

Jeśli masz jakiekolwiek pytania lub napotkasz jakiekolwiek problemy lub problemy z powolnym działaniem podczas korzystania z ClusterControl, skontaktuj się z nami za pośrednictwem naszego kanału wsparcia. Sugestie i opinie są bardzo mile widziane.

Miłego strojenia!