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:
|
1 2 3 4 5 6 7 8 9 |
# assign labels to the nodes so all services/pods will be assigned to right servers: kubectl label nodes arke06-sa09 type=power kubectl label nodes arke07-sa10 type=client kubectl label nodes ark08-sa11 type=client kubectl label nodes arke01-sa04 type=kv kubectl label nodes arke00-sa03 type=kv kubectl label nodes arke02-sa05 type=kv kubectl label nodes arke03-sa06 type=kv |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
#deploy Operator: kubectl create -f deployment.yaml #deploy Couchbase kubectl create -f couchbase-cluster-simple-selector.yaml #deploy Client(s): kubectl create -f pillowfight-ycsb.yaml I ran my tests directly from the client node by logging into the docker image of the client pod: docker exec -it --user root <pillowfight-yscb container id> bash And installing YCSB environment there manually: apt-get upgrade apt-get update apt-get install -y software-properties-common apt-get install python sudo apt-add-repository ppa:webupd8team/java sudo apt-get update sudo apt-get install oracle-java8-installer export JAVA_HOME=/usr/lib/jvm/java-8-oracle cd /opt wget https://download.nextag.com/apache/maven/maven-3/3.5.4/binaries/apache-maven-3.5.4-bin.tar.gz sudo tar -xvzf apache-maven-3.5.4-bin.tar.gz export M2_HOME="/opt/apache-maven-3.5.4" export PATH=$PATH:/opt/apache-maven-3.5.4/bin sudo update-alternatives --install "/usr/bin/mvn" "mvn" "/opt/apache-maven-3.5.4/bin/mvn" 0 sudo update-alternatives --set mvn /opt/apache-maven-3.5.4/bin/mvn git clone https://github.com/couchbaselabs/YCSB |
Executar as cargas de trabalho:
|
1 2 3 4 5 6 7 8 9 10 11 |
Examples of YCSB commands used in this exercise: Workload A Load: ./bin/ycsb load couchbase2 -P workloads/workloade -p couchbase.password=password -p couchbase.host=10.44.0.2 -p couchbase.bucket=default -p couchbase.upsert=true -p couchbase.epoll=true -p couchbase.boost=48 -p couchbase.persistTo=0 -p couchbase.replicateTo=0 -p couchbase.sslMode=none -p writeallfields=true -p recordcount=10000000 -threads 50 -p maxexecutiontime=3600 -p operationcount=1000000000 Run: ./bin/ycsb run couchbase2 -P workloads/workloada -p couchbase.password=password -p couchbase.host=10.44.0.2 -p couchbase.bucket=default -p couchbase.upsert=true -p couchbase.epoll=true -p couchbase.boost=48 -p couchbase.persistTo=0 -p couchbase.replicateTo=0 -p couchbase.sslMode=none -p writeallfields=true -p recordcount=10000000 -threads 50 -p operationcount=1000000000 -p maxexecutiontime=600 -p exportfile=ycsb_workloadA_22vCPU.log |
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% |
|
1 2 3 4 5 6 7 8 9 |
Workload E: Load: ./bin/ycsb load couchbase2 -P workloads/workloade -p couchbase.password=password -p couchbase.host=10.44.0.2 -p couchbase.bucket=default -p couchbase.upsert=true -p couchbase.epoll=true -p couchbase.boost=48 -p couchbase.persistTo=0 -p couchbase.replicateTo=0 -p couchbase.sslMode=none -p writeallfields=true -p recordcount=10000000 -threads 50 -p maxexecutiontime=3600 -p operationcount=1000000000 Run: ./bin/ycsb run couchbase2 -P workloads/workloade -p couchbase.password=password -p couchbase.host=10.44.0.2 -p couchbase.bucket=default -p couchbase.upsert=true -p couchbase.epoll=true -p couchbase.boost=48 -p couchbase.persistTo=0 -p couchbase.replicateTo=0 -p couchbase.sslMode=none -p writeallfields=true -p recordcount=10000000 -threads 50 -p operationcount=1000000000 -p maxexecutiontime=600 -p exportfile=ycsb_workloadE_22vCPU.log |
| 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:
- Cargas de trabalho do YCSB https://github.com/brianfrankcooper/YCSB/wiki/Core-Workloads
- Página do Kubernetes do Couchbase https://www.couchbase.com/products/cloud/kubernetes
- Download do Operador Autônomo do Couchbase https://www.couchbase.com/downloads
- Apresentando o Couchbase Operator https://www.couchbase.com/blog/couchbase-autonomous-operator-1-0-for-kubernetes-and-openshift/
Apêndice
Meu arquivo deployment.yaml
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 |
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: couchbase-operator spec: replicas: 1 template: metadata: labels: name: couchbase-operator spec: nodeSelector: type: power containers: - name: couchbase-operator image: couchbase/couchbase-operator-internal:1.0.0-292 command: - couchbase-operator # Remove the arguments section if you are installing the CRD manually args: - -create-crd - -enable-upgrades=false env: - name: MY_POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace - name: MY_POD_NAME valueFrom: fieldRef: fieldPath: metadata.name ports: - name: readiness-port containerPort: 8080 readinessProbe: httpGet: path: /readyz port: readiness-port initialDelaySeconds: 3 periodSeconds: 3 failureThreshold: 19 |
Meu arquivo couchbase-cluster-simple-selector.yaml
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 |
apiVersion: couchbase.database.couchbase.com/v1 kind: CouchbaseCluster metadata: name: cb-example spec: baseImage: couchbase/server version: enterprise-5.5.0 authSecret: cb-example-auth exposeAdminConsole: true antiAffinity: true exposedFeatures: - xdcr cluster: dataServiceMemoryQuota: 40000 indexServiceMemoryQuota: 40000 searchServiceMemoryQuota: 1000 eventingServiceMemoryQuota: 1024 analyticsServiceMemoryQuota: 1024 indexStorageSetting: memory_optimized autoFailoverTimeout: 120 autoFailoverMaxCount: 3 autoFailoverOnDataDiskIssues: true autoFailoverOnDataDiskIssuesTimePeriod: 120 autoFailoverServerGroup: false buckets: - name: default type: couchbase memoryQuota: 20000 replicas: 1 ioPriority: high evictionPolicy: fullEviction conflictResolution: seqno enableFlush: true enableIndexReplica: false servers: - size: 2 name: data services: - data pod: nodeSelector: type: kv resources: limits: cpu: 22000m memory: 48Gi requests: cpu: 22000m memory: 48Gi - size: 2 name: qi services: - index - query pod: nodeSelector: type: kv resources: limits: cpu: 22000m memory: 48Gi requests: cpu: 22000m memory: 48Gi |
Meu arquivo pillowfight-ycsb.yaml
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
apiVersion: batch/v1 kind: Job metadata: name: pillowfight spec: template: metadata: name: pillowfight spec: containers: - name: pillowfight image: sequoiatools/pillowfight:v5.0.1 command: ["sh", "-c", "tail -f /dev/null"] restartPolicy: Never nodeSelector: type: client |
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
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