Auto-scaling software-defined monitoring platform for software-defined networking service assurance

Concepts and technologies disclosed herein are directed to an auto-scaling software-defined monitoring (“SDM”) platform for software-defined networking (“SDN”) service assurance. According to one aspect of the concepts and technologies disclosed herein, an SDM controller can monitor event data associated with a network event that occurred within a virtualized IP SDN network that is monitored by a virtualized SDM resources platform. The SDM controller can measure, based upon the event data, a quality of service (“QoS”) performance metric associated with the virtualized SDM resource platform. The SDN controller can determine, based upon the QoS performance metric, whether an auto-scaling operation is to be performed. The auto-scaling operation can include reconfiguring the virtualized SDM resources platform by adding virtual machine capacity for supporting event management tasks either by instantiating a new virtual machine or by migrating an existing virtual machine to a new hardware host.

BACKGROUND

Cloud-based software-defined networking (“SDN”) services are being pursued by major telecommunications carriers around the world. Cloud-based SDN services allow customers to create and activate new services and to update existing services on-demand and in near real-time. SDN provides “network-on-demand” services that allow network infrastructure to adapt to user demand. Cloud SDN service assurance is realized through an automated service closed control loop. Successful operation of the automated service closed loop for SDN service assurance requires the successful execution of event monitoring and analytics in near real-time.

SDN “network-on-demand” services create management traffic storm impacts on network event monitoring systems due to real-time, dynamic changes and rapid, on-demand growth of SDN systems. These dynamic, unpredictable, and continuous SDN management traffic patterns make traditional, static event monitoring systems obsolete.

SUMMARY

The concepts and technologies disclosed herein are directed to an auto-scaling software-defined monitoring (“SDM”) platform for SDN service assurance. According to one aspect of the concepts and technologies disclosed herein, an SDM controller can monitor event data associated with a network event that occurred within a virtualized IP SDN network that is monitored by a virtualized SDM resources platform. The SDM controller can measure, based upon the event data, a quality of service (“QoS”) performance metric associated with the virtualized SDM resource platform. The SDN controller can determine, based upon the QoS performance metric, whether an auto-scaling operation is to be performed.

In some embodiments, the QoS performance metric includes a network event processing throughput. The QoS performance metric can alternatively or additionally include other metrics, such as, for example, response time

In some embodiments, the SDM controller can determine whether the auto-scaling operation is to be performed at least in part by determining whether the virtualized SDM resources platform has been degraded. In some embodiments, degradation of the virtualized SDM resources platform is determined based upon whether the event processing throughput has fallen below a threshold value.

In some embodiments, the auto-scaling operation can include reconfiguring the virtualized SDM resources platform by adding virtual machine capacity for supporting event management tasks. In some embodiments, virtual machine capacity can be added by instantiating one or more new virtual machines for supporting event management tasks. The SDM controller can generate an alert directed to an SDN controller to notify the SDN controller of the new virtual machine(s) to be instantiated. In some other embodiments, virtual machine capacity can be added by migrating a virtual machine to a new hardware host.

DETAILED DESCRIPTION

The concepts and technologies disclosed herein are directed to an auto-scaling SDM platform for SDN service assurance. SDN “network-on-demand” services generate management traffic storms due to the real-time dynamic changes, and the rapid, on-demand, growth of SDN services. Dynamic, unpredictable, and continuous SDN network management traffic patterns cannot be successfully monitored by the traditional static network event monitoring systems available today. Thus, a dynamic auto-scaling network event monitoring system that allows monitoring resources to adapt to the monitoring requirements of SDN “network-on-demand” services is needed.

Network event monitoring system virtualization is a solution, whereby one or more virtual machines (“VMs”) can be instantiated, stopped, and migrated in near real-time to meet monitoring demand. The concepts and technologies disclosed herein provide, among other capabilities, auto-scaling event monitoring capabilities to ensure that an acceptable level of network event processing throughput is available under capacity reduction events caused by the rapid growth and dynamic changes of SDN “network-on-demand” services.

An analytics-enabled auto-scaling SDM platform architecture disclosed herein provides “monitoring-on-demand” to adapt network monitoring capacity to the dynamic, unpredictable, and fast growth traffic patterns generated by SDN “network-on-demand” services with assurance of an acceptable network event processing throughput. An SDM controller provides event-oriented Quality of Service (“QoS”) monitoring, measurements, analytics, and resource auto-scaling on a virtualized SDM platform. Algorithms are provided to perform event-oriented QoS measurement, analytics, and resource auto-scaling on the virtualized SDM platform to ensure an acceptable level of network event processing throughput by the virtualized SDM platform.

