4 Replies Latest reply on Apr 20, 2015 8:20 AM by shawn_b

    NTA4.0 32 to 64bit Migration Path - How?

    shawn_b

      Greetings All

       

      Like so many of you that may have attempted this and received the notification that NTA v4.1 cannot be installed on your 32bit OS, I am seeking some advice on moving forward with the new version.

       

      My dilemma is that I presently have a very customized Solarwinds deployment.

       

      NPM, NTA, UDT and NCM.

       

      I absolutely love and cannot live without SW (geek moment) and NTA is the gem in the SW crown (for me)

       

      I have a lot of nodes being managed with a lot of customized charts, alerts and reports.

       

      There is no supported migration path for the Windows 32bit to 64bit OS so I am left wondering how can I upgrade to the latest version . . . and silently hoping that future versions of the products I use will not end up like NTA > wake up one morning and discover that your beloved SW application has gone 64bit and you cannot upgrade to the latest feature.

       

      I am a bit upset at SW for this, but know they have done it for the greater good of the product and know it was done with the product roadmap in mind.

       

      Building a new 64 bit OS server and installing all my application on it is not an option as I do not have time to recreate all those charts and reports

       

      do I install a new server just for NTA ? would my main SW server have to integrate with the new server? How?

       

      This is a more viable option for me, but will pose a time consuming challenge. The new server would have a new IP address.

       

      All my switches and routers are already configured to export Netflow data to the IP address of the present NTA server. Would this would mean reconfiguring all nodes to export Netflow to the new NTA server

       

      Solarwinds, do you have a migration path?

       

      What have the rest of you done?

        • Re: NTA4.0 32 to 64bit Migration Path - How?
          choly

          Hi Shawn,

           

          thanks for your feedback, I am sorry for troubles caused by dropping 32bit support, hopefully you will enjoy the performance and data granularity boost which 64bit version brings thru Flow Storage Database (FSDB).  Unfortunately NTA needs you to run main Orion and all additional pollers on 64bit servers, so I am afraid that migrating Orion to new server is a must.

           

          Things are easier if you are using separate SQL server, as the SQL DB holds most of resources/views configuration, nodes information, alert definitions, historical data (NTA's new FSDB will automatically migrate you historical flow data from SQL DB). So you just reconnect to your existing SQL server during new Orion server setup.

           

          Following guide can help you migrating the Orion server: http://www.solarwinds.com/documentation/orion/docs/OrionServerMigration.pdf

          To avoid reconfiguration of all your flow sources, you can set the original IP address to the new Orion server once you won't need the old one.

           

          As for reports, they are defined using configuration files, you would need to copy them the to the new server (check the guide above).

          Note: 64bit versions of NTA are using new web-based reporting, unfortunately there is no automated way how to migrate your custom reports, so you would have to manually recreate them in the web reporting (reason is that FSDB is not backwards compatible with SQL commands syntax, so you might need to use different constructs to get the data).

           

          For the best performance we recommend to use separate server for hosting FSDB.

           

          I hope this post helped you to plan the migration better.

          Feel free to contact me or our support if you have any additional questions!

          • Re: NTA4.0 32 to 64bit Migration Path - How?
            shawn_b

            Ok guys,

             

            Firstly, thank you for the reply and the information provided.

             

            Secondly . . .

             

            This might be a step in the right direction for a more productive and efficient application . . .  BUT is a massive pain for me if this migration does not reproduce my existing environment exactly to the new environment. I spent quite a lot of time over the past years building my suite of apps to what it is today.

             

            Spending more time to rebuild custom reports and view is NOT on my list of priorities. Quite a step in the wrong direction for the user experience

             

            I will try this migration and post my results