Первые шаги на сервере: что быстрее освоить — консоль или ispmanager
У новичка на сервере обычно два пути: открыть панель управления в браузере или подключиться по SSH и разбираться с командами. Панель дает готовые формы под типовые операции, консоль — прямой доступ к системе. Освоить панель получится быстрее, но Linux под ней никуда не денется.
В статье сравнили оба подхода по сильным и слабым сторонам, разобрали сценарии для разработчика, владельца сайта и системного администратора и собрали минимум знаний Linux, который понадобится даже при работе через панель.
Антипаттерн при работе с VPS: почему не стоит постоянно работать под root? Работать под root на VPS удобно: перед командами не нужно вводить sudo. Но ошибка может затронуть весь сервер, а безопасность VPS требует разделять обычные и административные действия.
Почему работа под root удобна и опасна? В Unix доступ к файлам и управление процессами зависят от пользователя и его групп. Root может изменять системные файлы, управлять службами, пакетами и сетью. При постоянной работе под root ошибка в команде способна затронуть системные файлы и службы. Опечатка в пути команды удаления или ошибка в скрипте, запущенном от root, может стереть системные файлы, изменить права на каталоги и остановить сервисы. При запуске от обычного пользователя ущерб чаще ограничен его правами. Украденный ключ, разрешающий вход под root, или пароль этой учётной записи сразу дают административные права. Ключ обычного пользователя даёт доступ только с его правами. Получение root-прав зависит от настроек sudo, пароля, уязвимостей и ошибок конфигурации.
Как правильно: отдельный пользователь и sudo.
В Ubuntu или Debian создайте пользователя и добавьте его в группу sudo:
adduser operator
usermod -aG sudo operator
Добавьте публичный ключ в файл .ssh/authorized_keys в домашнем каталоге нового пользователя и проверьте вход по SSH. Затем задайте параметр в
/etc/ssh/sshd_config:
PermitRootLogin no
Проверьте конфигурацию и примените изменения без разрыва текущих подключений:
sshd -t && systemctl reload ssh
Мини-чек-лист безопасного старта на VPS
• Отдельный пользователь создан, команды запускаются через sudo.
Почему дешёвый VPS-сервер может обойтись дорого в продакшене? Тариф в 3–5 долларов в месяц за VPS кажется приятной экономией на старте. Но если тариф выбран только по цене, счёт за простой, срочную миграцию и потерянных клиентов может прийти позже и оказаться выше, чем сэкономленная разница в ценнике.
Что скрывается за низким ценником? За низкой ценой могут стоять оверселлинг, общий диск, ограниченная поддержка и слабые гарантии по SLA. У части провайдеров низкая цена достигается за счёт плотного размещения клиентов на одной ноде: продаётся больше vCPU и RAM, чем физически доступно, в расчёте на то, что нагрузки не совпадут. В результате могут появляться CPU steal time, просадки I/O от соседей по железу и нестабильная производительность общего хранилища. SLA на бюджетном VPS-сервере может отсутствовать или ограничиваться формальным обещанием без понятной компенсации.
Реальные риски в продакшене. Под нагрузкой проблемы проявляются внезапно: API начинает отвечать с задержками, база данных упирается в I/O, сервис падает в самый неподходящий момент. Потеря данных из-за отсутствия бэкапов или срочная миграция перед дедлайном – реальные риски для проектов, которые выбирают инфраструктуру только по цене.
Как считать полную стоимость VPS? Реальная цена – это не только тариф, а TCO: тариф + стоимость инцидентов. Один час простоя интернет-магазина в пиковый сезон легко перекрывает годовую разницу между дешёвым и надёжным VPS. Добавьте часы на диагностику и миграцию, потери из-за недовольных клиентов – и экономия быстро испаряется.
Чек-лист: признаки надёжного VPS:
• SLA не ниже 99,9%
• NVMe-хранилище со стабильной производительностью или понятными IOPS-лимитами
• Современная аппаратная виртуализация, например KVM, и понятная политика изоляции ресурсов
• Автоматические бэкапы с проверенным восстановлением
• Поддержка 24/7 с заявленным временем ответа
• Гарантированная пропускная способность сети
Прежде чем продлевать текущий тариф, проверьте свой VPS по этому чек-листу. Если несколько пунктов вызывают сомнения – стоит пересмотреть выбор сервера для продакшена до первого серьёзного инцидента.
Почему аптайм зависит не только от VPS-провайдера?
Провайдер может обещать 99,9% аптайма VPS, но аптайм продукта и аптайм инфраструктурного узла остаются разными показателями. Когда сервис падает, причина часто находится за пределами зоны ответственности провайдера: в приложении, деплое, базе данных, DNS или внешних API.
Что именно гарантирует VPS-провайдер? SLA VPS-провайдера покрывает доступность физического узла, сетевого канала и питания. Если оборудование работает и сеть доступна, инфраструктурная часть SLA может считаться выполненной. Код, конфигурации, база данных и внешние зависимости остаются в вашей зоне ответственности.
Где на самом деле ломается аптайм? На практике многие простои возникают не из-за сбоев инфраструктуры, а из-за ошибок в коде и операционных процессах. Неудачный деплой, утечка памяти, переполненный диск, истёкший SSL-сертификат, недоступный DNS или упавший сторонний API гасят сервис независимо от стабильности хостинга.
Ошибки на стороне команды. Релиз без стейджинга и механизма отката, отсутствие проверок состояния, ручные правки конфигурации в продакшене: всё это классические источники простоев. Мониторинг, добавленный «потом», не предупреждает о проблеме до того, как её замечают пользователи.
Как повысить реальный аптайм сервиса? Стабильность сервиса на VPS складывается из нескольких пунктов. Автоматические бэкапы и снапшоты упрощают восстановление после сбоя. Проверки состояния и алерты сокращают время обнаружения инцидента. CI/CD-пайплайн с проверками и понятным откатом снижает риск ошибок при деплое.
Чек-лист надёжности:
Бэкапы и снапшоты настроены и проверены
DNS TTL снижен перед плановыми миграциями
SSL-сертификаты обновляются автоматически
Есть процедура отката для каждого релиза
Мониторинг и алерты подключены до деплоя
Аптайм сервиса на VPS-сервере зависит от инфраструктуры, архитектуры и операционных процессов одновременно. Пересмотрите собственные процессы: деплой, мониторинг, бэкапы и восстановление после сбоев. Если нужен взгляд со стороны, можно начать с аудита инфраструктуры и точек отказа.
Как разрешить пользователю реплики удаленно подключаться к Master-серверу PostgreSQL?
Вы настраиваете отказоустойчивый кластер баз данных. При попытке синхронизировать реплику с мастер-сервером соединение обрывается с ошибками сетевого доступа. В каком конфигурационном файле и как именно нужно прописать доступы, чтобы Master принял входящее подключение?
По умолчанию PostgreSQL придерживается строгой политики безопасности и блокирует любые удаленные попытки подключения, если они не разрешены в подсистеме авторизации.
Чтобы решить эту проблему, необходимо отредактировать конфигурационный файл клиентской аутентификации pg_hba.conf на стороне Master-сервера и явно разрешить репликацию для IP-адреса вашей реплики.
Для доступа к реплицируемым данным у пользователя replicator должна быть привилегия replication:
ALTER ROLE replicator WITH REPLICATION;
Предварительно ознакомьтесь с порядком применения правил в pg_hba.conf в официальной документации.
Чтобы PostgreSQL применил изменения в конфигурации авторизации, выполните reload службы в терминале:
systemctl reload postgresql
В качестве альтернативы можно отправить сигнал процессу postmaster с помощью pg_ctl reload, вызовом SQL-функции pg_reload_conf() или используя kill -HUP.
После применения изменений Master-сервер начнет принимать входящие пакеты от указанного IP-адреса, и процесс репликации сможет успешно инициализироваться.
На первый взгляд, настройка репликации в PostgreSQL кажется простой задачей: достаточно открыть доступ в pg_hba.conf и подключить standby-сервер.
Но в production-инфраструктуре за этой «простой настройкой» скрывается целый стек инженерных задач: необходимо следить за консистентностью WAL-журнала, контролировать лаг между репликами, обеспечивать безопасную сетевую доступность между узлами, настраивать резервное копирование, регулярно тестировать сценарии аварийного переключения и быть готовым вручную восстанавливать кластер в случае деградации одного из серверов.
Поэтому в ряде сценариев современные команды переходят от self-managed PostgreSQL к PaaS-решениям вроде Managed Databases, где отказоустойчивость, репликация и обслуживание кластера уже реализованы на уровне платформы.
Это позволяет сократить операционные расходы на сопровождение инфраструктуры и снизить риск простоев критичных сервисов.
Мой опыт работы с Selectel: первые впечатления от российского облачного провайдера
Когда проект начинает расти, рано или поздно возникает вопрос инфраструктуры. На старте многие используют самые простые решения: обычный хостинг или виртуальный сервер с минимальными настройками.
Но в какой-то момент появляются другие требования: больше ресурсов, стабильность, возможность быстро масштабироваться и нормальная работа с инфраструктурой.
Именно в этот момент я решил попробовать Selectel.
Почему выбрал Selectel
До этого я рассматривал разные варианты. Главными критериями были:
стабильность работы;
удобное управление сервером;
понятная документация;
возможность быстро менять конфигурацию;
наличие необходимых инструментов.
Хотелось получить не просто сервер, а платформу, с которой можно спокойно развивать проект.
Первое знакомство
Первое, что заметил - это подход к интерфейсу. После регистрации не приходится долго разбираться, где находятся основные функции.
Создание сервера, настройка ресурсов и управление услугами сделаны достаточно понятно даже для тех, кто не работает с инфраструктурой каждый день.
Что понравилось
За время использования больше всего обратил внимание на несколько моментов:
Скорость запуска. Не нужно ждать длительных настроек - необходимые ресурсы можно получить достаточно быстро.
Гибкость. Можно менять конфигурацию под текущие задачи, не покупая лишнее оборудование.
Экосистема. Помимо обычных серверов есть дополнительные инструменты, которые могут пригодиться при развитии проекта.
Что можно улучшить
При этом идеальных сервисов не бывает.
Например, новичкам может понадобиться больше объяснений по некоторым техническим моментам. Облачная инфраструктура сама по себе сложнее обычного хостинга, поэтому порог входа выше.
Итоги
Selectel оставил впечатление платформы, которая больше подходит тем, кто уже вырос из простого хостинга и хочет больше контроля над инфраструктурой.
Для небольших проектов можно начать с базовых решений, но когда появляются требования к масштабированию и стабильности, облачные платформы становятся более логичным выбором.
Как связать контейнеры Nginx и PHP в Docker Compose, чтобы Nginx мог проксировать запросы?
Допустим, вы пытаетесь развернуть связку из веб-сервера и PHP. Контейнеры поднимаются, но веб-сервер выдает ошибку сети и не может достучаться до PHP-бэкенда. Разберемся, что нужно прописать в конфиге Nginx, чтобы они увидели друг друга.
Чаще всего подобная проблема возникает из-за того, что контейнеры изолированы друг от друга на сетевом уровне, либо в конфигурационном файле веб-сервера некорректно указан адрес целевого хоста. В экосистеме Docker Compose встроенный DNS-сервер автоматически сопоставляет имена сервисов с их внутренними IP-адресами. Поэтому не нужно прописывать статические IP — достаточно правильно использовать имена, заданные в манифесте.
Для того чтобы контейнеры могли успешно взаимодействовать по сети внутри Docker Compose, их нужно поместить в единое сетевое пространство и правильно настроить проксирование.
Чтобы Nginx мог передавать запросы PHP-FPM, необходимо:
убедиться, что оба контейнера находятся в одной сети (app_network),
указать в конфигурации Nginx правильный адрес PHP-контейнера (в нашем примере это php:9000, где php — имя сервиса в docker-compose.yml).
Шаг 1: Проверка манифеста docker-compose.yml
Убедитесь, что для обоих сервисов явно выделена одна общая сеть. Пример корректной структуры:
В блоке location, отвечающем за обработку PHP-скриптов, в директиве fastcgi_pass вместо 127.0.0.1 или localhost необходимо подставить имя сервиса PHP из файла конфигурации:
server {
listen 80;
server_name localhost;
root /var/www/html;
index index.php index.html;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
fastcgi_pass php:9000; # Связь с PHP-контейнером
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
Директива depends_on в блоке Nginx гарантирует, что веб-сервер не начнет стартовать раньше, чем поднимется контейнер с PHP. Это предотвратит падение Nginx при первичном запуске окружения, если он не сможет сразу разрешить DNS-имя php.
Что делать, если Python-сервер падает из-за утечки памяти?
Привет, Хабр! Это наша экспериментальная рубрика, в которой мы даем новичкам быстрые ответы на четкие вопросы. Писать статью будет излишним, а некоторую пользу до аудитории донести, возможно, получится.
Итак, допустим, агент спустя время начинает расти по памяти и в итоге все падает. Где копать и как временно ограничить ущерб, пока ищете утечку?
Первое, что нужно сделать — измерить и локализовать. tracemalloc показывает, какие строки выделяют больше всего памяти, gc — количество объектов.
Часто проблема в неограниченных кэшах, списках или в C-расширениях. Сначала стоит включить tracemalloc, дать процессу поработать и снять снапшот:
import tracemalloc
tracemalloc.start()
# после нагрузки
snapshot = tracemalloc.take_snapshot()
top = snapshot.statistics('lineno')[:10]
for stat in top:
print(stat)
Параллельно делайте gc.collect() и логируйте число объектов len(gc.get_objects()), чтобы увидеть рост. На время расследования применяйте эксплуатационные меры: для WSGI-сервисов используйте Gunicorn с --max-requests и --max-requests-jitter, чтобы процессы периодически перезапускались и не накапливали мусор. А в контейнерах ставьте cgroup-пределы (--memory) и настраивайте restart-политику, чтобы платформа автоматически перезапускала упавшие поды.
Если утечка в C-расширении или сторонней библиотеке, то временно автоматический перезапуск и мониторинг позволяют сохранить сервис работоспособным, пока вы находите корень проблемы и исправляете код.
Если хотите освоить инструменты Python, то в Академии Selectel у нас есть отдельная подборка статей. Там мы рассказываем, как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга.
Почему трафик в ЦОДе балансируется не так, как вы ожидали
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 и больших моделей.
