Deleting a Dedicated Load Balancer

Scenarios

Call APIs to delete a dedicated load balancer.

Before you delete a dedicated load balancer, delete all resources associated with it. Figure 1 shows the associated resources.

Figure 1 Resources associated with a dedicated load balancer

Procedure

Perform the following steps to delete the associated resources and the load balancer. Skip the corresponding step if the associated resources do not exist. For example, you can skip 1 if no health check is configured.

1. Delete the health check configured for each associated backend server group.
   1. Send DELETE https://{elb_endpoint}/v3/{project_id}/elb/healthmonitors/{healthmonitor_id}. project_id indicates the project ID, and healthmonitor_id indicates the health check ID.
   2. Add X-Auth-Token to the request header.
   3. Check the response.
      • If the request is successful, 204 is returned, and the response body is empty.
      • If the request is abnormal, locate the fault by referring to Error Codes.
2. Remove backend servers from each associated backend server group.
   1. Send DELETE https://{elb_endpoint}/v3/{project_id}/elb/pools/{pool_id}/members/{member_id}. project_id indicates the project ID, pool_id indicates the backend server group ID, and member_id indicates the backend server ID.
   2. Add X-Auth-Token to the request header.
   3. Check the response.
      • If the request is successful, 204 is returned, and the response body is empty.
      • If the request is abnormal, locate the fault by referring to Error Codes.
3. Delete each associated backend server group.
   1. Send DELETE https://{elb_endpoint}/v3/{project_id}/elb/pools/{pool_id}. project_id indicates the project ID, and pool_id indicates the backend server group ID.
   2. Add X-Auth-Token to the request header.
   3. Check the response.
      • If the request is successful, 204 is returned, and the response body is empty.
      • If the request is abnormal, locate the fault by referring to Error Codes.
4. Delete the forwarding rules added to each listener.
   1. Send DELETE https://{elb_endpoint}/v3/{project_id}/elb/l7policies/{policy_id}/rules/{rule_id}. project_id indicates the project ID, policy_id indicates the forwarding policy ID, and rule_id indicates the forwarding rule ID.
   2. Add X-Auth-Token to the request header.
   3. Check the response.
      • If the request is successful, 204 is returned, and the response body is empty.
      • If the request is abnormal, locate the fault by referring to Error Codes.
5. Delete the forwarding policies added to each listener.
   1. Send DELETE https://{elb_endpoint}/v3/{project_id}/elb/l7policies/{policy_id}. project_id indicates the project ID, and policy_id indicates the forwarding policy ID.
   2. Add X-Auth-Token to the request header.
   3. Check the response.
      • If the request is successful, 204 is returned, and the response body is empty.
      • If the request is abnormal, locate the fault by referring to Error Codes.
6. Delete each listener added to the load balancer.
   1. Send DELETE https://{elb_endpoint}/v3/{project_id}/elb/listeners/{listener_id}. project_id indicates the project ID, and listener_id indicates the listener ID.
   2. Add X-Auth-Token to the request header.
   3. Check the response.
      • If the request is successful, 204 is returned, and the response body is empty.
      • If the request is abnormal, locate the fault by referring to Error Codes.
7. Delete the load balancer.
   1. Send DELETE https://{elb_endpoint}/v3/{project_id}/elbloadbalancers/{loadbalancer_id}. project_id indicates the project ID, and loadbalancer_id indicates the load balancer ID.
   2. Add X-Auth-Token to the request header.
   3. Check the response.
      • If the request is successful, 204 is returned, and the response body is empty.
      • If the request is abnormal, locate the fault by referring to Error Codes.