2026 — Снабжающая Компания Дана

Windows Server 2022 перешёл с основной на расширенную поддержку 13 октября 2026 года. Как сообщает BleepingComputer со ссылкой на Microsoft, октябрьское обновление стало последним в рамках основного периода; ежемесячные обновления безопасности будут выходить до 14 октября 2031 года. Для админа это не команда срочно выключить сервер, а повод пересмотреть срок его эксплуатации и план миграции. Подробности — в источнике.

Сначала отделите поддержку от работоспособности

Windows Server 2022 вышел в общую доступность в сентябре 2021 года как выпуск с длительным сроком поддержки — LTSC. Теперь система находится в периоде расширенной поддержки: Microsoft продолжит выпускать обновления безопасности без дополнительной платы. Это не делает лицензии бесплатными и не означает, что любой запрос на изменение поведения системы будет решён обновлением. Для работающей инфраструктуры практический вопрос звучит так: успеете ли вы обновить ОС до конца поддержки, не потеряв совместимость приложений и оборудования?

Microsoft рекомендует планировать переход на Windows Server 2025. Для него в новости указаны окончание основной поддержки в ноябре 2029 года и расширенной — 14 ноября 2034 года. Сравнивать эти сроки полезно не сами по себе, а с планируемым сроком жизни конкретной стойки, кластера или прикладной системы.

Чек-лист для инженера и закупщика

• Соберите список экземпляров, а не только физических серверов. Проверьте виртуальные машины, шаблоны развёртывания, резервные узлы и системы, которые редко попадают в отчёты мониторинга. Рядом с каждым экземпляром запишите роль, владельца сервиса, критичность, площадку и способ установки обновлений. Иначе при миграции легко заменить заметный файловый сервер, но оставить старую ОС в шаблоне, из которого завтра поднимут новую машину.
• Убедитесь, что обновления безопасности действительно доходят. Для каждого сервера проверьте источник обновлений, состояние последней установки и причины отложенных перезагрузок. Доступность обновлений до октября 2031 года бесполезна, если сервер месяцами ждёт окна обслуживания или потерял связь с корпоративным контуром обновлений. Зафиксируйте ответственного за проверку после каждого цикла установки, а не только за запуск задания.
• Разделите системы по сценарию дальнейшей жизни. Одним достаточно оставаться на Windows Server 2022 с установленными исправлениями, другим нужен переход на Windows Server 2025 из-за срока проекта или требований прикладного ПО. Для критичных служб отдельно оцените цену простоя и сложность отката. Решение «пока не трогать» тоже оформите: укажите, когда его пересмотреть и какое событие запустит миграцию.
• Проверьте зависимость от конкретного выпуска ОС. Составьте список приложений, агентов резервного копирования, средств защиты, драйверов и компонентов управления, которые работают на сервере. Запросите у их поставщиков подтверждение совместимости с Windows Server 2025 и требования к порядку обновления. Успешный запуск тестовой виртуальной машины ещё не доказывает, что в рабочем контуре пройдут резервное копирование, восстановление и штатное переключение службы.
• Испытайте миграцию на копии типовой нагрузки. Для проверки можно использовать доступную через Microsoft Evaluation Center пробную версию Windows Server 2025 на 180 дней. Повторите не только установку ОС, но и ввод машины в управление, подключение мониторинга, восстановление из резервной копии и прикладные проверки. Результат оформите коротким протоколом: что проверили, что не заработало и какой шаг потребуется перед переносом рабочего сервиса.
• Запланируйте откат до начала изменений. Укажите, где хранится проверенная копия данных, кто принимает решение остановить миграцию и как сервис возвращается на прежний узел. Особенно внимательно пройдите службы, у которых данные меняются во время переключения: вернуть старую виртуальную машину недостаточно, если состояние приложения уже разошлось. Репетиция отката часто обнаруживает больше проблем, чем сама пробная установка.
• Сверьте ОС с жизненным циклом железа. Если под новую систему планируется новый сервер, проверьте совместимость модели, контроллера хранения, сетевых адаптеров и средств удалённого управления. Для существующего оборудования запросите у вендора документацию по поддерживаемым конфигурациям и доступным драйверам. Не закладывайте покупку только по принципу «процессор мощнее прежнего»: сначала подтвердите, что на выбранной платформе поддерживается весь рабочий стек.
• Посчитайте закупку как проект, а не как цену сервера. В смету внесите оборудование, необходимые лицензии, внедрение, тестирование, резервирование, перенос данных и сопровождение. Для закупок в Казахстане заранее уточните у поставщика сроки поставки конкретной конфигурации, состав документов, условия гарантии и порядок обращения за поддержкой. Если замена узлов привязана к окну миграции, отдельно согласуйте, что произойдёт при задержке поставки или замене комплектующих на аналоги.
• Проверьте применимость hotpatch, прежде чем включать его в план. Microsoft продлила эту возможность до октября 2027 года для систем Windows Server 2022 Datacenter: Azure Edition. Не переносите этот срок автоматически на обычные установки Windows Server 2022. Если сокращение перезагрузок заложено в график обслуживания, сначала подтвердите выпуск и условия использования на конкретных экземплярах, а затем составьте отдельный порядок установки исправлений для остальных серверов.
• Назначьте контрольную дату для каждого сервиса. Общий срок расширенной поддержки — 14 октября 2031 года, но миграцию нельзя начинать в день его окончания. Отсчитайте время на согласования, закупку, испытания, перенос и возможный повтор работ. Для длительных проектов сравните горизонт эксплуатации с датами поддержки Windows Server 2025: так станет видно, не потребуется ли ещё одна замена ОС раньше окончания самого проекта.

