Em muitas cargas de trabalho HPC, conseguir o melhor desempenho de ponta a ponta em um aplicativo ou fluxo de trabalho depende da escolha da tecnologia certa a usar para hospedar seus arquivos durante o processamento, ou de configurar sua pilha de rede a fim de obter o desempenho ideal para MPI ou outros protocolos de comunicação. Este módulo abrange quais opções a AWS oferece nessas áreas, e orienta você na avaliação de preço/desempenho para que você escolha as soluções certas para cada carga de trabalho
Tópicos abrangidos:
- Armazenamento na AWS para HPC
- Escalabilidade de rede para cargas de trabalho HPC
Visão geral das opções de armazenamento na AWS: a AWS oferece muitas opções para armazenamento, que variam do armazenamento de objetos de alto desempenho a muitos tipos de sistemas de arquivos que podem ser vinculados a uma instância do EC2. Além do grande desempenho, várias dimensões diferenciam esses tipos de armazenamento, incluindo o custo e a escalonabilidade. A tabela a seguir contém orientações para encontrar o armazenamento certo para cada um de seus dados HPC:
Sistemas de arquivos compartilhados para HPC: o armazenamento compartilhado é obtido de várias maneiras, por exemplo, com uma simples montagem NFS de um volume EBS, com o Intel Lustre montado de volumes EBS, e com o serviço gerenciado da AWS chamado EFS. Como ocorre com o tipo de instância, é fácil testar as opções de armazenamento para encontrar o tipo de sistema de arquivos com o melhor desempenho.
Armazenamento vinculado à instância: os volumes EBS também estão disponíveis com várias opções, que se iniciam em opções magnéticas de volume com alto consumo de IOPS para uso geral. Muitos aplicativos HPC são executados muito bem nesses tipos de armazenamento EBS de volume magnético para uso geral mais baratos. Como ocorre na seleção de instâncias, a seleção do volume EBS é fácil de testar, o que permite uma solução otimizada.
Configuração do Lab Storage: as opções de configuração do armazenamento usadas na automação EnginFrame padrão estão descritas a seguir:
- Os scripts de integração montam um volume EFS em /efs nos nós mestre e de computação. Esses sistemas de arquivos contêm um diretório para aplicativos e um diretório de spool que armazena, por padrão, um diretório de envio separado para cada uma de suas tarefas
- O AWS ParallelCluster também fornece um volume EBS gp2 vinculado à mestre e montado no formato NFS nos nós de computação como /shared
- O diretório /home da instância mestre também é montada no formato NFS nos nós de computação. Como é instalado no mesmo sistema de arquivos do SO, não é recomendado o uso como armazenamento persistente
O desempenho desses sistemas de arquivos compartilhados pode variar substancialmente de uma carga de trabalho para outra. Para entender o que funciona melhor para você, a melhor abordagem é fazer um benchmark do mesmo caso no /efs (que está configurado como o local padrão no EnginFrame) e no /shared.
Redes atuais da AWS: atualmente, a AWS suporta recursos de Redes aperfeiçoadas usando SR-IOV (Virtualização de E/S de raiz única). O SR-IOV é um método de virtualização de dispositivos que oferece performance de E/S mais alta e utilização de CPU mais baixa comparado às implementações tradicionais. Para as instâncias do Amazon EC2 compatíveis, esse recurso oferece maior desempenho de pacotes por segundo (PPS), menores latências entre instâncias e baixíssima instabilidade de rede, além de ter sido testado para ter um bom desempenho em aplicativos “embaraçosamente paralelos” de computação de alta taxa de transferência de dados (HTC) e em aplicativos HPC baseados em MPI e OpenMP.
A velocidade da rede depende do tipo e do tamanho da instância, por exemplo, a r4.16xlarge oferece conectividade de 20 Gigabits entre instâncias, ao usar o mesmo grupo de deslocamento (um agrupamento lógico de instâncias) e redes aperfeiçoadas.
Configuração de redes de laboratório: por padrão, o laboratório cria um novo grupo de localização e requer que todos os nós de computação do cluster sejam iniciados nele. Isso proporciona a mais baixa latência e a maior largura de banda entre seus nós, o que é muito relevante se você executa aplicativos MPI. Se você tem um problema de HTC que se escalona horizontalmente para dezenas de milhares de núcleos ou mais (o que está além do escopo deste laboratório), você deve avaliar a possibilidade de executá-los em vários grupos de localização para proporcionar mais flexibilidade ao EC2 sobre onde alocar esse grande número de nós. Você pode desativar o uso de um grupo de localização fixo configurando o seguinte parâmetro na configuração do AWS ParallelCluster:
placement_group = NONE
Dica: se for necessário escalonar seu cluster para um número muito grande de nós, ou se for necessário um armazenamento de alto desempenho, é uma boa ideia falar com seu gerente técnico de contas ou com um arquiteto de soluções HPC, que podem analisar a estrutura de destino, ajudar a identificar possíveis gargalos e escolher as tecnologias certas para suas metas específicas.