On Sun, 25 Mar 2012, ruslan usifov wrote: > 2012/3/24 Sage Weil <sage@xxxxxxxxxxxx>: > > On Fri, 23 Mar 2012, ruslan usifov wrote: > >> Sorry for my bad English. > >> > >> I mean that, if throw pacemaker we organize fault tolerant monitor > >> (monitor that will work all time - even in fail case), we prevent > > > > The other key thing to keep in mind is that this is completely unnecessary > > with Ceph. Just run 3 (or 5, or 7, or whatever) monitors, and individual > > ceph-mon failures won't affect the availability. Ceph clients are smart > > enough to find a non-failed monitor, and the cluster manages consistency > > and so forth on it's own. > > > > The whole point is to _avoid_ kludgey proxy/failover solutions like > > this... > > > > sage > > Yes, you right and I agree with you, but if "Ceph clients are smart > enough to find a non-failed monitor" why they not smart to prevent > connect to failed monitor until it fully restore, so now I have > periodical delays when client try to connect to failed monitor, > ?ertainly finally it find live monitor and all work fine, and with > failover i try to solve problem of this delays Ah, I see. There are basically two types of delays to worry about: opening an initial session when one or more monitors may be down, and failing over to another monitor with the one our session is with goes away. For the first case, we can mask that by attempting to open a session with multiple monitors in parallel, and pick whichever succeeds first (or something along those lines). For the failover case, I think it basically comes down to a timeout: the amount of time you are willing to wait for one monitor before trying another (currently it's 3 seconds). Presumably pacemaker (or whatever) has the same type of delay built in? sage
