toasters

toasters@lists.teaparty.net

2 participants
13529 discussions

Upgarding filer head with LUNs and MSCS
by Borzenkov, Andrey 05 Jan '09

05 Jan '09

Hi, We are going to upgrade several filers (FAS270 -> FAS3140). They host FCP LUNs and Windows with MSCS connected. Now what I have been told: - MSCS records disks (LUNs) serial numbers; when these serial numbers change, MSCS won't detect and configure its disks. Basically, cluster has to be recreated from scratch - LUN serial number on filer depends on sysid; when sysid changes, LUN serial number will change - as during head upgrade sysid will change so will serial numbers; so MSCS will be very unhappy. Is the above correct? Now we'd rather avoid recreating all MSCS configuration. Are there any pitfalls if we save original serial numbers and set them again on new head before MSCS will go online? Will this work or some more tuning is necessary? Thank you! С уважением / With best regards / Mit freundlichen Grüβen --- Andrey Borzenkov Senior system engineer

3 3

Success using Bacula to back up an iSCSI-only NetApp
by David Lee Lambert 23 Dec '08

23 Dec '08

We have a two-controller FAS2020 NetApp with 1.5TB of storage (1TB on one, 500GB on the other), licensed for iSCSI only, and an old desktop system connected to a 12-tape library of LTO-4 (800GB uncompressed) tapes. I have gotten Bacula to back up files stored on ext3fs (Linux) and NTFS (Windows) partions on iSCSI LUNs on the NetApp. The Bacula instance is running under Ubuntu Gutsy (a "long-term supported" release), using the Gutsy package, 2.0.3. We're using Postgres version 8.2.5 as the database, because that's the available Ubuntu package and we use Postgres elsewhere. We're using the "open-iscsi" initiator, from an Ubuntu package. LVM and device-mapper are not installed on the backup-host, and it only has a single Fast Ethernet connection. (The hosts that are being backed up generally have dual Gigabit Ethernet connections to the filers.) I wrote several scripts to allow Bacula to take snapshots on the filer and mount them in a known place before the backup-job runs, then clean them up afterward. I can't publish them because they have a lot of details specific to our network, but the general outline is as follows: "easy_snap" takes 3 arguments: an NTFS or ext3fs volume-label, an indication of which filer the volume is on, and the complete path to the LUN on the filer (such as "/vol/vol5/testdatav2.lun"). It makes up a name to use for the snapshot. It issues "snap create", "lun clone create" and "lun map" commands via RSH to the filer. (It also checks to see if another snapshot of the same volume is still mounted by mistake; if so, it unmounts and unmaps it.) If another snapshot with the same name exists, the script tries to delete it, and renames it if that doesn't work. It cleans up any old "bacula-" snapshots. Then it issues a local "iscsiadm -m session --rescan" command, and if it still can't see the new LUN, logs the iSCSI session out and in again. It mounts the partition using "LABEL=" syntax, to a mount-point under /mnt where the last part is the lower-case form of the volume-label. "easy_unsnap" takes the same 3 arguments as "easy_snap". It unmounts the partition, logs out the iSCSI session, unmaps the LUN, and tries to delete the snapshot. We noticed that the snapshots weren't always being deleted, which is one reason why "easy_snap" tries to clean up old snapshots several ways. If a backup spans an hour-boundary where hourly snapshots are being created, or midnight for the nightly snapshot, the mapped LUN becomes part of the snapshot and the snapshot we took can't be deleted until the hourly or nightly snapshot goes away. I tried backing up Linux hosts with a filesystem on a raw (no partions) LUN using this script, but it didn't work: when the LUN is discovered, the /dev/disk/by-label/LABEL symlink does not get created. We wouldn't be able to back up LVM volumes with this configuration either, because LVM depends on device-mapper, and device-mapper would try to grab the disks itself. Right now our performance is limited by the network interface for LUNs containing a few large files, and by Postgres INSERT performance for filesystems with lots of small files. We get 9MByte/sec for the big-file LUNs, so for example a 46-GB SQL Server database takes an hour and 18 minutes to run. We have a test-system with over 300,000 files (including over 100,000 zero-length ones) in just a few directories, but only 580 MB of total data; that took two and a half hours to back up last night. However, our entire backup (except test-systems) ran within 6 hours, and we already have more than half of our production data being backed up with Bacula. For the most part, Bacula does what we want it to do in this case, and it allows a lot more flexibility with restoring files than we were able to achieve trying to use the "dump" command on the NetApp filers. -- David L. Lambert Yahoo! IM: davidleelambert ** MSN IM: lamber45(a)cse.msu.edu

1 0

Limiting SnapDrive user capabilities
by Borzenkov, Andrey 23 Dec '08

23 Dec '08

