Coming ADV_FILE changes

I had been aware for a while from an NDA conversation that these changes were on the way, but of course have not been able to discuss them.

However, with EMC opening up discussion on the EMC Community Forum – i.e., out in public, I now feel that I can at least discuss how excited I am about the coming ADV_FILE changes.

For some time I’ve railed against architectural failings in ADV_FILE devices, and explained why those failings have led me to advocate the use of VTLs over ADV_FILE devices. As announced on this thread in the forums by Paul Meighan, many of those architectural limitations are soon going to be relegated to the software evolutionary junkpile. In particular, EMC have stated in the forum article that the following changes are on the way:

  1. Volume selection criteria becomes intelligent. NetWorker currently uses the same volume selection criteria for disk backup as it does for tapes. This means that the oldest labelled volume with free space on it always gets picked first, and subsequent volumes get picked following this strategy. This has meant that backup administrators have continually fought a running battle to keep the original disk backup units staged more regularly than others. Instead, NetWorker will now pick ADV_FILE volumes in order of maximum capacity free, which will free a lot of backup administrators from the overall pain of day to day capacity management.
  2. Savesets can span advanced file type devices. Finally, the gloves are off! With the ability to have savesets cease writing to one disk backup unit and move over to another, NetWorker ADV_FILE devices will be able to serve as a scaleable and transparent storage pool, backups will flow from one device to another in exactly the way they always should have.
  3. Session changes. To reflect round-robining best practices, the default target sessions for disk backup units will drop from 4 to 1.

When we add together the first two changes, we get powerful enhancements in NetWorker’s disk backup functionality. Do other products already do this? Yes, I’m not suggesting that NetWorker is the first to this, but it’s fantastic to finally see this functionality coming into play.

Until this point, NetWorker has suffered the continual challenge with disk backup of constant administrative overheads and trying to plan in advance the best possible space allocation technique for disk backup filesystems. Once these changes come into play: no more challenge on either of these fronts.

Folks, this is big. Yes, these changes should have come a long time ago, but I’m not going to let the delay get in the way of being damn grateful that they’re finally coming.

6 thoughts on “Coming ADV_FILE changes”

  1. Hi Preston,

    Well that sure is good news.

    VTLs still have one advantage. We have one NetWorker server, one storage node and one dedicated storage node which can all read or write any tape in our VTL. We only have one physical tape library connected to the NetWorker server. We backup to the VTL through the most appropriate storage node and then clone to physical tape by mounting the virtual tape on the NetWorker server. Does NetWorker have the ability to share ADV_FILE devices so we can replicate this behaviour?

    Cheers,
    Rob

    1. Hi Rob,

      Sharing of ADV_FILE devices is actually possible. This is outlined in the administration guide for NetWorker (that link is for 7.5.x). Starting page 248 is the description of the process.

      To quote from the guide:

      In a Network Attached Storage (NAS) Environment, NetWorker operations can be performed concurrently on two storage nodes that share an AFTD. When sharing an AFTD, one storage node can save to a writable volume, while the other storage node either recovers or clones from a read-only volume.
      In a Storage Area Network (SAN), NetWorker operations are performed sequentially when two storage nodes share an AFTD. Only one storage node at a time can use the shared AFTD.

      Hope this helps!

      Cheers,

      Preston.

    1. To quote Paul’s announcement on the Forum:

      Over the longer term we’ll be looking to improve read/write concurrency as well as to eliminate the .RO device.

      As to whether they’ll come at the same time as the other changes, I’m not sure.

  2. One of the “issue” that remains is the fact that dropping Target Sessions to 1 is a good idea…. except if you have Tape Devices on the same storage node, since the lowest target session value for a Storage Node will get apply across all devices of that node…

    I’m still trying to figure out with EMC if this is a “normal behavior” (hehe) or a bug…

    Eric

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.