为高级Azure Cache for Redis实例配置虚拟网络(VNet)支持

重要

Azure Cache for Redis宣布其所有 SKU 的停用时间表。 建议尽快将现有Azure Cache for Redis实例移动到Azure托管 Redis。

迁移指南:

有关停用的更多详细信息:

Azure 虚拟网络 部署提供增强的安全性和隔离性,以及子网、访问控制策略和其他功能,以进一步限制访问。 使用虚拟网络配置Azure Cache for Redis实例时,它不可公开寻址。 相反,只能从虚拟网络中的虚拟机和应用程序访问实例。 本文介绍如何为高级层Azure Cache for Redis实例配置虚拟网络支持。

注意

经典部署模型将于 2024 年 8 月停用。 有关详细信息,请参阅云服务(经典)部署模型将于 2024 年 8 月 31 日停用

重要

Azure Cache for Redis建议使用Azure 专用链接,这简化了网络体系结构,并保护Azure中的终结点之间的连接。 可以通过专用终结点从虚拟网络连接到Azure缓存实例,该终结点在虚拟网络中的子网中分配了专用 IP 地址。 Azure 专用链接在所有层级上提供,包括 Azure Policy 支持和简化的网络安全组规则管理。 若要了解详细信息,请参阅 专用链接 文档。 若要将 VNet 注入缓存迁移到 专用链接,请参阅 Migrate 从 VNet 注入缓存迁移到专用链接缓存

虚拟网络注入的限制

  • 创建和维护虚拟网络配置通常容易出错。 故障排除也非常具有挑战性。 不正确的虚拟网络配置可能会导致问题:
    • 缓存实例的指标数据传输受阻
    • 副本节点无法从主节点复制数据
    • 可能丢失数据
    • 管理操作(如缩放)失败
    • 间歇性或完全性的 SSL/TLS 故障
    • 未能应用更新,包括重要的安全性和可靠性改进
    • 在最严重的情况下,会丧失可用性
  • 使用 VNet 注入缓存时,必须保持 VNet 更新,以允许访问缓存依赖项,例如证书吊销列表、公钥基础结构、Azure 密钥保管库、Azure 存储、Azure Monitor等。
  • VNet 注入缓存仅适用于高级层Azure Cache for Redis,而不适用于其他层。
  • 无法将现有Azure Cache for Redis实例注入虚拟网络。 创建缓存时必须选择此选项。
  • Azure门户不支持在资源创建期间配置 VNET 注入

设置虚拟网络支持

请参阅 az redis create

Azure Cache for Redis虚拟网络常见问题解答

以下列表包含有关Azure Cache for Redis网络的常见问题的解答。

Azure Cache for Redis和虚拟网络的一些常见配置错误问题是什么?

Azure Cache for Redis托管在虚拟网络中时,将使用以下表中的端口。

重要

如果下述表中的端口被阻止,缓存可能无法正常使用。 在虚拟网络中使用Azure Cache for Redis时,阻止了其中一个或多个端口是最常见的错误配置问题。

出站端口要求

Azure Cache for Redis需要满足网络连接要求,其中包括出站连接至其他依赖服务以确保缓存正常运行的连接,以及Redis子网内部用于节点间通信的连接。

端口 方向 传输协议 目的 本地 IP 远程 IP
80、443 出站 TCP Redis 依赖于 Azure 存储、PKI (Internet)、操作系统、基础结构和防病毒 (Redis 子网) * 4
443 出站 TCP Redis 依赖于 Azure 密钥保管库 和 Azure Monitor (Redis 子网) AzureKeyVault、AzureMonitor 1
12000 出站 TCP Redis 依赖 Azure Monitor (Redis 子网) AzureMonitor 1
53 出站 TCP/UDP DNS(Internet/虚拟网络)上的 Redis 依赖关系 (Redis 子网) 168.63.129.16 和 169.254.169.254 2 以及子网的任何自定义 DNS 服务器 3
123 出站 UDP 操作系统对 NTP 的依赖 (Redis 子网) *
1688 出站 TCP 用于激活的操作系统依赖项 (Redis 子网) *
8443 出站 TCP Redis 的内部通信 (Redis 子网) (Redis 子网)
10221-10231 出站 TCP Redis 的内部通信 (Redis 子网) (Redis 子网)
20226 出站 TCP Redis 的内部通信 (Redis 子网) (Redis 子网)
13000-13999 出站 TCP Redis 的内部通信 (Redis 子网) (Redis 子网)
15000-15999 出站 TCP Redis 内部通信和异地复制 (Redis 子网) (Redis 子网)(地理副本对等子网)
6379-6380 出站 TCP Redis 的内部通信 (Redis 子网) (Redis 子网)

