Multi Subnet Hybrid Cloud HA deployment

Hi Everyone,

I have the following query.

Current Setup:

We have a standalone Orion server(2017.3) with modules such as NPM, NTA, NCM, SAM, UDT, VMAN, IPAM for 230 servers and 450 n/w devices. We have a SQL server 2014 for Orion DB and Fastbit DB installed in the Orion server for NTA.

Requirement/Plan,

We have plans to upgrade the current environment to the latest version and also setup a HA for our monitoring solution. Client wants the HA to be in Azure Cloud (latency requirement is met which is 50ms). So primary orion will be on premise and secondary will be in Azure cloud. With respect to SQL DB, we will be having a separate SQL DB 2016 sp1 for NTA 4.4.

Queries:

) We are planning to use SQL Always-on cluster where on-premise SQL will hold Primary orion db and Azure SQL will host primary NTA db. Also same on premise SQL DB will also host secondary NTA DB and Azure SQL will host secondary Orion DB. I know this setup might work but in case of failover and when both DBs are running on the same server will there be any issue? Is it recommended to host NTA DB on the same SQL server as that of Orion?
) While going for NTA 4.4, our existing fastbit db will be lost. Can you suggest us the way to retain the data available for the client anytime when needed? or even extract it as a report?

Regards,

joe

Find more posts tagged with

ha failover

Accepted answers

All comments

cha-chang_

Joe,

I believe the most recent version of the components will now allow you to manage both NTA and Orion DB on the same instance. I am curious though, If you are hosting the DB's on the same instance, why are you not just putting the primary on the on-premise for both?

As far as the fastbit, as you probably already know the SQL will not support the migration of the NTA fastbit data. However, you can still access the older data by installing the older NTA on another node and run an evaluation mode to access the data, as needed.

mesverrum

Agree'd with this ^. I guess this might be seen as some kind of way to add in a distributed work load while also adding in a measure of redundancy, but it feels like a weird use of cloud resources.

First of all, if you ever intend to use the on prem SQL server to run the NTA db then it has to be upgraded to 2016.

One of the nice things about having your HA in the cloud is that you only really pay for what you use, and as long as the primary site is up the cloud servers would use very little. Having the NTA database run in the cloud all the time seems like it would undermine those cost savings. If the on-prem SQL server is not powerful enough to run both at the same time then the whole scheme kind of falls apart, but if it IS powerful enough then why would you pay ongoing cloud costs instead of just using the resources already at your disposal and then only use the cloud stuff needed? Can you check how many average flows per second your current NTA instance is getting? I feel like an environment of that size normally isn't normally generating a TON of flows and therefore the SQL loads could be pretty manageable, unless maybe you have a really high proportion of routers like you might see if you had many small sites that all pushed a lot of data through their WAN.

You can take a look at the sizing guide here, Multi-module system guidelines , and once you know how many flows you normally get that would help you to estimate the SQL requirements.

50,000 fps sustained would require something like below, but I often see customers with very large environments who are generating WAY less than 50k fps so this may be overkill for you, or it may be undersized:

NTA Flow Storage

r3.xlarge
4 CPUs, 30.5 GB RAM
SSD 80 GB (included in r3.xlarge) + EBS Volume 500 GB
8 GB for every received sustained 1000 Flows/s with 30-days retention period

If it turns out that your on prem server is in between where it can "kind of" run both at the same time but performance is not acceptable for normal use, and the on prem stuff was already maxed out and could not have any more resources on it dedicated to it, then that's pretty much the only case where I see a need to use the cloud as the primary sql node.

Another element to take into consideration is that if your client has been using orion with SQL in a "standard" setup then they will probably notice the performance slow down that comes from switching SQL to an AG. There is usually a measurable hit to performance due to having to switch the database to Full Recovery mode and then another hit in SQL for the HA sync waits. I've been on the fence lately on the pro's/con's of SQL AG on Orion, it depends a lot on the org and what goals they really have.

aLTeReGo

Azure SQL DB support has been officially added to the Orion Platform. You can learn more about this deployment option at the link below:

https://thwack.solarwinds.com/docs/DOC-204353#jive_content_id_Azure_SQL_DB_Support