Use o Armazenamento de Blobs do Azure com o Lustre Gerenciado do Azure

O Lustre Gerenciado do Azure se integra ao Armazenamento de Blobs do Azure para simplificar o processo de importação de dados de um contêiner de blobs para um sistema de arquivos. Também é possível exportar dados do sistema de arquivos para um contêiner de blobs para armazenamento de longo prazo. Este artigo explica os conceitos para usar a integração de blobs com os sistemas de arquivos Lustre Gerenciado do Azure.

Para entender os requisitos e a configuração necessários para um contêiner de blob compatível, consulte Pré-requisitos de integração de blob.

Visão geral da integração de Blobs

Você pode configurar a integração de blobs durante a criação do cluster e pode criar um trabalho de importação a qualquer momento após a criação do cluster. Depois que os dados forem importados, você poderá trabalhar com eles como faria com outros dados do sistema de arquivos. À medida que novos arquivos são criados ou os arquivos existentes são modificados no sistema de arquivos, você pode exportar esses arquivos de volta para a conta de armazenamento executando comandos da CLI do Lustre no cliente ou exportando os dados usando trabalhos de exportação.

Quando você importa dados de um contêiner de blob para um sistema de arquivos Lustre Gerenciado do Azure, somente os nomes dos arquivos (namespace) e os metadados são importados para o namespace do Lustre. O conteúdo real de um blob é importado quando acessado pela primeira vez por um cliente. Há um pequeno atraso no primeiro acesso aos dados enquanto o recurso HSM (Hierarchical Storage Management, gerenciamento de armazenamento hierárquico) do Lustre puxa o conteúdo do blob para o arquivo correspondente no sistema de arquivos.

Você pode buscar previamente o conteúdo dos blobs usando o comando do Lustre lfs hsm_restore a partir de um cliente montado com recursos sudo. Para saber mais, consulte Restaurar dados do Armazenamento de Blobs.

O Lustre Gerenciado do Azure funciona com contas de armazenamento que têm namespace hierárquico habilitado e contas de armazenamento com um namespace não hierárquico ou simples. As seguintes pequenas diferenças se aplicam:

• Para uma conta de armazenamento com o namespace hierárquico ativado, o Lustre Gerenciado do Azure lê os atributos POSIX do cabeçalho do blob.
• Para uma conta de armazenamento que não tenha o namespace hierárquico ativado, o Lustre Gerenciado do Azure lê os atributos POSIX dos metadados do blob. Um arquivo separado e vazio com o mesmo nome do conteúdo do contêiner de blob é criado para armazenar os metadados. Esse arquivo é um irmão do diretório de dados real no sistema de arquivos do Lustre Gerenciado do Azure.

Importar do armazenamento de Blobs do Azure

Você pode configurar a integração com o armazenamento de Blobs durante a criação do cluster e pode criar um trabalho de importação a qualquer momento após a criação do cluster.

Requisitos do contêiner de blob

Ao configurar a integração de blob durante a criação do cluster, você deve identificar dois contêineres de blob separados: o contêiner a ser importado e o contêiner de registro. O contêiner a ser importado contém os dados que você deseja importar para o sistema de arquivos do Lustre Gerenciado do Azure. O contêiner de registro é usado para armazenar os registros do trabalho de importação. Esses dois contêineres devem estar na mesma conta de armazenamento. Para saber mais sobre os requisitos para o contêiner de blob, consulte Pré-requisitos de integração de blob.

Importar prefixo

Ao importar dados de um contêiner de blob, você pode especificar opcionalmente um ou mais prefixos para filtrar os dados importados para o sistema de arquivos do Lustre Gerenciado do Azure. Os nomes de arquivos no contêiner de blob que correspondem a um dos prefixos são adicionados a um registro de metadados no sistema de arquivos. Quando um cliente acessa um arquivo pela primeira vez, seu conteúdo é recuperado do contêiner de blob e armazenado no sistema de arquivos.

