nfv open stack-shuo-yang
Post on 29-Nov-2014
1.830 Views
Preview:
DESCRIPTION
TRANSCRIPT
Shuo Yang Principal Architect of Cloud Computing, US R&D Center
OpenStack and NFV: Convergence of IT and CT Infrastructure
1
Agenda
Challenges and Opportunities
Relevant Industry Trends
Telco Operator Perspective
1
2
3
2
Software-Defined Everything
SDN, SDS, SDDC…
Cloud – a Software-defined Resource Pool
Virtualizing the underlying components and making it accessible through an API
Abstraction, aggregation(pooled), and automation via API
What has been done for compute is being repeated for network and
storage
Virtualization and consolidation
Programmatic provision, orchestration
Scale-out
Commoditization (standard components)
Virtual
Machines
Compute API
Virtual
Storage
Storage API
Virtual
Networks
Network API
3
OpenStack – a 10,000 Feet View
OpenStack Mission
To produce the ubiquitous Open Source cloud computing platform that will meet the
needs of public and private cloud providers regardless of size…
Common Interest from IT Vendors
Oct. 2010, first design summit held in Austin
No single dominant vendor, avoid vendor lock-in
Linux for cloud
API Driven Architecture
Proven architecture model used by the largest public clouds and made it accessible to
masses for use on commodity hardware
4
NFV – a 10,000 Feet View
NFV Mission
Replace purposely-built hardware with standard hardware for better price
performance ratio
Common Interest from Telco Service Providers
Born in Oct. 2012 by a list of top Telco service providers
No vendor lock-in
Apache family for network applications
Adding API to Control Network Functionality
use IT methodology to solve CT problems
Functionalities L4-L7
5
Agenda
Challenges and Opportunities
Relevant Industry Trends
Telco Operator Perspective
1
2
3
6
NFV – a Carrier-lead Initiative
Benefit of NFV Initiative
Reduction of Capex
Reduction of Opex
Faster time-to-market
Agility and Flexibility of Delivering Network
Functionality
Source: NFV_White_Paper
7
Execution reference points
Main NFV reference points Other reference points
Source: NFV GS NFV-0010 V0.1.6 2013/8
VNF: Virtual Network Function
OSS/BSS:Traditional OSS/BSS (Operations/Business Support Systems)
EMS : Traditional EMS (Element Management System )
NFVI: NFV Infrastructure 1
2
3
4
Computing Hardware
Storage Hardware
Network Hardware
Hardware resources
Virtualisation Layer
Virtualised
Infrastructure
Manager(s)
VNF Manager(s)
VNF 2
Orchestrator
OSS/BSS
NFVI
VNF 3
VNF 1
Virtual Computing
Virtual Storage
Virtual Network
EMS 2
EMS 3
EMS 1
Service, VNF and Infrastructure Description
Or-Vi
Or-Vnfm
Vi-Vnfm
Os-Ma
Se-Ma
Ve-Vnfm
Nf-Vi
Vn-Nf
Vl-Ha
1
2
3
4 5
MANO: Management and Orchestration 5 MANO
NFV Reference Architecture
NFV E2E Reference Architecture
8
DC/Rack
BOX Software Model
Decoupling between software(Telecom App) and hardware Standardized interface between NFV elements and infrastructure Telco network/element deployment automation, roll-out efficiency Resource pools cover all segment networks from access network, GW,
core networks, to OSS/BSS and application
LBS App 2 App 2 App 3 App 4
Switch Fabric Controller
ATCA
Ap
p 1
LBS
Co
ntro
ller
Ap
p 2
Ap
p 2
Ap
p 4
Ap
p 3
LBS App 2 App 2 App 3 App 4
IP/Ethernet Fabric
VM VM VM VM VM
VM
Controller
Physical Server Physical Server
EMS/NMS Consistent app
and physical resource view
No change to the EMS Physical and app, 1:1 mapping
Cloud – Perfect Platform for NFV
NFV Software Model
Chassis
ATCA
DC/Rack
9
BBU SRC RNC
PCRF SGSN MME
SDN Contro
ller &APPs
IMS BSS OSS EMS …… Third-Party APP
Office GGSN EPC FW DPI SBC
BRAS
OpenStack+ API
ESX/Hyper-
V KVM/XEN
Server Server Storage Server
OVS/VGW
Switch/GW Server
OpenStack
Nova Cinder Neutron
VNF Managers & MANO
NFVI managers
Virtualization Layer
COTS Hardware
NFV on OpenStack
IT Middleware
CT Middleware
Ceph
Server
ICT DevOps Tool Sets
NFV is expected to realize the many benefits of cloud
10
Agenda
Challenges and Opportunities
Relevant Industry Trends
Telco Operator Perspective
1
2
3
11
Differences Between NFV Wants and Cloud Provides
Computation vs. Connectivity
Compute-centric cloud platform vs. connect-centric NFV workload
Small App vs. Big App
Cloud enable multiple tenants with many relatively small VMs to share compute, storage,
and connect resources in a cost- and energy-efficient manner while NFV need to scale
network functions to serve millions and even tens of millions of subscribers for one or a few
large operators
Virtual and Physical Separation
Cloud decouple the virtual and physical domains while NFV want orderly handoffs between
definitive segments and service boundaries
12
Problems Observed with NFV Migration
DC/Rack
BOX Software Model
The BOX based application relied on network fabrics that is not provided by the best efforts cloud network
The lack of the connected view of the physical and virtual alarms/events makes EMS impossible to function
LBS App 2 App 2 App 3 App 4
Switch Fabric Controller
ATCA
Ap
p 1
LBS
Co
ntro
ller
Ap
p 2
Ap
p 2
Ap
p 4
Ap
p 3
LBS App 2 App 2 App 3 App 4
IP/Ethernet Fabric
VM VM VM VM VM
VM
Controller
Physical Server Physical Server
EMS/NMS Consistent app
and physical resource view
No change to the EMS Physical and app, 1:1 mapping
NFV Software Model
Chassis
ATCA
zero loss, low latency control link
Dedicated bandwidth Separation of
the VM and physical infrastructure mgmt
Overlay tunnel, no QoS or BW assurance
DC/Rack
?
?
13
NFV Challenges for OpenStack
Cross-DC Hierarchy Resource Scheduling
Single telecom app instance spread across multiple DCs for resilience/performance
Operator wants to treat DCs as one when deploying such apps
Affinity Scheduling
Telecom apps have multiple, tightly coupled VMs, and heavy Inter-VM traffic
High availability requirements (99.999%)
Policies govern redundancy & performance relationships
• Cross Version Upgrade
Telco apps have large data-plane traffic, often use SR-IOV & H/W accelerators
Redundancy mechanisms adopted to protect against hardware failures
Traditionally upgrades are coordinated with app
14
Cross-DC Hierarchy Resource Scheduling
• Stack DCs into Tree Hierarchy
• Each DC can operate independently but also be managed by a higher level DC
• Tenant requests resources from the “root” DC, which coordinates everything else
• Use only standard OpenStack REST interfaces between DCs
• Child is not aware it is being managed
• Cells Provide Tree-only for Nova, Don’t Work Well with Multiple DCs
• Need to configure firewalls for inter-cell, non HTTP traffic
• Other services in each DC need to be coordinated
• Each DC still needs to function independently
15
NE005
Manually (pre) partition the site into AvailabilityZones and host aggregates
Use same/different hostAggregate/AZ/... policies Deploy VMs into batches of "compatible VMs”
Deploy batches in (right) sequence. Can lead to “unemployable” VMs.
Create batches of VMs with different properties. Specify constraints between VMs
Within a batch & between batches. Capture available bandwidth info & bandwidth
requirements for use as scheduling constraints. Use linear programming to provide optimal
solutions
HOST Aggregate2
HOST Aggregate1
HOST1 HOST2 HOST3 HOST4
` diff host
diff AZ same host aggregate
same host aggregate
?
Affinity Scheduling Enhancement
(Short term) solution
(Long term) solution
NE005
HOST Aggregate1 HOST Aggregate2
16
Service Container Based Resource Allocation Each service container encapsulated all the apps of a BOX The service container will be allocated/scaled as an inseparable resource unit A lightweight Linux container (LXC) based app will further reduce the computing overhead
The Subscriber Flow-based Load Balance Direct Flow to Service Containers, the Containers Are Added to Scale the Entire Systems Capability
DC/Rack
Service Container
Service Container
Service Container
Service Container
Sub aware
LBS
Function wise equivalent of a BOX
EMS/NMS Consistent app and physical resource
view
EMS sees multiple BOXes which is consistent as pre-NFV DC/Rack
LBS App 2 App 2 App 3 App 4
vSwitch
VM VM VM VM VM
VM
Controller
Physical Server
Inter VM traffic is essentially “memory copy”
Hypervisor
Service Container Based Resource Allocation DC/Rack
17
Application-Centric Networking Platform App Container on Provisioning and Management
Linux container, server template App configuration management
AWS OpsWork/formation, OpenStack Heat,
App Level HA and Data Protection Application-aware infrastructure DR (data recovery) strategy
App Level Monitoring and SLA
App-driven dynamic resource scheduling
NFV Needs an App-Centric Architecture in Cloud
18
Together, We Can Make a History
• Fear Not, Facing Challenges is the Only Constant in Our Industry
• Telcos Service Providers Define/Understand NFV Real Needs with Decades of
Operational Experience
• Telco Solution Vendors, such as Huawei, Understand Telcos Networking
Stacks with Decades of Engineering Exercise
• OpenStack Provides a Common Platform to Start our Common Journey
• No Vendor Lock-in
• Create/Provide New Values on Top of Cloud Architecture
Copyright©2013 Huawei Technologies Co., Ltd. All Rights Reserved.
The information in this document may contain predictive statements including, without limitation, statements regarding the future financial and operating results, future product
portfolio, new technology, etc. There are a number of factors that could cause actual results and developments to differ materially from those expressed or implied in the predictive
statements. Therefore, such information is provided for reference purpose only and constitutes neither an offer nor an acceptance. Huawei may change the information at any time
without notice.
20
Challenges on Current Cloud Platforms
Parity issues with existing NFs
Manageability, performance, reliability, integration, and maintainability
Existing operation tools not longer meet the needs
Auto deployment and configuration in cloud platform
Operation monitoring especially networking
Troubleshooting across physical and virtual world
Lack of app-level infrastructure support
Only VM or platform level, if any, but on big app that has dependent modules
Resource provisioning
Resource pooling and scale-out
App-level policy support: dependency, sequencing, HA and SLA
top related