Configurar suporte de rede virtual (VNet) para uma instância do Cache Premium do Azure para Redis

A implantação da Rede Virtual do Azure fornece segurança e isolamento aprimorados, juntamente com: sub-redes, políticas de controle de acesso e outros recursos para restringir ainda mais o acesso. Quando uma instância do Cache Redis do Azure é configurada com uma rede virtual, ela não é endereçável publicamente. Em vez disso, a instância só pode ser acessada de máquinas virtuais e aplicativos dentro da rede virtual. Este artigo descreve como configurar o suporte de rede virtual para uma instância de Cache do Azure para Redis de camada Premium.

Limitações da injeção de VNet

• Criar e manter configurações de rede virtual geralmente são propensos a erros. A solução de problemas também é um desafio. Configurações de rede virtual incorretas podem causar problemas:
  • Transmissão de métricas obstruída de suas instâncias de cache
  • Falha do nó de réplica para replicar dados do nó primário
  • potencial perda de dados
  • falha de operações de gerenciamento, como dimensionamento
  • nos cenários mais graves, perda de disponibilidade
• Os caches injetados de VNet só estão disponíveis para o Cache do Azure para Redis de camada Premium, não para outras camadas.
• Ao usar um cache injetado de VNet, você deve alterar sua VNet para dependências de cache, como CRLs/PKI, AKV, Armazenamento do Azure, Azure Monitor e muito mais.
• Não é possível injetar uma instância existente do Cache do Azure para Redis em uma Rede Virtual. Você deve selecionar essa opção ao criar o cache.

Configurar o suporte de rede virtual

O suporte de rede virtual é configurado no painel Novo Cache do Azure para Redis durante a criação do cache.

1. Para criar um cache de camada Premium, entre no portal do Azure e selecione Criar um recurso. Você também pode criá-los usando modelos do Gerenciador de Recursos, PowerShell ou a CLI do Azure. Para obter mais informações sobre como criar uma instância do Cache do Azure para Redis, consulte Criar um cache.

   

2. Na página Novo, selecione Bancos de dados. Em seguida, selecione Cache do Azure para Redis.

   

3. Na página Novo Cache Redis, defina as configurações para o novo cache de camada Premium.

   Definição	Valor sugerido	Description
   Nome DNS	Introduza um nome globalmente exclusivo.	O nome do cache deve ser uma cadeia de caracteres entre 1 e 63 caracteres que contenha apenas números, letras ou hífenes. O nome deve começar e terminar com um número ou letra, e não pode conter hífenes consecutivas. O nome do host da instância de cache será \<DNS name>.redis.cache.windows.net.
   Subscrição	Selecione sua assinatura na lista suspensa.	A assinatura sob a qual criar essa nova instância do Cache do Azure para Redis.
   Grupo de recursos	Selecione um grupo de recursos na lista suspensa ou selecione Criar novo e insira um novo nome de grupo de recursos.	O nome do grupo de recursos no qual criar o cache e outros recursos. Ao colocar todos os recursos do seu aplicativo em um grupo de recursos, você pode facilmente gerenciá-los ou excluí-los juntos.
   Location	Selecione um local na lista suspensa.	Selecione uma região perto de outros serviços que usarão seu cache.
   Tipo de cache	Selecione um cache de camada Premium na lista suspensa para configurar os recursos de camada Premium. Para obter mais informações, consulte Preços do Cache do Azure para Redis.	O escalão de preço determina o tamanho, o desempenho e as funcionalidades que estão disponíveis para a cache. Para obter mais informações, consulte Visão geral do Cache do Azure para Redis.

4. Selecione a guia Rede ou selecione o botão Rede na parte inferior da página.

