LQR and MPC control of a simulated data center

Transcription

1 DEGREE PROJECT IN MATHEMATICS, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2017 LQR and MPC control of a simulated data center ERIK BERGLUND KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ENGINEERING SCIENCES

2

3 LQR and MPC control of a simulated data center ERIK BERGLUND Degree Projects in Optimization and Systems Theory (30 ECTS credits) Degree Programme in Applied and Computational Mathematics (120 credits) KTH Royal Institute of Technology year 2017 Supervisors at ABB: Winston Garcia-Gabin, Kateryna Mischenko Supervisor at KTH: Xiaoming Hu Examiner at KTH: Xiaoming Hu

4 TRITA-MAT-E 2017:59 ISRN-KTH/MAT/E--17/59--SE Royal Institute of Technology School of Engineering Sciences KTH SCI SE Stockholm, Sweden URL:

5 Abstract One of the largest contributions to a data center s power usage is its cooling system. To decrease the energy usage of the cooling system, an automatic control scheme that adapts the capacity of the cooling units is needed. In this master thesis, a Simulink model of a data center is developed, along with several LQR and one MPC controller. The controllers control the outlet temperature and volumetric airflow of two CRAH units in the simulated data center. Simulations are performed in which the controllers are judged based on their estimated energy usage and how often the server temperatures in the data center exceed 35 C. Based on the experimental results, recommendations are made regarding what kinds of controllers to investigate in ABB s further research. 2

6

7 Sammanfattning Ett av de största bidragen till ett datacenters energiförbrukning kommer från kylsystemet. För att minska kylsystemets energianvändning krävs ett automatiskt reglersystem som anpassar hur stor andel av kylningsenheternas kapacitet som utnyttjas. I detta examensarbete utvecklas en Simulink-modell av ett datacenter, samt flera LQR-regulatorer och en MPCregulator. Regulatorerna kontrollerar utblåsningstemperaturen och luftflödet hos två CRAHenheter i det simulerade datacentret. Simuleringar utförs, där regulatorerena bedöms efter uppskattad energianvändning och efter hur ofta servertemperaturerna övergår 35 C. Baserat på experimentella resultat ges rekommendationer angående vilken typ av regulatorer som bör undersökas närmare i ABBs fortsatta forskning. 3

8

9 Acknowledgements I would like to thank Xiaoming Hu for helping me get started with the thesis, and Winston Garcia- Gabin and Kateryna Mischenko for their advice and patient support throughout my work with it. I would like to thank my fellow master student Huang Zhang and his supervisor Xiaojing Zhang for their valuable contributions regarding the data center model. I would also like to thank my parents Anders and Astrid Berglund for their moral support during my work. Finally, I would like to thank my grandma Ingeborg Berglund for letting me live with her in Västerås during my time at ABB. 4

10

11 Abbreviations ASHRAE CRAH LQR MPC PID the American Society of Heating, Refrigerating and Air-Conditioning Engineers Computer Room Air Handler Linear Quadratic Controller Model Predictive Controller Proportional Integral Derivative (Controller) 5

12 Contents 1 Introduction Background Approaches for controlling the data center Statement of thesis scope Thermal model of the servers Statement of contributions Data center layout Assumptions Model Indices, parameters and variables Power usage of the servers Time delay Airflows Inlet temperatures Outlet temperatures Complete modeling framework Parameter values Inflow areas Other parameters Model validation Steady-state validation Step response validation Power usage of the cooling system Power usage model Indices, parameters and variables Power usage of the chiller Power usage of the fans Estimation of input temperature Validation of the power usage model Simulation results Proof of consistency Suggestions for model improvements Preliminary comments to the controller chapters 27 5 LQR control LQR Theory LQR formulations Tuning Linearization point Signal saturation Tuning experiments MPC control Overview of MPC Optimization problem formulation Tuning MPC tuning experiments Tuning experiment results

13 7 Controller tests and results Test description Experimental data generation Scenario Scenario Initial tests of the LQR controllers Tests of the LQR controllers with adjusted setpoints Tests of the LQI controller using both temperature and airflow as control variables Tests of the MPC controller Results Tables Figures Discussion Test results discussion Control of mean or maximum temperatures LQR vs LQI Temperature vs airflow control LQR vs MPC Suggestions for further work Introduction 1.1 Background A data center can be defined as a facility that contains concentrated equipment to store, manage, process and exchange digital data and information. The need for such services has drastically increased, along with the development of IT equipment technology. To support the energy intensive computing of a data center, as of 2004 most data centers use specialized computer room air conditioning systems [1]. Research efforts on data centers have been led by US based organizations such as the Department of Energy, the Department of Defense, ASHRAE s Technical Committee 9.9, The Green Grid and the Uptime Institute. According to [2], the research before 2012 was mostly concerned with IT equipment characteristics and safety. In comparison, research on energy savings in cooling of servers was limited. In 2007, the EPA published a report on data center efficiency identifying, among others, heat removal and control and management as topics in need of research [11]. The EU began making efforts in data center power efficiency by the end of 2010, launching projects All4Green and CoolEmAll. Since then, 6 more projects aiming to reduce the environmental impact of data centers have been launched [10]. They were completed in Figure 1: The energy consumption of a data center 7

14 Figure 1 illustrates the different parts of the energy consumption of a typical data center. Since cooling accounts for nearly 40 % of the energy consumption of a data center, this is a suitable area to focus on when researching how to decrease the energy needs. The cooling can be done on several scales, from cooling of individual chips, to cooling of the whole room. The room cooling system inside a typical data center can be described as follows: a CRAH cools the air inside of it by using cold water provided by an external cooler. A fan in the CRAH supplies this air to the data center, usually through a plenum. The servers racks are organized into rows dividing the data center into cold aisles and hot aisles. The chilled air is supplied to the cool aisles, passes through the server racks and exits them into the hot aisles. The hot air rises to the roof and recirculates into the CRAH where it is cooled again [4]. This is illustrated in figure 2. Figure 2: A diagram showing the layout of a data center with raised floor plenum cooling. Several alternative ways of cooling have been suggested. A review of the state of the art of cooling systems from 2015 [5] considers liquid cooling instead of air cooling, and concludes that liquid cooling will be able to support a higher density of power than air cooling, increase the energy efficiency by removing the air as an intermediate step and make it easier to use the heat generated from the servers. The main disadvantage of liquid cooling is the risk of having liquid near the servers in case of failure, so which solution that is the better alternative depends on whether this risk can be justified. The advantage of conventional air cooling is accessibility and maintainability, since it requires no pipes or barriers around the servers. Its disadvantage is lowered efficiency because of recirculation and bypass of air. This can be remedied by isolating the cold and hot aisles, but that increases cost and decreases maintainability. According to [12] page 430, data center users have stated that for power densities less than 14 W/m 2 (150 W/ft 2 ), the extra cost for containment is not justifiable. Part of that cost is because of the need of more sensitive control, which could be decreased with an efficient control algorithm. 1.2 Approaches for controlling the data center Temperature management of servers in data centers can be considered on several different scales, from the hardware in the server components, to the whole cooling architecture of a multi-room data center. Dynamic control of data center temperatures can be done on the server level, as in [25] and [7], rack level as in [9] and room level as in [24] and [6]. A study from 2006 [3] investigated the viability of using different parts of the cooling system of a data center as control variables. The conclusions were the following: The inlet temperature of the servers depends linearly on the CRAH supply temperature. The supply temperature would be suitable as a control variable, but it would not be enough to just change the supplied temperature if the fan speed would be to low. Increasing the fan speed would decrease the difference between inlet and outlet temperature of a server, but it would not decrease linearly. Instead, a given decrease in airflow would have a greater effect for lower initial airflows. Closing a vent in the plenum increased the temperature near it but decreased it at neighboring vents. Manipulation of vents would thus allow more localized temperature control. To capture the cyber-physical nature of a data-center, one approach used in [24] is to model 8

15 the data-center as a network of thermal and computational nodes. Test cases in the referenced dissertation shows that the coordinated optimization of IT-load leads to efficiency improvements in cases where the servers are not placed so that they are all cooled efficiently. A realistic model containing both IT-loads and thermal dynamics can be quite complex, and if it is not tractable to coordinate the IT-load and the cooling, another approach would be to predict the IT-load distribution in the cooling efforts, as was done for control of a single server in [25]. A common approximation in the models used when controlling the data center is to disregard the dynamics of airflow. The motivation for this is that they are quicker than the temperature dynamics. The air recirculation from server outlets to inlets, and the airflow that bypasses the servers and goes directly to the cold aisle have generally been modeled as static functions of the supplied airflows. Modeling their contributions as constants can lead to a model where the time derivatives of server temperatures depend linearly on airflow, as in [6]. Modeling them as polynomials of the inflow to the servers gives a more realistic model, and has been used to treat the case of individual servers as in [7]. In [9], a thermal model that can estimate a dynamic airflow in real time is developed. This model is used to aid a PID controller by estimating unavailable temperatures. Changes in outlet airflows are generally assumed to affect the server temperatures immediately, no time delays have, as far as I know, been considered in previous works. 1.3 Statement of thesis scope The objective of this thesis was to develop several control schemes for the cooling system of a data center, consisting of 2 CRAH units, and investigate their performance in a preliminary study for ABB. The conclusions of the thesis would be used to determine the direction of further research of data center control. The performance of the control schemes is judged based on two objectives: minimizing the energy consumption of the cooling system and keeping the maximum temperatures of the servers in the data center below a certain setpoint. The first part of the thesis was to develop a model of the data center. This model would be both in order to develop model based controllers, and to evaluate the performance of those controllers. In order to check the performance with respect to the control objectives, the model would need to simulate the server temperatures and the power usage of the cooling system. These two parts will be elaborated on in two separate chapters. The data center model was developed using energy balance equations and simplifying assumptions such as treating the servers and their enclosures as having one uniform temperature. The thermal dynamics are similar to the model in [25], except that they apply to servers in a data center instead of components of a server, using an empirically determined thermal mass for servers from [18]. The power usage of the cooling system is modeled similarly to [24], but incorporates a contribution from varying airflow as well as temperature. The most distinguishing feature of the current model compared to the previous ones is that it has a time delay for the controller outputs to take effect. However, tests of the model showed that this time delay was insignificant on the time scale of the servers thermal dynamics. The second part of the thesis was to develop controllers based on the data center model. Several LQR controllers and one MPC controller were developed. The LQR controllers were tuned according to the heuristic that they need to make the controlled system adjust to a change in setpoint twice as fast as the open loop system would move to that point naturally given a change in server usage. The MPC was developed to minimize an energy functional while taking constraints on controller outputs and maximum server temperatures into account. The model on which the LQR controllers were based on, was a linearized version of the dynamics of the mean temperatures of servers in two groups of server racks in one row of the data center. In the experiments with the controllers, they were used to control these mean temperatures, but also the maximum temperatures of the rack groups. One goal of the experiments was to investigate whether the controllers would have a stabilizing effect on the maximum temperatures even though their dynamics would not correspond entirely to the controllers internal models. If this was the case, control of the maximum temperatures could be a better way of avoiding overheating than controlling the mean temperatures. Some of the LQR controllers would use only airflow as a control variable, some used the outlet temperature of the CRAHs. This was done in order to investigate if there were any significant performance difference between airflow and temperature control. One LQR controller was also developed according to the same model as the others, but would use both outlet temperature and 9

