Cloud-based resource availability calculation of a network environment

An example method for cloud-based resource availability calculation of a network environment is provided and includes receiving a plurality of system error log (SEL) data in real time at a virtual appliance executing in a first network. The SEL data is received from a remote second network indicating system events associated with corresponding resources in the second network. The method further includes calculating a resource availability (RA) index indicative of availability of resources for workload deployment in the second network, and sending the RA index to a management application executing in the second network for appropriate management and allocation of resources in the second network. In specific embodiments, the method further includes receiving a SEL inventory associated with a specific resource in the second network, and updating the RA index based on the SEL inventory.

TECHNICAL FIELD

This disclosure relates in general to the field of communications and, more particularly, to cloud-based resource availability calculation of a network environment.

BACKGROUND

Data centers are increasingly used by enterprises for effective collaboration and interaction and to store data and resources. A typical data center network contains myriad network elements, including hosts, load balancers, routers, switches, etc. The network connecting the network elements provides secure user access to data center services and an infrastructure for deployment, interconnection, and aggregation of shared resource as required, including applications, hosts, appliances, and storage. Improving operational efficiency and optimizing utilization of resources in data centers are some of the challenges facing data center managers. Data center managers want a resilient infrastructure that consistently supports diverse applications and services and protects the applications and services against disruptions. A properly planned and operating data center network provides application and data integrity and optimizes application availability and performance.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

An example method for cloud-based resource availability calculation of a network environment is provided and includes receiving a plurality of system error log (SEL) data in real time at a virtual appliance executing in a first network. The SEL data is received from a remote second network indicating system events associated with corresponding resources in the second network. The method further includes calculating a resource availability (RA) index indicative of availability of resources for workload deployment in the second network, and sending the RA index to a management application executing in the second network for appropriate management and allocation of resources in the second network. In specific embodiments, the method further includes receiving a SEL inventory associated with a specific resource in the second network, and updating the RA index based on the SEL inventory.

As used herein, the term “SEL data” refers to a log (e.g., record, note) of a single significant system event associated with a particular resource (e.g., network or compute resource, such as a memory element, processor, etc.) in a network. SEL data can be formatted as at least one file that records the system event according to any suitable format. SEL data can also include information about location of events (e.g., dynamic random access memory (DRAM) errors are reported on location, central processing unit (CPU) cache miss is reported with CPU core location, etc.). Examples of significant system events indicated by the SEL data include software events (e.g., loss of data, reboot operations, successful launch of a program, driver, or service, etc.); security-related events (e.g., user login, malware interaction, etc.); setup events (e.g., events detected by domain controllers); and hardware events (e.g., events logged by the operating system of the reporting endpoint and related to the hardware of the system, such as boot-up, shutdown, memory failure, bug-check, driver error, etc.).

Example Embodiments

Turning toFIG. 1,FIG. 1is a simplified block diagram illustrating a communication system10for cloud-based resource availability calculation of a network environment in accordance with one example embodiment.FIG. 1illustrates a communication system10comprising a network12that includes a plurality of endpoints14managed by one or more instances of a management application referred to herein as unified computing system manager (UCSM)16. Each endpoint14may generate SEL data18and/or SEL inventory19, which is sent to the respective managing instance of UCSM16. In some embodiments, baseboard management controllers (BMCs) associated with each endpoint14may write system events into one or more log files (e.g., in flash memory of an associated network element) for example, whenever the event(s) occur, and the log file(s) may be included in SEL data18and/or SEL inventory19.

UCSM16may relay (e.g., forward, convey, send, deliver, etc.) SEL data18and SEL inventory19to at least one instance of a virtual appliance referred to herein as unified computing system (UCS) Central20executing in a cloud22. UCS Central20may include an index calculator24that processes SEL data18and SEL inventory19to generate a resource availability (RA) index26that is sent to UCSM16. UCSM16may use RA index26in management resource allocation decisions for resources in network12.

As used herein, the term “RA index” refers to a numeric value that indicates availability of one or more resources in network12. In a general sense, the RA index may be calculated for individual components (e.g., central processor units (CPUs), dynamic random access memory (DRAM), etc.) by analyzing SEL data generated by baseboard management controllers (BMCs) of network elements and/or reading appropriate sensor records. A “resource” comprises a component that can be used for workload deployment and software execution; examples of resources include processors, memory elements, network interfaces, network links, sensors, etc. In a general sense, resources can include computation resources (e.g., a component that performs execution of a process); service providing resources (e.g., application components that invoke computation tasks); network resources (e.g., components that provide bandwidth for communication); and data storage resources (e.g., components that provide storage for data). According to various embodiments, RA index26may be calculated by index calculator according to any known method.

The term “network element” is meant to encompass computers, network appliances, servers, routers, switches, gateways, bridges, load balancers, firewalls, processors, modules, or any other suitable device, component, element, or object operable to exchange information in a network environment. Moreover, the network elements may include any suitable hardware, software, components, modules, interfaces, or objects that facilitate the operations thereof. This may be inclusive of appropriate algorithms and communication protocols that allow for the effective exchange of data or information.

As used herein, the term “SEL inventory” includes a log of multiple significant system events associated with a particular resource in network12(e.g., associated with a specific endpoint14). For example, SEL inventory19may be generated by collecting substantially all SEL data18during a certain time interval (e.g., from boot-up until a specific query for SEL inventory19is received) for a specific endpoint14.

For purposes of illustrating the techniques of communication system10, it is important to understand the communications that may be traversing the system shown inFIG. 1. The following foundational information may be viewed as a basis from which the present disclosure may be properly explained. Such information is offered earnestly for purposes of explanation only and, accordingly, should not be construed in any way to limit the broad scope of the present disclosure and its potential applications.

Workloads are deployed on physical servers to ensure compliance with service level agreements (SLAs) between network operators and network subscribers. In a general sense, the term “workload” refers to the amount of processing to be executed by a computing resource in a given time interval; the workload can include application programming running in the computing resource and a certain number of users connected to and interacting with the applications. Network administrators may select target servers for workload deployment based on server resource capacities (e.g., CPU, memory and input/output capabilities). Over time, the network and computing resources can be degraded, for example, due to hardware component failures such as CPU core de-allocation, DRAM failures, etc. Additionally, total resource capacity may be lowered when certain network and computing resources enter a lower power state. Such degraded resource capacity may affect resource allocation, for example, when a server running with degraded components/capacity, may not be able to host workloads according to the SLAs.

In such scenarios, the RA index can inform network administrators about the true (e.g., effective) capacity of servers and other network and computing resources in the network, before such resources are selected for deploying workloads according to the SLAs. In a typical domain (e.g., with multiple servers), the resource availability data obtained from individual network and computing resources can be overwhelming and can take a lot of processing power to analyze and correlate to compute the RA index. Management applications, such as UCSM managing individual domains of the network typically do not have sufficient storage capacity or computing power to store and analyze resource availability information on a regular basis.

Management domains may easily get stressed or blocked with processing the large volume of data from individual network and compute resources to calculate the resource availability index of the underlying hardware. Thus regular management activities may get delayed and/or timed-out significantly. Additionally, if domain level management solutions are run in an embedded environment, stringent restrictions on the compute and network resources may have to be applied to analyze such voluminous information. Extrapolating the stringent requirement to multiple management domains in the date center could make the situation even worse.

Communication system10is configured to address these issues (among others) to offer a system and method for cloud-based resource availability calculation of a network environment. According to various embodiments, UCS Central20may receive a plurality of SEL data18from network12in real time indicating system events associated with corresponding resources (e.g., processors and memory elements in endpoints14) in network12. UCS Central20may calculate RA index26indicative of availability of resources for workload deployment in network12and send RA index26to UCSM16executing in network12for appropriate management and allocation of resources.

Note that network12may comprise a plurality of domains, each domain being managed by a separate instance of UCSM16. In many embodiments, each domain (e.g., referred to as a unified computing system) may be managed by an instance of UCSM16embedded in a fabric interconnect at an individual domain level; substantially all domains may be managed by UCS Central20at a network level. Massive sensor records and activity events (e.g., error events from BMCs) can require a significant chunk of resources to process at a domain level by individual instances of UCSM16. Instead of using UCSM16instances for processing voluminous sensor and activity/error records, SEL data18may be processed by a remote central management application, UCS Central20, executing as a virtual appliance in a server in cloud22.

