Quantos nós? Parte 1: Uma introdução ao dimensionamento de um cluster do Couchbase Server 2.0

A primeira parte desta série apresenta uma visão geral das considerações que devem ser levadas em conta ao dimensionar um cluster do Couchbase Server 2.0 para produção. A segundo parO livro examina mais detalhadamente casos de uso e cenários específicos. O 3o entra em alguns considerações sobre hardware e o 4a discute as métricas e o monitoramento para dimensionamento e quando decidir aumentar o cluster.

Ao procurar implantar um cluster do Couchbase, talvez a pergunta mais comum (e importante) que surge seja: De quantos nós eu preciso?

Embora haja, obviamente, muitas variáveis envolvidas nisso, a ideia básica é avaliar o desempenho geral e os requisitos de capacidade para sua carga de trabalho e conjunto de dados e, em seguida, dividir isso pelo hardware e pelos recursos disponíveis. Para uma discussão visual e de alto nível sobre esses fatores, bem como sobre as práticas gerais de execução de um cluster do Couchbase em produção, consulte uma de minhas recentes apresentações na Conferência do Couchbase: Couchbase Server 2.0 em produção 24×7

O dimensionamento de seu cluster do Couchbase será fundamental para sua estabilidade e desempenho. Seu aplicativo quer o maior número possível de leituras saindo do cache e a capacidade de E/S para lidar com as gravações. É preciso haver capacidade suficiente em todas as várias áreas para dar suporte a tudo o que o sistema está fazendo e, ao mesmo tempo, manter o nível de desempenho necessário.

Ao longo desta discussão, farei referência a 5 fatores determinantes que devem ser considerados ao dimensionar um cluster do Couchbase: RAM, disco (IO e espaço), CPU, largura de banda da rede e geral distribuição de dados.

1. RAM: Frequentemente uma das áreas mais importantes a serem dimensionadas corretamente, a RAM é o que permite que o Couchbase seja tão rápido. Os documentos armazenados em cache permitem que as leituras sejam atendidas com latência muito baixa e alta taxa de transferência, e a RAM disponível faz o mesmo com as gravações.

Em breve, teremos uma calculadora de dimensionamento atualizada, mas a quantidade de RAM necessária será uma agregação de: seus conjuntos de dados ativos e de réplicas, os metadados necessários para rastrear todos eles (cerca de 64 bytes de sobrecarga para cada item, além dos comprimentos das chaves), quanto do conjunto de dados total precisa ser armazenado em cache na RAM (seu "conjunto de trabalho") e qualquer sobrecarga necessária para que o sistema operacional faça um bom trabalho de armazenamento em cache de E/S de disco.

Com o Couchbase Server 2.0, reduzimos a sobrecarga de metadados por item. Também aprimoramos bastante o algoritmo de "ejeção" para usar um bit NRU (não usado recentemente), projetado para tornar a camada de cache de objetos mais inteligente sobre quais dados devem ser mantidos na RAM com base na carga de trabalho do aplicativo.

Ao aproveitar nosso novo recurso de exibição/índice, você também deverá reservar RAM para que o sistema operacional faça o melhor trabalho possível no armazenamento em cache das solicitações de disco. Muito mais sobre isso em Parte 2.

2. Disco: Os requisitos de seu subsistema de disco são divididos em dois componentes: tamanho e E/S.

• Tamanho: O Couchbase Server 2.0 terá maiores requisitos de tamanho de disco em relação ao 1.8. Normalmente, isso não é um problema, pois o espaço em disco é considerado "barato", mas é importante levar isso em consideração.

A mudança de um formato de disco com atualização no local para um formato somente de anexo significa que cada gravação (inserção/atualização/exclusão) criará uma nova entrada no(s) arquivo(s). Isso traz imensas vantagens em termos de confiabilidade, desempenho, consistência desse desempenho e tempos de aquecimento/inicialização muito melhores. No entanto, isso também significa que o tamanho do disco cresceria sem limites.

Com a versão 1.8, às vezes havia uma penalidade de desempenho devido à fragmentação dos arquivos no disco em cargas de trabalho com atualizações/exclusões frequentes. Na versão 2.0, além de essa fragmentação não existir, também temos um processo de compactação automática integrado que garante que apenas as cópias relevantes dos dados sejam mantidas, além de reduzir o tamanho dos próprios arquivos em disco.

Dependendo da carga de trabalho, o tamanho do disco necessário pode variar de 2 a 3 vezes o tamanho total do conjunto de dados (dados ativos e de réplica combinados) devido ao formato de disco somente de anexo. As cargas de trabalho mais pesadas de atualização/exclusão aumentarão o tamanho mais drasticamente do que as cargas de trabalho pesadas de inserção e leitura. Na realidade, é provável que o tamanho aumente e diminua significativamente ao longo do tempo, à medida que o processo de compactação automática é executado. O número de 2 a 3 vezes é mais devido a essa necessidade de expansão do que ao fato de seus dados realmente ocuparem mais espaço no disco.

Há também novos requisitos de espaço quando se aproveita o recurso de visualização/indexação do Couchbase Server 2.0. Novamente, muito mais sobre isso na parte 2.

• IO: será uma combinação da sua taxa de gravação sustentada, da necessidade de compactar os arquivos do banco de dados e de qualquer outra coisa que exija acesso ao disco. O Couchbase Server armazenará automaticamente em buffer as gravações no banco de dados na RAM e, por fim, as manterá no disco. Por esse motivo, o software pode acomodar taxas de gravação muito mais altas do que um disco é capaz de suportar. No entanto, a manutenção dessas gravações acabará exigindo E/S suficiente para que tudo seja transferido para o disco.

Você pode configurar facilmente os limites e o agendamento do processo de compactação para controlar quando ele é iniciado (e quando não é iniciado), mas lembre-se de que a conclusão bem-sucedida da compactação é essencial para manter o tamanho do disco sob controle.

Discutirei os detalhes mais detalhadamente na parte 2, mas, ao aproveitar os novos recursos do Couchbase Server 2.0, como visualizações/indexação e replicação entre centros de dados (XDCR), a E/S do disco se tornará muito mais importante para o dimensionamento correto.

Por fim, você deverá garantir que tenha espaço em disco e E/S suficientes para fazer backups e qualquer outra coisa fora do Couchbase que precise de espaço ou acesse o disco. Sempre que possível, nossa prática recomendada é usar as opções de configuração disponíveis para separar os arquivos de dados, os índices e os diretórios de instalação/configuração em unidades/dispositivos separados para garantir que a E/S e o espaço sejam alocados de forma eficaz.

3. CPU: Embora normalmente não seja uma grande preocupação com o Couchbase Server 1.8, os novos recursos do Couchbase Server 2.0 exigem uma quantidade maior de CPU. Nossa camada de cache baseada em objetos ainda permite uma taxa de transferência extremamente alta de solicitações em baixas latências, mesmo quando a CPU está sobrecarregada, mas será importante garantir que haja capacidade de processamento suficiente para manter o restante do sistema funcionando sem problemas. Em geral, recomendamos pelo menos 4 núcleos, com um núcleo extra por bucket que está sendo replicado com o XDCR e um núcleo extra por documento de design (relacionado a visualizações).

4. Rede: Na maioria das situações, esse não é o fator determinante para o dimensionamento de um cluster do Couchbase. No entanto, é sempre importante entender o que está acontecendo no nível da rede e garantir que haja largura de banda suficiente entre o aplicativo e os nós do Couchbase, bem como entre os próprios nós, para atender ao tráfego. Com o XDCR, também é importante garantir largura de banda suficiente entre os clusters (geralmente espalhados geograficamente em uma WAN).

A rede é quase sempre o gargalo final que afeta a latência. Por exemplo, você deve esperar que as leituras/gravações de documentos individuais dentro/fora do cache recebam tempos de resposta em algum lugar no percentil 99 em torno de 1-2ms no Amazon AWS, 500-900us em uma rede gig-e padrão e abaixo de 200us em uma rede 10G. Tudo isso indica que o próprio servidor Couchbase é capaz de fornecer latências extremamente baixas; é a rede que geralmente acrescenta tempo adicional. Lembre-se de que sua milhagem pode variar e use esses benchmarks para fins de comparação geral.

5. Distribuição de dados: Independentemente de tudo o mais, é sempre importante ter certeza de que seus dados estão seguros. O Couchbase é um sistema distribuído por natureza e pode fornecer escala muito linear e redundância de dados somente quando isso for permitido de forma eficaz.

No extremo, um único nó pode ser capaz de atender a todos os seus requisitos de RAM/disco/CPU/rede. No entanto, isso cria um ponto único de falha óbvio.

A adição de um segundo nó permitirá a replicação, mas ainda não é o ambiente ideal. Por um lado, a falha de um dos nós criará um ponto único de falha. Por outro lado, o eventual requisito de escalonamento será beneficiado por mais nós no cluster, pois cada um deles terá que mover cada vez menos dados.

É por esses motivos que sempre recomendamos pelo menos 3 nós em um cluster, independentemente de outros fatores de dimensionamento.

Sempre haverá um fator que ditará o nível mais alto de exigência e, portanto, "determinará" o número de nós necessários. Por exemplo, um conjunto de dados relativamente pequeno com uma carga de trabalho de gravação muito alta exigirá mais nós devido aos requisitos de rendimento do disco em vez do tamanho total do conjunto de dados. Por outro lado, uma carga de trabalho de leitura pesada em um conjunto de dados relativamente grande exigirá mais nós devido aos requisitos de RAM.

Todos os fatores acima são beneficiados e escalonados linearmente com a adição de mais nós. Não só as leituras e gravações do aplicativo são distribuídas uniformemente entre os nós, como também coisas como compactação, rebalanceamento, atualizações de exibição/índice e XDCR também são altamente vantajosas por terem mais nós. Cada nó só precisa operar em seu conjunto de dados local e, portanto, os processos intensivos de disco e CPU podem ocorrer em paralelo.

Embora os requisitos e a disponibilidade de recursos de todos variem, você deve sempre optar por mais nós menores, em vez de forçar o Couchbase a uma arquitetura de aumento de escala de alguns nós muito caros.

Por fim, as diretrizes e as calculadoras não são suficientes para fornecer números de dimensionamento no papel. É melhor testar o comportamento de seu aplicativo específico em níveis variados de escala e monitorar constantemente o sistema para garantir que ele inicie e permaneça dimensionado adequadamente.

Parte 2 desta série aborda com muito mais profundidade as considerações envolvidas na implantação (ou atualização) de um cluster do Couchbase Server 2.0.

Até a próxima vez...