I would like to have a clarification on the thin machines configuration you are envisioning: you are considering having a driver on it so the client can fall back to it, should the main driver fail. I am assuming that there would also be at least one node running on that thin machine, connected to the corresponding driver, is that correct?
This is definitely a point that we have not worked on so far, we only have discussed it. Currently, clients can only connect to one driver, which creates a single point of failure from the client's point of view. This is not acceptable, and I am making it one of our priorities for the short term, which means I am committing to implement a set of features that will take care of this, and include it in our next release.
Now, let's create the major requirements, as a foundation for this feature:
- a client should be able to connect to multiple drivers
- a client should be able to prioritize the drivers it is connected to, the priority constituting an ordering for the drivers the client falls back to.
example: if a driver with an assigned priority of 2 fails, the client should fall back to the available driver with the highest priority
- drivers with the same priority should be used as a pool to further parallelize and distribute the work submitted by the client
Please let me know if that would fulfill your requirements, and feel free to add to or correct what we said.
For the record, I have added the following feature request:
"Clients only connect to one driver
Feel free to consult or update it.