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

18 Dicas e truques

O capítulo apresenta informações para ajudar você a melhorar o desempenho do cluster do Ceph e inclui dicas de como configurá-lo.

18.1 Ajustando a depuração

Por padrão, o Ceph executa uma depuração diária simples (encontre mais detalhes na Seção 6.5, “Depuração”) e uma depuração semanal em detalhes. A depuração simples verifica os tamanhos e os checksums dos objetos para garantir que os grupos de posicionamento estejam armazenando os mesmos dados dos objetos. A depuração em detalhes compara o conteúdo de um objeto com o de suas réplicas para garantir que o conteúdo real seja o mesmo. O ponto negativo da verificação de integridade de dados é uma carga de E/S maior no cluster durante o procedimento de depuração.

As configurações padrão permitem que os Ceph OSDs iniciem a depuração em horários inadequados. Por exemplo, durante os períodos de cargas elevadas. Os clientes podem enfrentar latência e baixo desempenho quando as operações de depuração entram em conflito com as operações deles. O Ceph dispõe de várias configurações de depuração que podem limitá-la a períodos com cargas menores ou fora dos horários de pico.

Se o cluster tem carga alta durante o dia e carga baixa à noite, considere restringir a depuração a horários noturnos, como das 23h às 6h:

[osd]
osd_scrub_begin_hour = 23
osd_scrub_end_hour = 6

Se a restrição de horário não for um método eficaz para determinar uma programação de depuração, considere usar a opção osd_scrub_load_threshold. O valor padrão é 0,5, mas ele pode ser modificado para condições de carga baixa:

[osd]
osd_scrub_load_threshold = 0.25

18.2 Parando os OSDs sem redistribuição

Você precisa parar os OSDs para manutenção periódica. Se você não deseja que o CRUSH redistribua automaticamente o cluster para evitar transferências grandes de dados, defina o cluster primeiro como noout:

root@minion > ceph osd set noout

Se o cluster estiver definido como noout, você poderá iniciar a interrupção dos OSDs no domínio de falha que requer o trabalho de manutenção:

root@minion > systemctl stop ceph-osd@OSD_NUMBER.service

Mais informações podem ser encontradas na Seção 3.1.2, “Iniciando, parando e reiniciando serviços individuais”.

Após concluir a manutenção, reinicie os OSDs:

root@minion > systemctl start ceph-osd@OSD_NUMBER.service

Depois que os serviços do OSD forem iniciados, cancele a definição do cluster como noout:

root@minion > ceph osd unset noout

18.3 Sincronização de horário dos nós

O Ceph requer uma sincronização de horário precisa entre os nós específicos. Você deve configurar um nó com seu próprio servidor NTP. Mesmo que você possa apontar todas as instâncias ntpd para um servidor de horário público remoto, isso não é recomendável com o Ceph. Com essa configuração, cada nó no cluster tem seu próprio daemon NTP que se comunica continuamente pela Internet com um conjunto de três ou quatro servidores de horário, todos eles a alguns saltos de distância. Essa solução apresenta um alto grau de variação de latência que torna difícil ou impossível manter a diferença do relógio abaixo de 0,05 segundo (valor exigido pelos Ceph Monitors).

Portanto, use uma única máquina, como o servidor NTP, para o cluster inteiro. Depois disso, a instância ntpd do servidor NTP poderá apontar para o servidor NTP (público) remoto, ou ela poderá ter sua própria fonte de horário. As instâncias ntpd em todos os nós serão depois apontadas para esse servidor local. Essa solução apresenta diversas vantagens, como eliminar tráfego de rede e desvios de relógio desnecessários e diminuir a carga nos servidores NTP públicos. Para obter detalhes sobre como configurar o servidor NTP, consulte o Guia de Administração do SUSE Linux Enterprise Server.

Em seguida, para mudar o horário no cluster, faça o seguinte:

Importante
Importante: Definindo o horário

Em algum momento, é provável que você tenha que reverter o horário. Por exemplo, em caso de mudança do horário de verão para o padrão. Não é recomendável retroceder o horário por um período maior do que o de inatividade do cluster. Avançar o horário não causa nenhum problema.

Procedimento 18.1: Sincronização de horário no cluster
  1. Pare todos os clientes que acessam o cluster do Ceph, principalmente aqueles que usam o iSCSI.

  2. Encerre o cluster do Ceph. Em cada nó, execute:

    systemctl stop ceph.target
    Nota
    Nota

    Se você usa o Ceph e o SUSE OpenStack Cloud, pare também o SUSE OpenStack Cloud.

  3. Verifique se o servidor NTP foi configurado corretamente: todos os daemons ntpd obtêm o horário de uma ou mais fontes na rede local.

  4. Defina o horário correto no servidor NTP.

  5. Verifique se o NTP está em execução e funcionando apropriadamente. Execute em todos os nós:

    status ntpd.service

    ou

    ntpq -p
  6. Inicie todos os nós de monitoramento e verifique se não há nenhum desvio de relógio:

    systemctl start target
  7. Inicie todos os nós OSD.

  8. Inicie os outros serviços do Ceph.

  9. Se você tiver, inicie o SUSE OpenStack Cloud.

18.4 Verificando a gravação de dados sem equilíbrio

Quando os dados são gravados nos OSDs igualmente, o cluster é considerado equilibrado. Cada OSD em um cluster recebe um peso. O peso é um número relativo que informa ao Ceph a quantidade de dados que devem ser gravados no OSD relacionado. Quanto maior o peso, mais dados serão gravados. Se um OSD tiver peso zero, não serão gravados dados nele. Se o peso de um OSD for relativamente alto em comparação com outros OSDs, uma grande parte dos dados será gravada nele, o que torna o cluster desequilibrado.

Os clusters desequilibrados apresentam baixo desempenho e, em caso de falha repentina de um OSD com peso elevado, muitos dados precisam ser movidos para outros OSDs, o que também torna o cluster mais lento.

Para evitar isso, você deve verificar regularmente a quantidade de dados gravados nos OSDs. Se o valor estiver entre 30% a 50% da capacidade de um grupo de OSDs especificada por determinado conjunto de regras, você precisará redefinir o peso dos OSDs. Verifique cada disco e descubra qual deles é preenchido mais rapidamente do que os outros (ou está mais lento no geral) e reduza o peso dele. O mesmo é válido para os OSDs em que não há dados suficientes gravados. Você pode aumentar o peso deles para o Ceph gravar mais dados neles. No exemplo a seguir, você descobrirá o peso de um OSD com ID 13 e redefinirá o peso de 3 para 3,05:

$ ceph osd tree | grep osd.13
 13  3                   osd.13  up  1

 $ ceph osd crush reweight osd.13 3.05
 reweighted item id 13 name 'osd.13' to 3.05 in crush map

 $ ceph osd tree | grep osd.13
 13  3.05                osd.13  up  1
Dica
Dica: Redefinição de peso do OSD por utilização

O comando ceph osd reweight-by-utilization threshold automatiza o processo de redução de peso dos OSDs que estão com excesso de uso. Por padrão, ele diminuirá os pesos dos OSDs que atingiram 120% de uso médio. Porém, se você incluir o comando threshold, ele usará essa porcentagem no lugar.

18.5 Subvolume Btrfs para /var/lib/ceph

Por padrão, o SUSE Linux Enterprise é instalado em uma partição Btrfs. O diretório /var/lib/ceph deve ser excluído de instantâneos e rollbacks Btrfs, principalmente quando há um MON em execução no nó. O DeepSea oferece o executor fs, que pode configurar um subvolume para esse caminho.

18.5.1 Requisitos para nova instalação

Se você está configurando o cluster pela primeira vez, os seguintes requisitos devem ser atendidos antes que você possa usar o executor do DeepSea:

  • O SALT e o DeepSea estão instalados apropriadamente e funcionando de acordo com esta documentação.

  • salt-run state.orch ceph.stage.0 foi invocado para sincronizar todos os módulos do Salt e do DeepSea com os minions.

  • O Ceph ainda não foi instalado, portanto, o ceph.stage.3 ainda não foi executado e o /var/lib/ceph ainda não existe.

