Лига Сисадминов

Самое в происходящем удивительное то, что одни и те же люди:
Сначала рассказывают, что «есть вот другое, не такое, идите - учите матчасть». Не уточняя, какую матчасть, и что именно они имели в виду. 
Потом те же люди удивляются, что, если кадры не доучивать, то они и не учатся, вот же какая досада.

Отдельно надо заметить явление «отрыв технических абстрактных знаний от их применимости». Ситуацию легко продемонстрировать следующим образом:
Предполагается заучить, что обычно (но далеко не всегда) в серверном оборудовании по 2,4,6 блоков питания, и они поддерживают (обычно) горячую замену. Окей, заучили, и что из этого?
Окей, теперь сервер может работать на одном блоке питания.
И что это дает сервису, развернутому на нем ? Например, можно ли вместо 2 серверов «задорого» купить три системных блока «значительно дешевле» и развернуть три экземпляра сервисов?
Что это дает бизнесу, то есть, сколько прибыли получит (или не потеряет) бизнес от отсутствия ночных простоев, когда в офисе никого? И что мешает бизнесу пригнать в офис эникея к 7 утра, чтобы к 9 все работало?
Какое преимущество, в рублях в год, для бизнеса от того, что сервером можно управлять удаленно, через IPMI , если есть IP KVM, или можно эникея загнать в серверную с клавиатурой?

Отдельно надо отметить разрыв между наличием знаний, с пользой от применения этих знаний. Или даже отсутствия знаний пополам с пафосом.
Пример. Несколько лет назад коллеги проводили аудит одной организации. Примерно на 10% серверов когда-то давно забыли выключить разного рода «энергосбережение» и никак не отслеживали параметры типа CPU wait time. Итог – оборудование стоит «как бы нагруженное», но фактически «многое тормозит». Зато с знанием теории у отдела все хорошо, знают про то, что есть горячая замена блоков питания, и даже их меняли! Только железа в 1.5 раза больше купили. И это по прежнему было суммарно дешевле найма "шибко умных".

Все вышесказанное усугублялось отвратительной организацией.
В том числе поэтому, «массово знать что-то не нужно, и экспертиза не монетизируется» , РУ сегмент в части «собственных частных блогов» почти вымер. Я когда-то считал, что в 2010 году было 100 активных блогов про ИТ «на русском», в 2020 – хорошо, если 10.
Сейчас сходу не назову ни одного живого персонального блога. Не уверен, что есть «живые» подкасты, 5 лет назад были.  
Кто-то завел телеграм канал «на себя и того парня». С 10-20 активными подписчиками.
Кто-то просто перестал писать на русском.
По каким-то фундаментальным вещам читать просто нечего.
Есть корпоративные блоги, теперь переезжающие с сайта под цензурой Минцифры, и набитого ботами, на хотя бы Пикабу. Почему? На Пикабу охват больше, и живой аудитории около 15-20 тысяч человек. На Вестнике Минцифры (ранее – Хабр) живых (активно пишущих) участников осталось, может 50, живых комментаторов 200-300. Не «зарегистрированных, ничего не писавших десять лет, и вдруг вторым комментарием после 10 лет отсутствия, разоблачающие русофобское отношение к аналоговнетной Пиастре», а живых.

Поэтому авторы, пишущие «вкатываться стало трудно» не так уж неправы. Вкатываться стало трудно, в том числе, потому, что сообщества массово превратились  из «токсичных, но тему знающих» в «токсичных, и не обладающих актуальными, применимыми и оплачиваемыми знаниями».
В условном 2000 году давали направление на книгу в библиотеке.
В условном 2010 году давали направление на курс онлайн.
В условном 2020 году можно было найти какие-то базовые вещи на ютубе.
В 2026 году найти что-то актуальное в РУ сегменте почти невозможно. Иногда есть кривые переводы, которые не всегда понятны в отрыве от общего контекста.
Но, наметилась хорошая тенденция – корпоративные блоги вернулись на корп сайты и переходят на Пикабу. Видимо, размещаться на Вестнике Минцифры стало дорого. Например, Солар ИБ ведет свой интересный блог.

Заключение

Системное администрирование можно делить по грейдам:
Техник. Знает где в сервере блок питания, и то, что блок питания на горячую менять можно, а память, скорее всего, на горячую менять нельзя. И следит за авариями в мониторинге.
Системный администратор поглядывает не столько за авариями, сколько за трендами – что будет через квартал, полгода. Прикидывает, не пора ли начинать замену оборудования из-за роста аварий и роста нагрузки в ближайшие год – два. И смотрит в бизнес требования – что нужно бизнесу, с какими SLA, во сколько это обойдется.
Между этими двумя позициями значимый разрыв, в том числе в деньгах, и задачах. И огромный разрыв в опыте.
Уровнем выше идет уже управление бизнес подразделением – метрики задач, нагрузка на людей, ФОТ, TCO, ROI, и так далее.

Часть проблемы «ИТ в РФ» заключается в том, что техника слишком часто рассматривается отдельно, бизнес задачи отдельно, и ветки управления сходятся слишком высоко. Попытки создания матричных структур, где сотрудником командуют все, кому не лень, ведут к хаосу и трате времени на отписки «не делал одно, потому что был занят другим».

В мире с такими разделениями ситуация ничуть не лучше. Из того, что я вижу, мировые практики приезжают в РФ примерно через 3-5 лет после начала их публичного обсуждения «в мире».
Как году в 2022-2023 все стали говорить про «ИИ», хотя даже в РФ промышленное зрение и распознавание текста было года с 2012-2014. В мире применение ИИ для языка началось года с 2015, decoder-only GPT-1 – 2018 год.

На мой взгляд, текущий мировой тренд уже никак не связан с железом как таковым:
- ИИ отлично делает свою работу, но пишет слишком криво, поэтому к нему нужен и джун, чтобы джун проверял то, что сделала ИИ,
- ИИ это дорого, поэтому с ним растет продуктивность, но растет и выгорание, и стоимость, и сложность сопровождения проекта, потому что код становится не человеко читаем, сложен (дорог) в поддержке и развитии.
- Не годится для развития энтерпрайз систем, где цена ошибки и простоя высока.

Возвращаясь к теме «вката в ИТ через сопровождение техники».

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

Сложилась и закрепилась любопытная ситуация.
В 2015 году бизнес был готов закрывать свои потребности в ИТ «только железом». Железо стоило дешево, его было легко купить, легко сопровождать дешевыми мало и совсем необученными кадрами.
Часть кадров выросла до сеньоров, часть ушла в ИТ менеджмент, часть ушла в девопс и разработку.
В 2026 году в РФ закупка стала «дорогой» (в мире тоже, оперативная память вздорожала).
Бизнес захотел оптимизировать «железо», но оптимизировать в закупках 2015-2020 года уже нечего, и бизнес не готов платить людям с соответствующим уровнем, даже за аудит. Потому что бизнесу не нужен «аудит», они и так знают, что «все старое». Бизнесу нужно чудо, чтобы 10 летней давности железо работало как последний топовый домашний интел\амд, и , желательно, сразу с внедрением ИИ.

Но обучать сотрудников массовый бизнес не готов, и платить за переход «уже обученного» не готов.
Ныть можно. Например, на РБК вышла статья

«Дефицита IT-кадров нет. Есть игра, в которую никто не хочет играть честно», которую быстро переименовали в «IT‑кадры есть, но рынок труда в тупике: в чем подвох».
Пока искал, вдруг ее кто-то выложил (она за платной подпиской) выловил статью «Рынок IT сломался? Или почему сегодня недостаточно просто быть хорошим разработчиком.»

И, кратко еще раз

Вкатываться в сопровождение и работу только с железом в РФ (и вне РФ) сейчас бесперспективно. Знать нужно много, но перспективы никакие, и денег платить не готовы.

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

Читать первые 4 пункта именно в таком порядке, по мере выхода книг.
Остальные читать в любом порядке.

«Мифический человеко-месяц, или Как создаются программные системы» (англ. The Mythical Man-Month: Essays on Software Engineering)

https://ru.wikipedia.org/wiki/Мифический_человеко-месяц

Deadline. Роман об управлении проектами

Проект Феникс. Роман о том как DEVOPS меняет бизнес к лучшему

Рождение советской ПРО. Последний советский суперкомпьютер

https://topwar.ru/192565-rozhdenie-sovetskoj-pro-poslednij-sovetskij-superkompjuter.html

Весь цикл «Рождение советской ПРО»: https://topwar.ru/user/Sperry/

Можно читать даже комментарии, где пишут, что автор ничего не понимает, либерал и вредитель.

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

Читать в любом порядке

Intel Ultra Path Interconnect

https://en.wikipedia.org/wiki/Intel_Ultra_Path_Interconnect

AMD Infinity Fabric

https://www.amd.com/en/blogs/2025/engineering-the-future-of-ai.html

ECC memory

https://en.wikipedia.org/wiki/ECC_memory

Intelligent Platform Management Interface

https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface

Non-uniform memory access (NUMA)

https://en.wikipedia.org/wiki/Non-uniform_memory_access

NUMA Deep Dive Part 4: Local Memory Optimization

https://frankdenneman.ai/2016-07-13-numa-deep-dive-4-local-memory-optimization/

Ресурсы ниже могут быть не доступны из РФ, за что вы знаете, кому сказать спасибо

xfusion Hands-on Experience

https://support.xfusion.com/server-simulators/index_en.html

xfusion FusionServer 2288H V5 3D model

https://support.xfusion.com/server-3d/res/server/2288hv5/ind...

Huawei

The 3D Experience Center provides new hardware simulation for interactive experience, which supports all-round demonstration of hardware components and manual disassembly, providing details on the internal structure. You can access it as follows:

Visit Huawei Data Storage Infocenter (https://info.support.huawei.com/storage/#/home).

In the 3D Experience Center area on the home page, click Explore hardware.

Select OceanProtect Backup Storage.

Select the desired product model.

Select the component you want to view.

(Video) FusionServer Pro 2288H V5 Server Hardware Installation and Parts Replacement 11

https://support.huawei.com/enterprise/en/doc/EDOC1100002169

Storage Spaces with parity, very slow writes. Solved!

https://wasteofserver.com/storage-spaces-with-parity-very-slow-writes-solved/

NVME Raid – We Need To Go Deeper, или что там на глубине. GPU over NVME, с водяным охлаждением

NVME Raid – We Need To Go Deeper, или что там на глубине. GPU over NVME, с водяным охлаждением

Manage Hyper-V hypervisor scheduler types

https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-hyper-v-scheduler-types

PPS.
Такая проблема, как отсутствие технической возможности фильтрации контингента, существует и на Пикабу. Максимально можно забанить 200 человек, автобана нет. Поэтому в комментариях можно наблюдать шоу «я сервер на картинке видел, поэтому считаю, что статья плохая».
Необходимый уровень бана при текущей оценке Пикабу в 20.000 активных участников – 10% токсиков, что соответствует нормальному распределению 10-80-10. То есть, примерно 2000 позиций в банлисте. Не 200.

1. Лимит контейнера и cgroup v2: что происходит при memcg OOM

Самый частый сценарий: приложение внутри контейнера выходит за свой limits.memory.

В Kubernetes memory limit контейнера в итоге превращается в ограничение на уровне cgroup. В cgroup v2 жёсткий лимит задаётся через memory.max. Если потребление памяти в этой cgroup доходит до лимита и ядро не может освободить достаточно памяти, возникает memcg OOM.

На ALT Linux 11 используется cgroup v2 - как и в большинстве современных дистрибутивов Linux по умолчанию. Для Kubernetes это важный нюанс: в типовой конфигурации kubelet на cgroup v2 для container cgroup выставляется memory.oom.group=1.

Проверить это можно прям на ноде:

cat /sys/fs/cgroup/.../memory.oom.group

Если там 1, то при OOM внутри конкретного контейнера ядро рассматривает процессы этого контейнера как единую группу и убивает их вместе. Это отличается от привычного поведения cgroup v1, где мог умереть один worker-процесс, а основной процесс контейнера продолжал жить, оставляя приложение в полуживом состоянии.

Но тут есть важная оговорка: для multi-container pod это не обязательно означает мгновенную смерть всех контейнеров pod’а.

Если OOM произошёл на уровне cgroup конкретного контейнера, будет убит именно этот контейнер. Если же давление по памяти возникло выше по иерархии cgroup или дошло до node/global OOM, поведение уже зависит от лимитов, QoS, oom_score_adj и того, кого ядро выберет жертвой.

Для диагностики полезно смотреть не только memory.max, но и memory.events:

cat /sys/fs/cgroup/.../memory.max cat /sys/fs/cgroup/.../memory.events

В memory.events можно увидеть счётчики вроде:

high max oom oom_kill oom_group_kill

Они помогают понять, что именно произошло: контейнер приблизился к лимиту, упёрся в memory.max, словил OOM или был убит группой.

2. А что насчёт memory.high?

В cgroup v2 есть не только memory.max, но и memory.high.

memory.max - это жёсткая граница. Если контейнер дошёл до неё и память нельзя освободить, будет OOM.

memory.high - это мягкий порог. При его превышении ядро начинает троттлить процессы в cgroup и заставляет их проходить через reclaim, то есть пытаться освобождать память до того, как ситуация дойдёт до убийства.

Звучит конечно красиво, но в Kubernetes есть нюанс: сам факт использования cgroup v2 ещё не означает, что memory.high реально настроен для ваших контейнеров.

Обычно memory limit контейнера мапится в memory.max. А вот активное использование memory.high связано с MemoryQoS и конкретной конфигурацией kubelet/runtime. Если MemoryQoS не включён или runtime не выставляет этот параметр, memory.high может оставаться равным max, то есть фактически не работать как предварительный тормоз перед OOM.

Проверять надо на живой ноде:

cat /sys/fs/cgroup/.../memory.high

Если там max, никакого троттлинга на этом уровне нет.

3. QoS-классы: кто на самом деле защищён?

Когда память заканчивается на всей ноде, важную роль играет oom_score_adj. Это поправка, которую Kubernetes выставляет процессам контейнеров, чтобы повлиять на выбор жертвы kernel OOM Killer’ом.

QoS-классы в Kubernetes такие:

Guaranteed

Pod получает Guaranteed, только если для каждого контейнера заданы и CPU, и memory request/limit, и при этом:

cpu request == cpu limit memory request == memory limit

Если забыли задать CPU request/limit - это уже не Guaranteed.

Для обычных пользовательских pod’ов это стандартный способ получить сильную защиту от OOM Killer’а:

cat /proc/$PID/oom_score_adj -997

BestEffort

Если у pod’а нет ни requests, ни limits, он получает BestEffort.

Такие процессы получают:

cat /proc/$PID/oom_score_adj 1000

Это первый кандидат на вылет при node/global OOM.

Burstable

Всё остальное - Burstable.

Для Burstable pod’ов oom_score_adj считается по формуле:

oom_score_adj = 1000 - (1000 × memoryRequestBytes) / nodeMemoryCapacityBytes

Результат зажимается в диапазоне:

[2, 999]

То есть чем больше memory request относительно памяти ноды, тем ниже oom_score_adj и тем меньше вероятность быть выбранным OOM Killer’ом.

В моей лабе это хорошо видно:

# Guaranteed pod

cat /proc/$(pgrep stress-ng)/oom_score_adj

-997

# BestEffort pod

cat /proc/$(pgrep alpine)/oom_score_adj

1000

Отдельный нюанс: системные процессы могут быть защищены ещё сильнее. В моей песочнице, например, kubelet имел oom_score_adj=-999, а sshd - -1000.

То есть Guaranteed - это не имба для пода. Это сильная защита по сравнению с обычными workload-процессами, но не абсолютная гарантия жизни.

4. QoS и eviction - не одно и то же

Тут легко ошибиться.

oom_score_adj важен для kernel OOM Killer’а, когда ядро уже само выбирает, кого убить.

А kubelet eviction работает иначе. Если kubelet успевает заметить memory pressure до global OOM, он выселяет pod’ы по своей логике. Там важны:

1. превышает ли pod свои requests;

2. PriorityClass;

3. насколько сильно usage превышает request.

QoS-класс коррелирует с этим поведением, но не является единственным алгоритмом eviction.

Например, pod с низким priority, но потреблением в пределах request, не обязательно будет выселен раньше pod’а с более высоким priority, который сильно вышел за request. Поэтому для анализа инцидента надо понимать, что именно произошло:

• контейнер умер из-за своего memory limit;

• pod был выселен kubelet’ом;

• процесс был убит kernel OOM Killer’ом при global OOM.

Это разные события, и следы у них разные.

5. Global OOM: когда kubelet не успел

Если память на ноде закончилась резко, kubelet может не успеть сделать eviction. Тогда срабатывает обычный kernel OOM Killer.

Для проверки я запускал простой Python-скрипт, который агрессивно захватывал память:

import time

data = []

while True:

data.append(bytearray(100 * 1024 * 1024))

time.sleep(0.1)

В dmesg после этого можно увидеть что-то вроде:

Out of memory: Killed process 1841 (python3) total-vm:10GB, anon-rss:3.7GB, oom_score_adj:0

Здесь важно правильно читать поля.

total-vm - это виртуальное адресное пространство процесса.

anon-rss - реально резидентные анонимные страницы в RAM.

Разница между total-vm и anon-rss хорошо показывает, почему нельзя смотреть только на VIRT в top/ps и делать вывод, что процесс реально занял столько RAM. Но это ещё не вся история overcommit. Для анализа overcommit лучше смотреть глобальные счётчики:

grep -E 'CommitLimit|Committed_AS' /proc/meminfo

Committed_AS показывает объём памяти, который ядро уже пообещало процессам.

CommitLimit показывает предел, после которого новые аллокации в strict mode должны начать отклоняться.

Ещё один важный момент при разборе OOM-логов: не путайте строки invoked oom-killer и Killed process.

Строка вида:

python3 invoked oom-killer

описывает процесс, который наткнулся на нехватку памяти.

А строка:

Out of memory: Killed process ...

описывает уже выбранную жертву.

Иногда это один и тот же процесс, иногда нет.

6. Опасные игры с vm.overcommit_memory

В Linux есть три режима overcommit:

0 — эвристика ядра

1 — always overcommit

2 — strict overcommit

В моей лабе на ALT Linux 11 после старта Minikube/kubelet значение vm.overcommit_memory переключалось в 1.

Проверяется так:

sysctl vm.overcommit_memory

Важно: это node-level sysctl, а не настройка конкретного pod’а или cgroup. Он влияет на поведение всей ноды.

Режим 1 разрешает агрессивный overcommit: процессы могут успешно получать виртуальную память «про запас», а реальные проблемы проявятся позже - когда память начнут фактически трогать и страницы станут резидентными.

Самая опасная ситуация - вручную переключить ноду в strict mode:

sysctl vm.overcommit_memory=2

В режиме 2 ядро начинает проверять, не превышают ли обещанные аллокации общий commit limit.

Упрощённая формула такая:

CommitLimit = SwapTotal + RAM × overcommit_ratio / 100

Более точная формула учитывает huge pages:

CommitLimit = SwapTotal + (RAM - HugeTLB) × overcommit_ratio / 100

В моей лабе было 4 ГБ RAM, swap выключен, overcommit_ratio=50. Поэтому CommitLimit оказался около 2 ГБ:

sysctl vm.overcommit_memory=2

cat /proc/meminfo | grep CommitLimit

CommitLimit: 2005936 kB

Если нода уже нагружена и Committed_AS выше нового CommitLimit, такое переключение может быстро превратить систему в кирпич: новые процессы, fork, SSH-сессии и служебные демоны могут начать получать отказ на выделение памяти.

Перед включением strict mode надо хотя бы проверить:

grep -E 'CommitLimit|Committed_AS' /proc/meminfo

Если Committed_AS уже выше будущего CommitLimit, включать strict mode нельзя без подготовки.

Более безопасный порядок такой:

sysctl vm.overcommit_ratio=80

sysctl vm.overcommit_memory=2

Но и это не рекомендация «делать в проде». Это настройка, которую надо тестировать под конкретный workload. Kubernetes-кластер с контейнерами, JVM, Python, Go-сервисами, базами данных и sidecar’ами может очень неприятно отреагировать на строгий overcommit.

7. Что реально помогают настроить kube-reserved, system-reserved и evictionHard

Чтобы нода не доходила до global OOM, Kubernetes даёт несколько механизмов резервирования.

kube-reserved - ресурсы для kubelet, container runtime и компонентов Kubernetes.

system-reserved - ресурсы для системных демонов ОС.

evictionHard - аварийный порог, при котором kubelet начинает выселять pod’ы.

Например:

kubeReserved:

memory: "512Mi"

systemReserved:

memory: "512Mi"

evictionHard:

memory.available: "500Mi"

Эти параметры не делают pod’ы магически безопасными. Они уменьшают Node Allocatable и создают буфер, чтобы kubelet успел начать eviction до того, как ядро сорвётся в global OOM.

Но если memory spike слишком резкий, kubelet всё равно может не успеть. Тогда решение будет принимать уже kernel OOM Killer.

8. Что делать в целях диагностики

Проверить версию cgroup

stat -fc %T /sys/fs/cgroup

Для cgroup v2 будет:

cgroup2fs

Найти cgroup процесса

cat /proc/$PID/cgroup

Проверить лимиты контейнера

cat /sys/fs/cgroup/.../memory.max

cat /sys/fs/cgroup/.../memory.high

cat /sys/fs/cgroup/.../memory.oom.group

cat /sys/fs/cgroup/.../memory.events

Проверить приоритет для OOM Killer’а

cat /proc/$PID/oom_score

cat /proc/$PID/oom_score_adj

Проверить overcommit

sysctl vm.overcommit_memory

sysctl vm.overcommit_ratio

grep -E 'CommitLimit|Committed_AS' /proc/meminfo

Проверить события Kubernetes

kubectl describe pod <pod>

kubectl get events --sort-by=.lastTimestamp

Если контейнер умер из-за собственного лимита, обычно будет видно OOMKilled.

Если pod выселил kubelet, будет Evicted.

Если был global OOM на ноде, следы надо искать уже в dmesg/journal:

dmesg -T | grep -i -E 'out of memory|oom|killed process'

journalctl -k | grep -i -E 'out of memory|oom|killed process'

Итоги

requests и limits - это важные механизмы, но они не отменяют реальность Linux memory management.

Ключевые выводы всего вышеописанного:

1. Memory limit контейнера - это cgroup-лимит, а не предварительно зарезервированная RAM.

2. На cgroup v2 при memory.oom.group=1 процессы внутри контейнера обычно убиваются как группа. Но для multi-container pod это не всегда означает смерть всех контейнеров pod’а.

3. memory.high - полезный механизм cgroup v2, но не надо считать, что Kubernetes всегда его использует. Проверяйте реальное значение в cgroup.

4. QoS влияет на oom_score_adj, но kubelet eviction и kernel OOM Killer - разные механизмы.

5. Guaranteed - это сильная защита, но не гарантия бессмертия для пода. Системные процессы могут быть защищены сильнее, а при тяжёлом global OOM ядро всё равно будет кого-то убивать.

6. Strict overcommit mode опасен без расчёта Committed_AS и CommitLimit. Особенно на Kubernetes-нодах, где много процессов активно резервируют виртуальную память.

7. kube-reserved, system-reserved и evictionHard нужны не для красоты. Они дают kubelet шанс выселить pod’ы раньше, чем нода попадёт в global OOM.

Для тех, кто любит ностальгировать по старому доброму компьютерному прошлому, когда еще даже не вышла кора дуба, и многие сидели на Пентиумах 4 1,4 ГГц, а видеокарта была на AGP)

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

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

One to eight Pentium III Xeon Processors with Redundant Processor Power Module
Four 1" Wide Ultra2/Ultra3 SCSI Hot Plug Drive Bays
Two Redundant Hot Plug Power Supplies
Redundant Hot Plug Fans 
Eleven 64-bit PCI-X and PCI I/O expansion slots, all Hot Plug (10 x 100 MHz PCI-X and 1 x 33 MHz PCI)
Hot Spare Boot (NOTE: Upon the event of a failed processor or VRM in a multi-processing environment, the system will automatically reboot and use the remaining good processor(s).)

https://www.harddrivesdirect.com/quickspecs_proliant_DL760.p...

Sun 6500. Фирма Sun в 2010 была куплена фирмой Oracle. Последний SPARC M8 вышел в 2017 году. Технология замены была.

The CPU/Memory+ board and the I/O+ board are hot-pluggable under certain conditions. If the operating system detects a hardware failure in the board, the system powers down the corresponding board slot and turns off the left green status LED on the board. (See TABLE 9-2 for LED codes.)

https://docs.oracle.com/cd/E19095-01/ent55.srvr/805-2632-10/805-2632-10.pdf

Был IBM System x3950 M2 с его
Active Memory™ with Memory ProteXion, hot-swap memory with memory mirroring
https://lenovopress.lenovo.com/sg247630.pdf

Только для работы нужен включенный memory mirroring . И IBM больше не продает x86 – в 2014 году они продали этот бизнес Lenovo

Технология memory mirroring  до сих пор поддерживается, но с ограничениями

Memory Mirroring is supported by all Intel Xeon Scalable processors, starting from 1st Gen processors. Address Range Mirroring is only supported by Intel Xeon Platinum processors and Intel Xeon Gold processors.
Note that even though vSphere ESX supports reliable memory, vSphere Distributed Resource Scheduler (DRS) does not support for reliable memory and DRS is a feature included in the vSphere Enterprise Plus.

To use Memory Mirroring and Address Range Mirroring, the server configuration must meet the following requirement:

Lenovo ThinkSystem servers with Intel Xeon processors can support Memory Mirroring.

Lenovo ThinkSystem servers with Intel Xeon Platinum Processors or Intel Xeon Gold Processors can support Address Range Mirroring feature.

9x4 Dual In-line Memory Modules do not support Memory Mirroring and Address Range Mirroring.

“ADDDC Sparing” should be disabled in UEFI settings if you want to use the Memory Mirroring or Partial Memory Mirroring features. When ADDDC Sparing is enabled, both Full Mirroring and Partial Mirroring setup options get grayed out and mirroring feature cannot be enabled.
https://lenovopress.lenovo.com/lp1877-using-memory-mirroring...

Была такая фирма, Stratus Technologies. Тоже делали свое, отказоустойчивое.
Ну и. В 2014 их купили (Stratus Technologies, Inc. was acquired by Siris Capital Group on April 28, 2014). В 2025 их опять перекупили, теперь они называются Penguin Solutions

Была (или есть) у них линейка ftServer , вот она:
https://servodynamics.com.vn/stratus-ftserver-features-benefits-models-and-applications/

В которой заявляли

Dual customer replaceable units (CRUs) built with industry-standard components
Each CRU includes its own CPU, memory, storage, and power
https://servodynamics.com.vn/stratus-ftserver-features-benefits-models-and-applications/

Только это не CPU hot replace, а выдергивание целой ноды из мини-блейда.

На таком принципе любой блейд с VMware Fault Tolerance (FT) можно назвать Ultra Super HOT SWAP MILFS

С IBM интересная история. Все зависит, как и везде, от количества денег.
Младшие IBM Power, 710 или 730 – вот эти, https://en.wikipedia.org/wiki/IBM_Power_Systems

The IBM Power 710 server does not support CPU hot-swapping. Installing, removing, or replacing a system processor module or processor assembly is considered a non-concurrent maintenance task. You must completely power down the system and remove all power cords before performing any processor-related service.
While you cannot hot-swap the physical processor chips, the server does support Dynamic Processor Deallocation (for isolating failing parts dynamically) and CPU hot-plug (Dynamic LPAR) at the logical partition (LPAR) level to adjust used processors depending on utilization

