Partager via

Guide de dimensionnement

  • Article

Vue d’ensemble du guide de dimensionnement

Lors de la planification du déploiement des services de données Azure Arc, planifiez la quantité correcte de :

  • Compute
  • Mémoire
  • Stockage

Ces ressources sont requises pour :

  • Contrôleur de données
  • Instances managées SQL
  • Serveurs PostgreSQL

Étant donné que les services de données avec Azure Arc sont déployés sur Kubernetes, vous avez la possibilité d’ajouter plus de capacité à votre cluster Kubernetes au fil du temps par des nœuds de calcul ou un stockage. Ce guide décrit les exigences minimales et recommande des tailles pour certaines exigences courantes.

Spécifications générales de dimensionnement

Remarque

Si vous n’êtes pas familiarisé avec les concepts de cet article, vous pouvez en apprendre davantage sur la gouvernance des ressources Kubernetes et la notation de taille de Kubernetes.

Le nombre de cœurs doit être une valeur entière supérieure ou égale à un.

Lorsque vous déployez avec Azure CLI (az), utilisez une puissance de deux nombres pour définir les valeurs de mémoire. Plus précisément, utilisez les suffixes :

  • Ki
  • Mi
  • Gi

Les valeurs limites doivent toujours être supérieures à la valeur de la requête, si elles sont spécifiées.

Les valeurs limites pour les cœurs sont la métrique facturable sur les serveurs SQL Managed Instance et PostgreSQL.

Configuration de déploiement requise

Une taille minimale pour le déploiement des services de données activés pour Azure Arc peut être considérée comme étant le contrôleur de données Azure Arc, plus une instance SQL Managed Instance, plus un serveur PostgreSQL. Pour cette configuration, vous avez besoin d’au moins 16 Go de RAM et de 4 cœurs de capacité disponibles sur votre cluster Kubernetes. Vous devez vous assurer que vous disposez d’une taille minimale de nœud Kubernetes de 8 Go de RAM et de 4 cœurs et d’une capacité totale de 16 Go de RAM disponible sur tous vos nœuds Kubernetes. Par exemple, vous pouvez avoir 1 nœud à 32 Go de RAM et 4 cœurs, ou vous pouvez avoir 2 nœuds avec 16 Go de RAM et 4 cœurs chacun.

Pour plus d’informations sur le dimensionnement du stockage, consultez l’article Configuration du stockage.

Détails de la taille du contrôleur de données

Le contrôleur de données est une collection de pods déployés sur votre cluster Kubernetes pour fournir une API, le service de contrôleur, le programme d’amorçage et les bases de données de surveillance et les tableaux de bord. Ce tableau décrit les valeurs par défaut pour les demandes et les limites de mémoire et d’UC.

Nom du pod Demande d’UC Demande de mémoire Limite UC Limite de mémoire
bootstrapper 100m 100Mi 200m 200Mi
control 400m 2Gi 1800m 2Gi
controldb 200m 4Gi 800m 6Gi
logsdb 200m 1600Mi 2 1600Mi
logsui 100m 500Mi 2 2Gi
metricsdb 200m 800Mi 400m 2Gi
metricsdc 100m 200Mi 200m 300Mi
metricsui 20m 200Mi 500m 200Mi

metricsdc est un daemonset, qui est créé sur chacun des nœuds Kubernetes de votre cluster. Les nombres de la table sont par nœud. Si vous définissez allowNodeMetricsCollection = false dans votre fichier de profil de déploiement avant de créer le contrôleur de données, cette daemonset n’est pas créée.

Vous pouvez remplacer les paramètres par défaut des pods controldb et de contrôle dans votre fichier YAML du contrôleur de données. Exemple :

  resources:
    controller:
      limits:
        cpu: "1000m"
        memory: "3Gi"
      requests:
        cpu: "800m"
        memory: "2Gi"
    controllerDb:
      limits:
        cpu: "800m"
        memory: "8Gi"
      requests:
        cpu: "200m"
        memory: "4Gi"

