Industrial Application Server Platform Deployment Checklist

Posted on 338 views

SUMMARY

This Tech Note provides a checklist to cover before deploying a Platform to a computer. It is based on content found in Appendix A System Integrator Checklist of the FactorySuite A² Deployment Guide.

Use this checklist to evaluate current systems with the goal of uncovering sources of errors or poor performance. For example, the error message Platform exceed maximum heartbeats timeout of 8000 ms along with poor performance and strange symptoms is often caused by not having the ArchestrA network first in the Network Binding Order. See the section Configure Dual NICs below for more information about this configuration.
Application Versions

All Industrial Application Server versions
All Wonderware Application Server versions

SITUATION
Platform Deployment Checklist

The list items are compiled from integrator comments, Tech Support sources, and documentation. The items include internal and external links to supporting information.

The checklist is organized into the following areas:

General
Communication
Security
Administration (Local and Remote)
Redundancy Configuration
Migration
Compatibility

ACTION
General
Use Time Synchronization

Configure the computers in a Galaxy to synchronize time at regular intervals.

This is particularly important for alarm and data historization. The Historian node is a good candidate for the computer by which all other computers will synchronize time.

Note: Details about Time Synchronization are available throughout the Deployment Guide by searching (Ctrl + F keys) for time sync.
Disable Hyper-Threading

Disable Hyper-Threading on computers that support this hardware function.

Hyper-Threading gives a false impression of lowering processor load while actually increasing the load on the actual (rather than virtual) processor. Some computers vendors (for instance, Dell) may enable hyper-threading by default.
To disable hyper-threading

Reboot the computer.
Enter BIOS setup.
Disable hyper-threading.
Save and exit setup.

Note: For more information on hyper-threading, see Best Practice on page 233 of the FactorySuite A² Deployment Guide.
Communication
Disable IPv6 for Each Network Adapter

This task is not necessary for VMWare Network Adapters.

Disabling IPv6 is done by unchecking Internet Protocol Version 6 (TCP/IPv6) (Figure 1 below).

Figure 1: Disable IPv6
Configure IP Addressing

All nodes in your Galaxy must be able to communicate with each other by using both IP address and Node Name in the Network Address option of the WinPlatform’s editor.

If PCs in the Galaxy are using fixed IP addresses, create a hosts file with the host name to IP Address mapping.

WinPlatform connection problems may result if computers cannot be accessed by both Hostname and IP address. This is true no matter which type of Network Address you choose to use.

For example, assume two nodes in your Galaxy (host name: NodeA, IP address: 10.2.69.1; host name: NodeB, IP address: 10.2.69.2). NodeA must be able to ping NodeB with both NodeB and 10.2.69.2.

The reverse must also be true for NodeB pinging NodeA. Failure in either case may result in the following: you may not be able to connect to a remote Galaxy Repository node from the IDE or deployment operations may fail.
Configure Dual NICs

Use two Network Cards on a computer that hosts I/O DAServers. Doing so will increase throughput, and improve load balancing.

It is also good practice to place PLC communication on a dedicated (Control) network.

Note: More information on dual NIC configuration is contained in NIC Configuration: Redundant Message Channel (RMC) on page 63 of the FactorySuite A² Deployment Guide.
TCP Offload Engine (TOE) and Application Server Redundancy

TOE is a technology used in network interface cards to offload processing of the entire TCP/IP stack to the network controller. It is primarily used with high-speed network interfaces, such as Gigabit Ethernet and 10 Gigabit Ethernet, where processing overhead of the network stack becomes a significant concern.

Wonderware has discovered several issues involving the use of TOE (TCP Offload Engine) when configured with Application Server Redundancy. An enhancement request (L00074372) has been created to address this issue in a future Application Server release. In the meantime, TOE must be disabled in order for Application Server Redundancy to function properly.
Error Message Examples

When trying to deploy the last and largest engine of four engines, Redundancy.partnerStatus for all engines changes to “Standby – Not Ready” and logger is flooded with “Missed Heartbets” messages.
Tables were not created in WWALMDB database.
CFailoverStatusManager::CheckSubscription Found unacked remote subscriber over primary channel from platform 4 interested in local engine 4 (Dell Server).

Note: This issue has been reported on HP and Dell Servers.
Disabling TOE

Different computer manufacturers will have different methods to disable TOE.

To disable on HP Workstations and Server

Start the HP Network Configuration Utility.
Click the Teaming Device and open the properties.
In the Team Properties dialogue box, go to Settings and click on TCP Offload Engine.
Uncheck Enable and click OK to apply the settings.

For any other Workstations and Servers

For Windows Vista use the following command lines:

Enable: netsh int tcp set global chimney=enabled
Disable: netsh int tcp set global chimney=disabled

In Dell’s case, the TOE is enabled on some servers (such as PowerEdge), and the TCP Offload Engine settings are configured under the Broadcom network suite.

