At Overstock we do both, in different clouds. Our preferred option is a Ceph backend for Nova ephemeral storage. We like it because it is fast to boot and makes resize easy. Our use case doesn’t require snapshots nor do we have a need for keeping the data around if a server needs to be rebuilt. It may not work for other people, but it works well for us.
In some of our other clouds, where we don’t have Ceph available, we do use Cinder volumes for booting VMs off of backend SAN services. It works ok, but there are a few painpoints in regard to disk resizing - it’s a bit of a cumbersome process compared the experience with Nova ephemeral. Depending on the solution used, creating the volume for boot can take much much longer and that can be annoying. On the plus side, Cinder does allow you to do QOS to limit I/O, whereas I do not believe that’s an option with Nova ephemeral. And, again depending on the Cinder solution employed, the disk I/O for this kind of setup can be significantly better than some other options including Nova ephemeral with a Ceph backend. Bottom line: it depends what you need, as both options work well and there are people doing both out there in the wild. Good luck! On Aug 1, 2017, at 9:14 AM, John Petrini <jpetr...@coredial.com<mailto:jpetr...@coredial.com>> wrote: Just my two cents here but we started out using mostly Ephemeral storage in our builds and looking back I wish we hadn't. Note we're using Ceph as a backend so my response is tailored towards Ceph's behavior. The major pain point is snapshots. When you snapshot an nova volume an RBD snapshot occurs and is very quick and uses very little additional storage, however the snapshot is then copied into the images pool and in the process is converted from a snapshot to a full size image. This takes a long time because you have to copy a lot of data and it takes up a lot of space. It also causes a great deal of IO on the storage and means you end up with a bunch of "snapshot images" creating clutter. On the other hand volume snapshots are near instantaneous without the other drawbacks I've mentioned. On the plus side for ephemeral storage; resizing the root disk of images works better. As long as your image is configured properly it's just a matter of initiating a resize and letting the instance reboot to grow the root disk. When using volumes as your root disk you instead have to shutdown the instance, grow the volume and boot. I hope this help! If anyone on the list knows something I don't know regarding these issues please chime in. I'd love to know if there's a better way. Regards, John Petrini On Tue, Aug 1, 2017 at 10:50 AM, Kimball, Conrad <conrad.kimb...@boeing.com<mailto:conrad.kimb...@boeing.com>> wrote: In our process of standing up an OpenStack internal cloud we are facing the question of ephemeral storage vs. Cinder volumes for instance root disks. As I look at public clouds such as AWS and Azure, the norm is to use persistent volumes for the root disk. AWS started out with images booting onto ephemeral disk, but soon after they released Elastic Block Storage and ever since the clear trend has been to EBS-backed instances, and now when I look at their quick-start list of 33 AMIs, all of them are EBS-backed. And I’m not even sure one can have anything except persistent root disks in Azure VMs. Based on this and a number of other factors I think we want our user normal / default behavior to boot onto Cinder-backed volumes instead of onto ephemeral storage. But then I look at OpenStack and its design point appears to be booting images onto ephemeral storage, and while it is possible to boot an image onto a new volume this is clumsy (haven’t found a way to make this the default behavior) and we are experiencing performance problems (that admittedly we have not yet run to ground). So … • Are other operators routinely booting onto Cinder volumes instead of ephemeral storage? • What has been your experience with this; any advice? Conrad Kimball Associate Technical Fellow Chief Architect, Enterprise Cloud Services Application Infrastructure Services / Global IT Infrastructure / Information Technology & Data Analytics conrad.kimb...@boeing.com<mailto:conrad.kimb...@boeing.com> P.O. Box 3707, Mail Code 7M-TE Seattle, WA 98124-2207 Bellevue 33-11 bldg, office 3A6-3.9 Mobile: 425-591-7802<tel:(425)%20591-7802> _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ________________________________ CONFIDENTIALITY NOTICE: This message is intended only for the use and review of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message solely to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify sender immediately by telephone or return email. Thank you.
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
