open-iscsi диск неожиданно падает в read only (возможно, под нагрузкой)

dmesg что показывает после отвала?

Если же на этот диск настроить резервное копирование proxmox, то в эту же ночь диск упадёт в read only

1. Где диск расположен, экспортируется ( iscsi сервер ) и монтируется ( iscsi клиент ) по отношению к proxmox ?

Например, если у тебя сервер живёт на виртуалке, а при бекапе ВМ приостанавливается для создания snapshot’а, то отвал диска вполне ожидаем

2. настрой мониторинг этого диска. диск отвалится, если время выполнения I/O операций сервером превысит всякие приличия. точных цифр не скажу, не знаю

Если верно понимаю, то интересует этот кусок:

А до него:

Где диск расположен, экспортируется ( iscsi сервер ) и монтируется ( iscsi клиент ) по отношению к proxmox ? Например, если у тебя сервер живёт на виртуалке, а при бекапе ВМ приостанавливается для создания snapshot’а, то отвал диска вполне ожидаем

iSCSI-сервер на отдельном серваке, ночами простаивает.

настрой мониторинг этого диска. диск отвалится, если время выполнения I/O операций сервером превысит всякие приличия. точных цифр не скажу, не знаю

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

Отформатируйте, пожалуйста, куски с логами, читать очень сложно.

По теме - похоже, надо с сетью разбираться - при появлении нагрузки начинаются проблемы. Как физически сеть между iSCSI target и iSCSI initiator организована?

Отформатируйте, пожалуйста, куски с логами, читать очень сложно.

К сожалению, не могу поправить коммент уже, не те знаки поставил. Продублирую, начинается так:

[9610101.458504]  connection1:0: pdu (op 0x1 itt 0xb000003e) rejected. Reason code 0x9
[9610101.458542]  connection1:0: detected conn error (1020)
[9610101.458649] sd 7:0:0:0: [sdc] tag#0 FAILED Result: hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK
[9610101.458654] sd 7:0:0:0: [sdc] tag#0 CDB: Write Same(10) 41 00 36 00 a9 00 00 10 00 00
[9610101.458656] print_req_error: I/O error, dev sdc, sector 906012928
[9610225.224368]  connection1:0: detected conn error (1020)
[9610346.408506]  session1: session recovery timed out after 120 secs
[9610346.408519] sd 7:0:0:0: rejecting I/O to offline device

А чуть позже:

[9610346.408763] sd 7:0:0:0: rejecting I/O to offline device
[9610346.408772] JBD2: Error -5 detected when updating journal superblock for sdc1-8.
[9610903.229966] audit: type=1400 audit(1573412971.694:10974): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxc-102_</var/lib/lxc>" name="/" pid=25409 comm="(ionclean)" flags="rw, rslave"
[9610928.726331] audit: type=1400 audit(1573412997.190:10975): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxc-103_</var/lib/lxc>" name="/" pid=25720 comm="(ionclean)" flags="rw, rslave"
...
[9634328.830830] audit: type=1400 audit(1573436397.189:11001): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxc-103_</var/lib/lxc>" name="/" pid=5088 comm="(ionclean)" flags="rw, rslave"
[9635534.626294] EXT4-fs error (device sdc1): ext4_journal_check_start:61: Detected aborted journal
[9635534.626305] EXT4-fs (sdc1): Remounting filesystem read-only
[9636103.342853] audit: type=1400 audit(1573438171.693:11002): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxc-102_</var/lib/lxc>" name="/" pid=20544 comm="(ionclean)" flags="rw, rslave"
...
[9657164.903381] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null)

Надеюсь тот кусок уловил, но осознать пока не могу.

С сетью всё просто, proxmox на отдельном компе, за домашним роутером, подрубается к отдельному серваку за микротиком и цепляется за iSCSITarget в Win2008Server, сразу видит LUN и быстро конектится, ночью канал свободен и 30 Мбит/с в их распоряжении для бекапа.

До этого предыдущий proxmox жил в таких же условиях, не падал годами.

proxmox на отдельном компе, за домашним роутером, подрубается к отдельному серваку за микротиком и цепляется за iSCSITarget в Win2008Server

Еще раз, пожалуйста. Между роутером и микротиком что находится? Internet? Пинг какой между proxmox и W2K8? В логах W2k8 что-то есть при отваливании fs? И что такое «отдельный сервак»? Тот самый W2k8 или что-то другое? ,

Т.е. ты одновременно пишешь в одну фс с разных устройств ?

Да, между ними интернет, ping в среднем time=3.76 ms. Отдельный, это я имею в виду, что не виртуалка, а настоящий железный W2k8 сервер, где iSCSITarget настроена, когда с proxmox обращаюсь на него: давай LUN! Он сразу даёт и отлично подключается.