To disable TOE from the Registry Editor

Open the Registry Editor (regedit).
Locate HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Set the EnableTCPChimney parameter to 0.

Disable TOE from other locations

You can disable TOE from your network adaptors’ Advanced Settings. This setting might also be found in the motherboard.
Security
Confirm User Name and Password

All nodes in the Galaxy need to have the same user name/password for the Archestra Admin User (aaAdminUser.exe).
Configure Anti-Virus Software

Anti-Virus software should not process files in the ArchestrA folders listed below.

Note: The following paths assume C: as the drive. The paths could also be on D: or E: drives.

C:\Program Files\ArchestrA\Framework\Bin\CheckPointer
C:\Program Files\ArchestrA\Framework\Bin\GalaxyData
C:\Program Files\ArchestrA\Framework\Bin\GlobalDataCache
C:\Program Files\ArchestrA\Framework\Bin\Cache
C:\Documents and Settings\All Users\Application Data\ArchestrA (default setting, specified on WinPlatform editor’s General page, History store forward directory option)

If the Anti-Virus software processes these files, it may result in slow performance as deploys are performed.
Notes:

More information on Virus protection is found in Virus Protection on page 195 of the FactorySuite A² Deployment Guide.
The Readme files for Application Server 3.1 and later contains an updated list of Antivirus Software Exclusions.

Administration (Local and Remote)
Install Correct IAS Components

Install the IDE and Bootstrap on any PC that will browse the Galaxy. This includes WindowMaker and SCADAlarm Event Notification Software nodes.
Install the Bootstrap and Deploy a platform to any PC that will be an AOS (Application Object Server) or will be doing I/O with a Galaxy (includes WindowViewer and SCADAlarm Event Notification Software nodes).

Note: See Integrating FactorySuite Applications on page 91 of the FactorySuite A² Deployment Guide
Connection Requirements for Remote IDE (from a Client Machine to a Galaxy)

(Tested with Windows XP Pro SP1 on the client machine and Windows 2000 Server SP3 on the GR node.)

A. The Archestra Admin User (accessed via the Change Network Account utility) needs to have the same Username and Password on both the client machine and the GR Node.
B. The Logged in user on the client machine needs to be part of the local Administrators group.
C. The GR Node needs to have a user account with the same username and password as the logged-in user on the client machine. This GR Node user does not have to be logged in and does not have to be part of the Power Users or Administrators group.
Redundancy Configuration
Redundant AppEngines

WinPlatforms hosting redundancy-enabled AppEngines must run on the same operating system. For redundancy to function properly, WinPlatforms hosting redundancyenabled AppEngines must be deployed to computers running the same operating system.
Multiple NICs

In general, multiple NIC configuration is recommended only for Redundancy purposes. Using 1GB network cards in combination with managed switches should be sufficient for most process network throughput needs.

If any nodes in your ArchestrA environment (outside of redundant nodes) have multiple NICs, be aware that proper configuration of those computers is essential to successful communication between ArchestrA nodes.

In other words, if a PC has two network cards and will have a platform deployed to it, then the Network Binding Order must have the Archestra network as the first network even if one of the Network cards is disabled.

Information about configuring multiple NIC computers is included in the Introduction and ArchestrA Redundancy chapters of the IDE documentation (IDE.pdf).

Note: See NIC Configuration: Redundant Message Channel (RMC) on page 63 of the FactorySuite A² Deployment Guide.

The setting for the Network Binding Order can be found in Tech Note 368, Network Setup for AppEngine Redundancy.

Note: See Implementing Redundancy on page 61 of the FactorySuite A² Deployment Guide.
Migration
Verify Version and Patches

Verify that all nodes in the Galaxy have the same version and patch level of Industrial Application Server.
Upgrade Correctly

When upgrading from IAS 1.x to IAS 2.x be sure to uninstall IAS 1.x first before installing IAS 2.x.

For upgrading to Wonderware Application Server 3.0 and later, see Tech Note 705 Wonderware Application Server Migration Tips.
Compatibility
FactorySuite Component Version Compatibility

Ensure that there is no conflict between FactorySuite A² System Components and FactorySuite 2000 Components by following Tech Note 313, Installing FactorySuite® A² Components Alongside FactorySuite 2000 Components.

IAS and IndustrialSQL Server have specific version compatability requirements. Check the OS or DB Compatibility Matrix on the Wonderware Technical Support main page for detailed compatibility information.
SUPPORTING INFORMATION
References

The Application Server Tech Notes referenced in this Tech Note are available in the Wonderware Knowledge base.

Tech Note 368 Network Setup for AppEngine Redundancy
Tech Note 705 Wonderware Application Server Migration Tips

Leave a Reply

Your email address will not be published. Required fields are marked *

+ 18 = 27