Как да оптимизирате производителността на ClusterControl и неговите компоненти

Наблюдението и управлението са от решаващо значение за всяка производствена среда, тъй като производителността има значение. Бавните потребителски интерфейси, които изостават или не реагират, забавените сигнали и изчакването на клъстерни задания, когато сървърът е лишен от ресурси, са всичко, което може да създаде проблеми. Има начини за подобряване на производителността на ClusterControl, особено ако управлявате множество клъстери и всеки клъстер съдържа множество възли. Този блог предоставя някои съвети за настройка. Разработените тук точки са подбрани въз основа на нашия опит в справянето с проблеми с производителността, докладвани от нашите потребители и клиенти.

Като въведение ClusterControl се състои от няколко основни компонента – уеб приложение (frontend) базирано на PHP и редица демонизирани процеси (backend). Те използват база данни MySQL/MariaDB за постоянно съхранение. Вие ефективно контролирате своя клъстер от уеб приложението, което ще бъде преведено в серия от извиквания на процеси, изпълнявани от бекенд процесите за управление и наблюдение на клъстерите на вашите бази данни.

База данни MySQL

Компонентите на ClusterControl разчитат на база данни MySQL или MariaDB като постоянно хранилище за наблюдение на данни, събрани от управляваните възли и всички метаданни на ClusterControl (напр. какви работни места има в опашката, графици за архивиране, статуси на архивиране, и др.). По подразбиране скриптът за инсталиране ще инсталира всяка версия, която идва от стандартното хранилище на операционната система. Следва версията на MySQL/MariaDB, която се инсталира от инсталатора:

• 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 (Надежден) - MySQL 5.5

• Debian 9 (Stretch) - MySQL 5.5

• Debian 8 (Jessie) - MySQL 5.5

• Debian 7 (Wheezy) - MySQL 5.5

Скриптът на инсталатора ще направи някои основни настройки като конфигуриране на местоположението на datadir, MySQL порта, потребителя и размера на буферния пул на InnoDB в началото на инсталационния етап. Въпреки това, настройката може да не е подходяща, след като сте импортирали или създали повече клъстери/възли. С увеличен брой възли, които трябва да се наблюдават и управляват, ClusterControl ще използва повече ресурси, а слоят на базата данни обикновено е първото тесно място, с което се сблъскват потребителите. Може да е необходима допълнителна настройка, за да се задържи входящият товар.

ClusterControl е достатъчно интелигентен, за да открие всяка аномалия в производителността, като запише следните редове в cmon_X.log (където X е идентификаторът на клъстера):

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

Гореното просто означава, че са били необходими 220 мс (сумна стойност) за зареждане на 70 стойности за компонент "diskstat", където по-голямата част от времето за обработка се е случвало на етапа на обработка на SQL и 0 ms за анализиране на SQL резултатния набор Това заключава, че SQL слоят е отнел по-голямата част от времето за обработка, когато ClusterControl се опита да отправи заявка към набора от данни.

Смятаме, че повечето от SQL заявките, изпълнявани от ClusterControl, са правилно оптимизирани за един екземпляр на MySQL и използват правилно индексиране. Казано по-просто, ако видите нещо като горното да се появява редовно в регистрационния файл, някои подобрения на слоя на базата данни са необходими, както е показано в следващите раздели.

Настройка на размера на буферния пул на InnoDB

Размерът на буферния пул е важен компонент и трябва да бъде конфигуриран предварително, за да се подобри производителността на MySQL. Той позволява обработката на MySQL да се извършва в паметта, вместо да се удря по диска. Едно просто правило е да проверите съотношението на попадения в InnoDB и да потърсите следния ред в секцията БУФЕРЕН ПУЛ И ПАМЕТ:

Buffer pool hit rate 986 / 1000

Скоростта на попадане от 986 / 1000 показва, че от 1000 четения на реда е успял да прочете реда в RAM 986 пъти. Останалите 14 пъти трябваше да прочете реда данни от диска. Просто казано, 1000 / 1000 е най-добрата стойност, която се опитваме да постигнем тук, което означава, че често достъпните данни се вписват напълно в RAM.

Увеличаването на стойността innodb_buffer_pool_size ще помогне много за разполагане на повече място за работа на MySQL. Уверете се обаче, че имате достатъчно RAM ресурси предварително. По подразбиране ClusterControl разпределя 50% от RAM паметта към буферния пул. Ако хостът е посветен на ClusterControl, можете дори да го натиснете до по-висока стойност като 70%, при условие че отделите поне 2 GB RAM за процесите и кеша на ОС. Ако не можете да разпределите толкова много, увеличаването на RAM е единственото решение.

Промяната на тази стойност изисква рестартиране на MySQL (по-стар от MySQL 5.7.5), така че правилната подредба на рестартирането на услугата ще бъде:

1. Променете стойността на innodb_buffer_pool_size в my.cnf.
2. Спрете услугата CMON.
3. Рестартирайте услугата MySQL/MariaDB.
4. Стартирайте услугата CMON.

Или просто рестартирайте хоста, ако можете да си позволите по-дълъг престой.

Настройване на max_connections

По подразбиране скриптът на инсталатора ще конфигурира max_connections стойност до 512. Това е доста висока, макар и разумна, тъй като ClusterControl едва достига общо 200 връзки, освен ако MySQL сървърът не е споделен с други приложения или имате десетки MySQL възли, наблюдавани от ClusterControl (говорим за 30 възела и повече).

Висока стойност на max_connections губи ресурси и коригирането на стойността ще повлияе на максималната памет, конфигурирана за MySQL. Ако е по-голям от системната RAM, тогава има вероятност процесът на MySQL Server да приключи с изключение OOM, ако се използват всички връзки.

