RE: FW: Disk capacity planning

• Niall Litchfield <niall.litchfield_at_dial.pipex.com> wrote:
  > Hi
  >
  > The bad news is that I don't believe that
  > calculating IO/Sec *can* be done
  > for a *new* system. At least I'd like to see how it
  > is done. I'm willing to
  > bet that any formula for doing it will include (x%)
  > for 'overhead', which
  > actually means 'stuff I don't know about'. Of course
  > if the *new* system is
  > a replacement for an old system with known IO
  > requirements and the workload
  > is similar (or predictably different) then obviously
  > a calculation/lower
  > bound could be set.
  >
  > (of course if one has the exact data set that you
  > will use, and the IO
  > required by each and every sql statement in use, and
  > the exact number of
  > clients and the exact machine and software
  > configuration that will be used
  > for always then one can measure your IO requirement.
  > I have never seen such
  > a situation.)
  >
  > Actually however I think that this bad news is
  > rather mitigated by the fact
  > that I don't believe that capacity can be calculated
  > ahead of time for a
  > *new* system either. It will entirely depend on the
  > take up of the
  > application and any changes to the design/usage post
  > go-live.
  >
  > I think that that leaves us in a relatively good
  > position, namely that we
  > can estimate values for B,P etc based on our skill,
  > judgement (and budget :(
  > ), and that because none of the figures are *hard*
  > figures it ought to be
  > possible to negotiate *sensible* disk purchases.
  > They key is to take into
  > account all the demands on the system (as Cary
  > says). I'm afraid that for
  > *new* systems though getting into formulae for
  > *calculating* requirements is
  > likely to give false assurances. Time to brush up on
  > negotiating skills (and
  > to find how how to effectivey bribe your sys admin
  > and/or budget holders).
  >
  > Yours unscientifically
  >
  > Niall
  

this is where the z-space kicks in (discreteness). if you're using direct attached storage, the cabinets typically hold 14 drives spread across a split backplane per enclosure.

10 => PCI-X slots open > 0
4 Server PCI-X buses
n dual channel external SCSI RAID controllers n dual channel external SCSI RAID enclosures n*14 => drives > 0

so we will attempt to spread the IO across the PCI-X bus channels, across RAID controller channels, across drives.

so pick the following:

1 cabinet, 1 dual channel SCSI RAID controller, 14 drives

2 cabinets, 2 dual channel SCSI RAID controllers, 28 drives

3 cabinets, 3 dual channel SCSI RAID controllers, 42 drives (we have a winner :) ).

4 cabinets, 4 dual channel SCSI RAID controllers, 56 drives Received on Tue Jan 20 2004 - 13:29:26 CST