Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Netflow seperate database to Orion?

Not sure if this is a stupid question or not, but I'll ask it anyway. As netflow stats are not as critical to us as the underlying Orion information, is it possible to have the Netflow module utilising a seperate database to that of Orion? The logic being that a clustered / replicated SQL database would need to be significantly larger (and therefore more expensive) with netflow information included than breaking off the netflow stats into a seperate (less resilient) isolated database. Is this possible and if so, common / recommended?

Thanks in advance to anyone who can offer feedback on this.

Find more posts tagged with

Accepted answers

All comments

SamuelB

I don't believe this is possible today, but I would like to see it become possible in the future. I would like to replicate the Orion database, however, having the Netflow data in the same database makes this quite difficult.

Bahlkris

Does anyone know if this ever became possible? Our setup has netflow causing a bit of a performance problem on our DB server, id love to get this offloaded to another database and really go kind of bonkers with netflow.

mr.e

We have been thinking a lot about the impact of the NTA module, for two reasons. First, of course, is the size of the Orion DB. Second, the NetFlow services heavily tax our core Orion server, which shares cycles with several other SW modules (i.e. SAM, IPAM, VNQM, WPM, etc.). The solution we are considering is as follows:

Purchase a new core for Orion NPM, to be installed on a brand new server (or VM)
Create a new SolarWinds DB on a different SQL server, so as to avoid memory and CPU "fights" between both Orion databases.
Perform a SQL backup of the current Orion DB
Install the new (aka old) Orion database and also move the NTA module to it.
Once NTA is confirmed as properly running on the new server -- let it collect data for a while (i.e. 30 days).
After 30 days, remove the NTA tables from the "old" Orion database, and then shrink the DB.

Of course, the above plan comes with some downsides, which is why we're still considering it. First, we would have to spend $$$ on the new Orion NPM core server, and get our DBA's to let us have disk space on the new SQL server. Second, we do not have enough fund to also purchase Additional Polling Engines for the new Orion NPM server. So, we would have to "hope" that the new Orion NPM/NTA server will be able to handle the load w/o the Additional Polling Engines. Third, 30 days of historical data may not be enough for some of our end users -- those that like to see 3 months+ of NTA data for comparison.

So, if anyone out there has a different approach for reducing NTA load on the core and reducing the size of the DB, by all means share it w/us.

Bahlkris

So i am just curious, and you dont have to answer this, but how many Netflow sources are you pushing to your Orion DB and where are you seeing your bottleneck. Also whats the setup of your DB server?

i only have about 20 sources, my hardware is isolated so if everything goes down Orion is still up to tell you "hey everything is down". The hardware is great and my CPU and memory are scaled so high that we are way past the best practice for number of elements, however the disk is DA and it really started taking a hit when we scaled up Netflow. I love the Netflow data we are getting and more importantly so does management, but my server is taking a hit. I am currently considering a baby SAN just for this one database server. Seems like there should be a better way.

Getting a new NPM seems like it would work, but yeah $$$$ and on top of that you now don't have a single pane of glass. Its effectively like getting another product just for NTA.

mr.e

Well, currently we have 274 sources, and plan to add twice as many. We are not noticing application sluggishness yet, but the CPU is often quite high on our core Orion server -- with NTA services taking up most of the CPU and memory resources. Our SQL server is quite beefy too (96GB or RAM, 2 3Ghz procs and tons of disk space available). Again, I am not seeing bottlenecks per se, but I worry a bit about the impact of NTA on our core Orion box. By the way, I too would much more prefer for SW developers to release a version of NTA that can run in standalone mode (like Orion NCM).

Bahlkris

Wow you are way ahead of us on sources. What is your disk setup on your server? direct attached? SAN? Sas disk, sata, iscsi?

I'm now wondering if i have a different problem.

wonderz

NTA is a very heavy CPU/RAM resource. This is why the admin guide says you cant have SQL on same server as NTA. Reason? All your interfaces are sending Netflow packets every 60 sec. So multiply that by every Netflow source, for every min, for every hour/day/week/etc. That is a huge amount of data to index on a constant basis. It is why you see the CPU/RAM jump on the Orion server when Netflow service is collecting. This is why Netflow data is uncompressed default for only an hour. It has to start averaging down the data collection after an hour to keep the database at a decent capacity. NTA will average data down to 15min intervals older than an hour, and then 1hr intervals after a day (listed in pg35 of admin guide). The graphs become less granular the older the Netflow data becomes.

NTA is just receiving truckloads of packets on that continuous interval. This is also why it is recommended to have Orion on a dedicated SQL server and not on a SAN. SAN is great for large data, moving huge files. However with NTA, is sending smaller data, but a lot more small quick SQL transactions. So it is constantly writing to SQL to index the data, and then has to do many queries to load any of the NTA graphs. You will likely notice, loading the NTA summary page takes longer compared to other pages due to all the queries that must be performed to graph all that available information. It has to query a lot of tables to render that graph.

Also any Orion database for best I/O disk performance should be running RAID 10 config. To answer the main question above, NTA must be installed with NPM, because stores the data in the main NPM database. This is also why the NTA license size matches the NPM license. It uses the SNMP information from the NPM side to match up the interfaces sending data on the NTA side. NPM can tell you the total amount of traffic used on router or just a work station, where NTA will only look at the flow data conversations from the set interfaces on the configured routers and switches.

jacob_beucler

Hey there, great thread. This question is super relevant to the next release of NTA. Wonderz has accuratly communicated the constraints that the current version of NTA has and how the DB can be impacted. NTA provides great data thats for certain, however the impact on the DB can be costly. Scalability and Performance are the main area's of focus for the next release of NTA.

We are going to be moving the flow storage and processing off of the Orion SQL DB.

By doing this, we will be providing a performance increase for the rest of the Orion products that are leveraging the Orion DB. Additionally, we will not be forced to aggregate the data. Customers will be able to retain detailed data for as long as they like (given the appropriate amount of disk space). Perhaps the most impactful part of doing this work is that customers will be able to scale up the amount of NetFlow data they are capturing with out affecting the responsiveness of the rest of the Orion Products. In the very near future we will be releasing a Beta version that will allow you guys to deploy this, (NOT ON YOUR PRODUCTION ENVIRONMENT!) and see first hand how this is going work. I will respond back to this thread with links to the blog posts and Beta invitations when they go out.

Here is a link to the "What we are working on post" that was announced 2 weeks ago.

Bahlkris

This is exactly what I was hoping to hear. Jacob if you are at live I am going to come down and hug you.

mr.e

Jacob,

Please forgive if this sounds silly but I am not clear what you mean. See below...

It seems that you're saying that NTA will have its own database, but then that would seem to imply that NTA would no longer be a module of Orion NPM. Instead, NTA would be a standalone app, with integration to NPM. Is this correct? If not, I would appreciate clarification on this mattter.
What happens to the historical data that was collected before the "flow storage and processing" data is moved off the Orion SQL DB?

By the way, I too agree that NTA is a most definitely a CPU/RAM hog, since we see that right now... even we have a only small fraction of our interfaces monitored by NTA.

jacob_beucler

NTA will have its own database, NTA will still be a module of Orion NPM, NTA will still require a connection to the NPM DB (we will still need to know NPM stats and CBQoS information)
We will be providing a data migration solution for all customers that wish to move historical data.

Hope that helps!