Configurazione dell'alta disponibilità della virtualizzazion Red Hat OpenShift

Configurare l'alta disponibilità della virtualizzazion Red Hat OpenShift utilizzando gli operatori " Node " (Controllo dello stato) e "Self- Node " (Risoluzione automatica) per il rilevamento automatico dei guasti e il ripristino dei carichi di lavoro su IBM Cloud.

Obiettivi

Il tutorial tratta i seguenti argomenti:

  • Installare e configurare l'operatore Health Check di Node
  • Installare e configurare l'operatore di correzione Self- Node
  • Creare una risorsa personalizzata “ NodeHealthCheck ” per definire i criteri di integrità dei nodi
  • Verifica della correzione automatica dei nodi

Prima di iniziare

Assicurati che siano soddisfatti i seguenti prerequisiti prima di iniziare:

  • Un'istanza di IBM Cloud Red Hat OpenShift su un cluster VPC che esegue Red Hat OpenShift 4.12 o versioni successive
  • privilegi di amministratore del cluster
  • L'interfaccia da riga di comando (CLI) di oc, installata e configurata per accedere al cluster
  • La CLI di ibmcloud installata con il plug-in Kubernetes® Service

Per ulteriori informazioni sulla configurazione degli strumenti CLI, consultare la sezione " Configurazione della CLI".

Elevata disponibilità per i carichi di lavoro di virtualizzazione

L'alta disponibilità (HA) per i carichi di lavoro di virtualizzazione su Red Hat OpenShift Kubernetes Service (ROKS) garantisce che le macchine virtuali (VM) continuino a funzionare in modo affidabile nonostante eventuali guasti dell'infrastruttura, quali interruzioni dei nodi di lavoro o problemi hardware.

In un ambiente di virtualizzazione " Red Hat OpenShift " in esecuzione su ROVS, ROVS garantisce l'alta disponibilità (HA) grazie alla stretta integrazione tra i servizi del piano di controllo " Red Hat OpenShift ", la pianificazione " Kubernetes " e gli operatori di virtualizzazione " Red Hat OpenShift ". La piattaforma monitora costantemente lo stato dei nodi di lavoro e delle macchine virtuali. Quando un nodo di lavoro non è più disponibile, Red Hat OpenShift rileva automaticamente il guasto e avvia le azioni di ripristino.

Le macchine virtuali interessate da un guasto di un nodo vengono automaticamente riavviate o migrate su nodi operativi integri all'interno del cluster. Questo processo è reso possibile da uno storage condiviso e resiliente, sia nell’ambito dell’ Red Hat OpenShift Data Foundation (ODF) che dell’ NFS, che garantisce che i dischi di VM rimangano accessibili su tutti i nodi durante gli eventi di failover.

Le funzionalità chiave che consentono l'alta disponibilità (HA) su ROKS dell' IBM Cloud e includono:

  • Risanamento dei nodi guidato dall’operatore tramite NHC e SNR per individuare i nodi non funzionanti e ripristinare automaticamente le macchine virtuali
  • Kubernetes pianificazione basata su [...], per collocare le VM ripristinate sui nodi di lavoro disponibili
  • Archiviazione condivisa e resiliente tramite ODF e NFS per supportare il riavvio e la migrazione di VM
  • Riduzione della complessità operativa e dei tempi di ripristino grazie a un intervento manuale minimo

Utilizzando la virtualizzazione OpenShift su IBM Cloud ROKS, è possibile eseguire carichi di lavoro di virtualizzazione critici con maggiore affidabilità, ripristino più rapido e alta disponibilità integrata, in linea con i requisiti aziendali in materia di disponibilità e continuità operativa.

Node Integrazione tra Health Check e la correzione automatica tramite Self- Node

Per migliorare ulteriormente l'alta disponibilità dei carichi di lavoro di virtualizzazione su ROKS di IBM Cloud, le funzionalità Health Check (NHC) e Self- Node Remediation (SNR) di Node operano in sinergia per individuare automaticamente i nodi di lavoro non funzionanti e ripristinarli senza alcun intervento manuale. Questo intervento correttivo proattivo contribuisce a prevenire interruzioni prolungate e migliora la resilienza complessiva del cluster.

