summaryrefslogtreecommitdiff
path: root/content/background.tex
diff options
context:
space:
mode:
authormjkwiatkowski <mati.rewa@gmail.com>2026-07-07 16:44:19 +0200
committermjkwiatkowski <mati.rewa@gmail.com>2026-07-07 16:44:19 +0200
commit060e3a8002150d5795d489ccec999601d9109a42 (patch)
treec91ec2de7cb9eaf53ff30c78269da7a7052d15eb /content/background.tex
parent8191ba9fc68390d917b03dbbc936bd1c528e5a2b (diff)
feat: finished section 2.1.2
Diffstat (limited to 'content/background.tex')
-rw-r--r--content/background.tex32
1 files changed, 20 insertions, 12 deletions
diff --git a/content/background.tex b/content/background.tex
index 2f9cb2a..6be66ea 100644
--- a/content/background.tex
+++ b/content/background.tex
@@ -19,15 +19,23 @@ The scientific community has developed several datacenter simulators (see \Cref{
In our work, we decided to use \code{OpenDC}, because we find it important for a simulator to model hardware failures well.
\emph{Failure models} are a carefully calibrated, advanced feature of \code{OpenDC}.
-\subsection{Hardware Failures}\label{sss:failures}
-
-%What is below here is true, but nonetheless the argumentation should be slightly changed. And a citation is needed.
-However, there has been little effort made to integrate analytics that enable consistent and reliable prediction of datacenter behaviour into a holistic digital twin of a datacenter.
-Nor has the fidelity of failure modeling inside a datacenter simulation increased.
-The failure model is still a linear model.
-Since a datacenter simulator is quite different from a digital twin, we cannot use the same computation methods (not as they are right now, at least) -- we must adapt them.
-The prediciton models are the same ones for the digital twin as the ones used for the datacenter simulator.
-Since a digital twin is not a standalone simulator, a change to how we both predict and model failures is necessary.
+\subsection{Compute Failures}\label{sss:failures}
+A failure is defined as ``an event that makes a system fail to operate according to its specifications``~\cite{DBLP:journals/jpdc/JavadiKIE13}.
+Hardware and software failures in datacenters result in service downtime, missed \gls{sla} and user inconvenience~\cite{DBLP:conf/acsos/TalluriOVTI21, DBLP:journals/jpdc/JavadiKIE13}.
+A good example of a software failure is a hypervisor crash.
+Each \gls{vm} within the crashed hypervisor is killed as a result.
+An example of a hardware failure is a host crash, where a single server stops working (\eg as a result of a disk fault, or faulty power supply cable).
+
+\code{OpenDC} uses the notion of a \emph{failure model} to simulate failures, alongside \emph{failure traces}.
+A failure model consists of two statistical distributions:
+\begin{enumerate*}[label=(\arabic*)]
+ \item to model service unavailability
+ \item to model service availability.
+\end{enumerate*}
+A failure trace is defined by an interval, duration, and intensity of several failures, which are later looped throughout the simulated workload (source \url{opendc.org}).
+In summary \code{OpenDC} enables experimentation with failures that enables insights that are not provided by other state-of-the-art software.
+However, the fidelity of failure modeling inside a datacenter simulation is still insufficient to predict in failures in real-time, as they happen in a physical datacenter.
+Since a datacenter simulator is quite different from a digital twin, we cannot use the same computation methods from simulation to predict real-time failures.
\section{Digital Twinning}\label{ss:digital-twinning}
% To fix: remove the \gls commands for ExaDigiT.
@@ -154,7 +162,7 @@ Kalibre takes the best of both \gls{ml} and \gls{cfd} approaches and achieves su
\subsection{System Model for Datacenter Digital Twinning}
\label{ss:system_model_for_dcdts}
-\begin{figure}[t]
+\begin{figure}[tb]
\centering
\includegraphics[width=\linewidth]{images/system_model.pdf}
\caption{A generic system model for data center digital twin deployments.
@@ -165,8 +173,8 @@ Kalibre takes the best of both \gls{ml} and \gls{cfd} approaches and achieves su
To summarize, many \gls{dcdt}'s model the cooling systems inside the warehouse, because in a typical datacenter cooling accounts for more than 40\% of total electricity usage~\cite{DBLP:conf/AppliedEnergy/Zhao20}.
Since the cooling subsystem is mainly airflow-based, \gls{dt} designers often opt for a \gls{cfd} approach to model the facility.
-The reason why a digital twin might be needed for a cooling subsystem is primarily because of inefficient operational strategy.
-The cooling system parameters are often set constant, regardless of outdoor temperature \etc~\cite{DBLP:conf/AppliedEnergy/Zhao20}.
+%The reason why a digital twin might be needed for a cooling subsystem is primarily because of inefficient operational strategy.
+%The cooling system parameters are often set constant, regardless of outdoor temperature \etc~\cite{DBLP:conf/AppliedEnergy/Zhao20}.
%Zhang \etal argues that their system is akin to an IoT sensor, essentially.
% This is an important consideration -- DT is not simply a sensor, it must have predictive capabilities and be able to simulate the future.
% Zhang argues that ``digital twin services'' are enabled by simulation monitoring \etc.