如何为高级 Azure Redis 缓存配置虚拟网络支持

Azure Redis 缓存具有不同的缓存产品(包括群集、持久性和虚拟网络支持等高级层功能),使缓存大小和功能的选择更加灵活。 VNet 是云中的专用网络。 为 Azure Redis 缓存实例配置了 VNet 后,该实例不可公开寻址,而只能从 VNet 中的虚拟机和应用程序进行访问。 本文说明如何为高级 Azure Redis 缓存实例配置虚拟网络支持。

Note

Azure Redis 缓存同时支持经典 VNet 和 Resource Manager VNet。

有关其他高级缓存功能的信息,请参阅 Azure Redis 缓存高级层简介

为何使用 VNet?

Azure 虚拟网络 (VNet) 部署为 Azure Redis 缓存提供增强的安全性和隔离性,并提供子网、访问控制策略,以及用于进一步限制访问的其他功能。

虚拟网络支持

在创建缓存期间,可在“新建 Redis 缓存”边栏选项卡中配置虚拟网络 (VNet) 支持。

若要创建高级缓存,请登录到 Azure 门户,然后单击“新建” > “数据库” > “Redis 缓存”。

Note

除了在 Azure 门户中创建缓存以外,也可以使用 Resource Manager 模板、PowerShell 或 Azure CLI 创建。 有关创建 Azure Redis 缓存的详细信息,请参阅创建缓存

若要配置高级功能,请先在“定价层”下拉列表中选择一个高级定价层。 若要详细了解每个定价层,请单击“查看全部定价详细信息”,并从“选择你的定价层”边栏选项卡中选择一个定价层。

选择定价层

选择高级定价层后,可以通过选择与缓存相同的订阅和位置的 VNet 来配置 Redis VNet 集成。 若要使用新 VNet,请先创建 VNet,方法是遵循使用 Azure 门户创建虚拟网络使用 Azure 门户创建虚拟网络(经典)中的步骤,然后返回“新建 Redis 缓存”边栏选项卡来创建和配置高级缓存。

如果要为新缓存配置 VNet,请单击“新建 Redis 缓存”边栏选项卡上的“虚拟网络”,并从下拉列表中选择所需的 VNet。

虚拟网络

从“子网”下拉列表中选择所需的子网,并指定所需的“静态 IP 地址”。 如果使用经典 VNet,则“静态 IP 地址”字段是可选的;如果未指定任何地址,将从选定的子网中选择一个。

Important

将 Azure Redis 缓存部署到 Resource Manager VNet 时,缓存必须位于专用子网中,其中只能包含 Azure Redis 缓存实例,而不能包含其他任何资源。 如果尝试将 Azure Redis 缓存部署到包含其他资源的 Resource Manager VNet 子网,则部署会失败。

虚拟网络

Important

Azure 会保留每个子网中的某些 IP 地址,不可以使用这些地址。 子网的第一个和最后一个 IP 地址仅为协议一致性而保留,其他三个地址用于 Azure 服务。 有关详细信息,请参阅使用这些子网中的 IP 地址是否有任何限制?

除了 Azure VNET 基础结构使用的 IP 地址以外,子网中的每个 Redis 实例为每个分片使用两个 IP 地址,为负载均衡器使用一个额外的 IP 地址。 非群集缓存被视为包含一个分片。

创建缓存之后,可以在“资源菜单”中单击“虚拟网络”,查看 VNet 的配置。

虚拟网络

若要在使用 VNet 时连接到 Azure Redis 缓存实例,请在连接字符串中指定缓存主机名,如以下示例中所示:

private static Lazy<ConnectionMultiplexer> lazyConnection = new Lazy<ConnectionMultiplexer>(() =>
{
    return ConnectionMultiplexer.Connect("contoso5premium.redis.cache.chinacloudapi.cn,abortConnect=false,ssl=true,password=password");
});

public static ConnectionMultiplexer Connection
{
    get
    {
        return lazyConnection.Value;
    }
}

Azure Redis 缓存 VNet 常见问题

以下列表包含有关 Azure Redis 缓存缩放的常见问题的解答。

Azure Redis 缓存和 VNet 有哪些常见的错误配置问题?

在 VNet 中托管 Azure Redis 缓存时,会使用下表中的端口。

Important

如果下表中的端口受阻,缓存可能无法正常工作。 在 VNet 中使用 Azure Redis 缓存时,阻止这些端口中的一个或多个是最常见的错误配置问题。

出站端口要求

出站端口有七个要求。

  • 如果需要,与 Internet 的所有出站连接都可以通过客户端的本地审核设备建立。
  • 其中三个端口将流量路由到为 Azure 存储和 Azure DNS 提供服务的 Azure 终结点。
  • 剩余端口范围,这些端口用于内部 Redis 子网通信。 内部 Redis 子网通信不需要子网 NSG 规则。
端口 方向 传输协议 目的 本地 IP 远程 IP
80、443 出站 TCP Azure 存储/PKI (Internet) 上的 Redis 依赖关系 (Redis 子网) *
53 出站 TCP/UDP DNS (Internet/VNet) 上的 Redis 依赖关系 (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 子网)

入站端口要求

入站端口范围有八个要求。 这些范围中的入站请求从同一 VNET 中托管的其他服务入站,或者是 Redis 子网通信的内部请求。

端口 方向 传输协议 目的 本地 IP 远程 IP
6379、6380 入站 TCP 与 Redis 的客户端通信、Azure 负载均衡 (Redis 子网) (Redis 子网)、虚拟网络、Azure 负载均衡器
8443 入站 TCP Redis 的内部通信 (Redis 子网) (Redis 子网)
8500 入站 TCP/UDP Azure 负载均衡 (Redis 子网) Azure 负载均衡器
10221-10231 入站 TCP Redis 的内部通信 (Redis 子网) (Redis 子网)、Azure 负载均衡器
13000-13999 入站 TCP 与 Redis 群集的客户端通信、Azure 负载均衡 (Redis 子网) 虚拟网络、Azure 负载均衡器
15000-15999 入站 TCP 与 Redis 群集的客户端通信、Azure 负载均衡 (Redis 子网) 虚拟网络、Azure 负载均衡器
16001 入站 TCP/UDP Azure 负载均衡 (Redis 子网) Azure 负载均衡器
20226 入站 TCP Redis 的内部通信 (Redis 子网) (Redis 子网)

其他 VNET 网络连接要求

