Página de ajuda para manutenção gerenciada e atualizações de serviço do Amazon ElastiCache

P: Quais as atualizações de serviço no Amazon ElastiCache?

As atualizações de serviço são um atributo do Amazon ElastiCache que permite aplicar determinadas atualizações de serviço a seu critério. Essas atualizações podem ser de um dos seguintes tipos: patches de segurança ou atualizações de software secundárias. Essas atualizações ajudam a fortalecer a segurança, a confiabilidade e a performance operacional dos clusters.

O valor dessas atualizações de serviço é que você pode controlar quando aplicar a atualização (por exemplo, pode retardar a aplicação de atualizações de serviço quando houver um evento comercial importante que exija disponibilidade 24x7 dos clusters do ElastiCache).

Para obter detalhes de cada atualização de serviço, consulte o valor do atributo "Update Description" (Atualizar descrição). 

P: Como posso ser notificado sobre uma atualização de serviço do ElastiCache disponível?

Quando atualizações de serviços aplicáveis aos seus clusters forem disponibilizadas, notificaremos você usando vários canais, incluindo o console do Amazon ElastiCache, o e-mail, o Amazon Simple Notification Service (SNS), o AWS Personal Health Dashboard e o Amazon CloudWatch Events.

P: Como as atualizações aplicadas na janela de manutenção são diferentes das atualizações de serviço?

As atualizações disponíveis por meio de nossa manutenção gerenciada contínua estão separadas das oferecidas por atualizações de serviço. As atualizações aplicadas por meio de manutenção gerenciada contínua são agendadas diretamente nas janelas de manutenção sem nenhuma ação necessária de sua parte. As atualizações de serviço são cronometradas e permitem que você controle quando quer aplicá-las de acordo com a “Data recomendada de aplicação”. Se elas ainda não forem aplicadas até então, o ElastiCache poderá agendá-las na janela de manutenção.

P: Como determino se devo aplicar a atualização de serviço disponível?

Se o cluster do ElastiCache está participando de um programa de conformidade da HIPAA, PCI ou FedRAMP, é necessário aplicar as atualizações de serviço de acordo com a “Data recomendada de aplicação” para manter a conformidade. Para obter mais informações, consulte Atualizações de segurança de autoatendimento para conformidade.

Para outros clusters, recomendamos aplicar as atualizações de serviço de acordo com a cadência dos negócios. Se não for possível aplicar uma atualização na “Data recomendada de aplicação”, você poderá aplicá-la até a “Data de expiração da atualização”. Contudo, a “Data de expiração da atualização” pode mudar a qualquer momento, dependendo da disponibilidade de novas atualizações.

P: Qual o impacto da aplicação de uma atualização de serviço nos clusters do ElastiCache? Perderei dados ou a conectividade com meus clusters?

Quando você ou o Amazon ElastiCache aplica uma atualização de serviço a um ou mais clusters, a atualização é aplicada a um nó por vez dentro de cada fragmento até que todos os clusters selecionados estejam atualizados. Os nós que estiverem sendo atualizados sofrerão um período de inatividade de alguns segundos, embora o resto dos clusters continuará a distribuir o tráfego.

• Não haverá alteração na configuração dos clusters.
• Você observará um atraso nas métricas do CloudWatch, que serão atualizadas assim que possível.

As atualizações de serviço são aplicadas da mesma maneira que as “Atualizações de manutenção gerenciada contínua”, por meio da substituição de nós. Consulte as seguintes perguntas na seção Atualizações de manutenção gerenciada contínua nesta página para conhecer os detalhes sobre como a atualização é aplicada e como preparar sua aplicação para minimizar o impacto.

• Como a substituição de um nó afeta minha aplicação?
  
• Que práticas recomendadas devo seguir para obter uma experiência de substituição sem problemas e minimizar a perda de dados?
• Que práticas recomendadas de configuração de clientes devo seguir para minimizar a interrupção de aplicações durante a manutenção?
  

P: Existe tempo de inatividade associado à aplicação da atualização nos clusters do ElastiCache para Memcached?

Sim, o nó é substituído por um novo nó vazio. O conteúdo do cache não existirá mais e iniciará vazio.

P: Posso cancelar as atualizações de serviço?

Confira se é possível optar por não cancelar uma atualização de serviço verificando o valor do atributo “Atualização automática após a data de vencimento”. Se o valor do atributo “Atualização automática após a data de vencimento” de uma atualização de serviço for “não”, essa atualização de serviço poderá ser cancelada. Mas se o valor do atributo “Atualização automática após data de vencimento” de uma atualização de serviço for “sim” e a “Data recomendada de aplicação” estiver vencida, o ElastiCache agendará automaticamente a atualização de serviço para os clusters remanescentes durante a próxima janela de manutenção. Essa atualização automática do serviço será agendada antes da “Data de vencimento da atualização”, e você receberá uma notificação uma semana antes da atualização com o horário agendado. É altamente recomendável aplicar atualizações de segurança, mesmo que elas possam ser canceladas.  Se você escolher aplicar a atualização de serviço nos clusters restantes antes da janela de manutenção, o ElastiCache não reaplicará a atualização de serviço durante essa janela.

P: Por que as atualizações de serviço não podem ser aplicadas diretamente pelo ElastiCache durante as janelas de manutenção?

A finalidade das atualizações de serviço é proporcionar flexibilidade em relação ao momento da aplicação delas. Os clusters que não participam dos programas de conformidade compatíveis com o ElastiCache podem optar por não aplicar essas atualizações ou aplicá-las a uma frequência reduzida durante todo o ano. Isso é verdadeiro somente quando o valor do atributo “Atualização automática após data de vencimento” de uma atualização de serviço for “não”. Para obter mais informações, consulte “Posso cancelar as atualizações de serviço?”.

P: Posso usar as atualizações de serviço para cancelar a manutenção de serviço do Amazon ElastiCache e aplicar as atualizações disponíveis por conta própria?

Não, as atualizações de serviço são mutuamente exclusivas em relação às atualizações de manutenção gerenciada contínua aplicadas diretamente pelo Amazon ElastiCache durante as janelas de manutenção dos clusters.

P: Onde está a lista de todos os atributos das atualizações de serviço?

Uma lista completa de atributos e respectivas descrições está disponível em Aplicação das atualizações de autoatendimento.

P: Todas as atualizações de serviço têm o mesmo cronograma de aplicação?

Para ajudar a determinar com que brevidade as atualizações de serviço disponíveis devem ser aplicadas, consulte o atributo “Gravidade” da atualização de serviço, que tem os seguintes valores (em ordem de prioridade):

1. crítica: aplicação imediata recomendada (dentro de 14 dias ou menos)
2. importante: aplicação recomendada assim que o fluxo dos negócios permitir (dentro de 30 dias ou menos)
3. média: aplicação recomendada dentro de 60 dias ou menos
4. baixa: aplicação recomendada dentro de 90 dias ou menos

Para obter mais detalhes, consulte nossa documentação pública – Aplicação de atualizações.

P: Com que frequência as atualizações de serviço são lançadas?

O agendamento dos lançamentos depende da importância das atualizações de serviço.

P: O que é o atributo “SLA de atualização de serviço cumprido”?

Esse atributo reflete se o cluster foi atualizado na “Data recomendada de aplicação”. Se a atualização de serviço for aplicada após a “Data recomendada de aplicação”, o atributo “SLA de atualização de serviço cumprido” será definido como “não”.

Essas informações são relevantes para os clusters do Amazon ElastiCache que participam de programas de conformidade da HIPAA, PCI e FedRAMP. Para obter mais informações, consulte Atualizações de segurança de autoatendimento para conformidade.

P: Se eu perder uma ou mais atualizações de serviço, poderei aplicá-las posteriormente?

Sim. Salvo observação contrária no atributo “Descrição” da atualização de serviço, as atualizações de serviço sempre são cumulativas: se você deixar de aplicá-las na “Data de expiração da atualização”, elas serão incluídas na próxima atualização de serviço. As atualizações de serviço do tipo “segurança” se enquadram nessa categoria cumulativa.

P: Posso optar por aplicar uma atualização de serviço a nós específicos em um cluster do ElastiCache?

Não, as atualizações de serviço são aplicadas em nível de cluster. Se você cancelar uma atualização contínua, um cluster pode ter alguns nós atualizados e outros não. Nesse caso, o cluster continuará a ser exibido na lista de clusters em que a atualização de serviço deve ser aplicada. O cluster continuará a operar normalmente.

P: Por que o status da atualização de um ou mais nós em meus clusters do ElastiCache mudam de “não aplicada” para “concluída” mesmo quando não aplico a atualização de serviço?

Há dois casos em que isso pode acontecer:

(a) Se você deixou de aplicar a atualização de serviço que era opcional e a atualização está no status “expirada” agora. Portanto, os clusters participantes de programas de conformidade sempre devem aplicar todas as atualizações de serviço.
(b) Se o(s) nó(s) for(em) substituído(s) por qualquer outro motivo, como um evento de manutenção planejada ou failover de nós, o Amazon ElastiCache fornecerá novos nós com as atualizações de serviço mais recentes incluídas.

