<div dir="ltr"><div>Thanks for the responses Eugen and Sean!</div><div><br></div><div>The placement.yaml approach sounds good if it can prevent the compute host from reporting local_gb repeatedly, and then as you suggested use Placement Aggregates I can perhaps make that work for a subset of use cases. Too bad it is only available on Victoria+. I was looking for something that could work, even if partially, on Queens and Stein.</div><div><br></div><div>The cron job updating the reservation, I'm not sure if it will clash with the host updates (being overriden, as I've described in the LP bug), but you actually gave me another idea. I may be able to create a fake allocation in the nodes to cancel out their reported values, and then rely only on the shared value through placement.</div><div><br></div><div>Monitoring Ceph is only part of the problem. The second part, if you end up needing it (and you may if you're not very conservative in the monitoring parameters and have unpredictable workload) is to prevent new instances from being created, thus new data from being stored, to prevent it from filling up before you can react to it (think of an accidental DoS attack by running a certain storage-heavy workloads).</div><div><br></div><div>@Eugen, yes. I was actually looking for more reliable ways to prevent it from happening.</div><div><br></div><div>Overall, the shared placement + fake allocation sounded like the cleanest workaround for me. I will try that and report back.<br></div><div><br></div><div>Thanks for the help!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 6, 2021 at 10:57 AM Eugen Block <<a href="mailto:eblock@nde.ag">eblock@nde.ag</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
we're using OpenStack with Ceph in production and also have customers  <br>
doing that.<br>
 From my point of view fixing nova to be able to deal with shared  <br>
storage of course would improve many things, but it doesn't liberate  <br>
you from monitoring your systems. Filling up a ceph cluster should be  <br>
avoided and therefore proper monitoring is required.<br>
<br>
I assume you were able to resolve the frozen instances?<br>
<br>
Regards,<br>
Eugen<br>
<br>
<br>
Zitat von Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>>:<br>
<br>
> On Tue, 2021-01-05 at 14:17 -0300, Rodrigo Barbieri wrote:<br>
>> Hi Nova folks and OpenStack operators!<br>
>><br>
>> I have had some trouble recently where while using the "images_type = rbd"<br>
>> libvirt option my ceph cluster got filled up without I noticing and froze<br>
>> all my nova services and instances.<br>
>><br>
>> I started digging and investigating why and how I could prevent or<br>
>> workaround this issue, but I didn't find a very reliable clean way.<br>
>><br>
>> I documented all my steps and investigation in bug 1908133 [0]. It has been<br>
>> marked as a duplicate of 1522307 [1] which has been around for quite some<br>
>> time, so I am wondering if any operators have been using nova + ceph in<br>
>> production with "images_type = rbd" config set and how you have been<br>
>> handling/working around the issue.<br>
><br>
> this is indeed a know issue and the long term plan to fix it was to  <br>
> track shared storae<br>
> as a sharing resouce provide in plamcent. that never happend so  <br>
> there si currenlty no mechanium<br>
> available to prevent this explcitly in nova.<br>
><br>
> the disk filter which is nolonger used could prevnet the boot of a   <br>
> vm that would fill the ceph pool but<br>
> it could not protect against two concurrent request form filling the pool.<br>
><br>
> placement can protect against that due to the transational nature of  <br>
> allocations which serialise<br>
> all resouce useage however since each host reports the total size of  <br>
> the ceph pool as its local storage that wont work out of the box.<br>
><br>
> as a quick hack what you can do is set the  <br>
> [DEFAULT]/disk_allocation_ratio=(1/number of compute nodes)<br>
> <a href="https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.disk_allocation_ratio" rel="noreferrer" target="_blank">https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.disk_allocation_ratio</a><br>
> on each of your compute agents configs.<br>
><br>
><br>
> that will prevent over subscription however it has other negitve sidefects.<br>
> mainly that you will fail to scudle instance that could boot if a  <br>
> host exced its 1/n usage<br>
> so unless you have perfectly blanced consumtion this is not a good approch.<br>
><br>
> a better appoch but one that requires external scripting is to have  <br>
> a chron job that will update the resrved<br>
>  usaage of each of the disk_gb inventores to the actull amount of of  <br>
> stoarge allocated form the pool.<br>
><br>
> the real fix however is for nova to tack its shared usage in  <br>
> placment correctly as a sharing resouce provide.<br>
><br>
> its possible you might be able to do that via the porvider.yaml file<br>
><br>
> by overriding the local disk_gb to 0 on all comupte nodes<br>
> then creating a singel haring resouce provider of disk_gb that  <br>
> models the ceph pool.<br>
><br>
> <a href="https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/provider-config-file.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/provider-config-file.html</a><br>
> currently that does not support the addtion of providers to placment  <br>
> agggreate so while it could be used to 0 out the comptue node<br>
> disk inventoies and to create a sharing provider it with the  <br>
> MISC_SHARES_VIA_AGGREGATE trait it cant do the final step of mapping<br>
> which compute nodes can consume form sharing provider via the  <br>
> agggrate but you could do that form.<br>
> that assume that "sharing resouce provdiers" actully work.<br>
><br>
><br>
> bacialy what it comes down to today is you need to monitor the  <br>
> avaiable resouce yourslef externally and ensure you never run out of  <br>
> space.<br>
> that sucks but untill we proably track things in plamcent there is  <br>
> nothign we can really do.<br>
> the two approch i suggested above might work for a subset of  <br>
> usecasue but really this is a feature that need native suport in  <br>
> nova to adress properly.<br>
><br>
>><br>
>> Thanks in advance!<br>
>><br>
>> [0] <a href="https://bugs.launchpad.net/nova/+bug/1908133" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1908133</a><br>
>> [1] <a href="https://bugs.launchpad.net/nova/+bug/1522307" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1522307</a><br>
>><br>
<br>
<br>
<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Rodrigo Barbieri<div>MSc Computer Scientist</div><div>OpenStack Manila Core Contributor</div><div>Federal University of São Carlos</div><div><br></div></div></div></div></div></div></div></div>