Где план обычно ломается

«Обновления будут, значит ничего делать не надо». Исправления безопасности снижают один из рисков, но не решают вопросы совместимости новых версий приложений, износа оборудования и окончания гарантийных обязательств. Если сервер обслуживает важный сервис, владельцу нужна понятная дата пересмотра решения и рабочая процедура восстановления.

«Раз тестовая установка прошла, можно переносить всё». Тест без прикладных сценариев почти ничего не говорит о миграции. Проверяйте права доступа, задания по расписанию, сетевые зависимости, мониторинг и восстановление данных. Отдельно согласуйте, кто подписывает результат: администратор может подтвердить здоровье ОС, но корректность бизнес-процесса должен проверить владелец приложения.

«Поставщик подберёт аналог на месте». Для закупки сформулируйте требования к поддерживаемой ОС, конфигурации, документации и гарантии до размещения заказа. При замене модели запросите повторное подтверждение совместимости: сходные характеристики в прайс-листе не заменяют проверку драйверов, прошивок и условий поддержки.

Windows Server 2022 продолжит получать обновления безопасности до октября 2031 года, поэтому решение о миграции можно принимать без паники. Но инвентаризацию, тесты и закупочную подготовку лучше вести как одну задачу: именно на стыке ОС, приложений и оборудования чаще всего теряется время. Если под переход потребуется новая платформа, начать сверку конфигураций можно в разделе серверов. За другими практическими разборами подписывайтесь на блог.

Cisco выпустила рекомендации по пяти критическим уязвимостям NX-OS: на затронутых коммутаторах Nexus они могут привести к выполнению произвольного кода с правами root. Другой возможный исход — сбой процессов и перезагрузка устройства с потерей доступности сети. Речь о Nexus 3000 и Nexus 9000 в автономном режиме NX-OS, причём возможность эксплуатации зависит от включённых функций. Об этом сообщает BleepingComputer — на источник стоит заглянуть перед составлением плана работ.

Для инженера здесь главное не слово «критические», а условия атаки. Затронуты NX-API, Next Generation OAM (NGOAM) и MPLS OAM. Одна и та же модель в инвентарной ведомости может требовать разных действий в зависимости от режима работы и конфигурации. Разберём типичные выводы, которые легко сделать по заголовку новости, но опасно переносить в рабочий план без проверки.

Мифы и факты о затронутых Nexus

Миф: любой Nexus 9000 уязвим одинаково

Факт: рекомендации относятся к Nexus 3000 и Nexus 9000 в автономном режиме NX-OS. Nexus 9000 под управлением ACI и Nexus 7000, по данным Cisco, не затронуты ни одной из этих пяти уязвимостей. Но строка «Nexus 9000» в учётной системе ещё не отвечает на вопрос о риске: надо сверить режим работы и активные функции конкретного устройства.

На практике начните с привязки инвентарной записи к живому коммутатору: модель, режим, версия NX-OS, роль в сети и ответственная команда. Если в стойке есть пара коммутаторов для отказоустойчивости, проверяйте каждый отдельно. Расхождение конфигураций между ними — вполне рабочая ситуация после миграций и аварийных изменений; делать вывод по одному соседу нельзя.

Миф: раз NX-API выключен, можно закрывать заявку

Факт: NX-API действительно отключён по умолчанию, а CVE-2026-76471 связана со специально сформированным HTTP-запросом к нему. Но ещё три уязвимости — CVE-2026-76485, CVE-2026-76486 и CVE-2026-76501 — связаны с обработкой IP-трафика при включённом NGOAM. Отдельная CVE-2026-76465 относится к MPLS OAM. Проверка одной функции не заменяет проверку остальных.

Ищите не только явное включение в текущей конфигурации. Сверьте, зачем функция появилась: используется ли она системой управления, средствами диагностики или сетевым дизайном. После этого фиксируйте решение — отключать её или оставлять до обновления. Простое «у нас API не используют» без проверки работающей конфигурации слишком легко превращается в ложное чувство безопасности.

Миф: включённый NGOAM означает один и тот же сценарий для всех трёх CVE

Факт: для этой группы уязвимостей требуется NGOAM, однако дополнительные условия различаются. Для CVE-2026-76486 нужен также SRv6 либо NV Overlay. В случае NV Overlay Cisco уточняет конфигурацию VXLAN EVPN: VNI должен быть сопоставлен с интерфейсом NVE, а у него должен быть известен хотя бы один соседний VTEP. CVE-2026-76501 эксплуатируется при включённом SRv6; эта функция поддерживается лишь некоторыми моделями Nexus 9000.

