Серверное администрирование *

Привет, Хабр!

За последние три года рекламная система VK выросла в три раза по количеству кампаний, таргетингов и RPS. При этом мы столкнулись с физическими ограничениями bare-metal инфраструктуры: 128 CPU и 512 ГБ памяти на сервер стали потолком, в который мы упёрлись. Сервис баннерной карусели потреблял всё больше ресурсов, а время деплоя достигало 24 часов.

Меня зовут Артём Букин, я разрабатываю инфраструктурные проекты. В этой статье расскажу о технических деталях миграции ядра рекламной системы VK в облако: как перешли от MySQL-репликации к P2P-доставке снапшотов через торрент-протокол, научились применять данные без downtime и в итоге сократили потребление памяти в 2 раза, а время деплоя — в 4.

Мы все сталкивались с этим: открываешь репозиторий, а там код, который вроде бы работает, но при ближайшем рассмотрении вызывает лёгкую дрожь в руках. В этой статье я хочу поговорить о том, как «студенческий» код, написанный в спешке или ради эксперимента, неожиданно становится частью продакшн-систем. Разберём примеры, посмотрим, как такие артефакты выживают, какие последствия это несёт, и что с этим можно сделать, чтобы не жить на пороховой бочке.

Корейский стартап FuriosaAI представил сервер NXT RNGD для ИИ-инференса. 4 петафлопса вычислений при потреблении 3 кВт вместо 10+ кВт у GPU-решений. Анализ архитектуры, преимуществ и перспектив альтернативы NVIDIA.

Обзор инновационного 1U-сервера Supermicro ARS-121L-NE316R: 144-ядерный ARM-процессор NVIDIA Grace Superchip, 16 слотов E3.S и решение для хранилищ PCIe Gen5. Анализ архитектуры и сценариев применения.

99.9% аптайма.

Три невинные цифры, которые хостинг‑компании размещают по всем своим маркетинговым материалам как знаки отличия. Звучит впечатляюще, не так ли? Почти идеальная надежность. Ваш сайт работает стабильно 999 минут из каждой 1000.

Но вот что они вам не говорят: 99.9% аптайма означает, что ваш сайт недоступен 8 часов 46 минут каждый год.

Если хотите проверить математику, таблицы доступности конвертируют 99.9% в ~8ч 46м/год, а 99.99% в ~52.6м. В 30-дневном месяце 99.9% допускает около 43м 49с простоя, в то время как 99.99% около 4м 23с.

Это целый рабочий день. Исчез. Клиенты видят страницы ошибок, продажи испаряются, email‑сообщения возвращаются обратно. Пока вы платите премиальные цены за «корпоративную надежность».

И становится хуже. Разница в 0.1% между 99.9% и 99.8% аптайма? Она представляет удвоение времени простоя с 8.77 часов до 17.53 часов в год. Тем не менее хостинг‑компании ценят эти тарифы так, будто разница незначительна.

Вот скажите мне, хабравчане, в чём сила? Разве в деньгах? Вот и финдиректор говорит, что в деньгах. А я вот думаю, что сила в данных: у кого данные, тот и сильней!

Техгиганты, вроде Google (Alphabet), Meta (признана экстремистской в России) и Яндекса, получают огромную прибыль с монетизации пользовательских данных; менее очевидные Spotify, OZON и т.п. тоже неплохо зарабатывают на данных и рекламе. Банки каждую секунду проводят сотни тысяч транзакций, небольшие интернет-магазины собирают кучу телеметрии, а социальные сети крутят бесконечные алгоритмические фиды, чтобы вы смотрели свою персональную ленту с котиками и мемами.

Каждый клик, каждое движение мышкой, каждый свайп или тап по экрану — это запись в базе данных. И да, серверы давно умеют с этим всем работать.

И вот есть у бизнеса база данных, зачем тогда изобретать ложку для супа отдельные подходы для работы с данными в ней? Выбираешь что-то оптимальное/лучшее — и радуешься жизни.

А вот зачем

Для транзакций в реальном времени нужна одна система — OLTP (Online Transaction Processing), а для аналитики другая — OLAP (Online Analytical Processing). OLTP похож на Соника — он всегда в движении, стремительно мчится вперёд, реагирует на каждое препятствие и собирает колечки. А OLTP — отрабатывает каждую транзакцию быстро и предсказуемо. OLAP же напоминает Кирби — он втягивает в себя всё, что попадётся — горы предметов, врагов, целые миры. А OLAP поглощает массивы данных — миллионы и миллиарды строк, чтобы потом переварить их и превратить в осмысленный отчёт.

Серверный рынок постоянно развивается, и Dell не отстаёт от трендов. Недавно компания представила PowerEdge R7715 — 2U-сервер на базе процессоров AMD EPYC 9005, который сразу привлёк внимание специалистов по инфраструктуре. В этой статье мы расскажем, почему этот сервер может стать отличным решением для вашего дата-центра.

Привет, коллеги! Хочу рассказать одну историю. Был у нас в стойке один сервер. Назовем его «Феникс». Работал как часы, аптайм — 986 дней. Мы им гордились, ставили в пример новичкам, мол, вот как надо настраивать железо и софт. А потом пришло время планового техобслуживания в дата-центре. Простое выключение-включение. «Феникс» больше не взлетел. RAID-контроллер решил, что с него хватит, а заодно прихватил с собой пару дисков из массива. Вот тогда я впервые по-настояшему задумался о том, что цифровой мир подчиняется тем же жестоким законам, что и физический.

В теории, код и данные — это нечто вечное. Биты не ржавеют, скрипты не изнашиваются. Но на практике любая сложная система со временем деградирует. Это не просто отказ железа ; это медленный, неумолимый «постепенный скат в беспорядок» , который затрагивает всё: софт, конфигурации, данные. Это явление, которое я для себя называю  цифровой энтропией, — наш с вами постоянный и невидимый враг. Наша работа — не просто строить системы, а вести непрерывную войну с их неизбежным распадом.  

Эта статья — путешествие по самым темным уголкам цифровой энтропии. Мы заглянем в глаза её самым жутким проявлениям, поделимся байками из серверной и вооружимся как тактическими командами для экстренных случаев, так и стратегическими концепциями, которые помогут держать хаос в узде.

Недавно я увидел 1TB в статистике книг Audiobookshelf и решил отпраздновать это, рассказав людям как крут Audiobookshelf.

Audiobookshelf — приложение, которое ставится на свой компьютер, сервер аудиокниг. Это каталог ваших аудиокниг. Однако, зачем вообще аудиокниги, когда есть нормальные, текстовые? Если есть возможность, то...

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

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

TrueNAS на Raspberry Pi 5? Сейчас это реально: ARM-форк TrueNAS плюс неофициальный UEFI для Pi дают шанс поставить SCALE на Pi 5/CM5. В статье пройдём установку от обновления EEPROM и прошивки rpi5-uefi до первого входа в веб-интерфейс, соберём минимальный пул и проверим базовую работу. Это осознанный эксперимент: встроенный Ethernet недоступен, часть периферии RP1 не работает, а PCIe-коммутаторы видятся не полностью. Разберёмся, где такой вариант уместен, а где практичнее выбрать Raspberry Pi OS с ZFS, OpenMediaVault или классический x86.

Самый простой способ получить удалённый доступ к домашнему серверу — купить у провайдера статический «белый» IP (обычно 100–200 ₽/мес). Если же у вас уже есть арендованный VPS с публичным IP (например, для сайта, VPN или других проектов), его можно использовать как мост для доступа к серверу, сэкономив на покупке статического IP. В этой статье я расскажу, как настроил обратный SSH‑туннель через существующий VPS, чтобы стабильно подключаться к своему домашнему серверу, находящемуся за NAT от провайдера.

Нужно нарастить мощность без лишнего CAPEX? Разбираем, как вторичный рынок серверов превращается из «плана Б» в стандарт: 50–80% экономии, недели вместо месяцев, совместимость с российскими ОС. Плюс: чек-лист приёмки, таблица конфигураций и как провести пилот, чтобы спорить цифрами, а не мнениями.

Выбор сервера под 1С часто превращается в лотерею: одни экономят и получают тормоза, другие переплачивают за «железо с запасом», которым не пользуются. В статье мы собрали советы эксперта, рыночные цифры и чек-лист по конфигурациям, чтобы вы смогли подобрать сервер без боли и лишних расходов.

Мы поймали странный «обрыв» доступа к нескольким NAS и старому принтер-серверу. В логе — ничего драматического: «не получилось договориться по безопасности». Виноват оказался не «прокси/файрвол», а новая норма безопасности: клиент Windows Server 2025 уже требует подпись SMB-пакетов. Всё, что не умеет — идёт мимо кассы.

В тот же месяц у коллег «ложилась» интеграция, ретранслирующая NTLM на LDAP, — и снова не сеть виновата. LDAP-подпись и привязка канала (channel binding) перестали считать ретрансляцию чем-то приемлемым. Зато после шторма заметно стихло количество «подозрительных» попыток бокового смещения.

Мораль простая: реактивная модель «ставим патчи и надеемся» больше не тянет. Нужен проактивный дизайн — с нормами безопасности, которые не нужно «включать по желанию», а которые уже встроены в дефолт.

Привет, Хабр! В первой части я разобрал основы rsync: синтаксис, ключевые опции и работу по SSH. Эти аспекты позволяют эффективно пользоваться утилитой на базовом уровне. В этой статье заглянем «под капот» и научимся тонко контролировать весь процесс синхронизации и диагностировать проблемы с производительностью...

Что в статье:

— Фильтрация;
— Экономичные бэкапы;
— Диагностика и решение проблем.

Привет, Хабр! В арсенале системного администратора и разработчика есть множество инструментов для переноса данных. Мы копируем файлы десятки раз в день: cp для локальных копий, scp для удалённых серверов. Но что если задача сложнее? Нужно не просто скопировать, а синхронизировать два дерева файлов, дёргая по сети лишь изменившиеся данные? Или поддерживать в актуальном состоянии зеркало веб‑контента?

О чём эта статья?
— Фундамент: как правильно путями в rsync и почему слеш в конце решает всё;
— Два основных режима работы: локально, с сервером;
— Разбор флага -a: что скрывается под капотом; — Главные опции: как сделать вывод подробным, а работу — безопасной; — Синхронизация поверх SSH: работа с нестандартными портами; — Самые опасные «грабли» и как их избежать.

Нет ничего более постоянного, чем временное решение. Любой айтишник хоть раз лепил костыль на скорую руку — потом перепишем, потом сделаем нормально. Но «потом» обычно не наступает, и в итоге времянка живет в продакшене годами, переживает релизы и смену команд, а иногда становится частью продукта. У индустрии полно баек о том, как костыли превращались в легенды. В этой статье собрал самые интересные случаи из истории ИТ. Приглашаю под кат. 

В недавней статье об SSL‑сертификатах, точнее, в комментариях к ней, затронули вопрос, который похоже создает для многих головную боль: как обновлять сертификаты от Let's Encrypt? Ведь сертификаты выдаются на 3 месяца, а потом их надо обновлять.

Конечно, есть Certbot, есть софт, который умеет сам получать и обновлять сертификаты — но вопрос возник именно по тому софту, который сам не умеет (а подключить Certbot почему‑то не получается)

Когда‑то у меня тоже возник такой вопрос, и почему‑то не устроил Certbot — не помню уже точную причину. Решил проблему иначе.

Подробный обзор Dell PowerEdge R7725: 2U сервер на AMD EPYC 9005 с поддержкой 40 NVMe E3.S дисков. Тесты производительности в ИИ, HPC и хранилищных задачах. Узнайте, почему это "швейцарский нож" для современных ЦОД и как он сравнивается с конкурентами.