Condividi tramite

Considerazioni sulla continuità aziendale e sul ripristino di emergenza per Red Hat Enterprise Linux in Azure

  • Articolo

Questo articolo descrive come migliorare la continuità aziendale e la preparazione del ripristino di emergenza (BCDR) per un ambiente basato su Red Hat Enterprise Linux (RHEL) in Azure. Fornisce raccomandazioni che è possibile usare per supportare i carichi di lavoro RHEL e per distribuire i componenti di gestione della piattaforma RHEL. La sottoscrizione di Red Hat Management contiene componenti della piattaforma che consentono di gestire i carichi di lavoro in una o più zone di destinazione RHEL. Questi componenti offrono configurazioni BCDR personalizzate.

Considerazioni relative alla progettazione

Implementare le considerazioni seguenti per migliorare la resilienza dei carichi di lavoro RHEL.

Obiettivi del tempo di ripristino

Un obiettivo del tempo di ripristino (RTO) è il tempo necessario per il ripristino dello stato originale del sistema dopo un'emergenza. L'obiettivo RTO include il tempo necessario per:

  • Ripristinare le funzionalità minime alle macchine virtuali e alle applicazioni.
  • Ripristinare i dati richiesti dall'applicazione.

In termini aziendali, l'obiettivo RTO rappresenta la quantità di tempo in cui i processi aziendali sono fuori servizio. Un RTO basso è ideale per carichi di lavoro cruciali in modo che i processi aziendali possano riprendere rapidamente. Per i carichi di lavoro con priorità più bassa, un RTO superiore potrebbe non avere un effetto significativo sulle prestazioni aziendali.

Obiettivi del punto di ripristino

Per gestire correttamente un ambiente cloud, è necessario implementare backup, replica o entrambi per proteggere i dati da errori. L'obiettivo del punto di ripristino (RPO) si riferisce all'ultima volta in cui sono stati acquisiti i dati. Quando un sistema non riesce, è possibile ripristinarlo solo nel punto di ripristino più recente.

Si misura l'RPO dal punto di ripristino più recente al momento in cui si verifica un'interruzione. Se si misura l'RPO in ore, un errore di sistema causa la perdita di dati per le ore tra l'ultimo punto di ripristino e l'interruzione. Se si misura l'RPO in giorni, un errore di sistema causa la perdita di dati per i giorni tra l'ultimo punto di ripristino e l'interruzione. Un RPO di un giorno comporta teoricamente la perdita di tutte le transazioni nel giorno che porta all'errore.

Per i sistemi cruciali, misurare l'RPO in pochi minuti o secondi per evitare perdite di ricavi o profitti. Un RPO breve comporta in genere un aumento dei costi di gestione. Per ridurre questi costi, è necessario creare una linea di base di gestione incentrata sul rpo accettabile più lungo. È quindi possibile ridurre l'RPO delle piattaforme o dei carichi di lavoro specifici che garantiscono un maggiore investimento.

Considerazioni sul bcdr del carico di lavoro

Le considerazioni sulla progettazione per la disponibilità elevata e il ripristino di emergenza per i carichi di lavoro basati su RHEL dipendono dalle tecnologie che supportano tali carichi di lavoro. Molti carichi di lavoro moderni possono sfruttare i vantaggi dei servizi nativi di Azure per fornire ridondanza tra zone di disponibilità e aree diverse. Usare i servizi di Azure per gestire la replica dei dati, ridimensionare automaticamente i set di disponibilità e controllare i domini di aggiornamento e di errore. Queste procedure semplificano la disponibilità delle distribuzioni RHEL.

Le soluzioni di database e altre applicazioni con stato potrebbero richiedere soluzioni incentrate sul sistema operativo per offrire disponibilità elevata e ripristino di emergenza. Rivolgersi allo sviluppatore di applicazioni o al fornitore per verificare le soluzioni supportate dalle applicazioni. Per altre informazioni, vedere Disponibilità elevata e ripristino di emergenza per le app IaaS.

