Proxmox — это дистрибутив, предназначенный для виртуализации и контейнеризации на базе Debian Linux.
Когда потребности превышают отвечающий за все железный сервер, но еще недостаточно большой для использования Kubernetes, на помощь приходят различные решения, позволяющие управлять кластером из нескольких хостов, организовывать High Availability, репликацию и централизованное резервное копирование контейнеров и виртуализаций. техника. Proxmox является одним из них.
Пользуемся уже больше двух лет, очень довольны: очень многое упрощает: нарезка и резервирование ресурсов, живая миграция (только виртуальные машины qemu), централизованный сбор метрик (без необходимости подгонять экспортер/агент в каждом госте), управление (через WebUI, api и ssh).
Наша сеть выросла с трех серверов до дюжины, а количество хостов Proxmox в настоящее время увеличилось с нуля до восьми. Но иногда и ломается.
Contents
Что может пойти не так с Proxmox?
На самом деле много. Сетевые крепления, коросинк, новый замок…
Некоторые неисправности потребуют ручного вмешательства, другие устраняются самостоятельно. Некоторые самоисправления довольно неприятным способом, называемым ограждением, особенно неприятным, если затронутая служба не имеет собственного кластера. Другие сбои происходят только внутри кластера и никогда на одном хосте, другие наоборот.
Отказы одного хоста (узлы)
запертый замок
Проксмокс часто повесить замок на контейнере или ВМ — в интерфейсе это отображается, собственно, значком замка на соответствующем госте. Изменение конфигурации, удаление бэкапа, развертывание/клонирование/миграция — каждая из этих операций блокирует блокировку и обратная команда не всегда выполняется корректно.
Проблема в том, что застрявшая блокировка препятствует выполнению других операций, для которых требуется блокировка.
К счастью, им легко управлять. нужно сделать
pct unlock <CTid>для контейнеровqm unlock <VMid>для виртуальных машин
…на соответствующем хосте Proxmox
Критичность: низкая
Этот тип сбоя затрагивает только одного гостя и не влияет на его работу.
Сбой NAS
Как правило, это определяется по значку со знаком вопроса на накопителе. Proxmox постоянно пытается смонтировать хранилище, если оно включено в конфигурации кластера для соответствующего хоста, но не пытается размонтировать зависшее хранилище.
Легко решить:umount -nlf <mountpoint>
Критичность: от низкой до высокой
В зависимости от типа хранилища и его назначения, этот сбой может быть совершенно некритичным (установочные образы и образы контейнеров), и наоборот, если, например, ваше резервное хранилище или nfs-шара с запущенными контейнерами дает сбой выполнения.
Отказ внутренних служб самого Proxmox
В интерфейсе это выглядит как вопросительные знаки над самим хостом, его гостями и его репозиториями. В таком состоянии хост может оставаться сколь угодно долго даже в кластере, но он будет полностью неработоспособен из веб-интерфейса, а попытка использования утилит Proxmox через консоль закончится таймаутом и/или блокировкой.
Лучший способ лечения – перезагрузиться через ssh или с помощью KVM-хоста.
Однако, если перезагрузка неприемлема, вы можете попробовать остановить и перезапустить службы Proxmox:
for s in pveproxy spiceproxy pvestatd pve-cluster corosync; do systemctl stop $s; done
for s in corosync pve-cluster pvestatd spiceproxy pveproxy; do systemctl stop $s; doneКритичность: средняя
Несмотря на полную невозможность управления хостом через веб-интерфейс, запущенные гости продолжают работать.
Сбои на уровне кластера
Несоответствие между репликацией и конфигурацией высокой доступности
Proxmox может самостоятельно реплицировать гостей между хостами и перезапускать их в случае сбоя одного из хостов. Однако проверка непротиворечивости этих настроек не производится — таким образом, можно настроить репликацию на одном хосте и HA на другом, после чего попытка перемещения гостя закончится невозможностью его запуска.
Очень неприятно, но достаточно легко исправить, либо воссоздав конфигурацию HA, чтобы гость включал правильный хост, либо уничтожив и переместив его. /etc/pve/nodes/<host>/<lxc|qemu-server>/<guest>.conf в правильном месте (в правильной папке на смарт-хосте с действительной репликой) и запустить его вручную.
Критичность: катастрофическая
По сути, это бомба замедленного действия, ведущая к DoS. Вы не хотите это выяснить.
Ошибки репликации ZFS
Встречается раз-два в месяц перед обновлением до 7, обычно возникает, если каким-то образом хост с репликой и хост-источник разошлись в снапшотах: репликация не хранит только один снапшот для каждой цели репликации, и если снапшоты на источнике и цели не совпадают, репликация не удалась.
Отвечать — удалить соответствующий набор данных/том.
Критичность: катастрофическая
Еще одна версия предыдущей бомбы замедленного действия
Нет кворума в кластере
Состояние, которое не очень очевидно и трудно диагностируется. При этом гости продолжают работать (Proxmox обычно достаточно осторожен с гостями) там, где они были до того, как рухнул кворум, но любая работа с хостами или гостями становится невозможной включая разрешение через веб-интерфейс. Это происходит потому, что pmxcfs, хранение – и репликация между хостами! – настройки кластера, заходим в read-only при отсутствии кворума.
Это может быть связано со сбоем внутренних служб, сбоями в работе сети, неправильной настройкой брандмауэра или даже с длительной деградацией сети в недавнем прошлом.
Проверить кворум можно по ssh командой pvecm status. Обычный вывод будет содержать следующий блок:
Votequorum information
----------------------
Expected votes: 7
Highest expected: 7
Total votes: 7
Quorum: 4
Flags: QuorateЭто означает, что в кластере семь хостов (ожидаемые голоса), из которых минимум четыре необходимы для кворума (кворум), и сейчас все семь хостов активны (всего голосов), кворум достигнут (флаги: кворум). Если количество голосов меньше необходимого для кворума, кластер будет заблокирован до его восстановления.
Отвечать – в зависимости от обстоятельств. Однажды, после долгих проблем в сети хоста, нам помог перезапуск внутренних сервисов на хосте, который не имел отношения к наблюдаемому эффекту (который регулярно включался в кворум).
Критичность: катастрофическая
Все функции кластера перестают работать, задачи не запускаются, хосты с HA могут уйти в забор.
Сетевые ошибки
В целом Proxmox достаточно терпим к сетевым ошибкам, потерям пакетов и т.д., однако, если udp пакеты перестают нормально работать, события развиваются следующим образом:
- из-за потери пакетов нарушается обмен служебной информацией между узлами
- кворум восстановлен
corosync - один или несколько хостов теряют соединение с кластером и пытаются присоединиться
- если для хоста настроен HA, он выполняет жесткую перезагрузку
Это выглядит так:systemd[1]: rsyslog.service: Sent signal SIGHUP to main process 3087 (rsyslogd) on client request. systemd[1]: logrotate.service: Succeeded. systemd[1]: Finished Rotate log files. systemd[1]: logrotate.service: Consumed 1.067s CPU time. spiceproxy[1503847]: worker exit spiceproxy[3908]: worker 1503847 finished pveproxy[777811]: worker exit pveproxy[1280387]: worker exit pveproxy[888694]: error AnyEvent::Util: Runtime error in AnyEvent::guard callback: Can't call method "_put_session" on an undefined value at /usr/lib/x86_64-linux-gnu/perl5/5.32/AnyEvent/Handle.pm line 2259 during global destruction. pveproxy[3902]: worker 777811 finished pveproxy[3902]: worker 888694 finished pveproxy[3902]: worker 1280387 finished // Link to another host is garbled corosync[3813]: [KNET ] link: host: 8 link: 0 is down corosync[3813]: [KNET ] host: host: 8 (passive) best link: 0 (pri: 1) corosync[3813]: [KNET ] host: host: 8 has no active links corosync[3813]: [KNET ] rx: host: 8 link: 0 is up corosync[3813]: [KNET ] host: host: 8 (passive) best link: 0 (pri: 1) pveproxy[1643087]: got inotify poll request in wrong process - disabling inotify pveproxy[1643087]: worker exit // by corosync udp-packets disappearing corosync[3813]: [TOTEM ] Token has not been received in 5266 ms corosync[3813]: [KNET ] link: host: 1 link: 0 is down corosync[3813]: [KNET ] link: host: 8 link: 0 is down corosync[3813]: [KNET ] host: host: 1 (passive) best link: 0 (pri: 1) corosync[3813]: [KNET ] host: host: 1 has no active links corosync[3813]: [KNET ] host: host: 8 (passive) best link: 0 (pri: 1) corosync[3813]: [KNET ] host: host: 8 has no active links corosync[3813]: [TOTEM ] Token has not been received in 12169 ms corosync[3813]: [KNET ] rx: host: 1 link: 0 is up corosync[3813]: [KNET ] host: host: 1 (passive) best link: 0 (pri: 1) corosync[3813]: [KNET ] rx: host: 8 link: 0 is up corosync[3813]: [KNET ] host: host: 8 (passive) best link: 0 (pri: 1) corosync[3813]: [TOTEM ] Token has not been received in 19848 ms // Quorum disruption corosync[3813]: [QUORUM] Sync members[1]: 5 corosync[3813]: [QUORUM] Sync left[4]: 1 3 4 8 corosync[3813]: [TOTEM ] A new membership (5.13620) was formed. Members left: 1 3 4 8 corosync[3813]: [TOTEM ] Failed to receive the leave message. failed: 1 3 4 8 pmxcfs[3703]: [dcdb] notice: members: 5/3703 pmxcfs[3703]: [status] notice: members: 5/3703 // HA-hosts may do fencing there corosync[3813]: [QUORUM] This node is within the non-primary component and will NOT provide any services. corosync[3813]: [QUORUM] Members[1]: 5 // This cake is a lie, host is blocked corosync[3813]: [MAIN ] Completed service synchronization, ready to provide service. // Because of quorum absence pmxcfs[3703]: [status] notice: node lost quorum pmxcfs[3703]: [dcdb] crit: received write while not quorate - trigger resync pmxcfs[3703]: [dcdb] crit: leaving CPG group pve-ha-lrm[3910]: lost lock 'ha_agent_pve5_lock - cfs lock update failed - Operation not permitted pve-ha-lrm[3910]: status change active => lost_agent_lock // Quorum restoration corosync[3813]: [QUORUM] Sync members[5]: 1 3 4 5 8 corosync[3813]: [QUORUM] Sync joined[4]: 1 3 4 8 corosync[3813]: [TOTEM ] A new membership (1.13624) was formed. Members joined: 1 3 4 8 pmxcfs[3703]: [status] notice: members: 1/3409, 3/7179, 4/3856, 5/3703, 8/2042 pmxcfs[3703]: [status] notice: starting data syncronisation // Host unbloked for this moment corosync[3813]: [QUORUM] This node is within the primary component and will provide service. corosync[3813]: [QUORUM] Members[5]: 1 3 4 5 8 corosync[3813]: [MAIN ] Completed service synchronization, ready to provide service. pmxcfs[3703]: [status] notice: node has quorum pmxcfs[3703]: [status] notice: received sync request (epoch 1/3409/000000A6) pmxcfs[3703]: [status] notice: received sync request (epoch 1/3409/000000A7) pmxcfs[3703]: [dcdb] notice: start cluster connection // Problems persists pmxcfs[3703]: [dcdb] crit: cpg_join failed: 14 pmxcfs[3703]: [dcdb] crit: can't initialize service pve-ha-crm[3900]: lost lock 'ha_manager_lock - cfs lock update failed - Device or resource busy pve-ha-crm[3900]: status change master => lost_manager_lock // Another place for fencing pve-ha-crm[3900]: watchdog closed (disabled) pve-ha-crm[3900]: status change lost_manager_lock => wait_for_quorum pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pve-ha-crm[3900]: status change wait_for_quorum => slave pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pvescheduler[1634357]: replication: cfs-lock 'file-replication_cfg' error: got lock request timeout corosync[3813]: [TOTEM ] Token has not been received in 5396 ms pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 pmxcfs[3703]: [dcdb] crit: cpg_send_message failed: 9 corosync[3813]: [TOTEM ] Token has not been received in 12299 ms corosync[3813]: [TOTEM ] Retransmit List: b e corosync[3813]: [KNET ] link: host: 8 link: 0 is down corosync[3813]: [KNET ] host: host: 8 (passive) best link: 0 (pri: 1) corosync[3813]: [KNET ] host: host: 8 has no active links corosync[3813]: [KNET ] rx: host: 8 link: 0 is up corosync[3813]: [KNET ] host: host: 8 (passive) best link: 0 (pri: 1) // All thing became good for now pmxcfs[3703]: [status] notice: received all states corosync[3813]: [QUORUM] Sync members[5]: 1 3 4 5 8 corosync[3813]: [TOTEM ] A new membership (1.13630) was formed. Members corosync[3813]: [QUORUM] Members[5]: 1 3 4 5 8 corosync[3813]: [MAIN ] Completed service synchronization, ready to provide service. pmxcfs[3703]: [status] notice: cpg_send_message retried 1 times pmxcfs[3703]: [status] notice: all data is up to date pmxcfs[3703]: [status] notice: dfsm_deliver_queue: queue length 106 pmxcfs[3703]: [dcdb] notice: members: 1/3409, 3/7179, 4/3856, 5/3703, 8/2042 pmxcfs[3703]: [dcdb] notice: starting data syncronisation pmxcfs[3703]: [dcdb] notice: received sync request (epoch 1/3409/000000C2) pmxcfs[3703]: [dcdb] notice: received all states pmxcfs[3703]: [dcdb] notice: leader is 1/3409 pmxcfs[3703]: [dcdb] notice: synced members: 1/3409, 3/7179, 4/3856, 8/2042 pmxcfs[3703]: [dcdb] notice: waiting for updates from leader pmxcfs[3703]: [dcdb] notice: dfsm_deliver_queue: queue length 2 pmxcfs[3703]: [dcdb] notice: update complete - trying to commit (got 7 inode updates) pmxcfs[3703]: [dcdb] notice: all data is up to date pmxcfs[3703]: [dcdb] notice: dfsm_deliver_queue: queue length 2 pve-ha-lrm[3910]: successfully acquired lock 'ha_agent_pve5_lock' pve-ha-crm[3900]: successfully acquired lock 'ha_manager_lock' pve-ha-lrm[3910]: status change lost_agent_lock => active pve-ha-crm[3900]: watchdog active pve-ha-crm[3900]: status change slave => master // Bad again corosync[3813]: [TOTEM ] Token has not been received in 5363 ms corosync[3813]: [TOTEM ] Token has not been received in 12264 ms corosync[3813]: [QUORUM] Sync members[5]: 1 3 4 5 8 corosync[3813]: [TOTEM ] A new membership (1.1363c) was formed. Members corosync[3813]: [QUORUM] Members[5]: 1 3 4 5 8 corosync[3813]: [MAIN ] Completed service synchronization, ready to provide service. pvescheduler[1653190]: jobs: cfs-lock 'file-jobs_cfg' error: got lock request timeout pvescheduler[1653189]: replication: cfs-lock 'file-replication_cfg' error: got lock request timeout pveproxy[1641105]: proxy detected vanished client connection corosync[3813]: [TOTEM ] Token has not been received in 5399 ms corosync[3813]: [TOTEM ] Token has not been received in 12301 ms corosync[3813]: [QUORUM] Sync members[5]: 1 3 4 5 8 corosync[3813]: [TOTEM ] A new membership (1.13648) was formed. Members corosync[3813]: [QUORUM] Members[5]: 1 3 4 5 8 corosync[3813]: [MAIN ] Completed service synchronization, ready to provide service. corosync[3813]: [TOTEM ] Token has not been received in 5402 ms corosync[3813]: [KNET ] link: host: 8 link: 0 is down corosync[3813]: [KNET ] host: host: 8 (passive) best link: 0 (pri: 1) corosync[3813]: [KNET ] host: host: 8 has no active links corosync[3813]: [TOTEM ] Token has not been received in 12303 ms corosync[3813]: [KNET ] rx: host: 8 link: 0 is up corosync[3813]: [KNET ] host: host: 8 (passive) best link: 0 (pri: 1) corosync[3813]: [QUORUM] Sync members[5]: 1 3 4 5 8 corosync[3813]: [TOTEM ] A new membership (1.13654) was formed. Members corosync[3813]: [QUORUM] Members[5]: 1 3 4 5 8 corosync[3813]: [MAIN ] Completed service synchronization, ready to provide service.
Критичность: от высокой до катастрофической
Проблемы с сетью всегда неприятны, даже если они не вызывают деградации сервиса.
Обычные хосты будут пытаться переподключиться к кластеру до тех пор, пока не выиграют (и могут перейти в состояние отключения внутренней службы), а если хост настроен с высокой доступностью, вы увидите…
Фехтование (внезапный перезапуск)!
В общем, фехтование (фехтование, ограждение) работает для пользователя Проксмокс. Его задача, перед перезапуском (по правилам HA) гостя на другом хосте, состоит в том, чтобы обеспечить надежную изоляцию вышедшего из строя хоста и предотвратить конфликт двух экземпляров гостя за один и тот же адрес. запускать своих гостей до тех пор, пока не получит обновление текущей конфигурации кластера.
Это должно помочь, например, если ваша сетевая карта или порт в коммутаторе вышли из строя, или если вы обнаружили нестабильное обновление (с этим оборудованием).
Однако, если в самой сети есть проблемы, диагностика того, что происходит, может легко привести к путанице.
Происходит это (замыкание) при потере кворума на хостах, включенных в HA: каждый из этих хостов изо всех сил пытается переподключиться к кластеру. Если не удается подключиться к кластеру, эти узлы выполняют аппаратный перезапуск, принудительно отключая все запущенные на них службы.
В syslog похоже на внезапную перезагрузку без выключения: вот обычные рабочие логи, но сразу лог загрузки пропал.
Решение: Вылечить сеть, откатить последнее обновление, перенести кластерную сеть на физически отдельный контур — в зависимости от причины забора.
Особенно процесс заметен на виртуальных машинах: в физической консоли нет привычного лога выключения системы, сразу переключаемся на стартовую заставку, как бы нажимая ее Reset.
Критичность: катастрофическая, но стандартная
вместо несчастных случаев
Как и в любой сложной системе, важно знать три вещи: куда смотреть, что держать и на что нажимать. Но опыт, который дает это знание, как всегда, приходит сразу после того, как он был нужен…
Наличие без проблем, господа!