Each UCSM16instance may forward SEL data18to UCS Central20in cloud22; each UCSM16instance may receive SEL data18(e.g., from its managed endpoints14) to forward from resources in its respective managed domain. Each UCSM16instance registers with UCS Central20in some embodiments. In some embodiments, UCS Central20may receive SEL inventory19associated with a specific resource (e.g., in a particular endpoint14) in network12. The instance of UCSM16managing the specific resource may have previously sent a query requesting SEL inventory19, and may have received SEL inventory19in response. UCS Central20may update RA index26based on SEL inventory19.

Computing RA index26can include performing statistical analysis of SEL data18(and SEL inventory19), and correlating and consolidating SEL data18in real time. In many embodiments, RA index26may consolidate resource availability at a plurality of levels in network12. For example, the plurality of levels can include at least a network level, a domain level, a chassis level, a blade level and a device level. After data is processed and RA indices are calculated per domain and sub-components, the RA indices can be passed down to individual domains appropriately.

In some embodiments, SEL data18and SEL inventory19may be inventoried at UCS Central20executing in cloud22; UCS Central20may use throttling process (e.g., to conserver power) to derive RA index26for managed endpoints14. In some embodiments, RA index26may be broken down to the device level (e.g., at level of individual hardware devices at endpoints14) and sent to endpoints14by respective UCSM16instances.

During operation, each UCSM16instance may register with UCS Central20(e.g., executing in a virtual machine (VM) in cloud22). After a substantially complete inventory of all resources in network12is received at UCS Central20, UCS Central20may process the information and understand the allocation of resources associated with each managed domain. Each UCSM16instance may send incremental SEL data18(e.g., as and when an event is detected), which can include component information about degraded components or hardware disablement, such as CPU core de-allocation, dual in-line memory module (DIMM) blacklisting, DRAM failures etc., to UCS Central20. At UCS central20, information in SEL data18may be processed and RA index26may be calculated taking into account individual locations of events indicated in SEL data18. A resource manager module and a statistics manager module in UCS central20may process SEL data18to calculate effective capacity of individual devices (e.g., processor, memory element, etc.). The effective capacity information may be consolidated at various levels (e.g., device level, chassis level, blade level, domain level, etc.) including at a network (e.g., data center) level. The consolidated effective capacity information may be included in RA index26. RA index26, including effective capacity information at various network levels, may be relayed back to UCSM16. RA index26may be queried at each instance of UCSM16as appropriate. For example, administrators can decide to deploy their workloads based on RA index26observed at UCSM16.

Embodiments of communication system10can facilitate a faster, more efficient and effective method to enable administrators plan their workload deployments, for example, by accessing information about effective server capacity and not consuming end-point resources to calculate RA index26. Instead, calculation of RA index26may be delegated to cloud22for all the managed domains and endpoints14. Such an approach can facilitate better user experience, effective workload deployment and compliance with SLA requirements.

Turning to the infrastructure of communication system10, the network topology can include any number of servers, hardware accelerators, virtual machines, switches (including distributed virtual switches), routers, and other nodes inter-connected to form a large and complex network. A node may be any electronic device, client, server, peer, service, application, or other object capable of sending, receiving, or forwarding information over communications channels in a network. Elements ofFIG. 1may be coupled to one another through one or more interfaces employing any suitable connection (wired or wireless), which provides a viable pathway for electronic communications. Additionally, any one or more of these elements may be combined or removed from the architecture based on particular configuration needs.

Communication system10may include a configuration capable of TCP/IP communications for the electronic transmission or reception of data packets in a network. Communication system10may also operate in conjunction with a User Datagram Protocol/Internet Protocol (UDP/IP) or any other suitable protocol, where appropriate and based on particular needs. In addition, gateways, routers, switches, and any other suitable nodes (physical or virtual) may be used to facilitate electronic communication between various nodes in the network.

