NFV promises to do to carrier networks what Cloud has done to enterprise computing. NFV has been a part of CloudStack in order to scale and perform effectively. This presentation gives an overview of how and why NFV is used in CloudStack. This was presented at the NFV and SDN Summit on March 20, 2014 in Paris
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
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
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
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