1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
|
\chapter{Design}\label{s:design}
\begin{mynote}
Our contribution in this chapter is three-fold:
\vspace{-0.2cm}
\begin{enumerate}[label=\emph{C\textsubscript{\arabic*}}, itemsep=0.2pt]
\item We analyze the requirements for \mysystem (\Cref{ss:requirements_analysis}).
\item We propose a conceptual design for \mysystem's architecture (\Cref{ss:design_of_mysystem})
\item We describe how \mysystem enables predictive analytics through digital twinning (\Cref{ss:design_discussion})
\end{enumerate}
\end{mynote}
\section{Requirements Analysis}\label{ss:requirements_analysis}
In this section we determine the requirements that should be fulfilled by \mysystem.
We present here the stakeholders identified by our literature survey (see \Cref{sss:digital_twins_for_datacenters}) and the relevant use-cases.
Afterwards, we list the functional and non-functional requirements for \mysystem.
\subsection{Stakeholders}\label{sss:stakeholders}
We identify four main stakeholders of a predictive datacenter digital twin:
\begin{enumerate}[label=\textbf{S\arabic* --},align=left]
\item \textbf{Datacenter Managers}\\
Responsible for maintenance and operation of the warehouse, operators manage the datacenter daily.
They interact with the servers, bring downed hosts up and ensure customers' services run smoothly at all times.
Datacenter operators need to ensure different \gls{sla}s are met, energy costs are balanced and carbon emission quota is maintained.
\item \textbf{Datacenter Technicians}\\
The term datacenter engineers encompasses datacenter architects and technicians alike.
From the moment the datacenter layout is determined, to the physical process of booting the server racks for the first time, datacenter engineers help build and maintain the datacenter.
They must continuously adapt to changing requirements and ensure everything goes smoothly~\cite{DBLP:journals/computer/AthavaleBBMMPS24}.
\item \textbf{Scientists and Academia}\\
Digital twinning generates unprecedented amount of data.
To bring valuable insights, the ingested metrics must be effectively analyzed.
Scientists can draw conclusions from the monitoring data and in some deployments already benefit from the voluminous output of \gls{dcdt}s~\cite{DBLP:conf/noms/ZhangZLZWC22}.
\item \textbf{Customers and Users}\\
Digital twins are already used to visualize both facilities and human beings alike for the benefit of users and customers.
Cloud and HPC users are not directly interacting with the system, but pay for services hosted in the datacenter and are one of the primary stakeholders of digital twinning.
Not only through 3D datacenter visualizations, but also from the continuously generated metrics can users and customers benefit from \gls{dcdt}s.
\end{enumerate}
\subsection{Use-cases}\label{sss:use_cases}
Based on the identified stakeholders we list 6 potential use-cases for a predictive datacenter digital twin:
\begin{enumerate}[label=\textbf{UC\arabic* --},align=left]
\item \textbf{Energy Optimization} \\
Predicting and modeling energy optimization is curcial for \gls{dcdt}s.
It is the main use-case of some existing systems~\cite{DBLP:conf/sc/BrewerMKWBHSGGW24}.
Effective energy optimization, including the adjustments to the consumed energy type is a crucial use-case of \gls{dcdt}s.
\item \textbf{Failure Management} \\
Predictive maintenance of both hardware and software failures alike, by simulating the possible failure distribution of a running workload, can lower downtime, terminated tasks and ensure \gls{sla}s are not missed~\cite{DBLP:journals/computer/AthavaleBBMMPS24}.
\item \textbf{Heat Modelling} \\
Heat modeling is the primary use case of existing \gls{dcdt}s (see \Cref{tab:dt_features_comparison}).
Correct thermal management of the warehouse can optimize cooling strategies, leading to lower bills and maintenance costs.
\item \textbf{Network Traffic Modelling} \\
Congestion management and traffic routing can effectively benefit from digital twinning.
Detecting bottlenecks, adjusting datacenter protocols and calibrating switches and interconnects is already a important use-case for \gls{dcdt}~\cite{DBLP:conf/sigcomm/HongWDSSHZY21}.
\item \textbf{Virtual Prototyping} \\
Digital twinning can be used to provide insight into the system before changes are made.
Using a \gls{dcdt}, the operators can change, model and shape the datacenter to estimate their effect.
Virtual prototyping encompasses interacting with an existing datacenter model, or with a proof-of-concept, not yet constructed warehouse.
\item \textbf{Monitoring and Visualization} \\
3D visualizations and dashboards are of the utmost importance to all stakeholders, due to the insights they provide.
With real-time data ingestion and the two-way feedback loop, \gls{dcdt}s can empower descriptive analytics.
This use-case already shapes many existing systems (see \Cref{tab:dt_features_comparison}).
\end{enumerate}
\subsection{Functional Requirements}\label{sss:functional_requirements}
Based on a subset of the above use-cases, we formulate the functional and non-functional requirements for \mysystem:
\begin{enumerate}[label=\textbf{FR\arabic* --},align=left]
\item \textbf{The system should be able to handle workloads of arbitrary size.} \\
Existing systems range from Cloud through the Edge to HPC digital twins.
Therefore, \mysystem must support workloads similar in length and type to the commercial setting.
Without \textbf{FR1}, \mysystem will be incomplete, and like the majority of the \Cref{tab:dt_features_comparison} systems, its use-case will be niche.
\textbf{FR1} is necessary to avoid overly-specializing the \gls{dcdt}.
\item \textbf{The system should support failure detection.}\\
Failures are of crucial concern to datacenter operators.
The system detect and report failures to datacenter operators.
Without \textbf{FR2}, the system will not be able to help datacenter operators meet \gls{sla}s.
Including \textbf{FR2} is necessary to ensure that failures, which which can cause financial penalties, are detected in a timely manner so as to meet the different \gls{sla}s.
\item \textbf{The system should be capable of long-term and short-term data storage.}\\
\textbf{FR3} is necessary for \textbf{FR4} and \textbf{FR5}.
Without \textbf{FR3}, the system cannot support \gls{oda} techniques.
A system cannot be considered a \gls{dt} without insights stemming from accurate data analytics~\cite{DBLP:usdoe/report/AP26894}.
\gls{nasem} digital twin definition requires both real-time insights, and guidance based on historical-patterns.
Therefore, it is imperative to ensure \textbf{FR3}.
\item \textbf{The system should support real-time descriptive data analytics.}\\
There are many types of data analytics present is existing deployments~\cite{DBLP:conf/wosp/SumanCNTMI24}.
In order to scope down the project, we only select several use-cases for \gls{my_system}.
Out of the 4 prime analytics type, we find in the literature survey the predictive analytics to be the most urgently needed, and descriptive analytics to be the most prevailing type of data processing.
Therefore, in order to achieve performance on par with previous systems, and to ensure our system meets the official \gls{nasem} definition, \textbf{FR4} is needed.
\item \textbf{The system should enable predictive data analytics.}\\
The system should help future researchers incorporate predictive data analytics engines, regardless of the statistical modelling technique.
This is our novel contribution to the scientific field of \gls{dcdt}s.
Without \textbf{FR5}, we miss the aim of our entire project.
\item \textbf{The system should be able to process arbitrary amounts of telemetry.}\\
The size of the \gls{ai} economy is expected to grow~\cite{DBLP:journals/computer/AthavaleBBMMPS24}.
As a result, both current and future datacenters will generate huge amount of data.
Our system must be capable of ingesting and processing different metrics regardless of the volume of incoming messages.
Without \textbf{FR6}, we hinder the adoption of \mysystem in modern and future datacenters.
\item \textbf{The model should be capable of clear data visualization.}
The system must have a user-friendly, visual interface for data analytics, and support them in real-time.
Without \textbf{FR7}, we exclude important stakeholders such as customers and users from the potential benefactors of our system.
\end{enumerate}
\subsection{Non-functional Requirements}\label{sss:non_functional_requirements}
In addition to the functional requirements, we also present non-functional requirements for \mysystem:
\begin{enumerate}[label=\textbf{NFR\arabic* --},align=left]
\item \textbf{Datacenter} \\
\end{enumerate}
\section{Design of \emph{Sunfish}}\label{ss:design_of_mysystem}
\begin{figure}[t]
\includegraphics[width=\linewidth]{images/ref_architecture.png}
\caption{ The predictive datacenter digital twin reference architecture.
We call the system \emph{Sunfish}.
The architecture was designed with the \emph{AtLarge Design Process}~\cite{DBLP:conf/icdcs/IosupVTETBFMT19} over several iterations in the past months}
\end{figure}
\subsection{Digital Thread}
\subsection{Data Storage}
\subsection{Predictive Analytics Module}
\section{Discussion}\label{ss:design_discussion}
|
