Thank you Christian, That comforts me in what I was thinking about the MONs, I will resize them though, according to your advices and Paul's.
Regards, Adrien On Tue, Jul 7, 2015 at 6:18 AM, Christian Balzer <[email protected]> wrote: > > Hello, > > On Sun, 5 Jul 2015 16:17:20 +0000 Paul Evans wrote: > > > On Jul 4, 2015, at 2:44 PM, Adrien Gillard > > <[email protected]<mailto:[email protected]>> wrote: > > > > Lastly, regarding Cluster Throughput: EC seems to require a bit more > > CPU and memory than straight replication, which begs the question of how > > much RAM and CPU are you putting into the chassis? With proper amounts, > > you should be able to hit your throughput targets,. Yes, I have read > > about that, I was thinking 64 GB of RAM (maybe overkill, even with the > > 1GB of RAM per TB ? but I would rather have an optimal RAM configuration > > in terms of DIMM / channels / CPU) and 2x8 Intel cores per host (around > > 2Ghz per core). As the cluster will be used for backups, the goal is not > > to be limited by the storage backend during the backup window overnight. > > I do not expect much load during daytime. > > > > 64G is “OK” provided you tune the system well and DON”T add extra > > services onto your OSD nodes. If you’ll also have 3 of them acting as > > MONs, more memory is advised (probably 96-128G). > > > MONs don't need much in terms of memory. Certainly not 32GB. > What they do need is a moderate amount of CPU, so if those nodes can get > CPU bound by doing OSD work, maybe some pinning might be required. > And what they REALLY need is fast IO for their levelDBs and logs. > > > At the moment I am planning to have a smaller dedicated node for the > > master monitor ( ~ 8 cores, 32G RAM, SSD) and virtual machines for MON 2 > > and 3 (with enough resources and virtual disk on SSD) > > > > > > It would be good to have others comment on the practicality of this > > design, as I don’t believe there is a benefit to having a single MON > > that is ‘better' than the other two. My reasoning comes from a limited > > understanding of the Paxos implementation within Ceph, which suggests > > that a majority of MONs must be available at all times (i.e. - 2 of the > > 3), and that MON activities will be processed according to the speed of > > the slowest quorum member. If two of the MONs are running as VMs on OSD > > hosts, and you have a write-heavy workload, I can foresee some > > interesting resource contention issues that might sometimes destabilize > > your entire cluster. YMMV. > > > Even the least capable MON needs to be able to do the job, indeed. > However I'd still give the main MON more resources and faster/more durable > SSDs than the others, as it will by default do most of the work (and more > than the secondary ones). > > Regards, > > Christian > -- > Christian Balzer Network/Systems Engineer > [email protected] Global OnLine Japan/Fusion Communications > http://www.gol.com/ > -- ----------------------------------------------------------------------------------------- Adrien GILLARD +33 (0)6 29 06 16 31 [email protected]
_______________________________________________ ceph-users mailing list [email protected] http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
