# Зеркала GNU. Mirrorbits. ivi CDN
Что: 77616a050e10dcd623a19cfad1055af6beecebe0
Когда: 2025-12-11 21:02:57+03:00
Темы: bgp go multimedia netperf
```
Зеркала GNU. Mirrorbits. ivi CDN

http://savannah.gnu.org/maintenance/Mirroring/
https://jellyfin.org/posts/mirrorbits-cdn/
Интересна стала, наряду со всяким устройством Интернета, пирингом, ещё и
тема CDN и хотя бы зеркал, кэшей. А также столкнулся с тем, что частенько
ftpmirror.gnu.org отправляет на .ua серверы, которые, по понятным
причинам, недоступны у нас (хотя по IPv6 связанность была в одном месте).
Нашёл вот у них пояснение как устроено всё это зеркалирование и на
основе чего принимаются решения о ближайшем зеркале.

А ведь последнее что я делал в ivi это как-раз написание всего софта для
создания их кэширующего CDN. Но тогда я не понимал насколько это всё
важно и нужно. Просто выполнял задачи поставленные сетевиками. Даже
вспомню многое:

* как минимум, в каждом городе миллионнике стоят несколько кэш-серверов
* это были дешёвые сервачки, загруженные SSD в RAID0 и 4 1Gbps Ethernet
  портами. Где-то вместо SSD были даже HDD
* RAID0 просто ради распределения нагрузки. Если кто вылетит -- вся
  система и содержимое просто перенакатывались заново. Это всё же кэш,
  не более
* пользователь стучался по anycast адресу. Так или иначе как-то попадал
  на кластер проксей ближайший к нему
* внутри кластера на каждой машине есть знание обо всех своих соседях
  (обо всём содержимом кластера). Хранится в Redis. Информация между
  узлами широковещательно по UDP в Protocol Buffer передавалась
  периодически. Важные события ("я скачал такой фильм") отправлялись
  сразу же
* попадая на узел кластера, он на лету смотрел в Redis чтобы понять есть
  ли у него файл или есть ли этот файл на другой машине. Отдавал если
  есть локально. Перенаправлял HTTP ответом на другую машину в противном
  случае. Также учитывалась нагрузка (вроде только канал сети брался в
  расчёт) машин в кластере, чтобы равномернее распределять
* каждый запрос обновлял счётчики в Redis. Если какой-то контент всё
  чаще запрашивается, а его нет в кластере, то он скачивался с upstream
* если в кластере есть скачанный контент, но кол-во перенаправлений
  из-за нагрузки идёт в upstream, то он докачивается ещё на другую
  машину (одна, значит, не справляется)
* если файл надо скачать, то сначала идёт попытка скачать с соседнего
  узла. Затем с другого кластера кэширующих прокси. А лишь после всего
  этого уже с файловых серверов. Всё заточено под то, чтобы ни при каких
  обстоятельствах не лезть на файловые
* статистика запросов хранится, как минимум, за сутки. И превентивно
  софт предпринимает решение о скачивании чего-то отсутствующего в
  кластере. Делается всё, чтобы подготовиться к ударной нагрузке (люди
  просыпаются, или приходят с работы, и т.д.) заранее, а не начинать
  качать недостающий контент когда уже регулярно идут промахи
* более того, статистика хранится на всю неделю. Я прям точно помню что
  множество просматриваемого контента ощутимо отличается на выходных.
  Учитывая статистику прошлых выходных, в пятницу сервера готовятся к
  грядущей субботе
* постоянно идёт процесс и удаления менее приоритетных штук и пополнения
  текущих горячих. И ext4 ФС постоянно ломалась, как говорили админы:
  приходила в какое-то непонятное состояние и приходилось пересоздавать
  её с нуля. С тех пор я не доверяю ext4, да и вообще линуксоидам
* помню что нужно было хранить и аналог atime файлов. Включать atime на
  ФС -- изнашивает SSD. Поэтому его хранили тоже в Redis
* если кол-во промахов, даже имея несколько копий в кластере, росло, то
  значит в кластер нужно было добавлять дополнительные сервера, деваться
  некуда
* мы заранее знали что будет анонс какого-нибудь блокбастера и имели
  особые скрипты которые в Redis искусственно устанавливали счётчики
  запросов на это блокбастер на огромные значения, вынуждая кластер
  заранее скачивать этот фильм. И когда идёт премьера, то кэши заранее
  подготовлены к резкой нагрузке
* тогда я это всё ещё не понимал, но ввод/вывод узла в/из кластера
  производился просто поднятием/остановом BGP демона
* когда-то софт был написан на Python, но я пошёл к начальству и
  предложил полностью переписать на Go. Это значительно сократило
  потребляемые ресурсы и скорость реакции. Лавина UDP широковещательного
  трафика частично пропадала из-за невозможности достаточно быстро её
  обработать в userspace. С Go это решилось

Сейчас возможно всё как-то иначе устроено, ведь прошло уже более десяти
лет. SSD, слышал, стали значительно более надёжными (долгоживущими) -- а
прежде их, не дорогих, хватало на 2-3мес всего. Да и тогда ещё не было
4K контента.
```