Guia de Implantação
- Sobre este guia
- I SUSE Enterprise Storage
- II Implantação e upgrade do cluster
- III Instalação de serviços adicionais
- IV Implantação do cluster no SUSE CaaS Platform 4 (Technology Preview)
- A Atualizações de manutenção do Ceph baseadas nos point releases de upstream do “Nautilus”
- Glossário
- B Atualizações da documentação
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ãopassivos. Lembre-se de mencionar todos os nós MON no comandomountao 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
bytesou dearquivosarmazenados 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é › › 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.
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 limitO 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 reservationA 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 limitpara 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 addainda 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_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_namePor exemplo:
cephadm@adm > ceph fs new cephfs cephfs_metadata cephfs_dataVocê pode verificar se o sistema de arquivos foi criado listando todos os CephFSs disponíveis:
cephadm@adm >cephfs lsname: 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 >cephmds state5: 1/1/1 up
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 statO 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 1e, 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:
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
systemddeles em todos os outros nós:cephadm@mds >systemctl stop ceph-mds\*.service ceph-mds.targetSomente 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.targetReinicie todos os outros daemons MDS e redefina a configuração
max_mdsdesejada.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: 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 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"
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 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"
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_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
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 mydirDa 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"
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 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"
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_ssdcephadm@adm >ceph fs ls # Pool should now show up .... data pools: [cephfs_data cephfs_data_ssd ]
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/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.