3 ms·
I agree, that's a very odd way of addressing a problem of entry points failure: * If one is doing it in a cloud and wants to avoid potential issues with the cl
by notyourday 7y ago
I agree, that's a very odd way of addressing a problem of entry points failure:
* If one is doing it in a cloud and wants to avoid potential issues with the clients behind broken DNS resolvers, then one simply nails the entry point instances to specific IP addresses and in event of an entry point failure, assigns an IP address of a failed instance to a standby instance, resulting in a nearly immediate traffic swap.
* If one is running entry points on physical hardware, then the solution is to bind the entry points to a virtual IP address floating between the instances using VRRP.
* Finally, if one wants to be really super-clever and not drop sessions using controlled fail-over, one does does VRRP + service mac addresses similar to Fastly's faild or Google's MagLev. (But really, this is addressing 99.99999% reliability when in most of business cases 99.9% would do just fine and 99.99% would be amazing ).
- q3k 7y agoYou wouldn't use VRRP in these cases these days - since the networking world has moved on and now L3 is generally pushed to ToRs, you would use BGP to announce a /32 or /128 and configure an ECMP group on the ToR. This gives you not only redundancy then, but also traffic splitting. Maglev does use BGP, too (although in a way indirectly due to scale reasons).
- notyourday 7y agoJust because a customer has access to L2 fabric via a VLAN between customer's hardware does not mean the customer has access to be able to tweak ToR switch configuration. Using BGP on a L2 vlan for handling a single digit number of IP addresses allocated to the entry points is akin to using K8S to host a static HTML page.
- q3k 7y agoRight, but if they're using k8s, they better already have support from their local network operations team.