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

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.

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

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

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:

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:

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.

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