openstack load balancing use cases and requirements

LBaaS Use Cases and Requirements

What do you mean we have to make this work now?

OpenStack Design Summit – Fall 2012 – Tuesday October 16th [email protected]

mailto:[email protected]

Background and Thoughts

Please Read the Wiki: http://wiki.openstack.org/Quantum/LBaaS

Primer on Network Load Balancing: http://wiki.openstack.org/NetworkLoadBalancingIntegrationsWithQuantum

Decided to Standardize Two L3 Routed Use Cases for Now:

“Routed Mode”- LB device is the default L3 route path (maybe)

“One-Arm Mode”- LB device uses SNAT to force a L3 route path

http://wiki.openstack.org/Quantum/LBaaS

http://wiki.openstack.org/NetworkLoadBalancingIntegrationsWithQuantum

Quick Look At Routed Mode

VIP: 10.10.10.10

NLB: 20.20.20.1

Node: 20.20.20.10Gateway: 20.20.20.1

Node: 20.20.20.9Gateway: 20.20.20.1

Node: 20.20.20.8Gateway: 20.20.20.1

Ramifications: - L2 adjacency to 'Nodes' - L3 routing works to everything the 'Nodes' need to get to - No LB for the Local Segment

Quick Look At One-Arm ModeRamifications: - L3 client address abstracted to 'Nodes' - Additional L3 addressing for SNAT - 64k connections per IP - Defined as pools before deployed

VIP: 20.20.20.5Router: 20.20.20.1

Node: 20.20.20.10Gateway: 20.20.20.1

Node: 20.20.20.9Gateway: 20.20.20.1

Node: 20.20.20.8Gateway: 20.20.20.1

SNAT Pool20.20.20.50-52

LB Devices Should Be HA

MAC A

MAC B

MAC Masq C

Virtual IP bound to MAC C

Virtual IP

Virtual IP

routedomain

broadcastdomain

Dynamic MAC address generation

GARP or ICMPv6 for failover

1 IP per HA + 1 IP per device + 1 VIP

Dynamic MAC address generation

GARP or ICMPv6 for failover

1 IP per HA + 1 IP per device + 1 VIP

Dynamic routing protocol with forwarding on separate L3 network

Anycast or RHI Virtual IPs

1 IP per device + 1 VIP

Dynamic routing protocol with forwarding on separate L3 network

Anycast or RHI Virtual IPs

1 IP per device + 1 VIP

L2 HA

L3 HA

Use Case 1: Multi-Tenant Devices with Routed Shared Networks

One-Arm mode only – Edge LB Service

……….

OOB Management Port

Management Network

HA Virtual IP Network (Public)

HA Shared Network (Private)

1 IP Address per Device + 1 IP Address per HA Domain + 1 IP Address per Virtual Service ( n + d + v )1 IP Address per Device + 1 IP HA Cluster Management ( n + 1 )

1 IP Address per Device + 1 IP Address per HA Domain + 1 IP per 64k connections ( n + d + p )

n = number of LB devicesd = number of HA domainsp = number of concurrent SNAT addresses

OOB Typically is a physical interface

100% Routed L3 Topology for LB

All Virtual IPs are from shared network pools

There are no tenant specific networks at L2 or tenant provided L3 addressing

100% Routed L3 Topology for LB

All Virtual IPs are from shared network pools

There are no tenant specific networks at L2 or tenant provided L3 addressing

Use Case 1: Multi-Tenant Devices with Routed Shared Networks

One-Arm Mode Only

……….

OOB Management Port

Management Network


HA Shared Network (Private)

n = number of LB devicesd = number of HA domainsp = number of concurrent SNAT addresses


1 IP Address per Device + 1 IP HA Cluster Management ( n + 1 )

1 IP Address per Device + 1 IP Address per HA Domain + 1 IP per 64k connections ( n + d + p )1 IP Address per Device + 1 IP Address per HA Domain + 1 IP Address per Virtual Service ( n + d + v )

PROVIDER REQUIREMENTS

This looks like AtlasLB today

LB Device Management and HA networking

Predefined network poolsfor PUBLIC and PRIVATE routed networks

Predefined SNAT pool addresses

L3 filtering on PRIVATE virtual IPs allowing only tenant network addresses

to connect to the virtual service

Security groups must allow connectionsfrom SNAT pool addresses



LB Device Management and HA networking

Predefined network poolsfor PUBLIC and PRIVATE routed networks

Predefined SNAT pool addresses

L3 filtering on PRIVATE virtual IPs allowing only tenant network addresses

to connect to the virtual service

Security groups must allow connectionsfrom SNAT pool addresses

TENANT REQUIREMENTS


Defines MembersDefines LB Method

Defines Monitoring RequirementsDefines Persistence Requirements

Overload Virtual IPs with Different Ports

TENANT REQUIREMENTS





Use Case 2: Multi-Tenant Devices with Shared and Quantum Networks

……….

OOB Management Port

Management Network


HA Tenant Network

1 IP Address per Device + 1 IP HA Cluster Management ( n + 1 )



HA Tenant Network


Quantum IP Addresses

Dynamic MAC Addresses + Tenant Managed IP Addresses

Tenant Networks

Public HA Virtual IPs are from shared network pools

Tenant supplies network ids and required L3 addressing

Public HA Virtual IPs are from shared network pools

Tenant supplies network ids and required L3 addressing

1 IP Address per Device + 1 IP Address per HA Domain + 1 IP Address per Virtual Service ( n + d + v )

One-Arm mode only?

Use Case 2: Multi-Tenant Devices with Shared and Quantum Networks

One-Arm mode only?

……….

OOB Management Port

Management Network


HA Tenant Network


HA Tenant Network

Tenant Networks

1 IP Address per Device + 1 IP HA Cluster Management ( n + 1 )Quantum IP Addresses

Dynamic MAC Addresses + Tenant Managed IP Addresses

1 IP Address per Device + 1 IP Address per HA Domain + 1 IP Address per Virtual Service ( n + d + v )

1 IP Address per Device + 1 IP Address per HA Domain + 1 IP per 64k connections ( n + d + p )1 IP Address per Device + 1 IP Address per HA Domain + 1 IP per 64k connections ( n + d + p )


LB devices Management and sharednetwork HA requirements

Predefined network poolsfor shared network virtual IPs


LB devices Management and sharednetwork HA requirements


TENANT REQUIREMENTS

Tenant network id(s)

LB devices tenant network(s) HA requirements

IP for virtual IPs on tenant network(s)

Predefined network addressesfor SNAT pools on tenant network(s)




TENANT REQUIREMENTS

Tenant network id(s)







Use Case 3: Single-Tenant Load Balancing

One-Arm Mode Only

Public Network Address is not HA

Possibly HA Tenant Network

1 IP Address per Device


Tenant Networks


optionalLB device is 'owned' by a

single quantum tenant

LB device is not the onlyroute between tenant networks

Tenant controls LB HA devices

LB device is 'owned' by asingle quantum tenant

LB device is not the onlyroute between tenant networks

Tenant controls LB HA devices

Use Case 3: Single-Tenant Load Balancing

One-Arm Mode Only



1 IP Address per Device


Tenant Networks


optional


LB devices Management requirements





TENANT REQUIREMENTS

Tenant network id(s) (L2 on device)


LB device L3 filtering control






TENANT REQUIREMENTS









Use Case 4: Single-Tenant LB Devices as Gateway



1 IP per Device 1 IP per 64k connections



Tenant Networks


LB device is the onlyroute between tenant networks


LB device is the onlyroute between tenant networks

Do we even need this use case?

Use Case 4: Single-Tenant Devices as Gateway

Do we even need this use case?



1 IP per Device 1 IP per 64k connections



Tenant Networks







TENANT REQUIREMENTS




LB device route table control

LB device DHCP relay / service






TENANT REQUIREMENTS




LB device route table control

LB device DHCP relay / service






What Did We Miss?

openstack load balancing use cases and requirements

Documents