За да проверите това, просто потърсете max_used_connections MySQL състояние. Следва максималните връзки, достигани някога от MySQL на възел ClusterControl, който наблюдава 2 клъстера с общо 6 MySQL възела:

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

Добра стойност за начало е Max_used_connections x 2 и постепенно я увеличавайте, ако стойността постоянно расте. Промяната на променливата max_connections може да се извърши динамично чрез оператор SET GLOBAL.

Използване на MySQL сокет файл

По подразбиране скриптът на инсталатора автоматично ще конфигурира следната стойност на хост във всеки конфигурационен файл на база данни ClusterControl:

Горното ще принуди MySQL клиента да се свърже чрез TCP мрежа, точно като свързване с отдалечен MySQL хост, въпреки че ClusterControl работи на същия сървър като MySQL сървъра. Нарочно го конфигурирахме по този начин, за да опростим инсталационния процес, тъй като почти всяка платформа на ОС предварително конфигурира MySQL сокетния файл по различен начин, което значително намалява процента на неуспех на инсталацията.

Промяната на стойността на "localhost" ще принуди клиента да използва вместо това файла на MySQL Unix сокет:

В системите, базирани на Unix, MySQL програмите третират името на хоста localhost специално, по начин, който вероятно е различен от това, което очаквате в сравнение с други мрежови програми. За връзки към localhost, MySQL програмите се опитват да се свържат с локалния сървър, като използват Unix файл на сокет. Това се случва дори ако е дадена опция --port или -P за указване на номер на порт.

Използването на MySQL UNIX сокет файл е много по-сигурно и ще прекъсне мрежовите разходи. Винаги се препоръчва през TCP. Трябва обаче да се уверите, че файлът на сокета е конфигуриран правилно. Той трябва да съществува в следните директиви в my.cnf и във всеки файл с опции на MySQL на възел ClusterControl, например:

[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

Промяната на сокет файла също ще изисква рестартиране на MySQL и CMON. Ако използвате "localhost", тогава можете да добавите някои допълнителни опции за конфигурация като skip-networking=1, за да предотвратите приемането на отдалечени връзки. Нашето изображение на ClusterControl Docker използва този подход за преодоляване на ограничение в docker-proxy при обвързване към портове.

OpenSSH с SSSD

ClusterControl използва SSH протокол като основен комуникационен канал за управление и наблюдение на отдалечени възли. Конфигурациите на OpenSSH по подразбиране са доста прилични и трябва да работят в повечето случаи. Въпреки това, в някои среди, където SSH е интегриран с други инструменти за подобряване на сигурността, като SElinux или System Security Services Daemon (SSSD), това може да окаже значително влияние върху производителността на SSH.

Виждали сме много случаи, при които все по-голямо количество SSH връзки се установяват към всеки от управляваните възли и в крайна сметка както сървърът ClusterControl, така и всички управлявани възли максимират системната си памет със SSH връзки. В някои случаи само нормално пълно рестартиране на системата всяка вечер на сървъра на ClusterControl може да реши проблема.

Ако използвате вашата инфраструктура с демон на услугите за сигурност на системата (SSSD), препоръчваме ви да коментирате следния ред в конфигурацията на OpenSSH на клиента в /etc/ssh/ssh_config на възел ClusterControl:

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

Горното ще пропусне използването на SSSD за управление на хост ключа, който вместо това ще се обработва от OpenSSH клиент.

Започвайки от ClusterControl 1.7.0, имате възможност да използвате инструмент за наблюдение, базиран на агенти с Prometheus. С мониторинг, базиран на агенти, ClusterControl не използва SSH за вземане на проби от показатели за хост, които могат да бъдат прекомерни в някои среди.

Файлова система и разделяне на дялове

Контролерът ClusterControl записва нов запис в своя лог файл почти всяка секунда за всеки клъстер. За тези, които искат да се възползват от това последователно записване на диск и биха искали да спестят разходи, можете да използвате шпиндел диск за тази цел. Променете следния ред във всички cmon_X.cnf:

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

Заменете X с идентификатора на клъстера и рестартирайте услугата CMON, за да приложите промените.

Ако използвате ClusterControl като архивно хранилище, препоръчително е да разпределите достатъчно дисково пространство на отделен дял, различен от основния дял. Става по-добре, ако дялът се намира в мрежова или клъстерирана файлова система за лесно монтиране с целевите възли при извършване на операция по възстановяване. Виждали сме случаи, при които създадените резервни копия изяждат цялото дисково пространство на главния дял, което в крайна сметка засяга ClusterControl и неговите компоненти.

Бъдете актуални

ClusterControl има кратък цикъл на издаване - поне една нова основна версия на всяко тримесечие на годината плюс седмични корекции за поддръжка (предимно корекции на грешки - ако има такива). Причината е, че ClusterControl поддържа множество доставчици и версии на бази данни, операционни системи и хардуерни платформи. Често се въвеждат нови неща и се отхвърлят стари неща от предоставеното. ClusterControl трябва да бъде в крак с всички промени, въведени от доставчиците на приложения, и всеки път да следва най-добрите практики.

Препоръчваме на потребителите винаги да използват най-новата версия на ClusterControl (надграждането е лесно) заедно с най-новия уеб браузър (изграден и тестван в Google Chrome и Mozilla Firefox), тъй като много вероятно ще се възползваме от новите функции, налични в най-новата версия.

Последни мисли

Ако имате някакви въпроси или срещнете проблеми или проблеми със забавянето, когато използвате ClusterControl, моля, свържете се с нас чрез нашия канал за поддръжка. Предложенията и обратната връзка са много добре дошли.

Приятна настройка!