ENSURING CARRIER GRADE SERVICE LEVELS IN THE NEW VIRTUALIZED WORLD

Transcription

1 ENSURING CARRIER GRADE SERVICE LEVELS IN THE NEW VIRTUALIZED WORLD

2 White Paper 2 Ensuring Carrier Grade Service Levels in the New Virtualized World The telephone network has always been fault-tolerant and highly reliable. You could always count on being able to make a call and not get dropped while you re connected. But with the advent of cellular and VoIP, some in the industry became a bit complacent because it sort of became acceptable to drop a voice call and then redial. While this may be okay for some voice calls, it is not okay for critical functions such as video surveillance, firewalls, denial of service (DDoS) mitigation solutions and network controllers. Since the goal of Network Functions Virtualization (NFV) is to virtualize every network function such as firewalls, DDoS mitigation solutions and network controllers, one would argue that today, Communications Service Providers (CSPs) need fault tolerance and highly reliable networks more than ever. Because the reputation of a CSP rests not only on its ability to reliably connect voice calls, but also to connect and transfer data and video with guaranteed SLAs. If the network goes down, even just for a few seconds, millions of people can be affected. System failure not only results in potential loss of revenue for the operator, it can seriously damage its reputation and, in some cases, lives could be at stake. For example, if a call to the emergency services doesn t go through, the caller may not have a second chance, or if your firewall is down for a few seconds, that may be all it takes for an intruder to enter your private network and access confidential data. For CSPs, the question is not whether network components will fail (they will), it s what happens in the event of a failure. Can the network tolerate a fault and continue to deliver service as if nothing happened? Or will a network or an application fault result in loss of service for a few seconds (or longer) while the failed service is restarted? In other words, will service accessibility and service continuity be interrupted? Carrier grade service levels are achieved by ensuring that both service accessibility and service continuity (or retainability) are maintained: Service accessibility is the ability to respond to new service requests, such as initiating a phone call or establishing a TCP session for a stateful firewall session. Service continuity (or retainability) is the ability to maintain service without interruption, such as continuing an established phone call or continuing an established stateful firewall session. Continuous service accessibility and service continuity can only be achieved in a highly resilient environment. While sometimes used interchangeably, there is a difference between services that are highly available and those that are highly resilient and reliable. Availability is the percentage of time an application (or a network) is in an operable state i.e., can access information or resources. It is calculated as % Availability = Uptime/Total time. A service is considered highly available (or exhibits high availability attributes) if its availability is at least %. Resiliency is the ability to manage and recover quickly from faults/failures and to return to its original form, state, etc. (just before the failure). It provides complete fault management that includes the ability to detect, isolate, localize, recover and repair system faults. It may also include the ability to protect state for those applications that need service continuity. Reliability is how long a system performs as intended before it fails. It is typically measured in mean time between failures (MTBF). MTBF = Total Time in Service/Number of Failures. A highly resilient system that is able to manage and recover from faults will generally be more reliable. Therefore, a highly available (HA) system may not be highly reliable (HRel) or highly resilient (HRes). For example, five nines (99.999%) availability means the application (or network) is never inaccessible for more than 5 minutes in a one year period, which is very good. But what happens if it fails every week for just a few seconds causing every session to be initialized in the process? You now have a highly available system that is not reliable and not resilient. In a non-resilient environment, if an application fails, it means the application has to restart the sequence of interactions with the user, which is not acceptable for mission-critical stateful telecom systems, such as home subscriber service applications (that keep track of mobile users locations) or a firewall control function that correlates data and protects a network. In this situation, you may have an HA system that is not resilient.

