If you visit our Library & Support page, you will see links to each product's page that will provide you information such as system requirements, how-to's, upgrade advisor, etc. You should be able to find what you're looking for on these pages.

I would start with this link that will take you to the Orion requirements. Hope this helps!

Hi Alterego,

Thanks for quick response. However, This information suggests minimum h/w requirement that too when application is individually deployed. However, I need to know, keeping in view above scope, what all applications should be kept on same system sharing same database and what all separately.

For Example: NPM and NCM can be hosted together keeping in view the number of devices. However, Not sure whether device tracker and IPAM can also be clubbed together. In addition, NTA should be built altogether separate keeping in view the volume or should be set along with any other application. This at the same time should maintain the high availability also and retention period of data 180 days.

Please help me on this.

Thanks

Sumit

We usually recommend keeping all the products together on one database, exept the NTA product. This one you will want separate, as you've already read; however, NPM, NCM, IPAM and UDT should be together. As for the reports, when you set up your reports in the product, you can select your timeframe, so 180 days is possible, but I'm not sure exactly what information you need as the 180 day report would be a summary. 

If you're looking for a high availability solution, have you discussed an active/active approach with your sales rep?

Hi Alterego,

Oh..I missed clarifying upon180 days, I have mentioned this to suggest upon the database size keeping in view above mentioned count.

However, My concern here is , if keeping all component npm, ncm, ipam and UDT on same system then report may suffer performance. Should we configure reports separately? In addition, when we set up extra poller to accomodate incremented element, then all these components(IPAM and UDT) can also be polled separately through separate poller.

No, We couldn't discuss on this HA part. However, Tried Exploring if installed in active-active then whether we will have setup load balancer with fail-engine in between on separate system pointing towards two system. But in this case fail over-engine system will remain without HA. However, In case of Active-Passive, We suffer functionality of NTA in Fail-over. Please suggest.

Thanks

Sumit

NTA supports high availability configurations as outlined in the NTA Administrators Guide.

Hi Alterego,

Thanks for link.

One major concern coming my mind need clarification, Please suggest, as you said it is recommended to have all NPM, NCM, DT, IPAM, NTA together then Shall We have VNQM also deployed on same box first, If yes then keeping in view around 1000 network device, 50 IPSLA, 3000 ip phones, will a single box be able to accomodate this much if resource given around 24 GB RAM, 8 CPU and database on separate box with almost similar configuration.

Please help answer above query this will remove my doubts.

Best Regards

Sumit

Hi sumitk

We are just putting in our new environment now, with a similar size and product range as you, we are using -

1 HP ProLiant DL360 G9 E5-2630 server with 2 Processors (16 core), 48GB RAM and 3 300GB 15k disks in RAID1.  This will host - NPM, SAM, NCM, UDT, IPAM, NTA, VNQM

Then we have a VM for the NTA DB

An SQL server - virtual, and shared (not ideal, should be dedicated and physical)

The performance aspect is usually I/O on the disk, so put as many in as you can and don't use RAID 5.

Thanks smiffy for responding accurately addressing my issue.

Please suggest, what hardware specification you are taking for NTA DB and SQL server.

The following is a SAMPLE recommendation so you can add or subtract these according to your own needs.

Hardware Recommendations for Orion Servers
> NPM SLX /NCM DLX /IPSLA 25 Server
CPU                       Quad Core Processor 3GHz or better
HD Space             20 GB
Memory              8GB

> NPM SLX /NCM DLX Server
CPU                       Quad Core Processor 3GHz or better
HD Space             20 GB
Memory              8GB

> NPM SLX Server
CPU                       Quad Core Processor 3GHz or better
HD Space             20 GB
Memory              8GB

> Each Additional Polling Engine Server
CPU                       Quad Core Processor 3GHz or better
HD Space             20 GB
Memory              8GB

Hardware Recommendations for SQL Servers
>SQL DB for NPM SLX /NCM DLX /IPSLA 25 Server/10 x APE
CPU                       Quad Core Processor 3GHz or better
HD Space             20 GB
Memory              8-12GB
Mirrored drives for OS and 6 disks Raid 1+0 for database data files

>SQL DB for NPM SLX /NCM DLX Server/10 x APE
CPU                       Quad Core Processor 3GHz or better
HD Space             20 GB
Memory              8-12GB

>SQL DB for NPM SLX Server/10 x APE
CPU                       Quad Core Processor 3GHz or better
HD Space             20 GB
Memory              8-12GB

**SQL Server Hardware Recommendation**

3 GHz, dual core processor or better. This will work for all size licenses. Do not use
less than a 2 GHz processor for any Orion SQL server.

Best Practice use RAID 10
2 x Raid 1 disk (Mirroring) For operating system
2 x Raid 1 disk   (Mirroring) Place pagefile here and also can be used for applications and ad hoc Stuff
4 x RAID 1 +0 Stripping and mirroring for database files (2 partitions 1 for Data File and 1 for Log File)

WINDOWS 2012, SQL 2012, SQL 2014 AND SOLARWINDS PRODUCTS

https://thwack.solarwinds.com/community/solarwinds-community/product-blog/blog/2013/12/11/windows-2012-and-sql-2012-and-solarwinds-products

For more details please find Orion Admin Guide .

http://www.solarwinds.com/documentation/orion/docs/orionnpmadministratorguide.pdf

Server 2: Primary Database Server

Software Installed:

-      Microsoft SQL Server 2012, or 2008 R2 Standard Edition.

Recommended Deployment specs (Physical server recommended)

• Dual Quad Core Processor 3 GHz or better
• 64 GB RAM
• Hardware RAID Controller with a battery backed-up write back cache
• Disk Subsystem 1 Array 1: 2 x 146GB 15K disks RAID 1 (mirroring) Operating system
• Disc Subsystem 2 Array 2: 2 x 146GB 15K disks RAID 1 (Pagefile + Extra Storage)
• Disk Subsystem 3 Array 3: with 6x 15k 146GB or 300GB Disks configured in a RAID 1+0 arrays to allow for maximum write performance. This is for your SQL MDF AND FILEGROUPS
• Disk Subsystem 4 Array 4: with 4x 15k 146GB or 300GB Disks configured in a RAID 1+0 arrays to allow for maximum write performance. This is for your SQL LDF Transaction LOG File
• 1Gbit LAN port.
• Windows 2008 R2 Server (64-bit)

For more details please follow the links.

NETWORK PERFORMANCE MONITOR (NPM)

https://thwack.solarwinds.com/docs/DOC-1108

SERVER & APPLICATION MONITOR (SAM)

https://thwack.solarwinds.com/docs/DOC-1107

NETWORK CONFIGURATION MANAGER (NCM)

https://thwack.solarwinds.com/docs/DOC-1106

FIREWALL SECURITY MANAGER (FSM)

https://thwack.solarwinds.com/docs/DOC-170941

NETFLOW TRAFFIC ANALYZER (NTA)

https://thwack.solarwinds.com/docs/DOC-1104

WEB PERFORMANCE MONITOR (WPM)

https://thwack.solarwinds.com/docs/DOC-1098

IP ADDRESS MANAGER (IPAM)

https://thwack.solarwinds.com/docs/DOC-1105

VOIP & NETWORK QUALITY MANAGER (VNQM)

https://thwack.solarwinds.com/docs/DOC-1103

USER DEVICE TRACKER (UDT)

https://thwack.solarwinds.com/docs/DOC-1099

If this is really a concern then you may want to look into additional pollers to use, and remove the polling load from your Main Web Server.

This will reduce traffic for ensure faster web page loading times. Faster App response when logging to the server to run things like atlas... and most entities of the app are web based now rather than an app on the server to manage.  

Your biggest hindrance will be the IOPS to/from your DB, and adding more pollers you want to make sure that each polling engine has the throughput needed to the DB - since they write directly to the DB.

And really unless you have a big load on that server - it may not be much of a difference. For us it has helped in the past immensely (specifically with the amount of data polling that I have setup [using tables]) - but that issue did emanate from the DB to affect the web performance (again, all about IOPS)