OpenStack è una piattaforma open source per il cloud computing la cui architettura include servizi di calcolo, storage e rete, fornendo potenti capacità di virtualizzazione e funzioni di gestione automatizzata. Per garantire l'alta disponibilità della piattaforma OpenStack, è necessario adottare alcune soluzioni architetturali e misure tecniche. Questo articolo illustrerà alcune comuni soluzioni architetturali per l'alta disponibilità di OpenStack.
OpenStack High Availability
Per comprendere come raggiungere la disponibilità elevata, è fondamentale identificare quali servizi sono soggetti a mancata disponibilità. Innanzitutto, acquisiamo una comprensione di base della struttura di OpenStack.
OpenStack è composto da cinque componenti principali: Compute (Nova), Identity Management (Keystone), Image Management (Glance), Front-end Management (Dashboard) e Object Storage (Swift).
Nova è il componente principale responsabile del calcolo e del controllo. Include servizi come nova-compute, nova-scheduler, nova-volume, nova-network e nova-api. Come la maggior parte degli altri sistemi distribuiti, OpenStack è diviso in due tipi di nodi: nodi di controllo e nodi di calcolo. I nodi di controllo forniscono tutti i servizi tranne nova-compute. Questi componenti e servizi possono essere installati in modo indipendente e si possono scegliere le combinazioni desiderate.
Nova-compute viene eseguito su ogni nodo di calcolo. Per ora, supponiamo che sia affidabile; in caso contrario, una macchina di backup può essere utilizzata per il failover (sebbene configurare un backup per ogni nodo di calcolo possa risultare troppo costoso rispetto ai benefici).
Alta disponibilità del nodo di controllo
Garantire l'alta disponibilità del nodo di controllo è la sfida principale, e diversi componenti hanno requisiti e soluzioni specifici per la disponibilità.
(1) Che cosa succede se il nodo di controllo smette di funzionare, considerando che esiste un solo nodo di controllo che gestisce e controlla l'intero sistema?
Questo è il comune problema del single point of failure (SPoF). L'alta disponibilità non può essere raggiunta utilizzando una singola macchina. Spesso, una soluzione viene progettata per garantire un rapido subentro della macchina in caso di guasti, sebbene questo comporti costi aggiuntivi.
Per risolvere il problema del singolo punto, la soluzione tipica consiste nell'utilizzare dispositivi ridondanti o in standby caldo. Dal momento che guasti hardware o errori umani possono sempre causare guasti a uno o più nodi, e la manutenzione o gli aggiornamenti richiedono talvolta di arrestare temporaneamente alcuni nodi, un sistema affidabile deve essere in grado di sopportare l'arresto di uno o più nodi.
Le modalità di distribuzione comuni includono: modalità standby attivo-passivo, modalità attivo-attivo e modalità cluster
(2) Come costruire nodi di controllo ridondanti? O quali altri metodi possono garantire un controllo molto affidabile?
Molti potrebbero considerare l'implementazione di una modalità attiva-passiva, utilizzando un meccanismo heartbeat o metodi simili per il backup, e raggiungere un'elevata disponibilità tramite failover. OpenStack non supporta in modo nativo più nodi di controllo, quindi Pacemaker richiede che vari servizi implementino da soli i propri meccanismi di backup, monitoraggio e commutazione.
Un'analisi più approfondita dei servizi forniti dal nodo di controllo mostra che questi includono principalmente nova-api, nova-network, nova-scheduler, nova-volume, così come Glance, Keystone e il database MySQL. Questi servizi vengono forniti separatamente. Nova-api, nova-network e Glance possono essere eseguiti su ciascun nodo di calcolo, RabbitMQ può operare in modalità primaria-standby e MySQL può utilizzare un cluster ridondante ad alta disponibilità.
Le seguenti sezioni descrivono in dettaglio questi componenti.
Soluzioni di Alta Disponibilità per Componenti Chiave
1) Alta Disponibilità di nova-api e nova-scheduler
Ogni nodo di calcolo può eseguire la propria istanza di nova-api e nova-scheduler, garantendo il bilanciamento del carico per un corretto funzionamento. In questo modo, quando il nodo di controllo non è disponibile, l'api nova e i servizi correlati sui nodi di calcolo continuano a funzionare normalmente.
2) Alta disponibilità di nova-volume
Attualmente, non esiste una soluzione HA perfetta per nova-volume e sono necessari ulteriori lavori. Tuttavia, dal momento che nova-volume è basato su iSCSI, è possibile ottenere alta disponibilità integrandolo con DRBD o utilizzando una soluzione hardware ad alta disponibilità basata su iSCSI.
3) Alta disponibilità dei servizi di rete (nova-network)
OpenStack fornisce già molteplici soluzioni di rete ad alta disponibilità. Un approccio comunemente utilizzato è abilitare la modalità ad alta disponibilità tramite l'opzione "Multi-host". Altre soluzioni comuni includono Failover, Multi-nic, Gateway hardware e Quantum.
4) Alta disponibilità di Glance e Keystone
Le immagini OpenStack possono essere memorizzate utilizzando Swift e Glance può essere eseguito su più host. Pacemaker è una potente soluzione per l'alta disponibilità per la gestione di cluster multi-node, che implementa il passaggio da un servizio all'altro e il failover, ed è utilizzabile con Corosync e Heartbeat. Pacemaker supporta flessibilmente diverse modalità, come attivo-passivo, N+1 e N-N. Installando l'agente OCF su ogni nodo, è possibile verificare se gli altri nodi stanno eseguendo correttamente i servizi Glance e Keystone, aiutando Pacemaker ad avviare, arrestare e monitorare questi servizi.
5) Alta disponibilità dell'archiviazione oggetti Swift
Generalmente, il sistema di storage oggetti distribuito di OpenStack, Swift, non richiede configurazioni aggiuntive di HA. Questo perché Swift è progettato con un'architettura distribuita (senza un nodo master), meccanismi di tolleranza ai guasti, ridondanza, recupero dei dati, scalabilità e alta disponibilità.
6) Alta disponibilità del servizio Message Queue (RabbitMQ)
Se RabbitMQ non funziona, i messaggi potrebbero andare persi. Possono essere utilizzati diversi meccanismi di HA:
Il metodo confirm dell'editore notifica quando i dati vengono scritti su disco in caso di errore.
Il meccanismo cluster multi-nodo può essere utilizzato, ma i guasti ai nodi possono comunque causare guasti alle code.
La modalità attiva-passiva garantisce il failover in caso di guasto, ma l'avvio del nodo di backup potrebbe comportare ritardi o addirittura errori.
Per il ripristino da disastri e la disponibilità, RabbitMQ fornisce code persistenti che memorizzano i messaggi non elaborati su disco nel caso in cui il servizio della coda si arresti. Per prevenire la perdita di messaggi a causa dei ritardi tra l'invio e la scrittura dei messaggi, RabbitMQ introduce il meccanismo Publisher Confirm per garantire che i messaggi vengano effettivamente scritti su disco.
Per il supporto dei cluster, RabbitMQ offre modalità Active/Passive e Active/Active. Ad esempio, in modalità Active/Passive, quando un nodo fallisce, il nodo passivo viene immediatamente attivato e sostituisce rapidamente il nodo attivo guasto per continuare a gestire la consegna dei messaggi.
Costruire un OpenStack ad alta disponibilità
In generale, l'alta disponibilità si ottiene stabilendo ridondanza e backup. Le strategie comuni includono:
Modalità cluster. Backup reciproco tra più macchine, in cui ogni istanza è replicata più volte senza un nodo centrale. Esempi includono il sistema di storage oggetti distribuito Swift e la modalità multi-host di nova-network.
Modalità autonoma. In alcuni casi, il problema SPoF può essere risolto consentendo a ogni nodo di operare in modo indipendente, eliminando le relazioni master-slave per ridurre l'impatto di un nodo di controllo guasto. Ad esempio, nova-api è responsabile soltanto del proprio nodo.
Modalità attiva-passiva. Questo modello comune prevede un nodo passivo che rimane in stato di standby e backup, attivandosi in caso di guasto. Esempi includono cluster MySQL ad alta disponibilità e servizi come Glance e Keystone, che raggiungono la ridondanza attraverso Pacemaker e Heartbeat.
Modalità attivo-attivo. In questa modalità, i nodi si supportano e si replicano reciprocamente. Ad esempio, RabbitMQ utilizza un cluster ad alta disponibilità in modalità attivo-attivo, dove i nodi del cluster possono replicare le code. Da un punto di vista architetturale, questo approccio elimina le preoccupazioni riguardo ai nodi passivi che non riescono ad avviarsi o che presentano ritardi eccessivi.
In sintesi, l'ottimizzazione e i miglioramenti di OpenStack sono in continua evoluzione e il suo utilizzo e applicazioni vengono ulteriormente esplorati e sviluppati. Il tuning pratico è essenziale: buone idee e progetti necessitano di essere testati nel mondo reale per essere convalidati.
Protezione avanzata di OpenStack
Anche se OpenStack riduce il rischio di guasti singoli grazie all'architettura ridondata e ad alta disponibilità, la protezione dei dati rimane essenziale. Per garantire la continuità operativa, è necessario adottare una soluzione professionale di backup per prevenire la perdita di dati e l'impatto di guasti catastrofici.
Vinchin Backup & Recovery è una solida soluzione di backup per OpenStack che offre backup efficienti e senza agenti, con funzionalità come deduplicazione dei dati, compressione, backup incrementali, recupero a livello di file e archivio cloud, ecc. Garantisce un rapido recupero, un'integrazione perfetta con OpenStack e una forte sicurezza dei dati, rendendola la scelta ideale per gestire e proteggere ambienti cloud.
Oltre a ciò, la crittografia dei dati e la protezione contro il ransomware offrono una doppia garanzia per proteggere i backup delle tue macchine virtuali OpenStack. Puoi anche semplicemente trasferire i dati da un host OpenStack ad un'altra piattaforma virtuale (come VMware, Hyper-V, Proxmox, XenServer, oVirt, AWS EC2...) e viceversa.
Per eseguire il backup delle VM OpenStack con Vinchin Backup & Recovery sono sufficienti i seguenti 4 passaggi:
1. Selezionare l'oggetto di backup.
2. Seleziona destinazione backup.
3. Configura le strategie di backup.
4. Rivedi e invia il lavoro.
Vinchin Backup & Recovery è affidato da migliaia di aziende. Inizia oggi la tua prova completa di 60 giorni!
Domande frequenti sull'high availability di OpenStack
1. Cos'è una zona di disponibilità in OpenStack?
In OpenStack, una zona di disponibilità (AZ) è una partizione logica all'interno di un ambiente cloud che aiuta a distribuire i carichi di lavoro per migliorare la tolleranza ai guasti e la gestione delle risorse. Ogni AZ è un dominio di guasto isolato, il che significa che le istanze presenti in diverse AZ sono meno soggette a essere influenzate dagli stessi guasti hardware o di rete. Le AZ vengono generalmente utilizzate per raggruppare nodi di calcolo, mentre i servizi di archiviazione e rete possono disporre anch'essi di proprie zone per garantire maggiore resilienza e ridondanza. Gli utenti possono specificare un'AZ durante l'avvio delle istanze al fine di ottimizzare le prestazioni e l'affidabilità.
2. OpenStack è un SAAS o un PaaS?
OpenStack è principalmente una piattaforma IaaS. Fornisce risorse di calcolo, storage e rete virtualizzate, permettendo agli utenti di distribuire e gestire infrastrutture cloud. Sebbene OpenStack possa supportare soluzioni PaaS eseguendo servizi come Kubernetes o Cloud Foundry sopra, la sua funzione principale è fornire IaaS, non SaaS o PaaS.
Conclusione
Garantire un'elevata disponibilità in OpenStack richiede una combinazione di strategie architetturali e soluzioni tecniche per eliminare i singoli punti di guasto e migliorare la resilienza del sistema. Implementando modalità attivo-passivo e attivo-attivo, sfruttando tecniche di clustering e ottimizzando componenti chiave come Nova, Glance, Keystone e RabbitMQ, OpenStack può raggiungere un'infrastruttura cloud tollerante ai guasti e altamente affidabile. In aggiunta, soluzioni di storage distribuite come Swift forniscono in modo intrinseco ridondanza e resilienza.
