Альтернативи ESXi для SMB: Proxmox vs XCP‑ng vs Hyper‑V

Рішення за 60 секунд

Якщо вам потрібен найкоротший шлях до «працює як сучасний стек VMware» у невеликому офісі: обирайте Proxmox, особливо якщо ви комфортно працюєте з Linux і хочете потужні вбудовані резервні копії, кластеризацію та зрозумілу історію зі сховищем (ZFS для одиночного хоста або невеликих кластерів; Ceph — якщо у вас справді є потрібні вузли та мережа).

Якщо ви хочете віртуалізацію на базі Xen із чітким поділом обов’язків і солідною екосистемою: обирайте XCP‑ng разом з Xen Orchestra. Підходить, якщо вам подобається, коли хости відчуваються як аплайанс, а керування — ніби створене для цього, а не прироблене.

Якщо ви — Windows‑перший SMB з AD, Windows‑адміністраторами та вже сплачуєте за ліцензії Microsoft: обирайте Hyper‑V з Failover Clustering, якщо потрібна висока доступність, або окремий Hyper‑V, якщо ні. Це нудно, підтримується і дуже добре підходить для Windows‑навантажень. Але ваш дизайн сховища й резервного копіювання має бути явним, а не «на відчуттях».

Чого уникати: двовузлова «HA» конструкція без свідка, без протестованого відновлення і зі схемою сховища «в нас є NAS». Це не архітектура; це майбутній звіт про інцидент.

Що реально потрібно SMB (і що воно вважає потрібним)

Справжні вимоги

• Передбачувані оновлення, які не перетворюються на археологію на вихідних.
• Резервні копії, які ви можете відновити без молитви, особливо для контролерів домену, бізнес‑додатків і файлових серверів.
• Поведінка сховища, яку ви можете пояснити: затримка, надійність запису, кеш, снапшоти, реплікація. «Швидко» — це не план.
• Операційна ергономіка: віддалена консоль, життєвий цикл ВМ, зміни мережі та логи, які ви справді можете прочитати.
• Модель відмов: що відбувається, коли помирає хост, комутатор або заповнюється datastore.

Фальшиві вимоги (поширені ілюзії)

• «Нам потрібна HA», коли насправді потрібні швидкі відновлення і запасний хост.
• «Нам потрібна гіперконвергентність», коли немає достатньо вузлів, мережі або оперативної зрілості.
• «Ми просто використаємо той NAS» без підтвердження безпеки кешу запису і поведінки multipath.
• «Нам потрібна жива міграція», але не виділено бюджет на спільне сховище або хоча б дизайн, дружній до міграції.

Надійність — це ланцюг маленьких, неефектних рішень. Гіпервізор — лише одне посилання, але саме його ви торкаєтесь щоразу, коли щось ламається.

Цікавинки та історичний контекст

1. Xen старший за більшість «cloud‑native» посад: гіпервізор Xen виник на початку 2000‑х як дослідницький проєкт і став великою основою в індустрії віртуалізації.
2. Citrix XenServer формував багато корпоративних операцій Xen роками; XCP‑ng виріс як спільнотний продовжувач, коли організації захотіли більше відкритості та контролю.
3. KVM став основним інструментом віртуалізації в Linux і є базою для Proxmox, тож отримує переваги від широких інвестицій у ядро.
4. ZFS спроектований з думкою про цілісність даних end‑to‑end, а не просто як «RAID з кращим UI», саме тому його цінують ті, хто бачив тихі корупції даних.
5. Hyper‑V не «новий»: це роль Windows Server протягом багатьох релізів і вона сильно еволюціонувала завдяки внутрішнім хмарним вимогам Microsoft.
6. Failover clustering передує сучасному хайпу віртуалізації; модель кластеризації Windows давно припускає спільне сховище і кворум — все ще актуально, все ще легко помилитися в конфігурації.
7. Зловживання снапшотами — повторювана тема на всіх платформах: це зручна машина часу, поки не перетвориться на гранату продуктивності і витік сховища.
8. SMB3 приніс серйозну інфраструктуру для сховища (наприклад, multichannel і кращу стійкість) і став легітимним транспортом для робочих навантажень Hyper‑V у багатьох середовищах.

Порівняння платформ: Proxmox vs XCP‑ng vs Hyper‑V

Proxmox: прагматичний швейцарський ніж (з гострими лезами)

Proxmox VE — це платформа на базі Debian, що поєднує в собі віртуалізацію KVM і контейнери LXC з єдиним веб‑інтерфейсом, кластеризацією та вбудованою опцією сервера резервного копіювання (Proxmox Backup Server). Для SMB: можна придбати пару нормальних серверів, встановити Proxmox і отримати щось схоже на VMware без необхідності «збирати власну площину керування».

Де Proxmox блискучий:

• Відмінна історія зі сховищем для SMB: ZFS — першокласний варіант, і ви можете робити розумну реплікацію без SAN.
• Резервні копії — це реальний продукт: PBS добре працює з дедуплікацією, інкрементальними копіями і операційно прийнятний.
• Керування кластером просте, якщо ви поважаєте правила кворуму і фензингу.
• Дружність до Linux: якщо ваша команда знає Linux, завжди є «CLI‑вихід».

