<div dir="ltr">I think the answer is:  It depends.  Echoing Warren's experience below, we've also seen extraordinarily high load averages on our OSD nodes during certain recovery scenarios with Ceph.  Putting instances on there would simply not be viable under such circumstances.<div><br></div><div>Ceph's documentation was recently(-ish) updated to say that "[..] during recovery they [OSDs] need significantly more RAM (e.g., ~1GB per 1TB of storage per daemon).".  On nodes where you have multiple 4TB drives provisioned (for example) it's easy to chew through all available memory leaving precious little available for anything else.</div><div><br></div><div>But of course, if you were to build your converged compute / storage nodes with smaller amounts of disk per daemon, use only SSDs, and ensure there's plenty of memory left over after taking into consideration the above calculation then the answer becomes 'maybe'.<div><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>-- </div><div><br>-Nick<br></div></div></div></div>
<br><div class="gmail_quote">On 19 March 2015 at 19:07, Warren Wang <span dir="ltr"><<a href="mailto:warren@wangspeed.com" target="_blank">warren@wangspeed.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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<span class="HOEnZb"><font color="#888888"><br></font></span></div></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div>Warren</div></div></font></span><div><div class="h5">
<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" target="_blank">jlk@bluebox.net</a>]<br>
Sent: Thursday, March 19, 2015 9:20 AM<br>
To: <a href="mailto:openstack-operators@lists.openstack.org" target="_blank">openstack-operators@lists.openstack.org</a><br>
Subject: Re: [Openstack-operators] Hyper-converged OpenStack with Ceph<br>
<div><div><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" target="_blank">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" target="_blank">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></div></div>
<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></blockquote></div><br></div>

<br>
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">DataCentred Limited registered in England and Wales no. 05611763</span>