Para identificar dispositivos de diário/WAL/BD possivelmente órfãos, siga estas etapas:

Por padrão, o Ceph executa uma depuração diária simples (encontre mais detalhes na Seção 9.6, “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 5.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:

cephadm@adm > ceph osd unset noout

O Ceph requer uma sincronização de horário precisa entre todos os nós.

Recomendamos sincronizar todos os nós do cluster do Ceph com pelo menos três fontes de horário confiáveis localizadas na rede interna. As fontes de horário internas podem apontar para um servidor de horário público ou ter uma fonte de horário própria.

Importante: Servidores de Horário Públicos

Não sincronize todos os nós do cluster do Ceph diretamente com servidores de horário públicos remotos. 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 que podem fornecer horários um pouco diferentes. 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, que é o valor exigido pelos Ceph Monitors.

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: Definição do 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% e 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. Os Ceph Monitors armazenam o estado e o banco de dados deles no diretório /var/lib/ceph. Para evitar que um Ceph Monitor seja corrompido após o rollback de um sistema de um instantâneo anterior, crie um subvolume Btrfs para /var/lib/ceph. Um subvolume dedicado exclui os dados do monitor dos instantâneos do subvolume raiz.

Dica

Crie o subvolume /var/lib/ceph antes de executar a fase 0 do DeepSea, porque essa fase instala os pacotes relacionados do Ceph e cria o diretório /var/lib/ceph.

Em seguida, a fase 3 do DeepSea verifica se o @/var/lib/ceph é um subvolume Btrfs e falhará se for um diretório normal.

root@master # salt 'MONITOR_NODES' saltutil.sync_all
root@master # salt 'MONITOR_NODES' state.apply ceph.subvolume

root # mkdir -p /mnt/btrfs
root # mount -o subvol=@ ROOT_DEVICE /mnt/btrfs
root # btrfs subvolume create /mnt/btrfs/var/lib/ceph
root # umount /mnt/btrfs

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.

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

Esta seção descreve como usar o libstoragemgmt e/ou ferramentas de terceiros para ajustar as luzes de LED nos discos físicos. Esse recurso pode não estar disponível para todas as plataformas de hardware.

Pode ser complexo corresponder um disco OSD a um disco físico, principalmente em nós com alta densidade de discos. Alguns ambientes de hardware incluem luzes de LED que podem ser ajustadas por meio de software para piscar ou acender uma cor diferente com a finalidade de identificação. O SUSE Enterprise Storage oferece suporte a esse recurso por meio do Salt, do libstoragemgmt e de ferramentas de terceiros específicas ao hardware em uso. A configuração para esse recurso está definida no pillar Salt /srv/pillar/ceph/disk_led.sls:

root #  cat /srv/pillar/ceph/disk_led.sls
# This is the default configuration for the storage enclosure LED blinking.
# The placeholder {device_file} will be replaced with the device file of
# the disk when the command is executed.
#
# Have a look into the /srv/pillar/ceph/README file to find out how to
# customize this configuration per minion/host.

disk_led:
  cmd:
    ident:
      'on': lsmcli local-disk-ident-led-on --path '{device_file}'
      'off': lsmcli local-disk-ident-led-off --path '{device_file}'
    fault:
      'on': lsmcli local-disk-fault-led-on --path '{device_file}'
      'off': lsmcli local-disk-fault-led-off --path '{device_file}'

A configuração padrão para o disk_led.sls oferece suporte a LED de disco por meio da camada libstoragemgmt. No entanto, o libstoragemgmt fornece esse suporte por meio de um plug-in específico do hardware e de ferramentas de terceiros. Exceto se o plug-in libstoragemgmt e as ferramentas de terceiros apropriadas ao hardware estiverem instalados, o libstoragemgmt não poderá ajustar os LEDs.

Com ou sem o libstoragemgmt, as ferramentas de terceiros podem ser necessárias para ajustar as luzes de LED. Vários fornecedores de hardware disponibilizam essas ferramentas de terceiros. Alguns dos fornecedores e ferramentas comuns são:

O SUSE Linux Enterprise Server também oferece o pacote ledmon e a ferramenta ledctl. Essa ferramenta também pode funcionar para ambientes de hardware que utilizam compartimentos de armazenamento da Intel. A sintaxe apropriada ao usar essa ferramenta é a seguinte:

root #  cat /srv/pillar/ceph/disk_led.sls
disk_led:
  cmd:
    ident:
      'on': ledctl locate='{device_file}'
      'off': ledctl locate_off='{device_file}'
    fault:
      'on': ledctl locate='{device_file}'
      'off': ledctl locate_off='{device_file}'

Se você estiver em um hardware suportado, com todas as ferramentas de terceiros necessárias, os LEDs poderão ser habilitados ou desabilitados usando a seguinte sintaxe de comando do nó master Salt:

root # salt-run disk_led.device NODE DISK fault|ident on|off

Por exemplo, para habilitar ou desabilitar a identificação por LED ou luzes com falha em /dev/sdd no nó OSD srv16.ceph, execute o seguinte:

root # salt-run disk_led.device srv16.ceph sdd ident on
root # salt-run disk_led.device srv16.ceph sdd ident off
root # salt-run disk_led.device srv16.ceph sdd fault on
root # salt-run disk_led.device srv16.ceph sdd fault off

Nota: Nomeação de Dispositivos

O nome do dispositivo usado no comando salt-run precisa corresponder ao nome que o Salt reconhece. É possível usar o seguinte comando para exibir esses nomes:

root@master # salt 'minion_name' grains.get disks

Em muitos ambientes, a configuração /srv/pillar/ceph/disk_led.sls exigirá mudanças para ajustar as luzes de LED de acordo com as necessidades específicas do hardware. É possível fazer mudanças simples substituindo lsmcli por outra ferramenta ou ajustando os parâmetros da linha de comando. É possível fazer mudanças complexas chamando um script externo no lugar do comando lsmcli. Ao fazer qualquer mudança no /srv/pillar/ceph/disk_led.sls, siga estas etapas:

É possível usar um script externo para usar diretamente as ferramentas de terceiros para ajustar as luzes de LED. Os seguintes exemplos mostram como ajustar o /srv/pillar/ceph/disk_led.sls para suportar um script externo e dois scripts de amostra para ambientes HP e LSI.

/srv/pillar/ceph/disk_led.sls modificado, que chama um script externo:

root # cat /srv/pillar/ceph/disk_led.sls
disk_led:
  cmd:
    ident:
      'on': /usr/local/bin/flash_led.sh '{device_file}' on
      'off': /usr/local/bin/flash_led.sh '{device_file}' off
    fault:
      'on': /usr/local/bin/flash_led.sh '{device_file}' on
      'off': /usr/local/bin/flash_led.sh '{device_file}' off

Script de amostra para piscar luzes de LED no hardware HP usando os utilitários hpssacli:

root # cat /usr/local/bin/flash_led_hp.sh
#!/bin/bash
# params:
#   $1 device (e.g. /dev/sda)
#   $2 on|off

FOUND=0
MAX_CTRLS=10
MAX_DISKS=50

for i in $(seq 0 $MAX_CTRLS); do
  # Search for valid controllers
  if hpssacli ctrl slot=$i show summary >/dev/null; then
    # Search all disks on the current controller
    for j in $(seq 0 $MAX_DISKS); do
      if hpssacli ctrl slot=$i ld $j show | grep -q $1; then
        FOUND=1
        echo "Found $1 on ctrl=$i, ld=$j. Turning LED $2."
        hpssacli ctrl slot=$i ld $j modify led=$2
        break;
      fi
    done
    [[ "$FOUND" = "1" ]] && break
  fi
done

Script de amostra para piscar luzes de LED no hardware LSI usando os utilitários storcli:

root # cat /usr/local/bin/flash_led_lsi.sh
#!/bin/bash
# params:
#   $1 device (e.g. /dev/sda)
#   $2 on|off

[[ "$2" = "on" ]] && ACTION="start" || ACTION="stop"

# Determine serial number for the disk
SERIAL=$(lshw -class disk | grep -A2 $1 | grep serial | awk '{print $NF}')
if [ ! -z "$SERIAL" ]; then
  # Search for disk serial number across all controllers and enclosures
  DEVICE=$(/opt/MegaRAID/storcli/storcli64 /call/eall/sall show all | grep -B6 $SERIAL | grep Drive | awk '{print $2}')
  if [ ! -z "$DEVICE" ]; then
    echo "Found $1 on device $DEVICE. Turning LED $2."
    /opt/MegaRAID/storcli/storcli64 $DEVICE $ACTION locate
  else
    echo "Device not found!"
    exit -1
  fi
else
  echo "Disk serial number not found!"
  exit -1
fi