Eitan Zahavi wrote:
Well, this is a very old topic well discussed years ago. All credits to
Ashok Raj which you know better then me. The argument against the idea
for the SM to be the keeper of these registrations goes as follows:
Yes - and I still don't understand why this isn't a personal problem of the SM.
Without the use of client re-registration the only way to keep this data
consistent between the master SM and its standby slaves (or across SM
restarts) is by using a transaction safe model.
There are probable other solutions to this problem. Couldn't the data also be
written to a shared file system?
Transaction safe models are well known and require distributed handshake
or journaling systems (in our case distributed ones). Anyway what this
means is that every transaction (like creation of new Service Record or
registering to a multicast group) will have to be first committed and
approved by all standby SMs before it is responded.
This strict transaction safe model is not fitting very well with the
requirement for scalability of the fabric - which is hard to make even
without that complication.
How is this less scalable than every client in the fabric maintaining this data,
detecting failures (if this can be done), and reissuing the requests?
Having standby SMs rely on fabric clients in order to build their database just
seems like the wrong approach. If they actually had an up to data database,
then those SMs could also respond to queries.
- Sean
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
