Замінити vCenter на Proxmox: що ви отримуєте, що втрачаєте та робочі обходи, які справді працюють

Рамки рішення: що ви фактично замінюєте

Замінювати vCenter на Proxmox — це не просто «змінити гіпервізор». Це замінити цілу операційну модель:

• Площина контролю: vCenter (інколи з SSO, історією PSC, плагінами, моделлю ролей) проти керування кластером Proxmox VE (pve-cluster/corosync) з веб‑інтерфейсом і API.
• Рівень обчислень: ESXi проти KVM + QEMU (і опційно LXC).
• Історія зберігання: VMFS+SAN/NVMe-oF/vSAN проти ZFS/Ceph/NFS/iSCSI/FC (так, FC усе ще існує).
• Мережі: vDS/NSX проти Linux bridges, bonds, VLANs, OVS (опційно) і тим, якою насправді є ваша фізична мережа.
• Операції: «Усе — як у чек‑листі» проти «більшість речей — це файл, команда і лог».

Останній пункт — ключовий. vSphere — це продуктова суїта, що робить більшість речей безпечними для людей, які не хочуть SSH. Proxmox зроблено, щоб речі були можливими для тих, хто це робить.

Жоден підхід не є морально кращим. Але лише один відповідатиме інстинктам вашої команди. Якщо у вашій команді типова реакція — «відкрити тикет», доведеться інвестувати в навчання й охоронні механізми. Якщо ж стандартний інструмент — «tail -f», Proxmox відчується як повернення додому в трохи неохайну квартиру, де нарешті можна переставити меблі.

Цікаві факти та історичний контекст (які важливі в експлуатації)

1. KVM з’явився в ядрі Linux у 2007 році, перетворивши віртуалізацію з «фірмової штуки» на «функцію ядра». Ось чому шар обчислень у Proxmox виглядає нуднувато — і це в хорошому сенсі.
2. QEMU передував KVM; KVM його прискорив. На практиці більшість «чарів» VM в Proxmox — це конфіг QEMU плюс Linux‑підводка.
3. Proxmox VE існує з 2008 року. Це не проєкт вихідного вікенду; це довгоживучий дистрибутив з чіткими поглядами.
4. Рання ціль проекту Ceph — дешеве масштабоване залізо. Та історія видно в операційній натурі: стійкий, потужний і алергічний до примітивних припущень про зберігання.
5. ZFS народився в Sun з end‑to‑end контрольними сумами та copy‑on‑write. ZFS — це система зберігання, яка припускає, що ви собі брешете щодо стану дисків.
6. Live migration у стилі vMotion — це не одна функція; це суміш сумісності CPU, спільного сховища або потоків міграції, стабільності мережі та логіки планування.
7. Правила кворуму corosync походять з боротьби зі split‑brain. Це не обговорюється; це фізика розподілених систем, яка може бути грубою.
8. Домінування vSphere частково пояснюється UX для експлуатації: єдиний GUI, узгоджені поняття та широка екосистема партнерів. Коли ви йдете, ви залишаєте екосистему, а не тільки гіпервізор.
9. Снапшоти VMware стали культурною антипатерною, бо були надто прості. Proxmox теж робить снапшоти простими, тому тут потрібний дорослий нагляд.

Що ви отримуєте з Proxmox (реальні переваги)

1) Площина керування простіша, ніж виглядає

Модель кластера Proxmox пряма: членство corosync, розподілена конфігураційна файловa система (pmxcfs) і вузли, які мають погоджуватися щодо реальності. Ви не отримаєте тисячі об’єктів в інвентарі з плагінами.

У продакшні це часто означає швидше відновлення, коли щось іде не так. Менше рухомих частин — менше моментів «керуюча річ, що керує керуючою річчю» ламається.

2) KVM добре зрозумілий (і широко відлагоджений)

Якщо ви наймаєте Linux‑інженерів, ви зможете забезпечити персонал. Якщо ж вам потрібні «люди з vCenter», ринок менший і зарплатні запити вищі.

Крім того: коли виникає проблема з ядром/драйвером, ви в основному потоці Linux. Це важливо для NIC, HBA, NVMe і дивних серверних платформ, які вендори називають «сертифікованими», поки ви не запитаєте про конкретну прошивку.

3) Варіанти зберігання, що відповідають реальності

Proxmox не нав’язує єдиного погляду на зберігання. Можна використовувати:

• ZFS локально для передбачуваної продуктивності та простоти експлуатації.
• Ceph для розподіленого спільного зберігання з відмовостійкістю — ціна: складність і чутливість до затримок.
• NFS/iSCSI/FC коли бізнес вже має масив і ви не збираєтесь започатковувати релігію зберігання.

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

4) Прозора конфігурація та гачки для автоматизації

Proxmox лояльний до infrastructure‑as‑code, не змушуючи вас в одному вендорському сяйві. API корисний, є CLI, а багато критичних частин — це просто текстові файли.

Це не «легше». Це відновлювано. Коли UI впаде, ви все ще можете працювати. Це недооцінена перевага до тих пір, поки не настав 02:17 і ви дивитесь на пусту вкладку браузера.

5) Контроль витрат не лише про ліцензії

Так, ліцензування — драйвер. Але історія витрат не лише про підписку. Це ще:

• Менша залежність від пропрієтарних знань.
• Гнучкість у життєвому циклі обладнання.
• Можливість стандартизуватися на Linux‑інструментах для моніторингу, логування й інцидент‑відповіді.

Жарт #1: vCenter може відчуватися як розкішний круїзний лайнер. Proxmox — як вантажне судно: менше буфетів, більше наборів ключів.

Що ви втрачаєте (і що боляче в продакшні)

1) Інтеграція екосистеми та «один контакт відповідає»

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

В Proxmox інтеграції є, але ви повинні очікувати, що інтегруватимете через стандартні протоколи і API, а не через «чарівництво вендора». Це ок — поки корпоративний аудит не вимагає скріншотів із конкретної панелі.

2) Заплановане планування DRS і зрілі політики

vSphere DRS — не лише «переміщувати VM». Це доведений часом планувальник із роками шліфування й UI, що робить його невідворотним.

Proxmox має HA, live migration і інструменти, але планування простіше. Якщо ви покладаєтеся на DRS, щоби маскувати хронічні проблеми планування ємності, Proxmox висвітлить ці проблеми яскравим прожектором.

3) Деякі «комфортні функції для підприємств»

Речі, які ви можете пожалкувати в залежності від середовища:

• Глибокі моделі RBAC по багатьох об’єктах і плагінах.
• «Усе підтримується, якщо в HCL» — відчуття перестрахування при закупівлях.
• Відшліфовані життєві цикли патчів і оновлень (Proxmox має інструменти, але вони менш «корпоративні»).

4) Операційні огорожі (щоб запобігти «креативності»)

Proxmox дає силу. Сила хороша, доки добрі наміри інженера «оптимізувати» щось не призведуть до падіння кластера. У vSphere UI та дефолти часто не дозволяють зайвої творчості. У Proxmox Linux чемно дозволить вам робити помилки з великою швидкістю.

5) Реальність очікувань щодо підтримки

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

Жарт #2: Казали, що «ніхто не звільняється за купівлю VMware». Це правда — поки не прийде рахунок і фінанси не стануть вашим інцидентним командиром.

Робочі обходи, які справді працюють (і які — ні)

Замінити DRS: прийміть «достатньо добре», потім додайте огорожі

Що працює:

• Proxmox HA groups + priorities, щоб визначити «які VM мають повертатися першими».
• Афініті/анти‑афініті через теги + автоматизацію (скриптовані перевірки розміщення) для небагатьох навантажень, що цього справді потребують.
• Правило про запас ємності: тримайте нижчий рівень завантаження в steady‑state, щоб вам не потрібен був всезнаючий планувальник.

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

Замінити vSAN: оберіть Ceph або «зберегти SAN», а потім дотримуйтеся вибору

Ceph працює коли: у вас є щонайменше 4–6 вузлів, швидка і надлишкова мережа, однорідні диски та готовність ставитися до зберігання як до сервісу першого класу.

ZFS локально працює коли: ви готові, що «VM живуть там, де лежать дані», і вас влаштовує реплікація/бекапи замість семантики спільного сховища.

Залишати NFS/iSCSI/FC працює коли: у вас вже є команда масивів і ви хочете передбачувану продуктивність з меншою операційною складністю на кластері гіпервізорів.

Що не працює: «Ceph на 3 вузлах з 1GbE бо в лабораторії працювало». Лабораторія завжди працює. Продакшн — місце, де затримки визначають вашу особистість.

