Pour en savoir plus sur les versions, consultez les notes de version de Distributed Cloud connecté.

Configurer le stockage Distributed Cloud Connected

Cette page explique comment configurer le stockage connecté Distributed Cloud, y compris :

Symcloud Storage de Rakuten
Schémas de stockage local

Configurer Distributed Cloud connected pour Symcloud Storage

Par défaut, les charges de travail exécutées sur un nœud de rack Google Distributed Cloud connecté ne peuvent pas accéder au stockage local d'un autre nœud de rack Distributed Cloud connecté. Toutefois, vous pouvez configurer les racks connectés Distributed Cloud pour qu'ils utilisent Rakuten Symcloud Storage, une solution tierce qui sert de couche d'abstraction de stockage local sur chaque nœud connecté Distributed Cloud et met son stockage local à la disposition des charges de travail s'exécutant sur d'autres nœuds connectés Distributed Cloud. Symcloud Storage est l'option de stockage par défaut et unique sur les serveurs connectés Google Distributed Cloud.

Symcloud Storage est déployé depuis Google Cloud Marketplace et est soumis aux conditions qui y sont indiquées. Google fournit une assistance limitée pour l'utilisation de Symcloud Storage avec Distributed Cloud Connected et peut faire appel au fournisseur tiers pour obtenir de l'aide. Les mises à jour logicielles de Symcloud Storage sont incluses dans les mises à jour logicielles connectées Distributed Cloud.

Cette version de Distributed Cloud Connected est fournie avec Symcloud Storage 5.4.16 et est compatible avec cette version. Aucune autre version de Symcloud Storage n'est compatible avec cette version de Distributed Cloud Connected.

Obtenir une licence Symcloud Storage

Vous devez obtenir une licence Symcloud Storage au format YAML sur Google Cloud Marketplace :

Accéder à Marketplace

Classes de stockage Symcloud

Cette section décrit les classes de stockage que Symcloud Storage peut activer sur votre cluster connecté Distributed Cloud. Symcloud Storage sur Distributed Cloud Connected n'est pas compatible avec la classe de stockage robin-rwx ni avec les volumes de mode système de fichiers RWX configurés sur mesure. Pour en savoir plus sur les classes de stockage Symcloud, consultez Utiliser Robin CNS dans Kubernetes.

Classe de stockage `robin`

La classe de stockage robin est une classe de stockage de base Read Write-Once (RWO). L'exemple suivant illustre l'instanciation de la classe :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

Classe de stockage `robin-immediate`

La classe de stockage robin-immediate est identique à robin, sauf que le volume persistant est créé immédiatement après la création de la revendication de volume persistant correspondante. L'exemple suivant illustre l'instanciation de la classe :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin-immediate
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate

Classe de stockage `robin-repl-3`

robin-repl-3 est une classe de stockage RWO avec trois répliques qui s'étendent sur plusieurs nœuds Distributed Cloud. L'exemple suivant illustre l'instanciation de la classe :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin-repl-3
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
parameters:
    replication: "3"
    faultdomain: host

Prérequis

Avant de commencer, procédez comme suit :

Configurez la journalisation et la surveillance pour le projet Distributed Cloud associé cible.
Créez le cluster Distributed Cloud connecté cible.
Configurez votre réseau Distributed Cloud afin que les pods du cluster connecté Distributed Cloud cible puissent accéder au centre de données Google Cloud .
Associez chaque volume persistant local-block sur chaque nœud Distributed Cloud que vous ne souhaitez pas voir être abstrait par Symcloud Storage. Si vous dissociez un volume persistant local-block lié, l'installation de Symcloud Storage efface le contenu de ce volume persistant. Pour obtenir des instructions, consultez la section Liaison de la documentation Kubernetes.

Installer Symcloud Storage sur un nœud Distributed Cloud connecté

Pour installer Symcloud Storage sur un nœud connecté Distributed Cloud, procédez comme suit :

Utilisez la commande suivante pour appliquer la licence Symcloud Storage à votre cluster. Remplacez LICENSE_FILE par le chemin d'accès complet et le nom du fichier de licence Symcloud Storage.
```
kubectl apply -f LICENSE_FILE -n robin-admin
```

Utilisez la commande suivante pour vérifier l'état du service RobinCluster et de tous les nœuds Symcloud Storage :

kubectl describe robinclusters -n robinio

La commande renvoie un résultat semblable à celui-ci :

[...]
Status:
[...]
Phase:              Ready
robin_node_status:
[...]
 Status:           Ready
[...]
 Status:           Ready
[...]
 Status:           Ready
[...]

L'état attendu pour le service et les nœuds est Ready.

Définir Symcloud Storage comme classe de stockage par défaut

Utilisez la commande suivante pour définir Symcloud Storage comme classe de stockage par défaut sur votre cluster connecté Distributed Cloud. Remplacez STORAGE_CLASS par l'une des classes de stockage Symcloud.

kubectl patch storageclass STORAGE_CLASS -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Pour en savoir plus sur la définition de la classe de stockage par défaut, consultez Modifier la ressource StorageClass par défaut dans la documentation de Kubernetes.

Configurer des volumes de stockage Symcloud abstraits pour les charges de travail

Cette section fournit des exemples d'utilisation des classes de stockage Symcloud pour configurer le stockage abstrait de vos charges de travail Distributed Cloud connectées. Pour en savoir plus sur la configuration des volumes Symcloud Storage, consultez Utiliser Robin CNS dans Kubernetes.

Configurer un volume `ext4` RWO en mode système de fichiers

L'exemple suivant montre comment configurer une revendication de volume persistant pour un volume RWO en mode système de fichiers avec le système de fichiers ext4. Remplacez STORAGE_CLASS par l'une des classes de stockage Symcloud.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-fs-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

Configurer un volume RWO en mode bloc

L'exemple suivant montre comment configurer une revendication de volume persistant pour un volume RWO en mode bloc. Remplacez STORAGE_CLASS par l'une des classes de stockage Symcloud.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS
  volumeMode: Block

Modifier la configuration d'un volume existant

L'exemple suivant montre comment modifier la configuration d'un volume RWO compressé LZ4 Symcloud Storage existant à l'aide d'annotations. Remplacez STORAGE_CLASS par l'une des classes de stockage Symcloud.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: compressed-rwo-fs-pvc
  annotations:
    robin.io/compression: LZ4
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

L'exemple suivant montre comment modifier la configuration d'un volume RWO Symcloud Storage existant avec le système de fichiers xfs à l'aide d'annotations. Remplacez STORAGE_CLASS par l'une des classes de stockage Symcloud.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-xfs-pvc
  annotations:
    robin.io/fstype: xfs
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

Configurer le client CLI Symcloud Storage

Symcloud Storage fournit un client d'interface de ligne de commande (CLI) que vous pouvez utiliser pour gérer votre configuration Symcloud Storage. Pour configurer le client sur votre cluster connecté Distributed Cloud, procédez comme suit :

Obtenez le chemin d'accès à l'image Symcloud Storage utilisée par l'instance de service RobinCluster déployée sur votre cluster connecté Distributed Cloud et définissez vos variables d'environnement comme suit :

image_robin=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_robin}')
image_registry_path=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_registry_path}')
ROBIN_CNS_IMAGE="$image_registry_path/$image_robin"

Créez une ressource robincli avec le contenu suivant :

kind: Deployment
apiVersion: apps/v1
metadata:
 name: robincli
 namespace: default
 labels:
   name: robincli
spec:
 replicas: 1
 selector:
   matchLabels:
     name: robincli
 template:
   metadata:
     annotations:
       product: robin
     labels:
       name: robincli
   spec:
     containers:
     - name: robincli
       image: ROBIN_CNS_IMAGE
       workingDir: /root
       command: ["/bin/bash","-c","mkdir -p /root/.robin; ln -s -t /usr/lib/python3.7/site-packages/ /opt/robin/current/python3/site-packages/robincli /opt/robin/current/python3/site-packages/stormgr_def.py /opt/robin/current/python3/site-packages/stormgr_lib.py; /opt/robin/current/bin/robin client add-context robin-master.robinio --set-current; while true; do sleep 10000; done"]
       resources:
         requests:
           memory: "10Mi"
           cpu: "100m"

Remplacez ROBIN_CNS_IMAGE par le chemin d'accès complet au dépôt et le nom de l'image que vous avez obtenus à l'étape 1.

Appliquez la ressource robincli à votre cluster connecté Distributed Cloud.
Lors de l'installation initiale, Symcloud Storage génère un secret default-admin-user dans l'espace de noms robinio avec un mot de passe aléatoire. Utilisez les commandes suivantes pour obtenir ces identifiants de connexion :
1. Obtenez le nom d'utilisateur :
```
kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.username}' | base64 -d
```
2. Obtenez le mot de passe :
```
 
kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.password}' | base64 -d
```
Connectez-vous au pod que vous venez de créer et exécutez le client :
```
kubectl exec -it robincli -- bash
```

