Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    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 Виртуальная Среда
    Проблема с Ceph после миграции с версии 7.4 на 8.0

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Проблема с Ceph после миграции с версии 7.4 на 8.0, Proxmox Виртуальная Среда
     
    kifeo
    Guest
    #1
    0
    28.06.2023 12:45:00
    Привет! Я недавно обновился с 7.4 до 8.0. У меня кластер из 5 узлов, и 2 из них имеют следующее состояние сбоя. Упомяну, что эти два — HP N54L. Все процессы, связанные с ceph, завершаются с такой ошибкой: Код: 0> 2023-06-28T12:19:08.096+0200 7f5efbaf3a00 -1 *** Пойман сигнал (Неверная инструкция) ** в потоке 7f5efbaf3a00 имя потока:ceph-mon

    ceph версия 17.2.6 (810db68029296377607028a6c6da1ec06f5a2b27) quincy (стабильная) 1: /lib/x86_64-linux-gnu/libc.so.6(+0x3bf90) [0x7f5efc193f90] 2: gf_init_hard() 3: gf_init_easy() 4: galois_init_default_field() 5: jerasure_init() 6: __erasure_code_init() 7: (ceph::ErasureCodePluginRegistry::load(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, ceph::ErasureCodePl ugin**, std::ostream*)+0x2b5) [0x55a42d3fb605] 8: (ceph::ErasureCodePluginRegistry::preload(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::ostream*)+0x9f) [0x55a42d3fbbaf] 9: (global_init_preload_erasure_code(ceph::common::CephContext const*)+0x7c2) [0x55a42cea8f92] 10: main() 11: /lib/x86_64-linux-gnu/libc.so.6(+0x2718a) [0x7f5efc17f18a] 12: __libc_start_main() 13: _start() ЗАМЕТКА: требуется копия исполняемого файла или `objdump -rdS <исполняемый файл>`, чтобы интерпретировать это. То же самое происходит с монитором или osd, и после перезагрузки тоже. Есть ли какие-то подсказки, как я могу это решить? Спасибо!
     
     
     
    Minimons
    Guest
    #2
    0
    01.08.2023 19:17:00
    Это ПОЧЕМУ-то очень плохо! У многих из нас оборудование на миллионы долларов. Мы не можем просто так поменять всю нашу инфраструктуру, только потому что кто-то не хочет скомпилировать две разные бинарные версии. С этим уже сталкивались Microsoft, затем VMware, а теперь и Proxmox. Это действительно подрывает доверие к Proxmox. Я понимаю, что некоторые устанавливают это на $500 ноутбуках, но серьезные решения не обновляют всё новое оборудование только потому, что кому-то не хочется добавить один-два параметра компиляции. Может быть, это знак, что нам стоит задуматься о том, чтобы уйти от Proxmox, пока не стало слишком поздно.
     
     
     
    alexskysilk
    Guest
    #3
    0
    01.08.2023 20:18:00
    Жесткий урок для всех. IT-команды, на которых лежит ответственность за "миллионы долларов", обычно не обновляют системы без обширного тестирования, и даже тогда с большим сопротивлением. Я обычно жду, как можно дольше, чтобы сначала протестировать обновление в лаборатории, не говоря уж о том, чтобы применять его на основной системе.
     
     
     
    Minimons
    Guest
    #4
    0
    02.08.2023 09:23:00
    Дело в том, что я хочу сам решать, какое оборудование использует моя организация. Не должно быть так, чтобы этим занимались Proxmox или (в этом случае) Ceph (или человек, который на самом деле скомпилировал бинарные файлы Ceph). Я могу понять, если новое программное обеспечение действительно требует нового оборудования. Но я в это не верю. Вопрос лишь в том, чтобы скомпилировать бинарники с поддержкой обратной совместимости или создать два разных бинарника. ПОДРОБНЫЕ тестирования никогда не изменят бинарный файл так, чтобы он снова заработал на архитектуре AMD64. Это скользкий путь, а последствия огромные. Теперь вместо того, чтобы быть продуктивными, нам нужно следить за нашим серверным оборудованием. Именно поэтому мы изначально абстрагировали оборудование! Кто купит сервер Lenovo ThinkSystem SR950 V3 за миллион долларов, если через 5 лет Proxmox «не понравится его цвет»?
     
     
     
    fiona
    Guest
    #5
    0
    03.08.2023 09:28:00
    Привет, мы не выбирали прекращать поддержку этого старого оборудования, и если это можно исправить без негативных последствий, мы это сделаем. Для получения дополнительной информации см. https://forum.proxmox.com/threads/p...orking-on-amd-opteron-2427.129613/post-568822
     
     
     
    Diego Aguirre
    Guest
    #6
    0
    23.08.2023 18:26:00
    Та же проблема с Intel® Xeon® CPU E5320 @ 1.86GHz
     
     
     
    kifeo
    Guest
    #7
    0
    08.11.2023 10:06:00
    Проблема с HP N54L решена в версии 17.2.7
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

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