Re: SBS 2003 Installation Drives - Folders
- From: "John" <nospam@xxxxxxxxxx>
- Date: Sun, 12 Feb 2006 23:58:44 -0500
Leonid,
I guess I should have refreshed my newgroup before posting my response to
SuperGumby. ;-)
Thanks for the confirmation. I typically install these applications on
separate servers not in an SBS environment. I have a bunch of servers that I
can deploy but they are really desinged for single applications. Only one
SCSI connector on the SCA x 6 backplane......The easy, "packaged", aspect to
SBS raised a bunch of questions I did not have answers to.
Thanks again.
I will insert Disc 1 now. :-)
John Miller
SAMnet
"Leonid S. Knyshov" <lknyshov@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:xbqdnfON8b9_cXLenZ2dnUVZ_s2dnZ2d@xxxxxxxxxxxxxx
"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. 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.
The system is overpartitioned. Please explain the benefit you perceive by
using these additional partitions.
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.
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.
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.
Super,
All data inside CRM goes on the SQL partition. Same goes for your
Sharepoint content. Here is some data for the Sharepoint scenario -
http://www.microsoft.com/technet/prodtechnol/sppt/wss/wssipo2d.mspx
All user data goes on the Data partition
Exchange data goes on the Exchange partition
Neither of these has a chance to overflow the disk capacity. Databases are
rather easy to move should the disk capacity come close to being exceeded.
There is ample expansion space on this server either internally or through
addition of another storage array. Budget is obviously not a problem - CRM
licenses are not cheap. Notice that there is an additional file server on
this network already, which makes this mostly an application server.
The natural progression for this server will likely be to deploy SQL for
CRM on a separate member server once SBS R2 is released.
I would say this is close to an ideal configuration in compliance with
most of best practices.
Microsoft supports deploying its integrated applications in different
locations on the same server, but that's where the big C: partition will
come in handy for supporting system updates. It insists on putting a lot
of common files in %WINDIR%, which is a questionable practice, but we'll
see what happens in the next major release.
In this proposed configuration, this server will be very easy to bring
back online due to compartmentalization. Typically, the users would not
notice the disk failure. I could probably do a functional rebuild in an
hour or so. CRM is a mission-crtical application that is required for
sales and customer support. While it is offline, salespeople will be able
to continue to work in disconnected mode and continue being productive,
however they wouldn't be able to synchronize their changes until the
server is back online. More importantly to the company's image, CRM is a
customer support tool. If a customer calls in, then the customer support
team will have a problem getting the records, which is not good.
In case of RAID5, I would not be able to bring the system back that
quickly if solely due to rebuild requirements. Also, writing transaction
logs is a sequential operation, which carries a performance penalty of up
to 80% in a RAID5 scenario. This alone would slow down the entire array.
Lastly, history suggests that RAID5 arrays are more susceptible to
intermittent data corruption, which makes them a little more challenging
to rebuild. There is not a single best practices document that would
support putting both parts of the equation on the same disk, not to
mention same array. That's so for a good reason. :-)
I am perfectly fine with using RAID5 for heavy-read file servers that can
simply be rebuilt from backups as the risk there is minimal. Performance
degradation in addition to added risk of data corruption make me not
recommend it as a solution for an application or messaging server data
storage confguration.
The first thing we do if we have to recover a dead server for a new client
is rebuild its arrays to the best practices specification. Very frequently
the failed arrays are indeed RAID5 and involve rather tricky data
recovery. :-)
Now to address Shadow Copy... The technology covers shares, and database
files are not shared. Data Protection Manager further extends VSS, but
it's not a factor in this particular situation. Your shadow copies are
deltas of the original files, so if the original volume is corrupt, it
does not help much.
--
Leonid S. Knyshov, CEO
Crashproof Solutions, LLC - http://www.crashproofsolutions.com
MCP Exchange 2003/Small Business Server 2003, CCNA, SCSA 8, NCIE
Microsoft Small Business Specialist Partner
.
- References:
- SBS 2003 Installation Drives - Folders
- From: John
- Re: SBS 2003 Installation Drives - Folders
- From: SuperGumby [SBS MVP]
- Re: SBS 2003 Installation Drives - Folders
- From: Leonid S. Knyshov
- SBS 2003 Installation Drives - Folders
- Prev by Date: Re: POP3 Connector and Spam Filtering
- Next by Date: Re: SBS 2003 Installation Drives - Folders
- Previous by thread: Re: SBS 2003 Installation Drives - Folders
- Next by thread: Re: SBS 2003 Installation Drives - Folders
- Index(es):
Relevant Pages
|
Loading
