Sizing Guidance

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
• Memory
• Storage

Ces ressources sont requises pour :

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

É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

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 l’instance managée SQL.

Configuration de déploiement requise

Un déploiement de services de données avec Azure Arc de taille minimale peut être considéré comme le contrôleur de données Azure Arc et une instance managée SQL. For this configuration, you need at least 16-GB RAM and 4 cores of available capacity on your Kubernetes cluster. 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.

See the storage-configuration article for details on storage sizing.

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.

metricsdc est un daemonset, qui est créé sur chacun des nœuds Kubernetes de votre cluster. The numbers in the table are per node. 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. Example:

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

See the storage-configuration article for details on storage sizing.

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 :

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

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

Cumulative sizing

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.

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

Requirements:

• "SQL1": 1 SQL managed instance with 16-GB RAM, 4 cores
• "SQL2": 1 SQL managed instance with 256-GB RAM, 16 cores

Sizing calculations:

• 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 :
    • 272.5-GB RAM
    • 20.5 cores
  • For SQL:
    • 12.25-GB RAM
    • 4.25 cores

• 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
    • 284.75-GB RAM
    • 24.75 cores
  • Pour le contrôleur de données
    • 16-GB RAM
    • 4 cores
  • In total:
    • 300.75-GB RAM
    • 28.75 cores.

See the storage-configuration article for details on storage sizing.

Other considerations

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.

Your Kubernetes administrator may have set up resource quotas on your namespace/project. Gardez cela à l’esprit lors de la planification de la taille de vos instances de base de données.