Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Resiliencia en Amazon ElastiCache
La infraestructura AWS global se basa en AWS regiones y zonas de disponibilidad. AWS Las regiones proporcionan varias zonas de disponibilidad aisladas y separadas físicamente, que están conectadas mediante redes de baja latencia, alto rendimiento y alta redundancia. Con las zonas de disponibilidad, puede diseñar y utilizar aplicaciones y bases de datos que realizan una conmutación por error automática entre zonas de disponibilidad sin interrupciones. Las zonas de disponibilidad tienen una mayor disponibilidad, tolerancia a errores y escalabilidad que las infraestructuras tradicionales de centros de datos únicos o múltiples.
Además de la infraestructura AWS global, Amazon ElastiCache ofrece varias funciones que ayudan a respaldar sus necesidades de respaldo y resiliencia de datos.
Mitigación de errores
Cuando planifique ElastiCache la implementación de Amazon, debe planificar de manera que los errores tengan un impacto mínimo en su aplicación y sus datos. Los temas de esta sección abordan enfoques que puede aplicar para proteger la aplicación y los datos frente a errores.
Temas
Mitigación de errores al ejecutar Memcached
Al ejecutar el motor de Memcached, dispondrá de las opciones siguientes para minimizar el impacto de los errores. Existen dos tipos de errores que debe abordar en los planes de mitigación: errores de nodos y errores de zonas de disponibilidad.
Mitigación de errores de nodos
Las cachés sin servidor mitigan automáticamente los errores de los nodos con una arquitectura replicada de varias zonas de disponibilidad para que los errores de los nodos sean transparentes para su aplicación. Para mitigar el impacto de un error de nodo en un clúster de autodiseño, reparta los datos almacenados en caché por varios nodos. Como los clústeres de autodiseño no son compatibles con la réplica, los errores en nodos siempre tendrán como consecuencia la pérdida de datos en su clúster.
Al crear su clúster de Memcached, puede crearlo con 1 a 60 nodos o más si lo solicita de forma especial. Repartir los datos entre un mayor número de nodos implica que perderá menos datos en caso de error en algún nodo. Por ejemplo, si reparte los datos en 10 nodos, un único nodo almacenará aproximadamente un 10 % de los datos almacenados en la caché. En este caso, un error de nodo supondrá una pérdida aproximada del 10 % de la caché, que deberá reemplazarse cuando se cree y aprovisione un nodo de reemplazo. Si los datos se almacenan en caché en 3 nodos de mayor tamaño, un error en un nodo supondría una pérdida aproximada del 33 % de los datos almacenados en la caché.
Para obtener información acerca de la especificación del número de nodos en un clúster de Memcached, consulte Creación de un clúster de Memcached (consola).
Mitigación de errores de zona de disponibilidad
Las cachés sin servidor mitigan automáticamente los errores de las zonas de disponibilidad con una arquitectura replicada de varias zonas de disponibilidad a fin de que los errores de estas zonas sean transparentes para su aplicación.
Para mitigar el impacto de los errores de una zona de disponibilidad en un clúster de autodiseño, busque los nodos en tantas zonas de disponibilidad como sea posible. En el improbable caso de que se produzca un error en la zona de disponibilidad, perderá los datos guardados en la caché de esa zona, no los datos almacenados en la otra. AZs
¿Por qué tantos nodos?
Dado que mi región solo tiene tres zonas de disponibilidad, si se produjera un error en una de ellas, perdería aproximadamente un tercio de los datos. En ese caso, ¿por qué son necesarios más de tres nodos?
Esta es una excelente pregunta. Recuerde que estamos intentando mitigar dos tipos distintos de errores: errores de nodos y errores de zonas de disponibilidad. Tiene razón. Si los datos están distribuidos en distintas zonas de disponibilidad y, si se produce un error en una de ellas, solo perderá los datos almacenados en la memoria caché de dicha zona de disponibilidad, independientemente del número de nodos que tenga. Sin embargo, en caso de error en un nodo, disponer de más nodos reducirá la proporción de datos perdidos.
No existe ninguna “fórmula mágica” para determinar la cantidad de nodos que debe tener en un clúster. Debe sopesar el impacto de la pérdida de datos frente a la probabilidad de que se produzca algún error y los costos para llegar a su propia conclusión.
Para obtener información acerca de la especificación del número de nodos en un clúster de Memcached, consulte Creación de un clúster de Memcached (consola).
Para obtener información acerca de las regiones y zonas de disponibilidad, consulte Regiones y zonas de disponibilidad.
Mitigar los errores al ejecutar Valkey o Redis OSS
Al ejecutar un OSS motor Valkey o Redis, dispone de las siguientes opciones para minimizar el impacto de un fallo en un nodo o en una zona de disponibilidad.
Mitigación de errores de nodos
Las cachés sin servidor mitigan automáticamente los errores de los nodos con una arquitectura de varias zonas de disponibilidad a fin de que los errores de los nodos sean transparentes para su aplicación. Los clústeres de autodiseño deben configurarse adecuadamente para mitigar el fallo de un nodo individual.
Para mitigar el impacto de los fallos de los OSS nodos de Valkey o Redis en los clústeres de diseño propio, dispone de las siguientes opciones:
Mitigación de errores: grupos de replicación de Valkey o Redis OSS
Un grupo de OSS replicación de Valkey o Redis se compone de un único nodo principal desde el que la aplicación puede leer y escribir, y de 1 a 5 nodos de réplica de solo lectura. Cuando se escriben datos en el nodo principal, también se actualizan de forma asíncrona en los nodos de réplica de lectura.
Qué sucede en caso de error en una réplica de lectura
ElastiCache detecta la réplica de lectura fallida.
ElastiCache desconecta el nodo fallido.
ElastiCache lanza y aprovisiona un nodo de reemplazo en la misma zona de disponibilidad.
El nuevo nodo se sincroniza con el nodo principal.
Durante este tiempo, la aplicación podrá seguir realizando operaciones de lectura y escritura con los demás nodos.
Valkey o OSS Redis Multi-AZ
Puede habilitar Multi-AZ en sus grupos de replicación de Valkey o Redis. OSS Independientemente de que habilite Multi-AZ o no, se detectará y reemplazará automáticamente un error en el nodo principal. El modo en que esto tiene lugar varía en función de si Multi-AZ está habilitado o no.
Cuando Multi-AZ está habilitado
ElastiCache detecta la falla del nodo principal.
ElastiCache promueve el nodo de réplica de lectura con el menor retraso de replicación con respecto al nodo principal.
El resto de réplicas se sincronizarán con el nuevo nodo principal.
ElastiCache genera una réplica de lectura en la zona de disponibilidad del dispositivo primario que ha fallado.
El nuevo nodo se sincroniza con el nodo principal recién promovido.
La conmutación por error a un nodo de réplica suele ser más rápida que la creación y el aprovisionamiento de un nuevo nodo principal. Esto significa que la aplicación podrá reanudar la escritura en el nodo principal antes que si Multi-AZ no estuviera habilitado.
Para obtener más información, consulte Minimizar el tiempo de inactividad ElastiCache mediante el uso de Multi-AZ con Valkey y Redis OSS.
Cuando Multi-AZ está deshabilitado
ElastiCache detecta un fallo principal.
ElastiCache desconecta el principal.
ElastiCache crea y aprovisiona un nuevo nodo principal para reemplazar el nodo principal defectuoso.
ElastiCache sincroniza el nuevo primario con una de las réplicas existentes.
Cuando finaliza la sincronización, el nuevo nodo funciona como el nodo principal del clúster.
Durante los pasos 1 a 4 de este proceso, la aplicación no puede escribir en el nodo principal. Sin embargo, la aplicación podrá seguir leyendo datos de los nodos de réplica.
Para mayor protección, le recomendamos que lance los nodos del grupo de replicación en distintas zonas de disponibilidad ()AZs. De este modo, los errores en zonas de disponibilidad solo afectarán a los nodos de dichas zonas de disponibilidad, no a los demás.
Para obtener más información, consulte Alta disponibilidad a través de grupos de reproducción.
Mitigación de errores de zona de disponibilidad
Las cachés sin servidor mitigan automáticamente los errores de las zonas de disponibilidad con una arquitectura replicada de varias zonas de disponibilidad a fin de que los errores de estas zonas sean transparentes para su aplicación.
Para mitigar el impacto de los errores de una zona de disponibilidad en un clúster de autodiseño, busque los nodos de cada partición en tantas zonas de disponibilidad como sea posible.
Independientemente de la cantidad de nodos que tenga en una partición, si se encuentran en la misma zona de disponibilidad, un error catastrófico en dicha zona tendría como resultado la pérdida de todos los datos de la partición. Sin embargo, si ubica los nodos en varias zonasAZs, si se produce un fallo en una zona de disponibilidad, solo perderá los nodos de esa zona.
Cada vez que se pierde un nodo, puede experimentar una reducción del rendimiento, ya que las operaciones de lectura son compartidas por menos nodos. Esta reducción del rendimiento continuará hasta que los nodos se reemplacen.
Para obtener información sobre cómo especificar las zonas de disponibilidad para los OSS nodos de Valkey o Redis, consulte. Creación de un clúster Valkey (modo de clúster desactivado) (consola)
Para obtener más información acerca de las regiones y zonas de disponibilidad, consulte Selección de regiones y zonas de disponibilidad para ElastiCache.
Recomendaciones
Es recomendable crear cachés sin servidor en clústeres de autodiseño, ya que obtendrá automáticamente una mejor tolerancia a errores sin necesidad de configuración adicional. Sin embargo, al crear un clúster de autodiseño, hay dos tipos de errores para los que debe estar preparado: los errores de nodos individuales y los errores generalizados en zonas de disponibilidad. Los mejores planes de mitigación de errores abordarán ambos tipos de errores.
Minimización del impacto de los errores de nodos
Para minimizar el impacto de una falla en un nodo al usar Valkey o RedisOSS, recomendamos que la implementación utilice varios nodos en cada fragmento y distribuya los nodos en varias zonas de disponibilidad. Esto se hace automáticamente en las cachés sin servidor.
En el caso de los clústeres de diseño propio en Valkey o RedisOSS, le recomendamos que habilite Multi-AZ en su grupo de replicación para que la conmutación por error automática a una réplica en caso de que se ElastiCache produzca un error en el nodo principal.
Cuando ejecute Memcached y tenga distribuidos los datos en distintos nodos, cuantos más nodos utilice, menor será la pérdida de datos en caso de error en algún nodo.
Minimización del impacto de los errores en la zona de disponibilidad
Para minimizar el impacto de un error en una zona de disponibilidad, recomendamos lanzar los nodos en tantas zonas de disponibilidad distintas como sea posible. Distribuir los nodos de manera uniforme AZs minimizará el impacto en el improbable caso de que se produzca una falla en la zona de disponibilidad. Esto se hace automáticamente en las cachés sin servidor.
Otras precauciones
Si utilizas Valkey o RedisOSS, además de lo anterior, te recomendamos que programes copias de seguridad periódicas del clúster. Las copias de seguridad (instantáneas) crean un archivo .rdb que podrá utilizar para restablecer la caché en caso de error o daño. Para obtener más información, consulte Instantánea y restauración.
