BTW … I apologise for the length of time in replying … been sitting on a beach sinking cold ones over the Christmas break … and not thinking too much about RAID.

However, we’re back in business now.

Regards,
Neil

Now I could be a smarty-pants and say that if you have enough RAM in your system then you won’t really care about the pagefile because it won’t be used … but since we’re in the storage department and not the memory department I’ll have a go.

Considering that tihs is SBS, considering that there is all manner of reads and writes happening I’d suggest keeping the pagefile on a RAID 10 array because of it’s superior write speed to the RAID 5 array. Don’t put it on a RAID 0 as Windows gets very upset if it loses the Pagefile.

Therefore, for simplicity sake in this scenario, and the fact that there is 50gb volume for Windows (which is complete overkill), I’d put it on the same volume as the OS.

Now that one is sure to get the Winodws boffins all mad at me … let’s see.

Thanks
Neil

Using your scenario:
1 x 50Gb RAID 10 array for the Operating System
1 x 100Gb RAID 10 array for Exchange and SQL
1 x 1.2Tb RAID 5 for general data;

Where would you suggest to keep the PAGEFILE?

Yes, the scenario is based on minimum numbers of disk (after all it’s SBS), and would be much better for everyone if all raid arrays had their own disks, but the rub is in the heading … SBS is by very nature an unusual beast.

SBS is not going to be a video streaming system. Its major implementation is in small to medium business of extremely varied nature. In my experience its such organisations as cabinetmaking factories, industrial piping designers (CAD users) and customs-clearing houses etc – 20-30 users using Microsoft Office and possibly some specialised accounting packages.

Therefore streaming performance is not a factor because there just isn’t really very much “streaming” activity on the box. So if that is the case why not put it all on RAID 10 you ask – capacity answers that one.

Next the RAID card is there to help its mate the disk drive. We cache, queue, elevator sort and in general arrange the data coming to the disk in such a manner as to minimise the head movement of the drive.

Considering we have 512mb of cache on our high-end RAID cards, there’s plenty of room to arrange the deck chairs before launching the Titanic.

So yes, you are correct. If the drive is writing one type of data in one place and its next job is to write a different type of data to another area of the disk, then things will eventually just have to wait. However … this is exactly the same as the single RAID array that has two large Windows partitions residing on it … the data is in different places on the disks … but in that scenario you are stuck with all partitions having the same underlying RAID characteristics … which is exactly the scenario we are trying to get away from in the first place.

Don’t think I answered that one very well, but did I mention the fact that you should probably have a battery on that RAID card to protect all that data in cache? That’s another blog.

Ciao.

Both the OS and Exchange/SQL applications reside on a non-parity RAID array (RAID 10). This gives them the best disk performance that can be achieved with 4 disks (while still retaining data safety).

The data volume would reside in the large RAID 5 array. This gives good performance for general file serving, while maximising the capacity of the remaining space on the drives.

I understand that this recommendation is made in the light of limited IT budgets, but just for the sake of completeness: When there is concurrent disk IO from the DBs (random) as well as from file serving (sequential), doesn’t performance collapse (especially for the sequential access), because the drive heads on each disk are busy switching between the containers?