Large TSM deploy into VM / NFS environment - advice needed

[qldadmins]

Hi,


Our company is embarking on a massive TSM upgrade from an old, old version. One thing the Admins are doing is assessing best approach for a vast VM and Storage environment.

I'd like advice, particularly regardnig best/recommended methods of configuration around NFS.

There are mutliple sites, but for now, the primary one as our example...

• 400+ VMs.
• Multiple NFS (v3) mounts into most of the VM servers. (some mounts shared between servers)
• Multiple vServers from NetApp 'Cluster Mode' storage (OnTap 8.2.1) providing the NFS shares.

Namespaces that are currently not grouped (we think re-creating the namespaces on the Netapp will be the way to go as it will allow us to group mounts and therefore manage and concurrently back up the many volumes rather than mount / and have the single ridiculously big back up)

So - I am sure we are not the first poor slobs to face this.

Does anyone have thoughts as to best approach for managing this type of environment? The current leading proposal is re-create namespaces so as to allow grouping on specific attributes (prod systems, test systems, data types, etc), mount these into the TSM server and run the back ups as needed. This might not make a lot of sense, to explain, the Storage have 'namespace' exports allowing not only the export of the volume, but a "root level" export (contains all volumes as directories). I'd really like to hear from someone who has similar experience with NetApp Cluster Mode storage with similar landscape as I have described.

Management are not keen on backing up the NFS mounts through the client servers they are mounted into as keeping track of what is captured (and not duplicated when 1 volume is mounted into multiple clients) presents some reconciliation challenges. (how can we tell EVERYTHING is backed up!)

There is also the path the back up takes.
Netapp > client – client > TSM server
Not ideal. Would rather back up direct from NetApp
Netapp > TSM server

Just on that....
Does TSM have the capability to look at NFS mount points (assume 'domain all-local all-nfs' supplied in dsm.opt) and get that filespace directly from the source? Probably not, but I am not familiar yet with the stunning new features of the latest TSM.

Thanks in advance for any advice offered.

 

[qldadmins]

Just to clarify the main issue we are looking at....

NetApp cluster mode storage present volumes as 'namespaces'. The namespace is a junction point that is essentially a directory path from a root volume (which itself can be exported)

Exports frpm NetApp Storage (each relates to a single volume)
/path/to/mount/point/vol1 (Junction point = 'vol1')
/path/to/mount/point/vol2 (Junction point = 'vol2')
/path/to/mount2/point/vol1 (Junction point = 'vol1')
/any/path/you/like/vol1 (Junction point = 'vol1')

Each of these are the volume mount points so on a client server an example mount is...
netapp1:/path/to/mount/point/vol1 /mountdir_on_server
for example.

So even though many volumes have a junction point named 'vol1' - they are not related. similarly, the mount point when you mount it is the entire namespace - not just junction point.

The root of this entire space can also be exported and mounted. - so essentially all folders (and therefore all volumes) would be mounted under the one mount point (and therefore single massive filespace in TSM). Not something we think would be recommended for massive amounts of data to back up!

We are thinking of grouping and mounting into TSM something like...
netapp1:/path/to/mount
netapp1:/path/to/mount2

So all volumes are "grouped" and can be controlled (by type of data, how much data, etc, etc.) through the namespace paths. Whether this has pitfalls, or there is a better approach from people who have experience specific to this scenario, would be most grouse.

Thanks again.

 

[tony2018]

Hi,

Depending on the size of the nfs shares, you can probably looking into ndmp backups, they backup directly to tape, no lan backups, all san attached.

 

[moon-buddy]

Personally, I would stay away from any NDMP (NAS) backup: too slow - both for backup and restore - and too tedious to manage.

I also don't like using Netapp NFS drives (there are reasons for this and out-of-bounds for this topic). It is just too bad you have Netapp as your disk drives via NFS.

Having said all off this, what can you do?

I would stay the traditional route and backup VM using TSM for VE using the disk-to-tape method, like what the install guide writes.

 

[tony2018]

Question is, how is he backing up to tape, 10g or SAN? If you're backing the vm or datastores.

Yeah using tsm to do ndmp backups IS a pain( I'm actually testing it out now) but if the OP is backing over the network to san tape drives, mounting nfs on tsm server/client and than backing up to tape via SAN connectivity, its going to be even longer.

 

[moon-buddy]

Question is, how is he backing up to tape, 10g or SAN? If you're backing the vm or datastores.

Yeah using tsm to do ndmp backups IS a pain( I'm actually testing it out now) but if the OP is backing over the network to san tape drives, mounting nfs on tsm server/client and than backing up to tape via SAN connectivity, its going to be even longer.

Then you don't backup to tape directly - backup to disk then to tape.

LAN Free to disk is available as an option:

http://adsm.org/forum/index.php?threads/lan-free-to-disk.30477/#post-126340

 

[tony2018]

OP are able to provide SAN storage to your TSM server?