Valid points, let me reply a bit:
===> 1. at failover time the backup NetView had to "manage" all the
resources
that had been "unmanaged". This caused many traps within the NetView
system. This was a performance hit at failover time.
Me: Absolutely true, I have a small network, the resource hit is not only
acceptable, but from my design, the hardware needs to be handle a massive
network event.
===> 2. any interfaces that had been "unmanaged" in production were all now
"managed" since that information was not able to be saved and restored.
This caused the new system to show a lot of "red" when it really wasn't at
first.
Me: Also true, we do not unmanage any device. We use a completely open
discovery, we do not unmanage anything, all notifications/paging is done via
automation. There are many red icons, but since we do not have operators
looking at icons, it is not an issue. The operator interface has been
implemented so that critical devices are in smartsets, and should those
resources fail, automation handles the device failures.
===> 3. you had to administer 2 NetView maps.
NetView 7.1 will let you accomplish a primary/backup NetView system much
easier than the old NetView versions. There were ways to make it happen
in NetView 5 and 6, but it took a lot of custom scripting which we have
done for some customers. NetView 7.1 should make that more available to
everyone. NetView 7.1 should make it simpler to write a script to do the
backup, move files and restore on the backup without impacting the
production server.
Me: Absolutely, we have not implemented under version 6 because of the
limitations of the operator interface. However, I still do not see any need
"move" a database from one machine to another. This still requires time I do
not have, and is not a live system until the data gets moved. the backup
function, even with its limitations, splits the polling work geographically
and provides immediate, automated backup.
|