Bonnes pratiques de mise en réseau

Ce document décrit les bonnes pratiques à suivre pour créer un environnement de mise en réseau sécurisé et résilient pour les charges de travail AI Hypercomputer. Ces recommandations s'adressent aux architectes réseau, aux ingénieurs réseau et aux développeurs qui souhaitent configurer et déployer des charges de travail d'intelligence artificielle (IA) et de machine learning (ML) sur AI Hypercomputer.

Définir des rôles IAM clairs et limités

Une configuration correcte d'IAM contribue à améliorer la sécurité et la réussite de vos déploiements AI Hypercomputer. Dans les environnements de production, des autorisations insuffisantes ou mal configurées peuvent entraîner des échecs de déploiement. Les déploiements AI Hypercomputer, en particulier ceux qui utilisent Cluster Toolkit, échouent souvent dans les environnements avec des postures de sécurité renforcées où le compte de service Compute Engine par défaut ne dispose pas du rôle étendu Editor.

Pour atténuer les problèmes de déploiement qui peuvent survenir en raison de problèmes d'autorisation, suivez les bonnes pratiques listées dans cette section.

Utiliser des comptes de service dédiés

Pour une meilleure sécurité et un meilleur contrôle, évitez d'utiliser le compte de service Compute Engine par défaut. Créez plutôt un compte de service dédié pour votre déploiement AI Hypercomputer.

Vous pouvez utiliser Workload Identity gérée pour authentifier et autoriser les charges de travail au lieu d'utiliser des jetons de compte de service. Pour en savoir plus, consultez Authentifier des charges de travail à l'aide de mTLS pour Compute Engine ou Workload Identity pour GKE.

Accorder les rôles IAM nécessaires

Attribuez les rôles IAM suivants au compte de service dédié que vous avez créé :

  • Administrateur Compute (roles/compute.admin) : fournit un contrôle complet sur les ressources Compute Engine.
  • Utilisateur du compte de service (roles/iam.serviceAccountUser) : permet d'associer le compte de service à d'autres ressources, ce qui est essentiel pour les outils tels que Packer lors de la création d'images personnalisées.
  • Administrateur de l'espace de stockage (roles/storage.admin) : nécessite d'accéder aux buckets Cloud Storage et de les gérer, par exemple pour stocker des images Packer ou d'autres artefacts.
  • Administrateur Logging (roles/logging.admin) : permet au compte de service de configurer la journalisation et d'afficher les journaux, ce qui est essentiel pour le débogage.

Vérifier les autorisations avant le déploiement

Avant de commencer un déploiement, vérifiez que votre compte de service dispose des autorisations nécessaires. Exécutez la gcloud projects get-iam-policy commande :

gcloud projects get-iam-policy PROJECT_ID \
    --flatten="bindings[].members" \ format='table(bindings.role)' \
    --filter="bindings.members:serviceAccount:SERVICE_ACCOUNT_EMAIL"

Remplacez les éléments suivants :

  • PROJECT_ID : ID de votre Google Cloud projet.
  • SERVICE_ACCOUNT_EMAIL: adresse e-mail du compte de service que vous souhaitez vérifier.

Cette commande liste tous les rôles accordés à votre compte de service sur le projet spécifié. Assurez-vous que les rôles listés dans Accorder les rôles IAM nécessaires s'affichent dans le résultat.

Restreindre l'accès au réseau public et renforcer les configurations de pare-feu

Restreignez l'accès au réseau public et renforcez les configurations de pare-feu pour améliorer la sécurité. Cette pratique de sécurité fondamentale atténue le risque de règles de pare-feu par défaut trop permissives.

Des échecs de configuration de machine virtuelle (VM) peuvent se produire dans les environnements de production en raison de configurations de pare-feu restrictives qui ne sont pas présentes dans les tests internes. Les ingénieurs peuvent avoir des difficultés à diagnostiquer ces échecs sans connaître les règles de pare-feu spécifiques.

Vérifiez et mettez à jour vos règles de pare-feu afin de réduire au maximum l'exposition directe à Internet. Pour en savoir plus sur les règles de pare-feu VPC, consultez la section Règles de pare-feu VPC.

Standardiser les paramètres internes par défaut de mise en réseau

Standardisez les paramètres internes par défaut de mise en réseau pour réduire les risques et les problèmes de configuration. Les comportements de mise en réseau par défaut peuvent créer des risques ou des problèmes de configuration dans des environnements complexes ou renforcés en termes de sécurité. Google recommande les configurations suivantes :

  • Utiliser le DNS zonal : pour les nouveaux projets, définissez le système de noms de domaine (DNS) interne sur le DNS zonal uniquement. Cette approche permet de réduire l'impact d'une éventuelle indisponibilité mondiale du DNS. Pour en savoir plus sur l'utilisation du DNS zonal, consultez la présentation de l'utilisation du DNS zonal.
  • Désactiver les adresses IP externes : si possible, désactivez les adresses IP externes. Avant de désactiver les adresses IP, vous devez planifier et tester soigneusement dans un environnement de préproduction, car certains services tels que les groupes d'instances gérés (MIG) ou les clusters GKE avec des nœuds publics en dépendent. Pour en savoir plus sur la limitation des adresses IP publiques, consultez la section Limiter les adresses IP publiques sur Google Cloud.

Optimiser la mise en réseau par infrastructure

Les bonnes pratiques de mise en réseau pour votre déploiement varient en fonction de l'infrastructure choisie : GPU générales ou GPU en cluster.

Bonnes pratiques concernant les GPU générales

Lorsque vous utilisez des GPU générales, suivez ces bonnes pratiques de mise en réseau :

  • Utiliser des stratégies de placement compactes : si vos instances de GPU générales ne signalent pas d'ID physicalHost, utilisez des stratégies de placement compactes pour identifier les regroupements d'instances et optimiser les performances de ces ressources. Pour en savoir plus, consultez la section Définir le placement des instances.
  • Utiliser la carte d'interface réseau virtuelle Google (gVNIC) pour la communication hôte : pour des performances cohérentes, utilisez le protocole TCP/IP standard sur gVNIC pour toutes les communications hôte à hôte. Pour en savoir plus sur gVNIC, consultez la section Utiliser la carte d'interface réseau virtuelle Google.
  • Simplifier avec une architecture à VPC unique : sauf si des exigences d'isolation en disposent autrement, utilisez un réseau VPC unique standard pour toutes les communications. Cette recommandation de VPC unique s'applique aux séries G2, G4, A2 et N1. A3 Edge est une exception qui nécessite quatre VPC de données et GPUDirect-TCPX. Pour en savoir plus, consultez la section Maximiser la bande passante réseau des GPU dans les clusters en mode standard.

Bonnes pratiques concernant les GPU en cluster

Lorsque vous utilisez des GPU en cluster, suivez ces bonnes pratiques de mise en réseau :

  • Implémenter un environnement multi-VPC : pour vous assurer que le trafic GPU à GPU est isolé sur des VPC dédiés à bande passante élevée afin d' empêcher le trafic hôte ou de stockage de concurrencer la bande passante. Pour en savoir plus, consultez la section Environnement multi-VPC environment.
  • Appliquer des profils réseau optimisés pour RDMA : utilisez des profils réseau gérés par Google pour configurer automatiquement votre VPC pour la faible latence requise par RDMA over Converged Ethernet (RoCE). Pour en savoir plus, consultez la section Profils réseau pour des cas d'utilisation spécifiques.
  • Décharger les tâches d'infrastructure : utilisez des cartes d'interface réseau Titanium personnalisées pour décharger des tâches telles que le traitement des paquets réseau et la virtualisation pour le stockage, en réservant des cycles de processeur pour votre application d'IA.

Récapitulatif des bonnes pratiques

Le tableau suivant récapitule les bonnes pratiques recommandées dans ce document :

Sujet Tâche
IAM Définir des rôles IAM clairs et limités
Pare-feu Restreindre l'accès au réseau public et renforcer les configurations de pare-feu
Paramètres réseau par défaut Standardiser les paramètres internes par défaut de mise en réseau
Infrastructure Optimiser la mise en réseau par infrastructure

Étape suivante