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

Gruppo di hub

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 sia in esecuzione RHCOS, di una capacità di calcolo 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.27_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

Gruppo di hub

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. Se si utilizza la versione ODF 4.21 o successive, installare l'operatore OpenShift GitOps sul cluster hub. Per le istruzioni di installazione, consultare la guida " Installazione di Red Hat OpenShift GitOps Operator nella console web ".

Passo 3. Creare i cluster gestiti

Cluster gestito

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.27_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.27_openshift --workers 3 --cos-instance COS_CRN --disable-outbound-traffic-protection --cni OVNKubernetes
   

Passo 4. Preparare i segreti per l'ACM

Gruppo di hub

Per ogni cluster che si desidera gestire con ACM, è necessario creare un segreto sul cluster hub che includa il token di accesso e l' URL e del server del cluster gestito.

Se si desidera importare cluster gestiti durante la procedura di installazione del componente aggiuntivo ACM, eseguire i passaggi seguenti prima di avviare l'installazione. Se si sceglie di creare i segreti e importare i cluster gestiti dopo l'installazione dell'add-on sul cluster hub, è possibile farlo completando alcuni passaggi aggiuntivi tramite la CLI.

Eseguire i passaggi seguenti per ogni cluster che si desidera gestire.

1. Sul cluster che si desidera gestire con ACM, eseguire il comando per individuare il server URL. Nell'output, individuare e annotare il valore "Master URL ". Questo è il server URL da indicare nel segreto. Utilizza questo link URL anche nei passaggi seguenti.

   ibmcloud oc cluster get -c CLUSTER_NAME_OR_ID
   

   Output di esempio.

   NAME:                           mycluster
   ID:                             1234567
   State:                          normal
   Created:                        2025-01-22T19:22:16+0000
   Location:                       dal10
   Master URL:                     https://c100-e.<region>.containers.cloud.ibm.com:<port>
   ...
   

2. Recupera l' URL e di base del server OAuth Red Hat OpenShift. Sostituisci MASTER_URL con l' URL e individuato nel passaggio precedente. Il comando estrae l' URL e di base senza il suffisso /oauth/token.

   curl -sS MASTER_URL/.well-known/oauth-authorization-server | jq -r .token_endpoint | sed 's#/oauth/token##'
   

   Output di esempio.

   https://c111-e.us-east.containers.cloud.ibm.com:31282
   

3. Recuperare un token di accesso utilizzando l'endpoint ottenuto nel passaggio precedente. Esegui il seguente comando cURL, sostituendo URL con l'output del passaggio precedente e API_KEY con il tuo [IBM Cloud Chiave API](https://cloud.ibm.com/iam/apikeys){: external}. Nell'output, individua l' ACCESS_TOKEN e contenuto nella risposta "Location ". Questo è il token di accesso da includere nel segreto.

   Richiesta curl di esempio:

   curl -u 'apikey:API_KEY' -H "X-CSRF-Token: a" 'URL/oauth/authorize?client_id=openshift-challenging-client&response_type=token' -vvv
   

   Output di esempio. L'ACCESS_TOKEN è incluso nella stringa di risposta di Location.

   < HTTP/1.1 302 Found
   < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
   < Cache-Control: no-cache, no-store, max-age=0, must-revalidate
   < Expires: 0
   < Expires: Fri, 01 Jan 2030 00:00:00 GMT
   < Location: TOKEN_ENDPOINT/oauth/token/implicit#access_token=ACCESS_TOKEN&expires_in=86400&scope=user%3Afull&token_type=Bearer
   ...
   

4. Nel cluster hub, creare un segreto contenente il token di accesso al cluster e l' URL e del server. Per informazioni sulla creazione dei segreti, consultare la sezione " Utilizzo dei segreti " nella documentazione di Kubernetes.

   Esempio di segreto.

   apiVersion: v1
   kind: Secret
   metadata:
     name: SECRET_NAME
     namespace: SECRET_NAMESPACE  # The namespace that the secret is to be created in
   type: Opaque
   stringData:
     token: ACCESS_TOKEN
     server: SERVER_URL
   

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

Gruppo di hub

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. Se desideri importare i cluster che dovranno essere gestiti dal componente aggiuntivo, segui i passaggi descritti nella sezione " Preparazione dei segreti per ACM ", se non l'hai già fatto. Assicurati di salvare l'ID del cluster, il nome e lo spazio dei nomi del segreto che crei sul cluster hub. È possibile completare questa procedura anche dopo l'installazione del componente aggiuntivo sul cluster hub; tuttavia, per importare i cluster gestiti dopo l'installazione sono necessari ulteriori passaggi.

4. Esegui il comando per abilitare il componente aggiuntivo. Assicurati di specificare i parametri billingPlan e isLicenseAccepted, oltre al parametro opzionale --managedClusters se desideri importare i cluster durante il processo di installazione.

   ibmcloud oc cluster addon enable acm --cluster HUB_CLUSTER_ID --param 'managedClusters=["clusterid:CLUSTER_ID;secretname:SECRET_NAME;secretnamespace:SECRET_NAMESPACE;action:IMPORT"]' --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 'managedClusters=["]

   Facoltativo. Inserire questo parametro una o più volte per importare i cluster gestiti durante il processo di installazione del componente aggiuntivo. Puoi anche completare questo passaggio in un secondo momento. Per ulteriori informazioni, consultare la sezione " Preparazione dei segreti per ACM ".

   Specificare i seguenti valori:

   • clusterid: l'ID del cluster gestito da importare.

   • secretname: il nome del segreto creato sul cluster hub. Questo segreto contiene le credenziali del cluster gestito.

   • secretnamespace: lo spazio dei nomi del segreto creato sul cluster hub. Questo segreto contiene le credenziali del cluster gestito.

   • action:IMPORT: il parametro che specifica l'azione IMPORT per il cluster gestito.

   --param 'billingPlan='

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

   --param 'isLicenseAccepted='

   Obbligatorio. Specificare " TRUE " per accettare il contratto di licenza relativo al piano di fatturazione selezionato. 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 e importare un cluster gestito.

   ibmcloud ks cluster addon enable acm --cluster a5bcde982dfer2nwxq73 --param 'managedClusters=["clusterid:w7rthce34gfbq7ww12d3;secretname:managed-secret-1;secretnamespace:managed-ns1;action:Import"]' --param 'billingPlan=KUBERNETES' --param 'isLicenseAccepted=true'
   

5. 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 acmhubstatus
       ```
       Output di esempio.
   
       ```sh {: screen}
       status
           phase: Ready
       ```
   

Passo 6. Configurare il componente aggiuntivo Submariner

Cluster gestito

Seguite i passaggi per installare e configurare il componente aggiuntivo Submariner, che stabilisce la connettività tra i due cluster gestiti. Questi passaggi utilizzano la console ACM. Per informazioni più dettagliate, consultare la sezione " Distribuzione di Submariner tramite la console " nella documentazione di Red Hat.

1. Accedere alla console ACM. Quindi fare clic su Gestione flotta > Infrastruttura > Cluster > Clusteret.
2. Fare clic su Crea un set di cluster. Seguite i prompt per aggiungere i due cluster gestiti al set di cluster.
3. Fare clic sull'opzione per installare il componente aggiuntivo Submariner nel set di cluster.
4. Selezionare i cluster gestiti come cluster di destinazione per l'installazione del componente aggiuntivo.
5. Quando si rivede la configurazione per entrambi i cluster, modificare le seguenti impostazioni come mostrato e lasciare il resto come predefinito. Quindi fare clic su Installa.

   globalnetEnabled: true (checked)
   gateways: 2
   NATTEnable: false (unchecked)
   cableDriver: vxlan.
   

6. Attendere che lo stato dell'add-on Submariner sia a posto (verde). L'operazione può richiedere fino a 20 minuti.

Passo 7. Installare e configurare OpenShift Data Foundation

Cluster gestito

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

1. Seguire i passaggi per installare il componente aggiuntivo OpenShift Data Foundation sui 2 cluster gestiti. Specificare la versione ODF predefinita o successiva. Assicuratevi di includere l'opzione per abilitare NooBaa come opzione aggiuntiva durante l'installazione.

2. Verificare che la fondazione ODF sia stata installata correttamente. Nell'output, verificare che lo stato indichi Ready.

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

3. Eseguire il comando per aggiornare 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.

   Assicurarsi di sostituire MANAGED_CLUSTER_NAME nel comando con il nome del cluster gestito.

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

4. 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
   

5. Creare un servizio di esportazione per ocs-provider-server utilizzando il seguente YAML.

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

6. 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.
   

7. 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

Gruppo di hub

Installa ODF Multicluster Orchestrator sul tuo cluster hub e crea la politica di DR che consente il mirroring tra i tuoi due cluster gestiti.

1. Seguire i passaggi per installare ODF Multicluster Orchestrator sul cluster hub ACM. Per garantire la compatibilità, assicurarsi di installare lo stesso numero di versione della versione di ODF installata sui cluster gestiti nella sezione precedente.

2. Verificare l'installazione controllando che le unità operatore siano in funzione.

   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. Sul cluster hub ACM, creare un criterio DR con un intervallo di sincronizzazione di 5 minuti e specificare ogni cluster gestito nei parametri. Questo crea i bucket di oggetti NooBaa su entrambi i cluster gestiti e abilita il mirroring del pool di blocchi ODF Ceph per la replica dei volumi.

   1. Accedere alla console ACM, quindi fare clic su Gestione flotta > Servizi dati > Disaster Recovery > Criteri > Crea criterio DR.
   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

4. Sul cluster hub, eseguire i comandi per verificare che il criterio DR sia stato creato e applicato ai cluster gestiti.

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

   oc get drclusters
   

   Output di esempio.

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

5. Su ogni cluster gestito, verificare che il criterio DR sia stato applicato e sia in uno stato sano.

   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.