rados
com OSD completo/var
Este capítulo descreve vários problemas que você pode ter ao operar um cluster do Ceph.
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
.
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.
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.
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
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
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.
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”.
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.
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.
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.
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.
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.
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.
/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
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
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:
Pare o serviço master Salt:
root@master #
systemctl stop salt-master
Mude a configuração do master Salt relacionada ao cache de tarefas editando /etc/salt/master
:
job_cache: False keep_jobs: 1
Limpe o cache de tarefas do master Salt:
rm -rfv /var/cache/salt/master/jobs/*
Inicie o serviço master Salt:
root@master #
systemctl start salt-master