Thanks guys for the explanation :) Anthony D'Atri <anthony.datri@xxxxxxxxx> 于2022年1月28日周五 02:52写道: > Agreed. > > I’ve been in a situation where I wasn’t able to stock spare chassis > because of ostensible 2-hour turnaround from vendor support. Which was > actually 2 hours *from when they agreed to replace/repair*, and if the > local depot happened to have parts. One of my clusters as a result was > down 2 mons for >wince< 18 months. Hopefully most production deployments > will have better strategies, but it does reinforce Frank’s point. > > Beyond 5 one is into diminishing returns. At an OpenStack Summit a > handful of years ago a number of Ceph operators gathered, and mon count was > discussed. The consensus was that more than 5 was overkill at best, and > that the increased inter-mon traffic wasn’t worth it. ymmv. > > > > On Jan 27, 2022, at 5:34 AM, Frank Schilder <frans@xxxxxx> wrote: > > > > In addition to the workload distribution, the number of mons will also > determine how resilliant your system is towards admin mistakes. With 5 > mons, you can do service on 1 and loose and additional one without loosing > service. I have been there and would not operate a production cluster with > less than 5 MONs. > > > > The level of redundancy decides in how deep trouble you can allow > yourself to get into without loosing service. Minimum requirements only > work well in nice weather. > > _______________________________________________ > ceph-users mailing list -- ceph-users@xxxxxxx > To unsubscribe send an email to ceph-users-leave@xxxxxxx > _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx