cluster

Proxmox ve HA Cluster

Postato il

logoIn questo post  vedremo come realizzare un HA Failover Cluster utilizzando due nodi di proxmox ve 3.4.
Con l’implementazione di un cluster, si è in grado di bilanciare il carico di lavoro su diversi host, ed è generalmente consigliato per essere distribuito su almeno tre nodi per aumentare la disponibilità delle macchine virtuali (HA).
All’interno del cluster
è possibile eseguire la migrazione in tempo reale (live) delle macchine virtuali, anche se non si dispone di storage condiviso ed in  caso di manutenzione hardware, è possibile spostare “al volo” le macchine virtuali su un altro nodo, senza tempi di inattività (o downtime limitato), infatti se una macchina virtuale o contenitore (VM o CT) è configurato come HA e un host fisico va in failure la VM viene riavviata automaticamente su uno degli altri nodi che compone il cluster.
Leggi il seguito di questo post »

Annunci

Failover Cluster con OpenFiler 2.3 (4a Parte)

Postato il Aggiornato il

segue dalla parte 3a.

Avviare HeartBeat e prima configurazione

rm /opt/openfiler/etc/httpd/modules
ln -s /usr/lib64/httpd/modules /opt/openfiler/etc/httpd/modules

prima di avviare l’heartbeat creiamo un logical Volume:

lvcreate -L 50M -n filer vg0drbd

Entrare sull’interfaccia web di openfiler01 e abilitare il servzio iscsi target che genererà  automaticamente il file  /etc/ha.d/haresource
Leggi il seguito di questo post »

Failover Cluster con OpenFiler 2.3 (3a parte)

Postato il Aggiornato il

segue dalla parte 2a.

Configurazione di HeartBeat

Heartbeat si occupa di gestire lo switch delle risorse tra i due nodi, questo processo viene detto “FailOver”.
I due nodi eseguono heartbeat come servizio, il quale, invia un segnale sull’interfaccia secondaria (eth1).
Se un nodo muore, HeartBeat rileva questo evento ed elegge il nodo secondario a primario eseguendo vari script di avvio che si trovano in “/etc/ha.d/resources.d”

Occorre quindi modificare I file “/etc/ha.d/ha.cf” e “/etc/ha.d/authkeys”.

Su entrambi gli openfiler Creare il file /etc/ha.d/authkeys aggiungendovi

auth 2
2 crc

Registringiamo il permesso sul file solo all’utente root su entrambi gli openfiler: Leggi il seguito di questo post »

Failover Cluster con OpenFiler 2.3 (2a parte)

Postato il Aggiornato il

segue dalla parte 1a.
Ora occorre modificare su entrambi gli openfiler il file /etc/hosts per il corretto dialogo in rete tramite il nome host FQDN (Fully Qualified Domain Name).

Su openfiler01 :

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 openfiler01 localhost.localdomain localhost
192.168.32.12 openfiler02

Su openfiler02:

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 openfiler02 localhost.localdomain localhost
192.168.32.11 openfiler01

Adesso occorre che i due nodi si scambino informazioni via ssh senza l’utilizzo di una password ma con chiavi condivise:

Leggi il seguito di questo post »

Failover Cluster con OpenFiler 2.3 (1a Parte)

Postato il Aggiornato il

A distanza da più di anno dalla presentazione di questo progetto al LinuxDay 2010 di Bologna, dove potete qui scaricare le slide, pubblico finalmente il post relativo sul blog….che volete ognuno ha i suoi tempi :P.
Nel frattempo il progetto è stato ottimizzato e semplificato, per quanto possibile.
Il risultato finale è di ottenere un Cluster in Alta Affidabilità (HA), che metta a disposizione un volume iSCSI da utilizzare come datastore per vmware esxi 4.1 .
Il tutto è stato testato nelle condizioni peggiori:
openfiler in macchine  virtuali e rete a 100MB con risultati davvero notevoli ovvero le 3 macchine virtuali, sul volume messo a disposizione del cluster, non hanno subito la minima disfunzione una volta spento il nodo primario.
Le prestazioni del cluster con l’utilizzo di macchine fisiche con volumi raid dedicati e connessioni di rete in gigabit, utilizzando anche il bonding tra le schede di rete e switch con aggregation link, sono sicuramente di livello Enterprise.
Leggi il seguito di questo post »