Dynamic bandwidth allocation in cloud network switches based on traffic demand prediction

Abstract

Embodiments are provided for dynamic bandwidth allocation in cloud network switches in a cloud computing environment. Quality of service (QoS) policies can be dynamically changed at one or more cloud network switches based on dynamically estimating expected traffic demand for each of a plurality of traffic classes, with bandwidth being dynamically allocated among queues based on changing the QoS policies.

Description

Technical Field

[0001] The present invention relates generally to computing systems, and more specifically to different embodiments of dynamic bandwidth allocation in cloud network switches in a cloud computing environment for business demand prediction. Background Technology

[0002] A popular type of large-scale computing is cloud computing, where resources can interact and / or be accessed via communication systems such as computer networks. Resources can be software-rendered simulations and / or emulations of computing devices, storage devices, applications, and / or other computer-related devices and / or services running on one or more computing devices such as servers. For example, multiple servers can communicate and / or share information that can scale and / or shrink across servers based on the amount of processing power, storage space, and / or other computing resources required to complete a requested task. The term "cloud" implies the cloud-like appearance of a graph of interconnectivity between computing devices, computer networks, and / or other computer-related devices interacting in this arrangement. Summary of the Invention

[0003] Different embodiments for dynamic bandwidth allocation in cloud network switches in a cloud computing environment are provided. One or more Quality of Service (QoS) policies in one or more cloud network switches can be dynamically changed based on the expected service demand of each of multiple service categories of queues mapped to ports of network elements. The bandwidth allocation among queues of a given port in one or more cloud network switches can be dynamically changed by modifying the QoS policies.

[0004] In addition to the exemplary method embodiments described above, other exemplary system and computer product embodiments are provided and offer related advantages. Attached Figure Description

[0005] To facilitate understanding of the advantages of the invention, a more detailed description of the invention, briefly described above, will be presented with reference to specific embodiments shown in the accompanying drawings. It should be understood that these drawings depict only exemplary embodiments of the invention and are therefore not intended to limit the scope of the invention. The invention will be described and explained with additional features and details using the drawings, in which:

[0006] Figure 1 This is a block diagram illustrating an exemplary computing node according to an embodiment of the present invention.

[0007] Figure 2 This is an additional block diagram depicting an exemplary cloud computing environment according to an embodiment of the present invention.

[0008] Figure 3 This is an additional block diagram depicting the abstract model layer according to an embodiment of the present invention.

[0009] Figure 4 This is an additional block diagram depicting exemplary functional relationships between various aspects of the present invention.

[0010] Figure 5 This is a block diagram depicting the operation of dynamic bandwidth allocation in a cloud network switch in a cloud computing environment based on business demand prediction according to an embodiment of the present invention.

[0011] Figure 6 This is a block diagram depicting the operation of dynamic bandwidth allocation in a cloud network switch in a cloud computing environment based on business demand prediction according to an embodiment of the present invention.

[0012] Figure 7 This is an additional flowchart depicting a method for dynamic bandwidth allocation in a cloud network switch in a cloud computing environment based on business demand prediction, according to an embodiment of the present invention. Detailed Implementation

[0013] As a preliminary consideration, computing systems can include large-scale computing known as “cloud computing,” where resources can interact and / or be accessed via communication systems such as computer networks. Resources can be software-rendered simulations and / or emulations of computing devices, storage devices, applications, and / or other computer-related devices and / or services running on one or more computing devices such as servers. For example, multiple servers can communicate and / or share information that can scale and / or shrink across servers based on the amount of processing power, storage space, and / or other computing resources required to complete a requested task. The term “cloud” implies the cloud-like appearance of a graph of interconnectivity between computing devices, computer networks, and / or other computer-related devices interacting in this arrangement.

[0014] Cloud networks cause constant fluctuations in the types of applications running on them, resulting in different business characteristics over time. The constant changes in business demands complicate the process of allocating appropriate bandwidth via a priority plane in network switches to ensure Quality of Service (“QoS”) across the network. For example, a given QoS profile that statically reserves bandwidth for a set of service classes may be appropriate and effective at a given time, but could lead to unfavorable behavior if business demands change drastically.

[0015] Therefore, various embodiments of the present invention provide novel solutions for how to allocate bandwidth among switch queues in a cloud network, despite constantly changing service demands. In some implementations, one or more Quality of Service (QoS) policies in one or more cloud network switches can be dynamically changed based on anticipated service demands for each of a plurality of service categories. Bandwidth in one or more cloud network switches can be dynamically allocated based on dynamically changing QoS policies.

[0016] This invention offers advantages over existing technologies because many enterprise networks focused on QoS policies are primarily located within enterprise networks, where application service requirements change less frequently compared to cloud networks. Furthermore, it offers other advantages over existing technologies that rely on static bandwidth allocation between network switch queues. This is because static allocation is insecure in cloud environments where service requirements are constantly changing. If the allocation of services for network-sensitive applications is incorrect within the QoS policy, those services can experience packet delays, jitter, and / or data loss, while other lower-priority services avoid such degradation due to incorrect bandwidth allocation.

[0017] In other implementations, different differentiated service frameworks can differentiate service categories (e.g., service classes) and configure network elements (switches, routers) to process marked packets via a Differentiated Service Code Point (“DSCP”) field in the packet header. For example, depending on the importance of the service, packets marked as “high priority” may be forwarded before other packets, or some bandwidth may be reserved on the switch queue.

[0018] When the service requirements of a service category are known or widely recognized, this QoS policy can achieve the desired differentiated behavior. Therefore, this invention is applicable to cloud networks where service requirements can change rapidly over time. In some implementations, the QoS policy (i.e., queue bandwidth allocation) configured on the network switch can be dynamically changed, adjusted, or modified based on the expected requirements of each service category.

[0019] In some implementations, demand expectations can be derived from information relating to the scheduling of virtual entities typically implemented by an overlay Software Defined Network (overlay SDN) controller. In some embodiments, the invention can use visibility to map demand originating from servers to network elements into network topology and routing. Furthermore, different embodiments provide continuous monitoring and identification of network elements inconsistent with configured policies. Relying on the programmability in cloud networks implemented by software-defined underlying controllers to dynamically configure network elements, the invention can modify switch QoS configurations to reflect expected service processing behavior under new service conditions. In some implementations, QoS policies can be scalably changed, adjusted, and / or configured based on expected service demands. Allocations can be modified to match new service category demands only when expected service demands across one or more service categories exceed a predefined threshold. As a result, the proposed invention mitigates the problems of QoS priority plane activation as service conditions continuously change.

[0020] As used herein, "network element" can refer to, for example, switches, routers, and other packet processing components. Furthermore, the use of the term "network switch" should be considered merely as an example or illustration. Therefore, the term "network switch" can be replaced with "network element" to address and capture a broader perspective of the invention.

[0021] Furthermore, bandwidth allocation between queues can be explicitly defined, such as queue 3 receiving 50 gigabytes per second (“Gbps”), or implicitly defined, such as the scheduler serving queue 3 50% of the time; in a 100Gbps port, this has a net effect of allocating 50Gbps to queue 3. Moreover, bandwidth allocation can also be implemented implicitly.

[0022] Furthermore, a key aspect of this invention is the utilization of QoS policies. These policies apply to ports on network elements and define how bandwidth is allocated among queues for a given port.

[0023] Further examples of the aspects of the illustrated embodiments and their accompanying benefits will be described in this document.

[0024] It should be understood in advance that while this disclosure includes a detailed description of cloud computing, the implementation of the teachings cited herein is not limited to cloud computing environments and / or computing systems associated with one or more vehicles. Rather, embodiments of the invention can be implemented in conjunction with any other type of computing environment now known or developed hereafter.

[0025] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage devices, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with the service provider. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0026] The features are as follows:

[0027] On-demand self-service: Cloud consumers can unilaterally and automatically provide computing power, such as server time and network storage, as needed, without requiring human interaction with the service provider.

[0028] Extensive network access: Capabilities are available via the network and accessed through standard mechanisms that facilitate the use of heterogeneous thin client platforms or thick client platforms (e.g., mobile phones, laptops, and personal digital assistants (PDAs)).

[0029] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a sense of location independence because consumers typically do not have control or knowledge of the exact location of the resources provided, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0030] Rapid flexibility: The ability to provide capacity quickly and flexibly, automatically scaling down and up rapidly in some situations to scale up rapidly. For consumers, the available supply capacity often appears unlimited and can be purchased in any quantity at any time.

[0031] Measuring services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the service type (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both service providers and consumers.

[0032] The service model is as follows:

[0033] Software as a Service (SaaS): This provides consumers with the ability to use the provider's applications running on cloud infrastructure. Applications can be accessed from different client devices via thin client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application capabilities, with possible exceptions such as limited user-specific application configuration settings.

[0034] Platform as a Service (PaaS): This provides consumers with the ability to deploy applications created or acquired by the consumer using programming languages ​​and tools supported by the provider onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they have control over the deployed applications and the configuration of any application hosting environment.

[0035] Infrastructure as a Service (IaaS): The capabilities offered to consumers are processing, storage, networking, and other basic computing resources that enable consumers to deploy and run arbitrary software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but rather have control over the operating system, storage, deployed applications, and potentially limited control over selected networking components (e.g., host firewalls).

[0036] The deployment model is as follows:

[0037] Private cloud: A cloud infrastructure that operates solely for an organization. It can be managed by the organization or a third party and can exist on-site or off-site.

[0038] Community cloud: A cloud infrastructure shared by several organizations and supporting a specific community with shared concerns (e.g., tasks, security requirements, policies, and compliance considerations). It can be managed by an organization or a third party and can exist on-site or off-site.

[0039] Public cloud: Makes cloud infrastructure available to the public or large industry groups and is owned by an organization that sells cloud services.

[0040] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain a single entity but are bound together by standardized or proprietary technologies that enable data and applications to be ported (e.g., cloud bursting for load balancing between clouds).

[0041] Cloud computing environments are service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure comprising a network of interconnected nodes.

[0042] See now Figure 1 The diagram illustrates an example of a cloud computing node. Cloud computing node 10 is merely one example of a suitable cloud computing node and is not intended to impose any limitation on the use or scope of functionality of the embodiments of the invention described herein. In any case, cloud computing node 10 can be implemented and / or perform any of the functions set forth above.

[0043] Within cloud computing node 10, there exists a computer system / server 12 that can operate alongside many other general-purpose or special-purpose computing system environments or configurations. Examples of known computing systems, environments, and / or configurations that may be suitable for computer system / server 12 include, but are not limited to, personal computer systems, server computer systems, thin clients, fat clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the aforementioned systems or devices.

[0044] Computer system / server 12 can be described in the general context of computer system executable instructions (e.g., program modules) executed by the computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer system / server 12 can be implemented in a distributed cloud computing environment, where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules can reside in local and remote computer system storage media, including memory storage devices.

[0045] like Figure 1 As shown, the computer system / server 12 in cloud computing node 10 is illustrated in the form of a general-purpose computing device. The components of the computer system / server 12 may include, but are not limited to, one or more processors or processing units 16, system memory 28, and a bus 18 that couples the various system components, including the system memory 28, to the processor 16.

[0046] Bus 18 represents any one or more of several types of bus architectures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses using any of the various bus architectures. By way of example and not limitation, such architectures include Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses.

[0047] Computer system / server 12 typically includes various computer system readable media. Such media can be any available media that can be accessed by computer system / server 12, and includes volatile and non-volatile media, removable and non-removable media.

[0048] System memory 28 (or memory subsystem 28) may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Cache memory 32 may include, for example, a shared cache (such as L2 cache) shared among multiple cores of processor 16 and / or may include a private cache (such as L1 cache). Computer system / server 12 may also include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown, and generally referred to as "hard disk drives"). Although not shown, disk drives for reading from or writing to removable non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable non-volatile optical disks (such as CD-ROMs, DVD-ROMs, or other optical media) may be provided. In such a case, each may be connected to bus 18 via one or more data media interfaces. As will be further described and illustrated below, system memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform embodiments of the present invention.

[0049] A program / utility 40 (e.g., P / U) having a set (at least one) of program modules 42 may be stored in system memory 28, as an example and not a limitation, along with an operating system, one or more applications, other program modules, and program data. Each or some combination of the operating system, one or more applications, other program modules, and program data may include an implementation of a network environment. Program modules 42 (“PM”) typically perform functions and / or methods as described herein in embodiments of the invention.

[0050] The computer system / server 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and / or with any device that enables the computer system / server 12 to communicate with one or more other computing devices (e.g., network interface card, modem, etc.). This communication can be performed via input / output (I / O) interface 22. Furthermore, the computer system / server 12 can communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), via network adapter 20. As shown, network adapter 20 communicates with other components of the computer system / server 12 via bus 18. It should be understood that, although not shown, other hardware and / or software components can be used in conjunction with the computer system / server 12. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, redundant array of independent disks (RAID) systems, tape drives, and data archiving storage systems.

