Veritas-bu

[Veritas-bu] RE: Relative performance of 9840a's and 9940Bs u nder NT and W2K.

2002-11-21 22:07:16
Subject: [Veritas-bu] RE: Relative performance of 9840a's and 9940Bs u nder NT and W2K.
From: MarelP AT AUSTRALIA.Stortek DOT com (Marelas, Peter)
Date: Fri, 22 Nov 2002 14:07:16 +1100
Paul,

It sounds like your better off running backups through IP.
Reason is your servers can not drive the
capabilities of the existing tape technology which is only
getting faster.

By utilising an architecture based on IP you get to stack the
backups of slow servers together onto a lesser number of tape drives.

You could also utilise your existing SAN infrastructure by running
IP over it (this would need to be qualified further).

As your servers performance starts to match the capabilities of
your tape infrastructure in terms of throughput, you can move back
into SAN backups with SSO.

And just to clarify the 9940B is 30MB/s, 9840A is 10MB/s, 9840B is 19MBs
all native specs.

Regards
Peter Marelas



-----Original Message-----
From: Paul Bleimeyer [mailto:paulb AT mayo DOT edu]
Sent: Friday, 22 November 2002 09:53
To: 'Johnny Oestergaard'; veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] RE: Relative performance of 9840a's and 9940Bs
under NT and W2K.


Johnny, David, others,

Thanks for your comments. I am currently looking at a high growth
environment with a limited
retention window. 90days worth of backups with a little over 2gb of data.
Currently we have
4 drives running in a SSO environment over FC which works pretty well once
you get all the
the WWN's locked down to a specific Scsi id and held there. My main issue is
that with 10
upstream servers, it takes a bit of juggling to make sure everyone gets a
drive at night
at the right time and I don't see my growth tapering off until around 10TBs
sometime in the
next 24 months. Backup performance ranges from 7Mbps on highly fragmented
arrays in the SAN
with lots of small files and thousands of folders, to 10-11Mbps when we hit
the large files
and department style folders with large amounts of presentation data and
images.
My concern is that I am seeing the type of data we are handling is changing
over
time, which an increasing amount of it being somewhat uncompressible.

Johnny, You mentioned that I might find the speed of the 9940B somewhat slow
in comparison
to the 9840s we have now. Can you give me an idea of slow? I know we are
going to see a 10x
increase in capacity (uncompressed), but at what performance penalty? I
would rather
wait for 9840C's since it would theoretically allow me to reuse my existing
tape files, but
I am very concerned that we might not make it if the growth continues. I
will have to
rethink at my buffer settings again on my media servers as well. I think
there might be a bit
more I can squeak out of the drives for performance.

Our compression has been averaging around 1.6-1.7 to 1 right now, where as
it used to be right at
2.0 to 1.

Respectfully,

Paul

> -----Original Message-----
> From: Johnny Oestergaard [mailto:joe AT joe DOT net]

> The best we get at the moment on the drives is around 13
> MB/s. We have seen

> Moving from 9840 to depends mostly on what kind of needs you have.
> Using 9940B's will give you a lot more data in your library
> then using
> 9840B, but remember if you are used to the mount times and
> seek times on
> 9940B you will think of 9940B as slooow.
>
> In a HSM system with a lot of tapemounts 9940B could slow
> down your system,
> but if what you have is a "normal" backup/recovery senario
> you could end up
> with a faster total system performance with 9940B.
> 9940B is faster then 9840B, except for mount/dismount and
> seek, and you
> need less mounts to backup eg 1 TB data to 9940B then to 9840B.
>

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu

<Prev in Thread] Current Thread [Next in Thread>
  • [Veritas-bu] RE: Relative performance of 9840a's and 9940Bs u nder NT and W2K., Marelas, Peter <=