С трейсом всё хуже, чем с пингами. Трейс и до провайдера может не дойти. Echo request / reply чаще пропускается, чем TTL exceeded. Да и зачастую на роутерах no ip unreachables стоит, что правильно.
Опять же, трейс строить дольше, т.е. задержка перед отдачей контента ещё увеличится. В общем — мимо денег.
Стройная система костылей и подпорок? ;) И проблему закэшированного ответа это всё равно не решает. Как и проблему выбора узла, куда балансировать.
А если я захочу слить зону, скажем, в RIPN DNS?
Это, конечно, моё субъективное ИМХО, но DNS-балансировка — это зло, пока что подтверждаемое практикой.
Круто! Т.е. и DNS надо подстраивать под google? А кэширует ответы он тоже с учётом подсети? А другие «альтернативные» DNS тоже поддерживают такой механизм?
Нет уж, там где стандарты кончились, стабильности и предсказуемости нет.
Чтобы направить клиента на несколько узлов, каждый узел должен иметь свои глобально маршрутизируемые адреса (в случае anycast — нет). Чтобы анонсировать в BGP, нужно по /24 на каждый узел. Умножаем на количество узлов. Получаем, что нам столько не дадут.
Альтернативы? Провайдерские адреса. Т.е. каждый провайдер, подключенный к узлу, должен будет дать для всех серверов этого узла адреса. Уже тяжело администрировать (а в случае с IX — это просто нереально). Иначе трафик будет ходить неоптимальным маршрутом для тех провайдеров, которые своих адреса не дали. И по-любому, балансировщик должен будет учитывать не только узлы, но и откуда пользователь ломится, чтобы выбрать соответствующий IP-адрес этого узла.
Жуть с ружжом и бабка со стингером. :(
Код будет очень тяжелый. К тому же возникнет другая проблема: где взять столько IPv4 адресов в наше нелёгкое время?
И не забывайте, Стим — это «толстый клиент», а у нас, даже приложения для ТВ — это «тонкий клиент». Javascript, конечно вырос, но всё равно.
Опять же: если с клиента «пинговать» все узлы, то как скоро начнётся кино? И ведь каждый просмотр надо будет начинать с пропинговки: как оно там сейчас? В общем, очень тяжёлое решение выйдет.
А толку-то, если абонентское оборудование игнорирует TTL? Кстати, говорят, что гуглоднс тоже, но сам я такого в нём не видел.
Зачем проксировать? Чтобы надо было каналы регионы строить? Нет, спасибо! При архитектуре с редиректом каналы не нужны, а задержка будет та же, если не больше. К тому же, если сейчас служебный канал до узла упадёт, то обслуживание абонентов продолжится. А если проксировать — при падении этого канальчика надо будет класть весь узел, чтобы не портить обслуживание.
Да, в точку. По всем пунктам. :) Думаю, всё сойдётся, когда я напишу про устройство самого регионального узла. Там станет понятно, как именно мы всё компенсируем.
Пока что — обратите внимание: если контент на узле не найден — абонент отправляется в Москву.
Но главная проблема ДНС-балансировки — это инертность. Ждать 2 недели (!!!) пока абоненты перестанут приходить на узел — недопустимо. 2 недели — это у нас был опыт изменения адресов в ДНС. Ждали 2 недели, пока нагрузка по старым адресам пропадёт. И это при TTL 15 минут.
Для меня это некая данность из истории. На самом деле, там был такой своеобразный хабраэффект — об ivi.ru вышел репортаж в программе Вести. Может, кто из старожителей ответит точнее.
Проверил оба IP из дома. Ведут по части MTU себя одинаково. Но всё-таки, почему до них MTU=1462?
А вот с рабочего роутера (прямое подключения к AS31133) всё правильно:
gw-dtln-1#ping 94.25.232.249 df-bit size 1500
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 94.25.232.249, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/16 ms
Если нужно — готов подбросить трейсов и прочих таблиц маршрутизации для анализа.
Кстати, даже в прямом стыке с Yota нет этой сети. Где ЦОД? В Самаре? ;)
Чем характерен мобильный интернет? Уменьшенным значением MTU. Как с этим бороться? При помощи PMTUD (ICMP packet too big).
Проделал сейчас из дома (проводной провайдер QWERTY/cnt.ru, MTU=1500) такой простой эксперимент:
ramax-mba:~ ramax$ ping -D -s 1454 94.25.232.254
PING 94.25.232.254 (94.25.232.254): 1454 data bytes
1462 bytes from 94.25.232.254: icmp_seq=0 ttl=241 time=17.074 ms
1462 bytes from 94.25.232.254: icmp_seq=1 ttl=241 time=17.798 ms
^C
--- 94.25.232.254 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 17.074/17.436/17.798/0.362 ms
ramax-mba:~ ramax$ ping -D -s 1455 94.25.232.254
PING 94.25.232.254 (94.25.232.254): 1455 data bytes
Request timeout for icmp_seq 0
^C
О чём нам это говорит? О том, что MTU для сервера под вопросом равен 1454+8=1462 байт (всё ж таки стандартом в интернете сейчас можно считать 1500), а какой-то роутер ICMP packet too big не посылает или фильтрует. Как мой провайдер видит этот адрес?
О! Совпало!!! Оба провайдера проходят через Мегафон. Может быть, не стоит сразу на конкурента помои выливать, а посмотреть, кто ж блокирует ICMP по пути?
Кстати, странно, что этот IP адрес не светится на MSK-IX.
Да какая ж это проблема? Коробки с преднастроенным оборудованием отдаются курьерской компании, и — вперёд! Монтаж, как правило, делаем силами сотрудников ЦОД. Хотя, я вот в Краснодар съездил с огромным удовольствием в июне. :)
Проблемы — это когда какой-то непредусмотренный фактор вылезает. Один раз шефу пришлось решать проблему электроснабжения стойки. Но это всё-таки экзотика.
Серверы готовятся puppet'ом. Циски конфигурятся копи-пастом и последующей доводкой напильником по месту.
Насчёт набора софта — это тема для отдельной хорошей статьи (и не моего авторства).
Сложности — они всегда есть. Даже вот так на вскидку ничего выделить не могу. Но обещаю по теме дальнейших статей по возможности это освещать.
Зачем? Чтобы увеличить объём текста? Даже с моим знанием географии «на тройку» все города по карте узнаваемы. :)
Ну, ещё могу рекомендовать воспользоваться RIPE DB. У нас там актуальная информация.
Можно я сейчас не буду отвечать на первый и третий вопросы? ;) А то до следующей статьи дело не дойдёт. ;)
В Новосибе один узел, один из самых крупных региональных.
Считали, конечно.
По моему рассуждению, такая информация — очень сильно конфиденциальная, а то и коммерческая тайна. Я узнаю наше отношение к этому вопросу, и если мне разрешат, тогда напишу.
Опять же, трейс строить дольше, т.е. задержка перед отдачей контента ещё увеличится. В общем — мимо денег.
А если я захочу слить зону, скажем, в RIPN DNS?
Это, конечно, моё субъективное ИМХО, но DNS-балансировка — это зло, пока что подтверждаемое практикой.
Нет уж, там где стандарты кончились, стабильности и предсказуемости нет.
Альтернативы? Провайдерские адреса. Т.е. каждый провайдер, подключенный к узлу, должен будет дать для всех серверов этого узла адреса. Уже тяжело администрировать (а в случае с IX — это просто нереально). Иначе трафик будет ходить неоптимальным маршрутом для тех провайдеров, которые своих адреса не дали. И по-любому, балансировщик должен будет учитывать не только узлы, но и откуда пользователь ломится, чтобы выбрать соответствующий IP-адрес этого узла.
Жуть с ружжом и бабка со стингером. :(
И не забывайте, Стим — это «толстый клиент», а у нас, даже приложения для ТВ — это «тонкий клиент». Javascript, конечно вырос, но всё равно.
Опять же: если с клиента «пинговать» все узлы, то как скоро начнётся кино? И ведь каждый просмотр надо будет начинать с пропинговки: как оно там сейчас? В общем, очень тяжёлое решение выйдет.
Зачем проксировать? Чтобы надо было каналы регионы строить? Нет, спасибо! При архитектуре с редиректом каналы не нужны, а задержка будет та же, если не больше. К тому же, если сейчас служебный канал до узла упадёт, то обслуживание абонентов продолжится. А если проксировать — при падении этого канальчика надо будет класть весь узел, чтобы не портить обслуживание.
Пока что — обратите внимание: если контент на узле не найден — абонент отправляется в Москву.
Но главная проблема ДНС-балансировки — это инертность. Ждать 2 недели (!!!) пока абоненты перестанут приходить на узел — недопустимо. 2 недели — это у нас был опыт изменения адресов в ДНС. Ждали 2 недели, пока нагрузка по старым адресам пропадёт. И это при TTL 15 минут.
А вот трейс с первого роутера:
А вот с рабочего роутера (прямое подключения к AS31133) всё правильно:
Если нужно — готов подбросить трейсов и прочих таблиц маршрутизации для анализа.
Кстати, даже в прямом стыке с Yota нет этой сети. Где ЦОД? В Самаре? ;)
Проделал сейчас из дома (проводной провайдер QWERTY/cnt.ru, MTU=1500) такой простой эксперимент:
О чём нам это говорит? О том, что MTU для сервера под вопросом равен 1454+8=1462 байт (всё ж таки стандартом в интернете сейчас можно считать 1500), а какой-то роутер ICMP packet too big не посылает или фильтрует. Как мой провайдер видит этот адрес?
А как видит МТС?
О! Совпало!!! Оба провайдера проходят через Мегафон. Может быть, не стоит сразу на конкурента помои выливать, а посмотреть, кто ж блокирует ICMP по пути?
Кстати, странно, что этот IP адрес не светится на MSK-IX.
Проблемы — это когда какой-то непредусмотренный фактор вылезает. Один раз шефу пришлось решать проблему электроснабжения стойки. Но это всё-таки экзотика.
Насчёт набора софта — это тема для отдельной хорошей статьи (и не моего авторства).
Сложности — они всегда есть. Даже вот так на вскидку ничего выделить не могу. Но обещаю по теме дальнейших статей по возможности это освещать.
Ну, ещё могу рекомендовать воспользоваться RIPE DB. У нас там актуальная информация.
В Новосибе один узел, один из самых крупных региональных.
По моему рассуждению, такая информация — очень сильно конфиденциальная, а то и коммерческая тайна. Я узнаю наше отношение к этому вопросу, и если мне разрешат, тогда напишу.