You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

59 lines
2.8 KiB

This project is a (c)go iscsi library, with the eventual aim of implementing a
"hydra" iSCSI implementation.
An hydra is an iSCSI target that, internally, takes requests and mirrors them
across multiple *real* iSCSI targets, with the aim of ensuring redundancy and
fault tolerance. The hydra (or Very Clever Proxy, as we could also call it) is
intended to be run on the same host as the iSCSI initiator (qemu, say) to
insulate the guest against the vagaries of disc failures, targets going away for
any reason, etc, etc.
This is being created specifically with redundant, fault-tolerant remote virtual
discs in mind, so performance and reliability are key. Looks like this:
* Minimal iSCSI target implementation
- This should contain as few features as we can get away with, and is what
qemu will connect to - ideally over localhost (iscsi doesn't seem to
support UNIX sockets or I'd use those)
* Complete iSCSI initiator implementation
- This needs to support as much of iSCSI as possible, and certainly
everything both QEMU and common real targets support
- Bindings to libiscsi are the way forward here
* Very Clever Proxy
- Takes a list of targets to keep in sync
- Runs the minimal target implementation
- Runs initiators for each of the real targets
- Proxies requests between local and remote targers, maintaining consistency
- Allows real targets to be swapped out for blanks that are then initialised
from the remaining targets
- One broken real target doesn't stall I/O for the real initiator
- Metadata is stored in reserved space on the real targets, and used to
ensure consistency if the Very Clever Proxy is killed at any stage and
brought back up on a different machine
- If a real target disconnects and then reconnects within a given window, it
can be brought back to consistency without reinitialising the whole disc
- Resizing is supported
+ On resize down, the resize is propagated to the real initiator as soon
as the first real target has announced its new size
+ On resize up, the resize is only propagated once all real targets have
announced a new size, and the propagated size is the smallest size they
all have in common
- The real initiator can submit requests asynchronously and have them dealt
with asynchronously
- Writes to the real targets happen concurrently, not serially, to avoid
multiplying write latency by the number of real targets
- Must be able to bind to a specific IP[4|6] address to enable IP-based ACLs
- Zero-copy, or as close to it as possible.
- Hides the first 1MiB of each real target for metadata to support the above
+ Hiding the end would be problematic on resizes
+ 1MiB is a complete crapshoot, 4KiB might be enough. Check.