Re: Disk Management Strategies...? (here we go again!)
- From: "Les Connor [SBS MVP]" <les.connor@xxxxxxxxxxxx>
- Date: Sat, 17 Feb 2007 18:47:11 -0600
<snip>
The other option for my configuration, of course, is two drives in RAID 1
for OS, etc., and three drives in RAID 5 for data, logs, etc., and one drive
as a global hot spare now (as opposed to adding one later). But from what I
know about RAID 5, I'm not inclined to implement it.
<endsnip>
That's about as far as I'd go, it's a good disk config for SBS. I put all data on the raid 5, and also store shadow copies there. I used to worry about that, but don't anymore as I haven't seen any issues whatsoever. I used to overthink the partitions as well, and don't do that anymore either ;-).
--
Les Connor [SBS MVP]
"Michael Liu" <noone@xxxxxxxxxx> wrote in message news:uGjmrtiUHHA.488@xxxxxxxxxxxxxxxxxxxxxxx
[Note: Apologies in advance if this gets double-posted. I submitted a reply through Google Groups at least two hours ago and it has yet to post. Oh, and thanks Google Groups for publically publishing my Google account's email address in my original post -- how nice of you to help out the spammers.]
SuperGumby,
I appreciate you putting some real-world perspective on the scalability and performance of SBS (although your opening snide comments hardly promote the open exchange of ideas which -- correct me if I'm wrong -- is what I thought the Usenet groups are supposed to be about).
Incidentally, I wasn't just pulling that stuff out of the air when I suggested separating SQL/Exchange logs from data. Of the many documents and postings I had read in researching this subject, one was a White Paper published by Microsoft on the perrformance of BackOffice 4.5. They had configured their test server in a similar fashion: three sets of RAID volumes providing for a separation of OS, data, & transactions logs (only their data volume was on a RAID 5 array of four physical drives, instead of the RAID 1 array of two physical drives that I had planned).
After reading your response, I went back and reviewed that document and realized I had forgotten that they were testing BackOffice with loads up to 600 - 900 users (with a conclusion that BackOffice was able to adequately support such a load with a subsecond response time). Which leaves me somewhat bewildered: if the older technology of BackOffice (running on a very meager hardware configuation by today's standards) was able to support 600-900 users why does Microsoft suggest that SBS is optimal at no more than 50 users, with a max limit of 75? I suspect it may have more to do with marketing and requiring larger businesses to purchase Microsoft's more expensive discrete server technologies. Afterall, they wouldn't want SBS to kill their Windows Server, Exchange Server, SQL Server, ISA Server, (etc) product sales in the mid-sized business market. In any case, perhaps I am being overly cautious by wanting to distribute the OS, SQL/Exchange data, and SQL/Exchange logs over three sets of spindles.
All that said, I still haven't read anything in your post or your linked document to refute my configuration (except perhaps the issue of economy, as I'm sure many small businesses will not want to purchase six or more physical drives for their SBS server). Speaking of which, perhaps I wasn't clear (I'm a software developer by trade, so I'm still learning the correct terminology of the server admin community): the three volumes I suggested in my original post were each a hardware RAID array of two mirrored drives, for six drives total. It just so happens that my server is configured with six 73GB SAS drives (with two extra hot-plug slots available). So the only real downside I see (with the three RAID 1 volumes) is the current lack of a hot spare. But I can always add one (or two) drives later as more funds become available. In the meantime, I should be able to replace, within 24 hours, any drive that becomes defective. Is that really too much of a gamble? Just what are the odds that two out of six server-grade SCSI drives will fail within even 48 hours of each other. And then what are the additional odds that those two drives are both from the same mirrored pair?
The other option for my configuration, of course, is two drives in RAID 1 for OS, etc., and three drives in RAID 5 for data, logs, etc., and one drive as a global hot spare now (as opposed to adding one later). But from what I know about RAID 5, I'm not inclined to implement it.
- Michael
"SuperGumby [SBS MVP]" <not@xxxxxxxxxxx> wrote in message news:OJ%230ZBZUHHA.4668@xxxxxxxxxxxxxxxxxxxxxxxcomment: ho-hum
criticism: see above
http://www.supergumby.dyndns.org/changehardware/partitioning.htm
I'll comment on SQL performance. Those SQL tweaks you've been looking at relate to LARGE SQL servers. SQL Server is designed to handle THOUSANDS of users, SBS is imited to 75.
and you're somewhat muddying the water
The RAID1+RAID5 config you mention requires a minimum of 5 spindles (physical HDD's) which are presented to the OS as no less than two 'drives' (drive0 RAID1, drive1 RAID5). These drives may then be partitioned but the relationship between raid arrays, drives (volumes?) the OS sees, and partitions should not be mixed.
With 5 physical HDD's I'd create a single RAID5 array of 4 HDD's and have the 5th as hotspare. I'd then create a 20-30 GB 'OS' partition and apportion the rest of the space between VSS enabled/disabled space as I saw fit.
.
- References:
- Disk Management Strategies...? (here we go again!)
- From: GlobalAccessGroup
- Re: Disk Management Strategies...? (here we go again!)
- From: SuperGumby [SBS MVP]
- Re: Disk Management Strategies...? (here we go again!)
- From: Michael Liu
- Disk Management Strategies...? (here we go again!)
- Prev by Date: Re: internal lan ipaddress
- Next by Date: Re: Domain Registrar Recommendations
- Previous by thread: Re: Disk Management Strategies...? (here we go again!)
- Next by thread: RE: Question about SBS_LOGIN_SCRIPT.bat
- Index(es):
Relevant Pages
|
