Раздача тяжелого контента ведется не из внутреней сети, а с кэш-серверов, которые подключаются напрмую к операторам связи, об этом можно почитать в статье моего коллеги Димы Иванова Как устроен CDN RUTUBE: железо, сеть, ПО
При открытии пользователем сайта rutube.ru и работой с ним, как раз и возникает много горизонтального трафика - нужно сходить в базу авторизовать и загрузить его профиль, подгрузить понравившиеся видео и историю просмотра, на основе прошлых просмотренных видео выдать рекомендованные, при начале просмотра пользователем видео, нужно сходить в балансер и выбрать для него оптимальный кэш, при просмотре сохранить моменти, на котором он остановился, чтобы в следующий раз начать с него, все это и многое другое происходит через интеграцию между серивсами внутри платформы, отсюда и горизонтальный трафик.
на момент, когда использовались микротики с BGP, мы принимали от провайдеров default или default + их префиксы, сейчас уже стоят BR'ы, которые могут держать несколько FW, про перенос правил с максимальным количеством трафика на микротиках в начало я так же упомянал в статье
Вы правы, моя команда ранее не работала с этим оборудованием, поэтому мы сразу прошли базовое обучение MTCNA, после этого процесс настройки для нас значительно упростился
любой условно "бесплатный" сервис живет за счет рекламы, у вас есть выбор - смотреть рекламу или заплатить за подписку и не смотреть ее (собственно тот же youtube работает так же), вы можете скачать какой-то свежий фильм на торренте и скорее всего обнаружите там ту же рекламу, потому как те, кто его для вас озвучивал и выложил, как ни странно тоже хотят получать деньги за свою работу
архитектура leaf+spine в нашем случае была выбрана из-за ориентации платформы на бОльший трафик в пределах одного ЦОДа, а так же на концепцию, что в случае падения одного из ЦОДов, другие должны полностью взять на себя его нагрузку. В пределах одного ЦОДа передается очень большой объем трафика - помимо собственно трафика самого сайта rutube.ru, это базы данных, логи, транскодированное видео, видео с файлового хранилища, трафик из файлового хранилища на кэш-сервера 1 уровня итд. в случае если бы мы использовали традиционную архитектуру без leaf+spine и распределенного шлюза, нам пришлось бы ставить очень мощные роутеры для ядра сети в каждом ЦОДе с большим количеством каналов в сторону коммутаторов, а еще нужно держать всегда резерв для роста трафика, а еще как я писал в статье задержки при использовании традиционной 3х уровневой архитектуры значительно выше, особенно к ним чувствительны современные БД с репликацией. Ну и в конце концов - роутеры были бы единой точкой отказа для всего ЦОДа.
Подробнее можно ознакомиться с нашей архитектурой в статьях моих коллег:
В случае если у вас много небольших инстансов, возможно имеет смысл не завязывать все их на одно ядро, а просто поставить в каждом пару простых роутеров с 2я резервными каналами, вам не нужны будут жирные каналы до единой точки - ядра и в случае при проблемах в одном из кампусов, остальные останутся в работе.
да, cli вы определили верно, требования по импортозамещению нам конечно озвучивают, в следующем году планируем начать интероп тесты, так как сами понимаете, разом заменить все сетевое оборудование на такой большой сети не представляется возможным, будем делать это постепенно
Спасибо! частично инфраструктура RUTUBE на тот момент действительно работала на оборудовании Cisco, но это было арендованное оборудование у партнера холдинга и мы быстро от него отказались при начале модернизации
вы правы, потому мы и начали оптимизацию сети в том числе и с расширения каналов сейчас DCI - 400G, об этом как раз говориться в статье, а микротики отлично справились со своей задачей на время построения новой сети
Раздача тяжелого контента ведется не из внутреней сети, а с кэш-серверов, которые подключаются напрмую к операторам связи, об этом можно почитать в статье моего коллеги Димы Иванова Как устроен CDN RUTUBE: железо, сеть, ПО
При открытии пользователем сайта rutube.ru и работой с ним, как раз и возникает много горизонтального трафика - нужно сходить в базу авторизовать и загрузить его профиль, подгрузить понравившиеся видео и историю просмотра, на основе прошлых просмотренных видео выдать рекомендованные, при начале просмотра пользователем видео, нужно сходить в балансер и выбрать для него оптимальный кэш, при просмотре сохранить моменти, на котором он остановился, чтобы в следующий раз начать с него, все это и многое другое происходит через интеграцию между серивсами внутри платформы, отсюда и горизонтальный трафик.
В общих чертах архитектуру сервиса обрисовал мой коллега Эльдар Ниязов в этой статье - Архитектура национального видеохостинга: путь RUTUBE к 10 Тбит/с с использованием своей CDN
на момент, когда использовались микротики с BGP, мы принимали от провайдеров default или default + их префиксы, сейчас уже стоят BR'ы, которые могут держать несколько FW, про перенос правил с максимальным количеством трафика на микротиках в начало я так же упомянал в статье
Проблемы могут быть связаны с маршрутизацией у вашего или вышестоящего оператора связи, напишите на help@rutube.ru, мы попробуем разобраться
Вы правы, моя команда ранее не работала с этим оборудованием, поэтому мы сразу прошли базовое обучение MTCNA, после этого процесс настройки для нас значительно упростился
скорее всего причина во включенном VPN
любой условно "бесплатный" сервис живет за счет рекламы, у вас есть выбор - смотреть рекламу или заплатить за подписку и не смотреть ее (собственно тот же youtube работает так же), вы можете скачать какой-то свежий фильм на торренте и скорее всего обнаружите там ту же рекламу, потому как те, кто его для вас озвучивал и выложил, как ни странно тоже хотят получать деньги за свою работу
спасибо за вопрос по делу:)
архитектура leaf+spine в нашем случае была выбрана из-за ориентации платформы на бОльший трафик в пределах одного ЦОДа, а так же на концепцию, что в случае падения одного из ЦОДов, другие должны полностью взять на себя его нагрузку. В пределах одного ЦОДа передается очень большой объем трафика - помимо собственно трафика самого сайта rutube.ru, это базы данных, логи, транскодированное видео, видео с файлового хранилища, трафик из файлового хранилища на кэш-сервера 1 уровня итд. в случае если бы мы использовали традиционную архитектуру без leaf+spine и распределенного шлюза, нам пришлось бы ставить очень мощные роутеры для ядра сети в каждом ЦОДе с большим количеством каналов в сторону коммутаторов, а еще нужно держать всегда резерв для роста трафика, а еще как я писал в статье задержки при использовании традиционной 3х уровневой архитектуры значительно выше, особенно к ним чувствительны современные БД с репликацией. Ну и в конце концов - роутеры были бы единой точкой отказа для всего ЦОДа.
Подробнее можно ознакомиться с нашей архитектурой в статьях моих коллег:
Архитектура национального видеохостинга: путь RUTUBE к 10 Тбит/с с использованием своей CDN
Как устроен CDN RUTUBE: железо, сеть, ПО
Собственное файловое хранилище для 400 Пбайт видеоконтента
В случае если у вас много небольших инстансов, возможно имеет смысл не завязывать все их на одно ядро, а просто поставить в каждом пару простых роутеров с 2я резервными каналами, вам не нужны будут жирные каналы до единой точки - ядра и в случае при проблемах в одном из кампусов, остальные останутся в работе.
да, cli вы определили верно, требования по импортозамещению нам конечно озвучивают, в следующем году планируем начать интероп тесты, так как сами понимаете, разом заменить все сетевое оборудование на такой большой сети не представляется возможным, будем делать это постепенно
трафик транскодеров, файлового хранилища или кэш-серверов нет смысла загонять на NGFW, это террабиты, там вполне хватает обычных ACL
да, держат, мы не пускам туда весь трафик, в основном только в/из внешнего мира, "тяжелые" данные ходят мимо, их шлюзы терминируются на фабрике
А что конкретно вы считаете "мраком в текущих реалиях" из того, что описано в статье?
Спасибо! частично инфраструктура RUTUBE на тот момент действительно работала на оборудовании Cisco, но это было арендованное оборудование у партнера холдинга и мы быстро от него отказались при начале модернизации
вы правы, потому мы и начали оптимизацию сети в том числе и с расширения каналов сейчас DCI - 400G, об этом как раз говориться в статье, а микротики отлично справились со своей задачей на время построения новой сети