Де Proxmox кусає:

• Ceph не іграшка. Він чудовий, коли зроблений правильно, і дорогий, коли зроблений неправильно (в основному в часі, не в ліцензіях).
• Налаштування мережі та сховища має значення, якщо ви хочете детерміновану затримку. За замовчуванням все нормально, але не завжди чудово.
• Підтримка є, але ви все одно працюєте з Linux. Якщо ваша команда ставиться до Linux як до чутки, ви постраждаєте.

XCP‑ng: стабільність Xen з шаром керування, яким ви справді користуватиметесь

XCP‑ng — гіпервізор на базі Xen з доволі аплайсноїною присутністю хоста. У парі з Xen Orchestra (self‑hosted або з підтримкою) ви отримуєте сильний операційний робочий процес: керування ВМ, резервні копії, снапшоти, міграції, шаблони — без потреби приробляти десяток компонентів.

Де XCP‑ng блискучий:

• Операційна ясність: хости відчуваються послідовними; керування цілісне з Xen Orchestra.
• Хороший досвід життєвого циклу ВМ і зріла модель віртуалізації.
• Резервні копії через XO практичні, особливо при правильних репозиторіях і політиці зберігання.

Де XCP‑ng кусає:

• Вибір сховища може бути менш «з коробки» ніж Proxmox+ZFS для малих кластерів, залежно від вашого дизайну.
• Менше масової популярності ніж Hyper‑V; найм і локальні знання можуть бути тоншими в деяких регіонах.
• Деякі просунуті функції ускладнені не ліцензією, а операційною складністю — і це ваша проблема о 2‑й годині ночі.

Hyper‑V: розумний вибір, коли Windows — ваша релігія (або зарплата)

Hyper‑V — гіпервізор, який багато SMB вже мають через ліцензії Windows Server, і він добре інтегрується з Active Directory, Windows‑інструментами та операційним світом Microsoft. Для робочих навантажень Windows це раціональний вибір — особливо якщо ваша команда вже вільно володіє PowerShell.

Де Hyper‑V блискучий:

• Продуктивність і підтримка Windows‑навантажень відмінні.
• Failover Clustering зрілий і робить саме те, що обіцяє, якщо ви дотримуєтесь кворуму і вимог до сховища.
• Операційна сумісність в Microsoft‑середовищах: моніторинг, патчинг, ідентичність і управління узгоджені.

Де Hyper‑V кусає:

• Дизайн спільного сховища може бути безжалісним. CSV, iSCSI, SMB3 — кожен має гострі кути при неправильній конфігурації.
• Екосистема резервного копіювання дуже різна. Є чудові продукти; є такі, що «створюють файли, отже це резервне копіювання».
• Linux‑гості працюють добре, але якщо у вас переважно Linux і велике навантаження на сховище, Proxmox зазвичай плавніший у щоденній експлуатації.

Мій упереджений рейтинг для SMB (з застереженнями)

• Найкращий загальний вибір для SMB: Proxmox, якщо ви готові вивчити його досконало (особливо ZFS і гігієну резервного копіювання).
• Найкращий вибір «аплайс‑підхід + чисті операції»: XCP‑ng з Xen Orchestra, якщо ви хочете сфокусований стек віртуалізації зі зручними робочими процесами.
• Найкращий вибір для Windows‑перших: Hyper‑V, якщо у вас вже всюди Windows Server і ви вмієте відповідально проєктувати спільне сховище.

Невеликий жарт для очищення смаку: обговорення ліцензування віртуалізації — це єдині наради, де люди можуть втратити гроші, сидячи нерухомо.

Реалії сховища: ZFS, Ceph, SMB3, iSCSI та «NAS, що бреше»

Почніть з навантаження: чутливість до затримки важливіша за маркетинг IOPS

Віртуалізація в SMB зазвичай — суміш: кілька баз даних, файлові служби, AD, можливо інструмент RMM, VoIP‑аплайанс і якесь бізнес‑ПЗ, яке постачальник наполягає, що «легке». Правда в тому, що багато навантажень у SMB чутливі до затримки, а не до пікових пропускних здатностей. Користувачі помічають 30 ms затримки сховища швидше, ніж відсутність пікових IOPS у специфікації.

Сховище Proxmox: ZFS — стандартна відповідь з причини

Якщо ви не купуєте SAN, ZFS дає узгоджену історію: контрольні суми, снапшоти, реплікацію, компресію та передбачувані інструменти. Але ZFS не пробачить, якщо ви уявляєте, що RAM і правильний розклад vdev — опційні.

• Mirror vdevs — типовий солодкий пляж для SMB: передбачувана затримка і виживаність.
• RAIDZ підходить для ємкісних робочих навантажень, але випадкова затримка запису може зашкодити деяким сумішам ВМ.
• SLOG та L2ARC не є магічними «прискорювачами»; вони мають специфічні цілі та режими відмов.

Сховище Proxmox: Ceph чудовий, коли у вас є відповідна форма

Ceph блискучий, коли у вас достатньо вузлів (зазвичай 4+ для комфортної експлуатації, хоча люди працюють і з 3) і мережа, що не саботує його. Якщо ваша «мережа сховища» — один комутатор без резервування і VLAN, який іноді «забувають», Ceph навчить вас дисципліні.

Ceph зроблений правильно дає розподілене сховище, самовідновлення і тісну інтеграцію з Proxmox. Ceph зроблений неправильно дає «чому все повільно» і «чому кластер перейшов у режим read‑only».

Сховище XCP‑ng: оберіть дизайн, який ви зможете пояснити на дошці

XCP‑ng підтримує кілька типів репозиторіїв сховища, і правильний вибір залежить від вашого середовища. У SMB часто використовують спільне iSCSI/NFS сховище або локальне сховище з реплікацією/резервними копіями. Найбільший ризик — ставитися до спільного сховища як до «просто місця для ВМ», а не як до компонента з налаштуваннями multipath, поведінкою кешу запису і обробкою відмов.

Сховище Hyper‑V: трикутник CSV/SMB3/iSCSI

Hyper‑V може працювати на локальному сховищі, але типовий сценарій HA використовує Failover Clustering з Cluster Shared Volumes (CSV) на спільному блочному сховищі або SMB3‑файлові шари для зберігання ВМ. SMB3 — легітимний варіант, але він вимагає правильної конфігурації NIC, планування multichannel і сховища, яке поводиться під тривалим I/O від ВМ. Побутовий NAS, що виглядає нормально при копіюванні файлу зі швидкістю 50 MB/s, може здатися безсилим при малій випадковій записі з 20 ВМ.

Другий короткий жарт, бо сховище цього заслуговує: NAS без батарейно‑захищеного кешу запису — це як парашут із оптимізму: добре, поки не знадобиться.

Управління та операції: день‑2 важливіший за день‑1

Операції Proxmox

Веб‑інтерфейс Proxmox міцний, але справжня сила в тому, що під ним Linux. Це і сила, і пастка. Ви можете виправити майже все, а отже ви також можете «виправляти» речі так, що вони відходять від UI і потім дивують під час оновлень.

Операційні поради, що справді важливі:

• Тримайте зміни на хостах декларативними, де можливо (конфіг кластера, визначення сховищ, мережеві налаштування під контролем).
• Використовуйте Proxmox Backup Server замість імпровізованого експорту снапшотів.
• Плануйте кворум (непарна кількість голосуючих; використовуйте qdevice, якщо потрібно).

Операції XCP‑ng

Хости XCP‑ng доволі аплайсні, що зменшує розповзання конфігурацій. Xen Orchestra стає операційним центром: розклади резервних копій, збереження, тести відновлення, журнали завдань і інвентар. Це добре для SMB, бо «одне вікно» зменшує людські помилки під тиском.

Головна дисципліна операцій: тримайте Xen Orchestra здоровим і задокументованим, а оновлення хостів робіть плановими, а не героїчними діями.

Операції Hyper‑V

Операції Hyper‑V живуть у світі Windows: Failover Cluster Manager, Windows Admin Center, PowerShell і ваші інструменти патч‑менеджменту. У SMB небезпека — випадкова складність: один адміністратор створює кластер, інший робить «тимчасові» винятки, а за шість місяців ніхто не може пояснити, чому Live Migration працює тільки по вівторках.

Операційна суперсила Hyper‑V у тому, що він гармонійно вписується в існуючу Windows‑управління. Слабкість — спільне сховище і мережа кластера мають бути спроєктовані свідомо.

Безпека та патчинг: нудне перемагає

Безпека — це не «увімкнути MFA і готово». Для гіпервізорів це переважно про передбачуваний патчинг, мінімальну площу атаки і аудитованість.

Proxmox

• Базується на Debian, тож звичайний Linux‑патчинг плюс пакети Proxmox.
• Тримайте репозиторії узгодженими між вузлами; змішані репозиторії — класичний шлях до хаосу залежностей.
• Захистіть інтерфейси керування: виділений management VLAN, правила фаєрвола і ніякого «відкрито в інтернеті для зручності».

XCP‑ng

• Каденція патчів пряма; ставте оновлення пулу як планове технічне обслуговування.
• Доступ до XO чутливий; це фактично ваша площина керування віртуалізацією.

Hyper‑V

• Патчинг Windows добре відомий; плануйте кластер‑aware оновлення або еквівалентні робочі процеси.
• Зміцнюйте управління: обмежте RDP, використовуйте RBAC де можливо, логування PowerShell і дій адміністраторів.

Одна ідея про надійність (переказано, джерело вказано): переказана ідея — Gene Kranz: «Успішні операції походять від дисципліни й підготовки, а не від імпровізації.»

Резервні копії та аварійне відновлення: частина, про яку всі шкодують пізніше

Ієрархія резервного копіювання, яка справді працює в SMB

• Швидкі локальні резервні копії для швидких відновлень (хвилини‑години).
• Офлайнні або незмінювані копії для виживання під час ransomware (години‑дні).
• Реплікація поза майданчиком для втрати сайту (дні, але ви принаймні живі).

Proxmox + PBS

Proxmox Backup Server — одна з найпереконливіших причин обрати Proxmox. Він спроєктований для резервного копіювання ВМ з дедуплікацією та інкрементальною поведінкою, що робить часті бекапи реальністю без вибуху потреб у сховищі.

