BACKGROUND

Field of the Invention

At least one embodiment in accordance with the present invention relates generally to systems and methods for data center management and design, and more specifically, to systems and methods for managing data center airflow and energy usage and for arranging equipment in a data center based on airflow and energy usage.

Discussion of Related Art

In response to the increasing demands of information-based economies, information technology networks continue to proliferate across the globe. One manifestation of this growth is the centralized network data center. A centralized network data center typically consists of various information technology equipment, collocated in a structure that provides network connectivity, electrical power and cooling capacity. Often the equipment is housed in specialized enclosures termed "racks" which integrate these connectivity, power and cooling elements. In some data center configurations, these racks are organized into rows and clusters having hot and cold aisles to decrease the cost associated with cooling the information technology equipment. These characteristics make data centers a cost effective way to deliver the computing power required by many software applications.

Various processes and software applications, such as the InfraStruxure® family of products available from American Power Conversion by Schneider Electric (APC) of West Kingston, RI, have been developed to aid data center personnel in designing and maintaining efficient and effective data center configurations. These tools often guide data center personnel through activities such as designing the data center structure, positioning equipment within the data center prior to installation and adding, repositioning, or removing equipment after construction and installation are complete. Thus, conventional tool sets provide data center personnel with a standardized and predictable design methodology.

SUMMARY OF THE INVENTION

According to aspects of an embodiment, a computer-implemented method for sequential placement of cooling resources in a data center, comprises: defining a weighted, higher-order cooling metric, M , representing an overall performance of the cooling resources in the data center; enumerating all possible locations in the data center for placing an additional c cooling resources; and placing the c cooling resources in locations in the data center for which M is closest to an optimum value. In one variation, the computer- implemented method can further comprise: defining the higher-order cooling metric, M , in

C-1 R

terms of a cooling index Μ,·, such thatM = a{i, k)M - ^ , where R represents a number of k=0 i=l

racks in the data center, C represents a total number of cooling resources placed in the data center, i represents one of the R racks in the data center, Mf ^k) represents a value of metric Μ,· when k cooling resources are shut down, and a(i,k) is a weighting function for rack i with the k cooling resources shut down. In another variation, the computer-implemented method can further comprise: repeating enumerating and placing until a desired stopping condition is met by a resulting placement of cooling resources. In a further variation, the stopping condition is a desired redundancy level. In another further variation, the computer-implemented method further comprises: testing whether the desired stopping condition is met by a new resulting placement of cooling resources after removing one cooling resource from the resulting placement of cooling resources. In yet another further variation, the computer-implemented method further comprises: identifying that cooling resource which when removed results in a value of M closest to an optimum value; and removing that cooling resource identified. In yet another variation, Μ,· is capture index.

In accordance with aspects of another embodiment, a system for sequential placement of cooling resources in a data center layout, comprises: a computer storage system in which is stored a database holding a numerical computer model of the data center layout; and a computer processor executing a sequence of instructions directing: defining a weighted, higher-order cooling metric, M , representing an overall performance of the cooling resources in the data center; enumerating all possible locations in the data center for placing an additional c cooling resources; and placing the c cooling resources in locations in the data center for which M is closest to an optimum value. In a variation, defining further comprises: defining the higher-order cooling metric, M , in terms of a cooling index Μ,·,

C-1 R

such thatM = ^^α^ ^' , ^Μ^' , where R represents a number of racks in the data center, C k=0 i=l

represents a total number of cooling resources placed in the data center, i represents one of the R racks in the data center, Mf ^k) represents a value of metric M, when k cooling resources are shut down, and a(i,k) is a weighting function for rack i with the k cooling resources shut down. In another variation, the sequence of instructions further comprises: repeating enumerating and placing until a desired stopping condition is met by a resulting placement of cooling resources. In yet another variation, the stopping condition is a desired redundancy level. In an additional variation, the sequence of instructions further comprises: testing whether the desired stopping condition is met by a new resulting placement of cooling resources after removing one cooling resource from the resulting placement of cooling resources. In a further variation, the sequence of instructions further comprises: identifying that cooling resource which when removed results in a value of M closest to an optimum value; and removing that cooling resource identified.

In accordance with aspects of yet another embodiment, a computer-readable medium has stored thereon sequences of instructions including instructions that will cause a processor to: define a weighted, higher-order cooling metric, M , representing an overall performance of the cooling resources in the data center; enumerate all possible locations in the data center for placing an additional c cooling resources; and place the c cooling resources in locations in the data center for which M is closest to an optimum value. In a variation, defining further comprises: defining the higher-order cooling metric, M , in terms of a cooling index Μ,·,

C-l R

such that = a{i, k)M - ^ , where R represents a number of racks in the data center, C k=0 i=l

represents a total number of cooling resources placed in the data center, i represents one of the R racks in the data center, represents a value of metric M _t when k cooling resources are shut down, and a(i,k) is a weighting function for rack i with the k cooling resources shut down. In another variation, the sequences of instructions further causing the processor to: repeat enumerating and placing until a desired stopping condition is met by a resulting placement of cooling resources. In yet another variation, the stopping condition is a desired redundancy level. In an additional variation, the sequences of instructions further cause the processor to: test whether the desired stopping condition is met by a new resulting placement of cooling resources after removing one cooling resource from the resulting placement of cooling resources. In another additional variation, the sequences of instructions further cause the processor to: identify that cooling resource which when removed results in a value of M closest to an optimum value; and remove that cooling resource identified. In a further variation, ,· is a capture index metric.

