toasters November 2008

toasters@lists.teaparty.net

54 participants
58 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

Ontap 7.2.6 is under investigating
by Kappe, Michael 17 Apr '09

17 Apr '09

Hi, after Announcing Ontap 7.2.6 a few days ago, now it is not downloadable from the NOW-Page. Anyone know whats happend? Regards Michael

11 14

do toaster need a day off? (WAFL scans)
by Todd C. Merrill 13 Dec '08

13 Dec '08

Two scenarios: 1. R200, 7.2.2, two 12 TB aggregates, 85 volumes of various sizes, 70-80% full snapvault secondary, ALWAYS receiving snapvaults and nearly ALWAYS spinning to tape. 2. 6070, 7.2.4, two 8 TB aggregates, 27 volumes between 150 and 700 GB, 60-70% full recent migration (via volume snapmirrors) from 980's, serves home directories to NFS and CIFS clients. We stopped all snapmirrors/snapvaults to the R200, terminated CIFS, and shut off NFS. CPU utilization remained 90%+ and disk reads remained high for the next 6-7-8 hours until it finally quieted down. After volume snapmirroring the home dirs from the 980's to the 6070, we re-pointed the snapvaults (modify; start -r) and allowed NFS and CIFS access. 5 days later, file server performance still blows (worse than the 980's -- D'oh! Egg, meet Face; Face, meet Egg), with moderate CPU load 30-40-50% but high disk reads. In both cases, we determined that lots of WAFL scans were going on: container block reclamation volume deswizzling active bitmap rearrangement (of course...this NEVER seems to stop) and a few other types that have already scrolled out of my buffer. So, we figure--eventually--the WAFL scans will catch up and performance will go back to normal on the 6070. The performance of the R200 always blows. So...here finally is the question: do toasters need a day off? Said another way, to maintain acceptable performance and low/fast response times, do toasters need a goodly amount of (relatively) idle time in order for these WAFL scans to complete? Could the sub-optimal performance of another group of six 6070's that we have, that we *pound on* 7x24, be explained in part by always having at least the container block reclamation scan going on? 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 ---

5 7

7.2.x snapmirror to 7.3 and back again
by Roscoe P Coltraine 01 Dec '08

01 Dec '08

i have a filer on 7.2.4 with a very large volume size of 12164g. i need to do some loop reorginzation and want to snapmirror it off to a newer filer running 7.3 and then delete it to free up space for some other volume migrations and shelf swaps. when all is said and done i want to put this volume back. so the question is will i be able to snapmirror it back from 7.3 to 7.2.x?

4 4

SD 6.01 / W2K8 x64 / iSCSI and NLB Cluster
by Raj Patel 28 Nov '08

28 Nov '08

Hi all, A few queries about the above config - We are setting up a new E2k7 system with 2 front end CAS servers with NLB and 2 back end Mailbox servers in NLB config and doing CCR between them (no shared storage). I was able to install SnapDrive 6.01 and create four LUN's (non shared dedicated) on each Mailbox server on two seperate SAN's for the mail stores & logs. No problem. However as soon I rebooted and went to check the LUN's (which stayed connected) and create a new one I got a couple of errors (different on each system) - RPC server unavailable - Security package related error Oddly I can expand existing LUN's OK via SD - so some functionality exists - just can't create a new LUN within SD. I have had a suggestion to make sure the Windows Quorum Witness Disk should also be on the SAN - following Microsoft best practive I've created a small Quorum Witness Disk and share on a CAS server. Thats fine - still doesn't fix the RPC error (I can ping and access the admin share on the SAN from each mailbox server). The most annoying thing is that none of these issues has cropped up with W2K3 and SD 4.2.1 - I'm following the same fundamental setup steps. Given I'm not using shared storage clustering just CCR and NLB I want to discover the root of the SD errors - is it SD trying to be clever and insisting that for a Windows cluster you really need shared disks registered with the cluster administrator regardless of wether they're shared or not ? - just some weirdness with W2K8 and SD 6.01 ? - are there any gotchas with W2K8 and SD 6.01 that I need to be aware of ? I just noticed theres a DCOM exception for the W2K8 firewall on NOW - how come SD doesn't set this stuff up at install time ? I want to eliminate the clustering ASAP issue because until I nail the problem the Exchange guys can't really proceed with the rest of the install. Particularly if I need to keep messing around with breaking and re-establishing the cluster to sort out an RPC error. Thanks in advance, Raj.

1 0

Re: Downgrading Data ONTAP?
by Simon Vallet 28 Nov '08

28 Nov '08

Hi, On Tue, 25 Nov 2008 18:37:56 +0100 "Patrick van Helden" <pvh(a)databasement.eu> wrote: > I have reverted Ontap on several occasions, and yes before the revert > you will have to delete all the snapshots that were made with the new > Ontap version. Any snapshots made with the old version of ontap can > remain on the system. Confirmed. We downgraded yesterday, and it went quite well; the procedure from NetApp did indeed hint at deleting previous snapshots before downgrading. This cluster seems in good shape now. Let's just hope it'll stay that way ;-) Simon -- Simon Vallet Ingénieur systèmes, réseaux, sécurité CEA DSV/IG/GEN - Genoscope Tél.: +33 1 60 87 36 06 Mél.: svallet(a)genoscope.cns.fr

1 0

Re: vfiler migrate - qtree level mounts
by Fox, Adam 27 Nov '08

27 Nov '08

I can't see how this would be the case as long as you're SnapMirror relationships are volume-based, which vfiler migrate should do by default. But if you are migrating at the qtree level, clients would have to remount. -- Adam Fox ------------------------ Typed with my thumbs on a very small keyboard. ----- Original Message ----- From: Buerger, Andreas <andreas.buerger(a)wincor-nixdorf.com> To: toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Thu Nov 27 11:14:08 2008 Subject: vfiler migrate - qtree level mounts Hi, I want to perform a vfiler migrate in a production evironment this weekend, and regarding that I had a deeper look at the documentation at NOW. I did the migrate procedure some times before but always with non production data, and every time the migration went smooth without any client interuption (just nfs access). But when I had a deeper look at the documentation I was a little worried about the following chapter, how does a vfiler migration affect clients: http://now.netapp.com/NOW/knowledge/docs/ontap/rel73_vs/html/ontap/vfile r/provisioning/concept/c_oc_prov_vfiler-dr-how-migrating-affects-clients .html#c_oc_prov_vfiler-dr-how-migrating-affects-clients (same at the 7.2.5 documenation) # NFS volume-level mounts move transparently. # NFS qtree-level mounts need to be remounted. I tested that yesterday and and I can't reproduce that qtree level mounts need to be remounted after a vfiler migrate. Nearly every mount in our environment is based on the qtree level, so we would have a big problem if that's true. When I performed vfiler migrations in the past I never had any errors, it was just like a filer reboot or takeover, and I'm pretty sure that I had a lot qtree level mounts on the clients that were affected. Can anybody explain, why a qtree level mount needs be remounted like the documentation says? And whats the difference for the client if it mounts a complete volume like filer:/vol/volume or a qtree like filer:/vol/volume/qtree? May be someone can put me on the right way. Cheers Andreas -- WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

1 0

vfiler migrate - qtree level mounts
by Buerger, Andreas 27 Nov '08

27 Nov '08

Hi, I want to perform a vfiler migrate in a production evironment this weekend, and regarding that I had a deeper look at the documentation at NOW. I did the migrate procedure some times before but always with non production data, and every time the migration went smooth without any client interuption (just nfs access). But when I had a deeper look at the documentation I was a little worried about the following chapter, how does a vfiler migration affect clients: http://now.netapp.com/NOW/knowledge/docs/ontap/rel73_vs/html/ontap/vfile r/provisioning/concept/c_oc_prov_vfiler-dr-how-migrating-affects-clients .html#c_oc_prov_vfiler-dr-how-migrating-affects-clients (same at the 7.2.5 documenation) # NFS volume-level mounts move transparently. # NFS qtree-level mounts need to be remounted. I tested that yesterday and and I can't reproduce that qtree level mounts need to be remounted after a vfiler migrate. Nearly every mount in our environment is based on the qtree level, so we would have a big problem if that's true. When I performed vfiler migrations in the past I never had any errors, it was just like a filer reboot or takeover, and I'm pretty sure that I had a lot qtree level mounts on the clients that were affected. Can anybody explain, why a qtree level mount needs be remounted like the documentation says? And whats the difference for the client if it mounts a complete volume like filer:/vol/volume or a qtree like filer:/vol/volume/qtree? May be someone can put me on the right way. Cheers Andreas -- WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Gesch�ftsf�hrer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. J�rgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enth�lt vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt�mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

1 0

Fabric Metrocluster and FC switches
by Milazzo Giacomo 27 Nov '08

27 Nov '08

Hi all Up to now we've always successfully used Brocade 200E, 8 or 16 port, also because these are the only FC switches well documented in the TR3548 (Metrocluster Design and Implementation Guide). In that doc you can find also the correct cabling schema from shelves/heads to the correct port of switched. And in my experience it seems that MC software in Data Ontap seems to be stricly linked to the Brocade: if you wrong a cabling the system will warn you! Anyway I've read other docs where other model and/or vendors are cited as supported FC switches in a FMC config. McData, Cisco, other Brocade models and so on. Is someone there able to give me the right path on where to find documentation on how to cable/connect/use other switched than the 200E? The question comes because we're planning an extende FMC with DWDM switches and other appliances from Cisco and we could save a lot money (in connecting MC switches to DWDM devices...) using i.e. a superior Brocade model or a Cisco MDS. And again, what's about "dark side" of the fiber (not of the moon J). Apart the TR3552 on theory (and some practice) of optical network I was not able to found a doc/guide on, simplifying.... "where I need to link the LC/LC patch that comes from my MC switch? On which model/brand? What I've to ask to communication expert on the existing dark fiber and, over all, what I've to expect from him/her?" Thanks a lot PS) I've also tried to ask this at Prague NetApp Insight 2008 but I've got only...rumors...nothing concrete J

1 0

RE: latency figures visible via SNMP?
by Buerger, Andreas 27 Nov '08

27 Nov '08

It historically logs that data by default, the default period for that is one week backwards, but I bet it's configurable. It helps us a lot, when somebody points the finger at us to look back what was going on during that time. ________________________________ From: Leeds, Daniel [mailto:dleeds@edmunds.com] Sent: Wednesday, November 26, 2008 8:52 PM To: Buerger, Andreas; A Darren Dunham Subject: RE: latency figures visible via SNMP? the perf advisor is real time right? ie it wont historically log this data and graph it later... ive used perf advisor in previous dfm releases and liked it but didnt enjoy having to sit and watch it for hours while waiting for intermittent issues to occur :) -- Daniel Leeds Manager, Storage Operations Edmunds, Inc. 1620 26th Street, Suite 400 South Santa Monica, CA 90404 310-309-4999 desk 310-430-0536 cell -----Original Message----- From: owner-toasters(a)mathworks.com on behalf of Buerger, Andreas Sent: Wed 11/26/2008 11:19 AM To: A Darren Dunham; toasters(a)mathworks.com Subject: RE: latency figures visible via SNMP? If you use dfm a look at the perf advisor might be helpful. Those data is collected via dfm, we use your mentioned figures as well to monitor vol specific statistics. You can enable/disable and configure the perf advisor options in dfm: perfAdvisorDisabledCounterGroups perfAdvisorEnabled perfAdvisorMaxMonitorThreads perfAdvisorPollInterval perfAdvisorShowAllViews perfAdvisorShowDiagCounters perfAdvisorTransport They improved the NMC java client a lot, it's a very helpful utility for specific perf monitoring with lots of detail. The SDK API also an option, but before putting a script together I would check, if the dfm offers enough for your needs. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of A Darren Dunham Sent: Wednesday, November 26, 2008 6:59 PM To: toasters(a)mathworks.com Subject: Re: latency figures visible via SNMP? On Wed, Nov 26, 2008 at 01:22:33PM +0100, Stefan Funke wrote: > I didn't see that in SNMP either, but I've found something similar in > Manage Ontap SDK (http://communities.netapp.com/docs/DOC-1365): > [...] > > Thats far away from SNMP but maybe adoptable to your stats environment. Excellent, I'm not familiar with that, but I'll certainly investigate. I don't need SNMP per se. I'm just seeing how I can get the info from the filer with low overhead. I'd rather not fire off a lot of SSH sessions for what I need. So this might be fine. I have DFM, but I can't see that this value is gathered. Thank you for the pointer. -- Darren -- WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- WINCOR NIXDORF International GmbH Sitz der Gesellschaft: Paderborn Registergericht Paderborn HRB 3507 Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193 Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet. This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

1 0

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 November 2008