3 White Paper 3 In a HRes environment, the system is always monitoring and managing faults and protecting state as necessary so that applications will continue to run without disruption. This means downtime is prevented from happening in the first place. The best of all worlds is fault tolerance, which is the combination of HA, HRel and HRes. Fault-tolerant systems do more than simply recover quickly following an outage they work through faults and continue to run, no matter what occurs, preventing downtime from happening in the first place. This means an application will never fail not even for a few seconds because there is always a secondary application somewhere in the network. And if state replication is selected, it means the secondary will have the same state, the same data, the same everything as the primary. If the primary were to go down, the secondary would automatically take over without missing a beat and there would be no loss of state or data. Therefore Fault Tolerance = HA + Resiliency + High Reliability. See figure 1. Traditionally, fault tolerance was achieved through hardware duplication i.e., a 1+1 hardware approach. This method is effective in that it is quite resilient and requires no code changes which means it s simple and fast. However, it is extremely rigid, more expensive, requires special hardware (rather than commodity servers) and is not efficient. For example, today, most CSPs networks use this approach, which means they are very resilient but also very rigid and fairly underutilized only boasting 47% efficiency. The reason for the inefficiency is that all the hardware is 1+1 redundant. The second approach is to implement failover within an application, so that every application takes care of a partner application. The problem with this approach is that it is very inefficient, time consuming, complex and expensive because it requires extra coding, testing and support. Many application vendors have told us that in some cases adding more high availability code has increased the lines of code by 40%. On top of this, there s the added complexity, additional time needed and the potential impact on the reliability of their code. The third option is to deploy fault tolerance in the software infrastructure. This approach uses two industry-standard x86 servers that are linked via a virtualization platform that pairs protected virtual machines together to create a single operating environment. If one physical machine should fail, the application will continue to run on the other. Processing is automatically switched over, with no interruptions or data loss. Figure 1: Fault Tolerance = HA + HRel + HRes Transparent Fault Tolerance and Service Continuity Versus Application Aware There are three primary approaches to implementing fault tolerance: A hardware approach An application approach A software infrastructure approach Figure 2: The advantages of software infrastructure availability Until recently transparent fault tolerance in a virtualized environment hasn t been possible. But, the latest innovation from Stratus allows CSPs to unlock the power of both NFV and SDN, while maintaining carrier grade reliability.

4 White Paper 4 The Stages of NFV and the Need for High Availability It is widely accepted that the road to NFV may evolve in stages. Typically there are four stages in the transformation of a physical network function (PNF) to a virtual network function (VNF): software abstraction, virtualization, cloudification and de-componentization. 1. Software abstraction is when a network function is extracted from proprietary hardware and made to run on standard x86 servers to deliver more flexibility and reduce costs. 2. Virtualization is when a hypervisor is used to achieve better utilization of resources so that higher densities of VMs to physical servers can be dynamically achieved when needed and released when no longer needed in order to reduce waste/cost of resources and respond more rapidly to customer demand variations. 3. Cloudification is the process of automating resource virtualization, increasing elasticity and the speed of scaling up and scaling down resources to increase efficiency and utilization. This increases an organization s ability to quickly respond to shifting traffic patterns and customer demand for more resources. 4. De-componentization is the process of separating a big monolithic network function into smaller sub-functions (and building blocks) that can be selectively managed and be integrated into resource pools when needed so that more capacity, better latency and newer innovative services can be created. De-componentization also provides flexibility in the management of control planes and forwarding planes. For example, because state protection requirements vary by functional element, a software defined availability (SDA) approach can be applied to treat control plane processes differently from forwarding plane processes that are more latency sensitive and require accelerated packet processing through the fast path. Today new VNFs being developed are generally built in a cloud environment and use as many OpenStack sub-functions as possible. However, as existing PNFs are converted to VNFs, some vendors may adopt these stages of transformation i.e., for some applications, they may virtualize first and migrate to a cloud environment at a later stage. The Right Solution for Your Stage of Adoption Regardless of which stage of NFV transformation you are in, the need for high availability and resiliency is always there. Typical hypervisors like KVM do not support high availability or fault tolerance. While OpenStack supports basic levels of availability, it does not support service continuity and stateful fault tolerance. In both the hypervisor (KVM) and the cloud (OpenStack) it has been left to the applications to handle faults and perform the failover function. This has made full-blown NFV a risky proposition for telcos because application-level failover means every application has to be modified. This is just too complicated and time consuming and for many applications, not even possible. Whether an application is deployed in a cloud environment or just virtualized, Stratus software-based fault-tolerant solutions enable applications to achieve high performance, keep running and keep state in the event of a system fault or failure by remembering the preceding events in a given sequence of interactions with a user. everrun software is applicable for a virtualized infrastructure that is not yet cloudy. This product provides seamless fault tolerance with state protection for all KVM-based applications. Seamless means the applications do not need to be modified to become fault-tolerant. This product has been widely field-tested and proven with many communications applications and has over 12,000 licenses deployed. Stratus Cloud Solutions are designed for an OpenStack environment and leverage the same proven technology that can be found in everrun. Beyond seamless fault tolerance with geo-redundancy state protection, the solutions also support multiple levels of resiliency so that control elements and forwarding elements, for example, may have different levels of redundancy and state protection. They also provide resiliency management for a cloud environment including APIs with other orchestrators and an interface to HEAT. Either product may be ideal for your applications that need high availability depending on where you are in your path towards NFV. Essentially any application that uses KVM or KVM/ OpenStack can run on the Stratus software-based fault-tolerant platform (without code change) and will instantaneously become highly available or stateful fault-tolerant. This means application developers don t need to worry about the complexities and time consuming efforts required to make each application highly available.

