Este documento fornece orientações sobre arquitetura para ajudar você a projetar e dimensionar um sistema de arquivos Lustre para cargas de trabalho de computação de alto desempenho (HPC). Também fornece uma visão geral do processo para implantar um sistema de arquivos Lustre no Google Cloud usando o DDN EXAScaler.
O Lustre é um sistema de arquivos paralelo de código aberto que oferece armazenamento de alta capacidade e baixa latência para cargas de trabalho de HPC com acoplamento rígido. É possível escalonar um sistema de arquivos Lustre para dar suporte a dezenas de milhares de clientes HPC e petabytes de armazenamento. A EXAScaler Cloud é uma versão corporativa do Lustre oferecida pela DDN, uma parceira do Google. É possível implantar o EXAScaler Cloud em uma arquitetura de nuvem híbrida para aumentar a capacidade da HPC no local. O EXAScaler Cloud também pode servir como repositório para armazenar recursos de longo prazo a partir de uma implantação do EXAScaler no local.
As orientações neste documento são destinadas a arquitetos corporativos e profissionais técnicos que projetam, provisionam e gerenciam o armazenamento para cargas de trabalho da HPC na nuvem. No documento, pressupomos que você tenha uma compreensão conceitual dos sistemas de arquivos paralelos. Você também precisa entender os casos de uso da HPC para os quais sistemas de arquivos paralelos como o Lustre são ideais. Para mais informações, consulte Sistemas de arquivos paralelos para cargas de trabalho de HPC.
Visão geral do sistema de arquivos Lustre
O diagrama a seguir mostra a arquitetura de um sistema de arquivos Lustre:
Como mostrado no diagrama, a arquitetura contém os seguintes componentes:
Servidor de gerenciamento (MGS) e destinos de gerenciamento (MGT): o MGS armazena e gerencia informações de configuração sobre um ou mais sistemas de arquivos Lustre. O diagrama mostra os MGS gerenciando um único sistema de arquivos do Lustre. O MGS fornece informações de configuração para os outros componentes do Lustre em todos os sistemas de arquivos que gerencia. Os MGS registram registros de configuração do sistema de arquivos em dispositivos de armazenamento chamados de MGTs.
Servidores de metadados (GDG) e destinos de metadados (MDT): os nós GDG gerenciam o acesso do cliente ao namespace de um sistema de arquivos Lustre. Esse namespace inclui todos os metadados do sistema de arquivos, como a hierarquia de diretórios, o horário de criação do arquivo e as permissões de acesso. Os metadados são armazenados em dispositivos de armazenamento chamados de MDTs. Um sistema de arquivos Lustre tem pelo menos um GDG e um MDT associado. Para melhorar o desempenho de cargas de trabalho com muitos metadados, como quando milhares de clientes criam e acessam milhões de arquivos pequenos, adicione mais nós do GDG ao sistema de arquivos.
Servidores de armazenamento de objetos (OSS) e destinos de armazenamento de objetos (OST): os nós OSS gerenciam o acesso do cliente aos dados do arquivo armazenados em um sistema de arquivos do Lustre. Cada arquivo é armazenado como um ou mais objetos Lustre. Os objetos são armazenados em um único dispositivo de armazenamento (chamado de OST) ou listados em vários nós do OSS e OSTs. Um sistema de arquivos Lustre tem pelo menos um OSS e um OST associado. É possível escalonar a capacidade de armazenamento e o desempenho do sistema de arquivos adicionando mais nós OSS e OSTs. A capacidade total de armazenamento do sistema de arquivos é a soma das capacidades de armazenamento dos OSTs que estão conectadas a todos os nós do OSS no sistema de arquivos.
Clientes: um cliente Lustre é um nó de computação, como uma máquina virtual (VM), que acessa um sistema de arquivos Lustre por meio de um ponto de montagem. O ponto de montagem oferece um namespace unificado para todo o sistema de arquivos. É possível escalonar um sistema de arquivos Lustre para dar suporte ao acesso simultâneo por mais de 10.000 clientes. Os clientes do Lustre acessam todos os nós do GDG e do OSS em um sistema de arquivos o Lustre em paralelo. Esse acesso paralelo ajuda a maximizar o desempenho do sistema de arquivos. O acesso paralelo também ajuda a reduzir os pontos de acesso de armazenamento, que são locais de armazenamento acessados com muito mais frequência do que outros locais. Os pontos de acesso são comuns em sistemas de arquivos não paralelos e podem causar um desequilíbrio de desempenho entre os clientes.
Para acessar um sistema de arquivos Lustre, um cliente recebe o diretório e os metadados de arquivo necessários de um GDG e, em seguida, lê ou grava dados comunicando-se com um ou mais nós do OSS. O Lustre oferece uma boa conformidade com a semântica do POSIX e permite que todos os clientes tenham acesso total e paralelo ao sistema de arquivos.
Saiba mais sobre o sistema de arquivos do Lustre e como ele funciona na documentação do Lustre (em inglês).
Arquitetura do Lustre no Google Cloud
O diagrama a seguir mostra uma arquitetura para implantar um sistema de arquivos Lustre no Google Cloud:
A arquitetura mostrada neste diagrama contém os seguintes recursos. Todos os recursos são implantados em um único projeto do Google Cloud. Os recursos de computação e armazenamento são provisionados em uma única zona.
As VMs do Compute Engine hospedam os nós do MGS, GDG e OSS e os clientes do Lustre. Também é possível implantar os clientes do Lustre em um cluster do Google Kubernetes Engine e implantar o sistema de arquivos nas VMs do Compute Engine.
A arquitetura inclui os seguintes recursos de rede:
- Uma única sub-rede de nuvem privada virtual (VPC) usada para todas as VMs.
- Um gateway opcional do Cloud NAT e um Cloud Router para tráfego de saída das VMs privadas para a Internet.
- Regras de firewall opcionais para permitir conexões de entrada SSH em todas as VMs na topologia.
- Uma regra de firewall opcional para permitir o acesso HTTP da Internet ao console da Web do DDN EXAScaler no MGS.
- Um firewall para permitir conexões TCP entre todas as VMs.
Os discos permanentes oferecem capacidade de armazenamento para os nós MGS, GDG e OSS. Se você não precisa de armazenamento permanente, é possível criar um sistema de arquivos arranhado usando discos locais de unidade de estado sólido (SSD, na sigla em inglês). , que são anexados às VMs.
O Google enviou entradas IO500 que demonstram o desempenho dos sistemas de arquivos permanentes e de arranhão. Leia sobre o envio do Google Cloud que demonstra um sistema de arquivos de trabalho baseado em Lustre com mais de 10 Tbps na classificação de sistemas de armazenamento HPC IO500.
Diretrizes de design
Use as diretrizes a seguir para projetar um sistema de arquivos Lustre que atenda aos requisitos das cargas de trabalho da HPC. As diretrizes nesta seção não são completas. Eles fornecem um framework para ajudar você a avaliar os requisitos de armazenamento das cargas de trabalho da HPC, avaliar as opções de armazenamento disponíveis e dimensionar o sistema de arquivos Lustre.
Requisitos de carga de trabalho
Identifique os requisitos de armazenamento das cargas de trabalho de HPC. Defina os requisitos da forma mais granular possível e considere seus requisitos futuros. Use as perguntas abaixo como ponto de partida para identificar os requisitos da sua carga de trabalho:
- Quais são seus requisitos de capacidade de processamento e E/S por segundo (IOPS)?
- De quanta capacidade de armazenamento você precisa?
- Qual é sua meta de design mais importante: capacidade, IOPS ou capacidade de armazenamento?
- Você precisa de armazenamento permanente, armazenamento de arranhão ou ambos?
Opções de armazenamento
Para escolher as opções de armazenamento mais econômicas, escolha um dos tipos de Persistent Disks a seguir:
- Os discos permanentes padrão (
pd-standard) são a opção mais econômica quando a capacidade de armazenamento é a principal meta de design. Elas fornecem armazenamento em blocos eficiente e confiável usando unidades de disco rígido (HDD, na sigla em inglês). - Os discos permanentes SSD (
pd-ssd) são a opção mais econômica quando a meta é maximizar IOPS. Elas fornecem armazenamento em blocos rápido e confiável usando SSDs. - Os discos permanentes equilibrados (
pd-balanced) são a opção mais econômica para maximizar a capacidade de processamento. Eles fornecem armazenamento em blocos confiável e econômico usando SSDs.
Discos permanentes extremos (pd-extreme) podem proporcionar um desempenho melhor do que
os outros tipos de disco, e você pode escolher as IOPS necessárias. Mas pd-extreme custa
mais do que os outros tipos de disco.
Para mais informações sobre os recursos de desempenho de discos permanentes, consulte Desempenho do armazenamento em blocos.
Para armazenamento de trabalho, é possível usar SSDs locais temporários. Os SSDs locais estão fisicamente conectados ao servidor que hospeda as VMs. Portanto, os SSD locais oferecem maior capacidade e menor latência do que os discos permanentes. Porém, os dados armazenados em um SSD local permanecem somente até a VM ser interrompida ou excluída.
Servidores de armazenamento de objetos
Ao projetar a infraestrutura para os nós do OSS, recomendamos o seguinte:
Para o armazenamento, escolha um tipo de disco permanente apropriado com base nos seus requisitos de capacidade de armazenamento, capacidade e IOPS.
- Use
pd-standardpara cargas de trabalho que tenham os seguintes requisitos:- A carga de trabalho precisa de alta capacidade de armazenamento (por exemplo, mais de 10 TB) ou de alta capacidade de leitura e alta capacidade de armazenamento.
- A latência de E/S não é importante.
- Uma baixa capacidade de gravação é aceitável.
- Use
pd-balancedpara cargas de trabalho que tenham qualquer um dos seguintes requisitos:- Alta capacidade com baixa capacidade.
- A baixa latência fornecida por discos baseados em SSD.
- Use
pd-ssdpara cargas de trabalho que exigem alta IOPS (pequenas solicitações de E/S ou arquivos pequenos).
- Use
Provisione capacidade de armazenamento suficiente para alcançar as IOPS necessárias. Considere as IOPS de leitura e gravação fornecidas por cada tipo de disco.
Para as VMs, use um tipo de máquina da família de máquinas N2 ou N2D. Esses tipos de máquina oferecem desempenho previsível e econômico.
Aloque vCPUs suficientes para atingir a capacidade de disco permanente necessária. A capacidade máxima do disco permanente por VM é de 1,2 GBps, e é possível alcançar essa capacidade com 16 vCPUs. Comece com um tipo de máquina que tenha 16 vCPUs. Monitore o desempenho e aloque mais vCPUs quando precisar escalonar as IOPS.
Servidores de metadados
Os nós GDG não precisam de alta capacidade de armazenamento para metadados de exibição, mas precisam de armazenamento que seja compatível com IOPS altas. Ao projetar a infraestrutura para os nós do GDG, recomendamos o seguinte:
- Para armazenamento, use
pd-ssd, porque esse tipo de disco permanente fornece altos níveis de IOPS (30 IOPS por GB), mesmo com baixa capacidade de armazenamento. - Provisione capacidade de armazenamento suficiente para alcançar as IOPS necessárias.
- Para as VMs, use um tipo de máquina da família de máquinas N2 ou N2D. Esses tipos de máquina oferecem desempenho previsível e econômico.
- Aloque vCPUs suficientes para alcançar os IOPs necessários:
- Para cargas de trabalho de poucos metadados, use 16 vCPUs.
- Para cargas de trabalho de metadados médios, use 32 vCPUs.
- Para cargas de trabalho com uso intensivo de metadados, use 64 vCPUs. Monitore o desempenho e aloque mais vCPUs quando necessário.
Servidor de gerenciamento
O MGS precisa de recursos de computação mínimos. Não é um serviço com alto consumo de armazenamento.
Comece com um tipo de máquina pequeno para a VM (por exemplo, n2-standard-2) e um
disco pd-ssd de 128 GB para armazenamento e
monitore o desempenho.
Se a resposta for lenta, aloque mais vCPUs e aumente o tamanho do disco.
Disponibilidade e durabilidade
Se você precisar de armazenamento permanente, os tipos de disco permanente pd-standard e pd-balanced fornecem armazenamento altamente disponível e durável em uma zona. Para
persistência entre zonas ou regiões, copie os dados para baixo custo
Google Cloud Storage
usando a
CLI do Google Cloud
ou
Serviço de transferência do Cloud Storage.
Para reduzir o custo do armazenamento de dados no Cloud Storage,
armazene dados raramente acessados em um bucket da classe
Nearline Storage
oclasse
Coldline Storage.
Se você precisar de armazenamento temporário para uma implantação de zero, use SSDs locais como discos de dados para os nós do OSS e GDG. Esse design oferece alto desempenho com o menor número de VMs OSS. Esse design também ajuda a alcançar uma proporção de custo-benefício ideal em comparação com as outras opções.
Exemplo de tamanho para VMs de OSS
A estratégia recomendada para dimensionar e provisionar seu sistema de arquivos do Lustre é provisionar VMs de OSS suficientes para atender ao requisito geral de capacidade. Em seguida, aumente a capacidade de armazenamento dos discos OST até atingir a capacidade de armazenamento necessária. A carga de trabalho de exemplo usada nesta seção mostra como implementar essa estratégia seguindo as seguintes etapas:
- Determine os requisitos da carga de trabalho.
- Escolha um tipo de disco permanente.
- Calcule o número de VMs do OSS.
- Calcule o tamanho do disco por VM.
- Determine o número de vCPUs por VM.
Determinar os requisitos da carga de trabalho
Neste exemplo, a carga de trabalho requer 80 TB de capacidade de armazenamento permanente com uma capacidade de leitura de 30 GBps.
Escolher um tipo de Persistent Disk
Conforme discutido na seção
Opções de armazenamento,
pd-standard é a opção mais econômica quando a capacidade de armazenamento
é a meta principal de design e pd-balanced é a opção mais econômica para
maximizar a capacidade de processamento. A capacidade máxima é diferente para cada tipo de disco,
e a capacidade é escalonada conforme o tamanho do disco.
Para cada tipo de disco permanente que pode ser usado para essa carga de trabalho, calcule a capacidade de armazenamento necessária para escalonar a capacidade de leitura para a meta de 30 GBps.
| Tipo de disco | Capacidade de leitura por TB | Capacidade de armazenamento necessária para atingir a capacidade de processamento desejada |
|---|---|---|
pd-standard |
0,12 Gbps | 30 dividido por 0,12 = 250 TB |
pd-balanced |
0,28 Gbps | 30 dividido por 0,28 = 107 TB |
Para atingir a capacidade de leitura desejada de 30 Gbps usando pd-standard, você precisa provisionar 250 TB de capacidade de armazenamento. Esse valor é mais de três vezes a capacidade necessária de 80 TB. Portanto, para a carga de trabalho neste exemplo,
pd-balanced fornece armazenamento econômico que atende aos requisitos de
desempenho.
Calcular o número de VMs de OSS
A capacidade de leitura máxima por VM do Compute Engine é de 1,2 GBps. Para alcançar a capacidade de leitura desejada de 30 GBps, divida a capacidade de leitura de destino pela capacidade máxima por VM da seguinte maneira:
30 GBps / 1.2 GBps = 25
Você precisa de 25 VMs de OSS para alcançar a capacidade de leitura de destino.
Calcular o tamanho do disco por VM
Para calcular o tamanho do disco por VM, divida a capacidade (107 TB) necessária para atingir a capacidade de processamento (30 GBps) pelo número de VMs da seguinte maneira:
107 TB / 25 VMs = 4.3
Você precisa de 4,3 TB de capacidade de pd-balanced por VM.
Determinar o número de vCPUs por VM
A capacidade de leitura de uma VM é escalonada conforme o número de vCPUs alocadas para a
VM. A capacidade de leitura aumenta em 1,2 Gbps para 16 (ou mais) vCPUs. É necessário ter um tipo de máquina com pelo menos 16 vCPUs. Portanto, escolha um tipo de máquina da família de máquinas N2 ou N2D, como n2-standard-32.
Resumo da configuração
A carga de trabalho de exemplo tem os seguintes requisitos:
- Capacidade de armazenamento permanente de 80 TB
- Capacidade de leitura de 30 Gbps
Para atender aos requisitos dessa carga de trabalho, você precisa dos seguintes recursos de computação e armazenamento:
- Número de VMs OSS: 25
- Família de máquinas da VM: N2 ou N2D
- Número de vCPUs por VM: 16 ou mais
- Tipo de disco permanente:
pd-balanced - Tamanho do disco por VM: 4,3 TB
Exemplo de configuração de um sistema de arquivos de trabalho
A configuração a seguir é baseada em um envio do Google Cloud para IO500, que demonstra o desempenho de um sistema de arquivos de rascunho em escala extrema que usa o Lustre e é implantado no Google Cloud:
| Parâmetro de configuração | MDS | OSS | Clientes |
|---|---|---|---|
| Número de VMs | 50 | 200 | 1.000 |
| Tipo de máquina | n2-standard-80 |
n2-standard-64 |
c2-standard-16 |
| Número de vCPUs por VM | 80 vCPUs | 64 vCPUs | 16 vCPUs |
| RAM por VM | 320 GB | 256 GB | 64 GB |
| SO | CentOS 8 | CentOS 8 | CentOS 8 |
| Largura de banda da rede | 100 Gbps | 75 Gbps | 32 Gbps |
| Armazenamento SSD local | NVMe de 9 TB (24 discos) |
NVMe de 9 TB (24 discos) |
Nenhum |
A configuração anterior forneceu o seguinte desempenho:
| Métrica de desempenho | Resultado |
|---|---|
| Capacidade de gravação | 700 GBps (5,6 Tbps) |
| Capacidade de leitura | 1.270 GBps (10,16 Tbps) |
Operações de arquivos stat() |
1,9 milhão por segundo |
| Leituras de arquivos pequenos (3.901 bytes) | 1,5 milhão por segundo |
Opções de implantação
Nesta seção, apresentamos uma visão geral dos métodos que podem ser usados para implantar um sistema de arquivos EXAScaler Cloud no Google Cloud. Nesta seção, também descrevemos as etapas a serem seguidas ao implantar as VMs cliente.
Implantação do sistema de arquivos na nuvem do EXAScaler
Escolha entre os métodos a seguir para implantar um sistema de arquivos EXAScaler Cloud no Google Cloud:
Implantar usando uma solução do Google Cloud Marketplace fornecida pela DDN.
Implantar usando o Cloud HPC Toolkit. O kit de ferramentas inclui um blueprint que usa um módulo Terraform fornecido pelo DDN para implantar um sistema de arquivos de E/S alta.
Com qualquer um dos métodos, é possível personalizar o sistema de arquivos ao implantá-lo. Por exemplo, é possível especificar o número de VMs do OSS, o tipo de máquina para as VMs, os tipos de disco permanente e a capacidade de armazenamento.
Ao escolher um método, considere as seguintes diferenças:
Modificação pós-implantação: se você usar o Cloud HPC Toolkit, poderá modificar com eficiência o sistema de arquivos após a implantação. Por exemplo, para adicionar capacidade de armazenamento, aumente o número de nós OSS atualizando o blueprint do Cloud HPC Toolkit e aplicando a configuração do Terraform gerada novamente. Para ver uma lista dos parâmetros que podem ser especificados no blueprint, consulte a seção Entradas no README do módulo Terraform. Para modificar um sistema de arquivos que foi implantado usando a solução do Cloud Marketplace, faça as alterações para cada recurso de computação e armazenamento usando o Console do Google Cloud, a CLI do gcloud ou a API.
Suporte: a solução do Cloud Marketplace usa o Deployment Manager, que não é compatível com o VPC Service Controls. Para mais informações sobre essa limitação, consulte Limitações e produtos compatíveis do VPC Service Controls.
Implantação do cliente
Use um dos métodos descritos na seção Implantação do sistema de arquivos do EXAScaler Cloud para implantar as VMs cliente. No entanto, o Google recomenda que você provisione e gerencie as VMs clientes separadamente do sistema de arquivos. A maneira recomendada de implantar os clientes é usar a imagem de VM HP fornecida pelo Google, otimizada para cargas de trabalho de HPC.
Veja a seguir uma visão geral do processo de uso da imagem de VM HPC para implantar clientes do Lustre:
- Crie uma VM usando a imagem de VM do HPC.
- Instale os pacotes de cliente do Lustre na VM.
- Personalize a VM conforme necessário.
- Crie uma imagem personalizada a partir da VM.
- Provisione as VMs do cliente Lustre usando a imagem personalizada que você criou. Para automatizar o provisionamento e o gerenciamento das VMs do cliente, use um grupo de instâncias gerenciadas do Compute Engine ou uma ferramenta de terceiros, como o Slurm. Gerenciador de cargas de trabalho.
- Montar o sistema de arquivos Lustre nas VMs do cliente.
Opções de transferência de dados
Depois de implantar um sistema de arquivos Lustre no Google Cloud, você precisa mover seus dados para o sistema de arquivos. A tabela a seguir mostra os métodos que você pode usar para mover dados para o sistema de arquivos Lustre. Escolha o método que corresponde ao volume de dados que você precisa mover e ao local dos dados de origem (no local ou no Cloud Storage).
| Fonte de dados | Tamanho dos dados | Método recomendado de transferência de dados |
|---|---|---|
| No local | Pequeno (por exemplo, menos de 1 TB) | Organize os dados no Cloud Storage com a ferramenta gsutil. Em seguida, faça o download dos dados para o sistema de arquivos Lustre usando o Storage Transfer Service ou a CLI gcloud. |
| No local | Grande | Mova os dados para o sistema de arquivos Lustre usando o
Storage Transfer Service. Siga as instruções em Transferir dados entre sistemas de arquivos POSIX.
Esse método envolve o uso de um bucket intermediário do Cloud Storage. Depois de concluir o job de transferência, o Storage Transfer Service exclui os dados no bucket intermediário. |
| Cloud Storage | Grandes ou pequenos. | Faça o download dos dados do Cloud Storage para o sistema de arquivos Lustre usando o Storage Transfer Service ou a CLI gcloud. |
A seguir
- Saiba mais sobre o Lustre.
- Saiba mais sobre o DDN EXAScaler Cloud e a parceria da DDN com o Google.
- Leia sobre o envio do Google Cloud que demonstra um sistema de arquivos de trabalho baseado em Lustre com mais de 10 Tbps na classificação de sistemas de armazenamento HPC de IO500.
- Implante o DDN EXAScaler no Google Cloud, conforme descrito na seção Implantação do sistema de arquivos do Cloud do EXAScaler neste documento.
Colaboradores
Autor: Kumar Dhanagopal | Desenvolvedor de soluções de vários produtos
Outros colaboradores:
- Carlos Boneti | Engenheiro de software sênior
- Dean Hildebrand | Diretor técnico
- Sean Derrington | Gerente de produtos externos do grupo