{"id":2927,"date":"2011-03-13T18:05:57","date_gmt":"2011-03-13T08:05:57","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=2927"},"modified":"2018-12-11T18:17:35","modified_gmt":"2018-12-11T08:17:35","slug":"the-virtue-of-persistence","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2011\/03\/13\/the-virtue-of-persistence\/","title":{"rendered":"The virtue of persistence"},"content":{"rendered":"<p>I have to say, I&#8217;m really liking NetWorker&#8217;s ability to work with persistent binding on tape libraries now.<\/p>\n<p>If you&#8217;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&#8217;s been ways of preventing this from being an issue for filesystems\/LUNs &#8211; 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<pre>LABEL=\/boot &nbsp; &nbsp; \/boot &nbsp; &nbsp; &nbsp; ext3 &nbsp; &nbsp;defaults &nbsp; &nbsp; &nbsp; &nbsp;1 2<\/pre>\n<p>This allows the OS to mount the \/boot filesystem regardless of whether it&#8217;s on \/dev\/sda, \/dev\/sdb, \/dev\/<em>whatever<\/em>.<\/p>\n<p>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<pre>[root@linuxvtl ~]# <strong>sjisn 3.0.0<\/strong>\nSerial Number data for 3.0.0 (SPECTRA &nbsp;PYTHON):\n<span style=\"white-space: pre;\">\t<\/span>Library:\n<span style=\"white-space: pre;\">\t\t<\/span>Serial Number: XYZZY_A &nbsp;&nbsp;\n<span style=\"white-space: pre;\">\t\t<\/span>SCSI-3 Device Identifiers:\n<span style=\"white-space: pre;\">\t\t\t<\/span>ATNN=SPECTRA PYTHON\n<span style=\"white-space: pre;\">\t\t\t<\/span>WWNN=50223344AB000000\n<span style=\"white-space: pre;\">\t<\/span>Drive at element address 1:\n<span style=\"white-space: pre;\">\t\t<\/span>SCSI-3 Device Identifiers:\n<span style=\"white-space: pre;\">\t\t\t<\/span>ATNN=IBM &nbsp; &nbsp; ULT3580-TD1 &nbsp;XYZZY_A1 &nbsp;\n<span style=\"white-space: pre;\">\t<\/span>Drive at element address 2:\n<span style=\"white-space: pre;\">\t\t<\/span>SCSI-3 Device Identifiers:\n<span style=\"white-space: pre;\">\t\t\t<\/span>ATNN=IBM &nbsp; &nbsp; ULT3580-TD1 &nbsp;XYZZY_A2 &nbsp;\n<span style=\"white-space: pre;\">\t<\/span>Drive at element address 3:\n<span style=\"white-space: pre;\">\t\t<\/span>SCSI-3 Device Identifiers:\n<span style=\"white-space: pre;\">\t\t\t<\/span>ATNN=IBM &nbsp; &nbsp; ULT3580-TD1 &nbsp;XYZZY_A3 &nbsp;\n<span style=\"white-space: pre;\">\t<\/span>Drive at element address 4:\n<span style=\"white-space: pre;\">\t\t<\/span>SCSI-3 Device Identifiers:\n<span style=\"white-space: pre;\">\t\t\t<\/span>ATNN=IBM &nbsp; &nbsp; ULT3580-TD1 &nbsp;XYZZY_A4<\/pre>\n<p>If you can&#8217;t see the mappings there, don&#8217;t worry \u2013 we can see that via <em>inquire \u2013 <\/em>for example:<\/p>\n<pre>scsidev@3.1.0:IBM &nbsp; ULT3580-TD1 &nbsp; 550V|Tape, \/dev\/nst0\n<span style=\"white-space: pre;\">\t<\/span>S\/N:<span style=\"white-space: pre;\">\t<\/span>XYZZY_A1 &nbsp;\n<span style=\"white-space: pre;\">\t<\/span>ATNN=IBM &nbsp; &nbsp; ULT3580-TD1 &nbsp; &nbsp; XYZZY_A1 &nbsp;\n<span style=\"white-space: pre;\">\t<\/span>WWNN=50223344AB000100<\/pre>\n<p>That information works well for conventional situations where there&#8217;s no risk of a device re-ordering.<\/p>\n<p>When there&#8217;s a risk of re-ordering however, the above style of configuration doesn&#8217;t work \u2013 or if it does, it doesn&#8217;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<p>We can access device details referencing WWNs via the persistent binding mode \u2013 inquire -p, and jbconfig -p.<\/p>\n<p>Let&#8217;s look first at <em>inquire -p<\/em>:<\/p>\n<pre>[root@linuxvtl ~]# <strong>inquire -p<\/strong>\nscsidev@3.0.0:SPECTRA PYTHON &nbsp; &nbsp;|Autochanger (Jukebox),\n\/dev\/tape\/by-id\/scsi-350223344ab000000\n<span style=\"white-space: pre;\">\t\t<\/span>S\/N:<span style=\"white-space: pre;\">\t<\/span>XYZZY_A &nbsp;&nbsp;\n<span style=\"white-space: pre;\">\t\t<\/span>ATNN=SPECTRA PYTHON\n<span style=\"white-space: pre;\">\t\t<\/span>WWNN=50223344AB000000\nscsidev@3.1.0:IBM &nbsp; ULT3580-TD1 550V|Tape,\n\/dev\/tape\/by-id\/scsi-350223344ab000100-nst\n<span style=\"white-space: pre;\">\t\t<\/span>S\/N:<span style=\"white-space: pre;\">\t<\/span>XYZZY_A1 &nbsp;\n<span style=\"white-space: pre;\">\t\t<\/span>ATNN=IBM &nbsp; &nbsp; ULT3580-TD1 &nbsp; &nbsp; XYZZY_A1 &nbsp;\n<span style=\"white-space: pre;\">\t\t<\/span>WWNN=50223344AB000100<\/pre>\n<p>If we run <em>jbconfig -p<\/em>, the output and run-scenario looks a little different, because it&#8217;s referencing WWN-based paths rather than standard \/dev\/nst* paths:<\/p>\n<pre>[root@linuxvtl ~]# <strong>jbconfig -p<\/strong>\n\nJbconfig is running on host linuxvtl (Linux 2.6.18-128.el5),\n&nbsp;&nbsp;and is using linuxvtl as the NetWorker server.\n\n<span style=\"white-space: pre;\">\t<\/span> 1) Configure an AlphaStor Library.\n<span style=\"white-space: pre;\">\t<\/span> 2) Configure an Autodetected SCSI Jukebox.\n<span style=\"white-space: pre;\">\t<\/span> 3) Configure an Autodetected NDMP SCSI Jukebox.\n<span style=\"white-space: pre;\">\t<\/span> 4) Configure an SJI Jukebox.\n<span style=\"white-space: pre;\">\t<\/span> 5) Configure an STL Silo.\n\nWhat kind of Jukebox are you configuring? [1] <strong>2<\/strong>\n14484:jbconfig: Scanning SCSI buses; this may take a\nwhile ...&nbsp;\nThese are the SCSI Jukeboxes currently attached to your\nsystem:\n&nbsp;&nbsp;1) 350223344ab000000: Spectralogic\n&nbsp;&nbsp;2) 350223344ab000800: Spectralogic\nWhich one do you want to install? <strong>1<\/strong>\nInstalling 'Spectralogic' jukebox - 350223344ab000000.\n\nWhat name do you want to assign to this jukebox device? <strong>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]? <strong>no<\/strong>\n\nThe following drive(s) can be auto-configured in this\njukebox:\n&nbsp;1&gt; LTO Ultrium @ 3.1.0 ==&gt;\n\/dev\/tape\/by-id\/scsi-350223344ab000100-nst\n&nbsp;2&gt; LTO Ultrium @ 3.2.0 ==&gt;\n\/dev\/tape\/by-id\/scsi-350223344ab000200-nst\n&nbsp;3&gt; LTO Ultrium @ 3.3.0 ==&gt;\n\/dev\/tape\/by-id\/scsi-350223344ab000300-nst\n&nbsp;4&gt; LTO Ultrium @ 3.4.0 ==&gt;\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,&nbsp;\n&nbsp;you need to bypass auto-configure. Bypass\nauto-configure? (yes \/ no) [no] <strong>no<\/strong>\n\nJukebox has been added successfully\n...<\/pre>\n<p>Once a library has been configured with persistent binding, the device access paths logically become different. On Windows, you&#8217;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<pre>[root@linuxvtl ~]# <strong>nsrjb -v<\/strong>\n<em>&lt;snip&gt;<\/em>\ndrive 1 (\/dev\/tape\/by-id\/scsi-350223344ab000100-nst) slot : &nbsp;&nbsp;\ndrive 2 (\/dev\/tape\/by-id\/scsi-350223344ab000200-nst) slot : &nbsp;&nbsp;\ndrive 3 (\/dev\/tape\/by-id\/scsi-350223344ab000300-nst) slot : &nbsp;&nbsp;\ndrive 4 (\/dev\/tape\/by-id\/scsi-350223344ab000400-nst) slot :<\/pre>\n<div>While 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, <em>very<\/em> small price to pay. There is, indeed, virtue in persistence.&nbsp;If you want to read more about NetWorker and persistent binding, check out the <a title=\"PowerLink WhitePaper on Persistent Binding\" href=\"https:\/\/powerlink.emc.com\/nsepn\/webapps\/btg548664833igtcuup4826\/km\/live1\/en_US\/Offering_Technical\/White_Paper\/h5795-persistent-binding-udev-support-networker-wp.pdf?mtcs=ZXZlbnRUeXBlPUttQ2xpY2tDb250ZW50RXZlbnQsZG9jdW1lbnRJZD0wOTAxNDA2NjgwMzkyZDljLGRvY3VtZW50VHlwZT1wZGYsbmF2ZU5vZGU9MGIwMTQwNjY4MDFhYTY3MF9Hcmlk\">whitepaper about it available on PowerLink<\/a>.<\/div>\n","protected":false},"excerpt":{"rendered":"<p>I have to say, I&#8217;m really liking NetWorker&#8217;s ability to work with persistent binding on tape libraries now. If you&#8217;re&hellip;<\/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,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":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/pKpIN-Ld","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/2927","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=2927"}],"version-history":[{"count":1,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/2927\/revisions"}],"predecessor-version":[{"id":7522,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/posts\/2927\/revisions\/7522"}],"wp:attachment":[{"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/media?parent=2927"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/categories?post=2927"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nsrd.info\/blog\/wp-json\/wp\/v2\/tags?post=2927"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}