При разборе инцидентного бюллетеня это полезнее общей пометки «NGOAM есть». У инженера должен получиться перечень условий для каждого коммутатора: включён ли NGOAM, используются ли SRv6 или NV Overlay, и выполнены ли необходимые условия для VXLAN EVPN. Такой перечень помогает расставить приоритеты без гадания по названию платформы. При этом отсутствие дополнительного условия для одной CVE не отменяет проверки остальных уязвимостей NGOAM.

Миф: MPLS OAM можно не проверять — он и так выключен

Факт: MPLS OAM отключён по умолчанию, но CVE-2026-76465 применима, когда его явно активировали. Cisco описывает специально сформированный MPLS echo-request, отправленный на IP-адрес затронутого устройства. Для Nexus 9000 с ASIC Silicon One есть отдельное исключение: они не поддерживают MPLS OAM и этой уязвимости не подвержены.

Уточняйте аппаратную платформу и реальное состояние функции, а не полагайтесь на заводские настройки. В сети после нескольких проектов настройки по умолчанию давно могли смениться. Если MPLS OAM нужен для диагностики, согласуйте последствия его отключения с сетевой командой: устранить вектор атаки полезно, но потерять рабочий инструмент поиска неисправностей посреди эксплуатации — плохой обмен.

Миф: временная защита позволяет отложить обновление без плана

Факт: Cisco рекомендует переходить на исправленный выпуск NX-OS; подходящую версию предлагает определить через Software Checker. Для оборудования, которое пока нельзя обновить и перезагрузить, предусмотрены временные механизмы защиты Live Protect для всех пяти уязвимостей. Если NX-API, NGOAM или MPLS OAM не нужны, Cisco рекомендует их отключить.

Это разные меры для разных ограничений. Отключение функции убирает связанный с ней вектор атаки, но требует проверки зависимостей. Live Protect помогает пережить период до окна работ, а не отменяет необходимость определить исправленный выпуск. Обновление закрывайте только после проверки состояния коммутатора и сохранения сведений о том, что установлено и какие функции остались активны.

Что сделать до ближайшего окна работ

1. Составьте список устройств. Отделите Nexus 3000 и Nexus 9000 в автономном NX-OS от Nexus 7000 и Nexus 9000 в ACI. Для каждого затронутого устройства запишите модель, текущий выпуск NX-OS, роль и контакт владельца сервиса. Это основа для разговора с эксплуатацией и закупками, если обновление потребует дополнительной подготовки.
2. Проверьте функции по каждому коммутатору. Зафиксируйте состояние NX-API, NGOAM и MPLS OAM. Для NGOAM отдельно проверьте SRv6 и NV Overlay; для сценария с NV Overlay — условия VXLAN EVPN, NVE и соседнего VTEP. Для MPLS OAM уточните, не относится ли устройство к Nexus 9000 с Silicon One. Не подменяйте проверку предположением о типовой конфигурации.
3. Найдите исправленный выпуск. Сверьте установленную версию с рекомендациями Cisco через Software Checker. Перед изменениями проверьте совместимость выбранного выпуска с конкретной моделью и используемыми функциями, подготовьте резервную копию конфигурации и порядок возврата. Перезагрузку планируйте с учётом роли коммутатора, а не только свободного времени администратора.
4. Разделите постоянную и временную меры. Неиспользуемые функции — кандидаты на отключение после проверки зависимостей. Если обновление и перезагрузка пока невозможны, уточните применимость Live Protect и назначьте окно для перехода на исправленный выпуск. По завершении работ повторно проверьте версию, настройки и работоспособность сетевых сервисов.

Где обычно ошибаются при согласовании работ

Первая ловушка — смешать возможность выполнения кода и гарантированный захват коммутатора. Cisco описывает возможность выполнения кода с правами root, но также и сценарий, при котором атака приводит к сбою процессов и перезагрузке. Для ЦОД оба исхода серьёзны: даже без закрепления атакующего внезапная потеря сетевого узла может ударить по приложениям. Поэтому в заявке на изменения фиксируйте не только риск компрометации, но и риск простоя.

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

Если для работ нужны поддержка или поставка оборудования, в Казахстане разумно заранее согласовать с поставщиком совместимость конкретной модели и программного выпуска, комплект документации, гарантийные условия и сроки поставки. Не закладывайте замену устройства в план только из-за громкого заголовка: сначала выясните, затронуто ли оно и доступен ли исправленный выпуск. И наоборот, если замена действительно нужна, учитывайте её срок вместе с окном миграции и порядком возврата.

У Cisco одновременно вышли и рекомендации по Cisco License, ранее Smart Software Manager. Это отдельный продукт и отдельная задача: затронутые выпуски уязвимы независимо от конфигурации, обходных решений нет, рекомендовано обновление до 10-202609. Старые выпуски под прежним названием исправления не получат — для них Cisco рекомендует переход на поддерживаемый выпуск. Не смешивайте эту заявку с проверкой функций NX-OS: ответственные и план изменений могут различаться.

Сначала конфигурация, затем обновление

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

Dell призвала срочно обновить Dell System Update (DSU): критическая уязвимость CVE-2026-86360 позволяет удалённому атакующему без учётной записи потенциально выполнить произвольный код с правами root. Причина — ошибка обработки путей к файлам. Как сообщает BleepingComputer со ссылкой на предупреждение Dell, исправление входит в DSU версии 2.3.0.0 и более поздние выпуски. Подробности — в источнике.

