George,
Regarding 2 quotes from below:
>The end result is that the old NetWorker will not scale well. It is
>fine as a departmental backup system, but when you try to push it for
>use as an enterprise backup system it will hit a performance wall. The
>obvious solution to this would be to use faster CPU's in your server.
>Unfortunately this is a limited solution; there is a limit to how far
>you can overclock a 3 GHz CPU.
>In the new implementation the resource database is preserved on disk as
>a large number of very small files, one per resource. Every time an
>attribute is changed only the one resource file is written out. Since
>these files are so small there is a lot less work involved in updating
>them. This effectively solves this problem for quite some time.
How many clients were you running that a 3GHz processor had issues? I have 500
on a 4x400MHz Sun master with two e4500 storage nodes. In that environment,
one cpu is pegged about 22 hours a day and nsrd is VERY much our performance
bottleneck. Do you have any thoughts about how much (percentage) the load
dropped after moving to 7.x and the more efficient DB style?
>For those that are curious: in NSR7 the resources are still stored in
>text form, just like in the old nsr.res, but one resource per file.
>When you first start it the resource database is automatically
>converted to the new format. There are no tools provided to convert
>back. This is why this upgrade is stated to be one-way only. [text removed]
I remember the 5.x to 6.x conversion being painfully long, particularly in the
client data updates on the master (nsr.res and indexes). What was your feel
for how long it took to convert X number of clients?
Thanks,
Ted
-----Original Message-----
From: George Scott [mailto:George.Scott AT ITS.MONASH.EDU DOT AU]
Sent: Thursday, June 26, 2003 4:13 AM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: Re: [Networker] 7.0 Experience
Joel,
> I'd like to hear some feedback from people with 7.0 in production.
> Comments on stability, bugs, upgrade process. I'll be looking at
> upgrading several months down the road, and will probably ask again, but
> I'd like to hear what the current feelings are about the new release.
I have a small data zone running NSR7.0 in production. Short form
specs are: 1 Solaris-based server, 46 clients (Solaris, Linux, DU,
NetWare, Windows), 1 silo, 6 drives, 380 volumes, 600 GB/day).
So far I haven't noticed any problems that I can attribute to NSR7.
OTOH there are some improvements that show a lot of promise:
1. it copes with hardware failure in the tape system (eg, jukebox
problems) much much better than NSR5 or NSR6 does.
2. the resource database is now split up into a directory structure
with one resource per file (instead of the monolithic
/nsr/res/nsr.res and nsrjb.res).
3. each resource now has a comment attribute.
The larger your setup the more you will appreciate these improvements.
To expand on the second one:
The way older versions implement the resource database is one of the
big things preventing NetWorker from becoming an enterprise backup
solution. The problem is that the database is updated frequently while
backups are running (eg, every time a save set finishes the work list
and completion lists are updated). Although the database is held in
memory (in nsrd), every time it is updated it is also flushed back to
disk. The larger your setup the larger your resource database will be
and the more frequently it is updated.
In the old implementation it is preserved on disk as a small number of
relatively large files; every time an attribute is changed the whole
file is written out. In a moderate size setup, in the heat of a large
group, the work involved in constantly writing this file is enough to
peg one of the CPU's on your server. Nsrd appears to be single
threaded, so while it is updating the resource database it is not doing
anything else.
The end result is that the old NetWorker will not scale well. It is
fine as a departmental backup system, but when you try to push it for
use as an enterprise backup system it will hit a performance wall. The
obvious solution to this would be to use faster CPU's in your server.
Unfortunately this is a limited solution; there is a limit to how far
you can overclock a 3 GHz CPU.
In the new implementation the resource database is preserved on disk as
a large number of very small files, one per resource. Every time an
attribute is changed only the one resource file is written out. Since
these files are so small there is a lot less work involved in updating
them. This effectively solves this problem for quite some time.
For those that are curious: in NSR7 the resources are still stored in
text form, just like in the old nsr.res, but one resource per file.
When you first start it the resource database is automatically
converted to the new format. There are no tools provided to convert
back. This is why this upgrade is stated to be one-way only. My
feeling (albeit untested) is that you could concatenate the appropriate
individual resource files together and end up with nsr.res and
nsrjb.res files suitable for use with NSR6 again. You would probably
want to test this before relying on it :-).
The resource database was one of the big things preventing NetWorker
from being suitable for use enterprise wide, but not the only thing.
Others include: inability to rename anything on the fly (particularly
clients), the daily nsrim process, lack of decent volume management,
unwieldy user interfaces, old design (pre-SAN) device handling, minimal
security, lack of good tracing, auditing, and logging, lack of
reporting, capacity planning, and billing tools, inability to delegate
admin functions, inability to rotate log files, complex money grubbing
license structure, and, probably most significantly, poor support
structure. (Admittedly, some of these things are available as high
cost tack-ons. They shouldn't be - they should be tightly integrated
into the product as standard. Some of these might require large
sections of the product to be redesigned from the ground up - that is
the type of commitment required to produce a world-class product and to
become a market leader.)
Legato have come a long way, but there is still an enormous way to go.
They shouldn't rest on their laurels if they still aspire to become a
provider of enterprise data protection solutions.
George.
--
George Scott George.Scott AT its.monash DOT edu
Systems Programmer, IT Services, Monash University
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
