[ClusterLabs] fence_virt architecture? (was: Re: Still Beginner STONITH Problem)

[Andrei Borzenkov]

On Mon, Jul 20, 2020 at 11:45 AM Klaus Wenninger <kwenning at redhat.com>
wrote:

> On 7/20/20 10:34 AM, Andrei Borzenkov wrote:
>
>
>
>
>>
>> The cpg-configuration sounds interesting as well. Haven't used
>> it or looked into the details. Would be interested to hear about
>> how that works.
>>
>
> It maintains a registry of VM location (each fence_virtd polls local
> hypervisor at regular intervals) and forwards fencing request to
> appropriate host via corosync interconnect. It is also the only backend
> that can handle host failure - if it is known that host left cluster, any
> VM on this host is considered fenced by definition.
>
> It requires that hosts are configured in pacemaker cluster themselves (to
> handle host outage it must be properly fenced).
>
> That sounds definitely interesting.
> Are you saying that the hosts have to be pacemaker-nodes as well?
>

cpg backend requires a working corosync cluster (it is using it as
transport). It responds to "node joined" and "node left" events. So the
question is when "node left" is generated. My understanding so far was that
for unavailable node to be considered "left cluster" node must be fenced.
If I am wrong, pacemaker is not needed. If fencing is required, I am not
aware how it can be implemented without pacemaker.

In any case, it is a completely separate cluster, so "as well" is not
applicable.



> Otherwise we might be able to just add them to corosync and configure
> them not to vote on quorum ...
>

These clusters are on different levels. Consider multi-tenant deployment.
Each VM cluster has separate owner, and is managed independently. There is
no reason to integrate it into underlying host cluster. Host cluster is
managed by provider, not by tenant.



> ... the same knet might then even be used to connect the bridges
> on the hosts with each other on layer-2 ...
>

With distributed backend you do not need any network connectivity between
host and guest at all - just contact local hypervisor via local channel.
That is actually more secure.



>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clusterlabs.org/pipermail/users/attachments/20200720/a470efa8/attachment-0001.htm>