Când vine vorba de soluții industriale, este necesar să se aleagă soluția cea mai simplă, cea mai ușor de înțeles și monolitică ... care este testată în timp. Nu există loc pentru tehnologiile experimentale.
Și, ceea ce este deosebit de important, factorul uman nu joacă întotdeauna un rol mic. sistemul trebuie să fie setat și să-i învețe pe oameni să îl folosească corect (în cazul nostru, administratori). Și aici este foarte important să existe o interfață normală pentru gestionarea acestor probleme, deoarece mulți lucrează cu linia de comandă "goală" pur și simplu refuză sau nu poate. De asemenea, foarte importante sunt multe funcții încorporate, cum ar fi: absența unui nod centralizat (starea cvorumului), gruparea de servere și toate cipurile aferente.
În cazul meu, vor fi folosite mai ales containerele OpenVZ. dar de obicei, virtualele KVM sunt mai solicitate decât containerele (vom încerca pentru ele în cursul articolului). Dar și despre containere aș vrea să spun un cuvânt ... Mi-ar plăcea să folosesc LXC. în loc de OpenVZ (care este, de fapt - tatăl), dar pentru LXC este încă nici o interfață web distincte (Fork LXC Panel Web de pe GitHub I-ar da statut - experimental), precum și despre gruparea și nu vorbesc ... și când trebuie să automatizăm întregul centru de date, cum să fim fără el? Care este diferența dintre OpenVZ și LXC? Hmm, da, în general, este același lucru, dacă nu intrați în cod. De fapt, singura diferență este că OpenVZ folosește kernel-ul lui cârpit 2.6 (inclus cu toate patch-urile de securitate, KVM proaspete și lemn) și este inclus în apstrip LXC, și anume în nucleul de vanilie din 3.8. Și ca în timp, este evident că va fi și mai puternic și va "stoarce" OpenVZ. Dar, în acest moment, ca parte a OpenVZ Proxmox se pare mai multă soluție gata și completă (dezvoltatorii Proxmox promit o OpenVZ versiune viitoare pentru a înlocui LXC. Atunci când acestea sunt echivalente în funcționalitate).
Apropo ... e uimitor, dar despre Proxmox în runet, aproape că nu am găsit nicio documentație în limba rusă. Toate doar în Burujuysky off.dokah și forumuri. Deci, acest manual ar trebui să fie foarte util pentru public :)
Bine, suficientă demagogie. a mers pentru a instala și configura distroul nostru pe noduri!
Exerciții practice. grupurile diferite trebuie să fie în subrețele diferite, astfel încât să nu interfereze unul cu celălalt (de exemplu: un cluster în 1.1.1.X, al doilea în 1.1.2.X, masca și gateway-ul sunt aceleași peste tot).
După actualizare, verificați data și ora pentru a respecta starea actuală a afacerilor.
Dacă timpul nu se potrivește, corectați-l (opțional):
în cazul în care:
MM - luna
DD - zi
hh - oră
mm - minute
AAAA - an
ss - secunde
După aceea, configurația nodului este considerată completă. Configurați toate celelalte noduri și apoi îmbinați-le într-un cluster.
În primul rând, trebuie să creați un cluster pe primul nod. Acest lucru se face o dată.
3.1) Crearea unui cluster
Aici puteți specifica numele clusterului (în viitor nu poate fi schimbat):
Verificați starea clusterului:
Asta e tot! Apoi trebuie doar să adăugați nodurile deja configurate.
3.2) Adăugarea nodurilor la cluster
Pentru a adăuga noduri la cluster, executați comanda (trebuie să executați comenzile pe cel mai adăugat nod):
Când adăugați, vi se va cere să acceptați cheia RSA (va trebui să introduceți "da" când vi se solicită) și introduceți parola din rădăcina nodului cu care ne conectăm.
Verificați starea clusterului:
Exerciții practice. toate nodurile de cluster sunt cele mai bune pentru toate serverele de cluster din / etc / hosts pentru fiabilitate.
3.3) Ștergerea unui nod dintr-un cluster
Acest articol necesită o atenție specială, dacă există un nonsens - puteți rupe întregul cluster. Deci, mai întâi trebuie să eliminați toate VM-urile din nodul șters (mutați-le pe alt server sau ștergeți-le complet). După aceea, trebuie să dezactivați acest nod și să îl deconectați fizic de la rețea (important: asigurați-vă că în starea sa actuală acesta nu va mai apărea din nou în rețea!)
Verificați numărul de noduri:
Ce va elimina nodul din cluster. Totul, mai mult dop. nu este necesară nicio acțiune.
Verificați din nou numărul de noduri:
Dacă apoi trebuie să returnați acest nod în cluster, atunci trebuie să reinstalați complet Proxmox + pe el și să îi dați un nou nume și un nou IP = introduceți-l în cluster ca unul nou (a se vedea punctul 3.2).
Nodurile sunt configurate și gata, integrate într-un cluster .... Este timpul să conectați bolta. Aici vom lua un exemplu tipic despre modul în care conectăm stocarea la servere direct prin Fibre Channel. Configurația de bază, desigur, se întâmplă cu depozitul propriu-zis. În cazul nostru, acesta va fi IBM șasiu C4A (pe 24 de discuri IBM SAS, dintre care 22 sunt integrate în RAID6). Trebuie să fie configurat "ca de obicei" (acesta este un subiect pentru un articol separat). După conectarea la nodurile deja pregătite. O caracteristică de lucru cu un depozit conectat prin LVM. pe acesta este posibil să se plaseze numai discuri de KVM virtuale (și numai într-un format brut), dar în orice fel fișiere de containere OpenVZ.
Răspunsul ar trebui să fie ceva de genul:
În condiții cu un raid nativ, ar trebui să existe doar un disc sda1,2,3 ... Rebootăm serverele noastre unul câte unul. Când un nou dispozitiv sdb apare pe toate serverele. puteți începe diagnosticarea. sau imediat pentru a conecta spațiul de stocare. Memoria externă conectată prin LVM poate utiliza numai formatul discului brut pentru VM.
4.1) Diagnostic (opțional)
Vom descrie cum merită să diagnosticăm că depozitul este "cuplat" și sistemul îl vede. Această acțiune nu este obligatorie, iar în cazul execuției, este suficient să o faceți doar pe un singur nod.
Răspunsul ar trebui să fie ceva de genul:
După repornire, ar trebui să existe acest dispozitiv SDD foarte. Acesta este depozitul nostru. Vrei să vezi asta pentru 100%? Bine, hai să mergem!
Verificați dacă sistemul vede controlerul Fibre Channel și lemnul de foc este pe el.
Răspunsul ar trebui să fie ceva de genul:
Acest lucru este bun. Apoi, vom instala instrumentele de care avem nevoie pentru a diagnostica:
Scanați pentru a găsi dispozitive noi:
Răspunsul ar trebui să fie ceva de genul:
Și acum suntem convinși că magazinul nostru este exact litera SDB:
Răspunsul ar trebui să fie ceva de genul:
Verificăm din nou și ne asigurăm că totul este în vigoare.
Aceasta completează diagnosticul. Puteți începe să creați LVM și conectați-l la Proxmox VE.
4.2) Crearea LVM
LVM este o tehnologie specială de stocare în Linux, datorită căreia vom putea oferi o migrare live a mașinilor de la nod la nod. În general, funcționează ca VMware vMotion. Configurația sa este foarte simplă :) Toate punctele sunt efectuate o singură dată, când spațiul de stocare este inițial conectat la cluster.
Am desemnat volumul sdb ca dispozitiv LVM (o atenție deosebită pentru pericolul pierderii de date pe sdb. Ar trebui să înțelegi în mod clar ce faci ...):
Creați un grup pe dispozitivul sdb numit "ibm":
Asta e tot! Toate setările sunt sincronizate automat cu întregul cluster. Apoi, du-te la interfața web și "fixați" LVM-ul nostru.
Datacenter >>> Depozitare >>> Adăugați >> LVM în coloana "Volume Group" selectați ibm.
Asta e tot! Depozitul a fost adăugat și actualizat cu succes pe toate nodurile specificate.
Multipath - tehnologia de conectare a nodurilor rețelei de stocare folosind mai multe căi. În configurația noastră, 2 FC-uri sunt utilizate pe partea de server + 2 controler FC de pe partea de server de stocare + SAN-switch. În total, se pare că magazinul poate fi văzut pe 4 canale. Conectarea memoriei prin multipath oferă agregarea și redundanța canalelor, la nivelul central al sistemului. Acest lucru crește viteza și în caz de defecțiuni - neobservate pentru utilizatorul care utilizează suplimentar. canale. Că înțelegeți că tehnologia însăși face parte din kernel-ul Linux, iar în majoritatea cazurilor (pe hardware-ul normal), întreaga configurație este determinată automat. Deci, să instalați:
Efectuați un diagnostic, așa cum se arată în secțiunea 4.1. Puteți verifica id-ul fiecărui disc cu comanda:
În cazul nostru, configurația este definită automat. Imaginea generală pe care o avem este următoarea (când se conectează numai o unitate de stocare la comutatorul SAN):
sdb, sdc, sdd, sde - depozitul nostru și cele 4 canale.
Verificăm dacă multipathul este definit automat:
Informații suplimentare sunt afișate de comanda:
După cum vedem, spațiul de stocare este conectat prin 4 canale. Dar parametrul cheie aici este id: 360080e50003e2c4c000003b555000a25, și suplimentar: dm-2 (acesta este numele de stocare temporară). Deci, este montat în sistem, apoi este automat în orice caz prin id, iar numele de care avem nevoie pentru a crea LVM în secțiunea 4.2.
Pe acest nume creăm LVM:
Asta e tot! În plus, magazinul rămâne activat prin interfața web, așa cum se arată deja mai sus.
Aceasta este probabil cea mai dificilă parte. În mod implicit, VM se execută în modul clasic: plasat pe server, dar în cazul în care serverul devine indisponibil, toate VM sunt disponibile cu ea. În același mod HA, se întâmplă următoarele: în cazul unei defecțiuni a serverului, toate VM-urile se deplasează automat la alt server (e) al clusterului. HA este configurabil pur și simplu prin GUI web. Cu toate acestea, una dintre cerințele de muncă HA (în plus față de echipamente high-end și schimbul de depozitare) este disponibilitatea de hardware Scrimă, Dispozitiv pentru fiecare server (pentru a evita accesul simultan la date eronate VM de la mai multe servere, aceasta se numește «split-creier condiție» și poate duce la "coruperea datelor"). Acesta este ceea ce înseamnă înșelătorie. el joacă rolul de bouncers - fizic blochează accesul la serverul de date VM (închide porturile SAN deconectează de la rețea sau de la rețeaua de alimentare, sau doar reporniți serverul). Hardware Scrimă - este soluția cea mai eficientă și mai stabilă. Exemple de astfel de dispozitive sunt: râurile APC, întrerupătoarele SAN. și servicii privind similitudinea HP iLO. În cazul nostru, vom folosi utilitarul HP ILO. care este încorporat în serverul HP DL360 Gen9. Este ideal pentru acest rol. Conectați și configurați iLO pe server, atribuiți-i o parolă și configurați accesul. După aceea, continuăm:
6.1) Scrimă
Configurația are loc în întregime prin consolă și config. Fiți pregătit moral. În plus, fiecare echipament de protecție va avea propriile configurații specifice. În primul rând, trebuie să activați software-ul Fencing-domain și să îmbinați toate serverele de cluster în acesta (efectuați aceste operații pe toate serverele). Pentru aceasta, trebuie să dezarhivați linia (FENCE_JOIN = "da") în această configurație:
Verificați și adăugați serverul la domeniul de acoperire:
După aceea, serverul poate pierde sincronizarea cu clusterul. Acum este necesar să reporniți serviciul principal:
Apoi, instalați instrumentele necesare pentru a comunica cu HP iLO din sistemul de operare utilizând interfața IPMI:
Pornirea și repornirea serviciului:
Este evident că va jura ... pentru funcționarea IPMI este necesar să se activeze module suplimentare ale kernel-ului sistemului:
Să ne asigurăm că acestea sunt activate automat după repornirea sistemului de operare (corectați configurația și introduceți următoarele valori):
În primul caz, ar trebui să apară dispozitivul ipmidev, iar în al doilea caz, ieșirea va arăta astfel:
Verificarea Scrimă. Aceste comenzi fac aproximativ același lucru (1-2 verificați starea, 3 - trimiteți la reboot ... login și parola din iLO):
Pentru a nu arunca parola în config direct (inclusiv GUI-ul web), vom scrie cel mai simplu script:
Toate după ce aceste operații sunt efectuate pe toate serverele clusterului - ne mutăm la cel mai important și mai responsabil lucru ... pentru a edita configurația principală a clusterului. Trebuie să acționăm foarte atent și cu atenție. Amintiți-vă, după fiecare editare a configurării - este necesară acolo și creșteți versiunea cu 1 (parametrul config_version = ..). Creați o nouă configare temporară:
Iată clusterul de configurare a clusterului pe care l-am scris manual: cluster_test1_ilo4
Se pare ca aceasta:
Și acum verificăm activitatea dispozitivului de siguranță (de la orice server de cluster) și trimitem acest nod la reboot:
Asta e tot! Mai multe configurări de editare nu trebuie să fie, toate acțiunile ulterioare sunt efectuate prin GUI web.
Serviciul HA trebuie să fie activat pentru fiecare VM individual. Atenție: asigurați-vă că VM este oprit înainte de a porni HA.
Acesta este statutul VM fără HA:
Adăugați VM la HA:
Noul statut VM cu HA:
Asta e tot! Nu uitați să conectați VM noi la HA.
Dacă nu există un spațiu de stocare, serverele pot fi în continuare parte din cluster - numai astfel vor folosi doar subsistemul lor de disc. Avantajul lor este că astfel de servere pot fi folosite ca recipiente OpenVZ. și mașini virtuale KVM. Mașinile virtuale pot fi în mai multe formate. Caracteristicile formatelor de disc:
- cea mai bună performanță
- rezervă un loc complet pentru playerul virtual (disc fix)
- capacitatea de a face instantaneu (inclusiv "live")
- rezervă un loc pentru virtualul NOT complet (disc dinamic)
- compatibilitate completă cu VMware
- rezervă un loc pentru virtualul NOT complet (disc dinamic)
Fișierele cu containere OpenVZ sunt stocate în singurul nod aici: / var / lib / vz / private / ID (unde id este ID-ul coneinerului din interfața web)
Pe scurt. containerele sunt recomandate pentru a fi utilizate atunci când vine vorba de un nod fără stocarea conectată la acesta și sistemul linux oaspete. Resurse enorme de economisire + extensie de disc / memorie "în zbor".
Pentru a intra în container, trebuie să executați o comandă de la nod (unde 109 este ID-ul mașinii virtuale):
Toate, apoi personalizați sistemul de operare așa cum aveți nevoie, instalați tot software-ul (toate ca de obicei pe virtual). Când configurați complet containerul, să facem un șablon din el ... apoi din acest șablon puteți construi chiar și o grămadă de recipiente. Înainte de a continua, faceți clic pe Shutdown în interfața web și stingeți complet recipientul de care aveți nevoie. Apoi, prin interfața web, ștergeți complet interfața de rețea a containerului:
Punctul de la capătul liniei este important, nu-l atinge!
Totul, noul șablon pentru containere este gata de lucru. Apare în interfața web a Proxmox.
În procesul de exploatare, nu ar trebui să existe întrebări, totul este foarte logic și intuitiv. Când vă conectați la sistem, puteți include chiar rusă în interfață. Sistemul acceptă migrarea live și backup-urile live, astfel încât mașinile virtuale să poată fi mutate în mod liber între noduri în stare de funcționare + să facă backup-urile lor. Puteți încărca distribuțiile de sistem în spațiul de stocare .iso la magazinele de noduri locale - ceea ce face mai convenabil crearea de noi mașini virtuale.
Bucurați-vă!)
Articole similare
Trimiteți-le prietenilor: