Executar o Apache Cassandra em VMs do Azure

Cuidado

Este artigo faz referência ao CentOS, uma distribuição do Linux que atingiu o fim do suporte. Considere seu uso e planeje adequadamente. Para obter mais informações, consulte as diretrizes de fim de suporte do CentOS.

Este artigo descreve as considerações de desempenho para executar o Apache Cassandra em máquinas virtuais do Azure.

Essas recomendações são baseadas nos resultados de testes de desempenho internos. Use essas recomendações como uma linha de base e teste em relação à sua própria carga de trabalho.

Instância Gerenciada do Azure para Apache Cassandra

Se você estiver procurando por um serviço mais automatizado para executar o Apache Cassandra em máquinas virtuais do Azure, considere usar a Instância Gerenciada do Azure para Apache Cassandra. Esse serviço automatiza a implantação, o gerenciamento (patch e integridade de nó) e o dimensionamento de nós em um cluster Apache Cassandra. Ele também permite clusters híbridos para que os data centers Apache Cassandra implantados no Azure possam se conectar a um anel existente do Cassandra no local ou hospedado por terceiros. O serviço é implantado usando Conjuntos de Dimensionamento de Máquinas Virtuais do Azure. As recomendações a seguir foram adotadas durante o desenvolvimento desse serviço.

Tamanhos de VM e tipos de disco do Azure

As cargas de trabalho do Cassandra no Azure geralmente usam máquinas virtuais Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 ou Standard_E16s_v5. As cargas de trabalho do Cassandra se beneficiam de ter mais memória na VM, portanto, considere tamanhos de máquina virtual com otimização de memória, como Standard_DS14_v2 ou Standard_E16s_v5, ou tamanhos otimizados para armazenamento local, como Standard_L16s_v3.

Para garantir durabilidade, os dados e os logs de commit são geralmente armazenados em um conjunto de dois a quatro SSDs Premium de 1 TB (P30).

Os nós do Cassandra não devem ser muito densos em dados. É recomendável ter no máximo 1 a 2 TB de dados por VM e espaço livre suficiente para compactação. Para obter a maior taxa de transferência combinada possível e IOPS usando SSDs Premium, recomendamos criar um conjunto em faixas de alguns discos de 1 TB, em vez de usar um único disco de 2 TB ou 4 TB. Por exemplo, em uma VM DS14_v2, quatro discos de 1 TB têm um IOPS máximo de 4 × 5000 = 20 K, versus 7,5 K para um único disco de 4 TB.

Avalie Azure Ultra Disks para cargas de trabalho do Cassandra que necessitam de menor capacidade de disco. Eles podem fornecer IOPS/taxa de transferência mais alta e menor latência em tamanhos de VM como Standard_E16s_v5 e Standard_D16s_v5.

Para cargas de trabalho do Cassandra que não precisam de armazenamento durável, ou seja, em que os dados podem ser facilmente reconstruídos de outro meio de armazenamento, considere usar as VMs Standard_L16s_v3 ou Standard_L16s_v2. Esses tamanhos de VMs têm discos NVMe (NVM Express) temporários locais grandes e rápidos.

Rede Acelerada

Os nós do Cassandra fazem uso intenso da rede para enviar e receber dados da VM do cliente e para se comunicar entre os nós para replicação. Para um desempenho ideal, as VMs do Cassandra se beneficiam de uma rede de alta taxa de transferência e baixa latência.

Recomendamos habilitar a Rede Acelerada na NIC do nó do Cassandra e nas VMs que executam aplicativos cliente que acessam o Cassandra.

A rede acelerada requer uma distribuição do Linux moderna com os drivers mais recentes, como Cent OS 7.5 ou posterior ou Ubuntu 16.x/18.x. Para mais informações, veja Criar uma máquina virtual Linux com Rede Acelerada.

Cache de disco de dados da VM do Azure

As cargas de trabalho de leitura do Cassandra têm melhor desempenho quando a latência do disco de acesso aleatório é baixa. Recomendamos o uso de discos gerenciados do Azure com o cache ReadOnly habilitado. O cache ReadOnly fornece latência média mais baixa, pois os dados são lidos do cache no host em vez de irem para o armazenamento de back-end.

