Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Netapp: toasters

HSM/ILM for Netapp

 

 

Netapp toasters RSS feed   Index | Next | Previous | View Threaded


babarhaq at email

Jun 2, 2009, 5:12 AM

Post #1 of 20 (6720 views)
Permalink
HSM/ILM for Netapp

Hi all,

IHAC who is searching for a product that can provide HSM/ILM function for massive NAS environment.

This product can be either a hardware appliance, a software, or combination of both that can provide a total transparent solution for our user (i.e. regardless where is the physical data location, user can remain using it old logical path to access the same data) with tiered storage.

So far I can only identify two products one hardware Acopia and the other one is software approach CommVault. Both have it pros and cons but the biggest challenges for both products are not able to manage snapshot and do not go down to qtree level.

Thanks in advance.

Regards,
Babar Haq

--
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com


john.stoffel at taec

Jun 2, 2009, 9:24 AM

Post #2 of 20 (6541 views)
Permalink
Re: HSM/ILM for Netapp [In reply to]

Babar> IHAC who is searching for a product that can provide HSM/ILM
Babar> function for massive NAS environment.

It's not an easy solution space at all. Esp once you start thinking
about Backups and restores. We've been down this route with a couple
of vendors/solutions and found limitations in all of them.

In our case, we're purely interested in NFS clients and servers.
CIFS, iSCSI is a minor part of our operation.

Babar> This product can be either a hardware appliance, a software, or
Babar> combination of both that can provide a total transparent
Babar> solution for our user (i.e. regardless where is the physical
Babar> data location, user can remain using it old logical path to
Babar> access the same data) with tiered storage.

These are going to be *tough* to reconcile together. Having a single
mount point on client systems, which can have data spread across
multiple backend systems and be dynamically moved around isn't simple
to accomplish.

Babar> So far I can only identify two products one hardware Acopia and
Babar> the other one is software approach CommVault. Both have it
Babar> pros and cons but the biggest challenges for both products are
Babar> not able to manage snapshot and do not go down to qtree level.

We've used both. Acopia is a *neat* idea, but the problem with it is
backups.

You don't want to backup through the acopia, since it's a big
bottleneck, so you backup the Filers directly. But then you need to
manage and track *where* your files really are stored, and that
becomes a nightmare to deal with.

We also ran into some problems with Acopia's and filesystems with
large numbers of files (on the order of 10+ million) but those bugs
were fixed relatively quickly, and we haven't had major problems since
then.

The other issue is .snapshot/ dirs, since those are just so convenient
for user's to use and access to do their own restores. We ended up
exporting snapshots to another mount path user's could access and
giving them direction on how to access snapshots via the alternative
path. Not very ideal, and yet another thing to manually manage.

We've now also migrated to CommVault as our backup software, partly
because Legato was expensive to bring current, esp with NDMP
licensing, etc. We also have been intrigued by the integrated HSM
features of CommVault as well.

Note, that CV requires you have CIFS licenses, and a dedicated Windows
box (MediaAgent) which handles all the scanning of the
filesystem(s) for file(s) to migrate from one tier to another. So if
you're an NFS shop, you'll find that you now need CIFS licenses as
well from Netapp, which can be a hidden gotcha if you're not careful.

In our preliminary testing, the HSM aspect has worked pretty well. We
can stage files to disk/tape, they get recalled automatically and life
is good. We can even do a backup of the stub file, move it to another
filer/volume, and have access just work. We're still in the initial
deployment phase, but we're planning on rolling this out to all our
sites.

This is all using CV 7.0, they now have 8.0 out and we might upgrade
to that before we roll out HSM. But it can be tricky.

For us, the integration of HSM and backups is the *key* thing. Having
a single mountpoint for user data, which doens't change isn't as
important in the grand scheme of things. So the Acopia handles the
transparent migration of data between backend storage nicely, but
impacts backups and .snapshot access. Using CV, we get integrated
backups and HSM and regular .snapshots, but not transparent shuffling
of data.

To me, the big issue I want to see addressed is the size of NetApp
Aggregates. 16Tb aggregates are *stupid* esp since they have Raid
Groups.

