De câte ori am fost nevoiți să avem serviciile noastre sau, mai degrabă, să ne păstrăm serviciile întotdeauna disponibile și de câte ori ni s-a întâmplat să ne deteriorăm hard diskul serverului și să nu avem backup, bine, gândindu-ne la acestea circumstanțe, am decis să creez acest lucru tutorial pentru a ne asigura că serverele noastre sau mai bine zis serviciile noastre sunt întotdeauna online.
Ținând cont de faptul că tutorialul este conceput pentru oameni avansați în Linux, nu voi atinge subiecte precum instalarea sistemului de bază pe care îl voi folosi de această dată CentOS 6 pe 64 de biți în ultima sa actualizare. La fel, voi menționa doar ceea ce este strict necesar pentru funcționarea clusterului (servere de înaltă disponibilitate).
De asemenea, fac comentariul că acest ghid este îndreptat către necesitatea de a menține serviciul web mereu activ, deși l-am folosit cu alte servicii cu succes, cred că, ca început sau mai bine spus, ca început, cel mai simplu lucru este să creați un cluster web server.
Fără alte întrebări, să trecem la lucrurile bune.
Cerințe de sistem.1. Memorie RAM 1 GB
2. Hard disk 80 GB
3. Procesor Celeron
4. Partiție de date pentru cluster (indiferent de dimensiunea pe care doriți să o creați)
5. Sistem de operare CentOS 6 (în ultima sa actualizare)
Dacă îndepliniți cerințele, să începem Instalare cluster Linux.
Următorul lucru este să instalați DRBD pentru sincronizarea partițiilor pe ambele servere, pentru aceasta este necesar rulați în shell următoarele instrucțiuni:
1. Adăugați ELRepo la lista de depozite de sistem
[root @ node1 ~] rpm -ivh http://elrepo.org/elrepo-release-6-5.el6.elrepo.noarch.rpm
2. Instalați utilitarele drbd (Distributed Replicated Block Device) și pachetele kmod
[root @ node1 ~] yum install -y kmod-drbd83 drbd83-utils(Personal, folosesc 8.3 deoarece 8.4 mi-a dat probleme cu unele distribuții)
3. Drbd este adăugat sau introdus în nucleul sistemului
[root @ node1 ~] modprobe drbd
4. Trebuie creat fișierul de resurse pentru drbd
Se află la /etc/drbd.d/mydrbd.res; unde mydrbd.res este numele fișierului și acesta poate fi modificat de oricine dorim, atâta timp cât păstrăm extensia .res; Acest fișier trebuie creat pe ambele servere sau, atunci când fișierul este configurat corect, este copiat în al doilea nod; configurația ar fi mai mult sau mai puțin următoarea:
resource mydrbd {# acesta este numele resursei protocolului C; pornire {wfc-timeout 180; degr-wfc-timeout 120;} # 180 secunde de așteptare a dispozitivului slave, 120 secunde, dacă nu răspunde, este degradat și rămâne ca disc secundar {on-io-error detach; } net {cram-hmac-alg "sha1"; shared-secret "cheie secretă";} # În această parte este specificată o cheie cu criptare sha1, această cheie este pentru comunicarea între cele două noduri. sincronizator {rate 100M;} #synchronization speed, nu contează că avem o placă de rețea Gigabit, nu funcționează la 1000M, viteza maximă recomandată este de 100M (l-am instalat cu 10M și funcționează excelent, puțin lent prima sincronizare dar apoi nu vezi diferența) pe nodul1 {device / dev / drbd0; # aici specificăm care este dispozitivul rezervat pentru drbd, putem avea mai multe dispozitive pentru date diferite sau servicii diferite, precum SAMBA, MySQL, printre altele disk / dev / md2; #specificați partiția care va fi utilizată pentru adresa drbd 172.16.0.1:7788; # Specificăm un IP în afara gamei rețelei noastre, merită menționat faptul că cablul de rețea trebuie să fie conectat direct între servere, fără a trece printr-un comutator sau hub, dacă sunt modele recente de rețea, nu este necesar un cablu crossover. meta-disc intern; } pe nod2 {# specificațiile celui de-al doilea trebuie să fie aceleași cu cele ale primului, doar adresa IP se schimbă, trebuie să fie același port, asta pentru că dacă avem 2 clustere împreună, acestea vor intra în conflict și nu vor funcționa în mod adecvat, dacă dorim să avem mai multe clustere, este recomandat să folosim porturi diferite, este de la sine înțeles că aceste porturi trebuie să fie aceleași pe ambele noduri. dispozitiv / dev / drbd0; disc / dev / md2; adresa 172.16.0.2:7788; meta-disc intern; }}
MARI
5. Următoarea este configurația fișierului gazdăAceasta este astfel încât serverele să fie căutate prin IP-ul de sincronizare și nu prin IP-ul rețelei locale și astfel evităm conflictele cu serviciile:
/ etc / hosts 192.168.1.1 node1 #name of node1 on local network segment 192.168.1.2 node2 #name of node2 on local network segment 172.16.0.1 node1 #name of node1 on synchronization network segment 172.16.0.2 node2 #name from node2 in sync segment de rețea
6. Unitatea de stocare pentru drbd este inițializată
[root @ node1 ~] drbdadm create-md disk1
7. Începe serviciul drbd sau deamon
/etc/init.d/drbd start
8. În nodul pe care dorim să îl primim, executăm următoarea comandă
drbdadm - -overwrite-data-of-peer disk primar1
9. Monitorizăm sincronizarea ambelor noduri
Pentru aceasta executăm:
cat / proc / drbdRăspunsul din comanda de mai sus este ceva de genul următor:
versiune: 8.3.15 (api: 88 / proto: 86-97) GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c build de phil @ Build32R6, 2012-12-20 20:23:49 1: cs: SyncSource ro: ds primar / secundar: UpToDate / Inconsistent C rn- ns: 1060156 nr: 0 dw: 33260 dr: 1034352 al: 14 bm: 62 lo: 9 pe: 78 ua: 64 ap: 0 ep: 1 wo: f oos: 31424 [===== =============>.] sincronizat: 97,3% (31424/1048508) K finisare: 0:00:01 viteză: 21.240 (15.644) K / sec # Aici putem vedea că Sincronizarea merge la 97,3% și se specifică că acesta este nodul primar și nodul secundar apare ca inconsistent, deoarece sincronizarea nu a terminat încă. # Odată terminat, rulăm din nou cat / proc / drbd și avem următoarele: versiunea: 8.3.15 (api: 88 / proto: 86-97) GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c build de phil @ Build32R6, 2012-12-20 20: 23: 49 1: cs: Ro conectat: Primar / Secundar ds: UpToDate / UpToDate C r- ns: 1081628 nr: 0 dw: 33260 dr: 1048752 al: 14 bm: 64 lo: 0 pe: 0 ua: 0 ap: 0 ep: 1 wo: f oos: 0 # Prin returnarea mesajului UpToDate, suntem conștienți că sincronizarea este completă și partițiile drbd sunt exact aceleași.
10. Următorul lucru este să formatați dispozitivul nostru drbdPentru aceasta executăm:
mkfs.ext3 / dev / drbd1Folosesc ext3 pentru că mi-a oferit o stabilitate bună, dar am putea folosi și ext4, nu recomand utilizarea vreunui tip de partiție sub ext3.
Până acum suntem deja capabili să montăm manual partiția / dev / drbd1 în orice punct de montare al sistemului, în cazul meu folosesc / home pentru montare, deoarece fiecare dintre utilizatorii înregistrați în ambele noduri are propriile directoare pentru paginile web, prin urmare Alerg:
montare -t ext3 / dev / drbd1 / homeȘi încep să creez utilizatorii pentru replicarea datelor pe ambele servere, următorul este instalarea bătăilor inimii, aplicație utilizată pentru a monitoriza serverele între ei și care va fi însărcinată cu efectuarea modificărilor pertinente în cazul în care principalul se încadrează din orice motiv și transformă secundarul în primar pentru a asigura funcționalitatea sistemului.
Pentru instalarea bătăilor inimii ar trebui urmați doar pașii următori. Depozitul este instalat pentru descărcare cu următoarea comandă:
rpm -ivh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpmEditați fișierul:
epel.repo /etc/yum.repos.d/epel.reposchimbați linia # 6 ‘Enable = 1 by enable = 0’; puteți utiliza editorii vi sau nano, după cum doriți.
[epel] name = Pachete suplimentare pentru Enterprise Linux 6 - $ basearch # baseurl = http: //download.fedoraproject.org/pub/epel/6/$basearch mirrorlist = http: //mirrors.fedoraproject.org/metalink? repo = epel-6 & arch = $ basearch failovermethod = prioritate activată = 0 # Aceasta este linia pe care trebuie să o edităm Instalați bătăile inimii cu următoarea comandă: yum -enablerepo = epel instalați bătăile inimii Odată ce instalarea este terminată, ne va spune ceva similar la: Instalat: heartbeat .i686 0: 3.0.4-1.el6 Finalizat!Odată ce procesul de instalare este terminat, următorul lucru de făcut este să editați cele 3 fișiere esențiale pentru ca bătăile inimii să funcționeze; aflat în /etc/ha.d
- autorizări
- ha.cf
- resurse de iepuri
Deschidem fișierul autorizări cu următoarea comandă:
vi /etc/ha.d/authkeysSe adaugă următoarele rânduri:
tasta auth 1 1 sha1 pentru conexiunea între bătăile inimii # În această linie definim care va fi cheia pentru bătăile inimii fiecărui nod pentru a comunica între ele, poate fi aceeași cu cea utilizată în drbd sau diferită.Modificăm permisiunile de fișiere autorizări astfel încât să poată fi citit doar prin root:
chmod 600 /etc/ha.d/authkeysAcum edităm al doilea fișier:
vi /etc/ha.d/ha.cfAdăugăm următoarele rânduri:
logfile / var / log / ha-log # jurnalul sistemului este activat pentru viitoarele erres logfacility local0 keepalive 2 deadtime 30 # sistemul așteaptă 30 de secunde pentru a declara nodul1 ca inițial inoperabil 120 # sistemul așteaptă 120 de secunde pentru pornirea nodului să aștepte celălalt . bcast eth0 # este specificată placa Ethernet prin care se va transmite comunicația între servere, este foarte important să acordăm atenție deoarece aici definim ce placă de rețea merge la rețeaua locală și care să direcționeze sincronizarea udpport 694 # se specifică portul de sincronizare , ca și în drbd, putem avea mai multe servere și fiecare pereche cu portul respectiv definit auto_failback off # marcând-o ca oprită prevenim ca nodul 1 odată deteriorat și degradat să revină ca primar sau încercând să se întoarcă, făcând astfel conflict cu un alt nod nod nod 1 nod 2 # specificăm numele ambelor noduri.
MARI
Pentru a finaliza configurația, trebuie să edităm fișierul haresources cu comanda:
vi /etc/ha.d/haresourcesAdăugați următoarele rânduri:
node1 192.168.1.10/24/eth0 drbddisk :: mydrbd Filesystem :: / dev / drbd0 :: / home :: ext3 #această linie este responsabilă pentru montarea partiției de date pe nodul la care se face referire ca nod principal1 192.168.1.10/24/ eth0 httpd #această linie este responsabilă pentru definirea serviciului apache sau a serverului web către nodul la care se face referire ca primar
MARI
Cele 3 fișiere trebuie copiate în nodul2, următoarea comandă se va ocupa de acesta:
scp -r /etc/ha.d/root@node2:/etc/Fișierul trebuie editat httpd.conf astfel încât să asculte cererile de la ip-ul virtual, în acest caz 192.168.1.10:
vi /etc/httpd/conf/httpd.confLinia este adăugată sau modificată Ascultă 192.168.1.10:80
Fișierul modificat este copiat pe al doilea server:
scp /etc/httpd/conf/httpd.conf root @ node2: / etc / httpd / conf /Începem serviciul bătăilor inimii pe ambele noduri:
/etc/init.d/heartbeat startCu aceasta, avem pregătit serverul nostru de înaltă disponibilitate, este doar o chestiune de a intra în browserul nostru de internet și de a pune ip 192.168.1.10 sau de a instala un panou la alegere pentru administrarea domeniului și de a genera utilizatorii corespunzători pentru a accesa paginile sau domeniile înregistrate în server.
Serverul cu disponibilitate ridicată poate fi utilizat așa cum sa menționat deja la începutul acestui tutorial ca: server de e-mail, server web, server de baze de date, server samba printre alții; De asemenea, ne ajută să prevenim pierderea informațiilor din cauza defecțiunilor hardware și o putem întări mai mult cu raiduri pe unitățile de disc, fie prin hardware sau software, niciodată nu este prea mult să aveți discuri în raid pentru a întreține sistemul.
Cu toate acestea, serverul cu disponibilitate ridicată nu este scutit de probleme sau erori, atunci când un nod este degradat, putem merge la jurnalul bătăilor inimii pentru a vedea ce s-a întâmplat, acest lucru se realizează accesând fișierul atribuit în configurația de resurse în /etc/ha.d
În același mod, se poate întâmpla ca atunci când reporniți ambele servere, din anumite motive, să nu înceapă ca primar / secundar și să înceapă ca primar / necunoscut și necunoscut / secundar.
MARI
Pentru a rezolva acest lucru, trebuie să urmăm pașii următori.
În cochilia nodului căzut, tastăm:
resursă secundară drbdadmUlterior:
drbdadm deconectează resursaȘi apoi:
drbdadm - --discard-my-data connect resourceÎn cele din urmă, în nodul supraviețuitor sau primar, tastăm:
drbdadm connect resourceAcum va începe resincronizarea nodurilor de la nodul supraviețuitor la nodul căzut, aceasta începând imediat la apăsarea tastei "Introduce" în instrucțiunea 4.
Ceea ce s-a întâmplat aici este cunoscut sub numele de Creier impartit, acest lucru se întâmplă atunci când, dintr-un anumit motiv, nodul primar eșuează și este degradat, odată ce acest lucru se întâmplă, este foarte recomandat să revizuiți și să analizați în profunzime nodul căzut și înainte de a-l re-încorpora în cluster pentru a rezolva orice problemă existentă, ar putea fi, de asemenea, necesar pentru a reinstala întregul sistem de operare al acestui nod și, fără nicio problemă, încorporați-l în cluster ca secundar pentru sincronizare și, dacă ar fi cazul, odată sincronizat, schimbați-l în primar.
În cele din urmă, aș dori să subliniez revizuirea regulată a stării de sănătate a clusterelorȘtim bine că, pentru performanțe ridicate, este întotdeauna bine să fii cu un pas înaintea dezastrelor de computer; Întrucât, în calitate de personal IT, responsabilitatea de a avea grijă de datele companiei sau companiilor cărora le aparțin ne revine, ca o notă suplimentară, cred că merită să recomandăm să avem întotdeauna o copie de rezervă într-o unitate alternativă la noduri și asigurați astfel securitatea informațiilor garantată.
Instalați și configurați serverul Ubuntu
V-a plăcut și ați ajutat acest tutorial?Puteți recompensa autorul apăsând acest buton pentru a-i oferi un punct pozitiv
