[ThreeDHead]

Проблема такая, ютуб смотрим с американских серверов, причем имея в стране два GGC.

 

Немного поразбиравшись в проблеме, решили попробовать перенаправить трафик к серверам (r5---sn-25g7sb76.c.youtube.com) на местный GGC.

Т.к. имена доменов непонятно как генерятся, хочется все запросы нашему ДНС'у на *.c.youtube.com отвечать местными айпишниками. Есть подобный механизм в конфигах BIND9? Может конфиг регулярки какие поддерживает?

[ipaddr.ru]

С учетом того, что c.youtube.com - это отдельная зона со своими NS-ами, вам ничто не мешает поднять её локально и написать в ней что угодно.

[orlik]

Проблема такая, ютуб смотрим с американских серверов, причем имея в стране два GGC.

 

Немного поразбиравшись в проблеме, решили попробовать перенаправить трафик к серверам (r5---sn-25g7sb76.c.youtube.com) на местный GGC.

Т.к. имена доменов непонятно как генерятся, хочется все запросы нашему ДНС'у на *.c.youtube.com отвечать местными айпишниками. Есть подобный механизм в конфигах BIND9? Может конфиг регулярки какие поддерживает?

 

только есть одна проблема , принудительное заворачивание не ggc может негативно сказаться на сервисе , некоторые ролики перестанут грузиться (те которых нет в кеше). Я на это напоролся некоторе время назад , думаю будет лучше написать админам провайдера у которых стоит кеш и убедиться , для начала, что ваши префиксы анонсятся в сторону ggc ...

 

Я пробовал поднимать зону youtube локально и заворачивать туда клиентский трафик, раньше (год назад) это работало , сейчас уже нет , но вам ничто не мешает попробовать , главное для начала не заворачивайте туда всех клиентов :)

 

P.S. а не пробовали посмотреть сколько у вас трафика на них и поставить свои сервера ggc ?

P.P.S. у вас же вроде кешировалка стоит , неужели так много трафика из-за рубежа тянет ?

[ThreeDHead]

Проблему решили забавно.

 

За видеороликами ютуба нас всегда направляло на сети 208.65.152.0/22 и 208.117.224.0/19 обе эти сети находятся в US.

 

НАТ'ом занимается пул серверов под лиуксом, добавив две строчки:

iptables -t nat -I PREROUTING -s 10.X.Y.Z/NET -d 208.65.152.0/22 -p tcp --dport http -j DNAT --to-destination 89.218.72.76
iptables -t nat -I PREROUTING -s 10.X.Y.Z/NET -d 208.117.224.0/19 -p tcp --dport http -j DNAT --to-destination 89.218.72.76

Направили пакеты к местному GGC.

 

А теперь логика:

1. Плеер (или сама система гугла) понимает куда обращается. Т.е. я в наглую отправил пакет вообще в другую степь, он это понял и попытался с него брать контент.

2. Если это контента нет в местном GGC, то плеер (или система его перенаправляет) в другое место, как они выбирают "куда", я не в курсе. И так он кружит до тех пор, пока не найдет сервера с нужным контентом. И это радует.

 

Но осталась небольшая проблема - сети заворачиваются _целиком_, а в них могут быть и другие гуглосервисы...

И вторая проблема, если её решать как я спросил выше (через BIND) - то вообще испортится всё.

[yegorov-p]

Поддерживаю, у вас 300 мегабит в сторону гугла есть в пике?

[ThreeDHead]

P.S. а не пробовали посмотреть сколько у вас трафика на них и поставить свои сервера ggc ?

Отказали, даже на обещание обслуживать регион.

 

P.P.S. у вас же вроде кешировалка стоит , неужели так много трафика из-за рубежа тянет ?

Но она же не резиновая. И как она там Ютуб кеширует никому не известно.

 

Поддерживаю, у вас 300 мегабит в сторону гугла есть в пике?

Есть конечно. Но они лимиты задрали уже.

[orlik]

 

Но осталась небольшая проблема - сети заворачиваются _целиком_, а в них могут быть и другие гуглосервисы...

 

 

это легко проверить , посмотрите во что резолвятся googleusercontent.com mail.google.com google.com и вы сами все поймете , проверьчто чтоб все сервисы работали , может и будет счастье

[ThreeDHead]

это легко проверить , посмотрите во что резолвятся googleusercontent.com mail.google.com google.com и вы сами все поймете , проверьчто чтоб все сервисы работали , может и будет счастье

Проверил, вроде все нормально.

Прям нарадоваться не могу, 720p влёт кешируется. Сейчас день, а 200 Мбит с основного канала уже снял, счастье прям.

[vlad11]

За видеороликами ютуба нас всегда направляло на сети 208.65.152.0/22 и 208.117.224.0/19 обе эти сети находятся в US.

 

НАТ'ом занимается пул серверов под лиуксом, добавив две строчки:

iptables -t nat -I PREROUTING -s 10.X.Y.Z/NET -d 208.65.152.0/22 -p tcp --dport http -j DNAT --to-destination 89.218.72.76
iptables -t nat -I PREROUTING -s 10.X.Y.Z/NET -d 208.117.224.0/19 -p tcp --dport http -j DNAT --to-destination 89.218.72.76

Направили пакеты к местному GGC.

 

Что мешает прописать роуты внаглую? Ведь местный шлюз к GGC вы знаете.

 

наголовном бордере:

route add 208.65.152.0/22 $ip_border_2
route add 208.117.224.0/19 $ip_border_2

 

на бордер №2

route add 208.65.152.0/22 89.218.72.76
route add 208.117.224.0/19 89.218.72.76

Изменено 2 марта, 2013 пользователем vlad11

[ThreeDHead]

P.P.S. у вас же вроде кешировалка стоит , неужели так много трафика из-за рубежа тянет ?

Посмотрел. Также как и весь остальной трафик, система кеширует Ютуб порядка ~35%

[ThreeDHead]

Блин, не так все просто оказалось. Сегодня разворачиваешь одни сети, наутро начинают анонсировать другие...

Додобавляли до тех пор, что вообще перестали ролики грузиться.

Пришлось анализировать http-трафик на предмет запросов на .c.youtube.com их складывать в журнал, раз в час самые популярные /24 сети разворачивать на местный GGC. Т.о. система сама, автоматически будет подстраиваться.

Посмотрим, на сколько успешно сработает.

[t0ly]

как то уж очень "костыльно" это

[orlik]

как то уж очень "костыльно" это

Да, но это реальный способ съэкономить полосу, а при наших ценах на трафик... Но это конечно если это юудет работать ....

[Sonne]

Интересно, почему никто не хочет поставить прокси-кеш для ютуба?

 

http://forum.nag.ru/forum/index.php?showtopic=77232

 

Я хотел протестировать обсуждаемое решение, но пока острая необходимость отпала, а времени на все не хватает как обычно.

[alkanaft]

вот нетфликс например вот такие каропки бодяжит. даже написали на какой фрибзде, берде и нгинксе сделали и какую мамку супермикро заюзали https://signup.netflix.com/openconnect/hardware

при том проект чисто коммерческий, а гугль получается такой открытый и свободный зажал для своих же клиентов кешировалку. хрень какая-то....

[Sonne]

Посмотрел Netflix - офигенно! Вот только каропки высылают только на территорию действия сервиса, а территория действия - США и кажется Швеция/Норвегия.

[ThreeDHead]

как то уж очень "костыльно" это

В норме всё. Сейчас система работает нормально, 2/3 трафика направляет в региональный GGC. Абоненты начали смотреть ролики в 720p.

[orlik]

как то уж очень "костыльно" это

В норме всё. Сейчас система работает нормально, 2/3 трафика направляет в региональный GGC. Абоненты начали смотреть ролики в 720p.

 

как в итоге завернули то ?

[ThreeDHead]

как в итоге завернули то ?

Ну, собственно, я уже ключевой момент перенаправления уже написал.

Вчера связались со специалистами Гугла, те обещали помочь. Сегодня сказали что сделали, мы отключили принудительное перенаправление. Сперва отдавалось с регионального GGC, а в ЧНН начало отдаваться с Европы :( Отписали им, ждемс.

[orlik]

Вчнн даже клиенты самого телекома перенаправляются в европу , т.к. Ggc сервера перегружены

[ThreeDHead]

Вчнн даже клиенты самого телекома перенаправляются в европу , т.к. Ggc сервера перегружены

Саппорт КТ говорит обратное.

[replicant]

Вчнн даже клиенты самого телекома перенаправляются в европу , т.к. Ggc сервера перегружены

Саппорт КТ говорит обратное.

Саппорт может говорить все что угодно ... :)

[orlik]

Вчнн даже клиенты самого телекома перенаправляются в европу , т.к. Ggc сервера перегружены

Саппорт КТ говорит обратное.

 

Отправил сообщение в личку

[ThreeDHead]

Вернули принудительное перенаправление, а то как-то они починили, что трафик опять полился с Европы.

[orlik]

Принудительно, это натом ?