[0051] See now Figure 2 The diagram illustrates an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 to which local computing devices used by cloud consumers can communicate. These local computing devices include, for example, PDAs or cellular phones 54A, desktop computers 54B, laptop computers 54C, and / or automotive computer systems 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platforms, and / or software as services that cloud consumers do not need to maintain on their local computing devices. It should be understood that... Figure 2 The types of computing devices 54A-54N shown are intended to be illustrative only, and computing node 10 and cloud computing environment 50 can communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0052] See now Figure 3 This demonstrates a cloud computing environment of 50 ( Figure 2 This provides a set of functional abstractions. It should be understood beforehand. Figure 3 The components, layers, and functions shown are intended to be illustrative only, and embodiments of the invention are not limited thereto. As described, the following layers and corresponding functions are provided:

[0053] Device layer 55 includes physical and / or virtual devices embedded with and / or independent electronics, sensors, actuators, and other objects to perform different tasks in cloud computing environment 50. Each device in device layer 55 integrates networking capabilities with other functional abstraction layers, enabling information obtained from the device to be provided to other functional abstraction layers, and / or information from other abstraction layers to be provided to the device. In one embodiment, the different devices including device layer 55 can be merged into a physical network collectively referred to as the “Internet of Things” (IoT). As those skilled in the art will understand, such a physical network allows for the interoperability, collection, and dissemination of data for a wide variety of purposes.

[0054] As shown, device layer 55 includes sensor 52, actuator 53, a “learning” thermostat 56 with integrated processing, sensor and network electronics, camera 57, controllable household socket / jack 58, and controllable electrical switch 59 as shown. Other possible devices may include, but are not limited to, various additional sensor devices, network devices, electronic devices (such as remote control devices), additional actuator devices, so-called “smart” appliances (such as refrigerators or washer / dryers), and a variety of other possible interconnected objects.

[0055] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: a mainframe 61; a RISC (Reduced Instruction Set Computer) based server 62; a server 63; a blade server 64; a storage device 65; and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0056] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 71; virtual storage device 72; virtual network 73, including virtual private network; virtual application and operating system 74; and virtual client 75.

[0057] In one example, management layer 80 may provide the following functionalities: Resource Provisioning 81 provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and Pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User Portal 83 provides access to the cloud computing environment for consumers and system administrators. Service Level Management 84 provides cloud resource allocation and management to ensure that required service levels are met. Service Level Agreement (SLA) Planning and Fulfillment 85 provides pre-scheduling and procurement of cloud resources, anticipating future requirements for those resources according to the SLA.

[0058] Workload layer 90 provides examples of functions that can leverage a cloud computing environment. Examples of workloads and functions that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics processing 94; transaction processing 95; and, in the context of the embodiments illustrated in this invention, various workloads and functions 96 for dynamically allocating bandwidth among queues of switch ports in a cloud network switch. Furthermore, the workloads and functions 96 for dynamically allocating bandwidth among queues of switch ports in a cloud network switch may include operations such as analytics, analysis, and detection and comparison functions as will be further described. Those skilled in the art will understand that the workloads and functions 96 for dynamically allocating bandwidth among queues of switch ports in a cloud network switch can also work in conjunction with other parts of different abstraction layers (such as hardware and software layer 60, virtualization layer 70, management layer 80, and other abstraction layers 90 such as, for example, data analytics processing 94) to achieve the different objectives of the embodiments illustrated in this invention.

[0059] As previously indicated, the present invention provides dynamic bandwidth allocation in cloud network elements within a cloud computing environment. Quality of Service (QoS) policies can be dynamically changed across one or more cloud network switches based on dynamically estimated expected service demands for each of multiple service categories, wherein bandwidth is dynamically allocated among queues based on the changed QoS policies.

[0060] Now go to Figure 4 An example of a system 400 including a network 401 supporting Software-Defined Networking (SDN) will now be described in more detail. Figure 4In the example shown, system 400 is an enterprise system comprising multiple servers 402 and client systems 404 configured to communicate over network 401 using a switch 406 with SDN capabilities (e.g., OpenFlow compatible). Therefore, network 401 can also be referred to as enterprise network 401 and can be geographically distributed across multiple physical locations. In the exemplary embodiment, server 402, also referred to as a host or host system, is a high-speed processing device (e.g., mainframe, desktop computer, laptop computer, handheld device, embedded computing device, etc.) comprising at least one processing circuitry (e.g., computer processor / CPU) capable of reading and executing instructions and handling interactions with different components of system 400. One or more of servers 402 may be storage system servers configured to access large amounts of data and store large amounts of data to one or more data storage systems 408. Server 402 may also be a computing node comprising one or more workload managers 420, subroutines 422, and other applications (not shown).

[0061] Client system 404 may include various desktop computers, laptop computers, general-purpose computer equipment, mobile computing devices, and / or networked devices with processing circuitry and input / output (I / O) interfaces, such as buttons, touchscreens, audio inputs, display devices, and audio outputs. Client system 404 may be directly linked to one or more switches 406 or wirelessly linked via one or more wireless access points 410.

[0062] Data storage system 408 refers to any type of computer-readable storage medium and may include one or more auxiliary storage elements, such as hard disk drives (HDDs), solid-state storage, magnetic tape, or storage subsystems internal or external to server 402. Types of data that can be stored in data storage system 408 include, for example, various files and databases. Multiple data storage systems 408 may exist and be utilized by one or more of the servers 402, and these multiple data storage systems 408 may be distributed across various locations within system 400.

