Infor ION Grid Administration Guide

Infor ION Grid Administration Guide
Release 12.0.2.0
Copyright © 2022 Infor
Important Notices
The material contained in this publication (including any supplementary information) constitutes and
contains confidential and proprietary information of Infor.
By gaining access to the attached, you acknowledge and agree that the material (including any
modification, translation or adaptation of the material) and all copyright, trade secrets and all other
right, title and interest therein, are the sole property of Infor and that you shall not gain right, title or
interest in the material (including any modification, translation or adaptation of the material) by virtue
of your review thereof other than the non-exclusive right to use the material solely in connection with
and the furtherance of your license and use of software made available to your company from Infor
pursuant to a separate agreement, the terms of which separate agreement shall govern your use of
this material and all supplemental related materials ("Purpose").
In addition, by accessing the enclosed material, you acknowledge and agree that you are required to
maintain such material in strict confidence and that your use of such material is limited to the Purpose
described above. Although Infor has taken due care to ensure that the material included in this publication
is accurate and complete, Infor cannot warrant that the information contained in this publication is
complete, does not contain typographical or other errors, or will meet your specific requirements. As
such, Infor does not assume and hereby disclaims all liability, consequential or otherwise, for any loss
or damage to any person or entity which is caused by or relates to errors or omissions in this publication
(including any supplementary information), whether such errors or omissions result from negligence,
accident or any other cause.
Without limitation, U.S. export control laws and other applicable export and import laws govern your
use of this material and you will neither export or re-export, directly or indirectly, this material nor any
related materials or supplemental information in violation of such laws, or use such materials for any
purpose prohibited by such laws.
Trademark Acknowledgements
The word and design marks set forth herein are trademarks and/or registered trademarks of Infor and/or
related affiliates and subsidiaries. All rights reserved. All other company, product, trade or service
names referenced may be registered trademarks or trademarks of their respective owners.
Publication Information
Release: Infor ION Grid 12.0.2.0
Publication Date: March 1, 2022
Document code: iongrid_12.0.2.0_iongridag__en-us
Contents
Contents
Contacting Infor..................................................................................................................................7
Chapter 1: ION Grid overview............................................................................................................8

Knowledge prerequisites...................................................................................................................8
Infor ION Grid....................................................................................................................................8
Infor ION Grid application concepts..................................................................................................9
Important network topology considerations.....................................................................................10
Chapter 2: ION Grid administration tools.......................................................................................11
ION Grid administration tool overview.............................................................................................11
Accessing the Grid Management Pages.........................................................................................11
Accessing the web-based Grid Management Pages...................................................................11
Alternative method.......................................................................................................................12
Grid Management Pages overview.................................................................................................12
Home...........................................................................................................................................13
Hosts............................................................................................................................................13
Applications..................................................................................................................................16
Nodes...........................................................................................................................................21
Monitoring....................................................................................................................................26
Security........................................................................................................................................26
Configuration................................................................................................................................28
Grid Bootstrap status page..............................................................................................................28
Opening the Bootstrap status page.............................................................................................28
Chapter 3: Monitoring the Grid........................................................................................................30
Log files and reports........................................................................................................................30
Viewing log files...........................................................................................................................30
Configuring logging levels............................................................................................................31
Generating a Grid Status report...................................................................................................34
Infor ION Grid Administration Guide | 3

Contents
Viewing a Grid Status report........................................................................................................34

Log Archiver.................................................................................................................................34
Monitoring tools...............................................................................................................................36
Monitoring the state of the Grid from the classic administration UI..............................................36
Viewing counters..........................................................................................................................38
Alarms..........................................................................................................................................39
Notifications.................................................................................................................................39
Chapter 4: Changing the Grid configuration..................................................................................42
Configuring memory given to applications......................................................................................42
Configuring bindings........................................................................................................................42
Creating a new binding................................................................................................................43
Editing existing bindings..............................................................................................................44
Changing the display name of a grid...............................................................................................44
Changing the display name of a host..............................................................................................45
Comparing runtime history..............................................................................................................45
Changing how JVMs are launched on the OS process level...........................................................45
Requirements for script files that launch new JVMs....................................................................46
Overriding the Java Executable grid property..............................................................................46
Verifying the scripts are using the correct Java Executable to launch a node.............................47
Example scripts............................................................................................................................47
Multi-host grids.............................................................................................................................47
Scenarios.....................................................................................................................................48
Changing the JDK for a grid node...................................................................................................49
Changing the JDK for a grid host....................................................................................................50
Grid Properties................................................................................................................................50
Property context...........................................................................................................................51
Property strategies.......................................................................................................................53
JDBC drivers...................................................................................................................................54
Routers............................................................................................................................................54
Chapter 5: Managing the Grid.........................................................................................................58
Managing the Grid...........................................................................................................................58
Starting the Grid...........................................................................................................................58
Putting applications or parts of the Grid in an offline state..........................................................59
Stopping an individual Grid node.................................................................................................60

Contents
Stopping the Grid.........................................................................................................................61

Starting new Grid nodes (application instances).........................................................................61
Managing the Grid programmatically..............................................................................................62
Programmatically operating on the Grid by using REST..............................................................62
Programmatically operating on the Grid by using command line interface..................................63
Rolling upgrade...............................................................................................................................64
Chapter 6: Troubleshooting.............................................................................................................65
Introduction to troubleshooting........................................................................................................65
Troubleshooting tools.......................................................................................................................65
Investigating problems or issues.....................................................................................................66
Viewing threads...........................................................................................................................66
Reviewing an application's configuration.....................................................................................66
Gathering information when reporting a problem........................................................................66
Disaster recovery............................................................................................................................67
Accessing the offline version of the Grid GUI..............................................................................67
Recovering from the loss of a host..............................................................................................67
HttpTrace Logging...........................................................................................................................68
Chapter 7: Administrative task reference.......................................................................................69
Administering the Grid.....................................................................................................................69
Grid scripts......................................................................................................................................69
Administering Grid hosts.................................................................................................................70
Add an additional host.................................................................................................................70
Remove an additional host...........................................................................................................70
Handling transient hosts in a cloud environment.........................................................................72
Host Groups.................................................................................................................................72
Administering Grid applications.......................................................................................................74
Starting an application.................................................................................................................74
Stop application...........................................................................................................................74
Accessing Application Management Pages.................................................................................75
Application Repository.................................................................................................................75
Install new application..................................................................................................................75
Application deployment................................................................................................................76
Deploy application on hosts.........................................................................................................77
Undeploy application from hosts..................................................................................................77

Contents
Install a web application...............................................................................................................77

Managing application-specific web components..........................................................................79
Ports for client applications..........................................................................................................80
Connection Dispatchers...............................................................................................................80
Adding a DBC Configuration........................................................................................................81
Deployment Operations...............................................................................................................82
Importing and exporting...............................................................................................................82
Administering Grid nodes................................................................................................................84
Node capacity..............................................................................................................................84
Starting a new node.....................................................................................................................85
Start initial nodes.........................................................................................................................86
Stopping a node...........................................................................................................................86
Set offline.....................................................................................................................................86
Changing the Grid Service user......................................................................................................86
Changing the user assigned to the grid service on Windows platforms......................................87
Changing the user assigned to the grid service on Linux platforms............................................87
Maintenance....................................................................................................................................87
Grid database..............................................................................................................................87
Changing the database settings..................................................................................................88
The Grid and how it is stored on disk...........................................................................................89
Backing up and restoring important Grid files..............................................................................89

Contacting Infor
Contacting Infor
If you have questions about Infor products, go to Infor Concierge at https://concierge.infor.com/ and
create a support incident.
The latest documentation is available from docs.infor.com or from the Infor Support Portal. To access
documentation on the Infor Support Portal, select Search > Browse Documentation. We recommend
that you check this portal periodically for updated documentation.
If you have comments about Infor documentation, contact documentation@infor.com.

ION Grid overview
Chapter 1: ION Grid overview
Knowledge prerequisites
To install this product, you must have:
• Experience installing and configuring applications.
• Operating system administrator experience.
Infor ION Grid

The ION Grid is a Java-based application server that provides a distributed runtime environment for
other applications. Those other applications may, at any time, be added (deployed) or removed
(undeployed) from a grid. The distributed nature of a grid means that an instance of the Infor ION Grid
may span multiple server machines.
The ION Grid consists of several parts:
• Host
A host is a server machine that is participating in a grid. The host may be a physical or a virtual
machine. Each grid has at least one host but may have several. A host may be a member of more
than one grid.
Hosts operating in the same grid do not have to be running the same operating system as each
other. A grid can contain any combination of hosts from the supported platforms.
• Bootstrap
The Grid bootstrap is a JVM used to install, upgrade, and launch the grid on a specific host. The
bootstrap JVM is not owned by the grid but is in fact executed as a service, registered with the
operating system. It is designed to be decoupled in this way to allow the bootstrap or the Host
Router (which it launches) to fail independently of each other without causing total grid failure. In
the list of services, locate the grid bootstrap service. It will have a name in the format: Infor ION
GRID - gridName.
• Host Router
The Host Router is a built-in default router JVM. It is started by the bootstrap and subsequently
there is exactly one Host Router per host.
The host router is responsible for:
• Establishing the communication channels use for all grid internal communication

ION Grid overview
• Starting other grid JVMs on its host (application nodes and deploy nodes)
• Presenting a fixed point for communication with the grid from external clients (for example, the
grid administration ui)
• Node
A node is a JVM that is registered as being part of a grid where grid applications are running. A
grid typically has several nodes running different applications. Each node is running on one of the
hosts that are part of the grid.
Nodes operating in the same grid do not have to be running the same Java version as each other.
A grid can contain any combination of nodes running the supported Java versions. A typical example
of combining Java versions could be using 32-bit and 64-bit editions together depending on the
memory requirements for a specific node or application.
• Deploy Node
Deploy Nodes are used to execute deployment, upgrades, and undeployment of applications. The
deploy node is not necessarily launched on a host which is the target of an application deployment
operation. Also, one Deploy Node may perform a deployment operation with several hosts as
targets.
Infor ION Grid application concepts

A user of the ION Grid should be aware of the following concepts when installing and administering
the grid.
Node types
A node type defines what to run in a specific node. Each node is of exactly one node type. More
precisely, the node type defines what application to run in nodes of this type and may also define default
values for properties (for example, heap size). Node types are defined by the application developer.
Bindings
A binding defines where and how to run nodes of a specific node type. It can be seen as an association
between a node type and a set of hosts. In order to start a specific node type on a particular host, a
binding that associates the node type with the host is needed. Properties needed by the node or the
application running in the node may be defined per binding.
Bindings are defined when applications are installed or by a grid administrator at runtime.
Applications
A grid application is a logical grouping of one or more application modules. An application may be
running in more than one node. It is then said to have more than one application instance. Applications
for the grid are packaged in gar files. A gar file is a type of zip file that can be installed in a grid. It
contains Java class files (.jar files) and any other resources that the application may need.

ION Grid overview
Important network topology considerations

The Infor ION Grid is a highly distributed application server where application nodes can run on many
different hosts. Every node is able and will initiate communication to all Host Routers within the same
grid to register itself on startup, communicate during runtime, and de-register itself on shutdown.
Due to this design, low network latency and high bandwidth are essential for proper grid operation,
and so the following guidelines must be adhered to in order to avoid problems:
• All hosts should be connected using a fast network (Gigabit or faster is recommended).
The network has to be reliable. Dropped network connections result in unpredictable behavior of
applications installed in the grid.
• All hosts included within a grid must be located on the same network segment and ideally connected
to the same switch. The grid was not designed to work across network segments. Any topology
which bridges network segments will not be supported and will likely result in poor application
performance.
For example, the following configurations are unlikely to meet the requirements stated above and
are therefore not supported:
• Mixing hosts which are located in different data-centers or on different sites
• Mixing hosts in the DMZ and on the intranet
• All hosts should be able to communicate freely with each other without hindrance from firewall
configurations.
• If a firewall is in place, rules must be defined to ensure that TCP/IP traffic can flow freely between
all hosts in the Grid for all fixed ports. It is recommended that a firewall be used to ring-fence the
hosts rather than between hosts to minimize the chance of misconfiguration and resulting issues.
• Anti-virus software can interfere with communication between processes. If such software is installed
and running on the servers then care must be taken to ensure that exceptions are created for the
Java executable used to run the Grid.
• In the case of the Windows platform , care must be taken to ensure the firewall service (Windows
service named Windows Firewall) is started. This service should not be disabled or stopped
as this causes inconsistent behavior where traffic is randomly filtered.
• All hosts must be configured with a static IP address.

ION Grid administration tools
Chapter 2: ION Grid administration tools
This section describes the administrative tools that are available for a grid and how to access these
tools.
ION Grid administration tool overview

A grid includes several administration tools for managing and configuring the grid. These are:
• Grid Management Pages
• Offline Configuration Manager
• The Grid Script Utility
• Grid Bootstrap Status page
For procedures to access the management and configuration tools, see:
• Accessing the Grid Management Pages on page 11
• Accessing the offline version of the Grid GUI on page 67
For information about each of these tools, see Troubleshooting tools on page 65
Accessing the Grid Management Pages

Use a browser to access the web-based Grid Management Pages. The web-based version is the
primary user interface of the Grid Management Pages.
Accessing the web-based Grid Management Pages

To access the Management Pages, you must have one of these roles: grid-admin, app-admin, or
grid-viewer. See "Global Roles and Application Roles" in the Infor ION Grid Security and Administration
Guide.
1 Open one of the supported browsers.

2 Navigate to the URL https://server:port/ where server is the name of the server hosting
the grid and port is the HTTPS port for the grid router.
Alternative method
The following method will open the Grid Management Pages with grid-admin as assigned role. The
grid-admin role is required to perform many of the tasks.
Note:
• The following method can only be used on platforms which support a graphical user interface and
have a supported browser installed.
• The scripts delivered assume that the Java executable location is on the path. To verify this, open
a command prompt and type java and press Enter. If a command not found exception occurs
then Java is not on the path and should be added.
1 Open the file explorer or browser tool on the server hosting the grid and navigate to grid_root_
installation_path\bin.
2 Run the AdminUI.cmd by double-clicking on it.
Note: You can start the legacy swing-based Grid Management UI by running AdminUIClassic.
cmd instead.
Grid Management Pages overview

The Grid Management Pages allows you to manage the grid in a browser. The top bar is the starting
point of all navigation in the web user interface. It displays these top category pages:
• Home
• Hosts
• Applications
• Nodes
• Monitoring
• Security
• Configuration
The top bar also displays a search bar, current user information, Grid name, and a context menu for
grid-wide tasks. This table shows the items in the grid-wide context menu:
Top menu item Description Additional information

About Displays information about the current
Grid and shows license information about
third party libraries.
Show Hotkeys Describes keyboard shortcuts.

Top menu item Description Additional information

UI Personalization Allows enabling selected custom user in-
terface preferences.
Error Codes Displays Grid-specific error codes.
Alarm Codes Displays Grid-specific alarm codes.
Reset Log Counters Starts a task that immediately resets the
log counters for all nodes in the grid.
Change Grid Name Enables changing the display name of the See Changing of the display
grid. name of a grid on page 44
Set Grid Offline Starts a task that immediately sets the grid See Putting applications or
offline. parts of the Grid in an offline
state on page 59
Stop Grid Starts a task that immediately stops the See Stopping the Grid on page
grid. 61
Sign Out Immediately signs out the current user.
Home
The Home page is the first page of the Grid user interface. In addition to the top menu and drop-down
menu, which are available from all sub-pages of the Grid user interface, the Home page contains a
collection of widgets:
• List of notifications from events in the Grid that can be filtered by error, warning, or info
• List of hosts in the Grid, noting the number of running nodes and CPU and memory usage
• List of applications
Hosts
The Hosts page shows all hosts in the grid. The page can be viewed as a list, which is useful when
the Grid contain a larger number of hosts, or as individual cards, which is suitable for Grids that contains
few hosts. Switch view by clicking the corresponding icon.
Host list view

The host list view can be filtered and sorted by column. Each entry in the host list has a context menu
that enables these actions:
• Stopping the host

• Setting the host offline

• Changing the name of the host
• Starting a node on the host
• Stopping all nodes on the host
• Viewing host groups
A detailed view of the selected host is displayed in the lower part of the host list view.
Detailed host view tabs Description

