DataCenter Bridging / Networking (DCB/DCN) в Windows Server 2012 R2

Привет.

Технологии семейства DCB (они же DCN – DataCenter Networking) – редкая тема для обсуждения, хотя их поддержка появилась ещё в Windows Server 2012. Отсутствие информации в авторизованных курсах плюс традиционно слабая подготовка преподавателей Microsoft в сетевых технологиях сделали своё чёрное дело – “технология есть, а плода – нет” (ц) к/ф “ДМБ”. Около 100% рекомендаций выглядят как “ну типа клёвая штука, на серверах можно включать, оно там чего-то лучше станет делать”.

Попробуем разобраться, что, зачем и почему следует из включения данной одинокой галки в Add Roles and Features. Я предполагаю, что Вы знакомы с сетевыми технологиями хотя бы на уровне азбучных вопросов курса Cisco ICND1 3.0. Если нет – лучше вначале изучить его, это бесплатно.

DCB в Windows Server

• Ветхий завет технологий управления трафиком
• DCB: 802.1Q и его друзья
• Включаем поддержку DCB на сервере
• Настройки DCB в Windows Server

Начнём.

Ветхий завет технологий управления трафиком

Вначале никакого QoS не было. Была радость, что кадры и ячейки вообще иногда доходят до другого конца провода.

Потом стало выясняться, что радость не очень полная – ведь протоколы канального уровня в подавляющем большинстве не могли сделать ничего, что выходит за рамки LLC1, т.е. могли лишь зафиксировать факт того, что к ним что-то приехало, и у этого чего-то сошлась FCS. Был, конечно, вариант, как в потомстве HDLC – с LAP-x, чтобы с восстановлением данных, надёжно, но подходил он только для медленных линий, высокого процента проблем, связанных с физикой канала и логикой “надёжно доставить не смотря на потери времени и полосы пропускания”.

А трафика было всё больше и больше, и разного – служебного, важного, обычного. И клиенты операторов хотели платить за то, чтобы иметь хоть какие-то гарантии доставки трафика с определённым качеством. При этом клиенты не очень хотели, допустим, класть везде линии для Frame Relay, хоть оный и решал массу подобных вопросов – больно уж дорого, медленно, и куча NBMA-спефицики.

Плюс на горизонте вырисовывался голосовой трафик, интеграция которого в существующие сети резко увеличивала и количество классов трафика, и усложняла логику их обработки, да и вообще – потоковый трафик как таковой уже становился серьёзным испытанием для “обычных” сетей.

Арсенал по борьбе со всем этим счастьем начал расти. Что же в него входило?

Первым делом – протокол управления потоком, который 802.3x. Это возможность одному порту сказать другому “притормози, а то у меня буфер на приём уже под завязку, я разгружать внутрь не успеваю то, что ты присылаешь, если продолжишь присылать я буду тупо сбрасывать tail drop’ом”. Вы точно видели её в настройках сетевых адаптеров – если нет, почитайте мою статью про QoS в Windows NT, там про это есть.

Далее, в 802.3-кадрах в их LLC-части, в частности в 802.1Q-заголовке, был выделен дальний от окна уголок для трёх бит, которые стали называть себя 802.1p. Эти три бита могли использоваться произвольными механизмами marking’а для того, чтобы выставить личный приоритет данного кадра – так как бит всего три, то от нуля до семи. Благодаря данной метке приоритетная обработка могла начаться уже с момента поступления кадра в rx-ring принимающей стороны. Называется оно CoS – Class of Service.

В заголовках сетевого уровня – в частности, IPv4 – тоже выделили место под данные контроля качества. В IPv4 выделен байт, который называется ToS – Type of Service – внутри которого можно добавить информацию о желаемом (или требуемом) качестве доставки пакета. В ToS ситуация по сравнению с CoS осложнена тем, что у данного байта нет одного фиксированного формата – в зависимости от того, какой логики придерживается маркирующий, там могут быть совершенно разные значения – задача сопряжения записи маркировки и чтения оной ложится на плечи администратора, настраивающего домен QoS.

Были и другие механизмы – те же DE/FECN/BECN в Frame Relay, но это уже совсем другая история.