Limites de Symcloud Storage

Lorsque vous utilisez Symcloud Storage avec Distributed Cloud connecté, vous ne pouvez atteindre une haute disponibilité que si votre cluster Distributed Cloud connecté comporte au moins trois nœuds Distributed Cloud connecté.

Supprimer des nœuds qui utilisent Symcloud Storage d'un cluster

Les répliques de volumes de stockage Symcloud sont stockées sur des nœuds de calcul dans votre cluster connecté Distributed Cloud. Si vous supprimez un nœud du cluster, les données du volume de stockage Symcloud stockées sur ce nœud deviennent indisponibles. Pour éviter cela, vous devez effectuer l'une des opérations suivantes :

Si vous supprimez l'intégralité du cluster, supprimez les charges de travail et leurs volumes persistants Symcloud Storage correspondants avant de supprimer le cluster lui-même.
Si vous supprimez des nœuds spécifiques du cluster, vous devez migrer les données de charge de travail stockées sur ces nœuds avant de les supprimer du cluster. Pour obtenir des instructions, consultez Évacuer des volumes d'un disque.

Configurer des schémas de stockage local

Un schéma de stockage est un regroupement logique d'une ou plusieurs partitions. Chaque partition est une unité de stockage logiquement indépendante. Les partitions sont créées de manière séquentielle sur votre cluster jusqu'à ce que l'espace disque physique soit épuisé. Chaque schéma de stockage possède un nom unique qui l'identifie.

Pour créer un schéma de stockage local pour votre cluster connecté Distributed Cloud, vous devez le demander à Google. Une fois que nous avons testé le schéma et l'avons créé sur votre cluster, vous pouvez l'appliquer à l'aide de la CLI gcloud.

Vous ne pouvez pas modifier un schéma après l'avoir appliqué à un cluster. Pour modifier un schéma existant, vous devez demander à Google de le supprimer, puis demander la création d'un nouveau schéma pour le remplacer.

Définir des partitions pour un schéma de stockage local

Avant de pouvoir demander un schéma de stockage local, vous devez d'abord définir les partitions de ce schéma.

Une partition présente les propriétés suivantes :

Taille Vous pouvez spécifier la taille d'une partition en octets binaires ou utiliser tout l'espace restant sur le disque local.
Type Vous pouvez configurer une partition en tant que volume persistant Kubernetes (PV) ou volume local Linux sur le disque local.
Mode : Vous pouvez configurer le volume stocké dans la partition en tant que volume de blocs ou volume de système de fichiers. Pour les partitions de volumes persistants, la classe de stockage de la partition est respectivement local-block ou local-disks. Pour les partitions de volume local, vous pouvez spécifier les points de liaison et de montage pour les systèmes de fichiers contenus.

Demander un schéma de stockage local

Pour demander un nouveau schéma de stockage local pour votre cluster connecté Distributed Cloud, contactez l'assistance Google et indiquez la taille, le type, le mode et, éventuellement, les points de montage et de liaison pour chaque partition que vous souhaitez créer dans le schéma.

Lorsque nous recevons votre demande, nous effectuons une série de tests pour nous assurer de la robustesse du schéma, puis nous le créons sur votre cluster connecté Distributed Cloud.

Schémas de stockage local par défaut

Les navires connectés Distributed Cloud sont fournis avec les schémas de stockage local par défaut suivants :

default_control_plane_node. Ce schéma définit les partitions suivantes :
- Partition de volume local de 100 Go en mode système de fichiers.
- Partition de volume persistant en mode bloc qui occupe l'espace disque libre restant.
default_worker_node. Ce schéma définit une partition de volume persistant de 410 Go en mode bloc.

Appliquer un schéma de stockage local à un cluster

Pour appliquer un schéma de stockage local à votre cluster connecté Distributed Cloud, procédez de l'une des manières suivantes :

Pour appliquer un schéma de stockage local aux nœuds du plan de contrôle du cluster, utilisez l'option --control-plane-node-storage-schema lors de la création du cluster. Pour en savoir plus, consultez Créer un cluster.
Pour appliquer un schéma de stockage local aux nœuds de calcul du cluster, utilisez --node-storage-schema lorsque vous créez un pool de nœuds pour le cluster. Pour en savoir plus, consultez Créer un pool de nœuds.

Distributed Cloud connected crée les partitions définies dans votre schéma de stockage local une fois le cluster ou le pool de nœuds créé.