That is helpful, thank you. NTP mentioned those bugs during our install, apparently they were all fixed in 8.x and up but I'll be checking them anyway, just to be safe.
They also mentioned the disconnect issue though not in relation to a panic but rather to heavy load where the mgmt server can't keep up.
My mgmt server is on a different vlan, in an entirely different building in fact, and they made no mention of the need to be on the same net. Maybe for the poc they don't care. I'll check on that though.
Thanks again. It's comforting to know that someone has done something similar and not seen any appreciable overhead.
Jeff Kennedy
Qualcomm, Incorporated
QCT Engineering Compute
858-651-6592
-----Original Message-----
From: Klise, Steve [mailto:klises@sutterhealth.org]
Sent: Wednesday, April 04, 2012 8:03 PM
To: Kennedy, Jeffrey; NDMP List (toasters@teaparty.net)
Subject: RE: fpolicy overhead
With just the reporting pieces, should be not much impact if any. Are you refering to storage m & a, or reporting on quota management?
We ran into a rather "nasty" bug that panic'ed both filers around a year ago (yeah, it was bad); and I have never had that happen before. These were the bugs:
390540,390540 and my case was 2002040059.
Make sure the DOT you are running has these.. Not fun. I have been running without incident for ~ 6 months now.
I am running NTP on one of my filers with ~ 6000 users connected to a FAS6080. I am not blocking files (manager is still trying to get the ok to block users). One thing to watch for in your messages file is RPC disconnect/reconnect via your fpolicy NTP server. This is the precursor to a "panic". I have the ntp scanner on the same vlan as the filer. NTP insisted on this.
I have not seen any impact once I have had the patches applied. I had to make some CIF options modifications after the DOT upgrades. I can share those if you want them. Users were unable to access some of the cifs.. Never thought there were some many parameters you could change for cifs..
Hope this helps.
Regards
Steve Klise
Storage Engineer, NCDA
__________________________
PALO ALTO MEDICAL FOUNDATION
SUTTER HEALTH INFORMATION SERVICES
PENINSULA COASTAL REGION
Office: 408-523-3163 * Fax: 408-328-1406
e-mail: klises@sutterhealth.org<mailto:abouelj@sutterhealth.org>
WARNING: "All e-mail sent to or from this address will be received or otherwise recorded by the Palo Alto Medical Foundation e-mail system and is subject to archival, monitoring or review by, and/or disclosure to, someone other than the recipient."
________________________________
From: toasters-bounces@teaparty.net [toasters-bounces@teaparty.net] On Behalf Of Kennedy, Jeffrey [jkennedy@qualcomm.com]
Sent: Wednesday, April 04, 2012 6:48 PM
To: NDMP List (toasters@teaparty.net)
Subject: fpolicy overhead
Does anyone know what the overhead of fpolicy translates into? Specifically I'm looking at NTP QFS for external quota management (no file blocking).
Right now I can't test under load, just functional (minimal lab environment) but I'd like some idea of overhead before going too far down the path. For instance, if having fpolicy enabled for such a function will add 20%, I may as well stop now. But if it's 2% then everything's rosy.
As an aside, I'm also looking at the security audit and reporting product from Likewise, now EMC-Isilon. It also uses fpolicy and cifs auditing. I do not yet have this in the lab but any input on this would also be appreciated.
Thanks.
Jeff Kennedy
Qualcomm, Incorporated
QCT Engineering Compute
858-651-6592
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters