Comments 39
Редиректить по IP можно на уровне DNS через BIND :)
А данные надо кешировать по частоте их запроса на локальном прокси, об этом я уже писал.
А данные надо кешировать по частоте их запроса на локальном прокси, об этом я уже писал.
если ты про патч GeoIP — то решение кривое.
«география» настоящая далеко не всегда соответствует «географии» интернетной (см. войны провайдеров и тд)
«география» настоящая далеко не всегда соответствует «географии» интернетной (см. войны провайдеров и тд)
Нет, я только о том, что в BIND можно выдать разные A записи, причем эта зависимость базируется на IP отправителя.
1) ну это как бы совсем не решение проблемы ;))
2) патч geoip — это как раз и есть возможность выдавать A запись на основе source IP, просто удобно можно сказать «тем кто из россии — давать эту запись, кто из США — эту»
www.caraytech.com/geodns/
2) патч geoip — это как раз и есть возможность выдавать A запись на основе source IP, просто удобно можно сказать «тем кто из россии — давать эту запись, кто из США — эту»
www.caraytech.com/geodns/
можно у ookla поискать решения по реалтайм расчёту идеального места раздачи, помнится было что-то и оно моментально выдавала результаты
Бред какой-то.
Вся описанная технология идет лесом — проблема в том что датацентр с сервером может располагаться в соседнем здании, но скорость связи с ним намного хуже чем с ДЦ в другой стране (и такое бывает, и очень часто)
Проблема решается по другому — изучайте Cisco GSS, Citrix Netscaler Global DNS, F5 GTM — эти технологии в realtime измеряют задержки до клиента (точнее его ДНС сервера, который в 99.99% являеся либо своим либо ДНС провайдера), и по ряду «признаков» (QOS, «скорость» (RTT, tcp traceroute, etc), цена канала (вы пишите очевидную глупость «случайным образом если связ одинаковая» — не учитываете что скорость может быть одинаковой, но вот обсслужить пользователя из ДЦ в хабаровске стоит в 3 раза дороже по трафику чем из ДЦ в Москве предположим — или даже если скорость хуже из Москвы на 20%, но при этом сильно дешевле — то все равно выгоднее обслужить из Москвы)
В общем — не надо изобретать велосипед, если делаете нормальный проект — вложитесь в нормальное оборудование. Хотя в россии «велосипедный спорт» — занятие национальное… «Я его слепила из того что быыыло....» :)
Вся описанная технология идет лесом — проблема в том что датацентр с сервером может располагаться в соседнем здании, но скорость связи с ним намного хуже чем с ДЦ в другой стране (и такое бывает, и очень часто)
Проблема решается по другому — изучайте Cisco GSS, Citrix Netscaler Global DNS, F5 GTM — эти технологии в realtime измеряют задержки до клиента (точнее его ДНС сервера, который в 99.99% являеся либо своим либо ДНС провайдера), и по ряду «признаков» (QOS, «скорость» (RTT, tcp traceroute, etc), цена канала (вы пишите очевидную глупость «случайным образом если связ одинаковая» — не учитываете что скорость может быть одинаковой, но вот обсслужить пользователя из ДЦ в хабаровске стоит в 3 раза дороже по трафику чем из ДЦ в Москве предположим — или даже если скорость хуже из Москвы на 20%, но при этом сильно дешевле — то все равно выгоднее обслужить из Москвы)
В общем — не надо изобретать велосипед, если делаете нормальный проект — вложитесь в нормальное оборудование. Хотя в россии «велосипедный спорт» — занятие национальное… «Я его слепила из того что быыыло....» :)
не дописал…
… и по ряду «признаков» уже по заданному алгоритму (который можно очень тонко настраивать) выдаст в итоге нужную «площадку» клиенту.
проблема тут только одна — стоимость решения (десятки килобаксов как минимум) и то что в россии если по Cisco можно найти спецов (но GSS — худшее из трех), то Citrix и F5 — сразу тушить свет :P
Да, Citrix и F5 поддерживают и GeoIP — тобишь можно смешанные алгоритмы использовать (определять страну по GeoIP например а внутри страны уже по скорости связи выбирать лучшую площадку)
Вообще, я на highload делал на эту тему доклад — открывал конференцию, а мой друг и соратник anight делал доклад по CDN «самодельному» :)
… и по ряду «признаков» уже по заданному алгоритму (который можно очень тонко настраивать) выдаст в итоге нужную «площадку» клиенту.
проблема тут только одна — стоимость решения (десятки килобаксов как минимум) и то что в россии если по Cisco можно найти спецов (но GSS — худшее из трех), то Citrix и F5 — сразу тушить свет :P
Да, Citrix и F5 поддерживают и GeoIP — тобишь можно смешанные алгоритмы использовать (определять страну по GeoIP например а внутри страны уже по скорости связи выбирать лучшую площадку)
Вообще, я на highload делал на эту тему доклад — открывал конференцию, а мой друг и соратник anight делал доклад по CDN «самодельному» :)
Я не хотел отрицать этим постом возможность применения «железки», которую Вы описываете.
Но я бы хотел прокомментировать свою «очевидную глупость»: «случайным образом если связ одинаковая». Такого не написано в моем посте, уж простите, там речь шла о равном «расстоянии». Расстояние — вещь условная, и если оно правильно выбрано, то и правильно будет выбран канал, хотя сложность его выбора корректно — это отдельная проблема.
Не претендую на то, что предложенный вариант является «лучшим», но он жизнеспособен, как мне кажется. А в комментариях стоит быть несколько тактичнее, shapa.
Но я бы хотел прокомментировать свою «очевидную глупость»: «случайным образом если связ одинаковая». Такого не написано в моем посте, уж простите, там речь шла о равном «расстоянии». Расстояние — вещь условная, и если оно правильно выбрано, то и правильно будет выбран канал, хотя сложность его выбора корректно — это отдельная проблема.
Не претендую на то, что предложенный вариант является «лучшим», но он жизнеспособен, как мне кажется. А в комментариях стоит быть несколько тактичнее, shapa.
Объясняю.
В решении которое предлагаешь ты — не учтено очень много вещей.
Я привел только один из _многих_ «моментов» которые не учтены — а именно — цена канала.
А еще есть «толщина» каналов, нагрузка пула серверов (глупо давать клиенту более «близкую» но перегруженную площадку, да?) и тд и тп.
Объясняю откуда я это знаю… :) И почему твой подход не очень (мягко скажем) комплексный.
www.google.com/intl/en/press/zeitgeist2007/
Fastest Rising (global)
см. второе место.
это мы…
В решении которое предлагаешь ты — не учтено очень много вещей.
Я привел только один из _многих_ «моментов» которые не учтены — а именно — цена канала.
А еще есть «толщина» каналов, нагрузка пула серверов (глупо давать клиенту более «близкую» но перегруженную площадку, да?) и тд и тп.
Объясняю откуда я это знаю… :) И почему твой подход не очень (мягко скажем) комплексный.
www.google.com/intl/en/press/zeitgeist2007/
Fastest Rising (global)
см. второе место.
это мы…
Тут написано в теме поста «своими руками». Специально написано, чтобы не было сомнений в том, что так надо делать CDN всегда. Я полагаю, существует некоторая ниша, в которой и описанному мной есть место.
Badoo — это круто, он быстро вырос и всё такое, и вы молодцы!
Но задачи, ресурсы у всех разные.
Badoo — это круто, он быстро вырос и всё такое, и вы молодцы!
Но задачи, ресурсы у всех разные.
Ok, сорри если резко написал — не хотел, устал просто — 2 ночи тут в Майями, в датацентре работал :)
На самом деле — было бы здорово если бы кто-то взял и написал софт грамотный для этого (как Сысоев написал nginx) — на самом деле это не очень сложно, мало того я очень много могу рассказать как что и зачем — есть очень много специфического опыта :)
Сделать можно на основе Bind.
Просто «цена решения» действительно очень высока, но если бы был опенсорс продукт (или как минимум free, или даже просто недорогой) — то очень многие бы стали использовать, и качество сервиса повышать.
На самом деле — было бы здорово если бы кто-то взял и написал софт грамотный для этого (как Сысоев написал nginx) — на самом деле это не очень сложно, мало того я очень много могу рассказать как что и зачем — есть очень много специфического опыта :)
Сделать можно на основе Bind.
Просто «цена решения» действительно очень высока, но если бы был опенсорс продукт (или как минимум free, или даже просто недорогой) — то очень многие бы стали использовать, и качество сервиса повышать.
Cобственно — это очень хорошая бизнес идея / ниша — можно сделать free продукт но продавать поддержку.
Учитывая что у Citrix это решение входит только в enterprise версию netscaler, а у F5 железки от пары десятков килобаксов начинаются — то при цене решения (саппорта?) в пару килобаксов ОЧЕНЬ многие интернет компании бы захотели…
Спонсировать что ли разработку :)))
p.s. Citrix и F5 — внутри крутится linux, bind и еще много чего ;)
Учитывая что у Citrix это решение входит только в enterprise версию netscaler, а у F5 железки от пары десятков килобаксов начинаются — то при цене решения (саппорта?) в пару килобаксов ОЧЕНЬ многие интернет компании бы захотели…
Спонсировать что ли разработку :)))
p.s. Citrix и F5 — внутри крутится linux, bind и еще много чего ;)
Ага, мне кажется, что просто различие описанного мной и «железки» — возможность грамотно расставить веса. Т.е. с некоторым приближением можно веса расставить правильно, тогда будет счастье, динамически их менять тяжело (что может сделать железка, отслеживая реальную ситуацию).
Кстати, а как с железкой решить вопрос о необходимости копирования контента на определенную площадку? Ведь здесь не только вопрос выбора ближайшего сервера.
Кстати, а как с железкой решить вопрос о необходимости копирования контента на определенную площадку? Ведь здесь не только вопрос выбора ближайшего сервера.
«расставить веса» — звучит забавно :)
сначала эти веса надо откуда-то взять, да?
тобишь железка-то шибко умная выходит… и по snmp с роутеров (всех роутеров во всех ДЦ!) собирает информацию о нагрузке каналов и их «ширине», и мониторит каким-то образом пулы серверов на предмент нагрузки, и вообще мониторит площадки на предмет скорости работы, и меряет каким-то обазом со всех площадок задержки до клиента, и еще много чего делает :D
Копирование — совсем другая тематика.
У нас это умеет автоматически делать софт нашего собственного CDN — кэшировать интеллектуально «горячие» данные (потому как есть золотое правило — 5% контента запрашиваются 95% пользователей — и поэтому очень глупо копировать _все_ данные, а нужно автоматически «горячие» только)
сначала эти веса надо откуда-то взять, да?
тобишь железка-то шибко умная выходит… и по snmp с роутеров (всех роутеров во всех ДЦ!) собирает информацию о нагрузке каналов и их «ширине», и мониторит каким-то образом пулы серверов на предмент нагрузки, и вообще мониторит площадки на предмет скорости работы, и меряет каким-то обазом со всех площадок задержки до клиента, и еще много чего делает :D
Копирование — совсем другая тематика.
У нас это умеет автоматически делать софт нашего собственного CDN — кэшировать интеллектуально «горячие» данные (потому как есть золотое правило — 5% контента запрашиваются 95% пользователей — и поэтому очень глупо копировать _все_ данные, а нужно автоматически «горячие» только)
Вес по сути и есть 1/время_отлика_до_DNS. Я просто попытался навести мостик между двумя подходами, что они есть что-то диаметрально противоположное, а между ними есть связь.
Насчет «горячего» согласен, у нас только специфика в том, что «горячий» он разный для разных стран/регионов (в силу локализации контента по языку), поэтому копирование тесно объединено с вопросом выбора ближайшей площадки, а весь контент точно не скопировать.
Насчет «горячего» согласен, у нас только специфика в том, что «горячий» он разный для разных стран/регионов (в силу локализации контента по языку), поэтому копирование тесно объединено с вопросом выбора ближайшей площадки, а весь контент точно не скопировать.
Очень любопытно… А не могли бы вы изложить свои идеи более подробно в отдельной статье. Или хотя бы сказать, к какому источнику обратиться?
хм. интересно даже стало…
можете сказать навскидку, если делать толковый CDN (для CDN-провайдинга), во сколько обойдется корневая площадка (или как ее правильнее называть) и каждый узел?
Ну так, порядок чисел. Естественно, только само железо.
можете сказать навскидку, если делать толковый CDN (для CDN-провайдинга), во сколько обойдется корневая площадка (или как ее правильнее называть) и каждый узел?
Ну так, порядок чисел. Естественно, только само железо.
UFO just landed and posted this here
В России уже появился оператор услуг CDN, доставляющий контент в регионы России — компания NGENIX, которую я имею честь представлять. Поскольку мы являемся полноценным оператором связи и храним полную таблицу Интернет-маршрутизации, мы можем вычислять сервер, с которого надо отдавать контент конечному пользователю более оптимальным способом, чем это описано у вас в статье.
Обращайтесь, если захотите воспользоваться нашими услугами CDN в ваших проектах gorod с_о_б_а_к_а ngenix.net.
Обращайтесь, если захотите воспользоваться нашими услугами CDN в ваших проектах gorod с_о_б_а_к_а ngenix.net.
Мне кажется, этот пост — не место для рекламы своих услуг.
мда. на профессионалов вы никак не тянете.
«определение координат» по метрикам BGP — это очень сильно негарантированный способ.
оно может (и даже должно) использоваться, но лишь как одна из «переменных формулы»
«определение координат» по метрикам BGP — это очень сильно негарантированный способ.
оно может (и даже должно) использоваться, но лишь как одна из «переменных формулы»
Уважаемый shapa, я отнюдь не утверждал, что метрики BGP — это единственная переменная, которая используется у нас для определения того, с какого сервера отдать контент конечному пользователю. Но то, что мы имеем эту переменную (в отличие от «несетевых» CDN), дает нам неоспоримые преимущества.
преимущества перед кем? поставили пяток серверов (судя по карте ;)) ) по россии и считаете что построили полноценную CDN?
в курсе что современные технологии CDN — это применение multicast и прочих умных увещей? :)
в курсе что современные технологии CDN — это применение multicast и прочих умных увещей? :)
— не 5, а 7
— не серверов, а полноценных узлов связи (маршрутизаторы, свитчи, серверы)
— про multicast в курсе и успешно применяем
Нам в России преимуществ действительно пока иметь не перед кем, мы пока единственная в стране CDN. Я говорил про технологические преимущества сетевых CDN (NGENIX, LimeLight и др.) над несетевыми (Akamai, Panther Express и др.)
— не серверов, а полноценных узлов связи (маршрутизаторы, свитчи, серверы)
— про multicast в курсе и успешно применяем
Нам в России преимуществ действительно пока иметь не перед кем, мы пока единственная в стране CDN. Я говорил про технологические преимущества сетевых CDN (NGENIX, LimeLight и др.) над несетевыми (Akamai, Panther Express и др.)
а, 7 :) пардон, очень сильно ошибся :D
можно рассказать, как применяете multicast? правильно ли я понимаю, что файл размещенный в CDN будет мульткастом отдавать клиенту? как быть с тем что большинство российских операторов на multicast забили большой и толстый? :)
насчет «преимуществ в россии» — нашли чем гордиться, право.
CDN уровня и размера вашей — сделать полтора-два месяца максимум, и то только потому что долго «железо» в россию поставляется.
juniper'ы M серии и прочее вообще упоминать — смешно выглядит… Тем паче что как обычно — берут б/у M7 и всем потом рассказывают " а у нас жуниперы стоят!".
BTW мы сейчас для тривиальной social network берем только что вышедшие SRX5800…
Catalyst'ы — нашли чем хвастатяться… Мы от них как от огня бежим, переходим на force10. Cisco скурвилась жесточайшим образом в последние годы.
В общем, как обычно — «Президент Туркменистана Сапармурад Ниязов в великой книге „Рухнама“
с гордостью пишет, что туркмены изобрели колесо, письменность, выплавку
металлов. Никто этого не отрицает. Просто другие народы в это время
выпускали компьютеры и летали на Луну.»
Кто тут в роли Туркменистана и остальных народов — я думаю понятно :)
…
Вы бы лучше рассказали какие storage системы, какой рассчет I/O идет, как масштабируемость предусмотрена…
Вот тогда быть может и похвалим.
можно рассказать, как применяете multicast? правильно ли я понимаю, что файл размещенный в CDN будет мульткастом отдавать клиенту? как быть с тем что большинство российских операторов на multicast забили большой и толстый? :)
насчет «преимуществ в россии» — нашли чем гордиться, право.
CDN уровня и размера вашей — сделать полтора-два месяца максимум, и то только потому что долго «железо» в россию поставляется.
juniper'ы M серии и прочее вообще упоминать — смешно выглядит… Тем паче что как обычно — берут б/у M7 и всем потом рассказывают " а у нас жуниперы стоят!".
BTW мы сейчас для тривиальной social network берем только что вышедшие SRX5800…
Catalyst'ы — нашли чем хвастатяться… Мы от них как от огня бежим, переходим на force10. Cisco скурвилась жесточайшим образом в последние годы.
В общем, как обычно — «Президент Туркменистана Сапармурад Ниязов в великой книге „Рухнама“
с гордостью пишет, что туркмены изобрели колесо, письменность, выплавку
металлов. Никто этого не отрицает. Просто другие народы в это время
выпускали компьютеры и летали на Луну.»
Кто тут в роли Туркменистана и остальных народов — я думаю понятно :)
…
Вы бы лучше рассказали какие storage системы, какой рассчет I/O идет, как масштабируемость предусмотрена…
Вот тогда быть может и похвалим.
Никогда бы не стал брать «только что вышедшее» оборудование, обычно в таком в первые полгода жизни находят хардверные баги, которые лечатся только RMA.
Хорошо хоть source-коды открыть не просите… за похвалу :)
Хорошо хоть source-коды открыть не просите… за похвалу :)
ну, если бы были «в теме» — то SRX построены на junos, которой как сто лет в обед.
а насчет «исходники» — худшее что в таком диалоге может быть — так это «соскакивать» и ерничать начинать пытаться ;)
дело в том что используемое решение (почему-то вы решили похвастастья джуниперами M серии и каталистами :D ) очень сильно влиятет на итоговую надежность и качество сервиса.
а насчет «исходники» — худшее что в таком диалоге может быть — так это «соскакивать» и ерничать начинать пытаться ;)
дело в том что используемое решение (почему-то вы решили похвастастья джуниперами M серии и каталистами :D ) очень сильно влиятет на итоговую надежность и качество сервиса.
Я же писал про хардверные, а не про софтверные баги — у меня никаких претензий к JunOS как раз нет. А вот покупка нового железа — это всегда риск (посмотрите базу данных известных багов Juniper, если у вас есть доступ к их партнерскому сайту).
А по поводу информации о Juniper на нашем сайте — надо же как-то себя дифференцировать от «пионеров», не выкладывая при этом все наши ноу-хау в открытом доступе.
А по поводу информации о Juniper на нашем сайте — надо же как-то себя дифференцировать от «пионеров», не выкладывая при этом все наши ноу-хау в открытом доступе.
доступ есть, багов там в общем-то по последним железкам не супер много.
дифференциация от пионеров — вообще смешно ;)
написать вы можете все что угодно (" доктор — а мой сосед говорит что за день 5-х молодух может! — так и вы говорите...") — но по железу это тупые названия (которые ничего крутого в себе не несут), а вот технологии (которые кстати повторить не смогут пионеры в любом случае) — рассказывают.
почему-то всякие bitgravity с akamai не особо скрывают свои технологии :D
понятно, что если есть know how — их озвучивать нет смысла.
но продавать / рекламировать кота в мешке, особенно на российском рынке…
дифференциация от пионеров — вообще смешно ;)
написать вы можете все что угодно (" доктор — а мой сосед говорит что за день 5-х молодух может! — так и вы говорите...") — но по железу это тупые названия (которые ничего крутого в себе не несут), а вот технологии (которые кстати повторить не смогут пионеры в любом случае) — рассказывают.
почему-то всякие bitgravity с akamai не особо скрывают свои технологии :D
понятно, что если есть know how — их озвучивать нет смысла.
но продавать / рекламировать кота в мешке, особенно на российском рынке…
Категорически не согласен с тем, что Akamai и BitGravity не скрывают своих технологий — у них абсолютно пустые сайты, где кроме обтекаемых маркетинговых фраз ничего нет.
Оставлю это здесь, может кому-то пригодится.
Akamai Globally Distributed Content Delivery
ну и остальное.
Akamai Globally Distributed Content Delivery
ну и остальное.
Более детальная архитектура вышеописанного. Нарисовал сам =), когда делал Hdweb.ru
Sign up to leave a comment.
CDN своими руками или раздача видеоконтента