Enabling iSCSI APTPL with TargetCLI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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, 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. 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.


��.n��������+%������w��{.n����j�����{ay�ʇڙ���f���h������_�(�階�ݢj"��������G����?���&��




[Index of Archives]     [Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Device Mapper]

  Powered by Linux