Como fazer um test drive do Amazon Elastic File System

Muitos clientes estão entusiasmados com o Amazon EFS, pois torna incrivelmente fácil a criação e execução de um sistema de compartilhamento de arquivos durável, altamente disponível e escalonável. Em segundos, é possível criar um sistema de arquivos compatível com o NFSv4 e montá-lo em várias instâncias (até milhares) de Amazon EC2 ou em servidores on-premises.

O Amazon EFS fornece um sistema de arquivos elástico, simples e escalável para cargas de trabalho baseadas em Linux e foi projetado para ser escalado para petabytes sob demanda, sem interromper as aplicações que usam esses sistemas de arquivos. O Amazon EFS oferece suporte a uma ampla variedade de casos de uso, desde cargas de trabalho escaláveis ​​com alto paralelismo que exigem o mais alto desempenho possível até cargas de trabalho single thread sensíveis à latência. Casos de uso, como aplicações de negócio, análise de big data, servidores Web e gerenciamento de conteúdo, desenvolvimento e teste de aplicações, fluxos de mídia e entretenimento, salvas de bancos de dados e armazenamento de contêineres.

Tenho o privilégio de trabalhar com clientes que avaliam, projetam e implementam soluções de armazenamento para suportar diferentes aplicações e cargas de trabalho. Uma questão que vejo nos clientes que são novos no Amazon EFS é a falta de familiaridade com técnicas avançadas de sistema de arquivos. Quero compartilhar essas práticas recomendadas antes de avaliar e experimentar o Amazon EFS. Esta postagem ajuda a aproveitar ao máximo o Amazon EFS.

Crie um sistema de arquivos Amazon EFS

Se você ainda não o fez, crie um sistema de arquivos Amazon EFS com o AWS Administration Console ou a AWS Command Line Interface (CLI). Conclua as etapas 1, 2 e 3 em Introdução ao Amazon Elastic File System. Após alguns minutos, você deve efetuar login em uma instância do Amazon EC2 que possui um sistema de arquivos Amazon EFS montado.

Test drive

A primeira coisa que gosto de mostrar aos clientes após montar um sistema de arquivos é o tamanho: o número de blocos de 1K disponíveis. Execute df na linha de comandos da instância do EC2 em que o sistema de arquivos EFS está montado. Ele deve retornar algo semelhante ao que você vê abaixo.

Se é como eu, terá dificuldade em converter um valor de nove quadrilhões (16 dígitos) em algo compreensível. Assim, um rápido df –h facilita a compreensão. Parece às aplicações que elas têm > 8 EB de armazenamento disponível, mas o Amazon EFS é elástico, cresce e diminui automaticamente à medida que você adiciona e exclui dados e paga apenas pelo armazenamento que está usando (nesse caso, zero). Você não precisa mais se preocupar em provisionar armazenamento e paga apenas pelo que usa.

Como é fácil começar a usar o Amazon EFS, talvez você queira avaliar como o Amazon EFS funciona o mais rápido possível. Um teste comum que vejo que alguns clientes usam para avaliar o desempenho do Amazon EFS é um teste de “touch” para gerar muitos arquivos de zero byte. Eu já vi isso escrito em Perl, Python, Java e outras linguagens.

Para esta postagem, uso um script bash para ver com que rapidez arquivos de 1024 podem ser gerados. Execute o comando a seguir na instância do EC2, alterando o caminho para o sistema de arquivos Amazon EFS montado.

Quanto tempo demorou? No meu teste, foram necessários 16.808 segundos para gerar 1024 arquivos no Amazon EFS.

Se você acha que demorou muito para gerar 1024 arquivos de 0 bytes, verifique o comando para assegurar se está correto. Após excluir o primeiro conjunto de 1024 arquivos de 0 bytes, execute o comando novamente. Quais são os resultados? Praticamente os mesmos.

Se você ainda acredita que demorou muito para gerar 1024 arquivos de 0 bytes, pode compará-lo com outra plataforma de armazenamento. Modifique o comando e execute-o no volume do Amazon EBS montado na instância. Execute o comando a seguir e certifique-se de alterar o caminho para usar um volume do Amazon EBS. Neste exemplo, escrevo no diretório inicial do ec2-user.

Quanto tempo demorou? No meu teste, foram necessários 5.112 segundos para gerar 1024 arquivos de 0 byte no EBS. Este é o volume raiz, que é um volume EBS gp2 de 10 GB. Neste exemplo, a operação de gravação do EBS é 3,28 vezes mais rápida em comparação com o EFS.

Em casos como esse, gosto de brincar com diferentes cenários de simulação. O que aconteceria se o comando fosse reescrito para usar vários threads de execução? Isso permite gerar arquivos em paralelo. Apresento o GNU Parallel, que é uma ferramenta shell de código aberto para executar operações seriais em paralelo. Foi adicionado ao repositório Amazon Linux de forma que um comando sudo yum install parallel – y o instala no Amazon Linux 2, após instalar e ativar o pacote rpm EPEL. Para mais informações, consulte GNU Parallel.

Execute o comando a seguir após instalar o GNU Parallel e gere 1024 arquivos de 0 bytes usando vários threads de execução.

Reescrevendo o comando para usar 32 tarefas (ou 32 threads), é possível gerar 1024 arquivos de 0 bytes em apenas 8.647 segundos, o que representa uma melhoria de 94%.

O que aconteceria se reescrevêssemos o comando multithreading para gravar os arquivos em vários diretórios? Cada thread grava em um diretório separado. Isso distribui as operações de gravação entre vários inodes.

Para os que não estão familiarizados com inodes, um inode é uma estrutura de dados no estilo Unix que descreve objetos em um sistema de arquivos, como arquivos e diretórios. A contenção do inode ocorre quando vários threads tentam atualizar o mesmo inode, o que pode ser mais evidente nos sistemas de arquivos da rede devido às latências da rede. Execute o seguinte comando para gerar 1024 arquivos de 0 byte com 32 threads de execução, cada thread de execução deve gerar 32 arquivos em seu próprio diretório. Trinta e dois arquivos em 32 diretórios fornecem um total de 1024 arquivos.

Reescrevendo o comando para usar as 32 tarefas (ou 32 threads) e fazer com que cada thread de execução gere arquivos em seu próprio diretório, é possível gerar 1024 arquivos de 0 byte em apenas 0,776 segundos. Isso é 21 vezes mais rápido que o primeiro teste de um único diretório e um único thread.

Agora, e se o mesmo sistema de arquivos fosse montado em 2, 10, 100 ou 1000 instâncias do Amazon EC2? Quantos arquivos podem ser gerados em um sistema de arquivos que suporta consistência “abrir após fechar”, durabilidade dos dados em vários servidores de armazenamento e várias Zonas de Disponibilidade e alta disponibilidade projetada sem pontos únicos de falha?

Próximos passos

Este é apenas um teste que pode ser feito para avaliar e testar efetivamente o Amazon EFS. Para saber mais sobre suas características de desempenho, recomendo que consulte o Tutorial do Amazon EFS no GitHub. O tutorial explica muito mais do que o teste que fiz e mostra mais exemplos dos benefícios do paralelismo. Também demonstra como o tamanho de I/O, o tipo de instância EC2 e as diferentes ferramentas de transferência de arquivos têm um impacto significativo no desempenho. Essas técnicas também são usadas pelo AWS DataSync para melhorar o desempenho da transferência de dados de e para os sistemas de arquivos Amazon EFS.

Para obter mais sobre o GNU Parallel, consulte “GNU Parallel – The Command-Line Power Tool” na revista USENIX, de fevereiro de 2011.

Resumo

Os sistemas de arquivos Amazon EFS são distribuídos por um número irrestrito de servidores de armazenamento, permitindo acesso paralelo em massa aos objetos do sistema de arquivos. Esse design distribuído evita gargalos e as limitações inerentes aos servidores de arquivos tradicionais.

Neste teste, eu pude usar esses benefícios do Amazon EFS. Reduzi o tempo necessário para gerar 1024 arquivos de 0 bytes de 16.808 segundos para 0,776 segundos, o que representa uma melhoria de 2100%.

Nesta postagem, demonstrei apenas duas recomendações. Você pode usá-los para aproveitar melhor o design de armazenamento de dados distribuídos do Amazon EFS e obter acesso paralelo em massa aos dados do sistema de arquivos.

O primeiro foi acessar o Amazon EFS em paralelo com vários threads. O segundo foi acessar vários diretórios ou inodes em paralelo com vários threads. Outras recomendações para entender melhor e aproveitar o design distribuído do Amazon EFS estão incluídas no Tutorial do Amazon EFS. Espero poder escrever mais postagens sobre o Amazon EFS, o FSx for Windows File Server e o FSx for Lustre.

Sobre o Autor

Darryl Osborne é arquiteto de soluções para serviços de arquivo na Amazon Web Services (AWS). Ele é membro das equipes de serviço Amazon EFS e Amazon FSx e é responsável por evangelizar a ofertas de serviço de arquivo nativas da AWS. Ele gosta de passar o tempo ao ar livre em seu estado natal, Texas.