Se usó la API de Cloud Translation para traducir esta página.

Migración de almacenamiento con administración basada en políticas de almacenamiento

En este documento, se muestra cómo migrar discos de un almacén de datos de vSphere a otro almacén de datos de vSphere con administración basada en políticas de almacenamiento (SPBM).

1.29: Disponible de manera general
1.28: Vista previa
1.16: No disponible

Puedes migrar los siguientes tipos de almacenamiento:

Almacenamiento para componentes del sistema administrados por Google Distributed Cloud, que incluye:
- Discos de datos (archivos VMDK) que usan los nodos del plano de control de los clústeres de administrador y los clústeres de usuario del plano de control V2
- Discos de arranque (archivos VMDK) que usan todos los clústeres de administrador y los nodos del clúster de usuario
- Volúmenes de vSphere representados por PV/PVC en el clúster de administrador y que usan los componentes del plano de control de los clústeres de usuario de kubeception
Almacenamiento para cargas de trabajo que implementas en los nodos trabajadores del clúster de usuario con PV/PVC aprovisionados por el complemento de volumen de vSphere en el árbol o el controlador CSI de vSphere

Requisitos previos para un clúster de administrador

El clúster de administrador debe tener un plano de control de alta disponibilidad. Si el clúster de administrador tiene un plano de control sin alta disponibilidad, migra a HA antes de continuar.
Verifica que el clúster de administrador tenga un plano de control de alta disponibilidad:
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes
```
Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador.

En el resultado, asegúrate de que se vean tres nodos del plano de control. Por ejemplo:
```
admin-cp-1   Ready    control-plane,master ...
admin-cp-2   Ready    control-plane,master ...
admin-cp-3   Ready    control-plane,master ...
```

Requisitos para todos los clústeres (administrador y usuario)

El clúster debe tener inhabilitada la reparación automática de nodos. Si la reparación automática de nodos está habilitada, inhabilita la reparación automática de nodos.
El clúster debe usar la administración basada en políticas de almacenamiento (SPBM). Si tu clúster no usa SPBM, crea una política de almacenamiento antes de continuar.
Verifica que el clúster use SPBM:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG get onpremadmincluster --namespace kube-system \
  -ojson | jq '{datastore: .items[0].spec.vCenter.datastore, storagePolicyName: .items[0].spec.vCenter.storagePolicyName}'
```
Verifica que los grupos de nodos usen SPBM (solo clúster de usuario):
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremnodepools --namespace USER_CLUSTER_NAME-gke-onprem-mgmt \
  -ojson | jq '.items[] | {name: .metadata.name, datastore: .spec.vsphere.datastore, storagePolicyName: .spec.vsphere.storagePolicyName}'
```
Reemplaza lo siguiente:
- CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster (administrador o usuario).
- ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
- USER_CLUSTER_NAME: el nombre del clúster de usuario
En el resultado, si el campo datastore está vacío y el campo storagePolicyName no está vacío, entonces el clúster usa SPBM.
El clúster no debe usar el complemento de volumen en árbol de vSphere.

Si tu clúster se actualizó desde una versión anterior de Google Distributed Cloud, es posible que tenga PV/PVC que aprovisionó el complemento de volumen en árbol de vSphere. Este tipo de volumen puede estar en uso en un nodo del plano de control de un clúster de usuario de kubeception o en una carga de trabajo que creaste en un nodo trabajador.

Lista de todas las PVC y sus StorageClasses:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG get pvc --all-namespaces  \
   -ojson | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, storageClassName: .spec.storageClassName}'
```
Obtén una lista de todas las StorageClasses y observa qué aprovisionadores usan:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG get storageclass
```
En el resultado, si la columna PROVISIONER es kubernetes.io/vsphere-volume, las PVC creadas con esta StorageClass usan el complemento de volumen en árbol de vSphere. Para los StatefulSets que usan estos PV/PVC, mígralos al controlador de CSI de vSphere.

Realiza la migración del almacenamiento

Google Distributed Cloud admite dos categorías de migración de almacenamiento:

Storage vMotion para VMs, que traslada el almacenamiento de VM, incluidos los volúmenes adjuntos de CNS de vSphere que usan los Pods que se ejecutan en un nodo y los VMDK que usan estos volúmenes de CNS de VM vinculados a los nodos
Reubicación del volumen de CNS, que mueve volúmenes específicos de CNS de vSphere a un almacén de datos compatible sin realizar el almacenamiento de vMotion para las VM

Ejecuta almacenamiento vMotion para VMs

La migración implica los pasos que realizas en el entorno de vSphere y los comandos que ejecutas en la estación de trabajo de administrador:

En el entorno de vSphere, agrega los almacenes de datos de destino a la política de almacenamiento.
En el entorno de vSphere, migra las VM del clúster con el almacén de datos antiguo al almacén de datos nuevo. Para obtener instrucciones, consulta Cómo migrar una máquina virtual a un almacenamiento y un recurso de procesamiento nuevos.

En la estación de trabajo de administrador, verifica que las VM se hayan migrado de forma correcta al almacén de datos nuevo.

Obtén los objetos Machine del clúster:

kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml

En el resultado, en status.disks, puedes ver los discos conectados a las VM. Por ejemplo:

status:
addresses:
– address: 172.16.20.2
  type: ExternalIP
disks:
– bootdisk: true
  datastore: pf-ds06
  filepath: me-xvz2ccv28bf9wdbx-2/me-xvz2ccv28bf9wdbx-2.vmdk
  uuid: 6000C29d-8edb-e742-babc-9c124013ba54
– datastore: pf-ds06
  filepath: anthos/gke-admin-nc4rk/me/ci-bluecwang-head-2-data.vmdk
  uuid: 6000C29e-cb12-8ffd-1aed-27f0438bb9d9

Verifica que todos los discos de todas las máquinas del clúster se hayan migrado al almacén de datos de destino.

En la estación de trabajo de administrador, ejecuta gkectl diagnose para verificar que el clúster esté en buen estado.

Llama a las APIs de reubicación de CNS para trasladar volúmenes de CNS.

Si solo deseas mover volúmenes de CNS aprovisionados por el controlador de CSI de vSphere, puedes seguir las instrucciones en Migra volúmenes de contenedores en vSphere. Esto podría ser más simple si solo tienes volúmenes CNS en el almacén de datos anterior.

Si es necesario, actualiza tu política de almacenamiento

En el entorno de vSphere, actualiza la política de almacenamiento para excluir los almacenes de datos antiguos. De lo contrario, los volúmenes nuevos y las VM recreadas podrían asignarse a un almacén de datos antiguo.