BRIEF DESCRIPTION OF DRAWINGS

The accompanying drawings are not intended to be drawn to scale. In the drawings, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral. For purposes of clarity, not every component may be labeled in every drawing. In the drawings:

FIG. 1 shows an example computer system with which various aspects in accord with the present invention may be implemented;

FIG. 2 illustrates an example distributed system including an embodiment;

FIG. 3 is a side -by-side comparison of two similar floor plans distinguishable using a new metric of cooling performance;

FIG. 4 is a flowchart defining a sequential placement method according to aspects of an embodiment;

FIG. 5 is a flowchart defining a sequential placement method including backtracking according to aspects of another embodiment;

FIG. 6 is a floor plan illustrating an example layout to which aspects of an embodiment are applied; and

FIG. 7 is a mosaic of six snapshots showing the result after each of six stages of applying aspects of an embodiment.

DETAILED DESCRIPTION

At least some embodiments in accordance with the present invention relate to systems and processes through which a user may design data center configurations. These systems may facilitate this design activity by allowing the user to create models of data center configurations from which performance metrics may be determined. Both the systems and the user may employ these performance metrics to determine alternative data center configurations that meet various design objectives. Further, in at least one embodiment, a system will provide an initial layout of data center equipment and conduct a cooling analysis on the layout in real time. The aspects disclosed herein in accordance with the present invention, are not limited in their application to the details of construction and the arrangement of components set forth in the following description or illustrated in the drawings. These aspects are capable of assuming other embodiments and of being practiced or of being carried out in various ways. Examples of specific implementations are provided herein for illustrative purposes only and are not intended to be limiting. In particular, acts, elements and features discussed in connection with any one or more embodiments are not intended to be excluded from a similar role in any other embodiments.

For example, according to one embodiment of the present invention, a computer system is configured to perform any of the functions described herein, including but not limited to, configuring, modeling and presenting information regarding specific data center configurations. Further, computer systems in embodiments of the data center may be used to automatically measure environmental parameters in a data center, and control equipment, such as chillers or coolers to optimize performance. Moreover, the systems described herein may be configured to include or exclude any of the functions discussed herein. Thus the invention is not limited to a specific function or set of functions. Also, the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. The use herein of "including," "comprising," "having," "containing," "involving," and variations thereof is meant to encompass the items listed thereafter and equivalents thereof as well as additional items.

Designing Data Center Cooling

As described in U.S. Patent Application No, 12/019109, titled "System and Method for Evaluating Equipment Rack Cooling", filed January 24, 2008, and in U.S. Patent Application No. 11/342,300, titled "Methods and Systems for Managing Facility Power and Cooling" filed January 27, 2006 both of which are assigned to the assignee of the present application, and both of which are hereby incorporated herein by reference in their entirety, typical equipment racks in modern data centers draw cooling air in the front of the rack and exhaust air out the rear of the rack. The equipment racks and in-row coolers are typically arranged in rows in an alternating front/back arrangement creating alternating hot and cool aisles in a data center with the front of each row of racks facing the cool aisle and the rear of each row of racks facing the hot aisle. Adjacent rows of equipment racks separated by a cool aisle may be referred to as a cool or cold aisle cluster, and adjacent rows of equipment racks separated by a hot aisle may be referred to as a hot aisle cluster. As readily apparent to one of ordinary skill in the art, a row of equipment racks may be part of one hot aisle cluster and one cool aisle cluster. In descriptions and claims herein, equipment in racks, or the racks themselves, may be referred to as cooling consumers, and in-row cooling units and/or computer room air conditioners (CRACs) may be referred to as cooling providers. In the referenced patent applications, tools are provided for analyzing the cooling performance of a cluster of racks in a data center. In these tools, multiple analyses may be performed on different layouts to attempt to optimize the cooling performance of the data center.

In embodiments of the invention, different cooling performance metrics may be used to evaluate the cooling performance of a cluster. These metrics include capture index (CI) and recirculation index (RI) both of which are described in further detail in the applications, incorporated by reference above. In general, for a hot aisle cluster, the capture index indicates for each rack the percentage of the rack exhaust air that is captured by all of the coolers in the cluster. For a cool aisle cluster, the capture index indicates for each rack the percentage of rack airflow that is supplied directly by local cooling providers.

In at least one embodiment, a model of a data center is generated and displayed and a cooling analysis is provided of the data center. In creating a model, in at least one embodiment, a user may define a set of equipment racks and cooling providers to be included in a cluster, and the system will automatically arrange the equipment racks and the cooling providers in the cluster in a manner that will satisfy cooling requirements of the equipment racks.

A method according to aspects of at least one embodiment automatically identifies and places a number of in-row or over-aisle cooling units to adequately cool a given layout of data center objects. The method sequentially adds cooling units to the layout, until the cooling provided to a subject rack meets a user-defined criterion, usually a prescribed capture index (CI) or temperature. According to aspects of an embodiment, coolers are placed sequentially; the best location for each cooler is determined by an evaluation of cooling performance resulting from placing the cooler at each possible position within the layout.

