Esta página descreve padrões arquitetônicos para cargas de trabalho de automação de projetos eletrônicos (EDA, na sigla em inglês) no Google Cloud NetApp Volumes.
O NetApp Volumes oferece armazenamento compartilhado NFS altamente escalonável para oferecer suporte a cargas de trabalho de EDA. Essas cargas de trabalho processam conjuntos de dados de petabytes que compreendem milhões de arquivos pequenos, executam operações de diretório com muitos metadados e impulsionam E/S paralela em milhares de núcleos de computação. O NetApp Volumes mantém bibliotecas de design, conjuntos de ferramentas e dados temporários acessíveis, escalonando de volumes de tamanho de projeto a volumes de grande capacidade, com FlexCache opcional para designs híbridos e distribuição de dados. Os padrões a seguir mapeiam modelos comuns de implantação de EDA para esses recursos.
Para implementações de referência do GitHub, como eda-all-on-cloud e
eda-hybrid-cloud, consulte os exemplos de EDA do Cluster Toolkit.
Padrões arquitetônicos
A tabela a seguir resume os padrões comuns para cargas de trabalho de EDA. O melhor padrão para seu caso de uso depende de onde seus dados principais residem e de como você quer escalonar o desempenho de leitura e a computação.
| Estampa | Caso de uso | Principais recursos do NetApp Volumes |
|---|---|---|
| Volumes de grande capacidade para clusters de computação | Os dados de design e as toolchains residem em Google Cloud e exigem um único namespace compartilhado em escala | Pools e volumes de grande capacidade, layout de vários volumes e ciclo de vida do grupo de implantação |
| Burst para a nuvem | Os conjuntos de dados principais residem no local ou em outra região, e você precisa de computação em nuvem para atender à demanda máxima | FlexCache da origem ONTAP local, pré-população e volumes preexistentes |
| Escalonamento de desempenho por caches de distribuição de dados | As fases de leitura intensa exigem mais capacidade de processamento ou localidade agregada do que uma única exportação pode fornecer | Vários volumes do FlexCache ou vários endpoints de armazenamento por volume grande |
Usar volumes de grande capacidade como armazenamento de arquivos para clusters de computação
Use esse padrão quando os dados de computação e persistentes forem executados em Google Cloud, por exemplo, farms de EDA greenfield, centros de design migrados ou partições de burst de nuvem dedicadas que possuem seus conjuntos de dados.
Desafios resolvidos por volumes de grande capacidade
Volumes de grande capacidade atendem aos requisitos de alta capacidade, desempenho e simultaneidade de cargas de trabalho de EDA em grande escala. Essa configuração resolve os seguintes desafios:
Restrições de capacidade: acomoda grandes conjuntos de trabalho, como bibliotecas, blocos de IP e dados temporários de regressão.
Alta carga de metadados e E/S: processa caminhos de metadados intensivos (incluindo
readdirestatoperações), E/S aleatória pequena e alta largura de banda sequencial.
Layout recomendado
Em vez de colocar todos os dados em um único volume grande, particione os dados em vários volumes com base no ciclo de vida e nos padrões de acesso.
A tabela a seguir descreve o layout recomendado para particionar seus dados:
| Função do volume | Tipos de dados comuns | Padrões de acesso e ciclo de vida |
|---|---|---|
| Ferramentas | Binários de fornecedores e instalações de EDA licenciadas | Exportações estáveis, de retenção longa e de leitura |
| Bibliotecas | PDKs, células padrão e designs de referência | Leitura, grande número de arquivos e benefícios do ajuste do cache de atributos nos clientes |
| Página inicial | Arquivos de configuração do usuário e estado de projetos pequenos | Taxas de metadados mistas de leitura/gravação e moderadas |
| Rascunho | Diretórios de execução e resultados intermediários | Alta rotatividade, maior capacidade e maior demanda de IOPS |
O modelo do Cluster Toolkit eda-all-on-cloud provisiona esse layout com partições do Compute Engine gerenciadas pelo Slurm que ativam o NetApp Volumes pelo NFS.
Quando usar volumes de grande capacidade
Para volumes maiores que 4,8 TiB (Flex Unified) ou 15 TiB (Premium e Extreme), crie volumes de grande capacidade. Esses volumes são escalonados para uma capacidade muito grande e oferecem maior capacidade de processamento e limites máximos de IOPS. Volumes temporários e de biblioteca que excedem os limites de endpoint único são adequados para essa configuração.
Distribuição de clientes em volumes grandes
Um volume de grande capacidade expõe vários endpoints de armazenamento (endereços IP) à mesma exportação. Distribua clientes NFS em vários endpoints para escalonar a capacidade de processamento agregada e evitar que um único endereço IP se torne um gargalo. É possível usar uma das seguintes opções:
DNS round-robin (recomendado em escala): crie um registro A do Cloud DNS que liste vários endereços IP. Ative usando o FQDN para que cada cliente seja resolvido em um endereço no momento da ativação. Remonte se você mudar os registros DNS.
Fragmentação estática: divida os clientes em vários grupos e monte cada grupo em um endpoint escolhido para o posicionamento determinístico da carga.
Em uma arquitetura totalmente na nuvem, você provisiona exportações separadas
do NetApp Volumes em uma Google Cloud região para ferramentas,
bibliotecas e rascunho. As ferramentas e bibliotecas contêm dados de referência de leitura; o rascunho contém diretórios de execução e pontos de verificação e geralmente é um volume de grande capacidade. Os nós do Compute Engine gerenciados pelo Slurm na mesma VPC ativam cada exportação usando o NFS. O armazenamento é implantado em um grupo de implantação base e a computação em um grupo cluster para permitir que você escalone ou exclua o cluster sem excluir os volumes.
Burst para a nuvem
Use esse padrão quando os dados de design autoritativos permanecerem no local ou em um sistema ONTAP remoto e você quiser executar jobs de regressão, caracterização ou capacidade máxima em Google Cloud computação sem copiar bibliotecas inteiras primeiro.
Resolver desafios de armazenamento em nuvem híbrida com o FlexCache
Os volumes do FlexCache resolvem desafios comuns de armazenamento em nuvem híbrida para ambientes de EDA, oferecendo os seguintes benefícios:
Desempenho de acesso semelhante a LAN: a latência e a largura de banda da WAN limitam a velocidade com que os núcleos de computação em nuvem podem ler conjuntos de dados locais. O FlexCache atende fases de leitura intensa e operações de metadados localmente depois que os conjuntos de trabalho são armazenados em cache para resolver esse problema.
Armazenamento em cache de blocos sob demanda: copiar bibliotecas completas para a nuvem antes de cada job introduz atrasos na inicialização e duplica o armazenamento. O FlexCache armazena em cache apenas os blocos de dados acessados, o que minimiza os tempos de inicialização e reduz o uso geral do armazenamento em nuvem.
Fonte de origem coesa: em vez de gerenciar cópias desconectadas dos seus dados, você pode usar uma exportação NFS local na nuvem e ainda manter uma única cópia coerente no volume de origem local.
Comportamento e características do FlexCache
Você cria um volume do FlexCache no NetApp Volumes que aponta para um volume de origem ONTAP existente. As leituras de dados armazenados em cache são fornecidas por Google Cloud. As leituras frias recuperam blocos do volume de origem ONTAP uma vez e os fornecem localmente. Por padrão, as operações de gravação usam uma gravação indireta: o cache encaminha as operações de gravação para a origem e invalida os dados armazenados em cache afetados, o que preserva a coerência entre os caches.
A seguir estão as principais características do FlexCache para ambientes de EDA:
Armazenamento em cache somente pull no nível de bloco: apenas os dados acessados consomem capacidade de cache. Volumes esparsos são eficientes para bibliotecas grandes que são acessadas parcialmente por execução.
Leituras coerentes e atuais: os dados lidos do cache ou da origem são consistentes. Essa abordagem é adequada para bibliotecas de referência compartilhadas quando os padrões de gravação correspondem às orientações do FlexCache.
Latência de leitura semelhante a LAN após o aquecimento: fases de leitura com muitos metadados e capacidade de processamento, como a travessia de bibliotecas e arquivos de referência repetidos, se beneficiam quando os conjuntos de trabalho são armazenados em cache.
Pré-população: para evitar uma penalidade de leitura fria no primeiro acesso, pré-popule diretórios para listas de execução conhecidas antes de iniciar um job.
Modelo de referência híbrido
eda-hybrid-cloud
ativa volumes preexistentes, como ferramentas, bibliotecas, página inicial e rascunho, usando
pre-existing-network-storage. Os volumes podem ser exportações padrão do NetApp Volumes, volumes de grande capacidade ou volumes do FlexCache. O provisionamento de armazenamento fora do modelo de cluster evita a exclusão acidental ao desmontar a computação e oferece suporte a origens do FlexCache gerenciadas no ONTAP.
Considere as seguintes diretrizes operacionais:
Tamanho dos volumes de cache para o conjunto de trabalho, não a capacidade total do volume de origem.
Desative ou limite as atualizações de tempo de acesso no volume de origem (
-atime-updateno ONTAP) para evitar a invalidação desnecessária do cache. Para mais informações, consulte a visão geral do FlexCache.Ative o bloqueio de arquivos global somente se o fluxo exigir semântica de leitura negada entre caches. Essa abordagem adiciona latência e acopla a disponibilidade ao link de origem.
Planeje a conectividade de rede e a largura de banda entre a origem e Google Cloud. As fases de gravação intensa permanecem vinculadas à origem ou ao link de rede quando você usa a gravação indireta.
Na arquitetura de burst de leitura híbrida, as ferramentas autoritativas e os dados da biblioteca residem em um sistema ONTAP local. O NetApp Volumes hospeda volumes do FlexCache em Google Cloud que referenciam essas origens usando uma WAN ou link particular. Os nós do Slurm em Google Cloud ativam as exportações do FlexCache. As leituras são fornecidas do cache quando os dados estão ativos; as leituras frias recuperam blocos da origem local. Para rascunhos e pontos de verificação que recebem tráfego de gravação intenso da computação em nuvem, crie um volume de rascunho nativo da nuvem separado na mesma região do cluster para manter as gravações locais, em vez de rotear o tráfego de gravação sustentado por um FlexCache com uma origem local.
Escalonamento de desempenho por caches de distribuição de dados
Use esse padrão quando uma única exportação, mesmo um volume de grande capacidade, não fornecer capacidade de processamento de leitura agregada ou distribuição de clientes suficiente para uma fase do fluxo.
É possível implementar a distribuição de duas maneiras:
Volumes do FlexCache de distribuição de dados
Crie vários volumes do FlexCache com suporte do mesmo volume de origem e ative diferentes pools de computação (ou tipos de job) em caches diferentes. Cada cache é aquecido de forma independente, escalona a E/S de leitura em endpoints separados do NetApp Volumes e isola o thrash entre cargas de trabalho, por exemplo, pré-processamento de bibliotecas versus regressão longa.
A tabela a seguir compara abordagens de implantação única e múltipla do FlexCache.
| Abordagem | Escalona | Compensação |
|---|---|---|
| FlexCache único | Simplicidade, um caminho de ativação | Um limite máximo de capacidade e capacidade de processamento do cache |
| Vários FlexCaches (distribuição de dados) | Capacidade de processamento de leitura armazenada em cache agregada; isolamento por pool | Mais volumes para gerenciar; conjunto de trabalho dividido em caches |
| Somente origem (sem cache) | Coerência de gravação mais forte para um único site | Latência da WAN para computação em nuvem |
Se você souber as entradas do job com antecedência, use a pré-população em cada cache de distribuição de dados.
Distribuição de dados em volumes de grande capacidade com vários endpoints
Volumes de grande capacidade e volumes do FlexCache em escala expõem vários endereços IP por volume. Trate cada IP como um endpoint de armazenamento com seu próprio orçamento de slot de conexão.
Se você tiver centenas ou milhares de clientes NFS, considere o seguinte:
Entradas de tabela de slots RPC por cliente mais baixas: por exemplo, 8 slots por cliente no NFSv3, para que o total de operações pendentes por endpoint permaneça dentro dos limites recomendados (aproximadamente 10.000 slots por endpoint em todo o farm). Para mais informações, consulte Simultaneidade do NFS do Linux.
Espalhe as ativações entre os endpoints: use o round-robin do Cloud DNS ou a fragmentação estática.
Para implementar a distribuição de dados do FlexCache, use um volume de origem (ONTAP local ou um volume do modo ONTAP na nuvem) para fazer backup de vários volumes do FlexCache no NetApp Volumes. Ative cada cache usando diferentes consumidores, como uma partição do Slurm ou uma classe de job, para isolar conjuntos de trabalho e cargas de leitura em exportações.
Para implementar a distribuição de vários endpoints, use um volume de grande capacidade que exponha a mesma exportação NFS em vários endereços IP. Distribua os clientes entre esses endpoints atribuindo grupos de clientes fixos a cada endereço IP ou ativando um nome DNS que seja resolvido em um endereço por ativação. Cada endpoint tem seu próprio orçamento de conexão; a distribuição de clientes ajuda a evitar a concentração de E/S em todo o farm em um único endereço IP.
Combinar padrões
Para ambientes de EDA de produção, é possível combinar esses padrões arquitetônicos para otimizar o desempenho:
Totalmente na nuvem: use volumes temporários de grande capacidade e volumes padrão menores para ferramentas e página inicial.
Híbrido: use o FlexCache para bibliotecas e ferramentas, com um volume temporário provisionado na nuvem para saída de jobs.
Distribuição: use o FlexCache por site ou por fila do programador, além de DNS de vários endpoints para um volume temporário grande nativo da nuvem.
Corresponda ao nível de serviço e ao tipo de pool de volume (Flex Unified regular versus grande capacidade) às necessidades de capacidade e desempenho de cada camada. Para mais informações, consulte Níveis de serviço.