Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Aplica-se a SUSE Enterprise Storage 6

11 Instalação do CephFS

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.

11.1 Cenários e diretrizes suportados do CephFS

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”).

11.2 Servidor de metadados Ceph

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.

11.2.1 Adicionando um servidor de metadados

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é Security and Users (Segurança e Usuários) › Firewall › Allowed Services (Serviços Permitidos) e, no menu suspenso Service to Allow (Serviço para Permitir), selecione Ceph OSD/MDS. 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.

11.2.2 Configurando um servidor de metadados

Você pode ajustar o comportamento do MDS inserindo as opções relevantes no arquivo de configuração ceph.conf.

Configurações do servidor de metadados
mon force standby active

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.

mds cache size

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.

mds cache mid

O ponto de inserção para novos itens no LRU do cache (a partir da parte superior). O padrão é 0.7.

mds dir commit ratio

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.

mds dir max commit size

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.

mds decay halflife

A meia-vida da temperatura do cache do MDS. O padrão é 5.

mds beacon interval

A frequência em segundos das mensagens de beacon enviadas ao monitor. O padrão é 4.

mds beacon grace

O intervalo sem beacons antes que o Ceph declare um MDS como lento e possivelmente o substitua. O padrão é 15.

mds blacklist interval

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.

mds reconnect timeout

O intervalo em segundos para esperar os clientes se reconectarem durante a reinicialização do MDS. O padrão é 45.

mds tick interval

Com que frequência o MDS realiza as tarefas periódicas internas. O padrão é 5.

mds dirstat min interval

O intervalo mínimo em segundos para tentar evitar a propagação de estatísticas recursivas até a árvore. O padrão é 1.

mds scatter nudge interval

A rapidez com que as mudanças do dirstat se propagam. O padrão é 5.

mds client prealloc inos

O número de inodes para pré-alocar por sessão do cliente. O padrão é 1000.

mds early reply

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”.

mds use tmap

Usar o mapa trivial para atualizações de diretório. O padrão é “true”.

mds default dir hash

A função a ser usada para hashing de arquivos entre fragmentos de diretório. O padrão é 2 (isto é, “rjenkins”).

mds log skip corrupt events

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).

mds log max events

O máximo de eventos no diário antes de iniciar o corte. Defina como -1 (padrão) para desabilitar limites.

mds log max segments

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.

mds log max expiring

O número máximo de segmentos a serem expirados em paralelos. O padrão é 20.

mds log eopen size

O número máximo de inodes em um evento do EOpen. O padrão é 100.

mds bal sample interval

Determina com que frequência é feita uma amostra da temperatura do diretório para decisões de fragmentação. O padrão é 3.

mds bal replicate threshold

A temperatura máxima antes que o Ceph tente replicar os metadados para outros nós. O padrão é 8000.

mds bal unreplicate threshold

A temperatura mínima antes que o Ceph pare de replicar os metadados para outros nós. O padrão é 0.

mds bal split size

O tamanho máximo do diretório antes que o MDS divida um fragmento do diretório em bits menores. O padrão é 10000.

mds bal split rd

A temperatura máxima de leitura do diretório antes que o Ceph divida um fragmento do diretório. O padrão é 25000.

mds bal split wr

A temperatura máxima de gravação do diretório antes que o Ceph divida um fragmento do diretório. O padrão é 10000.

mds bal split bits

O número de bits que será usado para dividir um fragmento do diretório. O padrão é 3.

mds bal merge size

O tamanho mínimo do diretório antes que o Ceph tente fundir fragmentos adjacentes do diretório. O padrão é 50.

mds bal interval

A frequência em segundos de trocas de carga de trabalho entre os MDSs. O padrão é 10.

mds bal fragment interval

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.

mds bal fragment fast factor

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.

mds bal fragment size max

O tamanho máximo de um fragmento antes de quaisquer novas entradas serem rejeitadas com ENOSPC. O padrão é 100000.

mds bal idle threshold

A temperatura mínima antes que o Ceph migre uma subárvore de volta para seu pai. O padrão é 0.

mds bal mode

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.

mds bal min rebalance

A temperatura mínima da subárvore antes da migração do Ceph. O padrão é 0.1.

mds bal min start

A temperatura mínima da subárvore antes que o Ceph pesquise uma subárvore. O padrão é 0.2.

mds bal need min

A fração mínima do tamanho da subárvore de destino a ser aceita. O padrão é 0.8.

mds bal need max

A fração máxima do tamanho da subárvore de destino a ser aceita. O padrão é 1.2.

mds bal midchunk

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.

mds bal minchunk

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.

mds bal target removal min

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.

mds bal target removal max

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.

mds replay interval

O intervalo de poll do diário durante o modo de reprodução de standby ("standby ativo"). O padrão é 1.

mds shutdown check

O intervalo para polling do cache durante o encerramento do MDS. O padrão é 0.

mds thrash fragments

O Ceph fragmentará ou fundirá os diretórios aleatoriamente. O padrão é 0.

mds dump cache on map

O Ceph descartará o conteúdo do cache do MDS em um arquivo em cada mapa MDS. O padrão é “false” (falso).

mds dump cache after rejoin

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).

mds standby for name

Um daemon MDS servirá de standby para outro daemon MDS do nome especificado nesta configuração.

mds standby for rank

Um daemon MDS servirá de standby para um daemon MDS desta posição. O padrão é -1.

mds standby replay

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).

mds min caps per client

Definir o número mínimo de recursos que um cliente pode armazenar. O padrão é 100.

mds max ratio caps per client

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.

Configurações de diário (journaler) do servidor de metadados
journaler write head interval

Com que frequência atualizar o objeto de início do diário. O padrão é 15.

journaler prefetch periods

Quantos períodos de distribuição serão lidos primeiro na reprodução do diário. O padrão é 10.

journal prezero periods

Quantos períodos de distribuição serão zerados à frente da posição de gravação. O padrão é 10.

journaler batch interval

Latência máxima adicional em segundos que incorremos artificialmente. O padrão é 0.001.

journaler batch max

Número máximo de bytes para atrasar o descarregamento. O padrão é 0.

11.3 CephFS

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.

11.3.1 Criando o CephFS

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_num
cephadm@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
Dica
Dica: Mais tópicos

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.

11.3.2 Tamanho do cluster MDS

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.

11.3.3 Cluster e atualizações do MDS

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:

  1. Atualize os pacotes relacionados ao Ceph usando o zypper.

  2. 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
  3. 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
  4. 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.

11.3.4 Layouts de arquivos

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.

11.3.4.1 Campos de layout

Os seguintes campos de atributo são reconhecidos:

pool

ID ou nome de um pool RADOS em que os objetos de dados de um arquivo serão armazenados.

pool_namespace

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.

stripe_unit

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.

stripe_count

O número de unidades de distribuição consecutivas que constituem uma “faixa” RAID 0 de dados do arquivo.

object_size

O tamanho em bytes de objetos RADOS nos quais os dados do arquivo são empacotados.

Dica
Dica: Tamanhos de Objetos

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.

11.3.4.2 Layout de leitura com getfattr

Use o comando getfattr para ler as informações de layout de um arquivo de exemplo file como uma única string:

root # touch file
root # 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"
Dica
Dica: ID ou Nome do Pool

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 dir
root # getfattr -n ceph.dir.layout dir
dir: ceph.dir.layout: No such attribute
root # setfattr -n ceph.dir.layout.stripe_count -v 2 dir
root # getfattr -n ceph.dir.layout dir
# file: dir
ceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 pool=cephfs_data"

11.3.4.3 Gravando layouts com 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_metadata
root # setfattr -n ceph.file.layout.stripe_unit -v 1048576 file
root # 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
Nota
Nota: Arquivo Vazio

Quando os campos de layout de um arquivo são modificados usando setfattr, esse arquivo precisa estar vazio; do contrário, ocorrerá um erro.

11.3.4.4 Limpando layouts

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 it
root # mkdir mydir
root # setfattr -n ceph.dir.layout.pool_namespace -v foons mydir
root # 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 layout
root # setfattr -x ceph.dir.layout.pool_namespace mydir
root # getfattr -n ceph.dir.layout mydir
ceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \
 pool=cephfs_data_a"

11.3.4.5 Herança de layouts

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 layout
root # touch dir/file1
root # 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 file
root # setfattr -n ceph.dir.layout.stripe_count -v 4 dir
root # touch dir/file2

# file1's layout is unchanged
root # 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 layout
root # 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/childdir
root # getfattr -n ceph.dir.layout dir/childdir
dir/childdir: ceph.dir.layout: No such attribute
root # touch dir/childdir/grandchild
root # 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"

11.3.4.6 Adicionando um pool de dados ao servidor de metadados

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_ssd
cephadm@adm > ceph fs ls  # Pool should now show up
.... data pools: [cephfs_data cephfs_data_ssd ]
Dica
Dica: Chaves cephx

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/myssddir
root # 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.

Imprimir esta página