<div dir="ltr"><div>I would avoid co-locating Ceph and compute processes. Memory on compute nodes is a scare resource, if you're not running with any overcommit, which you shouldn't. Ceph requires a fair amount (2GB per OSD to be safe) of guaranteed memory to deal with recovery. You can certainly overload memory and reserve it, but it is just going to make things difficult to manage and troubleshoot. I'll give an example. I have 2 Ceph clusters that were experiencing aggressive page scanning and page cache reclaimation under some moderate workload. Enough to drive the load on an OSD server to 4 digits. If that had occurred on a box also running compute resources, we would have had tickets rolling in. However, all we did is slow down some of the storage, so it largely went unnoticed.</div><br>There may also come a time when package dependencies cause conflicts that will be difficult to reconcile. OVS, kernel, Ceph, etc. It's possible to attempt to dedicate resources on a single host to various processes, but I personally don't think it's worth the effort.<br><div><div><br></div>Warren<br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">Warren</div></div>
<br><div class="gmail_quote">On Thu, Mar 19, 2015 at 12:33 PM, Fox, Kevin M <span dir="ltr"><<a href="mailto:Kevin.Fox@pnnl.gov" target="_blank">Kevin.Fox@pnnl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We've running it both ways. We have clouds with dedicated storage nodes, and clouds sharing storage/compute.<br>
<br>
The storage/compute solution with ceph is working ok for us. But, that particular cloud is 1gigabit only and seems very slow compared to our other clouds. But because of the gigabit interconnect, while the others are 40gigabit, its not clear if its slow because of the storage/compute together, or simply because of the slower interconnect. Could be some of both.<br>
<br>
I'd be very curious if anyone else had a feeling for storage/compute together on a faster interconnect.<br>
<br>
Thanks,<br>
Kevin<br>
<br>
________________________________________<br>
From: Jesse Keating [<a href="mailto:jlk@bluebox.net">jlk@bluebox.net</a>]<br>
Sent: Thursday, March 19, 2015 9:20 AM<br>
To: <a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.openstack.org</a><br>
Subject: Re: [Openstack-operators] Hyper-converged OpenStack with Ceph<br>
<div class="HOEnZb"><div class="h5"><br>
On 3/19/15 9:08 AM, Jared Cook wrote:<br>
> Hi, I'm starting to see a number of vendors push hyper-converged<br>
> OpenStack solutions where compute and Ceph OSD nodes are one in the<br>
> same.  In addition, Ceph monitors are placed on OpenStack controller<br>
> nodes in these architectures.<br>
><br>
> Recommendations I have read in the past have been to keep these things<br>
> separate, but some vendors are now saying that this actually works out<br>
> OK in practice.<br>
><br>
> The biggest concern I have is that the compute node functions will<br>
> compete with Ceph functions, and one over utilized node will slow down<br>
> the entire Ceph cluster, which will slow down the entire cloud.  Is this<br>
> an unfounded concern?<br>
><br>
> Does anyone have experience running in this mode?  Experience at scale?<br>
><br>
><br>
<br>
Not CEPH related, but it's a known tradeoff that compute resource on<br>
control nodes can cause resource competition. This is a tradeoff for the<br>
total cost of the cluster and the expected use case. If the use case<br>
plans to scale out to many compute nodes, we suggest upgrading to<br>
dedicated control nodes. This is higher cost, but somewhat necessary for<br>
matching performance to capacity.<br>
<br>
We may start small, but we can scale up to match the (growing) needs.<br>
<br>
<br>
--<br>
-jlk<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>