Note that the numerical and letter designations assigned to the elements ofFIG. 1do not connote any type of hierarchy; the designations are arbitrary and have been used for purposes of teaching only. Such designations should not be construed in any way to limit their capabilities, functionalities, or applications in the potential environments that may benefit from the features of communication system10. It should be understood that communication system10shown inFIG. 1is simplified for ease of illustration.

The example network environment may be configured over a physical infrastructure that may include one or more networks and, further, may be configured in any form including, but not limited to, local area networks (LANs), wireless local area networks (WLANs), VLANs, metropolitan area networks (MANs), VPNs, Intranet, Extranet, any other appropriate architecture or system, or any combination thereof that facilitates communications in a network.

In some embodiments, a communication link may represent any electronic link supporting a LAN environment such as, for example, cable, Ethernet, wireless technologies (e.g., IEEE 802.11x), ATM, fiber optics, etc. or any suitable combination thereof. In other embodiments, communication links may represent a remote connection through any appropriate medium (e.g., digital subscriber lines (DSL), telephone lines, T1 lines, T3 lines, wireless, satellite, fiber optics, cable, Ethernet, etc. or any combination thereof) and/or through any additional networks such as a wide area networks (e.g., the Internet).

In various embodiments, UCSM16includes a management application located in network12that operates to manage, allocate, provision, and operate on endpoints14in network12. For example, UCSM16provides a unified, embedded management of substantially all software and hardware components in network12. UCSM16can provide a single point of management for an entire computing system (e.g., a set of network and compute resources linked together to appear as a single computing system) that can span a domain (e.g., portion) of network12. For example, each instance of UCSM16may manage a domain of up to 160 servers and associated infrastructure. In many embodiments, UCSM16may use a policy-based approach to provision servers by applying a desired configuration to physical infrastructure. For example, using certain specifically configured service profiles, administrators can reproduce existing physical environments, including I/O configuration, firmware, and settings. The configuration can be applied quickly, accurately, and automatically, improving business agility. A role-based access control (RBAC) model helps ensure security of the system configurations.

According to various embodiments, UCS Central20facilitates managing multiple domains of network12through a single interface in cloud22. For example, UCS Central20can facilitate global policy compliance, with subject-matter experts choosing appropriate resource pools and policies that may be enforced globally or managed locally. With simple user interface operations (e.g., drag-and-drop), service profiles can be moved between geographies to enable fast deployment of infrastructure, when and where it is needed, for example, to support workloads.

In many embodiments, UCS Central20comprises a virtual appliance (e.g., prepackaged as a VMware.ova or an ISO image) hosted outside network12. As used herein, the term “virtual appliance” comprises a pre-configured virtual machine image ready to execute on a suitable hypervisor; installing a software appliance (e.g., applications with operating system included) on a virtual machine and packaging the installation into an image creates the virtual appliance. The virtual appliance is not a complete virtual machine platform, but rather a software image containing a software stack designed to run on a virtual machine platform (e.g., a suitable hypervisor).

Network12comprises one or more domains, each domain managed by a separate and distinct instance of UCSM16. UCS Central20may securely communicate with UCSM16instances to (among other functions) collect inventory and fault data from throughout network12; create resource pools of servers available to be deployed; enable role-based management of resources; support creation of global policies, service profiles, and templates; enable downloading of and selective or global application of firmware updates; and invoke specific instances of UCSM16to more detailed management.

In many embodiments, UCS Central20stores global resource information and policies accessible through an Extensible Markup Language (XML) application programming interface (API). In some embodiments, operation statistics may be stored in an Oracle or PostgreSQL database. UCS Central20can be accessed through an appropriate graphical user interface (GUI), command line interface (CLI), or XML API (e.g., for ease of integration with high-level management and orchestration tools).

Turning toFIG. 2,FIG. 2is a simplified block diagram illustrating example details of another embodiment of communication system10. In a particular embodiment of a communication system10, index calculator24in UCS Central20may include a statistics manager28and a resource manager30in addition to a memory element32and a processor34. SEL data18and SEL inventory19from network12may be received at index calculator24. Statistics manager28may aggregate and analyze SEL data18and SEL inventory19using suitable statistical tools and processes. Resource manager30may include a database comprising a resource list33of substantially all resources and corresponding locations (e.g., domain, UCSM16connectivity, etc.) in network12. Resource manager30may compute RA index26comprising effective capacity of resources at various levels (e.g., device, blade, chassis, domain, and network) in network12. Index calculator24may use memory element32and a processor34to perform various operations described herein.

