Nesta página, explicamos como o Memorystore for Redis Cluster realiza a manutenção em instâncias. Também fornecemos 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 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 as instâncias rotineiramente 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 normalmente se enquadra nas seguintes categorias:
- Recursos do Memorystore. Para lançar alguns recursos, o 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, a performance 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 para a melhor performance e disponibilidade possível durante a manutenção, siga estas etapas:
- Use e configure o cliente de cluster do OSS Redis de acordo com as orientações em Práticas recomendadas do cliente Redis para garantir que qualquer manutenção programada não afete o aplicativo cliente. Nossas configurações de cliente recomendadas podem evitar redefinições de conexão por meio de 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) ao executar uma carga de trabalho representativa em nós primários e de réplica e monitorar o impacto do cliente. Essas atualizações testam a lógica de atualização de 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. O teste ajuda a garantir que o cliente de cluster do OSS Redis 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 é alcançada 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 normal do nó para permitir que os clientes acompanhem as atualizações da topologia do cluster sem qualquer 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 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 preparação (período durante o qual a atualização é aplicada e monitorada antes de ser considerada um sucesso e avançar) são integrados em toda a frota de clusters do Memorystore na escala de serviço. Além disso, os tempos de preparação 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 shard de cluster, incluindo o principal e as 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 criar antes de destruir para maximizar a estabilidade do cluster. Essa estratégia oferece mais benefícios ao atualizar um cluster com muitos shards. A aplicação das atualizações apenas a uma pequena parte do espaço de chaves geral do usuário por vez maximiza a disponibilidade de dados.
Estratégia de ciclo de vida de criar antes de destruir
Um cluster do Redis tem vários shards. Cada shard tem um nó principal e zero ou mais nós de réplica. O Memorystore usa o processo a seguir para atualizar qualquer nó do Redis principal ou de réplica em um shard:
- O Memorystore for Redis Cluster primeiro adiciona uma réplica completamente nova com a atualização de software mais recente ao shard. O Memorystore cria um nó totalmente novo, em vez de atualizar um nó atual, 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á 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 contínua 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 criar antes de destruir é 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 oferece suporte à 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.
É possível aproveitar melhor a arquitetura de escalonamento horizontal do cluster provisionando um número maior de shards 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 executa um failover coordenado para o nó de réplica recém-adicionado e, em seguida, prossegue 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, 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ó principal anterior, agora uma réplica, desbloqueia as solicitações atuais e as redireciona para o principal 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 exige mais redirecionamentos.
Os failovers coordenados normalmente levam dezenas de milissegundos. No entanto, o tamanho total do cluster pode aumentar a latência de failover. O mesmo acontece com os dados em trânsito pendentes de serem liberados 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 criar antes de destruir é remover o nó de réplica no software anterior. Uma remoção abrupta de nós seria impactante para aplicativos cliente, porque os clientes armazenam em cache as informações do endpoint e a topologia do cluster. O Memorystore for Redis Cluster projetou a remoção de uma réplica do Redis para ser normal, a fim de permitir que os aplicativos cliente atualizem a topologia antes de sofrer um desligamento de nó rígido. A topologia é personalizada para permitir que os clientes aprendam sobre 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 na 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 de cluster do OSS Redis 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 falhará, o que acionará uma atualização da topologia do cluster no cliente do cluster para que ele aprenda 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 as programações de manutenção para se alinhar às necessidades do aplicativo e minimizar 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 se estender além da janela selecionada.
Depois de configurar 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 definidas para janelas de manutenção.
Janelas de manutenção padrão
Se você não definir uma janela de manutenção, o Memorystore 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. 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 uma instância do Memorystore for Redis Cluster. Para garantir a performance ideal durante a manutenção, você pretende programá-la quando o cluster tiver o mínimo de tráfego, o que normalmente ocorre 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 garantir que você fique informado sobre eventos de manutenção no cluster, configure notificações por e-mail sobre a manutenção futura pelo menos uma semana antes da programação. 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]".
Após a conclusão da manutenção, uma notificação concluída é 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ê receberá um e-mail notificando sobre a manutenção cancelada. 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 descritas abaixo:
Para receber notificações de manutenção do Memorystore, conclua 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 futura.
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 oferecemos suporte ao envio de notificações para um endereço de e-mail diferente.
Ao se inscrever nas notificações de manutenção, você receberá alertas para todos os clusters do Memorystore com manutenção programada em um projeto especificado. Se você estiver inscrito, 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 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 são aplicadas:
- Não é possível reprogramar a manutenção se houver menos de uma hora restante antes do horário de manutenção programado atual.
- Após a reprogramação bem-sucedida, 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 (FAQ) 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 nas notificações e configure uma janela de manutenção. Também é possível
verificar o cluster manualmente para ver se o
maintenanceSchedule parâmetro aparece na resposta.
Quando o Memorystore for Redis Cluster notifica você sobre a manutenção futura?
Se você se inscrever nas notificações de manutenção e definir uma janela de manutenção, o Memorystore for Redis Cluster vai notificar você 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 adiar a atualização 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, 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 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 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 tiver 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 vai notificar você por e-mail pelo menos sete dias antes de uma atualização de manutenção ser programada para o cluster.
- Se você não tiver uma hora de baixo impacto ou sem impacto para o uso do aplicativo, use o padrão de serviço de 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 a atualização afeta o aplicativo. Você pode observar o impacto dessa atualização. Se houver problemas com a atualização, você poderá adiar a manutenção nos clusters de produção até resolver os problemas.
Se o dia e a hora atuais funcionarem para o cluster e você esperar uma carga alta no cluster no futuro, poderá executar 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 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 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 adiar por até duas semanas.
A seguir
- Confira as permissões necessárias para gerenciar janelas de manutenção para o cluster.