Los clústeres de Anthos en VMware ahora son Google Distributed Cloud (solo software) para VMware. Para obtener más información, consulta la descripción general del producto.

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

Migración de almacenamiento con la 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 con la administración basada en políticas de almacenamiento (SPBM).

1.29: Disponible de forma general
1.28: Versión preliminar
1.16: No disponible

Puedes migrar los siguientes tipos de almacenamiento:

Almacenamiento para componentes del sistema administrados por Google Distributed Cloud, incluidos los siguientes:
- 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 de Controlplane V2
- Discos de inicio (archivos VMDK) que usan todos los nodos del clúster de administrador y del clúster de usuarios
- 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 las cargas de trabajo que implementas en los nodos trabajadores del clúster de usuarios con PV o PVC aprovisionados por el complemento de volumen de vSphere en el árbol o el controlador de 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 tu clúster de administrador tiene un plano de control que no es de 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 ver tres nodos de 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 previos 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}'
```
(Solo para clústeres de usuarios) Verifica que los grupos de nodos usen SPBM:
```
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, 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 o PVC aprovisionados por el complemento de volumen en el árbol de vSphere. Un nodo del plano de control de un clúster de usuario de kubeception o una carga de trabajo que creaste en un nodo trabajador pueden estar usando este tipo de volumen.

Lista de todas las PVC y sus StorageClass:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG get pvc --all-namespaces  \
   -ojson | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, storageClassName: .spec.storageClassName}'
```
Enumera todas las StorageClass y consulta 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 el árbol de vSphere. En el caso de los StatefulSets que usan estos PV o PVC, migrálalos al controlador de CSI de vSphere.

Realiza la migración de almacenamiento

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

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

Realiza vMotion de almacenamiento para VMs

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

En tu entorno de vSphere, agrega los almacenes de datos de destino a tu política de almacenamiento.
En tu entorno de vSphere, migra las VMs del clúster que usan el almacén de datos anterior al almacén de datos nuevo. Para obtener instrucciones, consulta Migra una máquina virtual a un nuevo recurso de procesamiento y almacenamiento.

En tu estación de trabajo de administrador, verifica que las VMs se hayan migrado correctamente al nuevo almacén de datos.

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 VMs. 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 tu estación de trabajo de administrador, ejecuta gkectl diagnose para verificar que el clúster esté en buen estado.

Llama a las APIs de CNS Relocation para mover volúmenes de CNS

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

Actualiza tu política de almacenamiento si es necesario

En tu entorno de vSphere, actualiza la política de almacenamiento para excluir los almacenes de datos antiguos. De lo contrario, es posible que los volúmenes nuevos y las VMs recreadas se asignen a un almacén de datos anterior.