Nesta página, explicamos como o Memorystore for Redis Cluster realiza a manutenção em clusters. 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 inatividade do Memorystore for Redis Cluster. Essas recomendações se aplicam a clusters de alta disponibilidade e 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 de forma rotineira 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, o Memorystore requer uma atualização de manutenção.
- Patches do sistema operacional. Monitoramos continuamente as vulnerabilidades de segurança recém-identificadas no sistema operacional. Após a descoberta, corrigimos o 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 as características de segurança, desempenho e confiabilidade dos clusters além do que o Redis oferece.
O Memorystore for Redis Cluster não atualiza automaticamente os clusters para cada versão de manutenção. Para determinar o melhor momento para programar uma manutenção abrangente, o Google Cloud avalia periodicamente as atualizações disponíveis. Se você precisar de uma versão de manutenção específica antes, use a manutenção de autoatendimento depois que uma atualização estiver disponível. Para mais informações sobre as versões de manutenção, incluindo os números e detalhes, consulte os registros de alterações de manutenção do Memorystore for Redis Cluster.
Configurar o aplicativo cliente
Para configurar o aplicativo cliente para o melhor desempenho e disponibilidade possíveis durante a manutenção, siga estas etapas:
- Use e configure o cliente do cluster do OSS Redis de acordo com as orientações em Práticas recomendadas para clientes do Redis para garantir que as manutenções programadas não afetem o aplicativo cliente. Nossas configurações de cliente recomendadas podem evitar 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 escalonamento horizontal, alterações 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 de topologia inline nos 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 inatividade é alcançada usando os recursos de redirecionamento de solicitação do protocolo Redis com os seguintes mecanismos do Memorystore:
- Failover coordenado sem perda de dados.
- Remoção de nós de forma otimizada para permitir que os clientes acompanhem as atualizações da topologia do cluster sem impacto na 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 um escopo que aumenta progressivamente 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 aplicação (tempo durante o qual a atualização é aplicada e monitorada antes de ser considerada um sucesso e prosseguir) são integrados em toda a frota de clusters do Memorystore na escala do serviço. Além disso, os tempos de bake 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/zona de falha é atualizado a qualquer momento para garantir que um fragmento de cluster, incluindo o primário e as réplicas, tenha alta disponibilidade durante a atualização. Além disso, apenas alguns nós do Redis são atualizados em um determinado momento. 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 keyspace geral do usuário em um determinado 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:
- 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ó atual, para garantir que a capacidade provisionada seja mantida no caso de uma falha inesperada de inicialização.
- Se um nó dentro do fragmento a ser atualizado for um nó primário, 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 criar antes de destruir ajuda a reter a capacidade provisionada do cluster, em comparação com uma implantação gradual típica que é atualizada 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 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 OSS Redis para copiar os dados do nó principal para o nó de réplica. Isso é feito bifurcando um processo filho e aproveitando a replicação sem disco para inicializar a réplica. O Memorystore for Redis Cluster é compatível com a replicação sem disco. A menos que você ative a persistência, o Memorystore for Redis Cluster não usa discos durante a replicação.
Para aproveitar melhor a arquitetura de escalonamento horizontal do cluster, provisione um número maior de fragmentos para reduzir o tamanho do keyspace em um nó. Ter um conjunto de dados menor por nó ajuda a reduzir o impacto da latência de bifurcação de uma operação de sincronização completa. Ele também acelera a cópia de dados entre os nós.
Etapa 2: failover primário coordenado
Se o nó do Redis que precisa ser atualizado for um nó principal, o Memorystore primeiro executará um failover coordenado para o nó de réplica recém-adicionado e, em seguida, 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 inatividade do aplicativo:
- As solicitações de entrada do cliente são bloqueadas temporariamente no nó principal, fornecendo 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 o papel principal.
- O nó primário anterior, que agora é uma réplica, desbloqueia as solicitações atuais e as redireciona para o primário recém-eleito usando o protocolo de cluster do OSS Redis. 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 requer mais redirecionamentos.
Os failovers coordenados geralmente levam dezenas de milissegundos. No entanto, o tamanho total do cluster pode aumentar a latência de failover. Assim como os dados em trânsito pendentes de envio para as réplicas. O tamanho do cluster pode afetar a convergência entre os nós primários, o que afeta a tomada de decisões sobre a escolha do novo nó primário.
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 afetaria os 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 suave, 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 de ser removida.
O nó de réplica que executa o software anterior é mantido por um determinado período de drenagem, normalmente em minutos, durante o qual ele começa a redirecionar as solicitações de leitura recebidas para o nó principal do fragmento. Ele permite que o cliente do cluster atualize a topologia do cluster e aprenda sobre 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 vai acionar uma atualização da topologia do cluster no cliente do cluster para que ele saiba sobre a mudança de réplica. As novas atualizações da topologia do cluster não veem o nó de réplica que será removido.
Configurações de manutenção
Com o Memorystore, é possível personalizar as programações 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 1 hora. Em alguns casos, a manutenção pode ultrapassar a janela selecionada.
Depois que você configura uma janela de manutenção para um cluster, o Memorystore for Redis Cluster programa a manutenção automática no futuro de acordo com as preferências que você definiu 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). Das 22h às 6h
Janela de fim de semana. De sexta-feira, às 22h, até 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 um cluster. Para garantir o desempenho ideal durante a manutenção, você quer programá-la para quando o cluster tiver o mínimo de tráfego, o que geralmente ocorre por volta da meia-noite aos domingos.
Nesse caso, é possível definir 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 cluster, configure notificações por e-mail sobre as próximas manutenções com pelo menos uma semana de antecedência. 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 do cluster começa. O
assunto do e-mail será "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
notificando sobre o cancelamento. O assunto desse e-mail
seria "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]".
Você precisa ativar as notificações de manutenção para recebê-las. Para se inscrever nas notificações de manutenção, siga estas etapas:
Para receber notificações de manutenção do Memorystore, conclua estas etapas pelo menos uma semana antes da atualização de manutenção programada para o cluster. Se você não fizer isso, 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 para receber notificações de manutenção, você recebe alertas para todos os clusters do Memorystore com manutenção programada em um projeto especificado. Se você se inscrever, vai receber uma notificação separada para cada cluster.
Para instruções sobre como encontrar manutenções programadas, consulte Encontrar manutenções programadas.
Como reprogramar uma manutenção
No cenário em que as janelas de manutenção são configuradas para o cluster, esta seção fornece diretrizes sobre como reprogramar 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 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 da reprogramação da manutenção, escolha uma das seguintes opções:
- Atualizar agora: em vez de esperar pela 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 se aplicam:
- Se faltar menos de uma hora para o horário de manutenção programado, não será possível reprogramar a manutenção.
- Após a reprogramação, um e-mail é enviado confirmando o cancelamento da manutenção anterior, e uma nova notificação de manutenção futura é enviada com a programação atualizada.
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 for Redis Cluster.
Como saber quando a manutenção está programada para o cluster?
Para saber quando a manutenção está programada para o cluster, recomendamos que você
se inscreva para receber notificações e configure uma janela de manutenção. Também é possível
verificar o cluster manualmente para conferir se o
parâmetro maintenanceSchedule aparece na resposta.
Quando o Memorystore for Redis Cluster notifica você 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 é possível 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 originalmente programadas.
Por exemplo, se você programar a manutenção para 11 de outubro às 23h15, poderá adiá-la 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 manutenção.
Quais práticas recomendadas resultam em uma experiência tranquila de atualização de manutenção?
Para garantir uma experiência de atualização de manutenção tranquila, recomendamos que você faça o seguinte:
- Siga as instruções para configurar o aplicativo cliente.
- Defina a 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 envia uma notificação por e-mail pelo menos sete dias antes de uma atualização de manutenção programada para o 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 o aplicativo. É possível 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 o horário atuais forem adequados para o cluster e você espera 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 de manutenção especificada. O Memorystore for Redis Cluster geralmente conclui a atualização dentro da janela, mas nem sempre é assim.
É possível desativar a manutenção ou programá-la primeiro em determinados clusters?
Não é possível desativar a manutenção ou controlar a ordem de manutenção dos clusters. No entanto, depois de receber a notificação de manutenção inicial, é possível reprogramar a manutenção para adiá-la por até duas semanas.
A seguir
- Confira as permissões necessárias para gerenciar as janelas de manutenção do cluster.