The document provides an overview of Apache CloudStack, an open-source cloud orchestration platform that supports infrastructure-as-a-service (IaaS) and integrates network function virtualization (NFV). It discusses the features and capabilities of CloudStack, including network flexibility, scalability, and automation, as well as the advantages and challenges of implementing NFV within the platform. The content emphasizes the importance of open-source collaboration for innovation and scalability while outlining the potential cost reductions and automation benefits in network management.

1. Network
Func-on
Virtualiza-on
in
IAAS
Clouds
Chiradeep
Vi;al
@chiradeep
Commi;er,
Apache
CloudStack
Project

2. Agenda
• Overview of Apache CloudStack
• How and Why of NFV in CloudStack
• Does NFV deliver on its promise?

3. Apache CloudStack is a
• scalable,
• multi-tenant,
• open source,
• purpose-built,
• cloud orchestration platform for
• delivering turnkey Infrastructure-as-a-
Service clouds
Apache CloudStack

4. • Several
hundred
produc-on
clouds
• Largest
clouds
in
10’s
of
thousands
of
hypervisors
• Sectors:
• Hos-ng
• Enterprise
&
Educa-on
• Service
Providers
• Web
2.0
Commercial
and
Open
Source
Success

5. Most
Ac-vely
Developed
Apache
Project
Source:
h;p://www.ohloh.net/orgs/apache
retrieved
3/11/2014

6. Apache
CloudStack
State
Of
Union
–
March
2014
• Apache
Commi;ers
–
74
• Total
Apache
Contributors
All-­‐
Time
-­‐
799
• Individual
Companies
involved
in
ACS
-­‐
~284
(by
unique
domain
much
lower
than
actual
based
on
Gmail
and
other
non-­‐
company
addresses)
• Average
Monthly
contributors
>150
• Lines
of
Code
-­‐
1,521,161
• Total
commits
–
22,169
• Years
of
Effort
(
COCOMO
Model)
–
434
years
Stats
through
2/1/2014
Companies

7. How can you build your cloud?
Servers
Open Source Xen Hypervisor
Amazon Orchestration Software
AWS API (EC2, S3, …)
Amazon eCommerce Platform
Hypervisor
CloudStack Orchestration Software
Optional Portal
CloudStack or AWS API
StorageNetwork

8. Networking
Principles
in
Apache
CloudStack
• Flexibility
– Allow
various
combina-ons
of
technology
for
L2-­‐L7
network
services
– Allow
different
providers
(vendors)
for
the
same
network
service
in
a
Cloud
POP
• Pluggability
– Plugins
allow
vendors
to
drop
in
vendor-­‐specific
configura-on
and
lifecycle
management
code
• Service
scalability
– Scale
out
using
virtual
appliances
when
possible
– Scale
up
using
hardware
appliances
if
needed

9. Network Flexibility
Network
Services
• L2
connectivity
• IPAM
• DNS
• Routing
• ACL
• Firewall
• NAT
• VPN
• LB
• IDS
• IPS

10. Network Flexibility
Network
Services
• L2
connectivity
• IPAM
• DNS
• Routing
• ACL
• Firewall
• NAT
• VPN
• LB
• IDS
• IPS
Service
Providers
ü Virtual
appliances
ü Hardware
firewalls
ü LB
appliances
ü SDN
controllers
ü IDS /IPS
appliances
ü VRF
ü Hypervisor

11. Network Flexibility
Network
Services
• L2
connectivity
• IPAM
• DNS
• Routing
• ACL
• Firewall
• NAT
• VPN
• LB
• IDS
• IPS
Network
Isolation
• No
isolation
• VLAN
isolation
• Overlays
• L3
isolation
Service
Providers
ü Virtual
appliances
ü Hardware
firewalls
ü LB
appliances
ü SDN
controllers
ü IDS /IPS
appliances
ü VRF
ü Hypervisor

12. NFV in Apache CloudStack
• Built-in VNFs for IAAS network services
– Out of the box experience – no additional installation
– Lifecycle managed by CloudStack
– Debian 7.0 hardened appliance
• Vendor VNFs also supported
– Pooled model, no explicit instantiation
– License and initial configuration resist automation
– Citrix Netscaler ADC , Cisco ASA1000v firewall, Cisco
Nexus 1000v
• Software defined networking
– Built-in GRE/VxLAN controller
– Plugins for NSX, Contrail, OpenDaylight, etc

13. Computing
Hardware
Storage
Hardware
Network
Hardware
Hardware resources
Virtualisation Layer
Virtualised
Infrastructure
Manager(s)
VNF
Manager(s)
VNF 2
OrchestratorOSS/BSS
NFVI
VNF 3VNF 1
Execution reference points Main NFV reference pointsOther reference points
Virtual
Computing
Virtual
Storage
Virtual
Network
NFV Management and
Orchestration
EMS 2 EMS 3EMS 1
Service, VNF and Infrastructure
Description
Or-Vi
Or-Vnfm
Vi-Vnfm
Os-Ma
Se-Ma
Ve-Vnfm
Nf-Vi
Vn-Nf
Vl-Ha
ETSI
NFV
Func-onal
Blocks

14. Computing
Hardware
Storage
Hardware
Network
Hardware
Hardware resources
Virtualisation Layer
Virtualised
Infrastructure
Manager(s)
VNF
Manager(s)
VNF 2
OrchestratorOSS/BSS
NFVI
VNF 3VNF 1
Execution reference points Main NFV reference pointsOther reference points
Virtual
Computing
Virtual
Storage
Virtual
Network
NFV Management and
Orchestration
EMS 2 EMS 3EMS 1
Service, VNF and Infrastructure
Description
Or-Vi
Or-Vnfm
Vi-Vnfm
Os-Ma
Se-Ma
Ve-Vnfm
Nf-Vi
Vn-Nf
Vl-Ha
CloudStack
NFV
func-ons

