Shulou(Shulou.com)06/03 Report--

Following the content of the previous article, let's take a look at the other options provided in Azure Redis deployment. As mentioned in the previous article, in the Azure Redis Premium version, we can support the deployment of Redis in VNET. This benefit is obvious. We can use rules such as NSG to control the traffic in and out of redis, so as to protect the security of redis. But does it mean that there is no way to protect the network security of Redis if it is not the Redis version of Premium? Of course, this is not the case. Even if it is the redis of standard, we can still protect the security of redis by adding a whitelist in Firewall.

Of course, this is only a whitelist for the public network. Redis itself is still equivalent to being deployed in internet rather than a private network. If you want applications to access redis in a way that accesses content, you need to deploy Redis in a virtual network.

Redis virtual network deployment has the following main advantages:

Have a fixed static private ip

You can use NSG to control inbound and outbound traffic

Lower application access latency

Of course, in order to deploy in a virtual network, Redis also requires that we must have a separate subnet for redis deployment. What is the concept? If you have used application gateway, it is easy to understand this concept. Application gateway also requires that it must be deployed in a separate subnet. This subnet can only deploy application gateway resources, not any other resources. Redis is the same concept, which is a prerequisite for redis deployment in a virtual network.

In addition, if there are scenarios with strict requirements for inbound and outbound traffic, Redis also requires inbound or outbound permissions for specific servers and addresses, and redis needs to communicate with some management nodes regularly to maintain the state of redis itself.

The following is a detailed description of these requirements. If the network port does not meet the conditions, you will find that the redis deployment will report an error, timeout, and so on.

Outbound port requirement

There are seven requirements for outbound ports.

All outbound connections to the Internet can be established through the client's local audit device.

Three of these ports route traffic to Azure endpoints that serve Azure storage and Azure DNS.

The remaining port range, which is used for internal Redis subnet communication. Subnet NSG rules are not required for internal Redis subnet communication.

Port-oriented transport protocol destination local IP remote IP80, 443 Redis dependencies on outbound TCPAzure storage / PKI (Internet) * 53 Redis dependencies on outbound TCP/UDPDNS (Internet/VNet) (Redis subnets) 168.63.129.16 and 169.254.169.254 1 and any custom DNS servers in subnets 38443 outbound TCPRedis intercom (Redis subnet) (Redis subnet) 10221-10231 outbound TCPRedis intercom (Redis subnet) (Redis subnet) 20226 Internal communication of outbound TCPRedis (Redis subnet) (Redis subnet) 13000-13999 internal communication of outbound TCPRedis (Redis subnet) (Redis subnet) 15000-15999 internal communication of outbound TCPRedis and off-site replication (Redis subnet) (Redis subnet) (geographical replica peer subnet) 6379-6380 internal communication of outbound TCPRedis (Redis subnet) (Redis subnet)

These IP addresses owned by 1 Microsoft are used to address the host VM that serves the Azure DNS.

3 No subnet of the custom DNS server or update redis cache that ignores the custom DNS is not required.

Copy peer port requirements offsite

If offsite replication is used between caches in an Azure virtual network, note that the recommended configuration is to unblock ports 15000-15999 of the entire subnet in the inbound and outbound directions of the two caches, so that all replica components in the subnet can communicate directly with each other even if an offsite failover occurs in the future.

Inbound port requirement

There are eight requirements for the inbound port range. Inbound requests in these ranges are inbound from other services hosted in the same VNET, or internal requests for communication in the Redis subnet.

Port-oriented transfer protocol destination local IP remote IP6379, 6380 inbound TCP client communication with Redis, Azure load balancer (Redis subnet) (Redis subnet), virtual network, Azure load balancer 28443 inbound TCPRedis intercommunication (Redis subnet) (Redis subnet) 8500 inbound TCP/UDPAzure load balancer (Redis subnet) Azure load balancer 10221-10231 inbound TCPRedis intercom (Redis subnet), Azure load balancer 13000-13999 client communication between inbound TCP and Redis cluster, Azure load balancer (Redis subnet) virtual network, Azure load balancer 15000-15999 inbound TCP and Redis cluster client communication, Azure load balancing and offsite replication (Redis subnet) virtual network, Azure load balancer (regional replica peer subnet) 16001 inbound TCP/UDPAzure load balancer (Redis subnet) Azure load balancer 20226 inbound TCPRedis intercom (Redis subnet) (Redis subnet)

2 you can use the service tag "AzureLoadBalancer" (resource manager) or "AZURE_LOADBALANCER" (classic) to author NSG rules.

Other VNET network connection requirements

In a virtual network, the network connection requirements of the Azure Redis cache may not be met at first. When used in a virtual network, the Azure Redis cache requires all of the following to function properly.

Outbound network connection to the global Azure storage termination point. This includes endpoints located in the Azure Redis cache instance area and storage endpoints in other Azure areas. Azure storage endpoints are resolved under the following DNS domains: table.core.chinacloudapi.cn, blob.core.chinacloudapi.cn, queue.core.chinacloudapi.cn, and file.core.chinacloudapi.cn.

Outbound network connections to ocsp.msocsp.com, mscrl.microsoft.com, and crl.microsoft.com. This connection is required to support SSL functionality.

The DNS setting of the virtual network must be able to resolve all the endpoints and domains mentioned above. Ensure that an effective DNS infrastructure is configured and maintained for the virtual network to meet these DNS requirements.

Outbound network connection to the following Azure monitoring endpoints (resolved under the following DNS domains): 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.

So, to sum up, to deploy redis to a virtual network, you need to meet the following three conditions

There is a separate subnet for redis deployment

Meet the entry and exit requirements of redis

Premium version of Redis

The process of deployment is relatively simple. When deploying redis, select P-level redis, and then select the appropriate vnet and subnet. You can see that if subnet does not meet the conditions, it will prompt you that there are other resources in the subnet.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.