164 reputation
19
bio website tavendo.de
location Erlangen, Germany
age
visits member for 2 years, 11 months
seen Mar 23 at 7:14

I am founder of Tavendo, a mobile/cloud startup. Currently our main project is Autobahn WebSockets - Asynchronous RPC/PubSub over WebSockets.


Aug
31
asked IPv6 autoconfiguration with multiple interfaces
Aug
21
comment ZFS over iSCSI high-availability solution
Its even more tricky. I am using a test setup of 2 storage VMs and 2 database VMs all FreeBSD9. Created a 2-way mirrored pool over LUNs from the 2 storage nodes. I could verify resilvering after a storage node was gone and reappeared. However: I needed to kill iscontrol on the database node for the left storage node. Without doing that iscontrol tries to silently reconnect forever. It only does start doing so after access of the ZFS pool. But as long as it retries any ZFS pool command just hangs. Need to do more experiments. Can I run iscontrol without it daemonizing itself?
Aug
21
awarded  Supporter
Aug
21
comment ZFS over iSCSI high-availability solution
Periodically running zpool status, ok. But there is nothing "event driven"? Is there a ZFS Dtrace provider that could emit events like a failed disk? Regarding zpool import: so all the info needed to recreate a pool is stored within the vdevs (and with vdev mirror, hence redundently)? No info from the host (which may have died completely) is needed?
Aug
21
comment ZFS over iSCSI high-availability solution
Thanks for pointing to HAST! Using HAST would be quite similar: redundancy above storage nodes holding physical disks and below the database replication level. But HAST only supports 2 nodes, only 1 can be active. ZFS mirror supports also 3 storage nodes and can use all for read ops increasing throughput. HAST uses CARP .. additional complexity. As to the architecture being unusal: you are probably right, I am wondering why? Creating ZFS vdevs over SAN LUNs seem to be even recommended: hub.opensolaris.org/bin/view/Community+Group+zfs/…
Aug
21
comment ZFS over iSCSI high-availability solution
The main reason: with a "standard" architecture where ZFS RAID would be used over local physical disks and only that exported as iSCSI LUNs, there needs to be additional redundancy to protect against failures of complete storage nodes. In other words, in our case, database replication. And that is complex also. Why is it unwise?
Aug
21
awarded  Student
Aug
21
asked ZFS over iSCSI high-availability solution