Como administrar o Redis Gerenciado do Azure (versão prévia)
Esse artigo descreve como executar tarefas administrativas, como reinicializar e Atualizar canal e Agendar atualizações para suas instâncias do Redis Gerenciado do Azure (versão prévia).
Reinicialização
À esquerda, Reinicializar permite a reinicialização de um ou mais nós do cache. Essa funcionalidade de reinicialização permite que você teste seu aplicativo para garantir a resiliência caso ocorra uma falha de um nó de cache.
Importante
A reinicialização ainda não está disponível para a camada de Enterprise. A reinicialização está disponível para todos as outras camadas.
Selecione os nós a serem reinicializados e selecione Reinicializar.
Se tiver um cache premium com clustering habilitado, você poderá selecionar quais fragmentos do cache serão reinicializados.
Para reinicializar um ou mais nós do cache, selecione os nós e, em seguida, Reinicializar. Se você tiver um cache premium com clustering habilitado, selecione os fragmentos a serem reinicializados e, em seguida, Reinicializar. Depois de alguns minutos, os nós selecionados são reinicializados e voltam a ficar online alguns minutos mais tarde.
O efeito em aplicativos cliente varia de acordo com quais nós você reinicializa.
- Mestre: quando o nó primário é reinicializado, o Redis Gerenciado do Azure faz failover para o nó de réplica e o promove a primário. Durante esse failover, pode haver um pequeno intervalo curto em que as conexões com o cache podem falhar.
- Réplica: quando o nó de réplica é reinicializado, geralmente, não há efeito nos clientes do cache.
- Ambos primário e réplica: quando ambos os nós de cache forem reinicializados, o Redis Gerenciado do Azure para Redis tentará reinicializar normalmente ambos os nós, esperando que um termine antes de reinicializar o outro. Normalmente, não ocorre perda de dados. Entretanto, a perda de dados ainda pode ocorrer devido a eventos de manutenção ou falhas inesperadas. Reiniciar seu cache várias vezes consecutivas aumenta as chances de perda de dados.
- Nós de um cache premium com clustering habilitado – Quando você reinicializa um ou mais nós de um cache premium com o clustering habilitado, o comportamento dos nós selecionados é o mesmo de quando você reinicializa o nó ou os nós correspondentes de um cache sem cluster.
Perguntas frequentes sobre reinicialização
- Qual nó devo reinicializar para testar o aplicativo?
- Posso reinicializar o cache para limpar conexões de cliente?
- Perderei dados do cache se eu fizer uma reinicialização?
- Posso reinicializar o cache usando o PowerShell, a CLI ou outras ferramentas de gerenciamento?
- Posso reinicializar meu cache de Enterprise?
Qual nó devo reinicializar para testar o aplicativo?
Para testar a resiliência do aplicativo contra falhas do nó primário do cache, reinicialize o nó Primário. Para testar a resiliência do aplicativo contra falhas do nó de réplica, reinicialize o nó de Réplica.
Posso reinicializar o cache para limpar conexões de cliente?
Sim, se você reinicializar o cache, todas as conexões de cliente serão limpas. A reinicialização pode ser útil no caso de todas as conexões de cliente serem usadas devido a um erro lógico ou a um bug no aplicativo cliente. Cada tipo de preços tem diferentes limites de conexão do cliente para os vários portes, e quando os limites são atingidos, não são mais aceitas mais conexões de cliente. Reinicializar o cache fornece uma maneira de limpar todas as conexões de cliente.
Importante
Se você reinicializar o cache para limpar as conexões de cliente, o StackExchange.Redis se reconectará automaticamente quando o nó do Redis estiver online novamente. Se o problema subjacente não for resolvido, as conexões de cliente continuarão a ser usadas.
Perderei dados do cache se eu fizer uma reinicialização?
Se você reinicializar os nós Primário e Réplica, todos os dados no cache, ou todos os dados nesse fragmento quando você estiver usando um cache premium com o clustering ativado, devem estar seguros. Porém, em alguns casos, os dados podem ser perdidos. A reinicialização de ambos os nós deve ser feita com cautela.
Se você reinicializar apenas um dos nós, normalmente os dados não serão perdidos, mas isso ainda poderá ocorrer. Por exemplo, se o nó primário for reinicializado e uma gravação em cache estiver em andamento, os dados da gravação em cache serão perdidos. Outro cenário de perda de dados seria se você reinicializasse um nó e o outro nó ficasse inoperante devido a uma falha ao mesmo tempo.
Você também deve saber que a reinicialização de ambos os nós não resulta na liberação dos dados. Se você quiser limpar dados, use o procedimento de liberação do console do portal.
Posso reinicializar o cache usando o PowerShell, a CLI ou outras ferramentas de gerenciamento?
Sim, para ver as instruções do PowerShell, consulte Para reinicializar um Cache Redis do Azure.
Posso reinicializar meu cache de Enterprise?
Não. A reinicialização ainda não está disponível para a camada de Enterprise. A reinicialização está disponível para as camadas Basic, Standard e Premium. As configurações que você vê no menu Recurso em Administração dependem da camada do cache. Você não vê Reinicializar ao usar um cache da camada de Enterprise.
Liberar dados
Ao usar os níveis Básico, Standard ou Premium do Redis Gerenciado do Azure, você visualizará Liberar dados no menu de recursos. A operação Liberar dados permite que você exclua ou libere todos os dados no seu cache. Essa operação de liberação pode ser usada antes de escalar as operações de dimensionamento para reduzir potencialmente o tempo necessário para concluir a operação de dimensionamento no cache. Você também pode configurar para executar a operação de liberação periodicamente nos seus caches de desenvolvimento/teste para manter o uso de memória em marcar.
A operação de liberação, quando executada em um cache clusterizado, limpa os dados de todos os fragmentos ao mesmo tempo.
Importante
Anteriormente, a operação de liberação só estava disponível para os caches do nível Enterprise replicados geograficamente. Agora, ele está disponível nas camadas Básico, Standard e Premium.
Atualizar o canal e agendar atualizações
À esquerda, Agendar atualizações permite que você escolha um canal de atualização e uma janela de manutenção para sua instância de cache.
Qualquer instância de cache que usa o canal de atualização Estável recebe atualizações algumas semanas depois das instâncias de cache usando o canal de atualização de Versão prévia. Recomendamos escolher o canal de atualização Versão prévia suas cargas de trabalho não produtivas e menos críticas. Escolha o canal de atualização Estável para suas cargas de trabalho de produção mais críticas. Todos os caches são padronizados no canal de atualização Estável por padrão.
Importante
A alteração do canal de atualização na instância de cache faz com que o cache passe por um evento de aplicação de patch para aplicar as atualizações corretas. Considere alterar o canal de atualização durante a janela de manutenção.
Uma janela de manutenção permite que você controle os dias e as horas de uma semana durante as quais as VMs que hospedam seu cache podem ser atualizadas. O Redis Gerenciado do Azure realizará os melhores esforços para iniciar e concluir a atualização do software do servidor Redis na janela de tempo especificada que você definir.
Importante
A janela de manutenção aplica-se às atualizações do servidor Redis e do sistema operacional das VMs que hospedam o cache. Ela não se aplica às atualizações do sistema operacional do Host nos Hosts que hospedam as VMs de cache ou outros componentes da Rede do Azure. Em casos raros, onde os caches são hospedados em modelos mais antigos, a janela de manutenção também não se aplica às atualizações do sistema operacional Convidado. Você pode saber se seu cache está em um modelo mais antigo se o nome DNS do cache for resolvido em um sufixo de cloudapp.net
, chinacloudapp.cn
, usgovcloudapi.net
ou cloudapi.de
.
Atualmente, nenhuma opção está disponível para configurar uma reinicialização ou atualizações agendadas para um cache da camada Enterprise.
Para especificar uma janela de manutenção, marque os dias que você deseja, especifique a hora de início da janela de manutenção para cada dia. Depois, selecione OK. O tempo da janela de manutenção está em UTC e só pode ser configurado por hora.
A janela de manutenção padrão e mínima para atualizações é de cinco horas. Esse valor não é configurável no portal do Azure, mas você pode configurá-lo no PowerShell usando o parâmetro MaintenanceWindow
do cmdlet New-AzRedisCacheScheduleEntry. Para saber mais, confira Posso gerenciar as atualizações agendadas usando o PowerShell, a CLI ou outras ferramentas de gerenciamento?
Perguntas frequentes sobre agendamento de atualizações
- Quando as atualizações ocorrerão se eu não usar o recurso de agendamento de atualizações?
- Que tipos de atualizações são feitas durante a janela de manutenção agendada?
- Posso gerenciar as atualizações agendadas usando o PowerShell, a CLI ou outras ferramentas de gerenciamento?
- Uma atualização coberta e gerenciada pelo recurso "Atualizações Agendadas" pode ocorrer fora da janela "Atualizações Agendadas"?
Quando as atualizações ocorrerão se eu não usar o recurso de agendamento de atualizações?
Se você não especificar uma janela de manutenção, as atualizações poderão ser feitas a qualquer momento.
Que tipos de atualizações são feitas durante a janela de manutenção agendada?
Apenas as atualizações do servidor Redis são realizadas durante a janela de manutenção agendada. A janela de manutenção se aplica a atualizações do Azure ou do sistema operacional do host.
Posso gerenciar as atualizações agendadas usando o PowerShell, a CLI ou outras ferramentas de gerenciamento?
Sim, você pode gerenciar as atualizações agendadas usando os cmdlets do PowerShell a seguir:
- Get-AzRedisCachePatchSchedule
- New-AzRedisCachePatchSchedule
- New-AzRedisCacheScheduleEntry
- Remove-AzRedisCachePatchSchedule
Uma atualização coberta e gerenciada pelo recurso Atualizações Agendadas pode ocorrer fora da janela Atualizações Agendadas?
Sim. Em geral, as atualizações não são aplicadas fora da janela Atualizações Agendadas configuradas. As raras atualizações de segurança críticas podem ser aplicadas fora do agendamento de aplicação de patch como parte de nossa política de segurança.