Configuration du stockage

Concepts du stockage Kubernetes

Kubernetes fournit une couche d’abstraction de l’infrastructure sur la pile technique de virtualisation sous-jacente (facultatif) et le matériel. Kubernetes rend abstrait le stockage via des classes de stockage. Lorsque vous approvisionnez un pod, vous pouvez spécifier une classe de stockage pour chaque volume. Au moment du provisionnement du pod, le provisionneur de la classe de stockage est appelé pour approvisionner le stockage, puis un volume persistant est créé sur ce stockage provisionné et enfin, le pod est monté sur le volume persistant par une revendication de volume persistant.

Kubernetes offre aux fournisseurs d’infrastructure de stockage un moyen d’introduire des pilotes (également appelés « modules complémentaires » ou « add-ons ») qui étendent Kubernetes. Les modules complémentaires de stockage sont conformes au standard de Container Storage Interface. Vous trouverez des dizaines de modules complémentaires dans cette liste des pilotes CSI non définitive. Le pilote CSI spécifique que vous utilisez dépend de facteurs tels que le fait que vous exécutiez un service Kubernetes géré et hébergé dans le cloud ou le fournisseur OEM que vous utilisez pour votre matériel.

Pour afficher les classes de stockage configurées dans votre cluster Kubernetes, exécutez cette commande :

kubectl get storageclass

Exemple de sortie d’un cluster Azure Kubernetes Service (AKS) :

NAME                PROVISIONER                AGE
azurefile           kubernetes.io/azure-file   15d
azurefile-premium   kubernetes.io/azure-file   15d
default (default)   kubernetes.io/azure-disk   4d3h
managed-premium     kubernetes.io/azure-disk   4d3h

Vous pouvez obtenir des détails sur une classe de stockage en exécutant la commande suivante :

kubectl describe storageclass/<storage class name>

Exemple :

kubectl describe storageclass/azurefile

