Re: Disk Management Strategies...? (here we go again!)
- From: "SuperGumby [SBS MVP]" <not@xxxxxxxxxxx>
- Date: Sat, 17 Feb 2007 11:59:53 +1100
Scalability of SBS is not so much restrained by 'it does this' as it is
doing it all on one box. By the time you get to ~50 users you should be
thinking about additional server(s), taking some of the load off SBS.
"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@xxxxxxxxxxxxxxxxxxxxxxx
comment: 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: How to join SUS
- Next by Date: Re: Can't browse across subnets
- Previous by thread: Re: Disk Management Strategies...? (here we go again!)
- Next by thread: Re: Disk Management Strategies...? (here we go again!)
- Index(es):
Relevant Pages
|
