Requisitos de acesso a arquivos híbridos
As unidades anteriores estavam em grande parte focadas no que sua solução de armazenamento está fazendo. Esta unidade concentra-se no local onde os seus dados estão localizados. Especificamente, considerações de acesso a arquivos híbridos e como abordá-las.
Visão geral do acesso a arquivos híbridos
Você decidiu executar uma carga de trabalho HPC no Azure que está sendo executada atualmente em seu datacenter. Seu ambiente de computação acessa dados em seu NAS, que está servindo operações NFSv3 para sua carga de trabalho. Ele está sendo executado lá há anos, mas talvez seu ambiente NAS esteja chegando ao fim de seu ciclo. Em vez de substituí-lo, você está considerando uma migração de longo prazo para a nuvem.
Depois de tomar essa decisão, mas antes da implantação completa na nuvem de sua carga de trabalho HPC, você determina sua estratégia do Azure e estabelece sua configuração de conta/assinatura/segurança de linha de base. Agora a parte difícil: mover suas cargas de trabalho de HPC!
A construção do cluster HPC e seu plano de gerenciamento estão fora do escopo deste módulo. Supomos que você tenha determinado quais tipos e quantidades de máquinas virtuais deseja executar em seu cluster.
Por enquanto, também assumimos que seu objetivo é executar a carga de trabalho como está. Ou seja, você não deseja modificar a lógica ou os métodos de acesso atualmente implantados localmente. A implicação é que seu código espera que os dados estejam em caminhos de diretório nos sistemas de arquivos locais dos membros do cluster.
O primeiro objetivo é entender quais dados são necessários e de onde eles são originados. Seus dados podem estar em um único diretório em um único ambiente NAS ou podem estar espalhados por vários ambientes.
O próximo objetivo é determinar a quantidade de dados necessária para executar a carga de trabalho. Os dados de origem são alguns gigabytes ou centenas de terabytes?
Finalmente, você precisa determinar como os dados são apresentados na computação do Azure. Ele é servido localmente para cada máquina de cluster HPC ou compartilhado por uma solução NAS baseada em nuvem?
Considerações sobre acesso remoto a dados
Você tem uma carga de trabalho de genômica que deseja executar no Azure. Seus dados são gerados localmente por sequenciadores de genes e enviados para um ambiente NAS local. Os pesquisadores locais consomem os dados para vários usos. Os pesquisadores também podem querer consumir os resultados da carga de trabalho de HPC que você pretende executar no Azure. Mas alguns deles usam estações de trabalho locais para fazer isso. Vamos também supor que novos dados genômicos sejam gerados regularmente. Portanto, você tem um intervalo limitado para executar a carga de trabalho atual antes que os dados precisem ser substituídos/atualizados.
O desafio é apresentar os dados para a computação do Azure de forma econômica e oportuna, mas ainda preservar o acesso local a eles.
Aqui estão algumas das principais perguntas a serem feitas quando você está tentando executar cargas de trabalho HPC no Azure:
- Podemos mover os dados de origem para o Azure sem manter uma cópia no local?
- Podemos salvar dados de resultados no armazenamento do Azure sem manter uma cópia local?
- Os usuários locais precisam de acesso simultâneo aos dados de origem ou resultados?
- Se o fizerem, poderão operar nos dados no Azure ou precisam que os dados sejam armazenados localmente?
Se os dados precisarem ser mantidos no local, quantos dados deverão ser copiados para o Azure para a carga de trabalho? Quanto tempo você tem depois que os dados são processados antes de precisar processar um novo conjunto de dados? Sua carga de trabalho será executada nesse período?
Você também precisa considerar a conectividade de rede com o Azure. Você tem apenas acesso à Internet ao Azure? Essa limitação pode ser aceitável, dependendo do tamanho dos dados a serem copiados/transferidos e da quantidade de tempo entre as atualizações. Talvez você tenha uma grande quantidade de dados para copiar cada vez. Você pode precisar de uma conexão de rede de longa distância (WAN) com o Azure que usa o Azure ExpressRoute, o que forneceria mais largura de banda para copiar/transferir os dados.
Se você já tiver uma conexão de Rota Expressa com o Azure, aqui está a próxima consideração: quanto da conexão está disponível para sua operação de cópia de dados? Se o link estiver muito saturado, talvez seja necessário considerar a hora do dia em que você transfere dados. Ou talvez você queira configurar uma conexão de Rota Expressa maior para acomodar grandes transferências de dados.
Se você mover os dados para o Azure, talvez seja necessário considerar como protegê-los. Por exemplo, você pode ter um ambiente NFS local que usa um serviço de diretório que ajuda a estender as permissões aos usuários. Se você planeja copiar essa segurança para o Azure, precisará decidir se precisa de um serviço de diretório como parte da compilação do Azure. Mas se a carga de trabalho estiver restrita ao cluster HPC e os resultados forem transferidos de volta para o ambiente local, talvez seja possível omitir esses requisitos.
Em seguida, consideramos os métodos para acessar dados: cache, cópia e sincronização.
Cache vs. cópia vs. sincronização
Vamos discutir as abordagens gerais que você pode usar para adicionar dados ao Azure. O foco desta discussão de transferência de dados são os dados ativos, não o arquivamento e backup de dados.
Suponha que os dados transferidos em nossa discussão são o conjunto de trabalho de uma carga de trabalho de HPC. Num ambiente de HPC para as ciências da vida, os dados podem incluir dados de origem, como dados genómicos brutos, binários utilizados para processar esses dados ou dados suplementares, como genomas de referência. Ele precisa ser processado imediatamente após a chegada ou não muito tempo depois. Os dados também devem ser armazenados em mídia que tenha o perfil de desempenho apropriado para IOPS, latência, taxa de transferência e custo. Por outro lado, os dados de arquivamento/backup são, na maioria das vezes, transferidos para a solução de armazenamento mais barata possível, que não se destina a acesso de alto desempenho.
Os principais métodos de transferência de dados ativos são o cache, a cópia e a sincronização. Vamos discutir os prós e contras de cada abordagem, começando com a cópia.
A cópia de dados é a abordagem mais comum para mover dados. Os dados são copiados de várias maneiras, dependendo da ferramenta que você usa.
Considere estes fatores:
- O tamanho dos ficheiros.
- O número de ficheiros.
- A quantidade de taxa de transferência disponível para transferir os dados.
- A quantidade de tempo que você tem para fazer a transferência.
Uma ferramenta de cópia básica é cp tudo o que você precisa se estiver transferindo um punhado de arquivos de tamanho razoável para um destino remoto. Você provavelmente vai querer usar scp em vez de se estiver transferindo dados por redes que não são seguras: scp fornece criptografia por meio de cp uma conexão Secure Shell (SSH).
Há muitas abordagens para otimizar as operações de cópia, dependendo de onde você pretende copiar os dados. Se você estiver copiando arquivos diretamente para cada máquina HPC, poderá agendar operações de cópia individuais em cada nó, por exemplo.
Uma consideração ao copiar dados em links WAN é a quantidade de arquivos e pastas que estão sendo copiados. Se você estiver copiando muitos arquivos pequenos, você deseja combinar o uso de cópia com um arquivo como tar remover a sobrecarga de metadados do link WAN. Copie o arquivo .tar para o Azure e, em seguida, copie os dados para as máquinas.
Outro problema com a cópia envolve o risco de interrupção. Por exemplo, se você estiver tentando copiar um arquivo grande e houver erros de transmissão, o uso cp não funcionará porque não é possível reiniciar a cópia de onde parou.
Uma última preocupação com a cópia de dados é que sua cópia pode ficar obsoleta. Por exemplo, você pode copiar um conjunto de dados para o Azure. Enquanto isso, um usuário local pode ter atualizado um ou mais dos arquivos de origem. Você precisa determinar um processo para garantir que está usando os dados corretos.
A sincronização de dados é uma forma de cópia, mas é mais sofisticada. Ferramentas como rsync adicionar a capacidade de sincronizar dados entre a origem e o destino, além de copiá-los da origem. rsync garante que os arquivos estejam atualizados com base no tamanho do arquivo e nas datas de modificação. A sincronização permite minimizar a possibilidade de usar arquivos obsoletos.
rsync tem capacidade de recuperação. Por exemplo, se você estiver copiando um arquivo grande e tiver problemas de transmissão, rsync poderá retomar de onde parou.
rsync é gratuito e fácil de implementar. Tem capacidades além das que descrevemos aqui. Ele permite que você estabeleça um sistema de arquivos sincronizado no Azure com base em seus dados locais.
rsync também tem limitações que devemos mencionar. Primeiro, a ferramenta é de thread único. Ele pode executar apenas uma operação de cada vez e não pode paralelizar o acesso aos dados. O utilitário cp de cópia também é de thread único. Portanto, essas ferramentas não são otimizadas para operações de cópia/sincronização em grande escala que envolvem grandes quantidades de dados e uma curta janela de tempo. Além disso, você precisa executar a ferramenta para sincronizar dados. A execução da ferramenta adiciona complexidade ao seu ambiente, pois você precisa garantir que ele esteja sendo executado de acordo com seus requisitos de prazo. Talvez você queira agendar um script que inclua rsync, por exemplo. Essa abordagem requer que você adicione o registro em log do seu script, caso haja problemas. Isso também significa que você precisa ficar atento aos problemas. O nível de complexidade pode crescer rapidamente.
Se você estiver executando uma solução NAS comercial, há ferramentas de sincronização no nível do servidor que você pode comprar, que são mais sofisticadas e oferecem desempenho multi-threaded. Depois de habilitadas e configuradas, essas ferramentas estão sempre operando, sincronizando dados entre uma ou mais fontes e destinos.
Copiar e sincronizar transmite cópias completas dos dados de origem. A transmissão completa de arquivos pode ser boa para conjuntos de dados ou tamanhos de arquivo menores. Pode introduzir atrasos significativos se os dados de origem consistirem em muitos ficheiros grandes. Quanto mais dados transferir, mais tempo demorará a transferência. A sincronização garante que você esteja adicionando apenas novos arquivos à nuvem. Mas esses arquivos ainda precisam ser transmitidos em sua totalidade. Em alguns casos, a carga de trabalho HPC pode não exigir a totalidade de um determinado conjunto de ficheiros. Pode exigir acesso apenas a áreas específicas de ficheiros.
O armazenamento em cache de dados é uma terceira abordagem para adicionar dados ao Azure. Caching refere-se à recuperação e apresentação de dados de arquivo através de um cache. O cache pode estar localizado em clientes locais individuais ou pode ser um cache distribuído que atende a todas as máquinas HPC. Os caches são normalmente usados para minimizar a latência, portanto, colocar um cache em um limite de latência é uma abordagem ideal para servir dados. Por exemplo, você pode armazenar em cache solicitações de dados em uma conexão WAN colocando um cache distribuído na computação do Azure conectado ao armazenamento local no link WAN.
Neste módulo, estamos nos referindo especificamente ao cache de arquivos, onde o próprio cache coloca em campo solicitações de máquinas. Ele recupera os dados de um ambiente de armazenamento back-end (como um ambiente NAS NFS) e apresenta esses dados aos clientes.
O poder do cache é duplo. Primeiro, os caches não recuperam arquivos inteiros. Um cache recupera um subconjunto solicitado, ou intervalo de bytes, de arquivos, em vez de arquivos inteiros. A recuperação é baseada em solicitações de cliente para esses intervalos de bytes. Essa abordagem de recuperação minimiza as penalidades de desempenho para recuperar a totalidade de um arquivo grande quando apenas uma pequena seção do arquivo é necessária.
Em segundo lugar, os caches otimizam o acesso repetido de dados solicitados com frequência. Depois que um intervalo de bytes estiver no cache, as solicitações posteriores para esses dados serão rápidas. A única recuperação lenta é a primeira recuperação. Você pode obter benefícios significativos quando estiver executando um grande número de clientes/threads HPC que estão acessando um conjunto comum de arquivos.
O cache oferece outra vantagem para cenários híbridos. Os dados são armazenados no Azure (no cache) apenas de forma transitória. E é armazenado apenas durante a operação da carga de trabalho de HPC. Assim, você pode reduzir a sobrecarga logística envolvida na movimentação de dados mais concreta para o Azure. Você pode isolar as preocupações de privacidade e segurança de dados para o cache e as próprias máquinas HPC.
Finalmente, certas soluções de cache oferecem o que é chamado de verificação de atributos. Como a sincronização, o cache verifica periodicamente os atributos do arquivo na origem e recupera intervalos de bytes quando a modificação do arquivo é maior na origem. Essa arquitetura garante que seu ambiente HPC esteja sempre operando com os dados mais atualizados.
