Manually migrate layer-7 listeners to ALB

Sample scenario

In the following sample scenario, an enterprise has purchased an Internet-facing CLB instance in the China (Hangzhou) region. The CLB instance is configured with forwarding rules for redirection, domain names, and paths, and provides services over the internet through a domain name. When clients access www.example.net, DNS directs network traffic to the CLB instance based on an A record. The CLB instance then forwards the network traffic to ECS01 and ECS02 based on these rules.

Your company may need to migrate services from a CLB instance to an ALB instance to support business growth. To maintain service stability, you must not change the public-facing DNS domain name or the IP addresses of the backend servers. You can purchase a new ALB instance in the China (Hangzhou) region and complete the required configurations. Ensure that the forwarding rules of the ALB instance provide the same capabilities as your CLB forwarding rules. Then, use the weight settings in your DNS resolution to complete the traffic migration.

Notes

• The billing methods for CLB are pay-as-you-go. The billing method for ALB is pay-as-you-go. The billing items and pricing of CLB and ALB are different. After you migrate services from a CLB instance to an ALB instance, your billing will change. For detailed billing rules, see:

  • Pay-as-you-go CLB

  • ALB billing

• The ALB and CLB instances must use the same backend servers within the same Virtual Private Cloud (VPC).

• You cannot migrate services from the TCP or UDP listeners of a CLB instance to an ALB instance. Only application workloads from HTTP or HTTPS listeners can be migrated.

• You can migrate services from an IPv4 CLB instance to an IPv4 or dual-stack ALB instance. From an IPv6 CLB instance, services can be migrated only to a dual-stack ALB instance.

Prerequisites

• The CLB instance to be migrated has a listener and backend servers configured, and the CLB instance has an A record configured for domain name resolution to provide services externally through a domain name. For more information, see Getting started.

• The backend servers of the CLB instance are ECS01 and ECS02, both of which are in VPC1.

• A redirection rule and forwarding rules are configured for the CLB instance. For more information, see Redirect HTTP requests to HTTPS by using a CLB instance and Forward requests based on a domain name or URL.

• You have created two ECS instances in VPC1: ECS03 for pre-migration testing, and ECS04 for verification during the migration. The dig command is installed on ECS04.

Step 1: Create an ALB instance

1. Log on to the ALB console.

2. On the Instances page, click Create ALB.

3. On the Application Load Balancer (Pay-as-you-go) purchase page, configure the following parameters.

   Parameter	Description
   Region	Select the region where you want to deploy the ALB instance. The region must be the same as that of the CLB instance to be migrated. In this example, China (Hangzhou) is selected.
   Network Type	Select a network type for the instance. The system assigns a private or public IP address to the instance based on your selection. The network type must be the same as that of the CLB instance to be migrated. In this example, Public is selected. Private Network: The ALB instance has only a private IP address, can be accessed only by resources within the same VPC, and is not accessible from the internet. Internet: The ALB instance has both a public IP address and a private IP address. By default, an internet-facing ALB instance uses an elastic IP address (EIP) to provide services over the internet. Selecting Internet incurs EIP instance fees and data transfer fees. Public IP address: The EIP provides internet access to the ALB instance. Private IP address: Resources within the VPC can access the ALB instance. You can change the network type of an ALB instance. For more information, see Change the network type of an ALB instance. Note By default, dual-stack instances use their IPv4 addresses to provide services over the internet. To use the public IPv6 address, you must change the network type. This action incurs IPv6 gateway fees. For more information, see IPv6 gateway billing.
   VPC	Select the VPC that contains the backend servers of the CLB instance to be migrated. In this example, select VPC1.
   Zone ID	Select zones and vSwitches. ALB supports multi-zone deployment. To ensure high availability, select at least two zones if two or more zones are available in the current region. ALB does not charge extra fees for multi-zone deployment. Select a vSwitch in each selected zone. If no vSwitch is available in a zone, create one as prompted. Optional: Select an EIP in each selected zone. If no EIPs are available, you can keep the default option Auto-assign Public IP. The system automatically creates a pay-as-you-go (pay-by-data-transfer) BGP (Multi-ISP) EIP with default security protection and associates it with the ALB instance. Select an existing EIP: You can select an existing EIP and associate it with the new ALB instance. Important You can associate only existing pay-as-you-go (pay-by-data-transfer) EIPs that are not associated with an Internet Shared Bandwidth instance. The EIP type must be the same for all zones of the ALB instance.
   IP Version	Select an IP version for the instance. You can migrate services from an IPv4 CLB instance to an IPv4 or dual-stack ALB instance. You can migrate services from an IPv6 CLB instance only to a dual-stack ALB instance. IPv4: The ALB instance is accessible only via its IPv4 address. Dual-stack: The ALB instance is accessible via both IPv4 and IPv6 addresses. For more information about the limitations on dual-stack ALB instances, see ALB instance overview.
   Edition (Instance Fee)	Select an edition for the instance. Basic: Provides basic ALB features, such as routing based on domain names, URLs, and HTTP headers. Standard: Provides all features of the Basic edition, plus advanced routing features such as custom TLS security policies, redirects, and rewrites. WAF Enabled: In addition to the features of the Standard edition, this edition integrates with Web Application Firewall (WAF) 3.0. Web traffic to listeners on the ALB instance is automatically protected by WAF 3.0. For more information about the limitations of the WAF Enabled edition, see Enable WAF protection for an ALB instance. For more information about differences among the Basic, Standard, and WAF Enabled editions, see Features.
   Associate with Internet Shared Bandwidth	If an ALB instance is not associated with an Internet Shared Bandwidth instance, the default peak bandwidth of a dual-zone ALB instance is 400 Mbit/s. If you need higher bandwidth, select Associate with Internet Shared Bandwidth. You must then select a shared bandwidth package. If no shared bandwidth packages are available, click Purchase Shared Bandwidth Package and complete the purchase. Then, return to the ALB purchase page and click the icon. You can then select a shared bandwidth package. We recommend that you purchase a pay-as-you-go Internet Shared Bandwidth instance. For more information about how to purchase an Internet Shared Bandwidth instance, see Create and manage Internet Shared Bandwidth instances. Note This parameter is available only if you set Network Type to Public.
   Internet Metering Method	By default, Pay-By-Data-Transfer is selected. With the pay-by-data-transfer billing method, the peak bandwidth is an upper limit and for reference only, not a guaranteed metric. The actual bandwidth may be limited during periods of resource contention. For more information about EIP billing, see EIP billing. Note This parameter is available only if you set Network Type to Public and do not select Associate with Internet Shared Bandwidth.
   Instance Name	Enter a name for the instance.
   Resource Group	Select the resource group for the ALB instance.
   Note:	The first time you create an ALB instance, click Create to create a service-linked role. The service-linked role allows ALB to access other cloud services and resources, such as elastic network interfaces (ENIs), security groups, EIPs, and Internet Shared Bandwidth instances. For more information, see Service-linked roles for ALB. Note This parameter is displayed only when you create an ALB instance for the first time.

4. Click Buy Now and follow the on-screen instructions to create the instance.

Step 2: Create an ALB server group

1. Log on to the ALB console.

2. In the top navigation bar, select the region where the ALB instance is deployed. For this example, select China (Hangzhou).

3. In the left-side navigation pane, choose ALB > Server Groups.

4. On the Server Groups page, click Create Server Group.

5. In the Create Server Group dialog box, configure the following parameters and click Create.

   The following table describes the key parameters for this tutorial. Use the default values for all other parameters. For more information, see Create and manage server groups.

   Parameter	Description
   Server Group Type	Select Server.
   Server Group Name	Enter a name for the server group. This tutorial uses RS1.
   VPC	Select a VPC from the VPC dropdown list. Only servers in the selected VPC can be added to this server group. In this topic, select VPC1. This is the VPC that contains the backend servers of the CLB instance to be migrated.
   Backend Server Protocol	Select HTTP.
   Scheduling Algorithm	Select Weighted Round-robin.

6. In the dialog box that appears, click Add Backend Server. Then, on the Backend Servers tab, click Add Backend Server.

