После того, как я вытащил волосы через DFS, мне в голову пришла эта странная и потенциально опасная идея, благодаря которой, возможно, я смогу использовать HA-Proxy для балансировки нагрузки файлового ресурса между серверами.
Я провел несколько корректирующих трассировок пакетов, и оказалось, что TCP-порт 445 - единственное, что используется для совместного использования файлов Windows. В течение многих лет я всегда думал, что UDP 139, 135 и т. Д. Также участвовали, по крайней мере, в установлении соединения - но, видимо, нет!
Итак, я настраиваю базовый тест:
listen SMBTest *:445
mode tcp
server Smb1 172.16.61.201:445
server Smb2 172.16.61.202:445
И никогда не угадаешь, что ... работает ??? (!)
Теперь очевидно, что существует вся забота о синхронизации между файловыми серверами (конечно). Об этом можно легко позаботиться с помощью небольшого скрипта Robocopy.
И учитывая, что мне нужен только файловый ресурс HA, доступный только для чтения, не будет никаких проблем с блокировкой файлов и т. Д.
Репликация файлов - гораздо более сложная проблема, чем вы могли себе представить.
Репликация файлов обычно плохо масштабируется. Вы начнете замечать проблемы, когда число обрабатываемых вами файлов составит полмиллиона или больше, либо копирование занимает больше времени, чем требуется для синхронизации, поэтому вам либо придется закрепить сеанс на более длительный период и уменьшить интервалы между копиями или копировать меньше файлов.
Судя по тому немногому, что я знаю о вашей конкретной рабочей нагрузке, это все еще может подойти вам. Вы сказали, что файловый ресурс доступен только для чтения, что наводит меня на мысль, что вы обновляете данные большими партиями. Робокопирование может быть медленным в этих обстоятельствах, но, поскольку интервал между изменениями слишком велик, это может быть приемлемым риском.
Учитывая, что HAProxy предлагает сравнительный интеллект с балансировщиком нагрузки уровня 4 в этой настройке, может быть более выгодно использовать балансировщик нагрузки уровня 4, поскольку они обычно будут обрабатывать большую пропускную способность с меньшей задержкой при высоких нагрузках. Возможно, это не относится к вашей проблеме, но есть пища для размышлений.
Если вам требуются функции и производительность (например, общие ресурсы чтения / записи, которые необходимо синхронизировать), это не сработает. Если вы думаете, что вам это понадобится с этим набором данных в будущем, внимательно рассмотрите свое решение, так как к тому времени размер вашего набора данных может быть терабайтами, и вы не захотите оказаться в ситуации, когда вам придется выбросить его и повторно загрузить в новое решение.