Staging environment

kapitel5.tex

@@ -9,8 +9,57 @@
 
 \section{Planung} %TODO RNDSUP-423
 
+Um die Prozesse der \ac{RND} Abteilung einzuhalten, musste vor der Umsetzung eine Planung erstellt werden.
+Dies dient dazu, eine chaotische unstrukturierte Umsetzung zu vermeiden und somit sowohl Zeit zu sparen, als auch ein besseres Resultat zu erhalten.
+Des Weiteren kann durch eine gute Planung, weiteres Feedback von Kollegen eingeholt werden, welche oftmals mit einer anderen Perspektive neue Erkenntnisse und Ideen einbringen können.
+Somit kann vermieden werden, dass die Umsetzung mittendrin unterbrochen wird, da Komponenten noch nicht bereit sind, oder konkrete Einzelheiten noch ungeklärt sind.
+
+Im Route Injection Projekt musste hier spezielle noch geklärt werden, wie die \ac{BGP}-Sessions konfiguriert werden und welcher Router sich hierfür eignen würde.
+
+\newpage
+
+Das folgende Diagramm stellt die Struktur und Verbindungen der verschiedenen Komponenten dar.
+
+\begin{figure}[H]
+    \centering
+    \fbox{\includegraphics[width=\textwidth]{images/staging_architecture}}
+    \caption{\label{fig:staging-architecture}Route Injection Staging Architektur}
+    \centering{Quelle: Firmenintern}
+\end{figure}
+
+Die \ac{API}, der Injector und Bird sind hierbei direkte Komponenten des Route Injection Service.
+Zu Testzwecken und um Resourcen zu sparen, wird die \ac{API} auf derselben Maschine wie Consul betrieben.
+Da dies jedoch eine starke Abweichung von der Produktivumgebung ist, sollte dies nur als provisorische Zwischenlösung angesehen werden.
+Der Injector und Bird werden ebenfalls auf derselben Maschine betrieben, dies ist jedoch so beabsichtigt und wird auch in der Produktivumgebung so umgesetzt werden.
+Durch die \textcolor{blue}{blaue} Markierung soll symbolisiert werden, dass die sich darin befindlichen Komponenten innerhalb desselben Netzwerks betrieben werden.
+Das `Test System 01` befindet sich in einem eigenen, \textcolor{orange}{orange} markierten Netzwerk, um vom Route Injection Service getrennt werden.
+
+Des Weiteren wurde festgelegt wie der Route Injection Service überwacht werden soll.
+Eine gute Überwachung (Monitoring) kann viele Vorteile, wie zum Beispiel das frühe Erkennen von einer Überlast oder der Erkennung, dass ein Teil des Service nicht mehr erreichbar sein sollte.
+Daher wurden folgende Richtwerte für die \acp{VM} festgelegt.
+
+\begin{itemize}
+    \item Die Arbeitsspeicherauslastung darf 25\% freien Speicher nicht unterschreiten
+    \item Die Festplattenspeicherauslastung darf 20\% freien Speicher nicht unterschreiten
+    \item Die CPU Auslastung dark 80\% nicht überschreiten
+    \item Die \ac{BGP} Sessions müssen etabliert sein
+\end{itemize}
+
+Um die Kommunikation zwischen den einzelnen Komponenten sicherstellen zu können, wird hierfür ebenfalls ein Monitoring eingerichtet.
+Hier soll die \ac{API} über einen `Healthcheck` Endpunkt erweitert werden, welcher den \ac{HTTP} Statuscode 200 zurückgibt und damit signalisiert, dass die \ac{API} erreichbar ist.
+Um die Kommunikation zwischen der \ac{API} und Consul zu überprüfen, kann diese Testweise einen Wert in Consul anlegen und versuchen diesen zu lesen.
+Der Injector gibt seinen Zustand schon über seinen Heartbeat an Consul zurück.
+Dieser könnte zwecks Monitoring ebenfalls von der \ac{API} ausgelesen und überwacht werden.
+
 \section{Umsetzung}
 
+Der wichtigste und erste Punkt in der Umsetzung war das Anlegen der \acp{VM}.
+Zum provisionieren der Systeme, wird Ansible verwendet.
+Ansible ermöglicht es, viele Systeme automatisiert konfigurieren zu können, ohne dies händisch machen zu müssen.
+Während eine händische Konfiguration im kleinen Rahmen der Staging Umgebung zwar technisch möglich wäre, wäre dies in der Produktivumgebung, wo es viele Injectoren geben wird, nicht mehr ohne hohen Zeitaufwand möglich.
+Der zweite große Vorteil von Ansible ist, dass die Konfiguration leicht nachvollziehbar und versionierbar ist.
+Somit können Konfigurationsänderungen leicht wieder zurückgespielt werden.
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \endinput
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%