No portal do Azure, use os campos Prefixo de importação na guia Avançado durante a criação do cluster para especificar os dados a serem importados do contêiner de blob. Esses campos se aplicam apenas ao trabalho de importação inicial. Não é possível alterar o prefixo de importação depois que o cluster é criado.

Para um trabalho de importação, você pode especificar os prefixos de importação ao criar o trabalho. No portal do Azure, você pode especificar prefixos de importação nos campos do Prefixo de importação. Você também pode especificar o prefixo de importação ao usar a API REST para criar um trabalho de importação.

Tenha em mente as seguintes considerações ao especificar os prefixos de importação:

• O prefixo de importação padrão é /. Esse comportamento padrão importa o conteúdo de todo o contêiner de blob.
• Se você especificar vários prefixos, os prefixos não deverão se sobrepor. Por exemplo, se você especificar /data e /data2, o trabalho de importação falhará porque os prefixos se sobrepõem.
• Se o contêiner de blob estiver em uma conta de armazenamento com o namespace hierárquico ativado, você poderá pensar no prefixo como um caminho de arquivo. Os itens sob o caminho são incluídos no sistema de arquivos do Lustre Gerenciado do Azure.
• Se o contêiner de blob estiver em uma conta de armazenamento com um namespace não hierárquico (ou simples), você poderá pensar no prefixo de importação como uma cadeia de caracteres de pesquisa que é comparada com o início do nome do blob. Se o nome de um blob no contêiner começar com a cadeia de caracteres que você especificou como prefixo de importação, esse arquivo se tornará acessível no sistema de arquivos. O Lustre é um sistema de arquivos hierárquico e / os caracteres em nomes de blob se tornam delimitadores de diretório quando armazenados no Lustre.

Modo de resolução de conflitos

Ao importar dados de um contêiner de blob, você pode especificar como lidar com conflitos entre o contêiner de blob e o sistema de arquivos. Essa opção só se aplica a trabalhos de importação executados para clusters existentes. A tabela a seguir mostra os modos de resolução de conflitos disponíveis e suas descrições:

Modo	Descrição
fail	Se for detectado um conflito, o trabalho de importação falhará imediatamente com um erro.
skip	O trabalho de importação ignora o arquivo se for detectado um conflito.
overwrite-dirty	O trabalho de importação avalia um caminho conflitante para ver se ele deve ser excluído e reimportado. Para saber mais, consulte modo de substituição de gravação suja.
overwrite-always	O trabalho de importação avalia um caminho conflitante e sempre exclui/reimporta se estiver sujo, ou libera se estiver limpo. Para saber mais, consulte modo modo de substituição de gravação sempre.

Modo de substituição de gravação suja

O overwrite-dirty modo avalia um caminho conflitante para ver se ele deve ser excluído e reimportado. Em um alto nível, overwrite-dirty o modo verifica o estado do HSM. Se o estado do HSM for Limpo e Arquivado, o que significa que seus dados estão sincronizados com o contêiner de blob até onde o Lustre consegue saber, então apenas os atributos são atualizados, se necessário. Caso contrário, o arquivo é excluído e reimportado do contêiner de blob.

A verificação do estado do HSM não garante que o arquivo no Lustre corresponda ao arquivo no contêiner de blob. Se você precisar garantir que o arquivo no Lustre corresponda ao arquivo no contêiner de blob o mais próximo possível, use o modo overwrite-always.

Modo de substituição de gravação sempre

O modo overwrite-always avalia um caminho conflitante e sempre exclui/reimporta se estiver sujo, ou libera se estiver limpo. Esse modo é útil quando você deseja garantir que o sistema de arquivos esteja sempre sincronizado com o contêiner de blob. É também a opção mais cara, pois cada arquivo restaurado anteriormente é liberado ou excluído/reimportado no primeiro acesso.

Tolerância a erros

