This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Can Hot Standby point to a different database?

My current setup has 3 servers. My primary App server, My Database server, and My Hot Standby server. 

My current setup works as designed. If my primary stops the hotstand by kicks in immediately. However, I want to take it one step further.

My Hot Stand by server is located off site at our Business Recovery location in the event of a disaster.  However, in the event of a real disaster I'd lose my on site DB server as well.  So my question would be, While there is a Hot Standby Polling engine, Is there a Hot Standby DB server? 

 If not, Is there a way to point the Hot Standby engine to a second (redundant) Database?

  • CSpringer,

    First of all, I want to point that your setup with the HS server in a different physical location than the SQL server is not supported.  The reason for that is that in all testing, Orion is writing so much data to the SQL server that SQL becomes very sensitive to the latency between the polling server and the database server.  All testing that's been done in the past has proven that even across town, with some pretty serious bandwidth and minimal latency, SQL has bottleknecked and caused problems.  Hot Standby will still take over for the Orion server but if you rely on the HS server very long, you will see problems in the data being polled - gaps in the data, etc.  This also applies to the primary or secondary polling servers as well.

    My recommendation to you would be to move the Hot Standby server to the same location as the SQL server and use it as a short term fail over solution, just in case something should happen to the primary Orion NPM server.  Then design a true fail over solution.  For example, deploy a fully licensed Orion NPM server to an offsite location and set up SQL replication to a second server in another site.  This way, should a disaster happen, you can immidiately turn up the secondary server.  ...And there are options to automate this process as well.  This would require you to have a fully licensed, secondary Orion NPM server and SQL server to work though. 

    I hope this helps and I'd welcome any feedback that anybody else has on the subject and what they've done.

     

    Thanks,
    Jason Henson
    Loop1 Systems
    www.Loop1Systems.com

  • Jason,

     Thanks for the reply. The off site location is linked via a Gigaman  circuit so I can read/write to and from there just as fast and easy as I can write to the data center in the basement of this building. But I do understand the general reasoning why this would be unsupported as most means of getting across town are not that fast and this would present a problem for most instances.

     I understand that officially its "not supported", so if you dont give feedback on this I understand. But I'm going to ask, What are your thoughts on this?

    I do have a seprate licensed SQL box at my Business Recovery Center.  If I replicate the Database to that box weekly, In the event of a disaster, can I just re-run the config wizzard on the Hot Standby to point to that DB server (a DB server with a different name)?  

  • CSpringer,

    I think that should work fine.  I've never tested this scenario but if the Hot Standby server sees that the primary polling engine is down on the db in the data center, I would assume it would associate the polling of the network elements just fine.  It just wouldn't be an automatic solution because you would have to rerun the configuration wizard (or you could possibly run the wizard and just turn the SWI services off on the Hot Standby server).  All of this is hypothetical right now though and would need to be tested to validate that it works. 


    Thanks,
    Jason Henson
    Loop1 Systems
    www.Loop1Systems.com

  • We are in a similar situation. We have the primary engine in one Data center as well as the SQL server. The second engine is in an off site location. They are connected with dark fibre at 10Gb. Lots of bandwidth, no latency. The questions is, how do I ensure SQL redundancy?

    I can cluster the SQL, but they point to a common storage. What if the storage fails? Or the building burns down?

    Solarwinds has become a critical system in our environment. We can't tolerate the system being down for very long. The Fail Over Engine does not take care of the SQL. Has anybody used Neverfail? This is a recommendation that I found on the Solarwinds website?