Как стать автором
Обновить

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

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

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

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

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

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

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

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

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

[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
...
Ещё бы они для самих себя устроили такую подлянку. Сами себе небось robin-ном распределяют нагрузку.
На мою настройку RRDNS четыре восьмерки пока показывают разные последовательности IP при последовательных запросах. Возможно это как-то различается по разным частям гугло-инфраструктуры, так что оригинальный алярм статьи я пока не подтверждаю.
судя по таймштампу вы запрашивали второй раз после истечения TTL. А это — именно то, о чём написано в ОП. И это не RR.
смотрите update. их двое
А как эту проблему решаею ВК и ФБ?
Не в плане cdn, а в плане самого сайта.
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 серверам и при падении одного хоста, адрес используется другим, ну или есть корпоративное решение такого рода.
Anycast
А есть же ограничение на количество одновременных соединений к одному и тому же адресу? Пусть большое, но оно же есть!!!!??? И как с этим ФБ справляется?
Аппаратные LB, очевидно.
Такое ограничение есть только на клиенте. Балансировщики нагрузки по факту оперируют ip пакетами, «подсматривая» в tcp заголовки, но не устанавливают соединение сами, так что для них вообще нету такой проблемы. Серверу тоже без разницы, сколько клиентов присоединится на его порт, главное, чтобы сокетов на всех хватило. А вот клиент на каждое соединение тратит 1 эфемерный порт (теоретически, можно сэкономить и шарить один и тот же исходящий порт, если серверные адрес/порт отличаются, но так, на сколько я знаю, никто пока не делает, потому что не нужно), которых обычно выделено около 30 тысяч (net.ipv4.ip_local_port_range = 32768 61000).
Keepalived умеет такое.
Разве это не тот же Round Robin, с которым google не работает? :)
Довольно просто. Внутри сети используется динамическая маршрутизация, например OSPF. Внутренние балансеры траффика анонсируют маршрут на один и тот же адрес с одинаковой стоимостью, и нагрузка размазывается по ним равномерно. В случае наличия нескольких точек входа в сеть стоимость может быть и не одинаковой, ею можно перенаправлять нагрузку внутри сети.

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

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

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

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

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

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

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

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