Configurer une règle de stockage

Version 1.28 

• Dernière version
• Version 1.16
• Versions antérieures (non compatibles)

Ce document explique comment configurer une règle de stockage de VM pour un cluster GKE sur VMware.

Présentation

Dans vSphere, la gestion basée sur des règles de stockage (SPBM) permet d'aligner le stockage sur les exigences des machines virtuelles (applications). Il fournit un framework de règles de stockage qui sert de panneau de configuration unique pour un large éventail de services de données et de solutions de stockage.

Dans un cluster Anthos sur VMware, vous pouvez spécifier des règles de stockage au lieu de spécifier des datastores. Vous définissez des règles de stockage en fonction des exigences de votre application, puis vSphere sélectionne et gère automatiquement les datastores. Cela peut réduire les frais généraux et la maintenance associés au stockage.

Héritage

Vous pouvez spécifier une règle de stockage pour un cluster d'utilisateur, un pool de nœuds dans un cluster d'utilisateur ou un ensemble de nœuds du plan de contrôle dans un cluster d'utilisateur. Vous pouvez également spécifier une règle de stockage pour un cluster d'administrateur à condition qu'il dispose d'un plan de contrôle à haute disponibilité et qu'il ne dispose d'aucun pool de nœuds Windows.

Si vous spécifiez une règle de stockage pour un cluster d'utilisateur, les pools de nœuds du cluster d'utilisateur héritent de cette règle. Si vous spécifiez une règle de stockage pour un pool de nœuds individuel, cette règle est utilisée à la place de la règle de stockage au niveau du cluster. De même, si vous spécifiez un datastore pour un pool de nœuds individuel, ce datastore est utilisé à la place des règles de stockage au niveau du cluster.

Dans un cluster d'utilisateur sur lequel le plan de contrôle V2 est activé, la règle de stockage au niveau du cluster est héritée par les nœuds du plan de contrôle. Si vous spécifiez une règle de stockage ou un datastore pour les nœuds du plan de contrôle, cette règle de stockage ou ce datastore est utilisé à la place de la règle de stockage au niveau du cluster.

Appliquer des règles de stockage aux datastores

Vous pouvez appliquer une règle de stockage à un ou à plusieurs datastores. Si vous appliquez une règle de stockage à plusieurs datastores, les ressources de stockage d'un cluster d'administrateur, d'un cluster d'utilisateur ou d'un pool de nœuds peuvent être réparties entre les datastores.

Exemple: Créer une règle de stockage et un cluster d'utilisateur

Cette section donne un exemple de création d'une règle de stockage et d'un cluster d'utilisateur. Cet exemple illustre l'idée qu'une règle de stockage peut s'appliquer à deux datastores.

Appliquer des tags aux datastores

Pour que vous puissiez effectuer les étapes de cet exemple, votre environnement vSphere doit comporter au moins deux datastores.

Le cluster vSphere qui hébergera les nœuds de votre cluster d'utilisateur doit avoir accès aux datastores que vous prévoyez d'utiliser pour cet exercice. Une vérification préliminaire permet de vérifier cela.

Le compte vCenter que vous utilisez pour appliquer des tags doit disposer des droits d'ajout de tags vSphere suivants sur le serveur vCenter Server racine:

• vSphere Tagging.Create vSphere Tag
• Ajout de tags vSphere.Créer une catégorie de tags vSphere
• "vSphere Tagging.Assign" ou "Unassign vSphere Tag"

Dans le client vSphere, attribuez le même tag à chacun des datastores que vous avez choisi d'utiliser pour cet exercice. Pour obtenir des instructions, consultez la section Attribuer des tags aux datastores.

Pour en savoir plus, consultez la section Balises et attributs vSphere.

Créer une règle de stockage

Dans le client vSphere, créez une règle de stockage de VM pour l'emplacement basé sur des tags. Dans la règle de stockage, spécifiez le tag que vous avez appliqué aux datastores sélectionnés. Pour obtenir des instructions, consultez la page Créer une règle de stockage de VM pour l'emplacement basé sur des tags.