DSU — утилита командной строки, через которую администраторы устанавливают обновления BIOS, прошивок и программного обеспечения на серверах PowerEdge под Linux и Windows. Поэтому проверять нужно не только серверы, на которых сейчас идёт обновление, но и те, где утилиту оставили после прежнего обслуживания. Вместе с критической ошибкой Dell закрыла в DSU четыре уязвимости высокой степени опасности: CVE-2026-63697 и CVE-2026-71168 связаны с удалённым выполнением кода, CVE-2026-86361 и CVE-2026-86362 — с повышением привилегий.

Почему утилита обновления попадает в приоритетный список

Обычный серверный сервис легко найти в реестре приложений: у него есть владелец, адрес и порядок сопровождения. С DSU бывает иначе. Администратор мог установить её ради прошивки контроллера, добавить в образ ОС или вызвать из задания автоматизации. Когда работы закончились, пакет остался. Именно такую «вспомогательную» установку легко пропустить при плановом разборе уязвимостей.

Здесь цена ошибки выше, чем у рядовой пользовательской программы. Утилита обслуживает инфраструктуру PowerEdge, а описанная Dell атака допускает выполнение кода с максимальными правами. Приоритет проверки определяйте не по тому, насколько часто запускают DSU, а по сочетанию версии, доступности уязвимого компонента и роли сервера. Узел виртуализации, сервер резервного копирования и машина с доступом к административной сети требуют особенно аккуратного разбора последствий.

Формулировка «удалённый атакующий» не означает, что на каждом PowerEdge открыт одинаковый сетевой порт. Не стройте схему атаки по одному заголовку новости. Для своей установки выясните, какие компоненты DSU задействованы, откуда к ним есть доступ и какие сетевые ограничения действуют. Даже если внешний доступ исключён, это не повод откладывать исправление на неопределённый срок: внутренние сегменты тоже входят в модель угроз.

Порядок работ: от инвентаризации до повторной проверки

1. Найдите все установки DSU. Сверьте данные системы управления конфигурациями с установленными пакетами на Linux, списком программ и файлов на Windows, а также с образами развёртывания и сценариями обновления. Зачем: инвентаризация только работающих процессов не обнаружит утилиту, которую запускают по расписанию или вручную. Зафиксируйте сервер, версию, владельца системы и способ установки; не ограничивайтесь общим списком оборудования Dell.
2. Проверьте фактическую версию и доступ. Сопоставьте версию каждой найденной установки с порогом 2.3.0.0 или более поздним выпуском. Затем посмотрите правила межсетевого экрана, доступ из административных подсетей, задания оркестрации и учётные записи, от имени которых работает обновление. Зачем: так вы отделите срочное исправление уязвимой установки от проверки пакета, который уже обновлён, и сможете снизить доступность компонента до окончания работ.
3. Разберите зависимости перед заменой пакета. На тестовом узле проверьте, как новая версия DSU взаимодействует с вашей ОС, моделью сервера, репозиториями обновлений и существующими сценариями. Сохраните используемые параметры запуска и перечень заданий. Зачем: замена утилиты не должна неожиданно остановить очередное обслуживание прошивок или изменить поведение автоматизации. При вопросах по поддерживаемым сочетаниям опирайтесь на документацию Dell и подтверждение поставщика.
4. Подготовьте окно и путь отката. Разделите обновление самой DSU и установку BIOS или прошивок: это разные изменения с разными рисками простоя. Убедитесь, что резервные копии и процедура восстановления актуальны, согласуйте окно с владельцем сервиса, назначьте ответственного за проверку после работ. Зачем: попытка одновременно исправить утилиту и обновить все прошивки усложняет поиск причины сбоя.
5. Обновите DSU и проверьте результат. Установите версию 2.3.0.0 или новее из официального канала, затем повторно проверьте установленную версию и выполнение штатных заданий обновления. Отдельно проверьте, не сохранился ли старый пакет в шаблоне развёртывания, локальном репозитории или сценарии подготовки нового сервера. Зачем: иначе исправленный узел легко заменить новым — с той же уязвимой версией.
6. Закройте работу записью в инвентаризации. Зафиксируйте результат проверки, версию после обновления, исключения и назначенного владельца каждого оставшегося узла. Если обновить систему сразу нельзя, документируйте временное ограничение доступа и дату повторного рассмотрения. Зачем: без такого следа следующий дежурный не отличит сознательно отложенную работу от забытого сервера.

Что проверить в журнале и чего не ждать от патча

При обнаружении старой версии не ограничивайтесь установкой новой. Просмотрите журналы ОС, запуска DSU и средств централизованного мониторинга за доступный период: необычные вызовы утилиты, изменения файлов, незнакомые административные действия. Сопоставляйте события с утверждёнными работами — легитимное обновление тоже выглядит как изменение системных файлов. Если есть признаки посторонней активности, действуйте по процедуре реагирования, а не пытайтесь «лечить» возможный инцидент одной заменой пакета.

Dell пока не отмечала перечисленные уязвимости как активно эксплуатируемые. Это не подтверждение безопасности конкретного сервера и не основание объявлять его скомпрометированным. Практический вывод проще: исправляйте уязвимую версию, проверяйте доступ и сохраняйте данные, нужные для расследования, если оно потребуется.