Funzionalità o servizio di Azure Definizione Considerazioni
Aree geografiche Un gruppo di data center che si trovano vicini l'uno all'altro per fornire ritardi di rete ridotti. Per garantire un trasferimento rapido dei dati, una rete a livello di area specifica connette i data center. Quando si sceglie un'area di Azure, prendere in considerazione la posizione dei data center, degli utenti e dei dati back-end. Controllare la disponibilità dei servizi necessari nelle aree selezionate. Per le distribuzioni RHEL, potrebbe essere necessario avviare un'area e quindi aggiungere altre aree in futuro per scopi BCDR.
Azure ExpressRoute Un servizio di Azure che è possibile usare per stabilire connessioni private dai data center Microsoft alla propria infrastruttura o a una struttura di condivisione. ExpressRoute ignora la rete Internet pubblica e fornisce una connessione privata dedicata. Questa configurazione è un requisito comune per le distribuzioni RHEL su larga scala. ExpressRoute è un servizio condiviso, quindi è necessario pianificare attentamente la capacità della larghezza di banda per soddisfare le esigenze complessive di larghezza di banda dell'azienda.

Se la larghezza di banda non è sufficiente, è possibile compromettere l'esperienza utente o l'accesso ai servizi critici nel data center. Assicurarsi di distribuire ExpressRoute in modo resiliente tra aree e località di peering.
Zone di disponibilità Separare gruppi di data center con sistemi di alimentazione, raffreddamento e rete personalizzati all'interno di un'area di Azure. Le zone di disponibilità offrono disponibilità elevata e resilienza agli errori del data center. Per garantire un contratto di servizio elevato, usare le zone di disponibilità con l'infrastruttura RHEL, quando possibile. Le zone di disponibilità offrono ridondanza del data center all'interno di un'area. Ma non tutte le aree hanno zone di disponibilità, quindi è necessario pianificare attentamente. I servizi RHEL, ad esempio Azure Red Hat OpenShift e i servizi di gestione della zona di destinazione, supportano le zone di disponibilità.
Set di disponibilità Raggruppamento logico di macchine virtuali. Almeno una macchina virtuale è sempre attiva e in esecuzione durante gli eventi di manutenzione pianificati o non pianificati. Un dominio di errore è un subset di un set di disponibilità che condivide un'infrastruttura fisica comune, ad esempio alimentazione o rete. Quando si distribuiscono macchine virtuali in domini di errore diversi, un set di disponibilità riduce l'impatto degli errori hardware sulla disponibilità della macchina virtuale. I set di disponibilità offrono un contratto di servizio elevato. I set di disponibilità sono adatti per un'infrastruttura RHEL quando un'area non dispone di zone di disponibilità. I set di disponibilità hanno solo ridondanza hardware, simile alle regole anti-affinità dell'hypervisor. Pertanto, se le aree non dispongono di zone di disponibilità, è necessaria una strategia multiregione per data center e ridondanza geografica.
Azure Load Balancer Servizio di bilanciamento del carico di rete. È possibile configurare Load Balancer per fornire traffico di rete a volumi elevati in modo efficiente tra più server Red Hat Enterprise. Il servizio opera a bassa latenza e velocità effettiva elevata, migliorando le prestazioni e la disponibilità delle applicazioni.

Load Balancer può essere ridimensionato automaticamente in base alla domanda. Per promuovere una distribuzione ibrida delle applicazioni, Load Balancer può distribuire il traffico di rete tra più aree in Azure e anche tra ambienti locali e Azure.		 Load Balancer distribuisce il traffico di rete tra più server per garantire una disponibilità ininterrotta delle applicazioni e prevenire errori a singolo punto. In caso di emergenza, Load Balancer reindirizza il traffico ai server operativi per fornire un failover e un ripristino rapidi. Questa operazione riduce al minimo i tempi di inattività e gestisce le operazioni aziendali.

