Request Dispatching for Cheap Energy Prices in Cloud Data Centers

1. Request Dispatching for Cheap Energy Prices in Cloud Data Centers Hiroshi Yamada (TUAT)In cooperation withTakumi Sakamoto( takus@sslab.ics.keio.ac.jp ), HikaruHorie, Kenji Kono(Keio Univ.)

2. Make use of geographically-distributed data centers • Offer users a large amount of resources in a pay-as-you-go manner • Enable us to easily use resources as needed e.g. Amazon has more than tens of DCs over the world Cloud Service Providers Tokyo Dallas London Miami Seattle Amsterdam

3. Millions of dollars of electric costs per year [Qureshi+ SIGCOMM ’04] • Google spends $38 million on electricity • Other large companies pay tens of million dollars • Significant financial overheadin the management cost • Energy prices can be higher and higher • Limited fossil fuel • Restriction to build nuclear power plants ⇒Lead to higher charges for the use of clouds Energy costisEXTREMELY high

4. Forwards client requests to DCs in cheaper energy price regions[Qureshi+ SIGCOMM ’09] • Average utilization in DCs is 20〜30% • Servers can be replicated in different DCs Existing solution for reducing energy costs Energy prices are fluctuated over timein the US.

5. DCs’ capacities • The previous work dispatches requests only to the DC in the cheapest energy price region • Even if the DC is overloaded ⇒Service qualities can be degraded • Lose 1 % income if the response time is 10 % increased in Amazon [Kohavi+ ’07] • Various factors to be considered • DC loads, response time, ・・・ ⇒ Cannot dispatch requests based on only energy prices Challenges for dispatching client requests in clouds

6. Dispatching client requests to DCs in cheaper energy price regions, considering: • DCs’ capacities • Various factors such asDC loads and response time • Assumptions • Know the real-time energy prices that vary hourly • Use a function to automatically launch servers inside DCs like Amazon auto scaling function Proposal Requests Dispatcher $1 / MWh $2 / MWh $3 / MWh

7. Propose a mechanism to dispatch requests to save energy prices, satisfying pre-defined demands Show an example algorithm that satisfies pre-defined demands and can be integrated to our dispatcher Implement our prototype and perform simulation evaluation using real data Contributions

8. Requirements • Scalability • Has to handle a huge amount of requests sent to DCs • Ability to follow frequent-redirection-changes • Energy price and DC loads are changed frequently • Availability • Easy to fail to redirect requests if the dispatcher is fragile • Solution: Mapping Nodes • Run between clients and DCs in a P2P fashion • Satisfy the three requirements Design of request dispatcher

9. Constructs a distributed hash table (DHT) • Key: a host name, Value: Mapping Entry • Mapping entry contains the host’s IP and RTT (for cache) • Returns IP address like DNS servers • Clients use the returned address to connect Mapping Node

10. Used for mapping nodes to return IP addresses • Calculates dispatching request ratio in each DC • A DC to forward is decided based on the ratio • Cloud service providers can change weights A Request Dispatching Algorithm Example: request dispatching based on DC load, response time, and energy prices DC loads. Weight is decreased as DC loads are more severe Response time. Weight is 0 when latency is over 70 msec Energy prices.Weight is smoothly decreased as the price is higher weight

11. Implement a prototype on Overlay Weaver [Shodo+ ’06] • DC emulator: CloudSim [Buyya+ ’09] • Parameters • Energy prices data: 1st week in the US on Aug. 2010 • Workloads: E-commerce DC workload, borrowing from [Heller+ NSDI ’10] • Constraints (Threshold) • DC loads: less than 80 % • Response time: less than 70 ms Simulation Evaluation Compared with the following policies

12. Our proposal lowers energy prices without the constraint violation • 28 % better in energy prices than Random ⇒ Saves several hundred dollars if annual energy cost is several thousand dollars Result（Energy price and constraint violation） Constraint Violation Energy price nomalized by Random Lower is better Lower is better

13. Our proposal successfully regulates DC loads • DC loads in Latency & Price are fluctuated severely Result（DC loads） Threshold = 80% Random Loads are changed along with the workload. 1 1 1 1 2 2 2 2 3 3 3 3 4 4 4 4 5 5 5 5 6 6 6 6 7 7 7 7 Day Day Day Day Threshold = 80% Latency & Price Loads are sharply fluctuated. Threshold = 80% Latency & LoadLoads are changed along with the workload. Threshold = 80% Our Proposal Loads are changed along with the workload.

14. Energy-price-driven request dispatcher [Qureshi+ SIGCOMM ’09] • Dispatches requests to DCs in a cheap energy price region • Only consider energy price • Load-balancer for DCs [Wendell+ SIGCOMM ’10] • Dispatches requests to DCs based on their loads • Does not consider energy prices • DHT-based DNS[Ramasubramanian+ SIGCOMM ’04] • Achieves fault-tolerant and high performance DNS using DHT • Not focus on energy prices and cloud user policy Related Work

15. Proposal: Energy-price-driven request dispatcher for clouds • Takes response time and DC loads into account • Leverages a DHT mechanism • Our simulation result shows that our dispatcher saves energy costs without violation of pre-defined constraints • Future work • Enhance policies used in mapping nodes • Evaluate our prototype in the real world Conclusions