Patent Application
20190182980
A data center is a facility used to house computer systems and associated components, such as telecommunications and storage systems. It generally includes redundant or backup power supplies, redundant data communications connections, environmental controls (e.g., air conditioning, fire suppression) and various security devices. A large data center can consume significant amount of electricity. Most of the equipment is often in the form of server computers (“servers”) mounted in rack cabinets (“racks”), which are usually placed in multiple rows. Different types of racks consume different amounts of resources. For example, a first type of rack can consume 4 Kilo Watts (KW) of power supply, 5 units of airflow, 2 cubic feet per minute (CFM) of cooling, 10 Gigabits per second (Gbps) of network traffic, a second rack type can consume 2 KW of power supply, 3 units of airflow, 4 CFM of cooling, 7 Gbps of network traffic, and so on.
If the racks are not deployed in an appropriate manner, the resource utilization in the data center may not be uniform. Such an imbalance in resource utilization can cause a failure or increase the likelihood of a failure of one or more servers. For example, if a total power supply available for a row is 50 KW and all high power consumption rack types are deployed in the row, whose power consumption is likely to exceed 50 KW, then a power breaker of the row may be triggered causing the racks in the row to lose power. In another example, if all high heat generating racks are placed in a row where there is no sufficient airflow, excessive heat may cause failures in the rack. Accordingly, if the racks are not deployed in appropriate manner, the resource utilization across the data center may be imbalanced, which can cause a failure or increase the likelihood of a failure of the servers in the data center.
Embodiments are directed to placement of server racks of different types in a data center for efficient allocation of resources to the servers. A data center has limited physical resources (e.g., electrical power, cooling, airflow, network bandwidth, weight capacity, etc.). Various server rack types (e.g., hosting a type of a server computer) consume different amounts of these resources. If the distribution of server rack types in a data center is imbalanced, various unexpected failures can occur. Embodiments consider resource utilizations of all server rack types and generate a deployment layout that assigns these server rack types across multiple rows of the data center to ensure a deployment constraint of the data center is satisfied. For example, a deployment constraint for an efficient allocation of the resources can be that within every row of server racks, a percentage of a total available power supply consumed be substantially constant. For example, if in a first row 80% of the available 100 KW of power supply is consumed by the various types of server racks, then in a second row that has 50 KW of power supply available, the server racks of various types are to be deployed such that be 80% of the 50 KW power supply is consumed. One way to achieve the above resource utilization is that the deployment constraint can be further defined such that within every row of server racks, the percentage of each server rack type is substantially constant. For example, if 10% of a first row has a first server rack type, then 10% of a second row has first server rack type, etc. What is determined as substantially constant can be configured, e.g., by an administrator. For example, if the difference between two percentages is within a specified range, e.g., 2-3%, then the two percentages can be considered to be substantially equal or substantially constant.
After the server racks are deployed, e.g., based on the deployment layout determined as described above, application services that are run on these server racks can also be distributed across specific server racks, e.g., based on resource consumption of the application services. The application services can be bucketed or categorized into various categories or buckets based on their resource consumption. Application services from each bucket are distributed in a similar manner as the server rack types across the data center.
In some embodiments, a server rack (“rack”) is a framework in which multiple server computers (“server”) are installed. The rack contains multiple mounting slots using which the multiple servers can be stacked one above the other, consolidating network resources and minimizing the required floor space. In some embodiments, in a rack filled with multiple servers, a cooling system may be necessary to prevent excessive heat buildup that would otherwise occur when many power-dissipating components are confined in a small space. Note that the term server rack can also be used to refer to servers in the rack, and a rack type to refer to type of the servers in the rack.
Turning now to figures,
The deployment server 150 can generate a recommendation, e.g., the deployment layout 140, for arranging the racks 125 in a specific manner so that the resource utilization is balanced in the data center 105. The deployment layout 140 typically assigns the racks 125 of various types across multiple rows 110 of the data center 105 to ensure a deployment constraint 160 of the data center 105 is satisfied. In some embodiments, the deployment constraint 160 is a condition that may have to be satisfied in order for the resource utilization to be balanced across the data center 105. For example, the deployment constraint 160 can be that in every row of the data center a percentage of a row's total available power supply consumed by the racks in that row should be substantially constant across the rows 110. The deployment layout 140 typically includes the types of racks and the number of racks of each type to be placed in a row for every row of the data center 105.
The input parameters 135 considered by the deployment server 150 for generating the deployment layout 140 can include the rack types and a number of racks of each rack type to be deployed in the data center 105. The input parameters 135 may be sent to the deployment server 150 by a user, e.g., an administrator of the data center 105, using a client device 130. For example, upon receiving a request from the client device 130 for generating a deployment layout, the deployment server 150 can generate a graphical user interface (GUI) at the client device using which the user can input the input parameters 135. The deployment server 150 can retrieve the resource consumption parameters 155 associated with each of the rack types and the deployment constraint 160 from a storage system 145. The deployment server 150 can then generate the deployment layout 140 based on the input parameters 135, the resource consumption parameters 155 of the rack types and the deployment constraint 160.
In some embodiments, the deployment server 150 can employ various algorithms to generate the deployment layout 140, e.g., determine the number of racks of each type to be deployed in a row of the data center 105, based on the deployment constraint 160 and the resource consumption parameters 155. For example, consider that a first rack type 215 can consume 2 KW of power supply, 1 CFM of cooling, 10 Gbps of network traffic, a second rack type 220 can consume 4 KW of power supply, 2 CFM of cooling, 5 Gbps of network traffic, and a third rack type 225 can consume 8 KW of power supply, 3 CFM of cooling, and 5 Gbps of network traffic. Further, consider that the maximum available power supply in the first row is 100 KW. In one example, in generating the deployment layout 140, the deployment server 150 can employ an algorithm to determine a combination of rack servers of the three types to be deployed in the first row 205 such that a total power supply consumed by the combination of rack servers does not exceed 100 KW. The deployment server 150 can arrive at the number of racks considering all necessary inputs, e.g., a total number of racks requested, number of racks of each rack type, number of rows, number of racks per row, power supply for each row and resource consumption parameters of various rack types. Assuming that the deployment server 150 arrives at a, b and c numbers of racks of the three types, respectively, then the deployment server 150 determines a percentage of the first rack type 215 is x % ((a/a+b+c)*100). The deployment server 150 can then determine that other rows of the data center 105 should also have the first type rack as x % of the total number of racks in the corresponding row.
Note that the deployment layout 140 generated in the above example, considers power supply as one of the deployment constraints 160 so that power consumption by the server racks is balanced across the data center 105. In some embodiments, the deployment constraint 160 can consider other resource consumption parameters instead of or in addition to the power supply parameter so that the consumption of one or more resources is balanced across the data center 105.
The application services can be associated with resource consumption indicators, which indicate a level of consumption of a specified resource. For example, resource consumption indicators for power consumption can be “high power” and “low power.” Similarly, the resource consumption indicators for network traffic can be “high traffic” and “low traffic.” Note that the level of consumption of a specified resource in the above examples is represented using two values “high” and “low.” However, the level of consumption can be indicated in various other ways, e.g., as a range, more than two values, etc.
A user can input information such as application identification (ID) of the application services 305, rack type required for the application services 305, resource consumption indicators associated with the application services 305, etc. as input data 310. The deployment server 150 categorizes the application services 305 based on the resource consumption indicators of the application services 305 into multiple categories 315 in which each category is a characteristic of a level of consumption of a specified resource. For example, consider that the user has requested a first rack type 215 for the application services 305, and consider that the categories 315 are “high power,” “high traffic,” “low traffic,” “high CFM,” and “low airflow.” The deployment server 150 analyzes the resource consumption indicators of each of the application services 305 and categorizes the corresponding application service into one of the categories 315 based on the matching resource consumption indicator of the corresponding application service. For example, a first application service that is associated with a “high power” resource consumption indicator is categorized into the “high power” category. After each of the application services 305 is categorized into one of the categories 315, the deployment server 150 generates an application deployment layout 320 based on a distribution criterion to assign the application services from each of the categories 315 to racks of the first rack type 215 deployed in different rows. In some embodiments, the deployment server 150 assigns the application services from each of the categories 315 to different rows of the first rack type 215 racks in a manner similar to the deployment of the racks 125 in the data center 105. The deployment server 150 identifies the racks of the first rack type 215 in the data center 105 based on the deployment layout 140 and distributes the application services from each of the categories 315 based on the distribution criterion. For example, the distribution criterion can indicate that within every row that has the first rack type 215, a percentage of application services hosted by the first rack type 215 that are from a specified category should be substantially constant. For example, if 20% of the application services hosted by the first rack type 215 in the first row 205 are from a “high power” category, then the percentage of the application services hosted by the first rack type 215 in the second row 210 from the “high power” category should also be substantially equal to 20% of all the application services hosted by the first rack type 215 in the second row 210.
In another embodiment, the distribution criterion can indicate that the deployment server 150 is to distribute substantially equal percentage of the application services from a category across the multiple rows in which racks of the first rack type 215 are deployed. For example, if the racks of the first rack type 215 there are deployed in five rows, then each of the five rows hosts 20% of the application services from a specified category. The deployment server 150 continues to distribute application services from each of the categories 315 in the above described manner.
The deployment server 150 includes a deployment constraint component 410 that can be used to retrieve, define, and/or customize the deployment constraint 160, which can be used as a constraint in determining the deployment of the racks 125 in the data center 105.
The deployment server 150 includes a distribution constraint component 415 that can be used to retrieve, define, and/or customize the distribution constraint, which can be used as a constraint in determining the distribution of application services 305 to the racks 125 in the data center 105.
The deployment server 150 includes a layout generation component 420 that can be used to generate a deployment layout 140, which assigns the racks 125 of different types across multiple rows in the data center 105 ensuring that a deployment constraint is satisfied. The layout generation component 420 can also be used to generate the application deployment layout 320, which can be used to distribute application services 305 across specific server racks, e.g., based on resource consumption of the application services 305, so that the resource consumption by the application services 305 is balanced or uniform across the data center. Additional details with respect to the above components are described at least with reference to
At block 515, the data receiving component 405 retrieves the resource consumption parameters for each of the rack types, e.g., rack type specified in the input parameters, from a storage system associated with the deployment server 150. Examples of the resource consumption parameters 155 include a power supply consumed by the rack, airflow consumed by the rack, cooling units consumed by the rack, network traffic consumed by the rack, weight of the rack, etc. Different rack types can consume different amounts of the resources.
At block 520, the deployment constraint component 410 retrieves the deployment constraint, e.g., as described at least with reference to
At block 525, the layout generation component 420 generates the deployment layout 140 based on the deployment constraint 160, e.g., as described above at least with reference to
At block 615, the layout generation component 420 assigns each of the application services 305 to one of the multiple categories 315 based on the resource consumption indicators of the application services 305, e.g., as described at least with reference to
At block 620, the layout generation component 420 then assigns the application services from each of the categories 315 to various racks of a specified type based on a distribution criterion, e.g., as described at least with reference to
The memory 710 and storage devices 720 are computer-readable storage media that may store instructions that implement at least portions of the described embodiments. In addition, the data structures and message structures may be stored or transmitted via a data transmission medium, such as a signal on a communications link. Various communications links may be used, such as the Internet, a local area network, a wide area network, or a point-to-point dial-up connection. Thus, computer readable media can include computer-readable storage media (e.g., “non-transitory” media).
The instructions stored in memory 710 can be implemented as software and/or firmware to program the processor(s) 705 to carry out actions described above. In some embodiments, such software or firmware may be initially provided to the processing system 700 by downloading it from a remote system through the computing system 700 (e.g., via network adapter 730).
The embodiments introduced herein can be implemented by, for example, programmable circuitry (e.g., one or more microprocessors) programmed with software and/or firmware, or entirely in special-purpose hardwired (non-programmable) circuitry, or in a combination of such forms. Special-purpose hardwired circuitry may be in the form of, for example, one or more ASICs, PLDs, FPGAs, etc.
The above description and drawings are illustrative and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding of the disclosure. However, in some instances, well-known details are not described in order to avoid obscuring the description. Further, various modifications may be made without deviating from the scope of the embodiments. Accordingly, the embodiments are not limited except as by the appended claims.
Reference in this specification to “one embodiment” or “an embodiment” means that a specified feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
The terms used in this specification generally have their ordinary meanings in the art, within the context of the disclosure, and in the specific context where each term is used. Terms that are used to describe the disclosure are discussed below, or elsewhere in the specification, to provide additional guidance to the practitioner regarding the description of the disclosure. For convenience, some terms may be highlighted, for example using italics and/or quotation marks. The use of highlighting has no influence on the scope and meaning of a term; the scope and meaning of a term is the same, in the same context, whether or not it is highlighted. It will be appreciated that the same thing can be said in more than one way. One will recognize that “memory” is one form of a “storage” and that the terms may on occasion be used interchangeably.
Consequently, alternative language and synonyms may be used for any one or more of the terms discussed herein, nor is any special significance to be placed upon whether or not a term is elaborated or discussed herein. Synonyms for some terms are provided. A recital of one or more synonyms does not exclude the use of other synonyms. The use of examples anywhere in this specification including examples of any term discussed herein is illustrative only, and is not intended to further limit the scope and meaning of the disclosure or of any exemplified term. Likewise, the disclosure is not limited to various embodiments given in this specification.
Those skilled in the art will appreciate that the logic illustrated in each of the flow diagrams discussed above, may be altered in various ways. For example, the order of the logic may be rearranged, substeps may be performed in parallel, illustrated logic may be omitted; other logic may be included, etc.
Without intent to further limit the scope of the disclosure, examples of instruments, apparatus, methods and their related results according to the embodiments of the present disclosure are given below. Note that titles or subtitles may be used in the examples for convenience of a reader, which in no way should limit the scope of the disclosure. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. In the case of conflict, the present document, including definitions will control.
