Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • A new InternalLBVM should be spanned as soon as new source IP address is acquired by the LB rule. This code should be handled by InternalLoadBalancerVMManager. See more details on the VM in "InternalLBVM management and life cycle" section.
  • There is going to be 1 Internal LB vm spanned per guest IP address participating in the Internal Load Balancing. If more rules are added for the same IP, they will be managed on the same InternalLBVM.

If LB provider is Netscaler VPX:

  • TBDNetscaler VPX is not supported as Internal LB provider in this release. It will be supported only as a Public LB provider.
Backend changes

TBD. For InternalLBVM, have to put HA proxy management/configuration details here

Web Services API

Introduce new APIs

API Name

Request Parameters

Response parameters

Available to regular user

createLoadBalancer 

  • name (required, unique) - name of the LB
  • displayText (required) - display text of the LB
  • networkId (required) - the guest network id the Load Balancer belongs to. 
  • sourceIpAddressNetworkId (required) - 
  • sourceIpAddress (optional) - source IP address. Has to be specified with sourceIpNetworkId. If not specified, the IP address will be required from the network
  • scheme (required) - supported values Internal/Public
  • algorithm (required)
  • sourcePort (required)
  • instancePort (required)

LoadBalancer object:
* id

  • name
  • displayText
  • networkId
  • algorithm
  • sourceIpAddressNetworkId
  • sourceIpAddress
  • scheme (Public/Internal)
  • list of LoadBalancerRules objects
  • list of LoadBalancerInstance objects
    LoadBalancerRule object:
  • sourcePort
  • instancePort
    LoadBalancerInstance object:
  • instanceId
  • instanceName

yes

deleteLoadBalancer

  • id (required) - load balancer id
  • true/false

yes

listLoadBalancers

  • id
  • name
  • networkId
  • sourceIpAddressNetworkId
  • sourceIpAddress
  • scheme

list of LoadBalancer objects (see the structure in createLoadBalancer command description)

yes

DB changesTBD

  • Added new fields to load_balancing_rules table: source_ip_address, source_ip_address_network_id, scheme (accepts Internal and Public values)
  • DB upgrade: for all existing LB rules, fields source_ip_address and source_ip_address_network_id fields remain null. "scheme" should be updated with Public value

3) Attach VM to the Load Balancer

Existing API are going to be used to assign/remove vm to/from the load balancer

assignToLoadBalancerRule

assignToLoadBalancerRule

Internal Load Balancing rules management in Network

For Public LB rule, whenever a new LB rule is created, we re-send all the existing LB rules for the network, to the network elements. It would be a bit different when it comes to managing Internal LB rules.

  • When new Public LB rule is created, only Public LB rules for the network should be resend to the network elements. Internal Lb rules are managed separately.
  • During the network restart, we first resend all the Public LB rules, and then Internal
  • When internal Lb rule is created for IP1, we resend only all the rules for IP1 to the internal lb element. Internal LB rules for other IPs in the network, are not being re-send.

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. You see all the ip addresses allocated by the load balancers by executing the following command:

listLoadBalancers&scheme=Internal&networkId=<Id of the network the load balancer belongs to>

Internal Load Balancing Vm management and life cycle

...