As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Pilar Confiabilidade
O pilar de confiabilidade engloba a capacidade de uma carga de trabalho realizar a função pretendida de forma correta e consistente, quando esperado. Isso inclui a capacidade de operar e testar a carga de trabalho durante todo o seu ciclo de vida.
A configuração de uma carga de trabalho confiável começa com decisões antecipadas de design para software e infraestrutura. Suas decisões de arquitetura afetarão o comportamento da workload em todos os pilares do Well-Architected. Para obter confiabilidade, você deve seguir padrões específicos.
O pilar de confiabilidade se concentra nas seguintes áreas principais:
-
Arquitetura de carga de trabalho, incluindo cotas de serviço e padrões de implantação
-
Gerenciando e escalando instâncias do InfluxDB
Arquitetura de carga de trabalho, incluindo cotas de serviço e padrões de implantação
Cada um Conta da AWS tem cotas para os recursos oferecidos em cada um Região da AWS. Por exemplo, cada região tem uma cota de Timestream para instâncias do InfluxDB, independentemente do tamanho da instância. Depois de atingir o número máximo de instâncias em uma região, as chamadas adicionais para criar instâncias falham com uma exceção. Um volume de armazenamento da instância Timestream for InfluxDB pode crescer até um tamanho máximo de 16 tebibytes () em todos os suportados. TiBs Regiões da AWS
Padrões de implantação
Para alta disponibilidade e suporte de failover para instâncias Timestream for InfluxDB, você pode usar implantações Multi-AZ com uma única instância de banco de dados em espera. Esse tipo de implantação é chamado de implantação de instância de banco de dados multi-AZ. O Amazon Timestream para InfluxDB usa a tecnologia de failover da Amazon. Em uma implantação de instância de banco de dados Multi-AZ, o Amazon Timestream provisiona e mantém automaticamente uma réplica síncrona em espera em uma zona de disponibilidade diferente. Para fornecer redundância de dados, a instância de banco de dados primária é replicada de forma síncrona entre as zonas de disponibilidade para a réplica em espera.
A execução de uma instância de banco de dados com alta disponibilidade pode fornecer disponibilidade durante falhas na instância de banco de dados ou interrupção da zona de disponibilidade. Se uma interrupção não planejada de sua instância de banco de dados resultar de um defeito na infraestrutura, o Amazon Timestream for InfluxDB mudará automaticamente para a réplica em espera. O tempo de conclusão do failover depende da atividade do banco de dados e de outras condições no momento em que a instância de banco de dados primária se tornou indisponível.
Em geral, os tempos de failover variam de 60 a 120 segundos. No entanto, grandes transações com dados de alta cardinalidade ou um longo processo de recuperação com requisitos de pré-aquecimento podem aumentar o tempo de failover. Após a conclusão do failover, talvez seja necessário mais tempo antes que o console do Timestream reflita a nova zona de disponibilidade.
Se seu aplicativo precisar permanecer disponível durante uma Região da AWS paralisação completa, considere configurar a replicação ou a gravação em uma região diferente como parte de seus planos de recuperação de desastres (DR). No entanto, antes de configurar a replicação, certifique-se de compreender as limitações. Para obter mais informações, consulte a documentação do InfluxDB
O Amazon Timestream for InfluxDB faz backups internos periodicamente e os retém por 24 horas para oferecer suporte à disponibilidade e durabilidade. Os instantâneos são tirados durante as exclusões e mantidos por 30 dias para apoiar as restaurações. Para acessá-los ou usá-los, crie um caso em AWS Support
Gerencie e escale o Timestream para o InfluxDB
O Timestream for InfluxDB suporta classes de instância que são ideais para executar cargas de trabalho com uso intenso de memória em bancos de dados InfluxDB de código aberto. As diferentes classes de instância db.influx têm limites em vCPUs, memória, armazenamento e largura de banda de rede. Para escolher a classe de instância que atende aos requisitos de latência de gravação e consulta do seu aplicativo, observe as DiskUtilization
métricas da Amazon CloudWatch CPUUtilization
e durante o teste. MemoryUtilization
Você pode escalar suas instâncias para cima e para baixo com base em seus requisitos de carga de trabalho. O Timestream for InfluxDB fornece vários níveis de armazenamento pré-configurados com IOPS e taxa de transferência ideais para diferentes tipos de cargas de trabalho. Escolha o que funciona melhor para sua carga de trabalho com base em seus requisitos.
Se suas necessidades de escalabilidade mudarem em horários previsíveis, você pode usar uma AWS Lambda função ou um agendador personalizado e executar uma API ou SDK para aumentar e diminuir a escala com algum tempo de buffer.
Você gerencia sua configuração do InfluxDB no Timestream for InfluxDB usando parâmetros em um grupo de parâmetros. Os grupos de parâmetros atuam como um contêiner para as opções de configuração do InfluxDB que são aplicadas a uma ou mais instâncias de banco de dados. Ao modificar parâmetros em grupos de parâmetros, entenda a diferença entre parâmetros estáticos e dinâmicos e como e quando eles são aplicados. Para ver a configuração aplicada atual, use a ação GetDbParameterGroupda API.