openstack team mailing list archive

[Tom Ellis <tom.ellis@xxxxxxxxxxxxx>]

On 16/02/12 08:46, i3D.net - Tristan van Bokkem wrote:
> Any more thoughts about this subject? Ask? Vish?

The team I work in has looked at a number of methods for high
availability within the Diablo release and I've included some notes
below, hope this helps.

Font-end API servers
 * load balanced with h/w load balancer
 * use s/w LB for smaller deployments
 * run nova-scheduler on each

MySQL DB
 * multi-master configuration
 * alternative: drbd + pacemaker in active/passive

RabbitMQ service
 * Pacemaker with Active-passive configuration
 * Based on example from RabbitMQ site (already mentioned by someone else)
 * Virtual IP for the service - used for rabbitmq config in nova.conf
 * I think there are some corner cases where messages could be dropped
during failover and I believe later RabbitMQ versions support full
multi-master but require some client side changes - is there any plans
to support this?

nova-volume service
 * Current weakness in the HA setup, unless you are willing to use iscsi
tgtd with DRBD. I believe this would still have some problems when
failing over with the initiators that are logged in.
 * I'm hoping this will pan out for essex with some of the storage
vendors committing nova-volume support via their API's.

Glance
  * Run on multiple servers
  * Use another VIP in your pacemaker setup or load-balancer
  * Use swift as backend storage

Compute servers
 * Each run their own copy of nova-api (only instances running on the
node use this)
 * nova-network (multi-host configuration) with private network

Swift
 * Run swift-proxy across all swift-storage nodes on a small setup


Regards,

Tom