Nos dois casos, o cluster continuará a operar normalmente.

P: E se eu tiver nós nos quais quero aplicar atualizações de serviço expiradas? Devo aguardar a próxima atualização de serviço?

Os novos nós contêm todas as atualizações de serviço aplicáveis, assim você pode substituir manualmente os nós existentes que não foram atualizados para obter as atualizações mais recentes.

P: As atualizações de serviço são específicas de mecanismos?

Sim. Uma atualização de serviço pode ser aplicável apenas ao Redis OSS, apenas ao Memcached ou a ambos. Você pode procurar pelos atributos de atualização de serviço “Engine” (Mecanismo) e “Engine Version” (Versão do mecanismo) para determinar o escopo de cada atualização.

P: Posso alterar a atualização de serviço programada para um horário mais conveniente? O que acontecerá com a atualização programada se eu alterar a janela de manutenção?

Sim, você pode adiar a atualização de serviço alterando a janela de manutenção. A atualização programada só será aplicada ao cluster se a data programada combinar com a janela de manutenção do cluster. Depois da alteração da janela de manutenção, se a data programada tiver passado, a atualização de serviço será reprogramada para a janela recém-especificada nas semanas seguintes. Você receberá uma nova notificação uma semana antes da nova data.

A segurança na AWS é uma responsabilidade compartilhada. Recomendamos enfaticamente que a atualização seja aplicada o quanto antes.

P: Por que recebi notificações para várias atualizações para o mesmo cluster? Preciso aplicar todas elas?

Seu cluster pode ser parte de diferentes atualizações de serviço. A maioria das atualizações não precisa ser aplicada separadamente. A aplicação de uma atualização ao seu cluster marcará as outras atualizações como concluídas sempre que aplicável. Pode ser necessário aplicar várias atualizações ao mesmo cluster separadamente se o status não mudar para “completed” (concluído) automaticamente.

P: Como a atualização de serviço é programada e aplicada após a “Data máxima recomendada para aplicação”?

O ElastiCache programará a atualização de serviço nos clusters restantes após a “Data máxima recomendada para aplicação” se o valor do atributo “Auto-Update after Due Date” (Atualizar automaticamente após o prazo) for “yes” (sim). A atualização será programada na janela de manutenção do cluster e você receberá uma nova notificação uma semana antes da data programada, antes da aplicação das atualizações.

A atualização de serviço programada será aplicada aos clusters da mesma maneira que as “Atualizações de manutenção gerenciada contínua”. Consulte a seção a seguir sobre os detalhes de como a atualização é aplicada, como mudar a data programada e como preparar sua aplicação para uma atualização programada para minimizar o impacto.

P: O que acontecerá se a atualização do serviço não puder ser aplicada a todo o cluster em uma única janela de manutenção?

Para manter a estabilidade do cluster, o ElastiCache aplica as atualizações em apenas um nó de cada vez em cada fragmento. Se a atualização do serviço não puder ser aplicada a todo o cluster em uma única janela de manutenção, ela será programada para continuar nas próximas. Você receberá novas notificações na próxima data programada e poderá se preparar de acordo.

P: Posso reverter a atualização do serviço?

O cliente não pode reverter a atualização do serviço depois que ela começar. Se você se deparar com um problema após uma atualização de serviço, entre em contato com a equipe do AWS Support.

P: O que é uma atualização de manutenção gerenciada contínua?

Essas atualizações são obrigatórias e aplicadas diretamente nas janelas de manutenção, sem nenhuma ação necessária de sua parte. Essas atualizações são separadas daquelas oferecidas pelas atualizações de serviço.

P: Quanto tempo leva uma substituição de nó?

Normalmente, uma substituição leva alguns segundos. A substituição pode levar mais tempo em determinadas configurações de instância e padrões de tráfego. Por exemplo, os nós primários do Redis OSS podem não ter memória livre suficiente e podem estar enfrentando um tráfego de gravação elevado. Quando uma réplica vazia é sincronizada por meio desse primário, o nó primário pode ficar sem memória tentando resolver as gravações de entrada, assim como sincronizar a réplica. Nesse caso, o principal desconecta a réplica e reinicia o processo de sincronização. Podem ser necessárias várias tentativas para que a réplica seja sincronizada com sucesso. Também é possível que a réplica nunca seja sincronizada se o tráfego de entrada de gravação permanecer elevado.

