Visualizzazione post con etichetta Pacemaker. Mostra tutti i post
Visualizzazione post con etichetta Pacemaker. Mostra tutti i post

mercoledì 18 febbraio 2015

FailOver con Corosync/Pacemaker per Apache su Debian/WmWare

Il failover e' un sistema per permettere la continuita' di un servizio di rete mediante due server (di cui uno attivo ed uno passivo) che si sostituiscono nel caso in cui il sistema primario non funzioni in modo corretto



Attenzione : Il sistema indicato gestisce solo i servizi ma non la sincronizzazione dei dati

Per la configurazione e' stata seguita (e parzialmente modificata) la guida a questo link

Per simulare il sistema sono stati creati due server virtuali (deb1 e deb2) ed un client su WMware Player. I server sono stati configurati in modo identico partendo da una Debian base ed installando i pacchetti corosync, pacemaker ed apache2.

Il servizio ad alta disponibilita' (HA) sara' disponibile su 192.168.32.150

deb1 : 192.168.32.138
deb2 : 192.168.32.139
debclient : 192.168.32.140
HA : 192.168.32.150

la prima verifica e' che le macchine siano in grado di pingarsi reciprocamente

per prima cosa e' stato modificato il file /etc/hosts per far risolvere il nome in modo statico dell'altra macchina

per esempio su deb1 e' stato aggiutno
192.168.32.139 deb2.nearbee.it deb2

cosi' da deb1 si puo' pingare direttamente deb2

poi e' stato modificato il file /etc/corosync/corosync.conf  utilizzando il set di indirizzi dei server

interface {
ringnumber: 0
bindnetaddr: 192.168.32.0
 mcastaddr: 226.94.1.1 mcastport: 5405 }

in seguito si verifica /etc/corosync/corosync.conf  abbia ver=0 (di default e' gia' cosi') e si imposta START=yes su /etc/default/corosync

si effettuano le stesse modifiche sia su deb1 che su deb2 e poi si avvia il servizio
/etc/init.d/corosync start

con il comando
crm_mon -1
si devono quindi vedere i due server online

visto che si tratta di una configurazione a due macchine si impostano i seguenti parametri

crm configure property stonith-enabled=false
crm configure property no-quorum-policy=ignore

a questo punto viene impostato l'indirizzo HA 
crm configure primitive VIP ocf:IPaddr2 params ip=192.168.32.150 nic=eth0 op monitor interval=10s 

si verifica che l'ip virtuale 192.168.32.150 sia pingabile

si imposta quindi quale servizio deve essere impostato come high availability (nel nostro caso apache)
(HA-apache e' un nome che puo' essere impostato a piacere

crm configure primitive HA-apache lsb:apache2 op monitor interval=15s
(puo' essere configurato qualsiasi servizio presente in /etc/init.d/)
per verificare che il servizio sia stato modificato usare crm_mon -1
per semplicita' si puo' modificare il file index.html in /var/www inserendo il nome del server per rendere chiaramente visibile quale macchina sta rispondendo


a questo punto il sistema fail over e' completo
con i server deb1 e deb2 accesi e funzionanti, si puo' dal client collegarsi ad 

http://192.168.32.150

e rispondera' il server deb1. Spengendo la macchina virtuale deb1, l'indirizzo virtuale 192.168.32.150 sara' acquisito da deb2, collegandosi quindi ad http://192.168.32.150 sara' la macchina di backup a rispondere




Debugger integrato ESP32S3

Aggiornamento In realta' il Jtag USB funziona anche sui moduli cinesi Il problema risiede  nell'ID USB della porta Jtag. Nel modulo...