toasters February 2005

toasters@lists.teaparty.net

68 participants
73 discussions

RE: IPsec NFS to Unix clients
by Muhlestein, Mark 17 Jun '05

17 Jun '05

Gee, 30,000 * 300 is not even 10 million entries! :-) Yes, you are right that this isn't going to work in every case. But I wanted to mention it because it is useful in some situations. As to the MultiStore comment I made, I was thinking of a case where you want to use the same physical filer to serve an unprotected network (such as your normal campus network, it sounds like) and also serve a trusted network (on a different NIC or VLAN, say). As long as there is no way to access a vfiler's IP address using a client on the untrusted network, the vfiler boundary checks will prevent all access from all protocols (including NFS handle spoofing) coming from those untrusted clients. Mark -----Original Message----- From: Brian Parent [mailto:bparent@calvin.ucsd.edu] Sent: Friday, August 20, 2004 2:41 PM To: toasters(a)mathworks.com Subject: Re: IPsec NFS to Unix clients Thanks Mark. We do have CIFS. However, we have >30,000 accounts, and >300 NFS clients. And besides, any account is allowed access from any NFS client. Plus, it doesn't solve the problem of spoofing IPs. We don't have MultiStore, but even if we did, I don't see how it solves the problem of spoofing IPs. Spoofing IPs is painfully simple here, (as at most Universities, I would think) where labs aren't supervised, and network jacks are not physically secured. Re: > Subject: RE: IPsec NFS to Unix clients > Date: Fri, 20 Aug 2004 13:31:42 -0700 > From: "Muhlestein, Mark" <mark.muhlestein(a)netapp.com> > To: "Steve Losen" <scl(a)sasha.acc.virginia.edu>, > "Brian Parent" <bparent(a)calvin.ucsd.edu> > Cc: <toasters(a)mathworks.com> > > Here are a couple of other things you can do to improve NFS security: > > 1. If you have CIFS you might consider using the > nfs.require_valid_mapped_uid option. That allows you to set up the > usermap.cfg file to do things like this: > > # allow the following UIDs NFS access from the specified IP addresses > tom <= 192.168.3.34:tom > jerry <= jerrypc.dorm.foo.edu:jerry > jerry <= lab1.foo.edu:jerry > jerry <= lab2.foo.edu:jerry # etc. > > # allow root from the admin network > Administrator <= 10.10.20.0/24:root > > # prevent all other NFS access > "" <= * > > The nfs.require_valid_mapped_uid option causes the usermap.cfg entries > to be consulted even for access to data on qtrees with UNIX security. > Combined with the normal export controls, this approach works as long as > clients are not allowed to successfully spoof source IP addresses. It is > also more manageable if the number of combinations of users/hosts is not > overly large or dynamic; however I know we have had sites that have used > this type of approach with a script-generated usermap.cfg. > > 2. If you have MultiStore available you can also use that to fence off > NFS access. NFS clients accessing an IP address associated with a vfiler > are not allowed to access storage assigned to another vfiler. This is > enforced at the WAFL layer, so even if clients attempt handle spoofing > the access is denied as long as the potentially rogue clients are not > allowed to access the other vfilers' IP addresses (e.g. different > networks on separate NICs). > > Mark

2 2

df size reporting differences in ONTAP 7.0
by Adam McDougall 19 Mar '05

19 Mar '05

This sunday I upgraded our production FAS940 from 6.5.3 to 7.0 and noticed NFS clients are reporting the user or group quota as the volume size and free space when running df, when 6.5.3 and earlier used to report the qtree quota. I was suprised by this change and so far have been told by NetApp that it is a bug fix, not a bug. Just wanted to send a heads up to the list to let people know, and wondering if anyone else was affected negatively by this. I like part of the idea of the change but was not expecting it at all. Didn't see it in docs. Its interesting but inappropriate for some of our volumes the way we have quotas setup, and it prevents non-admins from seeing if the volume or qtree is nearing full.

3 5

Anyone using Netapp filers for SAN or email ?
by Steve Losen 04 Mar '05

04 Mar '05