Network event monitoring and analytics components are an integral part of the automated service closed loop control in cloud SDN “network-on-demand” networks to ensure successful customer service delivery. However, current efforts on service control loop automation are on policy engine, cloud orchestrator, and SDN controller. An adaptive and auto-scaling monitoring system that can adapt the monitoring infrastructure to support SDN “network-on-demand” service requirements is the missing link in the exiting service control loop. The concepts and technologies disclosed herein close the gap of automation needed in the service closed control loop for SDN service assurance. Thus, any telecommunications carriers and solution/equipment vendors targeted for this cloud SDN market will need such auto-scaling monitoring-on-demand system to meet automated service assurance commitment using cloud SDN infrastructure.

Referring now toFIG. 1, a block diagram illustrating an operating environment100in which aspects of the concepts and technologies disclosed herein can be implemented will be described. The operating environment100illustrates an SDM platform102and an SDN platform104. The SDM platform102monitors operations of the SDN platform104as will be described in greater detail herein.

The SDN platform104can create and manage intelligent networks that are programmable, application-aware, and more open than traditional networks. In the illustrated embodiment, the SDN platform104creates and manages one or more virtualized Internet protocol (“IP”) SDN networks106. The SDN platform104provides an agile and cost-effective communications platform for handling the dramatic increase in data traffic on networks by providing a high degree of scalability, security, and flexibility. The SDN platform104provides several benefits. The SDN platform104allows for the creation of multiple virtual network control planes on common hardware. The SDN platform104can help extend service virtualization and software control into many existing network elements. The SDN platform104enables applications to request and manipulate services provided, at least in part, by the virtualized IP SDN network(s)106, and to allow the virtualized IP SDN network(s)106to expose network states back to applications. The SDN platform104can expose network capabilities through one or more application programming interfaces (“APIs”) (not shown), making the control of network equipment remotely accessible and modifiable via third-party software clients using open protocols such as OPENFLOW, available from Open Networking Foundation (“ONF”).

The SDM platform102provides a capability to monitor, on-demand, traffic108associated with one or more network events109that occur during operation of the virtualized IP SDN network(s)106. The SDM platform102can adapt its monitoring capabilities to the dynamic, unpredictable, and fast growth of the traffic108to ensure an acceptable level of throughput for processing network events (referred to herein as “network event processing throughput”) is maintained, subject to available hardware host resources. As used herein, “network event processing throughput” is the number of network events per second processed by the SDM platform102. The SDM platform102is a shared distributed infrastructure to support SDN event life-cycle management, including event detection, event filtering, event categorization, event response, and event closure.

As used herein, a “network event,” such as one of the network events109, is a network occurrence that is of significance to one or more network operations performed by one or more of the virtualized IP SDN networks106. By way of example, and not limitation, the network events109can include capacity utilization (e.g., VM, processor, memory, storage, and/or network I/O) exceeding a designed threshold, failure of network I/O (i.e., communications failure) at devices, or a network topology update. What constitutes a “network event” can be defined by a telecommunications carrier, and accordingly, likely will vary from carrier to carrier.

A network event can trigger one or more alarms (e.g., faults) and/or one or more notifications (e.g., operations state change) by managed monitor devices to a network management system. Alarms and/or notifications can be triggered, for example, if a severity value is “major,” “critical,” or otherwise set so as to trigger an alarm and/or notification. In some embodiments, one or more event collectors (not shown) can receive the network events109via one or more simple network management protocol (“SNMP”) traps from one or more network devices operating on or in communication with one or more of the virtualized IP SDN network(s)106. The SDM platform102, which can include the event collectors and processors, can then associate a severity value to each of the network events109. The severity values can be established, for example, by a telecommunications carrier that utilizes the SDM platform102for monitoring operations of the virtualized IP SDN network(s)106. The severity values can include a numerical ranking, an alphabetic ranking, an alphanumeric ranking, or some other ranking, such as, for example, informational, warning, major, and critical. Intermediate severity values are also contemplated. Those skilled in the art will appreciate other severity ranking schemes to rank the significance of a network event on operations of the virtualized IP SDN network(s)106.

