Linee guida sulla linea di base delle operazioni per Azure Red Hat OpenShift

  • Articolo

Azure Red Hat OpenShift offre cluster OpenShift altamente scalabili e completamente gestiti su richiesta. Progettando correttamente la soluzione con gestione e monitoraggio, è possibile lavorare per l'eccellenza operativa e il successo dei clienti.

Considerazioni relative alla progettazione

Prendere in considerazione i seguenti fattori:

  • Esaminare la matrice di responsabilità di Azure Red Hat OpenShift per comprendere in che modo le responsabilità per i cluster sono condivise tra Microsoft, Red Hat e i clienti.
  • Tenere presente i limiti delle macchine virtuali di Azure e le aree supportate. Assicurarsi che sia disponibile la capacità per distribuire le risorse.
  • Considerare le soluzioni per isolare i carichi di lavoro dal punto di vista logico all'interno di un cluster e dal punto di vista fisico in cluster separati.
  • Considerare le soluzioni per consentire a Kubernetes di conoscere lo stato di integrità dei carichi di lavoro.
  • Tenere presente le varie dimensioni delle macchine virtuali e l'effetto dell'uso di uno o dell'altro.
  • Tenere presente i modi per monitorare e registrare Azure Red Hat OpenShift per ottenere informazioni dettagliate sull'integrità delle risorse e per prevedere potenziali problemi. Sia il cluster che le applicazioni in esecuzione in alto possono generare molti eventi. Usare avvisi per distinguere le voci di log per scopi cronologici e voci che richiedono un'azione immediata.
  • Tenere presente gli aggiornamenti e gli aggiornamenti di sistema importanti. Gli aggiornamenti delle patch critici vengono applicati automaticamente ai cluster dagli ingegneri dell'affidabilità del sito di Azure Red Hat OpenShift (SRE). I clienti che desiderano installare gli aggiornamenti delle patch in anticipo sono liberi di farlo.
  • Tenere presente le limitazioni delle risorse del cluster e dei singoli carichi di lavoro.
  • Tenere presente le differenze tra scalabilità automatica dei pod orizzontali e scalabilità automatica del cluster.
  • Esaminare il ciclo di vita del supporto e comprendere i criteri di supporto della versione. Azure Red Hat OpenShift supporta solo le versioni secondarie correnti e precedenti disponibili a livello generale di Red Hat OpenShift Container Platform. Le richieste di supporto richiedono che il cluster sia all'interno di una versione supportata.
  • Esaminare i requisiti di configurazione del cluster per mantenere la supportabilità del cluster.
  • Esaminare la rete tra spazi dei nomi per proteggere il traffico all'interno del cluster usando i criteri di rete.

Suggerimenti per la progettazione

  • Azure Red Hat OpenShift ha un ecosistema di operatore avanzato e deve essere usato per eseguire e automatizzare le attività operative con efficienza e accuratezza.
  • Aggiungere probe di integrità ai pod per monitorare l'integrità dell'applicazione. Assicurarsi che i pod contengano livenessProbe e idoneitàProbe. Usare i probe di avvio per determinare il punto in cui è stata avviata l'applicazione.
  • Usare le dimensioni delle macchine virtuali sufficienti per contenere più istanze di contenitori in modo da ottenere i vantaggi di una maggiore densità, ma non così grande che il cluster non possa gestire il carico di lavoro di un nodo con esito negativo.
  • Regolare le funzioni del cluster usando plug-in di ammissione, che vengono comunemente usati per applicare i criteri di sicurezza, le limitazioni delle risorse o i requisiti di configurazione.
  • Usare richieste pod e limiti per gestire le risorse di calcolo all'interno di un cluster. Le richieste e i limiti dei pod informano l'utilità di pianificazione Kubernetes, che assegna le risorse di calcolo a un pod. Limitare l'utilizzo delle risorse in un progetto usando intervalli di limiti.
  • Ottimizzare i valori delle richieste di CPU e memoria e ottimizzare l'efficienza delle risorse del cluster usando scalabilità automatica dei pod verticali.
  • La console Web OpenShift contiene tutte le metriche a livello di nodo. Stabilire un processo di monitoraggio usando l'integrazione predefinita di Prometheus o Container Insights.
    • Prometheus è preinstallato e configurato per i cluster Azure Red Hat OpenShift 4.x.
    • Container Insights può essere abilitato eseguendo l'onboarding del cluster in Kubernetes abilitato per Azure Arc.
    • La registrazione di OpenShift distribuisce gli aggregatori di log, l'archiviazione e i componenti di visualizzazione.
  • Automatizzare il processo di recapito dell'applicazione tramite le procedure DevOps e le soluzioni CI/CD, ad esempio Pipelines/GitOps fornite da OpenShift Container Platform.
  • Definire ClusterAutoScaler e MachineAutoScaler per ridimensionare i computer quando il cluster esce dalle risorse per supportare più distribuzioni.
  • Distribuire controlli di integrità del computer per ripristinare automaticamente i computer danneggiati in un pool di computer.
  • Ridimensionare i pod per soddisfare la domanda usando la scalabilità automatica orizzontale dei pod.
  • Usare un sistema di avvisi per fornire notifiche quando sono necessarie azioni dirette: avvisi delle metriche di Container Insights o interfaccia utente predefinita degli avvisi.

Continuità aziendale e ripristino di emergenza (BCDR)

L'organizzazione deve progettare funzionalità appropriate a livello di piattaforma Di Azure Red Hat OpenShift per soddisfare i requisiti specifici. Questi servizi dell'applicazione hanno requisiti correlati all'obiettivo del tempo di ripristino (RTO) e all'obiettivo del punto di ripristino (RPO). Esistono più considerazioni da affrontare per il ripristino di emergenza. Il primo passaggio consiste nel definire un contratto di servizio per l'infrastruttura e l'applicazione. Informazioni sul contratto di servizio per Azure Red Hat OpenShift. Per informazioni sul calcolo del tempo di attività mensile, vedere la sezione Dettagli del contratto di servizio.

Considerazioni sulla progettazione per BCDR

Prendere in considerazione i seguenti fattori:

  • Il cluster Azure Red Hat OpenShift deve usare più set di computer per fornire il livello minimo di disponibilità per l'applicazione.
  • Impostare limiti e richieste di pod. L'impostazione di questi limiti consente a Kubernetes di:
    • Assegnare in modo efficiente le risorse di CPU e memoria ai pod.
    • Avere una maggiore densità di contenitori in un nodo.
    • Aumentare l'affidabilità con costi ridotti a causa di un uso migliore dell'hardware.
  • Distribuire i nodi in tutte le zone disponibili per una disponibilità maggiore.
    • Scegliere un'area che supporta la funzionalità Zone di disponibilità.
    • Per ottenere un vantaggio completo dalle zone, anche tutte le dipendenze del servizio devono supportare le zone. Se un servizio dipendente non supporta le zone, è possibile che un errore di zona possa causare un errore del servizio. Esaminare i tipi di disco usati durante la distribuzione del carico di lavoro tra le zone.
    • Per maggiore disponibilità oltre a ciò che zone di disponibilità può ottenere, eseguire più cluster in aree associate diverse. Se una risorsa di Azure supporta la ridondanza geografica, specificare la posizione in cui il servizio ridondante avrà la propria area secondaria.
  • Creare in modo coerente backup per applicazioni e dati.
    • Un servizio senza stato può essere replicato in modo efficiente.
    • Se è necessario archiviare lo stato nel cluster, eseguire spesso il backup dei dati nell'area abbinata.
  • Aggiornare e gestire i cluster.
  • Per la connettività di rete se si verifica un failover:
    • Se è necessario distribuire il traffico tra aree, è consigliabile usare il servizio Frontdoor di Azure.
  • Per i failover pianificati e non pianificati:
    • Quando si configura un servizio di Azure, scegliere le funzionalità che supportano il ripristino di emergenza. Ad esempio, se Registro Azure Container viene scelto, abilitarlo per la replica geografica. Se un'area diventa non disponibile, è comunque possibile eseguire il pull delle immagini dall'area replicata.
  • Gestire le funzionalità DevOps di progettazione per raggiungere gli obiettivi a livello di servizio.

Consigli di progettazione per BCDR

Di seguito sono riportate le procedure consigliate per la progettazione:

  • I cluster Di Azure Red Hat OpenShift vengono con provisioning con tre nodi del piano di controllo e tre o più nodi di lavoro. Assicurarsi che il cluster venga creato in un'area che supporti zone di disponibilità in modo che i nodi vengano distribuiti tra le zone.
  • Per la disponibilità elevata, distribuire questi nodi in zone di disponibilità diversi. Poiché sono necessari set di computer diversi per ogni zona di disponibilità, creare almeno tre set di computer.
  • Non eseguire carichi di lavoro aggiuntivi nei nodi del piano di controllo. Anche se possono essere pianificati nei nodi del piano di controllo, causerà problemi di utilizzo e stabilità delle risorse aggiuntivi che possono influire sull'intero cluster.
  • Creare set di computer di infrastruttura per contenere i componenti dell'infrastruttura. Applicare etichette Kubernetes specifiche a questi computer e quindi aggiornare i componenti dell'infrastruttura da eseguire solo in tali computer.
  • Quando possibile, rimuovere lo stato del servizio dall'interno dei contenitori. In alternativa, usare una soluzione PaaS (piattaforma distribuita come servizio) che supporta la replica in più aree.
  • Le distribuzioni devono specificare i requisiti delle risorse pod. L'utilità di pianificazione può quindi pianificare in modo appropriato il pod. L'affidabilità si riduce in modo significativo quando i pod non sono pianificati.
  • Configurare più repliche nella distribuzione per gestire le interruzioni, ad esempio gli errori hardware. Per gli eventi pianificati, come gli aggiornamenti, un budget per le interruzioni può garantire che esista il numero necessario di repliche di pod per gestire il carico previsto dell'applicazione.
  • Usare i vincoli di topologia dei pod per pianificare automaticamente i pod nei nodi in tutto il cluster.
  • Le applicazioni potrebbero usare l'archiviazione per i dati e garantire la disponibilità tra aree, se necessario:
  • Creare il backup dell'applicazione e pianificare il ripristino:
  • Stimare i limiti delle risorse dei pod. Testare e stabilire una baseline. Iniziare con valori uguali per le richieste e i limiti. Quindi, regolare gradualmente tali valori fino a quando non viene stabilita una soglia che può causare instabilità nel cluster. I limiti dei pod possono essere specificati nei manifesti della distribuzione. Il ridimensionamento automatico verticale dei pod ottimizza i valori delle richieste di CPU e memoria e consente di ottimizzare l'efficienza delle risorse del cluster.
    • Le funzionalità predefinite possono gestire errori e interruzioni nell'architettura del servizio. Queste configurazioni consentono di semplificare l'automazione della progettazione e della distribuzione. Quando un'organizzazione definisce uno standard per il contratto di servizio, l'RTO e l'RPO, può usare i servizi integrati in Kubernetes e Azure per raggiungere gli obiettivi aziendali.
  • Prendere in considerazione strategie blu/verde o canary per distribuire nuove versioni dell'applicazione.
  • Impostare budget di interruzione della priorità/pod per limitare il numero di repliche di pod che il cluster può arrestare per le operazioni di manutenzione, garantendo così la disponibilità.
  • Applicare le quote di risorse agli spazi dei nomi del servizio. La quota di risorse in uno spazio dei nomi garantisce che le richieste e i limiti dei pod siano impostati correttamente in una distribuzione.
    • L'impostazione delle quote delle risorse a livello di cluster può causare problemi durante la distribuzione di servizi partner che non hanno richieste e limiti adeguati.
  • Archiviare le immagini del contenitore in Registro Azure Container e replicare geograficamente il registro in ogni area.
  • Usare più aree e posizioni di peering per la connettività di Azure ExpressRoute. Se si verifica un'interruzione che interessa un'area di Azure o una posizione del provider di peering, un'architettura di rete ibrida ridondante può garantire una connettività cross-premise senza interruzioni.
  • Interconnettere le aree con il peering di reti virtuali globale. Se i cluster devono comunicare tra loro, la connessione tra entrambe le reti virtuali può essere ottenuta tramite il peering di reti virtuali. Questa tecnologia interconnette le reti virtuali tra loro per fornire una larghezza di banda elevata nella rete backbone di Microsoft, anche in aree geografiche diverse.
  • Usare il protocollo anycast basato su TCP diviso, Frontdoor di Azure, per connettere tempestivamente gli utenti finali al POP frontdoor più vicino (punto di presenza). Altre funzionalità di Frontdoor di Azure includono:
    • Terminazione TLS
    • Dominio personalizzato
    • Web application firewall
    • Riscrittura URL
    • Affinità di sessione

Passaggi successivi

Informazioni sulle considerazioni sulla progettazione e sulle raccomandazioni per l'automazione della piattaforma e DevOps nelle zone di destinazione di Azure.