23 Sistema de arquivos em cluster #

Se o host de cliente executa o SUSE Linux Enterprise 12 SP2 ou versão mais recente, o sistema está pronto para montar o CephFS “out-of-the-box”.

Se o host de cliente executa o SUSE Linux Enterprise 12 SP1, você precisa aplicar todos os patches mais recentes antes de montar o CephFS.

Em qualquer caso, tudo o que é preciso para montar o CephFS está incluído no SUSE Linux Enterprise. O produto SUSE Enterprise Storage 7 não é necessário.

Para suportar a sintaxe completa de mount, o pacote ceph-common (que é fornecido com o SUSE Linux Enterprise) deve ser instalado antes de tentar montar o CephFS.

Importante

Sem o pacote ceph-common (e, portanto, sem o ajudante mount.ceph), os IPs dos monitores precisarão ser usados em vez dos nomes. O motivo é que o cliente do kernel não poderá executar a resolução de nome.

A sintaxe de montagem básica é:

root # mount -t ceph MON1_IP[:PORT],MON2_IP[:PORT],...:CEPHFS_MOUNT_TARGET \
MOUNT_POINT -o name=CEPHX_USER_NAME,secret=SECRET_STRING

Por padrão, o cluster do Ceph é executado com a autenticação ativada. Você deve criar um arquivo que armazena sua chave secreta (não o chaveiro propriamente dito). Para obter a chave secreta para determinado usuário e, em seguida, criar o arquivo, faça o seguinte:

Você pode montar o CephFS com o comando mount. Você precisa especificar o nome de host ou endereço IP do monitor. Como a autenticação cephx está habilitada por padrão no SUSE Enterprise Storage, você precisa especificar um nome de usuário e também o segredo relacionado:

root # mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \
 -o name=admin,secret=AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==

Como o comando anterior permanece no histórico do shell, uma abordagem mais segura é ler o segredo de um arquivo:

root # mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \
 -o name=admin,secretfile=/etc/ceph/admin.secret

Observe que o arquivo de segredo deve conter apenas o segredo do chaveiro real. Em nosso exemplo, o arquivo incluirá apenas a seguinte linha:

AQATSKdNGBnwLhAAnNDKnH65FmVKpXZJVasUeQ==

Dica: Especificar vários monitores

Convém especificar vários monitores separados por vírgulas na linha de comando mount para o caso de um monitor ficar inativo no momento da montagem. Cada endereço de monitor adota o formato host[:porta]. Se a porta não for especificada, será usado o padrão 6789.

Crie o ponto de montagem no host local:

root # mkdir /mnt/cephfs

Monte o CephFS:

root # mount -t ceph ceph_mon1:6789:/ /mnt/cephfs \
 -o name=admin,secretfile=/etc/ceph/admin.secret

Um subdiretório subdir poderá ser especificado se um subconjunto do sistema de arquivos tiver que ser montado:

root # mount -t ceph ceph_mon1:6789:/subdir /mnt/cephfs \
 -o name=admin,secretfile=/etc/ceph/admin.secret

Você pode especificar mais de um host de monitor no comando mount:

root # mount -t ceph ceph_mon1,ceph_mon2,ceph_mon3:6789:/ /mnt/cephfs \
 -o name=admin,secretfile=/etc/ceph/admin.secret

Importante: acesso de leitura ao diretório raiz

Se forem usados clientes com restrição de caminho, os recursos do MDS precisarão incluir o acesso de leitura ao diretório raiz. Por exemplo, um chaveiro pode ter a seguinte aparência:

client.bar
 key: supersecretkey
 caps: [mds] allow rw path=/barjail, allow r path=/
 caps: [mon] allow r
 caps: [osd] allow rwx

A parte allow r path=/ indica que os clientes com restrição de caminho podem ver o volume raiz, mas não podem gravar nele. Isso pode ser um problema para casos de uso em que o isolamento completo é um requisito.

Considere o uso de vários daemons MDS ativos em caso de gargalo no desempenho dos metadados no MDS único padrão.

A adição de mais daemons não aumenta o desempenho em todos os tipos de carga de trabalho. Por exemplo, um único aplicativo em execução em um só cliente não se beneficiará de um número maior de daemons MDS, a menos que o aplicativo esteja efetuando muitas operações de metadados em paralelo.

As cargas de trabalho que costumam se beneficiar de um número maior de daemons MDS ativos são aquelas com vários clientes, que podem atuar em muitos diretórios separados.

Cada sistema de arquivos CephFS tem uma configuração max_mds que controla quantas classificações serão criadas. O número real de classificações no sistema de arquivos apenas será aumentado se um daemon sobressalente estiver disponível para assumir a nova classificação. Por exemplo, se houver apenas um daemon MDS em execução, e max_mds estiver definido como dois, não será criada uma segunda classificação.

No exemplo a seguir, definimos a opção max_mds como 2 para criar uma nova classificação separadamente do padrão. Para ver as mudanças, execute ceph status antes e depois que você definir max_mds e observe a linha que contém fsmap:

cephuser@adm > ceph status
  [...]
  services:
    [...]
    mds: cephfs-1/1/1 up  {0=node2=up:active}, 1 up:standby
    [...]
cephuser@adm > ceph fs set cephfs max_mds 2
cephuser@adm > ceph status
  [...]
  services:
    [...]
    mds: cephfs-2/2/2 up  {0=node2=up:active,1=node1=up:active}
    [...]

A classificação recém-criada (1) passa pelo estado de “criação” e depois entra no estado “ativo”.

Importante: Daemons de standby

Mesmo com vários daemons MDS ativos, um sistema altamente disponível ainda requer daemons de standby para assumir o controle em caso de falha em qualquer um dos servidores que executam um daemon ativo.

Consequentemente, o limite máximo ideal de max_mds para sistemas de alta disponibilidade é menor do que o número total de servidores MDS no sistema. Para se manter disponível em caso de várias falhas do servidor, aumente o número de daemons de standby no sistema para corresponder ao número de falhas do servidor que você precisa superar.

Todas as classificações, incluindo as que devem ser removidas, devem primeiro estar ativas. Isso significa que é necessário ter pelo menos max_mds daemons MDS disponíveis.

Primeiramente, defina max_mds como um número mais baixo. Por exemplo, volte a ter um único MDS ativo:

cephuser@adm > ceph status
  [...]
  services:
    [...]
    mds: cephfs-2/2/2 up  {0=node2=up:active,1=node1=up:active}
    [...]
cephuser@adm > ceph fs set cephfs max_mds 1
cephuser@adm > ceph status
  [...]
  services:
    [...]
    mds: cephfs-1/1/1 up  {0=node2=up:active}, 1 up:standby
    [...]

Em várias configurações de servidor de metadados ativas, um balanceador é executado, que funciona para distribuir a carga de metadados igualmente no cluster. Em geral, isso funciona bem o suficiente para a maioria dos usuários; mas, às vezes, convém anular o balanceador dinâmico com mapeamentos explícitos de metadados para classificações específicas. Isso pode permitir que o administrador ou os usuários distribuam a carga do aplicativo igualmente ou limitem o impacto das solicitações de metadados dos usuários sobre o cluster inteiro.

O mecanismo fornecido para essa finalidade é chamado “export pin”. Ele é um atributo estendido de diretórios. O nome desse atributo estendido é ceph.dir.pin. Os usuários podem definir esse atributo usando os comandos padrão:

root # setfattr -n ceph.dir.pin -v 2 /path/to/dir

O valor (-v) do atributo estendido é a classificação à qual atribuir a subárvore do diretório. O valor padrão -1 indica que o diretório não foi fixado.

O export pin de um diretório é herdado do seu pai mais próximo com um export pin definido. Portanto, a definição do export pin em um diretório afeta todos os seus filhos. No entanto, a fixação do pai pode ser anulada pela definição do export pin do diretório filho. Por exemplo:

root # mkdir -p a/b                      # "a" and "a/b" start with no export pin set.
setfattr -n ceph.dir.pin -v 1 a/  # "a" and "b" are now pinned to rank 1.
setfattr -n ceph.dir.pin -v 0 a/b # "a/b" is now pinned to rank 0
                                  # and "a/" and the rest of its children
                                  # are still pinned to rank 1.