Замінити vMotion‑процеси: стандартизуйте шляхи міграції

Proxmox підтримує live migration, але досвід залежить від спільного сховища та якості мережі. Для планового обслуговування live migration підходить. Для «потрібно евакуювати вузол зараз» вам потрібні передбачувані обмеження:

• Однакове сімейство CPU і сумісні прапори, якщо хочете безшовні міграції.
• Спільне сховище (Ceph/NFS/iSCSI) або прийняття копіювання дисків і часу під час міграції.
• Виділена мережа для міграцій або QoS, щоб вона не конкурувала з реплікацією сховища.

Замінити корпоративні бекап‑суїти: вирішіть, потрібна app‑консистентність чи ні

Proxmox Backup Server (PBS) добре робить те, для чого створений: швидкі дедуплікаційні інкрементальні бекапи з тестуванням відновлення. Багато сторонніх інструментів також підтримують Proxmox/KVM.

Справжнє рішення: чи потрібні вам application‑consistent snapshot (VSS, зупинка бази даних тощо) або достатньо crash‑consistent з процедурами відновлення на рівні додатка? Якщо вдавати, що crash‑consistent підходить для всього, перше серйозне відновлення бази навчить керівництво.

Замінити «vCenter як джерело істини»: оберіть нове

У багатьох організаціях vCenter стає фактичною CMDB. Це не комплімент, але так буває.

Що працює: оберіть одну систему як власника інвентарю (CMDB, модель на кшталт NetBox, навіть Git) і нехай Proxmox буде шаром виконання, а не джерелом істини.

Що не працює: нехай істина дрейфує між таблицями, UI Proxmox і чиїмись спогадами.

Один надійний вислів для чесного погляду

«Надія — це не стратегія.» — General Gordon R. Sullivan

Практичні завдання: команди, виводи та рішення

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

Завдання 1: Перевірити членство кластера й кворум

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-pve
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Sun Dec 28 10:12:08 2025
Quorum provider:  corosync_votequorum
Nodes:            5
Node ID:          0x00000003
Ring ID:          1.54
Quorate:          Yes

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

Значення: «Quorate: Yes» означає, що кластер погоджено щодо членства; можна безпечно виконувати зміни на рівні кластера.

Рішення: Якщо немає кворуму, припиніть робити щось «креативне». Спочатку виправте corosync‑з’єднання, досяжність вузлів або ризик split‑brain.

Завдання 2: Перевірити стан лінків corosync (втрати пакетів і затримки)

cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 3
RING ID 0
    id    = 10.10.10.13
    status= ring 0 active with no faults
RING ID 1
    id    = 10.10.11.13
    status= ring 1 active with no faults

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

Рішення: Якщо кільце показує помилки, ставте це як інцидент продакшн. Флапінг кластера — шлях до «випадкових» HA‑подій VM.

Завдання 3: Подивитися, які вузли готові та які версії вони запускають

cr0x@server:~$ pvecm nodes
Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 pve01
0x00000002          1 pve02
0x00000003          1 pve03
0x00000004          1 pve04
0x00000005          1 pve05

Значення: Якщо вузол зникає тут, але все ще відповідає на ping, можливо, проблеми з corosync, а не відмова хоста.

Рішення: Не починайте технічне обслуговування, поки членство не стабільне кілька хвилин.

Завдання 4: Підтвердити затримку сховища на рівні ОС (ZFS або загальний IO)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.12-4-pve (pve03)  12/28/2025  _x86_64_ (64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.12    0.00    2.01    8.45    0.00   83.42

Device            r/s     w/s   rKB/s   wKB/s  await  svctm  %util
nvme0n1         220.0   410.0  8800.0 16400.0  3.20   0.15  9.60
sdg              10.0    80.0    90.0  1200.0 25.40   1.10  8.90

Значення: await — це end‑to‑end затримка. Один повільний пристрій може бути вузьким місцем для ZFS mirrors/RAIDZ vdevs або журналів Ceph OSD.

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

Завдання 5: Перевірити стан пулу ZFS та лічильники помилок

cr0x@server:~$ zpool status -x
all pools are healthy

Значення: Жодних відомих відмов пристроїв або помилок контрольних сум.

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

Завдання 6: Перевірити стиснення ZFS і тиск по місцю

cr0x@server:~$ zfs get -o name,property,value -r compression,compressratio,used,avail rpool
NAME   PROPERTY       VALUE
rpool  compression    zstd
rpool  compressratio  1.62x
rpool  used           3.41T
rpool  avail          820G

Значення: Стиснення ввімкнено і ефективне; доступного місця стає мало.

Рішення: При ~80–85% використання пулу плануйте розширення. ZFS під тиском місця стає «чому все повільно?»

Завдання 7: Перевірити стан кластеру Ceph (якщо ви його використовуєте)

cr0x@server:~$ ceph -s
  cluster:
    id:     3a9b5d4a-6f3c-4ed7-a4a5-1f2cc1dcb8b2
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 31 sec

  services:
    mon: 3 daemons, quorum pve01,pve02,pve03 (age 2d)
    mgr: pve01(active, since 2d), standbys: pve02
    osd: 15 osds: 15 up (since 2d), 15 in (since 2d)

  data:
    pools:   3 pools, 256 pgs
    objects: 1.20M objects, 4.6 TiB
    usage:   14 TiB used, 28 TiB / 42 TiB avail
    pgs:     256 active+clean

Значення: «slow ops» зазвичай означає затримку: диски, мережа або перевантажений OSD.

Рішення: Сприймайте slow ops як інцидент сховища. «Випадкові паузи» VM часто ведуть сюди.

Завдання 8: Визначити, який демон Ceph працює неправильно

cr0x@server:~$ ceph health detail
HEALTH_WARN 1 slow ops, oldest one blocked for 31 sec
[WRN] SLOW_OPS: 1 slow ops, oldest one blocked for 31 sec, daemons [osd.7] have slow ops.

Значення: У вас підозрюваний: osd.7.

Рішення: Перевірте затримку дисків, CPU steal, помилки NIC на цьому хості. Не перезапускайте балансування сліпо.

Завдання 9: Перевірити стан bridge/VLAN/bond на вузлі

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:fd:fe:aa:bb:01
eno2             UP             3c:fd:fe:aa:bb:02
bond0            UP             3c:fd:fe:aa:bb:01
vmbr0            UP             3c:fd:fe:aa:bb:01
vmbr1            UP             3c:fd:fe:aa:bb:01

Значення: Лінки і бриджі підняті. Це не доводить, що VLAN‑тегування правильне, але виключає «інтерфейс упав».

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

Завдання 10: Перевірити стан bond і активні лінії

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eno1
MII Status: up
Actor Churn State: none
Partner Mac Address: 24:5a:4c:11:22:33

Slave Interface: eno2
MII Status: up
Actor Churn State: none
Partner Mac Address: 24:5a:4c:11:22:33

Значення: LACP піднятий на обох лініях, churn немає. Добре.

Рішення: Якщо один slave флапає, очікуйте періодичні таймаути сховища і дивні явища corosync. Спочатку виправляйте фізичну мережу, потім налаштовуйте Linux.

Завдання 11: Перевірити, чи VMs відчувають ballooning або тиск пам’яті

cr0x@server:~$ qm list
      VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID
       101 api-prod-01          running    8192              80.00 22011
       114 db-prod-02           running   32768             500.00 18433
       130 kafka-03             running   16384             200.00 27190

Значення: Базовий інвентар VM і поточний стан.

Рішення: Якщо «running» VM повільна, підтвердіть запас пам’яті хоста; не робіть висновків щодо гостя одразу.

Завдання 12: Перевірити використання пам’яті хоста і активність swap

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           251Gi       198Gi       8.2Gi       2.1Gi        45Gi        41Gi
Swap:           16Gi       3.5Gi        12Gi

Значення: Swap використовується. Це може бути нормою або попередженням залежно від тренду і чутливості до затримок.

Рішення: Якщо swap зростає під час піку і IO‑затримки зростають, зменшіть overcommit, вимкніть ballooning для критичних завдань або додайте RAM.

Завдання 13: Виявити CPU steal і змагання за планувальник

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 6  0  356812 856432  9012 328912    0    0   120   450 1200 4100 18  6 70  6  0
 9  0  356812 844120  9012 329500    0    0   140   520 1350 4700 22  7 64  7  0
 7  0  356812 838900  9012 329910    0    0   160   610 1420 4900 25  6 60  9  0
 5  0  356812 834220  9012 330020    0    0   130   480 1280 4300 19  6 68  7  0
 6  0  356812 830440  9012 330120    0    0   110   460 1250 4200 17  5 72  6  0

Значення: wa вказує на IO wait. Якщо він підскакує — CPU чекає на сховище. Якщо підскакує st (в nested virt/cloud), CPU викрадають.

Рішення: Високий IO wait — це затримка сховища; припиніть налаштовувати CPU governors і дивіться на диски/мережу.

Завдання 14: Підтвердити синхронізацію часу (corosync і Ceph це люблять)

cr0x@server:~$ timedatectl
               Local time: Sun 2025-12-28 10:15:44 UTC
           Universal time: Sun 2025-12-28 10:15:44 UTC
                 RTC time: Sun 2025-12-28 10:15:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Значення: Годинник синхронізований.

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

Завдання 15: Інспектувати стан HA manager і відмови

cr0x@server:~$ ha-manager status
quorum OK
master pve02 (active, Wed Dec 24 11:02:14 2025)
lrm pve01 (active, Wed Dec 24 11:03:10 2025)
lrm pve02 (active, Wed Dec 24 11:02:14 2025)
lrm pve03 (active, Wed Dec 24 11:03:05 2025)
lrm pve04 (active, Wed Dec 24 11:03:02 2025)
lrm pve05 (active, Wed Dec 24 11:03:00 2025)
service vm:114 (started)

Значення: Quorum OK, HA master обрано, локальні менеджери ресурсів активні.

Рішення: Якщо HA флапає, перевірте corosync перш за все. HA залежить від здоров’я кластера.

Завдання 16: Конвертувати диск VMware у формат, дружній Proxmox

cr0x@server:~$ qemu-img convert -p -f vmdk -O qcow2 disk-flat.vmdk vm-101-disk-0.qcow2
    (100.00/100%)

Значення: Диск конвертовано. qcow2 підтримує снапшоти; raw часто швидший. Обирайте усвідомлено.

Рішення: Для баз даних з високим IO віддавайте перевагу raw на ZFS zvol або Ceph RBD; для загальних навантажень qcow2 підійде.

Швидкий план діагностики: знайдіть вузьке місце перед тим, як гадати

Це чек‑ліст на перші 10 хвилин, коли хтось каже: «Proxmox повільний» або «VM підвисає». Швидкість важлива. Також его дорого коштує.

Спочатку: здоров’я кластера й кворум (не діагностуйте привиди)

• Перевірте кворум: pvecm status → якщо немає кворуму, припиніть і виправте членство.
• Перевірте кільця corosync: corosync-cfgtool -s → шукайте помилки.
• Перевірте HA: ha-manager status → якщо HA нестабільна, ставте це як кластерну проблему.

По‑друге: затримки сховища (більшість «проблем гіпервізора» — про сховище)

• Local/ZFS: iostat -xz 1 3, zpool status, заповненість пулу.
• Ceph: ceph -s, ceph health detail для slow ops і підозрілих OSD.
• Картування симптомів: паузи VM, високий IO wait, «застряглі» бекапи, таймаути гостя.

По‑третє: мережа (бо сховище і кворум від неї залежать)

• Стан лінків: ip -br link, стан bond у /proc/net/bonding/*.
• Помилки: ethtool -S (не показано вище, але його слід використовувати) для CRC, дропів, ресетів.
• Сегментація: corosync і трафік сховища не повинні боротися з VM east‑west, якщо вам не подобається непередбачувана затримка.

Далі: навантаження обчислень

• Пам’ять: free -h, налаштування ballooning, тренди росту swap.
• CPU: vmstat, прив’язка CPU гостя тільки якщо є обґрунтування.
• Журнали ядра: journalctl -k для скидів драйверів і проблем з IOMMU.

Правило великого пальця: якщо не можете довести гіпотезу однією командою і одним фрагментом логу, ви ще вгадайці.

Три короткі історії з корпоративних рейдів

Інцидент через хибне припущення: «Це ж просто як vMotion»

Середня SaaS‑компанія мігрувала набір аплікаційних VM з vSphere на Proxmox під час ліцензійного дефіциту. У них було спільне NFS‑сховище і виділена 10GbE мережа. У vSphere вони роками робили live maintenance: евакуація хоста, патч, перезавантаження, далі. М’язова пам’ять сильна.

На Proxmox вони ввімкнули live migration і зробили планову евакуацію вузла. Для безстанового шару це спрацювало. Потім вони спробували базу даних. Міграція почалась, просувалась, а потім уповільнилася до повзання. Аплікація почала таймаути. На чергуванні вирішили, що це «нормальна повільність міграції» і дали їй продовжуватися.

Це не було нормою. В базі був віртуальний NIC на бриджі, який ділив пропускну здатність із міграційним трафіком, бо «мережа міграції» була не ізольована: VLAN на тому ж bond без QoS і політики на комутаторі. Під навантаженням потік міграції стиснув трафік реплікації бази, що спричинило повтори, збільшення IO, більше брудної пам’яті і ще повільнішу міграцію. Замкнене коло.

Виправлення було не героїчним. Вони відокремили трафік міграції на власну пару NIC (або хоча б ввели QoS), обмежили пропускну здатність міграцій і перестали мігрувати stateful VM у періоди пікових записів. Також оновили ранбук: «Live migration — це інструмент, а не ритуал.»

Хибне припущення було тонким: вони думали, що «live migration» — бінарна функція. Насправді це контракт продуктивності з вашою мережею і сховищем. vSphere робив більше за ручку. Proxmox показав фізику такою, якою вона є.

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

Велика внутрішня IT‑команда перенесла флот Windows і Linux VM на Proxmox з ZFS на кожному вузлі і асинхронною реплікацією між вузлами як «бідний чоловік‑shared storage». Дизайн був нормальний. Реалізація — амбіційна.

Хтось вирішив, що оскільки ZFS‑стиснення майже безкоштовне (часто так), потрібно увімкнути найсильніше стиснення і реплікувати все кожні п’ять хвилин. Кластер мав CPU, тож чому б ні? Ввімкнули zstd на високому рівні для dataset, часту реплікацію і пораділи за сучасність.

Через два тижні служба підтримки помітила шаблон: випадкова повільність VM в робочі години. Нічого «впало», просто повільно. Графіки сховища показували періодичні спайки. Мережеві графіки теж.

Корінь проблеми — не само стиснення. А поєднання агресивної частоти реплікацій з навантаженнями, що мають сплески записів. Реплікація створювала періодичні IO‑штормі. Високий рівень стиснення додавав навантаження на CPU під час цих штормів. І оскільки реплікації синхронізовані за годинником, кілька вузлів одночасно піківали. Вони створили розподілену «thundering herd».

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

Скучно, але правильно, що врятувало день: «правила кворуму, OOB‑доступ і дисципліноване обслуговування»

Регульована компанія працювала кластер Proxmox у двох шафах у тій самій залі. Не гламурно. Їхній SRE‑відділ наполягав на трьох речах, на які ніхто не хотів виділяти час: виділена мережа corosync з надлишковими комутаторами, документований out‑of‑band доступ для кожного вузла і суворий rolling maintenance з «проверкою кворуму» як воротами.

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

Оскільки їхня мережа corosync була окрема і надлишкова, кластер не флапнув. HA не почала панічно мігрувати VM. Це вже запобігало каскаду. Далі out‑of‑band доступ дозволив отримати логи і підтвердити помилки лінків навіть коли частина мережі поводилася нестабільно. Вони ізолювали комутатор, перемкнули лінки і замінили прошивку контрольовано.

Нічого з цього не вражало на демо. Але це запобігло простою. Пост‑інцидентний огляд був майже нудним — і це найвища похвала для операційної команди.

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

1) Симптом: випадкові паузи VM, поведінка типу «stun», таймаути

Корінь: затримка сховища (Ceph slow ops, ZFS пул майже повний, один повільний диск або мережні дропи на VLAN сховища).

Виправлення: перевірити ceph -s/ceph health detail або iostat і заповненість пулу; розділити трафік сховища; замінити відмовні диски; тримати ZFS нижче ~80–85%.

2) Симптом: HA постійно перезапускає сервіси або мігрує VM несподівано

Корінь: нестабільність corosync, втрата пакетів або флапінг кворуму.

Виправлення: перевірити pvecm status і corosync-cfgtool -s; поставити corosync на виділену мережу; виправити LACP і проблеми на комутаторах.

3) Симптом: live migration повільна або періодично не вдається

Корінь: міграційний трафік конкурує з VM/сховищем; відсутнє спільне сховище; занадто високий rate dirty memory; проблеми сумісності CPU.

Виправлення: виділити мережу для міграцій або включити QoS; планувати міграції; знизити обсяг записів під час міграцій; стандартизувати сімейство CPU або використовувати сумісні типи CPU.

4) Симптом: бекапи непослідовні, відновлення «сюрпризно погане»

Корінь: покладаєтесь на crash‑consistent снапшоти для додатків, які потребують quiesce; сплеск снапшотів; відсутність тестів відновлення.

Виправлення: визначити вимоги application‑consistency; використати guest agents де застосовно; встановити TTL снапшотів; тестувати відновлення щомісяця.

5) Симптом: мережа працює для деяких VLAN, але не для інших

Корінь: невідповідність awareness VLAN бриджів, mismatch trunk на комутаторі або використання неправильної інтерфейсу для management vs VM трафіку.

Виправлення: перевірити конфігурацію Linux bridge, дозволені VLAN на транку комутатора і режим bond; за потреби робити packet capture.

6) Симптом: «UI Proxmox повільний», але VM в порядку

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

Виправлення: перевірити навантаження і пам’ять вузла; підтвердити DNS‑резольв із вашої робочої станції і вузлів; перевірити timedatectl; стабілізувати трафік керування.

7) Симптом: продуктивність падає після «тюнінгу»

Корінь: передчасна оптимізація: агресивні налаштування ZFS, забагато реплікаційних задач, помилково підібрані PG у Ceph або прив’язка CPU без вимірів.

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

8) Симптом: апгрейд кластера викликає сюрпризи

Корінь: змішані конфігурації репозиторіїв, несумісні версії пакунків або оновлення без перевірки кворуму/стану HA.

Виправлення: стандартизувати репозиторії; робити rolling upgrades; гейтити на pvecm status і ha-manager status; мати доступ до консолі.

Контрольні списки / покроковий план

Покроковий план міграції (vCenter → Proxmox з мінімальною драмою)

1. Реальність інвентарю: перелік VM, типи ОС, режими завантаження (BIOS/UEFI), спеціальні пристрої, RDM‑подібні патерни, потреби GPU і вимоги app‑consistency.
2. Спочатку оберіть модель зберігання: Ceph vs shared array vs локальний ZFS+реплікація. Якщо вирішите пізно — перероблятимете все.
3. Спроектуйте мережі свідомо: мінімум відокремлені management, storage (якщо Ceph) і migration. Якщо фізично відокремити неможливо — застосуйте QoS і документуйте.
4. Побудуйте невеликий кластер Proxmox: не як лабораторну іграшку — використайте production‑подібні NIC, MTU, VLAN і сховище. Перевірте поведінку при відмові.
5. Визначте сумісність CPU: оберіть базову модель CPU для VM, якщо очікуєте міграції між різними хостами.
6. Вирішіть інструменти бекапу: PBS або сторонні; визначте RPO/RTO для кожного навантаження; погодьте з власниками додатків.
7. Побудуйте моніторинг до міграції: здоров’я вузлів, затримка сховища, помилки NIC і алерти на кворум/кластер. Якщо почекати — перший інцидент навчить всіх публічно.
8. Мігрируйте хвилями: почніть зі стателес сервісів, потім low‑risk stateful, найкритичніші stateful — останніми.
9. Короткочасно працюйте в двох системах: тримайте vSphere в режимі read‑only під час cutover; документуйте rollback шляхи.
10. Стандартизуйте шаблони: cloud‑init для Linux де можливо, однакові драйвери, QEMU guest agent і адекватні формати дисків.
11. Дотримуйтеся гігієни життєвого циклу: графік патчів, оновлення ядра, вирівнювання прошивок і вікна змін.
12. Проводьте вправи з відновлення: доведіть, що можете відновити «важку» VM (базу даних), а не лише disposable веб‑сервер.

Операційний чек‑ліст для здорового кластера Proxmox

• Кворум стабільний, кілька кілець corosync якщо можливо.
• Час синхронізований на всіх вузлах.
• Виділені або контрольовані мережі для storage/migration.
• ZFS пули не під близьким до повного; розклад scrub; обробка помилок дисків.
• Ceph: немає постійного HEALTH_WARN; slow ops — інциденти.
• Бекапи під моніторингом; відновлення тестуються; TTL для снапшотів встановлено.
• Rolling upgrades з документованим ранбуком і гейтом «stop if not quorate».

Поширені питання

1) Чи може Proxmox повністю замінити vCenter для підприємства?

Для багатьох підприємств — так, якщо під «замінити» ви маєте на увазі «надійно запускати і керувати віртуалізацією». Якщо ж потрібно «відтворити кожний vCenter‑плагінний робочий процес і політику» — ні. Плануйте додаткові інструменти для RBAC, CMDB і звітності про комплаєнс.

2) Який найближчий еквівалент vSphere HA?

Proxmox HA може перезапустити VM на інших вузлах і керувати пріоритетами. Це ефективно, коли corosync стабільний і сховище спільне (Ceph/NFS/iSCSI) або коли ви готові до іншого патерну відновлення для локального зберігання.

3) Який найуживаніший еквівалент DRS?

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

4) Використовувати Ceph чи ZFS?

Якщо вам потрібне спільне сховище і HA‑поведінка типу «VM може перезапуститися де завгодно з її диском», Ceph — нативний шлях для Proxmox, але він вимагає низької затримки мережі і однорідного заліза. Якщо цінуєте простоту й передбачувану локальну продуктивність — ZFS чудовий. Багато магазинів в продакшн використовують обидва: Ceph для загального, ZFS для латентнісно‑критичних робіт.

5) Чи потрібна окрема мережа для corosync?

Це не строго необхідно, але поводьтеся так, ніби вона потрібна. Corosync ненавидить втрати пакетів і jitter. Якщо corosync ділить переповнену мережу, нестабільність HA стане вашим новим хобі.

6) Як безпечно мігрувати VMware VM у Proxmox?

Стандартний шлях: експортуйте/конвертуйте диски (VMDK → qcow2/raw), відтворіть конфігурацію VM і перевірте режим завантаження й драйвери. Для великих флотів автоматизуйте конвертацію і генерацію конфігів. Завжди тестуйте «дивні» VM: UEFI, спеціальні NIC‑драйвери, бази даних і все з ліцензуванням, прив’язаним до віртуального обладнання.

7) Чи Proxmox Backup Server придатний для продакшну?

Так, для багатьох середовищ. Він швидкий, дедуплікує і оперційно адекватний. Справжнє питання не в «чи PBS хороший?», а в «чи потрібні вам application‑consistent бекапи і чи ви тестуєте відновлення?» Інструменти не замінюють дисципліну.

8) А RBAC і мульти‑тенантність?

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

9) Яка найбільша прихована вартість міграції з‑під vCenter?

Переобучення персоналу та відбудова «інституційної м’язової пам’яті»: моніторинг, incident response, бекап/відновлення і мережево‑сховищне проектування. Заміна гіпервізора — найпростіша частина.

10) Який найбільший ризик?

Недооцінити, наскільки дефолти vCenter захищали вас від вашої власної організації. У Proxmox ви цілком можете побудувати надійну платформу — але потрібно вибрати і впровадити стандарти.

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

1. Напишіть «definition of done» для міграції: стабільний кворум, поведінка HA, RPO/RTO бекапів і покриття моніторингу.
2. Обирайте сховище свідомо (Ceph vs ZFS vs масив) і задокументуйте домени відмов, які ви проєктуєте.
3. Розгорніть пілот з 3–5 вузлів з production‑подібною мережею. Перевірте: втрата вузла, втрата комутатора, втрата диска і процедури відновлення.
4. Створіть ранбук міграції, що включає: кроки конвертації, перевірки, шляхи відкату і «умови зупинки» (не кворут, Ceph health WARN тощо).
5. Інструментуйте базове спостереження: алерти на кворум, slow ops Ceph, стан пулу ZFS, помилки NIC, збої бекапів і нагадування про тестування відновлень.
6. Проведіть вогневий дріл: симулюйте відмову вузла і виміряйте час відновлення і час до розуміння. Якщо ви не можете пояснити інцидент за 15 хвилин — покращуйте спостереження.

Замінюйте vCenter на Proxmox, коли хочете платформу, яку можете осмислено підтримувати під стресом. Не робіть цього, бо хтось пообіцяв «те саме, але дешевше». Це не те саме. Але це може бути краще — якщо ви будуєте його свідомо.