7. In the Add Backend Server panel, select the backend servers used by the CLB instance that you are migrating, and then click Next.

   This example uses ECS01 and ECS02.

8. In the Ports/Weights wizard, set the port and weight for each ECS instance, and then click OK.

   For this example, set the port to 80 and use the default weight of 100.

   Note

   To handle traffic surges or scheduled peaks while managing costs, you can use Auto Scaling to automatically add or remove backend servers for an ALB instance.

Step 3: Configure ALB listeners

Add HTTP and HTTPS listeners

1. Log on to the ALB console.

2. In the top navigation bar, select the region where the ALB instance is deployed. For this example, select China (Hangzhou).

3. To open the listener configuration wizard, use one of the following methods:

   • On the Instances page, find the target instance and click Create Listener in the Actions column.

   • On the Instances page, click the ID of the target instance. On the Listener tab, click Create Listener.

4. In the Configure Listener step, configure the following parameters and click Next.

   Parameter	Description
   Listener Protocol	Select the protocol for the listener. In this example, HTTP is selected.
   Listener Port	Specify the port to receive requests and forward them to backend servers. The port number must be between 1 and 65535. In most cases, port 80 is used for HTTP and port 443 is used for HTTPS. Note The listener ports within an ALB instance must be unique. In this example, enter 80.
   Listener Name	Enter a name for the listener.
   Advanced Settings	Click Modify to expand the advanced settings. In this example, the default settings are used.

5. In the Select Server Group step, select a server group of the Server type, view the backend server information, and then click Next.

   In this example, the RS1 server group is selected.

6. In the Configuration Review step, confirm the configurations and click Submit.

7. Follow the instructions in Add an HTTPS listener to configure the HTTPS listener.

   The key parameters for this topic are:

   • Listener Protocol: Select HTTPS.

   • Listener Port: Enter 443.

Configure redirection

Configure a redirect forwarding rule for the HTTP listener of the ALB instance to redirect all HTTP requests received by the ALB instance to HTTPS on port 443.

1. On the Listener tab, click the ID of the HTTP listener that you created. On the listener details page, click the Forwarding Rules tab.

2. On the Forwarding Rules tab, click Add New Rule.

3. In the Add Forwarding Rule section, configure the following parameters and click OK.

   Configuration	Description
   Add Condition	From the drop-down list, select Path and Exact & Wildcard Pattern Matching. In this example, enter /*.
   Action	From the drop-down list, select Redirect and configure the following parameters. Protocol: In this example, HTTPS is selected. Domain Name: In this example, the default value ${host} is used. Port: Enter the port of the HTTPS listener that you created. In this example, enter 443. Path: In this example, the default value ${path} is used. Search: In this example, the default value ${query} is used. Status Code: In this example, 301 is selected.

Configure domain and path forwarding

Configure domain name- and path-based forwarding rules for the HTTPS listener of the ALB instance.

1. Return to the Listener tab and click the ID of the HTTPS listener that you created. On the listener details page, click the Forwarding Rules tab.

2. On the Forwarding Rules tab, click Add New Rule.

3. In the Add Forwarding Rule section, configure the following parameters and click OK.

   Configuration	Description
   Add Condition	From the drop-down list, select Domain Name and Exact & Wildcard Pattern Matching. In this example, enter www.example.net. Click Add Condition, select Path from the drop-down list, and then enter /home*.
   Action	Select Forward, and then select a server group of the Server type. In this example, the RS1 server group is selected. Note Ensure the selected server group contains the same backend servers as the vServer group used in the forwarding policy of the source CLB instance.

Step 4: Test traffic

Enable access logs

ALB integrates with Log Service (SLS) to provide access logs. Use them to monitor the load on your ALB instances and troubleshoot issues.

1. Log on to the ALB console.

2. In the top navigation bar, select the region where the ALB instance is deployed. For this example, select China (Hangzhou).

3. On the Instances page, find the target ALB instance and click its instance ID.

4. On the instance details page, click the Access Logs tab. On the Access Logs tab, click Create Access Log.

5. In the Create Access Log dialog box, configure the Project and Logstore, and then click OK. In the confirmation message that appears, click OK.

   Parameter	Description
   Project	A resource management unit in Log Service (SLS) for resource isolation and control. Select Project: Select a Project from the drop-down list. Create Project: Enter a name for the Project.
   Logstore	A unit in Log Service (SLS) that collects, stores, and queries log data. Select Logstore: Select a Logstore from the drop-down list. Create Logstore: Enter a name for the new Logstore. If you create a new Project, you must also create a new Logstore.
   Notes on Creating Service-linked Role	This operation automatically creates the service-linked role required to enable this feature.

Test traffic

1. Connect to ECS03. For more information, see Remote connection methods for ECS instances.

2. To modify the hosts file, run the following command:

   sudo vi /etc/hosts

   In the hosts file, add the IP address and domain name of the ALB instance. Save your changes and exit.

   118.XX.XX.39 www.example.net

3. To test the redirect configuration, run the following command:

   curl -X GET -L -v   http://www.example.net

   The following output is returned:

   # curl -X GET -L -v   http://www.example.net
   * About to connect() to www.example.net port 80 (#0)
   *   Trying 118.XX.XX.39...
   * Connected to www.example.net (118.XX.XX.39) port 80 (#0)
   > GET / HTTP/1.1
   > User-Agent: curl/7.29.0
   > Host: www.example.net
   > Accept: */*
   > 
   < HTTP/1.1 301 Moved Permanently
   < Date: Mon, 16 Jan 2023 08:28:46 GMT
   < Content-Type: text/html
   < Content-Length: 178
   < Connection: keep-alive
   < Location: https://www.example.net/
   < Via: HTTP/1.1 SLB.130

