5 Replies Latest reply on Sep 13, 2010 9:28 AM by jagle

    New Server - Database Sizing

    jagle

      We've been running NPM for a few years now and have subsequently added NCM and NetFlow modules.  Our data base at this time is running about 50GB.  Below are some of our vital signs from the details window. 

      We've also got about 140 routers that we run NetFlow gathering off of, which I've heard is often the lion's share of the database contents.

      We're making a brand new install of Orion on two new VMs (one poller, one SQL).  We'd like at least to double our retention across the board.

      Two questions:

      Where does netflow fit into the retention numbers below (or has it got it's own setting in the netflow management window)?

      ---AND---

      Can anyone recommend a good amount of disk to allocate for DB given these criteria?

      ----------------------------------

      Network Elements      3017
      Nodes     468
      Interfaces     2509
      Volumes     40
             
      Alerts     9
      Events     6371
      Pollers     5533
      Polling Engines     1
                  
      Retain Detail Stats     7 Days
      Retain Hourly Stats     30 Days
      Retain Daily Stats     60 Days
      Retain Events     30 Days

        • Re: New Server - Database Sizing
          jagle

          "Bueller? ...Bueller? ...Bueller?"

          Magic 8-Ball says...200 GB any comments?

            • Re: New Server - Database Sizing
              Andy McBride

              Hi jagle,

              A couple of things here to keep in mind.

              • Netflow has its own set of retention settings. Go tou NetFlow Settings from the NTA Summary page to set.
              • NetFlow will be the lion's share of the data , as you say. I would think about allocating 300-400GB to have room for growth.
              • SQL for NTA running on a VM is not supported. SQL for NTA must be on a dedicated SQL server.
              • We recommend locally attached storage with RAID 10 and 15 K spindles.
              • See The specified item was not found..

              Andy

                • Re: New Server - Database Sizing
                  jagle

                  That caveat about a dedicated physical box for SQL is not mentioned on the site.  Where the following quote comes from.

                  --------------

                  "Orion NTA has matching system requirements to its host Orion Network  Performance Monitor. Please refer to the Orion  NPM system requirements for details."

                  Operating SystemWindows 2003 Server (32-bit or 64-bit) including R2, with IIS  installed, running in 32-bit mode

                  Windows 2008 Server (32-bit or  64-bit) with IIS installed, running in 32-bit mode
                  .Net FrameworkVersion 3.5 or later
                  DatabaseSQL Server 2005 SP1 Express, Standard, or Enterprise

                  SQL  Server 2008 Express, Standard, or Enterprise

                  ---------------

                  I seem to recall multiple posts referring to NPM/NTA running on virtual servers on these forums. 

                  Little clarification please.

                  --Edit--

                  Upon further digging  I did find a mention of this.  Still though, it is unclear why this is the recommendation, please clarify if possible.

                    • Re: New Server - Database Sizing
                      Andy McBride

                      Running NPM and NTA on a virtual server is OK. SQL does not perform well for high I/O applications such as NTA when installed on a virtual server. That is why we don't support SQL on VM's. In the past, we have seen a lot of implementations with SQL on a VM and it has a very negative impact on NTA performance.  

                      Andy

                • Re: New Server - Database Sizing
                  jagle

                  BTW, 5 Months later our database is only about 20 Gigs.  So size seems to be pretty small despite cranking all the settings up and adding more nodes.

                  We're also running the poller and the DB on separate virtual servers.  Runs along perfectly, if a little CPU hungry.