Cada sistema de arquivos CephFS pode ser configurado para adicionar daemons de reprodução de standby. Esses daemons de standby seguem o diário de metadados do MDS ativo para reduzir o tempo de failover caso o MDS ativo se torne indisponível. Cada MDS ativo pode ter apenas um daemon de reprodução de standby o seguindo.

Configure a reprodução de standby em um sistema de arquivos com o seguinte comando:

cephuser@adm > ceph fs set FS-NAME allow_standby_replay BOOL

Quando definidos, os monitores atribuirão os daemons de standby disponíveis para seguir os MDSs ativos nesse sistema de arquivos.

Depois que um MDS entrar no estado de reprodução de standby, ele apenas será usado como standby para a classificação que está seguindo. Se houver falha em outra classificação, esse daemon de reprodução de standby não será usado como substituição, mesmo que não haja outros standbys disponíveis. Por esse motivo, se a reprodução de standby for usada, será aconselhável que cada MDS ativo tenha um daemon de reprodução de standby.

O uso de cotas com o CephFS tem as seguintes limitações:

Você pode configurar cotas do CephFS usando atributos estendidos virtuais:

Se os atributos aparecerem no inode de um diretório, uma cota será configurada nele. Se eles não estiverem presentes, nenhuma cota será definida nesse diretório (embora uma ainda possa ser configurada em um diretório pai).

Para definir uma cota de 100 MB, execute:

cephuser@mds > setfattr -n ceph.quota.max_bytes -v 100000000 /SOME/DIRECTORY

Para definir uma cota de 10.000 arquivos, execute:

cephuser@mds > setfattr -n ceph.quota.max_files -v 10000 /SOME/DIRECTORY

Para ver a configuração de cota, execute:

cephuser@mds > getfattr -n ceph.quota.max_bytes /SOME/DIRECTORY

cephuser@mds > getfattr -n ceph.quota.max_files /SOME/DIRECTORY

Nota: Cota não definida

Se o valor do atributo estendido for “0”, a cota não será definida.

Para remover uma cota, execute:

cephuser@mds > setfattr -n ceph.quota.max_bytes -v 0 /SOME/DIRECTORY
cephuser@mds > setfattr -n ceph.quota.max_files -v 0 /SOME/DIRECTORY

Por padrão, o recurso de instantâneo do CephFS está habilitado nos sistemas de arquivos novos. Para habilitá-lo nos sistemas de arquivos existentes, execute:

cephuser@adm > ceph fs set CEPHFS_NAME allow_new_snaps true

Após a habilitação dos instantâneos, todos os diretórios no CephFS terão um subdiretório .snap especial.

Nota

Este é um subdiretório virtual. Ele não aparece na listagem de diretórios do diretório pai, mas o nome .snap não pode ser usado como nome de arquivo ou diretório. O diretório .snap precisa ser acessado explicitamente, por exemplo:

tux > ls -la /CEPHFS_MOUNT/.snap/

Importante: limitação de clientes do kernel

Os clientes do kernel do CephFS têm uma limitação: eles não podem processar mais do que 400 instantâneos em um sistema de arquivos. O número de instantâneos deve ser mantido sempre abaixo desse limite, seja qual for o cliente que você usa. Se você usa clientes CephFS mais antigos, como SLE12-SP3, lembre-se de que ultrapassar 400 instantâneos é prejudicial para as operações, porque haverá falha no cliente.

Dica: Nome personalizado do subdiretório de instantâneos

Você pode configurar um nome diferente para o subdiretório de instantâneos definindo a configuração client snapdir.

Para criar um instantâneo, crie um subdiretório abaixo do diretório .snap com um nome personalizado. Por exemplo, para criar um instantâneo do diretório /CEPHFS_MOUNT/2/3/, execute:

tux > mkdir /CEPHFS_MOUNT/2/3/.snap/CUSTOM_SNAPSHOT_NAME

Para apagar um instantâneo, remova seu subdiretório dentro do diretório .snap:

tux > rmdir /CEPHFS_MOUNT/2/3/.snap/CUSTOM_SNAPSHOT_NAME