Quantos nós? Parte 3: Considerações sobre hardware

As duas primeiras partes desta série abordaram uma visão geral do 5 fatores para dimensionar um cluster do Couchbase Servere uma análise mais aprofundada de vários casos de uso e recursos e os efeitos que eles têm sobre o dimensionamento. A quarta parte examinará o métricas para monitoramento um cluster do Couchbase Server para determinar o tamanho adequado e quando aumentá-lo.

Agora, gostaria de fornecer algumas orientações sobre recomendações de hardware. Embora fosse fácil para nós da Couchbase exigir requisitos muito rígidos e rápidos de hardware, isso não seria nada apropriado, dada a grande diferença nos casos de uso e nos ambientes de aplicativos/infraestrutura em que nossos clientes desejam usar o software. Veja, por exemplo, a diferença entre um cliente que executa em seu próprio hardware físico, em seu próprio data center, onde tem acesso a sistemas de 512 GB de RAM, placas FusionIO e rede 10Gig-E, e um cliente que executa no AWS da Amazon. Os clientes do Couchbase abrangem esses dois extremos e praticamente todas as configurações intermediárias... você pode ver como é difícil para nós fornecer recomendações específicas.

No nível mais alto, o Couchbase foi projetado e testado para ser executado em "hardware de commodity". Como você pode ver acima, "commodity" significa coisas diferentes para pessoas diferentes. Eu sempre pergunto aos clientes que tipo de perfil de hardware eles têm, querem ou planejam ter. Em seguida, dimensionamos o cluster tendo em mente os benefícios da escalabilidade horizontal e o número de nós necessários para dar suporte ao conjunto de dados e ao workoad... em vez de dizer que você definitivamente precisará de 6 HP DL 380s com 64 GB de RAM, 24 núcleos de CPU e 2 TB de SSD. Nossa recomendação de hardware estará na interseção dos requisitos do conjunto de dados e da carga de trabalho, dos recursos disponíveis e do custo. Nossa documentação também aborda isso brevemente: Requisitos de recursos

Muito bem, chega de declarações de isenção de responsabilidade, vamos aos detalhes. Nas partes anteriores desta série, listei os 5 fatores de dimensionamento do Couchbase:

1. RAM
2. Disco
3. CPU
4. Rede
5. Distribuição de dados

Começarei com o mais fácil primeiro (na parte inferior) e vou subindo.

1. Distribuição de dados

O mais fácil :-) Qualquer implementação de produção do Couchbase deve ter pelo menos 3 nós. O motivo por trás disso é a segurança do autofailover, a facilidade de upgrades e o aumento da escala.

2. Rede

A segunda mais fácil :-S. Em geral, é provável que você tenha muito pouca escolha em relação ao tipo de rede disponível. Hoje em dia, qualquer coisa com 1Gig-E ou mais será suficiente para o Couchbase. Se o seu aplicativo for particularmente sensível à latência ou exigir uma taxa de transferência extremamente alta, você se beneficiará da conectividade de ponta a ponta de 10Gig-E.

Coloque o menor número possível de "saltos" entre os nós do Couchbase e os clientes em termos de firewalls e roteadores. Se for necessário ter esses elementos entre eles, saiba que a latência será afetada.

Ao configurar XDCRSe o recurso de rede for usado, a variabilidade da rede se torna maior, mas também se torna menos importante devido à forma como arquitetamos esse recurso.

3. CPU

O Couchbase tem mais a ver com núcleos de CPU do que com a velocidade de cada um deles (2,4 GHz versus 2,6 GHz versus 3,0 GHz versus Intel versus AMD não farão diferença). O Couchbase é multithread de várias maneiras e usará muitos núcleos... mas também não é necessário ter 32, 64 ou mais núcleos (a maioria concordaria que esses não são exatamente "commodities"). Comece com 4 núcleos para uma carga de trabalho básica e, em seguida, adicione mais núcleos conforme necessário para visualizações e XDCR. Consulte a seção partes anteriores desta série para obter mais detalhes.

4. Disco

