У меня есть 4 файловых сервера, к которым я хочу получить доступ под единственной точкой монтирования с другого сервера
Я подозреваю, что предложение скорее перепутано. Да у Вас может быть несколько файловых систем, доступных и смонтированных в том же месте - но не тривиальное осуществление - я подозреваю, что Ваше намерение состоит в том, чтобы предоставить шлюз этим четырем файловым системам через единственную точку монтирования - который не является тем же самым вообще.
Вы подразумеваете, что та же файловая система должна быть доступной на 4 серверах? Это - единственный сценарий, где glusterfs, казалось бы, имел бы смысл.
Что протоколы включены здесь?
Предположение, что это - проблема репликации, как близко к реальному времени это должно быть? Как это должно справиться с отказами?
Вы, кажется, думаете, что обратный прокси является решением. Но решение, к какой?
Поскольку вы можете удаленно смонтировать файловую систему из производственной установки, я предлагаю (cjc также упомянул об этом в комментарии) использовать что-то вроде unionfs. Unionfs - это инструмент, часто используемый в средах livecd / liveusb, чтобы представить систему с файловой системой только для чтения, объединенной с RAM-диском для чтения и записи, так что чтение происходило из файловой системы, доступной только для чтения, если файл не присутствует в области чтения-записи.
Если вы использовали что-то вроде vCenter Orchestrator и запускали его поверх vSphere, вы могли бы использовать для этого связанный клон. Это создаст новую виртуальную машину с базовым диском вашего живого сервера и дельта-диском со всеми вашими изменениями. Объем занятого места на жестком диске будет равен только изменениям, которые вы вносите в клон. Затем, когда вы закончите, от него можно отказаться, пока вам не понадобится развернуть новый связанный клон.
Поскольку это звучит так, как будто вы работаете с сервером на «голом железе», а ваша виртуальная машина является локальной для вашего рабочего стола, вы Вам придется придерживаться того, что вы уже делаете.