Nesta página, explicamos como o Memorystore para Redis Cluster realiza a manutenção dos clusters. Ele também fornece informações e recomendações de configuração que seus aplicativos clientes 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 for Redis Cluster atualiza os clusters regularmente 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 foi 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 precisa de 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 dos clusters além do que o Redis oferece.
Configurar o aplicativo cliente
Para configurar seu aplicativo cliente e ter o melhor desempenho e disponibilidade possíveis 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 evitam 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 reduzir escalonamento horizontal ou reduzir a escala, 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 existentes. Os testes ajudam a garantir que o cliente 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 Redis 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 da 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 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 do Memorystore na escala de serviço. Além disso, os tempos de espera são integrados ao cluster em várias 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 do usuário geral 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ó primário ou de réplica do Redis em um fragmento:
- O Memorystore for Redis Cluster primeiro 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 shard a ser atualizado for um nó principal, ele será primeiro 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 criar antes de destruir ajuda a manter a capacidade provisionada do cluster, em comparação com uma implantação rotativa 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 criando um fork de um processo filho e aproveitando a replicação sem disco para inicializar a réplica. O Memorystore para Redis Cluster é compatível com a replicação sem disco. A menos que você ative a persistência, o Memorystore para Redis Cluster 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 depois vai continuar 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 do cluster 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 dados em trânsito pendentes de liberação para 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. A remoção abrupta de um nó 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 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 atualize a topologia e conheça os novos endpoints de réplica. Se o cliente tentar acessar 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 do cluster 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 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 uma hora. Em alguns casos, a manutenção pode exceder a janela selecionada.
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ê tem a responsabilidade de supervisionar um ambiente de produção que inclui um cluster. Para garantir o desempenho ideal durante a manutenção, programe-a para quando o cluster tiver o mínimo de tráfego, o que normalmente 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 as próximas manutenções 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. A linha de 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 deste 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 estas etapas:
Para receber notificações de manutenção do Memorystore, verifique se você concluiu estas etapas pelo menos uma semana antes da atualização de manutenção programada para seu cluster. Caso contrário, o Memorystore for Redis Cluster não terá tempo suficiente para notificar você sobre a manutenção futura.
O Memorystore for Redis Cluster envia notificações para o endereço de e-mail associado à sua Conta do Google. Não é possível configurar um alias de e-mail personalizado (por exemplo, um alias de e-mail de equipe). 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ê recebe alertas de todos os clusters do Memorystore com manutenção programada em um projeto especificado. 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 o cluster, esta seção fornece diretrizes sobre como reagendar a manutenção. Por exemplo, se um novo serviço for lançado durante a janela de manutenção atual, talvez seja melhor adiar a janela de manutenção 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 reprogramá-la.
- 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.
Para instruções sobre como reprogramar a manutenção, consulte Reprogramar a manutenção.
Perguntas frequentes
Esta seção contém perguntas frequentes sobre a manutenção do Memorystore para Redis Cluster.
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 o cluster manualmente para saber 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 seu 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 for 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. O 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 a manutenção ou programar a manutenção em determinados clusters primeiro?
Não é possível desativar a manutenção nem controlar a ordem dela para seus clusters. No entanto, depois de receber a notificação inicial, você pode 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.