OpenStack Telco Cloud Challenges, David Fick, Oracle
•Download as PPTX, PDF•
2 likes•1,845 views
This document discusses challenges in moving telecom applications to the cloud and how OpenStack capabilities can help address them. It describes telecom applications as traditionally being "pet" applications that require dedicated hardware and high availability. For the cloud, these applications would need to be more like "cattle" with specific SLAs. The document outlines OpenStack capabilities around basic features, management and orchestration, performance, availability and reliability, and operations that could fulfill requirements to support telecom applications in the cloud.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to OpenStack Telco Cloud Challenges, David Fick, Oracle
Similar to OpenStack Telco Cloud Challenges, David Fick, Oracle (20)
More from Sriram Subramanian
More from Sriram Subramanian (10)
Recently uploaded
Recently uploaded (20)
OpenStack Telco Cloud Challenges, David Fick, Oracle
- 1. Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | OpenStack – Telco Cloud Challenges David Fick, Senior Software Architect Oracle 20 Aug 2015
- 2. Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | Telecom Applications Pets or Cattle? 2 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 health 1 Adapted from CERN presentations Credit: www.nmscommunications.com Example: IMS OR
- 3. Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 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 3
- 4. Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 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 4
- 5. Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | Telco Cloud NFV Architectural Framework 5 • Key NFV architectural elements for this discussion: • NFV Infrastructure (NFVI) • Virtualized Infrastructure Managers, e.g. OpenStack • Management and Orchestration “stack” • VNFs, i.e. applications
- 6. Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 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 6
- 7. Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 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 7
- 8. Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 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! 8
- 9. Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 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 9
- 10. Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | 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 10
- 11. Copyright © 2015 Oracle and/or its affiliates. All rights reserved. | Oracle 11
Editor's Notes
- After Stu’s presentation on the business level opportunities, challenges and use cases, I’ll be focusing on a more detailed view of the challenges and use cases related to fulfilling the NFV vision using open source components, in particular OpenStack Brief introduction of self (if not done at the start of the presentation)
- Everyone is familiar with the “pets vs cattle” question whether it is applied to servers, VMs, or applications? So what if we ask that question for telecom applications? If you look up the definition of a pet application in the dictionary, what do you see? A picture of a traditional telecommunications application! This answer assumes a binary choice of which type of application a given application is when it really is a spectrum from one extreme to the other
- Industry in transition, transitioning telco apps from very specialized pets to at least cloud deployable pets if not eventually cattle Greenfield telco cloud apps may be much closer to IT style cloud apps but during the transition existing telecom applications that are migrated will still need to be supported So what is it going to take to transition telecom applications from being pets to cattle or at least closer to cattle on that spectrum? Part of that transition will entail changes to the applications themselves But the non-functional characteristics (performance, availability, etc.) of these applications is not going to change with the transition to running them in a cloud environment Here are the major areas where OpenStack as a VIM in the NFV architecture needs to change: Note this is a sampling of some of the significant capabilities of OpenStack required to support NFV, it is far from an exhaustive list but should provide a view of the inherent challenges in implementing a full NFV solution Also note that this list can be viewed primarily as gaps there are some of the required capabilities are already supported by OpenStack
- Before we talk about some of the challenges of moving telecom applications to the cloud and what that means to OpenStack, let’s take a very quick look at the NFV reference architecture Who here fully understands the NFV architecture shown here? Everybody knows the difference between a PNF and a VNF, right? A lot going on in this figure but as we talk about the telecom challenges and use cases in using OpenStack to realize the NFV reference architecture there are 4 key elements (and we’ll ignore the rest): NFV infrastructure (NFVI) Physical and virtual compute, storage, and network resources Virtualized Infrastructure Managers, e.g. OpenStack The “MANO stack” The VNFs I won’t talk about the details of all the interfaces but we will indirectly talk about some of the requirements associated with the displayed interfaces
- This is a bit of a catchall slide that captures a set of functional capabilities that are required to support a telco cloud but do not fall into one of the other categories
- Latency: Have to be able to be able to guarantee worst case network latency Overriding goal is ensuring SLAs for all cloud resources used by VNFs including compute, networking, and storage
- I say enable since the only availability numbers that matter ultimately are the application’s Note that in the telco world when talking about availability numbers, we are talking about service availability, i.e. the application is available and able to process service requests
- This is more from the cloud operator’s perspective and certainly applies to more than just telecom applications
- Summary: