Configurar o suporte de rede virtual (VNet) para uma instância do Cache do Azure para Redis Premium
A implantação da Rede Virtual do Azure fornece segurança e isolamento aprimorados junto com: sub-redes, políticas de controle de acesso e outros recursos para restringir ainda mais o acesso. Quando uma instância do Cache do Azure para Redis é configurada com uma rede virtual, ela não pode ser endereçada publicamente. Em vez disso, a instância só pode ser acessada em máquinas virtuais e aplicativos na rede virtual. Este artigo descreve como configurar o suporte de rede virtual para uma instância do Cache do Azure para Redis de Camada Premium.
Observação
O modelo de implantação clássico será desativado em agosto de 2024. Para mais informações, consulte O modelo de implantação de Serviços de Nuvem (clássico) será desativado em 31 de agosto de 2024.
Importante
Cache do Azure para Redis recomenda o uso do Link Privado do Azure, que simplifica a arquitetura de rede e protege a conexão entre os pontos de extremidade no Azure. Você pode se conectar a uma instância de cache do Azure a partir da sua rede virtual por meio de um ponto de extremidade privado, que é atribuído a um endereço IP privado em uma sub-rede dentro da rede virtual. Os Links Privados do Azure são oferecidos em todas as nossas camadas, incluem o suporte do Azure Policy e gerenciamento simplificado de regras NSG. Para saber mais, consulte Documentação do Link Privado do Azure. Para migrar os caches injetados na sua VNet para o Link Privado, consulte Migrar de caches injetados na VNet para caches do Link Privado.
Limitações da injeção de VNet
- A criação e a manutenção de configurações de rede virtual são propensas a erros. A solução de problemas também é desafiadora. Configurações incorretas de rede virtual podem causar problemas:
- transmissão obstruídas de métricas de suas instâncias de cache
- falha do nó de réplica em replicar dados do nó primário
- possível perda de dados
- falha nas operações de gerenciamento, como escalonamento
- falhas intermitentes ou completas de SSL/TLS
- falha ao aplicar atualizações, incluindo melhorias importantes de segurança e confiabilidade
- nos cenários mais graves, a perda de disponibilidade
- Ao usar um cache injetado por VNet, você precisa manter a VNet atualizada para permitir o acesso a dependências de cache, como as listas de certificados revogados, a infraestrutura de chave pública, o Azure Key Vault, o Armazenamento do Azure, o Azure Monitor, entre outros.
- Os caches injetados pela VNet estão disponíveis apenas para o Cache do Azure para Redis de nível Premium, não para outros níveis.
- Você não pode injetar uma instância existente do Cache do Azure para Redis em uma Rede Virtual. Você deve selecionar esta opção ao criar o cache.
Configurar o suporte da rede virtual
O suporte da rede virtual é configurado no painel Novo Cache do Azure para Redis durante a criação do cache.
Para criar um cache de Camada Premium, acesse o portal do Azure e selecione Criar um recurso. Você também pode criá-los usando os modelos do Resource Manager, o 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.
Na página Novo, selecione Bancos de dados. Em seguida, selecione Cache do Azure para Redis.
Na página Novo Cache Redis, defina as configurações para o novo cache de Camada Premium.
Configuração Valor sugerido DESCRIÇÃO Nome DNS Insira um nome global exclusivo. O nome do cache deve conter de 1 a 63 caracteres e incluir somente números, letras ou hifens. O nome deve começar e terminar com um número ou uma letra e não pode conter hifens consecutivos. O nome do host de sua instância de cache será \<DNS name>.redis.cache.windows.net.Assinatura Selecione sua assinatura na lista suspensa. A assinatura na qual essa nova instância do Cache do Azure para Redis será criada. 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 o cache e outros recursos serão criados. Ao colocar todos os seus recursos de aplicativos em um só grupo de recursos, você pode gerenciá-los ou excluí-los juntos com facilidade. Localidade Selecione uma localização na lista suspensa. Selecione uma região perto de outros serviços que usarão o cache. Tipo de cache Selecione um cache de camada Premium na lista suspensa para configurar os recursos da camada Premium. Para obter mais informações, confira Preços do Cache do Azure para Redis. O tipo de preço determina o tamanho, o desempenho e os recursos disponíveis para o cache. Para obter mais informações, consulte Visão geral do Cache do Azure para Redis. Selecione a guia Rede ou o botão Rede na parte inferior da página.
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 o cache de camada Premium.
Importante
Ao implantar o Cache do Azure para Redis em uma rede virtual do Resource Manager, o cache deve estar em uma sub-rede dedicada que não contenha nenhum outro recurso, exceto instâncias do Cache do Azure para Redis. Se você tentar implantar uma instância do Cache do Azure para Redis em uma sub-rede de rede virtual do Resource Manager que contenha outros recursos ou que tenha um Gateway da NAT atribuído, a implantação falhará. A falha ocorre porque o Cache do Azure para Redis usa um balanceador de carga básico que não é compatível com um Gateway da NAT.
Configuração Valor sugerido Descrição Rede virtual Selecione sua rede virtual na lista suspensa. Selecione uma rede virtual que esteja na mesma assinatura e no mesmo local que o 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 estar contido no 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 em cada sub-rede, os quais não podem ser usados. O primeiro e o último endereço IP das sub-redes são reservados para fins de conformidade de protocolo, juntamente com três outros endereços usados para os serviços do Azure. Para saber mais, confira Existem restrições quanto ao uso de endereços IP nessas sub-redes?
Além dos endereços IP usados pela infraestrutura da rede virtual do Azure, cada instância do Cache do Azure para Redis na sub-rede usa dois endereços IP por fragmento e um endereço IP adicional para o balanceador de carga. Considera-se que um cache não clusterizado tem um fragmento.
Selecione a guia Próximo: Avançado ou o botão Próximo: Avançado na parte inferior da página.
Na guia Avançado de uma instância de cache de camada Premium, defina as configurações da porta não TLS, do clustering e da persistência de dados.
Selecione a guia Próximo: Marcas ou o botão Próximo: Marcas na parte inferior da página.
Opcionalmente, na guia Marcas, insira o nome e o valor caso deseje categorizar o recurso.
Selecione Examinar + criar. Você será levado para a guia Examinar + criar, na qual o Azure valida sua configuração.
Depois que a mensagem em verde Validação aprovada for exibida, selecione Criar.
A criação do cache demora um pouco. Monitore o progresso na página Visão Geral do Cache do Azure para Redis. Quando o Status for mostrado como Em execução, o cache estará pronto para uso. Após o cache ser criado, você pode exibir a configuração da rede virtual selecionando Rede virtual no menu Recurso.
Perguntas frequentes sobre a rede virtual do Cache do Azure para Redis
A lista a seguir contém respostas para perguntas frequentes sobre a rede do Cache Redis do Azure.
- Quais são alguns problemas comuns de configuração incorreta com o Cache do Azure para Redis e as redes virtuais?
- Como posso verificar se o meu cache está funcionando em uma rede virtual?
- Quando tento me conectar à minha instância do Cache do Azure para Redis 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 de sub-rede?
- Posso me conectar ao meu cache de uma rede virtual emparelhada?
- Há suporte para injeção de VNet em um cache em que 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 em que o Azure Lighthouse está habilitado?
Quais são alguns problemas comuns de configuração incorreta com o Cache do Azure para Redis e as redes virtuais?
Quando o Cache do Azure para Redis for hospedado em uma rede virtual, serão usadas as portas nas tabelas a seguir.
Importante
Se as portas nas tabelas a seguir estiverem bloqueadas, é possível que o cache não funcione corretamente. Ter uma ou mais dessas portas bloqueadas é o problema mais comum de configuração incorreta ao usar o Cache do Azure para Redis em uma rede virtual.
Requisitos de porta de saída
Há requisitos de conectividade de rede para o Cache do Azure para Redis necessários para conectividade de saída com outros serviços de dependência necessários para que o cache funcione ou até mesmo internos para a sub-rede do Redis para comunicação entre nós.
| Portos | Direção | Protocolo de transporte | Finalidade | IP local | IP remoto |
|---|---|---|---|---|---|
| 80, 443 | Saída | TCP | Dependências do Redis no Armazenamento do Azure, PKI (Internet), sistema operacional, infraestrutura e antivírus | (Sub-rede Redis) | * 4 |
| 443 | Saída | TCP | Dependência de Redis no Azure Key Vault e Azure Monitor | (Sub-rede Redis) | AzureKeyVault, AzureMonitor 1 |
| 12000 | Saída | TCP | Dependência do Redis no Azure Monitor | (Sub-rede Redis) | AzureMonitor 1 |
| 53 | Saída | TCP/UDP | Dependências de 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 |
| 123 | Saída | UDP | Dependência do sistema operacional no NTP | (Sub-rede Redis) | * |
| 1688 | Saída | TCP | Dependência do sistema operacional para ativação | (Sub-rede Redis) | * |
| 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 par de replicação geográfica) |
| 6379-6380 | Saída | TCP | Comunicações internas para Redis | (Sub-rede Redis) | (Sub-rede Redis) |
1 Você pode usar as marcas de serviço AzureKeyVault e AzureMonitor com grupos de segurança de rede (NSGs) do Resource Manager.
2 Esses endereços IP de propriedade da Microsoft são usados para endereçar a máquina virtual do host que atende ao 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 de porta de pares de replicação geográfica
Se você estiver usando a replicação geográfica entre os caches em redes virtuais do Azure: a) desbloqueie as portas 15000 a 15999 para toda a sub-rede nas direções de entrada e de saída e b) para ambos os caches. Com essa configuração, todos os componentes de réplica na sub-rede podem se comunicar diretamente uns com os outros, mesmo se houver 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 de entrada em outros serviços hospedados na mesma rede virtual ou internas para as comunicações de sub-rede do Redis. Ou, então, são internas às comunicações da sub-rede do Redis.
| Portas | Direção | Protocolo de transporte | Finalidade | IP local | IP remoto |
|---|---|---|---|---|---|
| 6379, 6380 | Entrada | TCP | Comunicação do cliente com o Redis, Balanceamento de Carga do Azure | (Sub-rede Redis) | (Sub-rede Redis), (Sub-rede do cliente), AzureLoadBalancer 1 |
| 8443 | Entrada | TCP | Comunicações internas para Redis | (Sub-rede Redis) | (Sub-rede Redis) |
| 8500 | Entrada | TCP/UDP | Balanceamento de Carga do Azure | (Sub-rede Redis) | AzureLoadBalancer |
| 10221-10231 | Entrada | TCP | Comunicação de cliente com clusters Redis, comunicações internas para Redis | (Sub-rede Redis) | (Sub-rede Redis), (Sub-rede do cliente), AzureLoadBalancer |
| 13000-13999 | Entrada | TCP | Comunicação do cliente com Clusters Redis, Balanceamento de Carga do Azure | (Sub-rede Redis) | (Sub-rede Redis), (Sub-rede do cliente), AzureLoadBalancer |
| 15000-15999 | Entrada | 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 do cliente), AzureLoadBalancer, (Sub-rede do par de replicação geográfica) |
| 16001 | Entrada | TCP/UDP | Balanceamento de Carga do Azure | (Sub-rede Redis) | AzureLoadBalancer |
| 20226 | Entrada | TCP | Comunicações internas para Redis | (Sub-rede Redis) | (Sub-rede Redis) |
1 Você pode usar a marca de serviço AzureLoadBalancer para o Resource Manager ou AZURE_LOADBALANCER para o modelo de implantação clássico para criar as regras de NSG.
Requisitos adicionais de conectividade de rede virtual
Há requisitos de conectividade de rede para o Cache do Azure para Redis necessários para conectividade de saída com outros serviços de dependência necessários para que o cache funcione ou até mesmo internos para a sub-rede do Redis para comunicação entre nós.
O Cache do Azure para Redis requer que todos os seguintes itens de conectividade de saída funcionem corretamente quando usados em uma rede virtual:
| Nome do host | Protocolo | Porta de saída | Objetivo | Marca de serviço |
|---|---|---|---|---|
| *.vault.azure.net | HTTPS | 443 | Azure Key Vault | AzureKeyVault |
| *.table.core.windows.net | HTTPS | 443 | Armazenamento do Azure | Armazenamento |
| *.blob.core.windows.net | HTTPS | 443 | Armazenamento do Azure | Armazenamento |
| *.queue.core.windows.net | HTTPS | 443 | Armazenamento do Azure | Armazenamento |
| *.file.core.windows.net | HTTPS | 443 | Armazenamento do Azure | Armazenamento |
| ocsp.digicert.com | HTTP | 80 | Infraestrutura de chave pública do Azure | N/A |
| crl4.digicert.com | HTTP | 80 | Infraestrutura de chave pública do Azure | N/A |
| ocsp.msocsp.com | HTTP | 80 | Infraestrutura de chave pública do Azure | N/A |
| mscrl.microsoft.com | HTTP | 80 | Infraestrutura de chave pública do Azure | N/A |
| crl3.digicert.com | HTTP | 80 | Infraestrutura de chave pública do Azure | N/A |
| cacerts.digicert.com | HTTP | 80 | Infraestrutura de chave pública do Azure | N/A |
| oneocsp.microsoft.com | HTTP | 80 | Infraestrutura de chave pública do Azure | N/A |
| crl.microsoft.com | HTTP | 80 | Infraestrutura de chave pública do Azure | N/A |
| cacerts.geotrust.com | HTTP | 80 | Infraestrutura de chave pública do Azure | N/A |
| www.microsoft.com | HTTP | 80 | Infraestrutura de chave pública do Azure | N/A |
| cdp.geotrust.com | HTTP | 80 | Infraestrutura de chave pública do Azure | N/A |
| status.geotrust.com | HTTP | 80 | Infraestrutura de chave pública do Azure | N/A |
| shoebox3.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| shoebox3-red.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| shoebox3-black.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| azredis.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| azredis-red.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| azredis-black.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| global.prod.microsoftmetrics.com | HTTPS | 443 | Azure Monitor | AzureMonitor |
| gcs.prod.monitoring.core.windows.net | HTTPS | 443 | Azure Monitor | AzureMonitor |
| *.prod.warm.ingest.monitor.core.windows.net | HTTPS | 443 | Azure Monitor | AzureMonitor |
| *.servicebus.windows.net | HTTPS | 443 | Azure Monitor | EventHub |
| *.update.microsoft.com | HTTPS | 443 | Serviço de atualização do sistema operacional | AzureCloud |
| *.windowsupdate.com | HTTP/HTTPS | 80, 443 | Serviço de atualização do sistema operacional | N/A |
| *.delivery.mp.microsoft.com | HTTP/HTTPS | 80, 443 | Serviço de atualização do sistema operacional | AzureCloud |
| go.microsoft.com | HTTP/HTTPS | 80, 443 | Antivírus | N/A |
| *.wdcp.microsoft.com | HTTPS | 443 | Antivírus | AzureCloud |
| *.wdcpalt.microsoft.com | HTTPS | 443 | Antivírus | AzureCloud |
| *.wd.microsoft.com | HTTPS | 443 | Antivírus | AzureCloud |
| definitionupdates.microsoft.com | HTTPS | 443 | Antivírus | N/A |
| azurewatsonanalysis-prod.core.windows.net | HTTPS | 443 | Diagnóstico interno | AzureCloud |
| shavamanifestazurecdnprod1.azureedge.net | HTTPS | 443 | Diagnóstico interno | N/A |
| shavamanifestcdnprod1.azureedge.net | HTTPS | 443 | Diagnóstico interno | N/A |
| *.data.microsoft.com | HTTPS | 443 | Diagnóstico interno | AzureCloud |
- A configuração DNS para a rede virtual deve ser capaz de resolver todos os pontos de extremidade e domínios mencionados nas entradas de tabela anteriores. Esses requisitos de DNS podem ser atendidos, garantindo que uma infraestrutura de DNS válida seja configurada e mantida para a rede virtual.
Como posso verificar se o meu cache está funcionando em uma rede virtual?
Importante
Quando você se conecta a uma instância do Cache do Azure para Redis que está 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 emparelhamento de rede virtual global não tem suporte no momento. Esse requisito se aplica a quaisquer aplicativos de teste ou ferramentas de execução de ping de diagnóstico. Seja qual for o local em que o aplicativo cliente está hospedado, os NSGs ou outras camadas de rede devem ser configurados de modo que o tráfego de rede do cliente tenha permissão para acessar a instância do Cache do Azure para Redis.
Depois que os requisitos de porta forem configurados conforme descrito na seção anterior, é necessário reinicializar na maioria dos casos para garantir que as alterações sejam aplicadas corretamente. Caso contrário, você poderá enfrentar alguns problemas de conectividade. Você pode verificar se o cache está funcionando seguindo estas etapas:
- Reinicialize todos os nós de cache. Não será possível reiniciar o cache com êxito se todas as dependências de cache necessárias não puderem ser acessadas, conforme documentado em Requisitos da porta de entrada e Requisitos da 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 o ping no ponto de extremidade do cache usando a porta 6380 de um computador que esteja na mesma rede virtual que o cache, usando
tcping. Por exemplo:tcping.exe contosocache.redis.cache.windows.net 6380Se a ferramenta
tcpingrelata que a porta está aberta, o cache está disponível para conexão de clientes na rede virtual.Outra maneira de testar isso: crie um cliente de cache de teste que se conecte ao cache e adicione e recupere alguns itens do cache. O cliente de cache de teste pode ser um aplicativo de console que usa StackExchange.Redis. Instale o aplicativo cliente de amostra 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 do Azure para Redis em uma rede virtual, por que recebo um erro informando que o certificado remoto é inválido?
Ao tentar se conectar a uma instância do Cache do Azure para Redis 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 o uso do 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 caracteres 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 é fornecida 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
Além disso, se a sub-rede em que o Cache do Azure para Redis está hospedado estiver bloqueando conexões de saída TCP na porta 80 para funcionalidade SSL/TLS, os clientes poderão enfrentar erros intermitentes de validação de certificado TLS.
Posso usar redes virtuais com um cache padrão ou básico?
As redes virtuais só podem ser usadas com caches de camada 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 do Azure para Redis 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 do Azure para Redis em uma sub-rede de rede virtual do Resource Manager que contenha outros recursos, como instâncias do Gateway de Aplicativo do Azure e NAT de saída, em geral, a implantação falhará. Exclua os recursos existentes de outros tipos antes de criar uma instância do 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 de sub-rede?
O Azure reserva alguns endereços IP em cada sub-rede, os quais não podem ser usados. O primeiro e o último endereço IP das sub-redes são reservados para fins de conformidade de protocolo, juntamente com três outros endereços usados para os serviços do Azure. Para obter mais informações, consulte Existem restrições quanto ao uso de endereços IP dentro dessas sub-redes?
Além dos endereços IP usados pela infraestrutura de rede virtual do Azure, cada instância do Cache do Azure para Redis na sub-rede usa dois endereços IP por fragmento de cluster, além de endereços IP para outras réplicas, se houver. Um endereço IP adicional é usado para o balanceador de carga. Considera-se que um cache não clusterizado tem um fragmento.
Posso me conectar ao meu cache de uma rede virtual emparelhada?
Se as redes virtuais estiverem na mesma região, você poderá conectá-las usando o emparelhamento de rede virtual ou uma conexão VNet a VNet do Gateway de VPN.
Se as redes virtuais emparelhadas do Azure estiverem em regiões diferentes: uma VM de cliente na região 1 não poderá acessar o cache na região 2 por meio do endereço IP com balanceamento de carga devido a uma restrição nos balanceadores de carga básicos. Ou seja, a menos que ele seja um cache com um balanceador de carga padrão, que atualmente é apenas um cache criado com zonas de disponibilidade.
Para obter mais informações sobre as restrições do emparelhamento de rede virtual, confira Rede Virtual – Emparelhamento – Requisitos e restrições. Uma solução é usar uma conexão VNet a VNet do Gateway de VPN em vez do emparelhamento de rede virtual.
Todos os recursos de cache funcionam quando um cache é hospedado em uma rede virtual?
Quando o seu 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 do Redis: como o Console do Redis é executado no navegador local, que geralmente está em um computador de desenvolvedor não conectado à rede virtual, ele não pode se conectar ao seu cache.
Há suporte para injeção de VNet em um cache em que 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 de Cache do Azure para Redis. Em vez disso, use links privados.
Usar ExpressRoute com Cache do Azure para Redis
Os clientes podem conectar um circuito do Azure ExpressRoute à infraestrutura de rede virtual deles. Dessa forma, eles estendem sua rede local para o Azure.
Por padrão, um circuito do ExpressRoute recém-criado não executa um 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 da internet é permitida diretamente da rede virtual. Os aplicativos cliente podem se conectar a outros pontos de extremidade do Azure, o que inclui 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 interromperá a conectividade com o Cache do Azure para Redis se o tráfego de saída for bloqueado no local, de modo que a instância do Cache do Azure para Redis não consiga comunicar-se com suas dependências.
A solução é definir uma ou mais UDRs (rotas definidas pelo usuário) na sub-rede que contém a instância do Cache do Azure para Redis. Uma UDR define rotas específicas de sub-rede que serão consideradas no lugar da rota padrão.
Se for possível, use a seguinte configuração:
- A configuração do ExpressRoute anuncia 0.0.0.0/0 e, por padrão, força os túneis de todo o tráfego de saída local.
- A UDR aplicada à sub-rede que contém a instância do Cache do Azure para Redis define 0.0.0.0/0 com uma rota de trabalho para tráfego TCP/IP para a internet pública. Por exemplo, ela define o tipo do próximo salto como internet.
O efeito combinado dessas etapas é que a UDR do nível de sub-rede tem precedência sobre o túnel forçado do ExpressRoute, e isso garante o acesso à Internet de saída na instância do Cache do Azure para Redis.
Conectar-se a uma instância do Cache do Azure para Redis a partir de um aplicativo local usando o ExpressRoute não é um cenário de uso típico devido a 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 uma UDR devem ser específicas o suficiente para ter precedência sobre todas as rotas anunciadas pela configuração do ExpressRoute. O exemplo a seguir usa o intervalo de endereços 0.0.0.0/0 amplo e, como tal, pode ser substituído acidentalmente pelos anúncios de rota que usam intervalos de endereços mais específicos.
Aviso
O Cache do Azure para Redis não tem suporte em configurações do ExpressRoute que anunciam incorretamente rotas de forma cruzada do caminho de emparelhamento da Microsoft para o caminho de emparelhamento privado. Configurações do ExpressRoute que têm emparelhamento da Microsoft 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ço forem anunciados incorretamente de modo cruzado 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 incorretamente encapsulados para a infraestrutura de rede local do cliente. Esse fluxo de rede interrompe o Cache do Azure para Redis. A solução para esse problema é parar de anunciar rotas de forma cruzada do caminho de emparelhamento da Microsoft 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 o ExpressRoute, consulte Visão geral técnica do ExpressRoute.
Conteúdo relacionado
Saiba mais sobre os recursos do Cache do Azure para Redis.