5 White Paper 5 The rest of this document focuses on the Stratus Cloud Solutions. For deployments using KVM that haven t yet migrated to OpenStack, everrun may be a better fit and is covered in a different paper. Please contact your Stratus representative or ali.kafel@stratus.com for more information. Stratus Cloud Solutions For both native cloud and legacy applications, the abstraction of availability from the hardware or application layer enables a CSP or an enterprise to change the level of availability based on application requirements at any given time. Organizations can switch applications between fault-tolerant, high availability and general availability modes without the need to make changes to application code. This intelligent, dynamic approach to availability significantly reduces cost, complexity and risk, without compromising reliability. The private and hybrid OpenStack-based Stratus Cloud Solutions provide software defined, fully automated, selectable levels of resiliency to cloud workloads. This includes fully stateful fault tolerance, with geo-redundancy to provide transparent service continuity. Unlike traditional approaches to fault tolerance, which require duplicate or triplicate resources, limit utilization to 50% to 30% and result in high costs, the Stratus SDA approach uses virtualized resiliency based on unique StatePoint technology. This is an n+k de-clustered redundancy approach which enables dramatic increases in efficiency of redundancy, allowing utilization levels of 80% to 90%, while providing uncompromised reliability, at a fraction of the resource cost. Software Defined Availability (SDA) Through SDA, the latest generation of availability, Stratus moves fault management and automatic failover from the hardware and applications to an automated virtualized resiliencey layer in the software infrastructure that provides: 1. Fully automated fault management, with selectable levels of resiliency 2. Seamless protection without code change 3. Higher efficiency of redundancy Fully Automated Fault Management, with Selectable Levels of Resiliency SDA provides complete and automatic fault management for every application this can include state protection through Stratus VM StatePoint processing, fault detection, localization, isolation, recovery (failover) and repair (redundancy restoration). Figure 3: Fault management cycle for every application However, not all applications need to have the same level of resiliency. In the case of stateless applications, where each transaction is independent of previous transactions, there is no need to protect state information. In this case, if the server goes down, it is sufficient to immediately restore the functionality (and the configuration) at the same or a different site (VM or hardware). If the application is restarted on another server, traffic will automatically be redirected without the loss of service accessibility and service continuity. In this stateless case, such applications will be deployed as high availability (HA) and all the other fault management functions will be provided except the checkpointing function. Examples of stateless VNFs include DNS. Stateful service continuity typically applies to continuous services where transactions may be dependent on or correlated to previous transactions. In this case, it is not sufficient to restore only functionality and configuration, the latest session states need to be restored as well. In this stateful case, such applications will be deployed as fault-tolerant (FT) which is essentially HA redundancy and state preservation.

6 White Paper 6 Examples of stateful applications include mobile management entity (MME), home subscriber server (HSS) and firewalls. However, for applications such as firewalls or virtual routers, only the control elements may need to be stateful while the forwarding elements may be stateless, leveraging DPDK and SR-IOV for higher performance and lower latency processing. In this scenario, the Stratus platform can be instructed to deploy the control function as FT, while the forwarding functions will be deployed as HA. In fact some applications such as web servers may not need any additional redundancy and can be deployed as general availability (GA). The salient characteristics of the availability modes in terms of the key fault management cycle phases are as follows: FT mode: Redundant VM instances, full-vm state checkpointing, NFVI fault detection, fault recovery with fully stateful VM failover to redundant entity. Repair (redundancy restoration) through re-instantiation of redundant instance and warm-up (state replication), followed by a move of the new redundant instance to standby state. HA mode: No VM instance redundancy, no infrastructure provided VM state checkpointing, NFVI fault detection, fault recovery with re-instantiation. Repair is not applicable. GA mode: No VM instance redundancy, no infrastructure provided VM state checkpointing, NFVI fault detection, fault recovery through clean up only (i.e. no automatic recovery), will require external intervention. This flexibility to specify different levels of redundancy enables CSPs to take any commercial off-the-shelf (COTS) virtualized and cloud applications and instantaneously make them HA or FT, without the complexity and time consuming efforts required to modify and test every application. Figure 4: Selectable levels of resiliency Seamless Protection Without Code Change Stratus Availability Services move the downtime prevention and recovery decisions outside the application layer into the underlying operating layer. Unlike traditional hardware-based availability solutions, availability is not dependent on a specific set of hardened servers it is effectively abstracted from the application and from the hardware. The key to all successful cloud architectures lies in the abstraction of services at different layers in the architecture. Unlike application-based HA solutions which require application code changes, this solution automatically creates VM pairs between hosts in an anti-affinity configuration. This means that the state of a VM (and all its applications) are captured regularly and asynchronously, based on a highly sophisticated Stratus StatePoint algorithm that ensures globally consistent state for all applications deployed in a stateful FT mode. If a fault occurs on the primary server at state n, the system automatically switches over to the secondary server which resumes automatically from the most recent statepoint, n, without data loss and without any code changes or impact to the application (see figure 5).