The SDM platform102and the SDN platform104operate in a closed control loop for service assurance110designed to assure performance of SDN “network-on-demand” services. The illustrated closed control loop for service assurance110can operate, at least in part, in one or more data centers111. The data center(s)111can include a plurality of hardware resources upon which a plurality of VMs and virtualized networking functions (“VNFs”) can be instantiated. VMs and VNFs can be instantiated by the SDN platform104to provide the virtualized IP SDN networks106. VMs and VNFs can be instantiated by the SDM platform102to provide the monitoring capabilities described herein.

The entities involved in the illustrated closed control loop for service assurance110include an SDM controller112, a virtualized SDM resources platform114, a policy engine116, a cloud service/resource orchestrator118, and an SDN controller120. In the illustrated example, the SDM controller112and the SDN controller120are shown as being in communication with the virtualized IP SDN network(s)106. It should be understood, however, that other configurations are contemplated in which any of the aforementioned entities can be configured to be in communication with the virtualized IP SDN network(s)106. The virtualized IP SDN network(s)106provides one or more user devices122with wireless and/or wired connectivity to the data center111so that the user device(s)122can access one or more IP services.

The SDM platform102provides a virtual resource auto-scaling event management service to assure an acceptable level of network event processing throughput under capacity reduction events due to the rapid growth and dynamic changes of SDN services provided by the SDN platform104. The network event processing throughput is the number of events per second processed by the SDM platform102. The SDM platform102is a shared distributed infrastructure to support SDN event life-cycle management, including event detection, event filtering, event categorization, event response, and event closure. The SDM platform102can determine: (1) what performance metrics are to be collected and measured; (2) when to trigger VM auto-scaling operations; (3) how and where to perform VM auto-scaling operations for achieving one or more design goals; and (4) where and what details are to be disseminated via one or more output reports.

The SDM controller112is an engine that utilizes a control decision model to determine when, how, and where to trigger and perform VM auto-scaling operations on the virtualized SDM resources platform114to meet one or more design goals. The SDM controller112can expose one or more APIs (not shown) to facilitate integration between the virtualized SDM resources platform114and the SDM controller112. The SDM controller112can send one or more alerts to the SDN controller120when an anomaly of IP network traffic patterns and/or behavior is detected.

The virtualized SDM resources platform114is a distributed event monitoring virtualization platform to collect and store metrics of interest. The virtualized SDM resources platform114can perform event life-cycle management, including event detection, event filtering, event categorization, event response, and event closure. The virtualized SDM resources platform114can output reports to the policy engine116to update capacity management policies for additional host resource allocation needed at the cluster level. A cluster is a group of hardware host resources that are allowed to be shared by VMs running on these hardware hosts. Host resources can include CPU, RAM, storage, and network I/O.

The policy engine116can establish and update policies for capacity management. Policies are utilized to instruct the cloud service/resource orchestrator118to allocate or reallocate cloud resources to meet service requirements. The cloud service/resource orchestrator118can orchestrate cloud resource allocation between service requirements and network resource requirements managed by the SDN Controller120. The SDN controller120can instruct SDN network nodes to program node hardware for hardware resource allocation/reallocation in the virtualized IP SDN network(s)106.

According to various embodiments, the functionality of the user device(s)122may be provided by one or more server computers, desktop computers, mobile devices, laptop computers, tablet computers, set-top boxes, other computing systems, and the like. It should be understood that the functionality of the user device(s)122can be provided by a single device, by two similar devices, and/or by two or more dissimilar devices. For purposes of describing the concepts and technologies disclosed herein, the user device(s)122are described herein as mobile devices such as smartphones. It should be understood that this embodiment is illustrative, and should not be construed as being limiting in any way.

Turning now toFIG. 2, a block diagram illustrating aspects of a simplified SDM auto-scaling platform architecture framework200will be described, according to an illustrative embodiment. The SDM auto-scaling platform architecture framework200includes the SDM controller112, the virtualized SDM resources platform114, the SDN controller120, the policy engine116, and the virtualized IP SDN network106, all introduced inFIG. 1. In the illustrated embodiment, the SDM controller112is separated from the SDN controller120. This design considers a principle of separation of the data and management planes. In an alternative embodiment, the SDM controller112can be integrated with the SDN controller120.

The illustrated SDM controller112includes a management system QoS monitor202, a management system QoS measurer204, a resource auto-scaler206, and an alert reporter208. The management system QoS monitor202, the management system QoS measurer204, the resource auto-scaler206, and the alert reporter208can be software modules executable by one or more processors of the SDM controller112. Alternatively, the management system QoS monitor202, the management system QoS measurer204, the resource auto-scaler206, and the alert reporter208can be implemented via separate hardware systems, each including one or more processors and having corresponding software modules executable by the processor(s).

