Re: SBS 2003 Installation Drives - Folders
- From: "John" <nospam@xxxxxxxxxx>
- Date: Sun, 12 Feb 2006 23:01:45 -0500
My responses are inline.
"SuperGumby [SBS MVP]" <not@xxxxxxxxxxx> wrote in message
news:%23OrMBxBMGHA.2696@xxxxxxxxxxxxxxxxxxxxxxx
I think your plan is crazy.
Should you move the application installation points you will reduce the
space required on the OS partition significantly. A 20GB partition has
enough space to accept the default program installation points.
And yet there are many applications that can only use the space on the C:
drive for maintenance functions, many times the requirements are multiples
of the space that the application actually takes up itself. An example of
this would be Goldmine where I typically ensure 4X the amount of free space
vs. the combine Goldmine file size is available on the C: partition. This
even when the application is installed on X:. The same is true for many
patch installations.
There is
also reason to practice caution about moving the installation point of the
major SBS applications, SBS is tightly integrated and by moving the
application installation point you may experience a problem when, say, a
service pack comes out.
So the SBS installation process which provides for locating the applications
and data on other drives does not provide the correct registry entries for
the service pack or other integrated software updates to follow? Then why
did MS make the change option part of the install?
The system is overpartitioned. Please explain the benefit you perceive by
using these additional partitions.
Well, I would start with the ability to easily transfer data to a larger
drive in the future by using the same drive letter. If SBS supports
spreading volumes across multiple server these would be even more reason.
The plan does not account at all for:
companywide shared data (either sharepoint or the 2000 style 'company
shared folder')
private user shares
roaming profiles or folder redirection (if implemented)
Though you mention CRM is to be installed you seem to have already run out
of space by dedicating it to other tasks.
As indicated in the post you responded to, we already have a file and print
server. We also have a Windows NAS that would provide more than enough space
for the majority of the data you mention. Does Sharepoint require that the
data reside on the application server itself? I am still spreading the
installation across 140 Gb. which matches the amount of space, but not the
organization which you mention below. With 6 drive bays the hot spare is
still available.
I would create a single RAID 5 array using 3 HDD's and the fourth as
hotspare. Total usable space 140GB partitioned as 20GB for OS/Program
installation point and a single DATA partition using the rest, all DATA
(exch/sql databases included) would reside on this partition. I _may_ move
the logfiles to this partition as well.
Raid 5 suffers from a significant performance decrease on it's write
process. In reviewing the Exchange and SQL group the majority of the
postings I read indicate that separating the Application and Data on
different set of drives provides for improved performance. They also offer
strong agruments for using Raid 1 vs. Raid 5 in an Exchange implementation.
I believe thae same reasoning would apply to SQL as well.
One of the most cohesive descriptions of the differences was posted on the
Excahnge group on Feb. 4th. I have pasted it below.
<snip>
The performance hit for mirroring is far less than the performance hit for
RAID 5. RAID 5 is good for applications that require a lot of space, but
have little IO. For IO intensive applications (read Exchange) you want the
best write performance possible. So, to help you understand, let's do the
math.
P = performance in IOPS of a single spindle. Lot's of people like to use
the number 130 for a 10K SCSI spindle. This number is obtained by taking
the average seek time plus the rotational latency and dividing 1 second by
the total. This number does not account for how long each IO will take, nor
what overhead the filsystem takes (NTFS is a journaling filesystem). I
always associate a target IO response time with an IOPS per spindle number.
For a 10K SCSI spindle, if I'm targeting 20ms IOs, that number is 85. for
40ms IOs, that number goes up to 100. At the 60-80ms IO range, yeah 130.
Exchange needs "average 20ms writes with no spikes lasting more than a few
seconds over 50ms". This is quoted from "Optimizing Storage for Exchange
Server 2003" ans is what MOM and other monitoring tools set their alerts
for. So, for a 10K RPM SCSI spindle, P=85 at a target 20ms IO.
N= number of spindles in the array.
N'= number of data spindles in the array. You get this by subtracting the
number of parity spindles from N.
For RAID 5:
read performance = P*N'
write performance=P*N'/4
For RAID 1/10/0+1
read performance=P*N
write performance =P*N/2
A RAID 5 set with 3 10K spindles will see read performance of 170 IOPS and
write performance of 42.5 IOPS at a target 20ms IO.
A mirror with two 10K spindles will see read performance of 170 IOPS and
write performance of 85 IOPS at a target 20ms IO. That's 100% better write
performance.
I hope this helps you get your mind around the performance differences
between RAID 1 and RAID 5.
</snip>
I've been waiting for proponents of the seperate partition for
Exchange/SQL databases to pull me up on a point (I've been involved in
more than a few such discussions), a point I have ignored but thought
about recently. The effect of large database files on Shadow Copy. I
haven't thought this through completely but at 'first level' it would seem
sensible to have such large databases on partitions excluded from Shadow
Copy, relying on the underlying database technology to 'roll back' or
'recover' data rather than allowing them to consume your Shadow Copy
allowance. If this 'pans out' in the manner I'm thinking I may well change
my position to '20GB for OS (turn off shadow copy), xGB for specifically
Shadow Copy excluded files, remaining GB's for Shadow Copy enabled
partition (DATA)'. The partition which holds the files excluded from
shadow copy could also hold the shadow copy data from the standard DATA
partition.
I am not sure on Exchange but for SQL I typically setup a daily backup
procedure within SQL itself to an IDE drive within the machine or on a
shared resource, then perform an offsite backup of that backup file. I am
not knowledgeable enough about Shadow Copy to debate it's merits or best
implementation.
"John" <nospam@xxxxxxxxxx> wrote in message
news:uiCpRqrLGHA.1180@xxxxxxxxxxxxxxxxxxxxxxx
Is there a document that describes the optimal installation locations for
an SBS 2003 Premium installation.
I am setting up a new server. I anticipate creating two hardware mirrors
of approx. 70 Gb. each. I have 6 drive bays available but I would prefer
to keep the 2 open bays for hot spares. If the perfomance increase
justified it, I would give up one of the spare drives to act as a
dedicated swap file location.
We run an additional server for File/Print/RDP so SBS will primarily be
used for Exchange and SQL, with the addition of Microsoft CRM 3.0. on
this installation.
I do not intend to install ISA right now but could add it in the future
for learning purposes. We currently run an external firewall with VPN
connections to multiple networks.
I guess my question(s) is really how I should break up the drives for OS,
Exchange Components, and SQL Components. My original plan was to allocate
as follows:
Mirror 1
First Partition = 20 Gb. for OS
Second Partition = 25 Gb. for SQL Application and other applications
except Exchange.
Third Partition = 25 Gb. for Exchange Application and Exchange Logs.
Mirror 2
First Partition = 40 Gb. for Exhange Mail Storage.
Second Partition = 30 Gb. for SQL Database.
Am I going about this correctly or should I be using a different
configuration?
Thank you.
.
- References:
- SBS 2003 Installation Drives - Folders
- From: John
- Re: SBS 2003 Installation Drives - Folders
- From: SuperGumby [SBS MVP]
- SBS 2003 Installation Drives - Folders
- Prev by Date: RE: <<SMTP protocol event sink>>
- Next by Date: My Document Redirection Problem
- Previous by thread: Re: SBS 2003 Installation Drives - Folders
- Next by thread: Re: SBS 2003/RWW woes
- Index(es):
Relevant Pages
|
|