在虚拟网络中,可能一开始不符合 Azure Redis 缓存的网络连接要求。 在虚拟网络中使用时,Azure Redis 缓存需要以下所有项才能正常运行。

  • 与全球 Azure 存储终结点建立的出站网络连接。 这包括位于与 Azure Redis 缓存实例相同区域中的终结点,以及位于 其他 Azure 区域的存储终结点。 Azure 存储终结点在以下 DNS 域之下解析:table.core.chinacloudapi.cnblob.core.chinacloudapi.cnqueue.core.chinacloudapi.cnfile.core.chinacloudapi.cn
  • ocsp.msocsp.commscrl.microsoft.comcrl.microsoft.com 建立的出站网络连接。 需要此连接才能支持 SSL 功能。
  • 虚拟网络的 DNS 设置必须能够解析前面几点所提到的所有终结点和域。 确保已针对虚拟网络配置并维护有效的 DNS 基础结构即可符合这些 DNS 要求。
  • 与以下 Azure 监视终结点(在下列 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。

如何验证缓存是否在 VNET 中正常工作?

Important

连接到 VNET 中托管的 Azure Redis 缓存实例时,缓存客户端必须位于同一 VNET 中或已启用 VNET 对等互连的 VNET 中。 这包括任何测试应用程序或诊断 ping 工具。 无论客户端应用程序在哪里托管,都必须配置网络安全组,这样客户端的网络流量才能到达 Redis 实例。

根据上一部分中所述的要求配置端口后,可通过执行以下步骤来验证缓存是否正常工作。

  • 重新启动所有缓存节点。 如果无法访问全部所需的缓存依赖项(如入站端口要求出站端口要求中所述),则缓存无法成功重启。
  • 重启缓存节点后(由 Azure 门户中的缓存状态报告),可执行以下测试:

    • 使用 tcping,从缓存所在的同一 VNET 中的某台计算机 ping 缓存终结点(使用端口 6380)。 例如:

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

      如果 tcping 工具报告端口已打开,则可以从该 VNET 中的客户端连接缓存。

    • 另一种测试方法是创建一个与缓存连接的测试缓存客户端(可以是使用 StackExchange.Redis 的简单控制台应用程序),然后在缓存中添加和检索一些项。 将示例客户端应用程序安装到缓存所在的同一个 VNET 中的某个 VM,然后运行该应用程序来验证与缓存之间的连接。

尝试连接到 VNET 中的 Redis 缓存时,为何会收到指出远程证书无效的错误?

尝试连接到 VNET 中的 Redis 缓存时,会收到类似于以下内容的证书验证错误:

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

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

[mycachename].redis.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.chinacloudapi.cn

是否可以对标准或基本缓存使用 VNet?

只能对高级缓存使用 VNet。

为什么在某些子网中创建 Redis 缓存失败,而在其他子网中不会失败?

如果要将 Azure Redis 缓存部署到Resource Manager VNet,缓存必须位于不包含任何其他资源类型的专用子网中。 如果尝试将 Azure Redis 缓存部署到包含其他资源的 Resource Manager VNet 子网,部署会失败。 必须先删除该子网中的现有资源,才能创建新的 Redis 缓存。

只要有足够的可用 IP 地址,就可以将多种类型的资源部署到经典 VNet。

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

Azure 会保留每个子网中的某些 IP 地址,但是这些地址不能使用。 子网的第一个和最后一个 IP 地址仅为协议一致性而保留,其他三个地址用于 Azure 服务。 有关详细信息,请参阅使用这些子网中的 IP 地址是否有任何限制?

除了 Azure VNET 基础结构使用的 IP 地址以外,子网中的每个 Redis 实例为每个分片使用两个 IP 地址,为负载均衡器使用一个额外的 IP 地址。 非群集缓存被视为包含一个分片。

在 VNET 中托管缓存时,是否可以使用所有缓存功能?

如果缓存是 VNET 的一部分,则只有 VNET 中的客户端可以访问缓存。 因此,以下缓存管理功能目前不起作用。

  • Redis 控制台 - 由于 Redis 控制台在本地浏览器中运行(这在 VNET 的外部),因此它无法连接到缓存。

将 ExpressRoute 用于 Azure Redis 缓存

客户可以将 Azure ExpressRoute 线路连接到虚拟网络基础结构,从而将其本地网络扩展到 Azure。

默认情况下,新创建的 ExpressRoute 线路不会在 VNET 上执行强制隧道(默认路由播发,0.0.0.0/0)。 因此,允许出站 Internet 连接直接来自 VNET,而且客户端应用程序能够连接到其他 Azure 终结点(包括 Azure Redis 缓存)。

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

解决方法是在包含 Azure Redis 缓存的子网上定义一个或多个用户定义的路由 (UDR)。 UDR 定义了要遵循的子网特定路由,而不是默认路由。

如果可能,建议使用以下配置:

  • ExpressRoute 配置播发 0.0.0.0/0 并默认使用强制隧道将所有输出流量发送到本地。
  • 应用到包含 Azure Redis 缓存的子网的 UDR 使用发往公共 Internet 的 TCP/IP 流量的工作路由(例如,通过将下一跃点类型设置为“Internet”)定义 0.0.0.0/0。

这些步骤的组合效应是子网级 UDR 将优先于 ExpressRoute 强制隧道,从而确保来自 Azure Redis 缓存的出站 Internet 访问。

出于性能原因,从本地应用程序使用 ExpressRoute 连接到 Azure Redis 缓存实例不是典型使用方案(为了获得最佳性能,Azure Redis 缓存客户端应与 Azure Redis 缓存在同一区域中)。

Important

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

Warning

未正确交叉播发从公共对等路径到专用对等路径的路由的 ExpressRoute 配置不支持 Azure Redis 缓存。 已配置公共对等互连的 ExpressRoute 配置收到来自 Microsoft 的大量 Microsoft Azure IP 地址范围的路由播发。 如果这些地址范围在专用对等路径上未正确交叉播发,结果是来自 Azure Redis 缓存实例子网的所有出站网络数据包都不会正确地使用强制隧道发送到客户的本地网络基础结构。 此网络流将破坏 Azure Redis 缓存。 此问题的解决方法是停止从公共对等路径到专用对等路径的交叉播发路由。

有关用户定义路由的背景信息,请参阅此概述

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

后续步骤

了解如何使用更多的高级缓存功能。