La tua azienda si affida a servizi cloud, database, server remoti o dati memorizzati di qualche tipo?
Certo che sì.
Temi costantemente i tempi morti?
Certo che sì.
Nel nostro mercato di 24 ore, sempre attivo, sempre connesso, qualcuno è sempre sveglio, i tempi morti sono critici. In poche parole, andare in bianco è un male per gli affari… ed è inaccettabile. Ecco perché le soluzioni ingegneristiche ad alta disponibilità, come quelle offerte da Liquid Web e da altre moderne società di web hosting, sono così importanti. Dall’infrastruttura ad alta disponibilità e i database SQL, alla replica ridondante, i log delle transazioni e l’eliminazione dei singoli punti di errore, un host web è buono solo quanto i suoi servizi di ingegneria dell’alta disponibilità (HA).
Prevediamo che la vostra applicazione sia ospitata su un’infrastruttura gestita tradizionale.
Ora, vediamo perché un server ad alta disponibilità è una soluzione migliore.
Alta disponibilità riassunta
Quando si parla di HA, i tre principi dell’ingegneria dell’affidabilità devono essere considerati:
- Ridurre o eliminare i singoli punti di errore.
- Nei sistemi ridondanti, assicurarsi che i punti di crossover siano affidabili.
- Il sistema in atto deve rilevare e reagire ai guasti in tempo reale.
Quando questi tre principi sono implementati in modo affidabile, si ottiene una riduzione significativa dei tempi di inattività. Un host web di qualità avrà questi principi in mente quando progetta i suoi servizi.
Ridurre i singoli punti di fallimento in un sistema HA significa ridondanza nei dati virtuali, fisici o una combinazione dei due. Una struttura HA avrà un volume primario e almeno un volume fisico di backup. Una configurazione standard è composta da due volumi primari identici, sostenuti da due volumi fisici identici, Distributed Replicated Block Device (DR:BD), sostenuti da due volumi virtuali DR:BD. I volumi DR:BD eseguono una replica selettiva e sincrona dei dati, il che significa che solo i blocchi di dati modificati (non l’intero volume) vengono riscritti e sottoposti a backup in tempo reale.
I volumi DR:BD in definitiva riducono i tempi di backup perché richiedono meno risorse di calcolo alla volta. Ogni livello di backup (due volumi primari identici, due volumi virtuali DR:BD identici, ecc.) è memorizzato su server fisici separati; alcuni host eseguono il backup anche su un server in una posizione remota. Una configurazione con una posizione remota elimina un altro singolo punto di fallimento, proteggendo i tuoi dati da disastri naturali e altri problemi basati sulla posizione, come interruzioni di corrente e guasti di rete.
Cosa fare con il database
In un sistema HA, si raccomanda che il tuo database SQL sia memorizzato su un ambiente server separato e ridondante, poiché migliora le prestazioni e riduce l’overhead sul tuo server primario. Un server SQL dedicato lavora anche con/per i principi dell’ingegneria dell’affidabilità in quanto è specificamente progettato per l’alta disponibilità, compresi i crossover automatici e affidabili e il rilevamento dei guasti in tempo reale.
I database SQL creano anche registri delle transazioni incrementali; un’altra guardia contro i singoli punti di errore. I registri delle transazioni registrano ogni cambiamento nel database a intervalli stabiliti con una frequenza di un minuto: il database SQL può usare i registri delle transazioni come un set di dati, scrivendo sui server di backup nella vostra configurazione HA.
La configurazione standard di Liquid Web per l’hosting di database SQL include un backup quotidiano dell’intero database e 24 ore di registri delle transazioni ogni ora.
Monitoraggio per il Failover
Al centro della configurazione HA dovrebbe esserci un sistema di monitoraggio che tenga costantemente e costantemente d’occhio la salute dei server in cluster ed esegua automaticamente i failover quando necessario. Il sottosistema di monitoraggio più popolare nel settore è Heartbeat. Heartbeat è un monitor basato su Linux che può supportare in modo affidabile più nodi. Heartbeat può identificare rapidamente e accuratamente i guasti critici e passare automaticamente il sistema a un server ridondante.
Come potete vedere, ogni parte del sistema HA lavora con/per più di uno dei tre principi dell’ingegneria dell’alta disponibilità. I nodi di dati ridondanti (fisici e virtuali) riducono i singoli punti di errore e creano punti di crossover affidabili.
Un server SQL dedicato crea un altro livello di ridondanza, un’altra guardia contro i singoli punti di errore, e ha punti di crossover incorporati e automatizzati.
Infine, Heartbeat siede al centro dell’intera configurazione, monitorando il sistema in tempo reale e automatizzando i crossover quando necessario.
Con un sistema HA di qualità in atto, i tempi di inattività sono ridotti o virtualmente eliminati, mantenendo il vostro business attivo e operativo tutto il giorno, tutti i giorni.