Jak optimalizovat výkon ClusterControl a jeho komponent

Monitorování a správa jsou zásadní pro jakékoli produkční prostředí, protože na výkonu záleží. Problémy mohou způsobit pomalá uživatelská rozhraní, která se zpožďují nebo nereagují, zpožděné výstrahy a časové limity klastrových úloh, když server nemá dostatek prostředků. Existují způsoby, jak zlepšit výkon ClusterControl, zejména pokud spravujete více clusterů a každý cluster obsahuje více uzlů. Tento blog nabízí několik tipů na ladění. Body zde vypracované vycházejí z našich zkušeností s problémy s výkonem hlášenými našimi uživateli a zákazníky.

Na úvod se ClusterControl skládá z několika hlavních komponent – ​​webové aplikace (frontend) založené na PHP a řady démonizovaných procesů (backend). Ty využívají databázi MySQL/MariaDB pro trvalé úložiště. Efektivně řídíte svůj cluster z webové aplikace, což bude převedeno na sérii volání procesů prováděných backendovými procesy za účelem správy a monitorování vašich databázových clusterů.

Databáze MySQL

Komponenty ClusterControl spoléhají na databázi MySQL nebo MariaDB jako trvalé úložiště pro monitorování dat shromážděných ze spravovaných uzlů a všech metadat ClusterControl (např. jaké úlohy jsou ve frontě, plány zálohování, stavy záloh, atd.). Ve výchozím nastavení instalační skript nainstaluje jakoukoli verzi, která přichází ze standardního úložiště operačního systému. Následuje verze MySQL/MariaDB instalovaná instalačním programem:

• 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

Instalační skript by provedl základní ladění, jako je konfigurace umístění datadir, portu MySQL, uživatele a velikosti zásobníku vyrovnávací paměti InnoDB na začátku fáze instalace. Po importu nebo vytvoření více clusterů/uzlů však nemusí být ladění vhodné. Se zvýšeným počtem uzlů, které je třeba monitorovat a spravovat, by ClusterControl spotřeboval více prostředků a databázová vrstva je obvykle prvním úzkým hrdlem, se kterým se uživatelé setkávají. K omezení příchozí zátěže může být zapotřebí další ladění.

ClusterControl je dostatečně chytrý na to, aby detekoval jakoukoli anomálii výkonu zápisem následujících řádků do souboru cmon_X.log (kde X je ID clusteru):

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

Výše uvedené jednoduše znamená, že načtení 70 hodnot pro komponentu "diskstat", kde většina času zpracování probíhalo ve fázi zpracování SQL, trvalo 220 ms (hodnota součtu) a 0 ms analýza výsledné sady SQL Z toho vyplývá, že vrstva SQL zabrala většinu času zpracování, když se ClusterControl pokusil dotazovat na datovou sadu.

Věříme, že většina SQL dotazů prováděných ClusterControl je správně optimalizována pro jednu instanci MySQL a používá správné indexování. Jednoduše řečeno, pokud se v souboru protokolu pravidelně objevuje něco podobného, ​​jako je výše uvedené, jsou v pořádku některá vylepšení databázové vrstvy, jak je ukázáno v následujících částech.

Ladění velikosti fondu vyrovnávací paměti InnoDB

Velikost vyrovnávací paměti je důležitou součástí a je třeba ji nakonfigurovat předem, aby se zlepšil výkon MySQL. Umožňuje, aby se zpracování MySQL odehrávalo uvnitř paměti místo zásahu do disku. Jednoduchým pravidlem je zkontrolovat poměr zásahů InnoDB a vyhledat následující řádek v části BUFFER POOL AND MEMORY:

Buffer pool hit rate 986 / 1000

Míra výskytu 986/1000 znamená, že z 1000 přečtení řádků bylo možné přečíst řádek v paměti RAM 986krát. Zbývajících 14krát musel načíst řádek dat z disku. Jednoduše řečeno, 1000/1000 je nejlepší hodnota, které se zde snažíme dosáhnout, což znamená, že často používaná data se plně vejdou do RAM.

Zvýšení hodnoty innodb_buffer_pool_size hodně pomůže k umístění většího prostoru pro MySQL pro práci. Předtím se však ujistěte, že máte dostatek zdrojů paměti RAM. Ve výchozím nastavení přiděluje ClusterControl 50 % paměti RAM do fondu vyrovnávacích pamětí. Pokud je hostitel vyhrazen pro ClusterControl, můžete ji dokonce posunout na vyšší hodnotu, například 70 %, za předpokladu, že ušetříte alespoň 2 GB paměti RAM pro procesy a mezipaměti operačního systému. Pokud nemůžete alokovat tolik, je jediným řešením zvýšení paměti RAM.

Změna této hodnoty vyžaduje restart MySQL (starší než MySQL 5.7.5), takže správné pořadí restartu služby bude:

1. Upravte hodnotu innodb_buffer_pool_size v souboru my.cnf.
2. Zastavte službu CMON.
3. Restartujte službu MySQL/MariaDB.
4. Spusťte službu CMON.

Nebo jednoduše restartujte hostitele, pokud si můžete dovolit delší prostoje.

Ladění max_connections

Ve výchozím nastavení nakonfiguruje instalační skript hodnotu max_connections až na 512. To je poměrně vysoké, i když rozumné, protože ClusterControl dosahuje sotva 200 připojení celkem, pokud není MySQL server sdílen s jinými aplikacemi nebo nemáte desítky MySQL uzlů monitorovaných ClusterControl (mluvíme o 30 a více uzlech).

Vysoká hodnota max_connections plýtvá zdroji a úprava hodnoty ovlivní maximální paměť nakonfigurovanou pro MySQL. Pokud je větší než systémová RAM, pak existuje šance, že proces serveru MySQL skončí s výjimkou OOM, pokud jsou použita všechna připojení.

Chcete-li to zkontrolovat, jednoduše vyhledejte stav MySQL max_used_connections. Níže je uveden maximální počet připojení, kterého kdy MySQL dosáhla na uzlu ClusterControl, který monitoruje 2 clustery s celkem 6 uzly MySQL:

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

Dobrá hodnota pro začátek je Max_used_connections x 2 a postupně ji zvyšujte, pokud hodnota trvale roste. Úpravu proměnné max_connections lze provést dynamicky pomocí příkazu SET GLOBAL.

Použití souboru socket MySQL

Ve výchozím nastavení instalační skript automaticky nakonfiguruje následující hodnotu hostitele uvnitř každého konfiguračního souboru databáze ClusterControl:

Výše uvedené přinutí klienta MySQL připojit se přes síť TCP, stejně jako připojení ke vzdálenému hostiteli MySQL, ačkoli ClusterControl běží na stejném serveru jako server MySQL. Záměrně jsme jej nakonfigurovali tímto způsobem, abychom zjednodušili proces instalace, protože téměř každá platforma OS předkonfiguruje soubor soketu MySQL jinak, což výrazně snižuje míru selhání instalace.

Změna hodnoty na "localhost" přinutí klienta místo toho použít soubor soketu MySQL Unix:

Na systémech založených na Unixu zacházejí programy MySQL s názvem hostitele localhost speciálně, a to způsobem, který se pravděpodobně liší od toho, co očekáváte ve srovnání s jinými programy založenými na síti. Pro připojení k localhost se programy MySQL pokoušejí připojit k místnímu serveru pomocí souboru soketu Unix. K tomu dochází, i když je zadána volba --port nebo -P pro specifikaci čísla portu.

Použití souboru soketu MySQL UNIX je mnohem bezpečnější a odřízne režii sítě. Vždy se doporučuje přes TCP. Musíte se však ujistit, že je soubor soketu správně nakonfigurován. Musí existovat na následujících direktivách uvnitř my.cnf a ve všech souborech voleb MySQL v uzlu ClusterControl, například:

