Disciplines de stockage pour SQL Managed Instance avec Azure Arc
Le stockage est un composant critique d’un déploiement SQL Managed Instance avec Azure Arc (SQL Managed Instance avec Arc). Comprendre comment les concepts de stockage décrits dans ce document ont un impact sur le fonctionnement des clusters Kubernetes est un aspect important des choix de conception de stockage et de la gestion.
Au lieu d’interagir directement avec le stockage sous-jacent, Kubernetes fournit une couche d’abstraction à différentes technologies de stockage via des classes de stockage. Les fournisseurs de cloud, les fournisseurs de matériel et les autres plateformes managées par Kubernetes offrent différentes options de StorageClass adaptées à des environnements et des scénarios d’implémentation spécifiques.
SQL Managed Instance avec Arc n’impose pas de limites ou de contraintes au niveau des classes de stockage. Il est donc important de choisir la conception et la configuration de stockage appropriées. La conception de stockage pour SQL Managed Instance avec Arc est aussi importante que si vous choisissiez des dispositifs de stockage de sauvegarde pour un SQL Server s’exécutant sur du matériel nu ou des machines virtuelles. Ces choix représentent en définitive vos besoins en matière de RPO, de RTO, de capacité et de performances.
Pour les déploiements SQL Managed Instance avec Arc, il est essentiel de prévoir les capacités de stockage et la configuration pour assurer un bon fonctionnement. Poursuivez votre lecture pour découvrir les éléments à prendre en considération en ce qui concerne le stockage, suivis des recommandations en matière de configuration de SQL Managed Instance avec Arc.
Architecture
Le diagramme d’architecture suivant illustre la conception logique des composants des services de données avec Azure Arc. Parmi ces composants figurent le nécessaire contrôleur de données Azure Arc ainsi qu’une ou plusieurs instances de SQL Managed Instance avec Arc contenant des bases de données provisionnées pour référence. Le contrôleur de données Azure Arc et SQL Managed Instance avec Arc proposent tous deux des options de dispositifs de stockage de sauvegarde, qui varient en fonction de la distribution Kubernetes et des fournisseurs d’infrastructure de stockage.
Remarques relatives à la conception
Vous trouverez ci-dessous les éléments à prendre en considération en ce qui concerne la conception et la configuration de votre stockage.
Classes de stockage
Il est important de choisir la StorageClass Kubernetes et la configuration les plus adaptées à vos composants de services de données compatibles avec Azure Arc pour favoriser les performances, la résilience et la capacité de votre stockage de données.
StorageClass, PersistentVolume (PV) et PersistentVolumeClaim (PVC) sont les objets de ressource Kubernetes que le système crée dans votre cluster Kubernetes au moment de provisionner les composants de services de données compatibles avec Azure Arc.
Les options de StorageClass varient en fonction de ce que proposent votre fournisseur de cloud et votre fournisseur de matériel ainsi que de la configuration réalisée par l’administrateur Kubernetes. PersistentVolumeClaim demande à ce qu’un volume persistant (PersistentVolume) soit créé pour la StorageClass et la taille demandées. Le diagramme suivant est une illustration de la relation entre ces ressources Kubernetes et les options possibles pour les classes de stockage.
Les ressources Kubernetes PV et PVC sont configurées au moment de provisionner, respectivement, le contrôleur de données Azure Arc et SQL Managed Instance avec Arc.
Vous avez le choix entre deux types de stockage :
- Local : volume monté sur un dispositif de stockage local attaché au nœud Kubernetes sur lequel s’exécute le pod. Ce type de stockage offre généralement une latence plus faible ainsi qu’un nombre d’opérations d’entrée/sortie par seconde (IOPS) et un débit plus élevés qu’un stockage à distance/partagé.
- Stockage à distance/partagé : dispositifs de stockage attachés au réseau assortis généralement d’une redondance intégrée. Parmi les options de stockage les plus courantes figurent les dispositifs NAS et SAN.
Au moment de choisir une StorageClass, tenez compte des standards suivants. Ces critères valent aussi pour tout serveur de base de données que vous seriez amené à mettre en place :
- Performances : le débit d’entrée/sortie (E/S) et le nombre d’IOPS du dispositif de stockage doivent répondre aux besoins de votre base de données.
- Rapport lecture/écriture : comprendre la charge de travail peut vous aider à choisir le matériel de sauvegarde de façon à répondre au mieux à vos besoins tout en limitant les coûts. Les charges de travail gourmandes en écritures peuvent tirer parti des configurations RAID 0, tandis que les données rarement consultées feront un meilleur usage d’un dispositif de stockage SAN.
- Isolation et colocalisation de bases de données : toutes les bases de données présentes sur une instance de SQL Managed Instance avec Arc partagent le même PV. De ce fait, vous pouvez choisir de déplacer les bases de données sur des instances distinctes de SQL Managed Instance avec Arc et ainsi éviter la contention des ressources de stockage.
- Capacité : la taille de stockage définie doit correspondre à la capacité future de votre contrôleur de données et des instances de base de données pour éviter d’avoir à redimensionner un PVC. Tenez compte des éventuelles limitations de stockage de la StorageClass que vous choisissez.
- Mode d’accès : les fournisseurs de classes de stockage proposent différents modes d’accès, prenant en charge différentes capacités de montage, de lecture ou d’écriture de stockage par les pods. RWX (Read Write Many) est requis pour le volume de sauvegarde SQL.
- Redondance : réplication des données au niveau de la couche de stockage physique (RAID) pour permettre un basculement harmonieux en cas de défaillance de disque matériel, qui est différent de la redondance au niveau de la base de données effectuée par les groupes de disponibilité.
Les services de données du contrôleur de données Azure Arc et de SQL Managed Instance avec Arc proposent des options granulaires pour configurer différentes classes de stockage pour les données de base de données. Ces services de données fournissent aussi des journaux, ce qui autorise une certaine flexibilité quant au choix de classes de stockage qui répondent aux besoins.
Contrôleur de données
Un cluster Kubernetes a besoin d’un contrôleur de données Azure Arc comme prérequis à la création d’instances de SQL Managed Instance avec Arc. L’exécution de plusieurs contrôleurs de données dans un cluster n’est pas prise en charge.
Quatre pods avec état différents s’exécuteront pour le contrôleur de données Azure Arc dans le cluster Kubernetes : Controller SQL, Controller API, Logs DB et Metrics DB. Chaque pod a besoin de deux volumes persistants pour les volumes de données et de journaux. Tous les composants du contrôleur de données ont besoin d’une StorageClass distante pour garantir la durabilité des données, car les composants du contrôleur de données n’assurent pas eux-mêmes la durabilité des données en mode natif.
Veillez à prendre en considération les ressources de calcul et de mémoire nécessaires au contrôleur de données Azure Arc. Le diagramme suivant représente le stockage du contrôleur de données, les ressources PV et PVC Kubernetes.
Le dimensionnement du volume par défaut du contrôleur de données est le minimum recommandé. La quantité de stockage que vous utilisez dépend du nombre de bases de données, de la façon dont vous utilisez les bases de données et du nombre de journaux générés. La StorageClass du contrôleur de données Azure Arc n’est pas sensible à la faible latence. Malgré cela, les utilisateurs peuvent constater des avantages à utiliser un stockage plus rapide dans les interfaces Grafana et Kibana en présence de nombreux déploiements SQL Managed Instance avec Arc dans un cluster. Grafana et Kibana sont des outils de visualisation de monitoring open source déployés avec le contrôleur de données et provisionnés avec des tableaux de bord permettant la consultation des métriques et des journaux pour SQL Managed Instance avec Arc.
Provisionnement du contrôleur de données
Au moment de provisionner le contrôleur de données Azure Arc, configurez la StorageClass et la capacité de stockage pour les journaux et les données. La configuration du stockage pour les journaux et les données s’applique aux huit PV que vous créez pour les pods du contrôleur de données. Pendant le provisionnement, vous pouvez spécifier un modèle de déploiement personnalisé qui remplace les paramètres par défaut comme la capacité, la conservation des journaux et les éléments liés à la sécurité, tels que les types de service Kubernetes. Une fois le provisionnement terminé, les objets PV et PVC de Kubernetes sont créés.
Il est important de comprendre que la StorageClass du contrôleur de données ne peut plus être modifiée une fois qu’elle est provisionnée. Si vous ne spécifiez pas de StorageClass, le contrôleur de données utilise la StorageClass par défaut de Kubernetes, laquelle peut varier en fonction de votre instance ou fournisseur Kubernetes.
Quand vous désinstallez le contrôleur de données Azure Arc, tous les volumes persistants qui lui sont associés sont supprimés. Archivez les éventuels journaux de niveau plan de contrôle des services de données compatibles avec Azure Arc que votre organisation a besoin de conserver avant de désinstaller le contrôleur de données.
SQL Managed Instance avec Azure Arc
SQL Managed Instance avec Arc propose deux niveaux différents pour répondre aux besoins de l’entreprise : Usage général et Critique pour l’entreprise. Pour les deux niveaux, il est important de passer en revue les limites minimales et maximales de SQL Managed Instance avec Arc, qui sont configurables, et de garantir que le cluster Kubernetes déployé dispose de la capacité de calcul et de mémoire appropriée.
Dans les scénarios où une même instance de base de données comporte plusieurs bases de données, toutes les bases de données utilisent les mêmes StorageClass, PVC et PV spécifiés pour SQL Managed Instance avec Arc. Plusieurs instances de SQL Managed Instance avec Arc peuvent coexister dans un même cluster Kubernetes. Cette configuration autorise la présence de volumes persistants indépendants et peut aider à séparer la contention des E/S des différentes bases de données en déployant les bases de données dans différentes instances de SQL Managed Instance avec Arc.
Le tableau suivant décrit les différents volumes persistants utilisés par chaque pod SQL Managed Instance avec Arc et leur objectif.
| Volume persistant | Description | Exigences liées à la classe de stockage |
|---|---|---|
| Données | Fichiers de données SQL Database (fichiers .mdf) | Dépend du niveau |
| DataLogs | Fichiers journaux SQL Database (fichiers .ldf) | Dépend du niveau |
| Journaux d’activité | Agent SQL, journaux d’erreurs, fichiers de trace, journaux d’intégrité | Dépend du niveau |
| Sauvegardes | Fichiers de sauvegarde SQL Server (complète, différentielle et transactionnelle) | Mode d’accès distant ReadWriteMany |
Niveau de service Usage général
Le niveau Usage général de SQL Managed Instance avec Arc doit utiliser le stockage distant pour l’instance de base de données de telle sorte que, en cas d’échec d’un pod, les données restent accessibles aux pods nouvellement créés. Le basculement est géré par le pod Kubernetes et l’orchestration des nœuds. Cette configuration est moins complexe comparée à celle du niveau Critique pour l’entreprise, qui utilise des groupes de disponibilité SQL et plusieurs réplicas SQL Managed Instance avec Arc. La configuration à un seul pod du niveau Usage général signifie que vous pouvez réduire la quantité de stockage, car vous n’avez pas besoin de dupliquer la capacité de stockage pour d’autres réplicas.
Niveau de service Critique pour l’entreprise
Le niveau Critique pour l'entreprise utilise un modèle à plusieurs pods où les volumes de données et de journaux peuvent être stockés dans des classes de stockage locales ou distantes. Les classes de stockage locales fonctionnent généralement mieux en termes de latence et de débit, car le dispositif de stockage est directement attaché au nœud. Le stockage à distance offre généralement une redondance intégrée, mais sa latence et son débit sont souvent plus faibles par rapport au stockage local. Ne perdez pas de vue que l’utilisation d’un plus grand nombre de réplicas de base de données Critiques pour l’entreprise nécessite des volumes persistants supplémentaires pour les données, les journaux et les DataLogs. La capacité de stockage totale nécessaire est beaucoup plus élevée.
Le diagramme suivant montre la configuration de stockage Critique pour l’entreprise pour SQL Managed Instance avec Arc avec deux réplicas.
Le niveau Critique pour l’entreprise vous permet de configurer deux ou trois réplicas secondaires. Le basculement est géré par le groupe de disponibilité SQL Always On, ce qui permet de subir moins de temps d’arrêt lors des mises à niveau et les défaillances qu’avec le niveau Usage général.
La configuration de plusieurs réplicas avec la réplication de données en mode commit synchrone assure une meilleure protection contre les défaillances susceptibles de toucher un pod, un nœud ou un matériel de stockage, par exemple. Cette protection contre les défaillances s’explique par la présence de plusieurs copies des données sur les réplicas. Envisagez de configurer des réplicas secondaires en tant qu’instances de scale-out en lecture, auxquelles les clients peuvent se connecter quand le point de terminaison de l’écouteur secondaire est utilisé.
Provisionnement et désinstallation d’Azure Arc SQL Managed Instance
Au moment de provisionner SQL Managed Instance avec Arc, vous avez la possibilité d’affecter différentes classes de stockage à chacun des volumes persistants SQL Managed Instance avec Arc nécessaires. Vous souhaiterez peut-être des options de stockage plus performantes pour les données et les DataLogs, mais les volumes Journaux et Sauvegarde peuvent utiliser des options de StorageClass plus économiques pour réduire les coûts. Dans les scénarios où vous utilisez un stockage local, vérifiez que les volumes peuvent être placés sur des nœuds et des dispositifs de stockage physiques différents pour éviter toute contention au niveau des E/S disque. Le fait de placer les données et les DataLogs sur le même lecteur physique peut occasionner une contention pour ce lecteur de stockage, ce qui se traduit par un niveau de performance médiocre. Au lieu de cela, envisagez de placer les données et les DataLogs sur des lecteurs de stockage distincts pour paralléliser les E/S pour les données et les journaux de base de données.
Quand vous supprimez SQL Managed Instance avec Arc, les PV et PVC associés ne sont pas supprimés. Ce comportement est l’assurance que vous pouvez accéder aux fichiers de base de données en cas de suppression accidentelle.
Recommandations de conception
Voici quelques recommandations pour la conception et la configuration de votre stockage.
Classes de stockage pour les charges de travail de production
Pour certains clouds publics, les classes de stockage recommandées dans le cas des charges de travail de production sont indiquées dans le tableau suivant.
| Fournisseur | Stockage validé et recommandé |
|---|---|
| Azure Kubernetes Service (AKS) | Disques managés Azure (niveau Premium) |
| Amazon Elastic Kubernetes Service (EKS) | Pilote de stockage CSI EBS |
| Google (GKE) | Disques persistants GCE |
Quand vous choisissez une StorageClass de production dans des scénarios locaux ou multiclouds, vérifiez qu’elle est en mesure de satisfaire vos besoins en matière de capacité de stockage, d’IOPS, de redondance et de débit. Les sections ci-dessous fournissent des recommandations supplémentaires pour ces scénarios.
Conception du contrôleur de données
Choisissez une StorageClass distance et partagée pour garantir la durabilité des données. En cas de suppression d’un pod ou d’un nœud, vous pouvez restaurer la sauvegarde du pop et le reconnecter au volume persistant. La StorageClass sous-jacente doit offrir une redondance et une haute disponibilité.
Nous vous recommandons d’utiliser un modèle de déploiement personnalisé au moment de créer votre contrôleur de données des services de données compatibles avec Arc. Un modèle personnalisé vous permet d’ajuster les classes de stockage, la taille de stockage pour les données et les journaux, la sécurité et les types de service Kubernetes. Vous pouvez les personnaliser pour les besoins de votre environnement et de votre entreprise. Le contrôleur de données Azure Arc a besoin au total de huit volumes persistants. La configuration minimale par défaut autorise 15 Gi pour les données et 10 Gi pour les journaux sur les PV. Configurez une capacité qui satisfait non seulement aux recommandations minimales, mais qui permet également de faire face à une croissance supérieure liée à l’exécution de nombreuses implémentations de SQL Managed Instance avec Arc dans un cluster. Cette configuration vous évitera d’avoir à redimensionner les PVC par la suite.
Nous vous recommandons de choisir une StorageClass à plus faible latence si votre cluster comporte un grand nombre de bases de données et de déploiements SQL Managed Instance avec Arc. Une latence plus faible profite à l’expérience utilisateur dans les interfaces Grafana et Kibana.
Migration de SQL Managed Instance avec Azure Arc
Nous vous recommandons de prévoir et de prendre en compte toutes les bases de données nouvelles et existantes impliquées dans la migration et le déploiement de votre instance de SQL Managed Instance avec Arc. Cette planification vous évitera par la suite d’avoir à déplacer des bases de données entre les instances.
Selon l’organisation de vos clusters Kubernetes, provisionnez les déploiements SQL Managed Instance avec Arc sur différents clusters Kubernetes selon que vous devez séparer les environnements (hors production/production), les régions et d’autres éléments opérationnels. Passez en revue le domaine de conception Organisation des ressources pour obtenir d’autres recommandations. Si vous configurez plusieurs instances de base de données sur un cluster, veillez à séparer les bases de données occupées dans leur propre instance pour éviter toute contention d’E/S.
Utilisez des étiquettes de nœud de sorte que les instances de base de données soient placées sur des nœuds distincts afin de répartir le trafic d’E/S global entre plusieurs nœuds. Pour configurer les étiquettes, consultez Étiquettes de nœud Kubernetes et Étiquettes avec affinité et anti-affinité de nœud Kubernetes. Si vous utilisez un environnement virtualisé, vérifiez que les E/S sont réparties de manière appropriée au niveau de l’hôte physique.
Planifiez la capacité pour SQL Managed Instance avec Arc afin d’inclure des tailles de stockage adéquates pour les données, les journaux, les DataLogs et les sauvegardes. En prévoyant une capacité à même de répondre aux besoins actuels et à la croissance prévue de toutes les bases de données qui résident dans les instances de SQL Managed Instance avec Arc, vous n’aurez pas besoin par la suite de redimensionner les PVC. Choisissez des lecteurs physiques distincts pour les données et les DataLogs pour permettre une activité d’E/S parallèle. L’activité d’E/S parallèle a pour effet d’améliorer le niveau de performance en évitant toute contention liée à l’utilisation d’un lecteur partagé.
Bien que plusieurs facteurs puissent prescrire un déploiement du niveau Critique pour l’entreprise ou Usage général de SQL Managed Instance avec Arc, le niveau Critique pour l’entreprise couplé à un stockage local offre la latence la plus faible et la disponibilité la plus élevée. Passez en revue le domaine de conception Continuité d’activité de SQL Managed Instance avec Arc pour obtenir des recommandations concernant la restauration à un instant dans le passé, la haute disponibilité et la reprise d’activité. Par ailleurs, passez en revue le domaine de conception Gouvernance des coûts liés à SQL Managed Instance avec Arc pour en savoir plus sur l’impact des niveaux sur les coûts.
Les sous-sections suivantes fournissent des recommandations plus spécifiques pour chaque niveau :
Recommandations pour le niveau de service Usage général
Pour un niveau de performance optimal, il est recommandé de choisir une StorageClass distante à faible latence pour les volumes persistants de données et de DataLogs. Évitez d’utiliser une StorageClass qui introduise des partitions réseau, ce qui est notamment le cas si vous configurez un cluster local pour qu’il utilise une StorageClass fournie par Internet pour les volumes persistants de sauvegarde et de journaux.
Recommandations pour le niveau de service Critique pour l’entreprise
Il est recommandé de passer en revue les différences entre les modes de disponibilité, qui exigent une configuration différente.
Pour les scénarios nécessitant la latence la plus faible possible, choisissez le stockage local si cette option est disponible pour votre infrastructure Kubernetes. Les volumes de stockage local doivent se trouver sur différents dispositifs de stockage sous-jacents pour éviter toute contention au niveau des E/S disque et optimiser les performances. Le dispositif de stockage ne doit pas remplir plusieurs fonctions, comme l’hébergement de la partition du système d’exploitation.
Pour les charges de travail gourmandes en lectures et à haute disponibilité, configurez plusieurs réplicas et faites en sorte que vos applications ou clients utilisent des réplicas secondaires en tant qu’instances de scale-out en lecture. Les réplicas secondaires ne sont pas lisibles par défaut ; vous pouvez configurer le paramètre.
Surveillance
Il est recommandé de superviser tous les PVC créés par les services de données compatibles avec Arc, notamment le contrôleur de données Azure Arc et toutes les instances de SQL Managed Instance avec Arc d’un cluster. Définissez des alertes pour vous avertir qu’un PVC se rapproche de sa capacité maximale. La notification vous permettra de redimensionner le PVC avant d’atteindre la capacité maximale. Pour les clusters directement connectés, le monitoring des PVC et les alertes sont assurés par Azure Monitor et Container Insights. Quand vous utilisez des clusters indirectement connectés, effectuez le monitoring et les alertes dans Grafana et Kibana. L’installation de Grafana comprend des tableaux de bord pour les métriques SQL Managed Instance avec Arc et les ressources Kubernetes.
Passez en revue les disciplines de gouvernance de SQL Managed Instance avec Arc pour obtenir des recommandations supplémentaires sur la supervision de SQL Managed Instance avec Arc.
Étapes suivantes
Pour plus d’informations sur votre parcours cloud hybride et multicloud, consultez les articles suivants :
- Passez en revue la configuration du stockage pour les services de données compatibles avec Azure Arc.
- Passez en revue les distributions Kubernetes validées pour les services de données compatibles avec Azure Arc.
- Passez en revue les conseils de dimensionnement pour les services de données compatibles avec Azure Arc.
- Passez en revue le monitoring avec Grafana et Kibana d’une instance SQL Managed Instance avec Arc.
- Découvrez les scénarios automatisés SQL Managed Instance avec Arc avec Azure Arc Jumpstart.
- Pour en savoir plus sur Azure Arc, consultez le Parcours d’apprentissage Azure Arc sur Microsoft Learn.