Installazione per ambiente virtualizzato ad alta disponibilità

Per un progetto ho il compito di pianificare una configurazione ad alta disponibilità per un negozio online e un sistema CMS. Tuttavia, ovviamente il progetto ha un budget limitato. Quindi una soluzione di fascia alta potrebbe non essere inclusa nel budget.

Ci saranno due macchine che eseguono il server web (CMS, negozio), una macchina che esegue il database e una macchina per eseguire un server fax necessaria per consegnare gli ordini ai partner. Tutti i sistemi eseguono Linux. Tutti questi componenti devono essere altamente disponibili e supportare il failover trasparente.

Per ridurre i costi dell'hardware, penso a un ambiente virtualizzato. Ci sono molte informazioni là fuori, ma non so esattamente dove cominciare. Sembra ovvio che almeno i server sono necessari come host per le macchine virtuali, quindi non esiste un singolo punto di errore.

Qual è il modo migliore per supportare l'alta disponibilità?

La prima domanda è quale soluzione di virtualizzazione sia la migliore in questa situazione. Ci deve essere una sorta di interfaccia di gestione. È necessario un modo per spostare una macchina virtuale in esecuzione da un host a un altro, in modo da poter eseguire la manutenzione dell'host. È necessario un qualche tipo di meccanismo, in modo che le macchine virtuali siano ancora disponibili in caso di errore di un host. Potresti consigliarti su una soluzione valida qui?

Uno storage di file condiviso sembra essere il prerequisito dell'alta disponibilità nella maggior parte dei casi (aspettarsi VMware vSphere che è piuttosto costoso). Tuttavia, preferirebbe mettere più soldi negli host della macchina virtuale piuttosto che aggiungere altri due server all'installazione per fornire un archivio file NFS ridondante. Esiste la possibilità di andare d'accordo solo con i due host di macchine virtuali? Una soluzione potrebbe essere due, usare questi due anche come host NFS. C'è molto di una penalità prestazionale per fare questo?

EDIT: mirare a una disponibilità del 99,9%. Tuttavia, non è richiesta la disponibilità 24 ore su 24, 7 giorni su 7 in quanto vi sono orari di lavoro regolari, il che offre un certo spazio di manovra. Il periodo di disponibilità che deve essere in qualche modo garantito è dalle 10 alle 24.

Come panoramica generale, per ottenere la disponibilità elevata è necessario:

1. Più server
2. Più copie coerenti dei dati
3. Dati coerenti a cui è possibile accedere tra più server
4. Un modo per avviare automaticamente una seconda istanza sul server di standby

Il numero 1 è semplice come sembra: acquista due server identici.

Il numero 2 può essere raggiunto da una SAN replicante (costosa, molto veloce, molto affidabile) o da un filesystem replicato su ciascuno dei server (economico, velocità e affidabilità possono dipendere dalla vostra conoscenza della tecnologia scelta).

Il numero 3 può essere ottenuto da una SAN (un LUN di archiviazione, accessibile da due server) o da un file system replicato (due aree di archiviazione separate, ogni server può vedere solo il proprio).

Il numero 4 può essere raggiunto da un'applicazione di battito cardiaco.

Per fare ciò con un budget limitato, diciamo VMWare vSphere, è possibile utilizzare una SAN o VMWare ora offre un'appliance di archiviazione autoreplicante che offre due archivi dati distinti su due server che possono essere utilizzati per la disponibilità elevata. vSphere offre anche heartbeat integrati e configurazioni ad alta disponibilità.

Per fare ciò senza budget, è possibile seguire il percorso Xen e utilizzare DRBD per replicare la memoria tra i due nodi. Quindi si imposta heartbeat per cambiare il nodo di archiviazione DRBD attivo e l'istanza Xen per avviare le macchine virtuali sul secondo host quando il primo si interrompe.

Non otterrai uptime di 5-nove (99,999%) usando questi consigli di base, ma potresti facilmente ottenere 3-nove (99,9%) usando i metodi più economici se sai cosa stai facendo.

