Quantos nós? Parte 2: Dimensionamento de um cluster do Couchbase Server 2.0

No primeira parte desta sérieEm meu artigo sobre o Couchbase, apresentei uma visão geral dos cinco fatores que determinam o dimensionamento do cluster do Couchbase: RAM, disco (IO e tamanho), CPU, rede e distribuição de dados. Nesta segunda parte, quero entrar em mais detalhes sobre casos de uso e cenários específicos para ver como vários designs de aplicativos e cargas de trabalho afetam esses vários fatores. Os terceira entrada desta série aborda diferentes opções de hardware e infraestrutura. Por fim, o quarta entrada analisa as métricas que podem ser monitoradas dentro e fora do Cocuhbase para entender os requisitos de dimensionamento.

O tamanho de um cluster do Couchbase Server 1.8 era bastante simples, e você pode encontrar uma discussão sobre isso aqui, juntamente com uma calculadora. Com as recentes adições de recursos à versão 2.0, isso se torna um pouco mais complicado...

Vamos dar uma olhada em duas considerações sobre o design e os requisitos do aplicativo que terão impacto no dimensionamento do cluster:

• Seu aplicativo é composto principalmente (ou mesmo exclusivamente) pelo acesso a documentos individuais? Ou você espera usar o nosso recurso de indexação e consulta? Uma boa descrição sobre como combinar acesso a chaves/documentos e visualizações pode ser encontrada aqui.
• Você planeja usar o novo Recurso de replicação entre data centers (XDCR)?

Acesso a documentos individuais e atualização a partir da versão 1.8

O caso de uso mais simples a ser discutido é quando um aplicativo realmente requer apenas acesso a um documento individual (normalmente chamado de caso de uso "chave/valor"). Isso inclui armazenamentos de sessão e de perfil de usuário, aplicativos de segmentação de anúncios, muitos jogos sociais etc.

O dimensionamento desses casos de uso é muito semelhante às diretrizes de dimensionamento do 1.8, com algumas modificações. Como em todas as discussões sobre dimensionamento, os mesmos cinco fatores determinantes se aplicam, sendo que o dimensionamento da RAM geralmente é o que vence aqui.

• RAM: Veja Parte 1 para uma discussão sobre as considerações do dimensionamento adequado da RAM. Para aqueles que estão familiarizados com a versão 1.8, não houve muita mudança aqui. Se não estiver familiarizado, dê uma olhada em nossas diretrizes e calculadora de dimensionamento.
• Disco: Lembre-se de que a atualização do Couchbase Server 1.8 para o 2.0 pode exigir muito mais espaço em disco. Do ponto de vista de E/S, o formato de disco somente de anexo lerá e gravará dados mais rapidamente e de forma mais consistente do que o 1.8. No entanto, há também a necessidade de compactação on-line dos arquivos de disco, e isso exigirá um pouco mais de E/S em disco. Este blog pode ajudá-lo a entender melhor a compactação.
• CPU: Conforme mencionado em Parte 1Se o aplicativo estiver em um ambiente de disco rígido, a leitura e a gravação do aplicativo na RAM e fora dela podem ser tratadas de forma muito eficiente com muito pouca CPU. A adição da compactação automática aumenta um pouco a atividade da CPU devido à E/S do disco, mas normalmente não afeta o desempenho do aplicativo. Embora as instalações típicas da versão 1.x pudessem "se contentar" com 2 núcleos, estamos aumentando essa recomendação para pelo menos 4, mesmo para o caso de uso básico de "documento-chave".

Ao fazer a atualização a partir da versão 1.x, é altamente recomendável usar o Suporte ao Couchbase para que possamos ajudar a analisar o ambiente, fornecer recomendações e ajudar a fazer com que a atualização ocorra da forma mais tranquila possível.

Replicação entre data centers (XDCR)

Muitas situações/ambientes criam a necessidade de replicação de dados em vários clusters do Couchbase. Você precisa do XDCR para recuperação de desastres, geolocalização de dados ou simplesmente sincronização para testes. Será importante garantir que seu cluster do Couchbase seja dimensionado de forma eficaz. Esses requisitos de capacidade são adicionais a tudo o mais que os clusters estão sendo solicitados a executar.

Para fins desta discussão, darei uma olhada separada nos requisitos de cluster de "origem" e "destino" para o XDCR. Na produção, você pode ter uma topologia um-muitos, muitos-um ou muitos-muitos combinando vários fluxos de replicação unidirecional.

1. Cluster de origem

• RAM: isso é um pouco variável, mas vimos que é necessário um pouco mais de RAM apenas para lidar com o processo de replicação de dados para outro cluster. Isso varia um pouco com base no número de buckets (e fluxos de replicação), mas uma boa estimativa é deixar cerca de 2 GB de RAM livre por nó, além do que é necessário para manter os dados. Isso é necessário para o processo Erlang (beam.smp no Linux, erl.exe no Windows).
• Disco: A implementação atual do XDCR envolve o envio de dados do subsistema de disco de um cluster de origem para o destino. Isso permite que nenhuma fila seja mantida na RAM e que a reinicialização de um processo de replicação ainda ocorra sem reenviar todos os dados. Além disso, várias gravações do aplicativo local são automaticamente desduplicadas antes de serem replicadas, economizando a preciosa largura de banda da rede. No entanto, isso significa que o cluster de origem de qualquer XDCR terá maiores requisitos de E/S de disco para ler os documentos depois que eles forem persistidos no disco
• CPU: O cluster de origem de um XDCR também terá maiores requisitos de CPU para processar e enviar os dados para outro cluster. Por padrão, há 32 fluxos por nó e por replicação. Isso pode ser aumentado, mas lembre-se de que um número maior de fluxos exigirá mais CPU. Uma prática recomendada geral deve ser ter um núcleo extra por bucket XDCR sendo replicado.

2. Cluster de destino:

• Dimensionamento de RAM e disco: geralmente não é preciso dizer, mas se você estiver enviando mais dados para um cluster (como na agregação de outros clusters), ele precisará de mais RAM e espaço em disco para conter esses dados. Se você estiver simplesmente replicando o mesmo conjunto de dados, não deverá haver nenhum requisito maior aqui.
• E/S de disco: Mesmo que você não precise de mais espaço para o mesmo conjunto de dados (ou seja, você não precisa do conjunto de trabalho da origem na memória), é provável que haja mais gravações do(s) cluster(s) de origem por meio do XDCR. Você precisará de IO de disco suficiente para persistir essas gravações no disco e também de largura de banda de IO suficiente para compacto esses dados junto com as gravações do aplicativo local. ???
• Em geral, é importante dimensionar os clusters de origem e de destino e testar o desempenho de sua carga de trabalho. No entanto, sabe-se que o desempenho do XDCR no cluster de origem se beneficiará muito com mais nós, pois os dados que precisam ser enviados são feitos em paralelo.

3. Rede

Embora os requisitos de rede entre clusters do Couchbase Server normalmente não exijam muita consideração, a transferência de dados por um link de WAN provavelmente exigirá um pouco mais de reflexão. O Couchbase Server fará automaticamente o checkpoint e reiniciará o XDCR conforme a rede permitir, mas a replicação só será eficaz se os dados puderem chegar ao outro lado.

4. Replicação bidirecional e outras topologias

Esta discussão se concentrou em clusters de origem e destino únicos que replicam um único bucket. A replicação bidirecional transforma cada cluster em uma origem e um destino com os requisitos de capacidade de ambos.

Ao combinar vários clusters e/ou vários buckets, é importante garantir que cada um tenha capacidade suficiente. Por exemplo, um one-many criará mais fluxos de replicação na única origem, e um many-one gerará uma sobrecarga significativa (espaço em disco / IO / CPU) no cluster de destino.
Visualizações e consultas

