Page tree
Skip to end of metadata
Go to start of metadata

Der Systemaufbau von YUNA kann auf unterschiedliche Arten erfolgen. Grundsätzlich sind zwei Komponenten notwendig, um eine Minimal-Instanz von YUNA zu betreiben:

Minimales System

Um im Portal Daten anzeigen zu lassen, diese zu filtern und zu durchsuchen und diese Daten in Diagrammen anzeigen zu lassen (sog. Ad-hoc-Analysen) ist lediglich ein minimaler Systemumfang notwendig: 

  • Ein Portal-Server (zum Betrieb des OSGI-basierten Portals)
  • 1 Datenbank (für PortalDB und DataDB)

Die PortalDB sollte in der gleichen Datenbank liegen wie die DataDB

Mit diesem Minimal-Setting können jedoch keine tiefgreifenden Analysen im Zuge von Sachverhalten und Jobs durchgeführt werden. Sofern dies gewünscht ist, muss eine zusätzliche Analyse-Ausführung hinzugefügt werden, wie im folgenden Abschnitt beschrieben.


Standard-Systemaufbau

Im Normalfall sollen mit YUNA Daten nicht nur "durchgeklickt" werden. Möchten Ihre Anwender Analysen durchführen, um sich beispielsweise vorhersagen zu lassen, zu welchen Zeitpunkten Servicetechniker zu einer bestimmten Anlage geschickt werden sollten, so ist neben dem Minimalsystem die Hinzunahme einer Ausführungsschicht für Analysen notwendig. Dies ist im aktuellen Fall ein R-Serve. Der normale Systemaufbau sieht also folgendermaßen aus:

  • Ein YUNA-Server (zum Betrieb des OSGI-basierten Portals)
  • 1 Datenbank (für PortalDB und DataDB)
  • 1 Server für R-Agenten (Plattform zur Ausführung der R-Analysen)

Zusammenspiel der Systemkomponenten

Dieser Systemaufbau lässt sich auf unterschiedliche Art und Weise bewerkstelligen:

Verteiltes System

Bei dieser Form der Systemkonfiguration stehen jeder der Komponenten eigene Hardwareressourcen zur Verfügung. D.h., sowohl der YUNA-Server, der R-Agent als auch die Datenbank können auf eigene Prozessoren und Verarbeitungskapazitäten mit jeweils dediziertem RAM zurückgreifen.

Geteilter Server

In diesem Fall teilen sich YUNA und der R-Agent eine Ressource und damit die gemeinsame Rechenleistung der CPU und den Arbeitsspeicher des Servers (egal ob physischer oder virtueller Server). Im unten gezeigten Bild liegt die Datenbank außerhalb des gemeinsam genutzten Systems. Rein theoretisch ist es jedoch auch möglich, alle Systemkomponenten auf einem gemeinsamen Server/System zu betreiben.


Die Agenten Installation sollte getrennt von der YUNA-Installation auf einer extra physischen oder virtuellen Maschine erfolgen (Beispiel verteiltes System). Ausschlaggebender Grund hierfür ist, dass die Agenten bzw die Skript-Sprachen dazu tendiert, so viel Arbeitsspeicher wie möglich für sich zu reservieren, weshalb umfangreiche Analysen dazu führen könnten, dass beispielsweise R den RAM eines gemeinsam genutzten Servers ausreizt und somit das Portal blockiert.


Betrieb mehrerer Instanzen

Es ist möglich - und in einigen Fällen auch sinnvoll - neben der produktiven Instanz weitere Instanzen zu betreiben. So werden aktuell in einigen Fällen neben der Produktivinstanz auch eine Testinstanz und eine Entwicklungsinstanz betrieben.

Entwicklungsinstanz

Auf der Entwicklungsinstanz können neue Portal-Funktionen anhand von Beispiel-Inhalt getestet werden, ohne dass die Produktiv-Instanz und somit der aktive Betrieb des Systems für die eigentlichen Anwender beeinträchtigt werden. Hier geht es jedoch um reine Funktionstests, um frühzeitig Bugs aufzudecken und den grundlegenden Funktionsumfang zu testen. Sobald neue Funktionen dort ausreichend getestet und abgenommen wurden, können sie auf die Testinstanz verschoben werden.

Testinstanz

Getestete neue Portalfunktionen werden auf der Testinstanz mit einer Kopie der Datensätze der Produktivinstanz verknüpft. Wird beispielsweise durch eine Funktionserweiterung oder Änderung am Code eine Anpassung am Inhalt des Dashboards notwendig, so können Ihre Dashboard Entwickler auf der Testinstanz ihre Änderungen zunächst entwickeln und testen. Alternativ können ihre Dashboard Entwickler jedoch auch die Referenz-Tag-Funktion des Portals nutzen, um ihre Anpassungen unter einem Test-Referenz-Tag zu testen.

Auch neue Analyseskripte können auf der Testinstanz zunächst getestet werden, bevor sie auf der Produktivinstanz live gehen.

Produktivinstanz

Dies ist die eigentlich gegnutzte Instanz ihres YUNA Portals. Auf ihr arbeiten ihre Fachanwender und Data Scientists. 

  • No labels