Forum
Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC:

What are the implications of DRBD Single-Primary? 7 years 10 months ago #823

  • Sean Nelson
  • Sean Nelson's Avatar Topic Author
  • Offline
  • Posts: 3
I apologize if this has been discussed before. It seems to be a very fundamental concept, but I haven't been able to find much discussion on it.

DRBD runs in a Single-Primary mode, right? I am having a hard time finding a definitive answer to what that means. Intuitively, I would assume that means if Host A is Primary and Host B is secondary, only the changes written to host A will be kept.

In that case, what happens if, in XenCenter, I right-click a VM and tell it to move to Host B? Does that mean all changes written to Host B will now be lost?

Do all of my VMs need to be located on a single host? Or does DRBD have some logic that allows the secondary to overwrite the primary with newer data when they have not been split?

Please Log in or Create an account to join the conversation.

Last edit: by Sean Nelson. Reason: Mixed up A and B

What are the implications of DRBD Single-Primary? 7 years 10 months ago #826

  • Salvatore Costantino
  • Salvatore Costantino's Avatar
  • Offline
  • Posts: 722
In a dual primary mode (which we are not), you can freely write to both DRBD resources simultaneously. It is expected that your applications have some form of locking logic in place so that your applications don't write to the same portions of both disks which would likely trash your data. Dual primary is considered to be a bit dangerous.

In single primary mode, applications (XenServer and its underlying VMs in our case) can only write to the primary. The secondary device is simply a real time replica of the primary. The 2 node HA-Lizard cluster logic does not directly expose the primary device to XenServer (as would be the case with traditional local storage). Instead, we expose the primary resource to XenServer as an iSCSI target. As far as XenServer is concerned, it thinks it is connected to an external iSCSI SAN. Layered on top of that is the ability to quickly swap roles and move the iSCSI target IP freely between the hosts so that XenSever never really knows which storage it is connected to.

Given all of this, you can freely move VMs between hosts and run VMs on both hosts with NO restrictions (there is no need to run VMs on a single host).

The only thing to consider is that the VMs running on the XenServer master would have slightly better read/write performance than VMs running on the slave. Performance on the Master is about the same as you would get with local storage - which is very good.
The following user(s) said Thank You: Sean Nelson

Please Log in or Create an account to join the conversation.

What are the implications of DRBD Single-Primary? 7 years 10 months ago #828

  • Sean Nelson
  • Sean Nelson's Avatar Topic Author
  • Offline
  • Posts: 3
Excellent response. Thank you! So, just to be sure I understand correctly. If a VM on the secondary host writes a bit to its storage, hosted on the DRBD system, the bit would first traverse the network, get written to the storage primary (which owns the storage IP at the moment), then DRBD would sync it back over the network to get written to storage secondary?

Please Log in or Create an account to join the conversation.

Last edit: by Sean Nelson.

What are the implications of DRBD Single-Primary? 7 years 10 months ago #829

  • Salvatore Costantino
  • Salvatore Costantino's Avatar
  • Offline
  • Posts: 722
Yes - precisely as you described it.
The following user(s) said Thank You: Sean Nelson

Please Log in or Create an account to join the conversation.

  • Page:
  • 1