16 airflow as control variables. In order to compensate for discrepancies with the linearized model on which the LQR controllers was based on and the real data center, some controllers had their state space extended with the integral of the difference between the controlled temperatures and their setpoints, making them LQI controllers. Another objective of the experiments with these controllers was to investigate the difference in controller performance with and without this extension. The MPC was designed with a discretized version of the data center model that would ignore time delays. Several tuning experiments were performed in order to choose the algorithm for the MPC. The results of these tuning experiments showed that the posed optimization problem was nonconvex, so that only local minima would be found, if any at all. The computation time for the MPC simulations were also significantly longer than for the LQR simulations. The experiments with the MPC would show if its ability to find local minima for energy usage and its capability of predicting the values of its controlled temperatures would warrant the effort of implementing it more efficiently so that it could work in real time. Tests in a real data center has been done with a similar MPC in [6]. The main difference between the MPC in that study and in this thesis, are that the MPC in that study only monitors rack inlet temperatures and does not take varying power usage of the servers into account, but has another control variable in the form of adjustable sizes of vents in the data center floor. The MPC in that study also has a slightly different objective function which assumes that the power usage of the chiller depends linearly on the supplied air temperatures, and which penalizes too large changes in controller output. The MPC and LQR controllers were used in two different test scenarios. In the first scenario, two servers in each rack would constantly work at minimum and maximum capacity respectively, increasing the difference between the maximum and minimum temperatures, making it inefficient to control the servers using mean temperatures. In the second scenario, the server load would shift between the servers with different thermal dynamics in each rack, which could present a problem when controlling the maximum temperatures. By comparing the controllers performance in these two extreme scenarios, conclusions could be drawn about whether a certain type of control scheme would be strictly better than another or if a controller s performance depended heavily on the type of variations in IT load. 2 Thermal model of the servers This chapter describes a dynamical model of the average temperatures of servers in a data center. The model is based on a module in the SICS-ICE data center used for research purposes [13]. The chapter is divided as follows: After a stating the contributions of another master thesis student to this model, a description of the data center is given. Then, the assumptions made for developing the mathematical model are presented, followed by the resulting equations in a general form. Finally, specific parameters values used in simulations are given, and some results of validation tests are shown. 2.1 Statement of contributions The data center model described here is based on a steady state model developed by Huang Zhang as part of his thesis work at ABB [8]. Given his model, I modified it to include dynamics and implemented it in Simulink. The equations in sections and describe derivations of coefficients and equations in Huang s original model. My contribution in these sections was to write down the derivations, explain the equations and to generalize them by naming parameters instead of using explicit parameter values. I also changed some parameters compared to Huang s model. Another contribution of Huang is section 2.4.2, the equation there was his suggestion. Huang s model included steady state special cases of the equations in sections and 2.4.6, but generalizing the model to include dynamics was my contribution. 2.2 Data center layout The data center modeled is a small scale slab floor data-center. It contains two rows of five server racks, four CRAHs and one UPS, battery pack and a single switchgear. The layout can be seen in figures 3 and 4. The data center has its vents on the CRAHs, creating two cool aisles outside the 10

17 server racks and one hot aisle between them. An advantage of this setup compared to the more common one with floor vents is that there is less air bypass from the cool aisles and recirculation from the hot aisle. In the model of this data center, there are 18 servers per rack, enumerated from top to bottom. Figure 3 shows how the CRAH units and racks are located in relation to each other and how they are enumerated. 2.3 Assumptions The model is based on several simplifying assumptions. All energy consumed by the servers is emitted as heat. All servers have the same power consumption for the same resource usage. All server have an equally sized enclosure in their racks. A server along with its enclosure will be referred to as that server s enclosing region. Any heat in the data center is assumed to be transported entirely by airflow, except for the emission of heat from the servers and removal of heat from the CRAHs. Air does not recirculate from the hot aisle to the inlets of the servers. A fixed proportion of the air is assumed to pass over the racks. Only heat and thermal energy is considered in the energy balance equations. The heat capacity and density of air are assumed to be constant, their dependency on temperature, pressure and humidity is ignored. The air velocity field originating from a certain CRAH is assumed to be constant over any cross section perpendicular to that CRAH. The temperature of an airflow is the same at the CRAH outlet and rack inlet. Airflows from different sources mix perfectly before entering a server. This mixing happens in non-overlapping regions in front of the server inlets, and during such a short time interval that inlet temperatures and airflows can be considered constant over this interval. Each CRAH has a fixed region of influence, a 2-dimensional region in the plane of the rack inlets below the height of the server racks through which air from that CRAH passes. The region of influence has the same size for all CRAHs. The region of influence of a CRAH has the same height as the server racks. The region of influence of a CRAH is assumed to be symmetrical with respect to the vertical plane perpendicular to the CRAH s outlet that contains the CRAH s midpoint. The regions of influence have the minimum width necessary for the racks next to the wall of the data center (racks 5 and 10) to have their inlets lie entirely inside the regions of influence of a CRAH (CRAHs 2 and 4 respectively). The air passing through the region of influence travels through the 3-dimensional region bounded by the convex hull of the points in the CRAH outlet and the region of influence of that CRAH. The lead time for a CRAH unit to change its output is ignored. Figure 3 shows with the lines extending from each CRAH unit in which region the air from them is assumed to travel, and shows their regions of influence. As seen from the figure, the inlets of racks 1 and 2 lie entirely within CRAH 1 s region of influence, while the inlets of racks 2, 3, 4 and 5 lie entirely withing the region of influence of CRAH 2. CRAH 1 also has a partial intersection with the inlet of rack 3 and CRAH 2 a very small intersection with the inlet of rack 1. By symmetry of the data center, the inlets of racks 6-10 and the regions of influence of CRAHs 3 and 4 have the corresponding intersections. 11

18 Figure 3: A labeling of racks and CRAHs with a top-down view of the regions of influence. Note how the regions of influence of CRAHs 1 and 2, and of CRAHs 3 and 4 overlap, and that the regions of influence of CRAHs 1,2,3 and 4 intersect partially with the inlets of racks 3,1,8 and 6 respectively. 2.4 Model Indices, parameters and variables Table 1 describes the variables, parameters and indices used to model the data center and its power usage. Specific values of the parameters are given in tables 2 and 3. 12

19 Index Description i Index of the CRAH units, i {1, 2, 3, 4} j Index of the server racks, j {1,..., 10} k Index of the servers in each rack, k {1,..., 18} Parameter Description p Proportion of air from the CRAHs that passes above the racks. p [0, 1) V airflow The volume of the region through which air is assumed to pass between the CRAH and its region of influence s i,j The area of the region through which airflow from CRAH i enters rack j s influence The area of the region of influence of a CRAH unit p idle The power usage of an idle server p peak The power usage of a server working at full capacity C th The thermal mass of the enclosing region of a server c p The specific heat capacity of the air in the data center. ρ The density of the air in the data center. Variable Description t Time measured from the start of a simulation t di (t) The time delay of the airflow from CRAH i that reaches the region of influence at time t u j,k (t) The resource usage of server k in rack j at time t. u j,k (t) [0, 1] P j,k (t) The power usage of server k in rack j at time t a i (t t di (t)) Volumetric airflow emitted from CRAH i at time t t di. Assumed to be a i (0) for t t di (t) < 0 a i,j (t) Volumetric airflow from CRAH i entering rack j at time t A j,k (t) Volumetric airflow entering the enclosing region of server k in rack j at time t T i,out (t t di (t)) Outlet temperature of CRAH i at time t t di (t). Assumed to be T i,out (0) for t t di (t) < 0 T j,k,in (t) Inlet temperature of the enclosing region of server k in rack j at time t T j,k,out (t) Outlet air temperature of the enclosing region of server k in rack j at time t. Table 1: Table describing the indices, parameters and variables of the model Power usage of the servers For simplicity, a linear equation for the power usage is assumed, as in [16]. With an idle server using power p idle, a full capacity server using p peak and the proportion of resources used of server k in rack j at time t being u j,k (t), the power usage of that server is Time delay P j,k (t) = p idle + (p peak p idle )u j,k (t). (1) Because of the distance between the CRAHs and the nearest row of racks, there is a time-delay in the airflow that reaches the racks. The time delay t di (t) at time t must be such that the volume of air passing from a CRAH unit to its region of influence during the time interval [t t di (t), t] equals the volume of the region the air is assumed to travel through. This yields the following equation: Airflows t t t di (t) (1 p)a i (τ)dτ = V airflows (2) The airflow from CRAH i that passes through that CRAH s region of influence at time t is (1 p)a i (t t di (t)). By the assumption that the airflow is distributed evenly, a i,j (t) = s i,j s influence (1 p)a i (t t di (t)) (3) 13

20 and A j,k (t) = a i,j (t). (4) A non-uniform distribution of airflow could also be simulated by changing the parameters s i,j or setting different weights on the sum in the right hand side of equation (4) Inlet temperatures For an ideal fluid with constant specific heat capacity c p, density ρ and volume V, a temperature change T corresponds to a change in internal energy Q = c p ρv T. If two volumes V 1 and V 2 of the same fluid with temperatures T 1 and T 2 perfectly mix, the net change in internal energy is 0. The temperature of the mixed fluid T will be such that the cooler volume of fluid will gain as much energy as the hotter one loses, so i=1 c p ρv 1 (T T 1 ) = c p ρv 2 (T 2 T ) T = V 1T 1 + V 2 T 2 V 1 + V 2. (5) The above equation can be generalized by induction. Assume that if n fluid volumes V 1,..., V n with temperatures T 1,...T n mix, the resulting fluid will have volume V = n m=1 V m and temperature n m=1 T = V mt m n m=1 V. Mixing in an extra volume of fluid V n+1 with temperature T n+1, the temperature of the resulting fluid is V T + V n+1 m n+1t n+1 m=1 = V mt m V + V n+1 n+1 m=1 V according to equation (5). To apply m this to the data center, the assumption of perfect mixing of airflows is used. This is assumed to happen at non overlapping regions outside the inlets of the racks. The time it takes for this mixing to occur is short enough that all airflows and temperatures can be considered constant over that time interval. Then the volume of air from each CRAH is proportional to the volumetric airflow of that CRAH reaching the considered inlet. The inlet temperature to the enclosing region of server k in rack j at time t can be calculated as T j,k,in (t) = 4 i=1 a i,j(t)t i,out (t t di (t)) 4 i=1 a. (6) i,j(t) Outlet temperatures The final step in the model derivation is to obtain a dynamical model of the server outlet temperatures. A simple type of model is a first order differential equation and such an equation will be derived as follows: Assuming that there is no inflow from the hot aisle, no heat conduction and a uniform temperature in the enclosing region of a server, T j,k,out (t) will be equal to the temperature of the enclosing region of server k in rack j. The air in the model is assumed to have a constant density ρ and specific heat capacity c p. The enclosing region of a server is assumed to have thermal mass C th. By energy balance, the rate of change in internal energy is equal to the inflow minus the outflow. The inflow air has temperature T j,k,in (t) and replaces the outflow air, changing the internal energy of the air surrounding the server. Assuming all energy used by the server is radiated as heat, or equivalently, dt j,k,out C th (t) = P j,k (t) + c p ρa j,k (t)(t j,k,in (t) T j,k,out (t)), (7) dt dt j,k,out (t) = P j,k(t) + c pρa j,k (t) (T j,k,in (t) T j,k,out (t)). (8) dt C th C th 14

21 2.4.7 Complete modeling framework To summarize, the data center model is described by the equations given below. P j,k (t) = p idle + (p peak p idle )u j,k (t). t t t di (t) (1 p)a i (τ)dτ = V airflows. s i,j a i,j (t) = (1 p)a i (t t di (t)) s influence A j,k (t) = 1 4 a i,j (t). 18 i=1 4 i=1 T j,k,in (t) = a i,j(t)t i,out (t t di (t)) 4 i=1 a. i,j(t) (9) dt j,k,out (t) = P j,k(t) dt C th + c pρa j,k (t) (T j,k,in (t) T j,k,out (t)). C th This is a nonlinear, continuous time model, although it is linear if all the control airflows a i (t), i {1, 2, 3, 4}, are held constant. It may be suitable to linearize the model if airflow is to be used as a control variable. For applications such as MPC, the differential and integral equations should be discretized. 2.5 Parameter values This section presents specific values of the parameters used for simulation of the data center and the reasons for choosing these values. The first subsection presents a table of the inflow areas, while the second lists the values of the other parameters Inflow areas With the assumptions on how the airflow is distributed, and the fact that the cooling units used in the data center have a width of 2.25 m [20], the values of s i,j can be calculated using the widths and heights of the racks and the distances between the CRAHs given in figures 4 and 5. Figure 4: Data center layout with measurements, top down view. 15

22 Figure 5: A sideways view of the data center with measurements. The values of s i,j for i {1, 2}, j {1, 2, 3, 4, 5} are given in m 2 in table 2. By the symmetry of the data center, s i,j = s i 2,j 5 for for i {3, 4}, j {6, 7, 8, 9, 10}. All values of s i,j not mentioned are 0, as CRAH units are assumed to only affect racks in the nearest row. s i,j j = i = Table 2: Table of the inflow areas for the racks and CRAHs on the left side of the data center Other parameters In table 3, the remaining parameters are listed. The lengths and areas are taken from given measurements in the specific data center (figures 4 and 5) and in the specifications of the CRAHunits [20]. The thermal mass of the enclosing region of a server was taken to be the thermal mass of a server studied in [18], a server of the same size, although not of the same brand, as the ones in the modeled data center. Ignoring the thermal mass of the enclosure of the server is justified by a conclusion of [19], that the servers heat capacity have the most significant contribution to the data center dynamics and that the thermal mass of the racks can be ignored. The density and heat capacity of air are taken from the values in [17] for a temperature of 300 K. As no data for the proportion of air traveling over the racks was found for the modeled data center, p was treated as a tuning parameter, and reasonable results were obtained for p = p peak and p idle were chosen so that p peak would be roughly twice of p idle and so that their mean would be 200 W, the power consumption of a typical server in the modeled data center. The CRAH outlets are rectangular, and the regions of influence were assumed to be so too. Therefore, V airflow was calculated as follows: Let h o be the height and w o be the width of a CRAH outlet, and h i be the height and w i be the width of a region of influence. The assumed region through which air travels from the CRAH outlet to the region of influence has, at a distance x from the CRAH, a height h(x) = hix+ho(l x) L, and a width w(x) = wix+wo(l x) L. The volume of the region is then V airflow = L 0 h(x)w(x)dx = L 6 (2(h ow o + h i w i ) + h o w i + h i w o ). (10) The measurements used to calculate V airflow are given in table 3. 16

23 Parameter Value Unit p 0.25 unitless L 1.2 m h o m w o m h i 2.15 m w i m V airflow m 3 s influence m 2 p idle 130 W p peak 270 W C th J/K c p 1007 J/(kg K) ρ kg/m 3 Table 3: Table of the remaining parameters of the data center model 2.6 Model validation To see that the model would give plausible outputs for given inputs, several tests were conducted. All simulations were done in Simulink, with the solver ode15s Steady-state validation In this validation, different scenarios were studied in which the cooling system was set to work at either minimum, medium or maximum capacity. The servers resource utilization were set to either 0%, 50% or 95%. The different scenarios are described in table 4. The minimum and maximum input temperatures to the model were chosen according to ASHRAE s recommendations, 18 C and 27 C respectively [21]. The maximum airflow was set to 2.18 m 3 /s, the airflow given in the specifications for the CRAH units [20], and the minimum airflow was assumed to be 1.3 m 3 /s. All CRAHs were set to have the same outlet airflow and temperature, and all servers had the same utilization. Scenario CRAH outlet CRAH outlet Server airflow temperature utilization m 3 /s 18 C 0% m 3 /s 27 C 0% m 3 /s 27 C 95% m 3 /s 18 C 95% m 3 /s 18 C 50% m 3 /s 22.5 C 50% Table 4: A description of the test scenarios for the steady state validation With the same resource utilization and inlet temperature for all servers, differences in server outlet temperature would be caused only by differences in inlet airflow. Therefore, four different outlet temperatures were obtained: One for racks 1 and 6, one for racks 2 and 7, one for racks 3 and 8 and one for racks 4, 5, 9 and 10. The steady state outlet temperatures are shown in table 5 17

24 Scenario Outlet temperature Outlet temperature Outlet temperature Outlet temperature racks 1 and 6 racks 2 and 7 racks 3 and 8 racks 4, 5, 9 and C C C C C C C C C C C C C C C C C C C C C C C C Table 5: Steady state temperatures for the scenarios described in table 4 As seen in table 5, all temperatures except for those in scenario 3 lie around or below 35 C, the maximum recommended operating temperature for a server according to Dell [23]. Overheating can be expected in scenario 3, as the servers are using almost all their resources while the cooling system works at minimum capacity. In the other scenarios, the temperatures are reasonable. For a better overview, the temperatures are plotted in figure 6. Note that in all scenarios, the ordering of racks by outlet temperature is always the same Racks 1 and 6 Racks 2 and 7 Racks 3 and 8 Racks 4,5,9 and 10 Racks Figure 6: The steady state temperatures in the different scenarios. The graphs correspond to the following scenarios: green - 3, blue - 2, magenta - 6, black - 4, cyan - 5 and red Step response validation In this validation, the step response of the model was studied. The model was initially in the steady state described in scenario 1 in the previous section. Three different cases were studied, and in each case, there would be a step in either the temperature, airflow or server usage at time 500 s. The step would be from the minimum to the maximum value in the case of temperature, from 0% to 95% in the case of server utilization, and from maximum to minimum in the case of airflow. The results of the simulations are shown in figures 7, 8 and 9. The figures illustrate the similarities and differences in how the model responds to steps in different inputs. The server temperatures are in a reasonable range throughout the simulation. Four different temperatures 18

25 were given, corresponding to the four different inlet airflows that a server could have in these scenarios. The step responses are stable first order responses, as can be expected by the model. The time constants can be calculated as τ = C th. The settling times are calculated as 4 τ c p ρa j,k for all servers. Figure 7 shows the step response for resource usage. In the steady state after the step response, the different temperatures are further apart, as the temperature impact of increased power usage depends on the rate of heat removal. The settling times are in the range 914 s s Time (s) Figure 7: Step response when the resource usage increases from 0% to 100 %. The graphs correspond to the following rack temperatures, with settling times: Orange - racks 4, 5, 9 and 10, settling time 1823 s. Cyan - racks 1 and 6, settling time 1753 s. Teal - racks 3 and 8, settling time 1508 s. Red - racks 2 and 7, settling time 914 s. Figure 8 shows the step response for inlet temperature. In contrast to the step response for resource usage, all temperatures have the same difference between them in the steady states before and after the step. The settling times are the same in the resource usage and inlet temperature step scenarios, as the time constant is not affected by power usage or inlet temperature. 19

26 Time (s) Figure 8: Step response when the inlet temperature increases from 18 C to 27 C.The graphs correspond to the following rack temperatures, with settling times: Orange - racks 4, 5, 9 and 10, settling time 1823 s. Cyan - racks 1 and 6, settling time 1753 s. Teal - racks 3 and 8, settling time 1508 s. Red - racks 2 and 7, settling time 914 s. Figure 9 shows the step response for airflow. As in the step response for resource usage, the temperatures move further apart after the step. Since the airflow is reduced, the settling times increase compared to the previous scenarios. In this case, they are in the range 1531 s s Time (s) Figure 9: Step response when the airflow decreases from 2.18m 3 /s to 1.3m 3 /s.the graphs corresponds to the temperatures of servers in the following racks: Orange - racks 4, 5, 9 and 10. Cyan - racks 1 and 6. Teal - racks 3 and 8. Red - racks 2 and 7. In the previously shown step responses, all servers in a rack had the same power usage, and would therefore have the same temperature according to the model. However, the model should be able to calculate individual temperatures for each server. Since all servers in a rack are assumed to have the same inlet temperature and airflow, this allows a comparison of how different resource usages affect the server temperatures. To illustrate this, the following step response simulation was performed: The serves in rack 2 would begin in the same steady state as in previous simulations. 20

27 At time 500 s, the servers would get an increase in resource usage between 0% and 85%. Figure 10 shows the results of this simulation. As before, the plot shows first order step responses % 0.8% 0.75% 0.7% 0.65% 0.6% 0.55% 0.5% 0.45% 0.4% 0.35% 0.3% 0.25% 0.2% 0.15% 0.1% 0.05% 0% Time (s) Figure 10: Step response for servers in rack 2, when their resource usages start at 0% and are increased to percentages evenly distributed between 0% and 85% at time 500s. Knowing that the model has an adequate behavior for simple test cases, a more advanced demonstration of the model s capabilities was done. This time, the temperature of server 1 in rack 2 was monitored. The simulation started in its usual steady state. At several points in time, there would be steps in the input signals. At 500 s, all server resource usage would go from 0% to 95%. At 1500 s, the airflow of CRAHs 1 would be changed from 2.18m 3 /s to 1.3m 3 /s and at 3000 s, the same thing would happen with CRAH 2. At 4500s, the outlet temperatures of CRAH would change from 18 C to 27 C and at 6000 s, the same thing would happen with CRAH 2. Finally, at 8500 s, all input signals would change to their original values. The results are shown in figure 11. The simulation illustrates all the ways that the temperature of a server in rack 2 can be changed. The time it takes for the temperature to return to its original value is approximately 20 min, indicating that this is how long it would take for this server to return to normal temperatures after a cooling system failure. 21

28 Time (s) Figure 11: A simulation of the temperature of server 1 in rack 2 when its resource usage increases from 0% to 100% at 500s, the airflow decreases from 2.18 m 3 /s to 1.3 m 3 /s for CRAH 1 at 1500 s and CRAH 2 at 3000 s, the output temperature increases from 18 C to 27 C for CRAH 1 at 4500 s and CRAH 2 at 6000 s, and all input signals are returned to their original values at 8500 s. An important result revealed by the model validation tests in this section is that the time delays of the airflows from the CRAH units are much smaller than the settling times of the server temperatures. This means that they can safely be ignored when deriving the internal models for the controllers, described in sections 5 and 6. 3 Power usage of the cooling system With the data center model developed, the next step is to model the power usage of the cooling system. The following subsections describe the derivation and validation of the data center s power usage model. 3.1 Power usage model The cooling power has two parts: The power used by the chiller supplying cold water to the CRAH, and the power used by the CRAH to maintain the airflow. The power usage of a CRAH can be estimated when its outlet temperatures and airflows are known, as well as its inlet temperature. This is described in subsections and To simplify calculations, the inlet temperature is assumed to be the same for all CRAHs. Subsection describes how to choose it appropriately Indices, parameters and variables This chapter will reuse indices, parameters and variables introduced in table 1. It introduces the variables listed in table 6. As the parameters introduced in this chapter are not reused in equations other than those they are introduced in, they will not be listed in 6, but will be given with explicit values and explanations when they are introduced. Variable T in (t) P i,cooling (t) P i,fan (t) Description Inlet temperature to the CRAH units at time t The heat removal rate of the chiller associated with CRAH i at time t The power usage of the fan of CRAH i at time t Table 6: Parameters and variables introduced for the power usage model 22

29 3.1.2 Power usage of the chiller Firstly, an estimate of the power usage of the chiller will be derived. Let T in (t) be the inflow temperature and T i,out (t) be the supplied temperature of CRAH i at time t. It is from here on assumed that T in (t) is greater than T i (t), since that will be the case in realistic situations where the output temperature of the CRAH does not change rapidly. If the CRAH shall supply air with a flow a i (t), the heat removal rate of its chiller must be P i,cooling (t) = c p ρa i (t)(t in (t) T i,out (t)). (11) The coefficient of performance (COP) of a chiller is the ratio of heat removed to the amount of work needed to remove that heat. To estimate the COP, a model is taken from [14]. This model has also been used in [24] and [25]. In this model, the COP is given as COP (T i,out ) = Ti,out T i,out Then, the power consumed by the chiller at time t in order to provide sufficient cooling to CRAH i is estimated by c pρa i (t)(t in (t) T i,out (t)). COP (T i,out (t)) Power usage of the fans Having a model of the chiller s power usage, the next step is to estimate that of the fans. The fan affinity laws state that the volumetric flow out of a fan is proportional to the rotation speed, and that the power usage is proportional to the rotation speed cubed [15]. To use this, a reference point with a given airflow and power usage is needed. According to the specifications for the SEE Cooler HDZ-2, an airflow of 2.18 m 3 /s corresponds to a power usage of 800 W. Therefore, with a i (t) being the airflow of CRAH i at time t, the power usage in W at that time is Estimation of input temperature P i,fan (t) = 800( a i(t) 2.18 )3. (12) What remains is to estimate T in (t). To simplify this, the air in the hot aisle is assumed to be perfectly mixed and the air entering the CRAHs will have the same temperature as that of the hot aisle. With the same kind of reasoning as in section 2.4.5, the temperature in the hot aisle is calculated as a weighted average of the temperatures of the airflows entering it. The weight of each temperature is the ratio of the corresponding airflow to the total emitted airflow of the CRAHs. This includes both airflows through the servers and airflows that bypass the racks. The latter kind of airflows are also assumed to have the same temperature as they had when leaving the CRAH unit. Time delays are applied to the bypassing airflows as well. With this and other previously stated assumptions, T in (t) can be calculated as T in (t) = j=1 k=1 A j,k(t)t j,k,out (t) i=1 (p + (1 p)(1 j=1 s i,j ))a i (t t di (t))t i,out (t t di (t)) s influence 4 i=1 a. i(t t di (t)) (13) 3.2 Validation of the power usage model To see that the power computed by the power usage model is realistic, a validation simulation was performed. A particular consistency requirement for the power usage model is that at steady state, the power removed from the data center must equal the power emitted by the servers. Simulation results indicate that this is the case, and a mathematical proof of this property is presented at the end of this section Simulation results Two simulations were performed in order to validate the power usage model. The scenario in both simulations involved the same step in server usage as described in section Firstly, the total 23

30 power usage of the cooling system was monitored. The result can be seen in figure 12. The step response in power usage looks similar to the step response in rack outlet temperature. This is because when T i,out (t) and a i (t) are held constant, changes in cooling system power usage are proportional to changes in T in (t), which is a linear combination of the changes in T j,k,out (t) Power (W) Time (s) Figure 12: Total power usage of the cooling system when the servers resource usage rises from 0% to 95% at 500 s. A commonly used metric for data centers is the PUE, which is the total power usage of the data center divided by the power usage of the servers. Since the largest contributions of power usage come from the cooling system and the servers, the sum of them can be taken as the total data center power to estimate the PUE. Using the same data as above, a plot of the PUE could be created. This is shown in figure 13. The PUE shown is slightly lower than 1.7, the average PUE reported in a survey from 2014 [22]. However, if the neglected parts of the data center s power usage contribute to 10% of the total power, then the PUE is initially 1.661, a value much closer to the average. 24

31 PUE Time (s) Figure 13: PUE of the simulated data center when the servers resource usage rises from 0% to 95% at 500 s. The second validation was to compare the rate of heat removal with the power emitted by the servers. The results can be seen in figure 14. Initially, the data center is in a steady state with the server power and heat removal rate equal to each other. After the step in the server power, the heat removal rate starts increasing as well, approaching the server power asymptotically. A comparison of figures 7 and 14 shows that as the temperature approaches a steady state, the heat removal rate approaches the server power. 25

32 Heat removal rate Server power usage Power (W) Time (s) Figure 14: A comparison of the power emitted by the servers and heat removal rate from the data center Proof of consistency This section presents a proof of the fact that at steady state, the heat emission rate of the servers is equal to the heat removal rate of the CRAH units. Assume that the data center is in a steady state. For the remainder of this section, variables that are generally time-dependent will be written without explicitly indicating this time dependency, e.g. T in (t) and a i (t) will be written as T in and a i. As seen from (11), the total rate of heat removal from the data center is 4 P i,cooling = i=1 Using the expression of T in from (13), 4 c p ρa i (T in T i,out ). (14) i=1 4 P i,cooling = c p ρ ( A j,k T j,k,out + i=1 which simplifies to j=1 k= j=1 (p 1 + (1 p)(1 s i,j ) ))a i T i,out, (15) s influence i=1 4 P i,cooling = c p ρ ( A j,k T j,k,out i=1 Using (3) to identify a i,j gives j=1 k= s i,j ) (1 p)( )a i T i,out. (16) s influence i=1 j=1 4 P i,cooling = c p ρ ( A j,k T j,k,out i=1 j=1 k= ) a i,j T i,out. (17) i=1 j=1 26

33 By (6), T j,k,in 4 i=1 a i,j = 4 i=1 a i,jt i,j, so 4 P i,cooling = c p ρ ( A j,k T j,k,out i=1 j=1 k=1 Using (4) to identify A j,k and simplifying further yields T j,k,in j=1 i=1 4 ) a i,j. (18) P i,cooling = c p ρa j,k (T j,k,out T j,k,in ). (19) i=1 j=1 k=1 In steady state, the left hand side of (7) must be 0, which implies that P j,k = c p ρa j,k (T j,k,out T j,k,in ). Therefore, steady state implies P i,cooling = P j,k. (20) i=1 j=1 k=1 As seen above, the total heat removal rate of the CRAH units is equal to the total heat emission rate of the servers. This concludes the proof. 3.3 Suggestions for model improvements When estimating the power usage as was done here, some complications have been overlooked. This matter will be brought up here, and can be used as suggestions for further work. Firstly, The COP should in general not depend only on T i,out (t), but on T in (t) as well. More specifically, it should depend on the difference between T i,out (t) and T in (t), decreasing when the difference increases. In [14], ignoring the dependency on T in (t) was justified by that there was only one cooling unit in the data center, so that if its output temperature would change by a certain amount, its input temperature would have changed by the same amount in a steady state, keeping T in (t) T i,out (t) constant for steady states. With four CRAH units, this is no longer true. Another issue with using the model from [14] is that individual cooling units have different COP. This suggests that an improvement of the COP estimation would be to use a model adapted to real data from the modeled data center, with dependencies on both T in (t) and T i,out (t). Furthermore, instead of having one inlet temperature for all CRAHs, different temperatures should be estimated for improved accuracy. Finally, one important component of the cooling system power usage was left out of the model: the internal fans of the servers. They are controlled by the IT-equipment s internal controllers, and depending on how they work, their power usage could be affected by external airflow and temperature and airflow input. 4 Preliminary comments to the controller chapters With test models of the servers temperatures and the cooling systems power usage, controllers for the data center could be designed. Two types of controllers were considered: LQR controllers, described in chapter 5, and MPC controllers, described in chapter 6. After that, chapter 7 will be dedicated to describe tests comparing the performance of the controllers. The internal models of the controllers will be based on the previously derived models, but with some differences. As previously mentioned, time delays will be ignored when designing the controllers. Furthermore, the controller models will only include half of the data center and will be expressed in terms of variables associated with racks 1 to 5 and CRAH-units 1 and 2. The two types of controllers will be designed with respect to different objectives. While the LQR controllers aim to keep both control and controlled variables near certain setpoints, the MPC aims to minimize an estimate of the cooling system s power usage. While it is desirable to minimize energy usage with the LQR controllers too, it is not possible to express the energy usage of the cooling system as a quadratic function, which would be needed in order to minimize it explicitly with an LQR controller. An MPC controller using an objective function similar to that of the LQR controllers could have been designed for the purpose of having a more fair comparison between the two control design frameworks. However, this was not done in this thesis, as the main purpose of 27

34 developing an MPC was to explicitly solve the problem of energy minimization under constraints on control and controlled variables. Because of symmetry of the data center and the independence of the variables associated with its two halves, controllers with no terms in their objective functions depending on variables associated with both halves of the data center will be mathematically equivalent to two independent controllers. For the LQR controllers, this is the case. For the MPC controllers, it is not, but in order to reduce computational complexity, the data center is assumed to have the same power usage and initial server temperature distribution in both of its halves, which also means that the controller outputs in both halves are going to be equal. The generalization in order to consider the whole data center is straightforward. 5 LQR control With the LQR controller, the objective is to keep both the server temperatures and the controller outputs at certain reference points. Five LQR controllers were developed: two of them using CRAH outlet temperature as the control variable while keeping the airflow constant, two varying the CRAH airflow with constant outlet temperature and one using both airflow and temperature as control variables. Among the two controllers with the same controlled variables, one would be a classical LQR controller and one an LQI controller. The controller using both airflow and temperature would also be an LQI controller. The distinction between these types of controllers, along with other background theory, will be described in subsection 5.1. After that, subsection 5.2 will describe the derivations of the LQR controllers internal models. Finally, subsection 5.3 describes how the LQR controllers were tuned. 5.1 LQR Theory LQR-controllers aim to optimally control a system defined by the linear state-space equations ẋ = Ax + Bu y = Cx, (21) Where x is the vector of state-space variables, u is the controller output and y is the observed output of the system. The LQR controllers considered here are infinite horizon controllers for linear, time invariant systems, i.e. they solve the problem: min u s.t. 0 x T Qx + u T Ru dt ẋ = Ax + Bu, (22) where A, B, Q and R are constant matrices, R is positive definite and Q is positive semidefinite. If Q can be written as C T C such that (A,B,C) describes an observable and reachable system, the the problem defined in (22) has a solution u = R 1 BP x, where P is the unique positive definite solution of the algebraic Riccati equation [29] A T P + P A P BR 1 B T P + Q = 0. (23) If equations 21 accurately describe the controlled system, the LQR controller will drive the system towards the steady state x = 0. In practice, model inaccuracies may cause x = 0 to not be a steady state of the true controlled system. In that case, the LQR controller can still have a stabilizing effect on the system, but make it get stuck in another state than x = 0. An extension to fix this problem is the LQI controller [30]. The LQI controller extends the state space with v(t) = t Cx(s)ds, yielding the new state space equations 0 [ x [ [ ] [ ] A 0 x B = + u v] C 0] v 0 [ ] [ ] (24) y C 0 x = 0 I v 28

35 The feedback law for the LQI-controller is constructed from (24) analogously to how the feedback law for the LQR controller was constructed from (21). Since the integral variables v will keep increasing or decreasing until the system reaches a state such that Cx = 0, the LQI extension ensures that the system does not get stuck in an undesirable state. 5.2 LQR formulations The LQR model formulations will be derived from the model described in chapter 2. As it was seen in the end of section that the time delays were insignificant in the time scale of the data center s dynamics, time delays will be ignored in this derivation. Since the variables will then all depend on the same time, and the LQR models will be time-invariant, the time dependency of the variables will not be written out explicitly. Any notation not introduced in this subsection will be described in table 1. From equations (9), the explicit relation between T j,k,out, P j,k, a 1, a 2, u j,k, T 1,out and T 2,out can be written as dt j,k,out dt = p idle + (p peak p idle )u j,k C th + c pρ(1 p) 18C th s influence = f(u j,k, a 1, a 2, T 1,out, T 2,out, T j,k,out ) 2 a i s i,j (T i,out T j,k,out ) i=1 (25) To obtain models for LQR controllers, the equation must be linearized around an equilibrium point. The following notation convention will be used: Let v be any variable. Then v 0 denotes the value of that variable around which the model is linearized, and v = v v 0. The equilibrium point, (u j,k,0, a 1,0, a 2,0, T 1,out,0, T 1,out,0, T j,k,out,0 ), is found by fixing u j,k,0, a 1,0, a 2,0, T 1,out,0 and T 2,out,0 and solving equation (26) for T j,k,out,0. f(u j,k,0, a 1,0, a 2,0, T 1,out,0, T 1,out,0, T j,k,out,0 ) = p idle + (p peak p idle )u j,k,0 C th + c pρ(1 p) 18C th s influence 2 a i,0 s i,j (T i,out,0 T j,k,out,0 ) = 0. A general linearized model around the equilibrium point can be expressed as d T j,k,out dt i=1 = f u j,k u j,k + f a 1 a 1 + f a 2 a 2 + f T 1,out T 1,out + f T 2,out T 2,out + f T j,k,out T j,k,out, (26) (27) where f v denotes the partial derivative of f (defined in (25)) with respect to a variable v, evaluated at (u j,k,0, a 1,0, a 2,0, T 1,out,0, T 1,out,0, T j,k,out,0 ). For all LQR formulations, it is assumed that the input variables not used to control the data center are constant, so u j,k and for some controllers either a 1,out and a 2,out or T 1,out and T 2,out [ are ] set to 0. To ensure controllability, the x1 number of controlled variables is reduced to 2: x =. For simplicity, they are modeled as the x 2 average server temperature deviations from a given setpoint of racks 1 and 2, and racks 3, 4 and 5 respectively, i.e. [ ] [ 1 2 ] 18 x1 = 36 j=1 k=1 T j,k,out x 18 2 k=1 T. (28) j,k,out j=3 Considering everything above, the different LQR state space formulations, on the form described in (22), can now be stated. For the temperature LQR controller, the state space model is [ ] T1,out ẋ = Ax + B temp, (29) T 2,out where and [ A = c pρ(1 p) 1 2 ] 2 2 j=1 i=1 a i,0s i,j 0 18C th s influence j=3 i=1 a i,0s i,j B temp = c pρ(1 p) 18C th s influence [ (30) 2 j=1 a ] 1 2 1,0s 1,j 2 j=1 a 2,0s 2,j 5 j=3 a 1 5 1,0s 1,j 3 j=3 a. (31) 2,0s 2,j 29

36 For the airflow LQR controller, the state space model is [ ] a1 ẋ = Ax + B air a 2 (32) with B air = c pρ(1 p) 18C th s influence 2 18 j=1 k=1 s 1 1,j(T 1,out,0 T j,k,out,0) 18 k=1 s 1 1,j(T 1,out,0 T j,k,out,0 [ j= j= j=3 k=1 s 2,j(T 2,out,0 T j,k,out,0) k=1 s 2,j(T 2,out,0 T j,k,out,0 ) ]. (33) For the two LQI controllers that use either airflow or temperature, the state space is extended from the above models with integrals of x 1 and x 2 as described in section 5.1. For the LQI controller that uses both airflow and outlet temperature, the state space model is the LQI extension of the model in equation 34. [ ] [ ] T1,out a1 ẋ = Ax + B temp + B T air. (34) 2,out a 2 As for the matrices in the cost functions, R is chosen to be the identity matrix for the controllers that use only one of temperature and airflow. For the controller that uses both outlet temperature and airflow, R = r temperature r temperature r airflow r airflow, (35) where r temperature and r airflow are tuning parameters. For the classical LQR controllers, the cost matrix for the variables is on the form [ ] 2 0 Q LQR = q, (36) 0 3 and for the LQI controllers, it is 2q Q LQI = 0 3q q int 0, (37) q int where q and q int are tuning parameters. The factors 2 and 3 comes from that x 1 is the temperature average of 2 racks, while x 2 is the temperature average of 3 racks. The procedure of choosing the tuning parameters will be explained in the next subsection. 5.3 Tuning To completely define the LQR controllers, what remains is to state the points around which the data center model was linearized, and the tuning parameters in the LQR cost functions. Also, a signal saturation used for the LQI controller that uses both outlet airflow and temperature Linearization point The linearization points were chosen by considering that if there are upper and lower bounds on the input variables, a reasonable choice is to linearize the model around the average of these bounds. This maximizes the minimum difference between the linearization point of a variable and any of its bounds. In section 2.6.1, upper and lower bounds on the control variables were given: 2.18 m 3 /s and 1.3 m 3 /s for the airflow and 27 C and 18 C for the temperature. The linearization points were thus 22.5 C for the temperatures and 1.74 m 3 /s for the airflows. The power usage at the linearization point was assumed to be 200 W for all servers. With the input variables fixed, the server temperatures to linearize around were determined by solving the steady state equation (26). 30

37 Taking the mean of the steady state server temperatures for racks 1 and 2, and racks 3, 4 and 5 gave the default reference point for the LQR controllers, i.e. the amount to subtract the mean temperatures obtained from the data center model by to get x 1 and x 2 as defined in the previous section. Other reference points were used in other experiments, but if nothing is else is mentioned, the experiments used these reference points, C for the mean temperature of racks 1 and 2, and C for that of racks 3,4 and Signal saturation The LQI controller using both temperature and airflow as control variables was constructed after some experiments had been performed with the other controllers. In these experiments, some of the controllers would output airflow or temperatures outside of the bounds decided on in section To limit the outputs of the new controller, a signal saturation was connected to it. Whenever the LQI controller would call for an airflow or temperature outside of the upper or lower bounds, the signal saturation would reduce this control output to the closest bound. The signal saturation was used in all experiments, both the tuning experiments and the ones described in section Tuning experiments The tuning parameters were determined by the heuristic that the controller should drive the system to a point twice as quickly as the open loop system would move there given a step input in power usage. More specifically, the time constant for the response in the first case should be half of that in the second case. This criterion was chosen in order to make sure that the controller would make the system respond significantly faster to inputs, but also to limit the aggressiveness of the controller. Two types of tuning experiments were performed. First, an open loop simulation was done. The initial state of the data center was the same linearization point as described above, but the power usage was instantly set to 100%. The server temperatures were given some time to settle, and at simulation time t = 3000 s the power usage of all servers was dropped to 50% again. The total simulation time was 6000 s. The measured outputs were the mean temperature deviation of racks 1 and 2 that of racks 3,4 and 5, i.e. x 1 and x 2. Let τ 1,rise and τ 1,fall be the time constants for the response of x 1 to the increase and decrease in power usage respectively, and let τ 2,rise and τ 2,fall be the corresponding for x 2. These time constants were determined by solving x 1 (τ 1,rise ) = e 1 x 1 (0) + (1 e 1 )x 1 (3000), x 1 (τ 1,fall ) = e 1 x 1 (3000) + (1 e 1 )x 1 (6000), τ 1,fall > 0, x 2 (τ 2,rise ) = e 1 x 2 (0) + (1 e 1 )x 2 (3000), x 2 (τ 2,fall ) = e 1 x 2 (3000) + (1 e 1 )x 2 (6000), τ 2,fall > 0 (38) As the outputs of the data center model were discrete time-series, the equations above were solved approximately by finding the values of x 1 and x 2 in the time series that would minimize the absolute value of the difference between the left and right sides of the equations above. With values of the time constants and of x 1 and x 2 at t = 3000 s, the next phase of the tuning experiments could begin. The experiments was similar to that for the open loop system, but with the controller connected, and the step input was in the controller s reference signal instead of in the power usage. From t = 0 s to t = 3000 s, the values of x 1 (3000) and x 2 (3000) from the previous experiment would be added to the usual reference signal of the LQR controller. Time constants were computed analogously as for the first tuning experiments. The parameters of the different LQR controllers were adjusted by trial and error until one of the time constants of the current closed loop experiment were equal to half of the corresponding time constant in the open loop experiments ±1s and the other time constants were less than half of their corresponding counterparts. The results of the tuning experiments are shown in table 7. For the LQI controllers, q was chosen significantly larger than q int. Despite this, q int had a great impact on the controller behavior, as can be seen by the very different behavior for the LQI and LQR controllers in the tests of section 7. 31

38 Controller τ 1,rise τ 2,rise τ 1,fall τ 2,fall q q int r airflow r temperature (s) (s) (s) (s) Open Loop LQI airflow LQR airflow LQI temperature LQR temperature LQI airflow & temperature Table 7: Time constants for the LQR tuning experiments and the chosen tuning parameters giving those time constants. 6 MPC control With the MPC controller, the objective is to minimize the energy usage of the CRAH units during a given prediction horizon, while satisfying upper- and lower-bound constraints on CRAH outlet airflow and temperature, and on server temperature. To simplify this problem, time discrete versions of the models in sections 2 and 3 are used. Time delays are not considered, in accordance with the conclusion at the end of section The optimization variables are the CRAH outlet airflow and temperature evaluated at the different discrete points in time. The table below presents the parameters and variables used in the time-discrete formulation. For parameters not listed in this table, see the the tables in section 2. Index n Parameter N t Variable t n u j,k T j,k,n a i,n T i,n,out Description Index of the time steps, n 0,..., N Description Number of time steps for which the server temperatures are predicted Length of a time step. Description The time at n time steps from the beginning of the prediction horizon. t n = n t The resource usage of server k in rack j. It is assumed to remain constant throughout the MPC s prediction horizon. The time-discrete approximation of the temperature of server k in rack j at time t n. The outlet airflow from CRAH unit i at time t n The outlet temperature of CRAH unit i at time t n Table 8: A table showing the variables in the time-discrete formulation of the data center model. 6.1 Overview of MPC MPC (Model Predictive Control) is a term for a broad range of control strategies with the following characteristics [28]: Explicit use of a model to predict the state of the controlled system at discrete points in time (the prediction horizon). Calculation of a sequence of control signals, one for each time point in the prediction horizon, that minimizes some objective function. A receding prediction horizon. The first control signal of the calculated sequence is used as input to the system and then the calculations are redone with the horizon displaced one step into the future. 32

39 What follows is a general mathematical description of an MPC control strategy, according to [27]. Let x(n) be a description of the state of the controlled system at time point n, and x(k, x 0 ) be the predicted state of the system k time steps into the future, given that it started in state x 0. let u(k) be the k : th calculated control signal, and u( ) be the full sequence of control signals. Let the MPC s model of the system s dynamics be described by x(k + 1, x 0 ) = f(x(k, x 0 ), u(k)). Denote by UX N (x 0, n) the set of admissible control sequences at time point n. The control sequences in the set must at that point in time and onwards be possible for the controller s actuator to output. They are also required to keep the predicted state of the system in the set X of allowed states throughout the prediction horizon of N future points, given that it starts at state x 0. Let the objective of the MPC controller be defined by the functions l(n + k, x(k, x 0 ), u(k)) and F (n + N, x(n, x 0 ), u(n)), in the sense that it aims to control the system in order to minimize N 1 k=0 l(n + k, x(k, x 0), u(k)) + F (n + N, x(n, x 0 ), u(n)). The MPC algorithm is as follows: 1. Sample the current state x(n) of the system and set x 0 := x(n) 2. Solve the optimization problem N 1 minimize l(n + k, x(k, x 0 ), u(k)) + F (n + N, x(n, x 0 ), u(n)) k=0 with respect to u( ) U N X (x 0, n) subject to x(k + 1, x 0 ) = f(x(k, x 0 ), u(k)), x(0, x 0 ) = x 0. k 0,..., N (39) 3. Let the controller actuator output the first control signal u (0) of the calculated optimal sequence u ( ). Increase n by 1 and go to step 1. For the classical control problem of setpoint tracking, l(n+k, x(k, x 0 ), u(k)) would be a measure of the predicted distance from a desired setpoint and F (n + N, x(n, x 0 ), u(n)) a terminal cost added in order to make sure that the controlled system will remain stable beyond the prediction horizon. In this case, some stability results of MPC have been established. In the more general case where a desired trajectory is not known beforehand, l(n + k, x(k, x 0 ), u(k)) can be seen as a cost of the predicted state and control signal at time step n + k. This case is known as economic MPC, and although it can be motivated heuristically, it is by no means clear that optimality and stability holds for an MPC in this general case[27]. In order to solve the MPC optimization problem with a general purpose optimization solver, it has to be transformed into the generic form of optimization problems as described in equation (40). minimize F (x) subject to G(x) 0, H(x) = 0. A reformulation of (39) to fit a standard form (40) is mostly straightforward, but one thing that needs to be decided is whether the state variables should be considered as variables in the optimization problem or not. Including these variables as optimization variables is called full discretization, and in this case, the system dynamics can be written as an equality constraint. While this way of formulating the problem has the advantage that an initial guess can be provided for the trajectory of the system s states, its disadvantage is the large number of optimization variables. In order to reduce the number of variables, the prediction of the system s future states can be decoupled from the solution of the optimization problem. This is done by letting an external function compute the state variables as a function of a control signal sequence and have this function called inside the objective and constraint functions provided to the optimization solver. This is called recursive discretization, and it is preferable when there is no prior knowledge of an optimal trajectory for the system. There is also a hybrid method, multiple shooting discretization, where some of the state variables are treated as variables in the optimization in order to have initial guesses for them [27]. As for the MPC considered in this thesis, it is an economic MPC as its aim is to minimize energy usage. A short computation time is important in this case, and an initial guess for the trajectory is not, so the optimization problem formulated will be based on recursive discretization. (40) 33

40 6.2 Optimization problem formulation In this subsection, the optimization problem solved by the MPC will be derived. To begin with, let the prediction horizon of the MPC controller be t N. The total energy usage over that prediction horizon according to the model developed in chapter 3 would be tn 0 2 i=1 c p ρa i (t)(t in (t) T i,out (t)) T i,out (t) T i,out (t) (a i(t) 2.18 )3 dt (41) and it should be minimized subject to the data center dynamics described in equations (9), initial conditions for all time dependent variables and some upper and lower bounds for the controller outputs and server temperatures. These upper and lower bounds are chosen to be the same as those mentioned in section 2.6.1, i.e. 1.3 a i (t) 2.18, 18 T i,out (t) 27, T j,k,out (t) 35. (42) A lower bound of 18 for T j,k,out (t) was also used initially. However, it was removed because it would never be enforced. as the server temperatures could never get lower than the CRAH outlet temperatures unless they started lower. To simplify this infinite-dimensional problem, the integral and the data center dynamics will be discretized by the forward Euler method, chosen as it is easy to implement. All time delays will be ignored. Also, the objective and nonlinear constraint functions will be expressed in terms of control and controlled variables. Before discretizing the integral in equation (41), the integrand will be expanded and expressed directly in terms of constants, server temperatures, CRAH airflows and temperatures. This will be done in steps outlined below. Time dependent variables will not have their time dependency explicitly denoted. Another notation convention here is that if there are multiple independent sums with respect to the index i some of the sums will use the indices i, i and i instead, but all of these mean that a sum is taken with respect to the index denoting the different CRAH units. Firstly, the integrand of equation (41) is expanded by using the expression for T in from equation (13). Note that with the assumption that the two halves of the data center have the same server temperatures, power usages and controller outputs, the sums for calculating T in need only be taken over i {1, 2} and j {1,..., 5}. The expanded integrand becomes 2 i=1 c p ρa i T 2 i,out T i,out ( 5 18 A j,k T j,k,out + j=1 k= ( a i 2.18 )3. ( 2 (p + (1 p)(1 i =1 Secondly, equation (4) is used to exclude A j,k, giving the expression 5 j=1 s i,j ) / 2 ) ))a i T i,out a i T i,out s influence i =1 (43) 2 i=1 c p ρa i T 2 i,out T i,out ( 5 18 j=1 k= a i,jt j,k,out + i = ( a i 2.18 )3. ( 2 (p + (1 p)(1 i =1 5 j=1 s i,j ) / 2 ) ))a i T i,out a i T i,out s influence i =1 Thirdly, equation (3) is used to replace a i,j in the previous expression, yielding (44) 34

41 2 c p ρa i ( Ti,out T i,out i=1 ( 5 18 j=1 k=1 2 i = i =1 s i,j s influence (1 p)a i T j,k,out + a i T i,out ) + 800( a i 2.18 )3. 2 (p + (1 p)(1 i =1 5 j=1 s i,j ) / ))a i T i,out s influence (45) With the integrand now in terms of a i, T i,out, T j,k,out and constant parameters, the integral will now be discretized. The objective function for the MPC s optimization is as below. ( N 2 c p ρa i,n Ti,n,out T i,n,out n=1 i=1 ( 5 18 j=1 k=1 2 i = i =1 s i,j s influence (1 p)a i,nt j,k,n + a i,n T i,n,out ) + 800( a i,n 2.18 )3 ) t ( 2 (p + (1 p)(1 i =1 5 j=1 s i,j ) / ))a i,nt i,n,out s influence (46) T j,k,n are not optimization variables, but computed from the control variables, according to a timediscretized form of the data center s dynamics. Discretizing equation (25) gives T j,k,n+1 T j,k,n t = p idle + (p peak p idle )u j,k C th + c pρ(1 p) 18C th s influence 2 a i,n s i,j (T i,n,out T j,k,n ) (47) i=1 The complete optimization problem can be stated as follows: ( N 2 c p ρa i,n min a 1,1,...,a 1,N,a 2,1,...,a 2,N, Ti,n,out T i,n,out T 1,1,out,...,T 1,N,out,T 2,1,out,...,T 2,N,out n=1 ( ( i =1 s.t. j=1 k= i =1 i=1 s i,j s influence (1 p)a i,nt j,k,n + a i,n T i,n,out ) + 800( a i,n 2.18 )3 ) t 18 T i,n,out 27, i {1, 2}, n {1,..., N}, 1.3 a i,n 2.18, i {1, 2}, n {1,..., N}, T j,k,n 35 2 (p + (1 p)(1 i =1 j {1,..., 5}, k {1,..., 18}, n {1,..., N}, 5 j=1 s i,j ) / ))a i,nt i,n,out s influence Where T j,k,n are computed from the optimization variables and T j,k,0 according to T j,k,n+1 T j,k,n = p idle + (p peak p idle )u j,k + c pρ(1 p) 2 a i,n s i,j (T i,n,out T j,k,n ), t C th 18C th s influence i {1, 2}, j {1,..., 5}, k {1,..., 18}, n {0,..., N 1}. (48) The initial implementation of the MPC was according to the formulation above. However, the computation time of that MPC was considered too long for applications or for running tests efficiently. Therefore, a relaxed problem formulation was implemented. In this formulation, the server temperature constraints were not included for all servers, but only for those that were estimated to run the greatest risk of violating those constraints. For each rack, temperature constraints would be enforced throughout the prediction horizon on the server with the highest initial temperature. i=1 35

42 If the IT load would shift very abruptly, a constraint violation could be possible if the IT load would shift so abruptly that a server which temperature is not constrained attains maximum temperature in its rack during the time period that the calculated controller outputs are used to control the data center. Since only T 1,1,out, T 2,1,out, a 1,1 and a 2,1 would be used, this problem can be mitigated by choosing t to be insignificant in relation to the time scale on which changes in the IT load happens. The mathematical formulation of the relaxed problem is identical to the original (48) except for the server temperature constraint, which can be expressed as below. T j,kj,max,n 35, k j,max = argmax T j,k,0, j {1, 2, 3, 4, 5}, n {1,..., N}. k {1,...,18} (49) 6.3 Tuning To implement the MPC as described in the previous sections, decisions must be made about the values of t and N, as well as about which optimization algorithm to use to solve the problem. For the experiment described in the controller tests section, the server s power usage was given by a time series with a difference of s between each sample. To match that, t was set to In the experiment, the IT load of the servers would shift every 30 min, so N was set to 50 to get a prediction horizon of approximately that length. As for the choice of algorithms, several experiments were conducted in order to compare the performance of the algorithms available with MATLAB s solver fmincon. These experiments, and their conclusions will be described below MPC tuning experiments To test which settings of the optimization solver that would provide the best performance, a total of 72 experiments were conducted. In these experiments, the solver was given the steady state around which the LQR controllers were linearized around as the initial condition. The optimization problem was solved for four different prediction horizons: 50 s, 100 s, 200 s and 400 s, with a time-step length of 2 s, 5 s or 10 s. For each combination of time step length and prediction horizon, the optimization problem was solved with the fmincon interior point, SQP and active set algorithms [26]. For each algorithm, two initial guesses for a solution of the problem were tested: The first was that the cooling system should run at maximum capacity, i.e. the CRAHs would output an airflow of 2.18 m 3 /s with temperature 18 C. The second was that the cooling system would run at minimum capacity throughout the prediction period, with CRAH temperature 27 C and airflow 1.3 m 3 /s. All algorithms were run with their default tolerance settings and limits on the maximum number of function evaluations, and plots of the objective function values were created Tuning experiment results The results of the tuning experiments indicated that the optimization problem would be difficult to solve. The different algorithms usually found solutions with different objective values, and different initial guesses also yielded different results. This has several possible explanations. The objective function could have a region where it is very flat, making the solvers stop prematurely. Also, the problem could be non-convex and have several local minima. For a larger number of time-steps, the solver did not converge to a solution that satisfied a local optimality condition. Instead, it stopped because the maximum number of allowed function evaluations had been reached. The difficulties of this optimization problem can be illustrated by figure 16 and table 9. In the figure, the objective function value remains almost the same from iteration 2 to iteration 42, indicating a flat objective function. The table shows the objective function values of the solutions in the tuning experiments and whether or not the solver actually managed to find an optimal solution. In the experiment with a prediction horizon t N = 400 and a steplength t = 2, the SQP and active set algorithm both converge to solutions that satisfy local optimality but have very different objective function values, indicating the existence of multiple local minima. This issue could be remedied by the usage of global optimization algorithms, but that was not explored in this thesis. 36

43 t Starting guess t N = 50 t N = 100 Interior SQP Active Interior SQP Active point set point set 2 max min max min max min t Starting guess t N = 200 t N = 400 Interior SQP Active Interior SQP Active point set point set 2 max min max min max min Table 9: A summary of the tuning experiment results. The objective values of the solutions generated by the optimization algorithms are listed. A green value means that the solution satisfied the solver s local optimality criterion, a red one means that the solver stopped because the limit of number of function evaluations was reached, and a blue value means that the solver stopped because a minimum steplength criterion was satisfied, but the generated solution was not feasible. The experiments did show a few important trends in the performance of the algorithms when finding local minima. As mentioned earlier, the interior point algorithm hit the limit of its number of function evaluations most often, while the other two algorithms managed to converge to a local minima in about half of the experiments. The interior point algorithm stopped with the shortest amount of time due to hitting this limit, while the SQP algorithm, whether it managed to converge or not, always finished faster than the active-set algorithm. Below are three figures illustrating that characterize how the different algorithms would converge to a solution. The plots are taken from the experiment where t = 2, N = 100 and the initial guess is that the fans should output an airflow of 2.18 m 3 /s with temperature 18 C throughout the prediction horizon. 37

44 Interior point algorithm convergence plot Objective function value Iteration Figure 15: A plot showing how the objective function changed with each iteration when the interior point algorithm was used. The solver only made 7 iterations before it stopped because it exceeded the limit for number of function evaluations SQP algorithm convergence plot 3 Objective function value Iteration Figure 16: A plot showing how the objective function changed with each iteration when the SQP algorithm was used. As seen, the objective function first decreased quickly and then remained around the same value throughout the iterations. The solver stopped because the computed step was shorter than the lowest step tolerance. However, the solver s constraint tolerance and optimality condition were not met. 38

45 Active set algorithm convergence plot 3 2 Objective function value Iteration Figure 17: A plot showing how the objective function changed with each iteration when the active set algorithm was used. The solver indicated that the found solution fulfilled local optimality conditions. However, the plot also shows an undesirable volatility of the objective function. Since the interior point algorithm requires strict feasibility in all its iterations, a new initial guess was generated by the solver before starting the iterations, explaining why the interior point algorithm has a lower objective function value in its first iteration. Note the relatively low number of iterations in figure 15 compared to those in figures 16 and 17. The interior point algorithm requires more function evaluations per iteration than the SQP and active set algorithms. A comparison of figures 16 and 17 shows that for both the active set and the SQP algorithms, the objective function decreases rapidly until iteration 2 and then does not decrease. However, the difference is that while the objective function stays relatively constant for the SQP algorithm, it makes sudden oscillations for the active set algorithm. Such volatility is undesirable, since the solver could then potentially exceed the limit of number of function evaluations at an iteration when it has generated a bad solution. With all this considered, the chosen algorithm for the MPC was SQP. Even though it did not find the best solution in all experiments, it seemed more reliable than the active set algorithm. With all algorithms using their default function evaluation limits, it succeeded to converge more often than the interior point algorithm. 7 Controller tests and results With all controllers defined, implemented and tuned, the next thing to do was test them with the data center model. To make the test realistic, the power usage of the server was to be based on real data. A detailed description on how this data was treated and how the test was designed will be given in the first subsection of this section. The results will be presented in tables and figures in the second subsection. The aim of the tests was to study the behavior of the different LQR controllers described in section 5 and the MPC in section 6 during two different scenarios, to draw conclusions about the pros and cons of the different types of regulators. The LQR controllers were used in two ways in the experiments. The first way was to have them control the average temperatures of the servers in the rack groups, in the way that they were designed to. The second way was to have them control the maximum server temperatures in those racks, as that could make it easier to avoid overheating, provided that the LQR controllers could control the maxima in a stable way. 39

46 7.1 Test description In this subsection, the simulation scenarios used to test the controllers will be described. The simulations were going to be based on real data, although this data had to be altered and reinterpreted before it could be used. How this was done is described in the first three parts of this subsection. Then in the final parts, the experimental procedures for all series of tests are described Experimental data generation The data available was a weighted average of the number of processes running or waiting to run on six different servers in the Luleå data center. Three different time series with different weight functions were given. For each of them, the weight function would decay exponentially with time from the measurement point and decrease by a factor e 1 for a time of 1, 5 and 15 min respectively. The utilized interpretation of the data was as follows: If the weighted average was 1 or greater, the server was assumed to have a 100% utilization percentage, otherwise, the server utilization at a certain point in time was assumed equal to the weighted average. The time series used in the simulations were chosen to have piecewise constant server utilizations that changed every 30 min, and each constant measurement corresponded to one value of the load in the initial data files. To have data for 90 servers, the load measurements for one server during a longer period in the original files was used as load measurements for several servers during a shorter time period in the simulations, and data from different files was concatenated into one time series for the simulation data. The time series were set to have uniformly spaced time points, making the time difference between two points s. The data was further modified to create two different scenarios that would be interesting to study. These will be described and motivated below Scenario 1 In the first scenario, one server in each rack was set to always run at full capacity, and another to use 0% of its capacity. This would create a maximum difference between server temperatures in each rack, making it necessary to use low set points when controlling mean temperatures using the LQR controllers. Figure 18 shows the average server utilization according to the time series that was used in this scenario. The distinct behavior of the server usage at different time periods makes it easy to see how the other measured quantities in the experiments are related to the server utilization Average server utilization Time (s) 10 5 Figure 18: A plot of the average server utilization throughout the first simulation scenario. Note the long time period between s and s where this average is essentially constant 40

47 7.1.3 Scenario 2 In this the second scenario, no servers were set to have constant capacity usage throughout the whole simulation. Instead, during alternating 30 minute periods, either the servers in racks 1, 4, 5, 6, 9 and 10 or the servers in racks 2, 3, 7 and 8 were set to run at 0 % capacity while the other servers worked as normal. This would cause the maximum temperature to shift between servers with different temperature dynamics, presenting a potential difficulty for LQR control of the maximum temperature. Figure 19 shows the average server utilization according to the time series that was used in this scenario. As can be expected, a comparison between this figure and 18 shows that the average server usage is lower in this scenario. The alternation in usage between the two groups of serves can be seen in the average, since a different number of servers are set to run at their lowest capacity in different time intervals Average server utilization Time (s) 10 5 Figure 19: A plot of the average server usage throughout the second simulation scenario. The average in this scenario has features similar to that in the first scenario, but is lower and oscillates due to an alternating number of servers running at their lowest capacity Initial tests of the LQR controllers With the data for server utilization generated as previously described, experiments with the different controllers could be conducted. Initially, eight tests per scenario were performed. These initial tests were done with the two classical LQR controllers and two LQI controllers, one using the CRAH airflows and the other using the CRAH outlet temperatures as control variables. Two tests were done with each type of controller. In one of them, the controller received two temperature averages and in the other, the controller received two temperature maxima as feedback. One average or maximum was taken over the servers in racks 1 and 2, and the other over those in racks 3, 4, and 5. These temperature averages and maximums were subtracted by the controller s reference point, which in the initial two tests of the controller in each scenario was 35 C. The initial temperature of all servers was also set to 35 C Tests of the LQR controllers with adjusted setpoints In the initial tests, maximum temperature reached by any server during the testing period would be recorded. Then, eight tests for each scenario with adjusted setpoints for the controllers would be performed. If T max was the maximum temperature of any server in the initial test with a given combination of controller and controlled variables, the setpoint for these controlled variables and 41

48 that controller in the second series of tests would be 2 35 T max. Otherwise, the second series of tests would be identical to the first Tests of the LQI controller using both temperature and airflow as control variables The LQI controller using both outlet airflow and temperature as controlled variables was tested in a similar way to the other LQR controllers. Four tests was performed with it, two for each scenario. In one test, it would have a setpoint of 35 C for the controlled temperatures, and in the other, the setpoint would be adjusted according to what was described in In all tests, the maximum temperatures of the two groups of racks were used as the controlled variables Tests of the MPC controller The testing of the MPC was done similarly to the testing of the LQR controllers, but it would have all server temperatures as its feedback, and no set-point would need to be specified for it. Therefore, only one test for each scenario was carried out with it. To compensate for the longer time for the MPC controller to compute its output, the MPC test used a shortened version of the simulation scenario that was used for the LQR controllers: only the first 101 time steps, or s of the server usage time series were used. 7.2 Results This section of the thesis consists of two parts highlighting different aspects of the results. Section contains tables presenting computed performance indices for all simulations, while section shows graphs from simulations of particular interest Tables Performance indices computed from the results of the LQR controller simulations are listed in tables 10 and 11. Furthermore, tables 12 and 13 lists these performance indices for the MPC simulations and for the first s of some of the LQR simulations. Two independent performance indices were measured: Integrated temperature constraint violation and total energy usage. Let T be the total simulation time for this test. The integrated temperature constraint violation in the tables is computed by a numerical approximation of 5 18 T j=1 k=1 0 max(t j,k(t) 35, 0)dt using the trapezoidal method. Dividing this by T and 180 gives the average constraint violation per server, also recorded in the tables. Similarly, the average power usage is the total energy usage divided by T. 42

49 LQR Temp. Feedback Setpoint Integrated Average Total Average or or variable ( C) temperature constraint energy power LQI Airflow (racks constraint violation usage usage mean or violationn per server (GJ) (kw) maximum) (s C) ( C) LQR Temp. Mean LQR Temp. Mean LQR Temp. Maximum LQR Temp. Maximum LQI Temp. Mean LQI Temp. Mean LQI Temp. Maximum LQI Temp. Maximum LQR Airflow Mean LQR Airflow Mean LQR Airflow Maximum LQR Airflow Maximum LQI Airflow Mean LQI Airflow Mean LQI Airflow Maximum LQI Airflow Maximum LQI Both Maximum LQI Both Maximum Table 10: A summary of the results from the LQR tests in scenario 1. Table 10 shows the performance indices of the LQR tests in the first scenario. One row in the table immediately stands out from the rest: The LQI airflow controller trying to control the average temperatures of the two groups of racks to C has an unreasonable energy usage. This is caused by the procedure from section prescribing a lower setpoint for the average temperatures than for which the linearized data center model is valid. No matter how much the controller increases the airflow, the average temperatures of the racks can not decrease below the outflow temperature from the CRAHs, in this case 22.5 C. The performance index values from that test will be disregarded in the discussion of the results. When the setpoints of the controllers were not adjusted, the controllers performed better in terms of constraint violation when they controlled the maximum values than when they controlled the maximum values. However, the controllers with the lowest constraint violation after adjusting the setpoints were those controlling mean values, because their setpoints were adjusted to be far from 35 C. The lowest energy usage was measured for controllers controlling mean temperatures with a reference point of 35 C, but they would also have the greatest constraint violation. Among the controllers with adjusted temperature setpoints, the controller with the lowest energy usage was the LQI controller controlling the maximum temperatures using CRAH airflow. As can be seen in figure 20, this controller manages to keep the maximum temperature nearly constant and close to 35 C. 43

50 LQR Temp. Feedback Setpoint Integrated Average Total Average or or variable ( C) temperature constraint energy power LQI Airflow (racks constraint violation usage usage mean or violationn per server (GJ) (kw) maximum) (s C) ( C) LQR Temp. Mean LQR Temp. Mean LQR Temp. Maximum LQR Temp. Maximum LQI Temp. Mean LQI Temp. Mean LQI Temp. Maximum LQI Temp. Maximum LQR Airflow Mean LQR Airflow Mean LQR Airflow Maximum LQR Airflow Maximum LQI Airflow Mean LQI Airflow Mean LQI Airflow Maximum LQI Airflow Maximum LQI Both Maximum LQI Both Maximum Table 11: A summary of the results from the LQR tests in scenario 2. Table 11 shows the performance indices of the LQR tests in the second scenario. The values in table 11 show some similar trends to those in table 10. Once again, the constraint violation is lower for the setpoint 35 C when the controllers control the maximum temperatures than when they control the mean temperatures. Also, the setpoints are adjusted to be lower in the cases where mean temperatures are controlled than in the corresponding cases with maximum temperature control. Contrary to the test results in scenario 1, the maximum temperatures in scenario 2 would be notably greater than 35 C when the LQI controllers controlled the maximum temperature with setpoint 35 C, thereby the lower adjusted setpoints for these controllers in table 11. Towards the end of a period of constant IT load, the LQI controller would have adapted its output so that the servers with the maximum temperatures in the two rack groups would be in a steady state. As soon as the IT load changes, the LQI controllers would need some time to adapt. During this time, there would be a spike in the maximum temperatures. In all the simulations where the temperature setpoint was adjusted, the classical LQR controllers would have a lower energy usage than their LQI counterparts. The controller with the lowest energy usage after its setpoint was adjusted was the LQR controller controlling the mean temperatures of the rack groups. This does not necessarily mean that it has the best performance. When this controller controls the maximum temperature instead, it has a much lower average constraint violation and only a slightly higher average power usage. 44

51 Scenario Integrated Average Total Average temperature constraint energy power constraint violation usage usage violation per server (MJ) (kw) (s C) ( C) 1, Servers with constant capacity usage 2, Alternating server usage Table 12: A summary of the results from the optimization tests. Table 12 shows the performance indices for the two MPC simulations. Since these simulations are done over a shorter time period than the LQR simulations, the total energy and integrated constraint violation can not be directly compared using the previous tables. To have a valid comparison between the LQR and MPC controllers, the performance indices for the LQR controllers must be computed for the same time period. Table 13 shows these performance indices, computed for all the LQR controllers with adjusted setpoints except the LQI airflow controller controlling the mean temperatures of the rack groups. Since the time series from the LQR tests do not have measurements at exactly the same times as the time series from the MPC tests, the actual computations are done using the points in the time series that lie within the first s. The actual time interval over which the performance indices and their time averages are computed is thus shorter than s for the LQR controllers. The length of this time interval for each LQR controller is shown in the last column of table

52 LQR Temp. Feedback Setpoint Integrated Average Total Average Time or or variable ( C) temperature constraint energy power (s) LQI Airflow (racks constraint violation usage usage mean or violation per server (MJ) (kw) maximum) (s C) ( C) Scenario 1 LQR Temp. Mean LQR Temp. Maximum LQI Temp. Mean LQI Temp. Maximum LQR Airflow Mean LQR Airflow Maximum LQI Airflow Maximum LQI Both Maximum Scenario 2 LQR Temp. Mean LQR Temp. Maximum LQI Temp. Mean LQI Temp. Maximum LQR Airflow Mean LQR Airflow Maximum LQI Airflow Maximum LQI Both Maximum Table 13: A table of the performance indices for the LQR controllers with adjusted setpoints, calculated for only the sample points in the time series within the first s of the simulation scenarios. As seen by comparing tables 12 and 13, the MPC has a lower energy usage than all the LQR controllers. In the first scenario, the difference between the MPC s energy usage and the best performing LQR controller s energy usage is less than 2 % of either controllers energy usage, suggesting that with a well chosen setpoint for the control variables, the LQR controller could actually have a lower energy usage than the MPC, due to its advantage of being able to adjust its output continuously. In the second scenario, the difference between the MPC s energy usage and that of the LQR controllers is greater. As will be seen in the figures below, the MPC is able to handle the abrupt server usage variations without large changes in the maximum temperature. One final thing to note is that for the first s of the simulation, the controllers that have the lowest energy usage are not the same as the ones for the full simulation, showing that it is not clear which of the LQR and LQI controllers that will have the lowest energy usage in a particular scenario Figures This section consists of figures with graphs of control and controlled variables from a few selected simulations. Each figure consists of 4 sub-figures. The first sub-figure shows the maximum temperature, minimum temperature and average temperature of the servers in racks 1 and 2. The second shows the same for all servers in racks 3, 4 and 5. The third shows the CRAH units output airflows and the fourth their output temperatures. 46

53 The first three figures show the simulations in scenario 1 with the LQI airflow controller controlling the maximum temperatures and the LQR and LQI temperature controllers controlling the average temperatures of the rack groups. The next four show simulations for all LQI controllers when they control the maximum temperatures in scenario 2. The two figures after that shows simulations for the LQR temperature controller controlling the average and maximum temperatures respectively, followed by a figure for the simulation with the LQI temperature controller controlling the average temperatures, all in scenario 2. The following two figure show the shortened simulations with the MPC. The last three show the first s of the following LQR simulations: The LQI airflow controller controlling the maximum temperatures in scenario 1, the LQR temperature controller controlling the average temperatures in scenario 2, and the LQI controller using both outlet temperature and airflow to control the maximum temperatures in scenario 2. In the figures for the LQR controllers, their setpoints are marked with a black dashed line. The upper temperature constraint of 35 C is marked in the figures with a red dashed line, as long as it does not coincide with the controller s setpoint. Minimum, mean and maximum temperature for all servers in racks 1 and 2 Minimum, mean and maximum temperature for all servers in racks 3, 4 and Maximum Minimum Mean Reference Constraint Maximum Minimum Mean Reference Constraint Time (s) 10 5 Airflows from CRAH units 1 and Time (s) 10 5 Outlet temperatures from CRAH units 1 and CRAH Airflow (m 3 /s) CRAH 1 CRAH Time (s) Time (s) 10 5 Figure 20: Figures for the LQI airflow controller controlling the maximum temperatures of the rack groups in scenario 1. Figure 20 shows why the LQI airflow controller that controls the maximum temperatures of the rack groups has both a low constraint violation and a low energy usage compared to other controllers in scenario 1. Throughout the simulation, there are almost no fluctuations in the maximum temperature of the two groups of racks. The integral part of the LQI controller ensures that the airflows are kept near values that keep the controlled maximum temperatures in a steady state at C, even though these values are not the reference points for the controller outputs. The minimum temperatures of the two groups of racks is also unchanging throughout the simulation, except for its decrease from 35 C in the beginning of the simulation. The servers that have those temperatures are the ones that are set to always run at maximum and minimum capacity respectively, and any fluctuations in the average server temperature is caused only by fluctuations in usage of the other servers, as can be seen by comparing the average server temperatures to the 47

54 graph of average server utilization in figure 18. Minimum, mean and maximum temperature for all servers in racks 1 and 2 Minimum, mean and maximum temperature for all servers in racks 3, 4 and Maximum Minimum Mean Reference Constraint Maximum Minimum Mean Reference Constraint Time (s) 10 5 Airflows from CRAH units 1 and Time (s) 10 5 Outlet temperatures from CRAH units 1 and 2 24 CRAH Airflow (m 3 /s) CRAH 1 CRAH Time (s) Time (s) 10 5 Figure 21: Figures for the LQR temperature controller controlling the mean temperatures of the rack groups in scenario 1 The LQR temperature controller controlling the mean temperatures of the rack groups had an energy usage almost as low as that of the LQI controller in the previous figure, and it also had a seemingly low average temperature constraint violation per server, according to table 10. However, figure 21 shows a problem not evident by these table entries. Since the maximum and minimum temperatures of the rack groups will be those of servers that constantly run at either minimum or maximum capacity in scenario 1, the changes in them are caused only by the CRAH units outlet temperatures. Figure 21 shows that the server running at maximum capacity in rack 1 will be overheated, not only occasionally, but throughout most of the simulation. The process of adjusting the temperature setpoint described in section fails here. Choosing an appropriate setpoint is further complicated by that the controller controls the mean temperature and not the max, and that it is not an LQI controller, so there is no guarantee that the setpoint will be reached if the internal model does not correspond to the actual controlled system. 48

55 Minimum, mean and maximum temperature for all servers in racks 1 and 2 Minimum, mean and maximum temperature for all servers in racks 3, 4 and Maximum Minimum Mean Reference Constraint Maximum Minimum Mean Reference Constraint Time (s) 10 5 Airflows from CRAH units 1 and Time (s) 10 5 Outlet temperatures from CRAH units 1 and 2 25 CRAH Airflow (m 3 /s) CRAH 1 CRAH Time (s) Time (s) 10 5 Figure 22: Figures for the LQI temperature controller controlling the mean temperatures of the rack groups in scenario 1. Figure 22 shows that with LQI control instead of LQR control, the simple method used to adjust the temperature setpoint in section works. There is no visible constraint violation in the figure, and table 10 says that the one that is there is minuscule. From what can be seen in figure 22, the LQI controller manages to keep the mean temperatures at the setpoint, although with some small oscillations, and in the initial test, the LQI controller kept the mean temperatures at a similar "nearly steady state" at 35 C. The disadvantage of the LQI controller is that it much more aggressive than the LQR controller. As there are no upper or lower limits on the controller outputs in an LQR or LQI controller, there is a risk that the controller will choose an output outside of an allowed range. In this case, the output temperature of CRAH 2, and thereby the input temperatures of racks 4 and 5, are lower than the ASHRAE recommendations. As signal saturation could be needed if this controller was to be implemented in the real data center. 49

56 Figure 23: Figures for the LQI airflow controller controlling the maximum temperatures of the rack groups in scenario 2. In scenario 2, the LQI airflow controller manages to keep the maximum temperature below 35 C most of the time, after its setpoint has been adjusted. The oscillations in server usage causes some oscillations in maximum temperature, so in order to not violate the temperature constraints, the setpoint for the controller has to be lower in scenario 2 than in scenario 1. The biggest difference between the two scenarios is evident from comparing the graphs of the CRAH airflows in figures 20 and 23. In scenario 1, the airflows are almost constant, while in scenario 2, they alternate between high and low values. CRAH 2 has a high airflow most of the time, either 2.0 m 3 /s or 1.8 m 3 /s depending on which group of servers that is being used beyond their minimum capacity, but it decreases to a low airflow between 0.67 m 3 /s and 0.82 m 3 /s when the server usage shifts from one group to the other. CRAH 1 outputs an airflow between 1.91 m 3 /s and 1.94 m 3 /s when the servers in rack 1 are active and one between 0.75 m 3 /s and 0.95 m 3 /s when they are not. 50

57 Figure 24: Figures for the LQI temperature controller controlling the maximum temperatures of the rack groups in scenario 2. The LQI temperature controller exhibits behavior similar to the LQI airflow controller when it controls the maximum temperatures. With it, CRAH 2 has a low outlet temperature most of the time, but with increases whenever the server usage is shifted between the groups of racks, and CRAH 1 alternates between a low and high outlet temperature. The main difference between the simulations with the temperature and airflow controller is that the oscillations in maximum server temperatures are slightly larger when the outlet temperature is used as the control variable. That the airflow controller would be better at reacting to disturbances is consistent with the results of the tuning experiments in table 7 of section 5.3. There it is seen that in all tuning experiments, the time constants for the airflow controller is equal to or lower than those for the temperature controller. 51

58 Minimum, mean and maximum temperature for all servers in racks 1 and 2 Minimum, mean and maximum temperature for all servers in racks 3, 4 and Maximum Minimum Mean Reference Maximum Minimum Mean Reference CRAH Airflow (m 3 /s) Time (s) 10 5 Airflows from CRAH units 1 and CRAH 1 CRAH Time (s) 10 5 Outlet temperatures from CRAH units 1 and CRAH 1 CRAH Time (s) Time (s) 10 5 Figure 25: Figures for the LQI controller using both airflow and temperature to control the maximum temperatures of the rack groups in scenario 2. Its setpoint is 35 C in this simulation. Most figures for the LQR controllers in this section shows simulation results after the controllers setpoints have been adjusted. However, figure 25 shows a simulation result for the LQI controller using both airflow and temperature when its setpoint is 35 C. Figure 34 further below shows the first s of this simulation. Note how the signal saturation limits the controller outputs. As can be seen in the figure, the maximum temperatures overshoot 35 C as soon as the server usage shifts. This also happens in the simulations for the LQI controllers using only one of temperature and airflow when their setpoint is 35 C. The previous figures show that after adjusting the setpoint for those controllers, the maximum temperature in the simulations rise to a value very close to 35 C. As will be shown in the next figure, the setpoint adjustment method described in section fails for the LQI controller using both temperature and airflow. 52

59 Figure 26: Figures for the LQI controller using both airflow and temperature to control the maximum temperatures of the rack groups in scenario 2. Its setpoint is C in this simulation. Figure 26 show that after the setpoint has been adjusted for the LQI controller using both airflow and temperature according to what was described in section 7.1.5, it is too low. The maximum temperatures now never reach above 34 C except for during the beginning of the simulation where they start at 35 C. This overcooling is reflected in the high energy usage of the LQI controller in table 11. The behavior of the controller outputs is similar to in the previous figure, except for that there is no signal saturation. 53