Hur man optimerar prestanda för ClusterControl och dess komponenter

Övervakning och hantering är avgörande för alla produktionsmiljöer eftersom prestanda är viktigt. Långsamma användargränssnitt som släpar efter eller inte svarar, försenade varningar och tidsgränser för klusterjobb när servern svälter på resurser är alla saker som kan orsaka problem. Det finns sätt att förbättra prestandan för ClusterControl, särskilt om du hanterar flera kluster och varje kluster innehåller flera noder. Den här bloggen ger några trimtips. Punkterna som utvecklas här är sammanställda utifrån vår erfarenhet av att hantera prestandaproblem som rapporterats av våra användare och kunder.

Som en introduktion består ClusterControl av flera huvudkomponenter - en webbapplikation (frontend) baserad på PHP och ett antal demoniserade processer (backend). Dessa utnyttjar en MySQL/MariaDB-databas för beständig lagring. Du styr effektivt ditt kluster från webbapplikationen, som kommer att översättas till en serie processanrop som exekveras av backend-processerna för att hantera och övervaka dina databaskluster.

MySQL-databas

ClusterControl-komponenter förlitar sig på en MySQL- eller MariaDB-databas som den beständiga lagringen för övervakning av data som samlas in från de hanterade noderna och all ClusterControl-metadata (t.ex. vilka jobb som finns i kön, säkerhetskopieringsscheman, säkerhetskopieringsstatus, etc.). Som standard installerar installationsskriptet vilken version som helst som kommer från operativsystemets standardlager. Följande är MySQL/MariaDB-versionen som installeras av installationsprogrammet:

• 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

Installationsskriptet skulle göra en del grundläggande justeringar som att konfigurera datadir-platsen, MySQL-porten, användaren och storleken på InnoDB-buffertpoolen i början av installationsstadiet. Men justeringen kanske inte är lämplig när du väl har importerat eller skapat fler kluster/noder. Med ett ökat antal noder som ska övervakas och hanteras skulle ClusterControl använda mer resurser, och databaslagret är vanligtvis den första flaskhalsen som användare stöter på. Viss ytterligare justering kan behövas för att innehålla den inkommande lasten.

ClusterControl är smart nog att upptäcka prestandaavvikelser genom att skriva upp följande rader i cmon_X.log (där X är kluster-ID):

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

Ovanstående betyder helt enkelt att det tog 220 ms (summavärde) att ladda 70 värden för komponenten "diskstat", där det mesta av bearbetningstiden skedde i SQL-bearbetningsstadiet och 0 ms att analysera SQL-resultatuppsättningen . Detta drar slutsatsen att SQL-lagret tog det mesta av bearbetningstiden när ClusterControl försökte fråga datauppsättningen.

Vi tror att de flesta av SQL-frågorna som körs av ClusterControl är korrekt optimerade för en enda MySQL-instans och använder korrekt indexering. Enkelt sagt, om du ser något liknande ovan dyka upp regelbundet i loggfilen, är vissa förbättringar av databaslagret på sin plats, som visas i följande avsnitt.

Tuning InnoDB buffertpoolstorlek

Buffertpoolens storlek är en viktig komponent och måste konfigureras i förväg för att förbättra MySQL-prestandan. Det gör att MySQL-bearbetning kan ske i minnet istället för att träffa disken. En enkel tumregel är att kontrollera InnoDB-träffförhållandet och leta efter följande rad under avsnittet BUFFERPOOL OCH MINNE:

Buffer pool hit rate 986 / 1000

Träfffrekvensen på 986/1000 indikerar att av 1000 radläsningar kunde den läsa raden i RAM 986 gånger. De återstående 14 gångerna var den tvungen att läsa raden med data från disken. Enkelt sagt, 1000/1000 är det bästa värdet som vi försöker uppnå här, vilket innebär att de ofta åtkomliga data passar fullt ut i RAM.

Att öka värdet på innodb_buffer_pool_size kommer att hjälpa mycket att ge mer utrymme för MySQL att arbeta på. Se dock till att du har tillräckligt med RAM-resurser i förväg. Som standard allokerar ClusterControl 50 % av RAM-minnet till buffertpoolen. Om värden är dedikerad till ClusterControl kan du till och med skjuta den till ett högre värde som 70 %, förutsatt att du sparar minst 2 GB RAM till OS-processer och cachar. Om du inte kan allokera så mycket är att öka RAM-minnet den enda lösningen.

Att ändra detta värde kräver en MySQL-omstart (äldre än MySQL 5.7.5), så den korrekta omstartsordningen för tjänsten blir:

1. Ändra värdet för innodb_buffer_pool_size i my.cnf.
2. Stoppa CMON-tjänsten.
3. Starta om MySQL/MariaDB-tjänsten.
4. Starta CMON-tjänsten.

Eller helt enkelt starta om värden om du har råd med en längre driftstopp.

Tuning max_connections

Som standard kommer installationsskriptet att konfigurera max_connections-värdet upp till 512. Detta är ganska högt, även om det är rimligt, eftersom ClusterControl knappt når 200 anslutningar totalt, om inte MySQL-servern delas med andra applikationer eller om du har tiotals MySQL-noder som övervakas av ClusterControl (vi pratar om 30 noder och fler).

Ett högt max_connections-värde slösar med resurser och justering av värdet kommer att påverka det maximala minnet som konfigurerats för MySQL. Om det är större än system-RAM finns det en chans att MySQL Server-processen kommer att avslutas med ett OOM-undantag, om alla anslutningar används.