Ao importar dados de um contêiner de blob, você pode especificar a tolerância a erros. O nível de tolerância a erros determina como o trabalho de importação lida com erros transitórios que ocorrem durante o processo de importação, por exemplo, erros do sistema operacional ou interrupções de rede. É importante observar que os erros nesse contexto não se referem a conflitos de arquivos, que são tratados pelo modo de resolução de conflitos.

As seguintes opções de tolerância a erros estão disponíveis para trabalhos de importação:

• Não permitir erros (padrão): o trabalho de importação falhará imediatamente se ocorrer algum erro durante a importação. Esse comportamento é o padrão.
• Permitir erros: o trabalho de importação continua se ocorrer um erro e o erro é registrado. Após a conclusão do trabalho de importação, é possível visualizar os erros no contêiner de registro.

Considerações sobre trabalhos de importação de blob

É importante considerar os itens a seguir ao importar dados de um contêiner de blob:

• Somente uma ação de importação ou exportação pode ser executada por vez. Por exemplo, se um trabalho de importação estiver em andamento, a tentativa de iniciar outro trabalho de importação retornará um erro.
• Os trabalhos de importação podem ser cancelados. É possível cancelar um trabalho de importação iniciado em um cluster existente ou um trabalho de importação iniciado durante a criação do cluster.
• A implantação do cluster pode retornar com êxito antes que o trabalho de importação correspondente seja concluído. O trabalho de importação continua a ser executado em segundo plano. Você pode monitorar o progresso do trabalho de importação das seguintes maneiras:
  • Portal do Azure: o portal do Azure exibe o status do trabalho de importação. Navegue até o sistema de arquivos e selecione Integração de blob para exibir o status do trabalho de importação.
  • Arquivo Lustre no diretório raiz: um arquivo com nome semelhante a /lustre/IMPORT_<state>.<timestamp_start> é criado no diretório raiz Lustre durante a importação. O espaço reservado <state> muda à medida que a importação avança. O arquivo é excluído quando o trabalho de importação é concluído com êxito.
• Para ver detalhes sobre um trabalho de importação concluído, verifique o contêiner de registro. O contêiner de registro contém registros para o trabalho de importação, incluindo quaisquer erros ou conflitos ocorridos durante a importação.
• Se o trabalho de importação falhar por qualquer motivo, talvez você não tenha estatísticas completas sobre o trabalho de importação, como o número de arquivos importados ou o número de conflitos.

Restaurar dados do Armazenamento de Blobs

Por padrão, o conteúdo de um blob é importado para um sistema de arquivos na primeira vez em que o arquivo correspondente é acessado por um cliente. Para determinadas cargas de trabalho e cenários, talvez você prefira restaurar os dados de um contêiner de blob antes que ele seja acessado pela primeira vez. Você pode optar por buscar previamente o conteúdo dos blobs para evitar o atraso inicial quando o blob for acessado pela primeira vez após a importação. Para buscar previamente o conteúdo dos blobs, você pode usar o comando do Lustre lfs hsm_restore a partir de um cliente montado com recursos sudo. O comando a seguir buscará previamente o conteúdo dos blobs no sistema de arquivos:

nohup find local/directory -type f -print0 | xargs -0 -n 1 sudo lfs hsm_restore &

Esse comando informa ao servidor de metadados para processar de forma assíncrona uma solicitação de restauração. A linha de comando não espera a conclusão da restauração, o que significa que a linha de comando pode enfileirar um grande número de entradas para restauração no servidor de metadados. Essa abordagem pode sobrecarregar o servidor de metadados e prejudicar o desempenho das restaurações.

Para evitar esse possível problema de desempenho, você pode criar um script básico que tenta percorrer o caminho e emite solicitações de restauração em lotes de um tamanho especificado. Para obter um desempenho razoável e evitar sobrecarregar o servidor de metadados, é recomendável usar tamanhos de lote entre 1.000 e 5.000 solicitações.

Exemplo: criar um script de restauração em lote

O exemplo a seguir mostra como criar um script para restaurar dados de um contêiner de blob em lotes. Crie um arquivo chamado file_restorer.bash com os conteúdos a seguir:

