One-click migration of Layer-7 listeners to ALB

Migration limitations

Supported CLB instance types

• Internal-facing IPv4 CLB instances in a VPC that have a Layer 7 listener (HTTP or HTTPS) configured.

• Internet-facing IPv4 CLB instances that have a Layer 7 listener (HTTP or HTTPS) configured.

Unsupported scenarios

The migration wizard does not support the following scenarios. We recommend that you manually migrate Layer 7 listeners from CLB to ALB.

• CLB instances that do not have an HTTP or HTTPS listener configured.

• Internal-facing CLB instances in a classic network.

• IPv6 CLB instances.

Migration considerations

• Migration is not supported in regions where ALB is unavailable. For information about the regions that support ALB, see Regions and zones that support ALB.

• The migration wizard does not migrate WAF configurations. If WAF is enabled for the CLB instance, you must manually enable WAF protection for the destination ALB instance after the migration. We recommend that you enable WAF 3.0 for the new ALB instance. For more information, see Enable WAF protection for an ALB instance.

• The migration wizard does not migrate threshold-based alert rules for CLB. You must configure new alert rules for the ALB instance using the CloudMonitor console, API operations, or SDKs. For more information, see Configure alert rules for ALB metrics.

• DDoS protection is enabled by default for the ALB instance. However, the migration wizard does not migrate custom DDoS protection thresholds. You must manually configure these thresholds in the Traffic Security console after the migration.

• The migration wizard does not migrate access control configurations. If you need access control, you must configure it for the ALB instance after the migration. For more information, see Access control.

• For an HTTPS listener, you must manually specify the server certificate and CA certificate.

• The migration wizard does not migrate CLB primary/secondary server group configurations.

• The migration wizard automatically migrates backend servers of an internal-facing CLB instance. However, it does not currently migrate backend servers of an internet-facing CLB instance. The migration wizard creates a new server group in the VPC where the ALB instance resides. You must manually add backend servers to this server group. The backend servers must be in the same VPC as the ALB instance.

Billing

The one-click migration from CLB to ALB incurs no additional charges. The new ALB instance is billed according to ALB billing rules.

• ALB billing rules

• Pay-as-you-go CLB billing rules

Prerequisites

• Configure a Layer 7 listener (an HTTP or HTTPS listener) on the CLB instance that you plan to migrate.

• This example uses four ECS instances.

  • Application servers: ECS01 and ECS02 are the backend servers.

  • Test servers: Use ECS03 to test traffic before the migration and ECS04 to verify traffic during the migration.

    If you already have test servers, you do not need to create ECS03 and ECS04.

Step 1: Use the migration wizard

1. Open the migration wizard using one of the following methods.

   Method 1: CLB console

   1. Log on to the CLB console.

   2. In the top navigation bar, select the region of the CLB instance.

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

   4. Click the Migration Wizard tab. After confirming the information in the message, click Enable on the Migrate from CLB to ALB card.

   Method 2: ALB console

   Note

   This method is unavailable if no ALB instances exist in the region of the CLB instance to be migrated. Use Method 1 instead.

   1. Log on to the ALB console.

   2. In the top navigation bar, select the region of the CLB instance.

   3. On the Instances page, click Migrate from CLB to ALB.

   4. In the Migrate from CLB to ALB dialog box, confirm the information in the message, select the CLB instance to migrate, and then click Open Migration Wizard.

2. In the Review Configurations step, review the basic information of the CLB instance and the pre-configured information for the ALB instance. Configure all listeners marked with the icon, select the confirmation checkbox, and then click Next.

   • : Indicates a configuration item that requires manual configuration.

   • : Indicates a configuration item that the system modifies automatically.

   You can click Modify Listener and Modify Certificate to modify the ALB listener configurations. You can modify certificates only for HTTPS listeners.

3. In the Create Instance step, configure the VPC and vSwitch for the new ALB instance, and then click Next.

   Parameter	Description
   VPC	For an internal-facing CLB instance, the new ALB instance is deployed in the same VPC as the CLB instance by default. For an Internet-facing CLB instance, you must select a VPC.
   Zone	Select a zone and a vSwitch. For high availability, we recommend selecting at least two zones if the current region supports two or more zones. ALB does not charge extra for using multiple zones. Select a vSwitch in each selected zone. If no vSwitches are available in a zone, create one as prompted on the console. Optional: When you migrate an Internet-facing CLB instance, you must select an elastic IP address (EIP) in each selected zone. If no existing EIP is available, you can select Purchase EIP. The system automatically creates a pay-as-you-go (pay-by-data-transfer) BGP (Multi-ISP) elastic IP address (EIP) with Anti-DDoS Origin Basic protection and associates it with the ALB instance. You can also associate an existing EIP with the new ALB instance. Important You can associate only pay-as-you-go (pay-by-data-transfer) EIPs that are not part of an Internet Shared Bandwidth instance. EIPs in different zones for the same ALB instance must be of the same type.

4. In the Confirm Order step, review the configurations of the ALB instance, select the checkbox in the Pricing/Billing section, and then click Start Migration.

