• Created by Unknown User (alena1108), last updated on Mar 18, 2013 4 minute read

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

Compare with Current View Page History

« Previous Version 14 Next »

Introduction

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

Feature developers:

  • APIs and Orchestration level - 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. Admin wants traffic coming from LB to App tier to be balanced as well. Load balancing on the APP tier will be covered by the Internal LB feature.

The general flow

  1. Create App tier using network offering with Service=Lb, Provider=InteralLBVm
  2. Acquire guest IP address - Ip1 - from the App tier.
  3. Create Internal Load Balancer LB1 for Ip1, public port 80, private port 80. The new internal LB VM starts up on App tier with the Ip1.
  4. Add vm1 to the LB1. The rule for Ip1/VM1/ports 80:80 is configured inside the HA proxy
  5. Add vm2 to the LB1. The rule for IP1/VM2/80:80 is configured inside the HA Proxy
  6. Create Internal Load Balancer LB2 for IP1, public port 81, private port 81. No need to start a new Internal LB vm as it's been already started for IP1.
  7. If you want to manage access from tier A to tier B, setup Network ACLs

Architecture and design description

1) Enable Internal LB on VPC tier

Introduce new Network Provider - InternalLBVm. This provider supports only 1 service  - LB

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. 

Java code changes
  • Introduce new Network Element - InternalLBVm. Make it extend LoadBalancingServiceProvider interface.
  • Introduce InternalLBNetworkApplianceManager
  • Allow to use network offering having LB/InternalLBVm to be used only when create network inside VPC
Backend changes

For the backend engineer to complete. We might need a separate template/set of scripts for this kind of vm, or we might use the existing VR template.

Web Services API

No changes to existing Apis

DB changes

Add one more default Network offering having LB Service with Internal LB provider. Insert this offering as a part of the upgrade as well.

2) Allocate IP address from the VPC Guest Network

Before creating the Internal Load Balancer, the Guest IP address has to be allocated from the App tier.

Java code changes
  • New code for allocating and managing IP addresses from the guest network to the account. Might need to create a new manager for that.
Backend changes

No backend changes are needed for this part

Web Services API

New set of APIs to allocate guest IP address to the account.

Api name

Request parameters

Response parameter

Available to regular user

allocateIpAddress

networkId (required, accepts only Id of VPC guest networks in 4.2)

  • id
  • ipAddress
  • networkId
  • account
  • domainId

yes

releaseIpAddress

id (required)

true/false

yes

listIpAddresses
  • id
  • ipAddress
  • networkId
  • account
  • domainId

List of Ip objects, each having:

  • id
  • ipAddress
  • networkId
  • account
  • domainId

yes

DB changes
TBD

3) Create Internal Load Balancer using the Guest IP address allocated on step #2

Java code changes
  • Add new manager - InternalLoadBalancerManagerImpl (name is TBD). This class will manage all the internal lb rules in the system.
  • 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 IP address / Public port combination.
  • There is going to be 1 Internal LB vm spanned per IP address participating in the Internal Load Balancing.
Backend changes

For the backend engineer to complete. Have to put HA proxy management/configuration details here

Web Services API

API name

Request parameters

Response parameters

Available to regular user

createInternalLoadBalancer

  • ipAddressId(required)
  • name (required)
  • description (required)
  • algorithm (required)
  • publicPort (required)
  • privatePort (required)
  • networkId (optional)
  • id
  • name
  • description
  • algorithm
  • publicPort
  • privatePort
  • networkId
  • ipAddress child object

yes

deleteInternalLoadBalancer

id(required)

true/false

yes

listInternalLoadBalancers

  • id
  • ipAddressId
  • name
  • description
  • algorithm
  • publicPort
  • privatePort
  • networkId

list of load balancers, each having parameters:

  • id
  • name
  • description
  • algorithm
  • publicPort
  • privatePort
  • networkId
  • ipAddress child object

yes

DB changes

TBD

4) Assign VMs to the Internal Load Balancer.

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

  • assignToLoadBalancerRule
  • deleteFromLoadBalancerRule
Web Services API

assignToLoadBalancerRule/deleteFromLoadBalancerRule will accept internal load balancer id when passed with id request parameter.

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

  • No labels