Com a crescente popularidade do Rook, gostaria de discutir suas armadilhas e problemas que você encontrará pelo caminho.
Sobre mim: Experiência na administração de ceph desde a versão hammer, fundador da comunidade no Telegram.
Para não ficar só na palavra, me referirei a posts aceitos no Habr (segundo a classificação) sobre problemas com ceph. Enfrentei a maioria dos problemas mencionados nesses posts. Links para o material utilizado no final do post.
No post sobre Rook, mencionamos ceph não apenas por acaso — o Rook, na verdade, é o ceph envolto no kubernetes, o que significa que herda todos os seus problemas. Vamos começar com os problemas do ceph.
Simplificação da gestão do cluster
Uma das vantagens do Rook é o gerenciamento conveniente do ceph através do kubernetes.
No entanto, o ceph possui mais de 1000 parâmetros de configuração, enquanto através do Rook podemos ajustar apenas uma parte menor deles.
Exemplo no Luminous
> ceph daemon mon.a config show | wc -l
1401
O Rook se posiciona como uma maneira conveniente de instalar e atualizar o ceph
Com a instalação do ceph sem o Rook, não há problemas — o playbook do ansible é escrito em 30 minutos, mas com a atualização, há muitos problemas.
Citação do post do Krok
Exemplo: funcionamento incorreto das tunas do crush após a atualização de hammer para jewel
> ceph osd crush show-tunables
{
…
«straw_calc_version»: 1,
«allowed_bucket_algs»: 22,
«profile»: «unknown»,
«optimal_tunables»: 0,
…
}
Mas mesmo dentro das versões menores, problemas podem ocorrer.
Exemplo: Atualização 12.2.6 que resulta o cluster em estado de health err e PG condicionalmente corrompido
Não atualizar, esperar e testar? Mas estamos usando o Rook também pela conveniência das atualizações.
Dificuldade de recuperação de desastre do cluster no Rook
Exemplo: OSD falha enchendo de erros por conta própria. Você suspeita que o problema está em um dos parâmetros da configuração, quer alterar a configuração para um demônio específico, mas não pode, pois você tem kubernetes e DaemonSet.
Não há alternativa. ceph tell osd.Num injectargs não funciona — OSD está inativo.
Dificuldade de depuração
Para algumas configurações e testes de desempenho, é necessário se conectar diretamente ao soquete do demônio osd. No caso do Rook, é preciso primeiro encontrar o contêiner adequado, depois entrar nele, descobrir a ausência de ferramentas de depuração e se frustrar bastante.
Dificuldade de elevação sequencial do OSD
Exemplo: OSD falha por OOM, começa o re-balanceamento, e em seguida os próximos falham.
Solução: Levantar OSD um por um, aguardando a completa inclusão no cluster antes de levantar os seguintes. (Mais detalhes no relatório Ceph. Anatomia do desastre).
No caso de instalação baremetal, isso é feito facilmente à mão; no caso de Rook e uma OSD por nó, não há grandes problemas, os problemas no levantamento sequencial surgirão se OSD > 1 por nó.
Claro, eles são solucionáveis, mas estamos utilizando Rook para simplificar, e acabamos complicando.
Dificuldade em definir limites para os demônios do ceph
Para a instalação baremetal do ceph, é fácil calcular os recursos necessários para o cluster — existem fórmulas e pesquisas. Ao usar CPUs fracas, você ainda terá que fazer uma série de testes de desempenho, entender o que é Numa, mas isso ainda é mais simples do que no Rook.
No caso do Rook, além dos limites de memória que podem ser calculados, surge a questão de definir o limite de CPU.
E aqui você terá que se esforçar com os testes de desempenho. Se os limites forem muito baixos, você terá um cluster lento; se forem ilimitados, haverá um uso ativo da CPU durante o rebalanceamento, o que afetará negativamente suas aplicações no kubernetes.
Problemas de interação de rede v1
Para o ceph, recomenda-se usar uma rede de 2x10gb. Uma para tráfego de cliente, outra para necessidades operacionais do ceph (rebalanceamento). Se você estiver usando ceph em baremetal, essa separação é fácil de configurar; se estiver usando Rook, a separação de redes pode causar problemas, uma vez que nem toda configuração de cluster permite fornecer duas redes diferentes para o pod.
Problemas de interação de rede v2
Se você optar por não separar as redes, durante o rebalanceamento o tráfego do ceph congestionará todo o canal e suas aplicações no kubernetes começarão a desacelerar ou poderão falhar. É possível diminuir a velocidade do rebalanceamento do ceph, mas então, devido ao longo rebalanceamento, você terá um risco aumentado de que o segundo nó saia do cluster devido a problemas de disco ou OOM, e então haverá garantia de leitura somente no cluster.
Longo rebalanceamento — longas lentidões nas aplicações
Citação do post Ceph. Anatomia do desastre.
Desempenho do cluster de teste:
Uma operação de gravação de 4 Kbytes leva 1 ms, com uma taxa de 1000 operações/segundo em 1 thread.
Uma operação de 4 Mbytes (tamanho do objeto) leva 22 ms, com uma taxa de 45 operações/segundo.
Assim, quando um dos três domínios falha, o cluster fica em um estado degradado por algum tempo, e metade dos objetos quentes se espalha por diferentes versões, então metade das operações de gravação começará com a recuperação forçada.
Calcamos o tempo da recuperação forçada de forma aproximada — operações de gravação no objeto degradado.
Primeiro, lemos 4 MB em 22 ms, escrevemos em 22 ms, e então em 1 ms escrevemos 4 KB de dados propriamente ditos. No total, somamos 45 ms em uma operação de gravação no objeto degradado em SSD, quando nosso desempenho normal era de 1 ms — uma queda de desempenho de 45 vezes.
Quanto maior a porcentagem de objetos degradados, pior a situação se torna.
Portanto, a velocidade de reequilíbrio é criticamente importante para o funcionamento correto do cluster.
Configurações específicas de servidores para ceph
O ceph muitas vezes requer um ajuste específico do host.
Exemplo: configurações sysctl e o mesmo JumboFrame, algumas dessas configurações podem impactar negativamente seu payload.
A real necessidade do Rook ainda é questionável.
Se você está na nuvem, tem armazenamento do seu provedor de nuvem, o que é muito mais conveniente.
Se você está em seus próprios servidores, a gestão do ceph será mais conveniente sem o Kubernetes.
Você aluga servidores em algum provedor de hospedagem de baixo custo? Então você encontrará muitas dificuldades com a rede, suas latências e largura de banda, o que afeta negativamente o ceph.
No total: A implementação do Kubernetes e a implementação do armazenamento são tarefas diferentes com diferentes variáveis e diferentes opções de solução - misturá-las significa fazer um trade-off potencialmente perigoso em favor de uma ou outra. Juntar essas soluções será muito difícil mesmo na fase de design, e ainda há o período de operação.
Lista de referências utilizadas:
Mas vocês falam do Ceph... ele é realmente tão bom?
Ceph. Anatomia de uma catástrofe
Fonte: habr.com
