mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
70 lines
4.0 KiB
Plaintext
70 lines
4.0 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * migrating_from_ocp_3_to_4/about-mtc-3-4.adoc
|
|
// * migrating_from_ocp_3_to_4/advanced-migration-options-3-4.adoc
|
|
// * migration_toolkit_for_containers/about-mtc.adoc
|
|
// * migration_toolkit_for_containers/advanced-migration-options-mtc.adoc
|
|
|
|
[id="migration-mtc-workflow_{context}"]
|
|
= {mtc-short} workflow
|
|
|
|
You can migrate Kubernetes resources, persistent volume data, and internal container images to {product-title} {product-version} by using the {mtc-first} web console or the Kubernetes API.
|
|
|
|
{mtc-short} migrates the following resources:
|
|
|
|
* A namespace specified in a migration plan.
|
|
* Namespace-scoped resources: When the {mtc-short} migrates a namespace, it migrates all the objects and resources associated with that namespace, such as services or pods. Additionally, if a resource that exists in the namespace but not at the cluster level depends on a resource that exists at the cluster level, the {mtc-short} migrates both resources.
|
|
+
|
|
For example, a security context constraint (SCC) is a resource that exists at the cluster level and a service account (SA) is a resource that exists at the namespace level. If an SA exists in a namespace that the {mtc-short} migrates, the {mtc-short} automatically locates any SCCs that are linked to the SA and also migrates those SCCs. Similarly, the {mtc-short} migrates persistent volumes that are linked to the persistent volume claims of the namespace.
|
|
+
|
|
[NOTE]
|
|
====
|
|
Cluster-scoped resources might have to be migrated manually, depending on the resource.
|
|
====
|
|
|
|
* Custom resources (CRs) and custom resource definitions (CRDs): {mtc-short} automatically migrates CRs and CRDs at the namespace level.
|
|
|
|
Migrating an application with the {mtc-short} web console involves the following steps:
|
|
|
|
. Install the {mtc-full} Operator on all clusters.
|
|
+
|
|
You can install the {mtc-full} Operator in a restricted environment with limited or no internet access. The source and target clusters must have network access to each other and to a mirror registry.
|
|
|
|
. Configure the replication repository, an intermediate object storage that {mtc-short} uses to migrate data.
|
|
+
|
|
The source and target clusters must have network access to the replication repository during migration. If you are using a proxy server, you must configure it to allow network traffic between the replication repository and the clusters.
|
|
|
|
. Add the source cluster to the {mtc-short} web console.
|
|
. Add the replication repository to the {mtc-short} web console.
|
|
. Create a migration plan, with one of the following data migration options:
|
|
|
|
* *Copy*: {mtc-short} copies the data from the source cluster to the replication repository, and from the replication repository to the target cluster.
|
|
+
|
|
[NOTE]
|
|
====
|
|
If you are using direct image migration or direct volume migration, the images or volumes are copied directly from the source cluster to the target cluster.
|
|
====
|
|
+
|
|
image::migration-PV-copy.png[]
|
|
|
|
* *Move*: {mtc-short} unmounts a remote volume, for example, NFS, from the source cluster, creates a PV resource on the target cluster pointing to the remote volume, and then mounts the remote volume on the target cluster. Applications running on the target cluster use the same remote volume that the source cluster was using. The remote volume must be accessible to the source and target clusters.
|
|
+
|
|
[NOTE]
|
|
====
|
|
Although the replication repository does not appear in this diagram, it is required for migration.
|
|
====
|
|
+
|
|
image::migration-PV-move.png[]
|
|
|
|
. Run the migration plan, with one of the following options:
|
|
|
|
* *Stage* copies data to the target cluster without stopping the application.
|
|
+
|
|
A stage migration can be run multiple times so that most of the data is copied to the target before migration. Running one or more stage migrations reduces the duration of the cutover migration.
|
|
|
|
* *Cutover* stops the application on the source cluster and moves the resources to the target cluster.
|
|
+
|
|
Optional: You can clear the *Halt transactions on the source cluster during migration* checkbox.
|
|
|
|
image::OCP_3_to_4_App_migration.png[]
|