Migração de armazenamento com gestão baseada em políticas de armazenamento

Este documento mostra como migrar discos de um repositório de dados do vSphere para outro repositório de dados do vSphere com gestão baseada em políticas de armazenamento (SPBM).

1.29: geralmente disponível
1.28: pré-visualização
1.16: não disponível

Pode migrar os seguintes tipos de armazenamento:

  • Armazenamento para componentes do sistema geridos pelo Google Distributed Cloud, incluindo:

    • Discos de dados (ficheiros VMDK) usados pelos nós do plano de controlo dos clusters de administrador e clusters de utilizador do plano de controlo V2

    • Discos de arranque (ficheiros VMDK) usados por todos os nós do cluster de administrador e do cluster de utilizador

    • Volumes do vSphere representados por PVs/PVCs no cluster de administrador e usados pelos componentes do plano de controlo dos clusters de utilizadores do kubeception

  • Armazenamento para cargas de trabalho que implementa em nós de trabalho do cluster de utilizadores com PV/PVCs aprovisionados pelo plug-in de volume do vSphere na árvore ou pelo controlador CSI do vSphere

Pré-requisitos para um cluster de administrador

  1. O cluster de administrador tem de ter um plano de controlo de HA. Se o cluster de administrador tiver um plano de controlo não de alta disponibilidade, migre para a alta disponibilidade antes de continuar.

  2. Verifique se o cluster de administrador tem um plano de controlo de HA:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes
    

    Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster de administrador.

    Na saída, certifique-se de que vê três nós do plano de controlo. Por exemplo:

    admin-cp-1   Ready    control-plane,master ...
    admin-cp-2   Ready    control-plane,master ...
    admin-cp-3   Ready    control-plane,master ...
    

Pré-requisitos para todos os clusters (administrador e utilizador)

  1. O cluster tem de ter a autorreparação de nós desativada. Se a autorreparação de nós estiver ativada, desative-a.

  2. O cluster tem de usar a gestão baseada em políticas de armazenamento (SPBM). Se o seu cluster não usar o SPBM, crie uma política de armazenamento antes de continuar.

  3. Verifique se o cluster usa SPBM:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get onpremadmincluster --namespace kube-system \
      -ojson | jq '{datastore: .items[0].spec.vCenter.datastore, storagePolicyName: .items[0].spec.vCenter.storagePolicyName}'
    

    (Apenas para o cluster de utilizadores) Verifique se os conjuntos de nós usam o 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}'
    

    Substitua o seguinte:

    • CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster (administrador ou utilizador).

    • ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador

    • USER_CLUSTER_NAME: o nome do cluster de utilizadores

    Na saída, se o campo datastore estiver vazio e o campo storagePolicyName não estiver vazio, o cluster está a usar o SPBM.

  4. O cluster não pode usar o plug-in de volume no interior da árvore do vSphere.

    Se o cluster foi atualizado a partir de uma versão anterior do Google Distributed Cloud, pode ter PVs/PVCs aprovisionados pelo plug-in de volume no tree do vSphere. Este tipo de volume pode estar a ser usado por um nó do plano de controlo de um cluster de utilizador do kubeception ou por uma carga de trabalho que criou num nó de trabalho.

    Lista de todos os PVCs e respetivas StorageClasses:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get pvc --all-namespaces  \
       -ojson | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, storageClassName: .spec.storageClassName}'
    

    Liste todas as StorageClasses e veja que aprovisionadores estão a usar:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get storageclass
    

    Na saída, se a coluna PROVISIONER for kubernetes.io/vsphere-volume, então os PVCs criados com esta StorageClass estão a usar o plug-in de volume na árvore do vSphere. Para os StatefulSets que usam estes PV/PVCs, migre-os para o controlador CSI do vSphere.

Faça a migração do armazenamento

O Google Distributed Cloud suporta duas categorias de migração de armazenamento:

  • Storage vMotion para VMs, que move o armazenamento de VMs, incluindo volumes do vSphere CNS anexados usados por Pods em execução num nó e VMDKs usados por estes volumes do vSphere CNS anexados aos nós

  • A mudança de localização do volume do CNS, que move volumes do CNS do vSphere especificados para um arquivo de dados compatível sem executar o armazenamento vMotion para VMs

Realize o armazenamento vMotion para VMs

A migração envolve passos que executa no seu ambiente vSphere e comandos que executa na sua estação de trabalho de administrador:

  1. No seu ambiente vSphere, adicione os arquivos de dados de destino à sua política de armazenamento.

  2. No seu ambiente do vSphere, migre as VMs do cluster que usam o antigo armazenamento de dados para o novo armazenamento de dados. Para ver instruções, consulte o artigo Migre uma máquina virtual para um novo recurso de computação e armazenamento.

  3. Na estação de trabalho de administração, verifique se as VMs foram migradas com êxito para o novo arquivo de dados.

    Obtenha os objetos Machine no cluster:

    kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml

    No resultado, em status.disks, pode ver os discos anexados às VMs. Por exemplo:

    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
    

    Verifique se todos os discos de todas as máquinas no cluster foram migrados para o arquivo de dados de destino.

  4. Na estação de trabalho do administrador, execute o comando gkectl diagnose para verificar se o cluster está em bom estado.

Chame as APIs de mudança de localização do CNS para mover volumes do CNS

Se quiser mover apenas volumes do CNS aprovisionados pelo controlador CSI do vSphere, pode seguir as instruções em Migrar volumes de contentores no vSphere. Isto pode ser mais simples se só tiver volumes do CNS no antigo repositório de dados.

Atualize a sua política de armazenamento, se necessário

No seu ambiente vSphere, atualize a política de armazenamento para excluir os antigos arquivos de dados. Caso contrário, os novos volumes e as VMs recriadas podem ser atribuídos a um arquivo de dados antigo.