Load Balancer può bilanciare il traffico tra server locali verso il cloud di Azure o verso i server in più aree di Azure. Per altre informazioni, vedere Opzioni di bilanciamento del carico.
Dischi gestiti Dischi virtualizzati gestiti da Azure. Scegliere le dimensioni e il tipo del disco. Azure distribuisce i dischi tra varie unità di archiviazione per proteggere i dati da errori hardware. I dischi gestiti sono la scelta migliore per tutte le infrastrutture RHEL. Non usare dischi non gestiti. Per altre informazioni, vedere Contratti di servizio per le macchine virtuali.

Diversi tipi di dischi hanno prestazioni e costi diversi. Per i computer dell'infrastruttura RHEL, è consigliabile usare l'unità SSD Premium di Azure. Prendere in considerazione costi, prestazioni e disponibilità quando si sceglie il tipo di disco. Quando si dealloca un sistema, vengono rimossi dischi SSD locali e temporanei. Eseguire il backup dei dati in questi dischi in base alle esigenze.
Backup di Azure Un servizio che offre soluzioni convenienti per eseguire il backup dei dati e recuperarli dal cloud di Azure. Il backup è una soluzione affidabile e conveniente che protegge l'infrastruttura RHEL da errori o danneggiamenti delle macchine virtuali. Usare Backup per ripristinare facilmente l'intera macchina virtuale o file e cartelle specifici dal cloud, senza dover ricreare la macchina virtuale o perdere dati. È anche possibile usare altre soluzioni partner supportate.
Azure Arc Piattaforma che estende i servizi di Azure in modo che vengano eseguiti in ambienti diversi, inclusi data center, dispositivi perimetrali e architetture multicloud. Usare Azure Arc per offrire funzionalità di sviluppo, operazioni e gestione della sicurezza coerenti per applicazioni e servizi. Usare Azure Arc per implementare backup e monitoraggio automatizzati centralizzati, aumentando la resilienza dal punto di vista bcdr.
Azure Site Recovery Servizio che fornisce funzionalità di ripristino di emergenza per garantire la continuità aziendale. È possibile replicare e gestire i carichi di lavoro, incluse le macchine virtuali di Azure e le macchine virtuali locali, in aree diverse. Con Site Recovery è possibile configurare processi di replica, failover e ripristino per proteggere le applicazioni durante interruzioni pianificate e interruzioni non pianificate. Usare Site Recovery per ridurre al minimo i problemi di ripristino, ridurre i costi dell'infrastruttura e garantire un ripristino sicuro e affidabile tra aree di Azure o da posizioni locali ad Azure.
Blocchi di risorse Funzionalità di Azure che è possibile usare per limitare utenti e ruoli nell'organizzazione. Proteggere le risorse critiche da modifiche accidentali o dannose. È possibile bloccare una risorsa a vari livelli di ambito, ad esempio sottoscrizione, gruppo di risorse o singoli livelli di risorse. A seconda del tipo di blocco, è possibile impedire agli utenti di eliminare o modificare una risorsa, ma possono comunque leggerne la configurazione. Per proteggere tutte le macchine virtuali di infrastruttura RHEL e delle immagini d'uso, usare i blocchi delle risorse. Per evitare la perdita accidentale di computer importanti, applicare almeno il blocco Elimina . Applicare il blocco ReadOnly ai computer dell'infrastruttura RHEL perché non cambiano spesso. Apportare modifiche solo durante le finestre di controllo delle modifiche appropriate.

Considerazioni sulla piattaforma RHEL BCDR

Per altre informazioni sulle funzionalità BCDR per un'infrastruttura della piattaforma RHEL, vedere:

Suggerimenti per la progettazione

