Partilhar via

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

  • Artigo

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.

Nota

O modelo de implantação clássico será desativado em agosto de 2024. Para obter mais informações, consulte O modelo de implantação (clássico) dos Serviços de Nuvem será desativado em 31 de agosto de 2024.

Importante

O Cache Redis do Azure recomenda o uso do Azure Private Link, que simplifica a arquitetura de rede e protege a conexão entre pontos de extremidade no Azure. Pode ligar-se a uma instância da Cache do Azure a partir da rede virtual através de um ponto final privado, que é atribuído a um endereço IP privado numa sub-rede na rede virtual. O Azure Private Link é oferecido em todas as nossas camadas, inclui o suporte para o Azure Policy e a gestão simplificada de regras do NSG. Para saber mais, veja a Documentação do Private Link. Para migrar as caches injetadas da VNet para o Private Link, veja Migrar das caches de injeção da VNet para as caches do Private Link.

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.

    Captura de ecrã que mostra Criar um recurso.

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

    Captura de tela que mostra a seleção do 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.

Rede virtual

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?

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

Importante

Se as portas nas tabelas a seguir estiverem bloqueadas, o cache pode não funcionar corretamente. Ter uma ou mais dessas portas bloqueadas é o problema de configuração incorreta mais comum quando você usa o Cache Redis do Azure em uma rede virtual.

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.

Portas Direção Protocolo de transporte Propósito Local IP Endereço IP remoto
80, 443 Saída TCP Dependências do Redis no Armazenamento/PKI do Azure (internet) (sub-rede Redis) * 4
443 Saída TCP Dependência do Redis no Azure Key Vault e no Azure Monitor (sub-rede Redis) AzureKeyVault, AzureMonitor 1
53 De Saída TCP/UDP Dependências Redis no DNS (internet/rede virtual) (sub-rede Redis) 168.63.129.16 e 169.254.169.254 2 e qualquer servidor DNS personalizado para a sub-rede 3
8443 Saída TCP Comunicações internas para Redis (sub-rede Redis) (sub-rede Redis)
10221-10231 Saída TCP Comunicações internas para Redis (sub-rede Redis) (sub-rede Redis)
20226 Saída TCP Comunicações internas para Redis (sub-rede Redis) (sub-rede Redis)
13000-13999 Saída TCP Comunicações internas para Redis (sub-rede Redis) (sub-rede Redis)
15000-15999 Saída TCP Comunicações internas para Redis e replicação geográfica (sub-rede Redis) (sub-rede Redis) (Sub-rede de pares de réplica geográfica)
6379-6380 Saída TCP Comunicações internas para Redis (sub-rede Redis) (sub-rede Redis)

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.

Portas Direção Protocolo de transporte Propósito Local IP Endereço IP remoto
6379, 6380 Interna TCP Comunicação do cliente com Redis, balanceamento de carga do Azure (sub-rede Redis) (sub-rede Redis), (sub-rede cliente), AzureLoadBalancer 1
8443 Interna TCP Comunicações internas para Redis (sub-rede Redis) (sub-rede Redis)
8500 Interna TCP/UDP Balanceamento de carga do Azure (sub-rede Redis) AzureLoadBalancer
10221-10231 Interna TCP Comunicação do cliente para Clusters Redis, comunicações internas para Redis (sub-rede Redis) (sub-rede Redis), (sub-rede cliente), AzureLoadBalancer
13000-13999 Interna TCP Comunicação do cliente com Clusters Redis, balanceamento de carga do Azure (sub-rede Redis) (sub-rede Redis), (sub-rede cliente), AzureLoadBalancer
15000-15999 Interna TCP Comunicação do cliente com Clusters Redis, balanceamento de carga do Azure e replicação geográfica (sub-rede Redis) (sub-rede Redis), (sub-rede cliente), AzureLoadBalancer, (sub-rede de peer de réplica geográfica)
16001 Interna TCP/UDP Balanceamento de carga do Azure (sub-rede Redis) AzureLoadBalancer
20226 Interna TCP Comunicações internas para Redis (sub-rede Redis) (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?

Importante

Quando você se conecta a uma instância do Cache Redis do Azure hospedada em uma rede virtual, seus clientes de cache devem estar na mesma rede virtual ou em uma rede virtual com emparelhamento de rede virtual habilitado na mesma região do Azure. O peering de rede virtual global não é atualmente suportado. Este requisito aplica-se a quaisquer aplicações de teste ou ferramentas de pinging de diagnóstico. Independentemente do local onde a aplicação cliente está alojada, os NSGs ou outras camadas de rede têm de estar configuradas de modo a que o tráfego de rede do cliente esteja autorizado a aceder à instância da Cache do Azure para Redis.

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.

Importante

As rotas definidas em um UDR devem ser específicas o suficiente para ter precedência sobre quaisquer rotas anunciadas pela configuração de Rota Expressa. O exemplo a seguir usa o amplo intervalo de endereços 0.0.0.0/0 e, como tal, pode ser acidentalmente substituído por anúncios de rota que usam intervalos de endereços mais específicos.

Aviso

O Cache Redis do Azure não é suportado com configurações de Rota Expressa que anunciam rotas cruzadas incorretamente do caminho de emparelhamento público para o caminho de emparelhamento privado. As configurações de Rota Expressa que têm emparelhamento público configurado recebem anúncios de rota da Microsoft para um grande conjunto de intervalos de endereços IP do Microsoft Azure. Se esses intervalos de endereços forem anunciados incorretamente no caminho de emparelhamento privado, o resultado será que todos os pacotes de rede de saída da sub-rede da instância do Cache do Azure para Redis serão encapsulados incorretamente para a infraestrutura de rede local de um cliente. Esse fluxo de rede interrompe o Cache do Azure para Redis. A solução para esse problema é parar as rotas de publicidade cruzada do caminho de emparelhamento público para o caminho de emparelhamento privado.

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.