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

20 Solução de problemas

Este capítulo descreve vários problemas que você pode ter ao operar um cluster do Ceph.

20.1 Relatando problemas de software

Se você tiver algum problema durante a execução do SUSE Enterprise Storage relacionado a alguns dos seus componentes, como Ceph ou Object Gateway, relate-o ao Suporte Técnico da SUSE. A forma recomendada é pelo utilitário supportconfig.

Dica
Dica

Como o supportconfig é um software modular, verifique se o pacote supportutils-plugin-ses está instalado.

rpm -q supportutils-plugin-ses

Se ele estiver ausente no servidor Ceph, instale-o com

zypper ref && zypper in supportutils-plugin-ses

Embora você possa usar o supportconfig na linha de comando, é recomendável usar o módulo do YaST relacionado. Há mais informações a respeito do supportconfig em https://www.suse.com/documentation/sles-12/singlehtml/book_sle_admin/book_sle_admin.html#sec.admsupport.supportconfig.

20.2 Falha ao enviar objetos grandes pelo rados com OSD completo

O rados é um utilitário de linha de comando que gerencia o armazenamento de objeto RADOS. Para obter mais informações, consulte man 8 rados.

Se você enviar um objeto grande para um cluster do Ceph com o utilitário rados, como

rados -p mypool put myobject /file/to/send

ele poderá preencher todo o espaço do OSD relacionado e causar sérios problemas no desempenho do cluster.

20.3 Sistema de arquivos XFS corrompido

Em raras circunstâncias, como bug de kernel ou hardware defeituoso/mal configurado, o sistema de arquivos adjacente (XFS) no qual um OSD armazena os dados pode ser danificado e incapaz de ser montado.

Se você tem certeza de que não há nenhum problema com o hardware e o sistema está configurado apropriadamente, emita um bug no subsistema XFS do kernel do SUSE Linux Enterprise Server e marque o OSD específico como inativo:

ceph osd down OSD identification
Atenção
Atenção: Não formatar ou, de alguma forma, modificar o dispositivo danificado

Mesmo que pareça plausível usar o xfs_repair para corrigir o problema no sistema de arquivos, não o utilize, pois o comando modifica o sistema de arquivos. O OSD pode ser iniciado, mas seu funcionamento talvez seja afetado.

Agora, limpe (zap) o disco subjacente e recrie o OSD executando:

ceph-disk prepare --zap $OSD_DISK_DEVICE $OSD_JOURNAL_DEVICE"

Por exemplo:

ceph-disk prepare --zap /dev/sdb /dev/sdd2

20.4 Mensagem de status “Too Many PGs per OSD”

Se você receber uma mensagem Too Many PGs per OSD após executar ceph status, isso significa que o valor mon_pg_warn_max_per_osd (por padrão, 300) foi excedido. Esse valor é comparado ao número proporcional de PGs por OSD. Isso significa que a configuração do cluster não é a ideal.

O número de PGs não pode ser reduzido depois que o pool é criado. Os pools que ainda não contêm dados podem ser apagados com segurança e, em seguida, recriados com um número menor de PGs. Para os pools que já contêm dados, a única solução é adicionar OSDs ao cluster para que a proporção de PGs por OSD seja reduzida.

20.5 Mensagem de status “nn pg stuck inactive”

Se você receber uma mensagem de status stuck inactive após executar ceph status, isso significa que o Ceph não sabe onde replicar os dados armazenados para atender às regras de replicação. Isso pode ocorrer logo após a configuração inicial do Ceph e é autocorrigido. Em outros casos, isso pode exigir uma interação manual, como recuperar um OSD com defeito ou adicionar um novo OSD ao cluster. Em casos muito raros, a redução do nível de replicação pode ajudar.

Se os grupos de posicionamento estiverem travados permanentemente, será necessário verificar a saída de ceph osd tree. A saída deve ter uma estrutura da árvore, parecida com o exemplo na Seção 20.7, “OSD está inativo”.

Se a saída de ceph osd tree for bem simples como no exemplo a seguir

ceph osd tree
ID WEIGHT TYPE NAME    UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1      0 root default
 0      0 osd.0             up  1.00000          1.00000
 1      0 osd.1             up  1.00000          1.00000
 2      0 osd.2             up  1.00000          1.00000

Você deverá verificar se o mapa CRUSH relacionado tem uma estrutura da árvore. Se ele também for simples, ou sem hosts como no exemplo acima, isso poderá significar que a resolução de nome de host não está funcionando corretamente no cluster.

Se a hierarquia estiver incorreta (por exemplo, a raiz contém hosts, mas os OSDs estão no nível superior e não foram atribuídos a hosts), você precisará mover os OSDs para o local correto na hierarquia. Isso pode ser feito usando os comandos ceph osd crush move e/ou ceph osd crush set. Para obter mais detalhes, consulte a Seção 6.4, “Manipulação de mapa CRUSH”.

20.6 Peso do OSD é 0

Ao ser iniciado, um peso é atribuído ao OSD. Quanto maior o peso, maior a chance de o cluster gravar dados no OSD. O peso é especificado em um Mapa CRUSH do cluster ou calculado pelo script de inicialização dos OSDs.

Em alguns casos, o valor calculado do peso dos OSDs pode ser arredondado para zero. Isso significa que o OSD não está programado para armazenar dados, e não há dados gravados nele. O motivo mais comum é que o disco é muito pequeno (menor do que 15 GB) e deve ser substituído por um maior.

20.7 OSD está inativo

O daemon OSD está em execução ou parado/inativo. Há 3 motivos gerais para um OSD inativo:

  • Falha no disco rígido.

  • Falha no OSD.

  • Falha no servidor.

Você pode ver o status detalhado dos OSDs executando

ceph osd tree
# id  weight  type name up/down reweight
 -1    0.02998  root default
 -2    0.009995   host doc-ceph1
 0     0.009995      osd.0 up  1
 -3    0.009995   host doc-ceph2
 1     0.009995      osd.1 up  1
 -4    0.009995   host doc-ceph3
 2     0.009995      osd.2 down  1

A listagem de exemplo mostra que o osd.2 está inativo. Em seguida, você pode verificar se o disco onde está o OSD foi montado:

lsblk -f
 [...]
 vdb
 ├─vdb1               /var/lib/ceph/osd/ceph-2
 └─vdb2

Você pode monitorar o motivo pelo qual o OSD está inativo inspecionando o arquivo de registro /var/log/ceph/ceph-osd.2.log. Após localizar e corrigir o problema que impossibilita a execução do OSD, inicie-o com

sudo systemctl start ceph-osd@2.service

Lembre-se de substituir 2 pelo número real do seu OSD parado.

20.8 Descobrindo OSDs lentos

Ao ajustar o desempenho do cluster, é muito importante identificar armazenamento/OSDs lentos no cluster. O motivo é que, se os dados forem gravados no disco (mais) lento, toda a operação de gravação ficará lenta, pois ela sempre espera sua conclusão em todos os discos relacionados.

Não é simples localizar o gargalo no armazenamento. Será preciso examinar cada OSD para descobrir os que estão atrasando o processo de gravação. Para fazer um benchmark em um único OSD, execute:

ceph tell osd.OSD_ID_NUMBER bench

Por exemplo:

root # ceph tell osd.0 bench
 { "bytes_written": 1073741824,
   "blocksize": 4194304,
   "bytes_per_sec": "19377779.000000"}

Em seguida, você precisa executar esse comando em cada OSD e comparar o valor de bytes_per_sec para descobrir os OSDs (mais) lentos.

20.9 Corrigindo avisos de diferença do relógio

As informações de horário em todos os nós do cluster devem estar sincronizadas. Se o horário de um nó não estiver totalmente sincronizado, você poderá receber avisos de diferença do relógio ao verificar o estado do cluster.

A sincronização de horário é gerenciada com o NTP (consulte http://en.wikipedia.org/wiki/Network_Time_Protocol). Defina cada nó para sincronizar o horário com um ou mais servidores NTP, de preferência com o mesmo grupo de servidores NTP. Se a diferença de horário ainda ocorrer em um nó, siga estas etapas para corrigi-la:

systemctl stop ntpd.service
systemctl stop ceph-mon.target
systemctl start ntpd.service
systemctl start ceph-mon.target

Você pode consultar os peers NTP e verificar a diferença de horário com sudo ntpq -p.

Os relógios dos Ceph Monitors precisam estar sincronizados com no máximo 0,05 segundo entre eles. Consulte a Seção 18.3, “Sincronização de horário dos nós” para obter mais informações.

20.10 Cluster de baixo desempenho causado por problemas de rede

Há outros motivos que podem prejudicar o desempenho do cluster. Um deles pode ser problemas de rede. Nesse caso, você pode observar que o cluster está atingindo o quorum, o OSD e os nós do monitor estão offline, a transferência de dados está levando muito tempo ou há muitas tentativas de reconexão.

Para verificar se o desempenho do cluster está prejudicado por problemas de rede, consulte os arquivos de registro do Ceph no diretório /var/log/ceph.

Para corrigir problemas de rede no cluster, observe atentamente os seguintes pontos:

  • Diagnóstico básico da rede. Tente o executor das ferramentas de diagnóstico do DeepSea net.ping para efetuar ping entre os nós do cluster para ver se uma interface pode acessar outra específica e o tempo médio de resposta. Qualquer tempo de resposta específico muito mais lento do que a média também será relatado. Por exemplo:

    root@master # salt-run net.ping
      Succeeded: 8 addresses from 7 minions average rtt 0.15 ms

    Tente validar toda a interface com a habilitação de JumboFrame:

    root@master # salt-run net.jumbo_ping
      Succeeded: 8 addresses from 7 minions average rtt 0.26 ms
  • Benchmark de desempenho de rede. Tente o executor de desempenho de rede do DeepSea net.iperf para testar a largura de banda de rede do nó interno. Em determinado nó do cluster, um número de processos iperf (conforme o número de núcleos de CPU) são iniciados como servidores. Os nós restantes do cluster serão usados como clientes para gerar tráfego de rede. A largura de banda acumulada de todos os processos iperf por nó será relatada. Isso deve refletir o throughput máximo de rede atingível em todos os nós do cluster. Por exemplo:

    root@master # salt-run net.iperf cluster=ceph output=full
    192.168.128.1:
        8644.0 Mbits/sec
    192.168.128.2:
        10360.0 Mbits/sec
    192.168.128.3:
        9336.0 Mbits/sec
    192.168.128.4:
        9588.56 Mbits/sec
    192.168.128.5:
        10187.0 Mbits/sec
    192.168.128.6:
        10465.0 Mbits/sec
  • Verifique as configurações de firewall nos nós do cluster. Certifique-se de que elas não bloqueiem as portas/protocolos necessários à operação do Ceph. Consulte a Seção 18.9, “Configurações de firewall para o Ceph” para obter mais informações sobre as configurações de firewall.

  • Verifique se o hardware de rede, como placas de rede, cabos ou switches, está funcionando apropriadamente.

Dica
Dica: Rede separada

Para garantir uma comunicação de rede rápida e segura entre os nós do cluster, configure uma rede separada usada exclusivamente pelos nós OSD e de monitor do cluster.

20.11 Pouco espaço em /var

Por padrão, o master Salt grava o retorno de cada minion para cada tarefa no cache de tarefas. Em seguida, o cache pode ser usado para pesquisa de resultados em tarefas anteriores. O diretório de cache padrão é /var/cache/salt/master/jobs/.

Cada retorno de tarefa de cada minion é gravado em um único arquivo. Ao longo do tempo, esse diretório pode ficar muito grande, dependendo do número de tarefas publicadas e do valor da opção keep_jobs no arquivo /etc/salt/master. keep_jobs define o número de horas (24, por padrão) para manter as informações sobre as tarefas anteriores dos minions.

keep_jobs: 24
Importante
Importante: Não definir keep_jobs: 0

Definir keep_jobs como “0” faz com que a limpeza do cache de tarefas nunca seja executada, o que pode resultar em uma partição cheia.

Para desabilitar o cache de tarefas, defina job_cache como “Falso”:

job_cache: False
Dica
Dica: Restaurando a partição cheia devido ao cache de tarefas

Quando a partição com arquivos de cache de tarefas ficar cheia por causa da configuração incorreta de keep_jobs, siga estas etapas para liberar espaço no disco e melhorar as configurações do cache de tarefas:

  1. Pare o serviço master Salt:

    root@master # systemctl stop salt-master
  2. Mude a configuração do master Salt relacionada ao cache de tarefas editando /etc/salt/master:

    job_cache: False
    keep_jobs: 1
  3. Limpe o cache de tarefas do master Salt:

    rm -rfv /var/cache/salt/master/jobs/*
  4. Inicie o serviço master Salt:

    root@master # systemctl start salt-master
Imprimir esta página