[OpenStack-docs] [ha-guide] Observations from mid-cycle ops meetup

Matt Kassawara mkassawara at gmail.com
Thu Mar 12 23:33:49 UTC 2015


Ceph definitely has a following, but I don't recall specific conversation
around redundant storage. Similar to physical network redundancy, I wonder
if we should simply mention storage redundancy options rather than attempt
to support a particular variant... especially if all of them lean toward a
vendor.

On Thu, Mar 12, 2015 at 4:58 PM, Meg McRoberts <dreidellhasa at yahoo.com>
wrote:

> Thanks, Matt -- this is very helpful.
>
> What about storage?  It seems like Ceph as the storage back-end provides
> much better data protection
> than the alternatives.  Did you sense a movement towards adapting Ceph or
> are people clinging to LVM,
> etc?
>
>   ------------------------------
>  *From:* Matt Kassawara <mkassawara at gmail.com>
> *To:* "openstack-docs at lists.openstack.org" <
> openstack-docs at lists.openstack.org>
> *Sent:* Thursday, March 12, 2015 1:44 PM
> *Subject:* [OpenStack-docs] [ha-guide] Observations from mid-cycle ops
> meetup
>
> I went to the mid-cycle ops meeting for a better idea of the HA methods
> implemented by operators. Most seem to agree on Galera with MariaDB/MySQL,
> RabbitMQ active-passive/active-active (some using a load balancer and
> others configuring services to use each node directly), Memcached
> active/active (via Oslo hash synchronization), and OpenStack APIs via
> hardware or HAProxy load balancer. On the other hand, networking drifted
> all over the place. Some people live and die by nova-net and won't move to
> neutron until it 100% mirrors the multi-host functionality with
> fixed/floating IP addresses, others use neutron but only with provider
> networks, most don't quite trust DVR/L3HA yet, and a few implement custom
> code with nova-net or neutron. For networking in the HA guide, I mostly
> suggest referencing the networking guide scenarios rather than suggesting a
> particular architecture. However, we should also mention them in the
> introduction somewhere because different architectures may impact the
> minimum number and type of nodes.
>
> _______________________________________________
> OpenStack-docs mailing list
> OpenStack-docs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20150312/60e40c7f/attachment.html>


More information about the OpenStack-docs mailing list