SlideShare a Scribd company logo
NFV Orchestration for
Optimal Performance
Hello There
DeWayne Filppi
Architect- GigaSpaces
Vadim Sukhomlinov
SDN/NFV Application Engineer – Intel
Agenda
◇The Challenge Data intensive
VNFs
◇The Environment DPA and EPA
◇The Missing Link Smart
Orchestration
◇Introducing TOSCA, ARIA, and Cloudify
The Challenge
NFV Orchestration
Requirements
Performance
◇ Placement and
configuration
◇ Mixed, Multiple
SLA sensitive
workloads
◇ Fine-tune
Hypervisor, OS
and other
bottlenecks
Scalability
◇ VNF placement
vs. VM placement
◇ Dynamic VNF
scaling in and out
◇ Maintain
Throughput and
SLA as VNF
scales
And More..
◇ High
Infrastructure
Utilization
◇ Service Function
Chaining (SFC)
◇ OSS/BSS
Interaction
◇ PNFV Integration
The Environment
DPA
◇ NFVI Level
◇ CPU pinning
◇ NUMA
◇ DPDK
◇ SR-IOV
◇ And more…
◇ VIM level
◇ Recognizes and
configures platform and
infrastructure
◇ Enables “asking” for
the right resources
EPA
FOR OPTIMIZED VNF PERFORMANCE, ENVIRONMENT AWARE
ORCHESTRATION IS REQUIRED
?
Requirements on NFV
infrastructure
◇Some differences to generic IT:
• Determinism and performance
• Small packet processing
• Real-time, latency (<10μs for CPE and access functions), jitter
• Availability (detect failed VMs in <1s and
autorestart, recover host failures)
• Regulatory, geolocation (incl. geo redundancy)
• Accelerate VM migration in planned
maintenance
• HW acceleration cards
• Advanced management (OSS/BSS)
VM1 VM2 VM3
Orchestration
service aware
platform aware
Hypervisor
CPU Chipset
Switch
Silicon
NIC
Silicon Linux+Apps
EPA for demanding applications recognizes
and configures platform/infrastructure
Source: Telefonica, May 2015
Server architecture and
workload placement
core15
core14
core13
core12
core11
core10
core9
core8
core7
core6
core5
core4
core3
core2
core1
core0
socket 0
core15
core14
core13
core12
core11
core10
core9
core8
core7
core6
core5
core4
core3
core2
core1
core0
socket 1
QPI
PCIe PCIe
NIC0 NIC1 NIC0 NIC1
1
0
G
1
0
G
1
0
G
1
0
G
1
0
G
1
0
G
1
0
G
1
0
G
memory memory
huge
page
huge
page
huge
page
huge
page
huge
page
huge
page
huge
page
huge
page
Legend:
Good placement
Bad placement
Key Enhanced Platform
Awareness features
◇Example platform features
for NFV dataplane
workloads:
• SR-IOV
• Huge Pages
• NUMA
• vCPU pinning to cores
• CPU model, instructions, Last Level
Cache
• vSwitch
• Real Time
• Trusted Execution Technology
• …
◇Cumulative performance impact on
Intel® Data Plane Performance
Demonstrators from platform
optimizations
as % of 10Gb/s
Source: Intel white paper QoS in
BRAS with Linux and IA, August 2014
13
Source: Telefonica, May 2015
EPA at Resource Orchestration
15
• NFV Resource Orchestrator needs
to understand what is required to
support each VM
• Requests facilities from the
relevant VIM, which then allocates
logical and physical resources
from a managed pool
Servers &
hypervisor
Resource
Orchestration
Virtual Network
Function
V
M
V
M
V
M
V
M
Infrastructure as a Service
VIM
Cloud/SDN
OpenStack* (EPA)
Features
16
Non-Uniform Memory Architecture (NUMA) CPU & memory configuration (co-located memory and socket)
NUMA I/O Device locality configuration (co-located PCI device and socketa)
CPU Pinning
Huge Page Support (2MB/1GB)
I/O Pass-through (Full PCIe pass-through of the I/O device to the guest)
I/O Pass-through (Virtual Function (SR-IOV) pass-through of the I/O device to the guest)
Intel ® Quick Assist Technology
Intel® TXT (Trusted platform)
HW offload API for RRC (Ruby Rapids)
Intel® AES-NI, AVX, SSE4.2, RD RAND (Instruction Set Extensions)
CPU Model (explicit model match for planned, or better for the future)
CPU llc (cache size)
vSwitches (type, capability) - OVS specified, with or without either DPDK/HWOA
LLC utilization
CPU ddio (direct i/o) - bios has to turn it on, DPDK makes use of it
CAT (cache allocation)
Example EPA list
benefit/use cases EPA feature HP ProLiant w Niantic NICs
avoid vSwitch bottleneck I/O Pass-through (Full PCIe pass-through of the I/O device to the guest) yes
avoid vSwitch bottleneck
I/O Pass-through (Virtual Function (SR-IOV) pass-through of the I/O device to
the guest) yes
connect NIC cache and memory CPU ddio (direct i/o) -bios has to turn it on, DPDK makes use of it yes (in BIOS settings)
memory close to vCPU
Non-Uniform Memory Architecture (NUMA) CPU & Memory configuration (co-
located memory and socket) yes
IO close to vCPU NUMA I/O Device Locality configuration (co-located PCI device and socket) yes
host OS scheduler doesn't move VMs CPU Pinning yes
requirement for DPDK packet processing
performance Huge Page Support (2MB/1GB) yes
correct VM placement AES-NI, AVX, SSE4.2, RD RAND (Instruction Set Extensions) yes
min compute performance CPU Model (explicit model match for planned, or better for the Future) yes
min compute performance CPU Last Level Cache (cache size) yes
min vSwitch features/performance
vSwitches (type, capability) -OVS specified, with or without either
DPDK/HWOA yes
virtualization latency/jitter real time hypervisor yes (needs BIOS settings)
trusted boot (trusted compute pools, geolocation) Trusted eXecution Technology yes
EPA Configuration
18
* Other names and brands may be claimed as the property of others
Descriptor with
Enhanced Platform
Awareness (EPA)
requirements
Example descriptor
with EPA requirements
The Missing Link
Environment Aware Orchestration
NFV Orchestration for Optimal Performance
VNFs Are (Very) Complex
◇ Multi-Tiers
◇ Load balanced
◇ Strict HW / Placement
◇ NUMA, DPDK, SR/IOV,
Affinity / Anti-Affinity
◇ Firewalls, networks,
storage,
◇ Often hard wired
◇ Day 1? and day 2?
◇ Scaling, Healing, elasticity?
Service Chains More So..
Add Their Own Complexities:
◇ Forwarding Graphs(dynamic?)
◇ Complex Environments
◇ Cutting Edge and Legacy in same
environment
◇ Multiple geographic locations
◇ Complex policies and SLA
requirements
“ The only constant is change”
-
Unknown
WHAT IF
You could orchestrate and
manage any VNF the same
way?
Orchestrating VNF
Blueprints with TOSCA
Topology Workflow Policy
(Topology Orchestration Specification for Cloud Applications)
VM
Container
TOSCA Models Deployments As
A Node Graph: The Blueprint
VM
Container
VNF
VM
VNF VNF
HostedOn
ConnectedTo
Network A Network B
Subnet Subnet
Node Type:
VM
Relationship:
ConnectedTo
TOSCA Models Are Interpreted
by Workflows
• “Install” workflow
VM
VNF
VM
Container
VNF
Server
VNF
Network
Subnet
1
2
4
3
4 4
5
<Placement/Affinity>
Flow
Graph
Creation
TOSCA Policies
• Asynchronous Post Deployment Actions
• Detect node failure and heal
• Detect capacity threshold and scale
• Any other automated async capability
TOSCA Requirements &
Capabilities
• Enables abstract specifications
• Platform/Cloud/VIM independent
• Example: rather than specify OS Image,
specify minimum OS Version
• Example: specify VNF host provides SR-IOV.
VNF Topology
VM
Container
node.js
VM
Tomcat
Old-School
Java App
VM
MongoDB
Hosted on
Connected-to
Node Type:
Container
◇ Types, Nodes and Interfaces
◇ Inputs and Outputs
◇ Relationships
◇ Requirements and Capabilities
VM
Container
VNF Blueprint
VM
Container
Bono (edge
proxy)
VM
Sprout (SIP
router)
Homer (xml
store)
HostedOn
ConnectedTo
Network A Network B
Subnet Subnet
Node Type:
VM
ConnectedTo
VM
Container
VNF Blueprint
VM
Container
Bono
VM
Sprout Homer
HostedOn
ConnectedTo
Network A Network B
Subnet Subnet
Node Type:
VM
ConnectedTo
◇ YAML Blueprint
◇ Resources
(Modules, YANG,
Scripts, Others)
Introducing Cloudify
Pure-Play Orchestrator based on TOSCA
VNF
Blueprint
(TOSCA)
Infrastructure
Plugins
Container
Plugins
Conf. Mgmt
Plugins
● Provision
● Configure
● Monitor
● Manage
Monitoring &
Alarming
VNF
Blueprint
(TOSCA)
Infra
Plugins
Container
Plugins
Conf Mgmt
Plugins
● Provision
● Configure
● Monitor
● Manage
Monitoring &
Alarming
Cloudify Key Aspects
Open Source
Open Source is key to
drive innovation and
create superb quality
software. No more
monolithic vendor
tied monsters.
Open Standard
Open standard and
vendor neutral
language based on
the TOSCA Spec for
describing VNFs and
forwarding graphs.
Future Proof
Be ready for what’s
coming and leverage
new emerging
Technologies and
tools.
“It is not the strongest of the
species that survives,
It is the one that is
most adaptable to change.”
-Charles Darwin
How
Cloudify
Fits in
ETSI NFV ?
Orchestrator
VNF Manager
Tying It All Together
Requirements:
● SR-IOV
● DPDK
● etc
VNFD
EPA Enabled VIM
NFVO
Exposing Platform Capabilities
NFVI
What Is ARIA?
◇ Embeddable TOSCA orchestration Engine
■ TOSCA Parser and Execution Engine
○ Python Library and CLI
■ Common Plugins
◇ Set of examples for Enterprise and NFV
◇ Open Source
◇ Open Governance
■ Apache Software Foundation
◇ www.AriaTOSCA.org
TOSCA Orchestration
Engine Library
Apache Software
Foundation Project
OASIS TOSCA
Defines and Refines
TOSCA SPEC
Platform
Consumes ARIA Library for TOSCA
orchestration capabilities
OPEN-O
Consumes ARIA library for TOSCA
orchestration capabilities and Multi-VIM
ARIA
ARIA
Tacker
Consumes ARIA library as Tacker
Orchestration Plugin for TOSCA
capabilities and Multi-VIM support
ARIA
Murano
Consumes ARIA library as orchestrator
Plugin for TOSCA capabilities and Multi-
VIM support
ARIA
Mist.IO
Consumes ARIA library as orchestrator
Plugin for TOSCA capabilities and Multi-
VIM support
ARIA
Use Cases
Spec
Gigaspaces & Intel
◇ Aria and Open-O initiative
◇ NFV Sales Collaboration
◇ Joint Effort to test VNFs on EPA hardware
References
◇ Cloudify community portal:
http://getcloudify.org
◇ NFV related posts at the Cloudify blog:
http://getcloudify.org/tags/NFV/
◇ Demo Video:
https://youtu.be/84gEy6Vvc0E
◇ Cloudify ClearWater https://github.com/Orange-
OpenSource/opnfv-cloudify-clearwater
Thank You
Questions?
Find us at:
◇ Twitter @CloudifySource
◇ email info@gigaspaces.com

More Related Content

NFV Orchestration for Optimal Performance

  • 2. Hello There DeWayne Filppi Architect- GigaSpaces Vadim Sukhomlinov SDN/NFV Application Engineer – Intel
  • 3. Agenda ◇The Challenge Data intensive VNFs ◇The Environment DPA and EPA ◇The Missing Link Smart Orchestration ◇Introducing TOSCA, ARIA, and Cloudify
  • 5. NFV Orchestration Requirements Performance ◇ Placement and configuration ◇ Mixed, Multiple SLA sensitive workloads ◇ Fine-tune Hypervisor, OS and other bottlenecks Scalability ◇ VNF placement vs. VM placement ◇ Dynamic VNF scaling in and out ◇ Maintain Throughput and SLA as VNF scales And More.. ◇ High Infrastructure Utilization ◇ Service Function Chaining (SFC) ◇ OSS/BSS Interaction ◇ PNFV Integration
  • 7. DPA ◇ NFVI Level ◇ CPU pinning ◇ NUMA ◇ DPDK ◇ SR-IOV ◇ And more… ◇ VIM level ◇ Recognizes and configures platform and infrastructure ◇ Enables “asking” for the right resources EPA FOR OPTIMIZED VNF PERFORMANCE, ENVIRONMENT AWARE ORCHESTRATION IS REQUIRED ?
  • 8. Requirements on NFV infrastructure ◇Some differences to generic IT: • Determinism and performance • Small packet processing • Real-time, latency (<10μs for CPE and access functions), jitter • Availability (detect failed VMs in <1s and autorestart, recover host failures) • Regulatory, geolocation (incl. geo redundancy) • Accelerate VM migration in planned maintenance • HW acceleration cards • Advanced management (OSS/BSS) VM1 VM2 VM3 Orchestration service aware platform aware Hypervisor CPU Chipset Switch Silicon NIC Silicon Linux+Apps EPA for demanding applications recognizes and configures platform/infrastructure
  • 10. Server architecture and workload placement core15 core14 core13 core12 core11 core10 core9 core8 core7 core6 core5 core4 core3 core2 core1 core0 socket 0 core15 core14 core13 core12 core11 core10 core9 core8 core7 core6 core5 core4 core3 core2 core1 core0 socket 1 QPI PCIe PCIe NIC0 NIC1 NIC0 NIC1 1 0 G 1 0 G 1 0 G 1 0 G 1 0 G 1 0 G 1 0 G 1 0 G memory memory huge page huge page huge page huge page huge page huge page huge page huge page Legend: Good placement Bad placement
  • 11. Key Enhanced Platform Awareness features ◇Example platform features for NFV dataplane workloads: • SR-IOV • Huge Pages • NUMA • vCPU pinning to cores • CPU model, instructions, Last Level Cache • vSwitch • Real Time • Trusted Execution Technology • … ◇Cumulative performance impact on Intel® Data Plane Performance Demonstrators from platform optimizations as % of 10Gb/s Source: Intel white paper QoS in BRAS with Linux and IA, August 2014
  • 13. EPA at Resource Orchestration 15 • NFV Resource Orchestrator needs to understand what is required to support each VM • Requests facilities from the relevant VIM, which then allocates logical and physical resources from a managed pool Servers & hypervisor Resource Orchestration Virtual Network Function V M V M V M V M Infrastructure as a Service VIM Cloud/SDN
  • 14. OpenStack* (EPA) Features 16 Non-Uniform Memory Architecture (NUMA) CPU & memory configuration (co-located memory and socket) NUMA I/O Device locality configuration (co-located PCI device and socketa) CPU Pinning Huge Page Support (2MB/1GB) I/O Pass-through (Full PCIe pass-through of the I/O device to the guest) I/O Pass-through (Virtual Function (SR-IOV) pass-through of the I/O device to the guest) Intel ® Quick Assist Technology Intel® TXT (Trusted platform) HW offload API for RRC (Ruby Rapids) Intel® AES-NI, AVX, SSE4.2, RD RAND (Instruction Set Extensions) CPU Model (explicit model match for planned, or better for the future) CPU llc (cache size) vSwitches (type, capability) - OVS specified, with or without either DPDK/HWOA LLC utilization CPU ddio (direct i/o) - bios has to turn it on, DPDK makes use of it CAT (cache allocation)
  • 15. Example EPA list benefit/use cases EPA feature HP ProLiant w Niantic NICs avoid vSwitch bottleneck I/O Pass-through (Full PCIe pass-through of the I/O device to the guest) yes avoid vSwitch bottleneck I/O Pass-through (Virtual Function (SR-IOV) pass-through of the I/O device to the guest) yes connect NIC cache and memory CPU ddio (direct i/o) -bios has to turn it on, DPDK makes use of it yes (in BIOS settings) memory close to vCPU Non-Uniform Memory Architecture (NUMA) CPU & Memory configuration (co- located memory and socket) yes IO close to vCPU NUMA I/O Device Locality configuration (co-located PCI device and socket) yes host OS scheduler doesn't move VMs CPU Pinning yes requirement for DPDK packet processing performance Huge Page Support (2MB/1GB) yes correct VM placement AES-NI, AVX, SSE4.2, RD RAND (Instruction Set Extensions) yes min compute performance CPU Model (explicit model match for planned, or better for the Future) yes min compute performance CPU Last Level Cache (cache size) yes min vSwitch features/performance vSwitches (type, capability) -OVS specified, with or without either DPDK/HWOA yes virtualization latency/jitter real time hypervisor yes (needs BIOS settings) trusted boot (trusted compute pools, geolocation) Trusted eXecution Technology yes
  • 17. * Other names and brands may be claimed as the property of others Descriptor with Enhanced Platform Awareness (EPA) requirements
  • 19. The Missing Link Environment Aware Orchestration
  • 21. VNFs Are (Very) Complex ◇ Multi-Tiers ◇ Load balanced ◇ Strict HW / Placement ◇ NUMA, DPDK, SR/IOV, Affinity / Anti-Affinity ◇ Firewalls, networks, storage, ◇ Often hard wired ◇ Day 1? and day 2? ◇ Scaling, Healing, elasticity?
  • 22. Service Chains More So.. Add Their Own Complexities: ◇ Forwarding Graphs(dynamic?) ◇ Complex Environments ◇ Cutting Edge and Legacy in same environment ◇ Multiple geographic locations ◇ Complex policies and SLA requirements
  • 23. “ The only constant is change” - Unknown
  • 24. WHAT IF You could orchestrate and manage any VNF the same way?
  • 25. Orchestrating VNF Blueprints with TOSCA Topology Workflow Policy (Topology Orchestration Specification for Cloud Applications)
  • 26. VM Container TOSCA Models Deployments As A Node Graph: The Blueprint VM Container VNF VM VNF VNF HostedOn ConnectedTo Network A Network B Subnet Subnet Node Type: VM Relationship: ConnectedTo
  • 27. TOSCA Models Are Interpreted by Workflows • “Install” workflow VM VNF VM Container VNF Server VNF Network Subnet 1 2 4 3 4 4 5 <Placement/Affinity> Flow Graph Creation
  • 28. TOSCA Policies • Asynchronous Post Deployment Actions • Detect node failure and heal • Detect capacity threshold and scale • Any other automated async capability
  • 29. TOSCA Requirements & Capabilities • Enables abstract specifications • Platform/Cloud/VIM independent • Example: rather than specify OS Image, specify minimum OS Version • Example: specify VNF host provides SR-IOV.
  • 30. VNF Topology VM Container node.js VM Tomcat Old-School Java App VM MongoDB Hosted on Connected-to Node Type: Container ◇ Types, Nodes and Interfaces ◇ Inputs and Outputs ◇ Relationships ◇ Requirements and Capabilities
  • 31. VM Container VNF Blueprint VM Container Bono (edge proxy) VM Sprout (SIP router) Homer (xml store) HostedOn ConnectedTo Network A Network B Subnet Subnet Node Type: VM ConnectedTo
  • 32. VM Container VNF Blueprint VM Container Bono VM Sprout Homer HostedOn ConnectedTo Network A Network B Subnet Subnet Node Type: VM ConnectedTo ◇ YAML Blueprint ◇ Resources (Modules, YANG, Scripts, Others)
  • 36. Cloudify Key Aspects Open Source Open Source is key to drive innovation and create superb quality software. No more monolithic vendor tied monsters. Open Standard Open standard and vendor neutral language based on the TOSCA Spec for describing VNFs and forwarding graphs. Future Proof Be ready for what’s coming and leverage new emerging Technologies and tools.
  • 37. “It is not the strongest of the species that survives, It is the one that is most adaptable to change.” -Charles Darwin
  • 38. How Cloudify Fits in ETSI NFV ? Orchestrator VNF Manager
  • 39. Tying It All Together
  • 40. Requirements: ● SR-IOV ● DPDK ● etc VNFD EPA Enabled VIM NFVO Exposing Platform Capabilities NFVI
  • 41. What Is ARIA? ◇ Embeddable TOSCA orchestration Engine ■ TOSCA Parser and Execution Engine ○ Python Library and CLI ■ Common Plugins ◇ Set of examples for Enterprise and NFV ◇ Open Source ◇ Open Governance ■ Apache Software Foundation ◇ www.AriaTOSCA.org
  • 42. TOSCA Orchestration Engine Library Apache Software Foundation Project OASIS TOSCA Defines and Refines TOSCA SPEC Platform Consumes ARIA Library for TOSCA orchestration capabilities OPEN-O Consumes ARIA library for TOSCA orchestration capabilities and Multi-VIM ARIA ARIA Tacker Consumes ARIA library as Tacker Orchestration Plugin for TOSCA capabilities and Multi-VIM support ARIA Murano Consumes ARIA library as orchestrator Plugin for TOSCA capabilities and Multi- VIM support ARIA Mist.IO Consumes ARIA library as orchestrator Plugin for TOSCA capabilities and Multi- VIM support ARIA Use Cases Spec
  • 43. Gigaspaces & Intel ◇ Aria and Open-O initiative ◇ NFV Sales Collaboration ◇ Joint Effort to test VNFs on EPA hardware
  • 44. References ◇ Cloudify community portal: http://getcloudify.org ◇ NFV related posts at the Cloudify blog: http://getcloudify.org/tags/NFV/ ◇ Demo Video: https://youtu.be/84gEy6Vvc0E ◇ Cloudify ClearWater https://github.com/Orange- OpenSource/opnfv-cloudify-clearwater
  • 45. Thank You Questions? Find us at: ◇ Twitter @CloudifySource ◇ email info@gigaspaces.com

Editor's Notes

  1. Describe VNF requirements (e.g. needs NUMA pinning) Understand environments capabilities (host X,Y supports NUMA, host X has no capacity, host Y available) Match the requirement and capability -> placing the load optimally
  2. Needs to represent VNF complexity + needs and the ability of Cloudify to orchestrate on the hybrid (partly data acceleration enabled) environment
  3. Needs to represent VNF complexity + needs and the ability of Cloudify to orchestrate on the hybrid (partly data acceleration enabled) environment
  4. Needs to represent VNF complexity + needs and the ability of Cloudify to orchestrate on the hybrid (partly data acceleration enabled) environment
  5. Needs to represent VNF complexity + needs and the ability of Cloudify to orchestrate on the hybrid (partly data acceleration enabled) environment
  6. Needs to represent VNF complexity + needs and the ability of Cloudify to orchestrate on the hybrid (partly data acceleration enabled) environment
  7. Needs to represent VNF complexity + needs and the ability of Cloudify to orchestrate on the hybrid (partly data acceleration enabled) environment