The management system QoS monitor202can monitor performance metrics such as capacity utilization data (e.g., VM, processor(s), memory, storage, network I/O, and the like), network input/output event counts for each event processor (e.g., each blade), and VM inventory pool. The management system QoS measurer204can measure network event processing throughput per event processor in a given time period via the number of events being successfully processed through network I/O of each event processor in that time period. Management system QoS is an aggregated count of network event processing throughput by each event processor in the virtualized SDM resources platform114. It should be understood that “network event processing throughput” is utilized herein as an illustrative design target to reflect an event packet loss metric. Other QoS performance metrics, such as, but not limited to, response time, can be incorporated as needed.

The resource auto-scaler206can perform auto-scaling operations of resources available from the virtualized SDM resources platform114. The auto-scaling operations can be triggered if the network event processing throughput falls below a designed threshold. The resource auto-scaler206can instruct the virtualized SDM resources platform114to re-configure one or more hardware host resources by adding more VM capacity for event management tasks through either new VM instantiation and/or VM migration if cluster hardware resources are available. If the hardware host capacity in the same cluster is available, VM migration can be performed. A VM migration moves the VM to a new hardware host in the same cluster that has sufficient available capacity to support event management task execution requirements. Otherwise, the resource auto-scaler206can perform load balancing and can instantiate one or more new VMs if a new VM is available for instantiation from an inventory list and if sufficient cluster hardware host capacity is available to assign to support event monitoring tasks. If no sufficient cluster hardware host resources are available to support both VM migration and new VM instantiation, then the alert reporter208can generate an alert210. The alert reporter208can send the alert210to the policy engine116, which, in turn, can update one or more policies212(e.g., a capacity management policy213) to add additional host resources at the cluster level.

The illustrated virtualized SDM resources platform114includes one or more event monitoring VMs (shown as VM-M1214-VM-MN214N; referred to herein collectively as VM-Ms214, or singularly as VM-M214), one or more hypervisors216, and one or more hardware hosts218(e.g., server modules or “blades”). Each of the hardware hosts218can support one of the hypervisors216that, in turn, can manage one or more of the VM-Ms214. The hardware hosts218can provide computing capacity to support the VM-Ms214. The hypervisors216provide resource management among the VM-Ms214supported thereby. Each of the hardware hosts218can include one or more logical server clusters (best shown inFIG. 5). Each server cluster is created for resource allocation and reallocation purposes.

Turning now toFIG. 3, a method300for auto-scaling the SDM platform102will be described, according to an illustrative embodiment. It should be understood that the operations of the methods disclosed herein are not necessarily presented in any particular order and that performance of some or all of the operations in an alternative order(s) is possible and is contemplated. The operations have been presented in the demonstrated order for ease of description and illustration. Operations may be added, omitted, and/or performed simultaneously, without departing from the scope of the concepts and technologies disclosed herein.

Thus, it should be appreciated that the logical operations described herein are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as states, operations, structural devices, acts, or modules. These states, operations, structural devices, acts, and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof. As used herein, the phrase “cause a processor to perform operations” and variants thereof is used to refer to causing a processor or multiple processors of the SDM controller112, the virtualized SDM resources platform114, the policy engine116, the cloud service/resource orchestrator118, the SDN controller120, the user device(s)122, and/or other systems and/or devices disclosed herein to perform one or more operations and/or causing the processor to direct other components of the computing system or device to perform one or more of the operations.

For purposes of illustrating and describing the concepts of the present disclosure, the methods disclosed herein will be described as being performed by components of the SDM controller112via execution of one or more software modules such as, for example, the management system QoS monitor202, the management system QoS measurer204, the resource auto-scaler206, and the alert reporter208. It should be understood that additional and/or alternative devices and/or network nodes can provide the functionality described herein via execution of one or more modules, applications, and/or other software. Thus, the illustrated embodiments are illustrative, and should not be viewed as being limiting in any way.

The method300will be described with reference toFIG. 3and additional reference toFIGS. 1-2. The method300begins at operation302, where the management system QoS monitor202monitors event data from one or more of the virtualized IP SDN networks106. Operation302can be performed by the management system QoS monitor202, which monitors system logs, performance metrics, and network events at the VM and hardware layers. Event data to be monitored can include capacity utilization (VM, CPU, RAM, storage, and/or network I/O), network I/O event counts for each event processor (e.g., blade), and VM inventory pool.

From operation302, the method300proceeds to operation304, where the management system QoS measurer204measures QoS performance based upon the event data. Operation304is performed by the management system QoS measurer204, which measures the event processing throughput at the SDM platform layer. The event processing throughput per event processor can be computed in a given measured time period via the number of events being successfully processed (by event management tasks) through network I/O of each event processor in that measured time period. Management system QoS measurement is an aggregated count of event processing throughput by each event processor in the SDM platform102. Here, event processing throughput is utilized as the design target to reflect event packet loss metric of QoS parameters. Other QoS metrics (such as delay-response time) can be incorporated when needed.

From operation304, the method300proceeds to operation306, where the resource auto-scaler206performs scaling decision analytics. From operation306, the method proceeds to operation308, where the resource auto-scaler206determines, based upon the scaling decision analytics, whether the virtualized SDM resources platform114has been degraded. If the resource auto-scaler206determines, based upon the scaling decision analytics, that the virtualized SDM resources platform114has not been degraded, the method300returns to operation302. If, however, the resource auto-scaler206determines, based upon the scaling decision analytics, that the virtualized resources platform114has been degraded, the method300proceeds to operation310. At operation310, the resource auto-scaler206performs VM-M reconfiguration. From operation310, the method300proceeds to operation312, where the method300ends.

Operations306,308and310are performed by the resource auto-scaler206. Operation306is triggered if the event processing throughput is measured to fall below a designed threshold value. Once the event processing throughput is detected to have fallen below the design threshold value at operation308, operation310is triggered to instruct the SDM controller112to perform VM re-reconfiguration by adding more VM capacity for event management tasks through either new VM spin-up or VM migration if cluster hardware host resources are available. The design threshold values for event processing throughput can be dynamically adjusted using a machine learning model for sub-optimal solutions when appropriate.

Turning now toFIG. 4, a method400for auto-scaling the SDM platform102will be described, according to an illustrative embodiment. The method300will be described with reference toFIG. 3and additional reference toFIGS. 1-2. The method400begins at operation402, where the management system QoS monitor202monitors one or more metrics at the VM and hardware layers of a monitored network, such as the virtualized IP SDN network106. The metrics can include capacity utilization, network I/O event counts, and VM pool inventory. From operation402, the method400proceeds to operation404, where the management system QoS measurer204measures the event processing throughput for each event processor in a given time period via the number of events beings successfully processed through network I/O of each event processor in that time period.

From operation404, the method400proceeds to operation406, where the resource auto-scaler206determines whether the event processing throughput measured at operation404is less than an event processing throughput design threshold. If the resource auto-scaler206determines that the event processing throughput is not less than the event processing throughput design threshold, the method400returns to operation402. If the resource auto-scaler206determines that the event processing throughput is less than the event processing throughput design threshold, the method400proceeds to operation408, where the resource auto-scaler206determines whether the VM-M214utilization is greater than a VM-M214utilization design threshold. If the resource auto-scaler206determines that the VM-M214is greater than the VM-M214utilization design threshold, the method400proceeds to operation410(shown inFIG. 4B).

Turning now toFIG. 4B, and particularly to operation410, the resource auto-scaler206determines whether the host capacity in a given cluster is greater than a minimum host capacity required to support a VM executing event monitoring instructions. If the resource auto-scaler206determines the host capacity is greater than the minimum host capacity, the method400proceeds to operation412, where the resource auto-scaler206assigns a new host found in round-robin to one or more of the existing VM-Ms214(e.g., one of the VM-Ms214). The method400then proceeds to operation414, where the method400ends.

Returning toFIG. 4A, and particularly to operation408, if the resource auto-scaler206determines that the VM-M214utilization is not greater than the VM-M214utilization design threshold, the method400proceeds to operation416(shown inFIG. 4B). Turning again toFIG. 4B, at operation416, the resource auto-scaler206determines whether any VM-M214is available to be instantiated from the VM inventory. Also, if at operation410, the resource auto-scaler206determines that the host capacity is not greater than the minimum host capacity required for VM application (i.e., event processing) execution, the method400proceeds to operation416. If, at operation416, the resource auto-scaler206determines that at least one VM-M214is available to be instantiated from the VM inventory, the method proceeds to operation418.

