Can SAM be installed on the same server as NPM, NCM, but use a different database? I would like to use separate ones if possible to improve performance.
In short, yes, it can be. But if you split the databases, then you lose the functionality of the products working together. My organization originally split them out and are now in discussions of how to put them together.
In order to get the integrated single pane of glass effect Solarwinds offers you are definitely best off keeping all of the possible applications on a single database, you really do give up a lot by breaking them apart.
If you want to minimize the impact of SAM on the performance of your NPM you can technically use SQL wizardry to associate the SAM tables with a filegroup on another disk drive, as shown here Moving a Table to a Different Filegroup - SQLMatters
but honestly I rarely see Orion installations that are big enough to justify that kind of administrative complexity. At that point the cost of having you and the DBA spend time to hash this all out probably costs more than the cost of supplying faster disks to the system in the first place.
My thought process for planning something like with would be along the lines of:
How big is your existing NPM environment in terms of element count?
Is the current performance acceptable or does it feel like its barely getting by?
How many read and write IOPS does your existing NPM generate to the storage system and is the latency currently reasonable (I'd be expecting under 10 ms, preferably less)?
What is the theoretical IOPS capacity of that storage system?
How many SAM components are you planning to add to the system?
There isn't a one to one relationship between elements and components and IOPS loads, but for purposes of this exercise in a reasonably small environment I would treat them equally, as in if I have 10000 NPM elements, and I'm about to add 10000 SAM components then I might want to make sure I have storage to support doubling my current IO loads. If I think I can support the added load we go ahead on the current storage, if not we figure out how to increase the IO capacity of the storage. I'd only be thinking about breaking the tables onto different disks if I had an environment with at least 5 full polling engines worth of stuff to monitor, and usually in environments that large we typically just throw it on a nice flash array and call it a day.
Try not to make things more complex than they have to be.
Originally I was thinking of setting SAM up in AWS and keeping NPM down locally, but looks like it will be all on one box now that I have done some testing. At some point I will need to move the DB off the server it is currently on since it will be going away, and will be going to a smaller server more suitable for this application. Really don't need 64G of ram for one DB, no matter how many nodes being polled.
Yeah, relatively rare that i see an environment using more than 16-32 gb of ram for the orion db, even when they run a ton of modules and elements. Fortunately moving the orion db around is pretty painless and can happen with almost no downtime, just back up the db, restore it to new sql server, stop services, run config wiz and change the db to the new location.
