NFV Orchestration for Optimal Performance
- 1. 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
- 9. Source: Telefonica, May 2015
- 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
- 12. 13 Source: Telefonica, May 2015
- 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
- 18. Example descriptor with 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)
- 33. Introducing Cloudify Pure-Play Orchestrator based on TOSCA
- 34. VNF Blueprint (TOSCA) Infrastructure Plugins Container Plugins Conf. Mgmt Plugins ● Provision ● Configure ● Monitor ● Manage Monitoring & Alarming
- 35. VNF Blueprint (TOSCA) Infra Plugins Container Plugins Conf Mgmt Plugins ● Provision ● Configure ● Monitor ● Manage Monitoring & Alarming
- 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
- #28: 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
- #29: Needs to represent VNF complexity + needs and the ability of Cloudify to orchestrate on the hybrid (partly data acceleration enabled) environment
- #30: Needs to represent VNF complexity + needs and the ability of Cloudify to orchestrate on the hybrid (partly data acceleration enabled) environment
- #31: Needs to represent VNF complexity + needs and the ability of Cloudify to orchestrate on the hybrid (partly data acceleration enabled) environment
- #32: Needs to represent VNF complexity + needs and the ability of Cloudify to orchestrate on the hybrid (partly data acceleration enabled) environment
- #34: Needs to represent VNF complexity + needs and the ability of Cloudify to orchestrate on the hybrid (partly data acceleration enabled) environment
- #35: Needs to represent VNF complexity + needs and the ability of Cloudify to orchestrate on the hybrid (partly data acceleration enabled) environment