Nesta página, explicamos como o Memorystore para Valkey realiza a manutenção em instâncias. 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 para Valkey. Essas recomendações se aplicam a instâncias de alta disponibilidade e sem réplicas. No entanto, recomendamos a configuração de alta disponibilidade para todos os casos de uso de produção.
O Memorystore para Valkey atualiza as instâncias regularmente para garantir que o serviço seja confiável, seguro, atualizado e tenha alto desempenho. Essas atualizações são chamadas de manutenção. A manutenção é totalmente gerenciada pelo serviço e foi projetada para não causar inatividade.
A manutenção geralmente 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 Valkey para melhorar as características de segurança, desempenho e confiabilidade da instância além do que o Valkey do OSS oferece.
Configurar o aplicativo cliente
Para configurar o aplicativo cliente para ter o melhor desempenho e disponibilidade possível durante a manutenção, siga estas etapas:
- Use e configure o cliente de terceiros de acordo com as orientações em Práticas recomendadas para clientes para garantir que qualquer manutenção programada não afete o aplicativo do cliente. Nossas configurações recomendadas de cliente 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 reduzir escalonamento horizontal ou para fora, mudanças no número de réplicas) enquanto executa uma carga de trabalho representativa nos nós principais 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 de terceiros esteja configurado corretamente para evitar qualquer impacto negativo no seu aplicativo.
Manutenção programada
O Memorystore para Valkey usa uma estratégia de ciclo de vida de implantação gradual e de criação antes da destruição para evitar o impacto do tempo de inatividade da manutenção programada do Memorystore nas instâncias do Valkey. A manutenção sem tempo de inatividade é alcançada usando os recursos de redirecionamento de solicitações do protocolo de cluster OSS Valkey em conjunto com os seguintes mecanismos do Memorystore:
- Failover coordenado sem perda de dados
- Remoção suave de nós para permitir que os clientes acompanhem as atualizações de topologia de nó sem impacto na disponibilidade
- Os endpoints do PSC da instância não são afetados pela manutenção. Para mais informações sobre endpoints do PSC, consulte Endpoints de instância.
O comportamento do serviço descrito nas seções a seguir se aplica apenas à manutenção programada. Para saber mais sobre o impacto de eventos não planejados, como falhas de hardware, consulte Comportamento do cliente durante um failover não planejado.
Janelas de manutenção padrão
Por padrão, o Memorystore atualiza sua instância nas seguintes janelas de acordo com o fuso horário da instância:
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
Estratégia de implantações graduais
As implantações do Memorystore para Valkey são realizadas com um escopo progressivamente maior e em uma taxa que permite a detecção de falhas com antecedência suficiente para reduzir o impacto e estabelecer a confiança na estabilidade. Os tempos de cozimento (tempo durante o qual a atualização é aplicada e monitorada antes de ser considerada um sucesso e seguir em frente) são integrados à frota de instâncias do Memorystore na escala do serviço. Além disso, os tempos de cozimento são integrados às instâncias em várias zonas de uma região (vários domínios de falha) para reduzir o escopo do impacto, se houver.
Na instância configurada para alta disponibilidade, no máximo um domínio/zona de falha é atualizado a qualquer momento para garantir que um fragmento de instância, incluindo o principal e as réplicas, tenha alta disponibilidade durante a atualização. Além disso, apenas alguns nós da Valkey são atualizados a qualquer momento. As atualizações usam um mecanismo de ciclo de vida de criação antes da destruição para maximizar a estabilidade da instância. Essa estratégia oferece mais benefícios ao atualizar uma instância 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 dos dados.
Estratégia de ciclo de vida "Criar antes de destruir"
Uma instância do Valkey 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 réplica Valkey em um fragmento:
- O Memorystore para Valkey 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 existente, para garantir que a capacidade provisionada seja mantida em caso de falha inesperada de inicialização.
- 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.
- O Memorystore remove a réplica que usa o software anterior.
- O processo é repetido para cada nó na instância.
A estratégia de criar antes de destruir ajuda a manter a capacidade provisionada da instância em comparação com uma implantação contínua 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 para Valkey ainda provisiona uma nova réplica, coordena o failover e, por fim, substitui o nó principal do fragmento.
Etapa 1: adicionar a réplica do Valkey
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 chave Valkey OSS de sincronização completa para copiar os dados do nó principal para o de réplica. Isso é feito bifurcando 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 da instância, 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ó Valkey 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 depois prossegue com a remoção do nó. Durante o failover coordenado, o cliente e os nós Valkey trabalham juntos e usam as seguintes estratégias para evitar o tempo de inatividade do aplicativo:
- As solicitações de cliente recebidas são bloqueadas temporariamente no nó principal, oferecendo uma janela para garantir que a réplica existente 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 OSS Valkey. Todas as novas solicitações enviadas para o nó de réplica anterior continuam sendo redirecionadas para o novo nó principal.
- O cliente compatível com Valkey atualiza a topologia na memória. Ele aprende o endereço do novo endpoint principal e não precisa mais de redirecionamentos.
As failovers coordenadas geralmente levam dezenas de milissegundos. No entanto, os dados em trânsito pendentes de transmissão para réplicas e o tamanho total da instância podem aumentar a latência de failover. O tamanho da instância pode afetar a convergência entre os nós principais, o que afeta a tomada de decisão na eleição do novo primário.
Etapa 3: remover a réplica do Valkey
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ó afetaria os aplicativos clientes porque eles armazenam em cache as informações do endpoint e a topologia da instância. O Memorystore para Valkey foi projetado para remover uma réplica de Valkey de forma suave, permitindo que os aplicativos clientes atualizem a topologia antes de ocorrer uma interrupção do nó. A topologia é personalizada para permitir que os clientes conheçam a nova réplica, mas também se esqueçam da que será removida com antecedência.
O nó de réplica que executa o software anterior é mantido por um determinado período de esgotamento, normalmente de alguns 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 terceiros atualize a topologia de nó e saiba sobre os novos endpoints de réplica. Se o cliente tentar acessar um nó removido após o período de esgotamento, a tentativa falhará, o que aciona uma atualização da topologia do nó no cliente de conexão para que ele saiba sobre a mudança da réplica. As novas atualizações da topologia de nó não mostram o nó de réplica a ser removido.