Installer Linux -server i klynge med høj tilgængelighed

Hvor mange gange har vi krævet at have vores tjenester, eller rettere sagt, at vores tjenester altid er tilgængelige, og hvor mange gange er det sket for os, at harddisken på vores server er beskadiget, og vi ikke har backup, godt, tænker på dem omstændigheder, har jeg besluttet at oprette dette tutorial for at sikre, at vores servere eller rettere vores tjenester altid er online.

I betragtning af at selvstudiet er designet til avancerede mennesker i Linux, vil jeg ikke berøre emner som f.eks. Installation af basissystemet, som jeg vil bruge denne gang CentOS 6 64 bit i sin sidste opdatering. På samme måde vil jeg kun nævne, hvad der er strengt nødvendigt for driften af ​​klyngen (servere med høj tilgængelighed).

Jeg kommenterer også, at denne vejledning er rettet mod behovet for at holde webtjenesten altid aktiv, selvom jeg har brugt den med andre tjenester med succes, tror jeg, at som en start eller bedre sagt, som en start, er det enkleste at oprette en server klynge web.

Uden videre lad os gå videre til de gode ting.

Systemkrav.1. RAM -hukommelse 1 GB
2. Harddisk 80 GB
3. Celeron processor
4. Datapartition for klyngen (uanset hvilken størrelse du vil oprette)
5. CentOS 6 -operativsystem (i den seneste opdatering)

Hvis du opfylder kravene, lad os starte Linux klynge installation.

Den næste ting er at installere DRBD til synkronisering af partitionerne på begge servere, for dette er det nødvendigt kør in -shell følgende instruktioner:

1. Føj ELRepo til listen over systemlagre

 [root @ node1 ~] rpm -ivh http://elrepo.org/elrepo-release-6-5.el6.elrepo.noarch.rpm

2. Installer drbd (Distributed Replicated Block Device) -værktøjer og kmod -pakker

 [root @ node1 ~] yum installer -y kmod-drbd83 drbd83-utils

(Personligt bruger jeg 8.3, da 8.4 gav mig problemer med nogle distributioner)

3. Drbd tilføjes eller indsættes i systemkernen

 [root @ node1 ~] modprobe drbd