Pour en savoir plus, consultez la section Règles de stockage des VM.

Si vous utilisez un datastore vSAN, consultez les Règles de stockage vSAN.

Créer un cluster d'utilisateur

Dans cet exercice, vous allez créer un cluster d'utilisateur avec un plan de contrôle à haute disponibilité, soit trois nœuds de plan de contrôle. En plus des nœuds du plan de contrôle, il existe six nœuds de calcul, trois dans un pool de nœuds et trois dans un deuxième pool de nœuds. Tous les nœuds utilisent des adresses IP statiques.

Commencez par suivre les instructions de la section Créer un cluster d'utilisateur (ControlPlane V2).

Lorsque vous remplissez le fichier de configuration de votre cluster d'utilisateur :

• Définissez la valeur de vCenter.storagePolicyName sur le nom d'une règle de stockage existante. Ne définissez pas de valeur pour vCenter.datastore.

• Spécifiez deux pools de nœuds. Pour le premier pool de nœuds, ne spécifiez pas de datastore ni de règle de stockage. Pour le deuxième pool de nœuds, définissez la valeur de vsphere.datastore sur le nom d'un datastore existant.

Remarque :Ne spécifiez pas à la fois un datastore et une règle de stockage pour vCenter, masterNode ou un pool de nœuds individuel.

Exemple de fichier de configuration de cluster

Voici un exemple de fichier de bloc d'adresses IP et de partie d'un fichier de configuration de cluster d'utilisateur.

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"
...

Voici les points importants à comprendre dans l'exemple précédent :

• Les adresses IP statiques des nœuds de calcul sont spécifiées dans un fichier de bloc d'adresses IP. Le fichier de blocs d'adresses IP comporte sept adresses, alors qu'il n'y a que six nœuds de calcul. L'adresse IP supplémentaire est nécessaire lors de la mise à niveau, de la mise à jour et de la réparation automatique du cluster.

• Les adresses IP statiques des trois nœuds de plan de contrôle sont spécifiées dans la section network.controlPlaneIPBlock du fichier de configuration du cluster d'utilisateur. Aucune adresse IP supplémentaire n'est nécessaire dans ce bloc.

• Le champ masterNode.replicas est défini sur 3. Il y aura donc trois nœuds du plan de contrôle. Sous masterNode, rien n'est spécifié pour vsphere.datastore ou vsphere.storagePolicyName. Les nœuds du plan de contrôle utilisent donc la règle de stockage spécifiée dans vCenter.storagePolicyName.

• Le fichier de configuration du cluster d'utilisateur inclut une valeur pour vCenter.storagePolicy, mais pas de valeur pour vCenter.datastore. La règle de stockage spécifiée sera utilisée par les nœuds de tout pool qui ne spécifie pas sa propre règle de stockage ni son propre datastore.

• Sous node-pool-1, rien n'est spécifié pour vsphere.datastore ou vsphere.storagePolicyName. Ainsi, les nœuds de node-pool-1 utiliseront la règle de stockage spécifiée dans vCenter.storagePolicyName.

• Sous node-pool-2, la valeur de vsphere.datastore est my-np2-datastore. Par conséquent, les nœuds de node-pool-2 utilisent ce datastore et n'utilisent pas de règle de stockage.

Continuez à créer votre cluster d'utilisateur comme décrit dans la section Créer un cluster d'utilisateur (Controlplane V2).

Créer un cluster d'utilisateur dans un centre de données distinct de votre cluster d'administrateur

Un cluster d'utilisateur peut se trouver dans un centre de données distinct du cluster d'administrateur. Les deux centres de données peuvent utiliser la même instance de vCenter Server ou des instances différentes de vCenter Server.

Cette section donne un exemple de création d'un cluster d'utilisateur qui utilise une instance distincte de vCenter Server du cluster d'administrateur. Étant donné que les clusters d'utilisateur et d'administrateur utilisent des instances distinctes de vCenter Server, ils se trouvent également dans des centres de données distincts.