1 可以将服务标记 AzureKeyVault 和 AzureMonitor 与资源管理器网络安全组(NSG)配合使用。

2这些由Microsoft拥有的 IP 地址用于处理提供Azure DNS的主机 VM。

3 如果子网不包含自定义 DNS 服务器或不采用忽略自定义 DNS 的较新 Redis 缓存,则不需要此信息。

4 有关详细信息,请参阅其他虚拟网络连接要求

异地复制节点端口要求

在 Azure 虚拟网络中的缓存之间使用地理复制时:a)解除对整子网中端口 15000-15999 的入站和出站方向的阻止,b)应用于两个缓存。 使用此配置时,子网中的所有副本组件都可以直接相互通信,即使将来发生地理故障转移。

入站端口要求

入站端口范围有八项要求。 这些范围内的入站请求是来自托管在同一虚拟网络中的其他服务的请求。 或者,它们是 Redis 子网通信内部的请求。

端口 方向 传输协议 目的 本地 IP 远程 IP
6379、6380 入站 TCP 与 Redis 的客户端通信,Azure负载均衡 (Redis 子网) (Redis 子网)、(客户端子网)、AzureLoadBalancer 1
8443 入站 TCP Redis 的内部通信 (Redis 子网) (Redis 子网)
8500 入站 TCP/UDP Azure负载均衡 (Redis 子网) Azure 负载均衡器 (AzureLoadBalancer)
10221-10231 入站 TCP 与 Redis 群集的客户端通信、Redis 内部通信 (Redis 子网) (Redis 子网)、(客户端子网)、AzureLoadBalancer
13000-13999 传入 TCP 与 Redis 群集的客户端通信,Azure负载均衡 (Redis 子网) (Redis 子网)、(客户端子网)、AzureLoadBalancer
15000-15999 入站 TCP 与 Redis 群集的客户端通信、Azure负载均衡和异地复制 (Redis 子网) (Redis 子网)、(客户端子网)、AzureLoadBalancer、(地域副本对等子网)
16001 入站 TCP/UDP Azure负载均衡 (Redis 子网) Azure 负载均衡器 (AzureLoadBalancer)
20226 入站 TCP Redis 的内部通信 (Redis 子网) (Redis 子网)

1 可以使用服务标记 AzureLoadBalancer 用于 资源管理器,或使用 AZURE_LOADBALANCER 用于经典部署模型来定义 NSG 规则。

其他虚拟网络连接要求

为了确保 Azure Cache for Redis 缓存的正常运行,需要满足网络连接要求,以便出站连接至其他必要的依赖服务,以及在 Redis 子网内部进行节点间通信。

Azure Cache for Redis要求以下所有出站连接项在虚拟网络中使用时正常运行:

主机名 协议 出站端口 目的 服务标记
*.vault.azure.cn HTTPS 443 Azure 密钥保管库 AzureKeyVault
*.table.core.chinacloudapi.cn HTTPS 443 Azure 存储 存储
*.blob.core.chinacloudapi.cn HTTPS 443 Azure 存储 存储
*.queue.core.chinacloudapi.cn HTTPS 443 Azure 存储 存储
*.file.core.chinacloudapi.cn HTTPS 443 Azure 存储 存储
ocsp.digicert.com HTTP 80 Azure公钥基础结构 空值
crl4.digicert.com HTTP 80 Azure公钥基础结构 空值
ocsp.msocsp.com HTTP 80 Azure公钥基础结构 空值
mscrl.microsoft.com HTTP 80 Azure公钥基础结构 空值
crl3.digicert.com HTTP 80 Azure公钥基础结构 空值
cacerts.digicert.com HTTP 80 Azure公钥基础结构 空值
oneocsp.microsoft.com HTTP 80 Azure公钥基础结构 空值
crl.microsoft.com HTTP 80 Azure公钥基础结构 空值
cacerts.geotrust.com HTTP 80 Azure公钥基础结构 空值
www.microsoft.com HTTP 80 Azure公钥基础结构 空值
cdp.geotrust.com HTTP 80 Azure公钥基础结构 空值
status.geotrust.com HTTP 80 Azure公钥基础结构 空值
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.chinacloudapi.cn HTTPS 443 Azure Monitor AzureMonitor
*.prod.warm.ingest.monitor.core.chinacloudapi.cn HTTPS 443 Azure Monitor AzureMonitor
*.servicebus.chinacloudapi.cn HTTPS 443 Azure Monitor EventHub
*.update.microsoft.com HTTPS 443 操作系统更新服务 AzureCloud
*.windowsupdate.com HTTP/HTTPS 80、443 操作系统更新服务 空值
*.delivery.mp.microsoft.com HTTP/HTTPS 80、443 操作系统更新服务 AzureCloud
go.microsoft.com HTTP/HTTPS 80、443 防病毒 空值
*.wdcp.microsoft.com HTTPS 443 防病毒 AzureCloud
*.wdcpalt.microsoft.com HTTPS 443 防病毒 AzureCloud
*.wd.microsoft.com HTTPS 443 防病毒 AzureCloud
definitionupdates.microsoft.com HTTPS 443 防病毒 空值
azurewatsonanalysis-prod.core.chinacloudapi.cn HTTPS 443 内部诊断 AzureCloud
shavamanifestazurecdnprod1.azureedge.net HTTPS 443 内部诊断 空值
shavamanifestcdnprod1.azureedge.net HTTPS 443 内部诊断 空值
*.data.microsoft.com HTTPS 443 内部诊断 AzureCloud
  • 虚拟网络的 DNS 配置必须能够解析前面表项所提到的所有终结点和域。 确保已针对虚拟网络配置并维护有效的 DNS 基础结构即可符合这些 DNS 要求。

