You have left out a lot of information. What kind of tape library or drives, network bandwith, how much data you are backing, when you are backing, when you zre backing the data?
Your question depends on these factors and more? If, however, you are ambiguous about using Network, ask one of their sales person to give you presentation. May be it is for you or isn't for you?
NetWorker will not be the bottleneck - it will be the hardware because NW can do serverless backups (at a storage node). However, the network link (to update the databases with the file information at the NW server) and of course a huge number of very small files could be the bottleneck as this speed has to support the backup. Both processes run in parallel.
You can of course run benchmarks to test the behaviour.
For such tests, please read the "Performance Tuning Guide" which you can download from Legato's Support Pages.
i think this question needs some clarification. Where you you expect a potential problem?
NetWorker does not really care whether the client is clustered, except for licensing .-).
The issue is how the virtual disks are presented to the OS, not to NW. As long as the OS can see it, NW can use it.
The only other necessary task is to start the NW client software (nsrexecd). But this again must be solved by the cluster solution - it can not be done by the NW client software itself.
A cluster scenario can of course be problematic ... for the NW server! But not for the client.
Sorry about the confusion. What I meant is that we are using 7.2 client and our Novell environment is clustered. I beleive it is Version 1.8. As per Legato it is not supported. Now what I wanted to know is, is anyone using it configured for a cluster so that if the volumes fail over networker is aware and backs up as ususal? Hope that was a little clearer
for the speed perfomance you should use on the novell side the following:
tsaup18 (at least or Sp5 for 6.5 where newer tsafs and so on are inside)
For tsafs you shoudl use the parameter: LOAD TSAFS.NLM /CacheMemoryThreshold=1 odr disabelign the cache for tsa.
This will ehance the speed, because networker does not use this function !
Add the bsdsock.nlm should be 6.59j and NOT newer !
there is a Bug with the newer versions of bsdsock.nlm in combination with libc.nlm and the networker that the datastream get corrupted and often retreyed.
If you are using solaris as networker server plattform, you should set there the following:
Would it be possible to elaborate on the network card specifications on Novell side. As for the bsdsock we tested this in the lab and you are right it works better with 6.59j. Would you know if this is a problem relateds to the Novel NLM or a compatibilty between Novell and Networker. I'm trying to see if Legato needs to do something for it to work with the recent bsdsock.nlm
it seams to be, that it has only indirect with the bsdsock.nlm to do, novell says, it has to do with the libc.nlm, nut i got also a new from December the 15. with the same problem in combination with the new bsdsock.nlm 6.63.01
EMC/Legato Eng. is working with novell Eng., together to fix that problem at the moment.
Btw, i got also a new patch from Friday for the saveset recover problem with smsut.nlm
look here, i collected everythign together but use at our own risk !
the problem was, that on a saveseset recover, the smsut.nlm consumed per 20 GB of restored date 100 MB in the ram of the novell server and never gives it free, also not if the memory was enought for the restore and the restore weas finished.
Tha last you sere from the novell server is a abend.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.