Главное тут то, что весь данный арсенал обладает ощутимыми минусами, которые заметны уже даже в случае достаточно несложной сети, где просто есть важный и не очень трафик. А уж если добавить мультикаст (разный по важности), голосовой трафик, трафик СХД – минусы станут крайне явными:

• Грубая работа – тот же 802.3x может использоваться лишь для того, чтобы сказать противоположному порту “заткнись”. Без разбора по части трафика, весь порт и целиком.
• Отсутствие возможности жесткого управления полосой – все эти 802.1p и ToS – это лишь пожелания.
• Невозможность резервирования конкретного объёма данных для отправки/приёма – вся логика 802.1p вышла из логики 802.3, где CSMA/CD и конкурентный доступ вида “кто первый в таборе проснулся, тот красивее всех оделся”. Возможность потерь трафика заложена здесь в саму идею, поэтому данный подход абсолютно непригоден для СХД и сетей датацентров. А уж о такой штуке, как, допустим, Live Migration / vMotion, да в географически распределенённом сценарии, и говорить с “чистым” CSMA/CD смысла нет.

Со всем этим надо было бороться, потому что на горизонте замаячило мега-объединение всех сетевых трафиков в пределах одной физической среды пропускания – всякие фабрики и прочее.

DCB: 802.1Q и его друзья

Комплект технологий, объединённых под термином DCB, адресно нацелен на решение всех этих задач. Вообще, в качестве доп.материала про него могу порекомендовать наш обзорный вебинар про сети датацентров и коммутаторы семейства Cisco Nexus, а также подумать про базовую сертификацию CCNA Data Center, в которой крайне подробно разбираются эти моменты, но пока постараюсь кратко и рамочно объяснить, в чём основная суть нововведений.

Data Center Bridging будет состоять из следующих компонентов:

802.1Qbb (Per-priority Flow Control)

Это прямая замена Flow Control (802.3x). Логика работы, по сути, позаимствована у Fibre Channel – вместо стандартного CSMA/CD, где “в среде передачи тихо – полезу-ка на пробу преамбулой, посмотрю”, в Fibre Channel используется явный запрос buffer credit – т.е. “вот тебе 10 килобайт, я под тебя их в буфере застолбил, ни в чём себе не отказывай”.

При таком подходе, что очевидно, схема 802.3x “буфер почти кончился, давайте ничего не передавать”, будет нецелесообразна, поэтому 802.1Qbb предлагает другой подход – в PAUSE-frame теперь указывается пауза для каждого класса отдельно. Т.е. можно “притормозить” важный поток данных при переполнении именно его личного буфера, чтобы избежать потерь.

802.1Qaz (Enhanced Transmission Selection)

ETS решает, фактически, важнейшую задачу – создаёт поверх L2-домена виртуальные каналы для каждого CoS. Логика работы будет такой – ETS определяет на уровне хоста т.н. priority groups, которые могут содержать один или более CoS’ов, для которых на уровне сетевого адаптера создаются раздельные tx/rx очереди (Virtual Queues, VQ), и позволяет резервировать для них как полосу пропускания (нужный процент от номинального максимума канала), так и приоритет вытеснения в случае конфликта. Обратите внимание, что сетевые адаптеры и bridge’ы должны поддерживать как минимум 2 таких PG, а лучше 8 (из которых как минимум одна должна уметь занимать 100% полосы пропускания), поэтому факт поддержки 802.1Qaz – это одно, а реальная поддержка – разная, поэтому имеет смысл внимательно подойти к проектированию архитектуры сети и функционалу конкретных сетевых адаптеров и коммутаторов.

802.1Qau (Congestion Notification)

Данный стандарт входит не во все реализации DCB, однако относится к нужным для изучения. Суть его достаточно проста – дать возможность при перегрузке локального буфера приёма данных уведомить об этом не одного и напрямую подключенного отправителя, а нескольких и, возможно, находящихся не в зоне local multicast’а. Сценарий использования может быть, например, такой – в distribution-коммутатор воткнуто аплинками несколько access-коммутаторов, и каждый из них отправляет, например, трафик двух VLAN – 10го и 20го. Трафик L3-терминируется на SVI, и входящая очередь одного из SVI – например, 10го – начинает переполняться. В этой ситуации стандартная схема “крикни ему, чтобы заткнулся на время” не подойдёт – во-первых SVI – это не физический порт, во-вторых отправителей несколько. 802.1Qau решит этот вопрос.

DCBx (eXchange)

Как понятно из вышенаписанного, получается, что на каждом сетевом узле, входящем в L2-домен с поддержкой DCB, нужно будет сделать много настроек в ценях единообразия домена DCB. Нужно:

• Согласовать Priority Groups (какие CoS’ы в какие группы попадают) и их нумерацию.
• Согласовать процент резервированной полосы пропускания для PG.
• Согласовать схему приоритета вытеснения одной PG другой в случае oversubscription.
• Иметь возможность “включить-выключить” один виртуальный CoS (по сути, например, интерфейс FCoE).

Для всего этого используется “прокачаный” протокол LLDP (802.1AB), хорошо известный в Windows ещё со времён NT 6.0 (тогда в Vista на интерфейсах появились два новых сетевых компонента – Link-Layer Topology Discovery Mapper I/O Driver и Link-Layer Topology Discovery Responder, который базировались на субверсии LLDP). Данный протокол подразумевает возможность несложного расширения транспортируемых данных, так как использует для их представления TLV, поэтому на него ложатся задачи и декларирования своих настроек, и синхронизации их с соседями.

Кстати, в самом начале протокол назывался Cisco-Intel-Nuova DCBX, а до стандартизации под крышей 802.1Q ещё длиннее – Converged Enhanced Ethernet DCBX (CEE-DCBX). Если увидите эти названия – это ступеньки к 802.1Qaz.

Полезно? Очень. Теперь поговорим, как это всё включить.

Включаем поддержку DCB на сервере

Первым делом убедимся, что наши сетевые адаптеры поддерживают DCB. Ведь разбивать трафик на очереди надо будет им, а не ОС. В случае виртуальных адаптеров Hyper-V это уже есть и беспокоиться ни о чём не надо.

Теперь установим компонент DataCenter Networking – это можно сделать например через PowerShell:

PS C:\Users\atraining> Install-WindowsFeature Data-Center-Bridging

Никаких особых параметров нет, перезагрузка не потребуется.

Чтобы сразу быть во всеоружии, добавим нужные модули в PowerShell и обновим справку.

PS C:\Users\atraining> Import-Module DCBQoS PS C:\Users\atraining> Import-Module NetAdapter PS C:\Users\atraining> Import-Module NetQoS PS C:\Users\atraining> Update-Help

Дождитесь обновления help’а и проверьте настройки интерфейсов. На каждом из тех, где должен работать DCB, должны существовать и быть включены компоненты QoS Packet Scheduler и Microsoft LLDP Protocol Driver. Первый из них – это NDIS-драйвер для реализации системных политик и запросов приложений в части QoS – например, маркировки исходящих IP-пакетов и кадров, второй – поддержка DCBX. Функционал их абсолютно разный, но на данный момент должны быть установлены оба.

Теперь пойдёмте в настройки сетевого адаптера и сделаем одну штуку, про которую многие забывают – выключим ставший не нужным Flow Control. Чтобы он нам все эти тонкие настройки, виртуальные очереди и прочее не перекрывались простым сигналом “Притормозите”.

Короткое отступление про внутреннюю конструкцию и компоненты DCB

Как эти компоненты будут взаимодействовать друг с другом, и кто за что будет отвечать?

Всё на самом деле не так сложно. Можно выделить следующие компоненты и зоны ответственности:

QoS Inspection Module (он же QIM)

Это – часть tcpip.sys, которая отвечает за то, чтобы фактически присвоить PDU’шкам то, что “заказывает” через минипорт DCB и не только он. По сути, различные подсистемы QoS передают “заказы” на QIM, а он уже разрешает возможные конфликты и производит фактическую работу. QIM всегда установлен, иначе бы ни одна настройка в системе, связанная с L2/L3 QoS не работала бы.

Data Center Bridging

Это – msdcb.sys. Он берёт настройки из реестра и DCB WIM-провайдера (которому, в свою очередь, выдаёт их, например, командлет Powershell) и передаёт их на QIM. Этот компонент как раз отсутствует, пока в системе не установлена фича “Data Center Bridging”.

WMI-провайдеры QoS Policy и DCB

