1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
\chapter{Implementation}\label{s:implementation}
In this chapter we describe the implementation of \gls{my_system}.
The main contribution of this chapter towards answering \emph{RQ3} is the prototype of \gls{my_system}.
After reading one should understand the technical decisions, choice of tools and modifications to existing software necessary for evaluation of \gls{my_system} in \Cref{s:evaluation}.
Any complex system is more than the sum of its parts~\cite{Wikipedia:article/Systems_Thinking}.
To understand why \gls{my_system} it is crucial to provide a holistic view on the prototype.
Therefore, the rest of the chapter is structured in a top-down approach: \Cref{ss:implementation_overview}
presents the rationale for using the specific software packages, \Cref{ss:data_flow} shows the flow of data within the system, and \Cref{ss:programming} details the different modifications and new software extensions.
\section{Overview}\label{ss:implementation_overview}
At the onset of the project, we decided \gls{my_system} will use only state-of-the-art software, deployed in the industry or evaluated in peer-reviewed scientific publications.
In order to facilitate visualizations and interactive dashboards, we decided to use \code{Grafana}~\cite{Wikipedia:article/Grafana}.
To enable the flow of data into the digital twin, we use \code{Kafka}~\cite{Wikipedia:article/Confluent}.
To store the in-band data we use a \code{Redis}~\cite{Wikipedia:article/Redis} cache, and for out-of-band data we use a \code{PostgreSQL}~\cite{Wikipedia:article/Postgresql}.
To enable predictive analytics, we chose a discrete-event simulator, \code{OpenDC}~\cite{GitHub:software/OpenDC}.
The \code{Analytics Engine}, \code{Monitoring Service}, and \code{HTTP Server} are described in detail in \Cref{ss:programming}.
\code{Grafana} is a state-of-the-art industry tool to visualize dashboards.
We posit it is crucial to include a user-friendly \gls{ui}.
A number of previous publications on digital twinning find dashboards important~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24, DBLP:conf/wosp/SumanCNTMI24, DBLP:conf/wosp/NicolaeTKLI26}.
We chose \code{Grafana} instead of other software packages because of its seamless integration with \code{PostgreSQL}.
\code{Grafana} provides good separation of concerns and compartmentalization as it does not store the displayed metrics itself.
Instead, it queries the \code{PostgreSQL} database in real-time~\cite{Wikipedia:article/Grafana}, unlike \eg \code{InfluxDB}.
Good alternatives to \code{Grafana} are \code{Kibana}~\cite{Wikipedia:article/Kibana}, \code{Prometheus}~\cite{Wikipedia:article/Prometheus}, and \code{Graphite}~\cite{Wikipedia:article/Graphite}.
\code{Kafka}, particularly \code{Kafka} developed by Confluent~\cite{Wikipedia:article/Confluent} is a battle-tested message broker that provides versatile capabilities to transfer huge volumes of data with little latency, in real-time.
We decided to use \code{Confluent Kafka} instead of \code{Kafka} developed by the Apache Foundation, because of it's masterful connector system allowing to easily add sources and sinks (\eg \code{PostgreSQL} sink, \code{Redis} sink, \code{OpenDC} source).
Additionally, as opposed to \code{Apache Kafka}, \code{Confluent Kafka} comes equipped with a \code{Schema Registry}.
The \code{Schema Registry} is a important component that allows the storage of database and cache schemas for easy retrieval.
With \code{Schema Registry}, we ensure that the data stored in \code{PostgreSQL} tables and in \code{Redis} streams contains the exact same schema.
Moreover, \code{Schema Registry} is compatible with versatile data interchange formats, such as \code{ProtoBuf}~\cite{Wikipedia:article/ProtoBuf}.
\code{Redis}, is a key value store that provides efficient store and retrieval operations~\cite{Wikipedia:article/Redis}.
In particular, \code{Redis} is capable of storing \emph{streams} -- append only logs which allow for fast and quick query of large volumes of data.
\code{Redis} is the industry leader in key value caching.
The only alternative to \code{Redis} is \code{memcached}~\cite{Wikipedia:article/Memcached}, which does not provide the capability to integrate with \code{Kafka}.
\code{PostgreSQL} is a database management system, necessary to store large volumes of out-of-band data coming from the physical datacenter.
The \code{PostgreSQL} server provides a simple and straightforward interface to query the data via \code{psql}.
Importantly, to adhere to the single responsibility principle, \code{PostgreSQL} does not provide any \gls{ui}.
Additionally, there exist many integrations between \code{PostgreSQL} and other software, including \code{Kafka}.
The many alternatives to \code{PostgreSQL} are listed in~\cite{Wikipedia:article/Postgresql}.
An alternative used in previous work is \code{InfluxDB}~\cite{DBLP:conf/wosp/SumanCNTMI24}.
Lastly, to enable predictive analytics we use a state-of-the-art discrete-event simulator, \code{OpenDC}~\cite{GitHub:software/OpenDC}.
\code{OpenDC} is a leading software package capable of modeling complex datacenter phenomena and workloads (\eg failures, workflows, machine learning).
For a specific overview of advantages of \code{OpenDC} and a thorough comparison with other alternatives, see \Cref{tab:datacenter_simulator_comparison}.
\begin{figure}[t]
\centering
\includegraphics[width=\linewidth]{images/flow_diagram.png}
\caption{The data flow within \gls{my_system}.}
\label{fig:flow_diagram}
\end{figure}
\section{Data Flow}\label{ss:data_flow}
\input{sources/listing_sinks.tex}
\ipsum[1-4]
\begin{figure}[t]
\input{sources/listing_schema.tex}
\end{figure}
\section{Programming Effort}\label{ss:programming}
|