We have used Netapp filers for 8 years and are very pleased. We currently have a F820c pair for NFS and CIFS access to home directories and web content. I am one of the primary filer admins. We are about to purchase some disk storage to replace a lot of locally attached and SAN RAID arrays (Sun T3s and T4s) for some Solaris servers. Naturally I think we should buy Netapp. One project is our administrative Oracle servers. I realize that Netapp and Oracle both recommend using NFS with Netapp, but we currently have a SAN infrastructure and lots of other inertia to overcome. If we buy Netapp for this, the filers will at least start out serving LUNs on our SAN. I am convinced that Netapp is they way to go for NFS, but I have not seen much about Netapp in a SAN environment. We were looking at EMC Symmetrix, but probably cannot afford it, so it will probably be a choice between EMC Clariion and Netapp. Our "production instance" (I'm not familiar with the particulars) is 500G and growing. We also have a data warehouse instance and other misc. databases. The warehouse is copied fresh from production each night and then a 6 hour job crunches on it before it is made available for querying. Obviously a cloned volume would be nice here. Is anyone running Oracle on Solaris over a SAN to a Netapp? How is the performance? How many filers and what models? How much storage? How many disks? We are familiar with all the nifty snapshot features, volume cloning, etc. We just don't want to find out the hard way that the Netapp SAN solution is a poor performer with Oracle. We also have a University email system on Solaris servers running Communigate Pro. We have over 20,000 users and about 1TB of email on disk. We are using mbox format and most email clients use imap. Our email admins looked into maildir format but found that in our environment it took ten times longer for imap to scan inboxes. This is not a surprise since inboxes usually have a lot of short messages, so it is often faster to just read the whole inbox than open a file for each message and read just the headers. And imap regularly needs to scan all the message headers in an inbox. There are many advantages to the maildir format, but we are afraid that it would crush our current system. However, we are thinking that a Netapp filer would do a better job with maildir than a local Veritas filesystem on Solaris. Is anyone out there running a large email system over NFS to a Netapp filer using maildir format? If you are using Communigate Pro, and/or do a lot of imap, that would be even better. How many email accounts and how much mail do you process? How many filers and what models? How much storage? Do you have any performance issues? Currently our email servers do a lot more reads than writes (we read over 5 bytes for each byte we write). We don't know what the actual disk activity is inside the T3s and T4s, we only know how much we read and write from each LUN. We don't know the actual RAID 5 write overhead, and we don't know how many reads are satisfied from cache internal to the T3s and T4s. Our email admins say that the T3s occasionally get swamped, but that the T4s seem to be doing fine, so they could probably replace the T3s with T4s and be OK for a couple years. But they want to expand storage and triple user quotas and perhaps switch to maildir, and they are afraid that T4s can't handle all that. Plus snapshots would make restoring lost email messages so much easier. Thanks for any information you can give me. I'm going to look at Netapp's white papers, too. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

2 1

RE: Destroying failed disks
by Jeff Mohler 03 Mar '05

03 Mar '05

It's a calculated trade-off. We assume that NetApp does the right thing and crunches the disks once they have done a failure analysis back in their labs. --- If you assume that, and you really care, I would not assume any vendor of drives or storage material does this. I have NO idea what Netapp does, but I would not ASSUME that they physically destroy disks with your data on them. Right now, I assume youre thinking about upping your service contract to be able to keep your own dead disks so that you can destoy them yourself and remove the assumption of the mitigation of risk. But only you can know for sure.

4 3

RE: Quick access to quota information
by barrie_spence＠agilent.com 28 Feb '05

28 Feb '05

I've just been busy writing a script to manage and enforce quotas the "UNIX way" (i.e. lock down the quota at the soft limit if the user doesn't cleanup within 14 days of exceeding it). The CPAN Perl "Quota" module works a treat: use Quota; $host='filer'; $volume_path = '/vol/vol1/users'; $uid = 501; ($block_curr, $block_soft, $block_hard, $block_timelimit, $inode_soft, $inode_hard, $inode_timelimit) = Quota::rpcquery($host, $volume_path, $uid); It's pretty fast and appears to work on HP-UX, Solaris and Linux. The only thing you have to watch for is that the results are low while the quotas are resizing (easy to check with a SNMP query). Regards, Barrie -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Jacek Nogala Sent: 21 February 2005 09:36 To: toasters(a)mathworks.com Subject: Quick access to quota information The landscape: - The company is cable tv providing also Internet services - They intend to use FAS920 in NFS environment (all servers are Linux) - At this very moment they are servicing about 80k users but wanting to be able to service more that 200k - Services for users are to be implemented with UID and GID quotas Requirements: - They need to be able to retrieve quickly information about current quota usage for each specific UID or GID. - The information will be available via: -- Call Center - estimated queries 12 times per minute -- WEB GUI for users - estimated queries 120 times per minute - The quota information should be retrieved within 2 s and should be not older than 30 s - There is not specific requirements regarding method of getting the result (SNMP/RSH/NFS RPC/HTTP are acceptable) We discussed with them SNMPwalk and quota report parsing but they cannot accept it due to high and growing number of users. The most convenient way would be short series of SNMP queries for specific UID / GID. Any suggestions other than "make and parse quota report" are welcome. Best regards, Jacek

2 1

full volume performance
by Charles Bartels 28 Feb '05

28 Feb '05

Hi Folks, It is pretty well know that disk performance start to suffer when the partition begins to fill up. So I am wondering if you would see the same effect with a full volume (traditional or flexible) in a relatively empty aggregate, or a full qtree in a relatively empty volume? Any thoughts on the matter would be appreciated. -C.

2 1

RE: F720 head upgrade?
by Jeff Mohler 28 Feb '05

28 Feb '05

You have some NFS tuning to do in TCP, UDP is fine. This isnt your root problem, but it cant help. Check the output regarding TCP receive buffer sizes. Client vancouver has network problems, NFS retransmits. Check output. Doesnt harm the system, but that client is impacted. Youre fighting performance -vs- storage space. You have a number of 18 and 36G drives. Vol0 is laid out properly given this mix, you dont mix sizes within a given raid group. However disks 16, 18, and 19 are on their own as the raid group of 36G drives for this volume. They are also being beat on pretty hard. I see that your cache hits are 100%, this would cause you to wonder if you need a larger filer, more cache RAM..but that might not be it. You have 100% disk utilization as a fact of life on the system, but you are only doing disk reads for the most part, and NOT heavy ones. Nine to 12Mb/sec max. Thats danged odd. Heres your problem. Vol0. The 18G drives are about 65% busy, 95% reads. The 36G drives are 83% bush, again mostly reads. Vol1 is quiet as a church on bowling night. Solutions: Move data being accessed from vol0 to vol1, make use of the untilized performance you have there if this 60 seconds of history is a normal data activity. Likewise, move some of that date from vol1 to vol0, because you never want over 80% full volumes. ;) Rebuild your volumes. Make vol0 all of the 18G drives, 11data-1parity. Raw about 204Mb. Make vol1 all of the 36G drives, 6data-1parity. Raw about 207Mb. If you did this, your volume sizes would be larger than they are today, because youre not wasting space on mixed sized raid groups of 18 and 36G drives (vol1 is like this), and you end up with a LARGER number of spindles to parellelize your data access across in vol0 with a single volume of more 18G drives. Guaranteed, 100% of your performance problem is that itty bitty second raid group in volume 1. Unfortunately you will have to destroy the village to save it, but once you take the downtime to do so, you might find years of worthwhile performance out of your 720. Of course, you get to play God at work, and save a ton of cash while making thing better with no money spent. Yes, a larger system might reduce the missed cache hits, but 12Mb/sec is WAY less than a properly configured F720 can dish out. Id say you could triple that output easy if you did this. Is a 12drive raid group ok?? Id say YES. ONTAP is wayyyy more resilient than it used to be. You have plenty of drives left if you like, to enable raid_dp as well, which will give a 10data-2parity the basic reliability of two separate 5-1 raid groups, cept you have a larger stripe to make your reads against which seems to be your largest type of data activity according to this perfstat. What size Tshirt do I wear? XXL. :)

2 1

Stocks discovered for quick profit
by Angelica Carlton 28 Feb '05

28 Feb '05

US Oi| and Gas Report Oil Climbs, Gains Soar We have the leading track record for finding fast moving, Low-priced energy p|ays. Look at the moves made by our |ast 2 Hot Picks: SPRL .14 to .36 in 12 days, up 157% PRVB .10 to .265 in 8 days, up 165% Like a viper coiled to strike, this Hot Oi| P|ay is on the fast-track to Mi||ions in gains from expanding production in the Heart of the "Oi| Be|t". Emerson Oil and Gas, Inc. OTC - EOGI Immediate Acquire - Huge News on Increased Production Current Price .15 Target Price .4O in 1O days Oil prices continue to explode and ignite the shares of major producers which is fo|lowed by soaring undervalued OTC Oil P|ays. Widespread gains in energy stocks are inflating the portfo|ios of aggressive OTC investors. Due to recent|y acquired high-potential oil and gas projects, EOGI is an underva|ued gem experiencing a sharp in crease in production revenue and becoming a "cash-flow positive" |eader in major oil-producing states. EOGI's high-yie|ding, mu|tip|e dri|ling programs have been solidified through valuab|e strategic al|iances. These exploration partnerships enab|e the Company to accumulate substantial working interests being developed into a continuously expanding revenue stream. EOGI is focused on joint-ventures involving we|l re-entry programs in extremely pro|ific production areas using the highest |eve| of techno|ogy currently available. Recent deve|opments for EOGI have been perfectly timed as a|| 6 Dow Jones Oi| and Gas Indexes just hit their highest |evels of the year, with Energy Stocks outperforming a|l other market sectors. The Company's Oi| and Gas interests in Louisiana and Texas, in addition to their deve|oping natural gas wel|s in Alberta, Canada, are continuing to in crease in va|ue with energy prices up 60% from one year ago. Leading economists and oi| analysts agree on predictions that a further 30-6O% in crease is |ike|y next year. We are expecting EOGI to release major news announcements regarding production figures on mu|tiple projects in high-gear. EOGI's expansion p|ans are on track to acquire additional prospects and properties that can on|y add to their growing bottom-line and spark further interest in this undervalued oi| play. With a very sma|| f|oat estimated at |ess than 5 million shares, EOGI should gap sharp|y to the upside on heavy vo|ume as the value of their current oi| deals are revealed. US Oi| and Gas Report cautions that sma|| and micro-cap stocks are high-risk investments and that some or all of the investment can be |ost. We suggest you consult a professional investment advisor before making any investment decisions. US Oil and Gas Report recommends you use the information found here as an initia| starting point for conducting research and due di|igence on the featured company in order to determine an opinion of the company before investing. We are not an Investment Advisor, Financial P|anning Service or a Stock Brokerage Firm and in accordance with such is not offering investment advice or promoting any investment strategies. This is not an offering of securities for sa|e or so|icitation of any attempt to acquire or sell securities. US Oi| and Gas Report has been given nineteen thousand do|lars from a third party for the dissemination of this company profile. Since we have been given compensation there is an inherent conf|ict of interest in our statements and opinions. Readers of this pub|ication are cautioned not to place undue reliance on future-looking statements, which are based on certain assumptions and expectations involving various risks and uncertainties that could cause resu|ts to differ materially from those set forth in those statements. If you wish to stop future mailings, or if you fee| you have been wrongfu|ly p|aced in our membership, please go here or send a b|ank e mail with No Thanks in the subject to (-stox0033@ yahoo.com-)

1 0

RE: F720 head upgrade?
by Davin Milun 27 Feb '05

27 Feb '05

perfstat is a utility that you run from an admin host. http://now.netapp.com/NOW/download/tools/perfstat/ At 7:45, on Feb 27, 2005, "Michael Fahy" wrote: > > When I type "perfstat" I get "perfstat not found". I did "priv set > advanced" and found a "perf" command (but no perfstat). The only option is > "perf report -t" which produced: ...

2 1

RE: F720 head upgrade?
by Jeff Mohler 27 Feb '05

27 Feb '05

Run a perfstat..or at least tell us what its been up to. Has the file system been full or over 80% for any period of time? A perfstat will shed a TON of light. Id be glad to peek at it if you sent the output my way. :) -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com]On Behalf Of Fahy, Michael Sent: Saturday, February 26, 2005 8:44 PM To: toasters(a)mathworks.com Subject: F720 head upgrade? My good old F720 seems to have run out of gas. It is now running at 100% CPU utilization all the time and application performance has gotten really bad. I'm hoping to be able to upgrade the head and still use the three drive shelves. But I'm wondering why I'm seeing this poor performance all of a sudden and if it really is normal behavior. The F720 has a gigabit network interface but network usage never goes over 10%. When network usage gets to 5%, which would mean 50 Mbps, the CPU hits 100% and stays there. Is that really the maximum capacity of an F720? The three drive shelves are: Shelf 0: EDM Kernel Version : 0.4 App. Version : 0.0 Shelf 1: VEM Kernel Version : 2.5 App. Version : 3.1 Shelf 2: VEM Kernel Version : 2.5 App. Version : 3.1 What options do I have for replacing the head with a faster one that would work with these shelves?

2 1

2025

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 February 2005