Usar o Armazenamento de Blob do Azure com o Azure Managed Lustre

O Azure Managed Lustre integra-se com o Armazenamento de Blobs do Azure para simplificar o processo de importação de dados de um contêiner de blob para um sistema de arquivos. Você também pode exportar dados do sistema de arquivos para um contêiner de blob para armazenamento de longo prazo. Este artigo explica os conceitos para usar a integração de blob com os sistemas de arquivos do Azure Managed Lustre.

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 Blob

Você pode configurar a integração de blob 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 os dados como faria com outros dados do sistema de arquivos. À medida que novos arquivos são criados ou 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 do Azure Managed Lustre, somente os nomes de arquivo (namespace) e metadados são importados para o namespace Lustre. O conteúdo real de um blob é importado quando acessado pela primeira vez por um cliente. Há um pequeno atraso ao acessar os dados pela primeira vez, enquanto o recurso Lustre Hierarchical Storage Management (HSM) extrai o conteúdo do blob para o arquivo correspondente no sistema de arquivos.

Você pode pré-buscar o conteúdo de blobs lfs hsm_restore usando o comando do Lustre de um cliente montado com recursos sudo. Para saber mais, consulte Restaurar dados do armazenamento de Blob.

O Azure Managed Lustre 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. Aplicam-se as seguintes pequenas diferenças:

• Para uma conta de armazenamento com namespace hierárquico habilitado, o Azure Managed Lustre lê atributos POSIX do cabeçalho blob.
• Para uma conta de armazenamento que não tem namespace hierárquico habilitado, o Azure Managed Lustre lê atributos POSIX dos metadados de 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 é irmão do diretório de dados real no sistema de arquivos do Azure Managed Lustre.

Importar do armazenamento de Blob

Você pode configurar a integração com o Armazenamento de Blob 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 log. O contêiner a ser importado contém os dados que você deseja importar para o sistema de arquivos do Azure Managed Lustre. O contêiner de registro em log é usado para armazenar logs para o 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.

Prefixo de importação

Ao importar dados de um contêiner de blob, você pode, opcionalmente, especificar um ou mais prefixos para filtrar os dados importados para o sistema de arquivos do Azure Managed Lustre. Os nomes de arquivo 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 Importar prefixo na guia Avançado durante a criação do cluster para especificar os dados a serem importados do contêiner de blob. Esses campos só se aplicam ao trabalho de importação inicial. Não é possível alterar o prefixo de importação após a criação do cluster.

Para um trabalho de importação, você pode especificar prefixos de importação ao criar o trabalho. No portal do Azure, você pode especificar prefixos de importação nos campos Importar prefixo. 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 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 deverão não ser sobrepostos. 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 namespace hierárquico habilitado, você poderá pensar no prefixo como um caminho de arquivo. Os itens sob o caminho são incluídos no sistema de arquivos do Azure Managed Lustre.
• 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 de blob. Se o nome de um blob no contêiner começar com a cadeia de caracteres especificada como o prefixo de importação, esse arquivo será disponibilizado no sistema de arquivos. O Lustre é um sistema de arquivos hierárquico, e / caracteres em nomes de blob tornam-se 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 sujo de substituição

O overwrite-dirty modo avalia um caminho conflitante para ver se ele deve ser excluído e reimportado. Em um nível alto, 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 pode dizer, somente os atributos serão atualizados, se necessário. Caso contrário, o arquivo será excluído e reimportado do contêiner de blob.

Verificar o 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 overwrite-always modo.

Modo de substituição-sempre

O overwrite-always modo 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, já que todos os arquivos restaurados anteriormente são liberados ou excluídos/reimportados após o 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 neste contexto não se referem a conflitos de arquivo, 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. Este é o comportamento predefinido.
• Permitir erros: o trabalho de importação continua se ocorrer um erro e o erro for registrado. Após a conclusão do trabalho de importação, você poderá exibir erros no contêiner de registro.

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

Os seguintes itens são importantes a serem considerados ao importar dados de um contêiner de blob:

• Apenas uma ação de importação ou exportação pode ser executada de cada 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. Você pode 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 de 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 ao /lustre/IMPORT_<state>.<timestamp_start> é criado no diretório raiz do Lustre durante a importação. O <state> espaço reservado muda à medida que a importação progride. O arquivo é excluído quando o trabalho de importação é concluído com êxito.
• Para exibir detalhes sobre um trabalho de importação concluído, você pode verificar o contêiner de registro. O contêiner de log contém logs para o trabalho de importação, incluindo quaisquer erros ou conflitos que ocorreram 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 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 eles sejam acessados pela primeira vez. Você pode optar por pré-buscar o conteúdo dos blobs para evitar o atraso inicial quando o blob é acessado pela primeira vez após a importação. Para pré-buscar o conteúdo de blobs, você pode usar o comando do lfs hsm_restore Lustre de um cliente montado com recursos sudo. O comando a seguir fará a pré-busca do conteúdo dos blobs no sistema de arquivos:

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

Este 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 que a restauração seja concluída, o que significa que a linha de comando tem o potencial de enfileirar um grande número de entradas para restauração no servidor de metadados. Essa abordagem pode sobrecarregar o servidor de metadados e degradar 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 alcançar um desempenho razoável e evitar sobrecarregar o servidor de metadados, recomenda-se usar tamanhos de lote de 1.000 a 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 nomeado file_restorer.bash com o seguinte conteúdo:

#!/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 saída de exemplo:

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

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

Você pode copiar dados do seu sistema de arquivos Azure Managed Lustre 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 Azure Managed Lustre, nem todos os arquivos são copiados para o contêiner de blob que você especificou quando criou o sistema de arquivos. As seguintes regras aplicam-se aos postos de trabalho de exportação:

• Os trabalhos de exportação copiam apenas arquivos novos ou cujo conteúdo é modificado. Se o arquivo importado 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 ficheiros apenas com alterações de metadados não são exportados. As alterações de metadados incluem: proprietário, permissões, atributos estendidos e alterações de nome (renomeadas).
• Os arquivos excluídos no sistema de arquivos do Azure Managed Lustre 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.

Executando trabalhos de exportação em sistemas de arquivos ativos

Em sistemas de arquivos ativos, alterações em 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 no sistema de arquivos podem ser exportados para o Armazenamento de Blobs. Nessa situação, você pode tentar novamente a exportação criando 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 novas 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 Blob, verifique o carimbo de data/hora no blob correspondente. Após a conclusão do trabalho, você também pode exibir o contêiner de log configurado no momento da implantação para ver informações detalhadas sobre o trabalho de exportação. O contêiner de log fornece informações de diagnóstico sobre quais arquivos falharam e por que eles falharam.

Se você estiver se preparando para encerrar um cluster e quiser executar 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 ajuda a garantir que todos os dados sejam exportados, evitando erros devido à atividade do sistema de arquivos.

Metadados para ficheiros exportados

Quando os arquivos são exportados do sistema de arquivos do Azure Managed Lustre 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 de blob como pares chave-valor:

Os atributos de diretório são salvos em um blob vazio. Esse blob tem o mesmo nome que o 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 chave-valor descritos anteriormente.

Considerações para trabalhos de exportação

Os seguintes itens são importantes a considerar ao exportar dados com um trabalho de exportação:

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

Copiar um contêiner de blob Lustre com AzCopy ou Storage Explorer

Você pode mover ou copiar o contêiner de blob que o Lustre usa usando o AzCopy ou o Storage Explorer.

Para 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, groupe permissions. Se você usar azcopy no contêiner de armazenamento sem esse sinalizador ou com o sinalizador definido como false, os dados e diretórios serão incluídos na transferência, mas os diretórios não reterão seus atributos POSIX.

No Gerenciador de Armazenamento, você pode habilitar esse sinalizador em Configurações selecionando Transferências e marcando a caixa para Incluir Stubs de Diretório.

Próximos passos

• Pré-requisitos para integração de armazenamento de blob
• Criar um trabalho de importação do Armazenamento de Blob para o Azure Managed Lustre
• Criar um trabalho de exportação para exportar dados do Azure Managed Lustre