When a backup server has been elevated to a director role only in the backup activities, I’d agree it slides closer to being something that could be virtualised, particularly in an environment that you’re describing where performance won’t be an issue.

My personal take on it though remains that one must always be careful of any configuration which sees the backup server dependent on additional infrastructure in order to, well, boot. In this case you’re not just depending on hardware being available, but the virtualisation layer being available as well.

I’m assuming in your site though you’d be either at the point of looking at, or already using SRM, with replication and failover possible between sites. If you’re in that situation, at the backup server is one of the hosts that can be moved between sites, then perhaps many of my objections regarding dependencies no longer apply.

If you’re looking for some other opinions, feel free to go to the forums and ask some others what they’d do, too :-)

Cheers,

Preston.

I’ll admit that my experience with LDOM is insufficient to provide any specific yay or nay recommendations on the proposed configuration. My gut reaction, even in a zeroth-tier configuration, is to keep backup servers on physically independent hosts. However, I will agree though that in the configuration you’re suggesting, where the actual backup processes will be handled by physically separate storage nodes, you have the most chance of running virtualised servers that don’t leach from each others resources – so long as you’re allocating a sufficient number of CPUs and the appropriate amount of RAM for each datazone to each server.

Specially two Networker server running on each physical CMT system, the domains are physically separated by the system’s bus. Each LDOM would have direct access to FC tape drive for recovery and supportability reasons.

For DR considerations all data is replicated to another site and for performance reasons the Networker server only serves as the controller for a datazone and does not handle real data IOs.

(Technically in a NetWorker datazone, there’s only one type of server – the backup server itself. Storage nodes aren’t referred to officially as servers in a NetWorker sense, and management console hosts are ‘servers’ but for a control zone – one control zone can administer multiple datazones. I’m not being nit-picky, I just thought I’d elaborate on how the terms are used, etc.)

That being said my personal preference would still be to avoid running a server or a storage node in a Solaris zone; it’s still effectively putting you into a position where resources are being shared for what is traditionally a performance critical/drive host.

If you are virtualising, or even running in Solaris zones, overall monitoring and control of IO throughput and performance in general becomes much trickier — particularly if you don’t have root/admin priveleges on the virtual server/global zone.