Migration von Version 3 zu 4

Vorgehensweise

1. Platzieren Sie eine externe Netzwerkkomponente, wie z. B. einen Anwendungs-Lastenverteiler oder einen Reverse-Proxy, zwischen den Clients und dem Ziel-Cluster.
2. Aktualisieren Sie den FQDN der Anwendung auf dem Quell-Cluster im DNS-Server, um die IP-Adresse der externen Netzwerkkomponente zurückzugeben.
3. Konfigurieren Sie die Netzwerkkomponente so, dass sie für die Anwendung in der Quell-Domain empfangene Anfragen an den Lastenverteiler in der Ziel-Cluster-Domain sendet.
4. Erstellen Sie einen Platzhalter-DNS-Eintrag für die Domain *.apps.source.example.com, der auf die IP-Adresse des Lastenverteilers des Quell-Clusters verweist.
5. Erstellen Sie für jede Anwendung einen DNS-Eintrag, der auf die IP-Adresse der externen Netzwerkkomponente vor dem Ziel-Cluster verweist. Ein spezifischer DNS-Eintrag hat eine höhere Priorität als ein Platzhalter-Eintrag, sodass bei der Auflösung des FQDN der Anwendung kein Konflikt entsteht.

1. Erstellen Sie im Projekt des Ziel-Clusters eine Route, die so konfiguriert ist, dass sie Anfragen annimmt, die an den FQDN der Anwendung im Quell-Cluster gerichtet sind:

   $ oc expose svc <app1-svc> --hostname <app1.apps.source.example.com> \
    -n <app1-namespace>

   Copy to Clipboard Toggle word wrap

   Mit dieser neuen Route nimmt der Server jede Anfrage für diesen FQDN an und sendet sie an die entsprechenden Anwendungs-Pods. Darüber hinaus wird bei der Migration der Anwendung eine weitere Route in der Ziel-Cluster-Domain erstellt. Anfragen erreichen die migrierte Anwendung über einen dieser beiden Hostnamen.

2. Erstellen Sie einen DNS-Eintrag bei Ihrem DNS-Anbieter, der den FQDN der Anwendung im Quell-Cluster auf die IP-Adresse des Standard-Lastenverteilers des Ziel-Clusters verweist. Dadurch wird der Datenverkehr von Ihrem Quell-Cluster zu Ihrem Ziel-Cluster umgeleitet.

   Der FQDN der Anwendung wird zum Lastenverteiler des Ziel-Clusters aufgelöst. Der standardmäßige Ingress-Controller-Router akzeptiert Anfragen für diesen FQDN, da eine Route für diesen Hostnamen zugänglich ist.

1. Ersetzen Sie das x509-Zertifikat des standardmäßigen Ingress-Controllers, das während des Installationsvorgangs erstellt wurde, durch ein benutzerdefiniertes Zertifikat.

2. Konfigurieren Sie dieses Zertifikat so, dass es die Platzhalter-DNS-Domains für den Quell- und den Ziel-Cluster im Feld subjectAltName enthält.

   Das neue Zertifikat ist für die Sicherung von Verbindungen gültig, die über eine der beiden DNS-Domains hergestellt werden.

Vorgehensweise

1. Ermitteln Sie den S3-Endpunkt, die AWS_ACCESS_KEY_ID und den AWS_SECRET_ACCESS_KEY, indem Sie den Befehl describe für die benutzerdefinierte NooBaa-Ressource ausführen.

   Sie verwenden diese Anmeldedaten, um MCG als Replikations-Repository hinzuzufügen.

Vorgehensweise

1. Legen Sie die Variable BUCKET fest:

   $ BUCKET=<your_bucket>

   Copy to Clipboard Toggle word wrap

2. Legen Sie die Variable REGION fest:

   $ REGION=<your_region>

   Copy to Clipboard Toggle word wrap

3. Erstellen Sie einen AWS S3-Bucket:

   $ aws s3api create-bucket \
       --bucket $BUCKET \
       --region $REGION \
       --create-bucket-configuration LocationConstraint=$REGION 

   1

   Copy to Clipboard Toggle word wrap

   1

   us-east-1 unterstützt keinen LocationConstraint. Wenn Ihre Region us-east-1 ist, lassen Sie --create-bucket-configuration LocationConstraint=$REGION weg.

4. Erstellen Sie einen IAM-Benutzer:

   $ aws iam create-user --user-name velero 

   1

   Copy to Clipboard Toggle word wrap

   1

   Wenn Sie Velero für die Sicherung mehrerer Cluster mit mehreren S3-Buckets verwenden möchten, erstellen Sie für jeden Cluster einen eindeutigen Benutzernamen.

