I have to say, I’m really liking NetWorker’s ability to work with persistent binding on tape libraries now.<\/p>\n
If you’re not aware of persistent binding, it exists to resolve a problem whereby on some platforms (such as Windows and Linux), device re-ordering can happen across reboots. For a long time there’s been ways of preventing this from being an issue for filesystems\/LUNs – for instance, on Linux most filesystem types support mounting a filesystem via a unique label or UUID. For example, this is a typical entry from \/etc\/fstab on a CentOS install:<\/p>\n
LABEL=\/boot \/boot ext3 defaults 1 2<\/pre>\nThis allows the OS to mount the \/boot filesystem regardless of whether it’s on \/dev\/sda, \/dev\/sdb, \/dev\/whatever<\/em>.<\/p>\n
Persistent binding allows us to do the same thing with tape as the above does with disk. The advantage of this is obvious: when NetWorker configures a tape library, it maps element order to device paths \u2013<\/p>\n
[root@linuxvtl ~]# sjisn 3.0.0<\/strong>\nSerial Number data for 3.0.0 (SPECTRA PYTHON):\n\t<\/span>Library:\n\t\t<\/span>Serial Number: XYZZY_A \n\t\t<\/span>SCSI-3 Device Identifiers:\n\t\t\t<\/span>ATNN=SPECTRA PYTHON\n\t\t\t<\/span>WWNN=50223344AB000000\n\t<\/span>Drive at element address 1:\n\t\t<\/span>SCSI-3 Device Identifiers:\n\t\t\t<\/span>ATNN=IBM ULT3580-TD1 XYZZY_A1 \n\t<\/span>Drive at element address 2:\n\t\t<\/span>SCSI-3 Device Identifiers:\n\t\t\t<\/span>ATNN=IBM ULT3580-TD1 XYZZY_A2 \n\t<\/span>Drive at element address 3:\n\t\t<\/span>SCSI-3 Device Identifiers:\n\t\t\t<\/span>ATNN=IBM ULT3580-TD1 XYZZY_A3 \n\t<\/span>Drive at element address 4:\n\t\t<\/span>SCSI-3 Device Identifiers:\n\t\t\t<\/span>ATNN=IBM ULT3580-TD1 XYZZY_A4<\/pre>\nIf you can’t see the mappings there, don’t worry \u2013 we can see that via inquire \u2013 <\/em>for example:<\/p>\n
scsidev@3.1.0:IBM ULT3580-TD1 550V|Tape, \/dev\/nst0\n\t<\/span>S\/N:\t<\/span>XYZZY_A1 \n\t<\/span>ATNN=IBM ULT3580-TD1 XYZZY_A1 \n\t<\/span>WWNN=50223344AB000100<\/pre>\nThat information works well for conventional situations where there’s no risk of a device re-ordering.<\/p>\n
When there’s a risk of re-ordering however, the above style of configuration doesn’t work \u2013 or if it does, it doesn’t work across reboots. To avoid it in its entirety, we instead do a configuration that uses more exact identification details. Typically, this is in a fibre-channel scenario, and that means WWNs.<\/p>\n
We can access device details referencing WWNs via the persistent binding mode \u2013 inquire -p, and jbconfig -p.<\/p>\n
Let’s look first at inquire -p<\/em>:<\/p>\n
[root@linuxvtl ~]# inquire -p<\/strong>\nscsidev@3.0.0:SPECTRA PYTHON |Autochanger (Jukebox),\n\/dev\/tape\/by-id\/scsi-350223344ab000000\n\t\t<\/span>S\/N:\t<\/span>XYZZY_A \n\t\t<\/span>ATNN=SPECTRA PYTHON\n\t\t<\/span>WWNN=50223344AB000000\nscsidev@3.1.0:IBM ULT3580-TD1 550V|Tape,\n\/dev\/tape\/by-id\/scsi-350223344ab000100-nst\n\t\t<\/span>S\/N:\t<\/span>XYZZY_A1 \n\t\t<\/span>ATNN=IBM ULT3580-TD1 XYZZY_A1 \n\t\t<\/span>WWNN=50223344AB000100<\/pre>\nIf we run jbconfig -p<\/em>, the output and run-scenario looks a little different, because it’s referencing WWN-based paths rather than standard \/dev\/nst* paths:<\/p>\n
[root@linuxvtl ~]# jbconfig -p<\/strong>\n\nJbconfig is running on host linuxvtl (Linux 2.6.18-128.el5),\n and is using linuxvtl as the NetWorker server.\n\n\t<\/span> 1) Configure an AlphaStor Library.\n\t<\/span> 2) Configure an Autodetected SCSI Jukebox.\n\t<\/span> 3) Configure an Autodetected NDMP SCSI Jukebox.\n\t<\/span> 4) Configure an SJI Jukebox.\n\t<\/span> 5) Configure an STL Silo.\n\nWhat kind of Jukebox are you configuring? [1] 2<\/strong>\n14484:jbconfig: Scanning SCSI buses; this may take a\nwhile ... \nThese are the SCSI Jukeboxes currently attached to your\nsystem:\n 1) 350223344ab000000: Spectralogic\n 2) 350223344ab000800: Spectralogic\nWhich one do you want to install? 1<\/strong>\nInstalling 'Spectralogic' jukebox - 350223344ab000000.\n\nWhat name do you want to assign to this jukebox device? VTL1<\/strong>\n15814:jbconfig: Attempting to detect serial numbers on the\njukebox and drives ...\n\n15815:jbconfig: Will try to use SCSI information returned by\njukebox to configure drives.\n\nTurn NetWorker auto-cleaning on (yes \/ no) [yes]? no<\/strong>\n\nThe following drive(s) can be auto-configured in this\njukebox:\n 1> LTO Ultrium @ 3.1.0 ==>\n\/dev\/tape\/by-id\/scsi-350223344ab000100-nst\n 2> LTO Ultrium @ 3.2.0 ==>\n\/dev\/tape\/by-id\/scsi-350223344ab000200-nst\n 3> LTO Ultrium @ 3.3.0 ==>\n\/dev\/tape\/by-id\/scsi-350223344ab000300-nst\n 4> LTO Ultrium @ 3.4.0 ==>\n\/dev\/tape\/by-id\/scsi-350223344ab000400-nst\nThese are all the drives that this jukebox has reported.\n\nTo change the drive model(s) or configure them as\nshared or NDMP drives, \n you need to bypass auto-configure. Bypass\nauto-configure? (yes \/ no) [no] no<\/strong>\n\nJukebox has been added successfully\n...<\/pre>\nOnce a library has been configured with persistent binding, the device access paths logically become different. On Windows, you’ll get device path names of \\.TapeX where X starts at something along the lines of 2^31-X; on Linux, the paths will vary depending on the install \u2013 for instance, CentOS may give a different result than Oracle Unbreakable Linux, etc. The device paths on Linux as well will explicitly reference the WWNs:<\/p>\n
[root@linuxvtl ~]# nsrjb -v<\/strong>\n<snip><\/em>\ndrive 1 (\/dev\/tape\/by-id\/scsi-350223344ab000100-nst) slot : \ndrive 2 (\/dev\/tape\/by-id\/scsi-350223344ab000200-nst) slot : \ndrive 3 (\/dev\/tape\/by-id\/scsi-350223344ab000300-nst) slot : \ndrive 4 (\/dev\/tape\/by-id\/scsi-350223344ab000400-nst) slot :<\/pre>\nWhile this makes referencing individual tape drives a little more fiddly, it has the distinct advantage that across multiple reboots, the library remains fully operable and all devices accessible \u2013 a very, very<\/em> small price to pay. There is, indeed, virtue in persistence. If you want to read more about NetWorker and persistent binding, check out the whitepaper about it available on PowerLink<\/a>.<\/div>\n","protected":false},"excerpt":{"rendered":"I have to say, I’m really liking NetWorker’s ability to work with persistent binding on tape libraries now. If you’re…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_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},"jetpack_post_was_ever_published":false},"categories":[3,5,15,16,27],"tags":[317,381,737,786,850,1129],"class_list":["post-2927","post","type-post","status-publish","format-standard","hentry","category-architecture","category-backup-theory","category-linux","category-networker","category-windows","tag-device-path","tag-fibre-channel","tag-persistent-binding","tag-reboot","tag-san","tag-zoning"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t