Configurare un criterio di archiviazione

Questo documento mostra come configurare un criterio di archiviazione VM per un cluster Google Distributed Cloud.

Panoramica

In vSphere, Gestione basata su criteri di archiviazione (SPBM) aiuta ad allineare l'archiviazione con le esigenze dell'applicazione delle macchine virtuali. Fornisce un framework di criteri di archiviazione che funge da singolo pannello di controllo unificato per una vasta gamma di servizi di dati e soluzioni di archiviazione.

In Google Distributed Cloud, puoi specificare i criteri di archiviazione come anziché specificare datastores. Definisci i criteri di archiviazione in base ai requisiti dell'applicazione e poi vSphere seleziona e gestisce automaticamente i datastore. Ciò può ridurre l'overhead e la manutenzione associati allo spazio di archiviazione.

Ereditarietà

Puoi specificare un criterio di archiviazione per un cluster utente, un pool di nodi un cluster Google Cloud o un insieme di nodi del piano di controllo in un cluster utente. Puoi anche specificare un criterio di archiviazione per un cluster di amministrazione, finché il cluster di amministrazione ha un piano di controllo ad alta disponibilità e non ha pool di nodi Windows.

Se specifichi un criterio di archiviazione per un cluster utente, il criterio viene ereditato. dai pool di nodi nel cluster utente. Se specifichi un criterio di archiviazione per un singolo pool di nodi, questo viene utilizzato al posto del criterio di archiviazione a livello di cluster. Allo stesso modo, se specifichi un datastore per un singolo pool di nodi, viene utilizzato un datastore al posto del criterio di archiviazione a livello di cluster.

In un cluster utente in cui è abilitato il control plane v2, il criterio di archiviazione a livello di cluster viene ereditato dai nodi del piano di controllo. Se specifichi un criterio di archiviazione o datastore per i nodi del piano di controllo, il criterio di archiviazione o il datastore al posto del criterio di archiviazione a livello di cluster.

Applicazione dei criteri di archiviazione ai datastore

Puoi applicare un criterio di archiviazione a un singolo datastore o a più datastore. Se applichi un criterio di archiviazione a più datastore, le risorse di archiviazione per un cluster di amministrazione, un cluster utente o un pool di nodi può essere distribuito e datastore.

Esempio: creare un criterio di archiviazione e un cluster utente

Questa sezione fornisce un esempio di creazione di un criterio di archiviazione e di un cluster di utenti. Questo esempio illustra l'idea che un criterio di archiviazione può essere applicato a due datastore.

Applicare i tag ai datastore

Per eseguire i passaggi dell'esempio, l'ambiente vSphere deve avere almeno due datastores.

Il cluster vSphere che ospiterà i nodi per il cluster utente deve avere accesso ai datastore che prevedi di utilizzare per questo esercizio. C'è un controllo preflight che lo verifichi.

L'account vCenter utilizzato per applicare i tag deve avere i seguenti elementi: Privilegi di tagging vSphere privilegi sul server vCenter principale:

• Tagging vSphere.Create vSphere Tag
• Tagging vSphere.Crea categoria di tag vSphere
• Tagging vSphere.Assegnazione o annullamento dell'assegnazione di tag vSphere

In vSphere Client, assegna lo stesso tag a ciascuno dei datastore che hai scelto di utilizzare per questo esercizio. Per istruzioni, vedi Assegnare tag a Datastore.

Per ulteriori informazioni, vedi Tag e attributi vSphere.

Crea un criterio di archiviazione

In vSphere Client, crea un criterio di archiviazione delle VM per il posizionamento basato su tag. Nel criterio di archiviazione, specifica il tag che hai applicato ai datastore selezionati. Per istruzioni, vedi Crea un criterio di archiviazione VM per il posizionamento basato su tag.

Per ulteriori informazioni, consulta Norme relative allo spazio di archiviazione delle VM.

Se utilizzi un datastore vSAN, consulta criterio di archiviazione vSAN.

Creazione di un cluster utente

In questo esercizio crei un cluster utente con un piano di controllo ad alta disponibilità, quindi sono presenti tre nodi del piano di controllo. Oltre al piano di controllo, nodi, ci sono sei nodi worker, tre in un pool di nodi e tre in un secondo pool di nodi. Tutti i nodi utilizzano indirizzi IP statici.

