Conformidade com POSIX

A seguir, confira as exceções à conformidade com POSIX do Managed Lustre do Google Cloud:

  • Atualizações de atime: por padrã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, com suporte a bloqueios de intervalo de bytes. A implementação de bloqueios fcntl do Lustre é quase compatível com POSIX e funciona como esperado para a maioria dos aplicativos. No entanto, como fcntl foi originalmente projetado para sistemas de arquivos locais, nenhum sistema de arquivos distribuído pode corresponder 100% a todos os requisitos 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 atrasada se o cliente falhar.

Consulte as perguntas frequentes do Lustre para mais detalhes.

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

O número de 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 um novo 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 suposições de muitos aplicativos e serviços comuns do Unix/Linux criados para esperar um número de inode persistente durante a vida útil de um arquivo. Isso inclui, mas não se limita a:

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

  • Utilitários de arquivamento e backup: ferramentas como tar que rastreiam arquivos pelo dispositivo + número de inode podem tratar um arquivo migrado como um novo, levando a 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 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 disruptivo.

  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 de lfs migrate em grande escala em um sistema de produção ativo.

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

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