Questa pagina descrive i pattern architetturali per i carichi di lavoro di automazione della progettazione elettronica (EDA) su Google Cloud NetApp Volumes.
NetApp Volumes fornisce uno spazio di archiviazione condiviso NFS altamente scalabile per supportare i carichi di lavoro EDA. Questi carichi di lavoro elaborano set di dati su scala di petabyte che comprendono milioni di file di piccole dimensioni, eseguono operazioni di directory con molti metadati e generano I/O paralleli con burst su migliaia di core di computing. NetApp Volumes mantiene accessibili le librerie di progettazione, le toolchain e i dati temporanei scalando i volumi dalle dimensioni del progetto a volumi di grande capacità, con FlexCache facoltativo per progetti ibridi e di fan-out. I seguenti pattern mappano i modelli di deployment EDA comuni a queste funzionalità.
Per le implementazioni di riferimento di GitHub, come eda-all-on-cloud e
eda-hybrid-cloud, consulta Esempi di EDA di Cluster Toolkit.
Pattern architetturali
La tabella seguente riassume i pattern comuni per i carichi di lavoro EDA. Il pattern migliore per il tuo caso d'uso dipende da dove risiedono i dati principali e da come vuoi scalare le prestazioni di lettura e il computing.
| Pattern | Caso d'uso | Funzionalità principali di NetApp Volumes |
|---|---|---|
| Volumi di grande capacità per i cluster di computing | I dati di progettazione e le toolchain risiedono in Google Cloud e richiedono un singolo spazio dei nomi condiviso su larga scala | Pool e volumi di grande capacità, layout multi-volume e ciclo di vita del gruppo di deployment |
| Burst nel cloud | I set di dati principali risiedono on-premise o in un'altra regione e hai bisogno di computing cloud per la domanda di picco | FlexCache dall'origine ONTAP on-premise, precompilazione e volumi preesistenti |
| Scalabilità delle prestazioni tramite cache di fan-out | Le fasi a lettura intensiva richiedono un throughput aggregato o una località maggiore di quella che può fornire una singola esportazione | Più volumi FlexCache o più endpoint di archiviazione per volume di grandi dimensioni |
Utilizzare volumi di grande capacità come spazio di archiviazione di file per i cluster di computing
Utilizza questo pattern quando il computing e i dati persistenti vengono eseguiti in Google Cloud, per esempio, in farm EDA greenfield, centri di progettazione migrati o partizioni di burst cloud dedicate che possiedono i propri set di dati.
Sfide risolte dai volumi di grande capacità
I volumi di grande capacità soddisfano i requisiti di capacità, prestazioni e concorrenza elevati dei carichi di lavoro EDA su larga scala. Questa configurazione risolve le seguenti sfide:
Vincoli di capacità: ospita set di lavoro di grandi dimensioni, come librerie, blocchi IP e dati temporanei di regressione.
Carico elevato di metadati e I/O: gestisce percorsi di metadati intensivi (incluse le operazioni
readdirestat), I/O casuali di piccole dimensioni e larghezza di banda sequenziale elevata.
Layout consigliato
Anziché inserire tutti i dati in un unico volume di grandi dimensioni, partiziona i dati su più volumi in base al ciclo di vita e ai pattern di accesso.
La tabella seguente descrive il layout consigliato per il partizionamento dei dati:
| Ruolo del volume | Tipi di dati comuni | Pattern di accesso e ciclo di vita |
|---|---|---|
| Strumenti | File binari dei fornitori e installazioni EDA con licenza | Esportazioni stabili, con conservazione a lungo termine e per lo più in lettura |
| Librerie | PDK, celle standard e progetti di riferimento | Per lo più in lettura, numero elevato di file e vantaggi dalla regolazione della cache degli attributi sui client |
| Home | File di configurazione dell'utente e stato del progetto di piccole dimensioni | Tassi di metadati moderati e di lettura/scrittura misti |
| Temporaneo | Directory di esecuzione e risultati intermedi | Churn elevato, capacità massima e domanda di IOPS più elevata |
Il progetto iniziale di Cluster Toolkit eda-all-on-cloud esegue il provisioning di questo layout con le partizioni di Compute Engine gestite da Slurm che montano NetApp Volumes su NFS.
Quando utilizzare i volumi di grande capacità
Per i volumi di dimensioni superiori a 4,8 TiB (Flex Unified) o 15 TiB (Premium ed Extreme), crea volumi di grande capacità. Questi volumi scalano fino a una capacità molto elevata e forniscono limiti di throughput e IOPS più elevati. I volumi temporanei e delle librerie che superano i limiti di un singolo endpoint sono adatti a questa configurazione.
Distribuzione dei client su volumi di grandi dimensioni
Un volume di grande capacità espone più endpoint di archiviazione (indirizzi IP) alla stessa esportazione. Distribuisci i client NFS su più endpoint per scalare il throughput aggregato ed evitare che un singolo indirizzo IP diventi un collo di bottiglia. Puoi utilizzare una delle seguenti opzioni:
DNS round-robin (consigliato su larga scala): crea un record A di Cloud DNS che elenca più indirizzi IP. Esegui il montaggio utilizzando l'FQDN in modo che ogni client risolva un indirizzo al momento del montaggio. Rimonta se modifichi i record DNS.
Sharding statico: dividi i client in più gruppi e monta ogni gruppo su un endpoint scelto per il posizionamento deterministico del carico.
In un'architettura completamente nel cloud, esegui il provisioning di esportazioni
NetApp Volumes separate in una Google Cloud regione per strumenti,
librerie e dati temporanei. Gli strumenti e le librerie contengono dati di riferimento per lo più in lettura; i dati temporanei contengono directory di esecuzione e checkpoint e spesso sono un volume di grande capacità. I nodi di Compute Engine gestiti da Slurm nello stesso VPC montano ogni esportazione utilizzando NFS. Lo spazio di archiviazione viene eseguito il deployment in un gruppo di deployment base e il computing in un gruppo cluster per consentirti di scalare o eliminare il cluster senza eliminare i volumi.
Burst nel cloud
Utilizza questo pattern quando i dati di progettazione autorevoli rimangono on-premise o in un sistema ONTAP remoto e vuoi eseguire job di regressione, caratterizzazione o capacità di picco su Google Cloud Compute senza copiare prima intere librerie.
Risolvere le sfide di spazio di archiviazione sul cloud ibrida con FlexCache
I volumi FlexCache risolvono le sfide comuni di spazio di archiviazione sul cloud ibrida per gli ambienti EDA fornendo i seguenti vantaggi:
Prestazioni di accesso simili a quelle della LAN: la latenza e la larghezza di banda della WAN limitano la velocità con cui i core di computing cloud possono leggere i set di dati on-premise. FlexCache gestisce le fasi a lettura intensiva e le operazioni sui metadati localmente dopo che i set di lavoro sono stati memorizzati nella cache per contrastare questo problema.
Caching a livello di blocco on demand: la copia di librerie complete nel cloud prima di ogni job introduce ritardi di avvio e duplica lo spazio di archiviazione. FlexCache memorizza nella cache solo i blocchi di dati a cui si accede, il che riduce al minimo i tempi di avvio e l'utilizzo complessivo dello spazio di spazio di archiviazione sul cloud.
Origine di origine coesa: anziché gestire copie disconnesse dei dati, puoi utilizzare un'esportazione NFS locale nel cloud e mantenere comunque una singola, copia coerente nel volume di origine on-premise.
Comportamento e caratteristiche di FlexCache
Si crea un volume FlexCache in NetApp Volumes che punta a un volume di origine ONTAP esistente. Le letture dei dati memorizzati nella cache vengono gestite da Google Cloud. Le letture a freddo recuperano i blocchi dal volume di origine ONTAP una volta e poi li gestiscono localmente. Per impostazione predefinita, le operazioni di scrittura utilizzano una scrittura di tipo write-around: la cache inoltra le operazioni di scrittura all'origine e invalida i dati memorizzati nella cache interessati, il che mantiene la coerenza tra le cache.
Di seguito sono riportate le caratteristiche principali di FlexCache per gli ambienti EDA:
Caching a livello di blocco, solo pull: solo i dati a cui si accede consumano la capacità della cache. I volumi sparsi sono efficienti per le librerie di grandi dimensioni a cui si accede parzialmente per esecuzione.
Letture coerenti e aggiornate: i dati letti dalla cache o dall'origine sono coerenti. Questo approccio è adatto per le librerie di riferimento condivise quando i pattern di scrittura corrispondono alle indicazioni di FlexCache.
Latenza di lettura simile a quella della LAN dopo il riscaldamento: le fasi di lettura con molti metadati e throughput elevato, come l'attraversamento della libreria e i file di riferimento ripetuti, traggono vantaggio una volta che i set di lavoro sono memorizzati nella cache.
Precompilazione: per evitare una penalità di lettura a freddo al primo accesso, precompila le directory per gli elenchi di esecuzione noti prima di avviare un job.
Progetto iniziale di riferimento ibrido
eda-hybrid-cloud
monta i volumi preesistenti, come strumenti, librerie, home e dati temporanei, utilizzando
pre-existing-network-storage. I volumi possono essere esportazioni NetApp Volumes standard, volumi di grande capacità o volumi FlexCache. Il provisioning dello spazio di archiviazione al di fuori del blueprint del cluster evita l'eliminazione accidentale quando si smonta il calcolo e supporta le origini FlexCache gestite in ONTAP.
Tieni presente le seguenti linee guida operative:
Dimensiona i volumi della cache per il set di lavoro, non per la capacità completa del volume di origine.
Disattiva o limita gli aggiornamenti del tempo di accesso sul volume di origine (
-atime-updatein ONTAP) per evitare l'invalidazione non necessaria della cache. Per saperne di più, consulta la panoramica di FlexCache.Attiva il blocco dei file globali solo se il flusso richiede una semantica di negazione della lettura tra le cache rigorosa. Questo approccio aggiunge latenza e accoppia la disponibilità al link di origine.
Pianifica la connettività di rete e la larghezza di banda tra l'origine e Google Cloud. Le fasi a scrittura intensiva rimangono vincolate all'origine o al link di rete quando utilizzi la scrittura di tipo write-around.
Nell'architettura di burst di lettura ibrida, gli strumenti autorevoli e i dati della libreria risiedono in un sistema ONTAP on-premise. NetApp Volumes ospita i volumi FlexCache in Google Cloud che fanno riferimento a queste origini utilizzando una WAN o un link privato. I nodi Slurm in Google Cloud montano le esportazioni FlexCache. Le letture vengono gestite dalla cache quando i dati sono attivi; le letture a freddo recuperano i blocchi dall'origine on-premise. Per i dati temporanei e i checkpoint che ricevono un traffico di scrittura elevato dal computing cloud, crea un volume temporaneo nativo del cloud separato nella stessa regione del cluster per mantenere le scritture locali, anziché instradare il traffico di scrittura sostenuto tramite un FlexCache con un'origine on-premise.
Scalabilità delle prestazioni tramite cache di fan-out
Utilizza questo pattern quando una singola esportazione, anche un volume di grande capacità, non fornisce un throughput di lettura aggregato o un fan-out client sufficiente per una fase del flusso.
Puoi implementare il fan-out in due modi:
Volumi FlexCache di fan-out
Crea più volumi FlexCache supportati dallo stesso volume di origine e monta pool di computing (o tipi di job) diversi su cache diverse. Ogni cache si attiva in modo indipendente, scala l'I/O di lettura su endpoint NetApp Volumes separati e isola il thrashing tra i carichi di lavoro, ad esempio la pre-elaborazione della libreria rispetto alla regressione lunga.
La tabella seguente confronta gli approcci di deployment di FlexCache singolo e multiplo.
| Approccio | Scala | Compromesso |
|---|---|---|
| FlexCache singolo | Semplicità, un percorso di montaggio | Un limite di capacità e throughput della cache |
| Più FlexCache (fan-out) | Throughput di lettura memorizzato nella cache aggregato; isolamento per pool | Più volumi da gestire; set di lavoro suddiviso tra le cache |
| Solo origine (nessuna cache) | Coerenza di scrittura più elevata per un singolo sito | Latenza WAN per il computing cloud |
Se conosci in anticipo gli input del job, utilizza la precompilazione su ogni cache di fan-out.
Fan-out su volumi di grande capacità con più endpoint
I volumi di grande capacità e i volumi FlexCache su larga scala espongono più indirizzi IP per volume. Considera ogni IP come un endpoint di archiviazione con il proprio budget di slot di connessione.
Se hai centinaia o migliaia di client NFS, tieni presente quanto segue:
Voci della tabella degli slot RPC per client inferiori: ad esempio, 8 slot per client su NFSv3, in modo che le operazioni in sospeso totali per endpoint rimangano entro i limiti consigliati (circa 10.000 slot per endpoint nella farm). Per saperne di più, consulta Concorrenza NFS Linux.
Distribuisci i montaggi tra gli endpoint: utilizza il round-robin di Cloud DNS o lo sharding statico.
Per implementare il fan-out di FlexCache, utilizza un volume di origine (ONTAP on-premise o un volume in modalità ONTAP cloud) per supportare più volumi FlexCache in NetApp Volumes. Monta ogni cache utilizzando consumatori diversi, ad esempio una partizione Slurm o una classe di job, per isolare i set di lavoro e i carichi di lettura tra le esportazioni.
Per implementare il fan-out di più endpoint, utilizza un volume di grande capacità che espone la stessa esportazione NFS su più indirizzi IP. Distribuisci i client tra questi endpoint assegnando gruppi di client fissi a ogni indirizzo IP o montando un nome DNS che si risolve in un indirizzo per montaggio. Ogni endpoint ha il proprio budget di connessione; la distribuzione dei client aiuta a evitare di concentrare l'I/O a livello di farm su un singolo indirizzo IP.
Combinare i pattern
Per gli ambienti EDA di produzione, puoi combinare questi pattern architetturali per ottimizzare le prestazioni:
Completamente nel cloud: utilizza volumi temporanei di grande capacità e volumi standard più piccoli per strumenti e home.
Ibrido: utilizza FlexCache per librerie e strumenti, con un volume temporaneo con provisioning cloud per l'output del job.
Fan-out: utilizza FlexCache per sito o per coda dello scheduler, oltre a DNS multi-endpoint per un volume temporaneo di grandi dimensioni nativo del cloud.
Abbina il livello di servizio del volume e il tipo di pool (Flex Unified normale rispetto a grande capacità) alle esigenze di capacità e prestazioni di ogni livello. Per saperne di più, consulta Livelli di servizio.