resource-agents

3], depending on targetcli version. Then you create the portal which exposes the target (backed by the raw disk) to the network as normal (see Debian guide fex). I did it like this, you have to adjust for the name of your device: /iscsi/iqn.20...1c9879a1/tpg1> cd portals /iscsi/iqn.20.../tpg1/portals> delete 0.0.0.0 3260 /iscsi/iqn.20.../tpg1/portals> create 10.1.1.101 /iscsi/iqn.20.../tpg1/portals> cd .. /iscsi/iqn.20...1c9879a1/tpg1> set attribute authentication=0 demo_mode_write_protect=0 generate_node_acls=1 cache_dynamic_acls=1 This creates a portal which exposes a single LUN, backed by the raw disk, on the IP 10.1.1.101, and disables authentication and demo mode (write protection). Next you install the iSCSI client (called initiator)[4], I did this on a separate machine. There I connected to each of the target on each Pi. Once successful you should get a number of disks under /dev/disk/by-path/ip-*, which you can then specify when importing the pool on the iSCSI client machine, say zpool -d /dev/disk/by-path/ip-X -d /dev/disk/by-path/ip-Y Since you're exposing the raw block device, there's no difference in that regard to having the disk plugged into the client machine directly. Btw, I recommend not messing with authentication at first, though it's not terribly difficult to set up. edit: As mentioned the nice thing about this approach is that it's effectively "harmless". If it doesn't work out for you, you can always put all the disks in a single machine and import the pool as normal. Also, iSCSI has a lot of robustness built in. For example the iSCSI client will temporarily store writes and re-issue once the target (server) is back online. I safely rebooted one of the Pis while copying data to the pool, for example. [1]: https://en.wikipedia.org/wiki/ISCSI#Concepts [2]: https://wiki.debian.org/SAN/iSCSI/LIO [3]: https://github.com/ClusterLabs/resource-agents/pull/1373 [4]: https://wiki.debian.org/SAN/iSCSI/open-iscsi

h a focus on HA and the capacity to navigate logical topology changes (due to faults, errors, etc.) in real time to resolve service interdependencies towards a defined 'goal state'. Extremely powerful, with a huge library of 'OCF resource agents' (service definitions) already written.[0] However, it also uses the 'agent on each machine' architecture. Where a small number of services are deployed at large scale in a parallel configuration I believe an agentless configuration methodology with PXE and IPMI power control is a more efficient node management path, though it obviously negatively impacts HA. PS. 'Features' like rollback and 'hotfix' are arguably negligible if you have a reasonable service build process incorporating versioning. [0] https://github.com/ClusterLabs/resource-agents

se it doesn't. This is another reason why a proven, general solution is great to have ... you actually get an operations process that handles the extremely common but swept under the rug edge cases that nobody wants to talk about, like upgrades, disk failures, oops I unplugged the cable/DDoS/network fabric issues, horizontal scaleout, appropriate rules for (non-)co-habitation with other services, for all services! Yes, TMTOWTDI, but I seriously doubt some random daemon knows better how to handle failure than a proven, daemon-agnostic operations process designed at a significantly more abstract, resource-oriented level. Have you had a look at the OCF format resource agents? If you define one, you can wash your hands of the whole issue: https://github.com/ClusterLabs/resource-agents/ I don't understand why "authoritative replicas" demand a few seconds of downtime? I find that most daemons, assuming they fsync() appropriately, come up again in well under a second using a dual master (live, standby) setup with DRBD (essentially network RAID1, works with any filesystem) with zero client reconfiguration required by using a shared (floating) IP to handle failover. Check it out.