5. Erstellen Sie die Datei velero-policy.json:

   $ cat > velero-policy.json <<EOF
   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "ec2:DescribeVolumes",
                   "ec2:DescribeSnapshots",
                   "ec2:CreateTags",
                   "ec2:CreateVolume",
                   "ec2:CreateSnapshot",
                   "ec2:DeleteSnapshot"
               ],
               "Resource": "*"
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:GetObject",
                   "s3:DeleteObject",
                   "s3:PutObject",
                   "s3:AbortMultipartUpload",
                   "s3:ListMultipartUploadParts"
               ],
               "Resource": [
                   "arn:aws:s3:::${BUCKET}/*"
               ]
           },
           {
               "Effect": "Allow",
               "Action": [
                   "s3:ListBucket"
               ],
               "Resource": [
                   "arn:aws:s3:::${BUCKET}"
               ]
           }
       ]
   }
   EOF

   Copy to Clipboard Toggle word wrap

6. Fügen Sie die Richtlinien hinzu, um dem Benutzer velero die erforderlichen Berechtigungen zu erteilen:

   $ aws iam put-user-policy \
     --user-name velero \
     --policy-name velero \
     --policy-document file://velero-policy.json

   Copy to Clipboard Toggle word wrap

7. Erstellen Sie einen Zugriffsschlüssel für den Benutzer velero:

   $ aws iam create-access-key --user-name velero

   Copy to Clipboard Toggle word wrap

   Beispielausgabe

   {
     "AccessKey": {
           "UserName": "velero",
           "Status": "Active",
           "CreateDate": "2017-07-31T22:24:41.576Z",
           "SecretAccessKey": <AWS_SECRET_ACCESS_KEY>,
           "AccessKeyId": <AWS_ACCESS_KEY_ID>
     }
   }

   Copy to Clipboard Toggle word wrap

   Halten Sie den AWS_SECRET_ACCESS_KEY und die AWS_ACCESS_KEY_ID fest. Sie benötigen die Anmeldedaten, um AWS als Replikations-Repository hinzuzufügen.

Vorgehensweise

1. Melden Sie sich bei GCP an:

   $ gcloud auth login

   Copy to Clipboard Toggle word wrap

2. Legen Sie die Variable BUCKET fest:

   $ BUCKET=<bucket> 

   1

   Copy to Clipboard Toggle word wrap

   1

   Geben Sie den Namen Ihres Buckets an.

3. Erstellen Sie den Speicher-Bucket:

   $ gsutil mb gs://$BUCKET/

   Copy to Clipboard Toggle word wrap

4. Legen Sie für die Variable PROJECT_ID Ihr aktives Projekt fest:

   $ PROJECT_ID=$(gcloud config get-value project)

   Copy to Clipboard Toggle word wrap

5. Erstellen Sie einen Service Account:

   $ gcloud iam service-accounts create velero \
       --display-name "Velero service account"

   Copy to Clipboard Toggle word wrap

6. Listen Sie Ihre Service Accounts auf:

   $ gcloud iam service-accounts list

   Copy to Clipboard Toggle word wrap

7. Legen Sie für die Variable SERVICE_ACCOUNT_EMAIL den entsprechenden email-Wert fest:

   $ SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \
       --filter="displayName:Velero service account" \
       --format 'value(email)')

   Copy to Clipboard Toggle word wrap

8. Fügen Sie die Richtlinien hinzu, um dem Benutzer velero die erforderlichen Berechtigungen zu erteilen:

   $ ROLE_PERMISSIONS=(
       compute.disks.get
       compute.disks.create
       compute.disks.createSnapshot
       compute.snapshots.get
       compute.snapshots.create
       compute.snapshots.useReadOnly
       compute.snapshots.delete
       compute.zones.get
   )

   Copy to Clipboard Toggle word wrap

9. Erstellen Sie die benutzerdefinierte Rolle velero.server:

   $ gcloud iam roles create velero.server \
       --project $PROJECT_ID \
       --title "Velero Server" \
       --permissions "$(IFS=","; echo "${ROLE_PERMISSIONS[*]}")"

   Copy to Clipboard Toggle word wrap

10. Fügen Sie dem Projekt eine IAM-Richtlinienbindung hinzu:

    $ gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \
        --role projects/$PROJECT_ID/roles/velero.server

    Copy to Clipboard Toggle word wrap

11. Aktualisieren Sie den IAM-Service Account:

    $ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}

    Copy to Clipboard Toggle word wrap

12. Speichern Sie die Schlüssel des IAM-Service Accounts in der Datei credentials-velero im aktuellen Verzeichnis:

    $ gcloud iam service-accounts keys create credentials-velero \
        --iam-account $SERVICE_ACCOUNT_EMAIL

    Copy to Clipboard Toggle word wrap

    Sie verwenden die Datei credentials-velero, um GCP als Replikations-Repository hinzuzufügen.

Vorgehensweise

1. Melden Sie sich bei Azure an:

   $ az login

   Copy to Clipboard Toggle word wrap

2. Legen Sie die Variable AZURE_RESOURCE_GROUP fest:

   $ AZURE_RESOURCE_GROUP=Velero_Backups

   Copy to Clipboard Toggle word wrap

3. Erstellen Sie eine Azure-Ressourcengruppe:

   $ az group create -n $AZURE_RESOURCE_GROUP --location CentralUS 

   1

   Copy to Clipboard Toggle word wrap

   1

   Geben Sie Ihren Standort an.

4. Legen Sie die Variable AZURE_STORAGE_ACCOUNT_ID fest:

   $ AZURE_STORAGE_ACCOUNT_ID="velero$(uuidgen | cut -d '-' -f5 | tr '[A-Z]' '[a-z]')"

   Copy to Clipboard Toggle word wrap

5. Erstellen Sie ein Azure-Speicherkonto:

   $ az storage account create \
       --name $AZURE_STORAGE_ACCOUNT_ID \
       --resource-group $AZURE_BACKUP_RESOURCE_GROUP \
       --sku Standard_GRS \
       --encryption-services blob \
       --https-only true \
       --kind BlobStorage \
       --access-tier Hot

   Copy to Clipboard Toggle word wrap

6. Legen Sie die Variable BLOB_CONTAINER fest:

   $ BLOB_CONTAINER=velero

   Copy to Clipboard Toggle word wrap

7. Erstellen Sie einen Azure Blob-Speichercontainer:

   $ az storage container create \
     -n $BLOB_CONTAINER \
     --public-access off \
     --account-name $AZURE_STORAGE_ACCOUNT_ID

   Copy to Clipboard Toggle word wrap

8. Erstellen Sie einen Service Principal und Anmeldedaten für velero:

   $ AZURE_SUBSCRIPTION_ID=`az account list --query '[?isDefault].id' -o tsv` \
     AZURE_TENANT_ID=`az account list --query '[?isDefault].tenantId' -o tsv` \
     AZURE_CLIENT_SECRET=`az ad sp create-for-rbac --name "velero" \
     --role "Contributor" --query 'password' -o tsv` \
     AZURE_CLIENT_ID=`az ad sp list --display-name "velero" \
     --query '[0].appId' -o tsv`

   Copy to Clipboard Toggle word wrap

9. Speichern Sie die Anmeldedaten des Service Principal in der Datei credentials-velero:

   $ cat << EOF > ./credentials-velero
   AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID}
   AZURE_TENANT_ID=${AZURE_TENANT_ID}
   AZURE_CLIENT_ID=${AZURE_CLIENT_ID}
   AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET}
   AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP}
   AZURE_CLOUD_NAME=AzurePublicCloud
   EOF

   Copy to Clipboard Toggle word wrap

   Sie verwenden die Datei credentials-velero, um Azure als Replikations-Repository hinzuzufügen.

Vorgehensweise

1. Ermitteln Sie den S3-Endpunkt, die AWS_ACCESS_KEY_ID und den AWS_SECRET_ACCESS_KEY, indem Sie den Befehl describe für die benutzerdefinierte NooBaa-Ressource ausführen.

Vorgehensweise

1. Melden Sie sich bei dem OpenShift Container Platform-Cluster an, auf dem Sie MTC installiert haben.

2. Rufen Sie die URL der MTC-Webkonsole durch Eingabe des folgenden Befehls auf:

   $ oc get -n openshift-migration route/migration -o go-template='https://{{ .spec.host }}'

   Copy to Clipboard Toggle word wrap

   Die Ausgabe sieht folgendermaßen aus: https://migration-openshift-migration.apps.cluster.openshift.com.

3. Starten Sie einen Browser und navigieren Sie zur MTC-Webkonsole.

   Anmerkung

   Wenn Sie versuchen, unmittelbar nach der Installation des Migration Toolkit for Containers Operator auf die MTC-Webkonsole zuzugreifen, kann es sein, dass die Konsole nicht geladen wird, weil der Operator noch mit der Konfiguration des Clusters beschäftigt ist. Warten Sie ein paar Minuten und versuchen Sie es erneut.

4. Wenn Sie selbstsignierte CA-Zertifikate verwenden, werden Sie aufgefordert, das CA-Zertifikat vom API-Server des Quell-Clusters zu akzeptieren. Die Webseite führt Sie durch den Annahmevorgang der restlichen Zertifikate.
5. Melden Sie sich mit Ihrem OpenShift Container Platform-Benutzernamen und -Passwort an.

Vorgehensweise

1. Melden Sie sich beim Cluster an.

2. Rufen Sie das Service Account-Token migration-controller ab:

   $ oc sa get-token migration-controller -n openshift-migration

   Copy to Clipboard Toggle word wrap

   Beispielausgabe

   eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJtaWciLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoibWlnLXRva2VuLWs4dDJyIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6Im1pZyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImE1YjFiYWMwLWMxYmYtMTFlOS05Y2NiLTAyOWRmODYwYjMwOCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDptaWc6bWlnIn0.xqeeAINK7UXpdRqAtOj70qhBJPeMwmgLomV9iFxr5RoqUgKchZRG2J2rkqmPm6vr7K-cm7ibD1IBpdQJCcVDuoHYsFgV4mp9vgOfn9osSDp2TGikwNz4Az95e81xnjVUmzh-NjDsEpw71DH92iHV_xt2sTwtzftS49LpPW2LjrV0evtNBP_t_RfskdArt5VSv25eORl7zScqfe1CiMkcVbf2UqACQjo3LbkpfN26HAioO2oH0ECPiRzT0Xyh-KwFutJLS9Xgghyw-LD9kPKcE_xbbJ9Y4Rqajh7WdPYuB0Jd9DPVrslmzK-F6cgHHYoZEv0SvLQi-PO0rpDrcjOEQQ

   Copy to Clipboard Toggle word wrap