[0063] System 400 also includes an SDN controller 410, which is a central software-defined network controller configured to make routing decisions within network 401. SDN controller 412 establishes secure links 403 and configures the communication attributes of links 405 between switches 406 and 406. For example, SDN controller 412 can configure switch 406 to control packet routing paths for data flows between server 402 and client system 404, and between one or more firewalls 414 and one or more load balancing networks 418. One or more firewalls 414 restrict access to and flow of network traffic between network 401 and one or more external networks 418. One or more load balancing networks 418 can distribute workloads across multiple computers, such as between server 402. SDN controller 412 can also configure switch 406 to define flows between server 402, programs (e.g., virtual machines), and subroutines 422 running on server 402.

[0064] Server 402, client system 404, and SDN controller 412 may include various computer / communication hardware and software technologies known in the art, such as one or more processing units or circuits, volatile and non-volatile memory (including removable media), power supply, network interface, support circuitry, operating system, etc. Although SDN controller 412 is described as a separate component, it should be understood that network configuration functions may optionally be implemented in one or more servers 402 or client systems 404 in a separate or distributed format.

[0065] Network 401 may include a combination of wireless, wired, and / or fiber optic links. For example... Figure 4 The network 401 shown represents a simplified example for illustrative purposes. For example, each link 405 depicted in network 401 may include more than one physical link. Embodiments of network 401 may include multiple switches 406 (e.g., hundreds), each with dozens of ports and links. Switches 406 are also commonly referred to as network resources and can represent any type of device capable of forwarding data through one or more ports. Network 401 may support a variety of known communication standards that allow data to be transmitted between server 402, client system 404, switch 406, SDN controller 412, firewall(s) 414, and / or load balancers(s) 416. Communication protocols are typically implemented at one or more layers, such as the physical layer (layer 1), link layer (layer 2), network layer (layer 3), transport layer (layer 4), and application layer (layer 5). In an exemplary embodiment, network 401 supports SDN as a layer 2 protocol. Switches 406 may be dedicated SDN switches or general-purpose SDN-enabled switches that also support Layer 2 and Layer 3 Ethernet.

[0066] In an exemplary embodiment, one of the servers 402 is an enterprise server 402 operable for configuring the SDN controller 412. A secure link 403 can be used between the enterprise server 402 and the SDN controller 412. The SDN controller 412 can aggregate and distribute flows and manage interactions. The SDN controller 412 can also list default quality of service requirements, such as end-to-end latency and bandwidth requirements, as well as other requirements based on each link, such as jitter. The SDN controller 412 can perform initial allocation and provisioning based on business needs and service categories.

[0067] Turn now Figure 5 A block diagram of an exemplary functional component 500 according to various mechanisms of the illustrated embodiments is shown. Figure 5 A system 500 for dynamic bandwidth allocation in a cloud network switch in a cloud computing environment is shown. In one aspect, Figures 1-4 One or more of the components, modules, services, applications, and / or functions described herein can be used Figure 5 In one respect, for the sake of brevity, descriptions of other embodiments described herein (e.g., Figures 1-4 Repeated descriptions of similar elements, components, modules, services, applications, and / or functions used in the document.

[0068] In view of the foregoing, according to the present invention, module / component block 500 can also be incorporated into different hardware and software components of a system for dynamic bandwidth allocation (e.g., dynamically changing Quality of Service "QoS" policies) in a cloud network switch in a cloud computing environment. Many functional blocks in functional block 500 can be executed as background processes on different components, in a distributed computing component, on a user device, or elsewhere.

[0069] Figure 1 The computer system / server 12 is shown as including a dynamic bandwidth allocation service 510. According to various aspects of the invention, the dynamic bandwidth allocation service 510 may include a processor 520 and a memory 530 to perform various computational, data processing, and other functions. The dynamic bandwidth allocation service 510 may be provided by... Figure 1 The computer system / server 12 is provided.

[0070] As those skilled in the art will understand, the depiction of the different functional units in the dynamic bandwidth allocation service 510 is for illustrative purposes, as the functional units may be located within the dynamic bandwidth allocation service 510, or elsewhere within and / or between distributed computing components.

[0071] In one aspect, the computer system / server 12 and / or the dynamic bandwidth allocation service 510 can provide virtualized computing services (i.e., virtualized computing, virtualized storage, virtualized networking, etc.). More specifically, the dynamic bandwidth allocation service 510 can be provided and / or included in virtualized computing, virtualized storage, virtualized networking, and other virtualization services executed on the hardware substrate.

[0072] In one respect, the dynamic bandwidth allocation service 510 can be provided and / or associated with the QoS component 540, the service category component 550, the configuration component 560, and the allocation component 570, each of which can communicate with each other.

[0073] In one aspect, a dynamic bandwidth allocation service 510 using one or more of QoS component 540, service category component 550, configuration component 560 and allocation component 570 can dynamically change the Quality of Service (QoS) policy in one or more cloud network switches based on the expected service requirements for each of the multiple service categories, wherein bandwidth is dynamically allocated among queues on the cloud network switches based on the dynamically changed QoS policy.

[0074] In one aspect, using one or more of the QoS component 540, service category component 550, and configuration component 560, the dynamic bandwidth allocation service 510 can determine service requirements based on the scheduling of one or more virtual entities by multiple overlay network controllers.

[0075] In one aspect, using one or more of QoS component 540, service category component 550, and configuration component 560, dynamic bandwidth allocation service 510 can use knowledge of topology and routing in the computing network to map service requirements to network elements; and based on this mapping, monitor and identify network elements that conflict with one or more of the QoS policies.

[0076] The QoS component 540 associated with the configuration component 560 can switch or adjust the QoS policy based on expected service requirements.

[0077] In one aspect, using one or more of QoS component 540, service category component 550, and configuration component 560, dynamic bandwidth allocation service 510 can determine the maximum amount of service demand for each of multiple service categories by determining the number of one or more virtual entities executed on one or more computing servers.

[0078] In some implementations, configuration component 560 can configure multiple network elements based on dynamically changing QoS policies.

[0079] In other implementations, regarding dynamically changing QoS policies in one or more cloud network switches based on anticipated service demands, using one or more of QoS component 540, service category component 550, and configuration component 560, dynamic bandwidth allocation service 510 can determine that service demands for each of multiple service categories exceed a predetermined service threshold; and dynamically allocate bandwidth among queues on the cloud network switch to enable processing and service service demands based on QoS policies.

[0080] To further explain, Figure 6 This is a block diagram depicting the operation of dynamic bandwidth allocation in a cloud network switch in a cloud computing environment based on business demand predictions according to an embodiment of the present invention.

[0081] In other words, Figure 6 This is a block diagram depicting a backbone / leaf network 600 with an equal cost multipath (“ECMP”) protocol operating between backbone switches and leaf switches (e.g., backbone switch 652A-M and leaf switch 642A-D). In one aspect, Figures 1-5 One or more of the components, modules, services, applications, and / or functions described herein can be used Figure 6 In one respect, for the sake of brevity, descriptions of other embodiments described herein (e.g., Figures 1-5 Repeated descriptions of similar elements, components, modules, services, applications, and / or functions used in the document. In some implementations, a data center network with a backbone / leaf network 600 topology may be assumed, such as backbone switch 652A-M in network 630, for example, but other network topologies may also be applied.

[0082] like Figure 6 As shown, the three servers are comprised in rack 1 (RACK1) (i.e., rack 640A), and the overall composition of rack 1 changes beyond a pre-established threshold. As a result, one or more QoS policies on all ports associated with them are modified (e.g., all ports shown as black dots, such as those of leaf switches 642A and backbone switches 652A-M, and ports shown as transparent dots, such as those of leaf switches 642A and 642D). The QoS policies in some ports (e.g., transparent dots such as those of leaf switches 642A and 642D) are based on the server service composition. Similarly, the QoS policies in some ports (e.g., all ports shown as black dots, such as those of leaf switches 642A and backbone switches 652A-M) reflect changes in aggregated rack services.

[0083] Therefore, this invention (such as using a backbone / leaf network 600) provides dynamically changing QoS policies in cloud network switches within a cloud computing network 630 based on the demand expectations of each service category (TC). Figure 6 As shown, the underlying cloud network controller 610 (e.g., an underlying SDN controller) and the overlay cloud network controller 620 (e.g., an overlay SDN controller) and the communication between them are illustrated. The underlying cloud network controller 610 and the overlay cloud network controller 620 may be co-located and / or incorporated into a single network stack. The underlying cloud network controller 610 has visibility into the topology of the cloud computing network 630 and the routing between servers in the network 630, and has the ability to update the service processing behavior on the network switches.

[0084] The overlay cloud network controller 620 may include all the necessary information to generate the expected business requirements for each business category (“TC”) on each server (e.g., servers in each of the server racks 640A-640D). These expected requirements may be calculated based on the virtual machine (“VM”) profiles that can be executed / run on the server racks 640A-640D.

[0085] For example, each of the VMs of a given type hosted on a server (e.g., one of the servers on racks 640A-640D) can be used as the expected tenant business requirement for that given VM type. Additionally, if one of the business categories is storage, the maximum amount of business allocated to the server (e.g., one of the servers on racks 640A-640D) can be calculated by summing the storage requirements of all VMs running on the server (e.g., one of the servers on racks 640A-640D) using the upper limit of virtual disk input / output operations per second (“IOPS”). This information can be aggregated at the rack level by summing the expected requirements for a given category across all servers in the rack (e.g., each server on one or more of racks 640A-640D).

[0086] The overlay cloud network controller 620 periodically notifies the underlying cloud network controller 610 of changes in expected demand per TC due to the arrival and / or departure of virtual entities (e.g., VMs, virtual NICs, and virtual disks). For example, if k service categories are supported, the underlying cloud network controller 610 maintains the expected demand for each of the k categories based on the network 630 resources allocated to the virtual entities running on each server (e.g., one or more servers on one or more racks 640A-640D).

[0087] The underlying cloud network controller 610 tracks the server-level and rack-level requirements for each service category (e.g., one or more servers on one or more racks 640A-640D) and can map multiple service categories to output queues at switch ports.

[0088] This mapping from service categories to output queues is configurable. The underlying cloud network controller 610 also maintains a QoS profile for each port in the network 630. The port's QoS profile reflects how much switch resources should be allocated to the processing traffic of each output queue. Therefore, the QoS policy determines how the switch handles traffic from each category.

[0089] In some implementations, QoS policies at switch ports can use round-robin scheduling to allocate scheduler time to each output queue. QoS policies can be defined based on the expected demand for each output queue, using caps or reservations that reflect user preferences for services. For example, for illustrative purposes, assuming a port speed of 100 gigabytes per second (Gbps), if the underlying cloud network controller 610 knows that the demand mapped to i service calls never exceeds piGbps, then the resource allocation for the i service call queue pairs can be configured as pi%, where i is a positive integer.

[0090] For example, a QoS policy can assign the following percentages [p1, p2, p3, p4, p5, p6, p7, p8], where p1 + ... + p8 equals 100%. If the expected traffic volume mapped to the queue changes, the QoS profile can be modified to reflect the change. This mapping of traffic categories to output queues and then to resource allocation can be managed by the underlying cloud network controller 610. Initially, all queues across all underlying switches can be allocated to evenly share available resources among TCs.

[0091] As the composition of business requirements changes in the cloud network, leading to changes in expected requirements, the proposed invention correspondingly modifies the QoS policy at the port. The underlying cloud network controller 610 identifies servers (e.g., one or more servers on one or more racks 640A-640D) whose business composition has changed beyond an established threshold compared to the last update from the overlay cloud network controller 620.

[0092] The goal is to avoid updating and modifying minor changes when there are significant differences in the service composition. Assuming k service categories, the calculation involves comparing two vectors. For example, this identification could be based on a heuristic approach, such as labeling ports whose demand for any service category has doubled or halved. The sensitivity of this calculation can be tuned based on the needs of network 630. When the overlay cloud network controller 620 notifies the underlying cloud network controller 610, the underlying cloud network controller 610 performs the following actions: In step 1a, a group of servers S whose service composition has changed by more than an established threshold compared to the last update can be identified. In step 1b), for each port on a leaf switch, for example, on one of leaf switches 642A-D connected to the servers in S, the egress QoS policy can be modified to reflect the new composition. In step 2a), a group of racks R (e.g., one of server racks 640A-640D) whose service composition has changed by more than an established threshold compared to the last update can be identified. In step 2b), for each leaf I of the rack connected to R, the QoS policy can be changed on the port facing the backbone switch to reflect the new QoS policy on each backbone (e.g., each of the backbone switches 652A-M), and the QoS policy can be changed on the port I to reflect the new QoS policy.

