Pilar de fiabilidad

El pilar de la confiabilidad abarca la capacidad de una carga de trabajo para realizar la función prevista de manera correcta y coherente cuando se espera que lo haga. Esto incluye la capacidad de operar y probar la carga de trabajo durante todo su ciclo de vida.

La configuración de una carga de trabajo confiable comienza con decisiones de diseño iniciales tanto para el software como para la infraestructura. Sus elecciones respecto a la arquitectura afectarán al comportamiento de su carga de trabajo en todos los pilares de Well-Architected. Para lograr la confiabilidad, debe seguir patrones específicos.

El pilar de la fiabilidad se centra en las siguientes áreas clave:

• Arquitectura de carga de trabajo, incluidas las cuotas de servicio y los patrones de implementación

• Administración y escalado de instancias de InfluxDB

Arquitectura de carga de trabajo, incluidas las cuotas de servicio y los patrones de despliegue

Cada uno Cuenta de AWS tiene cuotas para los recursos que se ofrecen en cada uno Región de AWS. Por ejemplo, cada región tiene una cuota de Timestream para las instancias de InfluxDB, independientemente del tamaño de la instancia. Cuando se alcanza el número máximo de instancias en una región, las llamadas adicionales para crear instancias fallan, salvo una excepción. El volumen de almacenamiento de una instancia de Timestream para InfluxDB puede crecer hasta un tamaño máximo de 16 tebibytes () en total. TiBs Regiones de AWS

Patrones de implementación

Para obtener una alta disponibilidad y compatibilidad con la conmutación por error de las instancias de Timestream for InfluxDB, puede utilizar las implementaciones Multi-AZ con una única instancia de base de datos en espera. Este tipo de implementación se denomina Implementación de instancia de base de datos Multi-AZ. Amazon Timestream para InfluxDB utiliza la tecnología de conmutación por error de Amazon. En una implementación de instancia de base de datos Multi-AZ, Amazon Timestream aprovisiona y mantiene automáticamente una réplica en espera sincrónica en una zona de disponibilidad diferente. Para proporcionar redundancia de datos, la instancia de base de datos principal se replica de forma sincrónica en todas las zonas de disponibilidad hasta la réplica en espera.

La ejecución de una instancia de base de datos con alta disponibilidad puede proporcionar disponibilidad durante un fallo de la instancia de base de datos o una interrupción en la zona de disponibilidad. Si una interrupción imprevista de la instancia de base de datos se debe a un defecto en la infraestructura, Amazon Timestream for InfluxDB cambia automáticamente a la réplica en espera. El tiempo requerido para completar la conmutación por error dependerá de la actividad de la base de datos y de otras condiciones existentes en el momento en que la instancia de base de datos principal deja de estar disponible.

Los tiempos de conmutación por error suelen estar entre 60–120 segundos. Sin embargo, las transacciones grandes con datos de alta cardinalidad o un proceso de recuperación prolongado con requisitos previos al calentamiento pueden aumentar el tiempo de conmutación por error. Una vez finalizada la conmutación por error, es posible que se necesite más tiempo antes de que la consola de Timestream refleje la nueva zona de disponibilidad.

Si su aplicación debe permanecer disponible durante una Región de AWS interrupción total, considere configurar la replicación o enviarla a otra región como parte de sus planes de recuperación ante desastres (DR). Sin embargo, antes de configurar la replicación, asegúrese de entender las limitaciones. Para obtener más información, consulte la documentación de InfluxDB.

Amazon Timestream para InfluxDB realiza copias de seguridad internas de forma periódica y las conserva durante 24 horas para garantizar la disponibilidad y la durabilidad. Las instantáneas se toman durante las eliminaciones y se conservan durante 30 días para permitir las restauraciones. Para acceder a ellas o utilizarlas, cree un caso en. AWS Support

Administre y escale Timestream para InfluxDB

Timestream for InfluxDB admite clases de instancias que son ideales para ejecutar cargas de trabajo que consumen mucha memoria en bases de datos de InfluxDB de código abierto. Las distintas clases de instancias de db.flux tienen límites en cuanto a v, memoria, almacenamiento y ancho de banda de red. CPUs Para elegir la clase de instancia que se ajuste a los requisitos de latencia de escritura y consulta de tu aplicación CloudWatch CPUUtilizationMemoryUtilization, observa Amazon y DiskUtilization las métricas durante las pruebas. Puedes escalar tus instancias hacia arriba o hacia abajo en función de tus requisitos de carga de trabajo. Timestream for InfluxDB proporciona varios niveles de almacenamiento preconfigurados con las IOPS óptimas y el rendimiento necesarios para los diferentes tipos de cargas de trabajo. Elija lo que mejor se adapte a su carga de trabajo en función de sus requisitos.

Si sus necesidades de escalado cambian en momentos predecibles, puede usar una AWS Lambda función o un programador personalizado y ejecutar una API o un SDK para escalar hacia arriba y hacia abajo con un tiempo de búfer.

La configuración de InfluxDB se administra en Timestream para InfluxDB mediante los parámetros de un grupo de parámetros. Los grupos de parámetros actúan como contenedores de las opciones de configuración de InfluxDB que se aplican a una o más instancias de base de datos. Al modificar los parámetros de los grupos de parámetros, comprenda la diferencia entre los parámetros estáticos y dinámicos y cómo y cuándo se aplican. Para ver la configuración aplicada actualmente, utilice la acción de la GetDbParameterGroupAPI.