5. Na guia Rede, selecione Redes Virtuais como seu método de conectividade. Para usar uma nova rede virtual, crie-a primeiro seguindo as etapas em Criar uma rede virtual usando o portal do Azure ou Criar uma rede virtual (clássica) usando o portal do Azure. Em seguida, retorne ao painel Novo Cache do Azure para Redis para criar e configurar seu cache de camada Premium.

   Importante

   Quando você implanta o Cache Redis do Azure em uma rede virtual do Gerenciador de Recursos, o cache deve estar em uma sub-rede dedicada que não contenha outros recursos, exceto instâncias do Cache do Azure para Redis. Se tentar implementar uma instância da Cache do Azure para Redis numa sub-rede de rede virtual do Resource Manager que contenha outros recursos ou tenha um NAT Gateway atribuído, a implementação falha. A falha ocorre porque o Cache Redis do Azure usa um balanceador de carga básico que não é compatível com um Gateway NAT.

   Definição	Valor sugerido	Description
   Rede virtual	Selecione sua rede virtual na lista suspensa.	Selecione uma rede virtual que esteja na mesma assinatura e local do cache.
   Sub-rede	Selecione sua sub-rede na lista suspensa.	O intervalo de endereços da sub-rede deve estar na notação CIDR (por exemplo, 192.168.1.0/24). Ele deve ser contido pelo espaço de endereço da rede virtual.
   Endereço IP estático	(Opcional) Insira um endereço IP estático.	Se você não especificar um endereço IP estático, um endereço IP será escolhido automaticamente.

   Importante

   O Azure reserva alguns endereços IP dentro de cada sub-rede, e estes endereços não podem ser utilizados. O primeiro e o último endereço IP das sub-redes são reservados para conformidade com o protocolo, juntamente com três outros endereços utilizados para os servidores do Azure. Para obter mais informações, veja Existem restrições à utilização de endereços IP nestas sub-redes?

   Para além dos endereços IP utilizados pela infraestrutura de rede virtual do Azure, cada instância da Cache do Azure para Redis na sub-rede utiliza dois endereços IP por extensão e um endereço IP adicional para o balanceador de carga. Uma cache sem cluster é considerada como tendo uma extensão.

6. Selecione a guia Avançar: Avançado ou selecione o botão Avançar: Avançado na parte inferior da página.

7. Na guia Avançado para uma instância de cache de camada Premium, defina as configurações para porta não-TLS, clustering e persistência de dados.

8. Selecione a guia Next: Tags ou selecione o botão Next: Tags na parte inferior da página.

9. Opcionalmente, na guia Marcas , insira o nome e o valor se quiser categorizar o recurso.

10. Selecione Rever + criar. Você é levado para a guia Revisão + criação, onde o Azure valida sua configuração.

11. Depois que a mensagem verde Validação passada for exibida, selecione Criar.

Demora um pouco para o cache ser criado. Você pode monitorar o progresso na página Visão geral do Cache do Azure para Redis. Quando Status é exibido como Em execução, o cache está pronto para uso. Depois que o cache for criado, você poderá exibir a configuração da rede virtual selecionando Rede Virtual no menu Recurso.

FAQ sobre a rede virtual da Cache do Azure para Redis

A lista a seguir contém respostas para perguntas frequentes sobre o Cache do Azure para rede Redis.

• Quais são alguns problemas comuns de configuração incorreta com o Cache Redis do Azure e redes virtuais?
• Como posso verificar se meu cache está funcionando em uma rede virtual?
• Quando tento me conectar à minha instância do Cache Redis do Azure em uma rede virtual, por que recebo um erro informando que o certificado remoto é inválido?
• Posso usar redes virtuais com um cache padrão ou básico?
• Por que a criação de uma instância do Cache do Azure para Redis falha em algumas sub-redes, mas não em outras?
• Quais são os requisitos de espaço de endereço da sub-rede?
• Posso me conectar ao meu cache a partir de uma rede virtual emparelhada?
• Há suporte para injeção de VNet em um cache onde o Azure Lighthouse está habilitado?
• Todos os recursos de cache funcionam quando um cache é hospedado em uma rede virtual?
• Há suporte para injeção de VNet em um cache onde o Azure Lighthouse está habilitado?

Quais são alguns problemas comuns de configuração incorreta com o Cache Redis do Azure e redes virtuais?

Quando o Cache Redis do Azure é hospedado em uma rede virtual, as portas nas tabelas a seguir são usadas.

• Requisitos de porta de saída
• Requisitos de porta de entrada

Requisitos de porta de saída

