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 para 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 foi projetada para não ter impacto no tempo 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 do 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 evitam redefinições de conexão com atualizações periódicas de 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 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 impactos negativos no aplicativo.
Manutenção programada
O Memorystore for Redis Cluster usa uma estratégia de ciclo de vida de implantação gradual e criação antes da destruição para evitar qualquer impacto de inatividade causado pela manutenção. A manutenção sem tempo de inatividade é realizada usando os recursos de redirecionamento de solicitações do protocolo de cluster do Redis OSS 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 de 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 de serviço. Além disso, os tempos de espera são integrados ao 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 do usuário a qualquer momento maximiza a disponibilidade de dados.
Estratégia de ciclo de vida "create-before-destroy"
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ó do Redis principal ou de réplica 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 uma 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 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 shards 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 shard.
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 OSS Redis de sincronização completa 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.
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 de 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 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 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 ultrapassar a janela selecionada.
Depois que uma janela de manutenção é configurada para uma instância de cluster, as manutenções automáticas futuras são programadas de acordo com as preferências definidas para as 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 gerenciando 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 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. 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 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 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 quantas vezes quiser em até duas semanas após o horário originalmente programado. Ao reagendar, você pode escolher uma das seguintes opções:
- Atualize agora. Em vez de esperar a janela de manutenção programada, é possível aplicar as atualizações ao cluster imediatamente.
- Dia e hora personalizados. Isso permite que você escolha qualquer horário específico em até duas semanas do horário de manutenção programado originalmente.
Ao reprogramar a manutenção, as seguintes restrições são aplicadas:
- Se faltar menos de uma hora para o horário programado da 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
Confira abaixo algumas perguntas frequentes sobre a política de manutenção do cluster do Memorystore para Redis:
Como saber quando a manutenção está programada para meu cluster?
Recomendamos que você se inscreva nas notificações e configure uma janela de manutenção para saber quando a manutenção está programada para sua instância. Também é possível verificar manualmente usando Encontrar manutenção programada para saber se o campo maintenance_schedule está definido na resposta.
Quando recebo uma notificação sobre as próximas manutenções?
Se você tiver uma assinatura de notificações de manutenção e tiver definido uma janela de manutenção, receberá um alerta por e-mail pelo menos uma semana antes de um evento.
Por quanto tempo posso adiar a manutenção?
Depois que a manutenção for programada para o cluster, inicie a atualização da instância imediatamente ou adie a atualização por até duas semanas a partir do horário de manutenção programado originalmente. Por exemplo, se a manutenção estiver programada para 11 de outubro às 23h15, será possível adiar até 25 de outubro às 23h15. A manutenção será aplicada no horário programado se nenhuma ação for realizada.
Para mais detalhes, consulte Como reprogramar a manutenção.
Quais práticas recomendadas devo seguir para ter uma experiência de atualização de manutenção tranquila?
Recomendamos que você faça o seguinte para garantir uma experiência de atualização de manutenção tranquila:
- Siga as instruções para configurar o aplicativo cliente.
- Defina sua janela de manutenção como um horário para que a manutenção não seja aplicada nos horários de pico do uso do Redis.
- É necessário ativar as notificações de manutenção por e-mail para receber um alerta pelo menos sete dias antes de uma atualização de manutenção ser programada para sua instância.
- Se você não tiver um horário de baixo ou nenhum impacto para o uso do aplicativo, recomendamos usar o padrão de serviço dos lançamentos graduais, que tem práticas recomendadas integradas. Para mais informações, consulte Manutenção programada.
Quando devo aplicar a manutenção imediatamente?
Um cenário em que você pode aplicar a atualização de manutenção imediatamente é em um cluster de teste para ver como ela afeta seu aplicativo. Assim, você pode observar o impacto que ela tem e adiar a manutenção em clusters de produção conforme necessário/permitido.
Você também pode agendar a manutenção imediatamente se o horário atual for adequado para seu cluster e você esperar uma carga alta no futuro.
As atualizações de manutenção sempre são concluídas dentro da janela de manutenção?
Uma atualização começa dentro da janela de manutenção especificada. A atualização geralmente é concluída dentro da janela, mas isso não é garantido.
Posso desativar a manutenção ou programar a manutenção em determinados clusters primeiro?
Não, não é possível desativar a manutenção nem controlar a ordem dela nos clusters. No entanto, depois de receber a notificação inicial de manutenção, é 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 do Redis.