Considérations sur les performances

Cette page vous explique comment configurer votre environnement Google Cloud Managed Lustre pour obtenir les meilleures performances.

Pour consulter les chiffres de performances spécifiques à chaque niveau de performances, consultez Niveaux de performances.

Performances après l'augmentation de la capacité

L'augmentation de la capacité de stockage d'une instance existante augmente son débit et ses IOPS maximaux, et éventuellement ses performances de métadonnées.

Les performances de débit de lecture s'améliorent progressivement à mesure que de nouvelles données sont écrites et redistribuées dans l'espace de stockage supplémentaire. Les performances du débit en écriture augmentent immédiatement.

Utilisation élevée de la capacité

Lorsque l'utilisation de la capacité de stockage d'une instance atteint 90%, les performances de l'instance peuvent être réduites. Envisagez d'augmenter la capacité de votre instance Managed Lustre. Vous devrez peut-être demander un quota supplémentaire avant l'expansion.

Si des erreurs No space left on device s'affichent, mais que votre instance indique une capacité restante, consultez Erreurs No space left on device.

Unité de transmission maximale (MTU) du réseau VPC

Lorsque vous créez votre réseau VPC, définir la valeur de mtu (unité de transmission maximale, ou la taille du plus grand paquet IP pouvant être transmis sur ce réseau) sur la valeur maximale autorisée de 8 896 améliore les performances jusqu'à 10% par rapport à la valeur par défaut de 1 460 octets.

Vous pouvez afficher la valeur MTU actuelle de votre réseau à l'aide de la commande suivante :

gcloud compute networks describe NETWORK_NAME --format="value(mtu)"

La valeur MTU d'un réseau peut être modifiée après la création du réseau, mais il y a des points importants à prendre en compte. Pour en savoir plus, consultez Modifier la MTU d'un réseau.

Types de machines Compute Engine

Le débit du réseau peut être affecté par le type de machine que vous choisissez. En général, pour obtenir le meilleur débit :

  • Augmenter le nombre de vCPU La bande passante de sortie maximale par instance est généralement de 2 Gbit/s par processeur virtuel, jusqu'au maximum du type de machine.
  • Sélectionnez une série de machines compatible avec des limites d'entrée et de sortie plus élevées. Par exemple, les instances C2 avec mise en réseau Tier_1 acceptent une bande passante de sortie allant jusqu'à 100 Gbit/s. Les instances C3 avec mise en réseau Tier_1 acceptent jusqu'à 200 Gbit/s.
  • Activez les performances réseau Tier_1 par VM avec des types de machines plus grands.
  • Utilisez la carte d'interface réseau virtuelle Google (gVNIC). gVNIC est la seule option pour les types de machines de génération 3 et ultérieurs. gVNIC est obligatoire lorsque vous utilisez la mise en réseau Tier_1.

Pour en savoir plus, consultez Bande passante réseau.

Configuration de plusieurs cartes d'interface réseau

En utilisant la fonctionnalité multirail intégrée de Lustre, les clients peuvent répartir le trafic réseau sur plusieurs cartes d'interface réseau (multi-NIC). Cela permet d'agréger la bande passante pour saturer les instances Managed Lustre à haute capacité.

Pour configurer plusieurs cartes d'interface réseau, vous devez :

  • Sélectionnez un type de machine avec plusieurs cartes d'interface réseau physiques.
  • Créez un sous-réseau pour chaque carte d'interface réseau et attribuez chaque carte à son sous-réseau.
  • Suivez la procédure multi-NIC lorsque vous vous connectez depuis Compute Engine ou GKE.

Vérifier l'équilibrage du trafic

Une fois que vous avez configuré plusieurs cartes d'interface réseau, vérifiez que les données sont correctement équilibrées.

Compute Engine

Vérifiez l'équilibrage des données directement sur la VM en surveillant les interfaces réseau configurées (par exemple, eth0 et eth1) à l'aide de nload tout en générant du trafic vers le backend Managed Lustre :

nload -m eth0 eth1

Dans une configuration multi-NIC réussie, les débits sortants doivent être à peu près équivalents sur toutes les interfaces configurées.

GKE