Parli di "spesa" in termini di "quanta liquidità questo costo costerà acquistare" quando si discute di spazio di archiviazione condiviso. Questo è un punto assolutamente valido, i soldi sono stretti ovunque .

Ma se stai parlando di High Availability, allora devi anche chiedere " perché vogliamo alta disponibilità?" e se la risposta è, ad esempio, "perché l'azienda trasforma oltre $ 2000 all'ora nelle vendite online, quindi se siamo fuori per un'ora, allora abbiamo perso $ 2000", allora la domanda di spesa e convenienza può diventare "Possiamo permettersi di non acquistare qualcosa che abiliti o migliori notevolmente la nostra distribuzione ad alta disponibilità? "

Questo è un dettaglio importante e gioca con il tuo commento sul budget: la "coda" IT non deve scuotere il "cane" aziendale insistendo su una soluzione eccessivamente complessa e costosa a un piccolo problema, ma allo stesso tempo se l'azienda ha determinati requisiti della sua infrastruttura IT, quindi deve essere preparato a budget per loro correttamente o per adeguare i suoi requisiti.

Penso che la virtualizzazione abbia molte potenzialità nel migliorare la disponibilità dei sistemi, ma non è una bacchetta magica. Il lato hardware delle cose, sebbene importante, è molto secondario rispetto ai requisiti software - non va bene avere un cluster di database SQL che cade senza problemi in caso di crash di uno dei server SQL se l'applicazione front-end che parla al database soffoca perché non è in grado di gestire il failover.

E due server "ad alta disponibilità" posti uno accanto all'altro in un datacenter sono ancora vulnerabili a interruzioni di corrente, furti, ecc. Ancora una volta, a seconda della risposta a " perché lo stiamo facendo?", Potrebbe essere necessario considerare questo aspetto piuttosto con attenzione poiché può aggiungere spese e complessità a parecchie parti del progetto.

Senza sapere quale DB e server applicazioni usi raccomanderei:

• Usa XEN> 3.2 in modalità PV per le macchine virtuali (solo il mio preferito): anche i compartimenti o altre soluzioni di virutalizzazione lightwight potrebbero adattarsi (OpenVZ per nominarne uno).
• Crea quattro macchine VM su ciascun nodo fisico
• Utilizzare un RAID 5 locale con dischi SAS da 3,5 "- quanti dischi è possibile localmente (5 è buono)
• Usa dischi RPM da 15k (i tuoi DB ne avranno bisogno)
• Usa DRBD e OCFS2 per fornire storage "condiviso" economico, usa una rete locale veloce, sicura e affidabile per questa connessione (il collegamento diretto di interconnessioni è piuttosto veloce e buono).
• Esegui l'HA a livello di applicazione
• Usa il bilanciamento del carico tra le coppie di macchine, in modo da ottenere 8 macchine che svolgono attività simultanee

HA-Esempi:

• Server applicazioni: utilizza Tomcat in modalità cluster attivo / attivo
• LVS: usa la replica simultanea di slave e master di lvs
• Oracle-DB: utilizzare RAC (non so se esistono soluzioni equivalenti per i DB OpenSource)

Se esegui HA a livello di applicazione, quel livello sa meglio come replicare le sessioni. Se un nodo cade (pianificato o non pianificato), il nodo sopravvissuto subentrerà, comprese le sessioni.

Perché vuoi acquistare i tuoi host? Perché non trovi un provider Enterprise Cloud / IaaS come BlueLock o Terremark che ti fornirà l'infrastruttura di cui hai bisogno? Forniranno servizi come vSphere HA (più come tempi di inattività ridotti rispetto al servizio HA ma è una soluzione economica), Firewall, Offloader LTM / SSL, SAN (con scaffali ridondanti), Monitoraggio / Avviso, ecc. Nota che non lo siamo parlando di soluzioni cloud di consumo qui, quindi preparatevi a pagare per il valore.

È possibile esaminare una soluzione di replica virtualizzata / di archiviazione all-in-one.

Il filesystem ZFS lo rende possibile, come indicato in questo post del blog .

Un'altra opzione sarebbe quella di seguire il tutorial che illustra in dettaglio una soluzione con Red Hat KVM .