{"id":2216,"date":"2010-04-26T20:08:54","date_gmt":"2010-04-26T10:08:54","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=2216"},"modified":"2018-12-11T18:43:15","modified_gmt":"2018-12-11T08:43:15","slug":"adv_file-operational-changes","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2010\/04\/26\/adv_file-operational-changes\/","title":{"rendered":"ADV_FILE operational changes"},"content":{"rendered":"

As I mentioned in an earlier post<\/a>, EMC have announced on their community forum that there are some major changes on the way for ADV_FILE devices. In this post, I want to outline in a little more detail why these changes are important.<\/p>\n

Volume selection criteria<\/h3>\n

One of the easiest changes to describe is the new volume selection criteria that will be applied. Currently regardless of whether it is backing up to tape, virtual tape, or ADV_FILE disk devices, NetWorker uses the same volume selection algorithm \u2013 whenever there are multiple volumes that could be chosen, it always picks volumes to write to in order of labeled date, from oldest to most recent. For tapes (and even virtual tapes), this selection criteria makes perfect sense. For disk backup units though, it’s seen administrators constantly “fighting” NetWorker to reclaim space from disk backup volumes in that same labeling order.<\/p>\n

If we look at say, four disk backup units, with the used capacity shown in red, this means that NetWorker currently writes to volumes in the following order:<\/p>\n

\"Current<\/a>So it doesn’t matter that the first volume picked also has the highest used capacity \u2013 in actual fact, the entire selection criteria is geared around trying to fill volumes in sequence. Again, that works wonderfully for tapes, but it’s terrible when it comes to ADV_FILE devices.<\/p>\n

The new selection criteria for ADV_FILE devices, according to EMC, is going to look like the following:<\/p>\n

\"Improved<\/a>So, recognising that it’s sub-optimal to fill disk backup units, NetWorker will instead write to volumes in order of least used capacity. This change alone will remove a lot of the day to day management headaches of ADV_FILE devices from backup administrators.<\/p>\n

Dealing with full volumes<\/h3>\n

The next major change coming is dealing with full volumes \u2013 or alternatively, you may wish to think of it as dealing with savesets whose size exceeds that of the available space on a disk backup unit.<\/p>\n

Currently if a disk backup unit fills during the backup process, whatever saveset being written to that unit just stays right there, hung, waiting for NetWorker staging to kick in and free space before it will continue writing. This resembles the following:<\/p>\n

\"Dealing<\/a>As every NetWorker administrator who has worked with ADV_FILE devices will tell you, the above process is extremely irritating as well as extremely disruptive. Further, this only works in situations where you’re not writing one huge saveset that literally exceeds the entire formatted capacity of your disk backup unit. So in short, if you’ve previously wanted to backup a 6TB saveset, you’ve had<\/em> to have disk backup units that were more than 6TB in size, even if you would naturally prefer to have a larger number of 2TB disk backup units. (In fact, the general practice has been when backing up to ADV_FILE devices to ensure that every volume can fit at least two of your largest savesets on it, plus another 10%, if you’re using the devices for anything other than just intermediate-staging.)<\/p>\n

Thankfully the coming change will see what we’ve been wanting in ADV_FILE devices for a long time \u2013 the ability for a saveset to just span from one volume it has filled across to another. This means you’ll get backups like:<\/p>\n

\"Disk<\/a>This will avoid situations where the backup process is effectively halted for the duration of staging operations, and it will allow for disk backup units that are smaller<\/em> than the size of the largest savesets to be backed up. This in turn will allow backup administrators to very easily schedule in disk defragmentation (or reformatting) operations on those filesystems that suffer performance degradation over time from the mass write\/read\/delete operations seen by ADV_FILE devices.<\/p>\n

Other changes<\/h3>\n

The other key changes outlined by EMC on the community forum are:<\/p>\n

    \n
  • Change of target sessions:\n
      \n
    • Disk backup units currently have a default target parallelism of 4, and a maximum target parallelism setting of 512. These will be reduced to 1 and 32 respectively (and of course can be changed by the administrator as required), so as to better enforce round-robining of capacity usage across all disk backup units. This is something most administrators will end up doing by default, but it’s a welcome change for new installs.<\/li>\n<\/ul>\n<\/li>\n
    • Full thresholds:\n
        \n
      • The ability to define a %full threshold at which point NetWorker will cease writing to one disk backup unit and start writing to another. Some question whether this is useful, but I can see the edge of a couple of different usage scenarios. First, as a way of allowing different pools to share the same filesystem, making better use of capacity, and secondly, in situations where a disk backup unit can’t be a dedicated filesystem.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

        When we add all these changes up, ADV_FILE type devices are going to be back in a position where they’ll give VTLs a run for their money on cost vs features. (With the possible exception being the relative ease of device sharing under VTLs compared to the very manual process of SAN\/NAS sharing of ADV_FILE devices.)<\/p>\n","protected":false},"excerpt":{"rendered":"

        As I mentioned in an earlier post, EMC have announced on their community forum that there are some major changes…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[3,16],"tags":[102,333,1101],"class_list":["post-2216","post","type-post","status-publish","format-standard","hentry","category-architecture","category-networker","tag-adv_file","tag-disk-backup","tag-vtl"],"aioseo_notices":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-zK","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/2216","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/comments?post=2216"}],"version-history":[{"count":1,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/2216\/revisions"}],"predecessor-version":[{"id":7558,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/2216\/revisions\/7558"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=2216"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=2216"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=2216"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}