You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 34 Next »

Introduction

This documents gives an overview to the design and functional implementation for Internal Load Balancing on VPC tiers.

Feature developers:

  • APIs and Business logic - Alena Prokharchyk
  • Backend - to be assigned

Use case

There are 2 tiers in the VPC - Web tier and Application tier. Traffic to Web tier is balanced on the VPC VR on the public side. User wants traffic coming from Web to the App tier to be balanced as well. Load balancing on the App tier will be covered by the Internal LB feature.

Internal LB can be handled by 2 network providers:

  • InternalLBVm - have to add support for this provider first.
  • Netscaler VPX

Glossary

  • Internal LB - the load balancing between internal (guest) cloudStack networks
  • Internal LB Rule- Load balancer rule with the front end IP from Internal (Guest) cloudStack network.
  • Internal LB VM - cloudStack system vm managing internal LB Rules

General flow

Example with Internal LB VM:

  1. Create App tier using network offering with Service=LB, Provider=InteralLBVm, LB service capability schema=Internal.
  2. Create LoadBalancingRule LB Rule1 - specify source Ip1, source port 80, dest port 80, schema=Internal. If the source IP1 is not acquired yet and it's free, it will be acquired automatically. New internal LB VM starts with IP1 on App tier, and this VM will manage all LB rules created for IP1.
  3. Add vm1 to the LB1. The rule for Ip1/VM1/ports 80:80 gets configured inside the HA proxy
  4. Add vm2 to the LB1. The rule for IP1/VM2/80:80 gets configured inside the HA Proxy
  5. Create Internal Load Balancer LB Rule2. This time don't specify the source IP address. The random source IP2 will get acquired from the guest network, assigned to the LoadBalancingRule and will be returned to the end user in the API response. New internal LB VM will start with IP2 on APP tier, and it will manage all LB rules created for IP2.
  6. If you want to manage access from Web tier to the App tier, setup Network ACLs on the VPC VR

The pic below is for the case when InternalLBVm is used as a provider for the LB service on internal tier:

  1. Public LB rule for 72.52.125.10 Public IP, public port 80 and private port 81. It enables LB for traffic coming from the internet to the vms on the Web tier. The LB rule is configured on the VPC VR.
  2. Internal LB rule #1 for 10.10.10.4 guest IP, loadBalancerPort 23 and instancePort 25. The LB rule is configured on InternalLBVM1.
  3. Internal LB rule #2 for 10.10.10.4 guest IP, loadBalancerPort 45 and instancePort 46. The LB rule is configured on InternalLBVM1.
  4. Internal LB rule #3 for 10.10.10.6 guest IP, loadBalancerPort 23 and instancePort 25. The LB rule is configured on InternalLBVM2.

Architecture and design description

1) Enable Internal LB on VPC tier

Introduce new Network Provider - InternalLBVm. This provider supports only 1 service  - LB with capability schema=Internal.

In order to have Internal Load Balancing support on VPC tier, the tier has to be created from the network offering with Service=LB, Provider=InternalLBVm, LB capability schema=Internal

Java code changes
  • Introduce new Network Element - InternalLBVm. Make it extend LoadBalancingServiceProvider interface. We need a new network element because Internal LB Vm will have different number of nics from the regular CS system vm (Guest and Control only); and its lifecycle will be different as well. The Vm will be started not when network gets implemented, but when the new IP gets acquired from the Guest Network for the Load Balancer rule.
  • Introduce InternalLBNetworkApplianceManager - for managing Internal Load Balancer vms. 
  • Allow to use network offering having LB capability schema=Internal to be used only when create network inside VPC
Backend changes

TBD. We might need a separate template/set of scripts for this kind of vm, or we can re-use the existing VR template.

Web Services API

No changes to existing Apis

DB changes

No changes

2) Create Load Balancer Rule 

Java code changes
  • Add new manager - InternalLoadBalancerManagerImpl (name is TBD). This class will be responsible for managing Internal LB rules.
  • The LBRule can be created with or without specifying the IP address. In this case we acquire IP address from the Guest network and start new Internal LB vm for the IP address
  • A new InternalLBVM should be spanned as soon as the guest IP address is acquired by the LB rule. This code should be handled by InternalLBNetworkApplianceManager. The VM gets created with 2 interfaces: eth0 - linkLocal (private in VMWare case), eth1 - the IP address of the LB rule.
  • There is going to be 1 Internal LB vm spanned per guest IP address participating in the Internal Load Balancing.
Backend changes

TBD. Have to put HA proxy management/configuration details here

Web Services API

Changes to existing APIs

API name

Request parameters

Response parameters

Available to regular user

createLoadBalancingRule

1) New parameters:

  • schema (String enum, with External/Internal choices; optional; =External by default)
  • sourceIpAddress (String, optional, can be used only with networkId conjunction)  If networkId=(guestNetworkId of the network where internal LB is supported) is passed in w/o sourceIpAddress param,  
    the IP address from the guest network will get acquired on the fly and be assigned to the Load Balancing Rule.
    2) Changes to existing parameters: 
  • None | 1) New parameters:
  • schema
  • sourceIpAddress 2) Changes to existing parameters: 
  • None | yes |

    listLoadBalancingRules

    1) New parameters:

  • schema
  • sourceIpAddress2) Changes to existing parameters: 
  • None | 1) Each Load Balancer will have new parameters:
  • schema
  • sourceIpAddress
    2) Changes to existing parameters: 
  • None | yes |
    DB changes

Existing table load_balancing_rules will get a new field - "schema". It will have "External" value by default, and will accept enum values External/Internal.

3) Assign VMs to the Internal Load Balancer.

Existing set of APIs will be used for adding/deleting VMs to/from Internal LB

  • assignToLoadBalancerRule
  • deleteFromLoadBalancerRule

How to list Guest IP addresses allocated for LB purpose

At the moment, cloudStack doesn't expose any API for listing IP addresses from the guest network. Adding a new one to serve this purpose:

API Name

Request Parameters

Response Parameters

Available to regular user

listIpAddresses

  • ipAddress
  • networkId
  • purpose

list of ip Addresses, each IP object having parameter:

  • ipAddress
  • networkId
  • purpose (can have value "LB" at this point)
  • state (Free/Allocated)

true

In 4.2 this API will return only Allocated IP addresses.

Internal Load Balancing Vm life cycle

  • Create: InternalLBVM gets created when the first Load Balancing Rule is created for the IP address
  • Destroy: InternalLBVM gets destroyed when the last Load Balancer is removed for the IP address
  • Reboot: InternalLBVM can be rebooted as a regular system vm using RebootSystemVm API.
  • List: InternalLBVM can be listed with ListSystemVMs API

Limitations

  • Internal and Public Lb are mutually exclusive on a tier. If the tier has LB on the public side, then it can't have the Internal LB
  • Supported just on VPC networks

UI

TBD

  • No labels