diff options
Diffstat (limited to 'content')
| -rw-r--r-- | content/background.tex | 2 | ||||
| -rw-r--r-- | content/design.tex | 57 |
2 files changed, 56 insertions, 3 deletions
diff --git a/content/background.tex b/content/background.tex index 3e0a5cf..97dc6aa 100644 --- a/content/background.tex +++ b/content/background.tex @@ -101,7 +101,7 @@ However, the fidelity of failure modeling inside a datacenter simulation is stil 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. \begin{figure}[t] \centering - \includegraphics[width=0.95\linewidth]{images/five_dimensional_dt.pdf} + \includegraphics[width=0.95\linewidth]{images/five_dimensional_dt.png} \caption[A basic framework for the \gls{dt}.]{A basic framework for the \gls{dt}. Four core elements of a \gls{dt} are defined: The physical entity (\myCircled{1}) and the simulated virtual twin (\myCircled{2}). A service for out-of-band data analytics (\myCircled{3}) and a persistent storage of historical data (\myCircled{4}) are crucial to the \gls{dt} because they are necessary to gain meaningful monitoring insights. Adapted from Tao \etal ~\cite{DBLP:conf/cirp/TAO2018169}.} %Fei Tao is a renowned figure with over 62k citations. He is a figure of authority on digital twins.% \label{fig:five_dimensional_dt} diff --git a/content/design.tex b/content/design.tex index 8ae83e6..7d4a73a 100644 --- a/content/design.tex +++ b/content/design.tex @@ -131,7 +131,7 @@ As a result of the \emph{AtLarge Design Process}~\cite{DBLP:conf/icdcs/IosupVTET \end{enumerate*} \subsection{The Physical Datacenter}\label{sss:physical_datacenter} -The physical datacenter (I) encompasses 3 core elements important to digital twinning. +The Physical Datacenter (I) encompasses 3 core elements important to digital twinning. Workloads (\myCircled{1a}) include the hardware requirements of each datacenter job and the submission time. They are executed on the datacenter compute (\myCircled{1b}), which is controlled partly by the Datacenter Operators (\myCircled{1c}). Component (\myCircled{1c}), while seemingly unimportant, is crucial to the digital twin design. @@ -219,9 +219,62 @@ Any discrepancies are communicated to the Analytics Engine (\myCircled{4b}) for \section{Requirement Validation}\label{ss:requirement_validation} %How does this model satisfy the requirements? %How did you arrive at this specific model? +In this section we describe the rationale behind the different design decisions of \mysystem. +To show that our model satisfies the functional and non-functional requirements, we map each component of \mysystem onto the requirements it fulfills. +\input{sources/requirements_validation.tex} +The Interactive Dashboard (\myCircled{2a}) supports (\textbf{FR2}), as it allows to display the failures detected to datacenter operators; it is the core of (\textbf{FR4}) because descriptive analytics are synonymous to visualizations. +It enables (\textbf{FR5}) because the predictive insights can be displayed directly through the dashboard to the datacenter operators. +Operators can then overwrite the autonomous decisions performed by the \gls{dt}. +Dashboards are the current industry practice for clear data visualization (\textbf{FR7}). +For our implementation, we ensure (\textbf{NFR1}) is met by including a state-of-the-art dashboard. +(\textbf{NFR2}) and (\textbf{NFR3}) are met by including in the system implementation a dashboard that enables logging of metrics. +The Message Broker (\myCircled{2b}) indirectly fulfills (\textbf{FR1}). +A good and robust message broker alleviates potential bottlenecks that might stem from large data transfer. +My including a dedicated message broker, we ensure the bottle neck when twinning is not \mysystem. +As the Message Broker (\myCircled{2b}) is a vital component in the communication between the datacenter operators and the physical twin, it indirectly enables (\textbf{FR2}), (\textbf{FR3}), (\textbf{FR4}), (\textbf{FR5}). +In the other direction, to ensure that the \gls{dcdt} can ingest any amount of data, the Message Broker (\myCircled{2b}) is needed for (\textbf{FR6}). +The non-functional requirements are met by including a state-of-the-art message broker from either academia or the industry in the implementation. +The inclusion of System Knobs (\myCircled{2c}) in the reference architecture fulfills (\textbf{FR2}). +With autonomous actions, the \gls{dt} can alter the operation of the datacenter based on the detected failures. +Failure detection must support datacenter operators in meeting \gls{sla}s. +Autonomous actions, enabled by System Knobs (\myCircled{2c}) help achieve that. +(\textbf{FR4}) and (\textbf{FR5}) are met by ensuring the insights that come from the \gls{dt} can be automated with the system knobs. +Supporting both predictive and descriptive analytics is core to the system knobs. +(\textbf{NFR4}) is met as the existing digital twin deployments often contain (indirectly) the System Knobs (\myCircled{2c}) element. +Including it in our design adheres to best design practice. +Importantly, (\textbf{NFR5}) is fulfilled together by creating a predictive analytics engine that is capable of intelligent insights and system knobs. +In order for the predictive insights to be realized, systems knobs are needed. +The Database (\myCircled{2c}) meets (\textbf{FR3}), (\textbf{FR4}), (\textbf{FR5}), (\textbf{FR6}) and (\textbf{NFR2}). +Trivially, including a simple \gls{dbms} in the architecture fulfills (\textbf{FR3}). +For the different types of analytics (\textbf{FR4}), (\textbf{FR5}), the Database (\myCircled{2c}) enables insights from historical patterns. +Database are the current state-of-the-art in storing telemetry (\textbf{FR6}). +They are designed to hold arbitrary volume of data. +Lastly, (\textbf{NFR2}) is met by storing in the database the logs from both the \gls{dcdt} and the physical datacenter. -\section{Discussion}\label{ss:discussion_archi} +The API Server (\myCircled{3c}) ensures (\textbf{FR4}), (\textbf{FR5}), (\textbf{FR2}) and (\textbf{NFR3}). +The server, which facilitates the insights that come into the System Knobs (\myCircled{2c}), by proxy enables (\textbf{FR4}) and (\textbf{FR5}). +To detect failures, some sort of notification daemon is needed for the datacenter operators, not just the dashboard. +The API Server (\myCircled{3c}) fulfills that role, ensuring (\textbf{FR2}). +The API server (\myCircled{3c}), specifically a server using the \gls{http} protocol is a state-of-the-art approach to existing digital twin communication (\textbf{NFR3}). + +The Cache (\myCircled{3b}) ensures the same requirements as the Database (\myCircled{3a}), with a couple of exceptions. +Namely, it also ensures (\textbf{NFR1}) and (\textbf{NFR3}). +Caching is needed for sub 1-second visualizations, and the inclusion of a cache for in-band data analytics is the current community practice. + +In our design, we include an Event-driven Simulator (\myCircled{4a}). +This ensures (\textbf{FR1}), (\textbf{FR2}), (\textbf{FR4}), (\textbf{FR5}) and all non-functional requirements except (\textbf{NFR2}). +Using a discrete-event simulator ensures that our system can handle workloads that are representative of the simulator at use. +Simulation, a method that is widely accepted by the scientific community, is one way \mysystem can ensure (\textbf{FR1}). +Detecting failures, enabling both descriptive and predictive analytics depends on how good of a simulator (\myCircled{4a}) is. +In principle, a robust, holistic simulator incorporated into the predictive engine is capable of meeting (\textbf{FR4}), (\textbf{FR2}) and (\textbf{FR5}). +Simulation also allows to model large workloads and to interact with the simulation in real-time (\textbf{NFR1}), it is considered a state-of-the-art approach to datacenter modelling (\textbf{NFR3}) and, with good data analytics provides enough data for insights at varying levels of confidence (\textbf{NFR4}). + +The Analytics Engine component (\myCircled{4b}) and the Monitoring Service (\myCircled{4c}) fulfill the same set of requirements, namely (\textbf{FR1}), (\textbf{FR2}), (\textbf{FR4}) and (\textbf{FR5}). +Additionally the Analytics Engine (\myCircled{4b}) also fulfills (\textbf{NFR4}), as it provides the capability to differentiate between different levels of confidence. +Both components are working together in unison, closely watching and reacting to the metrics from the real datacenter. +Hence, they fulfill (\textbf{FR2}), (\textbf{FR4}) and (\textbf{FR5}) and are crucial to the \gls{dcdt} operation. +(\textbf{FR1}) is fulfilled by ensuring both the Analytics Engine and the Monitoring Service are not the source of any bottlenecks during the system implementation. |