Що робити: ставтеся до сховища PBS як до продуктивних даних. Моніторте його, здійснюйте scrub (якщо ZFS), і тестуйте відновлення щомісяця. «У нас є резервні копії» — це правда лише після тестового відновлення.

XCP‑ng + Xen Orchestra

Система резервного копіювання Xen Orchestra операційно дружня. Можна робити дельта‑бекапи, керувати збереженням і надійно відновлювати — якщо репозиторій бекапів достатньо швидкий і політика зберігання не схожа на звалище.

Що робити: відокремте трафік резервного копіювання, слідкуйте за продуктивністю репозиторію і тестуйте відновлення з перевірками на рівні додатків.

Резервні копії Hyper‑V

Hyper‑V має хорошу інтеграцію VSS, але результат резервного копіювання сильно залежить від вибраного інструмента і дизайну сховища. Є хороші продукти; є налаштування, що тихо пропускають ВМ і все одно висилають «успішно». Вам потрібні журнали завдань з результатом по ВМ і процес, що голосно падає при помилці.

Три міні‑історії з корпоративного світу (анонімізовано, правдоподібно, технічно реально)

Інцидент, спричинений неправильним припущенням: «снапшоти NAS — це резервні копії»

Професійна фірма середнього розміру перейшла з застарілого гіпервізора на блискучий новий кластер. Вони використали спільне сховище на NAS і почувалися розумними: «NAS робить щогодинні снапшоти. Ми захищені.» Резервні копії відклали, бо міграція вже з’їла бюджет і терпіння.

Через три місяці стався ransomware: від однієї робочої станції воно поширилося по файлових шарах і врешті опинилося у гостьових шарах ВМ. Снапшоти NAS були, але розклад і збереження підходили для «ой, я випадково видалив файл», а не для «відкотити тиждень активно зашифрованих даних». Декілька снапшотів були забруднені, а найстаріша чиста точка була за межами вікна збереження.

Неправильне припущення не в тому, що снапшоти марні. Неправильне припущення — що снапшоти — це резервні копії. Резервні копії — ізольовані, відновлювані і операційно перевірені. Снапшоти — зручна функція з гострими кутами.

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

Оптимізація, що повернулася бумерангом: «увімкнемо дедуплікацію скрізь»

Малий SaaS‑провайдер з різною флотилією ВМ хотів зменшити витрати на сховище. Вони включили агресивну дедуплікацію і компресію на рівні сховища без бенчмарків. Спочатку результати виглядали добре: графіки ємності покращилися, керівництво посміхнулося, і всі забули.

Потім повільно підкралась затримка. Не постійна. Спайкова. Така, що SQL‑сервери жалілися, час входу коливався, і «інтернет повільний»‑заявки множилися. CPU сховища горіли обробкою дедуплікації, а робоча множина не дедуплікувалася так добре, як очікували. Гірше, адміністратори додали швидкий кеш, який не мав захисту від втрати живлення, бо «він добре пройшов бенчмарк».

Вони відкотили дедуплікацію на «гарячих» даних, залишили компресію де вона допомагала і правильно підібрали систему під реальний I/O, а не під бажану математику ємності. Оптимізація не була злою; вона була неміряною і застосована повсюдно.

Наслідком був не лише вплив на продуктивність. Це підкопало довіру до платформи. Коли користувачі перестають довіряти платформі, усі питання стають проблемами гіпервізора — навіть якщо вони такими не є.

Нудна, але правильна практика, що врятувала день: «кворум і фензинг не опціональні»

Виробничий SMB мав двовузловий кластер у віддаленому сайті. Нічого фантастичного. Вони зробили непопулярну річ: додали третій голос кворуму (маленький пристрій/сервіс‑свідок), задокументували модель відмов і перевірили, що втрата вузла викликає очікувану поведінку. Також налаштували фензинг, щоб розділений вузол не міг продовжувати писати у спільні ресурси.

Через шість місяців комутатор впав так, що розділив зв’язок кластера. У багатьох SMB це призвело б до split‑brain і корупції даних, що виявлялася б тижнями як «дивні проблеми в базах даних».

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

Це неефектна правда: нудні практики не роблять чудових слайдів, але вони запобігають відмовам, які руйнують кар’єри.

Практичні завдання з командами, виводами й рішеннями (12+)

Це перевірки, які я виконую, коли успадковую кластер, підозрюю вузьке місце або планую міграцію. Команди показані з реалістичними виводами і тим, яке рішення на їхній основі приймати.

1) Proxmox: підтвердити стан кластера і кворум

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             smb-cluster
Config Version:   12
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             2025-12-28 10:14:05
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2f
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate

Що це означає: Ви маєте кворум. Очікувані голоси збігаються з фактичними. Нема «2‑вузлового псевдо‑HA».

Рішення: Якщо Quorate: No або голосів не вистачає, зупиніть планування міграцій/оновлень і виправте кворум спочатку (qdevice, третій вузол або стратегія свідка).

2) Proxmox: перевірити стан Ceph (якщо використовуєте)

cr0x@server:~$ ceph -s
  cluster:
    id:     3b1f5e2a-9c1b-4c9b-8f0c-6b2a2a7c9d11
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 37 sec

  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 4h)
    mgr: pve1(active, since 2h), standbys: pve2
    osd: 9 osds: 9 up (since 3h), 9 in (since 3h)

  data:
    pools:   3 pools, 128 pgs
    usage:   2.1 TiB used, 4.9 TiB / 7.0 TiB avail
    pgs:     128 active+clean

