{"id":92570,"date":"2020-08-28T19:42:21","date_gmt":"2020-08-28T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker"},"modified":"2020-08-28T19:42:21","modified_gmt":"2020-08-28T17:42:21","slug":"modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Modelarea clusterelor tolerate la defecte pe baz\u0103 de PostgreSQL \u0219i Pacemaker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introducere<\/h1>\n

<\/p>\n

Cu ceva timp \u00een urm\u0103, am fost \u00eens\u0103rcinat s\u0103 dezvolt un cluster tolerant la defecte pentru PostgreSQL<\/a><\/noindex>, care func\u021bioneaz\u0103 \u00een mai multe centre de date interconectate prin fibr\u0103 optic\u0103 \u00eentr-un singur ora\u0219 \u0219i capabil s\u0103 suporte defectarea (de exemplu, pierderea aliment\u0103rii) a unui centru de date. Ca software responsabil pentru toleran\u021ba la defecte, am ales Pacemaker<\/a><\/noindex>, deoarece este solu\u021bia oficial\u0103 de la RedHat pentru crearea clusterelor tolerate la defecte. Este avantajos deoarece RedHat ofer\u0103 suport pentru aceasta \u0219i, \u00een plus, solu\u021bia este versatil\u0103 (modular\u0103). Cu ajutorul s\u0103u, se poate asigura toleran\u021ba la defecte nu doar pentru PostgreSQL, ci \u0219i pentru alte servicii, fie utiliz\u00e2nd module standard, fie cre\u00e2ndu-le pentru nevoile specifice.<\/p>\n

<\/p>\n

Pentru aceast\u0103 solu\u021bie, s-a ivit o \u00eentrebare rezonabil\u0103: c\u00e2t de tolerant va fi clusterul tolerant la defecte? Pentru a investiha acest lucru, am dezvoltat un laborator de testare care imit\u0103 diverse defecte la nodurile clusterului, a\u0219teapt\u0103 restabilirea func\u021bionalit\u0103\u021bii, restaureaz\u0103 nodul defectat \u0219i continu\u0103 testarea \u00een ciclu. Ini\u021bial, acest proiect a fost numit hapgsql, dar cu vremea m-am plictisit de un nume cu o singur\u0103 vocal\u0103. A\u0219adar, bazele de date tolerate la defecte (\u0219i IP-urile float care le indic\u0103) le-am \u00eenceput s\u0103 le numesc krogan<\/strong> (un personaj dintr-un joc video care are toate organele vitale duplicate), iar nodurile, clusterele \u0219i proiectul \u00een sine \u2014 tuchanka<\/strong> (planeta unde locuiesc kroganii).<\/p>\n

<\/p>\n

Acum conducerea a aprobat deschiderea proiectului pentru comunitatea open source sub licen\u021ba MIT<\/a><\/noindex>. README-ul va fi tradus \u00een cur\u00e2nd \u00een limba englez\u0103 (deoarece se a\u0219teapt\u0103 ca principalii consumatori s\u0103 fie dezvoltatorii de Pacemaker \u0219i PostgreSQL), iar vechea variant\u0103 a README-ului \u00een rus\u0103 am decis s\u0103 o prezint (par\u021bial) sub form\u0103 de acest articol.<\/p>\n

<\/p>\n

\"Modelarea<\/p>\n

<\/a><\/noindex><\/p>\n

Clusterele sunt desf\u0103\u0219urate pe ma\u0219ini virtuale VirtualBox<\/a><\/noindex>. Vor fi desf\u0103\u0219urate \u00een total 12 ma\u0219ini virtuale (\u00een total 36GiB), care formeaz\u0103 4 clustere tolerate la defecte (variante diferite). Primele dou\u0103 clustere constau din dou\u0103 servere PostgreSQL, care sunt amplasate \u00een diferite centre de date, \u0219i un server comun witness<\/em> c quorum device<\/strong> (amplasat pe o ma\u0219in\u0103 virtual\u0103 ieftin\u0103 \u00een al treilea centru de date), care rezolv\u0103 incertitudinea 50%\/50%<\/strong>, oferindu-\u0219i votul pentru una dintre p\u0103r\u021bi. Al treilea cluster este \u00een trei centre de date: un master, dou\u0103 slave, f\u0103r\u0103 quorum device<\/strong>. Clust erul patru este format din patru servere PostgreSQL, c\u00e2te dou\u0103 pentru fiecare centru de date: un master \u0219i celelalte replica, \u0219i utilizeaz\u0103 de asemenea witness<\/em> c quorum device<\/strong>. Clusterul patru rezist\u0103 la defec\u021biunea a dou\u0103 servere sau a unui centru de date. Aceast\u0103 solu\u021bie poate fi, dac\u0103 este necesar, extins\u0103 la un num\u0103r mai mare de replici.<\/p>\n

<\/p>\n

Serviciul de timp exact ntpd<\/a><\/noindex> de asemenea este reconfigurat pentru disponibilitate ridicat\u0103, dar utilizeaz\u0103 metoda ntpd<\/code> (orphan mode<\/em>). Serverul general witness<\/em> func\u021bioneaz\u0103 ca un server NTP central, furniz\u00e2nd timpul s\u0103u tuturor clusterelor, astfel sincroniz\u00e2nd toate serverele \u00eentre ele. Dac\u0103 witness<\/em> se defecteaz\u0103 sau devine izolat, atunci unul dintre serverele din cluster va \u00eencepe s\u0103 ofere timpul s\u0103u (\u00een interiorul clusterului). Un proxy de cache HTTP proxy<\/strong> de asemenea este ridicat pe witness<\/em>, cu ajutorul c\u0103ruia celelalte ma\u0219ini virtuale au acces la repozitoarele Yum. \u00cen realitate, servicii precum timpul exact \u0219i proxy-ul vor fi cu siguran\u021b\u0103 g\u0103zduite pe servere dedicate, \u00eens\u0103 \u00een stand acestea sunt plasate pe witness<\/em> doar pentru a economisi num\u0103rul de ma\u0219ini virtuale \u0219i spa\u021biu.<\/p>\n

<\/p>\n

Versiuni<\/h1>\n

<\/p>\n

v0. Func\u021bioneaz\u0103 cu CentOS 7 \u0219i PostgreSQL 11 pe VirtualBox 6.1.<\/p>\n

<\/p>\n

Structura clusterelor<\/h1>\n

<\/p>\n

Toate clusterele sunt destinate g\u0103zduirii \u00een mai multe centre de date, fiind unite \u00eentr-o re\u021bea plat\u0103 \u0219i trebuie s\u0103 reziste la defec\u021biunea sau izolarea de re\u021bea a unui centru de date. Prin urmare, nu este posibil<\/strong> s\u0103 se utilizeze pentru a proteja de split-brain<\/strong> tehnologia standard Pacemaker, care se nume\u0219te STONITH<\/em> (Shoot The Other Node In The Head) sau fencing<\/em>. Conceputul este: dac\u0103 nodurile din cluster \u00eencep s\u0103 suspecteze c\u0103 ceva nu este \u00een regul\u0103 cu un nod, nu r\u0103spunde sau se comport\u0103 incorect, acestea \u00eel deconecteaz\u0103 for\u021bat prin dispozitive \u201eexterne\u201d, cum ar fi un card de control IPMI sau un UPS. Dar aceasta va func\u021biona doar \u00een cazurile \u00een care, \u00een cazul unei defec\u021biuni unice a serverului, IPMI sau UPS continu\u0103 s\u0103 func\u021bioneze. Aici este prev\u0103zut\u0103 o protec\u021bie \u00eempotriva unei defec\u021biuni mult mai catastrofale, c\u00e2nd \u00eentregul centru de date se defecteaz\u0103 (de exemplu, r\u0103m\u00e2ne f\u0103r\u0103 energie). \u00cen cazul unei astfel de defec\u021biuni, toate stonith<\/em>-dispozitivele (IPMI, UPS etc.) nu vor func\u021biona nici ele.<\/p>\n

<\/p>\n

\u00cen schimb, sistemul se bazeaz\u0103 pe ideea de vot. Toate nodurile au drept de vot, iar func\u021bioneaz\u0103 doar cele care v\u0103d mai mult de jum\u0103tate din toate nodurile. Aceast\u0103 cantitate \u201ejum\u0103tate + 1\u201d se nume\u0219te cvorum<\/strong>. Dac\u0103 nu se adun\u0103 cvorumul, nodul decide c\u0103 se afl\u0103 \u00een izolare de re\u021bea \u0219i trebuie s\u0103 \u00ee\u0219i dezactiveze resursele, adic\u0103 este o astfel de protec\u021bie \u00eempotriva split-brain<\/strong>. Dac\u0103 software-ul care r\u0103spunde de acest comportament nu func\u021bioneaz\u0103, atunci va trebui s\u0103 intervin\u0103 un watchdog, de exemplu, bazat pe IPMI.<\/p>\n

<\/p>\n

Dac\u0103 num\u0103rul de noduri este par (cluster \u00een dou\u0103 centre de date), atunci poate ap\u0103rea a\u0219a-numita incertitudine 50%\/50%<\/strong> (fifty-fifty<\/em>), c\u00e2nd izolarea de re\u021bea \u00eemparte clusterul exact \u00een dou\u0103. Prin urmare, pentru un num\u0103r par de noduri se adaug\u0103 quorum device<\/strong> \u2014 un demon nepreten\u021bios care poate fi pornit pe cea mai ieftin\u0103 ma\u0219in\u0103 virtual\u0103 din al treilea centru de date. Acesta \u00ee\u0219i d\u0103 votul unuia dintre segmente (pe care \u00eel vede), astfel rezolv\u00e2nd incertitudinea 50%\/50%. Serverul pe care va fi pornit dispozitivul de cvorum l-am numit witness<\/em> (terminologie din repmgr, mi-a pl\u0103cut).<\/p>\n

<\/p>\n

Resursele pot fi mutate dintr-un loc \u00een altul, de exemplu, de pe servere defecte pe cele func\u021bionale sau la comanda administratorilor de sistem. Pentru ca clien\u021bii s\u0103 \u0219tie unde se afl\u0103 resursele de care au nevoie (unde s\u0103 se conecteze?), se folosesc IP-uri flotante<\/em> (float IP<\/strong>). Acestea sunt IP-uri pe care Pacemaker le poate muta \u00eentre noduri (totul se afl\u0103 \u00eentr-o re\u021bea plat\u0103). Fiecare dintre ele simbolizeaz\u0103 o resurs\u0103 (serviciu) \u0219i va fi situat acolo unde trebuie s\u0103 te conectezi pentru a accesa acest serviciu (\u00een cazul nostru BD).<\/p>\n

<\/p>\n

Tuchanka1 (schema cu compactare)<\/h2>\n

<\/p>\n

Structura<\/h3>\n

<\/p>\n

\"Modelarea<\/p>\n

<\/p>\n

Ideea a fost c\u0103 avem multe baze de date mici cu o sarcin\u0103 sc\u0103zut\u0103, pentru care nu este rentabil s\u0103 \u00eentre\u021binem un server slave dedicat \u00een modul hot standby pentru tranzac\u021bii read only (nu este nevoie de o astfel de risip\u0103 de resurse).<\/p>\n

<\/p>\n

\u00cen fiecare centru de date exist\u0103 un server. Fiecare server are dou\u0103 instan\u021be PostgreSQL (\u00een terminologia PostgreSQL, acestea se numesc clustere, dar pentru a evita confuzia, le voi numi instan\u021be, \u00een analogie cu alte baze de date, iar clusterele le voi numi doar clustere Pacemaker). O instan\u021b\u0103 func\u021bioneaz\u0103 \u00een modul master, \u0219i doar ea ofer\u0103 servicii (doar la ea se face referin\u021b\u0103 cu IP flotant). Cealalt\u0103 instan\u021b\u0103 func\u021bioneaz\u0103 ca slujitor pentru al doilea centru de date \u0219i va oferi servicii doar dac\u0103 masterul s\u0103u va c\u0103dea. Deoarece, \u00een majoritatea timpului, doar o instan\u021b\u0103 din dou\u0103 (masterul) va oferi servicii (va executa cereri), toate resursele serverului sunt optimizate pentru master (se aloc\u0103 memorie pentru cache shared_buffers etc.), dar astfel \u00eenc\u00e2t \u0219i a doua instan\u021b\u0103 s\u0103 aib\u0103 suficiente resurse (chiar \u0219i pentru o func\u021bionare suboptimal\u0103 prin cache-ul sistemului de fi\u0219iere) \u00een cazul unei defec\u021biuni a unuia dintre centrele de date. Slujitorul nu ofer\u0103 servicii (nu execut\u0103 cereri read only) \u00een timpul func\u021bion\u0103rii normale a clustere, pentru a evita o competi\u021bie pentru resurse cu masterul pe aceea\u0219i ma\u0219in\u0103.<\/p>\n

<\/p>\n

\u00cen cazul a dou\u0103 noduri, toleran\u021ba la defec\u021biuni este posibil\u0103 doar \u00een cazul replic\u0103rii asincrone, deoarece \u00een cazul replic\u0103rii sincrone, c\u0103derea slujitorului va duce la oprirea masterului.<\/p>\n

<\/p>\n

Defec\u021biunea witness<\/h3>\n

<\/p>\n

\"Modelarea<\/p>\n

<\/p>\n

Defec\u021biunea witness (quorum device<\/em>) o voi lua \u00een considerare doar pentru clusterul Tuchanka1, cu toate celelalte va fi aceea\u0219i poveste. \u00cen cazul unei defec\u021biuni a witness-ului, structura clusterului nu se va schimba, totul va continua s\u0103 func\u021bioneze la fel ca \u0219i p\u00e2n\u0103 acum. \u00cens\u0103 cvorumul va deveni 2 din 3, astfel \u00eenc\u00e2t orice defec\u021biune ulterioar\u0103 va deveni fatal\u0103 pentru cluster. Oricum, va trebui reparat urgent.<\/p>\n

<\/p>\n

Defec\u021biunea Tuchanka1<\/h3>\n

<\/p>\n

\"Modelarea<\/p>\n

<\/p>\n

Defec\u021biunea unuia dintre centrele de date pentru Tuchanka1. \u00cen acest caz witness<\/em> \u00ee\u0219i d\u0103 votul celui de-al doilea nod de la al doilea centru de date. Acolo, fostul slujitor se transform\u0103 \u00een master, rezultatul fiind c\u0103 ambele mastere func\u021bioneaz\u0103 pe un singur server, iar ambele au referin\u021be la IP-urile lor flotante.<\/p>\n

<\/p>\n

Tuchanka2 (clasic)<\/h2>\n

<\/p>\n

Structura<\/h3>\n

<\/p>\n

\"Modelarea<\/p>\n

<\/p>\n

Schema clasic\u0103 din dou\u0103 noduri. Pe unul func\u021bioneaz\u0103 masterul, pe cel\u0103lalt slujitorul. Ambele pot executa cereri (slujitorul doar read only), de aceea ambele au referin\u021be la IP flotant: krogan2 \u2014 pentru master, krogan2s1 \u2014 pentru slujitor. Toleran\u021ba la defec\u021biuni va exista at\u00e2t pentru master, c\u00e2t \u0219i pentru slujitor.<\/p>\n

<\/p>\n

\u00cen cazul a dou\u0103 noduri, toleran\u021ba la defec\u021biuni este posibil\u0103 doar \u00een cazul replic\u0103rii asincrone, deoarece \u00een cazul replic\u0103rii sincrone, c\u0103derea slujitorului va duce la oprirea masterului.<\/p>\n

<\/p>\n

Defec\u021biunea Tuchanka2<\/h3>\n

<\/p>\n

\"Modelarea<\/p>\n

<\/p>\n

\u00cen cazul unei defec\u021biuni a unuia dintre centrele de date witness<\/em> voteaz\u0103 pentru al doilea. Pe singurul centru de date func\u021bional va fi ridicat un master, iar ambele IP float: cel master \u0219i cel de lucru \u00eei vor indica. Desigur, instan\u021ba trebuie s\u0103 fie configurat\u0103 astfel \u00eenc\u00e2t s\u0103 aib\u0103 suficiente resurse (limite pentru conexiuni etc.) pentru a gestiona \u00een mod simultan toate conexiunile \u0219i cererile de la IP-urile float master \u0219i slave. Asta \u00eenseamn\u0103 c\u0103 \u00een condi\u021bii normale de func\u021bionare, ar trebui s\u0103 aib\u0103 un rezervor suficient de limite.<\/p>\n

<\/p>\n

Tuchanka4 (multe slave)<\/h2>\n

<\/p>\n

Structura<\/h3>\n

<\/p>\n

\"Modelarea<\/p>\n

<\/p>\n

Este deja o alt\u0103 extrem\u0103. Exist\u0103 baze de date care primesc foarte multe cereri de tip read-only (situa\u021bia tipic\u0103 a unui site cu \u00eenc\u0103rcare mare). Tuchanka4 este o situa\u021bie \u00een care slavele pot fi trei sau mai multe pentru a gestiona aceste cereri, dar totu\u0219i nu prea multe. La un num\u0103r foarte mare de slave, va trebui s\u0103 se inventeze un sistem ierarhic de replicare. \u00cen cel mai simplu caz (\u00een imagine), \u00een fiecare dintre cele dou\u0103 centre de date se afl\u0103 c\u00e2te dou\u0103 servere, pe fiecare dintre ele c\u00e2te o instan\u021b\u0103 PostgreSQL.<\/p>\n

<\/p>\n

O alt\u0103 caracteristic\u0103 a acestui sistem este c\u0103 aici se poate organiza deja o replicare sincron\u0103. Aceasta este configurat\u0103 pentru a replica, dac\u0103 este posibil, \u00eentr-un alt centru de date, \u0219i nu pe o replic\u0103 \u00een acela\u0219i centru de date cu masterul. La master \u0219i la fiecare slave se indic\u0103 un IP float. Ideal ar fi ca \u00eentre slave s\u0103 se efectueze un balansare a cererilor folosind un sql proxy<\/em>, de exemplu, pe partea clientului. Fiecare tip de client poate necesita un tip diferit sql proxy<\/em>, \u0219i doar dezvoltatorii clien\u021bilor \u0219tiu cine ce are nevoie. Aceast\u0103 func\u021bionalitate poate fi implementat\u0103 fie cu un demon extern, fie cu o bibliotec\u0103 client (connection pool) etc. Toate acestea dep\u0103\u0219esc subiectul clusterului de baze de date tolerant la defec\u021biuni (toleran\u021ba la defec\u021biuni SQL proxy<\/em> poate fi implementat independent, \u00eempreun\u0103 cu toleran\u021ba la defec\u021biuni a clientului).<\/p>\n

<\/p>\n

Defec\u021biunea Tuchanka4<\/h3>\n

<\/p>\n

\"Modelarea<\/p>\n

<\/p>\n

\u00cen cazul defec\u021biunii unui centru de date (adic\u0103 a dou\u0103 servere), martorul voteaz\u0103 pentru al doilea. Drept rezultat, \u00een al doilea centru de date func\u021bioneaz\u0103 dou\u0103 servere: pe unul func\u021bioneaz\u0103 masterul, iar acesta indic\u0103 IP-ul float master pentru primirea cererilor read-write; iar pe cel de-al doilea server func\u021bioneaz\u0103 un slave cu replicare sincron\u0103, care este indicat de unul dintre IP-urile float slave (pentru cererile read-only).<\/p>\n

<\/p>\n

Primul lucru de men\u021bionat: nu toate IP-urile float slave vor fi func\u021bionale, ci doar unul. \u0218i pentru a func\u021biona corect cu acesta, va fi necesar ca sql proxy<\/em> redirigeaz\u0103 toate cererile c\u0103tre singurul IP float r\u0103mas; iar dac\u0103 sql proxy<\/em> nu, atunci se pot enumera toate IP-urile float ale sclavilor prin virgul\u0103 \u00een URL pentru conectare. \u00cen acest caz, libpq<\/em> conexiunea va fi la primul IP func\u021bional, a\u0219a cum este implementat \u00een sistemul de testare automat\u0103. Este posibil ca \u00een alte biblioteci, de exemplu, JDBC, s\u0103 nu func\u021bioneze a\u0219a \u0219i s\u0103 fie necesar sql proxy<\/em>. A\u0219a s-a realizat deoarece pentru IP-urile float ale sclavilor exist\u0103 o interdic\u021bie de a se ridica simultan pe acela\u0219i server, astfel \u00eenc\u00e2t acestea s\u0103 se distribuie uniform pe serverele sclav, dac\u0103 sunt mai multe.<\/p>\n

<\/p>\n

Al doilea: chiar \u0219i \u00een cazul unei defec\u021biuni a centrului de date, va r\u0103m\u00e2ne o replicare sincron\u0103. \u0218i chiar dac\u0103 va avea loc o a doua defec\u021biune, adic\u0103 \u00een centrul de date r\u0103mas va ie\u0219i din func\u021biune unul dintre cele dou\u0103 servere, clusterul, de\u0219i va \u00eenceta s\u0103 ofere servicii, va p\u0103stra totu\u0219i informa\u021biile despre toate tranzac\u021biile confirmate, pentru care a dat o confirmare de commit (nu va exista pierdere de informa\u021bii \u00een cazul unei a doua defec\u021biuni).<\/p>\n

<\/p>\n

Tuchanka3 (3 centre de date)<\/h2>\n

<\/p>\n

Structura<\/h3>\n

<\/p>\n

\"Modelarea<\/p>\n

<\/p>\n