Name:            azurefile
IsDefaultClass:  No
Annotations:     kubectl.kubernetes.io/last-applied-configuration={"allowVolumeExpansion":true,"apiVersion":"storage.k8s.io/v1beta1","kind":"StorageClass","metadata":{"annotations":{},"labels":{"kubernetes.io/cluster-service":"true"},"name":"azurefile"},"parameters":{"sku
Name":"Standard_LRS"},"provisioner":"kubernetes.io/azure-file"}

Provisioner:           kubernetes.io/azure-file
Parameters:            skuName=Standard_LRS
AllowVolumeExpansion:  True
MountOptions:          <none>
ReclaimPolicy:         Delete
VolumeBindingMode:     Immediate
Events:                <none>

Vous pouvez voir les volumes persistants actuellement provisionnés et les revendications de volume persistant en exécutant les commandes suivantes :

kubectl get persistentvolumes -n <namespace>

kubectl get persistentvolumeclaims -n <namespace>

Exemple d’affichage de volumes persistants :

kubectl get persistentvolumes -n arc

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                      STORAGECLASS   REASON   AGE
pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            Delete           Bound    arc/sqldemo11-data-claim   default                 7d3h
pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            Delete           Bound    arc/data-metricsdb-0       default                 7d14h
pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            Delete           Bound    arc/sqldemo11-logs-claim   default                 7d3h
pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            Delete           Bound    arc/data-controller        default                 7d14h
pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            Delete           Bound    arc/logs-controller        default                 7d14h
pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            Delete           Bound    arc/logs-metricsdb-0       default                 7d14h
pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            Delete           Bound    arc/sqldemo10-logs-claim   default                 7d14h
pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            Delete           Bound    arc/sqldemo10-data-claim   default                 7d14h
pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            Delete           Bound    arc/data-controldb         default                 7d14h
pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            Delete           Bound    arc/logs-controldb         default                 7d14h
pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            Delete           Bound    arc/logs-logsdb-0          default                 7d14h
pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            Delete           Bound    arc/data-logsdb-0          default                 7d14h

Exemple d’affichage de revendications de volume persistant :

kubectl get persistentvolumeclaims -n arc

NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
data-controldb         Bound    pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            default        7d14h
data-controller        Bound    pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            default        7d14h
data-logsdb-0          Bound    pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            default        7d14h
data-metricsdb-0       Bound    pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            default        7d14h
logs-controldb         Bound    pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            default        7d14h
logs-controller        Bound    pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            default        7d14h
logs-logsdb-0          Bound    pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            default        7d14h
logs-metricsdb-0       Bound    pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            default        7d14h
sqldemo10-data-claim   Bound    pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            default        7d14h
sqldemo10-logs-claim   Bound    pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            default        7d14h
sqldemo11-data-claim   Bound    pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            default        7d4h
sqldemo11-logs-claim   Bound    pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            default        7d4h

Facteurs à prendre en compte lors du choix de la configuration de votre stockage

La sélection de la classe de stockage appropriée est importante pour la résilience et les performances des données. Si vous choisissez une classe de stockage incorrecte, vous risquez de perdre des données en cas de panne matérielle ou d’obtenir de moins bonnes performances.

Il existe en général deux types de stockage :

• Stockage local - stockage provisionné sur des disques durs locaux sur un nœud donné. Ce type de stockage peut être idéal en termes de performances, mais il demande une conception spécifique de la redondance des données via la réplication des données sur plusieurs nœuds.
• Stockage partagé distant - stockage provisionné sur un dispositif de stockage distant, par exemple un SAN, un NAS ou un service de stockage cloud, comme EBS ou Azure Files. Ce type de stockage fournit généralement une redondance des données automatique, mais il n’est généralement pas aussi rapide que le stockage local.

Classes de stockage NFS

Selon la configuration de votre serveur NFS et de votre provisionneur de classe de stockage, vous devrez peut-être définir supplementalGroups dans les configurations de pod pour les instances de base de données et vous devrez peut-être modifier la configuration du serveur NFS pour utiliser les ID de groupe transmis par le client (par opposition à l’examen des ID de groupe sur le serveur à l’aide de l’ID d’utilisateur transmis). Consultez votre administrateur NFS pour déterminer si c’est le cas.

La propriété supplementalGroups prend un tableau de valeurs que vous pouvez définir lors du déploiement. Le contrôleur de données Azure Arc les applique à toutes les instances de base de données qu’il crée.

Pour définir cette propriété, exécutez la commande suivante :

az arcdata dc config add --path custom/control.json --json-values 'spec.security.supplementalGroups="1234556"'

Configuration du stockage du contrôleur de données

Certains services dans Azure Arc pour les services de données dépendent de la configuration pour utiliser un stockage partagé distant, car les services n’ont pas la capacité de répliquer les données. Ces services se trouvent dans la collection de pods du contrôleur de données :

Au moment où le contrôleur de données est provisionné, la classe de stockage à utiliser pour chacun de ces volumes persistants est spécifiée en passant le paramètre --storage-class | -sc à la commande az arcdata dc create ou en définissant les classes de stockage dans le fichier de modèle de déploiement control.json utilisé. Si vous utilisez le portail Azure pour créer le contrôleur de données en mode directement connecté, le modèle de déploiement que vous choisissez possède la classe de stockage prédéfinie dans le modèle ou vous pouvez sélectionner un modèle qui n'a pas de classe de stockage prédéfinie. Si votre modèle ne définit pas de classe de stockage, le portail vous en demande une. Si vous utilisez un modèle de déploiement personnalisé, vous pouvez spécifier la classe de stockage.

Les modèles de déploiement fournis d’origine spécifient une classe de stockage par défaut appropriée pour l’environnement cible, mais elle peut être remplacée au moment du déploiement. Pour modifier la configuration de la classe de stockage pour les pods de contrôleur de données au moment du déploiement, consultez les étapes détaillées pour créer des modèles de configuration personnalisés.

Si vous définissez la classe de stockage à l'aide du paramètre --storage-class ou -sc, cette classe de stockage est utilisée à la fois pour les classes de stockage de journaux et de données. Si vous définissez les classes de stockage dans le fichier de modèle de déploiement, vous pouvez spécifier des classes de stockage différentes pour les journaux et pour les données.

Voici les facteurs importants à prendre en compte lors du choix d’une classe de stockage pour les pods de contrôleur de données :

• Vous devez utiliser une classe de stockage partagée distante afin de garantir la durabilité des données et que, si un pod ou un nœud est défaillant, quand le pod est rétabli, il peut se reconnecter au volume persistant.
• Les données écrites dans l’instance SQL du contrôleur, dans la base de données des métriques et dans la base de données des journaux sont généralement relativement peu volumineuses et ne sont pas sensibles à la latence : un stockage avec des performances ultrarapides n’est donc pas critique. Si vous avez des utilisateurs qui utilisent fréquemment les interfaces Grafana et Kibana, et que vous avez un grand nombre d’instances de base de données, vos utilisateurs pourraient tirer un bénéfice d’un stockage plus rapide.
• La capacité de stockage nécessaire varie en fonction du nombre d’instances de base de données que vous avez déployées, car les journaux et les métriques sont collectés pour chaque instance de base de données. Les données sont conservées dans les bases de données des journaux et des métriques pendant deux (2) semaines avant d’être supprimées.
• Changer la classe de stockage après le déploiement est difficile, non documenté et non pris en charge. Veillez à choisir la classe de stockage correctement au moment du déploiement.

Configuration du stockage de l’instance de base de données

Chaque instance de base de données a des volumes persistants pour les données, pour les journaux et pour les sauvegardes. Les classes de stockage de ces volumes persistants peuvent être spécifiées au moment du déploiement. Si aucune classe de stockage n'est spécifiée, la classe de stockage par défaut est utilisée.

Lorsque vous créez une instance à l'aide de az sql mi-arc create ou az postgres server-arc create, vous pouvez utiliser quatre paramètres pour définir les classes de stockage :

Le tableau ci-dessous liste les chemins dans le conteneur Azure SQL Managed Instance qui est mappé au volume persistant pour les données et les journaux :

Le tableau ci-dessous liste les chemins dans le conteneur de l’instance PostgreSQL qui est mappé au volume persistant pour les données et les journaux :

Chaque instance de base de données dispose d'un volume persistant distinct pour les fichiers de données, les journaux et les sauvegardes. Cela signifie qu'il existe une séparation des E/S pour chacun de ces types de fichiers, en fonction de la manière dont le fournisseur de volume provisionne le stockage. Chaque instance de base de données a ses propres revendications de volume persistant et ses propres volumes persistants.

S'il existe plusieurs bases de données sur une instance de base de données donnée, toutes les bases de données utilisent la même revendication de volume persistant, le même volume persistant et la même classe de stockage. Toutes les sauvegardes – les sauvegardes différentielles de journaux et les sauvegardes complètes utilisent la même revendication de volume persistant et le même volume persistant. Les revendications de volume persistant pour les pods d’instances de base de données sont présentées ci-dessous :

Voici les facteurs importants à prendre en compte lors du choix d’une classe de stockage pour les pods d’instances de base de données :

• À compter de la version de février 2022 des services de données Azure Arc, vous devez spécifier une classe de stockage compatible ReadWriteMany (RWX) pour les sauvegardes. En savoir plus sur le modes d'accès. Si aucune classe de stockage n’est spécifiée pour les sauvegardes, la classe de stockage par défaut dans Kubernetes est utilisée et, si elle n’est pas RWX, le déploiement d’une instance gérée Azure SQL peut échouer.
• Les instances de base de données peuvent être déployées dans un modèle de pod unique ou dans un modèle à plusieurs pods. Une instance d’Azure SQL Managed Instance de niveau tarifaire Usage général est un exemple de modèle de pod unique. Une instance d’Azure SQL Managed Instance de niveau tarifaire Critique pour l’entreprise est un exemple de modèle à plusieurs pods. Les instances de base de données déployées avec le modèle de pod unique doivent utiliser une classe de stockage partagée distante afin de garantir la durabilité des données et que, si un pod ou un nœud est défaillant, quand le pod est rétabli, il peut se reconnecter au volume persistant. En revanche, une instance managée Azure SQL à haute disponibilité utilise des groupes de disponibilité Always On pour répliquer les données d’une instance vers une autre de façon synchrone ou asynchrone. En particulier dans le cas où les données sont répliquées de façon synchrone, il y a toujours plusieurs copies des données, en général trois copies. Pour cette raison, il est possible d’utiliser un stockage local ou des classes de stockage partagé distant pour les fichiers de données et les fichiers journaux. Si vous utilisez un stockage local, les données sont toujours préservées, même dans le cas de la défaillance d’un pod, d’un nœud ou d’un matériel de stockage, car il existe plusieurs copies des données. Étant donné cette flexibilité, vous pouvez choisir d’utiliser un stockage local pour de meilleures performances.
• Les performances de la base de données sont en grande partie fonction du débit d’E/S d’un dispositif de stockage donné. Si votre base de données fait l’objet de lectures ou d’écritures intensives, vous devez choisir une classe de stockage qui a un matériel conçu pour ce type de charge de travail. Par exemple, si votre base de données est principalement utilisée pour des écritures, vous pouvez choisir un stockage local avec un niveau RAID 0. Si votre base de données est principalement utilisée pour des lectures d’une petite quantité de « données chaudes », mais qu’il existe un grand volume de stockage global des données froides, vous pouvez choisir un périphérique SAN avec des capacités de stockage hiérarchisé. Le choix de la classe de stockage appropriée n’est pas très différent du choix du type de stockage que vous utiliseriez pour une base de données.
• Si vous utilisez un fournisseur de volumes de stockage local, assurez-vous que les volumes locaux provisionnés pour les données, les journaux et les sauvegardes atterrissent chacun sur des périphériques de stockage sous-jacents différents afin d'éviter les conflits sur les E/S de disque. Le système d’exploitation doit également se trouver sur un volume monté sur un ou plusieurs disques distincts. Il s’agit essentiellement des mêmes conseils que ceux qui seraient à suivre pour une instance de base de données sur un matériel physique.
• Étant donné que toutes les bases de données sur une instance spécifique partagent une revendication de volume persistant et un volume persistant, veillez à ne pas colocaliser les instances de base de données occupées sur la même instance de base de données. Si possible, placez séparément les bases de données occupées dans leurs propres instances de base de données pour éviter la contention des E/S. En outre, utilisez le ciblage des étiquettes de nœud pour placer les instances de base de données sur des nœuds distincts afin de distribuer le trafic d’E/S global entre plusieurs nœuds. Si vous utilisez la virtualisation, veillez à envisager de distribuer le trafic d'E/S non seulement au niveau du nœud, mais également à l'activité d'E/S combinée effectuée par toutes les machines virtuelles de nœud sur un hôte physique donné.

Estimation des besoins en stockage

Chaque pod qui contient des données avec état utilise au moins deux volumes persistants : un volume persistant pour les données et un autre pour les journaux. Le tableau ci-dessous indique le nombre de volumes persistants nécessaires pour un seul contrôleur de données, une instance Azure SQL Managed Instance, une instance Azure Database pour PostgreSQL et une instance Azure PostgreSQL Hyperscale :

Le tableau ci-dessous indique le nombre total de volumes persistants requis pour un exemple de déploiement :

Ce calcul peut être utilisé pour planifier le stockage de votre cluster Kubernetes en fonction de l’environnement ou du provisionneur de stockage. Par exemple, si le provisionneur de stockage local est utilisé pour un cluster Kubernetes avec cinq (5) nœuds, pour l’exemple de déploiement ci-dessus, chaque nœud nécessite du stockage pour au moins 10 volumes persistants. De même, lors du provisionnement d’un cluster Azure Kubernetes Service (AKS) avec cinq (5) nœuds, il est important de choisir une taille de machine virtuelle appropriée pour le pool de nœuds pour que 10 disques de données puissent y être attachés. Vous trouverez plus d’informations sur la taille des nœuds pour les besoins en stockage des nœuds AKS ici.

Choix de la classe de stockage appropriée

Sites locaux et périphériques

Microsoft et ses partenaires OEM, OS et Kubernetes ont un programme de validation pour les services de données Azure Arc. Ce programme fournit des résultats de tests comparables à partir d’une boîte à outils de tests de certification. Les tests évaluent la compatibilité des fonctionnalités, les résultats des tests de résistance, ainsi que les performances et l'évolutivité. Les résultats des tests indiquent le système d'exploitation utilisé, la distribution Kubernetes utilisée, le matériel utilisé, le module complémentaire CSI utilisé et les classes de stockage utilisées. Cela aide les clients à choisir la classe de stockage, le système d'exploitation, la distribution Kubernetes et le matériel les mieux adaptés à leurs besoins. Vous trouverez plus d’informations sur ce programme et les résultats des tests ici.

Cloud public, services Kubernetes managés

Pour les services Kubernetes managés et basés sur le cloud public, nous pouvons formuler les recommandations suivantes :