Каково различие между Передачей любому из узлов и GeoDNS / GeoIP wrt HA?
В дополнение к дистрибутивам, упомянутым @ErikA, можно также использовать CentOS, который основан на RHEL минус собственные расширения RH. Я не думаю, что это "официально счастливо Oracle" дистрибутив, но я установил Oracle на нем без проблемы.
The key benefit of GeoDNS is that it resolves the same name to different IP addresses based on the requester's IP address.
An Anycasted DNS server will return the same IP address regardless of who is doing the asking.
The two work at different network layers. Anycast is below GeoDNS since it has no sense of the requester IP address's location, just its place in the network diagram. What may be close to the DNS server may not be close to the resource being requested, and the Anycasted DNS server has no way to tell this.
GeoDNS uses a map of resource locations and performs logic to determine which of those resources is closest to a given requesting IP address, and then returns that IP address.
Unless you're colocating your DNS servers with your network resources, what's close to the DNS server won't always be close to the resource, so using Anycast as your data-locality method is less effective than straight up GeoDNS.
The BGP anycast aspect lets clients send a request to a given DNS server, and get that request sent to a nearby instance of the DNS server by virtue of the BGP routing table, hopefully getting a quick response.
However, a normal ol' DNS server that's geographically distributed and anycasted does not have the capability of responding to queries differently depending on the requesting client's location - this is the extra feature that those "Geo-DNS" services are providing for extra cost, allowing you to send clients to an instance of a service that's close to them.
The reason for this feature to exist is that BGP anycast works just fine for something stateless like DNS, where it's quick and dirty and needs no connection or session persistence, but for something like a web server, you want to stick instances all over the world and make sure a given client will stick to a specific instance - routing changes in the global BGP table mid-connection would break TCP connections, break web application sessions, and generally cause havoc; anycast is generally not used for web servers for this reason.
It's best to provide a user in county X with an IP for an instance in country X via DNS, which is what you're forking the cash over for with a Geo-DNS service.
Традиционно у вас будет несколько DNS-серверов. Клиент выберет один случайным образом и запросит IP-адрес вашего веб-сервера. Это хорошо, если DNS-сервер находится близко к клиенту, но плохо, если, как это часто бывает, DNS-сервер находится далеко от клиента. В любом случае клиент получит в качестве ответа тот же IP-адрес.
Anycast позволяет нескольким серверам отвечать на один и тот же IP-адрес. При использовании Anycast DNS, когда клиент пытается связаться с вашим сервером имен, отвечает ближайший / самый быстрый сервер имен. Это означает, что клиент всегда получает быстрый ответ на свой DNS-запрос. Тем не менее, он всегда будет получать один и тот же ответ на свой DNS-запрос - IP-адрес вашего сервера. Если ваш сервер находится далеко от клиента, работа с ним может быть не оптимальной.
GeoDNS позволяет DNS-серверу отвечать с другим IP-адресом в зависимости от того, где находится клиент. (Очевидно, это требует наличия нескольких географически распределенных серверов.) GeoDNS не подразумевает anycast, хотя обычно вы развертываете оба, так что клиент получает ответ на свой DNS-запрос от географически близкого DNS-сервера, который затем отвечает IP-адрес географически ближайшего веб-сервера.