Информируем вас о важных изменениях в правилах регистрации и обслуживания доменных имен в зонах .RU,.РФ и .SU.

С 1 сентября 2026 года вступают в силу новые требования законодательства Российской Федерации, согласно которым для управления доменами в указанных зонах администраторам необходимо пройти обязательную идентификацию через портал Госуслуги (ЕСИА) с использованием подтвержденной учетной записи. Данное требование распространяется на физических лиц, индивидуальных предпринимателей и юридические лица.

Что необходимо сделать?
Для физических лиц и индивидуальных предпринимателей (резидентов РФ)
Если вы уже являетесь нашим клиентом и владеете доменами в зонах .RU,.РФ или .SU, пройти идентификацию через Госуслуги (ЕСИА) можно уже сейчас.

Для этого необходимо:

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

Если ваши персональные данные изменились или требуют корректировки, перед прохождением идентификации также необходимо обратиться в отдел сопровождения клиентов для их актуализации.

Для юридических лиц (резидентов РФ)
Перед прохождением идентификации рекомендуем выполнить предварительную проверку:

• убедиться, что организация зарегистрирована в Госуслугах (ЕСИА);
• проверить, что сотрудник, ответственный за управление доменными именами, добавлен к учетной записи организации и обладает необходимыми полномочиями.

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

my.adminvps.ru/knowledgebase/562/

Карта подключений строится на основе данных о подключениях из карточек оборудования. Администратор может переключаться между разными слоями отображения. Например, проверить оборудование в определенном VLAN, просмотреть общую топологию связности коммутаторов или вывести только управляющие подключения BMC либо PDU.



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

Контроль сетевой связности и точное планирование
Главное преимущество новой функции — наглядное представление состояния всех сетевых соединений. Если раньше DCImanager позволял отслеживать здоровье серверов и температурные показатели стоек и ЦОД, то теперь администраторам доступна сводка по статусам линков.





При аварии больше не нужно вручную проверять каждый коммутатор и отдельный порт. Статусы подключений отображаются на схеме и выделяются цветом — проблемные участки определяются за секунды.

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

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



www.ispsystem.ru/docs/dcimanager-admin/moduli/modul-shema-seti

ТАГРАС — нефтесервисный холдинг со штаб-квартирой в Альметьевске (Республика Татарстан), который предоставляет услуги не только ведущим предприятиям нефтегазовой отрасли, но и представителям смежных сфер.

ТАГРАС работает на рынке с 2006 года и на данный момент обслуживает более 1500 заказчиков. В структуру холдинга входит более 50 предприятий, разделенных на восемь дивизионов — каждый закрывает свою отрасль для диверсификации рисков:

• Система-Сервис — производство, прокат и ремонт нефтепогружного оборудования;
• ТАГРАС-РС — внутрискважинные работы по ремонту, ГРП и ПНП;
• ТаграС-ЭнергоСервис — строительные и ремонтные работы в энергетическом комплексе и промышленном строительстве;
• ТМС групп — машиностроение и сервис нефтепромыслового и бурового оборудования;
• ТаграС-ТрансСервис — грузопассажирские перевозки и логистика;
• Геофизический дивизион — исследования и сейсморазведка;
• БС-Платформа — информационная безопасность и цифровая трансформация предприятий, сервисная поддержка систем;
• ТАТНЕФТЕДОР — строительство и обслуживание автомобильных дорог.

В общей сложности в компаниях холдинга работает порядка 15 000 человек.

Исходные данные
С 2019 года ТАГРАС находится на пути цифровой трансформации. После ревизии бизнес-процессов в 2020–2025 годах проходила информатизация всех дивизионов холдинга. Параллельно с 2022 года для минимизации санкционных рисков началась замена импортного ПО на отечественные аналоги в соответствии с подпрограммой «Цифровой суверенитет» TAGRAS-Digital.

Поставленную задачу решает ИТ-дивизион компании — БС-Платформа. В общей сложности этот дивизион обслуживает 7000 пользователей и более 100 различных информационных систем в ИТ-инфраструктуре компаний холдинга.

Цели и задачи
В рамках программы «Цифровой суверенитет» необходимо было:

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

Решение, которое используется в проекте
Для решения поставленных задач в 2023 году специалисты БС-Платформы взяли курс на отказ от зарубежных облаков и перенос сервисов холдинга ТАГРАС в частный программно-аппаратный комплекс. Для этого на базе платформы виртуализации VMmanager был создан ПАК «Частное облако», который объединяет ресурсы четырех дивизионов: Таграс-РС, БС-Платформа, Таграс-ТрансСервис и Татнефтедор.

