Nosa Import Management
Der NOSA Import wurde vollständig neu entwickelt und löst das alte Nosa-Import-System aus dem MIKU System ab.
Neue Features
Zu den neuen Features gehören:
- Vollständige Redundanz in einem Multi-Node System
- Flexible Konfiguration
- Konfigurationsfrontend
- Detaillierteres Logging
- Unabhängiger Download und Import
- Verteilung der Daten im Multi-Node System
- Multi-Node Service System
- Berechtigungssystem (Ändern, Hinzufügen, Aktivieren, Username/Password anzeige)
Funktionsweise
Es gibt drei getrennte Konfigurationsblöcke. Die Quellen, die Proxies und die Targets. Die drei Konfigurationen werden dann mittels einer Reihenfolge den Nodes zugeordnet, die man dann Work Packages nennt.
Alle vier Teile lassen sich entsprechend aktivieren, bzw. kurzfristig deaktivieren.
Das Processing wird von zwei Services übernommen.
Konfiguration
Quellen
Eine Quelle ist ein Nokia-SAM oder ein NFM-P Server. Man gibt dort die IP oder den Hostnamen an, das Protokoll und die Authentifikation. Aktuell wird in der Authentifikation nur der Security-Block im XML unterstützt.
man kann mehrere Quellen angeben, die werden dann nach ein ander durchprobiert. Das ist auch hilfreich, wenn spezielle Nodes nur spezielle Quellen verwenden sollten
Proxies
Wenn zu einer Quelle ein Proxy dazwischen geschaltet werden soll, oder muss. Man kann hier eine Liste der Proxies erstellt, die man dann in dem Work-Package mit angeben kann. Man kann sogar das gleiche Work-Package erstellen, einmal mit Proxy und einmal ohne, oder mehrere Proxies. Damit kann man die Redundanz erhöhen
Targets
Die Targets sind aus Sicht der Nokia-SAM bzw. NFM-P System das Zielsystem um die Daten abzulegen. Aktuell wird nur die SFTP Methode unterstützt. Das Herunterladen der XML-Daten während der Anfrage funktioniert bei großen Netzen nicht zuverlässig. Wichtig ist das hier die Ziel-IP / Hostname eingegeben werden muss aus der Sicht der anderen Systeme. Das kann das gleiche System sein, welches die Anfrage startet, muss aber nicht. Man kann zum Beispiel eine Zentrale Ablage erstellen, oder die Arbeiten aufteilen. Das wird dann via Work-Package definiert.
Work-Packages
Hier werden die drei Teile miteinander verbunden.
Jede Stunde wird auf einem Node der prozess gestartet. Diese schaut in die Work-Packages und arbeitet diese ab. Wenn der Prozess bei dem ersten Work-Package erfolgreich war, wird der Prozess beendet. Gab es allerdings beim ersten Work-Package ein Problem, z.B. Proxy antwortet nicht, SAM nicht erreichbar, oder andere Probleme, wird das nächste Work-Package in der Liste ausgeführt. Schlagen alle Work-Packages fehl, gibt es auch keine Daten zum Importieren.
Hier ein Beispiel für den Node 1, der mit drei verschiedenen SAM/Proxy kombinationen konfiguriert wurde. Wenn der erste funktioniert hat, dann wird der Prozess erfolgreich beendet, die anderen werden ja nur dann abgearbeitet, wenn es geknallt hat.
Wartungsarbeiten
Wenn es Wartungsarbeiten gibt, zum Beispiel an einer Quelle, oder einem proxy, oder an einem Target, dann kann man dieses Element deaktivieren. Es werden dabei automatisch alle Work-Packages übersprungen, wo das deaktivierte Element zu finden ist.
Man kann also z.B. sagen: Deaktiviere die Quelle in Nürnberg. Alle betroffenen Work-Packages werden dann übersprungen.
Mann muss dabei aber vorsichtig sein, wenn ein Node nur diese eine Quelle in Nürnberg in seinem Work-Package hat, wird der Node keine Aktionen starten, wenn er an der Reihe ist. Das sollte bedacht werden.
Prozess
Der ganze Prozess wird von zwei Services gesteuert. Ein Service ist für das Holen der Daten verantwortlich, der andere Service ist für den Import der Daten verantwortlich.
Die Trennung ist nötig, weil ja auch ein fremder Node die Daten holen könnte, und sie auf ein anderen Node ablegt. Oder man benutzt einen sogenannten zentralen Topf, wo alle Daten angeliefert werden. Durch die Trennung sind diese Möglichkeiten gegeben.
nosaDownload Service
Dieser Service sendet den Nokia SAM entsprechende Anweisungen, um die Daten zu holen. Der Service kümmert sich ausschließlich um die Kommunikation zum SAM. Ob Daten kommen, oder ob sie korrekt sind, ist dem Service relativ egal. Wenn ein Remote-Target angegeben wurde, könnte der Service den Zustand der Daten nicht prüfen, aus diesem Grunde prüft er das auch generell nicht.
nosaImport Service
Dieser Service scannt die in den Targets abgelegten lokalen Verzeichnisse nach den Daten. Dabei prüft er unter anderem auch, ob die Daten schon vollständig sind. In Falle eines Remote Target, wüsste der Importer nicht, wann der Download fertig wäre. Von daher schaut der Service in die Datei hinein. Passt der Typ und die Datei, wird ein Importer gestartet der die Daten vom SAM kreuz-vergleicht und die statistischen Daten einpflegt.