Часть компонентов, безусловно, заменяемы на горячую.
https://www.redbooks.ibm.com/redpapers/pdfs/redp4796.pdf

То же "с оговорками, не всегда и не совсем" касается и IBM p-series.
Сначала IBM сделала пару раз ребрендинг –

In 2007, after the introduction of the POWER6 processor models, the last rename under the System p brand dropped the p (numbered) designation.

In April 2008, IBM announced a rebranding of the System p and its unification with the mid-range System i platform. The resulting product line was called IBM Power Systems.

Посмотрим руководство.

IBM Power S1012. Preparing the 9028-21B system to remove and replace the system processor module

To avoid possible data loss, you must power on the system to standby state after you replace each of these parts individually.
Identify the part and the system that you are working on. For instructions, see Identifying a part.

Use the blue identify LED on the enclosure to locate the system. Ensure that the serial number of the system matches the serial number to be serviced.

Stop the system. For instructions, see Stopping a system.

https://www.ibm.com/docs/en/power10/9028-21B?topic=module-preparing-system

Посмотрим IBM потолще -  IBM Power E1180, в документации к которому можно заблудиться -
https://www.ibm.com/docs/en/power11/9080-HEU?topic=e1180-tro...

поэтому посмотрим  Zero Downtime, Automation, and Energy Optimization on IBM Power11
https://www.redbooks.ibm.com/redbooks/pdfs/sg248596.pdf
Раздел 2.4 Live Partition Mobility

3. Checkpointing The system captures the state of all running processes on the original LPAR. This state includes memory, CPU state, open file descriptors, and network connections.

4. Workload migration The system transfers the captured state to the surrogate LPAR. The processes resume in their previous state.

5. Completion The surrogate LPAR becomes the new active system. You can decommission or reuse the original LPAR.

Выглядит как миграция нагрузки на другой процессорный модуль. Ничего плохого в этом нет, IBM всегда были (но будут ли?) хорошими, но относится ли замена модуля, с которого снята нагрузка и питание, к «горячей замене» ?

В пределах всего шасси, конечно, да, «горячая замена».

Заключение

Хуже всего в РУ сообществах не то, что люди не знают, о чем говорят. Бывает, знают, и знают намного лучше меня. Плохо даже не то, что люди оперируют граничными явлениями, встречающимися на уровне «2 стойки на ЦОД на 5000 стоек», и то не на каждый, и встречавшимися 5, 10, 20 лет назад. Без уточнения, в каком сегменте рынка стояло такое железо, и почему такое.

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

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

Total Cores 32
Max Turbo Frequency 4 GHz
Processor Base Frequency 2.1 GHz
Max Memory Size (dependent on memory type) 4 TB
Memory Types DDR5 @ 4800 MT/s (1 DPC)

Понятно, что закупка идет на системы позапрошлого поколения, 5th Gen Intel® Xeon® Scalable Processors.
С тех пор вышли поколение 6 (Granite Rapids) и 6+ (Intel® Xeon® 6+ processors).
7 поколение, Xeon Diamond Rapids, задержали до 2027 года) .
Но зачем брать утюг на 270 ватт, если есть Intel® Xeon® Gold 6538Y+ Processor на 225 ватт? Только ради 160 мегабайт кеша ?
Но тогда почему не взять Intel® Xeon® Gold 6554S Processor ? Или не платину Intel® Xeon® Platinum 8581V Processor ? Те же 270 ватт, но 300 кеша, 60 ядер.

И почему всего терабайт памяти, если их до 4 Тб на сокет для этого голда?

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

Сводная таблица спецификация 5 поколения:

https://www.intel.com/content/www/us/en/ark/products/series/...

PS

Еще и без GPU.