Jump to content

SIMS Server and SIMS Databse - On the same server? Or on seperate servers?


Recommended Posts

Posted

As it stands we have our Database and Document Server on a separate box to our SIMS Server.

 

At the moment both the box that holds our SQL Server and the box that holds our SIMS Server are nearing End Of Life so I was wondering moving forward if it's best to keep them separate or to move them to the same new server?

 

I've heard contradicting advise on what best practice is regarding SIMS so what do you do?

Posted

I'm a little confused - what do you have hosted on your 'SIMS Server' if not the database or document server? All SIMS consists of is the database, document server and the file share containing the setup files and related bits and bobs? Do you mean you have the file share on a different server?

 

There's absolutely no need to separate off the file share to be honest - the data usage via it are minimal.

 

We have the lot in a single VM.

Posted
I'm a little confused - what do you have hosted on your 'SIMS Server' if not the database or document server? All SIMS consists of is the database, document server and the file share containing the setup files and related bits and bobs? Do you mean you have the file share on a different server?

 

There's absolutely no need to separate off the file share to be honest - the data usage via it are minimal.

 

We have the lot in a single VM.

 

Excellent.

 

For as long as I can remember it's been set up like this where I work but I never really understood why. Now the old boss is gone and we need to move to a new box sometime soon I saw no reason why we couldn't stick it on one piece of kit. However not really being involved in SIMS before I wanted to ask what other people did first in case there was a reason for it I missed.

Posted (edited)

Our host nodes are HP DL380p Gen8's with dual E5-2690 processors and 96GB of RAM. They use a central storage server with 16x 100GB SSDs, interconnected with 10GbE. (For background, to give a sense of what components are actually being used).

 

The SIMS VM itself has 8 cores and 8GB RAM. The highest CPU usage we've seen was 12% - and that was 'start of lesson 1 everyone logging in' time - after the recent Spring update. Our setup is way overkill though, no doubt about that. The server also hosts SOLUS 3 and Discover, along with our cashless catering system.

 

Oh, and for a sense of scale - we have about 45 users in SIMS at any one time, as all teachers use it, as do admin, behaviour and SEN etc...

Edited by localzuk
  • Thanks 1
Posted

Perhaps at the time for load balancing it was deemed appropriate to separate the two services, or there were plans to add more SQL DBs into the database server.

Some places have a dedicated SQL server and SIMS would be an instance on that. In that scenario you might choose to hold the documents / files separately.

 

We have it all in one here too, as per spec in sig. It runs pretty well.

Posted
We have ours on a single VM. It has 4 cores and 8GB of RAM and has run fine until the last patch. CPU usage has never really been an issue (until now obviously) but SQL Server will gobble up all the RAM it can!
Posted

Some places have a dedicated SQL server and SIMS would be an instance on that. In that scenario you might choose to hold the documents / files separately.

 

we have ours like this as we ended up with 10+ different VMs run SQL and decided to consolidate.

 

Although having SIMS + SQL self contained on one VM has a huge advantage, "Take Snapshot" !

Posted

I got a ticket on the helpdesk at the end of last week from the NM, asking for the SIMS snapshots to be deleted, as the ~200GB server was taking up over 1TB with all the snapshots going back 2 years.

 

For most SQL apps, consolidating would work well. I like that i have SIMS as a separate VM so i can reboot easily and not affect the others, plus like you say, snapshot is an advantage. I have now deleted a few old ones, but that means, that the backups i have been keeping from the days of yore, wont be usable as i'm pretty sure if i restore the old backup to a new install it won't recognise it or complain about incompatibilities and table changes. I wouldn't want to work out which files were new in setups and swap them out or restore from backup and then rollback the client app which is probably the only workaround.

 

Now we're going to have to rely on taking a backup of the VM file itself that happens with the overall site backup, and slows down the recovery time.

 

I know i shouldn't rely on snapshot for backups, but it's so quick and easy to do

Posted

I know, we'd never use it for live rollback, too much data to lose, even in a few hours. It's more so you can at least look at how things were at a point in the past, which we do a lot. It's also useful to restore to a test server and extract info / reports / templates that may have been deleted, for later reimport to live server.

It's a pain but with no auditing, keeping lots of old backups is the only way we have to easily trace things, on those rare occasions we need to.

Posted

in that kind of situation i would just restore the vms from a backup.

 

out of interest what hypervisor are you using? it says vmware in your signature. surely that's horrifically slow have that many snapshots on a vm?

Posted
VMWare - no slowdown. It works like lightning. Not much data is changed in practise and it's only ever a diff to the last file. Removing one took 45 minutes though and subsequent ones have been 20 mins.
Posted
VMWare - no slowdown. It works like lightning. Not much data is changed in practise and it's only ever a diff to the last file. Removing one took 45 minutes though and subsequent ones have been 20 mins.

 

yes you have a point actually, on ours it would be max 2gb of sql data.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...