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