1. So#ware
Defined
Networking
in
Apache
CloudStack
Chiradeep
Vi:al
CloudStack
Commi:er
@chiradeep
Feb
27
2013
2. Agenda
• IntroducEon
to
CloudStack
and
IAAS
• What
is
SDN
• Why
SDN
and
IAAS?
• CloudStack’s
Network
Model
• Extensible
Networking
in
CloudStack
• SDN
integraEons
in
CloudStack
• CloudStack’s
naEve
SDN
approach
• Future
3. Apache
CloudStack
• History!
• Incubating in the Apache
Software Foundation since
April 2012!
• Open Source since May
Build your cloud the way 2010!
the world’s most successful
clouds are built! • In production since 2009!
• Tons of deployments,
including large-scale
commercial ones!
4. How
did
Amazon
build
its
cloud?
Amazon eCommerce Platform
AWS API (EC2, S3, …)
Amazon Orchestration Software
Open Source Xen Hypervisor
Commodity Commodity
Networking
Servers Storage
5. How
can
YOU
build
a
cloud?
Amazon eCommerce Platform
Optional Portal
AWS API (EC2, S3, …)
CloudStack or AWS API
CloudStack Orchestration Software
Amazon Orchestration Software
Hypervisor (Xen/KVM/VMW/)
Open Source Xen Hypervisor
Networking Servers Storage
6. SDN
DefiniEon
• SeparaEon
of
Control
Plane
from
the
hardware
performing
the
forwarding
funcEon
• Control
plane
is
logically
centralized
7. SDN
Advantages
• Centralized control makes it easier to
configure, troubleshoot and maintain
• Eliminates ‘box’ mode of configuration
• Enables control at a high level
8. Related
to
SDN
•
API
layer
over
a
collecEon
of
‘boxes’
– API layer communicates with boxes using box-level
APIs / ssh / telnet
• OpenFlow
– Standard protocol for the centralized control plane to
talk to the forwarding elements.
• Tunnels
/
overlays
– SDN is valuable for virtual topologies
– Initial target of SDN implementation
14. Defining
Cloud
CompuEng
(IAAS)
• Agility
– Re-provision complex infrastructure topologies in
minutes, not days
• API
– Automate complex infrastructure tasks
• VirtualizaEon
– Enables workload mobility and load sharing
• MulE-‐tenancy
– Share resources and costs
15. Defining
Cloud
CompuEng
(IAAS)
• Scalability
– Ability to consume resources limited by budget, not
by infrastructure
• ElasEcity
– Scale up and down on demand
– Reduce need to engineer for peak load
• Self-‐service
– No IT assistance
16. Cloud
Networking
Requirements
• Agile
– Complex networking topologies created by non-
network engineers
• API
– Language to talk with the network infrastructure
layer (not CLI)
• VirtualizaEon
– Hypervisor-level switches work together with physical
infrastructure
17. Cloud
Networking
Requirements
• Scalability
– Usually means L3 in the physical infrastructure
• ElasEcity
– Release resources when not in use
– Introduce new resources on demand
• Self-‐service
– Novices deploying, maintaining, troubleshooting
virtual networks
18. IAAS
+
SDN
–
made
for
each
other
• SDN
enables
agility
– API
to
controller
enables
easy
changes
to
networks
• SDN
works
with
virtualizaEon
/
vSwitches
– Typical
of
most
SDN
controllers
• SDN
controllers
are
designed
for
large
scale
• SDN
enables
virtual
networking
– The
illusion
of
isolated
networks
on
top
of
shared
physical
infrastructure
19. SDN
issues
• Discovery
of
virtual
address
-‐>
physical
address
mapping
– VxLAN = multicast
– GRE = programmed by control plane
– L3 isolation = no mapping, no discovery
20. SDN
issues
• State
maintenance
– Large number of endpoints + flows
– High arrival rate of new flows
– Needs fast and scalable storage and
processing
– Differentiator between vendors
21. SDN
issues
• L4-‐L7
– Service insertion and orchestration
– How do endpoints get services such as
• Firewall
• Load balancers
• IDS/IPS
– Service levels and performance
– Service Chaining
22. Network
VirtualizaEon
in
IAAS
Tenant 1 Virtual Network 10.1.1.0/24
!
Tenant 10.1.1.2
Gateway 1 VM 1
address 10.1.1.1
!
Tenant 10.1.1.3
1 VM 2
Internet!
!
Tenant 10.1.1.4
1 VM 3
!
Tenant 10.1.1.5
1 VM 4
23. Network
VirtualizaEon
in
IAAS
Tenant 1 Virtual Network 10.1.1.0/24
Public Public IP
!
Tenant 10.1.1.2
Network address Gateway 1 VM 1
65.37.141.11! address 10.1.1.1
65.37.141.36
!
Tenant 1 ! Tenant 10.1.1.3
Edge 1 VM 2
Services
Internet! !
Appliance(s)
NAT!
!
Tenant 10.1.1.4
DHCP!
1 VM 3
FW
!
Tenant 10.1.1.5
1 VM 4
24. Network
VirtualizaEon
in
IAAS
Tenant 1 Virtual Network 10.1.1.0/24
Public Public IP
!
Tenant 10.1.1.2
Network address Gateway 1 VM 1
65.37.141.11! address 10.1.1.1
65.37.141.36
!
Tenant 1 ! Tenant 10.1.1.3
Edge 1 !
Tenant 1 VM 2
Edge
Services
Services
Appliance(s)
NAT!
! !
Appliance(s)
Internet!
!
Tenant 10.1.1.4
DHCP!
1 VM 3
FW
Load
Balancing!
!
VPN Tenant 10.1.1.5
1 VM 4
25. Network
VirtualizaEon
in
IAAS
Tenant 1 Virtual Network 10.1.1.0/24
Public Public IP
!
Tenant 10.1.1.2
Network address Gateway 1 VM 1
65.37.141.11! address 10.1.1.1
65.37.141.36
!
Tenant 1 ! Tenant 10.1.1.3
Edge 1 !
Tenant 1 VM 2
Edge
Services
Services
Appliance(s)
NAT!
! !
Internet! Appliance(s)
!
Tenant 10.1.1.4
DHCP!
1 VM 3
FW
Load
Balancing!
!
Tenant 10.1.1.5
1 VM 4
Tenant 2 Virtual Network 10.1.1.0/24
Public IP
address
65.37.141.24!
Gateway
address
Tenant
2 VM 1 ! 10.1.1.2
65.37.141.80 10.1.1.1
!
Tenant 2 ! Tenant 10.1.1.3
Edge 2 VM 2
!
Services
Appliance
VPN!
NAT!
DHCP
Tenant
2 VM 3 ! 10.1.1.4
26. CloudStack
Network
Model
Tenant 1 Virtual Network
10.1.1.0/24
Public Public IP Tenant
Network address 10.1.1.2
!
Gateway 1 VM
65.37.141.11! address 1
65.37.141.36 10.1.1.1
Tenant 1 ! Tenant 10.1.1.3
Edge 1 !
Tenant
!
1 VM
Edge
Services
Services
Appliance(s)
NAT! Appliance(s)
! ! 2
Tenant 10.1.1.4
DHCP!
!
1 VM
FW
Load 3
Balancing!
Tenant 10.1.1.5
!
1 VM
4
Tenant 2 Virtual Network
Public IP 10.1.1.0/24
address Gateway Tenant 10.1.1.2
• Map
virtual
networks
2 o
physical
t VM
65.37.141.24!
65.37.141.80
address
infrastructure
10.1.1.1 1 !
• Edge 2 ! and
provision
network
services
in
Tenant
Define
Tenant 10.1.1.3
!
2 VM
virtual
networks
!
Services 2
Appliance
VPN!
• Manage
elasEcity
and
scale
o10.1.1.4
NAT!
Tenant f
network
DHCservices
P
2 VM
3 !
30. Service
Catalog
• Cloud
users
are
not
exposed
to
the
nature
of
the
service
provider
• Cloud
operator
designs
a
service
catalog
and
offers
them
to
end
users.
– Gold = {LB + FW, using virtual appliances}
– Platinum = {LB + FW + VPN, using hardware
appliances}
– Silver = {FW using virtual appliances, 10Mbps}
31. Service
Catalog
examples
L2 network with software appliances!
10.1.1.0/24!
VLAN 100
VM 1!
10.1.1.
2
65.37.141.1 10.1.1.1
11! CS!
65.37.141.1 Virtual VM 2!
12 Router! 10.1.1.
3
DHCP, DNS!
NAT!
Load 10.1.1.4 VM 3!
Balancing!
VPN
VM 4!
10.1.1.5
32. Service
Catalog
examples
L2 network with software appliances! L2 network with hardware appliances!
10.1.1.0/24! 10.1.1.0/24!
VLAN 100 VLAN 100
VM 1! 65.37.141.11 10.1.1.1 10.1.1.2 VM 1!
10.1.1.
1 Juniper
2 SRX!
65.37.141.1 10.1.1.1
11! CS! Firewall! NAT,
65.37.141.1 Virtual VM 2! VPN! VM 2!
10.1.1. 10.1.1.3
12 Router!
3 65.37.141.11 10.1.1.112
DHCP, DNS! 2 Netscaler!
NAT! Load
Load 10.1.1.4 VM 3! VM 3!
Balancer! 10.1.1.4
Balancing!
VPN
VM 4! VM 4!
10.1.1.5 10.1.1.
5
CS!
DHCP, Virtual
Router!
DNS!
Upgrade
33. MulE-‐Eer
virtual
networking
Internet!
IPSec or SSL site-to-site VPN!
! Custome
Loadbalancer Virtual appliance/!
r!
Hardware Devices!
(virtual or HW)! Premises!
MPLS VLAN!
Network Services!
App VM
• IPAM!
1!
• DNS! Web VM
1!
• LB [intra]!
• S-2-S VPN! App VM
• Static Routes! Web VM 2! VLAN 2724
• ACLs! 2!
• NAT, PF!
• FW [ingress & egress]! VLAN 353
Web VM DB VM
3! 1!
Web VM
4!
Web subnet ! App subnet DB Subnet!
10.1.1.0/24! VLAN 101
10.1.2.0/24! 10.1.3.0/24!
34. OrchestraEon
• Orchestra)on
describes the automated
arrangement, coordination, and management of
complex computer systems, middleware and
services
– Wikipedia
37. CloudStack
OrchestraEon
Hypervisor
Hypervisor
Resource
5
4
Resource
Hyperviso
Hyperviso
r
Plugins
r
Plugins
Plugin
Framew 6
ork
Network
API
7
Network
Resource
Network
API
Network
Resource
OrchestraEon
Core
Plugins
1
API
Plugins
2
8
Allocator
9
3
Storage
Plugins
Plugins
Storage
Storage
Resource
Resource
Allocator
Allocator
Plugins
Plugins
Physical Resources !
Orchestration steps can be executed in parallel or in sequence!
38. CloudStack
and
SDN
Hypervisor
Hypervisor
Resource
5
4
Resource
Hyperviso
Hyperviso
r
Plugins
r
Plugins
Plugin
Framew 6
ork
Network
API
7
SDN
Resource
Network
API
Network
controller
OrchestraEon
core
Plugins
1
API
Plugins
2
8
Allocator
9
3
Storage
Plugins
Plugins
Storage
Storage
Resource
Resource
Allocator
Allocator
Plugins
Plugins
Physical Resources !
Network plugin is the glue that understands the SDN controller’s API!
39. CloudStack
SDN
IntegraEon
• Nicira
NVP
– L2
(STT)
isolaEon
in
4.0
– Source
NAT
/
Logical
Router
in
4.2
• BigSwitch
– VLAN
isolaEon
in
4.1
– VNS
in
4.2
• Midokura
– L2-‐L4
network
virtualizaEon
– Coming
in
4.2
• CloudStack
NaEve
– Tech
preview
(since
4.0)
– Requires
XenServer
40. VM
OrchestraEon
Example
Hypervisor
Hypervisor
Resource
Resource
Call
Hypervisor
APIs
Hypervisor
Hypervisor
Plugins
Plugins
Plugin
Framew
ork
Network
AP
I
AP Resource
Network
SDN
controller
I
OrchestraEon
Network
Plugins
API
Plugins
core
Allocator
Storage
Plugins
Plugins
Storage
Storage
Resource
Resource
Start
3
VMs
Allocator
Allocator
Plugins
Plugins
Allocate
hypervisors
VM
1
Host
1
Host
3
VM
VM
2
3
VR
Host
2
Host
4
41. Built-‐in
(naEve)
controller
Create
Full
Mesh
of
GRE
CloudStack
SDN
tunnels
(if
they
don't
Controller
already
exist)
between
hosts
on
which
VMs
are
deployed
Host
1
(Pod
2)
Host
3
(Pod
3)
OVS
VM
CloudStack
SDN
1
controller
programs
the
Open
vSwitch
(OVS)
on
XenServer
to
configure
GRE
Tunnel
GRE
tunnels
Host
2
(Pod
4)
Host
4
(Pod
2)
OVS
OVS
VM
VM
2
3
VR
GRE
Tunnel
GRE
Tunnel
42. Built-‐in
controller
Assign
'Tenant'
key
for
isolaEon
Tenant1
Tenant2
New
tenants
can
share
the
Host
1
Host
3
established
VM
VM
VM
GRE
tunnels
VR
1
1
3
with
separate
tenant
keys
GRE
Tunnel
Host
2
Host
4
VM
VM
VM
2
2
3
VR
GRE
Tunnel
GRE
Tunnel
43. What
makes
it
different
• Purpose
built
for
IAAS
– Not
general
purpose
SDN
soluEon
• ProacEve
model
– Deny
all
flows
except
the
ones
programmed
by
the
end-‐user
API
– Scaling
problem
is
manageable
• Part
of
CloudStack
– ASF
project
• Uses
Virtual
Router
to
provide
L3-‐L7
network
services
– Could
change
