As I understand the USB design, it is strictly a master/slave connection. There can only be ONE master. Thus no "mirror the data".
There is a patent (
https://www.google.com/patents/US8447890) for a USB hub to allow two masters to be connected - but I have seen no products.
You can make use of the network by using a distributed filesystem that provides the redundancy. Each system would then perform the I/O to its respective USB devices.
You might be able to use iscsi to share disk level access - but that again tends to be a "master-slave" connection in that the iscsi client controls the I/O done on the iscsi target.
But doing either of these may require a kernel rebuild to that includes the iscsi modules (or distributed filesystem) for both systems.
A more complex/expensive solution is to use 4 pi nodes, two are I/O nodes acting as controllers for the respective USB attachments, the other two are the HA nodes. At that point the two I/O nodes can communicate to provide distributed access transparent to the two HA nodes. This way the two I/O processors can provide redundant NFS services - and the HA nodes use NFS failover for data, as well as HA services for one node to failover to the other.
What this doesn't get you is failover of things like USB mice/keyboards - which have to attached to only ONE hub. Using a USB-over-ethernet you can get such "sharing" during the failover from one HA node to another. But if one of the I/O nodes fail, you would lose the keyboard/mouse if they are attached to that node.
With that many nodes, you would want a network switch rather than usb network adapters (it would also simplify the network configuration (otherwise each node has to have 3 network adapters, using up the built-in USB connections - the native network connection would be to an administrative network for logging purposes... leaving only one USB connection for all the devices). Of course this also makes the network switch the single point of failure...
