Verwaltung der Architektur

Wesentliche Eigenschaften der Innovator-Architektur bestimmen Sie bei der Installation, wodurch bestimmte Umgebungsvariablen festgelegt werden.

Angaben zur Architektur

Die potentiell sehr komplexe Architektur von Innovator macht ein Minimum von Angaben erforderlich, die die jeweilige Struktur abbilden. Diese Angaben müssen bei der Installation gemacht werden. Sie können jedoch später problemlos im Administrationsprogramm verändert werden.

Zur Speicherung dieser Angaben werden auf den unterschiedlichen Betriebssystemen spezifische Techniken eingesetzt.

  • Unter Microsoft Windows werden die Einstellungen in der Registrierung abgelegt.
  • Unter Linux sind Umgebungsvariablen mit den jeweiligen Angaben zu belegen.

Im Folgenden wird in diesem Zusammenhang allgemein von Umgebungsvariablen gesprochen.

Die unbedingt notwendigen Angaben betreffen die folgenden Fragen.

Auf welchem Rechner soll der Hauptlizenzserver laufen?

Diese Angabe ist von entscheidender Bedeutung für den Betrieb von Innovator. Aufgrund der zentralen Stellung des Hauptlizenzservers für die Innovator-Architektur muss er von jedem Rechner aus, auf dem mit Innovator-Programmen gearbeitet werden soll, über das Netzwerk erreichbar sein.

Der Rechner, auf dem der Hauptlizenzserver laufen soll, sollte bereits bei der Installation festgelegt werden. Zwar kann auch diese Angabe geändert werden, es muss in diesem Fall aber eine erneute Freischaltung der Lizenzen für die Innovator-Produkte durch die MID GmbH durchgeführt werden.

Soll die Installation für den aktuellen oder alle Benutzer erfolgen?

Diese Angabe entscheidet darüber, in welchem Startmenü-Verzeichnis die Programmgruppe und wo die Einträge zu Innovator in der Registrierung abgelegt werden.

Ausschließlich dann, wenn die Einträge auf dem lokalen Rechner für alle Benutzer erfolgen, können die Innovator-Server als Dienste eingerichtet werden.

Wo sollen Programme, Einstellungen und Repositorys liegen?

Die Angabe des Installationsverzeichnisses bestimmt, wo die ausführbaren Programme, die gemeinsamen Daten und die Einstellungen zur Verfügung stehen werden. Die Einstellungen umfassen die Verzeichnisse für Repositorys und Parameterdateien. Diese Verzeichnisse können Sie nach der Installation im Administrationsprogramm ändern. Bei der Arbeit mit Netzwerklaufwerken ist dies oft notwendig.

Hinweis

Bei der Benutzung sogenannter Dienste (Services) unter MS Windows dürfen Projektverzeichnisse mit den Repositorys nicht auf Netzwerklaufwerken liegen.

Server und Portbereiche

Der Modellserver meldet sich regelmäßig beim Lizenzserver zurück. Allerdings kann auch der Lizenzserver eine Verbindung zum Modellserver aufbauen, um festzustellen, ob dieser noch läuft.

Für die Kommunikation zwischen den Modellservern und den Clients kann ausgehend von der bei der Installation festgelegten Portnummer des Lizenzservers entsprechend der Anzahl der maximal laufenden weiteren Komponenten und Modellserver der Portbereich bestimmt werden. Für die Modellserver eines Rechners kann die Portanzahl durch einen Innovator-Proxy minimiert werden.

Hinweis

Die Portnummer des Lizenzservers muss zwischen 1024 und 64000 liegen.

Der Lizenzserver (Port p), die von ihm benötigten Komponenten Bus und Hub (Ports p+1, p+2), ggf. der Agent für verwaltete Modelle (standardmäßig p+3), der Benachrichtigungsservice (p+4) und der Innovator-Proxy (p+5) benötigen jeweils einen Port. Modellserver versuchen, sich an den nächstfolgenden freien Port zu binden. Ist der nächste Port bereits belegt, wird solange der nächste geprüft, bis ein freier gefunden wird.

Eine gesicherte Verbindung (Firewall) muss auf den Ports aufsteigend vom Port p des Lizenzservers bis p+5 und anschließend für die maximal erwarteten Modellserver und deren Kommunikation mit den Clients (p+5+max) alle Pakete passieren lassen.

Für jeden Modellserver kann eine bestimmte Portnummer für die Öffnung der Verbindungen festgelegt werden.

Falls Sie als Betriebssystem Linux verwenden und häufiger Modellserver herunter- und herauffahren, sollten Sie zur Sicherheit noch ein paar weitere Ports belegen, da Linux die Ports erst nach einer von den Linux-Administratoren festgelegten Zeit freigibt (bis zu 30 Minuten).

Portbereiche für Hauptlizenzserver und Projektlizenzserver

