2 of 2 people found this helpful
1. it's the neverfail product: http://www.neverfailgroup.com/products/neverfail-it-continuity-engine
Basically it replicates [specific] files and registry entries between two servers, manages the application start-up (and stop). and visibility on the network
there are very small sync traffic between the two, and pings to ensure network connectivity for automatic failover.
It works pretty well, but adminning systems in a FoE configuration more than doubles your workload
2. No; though you might want to talk to a real database cluster for resliency. Note: some in Solarwinds support do not recommend this because they are used to dealing with sites that do not understand enterprise database infrastructures. I find it works fine in high performance (async) replication mode, and has done for several years.
3. Yes; follow the specific install instructions for installing the FOE environment.
4. You send them from devices to both servers (WAN install) . Only the active server writes to the database, so you do not get duplicated messages in either case.
5. Yes. Depends. Low latency definitely.
 a WAN install means you have routers between the servers and update the DNS to indicate the active server. My WAN is somewhat faster than 1Gbps.
if you have a replicated database then the database sync rate (for ~40,000 objects) ~= 16Mbps, and that seems to be pretty close to the database write rate.
if FOE is either side of the link then there is really very little FOE replication (mostly logfiles and other transient things that it doesn't really matter about!)
Thank you Richard,
I need more information on question 2. Are you saying that fail over engine has ability to failover to cluster SQL database.If so then how to avoid duplicate data in both SQL. Can we go with one SQL database or do we need two SQL database for Orion failover engine.
2 of 2 people found this helpful
I have a pair of high-performance SQL servers; the orion database is mirrored between the two of them (using SQlserver replication). https://msdn.microsoft.com/en-us/library/ms189852(v=sql.105).aspx
Orion writes to one server (the primary), this is replicated by sqlserver to the secondary.
if a sqlserver fails we flip the database to the other server and it writes to the 'secondary' sqlserver.
your sqlserver DBA should be able to help -- I don't really look after that part of our install I have the DBA do it. I only know enough to be dangerous and let someone else admin it.
Just out of curiosity, how difficult was it to setup SQL Server replication for Orion for your DBA? Any lessons learned or advice for anyone attempting this?
I'm still browsing around for a automatic failover solution..might have to crack open some SQL books.
1 of 1 people found this helpful
sqlserver 2008R2 replication is quite straightforward -- we run it in asynchronous mode for performance (though it actually works quite well in synchronous mode in our environment, though with the servers now a lot further apart the write-overhead is now about 10ms)
- have two identically configured servers
- you do a backup/restore of the database
- do a backup/restore of the database logs (for the changes)
- use the wizard to configure replication
- turn it on...
At this point I'm going to note that:
2012 release notes: This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. We recommend that you use AlwaysOn Availability Groups instead.
if you can cope with losing some data then log shipping would be an alternative, or the windows fail-over clustering (I have no experience of configuring this)
note: for fail-over:
- switch to synchronous mode (really slows write performance)
- perform a fail-over (applications will be redirected automatically to the active instance)
- switch back to asynchronous mode
- update the DNS indicating the new primary server