Minimizando o tempo de inatividade no ElastiCache (Redis OSS) com o Multi-AZ

Há vários casos em que o ElastiCache (Redis OSS) pode precisar substituir um nó primário; isso inclui certos tipos de manutenção planejada e o evento improvável de uma falha no nó primário ou na zona de disponibilidade.

Essa substituição resulta em algum tempo de inatividade do cluster, mas se o multi-AZ estiver habilitado, o tempo de inatividade será minimizado. A função do nó primário fará failover automaticamente para uma das réplicas de leitura. Não há necessidade de criar e provisionar um novo nó primário, pois ele ElastiCache lidará com isso de forma transparente. O failover e a promoção de réplica garantem que você possa continuar a gravar no novo primário assim que a promoção estiver concluída.

ElastiCache também propaga o nome do Serviço de Nomes de Domínio (DNS) da réplica promovida. Isso ocorre porque, em seguida, se o seu aplicativo estiver gravando no endpoint primário, nenhuma alteração nesse endpoint será necessária no seu aplicativo. Se estiver lendo de endpoints individuais, altere o endpoint de leitura da réplica promovida a primária para o endpoint da nova réplica.

No caso de substituições de nó planejadas, iniciadas devido a atualizações de manutenção ou atualizações de autoatendimento, esteja ciente do seguinte:

Você pode ativar o Multi-AZ usando o ElastiCache Management Console AWS CLI, o ou a ElastiCache API.

Habilitar o ElastiCache Multi-AZ em seu cluster Redis OSS (na API e na CLI, grupo de replicação) melhora sua tolerância a falhas. Isso é verdade, especialmente nos casos em que o cluster primário de leitura/gravação do seu cluster se torna inacessível ou falha por qualquer motivo. O Multi-AZ só é compatível com clusters Redis OSS que têm mais de um nó em cada fragmento.

Habilitar Multi-AZ

Você pode ativar o Multi-AZ ao criar ou modificar um cluster (API ou CLI, grupo de replicação) usando ElastiCache o console AWS CLI ou a API. ElastiCache

Você pode habilitar o Multi-AZ somente em clusters Redis OSS (modo de cluster desativado) que tenham pelo menos uma réplica de leitura disponível. Clusters sem réplicas de leitura não fornece alta disponibilidade ou tolerância a falhas. Para obter informações sobre como criar um cluster com replicação, consulte Criando um grupo de replicação do Redis OSS. Para obter informações sobre como adicionar uma réplica de leitura a um cluster com replicação, consulte Adicionar uma réplica de leitura para grupos de replicação do Redis OSS (Modo de cluster desativado).

Habilitação do multi-AZ (console)

Você pode habilitar o Multi-AZ usando o ElastiCache console ao criar um novo cluster Redis OSS ou modificando um cluster Redis OSS existente com replicação.

O Multi-AZ é ativado por padrão nos clusters Redis OSS (modo de cluster ativado).

Ativando o Multi-AZ ao criar um cluster usando o console ElastiCache

Para obter mais informações sobre esse processo, consulte Criação de um cluster Redis OSS (modo de cluster desativado) (console). Tenha uma ou mais réplicas e habilite o Multi-AZ.

Habilitação do multi-AZ em um cluster existente (console)

Para obter mais informações sobre esse processo, consulte Modificação de um cluster Usando o AWS Management Console.

Habilitar o recurso multi-AZ (AWS CLI)

O exemplo de código a seguir usa o AWS CLI para habilitar o Multi-AZ para o grupo de replicação. redis12

Para Linux, macOS ou Unix:

aws elasticache modify-replication-group \
    --replication-group-id redis12 \
    --automatic-failover-enabled \
    --multi-az-enabled \
    --apply-immediately

Para Windows:

aws elasticache modify-replication-group ^
    --replication-group-id redis12 ^
    --automatic-failover-enabled ^
    --multi-az-enabled ^
    --apply-immediately

A saída JSON desse comando deve ser semelhante ao seguinte.

