Curtis,
always interesting to have a conversation with you around BUR.
I'm very well aware of why global de-dupe is important, after all I've been
doing BUR for about 25 years now, I have a fair idea on how it works. However,
I'm sure that your link will be useful to someone newly research the subject.
:-)
Thanks for the link on the 3D4000, I'll have a look as it may be pertinant.
However, getting to the point of the thread, that being the use of an ESN or
not:
The in and out ports are exactly that. Therefore, with the flex ports, you have
a maximum of 8 "in" ports, which are systems connected to the library. i.e., my
understanding is that if you do not us ethe "out'ports you have 4 wasted ports.
I see you took me literally, so I'll make sure you understand that I would also
connect up to a switch... not connect the system directly to the ports. My
point was, that this gives you a maximum amount of bandwidth. The 1600MB per
sec was quoted from EMC. You suggest we check those figures, I agree. However
our testing groups got 1200 MB per sec written to older CDL models, so I
wouldn't be too surprised at 1600MB per sec in on the newer models.
Yes, I am aware that the real tapes will be connected to the SN and not the EDL
if you use an SN to do the cloning, obviously via a switch.
So the data paths are:
SN
Disk on the EDL, FC, Backplane, CPU on EDL, Back plane, FC, backplane, CPU on
SN, backplane, FC, Physical tape drive
ESN
Disk on the EDL, FC, Backplane, CPU on the EDL, Back plane, FC, Physical tape
drive.
Less hops, less CPU's involved for the ESN.
No matter what you do, when cloning. You will use CPU in the EDL. You will use
more if you use the ESN. However, if you use a standard SN, you will use some
of the FC bandwidth that would normally be used for writting to the VTL.
However, as stated, I would not do cloning during heavy Backup times, and my
issue is that we use Dedicated Storage Nodes which, in our case, are production
systems. Therefore, we do not want to load those systems, or the backup server,
with cloning activity.... thus the interest in the ESN.
However, in the end, we are both theorizing. I'm actually not entirely
convinced, except for off-loading load that would be put on production servers
that are DSNs. You statement, though, seems to come from the point of view that
you are right, because you think so, and you have to be proven wrong.
meanwhile, I'm willing to entertain both arguments, as I see merit in both.
As you say, in the end, we need concrete testing.
Siobhán
> Date: Mon, 4 May 2009 21:30:35 -0700
> From: wcplists1 AT GMAIL DOT COM
> Subject: Re: [Networker] Clone from EDL to library
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
>
> Siobhan Ellis said:
> >I've been looking at this recently, as well as the HP VLS 9000.
>
> As I covered in a recent post, what you'll find in that box is global (i.e.
> multi-node) dedupe and the lack of deduped replication (today). They're
> expecting to go GA with deduped replication very soon. Read here, however,
> why global dedupe is important:
> http://www.backupcentral.com/content/view/231/47/
>
>
> >I'm looking at a de-dupe variant of the EDL4206, or 4406. This would have
> >the 3D4000 on the back, to do the de-dupe. It would then replicate to
> >another 4000 at a remote site, which is connected to another 4206 or 4406.
> >We'll have replication going in both directions.
>
> I posted a couple of posts on the 3D4000 a few weeks back, and you should
> read them if you're considering it.
> http://www.backupcentral.com/content/view/230/47/
> http://www.backupcentral.com/content/view/232/47/
>
> You'll note that an EMC blogger came after me for what I said, saying that
> it was all untrue. You will then note that in part two, I proved everything
> I said was true using quotes directly from the documentation.
>
> >So, Curtis, normally you'll have a couple of FC ports to your "tape"
> >devices. The most the 4206 is capable of is 1600MB per sec... that would be
> >using all 4 in and, I suggest, probably some of the flex ports.
>
> You really want to check those numbers if you're looking at the 4000. But
> anyway... If you're using a regular SN, then you wouldn't have any tapes in
> the VTL dedicated to real tape; they would be connected to the SN.
>
> >So, if you use an external SN, you'll be using some of those "in" ports.
>
> I normally run such things through a switch anyway, so this wouldn't change
> anything.
>
> >Are you suggesting that you have a separate SN with separate FC links to
> >the physical library? IF so, why wouldn't you do it, and why would you use
> >the ESN?
>
> I'm just suggesting we use regular SNs the way we always have (however you
> use them in your environment), and that moving them inside a VTL doesn't
> make anything better. If anything, it slows down things because now you're
> doing two things with one box, instead of just doing one thing.
>
> >Also the throughput from the EDL to the physical
> >tape devices is literally straight from disk, via back plane, to tape,
> >rather than disk via back plane, via fc through the back plane to fc to
> >tape.
>
> No it's not, and that's my point. It still goes up into the SN CPU. It's
> just that the CPU is inside the VTL.
>
> OK, my argument boils down to this: I think this would slow down things. If
> someone proves otherwise, I will stand corrected and bless away. But I just
> see people theorizing why it would be good and other people saying that lots
> of people are doing it. I need some tests to convert me.
>
> -----Original Message-----
> From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
> On
> Behalf Of W. Curtis Preston
> Sent: Monday, 4 May 2009 5:13 PM
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Subject: Re: [Networker] Clone from EDL to library
>
> I know it's been a month since you posted this. I missed it then. Sorry
> for the late response.
>
> So you're saying that the dedicated SN inside the EDL can do the cloning for
> a SAN Storage Node that has better things to do. I get that, but the same
> can be said of a dedicated SN NOT inside the EDL.
>
> I don't see this as anything different than THAT, other than not having to
> buy another node. It's just that the EMC bloggers talk like this is such a
> superior way of doing things. I don't see how it's superior -- just
> different. (And I see downsides that I already pointed out.)
>
> -----Original Message-----
> From: lemons_terry AT emc DOT com [mailto:lemons_terry AT emc DOT com]
> Sent: Wednesday, March 25, 2009 6:09 AM
> To: wcplists1 AT GMAIL DOT COM
> Cc: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Subject: RE: [Networker] Clone from EDL to library
>
> Hi Curtis
>
> Well, IMHO (and the opinion of the many people who use this option) the
> advantage is that the 'production' storage nodes and the production SAN
> are not burdened with cloning; this is all done internally to the EDL.
> Yes, it does put a load on the EDL engine. But SOME system has to take
> on the burden, and I'd rather have it be a dedicated backup appliance
> than, say, my database server.
>
> As to slowing things down, the EDL engine has finite resources, of
> course. So the best practice would be to schedule the cloning to occur
> during the [insert wishful thinking here] time when the EDL was not busy
> accepting new backups.
>
> Thanks for this dialogue!
> tl
>
> -----Original Message-----
> From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
> On
> Behalf Of W. Curtis Preston
> Sent: Wednesday, March 25, 2009 2:16 AM
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Subject: Re: [Networker] Clone from EDL to library
>
> Terry,
>
> I'm honestly trying to figure out how this is better. It's better in
> that
> you don't need a separate storage node, but how ELSE is it better? He's
> still got to figure out how to tell NW to do all this; the queries and
> commands are all the same.
>
> And as to it being better... Here's my thought, PLEASE tell me what I
> don't
> understand. The VTL is still bringing the data into one I/O path and
> out
> another. In addition to the load this places on the CPU, you add the
> load
> of the storage node processing. Doesn't this add additional load to the
> VTL
> and inevitably slow things down?
>
> -----Original Message-----
> From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
> On
> Behalf Of Terry Lemons
> Sent: Sunday, March 22, 2009 7:38 PM
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Subject: Re: [Networker] Clone from EDL to library
>
> Hi
>
> One option you can consider is using the EDL NetWorker embedded storage
> node option. This would be an additional purchase, but would allow the
> EDL itself to read from the VTL and clone to the physical tape library.
> This is better than reading the data back into your storage node and
> writing the data to the physical tape library - the embedded storage
> node option does all of the cloning work.
>
> tl
>
> -----Original Message-----
> From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
> On
> Behalf Of Gordon
> Sent: Saturday, March 21, 2009 1:38 AM
> To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
> Subject: [Networker] Clone from EDL to library
>
> What is the best way to do this?
>
> I have all backup pools run in a VTL and I need 2 clones on real tape
> every day, the first copy stay in the same building in a fire proof
> safe-deposit box, the second copy is transported daily to another safe
> location.
> I need to make today a clon of all yesterday savesets twice, each ones
> on a diferent clone pool. To do that I make this mminfo query, I like to
> know your opinion about this. Thanks!
>
> mminfo -q 'savetime>=yesterday 00:00:00, savetime<=23:59:59 yesterday ,
> pool=filesystemW, pool=filesystemP, pool=Default, pool=filesystemL,
> !incomplete, !suspect' -r "volume, barcode, volid, ssid, cloneid, name,
> client, copies"|awk '{print $4 "/" $5}'|tail +2>ssid.cloneid
>
>
> nsrclone -S -f ssid.cloneid -b Copy1
>
> +----------------------------------------------------------------------
> |This was sent by tuamigobender AT gmail DOT com via Backup Central.
> |Forward SPAM to abuse AT backupcentral DOT com.
> +----------------------------------------------------------------------
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and
> type "signoff networker" in the body of the email. Please write to
> networker-request AT listserv.temple DOT edu if you have any problems with
> this
> list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and
> type
> "signoff networker" in the body of the email. Please write to
> networker-request AT listserv.temple DOT edu if you have any problems with
> this
> list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and
> type "signoff networker" in the body of the email. Please write to
> networker-request AT listserv.temple DOT edu if you have any problems with
> this
> list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and
> type
> "signoff networker" in the body of the email. Please write to
> networker-request AT listserv.temple DOT edu if you have any problems with
> this
> list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>
> To sign off this list, send email to listserv AT listserv.temple DOT edu and
> type "signoff networker" in the body of the email. Please write to
> networker-request AT listserv.temple DOT edu if you have any problems with
> this list. You can access the archives at
> http://listserv.temple.edu/archives/networker.html or
> via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
_________________________________________________________________
Want to stay on top of your life online? Find out how with Windows Live!
http://windowslive.ninemsn.com.au/
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
