toasters February 2007

toasters@lists.teaparty.net

50 participants
33 discussions

Netapp and VMware... It's all so confusing!
by Timothy Hollingworth 01 Apr '10

01 Apr '10

So, say for example, I want to virtualize an Exchange server. Lets also say that I want to manage it via Snapdrive and SME. Lets also say, just for the heck of it, that I want both the new front-engined Acura NSX as well as the Porsche RC3. The cars aside, I would have to run iSCSI from within the VM, install and use Snapdrive from within the VM to provision LUNs, install Exchange and then use SME? It seems kind of silly to use iSCSI from within a VM if the ESX box were fiber attached to the Filer, just to be able to use Snapdrive and SME, no? I would love to be able to use the features of SD and SME within a completely virtual environment and am wondering what some real world implementations other VMware/Netapp customers are running. Do you run storage for the databases and logs in VMDK's and manage snapshots and backups from a VMware virtual machine perspective or do you manage them as iSCSI LUNs and use SD and SME? Or am I completely blind and missing something? Timothy L. Hollingworth Sr. Network Engineer, ePlus Technology Inc. 678.462.6698 (cell) AIM: HollingworthTim YIM: t_holling

11 15

autosupport stops functioning
by Leeds, Daniel 27 Feb '08

27 Feb '08

anyone else have this happen? suddenly one of our filers stops generating autosupport messages. both autosupport.enable and autosupport.support.enable are on. if i generate a test email with the autosupport.doit option nothing happens. not even a failed message, the console just sits there as if i never generated one. needless to say neither netapp or our email server gets anything from this filer and nothing hits the console about generating any autosupport emails.

8 12

how to obtain patch releases
by J. Greg Mackinnon 27 Mar '07

27 Mar '07

We currently are running OnTap 7.2.0 and not having fun with it. 7.2.1 contains many important fixes, but 7.2.1P1 has some critical fixes as well. I am getting fed up waiting for the next GA release, and I am willing to take the risk of running a patch build. The only problem... I cannot figure out how to download it! In the past I have found patch release download links in the NOW KB when referencing a related bug number... not so this time. Anyone know how to get the binaries? Open a support case? Bribe a NetApp tech? Thanks, -Greg Mackinnon University of Vermont

4 3

dfm backup
by Leeds, Daniel 01 Mar '07

01 Mar '07

any dfm users out there? got another odd problem this time with dfm backup. if we issue a dfm backup command it runs through the steps but generates no backup file. it does spit out an error about not finding the db which i do not get... dfm backup create DANIEL Adaptive Server Anywhere Backup Utility Version 9.0.2.2452 Database server not found Waiting for existing writes to stop, which could take a few minutes. Please be patient ... Creating the archive ... Deleting any temporary directories. Restoring performance advisor status. Deleting any database backup job from database. no file called DANIEL exists anywhere that i can find...NOW did not result in a match on dfm backup issues. -- Daniel Leeds Senior Systems Administrator Edmunds.com

1 1

usermap problem
by Langborg Tom 01 Mar '07

01 Mar '07

Watch out. I got usermap problem after uppgrade to 7.2.1.1. I use ldap.usermap for usermapping. The unix name are not the same as windows name. With unix name same as windows name it still works. If there are someone who now any fix for this problem, Please send me a letter. Regards tom

2 2

FW: autosupport stops functioning
by Bender, Marilee 28 Feb '07

28 Feb '07

We had this issue too. I agree with the post below that it could be message size. However, if it's just past asups that were too large because of the messages file (or one of the other attachments), you can set the autosupport.content size to minimal to delete all the queued asups, then "doit" to generate one without the attachments to see if you receive it, then put the content back to complete. It cleared the issue on one of our NearStores....the other one appears to have a "corrupt" character in the data chunk as viewed from the smtp server logs. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Sphar, Mike Sent: Tuesday, February 27, 2007 2:19 PM To: toasters(a)mathworks.com Subject: RE: autosupport stops functioning I don't think this is the same problem as the one originally posted, but we once had a similar problem here where autosupport messages stopped being received by netapp because our mail gateway was rejecting all messages larger than a certain size. We didn't even know they were bouncing (we weren't getting the bounces) until one of the mail admins finally said something about it. -- Michael W. Sphar - IS&T - Lead Systems Administrator SMBU Engineering Support Services, BMC Software -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Stephen C. Losen Sent: Tuesday, February 27, 2007 6:55 AM To: Leeds, Daniel Cc: toasters(a)mathworks.com Subject: Re: autosupport stops functioning > > anyone else have this happen? > > suddenly one of our filers stops generating autosupport messages. both autosupport.enable and autosupport.support.enable are on. if i generate a test email with the autosupport.doit option nothing happens. not even a failed message, the console just sits there as if i never generated one. > > needless to say neither netapp or our email server gets anything from this filer and nothing hits the console about generating any autosupport emails. > > One of our filers stopped sending weekly autosupports because the /etc/messages file was huge (170MB). It gets sent to netapp as part of the autosupport. I got an automatic email from Netapp support telling me that they hadn't received an autosupport for two weeks. Buried in my huge /etc/messages file was an error indicating that autosupport had failed, but no reason why. This particular filer holds our home directories and gets a lot of CIFS logins, which we want to log. We have enabled CIFS login tracing, which is very verbose. I used /etc/syslog.conf to divert the CIFS auth messages to another file: *.warning;auth.none /dev/console *.info;auth.none /etc/messages auth.info /etc/cifs_auth_log I rotate the cifs_auth_log with a cron job because I think ONTAP will only rotate /etc/messages. Now /etc/messages only grows to about 200K and autosupport is working again. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

