Editar

FAQ da Cache do Azure para Redis

Alteração de licenciamento do Redis

Quais são as alterações feitas no licenciamento Redis?

O projeto de código aberto Redis foi alterado para um modelo de licença dupla com suporte para a Licença Disponível de Origem Redis versão 2 (RSALv2) ou Licença Pública do Lado do Servidor versão 1 (SSPLv1). Consulte o comunicado de imprensa do Redis para obter mais informações. Consulte também a postagem do blog da Microsoft sobre a alteração de licenciamento do Redis.

O Cache do Azure para Redis agora também é coberto pelas licenças RSALv2 e SSPLv1?

Não, o Cache Redis do Azure é oferecido aos clientes sob os termos de serviço da Microsoft. As licenças RSALv2 e SSPLv1 não se aplicam ao seu uso do Cache do Azure para Redis.

Minha instância do Cache do Azure para Redis continuará a receber patches e correções de bugs?

Sim, o Cache do Azure para Redis, o Cache do Azure para Redis Enterprise e o Enterprise Flash continuarão a receber patches e correções de bugs mesmo após o anúncio de licenciamento.

O que preciso fazer como cliente do Cache Redis do Azure em resposta a este anúncio de licenciamento?

Não há nenhuma ação necessária para nossos clientes do Azure em relação ao anúncio de licenciamento.

Serviços preteridos

Quais serviços do Cache do Azure para Redis foram preteridos?

  • Serviço de cache gerenciado - O serviço de cache gerenciado foi desativado em 30 de novembro de 2016.

  • Cache na função - O cache na função foi desativado em 30 de novembro de 2016.

Caches com dependência de Serviços de Nuvem (clássico)

O que devo fazer com quaisquer instâncias do Cache Redis do Azure que dependam dos Serviços de Nuvem (clássico)?

Você deve migrar todos os caches com uma dependência dos Serviços de Nuvem (clássico). Em agosto de 2021, anunciamos que os Serviços de Nuvem (clássicos) serão desativados em 31 de agosto de 2024. Todas as instâncias do Cache Redis do Azure que dependem dos Serviços de Nuvem (clássico) precisam ser desativadas até a mesma data.

Você deve migrar caches com uma dependência de Serviços de Nuvem (clássico) antes de 31 de agosto de 2024.

Quantos caches são afetados?

Fizemos um esforço para migrar o maior número possível de caches de forma transparente. Por causa disso, poucos caches e clientes são afetados.

Como sei se um cache foi afetado?

Verifique as Recomendações do Azure Advisor. Se o cache for afetado, você verá uma recomendação na sua assinatura.

Captura de tela que o Consultor recomenda migrar o cache de serviços de nuvem.

Como faço para migrar caches de Serviços de Nuvem (clássicos) para Conjuntos de Dimensionamento de Máquina Virtual do Azure?

Migramos a maioria dos caches de serem criados em Serviços de Nuvem (clássicos) para serem criados em Conjuntos de Escala de Máquinas Virtuais do Azure. A migração para os Conjuntos de Escala de Máquina Virtual do Azure remove a dependência. Há três maneiras de iniciar esse processo para caches em uma rede virtual:

  • Migre para um novo cache usando links privados.

    Crie um novo cache que use o Private Link para isolamento de rede em vez de injeção de rede virtual e migre seus dados para esse cache. Essa opção oferece a melhor e mais segura experiência de isolamento de rede, ao mesmo tempo em que garante que todos os novos caches sejam criados usando a infraestrutura atualizada.

  • Migre para um novo cache em uma nova sub-rede VNet do Azure Resource Manager.

    A criação de um cache em uma VNet clássica cria um cache de Serviços de Nuvem (clássico) e não um cache de Conjuntos de Escala de Máquina Virtual do Azure. A migração para um novo cache em uma nova sub-rede VNet do Azure Resource Manager corrige a dependência subjacente dos Serviços de Nuvem, mantendo uma experiência de rede virtual semelhante.

    Migramos a maioria dos caches de serem criados em Serviços de Nuvem (clássicos) para serem criados em Conjuntos de Escala de Máquinas Virtuais do Azure. Para migrar, exclua o cache existente e crie um novo cache em uma nova sub-rede VNet do Azure Resource Manager. É altamente recomendável não usar sub-redes antigas durante a migração de caches. Para obter opções recomendadas para migrar os dados no cache, consulte Migrar para o Cache do Azure para Redis.

  • Migração automática com perda de dados (recomendado).

    Podemos migrar caches do uso de Serviços de Nuvem (clássico) para o uso de Conjuntos de Dimensionamento de Máquina Virtual automaticamente, com a configuração de cache (incluindo chaves de acesso e nome do host) preservada. No entanto, esse método requer cerca de 30 minutos de tempo de inatividade e perda completa de dados no cache. Você pode usar o recurso de importação/exportação para salvar uma cópia dos dados antes da migração.

    Para utilizar essa opção, entre em contato azurecachemigration@microsoft.com ou crie uma solicitação de suporte para solicitar uma migração.

Meu cache não está usando injeção de VNet, mas recebi um aviso de que preciso migrar. O que devo fazer?