Efficient placement of cooling resources within a data center is a difficult problem, due to the complex airflow patterns that must be evaluated and the enormous number of possible layouts that must be considered. When designing and building mission-critical facilities, such as data centers, designers commonly err on the side of an over-abundance of cooling, wasting cooling resources including considerable power consumption by the data center. To limit the waste of resources, methods embodying aspects of the invention automate the design of layouts that have good cooling coverage and yet do not waste cooling resources.

Methods embodying aspects of the invention flexibly handle new cooling technologies and guarantee user-specified requirements for one or more of maximum inlet temperature, minimum capture index, or minimum cooling redundancy. By utilizing a generic airflow prediction engine, such as computational fluid dynamics (CFD), potential flow, algebraic calculators, or neural networks, to make estimates, many situations are accurately modeled. The guarantee that a layout meet certain user-specified requirements is achieved because the sequential placement of in-row and over-aisle cooling units permits checking of the user-specified requirements after each cooling unit, or set of cooling units, is allocated to the layout. Checking of the user-specified requirements against design performance thus need not wait for a completed design.

Aspects of embodiments include computer-implemented methods, computer systems programmed to perform such methods, and computer media carrying instructions for a processor to carry out such methods. Computer systems suitable for practicing such aspects of embodiments are now described.

Computer System

General Description

Various aspects and functions described herein in accord with the present invention may be implemented as hardware or software on one or more computer systems. There are many examples of computer systems currently in use. These examples include, among others, network appliances, personal computers, workstations, mainframes, networked clients, servers, media servers, application servers, database servers and web servers. Other examples of computer systems may include mobile computing devices, such as cellular phones and personal digital assistants, and network equipment, such as load balancers, routers and switches. Further, aspects in accord with the present invention may be located on a single computer system or may be distributed among a plurality of computer systems connected to one or more communications networks. For example, various aspects and functions may be distributed among one or more computer systems configured to provide a service to one or more client computers, or to perform an overall task as part of a distributed system. Additionally, aspects may be performed on a client-server or multi-tier system that includes components distributed among one or more server systems that perform various functions. Thus, the invention is not limited to executing on any particular system or group of systems. Further, aspects may be implemented in software, hardware or firmware, or any combination thereof. Thus, aspects in accord with the present invention may be implemented within methods, acts, systems, system elements and components using a variety of hardware and software configurations; the invention is not limited to any particular distributed architecture, network, or

communication protocol.

FIG. 1 shows a block diagram of a distributed computer system 100, in which various aspects and functions in accord with the present invention may be practiced. Distributed computer system 100 may include one more computer systems. For example, as illustrated, distributed computer system 100 includes computer systems 102, 104 and 106. As shown, computer systems 102, 104 and 106 are interconnected by, and may exchange data through, communication network 108. Network 108 may include any communication network through which computer systems may exchange data. To exchange data using network 108, computer systems 102, 104 and 106 and network 108 may use various methods, protocols and standards, including, among others, token ring, ethernet, wireless ethernet, Bluetooth, TCP/IP, UDP, Http, FTP, SNMP, SMS, MMS, SS7, Json, Soap, and Corba. To ensure data transfer is secure, computer systems 102, 104 and 106 may transmit data via network 108 using a variety of security measures including TSL, SSL or VPN among other security techniques. While distributed computer system 100 illustrates three networked computer systems, distributed computer system 100 may include any number of computer systems and computing devices, networked using any medium and communication protocol.

Various aspects and functions in accord with the present invention may be implemented as specialized hardware or software executing in one or more computer systems including computer system 102 shown in FIG. 1. As depicted, computer system 102 includes processor 110, memory 112, bus 114, interface 116 and storage 118. Processor 110 may perform a series of instructions that result in manipulated data. Processor 110 may be a commercially available processor such as an Intel Pentium, Intel Core, Intel Xeon, Motorola PowerPC, SGI MIPS, Sun UltraSPARC, or Hewlett-Packard PA-RISC processor, but may be any type of processor or controller as many other processors and controllers are available. Processor 110 is connected to other system elements, including one or more memory devices 112, by bus 114.

Memory 112 may be used for storing programs and data during operation of computer system 102. Thus, memory 112 may be a relatively high performance, volatile, random access memory such as a dynamic random access memory (DRAM) or static memory (SRAM). However, memory 112 may include any device for storing data, such as a disk drive or other non- volatile storage device. Various embodiments in accord with the present invention may organize memory 112 into particularized and, in some cases, unique structures to perform the aspects and functions disclosed herein.

Components of computer system 102 may be coupled by an interconnection element such as bus 114. Bus 114 may include one or more physical busses, for example, busses between components that are integrated within a same machine, but may include any communication coupling between system elements including specialized or standard computing bus technologies such as IDE, SCSI, PCI , InfiniBand, and others. Thus, bus 114 enables communications, for example, data and instructions, to be exchanged between system components of computer system 102.

Computer system 102 also includes one or more interface devices 116 such as input devices, output devices and combination input/output devices. Interface devices may receive input or provide output. More particularly, output devices may render information for external presentation. Input devices may accept information from external sources.

Examples of interface devices include keyboards, mouse devices, trackballs, microphones, touch screens, printing devices, display screens, speakers, network interface cards, etc.

Interface devices allow computer system 102 to exchange information and communicate with external entities, such as users and other systems.

Storage system 118 may include a computer readable and writeable nonvolatile storage medium in which instructions are stored that define a program to be executed by the processor. Storage system 118 also may include information that is recorded, on or in, the medium, and this information may be processed by the program. More specifically, the information may be stored in one or more data structures specifically configured to conserve storage space or increase data exchange performance. The instructions may be persistently stored as encoded signals, and the instructions may cause a processor to perform any of the functions described herein. The medium may, for example, be optical disk, magnetic disk or flash memory, among others. In operation, the processor or some other controller may cause data to be read from the nonvolatile recording medium into another memory, such as memory 112, that allows for faster access to the information by the processor than does the storage medium included in storage system 118. The memory may be located in storage system 118 or in memory 112, however, processor 110 may manipulate the data within the memory 112, and then copies the data to the medium associated with storage system 118 after processing is completed. A variety of components may manage data movement between the medium and integrated circuit memory element and the invention is not limited thereto. Further, the invention is not limited to a particular memory system or storage system.

Although computer system 102 is shown by way of example as one type of computer system upon which various aspects and functions in accord with the present invention may be practiced, aspects of the invention are not limited to being implemented on the computer system as shown in FIG. 1. Various aspects and functions in accord with the present invention may be practiced on one or more computers having a different architectures or components than that shown in FIG. 1. For instance, computer system 102 may include specially-programmed, special-purpose hardware, such as for example, an application- specific integrated circuit (ASIC) tailored to perform a particular operation disclosed herein. While another embodiment may perform the same function using several general-purpose computing devices running MAC OS System X on Motorola PowerPC processors, Intel Core processors, or Intel Xeon processors, and several specialized computing devices running proprietary hardware and operating systems.

Computer system 102 may be a computer system including an operating system that manages at least a portion of the hardware elements included in computer system 102.

Usually, a processor or controller, such as processor 110, executes an operating system which may be, for example, a Windows-based operating system, such as, Windows NT, Windows 2000 (Windows ME), Windows XP or Windows Vista operating systems, available from the Microsoft Corporation, a MAC OS System X operating system available from Apple Computer, one of many Linux-based operating system distributions, for example, the Enterprise Linux operating system available from Red Hat Inc., and Debian-derived

GNU/Linux distributions such as Ubuntu, a Solaris operating system available from Sun Microsystems, or a UNIX operating systems available from various sources. Many other operating systems may be used, and embodiments are not limited to any particular implementation.

The processor and operating system together define a computer platform for which application programs in high-level programming languages may be written. These component applications may be executable, intermediate, for example, C-, bytecode or interpreted code which communicates over a communication network, for example, the Internet, using a communication protocol, for example, TCP/IP. Similarly, aspects in accord with the present invention may be implemented using an object-oriented programming language, such as .Net, SmallTalk, Java, C++, Ada, or C# (C-Sharp). Other object-oriented programming languages may also be used. Alternatively, functional, scripting, or logical programming languages may be used.

Additionally, various aspects and functions in accord with the present invention may be implemented in a non-programmed environment, for example, documents created in HTML, XML or other format that, when viewed in a window of a browser program, render aspects of a graphical-user interface or perform other functions. Further, various embodiments in accord with the present invention may be implemented as programmed or non-programmed elements, or any combination thereof. For example, a web page may be implemented using HTML while a data object called from within the web page may be written in C++. Thus, the invention is not limited to a specific programming language and any suitable programming language could also be used.

A computer system included within an embodiment may perform functions outside the scope of the invention. For instance, aspects of the system may be implemented using an existing commercial product, such as, for example, Database Management Systems such as SQL Server available from Microsoft of Seattle WA., Oracle Database from Oracle of Redwood Shores, CA, and MySQL from MySQL AB of Uppsala, Sweden or integration software such as Web Sphere middleware from IBM of Armonk, NY. However, a computer system running, for example, SQL Server may be able to support both aspects in accord with the present invention and databases for sundry applications not within the scope of the invention. Example System Architecture

FIG. 2 presents a context diagram including physical and logical elements of distributed system 200. As shown, distributed system 200 is specially configured in accord of the present invention. The system structure and content recited with regard to FIG. 2 is for exemplary purposes only and is not intended to limit the invention to the specific structure shown in FIG. 2. As will be apparent to one of ordinary skill in the art, many variant system structures can be architected without deviating from the scope of the present invention. The particular arrangement presented in FIG. 2 was chosen to promote clarity.

Information may flow between the elements, components and subsystems depicted in FIG. 2 using any technique. Such techniques include, for example, passing the information over the network via TCP/IP, passing the information between modules in memory and passing the information by writing to a file, database, or some other non-volatile storage device. Other techniques and protocols may be used without departing from the scope of the invention.

Referring to FIG. 2, system 200 includes user 202, design interface 204, data center design and management system 206, communications network 208 and data center database 210. System 200 may allow user 202, such as a data center architect or other data center personnel, to interact with design interface 204 to create or modify a model of one or more data center configurations. According to one embodiment, design interface 204 may include aspects of the floor editor and the rack editor as disclosed in Patent Cooperation Treaty Application No. PCT/US08/63675, entitled METHODS AND SYSTEMS FOR

MANAGING FACILITY POWER AND COOLING, filed on May 15, 2008, which is incorporated herein by reference in its entirety and is hereinafter referred to as

PCT/US08/63675. In other embodiments, design interface 204 may be implemented with specialized facilities that enable user 202 to design, in a drag and drop fashion, a model that includes a representation of the physical layout of a data center or any subset thereof. This layout may include representations of data center structural components as well as data center equipment. The features of design interface 204, as may be found in various embodiments in accord with the present invention, are discussed further below.

As shown in FIG. 2, data center design and management system 206 presents data design interface 204 to user 202. According to one embodiment, data center design and management system 206 may include the data center design and management system as disclosed in PCT/US08/63675. In this embodiment, design interface 204 may incorporate functionality of the input module, the display module and the builder module included in PCT/US08/63675 and may use the database module to store and retrieve data.

As illustrated, data center design and management system 206 may exchange information with data center database 210 via network 208. This information may include any information required to support the features and functions of data center design and management system 206. For example, in one embodiment, data center database 210 may include at least some portion of the data stored in the data center equipment database described in PCT/US08/63675. In another embodiment, this information may include any information required to support design interface 204, such as, among other data, the physical layout of one or more data center model configurations, the production and distribution characteristics of the cooling providers included in the model configurations, the

consumption characteristics of the cooling consumers in the model configurations and one or more cooling metrics characterizing the amount of cool air produced by the cooling providers that is lost prior to being consumed by the cooling consumers.

In at least one embodiment, data center database 210 may store, as part of the physical layout of a data center model configuration, the location and characteristics of the tiles that make up surfaces of the data center, such as the floor, ceiling and walls, of a model space. In at least one embodiment, the tiles may be floor tiles that are part of a raised floor, while in another embodiment the tiles may be ceiling tiles that are part of a drop ceiling. The characteristics of the tiles stored in data center database 210 may include, among other characteristics, whether or not the tiles are perforated, the size of the tiles and cooling metrics associated with the tiles, such as, in the example of a perforated tile, the airflow rate and temperature of air passing through it. As used herein, the term "perforated tile" may include any surface designed to allow airflow to pass through its boundary. Examples of perforated tiles include, among others standard-sized perforated tiles, custom-sized perforated tiles, cover grills and open holes. In some embodiments, this information is useful for providing enhanced functionality through design interface 204.

In another embodiment, data center database 210 may store, as a portion of the production and distribution characteristics of the cooling providers, the type of cooling provider, the amount of cool air provided by the cooling provider, and a temperature of cool air provided by the cooling provider. Thus, for example, data center database 210 includes record of a particular type of CRAC unit that is rated to deliver airflow at the rate of 5,600 cfm at a temperature of 68 degrees Fahrenheit. In addition, the data center database 210 may store one or more cooling metrics, such as an airflow leakage rate of an air plenum, such as a raised floor or a drop ceiling.

Data center database 210 may take the form of any logical construction capable of storing information on a computer readable medium including, among other structures, flat files, indexed files, hierarchical databases, relational databases or object oriented databases. The data may be modeled using unique and foreign key relationships and indexes. The unique and foreign key relationships and indexes may be established between the various fields and tables to ensure both data integrity and data interchange performance.

The computer systems shown in FIG. 2, which include data center design and management system 206, network 208 and data center equipment database 210, each may include one or more computer systems. As discussed above with regard to FIG. 1, computer systems may have one or more processors or controllers, memory and interface devices. The particular configuration of system 200 depicted in FIG. 2 is used for illustration purposes only and embodiments of the invention may be practiced in other contexts. Thus, the invention is not limited to a specific number of users or systems.

Design Interface Embodiments

According to various embodiments, design interface 204 may provide users with a high degree of flexibility regarding how and when they design data center cooling systems. In these embodiments, the user may design the entire cooling system in advance of the remainder of the data center configuration, may design the cooling system concurrently with other attributes of the data center or may design the cooling system after other parts of the data center design are complete. Thus, design interface 204 may be used to design new data centers or may be used to modify the designs of existing data centers. The formulation of useful systems and methods for conducting these design activities is impacted by the unique manner in which design interface 204 may be structured and organized. Conversely, the elements used and acts performed in these design activities impact the attributes and facilities of this embodiment of design interface 204.

Design interface 204 may provide functionality through a variety of user interface screens and elements. The user interface can include many of the user interface elements discussed in PCT/US08/63675 with regard to the floor editor and the rack editor. These elements may function within this embodiment as they function with the floor editor and the rack editor disclosed within PCT/US08/63675.