At operation418, the resource auto-scaler206determines whether the host capacity in a given cluster is greater than a minimum host capacity required to support the application VM available to be instantiated from the VM inventory. If the resource auto-scaler206determines the host capacity is greater than the minimum host capacity required to execute event processing tasks, the method400proceeds to operation420, where the resource auto-scaler206spins up a new VM-M214and assigns a new host found in round-robin. The method400then proceeds to operation414, where the method400ends.

If, however, at operation418, the resource auto-scaler206determines that the host capacity is not greater than the minimum host capacity requested from VM application execution, the method400proceeds to operation422, where the alert reporter208alerts (via the alert210) the policy engine116of the event of insufficient host capacity in the SDM platform102. To avoid the transient effect, at operation422, the number of events reported to the alert reporter208can be computed.

From operation422, the method400proceeds to operation424, where the resource auto-scaler206determines if the number of insufficient host capacity events in a given measured time period is greater than an event design threshold. If the number of insufficient host capacity events in the given measured time period is less than the event design threshold, the method400returns to operation402(shown inFIG. 4A) and the method400restarts. If, however, the number of insufficient host capacity events in the given measure time period is greater than the event design threshold, the method400proceeds to operation426, where the capacity manager updates the cluster host resource allocation, where the host resources include computing, memory, storage, and network interfaces. From operation426, the method400then proceeds to operation414, where the method400ends.

Turning now toFIG. 5, a network topology500for a data center cloud502will be described, according to an illustrative embodiment. The illustrated network topology500includes three layers: an application (“APP”) layer504, a virtual network topology layer506, and a physical network topology layer508. The APP layer504can include one or more application VNFs510A-510N, each of which can be divided into one or more sub-VNFs512A-512D (referred to herein collectively as sub-VNFs512) to be executed by one or more VMs514A-514D (referred to herein collectively as VMs514), such as the VM-Ms214. In the context of the concepts and technologies disclosed herein, the VNFs510are event processing network functions for the SDM platform102.

The virtual network topology layer506includes the VMs514, one or more hypervisors516A-516N (referred to herein collectively as hypervisors516), and one or more server modules (“blades”)518A-518N (referred to herein collectively as blades518). Each of the blades518can support one of the hypervisors516that, in turn, can manage one or more of the VMs514. The blades518provide computing capacity to support the VMs514carrying the VNFs512. The hypervisors516provide resource management among the VMs514supported thereby. A logical server cluster (e.g., one or more server clusters520A-520N, referred to herein collectively as server clusters520) is created for resource allocation and reallocation purpose, which includes the blades518in the same server host522. Each server host522includes one or more of the server clusters520.

The physical network topology layer508includes an Ethernet switch (“ESwitch”) group, including one or more ESwitches524A-524N (referred to herein collectively as ESwitch group524). The physical network topology layer508also includes a router group, including one or more routers526A-526N (referred to herein collectively as router group526). The ESwitch group524provides traffic switching function among the blades518. The router group526provides connectivity for traffic routing between the data center cloud502and the virtualized IP SDN network(s)106. The router group526may or may not provide multiplexing functions, depending upon network design.

The virtual network topology layer506is dynamic by nature, and as such, the VMs514can be moved among the blades518as needed. The physical network topology layer508is more static, and as such, no dynamic resource allocation is involved in this layer. Through such a network topology configuration, the association among application VNFs510, the VM514supporting the application VNFs510, and the blades518that hosts the VM514can be determined.

In the illustrated example, a first VNF is divided into two sub-VNFs, VNF1-1512A and VNF1-2512C, which is executed by VM1-1-1514A and VM1-N-1514C, respectively. The VM1-1-1514A is hosted by the blade1-1518A and managed by the hypervisor1-1516A in the server cluster1520A of the server host522. Traffic switching between the blade1-1518A and the blade1-N518N is performed via ESwitch-1524A. Traffic communications between the ESwitch group524and the virtualized IP SDN network(s)106are performed via the router group526. In this example, the VM1-1-1514A can be moved from the blade1-1518A to the blade1-N518N for VM live migration if the blade1-1518A is detected to have difficulty to support the VNF1-1512A performance requirements and the blade1-N518N has sufficient capacity and is available to support the VNF1-1512A performance requirements. The virtual network topology layer506is dynamic by nature due to real-time resource allocation/reallocation capability of cloud SDN. The association of application, VM, and blade host in this example is the VNF1-1512A is executed on the VM1-1-1514A hosted by the blade1-1518A in the server cluster1520A.