Um dos novos recursos mais procurados do Couchbase Server 2.0 é a adição de exibições para indexação/consulta de dados. Como acontece com qualquer novo recurso, ele vem com certos requisitos e considerações relacionados ao dimensionamento do cluster.

No momento, o sistema de visualização é baseado em disco, o que significa que os requisitos de espaço em disco e de E/S serão aumentados, bem como a necessidade de mais RAM fora do cache baseado em objeto para melhorar a taxa de transferência e a latência da consulta por meio do cache de E/S integrado do sistema operacional.

O impacto real dependerá significativamente da carga de trabalho do seu aplicativo, bem como da quantidade e da complexidade dos documentos de design e das definições de visualização. É muito importante seguir essas práticas recomendadas de gravação de exibição ao projetar suas exibições para mitigar e diminuir os requisitos de dimensionamento o máximo possível. As cargas de trabalho pesadas de gravação exercerão mais pressão sobre a atualização real dos índices e as cargas de trabalho mais orientadas à leitura exercerão mais carga sobre a consulta desses índices.

1. Atualização do índice

Uma inserção ou atualização de um documento acabará acionando uma atualização de índice. Esse acionamento faz parte do nosso processo normal em segundo plano e/ou de uma solicitação de aplicativo. O processamento efetivo dessas atualizações terá os seguintes impactos:

• Tamanho do disco: Há arquivos extras criados para cada documento de design e para cada visualização dentro dele. Esses arquivos são preenchidos com as chaves e os valores emitidos pelas descrições das visualizações (por isso é importante mantê-los o menor possível). Esses arquivos são do tipo append-only, portanto, crescerão a cada nova inserção, atualização ou exclusão e serão compactados de forma semelhante aos arquivos de dados.
• E/S do disco: Possivelmente, o maior impacto que o uso de exibições terá em um sistema é na E/S do disco. A atualização do índice em si poderá exigir uma quantidade significativa de E/S, pois cada gravação de documento pode precisar ser gravada em vários arquivos de índice. Essas atualizações são tratadas por threads e processos separados para não afetar o funcionamento normal do banco de dados, mas ter E/S suficiente será crucial para manter os índices atualizados. Além disso, a compactação normal e automática dos índices consumirá uma certa quantidade de E/S de disco e é necessária para manter o tamanho dos arquivos de disco sob controle.
• CPU: Juntamente com a E/S de disco, as atualizações de exibição incorrerão em uma quantidade adicional de CPU. Por padrão, há 4 indexadores por bucket e por nó. Os sistemas com muitos núcleos se beneficiarão com o aumento desse número. A prática geral deve ser ter 1 núcleo adicional por documento de design (cada visualização é processada em série em um documento de design, mas vários documentos de design podem ser processados em paralelo)
• Índices de réplica: Desativados por padrão, podem ser ativados para ajudar muito o desempenho da consulta após a falha de um nó. No entanto, eles pelo menos dobrarão (dependendo de quantas réplicas estiverem configuradas) a quantidade de espaço em disco, E/S de disco e carga de CPU exigida pelo sistema. Juntamente com os indexadores primários, há 2 indexadores de réplica por bucket e por nó por padrão.

O processo de atualização do índice é escalonado linearmente com a adição de mais nós, pois cada nó é responsável apenas pelo processamento de seus próprios dados.

É nossa prática recomendada configurar o caminho do disco para que os índices estejam em uma unidade/unidade separada dos arquivos de dados. Como cada conjunto de arquivos é somente de anexação, as gravações são sempre sequenciais em um arquivo. Entretanto, a combinação dos arquivos de dados e de índice cria muito mais E/S aleatória no disco compartilhado. Além disso, as cargas de trabalho pesadas de gravação devem considerar seriamente o uso de SSDs.
2. Consulta de visualizações
Para que um aplicativo tenha o melhor desempenho ao consultar exibições, os seguintes impactos de dimensionamento devem ser levados em consideração:

• RAM: embora os arquivos de índice sejam armazenados e acessados do disco, o formato desses arquivos de disco se presta muito bem ao cache de E/S normal do sistema operacional. Por esse motivo, é importante deixar uma certa quantidade de RAM disponível para o sistema fora da cota do Couchbase. O número real dependerá muito do tamanho de seus índices, mas mesmo uma quantidade relativamente pequena pode ter um grande impacto na latência e no desempenho da consulta.
• E/S de disco: Embora não seja necessário espaço extra simplesmente por consultar as exibições, será necessária alguma quantidade de E/S adicional em disco. Isso dependerá muito da frequência com que os índices são atualizados e depois consultados, bem como da quantidade de RAM disponível para armazená-los em cache.
• CPU: Também haverá um aumento nos requisitos de CPU ao consultar as exibições devido ao manuseio da consulta individual e à mesclagem de resultados de vários nós.

Considerando a implementação scather/gather de indexação e consulta, cada nó precisa participar de cada solicitação de consulta. A taxa de transferência da consulta pode ser melhorada com o aumento do cache do sistema de arquivos disponível ou do hardware físico.

3. Efeito das opiniões sobre o reequilíbrio

Ao aproveitar o novo recurso Views do Couchbase Server 2.0, será importante conhecer e se preparar para o impacto que isso terá no rebalanceamento do cluster.

Em algum momento do processo de rebalanceamento, os dados que estão sendo movidos de um nó para outro precisam ser refletidos no(s) índice(s) desse nó para que as consultas retornem consistentemente os mesmos resultados. Projetamos o sistema para realizar essa atualização durante todo o processo de rebalanceamento, em vez de tentar recuperar tudo no final. Como cada a partição de dados é movida o índice é atualizado antes de transferir a propriedade de um para o outro. Esse comportamento é configurável. Você pode desativar o rebalanceamento com reconhecimento de índice se o seu aplicativo puder lidar com resultados inconsistentes e acelerar significativamente o tempo de rebalanceamento.

Deixar essa configuração ativada causa os seguintes impactos:

• RAM: como há um processamento extra a ser feito, mais RAM será usada para manter as gravações pendentes na fila de gravação em disco de cada nó de destino
• Tamanho do disco: Haverá um aumento significativo na quantidade de espaço em disco usado durante o rebalanceamento para garantir a segurança e a consistência das exibições. Isso será limpo quando os dados não forem mais necessários, mas, devido à grande quantidade de gravações, é possível que o processo de compactação não consiga acompanhar o ritmo até que o rebalanceamento seja concluído.
• E/S do disco: como haverá uma grande quantidade de dados sendo lidos, gravados e indexados ao mesmo tempo, a E/S do disco aumentará drasticamente durante o rebalanceamento.

Juntamente com quase todas as outras partes do Couchbase, o processo de rebalanceamento é beneficiado pelo fato de haver mais nós. Imagine adicionar apenas um nó a um cluster. Em um extremo, passar de 1 para 2 nós é sempre o pior cenário possível. Isso ocorre porque metade do conjunto de dados precisa ser movida. Na maioria dos casos, um conjunto de dados de réplica também está sendo criado durante o rebalanceamento. Nesse caso especial, há apenas um nó disponível para lidar com toda a leitura e o recebimento de dados. Em contrapartida, passar de 21 para 22 nós é significativamente menos intensivo. Apenas 1/21 dos dados precisa ser movido, provavelmente nenhuma réplica está sendo criada e a carga de leitura/recepção é compartilhada por todos os 21 nós.
Conclusão

Para qualquer sistema complexo (especialmente um banco de dados), o dimensionamento nunca é uma tarefa fácil. As variáveis são inúmeras e as considerações e decisões devem sempre se basear nos requisitos individuais do aplicativo e na disponibilidade de recursos. Faremos o possível para fornecer orientação, mas é muito importante testar e preparar um sistema com a carga de trabalho/necessidades do seu aplicativo antes e depois da implementação.

O próxima e terceira entrada desta série fornece algumas recomendações/considerações específicas de implantação e hardware para um cluster de produção do Couchbase Server.