toasters November 2006

toasters@lists.teaparty.net

53 participants
50 discussions

RE: simple SAN?!
by Davies,Matt 23 Nov '06

23 Nov '06

On the VMware side, as far as I understand you can only use FC to the physical machine, not to a virtual machine, as the VM's do not support FC. I believe you can still use VCB with Iscsi, it just needs a bit more scripting, I would check out the VMware discussion groups on the VMware website, I have always found them very helpful. Cheers Matt ________________________________ From: Willeke, Jochen [mailto:Jochen.Willeke@wincor-nixdorf.com] Sent: 23 November 2006 11:07 To: Davies,Matt; toasters(a)mathworks.com Subject: RE: simple SAN?! We already use ISCSI, but we aer thinking about VMWare and VMWare has some nice features (e.g. VCB) which need an FC-SAN. Thanks anyway Jochen ________________________________ From: Davies,Matt [mailto:MDAVIES@generalatlantic.com] Sent: Thursday, November 23, 2006 11:59 AM To: Willeke, Jochen; toasters(a)mathworks.com Subject: RE: simple SAN?! If you are looking at low cost san, I would go Iscsi, as long as everything you need on Iscsi is on Gig ethernet ports, it should work fine. Cheers Matt ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Willeke, Jochen Sent: 23 November 2006 10:11 To: toasters(a)mathworks.com Subject: simple SAN?! Hi, as we use not too much SAN at our site i am not really used to this topic. Yesterday i read an article about "simple SAN". "Simple SAN" seems to mean as an plug-n-play solution. But what about the components espacially the SAN-switches? Do we see really new (and cheap :D) SAN-switches or only old products "reassembled" as a solution for small companies. Regards Jochen

2 1

RE: simple SAN?!
by Davies,Matt 23 Nov '06

23 Nov '06

If you are looking at low cost san, I would go Iscsi, as long as everything you need on Iscsi is on Gig ethernet ports, it should work fine. Cheers Matt ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Willeke, Jochen Sent: 23 November 2006 10:11 To: toasters(a)mathworks.com Subject: simple SAN?! Hi, as we use not too much SAN at our site i am not really used to this topic. Yesterday i read an article about "simple SAN". "Simple SAN" seems to mean as an plug-n-play solution. But what about the components espacially the SAN-switches? Do we see really new (and cheap :D) SAN-switches or only old products "reassembled" as a solution for small companies. Regards Jochen

2 1

iSCSI SAN Queries
by Raj Patel 23 Nov '06

23 Nov '06

Hi, We're in the preliminary scoping phase for a low/mid-range iSCSI SAN solution. I was wondering if anyone had any positive or negative real-world experiences with - NetApp 270c HDS AMS200 EMC CX320 At the moment the NetApp is the most familiar to me as I have used one of their NAS boxes before and the simulator provides a pretty good indication of how it works. However the iSCSI seems a bit of a 'bolt-on' and its not clear if it will handle tiered storage as well as the other vendors (then again does it matter?). The HDS & EMC are unknown quantities (other than what I can glean from the web). Any feedback concerning ease of use, expansion, licensing, snapshot mechanism (the EMC seems clunky from their literature but I don't know if that's the case in operation). Also does anyone have any iSCSI 'gotchas' ? Is a TOE one of those 'nice to have but not really necessary' things on a modern server or should it be factored into the solution ? Cheers, Raj.

4 4

RE: iSCSI SAN Queries
by Learmonth, Peter 22 Nov '06

22 Nov '06

