A Novel Use of Openflow and Its Applications in Connecting Docker and Dummifying Cloud (Build, Ship,...

A Novel Use of Openflow

and Its Applications in

Connecting Docker and Dummifying Cloud

Build, Ship, Run any Cloud, any Scale

DaoliCloud Company

April, 2015

Sign-up a free trial account now at

www.daolicloud.com

2

Lift going up: Deployment, operation maintenance and scale-

out enlargement of cloud IaaS pool, e.g., Openstack, from now

on become plug-n-play easy for “dummies”

Lift going down: What? Docker is not connected? Don’t you

know Docker is for the cloud? Don’t you know cloud needs a

controller? No? You’re finished! Yes? Read on!

Lift Version of this Presentation

© DaoliCloud Company, all rights reserved, 2011—2015

Zero Configuration Plug-n-Play Cloud for Dummies, Wrapped in Docker Image

begin

image image

© DaoliCloud Company, all rights reserved, 2011—2015 3

• Executive Summary

• Cloud Networking Requirements and Current Practices

• A Novel Use of Openflow

• Application: Zero-Configuration Plug-n-Play Cloud

• RAIC：Redundant Array of Inexpensive Cloud

• Plug-n-Play RAIC Properties

• Long Term Value

• Conclusion

• Technical Backup Material

Content

4

Innovation in SDN

To divide (differentiation) cloud into small parts so that cloud deployment,

operation maintenance, and scale-out enlargement jobs are dummified into

plug-n-play simplicity; and then using SDN technique to reassemble

(integration) small parts back to cloud of unbound scalability

Applications

Near term: Zero-Configuration Plug-n-Play Cloud for Dummies, to reduce

cost for cloud deployment and operation-maintenance; to expedite cloud

maturity and time to market; Long term: Inter-Cloud

Executive Summary

Minimized

dummified

plug-n-play

cloud 1

SDN Controller to

reassemble cloud

into unbound scale© DaoliCloud Company, all rights reserved, 2011—2015

Minimized

dummified

plug-n-play

cloud N

5

Cloud Networking Requirements:

1. Number of overlay entities (VMs, Docker containers) > > capacity

of underlay IP resource

2. Network isolation for multi-tenancy

Current Practices:

Encapsulation: MAC in UDP (e.g., VXLAN) or IP in IP (e.g., GRE)

• Req 1 met: Each encapsulation makes a tunnel to reuse underlay

resource

• Req 2 met: Each tunnel forms an independent VPN to isolate

overlay network

Cloud Networking Requirements and

Current Practices

Payload encapsulation nullified overlay network

functions (overlay headers become payload data)Encapsulation

header label

= control plane

info placed in

forward plane

Underlay

packet

headers

L4/L3/L2


6

Encapsulation establishes software connection among cloud

servers in a cloud OS, e.g., Openstack, to scale UP cloud OS

• When a cloud OS is scaled UP, its deployment and operation-

maintenance jobs become very complex, only few “clever”

people can do the job, which efficiently shrink cloud market,

and prolong time to market

• A scaled-UP cloud, if too big, is unstable in operation; cloud

scale-UP has a humble size limit

• Encapsulation builds a physical large L2 network to include a

large number of irrelevant entities into a communications

group while in most cases communications take place only

between two entities; large L2 wastes resource + increases

complexity

Problem Analysis: Current Cloud Networking


“1 Cloud 2 Openstack” = scale OUT

Cloud Scalability: Scale UP or OUT?

“1 Cloud 1 Openstack” = scale UP

To orchestrate thousands of servers?

To build a Tower of Babel?

Mission impossible

Difficult to deployment

and operation maintenance

Connecting thousands of servers

= very low system stability

E.g., message queue gets too big

User space connected Openstack:

Each independent Openstack has a

small scale, very easy to deploy and

operate maintain, however, cloud user

still sees a cloud of unbound scale

…Openstack

or Docker

………

OpenStack

or Docker

Openstack

or Docker

OpenStack

or Docker

Independent Cloud

7

Independent Cloud

Independent Cloud

Let connection take place

upon user communications


8

Role of L4-port includes to let communications initiator recognize

dialog contexts “invented here”

Upon starting an overlay dialog, the underlay host has the dialog

initiator’s id, can OF packetin (id, L4-ports) to the OF controller

L4-ports has sufficient entropy to 1-1 code flow for underlay hosts

to unicast route & resume overlay packets

Encapsulation is not needed, so that cloud hosts needn’t know one

another in time of cloud OS deployment and service operation

A Novel Use of Openflow (more detailed know-how

in technical backup material)

Overlay/underlay

packets headers

L2/L3/L4 mapping

coding & replacing


Application: Cloud OS Horizontally Decoupled

9

Controller 1 Controller 2 Controller N…

Distributed SDN Controller Cluster, can be distributed in CDNs

Plug-n-Play Openstack/Docker Servers

…

…

…

Plug-n-Play

OpenStack

or Docker

SDN Control Plane:

Openflow Packetin

L4-ports coded flow

SDN Data Plane:

Overlay L4-port coded flow

on-the-fly connects overlay

nodes via underlay servers,

making cloud unbound for

users yet tiny for underlay

OpenStack

or Docker

OpenStack

or Docker

OpenStack

or Docker

Web (SSL)

connection

On-the-fly

data-plane

connection

Plug-n-Play

Plug-n-Play


10

Smallness in IaaS realization is desirable

Small scale of physical

implementation for IaaS

resource management

is like differentiation in math

to enable smooth integration

Invisible network patching boundary for small clouds are very useful:

• Only so can cloud have truly unbound scalability and elasticity

• Cloud OS becomes easy to deploy, stable to operate and maintain

• Arbitrary network topologies, widely distributed, inter-cloud

• Each server is an SDN router (distributed Neutron), no chokepoint

Provided network

patching boundary is

invisible by tenants;

Integration is beautiful

thanks to fine differentiation


11

RAIC：Redundant Array of Inexpensive Cloud

Plug-n-Play IaaS Pool

Scale OUT

• Adding SDN controllers

just like adding new

base stations

• Adding cloud resource

just like new mobile

phones entering market

Overlay nodes in arbitrary

network topology and

geological distribution

Straightforward inter-cloud


12

Plug-n-Play RAIC Properties

• Completely automatic “Zero-Configuration Plug-n-Play

Cloud for Dummies”, cloud wrapped in Docker image

• High availability, inter-datacenter distribution and arbitrary

network topology, every server is an Openflow controlled

router, no chokepoint

• Arbitrary elastic scalability

• User mode patch clouds to pool CPUs, disks & routers

• Hybrid Cloud

• Heterogeneous connecting VMs + Docker containers

• No special requirement on switches and networking boxes


begin

image image

13

Long Term Value for Inter-Cloud

Cloud is unbound large, meaning its service logic scalability

However the physical implementation of the cloud should follow

distributed computing principle, and open standards for

interoperability

Without packet encapsulation, inter-cloud connectivity and

interoperability become straightforward

DaoliCloud wishes to collaborate widely with the industry and

academia to make cloud computing really big, stable and quality

services


14

Conclusion

DaoliCloud’s SDN Cloud Networking Virtualization Technologies:

• Contribute to Openflow with a useful innovation

• Application: Zero-Configuration Plug-n-Play Cloud for Dummies

• Greatly eased cloud OS (e.g., Openstack) deployment, operation

and maintenance, these translate to speed-up cloud maturity

• Inter-cloud

Sign-up a free trial account NOW at

www.daolicloud.com

Download your own copy of “Plug-n-Play Cloud for Dummies”, plug-

n-play now!

Technical whitepapers and Product Introduction are available at:

www.daolicloud.com

Also available at:

www.slideshare.net/WenboMao


16

Technical backup material

Inherent problems for cloud networking

MAC address explosion One rack of servers in current CPU

condensity can host 10s of thousands containers. In conventional

flood-&-learn MAC populating, a ToR switch must hold multiple

such numbers of MACs since a cloud should be larger than one

rack. Moreover, can so MAC populated ToR work efficiently, and in

an affordable cost?

L2 broadcast control ARP broadcast is the only practical way to

plug-&-play construct a physical L2. However broadcast has

prohibitively high cost; to build a very large physical L2 is certainly

to look for trouble. In the next slide we shall discuss how current

technologies for L2 broadcast control, and their irrelevance to large

scale cloud networking.

The following cloud networking problems are already bad enough

for the scale of hypervisor-based CPU virtualization; the explosive

scale of container-based CPUs will only worsen the matter


17

Technical backup material

Cloud networking current technologies analysis

Problem with VPN, GRE, NVO3, VXLAN, NVGRE, STT, LISP, MPLS,

etc. encapsulation protocols:

Key issue They connect cloud OS hosts in scale UP manner: that’s why

they’re aka “large L2” protocols. Enlarging L2 hopelessly kills scalability

for cloud services. Also killed enroute is cloud service interoperability.

Technical assessment

1. To avoid MAC explosion and control L2 broadcast, encap for

servers/hosts; to isolate tenants, encap for each tenant; to patch cloud

for truly large scalability, encap further for IDCs; in general, to connect n

instances, O(n^2) encapsulations are needed.

2. IP connectivity is carefully architected to be connectionless flows so

that forward plane only conducts per flow checking for routing, this very

important architecting is nullified by encap into per packet checking

labelling (yellow header in Slide 5), that’s why encap is inefficient.

3. Encap enlarges packet over MTU (Maximum Transmission Unit), and

hence fragmentation/reassemble, additional cost.


Solution know-how: Virtual Ethernet Bridge (VEB)

distributed at vNICs is SDN programmable

Any entity worldwide is mapped to a

“Physically Associated Address” (PAA)

e.g., PAA = (MACs, IPs, ContextTag)

L4 ports: Very good usage for ContextTag

Forward plane:

Unicast cable for entities

in distributed clouds

Control plane of a tenant

a, b: plug

a, c: unplug

b, c: plug

a, b: plug

a, c: unplug

b, c: plug

Important property of PAA:

Worldwide Unique

L4 Ports can code sufficient

entropy for PAA uniqueness

Overlay network of arbitrary topology on distributed VEB no longer need encapsulation

A unicast cable plugging entities x and y = (PAA_x, PAA_y), in which:

L2 MAC addresses link x, y to their respective default gateways

L3 IP addresses = underlay IP addresses of the respective default gateways

L4 Ports numbers encode unique mappings between overlay entities and PAAs

18

VEB VEB

SDN

Controller


A Novel Use of Openflow and Its Applications in Connecting Docker and Dummifying Cloud (Build, Ship,...

Internet

Transcript of A Novel Use of Openflow and Its Applications in Connecting Docker and Dummifying Cloud (Build, Ship,...