From d4c3a916398e4eee9c1eaaa840968d4b19f40c91 Mon Sep 17 00:00:00 2001 From: mjkwiatkowski Date: Wed, 15 Jul 2026 15:56:09 +0200 Subject: feat: finished section 2.4.3 --- content/background.tex | 55 +++++++++++++++++++++++++++++++++++++++++++++++++- content/conclusion.tex | 2 +- content/design.tex | 2 +- 3 files changed, 56 insertions(+), 3 deletions(-) diff --git a/content/background.tex b/content/background.tex index 17d7d47..6e39e6d 100644 --- a/content/background.tex +++ b/content/background.tex @@ -158,7 +158,7 @@ We select only the digital twins that adhere closest to the \gls{nasem} definiti The aim of this survey is to search and organize the field of \gls{dcdt}s. In this subsection, we describe the methods for collecting relevant scientific articles and present the design of the system model for generic \gls{dcdt}s. -\begin{enumerate}[label=\textbf{\arabic*.}, align=left] +\begin{enumerate}[label=\textbf{\arabic*.}] \item \textbf{Review Strategy}\\ The most common methods for conducting literature surveys are \begin{enumerate*}[label=(\arabic*)] \item random traversal of the related literature, @@ -262,6 +262,59 @@ 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} +In \Cref{fig:system_model} we present a holistic model of \gls{dcdt}s from \Cref{sss:advanced_dts}. +The figure includes the functionality present in the majority of \gls{dcdt}s, combined together into a unified model. +We distinguish 3 core elements of every \gls{dcdt}: +\begin{enumerate*}[label=(\arabic*)] + \item the virtual world + \item digital thread + \item the physical world +\end{enumerate*}. +\begin{enumerate}[label=\textbf{\arabic*.}] + \item \textbf{Virtual World} contains the \gls{dcdt}. + It represents all the components that exist in software. + Every \gls{dcdt} model can be categorized into two sub-categories: + \begin{enumerate*}[label=(\arabic*)] + \item infrastructure model + \item operations model + \end{enumerate*}. + Each \gls{dcdt} from \Cref{sss:advanced_dts} contains a model of the infrastructure within the datacenter. + This includes virtual replicas of the hardware elements (\eg servers, networking, server racks, rooms). + These elements have varying degrees of fidelity. + For example, NetGraph models the datacenter interconnect using purely configuration files. + On the contrary ExaDigiT models the datacenter hardware fully in 3D. + Both offer virtual infrastructure models as a part of the \gls{dcdt}. + + The operations model is likewise present in all deployments. + It models the \emph{behaviour} of the datacenter, \ie the data flow, the different workloads running on the compute, the amount of data stored in each hosts \etc. + Both the infrastructure model and the operations model are part of all \gls{dcdt} deployments from \Cref{sss:advanced_dts}. + A digital twin that contains only the infrastructure model, cannot enable insights into the real-time operation of the datacenter. + Likewise, a \gls{dcdt} containing just the operations model does not possess a capability to \eg simulate the datacenter. + Only both, combined together enable the insights envisioned by the \gls{nasem} \gls{dt} definition~\cite{DBLP:usdoe/report/AP26894}. + \item \textbf{Digital Thread} connects the virtual world to the physical world. + This is a novel contribution of our thesis. + The digital thread is a \emph{conceptual} element that unites the components which do not belong in either of the worlds. + All \gls{dcdt} programs from \Cref{sss:advanced_dts} contain elements that are ``in-between'' the physical and virtual twin. + After comparing and corroborating these components across deployments, we find 4 that prevail the most: + \begin{enumerate*}[label=(\arabic*)] + \item the visualization interface + \item the message broker + \item the monitoring system + \item the system knobs + \end{enumerate*}. + These elements \emph{connect} facilitate the connection between the physical and the virtual. + For example, the visualization interface provides insights from the metrics collected by the \gls{dcdt} (virtual world) to the datacenter operators (physical world). + The message broker transfers the data from the real datacenter (physical world) to the digital twin (virtual world). + \item \textbf{Physical World} models the real datacenter. + All deployments in \Cref{sss:advanced_dts} contain this element. + Moreover, within the datacenter, we distinguish between 3 core elements that are necessary to model the datacenter faithfully\begin{enumerate*}[label=(\arabic*)] + \item the \gls{it} equipment + \item cooling subsystem + \item power supply + \end{enumerate*}. + All of the aforementioned systems from \Cref{sss:advanced_dts} model either of the 3 elements. + In order to adhere to the holistic view of \gls{dcdt}s, and to fulfill the \gls{nasem}'s definition, the system must contain all 3 of these elements. +\end{enumerate} \begin{figure}[t] \centering diff --git a/content/conclusion.tex b/content/conclusion.tex index 1df3d95..86d9f68 100644 --- a/content/conclusion.tex +++ b/content/conclusion.tex @@ -37,7 +37,7 @@ We answer the main research question by addressing each sub-research question. \item \emph{How to validate and evaluate a datacenter digital twin architecture in relation to system requirements?}\\ To answer the last research question we crated a prototype. - During the prototype design, we used state-of-the-practice software, such as \code{Confluent Kafka}, \code{Redis} and \code{PostgreSQL} (see \Cref{ss:implementation_overview}). + During the prototype design, we used state-of-the-practice software, such as \code{Confluent Kafka}, \code{Redis} and \code{PostgreSQL} (see \Cref{ss:detailed_implementation_overview}). However, as it turns out, evaluating \gls{dcdt}s is not a trivial task. Lacking the physical datacenter to experiment with, we came up with a novel digital twin evaluation method. Our method, relies solely on discrete-event simulation to model the physical datacenter, overcoming the problems of real-world experimentation (\eg sustainability, costliness, reproducibility). diff --git a/content/design.tex b/content/design.tex index 2eb195d..4fbb1b4 100644 --- a/content/design.tex +++ b/content/design.tex @@ -12,7 +12,7 @@ \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. +We present here the stakeholders identified by our literature survey (see \Cref{ss: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} -- cgit v1.2.3