<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">We've used ceph to address the storage requirement in small clouds pretty well. it works pretty well with only two storage nodes with replication set to 2, and because of the radosgw,
 you can share your small amount of storage between the object store and the block store avoiding the need to overprovision swift-only or cinder-only to handle usage unknowns. Its just one pool of storage.<br>
<br>
Your right, using lvm is like telling your users, don't do pets, but then having pets at the heart of your system. when you loose one, you loose a lot. With a small ceph, you can take out one of the nodes, burn it to the ground and put it back, and it just
 works. No pets.<br>
<br>
Do consider ceph for the small use case.<br>
<br>
Thanks,<br>
Kevin<br>
<br>
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF821369"><font color="#000000" face="Tahoma" size="2"><b>From:</b> Robert Starmer [robert@kumul.us]<br>
<b>Sent:</b> Monday, February 08, 2016 1:30 PM<br>
<b>To:</b> Ned Rhudy<br>
<b>Cc:</b> OpenStack Operators<br>
<b>Subject:</b> Re: [Openstack-operators] RAID / stripe block storage volumes<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">Ned's model is the model I meant by "multiple underlying storage services".  Most of the systems I've built are LV/LVM only,  a few added Ceph as an alternative/live-migration option, and one where we used Gluster due to size.  Note that the
 environments I have worked with in general are small (~20 compute), so huge Ceph environments aren't common.  I am also working on a project where the storage backend is entirely NFS...
<div><br>
</div>
<div>And I think users are more and more educated to assume that there is nothing guaranteed.  There is the realization, at least for a good set of the customers I've worked with (and I try to educate the non-believers), that the way you get best effect from
 a system like OpenStack is to consider everything disposable. The one gap I've seen is that there are plenty of folks who don't deploy SWIFT, and without some form of object store, there's still the question of where you place your datasets so that they can
 be quickly recovered (and how do you keep them up to date if you do have one).  With VMs, there's the concept that you can recover quickly because the "dataset" e.g. your OS, is already there for you, and in plenty of small environments, that's only as true
 as the glance repository (guess what's usually backing that when there's no SWIFT around...).</div>
<div><br>
</div>
<div>So I see the issue as a holistic one. How do you show operators/users that they should consider everything disposable if we only look at the current running instance as the "thing"   Somewhere you still likely need some form of distributed resilience (and
 yes, I can see using the distributed Canonical, Centos, RedHat, Fedora, Debian, etc. mirrors as your distributed Image backup but what about the database content, etc.).</div>
<div><br>
</div>
<div>Robert</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Feb 8, 2016 at 1:44 PM, Ned Rhudy (BLOOMBERG/ 731 LEX)
<span dir="ltr"><<a href="mailto:erhudy@bloomberg.net" target="_blank">erhudy@bloomberg.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div>
<div style="white-space:pre-wrap; font-size:small; font-family:'Courier New',Courier; color:rgb(0,0,0)">
In our environments, we offer two types of storage. Tenants can either use Ceph/RBD and trade speed/latency for reliability and protection against physical disk failures, or they can launch instances that are realized as LVs on an LVM VG that we create on top
 of a RAID 0 spanning all but the OS disk on the hypervisor. This lets the users elect to go all-in on speed and sacrifice reliability for applications where replication/HA is handled at the app level, if the data on the instance is sourced from elsewhere,
 or if they just don't care much about the data.
<div><br>
</div>
<div>There are some further changes to our approach that we would like to make down the road, but in general our users seem to like the current system and being able to forgo reliability or speed as their circumstances demand.</div>
<div style="font-size:small; font-family:'Courier New',Courier; color:rgb(0,0,0)">
<br>
<div>
<div>From: <a href="mailto:joe@topjian.net" target="_blank">joe@topjian.net</a> </div>
<div>Subject: Re: [Openstack-operators] RAID / stripe block storage volumes<br>
</div>
</div>
<div>
<div class="h5">
<div style="color:black; font-family:Arial,'BB.Proportional'; font-size:small; white-space:normal; background:white">
<div>
<blockquote>
<div dir="ltr">Hi Robert,
<div><br>
</div>
<div>Can you elaborate on "multiple underlying storage services"?</div>
<div><br>
</div>
<div>The reason I asked the initial question is because historically we've made our block storage service resilient to failure. Historically we also made our compute environment resilient to failure, too, but over time, we've seen users become more educated
 to cope with compute failure. As a result, we've been able to become more lenient with regard to building resilient compute environments.</div>
<div><br>
</div>
<div>We've been discussing how possible it would be to translate that same idea to block storage. Rather than have a large HA storage cluster (whether Ceph, Gluster, NetApp, etc), is it possible to offer simple single LVM volume servers and push the failure
 handling on to the user? </div>
<div><br>
</div>
<div>Of course, this doesn't work for all types of use cases and environments. We still have projects which require the cloud to own most responsibility for failure than the users. </div>
<div><br>
</div>
<div>But for environments were we offer general purpose / best effort compute and storage, what methods are available to help the user be resilient to block storage failures?</div>
<div><br>
</div>
<div>Joe</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Feb 8, 2016 at 12:09 PM, Robert Starmer <span dir="ltr">
<<a href="mailto:robert@kumul.us" target="_blank">robert@kumul.us</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">I've always recommended providing multiple underlying storage services to provide this rather than adding the overhead to the VM.  So, not in any of my systems or any I've worked with.
<div><br>
</div>
<div>R<br>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">
<div>
<div>On Fri, Feb 5, 2016 at 5:56 PM, Joe Topjian <span dir="ltr"><<a href="mailto:joe@topjian.net" target="_blank">joe@topjian.net</a>></span> wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<div>
<div>
<div dir="ltr">
<div>Hello,</div>
<div><br>
</div>
<div>Does anyone have users RAID'ing or striping multiple block storage volumes from within an instance?<br>
</div>
<div><br>
</div>
<div>If so, what was the experience? Good, bad, possible but with caveats?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Joe</div>
</div>
<br>
</div>
</div>
_______________________________________________<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>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
<div style="width:500px; font-style:oblique; margin:14px; margin-left:0px; padding-top:4px; border-top:1px dotted black">
</div>
<pre>_______________________________________________
OpenStack-operators mailing list
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a>
<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>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<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" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>