Node Health Check (NHC) monitora costantemente lo stato di salute dei nodi di lavoro, valutando aspetti quali la disponibilità dei nodi, lo stato di " kubelet " e i segnali di heartbeat. Quando un nodo entra in uno stato di malfunzionamento o smette di rispondere oltre una soglia prestabilita, l’NHC stabilisce che il nodo necessita di un intervento di ripristino e avvia le azioni correttive.

Una volta avviata la procedura di correzione, la funzione Self- Node Remediation (SNR) esegue operazioni di ripristino a livello di nodo. In base allo scenario di guasto e alla configurazione, SNR può riavviare in sicurezza il nodo interessato oppure eseguire il fencing per isolarlo dal cluster. Quando l'SNR individua i nodi difettosi, questi non influiscono più sui carichi di lavoro in esecuzione né causano problemi di “split-brain” o di coerenza dei dati.

L'integrazione tra NHC e SNR è particolarmente importante per i carichi di lavoro di virtualizzazion Red Hat OpenShift:

  • Il cluster isola rapidamente i nodi non funzionanti, in modo che le macchine virtuali non vengano pianificate su un'infrastruttura instabile.
  • Il cluster esegue automaticamente la migrazione delle macchine virtuali dai nodi guasti a quelli funzionanti.
  • Il cluster consente ai nodi ripristinati di ricongiungersi in modo sicuro e di riprendere a ospitare i carichi di lavoro dopo il ripristino.

Grazie alla combinazione della tecnologia NHC per il rilevamento e della tecnologia SNR per la risoluzione automatica dei problemi, la virtualizzazione " OpenShift " su IBM Cloud ROKS garantisce una risposta più rapida ai guasti, una riduzione del carico operativo e una maggiore continuità per i carichi di lavoro di virtualizzazione mission-critical.

Red Hat fornisce inoltre la funzionalità Fence Agents Remediation (FAR) per implementare la correzione tramite restrizioni basate sull'hardware o sull'alimentazione tramite l'API BMC, che attualmente non è supportata sui nodi di lavoro di ROKS.

Disattivare la protezione del traffico in uscita e abilitare il catalogo degli operatori

Gli operatori “Health Check” (Verifica dello stato) e “Self- Node ” (Risoluzione automatica) di Node sono disponibili nel catalogo degli operatori di Red Hat.

Se la protezione del traffico in uscita è disabilitata sul cluster (come raccomandato), saltare questo passaggio.

Se la protezione del traffico in uscita è abilitata (impostazione predefinita), i cataloghi " Red Hat " di Operator vengono disabilitati su ROVS. Seguire la procedura riportata di seguito per abilitare l'origine del catalogo predefinita su ROVS.

  1. Disattivare la protezione in uscita per garantire che il cluster disponga dell’accesso a Internet in uscita necessario per scaricare le immagini richieste da fonti quali registry.redhat.io e quay.io.

    ibmcloud oc vpc outbound-traffic-protection disable -c <cluster-name>

  2. Recupera la configurazione del cluster.

    ibmcloud ks cluster config --admin -c <cluster-name>

  3. Abilita l'impostazione predefinita CatalogSource.

    oc patch operatorhub cluster --type json -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": false}]'

  4. Verifica lo stato dell' CatalogSource.

    oc -n openshift-marketplace get catalogsource

  5. Verificare che gli operatori richiesti siano disponibili.

    oc get packagemanifests -n openshift-marketplace | grep node-healthcheck-operator
oc get packagemanifests -n openshift-marketplace | grep self-node-remediation

È possibile visualizzare l'elenco degli operatori presenti in ciascuna " CatalogSource " dalla console di Red Hat OpenShift, accedendo alla sezione Amministrazione > CustomResourceDefinitions > Dettagli dell’ OperatorHub.

Installare gli operatori " Node " per il controllo dello stato di salute e "Self- Node " per la correzione automatica

