Executar o Apache Cassandra em VMs do Azure
Cuidado
Este artigo faz referência ao CentOS, uma distribuição do Linux que está em EOL (fim da vida útil). Considere seu uso e planeje adequadamente. Para obter mais informações, veja as Diretrizes sobre fim da vida útil do CentOS.
Este artigo descreve as considerações de desempenho para executar o Apache Cassandra em máquinas virtuais do Azure.
Essas recomendações se baseiam nos resultados dos testes de desempenho, que podem ser encontrados no GitHub. É necessário usar essas recomendações como uma linha de base e, em seguida, testar 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. Essas cargas de trabalho 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 maior durabilidade, os dados e os logs de confirmação geralmente são armazenados em um conjunto de faixas de dois a quatro discos gerenciados 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 e IOPS combinada possível usando discos gerenciados premium, recomendamos criar um conjunto de 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 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 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.
Para saber mais, confira Comparando o desempenho de discos locais/efêmeros vs. discos persistentes/anexados do Azure (GitHub).
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 saber mais sobre a distribuição do Linux, confira Criar uma máquina virtual do 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 vs. fora do cache de 768 MBps.)
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.
Para saber mais, confira Comparando as configurações de cache de disco de dados da VM do Azure (GitHub).
Leitura antecipada do Linux
Na maioria das distribuições do Linux no Azure Marketplace, a configuração de leitura antecipada do dispositivo de bloco padrão é 4096 KB. As E/Ss de leitura 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).
Para saber mais, confira Comparando o impacto das configurações de leitura antecipada do disco (GitHub).
Tamanho da parte mdadm da matriz de disco
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 partes 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 o seguinte:
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.
Para saber mais, confira Medindo o impacto dos tamanhos de partes mdadm no desempenho do Cassandra (GitHub).
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 maior durabilidade, armazene os logs de confirmação em discos gerenciados premium e não no armazenamento local, que pode ser perdido caso a VM seja migrada para outro host.
Com base em nossos testes, o Cassandra no CentOS 7.x pode ter um desempenho de gravação inferior quando os logs de confirmação estão no sistema de arquivos XFS vs. 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.
Para saber mais, confira Observações sobre sistemas de arquivos ext4 e xfs e logs de confirmação compactados (GitHub).
Como 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 de linha de base para saída de rede na VM pode ajudar a descartar a rede como um gargalo.
Para saber mais sobre a execução de testes de desempenho, confira Validação do desempenho de VM do Azure de linha de base (GitHub).
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.
Para saber mais, confira Comparação do desempenho relativo de diversos tamanhos de documento do Cassandra (GitHub).
Fator de replicação
A maioria das cargas de trabalho do Cassandra usa um RF (fator de replicação) de 3 com discos premium anexados e de até 5 com 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. Ao usar um RF maior que 1 e um nível de consistência LOCAL_QUORUM, é normal que o desempenho de leitura e gravação seja inferior à mesma carga de trabalho executada com o RF 1.
Para saber mais, confira Comparação do desempenho relativo de vários fatores de replicação (GitHub).
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 nos mesmos dados, a segunda leitura e as subsequentes parecerão muito mais rápidas do que a original, que precisava acessar os dados no disco de dados remoto ou no cache do host quando ReadOnly estava 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 serão mais rápidas mesmo depois de limpar o cache da página do sistema operacional e reiniciar o serviço Cassandra.
Para saber mais, confira Observações sobre o uso que o Cassandra faz do cache de página do Linux (GitHub).
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 os dados que aparecem na segunda região ao usar a consistência de gravação LOCAL_QUORUM ou um desempenho significativamente reduzido de 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 grandes clusters ainda não é um problema totalmente resolvido e se aplica a 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.
Para saber mais, confira Medição do impacto da replicação entre regiões multi-DC (GitHub).
Configuração de transferência sugerida
Em um anel do 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.
Para saber mais, confira Observações sobre a transferência sugerida na replicação entre regiões (GitHub).
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- Arsen Vladimirskiy | Engenheiro principal de clientes
Outro colaborador:
- Theo van Kraay | Gerente de Programas Sênior
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
Para saber mais sobre esses resultados de desempenho, confira Cassandra em experimentos de desempenho de VMs do Azure.
Para saber mais sobre as configurações gerais do Cassandra, não específicas do Azure, confira os seguintes artigos: