Minimizar el tiempo de inactividad ElastiCache mediante el uso de Multi-AZ con Valkey y Redis OSS

Existen varios casos ElastiCache en los que el OSS de Valkey y Redis puede ser necesario reemplazar un nodo principal; estos incluyen ciertos tipos de mantenimiento planificado y el improbable caso de que se produzca un fallo en el nodo principal o en la zona de disponibilidad.

Este reemplazo produce un tiempo de inactividad para el clúster, pero si Multi-AZ se encuentra habilitado, el tiempo de inactividad es mínimo. El rol del nodo primario tendrá una conmutación por error automática en una de las réplicas de lectura. No es necesario crear ni aprovisionar un nuevo nodo principal, ya que ElastiCache lo gestionará de forma transparente. Esta conmutación por error y promoción de réplica garantizan la posibilidad de reanudar la escritura en la réplica principal tan pronto como se complete la promoción.

ElastiCache también propaga el nombre del Servicio de nombres de dominio (DNS) de la réplica promocionada. Lo hace así porque, en ese caso, si su aplicación escribe en el punto de enlace principal, no se requiere ningún cambio de punto de conexión en su aplicación. Si lee desde puntos de conexión individuales, asegúrese de cambiar el punto de enlace de lectura de la réplica promovida a principal en el punto de enlace de la nueva réplica.

En caso de que se inicien reemplazos de nodos planificados debido a actualizaciones de mantenimiento o actualizaciones de autoservicio, tenga en cuenta lo siguiente:

Puede habilitar Multi-AZ mediante la consola de ElastiCache administración, la o la API AWS CLI. ElastiCache

La activación de ElastiCache Multi-AZ en su clúster OSS de Valkey o Redis (en la API y la CLI, grupo de replicación) mejora su tolerancia a los errores. Esto es cierto especialmente en los casos en que el nodo principal de lectura/escritura del clúster deja de estar accesible o de funcionar por cualquier motivo. Multi-AZ solo se admite en clústeres de Valkey o Redis OSS que tienen más de un nodo en cada partición.

Habilitación de Multi-AZ

Puede habilitar Multi-AZ al crear o modificar un clúster (API o CLI, grupo de replicación) mediante la ElastiCache consola o la ElastiCache API. AWS CLI

Solo puede habilitar multi-AZ en clústeres de Valkey o Redis OSS (modo de clúster deshabilitado) que tengan al menos una réplica de lectura disponible. Los clústeres sin réplicas de lectura no ofrecen alta disponibilidad ni tolerancia a errores. Para obtener información acerca de la creación de clústeres con reproducción, consulte Creación de un grupo de replicación de Valkey o Redis OSS. Para obtener información acerca de la adición de réplicas de lectura a un clúster con reproducción, consulte Adición de una réplica de lectura para Valkey o Redis OSS (modo de clúster deshabilitado).

Habilitación de Multi-AZ (consola)

Puede habilitar las zonas de disponibilidad múltiples mediante la ElastiCache consola al crear un nuevo clúster de OSS de Valkey o Redis o al modificar un clúster existente mediante la replicación.

Multi-AZ se encuentra habilitado de forma predeterminada en los clústeres de Valkey o Redis OSS (modo de clúster habilitado).

Habilitar Multi-AZ al crear un clúster mediante la consola ElastiCache

Para obtener más información acerca de este proceso, consulte Creación de un clúster de Valkey (modo de clúster deshabilitado) (consola). Asegúrese de tener una o más réplicas y habilitar Multi-AZ.

Habilitación de Multi-AZ en un clúster existente (consola)

Para obtener más información sobre este proceso, consulte Modificación de un clúster Uso del ElastiCache AWS Management Console.

Habilitación de Multi-AZ (AWS CLI)

En el siguiente ejemplo de código, se utiliza AWS CLI para habilitar la zona de disponibilidad múltiple para el grupo de replicación. redis12

Para Linux, macOS o 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

La salida JSON de este comando debería tener un aspecto similar al siguiente.

{
    "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 obtener más información, consulte los temas siguientes en la Referencia de los comandos de la AWS CLI :

Habilitación de Multi-AZ (ElastiCache API)

El siguiente ejemplo de código usa la ElastiCache API para habilitar las zonas de disponibilidad múltiples para el grupo de replicación. 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 obtener más información, consulte los temas siguientes en la Referencia de la API de ElastiCache :

Escenarios de error con respuestas de Multi-AZ

Antes de la introducción de Multi-AZ, ElastiCache detectaba y sustituía los nodos defectuosos de un clúster mediante la recreación y el reaprovisionamiento del nodo defectuoso. Si habilita Multi-AZ, un nodo principal que produce error conmuta por error a la réplica con el menor retraso de reproducción. La réplica seleccionada se promocionará automáticamente a la principal, lo cual es mucho más rápido que crear y reaprovisionar un nuevo nodo principal. Este proceso suele tardar tan solo unos segundos hasta que se puede escribir de nuevo en el clúster.

Cuando la Multi-AZ está habilitada, supervisa ElastiCache continuamente el estado del nodo principal. Si se produce un error en el nodo principal, se realiza una de las siguientes acciones en función del tipo de error.

Escenarios de error cuando solo se produce un error en el nodo principal

Si solo se produce un error en el nodo principal, la réplica de lectura con el menor retardo de reproducción se promociona al clúster principal. A continuación, se crea una réplica de lectura de reemplazo y se aprovisiona en la misma zona de disponibilidad que el principal ha producido un error.

Cuando solo falla el nodo principal, ElastiCache Multi-AZ hace lo siguiente:

Una vez que la nueva réplica esté disponible, tenga en cuenta estos efectos:

Para obtener información acerca de la búsqueda de los puntos de conexión de un clúster, consulte los temas siguientes:

Escenarios de error cuando el nodo primario y algunas réplicas de lectura producen un error

Si se produce un error en el nodo principal y en al menos una réplica, la réplica disponible con el menor retardo de reproducción se promocionará al clúster principal. Las nuevas réplicas de lectura también se crean y se aprovisionan en las mismas zonas de disponibilidad que las de los nodos con error y que la réplica que se promocionó a nodo principal.

Cuando el nodo principal y algunas réplicas de lectura fallan, ElastiCache Multi-AZ hace lo siguiente:

Debe realizar los siguientes cambios en su aplicación una vez que los nuevos nodos estén disponibles:

Escenarios de error cuando se produce un error en todo el clúster

Si el error es general, todos los nodos se volverán a crear y a aprovisionar en las mismas zonas de disponibilidad que las de los nodos originales.

En esta situación, se perderán todos los datos del clúster debido al error de todos los nodos del clúster. Este tipo de error no suele producirse con frecuencia.

Cuando se produce un error en todo el clúster, ElastiCache Multi-AZ hace lo siguiente:

Puesto que cada uno de los nodos de reemplazo tendrán el mismo punto de conexión que el nodo al que reemplacen, no es necesario realizar ningún cambio de punto de conexión en su aplicación.

Para obtener información acerca de la búsqueda de los puntos de enlace de un grupo de replicación, consulte los temas siguientes:

Recomendamos que cree el nodo principal y las réplicas de lectura en distintas zonas de disponibilidad para incrementar el nivel de tolerancia a errores.

Prueba de la conmutación por error automática

Después de habilitar la conmutación por error automática, puede probarla mediante la ElastiCache consola AWS CLI, la y la ElastiCache API.

Cuando realice las pruebas, tenga en cuenta lo siguiente:

Probar la conmutación por error automática mediante el AWS Management Console

Utilice el procedimiento siguiente para probar la conmutación por error automática con la consola.

Probar la conmutación por error automática mediante el AWS CLI

Puede probar la conmutación por error automática en cualquier clúster habilitado para zonas de disponibilidad múltiples mediante esta operación. AWS CLI test-failover

En el siguiente ejemplo, se utiliza AWS CLI para probar la conmutación por error automática en el grupo redis00-0003 de nodos del clúster OSS (modo de clúster habilitado) de Valkey o Redis. 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

La salida del comando anterior es similar a la siguiente.

{
    "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 realizar un seguimiento del progreso de la conmutación por error, utilice la operación. AWS CLI describe-events

Para obtener más información, consulte los siguientes temas:

Probar la conmutación por error automática mediante la API ElastiCache

Puede probar la conmutación por error automática en cualquier clúster habilitado con Multi-AZ mediante la operación de ElastiCache API. TestFailover

El ejemplo siguiente comprueba la conmutación por error automática en el grupo de nodos redis00-0003 del grupo de reproducción (clúster, en la consola) 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 realizar un seguimiento del progreso de la conmutación por error, utilice la operación de la ElastiCache DescribeEvents API.

Para obtener más información, consulte los siguientes temas:

Limitaciones en multi-AZ

Tenga en cuenta las siguientes limitaciones para multi-AZ: