Hi Sam,
On 11/05/2015 10:22 PM, Sam McLeod wrote:
Hi Jerome,
Sorry for the delayed response (AEDT timezone) and thank you for your replies - particularly the second which confirmed my suspicions around Xen.
No worries, I am not the quickest myself to handle email :-)
So, basically the tools are there to save/restore PR metadata, sharing
it with a secondary node is an exercise left to the cluster admin but is
trivial (csync2 just works), and a 2-lines python script using rtslib
can restore arbitrary metadata from file on a different node if the WWNs
have changed. Unfortunately, dealing with broken logic from Xen will
still require some head-scratching I am afraid :-(
I use Corosync+Pacemaker to manage some high performance HA storage clusters and several of these use iSCSI w/ Xen or XenServer.
Good. Just curious, do you use DRBD for replication or a shared disks
enclosure ?
What I'm trying to do is avoid is:
A) Adding configuration or state managed outside of the clusters visibility, i.e. stored on a shared LV or filesystem.
B) Creating more managed resources and dependancies within the cluster design
Just a note, csync2 has been rewritten by people from LINBIT (company
behing DRBD) and is part of the stack routinely used with DRBD/Pacemaker
clusters. I personally use it too in Pacemaker clusters I deployed for
my clients.
One thing I could do to maybe help you integrate this a bit more would
be to export a targetcli command to load PR APTPL data directly from
CLI, that you could use to script your way out of that quagmire without
resorting to python code. Would that help?
That would be fantastic and a great help with configuration / state automation and repeatability.
With the PR information provided to TargetCLI from the OCF resource agent this would allow the LUN to shift between hosts and essentially appear unchanged to Xen.
Parameters are passed to TargetCLI as follows and would need to be extended to accept the PR metadata: https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/iSCSILogicalUnit#L362
I can submit a PR for the iSCSILogicalUnit resource agent if you're able to add and document the functionality to TargetCLI?
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 ?
--
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
