Вчера (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 июля. Для этого, пожалуйста, напишите запрос в техподдержку.

К облачным серверам с GPU в дата-центре Алматы скоро добавится новая видеокарта — NVIDIA RTX PRO 6000. Карта рассчитана на работу с крупными моделями и ресурсоемкими нагрузками.
Для каких задач подойдет:

• Обучение и дообучение моделей на больших датасетах.
• Инференс крупных LLM — 96 ГБ видеопамяти позволяют размещать масштабные модели на одной карте.
• HPC и научные вычисления, симуляции, аналитика больших данных.
• Тяжелая медиа-обработка и 3D-рендеринг.

Конфигурацию можно гибко менять и добавлять мощности в панели управления по мере роста проекта. Данные обрабатываются локально в дата-центре в Алматы в соответствии с требованиями законодательства Республики Казахстан. Оплата в тенге по модели pay-as-you-go.

pro.servercore.com/almaty_offer_gpu

Теперь можно заказать VDS с локацией в Алматы — в дата-центре Ahost.kz

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

На текущий момент все VDS в ДЦ Алматы открываются на базе процессоров Intel Xeon Scalable до 4.1 ГГц.

Сейчас можно заказать тарифы с NVMe-накопителями: VDS в готовых конфигурациях и гибкий VDS Форсаж. Чтобы заказать сервер с локацией «Алматы», просто выберите её при настройке параметров VDS на сайте или включите нужный фильтр в Личном кабинете.
firstvds.ru/products/vds_vps_hosting
firstvds.ru/products/vds_vps_forcing

Для VDS с локацией в Алматы мы предоставляем безлимитный канал 100 Мбит/с.

Стоимость серверов, размещенных в Ahost.kz, такая же, как и в других наших дата-центрах.

Привет!

Обещали – делаем.

Сегодня мы рады поделиться с вами новостью – теперь в Бегете вы можете заказать VPS с локацией в Казахстане.

Расскажем о серверах немного подробнее.

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

Стоимость аренды серверов в Казахстане не отличается от стоимости аренды в РФ.

Обратите внимание!
Минимальная конфигурация сервера, доступная для заказа в Казахстане, – 2 CPU, 2Гб RAM и 30 Гб NVMe.

При этом все доступные для серверов в России возможности актуальны и для Казахстана – к каждому серверу предоставляется выделенный IP-адрес, бесплатные автоматические бэкапы данных, DNS-хостинг, приватные сети и удобный мониторинг состояния серверов.
Также доступен облачный MySQL и многое другое.

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

Кстати, вслед за Казахстаном мы планируем добавить возможность аренды серверов в Европе, так что следите за нашими анонсами – впереди еще много всего интересного.

Если у вас возникли какие-либо вопросы, свяжитесь с нами удобным для вас способом – и мы обязательно ответим, а если вы захотите обсудить эту новость или наш хостинг с коллегами по цеху и сотрудниками Бегета, ждем вас в нашем сообществе в Telegram t.me/beget_chat

Привет, друзья!
Горы, природа и невероятная национальная кухня — вот ради чего хочется побывать в Казахстане. Теперь это можно сделать с is*hosting! Осваивайте новый рынок с помощью новой локации VPS в Алматы.

Арендовать VPS на базе серверов DELL R630 на SSD дисках можно в современном дата-центре Sairam, который расположен в Алматы, крупнейшем мегаполисе Казахстана. Более 20 лет на рынке и высокие технические показатели надежности — все это про новый дата-центр.

Sairam единственный дата-центр в Алматы который имеет сертификаты TIER III Design и TIER III Facility от компании Uptime Institute, а также соответствует следующим стандартам качества СТ РК 9001-2016, СТ РК ISO 14001-2016, СТ РК ISO 45001-2018, СТ РК ISO 20000-1-2016 и СТ РК 27001-2015. Дата-центр имеет 2 независимых ввода электроэнергии, а IT-нагрузка зарезервирована по схеме N2. Специалисты в Казахстане также позаботились о качественной системе охлаждения (тип резервирования N+1) и автоматической системе обнаружения дыма и пожаротушения во всех помещениях.

На объекте 24/7/365 находятся дежурная смена инженеров и служба охраны ЦОД. Критические показатели всех систем выводятся в единую систему мониторинга, которая также осуществляется круглосуточно.

С is*hosting и новым дата-центром в Казахстане Sairam ваши проекты под надежной защитой. Открывайте новые горизонты — VPS в Казахстане уже доступен в is*hosting!
И как всегда, мы помним о нашей традиции и объявляем очередные бонусы в честь открытия новой локации.

Получите 3 дополнительных месяца в подарок после оплаты, воспользовавшись кодом KZNOW, или 6 бонусных месяцев при оплате за год!
Код будет действовать до конца мая.
cp.inferno.name/cart.php?gid=74