Executando um cluster do SAS Grid Manager de alto desempenho na AWS com o Amazon FSX para Lustre

Por Neelam e Dilip Rajan

O SAS® é um fornecedor de software especializado em Ciência e Análise de Dados usado por empresas e organizações governamentais. O SAS Grid é uma plataforma de Análise de Computação rápida e altamente disponível que fornece gerenciamento centralizado que equilibra cargas de trabalho entre diferentes nós de computação. Este conjunto de aplicativos é capaz de gerenciar dados para análise visual, governança e segurança, previsão e mineração de texto, análise estatística, bem como gerenciamento ambiental. Nos últimos tempos, o SAS e a AWS colaboraram para testar em conjunto o uso do sistema de compartilhamento de arquivos Amazon FSX para Lustre e determinar o desempenho de cargas de trabalho padrão na AWS usando o SAS Grid Manager. Para obter um relatório detalhado sobre os resultados, consulte o whitepaper Acelerando o SAS usando sistemas de arquivos de alto desempenho.

Nesta publicação, discutimos a arquitetura proposta para implementar a infraestrutura subjacente da AWS necessária para executar o SAS Grid com FSX para Lustre; essa arquitetura também pode ser considerada para executar aplicativos semelhantes com requisitos exigentes de “entrada/saída” (E/S).

Visão geral da arquitetura

A execução de cargas de trabalho de alto desempenho, com alta dependência do desempenho da infraestrutura, especialmente da latência da rede, requer abordagens diferentes das usadas no projeto de aplicativos típicos. A AWS geralmente recomenda que os aplicativos sejam estendidos a várias zonas de disponibilidade para alta disponibilidade; no entanto, considerando o requisito de conectividade de latência muito baixa nesses tipos de aplicativos, recomenda-se que o tráfego seja mantido localmente, alcançando o desempenho ideal. Existem diferentes técnicas para alcançar esse objetivo:

• Execute em uma Virtual Private Cloud (Amazon VPC), usando tipos de instância que suportam “enhanced networking”
• Execute instâncias na mesma zona de disponibilidade
• Execute instâncias em “placement groups”

O diagrama a seguir ilustra a arquitetura SAS Grid com FSX para Lustre na AWS.

A arquitetura do SAS Grid consiste em nós intermediários, servidores de metadados e nós de computação em grid. Os nós de nível médio são responsáveis pela execução dos componentes do Platform Web Services (PWS) e do Load Sharing Facility (LSF). Esses componentes manipulam jobs enviados e retornam o status de cada job.

A execução eficiente do PWS e LSF em nós intermediários requer instâncias de alta memória do Amazon Elastic Compute Cloud (Amazon EC2). Em particular, para esse caso de uso, a família de instâncias r5, otimizada para esse tipo de recurso, atenderá a esse requisito.

Os servidores de metadados contêm o repositório que armazena definições de metadados para todos os produtos gerenciados pelo SAS Grid Manager; a família de instâncias r5 também atende efetivamente devido a seus recursos. É necessário atender ou exceder o requisito de memória recomendado de 24 GB de RAM ou 8 MB por núcleo físico (o que for maior). Os servidores de metadados não dependem de recursos de computação intensiva ou de alta largura de banda de E/S; portanto, a família de instâncias r5 selecionada atende às necessidades e permite um equilíbrio entre preço e desempenho.

Os nós do SAS Grid são responsáveis pela execução de trabalhos recebidos pelo grid, e as instâncias do EC2 capazes de lidar com esses trabalhos dependem do tamanho, complexidade e volume de trabalho executado pelo grid. Para atender aos requisitos mínimos das cargas de trabalho do SAS Grid, recomenda-se ter um mínimo de 8 GB de RAM física por núcleo e uma taxa de transferência de E/S garantida de 100 a 125 MB/segundo por núcleo físico. Para este caso de uso, as famílias de instâncias do EC2 m5n e r5n têm recursos suficientes para atender aos requisitos de RAM e desempenho, enquanto também hospedam bibliotecas SASDATA, SASWORK e UTILLOC necessárias para uma operação bem-sucedida da solução em um sistema de arquivos compartilhado. Se o SASWork estiver habilitado no armazenamento de instância, a família de instâncias i3en atenderá à necessidade integrando armazenamento maior que 1,2 TB. Na próxima seção, discutimos como os testes de desempenho foram realizados para alcançar as recomendações de instância do EC2 com o FSX for Lustre.

Etapas para maximizar o desempenho de I/O

O SAS Grid requer um sistema de arquivos compartilhado, e nós queríamos medir o desempenho do FSx para Lustre como o sistema de arquivos compartilhado escolhido, entre diferentes famílias de instâncias do EC2 que atendem aos requisitos mínimos de 8 GB de RAM física por núcleo e desempenho de 100 a 125 MB/segundo por núcleo físico.

O FSx for Lustre é um serviço de armazenamento de arquivos totalmente gerenciado, projetado para aplicativos que exigem armazenamento rápido. Como um sistema de arquivos compatível com POSIX, você pode usar o FSX para Lustre com aplicativos baseados em Linux atuais sem ter que fazer alterações. Embora o FSx for Lustre ofereça a escolha entre sistemas de arquivos scratch e persistentes, recomendamos que o SAS Grid use o sistema de arquivos persistente, pois os dados e bibliotecas SASWORK, SASDATA e UTILLOC precisam ser armazenados por períodos mais longos, garantindo alta disponibilidade e durabilidade dos dados. Para atender ao desempenho de E/S, certifique-se de selecionar a capacidade de armazenamento apropriada para desempenho por unidade de armazenamento para atingir o intervalo desejado de 100 a 125 MB /segundo.

Depois de configurar o sistema de arquivos, recomendamos a montagem do FSX para Lustre com a opção de montagem “flock”, que permite suporte consistente ao bloqueio de arquivos em todos os nós do cluster. O exemplo de código a seguir é um comando de montagem e uma opção de montagem para FSX para Lustre:

$sudo montar -t lustre -o noatime, fs-0123456789abcd.fsx.us-west- 2.amazonaws.com @tcp: /za3atbmv /fsx
$mount -t lustre
172.31.41.37 @tcp: /za3atbmv em /fsx tipo lustre

(rw, noatime, seclabel, rebanho, lazystatfs)

Testes de desempenho e resultados

Para selecionar as instâncias do EC2 mais bem colocadas para executar o SAS Grid com o FSX para Lustre, realizamos uma série de testes de desempenho de rede altamente paralelos, de instâncias do EC2 independentes contra um sistema de arquivos persistente de 100,8 TiB, que foi habilitado com uma capacidade de throughput agregada de 19.688 GB/segundo. Executamos esses testes em várias regiões usando várias famílias de instâncias do EC2 (c5, c5n, i3, i3en, m5, m5a, m5ad, m5n, m5dn, r5, r5a, r5ad, r5n e r5dn). Os testes foram executados por 3 horas para cada instância e a métrica DataWriteBytes no sistema de arquivos foi registrada a cada minuto. Apenas uma instância acessou o sistema de arquivos por vez e os resultados de p99.9 foram capturados. As métricas foram consistentes em quatro regiões diferentes.

Observamos que as famílias de instâncias i3en, m5n, m5dn, r5n e r5dn EC2 atendem ou excedem as recomendações mínimas de memória e desempenho de rede. Para obter mais informações sobre resultados de desempenho, consulte o whitepaper Acelerando SAS usando sistemas de arquivos de alto desempenho. A família de instâncias i3 está no limite de atender ao desempenho mínimo de rede, portanto, no caso específico de exigir armazenamento de instância para bibliotecas SASWORK e UTILLOC, instâncias i3en podem ser consideradas.

M5n e r5n são uma boa combinação de preço e desempenho, e recomendamos a família de instâncias m5n para nós SAS Grid. No entanto, se sua carga de trabalho estiver limitada à memória, considere o uso de instâncias r5n, que fornecem maior memória por núcleo físico por um preço mais alto do que as instâncias m5n.

Além disso, o script de teste de E/S predefinido: rhel_iotest.sh foi executado, que está disponível no repositório SAS Support Sample Tools (SASTSST), usando o mesmo FSX para configuração do Lustre mencionado acima. A tabela a seguir mostra o desempenho de leitura e gravação por núcleo físico para uma variedade de tamanhos de instância nas famílias m5n e r5n.

Para aproveitar a elasticidade, a escalabilidade e a flexibilidade da nuvem, recomendamos distribuir o SAS Grid e calcular a carga de trabalho em instâncias menores, em vez de usar menos instâncias maiores. Para a camada intermediária, use um mínimo de duas instâncias e, para servidores de metadados, recomendamos um mínimo de três instâncias para a arquitetura do SAS Grid.

Conclusões

Antes do Amazon FSx para o sistema de arquivos Lustre, você precisaria considerar o Amazon Elastic File System (Amazon EFS) ou algum sistema de arquivos de terceiros disponível no AWS Marketplace, em conjunto com o Amazon Elastic Block Store (Amazon EBS) para o armazenamento de dados e as Bibliotecas SASWork, SASDATA e UTILLOC. Cada uma dessas opções de armazenamento integra suas próprias configurações e limitações, resultando em um impacto no desempenho. Com o FSX for Lustre, você tem uma solução única para todos os requisitos de armazenamento do SAS Grid, permitindo que você se concentre no gerenciamento de seus negócios de forma otimizada, em vez de concentrar esforços na manutenção de um sistema de arquivos. Além disso, dados os resultados documentados neste texto, recomenda-se que os administradores SAS implantem o SAS Grid em instâncias m5n e r5n para nós de computação exigidos pelo SAS Grid ao integrar o FSX para o sistema de arquivos Lustre.

Se você tiver dúvidas ou sugestões, deixe um comentário.

Mais informações:

https://thinkwithwp.com/es/blogs/big-data/running-a-high-performance-sas-grid-manager-cluster-on-aws-with-amazon-fsx-for-lustre/

Este artigo foi traduzido do Blog da AWS em Inglês.

Sobre os tradutores

Christian Castro é Senior Solutions Architect na AWS Mexico.

Manuel Cuellar é Solutions Architect na AWS Centro America e Caribe.