Re: Disk Management Strategies...? (here we go again!)
- From: "SuperGumby [SBS MVP]" <not@xxxxxxxxxxx>
- Date: Fri, 16 Feb 2007 17:04:38 +1100
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.
"GlobalAccessGroup" <global_access_group@xxxxxxxxx> wrote in message
news:1171604258.443993.28320@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I realize there are a lot of diverse opinions on server disk volume/
partitioning strategies, many of which have been expressed in this
group. I think the problem is particularly complex with SBS servers
(even more so with SBS Premium) because of the number of very
different functions that must all be performed on a single box. For
example, SQL Server best practices would dictate at least three
separate disk spindles (with RAID): one for the OS, one for the data
files, and one for the transaction logs. (Some people would advocate
two additional spindles for the tempdb files and the high-activity
indexes). But how do you implement that alongside the best practices
for ISA, Exchange, Sharepoint Services, WSUS, etc. (Admittedly,
Exchange and SQL Server have similar requirements.) Then add Shadow
Copies and backup strategies to the mix, not to mention financial
constraints on your hardware, and you have quite a complicated puzzle
to solve in order to eke out the best combination of performance, data
security, and economy.
volumes/partitions: one for the OS (typically RAID 1) and one for dataFrom what I found, the most popular recommendation appears to be two
(typically RAID 5). However, I'm not convinced that this is the best
solution for SBS. One of the issues I feel is commonly overlooked is
the impact of Shadow Copies and backup strategies. It seems to me that
a volume/partition could be classified as falling into one of three
categories: no shadow/no backup; no shadow/yes backup; and yes shadow/
yes backup. (I can't imagine a scenario where one would want shadow
copies enabled but no backup.) I realize that is possible to designate
particular directories and files within a partition for backup, but I
like the idea of organizing backups by partition. It makes it far less
likely that some important files will be overlooked, and it simplifies
the backup/restore procedures.
The next consideration would be the physical separation of data. For
example, from a security point-of-view, you would lose valuable data
redundancy if you were to place shadow copies on the same physical
drives as the shadow source files. And from a performance point-of-
view, database data should be on different spindles than database
transaction logs.
So if we were to merge all this into a unified disk management
strategy, then I count three disk volumes (preferably all hardware
RAID 1 for the best combination of security, performance, and economy)
divided into a minimum of seven partitions:
Volume 1:
Partition (A): OS & Apps (no shadow/yes backup)
Partition (B): Pagefile, Tempdb, ISA Cache (no shadow/no backup)
Volume 2:
Partition (A): SQL & Exchange Data (no shadow/yes backup)
Partition (B): User Data File Store (yes shadow/yes backup)
Volume 3:
Partition (A): SQL & Exchange Transaction Logs (no shadow/no backup)
Partition (B): Shadow Copies (no shadow/yes backup)
Partition (C): WSUS, Client Apps, SBS Source Files (no shadow/no
backup)
Comments? Criticisms?
.
- Follow-Ups:
- Re: Disk Management Strategies...? (here we go again!)
- From: Michael Liu
- Re: Disk Management Strategies...? (here we go again!)
- References:
- Disk Management Strategies...? (here we go again!)
- From: GlobalAccessGroup
- Disk Management Strategies...? (here we go again!)
- Prev by Date: RE: Question about SBS_LOGIN_SCRIPT.bat
- Next by Date: RE: Anti Virus Excludes to Include.
- Previous by thread: Disk Management Strategies...? (here we go again!)
- Next by thread: Re: Disk Management Strategies...? (here we go again!)
- Index(es):
Relevant Pages
|
Loading