Some way to span aggregates with volumes, or move volumes live between
aggregates would be a godsend, but just bumping the size to 32Tb would
be a win too.

Hope this helps.
John
John Stoffel - Senior Staff Systems Administrator - System LSI Group
Toshiba America Electronic Components, Inc. - http://www.toshiba.com/taec
john.stoffel [at] taec - 508-486-1087


james_ at catbus

Jun 2, 2009, 10:22 AM

Post #3 of 20 (6534 views)
Permalink
Re: HSM/ILM for Netapp [In reply to]

>
>
> To me, the big issue I want to see addressed is the size of NetApp
> Aggregates. 16Tb aggregates are *stupid* esp since they have Raid
> Groups.


This is a serious issue for us, one group in particular will not
consider any file system less than 50Tb.


dleeds at edmunds

Jun 2, 2009, 10:33 AM

Post #4 of 20 (6535 views)
Permalink
RE: HSM/ILM for Netapp [In reply to]

agreed. the 16TB aggregate limits severely limit us as well. for several large image and video workloads we have to create multiple aggregates
and shares which is silly.

--
Daniel Leeds
Manager, Storage Operations
Edmunds.com
310.309.4999
dleeds [at] edmunds
________________________________________
From: owner-toasters [at] mathworks [owner-toasters [at] mathworks] On Behalf Of James Beal [james_ [at] catbus]
Sent: Tuesday, June 02, 2009 10:22 AM
To: toasters [at] mathworks
Subject: Re: HSM/ILM for Netapp

>
>
> To me, the big issue I want to see addressed is the size of NetApp
> Aggregates. 16Tb aggregates are *stupid* esp since they have Raid
> Groups.


This is a serious issue for us, one group in particular will not
consider any file system less than 50Tb.


jeremy.page at gilbarco

Jun 2, 2009, 10:34 AM

Post #5 of 20 (6538 views)
Permalink
RE: HSM/ILM for Netapp [In reply to]

I thought they where planning to move to 100TB volumes in the very near
future (7.4?)


-----Original Message-----
From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
On Behalf Of James Beal
Sent: Tuesday, June 02, 2009 1:22 PM
To: toasters [at] mathworks
Subject: Re: HSM/ILM for Netapp


>
>
> To me, the big issue I want to see addressed is the size of NetApp
> Aggregates. 16Tb aggregates are *stupid* esp since they have Raid
> Groups.


This is a serious issue for us, one group in particular will not
consider any file system less than 50Tb.



Please be advised that this email may contain confidential information.
If you are not the intended recipient, please do not read, copy or
re-transmit this email. If you have received this email in error,
please notify us by email by replying to the sender and by telephone
(call us collect at +1 202-828-0850) and delete this message and any
attachments. Thank you in advance for your cooperation and assistance.

In addition, Danaher and its subsidiaries disclaim that the content of
this email constitutes an offer to enter into, or the acceptance of,
any
contract or agreement or any amendment thereto; provided that the
foregoing disclaimer does not invalidate the binding effect of any
digital or other electronic reproduction of a manual signature that is
included in any attachment to this email.


john.stoffel at taec

Jun 2, 2009, 10:57 AM

Post #6 of 20 (6529 views)
Permalink
Re: HSM/ILM for Netapp [In reply to]

John> You don't want to backup through the acopia, since it's a big
John> bottleneck, so you backup the Filers directly. But then you need to
John> manage and track *where* your files really are stored, and that
John> becomes a nightmare to deal with.

Kyle> The latest version of the F5/Acopia software (v5.0.0) introduces
Kyle> a feature called File Tracking to specifically address this
Kyle> issue.

This doesn't help when you do NDMP backups, does it? Also, do you
*ever* trust version X.0 software? *grin* I'm not moving to
CommVault 8.x or OnTap 7.3.x until they're more stable and widely
tested. I need stability at work.

John


silkey at ece

Jun 2, 2009, 12:51 PM

Post #7 of 20 (6525 views)
Permalink
Re: HSM/ILM for Netapp [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/2/09 1:34 PM, Page, Jeremy wrote:
> I thought they where planning to move to 100TB volumes in the very near
> future (7.4?)

DOT 8.0 is supposedly bringing WAFL improvements to allow for 100TB
aggrs/vols (rumored to be dropping this summer).

I also hear jumping any 7.x variant to 8.0 will be a disruptive upgrade.

Cheers.

- --
Nick Silkey


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkolgtEACgkQrDQjhjXrMeK+cACgqJtAvcin5cpurMh1sNyIjJMF
Zh4AoI8kZw+DWA4Xvo5YrG0VgGN4orMH
=ERgH
-----END PGP SIGNATURE-----


Roger.Weeks at netapp

Jun 3, 2009, 11:49 AM

Post #8 of 20 (6484 views)
Permalink
Re: HSM/ILM for Netapp [In reply to]

This is not the case. Upgrades to Data ONTAP 8.0 can be performed
non-disruptively
from 7.3 releases. If you have not yet upgraded to a 7.3 release you will
need to
follow the guidelines to non-disruptively upgrade to the latest 7.3 release
before
upgrading to 8.0.


Roger Weeks
Technical Marketing Engineer
MultiStore € Security € HA

NetApp
408.822.6365 Direct
rweeks [at] netapp
www.netapp.com




> -----Original Message-----
> From: Nick Silkey [mailto:silkey [at] ece]
> Sent: Tuesday, 02 June, 2009 12:52
> To: Page, Jeremy
> Cc: James Beal; toasters [at] mathworks
> Subject: Re: HSM/ILM for Netapp
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 6/2/09 1:34 PM, Page, Jeremy wrote:
>> I thought they where planning to move to 100TB volumes in the very
> near
>> future (7.4?)
>
> DOT 8.0 is supposedly bringing WAFL improvements to allow for 100TB
> aggrs/vols (rumored to be dropping this summer).
>
> I also hear jumping any 7.x variant to 8.0 will be a disruptive upgrade.
>
> Cheers.
>
> - --
> Nick Silkey
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iEYEARECAAYFAkolgtEACgkQrDQjhjXrMeK+cACgqJtAvcin5cpurMh1sNyIjJMF
> Zh4AoI8kZw+DWA4Xvo5YrG0VgGN4orMH
> =ERgH
> -----END PGP SIGNATURE-----


bkitchen at DATALINK

Jun 3, 2009, 2:03 PM

Post #9 of 20 (6477 views)
Permalink
RE: HSM/ILM for Netapp [In reply to]

To be clear, a 7.3 upgrade to DOT 8 "7mode" will be non-disruptive. Moving to "cluster mode" would be disruptive. Correct?


________________________________
From: owner-toasters [at] mathworks [owner-toasters [at] mathworks] On Behalf Of Weeks, Roger [Roger.Weeks [at] netapp]
Sent: Wednesday, June 03, 2009 2:49 PM
To: silkey [at] ece
Cc: toasters [at] mathworks
Subject: Re: HSM/ILM for Netapp

This is not the case. Upgrades to Data ONTAP 8.0 can be performed non-disruptively
from 7.3 releases. If you have not yet upgraded to a 7.3 release you will need to
follow the guidelines to non-disruptively upgrade to the latest 7.3 release before
upgrading to 8.0.


Roger Weeks
Technical Marketing Engineer
MultiStore • Security • HA

NetApp
408.822.6365 Direct
rweeks [at] netapp<UrlBlockedError.aspx>
www.netapp.com




> -----Original Message-----
> From: Nick Silkey [mailto:silkey [at] ece]
> Sent: Tuesday, 02 June, 2009 12:52
> To: Page, Jeremy
> Cc: James Beal; toasters [at] mathworks<UrlBlockedError.aspx>
> Subject: Re: HSM/ILM for Netapp
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 6/2/09 1:34 PM, Page, Jeremy wrote:
>> I thought they where planning to move to 100TB volumes in the very
> near
>> future (7.4?)
>
> DOT 8.0 is supposedly bringing WAFL improvements to allow for 100TB
> aggrs/vols (rumored to be dropping this summer).
>
> I also hear jumping any 7.x variant to 8.0 will be a disruptive upgrade.
>
> Cheers.
>
> - --
> Nick Silkey
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iEYEARECAAYFAkolgtEACgkQrDQjhjXrMeK+cACgqJtAvcin5cpurMh1sNyIjJMF
> Zh4AoI8kZw+DWA4Xvo5YrG0VgGN4orMH
> =ERgH
> -----END PGP SIGNATURE-----


bkitchen at datalink

Jun 3, 2009, 2:03 PM

Post #10 of 20 (6479 views)
Permalink
RE: HSM/ILM for Netapp [In reply to]

To be clear, a 7.3 upgrade to DOT 8 "7mode" will be non-disruptive. Moving to "cluster mode" would be disruptive. Correct?


________________________________
From: owner-toasters [at] mathworks [owner-toasters [at] mathworks] On Behalf Of Weeks, Roger [Roger.Weeks [at] netapp]
Sent: Wednesday, June 03, 2009 2:49 PM
To: silkey [at] ece
Cc: toasters [at] mathworks
Subject: Re: HSM/ILM for Netapp

This is not the case. Upgrades to Data ONTAP 8.0 can be performed non-disruptively
from 7.3 releases. If you have not yet upgraded to a 7.3 release you will need to
follow the guidelines to non-disruptively upgrade to the latest 7.3 release before
upgrading to 8.0.


Roger Weeks
Technical Marketing Engineer
MultiStore • Security • HA

NetApp
408.822.6365 Direct
rweeks [at] netapp<UrlBlockedError.aspx>
www.netapp.com




> -----Original Message-----
> From: Nick Silkey [mailto:silkey [at] ece]
> Sent: Tuesday, 02 June, 2009 12:52
> To: Page, Jeremy
> Cc: James Beal; toasters [at] mathworks<UrlBlockedError.aspx>
> Subject: Re: HSM/ILM for Netapp
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 6/2/09 1:34 PM, Page, Jeremy wrote:
>> I thought they where planning to move to 100TB volumes in the very
> near
>> future (7.4?)
>
> DOT 8.0 is supposedly bringing WAFL improvements to allow for 100TB
> aggrs/vols (rumored to be dropping this summer).
>
> I also hear jumping any 7.x variant to 8.0 will be a disruptive upgrade.
>
> Cheers.
>
> - --
> Nick Silkey
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iEYEARECAAYFAkolgtEACgkQrDQjhjXrMeK+cACgqJtAvcin5cpurMh1sNyIjJMF
> Zh4AoI8kZw+DWA4Xvo5YrG0VgGN4orMH
> =ERgH
> -----END PGP SIGNATURE-----


Darren.Sykes at csr

Jun 4, 2009, 1:27 AM

Post #11 of 20 (6470 views)
Permalink
RE: HSM/ILM for Netapp [In reply to]

I'd imagine the few minutes disruption won't be the primary concern for
most people, it'll be the change in feature set when in cluster mode.



i.e. effectively turning off iSCSI, FC, ASIS etc will have a bigger
impact for most customers than a scheduled outage for an upgrade.





From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
On Behalf Of Brandon Kitchen
Sent: 03 June 2009 22:04
To: Weeks, Roger; silkey [at] ece
Cc: toasters [at] mathworks
Subject: RE: HSM/ILM for Netapp



To be clear, a 7.3 upgrade to DOT 8 "7mode" will be non-disruptive.
Moving to "cluster mode" would be disruptive. Correct?





________________________________

From: owner-toasters [at] mathworks [owner-toasters [at] mathworks] On
Behalf Of Weeks, Roger [Roger.Weeks [at] netapp]
Sent: Wednesday, June 03, 2009 2:49 PM
To: silkey [at] ece
Cc: toasters [at] mathworks
Subject: Re: HSM/ILM for Netapp

This is not the case. Upgrades to Data ONTAP 8.0 can be performed
non-disruptively
from 7.3 releases. If you have not yet upgraded to a 7.3 release you
will need to
follow the guidelines to non-disruptively upgrade to the latest 7.3
release before
upgrading to 8.0.


Roger Weeks
Technical Marketing Engineer
MultiStore * Security * HA

NetApp
408.822.6365 Direct
rweeks [at] netapp
www.netapp.com




> -----Original Message-----
> From: Nick Silkey [mailto:silkey [at] ece]
> Sent: Tuesday, 02 June, 2009 12:52
> To: Page, Jeremy
> Cc: James Beal; toasters [at] mathworks
> Subject: Re: HSM/ILM for Netapp
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 6/2/09 1:34 PM, Page, Jeremy wrote:
>> I thought they where planning to move to 100TB volumes in the very
> near
>> future (7.4?)
>
> DOT 8.0 is supposedly bringing WAFL improvements to allow for 100TB
> aggrs/vols (rumored to be dropping this summer).
>
> I also hear jumping any 7.x variant to 8.0 will be a disruptive
upgrade.
>
> Cheers.
>
> - --
> Nick Silkey
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
>
> iEYEARECAAYFAkolgtEACgkQrDQjhjXrMeK+cACgqJtAvcin5cpurMh1sNyIjJMF
> Zh4AoI8kZw+DWA4Xvo5YrG0VgGN4orMH
> =ERgH
> -----END PGP SIGNATURE-----





To report this email as spam click here
<https://www.mailcontrol.com/sr/LPhst0ldsTHTndxI!oX7UuoY1VmXKYhKv6XT+DSX
oqlLOoBnao7GzCidawF3of5z2LQLjnD75HLw2vPhlBpHvw==> .


john.stoffel at taec

Jun 4, 2009, 5:48 AM

Post #12 of 20 (6468 views)
Permalink
RE: HSM/ILM for Netapp [In reply to]

Glenn> Honestly, moving volumes between aggregates (and controllers)
Glenn> is the only thing I'm really looking forward to out of ONTAP 8.
Glenn> If all blocks are just virtual pointers now, it makes no sense
Glenn> that we cannot move volumes between aggregates and it is a huge
Glenn> issue for us today.

Hmm... will you be able to move volumes live? I assume you'll need to
have the free space in the destination aggr to hold the entire vol
you're moving, but that should be ok then.

Just keeping the data live and in production during such moves would
be a huge help.

Glenn> If they bump the limit beyond 32TB, I care less - most of our
Glenn> volumes we keep rather small to assist with backup limitations
Glenn> and/or reduction of single points of failure.

Sure, I agree too. I might even start to use more volumes then,
instead of qtrees within volumes.

John


Darren.Sykes at csr

Jun 4, 2009, 7:11 AM

Post #13 of 20 (6464 views)
Permalink
RE: HSM/ILM for Netapp [In reply to]

Yep, moving volumes on the fly is something we really appreciate with GX
(and will do with 8 in cluster mode).

It's pretty transparent from a client point of view (literally < 1
second access delay).

The only headache is NDMP backups of those volumes as they obviously
need to be updated to reflect the new location.


-----Original Message-----
From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
On Behalf Of John Stoffel
Sent: 04 June 2009 13:49
To: Glenn Walker
Cc: 'John Stoffel'; 'Babar Haq'; toasters [at] mathworks
Subject: RE: HSM/ILM for Netapp


Glenn> Honestly, moving volumes between aggregates (and controllers)
Glenn> is the only thing I'm really looking forward to out of ONTAP 8.
Glenn> If all blocks are just virtual pointers now, it makes no sense
Glenn> that we cannot move volumes between aggregates and it is a huge
Glenn> issue for us today.

Hmm... will you be able to move volumes live? I assume you'll need to
have the free space in the destination aggr to hold the entire vol
you're moving, but that should be ok then.

Just keeping the data live and in production during such moves would
be a huge help.

Glenn> If they bump the limit beyond 32TB, I care less - most of our
Glenn> volumes we keep rather small to assist with backup limitations
Glenn> and/or reduction of single points of failure.

Sure, I agree too. I might even start to use more volumes then,
instead of qtrees within volumes.

John


To report this email as spam click
https://www.mailcontrol.com/sr/jSDIDM8coDjTndxI!oX7UpnwNuh!OyUz+!uKA1W!K
fE59hIYsjQ7IyAocAv5M+cU2LQLjnD75HJhjvXYAQ53ow== .


knight at atmos

Jun 4, 2009, 7:37 AM

Post #14 of 20 (6475 views)
Permalink
Re: HSM/ILM for Netapp [In reply to]

I'd love to be able move volumes quickly and transparently
between aggregates, and clustered heads.
Is this really a possibility? I have a couple
of things I'd like to move around . . .
David

> Yep, moving volumes on the fly is something we really appreciate with GX
> (and will do with 8 in cluster mode).
>
> It's pretty transparent from a client point of view (literally < 1
> second access delay).
>
> The only headache is NDMP backups of those volumes as they obviously
> need to be updated to reflect the new location.
>
>
> -----Original Message-----
> From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
> On Behalf Of John Stoffel
> Sent: 04 June 2009 13:49
> To: Glenn Walker
> Cc: 'John Stoffel'; 'Babar Haq'; toasters [at] mathworks
> Subject: RE: HSM/ILM for Netapp
>
>
> Glenn> Honestly, moving volumes between aggregates (and controllers)
> Glenn> is the only thing I'm really looking forward to out of ONTAP 8.
> Glenn> If all blocks are just virtual pointers now, it makes no sense
> Glenn> that we cannot move volumes between aggregates and it is a huge
> Glenn> issue for us today.
>
> Hmm... will you be able to move volumes live? I assume you'll need to
> have the free space in the destination aggr to hold the entire vol
> you're moving, but that should be ok then.
>
> Just keeping the data live and in production during such moves would
> be a huge help.
>
> Glenn> If they bump the limit beyond 32TB, I care less - most of our
> Glenn> volumes we keep rather small to assist with backup limitations
> Glenn> and/or reduction of single points of failure.
>
> Sure, I agree too. I might even start to use more volumes then,
> instead of qtrees within volumes.
>
> John
>
>
> To report this email as spam click
> https://www.mailcontrol.com/sr/jSDIDM8coDjTndxI!oX7UpnwNuh!OyUz+!uKA1W!K
> fE59hIYsjQ7IyAocAv5M+cU2LQLjnD75HJhjvXYAQ53ow== .
>


Darren.Sykes at csr

Jun 4, 2009, 7:48 AM

Post #15 of 20 (6483 views)
Permalink
RE: HSM/ILM for Netapp [In reply to]

It is... if you're using the right operating system (and unfortunately
you're probably not).

However, future 'mainstream' Netapp OS support is in the pipeline. I'm
probably not helping here, but we can move volumes between heads, sites
and disk types transparently with OnTAP GX today.




-----Original Message-----
From: David Knight [mailto:knight [at] atmos]
Sent: 04 June 2009 15:37
To: Darren Sykes
Cc: john.stoffel [at] taec; gwalker [at] aetas;
babarhaq [at] email; toasters [at] mathworks
Subject: Re: HSM/ILM for Netapp

I'd love to be able move volumes quickly and transparently
between aggregates, and clustered heads.
Is this really a possibility? I have a couple
of things I'd like to move around . . .
David

> Yep, moving volumes on the fly is something we really appreciate with
GX
> (and will do with 8 in cluster mode).
>
> It's pretty transparent from a client point of view (literally < 1
> second access delay).
>
> The only headache is NDMP backups of those volumes as they obviously
> need to be updated to reflect the new location.
>
>
> -----Original Message-----
> From: owner-toasters [at] mathworks
[mailto:owner-toasters [at] mathworks]
> On Behalf Of John Stoffel
> Sent: 04 June 2009 13:49
> To: Glenn Walker
> Cc: 'John Stoffel'; 'Babar Haq'; toasters [at] mathworks
> Subject: RE: HSM/ILM for Netapp
>
>
> Glenn> Honestly, moving volumes between aggregates (and controllers)
> Glenn> is the only thing I'm really looking forward to out of ONTAP 8.
> Glenn> If all blocks are just virtual pointers now, it makes no sense
> Glenn> that we cannot move volumes between aggregates and it is a huge
> Glenn> issue for us today.
>
> Hmm... will you be able to move volumes live? I assume you'll need to
> have the free space in the destination aggr to hold the entire vol
> you're moving, but that should be ok then.
>
> Just keeping the data live and in production during such moves would
> be a huge help.
>
> Glenn> If they bump the limit beyond 32TB, I care less - most of our
> Glenn> volumes we keep rather small to assist with backup limitations
> Glenn> and/or reduction of single points of failure.
>
> Sure, I agree too. I might even start to use more volumes then,
> instead of qtrees within volumes.
>
> John
>
>
> To report this email as spam click
>
https://www.mailcontrol.com/sr/jSDIDM8coDjTndxI!oX7UpnwNuh!OyUz+!uKA1W!K
> fE59hIYsjQ7IyAocAv5M+cU2LQLjnD75HJhjvXYAQ53ow== .
>


knight at atmos

Jun 4, 2009, 8:30 AM

Post #16 of 20 (6463 views)
Permalink
Re: HSM/ILM for Netapp [In reply to]

I know we can't do this under 7.2.3
Is GX an extra cost, or something I can look forward
to as an no cost upgrade to our existing supported
cluster. I can barely afford to keep our 3020
cluster under support right now. I suppose I could
contact netapps sales support, but right now
I have no money, and would hate to waste their
time and mine. No need to reply - I'm curious,
but I'll contact netapp if it becomes a critical
need.

I'm so tired of this do more for less, on the surface
it seems like a good idea, but is just not sustainable.

David

> It is... if you're using the right operating system (and unfortunately
> you're probably not).
>
> However, future 'mainstream' Netapp OS support is in the pipeline. I'm
> probably not helping here, but we can move volumes between heads, sites
> and disk types transparently with OnTAP GX today.
>
>
>
>
> -----Original Message-----
> From: David Knight [mailto:knight [at] atmos]
> Sent: 04 June 2009 15:37
> To: Darren Sykes
> Cc: john.stoffel [at] taec; gwalker [at] aetas;
> babarhaq [at] email; toasters [at] mathworks
> Subject: Re: HSM/ILM for Netapp
>
> I'd love to be able move volumes quickly and transparently
> between aggregates, and clustered heads.
> Is this really a possibility? I have a couple
> of things I'd like to move around . . .
> David
>
> > Yep, moving volumes on the fly is something we really appreciate with
> GX
> > (and will do with 8 in cluster mode).
> >
> > It's pretty transparent from a client point of view (literally < 1
> > second access delay).
> >
> > The only headache is NDMP backups of those volumes as they obviously
> > need to be updated to reflect the new location.
> >
> >
> > -----Original Message-----
> > From: owner-toasters [at] mathworks
> [mailto:owner-toasters [at] mathworks]
> > On Behalf Of John Stoffel
> > Sent: 04 June 2009 13:49
> > To: Glenn Walker
> > Cc: 'John Stoffel'; 'Babar Haq'; toasters [at] mathworks
> > Subject: RE: HSM/ILM for Netapp
> >
> >
> > Glenn> Honestly, moving volumes between aggregates (and controllers)
> > Glenn> is the only thing I'm really looking forward to out of ONTAP 8.
> > Glenn> If all blocks are just virtual pointers now, it makes no sense
> > Glenn> that we cannot move volumes between aggregates and it is a huge
> > Glenn> issue for us today.
> >
> > Hmm... will you be able to move volumes live? I assume you'll need to
> > have the free space in the destination aggr to hold the entire vol
> > you're moving, but that should be ok then.
> >
> > Just keeping the data live and in production during such moves would
> > be a huge help.
> >
> > Glenn> If they bump the limit beyond 32TB, I care less - most of our
> > Glenn> volumes we keep rather small to assist with backup limitations
> > Glenn> and/or reduction of single points of failure.
> >
> > Sure, I agree too. I might even start to use more volumes then,
> > instead of qtrees within volumes.
> >
> > John
> >
> >
> > To report this email as spam click
> >
> https://www.mailcontrol.com/sr/jSDIDM8coDjTndxI!oX7UpnwNuh!OyUz+!uKA1W!K
> > fE59hIYsjQ7IyAocAv5M+cU2LQLjnD75HJhjvXYAQ53ow== .
> >
>
>


babarhaq at email

Jun 6, 2009, 10:51 PM

Post #17 of 20 (6398 views)
Permalink
RE: HSM/ILM for Netapp [In reply to]

>
> The F5 ARX (Acopia) does support managing NetApp Snapshots.

What the customers means from snapshot support is that once a file moves to other storage it also clears the blocks which are being held by previous snapshots for that specific file. Is that what Acopia does?

Appreciate your response.

Regards,
Babar Haq

--
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com


Stefan.Funke at netapp

Jun 8, 2009, 12:41 AM

Post #18 of 20 (6366 views)
Permalink
RE: HSM/ILM for Netapp [In reply to]

In a typical setup you will configure the ARX to ignore .snapshot
directories. F5 doesn't know anything about NetApp snapshots nor does it
manage any NetApp functionality like snapshots.


Stefan Funke
Systems Engineer
NetApp Deutschland GmbH



-----Original Message-----
From: Babar Haq [mailto:babarhaq [at] email]
Sent: 07 June 2009 07:52
To: Bob Blair; 'toasters [at] mathworks'
Subject: RE: HSM/ILM for Netapp



>
> The F5 ARX (Acopia) does support managing NetApp Snapshots.

What the customers means from snapshot support is that once a file moves
to other storage it also clears the blocks which are being held by
previous snapshots for that specific file. Is that what Acopia does?

Appreciate your response.

Regards,
Babar Haq

--
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com


Stefan.Funke at netapp

Jun 8, 2009, 1:05 AM

Post #19 of 20 (6387 views)
Permalink
RE: HSM/ILM for Netapp [In reply to]

Excuse me. Maybe that has changed since the last time I worked with a
ARX box.


-----Original Message-----
From: Kirby Wadsworth [mailto:kirbyw [at] F5]
Sent: 08 June 2009 09:53
To: Funke, Stefan; Babar Haq; Bob Blair; toasters [at] mathworks
Subject: RE: HSM/ILM for Netapp

Patently incorrect, Stefan.

ARX coordinates snapshots from multiple vendors including NTAP and
creates a virtual snapshot across different arrays - a function that no
other technology can provide.



-----Original Message-----
From: owner-toasters [at] mathworks [mailto:owner-toasters [at] mathworks]
On Behalf Of Funke, Stefan
Sent: Monday, June 08, 2009 3:42 AM
To: Babar Haq; Bob Blair; toasters [at] mathworks
Subject: RE: HSM/ILM for Netapp

In a typical setup you will configure the ARX to ignore .snapshot
directories. F5 doesn't know anything about NetApp snapshots nor does it
manage any NetApp functionality like snapshots.


Stefan Funke
Systems Engineer
NetApp Deutschland GmbH



-----Original Message-----
From: Babar Haq [mailto:babarhaq [at] email]
Sent: 07 June 2009 07:52
To: Bob Blair; 'toasters [at] mathworks'
Subject: RE: HSM/ILM for Netapp



>
> The F5 ARX (Acopia) does support managing NetApp Snapshots.

What the customers means from snapshot support is that once a file moves
to other storage it also clears the blocks which are being held by
previous snapshots for that specific file. Is that what Acopia does?

Appreciate your response.

Regards,
Babar Haq

--
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com


john.stoffel at taec

Jun 8, 2009, 6:30 AM

Post #20 of 20 (6374 views)
Permalink
RE: HSM/ILM for Netapp [In reply to]

>> The F5 ARX (Acopia) does support managing NetApp Snapshots.

Babar> What the customers means from snapshot support is that once a
Babar> file moves to other storage it also clears the blocks which are
Babar> being held by previous snapshots for that specific file. Is
Babar> that what Acopia does?

I don't see how the Acopia can do that without having to nuke the
entire snapshot, as well as having full control over the blocks on the
Netapp.

Now maybe the Acopia can intercept and translate where files are and
make it look transparent, but I'd be hesitent to trust it.

And still, the biggest issue is backups, esp NDMP backups of your
data, and then doing restores properly.

John

Netapp toasters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.