That page is mostly links to other docs, most of which are external. http://www.netapp.com/library/tr/3250.pdf http://www.netapp.com/library/tr/3338.pdf http://www.netapp.com/library/tr/3357.pdf http://www.netapp.com/library/tr/3323.pdf http://www.netapp.com/library/tr/3376.pdf http://support.microsoft.com/default.aspx?scid=kb;en-us;305547 http://www.netapp.com/library/tr/3302.pdf http://www.netapp.com/library/tr/3280.pdf Share and enjoy! Peter ________________________________ From: Raj Patel [mailto:phigmov@gmail.com] Sent: Wednesday, November 22, 2006 11:24 AM To: toasters(a)mathworks.com Subject: Re: iSCSI SAN Queries >http://now.netapp.com/NOW/knowledge/docs/bpg/san_ipsan/man_admin_iscsi. shtml One slight annoyance is that this site is member only and basic membership doesn't let you get to this page (Cisco has something similar on their site and its just as aggravating). The EMC page did come straight up though. I'll see if I can get the doc out of a local NetApp vendor. Cheers, Raj. On 11/23/06, Julio Calderon <jcalderon(a)agami.com> wrote: Thanks for sharing your findings. Rule of thumb, regardless of what vendor you choose to go with, review their specific best practices Netapp has them here: http://now.netapp.com/NOW/knowledge/docs/bpg/san_ipsan/man_admin_iscsi.s html EMC has them here: http://www.emc.com/techlib/pdf/H1784_Celerra_iSCSI_Solutions_MS_Exch_ldv .pdf Hitachi, I looked but could not find their best practices. My personal recommendation is to review what other vendors have to offer as well. If you do a quick search on the net, you will find many. Best Regards, Julio C.

1 0

RE: iSCSI SAN Queries
by Pichardo, Socrates 22 Nov '06

22 Nov '06

Greetings and salutations, We have deployed, quite successfully, Netapp 3020 with iSCSI for all our Exchange and SQL servers. This solution has been in prod for more than a year now and the issues that we have seen are not directly related to iSCSI. Of course, we did put in place some safe guards that we believe has made the whole solution more reliable like: - Run complete separate network for our iSCSI traffic. - TOE cards for our heavy-duty servers. - Overcapacity on our filer heads. We did this since our iSCSI decision had nothing to do with cost (which at the time of the RFP FC was still significantly more expensive than iSCSI) but with our desire to keep our installation simple and not having to bring a new protocol/environment (FC) under our management. iSCSI has proven to be as fast, reliable and cost effective as we expected it without the steep learning curve of FC. Here are a few findings: - TOE: On our lab we saw a 7%to 12% CPU savings by using them therefore we did not justify them for performance reasons but we ended up using them for SAN booting requirements. - iSCSI Performance: on our lab/RPF we noticed better performance out of FC under heavy load conditions. Under our expected loads (low to average), we did not noticed any significance performance gains on FC over iSCSI. - iSCSI Implementation: We also noticed that a year ago iSCSI looked like an "add-on" to most of the SAN vendors we spoke with. We selected Netapp for their simplicity and easy of management and both have been proven to be true. Regards, SPV ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Julio Calderon Sent: Tuesday, November 21, 2006 9:21 PM To: Raj Patel; toasters(a)mathworks.com Subject: RE: iSCSI SAN Queries Greetings, I've had first hand experience with Netapp 270s / iSCSI on couple of windows host. (past life) Nutshell: SLOW, don't try exchange on it, it kept timing out on me. I've also seen a large client have issues with Lotus notes when using Gfilers 980c and HDS as the backend storage. (this was a poor configuration issue, too many LUNs over a 1 gig connection) I've also tried it for another purposes and I lost my LUN a few times. The only way of getting it back then was by restarting the client! not a fun thing to do when you are running multiple apps on the same server. Suggestion would be, directly attach application servers via GigE across to your iSCSI device. If direct connecting your app servers is not realistic. use VLANs to segregate traffic, dedicate iSCSI traffic to a set of bonded ports. Start slow, make sure that the number of LUNs being provisioned to the app servers are provisioned in a control manner. (meaning, see how your application behaves in a controlled environment before doing any big role out) Monitor performance, use a testing tool (iozone) to see how much performance you would gain or loose from moving away from current solution. Also, consider the advantages and disadvantages an iSCSI solution would bring your environment. (replication, HA, speed, easy of management, backup, etc) TOE ? I think that the purpose of having iSCSI in your environment is to lower the investment of FC (SAN) solution by leveraging your current network infrastructure and current staff expertise so, if you start purchasing the TOE cards, you will in fact start cutting into the savings a properly architected and managed IP SAN (iscsi) solution would offer your company. I have not had the opportunity to try a TOE card nor have I needed it to yet since I am able to reach almost wire speeds on GigE at the moment. Can not comment on the HDS and EMC solutions but I can't believe they would be better than what Netapp has to offer since their main business is in the FC world. Hope this helps guide you! Best Regards, Julio Calderon West Region - Systems Engineer agami <http://www.agami.com/> 1269 Innsbruck Drive <http://maps.google.com/maps?q=1269+Innsbruck+Drive%2CSunnyvale%2CCA+940 89%2CUSA&hl=en> Sunnyvale, CA 94089 USA Work: 408.349.0414 Mobile: 408.394.5638 Fax: 408.349.0393 Email: jcalderon(a)agami.com <mailto:jcalderon@agami.com> IM: juliocus (Yahoo) Want a signature like this? <http://www.linkedin.com/e/sig/2105155/> ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Raj Patel Sent: Tuesday, November 21, 2006 11:40 AM To: toasters(a)mathworks.com Subject: iSCSI SAN Queries Hi, We're in the preliminary scoping phase for a low/mid-range iSCSI SAN solution. I was wondering if anyone had any positive or negative real-world experiences with - NetApp 270c HDS AMS200 EMC CX320 At the moment the NetApp is the most familiar to me as I have used one of their NAS boxes before and the simulator provides a pretty good indication of how it works. However the iSCSI seems a bit of a 'bolt-on' and its not clear if it will handle tiered storage as well as the other vendors (then again does it matter?). The HDS & EMC are unknown quantities (other than what I can glean from the web). Any feedback concerning ease of use, expansion, licensing, snapshot mechanism (the EMC seems clunky from their literature but I don't know if that's the case in operation). Also does anyone have any iSCSI 'gotchas' ? Is a TOE one of those 'nice to have but not really necessary' things on a modern server or should it be factored into the solution ? Cheers, Raj. <font size="2">"IMPORTANT NOTICE: The information in this email (and any attachments hereto) is confidential and may be protected by legal privileges and work product immunities. If you are not the intended recipient, you must not use or disseminate the information. Receipt by anyone other than the intended recipient is not a waiver of any attorney-client or work product privilege. If you have received this email in error, please immediately notify me by "Reply" command and permanently delete the original and any copies or printouts thereof. Although this email and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Transatlantic Reinsurance Company or its subsidiaries or affiliates either jointly or severally, for any loss or damage arising in any way from its use."</font>

3 2

RE: iSCSI SAN Queries
by Ledbetter, Charles 22 Nov '06

22 Nov '06

Julio pretty well summed things up. Think of iSCSI as iSAN. It's still a SAN setup and the blocks move over the very same SCSI protocol. Whether it's SCSI over FCP or SCSI over IP makes no real difference. With that in mind, you should treat your iSAN setups with the same consideration as SAN. Dedicated links, VLANs, etc. A TOE card should only be deployed once you know you need one. Start with a standard host NIC and watch your host's CPU. If it's being driven to capacity, a TOE or iSCSI HBA will help. If it's not, you're really just wasting money. -Charles -----Original Message----- From: Julio Calderon [mailto:jcalderon@agami.com] Sent: Tuesday, November 21, 2006 9:21 PM To: Raj Patel; toasters(a)mathworks.com Subject: RE: iSCSI SAN Queries Greetings, I've had first hand experience with Netapp 270s / iSCSI on couple of windows host. (past life) Nutshell: SLOW, don't try exchange on it, it kept timing out on me. I've also seen a large client have issues with Lotus notes when using Gfilers 980c and HDS as the backend storage. (this was a poor configuration issue, too many LUNs over a 1 gig connection) I've also tried it for another purposes and I lost my LUN a few times. The only way of getting it back then was by restarting the client! not a fun thing to do when you are running multiple apps on the same server. Suggestion would be, directly attach application servers via GigE across to your iSCSI device. If direct connecting your app servers is not realistic. use VLANs to segregate traffic, dedicate iSCSI traffic to a set of bonded ports. Start slow, make sure that the number of LUNs being provisioned to the app servers are provisioned in a control manner. (meaning, see how your application behaves in a controlled environment before doing any big role out) Monitor performance, use a testing tool (iozone) to see how much performance you would gain or loose from moving away from current solution. Also, consider the advantages and disadvantages an iSCSI solution would bring your environment. (replication, HA, speed, easy of management, backup, etc) TOE ? I think that the purpose of having iSCSI in your environment is to lower the investment of FC (SAN) solution by leveraging your current network infrastructure and current staff expertise so, if you start purchasing the TOE cards, you will in fact start cutting into the savings a properly architected and managed IP SAN (iscsi) solution would offer your company. I have not had the opportunity to try a TOE card nor have I needed it to yet since I am able to reach almost wire speeds on GigE at the moment. Can not comment on the HDS and EMC solutions but I can't believe they would be better than what Netapp has to offer since their main business is in the FC world. Hope this helps guide you! Best Regards, Julio Calderon West Region - Systems Engineer agami <http://www.agami.com/> 1269 Innsbruck Drive <http://maps.google.com/maps?q=1269+Innsbruck+Drive%2CSunnyvale%2CCA+940 89%2CUSA&hl=en> Sunnyvale, CA 94089 USA Work: 408.349.0414 Mobile: 408.394.5638 Fax: 408.349.0393 Email: jcalderon(a)agami.com IM: juliocus (Yahoo) Want a signature like this? <http://www.linkedin.com/e/sig/2105155/> _____ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Raj Patel Sent: Tuesday, November 21, 2006 11:40 AM To: toasters(a)mathworks.com Subject: iSCSI SAN Queries Hi, We're in the preliminary scoping phase for a low/mid-range iSCSI SAN solution. I was wondering if anyone had any positive or negative real-world experiences with - NetApp 270c HDS AMS200 EMC CX320 At the moment the NetApp is the most familiar to me as I have used one of their NAS boxes before and the simulator provides a pretty good indication of how it works. However the iSCSI seems a bit of a 'bolt-on' and its not clear if it will handle tiered storage as well as the other vendors (then again does it matter?). The HDS & EMC are unknown quantities (other than what I can glean from the web). Any feedback concerning ease of use, expansion, licensing, snapshot mechanism (the EMC seems clunky from their literature but I don't know if that's the case in operation). Also does anyone have any iSCSI 'gotchas' ? Is a TOE one of those 'nice to have but not really necessary' things on a modern server or should it be factored into the solution ? Cheers, Raj.

1 0

Problem mounting NFS from a Fedora Core 6 machine
by Gustavo Chaves 22 Nov '06

22 Nov '06

Hello, We have a F760 running Data Ontap 6.4.5. (Pretty old stuff, I know.) The filer has six network interfaces, each one connected to a different network. Recently we started experimenting with a Linux Fedora Core 6 machine. When we try to mount some directory at the filer from this machine, almost always the process hang. A very few times the process succeeds. Investigating the issue using tcpdump I discovered that in the process of mouting, when the filer's portmapper answers to the Linux box, sometimes its answers come from a different network interface and the Linux box doesn't like that. See below the history of an unsuccessful mount. The Linux box (10.202.40.66) tries to mount a directory from filer (10.202.48.109) with the following command and hangs until I kill it: mount filer:/vol/vol0/unix/config /mnt Note that on packet 111 the linux box sends a UDP packet to the filer's portmapper asking for the port number of the MOUNT service. The filer responds with packet 113, which comes from another of its interfaces (10.202.40.23). This response is rejected by the linux box with the ICMP packet number 114. If I try to mount specifying the interface 10.202.40.23, which is in the same network as the client, the mount succeeds. It seems that the portmapper response always tries to go back through the interface in the same network as the client. The problem is that we have some linux clients on networks on which there is no filer interface connected. In these cases it seems to be anyone's guess through which interface the portmapper response will come. We looked for differences in the TCP stack from Fedora Core 5 to 6, because until Core 5 this problem didn't arise, but we couldn't find anything relevant. Since the filer works ok with other Linux and Solaris machines, it seems that something must have been changed in the Linux kernel that made it more strict. We suspected of some firewall rules, but there is no iptables rules configured in the linux box. Has anybody seen this before? Any clue? Thank you. Gustavo. ---------------------------------------------------------------------- No. Time Source Destination Protocol Info 94 1.036676 10.202.40.66 10.202.48.109 TCP 33614 > sunrpc [SYN] Seq=0 Len=0 MSS=1460 TSV=16336999 TSER=0 WS=6 95 1.038301 10.202.48.109 10.202.40.66 TCP sunrpc > 33614 [SYN, ACK] Seq=0 Ack=1 Win=8760 Len=0 MSS=1460 WS=0 TSV=242744087 TSER=16336999 96 1.038319 10.202.40.66 10.202.48.109 TCP 33614 > sunrpc [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=16336999 TSER=242744087 97 1.038385 10.202.40.66 10.202.48.109 Portmap V2 GETPORT Call (Reply In 98) NFS(100003) V:3 TCP 98 1.039907 10.202.48.109 10.202.40.66 Portmap V2 GETPORT Reply (Call In 97) Port:2049 99 1.039914 10.202.40.66 10.202.48.109 TCP 33614 > sunrpc [ACK] Seq=61 Ack=33 Win=5888 Len=0 TSV=16337000 TSER=242744087 100 1.039939 10.202.40.66 10.202.48.109 TCP 33614 > sunrpc [FIN, ACK] Seq=61 Ack=33 Win=5888 Len=0 TSV=16337000 TSER=242744087 101 1.039966 10.202.40.66 10.202.48.109 TCP 34612 > nfs [SYN] Seq=0 Len=0 MSS=1460 TSV=16337000 TSER=0 WS=6 102 1.040592 10.202.48.109 10.202.40.66 TCP sunrpc > 33614 [ACK] Seq=33 Ack=62 Win=8760 Len=0 TSV=242744087 TSER=16337000 103 1.040669 10.202.48.109 10.202.40.66 TCP nfs > 34612 [SYN, ACK] Seq=0 Ack=1 Win=26280 Len=0 MSS=1460 WS=0 TSV=242744087 TSER=16337000 104 1.040677 10.202.40.66 10.202.48.109 TCP 34612 > nfs [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=16337000 TSER=242744087 105 1.040722 10.202.40.66 10.202.48.109 TCP [TCP segment of a reassembled PDU] 106 1.040849 10.202.48.109 10.202.40.66 TCP sunrpc > 33614 [FIN, ACK] Seq=33 Ack=62 Win=8760 Len=0 TSV=242744087 TSER=16337000 107 1.040856 10.202.40.66 10.202.48.109 TCP 33614 > sunrpc [ACK] Seq=62 Ack=34 Win=5888 Len=0 TSV=16337000 TSER=242744087 108 1.041776 10.202.48.109 10.202.40.66 NFS V3 NULL Reply (Call In 105) 109 1.041782 10.202.40.66 10.202.48.109 TCP 34612 > nfs [ACK] Seq=45 Ack=33 Win=5888 Len=0 TSV=16337000 TSER=242744087 110 1.041801 10.202.40.66 10.202.48.109 TCP 34612 > nfs [FIN, ACK] Seq=45 Ack=33 Win=5888 Len=0 TSV=16337000 TSER=242744087 111 1.041847 10.202.40.66 10.202.48.109 Portmap V2 GETPORT Call (Reply In 113) MOUNT(100005) V:3 UDP 112 1.042834 10.202.48.109 10.202.40.66 TCP nfs > 34612 [ACK] Seq=33 Ack=46 Win=26280 Len=0 TSV=242744087 TSER=16337000 113 1.042842 10.202.40.23 10.202.40.66 Portmap V2 GETPORT Reply (Call In 111) Port:4046 114 1.042851 10.202.40.66 10.202.40.23 ICMP Destination unreachable (Port unreachable) 115 1.042854 10.202.48.109 10.202.40.66 TCP nfs > 34612 [FIN, ACK] Seq=33 Ack=46 Win=26280 Len=0 TSV=242744087 TSER=16337000 116 1.042857 10.202.40.66 10.202.48.109 TCP 34612 > nfs [ACK] Seq=46 Ack=34 Win=5888 Len=0 TSV=16337000 TSER=242744087

1 0

RE: iSCSI SAN Queries
by Christopher Mende 21 Nov '06

21 Nov '06

I can't comment much on the other vendors' most current offerings, but iSCSI is anything but bolt-on for the filers. NetApp has the lion's share of iSCSI deployments worldwide. FAS270 (including clusters) running iSCSI configurations supporting Exchange, SQL, and all varieties of other applications are going in all over the place. With a FAS270c, tiered storage (mixing FC & SATA) is possible, with certain conditions. All secondary shelves are either SATA OR FC. From the system configuration guide: Caution 2: While both types of disk shelves can connect to the filer, if there is an existing DiskShelf14mk2 FC connected to the FAS270/FAS270c, then any additional expansion shelf must be a DiskShelf14mk2 FC. If however, you do not have an expansion shelf connected to the FAS270/FAS270c, then you can choose to connect to a loop of DiskShelf14mk2 AT or a loop of DiskShelf14mk2 FC, but not both. The FAS270/FAS270c does not support both types of disk shelves on the same loop. ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Raj Patel Sent: Wednesday, 22 November 2006 8:40 a.m. To: toasters(a)mathworks.com Subject: iSCSI SAN Queries Hi, We're in the preliminary scoping phase for a low/mid-range iSCSI SAN solution. I was wondering if anyone had any positive or negative real-world experiences with - NetApp 270c HDS AMS200 EMC CX320 At the moment the NetApp is the most familiar to me as I have used one of their NAS boxes before and the simulator provides a pretty good indication of how it works. However the iSCSI seems a bit of a 'bolt-on' and its not clear if it will handle tiered storage as well as the other vendors (then again does it matter?). The HDS & EMC are unknown quantities (other than what I can glean from the web). Any feedback concerning ease of use, expansion, licensing, snapshot mechanism (the EMC seems clunky from their literature but I don't know if that's the case in operation). Also does anyone have any iSCSI 'gotchas' ? Is a TOE one of those 'nice to have but not really necessary' things on a modern server or should it be factored into the solution ? Cheers, Raj. The information contained in this email is privileged and confidential and intended for the addressee only. If you are not the intended recipient, you are asked to respect that confidentiality and not disclose, copy or make use of its contents. If received in error you are asked to destroy this email and contact the sender immediately. Your assistance is appreciated.

1 0

IBM Branded NetApps
by Raj Patel 19 Nov '06

19 Nov '06

Hi all, A few quick queries - Has anyone had any experience with the IBM Branded NetApp's ? What does the N5200 compare with in the NetApp family ? How does service/support differ from NetApp ? Finally why would anyone go with IBM for a NetApp rather than NetApp direct (is it purely a question of vendor service quality or is there a significant price difference) ? Thanks in advance, Raj.

7 8

RE: Measuring Filer Performance
by Willeke, Jochen 16 Nov '06

16 Nov '06

Hi, i agree that latency is one of the main factors. But sometimes i wonder how to measure the latency the best way. One way i know is to use "tethereal -i [interface] -z rpc,rtt,100003,3" Which gives me an overview of the rtt which is seen by the client. But i am not so sure what to use to see the output from the filer. I know that statit gives me some kind of rtt for each disk. But where do you get a good overall-response-time for your filers from? Those counters shown by Blake (...stat show...) are very good, but i think they only show what the head sees. What is a reasonable value to be added as an "head-overhead". For example: - I run tethereal from a direct-attached client and see a read-rtt of 12ms - I run stat show -i 1 nfsv3:nfs:nfsv3_read_latency and see 3ms - I run a ping from the direct-attached client and get a rtt of 2ms - So i would think that the filer-overhead is ~7ms Do you think this is correct way to go? Best Regards Jochen -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Walker Sent: Thursday, November 16, 2006 4:25 AM To: Blake Golliher; George, Andrew Cc: Rohit; toasters(a)mathworks.com Subject: RE: Measuring Filer Performance I'd agree with the latency standpoint. It's a good metric to determine when the users will start to bitch. The latency might be hidden by the application, but it depends on how well it's written (single threaded vs multi threaded\low concurrency vs high concurrency). Typically, this is all a function of CPU\DISK (and sometimes memory) load. As a result, those are good to watch, and they are a direct result of the overall workload (CIFS\NFS\iSCSI IOPS). The hard part is determining what\why the workload tanks. Most times, users are only going to feel impact if there is a long running event that generates high latency - however, depending on workload, a single spike that lasts only moments (a second or two) can be devastating: this is where knowing your environment comes in handy. Glenn -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Blake Golliher Sent: Wednesday, November 15, 2006 7:08 PM To: George, Andrew Cc: Rohit; toasters(a)mathworks.com Subject: Re: Measuring Filer Performance Latency is primary for what most of what my filers are doing. Usually watched via nfs_hist (being sure to -z the stats), or using stats all wrapped up in a shell script. rsh $FILER 'priv set -q diag ; stats show -i $INTER -n $SAMPLES volume:$VOL:avg_latency volume:$VOL:total_ops volume:$VOL:read_latency volume:$VOL:read_ops volume:$VOL:write_latency volume:$VOL:write_ops volume:$VOL:other_latency volume:$VOL:other_ops volume:$VOL:nfs_read_latency volume:$VOL:nfs_read_ops volume:$VOL:nfs_write_latency volume:$VOL:nfs_write_ops volume:$VOL:nfs_other_latency volume:$VOL:nfs_other_ops' nfsv3:nfs:nfsv3_avg_op_latency nfsv3:nfs:nfsv3_op_percent nfsv3:nfs:nfsv3_write_ops nfsv3:nfs:nfsv3_write_latency nfsv3:nfs:nfsv3_read_ops nfsv3:nfs:nfsv3_read_latency nfsv3:nfs:nfsv3_ops' It's good to note that while stats show averages, nfs_hist shows a histogram, and can spot the occasional very high latency operation. Good to watch. I just poked around, there is a cifs component for stats, and it shows some interesting metrics the cifs users might want to watch. filer01*> stats show cifsdomain cifs cifs:cifs:cifs_ops:2658/s cifs:cifs:cifs_op_count: GetAttr: 1296 Read: 989 Write: 0 Lock: 1 Open/Close: 23 Directory: 0 Other: 335 cifs:cifs:cifs_op_pct: GetAttr: 48% Read: 37% Write: 0% Lock: 0% Open/Close: 0% Directory: 0% Other: 12% cifs:cifs:cifs_latency:3.27ms cifsdomain:10.0.0.3:netlogon_latency:9.50ms cifsdomain:10.0.0.3:netlogon_latency_base:6 cifsdomain:10.0.0.3:lsa_latency:0ms cifsdomain:10.0.0.3:lsa_latency_base:0 cifsdomain:10.0.0.3:samr_latency:0ms cifsdomain:10.0.0.3:samr_latency_base:0 cifsdomain:10.0.0.2:netlogon_latency:2.00ms cifsdomain:10.0.0.2:netlogon_latency_base:1 cifsdomain:10.0.0.2:lsa_latency:0ms cifsdomain:10.0.0.2:lsa_latency_base:0 cifsdomain:10.0.0.2:samr_latency:0ms cifsdomain:10.0.0.2:samr_latency_base:0 cifsdomain:10.0.0.1:netlogon_latency:0ms cifsdomain:10.0.0.1:netlogon_latency_base:0 cifsdomain:10.0.0.1:lsa_latency:0ms cifsdomain:10.0.0.1:lsa_latency_base:0 cifsdomain:10.0.0.1:samr_latency:0ms cifsdomain:10.0.0.1:samr_latency_base:0 There's also smb_hist. That's from a 960 running 6.5.6PsomethingDsomething.... -Blake On 11/15/06, George, Andrew <georgea(a)anz.com> wrote: > We only use our filers for CIFS (so this may be completely inapplicable > to you) > > 1. Cache age! Mainly because when I have seen filers that are worked to > death, that's the value that tends to react to it (though CP there are a > lot of secondary metrics to support that). > > 2. As mentioned by someone else...the magic metric is how badly the > users are bitching. That being a little "rubbery" we also check cache > age, cp type, disk utilisation, cpu usage, Ops/sec and network traffic > to determine if anything's bottlenecking. > > -----Original Message----- > From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] > On Behalf Of Rohit > Sent: Wednesday, 15 November 2006 9:59 PM > To: toasters(a)mathworks.com > Subject: Measuring Filer Performance > > Hi Folks > > I had some open questions and i hope you'll help me answer them based on > your experience. > > 1. If you just had a single metric to determine filer performance what > would it be ? > Would it be CPU usage, throughput, latency, IOPS..or anything else ? > > 2. At your place, what metrics do you use to determine if a filer is > still good enough not to worry about ? > > thanks > rohit > > ------------------------------------------------------------------------ > -- > Refinance & Home Equity Loan Quotes > Low credit score? Old Merchants can help. Get a quote in 2 easy steps! > http://tagline.bidsystem.com/fc/BgLEQfI7zNZsu5fZHhXyj0UMjSNzY6ZfSaWC/ > > > > > "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication." >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters November 2006