Отвечу здесь анону и bdfy в /etc/fstab всё отлично и после перезагрузки монтируется всё. А в одну ФС я не могу писать из разных мест, это бессмысленно ведь, и насколько я вижу, по крайней мере в Винде если я обращусь с попытками смонтировать в винде vhd, который iSCSITarget и даёт в качестве LUN, то всё погибнет. Там всё просто, настраивая iSCSITarget ты выделяешь место на виртуальном диске vhd, указываешь кто именно будет подключаться вплоть до ip, и только ему и даётся цель. Со стороны proxmox я обращаюсь к цели, она видя мой адрес, сразу говорит, да, пожалуйста, вот ваш LUN, я его монтирую, делаю на нём раздел и ФС и спокойно работаю, до наступления бэкапа.

Спасибо Serge10 за виндовые логи, совсем забыл! Там что-то странное, сегодня бэкап отвалился в 5 утра, в логах всё хорошо, а вот с 11 утра, когда я заново его переподключил, каждую минуту друг за другом:

Ошибка протокола в инициаторе iSCSI iqn.1993-08.org.debian...
Инициатор iSCSI iqn.1993-08.org.debian... выполнил выход из цели iSCSI.
Инициатор iSCSI iqn.1993-08.org.debian... успешно выполнил вход в цель iSCSI.

Но всё замонтировано в rw и я спокойно туда пишу сейчас и читаю по мелочи.

Я не пользуюсь дебиан дистрами, что там с планировщиками дискового IO. Если используется blk-mq, то надо менять, с такой топологией не взлетит.

[quote]за микротиком и цепляется за iSCSITarget в Win2008Server[/quote]

Если сервер iSCSI – это винда, то я слышал, что он очень плохо работает в этой роли.

Чуть выше писал, предыдущий proxmox бэкапился на этот же сервак, 4 года отпахал, падал 3-4 раза от отключения электричества.

Если ещё интерес не потеряли, я сейчас, для чистоты эксперимента проделаю всё с нуля, удалю цель полностью и разверну службу снова, подключу снова и отформатирую LUN снова и поставлю задание бэкапа. Потребуется время, но я вернусь.

4 года отпахал

а что диски в сервере показывают?

Если речь о здоровье дисков, RAID-5 чувствует себя хорошо.

Да, между ними интернет

Это очень плохой сценарий для использования iSCSI. Вы, фактически, не контролируете состояние сети между Вашими роутерами. А там может быть все что угодно - перезагрузка роутеров, смена маршрутов, обрыв линков и т. п. вещи.

iSCSI даже в локальной сети рекомендуют выносить в отдельную физическую сеть (не vlan) со своими проводами и коммутаторами. А Вы его через интернет прокинули…

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

приспособленными для интернета вроде NFS

Разве что за последнии годы что-то допилили. Во всяком случае ранее это было очень чувствительным к нестабильной связи. Поэтому даже не пытаюсь где-то в проде использовать.

решениями, приспособленными для интернета вроде NFS или SMB?

Будем честны, даже в древнем FTP ситуация с докачкой после обрыва лучше чем в NFS/SMB.

Но да, iSCSI - это точно не тот протокол, который стоит гонять поверх нестабильного линка.

Во всяком случае ранее это было очень чувствительным к нестабильной связи.

Не забывайте, все познается в сравнении :). По сравнению с iSCSI NFS гораздо лучше переносит проблемы со связью. Ну и уже давно есть реализации NFS на tcp (не на udp) протоколе.

Будем честны, даже в древнем FTP ситуация с докачкой после обрыва лучше чем в NFS/SMB.

А я нигде и не спорил с этим утверждением ;). Но в контексте данной темы NFS/SMB сравниваются с iSCSI, а никак не с ftp ;).

Ну и уже давно есть реализации NFS на tcp (не на udp) протоколе

Я пробовал всё. Внезапное падение в любом из них.

По сравнению с iSCSI NFS гораздо лучше переносит проблемы со связью.

Очень относительное сравнение. Согласен что iSCSI рухнет с гораздо большей вероятностью, такое как у ТС я бы даже не подумал делать. Но и называть NFS «удобной» для не стабильной связи тоже не стал бы.

Я вернулся с новостями.

Кстати, а чем обусловлен выбор именно этой технологии? Почему бы >не воспользоваться решениями, приспособленными для интернета >вроде NFS или SMB? IMHO, оба эти варианта гораздо менее >чувствительны к непредсказуемым задержкам и потерям пакетов, чем >iSCSI.

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

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

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

Это, конечно, хорошие новости, но я бы все равно рекомендовал бы Вам подумать о смене технологии выделения дискового пространства под бекап. Потому что однажды проблемы со связью, на которые Вы никак в принципе повлиять не в состоянии, могут привести не просто к ro-состоянию файловой системы, но и к ее полному развалу. Со всеми вытекающими последствиями.

Да, конечно, это неграмотный способ. Как я говорил, это сейчас больше исследование, тренировка. На данный момент добавляю в бэкап большие объёмы и буду следить за логами, интересно разобраться. Для работы выберу другой способ, пощупаю NFS, есть немного места на Synology. Спасибо за ответы, я дополню ветку по результатам тестов.