Overview Displays host-specific metadata, including current
uptime, CPU and memory usage, errors and
ports.
Nodes Lists the running nodes of the current host.
Bootstrap Displays the current status of the bootstrap for
the current host.
Application Folders Lists the folders and files of the applications in-
stalled on the host.
System Resource Folders Lists the Grid runtime binaries installed on the
host.
Managing the detailed view

Drag and drop the divider between the list and the detailed view to adjust the size of the detailed section.
To hide the detailed view, click the X icon.
To reopen the detailed section, select another entry in the list. This restores the detailed section to the
original size.
Hosts card view

The name and the address of the host are displayed in the header of each card. This table shows the
items in the summary host card:
Summary card items Description

Host is Displays the state of the host including Started, Stopped, or Of-
fline.
Errors Lists the number of errors in all node logs for the host since the Reset
Log Counter was used. You can click the link to show the detail card.
Warnings Lists the number of warnings in all node logs for the host since the
Reset Log Counters was used. You can click the link to show the detail
card.
CPU Current CPU used by the host.


Memory Current memory used by the host.
Select a host card to open the detail card and access the host context menu.
This table shows the additional items in the detailed host card:
Detailed host card items Description

Host Group Shows which host group this host belongs to, if any.
Note: This item is only visible if the specific Grid has defined host
groups.
Operating System The type and version of the host OS.
Version Version of the Grid installed on the host.
Uptime Operating system uptime.
Miniature cards for each Each node running on the host is represented by a miniature card. See
node Node card view on page 23 for details.
Context menu The context menu contains additional host-related views and actions.
This table shows the items in the host context menu:
Host context menu items Description Additional information

Bootstrap The page displays Bootstrap service infor- See Grid Bootstrap Status
mation, such as version and status, for Page on page 28
the selected host. See Opening the Bootstrap
status page on page 28
Application Folders The page lists the folders and files of the
applications installed on the host.
System Resource Folder The page lists Grid runtime binaries in-
stalled on the host.
Stop Stops the host, including all routers and Note: Stopping the last
nodes. host will take down the
whole Grid, making it im-
possible to access the Ad-
min UI. In this case, you
must restart the host from
command line using <GRI
D_INSTALL_FOLDER>/b
in/StartHost.cmd
Set Offline/Online Sets the host offline or online. The nodes See To put hosts in an of-
running on the host will not accept any fline state on page 59
new requests until it is online again.

Host context menu items Description Additional information

Start Node Starts a node on the host. See To start grid nodes
through the Hosts tab on
page 62
Stop all Nodes Stops all application nodes on the host.
Router nodes are not affected.
Change Name Changes the host display name. See Changing the display
name of a host on page 45
View Host Group Links to the Host Groups tab under See Host Groups on page
Configuration. The host group of this 72.
host is selected.
Delete Deletes the host from the Grid configura- This can be used to clean
tion. This option is only available when up the Grid configuration if
the host is stopped. the server no longer is
available.
Note: Deleting a host from
the Grid configuration does
not uninstall the host. You
must run the uninstaller on
the host.
Applications
The Applications page shows all installed applications in the grid. The page can be viewed as individual
cards, or as a list. You can also click Install New to install additional applications, as detailed in Install
New Application on page 75.
The page can be viewed as a list, which is useful when the Grid contains a larger number of installed
applications, or as individual cards, which is suitable for Grids that contain few applications. Switch
view by clicking the corresponding icon.
Applications list view

The applications list view can be filtered and sorted by column. Each entry in the application list has a
context menu that enables these actions:
• Stopping the application
• Setting the application offline
• Resetting the log counters
• Starting a node
• Starting initial nodes

A detailed view of the selected application is displayed in the lower part of the application list view.
Detailed application view tabs Description Additional information

Overview Displays application-specific See Accessing Application
details such as management Management Pages on page
pages, errors, and configuration 75.
problems.
Nodes Lists the running nodes of the
current application.
Bindings Displays existing binding and See Creating a new binding on
enables managing binding for page 43.
application-defined node types. Editing existing bindings on
page 44.
Properties Displays the Grid Properties See Grid Properties on page
page filtered to the specific ap- 50.
plication. On this page, you can
edit application properties and
Grid properties.
Deployment Displays the page for managing See Application deployment on
the deployment of the applica- page 76.
tion on host and host groups.
Deployment Operations Displays the deployment opera- See Deployment Operations on
tions performed for the applica- page 82.
tion.
Log Levels Displays the Monitoring > Log See Configuring temporary log
Levels page, filtered to the rele- levels for applications on page
vant application. 32.
Alarms Displays the Monitoring > See Alarms on page 39.
Alarm page, filtered to the rele-
vant application.
Application Model Displays the XML that defines
the application model.
Web Components Enables managing application- See Managing application-spe-
specific web components such cific web components on page
as REST services or web appli- 79.
cations, if applicable.
Connection Dispatchers Manage connection dispatch- See Connection Dispatchers on
ers. This page displays any ex- page 80.
isting connection dispatcher
configurations.
DBC Displays the Database Connec- See Adding a DBC Configura-
tion Configurations (DBC) page tion on page 81.
that lists existing configurations.


original size.
Applications card view

The application name, and the application type and version are displayed in the header of each card.
This table shows the items in the summary application card:

Application is Shows if the application is Online or Offline.
Run State is Shows the run state of the application: OK, Not OK, Not Running,
or UNKNOWN.
Alarm icon If any node of the application has an active alarm, an icon is displayed
next to the Run State. Click the icon for information about the specific
alarm.
Uptime Shows the application uptime.
Deploy State Shows whether the application has been deployed correctly (OK,
Failed, Queued).
Configuration Shows if the application configuration is correct (OK, Failed, or
Queued).
Errors Lists the number of errors in the application node logs since the Reset
Log Counters was used. You can click a specific link to show the fil-
tered log file.
Warnings Lists the number of warnings in the application node logs since the
Reset Log Counter was used. You can click a specific link to show the
filtered log file.
Select a specific application card to view the detailed card and access the context menu for the
applications.
This table shows the additional items in the detailed application card:
Detailed application card Description Additional information

items
Stop application Click the link to stop the application
immediately.

Detailed application card Description Additional information

items
Management pages This link is active if application-spe- See Accessing Application
cific management pages are avail- Management Pages on page
able. 75.
Host groups Shows which host group this appli- An application can belong to
cation belongs to, if any. more than one host group, but
Note: This item is only visible if the when later adding a binding for
specific Grid has defined host the application, only one of the
groups. host groups can be selected.
Node count Shows the total number of running Click the node count to list the
nodes for the application nodes.
Target Min Count Shows the total number of running
nodes for the application and the
total number of nodes that will start.
The total denotes the sum of all
binding min values, when the appli-
cation is online and started.
Miniature cards for each Each application node is represent- See Nodes card view on page
node ed by a miniature card. 23
Context menu The context menu contains addition-
al application-related views and ac-
tions.
This table shows the items in the application context menu:
Application context menu Description Additional information

items
Properties Displays the Grid Properties See Grid Properties on page 50
page filtered to the specific ap-
plication. On this page, you can
edit application properties and
Grid properties.
Bindings Displays existing binding and See Creating a new binding on
enables managing binding for page 43
application-defined node types. See To edit existing bindings on
page 44.
Role Mappings Displays the Role Mapping To manage role mappings, see
page, filtered to the current ap- "Configuring Role Mappings"
plication. topic in the Infor ION Grid Secu-
rity Administration Guide.


items
Web components Enables managing application- See Managing application-spe-
specific web components such cific web components on page
as REST services or web appli- 79.
cations, if applicable.
Note: The Web Components
menu option is enabled only if
the application contains a web
component.
Connection Dispatchers Manage connection dispatch- See Connection Dispatchers on
ers. This page displays any ex- page 80.
isting connection dispatcher
configurations.
Note: Connection dispatchers
are enabled only if the applica-
tion has been configured to
have connection dispatchers.
DBC Configuration Displays the Database Connec- See Adding a DBC Configura-
tion Configurations (DBC) tion on page 81.
page that lists existing configu-
rations.
Log Levels Displays the Monitoring > Log See Configuring temporary log
Levels > page, filtered to the levels for applications on page
relevant application. 32.
Application Model Displays the XML that defines
the application model.
Deployment Displays the page for managing See Application deployment on
the deployment of the applica- page 76.
tion on hosts or host groups.
Deployment Operations Displays the deployment opera- See Deployment Operations on
tions performed for the applica- page 82.
tion.
Import/Export Enables exporting and storing See Importing and exporting on
the application settings as a page 82.
document to store outside the
Grid. This document can be im-
ported at a later date to any
Grid that supports the feature.


items
Reset Log Counters Starts a task that resets all log
counters for the application
nodes, that is, the warning and
error count displayed on each
node miniature card
Start Node Starts an application node. See Starting grid nodes through
the Applications tab on page 62.
Start initial Nodes Starts all application bindings
with an initial count > 0. Will
start as many nodes as the ini-
tial count. Will not start anything
if the number of running nodes
already is equal or greater than
the initial count.
Set Offline Sets the application offline. See Putting applications in an
offline state on page 59.
Nodes
The Nodes page shows all running nodes in the grid. The page can be viewed as a list, which is useful
in most Grids. The page can also be viewed as individual cards, which is suitable for Grids that contain
few nodes. Switch view by clicking the corresponding icon.
You can also click Start Node to start an additional node, as detailed in Starting a new node on page
85.
Node list view

The nodes list view can be filtered and sorted by column. Each entry in the node list has a context
menu that enables these actions:
• Stopping the node.
• Setting the node offline.
• Resetting the log counters for the node.
• Run garbage collector.
• Immediately terminate the node.
• Creating a thread dump in the built-in format.
• Creating a java-native thread dump.
• Creating a heap dump.

A detailed view of the selected node is displayed in the lower part of the page.
Detailed node view tabs Description Additional information

Overview Displays node-specific details
such as management pages,
errors, and modules.
Log Displays the node-specific log.
Log Levels Displays the log levels for this See Configuring temporary log
node. Changes are applied im- levels for specific nodes on
mediately, and are only valid page 33.
until this specific node is
stopped.
Alarms Displays the Monitoring > See Alarms on page 39.
Alarm page, filtered to the rele-
vant application.
Node Capacity Enables setting a threshold for See Node capacity on page 84.
the relative number of requests
accepted for this node.
Threads The view presents a tree view See Viewing threads on page
of active threads in the node. 66.
Click a thread name to view
stack trace, CPU usage, and
other details.
Counters This view presents the counters See Viewing counters on page
for the node. 38.
Connection Handlers Lists the connection handlers Application nodes only.
active in this node, as well as
the number of active connec-
tions.
Properties Displays all the node properties, It is possible to filter the content
Java system properties, and when searching for a specific
operation system environment property or value.
variables for this node.
Proxies Lists all proxies registered in
this node, including the type of
proxy as well as the key expres-
sion.
Locks Displays all information about
locks currently held by the node,
if any.


original size.
Nodes card view

The node name, and the JVM ID are displayed in the header of each card. This table shows the items
in the summary node card:

Entity type Shows either node or router.
Node is Shows that the node is in any of these statuses:
• OK
• Offline
• Stopping
• Starting
• Not Responding
• Stale
• Failed
• Limited
Uptime Shows how long the node has been running for, or the time since
the node last started.Select a specific node card to view the de-
tailed card and access the context menu for nodes.
Errors Lists the numbers of errors in the node log since the Reset Log
Counters was used. You can click a specific link to show the filtered
log file.
Warnings Lists the number of warnings in the node log since the Reset Log
Counters was used. You can click a specific link to show the filtered
log file.
This table shows the additional items in the detailed node card:
Detailed node card items Description Additional information

Stop Node Click the link to stop the node im-
mediately.
Management pages This link is active if node-specific
management pages are available.

Detailed node card items Description Additional information

Application Shows either SYSTEM or the
name of the application.
Host Shows the grid host in which the
node is running.
PID Shows the system Process ID
(PID) for the node.
Debug Port Shows the port opened for debug- Only if the host router node
ging. is started in debug mode.
CPU Shows the approximate CPU us-
age.
Heap Shows the heap memory usage.
Run GC If required, click the icon to run the
garbage collector.
Log Shows the link where you can view
the node specific log.
Modules Select a specific node card to view Non-router nodes only.
the detailed card and access the
context menu forShows the mod-
ules in the node, including their
status. This field also shows the
router that has ports allocated in it.
Ports Gives an overview of the ports the Router nodes only.
node has allocated.
Context menu The context menu contains addi-
tional node-related views and ac-
tions.
Node context menu

This table shows the items in the node context menu.
Node context menu items Description Additional information

Properties Displays all the node properties, It is possible to filter the content
Java system properties, and when searching for a specific
operation system environment property or value.
variables for this node.
Log Levels Displays the log levels for this See Configuring temporary log
node. Changes are applied im- levels for specific nodes on
mediately, and are only valid page 33.
until this specific node is
stopped.

Node context menu items Description Additional information

Threads The view presents a tree view See Viewing threads on page
of active threads in the node. 66.
Click a thread name to view
stack trace, CPU usage, and
other details.
Counters This view presents the counters See Viewing counters on page
for the node. 38.
Proxies Lists all proxies registered in
this node, including the type of
proxy as well as the key expres-
sion.
Classpath Displays the classpaths for the
modules in the node. Expand
each module to view the class-
paths.
Client Connections Lists the number of active proxy Routers only.
clients connected to this node.
Connection Dispatchers Lists all connection dispatchers Routers only. See Connection
for the host, grouped by router. Dispatchers on page 80.
Connection Handlers Lists the connection handlers Application nodes only.
active in this node, as well as
the number of active connec-
tions.
Node Capacity Enables setting a threshold for See Node Capacity on page 84.
the relative number of requests
Reset Log Counters Starts a task that clears the er-
ror and warning counters for this
node, both system and applica-
tion counters.
Set Offline/Online Sets the node offline. The node See To put individual application
will not accept any new re- nodes in an offline state on
quests until it is set Online page 60.
again.
Thread Dump Starts a task that creates a
thread dump for the node.
Heap Dump Starts a task that creates a
heap dump for the node.
Kill Immediately terminates the
node process.

Monitoring
The Monitoring page is the starting point for the monitoring information and tasks in Grid Management
pages. The top category page contains these pages:
Monitoring pages Description Additional information

Monitoring This page enables configuring See Configuring filtered views
event filters for monitoring pur- for events on page 40.
poses.
Log Files This page enables viewing log See To view log files for old
files. nodes currently running on page
30.
Log Levels This page enables configuring See Configuring temporary log
the log levels for all modules in levels grid-wide on page 33.
the Grid.
HttpTrace Logging This page enables logging See HTTP Trace logging on
HTTP traffic details. page 68.
Log Archiver This page enables configuring See Log Archiver on page 34.
the log archive management in
terms of scheduling and purg-
ing.
Alarms This page shows alarms for ap- See Alarms on page 39.
plications modules that cannot
carry out all tasks. When the
problem is resolved, the alarm
is automatically cleared.
Notifications This page shows notifications See Notifications on page 39.
for events in the Grid.
Status Report This page enables creating a See Generating a Grid status
Grid status report. report on page 34.
Tasks This page shows the tasks that
have resulted in downloadable
resources, such as Grid status
reports and thread dumps.
Security
Most information about security-related topics is covered in the Infor ION Grid Security Administration
Guide.

Security pages Description Additional information

Security The Security tab consists of See Configurable headers
sections, HTTP Security set- chapter, in the Infor ION Grid
tings, and Users, which displays Security Administration Guide.
the roles connected to your
current user.
Role mappings This page displays the role For more information about
mapping for all applications. managing role mappings, see
Configuring Role Mappings in
the Infor ION Grid Security Ad-
ministration Guide.
Sessions This page displays current ses- For each session, the principal,
sions. its roles, the origin of the call
that established the session, the
component that established the
session, and its expiry time are
listed.
It is also possible to delete ses-
sions prematurely.
Client certificates This page enables managing See Managing client certificates
client certificates. in the Grid Management Pages.
in the Infor ION Grid Security
Administration Guide.
Identities This page enables managing See Managing HTTPS identities
identities. in the Grid Management Pages
in the Infor ION Grid Security
OAuth Credentials This page enables managing See Configuring OAuth con-
OAuth credentials. sumer credentials in the Infor
ION Grid Security Administra-
tion Guide.
Audit This page enables managing See Configuring audit in the In-
auditing. for ION Grid Security Administra-
tion Guide.
SAML This page enables managing See Authentication in the Infor
SAML configuration. ION Grid Security Administra-
tion Guide.

