Thursday
05Jun2008
NeverFail Basics-Part I
As part of a multi-part series I am working on, I decided it would be beneficial not only for me but for others to discuss the components built around Neverfail Heartbeat. To begin, Neverfail is a complex set of processes whose purpose is to provide high availability among windows based systems. It's hardware agnostic and "shared nothing" design allow for a robust, multi-protection level solution. With that lets visit the first and probably most important piece to a successful implementation, pre-installation environmental data gathering via SCOPE.
Pre-Discussion Definitions:
Server Check, Optimization, and Performance Evaluation to be exact. This process in and of itself captures and reports on the following criteria:
***Notably, you are required to run SCOPE prior to a production implementation to ensure environmental compatibility. In addition, installation support will not be given unless a SCOPE data collection has been run***
SCOPE must be run on both the primary and secondary before installation. Once complete the application will generate a CSV file (default location-C:\neverfail\scope\data\24 hour data) needed to create a NF license, obtainable from Neverfail's Extranet site. Licenses for the HA pair are tied to the hardware ID of the primary server. If the following are changed on the primary, Neverfail Heartbeat will fail to start:
Note-Hardware changes on the secondary, whether or not it was active or passive, will have no effect on NF licensing. If the secondary ever needs to change to the primary then a new license key will need to be generated from the NF Extranet site using the SCOPE report from the secondary.
In our next session, we will look at additional pre-installation tasks and walk through the main points of installation.
Pre-Discussion Definitions:
- Primary Identity-refers to the physical hardware associated with the source production server in the pair. The Primary will always maintain its identity as the primary but can switch between the active and passive role.
- Secondary Identity-refers to the physical hardware associated with the destination or opposing server in the pair. The Secondary will always maintain its identity as the secondary but can switch between the passive and active role.
- Active Role-Server that is visible on the network, running the protected application and servicing client requests
- Passive Role-Standby server in the pair, receiver of replicated data from active server, and is not visible on the public network
SCOPE
Server Check, Optimization, and Performance Evaluation to be exact. This process in and of itself captures and reports on the following criteria:
- Scrupulous information about your proposed HA server environment
- Server optimization recommendations to support Neverfail products
- Workload characteristics of said HA pairings
- Bandwidth measurement requirements for WAN implementations
***Notably, you are required to run SCOPE prior to a production implementation to ensure environmental compatibility. In addition, installation support will not be given unless a SCOPE data collection has been run***
SCOPE must be run on both the primary and secondary before installation. Once complete the application will generate a CSV file (default location-C:\neverfail\scope\data\24 hour data) needed to create a NF license, obtainable from Neverfail's Extranet site. Licenses for the HA pair are tied to the hardware ID of the primary server. If the following are changed on the primary, Neverfail Heartbeat will fail to start:
- Network Cards
- Processor
- MotherBoard
Note-Hardware changes on the secondary, whether or not it was active or passive, will have no effect on NF licensing. If the secondary ever needs to change to the primary then a new license key will need to be generated from the NF Extranet site using the SCOPE report from the secondary.
In our next session, we will look at additional pre-installation tasks and walk through the main points of installation.
tagged
disaster recovery in
disaster recovery
disaster recovery in
disaster recovery 







Reader Comments