Pilier de fiabilité

Le pilier de fiabilité englobe la capacité d'une charge de travail à exécuter correctement et de manière cohérente la fonction prévue lorsqu'elle est censée le faire. Cela inclut la capacité d'exploiter et de tester la charge de travail tout au long de son cycle de vie.

La configuration d'une charge de travail fiable commence par des décisions de conception initiales pour le logiciel et l'infrastructure. Vos choix d’architecture ont un impact sur le comportement des charges de travail sur les différents piliers Well-Architected. Pour atteindre la fiabilité, vous devez suivre des modèles spécifiques.

Le pilier de fiabilité se concentre sur les domaines clés suivants :

• Architecture de charge de travail, y compris les quotas de service et les modèles de déploiement

• Gestion et dimensionnement des instances InfluxDB

Architecture de charge de travail, y compris les quotas de service et les modèles de déploiement

Chacun Compte AWS dispose de quotas pour les ressources qu'il propose Région AWS. Par exemple, chaque région dispose d'un quota de diffusion temporelle pour les instances InfluxDB, quelle que soit la taille de l'instance. Une fois que vous avez atteint le nombre maximum d'instances dans une région, les appels supplémentaires pour créer des instances échouent, à une exception près. Un volume de stockage d'instance Timestream pour InfluxDB peut atteindre une taille maximale de 16 tebioctets () dans tous les cas pris en charge. TiBs Régions AWS

Modèles de déploiement

Pour une haute disponibilité et une prise en charge du basculement pour Timestream pour les instances InfluxDB, vous pouvez utiliser des déploiements multi-AZ avec une seule instance de base de données de secours. Ce type de déploiement est appelé déploiement d'instance de base de données multi-AZ. Amazon Timestream pour InfluxDB utilise la technologie de basculement Amazon. Dans le cadre d'un déploiement d'instance de base de données multi-AZ, Amazon Timestream approvisionne et gère automatiquement une réplique de secours synchrone dans une autre zone de disponibilité. Pour assurer la redondance des données, l'instance de base de données principale est répliquée de manière synchrone entre les zones de disponibilité vers la réplique de secours.

L'exécution d'une instance de base de données à haute disponibilité peut garantir la disponibilité en cas de défaillance de l'instance de base de données ou d'interruption de la zone de disponibilité. Si une panne imprévue de votre instance de base de données résulte d'un défaut d'infrastructure, Amazon Timestream for InfluxDB passe automatiquement à la réplique de secours. La durée du basculement dépend de l'activité de la base de données et d'autres conditions au moment où l'instance de base de données primaire est devenue indisponible.

Les durées de basculement oscillent généralement entre 60 et 120 secondes. Toutefois, des transactions importantes comportant des données à cardinalité élevée ou un long processus de restauration nécessitant un préchauffage peuvent augmenter le temps de basculement. Une fois le basculement terminé, un délai supplémentaire peut être nécessaire avant que la console Timestream reflète la nouvelle zone de disponibilité.

Si votre application doit rester disponible pendant une Région AWS panne complète, envisagez de configurer la réplication ou d'écrire dans une autre région dans le cadre de vos plans de reprise après sinistre (DR). Toutefois, avant de configurer la réplication, assurez-vous d'en connaître les limites. Pour plus d'informations, consultez la documentation InfluxDB.

Amazon Timestream for InfluxDB effectue régulièrement des sauvegardes internes et les conserve pendant 24 heures pour garantir la disponibilité et la durabilité. Les instantanés sont pris lors des suppressions et conservés pendant 30 jours pour permettre les restaurations. Pour y accéder ou les utiliser, créez un dossier sur AWS Support.

Gérez et dimensionnez Timestream pour InfluxDB

Timestream for InfluxDB prend en charge les classes d'instance idéales pour exécuter des charges de travail gourmandes en mémoire dans des bases de données InfluxDB open source. Les différentes classes d'instances db.influx ont des limites en termes de vCPUs, de mémoire, de stockage et de bande passante réseau. Pour choisir la classe d'instance qui répond aux exigences de latence d'écriture et de requête de votre application, observez les DiskUtilization indicateurs Amazon CloudWatch CPUUtilization etMemoryUtilization, lors des tests. Vous pouvez redimensionner vos instances à la hausse ou à la baisse en fonction de vos exigences en matière de charge de travail. Timestream for InfluxDB fournit plusieurs niveaux de stockage préconfigurés avec des IOPS et un débit optimaux requis pour différents types de charges de travail. Choisissez ce qui convient le mieux à votre charge de travail en fonction de vos besoins.

Si vos besoins de dimensionnement changent à des moments prévisibles, vous pouvez utiliser une AWS Lambda fonction ou un planificateur personnalisé et exécuter une API ou un SDK pour augmenter ou diminuer le dimensionnement avec un certain temps tampon.

Vous gérez votre configuration InfluxDB dans Timestream pour InfluxDB en utilisant des paramètres dans un groupe de paramètres. Les groupes de paramètres agissent comme un conteneur pour les options de configuration InfluxDB qui sont appliquées à une ou plusieurs instances de base de données. Lorsque vous modifiez des paramètres dans des groupes de paramètres, comprenez la différence entre les paramètres statiques et dynamiques, et apprenez comment et quand ils sont appliqués. Pour voir la configuration actuellement appliquée, utilisez l'action GetDbParameterGroupAPI.