Acesta este un cluster pentru situa\u021bia \u00een care exist\u0103 trei centre de date complet func\u021bionale, \u00een fiecare dintre care exist\u0103 un server Baz\u0103 de Date complet func\u021bional. \u00cen acest caz quorum device<\/em> nu este necesar. \u00centr-un centru de date func\u021bioneaz\u0103 masterul, iar \u00een celelalte dou\u0103 \u2014 sclavii. Replicarea este sincron\u0103, tip ANY (slave1, slave2), adic\u0103 clientului \u00eei va veni o confirmare a commitului atunci c\u00e2nd oricare dintre sclavi r\u0103spunde \u00eent\u00e2i c\u0103 a acceptat commitul. Resursele sunt indicate de un IP float pentru master \u0219i dou\u0103 pentru sclavi. Spre deosebire de Tuchanka4, toate cele trei IP-uri float sunt rezistente la erori. Pentru balansarea interog\u0103rilor SQL read-only se poate folosi sql proxy<\/em> (cu o rezisten\u021b\u0103 la erori separat\u0103), fie s\u0103 aloce un IP float sclav unei jum\u0103t\u0103\u021bi din clien\u021bi, iar celeilalte jum\u0103t\u0103\u021bi \u2014 al doilea.<\/p>\n

<\/p>\n

Defec\u021biunea Tuchanka3<\/h3>\n

<\/p>\n

\"Modelarea<\/p>\n

<\/p>\n

\u00cen cazul unei defec\u021biuni a unuia dintre centrele de date, r\u0103m\u00e2n dou\u0103. \u00cen unul este ridicat masterul \u0219i IP-ul float de la master, iar \u00een cel\u0103lalt \u2014 sclavul \u0219i ambele IP-uri float ale sclavilor (pe instan\u021b\u0103 trebuie s\u0103 existe un rezervor dublu pentru resurse, pentru a accepta toate conexiunile de la ambele IP-uri float ale sclavilor). \u00centre master \u0219i sclav exist\u0103 replicare sincron\u0103. De asemenea, clusterul va p\u0103stra informa\u021bii despre tranzac\u021biile confirmate \u0219i aprobate (nu va exista pierdere de informa\u021bii) \u00een cazul distrugerii a dou\u0103 centre de date (dac\u0103 acestea nu sunt distruse simultan).<\/p>\n

<\/p>\n

Am decis s\u0103 nu includ o descriere detaliat\u0103 a structurii fi\u0219ierelor \u0219i desf\u0103\u0219ur\u0103rii. Cei care doresc s\u0103 experimenteze pot citi toate acestea \u00een README. Prezent\u0103m doar descrierea test\u0103rii automate.<\/em><\/p>\n

<\/p>\n

Sistem de testare automat\u0103<\/h1>\n

<\/p>\n

Pentru a verifica rezisten\u021ba la defec\u021biuni a clusterele prin simularea diferitelor defecte, a fost realizat un sistem de testare automat\u0103. Aceasta este pornit\u0103 printr-un script test\/failure<\/code>. Scriptul poate accepta ca parametri numerele clustere pe care dori\u021bi s\u0103 le testa\u021bi. De exemplu, aceast\u0103 comand\u0103:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
va testa doar al doilea \u0219i al treilea cluster. Dac\u0103 parametrii nu sunt specifica\u021bi, toate clusterele vor fi testate. Toate clusterele sunt testate simultan, iar rezultatul este afi\u0219at \u00een panoul tmux. Tmux folose\u0219te un server tmux dedicat, a\u0219adar scriptul poate fi pornit din tmux-ul implicit, ceea ce va duce la un tmux \u00eennodat. V\u0103 recomand s\u0103 folosi\u021bi un terminal \u00eentr-o fereastr\u0103 mare \u0219i cu un font mic. \u00cenainte de a \u00eencepe testarea, toate ma\u0219inile virtuale sunt restaurate la un snapshot de la finalizarea scriptului. setup<\/code>.<\/p>\n
<\/p>\n
\"Modelarea<\/p>\n
<\/p>\n
Terminalul este \u00eemp\u0103r\u021bit \u00een coloane \u00een func\u021bie de num\u0103rul clustere testate, implicit (\u00een captur\u0103 de ecran) acestea sunt patru. Con\u021binutul coloanelor \u00eel voi explica folosind exemplul Tuchanka2. Panourile din captur\u0103 sunt numerotate:<\/p>\n
<\/p>\n
    \n
  1. Aici este afi\u0219at\u0103 statistica testelor. Coloanele:\n