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

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

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

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

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.

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.

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

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"
[...]

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:

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

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.