Linee guida per le operazioni per Azure Red Hat OpenShift

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

Considerazioni sulla progettazione

Prendere in considerazione i fattori seguenti:

  • Esaminare la matrice di responsabilità di Azure Red Hat OpenShift per comprendere in che modo le responsabilità per i cluster vengono 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.
  • Tenere presente i modi per isolare i carichi di lavoro in modo logico all'interno di un cluster e fisicamente in cluster separati.
  • Essere consapevoli dei modi per aiutare Kubernetes a comprendere lo stato di salute dei carichi di lavoro.
  • Tenere presente le varie dimensioni delle macchine virtuali e l'effetto dell'uso di uno o dell'altro.
  • Tenere presenti i modi per monitorare e registrare Azure Red Hat OpenShift per ottenere informazioni dettagliate sull'integrità delle risorse e prevedere potenziali problemi. Sia il cluster che le applicazioni in esecuzione possono generare molti eventi. Usare gli avvisi per distinguere le voci di log per scopi cronologici e voci che richiedono un'azione immediata.
  • Essere consapevoli degli aggiornamenti e potenziamenti importanti del sistema. Gli aggiornamenti critici delle patch 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 la scalabilità automatica orizzontale dei pod e la scalabilità automatica del cluster.
  • Esaminare il ciclo di vita del supporto e comprendere la politica di supporto delle versioni. 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.
  • Rivedere la rete cross-namespace per proteggere il traffico all'interno del cluster usando i criteri di rete.

Consigli per la progettazione

  • Azure Red Hat OpenShift ha un ecosistema di operatori avanzato e deve essere usato per eseguire e automatizzare le attività operative con efficienza e accuratezza.
  • Aggiungere sonde di salute ai pod per monitorare la salute dell'applicazione. Assicurati che i pod contengano i livenessProbe e i readinessProbe. Usare probe di avvio per determinare il punto in cui l'applicazione è stata avviata.
  • Usare le dimensioni delle macchine virtuali sufficienti per contenere più istanze di contenitore, 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 errori.
  • Regolare le funzioni del cluster usando i plug-in di ammissione, comunemente usati per applicare criteri di sicurezza, limitazioni delle risorse o requisiti di configurazione.
  • Usare le richieste e i limiti dei pod per gestire le risorse di calcolo all'interno di un cluster. Le richieste e i limiti dei pod servono per informare lo scheduler di 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 il ridimensionamento automatico verticale dei pod.
  • 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 su Kubernetes abilitato da Azure Arc.
    • OpenShift logging distribuisce aggregatori di log, memorizzazione e componenti di visualizzazione.
  • Automatizzare il processo di distribuzione delle applicazioni tramite procedure DevOps e soluzioni CI/CD, ad esempio Pipeline/GitOps fornite da OpenShift Container Platform.
  • Definire le definizioni di risorse ClusterAutoscaler e MachineAutoscaler per descrivere come modificare il cluster quando le risorse sono insufficienti, in modo da supportare le operazioni continuative. ClusterAutoscaler considera le risorse di tutti i nodi nel cluster, inclusi i nodi del piano di controllo. Quando si aumentano le prestazioni dei nodi del piano di controllo del cluster, si riduce la capacità rimanente per il ridimensionamento automatico dei nodi di lavoro.
  • Implementare i controlli di integrità delle macchine per riparare automaticamente le macchine danneggiate in un pool di macchine.
  • Ridimensionare i pod per soddisfare la domanda usando il ridimensionamento automatico orizzontale dei pod.
  • Usare un sistema di avvisi per fornire notifiche quando sono necessarie azioni dirette: avvisi metrici di Container Insights o interfaccia utente di avvisi integrata.

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 diverse considerazioni da considerare 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. Vedere la sezione Dettagli SLA per informazioni sui calcoli dei tempi di attività mensili.

Considerazioni sulla progettazione per BCDR

Prendere in considerazione i fattori seguenti:

  • Il cluster Azure Red Hat OpenShift deve usare più set di computer per fornire il livello minimo di disponibilità per l'applicazione.
  • Imposta le richieste e i limiti dei pod. L'impostazione di questi limiti consente a Kubernetes:
    • Assegnare in modo efficiente risorse di CPU e memoria ai pod.
    • Avere una densità di contenitore superiore 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 maggiore disponibilità.
    • Scegliere un'area che supporti le zone di disponibilità.
    • Per ottenere il vantaggio completo dall'uso di più zone, tutte le dipendenze del servizio devono supportare le zone anch'esse. Se un servizio dipendente non supporta le zone, è possibile che un errore di zona causi un errore del servizio. Esaminare i tipi di disco usati durante la distribuzione del carico di lavoro tra le zone.
    • Per una maggiore disponibilità oltre a ciò che le zone di disponibilità possono ottenere, eseguire più cluster in regioni abbinate diverse. Se una risorsa di Azure supporta la ridondanza geografica, specificare la posizione in cui il servizio ridondante avrà l'area secondaria.
  • Creare in modo coerente i 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 Frontdoor di Azure.
  • Per i failover pianificati e non pianificati:
    • Quando si configura ogni servizio di Azure, scegliere le funzionalità che supportano il ripristino di emergenza. Ad esempio, se si seleziona Registro Azure Container , abilitarlo per la replica geografica. Se una regione diventa inattiva, è comunque possibile estrarre le immagini dalla regione 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 Azure Red Hat OpenShift sono forniti con tre nodi di controllo e tre o più nodi di lavoro. Assicurarsi che il cluster venga creato in un'area che supporti le zone di disponibilità in modo che i nodi vengano distribuiti tra le zone.
  • Per la disponibilità elevata, distribuire questi nodi in zone di disponibilità diverse. 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à aggiuntivi delle risorse che possono influire sull'intero cluster.
  • Creare gruppi di macchine infrastrutturali per ospitare i componenti infrastrutturali. Applicare etichette Kubernetes specifiche a questi computer e quindi aggiornare i componenti dell'infrastruttura per l'esecuzione solo in tali computer.
  • Quando possibile, rimuovere lo stato del servizio dall'interno dei contenitori. Usare invece una piattaforma distribuita come servizio (PaaS) di Azure che supporta la replica a più aree.
  • Le distribuzioni devono specificare i requisiti delle risorse dei pod. L'utility di scheduling può quindi pianificare correttamente il pod. L'affidabilità si riduce significativamente quando i pod non sono assegnati.
  • Configurare più repliche nella distribuzione per gestire interruzioni come gli errori hardware. Per eventi pianificati come aggiornamenti e upgrade, un budget di interruzione può garantire che il numero necessario di repliche di pod siano disponibili per gestire il carico applicativo previsto.
  • 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 linea di base. Iniziare con valori uguali per le richieste e i limiti. Quindi, regolare gradualmente quei valori fino a stabilire una soglia che possa causare instabilità nel cluster. I limiti dei pod possono essere specificati nei manifest di distribuzione. La scalabilità automatica 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 sia la progettazione che l'automazione della distribuzione. Quando un'organizzazione definisce uno standard per il contratto di servizio, RTO e RPO, può usare i servizi integrati in Kubernetes e Azure per raggiungere gli obiettivi aziendali.
  • Prendere in considerazione strategie blue/green o canary per distribuire nuove versioni dell'applicazione.
  • Impostare la priorità dei pod e i budget di interruzione dei pod per limitare il numero di repliche di pod che il cluster può spegnere per le operazioni di manutenzione, garantendo così la disponibilità.
  • Imporre le quote di risorse sui namespace di 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 di risorse a livello di cluster può causare problemi durante la distribuzione dei servizi partner che non hanno richieste e limiti appropriati.
  • 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 un percorso del provider di peering, un'architettura di rete ibrida ridondante può contribuire a garantire una connettività cross-premise ininterrotta.
  • Interconnettere le regioni con il peering globale di rete virtuale. Se i cluster devono comunicare tra loro, è possibile connettersi tra loro entrambe le reti virtuali tramite il peering di rete virtuale. Questa tecnologia interconnette le reti virtuali tra loro per fornire una larghezza di banda elevata attraverso la rete backbone di Microsoft, anche in aree geografiche diverse.
  • Usare il protocollo anycast basato su TCP a segmentazione, Azure Front Door, per connettere tempestivamente gli utenti finali al POP (Point of Presence) di Azure Front Door più vicino. Altre funzionalità di Frontdoor di Azure includono:
    • Terminazione TLS
    • Dominio personalizzato
    • Firewall per applicazioni web
    • URL rewrite
    • Affinità di sessione

Passaggi successivi

Scopri le considerazioni e raccomandazioni della progettazione per l'automazione della piattaforma e DevOps nelle zone di atterraggio di Azure.

  • Last updated on