Configuration
Configuration pages Description Additional information
Grid Properties This page enables configuring See Grid Properties on page
Grid Properties on different lev- 50.
els, grid-wide, or per host, appli-
cation, node type, or binding.
JDBC Drivers This page enables managing See JDBC Drivers on page 54.
the available JDBC drivers.
Application Repository This page shows a table over See Application Repository on
all Grid Application Archives page 75.
(.gar files) that have been up-
loaded. It also enables upload-
ing and installing grid applica-
tions.
Runtime History This page enables comparing
two version of the Runtime his-
tory.
Endpoints This page shows the endpoints
available in the Grid that is
published on the router your
browser is accessing.
Routers This page shows the available
routers and their configuration.
Host Groups This page enables defining host See Host Groups on page 72.
groups.
Grid Bootstrap status page

The Grid Bootstrap status page can be used to monitor the bootstrap process for the Grid Agent on
the host that the bootstrap service is running on.
Opening the Bootstrap status page

To open the Bootstrap status page from the Grid Management pages:
1 Navigate to the Hosts page.
2 Click a host.
3 In the host details, select Bootstrap.

4 Copy the address url and paste it in the address field of a web browser.
To open the Bootstrap status page from the Grid host (Windows hosts only)
1 Open the file explorer or browser tool and navigate to grid_root_installation_path.
2 Double click on the BootstrapWebUI-xxxxx where xxxxx is the port on which the bootstrap
HTTP interface is running.
To open the Bootstrap status page directly (from other hosts or clients), in a browser, access the
bootstrap WebUI link at http://server:port where server is the name of the server hosting
the grid and port is the HTTP port for the bootstrap process.

Monitoring the Grid
Chapter 3: Monitoring the Grid
Log files and reports
Viewing log files

At least two log files are associated with each grid node, one containing the system log entries and
one or more containing the application-specific log entries. System log entries are those generated by
the grid as the container for the application running in the node; examples might include bootstrapping
information such as Grid and Java versions. Application log entries are those generated by the
application and relate specifically to functionality in the application; an application may declare more
than one log file. Because each application is running in one or more grid nodes, you can obtain valuable
information about an application by viewing these log files. You typically access log files from the
Applications, Nodes, or Log Files pages. Once a log file is opened, you can filter and search for
relevant information. It is also possible to view log files of old nodes that are no longer running and to
download log files in order to, for example, email them to someone.
Viewing log files

1 Log files can be accessed from the Applications, Nodes and Log Files pages.
2 Click the appropriate link, depending on which page you are on.
• On the Applications page, select an application. Then click the log icon for the applicable
node.
• On the Node list page a log icon is available on each row in the list of nodes. Click the icon to
open the log for that node.
Viewing log files for old nodes or nodes not currently running
Note: This procedure is useful to access log files for nodes that have crashed. The log files in that
case are not accessible by the usual means.
1 Select the Monitoring tab and then the Log Files tab.
2 In the list of log files, click the link in the File Name column for the log file you want to view.

Monitoring the Grid
You can also download log files. Click the Download link in the last column for the log file you want
to download.
You can click a column header to sort log files. Clicking a column header again will toggle between
ascending and descending order. Use the text field to filter the view. Specify a search word and
then press Enter.
Configuring logging levels

The log level can be configured on multiple levels. The configuration is found in slightly different ways
for each level.
Note: By activating more detailed logging, logs can fill up quickly. If activating debug or trace logging,
remember to switch back the log levels after capturing an event in the log.
To configure grid-wide logging levels

1 Access the Grid Management Pages as a user with the grid-admin role.
2 Click Configuration.
3 Find the Node log level property (in the Node Logging property group) and click on the link in the
Value column. The link is either "<undefined>" or a list of log levels such as
"ERROR,WARN,INFO,NOTE."
4 Select the applicable log levels. Click Create Property or Update Property.
To configure router logging levels

2 Click Configuration.
3 Find the Node log level property (in the Node Logging property group) and click the "Node log
level" link (not the link in the Value column).
4 To change the log level of a particular router, click on the link on the row for that router in either
the "Any host" column or the column for a particular host. If a particular host is selected, the logging
levels set will only affect the selected router on that host.
5 Click Create Property or Update Property.
To configure application logging levels

To set the application log level it is either possible to follow the instructions for router levels above or
to do the following:
2 Click Applications.

Monitoring the Grid
3 Click the application to configure log levels for.

4 Select Properties from the details of the applicable application.
5 Click the Node log level property (in the Node Logging property group). To find a property quickly,
use the input filter field.
6 Click Edit and then select log levels.
Note: The Level Error check box cannot be cleared.
7 Click Save.
The new log level will be applied to all nodes started after the configuration. It will not be applied
to running nodes.
To configure application-level logging for a specific host

2 Click Applications.
3 Click the application to configure log levels for.
4 Select Properties from the details of the applicable application.
5 Click the Node log level property (in the Node Logging property group). To find a property quickly,
use the input filter field.
6 In the context list to the left, find the Hosts section and click the host you want to override the log
level on.
7 Click Edit and then select log levels.
Note: The Level Error check box cannot be cleared.
8 Click Save.
The new log level will be applied to all affected nodes started after the configuration. It will not be
applied to running nodes.
Configuring temporary log levels for applications

The log levels can be configured temporarily for specific loggers in an application. This makes it possible
to get detailed logs for a specific theme handled by that application or module while avoiding filling the
logs with unnecessary noise. During trouble shooting it is useful to increase the log levels on a detailed
level. The changed log levels can be reset to the property values used for all new nodes that are started.
1 Access the Grid Management Pages as user with the grid-admin role, and select Applications.
2 Select Log levels from the details of the applicable application.
3 The Log levels page displays the application name and modules for the selected application.
4 Click the application name, or module name to display all loggers.
5 Identify the relevant loggers using the logger filter.
6 Select the check boxes for the relevant loggers to change the logging. Log level changes are
immediately applied.

Monitoring the Grid
7 When the required events have been captured in the logs, click the Reset icon. This resets the log
level configuration to the corresponding property values, for all loggers for this application. Resetting
the log levels is especially important for log levels Debug and Trace, which can have a serious
impact on performance.
Configuring temporary log levels for specific nodes

The log levels can be configured temporarily for specific loggers in a given node. This makes it possible
to get detailed logs for a specific theme handled by that node or module while avoiding filling the logs
with unnecessary noise. During troubleshooting it is useful to increase the log levels on a detailed level.
The changed log levels can be reset to the property values used for all new nodes that are started.
1 Access the Grid Management Pages as a user with the grid-admin role, and select Nodes.
2 Select Log Levels from the details of the relevant node.
3 The Log levels page displays the application name and modules for the selected node.
4 Click the application name, or module name to display all loggers.
5 Identify the relevant loggers using the logger filter.
6 Select the check boxes for the relevant loggers to change the logging. Log level changes are
immediately applied.
7 When the required events have been captured in the logs, click the Reset icon. This resets the log
level configuration to the corresponding property values, for all loggers for this node. Resetting the
log levels is especially important for log levels Debug and Trace, which can have a serious impact
on performance.
Configuring temporary log levels grid-wide

The log levels can be configured temporarily for specific loggers in a running grid. This makes it possible
to get detailed logs for a specific theme handled by applications, nodes, modules or loggers, while
avoiding filling the logs with unnecessary noise. During troubleshooting it is useful to increase the log
levels on a detailed level. The changed log levels can be reset to the property values used for all nodes.
1 Access the Grid Management Pages as user with the grid-admin role, and select Monitoring >
Log Levels. The left panel displays all the applications and modules currently running in the grid.
2 Click the applicable application or module to display the individual loggers. You can also select All
to display loggers for all applications and modules.
3 Identify the relevant loggers, for example by specifying the name in the logger filter.
4 Select the check boxes corresponding to the applications, module or loggers to change the logging.
Log level changes are immediately applied.
5 When the required events have been captured in the logs, click the Restart icon. This resets the
log level configuration to the corresponding property values, for all loggers. Resetting the log levels
is especially important for log levels Debug and Trace, which can have serious impact on
performance.

Monitoring the Grid
Generating a Grid Status report

Use this procedure to generate a Grid Status report.
The ION Grid is able to generate a report that includes a variety of information that is useful for
determining the state of a grid and its deployed applications. The report will indicate problems that it
finds and it will also contain log files, configuration files, and other things that may be of use for tracking
down problems. Although you can use the report simply to confirm that the grid is working satisfactorily,
the report is very helpful to include when you need to report a bug or problem with the ION Grid or an
application running in the grid.
1 Select the Monitoring tab and then the Status Report tab.
2 Click the Calendar icon next to the From and To fields to change the log file range. The default
range is one day.
3 Click Generate. The progress for generating the status report is displayed.
When the report is ready, either a Save dialog box is displayed, or the generated file is downloaded.
This will depend on the settings of your browser.
Viewing a Grid Status report

Use this procedure to view a Grid Status report that you have generated and downloaded as described
in Generating a Grid Status report on page 34.
To view a Grid Status report
1 Unzip the saved report into a separate directory. It needs to be unzipped to work correctly. Viewing
the report directly from within the zip file doesn’t work.
2 In the new directory, open the report.html document with a browser. The report.html document
provides an overview of the current status. Any problems that were found are typically indicated
using strong yellow or red color schemes.
3 View other report files in the directory. These include:
• Log files for existing and old grid nodes
• Configuration files for the grid
Log Archiver
The log archiver consists of three parts: an archiver, a purger, and a scheduler.
The archiver, when run, archives all the inactive log files on one or more hosts within the Grid. An
inactive log is a log for which its node has stopped. Whenever the log archiver is run, a notification is
displayed. Notifications can be viewed on the Home screen and under Monitoring > Notifications.
The purger, when run, purges old archives in the database to free up disk space or remove archives
that are no longer need to be kept.

Monitoring the Grid
Note: Log archiving will run when you are uninstalling hosts if the archiveLogsInDatabase flag is
passed to the uninstaller. For more information, see Remove an additional host on page 70.
Configuring automatic archiving

Configuring automatic archiving causes the archiver to run at a specific time on specific days of the
week. This allows you to archive all your inactive log files at specified intervals.
1 Navigate to the Log Archiver page under the Monitoring tab.
2 Click Configure.
3 Select the days of the week and specify a time.
4 Click OK.
Configuring automatic purging

Configuring automatic purging allows you to specify rules for purging old log files automatically to
manage the retention of archives and as a consequence, the size of the database.
2 Click Configure.
3 In the Schedule Automated Purge section, specify the age of archives (day) you wish to retain and
the maximum size of archives (MB).
4 Click OK.
Manually running the Log Archiver

To manually run the Log Archiver:
2 Click Run Archiver.
Manually running the Log Purger

To manually run the Log Purger:
2 Click Purge Logs.
3 Specify the age of archives (day) you wish to retain and the maximum size of archives (MB).
4 Click OK.

Monitoring the Grid
Viewing and downloading archived logs

To view archived logs, navigate to the Log Archiver page under the Monitoring tab.
All the log archives in the database are displayed in the log archives table on the left side of the page.
Monitoring tools
Monitoring the state of the Grid from the classic

administration UI
Use this procedure to monitor the grid using the profiler viewer and log viewer that are available through
the Grid Management Pages when these are accessed by running [grid_root_installation_
path]\bin\AdminUIClassic.cmd. The tools are accessed through the Launch menu at the top
of the window.
Profiler Viewer
This tool enables advanced low-level profiling for the grid application nodes to enable troubleshooting
and advanced performance monitoring. The profiler is primarily intended for use by developers and
those with a deep understanding of how the grid functions.
When you launch the tool, you will be presented with a list of the grid nodes for which profiling is
enabled. That view is structured as follows:
Grid
Node:<node_name>/<ip_address>:<port>-<process_id>
-<module_name>
-<grid_proxy_name>
-<method>
-<counter>
For each of the counters you can view the following information which is valid for the duration between
you starting then stopping profiling:
• Count - number of iterations of that entity
• Time(ms) - total time spent on iterations in msSize (KB) - total amount of data for all the
iterationsTime/Count - average time spent per iterationSize/Count - average amount of data per
iteration
Menu options available in the function and descriptions are as follows:

Monitoring the Grid
Menu Option Description

File • Open • Open a previously saved profile data
• Save log file.
• Save the current profiling data to a pro-
file data log file.
Actions • Reset Profiler • Clear profiling data
• Stop Profiling • Stop profiling data
• Start Profiling • Start profiling data
.
View • Size Unit • Change the displayed size unit for pro-
• Time unit filed data (Bytes, Kilobytes, Megabytes).
• Expand/Collapse • Change the displayed time unit for pro-
• Aggregation filed data (Nanoseconds, Microseconds,
• Refresh Milliseconds, Seconds).
• Show Methods - expand the profile data
tree to only show methods, only applica-
ble when tree is fully collapsed.
• Expand All: Fully expand the
profile data tree
• Collapse Al:lFully collapse the
profile data tree.
• Change the aggregation levels for the
data.
• Refresh the panel.
Log Viewer
The log viewer allows multiple log files to be able to be combined and searched in a merged fashion.
This has multiple uses including the ability to find out what an entire grid was doing at a particular point
in time, or to find all instances of a particular word or phrase.
The viewer consists of four separate panels:
• Files panel
Use to add files either by clicking Add or by dragging and dropping them directly into the pane.
You can select multiple files for adding by using Shift and Ctrl. Files can be either individual .log
files or .zip files. If you add a .zip file, the tool recursively searched the .zip file directories
and adds all .log files to the panel. This is useful for loading the contents of a Grid Status Report
.zip file.
For any files that do not have a .log extension, you will be prompted with the option to include
them.
Note: Adding files which do not have a .log extension may prevent the merging of the log files
from occurring properly.
The Files panel has several buttons:

Monitoring the Grid
• Add: Adds files, either .log or .zip containing log files.

• Remove: Removes the selected file or if no selection is made, removes all files.
• Invert: Inverts the current selection of files in the panel.
• Details: Toggles between showing all file details, including the name, size, modified date, and
the file path, and showing only the name. The default is to show all details.
• Sort: Sorts the list by the order in which the files were added, the file names, the size of the
files, the date the files were last modified, from, and to.
• Filter panel
Use to set filter criteria for viewing the log files. After you set the criteria, you click Update and the
results are displayed in the Output panel (right panel).
There are several filter options:
• Clear: Clears the filters
• Include Entries: Case insensitive text search for word to include. It is possible to include
OR as an operator by inserting a vertical bar (|) between the words to search for. For example,
info OR system would be constructed as info|system.
• Exclude Entries: Case insensitive text search for word to exclude. It is possible to include
OR as an operator by inserting a vertical bar (|) between the words to search for. For example,
info OR system would be constructed as info|system.
• From: Specify a date and time from which the filtered merge should begin.
• To: Specify a date and time at which the filtered merge should end.
• Update: Update the merged log output pane based on the selected files and filter. If no files
are selected in the file list pane, all files are included.
• Logs Time Span panel
Shows the time span at which the merged entity occurred in an included log file.
To work with this panel:
• Hold the mouse cursor over an area in the panel to see the date and time shown as a tool tip.
Click in the window to position the merged output pane according to the date and time displayed
in the tool tip.
• Right-click in the window on a specific log file to position the merged output pane on the selected
log file according to the date and time displayed in the tool tip.
• Output panel
This panel show the merged log output. The data is ordered in the following manner:
• First, the merged sources (log files) are listed.
• Second, the results of the merge, including applied filters, are displayed.
The result lines contain identifying numbers showing which source they are from.
Viewing counters
Counters are a mechanism that measures (counts) different things that occur in a grid node and that
may be of interest for monitoring and diagnosing the inner workings of an application. Counters are
maintained for each grid node and they are not persisted, so the information is lost if a node is stopped.

Monitoring the Grid
Good examples of counters are Used Heap, which shows the memory consumption, and Total Requests,
which shows how many requests have been handled by a thread pool in a node. However, there are
many others.
One very important aspect of counters is that the counter value is sampled periodically and a history
of counter values is maintained for each counter. This makes it possible to view things like memory
usage over time and even get the information displayed as a graph.
1 Navigate to the Nodes page.
2 Select Counters from the details of the relevant node.
A list of counters will be displayed. The displayed list shows the counters with their current value.
Some counters define a valid value range. If a counter is outside of the valid range, it is marked
with a yellow background. A counter that is outside of its valid range is unusual and is worth
investigating.
3 Clicking on the name of a counter will display a graph with the counter values over time. At the top
of the page it is possible to select units of measurement and also how often the counter history
should be polled and how much of it to keep in memory.
Alarms
Alarms are used by an application to signal that they are partly in a faulty state, that is, even though
all nodes are functioning (Global State is ok) it can't carry out all tasks. The alarms are raised by
module, and when the module is fully functioning again, the alarm is automatically cleared.
To view the raised alarms, select Monitoring > Alarms. To get more information about a specific
alarm, review the description or click the information icon (i) next to the alarm.
Notifications
The purpose of notifications is to bring the attention of Grid Administrators both to required tasks that
must be performed and to inform about what has recently happened in the Grid. Notifications are
created when certain actions are performed, either by an admin or by an automatic process. All
notifications are stored in the Grid database up to a maximum of 10000 notifications. This default can
be changed through the grid.events.max.stored property.
Viewing notifications
Notifications can both be viewed in the Notifications section on the Home page of the Grid Admin UI
and on the Monitoring - Notifications page. An Atom feed is also available at
https://host:port/grid/rest/events/events.atom. For monitoring what happens in a Grid,
the Events REST API is a good starting point. The events REST service is located at
https://host:port/grid/rest/events. The documentation for the REST API is available at
https://host:port/grid/rest.

Monitoring the Grid
Notification page
By default, the Monitoring > Notifications page displays both active notifications and resolved
notifications. Active notifications are also displayed on the Notification panel on the Home page.
The sorting is based on the time of publishing, with the latest notification listed at the top.
Applying notification filters

1 Navigate to the Notification page under the Monitoring tab.
2 Filter the displayed notifications using one or more of these methods:
• Clicking a filter icon on a row to only display the notification of this event type or application.
• Clicking Apply Filters and selecting one or more of the check boxes Hide Resolved
Notifications, Severity and Application.
• Specifying free text from title or content in the filter input box.
Resolving notifications
2 Apply suitable filters.
3 Select one or more check boxes. If the top check box is selected, all rows in the current display
are affected. Individual check boxes can be cleared by clicking them.
4 Click Resolve Selected.
The selected notification are resolved, but van still be viewed on this page.
Notifications can also be resolved in the Notification panel on the Home page, by clicking the X
icon. Resolved notifications are no longer displayed on the Notifications panel on the Home page.
Removing applied notification filters

2 Remove the applied filters using one or more of these methods:
• Clicking the applicable filter icon in one of the rows one more time.
• Clearing the check boxes in the Apply Filter dialog.
• Emptying the filter input box, or clicking the X icon.
Configuring filtered views for events

On the Monitoring page an administrator can configure filtered views for certain events.
The available event types are:
• Application Event

Monitoring the Grid
Generic event triggered by Grid applications.

• Application Status
Triggered when the Global State of the specified application is NOT OK. Cool-down applies and
the event is only sent once per change in state.
• Heap Usage
Triggers when the application heap threshold is surpassed.
To add an event filter to the Monitoring page:

1 Click New Filter under the desired event type to open the New Event Filter dialog box.
2 Select what application the filter should apply to.
3 Optionally, select Edit Recipients to open the Recipients dialog box.
a In the Recipients dialog box, specify a valid e-mail address and click the Add button to add a
recipient.
b Click OK to finish adding recipients.
Each card on the Monitoring page represents a filter for the event type (column) and application (row).
The Event Filter card details what application the filter is for and, if e-mail notifications are enabled, the
number of recipients of e-mail notifications and the number of times the event has been triggered.
• E-mail notifications can be enabled or disabled per event type and application by selecting the
enable or disable button.
• To edit the e-mail recipients for a given event type and application, click on the recipients icon in
the card to open the Recipients dialog box.
• To view the triggered events, click on the Triggered badge to open the Notifications page with
those events displayed.
Note: For e-mail notifications to be fully enabled the following Grid Properties must be specified on the
Grid Properties page:
• SMTP Server Address - required
• SMTP Server Port - optional if the default port is used
• SMTP Sender - required
• SMTP Password - required depending on security
• SMTP Security - required depending on security

Changing the Grid configuration
Chapter 4: Changing the Grid configuration
Configuring memory given to applications

This procedure explains how to set a global application value for the Max Heap property. The Max
Heap property as defined in the grid configuration controls the maximum memory amount that can be
allotted at node start to an application in a particular node. This property is one of the most commonly
configured properties. It enables you to accomplish the important task of ensuring that application
nodes have sufficient amounts of memory.
As with any grid property, it is possible to configure the Max Heap property differently for different
contexts. For example, you want an application node to have more memory if it is running on a particular
host. Sometimes applications define several node types and you may want to configure the Max Heap
property differently for different node types. The same goes for bindings. For more information about
configuring a property for different contexts, see Grid Properties on page 50.
2 Navigate to the Applications page.
3 Select the application for which you would like to change max heap settings.
4 Select Properties from the details of the application.
5 In the Grid Defined Properties section under Node Memory, click the row for the Max Heap property.
6 Edit the max heap for the application by clicking Edit, and then specifying the max heap size in
the input field that appears. Click Save.
Note: If the max heap has been overridden or configured in several contexts, you can view and
edit those values by navigating the different contexts on the left. If there is an arrow to the left of
the context name, this indicates that the Max Heap value has been overridden in that context or
by a child to that context.
Configuring bindings
Bindings are needed in order to start applications. A binding is a mapping from a node type, which the
application defines, to a set of hosts. So, in order to start an application on a particular host, there has
to be or at least one binding that associates the application (and its node type) with that host.
The bindings are also used to govern the minimum and maximum number of application node instances
that should be allowed. This means that if a binding is configured with a minimum of 2, the grid will

always try to make sure that at least two application node instances referenced by that binding are
running in the grid. If the number of nodes becomes fewer than the configured value, the grid will
automatically start nodes until the minimum is met.
The maximum works in the same but reverse way. It is impossible to start more application node
instances using this binding than the configured maximum. It should be noted that the maximum is
soft-enforced, if some condition arises which means the running node count exceeds the maximum
value, the Grid will not terminate a node to enforce the constraint.
It is also possible to configure the initial number of application nodes you want for a binding. If configured,
the initial value will be considered when the application starts. In fact, starting applications is just a
matter of honoring the initial value for all the bindings that belong to the application.
Also, as described in Grid Properties on page 50, the bindings are one of the different contexts that
you may use when defining property overrides. This enables you to define different property values for
your application depending on which binding is used to do the launch.
Creating a new binding

1 Go to Applications.
2 Select an Application.
3 Select Bindings.
4 Click Add New.
5 Specify this information for the binding:
Name
Specify a binding name.
Type
Select the node type to create a host binding.
Hosts
Select one or more hosts or select All, which means that the binding can be started on any host
on which the application is deployed.
Min
The minimum number of nodes for this binding which should be running in the Grid according to
the launch constraints, if the number of running nodes becomes lower than the minimum value
set, the Grid will start additional ones.
Initial
The initial number of nodes for this binding which should be started when the grid is first started
(providing that the application is not offline) or when the application is started if that is later,
according to the launch constraints.
Note: For most use cases the initial setting can be left as is, using the Min and Max settings should
be enough for most applications.

Max
The maximum number of nodes for this binding which should be started according to the launch
constraints. Maximum values are softly-enforced meaning if a condition arises where there are
more nodes running than the maximum value, the Grid will not stop running nodes and if necessary
they must be stopped manually.
Constraint
• Global: The constraints will be applied globally, that is, the number of nodes will be distributed
evenly across all hosts to which the binding applies (affected by Preferred Host, see below).
• Per Host: The constraints will be applied to each host, that is, the number of nodes will be
started on all hosts to which the binding applies.
Preferred Host
The preferred host on which this binding will be started, if the preferred host is not available when
the consistency check is performed, the binding will be started on another host for which this
binding is configured. Preferred host is only available when the constraint type is global.
Note: If the application is connected to one or more host groups, the only difference is that there
is a choice of host group (or all host groups) instead of hosts and there is no preferred host
selection.
Editing existing bindings

Bindings are deleted and edited through the mini-card. The fields are the same as when you create a
binding. Min, Initial, and Max values can be edited directly on the card using the minus (-) and plus
(+) icons.
In the bindings overview card, you may view the bindings as a list by selecting the Show as List check
box. You can also filter bindings by specifying any of the binding fields in the Filter field. If you are
using a filter, the number of matched bindings and the total number of bindings will show next to the
filter.
Changing the display name of a grid

Use this procedure to change the display name for a grid. When you create a grid, you provide a name
for the grid that then appears in various management tools. However, at a later date, you may want to
change the name, especially if the name no longer matches what you use the grid for.
Note that changing the display name of a grid does not change the name of the directory where grid
configuration information is stored. The directory name will still match the original name of the grid.
1 On the top UI menu (located in the top right corner), click on Change Grid Name.
2 In the dialog box, specify a new name and click Apply.

Changing the display name of a host

Use this procedure to change the display name for a host in the grid. When you installed the grid (and
when adding a scale-out host), you provide a name for the grid that then appears in various management
tools. However, at a later date, you may want to change the name, especially if the name no longer
matches what you use the host for. Note that changing the display name of a host does not change
the name in the configuration, it simply creates an alias for display purposes.
1 Go to Hosts.
2 Select the host you want to rename.
3 Select the Change Name menu option.
4 In the dialog box, specify a new name and click Apply.
Comparing runtime history

Whenever changes are made to the runtime configuration, a new version of runtime.xml is saved in
the Grid database. The runtime.xml describes the runtime configuration for the Grid, which all hosts
access. You can view older versions of runtime.xml, see a description of the changes in each version,
and compare two versions of runtime.xml.
To compare runtime history:
1 Navigate to Configuration.
2 Select Runtime History.
A list of the most recent versions of the runtime.xml file is displayed.
3 Select two check boxes in the list and click Compare.
The change set is displayed.
4 In the compare dialog, it is possible to do a quick compare of two other runtime configurations
given their index or name. The name can be found in an optionally displayed column in the runtime
history table.
Changing how JVMs are launched on the OS process

level
All grid nodes including Host Router, router and application nodes are JVMs. When a grid node is
started on a host, by default the new node is started using the same JDK or JRE as the Host Router
on that host is running on. However, at times you may want to influence how the JVM processes are
started in the operating system.
For example:

• You want a particular application to be launched using a particular JDK or JRE that is different
from the one used by the grid agent.
• You have an application that is monopolizing a resource (such as CPU) and you want to constrain
the application nodes to a subset of the available CPU cores on a host.
You want JVM processes belonging to a particular application to be launched using a specific user
that is different from the user running the grid agent process.
Regardless of example or needs, the way you change how JVM processes are launched is as follows:
1 Create a host operating system specific script file that launches the JVM process in the way you
want.
2 Override the Java Executable grid property so that it points to the script file created above. The
scripts are most likely OS- and host-specific, so the recommendation is to define the property
overrides in different host contexts.
Requirements for script files that launch new JVMs

Obviously, the script file should in one way or the other launch a JVM since that is the purpose of the
script, but there are additional requirements that the script has to comply with
1 The script must be passed all arguments that the grid would normally pass to the JVM during
launch. Those arguments define what type of grid node to create. The script is responsible for
propagating all those arguments to the JVM that is started by the script.
2 The script may terminate in one of two possible ways:
• The script may block and not terminate until the launched JVM (grid node) terminates.
• The script may asynchronously launch the JVM and exit with a return code of zero (0). A return
code other than zero will be considered an error by the grid.
Overriding the Java Executable grid property

Example scenarios with different scripts are described below. Each of the scenarios requires that you
override the Java Executable grid property so that it targets the script of each scenario. A generic
description of how to do this is given below and specific details will be given in each scenario.
Working with grid property overrides in general is described in Grid Properties on page 50.
1 Decide whether the override should be made in the context of an application or be made global?
Typically you want to override the property in the context of an application. However, there may
be odd scenarios where you want to perform the override regardless of the application. In that
case, you do it in the global context.
Depending on the situation, select one of the two paths below:
a To override the property in the context of an application, navigate to the Applications page.
b Select the application you want to reconfigure.
c Select Properties from the details of the application.

a To override the property in the global context, select Configuration > Grid Properties.
Note: Applications can be selected on the Grid Properties page.
2 In the Grid Defined Properties section under Node Properties, click the Java Executable property.
The edit page for the property is displayed. Here the value can be set and overridden in different
contexts. Using this matrix it is possible to override in various contexts. In the different example
scenarios described below, details will be given relevant to each case that will enable you to
continue from this point.
3 Given details from the different scenarios described below, identify the property context that you
want to override and edit the corresponding value.
4 Specify the path to the script file from the different example scenarios. Note that regardless of host
platform (OS) the path to the script file should be entered using forward slashes ("/") (even on
Windows).
5 Click Save.
Verifying the scripts are using the correct Java Executable

to launch a node
If you want to make sure that the script files are used to start the grid nodes in the correct situations
and in the correct way, check in the correct java executable log. If you have a script file named C:/
script/start.cmd, you should be able to find log entries similar to the following: 2011-09-28
09:36:12,864 DEBUG NodeLauncher: launching: [C:\script\start.cmd. However, the
log level DEBUG must be turned on in the Host Router in order for this to be displayed.
Example scripts
The scripts are executed by the operating system of each grid host. Since the operating system may
vary between different hosts the scripts has to be made specifically for each platform. The examples
in this document are for the Windows platform but there should be no problem to port them to other
platforms using other but equivalent commands.
Multi-host grids
The grid you are working on may be a multi-host grid and the application you want to change in the
different scenarios may be deployed on many of the hosts in that multi-host grid. In order to keep things
simple, the description of each scenario below will operate on one host but you must repeat the process
for each host that is relevant for each scenario.

Scenarios
The scenarios described below give detailed information for each case. The detailed information is
intended to be used together with the generic instructions above.
Scenario 1: Using a specific JRE when launching an application

In this scenario, assume you want all grid nodes belonging to a particular grid application to be running
in JVMs from a specific JRE. The rest of the Grid and other applications should not be affected. Typical
reasons for wanting to do this may be that the application only works using a specific patch level or a
JRE from a specific vendor.
In this scenario, assume that:
• The grid host is named HOST1
• HOST1 has a JRE installed on the following path "C:\Program Files\Java\jre8".
• The grid application APP1 is deployed on HOST1
To use a specific JRE when launching an application

1 Create a script file on the grid host (HOST1), for example,
C:\GridNodeStartScript\StartNodeJRE8.cmd, containing the following single line:
"C:\Program Files\Java\jre8\bin\java.exe" %*
As can be seen, the script line simply targets java.exe in the JRE that was wanted, and by the use
of "%*" at the end of the line, it makes sure to propagate all arguments that were passed to the
script.
2 Configure the application to use the script by editing the Java Executable grid property. Use the
following values:
• Override in the context of an application (APP1 in this case).
• In the matrix, identify the host column belonging to the host (HOST1) and click on the value
link in the first row (the application level row).
• Enter the following path in the dialog box: C:/GridNodeStartScript/StartNodeJRE8.cmd.
Remember to use forward slashes in the path.
The application nodes should now be launched using the specified script on HOST1.
Note: The examples given here are trying to illustrate the generic approach of creating a script file and
configuring the Java Executable grid property to point to that script file. This generic approach allows
for advanced scripts to be created. However, this particular example is so simple that you do not have
to create a script file at all. In this case, you could just enter "C:/Program Files/Java/jre8/bin/java.exe"
as the value of the Java Executable grid property and skip the script file completely.
Scenario 2: Running grid nodes belonging to an application as a specific user

Grid nodes are started using the same OS user that the grid agent is running as. Normally, an application
is not concerned about this user. It is a user that was specified when the Grid was created, and it should
work appropriately. However, if a particular application has to be running as another user, problems
can occur. The Grid is intended to run multiple applications in the same Grid, so a particular application
can’t be allowed to change the user that the entire Grid is using since that would impact the other

applications. In this case, you need to launch nodes belonging to just this particular application by using
another user.
Doing this in a safe way can be tricky since it may require that user names and passwords are hard
coded in script files. However, that is not something that can be recommended for security reasons.
Because of these challenges, there are no recommendations for this case, but general observations
can be noted.
On a UNIX platform, you have the sudo command and on Windows you have the run as command
that can be used to start processes as another user. Neither of them accepts that passwords are passed
to them from the command line. This is good since hard coding passwords in script files should be
avoided.
Third-party tools that are similar to the Windows run as command and also accept a password on the
command line exist. However, these are not recommended by Infor for the reasons mentioned above,
even though they would technically solve the problem. Some of the third-party tools support encryption
of the password information. Potentially those tools may provide a secure way of solving this problem,
but Infor does not give any recommendations in this area.
Giving the user access to the configuration area
If a particular user is used to run all or some of the grid nodes, it is crucial that the user has sufficient
security rights in the grid configuration area. The topic, Changing the Grid Service user on page 86,
describes how to change the directory security. The information is for Windows but the situation is the
same on all platforms. The user has to be given access to the grid configuration area.
Changing the JDK for a grid node

If a grid is installed using a particular JDK version and you later want to change to another JDK version,
you may do that by configuring a grid property. As always with grid properties, they may be configured
and overridden in different contexts (see Grid Properties on page 50). Typically a change of JDK version
will be done on all hosts in a grid or on individual hosts of a grid. The following steps describe how to
change the JDK version for all nodes running in one host. If you want to change the JDK version for
all hosts, you repeat the procedure for each host.
1 Go to Configuration.
2 Go to Grid Properties.
3 In the property list, click Java Executable in the Node Properties section.
4 In the context listing on the left, locate Hosts and click the host whose JDK you want to change.
5 Click Edit.
6 In the input field, specify the absolute path to the Java executable of the new JDK version. For
example, C:/JDK1.8/bin/java.exe).
7 Click Save.
8 Repeat this procedure for other hosts whose JDK you want to change.
9 For any nodes currently running, you will need to restart them to apply the changes. Any new nodes
will use the new JDK when they are started.

Changing the JDK for a grid host

Use this procedure to change the JDK version used on a particular grid host.
Note: Any overrides at host, application, or node level to the JDK set in the grid properties will still be
in place following this step, and will not be updated.
Changing the JDK stops all running applications immediately and then stops all grid nodes including
the Host Router. This procedure should only be done in controlled circumstances since it will impact
users of the application.
1 Stop the Grid. See Stopping the Grid on page 61.
2 For each host where you want to change the JDK:
a Open an administrator command prompt and navigate to grid_root_installation_path
\bin.
b Run the ChangeJDK script passing the new JDK as parameter. For example:
ChangeJDK c:\java\java18 (Windows) or ChangeJDK opt/java18 (*ix).
c Restart the grid bootstrap service.
3 Start the Grid. See Starting the Grid on page 58.
Grid Properties
The Grid Properties are a fixed set of settings defined for the Grid or the grid applications. Each property
has a collection type and a type (single, list, map, map list : integer, string, boolean, enum etc). Most
of them have a given default value. An administrator may set another value for the property in a different
context with higher priority, so that it will have another value at runtime.
In addition to the fixed grid-defined and application-defined grid properties, ad hoc properties can be
defined if needed.
The Grid Properties are primarily managed from Grid Management Pages>Configuration>Grid Properties,
where each property is described in detail. If the Grid is offline, the properties and their descriptions
are still accessible by launching the offline UI, see Accessing the offline version of the Grid GUI on
page 67.
If no application is selected from the drop down list in Configuration > Grid Properties, Grid Defined
Properties and Ad Hoc Properties are displayed. If an application is selected, the properties Application
Defined Properties are displayed, followed by Grid Defined Properties and Ad Hoc Properties.
On each row, the following are displayed:
• The property title, if defined (if not, the property name is displayed)
• The value of the property in the current context (grid-wide or application)
• A description of the property
• The property name

Click a property in the list to edit the runtime value. When editing a property, you can define and set
the value for this property in different contexts.
Property context
When editing a property value, all available contexts are listed on the left side of the page. Contexts
are shown hierarchically. For example, node types are displayed below applications, and bindings
below node types. Each level is more specific and overrides any value set by its parent. Values for
specific hosts can be set on each context. Grid-defined global properties can only have values on the
grid-wide context. Application-defined global properties can only have values on the application-wide
context.
An input field is available for filtering the displayed contexts. This can be useful when there are a lot
of bindings. There is also a check box for showing only the contexts that have a value set on that
context, or any of its children.
An arrow to the left of the context name indicates if a value has been set on that context or any of its
children.
For example, consider an application that uses lots of memory, which can be managed by overriding
the global value of Max Heap property. Typically, you would give this property a value in the
application-wide context. That means that all application nodes on any host will get this value when
launched.
Now, assume that the application has two different node types with different memory requirements. In
this case, you assign a higher value to the MaxHeap property in the context of the node type that
requires more memory. This will override the application context for this node type. Consequently, the
property will have the application-wide value in all application nodes except nodes of this node type.
The contexts have different priorities, so a property may be defined in several contexts, and the one
with the highest priority will be used as the actual runtime value depending on how and where the
application is running.
By setting a value in a context with higher priority, all children of that context will also resolve to that
value, unless they in turn have a different value specified. To see where a specific value is resolved,
click the expandable section Origin.
Resolving property values for application

These are the contexts, listed with lowest priority first. The property will resolve to the value specified
for the given context unless overridden by a context with higher priority.
1 Grid-wide and all host
This is the global base context (lowest priority). Use this context to set a base value for the property,
that will be inherited in other contexts (for example application, node type, binding).
2 Specific host (grid-wide and specific host)
Use this context to set a grid-wide property on a specific host.

3 Application-wide and all hosts

This is the base context (lowest priority) for application-defined properties. Use this context to set
a base value for the property, that will be inherited in other contexts (for example, node type,
binding). This is the context you start in when selecting an application property from the property
list.
4 Node type (node type and all hosts)
Use this context to set a property for all application instances that are running in a node of this
node type. This value will be inherited by bindings and hosts running this node type.
5 Specific host (application-wide and specific host)
Use this context to set a property for application nodes running on this specific host.
6 Binding (Binding and all hosts)
Use this context to set a property in the context of a binding.
7 Node type and specific host
Use this context to set a property in the context of a node type on a specific host.
8 Binding and specific host
This is the context with the highest priority. It sets a property value for application nodes started
with a specific binding on a specific host.
Resolving property values for routers

These contexts are (lowest priority first):
1 Grid-wide and all hosts
This is the global base context (lowest priority). Use this context to set a base value for the property,
that will be inherited in other contexts.
2 Routers
This is the base context (lowest priority) for routers. Use this context to set a base value for the
property, that will be inherited in the other router contexts.
3 Specific host (grid-wide and specific host)
Use this context to set a grid-wide property on a specific host.
4 Router
Use this context to set a property for a specific router.
5 Routers and specific host
Use this context to set a property for a specific router.
6 Router and specific host
Use this context to set a property for a specific router on a specific host.
This is how the property value is resolved in runtime for single values:
• Each application node or router is started using exactly one binding on exactly one host. When
resolving a property, the system will look for a property override for exactly that binding on exactly

that host (Binding and specific host context). If it finds one, the system has found the applicable
runtime value and is finished. If not, the system will continue to look for a property value in contexts
with lower priority until it finds a context that has defined a value. The last context to look in is the
global context (grid-wide or application-wide).
• If a property has been specified in a given context, a right arrow is displayed in front of the value.
To remove a value set in a given context, click Clear.
Property strategies
If a value is set on different contexts (for example, grid-wide and for a specific application), the resulting
value (for any given node) that will be used depends on the property strategy for each context. When
you edit the value of a property you can also change the strategy. Different collection types have
different strategies.
• Single value properties will always use the value from the context with the highest priority. The
strategy is “replace”. Since the strategy cannot be changed, it is not displayed in the Grid
Management Pages.
• List value properties can have one of these strategies:
• Replace - will ignore all values with a lower priority.
• Prepend - will use the values for the current context before values with a lower priority.
• Append - will use the values for the current context after values with a lower priority.
• Map and Listmap value properties can have one of these strategies:
• Replace - will ignore all values with a lower priority.
• Merge - will add all key/value-pairs for the current context to the map with a lower priority. Any
conflicting keys will use the values from the context with a higher priority.
Note: The only properties that can be completely removed, that is, no longer listed, are ad hoc properties,
because these properties are the only ones that can be added in runtime. To remove an ad hoc property,
select it in the property list and clear the property value on all set contexts. This will remove the ad hoc
property.
Adding a new ad hoc property

Create new Ad hoc properties only if it is necessary. Ad hoc properties can be useful for example to
assign environment variables to specific hosts, or be required for specific applications.
1 In Configuration > Grid Properties, click New Ad Hoc Property.
2 Specify the name of the property
3 Select the check boxes This should be a list, Environment Variable, and System Property as
applicable.
4 Click Add to create the property and display the edit property page.
5 Specify the property value for the applicable contexts.
6 Click Save.

JDBC drivers
JDBC drivers can be used by applications to connect to databases. The Grid provides drivers for the
databases that are supported by Grid. However, if an application requires other drivers they can be
uploaded manually.
Use the following procedures to manage the database drivers that can be used by application JDBC
connections.
Note: You cannot edit existing drivers, only add new ones (and remove old ones).
Add a database driver

The Grid supports the uploading of new database drivers (type 4 JDBC drivers only). If you have type
4 JDBC drivers you want to use, you can upload them to the Grid.
1 Navigate to the Configurations tab.
2 Click JDBC Drivers.
3 Click Add New.
4 Specify a name in the Name text field.
5 Browse to the driver file that you want to upload.
6 Click Save.
Remove database drivers

1 Navigate to the Configuration tab.
2 Click JDC Drivers menu.
3 Select the check box for each driver that you want to remove.
4 Click Delete and confirm that you want to remove the driver.
Note: You cannot remove the Grid internal drivers. You cannot remove drivers that are being used by
applications. Any application using the driver is shown in the Used By column. You must first either
uninstall the application or remove the connection configuration that is using the driver.
Routers
Defined routers are listed. Host routers are not visible by default.
Field Description
Edit Edits this router.
Delete Removes this router. Note that you cannot re-
move Host Routers.

Field Description
Host/ The hosts or host groups that the router is config-
Host Groups ured to run on. It is possible to configure a router
so that it automatically runs on all current and
future hosts in the Grid by choosing All. This
can be useful if configuring a load balancer to
distribute the load of client connections amongst
all the hosts in the Grid for either resilience or
load balancing.
External Address Optional external address (FQDN or IP Address).
If undefined, the router listens on the same ad-
dress as the grid agent is using on this host. If
the host has several network interfaces, it is
possible to select a different one here.
Proxy Port The port the router is listening on for non-HTTP
traffic such as legacy socket connections (con-
nection dispatchers) and the Grid client protocol.
Encryption & Ciphers It is possible to enable SSL encryption for the
proxy port. For more information on what these
settings mean, see "To configure SSL for Grid
proxy clients" in the Infor ION Grid Security Ad-
ministration Guide.
HTTPS Port The HTTPS port of the router if defined. The
HTTPS port serves web applications and web
services.
HTTPS Authentication Type It is possible to configure the authentication type
for the HTTPS connections on this port. See the
Infor ION Grid Security Administration Guide.
HTTPS Encryption & Ciphers It is possible to enable SSL encryption for this
port. For more information on what these settings
mean, see "To configure SSL for Grid HTTP
clients" in the Infor ION Grid Security Administra-
tion Guide.
HTTPS WWW AuthenticationMethods The router configuration dialog has settings for
WWW authentication methods. For more informa-
tion on what these settings mean, see "Configur-
ing Router WWW Authentication Methods" in the
HTTPS Identity Configure the HTTPS identity to use for this
router. For more information about HTTPS iden-
tities, see "HTTPS Identities" in the Infor ION Grid
Security Administration Guide.

Field Description
Token Authentication It is possible to enable token authentication for
this router. See "Token Authentication" in the Infor
ION Grid Security Administration Guide.
Impersonation It is possible to enable impersonation on this
router. For more information about impersonation,
see "Impersonation" in the Infor ION Grid Security
HTTP Strict Transport Security HTTP Strict Transport Security (HSTS) is a secu-
rity enhancement activated by a web application
through a HTTP response header. This enhance-
ment enforces the browsers to only use HTTPS
when accessing the web site domain. It also
prevents browsers from accessing the web server
if it does not have an SSL certificates signed by
a CA trusted by the browser.
Published Applications Configure which applications are accessible on
this router.
Note: Disabling SYSTEM disables access to the
Grid Management Pages using this router.
Editing and adding routers

Routers may be added or existing routers may be reconfigured. Client applications may connect to any
router as long as it is exposing the right type of port, HTTPS or proxy, and that port is exposed on a
network interface that is accessible from the client.
One reason for adding a new router is that you want to bind it to another network interface compared
to the existing routers, or you wish to add an additional router to distribute the load or scale-out to an
additional host for resilience. The external address property of the router is used for this (see above).
Another reason for adding a router is to achieve high availability. By having two routers that serve the
same types of ports but on different hosts, you still have a way for clients to connect to the Grid even
if one of the routers fails. To make this fully transparent to the clients, some form of network load
balancer in front of the routers may be needed.
To add a router, click the Add Router link. Edit a router by clicking on the router name link in the list,
then Edit. In both cases you will be presented with a dialog that lets you configure the router.
Application publishing and restrictions

Routers can be configured to publish different applications, depending on the intended role of that
router and the sensitivity of the published content. An application intended for a specific audience, e.g.
intranet users, may be published on a router that is only accessible on the intranet. By limiting where
an application is published, the access to that application is restricted. In this context, access to an
application means access to all its services: web services, REST services, and web applications.
Access to specific components cannot be configured.

SYSTEM is listed as a publishable application in the routers. By not publishing SYSTEM via a given
router, the Management UI will not be accessible via that router. SYSTEM is always published by the
Host Routers.
Note: The SYSTEM application cannot be removed from host routers.
To view the applications published by a router

1 Access the Web UI and select Configuration > Routers.
2 Select the router to view.
3 Scroll down to Published Applications.
To modify the application components published by a router

1 Access the Web UI and select Configuration > Routers.
2 Select the router to configure and click Edit.
3 Under Published Applications, select the applications you want to have published using that router.
4 Click Save.

Managing the Grid
Chapter 5: Managing the Grid
This section describes common administrative tasks, just as those for stopping and starting the grid.
Some of these tasks are performed interactively through an administrative user interface while others
can be performed programmatically.
Managing the Grid
Starting the Grid

The grid will start automatically when the host starts. The sequence of events is:
• The server starts and the operating system boots up.
• The grid bootstrap service is started by the operating system.
The grid bootstrap service checks the activation flag in the grid database and, if the host should
be active, it starts the Host Router.
If the grid does not start automatically, take the following steps (these are for Windows):
1 Access the Windows Server Manager on the server where the grid bootstrap service runs.
2 Under Configuration, select Services.
3 In the list of services, locate the grid bootstrap service. It will have a name in the format:Infor
ION Grid - gridName.
4 Verify the Status column states Started. If the service is not started, right-click on the service
and select Start.
5 If the grid still does not start automatically, execute the StartHost.cmd or StartAllHosts.
cmd script, which is located in grid_root_installation_path\bin.
6 If the grid still does not start automatically, follow these steps:
a Launch the offline configuration manager. See Accessing the offline version of the Grid GUI
on page 67.
b Click on the Hosts link.
c Check that the host is activated. If it is not, click the start symbol to activate the host.

Managing the Grid
Putting applications or parts of the Grid in an offline state

In the ION Grid it is possible to prevent new client requests from being accepted by the server
applications. This state is called offline. When some part of the grid is offline, it will no longer accept
new requests but ongoing requests will be allowed to finish. This is ideal for situations when parts of
a grid need to be taken down but you do not want to simply kill nodes since that would terminate existing
processes performed there. In this situation, you may start by having the grid enter an offline state.
When all ongoing requests are completed, you can stop the nodes or the relevant parts.
A typical example is that you want to stop an application in order to perform some maintenance. Just
stopping all application nodes could perhaps result in some ongoing processing being terminated
prematurely. The solution is to first put the application in an offline state. This prevents clients from
calling the application with more requests. When all ongoing requests are finished, you may safely
stop the application.
An important implication of an application being in an offline state is that nodes will no longer be
automatically started even if the application has bindings that are configured to maintain a minimum
number of running nodes. If an application has bindings of this type, it will be impossible to stop the
application without also putting it in an offline state. This is because not doing so would cause the grid
to automatically start new nodes to replace the stopped one.
The following entities may be put in an offline state:
• The entire Grid
• Individual hosts within the Grid
• Applications
• Individual application nodes
The following procedures describe how to put different parts of the grid in an offline state. Getting them
on-line again is done in the same way.
Putting hosts in an offline state

Note: This will put all the nodes on this host in an offline state regardless of what application they
belong to. The typical reason for doing this is that you intend to remove this host from the grid and you
want to allow application nodes to finish executing in a controlled manner.
1 Navigate to the Hosts tab.
2 Click a host.
3 Open the context menu for the host and select Set Offline.
Putting applications in an offline state

Note: This will put all the nodes belonging to a particular application in an offline state regardless of
where the nodes are running. It will also prevent the grid from automatically restarting nodes even if
they have been configured for that. The typical reason for doing this is that you intend to stop an
application for maintenance but you want to allow application nodes to finish executing in a controlled
manner.

Managing the Grid
1 Navigate to the Applications tab.

2 Click an application.
3 Open the context menu for the application and select Set Offline.
Putting individual application nodes in an offline state

Note: This will put only one node in an offline state. The typical reason for doing this is that you intend
to stop this node and you want to allow ongoing work in the node to finish executing in a controlled
manner.
1 Navigate to the Nodes tab.
2 Click on a node.
3 Open the context menu for the node and select Set Offline.
Stopping an individual Grid node

Normally, you do not stop individual application nodes. Instead, you stop an entire application and, as
a result, all nodes belonging to the application will be stopped. However, there are situations when you
want to stop an individual application node.
For example:
• A node is experiencing problems and you need to stop it, perhaps with the intention of starting a
new node to replace the stopped one.
• The application has been started in multiple instances (nodes) but all that capacity is no longer
needed, so some of the nodes can be removed in order to free resources.
• You want to clear a particular host in a multi-host grid from all nodes in order to perform some
maintenance on that host.
Considerations before stopping a node:
• Should the node be put in an offline state first?
• If the application node is the only one of its kind, the application may stop working. Should a new
similar application node be started first before the node is stopped?
• Applications are implemented differently. Some applications manage their nodes themselves.
Consult the documentation of the application. Does the documentation recommend some alternative
procedure to stopping the node in this case?
To stop an individual grid node
2 Click a node.
3 Open the context menu for the node and select Stop Node.

Managing the Grid
Stopping the Grid

Note: Stopping the entire Grid stops all applications that are running in it. When the Grid is stopped,
no applications can run and no requests can be served. Do not stop the Grid as a quick fix for any
problems that might occur.
Stopping the Grid completely can be useful when you need to run maintenance tasks, such as:
• Making a full backup of the database
• Exchanging an end-of-lifetime component in the hardware
• Upgrading the operating system to a newer version, which requires rebooting of a host
Considerations before stopping the Grid:
• Do you have access to start the Grid again? Verify that the bootstrap service is running and available,
or make sure that you have access to at least one of the hosts in the Grid.
To stop the Grid:
1 Click the menu located at the top right.
2 Click Stop Grid. A message Are you sure? is displayed.
3 Click Yes. A task should be displayed. After the task is finished, you will not be able to connect to
the server anymore.
Starting new Grid nodes (application instances)

Application instances are started by launching a binding that targets the correct node type. Normally
you do not start individual application nodes. Instead, you start an entire application and, as a result,
all nodes belonging to the application will be started. However, there are situations when you want to
start an individual application node. Examples are:
• An application is experiencing increased load and you want to start a new server application
instance, perhaps on a new host with spare capacity.
• You intend to stop an existing node and you want to start a new alternative node first so that the
operations of the application will not be disturbed when you stop the node.
• You want to move the execution of this application from one host to another. This would be done
by starting new nodes on the new host combined with stopping the old nodes on the original host.
Note that not all applications support this operation. Consult the documentation for the application.
Considerations before starting a node:
• Does the application support manually starting new nodes? Some applications manage their own
nodes and they should not be started manually.
• Some applications do not support several instances running simultaneously. If that is the case with
the application you are starting, existing nodes may have to be stopped first. However, ideally,
applications should be written to support this.
• Always consult the application's documentation on what is supported in each case.

Managing the Grid
Starting grid nodes through the Hosts tab

1 Navigate to the Hosts tab and click a host.
2 Click the menu icon for the host and select Start Node.
3 In the pop-up, select a binding and click Start.
Starting grid nodes through the Applications tab

1 Navigate to the Applications tab and click an application.
2 Click the menu icon for the application and select Start Node.
3 In the pop-up, select a binding and a host and click Start.
Starting grid nodes through the Nodes tab

2 Click Start New Node.
3 In the pop-up, select a binding and a host and click Start.
What if the binding to start does not appear in the pop-up?

The typical reasons for not finding a particular binding when trying to launch it on a host are:
• The binding is not configured to be able to run on that host.
• The binding is configured to allow a maximum number of simultaneously running nodes of this type
and that maximum number of nodes is already running in the grid.
For information on configuring bindings, see Configuring bindings on page 42.
Managing the Grid programmatically
Programmatically operating on the Grid by using REST

Use this procedure to programmatically operate on a grid. The ability to programmatically act upon a
grid depends on the fact that the ION Grid exposes a number of status documents and operations
using REST. The REST-enabled APIs are easy to call programmatically and may be used in various
scripting scenarios that operate on the grid or on individual parts of it, for example, applications or
nodes).

Managing the Grid
The REST services are defined by a WADL file in the same way that web services are defined in a
WSDL file. For more information on WADL, see http://www.w3.org/Submission/wadl/.
The WADL file describes the set of operations that is exposed and the schema of the data that is
passed as requests and returned as responses. The WADL file is typically imported into some external
tooling that will generate code in different languages that makes it easy to implement calls to the
exposed REST services.
The REST services are accessed through any of the HTTPS ports that are defined in the grid routers.
The WADL file is also accessible through any of those ports.
REST API
The documentation and a testing tool for Infor ION Grid REST API is available on all grid routers.
To read the documentation and to test the Infor ION Grid REST API:
1 Open a supported web browser.
2 Navigate to this URL:
https://server:port/grid/rest where server is the name of the server hosting the grid and port is the
HTTPS port for the grid router.
3 The Infor ION Grid REST API UI with a listing of available resources is displayed.
• Click the name of a resource to expand the listing of available operations.
• Click the name of an operation to display details about that operation.
• Clicking the operation link again will minimize the operation.
Note about PUT and POST operations: By clicking the Model Schema link in the Parameters section
a JSON skeleton of what the input for that operation looks like is displayed. Clicking this JSON skeleton
will fill the Value text area in the Parameters section with the JSON skeleton.
The Infor ION Grid REST API requires authentication and some of the REST methods require
authentication with the grid-admin and/or app-admin role. Authentication may be performed using
username/password or certificates. For information about how to generate a client certificate, see the
Programmatically operating on the Grid by using command

line interface
The tools folder contains grid-cli.jar that enables performing of tasks and fetching information
about the Grid from a command shell or script. The CLI commands are useful both for interactive work
where each command is submitted through the command line or from a scripting environment where
script output can be captured in json format (–json option).
Use the tool by specifying java –jar grid-cli.jar in the tools folder. This command returns
a general overview of options and commands. Adding the help parameter gives more information about

Managing the Grid
each command. To list possible sub commands, type java -jar grid-cli.jar help command.
To display the available options and parameters for a sub command, specify java -jar grid-
cli.jar help command subcommand.
Rolling upgrade
Rolling upgrade primarily targets Grids deployed in cloud, and is normally initiated by the Infor Cloud
team.
When the Grid detects that a Rolling Upgrade of Grid has been initiated, the upgrade is visualized in
the top right corner of the Grid Management Pages. The progress of the upgrade is visualized in the
Hosts tab and the Node tab. Once one of the host routers run the new version, it is possible to switch
to the new version of the Grid Management Pages by clicking Switch UI Version in the top right corner.
If a failed patch or standard update is detected, a warning is displayed.

Troubleshooting
Chapter 6: Troubleshooting
Introduction to troubleshooting
The first approach to troubleshooting is to use the techniques for monitoring the grid. As described in
chapter "Monitoring the Grid", you typically view log files and change log levels in order to gain more
information. When this is not enough, you can consider the state of the hosts (machines) and anything
related to the operating system on them. Are they configured optimally and do they have enough
resources at hand. For example, are the disks full? Do you need more memory? Are the CPUs stressed?
Are there network issues?
Troubleshooting tools
The ION Grid provides many sources of information about the configuration and runtime status of a
grid and the applications running within the grid. These include:
• Log files
Log files are available for each node. For more information, see Viewing log files on page 30.
• Counters
Counters are available for each grid node as well as a counter history. For more information, see
Viewing counters on page 38.
• Configuration history
You can review a history of changes to the grid configuration so that you can, for example, identify
changes that caused a problem or revert to a previous configuration. For more information, see
Comparing runtime history on page 45.
• Heap dumps and thread dumps
You can view heap dumps and thread dumps for individual grid nodes.
• Grid Status report
The Grid Status report is a generated report that shows the overall status of the grid, and also
includes log files, configuration files. For more information, see Generating a Grid Status report on
page 34 and Viewing a Grid Status report on page 34.

Troubleshooting
Investigating problems or issues
Viewing threads
If a grid node is using an unusually high percentage of the CPU for an extended period of time or if a
node show signs of being unresponsive, you may consider looking at the threads in the node in order
to see what is happening in the node. It could be a situation where a thread is in an endless loop or it
could be in a deadlock situation.
2 Click a node.
3 Select Threads from the details of the node.
4 Click a specific thread or group link to view the current state and call stack.
Reviewing an application's configuration

Problems may result from applications being incorrectly configured. One way of getting an indication
of such problems is to view the configuration of each application.
2 Click an application.
3 If a suggested action to perform is displayed below the Configuration problems header, you may
have a problem. Often the problem can be fixed by clicking on the Fix this problem link next to the
suggested action. However, consult the application's documentation in each case.
4 In addition to looking for a suggested action, review the information on this page. Consult the
application's documentation in each case.
Gathering information when reporting a problem

When reporting a problem, it is very helpful if as much information as possible is included. Log files
with errors and warnings are particularly helpful. For instructions on how to download log files, see
Viewing log files on page 30. If the problem is related to a specific application, gathering as much
information as possible about that application is also helpful.
If the Grid has operational problems, but at least parts of it are still running, it is always best to generate
a Grid Status Report as described in Generating a Grid Status report on page 34 and include that when
reporting the problem.
If the Grid is experiencing so many problems that it can’t be started, it will not be possible to generate
the Grid Status Report. You will also not be able to view log files and other information sources the
normal way. In this case, log files and other information must be retrieved manually from disk. See The

Troubleshooting
Grid and how it is stored on disk on page 89 for instructions on how to locate the grid configuration
area. In the configuration area, all log files and configuration files may be found.
Disaster recovery
Accessing the offline version of the Grid GUI

Use this procedure to access the basic offline-version of the graphical user interface for Grid. This
should only be used when you cannot access the other administrative user interfaces.
Some examples of where this might be required are as follows:
• The grid will not start because all hosts have been deactivated.
• You cannot log in to the grid as grid-admin because of a breakdown in the security process. For
example, all administrators have been accidentally removed.
Note:
• The following method can only be used on platforms which support a graphical user interface and
have a supported browser installed.
• The scripts delivered assume that the Java executable location is on the path, to verify this you
can open a command prompt and type java and press Enter. If a command not found exception
occurs then Java is not on the path and should be added.
To access the offline graphical user interface for Grid:

1 Open the file explorer or browser tool on the server hosting the grid and navigate to grid_root_
installation_path\bin.
2 Run the OfflineConfigUI.cmd by double-clicking on it.
3 Enter the connection options for the grid you want to manage. The default is to use the configuration
for the grid located where you launched the command from.
4 Click Launch Config Manager.
Recovering from the loss of a host

In the context of this procedure, a failed host is considered to be the permanent loss of a host. For
example, a disk crash or other hardware failure has occurred that renders the host unable to be restarted
to re-join the grid.
Use this procedure to replace a lost host:
• Remove the host from the Grid.
• Add the host to the Grid.

Troubleshooting
Note: Unlike Grid 1.x, Grid 2.x does not have the notion of a primary host. In 2.x you can install one
or more hosts and then remove any of them at will. As long as at least one host remains, the Grid will
be operational.
Removing a failed host from the configuration

Once you remove a failed host from the configuration, the remaining hosts will update the new
configuration accordingly.
Note: If the host is still operational, running the Grid's uninstaller is the preferred way to remove a host.
This instruction is only meant to be used when a host is completely unrecoverable and/or the
uninstallation procedure fails.
To remove a failed host from the configuration, run grid-cli recovery removeHost hostName
from any other functional host.
Note: this will remove the host from the configuration and the Grid's database only. Files will not be
removed and running Grid processes may still be running.
HttpTrace Logging
The HttpTrace Grid logger logs http traffic details. This page is used to configure which traffic is logged
on which detail level. Configuration changes made on the page are immediately active and persistent.
All log entries are tagged with a request ID to help correlate multiple log entries belonging to the same
request. The logging can be triggered by enabling the HttpTrace cookie, defining URL patterns or
defining Header patterns. When multiple triggers are in effect, the most detailed level of triggers is
applied.

Administrative task reference
Chapter 7: Administrative task reference
Administering the Grid

This section describes administrative tasks related to the entire Grid.
Note: The scripts delivered assume that the Java executable location is on the path. To verify the
location, open a command prompt, type "java", and then press Enter. If a command not found exception
occurs, then Java is not on the path and should be added.
Grid scripts
The ION Grid is delivered with a number of scripts which enable you to quickly perform operations
such as starting or stopping a host of the Grid. Furthermore, these scripts can be embedded in other
scripts, for example to control operation during a backup or maintenance script.
To locate the scripts, open the file explorer/browser tool or command prompt and navigate to grid_
root_installation_path\bin.
These scripts are delivered:
• StartAllHosts.cmd - set the status for all hosts in the grid to ACTIVATED which will cause the
bootstrap of each host to launch the Host Router resulting in Grid startup on all hosts.
• StartHost.cmd - set the status for the host on which the command is executed in the grid to
ACTIVATED which will cause the bootstrap of the host to launch the Host Router resulting in Grid
startup on this host.
• StopAllHosts.cmd - set the status for all hosts in the grid to DEACTIVATED which will cause
the bootstrap of each host to stop the Host Router resulting in the Grid stopping on all hosts.
• StopHost.cmd - set the status for the host on which the command is executed in the grid to
DEACTIVATED which will cause the bootstrap of the host to stop the Host Router resulting in the
Grid stopping on this host.
Note:
• Modifying the delivered scripts is not recommended as they are subject to replacement during
upgrades.
• The scripts delivered assume that the Java executable location is on the path. To verify that Java
is on the path, open a command prompt, type java, and then press Enter. If a command not found
exception occurs then Java is not on the path and should be added.

Administering Grid hosts

This section describes administrative tasks related to grid hosts.
Add an additional host

Use this procedure to add another host to the grid. By adding a new host to the grid, applications may
scale out to this new host or new applications may be installed there.
1 Run the UI installer on the desired host.
2 Specify the name of the Grid and the database address.
3 Follow the prompts.
Note: Requirements:
• Windows: local or domain account with the ability to log on and run as a service with CRUD
access to the file system where the grid will be installed
• Linux: local service account with CRUD access to the file system where the grid will be installed
a Run the Grid installer on the new server. See the installation instructions.
b Ensure to give the Grid host a unique name.
c Specify the same database and schema information as on the first host.
Remove an additional host

Use this procedure to remove a host from the Grid. Before removing a host from the Grid, you should
undeploy any applications running there. For more information on removing applications, see
Administering Grid applications on page 74.
1 In the file system of the host you are removing, navigate to the Grid uninstall folder. This is
grid_root_installation_path\uninstall.
2 On Windows, make sure the user running the uninstaller is part of the group named gridname_full.
3 On Windows, using elevated rights, run as administrator and then run the file named uninstall.cmd.
4 On Linux, run as root and then run uninstall.
Uninstall errors
One or more of the following errors may occur during the uninstallation:
• DATABASE_FAIL - The uninstaller failed to connect to the database. Verify the connection details
in the datasource.properties file located in grid_root_installation/config.
• SCALED_OUT - The Grid is scaled out to additional hosts. Remove these hosts before uninstalling
the primary host.
• STOP_SERVICE_FAIL - The uninstaller could not stop the service/daemon. Stop the
service/daemon manually, then run the uninstaller again.

On Windows, the service is named: Infor ION Grid - gridname.

On Linux, the daemon is named: grid_gridname.
• STOP_GRID_FAIL - The uninstaller could not stop the grid host.
• FILE_SYSTEM_LOCKED - Files or folders in the Grid install directory were locked, or the uninstaller
did not have sufficient permissions. Close any locking processes and verify that the uninstaller has
access to the files and folders.
• REMOVE_SERVICE_FAIL - The uninstaller could not remove the service/daemon. Remove the
service/daemon manually, then run the uninstaller again.
On Windows, the service is named: Infor ION Grid - gridname.
On Linux, the daemon is named: grid_gridname.
• CLEAN_DATABASE_FAIL - The uninstaller could not clean up the database.
• CLEAN_FILE_SYSTEM_FAIL - The uninstaller could not clean up the file system. If no other error
occurred, you can manually delete the remaining files.
• REMOVE_UNINSTALLER_FILES_FAIL - The uninstaller could not remove the uninstaller files.
You can manually delete the remaining files.
Uninstaller flags
If you want to force the uninstallation to ignore a certain problem, you can pass one or more flags to
the uninstaller. In the file system of the host you are removing, navigate to the grid uninstall folder. This
is grid_root_installation_path\uninstall. Using elevated rights (run as administrator on Windows, root
on Linux), run:
java -jar uninstall.jar flags -baseDir grid_root_installation_path
For example, if the database no longer exists, and you want to uninstall the grid, you can use:
java -jar uninstall.jar ignoreDBErrors -baseDir grid_root_installation_path
The flags you can use include:
• archiveLogsInDatabase - Archive all log files on disk in the database.
• forceClean - Remove uninstaller files even if errors occurred. You will not be able to rerun the
uninstaller.
• forceCleanIgnoreAll - Remove uninstaller files even if errors occurred and ignore all errors.
• help - Show the available start options.
• ignoreDBErrors - Ignore errors relating to database connections and cleanup. Use this if the
database is unreachable.
• ignoreLockedFileErrors - Ignore errors relating to locked files. Files might be left on disk after the
uninstaller finishes.
• ignoreScaleOutErrors - Ignore errors relating to scale out hosts. The whole grid will be deleted
from the database. Scaled out hosts might have files left on disk.
• ignoreServiceErrors - Ignore errors relating to the service/daemon. The service/daemon might not
be removed.
• ignoreStopGridErrors - Ignore errors relating to stopping the grid. Grid processes might be running,
and the files on disk might not be deleted.

• preserveLogFiles - Archive all log files on disk. The grid log files will be in a zip-file named
gridname-grid-log-archive-timestamp.zip. The uninstaller log will be named uninstall-gridname.log.
Both files will be located in the parent folder of the Grid install directory.
Handling transient hosts in a cloud environment

In most cloud Grid environments, hosts are not as static as they are in on-premises environments. The
hosts are more transient in nature. This means that hosts are added to and removed from a Grid
configuration regularly. The Grid does not know if hosts are just in a stopped state or have been removed
completely. In an on-premises environment, to remove a host from the Grid cluster, you execute a Grid
uninstaller. In a cloud environment, you need to run this Grid uninstaller automatically when a host is
terminated. The uninstaller takes down the host and then notifies the rest of the Grid that the host has
been removed completely. The uninstaller also archives log files for later reference.
If instances fail or for other reasons that the uninstaller cannot be executed, you can configure the Grid
to automatically remove hosts that are down in the Grid configuration but are not available in the cloud
environment. Note that configuring the Grid to do this cleanup means that there are no archived log
files. In addition, if a host is removed without executing the uninstaller, the Grid cannot determine if the
host is completely removed or the host is removed because of a temporary network glitch. The Grid
will log some proxy warnings that the host is unexpectedly unresponsive. These warnings will stop
after the host has been cleaned up, but existing warning will remain.
In some Grid environments, there are hosts that should never be removed from the configuration. If
the automatic cleanup is enabled, there is a possibility to add some hosts to a white list of hosts that
should not be part of the automatic cleanup. Make sure that the uninstaller is not executed when these
hosts are stopped.
Considerations to keep the Grid configuration up to date from a host perspective

• Create a service that will run the Grid uninstaller when a host is shut down or terminated. This will
ensure that the host is unregistered from the Grid.
• Set Grid property grid.host.cleanupLostHosts to true to enable the Grid monitor lost hosts. Stopped
hosts in Grid where the corresponding cloud instance is not available will be removed from the
configuration.
• Any hosts that should not be automatically removed from the configuration should be added to the
Grid property grid.host.cleanupWhitelist.
If neither of these steps are enabled, it is your responsibility to remove hosts that have been lost, either
manually or by scripting through Grid REST and cloud API.
Host Groups
Host Groups are used to group together a number of hosts. Applications and routers can be assigned
to the host group. When you assign an application, it will be deployed to all hosts in the group. When
you assign a router, it will start on all hosts in the group.

Adding a host group

1 Click Add New.
2 Specify a name for the host group.
3 To add hosts to the host group, select hosts from the Available host section and click the small left
arrow.
Adding hosts is optional. A host group can be empty.
Note: If the host is already added to a host group a message Are you sure? is displayed. Moving
a host from one host group to another can potentially uninstall and install different applications and
stop and start different routers on that host. Applications and routers are assigned to the host group
on their respective pages. On the Host Groups page, they are only listed.
Assigning application to host group

An application can be assigned to a host group for deployment purposes. When an application is
assigned to a host group, the grid will handle deployment, scale in and scale out operations based on
what hosts are part of the host group.
Assigning an application to a host group
1 Navigate to Applications.
2 Click the application that you want to assign to a host group.
3 Select Deployment from the details of the application.
4 Click Edit.
5 Mark any host groups that the application should be assigned to. A confirm dialog describing the
scale out operation that will be triggered is displayed.
6 If the dialog describes the desired behavior, click Apply; otherwise, click Cancel.
Assign router to host group

You can assign a router to a host group. This will let the grid start routers, to set the assigned routers
configuration on the hosts that are members of the host group. Any router bar host-routers can be
assigned to a host group.
1 Navigate to Configuration.
2 Click the Routers tab.
3 Click the router that you want to assign to a host group.
4 If the environment has any host groups defined, a Host Group option for the label Hosts is
displayed. Click this option.
5 Select the host group to assign the router to.
6 Click Save.

Assign binding to host group

You can assign a binding to a host group. This will let the grid start nodes, to apply the binding
configuration on the hosts in the host group. If an application is deployed to a host group, its bindings
can also be assigned to a host group.
2 Click the application which bindings you want to assign to a host group..
3 In the application details, click Bindings.
4 Hover over the binding that you want to move to a host group. A pen icon is displayed. Click this
pen.
5 In the Edit Binding dialog box, select the applicable host group or host groups for the application
binding.
Note: A binding in an illegal state carries a warning symbol. This happens when the application is
assigned to a host group, but the binding is not, or the other way around. A wildcard is an exception.
A wildcard is a part of both a host group and mode and of a host mode simultaneously.
Administering Grid applications

This section describes administrative tasks related to grid applications.
Starting an application
An application is started based on the information given in the bindings. If a binding is configured with
an initial node count greater than zero, that node count will be considered when starting the application.
So, if an application has two different bindings and both of them have an initial count of one (1), the
grid will recognize this and start one node each for the two bindings.
Stop application
The Stop Application task stops all grid nodes belonging to this application and sets the application in
an offline state. Since the application is put in an offline state, nodes will not be automatically started
even if a binding exists with a minimum count greater than zero. The application will remain in an offline
state until it is started again; depending on the choice made when stopping the application it will remain
in this offline state permanently or until Grid restart.
Note: We recommend that you first put the application in an offline state before stopping it. This gives
the application time to finish processing while at the same time preventing it from accepting new client
requests.

2 Select an application.
3 Select Stop from the application context menu displayed in list view, or click Stop Application in
the detailed card.
4 Click Yes to confirm the operation.
Accessing Application Management Pages

The management pages for an application are displayed if the application is running. The actual content
of the pages will differ depending on the application.
2 Select an application.
3 In the application details, click Management Pages. The management page for this application is
now displayed.
Application Repository
Shows a table over all Grid Application Archives (.gar files) that have been uploaded.
Note: An application might have been uploaded several times but with different versions.
All versions are listed in the table with information about when it was uploaded and if it is installed or
not. Application installation can be initiated right from this page by clicking the plus sign icon. Archives
can be downloaded by clicking the download icon located on the far right.
Upload application
1 Click Upload at the top of the page.
2 Select a .gar or .war file and click the Upload button.
Alternatively, drag and drop the .gar or .war file onto the repository page.
Delete applications from the repository

Select the corresponding check boxes and click the waste bin.
Note: Any application using that version must be uninstalled first.
Install new application

2 Click Install New.
3 Select an already uploaded application or click Upload to upload a new application.

4 Select which version of the application to install.

5 Click Next.
6 Specify a name for the application.
7 Choose which deployment profile to use.
8 Upload configuration data if applicable.
9 If the application is possible to auto scale, you can indicate it should not by clearing the Auto
scaling check box.
10 Select which hosts to deploy the application to.
11 Click Install to perform the installation.
Application deployment
When describing managing the installation and un-installation of a Grid application on a host or a host
group, we use the terms deploy and undeploy. The Grid contains an application deployment mechanism
which supports managing applications deployment on one or more hosts including the primary install
(deploying to the first host), scaling-in, scaling-out, upgrading and un-installing. To be functional, a grid
application must be deployed on at least one host, but an application can also be installed without
being deployed.
1 An application's deploy state indicates, per host or globally, the current deploy state of the application
- that is, if the deploy was successful, is in progress or failed.
2 A deploy is considered successful if the application files could be unzipped on disk on the target
host and the deployment profile was executed successfully.
3 Note that an application binding can only be started on a host where the application is considered
to be OK. An application can have one of these deployed states:
OK An application is deployed successfully.

In progress A deploy is currently in progress.
Failed A deploy has failed and must be handled.
The Deployment page shows which hosts the application is currently deployed on and the deploy
state.
On the Deployment page, you can do these tasks:
• Upgrade - Upgrade the application to another version.
• Scale Out - Deploys the application to another host so it is possible to start the application on that
host. Scale Out is only available if there are hosts the application yet has not been deployed to.
• Scale In - Undeploys the application from a host.
Note: This stops the application on that host if it is running. Scale in is only available if the application
is deployed to more than one host.
• Uninstall - Completely removes the application and its configuration from all hosts.
• Edit host groups, if host groups are defined in the grid.

Deploy application on hosts

If you want to scale out an application to a host that it is not yet deployed to, you may use this procedure.
After you have deployed the application on the new hosts, you also must reconfigure bindings for the
application so that the bindings allow for the application to start on the new hosts. To configure the
bindings, use the procedure Configuring bindings on page 42.
An alternative to scaling out is that you want to move the application to a new host. In that case, you
deploy the application to the new host, as described here, and later remove the application from the
old host. An alternative to removing the application from the old host is to leave it there but just
reconfigure the bindings so that it is not possible for the application to start on that host.
Note: Consult the documentation of each application. Some applications do not support scale-out and
there may be restrictions on what each application supports in terms of moving an application.
1 Open the Deployment page in the Application details.
2 Click the Scale Out link.
3 Select the host that you would like to scale the application out to and confirm the change.
Undeploy application from hosts

Use this procedure to remove an application from one or several hosts. Binding references associated
with this application and the selected hosts will be removed.
It is recommended to first stop any application nodes on the host that you want to remove the application
from.
Note: Removing the application from a host will remove all artifacts of that application including
configuration and data files depending on the application. Further, any grid properties which were
configured for that host will be lost. Please consult the documentation for each application for more
guidance.
1 Open the Deployment page in the Application details.
2 Click the Scale In link and select the hosts you want to remove the application from.
Install a web application

Along with Grid applications, Grid also supports web applications (war files). Once installed the web
application works just like a Grid application.
To install a web application:
1 On the Application page, select Install New to open the Install Application dialog box.
2 Select the Upload link in the Install Application dialog box to open the Upload to Repository dialog
box.
3 Click the Browse button and select a Web Application Archive file (.war).

4 The Install Application dialog box now shows the selected .war file along with two new fields, Type
Name and Version.
5 Specify a Type Name. This is the application name for the entry in the Application Repository.
6 Specify a Version. This is the application version for the entry in the Application Repository.
7 Optionally click the Show Details link for selection of advanced features.
Vertically Scalable
Determines whether the application can be scaled vertically on the same host; enabled by default.
Horizontally Scalable
Determines whether the application can be scaled horizontally across multiple hosts; enabled by
default.
Session Affinity
Indicates that the application requires Session Affinity; enabled by default.
Parent Class Loader First

Determines the behavior of the web application classloader; disabled by default.
8 Click the Upload button to add the Web Application to the Application Repository.
9 Select the newly uploaded application in the Install Application dialog box and click Next.
10 Specify a name for the application.
11 Select the Auto Scaling option if the application must be automatically installed on any new hosts
added to the Grid.
12 Select what hosts the application must initially be installed on.
13 Click Install to complete the installation.
By default a global Binding, named as the application, with minimum set one is created. Also a context
root with the same name as the binding in lower case is added.
Servlet Context Init Parameters
Servlets may require configuration in the form of Servlet Context Init Parameters. Such parameters
can be added to the application in the form of Grid Properties.
To add a Grid Property which will be used as a Servlet Context Init Parameter:
• On the Applications page, select the Web Application to expand the details for the application.
• From the details, select Properties to go to the property configuration page.
• Select Add Ad Hoc Property at the bottom of the page to display the fields for creating an ad hoc
property.
• Specify the name of the property. In order for the property to be propagated to the Servlet Context
as an Init Parameter, the property must be prefixed with "grid.servletContext.initParam.". For
example: "grid.servletContext.initParam.Language".
• Leave all check boxes unselected.
• Click Add to create the property and display the edit property page.
• Click Edit to set the value for all hosts. If the value should only be valid for a specific host, select
a host in the context listing on the left.

• Specify a value and click Save.

• At this point the application must be restarted in order for the properties to be propagated to the
Servlet Context.
Deployment profile data

Servlet Context Init Parameter Grid properties can be created during installation through the use of a
Profile Data file. The profile data file for Web Applications uses the same format as the normal Grid
applications (Java properties). During installation the profile data file is read and for each key prefixed
with "servletContext" a grid.servletContext.initpParam Grid property is created.
Example:
A profile data properties file has these contents:
servletContext.language=EN
servletContext.database=dbserver.example.com
Two grid properties are created:
grid.servletContext.initParam.language=EN
grid.servletContext.initParam.database=dbserver.example.com
These properties in turn are available as Init Parameters named "language" and "database" in the
Servlet Context when the application starts.
Managing application-specific web components

If the node types of a specific grid application contain web applications, or if they expose REST or web
services, these are managed from the application details in Grid Management Pages.
The menu option Web Components is only enabled for applicable applications.
The Grid Management page is grouped by module.
Edit Context Root settings

1 Navigate to the Grid management pages. Go to Applications.
2 Select the application.
3 Select Web Components from the application details.
4 Click Edit.
5 Edit the applicable check boxes for Compression, Header Routing, and Path Routing as directed
in the application documentation.
6 Click Save.
Note: Context roots cannot be removed, only edited.

Ports for client applications

