Cette page décrit les modèles d'architecture pour les charges de travail d'automatisation de la conception électronique (EDA) sur Google Cloud NetApp Volumes.
NetApp Volumes fournit un stockage partagé NFS hautement évolutif pour prendre en charge les charges de travail EDA. Ces charges de travail traitent des ensembles de données à l'échelle du pétaoctet comprenant des millions de petits fichiers, exécutent des opérations de répertoire à forte intensité de métadonnées et génèrent des E/S parallèles par rafales sur des milliers de cœurs de calcul. NetApp Volumes permet de conserver l'accessibilité des bibliothèques de conception, des chaînes d'outils et des données de travail en passant de volumes de la taille d'un projet à des volumes de grande capacité, avec FlexCache en option pour les conceptions hybrides et à distribution ramifiée. Les modèles suivants associent les modèles de déploiement EDA courants à ces fonctionnalités.
Pour obtenir des implémentations de référence GitHub, telles que eda-all-on-cloud et
eda-hybrid-cloud, consultez Exemples EDA de Cluster Toolkit.
Schémas d'architecture
Le tableau suivant récapitule les modèles courants pour les charges de travail EDA. Le meilleur modèle pour votre cas d'utilisation dépend de l'emplacement de vos données principales et de la manière dont vous souhaitez faire évoluer les performances de lecture et le calcul.
| Modèle | Cas d'utilisation | Principales fonctionnalités de NetApp Volumes |
|---|---|---|
| Volumes de grande capacité pour les clusters de calcul | Les données de conception et les chaînes d'outils résident dans Google Cloud et nécessitent un espace de noms partagé unique à grande échelle | Pools et volumes de grande capacité, mise en page multivoies et cycle de vie du groupe de déploiement |
| Rafale vers le cloud | Les ensembles de données principaux résident sur site ou dans une autre région, et vous avez besoin de calcul cloud pour répondre aux pics de demande | FlexCache à partir d'une origine ONTAP sur site, préremplissage et volumes préexistants |
| Mise à l'échelle des performances via des caches de distribution ramifiée | Les phases à forte intensité de lecture nécessitent un débit agrégé ou une localité supérieurs à ce qu'une seule exportation peut fournir | Plusieurs volumes FlexCache ou plusieurs points de terminaison de stockage par volume important |
Utiliser des volumes de grande capacité comme stockage de fichiers pour les clusters de calcul
Utilisez ce modèle lorsque le calcul et les données persistantes s'exécutent dans Google Cloud, par exemple, des fermes EDA "greenfield", des centres de conception migrés ou des partitions de rafale cloud dédiées qui possèdent leurs ensembles de données.
Défis résolus par les volumes de grande capacité
Les volumes de grande capacité répondent aux exigences élevées en termes de capacité, de performances et de simultanéité des charges de travail EDA à grande échelle. Cette configuration résout les problèmes suivants :
Contraintes de capacité : prend en charge les grands ensembles de travail, tels que les bibliothèques, les blocs IP et les données de travail de régression.
Charge élevée de métadonnées et d'E/S : gère les chemins de métadonnées intensifs (y compris les opérations
readdiretstat), les petites E/S aléatoires et la bande passante séquentielle élevée.
Mise en page recommandée
Au lieu de placer toutes vos données dans un seul volume important, partitionnez-les sur plusieurs volumes en fonction de leur cycle de vie et de leurs modèles d'accès.
Le tableau suivant décrit la mise en page recommandée pour partitionner vos données :
| Rôle du volume | Types de données courants | Modèles d'accès et cycle de vie |
|---|---|---|
| Outils | Binaires de fournisseurs et installations EDA sous licence | Principalement en lecture, longue conservation et exportations stables |
| Bibliothèques | Kits de développement de processus, cellules standard et conceptions de référence | Principalement en lecture, grand nombre de fichiers et avantages de l'optimisation du cache d'attributs sur les clients |
| Accueil | Fichiers de configuration utilisateur et état de projet de petite taille | Lecture/écriture mixte et taux de métadonnées modérés |
| De travail | Répertoires d'exécution et résultats intermédiaires | Taux de renouvellement élevé, capacité maximale et demande d'IOPS la plus élevée |
Le plan Cluster Toolkit eda-all-on-cloud provisionne cette mise en page avec des partitions Compute Engine gérées par Slurm qui installent NetApp Volumes via NFS.
Quand utiliser des volumes de grande capacité
Pour les volumes de plus de 4,8 Tio (Flex Unified) ou 15 Tio (Premium et Extreme), créez des volumes de grande capacité. Ces volumes peuvent atteindre une très grande capacité et offrent des plafonds de débit et d'IOPS plus élevés. Les volumes de travail et de bibliothèque qui dépassent les limites à point de terminaison unique conviennent à cette configuration.
Distribution des clients sur des volumes importants
Un volume de grande capacité expose plusieurs points de terminaison de stockage (adresses IP) à la même exportation. Distribuez les clients NFS sur plusieurs points de terminaison pour faire évoluer le débit agrégé et éviter qu'une seule adresse IP ne devienne un goulot d'étranglement. Vous pouvez utiliser l'une des options suivantes :
DNS en mode "tourniquet" (recommandé à grande échelle) : créez un enregistrement A Cloud DNS répertoriant plusieurs adresses IP. Installez-le à l'aide du nom de domaine complet afin que chaque client soit résolu en une seule adresse au moment de l'installation. Réinstallez-le si vous modifiez les enregistrements DNS.
Partitionnement statique : divisez les clients en plusieurs groupes et installez chaque groupe sur un point de terminaison choisi pour un placement de charge déterministe.
Dans une architecture entièrement dans le cloud, vous provisionnez des exportations NetApp Volumes distinctes dans une seule Google Cloud région pour les outils,
les bibliothèques et le travail. Les outils et les bibliothèques contiennent des données de référence principalement en lecture ; le travail contient des répertoires d'exécution et des points de contrôle, et constitue souvent un volume de grande capacité. Les nœuds Compute Engine gérés par Slurm dans le même VPC installent chaque exportation à l'aide de NFS. Le stockage est déployé dans un groupe de déploiement base et le calcul dans un groupe cluster pour vous permettre de faire évoluer ou de supprimer le cluster sans supprimer les volumes.
Rafale vers le cloud
Utilisez ce modèle lorsque les données de conception faisant autorité restent sur site ou dans un système ONTAP distant, et que vous souhaitez exécuter des tâches de régression, de caractérisation ou de capacité maximale sur Google Cloud le calcul sans copier d'abord des bibliothèques entières.
Résoudre les problèmes de stockage cloud hybride avec FlexCache
Les volumes FlexCache résolvent les problèmes courants de stockage cloud hybride pour les environnements EDA en offrant les avantages suivants :
Performances d'accès de type LAN : la latence et la bande passante du WAN limitent la vitesse à laquelle les cœurs de calcul cloud peuvent lire les ensembles de données sur site. FlexCache gère les phases à forte intensité de lecture et les opérations de métadonnées en local une fois les ensembles de travail mis en cache pour contrer ce problème.
Mise en cache au niveau du bloc à la demande : la copie de bibliothèques complètes dans le cloud avant chaque tâche introduit des délais de démarrage et duplique le stockage. FlexCache ne met en cache que les blocs de données auxquels il accède, ce qui minimise les temps de démarrage et réduit l'utilisation globale du stockage cloud.
Source d'origine cohérente : au lieu de gérer des copies déconnectées de vos données, vous pouvez utiliser une exportation NFS locale dans le cloud tout en conservant une seule copie cohérente dans le volume d'origine sur site.
Comportement et caractéristiques de FlexCache
Vous créez un volume FlexCache dans NetApp Volumes qui pointe vers un volume d'origine ONTAP existant. Les lectures des données mises en cache sont gérées par Google Cloud. Les lectures à froid récupèrent les blocs du volume d'origine ONTAP une seule fois, puis les diffusent en local. Par défaut, les opérations d'écriture utilisent une écriture différée: le cache transfère les opérations d'écriture à l'origine et invalide les données mises en cache affectées, ce qui préserve la cohérence entre les caches.
Voici les principales caractéristiques de FlexCache pour les environnements EDA :
Mise en cache au niveau du bloc, en mode "pull" uniquement : seules les données auxquelles il accède consomment de la capacité de cache. Les volumes épars sont efficaces pour les grandes bibliothèques auxquelles il accède partiellement par exécution.
Lectures cohérentes et actuelles : les données lues à partir du cache ou de l'origine sont cohérentes. Cette approche convient aux bibliothèques de référence partagées lorsque les modèles d'écriture correspondent aux conseils de FlexCache.
Latence de lecture de type LAN après l'échauffement : les phases de lecture à forte intensité de métadonnées et de débit, telles que la traversée de bibliothèques et les fichiers de référence répétés, sont avantageuses une fois les ensembles de travail mis en cache.
Préremplissage : pour éviter une pénalité de lecture à froid lors du premier accès, préremplissez les répertoires pour les listes d'exécution connues avant de démarrer une tâche.
Plan de référence hybride
eda-hybrid-cloud
installe des volumes préexistants, tels que des outils, des bibliothèques, des répertoires personnels et des répertoires de travail, à l'aide de
pre-existing-network-storage. Les volumes peuvent être des exportations NetApp Volumes standards, des volumes de grande capacité ou des volumes FlexCache. Le provisionnement du stockage en dehors du plan de cluster évite toute suppression accidentelle lorsque vous supprimez le calcul et prend en charge les origines FlexCache que vous gérez dans ONTAP.
Tenez compte des consignes opérationnelles suivantes :
Dimensionnez les volumes de cache pour l'ensemble de travail, et non pour la capacité totale du volume d'origine.
Désactivez ou limitez les mises à jour de l'heure d'accès sur le volume d'origine (
-atime-updatedans ONTAP) pour éviter toute invalidation inutile du cache. Pour en savoir plus, consultez la présentation de FlexCache.N'activez le verrouillage global des fichiers que si votre flux nécessite une sémantique stricte de refus de lecture entre les caches. Cette approche ajoute de la latence et associe la disponibilité au lien d'origine.
Planifiez la connectivité réseau et la bande passante entre l'origine et Google Cloud. Les phases à forte intensité d'écriture restent liées à l'origine ou à la liaison réseau lorsque vous utilisez l'écriture différée.
Dans l'architecture hybride de rafale de lecture, les outils faisant autorité et les données de bibliothèque résident sur un système ONTAP sur site. NetApp Volumes héberge des volumes FlexCache dans Google Cloud qui référencent ces origines à l'aide d'un WAN ou d'une liaison privée. Les nœuds Slurm dans Google Cloud installent les exportations FlexCache. Les lectures sont gérées à partir du cache lorsque les données sont "chaudes" ; les lectures à froid récupèrent les blocs de l'origine sur site. Pour les travaux et les points de contrôle qui reçoivent un trafic d'écriture important du calcul cloud, créez un volume de travail cloud natif distinct dans la même région que le cluster pour conserver les écritures en local, au lieu de router un trafic d'écriture soutenu via un FlexCache avec une origine sur site.
Scaling des performances via des caches de distribution ramifiée
Utilisez ce modèle lorsqu'une seule exportation, même un volume de grande capacité, ne fournit pas un débit de lecture agrégé ou une distribution ramifiée client suffisante pour une phase du flux.
Vous pouvez implémenter la distribution ramifiée de deux manières :
Volumes FlexCache de type "fan-out"
Créez plusieurs volumes FlexCache soutenus par le même volume d'origine, et installez différents pools de calcul (ou types de tâches) sur différents caches. Chaque cache s'échauffe indépendamment, fait évoluer les E/S de lecture sur des points de terminaison NetApp Volumes distincts et isole les conflits entre les charges de travail, par exemple, le prétraitement de la bibliothèque par rapport à une longue régression.
Le tableau suivant compare les approches de déploiement FlexCache uniques et multiples.
| Méthode | Balances | Compromis |
|---|---|---|
| FlexCache unique | Simplicité, un seul chemin d'installation | Une seule capacité de cache et un seul plafond de débit |
| Plusieurs FlexCache (type "fan-out") | Débit de lecture mis en cache agrégé ; isolation par pool | Plus de volumes à gérer ; ensemble de travail divisé entre les caches |
| Origine uniquement (sans cache) | Cohérence d'écriture la plus forte sur un seul site | Latence du WAN pour le calcul cloud |
Si vous connaissez vos entrées de tâche à l'avance, utilisez le préremplissage sur chaque cache de distribution ramifiée.
Distribution ramifiée sur des volumes de grande capacité avec plusieurs points de terminaison
Les volumes de grande capacité et les volumes FlexCache à grande échelle exposent plusieurs adresses IP par volume. Traitez chaque adresse IP comme un point de terminaison de stockage avec son propre budget de slots de connexion.
Si vous avez des centaines ou des milliers de clients NFS, tenez compte des points suivants :
Entrées de table de slots RPC par client inférieures : par exemple, huit slots par client sur NFSv3, afin que le nombre total d’opérations en attente par point de terminaison reste dans les limites recommandées (environ 10 000 slots par point de terminaison dans la ferme). Pour en savoir plus, consultez la section Simultanéité NFS Linux.
Répartissez les installations sur les points de terminaison : utilisez le DNS en mode "tourniquet" ou le partitionnement statique de Cloud DNS.
Pour implémenter la distribution ramifiée de FlexCache, utilisez un volume d'origine (ONTAP sur site ou un volume en mode ONTAP cloud) pour soutenir plusieurs volumes FlexCache dans NetApp Volumes. Installez chaque cache à l'aide de différents consommateurs, tels qu'une partition Slurm ou une classe de tâches, pour isoler les ensembles de travail et les charges de lecture entre les exportations.
Pour implémenter la distribution ramifiée à plusieurs points de terminaison, utilisez un volume de grande capacité qui expose la même exportation NFS sur plusieurs adresses IP. Répartissez les clients sur ces points de terminaison en attribuant des groupes de clients fixes à chaque adresse IP ou en installant un nom DNS qui se résout en une seule adresse par installation. Chaque point de terminaison dispose de son propre budget de connexion ; la distribution des clients permet d'éviter de concentrer les E/S à l'échelle de la ferme sur une seule adresse IP.
Combiner les modèles
Pour les environnements EDA de production, vous pouvez combiner ces modèles d'architecture afin d'optimiser les performances :
Entièrement dans le cloud : utilisez des volumes de travail de grande capacité, ainsi que des volumes standards plus petits pour les outils et les répertoires personnels.
Hybride : utilisez FlexCache pour les bibliothèques et les outils, avec un volume de travail provisionné dans le cloud pour la sortie des tâches.
Type "fan-out" : utilisez FlexCache par site ou par file d'attente de planificateur, ainsi que le DNS à plusieurs points de terminaison pour un grand volume de travail cloud natif.
Faites correspondre le niveau de service du volume et le type de pool (Flex Unified standard ou de grande capacité) aux besoins de chaque niveau en termes de capacité et de performances. Pour en savoir plus, consultez la section Niveaux de service.