{
    "ReplicationGroup": {
        "Status": "modifying", 
        "Description": "One shard, two nodes", 
        "NodeGroups": [
            {
                "Status": "modifying", 
                "NodeGroupMembers": [
                    {
                        "CurrentRole": "primary", 
                        "PreferredAvailabilityZone": "us-west-2b", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis12-001.v5r9dc.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis12-001"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2a", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis12-002.v5r9dc.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis12-002"
                    }
                ], 
                "NodeGroupId": "0001", 
                "PrimaryEndpoint": {
                    "Port": 6379, 
                    "Address": "redis12.v5r9dc.ng.0001.usw2.cache.amazonaws.com"
                }
            }
        ], 
        "ReplicationGroupId": "redis12", 
        "SnapshotRetentionLimit": 1, 
        "AutomaticFailover": "enabling", 
        "MultiAZ": "enabled", 
        "SnapshotWindow": "07:00-08:00", 
        "SnapshottingClusterId": "redis12-002", 
        "MemberClusters": [
            "redis12-001", 
            "redis12-002"
        ], 
        "PendingModifiedValues": {}
    }
}

Para obter mais informações, consulte estes tópicos na AWS CLI Referência de comandos:

Ativando o Multi-AZ (ElastiCache API)

O exemplo de código a seguir usa a ElastiCache API para habilitar o Multi-AZ para o grupo de replicação. redis12

https://elasticache.us-west-2.amazonaws.com/
    ?Action=ModifyReplicationGroup
    &ApplyImmediately=true
    &AutoFailover=true
    &MultiAZEnabled=true
    &ReplicationGroupId=redis12
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20140401T192317Z
    &X-Amz-Credential=<credential>

Para obter mais informações, consulte esses tópicos na Referência ElastiCache da API:

Cenários de falha com respostas do multi-AZ

Antes da introdução do Multi-AZ, ElastiCache detectou e substituiu os nós com falha de um cluster recriando e reprovisionando o nó com falha. Se você habilitar o Multi-AZ, um nó primário com falha fará failover para a réplica com o menor atraso de replicação. A réplica selecionada é promovida automaticamente para primário, o que é muito mais rápido do que criar e reprovisionar um novo nó primário. Esse processo normalmente demora apenas alguns segundos até que você possa gravar novamente no cluster.

Quando o Multi-AZ está ativado, monitora ElastiCache continuamente o estado do nó primário. Se o nó primário falhar, uma das seguintes ações será realizada, dependendo do tipo da falha.

Cenários de falha quando somente o nó primário falha

Se somente o nó primário falhar, a réplica de leitura com o menor atraso de replicação será promovida a primária. Depois disso, uma réplica de leitura de substituição é criada e provisionada na mesma zona de disponibilidade que o primário com falha.

Quando somente o nó primário falha, o ElastiCache Multi-AZ faz o seguinte:

Depois que a nova réplica estiver disponível, lembre-se dos seguintes efeitos:

Para obter informações sobre como encontrar os endpoints de um cluster, consulte os seguintes tópicos:

Cenários de falha quando o nó primário e algumas réplicas de leitura falham

Se o primário e pelo menos uma réplica de leitura falhar, a réplica disponível com o menor atraso de replicação será promovida a cluster primário. Novas réplicas de leitura também são criadas e provisionadas nas mesmas Zonas de disponibilidade que os nós com falha e a réplica que foi promovida a primário.

Quando o nó primário e algumas réplicas de leitura falham, o ElastiCache Multi-AZ faz o seguinte:

Faça as seguintes alterações no seu aplicativo depois que os novos nós estiverem disponíveis:

Cenários de falha quando cluster inteiro falha

Se tudo falhar, todos os nós serão recriados e provisionados nas mesmas Zonas de disponibilidade que os nós originais.

Nesse cenário, todos os dados do cluster são perdidos devido à falha de cada nó no cluster. Essa ocorrência é rara.

Quando todo o cluster falha, o ElastiCache Multi-AZ faz o seguinte:

Como cada um dos nós de substituição tem o mesmo endpoint que o nó que ele está substituindo, não é necessário fazer alterações de endpoint no seu aplicativo.

Para obter informações sobre como encontrar os endpoints de um grupo de replicação, consulte os seguintes tópicos:

Recomendamos que você crie o nó primário e as réplicas de leitura em diferentes Zonas de disponibilidade para aumentar o nível de tolerância a falhas.

Teste do failover automático

Depois de ativar o failover automático, você pode testá-lo usando o ElastiCache console AWS CLI, o e a ElastiCache API.

Ao testar, observe o seguinte:

Testando o failover automático usando o AWS Management Console

Use o procedimento a seguir para testar o failover automático com o console.

Testando o failover automático usando o AWS CLI

Você pode testar o failover automático em qualquer cluster habilitado para Multi-AZ usando a AWS CLI operação. test-failover

O exemplo a seguir usa o AWS CLI para testar o failover automático no grupo de nós redis00-0003 no cluster Redis OSS (modo de cluster ativado). redis00

aws elasticache test-failover \
   --replication-group-id redis00 \
   --node-group-id redis00-0003

aws elasticache test-failover ^
   --replication-group-id redis00 ^
   --node-group-id redis00-0003

A saída do comando precedente é semelhante ao seguinte.

{
    "ReplicationGroup": {
        "Status": "available", 
        "Description": "1 shard, 3 nodes (1 + 2 replicas)", 
        "NodeGroups": [
            {
                "Status": "available", 
                "NodeGroupMembers": [
                    {
                        "CurrentRole": "primary", 
                        "PreferredAvailabilityZone": "us-west-2c", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-001.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-001"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2a", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-002.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-002"
                    }, 
                    {
                        "CurrentRole": "replica", 
                        "PreferredAvailabilityZone": "us-west-2b", 
                        "CacheNodeId": "0001", 
                        "ReadEndpoint": {
                            "Port": 6379, 
                            "Address": "redis1x3-003.7ekv3t.0001.usw2.cache.amazonaws.com"
                        }, 
                        "CacheClusterId": "redis1x3-003"
                    }
                ], 
                "NodeGroupId": "0001", 
                "PrimaryEndpoint": {
                    "Port": 6379, 
                    "Address": "redis1x3.7ekv3t.ng.0001.usw2.cache.amazonaws.com"
                }
            }
        ], 
        "ClusterEnabled": false, 
        "ReplicationGroupId": "redis1x3", 
        "SnapshotRetentionLimit": 1, 
        "AutomaticFailover": "enabled", 
        "MultiAZ": "enabled",
        "SnapshotWindow": "11:30-12:30", 
        "SnapshottingClusterId": "redis1x3-002", 
        "MemberClusters": [
            "redis1x3-001", 
            "redis1x3-002", 
            "redis1x3-003"
        ], 
        "CacheNodeType": "cache.m3.medium", 
        "DataTiering": "disabled",
        "PendingModifiedValues": {}
    }
}

Para acompanhar o progresso do seu failover, use a AWS CLI describe-events operação.

Para obter mais informações, consulte as informações a seguir.

Testando o failover automático usando a API ElastiCache

Você pode testar o failover automático em qualquer cluster habilitado com o Multi-AZ usando a operação da ElastiCache API. TestFailover

O exemplo a seguir testa o failover automático no grupo de nós redis00-0003 no grupo de replicação (no console, cluster) redis00.

https://elasticache.us-west-2.amazonaws.com/
    ?Action=TestFailover
    &NodeGroupId=redis00-0003
    &ReplicationGroupId=redis00
    &Version=2015-02-02
    &SignatureVersion=4
    &SignatureMethod=HmacSHA256
    &Timestamp=20140401T192317Z
    &X-Amz-Credential=<credential>

Para acompanhar o progresso do seu failover, use a operação da ElastiCache DescribeEvents API.

Para obter mais informações, consulte as informações a seguir.

Limitações no Redis OSS Multi-AZ

Esteja ciente das seguintes limitações do Redis OSS Multi-AZ: