For those of you familiar with the Enterprise Operations Console, you may be familiar bshopp previously written, similarly titled article , which explains the function and purpose of EOC. That article was a big hit among users so I have decided to write up something similar for our latest release of EOC 2.0.
When discussing the Orion Suite of products with customers, we often get the question, “how does Orion scale?” Customers these days may have very different reasons for asking this question or different ideas of what scale means to them.
The answer is that SolarWinds provides multiple methods available for customers to choose from:
- Scaling horizontally or scaling up - If customers are scaling the number of elements within a single instance of Orion, SolarWinds provides the use of Additional Polling Engines to quickly expand the overall capacity.
- Scaling out - Whether it is the way in which the client runs their business such as a MSP, a customer has acquired additional instances of SolarWinds due to mergers or acquisitions, or any other number of reasons, customers may have what we refer to as a distributed model of deployment. This means the clients environments consist of multiple separate Orion Instances running throughout their infrastructure. The Enterprise Operations Console is the perfect tool to roll up data from each distributed instance.
In this post, we are going to discuss the Enterprise Operations Console 2.0 or EOC for short. Take the below first graphic, you have a worldwide network with teams responsible for managing their respective region, so an Orion installation resides in each; North America, EMEA and APAC.
EOC’s main functionality is to aggregate data from multiple Orion server installations and display that data in a similar fashion as the Orion Web Console. As an example, the global NOC/ Management Team may require a comprehensive view of all entities into a single dashboard for a representation of status, current alerts, and need the ability to run reports across the worldwide environment. The Enterprise Operations Console provides this visibility for you. Administrators even have the ability to create customized accounts and restrict what data each Orion EOC user is permitted to see. These restrictions can be set on an individual basis by customizing user settings and on a group basis by defining roles.
Now, the EOC 2.0 web console has changed slightly from the prior version as you can see in the screenshots below. The previous version of EOC is on the left, and the latest version of EOC is depicted below on the right.
Below is a quick touch on some of the new features and improvements. Stay tuned for more posts with additional details around these features.
- Improved Data Collection: Live on-demand polling and immediate display of data from distributed Orion Instances. (Discussed more below)
- Improved & Updated UI: EOC 2.0 is now built on the same framework as other members of the Orion product suite. This provides:
- An improved UI, with familiar navigation, icons, and controls.
- Access to Orion features such as High Availability including multi-subnet deployments (WAN/DR), and the ability to implement Additional Web Servers with EOC.
- New Status Rollup: View status of any Orion entity from distributed Orion sites with the unique Enterprise Summary Tiles.
- Improved Search Functions: Utilize Search integrated into the Navigation or utilize the Asset Explorer for pre-filtered searches within Enterprise Summary Tiles.
- New Alert Options: Input notes and acknowledge alerts from EOC.
- Global Reporting: Create and customize global reports with easy selection of desired sites.
- New Map Options: Import Maps from Orion Instances to display status in EOC NOC view. Use the WorldMap resource to display consolidated view across the distributed environment.
- PerfStack™ in EOC: Perform advanced analysis of issues by pulling entity data from multiple sites into a single PerfStack™!
Note: There is no upgrade path from EOC 1.6.x to EOC 2.0. You may run both these versions in tandem if desired, however EOC 2.0 will require a fresh install on a new server and a new database.
These changes were done based on feedback from you, our users, who were looking for an update to the UI, more flexibility with the tool, and something up to the standards the rest of the Orion Platform has executed upon with recent enhancements.
One of the common misconceptions about EOC is that it pulls all the data from each of your Orion servers into the EOC database. In actuality, EOC pulls high-level information such as current status, alerts, events, and more. Investigating further or drilling into elements within the EOC web console would then seamlessly redirect users behind the scenes to the local Orion instance that entity is actually being monitored from.
Let's walk through an example. Below you can see that I have a number of issues in my lab environment, and I will select a node entity that is in warning. This will populate the asset explorer with a pre-filtered list, and drilling into the device will actually take me to the device details page on the local instance where that node is being monitored from:
I can now continue further investigation or go right back to my EOC global view.
Now that we have gone through a high-level of what EOC is, let's dig deeper into how it works. In versions of the Enterprise Operations Console prior to 2.0, EOC contacted remote Orion instances at regular polling intervals in which it collected all current statistics based on the most recent polls. So by default, every 5 minutes, large subsets of data were retrieved from the remote sites and stored into the EOC database. The overview of the previous version can be reviewed here: What is the Enterprise Operations Console (EOC) & how does it work?
The problem was that even with decreasing the polling intervals, we were never able to achieve real-time polling or real-time display of that data within EOC. Very often, the data presented was well behind what was actually being detected at the local instance/site.
Delays in status and alert notification presented a serious problem for EOC users, therefore resolving this issue was extremely critical. EOC 2.0 now leverages a function called SWIS federation which executes only the queries necessary determined by the content of the page being viewed. In essence, Federated SWIS allows us to pull only the data we need, when we need it.
Depicted below is a more technical breakout of this first image. Each instance may contain different products, may be different sizes, and may be geographically dispersed.
With EOC 2.0, remote Orion SWIS services register themselves with EOC's federated SWIS service, thereby exposing their data through a single SWIS interface. When a user/client accesses the website and performs a function, a SWQL query is sent to SWIS on EOC. Here it is analyzed to determine what servers can satisfy the query. SWIS will then exclude any servers that are not necessary, forward the query to the appropriate Orion SWIS instances, combine the results from each, and send the aggregated results back to the client.
This process is completely transparent to the user and is able to run much more efficiently over constantly pulling copies of data, from each instance, into a database, and then running additional queries to provide the results. Federated SWIS performs all the heavy lifting, aggregating the data, and allows us to display that data exponentially faster than we were able to before.
EOC 2.0 will be able to highlight Alerts, Events, and Status from any of the following entities:
- IP SLA Operations
- NAS Volumes
- WPM Player locations
- Storage Arrays
- Virtual Clusters
- Virtual Datacenters
- Virtual Hosts
- Virtual Machines
- VCenter Servers
- And more...
Here are a few posts that can likely add additional insight into the flexibility of EOC 2.0