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

Compare with Current View Page History

« Previous Version 2 Next »

This documents gives an overview to the design and functional implementation for Internal Load Balancing on VPC tiers.
Feature developer - Kishan Kavala

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. Load balancing on the APP tier will be covered by the Internal LB.
The flow - internal LB has to be created for the tier B. Access from tier A to tier B can be managed by Network ACLs.

The guest IP from tier B is implicitly acquired and new system vm - the vm type is Internal LB - is created with this IP address. 

API and orchestration level

New APIs:

  • createInternalLoadBalancerRule (has all parameters listed in our regular createLBRule api except for the publicIpId). NetworkId will be required.
  • deleteInternalLoadBalancerRule
  • listInternalLoadBalancerRules

create/list APIs should return IP that is acquired automatically as a part of LB creation.

Existing LB APIs should be supported to add user vms to the LB.

  •  assignToLBRule
  •  removeFromLBRuleAs we are going to support LB on the public side on the VPC with the VPC VR as a provider, so we need a separate service/provider to support internal LB on the VPC - InternalLb service and InternalLb provider. Have to define these providers in the VPC offering as well as on the Network offering.

DB

Upgrade: whether have to upgrade existing default VPC/Network offering with the new Service/Provider, or create a new default one having Internal LB service/provider in place.

Backend

1. Create Load Balancer rule. The system vm with the Internal LB type will start automatically. The vm will have guest IP acquired from the App tier.

2. Create LB rule in haproxy.cfg with acquired IP and selected Vms is tier B

3. Restart haproxy

UI

TBD

  • No labels