2 1

RE: data management through compression for Netapp
by Glenn Walker 28 Feb '07

28 Feb '07

NetApp is definitely spoiling me with their feature set! The dedupe thoughts were specific to NetApp - ie, if NetApp were to perform dedupe on the source, what would life be like. I wasn't aware that Data Domain wouldn't use NetApp back-end storage... deduping without having some impressive fault tolerance is NOT a good idea! Glenn ________________________________ From: Glenn Dekhayser [mailto:gdekhayser@voyantinc.com] Sent: Tuesday, February 27, 2007 9:26 AM To: Glenn Walker; Darren Soothill; toasters(a)mathworks.com Subject: RE: data management through compression for Netapp Ah, Glenn, you're so spoiled with Netapp! :-) Problem is, with things like Data Domain, unless you're going to use the Netapp as back-end FC storage (which isn't supported yet), we're not in WAFL-land, so in most cases you are writing to the same place. And without Raid-DP, a single bit error on a raid rebuild could have a much bigger impact than normal, if that particular bit belongs to a byte that's referenced mulitple times in the de-duping scheme. Basically, I'm making the argument that if you're going to use de-duping- Raid-DP and WAFL is a MUST! Regarding the caching- de-duping would eliminate the efficiencies of WAFL read-ahead, since the blocks wouldn't be temporally located. While the read ahead would pick up the stub, the de-duping software (not being netapp-aware) would need to go back and retrieve the actual data referenced by the stub, and there goes your cache hit %. But, sometimes performance is not important. Glenn (the other one) ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Walker Sent: Tuesday, February 27, 2007 8:41 AM To: Darren Soothill; toasters(a)mathworks.com Subject: RE: data management through compression for Netapp I think that all of the solutions have their place - I'm not as interested in 'compression' as I am with 'deDupe' - they are separate, and not entirely equal. The only issue I can foresee with deDupe, besides adding overhead, is chance of failure: if the data is stored in a single block, and it is lost, so are you - but that's why you have parity, so it shouldn't be any more dangerous than normal data storage (provided the software works adequately). As for overhead, having multiple individuals 'hit' the same block would cause performance issues - but I'm not so convinced: There's really no such thing as 'overwrite' in ONTAP, it's always writing to a free block - as for reading the single block that has been deDuped, even though multiple machines hitting the same block should ordinarily cause higher latencies for everyone, I would think that the simple fact that there is one block with many accesses would indicate that it would already be cached - caching it in memory should remove the read latency penalty. Stubs carry their own penalties, btw: when the stub is seen, the filer must use the fpolicy service to communicate with the hosting system to redirect and\or obtain the actual data: this is multiple layers of network communication, memory lookup, and disk access before the client gets the requested data - this (in theory) should be slower than a self contained system in almost every case. VTL is definitely a good solution for backups and we're looking into them now. But HSM products, and archiving products of all types, still have one common flaw: they move the data around and it must then be managed. While this would be the most likely best way of dealing with the massive amounts of data in anyone's environment, it would still be nice to keep it all in one place. That's just a dream, anyways... I'm not sure that there would be enough savings through deDupe to actually accomplish anything like this. Now on the other hand, if the filer were able to move data to cheaper ATA storage within the same system, and simply use a redirector in the filesystem (pointer through vvbn), that could prove useful: you'd have the same lookup of vvbn-to-pvbn in order to find the data, but the actual blocks would be elsewhere within the system. No additional layers of stubs, or redirection through some other HSM system. Sorry for the long email this early in the morning, Glenn ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Darren Soothill Sent: Tuesday, February 27, 2007 12:36 AM To: toasters(a)mathworks.com Subject: RE: data management through compression for Netapp The issue with any compression technology is the latency it adds to any workload and what happens with a large number of people doing the same thing. Would you not be better at looking at an archiving product that can archive off the older files leaving stub files behind so any application can carry on working with no interruption. Assuming that the data is stored as lots of files. Perhaps you need to look at some traditional HSM type product that integrates with a tape library except instead of using a physical tape library you use a VTL which will do the deduplication and compression for you. You then have the added advantage that the VTL can spit out copies of the virtual tapes to be taken off site for DR. This type of solution should then be platform independent. ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Walker Sent: 27 February 2007 03:18 To: Glenn Dekhayser; Wilbur Castro; toasters(a)mathworks.com Subject: RE: data management through compression for Netapp I've also heard good things about Data Domain. On the other hand, does anyone have any experience with the A-SIS deDupe technology from NetApp? Sounds great, except for the 'out of band' nature of it. Glenn ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser Sent: Monday, February 26, 2007 8:36 PM To: Wilbur Castro; toasters(a)mathworks.com Subject: RE: data management through compression for Netapp Wilbur: What are your performance requirements? Adding compression/deDup into this has a serious impact on I/O performance, it will pretty much totally screw any read-ahead optimization. If you still want to go ahead, look at Data domain's Gateway series. It doesn't formally support Netapp, but i'm sure you could use it. This will do exactly what you want, as long as you want NFS! Glenn (the other one) ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Wilbur Castro Sent: Monday, February 26, 2007 4:55 PM To: toasters(a)mathworks.com Subject: data management through compression for Netapp Hi toasters, We have a couple of 100 TBs of heterogenous storage (some from netapp), and see that our storage grows close to 60% over year. We were looking at alternatives for managing this data growth. Compression was one of the techniques we were considering for our nearline and (possibly) primary storage. Our applications cannot change to do their own compression, so it boils down to doing this in the storage layer or through an external device. Also, we'd like to not have any performance impact and compression to happen transparently. Deduplication technology from storage vendors would help, but it is not a hetrogenous solution. I am not aware of any compression technology from netapp. Are you folks aware of any solutions? Would love to hear your experience with those or other alternative ways you deal with the storage growth problem while managing costs. Thx, Wilbur

1 0

RE: data management through compression for Netapp
by Glenn Walker 27 Feb '07

27 Feb '07

I think that all of the solutions have their place - I'm not as interested in 'compression' as I am with 'deDupe' - they are separate, and not entirely equal. The only issue I can foresee with deDupe, besides adding overhead, is chance of failure: if the data is stored in a single block, and it is lost, so are you - but that's why you have parity, so it shouldn't be any more dangerous than normal data storage (provided the software works adequately). As for overhead, having multiple individuals 'hit' the same block would cause performance issues - but I'm not so convinced: There's really no such thing as 'overwrite' in ONTAP, it's always writing to a free block - as for reading the single block that has been deDuped, even though multiple machines hitting the same block should ordinarily cause higher latencies for everyone, I would think that the simple fact that there is one block with many accesses would indicate that it would already be cached - caching it in memory should remove the read latency penalty. Stubs carry their own penalties, btw: when the stub is seen, the filer must use the fpolicy service to communicate with the hosting system to redirect and\or obtain the actual data: this is multiple layers of network communication, memory lookup, and disk access before the client gets the requested data - this (in theory) should be slower than a self contained system in almost every case. VTL is definitely a good solution for backups and we're looking into them now. But HSM products, and archiving products of all types, still have one common flaw: they move the data around and it must then be managed. While this would be the most likely best way of dealing with the massive amounts of data in anyone's environment, it would still be nice to keep it all in one place. That's just a dream, anyways... I'm not sure that there would be enough savings through deDupe to actually accomplish anything like this. Now on the other hand, if the filer were able to move data to cheaper ATA storage within the same system, and simply use a redirector in the filesystem (pointer through vvbn), that could prove useful: you'd have the same lookup of vvbn-to-pvbn in order to find the data, but the actual blocks would be elsewhere within the system. No additional layers of stubs, or redirection through some other HSM system. Sorry for the long email this early in the morning, Glenn ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Darren Soothill Sent: Tuesday, February 27, 2007 12:36 AM To: toasters(a)mathworks.com Subject: RE: data management through compression for Netapp The issue with any compression technology is the latency it adds to any workload and what happens with a large number of people doing the same thing. Would you not be better at looking at an archiving product that can archive off the older files leaving stub files behind so any application can carry on working with no interruption. Assuming that the data is stored as lots of files. Perhaps you need to look at some traditional HSM type product that integrates with a tape library except instead of using a physical tape library you use a VTL which will do the deduplication and compression for you. You then have the added advantage that the VTL can spit out copies of the virtual tapes to be taken off site for DR. This type of solution should then be platform independent. ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Walker Sent: 27 February 2007 03:18 To: Glenn Dekhayser; Wilbur Castro; toasters(a)mathworks.com Subject: RE: data management through compression for Netapp I've also heard good things about Data Domain. On the other hand, does anyone have any experience with the A-SIS deDupe technology from NetApp? Sounds great, except for the 'out of band' nature of it. Glenn ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser Sent: Monday, February 26, 2007 8:36 PM To: Wilbur Castro; toasters(a)mathworks.com Subject: RE: data management through compression for Netapp Wilbur: What are your performance requirements? Adding compression/deDup into this has a serious impact on I/O performance, it will pretty much totally screw any read-ahead optimization. If you still want to go ahead, look at Data domain's Gateway series. It doesn't formally support Netapp, but i'm sure you could use it. This will do exactly what you want, as long as you want NFS! Glenn (the other one) ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Wilbur Castro Sent: Monday, February 26, 2007 4:55 PM To: toasters(a)mathworks.com Subject: data management through compression for Netapp Hi toasters, We have a couple of 100 TBs of heterogenous storage (some from netapp), and see that our storage grows close to 60% over year. We were looking at alternatives for managing this data growth. Compression was one of the techniques we were considering for our nearline and (possibly) primary storage. Our applications cannot change to do their own compression, so it boils down to doing this in the storage layer or through an external device. Also, we'd like to not have any performance impact and compression to happen transparently. Deduplication technology from storage vendors would help, but it is not a hetrogenous solution. I am not aware of any compression technology from netapp. Are you folks aware of any solutions? Would love to hear your experience with those or other alternative ways you deal with the storage growth problem while managing costs. Thx, Wilbur

2 1

RE: data management through compression for Netapp
by Glenn Walker 27 Feb '07

27 Feb '07

I've also heard good things about Data Domain. On the other hand, does anyone have any experience with the A-SIS deDupe technology from NetApp? Sounds great, except for the 'out of band' nature of it. Glenn ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Dekhayser Sent: Monday, February 26, 2007 8:36 PM To: Wilbur Castro; toasters(a)mathworks.com Subject: RE: data management through compression for Netapp Wilbur: What are your performance requirements? Adding compression/deDup into this has a serious impact on I/O performance, it will pretty much totally screw any read-ahead optimization. If you still want to go ahead, look at Data domain's Gateway series. It doesn't formally support Netapp, but i'm sure you could use it. This will do exactly what you want, as long as you want NFS! Glenn (the other one) ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Wilbur Castro Sent: Monday, February 26, 2007 4:55 PM To: toasters(a)mathworks.com Subject: data management through compression for Netapp Hi toasters, We have a couple of 100 TBs of heterogenous storage (some from netapp), and see that our storage grows close to 60% over year. We were looking at alternatives for managing this data growth. Compression was one of the techniques we were considering for our nearline and (possibly) primary storage. Our applications cannot change to do their own compression, so it boils down to doing this in the storage layer or through an external device. Also, we'd like to not have any performance impact and compression to happen transparently. Deduplication technology from storage vendors would help, but it is not a hetrogenous solution. I am not aware of any compression technology from netapp. Are you folks aware of any solutions? Would love to hear your experience with those or other alternative ways you deal with the storage growth problem while managing costs. Thx, Wilbur

2 1

data management through compression for Netapp
by Wilbur Castro 27 Feb '07

27 Feb '07

Hi toasters, We have a couple of 100 TBs of heterogenous storage (some from netapp), and see that our storage grows close to 60% over year. We were looking at alternatives for managing this data growth. Compression was one of the techniques we were considering for our nearline and (possibly) primary storage. Our applications cannot change to do their own compression, so it boils down to doing this in the storage layer or through an external device. Also, we'd like to not have any performance impact and compression to happen transparently. Deduplication technology from storage vendors would help, but it is not a hetrogenous solution. I am not aware of any compression technology from netapp. Are you folks aware of any solutions? Would love to hear your experience with those or other alternative ways you deal with the storage growth problem while managing costs. Thx, Wilbur

3 2

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 2007