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

Artigo
11/11/2024

O Azure Managed Lustre integra-se ao 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 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 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 são importados, você pode trabalhar com os dados da mesma forma que 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 do Lustre Gerenciado do Azure, somente os nomes de arquivo (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 ao acessar os dados pela primeira vez enquanto o recurso HSM (Gerenciamento de Armazenamento Hierárquico) do Lustre efetua pull do conteúdo do blob para o arquivo correspondente no sistema de arquivos.

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

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. As seguintes pequenas diferenças se aplicam:

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

Importar do Armazenamento de Blobs

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 blobs 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 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 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. Você não pode alterar o prefixo de importação depois que o cluster é criado.

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 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.

Lembre-se das 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 não deverã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 no 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 especificada como o prefixo de importação, esse arquivo ficará 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:

Mode	Descrição
`fail`	O trabalho de importação falhará imediatamente com um erro se um conflito for detectado.
`skip`	O trabalho de importação ignora o arquivo se um conflito for detectado.
`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 overwrite-dirty.
`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 o modo de substituição sempre.

Modo de substituiçã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 em sincronia 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 Sobrescrever 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, pois todos os arquivos restaurados anteriormente são liberados ou excluídos/reimportados no primeiro acesso.

Tolerância a erros

Ao importar dados de um contêiner de blob, você pode especificar a tolerância ao erro. 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 arquivo, que são tratados pelo modo de resolução de conflitos.

As seguintes opções de tolerância de erro 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 é o comportamento padrão.
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 log.

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

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

Apenas 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. 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 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 <state> espaço reservado muda à medida que a importação avança. 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 log. O contêiner de log contém logs 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 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 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 Lustre lfs hsm_restore 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 &

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 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 obter um desempenho razoável e evitar sobrecarregar o servidor de metadados, é recomendável 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 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 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

Observação

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

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

Você pode copiar dados do sistema de arquivos do 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 sistema Azure Managed Lustre, nem todos os arquivos são copiados para o contêiner de blob especificado ao criar o sistema de arquivos. As seguintes regras se aplicam aos 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 apenas 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 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 no sistema de arquivos podem ser exportados para o Armazenamento de Blobs. Nessa situação, você pode repetir 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 Blobs, 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, verifique se todas as atividades de E/S foram 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 arquivos 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:

Atributo POSIX	Tipo
`owner`	INT
`group`	INT
`permissions`	formato octal ou rwxrwxrwx; O bocado pegajoso é suportado

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 sobre trabalhos de exportação

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

Apenas uma ação de importação ou exportação pode ser executada por 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 do Lustre com o AzCopy ou o Gerenciador de Armazenamento

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

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 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 selecionando Transferências e marcando a caixa Incluir Stubs de Diretório.

Compartilhar via