Submit a ticketCall us

Quickly Address Software Vulnerabilities
Patch Manager is an intuitive patch management software which extends the capabilities of WSUS and SCCM to not only patch Windows® servers and workstations, and Microsoft® applications, but also other 3rd-party applications which are commonly exploited by hackers. Learn More.

 

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

When to add polling engines - Video

Created by Jennifer Kuvlesky, last modified by Lori Krell on Jul 26, 2016

Views: 26 Votes: 1 Revisions: 4

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
13:47, 26 Jul 2016

Tags

Classifications

Public