A feladatnak szerintem több megoldása van.
A legegyszerűbb nyilván az, hogy egy ilyen aktív dobozod van, minden forgalom átmegy rajta, az igazi targetek felé pedig egy egyszerű CDB FIFO-t vezetsz a módosítási műveletekről, az olvasási műveleteket meg load balance-olod (figyelembe véve persze az írási queue állapotát).
Ha az egyik target megdöglik, a queue telik, ha visszajön, elkezded ráírni a módosításokat, és ha szinkronban van, már olvasni is tudsz róla (illetve addig is, ha a queue-t is figyelembe veszed).
Eddig ugye ez a proxy lesz a SPoF a storage helyett, de azért itt IP szinten sok lehetőséged van játszani, failovert viszonylag egyszerűen fogsz tudni csinálni, mindössze azt kell eldöntened, hogy milyen rendelkezésre állási és megbízhatósági garanciát akarsz adni. Lényegében a gépek állapotát és a queue-t kell jól szinkronizálni, ez elég gyakori feladat, nem storage jellegű.
Ha fontos (márpedig nyilván az) a rendelkezésre állás és az adatbiztonság is, pld. egy három gépes clustert tudnék ide elképzelni, ami az írásokat akkor igazolja vissza az initiatornak, amikor legalább két gépen stable storage-on van a cucc. RAID5 proxy, egy gép kieshet. :)
Ha tudod garantálni, hogy a forgalom mindig csak az aktív node-ra érkezzen, kész is van a SPoF-mentes dzsunkastorage szinkronizáló cucc, amivel vmware alá tudsz szarból várat építeni. (nyilván vannak még aspektusai a dolognak, amiket kezelni kell)
Szerintem ezt kb. egy hét alatt összelegóznám neked tesztpadon valami scriptnyelvben. Te profibb vagy, neked már gyors is lenne ennyi idő alatt. :)
Ilyen blokkokat elég jól fogsz tudni load balance-olni is, pld. target LUN-onként (mondjuk IP címekre mappelve), nem ez lesz a szűk keresztmetszet.
Ami bonyolultabb, az aktív-aktív, de a fenti miatt szerintem ennek az igénynek a létjogosultsága kevés.
--
zsebHUP-ot használok!