VMmanager был выбран по итогам строгого сравнительного тестирования близкого по функционалу конкурирующего отечественного решения по более чем 70 параметрам и функциям.

На фоне конкурента продукт VMmanager выделялся важными для внедрения преимуществами:

• Простая и быстрая установка через скрипт, не требующая глубоких знаний Linux;
• Широкий спектр способов развертывания виртуальных машин;
• Доступ к обновлениям без дополнительной авторизации, менеджер установки с графическим интерфейсом (все в рамках лицензии), а также возможность установки обновлений без остановки трафика, то есть вне сервисных окон;
• Интеграция с биллингом, которая позволяет легко заказывать дополнительные услуги или отказываться от неиспользуемых.

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

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

Для развертывания использовалась v2025.08.2–1 платформы управления инфраструктурой, на которой была запущена 141 виртуальная машина, 64 из них — под управлением Astra Linux 1.7.5 и 1.8.1. В качестве СУБД для поддержки продуктовых сред 1С задействовали Тантор и PostgreSQL.

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

Результаты
После внедрения ПАК «Частное облако» обеспечивает поддержку корпоративной почты на 4500 пользователей, электронного документооборота всех дивизионов холдинга, а также продуктового контура 1С четырех дивизионов.

В боевых условиях заказчик провел сравнительное нагрузочное тестирование производительности двух платформ. Результаты показали превосходство VMmanager.

Ключевые результаты ПМИ:

• VMmanager набрал максимальные баллы в 90% категорий.
• Преимущество в важных аспектах: документация, простота установки, интеграция с биллингом.
• Экономия времени: установка и администрирование проще на 40–50%.

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

Внедрение отечественного решения повысило безопасность данных. Теперь она соответствует ведущим отраслевым стандартам и требованиям регулятора.

Ускорили развертывание новых сервисов: скорость развертывания сократилась на 40%, а в целом ТСО — на 20–30%.

Мнение заказчика
В рамках программы цифрового суверенитета мы провели глубокую ревизию инфраструктуры и приняли решение организовать ПАК «Частное облако» на отечественном продукте виртуализации VMmanager.

Выбор был непростым: мы сравнили более 70 параметров и VMmanager показал себя лучше по ключевым критериям: простота внедрения, гибкость обновлений и возможность бесшовной интеграции с нашими процессами.

Сегодня уверенно смотрим в будущее: платформа дает нам фундамент для масштабирования в любых направлениях — от импортозамещения почтовой системы до реализации новых амбициозных задач.

Дмитрий Александрович Нефёдов
первый заместитель директора по информационным технологиям, главный инженер ООО «Про-Ресурс»

«КрасАвиа» — российская региональная авиакомпания. Базируется в Красноярском крае, осуществляет регулярные перевозки как внутри края, так и в соседние регионы, а также выполняет международные рейсы в Монголию. В общей сложности более 30 направлений на регулярной основе, включая районы Крайнего Севера.
www.krasavia.ru

Помимо пассажирских перевозок «КрасАвиа» доставляет почту, продовольствие, лекарства и другие жизненно необходимые грузы в районы Крайнего Севера, а также выполняет санитарные рейсы для оказания экстренной медицинской помощи, в том числе в труднодоступных территориях; осуществляет полеты в рамках деятельности лесопожарного центра; участвует в поисково‑спасательных операциях.

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

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

«КрасАвиа» приняла решение перейти на отечественную платформу виртуализации.

Задачи проекта
В авиационной отрасли к ИТ-инфраструктуре предъявляются повышенные требования по надежности и безопасности: даже кратковременные сбои могут влиять на критичные операционные процессы.

«КрасАвиа» требовалось развернуть стабильную и производительную платформу виртуализации с учетом имеющихся ИТ-ресурсов.

Задачи заказчика на старте проекта:

• Импортозамещение
• Заменить зарубежную платформу виртуализации отечественным решением без потери функциональности.
• Стабильность
• Обеспечить надежность и производительность инфраструктуры, а также повысить отказоустойчивость критически важных сервисов.
• Масштабируемость
• Создать масштабируемую среду для дальнейшего развития ИТ-инфраструктуры и роста авиакомпании.
• Гибкость управления
• Получить единую платформу для централизованного управления и настройки виртуальной инфраструктуры.

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

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

VMmanager — инструмент для создания отказоустойчивой виртуальной среды, а также для централизованного управления аппаратной и контейнерной виртуализацией.
Дополнительные критерии выбора VMmanager:

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

Этапы внедрения
Проект начался с развертывания тестового демостенда, который специалисты «КрасАвиа» и ISPsystem реализовали совместно.

На тестовой площадке команда проверила основные возможности VMmanager, оценила работу платформы под нагрузкой и протестировала сценарии эксплуатации, необходимые для внутренних сервисов компании.

Пилотирование проекта продолжалось шесть месяцев. За это время платформа VMmanager показала стабильную работу и полностью подтвердила соответствие требованиям заказчика. В результате тестовая среда была переведена в промышленную эксплуатацию.

Результаты проекта
Сегодня VMmanager успешно работает в инфраструктуре заказчика уже более восьми месяцев.

Использование отечественного решения позволило снизить зависимость от зарубежных поставщиков и сохранить контроль над развитием и сопровождением критически важных информационных систем.

Благодаря переходу на платформу VMmanager авиакомпании удалось сохранить высокий уровень надежности ИТ-сервисов и обеспечить устойчивую работу инфраструктуры для ежедневной деятельности предприятия.

Мнение заказчика
Отмечу высокую производительность платформы, удобную консоль управления и быструю работу консоли виртуальных машин. Виртуальные машины работают стабильно и быстро. Мы не используем какие‑то специфические функции: VMmanager для нас прежде всего надежная платформа виртуализации.
Сергей Алексеевич Баёв
Начальник отдела по инфраструктуре и телекоммуникационным системам

alefbank.ru

АО АКБ «Алеф-Банк» — универсальный банк, предоставляющий как традиционные банковские продукты, так и услуги с использованием цифровизации. Это финансовая организация с развитой ИТ-инфраструктурой и собственным ИТ-департаментом.

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

Инфраструктура компании размещена в двух территориально распределённых ЦОДах. Такая архитектура обеспечивает заказчику отказоустойчивость и возможность переключения между площадками в случае выхода из строя одной из них.

Контекст и исходная инфраструктура
До внедрения VMmanager компания использовала зарубежное ПО в качестве основной платформы виртуализации — и сейчас продолжает частично эксплуатировать продукт. Также в рамках импортозамещения на протяжении двух лет применялось решение на базе платформы виртуализации с открытым исходным кодом.

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

Задачи проекта
В рамках проекта перед командой банка стояли задачи, связанные с поддержанием и миграцией инфраструктуры на новое решение:

• Импортозамещение. Поиск отечественного продукта в условиях новых требований и ограничений.
• Оптимизация затрат. Поиск оптимального баланса между стоимостью владения новой платформой и её возможностями.
• Безопасность. Использование решений, подходящих для работы в регулируемой среде, включая наличие сертификата ФСТЭК.
• Развитие виртуальной инфраструктуры. Формирование устойчивой среды для запуска новых проектов банка.

Почему выбрали VMmanager
При выборе платформы команда ориентировалась на практические сценарии эксплуатации и модели лицензирования.

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

• Экономическая эффективность
• VMmanager обеспечил более предсказуемую стоимость владения по сравнению с альтернативами при сопоставимом наборе функций и предоставил гибкие варианты лицензирования.
• Стабильность работы
• В процессе эксплуатации команда отметила более стабильную работу системы — в процессе миграции на VMmanager не возникало сетевых проблем, что повысило стабильность операций.
• Наличие сертификата ФСТЭК
• Сертификат ФСТЭК стал одним из ключевых факторов при выборе решения для использования в банковской инфраструктуре.

Реализация проекта и планы
ИТ-среда банка — это критичная система, где любые изменения инфраструктуры напрямую влияют на доступность сервисов и бизнес-процессы. Поэтому переход на VMmanager выполняется поэтапно и вдумчиво: с предварительным тестированием и последовательным переносом сервисов без остановки ключевых систем.

Удобный интерфейс платформы, её готовность к быстрому старту и опыт сотрудников ИТ-подразделения банка позволяют проводить миграцию самостоятельно своими силами. Сейчас команда банка готовит инфраструктуру к запуску цифрового рубля, используя VMmanager в том числе для развёртывания тестовых контуров в виртуальной среде.

Проект находится в активной фазе, и заказчик уже отмечает ряд эффектов:

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

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

В планах заказчика — поэтапное расширение использования VMmanager и увеличение количества лицензий по мере роста инфраструктуры и задач проекта.

Мнение заказчика
Внедрение VMmanager стало для нас важным шагом в развитии цифровой инфраструктуры и импортозамещении в линейке программных продуктов банка. У нас появилась возможность удобно управлять виртуальными ресурсами и оперативно администрировать банковские информационные системы. Но главное мы получили надёжную, безопасную и аттестованную среду виртуализации, которая соответствует требованиям законодательства в сфере информационной безопасности.
Павел Дулле
Директор департамента информационных технологий АО АКБ «Алеф-Банк»

www.ispsystem.ru/vmmanager

Прямо сейчас в наличии выгодные конфигурации серверов на 16 ядерном процессоре AMD Ryzen 7 7700 (до 5.3 GHz ) и 64 GB в Европе (Германия, Финляндия).

Процессор AMD Ryzen 7 7700 оснащен встроенной графикой AMD Radeon Graphics. Она базируется на архитектуре RDNA 2 и имеет 2 вычислительных блока (128 ядер) с частотой до 2200 МГц.

• Устанавливаем Windows Server 2019,2022,2025, Windows 10 Pro, Linux
• Панель управления сервером
• Безлимитный канал 1 Gbps
• Защита от DDoS

Что может встроенная графика Ryzen 7 7700

• Вывод изображения / диагностика
• Для установки ОС, rescue, KVM/IPMI, базовой графической консоли.
• RDP / VNC / лёгкий GUI
• Windows/Linux с графическим интерфейсом, браузер, офисные задачи, панели управления.
• Видео-сервер
• Plex/Jellyfin/FFmpeg с аппаратным ускорением видео: H.264/H.265 encode/decode, AV1 decode — при нормальных драйверах и поддержке софта.
• Лёгкая 2D/3D-графика
• Простые приложения, браузерная графика, несложные визуальные задачи.

Конфигурации и аренда сервера abcd.host/hetzner-dedicated-servers
По вопросам пишите в личный кабинет my.abcd.host или Telegram: @ABCDSupportBot

Спасибо, что остаетесь с нами!
ABCD.HOST

Заказывать исключительно в биллинге cp.aofy.ru/billing.php
такой конфиг используется только для этого проекта

Рассказываем что произошло в NL/DE или «приключение на 20 минут, вошли и вышли».

• 2 июня: с разницей в 30 минут отключаются локации. Никакой ясности нет, явно что-то не так;
• К вечеру получаем сообщение, что датацентр nLighten по собственной инициативе обесточил всё оборудование и заблокировал доступ к серверным шкафам. Деталей очень мало;
• Деталей по-прежнему очень мало. Спустя несколько дней получаем сообщение, что процесс сдвинулся с мертвой точки, планируют назначение даты выгрузки оборудования;
• С 15 июня происходит выгрузка, миграция в другой датацентр;
• Сотрудники нового поставщика, к которому мы перевезли оборудование, не были готовы к проведению большого количества работ, что вызвало длительную задержку. В связи с этим было принято решение экстренно ехать сначала во Франкфурт-на-Майне, а затем и в Нидерланды для завершения работ своими силами.

20ого числа прибыли в Нидерланды, забрали нужные компоненты со склада и прямой дорогой отправились во Франкфурт. Дорога заняла примерно 5 часов на машине с минимальными остановками. В ночь с 20 на 21 июня запустили все сервисы в Германии как и обещали.

• Обратный маршрут был в Нидерланды. Согласовали пропуск в датацентр, подготовили все необходимое и также оперативно завершили работы с выявлением сломавшихся компонентов из-за резкого выключения питания и последующим запуском всех вычислительных узлов.
• Более 10 часов перелетов, 1500 километров дороги для финального решения всего инцидента.

Что стало причиной: доподлинно неизвестно, предварительно это беспрецедентное решение руководства сети датацентров nLighten на фоне заявлений журналистов про компанию Mirhosting, которая занимается сопровождением IT-инфраструктуры. К слову, Mirhosting на всем протяжении безупречно выполняли поставленные задачи и отличались высокими компетенциями. Сложно назвать произошедшее чем-то кроме поспешно сделанных решений, которые повлекли за собой последствия.

• Потери данных? Все данные за исключением одного гипервизора в полной сохранности. По нему все ещё ведется работа.
• Компенсации: начислено 22 дня + 1 полный месяц для всех услуг Германии и 25 дней + 1 полный месяц для всех услуг в Нидерландах.
• Выводы из всей истории: беспрецедентная непростая ситуация, по которой сложно было принять правильные решения ввиду абсурдности и очень малого количества деталей произошедшего.

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

hip.hosting