18.5.2 Requisitos para instalação existente

Se o cluster já foi instalado, os seguintes requisitos devem ser atendidos antes que você possa usar o executor do DeepSea:

  • O upgrade dos nós foi feito para o SUSE Enterprise Storage e o cluster está sob controle do DeepSea.

  • O cluster do Ceph está funcionando e saudável.

  • O processo de upgrade sincronizou os módulos do Salt e do DeepSea com todos os nós do minion.

18.5.3 Configuração automática

  • No master Salt, execute:

    root@master # salt-run state.orch ceph.migrate.subvolume

    Em nós sem um diretório /var/lib/ceph existente, esse comando fará o seguinte (um nó de cada vez):

    • criará o /var/lib/ceph como um subvolume Btrfs @/var/lib/ceph.

    • montará o novo subvolume e atualizará o /etc/fstab apropriadamente.

    • desabilitará a cópia em gravação para /var/lib/ceph.

    Em nós com uma instalação do Ceph existente, esse comando fará o seguinte (um nó de cada vez):

    • terminará os processos do Ceph em execução.

    • desmontará os OSDs no nó.

    • criará o subvolume Btrfs @/var/lib/ceph e migrará os dados existentes do /var/lib/ceph.

    • montará o novo subvolume e atualizará o /etc/fstab apropriadamente.

    • desabilitará a cópia em gravação para /var/lib/ceph/*, omitindo o /var/lib/ceph/osd/*.

    • remontará os OSDs.

    • reiniciará os daemons Ceph.

18.5.4 Configuração manual

Este procedimento usa o novo executor fs.

  1. Inspeciona o estado de /var/lib/ceph em todos os nós e imprime sugestões sobre como proceder:

    root@master # salt-run fs.inspect_var

    Isso retornará um dos seguintes comandos:

    salt-run fs.create_var
    salt-run fs.migrate_var
    salt-run fs.correct_var_attrs
  2. Execute o comando que foi retornado na etapa anterior.

    Se ocorrer um erro em um dos nós, a execução dos outros nós também será interrompida, e o executor tentará reverter as mudanças realizadas. Consulte os arquivos de registro nos minions com problema para determinar o que houve de errado. Será possível executar novamente o executor depois que o problema for resolvido.

O comando salt-run fs.help gera uma lista de todos os comandos de executor e de módulo referentes ao módulo fs.

18.6 Aumentando os descritores de arquivos

Para os daemons OSD, as operações de leitura/gravação são essenciais para manter o equilíbrio do cluster do Ceph. Geralmente, eles precisam ter muitos arquivos abertos para leitura e gravação ao mesmo tempo. No nível do OS, o número máximo de arquivos abertos ao mesmo tempo é chamado de “número máximo de descritores de arquivos”.

Para evitar que os OSDs fiquem sem descritores de arquivos, você pode anular o valor padrão do OS e especificar o número em /etc/ceph/ceph.conf. Por exemplo:

max_open_files = 131072

Após mudar o max_open_files, você precisará reiniciar o serviço do OSD no nó do Ceph relevante.

18.7 Como usar partições existentes para OSDs incluindo diários OSD

Importante
Importante

Esta seção descreve um tópico avançado que apenas especialistas em armazenamento e desenvolvedores devem consultar. Geralmente, ele é necessário ao usar tamanhos de diário OSD não padrão. Se o tamanho da partição do OSD for menor do que 10 GB, o peso inicial será arredondado para 0 e, como não são inseridos dados nela, você deve aumentar o peso. Não assumimos nenhuma responsabilidade em relação a diários excessivamente preenchidos.

Se você precisar usar partições de disco existentes como nó OSD, as partições de diário e de dados do OSD deverão estar em uma tabela de partição GPT.

Você precisa definir os tipos de partição corretos como as partições do OSD para que o udev as reconheça adequadamente e defina a propriedade delas como ceph:ceph.

Por exemplo, para definir o tipo de partição de diário /dev/vdb1 e de dados /dev/vdb2, execute o seguinte:

sudo sgdisk --typecode=1:45b0969e-9b03-4f30-b4c6-b4b80ceff106 /dev/vdb
sudo sgdisk --typecode=2:4fbd7e29-9d25-41b8-afd0-062c0ceff05d /dev/vdb
Dica
Dica

Os tipos de tabela de partição do Ceph estão relacionados em /usr/lib/udev/rules.d/95-ceph-osd.rules:

cat /usr/lib/udev/rules.d/95-ceph-osd.rules
# OSD_UUID
ACTION=="add", SUBSYSTEM=="block", \
  ENV{DEVTYPE}=="partition", \
  ENV{ID_PART_ENTRY_TYPE}=="4fbd7e29-9d25-41b8-afd0-062c0ceff05d", \
  OWNER:="ceph", GROUP:="ceph", MODE:="660", \
  RUN+="/usr/sbin/ceph-disk --log-stdout -v trigger /dev/$name"
ACTION=="change", SUBSYSTEM=="block", \
  ENV{ID_PART_ENTRY_TYPE}=="4fbd7e29-9d25-41b8-afd0-062c0ceff05d", \
  OWNER="ceph", GROUP="ceph", MODE="660"

# JOURNAL_UUID
ACTION=="add", SUBSYSTEM=="block", \
  ENV{DEVTYPE}=="partition", \
  ENV{ID_PART_ENTRY_TYPE}=="45b0969e-9b03-4f30-b4c6-b4b80ceff106", \
  OWNER:="ceph", GROUP:="ceph", MODE:="660", \
  RUN+="/usr/sbin/ceph-disk --log-stdout -v trigger /dev/$name"
ACTION=="change", SUBSYSTEM=="block", \
  ENV{ID_PART_ENTRY_TYPE}=="45b0969e-9b03-4f30-b4c6-b4b80ceff106", \
  OWNER="ceph", GROUP="ceph", MODE="660"
[...]

18.8 Integração com software de virtualização

18.8.1 Armazenando discos da KVM no cluster do Ceph

Você pode criar uma imagem de disco da máquina virtual controlada pela KVM, armazená-la em um pool do Ceph, opcionalmente, converter o conteúdo de uma imagem existente nela e, em seguida, executar a máquina virtual com qemu-kvm usando a imagem de disco armazenada no cluster. Para obter informações mais detalhadas, consulte o Capítulo 17, Ceph como back end para instância de KVM QEMU.

18.8.2 Armazenando discos da libvirt no cluster do Ceph

Similar à KVM (consulte a Seção 18.8.1, “Armazenando discos da KVM no cluster do Ceph”), você pode usar o Ceph para armazenar máquinas virtuais controladas pela libvirt. A vantagem é que você pode executar qualquer solução de virtualização compatível com libvirt, como KVM, Xen ou LXC. Para obter mais informações, consulte o Capítulo 16, Usando a libvirt com o Ceph.

18.8.3 Armazenando discos do Xen no cluster do Ceph

Uma forma de usar o Ceph para armazenar discos do Xen é usar a libvirt conforme descrito no Capítulo 16, Usando a libvirt com o Ceph.

Outra opção é fazer com que o Xen se comunique diretamente com o driver de dispositivo de blocos rbd:

  1. Se você não tem uma imagem de disco preparada para Xen, crie uma nova:

    rbd create myimage --size 8000 --pool mypool
  2. Liste as imagens no pool mypool e verifique se a nova imagem está lá:

    rbd list mypool
  3. Crie um novo dispositivo de blocos mapeando a imagem myimage para o módulo rbd do kernel:

    sudo rbd map --pool mypool myimage
    Dica
    Dica: Nome e autenticação de usuário

    Para especificar um nome de usuário, utilize --id user-name. Além disso, se você usar a autenticação cephx, deverá também especificar um segredo. Ele pode vir de um chaveiro ou de um arquivo que contém o segredo:

    sudo rbd map --pool rbd myimage --id admin --keyring /path/to/keyring

    ou

    sudo rbd map --pool rbd myimage --id admin --keyfile /path/to/file
  4. Liste todos os dispositivos mapeados:

    rbd showmapped
     id pool   image   snap device
     0  mypool myimage -    /dev/rbd0
  5. Agora, você pode configurar o Xen para usar esse dispositivo como disco para executar uma máquina virtual. Por exemplo, você pode adicionar a seguinte linha ao arquivo de configuração de domínio no estilo xl:

    disk = [ '/dev/rbd0,,sda', '/dev/cdrom,,sdc,cdrom' ]

18.9 Configurações de firewall para o Ceph

Atenção
Atenção: Falha nas fases do DeepSea com firewall

Há falha nas fases de implantação do DeepSea quando o firewall está ativo (e até configurado). Para percorrer as fases corretamente, você precisa desativar o firewall executando

root@master # systemctl stop SuSEfirewall2.service

ou definir a opção FAIL_ON_WARNING como “False” em /srv/pillar/ceph/stack/global.yml:

FAIL_ON_WARNING: False

É recomendável proteger a comunicação do cluster de rede com o SUSE Firewall. Você pode editar sua configuração selecionando YaST › Security and Users (Segurança e Usuários) › Firewall › Allowed Services (Serviços Permitidos).

Veja a seguir uma lista de serviços relacionados do Ceph e os números de porta que eles costumam usar:

Ceph Monitor

Habilitar o serviço Ceph MON ou a porta 6789 (TCP).

Ceph OSD ou Servidor de Metadados

Habilitar o serviço Ceph OSD/MDS ou as portas 6800-7300 (TCP).

iSCSI Gateway

Porta 3260 aberta (TCP).

Object Gateway

Abrir a porta de comunicação do Object Gateway. Isso é definido no /etc/ceph.conf na linha que começa com rgw frontends =. O padrão é 80 para HTTP e 443 para HTTPS (TCP).

NFS Ganesha

Por padrão, o NFS Ganesha usa as portas 2049 (serviço NFS, TCP) e 875 (suporte a rquota, TCP). Consulte a Seção 14.2.3, “Mudando as portas padrão do NFS Ganesha” para obter mais informações sobre como mudar as portas padrão do NFS Ganesha.

Serviços com base no Apache, como openATTIC, SMT ou SUSE Manager

Portas abertas 80 para HTTP e 443 para HTTPS (TCP).

SSH

Porta 22 aberta (TCP).

NTP

Porta 123 aberta (UDP).

Salt

Portas 4505 e 4506 abertas (TCP).

Grafana

Porta 3000 aberta (TCP).

Prometheus

Porta 9100 aberta (TCP).

18.10 Testando o desempenho da rede

Para testar o desempenho da rede, o executor net do DeepSea oferece os comandos a seguir.

  • Um ping simples para todos os nós:

    root@master # salt-run net.ping
    Succeeded: 9 addresses from 9 minions average rtt 1.35 ms
  • Um ping jumbo para todos os nós:

    root@master # salt-run net.jumbo_ping
    Succeeded: 9 addresses from 9 minions average rtt 2.13 ms
  • Um teste de largura de banda:

    root@master # salt-run net.iperf
    Fastest 2 hosts:
        |_
          - 192.168.58.106
          - 2981 Mbits/sec
        |_
          - 192.168.58.107
          - 2967 Mbits/sec
    Slowest 2 hosts:
        |_
          - 192.168.58.102
          - 2857 Mbits/sec
        |_
          - 192.168.58.103
          - 2842 Mbits/sec

18.11 Substituindo o disco de armazenamento

Se você precisa substituir um disco de armazenamento em um cluster do Ceph, pode fazer isso durante a plena operação do cluster. A substituição provocará um aumento temporário da transferência de dados.

Se houver falha no disco inteiro, o Ceph precisará regravar pelo menos a mesma quantidade de dados que a capacidade do disco com falha. Se o disco for removido apropriadamente e, em seguida, reinserido para evitar perda de redundância durante o processo, a quantidade de dados regravados será duas vezes maior. Se o novo disco tiver um tamanho diferente daquele que foi substituído, isso causará a redistribuição de alguns dados adicionais para nivelar o uso de todos os OSDs.

Imprimir esta página