4. Return to the ALB console, navigate to the Access Logs tab for the target ALB instance, and click the Simple Log Service link to view the access log.

   In the Log Service console, use the request_uri, http_host, upstream_addr, and status fields to review the runtime logs for the domain name- and path-based forwarding rules of ALB.

Step 5: Migrate workloads to ALB

The following steps assume that your Classic Load Balancer (CLB) is configured to redirect requests from HTTP port 80 to HTTPS port 443. The configuration supports multiple domain names over HTTPS. The domain name used in this topic is example.net.

Before the workload migration, DNS resolution is configured for the CLB instance. An A record maps the service domain name to the service address of the CLB instance.

After validating the configuration of the ALB instance, migrate the workload from CLB to ALB. This topic uses Alibaba Cloud DNS as an example to demonstrate the migration. For more information about Alibaba Cloud DNS, see Public Zone.

Step 1: Configure a temporary domain and add a CNAME record

1. Log on to the Alibaba Cloud DNS console.

2. On the Public Zone page, find and click the domain name example.net that is used by the CLB instance that you want to migrate.

3. On the Settings page, find the A record that points to the service address of the CLB instance to be migrated, and in the Actions column, click Modify.

4. In the Edit Record panel that appears, modify the Hostname, and then click OK. In this example, the Hostname is changed to web0, and the other parameters remain unchanged.

5. On the Settings page, click Add Record. In the Add Record panel, configure the following parameters and click OK.

   Parameter	Description
   Record Type	Select CNAME from the drop-down list.
   Hostname	Enter the prefix of your domain name. In this example, enter www.
   Query Source	Select Default.
   TTL	Time to Live (TTL) specifies how long a DNS record is cached on a DNS server. In this example, set the value to 5 seconds.
   Record Value	Enter the temporary domain name. In this example, enter web0.example.net.

Step 2: Add a CNAME record for the ALB instance

On the Settings page, click Add Record. In the Add Record panel, configure the following parameters and click OK.

Step 3: Set weights for canary release

1. On the Settings page, find the CNAME record that you added in Step 2. Click the drop-down arrow next to Modify and select Edit Record Set.

2. In the Edit Record panel, under Record Values, set the weights for the DNS records for the CLB and ALB instances. Set the weight of the DNS record for the CLB instance to 100, and set the weight of the DNS record for the ALB instance to 0. Click OK to save and exit.

3. If you observe that your services are not affected, gradually decrease the weight of the DNS record for the CLB instance and, at the same time, gradually increase the weight of the DNS record for the ALB instance.

