承接上篇文章内容，我们来看一下在Azure Redis部署中提供的其他选项，上篇讲过，在Azure Redis Premium版本中，我们可以支持将Redis部署在VNET中，这样的好处是显而易见的，我们可以通过NSG等规则来控制进出redis的流量，这样可以把redis的安全保护好，但是如果不是Premium版本的Redis是否意味着就没办法做Redis的网络安全防护呢？当然也不是这样，即使是standard的redis，我们仍然可以在Firewall里以添加白名单的方式保护redis的安全
当然这只是针对公网制定的白名单，redis本身仍然是相当于部署在internet中的，而不是一个私有的网络，如果想让应用以访问内容的方式访问redis，就需要将Redis部署在虚拟网络中了
Redis 虚拟网络部署主要有以下这些优势：
有固定的static private ip
可以使用NSG控制出入站流量
应用访问延迟更低
当然，想要部署在虚拟网络中，Redis还要求我们必须有一个独立的subnet用于redis部署，这是个什么概念呢？如果用过application gateway的话其实很容易理解这个概念，application gateway也是要求必须部署在一个独立的subnet中，这个subnet只能部署application gateway资源，不能部署其他任何资源，redis也是同样的概念，这是redis部署在虚拟网络里的一个前置条件
另外，如果对于出入站流量有严格要求的场景，Redis还要求对一些特定的服务器和地址有入站或者出站的权限，redis需要定期和一些管理节点进行通信以维护redis本身的状态
以下是这些要求的详细介绍，如果网络端口不满足条件的话，会发现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 子网） | 168.63.129.16 和 169.254.169.254 1 以及子网的任何自定义 DNS 服务器 3 |
| 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 Microsoft 拥有的这些 IP 地址用于对为 Azure DNS 提供服务的主机 VM 进行寻址。
3 没有自定义 DNS 服务器的子网或忽略自定义 DNS 的更新 redis 缓存不需要。
如果在 Azure 虚拟网络中的缓存之间使用异地复制，请注意，建议的配置是在两个缓存的入站和出站方向上取消阻止整个子网的端口 15000-15999，这样即使将来发生异地故障转移，子网中的所有副本组件也可以直接相互通信。
入站端口范围有八个要求。 这些范围中的入站请求从同一 VNET 中托管的其他服务入站，或者是 Redis 子网通信的内部请求。
| 端口 | 方向 | 传输协议 | 目的 | 本地 IP | 远程 IP |
|---|---|---|---|---|---|
| 6379、6380 | 入站 | TCP | 与 Redis 的客户端通信、Azure 负载均衡 | （Redis 子网） | （Redis 子网）、虚拟网络、Azure 负载均衡器 2 |
| 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 子网） |
2 可以使用服务标记“AzureLoadBalancer”（资源管理器）或“AZURE_LOADBALANCER”（经典）来创作 NSG 规则。
在虚拟网络中，可能一开始不符合 Azure Redis 缓存的网络连接要求。 在虚拟网络中使用时，Azure Redis 缓存需要以下所有项才能正常运行。
与全球 Azure 存储终结点建立的出站网络连接。 这包括位于 Azure Redis 缓存实例区域的终结点，以及位于其他 Azure 区域的存储终结点。 Azure 存储终结点在以下 DNS 域之下解析：table.core.chinacloudapi.cn、blob.core.chinacloudapi.cn、queue.core.chinacloudapi.cn 和 file.core.chinacloudapi.cn。
与 ocsp.msocsp.com、mscrl.microsoft.com 和 crl.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。
所以，总结来说，想要将redis部署到虚拟网络，需要满足以下三个条件
有一个独立的subnet用于redis部署
满足redis的出入站要求
Premium版本Redis
部署的过程相对来说就很简单了，在部署redis的时候选择P级别redis, 然后挑选合适的vnet和subnet，可以看到如果subnet不满足条件，会提示subnet中已经有其他资源
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
