Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    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 Виртуальная Среда
     
    le_top
    Guest
    #1
    0
    19.05.2020 15:23:00
    Когда машина выходит из строя, восстановление требует нескольких хитростей как минимум 50% времени. Я использую Proxmox VE 5.4-13, и у меня произошел сбой машины, она была изолирована и т.д. Некоторые машины правильно мигрировали, но 3 находятся в "трудном" состоянии. Два экземпляра переместились на машину, которая даже не входит в определенный для них кластер HA. Один использует необработанное изображение (не синхронизировано), а другой — ceph (недоступен на этой машине). Один экземпляр на правильной машине, но не стартует (systemctl status pve-container@130.service): Код: 19 мая 04:42:11 p3 lxc-start[24666]: lxc-start: 130: lxccontainer.c: wait_on_daemonized_start: 856 Нет такого файла или каталога — Не удалось получить состояние контейнера 19 мая 04:42:11 p3 lxc-start[24666]: lxc-start: 130: tools/lxc_start.c: main: 330 Контейнер не удалось запустить 19 мая 04:42:11 p3 lxc-start[24666]: lxc-start: 130: tools/lxc_start.c: main: 333 Чтобы получить больше деталей, запустите контейнер в фоновом режиме 19 мая 04:42:11 p3 lxc-start[24666]: lxc-start: 130: tools/lxc_start.c: main: 336 Дополнительную информацию можно получить, установив параметры --logfile и --logpriority 19 мая 04:42:11 p3 systemd[1]: pve-container@130.service: Управляющий процесс завершился, код=выход, статус=1. Я хотел бы вернуть эти машины на машину, которая перезагрузилась, без синхронизации/перемещения образа диска (недоступен на одной машине и, возможно, не синхронизирован для машины номер 130 выше). 1. Есть идеи, как это сделать? [ИСПРВЛЕНО: Мне удалось переместить машину на основе CEPH без проблем, и мне удалось переместить машину на основе необработанного изображения, используя мою процедуру ниже. Я исправил машину на ZFS, запустив ее на сервере, на котором она находилась, после отключения HA. Любой ответ на этот вопрос все равно будет полезен для будущих сбоев]. 2. Есть идеи, почему машины переместились на сервер, не входящий в конфигурацию кластера HA (или как узнать, почему)? Вот процедура, которую я собрал в прошлом для машины с необработанным изображением в похожей ситуации, но я не могу применить её в этот раз, поскольку мне нужно исправить машины на ZFS, а не необработанную машину, которая совсем не синхронизирована: Процедура для перемещения ВМ с необработанным изображением обратно на оригинальный сервер без "синхронизации" изображения: ВМ107 была найдена на p1 или копия ее необработанного изображения была на /mnt/bigdisk/vz/images/107/vm-107-disk-0.raw. Этот образ был меньше, чем изображение в том же месте на p5. Миграция на p1 не была настроена, неясно, как машина 107 была назначена на p1 (это произошло снова только что). Желательно было работать с ВМ107 на p5 с изображением, которое было на p5. Проблема заключалась в двух аспектах: миграция была невозможна, поскольку изображение на p5 блокировало, и в то же время это было желаемое изображение. Решение: - Переименовать /mnt/bigdisk/vz/images/107/vm-107-disk-0.raw на обеих машинах (в /mnt/bigdisk/vz/images/107/vm-107-disk-0.raw.org). - Создать /mnt/bigdisk/vz/images/107/vm-107-disk-0.raw на p1, чтобы получить изображение размера 0, которое не начнется. - Через интерфейс Proxmox запросить миграцию на p5, что успешно, поскольку изображение больше не блокировало. - Имея изображение размера 0, миграция происходит почти мгновенно. - Машина не стартовала, на p5, переместить /mnt/bigdisk/vz/images/107/vm-107-disk-0.raw.org на /mnt/bigdisk/vz/images/107/vm-107-disk-0.raw. - Затем запросить успешный старт ВМ107 на p5.
     
     
     
    fiona
    Guest
    #2
    0
    03.06.2020 10:03:00
    Привет, если я правильно понимаю, ты оказался в ситуации, когда файл конфигурации находится на одном узле, а диск, который ты хотел бы использовать, всё ещё на другом. Это не стандартная ситуация, поэтому нет единой команды, которую можно выполнить. Но твой обходной путь уже неплох. Его можно упростить, удалив записи о дисках из файла конфигурации (например, удалив строки в текстовом файле), затем переместив машину без диска и выполнив [qm|pct] --rescan <ID> на целевом узле (это заново добавит диски, которые присутствуют на целевом узле, в конфигурацию). Установлена ли ограниченная настройка для группы сервиса? В противном случае узлы, не входящие в группу, будут по-прежнему рассматриваться с низким приоритетом. Если ты установил ограниченную настройку, не мог бы ты поделиться конфигурацией своей группы сервиса? Код: cat /etc/pve/ha/groups.cfg
    cat /etc/pve/ha/resources.cfg Какой сервис был перемещён на неправильный узел? Какой узел вышел из строя, и какой узел был ошибочной целью? У тебя всё ещё есть системные журналы с того времени, когда это произошло (/var/log/syslog.*.gz)?
     
     
     
    le_top
    Guest
    #3
    0
    21.08.2020 13:54:00
    Это снова произошло для двух машин. Их группы были "пустыми". Я применил процедуру для ручного удаления rootfs из '/etc/pve/nodes/<server>/lxc/*.conf' для указанных машин. Затем я выполнил команды "pct rescan -vmid <ID>", чтобы повторно подключить диски. Это подключает диск как "unused0", так что ВМ не запустилась. Мне пришлось изменить "unused0" на "rootfs" в конфигурационном файле.
     
     
     
    fiona
    Guest
    #4
    0
    24.08.2020 08:58:00
    Привет, не мог бы ты выложить вывод команды: ha-manager config ha-manager groupconfig и сказать, какая машина была затронута? Подразумеваемое хранилище общее (или реплицированный ZFS)? Это произошло после сбоя узла или уже до этого?
     
     
     
    le_top
    Guest
    #5
    0
    24.08.2020 11:27:00
    Машины, которые были затронуты, это ct:102 и ct:140. Обе используют реплицированный ZFS. После сбоя обе их группы HA были пустыми. Я не могу гарантировать, что они были настроены до сбоя, но в принципе я проверял все настройки заранее. Машины были перенесены на сервер p1, который является "маленьким" сервером, чтобы помочь с кворумом. В данный момент он не хостит никаких машин, и ZFS не реплицируется на p1 (он реплицируется между p3 и p5). Нет общего хранилища между p3 и p5 - они находятся на разных площадках. Код: ha-manager config

    ct:101
       группа HAGroup1
       состояние запущено

    ct:102
       группа HAGroup1
       состояние запущено

    ct:103
       группа Gravelines
       состояние отключено

    ct:104
       группа Gravelines
       состояние запущено

    ct:105
       группа HAGroup1
       состояние запущено

    ct:107
       max_relocate 0
       состояние запущено

    ct:109
       группа HAGroup1
       max_relocate 3
       max_restart 3
       состояние запущено

    ct:120
       группа HAGroup1
       состояние запущено

    ct:130
       группа HAGroup1
       состояние запущено

    ct:140
       группа HAGroup1
       состояние запущено

    ct:180
       группа HAGroup1
       состояние запущено

    ct:223
       группа HAGroup1
       состояние запущено

    ct:224
       группа HAGroup1
       состояние запущено

    ct:225
       группа Gravelines
       состояние отключено

    ha-manager groupconfig

    группа: Gravelines
           комментарий Серверы на Gravelines
           узлы p5:1
           nofailback 1
           restricted 1

    группа: HAGroup1
           комментарий Серверы для вычислений
           узлы p5:2,p3:1
           nofailback 1
           restricted 1

    группа: HAGroupAll
           комментарий Серверы с минимальной мощностью
           узлы p5:2,p3:1
           nofailback 1
           restricted 1

    группа: HAGroupCeph1
           узлы p5:1
           nofailback 1
           restricted 1
     
     
     
    fiona
    Guest
    #6
    0
    25.08.2020 10:39:00
    Я пытался воспроизвести это на 4 ВМ и 4 КТ в группе, похожей на вашу HAGroup1, но всё корректно восстановилось на втором указанном узле. Посмотрев на код, я заметил, что группы в конфигурации HA не затрагиваются при отказе узла или восстановлении сервиса. Так что, вероятно, группы не были настроены для ваших двух контейнеров перед сбоем узла. У вас есть резервная копия вашего /etc/pve, где вы могли бы это проверить?
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

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