Managing and monitoring a single IT operation can be a pretty complex operation, and we make lots of great tools to help simply that process, but what to do when you’re a Managed Service Provider (MSP) and you have multiple independent IT operations to oversee.
There are a couple of different deployment scenarios for MSPs to take advantage of our Server and Application Monitor (SAM) product, as well as its sibling products, including the following:
· IP Address Manager (IPAM)
· Network Configuration Manager (NCM)
· Network Performance Monitor (NPM)
· Netflow Traffic Analyzer (NTA)
· User Device Tracker (UDT)
· VoIP and Network Quality Manager (VNQM)
· Web Performance Monitor (WPM)
The Centralized Deployment model is based on a single, centrally located SolarWinds server running SAM (or one or more of the other products listed above) and configured to monitor/manage nodes remotely.
There are two ways in which remote nodes can be monitored from a central server.
The central server can connect directly to the remote nodes and a number of protocols and ports may be needed to support this. Two commonly used protocols are Windows Management Instrumentation (WMI) and Simple Network Management Protocol (SNMP). An SNMP connection works well in this fashion for network devices, but WMI connections for servers are a bit more complicated because of the dependencies on Remote Procedure Calls (RPC). If the remote nodes are within the same enterprise, then RPC connectivity may not be an issue, but RPC is rarely capable of traversing a firewall connection. If you are managing a remote network via an always-on Site-to-Site VPN connection, then RPC/WMI may be possible across the VPN. Alternatively, enabling SNMP on the servers can provide a methodology for monitoring.
A second option is to deploy pollers to the remote sites. Poller remotability is useful when there is a large number of nodes to monitor on a remote network. This offloads the WMI or SNMP traffic from the site-to-site connection by performing those tasks locally and then relaying that information back to the central SolarWinds server. This information is sent directly to the instance of SQL Server supporting the main SolarWinds server, so there are also some firewall and port considerations with this method as well. As a result, this methodology is not well-suited to the MSP scenario, but may work well within a single multi-site enterprise. There are also latency issues with the database communication to be aware of as well.
The Decentralized Deployment model provides some advantages over the Centralized Deployment model by eliminating the challenges involved in supporting RPC/WMI or SQL traffic over a site-to-site network.
In this model, independent SolarWinds servers running SAM (or other products) are installed at the remote sites, and the Enterprise Operations Console (EOC) is used to provide a centralized, aggregated view of the individual remote sites. In addition, the EOC can be customized on a per-operator basis, so operators that are responsible for only some sites, can have their view customized to just those sites. The EOC can also be filtered by the particular SolarWinds products in use. For example, Network Administrators may wish to focus on the content provided by NPM, NCM, IPAM, and NTA, while Systems Administrators can be focused onto the information provided by SAM.
Finally, if you’ve implemented multiple SolarWinds products in this family, you can also choose a hybrid approach. You can implement one or more products with a centralized model and others with a distributed model, and regardless of the model used, the EOC can connect to all of them.
The diversity of deployment options makes monitoring and managing independent customer sites a breeze for MSPs who implement SolarWinds products. For more information about the ways SolarWinds can help MSPs manage customer operations, please visit the website for SolarWinds Managed Service Provider Software.