5. In the Complete step, wait for the migration to complete. You can then perform the following operations.

   Resource Orchestration Service (ROS) performs the migration, which takes 1 to 10 minutes. You can follow the prompts to navigate to the ROS console and view the status of the migration task in the corresponding stack.

   • Click View Instance to go to the details page of the new ALB instance.

   • Click CLB Instance List to return to the list of CLB instances.

   • Click ALB Instance List to return to the list of ALB instances.

6. Next steps: After the migration, verify that backend servers are added to the new ALB instance.

   1. In the navigation pane on the left, choose ALB > Instances.

   2. On the Instances page, find the new ALB instance and click its ID.

   3. Click the Listener tab. Find the target listener and click View Details in the Actions column.

   4. On the Listener Details tab, click View/Modify Backend Server in the Server Group (Default Forwarding Rule) section. On the Backend Servers tab that appears, check if any backend servers are listed.

      If no backend servers are listed, click Add Backend Server to add at least two. You must also deploy applications on them so the ALB instance can distribute requests. In this example, ECS01 and ECS02 are added as backend servers to the ALB instance.

      • For more information about how to create an ECS instance, see Create an instance by using the wizard.

      • The following example shows the commands to deploy test applications on ECS01 and ECS02:

        Commands for deploying an application on ECS01

        yum install -y nginx
        systemctl start nginx.service
        cd /usr/share/nginx/html/
        echo "Hello World ! This is ECS01." > index.html
        

        Commands for deploying an application on ECS02

        yum install -y nginx
        systemctl start nginx.service
        cd /usr/share/nginx/html/
        echo "Hello World ! This is ECS02." > index.html
        

Step 2: Test traffic

(Optional) Enable access logs

ALB integrates with Simple Log Service (SLS) to provide access logs. Use access logs to monitor the load on 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.

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

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

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

   Parameter	Description
   Project	A resource management unit in Simple Log Service used for resource isolation and control. Select Project: Select a Project from the drop-down list. Create Project: Enter a name for the new Project.
   Logstore	A unit in Simple Log Service used for collecting, storing, and querying log data. Select Logstore: Select a Logstore from the drop-down list. Create Logstore: Enter a name for the new Logstore. If you choose to create a new Project, you must also create a new Logstore.
   Notes on Creating Service-linked Role	This operation automatically creates a service-linked role with the required permissions.

Test traffic

1. Remotely log in to ECS03.

   Note

   This ECS03 instance has a public IP address.

2. Run the following command to modify the hosts file.

   sudo vi /etc/hosts

   In the hosts file, add the elastic IP address and domain name of the ALB instance, and then save and close the file.

   118.XX.XX.113 www.example.net

3. Run the following command to test traffic forwarding through the ALB instance.

   curl -v www.example.net

   The following figure shows the expected output:

   

4. (Optional) To view the access logs, return to the ALB console. On the Access Logs tab for your ALB instance, click the link next to Simple Log Service.

   In the Simple Log Service console, you can also combine fields such as request_uri, http_host, upstream_addr, and status as needed to view the runtime logs of an ALB domain name or URL-based forwarding rules.

Step 3: Migrate traffic to the ALB instance

The following steps assume that DNS resolution is already configured for the CLB instance, with an A record pointing the service domain name to the service address of the CLB instance. After you verify the configuration of the ALB instance, migrate traffic from the CLB instance to the ALB instance as follows. This topic uses Alibaba Cloud DNS as an example. For more information about Alibaba Cloud DNS, see Public Authoritative DNS Resolution.

Step 1: Configure a temporary domain and 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 for the CLB instance.

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

4. In the Edit Record panel, change the Hostname, and then click OK. In this example, the Hostname is changed to web0. Keep the other parameters 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	The prefix of your domain name. In this example, enter www.
   DNS Query Source	Select Default.
   TTL	Time to Live (TTL), which controls how long a DNS record is cached on DNS servers. 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 ALB

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

Step 3: Set weights and start the canary release

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

2. In the Record Values section at the bottom of the Edit Record panel, set the weights for the DNS records of the CLB and ALB instances as follows: set the weight of the DNS record for the CLB instance to 100, and the weight of the DNS record for the ALB instance to 0. Click OK to save your changes and exit.

   

3. After you verify that your services are not affected, gradually decrease the weight of the DNS record for the CLB instance and increase the weight of the DNS record for the ALB instance.

4. Log on to the ECS04 instance in the same VPC as the ALB instance, and run the dig command multiple times to verify the traffic migration.

   Note

   Ensure the ECS04 instance has a public IP address and install the dig command by running yum install bind-utils.

   dig www.example.net

   The following figure shows the command output. The results show that requests are distributed to the ALB or CLB instance based on the configured weights.

   

Step 4: Complete the traffic migration

Based on the traffic migration verification results, gradually decrease the weight of the DNS record for the CLB instance to 0 and, at the same time, gradually increase the weight of the DNS record for the ALB instance to 100. This completes the traffic migration from the CLB instance to the ALB instance. When all long-lived connections on the CLB instance are fully processed and the CLB instance receives no new traffic, you can monitor the instance for a period of time based on your business scenario and then release the CLB instance. For more information about how to release a CLB instance, see Release a CLB instance.

If your DNS provider does not support weighted CNAME records, click to view an alternative migration plan.

FAQ