Не смешивайте эту задачу с другими предупреждениями Dell. В тот же день компания призвала исправить две уязвимости максимальной степени опасности в Container Storage Modules — CVE-2026-63688 и CVE-2026-63692. Если в инфраструктуре используется CSM, заведите для него отдельную проверку и отдельный план обновления. Обновление DSU само по себе не заменяет работу с другим продуктом.

Где чаще всего ломается план обновления

• Проверяют только Linux. DSU применяется и на Windows-системах PowerEdge. Список активов и сценарии поиска должны охватывать обе платформы; при этом формулировку о правах root не стоит механически переносить на модель привилегий Windows.
• Путают версию утилиты с версией прошивки. Свежий BIOS не доказывает, что исправлена DSU. Проверяйте именно установленный пакет, а затем отдельно оценивайте состояние прошивок.
• Удаляют компонент без разговора с эксплуатацией. Если DSU встроена в регламент обслуживания, удаление может сорвать запланированные обновления. Сначала найдите зависимости, затем решайте, обновлять утилиту или выводить её из эксплуатации.
• Полностью полагаются на сегментацию. Ограничение доступа снижает риск, но не исправляет ошибку в пакете. Проверка сетевых правил — временная мера и часть контроля, а не замена обновлению.

Для команд в Казахстане здесь есть и закупочная часть работы. Если серверы обслуживает подрядчик или DSU включена в поставляемый образ, запросите подтверждение версии, перечень совместимых ОС и моделей, документацию по обновлению и порядок поддержки после установки. При планировании окна заранее согласуйте доступ к нужным пакетам и действия на случай неудачного обновления; сроки поставки оборудования или обслуживания уточняйте под свой проект. При выборе серверов полезно сразу закрепить, кто отвечает за обновление служебных утилит после ввода системы в эксплуатацию: поставщик, подрядчик или внутренняя команда.

Исправить пакет — и не потерять его снова

Главное действие сейчас — найти DSU на PowerEdge и довести обнаруженные установки до версии 2.3.0.0 или новее, не забыв про образы и автоматизацию. Параллельно проверьте доступ и сохраните понятный след выполненных работ. За другими практическими разборами серверной инфраструктуры можно следить в блоге.

Broadcom лишила Insight Enterprises права перепродавать лицензии VMware и услуги VMware Cloud Foundation, финансируемые Broadcom, в Северной Америке. Insight подтвердила решение в комментарии CRN — на источник. Случай заметный: Insight входила в высшую категорию партнёров VMware Pinnacle, а ранее Broadcom сама направляла к ней клиентов других партнёров для продления контрактов.

Это не сообщение об отключении работающих виртуальных машин и не объявление о прекращении всех услуг Insight. Компания заявила, что завершит уже заказанные работы и продолжит оказывать оплачиваемые клиентами услуги по VMware и VCF до 31 октября 2026 года. При этом Insight не уточнила свой партнёрский статус за пределами Северной Америки. Для заказчика в Казахстане новость — повод проверить собственную цепочку закупки, а не считать, что решение Broadcom автоматически распространяется на местного поставщика.

Почему статус крупного партнёра перестал быть достаточной гарантией

В прошлом году, после сокращения партнёрской сети, Broadcom называла Insight среди национальных поставщиков, к которым могли обратиться клиенты за продлением. Теперь сама Insight утратила указанные полномочия в Северной Америке. Вывод для закупок простой: прежняя награда, статус в презентации или успешная поставка в прошлом не подтверждают право оформить следующее продление.

Здесь легко смешать разные роли. Продажа подписки, оказание консультационных услуг и техническая поддержка по действующему договору — не одно и то же. У компании может остаться команда инженеров, способная сопровождать инфраструктуру, но возможность провести конкретный заказ через партнёрский канал зависит от действующих полномочий и условий сделки. Проверять нужно не логотип на сайте поставщика, а маршрут именно вашей покупки: кто выставляет предложение, кто оформляет подписку и куда придёт подтверждение прав на неё.

После приобретения VMware Broadcom сократила партнёрскую сеть, убрала бессрочные лицензии и перевела продажи на подписки с расчётом по ядрам процессоров. На таком фоне ошибка в закупке затрагивает не только цену. Если согласование затянется или счёт окажется невозможным к исполнению, можно не успеть к нужному окну продления, обновления или расширения кластера.

Рабочий сценарий: продление совпало с заменой серверов

Представим обычную задачу ИТ-службы в Казахстане. У компании работает кластер VMware; часть серверов планируют заменить, а вместе с этим предстоит продлить подписку. Администратор готовит конфигурацию новых узлов, закупщик собирает предложения, финансовая служба сверяет бюджет. Поставщик знакомый: раньше через него уже проходили заказы.

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

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

Что проверить до заявки на продление и серверы

