Orion Architecture

Legacy Page

This blog was posted in 2011 and is no longer accurate.  For the latest information, check out the following resources:

SolarWinds Orion Platform Scalability Guide

Orion Platform Architecture and Deployment Options Video

This blog recaps in relatively simple terms and diagrams, the basics of Orion’s architecture.

 

It is obviously not exhaustive in terms of the products and the deployment combinations, but it will hopefully give you the basic rules so you can easily derive and adapt them to your particular Orion deployment.

 

This blog is designed to help you getting rapidly familiar with most of the concepts and terminology but does not replace the architectural considerations described in each product’s user documentation set.

 

It is also a good set of pointers to many excellent blog postings that have been written in the past on all these products and components. Just follow the links…

 

The “*” in front of the names in the diagrams below, denotes commercial products. Boxes without “*” are modules that come with the Orion infrastructure and cannot be bought (e.g. Core).

 

I hope you’ll enjoy it and like always, post your comments and questions here, we’ll try to respond to them and improve this blog.

 

Basic software architecture

 

 

image_thumb_325087C1.png

 


 

Scalability: Growing an instance of Orion

 

  • With the Additional Web server (more users)
  • And the Additional Polling Engine (larger/more networks)

 

image_thumb_4E380DA0.png

 


 

Scalability: Consolidating multiple instances of Orion

 

  • EOC can be used for scalability or organizational needs (e.g. regional and national responsibilities; visualization offered at both levels)

 

image_thumb_115D151A.png

 


 

Segmented deployments

 

  • Avoiding VPN accesses with the Additional Web Server

 

image_thumb_70D5D567.png

 


Standalone products: APM, UDT, IPAM, NCM, SEUM

 

 

image_thumb_3D999BFE.png

 


 

Standalone products (shared DB server)

 

  • It is possible to host several SQL Server databases on the same physical database server
  • We do not support two instances of Orion products sharing the same database, but multiple Orion database can share the same SQL Server host if it is appropriately sized
  • We recommend to run the DB Server on a physical server (not a VM)

 

image_thumb_5629394E.png

 


 

Highly Available Architecture: Orion Fail Over Engine (Understanding the Orion Failover Engine Architecture) delivers several levels of protection

 

 

image_thumb_4E9DC9E1.png

 

 

MSP-type deployment

 

  • Today, there are two recommended ways to deal with MSP-type deployments of Orion, where an MSP manages Customer networks that have potentially overlapping IP Addresses

 

NAT-based deployment: Network Address Translators translate the customer domain addresses, so that they are all unique from an Orion perspective

 

EOC-based deployment: a full instance of Orion is deployed per Customer and they are consolidated at the MSP level by EOC

 

  • NAT-based deployment

 

NAT eliminates overlapping IP addresses

 

Makes identifications of managed devices more complex because the translated IP’s don’t make sense to report readers. This can be addressed by populating custom properties with IP’s or Names that will not be affected by any translation.

 

image_thumb_4A6A4303.png

 

  • EOC-based deployment

 

image_thumb_42922A94.png

       

  • More on MSP deployment in general and multi-tenancy in particular here
Parents
  • Solarwinds people,

    Looking over these diagrams and something is sticking out at me.  You have a heavy reliance on scaling CoreDB sql services UP and not out.  Are their any expectations that you'll start to use a myriad of specialized services to accommodate to the scale of your customers? Ex, Memcached, NoSql, application routing.

    Additionally, more web services don't fix many problems.  You need to allow web gardens for application pool distribution.  Too many times i find the entire system under lock because of a long running process in the application pool. 

Comment
  • Solarwinds people,

    Looking over these diagrams and something is sticking out at me.  You have a heavy reliance on scaling CoreDB sql services UP and not out.  Are their any expectations that you'll start to use a myriad of specialized services to accommodate to the scale of your customers? Ex, Memcached, NoSql, application routing.

    Additionally, more web services don't fix many problems.  You need to allow web gardens for application pool distribution.  Too many times i find the entire system under lock because of a long running process in the application pool. 

Children
No Data
Thwack - Symbolize TM, R, and C