Pour plus d’informations sur le dimensionnement du stockage, consultez l’article Configuration du stockage.

Détails de dimensionnement d’une instance gérée SQL

Chaque instance gérée SQL doit répondre aux limites et exigences de ressources minimales suivantes :

Niveau de service Usage général Critique pour l’entreprise
Demande d’UC Minimum : 1
Maximum : 24
Valeur par défaut : 2		 Minimum : 3
Maximum : illimité
Valeur par défaut : 4
Limite UC Minimum : 1
Maximum : 24
Valeur par défaut : 2		 Minimum : 3
Maximum : illimité
Valeur par défaut : 4
Demande de mémoire Minimum : 2Gi
Maximum : 128Gi
Valeur par défaut : 4Gi		 Minimum : 2Gi
Maximum : illimité
Valeur par défaut : 4Gi
Limite de mémoire Minimum : 2Gi
Maximum : 128Gi
Valeur par défaut : 4Gi		 Minimum : 2Gi
Maximum : illimité
Valeur par défaut : 4Gi

Chaque pod d’instance gérée SQL créé comporte trois conteneurs :

Nom du conteneur Demande UC Demande de mémoire Limite UC Limite de mémoire Notes
fluentbit 100m 100Mi Non spécifié(e) Non spécifié(e) Les demandes de ressources de conteneur fluentbit sont en plus de les requêtes spécifiées pour l’instance managée SQL.
arc-sqlmi Utilisateur spécifié ou non spécifié. Utilisateur spécifié ou non spécifié. Utilisateur spécifié ou non spécifié. Utilisateur spécifié ou non spécifié.
collectd Non spécifié(e) Non spécifié(e) Non spécifié(e) Non spécifié(e)

La taille du volume par défaut pour tous les volumes persistants est 5Gi.

Détails de dimensionnement du serveur PostgreSQL

Chaque nœud de serveur PostgreSQL doit avoir les ressources minimales suivantes :

  • Mémoire : 256Mi
  • Cœurs : 1

Chaque pod de serveurs PostgreSQL créé a trois conteneurs :

Nom du conteneur Demande UC Demande de mémoire Limite UC Limite de mémoire Notes
fluentbit 100m 100Mi Non spécifié(e) Non spécifié(e) Les demandes de ressources de conteneur fluentbit sont en plus de les requêtes spécifiées pour le serveur PostgreSQL.
postgres Utilisateur spécifié ou non spécifié. Utilisateur spécifié ou 256Mi (valeur par défaut). Utilisateur spécifié ou non spécifié. Utilisateur spécifié ou non spécifié.
arc-postgresql-agent Non spécifié(e) Non spécifié(e) Non spécifié(e) Non spécifié(e)

Dimensionnement cumulatif

La taille globale d’un environnement requis pour les services de données avec Azure Arc est principalement une fonction du nombre et de la taille des instances de base de données. La taille globale peut être difficile à prédire à l’avance, sachant que le nombre d’instances peut augmenter et réduire et la quantité de ressources requises pour chaque instance de base de données peut changer.

La taille de base d’un environnement de services de données avec Azure Arc donné est la taille du contrôleur de données, qui nécessite 4 cœurs et 16 Go de RAM. À partir de là, ajoutez le total cumulé des cœurs et de la mémoire requis pour les instances de base de données. SQL Managed Instance nécessite un pod pour chaque instance. Le serveur PostgreSQL crée un pod pour chaque serveur.

En plus des cœurs et de la mémoire que vous demandez pour chaque instance de base de données, vous devez ajouter 250m de cœurs et 250Mi de RAM pour les conteneurs d’agent.

Exemple de calcul de dimensionnement

Conditions requises :

  • « SQL1 »: 1 instance managée SQL avec 16 Go de RAM, 4 cœurs
  • « SQL2 » : 1 instance managée SQL avec 256 Go de RAM, 16 cœurs
  • « Postgres1 »: 1 serveur PostgreSQL à 12 Go de RAM, 4 cœurs

Calculs de dimensionnement :

  • La taille de « SQL1 » est la suivante : 1 pod * ([16Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). Pour les agents par pod, utilisez 16.25 Gi RAM et 4,25 cœurs.

  • La taille de « SQL2 » est la suivante : 1 pod * ([256Gi RAM, 16 cores] + [250Mi RAM, 250m cores]). Pour les agents par pod, utilisez 256.25 Gi RAM et 16,25 cœurs.

  • La taille totale de SQL 1 et de SQL 2 est la suivante :

    • (16.25 GB + 256.25 Gi) = 272.5-GB RAM
    • (4.25 cores + 16.25 cores) = 20.5 cores

  • La taille de « Postgres1 » est la suivante : 1 pod * ([12Gi RAM, 4 cores] + [250Mi RAM, 250m cores]). Pour les agents par pod, utilisez 12.25 Gi RAM et 4.25 cœurs.

  • Capacité totale requise :

    • Pour les instances de base de données :
      • RAM DE 272,5 GO
      • 20,5 cœurs
    • Pour SQL :
      • RAM DE 12,25 GO
      • 4,25 cœurs
    • Pour le serveur PostgreSQL
      • RAM DE 284,75 GO
      • 24,75 cœurs

  • La capacité totale requise pour les instances de base de données et le contrôleur de données est la suivante :

    • Pour l’instance de base de données
      • RAM DE 284,75 GO
      • 24,75 cœurs
    • Pour le contrôleur de données
      • 16 Go de RAM
      • 4 cœurs
    • Au total :
      • RAM DE 300,75 GO
      • 28,75 cœurs.

Pour plus d’informations sur le dimensionnement du stockage, consultez l’article Configuration du stockage.

Autres considérations

Gardez à l’esprit qu’une requête particulière de taille d’instance de base de données pour les cœurs ou la RAM ne peut pas dépasser la capacité disponible des nœuds Kubernetes dans le cluster. Par exemple, si le plus grand nœud Kubernetes que vous avez dans votre cluster Kubernetes est de 256 Go de RAM et de 24 cœurs, vous ne pouvez pas créer une instance de base de données avec une demande de 512 Go de RAM et 48 cœurs.

Conservez au moins 25 % de la capacité disponible sur les nœuds Kubernetes. Cette capacité permet à Kubernetes de :

  • Planifier efficacement les pods à créer
  • Activer la mise à l’échelle élastique
  • Prend en charge les mises à niveau propagées des nœuds Kubernetes
  • Facilite la croissance à long terme à la demande

Dans vos calculs de dimensionnement, ajoutez les besoins en ressources des pods système Kubernetes et toutes les autres charges de travail, qui peuvent partager la capacité avec les services de données avec Azure Arc sur le même cluster Kubernetes.

Pour maintenir la haute disponibilité pendant la maintenance planifiée et la continuité des sinistres, planifiez au moins l’un des nœuds Kubernetes de votre cluster pour qu’ils ne soient pas disponibles à un moment donné. Kubernetes tente de replanifier les pods qui s’exécutaient sur un nœud donné qui a été supprimé pour maintenance ou en raison d’une défaillance. S’il n’existe aucune capacité disponible sur les nœuds restants, ces pods ne seront pas replanifiés pour la création tant qu’il n’y aura pas de capacité disponible. Soyez extrêmement vigilant avec les grandes instances de base de données. Par exemple, s’il n’existe qu’un seul nœud Kubernetes suffisamment grand pour répondre aux besoins en ressources d’une grande instance de base de données et que ce nœud échoue, Kubernetes ne planifie pas ce pod d’instance de base de données sur un autre nœud Kubernetes.

Gardez les limites maximales pour une taille de cluster Kubernetes à l’esprit.

Votre administrateur Kubernetes peut avoir configuré des quotas de ressources sur votre espace de noms/projet. Gardez cela à l’esprit lors de la planification de la taille de vos instances de base de données.