4. Ressourcefilen til drbd skal oprettes
Det er placeret på /etc/drbd.d/mydrbd.res; hvor mydrbd.res er navnet på filen, og dette kan ændres af alle, vi ønsker, så længe vi beholder filtypen .res; Denne fil skal oprettes på begge servere, eller når filen er konfigureret korrekt, kopieres den til den anden knude; konfigurationen ville være mere eller mindre følgende:

 ressource mydrbd {#dette er navnet på protokol C -ressource; opstart {wfc-timeout 180; degr-wfc-timeout 120;} # 180 sekunders ventetid på slaveenheden, 120 sekunder, hvis den ikke svarer, degraderes den og forbliver som sekundær disk {on-io-error detach; } net {cram-hmac-alg "sha1"; delt-hemmelig "hemmelig nøgle";} #I denne del er der angivet en nøgle med sha1-kryptering, denne nøgle er til kommunikation mellem de to noder. syncer {rate 100M;} #synkroniseringshastighed, det gør ikke noget, at vi har et Gigabit -netværkskort, det virker ikke ved 1000M, den maksimalt anbefalede hastighed er 100M (jeg har installeret det med 10M, og det fungerer godt, lidt langsomt den første synkronisering, men så ser du ikke forskellen) på node1 {device / dev / drbd0; # her angiver vi, hvilken enhed der er forbeholdt drbd, vi kan have flere enheder til forskellige data eller forskellige tjenester, såsom SAMBA, MySQL, blandt andet disk / dev / md2; #specificer den partition, der skal bruges til drbd -adresse 172.16.0.1:7788; # Vi angiver en IP uden for vores netværks rækkevidde, det er værd at nævne, at netværkskablet skal tilsluttes direkte mellem servere uden at gå gennem en switch eller hub, hvis det er nyere model netværkskort, er et crossover -kabel ikke nødvendigt. meta-disk intern; } på node2 {# specifikationerne for den anden skal være de samme som dem for den første, kun ip -adressen ændres, det skal være den samme port, det er fordi hvis vi har 2 klynger sammen, vil de komme i konflikt og vil ikke fungere passende, hvis vi vil have flere klynger, anbefales det at bruge forskellige porte, det siger sig selv, at disse porte skal være ens på begge noder. enhed / dev / drbd0; disk / dev / md2; adresse 172.16.0.2:7788; meta-disk intern; }}

FORSTØRRE

5. Det følgende er værtens filkonfigurationDette er, så serverne søges gennem synkroniserings -IP'en og ikke af IP'en på det lokale netværk, og dermed undgår vi konflikter med tjenesterne:

 / etc / hosts 192.168.1.1 nod1 netværkssegment

6. Lagerenheden til drbd'en initialiseres

 [root @ node1 ~] drbdadm create-md disk1

7. Drbd -tjenesten eller deamon starter

 /etc/init.d/drbd start

8. I den node, som vi vil være den primære, udfører vi følgende kommando

 drbdadm--overwrite-data-of-peer primær disk1

9. Vi overvåger synkroniseringen af ​​begge noder
Til dette udfører vi:

 kat / proc / drbd

Svaret fra ovenstående kommando er noget i retning af følgende:

 version: 8.3.15 (api: 88 / proto: 86-97) GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c build af phil @ Build32R6, 2012-12-20 20:23:49 1: cs: SyncSource ro: Primary / Secondary ds: UpToDate / Inkonsekvent 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 [===== =============>.] synkroniseret: 97,3% (31424/1048508) K finish: 0:00:01 hastighed: 21.240 (15.644) K / sek # Her kan vi se, at synkroniseringen går til 97,3%, og det er angivet, at dette er den primære knude og den sekundære knude fremstår som inkonsekvent, da synkroniseringen ikke er afsluttet endnu. #Når vi er færdige, kører vi cat / proc / drbd igen, og vi har følgende: version: 8.3.15 (api: 88 / proto: 86-97) GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c build af phil @ Build32R6, 2012-12-20 20: 23: 49 1: cs: Tilsluttet ro: Primær / Sekundær 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 # Ved at returnere UpToDate -meddelelsen er vi klar over, at synkroniseringen er fuldført, og drbd -partitionerne er nøjagtig de samme.

10. Den næste ting er at formatere vores enhed drbdTil det udfører vi:

 mkfs.ext3 / dev / drbd1

Jeg bruger ext3, fordi det har givet mig god stabilitet, men vi kunne også bruge ext4, jeg anbefaler ikke at bruge nogen form for partition under ext3.

Indtil videre er vi allerede i stand til manuelt at montere / dev / drbd1 -partitionen i et hvilket som helst monteringspunkt i systemet, i mit tilfælde bruger jeg / home til montering, da hver af brugerne, der er registreret i begge noder, har deres egne mapper til websider, derfor Jeg løber:

 mount -t ext3 / dev / drbd1 / home

Og jeg begynder at oprette brugerne til datareplikation på begge servere, følgende er installation af hjerteslag, applikation, der bruges til at overvåge serverne indbyrdes, og hvem der skal stå for at foretage de relevante ændringer, hvis den primære af en eller anden grund falder og gør den sekundære til primær for at sikre systemets funktionalitet.

For installation af hjerteslag kun følgende trin skal følges. Lageret installeres til download med følgende kommando:

 rpm -ivh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm

Rediger filen:

 epel.repo /etc/yum.repos.d/epel.repo 

ændre linje # 6 'Aktiver = 1 ved aktiver = 0'; du kan bruge vi- eller nano -redaktionen, som du vil.

 [epel] name = Ekstra pakker til 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 = prioritet aktiveret = 0 # Dette er den linje, vi skal redigere Installer hjerteslaget med følgende kommando: yum -enablerepo = epel install heartbeat Når installationen er færdig vil den fortælle os noget lignende til: Installeret: hjerteslag .i686 0: 3.0.4-1.el6 Komplet! 

Når installationsprocessen er færdig, er den næste ting at gøre at redigere de 3 vigtige filer for at hjerteslaget skal fungere; placeret i /etc/ha.d

• autoriserede nøgler
• ha.cf
• harekilder

Vi åbner filen autoriserede nøgler med følgende kommando:

 vi /etc/ha.d/authkeys

Følgende linjer tilføjes:

 auth 1 1 sha1 -nøgle til forbindelse mellem hjerteslag # I denne linje definerer vi, hvilken der vil være nøglen til hjerteslagene i hver node til at kommunikere med hinanden, det kan være det samme som det, der bruges i drbd eller anderledes.

Vi ændrer filtilladelserne autoriserede nøgler så det kun kan læses med root:

 chmod 600 /etc/ha.d/authkeys

Nu redigerer vi den anden fil:

 vi /etc/ha.d/ha.cf

Vi tilføjer følgende linjer:

 logfile / var / log / ha-log # systemlog er aktiveret til fremtidige fejl logfacility local0 keepalive 2 deadtime 30 # systemet venter 30 sekunder med at erklære node1 som ubrugelig initdead 120 # systemet venter 120 sekunder på at node starter til at vente på den anden . bcast eth0 # er specificeret Ethernet -kortet, hvorigennem kommunikationen mellem servere vil blive transmitteret, det er meget vigtigt at være opmærksom, da vi her definerer hvilket netværkskort, der går til det lokale netværk, og hvilket direkte synkronisering udpport 694 # synkroniseringsporten er angivet , som i drbd kan vi have flere servere og hvert par med sin respektive port defineret auto_failback off # ved at markere det som off, vi forhindrer node1, når den er beskadiget og nedbrudt, fra at vende tilbage som primær eller forsøge at vende tilbage og dermed skabe konflikt med en anden node node node1 node2 # vi angiver navnene på begge noder. 

FORSTØRRE

For at afslutte konfigurationen skal vi redigere haresources -filen med kommandoen:

 vi /etc/ha.d/haresources

Tilføj følgende linjer:

 node1 192.168.1.10/24/eth0 drbddisk :: mydrbd Filsystem ::/ dev/ drbd0 ::/ home :: ext3 #denne linje er ansvarlig for montering af datapartitionen på noden, der refereres til som primær node1 192.168.1.10/24/ eth0 httpd #denne linje er ansvarlig for at definere apache -tjenesten eller webserveren mod den node, der refereres til som primær

FORSTØRRE

De 3 filer skal kopieres til node2, følgende kommando tager sig af det:

 scp -r /etc/ha.d/root@node2:/etc/

Filen skal redigeres httpd.conf så den lytter efter anmodninger fra den virtuelle ip, i dette tilfælde 192.168.1.10:

 vi /etc/httpd/conf/httpd.conf

Linjen tilføjes eller ændres Lyt til 192.168.1.10:80
Den ændrede fil kopieres til den anden server:

 scp /etc/httpd/conf/httpd.conf root @ node2: /etc /httpd /conf /

Vi starter hjerteslagstjenesten på begge noder:

 /etc/init.d/heartbeat start

Med dette har vi vores server med høj tilgængelighed klar, det er kun et spørgsmål om at gå ind i vores internetbrowser og sætte ip 192.168.1.10 eller installere et panel efter eget valg til domæneadministration og generere de tilsvarende brugere til at få adgang til de sider eller domæner, der er registreret i serveren.

Serveren med høj tilgængelighed kan bruges som allerede nævnt i begyndelsen af ​​denne vejledning som: e -mailserver, webserver, databaseserver, samba server blandt andre; På samme måde hjælper det os med at forhindre tab af information på grund af hardwarefejl, og vi kan forstærke det mere med raid på diskenhederne, enten ved hardware eller software, det er aldrig for meget at have diske i raid for at vedligeholde systemet.

Serveren med høj tilgængelighed er dog ikke fritaget for problemer eller fejl, når en knude er nedbrudt, kan vi gå til hjerteslagsloggen for at se, hvad der skete, dette opnås ved at få adgang til den fil, der er tildelt i haresources -konfigurationen i /etc/ha.d

På samme måde kan det ske, at når du genstarter begge servere af en eller anden grund, starter de ikke som primær / sekundær og starter som primær / uvidende og uvidende / sekundær.

FORSTØRRE

For at løse dette skal vi følge følgende trin.

I skallen på den faldne knude skriver vi:

 drbdadm sekundær ressource

Efterfølgende:

 drbdadm frakobler ressource

Og så:

 drbdadm---discard-my-data connect-ressource

Endelig skriver vi i den overlevende node eller primær:

 drbdadm forbind ressource

Nu vil det starte resynkroniseringen af ​​knudepunkterne fra den overlevende knude til den faldne knude, dette starter med det samme, når der trykkes på tasten "Gå ind" i instruktion 4.

Hvad der skete her er kendt som en Split-hjerne, dette sker, når den primære node af en eller anden grund fejler og nedbrydes, når det sker, kan det stærkt anbefales at gennemgå og analysere den faldne node i dybden, og inden den igen integreres i klyngen for at løse ethvert eksisterende problem, kan det også være nødvendigt at geninstallere hele operativsystemet i denne node og uden problemer inkorporere det i klyngen som sekundær til synkronisering, og hvis det var tilfældet, skal du ændre det til primær, hvis det var synkroniseret.

Endelig vil jeg gerne understrege regelmæssig gennemgang af klyngesundhedVi ved godt, at for høj ydeevne er det altid godt at være et skridt foran computerkatastrofer; Da det som IT -personale er ansvaret for at tage sig af dataene fra virksomheden eller virksomhederne, som vi tilhører, påhviler os, som en ekstra bemærkning, synes jeg, det er værd at anbefale altid at have en backup i en anden enhed til noder og har således sikkerhed for oplysningerne garanteret.

Installer og konfigurer Ubuntu Server

Kan du lide og hjælpe denne vejledning?Du kan belønne forfatteren ved at trykke på denne knap for at give ham et positivt punkt