Overview

You can plan hostnames based on the locations, usages, and account information of ECSs, and map the hostnames to private IP addresses of ECSs. This helps you manage ECSs more easily.

For example, if you have deployed 20 ECSs in an AZ, 10 used for website A and 10 for website B, you can plan their hostnames and private zones as follows:

• ECSs for website A: weba01.region1.az1.com – weba10.region1.az1.com
• ECSs for website B: webb01.region1.az1.com – webb10.region1.az1.com

After planning, you can quickly identify the locations and purposes of ECSs during routine management and maintenance.

For details about how to create private zones and map the hostnames to the private IP addresses of ECSs, see Configuring Private Domain Name Resolution for ECSs.

As Internet users are surging, a website application deployed only on one server may corrupt upon spiking concurrent requests. The common practice is to spread service load to multiple servers.

Multiple ECSs are deployed in the same VPC and communicate with each other using private IP addresses. The private IP addresses are coded into the internal APIs called among the ECSs. If one ECS is replaced in the system, the private IP address changes accordingly. In this case, you also need to change that IP address in the APIs and re-publish the website. This makes system maintenance inconvenient.

If you create a private zone for each ECS and configure record sets to map domain names to their private IP addresses, the ECSs will be able to communicate over private zones. When you replace one of the ECSs, you only need to change the IP address in record sets, instead of modifying the code.

Figure 2 shows a typical application scenario of private zones.

Figure 2 Configuring private zones for ECSs

ECS and RDS are deployed in a VPC. ECS and RDS nodes are described as follows:

• ECS0: primary service node
• ECS1: public service node
• RDS1: database node
• ECS2 and RDS2: backup service node and backup database node

When ECS1 becomes faulty, ECS2 must take over. However, if no private zones are configured for the two ECSs, you need to change the private IP addresses in the code for ECS0. Such change will interrupt services, and you must publish the website again.

Now assume that you have configured private zones for the ECSs and have written these zones in the code. After ECS1 becomes faulty, you only need to change the DNS records to redirect services to ECS2, without interrupting services or re-publish the website.

For details about how to create private zones for ECSs and add record sets, see Configuring a Private Domain Name for an ECS.

Configure private zones for ECSs so that they can access other cloud services, such as SMN and OBS, without connecting to the Internet.

When you create an ECS, note the following:

• If public DNS servers are configured for the VPC subnet where the ECS is running, requests to access cloud services will be routed over the Internet.

  Figure 3 shows the process for resolving a domain name when an ECS accesses Huawei cloud services such as OBS and SMN.

  The request redirected to the Internet has long access latency and poor experience.

• If a private DNS server is configured for the subnet, the private DNS server directly processes the requests to access cloud services.

  When the ECS accesses the Huawei cloud services, the private DNS server returns their private IP addresses, instead of routing requests over the Internet. This reduces network latency and improves access speed. Steps 1 to 4 on the left of Figure 3 show the process.

  To make your ECS accessible within the private network, change the default DNS servers of the ECS to private DNS servers, see How Do I Change Default DNS Servers of an ECS to Huawei Cloud Private DNS Servers?

Figure 3 Accessing cloud services