Como administrar o Azure Managed Redis (visualização)
Este artigo descreve como executar tarefas de administração, como reinicializar e atualizar o canal e agendar atualizações para suas instâncias do Azure Managed Redis (visualização).
Reiniciar
À esquerda, Reboot permite reinicializar um ou mais nós do cache. Esse recurso de reinicialização permite que você teste sua aplicação quanto à resiliência se houver uma falha de um nó de cache.
Importante
A reinicialização ainda não está disponível para a camada Enterprise. A reinicialização está disponível para todas as outras camadas.
Selecione os nós a serem reinicializados e selecione Reinicializar.
Se você tiver um cache premium com clustering habilitado, poderá selecionar quais fragmentos do cache serão reinicializados.
Para reinicializar um ou mais nós do cache, selecione os nós e selecione Reinicializar. Se você tiver um cache premium com clustering habilitado, selecione os fragmentos a serem reinicializados e, em seguida, selecione Reinicializar. Após alguns minutos, os nós selecionados são reinicializados e ficam online novamente alguns minutos depois.
O efeito em seus aplicativos cliente varia dependendo de quais nós você reinicializa.
- Primário - Quando o nó primário é reinicializado, o Azure Managed Redis realiza failover para o nó da réplica e o promove para primário. Durante esse failover, pode haver um curto intervalo no qual as conexões com o cache podem falhar.
- Réplica - Quando o nó da réplica é reinicializado, normalmente não há efeito nos clientes de cache.
- Primário e réplica - Quando ambos os nós de cache são reinicializados, o Azure Managed Redis tenta reinicializar normalmente ambos os nós, aguardando que um termine antes de reinicializar o outro. Normalmente, a perda de dados não ocorre. No entanto, a perda de dados ainda pode ocorrer devido a eventos de manutenção inesperados ou falhas. Reinicializar o cache muitas vezes seguidas 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 clustering habilitado, o comportamento para os nós selecionados é o mesmo que quando você reinicializa o nó ou nós correspondentes de um cache não clusterizado.
Perguntas frequentes sobre a reinicialização
- Qual nó devo reiniciar para testar meu aplicativo?
- Posso reiniciar o cache para limpar as conexões do cliente?
- Vou perder dados do meu cache se eu fizer uma reinicialização?
- Posso reinicializar meu cache usando PowerShell, CLI ou outras ferramentas de gerenciamento?
- Posso reiniciar meu cache Enterprise?
Qual nó devo reiniciar para testar meu aplicativo?
Para testar a resiliência do seu aplicativo contra falha do nó primário do cache, reinicialize o nó primário . Para testar a resiliência do seu aplicativo contra falha do nó da réplica, reinicialize o nó da réplica .
Posso reiniciar o cache para limpar as conexões do cliente?
Sim, se você reinicializar o cache, todas as conexões do cliente serão limpas. A reinicialização pode ser útil no caso em que todas as conexões de cliente são usadas devido a um erro de lógica ou um bug no aplicativo cliente. Cada camada de preço tem limites de conexão de cliente diferentes para os vários tamanhos e, uma vez que esses limites são atingidos, não são aceitas mais conexões de cliente. Reinicializar o cache fornece uma maneira de limpar todas as conexões do cliente.
Importante
Se você reinicializar o cache para limpar as conexões do cliente, o StackExchange.Redis se reconectará automaticamente assim que o nó Redis estiver online novamente. Se o problema subjacente não for resolvido, as conexões do cliente podem continuar a ser utilizadas.
Vou perder dados do meu 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 clustering habilitado deverão estar seguros. No entanto, os dados podem ser perdidos em alguns casos. A reinicialização de ambos os nós deve ser tomada com cuidado.
Se você reinicializar apenas um dos nós, os dados normalmente não são perdidos, mas ainda podem ser. Por exemplo, se o nó primário for reinicializado e uma gravação de cache estiver em andamento, os dados da gravação de cache serão perdidos. Outro cenário para perda de dados seria se você reinicializar um nó e o outro nó cair devido a uma falha ao mesmo tempo.
Você também deve saber que a reinicialização de ambos os nós não resulta em liberação de dados. Se você quiser limpar dados, use o procedimento de liberação do console do portal.
Posso reinicializar meu cache usando PowerShell, CLI ou outras ferramentas de gerenciamento?
Sim, para obter instruções do PowerShell, consulte Para reinicializar um Cache do Azure para Redis.
Posso reiniciar meu cache Enterprise?
N.º A reinicialização ainda não está disponível para a camada Enterprise. A reinicialização está disponível para as camadas Basic, Standard e Premium. As configurações exibidas no menu Recurso em Administração dependem da camada do cache. Você não vê Reinicializar ao usar um cache da camada Enterprise.
Liberar dados
Ao usar as camadas Basic, Standard ou Premium do Azure Managed Redis, você verá Liberar dados no menu de recursos. A operação Liberar dados permite que você exclua ou libere todos os dados em seu cache. Essa operação de liberação pode ser usada antes das 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 em seus caches de desenvolvimento/teste para manter o uso de memória sob controle.
A operação de liberação , quando executada em um cache clusterizado, limpa dados de todos os fragmentos ao mesmo tempo.
Importante
Anteriormente, a operação de liberação só estava disponível para caches de camada Enterprise replicados geograficamente. Agora, está disponível nos níveis Basic, Standard e Premium.
Atualizar 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 usando o canal de atualização estável recebe atualizações algumas semanas depois do que as instâncias de cache usando o canal de atualização de visualização. Recomendamos escolher o canal de atualização de visualização para 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 para o canal de atualização estável por padrão.
Importante
Alterar o canal de atualização na instância de cache resulta em um evento de aplicação de patches 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 controlar os dias e horários de uma semana durante os quais as VMs que hospedam seu cache podem ser atualizadas. O Azure Managed Redis faz um esforço ao máximo para iniciar e concluir a atualização do software de servidor Redis dentro da janela de tempo especificada que você definir.
Importante
O canal de atualização e a janela de manutenção se aplicam às atualizações do servidor Redis e às atualizações do sistema operacional das VMs que hospedam o cache. O canal de atualização e a janela de manutenção não se aplicam às atualizações do sistema operacional host para os hosts que hospedam as VMs de cache ou outros componentes de rede do Azure. Em casos raros, quando os caches são hospedados em modelos mais antigos, a janela de manutenção também não se aplica às atualizações do SO convidado. Você pode saber se o cache está em um modelo mais antigo se o nome DNS do cache for resolvido para um sufixo de cloudapp.net
, usgovcloudapi.net
chinacloudapp.cn
ou cloudapi.de
.
Atualmente, nenhuma opção está disponível para configurar um canal de atualização ou atualizações agendadas para um cache de camada Enterprise.
Para especificar uma janela de manutenção, verifique os dias desejados e especifique a hora de início da janela de manutenção para cada dia. Em seguida, selecione OK. O tempo da janela de manutenção está em UTC e só pode ser configurado de hora em 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 MaintenanceWindow
parâmetro do cmdlet New-AzRedisCacheScheduleEntry . Para obter mais informações, consulte Posso gerenciar atualizações agendadas usando PowerShell, CLI ou outras ferramentas de gerenciamento?
Perguntas frequentes sobre atualizações de agendamento
- Quando ocorrem as atualizações se eu não usar o recurso de agendamento de atualizações?
- Que tipo de atualizações são feitas durante a janela de manutenção programada?
- Posso gerenciar atualizações agendadas usando PowerShell, CLI ou outras ferramentas de gerenciamento?
- Uma atualização coberta e gerenciada pelo recurso "Atualizações agendadas" pode acontecer fora da janela "Atualizações agendadas"?
Quando ocorrem as atualizações 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 podem ser feitas a qualquer momento.
Que tipo de atualizações são feitas durante a janela de manutenção programada?
Somente as atualizações do servidor Redis são feitas durante a janela de manutenção agendada. A janela de manutenção não se aplica a atualizações do Azure ou atualizações do sistema operacional host.
Posso gerenciar atualizações agendadas usando PowerShell, CLI ou outras ferramentas de gerenciamento?
Sim, você pode gerenciar suas atualizações agendadas usando os seguintes cmdlets do PowerShell:
- Get-AzRedisCachePatchSchedule
- New-AzRedisCachePatchSchedule
- New-AzRedisCacheScheduleEntry
- Remove-AzRedisCachePatchSchedule
Uma atualização coberta e gerenciada pelo recurso Atualizações Agendadas pode acontecer fora da janela Atualizações Agendadas?
Sim. Em geral, as atualizações não são aplicadas fora da janela Atualizações agendadas configurada. Atualizações de segurança críticas raras podem ser aplicadas fora do cronograma de aplicação de patches como parte de nossa política de segurança.