• Сроки и состав действующих прав. Поднимите договоры, подтверждения подписок и данные портала заказчика. Отдельно выпишите даты окончания, продукты, объём лицензирования и контакты по поддержке. Не полагайтесь только на старые счета: они показывают прошлую покупку, а не условия будущей.
• Полномочия продавца для конкретной сделки. Попросите поставщика письменно подтвердить право продавать нужные продукты в вашей стране и объяснить, через какое юридическое лицо и канал будет оформлен заказ. Уточните, кто отвечает за регистрацию прав, выставление документов и исправление ошибки в заказе.
• Расчёт конфигурации. Сверьте число и характеристики процессоров в существующих и планируемых узлах с коммерческим предложением. Для подписки, рассчитываемой по ядрам, замена сервера может изменить базу расчёта. Просите спецификацию, в которой лицензии можно сопоставить с ведомостью оборудования, а не одну итоговую строку.
• Совместимость до закупки. Проверьте поддержку выбранных платформой серверов, процессоров, сетевых адаптеров и контроллеров, требования к прошивкам и драйверам. Затем сопоставьте результат с версией вашей среды и намеченным путём обновления. Формулировки «подходит для виртуализации» здесь недостаточно.
• Поставка и гарантия. Зафиксируйте в предложении состав комплектации, ожидаемые сроки поставки, гарантийные условия и порядок замены неисправного компонента. Оборудование, лицензии и услуги могут идти по разным договорам; проверьте, кто отвечает за стык между ними.

Полезный результат этой проверки — короткая таблица для проекта: текущие узлы и подписки, планируемые узлы, требуемые права, ответственный за поставку каждой позиции и крайний срок принятия решения. Она быстро показывает, где всё ещё стоит «уточним позже». Именно такие пустые ячейки обычно превращаются в простой проекта.

План Б без поспешной миграции

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

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

Есть и промежуточный вариант: не менять платформу немедленно, но убрать зависимость от одного устного обещания поставщика. Заранее запросите альтернативный подтверждённый маршрут закупки, сохраните актуальную документацию по конфигурации и проверьте, что доступы к данным о подписках и поддержке принадлежат заказчику, а не только подрядчику. Тогда смена посредника не начнётся с поиска учётных записей и договоров.

Где чаще всего ошибаются

• Переносят североамериканскую новость на весь рынок. Решение, подтверждённое Insight, касается указанного региона и конкретных видов продаж и услуг. Для закупки в Казахстане проверяйте местную цепочку отдельно.
• Смешивают полномочия на продажу с поддержкой существующей среды. Даже в случае Insight компания отдельно сообщила о продолжении уже заказанных и оплачиваемых клиентами работ до установленной даты. У своего контрагента запрашивайте раздельные ответы по поставке лицензий, сопровождению и открытым обращениям.
• Выбирают сервер только по цене и доступности. Дешевле купить узел сейчас, чем держать проект? Возможно. Но без проверки совместимости, расчёта лицензий и условий гарантии первоначальная экономия легко исчезает при вводе в эксплуатацию.
• Считают причиной решения слухи. CRN приводит мнения участников канала о возможных мотивах Broadcom, но официального объяснения причин в публикации нет. Строить закупочную стратегию на этих догадках не стоит.

При запросе предложения задайте поставщику прямые вопросы: кто будет стороной договора, каким документом подтверждаются полномочия на нужный продукт, когда заказчик увидит оформленные права, кто принимает обращения по поддержке и что произойдёт, если поставка или оформление задержатся. Ответы лучше получить до согласования бюджета — в переписке и спецификации, которые останутся у команды проекта.

Что забрать в работу

История Insight показывает, что даже заметный партнёрский статус не заменяет проверки конкретной сделки. Для казахстанской ИТ-службы практический шаг — связать план обновления серверов с проверкой подписок, совместимости и полномочий поставщика, а альтернативу платформе оценивать на тестовом контуре, без спешки. За похожими разборами инфраструктурных решений можно следить в блоге «Снабжающей Компании Дана».

Европейская комиссия предложила законопроект, обязывающий дата-центры раскрывать восемь ключевых показателей эффективности (KPI), включая PUE (Power Usage Effectiveness) для оценки использования энергии. Эта инициатива направлена на повышение прозрачности и устойчивости в секторе дата-центров.

Что такое PUE и его значение

PUE – это коэффициент, который измеряет общее потребление энергии дата-центра по сравнению с энергией, потребляемой ИТ-оборудованием. Например, если дата-центр потребляет 100 кВт для работы оборудования и 50 кВт для охлаждения и освещения, то PUE составит 1.5. На практике, идеальное значение PUE стремится к 1.0, но реальный диапазон для современных больших центров часто варьируется от 1.1 до 1.8.

Реальное применение KPI в дата-центрах

Согласно нововведениям, дата-центры в ЕС будут обязаны представлять информацию о PUE и других показателях, таких как потребление воды и углеродный след. Это помогает не только в мониторинге энергоэффективности, но и в оптимизации затрат на эксплуатацию. Внедрение таких мер требует от операторов существенных инвестиций в систему мониторинга и управления, включая использование оборудования от таких производителей, как HPE и Dell, которые предлагают решения для сбора и анализа данных о потреблении ресурсов.

Как это повлияет на инфраструктуру

Для системных администраторов и ИТ-директоров это значит необходимость пересмотра подходов к проектированию и эксплуатации дата-центров. Важно учитывать, что многие компоненты серверов, такие как процессоры Intel Xeon или AMD EPYC, обладают различными характеристиками TDP (Thermal Design Power), которые влияют на общее потребление энергии системы. Снижение PUE можно достичь, выбирая более эффективные серверные решения и оптимизируя охлаждение.

Технические аспекты, влияющие на KPI

Для повышения PUE важно учитывать и другие параметры, такие как MTBF (Mean Time Between Failures) и TCO (Total Cost of Ownership). Например, правильно выбрав компоненты с высокой надежностью и низким энергопотреблением, можно значительно уменьшить общий расход ресурсов. Использование NVMe SSD дисков, вместо традиционных HDD, также может оказать заметное влияние на производительность и эффективность дата-центра.

Перспективы в свете новых требований

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

Компания Synopsys представила свой новый модуль PCI Express (PCIe) 6.x IP, который обеспечивает реальную передачу данных с низкой задержкой и высокой пропускной способностью на уровне 64 GT/s. Это значительно увеличивает возможности для построения современных серверов и дата-центров, что особенно актуально для задач, требующих высокой скорости обработки данных.

Технические особенности PCIe 6.0

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

Применение в дата-центрах

С учетом роста потребностей в высокоскоростной передаче данных, внедрение PCIe 6.0 в серверные решения позволит улучшить работу облачных сервисов, систем машинного обучения и искусственного интеллекта. Например, серверы на базе платформ AMD EPYC или Intel Xeon с поддержкой PCIe 6.0 смогут обрабатывать данные быстрее, что критично для приложений, требующих быстрого отклика.

Совместимость и будущее

Текущие серверные платформы, такие как HPE ProLiant и Dell PowerEdge, могут быть обновлены для поддержки PCIe 6.0, что позволит пользователям извлечь выгоду из новых возможностей без полной замены оборудования. С учетом того, что новые процессоры уже на подходе, интеграция PCIe 6.0 станет ключевым фактором в планировании обновления серверной инфраструктуры.

Технический вывод

Внедрение PCIe 6.0 IP от Synopsys позволяет ожидать значительное увеличение пропускной способности и снижение латентности в серверных системах. Это открывает новые горизонты для обработки данных и сервисов, которые требуют высокой скорости передачи, таких как AI/ML и облачные решения. Использование данной технологии станет важным шагом для системных администраторов и ИТ-директоров, стремящихся улучшить производительность своих дата-центров.

Согласно последним данным, рынок серверных микропроцессоров достигнет $20.66 миллиардов в 2026 году, продолжая расти с CAGR 7.56%, что позволяет прогнозировать его общую стоимость в $29.74 миллиарда к 2031 году.

Влияние на серверную инфраструктуру

В условиях растущего объема данных и тренда на виртуализацию, серверные микропроцессоры становятся критически важными для обеспечения производительности. Компании, такие как Intel и AMD, активно развивают свои решения, оптимизируя процессоры для задач AI/ML и больших данных. Например, процессоры Intel Xeon Scalable обеспечивают высокую пропускную способность и производительность для интенсивных вычислительных задач. В то же время процессоры AMD EPYC предлагают конкурентные TDP и высокое количество ядер, что делает их идеальными для многопоточных приложений.

Требования к инфраструктуре данных

С ростом мощности серверных микропроцессоров увеличивается и требование к инфраструктуре. Параметры, такие как PUE (Power Usage Effectiveness), становятся важными метриками, которые должны отслеживаться при проектировании и эксплуатации ЦОД. Современные серверы требуют высокой эффективности по энергопотреблению, что подчеркивает необходимость оптимизации систем охлаждения и электроснабжения.

Применение новых технологий

С развитием серверных технологий, таких как CXL и DDR5, компании могут значительно улучшить производительность. NVMe устройства хранения становятся стандартом, обеспечивая высокую скорость доступа к данным. Эти технологии позволяют реализовать более быстрые и масштабируемые инфраструктуры для выполнения задач, связанных с виртуализацией и облачными сервисами.

Выводы для системных администраторов

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

В сентябре 2026 года стоимость аренды графических процессоров Nvidia H100 снизилась до $3.38 за час. Диапазон цен варьируется от $1.49 до $13 в зависимости от провайдера и платформы аренды. Это изменение происходит на фоне роста спроса на GPU для задач AI и ML.

Рынок аренды облачных GPU

Аренда GPU стала важным сегментом рынка облачных услуг, особенно в свете растущего интереса к искусственному интеллекту (AI) и машинному обучению (ML). С появлением моделей, требующих значительных вычислительных ресурсов, таких как H100, организации могут быстро масштабироваться, не тратя средства на покупку оборудования. Это позволяет сократить первоначальные инвестиции.

Технические характеристики H100

Nvidia H100 предлагает производительность до 60 TFlops в FP16 и 120 TFlops в INT8, что делает его подходящим для интенсивных вычислительных задач. Чип основан на архитектуре Hopper, поддерживает NVLink и PCIe 5.0, что обеспечивает высокую пропускную способность обмена данными. H100 также оптимизирован для работы с моделями AI, что делает его особенно привлекательным для дата-центров, ориентированных на обработку больших объемов данных.

Применение в реальных дата-центрах

Снижение цен на аренду H100 чипов открывает возможности для дата-центров оптимизировать свои затраты. Например, использование облачных GPU для тренировки моделей AI может быть рациональнее, чем содержание собственного оборудования, особенно для нерегулярных или сезонных нагрузок. Кроме того, аренда предоставляет гибкость в выборе нужного количество вычислительных ресурсов в зависимости от текущих потребностей бизнеса.

Тенденции на рынке аренды GPU

Согласно прогнозам, рынок аренды GPU будет расти на 25% ежегодно в ближайшие годы, что подтверждается увеличением количества предложений от различных провайдеров. Сейчас доступно множество моделей, включая H100, A100 и другие, что позволяет организациям выбирать оптимальные решения для своих задач.

Заключение

Снижение цен на аренду H100 GPUs открывает новые горизонты для компаний, активно использующих AI и ML. Это позволяет оптимизировать затраты и адаптировать вычислительные мощности под изменяющиеся требования бизнеса без лишних капиталовложений. При этом важно учитывать не только стоимость, но и характеристики и производительность арендуемых ресурсов, чтобы обеспечить соответствие требованиям задач.

Безопасность серверов под угрозой: уязвимость в прошивке BMC, известная как "LegacyHive", была раскрыта после июльского обновления 2026 года. Эта уязвимость, отслеживаемая под идентификатором CVE-2026-XXXX, позволяет злоумышленникам выполнять произвольный код, что потенциально может привести к компрометации серверов в корпоративной среде.

Что такое BMC и почему это важно

Baseboard Management Controller (BMC) — это специализированный контроллер, который управляет системами управления серверами. BMC обеспечивает загрузку, мониторинг и управление сервером на уровне оборудования, даже когда система выключена. Уязвимости в прошивке BMC могут повлечь за собой серьезные последствия, так как злоумышленники могут получить доступ на уровне оборудования, что делает систему уязвимой для атак на сети и данные.

Риски для дата-центров и серверной инфраструктуры

Дата-центры, использующие серверы с уязвимыми BMC, подвергаются риску аппаратного взлома. Анализируя архитектуру таких систем, можно выделить следующие аспекты:

• Управление серверами: необходимость в защите BMC становится критически важной, так как доступ к этому компоненту может позволить злоумышленникам изменить конфигурации, удалить логи и даже установить вредоносный код.
• Мониторинг: системы мониторинга должны быть способны выявлять и оповещать о подозрительной активности, связанной с управлением на уровне BMC.
• Обновления прошивки: для минимизации рисков требуется регулярно обновлять прошивки BMC и следить за публикациями о новых уязвимостях.

Конкретные действия для защиты инфраструктуры

Для защиты серверной инфраструктуры от уязвимостей BMC, управляющие и системные администраторы должны внедрить следующие меры:

• Мониторинг безопасности: установка программного обеспечения для мониторинга состояния прошивки BMC и автоматического оповещения о новых уязвимостях.
• План обновления: разработка плана регулярного обновления прошивки для всех серверов, включая Dell PowerEdge и другие системы, использующие BMC.
• Изолированный доступ: ограничение доступа к интерфейсам управления BMC, включая использование VPN и двухфакторной аутентификации.

Заключение

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

Согласно последнему отчету, объем рынка устойчивых дата-центров вырастет с $111.77 миллиардов в 2026 году до $417.28 миллиардов к 2034 году, что соответствует среднегодовому темпу роста (CAGR) 17.9%. Это подтверждает растущий интерес к экологически чистым решениям в сфере серверной инфраструктуры.

Тенденции устойчивости в дата-центрах

Современные дата-центры стремятся к интеграции устойчивых технологий. Например, установка систем для снижения потребления электроэнергии, таких как системы с высоким PUE (Power Usage Effectiveness), становится стандартом. По данным Uptime Institute, высокая плотность размещения серверов и использование жидкостного охлаждения значительно уменьшают углеродный след.

Использование серверов с низким TDP

Серверы, такие как HPE ProLiant Gen10 Plus и Dell PowerEdge, предлагают низкие показатели TDP (Thermal Design Power), что позволяет сократить расходы на охлаждение и обеспечить более эффективное использование электроэнергии. Внедрение таких серверов в дата-центры позволяет снизить операционные расходы и затраты на электроэнергию.

Новые технологии и их влияние

Разработка технологий, таких как NVMe (Non-Volatile Memory Express), также влияет на устойчивость систем. NVMe-накопители обеспечивают значительно более высокую скорость доступа к данным по сравнению с традиционными SATA-дисками, что позволяет оптимизировать ресурсы и снизить потребление энергии на обработку данных.

Оптимизация серверного оборудования

При выборе серверного оборудования для нового дата-центра стоит обратить внимание на решения от Intel и AMD, предоставляющие процессоры с высокой производительностью и низким энергопотреблением, такие как Intel Xeon Scalable и AMD EPYC. Эти процессоры обеспечивают высокую производительность для задач ИИ и машинного обучения, а также для виртуализации, что позволяет эффективнее распределять рабочие нагрузки.

Значение устойчивой практики

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

Сертификация LEED

Согласно данным, на июнь 2026 года в мире насчитывается более 1,948 LEED-сертифицированных дата-центров, что подтверждает необходимость участия в программах сертификации. Упоминание о таких проектах в тендерах может сыграть ключевую роль в победе над конкурентами.

Технические выводы

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