Nesta página, explicamos como o cluster do Memorystore para Redis realiza a manutenção das instâncias. Ele também fornece informações e recomendações de configuração que seus aplicativos cliente precisam conhecer para aproveitar o design de manutenção sem tempo de inatividade do Memorystore for Redis Cluster. Essas recomendações se aplicam a clusters altamente disponíveis e a clusters sem réplicas. No entanto, recomendamos a configuração de alta disponibilidade para todos os casos de uso de produção.
O Memorystore para Redis Cluster atualiza rotineiramente as instâncias para garantir que o serviço seja confiável, eficiente, seguro e atualizado. Essas atualizações são chamadas de manutenção. A manutenção é totalmente gerenciada pelo serviço e projetada para não ter impacto de inatividade.
A manutenção geralmente se enquadra nas seguintes categorias:
- Recursos do Memorystore. Para lançar alguns recursos, a Memorystore exige uma atualização de manutenção.
- Patches do sistema operacional. Estamos sempre monitorando vulnerabilidades de segurança recém-identificadas no sistema operacional. Após a descoberta, aplicamos um patch ao sistema operacional para proteger você contra novos riscos.
- Patches de banco de dados. A manutenção pode incluir uma atualização do Redis para melhorar a segurança, o desempenho e as características de confiabilidade da instância além do que o OSS Redis oferece.
Configurar o aplicativo cliente
Para configurar o aplicativo cliente e ter o melhor desempenho e disponibilidade possível durante a manutenção, siga estas etapas:
- Use e configure o cliente do cluster Redis OSS de acordo com as orientações em Práticas recomendadas para clientes do Redis para garantir que nenhuma manutenção programada afete seu aplicativo cliente. As configurações de cliente recomendadas podem evitar redefinições de conexão com atualizações periódicas da topologia inline e rotações de conexão em segundo plano.
- Teste o aplicativo cliente com uma série de operações de atualização (como escalonamento vertical ou horizontal, mudanças na contagem de réplicas) enquanto executa uma carga de trabalho representativa nos nós primários e de réplica e monitora o impacto no cliente. Essas atualizações testam a lógica de atualização da topologia inline em clientes, o impacto da sincronização completa, a descoberta de novos nós e a capacidade de remoção de nós atuais. Os testes ajudam a garantir que o cliente do cluster Redis OSS esteja configurado corretamente para evitar qualquer impacto negativo no aplicativo.
Manutenção programada
O Memorystore for Redis Cluster usa uma estratégia de ciclo de vida de implantação gradual e criar antes de destruir para evitar qualquer impacto de inatividade causada pela manutenção. A manutenção sem tempo de inatividade é realizada usando os recursos de redirecionamento de solicitações do protocolo de cluster do OSS Redis em conjunto com os seguintes mecanismos do Memorystore:
- Failover coordenado sem perda de dados.
- Remoção gradual de nós para permitir que os clientes acompanhem as atualizações de topologia do cluster sem afetar a disponibilidade.
- Os endpoints do Private Service Connect do cluster não são afetados pela manutenção. Para mais informações sobre esses endpoints, consulte Endpoints do cluster.
O comportamento do serviço descrito nas seções a seguir se aplica apenas à manutenção programada. Para informações sobre o impacto de eventos não planejados, como falhas de hardware, consulte Comportamento do cliente durante um failover não planejado.
Estratégia de implantação gradual
As implantações de manutenção do Memorystore for Redis Cluster são realizadas com escopo progressivamente crescente e em uma taxa que permite a detecção de falhas com antecedência suficiente para mitigar o impacto e estabelecer a confiança na estabilidade. Os tempos de espera (período em que a atualização é aplicada e monitorada antes de ser considerada um sucesso e seguir em frente) são integrados em toda a frota de clusters da Memorystore na escala do serviço. Além disso, os tempos de espera são integrados no cluster em todas as zonas de uma região (vários domínios de falha) para reduzir o escopo do impacto, se houver.
Para o cluster configurado para alta disponibilidade, no máximo um domínio de falha/zona é atualizado por vez para garantir que um fragmento de cluster, incluindo primário e réplicas, tenha alta disponibilidade durante toda a atualização. Além disso, apenas alguns nós do Redis são atualizados por vez. As atualizações usam um mecanismo de ciclo de vida de criação antes da destruição para maximizar a estabilidade do cluster. Essa estratégia oferece mais benefícios ao atualizar um cluster com muitos fragmentos. Aplicar as atualizações apenas a uma pequena parte do espaço de chaves geral do usuário a qualquer momento maximiza a disponibilidade de dados.
Estratégia de ciclo de vida de criar antes de destruir
Um cluster do Redis tem vários fragmentos. Cada fragmento tem um nó principal e zero ou mais nós de réplica. O Memorystore usa o seguinte processo para atualizar qualquer nó principal ou de réplica do Redis em um fragmento:
- Primeiro, o Memorystore for Redis Cluster adiciona uma réplica completamente nova com a atualização de software mais recente ao fragmento. O Memorystore cria um nó totalmente novo, em vez de atualizar um nó existente, para garantir que a capacidade provisionada seja mantida em caso de falha inesperada de bootstrap.
- Se um nó no fragmento a ser atualizado for um nó principal, ele será convertido em uma réplica antes da remoção usando um failover coordenado.
- Em seguida, o Memorystore remove a réplica que usa o software anterior.
- O processo é repetido para cada nó no cluster.
A estratégia de criação antes da destruição ajuda a manter a capacidade provisionada do cluster, em comparação com uma implantação gradual típica, que atualiza no local, mas resulta em uma interrupção de disponibilidade (e às vezes perda de dados) para o aplicativo cliente. Para fragmentos sem réplicas, o Memorystore for Redis Cluster ainda provisiona uma nova réplica primeiro, coordena o failover e, por fim, substitui o nó principal atual do fragmento.
Etapa 1: adicionar uma réplica do Redis
A primeira etapa do mecanismo de criação antes da destruição é adicionar um nó de réplica com o software mais recente usando o mecanismo de sincronização completa do Redis OSS para copiar os dados do nó principal para o de réplica. Isso é feito ramificando um processo filho e aproveitando a replicação sem disco para inicializar a réplica. O cluster do Memorystore para Redis é compatível com a replicação sem disco. A menos que você ative a persistência, o cluster do Memorystore para Redis não usa discos durante a replicação.
Para aproveitar ao máximo a arquitetura de escalonamento horizontal do cluster, provisione um número maior de fragmentos para reduzir o tamanho do espaço de chaves em um nó. Ter um conjunto de dados menor por nó ajuda a reduzir o impacto da latência de fork de uma operação de sincronização completa. Ele também acelera a cópia de dados entre os nós.
Etapa 2: failover principal coordenado
Se o nó do Redis que precisa ser atualizado for um nó principal, o Memorystore primeiro vai executar um failover coordenado para o nó de réplica recém-adicionado e, em seguida, vai prosseguir com a remoção do nó. Durante o failover coordenado, o cliente e os nós do Redis trabalham juntos e usam as seguintes estratégias para evitar o tempo de inatividade do aplicativo:
- As solicitações de clientes recebidas são bloqueadas temporariamente no nó principal, oferecendo uma janela para garantir que a réplica atual esteja 100% sincronizada com o principal.
- A réplica conclui o processo de eleição para assumir a função principal.
- O nó primário anterior, agora uma réplica, desbloqueia as solicitações atuais e as redireciona para o novo primário usando o protocolo de cluster do Redis OSS. Todas as novas solicitações enviadas ao nó de réplica anterior continuam sendo redirecionadas para o novo nó principal.
- O cliente compatível com o cluster do Redis atualiza a topologia na memória. Ele aprende o endereço do novo endpoint principal e não exige mais redirecionamentos.
Os failovers coordenados geralmente levam dezenas de milissegundos. No entanto, o tamanho total do cluster pode aumentar a latência de failover. O mesmo vale para os dados em trânsito pendentes de serem liberados para as réplicas. O tamanho do cluster pode afetar a convergência entre os nós principais, o que afeta a tomada de decisões sobre a eleição do novo principal.
Etapa 3: remover a réplica do Redis
A última etapa do mecanismo de criação antes da destruição é remover o nó de réplica no software anterior. Uma remoção abrupta de nós teria um impacto nos aplicativos clientes, porque eles armazenam em cache as informações do endpoint e a topologia do cluster. O Memorystore for Redis Cluster foi projetado para remover uma réplica do Redis de maneira gradual, permitindo que os aplicativos cliente atualizem a topologia antes de sofrer um desligamento forçado do nó. A topologia é personalizada para permitir que os clientes conheçam a nova réplica. A topologia também esquece a réplica que será removida antes da remoção.
O nó de réplica que executa o software anterior é mantido por um determinado período de drenagem, geralmente da ordem de minutos, durante o qual ele começa a redirecionar as solicitações de leitura recebidas para o nó principal do shard. Ele permite que o cliente do cluster Redis OSS atualize a topologia do cluster e conheça os novos endpoints de réplica. Se o cliente tentar alcançar um nó removido após o período de drenagem, a tentativa vai falhar, o que aciona uma atualização da topologia do cluster no cliente para que ele saiba sobre a mudança de réplica. Novas atualizações da topologia do cluster não mostram o nó de réplica que será removido.
Configurações de manutenção
Com o Memorystore, é possível personalizar os cronogramas de manutenção para se alinhar às necessidades do seu aplicativo e minimizar as interrupções. Para isso, configure uma janela de manutenção para o cluster.
As janelas de manutenção são definidas por cluster do Memorystore e permitem as seguintes opções de configuração:
- Dia da semana. Designa o dia em que a manutenção ocorre.
- Hora de início. A hora em que a manutenção começa.
A duração da janela de manutenção é de 1 hora. Em alguns casos, a manutenção pode ultrapassar o período selecionado.
Depois de configurar uma janela de manutenção para um cluster, o Memorystore para Redis Cluster agenda a manutenção automática no futuro de acordo com as preferências definidas para janelas de manutenção.
Janelas de manutenção padrão
Se você não definir uma janela de manutenção, o Memorystore vai atualizar o cluster em uma das seguintes janelas de tempo de acordo com o fuso horário do cluster:
Período da semana (de segunda a sexta-feira). 22h às 6h
Período do fim de semana. Sexta-feira, das 22h à segunda-feira, às 6h
Exemplo de manutenção
Como desenvolvedor que gerencia um serviço de carrinho de compras em um varejista, você é responsável por supervisionar um ambiente de produção que inclui uma instância do cluster do Memorystore para Redis. Para garantir a performance ideal durante a manutenção, programe-a para quando o cluster tiver o mínimo de tráfego, o que geralmente acontece por volta da meia-noite aos domingos.
Nesse caso, defina a janela de manutenção do cluster de produção como:
- Dia da semana. Domingo.
- Hora de início. 1h.
Notificações de manutenções futuras
Para ficar por dentro dos eventos de manutenção no seu cluster, configure notificações por e-mail sobre a manutenção futura pelo menos uma semana antes da data programada. Essas notificações terão a linha de assunto "Upcoming maintenance for your Cloud Memorystore instance [your-cluster-name]".
Uma notificação também é enviada quando a manutenção começa no cluster. O assunto do e-mail seria "Maintenance
is undergoing for your Cloud Memorystore instance [your-cluster-name]".
Quando a manutenção é concluída, uma notificação é enviada. O título do e-mail é "Completed Maintenance
for your Cloud Memorystore instance [your-cluster-name]".
Se o Memorystore reprogramar a manutenção, você vai receber um e-mail informando sobre o cancelamento. A linha de assunto desse e-mail seria "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]".
Você precisa ativar o recebimento dessas notificações de manutenção. Para se inscrever nas notificações de manutenção, siga as etapas abaixo:
Para receber notificações de manutenção do Memorystore, siga as etapas acima pelo menos uma semana antes da atualização de manutenção programada para sua instância. Caso contrário, o sistema não terá tempo suficiente para notificar você sobre a manutenção.
As notificações serão enviadas para o endereço de e-mail associado à sua Conta do Google. Não é possível configurar um alias de e-mail personalizado (um alias de e-mail de equipe, por exemplo). No momento, não é possível enviar notificações para um endereço de e-mail diferente.
Ao se inscrever nas notificações de manutenção, você vai receber alertas de todos os clusters do Memorystore com manutenção programada em um projeto específico. Se você tiver uma assinatura, vai receber uma notificação separada para cada cluster.
Para instruções sobre como encontrar a manutenção programada, consulte Encontrar a manutenção programada.
Como reprogramar uma manutenção
No cenário em que as janelas de manutenção estão configuradas para seu cluster, esta seção fornece diretrizes sobre como reagendar a manutenção. Por exemplo, se um novo serviço estiver programado para ser lançado durante a janela de manutenção atual, talvez seja melhor adiar a janela para alguns dias após o lançamento.
É possível reprogramar a manutenção em até 14 dias após o horário programado originalmente. Como parte do reagendamento da manutenção, escolha uma das seguintes opções:
- Atualizar agora: em vez de esperar a janela de manutenção programada, é possível aplicar as atualizações ao cluster imediatamente.
- Dia e horário personalizados: escolha qualquer horário em até 14 dias após o horário de manutenção programado originalmente.
Ao reprogramar a manutenção, as seguintes restrições são aplicadas:
- Se houver menos de uma hora antes do horário programado para a manutenção, não será possível reprogramar.
- Após o reagendamento, um e-mail é enviado confirmando o cancelamento da manutenção anterior, e uma nova notificação de manutenção futura é enviada com o cronograma atualizado.
Veja instruções sobre como reprogramar a manutenção em Reprogramar a manutenção.
Perguntas frequentes
Esta seção contém perguntas frequentes sobre a manutenção do cluster do Memorystore para Redis.
Como saber quando a manutenção está programada para seu cluster?
Para saber quando a manutenção está programada para seu cluster, recomendamos que você
se inscreva nas notificações e configure uma janela de manutenção. Você também pode verificar seu cluster manualmente para conferir se o parâmetro maintenanceSchedule aparece na resposta.
Quando o Memorystore for Redis Cluster notifica sobre as próximas manutenções?
Se você se inscrever para receber notificações de manutenção e definir uma janela de manutenção, o Memorystore for Redis Cluster vai enviar uma notificação por e-mail pelo menos uma semana antes de um evento de manutenção.
Por quanto tempo posso adiar a manutenção?
Depois de programar a manutenção do cluster, você pode iniciar a atualização imediatamente ou adiá-la por até duas semanas a partir da data e hora de manutenção programadas originalmente.
Por exemplo, se você programar a manutenção para 11 de outubro às 23h15, será possível adiar até 25 de outubro às 23h15. Se você não fizer nada, a manutenção será executada na data e hora programadas.
Para mais informações, consulte Reprogramar a manutenção.
Quais práticas recomendadas resultam em uma experiência de atualização de manutenção tranquila?
Para garantir uma experiência de atualização de manutenção sem problemas, recomendamos que você faça o seguinte:
- Siga as instruções para configurar o aplicativo cliente.
- Defina uma janela de manutenção para um dia e horário em que o cluster tenha o mínimo de tráfego (por exemplo, domingos à meia-noite).
- Ative as notificações de manutenção. Como resultado, o Memorystore para Redis Cluster notifica você por e-mail pelo menos sete dias antes de uma atualização de manutenção ser programada para seu cluster.
- Se você não tiver um horário de baixo ou nenhum impacto para o uso do aplicativo, use o padrão de serviço dos lançamentos graduais. Esse padrão contém práticas recomendadas para atualizações de manutenção. Para mais informações, consulte Manutenção programada.
Quando recomendamos que você aplique uma atualização de manutenção imediatamente?
É possível aplicar uma atualização de manutenção imediatamente em um cluster de teste para ver como ela afeta seu aplicativo. Você pode observar o impacto dessa atualização. Se houver problemas com a atualização, adie a manutenção nos clusters de produção até que eles sejam resolvidos.
Se o dia e a hora atuais forem adequados para seu cluster e você esperar uma carga alta no futuro, execute a atualização de manutenção imediatamente.
As atualizações de manutenção sempre são concluídas dentro da janela de manutenção?
O Memorystore for Redis Cluster inicia uma atualização de manutenção dentro da janela especificada. O cluster do Memorystore para Redis geralmente conclui a atualização dentro da janela, mas isso nem sempre acontece.
É possível desativar ou programar a manutenção em determinados clusters primeiro?
Não é possível desativar a manutenção nem controlar a ordem dela nos seus clusters. No entanto, depois de receber a notificação inicial, é possível reprogramar a manutenção para adiar por até duas semanas.
A seguir
- Confira as permissões necessárias para gerenciar janelas de manutenção do cluster.