AMX RMS CODECRAFTER Guia de Instalação descarregar pdf (Página 115)

Appendix C: Clustered Deployment

109

RMS Enterprise - Installation Guide

Appendix C: Clustered Deployment

Overview

The following points address common question relative to installing RMS in a clustered deployment.

Sticky Sessions

The term "sticky session" refers to the feature of many commercial load balancing solutions for web-farms to

route the requests for a particular session to the same physical machine that serviced the first request for that

session.

In a sticky session, the user is always sent to the same physical server as they page through the Web site. This

is usually done at the router or switch layer, and it keeps the session variables of the user available.

For users coming through the Flex interface, sticky sessions are a requirement. In the event of a fail-

over to another node, the user's session will not exist on the new node and they'll be forced back to

the login screen.

For programmatic clients coming through the REST interface, sticky sessions aren't a requirement,

but still desirable for performance reasons.

Shared file storage

Shared file storage serves two purposes:

Server log files are written to a shared log directory. This provides the application a single place to

download log files via the Flex UI.

If access to the shared log directory is lost, the individual servers will continue to also write their

log files to a local directory on their own hard drive.

Shared file storage houses the search index. All nodes in the cluster need to be able to read this

index data. Searches against this data only happen from the Flex UI (e.g. the Asset Management UI

uses searches against this index exclusively).

If access to this search index is lost, searches will fail.

Tomcat's Session Replication feature is not used by RMS.

In the event of node failure

When a node fails, the transactions in-work on that server will not be committed to the database.

Human users will be forced to login again and start their workflow over.

Programmatic clients (or NetLinx controllers) will have their current request fail and subsequent

requests will be routed to another server. They use Digest authentication and will simply re-

authenticate transparently.

Recommended procedure to restore a failed node

This will depend on the kind of failure:

If the JVM or Tomcat crashed, just restart Tomcat.

If the hard drive crashed, then a new drive and a reinstall is required.

If the hard drive crashed on the server that hosts the Sentinel Licensing service, then restoring that

node will likely also involve resetting the licenses with AMX so they can be reactivated on a new

hard drive.

If a node loses connectivity to the database

If a node loses database connectivity it does not remove itself from the cluster. It will just issue errors to both

the Flex and REST clients. The underlying database connection pool will begin working to restore database

connectivity. Without the database, the application simply will not function.

From a UI perspective, RMS may show an error retrieving the Hotlist, but if database connectivity is restored

the UI will recover and begin working again.

1 2 ... 110 111 112 113 114 115 116 117 118 119 120 ... 135 136

Comentários a estes Manuais

Sem comentários

AMX RMS CODECRAFTER Guia de Instalação Página 115

Comentários a estes Manuais

Manuais e produtos relacionados com Software AMX RMS CODECRAFTER