[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Understanding a HA routing service with virtual IPs



Hello,

wow, that sounds complex. But I have problems grasping what you wrote:
What is the advantage of multiple virtual IPs compared to one single
virtual IP address?

Here's what I did:
I use one single Virtual IP. The wildcard DNS Domain resolves to this IP
and only to this IP.
I have 3 nodes, 3 routers and 3 ip-failover pods.

One of the ip-failover pods is the keepalived-master and if he fails (or
the node he runs on) I can see via "oc logs" how one of the other
ip-failover pods takes the virtual IP and saves the day.
With this setup the cluster will allways be reachable as as long as a
single node is running (because each node has its own router and
ip-failover pod running).

Now, my question:
What is the advantage of your setup compared to mine? My setup seems to
be pretty straightforward and so far it survived all stress test. Am I
missing something?

regards,
v

PS Thank you for your long answer! Looking forward to learn more from
you and/or other people on this mailing list!



> Hi there,
>
> I don't know if my understanding is completely correct, but here it is:
> You use node labels and pod selectors to define a number N of nodes
> eligible to run a router pod. You want more than one to have HA. You
> deploy a number P of router pods and P < N after all you want to have
> some spare nodes in case some of them are down.
>
> Router pods need to be accessible from external hosts (that are not part
> of the OpenShift SDN) so they use host ports. That way they can be
> reached from the node IP, and when using the ip-failover service, the
> node IP becomes a Virtual IP. Each of the N nodes needs its own Virtual
> IP or VIP. And yes, the ip-failover service runs on privileged nodes and
> adds the VIP to the host network interface. The ip-failover pods manages
> the VIPs, not the host nodes.
>
> As not all N nodes will be running a router pod, the ip-failover pod on
> some ones will see they do not have router pods and release their VIPs.
> Other nodes ip-failover pods will get those VIPs and assign to their own
> host network interface. That way all N VIPs can be configured as IPs for
> the wildcard DNS domain.
>
> It took me some time to realize why we need all nodes eligible to run
> router pods to have VIPs even if we will never have all of then running
> router pods, that is, why P < N and not P = N at all times. The reason
> is the DNS configuration has to be static. Even if OSE supported doing
> dynamic DNS updates to increase or decrease the number of VIPs
> propagating those updates to all clients is problematic. OSE does not
> control DNS client cache settings and we do not want a too low TTL for
> those entries else DNS traffic may become too big and response time too low.
>
> Besides you have to plan for spare unused capacity. If P = N and you use
> most of your router nodes capacity, you won't survie a node crash,
> because the surviiving nodes won't be able to handle the extra load.
>
> If some part of my understanding is wrong, please someone enlighten me. :-)
>
>
> []s, Fernando Lozano
>
>
>> Hello,
>>
>> I am trying to understand the role of Virtual IPs when creating a
>> highly-available router.
>>
>> It would be nice if somebody told me whether I am right with my
>> assumptions and correct me if I am wrong:
>> As far as I understand the wildcard DNS domain is supposed to resolve to
>> a Virtual IP that is always owned by only one router/node. So if a
>> router or node fails, another router+node will take over the virtual IP
>> and routing will still work.
>>
>> Does this mean that openshift will add/remove ip addresses to my
>> ethernet interface via "ip adress add/remove"?
>> What is the point of specifying multiple virtual IP addresses as
>> described in
>> https://docs.openshift.com/enterprise/3.0/admin_guide/high_availability.html
>> ?
>>
>> Regards,
>> v
>>
>> _______________________________________________
>> users mailing list
>> users lists openshift redhat com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>
>
> _______________________________________________
> users mailing list
> users lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]