Hur många gånger har vi krävt att ha våra tjänster, eller snarare, hålla våra tjänster alltid tillgängliga, och hur många gånger har det hänt oss att hårddisken på vår server är skadad och vi har inte backup, ja, tänker på dem omständigheterna har jag bestämt mig för att skapa detta handledning för att säkerställa att våra servrar eller snarare våra tjänster alltid är online.
Med tanke på att handledningen är avsedd för avancerade personer i Linux kommer jag inte att beröra ämnen som installationen av bassystemet som jag kommer att använda den här gången CentOS 6 64 bitar i sin senaste uppdatering. På samma sätt kommer jag bara att nämna vad som är strikt nödvändigt för driften av klustret (servrar med hög tillgänglighet).
Jag kommenterar också att den här guiden riktar sig till behovet av att hålla webbtjänsten alltid aktiv, även om jag har använt den med andra tjänster framgångsrikt tror jag att som en början eller bättre sagt, som en början, är det enklaste att skapa en serverklusterwebb.
Utan vidare, låt oss gå vidare till de bra grejerna.
Systemkrav.1. RAM -minne 1 GB
2. Hårddisk 80 GB
3. Celeron -processor
4. Datapartition för klustret (vilken storlek du vill skapa)
5. Operativsystem CentOS 6 (i den senaste uppdateringen)
Om du uppfyller kraven, låt oss börja Linux -klusterinstallation.
Nästa sak är att installera DRBD för synkronisering av partitionerna på båda servrarna, för detta är det nödvändigt kör in -shell följande instruktioner:
1. Lägg till ELRepo i listan över systemförvar
[root @ node1 ~] rpm -ivh http://elrepo.org/elrepo-release-6-5.el6.elrepo.noarch.rpm
2. Installera drbd (Distributed Replicated Block Device) -verktyg och kmod -paket
[root @ node1 ~] yum installera -y kmod-drbd83 drbd83-utils(Personligen använder jag 8,3 eftersom 8,4 gav mig problem med vissa distributioner)
3. Drbd läggs till eller sätts in i systemkärnan
[root @ node1 ~] modprobe drbd
4. Resursfilen för drbd måste skapas
Det ligger på /etc/drbd.d/mydrbd.res; där mydrbd.res är namnet på filen och detta kan ändras av alla vi vill, så länge vi behåller tillägget .res; Denna fil bör skapas på båda servrarna, eller, när filen är korrekt konfigurerad, kopieras den till den andra noden; konfigurationen skulle vara mer eller mindre följande:
resurs mydrbd {#detta är namnet på protokollets C -resurs; start {wfc-timeout 180; degr-wfc-timeout 120;} # 180 sekunder väntar på slavenheten, 120 sekunder, om den inte svarar försämras den och förblir som sekundär disk {on-io-error detach; } net {cram-hmac-alg "sha1"; delad hemlig "hemlig nyckel";} #I denna del anges en nyckel med sha1-kryptering, denna nyckel är för kommunikation mellan de två noder. syncer {rate 100M;} #synkroniseringshastighet, det spelar ingen roll att vi har ett Gigabit -nätverkskort, det fungerar inte vid 1000M, den maximala rekommenderade hastigheten är 100M (jag har installerat det med 10M och det fungerar bra, lite långsamt den första synkroniseringen men då ser du inte skillnaden) på nod1 {device / dev / drbd0; # här anger vi vilken enhet som är reserverad för drbd, vi kan ha flera enheter för olika data eller olika tjänster, till exempel SAMBA, MySQL, bland annat disk / dev / md2; #specificera partitionen som ska användas för drbd -adress 172.16.0.1:7788; # Vi anger en IP utanför vårt nätverks räckvidd, det är värt att nämna att nätverkskabeln måste anslutas direkt mellan servrar, utan att gå igenom en switch eller hubb, om de är nya nätverkskort av modell är en crossover -kabel inte nödvändig. metadisk internt; } på nod2 {# specifikationerna för den andra måste vara desamma som de för den första, bara ip -adressen ändras, det måste vara samma port, detta beror på att om vi har två kluster tillsammans kommer de att konflikta och fungerar inte på lämpligt sätt, om vi vill ha flera kluster, rekommenderas det att använda olika portar, det är självklart att dessa portar måste vara desamma på båda noder. enhet / dev / drbd0; disk / dev / md2; adress 172.16.0.2:7788; metadisk internt; }}
FÖRSTORA
5. Följande är värdfilkonfigurationenDetta är för att servrarna ska sökas genom synkroniserings -IP och inte av IP: n för det lokala nätverket och därmed undviker vi konflikter med tjänsterna:
/ etc / hosts 192.168.1.1 nod1 #namn på nod1 på lokalt nätverkssegment 192.168.1.2 nod2 #namn på nod2 på lokalt nätverkssegment 172.16.0.1 nod1 #namn på nod1 på synkroniseringsnätverkssegment 172.16.0.2 nod2 #namn från nod2 i synkronisering nätverkssegment
6. Lagringsenheten för drbd initieras
[root @ node1 ~] drbdadm create-md disk1
7. Drbd -tjänsten eller deamon startar
/etc/init.d/drbd start
8. I noden som vi vill vara den primära kör vi följande kommando
drbdadm--overwrite-data-of-peer primär disk1
9. Vi övervakar synkroniseringen av båda noder
För detta utför vi:
cat / proc / drbdSvaret från kommandot ovan är ungefär så här:
version: 8.3.15 (api: 88 / proto: 86-97) GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c build by 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 [===== =============>.] synkroniserad: 97,3% (31424/1048508) K mål: 0:00:01 hastighet: 21 240 (15 644) K / sek # Här kan vi se att synkroniseringen går till 97,3% och det specificeras att detta är den primära noden och den sekundära noden visas som inkonsekvent eftersom synkroniseringen inte har slutförts ännu. #När vi är klara kör vi cat / proc / drbd igen och vi har följande: version: 8.3.15 (api: 88 / proto: 86-97) GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c build by phil @ Build32R6, 2012-12-20 20: 23: 49 1: cs: Ansluten 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 # Genom att returnera UpToDate -meddelandet är vi medvetna om att synkroniseringen är klar och drbd -partitionerna är exakt desamma.
10. Nästa sak är att formatera vår enhet drbdFör det utför vi:
mkfs.ext3 / dev / drbd1Jag använder ext3 eftersom det har gett mig bra stabilitet men vi kan också använda ext4, jag rekommenderar inte att använda någon typ av partition under ext3.
Hittills har vi redan kunnat montera / dev / drbd1 -partitionen manuellt i valfri monteringspunkt i systemet, i mitt fall använder jag / home för montering eftersom var och en av användarna som är registrerade i båda noder har sina egna kataloger för webbsidor, därför Jag springer:
mount -t ext3 / dev / drbd1 / homeOch jag börjar skapa användarna för datareplikering på båda servrarna, följande är hjärtslagsinstallation, applikation som används för att övervaka servrarna sinsemellan och som kommer att ansvara för att göra relevanta ändringar om primären faller av någon anledning och gör sekundären till primär för att säkerställa systemets funktionalitet.
För hjärtslagsinstallation endast följande steg bör följas. Förvaret installeras för nedladdning med följande kommando:
rpm -ivh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpmRedigera filen:
epel.repo /etc/yum.repos.d/epel.repoändra rad # 6 ‘Enable = 1 by enable = 0’; du kan använda vi- eller nanoredigerarna som du vill.
[epel] name = Extra paket för 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 aktiverad = 0 # Det här är raden som vi måste redigera Installera hjärtslaget med följande kommando: yum -enablerepo = epel install heartbeat När installationen är klar kommer den att berätta något liknande till: Installerad: hjärtslag .i686 0: 3.0.4-1.el6 klar!När installationen är klar är nästa sak att redigera de tre viktiga filerna för att hjärtslaget ska fungera; ligger i /etc/ha.d
- autentiseringsnycklar
- ha.cf
- harekällor
Vi öppnar filen autentiseringsnycklar med följande kommando:
vi /etc/ha.d/authkeysFöljande rader läggs till:
auth 1 1 sha1 -tangent för anslutning mellan hjärtslag # I den här raden definierar vi vilken som kommer att vara nyckeln för varje nodes hjärtslag för att kommunicera med varandra, den kan vara densamma som den som används i drbd eller olika.Vi ändrar filbehörigheterna autentiseringsnycklar så att den bara kan läsas med root:
chmod 600 /etc/ha.d/authkeysNu redigerar vi den andra filen:
vi /etc/ha.d/ha.cfVi lägger till följande rader:
logfile / var / log / ha-log # systemlogg är aktiverad för framtida fel logfacility local0 keepalive 2 deadtime 30 # systemet väntar 30 sekunder med att förklara nod1 som inoperabel initdead 120 # systemet väntar 120 sekunder på att nodstart startar för att vänta på den andra . bcast eth0 # är specificerat Ethernet -kortet genom vilket kommunikationen mellan servrar kommer att överföras, det är mycket viktigt att vara uppmärksam eftersom vi här definierar vilket nätverkskort som går till det lokala nätverket och vilket för att synkronisera direkt utpport 694 # synkroniseringsporten anges som i drbd kan vi ha flera servrar och varje par med sin respektive port definierade auto_failback av # genom att markera den som av. # vi anger namnen på båda noder.
FÖRSTORA
För att slutföra konfigurationen måste vi redigera haresources -filen med kommandot:
vi /etc/ha.d/haresourcesLägg till följande rader:
nod1 192.168.1.10/24/eth0 drbddisk :: mydrbd Filsystem ::/ dev/ drbd0 ::/ home :: ext3 #denna rad är ansvarig för att montera datapartitionen på noden som refereras till som primär nod1 192.168.1.10/24/ eth0 httpd #den här raden är ansvarig för att definiera apache -tjänsten eller webbservern mot noden som refereras till som primär
FÖRSTORA
De tre filerna måste kopieras till node2, följande kommando tar hand om det:
scp -r /etc/ha.d/root@node2:/etc/Filen måste redigeras httpd.conf så att den lyssnar efter förfrågningar från den virtuella ip, i det här fallet 192.168.1.10:
vi /etc/httpd/conf/httpd.confRaden läggs till eller ändras Lyssna 192.168.1.10:80
Den modifierade filen kopieras till den andra servern:
scp /etc/httpd/conf/httpd.conf root @ node2: /etc /httpd /conf /Vi startar hjärtslagstjänsten på båda noder:
/etc/init.d/heartbeat startMed detta har vi vår server med hög tillgänglighet klar, det är bara att gå in i vår webbläsare och sätta ip 192.168.1.10 eller installera en panel som du väljer för domänadministration och generera motsvarande användare för att komma åt de sidor eller domäner som är registrerade i servern.
Servern med hög tillgänglighet kan användas som redan nämnts i början av denna handledning som: e -postserver, webbserver, databaseserver, samba -server bland andra; På samma sätt hjälper det oss att förhindra förlust av information på grund av maskinvarufel, och vi kan förstärka det mer med raider på hårddiskenheterna, antingen med hårdvara eller programvara, det är aldrig för mycket att ha skivor i raid för att underhålla systemet.
Servern med hög tillgänglighet är dock inte undantagen från problem eller fel, när en nod försämras kan vi gå till hjärtslagsloggen för att se vad som hände, detta uppnås genom att komma åt filen som har tilldelats i haresources -konfigurationen i /etc/ha.d
På samma sätt kan det hända att när du startar om båda servrarna av någon anledning startar de inte som primära / sekundära och börjar som primära / okända och okända / sekundära.
FÖRSTORA
För att lösa detta måste vi följa följande steg.
I skalet på den fallna noden skriver vi:
drbdadm sekundär resursSenare:
drbdadm koppla bort resursOch då:
drbdadm---discard-my-data connect resourceSlutligen skriver vi i den överlevande noden eller primären:
drbdadm anslut resursNu kommer det att starta om synkronisering av noder från den överlevande noden till den fallna noden, detta börjar omedelbart när du trycker på knappen "Stiga på" i instruktion 4.
Det som hände här är känt som en Delad hjärna, detta händer när den primära noden av någon anledning misslyckas och försämras, när detta händer kan det starkt rekommenderas att granska och analysera den fallna noden på djupet och innan den återinkorporeras i klustret för att lösa eventuella befintliga problem, kan det också vara nödvändigt för att installera om hela operativsystemet för denna nod, och utan problem, införliva det i klustret som sekundär för synkronisering och om det var fallet, när det väl synkroniserats, ändra det till primärt.
Slutligen vill jag betona regelbunden översyn av klusterhälsaVi vet väl att för hög prestanda är det alltid bra att vara ett steg före datorkatastrofer. Eftersom det som IT -personal faller ansvaret för att ta hand om uppgif.webpterna för företaget eller företagen som vi tillhör, som en extra anteckning tycker jag att det är värt att rekommendera att alltid ha en backup i någon alternativ enhet till noder och har därmed säkerheten för informationen garanterad.
Installera och konfigurera Ubuntu Server
Gillade du och hjälpte denna handledning?Du kan belöna författaren genom att trycka på den här knappen för att ge honom en positiv poäng
