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á.
Atenuar falhas
Ao planejar sua ElastiCache implementação na Amazon, você deve planejar de forma que as falhas tenham um impacto mínimo em seus aplicativos e dados. Os tópicos nesta seção discutem as abordagens que você pode tomar para proteger seu aplicativo e dados contra falhas.
Mitigando falhas ao executar o Redis OSS
Ao executar o mecanismo Redis OSS, você tem as seguintes opções para minimizar o impacto de uma falha no nó ou na zona de disponibilidade.
Mitigar falhas de nós
Os caches sem servidor mitigam automaticamente falhas em nó com uma arquitetura multi-AZ, de maneira que as falhas no nó sejam transparentes para a aplicação. Os clusters autoprojetados devem ser devidamente configurados para mitigar a falha de um nó individual.
Para mitigar o impacto das falhas dos nós do Redis OSS em clusters autoprojetados, você tem as seguintes opções:
Mitigando falhas: grupos de replicação do Redis OSS
Um grupo de replicação do Redis OSS é composto por um único nó primário do qual seu aplicativo pode ler e gravar, e de 1 a 5 nós de réplica somente para leitura. Sempre que os dados são gravados no nó primário, eles também são atualizados de maneira assíncrona nos nós de réplica de leitura.
Quando uma réplica de leitura falha
ElastiCache detecta a falha na réplica de leitura.
ElastiCache desativa o nó com falha.
ElastiCache lança e provisiona um nó de substituição na mesma AZ.
O novo nó é sincronizado com o nó primário.
Durante esse período, seu aplicativo pode continuar lendo e gravando usando os outros nós.
Redis OSS Multi-AZ
Você pode habilitar o Multi-AZ em seus grupos de replicação do Redis OSS. Independentemente de você habilitar o Multi-AZ, uma falha primária será detectada e substituída automaticamente. Como isso acontece depende de o recurso Multi-AZ estar ou não habilitado.
Quando Multi-AZ está habilitado
ElastiCache detecta a falha do nó primário.
ElastiCache promove o nó de réplica de leitura com o menor atraso de replicação em relação ao nó primário.
As outras réplicas se sincronizam com o novo nó primário.
ElastiCache ativa uma réplica de leitura no AZ do primário que falhou.
O novo nó é sincronizado com o primário recém-promovido.
O failover em um nó de réplica geralmente é mais rápido do que criar e provisionar um novo nó primário. Isso significa que seu aplicativo pode retomar a gravação no nó primário mais cedo do que se o Multi-AZ não estivesse habilitado.
Para ter mais informações, consulte Minimizando o tempo de inatividade no ElastiCache (Redis OSS) com o Multi-AZ.
Quando o Multi-AZ está desabilitado
ElastiCache detecta falha primária.
ElastiCache coloca o primário offline.
ElastiCache cria e provisiona um novo nó primário para substituir o primário que falhou.
ElastiCache sincroniza o novo primário com uma das réplicas existentes.
Quando a sincronização é concluída, o novo nó funciona como nó primário do cluster.
Durante as etapas de 1 a 4 desse processo, seu aplicativo não pode gravar no nó primário. No entanto, seu aplicativo pode continuar a ler dos seus nós de réplica.
Para proteção adicional, recomendamos que você inicie os nós no seu grupo de replicação em diferentes zonas de disponibilidade (AZs). Se você fizer isso, uma falha de AZ afetará apenas os nós nessa AZ, e não os outros.
Para ter mais informações, consulte Alta disponibilidade com o uso de grupos de replicação.
Mitigar falhas de zonas de disponibilidade
Os caches sem servidor mitigam automaticamente falhas em zona de disponibilidade com uma arquitetura multi-AZ replicada, de maneira que as falhas em AZ sejam transparentes para a aplicação.
Para mitigar o impacto de uma falha na zona de disponibilidade em um cluster autoprojetado, localize seus nós para cada fragmento no maior número possível de zonas de disponibilidade.
Não importa quantos nós você tenha em um fragmento, se todos estiverem localizados na mesma zona de disponibilidade, uma falha catastrófica dessa AZ resultará na perda de todos os dados do fragmento. No entanto, se você localizar seus nós em várias AZs, uma falha de qualquer AZ resultará apenas na perda dos nós nessa AZ.
Sempre que você perde um nó, pode passar por uma degradação do desempenho, pois as operações de leitura são compartilhadas por menos nós. Essa degradação do desempenho continuará até que os nós sejam substituídos.
Para obter informações sobre como especificar as zonas de disponibilidade para os nós do Redis OSS, consulte. Criação de um cluster Redis OSS (modo de cluster desativado) (console)
Para obter mais informações sobre regiões e zonas de disponibilidade, consulte Escolher regiões e zonas de disponibilidade.
Recomendações
É recomendável criar caches sem servidor em clusters autoprojetados, pois você obtém automaticamente uma melhor tolerância a falhas sem configuração adicional. No entanto, durante a criação de um cluster autoprojetado, existem dois tipos de falhas para as quais você precisa se planejar: falhas de nós individuais e falhas amplas de zona de disponibilidade. O melhor plano de mitigação de falhas abordará ambos os tipos de falhas.
Minimizar o impacto das falhas em nó
Para minimizar o impacto de uma falha de nó, nós recomendamos que sua implementação use vários nós em cada estilhaço e distribua esses nós em várias zonas de disponibilidade. Isso é feito automaticamente para caches sem servidor.
Para clusters autoprojetados, recomendamos que você habilite o Multi-AZ em seu grupo de replicação para que ele ElastiCache faça o failover automático para uma réplica se o nó primário falhar.
Minimizar o impacto das falhas na zona de disponibilidade
Para minimizar o impacto de uma falha na zona de disponibilidade, nós recomendamos a execução dos nós em quantas zonas de disponibilidade diferentes forem disponíveis. Espalhar nós de forma uniforme em AZs minimizará o impacto no evento improvável de uma falha de AZ. Isso é feito automaticamente para caches sem servidor.
Outras precauções
Se você estiver executando o Redis OSS, além do acima, recomendamos que você agende backups regulares do seu cluster. Backups (snapshots) criam um arquivo .rdb que você pode usar para restaurar seu cache em caso de falha ou corrupção. Para ter mais informações, consulte Snapshots e restauração.