Wenn Sie Projekte in verschiedenen Innovator-Versionen verwalten müssen, dann verwenden Sie stets einen Projektlizenzserver für jede Innovator-Version (##.#). Ein Effekt besteht darin, dass Sie für diese Projektlizenzserver die Portzuordnung und die darauf basierenden Dienste bei einem Upgrade (Versionswechsel) nicht ändern müssen. Ebenso bleibt der Port des Hauptlizenzservers unverändert. Lediglich der neue Projektlizenzserver der jeweils neuen Innovator-Version benötigt dann eine Festlegung seiner Ports.

Kommunikation zwischen Server und Client

Innovator benötigt Warteschlangen (Message Queues) zur Kommunikation zwischen Server und Client (wie z.B. auch Oracle und MySQL).

Die Voreinstellung mancher Betriebssysteme für die Warteschlangen ist zu gering, vor allem, wenn viele Clients arbeiten. Dadurch kann es zur Meldung "Erstellen der Nachrichtenwarteschlange nicht möglich" kommen.

Wir empfehlen, den Wert für die Warteschlangen zumindest auf 256 zu erhöhen.

Unter Linux können Sie den aktuellen Wert mit dem Befehl ipcs -ql prüfen.

Tragen Sie die Anzahl der verfügbaren Warteschlangen in der Datei /etc/sysctl.conf ein:

kernel.msgmni = 256

Der neue Wert wird spätestens beim Neustart übernommen oder sofort durch Eingabe von sysctl -p an der Konsole.

Nach einer gewissen Zeit sollten Sie mit dem Befehl ipcs -q prüfen, wie viele Warteschlangen im laufenden Betrieb (durch Innovator oder auch Datenbanken) benutzt werden. Passen Sie den Wert so an, dass er ausreichende Reserven bietet.

Da ipc die Warteschlangen unvorhergesehen beendeter Prozesse nicht bereinigt, muss ggf. mit ipc-Befehlen eingegriffen werden, um die Warteschlangen wieder nutzen zu können.

Szenarien für Agenten, Lizenzserver und Projektverzeichnisse

Sinnvolle Szenarien

  • Gemeinsamer (Projekt-)Lizenzserver und gemeinsames Projektverzeichnis

    Mehrere Agenten werden auf verschiedenen Rechnern mit gemeinsamem Lizenzserver und gemeinsamem Projektverzeichnis betrieben.

    Um die Last zu verteilen, können die Modellversionen (Modellserver) auf unterschiedlichen Rechnern starten.

    Alle Agenten (z.B. in der physischen Ansicht) zeigen alle Modellversionen an. Es ist ersichtlich, wo sie laufen.

  • Gemeinsamer (Projekt-)Lizenzserver und separate Projektverzeichnisse

    Mehrere Agenten werden auf verschiedenen Rechnern mit gemeinsamem Lizenzserver und getrennten Projektverzeichnissen betrieben.

    Mit dieser Variante können die Repositorys physisch auf unterschiedlichen Festplatten liegen, wenn z.B. der Plattenplatz nicht ausreicht.

    Die Agenten bieten unterschiedliche Modellversionen an. Es ist ersichtlich, wo sie laufen.

Problematische Szenarien

  • Agenten mit unterschiedlichen (Projekt-)Lizenzservern und gemeinsamem Projektverzeichnis

    Mehrere Agenten werden mit unterschiedlichen (Projekt-)Lizenzservern der gleichen Version, aber mit gemeinsamem Projektverzeichnis betrieben.

    Für die Modellversionen ist dann nicht entscheidbar, welcher Agent zuständig ist.

    Das Anlegen von Modellversionen kann unmöglich sein oder zu falschen Zuordnungen führen.

  • Agenten und Modellserver mit unterschiedlichen (Projekt-)Lizenzservern und gemeinsamem Projektverzeichnis

    Agent und Modellserver werden mit unterschiedlichen (Projekt-)Lizenzservern der gleichen Version, aber mit gemeinsamem Projektverzeichnis betrieben.

    Agent und Modellserver fahren mit unterschiedlichen Bussen und begegnen sich dabei nicht.

    Zustände von Modellversionen können nicht eindeutig erkannt werden. Dadurch sind Fehlentscheidungen möglich.

  • Linux- und Windows-Agenten mit gemeinsamem Projektverzeichnis

    Die korrekte Vergabe der Berechtigungen auf einem gemeinsamen INOPRJ-Verzeichnis ist problematisch, wenn ein Agent auf einem Windows-System und der andere auf einem Linux-System läuft. Beide Benutzer benötigen Lese- und Schreibrechte für das Modellverzeichnis und seinen Inhalt.

    Speziell betrifft dies:

    • die Datei xxx.inoprj.uuid

      Die beiden Agenten finden nicht heraus, dass sie auf demselben INOPRJ-Verzeichnis arbeiten, wenn Windows diese Datei nicht lesen kann.

    • das Verzeichnis ivm

      Der Windows-Agent kann keine Logs schreiben, wenn dieses Verzeichnis für Windows nicht schreibbar ist. Eine Modellversion, die vom Linux-Agenten erstellt wurde, kann vom Windows-Agenten nicht gestartet werden, wenn die Unterverzeichnisse und Repositorydateien für den Windows-Agent nicht lesbar bzw. schreibbar sind.