Рассмотрим конфигурацию с двумя идентичными серверами WS2012R2. Оба имеют четырехпортовые сетевые платы. У каждого есть одна сетевая карта, подключенная к подсети, совместно используемой другими серверами, и в конечном итоге доступная для клиентских машин. Остальные три порта на каждом сервере объединены в единую группу и подключены к другой подсети, совместно используемой только двумя рассматриваемыми серверами. Что я хотел бы видеть, так это то, что трафик SMB предпочтительно проходит по более быстрому пути с 3 ником и только при необходимости прибегает к более загруженному пути с 1 ником.
Могу ли я доверять балансировке нагрузки в SMB3, чтобы здесь все было правильно? Если нет, могу ли я применить какое-то взвешивание, подобное расчету стоимости маршрутов TCP / IP?
Я чувствую себя довольно комфортно, говоря вам, что продукт «будет делать правильные вещи», но у меня нет репрезентативной среды, чтобы точно имитировать то, о чем вы говорите.
Говоря технически об этом, дьявол в деталях после того, как серверные компьютеры передают детали своих сетевых интерфейсов через FSCTL_QUERY_NETWORK_INTERFACE_INFO API. Это согласование фактически показано в качестве примера в разделе 4.8. [MS-SMB2]: версии 2 и 3 протокола блока сообщений сервера (SMB) Технические характеристики. К сожалению, часть спецификации, которая будет содержать логику, связанную с выбором сетевого соединения, просто говорит: «Клиент выбирает любую одну пару сетевых интерфейсов для установления нового соединения ...». В протоколе выбора интерфейса есть некоторый нюанс (который, к счастью, Microsoft не включила в спецификацию, хотя, полагаю, можно утверждать, что такое поведение выходит за рамки спецификации). Эта статья, например, описывает, как "немаршрутизируемые" (читай: APIPA и локальные адреса канала) не используются для многоканального SMB.
Помимо «немаршрутизируемых» адресов, описанных в статье выше, это действительно заставляет меня задаться вопросом, есть ли в продукте неявное предположение, что произвольные сетевые интерфейсы в паре клиент / сервер могут взаимодействовать. (Это вполне может быть веной неудачи, просто ожидающей, чтобы ее разработали, в некоторых необычных сценариях, где фильтрация / политика трафика делает это предположение неверным.) Я собираюсь предположить, что, вероятно, есть некоторые предпочтения для интерфейсов в той же подсети, что и интерфейс первоначального канал был создан на. (Было бы неплохо, если бы Microsoft опубликовала такое поведение!) (Я вижу, что Я не единственный, кто думал об этом, по крайней мере...)
Вы можете сделать Get-SmbMultichannelConnection с машины, чтобы узнать, создается ли многоканальное соединение SMB между серверами во время длительной операции копирования. Добавить -IncludeNotSelected аргумент, если вы хотите увидеть «невыбранные» пути.
Вы можете полностью исключить подключения из многоканального SMB с помощью New-SmbMultichannelConstraint командлет, но это не взвешивание приоритета канала как такового - это просто исключение (а это не то, что вы ищете).
В стороне: я предполагаю, что вы используете встроенную функциональность объединения сетевых адаптеров в W2K12. Вы можете проверить с помощью своих коммутаторов, что выбранный алгоритм хеширования LACP (который в Windows Server называется «режимом балансировки нагрузки») является оптимальным. Я слышал разговоры об изменении этого режима, предлагающем более высокую пропускную способность с различными коммутаторами.