4. Log on to the ECS04 instance, execute the dig command multiple times, and verify the effect of the traffic migration.

   dig www.example.net

   The following output is returned. By running the command multiple times, you can see that requests are routed to the ALB or CLB instance based on the configured weights.

   # dig www.example.net
   
   ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10 <<>> www.example.net
   ;; global options: +cmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31592
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
   
   ;; QUESTION SECTION:
   ;www.example.net.                IN      A
   
   ;; ANSWER SECTION:
   www.example.net.     5     IN      CNAME   web0.example.net.
   web0.example.net.    5     IN      A       47.XX.XX.144
   
   ;; Query time: 63 msec
   ;; SERVER: 100.XX.XX.136#53(100.XX.XX.136)
   ;; WHEN: Thu Jan 19 15:46:40 CST 2023
   ;; MSG SIZE  rcvd: 66

   # dig www.example.net
   
   ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10 <<>> www.example.net
   ;; global options: +cmd
   ;; Got answer:
   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14224
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
   
   ;; QUESTION SECTION:
   ;www.example.net.                IN      A
   
   ;; ANSWER SECTION:
   www.example.net.     5     IN      CNAME   alb-a8mmh2XXX.cn-hangzhou.alb.aliyuncs.com.
   alb-a8mXXX.cn-hangzhou.alb.aliyuncs.com. 60 IN A 116.XX.XX.54
   alb-a8mXXX.cn-hangzhou.alb.aliyuncs.com. 60 IN A 118.XX.XX.39
   
   ;; Query time: 4 msec
   ;; SERVER: 100.XX.XX.136#53(100.XX.XX.136)
   ;; WHEN: Thu Jan 19 15:47:52 CST 2023
   ;; MSG SIZE  rcvd: 128

Step 4: Complete the migration

Based on the traffic migration verification results, gradually decrease the weight of the DNS record for the CLB instance to 0, while gradually increasing the weight of the DNS record for the ALB instance to 100. At this point, you have completed the migration of traffic from the CLB instance to the ALB instance. After all long-lived connections to the CLB instance are closed and the CLB instance receives no new traffic, you can monitor the instance for a period of time based on your business needs and then release the CLB instance. For more information about how to release a CLB instance, see Create and manage CLB instances.

After the migration, the access path for the ALB instance is as follows:

View an alternative solution if your DNS provider does not support weighted CNAME records.

Advanced features

FAQ

1. Which configurations must be the same for the CLB and ALB instances before and after migration?

   The region, network type, listener protocol, and backend servers must be the same. The ALB instance must be deployed in the same VPC as the CLB instance's backend servers, but it can be in a different zone.

2. What are the differences between the certificates used by CLB and ALB?

   Both CLB and ALB support HTTPS encryption. While CLB natively supports certificates issued by Alibaba Cloud and third-party certificates, ALB uses certificates managed by Certificate Management Service.

   • For a CLB instance, see Upload certificates.

   • For an ALB instance, see Purchase an SSL certificate and Upload, sync, and share SSL certificates.

3. What are the differences in access control between CLB and ALB?

   • CLB provides listener-level access control, which allows you to set unique access policies for each listener. For more information, see access control.

   • ALB instances support both IPv4 and dual-stack. ALB IPv4 instances allow you to set unique access policies for each listener. For more information, see access control. However, ALB dual-stack instances do not support access control.

4. What are the differences in domain name resolution between CLB and ALB?

   • For a CLB instance, use an A record to map your custom domain name to the service address of the CLB instance.

   • For an ALB instance:

     • We recommend using a CNAME record to map your custom domain name to the DNS name of the ALB instance for easier access.

     • If your custom domain name requires a fixed IP address, use an ALB instance in static IP mode. Then, use an A record to map your custom domain name to the ALB instance's IP address.

Related topics

• SLB product family

• What is Application Load Balancer (ALB)?

• ALB instance overview

• Features

• ALB billing

• Quotas and limits

• Enabling WAF for an ALB instance

• Migrating Layer 7 listeners from CLB to ALB in one click