7 White Paper 7 thousands of deployments, the average total added latency for the whole process including checkpointing with the I/O barrier is less than 1ms (about 750 micro seconds). Obviously for applications that don t need state redundancy, the added latency is much less. Figure 5: Seamless protection with no application impact At this point, most fault management functions have been performed including state checkpointing, fault detection, localization, isolation, and recovery (failover). Once the hotstandby VM host has taken over at the same state left off by the active VM and without any data loss, the final step is to repair the situation (redundancy restoration). As figure 5 shows, when the hotstandby node takes over and becomes the new active node, a third host will be created to become the new hotstandby host so that the system is never left without redundancy. Globally consistent state is guaranteed for every application that needs state protection based on a Stratus StatePoint technology which performs a pause, capture and resume (PCR) mechanism. When the state of an active VM changes, the egress packets for the applications in that VM are temporarily held in the I/O queue due to the insertion of an I/O barrier (see step 1 in the figure 6). The packets will stay held (see step 2) until the state update for that statepoint, n, is sent to the hotstandby VM and acknowledgement received back (see step 3) before the I/O barrier is removed (see step 4). In other words, the IO barrier (at the active server) prevents all external communications from the application execution prior to state replication. Once the acknowledgement is received and the I/O barrier is removed for state n, the egress packets (for state n) are transmitted (see step 5) to the remote end. If a failure happens at the active VM before the acknowledgement for state n is received from the hotstandby VM, then the packets are thrown away by the active VM and the hotstandby VM will resume processing by repeating the last n state that the active VM had done. This ensures that egress packets are never duplicated and globally consistent state is guaranteed. A question that may come up may be: How much latency is added during this whole process? Based on data from Figure 6: Guaranteeing globally consistent state

8 White Paper 8 Higher Efficiency of Redundancy Unlike the traditional 1+1 approach for redundancy, which takes twice the amount of resources and runs at sub 50% utilization and efficiency, the Stratus SDA approach can use an n+k de-clustered redundancy approach that raises the efficiency of redundancy to levels of 80%+, while providing uncompromised reliability, at a fraction of the cost. Improving utilization and efficiency of redundancy can be achieved using a two dimensional approach: Our asymmetric StateSync and n+k de-clustered redundancy technology ensures globally consistent state between primary and secondary VMs but, instead of using twice the amount for CPU resources for each redundant VM, the secondary only uses 6-12% of the resources used by the primary. The n+k de-clustered redundancy architecture breaks up a workload into smaller primary VMs, with even smaller corresponding secondary VMs on other servers (anti-affinity) as shown in figure 7. This means each primary server VMs (with their applications) are backed up on separate secondary servers. However, instead of an active-active scenario, we deploy an active-hotstandby model, where the secondary shadow VMs are standing by to get state update (if state protection FT is requested) information rather than doing the same amount of work as the VMs on the primary. Also as figure 7 shows, each physical server will run a combination of primary VMs (whose secondary VMs are backed up on separate servers) and also smaller secondary VMs whose primary VMs are doing the complete workload in other physical servers. Stand-up reserve capacity to stand-up the secondary VMs when they become the active VMs is also allocated, to ensure the failover will happen automatically without a problem. The second dimension to increase efficiency of redundancy is to support the de-composed model of control planes versus the forwarding planes. Because state protection requirements vary by functional elements, the Stratus SDA architecture is capable of treating control plane processes differently from forwarding plane processes. Control elements are typically stateful processes that require complex processing and have less critical latency requirement (within milliseconds). Whereas forwarding elements are generally stateless and have very strict latency requirements (within micro seconds). Stratus SDA enables control plane packets to go through the mechanism of PCR in order to provide state protection. However, for forwarding elements where SR-IOV and/or DPDK are used for accelerated packet processing, these packets do not go through the PCR mechanism and go directly through the fast path as shown in figure 8. This sophisticated level of resiliency automation is what enables the Stratus solution to dramatically increase utilization, and raise the efficiency of redundancy from traditional telecom levels of 45% to levels of 80%+, while providing uncompromised reliability, at a fraction of the cost. Figure 7: n+k de-clustered redundancy with asymmetric StateSync

9 White Paper 9 Figure 8: State protection requirements vary by functional element Figure 9: The Stratus software-based fault-tolerant cloud solution The Stratus Cloud Solutions consist of two products; Availability Services and Workload Services. See figure 9. Availability Services enable you to achieve stateful continuous availability for mission critical workloads, as well as other availability level options for less critical workloads. It leverages the KVM hypervisor with added extensions for transparent availability services. Workload Services enables fast, easy and efficient deployments and management for all workload types in OpenStack based clouds. It provides intelligent dynamic resilience management that leverages Heat and other standard OpenStack services to provide faster deployment and management of all virtualized and cloud applications, with selectable levels of resiliency and availability for each application. It also interfaces to other MANO functions, such as orchestrators and OSS systems through an API. Key features of both services are summarized below: Key Features: Availability Services Achieve SLAs with no downtime, data loss or business interruptions with stateful service accessibility and service continuity, without code changes Optimize flexibility and ROI with one solution for all applications with multiple availability levels Increase efficiencies with higher resource utilization using n+k de-clustered redundancy Workload Services Reduce complexity, cost and human errors with Resource Tagging and interface to other MANO functions and OSS systems through an open API Speed up deployments from days to minutes with the Service Catalog

10 White Paper 10 Conclusions In summary, Stratus Cloud Solutions, integrated with OpenStack, are aimed to be to CSPs what VMware has been to enterprises. It unlocks the same value, but with seven 9 s ( %) stateful carrier class reliability, higher network efficiencies and better economic value. Enabling the cloudification of the communications network infrastructure, the Stratus Cloud Solutions pave the way for the widespread deployment of the new converged IP network that includes NFV, SDN, IMS, LTE and WiFi. Beyond network functions, the Stratus solution provides a platform for CSPs to open up valuable new revenue streams by offering competitive cloud propositions such as IaaS and big data analytics. In summary it provides the following benefits: Reduces the time and complexity associated with deploying highly resilient NFV and other cloud applications: Any virtualized and cloud application can be deployed with transparent and instantaneous service continuity without code changes Developers can implement HA without the need for additional application code (40% to 50%) CSPs have a broader range of deployable VNFs and other Cloud applications with automatic HA Minimizes CAPEX and OPEX: Resource utilization increases from sub 50% in traditional fault-tolerant architectures to more than 80% with intelligent software-based fault tolerance, at a fraction of the resource cost Uses COTS hardware and open source software (KVM and OpenStack) available on multiple distros Offers full OpenStack support with interfaces to other orchestrators for automated deployment and management that reduces human errors and complexity Optimizes flexibility and ROI with one cloud solution: Supports multiple availability modes (FT, HA and GA) with complete fault management (fault detection, localization, isolation, repair, recovery, and state protection) for all applications Enables different customers to deploy the same applications in a variety of availability modes, depending on SLA needs Supports enterprise applications in the same solution for IaaS as well as internal applications Stratus Track Record in Telecoms Stratus has a long and successful history of working with CSPs. In the early 1990s, Stratus provided hardware fault-tolerant computing platforms, as well as SS7-based network software, to some of the largest CSPs in the world. Stratus provided technologies and products used for network management and intelligent call control, including home location registers (HLR), number portability, softswitches and session border controllers (SBCs). About seven years ago, Stratus created the industry s first software-based fault-tolerant infrastructure software that runs on standard Intel x86 COTS servers. This product, everrun, provides seamless fault tolerance with state protection for all KVM-based application. Seamless means the applications do not need to be modified to become fault-tolerant. It has been widely field-tested and deployed with many communications applications, with over 12,000 licenses deployed. Today, Stratus is leveraging more than 30 years of experience of enabling %+ computing reliability, together with its telecom software experience, to create a stateful software-based fault tolerant virtualization and cloud environment (based on OpenStack and KVM), that runs on standard Intel x86 COTS servers. This environment brings application transparent carrier-class reliability to NFV, SDN, IMS and enterprise applications, making them statefully fault-tolerant and geo-redundant. The Stratus software infrastructure solution enables CSPs to deploy a fully virtualized NFV Infrastructure that provides a multi-application, multi-vendor, multi-platform, liquid resource pooling platform, with software defined availability. Beyond network functions, the Stratus solution provides a platform for CSPs to offer competitive cloud propositions, including IaaS and big data analytics, potentially opening up valuable new revenue streams with compelling economic value. Specifications and descriptions are summary in nature and subject to change without notice. Stratus and the Stratus Technologies logo are trademarks or registered trademarks of Stratus Technologies Bermuda Ltd. All other marks are the property of their respective owners Stratus Technologies Bermuda Ltd. All rights reserved