Enterprise layout for NPM, NCM, IPAM, etc

With 650 devices on your network, it's highly unlikely that polling capacity is your issue. In any case, even if you do want additional pollers, you're better off placing them at the same site where the SQL server is located. The polling does not generate much WAN traffic, but trying to communicate between the pollers and the Orion SQL database across the WAN will kill your performance. What do you see when you go to Settings/Polling Engines?

campbech‌

Do you have a requirement to split up the monitoring? Unless you have a special requirement, or some seriously small WAN links between sites, 650 devices should be easily monitored on your existing platform. I'm running:

• a single server (VM) for NPM/NCM/IPAM/SAM/NTA with 4 CPUs and 8GB RAM
• a single server (VM) for the NTA DB with 2 CPUs and 8GB RAM
• a single server for the SQL DB
• ...while monitoring over 1500 devices.

That said, if you want to split things up, you should install an additional poller at each site and configure it to monitor the local devices.

As for the performance issues (USUALLY! SQL related in my experience), there are some tuning tips in the admin guides. You should review those first for tips on how to improve your performance. There are also several posting on here for certain performance enhancement.

D

+1 for suspect your current server or SQLserver database is not right-sized. the SQL server<>poller bandwidth is >> poller<>device bandwidth => adding additional pollers will only make you more unhappy. springing for 6 pairs of SSD for mirrored tempdb, log, and SQLServer data will make the server a lot happier

What is your current server config?

As RichardLetts‌ said, it's likely that your database is strangling response time, if by speed you're referring to the responsiveness of the Orion website. I would definitely log a call with support and ask them to go through your database host and storage IOPS are up to the task.

If it's speed from a response time perspective seen to nodes at your remote sites, as polled from your central server, then this is just a symptom of having poor connectivity between your central installation and the remote sites (polled over the internet, I expect?).

If you're dead set on breaking out your pollers then you have two basic options:

1. Additional Polling Engines at each hospital, updating a central database (not ideal considering your site links are potentially suspect).
2. Full blown separate instances per hospital, using Enterprise Operations Console to consolidate the data (could be more expensive, depending on your licensing source).

With option 1, you'll have an Additional Polling Engine at each hospital, with the relevant modules installed (NPM/SAM/NCM etc). You then move the relevant nodes onto each local poller and then these pollers will update the central database directly. The benefit here is immediate; all data in the database is from the local poller's perspective BUT you do have the downside of a single point of failure: the main database itself.

In addition, assuming you find out that your current database host is not fit for purpose and your site links are of adequate speed, you should consider using a cloud provider for the database host. As your hospitals are likely to be split over a wide geographic area. I'm not sure if there are any whitepapers knocking about on this site about implementing SolarWinds partially in the cloud, but with the right sized AWS instance you would have all the IOPS you need to ensure the website is responsive, plus you could couple this with using an Additional Web Engine, also in the cloud, to improve things further.

For option 2, you'll be looking at multiple instances of SolarWinds, multiple licenses (and renewals) but you'll have the peace of mind that everything you see is from a local poller. EOC does have limitations when it comes to setting up views, but since I expect this will be a centrally managed solution, it will do the job just fine.

It's hard to recommend one or the other, as you have a relatively small number of polled devices. If you find the database needs some love, you'll likely be OK with option 1. If you find that the links between the sites is the issue (coming from the response times seen as being the 'speed' issue you mentioned in the OP), then option 2 would be the best bet.

Phew. Long post, but I hope it helped!