Turning now toFIG. 6, a block diagram illustrating a computer system600configured to provide the functionality described herein for an auto-scaling SDM platform for SDN service assurance in accordance with various embodiments of the concepts and technologies disclosed herein is described. The computer system600includes a processing unit602, a memory604, one or more user interface devices606, one or more input/output (“I/O”) devices608, and one or more network devices610, each of which is operatively connected to a system bus612. The system bus612enables bi-directional communication between the processing unit602, the memory604, the user interface devices606, the I/O devices608, and the network devices610.

The processing unit602may be a standard central processor that performs arithmetic and logical operations, a more specific purpose programmable logic controller (“PLC”), a programmable gate array, or other type of processor known to those skilled in the art and suitable for controlling the operation of the server computer. The processing unit802can be a single processing unit or a multiple processing unit that includes more than one processing component. Processing units are generally known, and therefore are not described in further detail herein.

The memory604communicates with the processing unit602via the system bus612. The memory604can include a single memory component or multiple memory components. In some embodiments, the memory604is operatively connected to a memory controller (not shown) that enables communication with the processing unit602via the system bus612. The memory604includes an operating system614and one or more program modules616. The operating system614can include, but is not limited to, members of the WINDOWS, WINDOWS CE, and/or WINDOWS MOBILE families of operating systems from MICROSOFT CORPORATION, the LINUX family of operating systems, the SYMBIAN family of operating systems from SYMBIAN LIMITED, the BREW family of operating systems from QUALCOMM CORPORATION, the MAC OS, iOS, and/or LEOPARD families of operating systems from APPLE CORPORATION, the FREEBSD family of operating systems, the SOLARIS family of operating systems from ORACLE CORPORATION, other operating systems, and the like.

The program modules616may include various software and/or program modules described herein. In some embodiments, for example, the program modules616include the management system QoS monitor202, the management system QoS measurer204, the resource auto-scaler206, and the alert reporter208. This and/or other programs can be embodied in computer-readable media containing instructions that, when executed by the processing unit602, perform the methods300,400described in detail above with respect toFIGS. 3, 4A, and 4B. According to embodiments, the program modules616may be embodied in hardware, software, firmware, or any combination thereof. Although not shown inFIG. 6, it should be understood that the memory604also can be configured to store any data disclosed herein.

The user interface devices606may include one or more devices with which a user accesses the computer system600. The user interface devices606may include, but are not limited to, computers, servers, personal digital assistants, cellular phones, or any suitable computing devices. The I/O devices608enable a user to interface with the program modules616. In one embodiment, the I/O devices608are operatively connected to an I/O controller (not shown) that enables communication with the processing unit602via the system bus612. The I/O devices608may include one or more input devices, such as, but not limited to, a keyboard, a mouse, or an electronic stylus. Further, the I/O devices608may include one or more output devices, such as, but not limited to, a display screen or a printer.

The network devices610enable the computer system600to communicate with other networks or remote systems via a network618. Examples of the network devices610include, but are not limited to, a modem, a radio frequency (“RF”) or infrared (“IR”) transceiver, a telephonic interface, a bridge, a router, or a network card. The network618may include a wireless network such as, but not limited to, a Wireless Local Area Network (“WLAN”) such as a WI-FI network, a Wireless Wide Area Network (“WWAN”), a Wireless Personal Area Network (“WPAN”) such as BLUETOOTH, a Wireless Metropolitan Area Network (“WMAN”) such a WiMAX network, or a cellular network. Alternatively, the network618may be a wired network such as, but not limited to, a Wide Area Network (“WAN”) such as the Internet, a Local Area Network (“LAN”) such as the Ethernet, a wired Personal Area Network (“PAN”), or a wired Metropolitan Area Network (“MAN”).

Referring now toFIG. 7, aspects of a network functions virtualization platform (“NFVP”)702are described. The NFVP702is a shared infrastructure that can support multiple services and network applications, such as video streaming services described herein. The illustrated NFVP702includes a hardware resource layer704, a virtualization/control layer706, and a virtual resource layer708that work together to perform operations as will be described in detail herein. While connections are shown between some of the components illustrated inFIG. 7, it should be understood that some, none, or all of the components illustrated inFIG. 7can be configured to interact with one another to carry out various functions described herein. In some embodiments, the components are arranged so as to communicate via one or more networks (not shown). Thus, it should be understood thatFIG. 7and the following description are intended to provide a general understanding of a suitable environment in which various aspects of embodiments can be implemented, and should not be construed as being limiting in any way.