Há nove requisitos de porta de saída. As solicitações de saída nesses intervalos são: a) de saída para outros serviços necessários para o funcionamento do cache ou b) internas à sub-rede Redis para comunicação interno. Para replicação geográfica, existem outros requisitos de saída para comunicação entre sub-redes do cache primário e de réplica.

1 Você pode usar as tags de serviço AzureKeyVault e AzureMonitor com NSGs (grupos de segurança de rede) do Gerenciador de Recursos.

2 Esses endereços IP de propriedade da Microsoft são usados para endereçar a VM host que serve o DNS do Azure.

3 Essas informações não são necessárias para sub-redes sem servidor DNS personalizado ou caches Redis mais recentes que ignoram o DNS personalizado.

4 Para obter mais informações, consulte Requisitos adicionais de conectividade de rede virtual.

Requisitos da porta do elemento de rede de georreplicação

Se você estiver usando a replicação geográfica entre caches em redes virtuais do Azure: a) desbloqueie as portas 15000-15999 para toda a sub-rede nas direções de entrada e saída e b) para ambos os caches. Com essa configuração, todos os componentes da réplica na sub-rede podem se comunicar diretamente entre si, mesmo que haja um futuro failover geográfico.

Requisitos de porta de entrada

Há oito requisitos de intervalo de portas de entrada. As solicitações de entrada nesses intervalos são entradas de outros serviços hospedados na mesma rede virtual. Ou são internos às comunicações da sub-rede Redis.

1 Você pode usar a marca de serviço AzureLoadBalancer para o Gerenciador de Recursos ou AZURE_LOADBALANCER para o modelo de implantação clássico para criar as regras NSG.

Requisitos adicionais de conectividade de rede virtual

Há requisitos de conectividade de rede para o Cache Redis do Azure que podem não ser atendidos inicialmente em uma rede virtual. O Cache Redis do Azure requer que todos os seguintes itens funcionem corretamente quando usados em uma rede virtual:

• Conectividade de rede de saída para pontos de extremidade do Azure Key Vault em todo o mundo. Os pontos de extremidade do Azure Key Vault são resolvidos no domínio vault.azure.netDNS .
• Conectividade de rede de saída para pontos de extremidade do Armazenamento do Azure em todo o mundo. Os pontos de extremidade localizados na mesma região que a instância do Cache Redis do Azure e os pontos de extremidade de armazenamento localizados em outras regiões do Azure estão incluídos. Os pontos de extremidade do Armazenamento do Azure são resolvidos nos seguintes domínios DNS: table.core.windows.net, blob.core.windows.net, queue.core.windows.nete file.core.windows.net.
• Conectividade de rede de saída para , , , , mscrl.microsoft.com, cacerts.digicert.comcrl3.digicert.com, oneocsp.microsoft.come crl.microsoft.com. ocsp.msocsp.comcrl4.digicert.comocsp.digicert.com Esta conectividade é necessária para suportar a funcionalidade TLS/SSL.
• A configuração de DNS para a rede virtual deve ser capaz de resolver todos os pontos de extremidade e domínios mencionados nos pontos anteriores. Esses requisitos de DNS podem ser atendidos garantindo que uma infraestrutura DNS válida seja configurada e mantida para a rede virtual.
• Conectividade de rede de saída para os seguintes pontos de extremidade do Azure Monitor, que são resolvidos nos seguintes domínios DNS: shoebox2-black.shoebox2.metrics.nsatc.net, north-prod2.prod2.metrics.nsatc.net, azglobal-black.azglobal.metrics.nsatc.net, shoebox2-red.shoebox2.metrics.nsatc.net, east-prod2.prod2.metrics.nsatc.net, azglobal-red.azglobal.metrics.nsatc.net, shoebox3.prod.microsoftmetrics.com, shoebox3-red.prod.microsoftmetrics.com, shoebox3-black.prod.microsoftmetrics.comazredis-red.prod.microsoftmetrics.com e azredis-black.prod.microsoftmetrics.com.

Como posso verificar se meu cache está funcionando em uma rede virtual?

