Может ли SMB3 Multipathing быть взвешенным политикой?
Рассмотрим конфигурацию с двумя одинаковыми серверами WS2012R2. Оба имеют четырехпортовые сетевые платы. Каждый из них имеет один сетевой адаптер, подключенный к подсети, совместно используемой другими серверами и в конечном итоге доступной для клиентских компьютеров. Остальные три порта на каждом сервере "никем объединены" и подключены к другой подсети, общей для двух рассматриваемых серверов. Я хотел бы видеть, что трафик SMB преимущественно идет по более быстрому 3-никовому пути и прибегает к более перегруженному 1-никовому пути, если это необходимо.
Могу ли я доверять балансировке нагрузки в SMB3, чтобы поступать правильно? Если нет, могу ли я применить какое-то взвешивание, подобное стоимости маршрута tcp / ip?
1 ответ
Я чувствую себя довольно комфортно, когда говорю вам, что продукт будет "делать правильные вещи", но у меня нет репрезентативной среды, чтобы точно имитировать то, о чем вы говорите.
Чтобы говорить об этом технически, дьявол в деталях после того, как серверные компьютеры сообщают подробности своих сетевых интерфейсов через 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) является оптимальным. Я видел некоторые разговоры об изменении этого режима, предлагая более высокую пропускную способность с различными коммутаторами.