Executar o Apache Cassandra em VMs do Azure

  • Artigo

Atenção

Este artigo faz referência ao CentOS, uma distribuição Linux que está se aproximando do status de Fim da Vida Útil (EOL). Por favor, considere o seu uso e planeje de acordo. Para obter mais informações, consulte as diretrizes de Fim da Vida Útil do CentOS.

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

Essas recomendações são baseadas nos resultados dos testes de desempenho, que você pode encontrar no GitHub. Você deve usar essas recomendações como uma linha de base e, em seguida, testar em relação à sua própria carga de trabalho.

Azure Managed Instance for Apache Cassandra

Se você estiver procurando 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. Este serviço automatiza a implantação, o gerenciamento (aplicação de patches e integridade do nó) e o dimensionamento de nós dentro de um cluster Apache Cassandra. Ele também fornece a capacidade para clusters híbridos, para que os datacenters Apache Cassandra implantados no Azure possam ingressar em um anel Cassandra existente no local ou hospedado por terceiros. O serviço é implantado usando os Conjuntos de Escala de Máquina Virtual do Azure. Durante o desenvolvimento deste serviço, foram adotadas as seguintes recomendações:

Tamanhos de VM do Azure e tipos de disco

As cargas de trabalho 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 Cassandra se beneficiam de ter mais memória na VM, portanto, considere tamanhos de máquina virtual otimizados para memória, como Standard_DS14_v2 ou Standard_E16s_v5, ou tamanhos otimizados para armazenamento local, como Standard_L16s_v3.

Para maior durabilidade, os dados e os logs de confirmação geralmente são armazenados em um conjunto de distribuição de dois a quatro discos gerenciados premium de 1 TB (P30).

Os nós Cassandra não devem ser muito densos em dados. Recomendamos 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 e IOPS possível usando discos gerenciados premium, recomendamos a criação de um conjunto de distribuição a partir de alguns discos de 1 TB, em vez de usar um único disco de 2 TB ou 4 TB. Por exemplo, em uma DS14_v2 VM, quatro discos de 1 TB têm um IOPS máximo de 4 × 5000 = 20 K, contra 7,5 K para um único disco de 4 TB.

Avalie os Discos Ultra do Azure para cargas de trabalho Cassandra que precisam 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 Cassandra que não precisam de armazenamento durável, ou seja, onde os dados podem ser facilmente reconstruídos a partir de outro meio de armazenamento, considere usar Standard_L16s_v3 ou Standard_L16s_v2 VMs. Esses tamanhos de VMs têm discos NVMe temporários locais grandes e rápidos.

Para obter mais informações, consulte Comparando o desempenho de discos locais/efêmeros do Azure vs discos anexados/persistentes (GitHub).

Redes Aceleradas

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

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

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

Cache de disco de dados da VM do Azure

As cargas de trabalho de leitura 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, porque os dados são lidos do cache no host em vez de ir para o armazenamento de back-end.

Cargas de trabalho de leitura aleatória e pesadas como Cassandra se beneficiam da 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, DS14_v2 máquinas virtuais têm uma taxa de transferência máxima em cache de 512 MB/s versus não armazenada em cache de 768 MB/s.)

O cache ReadOnly é particularmente útil para séries cronológicas 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 constantemente substituídos. Por exemplo, DS14_v2 fornece um tamanho de cache de 512 GB, que pode armazenar até 50% dos dados de um nó Cassandra com densidade de dados de 1-2 TB.

Não há nenhuma penalidade de desempenho significativa por falhas de cache quando o cache ReadOnly está habilitado, portanto, o modo em cache é recomendado para todas as cargas de trabalho, exceto as mais pesadas de gravação.

Para obter mais informações, consulte Comparando configurações de cache de disco de dados de VM do Azure (GitHub).

Linux read-ahead

Na maioria das distribuições Linux no Azure Marketplace, a configuração padrão de leitura antecipada do dispositivo de bloco é de 4096 KB. Os IOs lidos por Cassandra são geralmente aleatórios e relativamente pequenos. Portanto, ter uma grande leitura antecipada desperdiça a taxa de transferência lendo partes de arquivos que não são necessárias.

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

Configure 8 KB read-ahead para todos os dispositivos de bloco no conjunto de distribuição e no próprio dispositivo de matriz (por exemplo, /dev/md0).

Para obter mais informações, consulte Comparando o impacto das configurações de leitura antecipada do disco (GitHub).

Tamanho do bloco mdadm da matriz de disco

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

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

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

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

Para obter mais informações, consulte Medindo o impacto dos tamanhos de blocos mdadm no desempenho do Cassandra (GitHub).

Confirmar sistema de arquivos de log

As gravações 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 dados da memória para o arquivo de log de confirmação a cada ~10 segundos e não toca no disco para cada gravação. Nessa configuração, o desempenho de gravação é quase idêntico se o log de confirmação estiver em discos anexados premium versus 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 em arquivos de dados a partir dos logs de confirmação liberados. Para maior durabilidade, armazene logs de confirmação em discos gerenciados premium e não no armazenamento local, que pode ser perdido se a VM for migrada para outro host.

Com base em nossos testes, Cassandra no CentOS 7.x pode ter menor desempenho de gravação quando os logs de confirmação estão no sistema de arquivos xfs versus ext4. Ativar a compactação de log de confirmação coloca o desempenho do xfs em linha com o ext4. O xfs comprimido tem um desempenho tão bom quanto o ext4 compactado e não compactado em nossos testes.

Para obter mais informações, consulte Observações sobre sistemas de arquivos ext4 e xfs e logs de confirmação compactados (GitHub).

Medindo o desempenho da VM de linha de base

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

Mais tarde, quando você executa 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 da linha de base para a saída de rede na VM pode ajudar a excluir a rede como um gargalo.

Para obter mais informações sobre como executar testes de desempenho, consulte Validando o desempenho da VM do Azure (GitHub) da linha de base.

Tamanho do documento

O desempenho de leitura e gravação de Cassandra depende do tamanho do documento. Você pode esperar ver maior latência e operações mais baixas/segundo ao ler ou escrever com documentos maiores.

Para obter mais informações, consulte Comparando o desempenho relativo de vários tamanhos de documentos Cassandra (GitHub).

Fator de replicação

A maioria das cargas de trabalho Cassandra usa um fator de replicação (RF) de 3 ao usar discos premium conectados e até 5 ao usar discos locais temporários/efêmeros. O número de nós no anel de 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. Ao usar RF maior que 1 e um nível de consistência de LOCAL_QUORUM, é normal que o desempenho de leitura e gravação seja inferior à mesma carga de trabalho em execução com RF 1.

Para obter mais informações, consulte Comparando o desempenho relativo de vários fatores de replicação (GitHub).

Cache de páginas Linux

Quando o código Java de Cassandra lê arquivos de dados, ele usa E/S de arquivos regulares 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 de páginas 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, a segunda leitura e as leituras subsequentes parecerão ser muito mais rápidas do que a leitura original, que precisava acessar dados no disco de dados remoto ou do cache do host quando ReadOnly está habilitado. Para obter medições de desempenho semelhantes em execuções subsequentes, limpe o cache de páginas do Linux e reinicie o serviço Cassandra para limpar sua memória interna. Quando o cache ReadOnly está habilitado, os dados podem estar no cache do host e as leituras subsequentes serão mais rápidas mesmo depois de limpar o cache de páginas do sistema operacional e reiniciar o serviço Cassandra.

Para obter mais informações, consulte Observações sobre o uso Cassandra do cache de páginas do Linux (GitHub).

Replicação de vários datacenters

O Cassandra suporta nativamente o conceito de vários data centers, facilitando a configuração de um anel Cassandra em várias regiões do Azure ou em zonas de disponibilidade dentro de uma região.

Para uma implantação em várias regiões, use o emparelhamento de rede virtual global do Azure para conectar as redes virtuais nas diferentes regiões. Quando as VMs são implantadas na mesma região, mas em zonas de disponibilidade separadas, as VMs 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 da rede entre regiões pode ser 10 a 100 vezes maior do que a latência dentro de uma região. Espere um atraso entre os dados que aparecem na segunda região ao usar LOCAL_QUORUM consistência de gravação ou um desempenho significativamente menor de gravações ao usar EACH_QUORUM.

Quando você executa o Apache Cassandra em escala e, especificamente, em um ambiente multi-DC, o reparo de nó torna-se desafiador. Ferramentas como o Reaper podem ajudar a coordenar reparos em escala (por exemplo, em todos os nós de um data center, um data center de cada vez, para limitar a carga em todo o cluster). No entanto, o reparo de nó para grandes clusters ainda não é um problema totalmente resolvido e se aplica a todos os ambientes, seja no local ou na nuvem.

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

Para obter mais informações, consulte Medindo o impacto da replicação multi-dc entre regiões (GitHub).

Configuração de transferência sugerida

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

Para obter mais informações, consulte Observações sobre transferência sugerida na replicação entre regiões (GitHub).

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

Outros contribuidores:

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

Para obter mais informações sobre esses resultados de desempenho, consulte Cassandra em Experimentos de desempenho de VMs do Azure.

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