cephx
/var/lib/ceph
em nós do Ceph MonitorO capítulo apresenta informações para ajudar você a melhorar o desempenho do cluster do Ceph e inclui dicas de como configurá-lo.
Para identificar dispositivos de diário/WAL/BD possivelmente órfãos, siga estas etapas:
Selecione o dispositivo que pode ter partições órfãs e grave a lista de suas partições em um arquivo:
root@minion >
ls /dev/sdd?* > /tmp/partitions
Execute readlink
em todos os dispositivos block.wal, block.db e de diário e compare a saída com a lista de partições que foi gravada:
root@minion >
readlink -f /var/lib/ceph/osd/ceph-*/{block.wal,block.db,journal} \
| sort | comm -23 /tmp/partitions -
A saída é a lista de partições que não são usadas pelo Ceph.
Remova as partições órfãs que não pertencem ao Ceph usando o comando de sua preferência (por exemplo, fdisk
, parted
ou sgdisk
).
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.
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:
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.
Pare todos os clientes que acessam o cluster do Ceph, principalmente aqueles que usam o iSCSI.
Encerre o cluster do Ceph. Em cada nó, execute:
root #
systemctl stop ceph.target
Se você usa o Ceph e o SUSE OpenStack Cloud, pare também o SUSE OpenStack Cloud.
Verifique se o servidor NTP foi configurado corretamente: todos os daemons chronyd
obtêm o horário de uma ou mais fontes na rede local.
Defina o horário correto no servidor NTP.
Verifique se o NTP está em execução e funcionando apropriadamente. Execute em todos os nós:
root #
systemctl status chronyd.service
Inicie todos os nós de monitoramento e verifique se não há nenhum desvio de relógio:
root #
systemctl start target
Inicie todos os nós OSD.
Inicie os outros serviços do Ceph.
Se você tiver, inicie o SUSE OpenStack Cloud.
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
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.
/var/lib/ceph
em nós do Ceph Monitor #
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.
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.
O Salt e o DeepSea precisam estar instalados e funcionando apropriadamente.
Se o seu cluster já estiver instalado, os seguintes requisitos deverão ter sido atendidos:
O upgrade dos nós foi feito para o SUSE Enterprise Storage 6 e o cluster está sob controle do DeepSea.
O cluster do Ceph está funcionando e saudável.
O processo de upgrade sincronizou os módulos do Salt e do DeepSea com todos os nós do minion.
Antes de executar a fase 0 do DeepSea, aplique os seguintes comandos a cada um dos minions Salt que se tornarão Ceph Monitors:
root@master #
salt 'MONITOR_NODES' saltutil.sync_allroot@master #
salt 'MONITOR_NODES' state.apply ceph.subvolume
O comando ceph.subvolume
faz o seguinte:
Cria o /var/lib/ceph
como um subvolume Btrfs @/var/lib/ceph
.
Monta o novo subvolume e atualiza o /etc/fstab
apropriadamente.
Se você se esqueceu de executar os comandos mencionados na Seção 25.6.2.1, “Antes de executar a fase 0 do DeepSea” antes de executar a fase 0, o subdiretório /var/lib/ceph
já existe, o que causa uma falha na validação da fase 3 do DeepSea. Para convertê-lo em um subvolume, faça o seguinte:
Mude o diretório para /var/lib
:
cephadm@mon >
cd /var/lib
Faça backup do conteúdo atual do subdiretório ceph
:
cephadm@mon >
sudo mv ceph ceph-
Crie o subvolume, monte-o e atualize o /etc/fstab
:
root@master #
salt 'MONITOR_NODES' state.apply ceph.subvolume
Mude para o subdiretório de backup, sincronize o conteúdo dele com o novo subvolume e, em seguida, remova-o:
cephadm@mon >
cd /var/lib/ceph-cephadm@mon >
rsync -av . ../cephcephadm@mon >
cd ..cephadm@mon >
rm -rf ./ceph-
No SUSE Enterprise Storage 5.5, o diretório /var
não está em um subvolume Btrfs, mas suas subpastas (como /var/log
ou /var/cache
) são subvolumes Btrfs abaixo de “@”. A criação dos subvolumes @/var/lib/ceph
exige primeiro a montagem do subvolume “@” (ele não é montado por padrão) e a criação do subvolume @/var/lib/ceph
abaixo dele.
Veja a seguir exemplos de comandos que ilustram o processo:
root #
mkdir -p /mnt/btrfsroot #
mount -o subvol=@ ROOT_DEVICE /mnt/btrfsroot #
btrfs subvolume create /mnt/btrfs/var/lib/cephroot #
umount /mnt/btrfs
Neste ponto, o subvolume @/var/lib/ceph
foi criado, e você pode continuar conforme descrito na Seção 25.6.2, “Etapas necessárias durante uma nova implantação de cluster”.
A configuração automática do subvolume Btrfs @/var/lib/ceph
nos nós do Ceph Monitor talvez não seja adequada para todos os cenários. É possível migrar o diretório /var/lib/ceph
para um subvolume @/var/lib/ceph
seguindo estas etapas:
Termine os processos do Ceph em execução.
Desmonte os OSDs no nó.
Mude para o subdiretório de backup, sincronize o conteúdo dele com o novo subvolume e, em seguida, remova-o:
cephadm@mon >
cd /var/lib/ceph-cephadm@mon >
rsync -av . ../cephcephadm@mon >
cd ..cephadm@mon >
rm -rf ./ceph-
Remonte os OSDs.
Reinicie os daemons do Ceph.
Encontre informações mais detalhadas sobre a configuração manual no arquivo /srv/salt/ceph/subvolume/README.md
no nó master Salt.
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.
Você pode criar uma imagem de disco da máquina virtual controlada pela KVM, armazená-la em um pool do Ceph, opcionalmente, converter o conteúdo de uma imagem existente nela e, em seguida, executar a máquina virtual com qemu-kvm
usando a imagem de disco armazenada no cluster. Para obter informações mais detalhadas, consulte o Capítulo 24, Ceph como back end para instância de KVM QEMU.
libvirt
no cluster do Ceph #
Similar à KVM (consulte a Seção 25.8.1, “Armazenando discos da KVM no cluster do Ceph”), você pode usar o Ceph para armazenar máquinas virtuais controladas pela libvirt
. A vantagem é que você pode executar qualquer solução de virtualização compatível com libvirt
, como KVM, Xen ou LXC. Para obter mais informações, consulte o Capítulo 23, Usando a libvirt
com o Ceph.
Uma forma de usar o Ceph para armazenar discos do Xen é usar a libvirt
conforme descrito no Capítulo 23, Usando a libvirt
com o Ceph.
Outra opção é fazer com que o Xen se comunique diretamente com o driver de dispositivo de blocos rbd
:
Se você não tem uma imagem de disco preparada para Xen, crie uma nova:
cephadm@adm >
rbd create myimage --size 8000 --pool mypool
Liste as imagens no pool mypool
e verifique se a nova imagem está lá:
cephadm@adm >
rbd list mypool
Crie um novo dispositivo de blocos mapeando a imagem myimage
para o módulo rbd
do kernel:
cephadm@adm >
rbd map --pool mypool myimage
Para especificar um nome de usuário, utilize --id user-name
. Além disso, se você usar a autenticação cephx
, deverá também especificar um segredo. Ele pode vir de um chaveiro ou de um arquivo que contém o segredo:
cephadm@adm >
rbd map --pool rbd myimage --id admin --keyring /path/to/keyring
ou
cephadm
rbd map --pool rbd myimage --id admin --keyfile /path/to/file
Liste todos os dispositivos mapeados:
rbd showmapped
id pool image snap device
0 mypool myimage - /dev/rbd0
Agora, você pode configurar o Xen para usar esse dispositivo como disco para executar uma máquina virtual. Por exemplo, você pode adicionar a seguinte linha ao arquivo de configuração de domínio no estilo xl
:
disk = [ '/dev/rbd0,,sda', '/dev/cdrom,,sdc,cdrom' ]
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
› › › .Veja a seguir uma lista de serviços relacionados do Ceph e os números de porta que eles costumam usar:
Habilitar o serviço
ou a porta 6789 (TCP).Habilite o serviço
ou as portas 6800-7300 (TCP).Porta 3260 aberta (TCP).
Abrir a porta de comunicação do Object Gateway. Isso é definido no /etc/ceph.conf
na linha que começa com rgw frontends =
. O padrão é 80 para HTTP e 443 para HTTPS (TCP).
Por padrão, o NFS Ganesha usa as portas 2049 (serviço NFS, TCP) e 875 (suporte a rquota, TCP). Consulte a Seção 21.2.1.4, “Mudando as portas padrão do NFS Ganesha” para obter mais informações sobre como mudar as portas padrão do NFS Ganesha.
Portas abertas 80 para HTTP e 443 para HTTPS (TCP).
Porta 22 aberta (TCP).
Porta 123 aberta (UDP).
Portas 4505 e 4506 abertas (TCP).
Porta 3000 aberta (TCP).
Porta 9100 aberta (TCP).
Para testar o desempenho da rede, o executor net
do DeepSea oferece os comandos a seguir:
Um ping simples para todos os nós:
root@master #
salt-run
net.ping Succeeded: 9 addresses from 9 minions average rtt 1.35 ms
Um ping jumbo para todos os nós:
root@master #
salt-run
net.jumbo_ping Succeeded: 9 addresses from 9 minions average rtt 2.13 ms
Um teste de largura de banda:
root@master #
salt-run
net.iperf Fastest 2 hosts: |_ - 192.168.58.106 - 2981 Mbits/sec |_ - 192.168.58.107 - 2967 Mbits/sec Slowest 2 hosts: |_ - 192.168.58.102 - 2857 Mbits/sec |_ - 192.168.58.103 - 2842 Mbits/sec
Ao executar um teste usando o executor net.iperf
, os processos do servidor “iperf3” iniciados não são automaticamente interrompidos quando um teste é concluído. Para interromper os processos, use o seguinte executor:
root@master #
salt '*' multi.kill_iperf_cmd
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:
Fornecedor/Controladora de Disco | Ferramenta |
---|---|
HPE SmartArray | hpssacli |
LSI MegaRAID | storcli |
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 onroot #
salt-run disk_led.device srv16.ceph sdd ident offroot #
salt-run disk_led.device srv16.ceph sdd fault onroot #
salt-run disk_led.device srv16.ceph sdd fault off
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:
Faça as mudanças necessárias no /srv/pillar/ceph/disk_led.sls
no nó master Salt.
Verifique se as mudanças estão refletidas corretamente nos dados do pillar:
root #
salt 'SALT MASTER*' pillar.get disk_led
Atualize os dados do pillar em todos os nós usando:
root #
salt '*' saltutil.pillar_refresh
É 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