Vérifiez que le trafic réseau de votre charge de travail est équilibré sur plusieurs cartes d'interface réseau en déployant un pod de débogage réseau temporaire sur le nœud où votre charge de travail est planifiée :

  1. Identifiez le nœud sur lequel votre charge de travail est planifiée :

    kubectl get pod POD_NAME -o wide

    Remplacez POD_NAME par le nom de votre pod. Dans le résultat de la commande, notez le nom dans la colonne NODE.

  2. Lancez le débogueur réseau sur ce nœud :

    kubectl run multi-nic-debug --rm -i --tty --image=nicolaka/netshoot \
  --overrides='{"spec": {"hostNetwork": true, "nodeSelector": {"kubernetes.io/hostname": "NODE_NAME"}, "tolerations": [{"key": "nvidia.com/gpu", "operator": "Exists", "effect": "NoSchedule"}]}}' \
  -- /bin/bash -c "apk update && apk add nload && nload -m eth0 eth1"

    Remplacez NODE_NAME par le nom du nœud de l'étape précédente.

  3. Dans le résultat, analysez les débits binaires de la colonne Sortant pour eth0 et eth1. Si la configuration réussit, les débits sont à peu près équivalents. Le résultat ressemble à ce qui suit :

    Device eth0 [10.1.0.50] (1/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.63 MBit/s                       Curr: 1.46 GBit/s
Avg: 1.60 MBit/s                        Avg: 1.44 GBit/s
Min: 1.40 MBit/s                        Min: 1.25 GBit/s
Max: 1.64 MBit/s                        Max: 1.47 GBit/s
Ttl: 590.94 GByte                       Ttl: 405.19 GByte

Device eth1 [172.16.15.5] (2/2):
==========================================================================
Incoming:                               Outgoing:
Curr: 1.64 MBit/s                       Curr: 1.47 GBit/s
Avg: 1.62 MBit/s                        Avg: 1.44 GBit/s
Min: 1.42 MBit/s                        Min: 1.26 GBit/s
Max: 1.66 MBit/s                        Max: 1.47 GBit/s
Ttl: 587.68 GByte                       Ttl: 406.36 GByte

  4. Quittez le débogueur en appuyant sur Ctrl+C.

Résoudre les goulots d'étranglement courants

Si les performances de votre charge de travail sont nettement inférieures à celles attendues pour votre niveau de performances Managed Lustre, vérifiez les problèmes courants suivants :

  • Nombre insuffisant de machines clientes : une seule machine cliente est limitée par ses propres limites de traitement de réseau à un seul lien et de processeur virtuel (vCPU). Pour saturer les niveaux à haut débit, vous devez répartir la charge. Par exemple, pour saturer un système de fichiers Managed Lustre de 100 000 Mo/s, vous avez généralement besoin d'au moins 60 machines clientes standards (ou 12 machines clientes configurées pour utiliser un réseau à bande passante élevée de niveau 1) écrivant en parallèle. Pour la taille d'instance maximale de n'importe quel niveau de performances, vous aurez peut-être besoin de plus de 2 500 machines clientes configurées pour utiliser la mise en réseau Tier 1 à bande passante élevée.

  • MTU non idéale du cloud privé virtuel (VPC) : par défaut, les réseaux VPC utilisent une MTU de 1460 (trames Ethernet standards). Pour le stockage hautes performances comme Managed Lustre, vous devez configurer des trames géantes avec une MTU de 8896. L'exécution avec une MTU 1460 standard oblige le processeur à traiter plus du double du nombre de paquets réseau, ce qui ajoute une surcharge de processeur et limite la bande passante maximale.

  • Configuration de la bande passante réseau de niveau 1 manquante : de nombreux types de machines hautes performances nécessitent que vous activiez explicitement la bande passante réseau de niveau 1.

    • Sur les pools de nœuds Compute Engine et GKE Standard, utilisez l'option --network-performance-configs=total-egress-bandwidth-tier=TIER_1 lors de la création. Sans cet indicateur, une VM ou un nœud peuvent être plafonnés à une limite de sortie par défaut inférieure.
    • Sur GKE Autopilot, vous ne spécifiez pas cet indicateur directement. À la place, sélectionnez une série de machines qui prend en charge une bande passante plus élevée (par exemple, c3) à l'aide de sélecteurs de nœuds dans les spécifications de vos pods.

    Pour en savoir plus, consultez Types de machines Compute Engine.

  • Utilisation déséquilibrée des cibles de stockage d'objets (OST) Lustre : Lustre géré divise les données de fichier sur plusieurs cibles de stockage d'objets (OST). Si votre test ou votre charge de travail écrivent dans un seul fichier non rayé, ou si les tâches client écrivent des modèles qui surchargent un seul OST, cet OST devient un goulot d'étranglement tandis que le reste du système de fichiers reste inactif. Pour éviter cela, assurez-vous de répartir la charge utile d'écriture de manière uniforme sur tous les OST disponibles (par exemple, en utilisant le mode "un fichier par processus" dans les benchmarks).

  • Contention de la bande passante réseau partagée : la bande passante de sortie sur les machines clientes (VM Compute Engine ou nœuds GKE) est partagée entre toutes les opérations réseau sur la machine. Si vos machines clientes ou vos pods téléchargent simultanément de gros packages, exécutent des analyses de journalisation lourdes ou communiquent de manière intensive avec d'autres nœuds de cluster, les performances de votre stockage seront limitées à la bande passante réseau restante.