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

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, 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”, e o restante será “passivo”. Lembre-se de mencionar todos os nós MDS no comando mount ao montar o CephFS de um cliente.

  • Os instantâneos do CephFS estão desabilitados (padrão) e não são suportados nesta versão.

  • Os clientes são baseados no SUSE Linux Enterprise Server 12 SP2 ou SP3 e usam o driver do módulo do kernel cephfs. O módulo FUSE não é suportado.

  • As cotas do CephFS não são suportadas no SUSE Enterprise Storage, já que o suporte a cotas foi implementado apenas no cliente do FUSE.

  • O CephFS suporta mudanças de layout de arquivo, conforme documentado em http://docs.ceph.com/docs/jewel/cephfs/file-layouts/. 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.

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 4.3, “Implantação do cluster”, ou adicioná-lo a um cluster já implantado, conforme descrito no Seção 1.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.

Tamanho do cache do MDS
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.

Para obter uma lista detalhada das opções de configuração relacionadas ao MDS, consulte http://docs.ceph.com/docs/master/cephfs/mds-config-ref/.

Para obter uma lista detalhada das opções de configuração do gravador de diário do MDS, consulte http://docs.ceph.com/docs/master/cephfs/journaler/.

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 7, 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:

root # ceph osd pool create cephfs_data pg_num
root # 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:

root # ceph fs new fs_name metadata_pool_name data_pool_name

Por exemplo:

root # ceph fs new cephfs cephfs_metadata cephfs_data

Você pode verificar se o sistema de arquivos foi criado listando todos os CephFSs disponíveis:

root # 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:

root # 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 13, 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.

root # ceph mds stat

O comando a seguir define o número de MDS ativos como dois em uma instância do sistema de arquivos.

root # 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:

root # ceph fs set fs_name max_mds 1

e, em seguida, desative explicitamente os outros daemons MDS ativos:

root # 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. Consulte http://docs.ceph.com/docs/luminous/cephfs/multimds/ para obter informações adicionais.

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 1 instância e pare todos os daemons MDS de standby usando as unidades systemd deles em todos os outros nós:

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

    root # systemctl restart ceph-mds\*.service ceph-mds.target
  4. Reinicie todos os outros daemons MDS e redefina a configuração max_mds desejada.

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

Imprimir esta página