1 of 19

From Fastnet Lighthouse to the Cloud:�Dovetailing Resilience into Greener Data Centre Infrastructure

James Delaney, MSc Cloud Computing (MTU), Data Centre Engineer (UCC)

Supervisor: Dr Patrick McCarthy (MTU)

_{Good afternoon everyone. My name is James Delaney, and I’m a Data Centre Engineer with the IT Services at University College Cork.}

_{It’s great to be here at the HEAnet Conference, and to have the chance to share some of my recent work on data-centre resilience and sustainability.}

_{The talk is titled “From Fastnet Lighthouse to the Cloud: Dovetailing Resilience into Greener Data Centre Infrastructure.”}

_{It’s inspired by the architecture of the Fastnet Lighthouse, situated off the coast of West Cork. A remarkable and picturesque structure built to serve as an aid to navigation and endure the harshest conditions of the Atlantic Ocean. I’ve re-imagined the principle of interlocking resilience behind its construction through the lens of cloud computing, exploring how we can design digital systems that are both robust and energy-aware.}

_{Over the next few slides, I will show how that analogy led to a Kubernetes-based approach that drives more efficient workload placement in data centre environments, cutting energy usage and CO₂ emissions, whilst safeguarding service reliability.}

2 of 19

Introduction

A software-defined approach inspired by the dovetail toggle of the Fastnet Lighthouse

Making Kubernetes clusters more resilient and energy-efficient, and stewarding a greener data-centre future

This project started as part of my master’s research at Munster Technological University, under the supervision of Dr Patrick McCarthy.

The idea came from a simple question: how can we make our data centres smarter, more resilient, and more sustainable?

When you think about it, most of the energy savings we talk about in IT or a data centre context come from better hardware, such as smarter cooling, more efficient chips, or greener power sources. But the real progress will come from how we use those servers which make up these data centres. A lot of them sit half-idle, powered on just in case something fails or needs to scale, quietly wasting energy in the background.

My project looks at how software could make better decisions automatically in this context, switching things on and off at the right time, moving work around when needed, and doing all that without breaking anything or affecting reliability.

Those are the guiding principles behind the system I’ll walk through today.

3 of 19

Background – The Fastnet Lighthouse Analogy

Why the Fastnet?

What makes its design uniquely resilient, and relevant to data centres?

Preserving fault tolerance where Kubernetes falters – resilience through interlocking design

Background –

The Fastnet Analogy

Before getting into the technical details, I want to explain why I chose the Fastnet Lighthouse as the foundation for this project, and how its design inspired the way we think about building more resilient digital systems.

The Fastnet Lighthouse is an incredible piece of 19th-century engineering. Each granite block used in its construction interlocks vertically and horizontally with those around it, meaning no single stone can fail on its own. Its strength doesn’t come from any one part; it comes from how everything is connected.

That interlocking design was achieved through what’s known as a dovetail toggle. It’s that same dovetail principle, where strength comes from connection, that inspired the architecture of my system. The idea was to translate that physical resilience into a digital form, where computing nodes interlock logically to support one another and maintain stability even as workloads shift or consolidate.

We’ll come back to the Fastnet a little later, when I show how that same idea of interlocking strength inspired the digital system I built.

Now, to put that into a modern context, Kubernetes is the leading platform used today for running containerised applications in the cloud. It spreads those containers across multiple machines, known as nodes, and manages their deployment, scaling, and recovery automatically.

For those who may not be familiar, a container is a small, self-contained package that includes an application and everything it needs to run, such as its code, libraries, and configuration. You can think of it like a shipping container for software. It keeps everything tidy, consistent, and portable, so the same application can run reliably on any machine, anywhere. For example, one container might run a website, another an email service, and another a payroll system.

4 of 19

Background – The Fastnet Lighthouse Analogy

Why the Fastnet?

What makes its design uniquely resilient, and relevant to data centres?

Preserving fault tolerance where Kubernetes falters – resilience through interlocking design

Background –

The Fastnet Analogy

I'd like to think we're all recovered from the Azure outage on Wednesday of last week, and also the one on the 9th of October if you’re keeping score. On that day the Kubernetes nodes which power the Azure Front Door went down – which was a bit ironic, as it took them a while to get a handle on it. Even major cloud players can trip over their own Kubernetes architecture, or other cloud architectures for that matter, and it shows where a dovetailed approach to resilience could really make a difference. And while that example highlights why resilience matters, it also shows that resilience alone doesn’t necessarily mean efficiency.

But while Kubernetes is excellent at keeping services running, it’s designed to maintain the desired state, not to optimise for efficiency. It restarts failed containers and replaces them on other nodes when needed, but it doesn’t proactively move workloads to save energy or free up machines. Doing that could break its own fault-tolerance model. For example, if two replicas of the same application ended up on the same node, a single failure could take both offline.

This leaves operators with a trade-off. They can keep everything running for resilience and waste energy, or save energy and risk downtime.

Reinforcement learning, put simply, is a type of machine learning where a system learns by doing. It tries something, observes the result, and uses that feedback to make a better choice next time.

Researchers have looked at using reinforcement learning to make cloud systems more energy-efficient, and it’s been shown to work. But most of those approaches overlook resilience. They treat workloads as if they were all independent, not as connected services that depend on one another. That’s where the Fastnet analogy comes in. Just like the lighthouse’s stones share the pressure between them, this design spreads risk and recovery across nodes. Each node depends on and protects its neighbours.

By making resilience part of the structure itself, rather than something added on later, we can safely consolidate workloads, reduce power use, and still maintain the same level of reliability and protection against failure.

5 of 19

Solving the Data Centre Resilience Problem for Sustainability

Data centres are the main driver of Ireland’s electricity growth since 2015

Demand from data centres grew by 22.6% per year (vs 0.4% in other sectors)

Ireland’s electricity use rose 24.7% (2012–2022) – 2nd fastest in the EU, while EU demand fell 3.1%

Household electricity use stayed flat → growth driven by data centres

Similar trend worldwide, with data centres among the fastest-growing energy consumers

H. Daly, “Data centres in the context of Ireland’s carbon budgets,” 2024.

Since around 2015, data centres have been the main driver of Ireland’s electricity growth. Their energy use has been rising by over twenty percent a year, while most other sectors have stayed more or less flat. You can see that steep climb in the red line on the graph here.

And this isn’t just an Irish story. The same pattern is happening all over the world, driven by the rapid growth of cloud computing and the scale of modern workloads running in containers. Containers now sit behind almost every modern service, from Netflix and Spotify to Booking.com, and Kubernetes has become the standard way to manage them.

The problem is that while containers make systems more flexible, the infrastructure underneath them has become more power-hungry. Clusters are kept running at full capacity for resilience, which means thousands of machines often sit idle but still switched on, just in case something fails.

So the real challenge isn’t only to make data centres greener, but to rethink what resilience means, to find a way for energy efficiency and resilience to work together rather than against each other.

6 of 19

Telemetry

How can real-time power telemetry from Kepler be integrated into RL-driven scheduling for energy-aware workload placement?

Resilience

How can a RL-based workflow orchestration framework, leveraging the dovetail toggle approach, balance energy efficiency, scalability, and fault tolerance in large-scale data centres?

Efficiency

How can Reinforcement Learning (RL) be applied to optimise energy efficiency in Kubernetes orchestration?

Research Questions

7 of 19

System Architecture Design •

Defined six-layer modular framework (data → analysis → recommendation → RL → migration → reporting).
Designed dovetail scheduling logic to preserve ReplicaSet fault tolerance.

Implementation & Environment •

Developed in Python (v3.10) and deployed on k3s/k3d simulated clusters.
Integrated Docker, Kepler, and Prometheus for real-time telemetry.
PostgreSQL database for persistent metric logging.

Reinforcement Learning Agent •

Tabular Q-learning with 10,000 training episodes.
State space: CPU/memory levels + container mappings.
Reward: balance energy efficiency, consolidation, and fault tolerance.

Analysis & Validation •

Visual telemetry in Grafana dashboards.
Human-readable logs and rationales for transparency.

Evaluation Procedure •

Compared RL against advanced rule-based, random, and default Kubernetes schedulers.
Tested across 4, 8, and 12 node clusters.
Key metrics: energy, CO₂ savings, migrations.

Methodology

