Re: Antwort: Re: Antwort: Re: Antwort: Re: SBD 1.2.0 / corosync 2.3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



philipp.achmueller@xxxxxx napsal(a):
Philipp,


hi,

thank you for clarification.

i just wanted to test storage based fencing.
May i have to reconsider about using storage based fencing, but since
my
actual fencing method(fence_cisco_ucs) use ip, i'm not 100% sure if
this
is enough to keep my VMs safe.

So you are running multiple VMs (and on them cluster) or cluster of bare
metal machines with VMs (and they are not part of cluster)?

Hi,

yes, 2 baremetal nodes with pacemaker, running several VMs.

Because for first case, it's best to use VMs fencing. For second case,
fence_cisco_ucs is probably best method, because it will simply prohibit
evinced node to access shared storage with VMs, so VMs are safe.


So fence_cisco_ucs should be enough, no storage based fencing needed?


Generally. Whole reason for fencing is to protect shared disk by disabling access to it by malicious node. There are two main options to achieve that. 1. Kill node = power fencing. 2. Prohibit access for node to storage = storage fencing (fabric fencing).

Now. fence_cisco_ucs seems to be power fencing (sorry for my mistake in previous mail, there is also very similarly named fence_cisco_mds, but this is storage fencing) so it will simply restart node. So node is no longer accessing storage -> it's safe and no need for storage based fencing.

Of course for super important productions, it may make sense to use both (if one of method fails). But generally, power fencing is recommended and well tested.

Regards,
  Honza


Regards,
   Honza


i will file a bug for sbd

regards




_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss




[Index of Archives]     [Linux Clusters]     [Corosync Project]     [Linux USB Devel]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Linux Kernel]     [Linux SCSI]     [X.Org]

  Powered by Linux