1. Preliminary:
The redundancy of GuardPoint Pro servers and/or database is employed by high security systems requiring a quasi-total availability of the access control system.
In case of failure of the GuardPoint Pro server, it is possible to guarantee the permanence of the service by switching towards a redundant server.
GuardPoint Pro works thanks to a server, linked to a database. Some workstations can be linked to the server, if necessary. The database can be installed on the PC server or on another PC.
The GuardPoint Pro server redundancy principle is to provide the server function in case of failure of the main server. The database can have also a redundant database by replicating the main database.
2. Cold server Redundancy (by external third party application):
Principle
In integrated systems the GuardPoint Pro functions as the Access Control component. When the external supervising application detects a failure in one of the component, it may decide to swap all components to a redundant server, simply by starting GuardPoint Pro on a redundant PC.
Launching GuardPoint Pro on a redundant PC:
- Automatically closes GuardPoint Pro Server on the main PC, by a command sent from the redundant server to the main server via spread tool.
- All the controllers are polled now by the GuardPoint Pro redundant server.
- All the workstations swap automatically to the GuardPoint Pro redundant server.
When the main server is operational again, launching (manually) GuardPoint Pro on it automatically closes GuardPoint Pro on the redundant server by a spread command and recovers communication with controllers and workstations.
CAUTION: If during the swap the backup server is on failure, controllers will continue to work in stand alone mode but workstations could not run normally.
The data source must be SQL type. For duplicate data source configuration (i.e. replication or mirroring) see Chapter 4 to automatic swap to the secondary data source.
Server Settings (already supported since version 1.6.004)
- Both servers (main and redundant servers) must be provided each with an GuardPoint Pro dongle having the same configuration.
- Both PC must be defined in "Computer" screen of GuardPoint Pro.
- The main server must have in its GuardPointPro.ini file the following option: ServerRedundancy = 1
- In Multisite installations, the following option must be added: ServerRedundancyName = Name of the redundant server (e.g. ServerRedundancyName = SERVER2).
- The redundant server must have in its GuardPointPro.ini file the option: ServerRedundancy = 2
- In Multisite installations, the following option must be added: ServerRedundancyName = Name of the main server, (eg ServerRedundancyName = SERVER1).
The option ServerRedundancy allows the spread upon the redundant server startup, to stop immediately GuardPoint Pro on the server which has the option ServerRedundancy different from 2. On closing, GuardPoint Pro writes in its AME file the following line: 02/12/2004 10:26:37 Get order from 2nd server to shutdown
In Multisite installations where multiple servers can run simultaneously, the option ServerRedundancyName allows each site to have its own backup server. In addition, it allows to inform the local workstations only (and not all the workstations) about the server swap.
Workstation Settings
Workstations must be defined in the "Computer" screen of GuardPoint Pro.
When the redundant server starts, it indicates to the running workstations, via the spread, that the server with the option ServerRedundancy = 2 starts. Also, the workstations understand this message by switching to this server.
All the workstations that not running at this time, were not informed of the switch and are set by default to point to the main server. When starting, the workstation receives from the current server its “ServerRedundancy” value via the spread and points automatically towards the right server.
3. Hot Server Redundancy
Principle
Since version 1.7.001, GuardPoint Pro is able to manage by itself the failure detection of the main server and switch automatically all the components of the system to a redundant server. To do so, an application called "RedundancyChecker" installed on the backup server, monitors the main server. When main server failure is detected, the RedundancyChecker launches GuardPoint Pro on the redundant server and then closes itself automatically.
By launching GuardPoint Pro on the redundant PC, the operation is the same as described in the cold redundancy chapter, namely:
- Automatically closes GuardPoint Pro Server on the main PC, by a command sent from the redundant server to the main server via spread tool.
- All the controllers are polled now by the GuardPoint Pro redundant server.
- All the workstations swap automatically to the GuardPoint Pro redundant server.
When the main server is operational again, launching GuardPoint Pro on it (manually) automatically closes GuardPoint Pro on the redundant server by a spread command and recovers communication with controllers and workstations. To rearm the redundancy, it needs to restart manually the RedundancyChecker on the redundant PC.
CAUTION: If during the swap the backup server is on failure, controllers will continue to work in stand alone mode but workstations could not run normally.
Note: If during the swap the RedundancyChecker does not run on the redundant server, the swap could be done. The customer must ensure by himself that this application runs on the redundant server (e.g. by installing a watchdog, an application to run it as a service, etc.).
The data source must be SQL type. For duplicate data source configuration (i.e. replication or mirroring) see Chapter 4 to automatic swap to the secondary data source.
4. RedundancyChecker version 1.2 Settings
The RedundancyChecker must be installed on the redundant PC in the GuardPoint Pro folder - consisting of an exe and an ini file.
Before starting the RedundancyChecker.exe utility on the redundant PC, it is necessary to configure the RedundancyChecker.ini file. To do so, open the file RedundancyChecker.ini located in the GuardPoint Pro folder with Notepad and set the following options:
- NumRetry = 3 Attempts number before pinging the server IP address
- Interval = 5 Delay in seconds between handshakes
- TimeOut = 1000 Timeout for GuardPoint Pro to reply in milliseconds
- PingTimeOut = 1000 Pinging timeout of the server in milliseconds
- ServerName = Name of the main server
- ServerIP = Main server IP address
- ThirdPartyIP = Third PC IP address
- PathExe = Command Line to execute GuardPoint Pro
- ApplicationName = Name of the application to close, if require
The RedundancyChecker utility runs like a watchdog with the GuardPoint Pro application server. It applies a constant handshake with GuardPoint Pro on the main server each X seconds , where X is the value specified for the Interval option in the file RedundancyChecker.ini.
The timeout in milliseconds for which GuardPoint Pro is supposed to answer is set in the TimeOut option. If GuardPoint Pro did not respond after Y attempts, where Y is the value given for the NumRetry option, the RedundancyChecker begins to ping the IP address of the main server defined in the ServerIP option. The timeout in milliseconds for which the main server (named in the ServerName option) is supposed to respond is defined in the PingTimeOut option.
If the ping to the main server succeeds, it means that the PC runs but GuardPoint Pro has been closed on the main server. Then, GuardPoint Pro is launched on the redundant PC, with the PathExe option which must contain the command line to run GuardPoint Pro on the redundant PC.
If the ping fails, we suspect one of two scenarios:
a. the main server is either closed, out of order or just lost network connection
b. the redundant PC lost network connection or the network has failed
To determine which of the two cases is true, the RedundancyChecker pings the IP address of a third PC, defined in the ThirdPartyIP. It is recommended to indicate an IP address which always replies (such as router or network printer).
If the ping to the third PC succeeds, it means that the suspected scenario a) is true and the redundant PC network connection is ok. Therefore GuardPoint Pro is then launched on the redundant server.
But if the ping to the third PC fails, it means that the suspected scenario b) is true: the redundant PC network connection is in failure whilst the main server may be still working. Therefore in this case no action is initiated.
Obviously, it is possible to install the RedundancyChecker utility on the main server in the same way, to check if GuardPoint Pro on the redundant PC is running.
The ApplicationName option is optional and allows to force the process closure of a local application (e.g. GuardPointPro.exe) before launching GuardPoint Pro locally.
After the RedundancyChecker utility has detected a problem on the remote PC and then started GuardPoint Pro locally, it automatically closes itself.
Note: for installations not using the server redundancy functionality, the RedundancyChecker utility can be configured to run as a watchdog for the local GuardPoint Pro application (e.g. if you close the application by mistake). To do so, simply set in the RedundancyChecker.ini, the options ThirdPartyIP and ServerIP with the IP address of the local PC. In this way, the RedundancyChecker will not close itself after starting GuardPoint Pro locally.
Example for RedundancyChecker.ini
[RedundancyChecker]
NumRetry = 3
Interval = 5
TimeOut = 1000
PingTimeOut = 1000
ServerName = MAINSRV
ServerIP = 192.168.168.58
ThirdPartyIP = 192.168.168.60
PathExe = C:\Program Files\ GuardPointPro \ GuardPointPro.exe /us=1000 /pw=2000
ApplicationName = GuardPoint Pro.exe
5. Database Redundancy
On a duplicate data source configuration (type replication or mirroring, carried out by MS SQL), the database redundancy is independent of the server redundancy but it can be complementary. Indeed, when the redundant server has started, the system (server and workstations) can either switch to the second data source or keep its connection to the main database as long as it is available (e.g. although GuardPoint Pro is closed on the server). In this case, the system will automatically switch to the second data source only if the main data source becomes unavailable (e.g. database server off).
In all cases, after the data source switch, when the main database becomes operational again, the user must switch manually each PC to the main data source by selecting in GuardPoint Pro, the option: Tools>Switch_database
CAUTION: In this configuration, for keeping the databases identical every time, database replication or mirroring should be carried out by the database software itself (MS SQL). In database mirroring mode, only one of the two databases is available at a given moment. Only Microsoft SQL Server decides of the database availability. GuardPoint Pro does not manage either database replication or mirroring. This implies that if the backup database is unavailable at the right time, the system will enter in stand alone mode and the server and workstations will not run normally. In addition, GuardPoint Pro does not check if there are differences between the databases.
Comments
0 comments
Please sign in to leave a comment.