Some thoughts below..
At 11:53 AM 6/21/2001 -0500, John_Wang AT enron DOT net wrote:
>Hello Curtis
>
>That may be irrelevant, if the other streams are still in the queue when
>all the
>streams that are running finishes, switching the database out of hot mode till
>the other streams come out of the queue may be acceptable depending on how the
>streams were configured. Ultimately, to minimize time in the "hot" mode and
>overhead, some sort of filesystem freeze should be used as is available from
>Veritas Filesystem or Sun's old Backup Copilot product.
It's definitely not irrelevant when you get calls from the DBAs complaining
that you shutdown and restarted their database five times last night. (Or
put into and took out of hot backup mode.) And yes, you can use vxfs
snapshot or EMC BCVs to take downtime to a minimum, but that costs a LOT
more per box.
>Besides multi streaming an individual server is a pointless exercise if your
>site is large enough to have enough simultaneous sessions from different
>servers
>to begin with. It's the old parallel processing performance problem, too
>fine
>a granularity will not actually amortize the overhead required. If you have
>more database servers to backup than the number of streams that you are
>willing
>to allow to your storage units concurrently, there's no point in
>multi-streaming.
I definitely disagree here. You assume that all of the database servers
can be kept in backup mode indefinitely. Doing things the way you suggest
might result in the same amount of overall backup time, but it will
definitely result in increased time per server. I try to design things in
such a way that each server is backed up as quick as possible.
>Also, if the database is distributed across a RAID, the RAID
>hardware will hopefully already have squeezed out whatever performance
>gain that
>could be had by parallelism making multiple streams a moot point, if the
>database is all on one volume, multi-streaming will slow it down and with
>modern
>disks going towards monolithic drives with very few platters, any kind of
>parallelism will likely slow it down as more data is now on the same physical
>device.
Again, I definitely disagree. I've used many very nice pieces of RAID
hardware, and your assumption that one stream should be the same speed as
many streams is definitely not the case. In my latest configuration, we
were pumping 200 MB/s out of one RAID array using multistreaming. Try
doing that with a single stream.
>The only thing I use multi-streaming for is when I have an unreliable link.
>That way, the backup is broken up into smaller backups that would not
>invalidate
>each other when a problem does occur ie.: if the link temporarily goes
>out, only
>a small piece needs to get requeued rather than the whole thing. In this
>case,
>I would also constrain the class to a limited number of concurrent jobs in
>order
>to limit the number of segments disrupted by a network blip. Other than for
>that use, I consider multi-streaming to be just plain evil. The only
>problem I
>have there is that I have to increase the period of time, jobs are allowed to
>remain in the queue for and that can only be done globally rather than on
>a per
>class basis, wish Veritas would change that...
>
>Now, arguably, there may be cases where a specific server is so critical that
>they want to be able to dedicate all resources to that server during the
>backup
>period. At that point, my view is that they need a more robust
>filesystem like
>Veritas Filesystem and perhaps a local tape changer and drives if the need
>for a
>short backup window is so critical. Playing with multi-streaming will just
>accommodate that server at the expense of overall capacity.
But what if you have a data center full of critical servers, each of which
wants their backup to be completed as quick as possible? The best way to
do it is multistreaming.
---
W. Curtis Preston
Principal Consultant for Storage Designs, your storage experts
Webmaster: http://www.backupcentral.com Phone: 760 631 7991
|
