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, puedes 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 un número de nodos comprendido entre 1 y 60, o más si se 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 guardados 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 más información acerca de las regiones y zonas de disponibilidad, consulte Selección de regiones y zonas de disponibilidad para ElastiCache.
Mitigación de errores al ejecutar Valkey o Redis OSS
Si ejecuta un motor de Valkey o Redis OSS, dispondrá de las siguientes opciones para minimizar el impacto de los errores que se produzcan en un nodo o 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 errores de los nodos de Valkey o Redis OSS en los clústeres de autodiseño, dispone de las siguientes opciones:
Mitigación de errores: grupos de replicación de Valkey o Redis OSS
Un grupo de replicación de Valkey o Redis OSS se compone de un solo nodo principal, disponible para operaciones de lectura y escritura para su aplicación, 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.
Multi-AZ de Valkey o Redis OSS
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 el fallo 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 que ha fallado.
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 zonas AZs, si se produce un fallo en una zona de disponibilidad, solo perderá los nodos de esa zona de disponibilidad.
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 más información acerca de la especificación de zonas de disponibilidad en los nodos de Valkey o Redis OSS, consulte Creación de un clúster de Valkey (modo de clúster deshabilitado) (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 un error en un nodo al utilizar Valkey o Redis OSS, recomendamos que su implementación utilice varios nodos en cada partición 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 autodiseñados en Valkey o Redis OSS, le recomendamos que habilite la opción 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 ElastiCache se 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 ejecuta Valkey o Redis OSS, además de todo lo anterior, recomendamos que programe 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.
