Sådan optimeres ydeevnen af ​​ClusterControl og dens komponenter

Overvågning og styring er afgørende for ethvert produktionsmiljø, fordi ydeevne betyder noget. Langsomme brugergrænseflader, der halter eller ikke reagerer, forsinkede advarsler og klyngejob-timeouts, når serveren er udsultet af ressourcer, er alle ting, der kan forårsage problemer. Der er måder at forbedre ydeevnen af ​​ClusterControl på, især hvis du administrerer flere klynger, og hver klynge indeholder flere noder. Denne blog giver nogle tuning tips. Punkterne, der er uddybet her, er sammensat på baggrund af vores erfaring med at håndtere ydeevneproblemer, rapporteret af vores brugere og kunder.

Som en introduktion består ClusterControl af flere hovedkomponenter - en webapplikation (frontend) baseret på PHP og en række dæmoniserede processer (backend). Disse udnytter en MySQL/MariaDB-database til vedvarende lagring. Du styrer effektivt din klynge fra webapplikationen, som vil blive oversat til en række proceskald, der udføres af backend-processerne for at administrere og overvåge dine databaseklynger.

MySQL-database

ClusterControl-komponenter er afhængige af en MySQL- eller MariaDB-database som det vedvarende lager til overvågning af data indsamlet fra de administrerede noder og alle ClusterControl-metadata (f.eks. hvilke job der er i køen, backup-planer, backup-statusser, etc.). Som standard vil installationsscriptet installere uanset hvilken version, der kommer af OS'ets standardlager. Følgende er MySQL/MariaDB-versionen, der installeres af installationsprogrammet:

• CentOS/Redhat 6 - MySQL 5.1

• CentOS/Redhat 7 - MariaDB 5.5

• Ubuntu 18.04 (Bionisk) - 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

Installationsscriptet ville foretage nogle grundlæggende justeringer, såsom at konfigurere datadir-placeringen, MySQL-porten, brugeren og InnoDB-bufferpuljens størrelse i begyndelsen af ​​installationsfasen. Men tuningen er muligvis ikke egnet, når du først har importeret eller oprettet flere klynger/knuder. Med et øget antal noder, der skal overvåges og administreres, ville ClusterControl bruge flere ressourcer, og databaselaget er almindeligvis den første flaskehals, som brugerne støder på. Noget yderligere justering kan være nødvendigt for at indeholde den indkommende belastning.

ClusterControl er smart nok til at registrere enhver uregelmæssig ydeevne ved at skrive følgende linjer op i cmon_X.log (hvor X er klynge-id'et):

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

Ovenstående betyder ganske enkelt, at det tog 220 ms (sumværdi) at indlæse 70 værdier for komponent "diskstat", hvor det meste af behandlingstiden foregik på SQL-behandlingsstadiet og 0 ms at parse SQL-resultatsættet . Dette konkluderer, at SQL-laget tog det meste af behandlingstiden, da ClusterControl forsøgte at forespørge datasættet.

Vi mener, at de fleste af de SQL-forespørgsler, der udføres af ClusterControl, er korrekt optimeret til en enkelt MySQL-instans og bruger korrekt indeksering. Simpelthen sagt, hvis du ser noget som ovenstående dukker op regelmæssigt i logfilen, er nogle forbedringer til databaselaget i orden, som vist i de følgende afsnit.

Tuning af InnoDB-bufferpoolstørrelse

Bufferpuljens størrelse er en vigtig komponent og skal konfigureres på forhånd for at forbedre MySQL-ydeevnen. Det tillader MySQL-behandling at ske inde i hukommelsen i stedet for at ramme disken. En simpel tommelfingerregel er at kontrollere InnoDB-hitforholdet og se efter følgende linje under sektionen BUFFERPOOL OG HUKOMMELSE:

Buffer pool hit rate 986 / 1000

Hitraten på 986/1000 indikerer, at ud af 1000 rækkelæsninger var den i stand til at læse rækken i RAM 986 gange. De resterende 14 gange skulle den læse rækken af ​​data fra disken. Simpelthen sagt, 1000/1000 er den bedste værdi, som vi forsøger at opnå her, hvilket betyder, at de ofte tilgåede data passer fuldt ud i RAM.

Forøgelse af innodb_buffer_pool_size værdien vil hjælpe meget med at rumme mere plads til MySQL at arbejde på. Sørg dog for, at du har tilstrækkelige RAM-ressourcer på forhånd. Som standard allokerer ClusterControl 50 % af RAM til bufferpuljen. Hvis værten er dedikeret til ClusterControl, kan du endda skubbe den til en højere værdi som 70%, forudsat at du sparer mindst 2 GB RAM til OS-processerne og caches. Hvis du ikke kan allokere så meget, er forøgelse af RAM den eneste løsning.

Ændring af denne værdi kræver en MySQL-genstart (ældre end MySQL 5.7.5), således vil den korrekte servicegenstartsrækkefølge være:

1. Rediger værdien for innodb_buffer_pool_size inde i my.cnf.
2. Stop CMON-tjenesten.
3. Genstart MySQL/MariaDB-tjenesten.
4. Start CMON-tjenesten.

Eller genstart simpelthen værten, hvis du har råd til længere nedetid.

Tuning max_connections

Som standard vil installationsscriptet konfigurere max_connections-værdien op til 512. Dette er ret højt, selvom det er fornuftigt, da ClusterControl knap når 200 forbindelser i alt, medmindre MySQL-serveren deles med andre applikationer, eller du har snesevis af MySQL-noder, der overvåges af ClusterControl (vi taler om 30 noder og mere).

En høj max_connections-værdi spilder ressourcer, og justering af værdien vil påvirke den maksimale hukommelse, der er konfigureret til MySQL. Hvis det er større end system-RAM, er der en chance for, at MySQL Server-processen afsluttes med en OOM-undtagelse, hvis alle forbindelser bruges.

For at kontrollere dette, skal du blot se efter max_used_connections MySQL-status. Følgende er de maksimale forbindelser, der nogensinde er nået af MySQL på en ClusterControl-node, der overvåger 2 klynger med i alt 6 MySQL-noder:

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

En god værdi at starte er Max_used_connections x 2, og øg den gradvist, hvis værdien konstant vokser. Ændring af max_connections-variablen kan udføres dynamisk via SET GLOBAL-sætning.

Brug af MySQL-socket-fil

Som standard vil installationsscriptet automatisk konfigurere følgende værtsværdi i alle ClusterControl-databasekonfigurationsfiler:

Ovenstående vil tvinge MySQL-klienten til at oprette forbindelse via TCP-netværk, ligesom at oprette forbindelse til en ekstern MySQL-vært, selvom ClusterControl kører på den samme server som MySQL-serveren. Vi har bevidst konfigureret det på denne måde for at forenkle installationsprocessen, da næsten alle OS-platforme prækonfigurerer MySQL-socket-filen forskelligt, hvilket i høj grad reducerer installationsfejlfrekvensen.

Ændring af værdien til "localhost" vil tvinge klienten til at bruge MySQL Unix-socket-filen i stedet:

På Unix-baserede systemer behandler MySQL-programmer værtsnavnet localhost specielt på en måde, der sandsynligvis er anderledes end hvad du forventer sammenlignet med andre netværksbaserede programmer. For forbindelser til localhost forsøger MySQL-programmer at oprette forbindelse til den lokale server ved at bruge en Unix-socket-fil. Dette sker, selvom der gives en --port eller -P mulighed for at angive et portnummer.

Brug af MySQL UNIX socket-fil er meget mere sikker og vil afskære netværksoverhead. Det anbefales altid over TCP. Du skal dog sikre dig, at socket-filen er konfigureret korrekt. Det skal eksistere på følgende direktiver inde i my.cnf og alle MySQL-optionsfiler på ClusterControl node, for eksempel:

[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

Ændring af socket-filen kræver også en MySQL- og CMON-genstart. Hvis du bruger "localhost", kan du tilføje nogle yderligere konfigurationsmuligheder såsom skip-networking=1, for at forhindre accept af fjernforbindelser. Vores ClusterControl Docker-billede bruger denne tilgang til at overvinde en begrænsning i docker-proxy ved binding til porte.

OpenSSH med SSSD

ClusterControl bruger SSH-protokol som sin vigtigste kommunikationskanal til at styre og overvåge fjernknuder. Standard OpenSSH-konfigurationerne er ret anstændige og burde fungere i de fleste tilfælde. I nogle miljøer, hvor SSH er integreret med andre sikkerhedsforbedringsværktøjer som SElinux eller System Security Services Daemon (SSSD), kan det dog have en betydelig indvirkning på SSH-ydelsen.

Vi har set mange tilfælde, hvor en stadigt stigende mængde af SSH-forbindelser etableret til hver af de administrerede noder og til sidst, både ClusterControl-serveren og alle administrerede noder maksimerer deres systemhukommelse med SSH-forbindelser. I nogle tilfælde kunne kun en normal fuld systemgenstart hver nat på ClusterControl-serveren løse problemet.

Hvis du kører din infrastruktur med System Security Services Daemon (SSSD), anbefales det, at du kommenterer følgende linje i OpenSSH-klientkonfigurationen på /etc/ssh/ssh_config på ClusterControl-noden:

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

Ovenstående vil springe over at bruge SSSD til at administrere værtsnøglen, som i stedet vil blive håndteret af OpenSSH-klienten.

Fra ClusterControl 1.7.0 har du mulighed for at bruge agentbaseret overvågningsværktøj med Prometheus. Med agentbaseret overvågning bruger ClusterControl ikke SSH til at prøve værtsmetrikker, som kan være for store i nogle miljøer.

Filsystem og partitionering

ClusterControl-controlleren skriver en ny post i sin logfil næsten hvert sekund for hver klynge. For dem, der ønsker at drage fordel af denne sekventielle skrivning på disk og gerne vil spare omkostninger, kan du bruge en spindelskive til dette formål. Rediger følgende linje inde i alle cmon_X.cnf:

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

Erstat X med klynge-id'et, og genstart CMON-tjenesten for at anvende ændringerne.

Hvis du bruger ClusterControl som backup-lageret, anbefales det, at du allokerer tilstrækkelig diskplads på en separat partition, som ikke er rodpartitionen. Det bliver bedre, hvis partitionen ligger på et netværks- eller klyngefilsystem for nem montering med de målrettede noder, når der udføres gendannelse. Vi har set tilfælde, hvor de oprettede sikkerhedskopier spiste al diskplads på hovedpartitionen, hvilket til sidst påvirker ClusterControl og dets komponenter.

Hold dig opdateret

ClusterControl har en kort udgivelsescyklus - mindst én ny større udgivelse hvert kvartal af året plus ugentlige vedligeholdelsespatches (for det meste fejlrettelser - hvis nogen). Årsagen er, at ClusterControl understøtter flere databaseleverandører og -versioner, operativsystemer og hardwareplatforme. Der er ofte nye ting, der bliver introduceret, og gamle ting, der bliver forældet fra det, der leveres. ClusterControl skal følge med i alle de ændringer, der indføres af applikationsleverandører og følge bedste praksis hver gang.

Vi anbefaler brugere altid at bruge den nyeste version af ClusterControl (opgradering er let) sammen med den nyeste webbrowser (bygget og testet på Google Chrome og Mozilla Firefox), da vi med stor sandsynlighed vil drage fordel af de nye funktioner, der er tilgængelige i den seneste version.

Sidste tanker

Hvis du har spørgsmål eller støder på problemer eller problemer med langsomhed, når du bruger ClusterControl, bedes du kontakte os via vores supportkanal. Forslag og feedback er meget velkomne.

God stemning!