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 A and Application tier B. Traffic to Web tier is balanced on the VPC VR on the public side. User wants traffic coming from Web to App tier to be balanced as well. Load balancing on the APP tier will be covered by the Internal LB feature.

General flow

With InternalLBVM:

1. Create App tier using network offering with Service=LB, Provider=InteralLBVm, LB service capability schema=Internal.
2. Create LoadBalancingRule LBRule1 for Ip1, loadBalancerPort 80, instancePort 80, schema=Internal. The new internal LB VM starts up on App tier with the 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 LBRule2 for IP1, loadBalancerPort port 81, instancePort 81, schema=Internal. No need to start a new Internal LB vm as it's been already started for IP1 on step 2)
6. If you want to manage access from tier A to tier B, setup Network ACLs on the VPC VRWith Netscaler VPX:

1. Create App tier using network offering with Service=LB, Provider=Netscaler, LB service capability schema=Internal.
2. Create LoadBalancingRule LBRule1 for Ip1, loadBalancerPort 80, instancePort 80, schema=Internal. Nothing gets configured on the Netscaler.
3. Add vm1 to the LB1. The rule for Ip1/VM1/ports 80:80 gets configured on the Netscaler.
4. Add vm2 to the LB1. The rule for IP1/VM2/80:80 gets configured on the Netscaler.
5. Create Internal Load Balancer LBRule2 for IP1, loadBalancerPort port 81, instancePort 81, schema=Internal. Nothing gets configured on the Netscaler.
6. If you want to manage access from tier A to tier B, setup Network ACLs on the VPC VR.

The pic below is for the case when InternalLBVm is used as a provider:

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.
2. Internal LB rule #1 for 10.10.10.4 guest IP, loadBalancerPort 23 and instancePort 25. 
3. Internal LB rule #2 for 10.10.10.4 guest IP, loadBalancerPort 45 and instancePort 46.
4. Internal LB rule #3 for 10.10.10.6 guest IP, loadBalancerPort 23 and instancePort 25.Public LB rule gets configured on the VPC VRInternalLB rules #1 and #2 get configured on Internal LB VM1Internal LB rule #3 gets configured on Internal LB VM2.

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.
• A new InternalLBVM should be spanned when the first LB rule for the IP address gets created. This code should be handled by InternalLBNetworkApplianceManager. The VM gets created with 1 interface having IP address of the Load Balancer assigned to it.
• You can create as many Internal Load Balancers for the IP address as  you want. The Internal Load Balancer is uniquely identified by the IpAddress / LbPort combination.
• There is going to be 1 Internal LB vm spanned per 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

DB changes

TBD

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

Internal Load Balancing Vm life cycle

• Create: InternalLBVM gets created when the first Load Balancer 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

Question: should we allow destroying the vm with DestroySystemVM command?

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