Turning toFIG. 3,FIG. 3is a simplified block diagram illustrating example details of an embodiment of communication system10. Network12may include various domains, for example, domains40(1) and40(2). Each domain40(1) and40(2) may be managed by a separate instance of UCSM, for example, UCSM16(1) and16(2), respectively. Each domain40(1) and40(2) may include various chassis; for example, domain40(1) may include chassis42(1) and42(2); domain40(2) may include chassis42(3). Each chassis42(1)-42(3) may include one or more blades. For example, chassis42(1) includes blades44(2) and44(2); chassis42(2) may include blade44(3); chassis42(3) may include blades44(4) and44(5).

Each blade may include at least one BMC that represents endpoint14; for example, blade44(1) may include BMC14(1); blade44(2) may include BMC14(2); blade44(3) may include BMC14(3); blade44(4) may include BMC14(4); and blade44(5) may include BMC14(5). Each BMC14(1)-14(5) may manage several devices46such as memory elements and processors. For example, BMC14(1) may manage and record events associated with MEM1(e.g., memory element) and CPU1(e.g., processor) in blade44(1); BMC14(2) may manage and record events associated with MEM2and CPU2in blade44(2); BMC14(3) may manage and record events associated with MEM3and CPU3in blade44(3); BMC14(4) may manage and record events associated with MEM4and CPU4in blade14(4); and BMC14(5) may manage and record events associated with MEM5, MEM6, CPU5, and CPU6in blade44(5). Although only a limited number of devices, blades, chassis and domains are illustrated in the figure, any number of devices, blades, chassis and domains may be included in communication system10within the broad scope of the embodiments.

Assume, merely for example purposes and not as a limitation that CPU2becomes less effective than its expected processing capacity due to thermal trip errors. BMC14(2) may log the event into SEL data18, and send SEL data18to UCSM16(1). Similarly, assume that CPU3experiences a significant system event such as a power failure. BMC14(3) may log the event into SEL data18, and send SEL data18to UCSM16(1). UCSM16(1) may relay SEL data18from BMC14(1) and14(2) to UCS Central20in cloud22. Assume, merely for example purposes that MEM5, CPU5and CPU6suffer a breakdown. BMC14(5) may generate SEL data18and send it to UCSM16(2), which may relay the information to UCS Central20.

UCS Central20may compute RA index26at various levels. For example, at a network level, resource availability may be less effective by approximately 40% (e.g., 5 out of 12 devices are not fully effective). At a domain level, domain40(1) may be less effective by approximately 30% (e.g., 2 out of 6 devices not fully effective) whereas domain40(2) may be less effective by approximately 50% (e.g., 3 out of 6 devices not fully effective). At a chassis level, chassis42(1) may be less effective by approximately 25%, whereas chassis42(2) may be completely out of commission. Various such calculations may be performed based on the type of system event logged in SEL data18and RA index26calculated appropriately at various levels.

Turning toFIG. 4,FIG. 4is a simplified flow diagram illustrating example operations50that may be associated with embodiments of communication system10. At52, each endpoint14may generate SEL data18at respective BMCs on occurrence of a system event. At54, each BMC may update its respective SEL inventory19. At56, each BMC may send updated SEL inventory19to interested subscribers, for example, corresponding UCSM16instances.

Turning toFIG. 5,FIG. 5is a simplified flow diagram illustrating example operations60that may be associated with embodiments of communication system10. At62, UCSM16may receive RA index26from UCS Central20. At64, UCSM16may determine resource allocation in its managed domain using RA index26. At66, UCSM16may instantiate resources in its managed domain accordingly.