Installa entrambi gli operatori dalla console Red Hat OpenShift OperatorHub.

  1. Accedi alla console Red Hat OpenShift.

  2. Vai su Operatori > OperatorHub.

  3. Cerca e installa l'operatore Health Check di Node con le seguenti impostazioni:

    • Nome: Controllo dello stato di salute di Node
    • Spazio dei nomi: openshift-workload-availability
    • Strategia di approvazione: automatica

  4. Cerca e installa l'operatore di correzione Self- Node con le seguenti impostazioni:

    • Nome: Bonifica auto Node e
    • Spazio dei nomi: openshift-workload-availability
    • Strategia di approvazione: automatica

  5. Attendere fino a quando entrambi gli operatori non mostrano lo stato “ Operazione riuscita ”.

Configurazione dell'operatore di correzione "Self- Node "

L'operatore di correzione "Self- Node " crea un' SelfNodeRemediationConfig predefinita denominata self-node-remediation-config e un' SelfNodeRemediationTemplate predefinita denominata self-node-remediation-automatic-strategy-template.

La risorsa personalizzata (CR) “Configurazione di correzione automatica (Self- Node ) (Configurazione SNR)” definisce i parametri per l’operatore di correzione automatica (Self- Node ), che rileva, isola e riavvia automaticamente i nodi Kubernetes non funzionanti senza richiedere interfacce di gestione quali l’Intelligent Platform Management Interface (IPMI). Questo approccio senza agenti rende SNR Config utile per ambienti bare-metal o con risorse limitate, in cui non sono disponibili interfacce di gestione dell'hardware.

Il modello di correzione automatica (Self- Node, modello SNR) definisce la strategia di riavvio che l'operatore di correzione automatica (Self- Node ) applica quando avvia il ripristino di un nodo non funzionante. Isolando i nodi non funzionanti tramite riavvii software o dispositivi di monitoraggio (watchdog), SNR Template contribuisce a garantire un ripristino sicuro dei carichi di lavoro, in particolare per le applicazioni con stato.

È possibile utilizzare le risorse predefinite SelfNodeRemediationConfig e SelfNodeRemediationTemplate create automaticamente dall'operatore di correzione di Self- Node, oppure personalizzarle per soddisfare i requisiti specifici del cluster.

Modifica o creazione di una configurazione di correzione per Self- Node

Modificare la configurazione SNR per regolare i parametri di rilevamento e di contenimento, quali i timeout del server API, gli intervalli di verifica dei peer e il numero minimo di peer richiesto affinché venga avviata la correzione. Per modificare la configurazione predefinita di Self- Node Remediation o crearne una nuova:

  1. Nella console di Red Hat OpenShift, vai su Operatori > Operatori installati ( Progetto: openshift-workload-availability ) > Operatore di correzione Self- Node > Configurazione di correzione Self- Node.

  2. Per modificare la configurazione predefinita:

    1. Apri self-node-remediation-config
    2. Fai clic su " Azioni " e seleziona " Modifica" SelfNodeRemediationConfig
    3. Aggiornare i parametri YAML secondo necessità (ad esempio, la strategia di correzione)
    4. Fai clic su " Salva " per applicare le modifiche

  3. Per creare una nuova configurazione:

    • Fare clic su " **Crea SelfNodeRemediationConfig **" e specificare i parametri richiesti
    • In alternativa, creare un file YAML denominato “ snr-config.yaml ”:
    apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationConfig
metadata:
  name: customer-self-node-remediation-config
  namespace: openshift-workload-availability
spec:
  apiServerTimeout: 5s
  peerApiServerTimeout: 5s
  hostPort: 30001
  isSoftwareRebootEnabled: true
  watchdogFilePath: /dev/watchdog
  peerDialTimeout: 5s
  peerUpdateInterval: 15m
  apiCheckInterval: 15s
  peerRequestTimeout: 7s
  maxApiErrorThreshold: 3
  minPeersForRemediation: 1

  4. Applica la configurazione.

    oc apply -f snr-config.yaml

Per una spiegazione dettagliata di tutti i parametri disponibili, consultare la sezione " Informazioni sulla configurazione dell'operatore di correzione Self- Node".

Modifica o crea un modello di correzione di Self- Node