如何验证我的缓存在虚拟网络中是否正常工作?

重要

连接到托管在虚拟网络中的 Azure Cache for Redis 实例时,缓存客户端必须位于同一虚拟网络中,或者位于已在同一 Azure 区域中启用虚拟网络对等互连的虚拟网络中。 当前不支持全局虚拟网络的对等互联。 此要求适用于任何测试应用程序或诊断 ping 工具。 无论在何处托管客户端应用程序,都必须配置 NSG 或其他网络层,以便允许客户端的网络流量到达Azure Cache for Redis实例。

根据上一部分所述配置端口要求后,在大多数情况下需要重新启动以确保更改正确反映。 否则,可能会遇到一些连接问题。 可以按照以下步骤验证缓存是否正常工作:

  • 重新启动所有缓存节点。 如果无法访问所有所需的缓存依赖项(如入站端口需求出站端口需求中所述),缓存将无法成功重启。
  • 重启缓存节点后,如Azure门户中缓存状态报告的那样,可以执行以下测试:
    • 使用 tcping,从缓存所在的虚拟网络中的某台计算机对缓存终结点发出 ping 命令(使用端口 6380)。 例如:

      tcping.exe contosocache.redis.cache.chinacloudapi.cn 6380

      如果 tcping 工具报告端口已经开启,则虚拟网络中的客户端可连接缓存。

    • 进行测试的另一种方法:创建测试缓存客户端,使其连接到缓存,以便添加和检索缓存的某些项。 测试缓存客户端可以是使用 StackExchange.Redis 的控制台应用程序。 将示例客户端应用程序安装到缓存所在虚拟网络中的一个 VM 上。 然后运行它来验证与缓存的连接。

尝试连接到虚拟网络中的Azure Cache for Redis实例时,为什么收到一个错误,指出远程证书无效?

尝试连接到虚拟网络中的Azure Cache for Redis实例时,会看到证书验证错误,如下所示:

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

这可能是因为你在通过 IP 地址来连接主机。 建议使用主机名。 换而言之,请使用以下字符串:

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

避免使用类似于以下连接字符串的 IP 地址:

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

如果无法解析 DNS 名称,则可使用某些客户端库包括的 sslHost(由 StackExchange.Redis 客户端提供)之类的配置选项。 此选项允许你替代用于证书验证的主机名。 例如:

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

此外,如果托管Azure Cache for Redis的子网阻止 TCP 出站连接通过端口 80 进行 SSL/TLS 功能,则客户端可能会遇到间歇性 TLS 证书验证错误。

是否可以将虚拟网络与标准或基本缓存一起使用?

虚拟网络只能与高级层缓存一起使用。

为什么创建Azure Cache for Redis实例在某些子网中失败,但不能在其他子网中创建实例?

如果要将Azure Cache for Redis实例部署到虚拟网络,缓存必须位于不包含其他资源类型的专用子网中。 如果尝试将Azure Cache for Redis实例部署到包含其他资源的资源管理器虚拟网络子网---例如Azure 应用程序网关实例和出站 NAT---部署通常会失败。 在创建新的Azure Cache for Redis实例之前,请删除其他类型的现有资源。

子网中还必须有足够的可用 IP 地址。

子网地址空间的要求是什么?

Azure在每个子网中保留一些 IP 地址,并且无法使用这些地址。 子网的第一个和最后一个 IP 地址保留为协议一致性,另外还有三个用于Azure服务的地址。 有关详细信息,请参阅使用这些子网中的 IP 地址是否有任何限制

