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

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Сервер Samba в контейнере – неудачные передачи при отправке с одного узла., Proxmox Виртуальная Среда
     
    Nelluk
    Guest
    #1
    0
    14.12.2024 15:05:00
    Я добавил второй узел Proxmox 8.3 с 14ТБ HDD, предназначенный для использования в качестве сетевого хранилища. Я следовал этой инструкции, чтобы настроить непривилегированный контейнер, работающий с Samba-сервером, для обмена HDD в моей сети с разными ОС. Это работает нормально при отправке данных с других устройств. Однако, когда я смонтировал общую папку на локальном узле и попытался сделать резервную копию моих локальных ВМ, он начинал сбоить после копирования нескольких гигабайт, блокировал файловый сервер LXC и требовал принудительную перезагрузку узла. (Я пробовал разные способы восстановления без принудительной перезагрузки, но только она помогла). Я начал тестирование с `dd`, чтобы исключить часть задачи резервного копирования, и обнаружил несколько вещей:

    - Ограничение скорости передачи до ~60 МБ/с проходит успешно. Всё, что выше ~80 МБ/с, приводит к зависанию `smbd` после 8-12 ГБ.
    - Передачи данных с других устройств (другой узел Proxmox, Mac, PC) проходят отлично и достигают скоростей 150-250 МБ/с.
    - Если установить `dd` для работы сжимаемыми данными, заполненными нулями, проблем не возникает, и достигаются высокие скорости. Проблема возникает при использовании случайных данных.
    - Я пробовал разные изменения в `smb.conf` как было найдено в интернете, но никаких улучшений не было.
    - Я увеличил ресурсы для контейнера файлового сервера с 512 МБ ОЗУ/2 ядра до 2048 МБ ОЗУ/4 ядра, и это дало небольшой прирост (перед сбоем копируется несколько дополнительных ГБ).
    - В состоянии сбоя процесс `smbd` загружен на максимум CPU контейнера. Даже если терминал контейнера отвечает, я не могу ничего сделать, чтобы убить сервер и восстановить работу без перезагрузки. (zombie-процесс `smbd` потребляет 200% CPU при выделении 2 ядра)
    - Я попробовал запустить другой контейнер Samba, на этот раз используя шаблон turnkey linux для файлообмена. Он сбоит точно так же.

    Я мог бы обойтись тем, что просто не использую Samba-общий ресурс на локальном узле или ограничу скорости, но мне бы хотелось лучше понять, что происходит, или найти более чистое решение, если это возможно.
     
     
     
    ernholm
    Guest
    #2
    0
    05.07.2025 17:56:00
    Описание выше полностью соответствует моей ситуации, за исключением того, что диск — это NVMe SSD, на котором и находится PVE. Там я создал zfspool, к которому Ubuntu Docker VM обращается по SMB из Cockpit LXC. Я не уверен, что именно и когда вызывает это состояние, но это всегда происходит во время передачи файлов между узлами, и как только это случается, мне приходится физически выключать сервер, чтобы восстановить его (хотя VM и LXC работают нормально для всего остального). У вас когда-нибудь удавалось это решить? Я уже второй день в отпуске и не имею физического доступа к хосту, так что сейчас буду просто "жить" с частью служб, которые зависли, чтобы оставшаяся часть PVE продолжала функционировать, пока я не получу физический доступ. Очень досадно.
     
     
     
    Nelluk
    Guest
    #3
    0
    05.07.2025 20:36:00
    К сожалению, так и не нашёл хорошего решения. Если память не изменяет, я постоянно использовал SMB-сервер как точку назначения для других серверов в сети, но перестал пытаться монтировать его на локальном узле для резервного копирования. По-моему, я просто предоставил SMB-серверу директорию и ZFS-монтаж для использования узлом для резервного копирования. Отмечу, что в моей ситуации передача данных между узлами никогда не вызывала проблем — проблема возникала только при записи на SMB-сервер с узла, на котором он и находился.
     
     
     
    guruevi
    Guest
    #4
    0
    05.07.2025 20:59:00
    Обратите внимание, что SMB асинхронен, и ваше хранилище ДОЛЖНО соблюдать и использовать fsync, чтобы Samba работала корректно. Вы описываете поведение, которое я обнаружил, когда хранилище тоже было асинхронным. Тогда сервер пишет в оперативную память на полной скорости, пока не закончится сессия (SMB-сессия заканчивается каждые 15 минут). После этого новая SMB-сессия не сможет запуститься, пока все данные не будут записаны на диск, а затем сессия продолжится. В течение этого времени ваш клиент должен зависнуть или повторить попытку, или, в некоторых случаях, произойдёт таймаут, что приведёт к записи повреждённых данных. Обратите внимание, что SMB не падает, просто не может начать новую сессию, пока старая сессия пишет на диск. Протокол SMB довольно плох, если вам нужен надёжный перенос данных, используйте NFS.
     
     
     
    ernholm
    Guest
    #5
    0
    05.07.2025 22:06:00
    Извини за путаницу, я имел в виду между VM/LXC на одном (и только) узле. Вне узла (к другим клиентам в сети) SMB, кажется, работал нормально. Попробую настроить NFS в качестве обходного пути (или запустить контейнеры, перебрасывающие данные, как Docker LXC, монтируя zfspool как директорию напрямую).
     
     
     
    gfngfn256
    Guest
    #6
    0
    06.07.2025 08:16:00
    Кто-нибудь из вас пробовал указать локальный tmpdir в файле /etc/vzdump.conf, как описано в документации? Тогда резервная копия будет временно создаваться локально, а уже потом переноситься на хранилище резервных копий (SMB). Это также рекомендуется, если целевой диск — NFS/CIFS в определенных условиях — смотрите эти документы.
     
     
     
    ernholm
    Guest
    #7
    0
    06.07.2025 14:03:00
    Я тут бэкапы не использовал, данные писались ВМ (обычно ffmpeg объединяет файлы, а потом другие сервисы переносят готовые файлы куда-то за пределы smb-шары), так что не уверен, применимо ли это в моем случае?
     
     
     
    gfngfn256
    Guest
    #8
    0
    06.07.2025 14:07:00
    Если это не связано с vzdump – можете проигнорировать мой предыдущий пост в вашей ситуации.
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

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