Prima di iniziare

Prima di creare i cluster, raccogli i dettagli relativi alla VPC e all’ Cloud Object Storage e necessari da inserire nei comandi di creazione dei cluster.

1. Recupera i tuoi ID VPC. Prendi nota dell'ID della VPC che desideri utilizzare per ciascun cluster.

   ibmcloud is vpcs
   

2. Recupera i dettagli della sottorete per una VPC specifica. Prendi nota degli ID delle sottoreti che desideri utilizzare per ciascun cluster.

   ibmcloud is subnets --vpc VPC_ID
   

3. Elenca le tue istanze di Cloud Object Storage.

   ibmcloud resource service-instances --service-name cloud-object-storage
   

4. Recupera il CRN dell'istanza che desideri utilizzare. Prendere nota del valore riportato nel campo " ID ".

   ibmcloud resource service-instance SERVICE_INSTANCE
   

Passo 1. Creare il cluster hub

Hub cluster

Questo è il cluster su cui si installa ACM per gestire i cluster ODF primario e secondario. Assicurati che il tuo cluster di hub disponga di almeno 16 vCPU x 64 GB di capacità di elaborazione disponibile.

Per ogni cluster, assicurarsi di consentire il traffico in uscita includendo il parametro --disable-outbound-traffic-protection nella CLI o selezionando l'opzione per disabilitare la protezione del traffico in uscita nell'interfaccia utente.

1. Creare un cluster VPC in us-east per installare ACM. Questo è il cluster hub che si può usare per gestire i cluster ODF. Assicurati che il tuo cluster hub disponga di almeno 3 nodi di lavoro su cui è in esecuzione RHCOS, di una capacità di elaborazione disponibile di almeno 16 vCPU e 64 GB, che il traffico in uscita sia disabilitato e che soddisfi tutti i prerequisiti per ACM. Il seguente esempio di comando crea un cluster per ACM in us-east.

   ibmcloud ks cluster create vpc-gen2 --flavor bx2.16x64 --name acm-hub-cluster-dr-odf --subnet-id SUBNET_ID --vpc-id VPC_ID --zone us-east-2 --version 4.21.31_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
   

2. Prendere nota dell'ID del cluster riportato nell'output. Ti servirà in una fase successiva.

Passo 2. Crea un profilo attendibile per il cluster di hub

Hub cluster

1. Crea il profilo attendibile.

   ibmcloud iam trusted-profile-create acm-operator-profile
   

2. Creare la regola di fiducia per le risorse di calcolo, con ambito limitato allo spazio dei nomi kube-system sulle risorse di calcolo Red Hat OpenShift.

   ibmcloud iam trusted-profile-rule-create acm-operator-profile \
     --name kube-system-rule \
     --type Profile-CR \
     --conditions claim:namespace,operator:EQUALS,value:kube-system \
     --cr-type ROKS_SA
   

3. Assegnare la politica di accesso IAM al profilo. Sostituisci " CLUSTER_ID " con l'ID del tuo cluster di hub.

   ibmcloud iam trusted-profile-policy-create acm-operator-profile \
     --roles Reader,Viewer,Operator,Editor \
     --service-name containers-kubernetes \
     --service-instance CLUSTER_ID
   

4. Assegnare il profilo attendibile al cluster di hub. Una volta assegnato un profilo attendibile a un cluster, non è più possibile rimuoverlo.

   ibmcloud oc experimental trusted-profile set --cluster CLUSTER_NAME_OR_ID --trusted-profile TRUSTED_PROFILE_ID
   

5. Verificare che il segreto del profilo attendibile sia stato creato nel cluster. L'esecuzione di questo comando può richiedere fino a 10 minuti. Attendere che venga visualizzato il codice segreto prima di procedere all'installazione del componente aggiuntivo ACM. Se si procede prima che il segreto sia stato creato, l'installazione del componente aggiuntivo ACM non andrà a buon fine.

   oc get secrets -n kube-system | grep ibm-cloud-credentials
   

