This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Latest version of NTA is incompatible with security policy in our environment due to NO SQL DB requirement

I am a contractor working with the military and recently went to start the process for upgrading our SolarWinds products.  We ran into a real conundrum when we found out that NTA is now using a NO SQL database.  There is no way this is going to be allowed in our environment.  It is putting my team in the position of having to reconsider whether to continue with SW or look for another solution that will mesh with the security requirements of our environment going down the road.  What was the reasoning behind the change in DB for NTA?  Is this the way it is going to be going forward?

  • We ran into a real conundrum when we found out that NTA is now using a NO SQL database.

    Very important to note that the new datastore for NTA is an optional datastore. If your security requirements require this data to be stored in SQL Server, you can continue to do that!

    However, I'd be quite curious as to what the perceived security differential is between Microsoft SQL Server and any other datastore, particularly if it's hosted on a dedicated server with appropriate security restrictions.

    What was the reasoning behind the change in DB for NTA?

    The reasoning for the new change is that the new datastore technology is exponentially faster than using a transactional database. In addition, netflow data is extremely voluminous, and getting that out of the shared database for the remainder of the modules of the product suite, means that the other modules will have much better performance also. Using the dedicated datastore also means that you can store up to 60 days of detail netflow data, rather than the 15 minutes that is possible when using SQL Server.

    We talked about the NTA v4 datastore technology in SolarWinds Lab Episode #9.

  • Thank you.  I will look over that episode.  We were under the impression it was not optional with a 64 bit operating system from our own reading of the install and other documents.

  • We were under the impression it was not optional with a 64 bit operating system

    Somewhat the opposite. Use of the new NTA4 datastore requires a 64-bit operating system.

    If you can point me to the source you used, I'll be happy to review that and make sure it says what it should.

  • Just to be clear.  We are using a 64 bit 2008 server.  We want to avoid using the new NTA datastore since it is not cleared for use in our environment.

    Do we have options of using the same SQL instance that NPM etc are using?

    Do we have the option to use a dedicated SQL DB for NTA separate from the one being used by NPM et al.

    Thanks for your quick response too by the way.

  • My apologies for the delay in responding.

    I was inquiring internally to determine whether I had misunderstood the requirements for NTA4.

    Turns out, I had. :-(

    The 64-bit installation requires the use of the new datastore, and the datastore requires the use of 64-bit systems.

    The only way to retain NTA 4.0 on a SQL Server instance is to install NTA 4.0 to a 32-bit system.

    Is there anything I can do to help with the issue regarding the use of the new datastore?

    I'm curious about the specific reasons for it being disallowed in your environment, and if this is going to affect other military installations as well.

  • The military seems to like Oracle and MS SQL in my situation.  I would imagine there are plenty of other locations that are the same way.

    I would also point out that SolarWinds is not the only vendor using NO SQL type databases and that seems to be the future of many of these sort of thing so I am sure the military will adopt new policies to allow them.  Time.  That is the question.

  • Thanks for digging.  Knowing for sure is what we really needed.