This framework was designed and tested through five main stages.It began with the architecture design, which defined a modular, six-layer structure linking data collection, analysis, and decision-making.

We then moved into implementation, developing everything in Python on lightweight Kubernetes test clusters, with Kepler and Prometheus providing live energy telemetry.

The reinforcement-learning agent formed the intelligence layer, trained through thousands of episodes to balance efficiency and reliability.

We evaluated it against existing Kubernetes schedulers across multiple cluster sizes, and finally, used Grafana dashboards and detailed logs for validation.

I’ll show you how those layers connect technically a little later, but this should hopefully give you a flavour of how the overall structure of the research was carried out.

8 of 19

Research Design –

The Dovetail Toggle

Designed by William Douglass

2074 granite stones – each one hand carved

Interlocking blocks joined both vertically and horizontally

Each stone knitted in with the one above, below, and either side

No single stone could fail in isolation – to crack it would mean bringing down the entire edifice

9 of 19

Research Design –

The Dovetail Toggle

Resilience through interlocking structural design

Translated into a distributed computing context

Each node depends on, and protects its neighbours

10 of 19

Active Nodes

Cold Standby (Idle) Nodes

Primary containers (hosted on this node)

Replica of primary containers from previous node

Research Design –

The Dovetail Toggle

Nodes interlock laterally via primaries and replicas

Circular failover ensures no replica shares its primary node

Cold standbys activate only when required for scaling or node failure

Engineered for resilience, optimised for sustainability

This is where the Fastnet analogy becomes digital, with the dovetail toggle reimagined inside a Kubernetes cluster.

Each red coloured segment on the diagram represents a node in the cluster. The nodes are linked laterally, just like the stones in the lighthouse. Each one runs its own primary containers and also holds replicas of its neighbour’s workloads.

That circular pattern creates a closed failover loop. If one node goes offline, its workloads are already mirrored elsewhere. And because no replica ever sits on the same node as its primary, there is no single point of failure.

Around that main ring are cold standby nodes. These stay in a low-power state and only activate when more capacity is needed for scaling or when a failure occurs.

The result is a system designed for both resilience and sustainability, keeping backup capacity ready but powering down what is not needed.

At the centre of the cluster sits the reinforcement learning agent. It monitors live telemetry from Kepler, analysing power and performance data in real time to decide where containers should be placed or moved, keeping the cluster balanced and energy-efficient.

11 of 19

Active Nodes

Cold Standby (Idle) Nodes

Primary containers (hosted on this node)

Replica of primary containers from previous node

Research Design –

The Dovetail Toggle

Dovetail Migration Logic Summary

Each node hosts its own primaries and replicas of the previous node’s primaries

When a node shuts down:

Primaries → move two nodes forward
Replicas → move one node forward

Maintains circular fault tolerance and avoids co-location of primaries and replicas

A + F

B + F

Building on that migration logic, this diagram shows what happens when the reinforcement learning model identifies an opportunity to save energy.

In this example, the model recognises that Node F is under-utilised and can be powered down safely, by reducing wasted energy while keeping the cluster balanced. Its primary containers are moved two nodes forward, and its replicas are moved one node forward, following that same circular dovetail pattern.

This arrangement ensures that even with one node offline, every workload still has an active replica elsewhere, and no primary ever overlaps with its replica on the same node. This is dependent on whether the two nearest nodes ahead have enough available capacity. If they don't, the model searches for the next available pair of nodes to host the primaries and replicas belonging to Node F.

Once the migrations finish, Node F enters a low-power cold standby state, cutting the energy use of Node F by almost sixty-four percent while the rest of the cluster continues to run normally.

It is a clear demonstration of how the system can act autonomously to consolidate workloads, maintaining full resilience while achieving measurable energy savings.

12 of 19

System Level Architecture

6

Reporting Systems

Delivers real-time and persistent reporting outputs, including detailed operator-facing rationales.

1

Data Collection Layer

Gathers real-time CPU, memory and power metrics from containers and nodes via Docker, Kepler, and Prometheus.

2

Analysis Layer

Processes collected data to assess resource utilisation, energy consumption, and operational anomalies.

3

Recommendation Engine

Generates actionable migration suggestions based on multi-criteria optimisation.

5

Migration Planner

Designs migration sequences that maintain ReplicaSet fault tolerance, based on the dovetail toggle architecture.

4

RL Module

Trains a Q-learning agent to improve container placement strategies dynamically.

This diagram shows how the full system fits together. It’s organised into six layers, each with a clear and independent role.

It starts with data collection, which gathers real-time metrics from Docker, Prometheus, and Kepler, capturing everything from CPU and memory usage to live power readings.

The analysis layer then cleans and interprets that data, detecting any imbalance or inefficiency before passing it further down the pipeline.

The recommendation layer takes those insights and proposes migrations or optimisations, weighing energy use against performance.

At the centre sits the reinforcement learning module, built on a Q-learning algorithm. Over time, it learns how to make better placement decisions, balancing efficiency with resilience, guided by live feedback from the system itself.

Once a decision is made, the migration planner safely carries it out, following the dovetail rules that keep replicas separate and reliability intact.

Finally, the reporting layer ties everything together by generating plain-language explanations and detailed logs, making every automated action transparent and verifiable.

13 of 19

Implementation & Measurements

Energy models calibrated to Dell PowerEdge R740 specs

Idle draw assumed at 36% of peak (Berkeley Lab 2024)

Energy & CO₂ estimated via SEAI emission factor (0.2548 kg CO₂ / kWh)

Evaluation under identical 4, 8, and 12 node clusters

Live telemetry confirmed post-migration energy drops in Grafana

Implementation & Measurements

To validate the model, we built and tested it in a controlled environment using lightweight virtualised Kubernetes clusters. These were configured in three sizes, with four, eight, and twelve nodes.

The energy models were calibrated against Dell PowerEdge R-seven-forty server specifications. Idle power draw of a cold standby server was assumed to be about thirty-six percent of peak usage, based on data from Berkeley Lab research in 2024.

Energy and CO₂ savings were then estimated using the Sustainable Energy Authority of Ireland's emissions factor of zero point two five four eight kilograms of CO₂ per kilowatt-hour, giving a realistic baseline for sustainability impact.

On the right, you can see an example of what the system output looks like. The reinforcement learning agent identifies under-utilised nodes, generates a migration plan, and estimates the power savings achieved once those nodes are powered down.

All of these recommendations were automatically logged and validated through Grafana dashboards, confirming the post-migration energy reduction in real time.

14 of 19

Implementation & Measurements

Energy models calibrated to Dell PowerEdge R740 specs

Idle draw assumed at 36% of peak (Berkeley Lab 2024)

Energy & CO₂ estimated via SEAI emission factor (0.2548 kg CO₂ / kWh)

Evaluation under identical 4, 8, and 12 node clusters

Live telemetry confirmed post-migration energy drops in Grafana

Implementation & Measurements

Progressive Reduction in Daily CO₂ Emissions During RL Agent Training Across Cluster Sizes

Real-time Grafana dashboard showing reduced power usage after three nodes were powered down in a 12-node cluster.

15 of 19

Reinforcement Learning Policy

(this research)

Nodes Shutdown: 3

Annual Savings (kWh): 2522.88

co₂ Reduction (kg): 642.84

Advanced Heuristics Policy

Nodes Shutdown: 2

Annual Savings (kWh): 1681.92

co₂ Reduction (kg): 428.56

K8s Default &

Random Policies

Nodes Shutdown: 0

Annual Savings (kWh): 0

co₂ Reduction (kg): 0

Rule Based Policy

Nodes Shutdown: 0.003

Annual Savings (kWh): 2.52

co₂ Reduction (kg): 0.64

Findings

12 Node Cluster Simulation

SEAI factor: 0.2548 kg CO2/kWh

Idle power = 36% of peak (Berkeley Lab, 2024)

This is where the architecture really shows its impact.

To test how effective it was, I compared five different scheduling strategies side by side in a twelve-node Kubernetes cluster.

• The default Kubernetes scheduler, simply maintains availability without considering energy use.

• A random policy, places workloads arbitrarily without optimisation.

• A rule-based policy, follows fixed, human-defined thresholds.

• An advanced heuristic approach, applies more complex logic but still doesn’t learn from experience.

• And finally, the reinforcement learning policy developed in this research, learns optimal placement strategies over time while preserving fault tolerance.

The reinforcement learning model was the only one capable of safely shutting down three nodes while still adhering to the dovetail architecture and maintaining full system reliability.

That translated into an annual energy saving of about two and a half thousand kilowatt-hours and a CO₂ reduction of roughly six hundred and forty kilograms per year, all achieved through the model’s own autonomous decisions.

16 of 19

Reinforcement Learning Policy

(this research)

Nodes Shutdown: 3

Annual Savings (kWh): 2522.88

co₂ Reduction (kg): 642.84

Advanced Heuristics Policy

Nodes Shutdown: 2

Annual Savings (kWh): 1681.92

co₂ Reduction (kg): 428.56

K8s Default &

Random Policies

Nodes Shutdown: 0

Annual Savings (kWh): 0

co₂ Reduction (kg): 0

Rule Based Policy

Nodes Shutdown: 0.003

Annual Savings (kWh): 2.52

co₂ Reduction (kg): 0.64

Findings

12 Node Cluster Simulation

SEAI factor: 0.2548 kg CO2/kWh

Idle power = 36% of peak (Berkeley Lab, 2024)

The advanced heuristic method came close, managing to shut down two nodes, but beyond that reliability began to fail. The rule-based, random, and default Kubernetes schedulers achieved little to no measurable savings at all.

What stands out most is that these savings were achieved without any loss of reliability, showing that energy efficiency and resilience do not have to compete; they can strengthen one another.

One interesting pattern that emerged during testing was how the savings scaled almost linearly with cluster size. In the four-node cluster, the model safely powered down one node; in the eight-node cluster, it powered down two; and in the twelve-node cluster, it powered down three. As the clusters grew, there was simply more room for efficiency gains, showing that the model can scale effectively to larger data centres.

17 of 19

Why This Matters

2 return flights from Cork to London per person

2 months of electricity for an average Irish household

What 25 trees absorb in an entire year

So what does that saving of six hundred and forty-two kilograms of CO₂ per year actually mean in real terms?

It’s about the same as two return flights from Cork to London per person, or roughly two months of electricity use for the average Irish household.

It’s also what twenty-five trees absorb over the course of a full year.

And remember, that figure comes from just three nodes in a twelve-node cluster. In a modern data centre, that could mean hundreds or even thousands of nodes, multiplied across racks, regions, and institutions.

So the impact isn’t only technical. It’s environmental, it’s scalable, and it’s immediate.

This is what happens when we start to see resilience and sustainability not as competing goals, but as parts of the same system, each strengthening the other.

18 of 19

Conclusions & Future Research

Conclusions

RL transformed Kubernetes into a self-optimising, energy-aware platform
Dovetail design delivered resilience and sustainability in one architecture
Outperformed Kubernetes ReplicaSets – kept structure, cut power
Lightweight Q-learning achieved real-time, scalable efficiency
Marks a progressive step toward carbon-intelligent cloud infrastructure

Future Work

Validate performance at scale in a live Kubernetes cluster to measure real-world energy and CO₂ savings
Stress-test resilience under live failure conditions to refine self-healing behaviour
Adapt the RL architecture for broader orchestration contexts – from edge to virtualised and HPC environments
Take the next step toward embedding carbon awareness into native orchestration
Enable others to reduce their CO₂ footprint through shared, open innovation

To wrap up, this research demonstrated that reinforcement learning can make Kubernetes far smarter, turning it from a static scheduler into one that’s self-optimising and energy-aware.

By applying the dovetail design principle, it became possible to unite resilience and sustainability within a single system, something existing schedulers have never truly achieved.

Looking ahead, there are several potential avenues for further exploration. These include validating the model at larger scale, studying how it behaves under live failures, and adapting the approach for other environments such as virtual machines or high-performance clusters. There’s also strong potential for open collaboration, allowing others to embed carbon awareness directly into their orchestration tools.

And the key message I want to leave you with is this: sustainability in technology will not come from doing less, but from designing better. From building systems that are not only resilient in how they run, but responsible in how they consume.

Data centres will continue to power our digital lives, but how we power them is up to us. By reducing their emissions, we are not only improving our technology, we are safeguarding the natural world that sustains us, for ourselves, and for those who will inherit it.

19 of 19

Thank

You