Що це означає: Дані чисті, але є повільні операції. Зазвичай це затримка: диски, мережа або зайнятий OSD.

Рішення: Не ігноруйте повільні операції. Перевірте затримки OSD і пропади мережі, доки користувачі не помітили.

3) Proxmox: стан пулу ZFS і лічильники помилок

cr0x@server:~$ zpool status -v
  pool: rpool
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: Upgrade the pool to enable all features.
  scan: scrub repaired 0B in 00:19:12 with 0 errors on Sun Dec 22 03:10:41 2025
config:

        NAME                                             STATE     READ WRITE CKSUM
        rpool                                            ONLINE       0     0     0
          mirror-0                                       ONLINE       0     0     0
            ata-SAMSUNG_MZ7L3480HBLT-00003_S6H7NX0T12345 ONLINE       0     0     0
            ata-SAMSUNG_MZ7L3480HBLT-00003_S6H7NX0T67890 ONLINE       0     0     0

errors: No known data errors

Що це означає: Пул здоровий; scrub‑перевірки відбуваються; немає ознак тихої корупції даних.

Рішення: Якщо ви бачите ненульовий CKSUM або помилки читання, перевірте кабелі/HBA/прошивку дисків перед тим, як звинувачувати «гіпервізор».

4) Proxmox: перевірити ризик thin provisioning (LVM‑thin)

cr0x@server:~$ lvs -a -o+seg_monitor,lv_size,data_percent,metadata_percent vg0
  LV                VG  Attr       LSize   Pool     Data%  Meta%  Monitor
  data              vg0 twi-aotz--  <3.64t           88.21  12.44  monitored
  vm-101-disk-0     vg0 Vwi-aotz--  120.00g data     67.02
  vm-102-disk-0     vg0 Vwi-aotz--  200.00g data     91.13

Що це означає: Ваш thin‑pool заповнений на 88%. Понад ~90% ви потрапляєте в зону «ВМ можуть ставати на паузу або пошкоджуватись», якщо він заповниться.

Рішення: Розширте пул, видаліть старі снапшоти або мігруйте ВМ. Також встановіть оповіщення на 70/80/90%.

5) Хост Linux: швидко знайти затримку сховища за допомогою iostat

cr0x@server:~$ iostat -x 1 3
Linux 6.8.12 (pve1)  12/28/2025  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.21    0.00    3.44    8.77    0.00   77.58

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz await r_await w_await  svctm  %util
nvme0n1         85.00  220.00  4200.0 18000.0    170.9     2.15   7.90    2.10   10.10   0.38  11.5
sda              1.00   55.00    12.0   820.0     30.9    12.40 220.00   15.00  223.00   2.10  12.0

Що це означає: sda має 220 ms await на запис. Це затримка, яку відчують користувачі, навіть якщо %util не зашкалює.

Рішення: Визначте, що розміщено на sda (журнал, ціль бекапу, повільний datastore) і припиніть класти довільні записи туди.

6) Proxmox: побачити навантаження диска по ВМ

cr0x@server:~$ pvesh get /nodes/pve1/qemu/101/status/current
{
  "cpu": 0.12,
  "diskread": 10485760,
  "diskwrite": 52428800,
  "mem": 3435973836,
  "name": "sql-small",
  "netin": 1048576,
  "netout": 786432,
  "status": "running",
  "uptime": 172800
}

Що це означає: Ця ВМ пише набагато більше, ніж читає. Спаруйте це з перевірками затримки сховища.

Рішення: Якщо «гучний сусід» очевидний, перемістіть його на швидше сховище або ізолюйте на власному vdev/LUN.

7) XCP‑ng: перевірити стан пулу і хостів

cr0x@server:~$ xe pool-list
uuid ( RO)                : 2c7f6c2c-1b75-4a8b-8a8e-4a1d3d2a2f31
          name-label ( RW): smb-xcp-pool
    name-description ( RW): Primary virtualization pool
              master ( RO): 0a1b2c3d-4e5f-6789-aaaa-bbbbccccdddd

Що це означає: У вас визначений пул і master. У Xen‑світі здоров’я master важливе для оркестрації.

Рішення: Якщо master непевний, виправте його перед оновленнями або міграціями; операції пула залежать від нього.

8) XCP‑ng: перелік репозиторіїв сховища і раннє виявлення «майже повно»

cr0x@server:~$ xe sr-list params=name-label,uuid,type,physical-size,physical-utilisation
name-label ( RW): iSCSI-SR
uuid ( RO)      : 11111111-2222-3333-4444-555555555555
type ( RO)      : lvmoiscsi
physical-size ( RO): 4398046511104
physical-utilisation ( RO): 4026531840000

Що це означає: ~4.0 TB використано з 4.4 TB. Це небезпечно мало для снапшотів і метаданих.

Рішення: Розширте SR або евакуюйте ВМ. Також зменшіть збереження снапшотів, якщо вони використовуються як машина часу.

9) XCP‑ng: перевірити вплив завдань бекапу шляхом виявлення проліферації снапшотів