3. Klicken Sie in der MTC-Webkonsole auf Clusters.
4. Klicken Sie auf Add Cluster.

5. Füllen Sie die folgenden Felder aus:

   • Cluster name: Der Clustername kann Kleinbuchstaben (a-z) und Zahlen (0-9) enthalten. Er darf keine Leerzeichen oder internationalen Zeichen enthalten.
   • URL: Geben Sie die URL des API-Servers an, z. B. https://<www.example.com>:8443.
   • Service account token: Fügen Sie das Service Account-Token migration-controller ein.

   • Exposed route host to image registry: Wenn Sie die Direct Image Migration verwenden, geben Sie die verfügbare Route zur Image-Registrierung des Quell-Clusters an.

     Um die Route zu erstellen, führen Sie den folgenden Befehl aus:

     • Für OpenShift Container Platform 3:

       $ oc create route passthrough --service=docker-registry --port=5000 -n default

       Copy to Clipboard Toggle word wrap

     • Für OpenShift Container Platform 4:

       $ oc create route passthrough --service=image-registry --port=5000 -n openshift-image-registry

       Copy to Clipboard Toggle word wrap
   • Azure cluster: Sie müssen diese Option auswählen, wenn Sie Azure-Schnappschüsse zum Kopieren Ihrer Daten verwenden.
   • Azure resource group: Dieses Feld wird angezeigt, wenn Azure cluster ausgewählt ist. Geben Sie die Azure-Ressourcengruppe an.
   • Require SSL verification: Optional: Wählen Sie diese Option, um SSL-Verbindungen zum Cluster zu verifizieren.
   • CA bundle file: Dieses Feld wird angezeigt, wenn die Option Require SSL verification erforderlich ausgewählt ist. Wenn Sie eine benutzerdefinierte Datei mit CA-Zertifikatpaket für selbstsignierte Zertifikate erstellt haben, klicken Sie auf Browse, wählen Sie die CA-Paketdatei aus und laden Sie sie hoch.

6. Klicken Sie auf Add Cluster.

   Der Cluster wird in der Liste Clusters angezeigt.

Vorgehensweise

1. Klicken Sie in der MTC-Webkonsole auf Replication repositories.
2. Klicken Sie auf Add repository.

3. Wählen Sie einen Storage provider type und füllen Sie die folgenden Felder aus:

   • AWS für S3-Anbieter, einschließlich AWS und MCG:

     • Replication repository name: Geben Sie den Namen des Replikations-Repositorys in der MTC-Webkonsole an.
     • S3 bucket name: Geben Sie den Namen des S3-Buckets an.
     • S3 bucket region: Geben Sie die Region des S3-Buckets an. Erforderlich für AWS S3. Optional für einige S3-Anbieter. Informieren Sie sich in der Produktdokumentation Ihres S3-Anbieters über die erwarteten Werte.
     • S3 endpoint: Geben Sie die URL des S3-Dienstes an, nicht den Bucket, zum Beispiel https://<s3-storage.apps.cluster.com>. Erforderlich für einen generischen S3-Anbieter. Sie müssen das Präfix https:// verwenden.
     • S3 provider access key: Geben Sie den <AWS_SECRET_ACCESS_KEY> für AWS oder den S3-Anbieter-Zugangsschlüssel für MCG und andere S3-Anbieter an.
     • S3 provider secret access key: Geben Sie die <AWS_ACCESS_KEY_ID> für AWS oder den geheimen S3-Anbieter-Zugangsschlüssel für MCG und andere S3-Anbieter an.
     • Require SSL verification: Deaktivieren Sie dieses Kontrollkästchen, wenn Sie einen generischen S3-Anbieter verwenden.
     • Wenn Sie ein benutzerdefiniertes CA-Zertifikatpaket für selbstsignierte Zertifikate erstellt haben, klicken Sie auf Browse und suchen Sie nach der base64-kodierten Datei.

   • GCP:

     • Replication repository name: Geben Sie den Namen des Replikations-Repositorys in der MTC-Webkonsole an.
     • GCP bucket name: Geben Sie den Namen des GCP-Buckets an.
     • GCP credential JSON blob: Geben Sie die Zeichenfolge in der Datei credentials-velero an.

   • Azure:

     • Replication repository name: Geben Sie den Namen des Replikations-Repositorys in der MTC-Webkonsole an.
     • Azure resource group: Geben Sie die Ressourcengruppe des Azure Blob-Speichers an.
     • Azure storage account name: Geben Sie den Namen des Azure Blob-Speicherkontos an.
     • Azure credentials - INI file contents: Geben Sie die Zeichenfolge in der Datei credentials-velero an.
4. Klicken Sie auf Add repository und warten Sie auf die Validierung der Verbindung.