Cargas de trabalho de leitura intensa e aleatória, como o Cassandra, se beneficiam de uma latência de leitura mais baixa, embora o modo em cache tenha limites de taxa de transferência mais baixos do que o modo sem cache. Por exemplo, as máquinas virtuais DS14_v2 têm uma taxa de transferência máxima em cache de 512 MBps em comparação com 768 MBps sem cache.

O cache ReadOnly é particularmente útil para séries temporais do Cassandra e outras cargas de trabalho em que o conjunto de dados de trabalho se encaixa no cache do host e os dados não são substituídos constantemente. Por exemplo, a DS14_v2 fornece um tamanho de cache de 512 GB, que pode armazenar até 50% dos dados de um nó do Cassandra com densidade de dados de 1 a 2 TB.

Não há penalidade de desempenho significativa por faltas de cache quando o cache ReadOnly está habilitado, portanto, o modo em cache é recomendado para todas as cargas de trabalho, exceto as que fazem um uso mais intensivo de gravação.

Leitura antecipada do Linux

Na maioria das distribuições do Linux disponíveis para o Azure no Microsoft Marketplace, a configuração de leitura antecipada do dispositivo de bloco padrão é de 4.096 KB. As operações de leitura de E/S do Cassandra geralmente são aleatórias e relativamente pequenas. Portanto, uma grande leitura antecipada desperdiça a taxa de transferência com a leitura de partes de arquivos que não são necessárias.

Para minimizar a leitura antecipada desnecessária, defina a configuração de leitura antecipada do dispositivo de bloco do Linux para 8 KB. (Confira Configurações de produção recomendadas na documentação do DataStax).

Configure 8 KB de leitura antecipada para todos os dispositivos de bloco no conjunto de faixas e no próprio dispositivo de matriz (por exemplo, /dev/md0).

Tamanho do bloco mdadm da matriz de discos

Ao executar o Cassandra no Azure, é comum criar um conjunto de faixas mdadm (ou seja, RAID 0) de diversos discos de dados para aumentar a taxa de transferência geral do disco e o IOPS para mais perto dos limites da VM. O tamanho de faixa de disco ideal é uma configuração específica do aplicativo. Por exemplo, para cargas de trabalho OLTP do SQL Server, a recomendação é 64 KB. Para cargas de trabalho de data warehousing, a recomendação é 256 KB.

Nossos testes não encontraram uma diferença significativa entre os tamanhos de blocos de 64k, 128k e 256k para cargas de trabalho de leitura do Cassandra. Parece haver uma vantagem pequena, ligeiramente perceptível, no tamanho de parte de 128k. Portanto, recomendamos as seguintes abordagens:

  • Se você já estiver usando um tamanho de bloco de 64 K ou 256 K, não faz sentido reconstruir a matriz de disco para usar o tamanho de 128 K.

  • Para uma nova configuração, faz sentido usar 128 K desde o início.

Sistema de arquivos de log de confirmação

As gravações do Cassandra têm melhor desempenho quando os logs de confirmação estão em discos com alta taxa de transferência e baixa latência. Na configuração padrão, o Cassandra 3.x libera os dados da memória para o arquivo de log de confirmação a cada 10 segundos aproximadamente e não toca no disco para cada gravação. Nesta configuração, o desempenho de gravação é quase idêntico independentemente de o log de confirmação estar em discos anexados premium ou discos locais/efêmeros.

Os logs de confirmação devem ser duráveis para que um nó reiniciado possa reconstruir quaisquer dados que ainda não estejam nos arquivos de dados dos logs de confirmação liberados. Para obter melhor durabilidade, armazene logs de confirmação em SSDs Premium e não no armazenamento local, que podem ser perdidos se a VM for migrada para outro host.

Com base em nossos testes, o Cassandra no CentOS 7.x pode ter desempenho de gravação inferior quando os logs de confirmação estão no sistema de arquivos xfs em comparação com ext4. Ativar a compactação do log de confirmação alinha o desempenho do xfs com o ext4. O xfs compactado funciona tão bem quanto o ext4 compactado e não compactado em nossos testes.

Medir o desempenho da VM de linha de base

Depois de implantar as VMs para o anel do Cassandra, execute alguns testes sintéticos para estabelecer a rede de linha de base e o desempenho do disco. Use esses testes para confirmar se o desempenho está alinhado com as expectativas, com base no tamanho da VM.

Mais tarde, ao executar a carga de trabalho real, conhecer a linha de base de desempenho facilita a investigação de possíveis gargalos. Por exemplo, conhecer o desempenho padrão para egressos de rede na VM pode ajudar a descartar a rede como um gargalo.

Tamanho do documento

O desempenho de leitura e gravação do Cassandra depende do tamanho do documento. É possível esperar uma latência mais alta e operações/segundo mais baixas ao ler ou escrever documentos maiores.

Fator de replicação

A maioria das cargas de trabalho do Cassandra usa um RF (fator de replicação) de 3 quando usam discos premium anexados e até 5 quando usam discos locais temporários/efêmeros. O número de nós no anel do Cassandra deve ser um múltiplo do fator de replicação. Por exemplo, RF 3 implica um anel de 3, 6, 9 ou 12 nós, enquanto RF 5 teria 5, 10, 15 ou 20 nós. Quando você usa RF maior que 1 e um nível de consistência de LOCAL_QUORUM, é normal que o desempenho de leitura e gravação seja menor do que a mesma carga de trabalho em execução com RF 1.

Cache de página do Linux

Quando o código Java do Cassandra lê arquivos de dados, ele usa E/S de arquivo regular e se beneficia do cache de páginas do Linux. Depois que partes do arquivo são lidas uma vez, o conteúdo lido é armazenado no cache da página do sistema operacional. O acesso de leitura subsequente aos mesmos dados é muito mais rápido.

Por esse motivo, ao executar testes de desempenho de leitura em relação aos mesmos dados, as segundas e subsequentes leituras parecem ser muito mais rápidas do que a leitura original, que precisava acessar dados no disco de dados remoto ou no cache do host quando ReadOnly está habilitado. Para obter medições de desempenho semelhantes em execuções subsequentes, limpe o cache de página do Linux e reinicie o serviço Cassandra para limpar a memória interna dele. Quando o cache ReadOnly está habilitado, os dados podem estar no cache do host e as leituras subsequentes são mais rápidas mesmo depois de limpar o cache da página do sistema operacional e reiniciar o serviço cassandra.

Replicação de diversos data centers

O Cassandra oferece suporte nativo ao conceito de vários datacenters, facilitando a configuração de um anel do Cassandra em várias regiões do Azure ou em zonas de disponibilidade em uma região.

Para uma implantação multirregional, use o emparelhamento de VNet global do Azure para conectar as redes virtuais nas diferentes regiões. As VMs que são implantadas na mesma região, mas em zonas de disponibilidade separadas, podem estar na mesma rede virtual.

É importante medir a latência de ida e volta da linha de base entre regiões. A latência de rede entre as regiões pode ser de 10 a 100 vezes maior que a latência em uma região. Espere um atraso entre o aparecimento dos dados na segunda região ao usar a consistência de gravação LOCAL_QUORUM ou uma redução significativa no desempenho das gravações ao usar EACH_QUORUM.

Ao executar o Apache Cassandra em escala e especificamente em um ambiente de diversos DCs, o reparo de nó se torna complexo. Ferramentas como o Reaper podem ajudar a coordenar os reparos em escala (por exemplo, em todos os nós de um datacenter, em um datacenter por vez, para limitar a carga em todo o cluster). No entanto, o reparo de nós para clusters grandes continua sendo um desafio não resolvido e se aplica em todos os ambientes, seja no local ou na nuvem.

Quando os nós são adicionados a uma região secundária, o desempenho não é dimensionado linearmente, pois alguns recursos de largura de banda e CPU/disco são gastos no recebimento e envio do tráfego de replicação entre regiões.

Configuração de transferência sugerida

Em um anel Cassandra multirregional, as cargas de trabalho de gravação com nível de consistência LOCAL_QUORUM podem perder dados na região secundária. Por padrão, a transferência sugerida do Cassandra é limitada a uma taxa de transferência máxima relativamente baixa e uma vida útil de dica de três horas. Para cargas de trabalho com gravações pesadas, recomendamos aumentar a limitação de transferência sugerida e o tempo da janela de sugestão para garantir que as dicas não sejam descartadas antes de serem replicadas.

Colaboradores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

Outro colaborador:

Para ver perfis de LinkedIn não públicos, entre em LinkedIn.

Próximas etapas

Para obter mais informações sobre as configurações gerais do Cassandra, não específicas do Azure, consulte:

  • Last updated on