[0093] like Figure 6 The diagram illustrates an exemplary backbone / leaf network with an Equal Cost Multipath (ECMP) protocol running between backbone and leaf switches. In this example, the composition of the three servers in rack 1, as well as the overall composition of rack 1, changes exceed a pre-established threshold. Therefore, the QoS policies on all ports shown (e.g., one of server racks 640A-640D, 642A, and each of backbone switches 652A-M) are modified. The QoS policies on the orange ports are based on the server service composition of each step 1a. Similarly, the QoS policies on the red ports reflect changes in aggregated rack services according to step 2b.

[0094] QoS policy changes can be applied in predefined discrete steps and are triggered only when certain thresholds are exceeded. The logic used to adjust thresholds or trigger QoS policy changes in switch ports can take into account real-time information, i.e., when packet loss occurs in certain service categories or in the traffic flow of a sampled real-time communication mechanism. QoS policies can be adjusted for service categories that are regularly exceeding their assigned limits.

[0095] Turn now Figure 7The document describes a method 700 for dynamic bandwidth allocation in a cloud network switch in a cloud computing environment, executed by a processor, wherein aspects of the illustrated embodiments may be implemented. Function 700 may be implemented as a method executable as instructions on a machine, wherein the instructions are included on at least one computer-readable medium or a non-transitory machine-readable storage medium. Function 700 may begin at block 702.

[0096] Quality of Service (QoS) policies can be dynamically changed across one or more cloud network switches based on dynamically estimated expected service demands for each of multiple service categories, where bandwidth is dynamically allocated among queues based on the changed QoS policies, as shown in box 704. As shown in box 706, bandwidth across one or more cloud network switches can be dynamically allocated based on dynamically changing QoS policies. Function 700 may end, as shown in box 708.

[0097] In one respect, combination Figure 7 The operation of method 700 may include each of the following, as part of at least one box and / or at least one box: The operation of method 700 may determine service requirements based on communication with an overlay controller that schedules one or more virtual entities. The operation of method 700 may map service requirements from one or more computing servers to network elements using topology and routing in the computing network; and monitor and identify network elements that conflict with one or more QoS policies based on the mapping.

[0098] Method 700 can switch or adjust QoS policies based on anticipated service demands. Method 700 can determine the maximum amount of service demand for each of multiple service categories by determining the number of one or more virtual entities running on one or more computing servers and using the configuration files of one or more virtual entities. Method 700 can configure multiple network elements based on dynamically changing QoS policies. In association with dynamically changing QoS policies in one or more cloud network switches based on anticipated service demands, Method 700 can determine that: service demand for each of multiple service categories exceeds a predetermined service threshold; and dynamically allocate network resources (e.g., bandwidth) to one or more cloud network elements to enable processing and serving service demands based on QoS policies.

[0099] Method 700 can switch or adjust QoS policies based on anticipated service demands. Method 700 can determine the maximum service demand for each of multiple service categories by determining the number of one or more virtual entities executing on one or more computing servers. Method 700 can configure multiple network elements based on dynamically changing QoS policies. Method 700 can determine that the service demand for each of multiple service categories exceeds a predetermined service threshold; and dynamically allocate bandwidth among queues on cloud network switches to enable processing and service of service demands based on QoS policies.

[0100] Method 700 can determine that one or more virtual entities are scheduled or removed for execution on one or more cloud network switches; and based on the determination that one or more virtual entities are scheduled or removed, reserve or release one or more network elements and resources for the service requirements of each of the multiple service categories.

[0101] This invention can be an apparatus, system, method, and / or computer program product. A computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to execute aspects of the invention.

[0102] Computer-readable storage media can be tangible means for retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital universal disk (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or protrusions in slots having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0103] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the suitable computing / processing device.

[0104] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and conventional procedural programming languages ​​(such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as a standalone software package, partially on a user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)) or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may be personalized to execute computer-readable program instructions by utilizing state information from the computer-readable program instructions in order to perform aspects of this invention.

[0105] The present invention will now be described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0106] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more boxes of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner, such that the computer-readable storage medium storing the instructions includes an article of manufacture containing instructions that implement aspects of the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0107] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, such that the instructions that execute on the computer, other programmable apparatus, or other device perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0108] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions marked in the blocks may occur in a non-linear order. For example, depending on the functions involved, two consecutively shown blocks may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

Claims

1. A method for dynamic bandwidth allocation in a cloud network element in a cloud computing environment, the method being executed by a processor, the method comprising: The Quality of Service (QoS) policy in one or more cloud network switches is dynamically modified based on the expected service demand of each of multiple service categories, wherein the bandwidth is dynamically allocated among queues based on the modified QoS policy. Changing the QoS policy includes: Change the QoS policy associated with the port of the leaf switch of the one or more cloud network switches, and After changing the QoS policy associated with the port of the leaf switch, change the QoS policy associated with the port of the backbone switch associated with the one or more cloud network switches.

2. The method of claim 1, further comprising determining the expected service requirements based on communication with an overlay controller that schedules one or more virtual entities.

3. The method according to claim 1, further comprising: Use the topology and routing in the computing network to map service requests from one or more computing servers to network elements; as well as Based on the mapping, network elements that conflict with one or more of the QoS policies are monitored and identified.

4. The method according to claim 1, further comprising: By determining the number of one or more virtual entities executed on one or more computing servers, and using the configuration files of the one or more virtual entities, the maximum amount of the business demand for each of the plurality of business categories is determined.

5. The method according to claim 1 further includes configuring multiple network elements based on dynamically changing the QoS policy.

6. The method according to claim 1, wherein, The ability to dynamically change the QoS policy in one or more cloud network switches based on anticipated business needs also includes: Determining that the business demand for each of the plurality of business categories exceeds a predetermined business threshold; and Network resources are dynamically allocated to the one or more cloud network elements to enable the processing and service of service requirements based on the QoS policy.

7. A system for dynamic bandwidth allocation in cloud network elements within a cloud computing environment, the system comprising: One or more computers having executable instructions that, when executed, cause the system to perform the method as described in any one of claims 1-6.

8. A computer program product for dynamic bandwidth allocation in a cloud network element in a cloud computing environment, the computer program product comprising: Program instructions that can be executed by a processor to cause the processor to perform the method of any one of claims 1-6.

Images