Continuăm
Continuați crearea clusterului, ați început prima parte.
De data aceasta voi vorbi despre configurarea clusterului.
Ultima dată am ajuns la concluzia că sincronizarea DRBD a început.
Dacă am ales același server ca serverul primar pentru ambele resurse, atunci după sincronizare ar trebui să vedem aproximativ această imagine în / proc / drbd:
Câmpul cel mai interesant aici este ds: UpToDate / UpToDate. ceea ce înseamnă că atât copiile locale cât și cele la distanță sunt actualizate.
După aceea, vom traduce resursele în modul secundar - apoi vor fi gestionate de cluster:
Deci, managerul de cluster.
Pacemaker utilizează infrastructura Corosync pentru comunicarea inter-nod, deci trebuie să o configurați mai întâi.
Corosync are suficientă funcționalitate largă și moduri multiple pentru a sprijini comunicarea între noduri (unicast, multicast, difuzare), are un suport RRP (redundantă Protocol Ring), care permite utilizarea mai multor moduri diferite de a comunica între nodurile de cluster pentru a minimiza riscul unui Split-cerebral, există situații în care conexiunea dintre noduri este complet pierdut, și ei amândoi cred că vecinul a murit. Ca urmare, ambele noduri intră în modul de lucru și începe haosul :)
Prin urmare, vom folosi atât replicarea cât și interfețele externe pentru a asigura conectivitatea clusterului.
Să începem
Acesta trebuie pus sub numele / etc / corosync / authkey pe ambele servere.
Apoi, creați config, trebuie să fie identic pe ambele noduri:
Totul, puteți rula Pacemaker (va lansa Corosync în avans).
Întreaga configurare a stimulatorului este realizată prin intermediul utilitarului CRM. și îl puteți rula pe orice server din cluster - va actualiza automat configurația pe toate nodurile după modificare.
Să vedem starea curentă:
Dacă totul este așa, atunci conexiunea este stabilită și nodurile sunt văzute una de cealaltă.
Acum avem nevoie de resurse pentru a gestiona SCST.
Odată le-am găsit undeva pe Internet, modificat la nevoile lor și postat pe Github.
- SCSTLun - gestionează crearea de dispozitive
- SCSTTarget - gestionează crearea obiectivelor iSCSI
Aceasta, de fapt, scripturile de bash obișnuite, care implementează un simplu pacemaker API.
Puneți-le în /usr/lib/ocf/resource.d/heartbeat. astfel încât managerul de cluster să le vadă.
Apoi, executați crm și introduceți modul de configurare:
Voi da un exemplu de configurație:
Setările comune ale clusterului
Ele sunt la baza. Important aici nu-cvorum-politica = «ignora» și de așteptat-cvorum voturi = «2» - avem un grup de 2 servere și un cvorum nu poate fi aici bine în nici un fel, așa că ignorați.
Există, de asemenea, resurse speciale, de exemplu DRBD (ocf: linbit: drbd), care au moduri Master / Slave.
Atunci când tranziția nodului la modul activ, managerul de cluster va transfera resursa în modul master și invers. DRBD va trece apoi de la secundar la primar. Pentru el, specificăm numele resursei și calea spre configurația DRBD (probabil, poate fi omis, nu-mi amintesc exact).
Urmează resursele noastre auto-scrise.
Pentru ocf: bataie de inimă: SCSTLun, specificăm IQN-ul țintă la care va fi adăugat, numele dispozitivului. LUN - un număr (ținta trebuie să fie LUN 0, altfel unii inițiatori aruncă acoperișul), calea spre dispozitivul exportat și dispozitivul de manipulare.
Operatorul trebuie să fie oprit în detaliu - acesta este modul în care SCST va funcționa cu dispozitivul nostru.
De interesant este:- disc - de fapt, este doar o comandă SCSI direct de la inițiator la dispozitivul SCSI, cel mai simplu mod, dar funcționează numai cu dispozitive reale SCSI. dispozitiv de export DRBD
- vdisk_blockio - deschide aparatul ca bloc, ocolind memoria cache a sistemului de operare. Folosit dacă nu trebuie să cache I / O
- vdisk_fileio - deschide dispozitivul ca fișier, permițând utilizarea cache-ului de pagină al sistemului de operare, modul cel mai productiv, acesta și alegeți
Vdisk_fileio are un parametru important care afectează viteza - nv_cache = 1. este înregistrat rigid în SCSTLun.
Acest parametru indică SCST să ignore comenzile inițiatorului pentru a reseta cache-ul la dispozitiv. În mod potențial, acest lucru poate duce la pierderea datelor în caz de oprire de urgență a spațiului de stocare. inițiatorul va crede că datele se află pe disc și sunt încă în memorie. Deci, utilizați-vă pe propriul risc.
După aceasta, puteți vedea situația actuală:
Vedem că resursele sunt într-o stare inactivă, DRBD în modul Slave (secundar).
Acum puteți încerca să le activați:
Dacă totul este așa, atunci vă puteți felicita - clusterul este în funcțiune!
Fiecare grup de resurse este pornit pe serverul său, așa cum este specificat în configurația de directivă a locației.
Pentru confirmare, puteți vedea jurnalul de kernel - dmesg - unde DRBD și SCST afișează diagnosticele lor.
Sfârșitul celei de-a doua părți
În cea de-a treia și ultima parte, vă vom arăta cum să configurați serverul ESXi să funcționeze optim cu acest cluster.
1. Fiecare resursă normală are comanda Monitor API, pe care Pacemaker o folosește pentru a verifica starea resursei. Apelul său este activat de parametrii monitorului din resursă, puteți seta acțiunea la eroare. În mod implicit, clusterul repornește resursa, însă puteți pune modul de așteptare. care va determina migrarea tuturor resurselor de la nodul defect. Puteți specifica numărul de erori de repornire, după care va avea loc migrarea.
Înainte de a începe clusterul, am chinuit sistemul de foarte mult timp și stabilitatea părții software a fost mai mult decât satisfăcătoare pentru mine, deci nu am început să activez acest mod - dacă cineva are nevoie de el, atunci se face în două contează.
În general, Pacemaker are o mulțime de oportunități - cei interesați pot să se uite în documentație, nu este vorba despre unul sau chiar mai multe articole.
Ceea ce este "verificați pe shatdowne" nu a înțeles. Da, și drbd trăiește în kernel, nu-l puteți omorî -9.
2. Ce fel de teste, de exemplu? Rețeaua a fost scoasă, puterea unuia dintre noduri a fost tăiată, întrerupătorul a fost tăiat. Totul a funcționat așa cum ar trebui.
Și totuși, ca practic întregul software-ul de operare stocate în nucleu (SCST, DHD), eșecul său va duce la un colaps de bază (în special dacă includ panic_on_oops suplimentare) nod și, de fapt, să fie mort, care detectează al doilea nod.
Transferul IP-shnika pentru ESXi rulează fără probleme, timpul de expirare Corosync este de 4 secunde în mod prestabilit, timpul de expirare iSCSI în ESXi este de 10 secunde.
Deci totul merge foarte repede și aproape fără îndoială pentru VM.
1. Hmm. On-fail = standby? Când am încercat - a funcționat complet greșit. Nu-mi amintesc adevărul despre ce sa întâmplat. Și pentru a anticipa greutățile, adică pentru a planifica activitatea clusterului cu ajutorul unor greutăți - într-adevăr nu funcționează. Ca urmare a greutății, am început să schimbăm regula care analiza parametrul pentru ocf de resurse de casă.
Verificarea închiderii - în acest context, este atunci când verificarea resursei de cluster nu este produs în mod direct, și se crede că resursa este întotdeauna disponibilă - atât timp cât nodul este în viață. Noda a murit - atunci resursa nu este disponibilă.
2. Priviți, ipotetic, că renunțați la DRBD pe unul dintre noduri.
În primul rând, este posibil ca întregul stimulator cardiac al nodului să nu intre în repornirea panicii de kernel imediat.
În al doilea rând, chiar dacă este așa - este faptul că o mașină virtuală încărcată puternic timp de 4 secunde va atârna așteptând accesul la disc?
DRBD a adăugat la miezul de bază? Ei bine, ar trebui. Se răcește.
3. Au existat defecțiuni în timpul utilizării unei astfel de scheme în producție, când unul dintre noduri a căzut pentru un motiv sau altul? Schimbarea clusterului a funcționat în mod normal și nu au existat probleme la mașinile virtuale din ESXi?
Îmi voi explica întrebarea - astfel de scheme sunt capabile să trăiască ani de zile până când, la un moment dat, se pare că nu funcționează.
1. În momentul în care funcționează așa cum este scris în documentație - dacă o resursă cade, atunci toate resursele sunt mutate într-un nod de rezervă.
În general, nu ofer un serviciu - fac o stocare extrem de accesibilă pentru clusterul vSphere, nimic mai mult.
Înțeleg că puteți face multe lucruri și adăugați câteva nivele la accesibilitate, dar am și de ajuns că există :)
O dispoziție a serviciului, și toți ceilalți parametri (de discuri, tablouri, DHD, rețele etc.), am monitorizat separat de Zabbix-ohmi și dacă ceva nu este furnizat de cluster de configurare, atunci voi răspunde la foarte.
În ceea ce privește STONITH, m-am gândit (pe baza IPMI), dar am decis că este redundant.
Și cel de-al treilea nod martor, da, are sens, numai aici în Pacemaker nu există nici o modalitate ușoară de a adăuga doar un nod martor.
Puteți face al treilea nod standby = pornit, dar trebuie să aibă toate aceleași resurse (DRBD cel puțin), deoarece Clusterul va încerca să le monitorizeze. Cea de-a doua cale nu este de a porni Pacemaker-ul deloc, dar lăsați doar Corosync, dar nu sunt sigur că aceasta este o idee bună, trebuie să verificați. Dar, cel mai probabil, această metodă este cea mai optimă.
2. Ce înseamnă - cade? Gluck în software-ul? Apoi, kernelul va intra în rezeta imediat, este configurat în sysctl (kernel.panic)
În al doilea rând, chiar dacă este așa - este faptul că o mașină virtuală încărcată puternic timp de 4 secunde va atârna așteptând accesul la disc?
Și care este problema? În toate OS-urile obișnuite, timpul de expirare a I / O pe disc este mult mai mare (și în Linux, în Windows) și poate fi întotdeauna codificat dacă este necesar.
Am făcut în mod specific o mașină virtuală care a scris tot drumul pe disc și a ucis nodul activ pe sursa de alimentare - nu a existat nici un jurământ din partea OS oaspete, totul a continuat să funcționeze așa cum ar fi trebuit.
DRBD a adăugat la miezul de bază? Ei bine, ar trebui. Se răcește.
Da, au făcut-o, dar asta nu schimbă nimic.
Modulul este integrat sau integrat în miez - nu există nici o diferență în ceea ce privește munca.
Eu, aparent, o colectez cu un modul. versiunea mai veche este în kernel.
3. Au existat defecțiuni în timpul utilizării unei astfel de scheme în producție, când unul dintre noduri a căzut pentru un motiv sau altul?
Schimbarea clusterului a funcționat în mod normal și nu au existat probleme la mașinile virtuale din ESXi?
Nu, pah pah, funcționează atât de clar. Dar înainte de producție, așa cum am scris mai sus, m-am prefăcut că sunt orice fel de simulator și l-am condus în mod previzibil.
Îmi voi explica întrebarea - astfel de scheme sunt capabile să trăiască ani de zile până când, într-un anumit moment, se dovedește că nu funcționează.
Sunt de acord că în configurația mea nu este furnizat totul, dar pentru cerințele mele în mod specific acest lucru este mai mult decât suficient.
Și am încercat să verific comportamentul grupului în toate situațiile mai mult sau mai puțin reale.
Am pus în aplicare în mod diferit, au FreeBSD + ZFS + crap și două servere identice, totul funcționează ca sclav maestru, atunci când comandantul groapa se ridica sclavi, Slay ia să stăpânească snepshoty și role de stocare în prezent snepshotov copac, cu numirea comandantului de sclavi, se oprește rola snepshotov , și pot fi rulate în ordine inversă.
ZFS Eu iubesc cu toată inima mea (instantanee în special clone și checksum) acasă yuzayu lui, dar în performanță este de până la raidurile obișnuite cade scurt, a plutit, știm. Și dacă opriți toate chiflele care reduc performanța, atunci se dovedește a fi nu mai bună decât metodele tradiționale - nu există miracole.
pe un controler de 6 GB se simte minunat.
Ați putea să vă testați soluția (înregistrare, citire, intrare aleatorie)
pe un controler de 6 GB se simte minunat.
Ați putea să vă testați soluția (înregistrare, citire, intrare aleatorie)
La ceea ce aici controlerul nu este absolut clar, în special în ceea ce privește ZFS, la care controlorul este, în general, contra-indicativ.
Nu am testele ZFS la îndemână, pot să conduc gratuit în timp ce stochez cu RAID10 matrice pe LSI 9271, dar nu există surprize, cred, nu va fi.
În consecință, mulți ZFS și utilizatori RAID Linux MD, cum ar fi mine, uita-te pentru controlere non-RAID, care sunt pur și simplu, de încredere, rapid, ieftin, și de altfel vin fără clopote și fluiere. Cele mai multe plăci de bază au până la 4 sau 6 porturi la bord (pentru a vă asigura că permiteți întotdeauna modul AHCI în BIOS)
(c) blog.zorinaq.com/?e=10
Oferiți cel puțin un test comparativ sintetic, nu dd. Și să introducem câteva milioane de linii. Dacă sunteți interesat, vă pot aduce datele. Am început să fie minuscule, așa amuzant. Critica și opinia dvs. nu mai sunt binevenite?
Pot testa prin fio, dar care este scopul? Pentru a compara citirile, trebuie să aveți sisteme identice din punct de vedere al fierului, astfel încât această comparație să fie corectă. Pot testa backend-ul SCST_NULLIO fără a ține seama de subsistemul disc, dar nu este clar ce măsuram.
unde am spus că folosesc un raid? controlerul meu nu funcționează în modul raid, ci doar îmi dă viteza necesară. Și așa este inclus așa cum este indicat într-unul dintre legăturile dvs. Poate că pur și simplu nu știi cum să gătești raidz? Din câte știu, unul din cdn-urile rusești este folosit în același mod ca și mine și poate rezista unor sarcini grave.
Ce măsurare da operațiuni pe secundă este ce altceva.
I-am spus să vă aducă numerele de teste ale sistemului lor, de exemplu, conectați luna și pentru a extinde baza, de exemplu, am testat lansat la Diasoft de bază, de lângă Loong încărcate postat backup-uri incrementale ale postgres,
unde am spus că folosesc un raid? controlerul meu nu funcționează în modul raid, ci doar îmi dă viteza corectă
Care este diferența dintre un controler care "dă viteza necesară" și doar o conexiune directă a discurilor la controlerul de pe placa de bază sau în altă parte?
Poate că pur și simplu nu știi cum să gătești raidz?
Poate că nu pot, există un fel de magie secretă, împărtășesc-o?
Ce măsurare da operațiuni pe secundă este ce altceva.
Unde? Câte discuri? La 2, 5, 7, 10, 30 La ce nivel de RAID? Sau poate pe un SSD? Care este relația înregistrării / citirii?
Este cu adevarat de neinteles ca exista multi factori care influenteaza rezultatul? Am mai multe stocări diferite, cu sisteme de disc diferite și cu tehnologii de conectare diferite (iSCSI 1Gb / 10Gb, FC), iar rezultatele pentru toți sunt foarte diferite.
raidz este compilat din 16 discuri pe un disc 2TB + 1 pentru spere + cache pe două ssd. Fără un controler suplimentar nu se poate face și plus setări suplimentare. Așa pregătesc zf-urile pentru producție.
Măsurați exact pe piscina de ioan. Am vorbit despre canal, aparent nu am citit cu grijă porturile gigabit colectate în lacp.
Astfel, am rezervat încă canalul. Dacă folosiți zfs în linux, atunci nu mai aveți întrebări.
Articole similare
Trimiteți-le prietenilor: