Forum Discussion
VIPRION vCMP and vGuest cluster member IP
Sure I will. Taking chance, I have quite a problem figuring out why those member IPs are necessary. I assume that only relevant scenario is when HA is configured - or not really?
Even for HA I wonder how exactly those member IPs are used?
I know that multi slot vGuest is actually bunch of separate VMs working together and advertising to outside world as single entity.
My guess is that TMM related traffic is handled via hidden ports (0.x) using both front interfaces and backplane connections.
But what member IPs are used for? In case of HA we can either set one Unicast (TMM) + Multicast (I assume Multicast is using vGuest cluster IP?) or Unicast (TMM) + Unicast member IP mesh.
Side note - in v13.0.0.HF2 (I don't remember if in older versions as well) it's possible to define interface for Multicast - when it makes sense to choose other interface than eth0 - mgmt.?
Now when we use Multicast or Unicast mesh what exactly happens?
Failover traffic (at least based on traces I did) works like that:
- Active is sending traffic to Standby
- Standby is sending traffic to Active
Standby decides that Active is down when will not receive any packets from Active for 3 s (default)
Scenarios seems to look like that:
Unicast + Multicast:
- Active sends traffic to TMM port of Passive
- Active sends traffic (from cluster IP?) to set Multicast IP (default 224.0.0.245)
- Standby listens for packets on TMM port
- Standby listens for packets on what? cluster IP, all member IPs (more probably)?
When Standby will decide that Active is down? When there is both no TMM traffic and Multicast traffic - quite logic, but what is difference if Standby/Active has only vGuest cluster IP configured vs cluster member IPs?
Is having all member IPs defined is a way to detect how many VMs on Active are actually up (so how many blades are running on Active)?
If so how can it be dependent on all member IPs configured on Active - I assume that Multicast traffic is not send from all member IPs at the same time - or it is so?
Can see logic when Unicast mesh is configured - then source and destination is clear and it's easy to find out which VM on Active is not sending traffic = it's down.
If detecting vGuest VMs failures is indeed part of HA then how it is used for failover decisions?
Will failover be triggered if Standby detects that Active is running on less slots?
Will Active consider Standby down it it's running on less slots?
Will mirroring break when number of slots on Active and Standby is different (according to info I found mirroring is not working correctly if both HA devices are not homogeneous - for vGuest = same vCPU and slots allocation)
Any other outcomes? Or above it total garbage?
Sorry for so many questions but as I said, right now I have no access to VIPRION so can't check it by myself.
Piotr
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com