Их задача проста – обеспечивать различные способы администрирования и хранения настроек для QoS и DCB. Именно с NDIS 6.30, т.е. Windows Server 2012 R2, данные CoS канального уровня являются обязательным компонентом для данных настроек.

Теперь продолжим про настройки Data Center Bridging.

Настройки DCB в Windows Server

Первый шаг – определиться с логической моделью DCB в нашей сети. Есть два варианта – умные коммутаторы настраивают сетевые адаптеры хостов и ручная настройка. Если нам хочется узнать текущую настройку – т.е. будут ли сетевые адаптеры слушать DCBx или будут исходить из своих настроек, то надо выполнить такой командлет:

PS C:\Users\atraining> Get-NetQoSDCBxSetting

Если выведется True – мы слушаем LLDP/DCBx-кадры и читаем их содержимое, если False – исходим из локальных настроек.

Мы можем также регулировать это на уровне адаптера, просто отключая компонент Microsoft LLDP Protocol Driver на нужном адаптере – это не повлияет на фактическую работу DCB-механизмов, лишь отключит DCBx-взаимодействие.

Если захотим отключить DCBx глобально – ну нет у нас в сети таких коммутаторов особо умных, либо это виртуальная сеть “точка-точка” между двумя виртуалками – это делается так:

PS C:\Users\atraining> Set-NetQoSDCBxSetting -Willing 0

Это, подчеркну, именно про DCBx – т.е. про протокол обмена информацией. Глобальное включение-выключение именно DCB на сетевом адаптере выглядит иначе:

PS C:\Users\atraining> Enable-NetAdapterQoS название адаптера

Выключить, если что, так же, только Disable вместо Enable.

Если же хочется вообще посмотреть глобальные настройки DCB на всех интерфейсах – есть удобный командлет:

PS C:\Users\atraining> Get-NetAdapterQos

Вы увидите множество настроек, про которые мы поговорим дальше – некоторые простые, типа QoS Enabled, а некоторые поинтереснее.

Теперь настроим Priority Flow Control – стартово “разметим” классы для трафика, которые будут задействованы на нашем хосте.

Настройка Priority Flow Control в DCB для Windows Server 2012 R2

Для начала посмотрим, как у нас сейчас с PFC дела обстоят:

PS C:\Users\atraining> Get-NetQoSFlowControl

Скорее всего, Вы увидите табличку из двух колонок, где слева – приоритет 802.1p, а справа – False. Мы можем включить те приоритеты, которые будут задействоваться нами в работе DCB:

PS C:\Users\atraining> Enable-NetQoSFlowControl -Priority класс 802.1p

Если надо, можно указать несколько классов через запятую и без пробелов. Выключить, если что, так же, только Disable вместо Enable.

После того, как включили нужные классы в DCB-работу – можно настраивать 802.1Qaz.

Настройка Enhanced Transmission Selection в DCB для Windows Server 2012 R2

Созданим классы трафика – определения, нужные для того, чтобы было удобно именовать информацию вида “Трафику с таким приоритетом выделить столько полосы по такой-то логике”. Учитывайте, что к одному классу трафика (фактически, priority group) можно привязать более одного 802.1p-приоритета, а наоборот – нет.

Создадим, например, класс для RDP-трафика – ну, хочется нам, чтобы у людей лучше и стабильнее работал доступ к терминальному серверу.

PS C:\Users\atraining> New-NetQoSTrafficClass -Name “RDP” -Priority 2 -BandwidthPercentage 50 -Algoritm ETS

Что обозначают эти параметры? Параметр -Name просто задаёт удобное для идентификации имя класса. Параметр -Priority – один или более приоритетов, которые будут относиться к данной priority group. Параметр -BandwidthPercentage – резервируемую под эту priority group полосу пропускания, а вот параметр Algoritm будет интересным – у него будет два значения Transmission Selection Algorhitm – ETS или Strict. Strict будет жестким – именно столько полосы пропускания, ровно, а ETS будет позволять адаптироваться под текущую ситуацию – например, использовать больше полосы, если надо. Используйте ETS, но учтите – внимательно ознакомьтесь с документацией на сетевой адаптер, умеет ли он именно столько 802.1Qaz-очередей, сколько надо, и умеет ли Enhanced Transmission Selection.

Пока классы не созданы, все 802.1p-приоритеты привязаны к дефолтному классу, поэтому Вы можете максимально создать не 8, а 7 классов – дефолтный всегда есть. Посмотреть на дефолтный, да и на все вообще, просто:

PS C:\Users\atraining> Get-NetQoSTrafficClass

Ну а теперь, когда задействованные 802.1p-приоритеты включены, priority group’ы созданы, полоса пропускания размечена, алгоритмы поведения выбраны, нужно назначать трафик.

Настройка DCB QoS Policy для Windows Server 2012 R2

Наша задача – написать L3/L4 критерии для того, чтобы было понятно, какой трафик сетевого/транспортного уровня как надо помечать на канальном уровне.

Мы выбрали для примера RDP – сделаем для него. Напомню, для него мы выбрали 2й CoS приоритет. Для начала созданим базовую политику, а потом посмотрим на тонкости настроек.

PS C:\Users\atraining> New-NetQosPolicy -Name “RDP DCB QOS Policy” -PriorityValue8021Action 2 -IPProtocolMatchCondition Both -IPPortMatchCondition 3389

Что мы создали? Создали именованную политику, которая крайне проста – “Всё то, что идёт по TCP и UDP и на 3389й порт, метить на уровне 802.1p как 2й класс”. TCP и UDP задаются параметром -IPProtocolMatchCondition Both, там, увы, можно задать или TCP, или UDP, или оба – Both. Что же мы ещё сможем добавить в нашу политику?

Мы можем улучшить критерии отбора трафика, задав source / destination. Это делается параметрами -IPSrcPrefixMatchCondition и -IPDstPrefixMatchCondition, формат параметра – префикс, вида 192.168.17.0/25 или fd00:0:0:162/64.

Мы можем ограничить применяемость нашей политики только трафиком, идущим через интерфейс, классифицированный нужным образом – это параметр -NetworkProfile со значением Domain / Public / Private. Или ещё и именем файла – параметр -AppPathNameMatchingCondition поможет нам указать, что политика сработает только в случае, когда с сетью взаимодействует данный конкретный файл (например, mstsc.exe)

Мы можем указать, как вести себя системе, если несколько политик перекрывают друг друга – для этого есть байтовый параметр -Precedence, который 127 по умолчанию, и чем выше – тем лучше. Иными словами, из дву разных политик, под которые подпадёт одинаковый трафик, выиграет та, у которой Precedence будет числово выше.

Мы можем детальнее задать порты – что порты отправителя, что получателя. Допустим, мы хотим, чтобы наше приложение выбирало только “правильные” динамические порты, т.е. последние 2^14 из адресного пространства TCP/UDP. А те, кто будут отправлять из-под “неправильных портов” нам не нужны – вдруг они на работу роутер принесли с NAT/PAT и шаманят из-под него. Для этого у нас есть параметры -IPSrcPortStartMatchCondition и -IPSrcPortEndMatchCondition, задающие, соответственно, первый и последний порт из диапазона. Для портов назначения – аналогичная пара из -IPDstPortStartMatchCondition и -IPDstPortEndMatchCondition.

Мы можем даже попутно добавлять метки в ToS-поле IP-заголовка, для этого есть ключ -DSCPAction, где можно задать шестибитовое значение DSCP (подробнее про DSCP можно почитать здесь), которое будет прописываться, замещая собой предыдущее, у всех пакетов, подпадающих под данную политику.

Также можно задать и максимальную полосу пропускания – притом что в битах в секунду, что в байтах – это делается параметрами -ThrottleRateActionBitsPerSecond и -ThrottleRateActionBytesPerSecond. В случае задания в байтах можно пользоваться сокращениями вида 10MB или 2MB, в случае бит – всё в явном виде, специально QWORD выделен под это. :)

Для HTTP мы можем задавать фильтрацию по URL – параметр -URIMatchCondition позволит задать URL, возвратный трафик с которого будет подпадать под данную политику. Т.е. если создать правило с -URIMatchCondition “http://www.atraining.ru” и ограничить полосу пропускания, то загружаемый с этого URL трафик на хост, на котором задана политика, будет ограничиваться указанными значениями.

Вариантов множество – думаю, Вы выберете себе подходящий.

Удач!