Conformidade com POSIX

As seguintes são exceções à conformidade com POSIX do Google Cloud Managed Lustre:

  • Atualizações do atime: por padrão, o atime está ativado no Lustre, mas, por motivos de desempenho, as atualizações podem ser adiadas. Isso significa que o tempo de acesso de um arquivo pode não ser atualizado imediatamente após cada operação de leitura.

  • flock/lockf: referem-se a duas APIs principais de bloqueio de arquivos: flock(2) e fcntl(2).

    • flock: um bloqueio consultivo de arquivo inteiro no estilo BSD que não é definido pelo POSIX. O Lustre oferece suporte total à semântica flock no estilo BSD em todo o cluster por padrão.
    • fcntl: é a API de bloqueio definida pelo POSIX, que oferece suporte a bloqueios de intervalo de bytes. A implementação do Lustre de bloqueios fcntl é quase compatível com POSIX e funciona como esperado para a maioria dos aplicativos. No entanto, como o fcntl foi originalmente projetado para sistemas de arquivos locais, nenhum sistema de arquivos distribuído pode corresponder 100% a todos os requisitos de fcntl do POSIX, incluindo o Lustre. Por exemplo, fcntl() especifica que os bloqueios precisam ser liberados imediatamente quando o processo proprietário é encerrado, mas a liberação de bloqueio do Lustre pode ser adiada se o cliente falhar.

Consulte as perguntas frequentes do Lustre para mais detalhes.

Mudanças no número do inode devido à migração de metadados

O número do inode de um arquivo em um sistema de arquivos Lustre não é um identificador imutável.

Uma operação de rebalanceamento de metadados, como uma iniciada por lfs migrate, envolve a migração de metadados de alguns arquivos de um MDT para outro. Como consequência direta dessa migração para uma nova MDT, esses arquivos recebem um novo número de inode.

Embora esse comportamento esteja em conformidade com o padrão POSIX, ele pode violar as premissas de muitos aplicativos e serviços comuns do Unix/Linux criados para esperar um número de inode persistente durante o ciclo de vida de um arquivo. Isso inclui, mas não se limita a:

  • Front-ends NFS e SMB: esses serviços geralmente derivam identificadores de arquivo de números de inode. Uma mudança pode causar erros Stale file handle para os clientes.

  • Utilitários de arquivamento e backup: ferramentas como o tar, que rastreiam arquivos pelo dispositivo e pelo número do inode, podem tratar um arquivo migrado como um novo arquivo, resultando em backups incrementais ineficientes.

  • Agregadores de registros, sistemas de detecção de intrusões e aplicativos personalizados que usam stat() e armazenam st_ino também podem ser afetados.

Os administradores precisam estar cientes desse comportamento e do possível impacto dele nos aplicativos antes de iniciar qualquer rebalanceamento manual de metadados.

Estratégias de mitigação

O rebalanceamento de metadados precisa ser tratado como um evento de manutenção planejado e destrutivo.

  1. Programe uma janela de manutenção. Comunique uma interrupção planejada a todos os usuários e proprietários de aplicativos. Se possível, não realize operações lfs migrate em grande escala em um sistema de produção ativo.

  2. Se necessário, desconecte e reconecte o sistema de arquivos após a migração.

  3. Alguns aplicativos podem precisar ser liberados ou reiniciados após uma migração.