Minimizando o tempo de inatividade ElastiCache usando o Multi-AZ com Valkey e Redis OSS

Há vários casos em que, ElastiCache com o Valkey e o Redis, OSS pode ser necessário 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 Domain Name Service (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 o. ElastiCache API

Habilitar o ElastiCache Multi-AZ em seu OSS cluster Valkey ou Redis (no grupo de replicação API eCLI,) 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 OSS clusters Valkey e Redis com mais de um nó em cada fragmento.

Habilitar Multi-AZ

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

Você pode habilitar o Multi-AZ somente em clusters Valkey ou 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 Criação de um grupo de replicação Valkey ou 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 Valkey ou 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 Valkey ou Redis ou ao modificar um OSS cluster existente com replicação.

O Multi-AZ é ativado por padrão nos clusters Valkey ou 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 Valkey (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 ElastiCache 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 JSON saída desse comando deve ser semelhante à 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:

Habilitar o recurso multi-AZ (ElastiCache API)

O exemplo de código a seguir usa o 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 ElastiCache APIReferência:

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 habilitar o failover automático, você pode testá-lo usando o ElastiCache console AWS CLI, o. e. 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 Valkey ou 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 o ElastiCache API

Você pode testar o failover automático em qualquer cluster habilitado com o Multi-AZ usando a ElastiCache API operação. 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 ElastiCache DescribeEvents API operação.

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

Limitações do Multi-AZ

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