Como os nós do Memcached não precisam de sincronização, a substituição deles é concluída mais rápido, independentemente dos tamanhos dos nós.

P: Como uma substituição de nó afeta minha aplicação?

Para nós do Redis OSS, o processo de substituição foi criado para fazer o possível para reter seus dados atuais. Ele também exige uma replicação bem-sucedida. Para clusters de nó único, o ElastiCache inicia de modo dinâmico uma réplica, replica os dados e faz o failover para ele. Para grupos de replicação compostos por vários nós, o ElastiCache substitui as réplicas atuais e sincroniza os dados do primário para as novas réplicas. Se o Multi-AZ com failover automático estiver habilitado, a substituição do primário acionará um failover para uma réplica de leitura. Para configurações de cluster configuradas para usar clientes de cluster e configurações não cluster com o failover automático ativado, as substituições de nó planejadas são concluídas enquanto o cluster atende às solicitações de gravação recebidas. Se o Multi-AZ estiver desativado, o ElastiCache substituirá o primário e sincronizará os dados de uma réplica de leitura. O nó primário fica indisponível durante esse período, o que leva a uma maior interrupção das gravações.

Para os nós do Memcached, o processo de substituição gera um novo nó vazio e encerra o nó atual. O novo nó ficará indisponível por um curto período durante a substituição. Após a substituição, o aplicativo poderá sofrer uma degradação na performance durante o preenchimento do novo nó com dados do cache.

P: Que melhores práticas devo seguir para obter uma experiência de substituição sem problemas e minimizar a perda de dados?

Para nós do Redis OSS, o processo de substituição foi criado para fazer o possível para reter seus dados atuais. Ele também exige uma replicação bem-sucedida. Tentamos substituir uma quantidade suficiente de nós por meio do mesmo cluster de cada vez para mantê-lo estável. Você pode provisionar réplicas primárias e de leitura em diferentes zonas de disponibilidade. Nesse caso, quando um nó for substituído, os dados serão sincronizados por meio de um nó emparelhado em uma zona de disponibilidade diferente. Também recomendamos atualizar a versão do mecanismo do Redis OSS para 5.0.6 ou posterior, pois essas versões têm melhor estabilidade e permitem que seus clusters distribuam continuamente solicitações de gravação de entrada durante as atividades de aplicação de patches, se estiverem com o failover automático habilitado. Por fim, se sua configuração conta com apenas uma réplica primária e uma réplica única por fragmento, recomendamos incluir outras réplicas antes de aplicar os patches. Isso evitará riscos e redução da disponibilidade durante o processo de aplicação de patches. Para clusters de nó único, recomendamos que exista memória suficiente disponível para o Redis OSS, como descrito aqui. Para grupos de replicação com vários nós, também recomendamos programar a substituição durante um período de baixo tráfego de gravação de entrada.

Para os nós do Memcached, programe sua janela de manutenção durante um período com um baixo tráfego de entrada de gravação, teste sua aplicação para o failover e use o cliente “mais inteligente” disponibilizado pelo ElastiCache. A perda de dados é inevitável, pois o Memcached só tem dados na memória.

P: Quais melhores práticas de configuração de cliente devo seguir para minimizar a interrupção de aplicativos durante a manutenção?

Para o Redis OSS, a configuração no modo cluster oferece a melhor disponibilidade durante operações gerenciadas ou não gerenciadas. Recomendamos sempre usar um cliente compatível com o modo cluster que se conecta ao endpoint de descoberta do cluster. Para o modo de cluster desabilitado, recomendamos usar sempre o endpoint do primário para todas as operações de gravação. Os endpoints de nós individuais dos nós de réplica podem ser usados para todas as operações de leitura. Se o failover automático estiver habilitado no cluster, o nó primário poderá sofrer alterações. Portanto, o aplicativo deve confirmar a função do nó e atualizar todos os endpoints de leitura para garantir que o mestre não fique sujeito a uma carga excessiva. Com o failover automático desabilitado, a função do nó não mudará. No entanto, o tempo de inatividade das operações gerenciadas ou não gerenciadas será maior em relação aos clusters com failover automático habilitado. Evite direcionar as solicitações de leitura apenas às réplicas de leitura. Se você configurar o cliente para direcionar solicitações de leitura apenas para réplicas de leitura, garanta a disponibilidade de pelo menos duas réplicas de leitura para evitar qualquer interrupção das leituras durante a manutenção.

P: Como posso gerenciar substituições de nó por conta própria?

Recomendamos que você permita que o ElastiCache gerencie as substituições de nó durante sua janela de manutenção programada. Você pode especificar seu horário preferencial para as substituições por meio de uma janela de manutenção semanal durante a criação de um cluster do ElastiCache. Para alterar posteriormente sua janela de manutenção para um horário mais conveniente, você pode usar a API ModifyCacheCluster ou clicar em Modify no Console de Gerenciamento do ElastiCache.

Se preferir gerenciar você mesmo a substituição, há várias ações disponíveis, dependendo do caso de uso e da configuração do cluster:

• Alterar a janela de manutenção.
• Reiniciar a instância usando o processo de backup e restauração.
• Se a configuração do cluster for Cluster Mode Disabled

o Substituir uma réplica de leitura (Cluster-Mode Disabled): procedimento para substituir manualmente uma réplica de leitura em um grupo de replicação.
o Substituir o nó primário (Cluster-Mode Disabled): procedimento para substituir manualmente o nó principal em um grupo de replicação.
o Substituir um nó autônomo (Cluster-Mode Disabled): dois procedimentos diferentes para substituir um nó autônomo.

• Se a configuração do cluster for Cluster Mode Enabled

o Substituir um nó no cluster com um ou mais fragmentos: para substituir os nós, você pode usar backup e restauração ou aumentar e reduzir a escalabilidade.

Para obter mais instruções sobre todas essas opções, consulte a página Ações que você pode tomar quando um nó está agendado para substituição.

Para Memcached, basta excluir e recriar os clusters. Após a substituição, a sua instância não deverá ter mais nenhum evento programado associado a ela.

P: Como posso ficar sabendo sobre as próximas substituições programadas?

Para receber notificações, é possível definir as notificações do Amazon SNS para eventos significativos, como o eventos de substituição programada. É possível fazer isso no Console de Gerenciamento do ElastiCache da seção Eventos, ou utilizando a API describe-events para procurar pelo próximo evento ElastiCache:NodeReplacementScheduled.

Para configurar notificações do SNS, use as informações disponibilizadas aqui.

P: Posso alterar a manutenção programada para um horário mais conveniente?

Sim. Você pode mudar a janela de manutenção do seu cluster. Para alterar posteriormente sua janela de manutenção para um horário mais conveniente, você pode usar a API(ModifyCacheCluster ou ModifyReplicationGroup) ou clicar em Modify no Console de Gerenciamento do ElastiCache.

Depois de mudar a janela de manutenção, o serviço ElastiCache programará seu nó para manutenção durante a janela recentemente especificada. Veja abaixo exemplos de como as mudanças entrarão em vigor.

Por exemplo,

digamos que hoje seja quinta-feira, 9 de novembro, às 15h, e a próxima janela de manutenção seja sexta-feira, 10 de novembro, às 17h. Veja estes três cenários e seus resultados:

• Você muda sua janela de manutenção para sexta-feira, às 16h (após a data/hora atual e antes da próxima janela de manutenção programada). O nó será substituído na sexta-feira, 10 de novembro, às 16h.
• Você muda sua janela de manutenção para sábado, às 16h (após a data/hora atual e depois da próxima janela de manutenção programada). O nó será substituído no sábado, 11 de novembro, às 16h.
• Você muda sua janela de manutenção para quarta-feira, às 16h (dia da semana anterior à data/hora atual). O nó será substituído na próxima quarta-feira, 15 de novembro, às 16h.

P: Por que é necessário fazer essas substituições de nós?

Essas substituições são necessárias para a aplicação de atualizações de software obrigatórias no host subjacente. As atualizações ajudam a fortalecer a nossa segurança, a nossa confiabilidade e a nossa performance operacional.

P: Essas substituições afetam meus nós em várias zonas de disponibilidade ao mesmo tempo?

Podemos substituir vários nós do mesmo cluster, dependendo da configuração do cluster, mantendo sempre sua estabilidade. Para clusters fragmentados, tentamos evitar a substituição de vários nós do mesmo fragmento ao mesmo tempo. Além disso, tentamos evitar a substituição da maioria dos nós principais no cluster em todos os fragmentos.
Para clusters não estilhaçados, tentamos escalonar ao máximo as substituições de nós durante a janela de manutenção para continuar a manter a estabilidade do cluster.

P: Os nós de clusters diferentes em regiões diferentes podem ser substituídos ao mesmo tempo?

Sim. É possível que esses nós sejam substituídos ao mesmo tempo, se sua janela de manutenção para esses clusters estiver configurada para ser a mesma.