Como funciona a sincronização

O S3 Files mantém automaticamente a sincronia entre o sistema de arquivos e o bucket do S3 vinculado. Os dados usados ativamente são copiados para o sistema de arquivos para que você possa ler e gravar arquivos usando com baixa latência operações de arquivo padrão do Linux. O S3 Files exige a habilitação do Versionamento do S3 no bucket do S3 vinculado. Ao editar arquivos no sistema de arquivos, o S3 Files copia suas alterações de volta para o bucket do S3 como novas versões dos objetos correspondentes, garantindo que as versões antigas sejam preservadas. Quando outras aplicações adicionam, modificam ou excluem objetos no bucket do S3, o S3 Files reproduz automaticamente essas alterações no sistema de arquivos. Quando ocorre um conflito devido a alterações simultâneas nos mesmos dados no sistema de arquivos e no bucket do S3, o S3 Files trata o bucket do S3 como a fonte de referência em caso de conflitos.

Para otimizar os custos de armazenamento, o S3 Files remove os dados não utilizados recentemente do sistema de arquivos. Os dados permanecerão armazenados de forma durável no bucket do S3 vinculado e serão recuperados no sistema de arquivos na próxima vez em que forem acessados.

O bucket do S3 pode ser acessado por meio do sistema de arquivos

Depois de criar um sistema de arquivos do S3, você pode montar os buckets do S3 nos recursos de computação e começar a acessar os dados do bucket do S3 imediatamente. Por padrão, quando você acessa um diretório pela primeira vez listando o respectivo conteúdo ou abrindo um arquivo dentro dele, o S3 Files importa os metadados de todos os arquivos desse diretório, bem como os dados de arquivos menores que o limite de tamanho de importação (cujo padrão é 128 KiB) do bucket do S3. O primeiro acesso a um diretório pode ter maior latência, mas as leituras e gravações subsequentes são significativamente mais rápidas. Ao importar metadados antecipadamente, o S3 Files oferece baixa latência para examinar o conteúdo do diretório, visualizar o tamanho dos arquivos e verificar as permissões.

Por exemplo, suponha que o bucket do S3 contenha um prefixo data/images/ com mil objetos. Na primeira vez em que você executa ls /mnt/s3files/data/images/, o S3 Files importa metadados de todos os mil arquivos e copia de forma assíncrona os dados dos arquivos com tamanho inferior ao limite de tamanho de importação para o sistema de arquivos. Essa listagem inicial pode levar alguns segundos, mas os comandos subsequentes, como ls -la, stat ou cat, em arquivos individuais nesse diretório, respondem com baixa latência.

Com relação a arquivos maiores que o limite de tamanho de importação, o S3 Files importa somente metadados, e os dados não são copiados para o sistema de arquivos, mas lidos diretamente do bucket do S3 quando acessados. É possível ajustar esse limite para que ele corresponda melhorar à sua workload. Por exemplo, você pode aumentá-lo para importar mais dados antecipadamente para workloads que acessam repetidamente os mesmos arquivos e se beneficiar de leituras de baixa latência. Para workloads que fazem streaming de dados sequencialmente, um limite mais baixo pode ser mais econômico, pois o benefício da latência da importação de dados antecipada é menos significativo quando os dados são lidos sequencialmente em grandes blocos em vez de em blocos pequenos e aleatórios. Para obter mais informações, consulte Personalizar a sincronização para o S3 Files.

As alterações no sistema de arquivos são reproduzidas automaticamente no bucket do S3

Quando arquivos no sistema de arquivos são criados, modificados ou excluídos, o S3 Files copia automaticamente essas alterações para o bucket do S3. Os novos arquivos se tornam novos objetos do S3, as alterações nos arquivos existentes se tornam novas versões do objeto e os arquivos excluídos se tornam marcadores de exclusão do S3.

As permissões POSIX definidas em arquivos e diretórios por meio do sistema de arquivos, como proprietário (UID), grupo (GID) e bits de permissão, são armazenadas como metadados de objetos do S3 definidos pelo usuário nos objetos correspondentes do S3. Quando as permissões são alteradas por meio de chmod, chown ou chgrp, o S3 Files exporta essas alterações, bem como quaisquer alterações nos dados, para o bucket do S3. Quando o S3 Files importa objetos do bucket do S3, ele lê esses metadados e aplica as permissões POSIX correspondentes no sistema de arquivos. Os objetos que não têm metadados de permissão POSIX recebem permissões padrão.

