Comportamento do sistema de ficheiros

Em última análise, o Azure Container Storage habilitado pelo Azure Arc fornece uma interface de sistema de ficheiros para as aplicações. Os sistemas de ficheiros têm comportamentos específicos para os quais as aplicações devem ser projetadas para gerir. Este artigo explica como as alterações ao sistema de ficheiros partilhados se propagam e o que acontece a um sistema de ficheiros espelhado durante a sincronização espelhada.

O que queremos dizer com interface de sistema de ficheiros?

Uma aplicação pode aceder a muitos sistemas de ficheiros na sua estrutura de pastas através de mounts. No Kubernetes, as aplicações (pods) configuram os suportes usando PVCs. Quando um pod é montado com um PVC EdgeVolume, tem acesso a um sistema de ficheiros partilhado através de uma pasta montada.

Veja este guia, por exemplo, para configurar um PVC para o volume de suporte na cloud da nossa extensão. Um sistema de ficheiros montado com um PVC EdgeVolume tem um componente local e um remoto. O sistema de ficheiros local recebe as operações do sistema de ficheiros da aplicação. Encaminha as operações do sistema de ficheiros para o componente remoto que tem acesso ao armazenamento subjacente.

Propagação de alterações e cache local

Vários pods de um nó qualquer do cluster podem montar a mesma pasta partilhada do EdgeVolume. Dentro desta pasta, as escritas de um pod são legíveis a partir de outros pods. Se houver pods em nós separados que estão a montar a mesma pasta partilhada, as alterações podem demorar algum tempo a serem propagadas. Ficheiros e pastas novos ou removidos podem demorar até 60 segundos a propagar-se. As escritas de ficheiros podem demorar até 30 segundos a propagar-se.

A razão para estes atrasos deve-se aos tempos de invalidação da cache do lado do cliente. Quando o pod faz uma operação de leitura no sistema de ficheiros local, pode usar uma cache local e nunca fazer uma chamada de rede. As entradas de cache que utiliza acabam por expirar, por isso, assim que a cache relevante expira, o sistema de ficheiros do pod relê a informação pela rede. Neste ponto, o sistema de ficheiros local extrai os metadados e conteúdos mais recentes dos ficheiros.

As sequências de operações de ficheiro que envolvem abrir o ficheiro, ler e depois fechar o ficheiro (ao contrário dos ficheiros abertos de longa duração) leem sempre o conteúdo mais recente do ficheiro. Quando o sistema de ficheiros do pod local processa uma chamada aberta, vai diretamente para o servidor para verificar se o ficheiro mudou.

Espelhar o comportamento do sistema de ficheiros

Quando ocorre uma sincronização de espelho, uma aplicação interna executa-se para detetar e realizar operações no sistema de ficheiros para sincronizar o sistema de ficheiros perimetral para corresponder a um alvo de blob. A configuração do subvolume espelhado é descrita neste artigo.

As operações que podem ser realizadas para completar uma sincronização espelhada enquadram-se nas seguintes categorias:

• Criar novos ficheiros ou pastas para corresponder a blobs recém-criados.
• Remover ficheiros ou pastas existentes para corresponder aos blobs removidos.
• Modificar ficheiros existentes para corresponder a blobs modificados, descarregando o novo blob e renomeando-o sobre o ficheiro antigo.
• Modificar metadados de ficheiros ou pastas: proprietário, grupo, permissões e xattrs com base nas alterações de metadados no blob.

Quando a aplicação interna realiza estas operações, faz-no diretamente no sistema de ficheiros subjacente. Eventualmente, as alterações chegam aos pods de clientes que lêem o sistema de ficheiros. Uma vez feita uma alteração no sistema de ficheiros interno, pode demorar até 30 segundos para que as alterações em ficheiros sejam feitas ou 60 segundos para que os ficheiros criados ou removidos se propaguem para os pods de clientes.

Como as sincronizações de modificação de blob são implementadas usando renomeações com o conteúdo completo dos ficheiros, as aplicações nunca veem ficheiros parcialmente sincronizados. Ou veem o conteúdo do ficheiro antigo ou o conteúdo do ficheiro novo.

No entanto, as alterações de metadados são aplicadas diretamente ao ficheiro ou pasta visível do cliente. Isto significa que é possível ver metadados parcialmente sincronizados (proprietário, grupo, permissões ou xattrs).