För att kontrollera detta, leta helt enkelt efter max_used_connections MySQL-status. Följande är de maximala anslutningar som någonsin nåtts av MySQL på en ClusterControl-nod som övervakar 2 kluster med totalt 6 MySQL-noder:

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

Ett bra värde att börja är Max_used_connections x 2, och gradvis öka det om värdet konstant växer. Ändring av variabeln max_connections kan göras dynamiskt via SET GLOBAL-satsen.

Använda MySQL-socketfil

Som standard kommer installationsskriptet automatiskt att konfigurera följande värdvärde i alla ClusterControl-databaskonfigurationsfiler:

Ovanstående kommer att tvinga MySQL-klienten att ansluta via TCP-nätverk, precis som att ansluta till en fjärransluten MySQL-värd även om ClusterControl körs på samma server som MySQL-servern. Vi har medvetet konfigurerat det på detta sätt för att förenkla installationsprocessen eftersom nästan varje OS-plattform förkonfigurerar MySQL-socket-filen på olika sätt, vilket avsevärt minskar antalet installationsfel.

Att ändra värdet till "localhost" tvingar klienten att använda MySQL Unix-socketfilen istället:

På Unix-baserade system behandlar MySQL-program värdnamnet localhost speciellt, på ett sätt som sannolikt skiljer sig från vad du förväntar dig jämfört med andra nätverksbaserade program. För anslutningar till localhost försöker MySQL-program att ansluta till den lokala servern med hjälp av en Unix-socket-fil. Detta inträffar även om ett --port eller -P alternativ ges för att ange ett portnummer.

Att använda MySQL UNIX-socket-fil är mycket säkrare och kommer att skära av nätverket. Det rekommenderas alltid över TCP. Du måste dock se till att socketfilen är korrekt konfigurerad. Det måste finnas på följande direktiv inuti my.cnf och alla MySQL-alternativfiler på ClusterControl-noden, till exempel:

[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

Att ändra socketfilen kräver också en omstart av MySQL och CMON. Om du använder "localhost", kan du sedan lägga till några ytterligare konfigurationsalternativ som skip-networking=1, för att förhindra att fjärranslutningar accepteras. Vår ClusterControl Docker-bild använder detta tillvägagångssätt för att övervinna en begränsning i docker-proxy vid bindning till portar.

OpenSSH med SSSD

ClusterControl använder SSH-protokoll som sin huvudsakliga kommunikationskanal för att hantera och övervaka fjärrnoder. Standard OpenSSH-konfigurationerna är ganska anständiga och borde fungera i de flesta fall. Men i vissa miljöer där SSH är integrerat med andra säkerhetsförbättringsverktyg som SElinux eller System Security Services Daemon (SSSD), kan det få betydande inverkan på SSH-prestandan.

Vi har sett många fall där en ständigt ökande mängd SSH-anslutningar upprättas till var och en av de hanterade noderna och så småningom, både ClusterControl-servern och alla hanterade noder maximerar sitt systemminne med SSH-anslutningar. I vissa fall kan bara en normal fullständig omstart av systemet varje natt på ClusterControl-servern lösa problemet.

Om du kör din infrastruktur med System Security Services Daemon (SSSD), rekommenderas det att du kommenterar följande rad i OpenSSH-klientkonfigurationen på /etc/ssh/ssh_config på ClusterControl-noden:

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

Ovanstående kommer att hoppa över användningen av SSSD för att hantera värdnyckeln, som kommer att hanteras av OpenSSH-klienten istället.

Från och med ClusterControl 1.7.0 har du möjlighet att använda agentbaserat övervakningsverktyg med Prometheus. Med agentbaserad övervakning använder ClusterControl inte SSH för att ta prov på värdstatistik som kan vara överdriven i vissa miljöer.

Filsystem och partitionering

ClusterControl-kontrollern skriver ny post i sin loggfil nästan varje sekund för varje kluster. För den som vill dra nytta av denna sekventiella skrivning på disk och vill spara kostnader kan du använda en spindelskiva för detta ändamål. Ändra följande rad i alla cmon_X.cnf:

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

Ersätt X med kluster-ID och starta om CMON-tjänsten för att tillämpa ändringarna.

Om du använder ClusterControl som säkerhetskopieringsarkiv, rekommenderas det att du allokerar tillräckligt med diskutrymme på en separat partition förutom rotpartitionen. Det blir bättre om partitionen finns i ett nätverksanslutet eller klustrat filsystem för enkel montering med de riktade noderna när du utför återställningsoperation. Vi har sett fall där de skapade säkerhetskopiorna tog upp allt diskutrymme på huvudpartitionen, vilket så småningom påverkade ClusterControl och dess komponenter.

Håll dig uppdaterad

ClusterControl har en kort utgivningscykel - minst en ny stor utgåva varje kvartal, plus veckovisa underhållskorrigeringar (mest buggfixar - om några). Anledningen är att ClusterControl stöder flera databasleverantörer och versioner, operativsystem och hårdvaruplattformar. Det är ofta nya saker som introduceras och gamla saker utfasas från det som tillhandahålls. ClusterControl måste hålla jämna steg med alla ändringar som införs av applikationsleverantörer och följa bästa praxis varje gång.

Vi rekommenderar användare att alltid använda den senaste versionen av ClusterControl (uppgradering är enkel) tillsammans med den senaste webbläsaren (byggd och testad i Google Chrome och Mozilla Firefox), eftersom vi med stor sannolikhet kommer att dra nytta av de nya funktionerna i den senaste versionen.

Sluta tankar

Om du har några frågor eller stöter på problem eller problem med långsamhet när du använder ClusterControl, vänligen kontakta oss via vår supportkanal. Förslag och feedback är mycket välkomna.

Lycklig stämning!