cephx
Este capítulo descreve as tarefas de administração que normalmente são executadas depois que o cluster é configurado e o CephFS é exportado. Se você precisar de mais informações sobre como configurar o CephFS, consulte o Capítulo 11, Instalação do CephFS.
Quando o sistema de arquivos é criado e o MDS está ativo, você está pronto para montar o sistema de arquivos de um host de cliente.
Se o host de cliente executa o SUSE Linux Enterprise 12 SP2 ou SP3, você pode ignorar esta seção, já que 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 6 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.
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:
Veja a chave do usuário específico em um arquivo de chaveiro:
cephadm@adm >
cat /etc/ceph/ceph.client.admin.keyring
Copie a chave do usuário que utilizará o sistema de arquivos Ceph FS montado. Normalmente, a chave tem a seguinte aparência:
AQCj2YpRiAe6CxAA7/ETt7Hcl9IyxyYciVs47w==
Crie um arquivo com o nome de usuário como parte do nome de arquivo. Por exemplo, /etc/ceph/admin.secret
para o usuário admin.
Cole o valor da chave no arquivo criado na etapa anterior.
Defina os direitos de acesso apropriados para o arquivo. O usuário deve ser a única pessoa que pode ler o arquivo. Outras pessoas não devem ter nenhum direito de acesso.
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==
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
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.
Para desmontar o CephFS, use o comando umount
:
root #
umount /mnt/cephfs
/etc/fstab
#
Para montar o CephFS automaticamente na inicialização do cliente, insira a linha correspondente na respectiva tabela de sistemas de arquivos /etc/fstab
:
mon1:6790,mon2:/subdir /mnt/cephfs ceph name=admin,secretfile=/etc/ceph/secret.key,noatime,_netdev 0 2
Por padrão, o CephFS é configurado para um único daemon MDS ativo. Para aumentar o desempenho dos metadados em sistemas de grande escala, é possível habilitar vários daemons MDS ativos, que compartilharão a carga de trabalho dos metadados entre eles.
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
:
cephadm@adm >
ceph
status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby [...]cephadm@adm >
ceph
mds set max_mds 2cephadm@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”.
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:
cephadm@adm >
ceph
status [...] services: [...] mds: cephfs-2/2/2 up {0=node2=up:active,1=node1=up:active} [...]cephadm@adm >
ceph
mds set max_mds 1cephadm@adm >
ceph
status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby [...]
Observe que ainda temos dois MDS ativos. As classificações ainda existem, apesar de termos reduzido max_mds
, pois max_mds
apenas restringe a criação de novas classificações.
Em seguida, use o comando ceph mds deactivate rank
para remover a classificação desnecessária:
cephadm@adm >
ceph
status [...] services: [...] mds: cephfs-2/2/1 up {0=node2=up:active,1=node1=up:active}cephadm@adm >
ceph
mds deactivate 1 telling mds.1:1 192.168.58.101:6805/2799214375 to deactivatecephadm@adm >
ceph
status [...] services: [...] mds: cephfs-2/2/1 up {0=node2=up:active,1=node1=up:stopping}cephadm@adm >
ceph
status [...] services: [...] mds: cephfs-1/1/1 up {0=node2=up:active}, 1 up:standby
A classificação desativada entrará primeiro no estado de interrupção, por um período enquanto ela transmite sua cota de metadados para os daemons ativos restantes. Essa fase pode levar de segundos a minutos. Se o MDS parecer travado no estado de interrupção, isso deverá ser investigado como um possível bug.
Se um daemon MDS falhar ou for terminado durante o estado de “interrupção”, um standby assumirá o controle, e a classificação voltará para o estado “ativo”. Você poderá tentar desativá-la novamente quando ela voltar a ser ativa.
Quando um daemon sair do estado de interrupção, ele será iniciado novamente e voltará a ser 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.
Se um daemon MDS parar de se comunicar com o monitor, o monitor aguardará mds_beacon_grace
segundos (o padrão é 15 segundos) antes de marcar o daemon como lento. Você pode configurar um ou mais daemons de “standby” para assumir o controle durante o failover do daemon MDS.
Há várias configurações que controlam o comportamento de um daemon durante o standby. Você pode especificá-las no ceph.conf
no host em que o daemon MDS é executado. O daemon carrega essas configurações quando é iniciado e as envia para o monitor.
Por padrão, se nenhuma dessas configurações for usada, todos os daemons MDS que não tiverem uma classificação serão usados como “standby” para qualquer classificação.
As configurações que associam um daemon de standby a determinado nome ou classificação não garantem que o daemon apenas será usado para essa classificação. Quando há vários standbys disponíveis, elas indicam que o daemon de standby associado será usado. Em caso de falha em uma classificação, e se um standby estiver disponível, ele será usado mesmo se estiver associado a uma diferente classificação ou daemon nomeado.
Se definido como verdadeiro, o daemon de standby lerá continuamente o diário de metadados de uma classificação ativa. Isso resulta em um cache de metadados a quente e acelera o processo de failover em caso de falha no daemon que está assumindo a classificação.
Uma classificação ativa pode ter apenas um daemon de reprodução de standby atribuído a ela. Se dois daemons forem definidos como reprodução de standby, um deles vencerá arbitrariamente, e o outro se tornará um standby normal que não é de reprodução.
Quando um daemon 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.
Defina essa opção para fazer com que o daemon de standby apenas assuma uma classificação com falha se o último daemon a mantê-la corresponder a este nome.
Defina essa opção para fazer com que o daemon de standby apenas assuma a classificação especificada. Se houver falha em outra classificação, esse daemon não será usado para substituí-la.
Use em conjunto com mds_standby_for_fscid
para ser específico quanto à classificação do sistema de arquivos que você pretende usar em caso de vários sistemas de arquivos.
Se mds_standby_for_rank
for definido, trata-se simplesmente de um qualificador que indica qual classificação do sistema de arquivos está sendo referenciada.
Se mds_standby_for_rank
não for definido, a definição de FSCID fará com que este daemon seja direcionado para qualquer classificação no FSCID especificado. Use essa opção se você tem um daemon que deseja usar para qualquer classificação, mas apenas em um sistema de arquivos específico.
Essa configuração é usada nos hosts de monitor. O padrão é verdadeiro.
Se for falso, os daemons configurados com standby_replay=true
apenas se tornarão ativos se houver falha na classificação/nome que foram configurados para seguir. Por outro lado, se essa configuração for verdadeira, um daemon configurado com standby_replay=true
poderá ser atribuído a alguma outra classificação.
Veja a seguir várias configurações do ceph.conf
de exemplo. Você pode copiar um ceph.conf
com a configuração de todos os daemons para todos os servidores ou pode ter um arquivo diferente em cada servidor contendo a configuração do daemon desse servidor.
Dois daemons MDS “a” e “b” atuando como par. Aquele que não estiver atribuído a uma classificação no momento será o seguidor de reprodução de standby do outro.
[mds.a] mds standby replay = true mds standby for rank = 0 [mds.b] mds standby replay = true mds standby for rank = 0
Você pode definir cotas em qualquer subdiretório do sistema de arquivos Ceph. A cota restringe o número de bytes ou de arquivos armazenados abaixo do ponto especificado na hierarquia de diretórios.
O uso de cotas com o CephFS tem as seguintes limitações:
As cotas do Ceph confiam que o cliente que está montando o sistema de arquivos pare de gravar nele quando um limite é atingido. A parte do servidor não pode evitar que um cliente mal intencionado grave a quantidade de dados que ele precisar. Não use cotas para evitar o preenchimento do sistema de arquivos em ambientes em que os clientes não são totalmente confiáveis.
Os processos que estão gravando no sistema de arquivos serão interrompidos logo após o limite da cota ser atingido. Inevitavelmente, eles poderão gravar alguma quantidade de dados acima do limite configurado. Os gravadores do cliente serão interrompidos dentro de décimos de segundos após ultrapassar o limite configurado.
As cotas são suportadas pelo cliente do espaço de usuário (libcephfs, ceph-fuse). Os clientes do kernel do Linux 4.17 e superiores suportam cotas do CephFS nos clusters do SUSE Enterprise Storage 6. Haverá falha nos clientes do kernel (até nas versões recentes) ao processar cotas em clusters mais antigos, mesmo que eles possam definir os atributos estendidos das cotas.
O cliente precisa ter acesso ao inode do diretório em que as cotas são configuradas para aplicá-las. Se o cliente tiver acesso restrito a um determinado caminho (por exemplo, /home/user
) com base no recurso do MDS, e se a cota for configurada em um diretório de origem ao qual ele não tem acesso a (/home
), o cliente não a aplicará. Ao usar restrições de acesso com base no caminho, certifique-se de configurar a cota no diretório em que o cliente também esteja restrito (/home/user
) ou em algum local aninhado abaixo dele.
Você pode configurar cotas do CephFS usando atributos estendidos virtuais:
ceph.quota.max_files
Configura um limite de arquivos.
ceph.quota.max_bytes
Configura um limite de bytes.
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:
cephadm@mds >
setfattr -n ceph.quota.max_bytes -v 100000000 /SOME/DIRECTORY
Para definir uma cota de 10.000 arquivos, execute:
cephadm@mds >
setfattr -n ceph.quota.max_files -v 10000 /SOME/DIRECTORY
Para ver a configuração de cota, execute:
cephadm@mds >
getfattr -n ceph.quota.max_bytes /SOME/DIRECTORY
cephadm@mds >
getfattr -n ceph.quota.max_files /SOME/DIRECTORY
Se o valor do atributo estendido for “0”, a cota não será definida.
Para remover uma cota, execute:
cephadm@mds >
setfattr -n ceph.quota.max_bytes -v 0 /SOME/DIRECTORYcephadm@mds >
setfattr -n ceph.quota.max_files -v 0 /SOME/DIRECTORY
Os instantâneos do CephFS criam uma visão apenas leitura do sistema de arquivos no momento em que são capturados. Você pode criar um instantâneo em qualquer diretório. O instantâneo incluirá todos os dados no sistema de arquivos abaixo do diretório especificado. Após a criação de um instantâneo, os dados incluídos no buffer serão descarregados dos vários clientes de maneira assíncrona. Dessa forma, a criação de um instantâneo é muito rápida.
Se você tiver vários sistemas de arquivos CephFS compartilhando um único pool (por meio de namespaces), seus instantâneos colidirão, e a exclusão de um instantâneo resultará em dados de arquivos ausentes em outros instantâneos que compartilham o mesmo pool.
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:
cephadm@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.
Os clientes do kernel do CephFS têm uma limitação: eles não podem processar mais de 400 instantâneos em uma árvore de diretórios. 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.
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