Servidor Couchbase

Certificação de desempenho do operador autônomo do Couchbase no Kubernetes

Na Couchbase, levamos o desempenho muito a sério e, com o lançamento do nosso novo produto, o Couchbase Autonomous Operator 1.0, queríamos ter certeza de que ele é de nível empresarial e está pronto para produção para os clientes.

Nesta postagem do blog, discutiremos os resultados detalhados de desempenho da execução dos testes de benchmark de desempenho do YCSB no Couchbase Server 5.5 usando o Autonomous Operator para implantar na plataforma Kubernetes. Uma das grandes preocupações das empresas que planejam executar o banco de dados no Kubernetes é o "desempenho".

Este documento apresenta uma comparação rápida de duas cargas de trabalho, a saber YCSB A & E com o Couchbase Server 5.5 no Kubernetes versus metal puro.

Carga de trabalho A do YCSB: Essa carga de trabalho tem uma mistura de 50/50 de leituras e gravações. Um exemplo de aplicativo é um armazenamento de sessão que registra ações recentes.

Carga de trabalho E: intervalos curtos: Nessa carga de trabalho, são consultados intervalos curtos de registros, em vez de registros individuais. Exemplo de aplicativo: conversas encadeadas, em que cada varredura é para as postagens em um determinado encadeamento (supostamente agrupadas por ID de encadeamento).

Em geral, não observamos nenhuma degradação significativa do desempenho na execução do Couchbase Cluster no Kubernetes, A carga de trabalho A teve um desempenho equivalente em comparação com o bare metal e a carga de trabalho E teve uma degradação de aproximadamente menos de 10%. 

Configuração:

Para a configuração, o Couchbase foi instalado usando a implantação do Operator, conforme indicado abaixo. Para obter mais detalhes sobre a configuração, consulte aqui

Arquivos:

Implementação do operador: deployment.yaml (consulte o Apêndice)

Implantação do Couchbase: couchbase-cluster-simple-selector.yaml (consulte o Apêndice)

Implantação do gerador de carga de trabalho/cliente: pillowfight-ycsb.yaml (consulte o Apêndice) (imagem oficial do docker do pillowfight do dockerhub e instalação manual do java e do YCSB sobre ela)

Hardware:

7 servidores

24 CPU x 64 GB de RAM por servidor

Configuração do Couchbase

4 servidores: 2 nós de dados, 2 nós de índice+consulta

Cota de 40 GB de RAM para o serviço de dados

Cota de 40 GB de RAM para serviços de índice

1 réplica de dados/bucket

1 réplica de índice primário

Testes:

Carga de trabalhoA e carga de trabalhoE da YCSB

10 milhões de documentos

Fluxo de trabalho após a inicialização de um novo cluster k8s vazio em 7 servidores:

 

Executar as cargas de trabalho:

 

Resultados do teste:

Env Configuração direta Recursos do pod do Kubernetes Teste Bare metal Kubernetes Delta
Env 1 22 vCPU, 48 GB de RAM

(os núcleos da CPU e a RAM disponíveis são definidos no nível do núcleo do sistema operacional)

Limite para:

cpu: 22000m = ~22vCPU

mem: 48GB

Todos os pods estão em nós dedicados

Carga de trabalhoA

50/50 get/upsert

Taxa de transferência: 194,158 req/seg

Média de uso da CPU: 86% de todos os 22 núcleos

Taxa de transferência: 192,190 req/seg

Média de uso da CPU: 94% da cota da CPU

– 1%
Env 2 16 vCPU, 48 GB de RAM

(os núcleos da CPU e a RAM disponíveis são definidos no nível do núcleo do sistema operacional)

Limite para:

cpu: 16000m = ~16vCPU

mem: 48GB

Todos os pods estão em nós dedicados

Carga de trabalhoA

50/50 get/upsert

Taxa de transferência: 141,909 req/seg

Média de uso da CPU: 89% de todos os 16 núcleos

Taxa de transferência: 145,430 req/seg

Média de uso da CPU: 100% da cota da CPU

+ 2.5%

Env Configuração direta Recursos do pod do Kubernetes Teste Bare metal Kubernetes Delta
Env 1 22 vCPU, 48 GB de RAM

(os núcleos da CPU e a RAM disponíveis são definidos no nível do núcleo do sistema operacional)

Limite para:

cpu: 22000m = ~22vCPU

mem: 48GB

Todos os pods estão em nós dedicados

Carga de trabalhoE

95/5 digitalização/inserção

Taxa de transferência: 15,823 req/seg

Média de uso da CPU: 85% de todos os 22 núcleos

Taxa de transferência: 14,281 req/seg

Média de uso da CPU: 87% da cota da CPU

– 9.7%
Env 2 16 vCPU, 48 GB de RAM

(os núcleos da CPU e a RAM disponíveis são definidos no nível do núcleo do sistema operacional)

Limite para:

cpu: 16000m = ~16vCPU

mem: 48GB

Todos os pods estão em nós dedicados

Carga de trabalhoE

95/5 digitalização/inserção

Taxa de transferência: 13,014 req/seg

Média de uso da CPU: 91% de todos os 16 núcleos

Taxa de transferência: 12,579 req/seg

Média de uso da CPU: 100% da cota da CPU

– 3.3%

Conclusões:

O Couchbase Server 5.5 está pronto para produção para ser implantado no Kubernetes com o Autonomous Operator. Desempenho do Couchbase Server 5.5 no Kubernetes comparável à execução em bare metal.   Há pouca penalidade de desempenho na execução do Couchbase Server na plataforma Kubernetes. Observando os resultados, a carga de trabalho A teve desempenho equivalente em comparação com o bare metal e a carga de trabalho E teve aproximadamente menos de 10% de degradação.

Referências:

  1. Cargas de trabalho do YCSB https://github.com/brianfrankcooper/YCSB/wiki/Core-Workloads
  2. Página do Kubernetes do Couchbase https://www.couchbase.com/products/cloud/kubernetes
  3. Download do Operador Autônomo do Couchbase https://www.couchbase.com/downloads  
  4. Apresentando o Couchbase Operator https://www.couchbase.com/blog/couchbase-autonomous-operator-1-0-for-kubernetes-and-openshift/

Apêndice

Meu arquivo deployment.yaml

Meu arquivo couchbase-cluster-simple-selector.yaml

 

Meu arquivo pillowfight-ycsb.yaml

 

Compartilhe este artigo
Receba atualizações do blog do Couchbase em sua caixa de entrada
Esse campo é obrigatório.

Autor

Postado por Raju Suravarjjala, diretor sênior de engenharia de qualidade, Couchbase

Raju Suravarjjala é diretor sênior de engenharia de qualidade da Couchbase. Ele é versado no gerenciamento de equipes de vários tamanhos e é especializado em testes de sistemas distribuídos. Ele tem cerca de 20 anos de experiência no setor, trabalhando com várias empresas de tecnologia, como Gupta SQLBase, Zaplet, Plumtree, BEA Systems e Oracle. Ele tem mestrado em ciência da computação pela University of Louisiana at Lafayette e é bacharel em engenharia mecânica pela Jawaharlal Nehru Technological University, na Índia.

2 Comentários

  1. Prezado Raju,

    É um bom blog.
    Por favor, atualize-o um pouco para que seja mais fácil de acompanhar.

    Dois comentários:

    Comentário#1:
    sequoiatools/pillowfight:v5.0.1 parece ter sido desenvolvido no coreos e, portanto, não tem um gerenciador de pacotes, especificamente não tem o apt-get.

    Comentário#2
    As etapas abaixo não estão funcionando agora, pois houve alguma alteração no contrato de licença do Oracle Java.
    sudo apt-add-repository ppa:webupd8team/java

    -Obrigado

  2. Instalei o JDK 11.

    Recebi o erro abaixo ao usar "-p couchbase.epoll=true"

    Carregando carga de trabalho...
    Teste inicial.
    Tempo máximo de execução especificado como: 120 segundos
    ADVERTÊNCIA: Ocorreu uma operação ilegal de acesso reflexivo
    AVISO: Acesso reflexivo ilegal por com.couchbase.client.deps.io.netty.util.internal.PlatformDependent0 (file:/opt/ycsb-couchbase2-binding-0.15.0/lib/core-io-1.3.1.jar) ao campo java.nio.Buffer.address
    AVISO: Considere a possibilidade de relatar isso aos mantenedores do com.couchbase.client.deps.io.netty.util.internal.PlatformDependent0
    AVISO: Use -illegal-access=warn para ativar avisos de outras operações de acesso reflexivo ilegal
    AVISO: Todas as operações de acesso ilegal serão negadas em uma versão futura
    Aug 23, 2019 9:15:34 AM com.couchbase.client.deps.io.netty.util.internal.PlatformDependent
    INFORMAÇÕES: Sua plataforma não fornece uma API de baixo nível completa para acessar buffers diretos de forma confiável. A menos que explicitamente solicitado, o buffer de heap sempre será preferido para evitar a possível instabilidade do sistema.
    com.yahoo.ycsb.DBException: Não foi possível conectar-se ao Couchbase Bucket.
    at com.yahoo.ycsb.db.couchbase2.Couchbase2Client.init(Couchbase2Client.java:208)
    at com.yahoo.ycsb.DBWrapper.init(DBWrapper.java:86)
    em com.yahoo.ycsb.ClientThread.run(Client.java:424)
    em java.base/java.lang.Thread.run(Thread.java:834)
    Causas: java.lang.IllegalStateException: falha ao criar um loop de evento filho
    at com.couchbase.client.deps.io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:68)
    at com.couchbase.client.deps.io.netty.channel.MultithreadEventLoopGroup.(MultithreadEventLoopGroup.java:49)
    at com.couchbase.client.deps.io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:91)
    at com.couchbase.client.deps.io.netty.channel.epoll.EpollEventLoopGroup.(EpollEventLoopGroup.java:67)
    at com.yahoo.ycsb.db.couchbase2.Couchbase2Client.init(Couchbase2Client.java:195)
    ... 3 mais
    Causado por: java.lang.NullPointerException
    at com.couchbase.client.deps.io.netty.util.internal.PlatformDependent0.allocateMemory(PlatformDependent0.java:330)
    at com.couchbase.client.deps.io.netty.util.internal.PlatformDependent.allocateMemory(PlatformDependent.java:210)
    at com.couchbase.client.deps.io.netty.channel.epoll.IovArray.(IovArray.java:64)
    at com.couchbase.client.deps.io.netty.channel.epoll.EpollEventLoop.(EpollEventLoop.java:60)
    at com.couchbase.client.deps.io.netty.channel.epoll.EpollEventLoopGroup.newChild(EpollEventLoopGroup.java:106)
    at com.couchbase.client.deps.io.netty.util.concurrent.MultithreadEventExecutorGroup.(MultithreadEventExecutorGroup.java:64)
    ... 7 mais

Deixe um comentário

Pronto para começar a usar o Couchbase Capella?

Iniciar a construção

Confira nosso portal do desenvolvedor para explorar o NoSQL, procurar recursos e começar a usar os tutoriais.

Use o Capella gratuitamente

Comece a trabalhar com o Couchbase em apenas alguns cliques. O Capella DBaaS é a maneira mais fácil e rápida de começar.

Entre em contato

Deseja saber mais sobre as ofertas do Couchbase? Deixe-nos ajudar.