Von: Jan Friesse <[email protected]> An: [email protected] Kopie: [email protected] Datum: 31.07.2014 11:33 Betreff: Re: Antwort: Re: Antwort: Re: Antwort: Re: [corosync] SBD 1.2.0 / corosync 2.3
[email protected] 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 ok, thank you! >> >> Regards, >> Honza >> >>> >>> i will file a bug for sbd >>> >>> regards >>> >>> >
_______________________________________________ discuss mailing list [email protected] http://lists.corosync.org/mailman/listinfo/discuss