Depois que os requisitos de porta são configurados conforme descrito na seção anterior, uma reinicialização é necessária na maioria dos casos para garantir que as alterações reflitam corretamente. Caso contrário, poderá ter alguns problemas de conectividade. Você pode verificar se o cache está funcionando seguindo estas etapas:

• Reinicialize todos os nós de cache. O cache não poderá ser reiniciado com êxito se não for possível alcançar todas as dependências de cache necessárias---conforme documentado em Requisitos de porta de entrada e Requisitos de porta de saída.
• Depois que os nós de cache forem reiniciados, conforme relatado pelo status do cache no portal do Azure, você poderá fazer os seguintes testes:

  • Execute ping no ponto de extremidade do cache usando a porta 6380 de uma máquina que esteja na mesma rede virtual que o cache, usando tcping. Por exemplo:

    tcping.exe contosocache.redis.cache.windows.net 6380

    Se a tcping ferramenta informar que a porta está aberta, o cache estará disponível para conexão de clientes na rede virtual.

  • Outra maneira de testar: crie um cliente de cache de teste que se conecte ao cache e, em seguida, adicione e recupere alguns itens do cache. O cliente de cache de teste pode ser um aplicativo de console usando StackExchange.Redis. Instale o aplicativo cliente de exemplo em uma VM que esteja na mesma rede virtual que o cache. Em seguida, execute-o para verificar a conectividade com o cache.

Quando tento me conectar à minha instância do Cache Redis do Azure em uma rede virtual, por que recebo um erro informando que o certificado remoto é inválido?

Quando você tenta se conectar a uma instância do Cache Redis do Azure em uma rede virtual, você vê um erro de validação de certificado como este:

{"No connection is available to service this operation: SET mykey; The remote certificate is invalid according to the validation procedure.; …"}

A causa pode ser que você está se conectando ao host pelo endereço IP. Recomendamos que você use o nome do host. Em outras palavras, use a seguinte cadeia de caracteres:

[mycachename].redis.cache.windows.net:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

Evite usar o endereço IP semelhante à seguinte cadeia de conexão:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False

Se você não conseguir resolver o nome DNS, algumas bibliotecas de cliente incluem opções de configuração como sslHost, que é fornecido pelo cliente StackExchange.Redis. Essa opção permite que você substitua o nome do host usado para validação de certificado. Por exemplo:

10.128.2.84:6380,password=xxxxxxxxxxxxxxxxxxxx,ssl=True,abortConnect=False;sslHost=[mycachename].redis.cache.windows.net

Posso usar redes virtuais com um cache padrão ou básico?

As redes virtuais só podem ser usadas com caches de nível Premium.

Por que a criação de uma instância do Cache do Azure para Redis falha em algumas sub-redes, mas não em outras?

Se você estiver implantando uma instância do Cache Redis do Azure em uma rede virtual, o cache deverá estar em uma sub-rede dedicada que não contenha nenhum outro tipo de recurso. Se for feita uma tentativa de implantar uma instância do Cache Redis do Azure em uma sub-rede de rede virtual do Gerenciador de Recursos que contenha outros recursos --- como instâncias do Gateway de Aplicativo do Azure e NA de Saída --- a implantação geralmente falhará. Elimine os recursos existentes de outros tipos antes de criar uma nova instância da Cache do Azure para Redis.

Você também deve ter endereços IP suficientes disponíveis na sub-rede.

Quais são os requisitos de espaço de endereço da sub-rede?

O Azure reserva alguns endereços IP dentro de cada sub-rede, e estes endereços não podem ser utilizados. O primeiro e o último endereço IP das sub-redes são reservados para conformidade com o protocolo, juntamente com três outros endereços utilizados para os servidores do Azure. Para obter mais informações, veja Existem restrições à utilização de endereços IP nestas sub-redes?

Além dos endereços IP usados pela infraestrutura de rede virtual do Azure, cada instância do Cache Redis do Azure na sub-rede usa dois endereços IP por fragmento de cluster, além de endereços IP para réplicas adicionais, se houver. Mais um endereço IP é usado para o balanceador de carga. Considera-se que um cache não clusterizado tem um fragmento.

