Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Polling SNMP from 2 Separate Orion Instances

We are contemplating turning on a secondary environment which is a exact copy of our primary instance. What would be some of the concerns in regards to polling our network devices and such twice at the standard polling intervals.

Also, what are some ideas to keep the two separate databases in sync with one another a side from the manual effort of updating 1 after the other?

Find more posts tagged with

npm monitoring

snmp polling

Accepted answers

All comments

derik.pfeffer

jovazque,

This question is not uncommon with Larger Organizations who want an Active/Active Polling Environment. Can you share what your goals are by standing up a parallel instance? I can then share some comments on what I have seen other Clients have done to accommodate their requirements for such an environment.

Best Regards,

Derik Pfeffer

Loop1 Systems: SolarWinds Training and Professional Services

LinkedIN: Loop1 Systems

Facebook: Loop1 Systems

Twitter: @Loop1Systems

d09h

I did exactly that when we opted not to use Failover Engine. For that matter, NetQoS and Cacti also polled the devices (along with both SolarWinds deployments). No gotchas, but certainly an investment in time compared to an automatically synchronized setup (with SQL log shipping). In the latter case, it's an investment in time up front. Recreating views and duplicating pollers/ reports/ queries is certainly time-consuming. Don't want to plan to recreate something and then never get back to it when priorities shift.

I would add that SolarWinds admins can appreciate the importance of keeping both sides looking alike. WIsh I could say the same for power users (people with node management rights, ability to create views). Pretty easy for things to get out of synch. As the saying goes, hard work pays off eventually. Procrastination pays off right now.

jovazque

Essentially, we are looking to have the secondary instance act as a back up/ test area for new modules and upgrade features. During our last attempt to try an in place upgrade, we lost our monitoring environment for 12+ hours. This did not go over well and we created a "test" environment from cloned images of our primary to try upgrading again while having sight into our infrastructure devices.

The secondary's main roll would be to provide infrastructure monitoring of our enterprise's devices during maintenance windows and in the event of server outages on the primary instance. Its secondary roll would be as a test ground for new modules. Similar to a Lab Environment

dgsmith80

Don't forget that if they are separate systems then you will need duplicate licenses for the replica environment. If this is just going to be a lab / demo environment then you could speak to SolarWinds or your local partner about lab specific licenses which are a lot cheaper.

In terms of getting the systems synced, you would start by duplicating the existing database and following more or less the instructions for migrating to a new IP Address, but be warned you do need to make changes to the database to make sure they are two separate instances and remove and connectivity between them.

Like Derek said best to give an idea of what your end goal is and then let some of the people here give you some guidance on best approach

rschroeder

What reasons would there be for duplicating your environment instead of using a Failover solution from SW?

I purchased the NAM licensing last fall, which includes the Failover Engine. Once that's set up, polling and reporting continues even though your Main Poller and APE's may be down.

Isn't that the solution you really want? It looks a LOT less expensive than duplicating your entire license environment.

derik.pfeffer

@jovazque,

All of these responses are good input. If you are looking for 100% coverage for your existing environment during upgrades, you can simply stand up and replica and use the first DB to Seed the secondary. Just remember that you will need to manually keep them sync'd following the initial copy. This does cost $$ for the secondary licenses, but would allow you to monitor existing environment, test upgrades, test additional products without impacting you production system. I would recommend keeping the alerts on the secondary system disabled as to not flood yourselves with multiple alerts for the same issue. If you just had a couple of critical systems that needed monitoring while you are upgrading the production system, then you could look at a lower license level to cover those items and not a full copy. I hope all this info from the forum is helpful in making your ultimate decision.

Best Regards,

Derik Pfeffer

Loop1 Systems: SolarWinds Training and Professional Services

LinkedIN: Loop1 Systems

Facebook: Loop1 Systems

Twitter: @Loop1Systems