Per le applicazioni native del cloud nei contenitori Linux, usare una piattaforma basata su Kubernetes per garantire scalabilità, disponibilità elevata e ridondanza. Prendere in considerazione l'uso della piattaforma Azure Red Hat OpenShift o di una distribuzione OpenShift autogestito con l'archiviazione replicata o con replica geografica.

Per le applicazioni front-end native dell'applicazione Web e senza stato, è possibile usare molti dei servizi nativi di Azure che forniscono la disponibilità delle applicazioni. Per le architetture che usano tali servizi, vedere:

Le architetture precedenti usano vari servizi di Azure per le zone di disponibilità. L'architettura multiregione usa le funzionalità di replica geografica per il contenuto e Frontdoor di Azure come servizio di bilanciamento del carico.

Per molte applicazioni tradizionali con stato che richiedono disponibilità elevata, RHEL offre il componente aggiuntivo Pacemaker a disponibilità elevata. È possibile ottenere sistemi con questa funzionalità da Azure Marketplace oppure distribuire un'immagine personalizzata con i componenti software necessari incorporati. Per altre informazioni, vedere Configurare un cluster a disponibilità elevata di Red Hat in Microsoft Azure.

I problemi di disponibilità influiscono sulle interruzioni del servizio e sui tempi di risposta del servizio. Può verificarsi una riduzione delle prestazioni del servizio, che potrebbe compromettere l'esperienza del servizio del cliente. Per assicurarsi di mantenere i livelli di prestazioni e una capacità sufficiente all'interno delle aree necessarie, usare la funzionalità di prenotazione della capacità su richiesta di Azure.

Affidabilità

Molti dei concetti che si applicano alle infrastrutture di macchine virtuali di infrastruttura distribuita come servizio si applicano anche alle architetture RHEL. Per altre informazioni, vedere Principi di progettazione dell'affidabilità.

Clusters (Cluster)

Azure non supporta la combinazione di Servizi centrali server applicazioni e disponibilità elevata del database all'interno di un singolo cluster RHEL Pacemaker. Per risolvere questa limitazione, separarli in singoli cluster. È possibile combinare fino a cinque cluster di servizi centrali in una coppia di macchine virtuali.

Per BCDR in SAP, considerare i servizi seguenti per eseguire cluster di servizi centrali SAP:

  • Cluster RHEL Pacemaker: i dispositivi a blocchi STONITH non sono supportati, ma è possibile basarsi sull'agente di isolamento di Azure.
  • Software cluster non Microsoft certificato SAP: esplorare questa opzione se è conforme ai requisiti.

Scegliere il servizio appropriato in base alle esigenze specifiche e al sistema operativo.

Per altre informazioni, vedi:

È possibile usare La raccolta di calcolo per archiviare immagini d'oro per le distribuzioni. Usare queste immagini per il ripristino di emergenza di applicazioni e strumenti. La raccolta di calcolo può usare risorse a disponibilità elevata con account di archiviazione con ridondanza della zona nelle aree che supportano le zone di disponibilità. L'archiviazione con ridondanza della zona offre resilienza rispetto agli errori di zona. È anche possibile replicare le immagini della raccolta in altre aree o aree geografiche.

Nota

È consigliabile disporre di almeno due raccolte in aree diverse.

Site Recovery

Site Recovery può migliorare la resilienza di alcuni componenti RHEL. Per un elenco dei server di ripristino del sito RHEL supportati, vedere Matrice di supporto per il ripristino di emergenza delle macchine virtuali di Azure con Site Recovery. È anche possibile configurare Site Recovery come failover da ambienti locali al cloud. Per ottenere una stima dei costi di Site Recovery, usare Site Recovery Deployment Planner.

Nodi del cluster di ripristino

Per ridurre gli oggetti RTO e aumentare la resilienza, è possibile usare nodi del cluster di ripristino remoto attivo o di standby. È necessario configurare manualmente gli elementi del cluster di ripristino di emergenza. Ad esempio, è necessario applicare configurazioni per configurare le risorse e copiare i dati.

Passaggi successivi