Thomas,
>>> An idea is to allow the configuration of the behavior and add two
>>> additional behaviors,
>>> i.e. migrate away and relocate away.
>> What's the difference between migration and relocation? Temporary vs.
>> permanent?
>
> Migration does an online migration if possible (=on VMs) and the services is
> already running.
> Relocation *always* stops the service if it runs and only then migrates it.
> If it then gets started on the other side again depends on the request state.
>
> The latter one may be useful on really big VMs where short down time can be
> accepted
> and online migration would need far to long or cause congestion on the
> network.
Ah, ok. So relocation is migration without "online" checked (UI) or "qm
migrate" without "--online"?
>>>> (Please don't comment on whether this setup is ideal – I'm aware of the
>>>> risks a single chassis brings…)
>>> As long as nodes share continents your never save anyway :-P
>> True, but impossible to implement for approx. 99.999999% of all PVE users.
>> And latencies will be a nightmare then, esp. with
>> Ceph :D
>
> Haha, yeah, would be quite a nightmare, if you haven't your own sea cable
> connection :D
Even then the latency adds up by approx. 1 millisecond per 100km…
>>> Quasi, a maintenance mode? I'm not opposed to it, but if such a thing would
>>> be done
>>> it would be only a light wrapper around already existing functionality.
>> Absolutely. Just another action that would evacuate the current host as
>> optimal as possible. All VMs that are constrained to a
>> specific node group should be migrated within that group, all other VMs
>> should be migrated to any node available (possible doing
>> some load balancing inside the cluster).
>
> I'll look again in this, if I get an idea how to incorporate this without
> breaking edge cases I can give it a shot,
> no promise yet, though, sorry :)
>> If there are valid concerns against this reasoning, I'm open to suggestions
>> for improvement.
>
> Sounds OK, I have to think about it if I can propose a better fitting
> solution regarding our HA stack.
> An idea was to add simple dependencies, i.e. this group/service should
> not run on the same node as the other group/services. Not sure if this is
> quite specialism or more people would profit from it...
I'd like to hear you suggestions if you find the time…
>> Interesting idea. Didn't have a look at priorities yet.
>>
>> Request for improvement: In "datacenter -> HA -> groups" show the configured
>> priority, e.g. in a format
>> "nodename(priority)[,nodename(priority)]"
>
> Hmm, this should already be the case, except if the default priority is set.
> I added this when I reworked the HA group editor sometimes in 4.3.
Well, I didn't play with priorities yet so it might be that it just didn't show
up in my case.
Thank you,
Uwe
_______________________________________________
pve-user mailing list
pve-user@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user