Quando um arquivo no sistema de arquivos é modificado, o S3 Files espera até 60 segundos, agregando todas as alterações sucessivas no arquivo nesse período, para só então copiá-las para o bucket do S3. Isso significa que gravações rápidas e sucessivas no mesmo arquivo são capturadas em uma única solicitação PUT do S3, em vez de gerar uma nova versão do objeto para cada alteração individual, o que reduz os custos de solicitação do S3 e os custos de armazenamento. Se você continuar modificando o arquivo depois que o S3 Files copiar suas alterações de volta para o bucket do S3, ele copiará as alterações subsequentes conforme necessário.

Por exemplo, se uma aplicação abrir um arquivo de log e anexá-lo 50 vezes em 30 segundos, o S3 Files agrupará todos os 50 anexos em uma única solicitação PUT do S3. Se a aplicação continuar gravando após a primeira sincronização, o S3 Files copiará as alterações adicionais em uma sincronização subsequente.

As alterações no bucket do S3 aparecem automaticamente no sistema de arquivos

O S3 Files monitora as alterações no bucket do S3 usando as notificações de eventos do S3. Quando outra aplicação que está trabalhando com a API do S3 adiciona, modifica ou exclui objetos no bucket do S3, o S3 Files reproduz automaticamente essas alterações no sistema de arquivos para arquivos cujos dados estão armazenados no momento no armazenamento de alta performance do sistema de arquivos. Os arquivos cujos dados expiraram no sistema de arquivos somente serão atualizados na próxima vez em que forem acessados. Nesse momento, o S3 Files recuperará a versão mais recente do bucket do S3.

Noções básicas sobre o impacto das operações de renomeação e movimentação

O Amazon S3 usa uma estrutura de armazenamento não hierárquica na qual os objetos são identificados pelo nome das respectivas chaves. Embora o S3 Files permita organizar os dados em diretórios, o S3 não tem um conceito nativo de diretórios. O que aparece como um diretório no sistema de arquivos é um prefixo comum compartilhado pelas chaves dos objetos no bucket do S3. Além disso, os objetos do S3 são imutáveis e não permitem renomeações atômicas. Por isso, quando um arquivo é renomeado ou movido, o S3 Files precisa gravar os dados em um novo objeto com a chave atualizada e excluir o original. Quando um diretório e renomeado ou movido, o S3 Files precisa repetir esse processo para cada objeto que compartilha esse prefixo. Portanto, quando você renomeia ou move um diretório que contém dezenas de milhões de arquivos, os custos de solicitação do S3 e o tempo de sincronização aumentam significativamente.

O S3 Files exibe um erro quando você tenta criar um sistema de arquivos com escopo para um prefixo com um grande número de objetos, em que a renomeação pode levar até 4 horas (em torno de 12 milhões de objetos, no máximo). Esse erro alerta que grandes operações recursivas de renomeação ou movimentação podem afetar o desempenho do sistema de arquivos, pois cada arquivo exige solicitações separadas de gravação e exclusão para o bucket do S3. Se você ainda quiser criar um sistema de arquivos com escopo para esse prefixo, é possível adicionar o parâmetro --AcceptBucketWarning.

Como o S3 Files renomeia objetos individualmente no bucket do S3, os dois diretórios ficarão visíveis no bucket do S3 enquanto a renomeação não for totalmente concluída. Os objetos gravados após a renomeação do diretório, mas antes da sincronização total da renomeação, não serão movidos. Para simplificar o trabalho de reorganização de dados, é recomendável não criar objetos por meio do bucket do S3 ao renomear um diretório correspondente.

Por exemplo, se você executar mv /mnt/s3files/projects/alpha /mnt/s3files/projects/beta, a renomeação será concluída imediatamente no sistema de arquivos. No bucket do S3, o S3 Files começa a copiar e excluir cada objeto na nova chave dentro do bucket do S3 (substituindo o prefixo projects/alpha/ por projects/beta/) e excluindo o original. Durante esse processo, o bucket do S3 retém temporariamente os objetos em projects/alpha/ e projects/beta/. Depois que todos os objetos forem movidos, só projects/beta/ permanecerá.

Os dados não utilizados expiram do sistema de arquivos para otimizar o armazenamento

O S3 Files otimiza os custos de armazenamento removendo automaticamente do sistema de arquivos os dados que não foram lidos recentemente. Os dados permanecem armazenados com segurança no bucket do S3. O S3 Files remove somente a cópia do sistema de arquivos. Os metadados de arquivo, como nomes, tamanhos e permissões, nunca são removidos do sistema de arquivos para que você possa continuar navegando com baixa latência no sistema de arquivos.