The hardware resource layer704provides hardware resources, such as, for example, the hardware hosts218. In the illustrated embodiment, the hardware resource layer704includes one or more compute resources710, one or more memory resources712, and one or more other resources714. The compute resource(s)710can include one or more hardware components that perform computations to process data, and/or to execute computer-executable instructions of one or more application programs, operating systems, and/or other software. The compute resources710can include one or more central processing units (“CPUs”) configured with one or more processing cores. The compute resources710can include one or more graphics processing unit (“GPU”) configured to accelerate operations performed by one or more CPUs, and/or to perform computations to process data, and/or to execute computer-executable instructions of one or more application programs, operating systems, and/or other software that may or may not include instructions particular to graphics computations. In some embodiments, the compute resources710can include one or more discrete GPUs. In some other embodiments, the compute resources710can include CPU and GPU components that are configured in accordance with a co-processing CPU/GPU computing model, wherein the sequential part of an application executes on the CPU and the computationally-intensive part is accelerated by the GPU. The compute resources710can include one or more system-on-chip (“SoC”) components along with one or more other components, including, for example, one or more of the memory resources712, and/or one or more of the other resources714. In some embodiments, the compute resources710can be or can include one or more SNAPDRAGON SoCs, available from QUALCOMM of San Diego, Calif.; one or more TEGRA SoCs, available from NVIDIA of Santa Clara, Calif.; one or more HUMMINGBIRD SoCs, available from SAMSUNG of Seoul, South Korea; one or more Open Multimedia Application Platform (“OMAP”) SoCs, available from TEXAS INSTRUMENTS of Dallas, Tex.; one or more customized versions of any of the above SoCs; and/or one or more proprietary SoCs. The compute resources710can be or can include one or more hardware components architected in accordance with an ARM architecture, available for license from ARM HOLDINGS of Cambridge, United Kingdom. Alternatively, the compute resources710can be or can include one or more hardware components architected in accordance with an x86 architecture, such an architecture available from INTEL CORPORATION of Mountain View, Calif., and others. Those skilled in the art will appreciate the implementation of the compute resources710can utilize various computation architectures, and as such, the compute resources710should not be construed as being limited to any particular computation architecture or combination of computation architectures, including those explicitly disclosed herein.

The memory resource(s)712can include one or more hardware components that perform storage operations, including temporary or permanent storage operations. In some embodiments, the memory resource(s)712include volatile and/or non-volatile memory implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data disclosed herein. Computer storage media includes, but is not limited to, random access memory (“RAM”), read-only memory (“ROM”), Erasable Programmable ROM (“EPROM”), Electrically Erasable Programmable ROM (“EEPROM”), flash memory or other solid state memory technology, CD-ROM, digital versatile disks (“DVD”), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store data and which can be accessed by the compute resources710.

The other resource(s)714can include any other hardware resources that can be utilized by the compute resources(s)710and/or the memory resource(s)712to perform operations described herein. The other resource(s)714can include one or more input and/or output processors (e.g., network interface controller or wireless radio), one or more modems, one or more codec chipset, one or more pipeline processors, one or more fast Fourier transform (“FFT”) processors, one or more digital signal processors (“DSPs”), one or more speech synthesizers, and/or the like.

The hardware resources operating within the hardware resource layer704can be virtualized by one or more virtual machine monitors (“VMMs”)716-716K (also known as “hypervisors”; hereinafter “VMMs716”), such as the hypervisors216, operating within the virtualization/control layer706to manage one or more virtual resources that reside in the virtual resource layer708. The VMMs716can be or can include software, firmware, and/or hardware that alone or in combination with other software, firmware, and/or hardware, manages one or more virtual resources operating within the virtual resource layer708.

The virtual resources operating within the virtual resource layer708can include abstractions of at least a portion of the compute resources710, the memory resources712, the other resources714, or any combination thereof. These abstractions are referred to herein as virtual machines (“VMs”). In the illustrated embodiment, the virtual resource layer708includes VMs718-718N (hereinafter “VMs718”), such as the VM-Ms214. The VMs718can execute one or more applications to provide one or more services, such as, for example, streaming video services.

In some embodiments, a server can include a plurality of server clusters, such as the server clusters shown inFIG. 5. Each server cluster can include one or more of the VMs718, one or more of the VMMs716, and a plurality of host hardware resources, such as one or more of the compute resources710, one or more of the memory resources712, and one or more of the other resources714.