15. NFV
func-ons
in
CloudStack
• Similar
to
ETSI,
but
not
iden-cal
– VirtualNetworkApplianceManager
=
VNF
Manager
– NetworkServiceManager
=
NFV
Orchestrator
– VirtualRouter
=
VNF
• Purpose-­‐built
for
IAAS
today
– Can
be
generalized
– Need
external
APIs
(currently
internal)

16. Example:
VNF
Lifecycle
Management
GREKey2724
DB
VM 1!
Web
VM 1!
Web
VM 3!
Web
VM 2!
GREKey1001
App
VM 1!
App
VM 2!
GREKey398
!
Virtual Router!
Internet!
Customer!
Premises!
IPSec VPN!
Private Gateway!Loadbalancer
(HW
or
Virtual)
Network Services!
• IPAM!
• DNS!
• LB [intra]!
• S-2-S VPN!
• Static Routes!
• ACLs!
• NAT, PF!
• FW [ingress & egress]!
LB VM !
Automated
Lifecycle:
Instan-a-on,
HA,
scaling
upgrade,
decommission

17. Example:
VNF
Lifecycle
Management
• IAAS
API
calls
result
in
VNF
instan-a-on
and
destruc-on
– Create
a
subnet
with
NAT,
firewall
and
LB
service
• Results
in
instan-a-on
of
virtual
router
VM
and
LB
VM
– Remove
LB
service
• Results
in
LB
VM
gemng
garbage
collected
– Destroy
subnet
• Results
in
virtual
router
gemng
destroyed
/
garbage
collected

18. Example:
Network
Service
onboarding

19. The
NFV
Promise
• Scalability
• Large-­‐scale
network
automa-on
• Cost
reduc-on
• Rate
of
innova-on
• Disaster
recovery

20. Scaling
with
CloudStack
NFV
• Scale
out
models
– Flexible
mapping
of
VNF
instances
to
unit
of
scaling
• Per
N
tenant,
per
N
network,
per
service
instance,
per
N
applica-on,
per
POP
• Scaling
model
can
be
tuned
on
the
fly
– Instan-ate
on
demand,
or
pool-­‐based
– VNFs
are
stateless
and
disposable
• Scale
up
model
– Configurable
memory,
CPU,
network
and
storage
capacity
for
a
VNF.

21. Scaling:
Caveat
• Effec-ve
scaling
requires
appropriate
network
topology
– Designed
for
predominantly
east-­‐west
traffic
– Firewall,
ACL
provided
at
the
VM
or
hypervisor
level
– ECMP
for
increased
bandwidth
/
availability
• VNF
need
to
be
stateless
– Recreate
a
VNF
by
re-­‐impor-ng
config.
– Applica-ons
should
tolerate
VNF
scaling
ac-ons
• Scale
up
limited
by
hypervisor
overhead

22. NFV
Promise:
Network
Automa-on
• Everything
in
CloudStack
is
– API-­‐driven
– Self-­‐service
• No
chance
of
misconfigura-on
• Configura-on
changes
are
atomic
across
VNF

23. Network
Automa-on:
Caveats
• VNF
are
unnecessarily
hard
to
configure
– Usually
have
no
APIs
– Varying
models
for
reconfigura-on:
• Impera-ve
(e.g.,
iptables)
• Configura-on
file
based
(usually
not
hitless)
• CLI
screen
scrape
• Netconf/YANG
etc
– Rollback
is
hard
• Out-­‐of-­‐band
changes
are
hard
to
reconcile
– Network
admins
s-ll
have
remote
access
to
VNF!

24. Cost
reduc-on
• Capex
– Replace
proprietary
firewalls,
routers,
NAT,
LB,
VPN
with
(free)
Linux
appliances
• Opex
– Instan-ate
complex
network
topologies
and
VNF
forwarding
graphs
in
seconds
• Development
– Reuse
and
improve
open
source

25. Cost
reduc-on:
Caveats
• None

26. Rate
of
innova-on
• Open
source
is
key
– Knowledge
is
just
a
Google
search
away
• Closed
source
VNFs
are
harder
to
integrate
2010
2009
2011
2012
2013
2014
#
of
core
dev
1
4

27. Rate
of
Innova-on
:
Caveats
• Development
model
– Solving
problems
or
marke-ng
claims?
• OSS
License
minefield
• Niche
needs
may
not
be
met
in
OSS
• Standardiza-on
/
Conven-ons
for
VNF
ini-aliza-on,
scaling,
metrics,
etc
are
needed

28. Rate
of
Innova-on:
caveat
• Avoid
NIH
• Focus
on
customer
value
not
vendor
value
• Clear
vision
required
• Requires
fast
itera-on
and
frequent
releases

29. Disaster
Recovery
• Advantage:
Very
low
MTTR
• Keys:
– Stateless
VNF
– Automated
VNF
configura-on
– Awareness
of
shared
fate
(rack
/
POP)
– Immutable
object
store
with
an
API
(e.g.,
S3)

30. DR:
caveats
• Focus
on
state
– Where
it
is
stored,
backed
up
and
recovered
from
– Decouple
it
from
VNF

31. Futures
• CloudStack
liaison
with
ETSI
NFV
MANO
WG
• Iden-fy
gaps
• Proof
of
concepts
(POC)
with
non-­‐IAAS
workloads