Submit a ticketCall us

AnnouncementsFace your biggest database issues head-on

Our new eCourse helps you navigate SQL Server performance blocks by teaching you how to recognize and deal with the three DBA Disruptors: Performance Hog, Blame Shifter, and Query Blocker. Register today to learn how to defend your environment and fend off menacing disruptions.

Register for your free eCourse.

Home > Success Center > Network Performance Monitor (NPM) > Network Performance Monitor (NPM) Training > Free SolarWinds Training Videos - NPM > When to add polling engines - Video

When to add polling engines - Video

Updated July 26th, 2016 

Overview

This video (2:42) describes when to add polling engines and the options for deploying - distributed or centralized environments. 

 

Environment

  • Network Performance Monitor
  • Orion Core products

Video Transcription

 

Scalability is similar to adding “horsepower” to your Orion® deployment and come into play on larger Orion environments. Once an Orion server reaches around 10,000 elements, it is time to start looking at additional capacity.  In environments such as this, it is necessary to add additional polling engines to spread the load between multiple servers. This also allows a customer to scale up installed modules without the need for additional licenses for each module. Polling engines are machines dedicated strictly to gathering device statistics and can be deployed locally or remotely.  Since no two networks are the same, there are different architectures that cover both large and geographically disparate network deployments. 

The first architecture we will discuss is the centralized option. Each Orion instance can poll 10,000 elements without an additional polling engine.  By adding one additional polling engine, the “instance” of NPM can now handle roughly 20,000 elements, this is true for up to 100,000 total elements.  One of the main benefits of the centralized model is that as you add polling engines to scale up NPM, you are also able to increase capacity of the modules as well.  For instance, if you need additional capacity to monitor applications with Server & Application Monitor or SAM, adding a polling engine will increase the capacity of both NPM and SAM. 

The second option for scaling NPM is the distributed architecture.  This is typically done in larger, more geographically dispersed environments.  Deploying a distributed model is slightly more complex and requires additional planning, but in the end can provide a more fault tolerant, locally controlled monitoring solution.  This is accomplished by placing separate autonomous Orion servers at multiple locations and combining the monitored data into a single view with the Enterprise Operations Console.  

The Enterprise Operations Console (EOC) acts as a single pain of glass for multiple Orion instances. For example, if I have an Orion deployment in North America and another one in Europe, the EOC will show both instances including global alerts and events. Each instance is still separately maintained but rolls up information into a single unified interface. The administrator has the option to allow full local control over the monitoring environment yet maintain that enterprise-wide visibility.

 

Last modified

Tags

Classifications

Public