除了Azure虚拟网络基础结构使用的 IP 地址之外,子网中的每个 Azure Cache for Redis 实例在每个群集分片中使用两个 IP 地址,如果有更多的副本,则还会使用额外的 IP 地址。 为负载均衡器使用另外一个 IP 地址。 非群集缓存被视为包含一个分片。

我可以从对等虚拟网络连接到缓存吗?

如果虚拟网络位于同一区域,则可以使用虚拟网络对等互连或 VPN 网关 VNET 到 VNET 连接来连接它们。

如果对等互连的 Azure 虚拟网络位于 不同 区域:由于基本负载均衡器的限制,位于区域 1 的客户端 VM 无法通过其负载均衡 IP 地址访问区域 2 中的缓存。 也就是说,除非它是一个使用标准负载均衡器的缓存(目前仅限于使用可用性区域创建的缓存)。

有关虚拟网络对等互连约束的详细信息,请参阅虚拟网络 - 对等互连 - 要求和约束。 一种解决方案是使用 VPN 网关 VNET 到 VNET 连接,而不是虚拟网络对等互连。

当缓存承载在虚拟网络中时,是否所有缓存功能都可以使用?

如果缓存是虚拟网络的一部分,则只有虚拟网络中的客户端可以访问缓存。 因此,以下缓存管理功能目前无法使用。

  • Redis 控制台:由于 Redis 控制台在本地浏览器中运行(通常在未连接到虚拟网络的开发人员计算机上),因此它无法连接到缓存。

在启用了Azure Lighthouse的缓存上是否支持 VNet 注入?

否,如果订阅已启用Azure Lighthouse,则无法在Azure Cache for Redis实例上使用 VNet 注入。 请改用专用链接。

将 ExpressRoute 与 Azure Cache for Redis 配合使用

客户可以将 Azure ExpressRoute 线路连接到其虚拟网络基础结构。 这样,他们就会将其本地网络扩展到Azure。

默认情况下,新创建的 ExpressRoute 线路不会在虚拟网络上使用强制隧道(播发一个默认的路由,即 0.0.0.0/0)。 因此,可以直接从虚拟网络建立出站 Internet 连接。 客户端应用程序可以连接到其他Azure终结点,其中包括Azure Cache for Redis实例。

常见的客户配置是使用强制隧道(播发默认路由),以强制出站 Internet 流量改为流向本地。 如果出站流量随后被本地阻止,则此流量流会中断与Azure Cache for Redis的连接,以便Azure Cache for Redis实例无法与其依赖项通信。

解决方案是在包含Azure Cache for Redis实例的子网上定义一个或多个用户定义的路由(UDR)。 UDR 定义的路由是特定于子网的,优先于默认路由。

如果可以,请使用以下配置:

  • ExpressRoute 配置会播发 0.0.0.0/0,并默认使用强制通道将所有出站流量发送到本地环境。
  • 应用于包含 Azure Cache for Redis 实例的子网的用户定义的路由 (UDR) 将 0.0.0.0/0 定义为具有通向公共互联网的 TCP/IP 流量的有效路由。 例如,它可以将下一跃点类型设置为“Internet”。

这些步骤的组合效果是子网级 UDR 优先于 ExpressRoute 强制隧道,并确保从 Azure Cache for Redis 实例进行出站 Internet 访问。

由于性能原因,使用 ExpressRoute 从本地应用程序连接到Azure Cache for Redis实例并不是典型的使用方案。 为了获得最佳性能,Azure Cache for Redis客户端应与Azure Cache for Redis实例位于同一区域。

重要

UDR 中定义的路由 必须 足够明确,以便优先于 ExpressRoute 配置所播发的任何路由。 下面的示例使用的 0.0.0.0/0 的地址范围很广泛,因此可能会被那些使用更具体地址范围的路由播发潜在地重写。

警告

ExpressRoute 配置不支持 Azure Cache for Redis,如果错误地将路由从 Microsoft 对等路径跨播到专用对等路径。 配置了 Microsoft 对等连接的 ExpressRoute 配置会从 Microsoft 接收来自 Azure 大量 IP 地址范围的路由公告。 如果这些地址范围在专用对等互连路径上错误地交叉播发,则结果是,来自Azure Cache for Redis实例子网的所有出站网络数据包都错误地强制隧道到客户的本地网络基础结构。 此网络流会中断Azure Cache for Redis。 解决此问题的方法是停止在 Microsoft 对等互连路径与专用对等互连路径之间的跨播发路由。

虚拟网络流量路由中提供了有关 UDR 的背景信息。

有关 ExpressRoute 的详细信息,请参阅 ExpressRoute 技术概述

详细了解Azure Cache for Redis功能。