toasters

toasters@lists.teaparty.net

1 participants
13515 discussions

Question about SnapMirror, cascade, and deleting old snapshots.
by Nathan Patwardhan 21 Oct '08

21 Oct '08

We using SnapMirror for three filers in a cascade. filerA is the master so we normally cascade SnapMirror as filerA->filerB->filerC. In the case of a DR event, we'll repoint things so we end up with filerB->filerA->filerC or filerC->filerA->filerB or some combination like that. After the DR event is over, we put restructure the cascade so that it goes A->B->C as noted above. As part of this restructuring, we will do a 'snapmirror release' for any relationships that no longer exist after things are repointed. Generally this cleans up any snapshots that we don't need and things are happy. Recently, I noticed that we have a couple of old and somewhat large snapshots that never expire. These have been around for a couple of months and are hogging 5-10% of a volume that's already pretty full. I'd like to delete them but I don't see any Broken-Off relationships when I run 'snapmirror status <volume>'. I'm just not comfortable winging it with release until I get a better grasp on how SnapMirror got into this state. Looking at 'snapmirror destinations -s <volume>' I have a pretty good idea of how things were pointed in our cascade during DR events that generated these snapshots in the first place, but I remain unclear about how to (or even if I can!) do a snapmirror release in this case. Please advise! -- Nathan Patwardhan "Of course, the US has many elements of socialism already since capitalists, like cats, tend to get themselves stuck up a tree every so often." -- Joe Johnston

2 3

Limits on ASIS enabled FlexVols
by Ray Van Dolson 21 Oct '08

21 Oct '08

Hello fellow toaster-ites! I am evaluating the use of NFS datastore on NetApp for use with ESX. Initially the potential benefits of ASIS (dedup) had me just about sold, however, I discovered that with the FAS2020 we're looking at there is a 500GB limit to the size of ASIS enabled FlexVols. Bummer. I see this limit goes up to 1TB with the FAS2050, so I may need to compare that option as well... Moreover, I'm wondering what the limit on the *number* of max-sized ASIS enabled flexvols is per filer? Could I have 15 500GB ASIS enabled flexvols in the FAS2020 above? That wouldn't seem to make logical sense as I understand the limitation is tied to memory.... but this might help us get around this size limitation. Thanks in advance. (No sales replies to this please) Ray

3 3

Re: Question about SnapMirror, cascade, and deleting old snapshots.
by Nathan Patwardhan 21 Oct '08

21 Oct '08

On Mon, Oct 20, 2008 at 10:41 PM, Bassett, Oliver <oliver.bassett(a)nz.fujitsu.com> wrote: > Nathan, > > Easiest solution at this point is to delete the really large/old > snapshot in the volume on FilerA. This will replicate the snapshot to > filer b and filer c, without damaging the existing snapmirror > relationships (as long as everything is up to date with low lag times). Ah, that's a problem I'd forgotten to mention and why I'm hesitant to just go and release things. On FilerA, although the master, the snapshot is still locked by snapmirror: 5% ( 4%) 4% ( 3%) Aug 20 08:05 filerA(0101195225)_perforce.7 (snapmirror) To my surprise the snapshot is in the *same* state on filerB and filerC, so unfortunately as things stand right now, I can't just go and delete the snapshot. -- Nathan Patwardhan "Of course, the US has many elements of socialism already since capitalists, like cats, tend to get themselves stuck up a tree every so often." -- Joe Johnston

1 0

SnapMirror and NDMP ; competing snap schedules?
by Nick Silkey 21 Oct '08

21 Oct '08

Toasters -- Having abandoned synch SnapMirror due to compatibility issues, we are looking to asynch snaps for BCP/DR. Unfortunately we still need to cut the SnapMirror destination (7.2.4) to tape via NDMP. It looks like an outstanding bug <http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=36554> and corresponding KB article <http://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb44293> indicate that the schedules of SnapMirror and NDMP moves should never compete with one another due to tripping on one another's snaps. So we either need to 1.) break the mirror in order to blow out backups, or 2.) setup a SnapMirror schedule which leaves a window for scheduled backups. $mgmt would much prefer the first option in order to maximize replication, and since no one is able to confirm test numbers for backup time duration. So ... any production tips on hailing the SnapMirror destination to break when its time to get our NDMP on? And resync'ing upon NDMP completion? Or am I really off-base with the above? :) Insight appreciated. Thanks. -- Nick

3 2

R: Snapvault slow on one specific volume?
by Milazzo Giacomo 15 Oct '08

15 Oct '08

Yes of course you're right. We all know that manual paragraph that but considering this option cannot damage data contained it could be useful to test it also in this case...there are a lot of misteries in options... J Regards, Da: De Wit Tom (Consultant) [mailto:tom.de.wit@consultant.volvo.com] Inviato: mercoledì 15 ottobre 2008 16.06 A: Milazzo Giacomo; Darren Sykes; Glenn Walker; Page, Jeremy; toasters(a)mathworks.com Oggetto: RE: Snapvault slow on one specific volume? I wouldn't recommend enabling extents for volumes other than the ones holding exchange databases. The option does degrade runtime performance and only improves validation of exchange databases, so the option should only be used with Exchange databases. The DataOntap administration guide tells the following: When to enable logical extents <http://now.netapp.com/NOW/knowledge/docs/ontap/rel73/html/ontap/sysadmin/tu…> You enable logical extents for volumes that contain Microsoft Exchange data only. The decision to use logical extents involves a trade-off between improved database validation performance and runtime performance. Use logical extents when you want to improve validation performance. If runtime performance is higher priority, you might not want to use extents. Grtz, Tom ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Milazzo Giacomo Sent: woensdag 15 oktober 2008 15:21 To: Darren Sykes; Glenn Walker; Page, Jeremy; toasters(a)mathworks.com Subject: R: Snapvault slow on one specific volume? Reading about this they seem the same issues with Exchange on WAFL LUNs on a volume WITHOUT the "vol options extent on". You certainly know that if you have an old Data Ontap without that options (it came fm 7.2 if I well remember) or if you leave it off and you have Exchange LUNs this can cause terribly bad performances (and fragmentation nightmares) as the one here reported. Waiting for a fix I put it so...why don't you put the extent vol options to on and try again? J Regards Da: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] Per conto di Darren Sykes Inviato: mercoledì 15 ottobre 2008 10.10 A: Glenn Walker; Page, Jeremy; toasters(a)mathworks.com Oggetto: Re: Snapvault slow on one specific volume? I'd say it was probably the bug; in theory dedup should increase performance in that situation as the block would be stored in the cache and therefore we wouldn't need to go to disk to get that data. The degradation is also really pronounced - doing a plain old rsync file copy of the VMDK's shows great performance right until it hits the sequence of dedup'd blank blocks, then the transfer literally almost stops. From speaking to a couple of people, I wouldn't expect 7.2.5.1 or 7.3 to provide many improvements over the latest P releases of of 7.2.4. The bug is more likely to be fixed in 7.3.1, so it's a good 4 months away. However, as the NOW case mentioned, this won't affect the normal operation of a VM, assuming you're not attempting to do anything horrible - like a block for block disk image. Someone also suggested that a disk format might cause problems, however I'd query that as writes are unaffected, it's just reading back those blank blocks. In normal operation a guest OS would never do that, as far as it's concerned (due to the information stored within the guest's file system) they're just unallocated blocks on the disk that'll never be read. Darren On 15/10/2008 00:43, "Glenn Walker" <ggwalker(a)mindspring.com> wrote: Guessing that it sped up access due to the bug (and/or regular performance degradation from hitting the same blocks multiple times due to de-dupe)? With some of the dedupe improvements rumored in 7.3, I'd expect that to potentially improve. ________________________________ From: Darren Sykes [mailto:Darren.Sykes@csr.com] Sent: Tuesday, October 14, 2008 9:45 AM To: Glenn Walker; Page, Jeremy; toasters(a)mathworks.com Subject: RE: Snapvault slow on one specific volume? SMotion - you'd hope (without breaking any NDA's) that they would address that in the next version, and possibly give you the option to specify thin or fat disks explicitly. Out of interest - I removed dedup on our templates volume and a VM provisioning job that took 16 mins yesterday took less than 5 mins today. Darren. ________________________________ From: Glenn Walker [mailto:ggwalker@mindspring.com] Sent: 14 October 2008 13:43 To: Darren Sykes; Page, Jeremy; toasters(a)mathworks.com Subject: RE: Snapvault slow on one specific volume? FC and iSCSI does mean FAT VMDK, unless you create them manually and specify thin provisioned (not typical). The Storage VMotion info is good to know - I hope they get that fixed soon. Thanks for the additional info - it's something for us to watch out for. We went NFS from the start (and performed P2V and V2V into the NFS-based datastores), but I know that SVMotion has been used and templates as well. I'll try to check our use of templates a bit later today... Glenn ________________________________ From: Darren Sykes [mailto:Darren.Sykes@csr.com] Sent: Tuesday, October 14, 2008 3:00 AM To: Glenn Walker; Page, Jeremy; toasters(a)mathworks.com Subject: RE: Snapvault slow on one specific volume? Glenn, That's true; by default all new VM's created on an NFS volume would be thin provisioned. I'm not sure if that's the case for templates though (I thought they were created fat on purpose for performance reasons when deploying them). Also, we migrated from FC and iSCSI LUNS (which is basically a file copy) so most of our VM's are fat anyway. From what I understand using SVMOTION also results in a fat filed VM, though that's not officially supported on NFS in ESX3.5. So, in summary there are a few reasons why you might end up with non-thin provisioned VM's on NFS and may therefore hit this bug. Darren ________________________________ From: Glenn Walker [mailto:ggwalker@mindspring.com] Sent: Tue 10/14/2008 03:23 To: Darren Sykes; Page, Jeremy; toasters(a)mathworks.com Subject: RE: Snapvault slow on one specific volume? I was under the impression that ESX over NFS used thin-provisioned VMDKs by default (that's how it is in our environment, and all of the files are appearing as thin-provisioned). Would this then be not the same bug? Thin-provisioned VMDKs means that the portion of the VMDK not allocated to the guest would be treated as a sparse file, not a file filled with zeros. (unless someone decided to perform a full format on the 'disk', perhaps?) ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Darren Sykes Sent: Monday, October 13, 2008 3:51 PM To: Page, Jeremy; toasters(a)mathworks.com Subject: RE: Snapvault slow on one specific volume? Jeremy/All, Following on from our conversation offline: It would seem you (and I) have been suffering from the bug described here: http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=281669 We saw it on template volumes. I'm planning to disable ASIS on that volume to attempt to speed up access. Obviously, that solution may be less than useful in your environment where it's live data volumes which benefit from ASIS. Darren ________________________________ size=2 width="100%" align=center tabIndex=-1> From: owner-toasters(a)mathworks.com on behalf of Page, Jeremy Sent: Mon 10/13/2008 13:14 To: toasters(a)mathworks.com Subject: Snapvault slow on one specific volume? I have an aggr with two volumes on it. One of them is a 3.5 TB CIFS/NFS share that is reasonably fast to snapvault and a 1 TB NFS share (ESX VMs) that is exceptionally slow. As in it's been doing it's initial copy for over a week and still has not finished. NDMP backups of this volume are also quite slow, does anyone know why it would be so much slower then the other volume using the same spindles? The filer is not under extreme load, although occasionally it's pretty busy. Here is a "normal" sysstat: CPU Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk ops/s in out read write read write age hit time ty util 12% 1007 2970 8996 15769 9117 0 0 8 93% 49% : 41% 18% 920 2792 6510 11715 6924 0 0 8 99% 84% T 39% 15% 1276 3580 10469 15942 8041 0 0 10 92% 33% T 36% 13% 1487 3416 11347 15632 4907 0 0 11 89% 42% : 43% 17% 1417 3180 9890 14000 9444 0 0 9 98% 79% T 41% 13% 972 3704 9705 15427 9934 0 0 7 92% 46% T 51% 18% 1087 2947 11911 17717 4640 0 0 9 98% 33% T 47% 11% 1204 3358 11219 14090 5159 0 0 7 88% 100% : 50% 12% 1161 2808 9085 12640 5936 0 0 9 90% 33% T 44% 13% 981 4735 11919 16125 7097 0 0 9 92% 45% : 43% 15% 1158 5780 12480 17565 8266 0 0 10 92% 88% T 41% I'm just having difficulty trying to determine why two volumes on the same spindles would be so different in the time it takes to do their initial transfer. Also, the VM's do not seem slower then those hosted on other aggregates (this one is 3 RG of 11 disks each, Ontap 7.2.4 on a 3070A IBM rebranded). To report this email as spam click here <https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==> . This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.

1 0

NTP QFS question
by Milazzo Giacomo 15 Oct '08

15 Oct '08

Hi all I don't know if there's somebody that can help me. I need NTP for a customer both in the NAS NetApp edition and for some iSCSI/FC LUNs mounted using Snapdrive on Windows. One of my account manager told me that NTP licensing model offers one kind of license for DAS/RAID on Windows host and another one for SAN tiered on TB basis (up to 2, 5 or unlimited). The 2 TB SAN versione costs a lot of money more respect the DAS/RAID one and I don't understand the difference between having a 2 TB DAS disk quoted/screened by NTP and a iSCSI LUN of same size!!! I've tried the DAS/RAID version on a Windows host with iSCSI LUNs and it works on them fine. Where's the difference? Only commercials? regards

2 1

Running OnTap SIM 7.3 on ESX VM
by Robert Borowicz 10 Oct '08

10 Oct '08

He all, I'm working for a start-up now who is trying to develop against the OnTap SNMP agent and API to do Systems Mgmt with the appliance we make. I've suggested using the SIM for OnTap 7.3 and have stood it up on a ESX VM imaged with CenOS 5.2. I can install the OnTAP SIM just fine with all the defaults using dir /sim, 3 disks, and using eth0 on the VM image of CenOS. Our lab at work uses 192.168.10.1 for a Def Gate and the host VM is using 192.168.9.110 and I can ping the Def Gate from CenOS just fine. But when I fire up the SIM (letting it DHCP an addr) I can't ping the Def Gate from the SIM. So I asked the ESX admin at work to create another interface on my VM CenOS environ. He gave it a static, (192.168.9.109) and I applied it to eth1 as it were. I STILL can't ping the Def Gate via the SIM. I CAN ping the IP I stood up for the SIM (.109) from other boxes in the lab but just not ANYTHING from inside the SIM on the VM. Anybody try to use a VM to run the SIM in and see similar experiences ? I stood up the same 7.3 SIM at home on a Generic Athlon 3200+ running CenOS 5.2 and it's FINE. That box only has one NIC and the OnTap 7.3 SIM piggy backs onto eth0 just fine creating NS0 and booting up fine. Suggestions welcomed. I've asked the lab manager for my own bare metal to run the SIM on in meantime.... TIA -Rob

5 5

Synchronous SnapMirror destinations + NDMP moves
by Nick Silkey 07 Oct '08

07 Oct '08

(NB: Resent from $oldjob. Newly-subscribed identity is having issues posting.) Toasters -- Anyone out there NDMP moving data from synchronous SnapMirror destinations successfully? We have a FAS3020C cluster at 7.2.4 and are moving forward on each head synchronously SnapMirroring via GigE to a remote FAS3020, also at 7.2.4. Ultimately we want to cut backups via NDMP to TSM over FCP from the SnapMirror destinations on secondary storage. There are some concerns which were raised by our SE about SnapMirror and NDMP stepping on one another, <http://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb44293> being one example. Looking to hear from those in the trenches on the above. Thanks. -- Nick

2 2

Aggregate snapshot on metrocluster
by Nicholas Bernstein 07 Oct '08

07 Oct '08

Does anyone know if the aggr snapshot can be turned off on a metrocluster? It looks like it creates a separate aggr snapshot that metro uses, and the schedule could be disabled, or paired down for space reclamation. -Nick -- Nicholas Bernstein Technologist, Consultant, Instructor http://nicholasbernstein.com

2 2

Re: Mail Delivery Failure
by Nicholas Bernstein 07 Oct '08

07 Oct '08

I¹ve noticed a couple of these bounces over the last week or so. Would it be possible to adjust the majordomo settings to have the list rewrite the sender to bounce messages go to a single /dev/null address? -Nick On 10/7/08 6:16 AM, "Mail Manager" <-----------> wrote: > Please do not reply to this note. > > The mail address <------------> is not valid. > > Your message with subject "Re: AIX over FC speed issues" was not delivered. > > Following are the original recipient(s). > > <---------------> > > -- Nicholas Bernstein Technologist, Consultant, Instructor http://nicholasbernstein.com

2 1

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