Hi,
we just received a new 3140 cluster here to upgrade an existing 3020c production filer. And now we're looking for a way to migrate the existing data (~18TB) with the least possible downtime.
Ideally, we would use SnapMirror to copy the data on the new filer and then transparently (for clients) switch the production system, similarly to what happens when a cluster member fails over to the other member. But we don't know if this is possible.
So the questions are: - do you think such a procedure could be successful ? - do you have any other ideas to migrate the data without service interruption ?
Cheers, Simon
Hi Simon,
On Mon, Jul 28, 2008 at 12:08 PM, Simon Vallet svallet@genoscope.cns.fr wrote:
Hi,
we just received a new 3140 cluster here to upgrade an existing 3020c production filer. And now we're looking for a way to migrate the existing data (~18TB) with the least possible downtime.
Ideally, we would use SnapMirror to copy the data on the new filer and then transparently (for clients) switch the production system, similarly to what happens when a cluster member fails over to the other member. But we don't know if this is possible.
So the questions are:
- do you think such a procedure could be successful ?
- do you have any other ideas to migrate the data without service
interruption ?
I've done this a dozen times, and it's succesfull, however not entirely without downtime. When switching over, you will need to do a last mirror update to catch the last changes with CIFS disabled on the source filer, this usually means a few seconds per volume of downtime and a few hickups when reconfiguring the paths to CIFS shares. If you want me to, I could write you down the basic steps you take to be sure that you will not lose any client data.
Without any interruption, we usually use HSM-like configurations such as Acopia (now F5) and the likes have.
HTH & HAND,
Hi Nils, i am in a similar position, could you list the steps if its not too much work?
Thanks a lot
Cris
--- On Mon, 7/28/08, Nils Vogels bacardicoke@gmail.com wrote:
From: Nils Vogels bacardicoke@gmail.com Subject: Re: Migrating data without service interruption : 3020 -> 3140 To: "Simon Vallet" svallet@genoscope.cns.fr Cc: toasters@mathworks.com Date: Monday, July 28, 2008, 12:00 PM Hi Simon,
On Mon, Jul 28, 2008 at 12:08 PM, Simon Vallet svallet@genoscope.cns.fr wrote:
Hi,
we just received a new 3140 cluster here to upgrade an
existing 3020c
production filer. And now we're looking for a way
to migrate the
existing data (~18TB) with the least possible
downtime.
Ideally, we would use SnapMirror to copy the data on
the new filer and
then transparently (for clients) switch the production
system,
similarly to what happens when a cluster member fails
over to the other
member. But we don't know if this is possible.
So the questions are:
- do you think such a procedure could be successful ?
- do you have any other ideas to migrate the data
without service
interruption ?
I've done this a dozen times, and it's succesfull, however not entirely without downtime. When switching over, you will need to do a last mirror update to catch the last changes with CIFS disabled on the source filer, this usually means a few seconds per volume of downtime and a few hickups when reconfiguring the paths to CIFS shares. If you want me to, I could write you down the basic steps you take to be sure that you will not lose any client data.
Without any interruption, we usually use HSM-like configurations such as Acopia (now F5) and the likes have.
HTH & HAND,
-- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you.
On Mon, 28 Jul 2008 13:00:19 +0200 "Nils Vogels" bacardicoke@gmail.com wrote:
On Mon, Jul 28, 2008 at 12:08 PM, Simon Vallet svallet@genoscope.cns.fr wrote:
Ideally, we would use SnapMirror to copy the data on the new filer and then transparently (for clients) switch the production system, similarly to what happens when a cluster member fails over to the other member. But we don't know if this is possible.
So the questions are:
- do you think such a procedure could be successful ?
- do you have any other ideas to migrate the data without service
interruption ?
I've done this a dozen times, and it's succesfull, however not entirely without downtime. When switching over, you will need to do a last mirror update to catch the last changes with CIFS disabled on the source filer, this usually means a few seconds per volume of downtime and a few hickups when reconfiguring the paths to CIFS shares.
CIFS is not really critical here, so that wouldn't be much of a problem. As for NFS, could you be a bit more specific about the way clients are migrated ?
If you want me to, I could write you down the basic steps you take to be sure that you will not lose any client data.
I'd very much like that :-)
Just for the sake of the discussion, another poster suggested off-list to simply replace the heads one by one, which seems a quite appropriate solution -- but as the new system is already racked and cabled, it would probably involve too much moving around and re-cabling, which I'm not very keen about.
Without any interruption, we usually use HSM-like configurations such as Acopia (now F5) and the likes have.
We don't really have the need for such an high-availability setup here, but those look quite nice to me.
Thanks to all of you once again -- this list rocks :-)
Simon
For NFS SnapMirror offers volume migration; it still takes time to perform the last sync, so it is obviously not fully transparent; but as long as your clients can wait for it, it is as good as you can get.
For CIFS you could migrate data, configure the same name/IP for new filer and start services. It will never be fully transparent (nor is normal cluster failover for CIFS).
For FCP/iSCSI the only way to do it (I can think of) is to use host side mirroring. Add new LUNs, mirror the old one onto new, them break mirror and remove old LUNs.
С уважением / With best regards / Mit freundlichen Grüβen
--- Andrey Borzenkov Senior system engineer
-----Original Message----- From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Simon Vallet Sent: Monday, July 28, 2008 2:08 PM To: toasters@mathworks.com Subject: Migrating data without service interruption : 3020 -> 3140
Hi,
we just received a new 3140 cluster here to upgrade an existing 3020c production filer. And now we're looking for a way to migrate the existing data (~18TB) with the least possible downtime.
Ideally, we would use SnapMirror to copy the data on the new filer and then transparently (for clients) switch the production system, similarly to what happens when a cluster member fails over to the other member. But we don't know if this is possible.
So the questions are: - do you think such a procedure could be successful ? - do you have any other ideas to migrate the data without service interruption ?
Cheers, Simon
--
Simon Vallet Ingénieur Système/Réseaux CEA DSV/IG/GEN - Genoscope Tél : +33 1 60 87 36 06 Mél. : svallet@genoscope.cns.f
without something like GX or an acopia switch you cannot achieve full transparency. it should be pretty quick with snapmirror though unless you are migrating 300+ volumes.
you could always pull the fire alarm right before the cutover and quickly do the final sync and cutover while everyone is evacuating the office...
:)
-- 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@mathworks.com on behalf of Simon Vallet Sent: Mon 7/28/2008 3:08 AM To: toasters@mathworks.com Subject: Migrating data without service interruption : 3020 -> 3140
Hi,
we just received a new 3140 cluster here to upgrade an existing 3020c production filer. And now we're looking for a way to migrate the existing data (~18TB) with the least possible downtime.
Ideally, we would use SnapMirror to copy the data on the new filer and then transparently (for clients) switch the production system, similarly to what happens when a cluster member fails over to the other member. But we don't know if this is possible.
So the questions are: - do you think such a procedure could be successful ? - do you have any other ideas to migrate the data without service interruption ?
Cheers, Simon
-
Borzenkov, Andrey -
Cristian Rojas -
Leeds, Daniel -
Nils Vogels -
Simon Vallet