aroundITnets

Тот самый коллега по Цеху на связи.

Пока на подходе более серьезная статья о фрагменте пути из девопса в железо, хочу поделиться небольшой ночной шалостью. Прознал накануне, что на вторичном рынке в огромном количестве водятся литий-ионные элементы питания по неприлично низкой цене. Не смог удержаться и взял два десятка.

Вопрос "а зачем они мне?" был неизбежен, но мучал недолго - ответ на него, как это часто случается, пришел посреди ночи.

Сравнил напряжение на ячейках, воткнул в распечатанное на 3Д-принтере крепление (крайне удобная штука, как оказалось!) - вот и готова аккумуляторная батарея. Решаю запитать от нее собранную накануне плату управления шаговыми двигателями, на всякий случай подпаиваю к ней дополнительный разьем и выключатель.

Подаю питание - волшебный дым сегодня милостив. Подключаюсь к плате по вайфаю, кручу шаговиком в разные стороны - все штатно.

Ну, гештальт закрыт, вариант применения аккумуляторам найден, теперь можно спать спокойно.

До этого дня я мало задумывался про актуальность CDN и развития связности в разрезе текущей AI революции, а, ведь, оно действительно имеет место быть… 🤔

Основной вопрос - кто должен платить за развитие CDN и сокращение времени работы агентов ради экономии токенов? )

Слайд с СAPIF5

Всем привет!

На моем карьерном и жизненном пути иногда встречаются удивительные люди - это настоящие адепты технологий, технари до глубины души и для которых "идея" не пустое слово, а первый шаг в реализации интересных проектов.

Мне кажется, что то, что я считаю важным и достойным собственной поддержки должны видеть и коллеги по Цеху.

С сегодняшнего дня посты в канале будут не только от моего имени, но и от одного из таких людей.

Представится он сам (или нет 🙂) в комментариях к своим же постам по желанию.

Граждане из QratorLab собрали интересный отчёт о недавнем падении М9, наблюдая за перестроением маршрутов. Этакоя «BGP-призма, дай мне сил».
Внутри есть интересные цифры и важный вывод: М9 – большая и важная точка, но не надо переоценивать её значимость, будто без неё рунет коллапсирует до времён модемных пулов.

https://radar.qrator.net/blog/articles/228

Вывод очень важный и подтверждает неоднократно сказанные мною ранее слова - «не девяткой единой живет Интернет в РФ».

Некоторым «вещателям» стоит задуматься и тем кто еще строит свои сети по принципу «без М9 - никуда».

https://t.me/vostokforumru/372 тут мы в кратце тоже затронем этот вопрос

Про "универсальных солдат" и команду.

Обычно не пишу про менеджмент, но прочитав пару последних постов коллег, отмечу несколько моментов.

Тезисы, которые я для себя отметил из этих постов:

- быть "универсальным солдатом" - плохо
- тянуть на себе большой объем работы и большую ЗО - плохо
- менеджер, который ищет универсального солдата - слабый менеджер, который не хочет решать проблемы команды

Не претендуя на истину:

- универсальный солдат в команде - это превосходно!
- найти такого солдата (скорее даже человека с таким потенциалом) для менеджера - большой успех, удержать - очень сложная задача!
- создать универсального солдата - крайне сложно!
- создать команду из «универсальных солдат» - почти не возможно!

Для человека:

- быть универсальным солдатом - может быть как хорошо, так и плохо, зависит от целей этого человека!
- развалится ли что-то если тебя как «универсального солдата» уволят - конечно же нет! Что-то поменяется, но все будет работать.

Если Ты "универсальный солдат" - это твоя Сила, которую нужно преумножать, делиться знаниями в команде и быть драйвером развития своих коллег.

Главное не допускать нескольких ошибок:
1. «универсальность» наигранная и мнимая, созданная в уловиях слабой команды, слабого менеджмента и в голове конкретного человека.
2. В одной команде и компании ты «универсальный солдат», в другой ты «обычный новичок», которому нужно рости до Солдата!

P.S.

Задушить Инженера процессами и "эффективным менеджментом" - легко. Сделать так, чтобы в команде все стремились стать "универсальными солдатами" в рамках своего грейда - трудно. К сожалению, многие ищут именно простых решений, поэтому чахнут в работе, подходах и процессах.

Есть такая штука - ATS и это не то, что первое приходит на ум, а "аналог" TLS, точнее надстройка над ним — App Transport Security (ATS) в экосистеме Apple.

Узнал я об этом не из праздного любопытства, а по результатам разбора инцидента, а рамках которого у пользователей Apple начали возникать проблемы с плейбеком.

Вероятно те, "кого нельзя называть" начали как-то фильтровать ATS на ТСПУ и, как следствие, фон ошибок о недоступности ресурсов начал расти.

Можно было бы списать на сертификаты, но симптоматика крайне неуловимая. Баг плавающий, воспроизводится через раз, и общей картины так и не сложилось.

Но! Если принудительно включить отдачу контента по http, то проблема уходит.

Похоже, зацепили чуть больше, чем планировали 😎

P.S.

Удастся или нет доказать влияние «технических средств» - время покажет.

СПИКЕРЫ ТТС'26 АЛТАЙ

С удовольствием представляем очередного эксперта отрасли - спикера нашей конференции.

🎤 Аркадий Марисенков
Руководитель направления и архитектор OkkoCDN


📃Тема доклада: “ULB Uplink Load Balancer: Как мы отказались от дорогого проприетарного ПО и научились балансировать трафик между аплинками на скорости более 7 Tbps”

В рамках своего выступления спикер затронет следующие темы:

✔️ Контекст и Предпосылки: Как была устроена балансировка трафика в Okko до внедрения ULB. С какими проблемами (стоимость, лицензирование, «черные ящики») мы столкнулись при использовании платного решения.

✔️ Мотивация разработки: Почему доработка существующего решения стала невозможна и как мы пришли к решению «писать самим».

✔️ Архитектура ULB: Ключевые принципы построения. Как мы решали вопросы обнаружения аплинков, их загрузки и проверки здоровья.

✔️ Результаты и цифры: Что получилось в итоге. Экономический эффект от замещения платного решения.

✔️ Эксплуатация: Как сейчас живет компонент ULB в Okko и планы его развития.

Регистрируйтесь скорее, чтобы не пропустить одну из самых масштабных конференций отрасли на https://ttsconf.ru/!
__________
Друзья, в случае блокировки Telegram встречаемся в MAX.

#ТТС26 #Манжерок

Это будет первый доклад про уникальное решение управления трафиком, которое мы разработали в рамках команды OkkoCDN!

Общая ситуация с закупками:

по цене, увы, только рост ожидается, разрушены ЦОДы Амазон = спрос на память и накопители только увеличивается 💩

Внутреннего оптимизма на исправление ситуации в ближайшем будущем - нет.

Вот оно время облаков, которых не построил только совсем ленивый? 😀

Не коммутаторами едиными! 😎

Смотрим что у нас доступно по сети:

~# lshw -class Network

*-network
       description: Ethernet interface
       product: MT28908 Family [ConnectX-6]
       vendor: Mellanox Technologies
       physical id: 0
       bus info: pci@0000:82:00.0
       logical name: eth3
       version: 00
       serial: f2:a8:dd:a8:88:7d
       capacity: 40Gbit/s
       width: 64 bits
       clock: 33MHz
       capabilities: pciexpress vpd msix pm bus_master cap_list rom ethernet physical fibre 1000bt-fd 10000bt-fd 25000bt-fd 40000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=mlx5_core driverversion=6.11.0-26-generic duplex=full firmware=20.43.8002 (MT_0000000222) latency=0 link=yes multicast=yes port=fibre slave=yes
       resources: iomemory:5000-4fff irq:60 memory:5004c000000-5004dffffff memory:b8800000-b88fffff

Читаем capacity: 40Gbit/s и удивляемся (или нет?), что у нас 40 Gbit/s, ведь ожидалось, что будет 100 Gbit/s (линк поднят с модулями 100 Gbit/s).

Проверяем вывод ethtool:

~# ethtool eth3 | grep -i speed
 Speed: 100000Mb/s

Получается, что вполне можем рассчитывать на 100Gbit/s или есть еще какие-то ограничения, которые не на поверхности? Какие? 🙃

С BGP работаю давно, а про эти штуки или не знал, или почему-то очень старался забыть 😎

1️⃣ check-first-as (Cisco)

IOS / IOS-XE.

Назначение: Проверяет первую AS в пути. Если она не совпадает с AS пира, маршрут помечается not best, но не удаляется из таблицы.

Применение: Мягкая фильтрация. Маршрут остается в RIB, но не используется для форвардинга.

2️⃣ enforce-first-as (Juniper)

Junos OS.

Назначение: Строгая проверка. Если первая AS в пути не равна AS соседа, маршрут полностью отбрасывается (с уведомлением об ошибке).

Применение: Жесткая безопасность. Защита от хайджекинга (когда вам пытаются прислать чужой префикс с левым AS-path).

Механика: Если номера автономных систем (ASN) не совпадают, маршрутизатор отклоняет маршрут и отправляет уведомление пиру с кодом ошибки "update message error" (ошибка в сообщении обновления) и подкодом ошибки "malformed AS path" (некорректный путь AS).

Кто-то пользуется этими механизмами фильтрации?

Давно и много ходит разговоров о создании Телехаусов, объединяющих операторов связи и CDN провайдеров с целью локализации трафика, но пока у каждого оператора CDN в РФ есть «свой план и они его придерживаются», каждый ищет идеальную для себя точку локализации контента из своего представления:

🟢 географии распределения пользователей
🟢 наличия минимально отказоустойчивого ЦОДа (в регионах есть свои особенности "ЦОДов")
🟢 наличия операторов связи (ISP)
🟢 наличия портовой емкости у операторов связи

А пока все говорят - мы это сделали!

У меня на поддержке проект, в котором мы построили CDN-HUB (aka Телехаус) и достаточно быстро пришли к необходимости свопнуть Juniper MX104 на MX240 из-за кратного роста объемов трафика за несколько месяцев!

Сейчас участниками CDN-HUB уже являются большое количество региональных ISP и крупнейшие мировые CDN провайдеры!

Другими словами - концепция более чем рабочая и довольно перспективная!

P.S.

Проект реализован и развивается в г. Душанбе, Республика Таджикистан 🇹🇯

Linux ate my RAM! 🫤

Очень хорошая статья про то как читать free -h и в целом про работу Linux с оперативной памятью и использованию ее под файловый кеш.

~# free -h
               total        used        free      shared  buff/cache   available
Mem:           755Gi        99Gi        13Gi        54Gi       703Gi       655Gi

🟢 total - общее количество RAM в системе
🟢 used - количество памяти, используемое системой и приложениями (без учёта buff/cache)
🟢 free - абсолютно свободная RAM, не используемая ни под что (ни под приложения, ни под кеш/буферы)
🟢 shared - память, используемая разделяемыми библиотеками и для общей памяти между процессами (tmpfs, ramfs, shared memory segments)
🟢buff/cache - память, используемая под буферы и кеш ядра (файловый кеш, метаданные, сокеты, inodes и т.п.)
🟢available - реально доступная память для запуска новых приложений без использования swap (≈ free + часть buff/cache, которую можно освободить мгновенно)

Выше приведен вывод команды с одного из действующих серверов раздачи контента, в котором под файловый кеш задействовано более 700GB RAM и при таких объемах возникают "особенности" про которые на момент написания статьи, вероятно, никто не думал. А мы расскажем чуть позже.

«Теория без практики мертва, практика без теории слепа», поэтому в конце статьи есть ссылка на практическую часть, по которой можно оценить время работы с/без использования файлового кеша.

P.S.

Очень релевантная инфа для собесов 😉

В связи с амбициозными планами по развитию CDN ищу себе в команду опытного и заряженного на результат инженера.

Кому интересно - приходите общаться!

https://hh.ru/vacancy/130389389?from=applicant_recommended&hhtmFrom=main

Привет,

вчера Мы показали открытие Олимпийских Игр 2026 ⚽️

Трафик в пределах нескольких Tbps и достаточно планомерный рост пользователей, вероятно, говорит о том, что интерес к "перформансам" немного подостыл.

Самое интересное - это первый день после открытия!

Лыжи и 🎿 Дарья Непряева — скиатлон 10км + 10км, 15:00 создали нагрузку аналогичную открытию Олимпийских Игр!

Болеем за Наших! Они лучшие в любом случае! 🇷🇺

Новый исторический рубеж! Мы становимся первым в мире онлайн-сервисом, который получил эксклюзивные права на трансляцию Олимпийских игр. Это огромная честь и ответственность. Готовьтесь смотреть главные спортивные события только в Okko! 💜

Важная составляющая успеха - признание! Спасибо, Okko! 🏆