Pros v. Cons for On or Off- box SQL

Pro's for on box
reduce chance for any communication issues
you only have one server

Con's
limited to 32bit SQL (as Notification Server requires 32bit Windows), and it's inherent memory problems (can't get enough)

Pro's for off box
can utilize 64bit SQL with a dump truck load of memory. This also gives you a base server for Service Desk 7 (which requires 64bit)

Con's for off box
chance of communication issues
extra hardware

In my current and previous job we had the sql off box. In my current job, the Altiris database is shared with other databases and things seems to be running fine. The sql server is an Intel Xeon E5345 @ 2.33GHz with 16GB RAM. We seem to be running just fine on everything. I would recommend that you look into all of your inventory, tasks, and patches schedules and either spread them over the period of the day, or to schedule them to run off hours. Also, try to switch the authentication mode to the Altiris sql to SQL Authentication instead of Windows Authentication. That seems to speed things up.

I forgot to mention that we run around 21k PCs controlled by 3 NS Servers and 12 Deployment Servers. LOTS of fun!

We recently "outgrew" our hardware on one of our NS's that was running SQL 2000 on-box.  Altiris and SQL were both fighting for limited resources, and as such our queues would never catch up no matter how much tweaking we'd do.

The server is about 2-3 years old (I don't have exact specs handy, sorry) and is managing about 5,500 clients (Inventory, Patch, SWD, Task Server mainly).  Once we moved the database off-box to a SQL 2005 cluster (database still in SQL 2000 format for now), performance went through the roof.  No longer are we waiting up to two minutes for pages to load -- they're nearly instantaneous.  I've not seen queues get backed up, let alone more than a dozen files in any of them at one time.

If you move to a shared SQL environment, make sure you give Altiris its own instance on the SQL server as it loves to thrash its temp db!

Well you have a pretty beefy box there (esp. for 1200 nodes), but even then the notes above are all correct.  If you can get your SQL off-box on a 64bit server like Jim suggests, it is the way to go.  We manage ~17,000 nodes on our current NS, which until a few months ago was all running on a quad-socket Dell 6950 (single cores), 8GB RAM, all local disks, with SQL 2000 Enterprise on Win2K3 Enterprise.  First we moved the DB to SAN-attached storage (with SQL server still running on-box), which helped the disk contention issues we were having, but that eventually wasn't enough.  Finally we got a loaded (dual quads, 48GB RAM) box with Win2003 x64 edition and migrated the DB to that running on SQL 2005 x64 (note you can use Standard Edition just fine with 48GB RAM).  The performance is incredibly better.  A few examples:

• Running the Patch Vulnerability reports used to take > 12 minutes when run against all 17000 machines, with all patches back to 2000 or so, it now runs in about 1:15.
• Loading a Collection Picker (for reports or collection inclusion) used to take over 45 seconds, now it loads in about 5.

Granted you have a much smaller environment to contend with, and servers don't grow on trees (esp. in this economy).  But if there is any way you can get your DB offbox (on 64bit) I would do it.

Kyle,

I was wondering how much RAM you have in your NS/DS server (I assume they are the same box). Also how much fixed memory did you allocate on the SQL server? I am about to set up a similar configuration with a virtual NS and a physical 64-bit SQL 2005 server.

Thanks,
Brandon

Brandon,

We used to be running a similar setup to what it looks like you will be setting up.  We had our NS (for version 6) set up on a Microsoft Virtual Server running Sever 2003 with 4GB of RAM and a Quad-Core AMD 2.29 GHz processor.  This worked fine for us and we were managing close to 18,000 clients.  Of course we had inventories and software deliveries and everything randomized to make sure we were not sending too much traffic to the box at any given time.  We run a pretty nice SQL box since it handles a few other web apps we have running.  Windows Server 2003 x64, SQL Server 2005 64bit Enterprise.  32 GB of RAM and Quad 3.0 GHz Dual Core AMD 8222 SE processors.  This box screams and we never have any issues with it.  Obviously for your needs, this type of box could be toned down quite a bit.

When we cut over to version 7, we decided to do an off-box migration to a new physical server with some better specs to make things run just a bit smoother.  This physical box is also running 4GB of RAM but is making use of Quad Xeon processors.

You should be fine with 1200 nodes on a VServer with 4GB of RAM and off-box SQL server.  How are you planning on distributing software and managing tasks?  Do you have other servers allocated as task servers or package servers?  Software delivery and task can increase the load on the NS if it is handling everything.  In fact, I believe the maximum recommended number of clients using the NS for a task server is 500.

Another question, here is a screenshot of my Server Performance Report over the last 7 days:

Can someone give me some idea of what these numbers mean?  Does this look like abnormal activity for an environment with only 1200 nodes?  Is there another report that I could run that would give better information? 

Thank you for your responses so far.  it seems that we must have something set incorrectly if we have such a small number of managed nodes and we are having these issues and you guys are managing thousands more machines.  Any ideas on out of the box settings that could be changed or anything that might help?

The Client Configuratino Requests (CCRs). The rest seem acceptable, although to be honest I've never seen an exact breakdown on what is good\bad.

With the CCRs, you should be able to drill down and see what machines are causing the errors. Just a few bad installations could flood your system with error messages.

It looks like some of these errors are due to the fact that we had a bad Ghost image that was built with the Altiris Agent already installed and then rolled out that way.  One machine in particular had 751 errors in the last 7 days.  I think that we may have a couple of machines that have the same GUID as a result.  I found a couple of KB articles (#3848 looks the most promising) on how to fix this without having to reimage the machine, but was wondering if you had ever had this issue and have an article that you would recommend detailing the steps necessary to reset the machine GUID.

Could those errors be causing DB slowdown issues?

I have used the duplicate guid diagnostics to great effect. You can also run the task it contains, aexagentutil /resetguid on any problem system listed by the report the kit ocntains. In addition, you might want to take a look at this report - Altiris KB30567 Table Sizes per Solution. That should give you an idea of what tables are growing out of control. Pay special attention to the tables that start with Evt (event) or if you use it, Application Metering.