Architecture de déploiement GCP

Attention : Vous ne pouvez actuellement utiliser le modèle de déploiement GCP qu'avec Automation Suite 2024.10. Nous vous recommandons donc de vous référer à la Documentation d'Automation Suite 2024.10.

Cette page offre un aperçu de l'architecture de déploiement sur GCP, les composants requis et toutes les limitations connues.

Schéma d'architecture

Composants

• Réseau virtuel
  • Un sous-réseau où résident tous les nœuds.
  • Une passerelle NAT pour la connectivité sortante (une ressource Cloud Nat attachée à un routeur cloud) ;
  • Règles de pare-feu pour sécuriser le trafic du sous-réseau.
• Une zone privée DNS nécessaire à l'installation. Pour plus de détails, consultez la section Limitations connues.
• 3 Groupes d'instances gérés. Vous pouvez choisir le type d'instance pour les nœuds de serveur et d'agent. Veillez à vérifier les exigences de la machine en mode de production multi-nœuds compatible haute disponibilité ainsi que les exigences de la machine en mode d'évaluation à nœud unique afin de répondre à la configuration matérielle requise. Chaque machine virtuelle dispose d'un système d'exploitation de 128 Go et de fichiers binaires de cluster de 256 Go et d'un disque d'état. Les nœuds de serveur disposent d'un disque de données supplémentaire de 512 Go/2048 Go, selon que les produits AI sont installés ou non.
  • Nœuds de serveur (plan de contrôle du cluster). Les nœuds de serveur exécutent également des charges de travail.
  • Nœuds d'agent. Conçus pour exécuter uniquement des charges de travail (ils n'ont pas de services de plan de contrôle). Si le nombre de nœuds d'agent souhaités est de 0, un groupe d'instances géré vide est créé.
  • Nœuds GPU. Nœuds utilisés spécifiquement pour les modèles ML dotés de cartes vidéo. Si le nombre de nœuds GPU souhaités est de 0, aucun groupe d'instances gérées n'est créé.
• Équilibreur de charge public utilisé pour équilibrer le trafic HTTPS depuis le port 443 vers les nœuds.
• 2 équilibreurs de charge internes et 1 groupe d'instances géré nécessaires pour transférer les demandes d'enregistrement de nœud. Les MV ont la plus petite taille d'instance possible.
• Nœud Task Mining déployé en tant que machine virtuelle distincte. Son type d'instance est n2-standard-32.
• Instance de bastion utilisée pour accéder aux autres nœuds. Elle possède une adresse IP publique et SSH activé.
• Instance de base de données SQL :
  • 8 cœurs et 32 Go de RAM
  • Taille de disque de 1 000 Go pouvant être étendue manuellement
  • Les bases de données sont créées par l'installateur
• Gestionnaire de clés secrètes utilisé pour stocker les informations d'identification générées automatiquement pour le serveur SQL, la plate-forme Automation Suite et la console ArgoCD.

Limites connues

Dns

• En raison du fait qu'un DNS ne peut pas être automatiquement attaché au LB :
  • Les étapes de configuration du DNS ne peuvent être effectuées qu'après l'installation, alors qu'elles sont nécessaires lors de l'installation. La zone DNS privée résout ce problème et peut être supprimée en toute sécurité une fois l'installation terminée. Alternativement, à des fins de test, vérifiez l'Étape 4 : Configuration du DNS.
  • Les serveurs DNS principaux en amont doivent être forcés à correspondre aux serveurs de noms du nœud. Cela pourrait entraîner la corruption du fichier de configuration rke ( /etc/rancher/rke2/config.yaml) au redémarrage de la machine virtuelle, ce qui peut avoir un impact sur le processus de mise à niveau post-installation.

RHEL

• Google peut mettre à jour la version RHEL sans préavis, laissant ainsi les déploiements d'Automation Suite en dehors du support. Actuellement, les déploiements manuels à l'aide d'images RHEL personnalisées sont le seul moyen d'obtenir et de rester en support.