Cluster ad alta disponibilità
I tuoi servizi restano attivi quando un server si guasta
Costruiamo cluster HA su Proxmox VE, Hyper-V, SUSE Virtualization e XCP-ng che rilevano i guasti dei nodi e riavviano automaticamente le tue macchine virtuali.
-
Failover e failback automatici -
Replica continua delle VM -
Storage distribuito con Ceph -
Rilevamento dei guasti in pochi secondi -
Monitoraggio dello stato dei nodi e avvisi
Nessun singolo punto di guasto
Failoververificato
Minutiper recuperare
Resiliente allaperdita di nodi
Cosa ti offre un cluster HA
Un cluster ad alta disponibilità mantiene i servizi in esecuzione durante guasti hardware, finestre di manutenzione e persino interruzioni regionali. Ecco cosa significa nella pratica.
-
Tempi di inattività minimi
Per saperne di più MenoQuando un nodo si guasta, le sue macchine virtuali vengono riavviate su nodi integri entro pochi minuti, senza bisogno di intervento manuale. I nodi vengono aggiornati uno alla volta mentre le VM migrano a caldo, quindi la manutenzione non comporta più una finestra di inattività.
-
Sicurezza dei dati
Per saperne di più MenoI dati della VM vengono replicati continuamente tra i nodi o mantenuti su storage distribuito come Ceph. La perdita di un disco, di un nodo o di un percorso di rete non rende i tuoi dati offline.
-
Recupero prevedibile
Per saperne di più MenoGli obiettivi di tempo di ripristino e punto di ripristino vengono concordati durante la progettazione e poi verificati nei test di failover, non lasciati sulla carta. Quando il nodo guasto torna in servizio, i carichi di lavoro vengono riportati in modo ordinato.
-
Scelta della piattaforma
Per saperne di più MenoRealizziamo cluster HA su Proxmox VE, Microsoft Hyper-V, SUSE Virtualization e XCP-ng. Ogni piattaforma porta con sé il proprio stack di replica e gestione: scegliamo quella che i vostri ingegneri si sentiranno davvero a proprio agio nel gestire.
-
Crescita senza interruzioni
Per saperne di più MenoLa capacità cresce aggiungendo nodi al cluster, con i carichi di lavoro ridistribuiti tra di essi: i nuovi nodi si uniscono mentre i servizi continuano a funzionare. Le macchine virtuali vengono distribuite tra i nodi in base al carico effettivo, mantenendo costanti i tempi di risposta.
-
Costi trasparenti
Per saperne di più MenoProxmox VE e XCP-ng includono l’HA senza costi di licenza aggiuntivi: paghi per l’hardware e la configurazione, non per licenze cluster per nodo. Anche le piattaforme commerciali sono supportate, quando sono in linea con le licenze esistenti.
Carichi di lavoro che giustificano un cluster HA
- Database e code di messaggi
- E-commerce e sistemi di pagamento
- Piattaforme SaaS e portali clienti
- ERP, CRM e applicazioni critiche per il business
- Sanità e sistemi regolamentati
- Servizi di streaming e in tempo reale
- Servizi file e archiviazione
- VoIP e piattaforme di comunicazione
Cluster HA chiavi in mano – dalla
progettazione al failover verificato
-
1
Valutazione e progettazione
Identifichiamo le tue applicazioni critiche, i tempi di inattività accettabili e gli obiettivi di ripristino. Verifichiamo l’hardware, la rete e lo storage esistenti. Sulla base di queste informazioni, progettiamo il cluster – numero di nodi, layout dello storage e logica di failover – per soddisfare tali obiettivi.
-
2
Configurazione di nodi e rete
Configuriamo i server come nodi di cluster con interconnessioni ridondanti. Gli IP di failover e la ridondanza di rete vengono configurati e verificati. Viene implementato uno storage condiviso o distribuito per la ridondanza dei dati.
-
3
Configurazione del cluster
Installiamo e configuriamo servizi cluster su Proxmox VE, Microsoft Hyper-V, SUSE Virtualization o XCP-ng. Le risorse del cluster – IP virtuali, storage e capacità di calcolo – vengono definite e priorizzate. Le regole di failover e failback automatici vengono configurate per ciascun carico di lavoro.
-
4
Test di failover
Simuliamo guasti dei nodi e verifichiamo che le macchine virtuali si riavviino dove previsto, entro il tempo concordato. Le prestazioni sotto carico di failover vengono misurate, non presunte. Viene testato anche il ripristino da scenari di guasto dello storage e della rete.
-
5
Monitoraggio e manutenzione
Il monitoraggio tiene traccia dello stato dei nodi, dello stato della replica e del quorum del cluster. Gli avvisi vengono attivati su eventi critici: perdita di un nodo, replica degradata, esaurimento delle risorse. La manutenzione programmata mantiene stabile il cluster senza interrompere i servizi.
-
6
Supporto continuo
I nostri ingegneri restano disponibili per la risoluzione dei problemi e le modifiche alla configurazione. Applichiamo aggiornamenti e upgrade nodo per nodo, senza tempi di inattività del cluster.
Domande frequenti
-
Quanto velocemente avviene effettivamente il failover?
Per la maggior parte delle configurazioni HA, una macchina virtuale da un nodo guasto si riavvia su uno sano entro uno-cinque minuti: il tempo esatto dipende dalla piattaforma, dallo storage e dalla rapidità con cui si avvia il sistema operativo guest. Per gli eventi pianificati, la migrazione live sposta le VM senza alcuna interruzione. Se anche un minuto è troppo, consulta la domanda sulla fault tolerance qui sotto.
-
Di quanti server ho bisogno per un cluster HA?
Tre nodi sono il minimo pratico: un cluster necessita di una maggioranza di voti (quorum) per decidere quali nodi sono integri ed evitare situazioni di split-brain. Una configurazione a due nodi è possibile con un dispositivo di quorum esterno, ma consigliamo una configurazione con tre o più nodi.
-
Tutti e quattro gli hypervisor supportano l'alta disponibilità?
Sì. Proxmox VE dispone di un gestore HA integrato, Microsoft Hyper-V utilizza il clustering di failover di Windows Server, SUSE Virtualization include l’HA pronta all’uso e XCP-ng la fornisce tramite il suo stack di gestione. I principi sono gli stessi: cambiano gli strumenti, e noi li adattiamo al tuo team.
-
Di quale storage ha bisogno un cluster HA?
Il failover funziona solo se ogni nodo può accedere ai dati della VM, quindi il cluster necessita di storage condiviso o distribuito, ad esempio Ceph, volumi replicati o un sistema di storage esterno. I dischi puramente locali non sono sufficienti; progettiamo il livello di storage insieme al cluster.
-
Un cluster HA mi protegge dalla perdita di dati?
L’HA protegge la disponibilità, non la cronologia: se i dati vengono danneggiati o eliminati, la replica copia fedelmente il danno su ogni nodo. Ecco perché i backup restano obbligatori insieme a qualsiasi cluster. La quantità di dati recenti che un failover può perdere dipende dal fatto che la replica sia sincrona o asincrona, e la configuriamo in base al tuo obiettivo di punto di ripristino.
-
Gli utenti noteranno qualcosa durante un failover?
Per gli eventi pianificati – manutenzione, ribilanciamento del carico – le macchine virtuali vengono spostate live tra i nodi e gli utenti non si accorgono di nulla. In caso di guasto imprevisto di un nodo, le VM interessate vengono riavviate su un altro nodo, quindi le sessioni attive su quelle VM vengono interrotte brevemente e poi riprendono. Le applicazioni ben progettate si riconnettono automaticamente e, per la maggior parte degli utenti, è come un ricaricamento della pagina.
-
Qual è la differenza tra alta disponibilità e tolleranza ai guasti?
L'alta disponibilità riavvia le VM interessate su un altro nodo: si verifica una breve interruzione. La tolleranza ai guasti mantiene una copia speculare live della macchina in esecuzione, quindi un guasto del nodo non provoca alcuna interruzione, al costo di circa il doppio delle risorse. La maggior parte dei carichi di lavoro è ben servita dall'HA; la tolleranza ai guasti è riservata ai pochi che non possono tollerare nemmeno pochi secondi di inattività.
-
Le mie applicazioni devono essere modificate per essere eseguite in un cluster HA?
Di solito no: l’HA a livello di VM è trasparente per le applicazioni al suo interno. Per database e altri servizi stateful, è possibile aggiungere la replica a livello applicativo sopra l’HA del cluster per garantire tempi di ripristino ancora più stringenti, ma è un’opzione, non un requisito.
