| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
Re: [Xen-users] Aoe or iScsi???
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
|
|
|
| |
|
Home