On 11/09/2015 01:40 AM, Sam McLeod wrote:
Edit: Sorry looks like the mailing list software decided to create a new thread from my last reply, reason X of Y why I hate using mailing lists in 2015.
Please disregard:http://comments.gmane.org/gmane.linux.scsi.target.devel/10469
Good. Just curious, do you use DRBD for replication or a shared disks
enclosure ?
We replicate the LUNs that we export via iSCSI, but not the local filesystems that the storage hosts use for simplicities sake.
Have a look at the system diagram here:https://smcleod.net/ssd-storage-cluster-diagram/
Well, as I mentioned, one simple and easy way to replicate the PR
metadata is to use csync2.
It is very ligtweight, config is simple and there is no complexity to
manage like there would be if using DRBD.
Well, adding the possibility to load arbitrary PR metadata is doable.
But if you just replicate the PR metadata in /var/target/, just doing this:
targetcli /backstores/block create
name=${OCF_RESOURCE_INSTANCE}dev=${OCF_RESKEY_path}
(from the OCF agent source you linked to) is normally enough to restore
the PR data (granted you have it properly replicated in /var/target/pr),
based on the device T10 WWN serial. What puzzles me is that the RA then
proceeds to change the WWN. If this is used, then yes, you would need to
load PR manually afterwards from the actual ${OCF_RESKEY_scsi_sn} in
use, assuming the same was used on the primary node. I need to check
what happens in that case, as I never played with that. I would guess
the iblock backend honors the WWN change and uses it for PR metadata,
but I am not sure. Do you actually provide an ${OCF_RESKEY_scsi_sn} in
your configs ? If so, what is the goal ?
We do indeed provide the WWN / serial and while that's useful for LUN discovery by the Xen initiators the idiocy of Xen not using that for ongoing identification and instead looking for the SCSIID means that when you fail over between nodes and the SCSIID
changes if you need to restart any of the initiators they will no longer be able to attach the storage.
Could you give me a CLI example where you highlight what exactly Xen is
using and what the LUN exposes before/after migration in terms of
scsi_id / blkid / cat /sys/...../vpd_unit_serial etc. I just want to
make sure that we are on the same page here and that I can
reproduce/alter the behavior. There have been confusions in the past re.
vpd_assoc_logical_unit / NAA / vpd_unit_serial / WWN ;-)
The only way to fix it is by taking the LUN completely offline, logging out and forgetting it in XenServer and recreating / attach it again which is a right
pain.
I really don't want to add another DRBD replicated resource to the cluster just to share this tiny bit of metadata so if I can enforce the SCSID during creation then I believe this will no longer be an issue.
Well, send me some fixed point reference to work on (see above) and I
will setup a lab and see what makes the most sense in terms of
integrating with the RA. Also, please confirm which versions of
rtslib/targetcli you are using.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