Modificare il modello SNR per controllare la strategia di riavvio applicata quando viene ripristinato un nodo non funzionante, ad esempio per passare da una strategia all'altra tra " Automatic", " ResourceDeletion" o " OutOfServiceTaint ". Per modificare il modello predefinito di correzione di Self- Node o crearne uno nuovo:

  1. Nella console Red Hat OpenShift, vai su Operatori > Operatori installati ( Progetto: openshift-workload-availability ) > Operatore di correzione Self- Node > Modello di correzione Self- Node.

  2. Per modificare il modello predefinito:

    1. Apri self-node-remediation-automatic-strategy-template
    2. Fai clic su " Azioni " e seleziona " Modifica" SelfNodeRemediationTemplate
    3. Aggiornare i parametri YAML secondo necessità (ad esempio, la strategia di correzione)
    4. Fai clic su " Salva " per applicare le modifiche

  3. Per creare un nuovo modello:

    • Fare clic su “Crea” ( SelfNodeRemediationTemplate ) e specificare i parametri richiesti
    • In alternativa, creare un file YAML denominato “ snr-template.yaml ”:
    apiVersion: self-node-remediation.medik8s.io/v1alpha1
kind: SelfNodeRemediationTemplate
metadata:
  name: customer-self-node-remediation-template
  namespace: openshift-workload-availability
spec:
  template:
    spec:
      remediationStrategy: Automatic

  4. Applica il modello.

    oc apply -f snr-template.yaml

Per una spiegazione dettagliata di tutti i parametri disponibili, consultare la sezione " Informazioni sulla configurazione del modello di correzione Self- Node".

Configurare l'operatore di controllo dello stato di integrità di " Node "

L'operatore Health Check (NHC) di Node monitora lo stato di salute dei nodi in un cluster Red Hat OpenShift e identifica i nodi che presentano problemi.

La risorsa personalizzata (CR) “ NodeHealthCheck ” definisce i criteri e le soglie specifici per stabilire se un nodo non è in condizioni ottimali e richiede un intervento correttivo.

Crea una risorsa " NodeHealthCheck "

Per definire i criteri di integrità dei nodi e configurare i trigger di correzione tramite la console o la CLI di OpenShift, procedere come segue:

  1. Nella console di OpenShift, accedere a Operatori > Operatori installati (Progetto: openshift-workload-availability) > Operatore di controllo dello stato di Node > Controllo dello stato di Node.

  2. Fare clic su " **Crea NodeHealthCheck **" e inserire i parametri richiesti.

  3. In alternativa, creare un file YAML denominato “ nhc-node-notready.yaml ”:

    apiVersion: remediation.medik8s.io/v1alpha1
kind: NodeHealthCheck
metadata:
  name: customer-node-notready-check
  namespace: openshift-workload-availability
spec:
  minHealthy: 51%
  unhealthyConditions:
    - type: Ready
      status: "False"
      duration: 300s
    - type: Ready
      status: "Unknown"
      duration: 300s
  remediationTemplate:
    apiVersion: self-node-remediation.medik8s.io/v1alpha1
    kind: SelfNodeRemediationTemplate
    name: self-node-remediation-automatic-strategy-template
    namespace: openshift-workload-availability

  4. Applica la configurazione.

    oc apply -f nhc-node-notready.yaml

L' remediationTemplate deve corrispondere al nome dell' SelfNodeRemediationTemplate predefinito oppure a quello di un SelfNodeRemediationTemplate personalizzato creato nell'Operatore di correzione di Self- Node (come descritto in Modifica o creazione di un modello di correzione di Self- Node ).

Per una spiegazione dettagliata di tutti i parametri disponibili, consultare la sezione “Informazioni sull’operatore Health Check di Node ”.

Verificare la configurazione

Dopo aver configurato gli operatori, verificare che funzionino correttamente.

  1. Consulta le risorse su NodeHealthCheck.

    oc get nhc -n openshift-workload-availability

  2. Consulta le risorse su SelfNodeRemediationConfig.

    oc get selfnoderemediationconfig -n openshift-workload-availability

  3. Consulta le risorse su SelfNodeRemediationTemplate.

    oc get selfnoderemediationtemplate -n openshift-workload-availability

Passi successivi

Dopo aver configurato il controllo automatico dello stato dei nodi e le azioni correttive, si consiglia di prendere in considerazione le seguenti azioni: