Os servidores intensivos de io e cpu devem ser separados no cluster do kubernetes?

Question

Estamos projetando uma nova arquitetura de cluster para o nosso serviço da web e estamos planejando usar o armazenamento de objetos Ceph e os kubernetes para nossos serviços. para otimizar nossos servidores Temos diferentes opções:

1. Use servidores idênticos e execute o Ceph e nossos serviços em todos eles e gerencie com kubernetes

2. Como acima, use servidores idênticos, mas rotule alguns deles para o Ceph e não execute serviços neles

3. Use dois tipos de servidores: um otimizado para io e um otimizado para cpu. Em seguida, execute o Ceph on io e os serviços em cpu. e gerenciar todos eles com kubernetes

4. Como acima, tendo dois servidores separados, mas não use kubernetes para os io e deixe o ceph lidar com tudo (não é mais simples não usar os kubernetes para nosso cluster Ceph?)

Eu sei que servidores idênticos têm benefícios de melhor escalonamento. Por outro lado, ter dois tipos de servidores nos permite otimizar cada um deles. Qual é a melhor solução?

    

Answer 1

Algumas coisas a considerar:

Se você estiver usando discos rotativos, convém ter discos separados para o Ceph e para tarefas aleatórias do Kubernetes. Dessa forma, a E / S aleatória das tarefas do kubernetes não quebra a sequencialidade dos acessos do Ceph (especialmente para gravações e leituras grandes). Obviamente, você pode conseguir isso com (2), (3) ou (4). Mas você também pode realizar isso com sua opção (1) se tiver vários discos em seus servidores (JBOD) e alocar cada disco para Ceph ou Kubernetes, mas não para ambos (ou se você usar uma unidade flash separada para Kubernetes, etc ..)

Se os seus servidores otimizados para CPU vierem com um grande disco de inicialização, você pode acabar se sentindo como se o armazenamento estivesse ocioso porque as tarefas de serviço não usam tudo, e mais tarde gostaria de poder executar o Ceph nesses nós também , para desarmar esse armazenamento. Mas se é um pequeno disco / ssd, então você pode não se importar.

Haverá alguma incerteza em quantos servidores você precisa. (por exemplo, crescimento, falhas, estimativas de carga imprecisas). Você tem que comprar demais por causa dessa incerteza. A overbuying é pior com 2 SKUs em vez de 1 SKU. E é mais difícil redirecionar os servidores mais tarde, à medida que suas necessidades mudam. Esse tipo de favorece (1) ou (2).

Do ponto de vista da segurança, talvez você se sinta mais confortável se a veiculação de tarefas não estiver na mesma máquina do armazenamento. Isso é mais importante se você tiver uma variedade de tarefas de serviço diferentes que são confiáveis em diferentes graus.

Não sei ao certo que tipo de "otimização" você deseja fazer com suas SKUs de servidor. Escolher SKUs que se encaixam exatamente em um pod não é uma boa prática. Você deve ter pods menores e confiar no agendador para o pacote de bin.

    

Answer 2

Você deve executar o Ceph no Kubernetes?

Se você quiser usar o Ceph para fornecer PVs para seus contêineres , você deve executá-lo fora do Kubernetes .

Se você estiver olhando para executar o Ceph usando DaemonSet e StatefulSet, você deve considerar isso . Existem algumas sugestões para decidir se isso é adequado para a sua organização.

Que tipos de SKUs você deve comprar?

Se a sua prioridade é otimizar a implantação do Ceph para uma taxa de transferência máxima, você precisará de um ou mais SSDs para o diário do Ceph e vários SSDs / HDDs para o armazenamento em block. Você não vai querer compartilhar esses dispositivos com outras cargas de trabalho. Se você usar o Kubernetes para gerenciar o Ceph nessa configuração e particionar estaticamente todas as suas outras cargas de trabalho para outros servidores, haverá pouco benefício em usar o Kubernetes.

Se você estiver otimizando o custo / densidade máxima, a escolha certa dependerá da combinação de cargas de trabalho. Se o Ceph for a única carga de trabalho de armazenamento, você ainda poderá economizar dinheiro executando-o em SKUs otimizados de densidade de armazenamento em um local separado.