In the context of this design interface, an embodiment provides features for computing and ensuring cooling redundancy at specific rack locations. Conventionally, there is no concept of cooling redundancy at a specific rack location. A single redundancy level is conventionally stated for an entire facility. In some cases, some racks in a facility will have sufficient redundancy while others will not. Other facilities may be so over-designed to ensure cooling redundancy at all locations that substantial capital and ongoing energy costs are wasted. The exemplary embodiment provides a method by which redundancy can be computed for each rack location in a new or existing facility. With this information, data center designers and operators can make fact-based business decisions related to IT uptime and expenditures. For example, the designer of a new facility can minimize the number of coolers to just satisfy the level of redundancy required - which may be potentially different in different areas of the data center - thereby avoiding costs associated with over-provisioning. As another example, a data center operator may use the method to determine where to install a new server so that the cooling redundancy requirements of the new server will be met and that the cooling redundancy of other nearby IT equipment will not be adversely affected by the installation.

General Design Principles

A cooling metric that measures the overall cooling performance of the layout is defined to achieve a successful sequential, automatic placement method. Since a simple enumeration step is performed when searching for a place to allocate each cooling unit, an objective metric permits comparison of the cooling coverage provided by different prospective layouts that may be indistinguishable at first glance, especially when a high level of redundant cooling is required of a design. A new higher-order metric is introduced in the discussion that follows, that incorporates a common measure, such as temperature or capture index as a base, but also incorporates additional information about performance if one or more coolers fail.

The combination of sequential allocation of cooling resources with a new cooling metric to determine performance provides a robust, efficient method for placement of coolers within data center design and management tools. This method also allows for many different combinations of airflow prediction engines and higher-order metrics, which permits its use in other, more general, data center tools.

High-level view

In this section, the following aspects of the novel auto-placement method are discussed:

1. Initial conditions - What setup and structure is used?

2. Stopping conditions - How the method will finish?

3. Choice of stage size - How many coolers are placed at a time?

4. Enumeration of locations - Where will coolers be placed?

5. Higher- order metrics - How can alternative placements be accurately compared?

Initial conditions

According to aspects of some embodiments, two conditions should be observed. First, objects should be placed using a row-based architecture, featuring hot and cold aisles. This condition is not very restrictive, as many layouts are organized in this manner. Restricting cooler placements to rows limits the number variables to consider, without significantly constraining performance that can be achieved in a given space. It is much simpler to place a cooler "between rack 1 and rack 2" than to optimize over all possible two- dimensional locations for the cooler. This condition is not strictly limited to rows. Aspects of embodiments can also operate on other well-behaved, non-standard geometries, such as curved and perpendicular arrangements having adjacent rack and aisle spaces.

Second, all non-cooling objects should be positioned within rows before placement of cooling units begins. Aspects of embodiments of the method place cooling units, rather than racks, Uninterruptible Power Supplies (UPSs), or Power Distribution Units (PDUs). The placement of cooling units can more easily be done if all other objects are already present, so the effectiveness of each cooling unit relative to the other objects can be verified. Otherwise, a more complex method including computations after the placement of each non-cooling object would be used, to ensure that the user- specified requirements have been met. Stopping conditions

Methods according to aspects of embodiments terminate upon meeting a stopping condition; that is, a check that a desired level of cooling performance has been met by the layout produced. Performance can be measured using any one of, or combination of, many different metrics, e.g., capture index, temperature, and redundancy. Efficient embodiments favor metrics having less computational overhead over metrics having more computational overhead. Such metrics include those disclosed in US Patent Application Serial No.

12/974,719, filed December 21, 2010, US Patent Application Serial No. 12/416,567, filed April 1, 2009, and US Patent Application Serial No. 11/342,300, filed January 27, 2006, all incorporated herein by reference.

Stage size, c

Aspects of some embodiments are flexible regarding the number of cooling units that will be placed in each stage of testing. Often, it might be useful to assign two or more coolers at a time to a layout, such as a hot aisle containment layout where row lengths remain equal. Containment layouts are those in which features of the space "contain" airflows by means of physical barriers or baffles. In such a layout, an aisle may be fully bounded by a floor, ceiling, racks, and containment barriers on all six sides.

Thus, put in general terms, the sequential process allocates c coolers at a time. While a large c may provide more accurate estimates of the number of necessary cooling units, enumerating all of the possible arrangements for c coolers can be extremely expensive. A tradeoff is therefore be made in the selection of the stage size, c, as illustrated in Table 1. Table 1 shows that large stage sizes use the most computational effort, but can be advantageous. For most applications, a stage size of one or two will be advisable. c Applications Pros Cons

1 Most layouts Fast Less accurate

2 Containment Even row lengths Slow

3 Non-containment layouts Accuracy Very Slow

4 Containment layouts Accuracy; even row lengths Very Slow

5+ Unusual designs - Too many layouts to test

Table 1 Users wishing to use large stage sizes may have to perform some additional computations to ensure that optimal results are reached. Granularity of the results achieved when using large stage sizes may be non-optimal, and so some adjustment steps may additionally be performed by the method. For example, if a layout requires 13 coolers, and a selected stage size of four places coolers with a granularity which is a multiple of four for the final number of coolers placed, the method would stop after placing 16 cooling units, rather than after placing the optimum number of 13 cooling units. Two possible aspects of embodiments which make the desired adjustment include: attempting to remove cooling units via "backtracking," as discussed below; or, back up one stage, so that 12 coolers have been placed, and then place coolers using a smaller stage size, e.g., 1, 2, or 3, until the number of coolers which satisfy the cooling requirements of the layout cannot be reduced.

Enumeration and comparison of possible locations

Each step of the sequential method involves an enumeration of the possible locations to place c cooling units. Because the layout is constrained by an initial condition given above to be based on rows and aisles, there exist only a limited number of locations to place each cooler. The available spaces in which each cooling unit can be located will fall either before the first object of each row or after any object of a row.

The number of locations does not increase as coolers are placed, since typically the same unit will be used throughout the layout. Swapping the order of cooling units produces no airflow difference, and so for in-row units the number of locations available for remaining coolers remains constant. For over-aisle units, the placement of a cooler reduces the number of locations available for remaining coolers.

For each enumerated location, estimates of the performance measures of interest, e.g., CI, temperature, and redundancy, for the entire room are used. After computing such estimates the coolers are placed in the layout at locations that perform the best: maximizing overall CI, maximizing overall redundancy, and/or minimizing overall inlet temperatures. This objective comparison is not simple, so a new type of metric, discussed below, has been proposed which accommodates the details necessary for comparison of layouts.

The testing of locations is, at heart, an enumeration scheme. All possible placements for a cooling unit are tested, and the location that produces the most benefit for the room is selected as the result. However, enumeration does not necessarily make the method inefficient. The act of choosing an optimal location for one cooler at a time reduces the number of tested layouts significantly. Consider a layout with 40 racks that requires 10 in- row cooling units. Enumerating every possible location for the 10 coolers would require approximately 10 ¹⁰ layout calculations, but allocating only one cooler at time limits our calculations to only 10 · 40 = 400 layouts, an amount that real-time calculators can compute in only a second or two. Since only a small fraction of the possible layouts is tested, a 100% optimized design is not assured, but instead a fast, good, even near-optimized design is assured. A New Metric for Optimizing Layouts

To effectively compare data center layouts, metrics indicative of how well a room is covered by cooling resources are required. During optimization, for example during a comparison of layouts, these metrics will be used to distinguish between the performance of different layouts and thus permit the method to return the best configuration, that is, the layout that provides the minimum or maximum value of the chosen metrics. While the cooling index metrics of inlet temperature, capture index, escaped power, and redundancy are often used to evaluate cooling performance at a rack level, these measures are not easily adapted to room or cluster optimization.

FIG. 3 illustrates the limitations of these metrics with two distinct layouts as they might be shown in a current release of ISX Designer by APC. Using any of the metrics capture index, escaped power, and inlet temperature, both layouts appear to be identical; neither layout is better optimized than the other based on those three metrics. Layouts A and B each feature four racks R with 100% hot aisle and cold aisle capture indices, as marked on each rack in FIG. 3, meaning that all of the racks' hot air is captured by the cooling units and the rack inlet only takes in cold air supplied by the cooling units. These identical capture indices also indicate identical rack inlet temperatures when the cooling units operate at identical supply temperatures. But, from an energy efficiency and redundancy standpoint, layout A is intuitively preferred over layout B because it features shorter cooler-to-rack separation distances. Accordingly, a new set of "higher-order" cooling metrics is therefore defined that take into account measures of energy efficiency and redundancy. These new metrics also can be aggregated to obtain full-room estimates of cooling coverage, rather than simply a measure of the spot coverage at a particular rack which conventional metrics provide. These higher-order metrics provide:

1. Estimates of room cooling that can take on values from the set of real numbers, rather than a smaller set of numbers such as the whole numbers or integers, thus limiting the number of layouts that can share the same score. Layouts that produce results that are tightly grouped can nevertheless be easily distinguished.

2. Estimates that grade performance on multiple redundancy levels. This will allow comparison of layouts that would otherwise be indistinguishable at first glance, which commonly occurs in layouts with a large amount of cooling redundancy.

3. Flexibility to encourage even coverage of information technology (IT) loads or to reward extra coverage of critical IT load locations via the application of weighting schemes.

Let Mi be a performance metric for rack i in a data center under design. This metric Mi could be any of the common metrics utilized in data center design, such as inlet temperature, capture index, and escaped power (or any combination of these metrics). A new, higher- order metric M is defined as follows:

Mi ^k) = Mi , under the condition that the k coolers having the largest impact on Mi have been turned off, failed, or otherwise been omitted from the measurement.

Methods of computing where ,· is capture index (CI), cooling reliability index (CRI), or the like, are disclosed in US Patent Applications Serial Nos. 12/974,719,

12/416,567, and 11/342,300, mentioned above.

To obtain an objective representation of an entire room of R racks cooled by C coolers, a weighted sum, M , is computed of the higher-order metric Mi ^k) over every value of k from 0 to C- 1 and every value of i from 1 to R to obtain a weighted total measure. For example, if capture index is the metric ,· of interest, the weighted higher-order metric of weighted total capture index is defined

where a(i,k) is a weighting function for different racks, i, and redundancy levels, k, and Clf ^k) is the higher-order metric when CI is the performance measure of interest. Another higher- order metric could instead be used, for example total escaped power or total inlet temperature, resulting in weighted metrics of the weighted total escaped power or weighted total inlet temperature.

The weighting function a(i,k) allows for various redundancy levels and racks to be valued differently. One useful implementation is to weight each rack equally and give each successive redundancy level half the weight of the previous level. The resulting weighting function is: a{i, k) = a{k) = --- ;

2

and, the resulting weighted total capture index is:

Using this higher-order metric based on capture index produces a distribution which tends to result in even coverage over all racks and typically ensures that all racks will be covered with a desired level of cooling before beginning to add cooling redundancies into the layout. Some users may require uneven cooling coverage to address particular needs. In those cases, simple weighting schemes can be devised, for example to ensure that mission- critical racks are covered with a higher level of redundancy, without much adjustment to the metric. For example constant multipliers can be applied to certain racks and not to others.

Sequential Placement Methods

The various concepts and aspects of embodiments described above are integrated and combined into sequential placement methods, including two described now.

A Basic Method

An exemplary, basic method, performed by software executing on a computer processor operates as follows. The method is illustrated in the flowchart of FIG. 4. First, a user selects an initial layout, stage size, c, and stopping conditions, x, step 401. The method then enters a loop where the stopping condition is checked, step 402, and if not met, steps for placing coolers are then performed. Those steps include enumerating all possible locations for the stage of c coolers, step 403; followed by placing the c coolers in the best locations found as determined by evaluating a cooling metric for each of the enumerated layouts, step 404. Within step 404, one of the higher-order metrics discussed above is evaluated and applied in determining the best locations for a stage of c coolers. Any suitable higher-order metric and/or weighting function as explained above can be used. Control then returns to the test for the stopping condition, step 402.

Once the stopping condition is met, step 402, the layout that has been sequentially developed is returned, step 405.

A Modified Method Including Backtracking

The basic method can produce sub-optimal results in some cases. This arises because sequential placement of individual coolers may not provide the same results as if all of the coolers were placed at once. Therefore, an enhancement of the basic method includes backtracking, which systematically checks the end result and removes unnecessary coolers, as shown in FIG. 5.

The initial placement proceeds as described above in connection with FIG. 4, thus like reference numerals are used in this description of FIG. 5. First, a user selects an initial layout, stage size, c, and stopping conditions, x, step 401. The method then enters a loop where the stopping condition is checked, step 402, and if not met, steps for placing coolers are then performed. Those steps include enumerating all possible locations for the stage of c coolers, step 403; followed by placing the c coolers in the best locations found as determined by evaluating a cooling metric for each of the enumerated layouts, step 404. Within step 404, one of the higher-order metrics discussed above is evaluated and applied in determining the best locations for a stage of c coolers. Any suitable higher-order metric and/or weighting function as explained above can be used. Control then returns to the test for the stopping condition, step 402.

Once the stopping condition is met, step 402, a backtracking loop commences at step 501 by enumerating all possible locations from which a cooler can now be removed. Next, a test is performed to determine whether the layout satisfies the stopping condition x with one cooler less than presently in the layout, step 502. If the test is satisfied, step 502, the cooler determined in the enumeration of step 501 to be the best location from which to remove a cooler is, in fact, removed, step 503. Control then returns to the enumeration at step 501 , which is performed over the new layout having one cooler fewer than the previous pass through the backtracking loop, steps 501 , 502, and 503. After the backtracking loop completes, which occurs when the test at step 501 first fails, the layout that has been sequentially developed and then backtracked is returned, step 405. An Example

The basic method is now illustrated by an example of automatically placing over-aisle cooling units in a sample layout. The layout is a cluster with 12 medium density (4 kW) racks and 6 high density (8 kW) racks, as shown in FIG. 6. An algebraic calculator is used to estimate capture index for each rack within the layout and place each cooling unit to minimize the weighted total escaped power at each stage. The desired result is a layout with N + 1 redundancy. Thus, the stopping condition is N + 1 redundant cooling.

FIG. 7 shows six floor plan snapshots illustrating the results of performing six cooler placement stages according to aspects of the illustrative embodiment, with the final result being a layout with N + 1 redundancy. The cooler to be added at each stage is tested in all of the available positions, roughly corresponding to each empty space in the aisle across from two racks. Each cooler is placed, one at a time, into the best possible location available at that stage. When five coolers have been placed, as shown in FIG. 7 snapshot 5, every rack is adequately cooled when measured by the metric of CI. When six coolers have been placed, as shown in FIG. 7 snapshot 6, every rack has N + 1 redundant cooling. The process then stops because the stopping condition of N + 1 redundant cooling has been met for every rack.

This example uses a stage size of 1 , and so the method of FIG. 4 may be followed. Of course, a larger stage size and backtracking, as described in connection with FIG. 5 could also have been followed, had the initial conditions have suggested to the skilled designer that such an approach would have been suitable.

This example illustrates the sequential nature of the method and shows how stopping conditions are satisfied, but also highlights its ability to perform placement of new cooling technology. Provided the new technology is modeled using CFD or an algebraic calculator, an auto-placement method embodying aspects of the invention can perform such placement of cooling elements into a layout.

Having thus described several aspects of at least one embodiment of this invention, it is to be appreciated various alterations, modifications, and improvements will readily occur to those skilled in the art. Such alterations, modifications, and improvements are intended to be part of this disclosure, and are intended to be within the spirit and scope of the invention. Accordingly, the foregoing description and drawings are by way of example only.

What is claimed is: