One concern I've heard of is that on a SAN, SCSI ID's can change with each reboot. I've been told that persistent binding is the way to go, to ensure that the SCSI ID (a/k/a target) doesn't change "randomly" after a reboot.
In the case where persistent binding is not available, how does one ensure that the target ID doesn't change? My questions is related to disk and tape storage;ensuring that the vfstab (or related, depending on the OS) and the tape links don't change is key to reliable systems on a SAN.
This case is specifically one where a tape changer is being added to a SAN currently only being used for EMC Symmetrix access. I'm concerned that without persistent binding (which I believe is not available due to the drivers being used and supported) that the disk and tape may change after a reboot.
Yup, I've been there. This is mostly an NT thing for disk, where the "physicaldisk" number under NT disk admin will change for a particular drive letter on reboot according to NT's own numbering scheme under NT Detect. Mapping drives under the Solaris sd.conf file helps on that platform. (Or, use the .conf file for the HBA driver.)
The way to stop this from happening haphazardly for a particular server is to use LUN security in the storage array to let each server only "see" what you want it to "see." Using only "primary" partitions under NT will also help.
For a tape library with robotics, you can permanently set the SCSI ID of each device that is introduced into the fabric by using the data router that the library is connected to. There is a "mapping" option on the data routers that allow this.
If you let the data router "assign" SCSI ID's automatically, The ID's can change if drives are added or removed, or the Data Router is rebooted. These changes are then seen by the backup server and things start to get ugly.
You can get more information on this from the CrossRoads Web site at http://www.crossroads.com/support/manuals/. Look for the users manual for the Crossroads 45XX bridge.
Editor's note: Do you agree with this expert's response? If you have more to share, post it in our Storage Networking forum at http://searchstorage.discussions.techtarget.com/WebX?50@@.ee83ce4 or e-mail us directly at firstname.lastname@example.org.
This was first published in September 2001