Redundancy Overview
The primary goal for CygNet Redundancy is to ensure high availability for CygNet services, regardless of the complexity of your CygNet setup. The CygNet Redundancy solution is designed to achieve continuous operation of all CygNet services in the wake of component failure in the system, whether failure is due to normal operational transition of data from one location to another (via replication to move data from a primary server to a DR server, or backup, or forwarding, etc.), or due to an unforeseen natural disaster.
A high availability redundant system can be simple or extremely complex. You might run CygNet locally or across multiple data centers. You might run a pair of redundant servers, or two servers in different data centers, or locally redundant servers in multiple data centers, which are themselves redundant. Add to this, and you might need to support multiple networks (for example, the main production network, a business network, a test network) participating in a CygNet Redundancy configuration.
To accomplish this potential environmental complexity, each site in your CygNet setup runs on a unique domain and each domain has a specific role: Active, Local Standby, or Data-Center Standby.
When a failover is performed manually (triggered via human intervention) or automatically (triggered without warning), all sites will swap domains, and assume a different role. The benefit to this model is that clients will always connect to the same domain, regardless of where the domain is running, so they don’t have to make any changes as the result of a failover. The failover process involves stopping all the services and restarting them on a different domain, swapping to another domain, and assuming another role.
CygNet redundancy operates on top of the CygNet replication model and is supported by underlying replication functionality, although replication is disabled for all services in a redundant environment. See Configuring Redundancy for more on this.
CygNet Software supports high availability across servers in a redundant environment through the following areas of focus:
- Centralized Configuration
- Failover Readiness and Replication Status
- Failover Duration and Performance
- Awareness of a Failover Event
- Elimination of Replication Scripts
Centralized Configuration
All configuration work required to set up redundant pairs, redundancy mode for services, and source and replicated services is centralized in a familiar CygNet workflow.
In a complex redundant environment it is possible that you might have several different CygNet domains running different sites, or rather different copies of the same site. This might entail a CygNet site hosting 24 or more services, and running multiple copies of that site on different domains, with some sites acting as the primary production site, some as the backup or test site, and some as a business site. Each site in the environment has multiple services; each service has its own configuration file. Manual configuration of such a vastly complex system would be prohibitively time consuming.
CygNet provides two administrative tools to simplify this mass configuration work allowing you to define all domains, servers, sites, modes, and keywords at play in one central place. The tools are the CygNet Config File Manager and the CygNet Redundancy Editor.
CygNet Config File Manager
|
The CygNet Config File Manager is a configuration file management tool used to centrally manage all configuration files in your CygNet system (from both local and remote servers) even if you aren’t currently running the application on the host server. The tool will allow you to edit (via manual and mass-modification options) and validate your configuration files in one central location. The CygNet Config File Manager is stored in the CygNet\Bin directory (ConfigFileMgr.exe) on the host server.
|
CygNet Redundancy Editor
|
In addition to configuring the keywords in your service configuration files, it is necessary to define the redundant relationships between the servers in your CygNet setup.
The CygNet Redundancy Editor is a configuration tool where you can define the relationships between the servers, hosts, and sites in your redundancy environment. The Redundancy Editor is also where you set up the trigger conditions that will initiate the auto-failover process for each domain in the redundancy environment. Once all redundant relationships are known by the system, you can execute failover between machines, stop and start sites, and allow servers to switch the domains on which they are running, and support high availability across data centers. The CygNet Redundancy Editor is accessible from the RSM service pane in CygNet Explorer on the primary host server. Once relationships are configured you can access the editor from any RSM in the redundant environment.
|
Once service configuration files and a redundancy definition for all sites are configured the system will use this information to make good decisions about how to execute a failover and what the downstream consequences will be. Each service configuration file will contain everything it needs to run in any mode. When a redundant service starts, the RSM will tell it what domain to run in and if it’s replicating, where to replicate from.
Failover Readiness and Replication Status
Once redundancy is configured, it's important to know what's happening in your system, to give you confidence that replication is working, that all data is getting backed up appropriately, to the right place, and in a timely manner and that your services are ready to failover.
The following tools will give you that visibility and confidence that redundancy, failover and replication are working as expected, the CygNet Redundancy Dashboard and the CygNet ReplValidator utility.
CygNet Redundancy Dashboard
|
To provide visibility into the redundancy, failover and replication process, a customizable CygNet Redundancy Dashboard is available in CygNet Studio. The dashboard shows every service in your system, on which domain it is running, and if it is standby mode, whether it’s ready to become the active service. Other key pieces of information available on the dashboard include each service's status, the direction and status of replication, the system's readiness to execute local failover, and the system's readiness to execute data-center failover. Note: The CygNet Redundancy Dashboard comprises several sample CygNet Studio screens and script files found in the Samples\Redundancy Dashboard folder of the CygNet source. The Redundancy Dashboard screens utilize VBScript and the CygNet COM API to gather the necessary information from services to display on a CygNet Studio screen. These sample files are not part of the CygNet product and are provided for your convenience only. Feel free to copy and modify these files to suit the requirements of your own CygNet Redundancy environment. The Redundancy dashboard is built in CygNet Studio so you can modify it, and add information that is meaningful in your environment and to your enterprise.
|
ReplValidator
|
Another tool for monitoring replication is the ReplValidator utility, which validates the replication process by comparing the records of a replicated service against its source service, and determining how many records differ between the replicated and the source service. This utility is a replication validator that can be used to compare all services except the ARS, RSM, and VHS to identify any problems with your replicated data.
|
Failover Duration and Performance
The amount of time it takes to perform a failover is hugely dependent on the size and configuration of your system. A system with 10,000 devices in its UIS is not going to failover as quickly as a system with only 100 devices. A system running on older hardware and operating system is going to be much slower than a system running on a high-end newer server. CygNet Redundancy endeavors to perform local and data-center replication and failover as quickly and as efficiently as possible using minimum system resources.
Awareness of a Failover Event
CygNet is fully aware that a failover event is occurring. This means that when a failover is initiated, all facets of CygNet (both client-side and server-side) are aware of that action, and a full resynchronization is not required in order to catch up or recover after the event. This also means that the system is aware and prepared to change the direction of replication, if needed, allowing for forwards and backwards failover between local and remote data centers within a relatively short period of time.
Recovery of a failed service is completely automated, and all you need to do is get the machine up and running again after a failover.
Elimination of Replication Scripts
CygNet Redundancy provides a failover solution that eliminates the need for scripts. In the past users who wanted to automate a failover often had to run a set of scripts to copy configuration files, stop sites, and start sites. CygNet has taken that complex failover workflow and built it into the CygNet product, so that now once you have your configuration files and a redundancy definition configured, you can perform a failover with the click of a button and CygNet manages all the changes that need to take place.
More:
