fillest
cdn ? Посоветуйте проверенный cdn, имеющий узлы в рашке? Чтоб латенси не скакало периодически как хохол. В идеале, чтоб ещё было нормальное апи для сброса кеша, и кеш сбрасывался не часами. Чтоб были графики rps, кроме тупейшего объёма трафика. Но ключевое и достаточное, конечно, чтоб стабильное низкое латенси было.
OCTAGRAM
парсинг cdn видео PlayWire оказался каким–то замороченным по сравнению с другими хостингами. URL у них неочевидные. Для тех, кто тоже парсит сайты с видео, вдруг пригодится. Mне сейчас известны 3 вида JSON URL'ов:
zeus.json, online
player.json, online
config.json, online

Причём, первые два — на config.playwire.com, а третий — на cdn.playwire.com, а я, читая не выполняющуюся часть кода JavaScript, пытался налепить на первый домен.
В своей работе я нашёл наиболее полезным zeus.json, в нём наибольшее количество желаемой информации: и длина, и постер, и ссылка на manifest.f4m. Я поначалу этот f4m проигнорировал, мол, а зачем мне HDS, если я знаю, как делать ссылки вида cdn.phoenix.intergi.com . Напрасно. Во–первых, узнал, что manifest.f4m — не обязательно HDS, а может быть и сборник прямых ссылок на mp4. Большинство последних видео сейчас всё же залиты по моему шаблону, так что заказчик был доволен, заплатил, но процентов 15% видео криво спарсились из–за того, что я не смотрел в f4m. Некоторые видео залиты под другим адресом, пример выше как раз такой. Если посмотреть в config.playwire.com можно сконструировать URL вида cdn.playwire.com , и этот URL работает. У большинства видео, впрочем, f4m такой: config.playwire.com , здесь есть 2 формата видео, для мобилок и обычный, и адрес у обоих по шаблону.
Некоторый интерес может представлять config.json, там дан rtmp адрес, вдруг кому–то это именно то, что нужно.
Нулевой или отсутствующий duration — видимо, бывает, как раз у видео старого образца. Видео может быть нормальным, но вот длина неизвестна, если, конечно, сайт с видео не предоставил её каким–то другим образом.
Постеров, на самом, деле, похоже, может быть 10. Если URL постера выглядит так: cdn.phoenix.intergi.com , то последнюю цифру можно менять от 0 до 9 или ставить по рандому. Про другие URL постеров не скажу, но ситуация может быть похожая. Очень может быть, что всё отличается от клиента к клиенту.
Melhior
cdn Пока единственный cdn с правилом — зашел на сайт,создал аккаунт и сразу работай это cdn77. Остальные это бюрократия с менеджерами на пару недель.
Melhior
cdn У меня такое чувство что конторам доставляет удовольствие "для прайса и подключения пишите". Единственная западная контора у которой можно все включить и настроить через сайт это cdn77. У нас вобще этого нет. Видимо любят люди платить "персональным менеджерам" и "инженерам" вместо того чтобы просто оплатить создание автоматизации. Да и мелкие конторы бы потянулись на попробовать.
korchasa
охуеть cdn Судя по наколеночным расчетам, Dropbox генерирует около террабита траффика. Не удивлюсь, если они начали строить свои ДЦ, и будут слезать с Амазона.
korchasa
dev cdn Планируем логику раскладывателя по дискам. 
1. Как минимум нам нужно знать количество пустого места. Тут все просто.
2. Так как диски у нас трех типов hdd 3.5, hdd 2.5 и ssd, то они, соответственно, имеют разные задержки и пропускную способность. Что делать с latency пока непонятно — если только складывать мелкие файлы, чтобы уменьшить количество fseek'ов на винт. Что делать с пропускной способностью тоже не ясно, т.к. она зависит от характера нагрузки. В голову приходит только экспериментально посчитать для каждого типа показатель "производительности".
3. Некоторые наши файлы являются важными и должны иметь несколько копий в системе. Тут мнения разделились. 
a) если исходить из того, что вылет двух винтов на коротком промежутке времени, это маловероятное событие. Соответственно, мы просто храним две копии, и каждые 5 минут долбимся на машину и проверяем жив ли винт. Если нет, то делаем новую копию файла. Минусы — при вылете винчестера придется большая нагрузка на менеджер-раскладыватель(нужно научить ноды копировать файлы друг у друга, чтобы не тратить память менеджера впустую).
b) у каждого винчестера есть какой-то показатель надежности(рассчитываемый по возрасту и типу), и надежность файла это сумма надежностей его копий. Т.е. файл может оказаться на 2-х молодых винтах, или 3-4 старых. Доступность файла не проверяем, и делаем его копию только в случае, если пользователь не может скачать.
c) на части машин ставим RAID 6, т.е. делаем надежность свойством машины. Из минусов — либо ставим железный контроллер и увеличиваем стоимость отдельной машины, либо молимся на прямоту софтверной реализации. Еще один минус — все копии файла лежат на одной машине. Если какой-то файл становится сильно популярным, то он отъест большую часть канала.

Скорее всего будет вариант a, возможно, временно сделаем raid.

4. Получать информацию будем через опрос менеджером нод, чтобы не пришлось узнавать о вылете ноды какими то окольными способами.