PaperlayerView exact revision on arXiv

Source-linked AI summary

Slasher: Power Flexibility for Cloud Datacenters

Liuzixuan Lin, Fiodar Kazhamiaka, Alok Gautam Kumbhare, Chaojie Zhang, Jaylen Wang, Hassan Khan, Rodrigo L. Assis, Mariana Rodrigues, Kyle Woolcock, Nithish Mahalingam, Brijesh Warrier, Rodrigo Fonseca, Ricardo Bianchini

arXiv:2608.26021v1cs.DCcs.OSeess.SY

TL;DR

Cloud datacenters need to modulate substantial power across diverse infrastructure and grid events, but limited application visibility constrains platform-level control. The paper presents Slasher, a coordinated system with impact-aware policies, simulation, and workload modeling. Experiments report coordinated policies that use service slack, avoid high-priority impact, and achieve modest reductions while preserving service quality.

  • Problem

    Datacenter power modulation spans diverse targets and timescales, while limited application visibility restricts operators to platform and power-device telemetry.

  • Method

    Slasher coordinates power devices and software levers through playbooks, impact models, a high-fidelity simulator, and evaluated power-control policies.

  • Results

    Coordinated Slasher policies leverage service slack, avoid impact to high-priority services, and achieve modest power reductions while preserving service quality.

  • Takeaways & Limitations

    Impact-aware coordination can support datacenter power reduction across varied operational scenarios while accounting for thousands of servers and services.

  • Takeaways & Limitations

    GPU- and LLM-specific workload management and platform-workload interaction remain future work, and some described levers and scenarios are still being integrated.

Abstract

from arXiv · show

Datacenters consume many megawatts of power, and regularly encounter scenarios that require modulating their power draw. These scenarios include datacenter infrastructure failures, power grid failures, grid services, and more, spanning a diverse range of requirements in terms of the power magnitude, the scope of the reduction, the notice time, and other dimensions. To address these scenarios, we have built Slasher, a general system for modulating the power of \azure datacenters to handle scenarios ranging from individual racks to regional multi-datacenter grid events. Slasher coordinates datacenter resources with the goal of meeting power targets while minimizing negative impact on hosted workloads. In this paper, we review the main power modulation scenarios, characterize the power reduction levers using data from production cloud datacenters, describe Slasher's system architecture, and formulate the cloud datacenter power modulation control problem. We also develop a high-fidelity datacenter simulator and propose a workload impact model, using them to design and evaluate power control algorithms.

1 Introduction

Cloud datacenters need power flexibility across diverse events, but limited application visibility makes platform-level, impact-aware coordination necessary. Slasher combines datacenter levers, workload-impact modeling, simulation, and control policies to meet power targets while limiting service harm.

  • Motivation: Datacenters consume 10s-1000s of MW, while rising AI demand and constrained grid capacity are driving requirements for dynamic power reduction.Power flexibility is expected to unlock 10’s of GW of capacity within existing constraints.
  • Motivation: Power-flexibility scenarios differ in reduction magnitude, frequency, domain, duration, and advance notice, from hall-level cooling failures to near-instant multi-row faults.The paper gives examples of 10% reduction for 3-6 hours with 30 minutes’ lead time and 5% near-instant reduction.
  • Problem: Limited visibility into applications prevents broad adoption of application-based power management, so operators rely on platform telemetry and power-device data.Available signals include server occupancy, resource utilization, and power meters across the delivery system.
  • Slasher: Slasher coordinates power devices and software levers through dynamically recomputed playbooks that map actions to power domains while minimizing hosted-service impact.Playbooks activate when scenarios trigger and target power within the scenario’s required limit.
  • Scope: GPU- and LLM-specific workload management remains future work because application-specific modulation generally requires platform-workload interaction unavailable at the platform layer.The core system is operational and in production, but some levers and scenarios are still being integrated.
  • Contributions: The paper contributes production-trace analysis, Slasher, a coordinated battery-workload experiment, Stratosim, an impact model, and simulations of control policies.These contributions support formulation and evaluation of the cloud-datacenter power-modulation control problem.

2 Background

Datacenter power-management scenarios span internal failures, grid events, and grid services with widely varying response requirements. Slasher focuses on scenarios compatible with platform-level controls and organizes them across five dimensions.

  • Scenario classes: The paper groups scenarios into power oversubscription mitigation, infrastructure outages, grid shortages, grid emergencies, grid services, and grid-interconnection requirements.These categories cover both internal datacenter events and external grid-related demands.
  • Scope: Slasher excludes grid-interconnection requirements because their often sub-second response times and lead times are unsuitable for software platform-level controls.The paper focuses on power-reduction scenarios with requirements that vary substantially across cases.
  • Scenario dimensions: The unifying scenario dimensions are event frequency, lead time, response duration, power reduction, and blast radius.Figure 1 presents a representative range for each dimension across scenarios.
  • Infrastructure scenarios: Infrastructure outages can require shedding power after cooling or power-equipment failures reduce available capacity, while power oversubscription prevents demand from exceeding device capacity.Cooling losses may require operation within a lowered cooling-capacity budget.
  • Grid scenarios: Grid shortages may require long-lead-time, multi-week reductions across entire regions, whereas LFDD grid emergencies can require 5-60% shedding within 200 ms.The LFDD requirement applies to large customers during severe grid-frequency drops.
  • Grid services: Grid peak shaving offers predictable events and long reaction times, with contractual constraints on lead time, duration, and invocation frequency.Demand response helps balance generation and demand as variable wind and solar generation increases.

3 Power Modulation Levers

Cloud datacenter power can be modulated through coordinated hardware, platform, and workload levers, but each offers different power, duration, notice, and workload-impact trade-offs. Production measurements show that server shutdown and VM consolidation offer major opportunities, while frequency capping often sacrifices more serving capacity than power.

  • Lever trade-offs: Datacenter power modulation combines power devices, server controls, VM management, and workload migration or delay, each with distinct operating limits.Batteries and generators can avoid workload impact but may be expensive, regulated, or unsuitable for IT-power reductions.
  • Server power: Server base power dominates total datacenter power, making server shutdown or low-power states the largest reduction opportunity.Unallocated servers already operate in low-power states, so shutting them down yields little additional reduction; allocated-server shutdown can substantially affect applications.
  • Frequency throttling: 46% of peak load is Vault’s serving capacity at 2.5 GHz versus 1300 RPS at maximum frequency.The study evaluates ten request-serving workloads on dedicated cores while holding uncore frequency at its maximum.
  • Frequency throttling: At 40% less dynamic power, the median application retains 48% of peak serving capacity, while applications range from 7% to 57%.Most workloads lose more serving capacity than the achieved power reduction, so frequency throttling is best suited to rare, short-lived events.
  • Diverting new deployments: 3–7% additional servers become unallocated after 12 hours without new deployments, with a 5–15% reduction in average occupancy.Changes occur quickly within two hours, while recently deployed datacenters may gain meaningful but short-lived power-reduction opportunities.

4 Slasher System Design

Slasher jointly controls datacenter power infrastructure, servers, and VMs through hierarchical local and regional controllers. Its fast and slow paths coordinate diverse power-shedding actions across event scopes and response requirements while minimizing workload impact.

  • Architecture overview: Slasher jointly controls generators, batteries, servers, and VMs to meet power targets while minimizing hosted-service impact.It maps modulation policies to playbooks that associate levers with specific power domains.
  • Requirements: Centralized regional control coordinates multi-datacenter events, overlapping scenarios, and shared lever interfaces through a hierarchical design.A regional controller configures and receives summarized data from local per-datacenter controllers.
  • Architecture overview: The two-tier architecture separates fast, detailed local actuation from regional allocation of power-shedding goals across halls.Local controllers own high-fidelity telemetry and actuation, while the orchestrator assigns goals that collectively meet regional targets.
  • Local controller: Local controllers pre-compute responses offline, then monitor scenarios online and execute ordered, rate-limited, reversible actions through specialized handlers.The decision manager maintains resource and lever inventories, while the consolidator enforces the most restrictive simultaneous limit.
  • Fast and slow paths: Hardware sidecars handle sub-second electrical events, while slower software mechanisms provide sustained power reduction as storage limits approach.Combining hardware and software controllers covers varying lead times, durations, and shedding magnitudes.
  • Scenario tracking: A power-path tree maps each scenario to affected infrastructure nodes and records overlapping events with distinct marks.Leaves represent servers, intermediate nodes represent power devices, and event markings are removed when scenarios end.

5 Datacenter Simulation

Stratosim is a high-fidelity simulator for studying Slasher policies in a de-risked environment. It replays telemetry across modeled power and IT infrastructure, enabling evaluation of diverse power scenarios and controller policies.

  • Simulator purpose: Stratosim replays datacenter state from telemetry streams and models Slasher actions across the power-delivery hierarchy.The simulator was built to study control policies without directly risking workload or grid operations.
  • Simulated infrastructure: The simulated infrastructure includes grid-connected UPS and PDU power delivery, redundant rack connections, servers, VMs, and software control actions.Its power-delivery topology can be configured to represent arbitrary network structures.
  • Simulator design: Telemetry and event traces are dispatched as timestamped receiver-value tuples to simulator entities representing power and IT components.The implementation uses Salabim for discrete-event simulation.
  • Simulator design: The simulator supports diverse trace sources, full-stack modeling from grid connection to VMs, and realistic telemetry and control delays.Real-world component connections are mapped onto simulator objects.
  • Simulator purpose: Stratosim supports high-fidelity study of diverse datacenter power scenarios and evaluation of controller policies.The simulator is used for the power scenarios and control-policy experiments described later in the paper.

6 Workload Impact Formulation

Slasher models workload impact by relating service capacity reductions to load distributions, service architecture, and inferred priorities. It then aggregates these impacts to guide power-control decisions while accounting for uncertainty and model limitations.

  • 6.1 Service Model: Services consist of VMs organized into logical functions, whose user-facing status, statefulness, and failure-domain resilience shape capacity-loss impact.Cloud-visible VM features can serve as proxies for application properties when direct application knowledge is unavailable.
  • 6.1 Service Model: Slack capacity is a natural reduction target, but harvesting it can still affect services depending on their architecture and load behavior.Network-attached storage is one observable proxy associated with statefulness.
  • 6.2 Impact Model: Expected Shortfall quantifies service impact as capacity shortfall above the reduced capacity, weighted by the probability of each load level and normalized by average load.The model re-purposes Conditional Value at Risk from finance for cloud resource reductions.
  • 6.2 Impact Model: The ES metric is comparable across services because it approaches 1 as remaining capacity approaches zero and is 0 when capacity covers the maximum load.Service load can be estimated from proxies such as CPU utilization and network traffic.
  • 6.2 Impact Model: Fitted load distributions from hourly CPU traces provide differentiable probability densities for calculating service impact functions.The paper uses common probabilistic distributions and Gaussian KDE to fit usage data.
  • 6.2 Impact Model: Service B can tolerate more capacity loss than Service A while keeping expected shortfall negligible, demonstrating architecture-dependent impact variation.Slack between pre-event capacity and actual load enables reductions with zero or little impact.
  • 6.2 Impact Model: Without application performance metrics, the model cannot distinguish over-provisioning from utilization-sensitive performance degradation.A conservative alternative rescales historical usage so load = 1 corresponds to the observed maximum.
  • 6.3 Total Cost of an Action: Total action cost sums service impacts weighted by priorities inferred from platform-visible properties.The optimization objective is to minimize aggregate event-response impact across hosted services.

7 Control Policy for Server Shutdown

Slasher selects server shutdown actions to meet power-reduction goals while minimizing service impact. Its evaluated score-based policies use workload slack and iterative impact updates to outperform utilization-only selection, with computation completing in seconds.

  • 7 Control Policy for Server Shutdown: Low-impact levers may be insufficient for extreme events, so server shutdown is evaluated despite its significant effect on allocated workloads.The study excludes power throttling and VM consolidation, deferring consolidation and other levers to future work.
  • 7 Control Policy for Server Shutdown: The selection challenge is non-additive: shutting down a second server can push a service from slack capacity into under-capacity.Marginal service impact increases as capacity is repeatedly reduced.
  • 7 Control Policy for Server Shutdown: Local controllers rank servers using datacenter telemetry and produce a cumulative power-reduction list in seconds.This runtime allows the list to remain consistent with changing datacenter and service state.
  • 7 Control Policy for Server Shutdown: The evaluation uses production traces containing 30 days of service CPU history, 1 hour of power telemetry, and 1 hour of VM allocation records.These inputs support service-load estimation, power attribution, and VM-state reconstruction in Stratosim.
  • 7 Control Policy for Server Shutdown: AscUtil ranks servers by utilization, whereas AscScore-OnePass ranks estimated cost once and AscScore-ReEval recalculates scores when selected servers overlap in services.All policies first shut down empty servers until cluster buffer constraints are reached.
  • 7 Control Policy for Server Shutdown: The first 5% reduction comes from excess unallocated servers, while utilization-only selection quickly incurs large cost as reduction targets increase.The total-cost comparison aggregates expected impact across services.
  • 7 Control Policy for Server Shutdown: A 15% power reduction can imply over 1000 services experiencing capacity shortfall when the reference service cost is 1500.This quantifies the aggregate impact represented by the cost metric.
  • 7 Control Policy for Server Shutdown: AscScore-ReEval keeps total cost near zero even at 15% power reduction, while one-pass scoring produces non-zero impacts beyond service slack.AscScore variants prioritize spot VMs and services with sufficient slack capacity.

8 Summary

The paper presents Slasher as a coordinated system for datacenter power flexibility, combining hardware and software controls with simulation and impact modeling. Experiments suggest that impact-aware policies can achieve modest reductions while preserving service quality, while broader scenario-specific policies remain future work.

  • 8 Summary: Power modulation is increasingly important as datacenter power demands grow.The paper frames flexibility as a response to expanding power requirements.
  • 8 Summary: Slasher coordinates hardware and software levers to meet power targets while minimizing workload impact.The system manages datacenter power flexibility across available infrastructure and platform controls.
  • 8 Summary: Stratosim simulates power-management policies using high-resolution datacenter power traces.The simulator supports testing policies against detailed datacenter power behavior.
  • 8 Summary: A risk-based service impact model quantifies the effects of throttling or shutting down VMs.The model provides the impact signal used in power-control decisions.
  • 8 Summary: Experiments show that impact-aware policies can exploit slack across services and avoid affecting high-priority services while considering thousands of servers and services.The reported scope includes coordinated control across a large datacenter state.
  • 8 Summary: The results suggest that coordinated, impact-aware policies can support modest power reductions while preserving service quality.This conclusion is stated within the scope of the evaluated policies and scenarios.
  • 8 Summary: Tailoring policies to each scenario remains open, alongside power reduction for cloud storage and algorithms for the broader action space.AI workloads may also offer opportunities through geographic distribution and local modulation.

A Evaluated workloads

The evaluated workload set comprises request-serving applications running in CPU VMs without attached accelerators. These workloads span compute, memory, storage, transactional, inference, authentication, and graph-database behaviors with application-specific p99 SLOs.

  • A Evaluated workloads: The study evaluates ten request-serving applications running in CPU VMs without attached accelerators.Their request paths span compute, memory, and storage operations.
  • A Evaluated workloads: The workload set includes PostgreSQL, TensorFlow Serving, Go HTTP pointer chasing, Keycloak, and Neo4j, among other cloud-like services.The applications have distinct p99 SLOs, including 3.09 ms for PostgreSQL and 62 ms for TensorFlow Serving.

B Optimization problem formulation

The formulation selects worker throttling, server power states, and worker placement to meet a datacenter power target while minimizing hosted-workload impact. It models power bottom-up from worker dynamics, server baselines, datacenter baseline power, and PUE, while making explicit simplifying assumptions.

  • B Optimization problem formulation: The optimization chooses actions that meet the power reduction target while minimizing workload impact.
  • B Optimization problem formulation: Worker states α_w continuously scale CPU frequency, server states β_k encode on/off or intermediate low-power states, and A records worker placement.
  • B.1 Worker and server models: Worker dynamic power depends on implicit average utilization and scales with the CPU frequency of the cores running each VM.
  • B.1 Worker and server models: Each server combines baseline power for idle CPU, memory, networking, and other components with the dynamic power of its hosted workers.
  • B.2 Power model: The worker power function is zero when a worker is unallocated to a server or when its server is off.
  • B.2 Power model: The model assumes server base power is frequency-independent, abstracts whole-core versus per-worker frequency control, and permits throttling individual workers on multi-tenant servers.
  • B.2 Power model: Datacenter power combines baseline power, server power, and PUE, which captures additional consumption from power infrastructure and cooling.
  • B.3 Putting it together: The integrated problem determines α_w and β_k using target power, allocation, worker-power functions, and weighted service-impact functions.

C Service priority configuration

Table 3 provides service-priority weight factors used in the datacenter shedding experiments.

  • C Service priority configuration: Service-priority weight factors are specified for the datacenter shedding experiments in Section 7.
Loading 2608.26021v1…