5. Klicken Sie auf Close.

   Das neue Repository wird in der Liste Replication repositories angezeigt.

Vorgehensweise

1. Klicken Sie in der MTC-Webkonsole auf Migration plans.
2. Klicken Sie auf Add migration plan.

3. Geben Sie bei Plan name einen Namen ein.

   Der Name des Migrationsplans darf nicht mehr als 253 klein geschriebene alphanumerische Zeichen(a-z, 0-9) und keine Leerzeichen oder Unterstriche(_) enthalten.

4. Wählen Sie einen Source cluster, einen Target cluster und ein Repository aus.
5. Klicken Sie auf Next.
6. Wählen Sie die zu migrierenden Projekte aus.
7. Optional: Klicken Sie auf das Bearbeitungssymbol neben einem Projekt, um den Ziel-Namespace zu ändern.
8. Klicken Sie auf Next.

9. Wählen Sie einen Migration type für jedes PV:

   • Mit der Option Copy werden die Daten aus der PV eines Quell-Clusters in das Replikations-Repository kopiert und anschließend in einem neu erstellten PV mit ähnlichen Merkmalen im Ziel-Cluster wiederhergestellt.
   • Mit der Option Move wird die Bereitstellung eines Remote-Volume, z. B. NFS, auf dem Quell-Cluster aufgehoben, eine PV-Ressource auf dem Ziel-Cluster erstellt, die auf das Remote-Volume verweist, und dann das Remote-Volume auf dem Ziel-Cluster bereitgestellt. Anwendungen, die auf dem Ziel-Cluster ausgeführt werden, verwenden dasselbe Remote-Volume, das auch der Quell-Cluster verwendet hat.
10. Klicken Sie auf Next.

11. Wählen Sie eine Copy method für jedes PV:

    • Snapshot copy sichert und stellt Daten mithilfe der Schnappschuss-Funktionalität des Cloud-Anbieters wieder her. Dies ist wesentlich schneller als Filesystem copy.

    • Filesystem copy sichert die Dateien auf dem Quell-Cluster und stellt sie auf dem Ziel-Cluster wieder her.

      Die Methode der Dateisystemkopie ist für die Direct Volume Migration erforderlich.

12. Sie können die Option Verify copy wählen, um die mit Filesystem copy migrierten Daten zu verifizieren. Die Daten werden verifiziert, indem für jede Quelldatei eine Prüfsumme generiert und diese nach der Wiederherstellung überprüft wird. Die Datenverifizierung verringert die Leistung erheblich.

13. Wählen Sie eine Target storage class aus.

    Wenn Sie Filesystem copy gewählt haben, können Sie die Ziel-Speicherklasse ändern.

14. Klicken Sie auf Next.

15. Auf der Seite Migration options ist die Option Direct image migration ausgewählt, wenn Sie eine verfügbar Image-Registrierungsroute für den Quell-Cluster angegeben haben. Die Option Direct PV migration wird ausgewählt, wenn Sie die Daten mit Filesystem copy migrieren.

    Die direkten Migrationsoptionen kopieren Images und Dateien direkt vom Quell-Cluster auf den Ziel-Cluster. Diese Option ist wesentlich schneller als das Kopieren von Images und Dateien vom Quell-Cluster in das Replikations-Repository und anschließend vom Replikations-Repository in den Ziel-Cluster.

16. Klicken Sie auf Next.

17. Optional: Klicken Sie auf Add Hook, um dem Migrationsplan einen Hook hinzuzufügen.

    Ein Hook führt benutzerdefinierten Code aus. Sie können bis zu vier Hooks zu einem einzigen Migrationsplan hinzufügen. Jeder Hook wird während eines anderen Migrationsschritts ausgeführt.

    1. Geben Sie den Namen des Hooks ein, der in der Webkonsole angezeigt werden soll.
    2. Wenn es sich bei dem Hook um ein Ansible-Playbook handelt, wählen Sie Ansible playbook und klicken Sie auf Browse, um das Playbook hochzuladen, oder fügen Sie den Inhalt des Playbooks in das Feld ein.
    3. Optional: Geben Sie ein Ansible-Laufzeit-Image an, wenn Sie nicht das Standard-Hook-Image verwenden.

    4. Wenn es sich bei dem Hook nicht um ein Ansible-Playbook handelt, wählen Sie Custom container image und geben Sie den Namen und den Pfad des Images an.

       Ein benutzerdefiniertes Container-Image kann Ansible-Playbooks enthalten.

    5. Wählen Sie Source cluster oder Target cluster.
    6. Geben Sie bei Service account name und Service account namespace Werte ein.

    7. Wählen Sie den Migrationsschritt für den Hook:

       • preBackup: Bevor die Anwendungs-Workload auf dem Quell-Cluster gesichert wird
       • postBackup: Nachdem die Anwendungs-Workload auf dem Quell-Cluster gesichert wurde
       • preRestore: Bevor die Anwendungs-Workload auf dem Ziel-Cluster wiederhergestellt wird
       • postRestore: Nachdem die Anwendungs-Workload auf dem Ziel-Cluster wiederhergestellt wurde
    8. Klicken Sie auf Add.

18. Klicken Sie auf Finish.

    Der Migrationsplan wird in der Liste Migration plans angezeigt.

Vorgehensweise

1. Melden Sie sich bei der MTC-Webkonsole an und klicken Sie auf Migration plans.

2. Klicken Sie auf das Optionen-Menü neben einem Migrationsplan und wählen Sie eine der folgenden Optionen unter Migration:

   • Stage kopiert Daten aus dem Quell-Cluster in den Ziel-Cluster, ohne die Anwendung anzuhalten.

   • Cutover stoppt die Transaktionen auf dem Quell-Cluster und verschiebt die Ressourcen in den Ziel-Cluster.

     Optional: Im Dialogfeld Cutover migration können Sie das Kontrollkästchen Stop transactions on the source cluster during migration deaktivieren.

   • State kopiert ausgewählter Persistent Volume Claims (PVCs) und Kubernetes-Ressourcen, die den Status einer Anwendung bilden. Sie können die State-Migration verwenden, um einen Namespace innerhalb desselben Clusters zu migrieren.

     Wichtig

     Verwenden Sie die State-Migration nicht, um einen Namespace zwischen Clustern zu migrieren. Verwenden Sie stattdessen die Stage- oder Cutover-Migration.

     • Wählen Sie im Dialogfeld State migration ein oder mehrere PVCs aus und klicken Sie auf Migrate.

3. Wenn die Migration abgeschlossen ist, überprüfen Sie in der OpenShift Container Platform-Webkonsole, ob die Anwendung erfolgreich migriert wurde:

   1. Klicken Sie auf Home → Projects.
   2. Klicken Sie auf das migrierte Projekt, um seinen Status anzuzeigen.
   3. Klicken Sie im Bereich Routes auf Location, um zu verifizieren, ob die Anwendung funktioniert (falls zutreffend).
   4. Klicken Sie auf Workloads → Pods, um zu verifizieren, ob die Pods im migrierten Namespace ausgeführt werden.
   5. Klicken Sie auf Storage → Persistent Volumes, um zu überprüfen, ob die migrierten persistenten Volumes korrekt bereitgestellt wurden.

Vorgehensweise

1. Rufen Sie das CR-Manifest MigrationController ab:

   $ oc get migrationcontroller <migration_controller> -n openshift-migration

   Copy to Clipboard Toggle word wrap

2. Aktualisieren Sie die Proxy-Parameter:

   apiVersion: migration.openshift.io/v1alpha1
   kind: MigrationController
   metadata:
     name: <migration_controller>
     namespace: openshift-migration
   ...
   spec:
     stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port> 

   1

   
     httpProxy: http://<username>:<password>@<ip>:<port> 

   2

   
     httpsProxy: http://<username>:<password>@<ip>:<port> 

   3

   
     noProxy: example.com 

   4

   Copy to Clipboard Toggle word wrap

   1

   Stunnel-Proxy-URL für die Direct Volume Migration.

   2

   Proxy-URL für die Erstellung von HTTP-Verbindungen außerhalb des Clusters. Das URL-Schema muss http sein.

   3

   Proxy-URL für die Erstellung von HTTPS-Verbindungen außerhalb des Clusters. Wenn dies nicht angegeben wird, wird httpProxy sowohl für HTTP- als auch für HTTPS-Verbindungen verwendet.

   4

   Durch Kommata getrennte Liste von Zieldomain-Namen, Domains, IP-Adressen oder anderen Netzwerk-CIDRs zum Ausschluss von Proxying.

   Stellen Sie einer Domain ein . voran, um nur Subdomains zu finden. Zum Beispiel gibt es bei .y.com eine Übereinstimmung mit x.y.com, aber nicht mit y.com. Verwenden Sie *, um den Proxy für alle Ziele zu umgehen. Wenn Sie Worker hochskalieren, die nicht in dem durch das Installationskonfigurationsfeld networking.machineNetwork[].cidr definierten Netzwerk enthalten sind, müssen Sie sie zu dieser Liste hinzufügen, um Verbindungsprobleme zu vermeiden.

   Dieses Feld wird ignoriert, wenn weder das Feld httpProxy noch das Feld httpsProxy konfiguriert ist.

3. Speichern Sie das Manifest als migration-controller.yaml.

4. Wenden Sie das aktualisierte Manifest an:

   $ oc replace -f migration-controller.yaml -n openshift-migration

   Copy to Clipboard Toggle word wrap

Vorgehensweise

1. Erstellen Sie ein MigCluster-CR-Manifest für den Host-Cluster:

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <host_cluster>
     namespace: openshift-migration
   spec:
     isHostCluster: true
   EOF

   Copy to Clipboard Toggle word wrap

2. Erstellen Sie ein Secret-Objektmanifest für jeden Remote-Cluster:

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: <cluster_secret>
     namespace: openshift-config
   type: Opaque
   data:
     saToken: <sa_token> 

   1

   
   EOF

   Copy to Clipboard Toggle word wrap

   1

   Geben Sie das base64-kodierte SA-Token (Service Account) migration-controller des Remote-Clusters an. Sie erhalten das Token, indem Sie den folgenden Befehl ausführen:

   $ oc sa get-token migration-controller -n openshift-migration | base64 -w 0

   Copy to Clipboard Toggle word wrap

3. Erstellen Sie für jeden Remote-Cluster ein MigCluster-CR-Manifest:

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigCluster
   metadata:
     name: <remote_cluster> 

   1

   
     namespace: openshift-migration
   spec:
     exposedRegistryPath: <exposed_registry_route> 

   2

   
     insecure: false 

   3

   
     isHostCluster: false
     serviceAccountSecretRef:
       name: <remote_cluster_secret> 

   4

   
       namespace: openshift-config
     url: <remote_cluster_url> 

   5

   
   EOF

   Copy to Clipboard Toggle word wrap

   1

   Geben Sie die CR Cluster des Remote-Clusters an.

   2

   Optional: Geben Sie für die Direct Image Migration die verfügbare Registrierungsroute an.

   3

   Bei false ist die SSL-Verifizierung aktiviert. CA-Zertifikate sind nicht erforderlich und werden nicht überprüft, wenn true.

   4

   Geben Sie das Objekt Secret des Remote-Clusters an.

   5

   Geben Sie die URL des Remote-Clusters an.

4. Verifizieren Sie, dass sich alle Cluster im Status Ready befinden:

   $ oc describe cluster <cluster>

   Copy to Clipboard Toggle word wrap

5. Erstellen Sie ein Secret-Objektmanifest für das Replikations-Repository:

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     namespace: openshift-config
     name: <migstorage_creds>
   type: Opaque
   data:
     aws-access-key-id: <key_id_base64> 

   1

   
     aws-secret-access-key: <secret_key_base64> 

   2

   
   EOF

   Copy to Clipboard Toggle word wrap

   1

   Geben Sie die Schlüssel-ID im base64-Format an.

   2

   Geben Sie den geheimen Schlüssel im base64-Format an.

   AWS-Anmeldedaten sind standardmäßig base64-kodiert. Bei anderen Speicheranbietern müssen Sie Ihre Anmeldedaten verschlüsseln, indem Sie den folgenden Befehl mit jedem Schlüssel ausführen:

   $ echo -n "<key>" | base64 -w 0 

   1

   Copy to Clipboard Toggle word wrap

   1

   Geben Sie die Schlüssel-ID oder den geheimen Schlüssel an. Beide Schlüssel müssen base64-kodiert sein.

6. Erstellen Sie ein MigStorage-CR-Manifest für das Replikations-Repository:

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigStorage
   metadata:
     name: <migstorage>
     namespace: openshift-migration
   spec:
     backupStorageConfig:
       awsBucketName: <bucket> 

   1

   
       credsSecretRef:
         name: <storage_secret> 

   2

   
         namespace: openshift-config
     backupStorageProvider: <storage_provider> 

   3

   
     volumeSnapshotConfig:
       credsSecretRef:
         name: <storage_secret> 

   4

   
         namespace: openshift-config
     volumeSnapshotProvider: <storage_provider> 

   5

   
   EOF

   Copy to Clipboard Toggle word wrap

   1

   Geben Sie den Bucket-Namen an.

   2

   Geben Sie die CR Secrets des Objektspeichers an. Sie müssen sicherstellen, dass die in der CR Secrets des Objektspeichers gespeicherten Anmeldedaten korrekt sind.

   3

   Geben Sie den Speicheranbieter an.

   4

   Optional: Wenn Sie Daten mit Hilfe von Schnappschüssen kopieren, geben Sie die CR Secrets des Objektspeichers an. Sie müssen sicherstellen, dass die in der CR Secrets des Objektspeichers gespeicherten Anmeldedaten korrekt sind.

   5

   Optional: Wenn Sie Daten mit Hilfe von Schnappschüssen kopieren, geben Sie den Speicheranbieter an.

7. Verifizieren Sie, dass die CR MigStorage den Status Ready hat:

   $ oc describe migstorage <migstorage>

   Copy to Clipboard Toggle word wrap

8. Erstellen Sie ein MigPlan-CR-Manifest:

   $ cat << EOF | oc apply -f -
   apiVersion: migration.openshift.io/v1alpha1
   kind: MigPlan
   metadata:
     name: <migplan>
     namespace: openshift-migration
   spec:
     destMigClusterRef:
       name: <host_cluster>
       namespace: openshift-migration
     indirectImageMigration: true 

   1

   
     indirectVolumeMigration: true 

   2

   
     migStorageRef:
       name: <migstorage> 

   3

   
       namespace: openshift-migration
     namespaces:
       - <source_namespace_1> 

   4

   
       - <source_namespace_2>
       - <source_namespace_3>:<destination_namespace> 

   5

   
     srcMigClusterRef:
       name: <remote_cluster> 

   6

   
       namespace: openshift-migration
   EOF

   Copy to Clipboard Toggle word wrap

   1

   Direct Image Migration ist aktiviert, wenn false.

   2

   Direct Volume Migration ist aktiviert, wenn false.

   3

   Geben Sie den Namen der CR-Instanz MigStorage an.

   4

   Geben Sie einen oder mehrere Quell-Namespaces an. Standardmäßig hat der Ziel-Namespace denselben Namen.

   5

   Geben Sie einen Ziel-Namespace an, wenn er sich vom Quell-Namespace unterscheidet.

   6

   Geben Sie den Namen der Instanz MigCluster des Quell-Clusters an.

9. Vergewissern Sie sich, dass die Instanz MigPlan sich im Status Ready befindet:

   $ oc describe migplan <migplan> -n openshift-migration

   Copy to Clipboard Toggle word wrap

10. Erstellen Sie ein MigMigration-CR-Manifest, um die in der Instanz MigPlan definierte Migration zu starten:

    $ cat << EOF | oc apply -f -
    apiVersion: migration.openshift.io/v1alpha1
    kind: MigMigration
    metadata:
      name: <migmigration>
      namespace: openshift-migration
    spec:
      migPlanRef:
        name: <migplan> 

    1

    
        namespace: openshift-migration
      quiescePods: true 

    2

    
      stage: false 

    3

    
      rollback: false 

    4

    
    EOF

    Copy to Clipboard Toggle word wrap

    1

    Geben Sie den Namen der CR MigPlan an.

    2

    Die Pods auf dem Quell-Cluster werden vor der Migration gestoppt, wenn true.

    3

    Wenn true, wird eine Stage-Migration durchgeführt, bei der die meisten Daten kopiert werden, ohne die Anwendung anzuhalten.

    4

    Eine abgeschlossene Migration wird rückgängig gemacht, wenn true.

11. Überprüfen Sie die Migration, indem Sie den Fortschritt der CR MigMigration beobachten:

    $ oc watch migmigration <migmigration> -n openshift-migration

    Copy to Clipboard Toggle word wrap

    Die Ausgabe sieht wie folgt aus:

    Beispielausgabe

    Name:         c8b034c0-6567-11eb-9a4f-0bc004db0fbc
    Namespace:    openshift-migration
    Labels:       migration.openshift.io/migplan-name=django
    Annotations:  openshift.io/touch: e99f9083-6567-11eb-8420-0a580a81020c
    API Version:  migration.openshift.io/v1alpha1
    Kind:         MigMigration
    ...
    Spec:
      Mig Plan Ref:
        Name:       migplan
        Namespace:  openshift-migration
      Stage:        false
    Status:
      Conditions:
        Category:              Advisory
        Last Transition Time:  2021-02-02T15:04:09Z
        Message:               Step: 19/47
        Reason:                InitialBackupCreated
        Status:                True
        Type:                  Running
        Category:              Required
        Last Transition Time:  2021-02-02T15:03:19Z
        Message:               The migration is ready.
        Status:                True
        Type:                  Ready
        Category:              Required
        Durable:               true
        Last Transition Time:  2021-02-02T15:04:05Z
        Message:               The migration registries are healthy.
        Status:                True
        Type:                  RegistriesHealthy
      Itinerary:               Final
      Observed Digest:         7fae9d21f15979c71ddc7dd075cb97061895caac5b936d92fae967019ab616d5
      Phase:                   InitialBackupCreated
      Pipeline:
        Completed:  2021-02-02T15:04:07Z
        Message:    Completed
        Name:       Prepare
        Started:    2021-02-02T15:03:18Z
        Message:    Waiting for initial Velero backup to complete.
        Name:       Backup
        Phase:      InitialBackupCreated
        Progress:
          Backup openshift-migration/c8b034c0-6567-11eb-9a4f-0bc004db0fbc-wpc44: 0 out of estimated total of 0 objects backed up (5s)
        Started:        2021-02-02T15:04:07Z
        Message:        Not started
        Name:           StageBackup
        Message:        Not started
        Name:           StageRestore
        Message:        Not started
        Name:           DirectImage
        Message:        Not started
        Name:           DirectVolume
        Message:        Not started
        Name:           Restore
        Message:        Not started
        Name:           Cleanup
      Start Timestamp:  2021-02-02T15:03:18Z
    Events:
      Type    Reason   Age                 From                     Message
      ----    ------   ----                ----                     -------
      Normal  Running  57s                 migmigration_controller  Step: 2/47
      Normal  Running  57s                 migmigration_controller  Step: 3/47
      Normal  Running  57s (x3 over 57s)   migmigration_controller  Step: 4/47
      Normal  Running  54s                 migmigration_controller  Step: 5/47
      Normal  Running  54s                 migmigration_controller  Step: 6/47
      Normal  Running  52s (x2 over 53s)   migmigration_controller  Step: 7/47
      Normal  Running  51s (x2 over 51s)   migmigration_controller  Step: 8/47
      Normal  Ready    50s (x12 over 57s)  migmigration_controller  The migration is ready.
      Normal  Running  50s                 migmigration_controller  Step: 9/47
      Normal  Running  50s                 migmigration_controller  Step: 10/47

    Copy to Clipboard Toggle word wrap