У меня есть два сервера, оба под управлением Windows Server 2016 Standard, оба являются виртуальными машинами поверх стандартного хоста Windows Server 2016, использующего Hyper-V.
На одном сервере работает служба, которая должна хранить данные в локальной файловой системе, то есть что-то с буквой диска. Нет путей UNC, нет SMB, нет аутентификации.
Другой сервер - файловый.
Я бы хотел, чтобы сервер приложений хранил данные приложения на файловом сервере. Я могу сделать это через iSCSI, который создает VHDX на файловом сервере. Это нормально работает, приложение успешно сохраняет свои данные на этом жестком диске.
Однако я хотел бы сделать резервные копии содержимого VHDX, и в идеале сделать это на файловом сервере. Для этого мне нужно смонтировать VHDX, но я не могу этого сделать, потому что он «используется другим процессом». Это облом.
Есть ли (поддерживаемый) способ сохранить подключенный VHDX только для чтения на файловом сервере при совместном использовании через iSCSI? Меня не беспокоит, что сервер приложений пытается отформатировать или создать разделы или что-то в этом роде. Я гибок в файловой системе (NTFS, ReFS или даже ExFAT).
Я подумал, стоит ли мне просто переместить VHDX на физический хост-компьютер, а затем подключить его к обеим виртуальным машинам как общие жесткие диски, но похоже, что это предназначен для отказоустойчивой кластеризации.
Возможно, iSCSI и VHDX здесь неправильный подход, существуют ли другие поддерживаемые способы, чтобы одна буква диска на сервере A фактически записывала данные в место на сервере B таким образом, чтобы сервер B мог получить доступ к файлам, сохраняя при этом возможность использовать теневые копии томов (VSS) для резервного копирования? (и да, установка агента резервного копирования на сервере A возможна, но я хочу, чтобы все было как можно проще - я понимаю, что iSCSI может быть излишним, поскольку я разделяю все блочное устройство, когда на самом деле я просто хочу Общая папка).
Короче говоря: вы не можете этого сделать. Даже в режиме одиночной записи никто не будет обновлять ваш родной читатель об изменениях метаданных на блочном томе: для обновления второй «теневой» $ MFT потребуется последовательность размонтирования / монтирования.
Как насчет бега net use x: \\fileserver\smbshare на сервере приложений, который подключает общий ресурс к диску x: на сервере приложений?
И нет, я не думаю, что вы можете смонтировать цель iSCSI на файловом сервере одновременно с тем, как она используется на сервере приложений. У файлового сервера не будет возможности узнать, как внутренние данные файловой системы были обновлены сервером приложений. Следовательно, любые новые созданные файлы / расширенные существующие файлы не будут видны файловым сервером, и резервное копирование будет бесполезным.