Почему трафик в ЦОДе балансируется не так, как вы ожидали
LAG часто воспринимают как простую и понятную вещь: объединили несколько линков — получили больше пропускной способности и отказоустойчивость. Но в реальности всё упирается не только в наличие агрегированного канала, а в то, как именно по нему раскладываются потоки.
Из-за этого и появляются знакомые инфраструктурные сюжеты: один линк забит, другой почти пустой; после изменения топологии поведение трафика меняется неочевидно; ECMP вроде есть, но равномерности всё равно нет; в VxLAN/EVPN-фабрике проблема становится ещё менее прозрачной.
7 июля в 20:00 на бесплатном уроке вместе с преподавателями-практиками разберём, как на самом деле работает балансировка трафика в сетях ЦОД: от LAG и хеширования до ECMP, vPC/MLAG и VxLAN/EVPN. Фокус — на том, какие решения в дизайне сети помогают избежать перекосов, перегрузок и сценариев уровня «всё упало, всё пропало». Присоединяйтесь.
Больше бесплатных уроков июля по инфраструктуре, сетям, разработке, AI и другим направлениям собрали в дайджесте — там можно посмотреть все темы месяца.
Как я в Zabbix мониторю аккаунт в REG.RU: баланс, неоплаченные счета и сроки всех услуг - через API reg.ru
Домен можно сторожить по WHOIS: взял имя, посмотрел дату, повесил триггер «истекает через 30 дней». Но WHOIS видит ровно один домен и ничего вокруг. Он не знает, что на счёте кончились деньги, что висит неоплаченный счёт, из-за которого услугу снимут раньше срока, что в том же аккаунте ещё десяток доменов, SSL и хостинг. Поэтому я опрашиваю не WHOIS, а биллинговый API самого регистратора - он отдаёт весь аккаунт целиком. Собрал из этого шаблон под Zabbix 7.0, MIT. Расскажу, как он устроен и что в нём, на мой взгляд, сделано правильно.
Архитектура Три HTTP-айтема ходят в api.reg.ru - список услуг, неоплаченные счета и баланс - и складывают сырой JSON. Дальше всё считается из него: dependent items тянут баланс, сумму и число счетов через JSONPath, а LLD разворачивает прототипы под каждую услугу (ненужные типы отсекаются макросом-регуляркой). Каждая цепочка начинается с error_handler - битый или пустой ответ API не роняет айтем, а подставляет безопасное значение. На весь аккаунт получается несколько запросов в час, а не отдельная проверка на каждую услугу.
Что считаю правильным дизайном - две цепочки зависимостей Первое - nodata. Когда API регистратора отваливается целиком, каждый триггер «нет данных» (услуги, счета, баланс) хочет сработать сам, и ты получаешь пачку алертов про одну причину. Я завязал nodata услуг и счетов на корневой «No data from balance API». Полный отвал API теперь - один алерт, а не три. Корень я специально оставил без зависимостей, чтобы случайно не завязали и его, - об этом есть комментарий прямо в шаблоне.
Второе - сроки. На каждую услугу не один триггер, а каскад: ИСТЕКЛА (Disaster) → ≤7 дней (High) → ≤14 (Warning) → ≤30 (Info). Каждый уровень зависит от более тяжёлого. Поэтому услуга, которой осталось три дня, даёт один алерт High - а не три штуки (Info, Warning, High) одновременно. По мере приближения срока ты видишь ровно один триггер нужной серьёзности.
Для работы API, необходимо прописать разершенные IP в кабинете https://www.reg.ru/user/account/settings/api/, в настройках API задать адьтернативный пароль, и сохранить в макрос хоста {$RR_PASSWORD} как Secret. Логин - {$RR_USERNAME}. Для рег.облако взять API в https://cloud.reg.ru/panel/settings и сохранить в {$RRC_API_KEY}
Итог Баланс, неоплаченные счета и сроки всех услуг - под алертами в одном дашборде, без отдельного демона-прослойки. В репозитории два шаблона: разобранный выше под api.reg.ru (домены, хостинг, SSL) и отдельный под облачный api.cloudvps.reg.ru - там к балансу и срокам добавлен мониторинг самих VPS: реглеты, снапшоты, сети. Шаблоны, README и changelog - GitHub, PR и issues welcome.
А чем вы следите за биллингом у провайдеров и регистраторов - дёргаете API, или живёте на письмах «ваша услуга истекает»?
Вебинар: через час расскажем, как управлять IT-инфраструктурой через Terraform
Terraform-провайдер Selectel позволяет управлять физическими серверами и другими ресурсами по концепции IaC. Мы готовим большой апдейт этого сервиса — на вебинаре расскажем все подробности.
Что вас ждет:
поделимся возможностями Terraform-провайдера для управления IT-инфраструктурой;
презентуем большой обновление и покажем, как теперь управлять локальными сетями и настраивать разделы;
объясним, как работают новые функции.
Приятный бонус: все слушатели вебинара получат промокод на 3 000 бонусов в панели Selectel, чтобы протестировать возможности Terraform.
Вебинар «Переход с Microsoft Exchange на Почту VK WorkSpace: пошаговый план»
16 июня в 11:00 К2Тех совместно с VK Tech проведет вебинар о переходе с Microsoft Exchange на почту VK WorkSpace. Поговорим о том, как подойти к миграции без лишнего стресса, что важно учесть на старте проекта и как перенести ключевые данные без потерь.
Поддержка Microsoft Exchange 2016 и 2019 завершена, поэтому вопрос миграции для многих компаний уже перестал быть теоретическим. Когда обновления безопасности больше не выходят, почтовая система становится источником растущих рисков, а откладывать переход все сложнее.
На вебинаре разберем, как выглядит пошаговый план миграции на VK WorkSpace: от предварительной оценки и подготовки до переноса данных и настройки целевой среды. Отдельно обсудим типовые риски проекта и практические способы их минимизации.
Покажем и техническую сторону вопроса. В программе — демонстрация встроенных инструментов миграции VK WorkSpace: перенос писем, календарей, контактов и групп рассылки, а также разбор того, что важно проверить заранее, чтобы не столкнуться с неприятными сюрпризами на этапе переключения.
Еще один важный блок — экосистемность платформы. Коротко пройдемся по возможностям VK WorkSpace: почта, календарь, мессенджер, видеоконференции, диск, документы и другие сервисы для совместной работы в едином контуре.
Команда К2Тех поделится практикой проектов в различных отраслях: какие задачи чаще всего возникают при миграции, где обычно скрываются узкие места и какую роль играет интегратор при использовании встроенных средств переноса.
Также обсудим, как выстраивать политики безопасности корпоративной почты с учетом требований регуляторов, и расскажем, какие возможности VK WorkSpace появятся в ближайших релизах.
Спикеры:
Антон Тен, коммерческий директор VK WorkSpace, VK Tech.
Павел Бухтияров, руководитель направления «Почта» VK WorkSpace, VK Tech.
Владимир Сергеев, эксперт практики UC и ПО для совместной работы, К2Тех.
Для кого будет полезен вебинар
ИТ-директора и CIO, которые планируют отказ от Exchange и выбирают целевую почтовую платформу.
Руководители ИБ и CISO, отвечающие за снижение рисков, связанных с устаревшими системами и отсутствием обновлений безопасности.
Руководители инфраструктурных и почтовых команд, администраторы Exchange и VK WorkSpace.
Архитекторы и руководители проектов, которым нужно спланировать миграцию и оценить ее влияние на бизнес-процессы.
🎁 Бонус:
Для компаний, которые рассматривают переход с Exchange, на вебинаре будут доступны консультация по миграции, специальные условия технической поддержки до 30 июля 2026 года.
Развивается не только наша инфраструктура, но и сервисы. Сегодня — про AI-агентов.
За последние три месяца количество активных агентов выросло в 4 раза, а пользователи тратят больше миллиарда токенов в день.
Теперь можно закрывать больше сценариев в одном диалоге: поиск актуальных данных и создание визуалов под запрос.
➖ Веб-поиск
Агент ищет информацию в интернете перед ответом, а вы получаете актуальные цены, тарифы, новости, данные с сайтов. Под капотом — интеграция с Яндексом.
Функция включается в настройках агента. Стоимость — 0,49 руб. за запрос.
➖ Генерация изображений
Агент генерирует иллюстрации, иконки, баннеры прямо в диалоге, без лишних переключений. В будущем добавим и генерацию аудио.
Доступные модели: Gemini 3.1 Flash Image Preview и Gemini 3 Pro Image Preview, они же Nano Banana. Список будет пополняться.
Оплата — по токенам выбранной модели. Включить можно где удобно: при создании агента, в настройках уже готового или прямо в чате.
Бонусом поменяли способ тарификации для новых агентов на поресурсный. Так можно дешевле тестировать новые фичи, платить только за фактическое использование и настраивать агента под свои задачи.
UPD1: Так же возможно ситуация затронула следующие хостинги: THE.Hosting UFO.Hosting Alexhost.com Vdsina.com Hip.hosting Datacheap.ru ihc.ru
Оператор дата-центров nLighten в одностороннем порядке и без уведомления остановил работу серверов MIRhosting в Нидерландах и Германии. В MIRhosting назвали действия поставщика абсолютно неприемлемыми.
Что делается сейчас:
MIRhosting привлекает юристов для выяснения деталей;
Идутся поиски альтернативных площадок для размещения инфраструктуры;
Инженеры пытаются восстановить доступ к серверам для спасения данных;
Готовятся варианты экстренного переезда для клиентов.
Компания «Евробайт» полностью контролирует ситуацию и находится на связи с партнёром. Как только появится конкретика по срокам и параметрам миграции оборудования, специалисты «Евробайт» свяжутся с каждым пострадавшим клиентом индивидуально. Команда приложит все усилия, чтобы решить проблему с минимальными неудобствами.
Материал основан исключительно на данных из открытых источников. Автор публикации не гарантирует достоверность предоставленных сведений и не несёт ответственности за их точность.
На конференции ЦИПР одной из важных тем для облачных операторов была постройка дата-центров в московском регионе. Сразу скажем, что пока это не закон и конкретных документов под эти планы нет, но радует, что правительство понимает важность этой темы.
Заместитель министра цифрового развития, связи и массовых коммуникаций Евгений Филатов сообщил, что Минцифры обсуждают с Минэнерго возможность разрешить новым игрокам подключиться, если у них есть свои источники энергии. Почему это важно?
Облачные сервисы хороши тем, что пользователю не приходится задумываться, где находятся серверы — в Москве, Сибири или даже за границей. Грамотная организация позволяет бесшовно использовать сервисы в любой локации. Но провайдеру как раз приходится заботиться о том, чтобы дата-центры обладали нужной скоростью доступа и низким пингом, имелась возможность быстро переключиться на другие сервисы при инцидентах в текущем. Кроме того, для некоторых задач важны Edge Computing, то есть технологии, обеспечивающие вычисления в ближайших ЦОДах (для минимальной задержки сигнала).
Однако в таких регионах, как Москва, с февраля подключение ЦОД к электросетям ограничено, так как нет лишних мощностей — они уже использованы или зарезервированы для крупных игроков. А значит, рынок монополизируется: небольшим облачным операторам труднее расширять серверные мощности, чтобы запускать уникальные сервисы и показывать конкурентоспособность на рынке.
Возможность запускать дата-центры, пусть и со своими источниками энергии (которые найти в таких регионах, как Москва, непросто), расширит количество игроков, даст возможность выбора для облачных операторов и позволит достичь максимальной функциональности и надежности сервисов.
Дефицит электроэнергии — не российская особенность, а тренд для всех развитых стран мира. В частности, в США из-за массового строительства дата-центров под ИИ планируется даже возрождение АЭС, которые смогут дать постоянные мощности по приемлемым ценам (СЭС ночью не работают, ВЭС зависят от ветра). Ресурс Servernews отмечает, что такие крупные компании, как Microsoft, SoftBank и SpaceX (недавно слилась с ИИ-компанией xAI), собираются использовать газовые генераторы, а OpenAI под проекты Oracle закупает топливные элементы.
Надеемся, что и российские регуляторы не останутся в стороне и помогут решить общемировую проблему.
AMD вкладывает $10 млрд в Тайвань: гонка ИИ-ускорителей против Nvidia
AMD инвестирует больше 10 миллиардов долларов в тайваньские производственные мощности, чтобы ускорить выпуск ИИ-чипов и сократить разрыв с Nvidia. Компания делает ставку не только на сами процессоры, но и на всю инфраструктуру вокруг них.
По данным Habr, AMD расширяет сотрудничество с крупнейшими тайваньскими производителями упаковки, подложек и серверных платформ. Цель — быстрее выводить на рынок новые поколения EPYC и Instinct, серверных процессоров и ИИ-ускорителей соответственно.
Почему Тайвань? Потому что там сосредоточена критическая масса компетенций в области продвинутой упаковки чипов и производства подложек. Для современных ИИ-ускорителей это не менее важно, чем сам кристалл. Технологии 2.5D-упаковки позволяют размещать несколько кристаллов на одной подложке с высокоскоростными межсоединениями — без этого невозможно достичь пропускной способности памяти, которую требуют модели вроде GPT или Stable Diffusion.
AMD инвестирует в:
Технологии 2.5D-упаковки для многокристальных решений
Производство высокоплотных подложек под ИИ-ускорители
Сборку серверных стоек и интеграцию многокомпонентных систем для дата-центров
Это не просто покупка мощностей. AMD выстраивает полный цикл от кристалла до готовой стойки в дата-центре. На фоне роста спроса на вычисления для обучения и инференса моделей время вывода продукта на рынок становится решающим фактором. Nvidia доминирует не только из-за производительности GPU, но и благодаря зрелой экосистеме CUDA и готовым серверным решениям вроде DGX.
AMD пытается сократить этот разрыв через вертикальную интеграцию. Вложения в тайваньских партнёров дают контроль над цепочкой поставок и позволяют быстрее итерировать новые поколения Instinct. Но есть подводный камень: даже с лучшим железом AMD нужно переломить инерцию рынка, где CUDA остаётся де-факто стандартом для разработки ML-систем.
Инвестиции AMD — это ставка на то, что в ближайшие годы спрос на ИИ-вычисления будет расти быстрее, чем Nvidia сможет масштабировать производство. Если это так, рынок откроется для альтернатив. Если нет — 10 миллиардов окажутся вложениями в догоняющую позицию.
Теперь вы можете развернуть сервер в Нью-Йорке. Хороший вариант, если важна низкая задержка для пользователей в Северной Америке или вы хотите распределить инфраструктуру между США и Европой.
Физически дата-центр находится в Буффало, штат Нью-Йорк. Мы подключили локацию к опорно-магистральной сети, чтобы обеспечить стабильное управление и качественное соединение с инфраструктурой в других локациях.
Есть фиксированные и произвольные конфиги. Минималка 1 CPU, 1 ГБ RAM и 15 ГБ диска.
4 × V100 SXM2 против современных GPU: ищем команду для комплексного баттла архитектур в ML-инференсе
Привет, Хабр!
Пока все охотятся за новыми GPU, мы разворачиваем проект NeuralTower на древнем, но очень неплохом enterprise-железе: 4 × NVIDIA V100 SXM2 32GB (суммарно 128 GB HBM2). Внутри мезонинов карты объединены по сверхбыстрой шине NVLink, а сами мезонины подключены к плате через четыре физических разъема PCIe x16 под управлением двух чипов-свитчей PLX. Работает всё это на вручную собранном Gentoo Linux + вручную собранные библиотеки.
Пока на коленках, но мы победили софтверные ограничения vLLM для SM 7.0 под CUDA 12.x, упаковали стек в Docker, заменили FlashAttention на адаптированный xFormers и принудительно зафиксировали float16. Система стабильно держит Tensor Parallelism на все 4 карты, с учетом гибридной топологии.
Цель: провести многогранный сравнительный тест
Мы хотим столкнуть лбами нашу old-enterprise топологию с современными картами архитектуры SM 8.0+ (например, 4 × RTX 3090 / 4090, 4 × A100 или H100).
Для теста планируем запускать тяжелые модели: Qwen-32B в чистом FP16 или Llama-70B в квантовании AWQ/GPTQ. Просто у нас нет больше чем 128Gb, а так модели можем согласовать.
Мы ищем единомышленников с доступом к современным 4-карточным ригам, чтобы собрать комплексную матрицу метрик, а не только банальный TPS:
Метрики инференса: Time-to-First-Token (TTFT), общая скорость генерации TPS и задержки при разной длине контекста.
Аппаратная эффективность: Насколько внутренний NVLink и PLX-свитчи с поддержкой GPUDirect P2P на старом железе обходят по шине «гражданские» материнские платы с PCIe x16/x8 при распределении весов через Tensor Parallelism.
Эффективность памяти: Поведение и утилизация KV-кэша vLLM на пропускной способности HBM2 против современной GDDR6X/HBM3.
Экономика вычислений: Соотношение чистой производительности к стоимости б/у оборудования и его энергопотреблению (Performance per Watt / Per Dollar).
Отдельный открытый вопрос: очень хотелось бы сравнить влияние архитектур на итоговое качество генерации (perplexity / alignment), но в команде пока идут споры о методике замера на разных версиях движков. Если у вас есть готовые идеи, как это корректно протестировать - будем рады обсудить.
Что с нас, что с вас?
С нас: Полностью готовые Docker-контейнеры. Развертывание тестового окружения на вашей стороне займет 10 минут. Думаем, Docker/Linux x64
С вас: Запуск тестов на вашем железе и сбор логов.
Когда?
Возможны варианты. Но надеемся уже провести тесты в середине лета.
Все результаты мы объединим, детально проанализируем и опубликуем здесь же, на Хабре, в виде большого технического исследования с графиками.
Если у вас есть подходящие мощности и вам интересно принять участие в баттле железных архитектур - пишите в комментарии или в ЛС! Давайте сделаем крутой материал.
Сервер для PyTorch: как выбрать конфигурацию под обучение и инференс
PyTorch запустится почти на любом сервере, но между «запустится» и «работает стабильно под нагрузкой» — большая разница. Частая ошибка — выбирать VRAM по размеру модели, но видеопамять занимают контекст, KV-cache, размер батча и служебные расходы фреймворка.
В новой статье разобрали, когда хватает CPU и в каких сценариях нужен GPU. Показали, как заранее проверить совместимость драйвера NVIDIA и версии CUDA, как эмпирически измерить фактическое потребление VRAM и сколько RAM закладывать под DataLoader с несколькими воркерами. И собрали ориентиры по конфигурациям — от прототипирования и небольшого инференса до обучения на 2–4 GPU и больших моделей.
После предыдущего поста мне захотелось немного порефлексировать относительно того, как сейчас обстоит ситуация с платформами виртуализации. Сегодня я не буду задавать никаких вопросов, пишу эту заметку скорее для фиксации своих мыслей и ваших мнений.
Довольно давно я (как наверняка и многие из вас) размышляю о том, как обстоят дела с софтом и куда все это идет. Естественно, думаю об этом я со своей колокольни виртуализации, но буду рад, если вы выскажитесь под постом и про другие классы и категории.
Итак, как я это вижу.
Раньше на рынке все было довольно мейнстримно - был один лидер (VMware) и множество догоняющих. Все было понятно и предсказуемо. Но в силу произошедших и происходящих до сих пор событий рынок как будто раздробился.
Часть компаний осталась на том же софте, но в ряде случаев - с туманными перспективами. Часть ушла на российские платформы. Кто-то перешел на опенсорс.
Но какого-то единого вектора, как это было раньше, теперь нет. Каждая компания решает задачу по-своему, исходя из бюджета, наличия рук и уровня паранойи требований. И это, пожалуй, главная особенность сегодняшней ситуации.
Отсюда же вытекает проблема с кадрами. Пласт специалистов под VMware был просто огромный, сегодня же, когда внезапно на рынке появилась куча новых платформ, порой приходится искать подходящего человека или же его обучать. Словом, происходит какое-то броуновское движение.
И в связи с этим я все чаще задаю себе вопрос - к чему мы в итоге придем лет через 5-7? Устаканится ли российский софтверный рынок? Найдем ли мы равновесие между привычным зарубежным софтом и подросшим (смею на это надеяться) российским?
Лично у меня ответа пока нет, но есть чувство, что мы находимся в середине большого переходного периода, и конца ему пока не видно.
Образ сервера для деплоя: golden image, immutable infrastructure и многослойная сборка
Образ сервера — это основа предсказуемого деплоя. Одна и та же конфигурация на всех инстансах, развертывание за минуты вместо часов, никаких расхождений между средами. На этой идее держатся immutable infrastructure, сборка образа как финальный шаг CI/CD и подход cattle, not pets.
В новой статье разобрали, чем образ отличается от snapshot и бэкапа. Показали, где в CI/CD место Packer, Docker и cloud-init. Рассказали про многослойную сборку и отдельно — про работу с секретами через переменные окружения и регулярную пересборку базового слоя.
Очередная история про контроллеры домена и ребутлуп после обновления хорошо показывает старую проблему.
Когда каталог ложится, все вспоминают про резервки. Когда каталог подняли, внезапно выясняется, что резервка не умеет ответить на главный вопрос: что из свежих изменений мы сейчас потеряли.
Учётки, членства, атрибуты, результаты массовых правок, последствия миграции – всё это очень легко откатывается вместе с аварией.
В итоге сервис вроде живой, а дальше начинается админская археология.
Поэтому для каталога мало просто уметь подняться из копии. Нужно ещё уметь нормально разруливать логические потери без отката всего подряд.
Потому что «всё поднялось» и «всё починилось» – это, как известно, две разные стадии одного и того же инцидента.
DNS-сервер не отвечает: что делать владельцу сайта
Когда пользователи не могут открыть сайт из-за DNS-ошибки, первый импульс — искать проблему у себя. Но причина часто на стороне владельца: истек домен, сбились NS-записи после смены хостинга или DNS-серверы провайдера легли под DDoS-атаками.
В новой статье собрали диагностику для обеих сторон — и для пользователя, и для администратора сайта: как быстро локализовать проблему, проверить NS-записи и DNS через nslookup и ping, и что делать, если дело все-таки в хостере.
Выделенный CPU в аттестованном облаке 152-ФЗ: новая линейка тарифов Рег.облака
Компании, которые обрабатывают персональные данные в облаке, привычно сталкиваются с одним компромиссом: либо юридически чистая инфраструктура, либо предсказуемая производительность. Рег.облако запустил линейку тарифов, которая закрывает оба требования сразу.
Новые тарифы с выделенным CPU работают в аттестованном облаке до 1 уровня защищенности по требованиям 152-ФЗ и ФСТЭК. Физические ядра процессора не делятся с другими виртуальными машинами — никакой переподписки и влияния соседних нагрузок. В основе — процессоры Intel Xeon Gold 2,8 ГГц и NVMe-накопители с низкими задержками.
Сценарий очевидный: базы данных с персональными данными — PostgreSQL, MySQL, 1С, Oracle — и любые высоконагруженные системы в регулируемых отраслях, где просадка производительности недопустима.
Как выбрать дисковую систему для выделенного сервера
Выбор накопителя определяет производительность и надежность сервера целиком. Но правильного ответа для всех не существует — конфигурация зависит от задач конкретного проекта.
В новой статье мы сравнили NVMe SSD, SATA SSD и SATA HDD, разобрали как работают дисковые массивы RAID и какую конфигурацию выбрать под разные сценарии.
Автоматизация рутины в ispmanager: скрипты, CRON и плагины
Настройка серверов, бэкапы, обновления, управление пользователями — всё это можно делать вручную. Или один раз настроить и забыть.
В новой статье разобрали, как автоматизировать типовые задачи в ispmanager: настроить планировщик CRON прямо из панели, написать скрипт резервного копирования, создать собственный плагин и подключить внешние инструменты вроде Zabbix или Git. Подробности — в блоге Рег.облака.
Раньше можно было запускать только статику (SSG) и одностраничные приложения (SPA). К ним добавился и серверный рендеринг (SSR).
SSR — это когда страница собирается на сервере и сразу приходит пользователю готовой. Например, в интернет-магазине вы сразу увидите товары и цены без пустого экрана и долгой загрузки.
Что дает этот режим:
+1 к гибкости разработки. В приложении можно использовать серверную логику, авторизацию и собственные API-обработчики.
+1 к SEO. Страницы рендерятся на сервере → лучше индексируются и быстрее попадают в выдачу.
+1 к простоте архитектуры. Не нужно создавать отдельный бэкенд, ведь часть логики можно держать в SSR.
Как включить: при создании просто активируйте SSR — приложение развернется как бэкенд, где можно выбрать конфигурацию сервера и задать команду запуска.
Минимальный конфиг: от 510 ₽/мес с 1 CPU и 1 ГБ RAM
☝🏻 После деплоя режим изменить нельзя. Для других настроек создайте новое приложение.
