1

In the university from Uruguay where I work, we have 2 IBM BladeCenter S with 4 server blades each one. Each blade have XenServer 6.2 installed and working.

Our idea is have each BladeCenter in different builds (connected) to have failover.

Each BladeCenter chassis, have fibre channel storage embedded in the chassis and, a priori, I don't find how to share this storage to the other BladeCenter chassis.

Also, I know the shared storage way isn't the best, because it implements a single point of fail...

So, I need to find a way to do high availability with XenServer 6.2, without shared storage. I found http://www.halizard.com/, but I want to know other alternatives to have HA without shared storage.

The other thing I can think of, is if I could mirror the storages by network (with iSCSI), and multipath the iSCSI targets as 1, or have multipathing iSCSI and Fibre Channel (but I don't know if this exists). If this is possible, the XenServer HA implementation will work.

Hope we can help me!

ddave
  • 11
  • 1
  • 3

3 Answers3

1

Hi You may try Xen DRBD to achieve HA without shared storage...

http://www.drbd.org/users-guide/ch-xen.html

https://github.com/locatrix/xs-pacemaker

-Asit

Asit
  • 11
  • 2
1

If you an attach enough local storage you can build your own iSCSI HA-solution.

Reiceipe: - drbd > 8.2.x - tgtd

Set up two local VMs that replicate two LVs onto each other in drbd dual primary mode. Use each local iscsi target. In XEN-server make sure to use eacch target in active/passive mode (no rr!).

Nils
  • 7,657
  • 3
  • 31
  • 71
0

When choosing an HA solution, you'll need to decide what level of downtime (if any) is acceptable. This will affect the complexity of your setup.

I think you have two options without purchasing additional equipment (with further permutations):

  1. "Always up" - DRBD in Primary-Primary
  2. 5-15 minutes of downtime - DRBD in Primary-Slave mode

For the highest availability setup without shared storage, you'd have to use DRBD in primary-primary role. This will require a STONITH device to kill off a non-responding node. IP based battery backup devices can generally handle this function efficiently. Pacemaker and corosync can handle bringing up the VMs and managing the resources.

Pros are that you can do live migration and downtime is theoretically eliminated.

The cons of this setup is that if a split-brain happens (it will), it can be difficult to fix since data may exist on both nodes.

Alternatively, if you're okay with a few minutes of downtime, this is what we run:

  • DRBD in Primary-Secondary Role
  • A storage stack of MDADM Raid 1 Array -> LVM -> DRBD -> LVM
  • A script to bring up the resources in case of a fail-over event (admin manually runs this).

Basically, we have two storage LVM pools on top of two MDADM Raid 1 arrays. They're exported to DRBD to do block level replication. Then, you add LVM on top of DRBD to enable snapshots of the VMs and direct filesystem access to the VMs. Why two?

The original idea was to create a DRBD resource for each VM, so that the machines could be moved between hosts depending on load and not have one host sitting idle. Administering it was a pain, so two DRBD resources of 200GB each was a good compromise. That way, r0 can be primary on node1 and r1 can be primary on node2. If node1 fails, we run our "make master" script on node2 and it handles the LVM mappings, setting DRBD primary for those resources and telling virsh to startup all the nodes. On an SSD array, I can bring down a dozen VMs and bring them up on node2 in about 2-3 minutes.

RyanH
  • 327
  • 1
  • 6