Este será um grande desafio, como não poderia deixar de ser. O Couchbase é um banco de dados, mas diferente de qualquer outro. Enquanto Oracle/MySQL/Postgres dependem muito do desempenho do disco, o Couchbase separa o desempenho do aplicativo principal do IO do disco, o que significa que os requisitos são muito menores. Menores, mas não inexistentes.

• Use o melhor armazenamento "local" que você tiver disponível.  Nossa prática recomendada e arquitetura gira em torno de um sistema distribuído. Não recomendamos o uso de um sistema de armazenamento de back-end centralizado, como um SAN ou NAS. Embora esses sistemas possam atender às necessidades de desempenho, eles apresentam um único gargalo/ponto de falha (mesmo que seja HA) que limita a natureza distribuída do Couchbase. Os benefícios de ter um armazenamento compartilhado podem superar isso, mas é algo a ser levado em consideração.
• EBS < unidade virtual < 7200 < 10K < SSD < FusionIO: Discutirei as considerações sobre o hardware da nuvem e da VM mais adiante, mas faz sentido que os discos mais rápidos sejam mais rápidos. Normalmente, vemos cerca de 1.000 ou menos gravações por segundo por nó para EBS, cerca de 1.500 para unidades de 10K e bem mais de 6.000 para SSDs. Já vi taxas de gravação acima de 30 mil por segundo por nó... você entendeu: tudo depende. Se a sua carga de trabalho for tal que você dependa muito do desempenho do disco para leituras pesadas (do disco), gravações contínuas, atualização de índices e/ou XDCR, então você deverá pensar mais sobre a sua camada de disco. Sei que "pesado" é um termo muito vago, mas não há outra maneira de dizer isso e só posso recomendar que você aproveite a experiência de nossas equipes de engenharia e de campo aqui no Couchbase para obter detalhes específicos sobre seu aplicativo.
• RAID não é um requisito, mas se você tiver uma configuração de implantação padrão, geralmente RAID 0 ou 10 é melhor do que 1 ou 5. Você deverá usar o RAID para melhorar a taxa de transferência e a latência, não para melhorar a redundância, pois o Couchbase já terá réplicas em todo o cluster. Nos casos em que você tiver as unidades de disco e o espaço disponíveis e estiver armazenando grandes quantidades de dados (>100 GB) por nó, o RAID 5 pode realmente valer a pena para evitar a necessidade de failover e rebalanceamento quando um disco falhar.
• Se você depende de exibições, é uma boa ideia ter dois discos separados e dividir os dados e as exibições entre eles para obter o melhor desempenho e eficiência. Veja mais sobre exibições na seção Partes anteriores desta série.
• O espaço em disco geralmente é barato, obtenha o máximo que você puder pagar. Veja meu postagens anteriores para saber como nosso formato de arquivo somente de anexo e a compactação precisam ser levados em conta.

5. RAM

Essa também é bem fácil... em geral, obtenha o máximo de RAM possível no cluster (com base em suas necessidades de cálculo de dimensionamento). O ponto ideal para o Couchbase é geralmente em torno de 8 GB a 128 GB por nó. Embora certamente haja exceções, menos de 8 não deixa muito espaço disponível para headroom ou cache de disco e mais de 128 começa a colocar uma quantidade muito grande de dados sob a responsabilidade da disponibilidade e dos recursos disponíveis de apenas um nó.

Algumas outras considerações:

• Embora possa parecer intuitivo tentar usar toda a memória disponível, na verdade é uma prática recomendada deixar alguma RAM disponível fora da cota do Couchbase. A maioria dos sistemas operacionais modernos deseja alguns gigabytes (o Windows geralmente um pouco mais do que o Linux), e pode haver outros processos em execução nesses nós, como agentes de monitoramento. Também há necessidade de cache de E/S para exibições e para o funcionamento geral do sistema. Normalmente, recomendamos que cerca de 60-80% da RAM de um sistema sejam alocados para a cota do Couchbase, deixando o restante para espaço livre e necessidades de memória fora do próprio Couchbase.
• É melhor usar nós de 6x32GB em vez de 3x64GB
• Não haverá uma diferença perceptível entre os diferentes tipos de RAM ou velocidades.
• Linux (garante o uso mais eficiente e amplo da RAM):
  • Ter de 5 a 10 GB de espaço de troca configurado. Embora certamente não esperemos usá-lo, também queremos ter um pouco de segurança contra o Eliminação do OOM do Linux
  • Desative a THP (páginas enormes transparentes, às vezes conhecidas como páginas anônimas hyge). Embora elas possam ser benéficas em alguns casos, temos visto problemas em nossos clientes com elas ativadas (consulte seu sistema operacional e versão específicos para obter instruções sobre como desativar o THP).
  • Definir a permuta como 0
  • Evidências recentes sugerem que a desativação do Zone Reclaim em sistemas NUMA pode ser benéfica (http://engineering.linkedin.com/performance/optimizing-linux-memory-management-low-latency-high-throughput-databases)

"Colocação"

Muitas vezes nos perguntam se é possível executar o Couchbase nos mesmos servidores que o aplicativo. Embora não haja nenhuma limitação técnica para fazer isso, essa não seria nossa recomendação de prática recomendada por alguns motivos:

• Os cálculos de dimensionamento ficam mais complicados quando se leva em conta os requisitos de outras tecnologias.
• A maioria dos outros aplicativos tem, na verdade, requisitos de hardware/dimensionamento diferentes dos do Couchbase e, portanto, a capacidade de atribuir recursos onde eles são importantes é uma vantagem de dividi-los.
• O dimensionamento fica mais complexo. Imagine um farm de aplicativos de 3 nós com 3 nós do Couchbase em execução nos mesmos servidores. Agora você deseja dimensionar o aplicativo, mas não precisa dimensionar o Couchbase com ele. Você tem 5 servidores de aplicativos, dos quais apenas 3 têm o Couchbase em execução?
• A administração é mais difícil. O mesmo ambiente acima... agora você precisa reiniciar a camada de aplicativos, mas não quer que o Couchbase caia com ela.

Fazer ou não fazer uma VM?

Não é segredo que o hardware físico lhe proporcionará o melhor desempenho e o uso mais eficiente dos recursos. No entanto, uma grande parte dos clientes do Couchbase está usando VMs e essa é uma implantação que testamos e suportamos. Algumas coisas que você deve ter em mente:

• Trate o Couchbase com respeito... não sobrecarregue a máquina host com outros aplicativos. O comprometimento excessivo da CPU e da RAM, especialmente, pode levar a resultados muito inesperados (e difíceis de diagnosticar). Parte disso pode ser controlada com configurações reais no host vm (como a RAM) e parte é apenas uma prática recomendada (como não alocar mais CPUs virtuais do que o número de núcleos físicos)
• A rede ficará um pouco mais lenta com as VMs... talvez não seja perceptível, mas há um efeito.
• Os mesmos requisitos numéricos se aplicam à CPU e à RAM
• O armazenamento local é melhor do que voltar para uma SAN compartilhada pelos mesmos motivos mencionados acima para um ambiente distribuído.
• Nossa recomendação geral de mais nós em vez de menos é ainda mais forte com as VMs
• Certifique-se de que você não tenha mais de um nó do Couchbase por máquina física
• Você pode sacrificar alguns dos itens acima para ambientes que não sejam de produção, mas lembre-se de que poderá ter problemas de desempenho ou estabilidade. Se você planeja ter os mesmos conjuntos de dados de produção e as mesmas cargas de trabalho em teste, UAT e/ou preparação, também terá os mesmos requisitos de recursos nesses ambientes.
• Não parece haver diferença entre a escolha das tecnologias de virtualização

Nas nuvens...

Uma "nuvem", nesse contexto, é um ambiente de implementação em que o hardware é realmente desacoplado do software para cada componente e, na minha opinião, é diferente de apenas executar em VMs. Cerca de 50% de nossos clientes estão implantados na Amazon. Alguns outros estão em algum outro fornecedor de nuvem, como GAE/Rackspace/Softlayer/Savvis/etc, e outros estão executando sua própria nuvem privada. Mantendo o tema do início, não estou em posição de dizer em qual infraestrutura você deve implantar o Couchbase... você é que vai me dizer.

Muitas/todas as considerações se aplicam às nuvens e às VMs, e temos uma documentação mais específica sobre considerações sobre a nuvem aqui.

• RAM: Normalmente, você tem menos RAM disponível por nó
• Disco: Uma única unidade EBS é (potencialmente de forma inconsistente) lenta. Recomendamos um LVM/striped-RAID de 4 a 6 unidades por nó para obter o melhor desempenho, e é bom considerar unidades EBS com IOPS otimizado/provisionado. O EC2 também oferece instâncias baseadas em SSD que, embora sejam muito caras no momento, seriam a melhor opção para o desempenho. Lembre-se de que você também pode "escolher" os tipos de disco para o diretório de instalação, o diretório de arquivos de dados e o diretório de exibição/índice.
• Distribuição de dados: Novamente, planeje usar mais nós em vez de menos.
• Zonas de disponibilidade: Embora ainda não façamos nada de especial para implantar o Couchbase em racks ou zonas (isso está chegando), ainda é uma boa ideia dividir seu cluster em zonas. Dessa forma, a falha de uma zona não tornará todo o conjunto de dados indisponível. O uso do XDCR entre as zonas pode ser uma boa consideração para proporcionar maior resiliência.

"Aumentar a escala" vs. "Diminuir a escala"

A elasticidade do Couchbase por meio do rebalanceamento permite não apenas a manutenção e o upgrade contínuos do software, mas também do hardware. Ao adicionar um novo nó de maior capacidade e trocá-lo pelos nós mais antigos de menor capacidade, você pode obter escalabilidade vertical... tudo isso sem perda de desempenho ou disponibilidade de dados para um aplicativo em execução.

Saber quando aumentar a capacidade dos seus nós dependerá do seu próprio caso de uso, da disponibilidade de recursos e das variáveis de custo subjacentes. Em um extremo, não recomendaríamos 1, 2 ou 3 nós de hardware muito robusto... nem recomendaríamos 1.000 nós muito pequenos. Algumas regras gerais são:

1. Escala fora com o menor tamanho de nó possível, até cerca de 15 a 20 nós, e depois considerar dimensionamento para cima para reduzir o número de nós
2. Ao aumentar a escala, não escolha um hardware que reduza a contagem de nós para menos de 6... enxágue e repita o #1 acima
3. Se a sua carga de trabalho for vinculada à memória, tome cuidado ao reduzir o número de nós em relação à taxa de transferência de disco que você tem... quanto mais RAM cada nó tiver, mais E/S de disco será necessária para cada nó, tanto para carga de trabalho estável quanto para compactação e, principalmente, rebalanceamento etc.
4. Se sua carga de trabalho for vinculada ao disco, é melhor ter mais nós para distribuir a carga de trabalho em vez de aumentar gradualmente o desempenho do disco de cada nó no local

Um bom exemplo disso é um cliente recente cujo dimensionamento exigia 32 nós de discos giratórios devido a uma carga de trabalho pesada de gravação. Ao analisar as SSDs, ele conseguiu reduzir esse número para 9... encaixando-se bem no #1 e no #2 acima e compensando facilmente o custo das SSDs.

Em resumo

Para começar, seus requisitos mínimos de hardware devem ser mais ou menos assim:

• 3 nós
• 4+GB DE RAM
• 4 núcleos de CPU (+1 por bucket, +1 por documento de design, +1 por fluxo XDCR, +1 por trabalhador de leitura/gravação além do padrão de 3)
• O melhor armazenamento "local" que você tem disponível
• A rede de menor latência e maior taxa de transferência que você tem disponível

No final das contas, sua arquitetura geral será muito melhor atendida se tiver mais nós com capacidades/potências menores do que se tiver menos nós com potência (e custo) muito maiores.

E lembre-se, em caso de dúvida, a equipe de campo do Couchbase está à disposição para avaliar seu ambiente e fornecer orientação sobre suas necessidades específicas. Queremos garantir que você tenha a melhor experiência possível com o produto.

No próxima e quarta entrada desta série, discutirei as várias métricas e práticas de monitoramento para entender o dimensionamento adequado de um cluster do Couchbase Server.