6. Se si utilizza la versione ODF 4.21 o successive, installare l’operatore OpenShift GitOps sul cluster hub.

   1. Nella vista della piattaforma Core della console web OpenShift del cluster hub, accedere a Ecosystem > Software Catalog e cercare Red Hat OpenShift GitOps.

   2. Fai clic sulla Red Hat OpenShift GitOps riquadro.

   3. Nella pagina " Install Operator ", seleziona un canale di aggiornamento e una versione di " GitOps " da installare.

   4. Scegliere uno spazio dei nomi installato. Lo spazio dei nomi di installazione predefinito è openshift-gitops-operator.

      Per la versione GitOps 1.10 e successive, lo spazio dei nomi predefinito è stato modificato da openshift-operators a openshift-gitops-operator.

   5. Selezionare la casella di controllo " Abilita il monitoraggio del cluster consigliato dall'operatore su questo spazio dei nomi " per abilitare il monitoraggio del cluster.

   6. Fai clic su Install. Red Hat OpenShift GitOps è installato in tutti gli spazi dei nomi del cluster.

   7. Verificare che l'operatore " Red Hat OpenShift " GitOps sia presente nell'elenco Operatori > Operatori installati e che lo Stato sia "Riuscito".

   Dopo l'installazione, OpenShift GitOps configura automaticamente un'istanza di Argo CD pronta all'uso nello spazio dei nomi openshift-gitops e nella barra degli strumenti della console viene visualizzata l'icona di Argo CD.

Passo 3. Creare i cluster gestiti

Managed cluster

1. Creare un cluster VPC su us-east con almeno 3 nodi di lavoro che eseguono RHCOS, una capacità di calcolo disponibile di almeno 16 vCPU e 64 GB, e la protezione del traffico in uscita disabilitata. Questo sarà il cluster ODF primario gestito. Il comando di esempio riportato di seguito crea un cluster in us-east.

   ibmcloud ks cluster create vpc-gen2 --flavor bx2.16x64 --name managed-cluster-1-dr-odf --subnet-id SUBNET_ID --vpc-id VPC_ID --zone us-east-2 --version 4.21.31_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
   

2. Creare un cluster VPC su jp-tok con almeno 3 nodi di lavoro che eseguono RHCOS, una capacità di calcolo disponibile di almeno 16 vCPU e 64 GB, e la protezione del traffico in uscita disabilitata. Questo sarà il cluster ODF secondario gestito. Per l'alta disponibilità, assicurarsi che la rete del cluster secondario non si sovrapponga a quella del cluster primario. Il comando di esempio riportato di seguito crea un cluster in jp-tok.

   ibmcloud ks cluster create vpc-gen2 --flavor bx2.16x64 --name managed-cluster-2-dr-odf --subnet-id SUBNET_ID --vpc-id VPC_ID --zone jp-tok --version 4.21.31_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
   

Passo 4. Installare il componente aggiuntivo ACM sul cluster di hub

Hub cluster

Utilizza la CLI per installare il componente aggiuntivo ACM sul cluster hub.

1. Individua la versione predefinita del componente aggiuntivo ACM.

   ibmcloud oc cluster addon versions
   

2. Esamina le opzioni aggiuntive di ACM. Nel comando, specificare la versione predefinita individuata nel passaggio precedente. Prendi nota delle opzioni che desideri includere durante l'installazione del componente aggiuntivo.

   ibmcloud oc cluster addon options --addon acm --version DEFAULT_VERSION
   

3. Esegui il comando per abilitare il componente aggiuntivo. Assicurati di specificare i parametri billingPlan e isLicenseAccepted.

   ibmcloud oc cluster addon enable acm --cluster HUB_CLUSTER_ID --param 'billingPlan=PLAN' --param 'isLicenseAccepted=BOOLEAN'
   

   Parametri di comando. Si veda il comando di esempio riportato di seguito per un esempio di ciascun tipo di parametro.

   --cluster

   Obbligatorio. L'ID del cluster di hub su cui installare il componente aggiuntivo ACM.

   --param 'billingPlan='

   Obbligatorio. Il piano di fatturazione che desideri selezionare per ACM. Specificare " KUBERNETES " per il piano " ACM per Kubernetes ".

   --param 'isLicenseAccepted='

   Obbligatorio. Imposta questa opzione su “ true ” per accettare il contratto di licenza relativo al piano di fatturazione selezionato. L'estensione non verrà installata correttamente se non si accetta la licenza. Accettando la presente licenza, l'utente accetta i termini e le condizioni applicabili e dichiara di aver compreso i servizi inclusi nel piano selezionato.

   Comando di esempio per installare il componente aggiuntivo ACM con il piano di fatturazione ACM per " Kubernetes ".

   ibmcloud oc cluster addon enable acm --cluster a5bcde982dfer2nwxq73 --param 'billingPlan=KUBERNETES' --param 'isLicenseAccepted=true'
   

4. Verifica che il componente aggiuntivo sia stato installato. Potrebbero essere necessari alcuni minuti prima che il componente aggiuntivo compaia nei risultati riportati di seguito.

   1. Nel cluster di hub, verificare che la risorsa acmhub sia stata creata.

       oc get acmhub
       ```
       Output di esempio.
   
       ```sh {: screen}
           NAME       AGE
           acm-auto   1h
       ```
   1. Nel cluster di hub, verificare lo stato dell' `acmhub`.
   
   ```sh {: pre}
       oc describe acmhub
       ```
       Output di esempio.
   
       ```sh {: screen}
       Status
           Message: ACM installed successfully
       ```
   

Passo 5. Importa i cluster gestiti in ACM

Hub cluster Managed cluster

Importa entrambi i cluster gestiti in ACM in modo che il cluster hub possa gestirli.

1. Apri la console web OpenShift relativa al cluster di hub.

2. Dal punto di vista della gestione della flotta, fare clic su “Importa cluster ”.

3. Inserisci il nome del primo cluster gestito, seleziona un insieme di cluster, se applicabile, e inserisci eventuali etichette aggiuntive.

4. Per la modalità Importazione, selezionare " Esegui i comandi di importazione manualmente " e fare clic su Avanti.

5. Se lo si desidera, selezionare un modello di automazione e fare clic su Avanti.

6. Controlla i dettagli e fai clic su " Genera comando ". Copia il comando visualizzato.

7. Accedi al primo cluster gestito ed esegui il comando copiato utilizzando l' kubectl e configurata per quel cluster.

8. Ripetere i passaggi da 2 a 7 per il secondo cluster gestito.

9. Dal punto di vista della gestione della flotta, verificare che entrambi i cluster gestiti siano elencati e presentino lo stato “Pronto” prima di procedere.

Passo 6. Configurare il componente aggiuntivo Submariner

Hub cluster Managed cluster

Configurare il componente aggiuntivo Submariner per stabilire una connessione di rete tra i due cluster gestiti. Scegli una delle seguenti opzioni in base alla tua infrastruttura e ai tipi di cluster:

• Opzione 1: Transit Gateway (preferita) — Supportata sia per i cluster Red Hat OpenShift on IBM Cloud che per quelli Red Hat OpenShift Virtualization Service (ROVS) con istanze di server virtuali (VSI) e nodi di lavoro bare metal.
• Opzione 2: Network Load Balancer (NLB) — Supportato solo per i cluster " Red Hat OpenShift on IBM Cloud " con nodi di lavoro VSI.

Passo 7. Installare e configurare OpenShift Data Foundation

Managed cluster

Installare e configurare ODF sui 2 cluster gestiti. Assicurarsi di completare questi passaggi sia sul cluster primario che su quello secondario gestito.

Prima di eseguire qualsiasi comando di “ oc ” descritto in questa sezione, assicurati che il contesto sia impostato sul cluster gestito che stai configurando. Esegui il comando ibmcloud oc cluster config --cluster MANAGED_CLUSTER_NAME_OR_ID --admin per cambiare contesto, quindi verifica con oc config current-context``.

1. Per ogni cluster gestito, installare il componente aggiuntivo “ OpenShift Data Foundation” dalla console IBM Cloud.

   1. Accedi alla pagina Panoramica del tuo cluster e scorri verso il basso fino alla sezione Componenti aggiuntivi.
   2. In “ OpenShift Data Foundation”, fare clic su Installa.
   3. Seleziona la casella " Implementare il gateway multi-cloud per oggetti " NooBaa "".
   4. Fai nuovamente clic su " Installa " per confermare.
   5. Attendere che lo stato del componente aggiuntivo ODF passi da “In fase di abilitazione” a “Normale” (segno di spunta verde) prima di procedere.

2. Verificare che ODF sia stato installato correttamente. Nell'output, verificare che lo stato indichi Ready.

   Lo stato “Normale” dell’interfaccia utente indica che il componente aggiuntivo è stato distribuito, ma l’operatore ODF potrebbe comunque aver bisogno di qualche minuto per completare l’inizializzazione e la registrazione delle proprie risorse.

   oc get storagecluster -n openshift-storage ocs-storagecluster -o jsonpath='{.status.phase}{"\n"}'
   

È necessario eseguire i passaggi seguenti su ciascun cluster gestito. Passa al primo cluster gestito utilizzando ibmcloud oc cluster config --cluster MANAGED_CLUSTER_NAME_OR_ID --admin, completa tutti i passaggi fino alla fine di questa sezione, quindi passa al secondo cluster gestito e ripeti la procedura.

1. Esegui il comando per aggiornare il file " ACM Managed Cluster Name " nella sezione " multiClusterService " della risorsa " storageCluster ". Ciò consente a ODF di utilizzare GlobalNet. Per ulteriori informazioni, vedere Creazione di un cluster OpenShift Data Foundation su cluster gestiti.

   Sostituisci MANAGED_CLUSTER_NAME con il nome del cluster a cui è attualmente indirizzato il tuo contesto.

   kubectl patch storagecluster -n openshift-storage ocs-storagecluster --type merge -p'{"spec":{"network":{"multiClusterService":{"clusterID":"MANAGED_CLUSTER_NAME","enabled":true}}}}'
   

   Output di esempio.

   storagecluster.ocs.openshift.io/ocs-storagecluster patched
   

2. Verificare le esportazioni di servizio. Potrebbe essere necessario qualche minuto per visualizzare l'output.

   oc get serviceexport -n openshift-storage
   

   Output di esempio:

   NAME              AGE
   rook-ceph-mon-d   4d14h
   rook-ceph-mon-e   4d14h
   rook-ceph-mon-f   4d14h
   rook-ceph-osd-0   4d14h
   rook-ceph-osd-1   4d14h
   rook-ceph-osd-2   4d14h
   

3. Crea un'esportazione del servizio per ocs-provider-server.

   oc apply -f - <<EOF
   apiVersion: multicluster.x-k8s.io/v1alpha1
   kind: ServiceExport
   metadata:
     name: ocs-provider-server
     namespace: openshift-storage
   EOF
   

   Output di esempio.

   serviceexport.multicluster.x-k8s.io/ocs-provider-server created
   

4. Eseguire il comando per aggiornare la risorsa storageCluster e utilizzare l'esportazione del servizio ocs-provider-server creata.

   oc annotate storagecluster ocs-storagecluster -n openshift-storage ocs.openshift.io/api-server-exported-address=MANAGED_CLUSTER_NAME.ocs-provider-server.openshift-storage.svc.clusterset.local:50051.
   

   Output di esempio.

   storagecluster.ocs.openshift.io/ocs-storagecluster annotated
   

5. Verificare che la risorsa storageCluster sia pronta.

   oc get storagecluster -n openshift-storage
   

   Output di esempio.

   NAME                    PHASE  
   ocs-storagecluster      Ready   
   

Passaggio 8. Configurare la politica di ripristino di emergenza a livello regionale

Hub cluster

Installa ODF Multicluster Orchestrator sul tuo cluster hub e crea la politica di ripristino di emergenza (DR) che consenta il mirroring tra i tuoi due cluster gestiti.

1. Installare ODF Multicluster Orchestrator sul cluster hub.

   1. Se non l'hai già fatto, installa l'operatore " OpenShift " ( GitOps ) sul cluster hub. Per le istruzioni di installazione, consultare la fine della pagina , Passaggio 2. Crea un profilo attendibile per il cluster di hub.
   2. Nella vista della piattaforma Core della console web OpenShift del cluster hub, accedere a Ecosystem > Software Catalog e cercare ODF Multicluster Orchestrator.
   3. Fare clic sul riquadro “ODF Multicluster Orchestrator ”. Assicurati di selezionare lo stesso numero di versione della versione ODF che hai installato sui cluster gestiti nella sezione precedente. Mantieni tutte le altre impostazioni predefinite e fai clic su Installa.
   4. Assicurarsi che le risorse dell'operatore siano installate nel progetto openshift-operators e disponibili per tutti gli spazi dei nomi. Fai nuovamente clic su " Installa " per confermare.

   L'ODF Multicluster Orchestrator installa inoltre l' OpenShift DR Hub Operator sul cluster hub come dipendenza.

2. Verificare l'installazione controllando che le unità operatore siano in funzione. Assicurati che il contesto CLI sia impostato sul cluster hub prima di eseguire questo comando.

   oc get pods -n openshift-operators
   

   Output di esempio.

   NAME                                        READY   STATUS       RESTARTS    AGE
   odf-multicluster-console-6845b795b9-blxrn   1/1     Running      0           4d20h
   odfmo-controller-manager-f9d9dfb59-jbrsd    1/1     Running      0           4d20h
   ramen-hub-operator-6fb887f885-fss4w         2/2     Running      0           4d20h
   

3. Nel cluster hub, creare una politica di DR con un intervallo di sincronizzazione di 5 minuti e specificare ciascun cluster gestito nei parametri. In questo modo vengono creati dei bucket di oggetti " NooBaa " su entrambi i cluster gestiti e viene abilitato il mirroring del pool di blocchi ODF Ceph per la replica dei volumi.

   1. Nella sezione " Fleet Management " della console web OpenShift del cluster hub, accedere a Data Services > Disaster recovery > Policies > Create DRPolicy.

   2. Creare un criterio DR che includa i seguenti parametri.

      • Cluster collegati: PRIMARY_MANAGED_CLUSTER_NAME, SECONDARY_MANAGED_CLUSTER_NAME
      • Politica di replica: Asincrono
      • Intervallo di replica: 5m
      • Se applicabile, selezionare "Abilita supporto per il ripristino di emergenza per le istanze di " PersistentVolumeClaims " ripristinate e clonate (solo per Data Foundation)" in " Impostazioni avanzate ".

      Red Hat afferma esplicitamente che questa opzione deve essere utilizzata solo con applicazioni individuate e in ambienti in cui i volumi RBD clonati/ripristinati sono attivamente supportati.

4. Sul cluster hub, eseguire i seguenti comandi per verificare che la politica di DR sia stata creata e applicata ai cluster gestiti. Assicurati che il contesto CLI sia impostato sul cluster hub prima di eseguire questi comandi.

   ibmcloud oc cluster config --cluster HUB_CLUSTER_NAME --admin
   

   oc get drpolicy DRPOLICY_NAME -o jsonpath='{.status.conditions[].reason}{"\n"}'
   

   Output di esempio.

   Succeeded
   

   oc get drclusters
   

   Output di esempio.

   NAME               AGE
   managed-cluster1   4m42s
   managed-cluster2   4m42s
   

5. Su ciascun cluster gestito, verificare che la politica di DR sia stata applicata e che sia in uno stato corretto. Prima di eseguire questi comandi, passare al contesto CLI di ciascun cluster gestito.

   ibmcloud oc cluster config --cluster MANAGED_CLUSTER_NAME --admin
   

   oc get csv,pod -n openshift-dr-system
   

   Output di esempio.

   NAME                                                                          DISPLAY                         VERSION        REPLACES   PHASE
   clusterserviceversion.operators.coreos.com/odr-cluster-operator.v4.15.0       Openshift DR Cluster Operator   4.15.0                    Succeeded
   clusterserviceversion.operators.coreos.com/volsync-product.v0.8.0             VolSync                         0.8.0                     Succeeded
   NAME                                             READY   STATUS    RESTARTS   AGE
   pod/ramen-dr-cluster-operator-6467cf5d4c-cc8kz   2/2     Running   0          3d12h
   

   oc get cephblockpool ocs-storagecluster-cephblockpool -n openshift-storage -o jsonpath='{.status.mirroringStatus.summary}{"\n"}'
   

   Output di esempio.

   {"daemon_health":"OK","health":"OK","image_health":"OK","states":{}}
   

6. Opzionale: Esaminare gli operatori che si possono installare per migliorare le funzioni di ODF Regional Disaster Recovery.

7. Opzionale: Testare la configurazione del disaster recovery.

Operatori opzionali per ODF Regional Disaster Recovery

Esaminare gli operatori opzionali che è possibile installare sull'hub ACM o sui cluster gestiti per migliorare le funzionalità di ODF Regional Disaster Recovery. Si noti che IBM non è responsabile della gestione di questi operatori.

L'utente è responsabile della gestione di questi operatori, compresi, ma non solo, l'aggiornamento, il monitoraggio, il ripristino e la reinstallazione.

Testare la configurazione di disaster recovery

Creare un'applicazione di esempio per testare la soluzione di disaster recovery. Per ulteriori informazioni, vedere Creare un'applicazione di esempio per testare l'applicazione di disaster recovery.

1. Distribuire un'applicazione basata su abbonamento dalla console ACM. La scheda della topologia dell'applicazione è verde quando tutte le risorse dell'applicazione sono state distribuite correttamente.

2. Nella pagina dell'applicazione, vai su Azioni > Gestisci politica dati.

3. Assegna a questa applicazione la policy DR creata in precedenza.

4. Verificare che i pod dell'applicazione siano in esecuzione sul cluster primario.

5. Nella pagina dell'applicazione, vai su Azioni > Applicazione di failover. Selezionare il cluster ODF secondario come cluster di destinazione. Fare clic su Avvia.

6. Verificare che i pod dell'applicazione siano spostati nel cluster secondario.

7. Nella pagina dell'applicazione, vai su Azioni > Riposiziona applicazione. Selezionare il cluster ODF primario come cluster di destinazione. Fare clic su Avvia.

8. Verificare che i pod dell'applicazione siano riportati nel cluster principale.

Aggiornamento dell'ambiente regionale di ripristino di emergenza ODF

Per informazioni su quando e come aggiornare i componenti dell'ambiente ODF-RDR, consultare la sezione " Aggiornamento dell'ambiente ODF Regional Disaster Recovery ".

Risoluzione dei problemi

Se riscontri problemi con la configurazione del ripristino di emergenza regionale di ODF, consulta la sezione " Verifica della configurazione del ripristino di emergenza regionale di Data Foundation di OpenShift" per controllare lo stato di integrità di ciascun componente della tua configurazione.

Applicazioni e carichi di lavoro supportati

Una volta completata la configurazione, verifica i tipi di applicazioni e carichi di lavoro per i quali è possibile applicare il Disaster Recovery regionale.

In abbonamento

Un'applicazione viene distribuita da una fonte esterna, come GitHub, un repo Helm o Object Storage.

Per ulteriori informazioni, vedere Creazione di un'applicazione di esempio basata sulle sottoscrizioni nella documentazione di Red Hat.

ApplicationSet-based

Un'applicazione viene distribuita da un repository GitHub utilizzando l'operatore GitOps, che gestisce la distribuzione continua. Questo include due sottotipi:

• GitOps Modello pull ( ArgoCD pull): Un cluster gestito estrae l'applicazione da GitHub utilizzando l'operatore GitOps.

• GitOps Modello push ( ArgoCD push): L'operatore di GitOps spinge l'applicazione nel cluster gestito durante le distribuzioni e gli aggiornamenti.

Per ulteriori informazioni, vedere Creazione di applicazioni basate su set di applicazioni nella documentazione di Red Hat.

Per ulteriori informazioni sui sottotipi di GitOps, vedere Deploying Argo CD with Push and Pull model nella documentazione di Red Hat.

Applicazioni scoperte

Un'applicazione è stata preinstallata in un cluster gestito senza utilizzare ACM. In questo caso, è possibile utilizzare il rilevamento ACM per l'applicazione preinstallata e configurare comunque il criterio DR.

Per ulteriori informazioni, consultare la sezione Protezione del ripristino di emergenza per le applicazioni scoperte nella documentazione di Red Hat.

Applicazioni che includono le implementazioni di VM

Un'applicazione basata su VM viene distribuita sul cluster gestito dalla console ACM. Queste applicazioni VM possono essere basate su abbonamento, ApplicationSet-based, oppure individuate, come descritto in precedenza. Per questi tipi di applicazioni, dalla console ACM sono disponibili opzioni per avviare, arrestare, mettere in pausa ed eliminare le operazioni dell' VM.

Per ulteriori informazioni, consultare Red Hat Advanced Cluster Management for Virtualization nella documentazione di Red Hat.