company_banner

DNS Google больше не поддерживает Round Robin DNS


    Раньше, когда надо было распределить нагрузку на несколько серверов, мы прописывали несколько A-записей с одним именем в DNS-зоне, и все работало. Запросы клиентов распределялись примерно поровну. Особенно актуален такой способ балансировки был для раздачи статитического контента.

    Недавно наш клиент обратился к нам с проблемой:
    В ЧНН начинались проблемы с загрузкой различных флешек — файлы загружались по несколько минут.

    Расследование выявило неравномерную загрузку одного из серверов раздачи статики — он отдавал в разы больше трафика в сеть, чем все остальные. Причем периодически нагрузка переходила от одного сервера к другому.

    В DNS зоне было прописано что-то типа:

    cdn.exampe.com IN A 192.168.10.1
    cdn.exampe.com IN A 192.168.12.1
    cdn.exampe.com IN A 192.168.15.1
    cdn.exampe.com IN A 192.168.16.1
    cdn.exampe.com IN A 192.168.11.1
    cdn.exampe.com IN A 192.168.19.1
    


    Раньше клиенты получали ответы от DNS-серверов по алгоритму round-robin, но поиск проблемы привел к совершенно неожиданному результату!

    Запросы к DNS серверу по адресу 8.8.8.8 неизменно возвращали один и тот же адрес.
    Никакого round-robin. Возвращаемый адрес мог смениться, если заканчивался TTL, а мог и не измениться.

    Техподдержка корпорации добра ответила в стиле «мы лучше вас знаем, что именно вам надо».

    DNS Round Robin has never been an effective means of load-balancing, and is less so today, as applications switch from gethostbyname to getaddrinfo for IPv6 support:

    homepage.ntlworld.com/jonathan.deboynepollard/FGA/dns-round-robin-is-useless.html

    www.tenereillo.com/GSLBPageOfShame.htm

    daniel.haxx.se/blog/2012/01/03/getaddrinfo-with-round-robin-dns-and-happy-eyeballs


    RRDNS никогда хорошо не работало, а дальше будет еще хуже. И когда наступит IPv6, станет совсем плохо…
    Вот такое мнение у корпорации добра, и никакие графики нагрузки переубедить ее не смогли.

    Дальнейшее расследование проблемы показало, что проблема не только в Google, но и в Hetzner, в котором хостится зона.

    Проблема номер раз:
    Каждый из гугло-серверов передает ответы точно такими же, какими получил от DNS-серверов, обслуживающих зону, ничего не изменяя в них. Если каждый из серверов получает свой вариант последовательности, то при последовательных запросах складывается впечатление, что Google отдает адреса в случайном порядке, хотя на самом деле это ответы отдаются со случайно выбранного сервера.

    Проблема номер два:
    Хетцнер, в котором хостится проблемная DNS-зона, начал отдавать список адресов для хоста неизменным.
    И в итоге на всех гугло-серверах оказалась одинаковая последовательность адресов.

    Ответ от ТП Hetzner также не порадовал:

    This function is not enabled on our DNS-resolvers. If you want to use that kind of loadbalancing, you have to setup and use your own servers.



    Конечно, можно обратиться к платным поставщикам услуг CDN или сказать программистам, чтобы они генерировали ссылки на контент, которые указывают на конкретные сервера (естественно, для каждого запроса сервер в ссылке берется случайным образом, чтобы распределить нагрузку).
    Но с админов обычно требуют решить проблему быстро, и чтоб работало сейчас.
    А уже потом можно будет поискать решение получше.

    Возвращаем редирект на конкретный сервер средствами nginx:
    Воспользуемся директивой split_clients, распределим проценты согласно мощности наших серверов и пропишем на каждом из них вот такой конфиг.
    Естественно, в строке hostname cdn1.example.com; указываем свое уникальное имя для каждого из серверов.

    http {
        split_clients "${remote_addr}AAA" $variant {
                       15%               1;
                       15%               2;
                       15%               3;
                       15%               4;
                       15%               5;
                       15%               6;
                       *                 7;
        }
    
    server {
      listen 80;
      server_name cdn.example.com;
      return 302 http://cdn$variant.example.com/$request_uri;
    }
    
    server {
      listen 80;
      server_name cdn1.example.com;
      location / {
         root /srv/www/cdn.example.com/htdocs; 
      } 
    }
    


    В итоге nginx возвращает пользователю редиректы на сервер, который определяется на основании хеша ip адреса клиента.
    Вот такое вот распределение нагрузки.

    PS: Перевели зону с Хетцнера в Яндекс
    Southbridge
    575,71
    Обеспечиваем стабильную работу highload-проектов
    Поделиться публикацией

    Комментарии 65

      +10
      Немного удивляет и отношение Гугла к этой ситуации, и то, что они вообще допустили такое.
        –3
        По ссылкам из ответа их техподдержки понятно, почему они такое допустили. Рекомендую к прочтению.
          +6
          Ну им-то пофиг, что RR народ использовал для простого и дешевого решения проблемы распределения нагрузки. По сути они теперь вынуждают больше тратить на инфраструктуру.
            0
            Почитайте матчасть, дело не в Google, а в RFC 3484 и функции getaddrinfo(), которая ему следует.
        0
        Как вариант, можно использовать haproxy — через него можно пробрасывать что угодно и как угодно, с разными схемами балансировки.
          +8
          Да, 3 Gbps пустить через один канал/сервер отличный вариант, тогда как, например, 10 серверов и поднимались для балансировки.
        • НЛО прилетело и опубликовало эту надпись здесь
            –1
            Все верно пишет Иван_83
            Корпорация зла все злее…
              0
              По сути своей верно — прописывать публичные ДНСы, это как надеяться что уличный фонарь будет освещать твоё окно всю жизнь без проблем.
                +3
                Не глупы а дорожат временем. Гораздо легче пользоваться готовым и хорошо (до последнего времени) работающим сервисом, чем поднимать своё. Кроме того, ИМХО, Гугло-Яндекс ДНС это нескончаемое добро по сравнению с криво настроенными домашними резолверами.

                Приватность ИМХО не самоцель. Я вообще не вижу проблем от использования публичных DNS поисковиков. При таких объёмах запросов меня никто не видит. А статистика и особенно мониторинг странных доменов со зловредами — прекрасное подспорье в защите против зловредов на уровне поисковиков.

                Провайдерские ДНС местами хуже. Достаточно вспомнить Ростелеком (особенно южный филиал, где ДНС-ы ложились по лету как по часам), yota DNS-ами не баловала (не знаю как сейчас).

                Кроме того в конторе на 3 виндоус машины плюс один D-Link роутеро-свич именно Гугло-Яндекс DNS позволяет (позволяло...) забыть о проблемах с DNS.
                • НЛО прилетело и опубликовало эту надпись здесь
                0
                Согласен, без предупреждения такие вещи делать не очень корректно, но тем не менее отрицать доводы представителей «корпорации бобра», тоже тяжеловато: сейчас существует огромное количество разного рода балансировщиков нагрузок, начиная с промышленных, которые могут стоить, как самолет, заканчивая опенсорсными, как приведенный выше haproxy или более продвинутый pfsense. Почему вы хотите продолжать пользоваться «недобалансировкой» с использованием RR на DNS?
                Хотя, тут могут быть и другие причины, например: некоторые пользователи могут решить, что так как данная конфигурация плохо балансирует нагрузку, то виноват в этом гугл. Решили себя обезопасить, ничего личного, «от дурака».
                  0
                  Пример. Есть несколько серверов, в интернет смотрит отдельный лоадбалансер. Как обеспечить отказоустойчивость балансера, кроме как дублируя его и используя RRDNS?
                    +2
                    Ну гуглы сами используют anycast.
                      0
                      Кроме RRDNS есть еще как минимум heartbeat и routed/relayd (тут точно названия не помню)
                        0
                        Это, как я понимаю, предполагает наличия собственного ДЦ.
                          0
                          Нет, ДЦ свой не нужен. Достаточно автономной системы и сетки IP-адресов.
                            0
                            Только есть нюанс, насколько я знаю — сетка, которая будет отдана под аникаст, должна быть не менее /24.
                              0
                              увы, как бы расточительно это ни было :(

                              Я тоже одно время хотел сделать anycast на несколько штук адресов. Вариантов не нашел — пришлось брать /24 и маршрутизировать сеть через BGP.
                              0
                              Все это не нужно, достаточно 1 virtual IP (ну либо решить вопрос с доступом к серверам и использовать вообще только 1 IP на несколько)
                                0
                                Не подскажете где такие раздают?
                                Хочу по три сервера на каждый континент поставить и этот ваш virtual IP туда как нельзя кстати бы подошел.
                                Про в скобках, тоже, пожалуйста, подробнее напишите, очень хочется поскорее внедрить!
                                  0
                                  Virtual IP просите у хостера, с саппортом можно общаться ;)
                                  Тот же Hetzner дает KVM ко всем серверам бесплатно и сразу, если сервера в одной стойке (что опять же легко получается при запросе ) то берете адреса что вам выдали и делаете их не статическими а мигрирующими
                                    0
                                    Шикарная новость, а вот подскажите, можно ли будет этот KVM использовать и для раздачи файлов и для закачки?
                                    Файлы не будут вместе с ним мигрировать?
                                      0
                                      Конечно, прямо в мозг пользователю загружаются. Ві отстали от жизни
                                      0
                                      Не KVM, а LaRa наверное, на время. Она убога. Во вторых. Я вот так и не смог придти к тому, как как следует при выходе одного балансера перекинуть vip на соседний сервер. Если подскажите, респект.
                                        0
                                        Не суть важно.
                                        Берете любой демон типа heartbeat, главное условие чтобы между серверами был броадкаст либо юникаст (т.е. не роутинг).
                                        На каждом сервере есть свой IP, можно их и использовать, просто каждый сервер будет для одного IP мастером.
                                        Ну и не привязываем балансер к конкретному IP.
                                        Или привязываете, каждый ведь волен извращаться как ему нравится ;)
                                          0
                                          Вы точно работали с хетзнеровским v-ip или я не понимаю чего-то? Там-же на их оборудовании роутинг идёт на нужную тачку. Или, через api им сообщать, куда роутить?
                                            0
                                            Да, забыл уточнить. в пределах одного аккаунта, что бывает проблемой.
                                              0
                                              Это называется FailoverIP
                                              В вики хетцнера даже готовый скипт для переключения через API есть
                                              https://wiki.hetzner.de/index.php/Failover_Skript/ru
                                              0
                                              Вы вообще понимаете как работает сеть, что такое роутинг, каким образом маршрутизатор определяет на какой физический хост отправлять пакеты?
                                              Если нет то либо сначала изучите основы либо вообще даже не пытайтесь
                                                0
                                                Я то как раз в курсе и не первый день, хоть и не сетевик. А вы резки.
                                +2
                                К сожалению тут как раз ситуация, когда есть N серверов в разных ДЦ,
                                разбросанных от штатов до селектела, через хетцнер… ;)

                                и они никак не завязны на какую-то БД или бекенд. Самодостаточны и генерируют много трафика.

                                haproxy и прочее точно так же будут упираться в гигабит.
                                  0
                                  CloudFlare?
                                0
                                HSRP/VRRP/CARP
                                  0
                                  Как я понимаю, эти решения предполагают наличие своего ДЦ?
                                    0
                                    нет, они даже не требуют большого количества IP-адресов
                                  0
                                  HA на уровне балансеров чем не устраивает? Ответ на этот вопрос еще давно за нас продумали =)
                                    0
                                    RoundRobin отказоустойчивости не обеспечивает — если один балансер из двух упадёт, то половина запросов отвалится.

                                    Отказоустойчивость решается или сменой A-записи при падении узла или обеспечением отказоустойчивости самого IP например путём его анонса из разных ДЦ.
                                      0
                                      Если смотреть на браузеры, то в случае падения первого адреса из списка после таймаута подхватывается следующий и дальше кэшируется, так что можно сказать, что худо-бедно, но обеспечивает.
                                      0
                                      Как вариант, использовать какие-либо health check. Мы используем от амазона и они оперативно переключают записи в dns при фейле в течение пары минут + всякие плюшки типа geo-dns.
                                    0
                                    А мне гуглоднс возвращает больше одного адреса:

                                    lamo$ host vk.com 8.8.8.8
                                    Using domain server:
                                    Name: 8.8.8.8
                                    Address: 8.8.8.8#53
                                    Aliases:
                                    
                                    vk.com has address 87.240.131.120
                                    vk.com has address 87.240.143.241
                                    vk.com has address 87.240.131.117
                                    vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:801
                                    vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:802
                                    vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:803
                                    

                                      +1
                                      Неужели одумались?

                                      [13:49:30] → dig @8.8.8.8 google.com A
                                      ;; ANSWER SECTION:
                                      google.com. 299 IN A 216.58.214.78

                                      [14:00:50] → dig @8.8.8.8 google.com A
                                      ;; ANSWER SECTION:
                                      google.com. 299 IN A 217.19.208.238
                                      google.com. 299 IN A 217.19.208.216
                                      google.com. 299 IN A 217.19.208.245
                                      ...
                                        +6
                                        Ещё бы они для самих себя устроили такую подлянку. Сами себе небось robin-ном распределяют нагрузку.
                                          0
                                          На мою настройку RRDNS четыре восьмерки пока показывают разные последовательности IP при последовательных запросах. Возможно это как-то различается по разным частям гугло-инфраструктуры, так что оригинальный алярм статьи я пока не подтверждаю.
                                            +1
                                            судя по таймштампу вы запрашивали второй раз после истечения TTL. А это — именно то, о чём написано в ОП. И это не RR.
                                            0
                                            смотрите update. их двое
                                            0
                                            А как эту проблему решаею ВК и ФБ?
                                            Не в плане cdn, а в плане самого сайта.
                                              0
                                              vk.com:
                                              vk.com. 202 IN A 87.240.143.241
                                              vk.com. 202 IN A 87.240.131.117
                                              vk.com. 202 IN A 87.240.131.118

                                              facebook.com:
                                              facebook.com. 29 IN A 31.13.76.68

                                              Что то мне подсказывает что у facebook настроено что то типа CARP (для freebsd) для linux не помню как называется, но есть то же похожее на уровне ядра, суть в том что 1 адрес присвоен N серверам и при падении одного хоста, адрес используется другим, ну или есть корпоративное решение такого рода.
                                                0
                                                Anycast
                                                  0
                                                  А есть же ограничение на количество одновременных соединений к одному и тому же адресу? Пусть большое, но оно же есть!!!!??? И как с этим ФБ справляется?
                                                    0
                                                    Аппаратные LB, очевидно.
                                                      0
                                                      Такое ограничение есть только на клиенте. Балансировщики нагрузки по факту оперируют ip пакетами, «подсматривая» в tcp заголовки, но не устанавливают соединение сами, так что для них вообще нету такой проблемы. Серверу тоже без разницы, сколько клиентов присоединится на его порт, главное, чтобы сокетов на всех хватило. А вот клиент на каждое соединение тратит 1 эфемерный порт (теоретически, можно сэкономить и шарить один и тот же исходящий порт, если серверные адрес/порт отличаются, но так, на сколько я знаю, никто пока не делает, потому что не нужно), которых обычно выделено около 30 тысяч (net.ipv4.ip_local_port_range = 32768 61000).
                                                    0
                                                    Keepalived умеет такое.
                                                      0
                                                      Разве это не тот же Round Robin, с которым google не работает? :)
                                                      0
                                                      Довольно просто. Внутри сети используется динамическая маршрутизация, например OSPF. Внутренние балансеры траффика анонсируют маршрут на один и тот же адрес с одинаковой стоимостью, и нагрузка размазывается по ним равномерно. В случае наличия нескольких точек входа в сеть стоимость может быть и не одинаковой, ею можно перенаправлять нагрузку внутри сети.

                                                      Каждый балансер уже следит за живостью HTTP серверов и направляет траффик на них, учитывая их загрузку и прочие факторы. Может показаться, что балансеры лишние, но это не так: их можно поставить существенно меньше, чем фронтов, и они могут прокачивать через себя много траффика, 10 гигабит через одну машину — легко, а если постараться — то и 40 гигабит.

                                                      Если интересны подробности, то рекомендую прочитать статью от гугла про их Maglev: http://static.googleusercontent.com/media/research.google.com/ru//pubs/archive/44824.pdf
                                                      +1
                                                      В ЧНН начинались проблемы с загрузкой различных флешек — файлы загружались по несколько минут.
                                                      Тут имеются в виду SWF файлы («флешки»)? Если для сохранения информации во флешках используют SharedObject (а они точно используют), то из-за вашего редиректа на каждый поддомен cdn'a будет свое сохранение. То есть пользователям будет казаться, что они потеряли сохранения, если попадут на новый cdn при следующем посещении и только в случае, если у пользователя динамический ip адрес, а это мобильные клиенты, да и вообще большинство домашних провайдеров — имхо таких людей будет очень много.
                                                        0
                                                        Большое спасибо.
                                                        Озадачили разработчиков, ждем их комментариев
                                                        –2
                                                        В выдаче 8.8.8.8 порядок этих ип всегда одинаков, в отличии от ожидаемого поведения «нормального» DNS сервера:

                                                        host vk.com 8.8.8.8
                                                        Using domain server:
                                                        Name: 8.8.8.8
                                                        Address: 8.8.8.8#53
                                                        Aliases:

                                                        vk.com has address 87.240.131.118
                                                        vk.com has address 87.240.131.119
                                                        vk.com has address 87.240.131.120
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:904
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:905
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:906

                                                        host vk.com 8.8.8.8
                                                        Using domain server:
                                                        Name: 8.8.8.8
                                                        Address: 8.8.8.8#53
                                                        Aliases:

                                                        vk.com has address 87.240.131.118
                                                        vk.com has address 87.240.131.119
                                                        vk.com has address 87.240.131.120
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:807
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:808
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:809
                                                        vk.com mail is handled by 10 mail.vk.com.
                                                        [root@schm-dhcp ~]# host vk.com 8.8.8.8
                                                        Using domain server:
                                                        Name: 8.8.8.8
                                                        Address: 8.8.8.8#53
                                                        Aliases:

                                                        vk.com has address 87.240.131.119
                                                        vk.com has address 87.240.131.120
                                                        vk.com has address 87.240.143.241
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:807
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:808
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:809
                                                        vk.com mail is handled by 10 mail.vk.com.
                                                        [root@schm-dhcp ~]# host vk.com
                                                        vk.com has address 87.240.143.241
                                                        vk.com has address 87.240.131.118
                                                        vk.com has address 87.240.131.117
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:907
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:908
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:909
                                                        vk.com mail is handled by 10 mail.vk.com.
                                                        [root@schm-dhcp ~]# host vk.com
                                                        vk.com has address 87.240.131.118
                                                        vk.com has address 87.240.131.117
                                                        vk.com has address 87.240.143.241
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:908
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:909
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:907
                                                        vk.com mail is handled by 10 mail.vk.com.
                                                        [root@schm-dhcp ~]# host vk.com
                                                        vk.com has address 87.240.131.117
                                                        vk.com has address 87.240.143.241
                                                        vk.com has address 87.240.131.118
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:909
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:907
                                                        vk.com has IPv6 address 2a00:bdc0:3:103:1:0:403:908

                                                          0
                                                          Написал update
                                                          Пока гипотеза сменилась.
                                                          В основном виноват Hetzner, в котором зона хостится.
                                                          Он перестал порядок записей менять и каждый раз отдает один и тот же вариант.

                                                          А гугл, в отличие от яндекса, похоже кеширует просто последовательность символов, полученную от хетцнера.
                                                          и ничего не меняя отправляет ее в ответ на запросы.
                                                          0
                                                          По-моему в данном случае использовать split_clients не совсем правильно, лучше upstream.
                                                            0
                                                            почему?
                                                            нам надо разделить клиентов на несколько частей — split clients

                                                            А главный плюс апстрима — определение упавших бекендов тут не используется.
                                                            в качестве апстрима мы же будем указывать вирт. сервера в том же nginx
                                                              0
                                                              При добавлении сервера вам придется изменять долю у всех остальных записей, нет резолва и остальных фич апстрима, плюс необходимость компиляции еще одного модуля.
                                                                0
                                                                не совсем понял, зачем тут нужен резолв и остальные фичи?

                                                                в общем затраты на конфигурацию не существенны — они одноразовые

                                                                а вот бессмысленные затраты на создание tcp-Соединений к апстримам будут на каждый запрос
                                                                  0
                                                                  > а вот бессмысленные затраты на создание tcp-Соединений к апстримам будут на каждый запрос

                                                                  А нельзя использовать keepalive до апстримов?
                                                            0
                                                            На мой взгляд, на коленке получилось более изящное и правильное решение))

                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                            Самое читаемое