Esta página explica como o Memorystore for Redis Cluster realiza a manutenção nas instâncias. Também fornece informações e recomendações de configuração de que as aplicações cliente devem ter conhecimento para tirar partido do design de manutenção sem tempo de inatividade do Memorystore para Redis Cluster. Estas recomendações aplicam-se a clusters altamente disponíveis e a clusters sem réplicas. No entanto, recomendamos vivamente a configuração de alta disponibilidade para todos os exemplos de utilização de produção.
O Memorystore for Redis Cluster atualiza rotineiramente as instâncias para garantir que o serviço é fiável, tem um bom desempenho, é seguro e está atualizado. Estas atualizações são denominadas manutenção. A manutenção é totalmente gerida pelo serviço e foi concebida para não ter impacto na inatividade.
Normalmente, a manutenção enquadra-se nas seguintes categorias:
- Funcionalidades do Memorystore. Para iniciar algumas funcionalidades, o Memorystore requer uma atualização de manutenção.
- Patches do sistema operativo. Monitorizamos continuamente as vulnerabilidades de segurança recém-identificadas no sistema operativo. Após a deteção, aplicamos patches ao sistema operativo para proteger o utilizador contra novos riscos.
- Patches da base de dados. A manutenção pode incluir uma atualização do Redis para melhorar as caraterísticas de segurança, desempenho e fiabilidade da instância além do que o OSS Redis oferece.
Configure a aplicação cliente
Para configurar a sua aplicação cliente para o melhor desempenho e disponibilidade possíveis durante a manutenção, siga estes passos:
- Use e configure o cliente do cluster Redis de OSS de acordo com as orientações nas práticas recomendadas do cliente Redis para garantir que qualquer manutenção agendada não afeta a sua aplicação cliente. As nossas configurações de cliente recomendadas podem evitar as reposições de ligação através de atualizações de topologia incorporadas periódicas e rotações de ligações em segundo plano.
- Teste a sua aplicação cliente com uma série de operações de atualização (como aumentar ou diminuir a escala, alterações à quantidade de réplicas) enquanto executa uma carga de trabalho representativa nos nós primários e de réplica, e monitoriza o impacto no cliente. Estas atualizações testam a lógica de atualização da 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 do cluster Redis de OSS está configurado corretamente para evitar qualquer impacto negativo na sua aplicação.
Manutenção agendada
O Memorystore for Redis Cluster tira partido de uma implementação gradual e de uma estratégia de ciclo de vida de criação antes da destruição para evitar qualquer impacto de tempo de inatividade causado pela manutenção. A manutenção sem tempo de inatividade é alcançada através da utilização das capacidades de redirecionamento de pedidos do protocolo de cluster do Redis OSS em conjunto com os seguintes mecanismos do Memorystore:
- Ativação pós-falha coordenada sem perda de dados.
- Remoção de nós elegante para permitir que os clientes alcancem as atualizações da topologia do cluster sem qualquer impacto na disponibilidade.
- Os pontos finais do Private Service Connect do cluster não são afetados pela manutenção. Para mais informações sobre estes pontos finais, consulte o artigo Pontos finais de cluster.
O comportamento do serviço descrito nas secções seguintes aplica-se apenas à manutenção agendada. Para ver informações sobre o impacto de eventos não planeados, como falhas de hardware, consulte o artigo Comportamento do cliente durante uma comutação por falha não planeada.
Estratégia de implementação gradual
As implementações de manutenção do Memorystore for Redis Cluster são realizadas com um âmbito progressivamente crescente e a uma taxa que permite a deteção de falhas com antecedência suficiente para mitigar o impacto e estabelecer confiança na estabilidade. Os tempos de processamento (tempo durante o qual a atualização é aplicada e monitorizada antes de ser considerada um sucesso e de avançar) estão integrados na frota de clusters do Memorystore à escala do serviço. Além disso, os tempos de preparação estão integrados no cluster em várias zonas numa região (vários domínios de falhas) para reduzir o âmbito do impacto, se existir.
Para o cluster configurado para alta disponibilidade, é atualizado, no máximo, um domínio de falha/zona em qualquer momento para garantir que um fragmento do cluster, incluindo as réplicas primárias e secundárias, tem alta disponibilidade durante toda a atualização. Além disso, apenas alguns nós do Redis são atualizados em qualquer momento. As atualizações usam um mecanismo de ciclo de vida de criação antes da destruição para maximizar a estabilidade do cluster. Esta estratégia oferece mais vantagens quando atualiza um cluster com muitos fragmentos. A aplicação das atualizações apenas a uma pequena parte do espaço de chaves do utilizador geral em qualquer momento maximiza a disponibilidade dos dados.
Estratégia de ciclo de vida de criação antes da destruição
Um cluster 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 existente num fragmento:
- O Memorystore for Redis Cluster adiciona primeiro 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 aprovisionada é retida em caso de falha de arranque inesperada.
- Se um nó no fragmento a ser atualizado for um nó principal, é primeiro convertido numa réplica antes da remoção através de uma transferência de controlo coordenada.
- 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 reter a capacidade aprovisionada do cluster, em comparação com uma implementação contínua típica que atualiza no local, mas resulta numa indisponibilidade (e, por vezes, perda de dados) para a aplicação cliente. Para fragmentos sem réplicas, o Memorystore for Redis Cluster continua a aprovisionar primeiro uma nova réplica, coordena a comutação por falha e, por último, substitui o nó principal existente do fragmento.
Passo 1: adicione uma réplica do Redis
O primeiro passo do mecanismo de criação antes da destruição é adicionar um nó de réplica com o software mais recente através do mecanismo Redis OSS de sincronização completa para copiar os dados do nó principal para o nó de réplica. Isto é feito através da ramificação de um processo secundário e da utilização da replicação sem disco para iniciar a réplica.
Pode tirar o melhor partido da arquitetura de escala horizontal do cluster aprovisionando um número mais elevado de fragmentos para reduzir o tamanho do espaço de chaves num nó. Ter um conjunto de dados mais pequeno por nó ajuda a reduzir o impacto da latência de ramificação de uma operação de sincronização completa. Também acelera a cópia de dados entre os nós.
Passo 2: comutação por falha primária coordenada
Se o nó do Redis que precisa de ser atualizado for um nó principal, o Memorystore executa primeiro uma comutação por falha coordenada para o nó de réplica recém-adicionado e, em seguida, prossegue com a remoção do nó. Durante a comutação por falha coordenada, o cliente e os nós do Redis funcionam em conjunto e usam as seguintes estratégias para evitar o tempo de inatividade da aplicação:
- Os pedidos de clientes recebidos são bloqueados temporariamente no nó principal, o que dá tempo para garantir que a réplica existente está 100% sincronizada com o principal.
- A réplica conclui o processo de eleição para assumir a função principal.
- O nó principal anterior, agora uma réplica, desbloqueia os pedidos existentes e redireciona-os para o principal recém-eleito através do protocolo de cluster do Redis de código aberto. Todos os novos pedidos enviados para o nó de réplica anterior continuam a ser redirecionados para o novo nó principal.
- O cliente compatível com o Redis Cluster atualiza a respetiva topologia na memória. Aprende o endereço do novo ponto final principal e deixa de precisar de redirecionamentos.
Normalmente, as comutações por falha coordenadas devem demorar dezenas de milissegundos. No entanto, o tamanho total do cluster pode aumentar a latência de comutação por falha. O mesmo se aplica aos dados em curso pendentes de serem descarregados para réplicas. A dimensão do cluster pode afetar a convergência nos nós principais, o que afeta a tomada de decisões sobre a eleição do novo nó principal.
Passo 3: remova a réplica do Redis
O último passo do mecanismo de criação antes da destruição é remover o nó da réplica no software anterior. Uma remoção abrupta de um nó teria um impacto nas aplicações cliente, uma vez que os clientes armazenam em cache as informações do ponto final e a topologia do cluster. O Memorystore for Redis Cluster foi concebido para que a remoção de uma réplica do Redis seja feita de forma elegante, de modo a permitir que as aplicações cliente atualizem a respetiva topologia antes de sofrerem um encerramento forçado do nó. A topologia é personalizada para permitir que os clientes saibam mais sobre a nova réplica. A topologia também esquece a réplica que vai ser removida antes de ser removida.
O nó de réplica que executa o software anterior é mantido durante um determinado período de esgotamento, normalmente, numa questão de minutos, durante o qual começa a redirecionar os pedidos de leitura recebidos para o nó principal do respetivo fragmento. Permite que o cliente do cluster Redis de OSS atualize a topologia do cluster e saiba mais sobre os novos pontos finais da réplica. Se o cliente tentar alcançar um nó removido após o período de esgotamento, a tentativa falha, o que, por sua vez, aciona uma atualização da topologia do cluster no cliente do cluster para que este fique a saber da alteração da réplica. As novas atualizações da topologia do cluster não veem o nó da réplica que vai ser removido.
Definições de manutenção
Com o Memorystore, pode personalizar os agendamentos de manutenção para se alinharem com as necessidades da sua aplicação e minimizar as interrupções. Pode fazê-lo configurando um período 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 do período de manutenção é de 1 hora. Tenha em atenção que, em alguns casos, a manutenção pode prolongar-se para além do período selecionado.
Depois de configurar um período de manutenção para uma instância de cluster, a manutenção automática futura é agendada de acordo com as preferências definidas para os períodos de manutenção.
Períodos de manutenção predefinidos
Se não definir um período de manutenção, o Memorystore atualiza o cluster num dos seguintes períodos, de acordo com o fuso horário do cluster:
Janela de dias úteis (segunda a sexta-feira). Das 22:00 às 06:00
Período do fim de semana. Sexta, das 22:00 às segunda, às 06:00
Exemplo de manutenção
Como programador que gere um serviço de carrinho de compras num retalhista, é responsável por supervisionar um ambiente de produção que inclua uma instância do Memorystore for Redis Cluster. Para garantir um desempenho ideal durante a manutenção, pretende agendá-la para quando o cluster tiver um tráfego mínimo, o que ocorre normalmente por volta da meia-noite aos domingos.
Neste caso, pode definir o período de manutenção do cluster de produção para:
- Dia da semana. Domingo.
- Hora de início. 01:00
Notificações de manutenção futuras
Para garantir que se mantém informado sobre os eventos de manutenção no seu cluster, pode configurar notificações por email sobre a manutenção futura, pelo menos, uma semana antes da data agendada. Estas notificações têm a linha de assunto "Upcoming maintenance for your Cloud Memorystore instance [your-cluster-name]".
Também é enviada uma notificação quando a manutenção do cluster é iniciada. A linha de assunto do email seria "Maintenance
is undergoing for your Cloud Memorystore instance [your-cluster-name]".
Quando a manutenção estiver concluída, é enviada uma notificação de conclusão. O título do email é "Completed Maintenance
for your Cloud Memorystore instance [your-cluster-name]".
Se o Memorystore reagendar a manutenção, recebe um email a notificar que a manutenção foi cancelada. O assunto deste email seria "Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]".
Tem de aceitar receber estas notificações de manutenção. Para se inscrever nas notificações de manutenção, siga os passos descritos abaixo:
Para receber notificações de manutenção do Memorystore, certifique-se de que concluiu os passos acima, pelo menos, uma semana antes da atualização de manutenção agendada para a sua instância. Se não o fizer, o sistema não tem tempo suficiente para lhe enviar uma notificação sobre a manutenção futura.
As notificações são enviadas para o endereço de email associado à sua Conta Google. Não é possível configurar um alias do email personalizado (por exemplo, um alias do email de equipa). De momento, não suportamos o envio de notificações para um endereço de email diferente.
Ao subscrever as notificações de manutenção, recebe alertas para todos os clusters do Memorystore com manutenção agendada num projeto especificado. Se tiver subscrito, recebe uma notificação separada para cada cluster.
Para obter instruções sobre como encontrar a manutenção agendada, consulte o artigo Encontre a manutenção agendada.
Reagendamento da manutenção
No cenário em que os períodos de manutenção estão configurados para o seu cluster, esta secção fornece diretrizes sobre como reagendar a manutenção. Por exemplo, se o lançamento de um novo serviço estiver agendado para o seu período de manutenção atual, é recomendável adiá-lo até alguns dias após o lançamento.
Pode reagendar a manutenção as vezes que quiser no prazo de duas semanas após a hora originalmente agendada. Pode escolher uma das seguintes opções ao reagendar:
- Atualizar agora. Em vez de esperar pelo período de manutenção agendado, pode aplicar imediatamente as atualizações ao seu cluster.
- Dia e hora personalizados. Isto permite-lhe escolher qualquer hora específica no prazo de duas semanas da hora de manutenção originalmente agendada.
Ao reagendar a manutenção, aplicam-se as seguintes restrições:
- Se faltar menos de uma hora para a hora de manutenção agendada atual, não pode reagendar a manutenção.
- Após o reagendamento bem-sucedido, é enviado um email a confirmar o cancelamento da manutenção anterior e é enviada uma nova notificação de manutenção futura com o agendamento atualizado.
Para ver instruções sobre como reagendar a manutenção, consulte o artigo Reagende a manutenção.
Perguntas frequentes
Seguem-se algumas perguntas frequentes sobre a política de manutenção do Memorystore for Redis Cluster:
Como posso saber quando está agendada a manutenção do meu cluster?
Recomendamos que subscreva as notificações e configure um período de manutenção para saber quando a manutenção está agendada para a sua instância. Também pode verificar manualmente através da opção Encontrar manutenção agendada para ver se o campo maintenance_schedule está definido na resposta.
Quando é que recebo uma notificação sobre a manutenção futura?
Se subscreveu as notificações de manutenção e definiu um período de manutenção, recebe um alerta por email, pelo menos, 1 semana antes de um evento de manutenção.
Durante quanto tempo posso adiar a manutenção?
Assim que a manutenção for agendada para o seu cluster, pode iniciar a atualização da sua instância imediatamente ou adiá-la até 2 semanas a partir da hora de manutenção originalmente agendada. Por exemplo, se a manutenção estiver agendada para 11 de outubro às 23:15, pode adiá-la até 25 de outubro às 23:15. A manutenção vai ser aplicada à hora agendada se não forem tomadas medidas.
Para mais detalhes, consulte o artigo Remarque a manutenção.
Que práticas recomendadas devo seguir para uma experiência de atualização de manutenção sem problemas?
Recomendamos que tome as seguintes medidas para garantir uma experiência de atualização de manutenção sem problemas:
- Siga as instruções para configurar a aplicação cliente
- Deve definir o período de manutenção para uma hora que garanta que a manutenção não é aplicada nas horas de pico de utilização do Redis.
- Deve ativar as notificações de manutenção para receber um alerta por email, pelo menos, sete dias antes de uma atualização de manutenção ser agendada para a sua instância.
- Se não tiver uma hora de baixo impacto ou sem impacto para a utilização da sua aplicação, recomendamos que use a predefinição do serviço de implementações graduais, que tem práticas recomendadas incorporadas. Para mais informações, consulte o artigo Manutenção programada.
Quando devo aplicar a manutenção imediatamente?
Um cenário em que pode aplicar a atualização de manutenção imediatamente é num cluster de teste para ver o impacto na sua aplicação. Isto permite-lhe observar o impacto que tem e adiar a manutenção nos clusters de produção conforme necessário/permitido.
Também pode agendar imediatamente a manutenção se a hora atual for adequada para o seu cluster e esperar uma carga elevada no cluster no futuro.
As atualizações de manutenção são sempre concluídas dentro do período de manutenção?
Uma atualização começa dentro do período de manutenção que especificar. Normalmente, a atualização é concluída dentro do período, mas isto não é garantido.
Posso recusar a manutenção ou agendar a manutenção em determinados clusters primeiro?
Não, não pode desativar a manutenção nem controlar a ordem de manutenção dos seus clusters. No entanto, assim que receber a notificação de manutenção inicial, pode reagendar a manutenção para a adiar até 2 semanas.
O que se segue?
- Veja as autorizações necessárias para gerir as janelas de manutenção do seu cluster Redis.