Hi, We are looking for a possibility to limit SnapDrive account to the bare minimum. The goal is to allow some SD operations (effectively, connecting and disconnecting snapshots) to a (Windows) user, while not giving this user full administrative capabilities on a filer. I have a feeling that careful usage of roles on filer could accomplish this; anybody has done it before? I would appreciate any hints. Thank you and Merry Christmas! С уважением / With best regards / Mit freundlichen Grüβen --- Andrey Borzenkov Senior system engineer

2 1

SMVI Command Line questions
by hollandwl＠gmail.com 23 Dec '08

23 Dec '08

Just started evaluating SMVI 1.01 in our Dev environment to get a feel for how it works. A couple of things showed up immediately that I could use some clarification on: 1. Is there any way to get it to simply pass the logged on Windows credentials and not prompt for a password the first time? The current behavior totally defeats the ability to script the operations as we do not wish to store passwords in clear text. 2. Is there any way to have it create backups/snapshots in a user friendly format? Using the -backup-name switch puts the name you enter into the snapshot name, but you still end up with something like smvi-backupname-someobscenelylonguid-volname. This naming convention makes integration with snapvault difficult as I know what name I pass with -backup-name, but don't know what the hiddeously long name is going to be. It would be EXTREMELY helfpful if the snapshot name were the same as -backup-name passed on the command line.

1 0

RE: Quick question about "LUN protocol type"
by David L. Lambert 19 Dec '08

19 Dec '08

OK, I guess I phrased my question poorly. I want to make a LUN that will only be accessed by a Linux host. It will have a partition-table, and one partition in that partition-table. That partition will have a labeled ext3fs filesystem on it (Ubuntu's "mount LABEL=..." seems more reliable if I do it that way). Should I tell the NetApp that it's a "Windows" or a "Linux" LUN? Or will the NetApp behave exactly the same either way? -- David Lee Lambert -----Original Message----- From: Jeff Mohler [mailto:speedtoys.racing@gmail.com] Subject: Re: Quick question about "LUN protocol type" Why not map two Luns? ___ Sent from my $400 phone that has no text editing tools. Yay. On Dec 15, 2008, at 7:59 AM, David Lee Lambert <dlambert(a)bmtcarhaul.com> wrote: > In the FilerView LUN wizard, I see the following options for "LUN > protocol > type": > > [...] > > If we're making a LUN with a DOS partition table and one partiton that will be used by a Linux host, should we use the "Windows" or "Linux" setting? Or does it matter? > > -- > David L. Lambert > Yahoo! IM: davidleelambert ** MSN IM: lamber45(a)cse.msu.edu

2 1

Serial console cable shenanigans (FAS3020s to Cyclades)
by Nick Silkey 16 Dec '08

16 Dec '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 toasters -- I am trying to troubleshoot connectivity issues between my serial consoles and my 3020s. Per NetApp, we are 'required' to hang the X881[1] rj45-to-db9 dongle off the filers. But my Cyclades can easily grok rj-45. A phone call to NetApp revealed that a pin-out of: 4 -> 4 3 -> 6 6 -> 3 should allow me to not have to used the NetApp dongle (TSE appears to have walked the pin-outs backwards to come up with the above). Havent tested this yet; looking to confirm from those on the list since the pinout is non-standard. So is anyone out there tapping into their Cyclades without the NetApp db9 dongle hanging off their 3xx0 filer? Insight appreciated. Thanks. [1]: http://now.netapp.com/NOW/knowledge/solutions/kb13794_X881.jpg ; taken from https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb13794 - -- Nick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAklGkAgACgkQrDQjhjXrMeJX7gCfUol7uWHNjlE8m0R1gC863CqK dqYAniNUoFg4mrgC9LNjJ09vO3VKkBAh =UPnp -----END PGP SIGNATURE-----

1 1

Leopard globalSAN iSCSI and 7.1.3
by Carl Howell 15 Dec '08

15 Dec '08

On one of our Xserve¹s, I¹ve used the Studio Network Solution¹s iSCSI initiator(3.3.0.43) with OnTap version 7.0.5 and didn¹t have any problems. Now, after upgrading to OnTap version 7.1.3, I get the following error: Mon Dec 15 16:18:36 CST [iscsi.protocol.violation:warning]: ISCSI: iSCSI protocol violation, 'Initiator did not respond to offered MaxBurstLength' Does anyone have any ideas on how to fix this? Thanks, --Carl

1 0

Re: Quick question about "LUN protocol type"
by David Lee Lambert 15 Dec '08

15 Dec '08

No, when I say a "DOS partition table" I mean what I get by running the program "/sbin/fdisk" under Linux, and subsequently doing e.g. mke2fs -L APPDATA -j /dev/sde1 instead of just doing mke2fs -L APPDAT -j /dev/sde On Monday 15 December 2008 11:19:48 am Webster, Stetson wrote: > Question: Is DOS directly interfacing with the lun? Do you have SAN device > drivers for DOS? > -----Original Message----- > From: David Lee Lambert [mailto:dlambert@bmtcarhaul.com] > Subject: Quick question about "LUN protocol type" > > In the FilerView LUN wizard, I see the following options for "LUN protocol > type": > [...] > > If we're making a LUN with a DOS partition table and one partiton that will > be used by a Linux host, should we use the "Windows" or "Linux" setting? > Or does it matter? -- David L. Lambert Software Developer, Precision Motor Transport Group, LLC Work phone 517-349-3011 x223 Cell phone 586-873-8813

1 0

Quick question about "LUN protocol type"
by David Lee Lambert 15 Dec '08

15 Dec '08

In the FilerView LUN wizard, I see the following options for "LUN protocol type": Solaris Windows - "The LUN will be used to store a raw disk device in a single-partition Windows disk" HP-UX AIX Linux - "The LUN will be used to store a Linux raw disk with no partition table" NetWare VMware The "na_snap" manpage also lists the types "windows_gpt" and "vld". If we're making a LUN with a DOS partition table and one partiton that will be used by a Linux host, should we use the "Windows" or "Linux" setting? Or does it matter? -- David L. Lambert Yahoo! IM: davidleelambert ** MSN IM: lamber45(a)cse.msu.edu

1 0

RE: qtree "top" tool
by Glenn Walker 14 Dec '08

14 Dec '08

All good points. That said, when I said 'write tool' and 'cifs top' I was thinking more interactive on the CLI of the actual filer to spot check stuff. I could have all of the talent in the world and not be able to produce this without getting it checked into the ONTAP code ;) Perhaps I will un-lazy myself when I get free time and give a client script version of this a whirl. Glenn -----Original Message----- From: Jeff Mohler [mailto:speedtoys.racing@gmail.com] Sent: Friday, December 12, 2008 10:37 PM To: Glenn Walker Cc: Todd C. Merrill; Nicholas Bernstein; Toasters Subject: Re: qtree "top" tool Netapp -could- write a lot of things. But there'd always be the "It'd be nice if..." But..then they'd be paying script writers instead of engineers by the lot, and the CLI and ZAPI are pretty open and available. But if I had any talent at all to script anything, Id be doing something like this too, perhaps. On Fri, Dec 12, 2008 at 7:25 PM, Glenn Walker <ggwalker(a)mindspring.com> wrote: > This is a good point. > > Using the perfstat tool will give you some running incrementals (it > zeroes for each iteration), but I think you want more of a tool like > cifs top, no? I don't see why NetApp couldn't easily write something > like this, and it would be a good tool to have: sysstat only goes so > far. > > Glenn > > -----Original Message----- > From: Todd C. Merrill [mailto:tmerrill@mathworks.com] > Sent: Friday, December 12, 2008 2:25 PM > To: Glenn Walker > Cc: Nicholas Bernstein; Toasters > Subject: RE: qtree "top" tool > > > Yes, I know about `qtree stats`. But, just like nfsstat, > it gives you cumulative stats. > > The NFS top tool I mentioned does an incremental nfsstat. > I'm looking for the same--*incremental* qtree stats, > in order to debug high usage as it is happening. > > > On Wed, 10 Dec 2008, Glenn Walker wrote: > >> You mean qtree stats? >> >> It shows CIFS and NFS ops per qtree - doesn't work at the vol level >> (wish it would). >> >> Glenn >> >> -----Original Message----- >> From: owner-toasters(a)mathworks.com > [mailto:owner-toasters@mathworks.com] >> On Behalf Of Nicholas Bernstein >> Sent: Wednesday, December 10, 2008 1:00 PM >> To: Toasters >> Subject: Re: qtree "top" tool >> >> I don't have a filer in front of me to test, but isn't there a stats >> show >> qtree? >> >> >> On 12/9/08 6:16 PM, "Todd C. Merrill" <tmerrill(a)mathworks.com> wrote: >> >> > Folks, >> > Before I write one myself or modify the NFS top tool >> > on the NOW toolchest: >> > >> > http://now.netapp.com/NOW/download/tools/ntaptop/ >> > >> > does anybody have an equivalent one for `qtree stats`? >> > >> > >> > Until next time... >> > >> > The MathWorks, Inc. 508-647-7000 x7792 >> > 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX >> > tmerrill(a)mathworks.com http://www.mathworks.com >> > --- >> > >> >> -- >> Nicholas Bernstein >> Technologist, Consultant, Instructor >> http://nicholasbernstein.com >> >> >> >> > > > Until next time... > > The MathWorks, Inc. 508-647-7000 x7792 > 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX > tmerrill(a)mathworks.com http://www.mathworks.com > --- > > >

1 0

Jump to page:

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