Commencez par suivre les instructions de la section Créer un cluster d'utilisateur (ControlPlane V2).

Lorsque vous remplissez le fichier de configuration de votre cluster d'utilisateur :

• Définissez la valeur de vCenter.storagePolicyName sur le nom d'une règle de stockage existante. Ne définissez pas de valeur pour vCenter.datastore.

• Sous vCenter, spécifiez des valeurs pour address, datacenter, cluster et resourcePool.

• Spécifiez une valeur pour network.vCenter.networkName.

• Spécifiez deux pools de nœuds. Pour le premier pool de nœuds, ne spécifiez pas de datastore ni de règle de stockage. Pour le deuxième pool de nœuds, définissez la valeur de vsphere.datastore sur le nom d'un datastore existant.

Remarque :Ne spécifiez pas à la fois un datastore et une règle de stockage pour vCenter, masterNode ou un pool de nœuds individuel.

Exemple de fichier de configuration de cluster

Voici un exemple de fichier de bloc d'adresses IP et de partie d'un fichier de configuration de cluster d'utilisateur.

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"
...

Voici les points importants à comprendre dans l'exemple précédent :

• Le fichier de configuration du cluster d'utilisateur inclut une valeur pour vCenter.storagePolicy, mais pas de valeur pour vCenter.datastore. La règle de stockage spécifiée sera utilisée par les nœuds de tout pool de nœuds qui ne spécifie pas sa propre règle de stockage ni son propre datastore.

• Sous vCenter, des valeurs sont spécifiées pour address, datacenter, cluster et resourcePool. Le cluster d'utilisateur utilisera donc un serveur vCenter, un centre de données, un cluster vSphere et un pool de ressources différents de ceux du cluster d'administrateur.

• Une valeur est spécifiée pour network.vCenter.networkName.

• Le champ masterNode.replicas est défini sur 3. Il y aura donc trois nœuds du plan de contrôle. Sous masterNode, rien n'est spécifié pour vsphere.datastore ou vsphere.storagePolicyName. Les nœuds du plan de contrôle utilisent donc la règle de stockage spécifiée dans vCenter.storagePolicyName.

• Sous node-pool-1, rien n'est spécifié pour vsphere.datastore ou vsphere.storagePolicyName. Ainsi, les nœuds de node-pool-1 utiliseront la règle de stockage spécifiée dans vCenter.storagePolicyName.

• Sous node-pool-2, la valeur de vsphere.datastore est my-np2-datastore. Par conséquent, les nœuds de node-pool-2 utilisent ce datastore et n'utilisent pas de règle de stockage.

Continuez à créer votre cluster d'utilisateur comme décrit dans la section Créer un cluster d'utilisateur (Controlplane V2).

Utiliser Storage vMotion

Preview

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Cette section explique comment utiliser Storage VMotion dans un cluster qui utilise SPBM. Si vous souhaitez utiliser Storage VMotion dans un cluster qui n'utilise pas SPBM, consultez la page Utiliser l'outil de migration de datastore.

Procédez comme suit :

1. Migrez toutes les VM du cluster vers le datastore cible. Pour obtenir des instructions, consultez la page Migrer une machine virtuelle vers une nouvelle ressource de calcul et un nouvel espace de stockage.

2. Vérifiez que les VM ont bien été migrées vers le nouveau datastore.

   Récupérez les objets Machine dans le cluster:

   kubectl --kubeconfig CLUSTER_KUBECONFIG get machines --output yaml
   

   Dans la sortie, les disques associés aux VM s'affichent sous status.disks. Exemple :

   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
   

   Vérifiez que tous les disques de toutes les machines du cluster ont bien été migrés vers le datastore cible.

3. Exécutez gkectl diagnose pour vérifier que le cluster est opérationnel.

4. Mettez à jour la règle de stockage pour exclure les anciens datastores. Sinon, les nouveaux volumes et les VM recréées peuvent être attribués à un ancien datastore.