Posso me conectar ao meu cache a partir de uma rede virtual emparelhada?

Se as redes virtuais estiverem na mesma região, você poderá conectá-las usando emparelhamento de rede virtual ou uma conexão VNET-to-VNET do Gateway VPN.

Se as redes virtuais emparelhadas do Azure estiverem em regiões diferentes : uma VM cliente na região 1 não poderá acessar o cache na região 2 por meio de seu endereço IP com balanceamento de carga devido a uma restrição com balanceadores de carga básicos. Ou seja, a menos que seja um cache com um balanceador de carga padrão, que atualmente é apenas um cache que foi criado com zonas de disponibilidade.

Para obter mais informações sobre restrições de emparelhamento de rede virtual, consulte Rede virtual - Emparelhamento - Requisitos e restrições. Uma solução é usar uma conexão VNET-to-VNET do Gateway VPN em vez do emparelhamento de rede virtual.

Todos os recursos de cache funcionam quando um cache é hospedado em uma rede virtual?

Quando o cache faz parte de uma rede virtual, somente os clientes na rede virtual podem acessar o cache. Como resultado, os seguintes recursos de gerenciamento de cache não funcionam no momento:

• Console Redis: Como o Console Redis é executado em seu navegador local ---geralmente em uma máquina de desenvolvedor que não está conectada à rede virtual---ele não pode se conectar ao cache.

Há suporte para injeção de VNet em um cache onde o Azure Lighthouse está habilitado?

Não, se sua assinatura tiver o Azure Lighthouse habilitado, você não poderá usar a injeção de VNet em uma instância do Cache do Azure para Redis. Em vez disso, use links privados.

Usar a Rota Expressa com o Cache Redis do Azure

Os clientes podem conectar um circuito de Rota Expressa do Azure à infraestrutura de rede virtual. Dessa forma, eles estendem sua rede local para o Azure.

Por padrão, um circuito de Rota Expressa recém-criado não usa túnel forçado (anúncio de uma rota padrão, 0.0.0.0/0) em uma rede virtual. Como resultado, a conectividade de saída com a Internet é permitida diretamente da rede virtual. Os aplicativos cliente podem se conectar a outros pontos de extremidade do Azure, que incluem uma instância do Cache do Azure para Redis.

Uma configuração comum do cliente é usar o túnel forçado (anunciar uma rota padrão), que força o tráfego de saída da Internet a fluir localmente. Esse fluxo de tráfego interrompe a conectividade com o Cache Redis do Azure se o tráfego de saída for bloqueado localmente, de modo que a instância do Cache do Azure para Redis não consiga se comunicar com suas dependências.

A solução é definir uma ou mais rotas definidas pelo usuário (UDRs) na sub-rede que contém a instância do Cache do Azure para Redis. Um UDR define rotas específicas da sub-rede que serão honradas em vez da rota padrão.

Se possível, use a seguinte configuração:

• A configuração da Rota Expressa anuncia 0.0.0.0/0 e, por padrão, força túneis todo o tráfego de saída local.
• O UDR aplicado à sub-rede que contém a instância do Cache Redis do Azure define 0.0.0.0/0 com uma rota de trabalho para o tráfego TCP/IP para a Internet pública. Por exemplo, ele define o próximo tipo de salto como internet.

O efeito combinado dessas etapas é que o UDR no nível da sub-rede tem precedência sobre o túnel forçado da Rota Expressa e garante o acesso de saída à Internet a partir da instância do Cache Redis do Azure.

Conectar-se a uma instância do Cache Redis do Azure a partir de um aplicativo local usando a Rota Expressa não é um cenário de uso típico por motivos de desempenho. Para obter o melhor desempenho, os clientes do Cache do Azure para Redis devem estar na mesma região que a instância do Cache do Azure para Redis.

Informações básicas sobre UDRs estão disponíveis em Roteamento de tráfego de rede virtual.

Para obter mais informações sobre a Rota Expressa, consulte Visão geral técnica da Rota Expressa.

Conteúdos relacionados

Saiba mais sobre os recursos do Cache do Azure para Redis.

• Camadas de serviço do Cache do Azure para Redis Premium