Для информации. Ключевым направлением проекта все больше становиться виртуализация и облака. Сервисы серии «виртуальный хостинг» будут пересмотрены и тарифы скорректированы в соответствии с рынком с 1.08.2026. Рекомендуем всем максимально переносить проекты в виртуальные сервера VDS. Это безопаснее, надежнее, гибче и удобнее в администрировании.

ihor.online/vds

Вчера (2 июля) один из серверов виртуализации в ЦОД Алматы перестал отвечать, так как произошёл аппаратный отказ процессора AMD EPYC 9655.

Почему не сразу удалось выявить причину проблемы, как это связано с параллельными событиями в локации, как было выполнено восстановление — в нашем разборе.

Инцидент
Необходимо отметить, что сетевые события, происходившие в тот же период, не были прямой причиной аварии сервера. Ни плановые работы на сети оператора, объявленные до инцидента с сервером, ни внеплановые работы на канале, начавшиеся позднее, не были связаны с аппаратным отказом узла виртуализации. Эти события совпали по времени с восстановительными работами и повлияли на сроки миграции виртуальных машин, но не являлись причиной отказа сервера.

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

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

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

Несмотря на сочетание нескольких факторов, виртуальные машины были перенесены на соседние узлы без потери клиентских данных.

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

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

После стабилизации сервера и восстановления сетевой связности виртуальные машины были перенесены на соседние узлы кластера.

Потери клиентских данных не зафиксировано.

Первопричина
Первопричиной инцидента стал аппаратный отказ процессора AMD EPYC 9655.

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

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

Почему первоначально возникла версия о проблеме с дисками
На первом этапе была выдвинута гипотеза о неисправности дисковой подсистемы. Для проверки этой версии диски аварийного узла были перенесены в другой сервер.

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

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

Инженер полностью восстановил загрузку: заново настроил GRUB2 и вручную создал EFI-записи в NVRAM материнской платы. После этого узел начал загружать основную операционную систему, однако под нагрузкой виртуализации снова воспроизводилось зависание ОС.

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

Дополнительное диагностическое наблюдение
Во время диагностики был выполнен обратный тест: диски от другого сервера были установлены в неисправную платформу.

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

Поэтому в таком режиме деградация процессора не проявлялась.

Рассмотренные варианты восстановления
Рассматривались два основных сценария восстановления.

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

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

Отдельно рассматривался вариант физического демонтажа неисправного процессора. Однако он также не являлся оптимальным: вместе с процессором сервер потерял бы доступ к части оперативной памяти и части NVMe-накопителей, так как они подключены через соответствующие PCI Express-линии. Это могло дополнительно осложнить восстановление и снизить вероятность корректного доступа ко всей конфигурации узла.

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

Стабилизация узла
После восстановления GRUB2 и EFI-записей сервер начал загружать основную операционную систему, но зависал при появлении нагрузки от виртуализации.

Для снижения нагрузки все виртуальные машины были остановлены. Также инженер принудительно завершал процессы, которые автоматически запускались и могли снова привести к зависанию ОС.

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

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

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

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


После восстановления интернет-связности миграция была продолжена.

Итог восстановления
После восстановления сети все виртуальные машины и данные были перенесены на соседние узлы кластера.

Потери клиентских данных не произошло.

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

Выводы
Инцидент был вызван нестандартным аппаратным отказом процессора AMD EPYC 9655. Отказ не проявлялся в минимальном rescue-окружении и становился заметен только после запуска полноценной операционной системы под нагрузкой виртуализации.

Диагностику осложнили следующие факторы:

• Повреждение загрузочного раздела RAID1 и неработоспособность GRUB2.
• Необходимость вручную восстанавливать GRUB2 и EFI-записи в NVRAM материнской платы.
• Длительная самодиагностика серверной платформы после каждого зависания и перезагрузки.
• Неочевидный характер отказа процессора, который проявлялся только под нагрузкой KVM.
• Независимое сетевое событие, вызванное незаявленными работами оператора RETN.

Какие меры мы уже предприняли и что ещё планируем сделать:

• Вся хронология событий и симптомы проблемы внесены в нашу внутреннюю базу знаний, чтобы в случае возникновения аналогичной ситуации время на устранение значительно сократилось.
• В ближайшее время мы закончим организацию второго канала с магистральным провайдером Транстелеком Казахстан, чтобы не зависеть только от RETN.
• Возместим время простоя вашего VPS в локации Казахстан за 2 июля. Для этого, пожалуйста, напишите запрос в техподдержку.