Verifique se o cache está usando a replicação geográfica. Em caso afirmativo, você deve migrar seus dados do seu par replicado geograficamente atual para um novo par replicado geograficamente.

Por exemplo:

  1. Crie um novo par de caches Premium replicados geograficamente que correspondam à mesma configuração do seu par de caches atual.
  2. Desvincule seu par original de caches replicados geograficamente e exporte um arquivo RDB do cache primário.
  3. Importe o arquivo RDB para o cache primário em seu novo par replicado geograficamente.

O novo par de caches replicados geograficamente não terá a mesma dependência dos Serviços de Nuvem.

O que devo fazer se não conseguir criar uma nova instância de cache com a mensagem de erro "a sub-rede é afetada pela desativação dos Serviços de Nuvem"?

Estamos começando a bloquear a criação de novos caches usando o modelo de implantação (clássico) dos Serviços em Nuvem. Novos caches ainda podem ser criados usando esse modelo de implantação antigo se forem criados em uma sub-rede de rede virtual que já continha um cache de Serviços de Nuvem ou se um cache for implantado em uma VNet clássica. Se você vir essa mensagem, crie uma nova sub-rede em sua rede virtual na qual implantar seu cache. Criar uma sub-rede em sua rede virtual garante que um cache seja criado sem a dependência dos Serviços de Nuvem.

Para verificar se você tem um ou mais caches baseados em Serviços de Nuvem em sua sub-rede, você pode verificar o Consultor do Azure no portal ou usar a API REST de links de navegação de recursos. Use a API com sua ID de assinatura, nome do grupo de recursos, nome da resource-navigation-links rede virtual e nome da sub-rede para obter caches nessa sub-rede que estejam usando os Serviços de Nuvem.

Se você estiver criando um novo cache usando a API REST, certifique-se também de que não está passando a redisconfiguração {"CacheVmType": "CloudService"} junto com a solicitação de criação. Esse parâmetro é um parâmetro não documentado, então é improvável que você esteja fazendo isso.

Se você precisar criar novos caches usando o modelo de implantação dos Serviços de Nuvem (clássico), entre em contato azurecachemigration@microsoft.com ou crie uma solicitação de suporte para solicitar uma isenção.

O que acontece se os caches não forem atualizados/migrados até 31 de agosto de 2024?

Esses caches serão desligados e você perderá todos os dados em seus caches.

Qual é o cronograma para o suporte?

A aposentadoria ocorre em três fases para que você tenha o máximo de tempo para migrar:

  1. Estágio Ativo (agora até 30 de abril de 2023)

    Os caches têm suporte total, sem alteração de status a partir de hoje. Este período é dado para permitir que os clientes tenham tempo para fazer a transição do Serviço de Nuvem (clássico) com o mínimo de interrupção.

  2. Estágio de Manutenção (1º de maio de 2023 a 31 de dezembro de 2023)

    Os caches receberão segurança crítica, estabilidade e correções de bugs, mas sem novos recursos.

  3. Estágio Inativo (1º de janeiro de 2024 a 31 de agosto de 2024)

    Os caches recebem apenas correções de segurança críticas. Todos os clientes com problemas de suporte precisam migrar para um cache baseado em VMSS antes de receber suporte. Os clientes devem sair de seus caches até 31 de agosto de 2024.

Imagem de uma linha do tempo que mostra a linha do tempo para desativar os serviços de nuvem (clássico).

Essa linha do tempo se aplica a caches executados no Redis 4.0?

N.º Esta linha do tempo só se aplica a caches executados no Redis 6.0. O Redis 4.0 é uma parte de uma desativação separada que termina antes da aposentadoria (clássica) dos Serviços de Nuvem. Todos os caches restantes usando o Redis 4.0 em Serviços de Nuvem (clássico) serão migrados automaticamente para usar Conjuntos de Escala de Máquina Virtual e Redis 6.0 após 31 de outubro de 2023. Esse método de migração requer tempo de inatividade e perda total de dados no cache, portanto, migre antes dessa data se quiser evitar o tempo de inatividade ou a perda de dados. Entre em contato azurecachemigration@microsoft.com ou crie uma solicitação de suporte para solicitar uma atualização automática antes de 31 de outubro de 2023.

Onde posso obter mais informações se tiver mais dúvidas sobre esta reforma?

Publique qualquer uma das suas perguntas na página de Perguntas e Respostas sobre a desativação (clássica) dos Serviços na Nuvem. Além disso, você pode enviar e-mail para azurecachemigration@microsoft.com para obter mais informações.

Perguntas gerais

E se minha pergunta sobre o Cache Redis do Azure não for respondida aqui?

Se a sua pergunta não estiver listada aqui, informe-nos para que possamos ajudá-lo a encontrar uma resposta.

  • Para alcançar um público mais amplo, você pode postar uma pergunta na página de perguntas e respostas da Microsoft para o Cache do Azure e interagir com a equipe do Cache do Azure e outros membros da comunidade.

  • Se quiser fazer uma solicitação de recurso, você pode enviar suas solicitações e ideias para o Cache do Azure para Redis User Voice.

  • Pode também enviar-nos a sua pergunta para o endereço .azurecache@microsoft.com