O capítulo apresenta informações para ajudar você a melhorar o desempenho do cluster do Ceph e inclui dicas de como configurá-lo.
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:
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:
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 ntpd 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:
status ntpd.service
ou
ntpq -p
Inicie todos os nós de monitoramento e verifique se não há nenhum desvio de relógio:
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% 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
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.
Se você está configurando o cluster pela primeira vez, os seguintes requisitos devem ser atendidos antes que você possa usar o executor do DeepSea:
O SALT e o DeepSea estão instalados apropriadamente e funcionando de acordo com esta documentação.
salt-run state.orch ceph.stage.0
foi invocado para sincronizar todos os módulos do Salt e do DeepSea com os minions.
O Ceph ainda não foi instalado, portanto, o ceph.stage.3 ainda não foi executado e o /var/lib/ceph
ainda não existe.
Se o cluster já foi instalado, os seguintes requisitos devem ser atendidos antes que você possa usar o executor do DeepSea:
O upgrade dos nós foi feito para o SUSE Enterprise Storage 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.
No master Salt, execute:
root@master #
salt-run
state.orch ceph.migrate.subvolume
Em nós sem um diretório /var/lib/ceph
existente, esse comando fará o seguinte (um nó de cada vez):
criará o /var/lib/ceph
como um subvolume Btrfs @/var/lib/ceph
.
montará o novo subvolume e atualizará o /etc/fstab
apropriadamente.
desabilitará a cópia em gravação para /var/lib/ceph
.
Em nós com uma instalação do Ceph existente, esse comando fará o seguinte (um nó de cada vez):
terminará os processos do Ceph em execução.
desmontará os OSDs no nó.
criará o subvolume Btrfs @/var/lib/ceph
e migrará os dados existentes do /var/lib/ceph
.
montará o novo subvolume e atualizará o /etc/fstab
apropriadamente.
desabilitará a cópia em gravação para /var/lib/ceph/*
, omitindo o /var/lib/ceph/osd/*
.
remontará os OSDs.
reiniciará os daemons Ceph.
Este procedimento usa o novo executor fs
.
Inspeciona o estado de /var/lib/ceph
em todos os nós e imprime sugestões sobre como proceder:
root@master #
salt-run
fs.inspect_var
Isso retornará um dos seguintes comandos:
salt-run fs.create_var salt-run fs.migrate_var salt-run fs.correct_var_attrs
Execute o comando que foi retornado na etapa anterior.
Se ocorrer um erro em um dos nós, a execução dos outros nós também será interrompida, e o executor tentará reverter as mudanças realizadas. Consulte os arquivos de registro nos minions com problema para determinar o que houve de errado. Será possível executar novamente o executor depois que o problema for resolvido.
O comando salt-run fs.help
gera uma lista de todos os comandos de executor e de módulo referentes ao módulo fs
.
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.
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
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" [...]
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 17, Ceph como back end para instância de KVM QEMU.
libvirt
no cluster do Ceph #
Similar à KVM (consulte a Seção 18.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 16, 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 16, 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:
rbd create myimage --size 8000 --pool mypool
Liste as imagens no pool mypool
e verifique se a nova imagem está lá:
rbd list mypool
Crie um novo dispositivo de blocos mapeando a imagem myimage
para o módulo rbd
do kernel:
sudo 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:
sudo rbd map --pool rbd myimage --id admin --keyring /path/to/keyring
ou
sudo 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@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
› › › .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).Habilitar 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 14.2.3, “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
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.