Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    Чистое завершение работы всего кластера.

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Чистое завершение работы всего кластера., Proxmox Виртуальная Среда
     
    gurubert
    Guest
    #1
    0
    16.01.2023 15:21:00
    Привет, подскажи, пожалуйста, как правильно выключать целый PVE кластер, включая ресурсы HA? Руководство описывает только обслуживание отдельных узлов, но иногда нужно выключить всё. Мы заметили, что просто выключить все узлы недостаточно, потому что HA fencing перезагружает некоторые узлы, а потом они снова включаются.
     
     
     
    Moayad
    Guest
    #2
    0
    17.01.2023 08:30:00
    Привет! У нас открыт запрос на улучшение в Bugzilla [0]. И вот ещё обсуждение на нашем форуме по той же теме [1], может, вы найдёте больше информации от людей, которые поделились своим опытом. Однако, рекомендуем остановить все сервисы/ресурсы HA, pve-ha-crm и pve-ha-lrm, работающие на кластере, затем дождаться, пока все ресурсы HA не перестанут работать, после этого можно выдать команду отключения или из PVE GUI. [0] https://bugzilla.proxmox.com/show_bug.cgi?id=3839 [1] https://forum.proxmox.com/threads/shutdown-of-the-hyper-converged-cluster-ceph.68085/
     
     
     
    jkl
    Guest
    #3
    0
    04.07.2024 19:26:00
    Пожалуйста, раскрой эту тему подробнее. Улучшение Bugzilla, по сути, не имеет никакой активности. Пост на форуме, на который дается ссылка, размыт в плане рекомендаций. Ответ здесь довольно общий и не охватывает процесс возврата кластера в онлайн. Предоставьте четкие, лаконичные, пошаговые инструкции по правильному выключению и правильному запуску гиперконвергентного кластера Proxmox, работающего на Ceph.
     
     
     
    t.lamprecht
    Guest
    #4
    0
    04.07.2024 19:52:00
    Самое сложное здесь — это процедура выключения, и она была добавлена в документацию совсем недавно, поэтому она еще не доступна в пакете с обновленным номером версии, но поскольку исходник документации относительно легко читать в сыром виде, ты можешь уже сейчас посмотреть содержимое в этом коммите git: https://git.proxmox.com/?p=pve-docs...b;hp=33bd85d554fc91d73d2dc141173bde7a49f8cc80
     
     
     
    jkl
    Guest
    #5
    0
    04.07.2024 22:53:00
    Спасибо! Для тех, кто ищет эту информацию, вот что сейчас ждет публикации в документации: Shutdown {pve} + Ceph HCI кластер

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Чтобы полностью отключить кластер {pve} + Ceph, сначала остановите все Ceph-клиенты. В основном это будут виртуальные машины и контейнеры. Если у вас есть дополнительные клиенты, которые могут обращаться к Ceph FS или установленному RADOS GW, остановите и их. Гостевые системы с высокой доступностью переведут свое состояние в 'остановлено', когда будут выключены с помощью инструментов {pve}.

    После того, как все клиенты, виртуальные машины и контейнеры выключены или больше не обращаются к кластеру Ceph, убедитесь, что кластер Ceph находится в здоровом состоянии. Либо через веб-интерфейс, либо через CLI:

    Код: ceph -s

    Чтобы отключить все действия самовосстановления и приостановить ввод-вывод клиентов в кластере Ceph, включите следующие флаги OSD в панели **Ceph -> OSD** или через CLI:

    Код: ceph osd set noout
    ceph osd set norecover
    ceph osd set norebalance
    ceph osd set nobackfill
    ceph osd set nodown
    ceph osd set pause

    Начните выключать узлы без монитора (MON). После того, как эти узлы выключены, продолжайте выключать узлы с установленными на них мониторами. При включении кластера сначала запустите узлы с мониторами (MONs). После того, как все узлы будут включены и работают, убедитесь, что все службы Ceph работают, прежде чем отменять флаги OSD:

    Код: ceph osd unset pause
    ceph osd unset nodown
    ceph osd unset nobackfill
    ceph osd unset norebalance
    ceph osd unset norecover
    ceph osd unset noout

    Теперь вы можете запускать гостевые системы. Гостевые системы с высокой доступностью изменят свое состояние в 'запущен' при включении.
     
     
     
    Fumareddu
    Guest
    #6
    0
    09.08.2024 12:40:00
    Огромное спасибо за это! Я уезжаю в отпуск и хочу отключить свой домашний кластер на время, так как он мне не понадобится. Я всегда находил разрозненную информацию о продолжительном отключении Ceph-кластера, и это, кажется, наконец-то решает этот вопрос. Однако у меня возникает вопрос: есть ли способ это автоматизировать? Пока это не моя проблема, так как у моего заказчика Ceph пока "нет", но у меня есть процедура отключения, связанная с NUT-сервером, когда электропитание пропадает более чем на 20 минут. Чтобы безопасно его отключить, я думаю, единственный способ — написать скрипт? Это означало бы, однако, что простое автоматическое включение удаленно не будет работать без предварительной очистки этих флагов, верно? Это означало бы, что заказчик без IT-знаний не сможет просто "включить сервер обратно".
     
     
     
    sw-omit
    Guest
    #7
    0
    10.08.2024 11:05:00
    Если ты не напишешь скрипт для стартапа/рабочего процесса, который будет ждать, пока все узлы в кластере не будут включены примерно на 2 минуты (чтобы избежать проблем при повторных отключениях электропитания), не сбросит флаги и только потом начнет загружать виртуальные машины/контейнеры/подобное.
     
     
     
    gkmn
    Guest
    #8
    0
    08.09.2024 21:03:00
    Вопрос от новичка: для моей домашней сети (3 ноды, ZFS, репликация, HA) нужна какая-нибудь штука, чтобы быстро вырубалась при отключении электричества, а у меня всего несколько минут UPS. Нельзя ли просто `pvecm expected x` с `x`, равным абсурдно большому числу, а потом выключить ноды из Proxmox UI? Это должно предотвратить попытки переключения на резерв при выключении и потом при перезагрузке. И когда все ноды снова будут в сети, вернуть нормальное значение кворума. Я правильно понимаю логику?
     
     
     
    UdoB
    Guest
    #9
    0
    08.09.2024 21:10:00
    Нет, ты не можешь установить значение выше реально возможного: Код: ~# pvecm expected 99
    Не удалось установить ожидаемое количество голосов: CS_ERR_INVALID_PARAM Не тестировалось: Я бы просто выключил все узлы одновременно. Это не должно спровоцировать перемиграции HA...
     
     
     
    gkmn
    Guest
    #10
    0
    08.09.2024 22:12:00
    Хм... Это предполагает кучу всего. И сразу подготавливает к проблемам при запуске, если системы не используют примерно одно и то же время (блуждающий fsck, какое-то оборудование, для которого драйвер тратит дополнительное время при загрузке...). На самом деле, должно быть что-то вроде `ha pause/disable` и `ha resume/enable`. Или еще лучше – "cluster disable & shutdown", где при перезапуске UI требует "клик", чтобы снова включить. Очевидно, это не имеет особого смысла для крупных установок. Но я уверен, что домашних/магазинных/лабораторных кластеров с небольшим количеством узлов насчитывается тысячи.
     
     
     
    UdoB
    Guest
    #11
    0
    09.09.2024 08:59:00
    Ну, документация говорит мне в https://pve.proxmox.com/pve-docs/chapter-ha-manager.html#ha_manager_shutdown_policy: Для Policy=Migrate там сказано, что, как мне кажется, разработчики PVE все сделали разумно – они же профессионалы. Реальное поведение для конкретного кластера сложно проверить, потому что тут время играет роль – нужно хотя бы минуту (или две), чтобы вообще спровоцировать активность HA.
     
     
     
    UdoB
    Guest
    #12
    0
    09.09.2024 11:31:00
    Просто из любопытства я протестировал несколько вещей, чтобы нарушить работу кластера — или, по крайней мере, ресурса высокой доступности (HA). Это довольно длинный пост, читайте его для развлечения или пропустите. В конце концов, я могу воспроизвести проблемную ситуацию в моей тестовой конфигурации... У меня есть: чистый виртуальный Test-Cluster из шести узлов (pna,...pnf), поддерживаемый двумя медленными узлами proof-of-concept HC-Ceph (pnd/pne). Я создал группу высокой доступности "HATEST" с одной VM (antix), которая работает на узле pnd и запускает "ping" в терминале — для визуального мониторинга.  Изначально в этой группе HA было три узла. Но настоящая проверка — это выключить все узлы, которые важны. С тремя из них я бы потерял как PVE-Quorum, так и Ceph (настроенный для size=4/min_size=2) был бы очень недоволен. Поэтому я сократил количество узлов до двух для HA. Теперь я могу тестировать:
    1) Ручная миграция между этими узлами HA работает, как и ожидалось, без каких-либо заминок.
    2) Выключение узла (pnd) с работающей тестовой VM — гостевая VM выключилась (так как Policy=Conditional) и затем перезапустилась на другом узле (pne).
    Это, конечно, не то, что я хотел. Только сейчас я изменил Policy с Conditional на Policy Migrate.
    3) Из чистого любопытства: ручная миграция с pnd на pnf — миграция с узла вне определенной группы HA работает! Но затем VM мигрирует обратно с этого не-HA-узла на pnd через несколько секунд.
    4) Выключение узла (pnd) с работающей тестовой VM — это инициирует миграцию (pnd-->pne), гостевая VM остается "включенной"; никаких заминок.  При повторном включении этого тестового узла VM мигрирует обратно на свой исходный узел (pnd).

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

    А теперь перейдем к более интересным тестам.  Базовая конфигурация: все шесть узлов включены и работают, тестовая VM находится на pnd, включена и работает, с видимым "ping".

    5) Выключение всех узлов в группе HA одновременно — запуск через GUI с трехсекундной задержкой для щелчков; узел, на котором находится тестовая VM (pnd), первое удивление: VM мигрировала из определенной группы на узел pna.  Заминок нет, но неожиданно. Это задокументированное поведение..., теперь я устанавливаю флаг "restricted" в моей группе HATEST. VM автоматически мигрировала обратно к источнику, как ожидалось.  Все узлы снова включены; VM на pnd.

    6) Выключение всех узлов в группе HA одновременно — запуск через GUI с трехсекундной задержкой; узел, на котором находится тестовая VM (pnd), миграция не началась.  Выключение вторичного узла (pne) завершилось, гостевая система продолжает работу на исходном узле! Выключение pnd, очевидно, отменилось. Я подождал пять минут.

    Эта ситуация не чистая: VM все еще работает на pnd, узел pnd «засерен» (pvestatd?), но я могу щелкнуть «Выключить» из WebGUI другого узла — никакой реакции.  SSH работает, "qm list" подтверждает, что VM находится здесь.

    Устранение неполадок:

    Код:
    root@pnd:~# shutdown -h now
    Failed to set wall message, ignoring: Transport endpoint is not connected
    Call to PowerOff failed: Transport endpoint is not connected

    root@pnd:~# systemctl start pvestatd
    Failed to start pvestatd.service: Transaction for pvestatd.service/start is destructive (systemd-binfmt.service has 'stop' job queued, but 'start' is included in transaction).
    See system logs and 'systemctl status pvestatd.service' for details.

    root@pnd:~# systemctl start pvescheduler.service
    Failed to start pvescheduler.service: Transaction for pvescheduler.service/start is destructive (dev-dm\x2d2.swap has 'stop' job queued, but 'start' is included in transaction).
    See system logs and 'systemctl status pvescheduler.service' for details.

    Пока я знаю, как принудительно выключить эту систему... какой был бы хороший способ продолжить???

    Код:
    root@pnd:~# qm shutdown 29101
    Requesting HA stop for VM 29101 # ДЕЙСТВУЕТ
    И теперь узел выключается тоже!  Выключение обоих узлов этой двухузловой группы HA прошло не очень хорошо.  Включите оба узла.  Запрос состояния HA сейчас "stopped", что кажется неправильным.  Вероятно, из-за моего ручного "qm shutdown".

    Вернемся к нормальному состоянию: все шесть узлов включены; тестовая VM видна с "ping" на pnd.

    7) То же самое, что и 5+6, но в обратном порядке: сначала выключите неиспользуемый HA-узел pne, затем pnd с работающей тестовой VM; снова с ~трехсекундной задержкой между ними.  pne выключается быстро, как и в 6): "qm shutdown" работает, и узел выключается тоже.

    Теперь я, возможно, нашел виновника: нет агента в тестовой VM!  ACPI, кажется, недостаточно для моей цели?  Установите qemu-guest-agent!

    Вернемся к нормальному состоянию: все шесть узлов включены; тестовая VM видна с "ping" на pnd.

    Теперь С гостевым агентом...

    8) То же самое, что и 7 = выключить pne + pnd --> кажется, что гостевой агент ничего не меняет, вторичный HA-узел pne выключается, узел с VM остается включенным, и VM продолжает работать в WebGui оба узла показаны выключенными через несколько минут; оба не поддаются управлению, как и раньше; VM все еще работает! Снова: ssh --> "qm shutdown" требуется, чтобы выключить VM, а затем узел следует автоматически.

    Вернемся к нормальному состоянию: все шесть узлов включены; тестовая VM видна с "ping" на pnd.

    9) Замедлим: просто выключите в настоящее время неиспользуемый pne. Затем выключите единственный оставшийся узел в группе HATEST, на котором работает тестовая VM.  Выключение pne работает - конечно!  Выключение pnd НЕ работает, оно просто игнорируется!? Через (ровно) пять минут он снова достиг этого странного "засеренного" (не: красный крест), "не подлежит управлению, но VM продолжает работать" состояния. Без ssh я ничего не мог сделать, VM все еще работает... в течение 30(!) минут. Затем он выключается! После этого длительного тайм-аута: отсутствующие службы перезапускаются; WebGUI снова активен; VM перезагрузилась.

    У меня нет хорошего объяснения 30-минутного нокаута. Это кажется удивительным, и поведение не то, что я хочу. Для аварийного выключения (ИБП) это, вероятно, плохо.

    Воспроизводимый результат этой последовательности тестов на данный момент: при вызове "выключение" на последний стоящий узел группы HA с одной работающей VM я сталкиваюсь с проблемным состоянием: через пять минут этот узел больше не поддается управлению в WebGui, но VM продолжает работать на этом самом узле. Через 30 минут система снова поддается управлению. Является ли это ожидаемым поведением? Я не уверен...

    PS: все узлы имеют два виртуальных OSD для Ceph. Я проигнорировал это намеренно, так как size=4/min_size=2 должно убирать серьезные проблемы подальше.
     
     
     
    SteveITS
    Guest
    #13
    0
    07.05.2025 17:59:00
    Пришлось повозиться с этим вчера вечером. Когда я остановил эти сервисы, первые несколько серверов это сделали сразу. Последние два зависли, и через 10-15 минут я сдался. Я запустил их все заново и просто массово выключил ВМ. Похоже, это сработало...? Потом я выполнил шаги Ceph. Важный момент: без работающих сервисов выключение вообще ничего не делало (ладно, ок). Еще, когда я запустил сервисы на узлах, где они остановились, они наконец-то остановились на этих двух последних. Я что-то упускаю? Нужно было подождать дольше? Есть какой-то долгий таймаут?
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

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