Se um arquivo no sistema de arquivos não tiver sido lido por trinta dias (configurável) e as respectivas alterações já tiverem sido sincronizadas com o bucket do S3, o S3 Files removerá os dados do arquivo do sistema de arquivos. Na próxima vez em que esse arquivo for lido, o S3 Files recuperará a versão mais recente do objeto correspondente do bucket do S3 e a copiará de volta para o sistema de arquivos.

Por exemplo, suponha que você processe um conjunto de dados em /mnt/s3files/data/batch-jan.parquet em janeiro e não o acesse novamente. Após trinta dias, o S3 Files removerá os dados do arquivo do sistema de arquivos. O arquivo ainda aparecerá nas listagens de diretórios com o tamanho correto e as devidas permissões, mas os dados não estarão mais no sistema de arquivos. Quando o arquivo for lido novamente em abril, o S3 Files o recuperará do bucket do S3 e o copiará de volta para o sistema de arquivos. A primeira leitura poderá ter maior latência, mas as leituras subsequentes serão rápidas.

O bucket do S3 é a fonte de referência em caso de conflitos

Um conflito ocorre quando o mesmo arquivo é modificado por meio do sistema de arquivos e o objeto do S3 correspondente também é alterado antes de o S3 Files sincronizar as alterações do sistema de arquivos de volta para o bucket do S3. Por exemplo, é possível editar um arquivo por meio do sistema de arquivos montado enquanto outra aplicação carrega uma nova versão do objeto correspondente ou a exclui diretamente no bucket vinculado do S3.

O S3 Files detecta conflitos quando tenta sincronizar as alterações do sistema de arquivos com o bucket do S3 ou quando recebe uma notificação de evento do S3 indicando que o objeto foi alterado. Como o bucket do S3 serve como armazenamento de longo prazo para os dados, o S3 Files o considera o bucket do S3 como a fonte de referência quando ocorre um conflito. Isso oferece consistência previsível, garantindo que a versão no bucket do S3 sempre tenha precedência. Em caso de conflito, o S3 Files move o arquivo conflitante do local atual no sistema de arquivos para um diretório de achados e perdidos e importa a versão mais recente do bucket vinculado do S3 para o sistema de arquivos.

Por exemplo, suponha que você edite /mnt/s3files/report.csv por meio do sistema de arquivos. Antes de o S3 Files sincronizar as alterações de volta para o bucket do S3, outra aplicação carregará uma nova versão do report.csv diretamente no bucket do S3. Quando o S3 Files detectar o conflito, ele moverá a versão do report.csv para o diretório de achados e perdidos e a substituirá pela versão do bucket do S3.

O diretório de achados e perdidos está localizado no diretório raiz do sistema de arquivos, abaixo do nome .s3files-lost+found-file-system-id. Se você montar o sistema de arquivos por meio de um ponto de acesso que especifica um diretório raiz, o diretório de achados e perdidos não ficará visível nessa montagem porque está localizado acima do diretório raiz do ponto de acesso. Para acessar o diretório de achados e perdidos, monte o sistema de arquivos sem um ponto de acesso ou use um ponto de acesso sem uma restrição de diretório raiz para que possa acessar o escopo completo do sistema de arquivos por meio do ponto de acesso.

Quando o S3 Files move um arquivo para o diretório de achados e perdidos, ele acrescenta ao nome do arquivo um identificador para distinguir várias versões do mesmo arquivo que podem ser movidas ao longo do tempo. Os arquivos no diretório de achados e perdidos não são copiados para o bucket do S3. É possível excluir e copiar arquivos desse diretório, mas não mover ou renomear arquivos dentro dele nem excluir o próprio diretório. Se você quiser manter as alterações do sistema de arquivos em vez da versão mais recente no bucket do S3, copie o arquivo do diretório de achados e perdidos de volta para o caminho original. É possível recuperar o caminho original do arquivo com base nos atributos estendidos do arquivo no diretório de achados e perdidos. Em seguida, o S3 Files o copiará para o bucket do S3 como uma nova versão do objeto. Para obter mais informações, consulte Solução de problemas do S3 Files.

As configurações de sincronização padrão funcionarão para a maioria das workloads para acesso baseado em arquivos de baixa latência aos dados do S3. Para ver mais detalhes sobre como configurar esses parâmetros, consulte Personalizar a sincronização para o S3 Files.