You can specify important Innovator architecture properties upon installation which set certain environment variables.
Architecture Specifications
The potentially complex architecture of Innovator means that a small amount of input is required to define individual structures. This input needs to be carried out upon installation. However, this can also be easily changed in the Administration Program at a later stage.
Different operating systems use specific techniques for storing these settings.
- The registration settings are stored in the registry under Microsoft Windows.
- Environment variables must be assigned with the individual settings under Linux.
The following talks about environment variables in general.
Some settings, pertaining to the following questions, are absolutely necessary:
Which computer will the main license server run on?
This setting is of critical importance for operating Innovator. Due to its central position in the Innovator architecture, the main license server must be accessible from every computer that will run Innovator programs.
The computer that will run the main license server must be determined during installation. Although it is possible to change it at a later date, this would require all Innovator licenses to be activated by MID GmbH again.
Should the installation be carried out for the current user or for all users?
This specification determines which start menu directory the program group will be stored in and where the Innovator entries will be stored in the registration.
The Innovator server can only be set as services if the entries are made for all users on the local computer.
Where should programs, settings and repositories be located?
Specifying installation directories determines where the executable programs, common data and settings will be available. The settings contain the directories for repositories and parameter files. These directories can be modified in the Administration Program once the installation has taken place. This is often required if you work with network drives.
Server and Port Ranges
The model server regularly contacts the license server. However, the license server may also call the model server to determine whether it is still running.
For communication between model servers and clients, the range of port numbers can be derived from the license server's port number specified upon installation and according to the maximum amount of concurrently running components and model servers.
Note
The license server's port number must be a value between 1024 and 64000
The license server (port p), the bus and hub components (ports p+1, p+2) it requires, the possible agent for managed models (default p+3) and the notification service (p+4) each require one port. Model servers attempt to connect to the next free port. If the next port is already assigned, the next consecutive one is checked until a free port is found.
A secure connection (firewall) must allow all packages, starting from port p of the license server to p+4 and then for the maximum number of expected model servers and their communication with clients (p+4+max).
A certain port number can be set for each model server for opening the connection.
If you use Linux as your operating system and frequently start up and shut down model servers, you should use a few other ports. This should be done for security reasons, since Linux only releases ports after a time specified by the Linux administrators (up to 30 minutes).
Port Range for Main License Servers and Project License Servers
If you need to manage projects in different Innovator versions, always use one project license server for each Innovator version (##.#). One effect of this is that you do not need to change the port assignment and services based upon this for these project license servers in the case of an upgrade (version change). Furthermore, the port of the main license server remains unchanged. Only the new project license server of the new Innovator version then requires a port definition.
Communication between Server and Client
Innovator requires Message Queues for communication between the Server and the Client (e.g. Oracle and MySQL).
The default on most operating systems is too low for message queues, particularly when a lot of clients are using it. If this is the case, an error message "cannot create message queue" often appears.
We recommend increasing the value of the message queue to at least 256.
You can verify the current value with the command ipcs -ql when using Linux.
Input the number of available message queues in the /etc/sysctl.conf file:
kernel.msgmni = 256
The new value will be adopted upon reboot or directly by inputting sysctl -p in the console.
The amount of message queues being used in the current system should be verified after a certain amount of time using the ipcs -q command (in Innovator or databases). Adjust the value in such a way that it offers adequate reserves.
ipc does not alter the message queues of processes which have been unexpectedly ended. If necessary, these can be engaged with the ipc command so that the message queues can be used again.
Scenarios for Agents, License Server and Project Directory
Useful Scenarios
-
Common (project) license server and common project directory
Multiple agents run on various computers with common license server and common project directory.
Model versions (model server) can be started on various computers to spread the load.
All agents (e.g. in the physical view) show all model versions. It is clear where they are running.
-
Common (project) license server and separate project directory
Multiple agents run on various computers with common license server and separate project directories.
Repositories can physically be on various hard drives if e.g. there is not sufficient disk space.
Agents provide different model versions. It is clear where they are running.
Problematic Scenarios
-
Agents with different (project) license license servers and common project directory
Multiple agents are running with different (project) license servers of the same version but with a common project directory.
You cannot determine which agent is responsible for the model versions.
You cannot create model versions or these are misassigned.
-
Agents and model servers with different (project) license servers and common project directory
Agent and model server are running with different (project) license servers of the same version but with a common project directory.
Agent and model server are run on different buses and do not come into contact with one another.
Model version states cannot be identified as unique. This may lead to mistakes being made.
-
Linux and Windows Agents with a Common Project Directory
Correct rights assignment on a common INOPRJ directory is problematic if one agent is running on a Windows system and the other is running on a Linux system. Both users require read and write rights for the model directory and its content.
This specifically concerns:
-
The xxx.inoprj.uuid file
Both agents do not determine that they are working on the same INOPRJ directory if Windows cannot read this file.
-
The ivm directory
The Windows agent cannot write logs if this directory is not writable for Windows. A model version created by Linux agents cannot be started by Windows agents if the subdirectories and repository files cannot be read and written by the Windows agent.
-
Related Topics