[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

Změna souboru soketu bude také vyžadovat restart MySQL a CMON. Pokud používáte "localhost", můžete přidat některé další možnosti konfigurace, jako je skip-networking=1, abyste zabránili přijímání vzdálených připojení. Náš obraz ClusterControl Docker používá tento přístup k překonání omezení v docker-proxy při vazbě na porty.

OpenSSH s SSSD

ClusterControl používá protokol SSH jako svůj hlavní komunikační kanál pro správu a monitorování vzdálených uzlů. Výchozí konfigurace OpenSSH jsou docela slušné a ve většině případů by měly fungovat. V některých prostředích, kde je SSH integrováno s jinými nástroji pro vylepšení zabezpečení, jako je SElinux nebo System Security Services Daemon (SSSD), by to mohlo mít významný dopad na výkon SSH.

Viděli jsme mnoho případů, kdy stále rostoucí počet připojení SSH navazoval na každý ze spravovaných uzlů a nakonec server ClusterControl i všechny spravované uzly vyčerpaly svou systémovou paměť připojeními SSH. V některých případech by problém mohl vyřešit pouze normální úplný restart systému každou noc na serveru ClusterControl.

Pokud provozujete svou infrastrukturu s démonem System Security Services Daemon (SSSD), doporučuje se, abyste okomentovali následující řádek v konfiguraci klienta OpenSSH v /etc/ssh/ssh_config v uzlu ClusterControl:

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

Výše uvedené přeskočí použití SSSD ke správě hostitelského klíče, které bude místo toho zpracovávat klient OpenSSH.

Počínaje ClusterControl 1.7.0 máte možnost používat s Prometheus monitorovací nástroj založený na agentech. Díky monitorování založenému na agentech ClusterControl nepoužívá SSH k vzorkování metrik hostitelů, které mohou být v některých prostředích nadměrné.

Systém souborů a rozdělení

Řadič ClusterControl zapisuje novou položku do svého souboru protokolu téměř každou sekundu pro každý cluster. Pro ty, kteří chtějí využít výhod tohoto sekvenčního zápisu na disk a chtěli by ušetřit náklady, mohou k tomuto účelu použít vřetenový disk. Upravte následující řádek uvnitř všech cmon_X.cnf:

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

Nahraďte X ID clusteru a restartujte službu CMON, aby se změny projevily.

Pokud používáte ClusterControl jako úložiště záloh, doporučuje se alokovat dostatek místa na disku na samostatný oddíl jiný než kořenový. Je lepší, když je oddíl umístěn na síťovém nebo klastrovém systému souborů pro snadné připojení k cílovým uzlům při provádění operace obnovy. Viděli jsme případy, kdy vytvořené zálohy spotřebovaly veškerý diskový prostor hlavního oddílu, což nakonec ovlivnilo ClusterControl a jeho součásti.

Udržovat aktuální

ClusterControl má krátký cyklus vydávání – alespoň jedno nové hlavní vydání každé čtvrt roku plus týdenní opravné opravy (většinou opravy chyb – pokud nějaké existují). Důvodem je, že ClusterControl podporuje více databázových prodejců a verzí, operačních systémů a hardwarových platforem. Často se zavádějí nové věci a staré věci se zavrhují z toho, co je poskytováno. ClusterControl musí držet krok se všemi změnami zavedenými dodavateli aplikací a pokaždé se řídit osvědčenými postupy.

Doporučujeme uživatelům, aby vždy používali nejnovější verzi ClusterControl (upgrade je snadný) spolu s nejnovějším webovým prohlížečem (vytvořeným a testovaným na Google Chrome a Mozilla Firefox), protože velmi pravděpodobně využíváme nové funkce dostupné v nejnovější verzi.

Poslední myšlenky

Pokud máte nějaké dotazy nebo narazíte na nějaké problémy nebo problémy s pomalostí při používání ClusterControl, kontaktujte nás prosím prostřednictvím našeho kanálu podpory. Návrhy a zpětná vazba jsou velmi vítány.

Šťastné ladění!