Ele não precisa de você

Em conexão com a crescente popularidade de Rook, quero falar sobre as armadilhas e os problemas que esperam por você no caminho.

Sobre mim: Experiência em administração do Ceph com a versão hammer, fundador da comunidade t.me/ceph_ru em telegramas.

Para não ser infundado, vou me referir a posts aceitos pelo Habr (a julgar pela classificação) sobre problemas com o ceph. Também encontrei a maioria dos problemas nessas postagens. Links para o material usado no final do post.

No post sobre Rook, mencionamos ceph por uma razão - Rook é essencialmente ceph envolto em kubernetes, o que significa que herda todos os seus problemas. Começaremos com problemas de ceph.

Simplifique o gerenciamento de cluster

Uma das vantagens do Rook é a conveniência de gerenciar o ceph através do kuberentes.

No entanto, o ceph contém mais de 1000 parâmetros para ajuste, ao mesmo tempo através da torre, podemos editar apenas uma pequena parte deles.

Exemplo luminoso
> ceph daemon mon.a show de configuração | wc -l
1401

Rook está posicionado como uma maneira conveniente de instalar e atualizar ceph
Não há problemas com a instalação do ceph sem o Rook - playbook gravável em 30 minutos, mas há muitos problemas com a atualização dos problemas.

Citação da postagem de Krok

Exemplo: operação incorreta de tunables de esmagamento após a atualização do hummer para a jóia

> ceph osd crush show-tunables
{
...
"Straw_calc_version": 1,
"Allowed_bucket_algs": 22,
"Perfil": "desconhecido",
Optimal_tunables: 0,
...
}

Mas mesmo nas versões secundárias existem problemas.

Exemplo: Atualização 12.2.6, trazendo o cluster à integridade, erro e PG condicionalmente interrompido
ceph.com/releases/v12-2-8-released

Não atualize, espere e teste? Mas nós meio que usamos o Rook para a conveniência de atualizações também.

A complexidade do cluster de recuperação de desastre no Rook

Exemplo: OSD trava erros de erupção sob seus pés. Você suspeita que o problema esteja em um dos parâmetros na configuração, você deseja alterar a configuração para um daemon específico, mas não pode, porque possui o kubernetes e o DaemonSet.

Não há alternativa. ceph dizer osd.Num injectargs não funciona - OSD mentiras.

Complexidade de depuração

Para algumas configurações e testes de desempenho, você deve se conectar diretamente ao soquete daemon osd. No caso do Rook, você primeiro precisa encontrar o contêiner certo, depois entrar nele, encontrar o ajuste de depuração ausente e ficar muito chateado.

A dificuldade de elevar sequencialmente o OSD

Exemplo: o OSD cai no OOM, o reequilíbrio começa e, no outono seguinte.

Solução: aumente o OSD, um de cada vez, aguarde até que seja totalmente incluído no cluster e aumente os próximos. (Mais no relatório da Ceph. Anatomia de um desastre.)

No caso da instalação baremetal, isso é feito manualmente, no caso de Rook e um OSD no nó, não há problemas específicos; problemas com elevação sucessiva ocorrerão se OSD> 1 no nó.

Obviamente, eles são solucionáveis, mas nós carregamos o Rook para simplificação, mas temos complicações.

A dificuldade de selecionar limites para os demônios ceph

Para instalações de cepa baremetal, é fácil calcular os recursos necessários por cluster - existem fórmulas e estudos. Ao usar CPUs fracas, você ainda precisa realizar uma série de testes de desempenho para descobrir o que é o Numa, mas ainda é mais simples do que no Rook.

No caso de Rook, além dos limites de memória que podem ser calculados, surge a questão de definir o limite da CPU.

E então você precisa suar com testes de desempenho. No caso de subestimar os limites, você obterá um cluster lento; no caso de definir unlim, você receberá um uso ativo da CPU com reequilíbrio, o que afetará gravemente seus aplicativos nos kubernetes.

Problemas de rede v1

Para o ceph, é recomendável usar uma rede de 2x10gb. Um para o tráfego do cliente, outro para o escritório usa ceph (reequilíbrio). Se você mora com ceph no baremetal, essa separação é fácil de configurar; se você mora com o Rook, a separação por redes causará problemas para você, porque nem todas as configurações de cluster permitem que duas redes diferentes sejam submetidas ao pod.

Problemas de rede v2

Se você se recusar a compartilhar redes, com o reequilíbrio, o tráfego ceph obstruirá o canal inteiro e seus aplicativos no kubernetes ficarão mais lentos ou travarão. Você pode reduzir a taxa de reequilíbrio de ceph, mas, devido ao reequilíbrio longo, você aumenta o risco de o segundo nó cair do cluster em discos ou OOM e já existe garantia de leitura apenas no cluster.

Rebalanceamento longo - freios de aplicação longos

Cite um post do Ceph. Anatomia do desastre.

Teste de desempenho do cluster:

Uma operação de gravação de 4 KB leva 1 ms, realiza 1000 operações / segundo em 1 fluxo.

Uma operação de 4 MB de tamanho (tamanho do objeto) leva 22 ms, desempenho 45 operações / segundo.

Portanto, quando um dos três domínios falha, o cluster fica em um estado degradado por algum tempo e metade dos objetos ativos se espalha de acordo com versões diferentes, e metade das operações de gravação começa com uma recuperação forçada.

O tempo de recuperação forçada é calculado aproximadamente - operações de gravação em um objeto degradado.

Primeiro, lemos 4 MB em 22 ms, escrevemos 22 ms e, em seguida, 1 ms, escrevemos 4 KB de dados. No total, 45 ms para uma operação de gravação em um objeto degradado no SSD, quando tivemos um desempenho padrão de 1 ms - uma queda de desempenho de 45 vezes.

Quanto mais temos a porcentagem de objetos degradados, pior fica.

Acontece que a taxa de reequilíbrio é crítica para a operação correta do cluster.

Configurações específicas do servidor para ceph

O ceph pode precisar de um ajuste específico do host.

Exemplo: configurações sysctl e o mesmo JumboFrame, algumas dessas configurações podem afetar negativamente sua carga útil.

A real necessidade de uma torre permanece em questão

Se você estiver na nuvem, possui armazenamento do seu provedor de nuvem, o que é muito mais conveniente.

Se você estiver em seus servidores, o gerenciamento do ceph será mais conveniente sem o kubernetes.

Você aluga um servidor em alguma hospedagem de baixo custo? Então você se divertirá muito com a rede, seus atrasos e largura de banda, o que obviamente afeta negativamente o ceph.

Total: A introdução de kuberentes e a introdução do repositório são tarefas diferentes, com diferentes opções introdutórias e diferentes de solução - para misturá-las, isso significa fazer uma troca possivelmente perigosa por causa disso ou daquilo. A combinação dessas soluções será muito difícil, mesmo na fase de projeto, e ainda há um período de operação.

Lista de literatura usada:

Post # 1 Mas você diz Ceph ... mas ele é bom?
Post # 2 Ceph. Anatomia do desastre