diff options
Diffstat (limited to 'content/design.tex')
| -rw-r--r-- | content/design.tex | 102 |
1 files changed, 89 insertions, 13 deletions
diff --git a/content/design.tex b/content/design.tex index b14dfec..48d6ffd 100644 --- a/content/design.tex +++ b/content/design.tex @@ -1,4 +1,6 @@ -\chapter{Design}\label{s:design} +% Changed chapter name, as suggested by Alexandru +\chapter{Design of \mysystem, a Digital Twin For Predictive Analysis of Datacenters}\label{s:design} +\section{Overview}\label{ss:design_overview} \begin{mynote} Our contribution in this chapter is three-fold: \vspace{-0.2cm} @@ -106,30 +108,104 @@ In addition to the functional requirements, we also present non-functional requi Without \textbf{NFR1}, \mysystem's insights will not be timely, and will be useless to datacenter operators. \item \textbf{The system should log the ingestion and processing of metrics.} \\ The system should provide a log of the current network traffic to and from the digital twin. - \item \textbf{The system should adhere to modern software development standards.} \\ The system should follow modern coding principles and guidelines to ensure reproducibility and usefulness for future work. Without \textbf{NFR3}, it will be difficult for current and future digital twin developers to include predictive analytics using \mysystem in their deployments. - \item \textbf{The system should provide insights at varying levels of confidence.} \\ With the huge amount of telemetry data incoming from the physical twin, the digital counterpart must be able to filter and pre-process the telemetry. Without \textbf{NFR4}, the system will present overwhelming amount of information to its users, rendering it unusable. \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. +\begin{figure}[ht] + \centering + \includegraphics[width=0.75\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} + The architecture was designed with the \emph{AtLarge Design Process}~\cite{DBLP:conf/icdcs/IosupVTETBFMT19} over several iterations in the past months.} + \label{fig:reference_architecture} \end{figure} -\subsection{Digital Thread} +\section{Overview of \mysystem Architecture}\label{ss:design_of_mysystem} +As a result of the \emph{AtLarge Design Process}~\cite{DBLP:conf/icdcs/IosupVTETBFMT19} designed a reference architecture for a predictive datacenter digital twin. +\Cref{fig:reference_architecture} encompasses 4 main elements: +\begin{enumerate*}[label=(\Roman*)] + \item physical datacenter + \item digital thread + \item digital twin + \item predictive analytics. +\end{enumerate*} -\subsection{Data Storage} +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. +We envision \gls{dcdt}s as systems that contain a human-in-the-loop, which can control and overwrite the system's autonomous decisions. +Datacenter Operators (\myCircled{1c}) interact with both the Servers (\myCircled{1b}), and have the ability to overwrite the potential autonomous digital twin decisions, stemming from component (\myCircled{2c}), the System Knobs. -\subsection{Predictive Analytics Module} +The Digital Thread (II) is a novel contribution from \Cref{s:background}. +It separates the physical world from the virtual world, and contains components that do not belong to either twin, or belong to both twins. +It contains the Interactive Dashboard (\myCircled{2a}), the Message Broker (\myCircled{2b}), and System Knobs (\myCircled{2c}). -\section{Discussion}\label{ss:design_discussion} +To fulfill the functional requirements of our system, we incorporate element (\myCircled{2a}), the Interactive Dashboard to our system. +This dashboard ingests data coming directly from the Message Broker (\myCircled{2b}) and from the long-term storage (\myCircled{3a}), the Database. +The Interactive Dashboard (\myCircled{2a}) allows datacenter operators to see the telemetry data arrive to the digital twin in real time. + +The Message Broker (\myCircled{2b}) is a crucial component to the reference architecture, because it facilities the physical twin $\rightarrow$ virtual twin connection. +A low-latency, high-throughput message broker partly meets our functional requirements to enable arbitrary amounts of telemetry data transfer. +We elaborate on the specific components that make up the message broker (\myCircled{2b}) in \Cref{sss:message_broker}. + +The System Knobs (\myCircled{2c}) represent the different cogs within the datacenter software and hardware (\myCircled{1b}) that can be adjusted during runtime (\eg to optimize \gls{pue}, change cooling strategy, allocate compute resources). +For example, System Knobs (\myCircled{2c}) within the datacenter scheduler can be tuned to schedule jobs on Servers (\myCircled{1b}) that are least likely to experience future downtime. +The autonomous actions of the digital twin (the tuning of the System Knobs (\myCircled{2c})) can be further adjusted by Datacenter Operators (\myCircled{1c}). + +In our design, we explicitly differentiate between the physical and virtual space by including the Digital Twin (III) in a separate box. +The Digital Twin (III) constitutes of the long-term storage (\myCircled{3a}), short-term storage (\myCircled{3b}), the API Server (\myCircled{3c}) and the Predictive Analytics (IV) module. + +Long-term storage, namely a Database (\myCircled{3a}) is crucial to enable real-time visualizations (\myCircled{2a}), and to model long-term system behaviour. +This fulfills the functional requirements for our system, as we set out to differentiate between in-band data analytics, and out-of-band data analysis. +The data is consumed by the Database (\myCircled{3a}) directly from the Message Broker (\myCircled{2b}). +In-between, simple data pre-processing can take place. +Short-term storage, in the form of a Cache (\myCircled{3b}) is essential for in-band data analytics, ``on-the-go''. +The Cache (\myCircled{3b}) retains the data consumed from the Message Broker (\myCircled{2b}), and for a short period of time keeps a copy. +The data analytics performed on the Database (\myCircled{3a}) dataset and the Cache (\myCircled{3b}) adhere to the use-cases for predictive (long-term) and descriptive (long-term, short-term) data analytics. + +The Message Broker (\myCircled{2b}) enables one-way connection (physical twin $\rightarrow$ digital twin). +The API Server (\myCircled{3c}) enables the digital twin $\rightarrow$ link. +The API Server (\myCircled{3c}) communicates directly with the System Knobs (\myCircled{2c}) in order to take meaningful action, based on the (predictive) insights generated by the Digital Twin (III). +Additionally, the Physical Twin (III) can query the API Server (\myCircled{3c}) for one-shot requests (\eg to create a new datacenter prototype configuration, to request special data analysis). +Moreover, the Datacenter Operators (\myCircled{1c}) can query the API Server (\myCircled{3c}) for extra insights, when necessary. + +The Predictive Analytics (IV) module is an extensible part of the reference architecture, enabling different kinds of predictive analysis. +In our design, to facilitate meaningful predictions we incorporate an Event-driven Simulator (\myCircled{4a}), Analytics Engine (\myCircled{4b}), and a Monitoring Service (\myCircled{4c}). + +We chose an Event-driven Simulator (\myCircled{4a}) as a core element of predictive analytics. +For the rationale behind this decision see \Cref{ss:datacenters}. +The predictions from the Event-driven Simulator (\myCircled{4a}) communicate directly with the Database (\myCircled{3a}) to store the simulation results, and with the Analytics Engine (\myCircled{4b}). + +The Analytics Engine (\myCircled{4b}) performs descriptive and predictive data analytics on the results from the Event-driven Simulator (\myCircled{4a}) and the telemetry data collected from the physical datacenter (stored in (\myCircled{3a}, \myCircled{3b})). +This component is highly extensible to accommodate the different types of analytics (\eg \gls{ml}, \gls{ai}, statistical methods). +The results of the data analysis are propagated to the API Server (\myCircled{3c}) to be queued for retrieval by the physical twin. + +The Monitoring Service (\myCircled{4c}) serves as a separate thread to watch over the collected telemetry in real-time. +It facilities detection of irregularities in collected data, which adheres to the functional requirements set out for the system. +Any discrepancies are communicated to the Analytics Engine (\myCircled{4b}) for further analysis, and potential insights. + +\begin{figure}[t] + \centering + \includegraphics[width=\linewidth]{images/message_broker.png} + \caption{The detailed view of the Message Broker (\myCircled{2b}) from \Cref{fig:reference_architecture}.} + \label{fig:message_broker} +\end{figure} +\section{The Digital Thread and Predictive Analytics}\label{ss:detailed_design} +\subsection{Message Broker}\label{sss:message_broker} +The Message Broker (\myCircled{2b}) is a component is slightly more complex, and necessities a separate diagram. +In \Cref{fig:message_broker} we present the composite elements that make up the Message Broker. +In particular, the \emph{schema registry} and the \emph{connector manager} play a crucial part in fulfilling the functional requirements of our system. +The \emph{schema registry} allows the telemetry producer to submit \emph{any} data format for sending (and storing) the telemetry data.The registry is responsible for detecting what kind of format is the data sent in, and automatically adjusting the schema within the \emph{data pipeline}. +The connector manager is responsible for joining multiple distinct services to a single data pipeline. +In the reference architecture, the consumers would constitute the Database (\myCircled{3a}), the Cache (\myCircled{3b}), and the Interactive Dashboard (\myCircled{2a}). +What is remarkable about the connector manager is the ability to swiftly connect more consumers to the system. +This way, the predictive digital twin can facilitate multiple different types of analytics engines or techniques. +Additionally, the setup is \Cref{fig:message_broker} is currently standard industry practice for large software deployments. +\section{Discussion}\label{ss:design_discussion} |