It's interesting that the big disk frames (EMC, Hitachi, IBM Shark)
are (in my experience) configured thusly..
Each frame is populated with disk 'modules', each of which is a pair
of SCSI drives, internally mirrored. These present to the frame as
one drive (ie 2 36G drives look like a single 36G drive). The
modules are then raided with each other, then presented to the hosts in
8G or 14G LUN's or chunks.
And the frames will have 4-8G of read cache and 4-8G of write cache.
Now figure out what the optimal disk layout is....
The OS will then usually group them back together into volume
groups, etc.
Did I get that right?
------------------------------------------------------------------------
Jim Wildman, CISSP jim@rossberry.com
http://www.rossberry.com
On 10 Sep 2002, Ian C. Blenke wrote:
> I've met "old skool" admins that throw their nose up in the air when I
> start explaining my disk layouts and reasoning. This is particularly
> true when you start dealing with old-school DBAs that like dealing with
> "spindles", even though modern SANs abstract the spindle away from the
> host machine and most volume managers like Veritas negate the need to
> care. Sure, you want to avoid head contention if you can help it, but
> when you have 320G on a harddrive and only one head per platter on a
> couple of platters (all on the same arm anyway, already beyond the reach
> of the admin), there's going to be a head contention issue - you simply
> have to make up the seek penalties with caching strategies. Why do you
> think they ship 8M caches on large IDE harddrives today? Drives
> disregard cache flush imperatives from the bus to improve write
> performance, RAID controller cards often do the same from the host OS,
> it gets to the point where you simply have to throw a gob 'o RAM at
> cache anyway, stripe the drives, and divvy up the volumes from virtual
> pools of disk space.
>
> But I digress..
>
> - Ian C. Blenke <icblenke@nks.net> <ian@blenke.com>
> http://ian.blenke.com
>
>
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:15:01 EDT