+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Кластер PVE постоянно ломается., Proxmox Виртуальная Среда

ThinkPrivacy

Guest

22.09.2016 19:55:00

Сегодня я просто готов вырвать себе волосы — переустановил Proxmox на трёх разных серверах уже около четырёх раз на каждом, и вот в чём дело: он не только не работает, но и назад откатиться тоже никак не получается. У меня есть три сервера (ноды) с Proxmox версии 4.2-23. Все три сервера подключены к сети RPN, а также имеют публичные IP.

На первом сервере я ввожу:
Code: # pvecm create tpc1
Corosync Cluster Engine Authentication key generator.
Gathering 1024 bits for key from /dev/urandom.
Writing corosync key to /etc/corosync/authkey.

На втором и третьем сервере я ввожу:
Code: # pvecm add 10.91.150.134
The authenticity of host '10.91.150.134 (10.91.150.134)' can't be established.
ECDSA key fingerprint is ########################################.
Are you sure you want to continue connecting (yes/no)? yes
root@10.91.150.134's password:
copy corosync auth key
stopping pve-cluster service
backup old database
Job for corosync.service failed. See 'systemctl status corosync.service' and 'journalctl -xn' for details.
waiting for quorum...

10.91.150.134 — это RPN IP первого сервера, где я создавал кластер. И вот тут система зависает. Я больше не могу попасть в веб-интерфейс на серверах 2 и 3 и вынужден заново устанавливать Proxmox.

Мультикаст включён на RPN:
Code: # ifconfig eth1 | grep MTU
UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1

Вывод systemctl status corosync.service:
Code: # systemctl status corosync.service
● corosync.service - Corosync Cluster Engine
Loaded: loaded (/lib/systemd/system/corosync.service; enabled)
Active: failed (Result: exit-code) since Thu 2016-09-22 19:38:07 CEST; 19min ago
Process: 11271 ExecStart=/usr/share/corosync/corosync start (code=exited, status=1/FAILURE)

Sep 22 19:37:06 pmn2 corosync[11280]: [QB ] server name: cmap
Sep 22 19:37:06 pmn2 corosync[11280]: [SERV ] Service engine loaded: corosync configuration service [1]
Sep 22 19:37:06 pmn2 corosync[11280]: [QB ] server name: cfg
Sep 22 19:37:06 pmn2 corosync[11280]: [SERV ] Service engine loaded: corosync cluster closed process group service v1.01 [2]
Sep 22 19:37:06 pmn2 corosync[11280]: [QB ] server name: cpg
Sep 22 19:37:06 pmn2 corosync[11280]: [SERV ] Service engine loaded: corosync profile loading service [4]
Sep 22 19:37:06 pmn2 corosync[11280]: [QUORUM] Using quorum provider corosync_votequorum
Sep 22 19:37:06 pmn2 corosync[11280]: [QUORUM] Quorum provider: corosync_votequorum failed to initialize.
Sep 22 19:37:06 pmn2 corosync[11280]: [SERV ] Service engine 'corosync_quorum' failed to load for reason 'configuration error: nodelist or quorum.expected_votes must be configured!'
Sep 22 19:38:07 pmn2 corosync[11271]: Starting Corosync Cluster Engine (corosync): [FAILED]
Sep 22 19:38:07 pmn2 systemd[1]: corosync.service: control process exited, code=exited status=1
Sep 22 19:38:07 pmn2 systemd[1]: Failed to start Corosync Cluster Engine.
Sep 22 19:38:07 pmn2 systemd[1]: Unit corosync.service entered failed state.

Вывод journalctl -xn:
Code: # journalctl -xn
-- Logs begin at Thu 2016-09-22 15:57:08 CEST, end at Thu 2016-09-22 19:59:29 CEST. --
Sep 22 19:59:17 pmn2 pmxcfs[11262]: [dcdb] crit: cpg_initialize failed: 2
Sep 22 19:59:17 pmn2 pmxcfs[11262]: [status] crit: cpg_initialize failed: 2
Sep 22 19:59:23 pmn2 pmxcfs[11262]: [quorum] crit: quorum_initialize failed: 2
Sep 22 19:59:23 pmn2 pmxcfs[11262]: [confdb] crit: cmap_initialize failed: 2
Sep 22 19:59:23 pmn2 pmxcfs[11262]: [dcdb] crit: cpg_initialize failed: 2
Sep 22 19:59:23 pmn2 pmxcfs[11262]: [status] crit: cpg_initialize failed: 2
Sep 22 19:59:29 pmn2 pmxcfs[11262]: [quorum] crit: quorum_initialize failed: 2
Sep 22 19:59:29 pmn2 pmxcfs[11262]: [confdb] crit: cmap_initialize failed: 2
Sep 22 19:59:29 pmn2 pmxcfs[11262]: [dcdb] crit: cpg_initialize failed: 2
Sep 22 19:59:29 pmn2 pmxcfs[11262]: [status] crit: cpg_initialize failed: 2

