Re: [Xen-users] Aoe or iScsi???

[Gilberto Nunes <gilberto.nunes@xxxxxxxxxxxxxxx>]

hi again...

I'm try to replace vblade to ggaoed, but I don't know how to use it...
I'm already installed it on server side, but I don't know how use it on
client side...
Perhaps I can use aoetools too???

Please, somebody can point some how to???

Thanks a lot


Em Seg, 2010-07-05 Ãs 19:45 +0200, Bart Coninckx escreveu:
> On Monday 05 July 2010 18:43:20 Adi Kriegisch wrote:
> > Hi!
> > 
> > > I run bonnie++ like this:
> > > bonnie++ -d /tmp/ -s 1000 -r 500 -n 1 -x 1 -u root |  bon_csv2txt >
> > > test.txt
> > 
> > just checking: your storage server has 500MB RAM? (-r)
> > 
> > > This is the result:
> > >
> > > Version  1.03c      ------Sequential Output------ --Sequential Input-
> > > --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> > > Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP 
> > > /sec %CP bacula-selbet 1000M 53004  98 189796  37 97783  17 62844  99
> > > 1505552  99 +++++
> > 
> > [SNIP]
> > 
> > > It's tell something?
> > 
> > Ja, your storage system can handle ~190MB/s sequential write. This means
> > you will not get full peak performance to your clients as one gigabit
> > interface is limited with 120MB/s.
> > Your write speed (1,15GB/s) shows that you misspecified RAM size on your
> > bonnie commandline because this is _WAY_ beyond what your disks are able to
> > handle. (Good SATA disks will give you above 100MB/s read speed. Reading at
> > that speed hints at 15 or more disks; the limit there is definitely bus
> > speed and administrative overhead.)
> > 
> > What you are really interested in (or should be) are IOPS (Input Output
> > Operations per Second): A typical server or workstation no matter if
> > virtual or 'real' does a mixture between sequential and random I/O.
> > Every server you run has its own partition on your storage backend. Just to
> > get a better idea of what I am talking about consider the following:
> > Every virtual machine does a sequential file read. What does that mean on
> > the storage backend? -- There are 13 files being read at 13 different
> > positions at the same time. This is a (close to) random I/O workload. Disk
> > heads are flying around to satisfy all requests. No way you will be close
> > to any high MB/s value: your disks are doing random I/O.
> > Measuring sequential peak performances on network storage is pointless for
> > this very reason. (People on this list were suggesting to do that just to
> > verify your disk subsystem works fine.)
> > To get an idea of what performance you might expect, you can do the
> > following:
> > 1. calculate IOPS that you might expect. You may use one of the online
> >    calculators that are available[1].
> >    This begins with calculating IOPS per disk where you might need to
> >    consult your vendor's datasheet or lookup the disks here[2]. You'll
> >    immediately notice that SAS disks offer twice or more IOPS than SATA
> >    drives.
> >    When calculating IOPS you need to specify a workload as well. This means
> >    specify the read/write ratio. Average fileservers have around 80% read
> >    and 20% write. Read and write operations differ in the latency they
> >    have: The more latency a request has the fewer requests can be handled
> >    per second. (This is also the reason why local storage will always bring
> >    more IOPS than network storage: network transport simply adds to
> >  latency.) 2. measure the IOPS you get. I personally prefer using FIO[3]
> >  which is readily available in Debian. FIO is fully configurable; there are
> >  however some reasonable examples which you might use:
> >    /usr/share/doc/fio/examples/iometer-file-access-server mimiks a typical
> >    file server workload with 80% read. The IOPS calculator above[1] is only
> >    able to calculate IOPS for a fixed block size where this workload mixes
> >    blocksizes from 512byte to 64k. The result in IOPS cannot be directly
> >    compared. If you want to do so, you need to specify 4k blocks only in
> >  the config.
> >    WARNING: Do not use IOMeter itself on linux: it provides incorrect
> >    results as it cannot use aio on linux and therefor is unable to queue
> >    requests.
> >    Using the stock 'iometer-file-access-server' profile you should get the
> >    something like:
> >    3 disks/RAID5: 200-250 IOPS
> >    4 disks/RAID5: 270-320 IOPS
> >    5 disks/RAID5: 340-390 IOPS
> >    and so on (for SATA disks with AoE).
> > 3. find the bottleneck in case you're not getting what you can expect.
> >    Measure IOPS on the storage server with 'iostat 1' ("tps" roughly
> >    corresponds to IOPS).
> >    ...ok, writing up how to debug a storage backend will take another
> >    hour... ask me if necessary.
> > 
> > -- Adi
> > 
> > [1] http://www.wmarow.com/strcalc/
> > [2] http://www.wmarow.com/strdir/hdd/
> > [3] http://freshmeat.net/projects/fio
> > 
> > PS: Maybe there should be a wiki page about how to plan and implement a
> > storage backend for a xen server? -- then others can add their knowledge
> > more easily.
> > ...and the question pops up every once in a while.
> > 
> 
> Adi, most educational, thank you.
> 
> B.
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users

Gilberto Nunes
TI
Selbetti GestÃo de Documentos
Telefone: +55 (47) 3441-6004
Celular: +55 (47) 8861-6672




_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users