diff options
Diffstat (limited to 'content/design.tex')
| -rw-r--r-- | content/design.tex | 19 |
1 files changed, 14 insertions, 5 deletions
diff --git a/content/design.tex b/content/design.tex index 7d4a73a..72414a3 100644 --- a/content/design.tex +++ b/content/design.tex @@ -2,12 +2,14 @@ \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: + Addressing RQ$_2$, our contribution in this chapter is three-fold: \vspace{-0.2cm} \begin{enumerate}[label=\emph{C\textsubscript{\arabic*}}, itemsep=0.2pt] - \item We analyze the requirements for \mysystem (\Cref{ss:requirements_analysis}). - \item We propose a conceptual design for \mysystem's architecture (\Cref{ss:design_of_mysystem}) - \item We describe how \mysystem fulfills the functional and non-functional requirements in \Cref{ss:requirement_validation}. + \item We analyze the requirements for digital twins enabling predictive analysis of datacenters~(\Cref{ss:requirements_analysis}). + + \item We design the \mysystem architecture as a digital twin enabling predictive analysis of datacenters through discrete-event simulation and ODA~(\Cref{ss:design_of_mysystem}). + + \item We analyze how \mysystem fulfills the functional and non-functional requirements~(\Cref{ss:requirement_validation}). \end{enumerate} \end{mynote} \section{Requirements Analysis}\label{ss:requirements_analysis} @@ -107,6 +109,9 @@ In addition to the functional requirements, we also present non-functional requi \item \textbf{Using \mysystem should not introduce any delays in visualizations longer than 1 second.}\\ The system must work in real-time, without significant delay. We impose 1 second delay as acceptable to datacenter engineers. + We have arrived at the 1 second threshold due to the fact that datacenter operators need time to react to sudden changes in the facility behaviour. + To expect a sub-1-second performance from human employees is unjustified. + At the same time, any delay $>1$ second can already negatively impact engineer's ability to react to different events at the same time in the correct order (\ie $>1$ delay hinders the ability of technicians to follow the specific datacenter protocols and policies during an event). The system must support datacenter operators with insights at fine-grained granularity, so that insights derived from data analysis remain accurate upon reception by datacenter operators. 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.} \\ @@ -227,7 +232,11 @@ The Interactive Dashboard (\myCircled{2a}) supports (\textbf{FR2}), as it allows 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. +In our design, we ensure (\textbf{NFR1}) is in a two-fold way. +Firstly, we ensure a direct connection between the Interactive Dashboard (\myCircled{2a}) and the Message Broker (\myCircled{2b}). +As the Message Broker (\myCircled{2b}) is capable of accommodating multiple consumers, the Interactive Dashboard (\myCircled{2b}) receives the same telemetry at the same rate as the live prediction engine. +Secondly, through a direct connection to the Database (\myCircled{3a}), the Interactive Dashboard (\myCircled{2a}) can instantly retrieve all historical patterns. +Thus, we meet (\textbf{NFR1}). (\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}). |