На узлах нет контейнеров или виртуальных машин, всё свежеустановленное, единственное, что я изменил — установил sudo, добавил своего пользователя в группу sudo и настроил eth1 для RPN на каждом сервере.

Это меня просто сводит с ума и отнимает кучу времени. Кто-нибудь знает, как это исправить или хотя бы как снова запустить второй и третий сервер после неудачного pvecm add, чтобы не тратить время на постоянную переустановку? Заранее спасибо!

mathx

Guest

17.01.2017 06:26:00

Вспоминаю. Та же проблема. Очень серьёзная — отсутствие работы multicast на короткое время вызывает полный сбой веб-интерфейса и требует переустановки. Я точно не уверен, что multicast был заблокирован, но я изменил кое-что, что могло это разрешить. Теперь вижу multicast-трафик от главного узла на вторичном: 00:30:16.437846 IP xx.xx.xxx.248.5404 > 239.192.103.27.5405: UDP, длина 136 — это видно на обоих узлах. (И я делал http://pve.proxmox.com/wiki/Multicast_notes#Linux:_Enabling_Multicast_querier_on_bridges на главном/первом узле, потому что думаю, что коммутатор по умолчанию этого не поддерживает.) Я прервал (^C) зависание с ожиданием кворума и попробовал снова выполнить pvecm add, но получил: # pvecm add x.x.x.248 не удаётся создать общую базу ssh-ключей '/etc/pve/priv/authorized_keys' — ключ аутентификации уже существует. Конечно, я не могу создать /etc/pve/priv, так как это смонтировано как кластерная директория. Сейчас перезагружаюсь, чтобы проверить, поможет ли это... Перезагрузка помогла немного: теперь я вижу второй узел в интерфейсе первого, и там зелёная галочка. Однако, при клике на диски узла пытается загрузиться окно со сводкой/статусом, и крутится индикатор до сообщения «сбой связи». Есть ли способ полностью удалить конфигурацию кластера и начать заново на случай, если multicast изначально не работал при старте?

mathx

Guest

17.01.2017 16:30:00

Я изначально собирался всё равно переустанавливать оба узла, поэтому начал ковыряться с файлами /etc/pve/priv auth keys и known_hosts, а также удалил corosync.conf на одном из узлов и заново делал pvecm re-create. После нескольких перезагрузок, ручной очистки authkeys и принудительного добавления через pvecm add -f я получил разные ошибки, вроде «transport endpoint not connected», которые относились к директории priv (это, разумеется, общий монтируемый каталог). Но сейчас всё вроде работает. Не могу сказать точно, что именно помогло.

Вопрос теперь: какой тест можно провести, чтобы наверняка убедиться, что всё работает? (Я думаю, что установка контейнера с другого узла и последующая миграция — неплохой вариант.)

[EDIT: И это сработало. Думаю, всё в порядке.]

Хотелось бы всем рассказать, как я выкрутился из проваленного pvecm create/setup с multicast/querier, и как у меня теперь рабочий кластер, но не могу. Могу только сказать, что это возможно, если заодно убедиться, что multicast и querier на самом деле работают. На странице с настройками кластера стоит особо подчеркнуть требования к multicast — люди НИКАК не должны предполагать, что их сеть это поддерживает, даже если она без фаервола и открыта. Без корректного querier всё работать не будет. И хуже того — если запустите настройку кластера без работающего multicast, то попадёте в такую ловушку, из которой очень сложно выйти обратно к нормальной работе, фактически ломая все узлы.

mathx

Guest

23.08.2017 01:05:00

Лол, я вот только что забыл об этом и снова наступил на те же грабли. Кто-нибудь разобрался, как выйти и перезапустить? Хотя multicast querier включён на основном/первом узле. Так что я в замешательстве — почему таймаут при ожидании кворума. Может, проблема из-за того, что querier включён на обоих узлах? Казалось, что это так — отключение одного не помогло. Я вижу пакеты, исходящие с одного из узлов: 19:49:49.117635 IP 162.x.x.y.5404 > 239.192.95.45.5405: UDP, length 119, но на проводе другого узла таких пакетов нет. Думаю, проблема связана с IGMP.

Причём никаких IGMP-пакетов вообще не видно на vmbr0 (или vmbr1, vmbr2, на других частных сетях, где у меня контейнеры и виртуальные машины) с мастер-узла, где изначально создавал кластер.

Статус на этом узле такой:
Version: 6.2.0
Config Version: 2
Cluster Name: hc-nplus
Cluster Id: 24525
Cluster Member: Yes
Cluster Generation: 4
Membership state: Cluster-Member
Nodes: 1
Expected votes: 1
Total votes: 1
Node votes: 1
Quorum: 1
Active subsystems: 5
Flags:
Ports Bound: 0
Node name: charon
Node ID: 1
Multicast addresses: 239.192.95.45
Node addresses: 127.0.0.1

Статус на другом узле примерно такой же, за исключением того, что node addresses — реальный IP, Node Id = 2, и Quorum: 2, activity blocked.

На узле, который пытается присоединиться, где я вижу IGMP, команда ip maddr показывает, что он сам добавился в multicast-группу:
vmbr0: inet 239.192.95.45

Но такой группы нет на мастер-узле/узле, который создавал кластер.

mathx Guest	#5 0 13.09.2017 05:59:00 напоминаю... застрял в этой ситуации, даже веб-консоль не запускается, сервер фактически полностью заблокирован для PVE-операций

A71

Guest

22.02.2018 14:30:00

Я столкнулся с точно такой же ситуацией, что и ты, с версией 5.1 (proxmox-ve_5.1-3.iso). Предположил, что мультикаст включён, и сломал второй узел. Попробую вернуть рабочую конфигурацию, так как в моём случае установка требует изменений в сети (использую VLAN, пакет, который, кстати, НЕ входит в стандартную установку)… так что простая установка занимает пару часов. Напишу здесь отзывы.

A71 Guest	#7 0 22.02.2018 16:29:00 Отлично, что нашли проблему! Проверьте файл /etc/hosts! Потому что сервера, которые я использую, требуют продвинутой сетевой настройки (как указано на странице https://pve.proxmox.com/wiki/Proxmox_VE_4.x_Cluster#Re-installing_a_cluster_node в разделе "Переустановка узла": при первой установке Proxmox не должен быть включён LACP для доступа к сети). Я также использую VLAN для управляющей сети, а пакет vlan в Debian по умолчанию не установлен. Поэтому на первом этапе сетевая настройка временная. Вот почему у меня был неправильный файл /etc/hosts на втором узле. Не спрашивайте меня почему — на первом узле он был обновлен корректно... Я тоже (как, видимо, и многие другие) делал свой первый "pvecm add node1" с node2 при неработающем мультикасте (или виноват был уже /etc/hosts?). Команда: pvecm add node1 Подлинность хоста 'node1 (10.10.10.101)' не может быть установлена. Отпечаток ключа ECDSA: SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Вы уверены, что хотите продолжить подключение (yes/no)? yes root@node1s password: копирую ключ аутентификации corosync останавливаю службу pve-cluster делаю резервную копию базы данных Job for corosync.service failed because the control process exited with error code. See "systemctl status corosync.service" and "journalctl -xe" for details. ожидание кворума... Вот последствия неправильного файла /etc/hosts на втором узле (даже если всё становится понятно, когда поймёшь, как это работает, для новичка — это совсем не очевидно): На node2: service corosync status <=> failed <=> /etc/pve/corosync.conf доступен только для чтения corosync[2138]: ошибка [SERV ] Сервис 'corosync_quorum' не загрузился из-за ошибки в конфигурации: nodelist или quorum.expected_vote pvecm add node1 не может создать общую SSH-базу ключей '/etc/pve/priv/authorized_keys', выявлены следующие ошибки: * ключ аутентификации '/etc/corosync/authkey' уже существует * конфигурация кластера '/etc/pve/corosync.conf' уже существует pvecm add node1 --force не может создать общую SSH-базу ключей '/etc/pve/priv/authorized_keys' кластер не готов — нет кворума? невозможно добавить узел: команда завершилась неудачей (ssh node1 -o BatchMode=yes pvecm addnode node2 --force 1) pvecm nodes Невозможно инициализировать сервис CMAP pvecm status Невозможно инициализировать сервис CMAP Как только я исправил /etc/hosts на node2, мне удалось запустить рабочий кластер просто перезапустив службу corosync: Команды: service corosync restart service corosync status => активен corosync[23674]: [QUORUM] Участники[1]: 2 corosync[23674]: [MAIN ] Завершена синхронизация сервиса, готов к работе. corosync[23674]: notice [TOTEM] Сформировано новое членство (10.10.10.101:12). Присоединился участник: 1 corosync[23674]: [QUORUM] Этот узел в составе основного компонента и готов предоставлять сервис. corosync[23674]: [QUORUM] Участники[2]: 1 2 Надеюсь, это поможет!

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры