diff --git a/Praxisbericht.tex b/Praxisbericht.tex
index 0c935e1..7bd629e 100644
--- a/Praxisbericht.tex
+++ b/Praxisbericht.tex
@@ -218,9 +218,9 @@ Mithilfe der beiden Pipelines kann FluxCD einen massiven Teil des Deployments au
 
 \subsection{High Availability, Longhorn und CloudNativePG}
 
-Viele der Kunden sind an zunehmend an Ausfallsicherheit interessiert. Sofern eine Distribution ein High-Availability Control-Plane zur Verfügung stellt, ist dies für das Cluster realisierbar. Für einfache stateless Workloads, also Software die keine Daten zwischenspeichern muss, ist die Realisierung trivial: sie muss auf mehrere Nodes verteilt werden, und im Falle eines Ausfalls realisiert Kubernetes durch Health-Checks dass der Workload nichtmehr Aufnahmefähig ist und verschiebt die Anfragen. Bei Stateful Workloads wie Datenbanken ist der Prozess komplexer. Da bei einem Ausfall des Workloads oder der Node die an den Workload gebundenen Daten nichtmehr aufrufbar sind dürfen die Daten nicht nur an einem lokalen Punkt gespeichert werden. Dafür existieren Distributed Storage Provider. Ein Distributed Storage Provider kümmert sich um die Duplizierung von Daten innerhalb eines Clusters nach vorgeschriebenen Regeln, Realisiert in \texttt{StorageClass}-Objekten. Longhorn ist solch ein beliebter und einfach zu bedienender Distributed-Storage Provider, welcher die Replikation der Daten auf Clusterebene übernimmt, damit bei einem Ausfall von einer Node der Workload trotzdem mit minimalen bis keinem Datenverlust auf eine andere Node übergeben werden kann. Alternativ dazu gibt es auch Workloads, welche von sich aus die Replikation übernehmen können. Diese sind dem vorherigen darin Überlegen, dass die Software die Datenreplikation besser steuern kann, wodurch die Wahrscheinlichkeit für invalide Daten sinkt. Dazu gehört auch PostgreSQL, die Datenbank welche psb-intern genutzt wird. Da das Replizieren über Primary \& Secondary Datenbanken übernommen wird welche manuell zugewiesen werden müssen, bietet es sich an die Provision dieser von einem Operator zu übernehmen. CloudNativePG (kurz CNPG), ist ein Kubernetes-Operator, welcher die Provision von High-Availability Postgres-Datenbanken mit Failover bei Ausfall übernehmen kann, und somit perfekt geeignet ist. CNPG selbst braucht dabei keinen Distributed Storage da es durch die Anwendungsinterne Replikationslogik den Speicher verteilt.
+Viele der Kunden sind an zunehmend an Ausfallsicherheit interessiert. Sofern eine Distribution ein High-Availability Control-Plane zur Verfügung stellt, ist dies für das Cluster realisierbar. Für \textit{Stateless Workloads}, also Software die keine Daten zwischenspeichert, ist die Realisierung trivial: die Container müssen auf mehrere Nodes verteilt werden, und im Falle eines Ausfalls realisiert Kubernetes durch Health-Checks dass der Workload nichtmehr Aufnahmefähig ist und verschiebt die Anfragen. Bei \textit{Stateful Workloads} wie Datenbanken ist der Prozess komplexer. Da bei einem Ausfall des Workloads oder der Node die an den Workload gebundenen Daten nichtmehr aufrufbar sind dürfen die Daten nicht nur an einem lokalen Punkt gespeichert werden. Dafür existieren \textit{Distributed Storage Provider}. Ein Distributed Storage Provider kümmert sich um die Replizierung von Daten innerhalb eines Clusters nach vorgeschriebenen Regeln, Dokumentiert in \texttt{StorageClass}-Komponenten. \textit{Longhorn} ist ein einfach zu bedienender Distributed-Storage Provider, welcher die Replikation der Daten auf Clusterebene übernimmt, damit bei einem Ausfall von einer Node der Workload trotzdem mit minimalen bis keinem Datenverlust auf eine andere Node übergeben werden kann. Alternativ dazu gibt es auch Workloads, welche von sich aus die Replikation übernehmen können. Diese sind dem vorherigen darin Überlegen, dass die Software die Datenreplikation besser steuern kann, wodurch die Wahrscheinlichkeit für invalide Daten sinkt. Dazu gehört auch \textit{PostgreSQL}, die Datenbank welche psb-intern genutzt wird. Da das Replizieren über Primary \& Secondary Datenbanken übernommen wird welche manuell zugewiesen werden müssen, bietet es sich an die Provision dieser von einem Operator zu übernehmen. \textit{CloudNativePG} (kurz CNPG), ist ein Kubernetes-Operator, welcher die Provision von High-Availability Postgres-Datenbanken mit Failover bei Ausfall übernehmen kann, und somit perfekt geeignet ist. CNPG selbst braucht dabei keinen Distributed Storage, da es durch die Anwendungsinterne Replikationslogik den Speicher zwischen Pods verteilt.
 
-Mit der Kombination aus Longhorn und CNPG können somit Stateful Workloads Highly-Available gemacht werden, um Ausfälle der Produktion zu vermeiden.
+Mit der Kombination aus Longhorn und CNPG können somit alle Stateful Workloads von selektron Highly-Available gemacht werden, um Ausfälle der Produktion zu vermeiden.
 
 
 \subsection{Airgap-Installation}