>>Hello, my name is Jez Marsh.
I'm a THWACK MVP.
I'm the founder of Silverback Systems, a U.K.-based partner.
I'm here today to talk about the Orion Platform at scale,
Go Big or Go Home.
So why should you listen to me?
Well, over the years I've worked with customers,
big and small, from a single polling engine,
all the way up to eight polling engines,
six additional web engines,
multiple different geographical sites.
You name it, I've done it.
And before I get into the content today,
let's talk about the nightmares
that can happen if you get it wrong.
Over the years I've seen more than three instances
which were proof of concepts,
and the customers were having problems
and they called me in.
I only found out that they had built
the whole thing on SQL Express and they didn't change it.
Also, I have seen times where a customer's built something
in a virtual environment,
but they didn't show the virtual team
how big all the system requirements for the Orion Platform,
and they were running them on itty bitty little VMs,
and then, sometimes it's simple as just giving them
the right resources; know where they go.
Other times, you have customers that will want
to actually upgrade their platform,
but they're behind the times,
so NPM 12.1, 12.2, they want to go up to 12.5,
well 12.4 even if they want to go back a bit.
And they find that they can't do on the platform they have.
And they call me in, and I'd actually have to say,
"Well, throw that away.
Build another one in parallel,
and then once you've got the history that you had
in the previous instance, go with the new one,
decommission the old one."
And I think the final, and in a way most egregious
problem that customers have is, they use...
They don't stick to the default polling intervals.
I've had a few customers that've gone down to
10-second polling intervals, tried to load 1,200 VMs
in there and realized why nothing happens.
Sometimes, you just have to read the instructions
to make sure you're going to get a good experience.
And that leads me into the first piece,
when you are looking to scale your platform,
the first thing you have to do is make sure you're getting
the most out of the platform you already have.
So the basics are simple: make sure that you've built your
original platform using the recommended specifications
that are on SolarWinds website.
Make sure that there's enough resources available,
especially if you're building in a virtual environment.
Many times I've seen people low-balling these the compute.
Only to find that they forget
to put it up to the recommended
when it goes out of proof-of-concept.
Usually, the simple things will give you a good foundation
and you can forge forward from there.
If you haven't already got a polling engine
or you haven't already got an Orion Platform in place
and you want to start again or start from scratch,
the first thing you need to do is be honest with yourself.
Count the number of devices you need to monitor,
have a good idea of how many interfaces you're gonna have
in your platform, and also find out how many applications
you're going to need to monitor.
Once you've got that information, have a look
at the sizing guides on the Orion website,
and then you'll know exactly what platform you need to build
to give you a good start.
But if you find that you've done all that right,
and you're struggling, maybe it's time to think about
the scalability engines and that's the next section.
When you're talking about scaling,
the first thing you need to consider is,
which fit is your business?
There are two ways to go.
You can either go straight into using
the scalability engines or you can consider using EOC,
or the Enterprise Operations Console.
So, what's the difference between the two paths?
For the additional polling engines, which is one of
the scalability engines that we're gonna talk about today,
you would consider using those first instead of EOC.
If you have a single Orion deployment, in other words,
one single big instance, and also, if you need to keep all
of your data in a single database, going straight to
the scalability engines is the way to go for you.
The second path, is if you use EOC.
Now, that's useful if you need
to have multiple Orion instances,
if you need to have a consolidated management of
those instances, and if you need data
in multiple repositories.
So, now I've given you an introduction about
the two different paths,
let's talk about the use cases for these two options.
If you're gonna go straight into using
the scalability engines, for additional polling engines,
specifically, you'd be looking at doing that,
if you're exceeding your polling capacity
on your current polling engine
or if you're looking at geographically remote polling,
so if you have a couple of offices,
but you want to make sure that you can poll them locally,
to avoid the speed of light problems of polling over a WAN.
Also, if you have a high security environment,
which means you need to poll that
from within the environment.
And finally, if you've got more than one client location.
Especially if you're an MSP, you may need
to put a polling engine in each of your sites.
Now, the Enterprise Operations Console,
that would jump out at you if you need,
a segmented management by business unit.
So, if you have a financial office in the U.S.,
and then you have an administration office in the U.K.,
that's when you might want to have multiple instances.
Also, if you have a large infrastructure with low bandwidth
between sites, having multiple small Orion instances,
all managed by EOC will help you.
And finally, if you've just bought another business,
if you've merged two businesses together,
you may have more than one Orion instance in place,
but you want to have one oversight over the whole platform,
that's where EOC will help.
The scalability engines,
what is an additional polling engine?
Now the primary function of an additional polling engine
is simply to extend your polling capacity.
If you've reached the capacity on the primary polling engine
you had when you deployed Orion,
an additional polling engine will give you the ability
to monitor more things with the license that you've bought.
As I said previously, if you need to manage devices
in a geographically diverse location,
having the additional polling engine in that site,
especially if you're talking about different countries,
will give you the ability to make sure that
the information that you have in the database,
is a real representation, especially important
when you're looking at response times.
For high security environments, like in the UK
the payment card infrastructure or PCI environment,
you may not be able to poll across the security barrier.
In that case, you may need
to put an additional polling engine
inside the PCI environments;
so you can get the information you need
without potentially exposing you to risks.
And finally, if you have a large infrastructure
and you simply can't poll everything
from a single polling engine, an APE will help you.
You can, literally, put them where you need them
and get all that information in a single instance.
With the Enterprise Operations Console,
what this is, was it's not technically a scalability engine,
it simply gives you the ability to manage multiple instances
from a single pane of glass.
For example, if you're a managed service provider,
you may need to have an instance of Orion
in each one of your customers, simply because that's
what they have contractually obliged you to do.
Also, if you have a large infrastructure,
but across multiple sites,
having an individual instance for each site,
will give you the ability to scale that site out,
but also have everything under one roof.
So, let's talk about the second scalability engine;
the additional web server.
And the primary job of this
is simply giving your Orion goodness to more people.
It also means that you can split out the IIS resources,
that you would normally use on your primary polling engine
across a different server.
Giving you more power for your polling,
maximizing what you get out of your primary polling engine.
As concurrent number of users rises,
additional web engines will help you make sure
that you aren't going to end up with users complaining,
that the website's slow or even worse, they can't get to it.
You can also put these behind load balancers,
making sure that you can control
who can access which servers when,
giving you additional capacity should you need it.
And also, one of the things that I like to do, is to suggest
putting your additional web servers inside your DMZ.
Which means that you can make sure people can access
the information you want, whilst making sure
that the integrity of your platform,
especially the database, is kept.
So, when you're looking to scale your Orion instance,
the first thing you have to do is choose your path.
There are two paths, really.
You go straight through your scalability engines
or you look at using EOC or Enterprise Operations Console
to give you additional management
over multiple Orion instances.
Why would you want to go straight
to an additional polling engine?
If you already reached your polling capacity but you have
licensing capacity available to you,
getting an additional polling engine will make sure
that you can have that without losing out.
It gives you the ability to have more,
in your single instance, especially useful if you need
to have everything in a single database.
For the Enterprise Operations Console,
if you have multiple Orion instances,
that gives you the ability to manage them all
under a single pane of glass.
It also means that you don't have to have multiple tabs open
and makes it easier for your support teams
to manage what you have.
Also, if you need to have data in more than one place,
you can't have it all in one place,
multiple instances is the way to go.
With that explained, let's have a look
at the use cases of the two. So, we've
already touched on it, but additional polling engines
will give you additional polling capacity where you need it.
Also, if you're an environment
that has multiple geographic locations, big sites,
you simply can't monitor it all
from a single polling engine,
an additional polling engine will allow you
to bring all that information into your database
and into your views.
If, like in the U.K.
with the payment card infrastructural PCI platforms,
you may not be able to poll across a security boundary.
Having an additional polling engine
inside the security boundary, gives you the ability
to monitor that information, get it securely
into the database without compromising your security.
And finally, if you have multiple client locations,
they simply may contractually bind you
to have a polling engine in that platform.
That's where an APE will save you.
Now, on to the Enterprise Operations Console,
and the use cases for that one.
If you have a need to segment your monitoring,
the EOC will give you the ability to have that information
in a single pane of glass without binding you
to polling across a WAN.
Useful if you have low bandwidth in between your sites,
but also, if you just had a merger
and you have two Orion instances in place
and you want to put them all in a single place
and monitor them, without having to have two pages
for your operations teams to look at.
The EOC would be the way to go.
The next section is,
finding out whether you do need to scale.
So, there are three simple questions
you can ask yourself and if you answer yes to any of these,
you'll need to go ahead with the scalability engine.
The first question to ask yourself is
if you're going to be monitoring more than 10,000 elements.
Second, ask if you're going to be needing
more than 1,000 agents in your environment.
And third,
ask how many web users you're going to have.
If you have more than 20 concurrent users,
you're going to need to scale out.
All right, so now we've talked
about the scalability engines.
Lets give you some more detail on what they can do for you.
So, the additional polling engine,
as I've mentioned, will just give you the raw capacity
to monitor more of what you need to have.
If you have more than one environment,
and you need to get that information to one database,
that's where an APE will come in play.
So, I've talked to you a little bit
about the additional polling engines.
So, let me give you an example, from my own experience,
of why they were needed.
I used to work at an MSP and we needed
to expand our polling capacity
because the multiple tenants that we had was too difficult
for just a single polling engine to handle.
We got another additional polling engine
and put it in our biggest customer's environment.
And we were able to save all of that polling capacity
and move it onto that dedicated polling engine,
whilst the original polling engine
was able to cope with the rest of it.
Now, over time, the other customers,
which weren't quite so picky,
didn't need their own polling engine,
they started growing their environments
and over time, it got to the point where
both polling engines were pretty at capacity.
And then, we needed to think about getting another one.
So, we had a look, and we balanced the polling,
and we realized we didn't really need to buy
an additional polling engine at that point,
we just needed to save some compute cycles
on the primary polling server.
It turned out that it was the website,
that was causing problems.
IIS was using a lot of resource,
there were a number of connections to the website
and that was growing as our customer base was growing.
So, we thought about, can we just take this away,
can we move the web content elsewhere.
And that's where the second scalability engine comes in,
which is the additional web server.
By default, around about 20 concurrent sessions
is the maximum you can handle,
depending on how complex your views are.
When you get to that point,
you need to think about getting an additional web server,
which will give you the additional capacity
to service more users at the same time.
The beauty of it is, you can add as many as you like,
and it's relatively inexpensive
when compared to adding additional polling engines,
if it's literally just the compute cycles
that the website is using, that you need to free up.
And you can further improve things by load balancing them.
Put them behind an F5, for example,
and you can make it more efficient for your users
by routing them to whichever of the additional web engines
is local to them.
If you've got users in the United States
and your polling engines are in the U.K., for an example,
it's going to be pretty slow for them.
But, if you put an additional web engine
in their side, it might be quicker.
Although, you still have the speed of light problems,
which you can't do anything about.
And finally, one of the things I do recommend,
especially if you have security concerns,
is putting your additional web engines inside your DMZ.
That means you can control which people can access it,
while still having the integrity of the back-end database.
Because it's on a different network, you can control
which ports go through it. It helps.
Another benefit of load balancing your additional web
servers is that you can actually perform maintenance on them
without any downtime.
So, if you had two additional web engines in production,
and another two additional web engines, which are passive,
you can switch everything by just changing
the load balancing settings onto the passive nodes,
do whatever Windows patching or whatever maintenance
that you need on the live, and then switch it back.
It just gives you that flexibility,
while using a different technology,
which isn't specifically SolarWinds.
With that said, I hope you found this session useful.
If you have any questions, you can always get me on THWACK,
but for those here today, I'll take your questions now.
All right, you, sir.
>>Yeah, uh, hi, yeah.
Uh, I have a really big environment.
I'm already using a couple polling engines.
So, I'm just wondering, how many can I use total?
>>OK, well, there's two ways you can find out
if you need an additional polling engine.
If you're an admin user, look at the little bell at the top
um, you'll get notifications up there,
which will say, that the polling completion is struggling.
If you need to check that,
then there's a good idea that you do,
if you go into your polling settings
and have a look at the completion rate.
If there's anything below 99, you need to look about it.
Because if you have problems,
you may end up losing some of your metrics
and that's never good for a monitoring system, right?
And as far as your second question,
about how many you can have, you can have a hundred.
So, you got plenty of space to grow.
>>Thank you.
>>OK. You, sir.
>>Yeah, so I've read a bunch of articles
about stackable engines, both on THWACK
and on the support community.
Can you tell me a little bit about that?
>>OK, so, stacking your polling engines
is supported, OK.
So, if you have your primary polling engine
and you have compute available, you can
put three additional polling engine licenses on that server.
So, effectively, quadrupling your capacity on that one box.
You need to have the compute available.
Otherwise, you're going to struggle.
If you have an additional polling engine
that you need to stack, same rule applies.
You can have another three licenses on top of that,
to give you four times the capacity.
But, when I speak to my clients, especially in this age,
with virtualization being everywhere,
if you need additional polling engines,
just build another server.
It gives you the ability to control
where your polling's happening.
And if you need to put Windows patching on, for example,
you can fail, if you have the capacity that is,
you can fail all of the polling from one polling engine
you need to patch, to a different one;
get that server patched up
and then put everything back where it was.
And you can use custom properties to find out
exactly where the parent polling engine is
to make it easy for you.
So you're not guessing.
>>Thank you for your time.
>>OK, you, sir.
>>Hey, uh, so I kind of got distracted
with some personal projects over the past couple of years,
and I'm a little behind on my upgrades,
I'm running NPM 12.4 but it's all on Server 2012 uh,
could you, kind of give me some advice on that?
>>OK, um, you're in a difficult spot, firstly.
>>Yeah.
>>If I was asked to do this for you.
The first thing I would recommend you do, is throw it away.
Not literally, but the system requirements
from 12.4 onwards have changed.
Your current operating system, is not supported.
So, you'll need to provide additional servers,
new servers, to replace what you have.
So, what I would do, is get some trial evaluation licenses.
You can reach out to your SolarWinds sales rep for that.
And then, build something in parallel.
>>Sure.
>>Make sure you've got everything monitored
in the new platform, that you had previously
and then when you've got the right amount
of history in your database, 30 days or whatever it is,
then you can switch all your users
to looking at the new platform
and then you can decommission the old one.
That would be what I would recommend.
>>Uh, all right, cool thanks, man.
>>That's all I've got time for today,
but I thank you for your attention.
It's been a privilege to talk to you today.
If you have any other questions, reach out to me on THWACK
and I hope you've enjoyed it.
Thank you.