I have lots of existing q-tree snapmirrrors of the form:
srcfiler:/vol/volM/qtreeX destfiler:/vol/volN/qtreeY
"srcfiler" (DNS name) is the e11 interface on srcfiler "destfiler" (DNS name) is the e9a interface on destfiler
We just built a "dedicated snapmirror/backup" network and added the following:
"srcfiler-backup" (DNS name) is the e0 inteface on srcfiler "destfiler-backup" (DNS name) is the e11a interface on destfiler
Subsequent 'snapmirror update -S ...' commands (we don't use snapmirror.conf) still use the non "-backup" network links. I'm not seeing the counters on the "-backup" links increment via the `ifstat` command.
The $64,000 question: --------------------- How do I "move" these snapmirrors to the "-backup" network links...without, of course, re-initializing them?
I'm expecting, in the end, to see `snapmirror status` give back to me:
srcfiler-backup:/vol/volM/qtreeX destfiler-backup:/vol/volN/qtreeY
and see the counters on e0 on srcfiler and e11a on destfiler increment.
Until next time...
The MathWorks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---
Some presumptions:
1. the destfiler:/vol/volN/qtreeY in /etc/snapmirror.conf *must* be the "hostname" of the filer. 2. the srcfiler-backup:/vol/volM/qtreeX in /etc/snapmirror.conf can be *any* hostname associated with the source filer. (i.e. if src-filer-e11 is the hostname for that interface use that) 3. destfiler and srcfiler-backup *must* be on different networks
In your example:
srcfiler:/vol/volM/qtreeX destfiler:/vol/volN/qtreeY
should change to:
srcfiler-backup:/vol/volM/qtreeX destfiler:/vol/volN/qtreeY
What happens is destfile tries to talk to srcfiler-backup and looks for a common interface. If it finds one then it will use srcfiler-backup interface and should talk to the destfiler-backup
On Wed, Apr 2, 2008 at 10:25 AM, Todd C. Merrill tmerrill@mathworks.com wrote:
I have lots of existing q-tree snapmirrrors of the form:
srcfiler:/vol/volM/qtreeX destfiler:/vol/volN/qtreeY
"srcfiler" (DNS name) is the e11 interface on srcfiler "destfiler" (DNS name) is the e9a interface on destfiler
We just built a "dedicated snapmirror/backup" network and added the following:
"srcfiler-backup" (DNS name) is the e0 inteface on srcfiler "destfiler-backup" (DNS name) is the e11a interface on destfiler
Subsequent 'snapmirror update -S ...' commands (we don't use snapmirror.conf) still use the non "-backup" network links. I'm not seeing the counters on the "-backup" links increment via the `ifstat` command.
The $64,000 question:
How do I "move" these snapmirrors to the "-backup" network links...without, of course, re-initializing them?
I'm expecting, in the end, to see `snapmirror status` give back to me:
srcfiler-backup:/vol/volM/qtreeX destfiler-backup:/vol/volN/qtreeY
and see the counters on e0 on srcfiler and e11a on destfiler increment.
Until next time...The MathWorks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com
On Wed, 2 Apr 2008, tmac wrote:
- the destfiler:/vol/volN/qtreeY in /etc/snapmirror.conf *must* be
the "hostname" of the filer.
As I mentioned, we do not use snapmirror.conf.
That said, I can create *new* snapmirrors and have the status reflect the "-backup" interface, as you surmise:
should change to:
srcfiler-backup:/vol/volM/qtreeX destfiler:/vol/volN/qtreeY
Yes, I see that...with new snapmirrors.
However, I can't yet make *existing* snapmirrors use the new interfaces. They seem to be "stuck" using the interfaces they were initialized with.
- the srcfiler-backup:/vol/volM/qtreeX in /etc/snapmirror.conf can be
*any* hostname associated with the source filer. (i.e. if src-filer-e11 is the hostname for that interface use that)
No snapmirror.conf involved, but I do in fact see that with `snapmirror status.`
- destfiler and srcfiler-backup *must* be on different networks
Yes, that is true. I neglected to mention that.
Until next time...
The MathWorks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---
In the process of doing this myself. I'm using the facility provided in the /etc/snapmirror.conf file that allows you to set the interface to be used. Example:
Sourcefiler-backup = failover(<name/ip of src int><name/ip of dst int>)
Seems to work so far, but haven't had a lot of time to test it. Will know by Friday evening if we're seeing what we expect.
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Todd C. Merrill Sent: Wednesday, April 02, 2008 2:50 PM To: tmac Cc: toasters@mathworks.com Subject: Re: how to "move" an existing snapmirror to new network interfaces?
On Wed, 2 Apr 2008, tmac wrote:
- the destfiler:/vol/volN/qtreeY in /etc/snapmirror.conf *must* be
the "hostname" of the filer.
As I mentioned, we do not use snapmirror.conf.
That said, I can create *new* snapmirrors and have the status reflect the "-backup" interface, as you surmise:
should change to:
srcfiler-backup:/vol/volM/qtreeX destfiler:/vol/volN/qtreeY
Yes, I see that...with new snapmirrors.
However, I can't yet make *existing* snapmirrors use the new interfaces. They seem to be "stuck" using the interfaces they were initialized with.
- the srcfiler-backup:/vol/volM/qtreeX in /etc/snapmirror.conf can be
*any* hostname associated with the source filer. (i.e. if src-filer-e11 is the hostname for that interface use that)
No snapmirror.conf involved, but I do in fact see that with `snapmirror status.`
- destfiler and srcfiler-backup *must* be on different networks
Yes, that is true. I neglected to mention that.
Until next time...
The MathWorks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---
FYI - this worked as described in the documentation.
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Glenn Walker Sent: Wednesday, April 02, 2008 8:10 PM To: Todd C. Merrill; tmac Cc: toasters@mathworks.com Subject: RE: how to "move" an existing snapmirror to new network interfaces?
In the process of doing this myself. I'm using the facility provided in the /etc/snapmirror.conf file that allows you to set the interface to be used. Example:
Sourcefiler-backup = failover(<name/ip of src int><name/ip of dst int>)
Seems to work so far, but haven't had a lot of time to test it. Will know by Friday evening if we're seeing what we expect.
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Todd C. Merrill Sent: Wednesday, April 02, 2008 2:50 PM To: tmac Cc: toasters@mathworks.com Subject: Re: how to "move" an existing snapmirror to new network interfaces?
On Wed, 2 Apr 2008, tmac wrote:
- the destfiler:/vol/volN/qtreeY in /etc/snapmirror.conf *must* be
the "hostname" of the filer.
As I mentioned, we do not use snapmirror.conf.
That said, I can create *new* snapmirrors and have the status reflect the "-backup" interface, as you surmise:
should change to:
srcfiler-backup:/vol/volM/qtreeX destfiler:/vol/volN/qtreeY
Yes, I see that...with new snapmirrors.
However, I can't yet make *existing* snapmirrors use the new interfaces. They seem to be "stuck" using the interfaces they were initialized with.
- the srcfiler-backup:/vol/volM/qtreeX in /etc/snapmirror.conf can be
*any* hostname associated with the source filer. (i.e. if src-filer-e11 is the hostname for that interface use that)
No snapmirror.conf involved, but I do in fact see that with `snapmirror status.`
- destfiler and srcfiler-backup *must* be on different networks
Yes, that is true. I neglected to mention that.
Until next time...
The MathWorks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---
Is there any limit to the number of CIFS shares that can be defined on/under a filer / clustered pair / aggregate / volume / qtree / etc.?
Until next time...
The MathWorks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---
There is a share limit per controller, but it's based on model/system memory. I'd start here.
http://now.netapp.com/NOW/knowledge/docs/ontap/rel73/html/ontap/filesag/ accessing/concept/c_oc_accs_CIFS_resource_limits_by_system_memory.html
But just to give you an idea, it seems to run from about 12,000 on older, small systems to as high as 192,000 on 6000-class controllers.
-- Adam Fox Systems Engineer adamfox@netapp.com
-----Original Message----- From: Todd C. Merrill [mailto:tmerrill@mathworks.com] Sent: Thursday, August 14, 2008 3:21 PM To: toasters@mathworks.com Subject: limit to number of CIFS shares?
Is there any limit to the number of CIFS shares that can be defined on/under a filer / clustered pair / aggregate / volume / qtree / etc.?
Until next time...
The MathWorks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill@mathworks.com http://www.mathworks.com ---
Hey Todd,
On Thu, Aug 14, 2008 at 9:21 PM, Todd C. Merrill tmerrill@mathworks.com wrote:
Is there any limit to the number of CIFS shares that can be defined on/under a filer / clustered pair / aggregate / volume / qtree / etc.?
While I haven't ever encountered the limits of ONTAP, on smaller models there is a noticeable performance-related downside when using 1000+ shares. For some reason it seems that all the CIFS locking, states and maybe even the shares themselves take up quite some memory, resulting in a lower cache-age.
If you want to create a per-user share, you might want to consider the autohome option, it seems to take up less resources.
HTH & HAND !
-
Fox, Adam -
Glenn Walker -
Nils Vogels -
tmac -
Todd C. Merrill