Other ctl HA vs HAST for vSphere SAN - are both necessary?

[Avery Freeman]

Hi,

I'm looking at setting up a storage area network for ESXi/vSphere, and I've been looking at all my options.

One thing I came across recently while looking at HAST was that ctl itself has its own HA functionality.

From ctl(4):

+o     Support for multiple ports, initiators, targets and backing stores
+o     Support for VMWare VAAI and Microsoft ODX offload (COMPARE AND    WRITE,
             XCOPY,    POPULATE TOKEN/WRITE USING TOKEN, WRITE    SAME and UNMAP)

...

ha      Internal frontend    used to    receive    requests from other node ports
             in High Availability cluster.

OK, so those look good for a vSphere SAN. It also explains these variables:

kern.cam.ctl.ha_id
         Specifies unique position of this node within High    Availability
         cluster.  Default is 0 -- no HA, 1    and 2 -- HA enabled at speci-
         fied position.

kern.cam.ctl.ha_mode
         Specifies High Availability cluster operation mode:
           0       Active/Standby -- primary node has backend access
               and processes requests, while secondary can only do
               basic LUN discovery and reservation;
           1       Active/Active -- both nodes have backend access and
               process requests, while secondary node synchronizes
               processing with primary one;
           2       Active/Active -- primary node has backend access
               and processes requests, while secondary node    for-
               wards all requests and data to primary one;
         All above modes require established connection between HA cluster
         nodes.  If    connection is not configured, secondary    node will re-
         port Unavailable state; if    configured but not established --
         Transitioning state.  Defaults to 0.

kern.cam.ctl.ha_peer
         String value, specifying method to    establish connection to    peer
         HA    node.  Can be "listen IP:port", "connect IP:port" or empty.

kern.cam.ctl.ha_link
         Reports present state of connection between HA cluster nodes:
          0       not configured;
          1       configured but not established;
          2       established.

kern.cam.ctl.ha_role
         Specifies default role of this node:
          0       primary;
          1       secondary.
         This role can be overridden on per-LUN basis using    "ha_role" LUN
         option, so    that for one LUN one node is primary, while for    an-
         other -- another.    Role change from primary to secondary for HA
         modes 0 and 2 closes backends, the    opposite change    -- opens.  If
         there is no primary node (both nodes are secondary, or secondary
         node has no connection to primary one), secondary node(s) report
         Transitioning state.  State with two primary nodes    is illegal
         (split brain condition).

So if these are options with bare ctl(4), why would one use HAST?

Am I correct in thinking the typical ctl(4) HA topology would be something like:

FreeBSD.host{0,1} -> zfs -> zvol -> ctl.target{0,1}

While for HAST, it's layer would be "under" zfs, such as:

FreeBSD.host{0,1} -> HAST{0,1} -> zfs -> zvol -> ctl.target{0,1} -> uCARP

If HAST is employed, is ctl(4) still necessary for block level target?

Would ctl(4) HA be unnecessary?

Is anyone who's using one, the other, or both for SAN like to tell me about it?

Lastly, if anyone's tried HAST or ctl(4) but decided to go another route, what was involved in your decision?

Thanks!

 

[sek]

UP