cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 10

NPM Design question

Jump to solution

Hi Guys

I have a "small" design question to ask

Today we have 2 NPM instances one in our corp network and one in our secure enclave, witch is a secluded portion of our network, so it would be possible to be able to cut it of and operate it autonomously in case of an attack.

But our normal procedures do that monitoring both systems simply isn't an option on a day to day basis.

So I need to design a system where we can monitor both the the Corp network and the Enclave through a single "pain of glass"

One suggestion is the Enterprise console I understand that this will be able to receive data from several systems, but as I understand this will only give us monitoring capabilities, If we need to dig deeper we have to do it on the relevant system.

Anther suggestion is to place 2 Corp APE's in the Enclave and monitor it all through the Corp system but still retaining the Enclave system, but then I fear that if we ever had to run the Enclave autonomously equipment will not be up to date on the Enclave system.

I am not sure how big a problem the last one will be, because the Enclave setup is pretty static.

Is there anybody out there that has solved this or have some design recommendations, suggestion or anything?

What are the pro's and con's and is there another solution that I haven't thought about?

We have 2 NPM setups, one with unlimited nodes (Corp), and the one in the Enclave has a max of 2000 Nodes i think

If we could do this with one setup That would be sweet

Hope you can help me a little

Regards Jens

0 Kudos
1 Solution
Level 16

Hi jens

"you can not eat your cake and have it"

Like to keep it "safe" keep  those 2 instances.

"Anther suggestion is to place 2 Corp APE's in the Enclave and monitor it all through the Corp system but still retaining the Enclave system, but then I fear that if we ever had to run the Enclave autonomously equipment will not be up to date on the Enclave system."

If you need to join those  2 instances.

I will run the SLX DB and Main Poller  from the Enclave NET & I will have the "Corp" APE in DMZ net  that can be "drop" with police base route in case of that critical isues.

View solution in original post

0 Kudos
11 Replies
Level 16

Hi jens

"you can not eat your cake and have it"

Like to keep it "safe" keep  those 2 instances.

"Anther suggestion is to place 2 Corp APE's in the Enclave and monitor it all through the Corp system but still retaining the Enclave system, but then I fear that if we ever had to run the Enclave autonomously equipment will not be up to date on the Enclave system."

If you need to join those  2 instances.

I will run the SLX DB and Main Poller  from the Enclave NET & I will have the "Corp" APE in DMZ net  that can be "drop" with police base route in case of that critical isues.

View solution in original post

0 Kudos

Our solution will be the one you suggested with an APE HA couple in the enclave.

We will handle the problem with ensuring the Enclave system is up to date with Quarterly procedures describing how to compare the Enclave nodes in the Corp system and the nodes in the Enclave system.

As it is now we rarely logon to the Enclave system so it will only be an improvement

Regards Jens

0 Kudos

That SLX DB you are talking about, does that "syncronice" 2 databases ? and if it is can it be run scheduled ?

0 Kudos

No

I talking about consolidate the corp  instances  to your  secure enclave and run just 1  NPM .

You could keep the "corp" on separate APE.

0 Kudos
Level 12

We currently have an APE in addition to the main poller and with the APE's in the enclave you can talk to them through the main poller and have a single pain of glass and create maps and groups in much the same way and you would use it much like you do the main poller but you can use one web server.

Jobs for keeping them up to date runs on the main poller.

The job for updating them on the additional poller in case of isolation is on the additional poller - because when you install the additional poller basically you run an app that sucks down everything from the main poller.

So that might work for you as well.

0 Kudos

Interesting!

But do you have any visibility in case of an isolation, you cant have a webserver connected to the APE can you?, and what of the database where is that located?

0 Kudos

Some help for you building your secure environment hopefully of some use to you.

https://support.solarwinds.com/Success_Center/Orion_Platform/Knowledgebase_Articles/Secure_Orion_env...

0 Kudos

I'd say you've already covered the bases there.  I would feel like EOC is the best choice in this case, and yes you would have to have some way of accessing the enclave web console itself on a system outside of the enclave for it to work.  Easiest answer is to just open up 80/4443 to the enclave server for users in the corp network.  If that is deemed to be too much exposure you could put up an additional web server that is linked to the enclave via port 17777 to the app server and 1433 to the database, but is accessible for corp users via 80/443.  That way the AWS can act as a sort of dmz or proxy to mitigate concerns about exposing the enclave to corp directly.

I haven't tried it before but I suspect you can even point your EOC at the AWS instead of the enclave application server directly since the AWS also runs the info service (I always like to test my really ugly SWQL queries against an AWS if I'm worried that they will chew up all the memory, that way I can bounce the web server with less impact than if I did it on the app server).

- Marc Netterfield, Github
0 Kudos

Sound like and interresting idea to pull a AWS out of the Enclave, so it would be a little bit easier to manage.

How is the EOC to install easy peasy, or should I calculate with some expert help.

0 Kudos

Unfortunately, the Enterprise Operations Console is not able to connect and pull data through an Additional Web Server.  EOC would need to be able to communicate directly to the primary polling engine of each instance via port 17777 and 443.  As you mentioned above, EOC would provide an extended layer of visibility for both instances, but not provide a single management/ administration layer.  EOC will roll up data in order to allow users the ability to begin investigation from a single, consolidated dashboard, but then drill down to deeper information by directing the user to the instance that is responsible for monitoring a particular entity.  It is very easy to install and test on a separate VM.    

0 Kudos

EOC is trivially easy to set up, typically takes like an hour from the start of install until I'm done.

- Marc Netterfield, Github
0 Kudos