This section provides a general description of how client applications and other server applications
connect to the grid through ports. More specific descriptions of this are in the installation guides for
each application that needs to connect to the grid. Use this description to identify the correct ports for
client applications to use to connect to the grid.
Grid applications do not normally expose ports themselves. Clients connect to ports opened in one of
the grid routers. This is an important concept that enables grid applications to be moved between hosts
and scaled out without confusing the connected clients.
It is possible for applications to bypass the routers and open ports themselves. However, they rarely
do and, if they do, the correct way of configuring that application is described in the application's
documentation. In that case, what is written here does not apply.
The routers may expose ports of different types:
• Proxy - Access to the internal Grid communication protocol.
• HTTPS - Access to web applications, web services, and REST.
• Connection Dispatchers - Ports opened on behalf of grid applications with proprietary communication
configured per application.
Technically, routers are application neutral. A client may connect to any router in a grid as long as that
router exposes the correct type of port on a network interface that is accessible from the client. So,
given that an application client needs a particular type of port, it is possible to select any such port as
long as the client can reach it. However, this should be described in the documentation of the client
application.
Connection Dispatchers
Manage connection dispatchers, that is, open ports on behalf of Grid applications with proprietary
information.
This page displays any existing connection dispatcher configurations.
Note: Connection dispatchers are enabled only if the application has been configured to have connection
dispatchers.
1 Click Add New.
2 Specify this information.
Type
Specify a pre-defined application-specific name of the connection dispatcher.
Authentication Type
Select between No authentication, Server authentication only, Clients may
authenticate with certificate, or Clients must authenticate with
certificate.
Router
Specify which router to use when opening the port.

Port
Specify the port to use.
Description
Provide a description for the connection dispatcher.
Adding a DBC Configuration

The Database Connection Configurations (DBC) page lists existing configurations. Click the pen
icon to edit any configuration.
1 Click Add New.
2 Specify this information.
Name
Specify the name of the database connection.
Driver
Specify the JDBC driver in use for the database connection.
JDBC URL
Specify the connection string for the database connection.
Schema
Optionally, specify the database connection schema.
Username
Specify the database connection user name.
Password
Specify the database connection password.
Keys
Optionally, map the DBC Configuration to one or more keys. These can be used for tenant mapping.
Pool Settings
Click to expand and optional change how the database pooling is configured.
• Min idle connections: The minimum number of connections that can remain idle in the
pool, without extra ones being created, or zero to create none.
• Max idle connections: The maximum number of connections that can remain idle in the
pool, without extra ones being released, or negative for no limit.
• Max total connections: The maximum number of active connections that can be allocated
from this pool at the same time, or negative for no limit.
• Max wait millis: The maximum number of milliseconds that the pool will wait (when there
are no available connections) for a connection to be returned before throwing an exception,
or -1 to wait indefinitely.

• Time between evictions runs millis: The number of milliseconds to sleep between
runs of the idle object evictor thread. When non-positive, no idle object evictor thread will be
run.
• Num tests per eviction run: The number of objects to examine during each run of the
idle object evictor thread (if any).
• Min evictable idle time millis: The minimum amount of time an object may sit idle
in the pool before it is eligible for eviction by the idle object evictor (if any).
• Soft min evictable idle time millis: The minimum amount of time a connection
may sit idle in the pool before it is eligible for eviction by the idle connection evictor, with the
extra condition that at least 'minIdle' connections remain in the pool. When
minEvictableIdleTimeMillis is set to a positive value, minEvictableIdleTimeMillis is examined
first by the idle connection evictor. For examle, when idle connections are visited by the evictor,
idle time is first compared against minEvictableIdleTimeMillis (without considering the number
of idle connections in the pool) and then against softMinEvictableIdleTimeMillis, including the
minIdle constraint.
• Test on borrow: The indication of whether objects will be validated before being borrowed
from the pool. If the object fails to validate, it will be dropped from the pool, and we will attempt
to borrow another.
• Test on create: The indication of whether objects will be validated after creation. If the
object fails to validate, the borrow attempt that triggered the object creation will fail.
• Test on return: The indication of whether objects will be validated before being returned
to the pool.
• Test while idle: The indication of whether objects will be validated by the idle object
evictor (if any). If an object fails to validate, it will be dropped from the pool.
Note: There are Grid counters for DBC pooling. These can be viewed for each node on the node
page.
Deployment Operations
This page displays a row for each deployment operation for the application, and links to the
corresponding log files.
On this page you can do these tasks:
• Retry/Undo - This option is available If an operation has failed. This is the same as on the Deploy
page.
• View profile data - This option is available if the operation used the deployment profile data.
Importing and exporting

An application's settings can be exported and stored outside of the Grid in a document. This document
can be imported at a later date to any Grid that supports the feature. This can be useful for migration,
cloning, or back up of an application's configuration.

Exporting a document
2 Click on the application where you want to import the settings.
3 Select Import/Export from the application details.
4 Under import, click on the folder icon.
5 Specify a password in the text field. The password must be at least 16 characters.
6 Verify the password.
7 In the Valid Through field, specify the date when the document should expire.
8 Click Export. A download prompt is displayed. When exporting a document, any sensitive data
will be encrypted. The encrypted fields cannot be decrypted after the specified validity date.
Importing a document
2 Click on the application where you want to import the settings.
5 Navigate to the document you want to import and click OK.
6 Specify the password to decrypt sensitive data.
If there is no sensitive data in the document, you will not be asked to specify the password.
7 Click Import.
When importing a document, any configuration for the application will be replaced with the data from
the imported document. This may remove or add settings for an application, such as bindings, properties,
and persisted data. If you want to check the changes to be made in the document, use the diff
functionality. The import will not modify anything if it detects that the document contains settings that
are illegally configured, but will present the detected errors in a list instead.
Using diff on an imported document with the application's current state:

2 Click on the application where you want to use the diff settings.
5 Navigate to the document where you want to use diff and click OK.
6 Specify the password to decrypt sensitive data.
If there is no sensitive data in the document, you will not be asked to specify the password.
7 Click Diff.
Diff is presented as a JSON document containing data from both the settings that are currently in use
for the application and the provided JSON document. Any setting that would be removed by an import

is marked red. Any setting that would be added by an import is marked green. Any setting that would
be changed by an import is marked yellow. Unchanged settings are not marked in any specific way. If
you agree with the presented changes, you can click Import.
If the diff shows something unwanted or if there is an error message presented when you import, you
may modify the document manually to change any values that should be imported. Before making any
changes to the document, it is recommended that you first create a copy of the document that you
want to modify.
Grid used to provide a different wizard based Import or Export zip format. This format is still supported
and now comes with a converter. The converter allows you to extract the settings for an application
and creates a JSON document for it. This JSON document can be imported. The new JSON preserves
the password to decrypt sensitive data so you must specify the same password used for the zip in the
old import/export tool.
Converting an imported zipped document

2 Click on the application where you want to use the diff settings.
5 Navigate to the zipped document that you want to convert and click OK.
6 Click Convert.
Administering Grid nodes

This section describes administrative tasks related to grid nodes.
Node capacity
The node capacity option makes it possible to define a threshold for the relative number of requests
Setting node weight

A node with a weight of 50 will receive half the number of requests as a node with weight set to 100.
This configuration only affects the running node.
Note: This task is only applicable in environments without load balancers.
1 Navigate to Nodes.

2 Select a node.
3 Select Node Capacity from the node details.
4 Specify a Node Weight and click Set.
Busy monitor
Enabling the Busy Monitor makes the node go Offline whenever the heap usage in percent is greater
than the Memory Threshold. The denied request counter tracks the number of requests being denied
because of memory problems.
This configuration only affects the running node.
Note: This task is only applicable in environments without load balancers.
1 Navigate to Nodes.
2 Select a node.
3 Select Node Capacity from the node details.
4 Specify a value for Busy Monitor.
5 Click Set.
Starting a new node

Starting a new node can be triggered from both the node card and the node list. Click to launch a new
node. First select the binding (application name is in italics) and then select the host to launch the node
on and finally click Start.
Application instances are started by launching a binding that targets the correct node type. Normally
you do not start individual application nodes. Instead, you start an entire application and, as a result,
all nodes belonging to the application will be started.
However, there are situations when you want to start an individual application node. Examples are:
• An application is experiencing increased load and you want to start a new server application
instance, perhaps on a new host with spare capacity, to cope with the new situation.
• You intend to stop an existing node and you want to start a new alternative node first so that the
operations of the application will not be disturbed when you stop the node.
• You want to move the execution of this application from one host to another. This would be done
by starting new nodes on the new host combined with stopping the old nodes on the original host.
Before starting a node, note these considerations:
• Does the application support manually starting new nodes? Some applications manage their own
nodes and they should not be started manually.
• Some applications do not support several instances running simultaneously. If that is the case with
the application you are starting, existing nodes may have to be stopped first. However, ideally,
applications should be written to support this.
• Always consult the application's documentation on what is supported in each case.

Start initial nodes

Starts all application bindings with an initial count > 0. Will start as many nodes as the initial count. Will
not start anything if the number of running nodes already is equal or greater than the initial count.
Stopping a node
You can stop a node immediately, which is not recommended, or in a controlled fashion, which gives
the node 60 seconds to clean up.
Normally, you do not stop individual application nodes. Instead, you stop an entire application and, as
a result, all nodes belonging to the application will be stopped. However, there are situations when you
want to stop an individual application node.
For example:
• A node is experiencing problems and you need to stop it, perhaps with the intention of starting a
new node to replace the stopped one.
• The application has been started in multiple instances (nodes) but all that capacity is no longer
required, so some of the nodes can be removed to free resources.
• You want to clear a particular host in a multi-host grid from all nodes to perform some maintenance
on that host.
Before stopping a node, note these considerations:
• Should the node be put in an offline state first?
• If the application node is the only one of its kind, the application may stop working. Should a new
similar application node be started first before the node is stopped?
• Applications are implemented differently. Some applications manage their nodes themselves.
• Consult the documentation of the application. Does the documentation recommend an alternative
procedure to stopping the node in this case?
Set offline
Sets the application offline, meaning that the Grid will not automatically start any nodes and most parts
of the application will not be available. For example, HTTP, REST, and non admin proxys.
Changing the Grid Service user

Use this procedure if you need the grid bootstrap service to run as a different user than the default
user.
If the grid runs on multiple hosts, repeat this procedure for each host.

Changing the user assigned to the grid service on Windows

platforms
1 Stop the Grid.
2 Access the Windows Server Manager on the server where the grid bootstrap service runs.
3 Under Configuration, select Services.
4 In the list of services, locate the grid bootstrap service. It will have a name in the format:Infor
ION Grid - gridname.
5 To stop the grid bootstrap service, right-click the entry and select Stop.
6 Double-click the entry to open the Properties dialog box.
7 On the Log On property tab, change the default user to the user you want the grid on this host to
run as.
8 Ensure that the Grid service user is added to the local Grid full security group, named
gridName_full. For more information, see "File Security" in the Infor ION Grid Security
9 Start the grid bootstrap service. Right-click the grid bootstrap service entry and select Start.
10 Start the Grid.
Changing the user assigned to the grid service on Linux

platforms
1 Stop the Grid. At the command line, type /grid_installation_dir/bin/StopHost.
2 Stop the grid bootstrap service. At the command line, type service grid_gridname
3 To launch the bootstrap service as the new user, edit the file /etc/init.d/grid_gridname.
Replace the line USER= with the new user name.
4 Change the owner of the Grid directory. At the command line, type chown -R newUser
Name:newUserNamegrid_installation_dir/.
5 Start the grid bootstrap service. At the command line, type service grid_gridname
6 Start the Grid. At the command line, type /grid_installation_dir/bin/StartHost.
Maintenance
Grid database
The grid uses a database to store all grid data, including but not limited to the following examples:

• Grid runtime binary files

• Grid applications and associated configuration files
• Grid topology and runtime metadata
The Grid keystores and certificates of the grid database are generally considered to be static, that is,
non-transactional. The most common trigger of an update to the grid database is when configuration
changes are made. The following are some examples of such changes:
• Add, remove or change a host
• Add, remove, upgrade or re-configure an application
• User management changes
• Grid configuration changes including but not limited to bindings and properties
Given the content of the database, it is critical to the operation of the grid. Loss of the database or
corruption to the data will result in the inability to operate the grid and therefore consideration must be
given to the infrastructure, security, and maintenance of the database server.
It is highly recommended that the database server be prepared for production purposes in that some
or all of the following principles are employed. Please note that these are only intended as guidelines
to enforce the need to consider the requirements that the grid database be highly available:
• Disks are configured in a RAID array employing redundancy (for example, RAID 1, 5 or 10)
• Database server is clustered either active-active or active-passive to cope with single server failure
• Database server employs multiple network interfaces with a common address
• Regular point-in-time backups are taken and their ability to be restored is validated at each occasion
Changing the database settings

Use the following procedure to change the user or password for the grid database connection.
1 Stop the grid.
2 Stop the bootstrap service.
3 Run this CLI command:
grid_installation_dir/tools> java -jar grid-cli.jar database config -

user <new-user> -password <new-password>
This is an example, use the help parameters to view all options.

4 Start the bootstrap service.
5 Repeat steps 2–4 for each Grid host.
6 Start the grid.

The Grid and how it is stored on disk

Each instance of a grid has a folder on disk on each host that is part of that grid instance. This folder
is called a grid configuration area. It contains the runtime artifacts of the grid, configuration data, and
the applications deployed to that host.
The configuration area is located within grid_root_installation_path.
When looking within a configuration area, you will find a set of subfolders, some of which are:
• grid/applications: All applications that are deployed in this host will reside here in a subfolder
of their own
• config: Configuration data used by the grid
• grid/log: Log files from all application grid nodes running on this host
Backing up and restoring important Grid files

In a grid, certain files are essential to the communication within and to that grid. It is recommended to
perform a backup of these files in case of data loss or corruption. Backups should be performed for all
hosts in a grid.
To locate the grid files area, see The Grid and how it is stored on disk on page 89.
Note: When backing up the grid files, the applications will be backed up as well. However, from the
applications' perspective, that may not be enough. Consult the documentation for each application
regarding backup procedures.
Note: When you back up the grid files, be sure to apply file security to them so that they are protected
similarly to how the live production grid files are protected.
What Grid files should be backed up?

Listed below are the directories that should be backed up.
Installation /secure directory

The contents of the grid_root_installation_path/secure directory should be backed up.
After restoring the contents of this folder, restart the host.
Installation /config directory

The contents of the grid_root_installation_path/config directory should be backed up.
After restoring the contents of this folder, restart the host.

Infor ION Grid Administration Guide

Uploaded by

Copyright:

Available Formats

Infor ION Grid Administration Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Infor ION Grid Administration Guide

Uploaded by

Copyright:

Available Formats

Infor ION Grid Administration Guide

Chapter 1: ION Grid overview............................................................................................................8

Infor ION Grid Administration Guide | 3

Viewing a Grid Status report........................................................................................................34

Infor ION Grid Administration Guide | 4

Stopping the Grid.........................................................................................................................61

Infor ION Grid Administration Guide | 5

Install a web application...............................................................................................................77

Infor ION Grid Administration Guide | 6

Infor ION Grid Administration Guide | 7

Chapter 1: ION Grid overview

Infor ION Grid

Infor ION Grid Administration Guide | 8

Infor ION Grid application concepts

Infor ION Grid Administration Guide | 9

Important network topology considerations

Infor ION Grid Administration Guide | 10

Chapter 2: ION Grid administration tools

ION Grid administration tool overview

Accessing the Grid Management Pages

Accessing the web-based Grid Management Pages

Infor ION Grid Administration Guide | 11

Grid Management Pages overview

Top menu item Description Additional information

Infor ION Grid Administration Guide | 12

Top menu item Description Additional information

Host list view

Infor ION Grid Administration Guide | 13

• Setting the host offline

Detailed host view tabs Description

Managing the detailed view

Hosts card view

Summary card items Description

Infor ION Grid Administration Guide | 14

Summary card items Description

Detailed host card items Description

This table shows the items in the host context menu:

Host context menu items Description Additional information

Infor ION Grid Administration Guide | 15

Host context menu items Description Additional information

Applications list view

Infor ION Grid Administration Guide | 16

Detailed application view tabs Description Additional information

Infor ION Grid Administration Guide | 17

Managing the detailed view

Applications card view

Summary card items Description

Detailed application card Description Additional information

Infor ION Grid Administration Guide | 18

Detailed application card Description Additional information

This table shows the items in the application context menu:

Application context menu Description Additional information

Infor ION Grid Administration Guide | 19

Application context menu Description Additional information

Infor ION Grid Administration Guide | 20

Application context menu Description Additional information

Node list view

Infor ION Grid Administration Guide | 21

Detailed node view tabs Description Additional information

Infor ION Grid Administration Guide | 22