Here at SolarWinds we offer a product called EOC - or Enterprise Operations Console. EOC is used when you want to deploy Orion in a distributed management architecture. Today I received a question about when you should think about deploying such an architecture so I thought I'd take a few minutes to write on the subject.


Before we go into the reasons to deploy such an architecture we should agree on what exactly a distributed network management architecture is. For the purposes of this conversation, a distributed network management architecture is any NMS that has more than core. The core being the main server and/or database. In many cases these systems are distributed geographically but not always. In almost all cases, because the network management data is being stored in more than one system you'll make some tradeoffs with regards to global reporting capabilities. These tradeoffs can be mitigated but not without additional investment of time and/or resources.


There are three primary reasons for deploying a distributed network management architecture. Let's explore each individually...


Scale - the reason that most organizations deploy a distributed management system is that their network is so big that a single core system simply can't keep up. With Orion (for instance) this typically happens when the network grows beyond around 50,000 managed elements. In a network like that, the database backend for the NMS (SQL in Orion's case) simply can't keep up. Some of the data that Orion collects (like NetFlow and Syslog for instance) can be quite database intensive from an I/O standpoint.


Geography - if your network has two logical hubs, for instance if you have networks in Europe and Asia with data centers in each, it might make a lot of sense to deploy a geographically distributed NMS. When you're polling a large network across the WAN, especially an expensive and possibly high-latency WAN, you can experience a signficant degradation in data quality and performance visibility. Additionally, if the WAN connection is down you aren't able to collect data for those remote networks. Add to that the cost of polling for data across inter-continental links and distributed NMS suddenly become a very good idea for these types of networks. In these cases the question is usually not whether or not to distribute but whether or not to rollup the results into a product like EOC.


Disaster Recovery (DR) - another common reason for deploying your NMS in a distributed model is for disaster recovery. We see this commonly within companies that have DR sites or redundant data centers. These are special cases and so we'll not go into the details here.


So, in a nutshell, if you've got Orion and you're wondering whether or not you should deploy EOC. Ask yourself these questions:

a) Would I benefit from distributing my NMS geographically?

b) Has my NMS grown beyond what I can build a SQL Server to support?


Ping me back if you have any questions/comments and be careful out there...

Flame on...