Quante volte abbiamo richiesto di avere i nostri servizi, o meglio, di mantenere i nostri servizi sempre disponibili, e quante volte ci è capitato che l'hard disk del nostro server sia danneggiato e non abbiamo backup, beh, pensando a quelli circostanze, ho deciso di creare questo tutorial per fare in modo che i nostri server o meglio i nostri servizi siano sempre online.
Tenendo conto che il tutorial è progettato per persone avanzate in Linux, non toccherò argomenti come l'installazione del sistema di base che utilizzerò questa volta CentOS 6 64 bit nel suo ultimo aggiornamento. Allo stesso modo, menzionerò solo ciò che è strettamente necessario per il funzionamento del cluster (server ad alta disponibilità).
Faccio anche il commento che questa guida è diretta alla necessità di mantenere sempre attivo il servizio web, nonostante io lo abbia utilizzato con successo con altri servizi, penso che per cominciare o meglio, per cominciare, la cosa più semplice sia creare un web cluster di server.
Senza ulteriori indugi passiamo alle cose buone.
Requisiti di sistema.1. Memoria RAM 1 GB
2. Disco rigido 80 GB
3. Processore Celeron
4. Partizione dati per il cluster (qualsiasi dimensione si desideri creare)
5. Sistema operativo CentOS 6 (nel suo ultimo aggiornamento)
Se soddisfi i requisiti, iniziamo il Installazione del cluster Linux.
La prossima cosa è installare il DRBD per la sincronizzazione delle partizioni su entrambi i server, per questo è necessario eseguire in shell le seguenti istruzioni:
1. Aggiungi ELRepo all'elenco dei repository di sistema
[root @ node1 ~] rpm -ivh http://elrepo.org/elrepo-release-6-5.el6.elrepo.noarch.rpm
2. Installa le utility drbd (Distributed Replication Block Device) e i pacchetti kmod
[root @ node1 ~] yum install -y kmod-drbd83 drbd83-utils(Personalmente uso 8.3 poiché 8.4 mi ha dato problemi con alcune distribuzioni)
3. Drbd viene aggiunto o inserito nel kernel di sistema
[root @ node1 ~] modprobe drbd
4. Il file di risorse per il drbd deve essere creato
Si trova in /etc/drbd.d/mydrbd.res; dove mydrbd.res è il nome del file e questo può essere modificato da chi vogliamo, purché manteniamo l'estensione .res; Questo file va creato su entrambi i server, oppure, quando il file è configurato correttamente, viene copiato nel secondo nodo; la configurazione sarebbe più o meno la seguente:
resource mydrbd {#questo è il nome della risorsa C del protocollo; avvio {wfc-timeout 180; degr-wfc-timeout 120;} # 180 secondi di attesa del dispositivo slave, 120 secondi, se non risponde viene degradato e rimane come disco secondario {on-io-error detach; } net {cram-hmac-alg "sha1"; shared-secret "chiave segreta";} #In questa parte è specificata una chiave con crittografia sha1, questa chiave serve per la comunicazione tra i due nodi. syncer {rate 100M;} #velocità di sincronizzazione, non importa che abbiamo una scheda di rete Gigabit, non funziona a 1000M, la velocità massima consigliata è 100M (l'ho installata con 10M e funziona benissimo, un po' lenta la prima sincronizzazione ma poi non si vede la differenza) su node1 {device/dev/drbd0; # qui specifichiamo quale è il dispositivo riservato al drbd, possiamo avere più dispositivi per dati diversi, o servizi diversi, come SAMBA, MySQL, tra gli altri disk/dev/md2; #specificare la partizione che verrà utilizzata per l'indirizzo drbd 172.16.0.1:7788; # Specifichiamo un IP al di fuori del range della nostra rete, vale la pena ricordare che il cavo di rete deve essere collegato direttamente tra i server, senza passare per uno switch o un hub, se sono schede di rete di modello recente, non è necessario un cavo crossover. interno del meta-disco; } su node2 {# le specifiche del secondo devono essere uguali a quelle del primo, cambia solo l'indirizzo ip, deve essere la stessa porta, questo perché se abbiamo 2 cluster insieme, andranno in conflitto e non funzioneranno opportunamente, se vogliamo avere più cluster, si consiglia di utilizzare porte diverse, va da sé che queste porte devono essere le stesse su entrambi i nodi. dispositivo / dev / drbd0; disco / dev / md2; indirizzo 172.16.0.2:7788; interno del meta-disco; }}
INGRANDIRE
5. Quella che segue è la configurazione del file hostIn questo modo i server vengono cercati tramite l'IP di sincronizzazione e non tramite l'IP della rete locale e quindi si evitano conflitti con i servizi:
/ etc / hosts 192.168.1.1 node1 #nome di node1 sul segmento di rete locale 192.168.1.2 node2 #nome di node2 sul segmento di rete locale 172.16.0.1 node1 #nome di node1 sul segmento di rete di sincronizzazione 172.16.0.2 node2 #name from node2 in sync segmento di rete
6. L'unità di memoria per il drbd è inizializzata
[root @ node1 ~] drbdadm create-md disk1
7. Inizia il servizio drbd o demone
/etc/init.d/drbd start
8. Nel nodo che vogliamo essere il primario eseguiamo il seguente comando
drbdadm - -overwrite-data-of-peer primary disk1
9. Monitoriamo la sincronizzazione di entrambi i nodi
Per questo eseguiamo:
cat / proc / drbdLa risposta del comando precedente è simile alla seguente:
versione: 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 / Incoerente 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: foos: 31424 [===== =============>.] sync'ed: 97,3% (31424/1048508) K finish: 0:00:01 speed: 21.240 (15.644) K/sec # Qui possiamo vedere che la Sincronizzazione va al 97,3% e si specifica che questo è il nodo primario e il nodo secondario appare come inconsistente in quanto la sincronizzazione non è ancora terminata. #Una volta terminato, eseguiamo nuovamente cat / proc / drbd e abbiamo quanto segue: version: 8.3.15 (api: 88 / proto: 86-97) GIT-hash: 0ce4d235fc02b5c53c1c52c53433d11a694eab8c build by phil @ Build32R6, 2012-12-20 20 : 23: 49 1: cs: Connected ro: Primary / Secondary ds: UpToDate / UpToDate C rn- 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 # Restituendo il messaggio UpToDate, siamo consapevoli che la sincronizzazione è completa e le partizioni drbd sono esattamente le stesse.
10. La prossima cosa è formattare il nostro dispositivo drbdPer questo eseguiamo:
mkfs.ext3 / dev / drbd1Uso ext3 perché mi ha dato una buona stabilità ma potremmo usare anche ext4, non consiglio di usare nessun tipo di partizione sotto ext3.
Finora siamo già in grado di montare manualmente la partizione /dev/drbd1 in qualsiasi punto di montaggio del sistema, nel mio caso uso /home per il montaggio poiché ciascuno degli utenti registrati in entrambi i nodi ha le proprie directory per le pagine web, quindi Io corro:
mount -t ext3 / dev / drbd1 / homeE inizio a creare gli utenti per la replica dei dati su entrambi i server, il seguente è il installazione del battito cardiaco, applicazione utilizzata per monitorare i server tra di loro e che avrà il compito di apportare le relative modifiche qualora il primario cada per qualsiasi motivo e trasformi il secondario in primario per garantire la funzionalità del Sistema.
Per il installazione del battito cardiaco devono essere seguiti solo i seguenti passaggi. Il repository viene installato per il download con il seguente comando:
rpm -ivh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpmModifica il file:
epel.repo /etc/yum.repos.d/epel.repocambia riga # 6 ‘Abilita = 1 per abilita = 0’; puoi usare gli editor vi o nano, come desideri.
[epel] name = Pacchetti extra per 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 = priority enabled = 0 # Questa è la riga che dobbiamo modificare Installa l'heartbeat con il seguente comando: yum -enablerepo = epel install heartbeat Una volta terminata l'installazione ci dirà qualcosa di simile a: Installato: heartbeat .i686 0: 3.0.4-1.el6 Completato!Una volta terminato il processo di installazione, la prossima cosa da fare è modificare i 3 file essenziali per il funzionamento dell'heartbeat; situato in /etc/ha.d
- chiavi di autenticazione
- ha.cf
- leprerisorse
Apriamo il file chiavi di autenticazione con il seguente comando:
vi /etc/ha.d/authkeysSi aggiungono le seguenti righe:
auth 1 1 sha1 chiave per la connessione tra gli heartbeat # In questa riga definiamo quale sarà la chiave per comunicare tra loro gli heartbeat di ogni nodo, può essere uguale a quella usata nel drbd o diversa.Cambiamo i permessi dei file chiavi di autenticazione in modo che possa essere letto solo da root:
chmod 600 /etc/ha.d/authkeysOra modifichiamo il secondo file:
vi /etc/ha.d/ha.cfAggiungiamo le seguenti righe:
logfile / var / log / ha-log # il log di sistema è abilitato per errori futuri logfacility local0 keepalive 2 deadtime 30 # il sistema aspetta 30 secondi per dichiarare il nodo1 come inutilizzabile initdead 120 # il sistema aspetta 120 secondi per l'avvio del nodo per attendere l'altro . bcast eth0 # viene specificata la scheda Ethernet attraverso la quale verrà trasmessa la comunicazione tra i server, è molto importante prestare attenzione poiché qui definiamo quale scheda di rete va alla rete locale e quale indirizzare la sincronizzazione udpport 694 # viene specificata la porta di sincronizzazione , come nel drbd possiamo avere più server e ogni coppia con la rispettiva porta definita auto_failback off # contrassegnandolo come off evitiamo che node1 una volta danneggiato e degradato torni come primario o cerchi di tornare in conflitto con un altro nodo node node1 node2 # specifichiamo i nomi di entrambi i nodi.
INGRANDIRE
Per completare la configurazione, dobbiamo modificare il file haresources con il comando:
vi /etc/ha.d/haresourcesAggiungi le seguenti righe:
node1 192.168.1.10/24/eth0 drbddisk :: mydrbd Filesystem :: / dev / drbd0 :: / home :: ext3 #questa riga è responsabile del montaggio della partizione dati sul nodo indicato come nodo primario1 192.168.1.10/24/ eth0 httpd #questa riga è responsabile della definizione del servizio apache o del server web verso il nodo a cui si fa riferimento come primario
INGRANDIRE
I 3 file devono essere copiati su node2, il seguente comando se ne occuperà:
scp -r /etc/ha.d/root@node2:/etc/Il file deve essere modificato httpd.conf in modo che ascolti le richieste dall'ip virtuale, in questo caso 192.168.1.10:
vi /etc/httpd/conf/httpd.confLa linea viene aggiunta o modificata Ascolta 192.168.1.10:80
Il file modificato viene copiato sul secondo server:
scp /etc/httpd/conf/httpd.conf root @ node2: /etc/httpd/conf/Avviamo il servizio heartbeat su entrambi i nodi:
/etc/init.d/heartbeat startCon questo, abbiamo il nostro server ad alta disponibilità pronto, è solo questione di entrare nel nostro browser Internet e mettere l'ip 192.168.1.10 o installare un pannello di tua scelta per l'amministrazione del dominio e generare gli utenti corrispondenti per accedere alle pagine o domini registrati nel server.
Il server ad alta disponibilità può essere utilizzato come già accennato all'inizio di questo tutorial come: server di posta elettronica, server web, server di database, server di samba tra gli altri; Allo stesso modo, ci aiuta a prevenire la perdita di informazioni a causa di guasti hardware e possiamo rafforzarla maggiormente con raid sulle unità disco, sia hardware che software, non è mai troppo avere dischi in raid per mantenere il sistema.
Tuttavia, il server ad alta disponibilità non è esente da problemi o errori, quando un nodo viene degradato possiamo andare al registro dell'heartbeat per vedere cosa è successo, questo si ottiene accedendo al file assegnato nella configurazione di haresources in /etc/ha.d
Allo stesso modo, può succedere che quando si riavviano entrambi i server per qualche motivo non si avviano come primari/secondari e si avviano come primario/sconosciuto e sconosciuto/secondario.
INGRANDIRE
Per risolvere questo dobbiamo seguire i seguenti passaggi.
Nella shell del nodo caduto digitiamo:
drbdadm risorsa secondariaSuccessivamente:
drbdadm disconnette risorsaE poi:
drbdadm - --discard-my-data connect resourceInfine, nel nodo sopravvissuto, o primario, digitiamo:
drbdadm collega risorsaOra inizierà la risincronizzazione dei nodi dal nodo sopravvissuto al nodo caduto, questo iniziando immediatamente quando si preme il tasto "Accedere" nell'istruzione 4.
Quello che è successo qui è noto come a Cervello diviso, questo accade quando per qualche motivo il nodo primario si guasta e viene degradato, una volta che ciò accade si consiglia vivamente di rivedere e analizzare in profondità il nodo caduto e prima di re-incorporarlo nel cluster per risolvere qualsiasi problema esistente, potrebbe anche essere necessario reinstallare l'intero sistema operativo di questo nodo, e senza alcun problema, incorporarlo nel cluster come secondario per la sincronizzazione e se fosse il caso, una volta sincronizzato, cambiarlo in primario.
Infine, vorrei sottolineare il revisione regolare dello stato di salute del clusterSappiamo bene che per prestazioni elevate è sempre bene essere un passo avanti ai disastri informatici; Poiché in qualità di personale IT la responsabilità di curare i dati dell'azienda o delle aziende di cui facciamo parte ricade su di noi, come nota aggiuntiva, credo sia opportuno consigliare di avere sempre un backup in qualche unità alternativa ai nodi e avere così la sicurezza delle informazioni garantite.
Installa e configura Ubuntu Server
Ti è piaciuto e hai aiutato questo Tutorial?Puoi premiare l'autore premendo questo pulsante per dargli un punto positivo
