Componentes de cluster do DAX - Amazon DynamoDB

Componentes de cluster do DAX

Um cluster do Amazon DynamoDB Accelerator (DAX) consiste em componentes da infraestrutura da AWS. Esta seção descreve esses componentes e como eles funcionam em conjunto.

Nodes

Um é o menor bloco de criação de um cluster do DAX. Cada nó executa uma instância do software DAX e mantém uma única réplica dos dados em cache.

Você pode escalar seu cluster do DAX de uma das seguintes formas:

  • Adicionando mais nós ao cluster. Isso aumenta o throughput de leitura geral do cluster.

  • Ao usar um tipo de nó maior. Tipos de nó maiores fornecem mais capacidade e podem aumentar o throughput. (Você deve criar um novo cluster com o novo tipo de nó.)

Cada nó em um cluster é do mesmo tipo de nó, e executa o mesmo software de cache do DAX. Para obter uma lista de tipos de nós disponíveis, consulte Preços do Amazon DynamoDB.

Clusters

Um cluster é um agrupamento lógico de um ou mais nós que o DAX gerencia como uma unidade. Um dos nós do cluster é designado como o nó primário e os outros nós (se houver) são réplicas de leitura.

O nó primário é responsável pelo seguinte:

  • Cumprir solicitações de aplicativo para dados em cache.

  • Tratar de operações de gravação para DynamoDB.

  • Remover dados do cache, de acordo com a política de remoção do cluster.

Quando alterações são feitas nos dados armazenados em cache no nó primário, o DAX propaga as alterações para todos os nós de réplica de leitura usando logs de replicação. Depois que a confirmação é recebida de todas as réplicas de leitura, o DynamoDB exclui os logs de replicação do nó primário.

As réplicas de leitura são responsáveis pelo seguinte:

  • Cumprir solicitações de aplicativo para dados em cache.

  • Remover dados do cache, de acordo com a política de remoção do cluster.

No entanto, ao contrário do nó primário, as réplicas de leitura não gravam no DynamoDB.

As réplicas de leitura têm duas finalidades adicionais:

  • Escalabilidade. Se houver um grande número de clientes de aplicações que precisam acessar o DAX simultaneamente, você poderá adicionar mais réplicas para escalabilidade de leitura. O DAX distribuirá a carga uniformemente entre todos os nós no cluster. (Outra forma de aumentar o throughput é usar maiores tipos de nó de cache.)

  • Alta disponibilidade. Em caso de falha de um nó principal, o DAX recupera automaticamente uma réplica de leitura e a designa como o novo nó principal. Se um nó de réplica falhar, outros nós no cluster do DAX ainda poderão atender às solicitações até que o nó com falha seja recuperado. Para obter a máxima tolerância a falhas, você deve implantar as réplicas de leitura em Zonas de disponibilidade separadas. Essa configuração garante que o cluster do DAX continue a funcionar, mesmo que toda uma zona de disponibilidade se torne indisponível.

Um cluster do DAX pode oferecer suporte a até 11 nós por cluster (o nó primário, mais um máximo de dez réplicas de leitura).

Importante

Para uso em produção, é altamente recomendável usar o DAX com pelo menos três nós e posicionar cada nó em diferentes zonas de disponibilidade. São necessários três nós para que um cluster DAX seja tolerante a falhas.

Um cluster do DAX pode ser implantado com um ou dois nós para workloads de desenvolvimento ou de teste. Os clusters de um e dois nós não são tolerantes a falhas, portanto, não convém usar menos de três nós na produção. Se o cluster de um ou dois nós encontrar erros de software ou de hardware, ele poderá se tornar indisponível ou perder os dados armazenados em cache.

Regiões e zonas de disponibilidade

Um cluster do DAX em uma região da AWS só pode interagir com tabelas do DynamoDB que estão na mesma região. Por esse motivo, é necessário iniciar o cluster do DAX na região correta. Se você tiver tabelas do DynamoDB em outras regiões, inicie os clusters do DAX também nessas regiões.

Cada região é projetada para ser completamente isolada das outras. Dentro de cada região há várias zonas de disponibilidade. Ao iniciar seus nós em diferentes zonas de disponibilidade, você é capaz de alcançar o máximo possível de tolerância a falhas.

Importante

Não coloque todos os nós do cluster em uma única zona de disponibilidade. Nessa configuração, o cluster do DAX se tornará indisponível no caso de uma falha na zona de disponibilidade.

Para uso em produção, é altamente recomendável usar o DAX com pelo menos três nós e posicionar cada nó em diferentes zonas de disponibilidade. São necessários três nós para que um cluster DAX seja tolerante a falhas.

Um cluster do DAX pode ser implantado com um ou dois nós para workloads de desenvolvimento ou de teste. Os clusters de um e dois nós não são tolerantes a falhas, portanto, não convém usar menos de três nós na produção. Se o cluster de um ou dois nós encontrar erros de software ou de hardware, ele poderá se tornar indisponível ou perder os dados armazenados em cache.

Grupos de parâmetros

Os grupos de parâmetros são usados para gerenciar as configurações de tempo de execução dos clusters do DAX. O DAX tem vários parâmetros que você pode usar para otimizar a performance (como a definição de uma política de TTL para dados armazenados em cache). Um grupo de parâmetros é um conjunto de parâmetros que você pode aplicar a um cluster. Dessa maneira, você garante que todos os nós desse cluster sejam configurados exatamente da mesma forma.

Grupos de segurança

Um cluster do DAX é executado em um ambiente da Amazon Virtual Private Cloud (Amazon VPC). Esse ambiente é uma rede virtual dedicada à sua conta da AWS e é isolada de outras VPCs. Um grupo de segurança atua como um firewall virtual para a VPC, permitindo que você controle o tráfego de entrada e saída de rede.

Ao iniciar um cluster na VPC, você adiciona uma regra de entrada ao grupo de segurança para permitir tráfego de rede de entrada. A regra de entrada especifica o protocolo (TCP) e o número da porta (8111) para seu cluster. Depois que você adiciona essa regra de entrada ao grupo de segurança, as aplicações em execução na VPC podem acessar o cluster do DAX.

ARN do cluster

A cada cluster do DAX é atribuído um nome do recurso da Amazon (ARN). O formato do ARN é o seguinte.

arn:aws:dax:region:accountID:cache/clusterName

Você usa o ARN do cluster em uma política do IAM para definir permissões para operações da API do DAX. Para ter mais informações, consulte Controle de acesso do DAX.

Endpoint do cluster

Cada cluster do DAX fornece um endpoint de cluster para ser usado pela sua aplicação. Ao acessar o cluster usando o endpoint, o aplicativo não precisa saber os nomes de hosts e os números de portas de nós individuais no cluster. O aplicativo "conhece" automaticamente todos os nós no cluster, mesmo que você adicione ou remova réplicas de leitura.

Veja a seguir um exemplo de endpoint de cluster na região us-east-1 que não está configurado para usar criptografia em trânsito.

dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com

Veja a seguir um exemplo de endpoint de cluster na mesma região que está configurada para usar criptografia em trânsito.

daxs://my-encrypted-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com

Endpoints de nó

Cada um dos nós individuais em um cluster do DAX tem seu próprio nome de host e número de porta. Veja a seguir um exemplo de endpoint de nó.

myDAXcluster-a.2cmrwl.clustercfg.dax.use1.cache.amazonaws.com:8111

O aplicativo pode acessar um nó diretamente usando o endpoint desse nó. No entanto, recomendamos tratar o cluster do DAX como uma unidade única e acessá-lo usando o endpoint do cluster. O endpoint do cluster faz com que o aplicativo não precise manter e atualizar uma lista de nós quando você adiciona ou remove nós do cluster.

Grupos de sub-redes

O acesso aos nós do cluster do DAX é restrito a aplicações em execução em instâncias do Amazon EC2 em um ambiente de Amazon VPC. Você pode usar grupos de sub-redes para conceder acesso ao cluster a partir de instâncias do Amazon EC2 em execução em sub-redes específicas. Um grupo de sub-redes é uma coleção de sub-redes (normalmente privadas) que você pode designar para clusters em execução em um ambiente de Amazon VPC.

Ao criar um cluster do DAX, você deve especificar um grupo de sub-redes. O DAX utiliza esse grupo de sub-redes para selecionar uma sub-rede e endereços IP nessa sub-rede para associar aos seus nós.

Eventos

O DAX registra eventos significativos em seus clusters, como uma falha ao adicionar um nó, êxito ao adicionar um nó ou alterações nos security groups. Ao monitorar eventos importantes, você pode saber o estado atual dos seus clusters e, dependendo do evento, poderá executar a ação corretiva. Você pode acessar esses eventos usando o AWS Management Console ou a ação DescribeEvents na API de gerenciamento do DAX.

Também é possível solicitar que essas notificações sejam enviadas a um tópico específico do Amazon Simple Notification Service (Amazon SNS). Com isso, você ficará sabendo imediatamente quando um evento ocorrer em seu cluster do DAX.

Janela de manutenção

Cada cluster tem uma janela de manutenção semanal para aplicação das alterações do sistema. À medida que as alterações são aplicadas sequencialmente, um nó existente é substituído e um novo nó com as alterações aplicadas é adicionado ao cluster. Durante esse período, sua aplicação pode observar controles de utilização ou erros transitórios. Portanto, recomendamos que você agende a janela de manutenção durante o período de menor uso e ajuste essa programação periodicamente conforme necessário. Você pode especificar um intervalo de tempo de até 24 horas de duração durante o qual todas as atividades de manutenção solicitadas devem ocorrer.

Se você não especificar uma janela de manutenção de sua preferência ao criar ou modificar um cluster de cache, o DAX atribuirá uma janela de manutenção de 60 minutos em um dia aleatório da semana. Essa janela de 60 minutos é selecionada aleatoriamente dentro de um bloco de 8 horas para cada Região da AWS. A seguinte tabela lista os blocos de tempo de cada região dos quais as janelas de manutenção padrão são atribuídas.

Código da região Nome da região Janela de manutenção
ap-northeast-1 Região Ásia-Pacífico (Tóquio) 13h às 21h (UTC)
ap-southeast-1 Região Ásia-Pacífico (Singapura) Das 14:00 às 22:00 (UTC)
ap-southeast-2 Região Ásia-Pacífico (Sydney) 12h às 20h (UTC)
ap-south-1 Região Ásia-Pacífico (Mumbai) 17h30 à 1h30 (UTC)
cn-northwest-1 Região China (Ningxia) Das 23h às 7h (UTC)
cn-north-1 Região China (Pequim) 14h às 22h (UTC)
eu-central-1 Região Europa (Frankfurt) 23h às 7h (UTC)
eu-west-1 Região Europa (Irlanda) 22h às 6h (UTC)
eu-west-2 Região Europa (Londres) 23h às 7h (UTC)
eu-west-3 Região Europa (Paris) 23h às 7h (UTC)
sa-east-1 Região América do Sul (São Paulo) 1h às 9h (UTC)
us-east-1 Região Leste dos EUA (N. da Virgínia) 3h às 7h (UTC)
us-east-2 Região Leste dos EUA (Ohio) 23h às 7h (UTC)
us-west-1 Região Oeste dos EUA (Norte da Califórnia) Das 6h às 14h (UTC)
us-west-2 Região Oeste dos EUA (Oregon) 6h às 14h (UTC)