>>>>> "Doug" == Doug Hughes <[email protected]> writes:
Doug> On 6/16/2011 8:19 AM, John Stoffel wrote: >> Ryan> I've done a hot _add_ to a loop without downtime. A shelf Ryan> _swap_ is not as easy and unless you were REALLY fast on your Ryan> fingers would require downtime. -rd >> >> I've been hearing on the toasters mailing list that doing stuff like >> this might work for a bit, but that you'll end up with memory leaks >> and a crash sometime down the line. >> >> So push comes to shove, Netapp does NOT offer an easy way to >> expand/grow/migrate your data transparently from one set of >> disks/shelves to another. Doug> I'll point out that while NetApp makes this difficult, zfs Doug> currently makes this nearly impossible, as a point of Doug> comparison. You can use zfs send/recv to replicate an entire Doug> pool, slowly, and in stages, to a remote host and then schedule Doug> a downtime window for the last synchronization. It's tedious but Doug> works ok up to a few 10s of TB, after that it's Doug> impractical. Another way to do it might be to have a total Doug> storage virtualization layer. The problem with a storage virtualization layer is backups. Or more accurately, restores of a complete directory when it's spread across multile backends. This was the Acopia model which we tried to make work but failed. If you do backups through the DataDirector, then you screw up your data again. If you do backups through the backends, then you're going to have problems restoring your data. And all users care about is restores restores restores. When it works, it's great. Data gets shuffled around behind the frontend and life is nice. Then you have an event of some sort and need to restore. Ouch... Or if you want to use it purely for data migration needs, you have to either: a) shutdown the main NAS box, install the DataDirector (my name so as to stop blaming Acopia), then remount the client if the DataDirector doesn't have MAC spoofing. Then you can migrate the data, etc. Thne you get to pull the DataDirector out of the path between clients and the new NAS, which is also painful. John _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
