OpenStack Telco Cloud Challenges, David Fick, Oracle

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |

OpenStack – Telco Cloud Challenges

David Fick, Senior Software ArchitectOracle20 Aug 2015

Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 2

Telecom Applications Pets or Cattle?

Pet application1

/pet ap·pli·ca·tion/cloud expression a. Application instances given names b. Each instance is unique, raised, and cared for c. When it gets sick you nurse it back to health1 Adapted from CERN presentations

Credit: www.nmscommunications.com

Example: IMSOR


Telecom Applications Why are they pets today?• Dedicated hardware and a fully integrated solution from the hardware up through the

application• Traditionally a different style of application from most IT applications– Predominantly stateful applications (in-memory state)– Create and manage long-term service connections from establishment through teardown– Highly distributed (including geographic redundancy)– Real-time or near real-time

• Strict availability requirements– Application availability of 5+ 9s (including maintenance actions & upgrades)– Application elements designed to be highly redundant

• Highly network intensive workloads– Timing is very tight for telecommunications protocols– High bandwidth & low latency are a necessity

• Operations– In-service upgrades are mandatory throughout the stack– “Standard” management interfaces to tie into higher level management infrastructure


Telecom Applications Moving to the cloud• Telecom applications in the cloud are not really pets any more since the

infrastructure is no longer provided as part of the application– More a breed of cattle with specific performance and availability SLAs!– And a cloud supporting such SLA policies and enforcement capabilities would be attractive to

Enterprise/IT cloud applications as well

• Moving telecom applications to the cloud requires:– Application changes– Enhancements to the cloud infrastructure

• OpenStack capabilities to fulfill these requirements fall into the following broad categories:– Basic feature enhancements– Support NFV management & orchestration use cases– Performance– Availability & reliability– Operations / Manageability


Telco Cloud NFV Architectural Framework

• Key NFV architectural elements for this discussion:• NFV Infrastructure (NFVI)• Virtualized

Infrastructure Managers, e.g. OpenStack

• Management and Orchestration “stack”

• VNFs, i.e. applications


OpenStack Capabilities Basic Features• Networking enhancements– VLAN trunking within VMs– Complete IPv6 support within Neutron (IPv4 feature parity)– Disablement of port security rules for packet processing

workloads– Combination of L3 HA and DVR

• Features to support migration of PNFs to VNFs– Shared volumes between VM instances– Application virtual IP (VIP) management


OpenStack Capabilities Management & Orchestration• All interactions with a VIM, such as OpenStack, need to be orchestratable

via higher level NFV MANO elements (Orchestrator and VNF managers)• As many of the specifics of the OpenStack deployment model need to be

abstracted out of the interfaces exposed to the other NFV MANO elements– For example, Neutron operations that require a priori knowledge about the cloud

deployment

• Resource reservation and allocation interfaces• Service chaining for “bump-in-the-wire” VNFs• On-demand and automatic scaling of VNFs/services• Notifications for virtualized resource configuration and state changes for

consumption by VNF managers and the service orchestrator• Metrics collection related to the operation, usage, and state of the VNFs,

virtual resources, and physical resources


OpenStack Capabilities Performance• Exclusive access to allocated resources– CPU: e.g. CPU pinning– Memory: No oversubscription / large page support for guest RAM allocations– Network: Traffic separation

• Workload placement with optimal performance characteristics– NUMA placement– Placement or co-location of associated application elements (affinity filter)

• Networking– Highest performance network paths, e.g. support for:

• DPDK-enhanced Open vSwitch• SR-IOV

– Quality of Service (QoS)• Bandwidth• Latency

– Minimize packet hops thru system• While meeting availability and reliability requirements!


OpenStack Capabilities Availability & Reliability• Cloud infrastructure needs to “enable” hosted applications to meet

their service availability requirements– Cloud infrastructure’s availability numbers must be sufficient to allow

application’s to meet their availability targets• Infrastructure service failovers cannot take many seconds

– VM placement policies/rules to ensure redundant VMs are not placed in the same fault domain (anti-affinity)

– Upgrades to the cloud infrastructure cannot affect application availability• Live migration likely not an option for a certain class of telecom applications

– (Optional) Cloud infrastructure could support the interfaces needed to drive HA policies within the hosted applications (e.g. notifications)

• Hosted applications (or their management elements) should not need to interact with the cloud infrastructure after initial deployment


OpenStack Capabilities Operations / Manageability• In-service upgrade of the cloud infrastructure– Upgrade strategies that require taking down a service’s control

plane are unacceptable

• Auditing and traceability services across all layers– Especially for network paths, e.g. port mirroring– Being able to track a request as it leads to additional

actions/operations within other OpenStack services

Copyright © 2015 Oracle and/or its affiliates. All rights reserved. |Oracle Confidential – Internal

11

Technology

OpenStack Telco Cloud Challenges, David Fick, Oracle