Re: Convert RAID1 to RAID5
- From: aus <aus@xxxxxxx>
- Date: Sun, 10 Dec 2006 04:34:32 +0000
Leythos wrote:
In article <OWngAdoGHHA.4688@xxxxxxxxxxxxxxxxxxxx>, aus@xxxxxxx says...Leythos wrote:In article <eN8yCVgGHHA.3304@xxxxxxxxxxxxxxxxxxxx>, aus@xxxxxxx says...So, have you tried (all raid 1):Leythos wrote:Yep, sure do test it and other configs - since we setup higher performance systems we tend to be in the area of performance when it comes to smaller servers too.In article <uqg$pfMGHHA.3268@xxxxxxxxxxxxxxxxxxxx>, aus@xxxxxxx says...With SBS you have a 75 user limit and even with multiple disks you wont see any real difference compared to properly set up mirrors - even with SQL. If you setup a mirrored server with dedicated page file disks (unmirrored) it will match a RAID-5 array for most all applications I have seen (I'm sure there may be exceptions). The difference is using multiple mirrors - not one (and on separate channels) - together with separate page disks. I'm guessing you have never tested this configuration - most don't.I would advise against using the existing disks with new ones to make a new RAID 5 set. I advocate RAID 1 for everything - ine for OS one for data; you wont see any real word difference between mirroring and RAID 5 and there is just so much less to go wrong - a few years of seeing the two options work and fail in many incarnations has convinced me!In a typical R5 array that is installed/setup by small shops, where they have 3xDisk for R5, you are right, but, in a proper setup where you have 5xDisks or more, then you will see a LOT of read performance that you don't get out of a Mirror - this is very much the case when you have LOTS of users accessing the server or have a SQL database that users are hitting.
Wait till you get into more users, on a properly setup server, you'll notice the difference in a heartbeat.
If you setup a RAID-1 for the OS/apps/etc... then install another RAID-0 or RAID-1 or single disk for page file, it's still not as fast as a properly configured system designed for SQL use.
In a typical server, even SBS, using SQL, we like to setup as follows:
Disk 0/1 - R1 - C Drive - OS
Disk 2/3 - R1 - D Drive - SQL Transaction Logs, Applications
Disk 4,5,6,7,8 - R5 - E Drive - SQL Data, User Data
Disk 9,10 - R1 - F Drive - Online backup storage
Disk 11/12 - Online hot spares
If it's a stripped down server, with little room, we do:
Disk 0/1 - R1 - C Drive - OS / SQL Transaction Logs / Applications
Disk 2,3,4,5 - R5 - D Drive - SQL Data / User Apps
On a minimal system we've done the following:
Disk 0/1 R1 - All files/apps/OS, etc...
Disk 2 (or /3) - Page File, Utilities, online backups
[SCSI channel A]
Disk 0/1 - OS
Disk 1/2 - SQL Logs
[SCSI channel B]
Disk 3/4 - SQL data
[on a 3rd non-RAID SCSI controller - so channel C]
Disk 5 - page file/backups
or for the second option (smaller server):
Disk 0/1 - OS
Disk 2/3 - SQL / Data
Disk 4 - Page file / backups
What are the comparative transaction throughput figures you got compared to your variants under the loading tool you use?
We looked at transaction time, after clearing the cache/sql cache and found that reads were quicker on properly setup R5 arrays. Yes, we tested R1/R5, this was a couple years ago, but the technology is still the same.
Remember this is SBS - you aren't going to see your first option hardware setup with SBS very often, you are probably the only person here - I will probably never see that spec. 99% of SBS users will not see any performance difference as there just isn't going to be the loading in the typical setup.
99% of SBS users won't see the difference because 90% of them will never be presented with that option after it's already installed, they'll just buy another server.
I'd say this is wrong. 99% of SBS users just don't have an actual requirement for the sort of bigger setup you mention and would see no difference (in having big R5 arrays) and many don't use SQL either.
Ask here what a typical setup is - the 'standard' shop I see is a 10 - 30 user setup, using Exchange and about a third or less of the time using SQL. You may be in a niche market using SBS on very big servers, possibly to save on SQL license costs, but it's atypical in the SBS market.
So given the non-advatage of R5, the next key point (for me) is the grief you have when RAID 5 fails - too often I have see an array not come back up - and its major time waster; it also runs in what I consider to be an unstable mode while its hashing the data from the existing disks (most SBS RAID 5 users don't actually run a hot spare in my experience).
This together with the advantage that if pushed I can run away with any one disk and still read all it's data contiguously is an ace I like to play very occasionally.
The only time I've ever had a r5 array not recover was when a builder split the array of 6 drives across two channels and they lost 1 channel. I've had many drive failures in R1/R5 and never lost anything, always recovered, and unless it was a improperly setup R5 array, didn't suffer much in the way of performance.
I would say that your 13 disk solution is wrong to put user data and SQL data on the same drive set as they typically have different access profiles - this is generally discouraged - you'd be better to have the user data on a completely separate disk set - specially if this is Exchange data, but I'm assuming you run a separate server for Exchange.
If you are willing to put everything on a R1 array, then my putting randomly read data on a R5 array only improves access and performance - since the more spindles the more one can access at the same time.
The point was re. your specific example - i.e. using a 13 disk setup; to still put SQL and user data together despite having 13 disks isn't best use of the resource. Like having a Ferrari and driving in 3rd gear.
More spindles in one R5 array gives faster access, but "since the more spindles the more one can access at the same time" isn't the same thing.
For the size of server you need to hold all those disks I'd rather plump for 2 leaner servers (not necessarily slower ones) to split the load every time, even with extra licensing requirement.
Except that in most cases a user won't be loading the CPU and it's the Disk performance that hurt them, at least on a properly configured server. So, rather than spending the extra money on a full server, since it's already (the two server option) going to take as many drives, you can just properly build the server the first time and they won't need the extra.
I wasn't thinking CPU. The two server option has many advantages over one huge lump of a server - specifically that of throughput (and somewhat less with CPU - but depends on operation) - e.g. separate network paths, totally separate access to data arrays, totally independent processing, independence of operation (key for me and users re. down time) etc. etc.
HP sells a server that provides for 16 drives, Dual Dual or Dual Quad Core CPU's, and loaded with SBS and 4GB RAM, it's about $16,000, which would support the full complement of 75 concurrent users without a performance loss vs two servers with 75 users needing the same level of space.
Does that include all 16 disks and any CALs?
I usually use Dell - for the same $$ they tend to beat HP with a higher performing box; Dell annoy me in their order processing so I always run a comparative HP quote but HP have never matched the spec. for the $. They also give you an extra discount if you ring them at month or quarter end.
A $16K server is a big beast and I think I would never go with that option - a two server option is just better and would easily beat single server performance due to real concurrency of operation with zero contention for any resource. The thing is it would cost a similar amount to use two smaller boxes - its only the licensing that may be influencing cost (depends on the setup).
Don't get me wrong, I have several clients with Dual 200GB SATA drives in a R1 with 4GB RAM running SBS 2003 Prem, and using SQL with 20 users, but, if I had designed the system from scratch I would have gone with a dedicated RAID Card and 4 drives (since that's all the case can handle) in a hardware R5 setup for performance reasons.
Me too - except it would be two pairs of mirrors ;)
.
- References:
- Convert RAID1 to RAID5
- From: Curtis
- Re: Convert RAID1 to RAID5
- From: aus
- Re: Convert RAID1 to RAID5
- From: aus
- Re: Convert RAID1 to RAID5
- From: aus
- Convert RAID1 to RAID5
- Prev by Date: Re: Connector pop3 download more frequently
- Next by Date: The Mystery Part IV
- Previous by thread: Re: Convert RAID1 to RAID5
- Next by thread: Re: Convert RAID1 to RAID5
- Index(es):
Relevant Pages
|