Note that in this Specification, references to various features (e.g., elements, structures, modules, components, steps, operations, characteristics, etc.) included in “one embodiment”, “example embodiment”, “an embodiment”, “another embodiment”, “some embodiments”, “various embodiments”, “other embodiments”, “alternative embodiment”, and the like are intended to mean that any such features are included in one or more embodiments of the present disclosure, but may or may not necessarily be combined in the same embodiments. Note also that an ‘application’ as used herein this Specification, can be inclusive of an executable file comprising instructions that can be understood and processed on a computer, and may further include library modules loaded during execution, object files, system files, hardware logic, software logic, or any other executable modules. Furthermore, the words “optimize,” “optimization,” and related terms are terms of art that refer to improvements in speed and/or efficiency of a specified outcome and do not purport to indicate that a process for achieving the specified outcome has achieved, or is capable of achieving, an “optimal” or perfectly speedy/perfectly efficient state.

In example implementations, at least some portions of the activities outlined herein may be implemented in software in, for example, UCS Central20. In some embodiments, one or more of these features may be implemented in hardware, provided external to these elements, or consolidated in any appropriate manner to achieve the intended functionality. The various network elements (e.g., UCS Central20) may include software (or reciprocating software) that can coordinate in order to achieve the operations as outlined herein. In still other embodiments, these elements may include any suitable algorithms, hardware, software, components, modules, interfaces, or objects that facilitate the operations thereof.

Furthermore, UCS Central20described and shown herein (and/or their associated structures) may also include suitable interfaces for receiving, transmitting, and/or otherwise communicating data or information in a network environment. Additionally, some of the processors and memory elements associated with the various nodes may be removed, or otherwise consolidated such that a single processor and a single memory element are responsible for certain activities. In a general sense, the arrangements depicted in the FIGURES may be more logical in their representations, whereas a physical architecture may include various permutations, combinations, and/or hybrids of these elements. It is imperative to note that countless possible design configurations can be used to achieve the operational objectives outlined here. Accordingly, the associated infrastructure has a myriad of substitute arrangements, design choices, device possibilities, hardware configurations, software implementations, equipment options, etc.

In some of example embodiments, one or more memory elements (e.g., memory element32) can store data used for the operations described herein. This includes the memory element being able to store instructions (e.g., software, logic, code, etc.) in non-transitory media, such that the instructions are executed to carry out the activities described in this Specification. A processor can execute any type of instructions associated with the data to achieve the operations detailed herein in this Specification. In one example, processors (e.g., processor34) could transform an element or an article (e.g., data) from one state or thing to another state or thing. In another example, the activities outlined herein may be implemented with fixed logic or programmable logic (e.g., software/computer instructions executed by a processor) and the elements identified herein could be some type of a programmable processor, programmable digital logic (e.g., a field programmable gate array (FPGA), an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM)), an ASIC that includes digital logic, software, code, electronic instructions, flash memory, optical disks, CD-ROMs, DVD ROMs, magnetic or optical cards, other types of machine-readable mediums suitable for storing electronic instructions, or any suitable combination thereof.

These devices may further keep information in any suitable type of non-transitory storage medium (e.g., random access memory (RAM), read only memory (ROM), field programmable gate array (FPGA), erasable programmable read only memory (EPROM), electrically erasable programmable ROM (EEPROM), etc.), software, hardware, or in any other suitable component, device, element, or object where appropriate and based on particular needs. The information being tracked, sent, received, or stored in communication system10could be provided in any database, register, table, cache, queue, control list, or storage structure, based on particular needs and implementations, all of which could be referenced in any suitable timeframe. Any of the memory items discussed herein should be construed as being encompassed within the broad term ‘memory element.’ Similarly, any of the potential processing elements, modules, and machines described in this Specification should be construed as being encompassed within the broad term ‘processor.’

Although the present disclosure has been described in detail with reference to particular arrangements and configurations, these example configurations and arrangements may be changed significantly without departing from the scope of the present disclosure. For example, although the present disclosure has been described with reference to particular communication exchanges involving certain network access and protocols, communication system10may be applicable to other exchanges or routing protocols. Moreover, although communication system10has been illustrated with reference to particular elements and operations that facilitate the communication process, these elements, and operations may be replaced by any suitable architecture or process that achieves the intended functionality of communication system10.