cr0x@server:~$ xe snapshot-list params=uuid,name-label,creation-time | head
uuid ( RO)         : 9a9a9a9a-1111-2222-3333-444444444444
name-label ( RO)   : xo_backup_delta_101_2025-12-28T02:00:01Z
creation-time ( RO): 2025-12-28 02:00:03Z

Що це означає: XO створив снапшот резервної копії. Це нормально — якщо їх правильно прибирають.

Рішення: Якщо снапшоти зберігаються довше за вікно завдання, перевірте завислі бекапи і продуктивність репозиторію, перш ніж це переросте в лавину.

10) Hyper‑V: перевірити роль хоста і запущені ВМ

cr0x@server:~$ powershell -NoProfile -Command "Get-VM | Select-Object Name,State,Status | Format-Table -AutoSize"
Name             State   Status
----             -----   ------
AD01             Running Operating normally
FILE01           Running Operating normally
SQL01            Running Operating normally
RDSH01           Running Operating normally

Що це означає: Базовий інвентар. Проблеми зі «Status» часто корелюють з проблемами сховища або інтеграційних сервісів.

Рішення: Якщо ВМ показують деградовану інтеграцію, виправте це перед тестуванням міграцій або бекапів.

11) Hyper‑V: перевірити кворум кластера і стан вузлів

cr0x@server:~$ powershell -NoProfile -Command "Get-Cluster | Select-Object Name,QuorumArbitrationTimeMax,QuorumType | Format-List"
Name  : SMB-CLUSTER
QuorumArbitrationTimeMax : 60
QuorumType : NodeAndFileShareMajority

Що це означає: У вас є свідок (файловий шар) і модель кворуму, що може пережити втрату вузла.

Рішення: Якщо у вас 2‑вузловий кластер без свідка, додайте його, перш ніж називати це «HA».

12) Hyper‑V: стан CSV і виявлення redirected I/O

cr0x@server:~$ powershell -NoProfile -Command "Get-ClusterSharedVolume | Select-Object Name,State,OwnerNode | Format-Table -AutoSize"
Name                      State  OwnerNode
----                      -----  ---------
Cluster Disk 1 (CSV)      Online HVNODE1
Cluster Disk 2 (CSV)      Online HVNODE2

Що це означає: CSV‑томи онлайн. Але «онлайн» не означає «швидко». Redirected I/O все ще може вам нашкодити.

Рішення: Якщо підозрюєте redirected I/O, перевірте події кластера і мережевий дизайн; трафік сховища може робити hairpin.

13) Мережа: виявити невідповідність MTU і пропади на Linux‑хостах

cr0x@server:~$ ip -s link show dev bond0
2: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
     9812312312 8123123      0   12450       0  12345
    TX:  bytes packets errors dropped carrier collsns
     8123123123 7123123      0       0       0      0

Що це означає: RX‑пакети відкидаються на bond, який виконує роль мережі для сховища/міграції — підозріло. MTU‑невідповідність, буферизація комутатора або перевантаження.

Рішення: Не вмикайте jumbo frames «бо продуктивність», якщо кожен проміжний хоп не узгоджений і не протестований реальним трафіком.

14) Proxmox: перевірити, чи завдання резервного копіювання реально виконувалися і скільки часу займали

cr0x@server:~$ cat /var/log/pve/tasks/active | head
UPID:pve1:0002A1B3:01A2B3C4:676F6D10:vzdump:101:root@pam:
UPID:pve1:0002A1B4:01A2B3C5:676F6D12:vzdump:102:root@pam:

Що це означає: Завдання працюють. Корелюйте з логами завершення, щоб упевнитися, що вони завершуються і не зависають.

Рішення: Якщо завдання довго виснуть або накладаються на робочий час, налаштуйте розклад, обмеження пропускної здатності та продуктивність сховища.

Швидкий план діагностики

Це послідовність «припиніть гадати», коли користувачі скаржаться, що «все повільно» або коли міграції/бекапи повільні. Мета — знайти вузьке місце за хвилини, а не години.

Перше: це затримка сховища, конкуренція CPU чи пропади мережі?

• Затримка сховища: запустіть iostat -x на хостах; перевірте дашборди сховища гіпервізора; шукайте високу await, глибину черги і насичення.
• Конкуренція CPU: перевірте симптоми steal/ready на хості (залежить від платформи); упевніться, що ви не надмірно перевантажили машину під високим навантаженням на переривання.
• Мережеві пропади: дивіться лічильники drop на інтерфейсах і помилки портів комутатора; перевірте узгодженість MTU на мережах сховища/міграції.

Друге: ізолюйте «гучного сусіда»

• Визначте ВМ з високими швидкостями запису (бази даних, логування, проксі бекапів).
• Шукайте ланцюги снапшотів і thin‑pools, що наближаються до заповнення.
• Переконайтеся, що бекапи не б’ють по продакшн‑сховищу в піковий час.

Третє: упевніться, що площина керування не бреше вам

• Кворум/кластер: якщо кворум нестабільний, усе інше стає дивним.
• Синхронізація часу: дрейф часу ламає TLS, автентифікацію і логіку кворуму креативними способами.
• Журнали подій: шукайте флапи шляхів сховища, збої multipath, redirected I/O CSV або повільні операції Ceph.

Четверте: вирішіть коригувальну дію

• Якщо висока затримка сховища: перемістіть «гарячі» ВМ, виправте безпечність кеша, додайте дзеркала або оновіть мережу сховища.
• Якщо пропади мережі: виправте MTU/flow control/bonding, оновіть прошивку/драйвери NIC або перерахуйте VLAN/шляхи.
• Якщо бекапи спричиняють біль: додайте виділене бекап‑сховище/репозиторій, обмежуйте пропускну здатність або рознесіть розклади.

Поширені помилки: симптом → корінь → виправлення

1) ВМ ставлять на паузу або сховище переходить у read‑only під навантаженням

Симптоми: ВМ зависають, помилки I/O, раптовий «read‑only filesystem», thin‑pools панікують.

Корінь: Заповнений thin‑pool (LVM‑thin, overcommitted SR, Ceph nearfull) або datastore до 100%.

Виправлення: Встановіть жорсткі пороги оповіщення; розширюйте сховище до 80–85%; зменшуйте збереження снапшотів; переміщуйте великі диски з thin‑pool, якщо вони не моніторяться.

2) Жива міграція випадково не вдається

Симптоми: Іноді працює, іноді таймаутить; швидкість міграції непостійна.

Корінь: Мережа міграції ділиться пропускною здатністю з продакшном, MTU‑невідповідність або проблеми DNS/часу у площині керування.

Виправлення: Виділений VLAN/NIC для міграції; перевірте MTU на кожному хопі; забезпечте стабільну резолюцію і синхронізацію часу.

3) Бекапи успішні, але відновлення зламані

Симптоми: Відновлення завантажується, але додаток пошкоджений; AD або SQL скаржаться; «успішні» бекапи не містять послідовних даних.

Корінь: Немає консистентних снапшотів на рівні додатка (VSS не працює), ланцюги снапшотів занадто довгі або інтеграційні сервіси гостя неправильно налаштовані.

Виправлення: Перевірте guest tools; перевірте VSS‑writers; робіть щомісячні відновлення з перевіркою додатків, не лише «воно завантажилося».

4) Ceph працює посередньо, попри швидкі диски

Симптоми: Повільні операції, непостійні затримки, клієнти відчувають раптові паузи.

Корінь: Недобудована мережа (без резервування, недостатня пропускна здатність), або макет OSD не узгоджений з типами дисків; відновлення конкурує з продакшном.

Виправлення: Розділіть мережі Ceph де потрібно; забезпечте 10/25GbE як базу; налаштуйте recovery/backfill; уникайте змішування повільних HDD‑OSD з latency‑чутливими VM‑пулами.

5) Hyper‑V кластер «працює», але продуктивність жахлива

Симптоми: CSV онлайн, але ВМ підвисають; затримки сховища стрибкоподібні під час failover або бекапу.

Корінь: Проблеми з шляхами до спільного сховища, redirected I/O CSV через мережеві/сховищні збої або погано спроєктована мережа SMB3/iSCSI.

Виправлення: Перевірте multipath; розділіть мережі сховища; перевірте події кластера; переконайтеся, що сховище підтримує навантаження (а не тільки «це NAS»).

6) ZFS «таємниче повільніє» після додавання кеш‑пристрою

Симптоми: Інколи паузи, дивні спайкові затримки, іноді після відключень живлення.

Корінь: Неправильне використання SLOG/L2ARC або SSD без PLP у місцях, де важлива довговічність запису.

Виправлення: Використовуйте SLOG тільки для прискорення sync‑записів з належним захистом від втрати живлення; бенчмаркуйте й перевіряйте; не копіюйте налаштування ZFS механічно.

Чеклісти / покроковий план

Практична карта рішень для SMB

1. Перерахуйте навички вашої команди. Якщо ніхто не вміє усувати проблеми з Linux‑мережею або сховищем, Proxmox/XCP‑ng все ще можливі — але бюджетуйте навчання/підтримку.
2. Визначте вашу ціль HA. Це «хост може померти і ВМ перезапустяться» чи «нульовий простий час»? SMB зазвичай потребують першого.
3. Оберіть стратегію сховища.
   • Один хост: локальний ZFS на Proxmox важко побити.
   • Два хости: будьте обережні — ризики кворуму і split‑brain. Додайте свідка/qdevice.
   • Три+ хости: кластеризація стає розумною; Ceph стає правдоподібним, якщо мережа сильна.
   • Існуючий SAN: будь‑яка з трьох платформ може працювати; питання — інструменти операцій і інтеграція резервних копій.
4. Виберіть платформу резервних копій. Proxmox+PBS — сильний дефолт; XCP‑ng+XO — сильний варіант; для Hyper‑V усе залежить від обраного інструмента і дисципліни процесів.
5. Проведіть пілотну міграцію. Одна Windows‑ВМ, одна Linux‑ВМ, одна «болюча ВМ» (база даних або інтенсивний I/O). Вимірюйте, не гадайте.

План міграції, що не створить місяць хаосу

1. Побудуйте нові хости з чистою management‑мережею. По можливості відокремте управління від трафіку ВМ.
2. Вирішіть макет сховища завчасно. Дзеркала проти RAIDZ, дизайн CSV, SR‑дизайн, розташування репозиторію бекапів.
3. Впровадьте моніторинг до cutover у продакшн. Затримка сховища, вільне місце в пулах, успіх бекапів, тиск пам’яті на хостах.
4. Проведіть тести відновлення під час пілота. Одне відновлення файлу, одне повне ВМ‑відновлення, одне відновлення з консистентністю додатка.
5. Переміщуйте ВМ з низьким ризиком спочатку. Потім середні. Залиште дивний вендорський аплайанс на кінець, коли буде час і кава.
6. Задокументуйте модель відмов. Що відбувається, якщо помре хост? Кого оповіщати? Які RTO/RPO?
7. Каденція патчів і контроль змін. Встановіть щомісячне вікно. Дотримуйтеся його. «Ми ніколи не патчимо» — не стабільність; це відкладена відмова.

Чистота операцій (щомісяця)

• Перевіряти кворум кластера і членство.
• Перевіряти вільне місце в datastore/pool і тренд зростання.
• Переглядати журнали бекапів на предмет успіху по ВМ і зсувів у тривалості.
• Виконати щонайменше один тест відновлення з перевіркою додатка.
• Переглянути снапшоти: вік, кількість і призначення.
• Перевірити лічильники drop/error на NIC і стан портів комутаторів.
• Підтвердити, що синхронізація часу стабільна на хостах і критичних ВМ.

FAQ

1) Яка найкраща альтернатива ESXi для типового SMB з 2–4 хостами?

Proxmox — найкращий дефолт, якщо ви вмієте працювати з Linux. Для більш аплайс‑відчуття XCP‑ng з Xen Orchestra — близький другий вибір. Hyper‑V перемагає, якщо ви Windows‑перші і вже добре управляєте кластерами.

2) Чи Proxmox «клас для підприємств» або просто проєкт для homelab?

Він здатний для підприємств. Питання в тому, чи ваші операції — підприємницького рівня: патчинг, моніторинг, резервні копії і контроль змін. Proxmox не завадить вам робити захоплюючі помилки.

3) Чи повинні SMB використовувати Ceph?

Тільки якщо у вас достатньо вузлів, належна пропускна здатність/резервування мережі і апетит до операцій розподіленого сховища. Якщо у вас 2 вузли і молитва, краще локальний ZFS з реплікацією/бекапами.

4) Чи складніше керувати XCP‑ng ніж Proxmox?

Не обов’язково. Хости XCP‑ng доволі аплайсні, а Xen Orchestra дає чистий робочий процес. Proxmox дає більше «рідної» гнучкості Linux, що може бути легше або важче залежно від вашої команди.

5) Чи Hyper‑V добре працює з Linux‑навантаженнями?

Так, особливо сучасні дистрибутиви з компонентами інтеграції. Але якщо ваша інфраструктура Linux‑орієнтована і сховище‑залежна, Proxmox буде природнішим вибором в експлуатації.

6) Яка найпоширеніша помилка зі сховищем у віртуалізації SMB?

Запуск сховища надто заповненим — thin‑pools, SRs, datastores — поки щось не досягає 100%. Спочатку деградує продуктивність, потім паузи, помилки або пошкоджений стан. Моніторинг ємності не опціональний.

7) Чи дійсно мені потрібен виділений сервер/репозиторій для резервних копій?

Вам потрібна ціль резервного копіювання, яка не помре разом з гіпервізором і бажано не буде зашифрована разом із рештою середовища. Часто це означає окремий сервер або загартований репозиторій, а не «шар на тому ж NAS».

8) Який найпростіший HA, що дійсно безпечний?

3‑вузловий кластер (або 2 вузли плюс належний свідок/qdevice) з чіткою поведінкою кворуму, протестованим failover і резервними копіями, що відновлюються. Усе інше — демонстрація, а не система.

9) Як утримувати витрати під контролем, підвищуючи надійність?

Інвестуйте в нудні речі: ECC RAM, дзеркальні SSD, резервні комутатори (або принаймні резервні шляхи) і ціль резервного копіювання з можливістю незмінності/офлайн. Не переплачуйте за функції, якими ви не вмієте керувати.

Наступні кроки, які можна виконати

1. Оберіть переможця, виходячи з реальності персоналу: Proxmox для команд, що вміють Linux; XCP‑ng+XO для чистих аплайс‑операцій; Hyper‑V для Windows‑перших організацій.
2. Запишіть вашу модель відмов (втрата хоста, втрата комутатора, втрата сховища) і переконайтеся, що дизайн кворуму/свідка відповідає їй.
3. Побудуйте пілот з репрезентативними ВМ і виміряйте затримку сховища, тривалість бекапів і успішність відновлення.
4. Впровадьте моніторинг і оповіщення для ємності, затримки і успіху бекапів до того, як мигруєте все.
5. Заплануйте щомісячні тести відновлення і ставтесь до несправностей як до інцидентів продакшну — бо вони такими і є, лише відкладені.

Якщо хочете правило на око: обирайте платформу, яку ваша команда зможе надійно оперувати о 2‑й годині ночі. Найкращий гіпервізор — той, який ви в змозі полагодити під тиском без імпровізацій, що ведуть до ще більшого інциденту.