#!/bin/bash
set -feu
set -o pipefail
main()
{
    if [ $# -lt 2 ]; then
        echo "$0 <path_to_fully_restore> <max_restores_at_a_time>"
        echo "Missing parameters"
        exit 1
    fi
    local RESTORE_PATH=$1
    local MAX_RESTORES=$2
    local FILES_LIST="/tmp/files_to_restore"
    find "$RESTORE_PATH" -type f > "$FILES_LIST"
    local TOTAL_FILES
    TOTAL_FILES=$(wc -l "$FILES_LIST")
    local RESTORE_TOTAL=0
    local RESTORE_COUNT=0
    while IFS="" read -r p || [ -n "$p" ]; do
        printf '%s\n' "$p"
        lfs hsm_restore "$p"
        ((RESTORE_COUNT++)) || true
        ((RESTORE_TOTAL++)) || true
        if (( RESTORE_COUNT >= MAX_RESTORES )); then
            while true; do
                local STATE
                STATE=$(lfs hsm_state "$p")
                RELEASED=') released exists archived'
                if ! [[ $STATE =~ $RELEASED ]]; then
                    echo "Restored $RESTORE_TOTAL / $TOTAL_FILES"
                    break
                fi
                sleep 0.2
            done
            RESTORE_COUNT=0
        fi
    done < "$FILES_LIST"
}
main "$@"

O exemplo a seguir mostra como executar o script junto com a amostra de saída:

root@vm:~# time ~azureuser/file_restorer.bash /lustre/client/ 5000
Finding all files to restore beneath: /lustre/client/
Found 78100 to restore
Initiating restores in batches of 5000...
Restored 5000 / 78100
Restored 10000 / 78100
Restored 15000 / 78100
Restored 20000 / 78100
Restored 25000 / 78100
Restored 30000 / 78100
Restored 35000 / 78100
Restored 40000 / 78100
Restored 45000 / 78100
Restored 50000 / 78100
Restored 55000 / 78100
Restored 60000 / 78100
Restored 65000 / 78100
Restored 70000 / 78100
Restored 75000 / 78100
Restored 78100 / 78100
real	6m59.633s
user	1m20.273s
sys	0m37.960s

Observação

No momento, o Lustre Gerenciado do Azure restaura dados do Armazenamento de Blobs a uma taxa de transferência máxima de aproximadamente 7,5 GiB/segundo.

Exportar dados para o Armazenamento de Blobs usando um trabalho de exportação

Você pode copiar dados do seu sistema de arquivos Lustre gerenciado pelo Azure para o armazenamento de longo prazo no Armazenamento de Blobs do Azure criando um trabalho de exportação.

Quais arquivos são exportados durante um trabalho de exportação?

Quando você exporta arquivos do seu sistema Lustre Gerenciado do Azure, nem todos os arquivos são copiados para o contêiner de blob que você especificou quando criou o sistema de arquivos. As regras a seguir se aplicam a trabalhos de exportação:

• Os trabalhos de exportação copiam apenas arquivos novos ou cujo conteúdo foi modificado. Se o arquivo que você importou do contêiner de blob durante a criação do sistema de arquivos não for alterado, o trabalho de exportação não exportará o arquivo.
• Os arquivos com alterações de metadados apenas não são exportados. As alterações de metadados incluem: proprietário, permissões, atributos estendidos e alterações de nome (renomeado).
• Os arquivos excluídos no sistema de arquivos do Lustre Gerenciado do Azure não são excluídos no contêiner de blob original durante o trabalho de exportação. O trabalho de exportação não exclui arquivos no contêiner de blob.
• Os nomes de blob devem estar em conformidade com determinadas regras de nomenclatura, o que significa que os nomes de blob aceitáveis diferem ligeiramente dos nomes de arquivo POSIX aceitáveis. O processo de exportação preserva caracteres especiais em nomes de arquivo, aplicando o escape de forma adequada ao exportar para blobs. No entanto, um nome de arquivo que viola uma regra de nomeação de blob, como um nome de arquivo que excede o comprimento máximo do nome do blob, resulta em um erro ao tentar exportar esse arquivo.

Execução de tarefas de exportação em sistemas de arquivos ativos

Em sistemas de arquivos ativos, as alterações nos arquivos durante o trabalho de exportação podem resultar em status de falha. Esse status de falha permite que você saiba que nem todos os dados do sistema de arquivos puderam ser exportados para o Armazenamento de Blobs. Nessa situação, você pode repetir a exportação ao criar um novo trabalho de exportação. O novo trabalho copia apenas os arquivos que não foram copiados no trabalho anterior.

Em sistemas de arquivos com muita atividade, as tentativas podem falhar várias vezes porque os arquivos são alterados com frequência. Para verificar se um arquivo foi exportado com êxito para o Armazenamento de Blobs, verifique o carimbo de data/hora no blob correspondente. Após a conclusão do trabalho, você também pode visualizar o contêiner de registro configurado no momento da implementação para ver informações detalhadas sobre o trabalho de exportação. O contêiner de registro fornece informações de diagnóstico sobre quais arquivos falharam e por que falharam.

Se estiver se preparando para desativar um cluster e quiser realizar uma exportação final para o Armazenamento de Blobs, certifique-se de que todas as atividades de E/S sejam interrompidas antes de iniciar o trabalho de exportação. Essa abordagem garante que todos os dados sejam exportados, evitando erros devido à atividade do sistema de arquivos.

Metadados para arquivos exportados

Quando os arquivos são exportados do sistema de arquivos do Lustre Gerenciado do Azure para o contêiner de blob, metadados adicionais são salvos para simplificar a reimportação do conteúdo para um sistema de arquivos.

A tabela a seguir lista os atributos POSIX do sistema de arquivos Lustre que são salvos nos metadados do blob como pares de valores-chave:

Atributo POSIX	Tipo
owner	int
group	int
permissions	formato octal ou rwxrwxrwx; há suporte para sticky bit

Os atributos do diretório são salvos em um blob vazio. Esse blob tem o mesmo nome do caminho do diretório e contém o seguinte par chave-valor nos metadados do blob: hdi_isfolder : true.

Você pode modificar os atributos POSIX manualmente antes de usar o contêiner para hidratar um novo cluster Lustre. Edite ou adicione metadados de blob usando os pares de valores-chave descritos anteriormente.

Considerações sobre trabalhos de exportação

É importante considerar os itens a seguir ao exportar dados com um trabalho de exportação:

• Somente uma ação de importação ou exportação pode ser executada por vez. Por exemplo, se um trabalho de exortação estiver em andamento, a tentativa de iniciar outro trabalho de exportação retornará um erro.

Copiar um contêiner de blob do Lustre com o AzCopy ou o Gerenciador de Armazenamento

Você pode mover ou copiar o contêiner de blob que o Lustre usa com o AzCopy ou o Gerenciador de Armazenamento.

Para o AzCopy, você pode incluir atributos de diretório adicionando o seguinte sinalizador:

--include-directory-stub

A inclusão desse sinalizador preserva os atributos POSIX do diretório durante uma transferência, por exemplo, owner, group e permissions. Se você usar azcopy no contêiner de armazenamento sem esse sinalizador ou com o sinalizador definido como false, os dados e os diretórios serão incluídos na transferência, mas os diretórios não manterão seus atributos POSIX.

No Gerenciador de Armazenamento, você pode habilitar esse sinalizador em Configurações ao selecionar Transferências e ao marcar a caixa Incluir Incluir stubs de diretório.

Próximas etapas

• Pré-requisitos para a integração do armazenamento de blobs
• Criar um trabalho de importação do Armazenamento de Blobs para o Lustre Gerenciado do Azure
• Criar um trabalho de exportação para exportar dados do Lustre Gerenciado do Azure