diff options
Diffstat (limited to 'content')
| -rw-r--r-- | content/background.tex | 32 |
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. |