Re: I/O performance for dummys
- From: dougm <dougm1964'@t'hotmail.com>
- Date: Sat, 11 Mar 2006 00:07:04 GMT
Gary Mills wrote:
We are in the process of setting up an iSCSI SAN, using our Netapplet me toss into the mix the use of Jumbo ethernet frames. Depending on the application it makes a huge difference on iscsi performance. Of course you can't use the qlogic HBA's (I'm assuming 4010c?) but the solaris iscsi initiator. Then you need to have a nic, switches and iscsi target connection that supports them.
filer for storage. I asked our storage guy to do some I/O testing,
just to be sure that the SAN was delivering reasonable I/O
performance. We used several spare servers for this test:
1) A 4-CPU E450 with 3 gigs of memory running Solaris 10.
It has a Qlogic iSCSI HBA.
2) A single-CPU V100 with 1 gig of memory running Solaris Nevada 27a.
It's using the software iSCSI initiator.
3) A single-CPU V210 with 512 megs of memory running Solaris 9.
It also has a Qlogic iSCSI HBA.
None of us have any experience with I/O benchmarks. Our storage guy
tried several of these. One is `iozone'. I don't know what the
others were. He compared UFS on iSCSI with UFS on a local disk and
with NFS, and reported that on a given server there was little
difference. He also reported higher performance on the newer servers,
the ones with faster CPUs, even though CPU usage was low.
How should we be doing this? Should we be testing raw devices, rather
than UFS? What should be the limiting factor in I/O performance in
this sort of configuration? All I really want is to be able to say
that by connecting a server to our SAN we can supply a certain amount
of storage capacity with a certain amount of I/O performance. Is this
even possible?
We're implementing a pair of x4200's, a pair of DNF ipBank iscsi SAN's, a pair of HP 3400cl switches with a 10 gig backbone between them. Each respective server, san and switch combo will be physically located in separate buildings. 1/2 of each san will be mirrored to the other san in the other building (at the san level.) The remaining 1/2 of the san (4.x TB?) will be used as the campus filestore for the students (server 1) and fac/staff (server 2.) The iscsi "network" will be separate from the server (->customer) network. So isolation of the iscsi traffic solely to servers, backups and san->san replication with the 10gig backbone will be extremely robust.
Performance testing so far has shown that manipulation of files > 100meg see a benefit from jumbo frames. Smaller files show a network hit but nothing taxing with a 10gig link. The io tests I did were more real world than a specific i/o test package. Namely 300 volunteers simultaneously accessing a SMB share and reading and writing files of around 10 to 300 meg. The same test was performed with an NFS share through the firewall to a blade 100 which really choked on about 30 users because of cpu/memory limits. We really limit NFS shares to services requiring them. We then did a test of an NFS mount from the server to a mac X-Serve which shared out AFP volumes. Still no real performance bottlenecks on i/o. I can give you more details and specs if you like but it wasn't testing for "specs" but testing for real world use. We used v20z's for the samba/nfs servers, a variety of iscsi targets (Starwind on windows, DNF ipBank, Celeros, lefthand network) and other than starwind (a software solution) they performed pretty much the same. The comparison then devolved into price/performance. ipBank seems to be the winner.
Sorry this got so long,
Doug
.
- Follow-Ups:
- Re: I/O performance for dummys
- From: Gary Mills
- Re: I/O performance for dummys
- References:
- I/O performance for dummys
- From: Gary Mills
- I/O performance for dummys
- Prev by Date: Re: TSL-A500C Tape Drive
- Next by Date: Re: top command
- Previous by thread: Re: I/O performance for dummys
- Next by thread: Re: I/O performance for dummys
- Index(es):
Relevant Pages
|
