O sistema de arquivos Ceph (CephFS) é um sistema de arquivos compatível com POSIX que usa um cluster de armazenamento do Ceph para armazenar seus dados. O CephFS usa o mesmo sistema de cluster que os dispositivos de blocos do Ceph, o armazenamento de objetos do Ceph com APIs S3 e Swift ou as vinculações nativas (librados
).
Para usar o CephFS, você precisa ter um cluster de armazenamento do Ceph em execução e, no mínimo, um servidor de metadados Ceph.
Com o SUSE Enterprise Storage 6, a SUSE inclui suporte oficial para diversos cenários em que o componente distribuído e de expansão horizontal CephFS é usado. Essa entrada descreve os limites físicos e apresenta orientações para os casos de uso sugeridos.
Uma implantação suportada do CephFS deve atender a estes requisitos:
No mínimo, um Servidor de Metadados. A SUSE recomenda implantar vários nós com a função MDS. Apenas um será ativo
, os demais serão passivos
. Lembre-se de mencionar todos os nós MON no comando mount
ao montar o CephFS de um cliente.
Os clientes são SUSE Linux Enterprise Server 12 SP3 ou mais recente, ou SUSE Linux Enterprise Server 15 ou mais recente, usando o driver de módulo do kernel cephfs
. O módulo FUSE não é suportado.
As cotas do CephFS são suportadas no SUSE Enterprise Storage 6 e podem ser definidas 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. Para obter mais informações, consulte o Seção 19.6, “Definindo cotas do CephFS”.
O CephFS suporta mudanças de layout de arquivo, conforme documentado em Seção 11.3.4, “Layouts de arquivos”. No entanto, embora o sistema de arquivos seja montado por qualquer cliente, novos pools de dados não podem ser adicionados a um sistema de arquivos CephFS existente (ceph mds add_data_pool
). Eles apenas podem ser adicionados enquanto o sistema de arquivos está desmontado.
No mínimo, um Servidor de Metadados. A SUSE recomenda implantar vários nós com a função MDS. Por padrão, os daemons adicionais do MDS começam como daemons de standby
, agindo como backups para o MDS ativo. Vários daemons ativos do MDS também são suportados (consulte a seção Seção 11.3.2, “Tamanho do cluster MDS”).
O servidor de metadados Ceph (MDS) armazena metadados para o CephFS. Os dispositivos de blocos e o armazenamento de objetos do Ceph não usam o MDS. Os MDSs permitem que os usuários do sistema de arquivos POSIX executem comandos básicos, como ls
ou find
, sem a necessidade de uma carga enorme no cluster de armazenamento do Ceph.
Você pode implantar o MDS durante o processo inicial de implantação do cluster, conforme descrito na Seção 5.3, “Implantação do cluster”, ou adicioná-lo a um cluster já implantado, conforme descrito no Seção 2.1, “Adicionando novos nós do cluster”.
Após implantar o MDS, permita o serviço Ceph OSD/MDS
na configuração do firewall do servidor no qual o MDS está implantado: Inicie o yast
, navegue até › › e, no menu suspenso (Serviço para Permitir), selecione . Se o nó MDS do Ceph não permitir tráfego completo, haverá falha na montagem do sistema de arquivos, mesmo que outras operações continuem funcionando apropriadamente.
Você pode ajustar o comportamento do MDS inserindo as opções relevantes no arquivo de configuração ceph.conf
.
Se definida como “true” (padrão), monitora a reprodução de standby forçada para ficar ativa. Definida nas seções [mon]
ou [global]
.
mds cache memory limit
O limite flexível de memória (em bytes) que o MDS impõe ao cache. Os administradores devem usá-lo no lugar da configuração antiga mds cache size
. O padrão é 1 GB.
mds cache reservation
A reserva de cache (memória ou inodes) para manutenção do cache do MDS. Quando o MDS começar a usar a reserva, ele revogará o estado do cliente até o tamanho do cache reduzir para restaurar a reserva. O padrão é 0,05.
O número de inodes para armazenar em cache. Um valor de 0 (padrão) indica um número ilimitado. É recomendado usar mds cache memory limit
para limitar a quantidade de memória que o cache do MDS usa.
O ponto de inserção para novos itens no LRU do cache (a partir da parte superior). O padrão é 0.7.
A fração do diretório que foi modificada antes que o Ceph se comprometa usando uma atualização completa, em vez da atualização parcial. O padrão é 0.5.
O tamanho máximo de uma atualização de diretório antes que o Ceph o divida em transações menores. O padrão é 90 MB.
A meia-vida da temperatura do cache do MDS. O padrão é 5.
A frequência em segundos das mensagens de beacon enviadas ao monitor. O padrão é 4.
O intervalo sem beacons antes que o Ceph declare um MDS como lento e possivelmente o substitua. O padrão é 15.
A duração da lista negra para MDSs com falha no mapa OSD. Essa configuração controla quanto tempo os daemons MDS com falha permanecerão na lista negra do mapa OSD. Ela não tem efeito sobre o tempo que um elemento permanece na lista negra quando o administrador o inclui na lista negra manualmente. Por exemplo, o comando ceph osd blacklist add
ainda usará o tempo padrão de lista negra. O padrão é 24*60.
O intervalo em segundos para esperar os clientes se reconectarem durante a reinicialização do MDS. O padrão é 45.
Com que frequência o MDS realiza as tarefas periódicas internas. O padrão é 5.
O intervalo mínimo em segundos para tentar evitar a propagação de estatísticas recursivas até a árvore. O padrão é 1.
A rapidez com que as mudanças do dirstat se propagam. O padrão é 5.
O número de inodes para pré-alocar por sessão do cliente. O padrão é 1000.
Determina se o MDS deve permitir que os clientes vejam os resultados da solicitação antes que eles se comprometam com o diário. O padrão é “true”.
Usar o mapa trivial para atualizações de diretório. O padrão é “true”.
A função a ser usada para hashing de arquivos entre fragmentos de diretório. O padrão é 2 (isto é, “rjenkins”).
Determina se o MDS deve tentar ignorar os eventos de diário corrompidos durante a reprodução do diário. O padrão é “false” (falso).
O máximo de eventos no diário antes de iniciar o corte. Defina como -1 (padrão) para desabilitar limites.
O número máximo de segmentos (objetos) no diário antes de iniciar o corte. Defina como -1 para desabilitar limites. O padrão é 30.
O número máximo de segmentos a serem expirados em paralelos. O padrão é 20.
O número máximo de inodes em um evento do EOpen. O padrão é 100.
Determina com que frequência é feita uma amostra da temperatura do diretório para decisões de fragmentação. O padrão é 3.
A temperatura máxima antes que o Ceph tente replicar os metadados para outros nós. O padrão é 8000.
A temperatura mínima antes que o Ceph pare de replicar os metadados para outros nós. O padrão é 0.
O tamanho máximo do diretório antes que o MDS divida um fragmento do diretório em bits menores. O padrão é 10000.
A temperatura máxima de leitura do diretório antes que o Ceph divida um fragmento do diretório. O padrão é 25000.
A temperatura máxima de gravação do diretório antes que o Ceph divida um fragmento do diretório. O padrão é 10000.
O número de bits que será usado para dividir um fragmento do diretório. O padrão é 3.
O tamanho mínimo do diretório antes que o Ceph tente fundir fragmentos adjacentes do diretório. O padrão é 50.
A frequência em segundos de trocas de carga de trabalho entre os MDSs. O padrão é 10.
O atraso em segundos entre um fragmento ser capaz de se dividir ou fundir e a execução da mudança de fragmentação. O padrão é 5.
A proporção pela qual os fragmentos podem exceder o tamanho dividido antes de uma divisão ser executada imediatamente, ignorando o intervalo do fragmento. O padrão é 1.5.
O tamanho máximo de um fragmento antes de quaisquer novas entradas serem rejeitadas com ENOSPC. O padrão é 100000.
A temperatura mínima antes que o Ceph migre uma subárvore de volta para seu pai. O padrão é 0.
O método para calcular a carga do MDS:
0 = Híbrido.
1 = Taxa de solicitação e latência.
2 = Carga da CPU.
O padrão é 0.
A temperatura mínima da subárvore antes da migração do Ceph. O padrão é 0.1.
A temperatura mínima da subárvore antes que o Ceph pesquise uma subárvore. O padrão é 0.2.
A fração mínima do tamanho da subárvore de destino a ser aceita. O padrão é 0.8.
A fração máxima do tamanho da subárvore de destino a ser aceita. O padrão é 1.2.
O Ceph migrará qualquer subárvore que seja maior do que essa fração do tamanho da subárvore de destino. O padrão é 0.3.
O Ceph ignorará qualquer subárvore que seja menor do que essa fração do tamanho da subárvore de destino. O padrão é 0.001.
O número mínimo de iterações do balanceador antes que o Ceph remova um destino do MDS antigo do mapa MDS. O padrão é 5.
O número máximo de iterações do balanceador antes que o Ceph remova um destino do MDS antigo do mapa MDS. O padrão é 10.
O intervalo de poll do diário durante o modo de reprodução de standby ("standby ativo"). O padrão é 1.
O intervalo para polling do cache durante o encerramento do MDS. O padrão é 0.
O Ceph fragmentará ou fundirá os diretórios aleatoriamente. O padrão é 0.
O Ceph descartará o conteúdo do cache do MDS em um arquivo em cada mapa MDS. O padrão é “false” (falso).
O Ceph descartará o conteúdo do cache do MDS para um arquivo após reingressar no cache durante a recuperação. O padrão é “false” (falso).
Um daemon MDS servirá de standby para outro daemon MDS do nome especificado nesta configuração.
Um daemon MDS servirá de standby para um daemon MDS desta posição. O padrão é -1.
Determina se um daemon MDS do Ceph deve fazer poll e reproduzir o registro de um MDS ativo ("standby ativo"). O padrão é “false” (falso).
Definir o número mínimo de recursos que um cliente pode armazenar. O padrão é 100.
Definir a proporção máxima de recursos atuais que podem ser chamados novamente durante uma pressão do cache do MDS. O padrão é 0.8.
Com que frequência atualizar o objeto de início do diário. O padrão é 15.
Quantos períodos de distribuição serão lidos primeiro na reprodução do diário. O padrão é 10.
Quantos períodos de distribuição serão zerados à frente da posição de gravação. O padrão é 10.
Latência máxima adicional em segundos que incorremos artificialmente. O padrão é 0.001.
Número máximo de bytes para atrasar o descarregamento. O padrão é 0.
Quando você tem um cluster de armazenamento do Ceph saudável com pelo menos um servidor de metadados Ceph, pode criar e montar o sistema de arquivos Ceph. Verifique se o seu cliente tem conectividade de rede e um chaveiro de autenticação apropriado.
Um CephFS requer pelo menos dois pools RADOS: um para dados e outro para metadados. Ao configurar esses pools, considere o seguinte:
Uso de um nível mais alto de replicação para o pool de metadados, pois qualquer perda de dados nesse pool pode tornar todo o sistema de arquivos inacessível.
Uso de armazenamento de latência menor, como SSDs, para o pool de metadados, pois isso melhora a latência observada das operações do sistema de arquivos nos clientes.
Ao atribuir um role-mds
em policy.cfg
, os pools necessários são criados automaticamente. Você pode criar manualmente os pools cephfs_data
e cephfs_metadata
para ajuste do desempenho manual antes de configurar o Servidor de Metadados. O DeepSea não criará esses pools se eles já existirem.
Para obter mais informações sobre gerenciamento de pools, consulte o Capítulo 11, Gerenciando pools de armazenamento.
Para criar os dois pools necessários (por exemplo, “cephfs_data” e “cephfs_metadata”) com as configurações padrão para uso com o CephFS, execute os seguintes comandos:
cephadm@adm >
ceph osd pool create cephfs_data pg_numcephadm@adm >
ceph osd pool create cephfs_metadata pg_num
É possível usar os pools EC em vez dos pools replicados. É recomendável usar apenas os pools EC para requisitos de baixo desempenho e acesso aleatório com pouca frequência. Por exemplo, armazenamento frio, backups, arquivamento. O CephFS em pools EC requer a habilitação do BlueStore, e o pool deve ter a opção allow_ec_overwrite
definida. É possível definir essa opção executando ceph osd pool set ec_pool allow_ec_overwrites true
.
Apagar a codificação aumenta significativamente o overhead das operações do sistema de arquivos, principalmente de pequenas atualizações. Esse overhead é inerente ao uso do recurso de apagar codificação como mecanismo de tolerância a falhas. Essa desvantagem é compensada pela redução substancial do overhead de espaço de armazenamento.
Quando os pools são criados, você pode habilitar o sistema de arquivos com o comando ceph fs new
:
cephadm@adm >
ceph fs new fs_name metadata_pool_name data_pool_name
Por exemplo:
cephadm@adm >
ceph fs new cephfs cephfs_metadata cephfs_data
Você pode verificar se o sistema de arquivos foi criado listando todos os CephFSs disponíveis:
cephadm@adm >
ceph
fs ls
name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]
Quando o sistema de arquivos for criado, o MDS poderá inserir um estado ativo. Por exemplo, em um único sistema MDS:
cephadm@adm >
ceph
mds stat
e5: 1/1/1 up
Você pode encontrar mais informações sobre tarefas específicas, por exemplo, montar, desmontar e configuração avançada do CephFS, no Capítulo 19, Sistema de arquivos em cluster.
Vários daemons MDS ativos podem atender a uma instância do CephFS. Todos os daemons MDS ativos atribuídos a uma instância do CephFS distribuirão a árvore de diretório do sistema de arquivos entre eles e, portanto, dividirão a carga de clientes simultâneos. Para adicionar um daemon MDS ativo a uma instância do CephFS, é necessário um standby separado. Inicie um daemon adicional ou use uma instância de standby existente.
O comando a seguir exibirá o número atual de daemons MDS ativos e passivos.
cephadm@adm >
ceph mds stat
O comando a seguir define o número de MDSs ativos como dois em uma instância do sistema de arquivos.
cephadm@adm >
ceph fs set fs_name max_mds 2
Para reduzir o cluster MDS antes de uma atualização, duas etapas são necessárias. Primeiramente, defina max_mds
de forma que permaneça apenas uma instância:
cephadm@adm >
ceph fs set fs_name max_mds 1
e, em seguida, desative explicitamente os outros daemons MDS ativos:
cephadm@adm >
ceph mds deactivate fs_name:rank
em que rank é o número de um daemon MDS ativo de uma instância do sistema de arquivos, variando de 0 a max_mds
-1.
Recomendamos que pelo menos um MDS seja deixado como daemon de standby.
Durante as atualizações do Ceph, os flags de recursos em uma instância do sistema de arquivos podem mudar (normalmente, adicionando novos recursos). Os daemons incompatíveis (como os de versões mais antigas) não funcionam com um conjunto de recursos incompatíveis e se recusarão a iniciar. Isso significa que a atualização e a reinicialização de um daemon podem fazer com que todos os outros daemons ainda não atualizados parem e se recusem a iniciar. Por esse motivo, recomendamos reduzir o cluster MDS ativo para o tamanho 1 e parar todos os daemons de standby antes de atualizar o Ceph. Veja a seguir as etapas manuais para este procedimento de atualização:
Atualize os pacotes relacionados ao Ceph usando o zypper
.
Reduza o cluster MDS ativo, conforme descrito acima, para uma instância e pare todos os daemons MDS de standby usando as unidades systemd
deles em todos os outros nós:
cephadm@mds >
systemctl stop ceph-mds\*.service ceph-mds.target
Somente depois disso, reinicie o único daemon MDS restante, o que faz com que ele seja reiniciado usando o binário atualizado.
cephadm@mds >
systemctl restart ceph-mds\*.service ceph-mds.target
Reinicie todos os outros daemons MDS e redefina a configuração max_mds
desejada.
cephadm@mds >
systemctl start ceph-mds.target
Se você usa o DeepSea, ele seguirá esse procedimento se o pacote ceph for atualizado durante as fases 0 e 4. É possível executar esse procedimento enquanto os clientes estão com a instância do CephFS montada e a E/S está em andamento. No entanto, observe que haverá uma pausa de E/S muito breve durante a reinicialização do MDS ativo. Os clientes serão recuperados automaticamente.
Convém reduzir a carga de E/S o máximo possível antes de atualizar um cluster MDS. Um cluster MDS ocioso passará por esse procedimento de atualização mais rapidamente. Por outro lado, em um cluster excessivamente carregado com vários daemons MDS, é essencial reduzir a carga de maneira antecipada para evitar que um único daemon MDS fique sobrecarregado com E/S contínua.
O layout de um arquivo controla como o conteúdo dele é mapeado para objetos RADOS do Ceph. É possível ler e gravar o layout de um arquivo usando atributos estendidos virtuais ou xattrs, na forma abreviada.
O nome dos xattrs de layout depende se um arquivo é regular ou um diretório. Os xattrs de layout de arquivos regulares são denominados ceph.file.layout
. Os xattrs de layout de diretórios são denominados ceph.dir.layout
. Onde os exemplos fazem referência ao ceph.file.layout
, substitua a parte .dir.
conforme apropriado ao trabalhar com diretórios.
Os seguintes campos de atributo são reconhecidos:
ID ou nome de um pool RADOS em que os objetos de dados de um arquivo serão armazenados.
Namespace RADOS em um pool de dados no qual os objetos serão gravados. Por padrão, ele está vazio, o que significa o namespace padrão.
O tamanho em bytes de um bloco de dados utilizado na distribuição RAID 0 de um arquivo. Todas as unidades de distribuição para um arquivo têm tamanho igual. A última unidade de distribuição normalmente está incompleta. Ela representa os dados no fim do arquivo e o "espaço" não utilizado além dele até o fim do tamanho da unidade de faixa fixa.
O número de unidades de distribuição consecutivas que constituem uma “faixa” RAID 0 de dados do arquivo.
O tamanho em bytes de objetos RADOS nos quais os dados do arquivo são empacotados.
O RADOS impõe um limite configurável aos tamanhos dos objetos. Se você aumentar os tamanhos dos objetos CephFS além desse limite, as gravações poderão falhar. A configuração do OSD é osd_max_object_size
, que por padrão é de 128 MB. Objetos RADOS muito grandes impedem a operação contínua do cluster. Portanto, aumentar o limite de tamanho do objeto além do padrão não é recomendado.
getfattr
#
Use o comando getfattr
para ler as informações de layout de um arquivo de exemplo file
como uma única string:
root #
touch fileroot #
getfattr -n ceph.file.layout file # file: file ceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=419430
Leia os campos de layout individuais:
root #
getfattr -n ceph.file.layout.pool file # file: file ceph.file.layout.pool="cephfs_data"root #
getfattr -n ceph.file.layout.stripe_unit file # file: file ceph.file.layout.stripe_unit="4194304"
Ao ler os layouts, o pool costuma ser indicado por nome. No entanto, em casos raros em que os pools apenas foram criados, o ID pode ser a saída.
Os diretórios não têm um layout explícito até que ele seja personalizado. Há falha nas tentativas de ler o layout se ele nunca foi modificado: isso indica que o layout do próximo diretório de origem com um layout explícito será usado.
root #
mkdir dirroot #
getfattr -n ceph.dir.layout dir dir: ceph.dir.layout: No such attributeroot #
setfattr -n ceph.dir.layout.stripe_count -v 2 dirroot #
getfattr -n ceph.dir.layout dir # file: dir ceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 pool=cephfs_data"
setfattr
#
Use o comando setfattr
para modificar os campos de layout de um arquivo de exemplo file
:
cephadm@adm >
ceph osd lspools 0 rbd 1 cephfs_data 2 cephfs_metadataroot #
setfattr -n ceph.file.layout.stripe_unit -v 1048576 fileroot #
setfattr -n ceph.file.layout.stripe_count -v 8 file # Setting pool by ID:root #
setfattr -n ceph.file.layout.pool -v 1 file # Setting pool by name:root #
setfattr -n ceph.file.layout.pool -v cephfs_data file
Quando os campos de layout de um arquivo são modificados usando setfattr
, esse arquivo precisa estar vazio; do contrário, ocorrerá um erro.
Para remover um layout explícito de um diretório de exemplo mydir
e reverter para herdar o layout de sua origem, execute o seguinte:
root #
setfattr -x ceph.dir.layout mydir
Da mesma forma, se você definiu o atributo "pool_namespace" e deseja modificar o layout para usar o namespace padrão, execute:
# Create a directory and set a namespace on itroot #
mkdir mydirroot #
setfattr -n ceph.dir.layout.pool_namespace -v foons mydirroot #
getfattr -n ceph.dir.layout mydir ceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a pool_namespace=foons" # Clear the namespace from the directory's layoutroot #
setfattr -x ceph.dir.layout.pool_namespace mydirroot #
getfattr -n ceph.dir.layout mydir ceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a"
Os arquivos herdam o layout do diretório pai deles no momento da criação. No entanto, as mudanças subsequentes no layout do diretório pai não afetam os filhos:
root #
getfattr -n ceph.dir.layout dir # file: dir ceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data" # file1 inherits its parent's layoutroot #
touch dir/file1root #
getfattr -n ceph.file.layout dir/file1 # file: dir/file1 ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data" # update the layout of the directory before creating a second fileroot #
setfattr -n ceph.dir.layout.stripe_count -v 4 dirroot #
touch dir/file2 # file1's layout is unchangedroot #
getfattr -n ceph.file.layout dir/file1 # file: dir/file1 ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data" # ...while file2 has the parent directory's new layoutroot #
getfattr -n ceph.file.layout dir/file2 # file: dir/file2 ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"
Os arquivos criados como descendentes do diretório também herdarão o layout se os diretórios intermediários não tiverem layouts definidos:
root #
getfattr -n ceph.dir.layout dir # file: dir ceph.dir.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"root #
mkdir dir/childdirroot #
getfattr -n ceph.dir.layout dir/childdir dir/childdir: ceph.dir.layout: No such attributeroot #
touch dir/childdir/grandchildroot #
getfattr -n ceph.file.layout dir/childdir/grandchild # file: dir/childdir/grandchild ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"
Antes que você possa usar um pool com o CephFS, precisa adicioná-lo ao Servidor de Metadados:
cephadm@adm >
ceph fs add_data_pool cephfs cephfs_data_ssdcephadm@adm >
ceph fs ls # Pool should now show up .... data pools: [cephfs_data cephfs_data_ssd ]
Verifique se as chaves cephx permitem que o cliente acesse esse novo pool.
Em seguida, você poderá atualizar o layout em um diretório no CephFS para usar o pool adicionado:
root #
mkdir /mnt/cephfs/myssddirroot #
setfattr -n ceph.dir.layout.pool -v cephfs_data_ssd /mnt/cephfs/myssddir
Todos os novos arquivos criados dentro desse diretório agora herdarão o layout dele e armazenarão os dados em seu pool recém-adicionado. Talvez você observe que o número de objetos em seu pool de dados principal continua aumentando, mesmo que os arquivos estejam sendo criados no pool recém-adicionado. Isso é normal: os dados do arquivo são armazenados no pool especificado pelo layout, mas uma pequena quantidade de metadados é mantida no pool de dados principal para todos os arquivos.