Назад | Перейти на главную страницу

Проблема с производительностью файлового сервера отказоустойчивого кластера в Windows Server 2016

Я столкнулся с интересной проблемой производительности скорости передачи файлового сервера с отказоустойчивым кластером, который я недавно настроил в Server 2016. Конкретная проблема заключается в том, что когда я получаю доступ к общей папке из кластерного пути хранения (например, \\ store01 \ share01), передача файлов скорость (пишет в частности вроде) есть способ, путь медленнее, чем когда я обращаюсь к нему через локальный путь на текущем узле владельца (например, \\ srv04 \ e $ \ Shares \ Share01).

Например, я скопировал 499 файлов .txt (всего 26,07 МБ) с помощью Robocopy:

Это проблема независимо от текущего узла-владельца или от того, откуда передаются данные. Хотя в то время я не следил за ним, я более или менее установил и настроил службу, как указано в это руководство. Я пробовал возиться с некоторыми настройками, но все они вернулись к значениям по умолчанию (насколько мне известно). Я немного огляделся и не нашел ничего, конкретно упоминающего об огромной проблеме с производительностью при использовании отказоустойчивого кластера, поэтому я провел несколько случайных исследований, не особо показывающих это.

Несколько важных моментов о конфигурации:

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

Заранее спасибо.

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

https://www.starwindsoftware.com/blog/lacp-vs-mpio-on-windows-platform-which-one-is-better-in-terms-of-redundancy-and-speed-in-this-case- 2

http://scst.sourceforge.net/mc_s.html

Решение: вам нужно отключить свои сетевые адаптеры и использовать MPIO.

Вторая проблема - это сама Synology. Это не то, что вы используете в качестве основного хранилища, в лучшем случае это резервный блок.

Решение: вы копируете свой контент на локальные диски и используете Synology в качестве хранилища резервных копий или что-то еще.

После удаления объединения сетевых адаптеров и размещения соединений на Synology / Server в другой подсети для хорошей оценки я все еще не заметил улучшения производительности.

Тем не менее, я наконец нашел решение. Оказывается, причиной была постоянная доступность (по умолчанию) для общего ресурса. Есть документация, в которой говорится, что это может вызвать "небольшое" снижение производительности (как здесь) из-за обхода кеша записи в некоторых случаях кажется, что «небольшое» снижение производительности на самом деле «гигантское». Вот статья это дает довольно полезную информацию о непрерывной доступности и о том, когда вы можете захотеть ее использовать (резюмируя, вы можете отключить ее, если ваш общий ресурс настроен на «Файловый сервер общего использования» и вас беспокоит производительность).

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