У меня есть виртуальная машина A, которая должна быть постоянно подключена к контейнеру B. Виртуальная машина A получает ежедневную резервную копию: Код: INFO: статус = работает INFO: обновление VM A: -lock backup INFO: включить диск 'scsi0' '________-disk-0' INFO: режим резервного копирования: снимок INFO: приоритет ionice: 7 INFO: найдены снимки (не включены в резервную копию) INFO: создание архива '/mnt/dump/vzdump-qemu-___-2019_12_13-05_00_02.vma.lzo' INFO: выполнение команды 'fs-freeze' от гостевой агента INFO: выполнение команды 'fs-thaw' от гостевой агента INFO: начата задача резервного копирования 'xxxxxxxxxxxxx' И все по-прежнему нормально. Затем начинаются резервные копии контейнеров. Контейнер B даже не включен в эту задачу резервного копирования (он идет позже в отдельной задаче) Код: INFO: начало новой задачи резервного копирования: vzdump ___ ___ ___ ___ ___ ___ ___ ___ ___ -storage dir_zfs-dir --quiet 1 --node node2 --mode snapshot --mailnotification failure --compress lzo INFO: тип файловой системы на dumpdir - 'zfs' -используя /var/tmp/vzdumptmp9156 для временных файлов INFO: Начало резервного копирования VM ___ (lxc) INFO: Резервное копирование начато в 2019-12-13 05:15:03 INFO: статус = работает INFO: Название CT: example.com INFO: режим резервного копирования: снимок INFO: приоритет ionice: 7 INFO: создание снимка хранилища 'vzdump' Логический том "snap_vm-___-disk-0_vzdump" создан. INFO: создание архива '/mnt/dump/vzdump-lxc-___-2019_12_13-05_15_03.tar.lzo' INFO: Всего записанных байт: 23857827840 (23ГиБ, 195МиБ/с) INFO: размер архивного файла: 19.61ГБ INFO: удалить старую резервную копию '/mnt/dump/vzdump-lxc-___-2019_12_11-05_15_02.tar.lzo' INFO: удалить снимок vzdump Логический том "snap_vm-___-disk-0_vzdump" успешно удален INFO: Завершено резервное копирование VM ___ (00:02:04) В 05:15:23 связь между VM A и CT B оказывается нарушенной. Вчера то же самое случилось в то же время (менее чем через 10 секунд после начала первой резервной копии LXC). Ручной запуск резервного копирования LXC также приводит к сбою соединения. Сервисы как в VM A, так и в CT B используют IP-адреса для связи друг с другом (VM A обращается к CT B каждые несколько секунд). Связь между ними не прекращается, это лишь небольшая перебойка. Но этого достаточно, чтобы привести к сбою обоих сервисов. Во время резервного копирования задержка ввода-вывода достигает 40-45%, но у других машин такой проблемы нет (большинство из них выполняют задачу каждые несколько секунд или максимум каждые пару минут, и я бы знал, если бы это не сработало). Это единственный сценарий в моем узле, где сервисы зависят от внутренней LAN-коммуникации, кроме SMTP и DNS (которые происходят периодически). Перемещение VM A на тот же NVME-диск, где находятся контейнеры, и с вращающегося диска, который хранит резервные копии, предотвращает возникновение проблемы. Но я не понимаю, каким образом задержка ввода-вывода, узкое место на диске, влияет на сетевую связь, особенно учитывая, что VM A записывает на диск очень-очень мало. Мне не абсолютно необходимо, чтобы она находилась на вращающихся дисках, но это критически важный сервис с низким использованием диска, и мне кажется безопаснее иметь его на ZFS-RAID10, чем на одном NVME-диске. Дополнительная информация: VM A и CT B используют общий публичный IP. Pve-firewall не активен на любом уровне (сервис фактически маскирован).