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

Global NPM Deployment

Our company has sites all around the globe. I currently have 3 active polling engines and 1 hot-standby all polling from our headquarters in Maryland. We are looking at distributing the polling engines to our hub site locations within each region (Asia, Europe, South America, and US) but leaving the database in Maryland. The question is if other users do this today and if any problems or issues come up in sending the SQL data across the WAN. Today we obviously do ICMP/SNMP traffic accross the WAN and have not had issues. I was wondering if SQL would run into any issues if ICMP/SNMP are fine today.

Any ideas or suggestions would be appreciated. The end goal is to have regional pollers with potentially the Netflow Module purchased for each so Netflow wouldn't need to be sent all the way back to Maryland as well.

Find more posts tagged with

Accepted answers

All comments

cdoyle

Hi Brian,

Setting up your polling engines to write to a SQL server in a different geographical location could lead to all sorts of problems. Generally, SQL writes aren't as forgiving as SNMP polls

A better option to allow yourself to poll all of these locations 'locally' would be to use different Orion installations at each location, and then an EOC installation to monitor all of your locations.

You can get more information about EOC here: http://www.solarwinds.com/products/orion/eoc/

Please feel free to contact our support or sales teams to discuss your options for polling an environment like this

Cheers,
Caroline

brian_duvall

I haven't noticed that before but it looks like an option.

Couple questions:

1) Aren't the updates to EOC still SQL writes going across a WAN? Even though they may be scheduled, wouldn't that have same issus as if we simply had a remote poller sending its updates constantly back to the db?

2) If the EOC doesn't get constant updates and our NOC is doing is monitoring from the EOC, if a node goes down on a remote poller...how long would it take the EOC to find out? I am worried alarming would be slowed down by this method.

3) Speaking of alarming...for all the customized pollers/advanced alarming/etc that I have configured...if I have multiple databases around the globe..would I have to recreate an alarm on every poller or does the EOC push updates to the remote databases so that an alarm only needs to be created once. Wouldn't want to do the same work 4 times.

Definitely looks neat but it seems like data would have to travel across the WAN anyway so wanted to see what type of metrics you have on how it improves performance.

cdoyle

EOC requests summarized data over the WAN, using our Information Service. The traffic required to get these sumamries is much smaller than would be required to read/write to a SQL server over a WAN, and its been designed to run over WAN links.

As for alerting - the Orion servers at each location would be responsible for the alerting at their locations. As for doing the alert/poller creation work 4 times - you can always create the advanced alert / universal poller once, then export it and import it into your other servers

brian_duvall

Thanks for the reply.

This is something I will need to dig deeper into the details to find out what "summarized" data is sent, how often its sent, and what type of customizing can be done.

Not digging the repeats of alerts/polling but that is fine..plus I assume I can't keep historical data on nodes that I would need to send to the different regions so that would be a large pain. Every custom attribute I create I would need to do 4 times...I think I will hold off on EOC til I absolutely have no other choice. Seems like a lot of extra work to keep everything in line.