Мы раскроем принципы нашей инфраструктуры и архитектуры, расскажем про используемые решения, поделимся опытом решения рутинных и совершенно нестандартных проблем и, конечно же, выслушаем все претензии и предложения.
Перед тем как рассказать о том, что представляет собой Rutube сегодня, хотелось бы провести небольшой экскурс в историю.
Юные годы: создание и переезд в Москву
Видеоплатформа и сайт («Зеленый» RuTube, на корпоративном сленге) были придуманы и разработаны в городе Орёл, компанией Inventos.
В 2008-ом году проект приобрёл «Газпром-Медиа Холдинг», и начался набор новой команды в Москве, но до конца 2009-го года поддержка осуществлялась орловскими разработчиками.
Заметки на полях: несмотря на то, что московская команда была собрана из специалистов, в целом имеющих опыт работы с высоконагруженными системами, опыта работы с видео у них было мало — поэтому идеи и наработки, с которыми был куплен проект, пришлось постигать и переосмыслять практически с нуля.
Признаемся — некоторые решения, используемые в переработанном виде и по сей день, были оценены по достоинству далеко не сразу.
Интересно, что значительная часть команды сейчас — из этого, первого, московского «призыва».
Вот как выглядела архитектура проекта осенью 2008 года, в момент приобретения Газпром-Медиа Холдингом.
Язык разработки — Perl. Данные хранились в MySQL, для работы с которой был написан свой ORM. В качестве кэша использовали memcached. Для хранения видеофайлов использовалось несколько 4-х юнитовых серверов SuperMicro, с 16-ю дисками по 1 Тб каждый, объединённых в RAID-5 массив. У каждого сервера был свой дублёр, на котором содержалась точная копия данных. Репликация происходила по DRBD (блочное копирование).
Заметки на полях: есть множество примеров успешной эксплуатации подобных решений — схема очень проста, не требует больших вложений и знания каких-то хитрых инструментов, однако обладает рядом недостатков. Выход из строя любого диска приводит к деградации производительности массива, а в случае выхода из строя всего мастер-сервера, нагрузка по обслуживанию клиентского трафика ложится на реплику. После возвращения в строй мастер-сервера, нагрузка увеличивается за счёт реплицирования данных в обратную сторону, что тоже не добавляет радости.
Создание полной реплики 16-ти терабайтного массива в таких условиях занимало примерно месяц. При этом был риск остаться без живой реплики.
Управлялось всё это хозяйство инструментом, получившим название FileCluster — это была база данных MySQL с интерфейсом на Perl. В базе хранилась вся информация о видеофайлах, а именно, на каких конкретно машинах они лежат. Идея FileCluster заключалась в предоставлении пользователю абстрактного слоя, позволяющего выполнять операции заливки, удаления и чтения файлов из некой сущности, логически объединяющей все физические хранилища.
Всё общение вспомогательных машин (например, энкодеров) с хранилищем происходило через FileCluster.
Файлы между серверами передавались с помощью специальной утилиты, написанной на основе libssh, по, как нетрудно догадаться, ssh.
Заметки на полях: в целом, FileCluster решал множество проблем — позволял уйти от обращения к конкретным физическим хранилищам и избавлял от необходимости плодить на всех машинах большое количество маунт-пойнтов. Однако, имел ряд серьёзных недостатков — например, из-за отсутствия возможности перераспределения контента по хранилищам, после ввода в эксплуатацию новых, на них ложилась повышенная нагрузка.
В качестве протокола для раздачи видео использовался протокол HTTP (progressive download). Надо заметить, что в те времена (2008 год) альтернативой для воспроизведения во flash был только RTMP.
Система видеоотдачи была построена по принципу storage-cache (origin-edge в терминологии Adobe). Клиенты получают видео с кэш-серверов. Если же запрашиваемый файл отсутствует в кэше, отправляется запрос к хранилищу, а ответ кэшируется. Это очень гибкая схема, позволяющая достаточно просто реализовать географически распределённую сеть доставки контента (CDN).
Основой видеоотдачи была ещё одна оригинальная разработка — специальный демон, на основе libevent, получивший название VideoD. Демон написан на C++ с использованием STL.
Старожилы рунета наверняка помнят, что видео RuTube в те времена упаковывалось в свой собственный формат iflv. Формат представлял собой обычный flv-файл, с метаданными о количестве ключевых кадров и их расположении. Такой файл было невозможно воспроизвести стандартными средствами, зато VideoD мог запросить любой фрагмент видео. На фронте проекта располагались несколько серверов с запущенным VideoD. При запросе видео, VideoD обращался к хранилищу, доставал необходимый файл или его фрагмент, и отдавал клиенту.
Для реализации byte range запросов и кэширования, на всех машинах, образующих хранилище, также были запущены инстансы VideoD, в специальном режиме. Фрагменты файлов, полученные с хранилища таким образом, сохранялись на кэширующих серверах и, при повторных запросах, отдавались уже оттуда.
Заметки на полях: хотя один инстанс VideoD мог обслуживать несколько клиентов, демон был однопоточным, поэтому любая операция чтения с жёсткого диска блокировала все прочие. По этой причине на всех отдающих серверах были установлены сетевые интерфейсы с пропускной способностью 1 гигабит — большего в те времена просто не требовалось.
Гибкость схемы storage-cache достигается за счёт усложнения системы балансировки нагрузки на кэширующие серверы. Для эффективной работы балансера необходимо постоянно отслеживать состояние всей системы, собирая и анализируя большое количество метрик: доступность кэш-серверов, трафик на их сетевых интерфейсах, загрузка дисковой подсистемы, просматриваемые в настоящий момент ролики, частота запроса конкретных роликов (популярность), распределение запросов по регионам и многое другое. Система балансировки образца 2009 года была реализована на базе Perlbal в виде специального плагина и умела отслеживать только одну метрику — популярность роликов.
На основании этой метрики, система балансировки выбирала группу серверов, на которых должен кэшироваться контент. Для получения ссылки на файл, балансер обращался к кэшу (memcached). Если данных в кэше не было, балансер обращался к бэкенду (FileCluster), который обрабатывал запрос и складывал данные в кэш, а затем балансер повторно обращался к кэшу.
Если всё шло хорошо, то данные успешно попадали в кэш и, при повторном обращении, балансер их получал. Если возникали какие-то проблемы (обычно очень не вовремя), и при повторном обращении в кэше всё ещё не было данных, то пользователь видел печальное сообщение о том, что видео в данный момент недоступно. Стоит отметить, что уже в то время система балансировки представляла собой отдельную сущность, что в дальнейшем позволило нам перестраивать видеоплатформу, не внося серьёзных изменений в бэкенд.
Вся нагрузка распределялась между двумя площадками. В основном ЦОДе было 48 серверов, и ещё 16 в Ростелекоме. Все серверы находились за IPVS, с помощью которой и обеспечивалась отказоустойчивость — «упавшие» машины просто не попадали в выдачу.
Заметки на полях: может показаться, что не всё было сделано оптимально. Но следует принять во внимание тот факт, что Inventos были своего рода первопроходцами, и многие решения, кажущиеся сейчас странными, в далёком 2008 году выглядели оправданными и порой единственно верными. В любом случае, эта архитектура позволяла обслуживать около 20 тысяч одновременных пользователей, при суммарной нагрузке 25 гигабит.
Rutube сегодня
C 2009 года в архитектуре проекта произошли глобальные изменения, основные из которых пришлись на 2012-2014 гг. Были полностью переписаны сайт и сама видеоплатформа.
В качестве основного инструмента разработки используется Python и фреймворк Django. Все независимые задачи (конвертация видео, статистика, поиск дубликатов, сайт) разнесены между самостоятельными сервисами, которые взаимодействуют между собой через RPC на основе Celery. Для организации очередей сообщений был выбран beanstalk, но позже было принято решение отказаться от него в пользу RabbitMQ, который сейчас и обеспечивает большую долю транспорта между сервисами. Взаимодействие с RabbitMQ сделано с помощью Celery. Кэширование организовано через Cacheops + Redis. Для поиска используется Sphinx.
Основная база данных — по-прежнему MySQL, но некоторые проекты усиленно поглядывают «налево» в поисках нового спутника жизни.
Все компоненты платформы дублируются в двух дата-центрах. Организована репликация master-master между основными базами данных, также подняты отдельные реплики master-slave для всех сервисов, создающих значимую нагрузку на чтение — например, для статистики.
Хранилище
FileCluster был заменён на новый инструмент, который мы назвали FileHeap. FileHeap представляет собой почти классическую реализацию SDS (software defined storage). Написано всё на Python, в качестве базы данных используется MySQL. Для хранения файлов используются недорогие 2-х юнитовые серверы с 16 Гб оперативной памяти, одним 6-ти ядерным процессором и 12-ю дисками по 4 Тб каждый. Также в этой схеме присутствует Царь-Диск — NetApp, доставшийся в наследство от FileCluster. От NetApp мы планируем избавиться в самое ближайшее время, как только нарастим объём недорогих хранилищ до необходимого размера. Все серверы, используемые для хранения файлов, разнесены по двум дата-центрам. На случай ядерной войны, FileHeap всегда создаёт три копии каждого объекта, две из которых обязательно физически находятся в разных дата-центрах.
FileHeap воспринимает каждый жёсткий диск как отдельное хранилище и следит за равномерным заполнением всех доступных ему дисков. Такая схема позволяет нам легко расширять хранилище в соответствие с нашими потребностями, а также без проблем заменять выходящие из строя жёсткие диски.
Загрузка файлов и конвертация
Для загрузки файлов и конвертации существует отдельная группа машин, также равномерно разделённая между двумя дата-центрами. Сервис, отвечающий за конвертацию, разработан на основе библиотеки Celery. Для конвертации используется ffmpeg. Транскодинг каждого качества запускается отдельным процессом и, как правило, на разных серверах, поэтому в случае, если конвертер «умер», существует ненулевая вероятность, что исходник сохранился на другом конвертере, и в итоге задача завершится без ошибок. Передача файлов между конвертерами происходит по WebDAV, в качестве сервера используется nginx.
Для управления группой конвертеров был разработан специальный сервис, который назвали Duck (Download, Upload and Convert King). С его помощью осуществляется мониторинг работы конвертеров, управление очередями задач, удаление и повторная постановка на обработку, а также ввод в систему новых машин для конвертации.
Балансировка и CDN
Балансировка отдачи видеофайлов реализована на Python с использованием библиотеки Py3 asyncio. На серверах группы балансировки работают несколько демонов, которые занимаются мониторингом работоспособности всех отдающих серверов и следят за состоянием канала. Помимо этого, балансер хранит информацию о просмотрах и популярности роликов. Все эти параметры используются для принятия решения о том, с какого сервера быстрее отдать запрошенный пользователем контент. Обмен данными между серверами балансировки организован через Redis.
При запросе видео, если в кэше нет данных о размещении ролика, балансер обращается к FileHeap и формирует ссылку для кэширующего сервера, по которой можно получить необходимый файл с физического хранилища.
У Rutube есть несколько точек установки кэширующих серверов для видеоотдачи. В Москве они размещены в трёх дата-центрах. Треть серверов предназначена для «горячего» контента (популярные ролики, например, «Интерны»). На «горячих» серверах подняты сетевые интерфейсы с пропускной способностью до 80 гигабит, на «холодных» — до 40. Помимо этого, есть несколько точек, обслуживаемых другими операторами связи — одна точка в Красноярске и две в Ереване. Сейчас мы активно работаем в направлении расширения нашей сети доставки.
После инфраструктурного объединения с live-платформой (разработанной компанией ГПМ-Технолоджи) и перехода кинотеатра NOW.ru на платформенный плеер, на начало октября 2015 года платформа Rutube обслуживает до 350 тысяч одновременных просмотров видео по требованию (VOD) и до 65 тысяч одновременных live-потоков, при суммарном трафике 700 гигабит.
Но это далеко не предел — ведь админы закупают серверы, Холдинг открывает новые каналы, а разработка пишет код.
Комментарии (54)
ZoomLS
21.10.2015 12:46+22Скоро уже 2016 год, а у вас до сих пор только через Flash ролики работают. Представляете сколько возможной нагрузки проходит мимо вас? ;)
tumbler
21.10.2015 12:53+6Еще через HLS и byte-range http со своей системой кэширования.
«Хром» грянул со своим отключением флеша, и руководство выделило ресурсы на переезд на MPEG/Dash. Так что в новый год — с новым протоколом (если взлетит)
Aquary
22.10.2015 05:53Можете ли дать расклад — для каких клиентов какие протоколы используются как дефолтные? Т.е. понятно например, что iOS — это HLS, без вариантов. Когда используется iflv и когда — progressive download?
calorie
22.10.2015 08:30+3iflv уже нигде, сейчас основной протокол для Flash — HDS (a до этого еще был RTMP). Про iOS вы правы, а дальше остается самый интересный зоопарк устройств — Android, телевизоры, приставки. Для них по дефолту пробуем проиграть HLS, если нет — то даунгрейд до byte-range. Но бывают сюрпризы: например у Samsung на некоторых exynos и некоторых прошивках HLS проигрывается только при выключенном wi-fi. А у ряда телевизоров, при заявленной поддержке HLS, автоподбор качества сопровождался появлением «черного экрана» — оставили им HLS, но с одним качеством в плейлисте.
Reeze
21.10.2015 13:31+16Rutube еще существует? Последний раз заходил туда года 4 назад или больше. Чем он лучше YouTube?
calorie
21.10.2015 15:23Совсем не обязательно заходить на rutube.ru — наш плеер есть на многих ресурсах (в web, мобильных приложениях и в телевизорах), иногда в white label)
Turbo
22.10.2015 00:22+3Несколько лет назад (если не изменяет память в 2007-2008) ролики с проекта реально часто встраивали в том же ЖЖ и на других сайтах примерно с такой же частотой что и Youtube. Мне кажется при грамотном развитии могли бы продолжить ряд, Facebook — VK, Google — Yandex, Youtube — Rutube (?). Но сайт во-первых стал заметно лагать, а во-вторых стал просто перегружен рекламой. При этом качество и удобство Youtube расло, а на Rutube нет. В итоге имеем то что имеем: Youtube деофлтный видеохостинг в России.
Пишу, потомучто сам в своем блоге регулярно выкладывал ролики именно с Rutube, но в итоге пришлось от него отказаться. Более того в какой-то момент поменялся код встройки и всё старое что было встроенным, оказалось нерабочим.Selenius
22.10.2015 00:46-3С 2008 года очень многое поменялось. Попробуйте ещё раз, вдруг понравится.
Насчёт удобства — скажите, чего именно не хватает, вдруг оно уже есть или появится в ближайшее время? :)
dmitrysamsonov
21.10.2015 13:57+3А сколько реально могут отдать трафика серверы с «пропускной способностью до 80 гигабит»? Интересно было бы узнать подробности, как вам это удалось.
Особенно как решали проблему с ростом softirq.
myc
21.10.2015 15:44+2Исторический максимум был около 77Gbps. При это idle уходил в 0.
Сейчас мы стараемся держать трафик в пределах 75-85% от пропускной способности.
С softirq особо не боролись.
Ограничились только равномерным разбрасыванием irq по CPU/тредам и без привязки к numa-нодам.
В каждом и таком сервере установлено по 2 10-корника Intel Xeon CPU E5-2660 v2 @ 2.20GHz с включенным гипертредингом. Как ни странно, но включение гипертрединга ощутимо помогает.
Из странных моментов можно отметитьdmitrysamsonov
21.10.2015 15:48А какие карты используете?
privatelv
21.10.2015 14:08+1Напишите пожалуйста как трафик балансируется между CDN точками? (технология и логика отправки запроса пользователя на конкретную машину)
Как вы понимаете, что раздачей трафика с конкретной точки вы делаете пользователям лучше (Собираете ли вы статистику с клиента и если да то какую)?tumbler
21.10.2015 14:41На 7 уровне балансер использует привязку IP-сетей к CDN-точкам. Список сетей собирается, если не ошибаюсь, на основе BGP. При выборе «Москва» или «Ереван» логика вполне очевидная :-). Технология — выдача пользователю конечной ссылки на edge-сервер, который кэширует контент, полученный с ориджинов в Москве. Статистика собирается с плеера, там все задержки, ошибки и основные события проигрывания контента и рекламы — анализируется аналитиками оффлайн.
Selenius
21.10.2015 15:54Да, сети собираем по BGP. Сейчас конструкция дорабатывается, так как список узлов растёт.
ishevchuk
21.10.2015 14:24+1На «горячих» серверах подняты сетевые интерфейсы с пропускной способностью до 80 гигабит, на «холодных» до 40.
Вы используете 40G карточки? Если да, то какие? :)myc
21.10.2015 15:50+1Нет. Мы сейчас используем intel X520 2x10G.
40G карточки от Intel, Mellanox, Chelsio пока еще ведут себя плохо на реальной нагрузке.
phprus
21.10.2015 19:15> 40G карточки от Intel, Mellanox, Chelsio пока еще ведут себя плохо на реальной нагрузке.
А в чем это выражается?
И, скажите, пожалуйста, какие настройки Ваших 10GE карточек Вы используете?Selenius
21.10.2015 20:01Это выражается, например, в спонтанных прерываниях передачи данных.
Или невозможностью выжать с карточки больше половины производительности.
Selenius
21.10.2015 16:21Сейчас уже 100G на подходе. :)
monah_tuk
22.10.2015 08:13Это как с USB3: уже 3.1 и TypeC на подходе (точнее даже есть уже), а драйвера почти под все контроллеры 3.0 до сих пор сырые даже под виндой. Хотя и сами контроллеры — тоже.
Selenius
22.10.2015 13:09Ну тут ситуация такая: 40G более-менее прижился только на коммутаторах для внутренних нужд ЦОД, со стороны железа для маршрутизации его поддержка сильно ограничена. С карточками, хотя 40G как стандарт уже достаточно давно существует, стабильности пока тоже нет.
А вот 100G с новыми, достаточно компактными модулями, появляются и там, и там. Плюс первые карточки на 100G для серверов уже практически доступны. И есть подозрение, что производители своё внимание перенесут именно на стандарт 100G. А 40G останется достаточно нишевым решением.
Мы пока нигде 100G в сети не используем (думали про магистральную часть), но вызвано это было чисто трезвым расчётом — зачем покупать 100G, которые нельзя передать через пассивный DWDM, если 10х10G прекрасно через него передаются (у нас есть места, где имеются агрегаты 32х10G), стоят дешевле и прекрасно поддерживаются всем оборудованием.
Но на ближайшее будущее (1-2 года) мы считаем, что 100G станет подходящим для нас стандартом.
xandr0s
21.10.2015 15:16+1Похоже, все рано или поздно проходят через drbd и хапают сполна на сплит-брейнах ))
porutchik
21.10.2015 21:44FileCluster был заменён на новый инструмент, который мы назвали FileHeap. FileHeap представляет собой почти классическую реализацию SDS (software defined storage).
FileHeap воспринимает каждый жёсткий диск как отдельное хранилище и следит за равномерным заполнением всех доступных ему дисков. Такая схема позволяет нам легко расширять хранилище в соответствие с нашими потребностями, а также без проблем заменять выходящие из строя жёсткие диски.
MogileFS не рассматривали? :)tumbler
22.10.2015 09:57Смотрели на пару сторонних open-source решений, которые на тот момент существовали, но быстро поняли, что все-таки нужна внутренняя разработка. Во-первых, со стороны админов было несколько требований по служебным задачам, которые FileHeap должен выполнять в фоне; во-вторых, должна быть поддержка доступа к файлам в обход слоя SDS, в частности, сами стораджи являются ориджинами для видеоотдачи и достаточно требовательны к эффективности ФС.
itforge
21.10.2015 22:00Насколько стабильно работает celery? Есть какие-нить глюки?
FileHeap асинхронный? Какую библиотеку используете для асинхронности?tumbler
22.10.2015 10:03Celery вообще достойно отдельной статьи про то, что там есть, и чего там нет. Если кратко — celery стабильна, функциональна и обширно документирована. Что не мешает раз в месяц заниматься диким дебаггингом всяких странностей. Ну вот например, если в проекте настроены несколько приложений celery одновременно, то сериализацией будет заниматься то приложение, которое было импортировано первым, а не то, которое сейчас ставит или обрабатывает задачи. Или вот авторы
запрещают«deprecate-ят» apply_async задачи приложения А в контексте выполнения задачи приложения B, при этом обещают это напрочь запретить в 3.2.
Но в целом — все попытки написать свою систему выполнения асинхронных задач у нас в конечном итоге вылились в «короче переезжаем на celery».
tumbler
22.10.2015 10:06FileHeap — синхронный, это вообще django-приложение с celery-like придатком и HTTP интерфейсом (слой файловой системы а-ля SDS нам в результате вообще не нужен оказался). Единственное асинхронное что там есть — это хитрый хак к nginx, чтобы предотвратить избыточное чтение файла при загрузке (nginx — requestcache — uwsgi — final_file).
tapin13
22.10.2015 01:45+4Спасибо за статью, интересно.
Не пользуюсь вашим сервисом уже очень давно, причины просты, сколько не заходил, все время медленная работа. В связи со статьей и вроде как какими-то изменениями решил посмотреть, как там оно…
Зашел с главной в 3-5 разных видео, везде вижу надпись «Просмотр запрещен по требованию правообладателя. Видео доступно на территории РФ...». Внимание вопрос, мой IP вы определили при заходе на сайт. Так сложно выдавать видео ролики которые я ДА могу просмотреть, не будучи в РФ...? В общем после очередного посещения, понял, что снова готов еще пару лет не заходить на ваш ресурс.tumbler
22.10.2015 10:15+2Рискую нарваться на пачку минусов, но все-же отвечу.
Правообладатели, к сожалению, требуют достаточно жестких условий по недоступности контента, от этого никуда не деться, как и от рекламы. Все технари у нас понимают, что всё это отпугивает пользователей, но стараются придумывать другие фишки, которыми можно привлечь пользователей — андроид-приложение, вообще было личным проектом изначально, к примеру.
По поводу фильтрации роликов: во-первых, КонКуренты этого тоже не делают насколько я знаю, но Вы ведь к ним на пару лет не перестанете ходить? И даже если убрать лицензионный контент, недоступный в Вашем регионе — Вы увидите кошечек, трэш и аниме. Останетесь и сделаетесь нашими фанатами?
А вообще приятно, что из всех комментариев большинство касается не «этической стороны», а технической. Ради них и будем продолжать публикации.tapin13
22.10.2015 11:41+2признателен Вам за ответ.
КонКуренты этого тоже не делают
— так давайте будем лучше конкурентов? )
Вы ведь к ним на пару лет не перестанете ходить?
— не будем лукавить, что бы посмотреть видео я захожу на ютую, где и быстро (быстрее чем у вас, я вчера таки нашел пробный ролик который попытался посмотреть и несколько раз перепрыгнуть в разные части ролика, увы, у вас это медленно) и с правами я там натыкался может пару раз за много лет.
Вы увидите кошечек, трэш и аниме
— хм… вы и меня поймите около 10 кликов на совершенно разные видео, и ни одно я не могу посмотреть… от чего я перестану заходить на ваш ресурс от видео которые я сам выбрал про кошечек, которое я могу посмотреть ли 10 возможно мне интересных, но которые я не могу посмотреть. Мало того, если бы все упиралось хотя бы в оплату платного аккаунта, я бы еще понял, но как вы понимаете менять свое гео положения я не собираюсь.
Удачи вам, возможно мои замечания окажутся полезными и ваш сервис таки переплюнет ютуб и прочих буржуев )
lonelysuch
22.10.2015 11:41А вообще приятно, что из всех комментариев большинство касается не «этической стороны», а технической. Ради них и будем продолжать публикации.
Это уже какой то шантаж. Так же, как и низкое качество при включении AdBlock. А самое смешное, что отключая AdBlock для RuTube — все равно видишь ограничение на качество. Получается, что вам пофиг на настройки AdBlock? Вам важно, что он есть в браузере?calorie
22.10.2015 12:04О нет, такого быть не должно (только если у видео в реальности не только одно качество)! Пожалуйста, в случае такой ошибки отправьте сообщение об ошибке из плеера.
lonelysuch
22.10.2015 12:14Я именно о сообщении в плеере:
C AdBlock: imgur.com/p6UxIwM
Без AdBlock: imgur.com/JvmzkdK
Хорошо, спасибо. Напишу.
calorie
22.10.2015 12:24+ кажется не самая удачная формулировка: «Ради них» — это ради технических камментов и пожеланий) К которым, как раз и относится вопрос про «запрещенный» контент.
Кстати, небанальность этой задачи обусловлена наличием очень широких возможностей по распространению контента (думаю про это мы расскажем в статье про dashboard.rutube.ru):
* контент может открываться в разное время на разных ресурсах в разных странах;
* в каких-то странах доступен по платной модели, в других — по рекламной.
(Правда по платной модели пока доступны только несколько роликов в моем канале)))
tapin13
22.10.2015 13:19Если будете писать еще, возможно остались какие-то фото дата центров или офиса, еще с Орла или начало в Москве, было бы интересно посмотреть, как это все было. Спасибо.
Hamsters
26.10.2015 14:44В процессе. :) Фотографии, конечно, сохранились, думаю, что опубликуем в ближайшее время.
Begetan
26.10.2015 00:42-1Для меня ролик RuTube всегда означал только одно — проигрываться будет медленно, настолько медленно, что смотреть без прерываний будет невозможно. После этой статьи стало понятно почему.
Система Google Global Cache насчитывает, пожалуй, уже тысячи точек с десятками тысяч серверов.
Запустите на пограничных маршрутизаторах статистику трафика по netflow и сделайте агрегацию по номеру AS ( автономной системы). Выберите AS с трафиками больше 1-10 Гбит и начинайте договариваться с операторами о размещении серверов. Центральная точка должна вообще только обслуживать кеши! Эффективность кеширования у Гугла достигает 70-80% плюс драматически падает задержка.
Поставьте на каждом континенте как минимум по одному кластеру своего кеша в — на нем и отработаете все технологии. То же самое должно быть хотя бы в в каждом федеральном округе! Кстати у Гугла давно уже двухуровневая схема кеша!
Если всего вышеперечисленного не сделать, то скоро ваше имя забудут даже те кто знал. Останется вам уповать только на блокировку Гугла в России.myc
26.10.2015 08:32+2Из каких таких глубин пишешь ты сюда, друг мой сверхбыстрый?
Мы уже лет пять играемся с CDN-ами.
1. Видео-трафик не особенно чувствителен к задержкам.
2. В большинстве случаев, если у пользователя хреново качается из Москвы через магистралов, то из CDN тоже будет хреново.
Дело в том, что в Росси большинство операторов последней мили как правило ограничиваются линками с магистралами и не участвуют в ix, где обычно ставятся CDN-провайдеры.
Так что покупать CDN для доставки и видео дорого и бестолково.
Мы же начали строить свой CDN только, чтобы немного сократить затраты на каналы.
Сейчас мы договаривамся с операторами, но пока процесс идет неспешно.Begetan
27.10.2015 20:10Пишу я из Европы, на вашей карте сети такого места судя по всему не существует. Обидно не за уровень международного развития крупных национальных игроков, типа Яндекса или Рутуба. Обидно, что сама мысль о необходимости развития вызывает раздражение.
Selenius
Наконец-то и про нас есть статья!