Inizia seguendo le istruzioni in Crea un cluster utente.

Mentre compili il file di configurazione del cluster utente:

• Imposta il valore di vCenter.storagePolicyName sul nome di un campo esistente criterio di archiviazione. Non impostare un valore per vCenter.datastore.

• Specifica due pool di nodi. Per il primo pool di nodi, non specificare un datastore, né specificare un criterio di archiviazione. Per il secondo pool di nodi, imposta il valore vsphere.datastore sul nome di un datastore esistente.

Nota: non specificare sia un datastore sia un criterio di archiviazione per vCenter, masterNode o un singolo pool di nodi.

File di configurazione del cluster di esempio

Ecco un esempio di un file di blocco IP e di una parte di un cluster utente di configurazione del deployment.

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
    - ip: 172.16.21.3
    - ip: 172.16.21.4
    - ip: 172.16.21.5
    - ip: 172.16.21.6
    - ip: 172.16.21.7
    - ip: 172.16.21.8

user-cluster-yaml

apiVersion: v1
kind: UserCluster
...
vCenter:
  storagePolicyName: "my-storage-policy"
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.9"
      hostname: "cp-vm-1"
    - ip: "172.16.21.10"
      hostname: "cp-vm-2"
    - ip: "172.16.21.11"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
    - "172.16.21.30-172.16.21.39"
...
enableControlplaneV2: true
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-pool-1"
  enableLoadBalancer: true
- name: "worker-pool-2"
  vSphere:
    datastore: "my-np2-datastore"
...

Di seguito sono riportati i punti importanti da comprendere nell'esempio precedente:

• Gli indirizzi IP statici per i nodi worker sono specificati in un blocco IP . Il file di blocco IP contiene sette indirizzi anche se sono presenti solo sei nodi worker. L'indirizzo IP aggiuntivo è necessario durante l'upgrade o l'aggiornamento del cluster e riparazione automatica.

• Gli indirizzi IP statici per i tre nodi del piano di controllo sono specificati nel Sezione network.controlPlaneIPBlock del file di configurazione del cluster utente. Non è necessario un indirizzo IP aggiuntivo in questo blocco.

• Il campo masterNode.replicas è impostato su 3, quindi ci sono tre dai nodi del piano di controllo. In masterNode, non è specificato nulla per vsphere.datastore o vsphere.storagePolicyName. Pertanto, i nodi del control plane utilizzeranno il criterio di archiviazione specificato in vCenter.storagePolicyName.

• Il file di configurazione del cluster utente include un valore per vCenter.storagePolicy, ma non include un valore per vCenter.datastore. Il criterio di archiviazione specificato verrà utilizzato dai nodi in qualsiasi che non specifica un proprio criterio di archiviazione o un proprio datastore.

• In node-pool-1, non è stato specificato nulla per vsphere.datastore o vsphere.storagePolicyName. Quindi i nodi in node-pool-1 utilizzeranno criterio di archiviazione specificato in vCenter.storagePolicyName.

• In node-pool-2, il valore di vsphere.datastore è my-np2-datastore, i nodi in node-pool-2 utilizzano lo stesso datastore e non usano un criterio di archiviazione.

Continua a creare il cluster utente come descritto in Crea un cluster utente.

Crea un cluster utente in un data center separato dal cluster di amministrazione

Un cluster utente può trovarsi in un data center distinto da quello del cluster amministrativo. I due data center possono utilizzare la stessa istanza Server vCenter o diverse istanze di vCenter Server.

Questa sezione fornisce un esempio di come creare un cluster utente che utilizza una separata di vCenter Server dal cluster di amministrazione. Poiché l'utente e utilizzano istanze separate di vCenter Server, sono anch'essi presenti in data center separati.

Per iniziare, segui le istruzioni riportate in Creare un cluster utente.

Quando compili il file di configurazione del cluster utente:

• Imposta il valore di vCenter.storagePolicyName sul nome di un criterio di archiviazione esistente. Non impostare un valore per vCenter.datastore.

• In vCenter, specifica i valori per address, datacenter, cluster e resourcePool.

• Specifica un valore per network.vCenter.networkName.

• Specifica due pool di nodi. Per il primo pool di nodi, non specificare un datastore, né specificare un criterio di archiviazione. Imposta il valore per il secondo pool di nodi di vsphere.datastore al nome di un datastore esistente.

Nota: non specificare sia un datastore sia un criterio di archiviazione per vCenter, masterNode o un singolo pool di nodi.

File di configurazione del cluster di esempio

Ecco un esempio di un file di blocco IP e di una parte di un cluster utente di configurazione del deployment.

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
    - ip: 172.16.21.3
    - ip: 172.16.21.4
    - ip: 172.16.21.5
    - ip: 172.16.21.6
    - ip: 172.16.21.7
    - ip: 172.16.21.8

user-cluster-yaml

apiVersion: v1
kind: UserCluster
...
vCenter:
  address: "my-vcenter-server-2.my-domain.example"
  datacenter: "my-uc-data-center"
  cluster: "my-uc-vsphere-cluster"
  resourcePool: "my-uc-resource-pool"
  storagePolicyName: "my-storage-policy"
network:
  vCenter:
    networkName: "my-uc-network"
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.9"
      hostname: "cp-vm-1"
    - ip: "172.16.21.10"
      hostname: "cp-vm-2"
    - ip: "172.16.21.11"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
    - "172.16.21.30-172.16.21.39"
...
enableControlplaneV2: true
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-pool-1"
  enableLoadBalancer: true
- name: "worker-pool-2"
  vSphere:
    datastore: "my-np2-datastore"
...

Di seguito sono riportati i punti importanti da comprendere nell'esempio precedente:

• Il file di configurazione del cluster utente include un valore per vCenter.storagePolicy, ma non include un valore per vCenter.datastore. Il criterio di archiviazione specificato verrà utilizzato dai nodi di qualsiasi pool di nodi che non specifica il proprio criterio di archiviazione o il proprio datastore.

• In vCenter sono specificati i valori per address, datacenter, cluster e resourcePool. Quindi il cluster utente utilizzerà un indirizzo Server vCenter, data center, cluster vSphere e pool di risorse dall'amministratore in un cluster Kubernetes.

• È stato specificato un valore per network.vCenter.networkName.

• Il campo masterNode.replicas è impostato su 3, quindi ci saranno tre nodi del piano di controllo. In masterNode, non è stato specificato nulla per vsphere.datastore o vsphere.storagePolicyName. Quindi i nodi del piano di controllo userà il criterio di archiviazione specificato in vCenter.storagePolicyName.

• In node-pool-1, non è specificato nulla per vsphere.datastore o vsphere.storagePolicyName. Quindi i nodi in node-pool-1 utilizzeranno criterio di archiviazione specificato in vCenter.storagePolicyName.

• In node-pool-2, il valore di vsphere.datastore è my-np2-datastore, quindi i nodi in node-pool-2 utilizzano quel datastore e non un criterio di archiviazione.

Continua a creare il cluster utente come descritto in Creare un cluster utente.

Utilizzo dello spazio di archiviazione di vMotion

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Questa sezione mostra come utilizzare Storage vMotion in un cluster che utilizza SPBM. Se vuoi utilizzare Storage vMotion in un cluster che non utilizza SPBM, consulta Utilizza lo strumento di migrazione del datastore.

Segui questi passaggi:

1. Esegui la migrazione di tutte le VM del cluster al datastore di destinazione. Per istruzioni, vedi Esegui la migrazione di una macchina virtuale a una nuova risorsa di computing e archiviazione.

2. Verifica che la migrazione delle VM al nuovo datastore sia stata eseguita correttamente.

   Recupera gli oggetti Machine nel cluster:

   kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml
   

   Nell'output, in status.disks, puoi vedere i dischi collegati delle VM in esecuzione. Ad esempio:

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

   Verifica che sia stata eseguita la migrazione di tutti i dischi di tutte le macchine del cluster al datastore di destinazione.

3. Esegui gkectl diagnose per verificare che il cluster sia integro.

4. Aggiorna il criterio di archiviazione per escludere i datastore precedenti. In caso contrario, i nuovi volumi e VM ricreate potrebbero essere assegnati a un datastore precedente.