Data center bridging что это
Консолидация LAN и SAN сетей ЦОД на базе протоколов DCB и FCoE
Цель данной статьи — дать читателю базовое понимание технологий, благодаря которым стало возможным объединение двух сетей Ethernet и Fibre Channel (FC). Эти сети долгие годы строились параллельно и сопровождались независимо. Протоколы Data Center Bridging (DCB) и Fibre Channel over Ethernet (FCoE) позволяют совместить функции обеих на едином наборе оборудования, что экономит капитальные и операционные затраты на инфраструктуру Центров Обработки Данных.
Ethernet, без сомнения, самая популярная на сегодняшний день сетевая технология. За время существования Ethernet максимальная скорость передачи данных выросла с 10 Мбит/с до 100 Гбит/с. Ethernet вытеснил с рынка множество других протоколов, за счет своей простоты, дешевизны и широкой поддержки сетевой индустрией. В Ethernet сетях допустимы потери передаваемых данных, что категорически неприемлемо для сетей Fibre Channel. DCB – технология «улучшения» Ethernet, которая обеспечивает транспортировку данных без потерь. FCoE — протокол транспорта FC через «улучшенный» Ethernet.
Хотя DCB и FCoE используются совместно для построения целостного решения, это две разные технологии, и мы рассмотрим их по отдельности
Технология Data Center Bridging (DCB)
Что же требуется от Ethernet, чтобы обеспечить его применимость для транспорта FC? Этот вопрос являлся предметом пристального внимания сетевой индустрии и разработки стандартов на протяжении ряда лет и для обозначения набора усовершенствований Ethernet для нужд центров обработки данных появилось несколько терминов:
• CEE (Converged Enhanced Ethernet)– термин, предложенный компанией IBM и активно используемый в рамках процесса стандартизации Fibre Channel over Ethernet
• DCB (Data Center Bridging) – термин, используемый в процессе стандартизации различных усовершенствований Ethernet в комитетах организации IEEE
• DCE (Data Center Ethernet) – термин, используемый Cisco для обозначения архитектуры Ethernet нового поколения для задач центров обработки данных.
Для обозначения «улучшенного Ethernet» в дальнейшем в статье будет использоваться термин Data Center Bridging.
К основным компонентам решения Data Center Bridging относятся:
• Обеспечение транспорта без потерь (lossless Ethernet). Для этого необходимо выполнить два условия:
o Внутренняя архитектура коммутатора должна обеспечивать коммутацию данных без потерь. В частности, на коммутаторах Cisco Nexus это обеспечивается с использованием концепции VOQ (Virtual Output Queuing – организация виртуальных выходных очередей), которая предусматривает передачу данных через коммутационную матрицу к выходному порту только в случае, если он способен принять эти данные 
• Должны существовать механизмы управления потоком, которые не позволят отправить в сеть больше информации данного типа, чем сеть может передать в конкретный момент времени (аналогично тому, что обеспечивается в сетях Fibre Channel благодаря механизму Buffer-to-buffer Credits). В DCB был создан механизм управления потоком PFC (Priority-based Flow Control, IEEE 802.1Qbb), функционирующий отдельно для каждого класса трафика и позволяющий приостанавливать передачу данных сети хранения, не затрагивая управляющие данные и клиент-серверные сессии. Управление полосой, доступной разным типам трафика. Это необходимо для того, чтобы определить уровни обслуживания, предоставляемые для разных типов трафика в консолидированной сети, и тем самым сделать возможной их совместную передачу без ущерба для качества. Данная задача решается в архитектуре DCB с помощью механизма ETS (Enhanced Transmission Selection, IEEE 802.1Qaz).
• Автоматическое определение настроек взаимодействующих устройств. Это необходимо для автоматического обеспечения согласованных настроек управления потоком и выделенной полосы для разных типов трафика, логического состояния «виртуальных полос» и т.д., а также для определения того, поддерживает ли взаимодействующее устройство функции DCB, т.е. определения границы «домена» DCB в рамках сети Ethernet. Данную задачу решает протокол DCBX (Data Center Bridging Exchange), разрабатываемый в рамках IEEE 802.1Qaz.
Технология Fibre Channel over Ethernet (FCoE)
Передача информации протокола Fibre Channel через «улучшенный» Ethernet в архитектуре FCoE происходит с полным сохранением структуры кадров Fibre Channel – кадры Fibre Channel оснащаются дополнительными заголовками и помещаются внутрь кадров Ethernet.
Необходимо заметить, что из требования передачи (инкапусляции) кадров Fibre Channel следует два существенных дополнительных требования, предъявляемых FCoE к транспорту DCB:
• Поддержка больших кадров Ethernet. Поскольку максимальный размер кадра Fibre Channel превышает 2 килобайта, то он не может быть инкапсулирован в стандартный кадр Ethernet размером до 1518 байт, поэтому для передачи Fibre Channel через Ethernet необходима поддержка кадров большего размера – так называемых jumbo frames.
• Работа на скорости 10 Гбит/с и выше. Современные сервера, как правило, подключены к сети хранения на скорости 4-8 Гбит/с, поэтому, естественно, мы не можем использовать для консолидированного транспорта скорости 1 Гбит/с или ниже.
На сегодняшний день FCoE совместно с DCB имеют широкое применение, особенно на уровне подключения серверов к сети ЦОД, позволяя сократить в два раза количество сетевых адаптеров и коммутаторов, уменьшить кабельную инфраструктуру. Технология консолидации ввода-вывода является эффективным способом сокращения расходов на создание и эксплуатацию ЦОД, повышает гибкость и скорость развертывания новых сервисов.
Overview of Data Center Bridging
IEEE 802.1 Data Center Bridging (DCB) is a collection of standards that defines a unified 802.3 Ethernet media interface, or fabric, for local area network (LAN) and storage area network (SAN) technologies. DCB extends the current 802.1 bridging specification to support the coexistence of LAN-based and SAN-based applications over the same networking fabric within a data center. DCB also supports technologies, such as Fibre Channel over Ethernet (FCoE) and iSCSI, by defining link-level policies that prevent packet loss.
DCB consists of the following 802.1 draft standards that specify how networking devices can interoperate within a unified data center fabric:
Priority-based Flow Control (PFC)
PFC is specified in the IEEE 802.1Qbb draft standard. This standard is part of the framework for the DCB interface.
PFC supports the reliable delivery of data by substantially reducing packet loss due to congestion. This allows loss-sensitive protocols, such as FCoE, to coexist with traditional loss-insensitive protocols over the same unified fabric.
PFC specifies a link-level flow control mechanism between directly connected peers. PFC is similar to IEEE 802.3 PAUSE frames but operates on individual 802.1p priority levels instead. This allows a receiver to pause a transmitter on any priority level.
Enhanced Transmission Selection (ETS)
ETS is a transmission selection algorithm (TSA) that is specified in the IEEE 802.1Qaz draft standard. This standard is part of the framework for the DCB interface.
ETS allocates bandwidth between traffic classes that are assigned to different IEEE 802.1p priority levels. Each traffic class is allocated a percentage of available bandwidth on the data link between directlyconnected peers. If a traffic class doesn’t use its allocated bandwidth, ETS allows other traffic classes to use the available bandwidth that the traffic class is not using.
Data Center Bridging Exchange (DCBX) Protocol
The Data Center Bridging Exchange (DCBX) protocol is also specified in the IEEE 802.1Qaz draft standard. DCBX allows DCB configuration parameters to be exchanged between two directlyconnected peers. This allows these peers to adapt and tune Quality of Service (QoS) parameters to optimize data transfer over the connection.
DCBX is also used to detect conflicting QoS parameter settings between the network adapter (local peer) and the remote peer. Based on the local and remote QoS parameter settings, the miniport driver resolves the conflicts and derives a set of operational QoS parameters. The network adapter uses these operational parameters for the prioritized transmission of packets to the remote peer. For more information about how the driver resolves its operational NDIS QoS parameter settings, see Resolving Operational NDIS QoS Parameters.
DCBX consists of DCB type-length-value (TLV) settings that are carried over the Link Layer Discovery Protocol (LLDP) packets. LLDP is specified in the IEEE 802.1AB-2005 standard.
NoteВ В DCBX specifies that the local peer maintain configuration parameters from only one remote peer at any given time. As a result, the network adapter maintains only one set of local, remote, and operational NDIS QoS parameters.
Each ETS traffic class and PFC configuration setting is associated with an IEEE 802.1p priority level. The priority level is specified as a 3-bit value within a packet’s 802.1Q tag. For NDIS packets, the 802.1p priority level is specified by the UserPriority member of the NDIS_NET_BUFFER_LIST_8021Q_INFO structure that is associated with a packet’s NET_BUFFER_LIST structure.
For more information about priority levels, see IEEE 802.1p Priority Levels.
Обзор моста центров обработки данных
Мосты в центре обработки данных (DCB) IEEE 802,1 — это набор стандартов, который определяет 802,3 унифицированный интерфейс медиа-мультимедиа (или структуру) Ethernet для технологий локальной сети (LAN) и сети хранения данных (SAN). DCB расширяет текущую спецификацию моста 802,1 для поддержки сосуществования приложений на основе локальной сети и SAN в рамках одной сетевой структуры в центре обработки данных. DCB также поддерживает такие технологии, как Fibre Channel over Ethernet (Фкое) и iSCSI, путем определения политик уровня связи, предотвращающих потери пакетов.
DCB состоит из следующих 802,1 черных стандартов, указывающих, как сетевые устройства могут взаимодействовать в рамках единой структуры центра обработки данных.
управление Flow на основе приоритета (коэффициент мощности)
Коэффициент компенсаций указывается в стандарте черновика IEEE 802.1 КББ. Этот стандарт является частью платформы для интерфейса DCB.
Коэффициент мощности обеспечивает надежную доставку данных путем значительного снижения потери пакетов из-за перегрузки. Это позволяет протоколам с потерей данных, таким как Фкое, сосуществовать с традиционными протоколами, не учитывающими потери данных, в одной объединенной структуре.
Коэффициент мощности задает механизм управления потоком на уровне связи между напрямую подключенными одноранговыми узлами. Коэффициент компенсаций напоминает кадры приостановки IEEE 802,3, но работает с отдельными уровнями приоритета 802.1 p. Это позволяет получателю приостанавливать передатчики на любом уровне приоритета.
дополнительные сведения о коэффициенте компенсаций см. в разделе элемент управления Flow на основе приоритета (коэффициент мощности).
Расширенный выбор передачи (ETS)
ETS — это алгоритм выбора передачи (TSA), который указывается в стандарте IEEE 802.1 Каз. Этот стандарт является частью платформы для интерфейса DCB.
ETS выделяет пропускную способность между классами трафика, назначенными разным уровням приоритета IEEE 802.1 p. Каждому классу трафика выделяется процент доступной пропускной способности по каналу данных между одноранговыми узлами директликоннектед. Если класс трафика не использует выделенную пропускную способность, ETS позволяет другим классам трафика использовать доступную пропускную способность, которую не использует класс трафика.
Дополнительные сведения о ETS см. в разделе Улучшенный алгоритм выбора передачи (ETS).
протокол Exchange моста центра обработки данных (дкбкс)
протокол Exchange «мост центра обработки данных» (дкбкс) также указывается в стандарте IEEE 802.1 каз. ДКБКС разрешает обмен параметрами конфигурации DCB между двумя одноранговыми узлами директликоннектед. Это позволяет этим одноранговым узлам адаптировать и настраивать параметры качества обслуживания (QoS) для оптимизации передачи данных через соединение.
ДКБКС также используется для обнаружения конфликтующих параметров параметров качества обслуживания между сетевым адаптером (локальным узлом) и удаленным одноранговым узлом. На основе параметров локального и удаленного качества обслуживания драйвер минипорта разрешает конфликты и получает набор параметров оперативного качества обслуживания. Сетевой адаптер использует эти операционные параметры для приоритетной передачи пакетов на удаленный узел. Дополнительные сведения о том, как драйвер разрешает свои рабочие параметры качества по NDIS, см. в разделе разрешение рабочих параметров качества по NDIS.
ДКБКС состоит из параметров типа DCB-length-value (TLV), которые переносятся на пакеты LLDP. LLDP задается в стандарте IEEE 802.1 AB-2005.
Дополнительные сведения об уровнях приоритетов см. в разделе уровни приоритетов IEEE 802.1 p.
antiCisco blogs
блоги по технологиям и оборудованию cisco от инструкторов
Fibre Channel over Ethernet
Предпосылки к появлению
FCoE еще называют унифицированной фабрикой (Unified Fabric). Отчего же так повелось? Давайте окунемся на некоторое время назад и вспомним (а кто-то просто узнает) как раньше строились сети. Отдельно существовала LAN сеть, отдельно SAN.
Это не очень удобно: на серверах были отдельные адаптеры для FC и Ethernet, требовалось больше коммутаторов, следовательно возрастала административная нагрузка. FCoE же позволяет уйти от этих проблем. Главное, чтобы сетевые устройства и сервера поддерживали технологию.
Прим. Сетевые адаптеры, которые умеют передавать как FC, так и Ethernet трафик, называются Converged Network Adapter (CNA).
Обзор технологии
FCoE позволяет передавать Fibre Channel (FC) трафик через физический Ethernet порт. Все FCoE фреймы используют уникальный EtherType (0x8906), который позволяет коммутатору понять, что к нему пришел не просто Ethernet, а FC. Ниже представлена FCoE инкапсуляция.
Существует одна большая проблема: Ethernet по-умолчанию является протоколом, который никому ничего не должен и ничего не гарантирует – фреймы могут дропаться (по разным причинам). FC же требуется среда без потерь (lossless среда), что связано с работой протоколов более высокого уровня (SCSI). Напомню, что в FC такого рода бездропная передача фреймов организована с помощью Buffer-to-Buffer кредитов.
Соответственно если мы хотим передать FC трафик поверх Ethernet’а, то придется его несколько модифицировать. В частности, появились такие технологии, как link-level flow control (LLFC) и priority flow control (PFC).
FCoE Initialization Protocol (FIP)
Если Data Plane для FCoE не представляет особого интереса, то вот процесс Control Plane довольно интересен. У FC протоколом на CP является FIP. Рассмотрим его основные функции.
FIP vlan Discovery. FCoE фреймы передаются в рамках vlan’ы. Для FCF важно понимать, к какой VSAN’е относится тот или иной фрейм. Поэтом первым делом необходимо узнать vlan’у для передачи трафика. При подключении, конечная станции высылает служебное сообщение на зарезервированный мультикастный МАС-адрес, который прослушивается всеми FCF. Эти сообщение передаются в рамках native vlan, все последующие – в рамках узнанной только что vlan.
FIP FCF Discovery. Это процесс поиска FCF, который готов обслужить процесс залогирования в фабрику. Этап необходим для информирования сервера о том, что FCoE vlan’а готова для установления логического FC туннеля между двумя сторонами.
FIP FLOGI. После получения FCoE VLAN и FCoE MAC можно начинать классический FC процесс FLOGI. FCoE FLOGI это юникастовый фрейм, полностью аналогичный фрейму в FC.
Прим. Все FIP сообщения передаются с Ethertype 0x8914
Прим. FIP и FCoE фреймы используют разный Source MAC. Для FIP используется встроенный производителем адрес в CAN. Для FCoE используется МАС, полученный от фабрики (Fabric Provided MAC Address, FPMA).
Data Center Bridging
Помните что происходит в FC, когда на одной из станции кончаются кредиты? Правильно, высылается сообщение PAUSE. Это и есть метод, обеспечивающий lossless среду. Примерно тоже самое перенесли из FC на FCoE, но с некоторыми дополнениями и улучшениями, в частности:
Рассмотрим эти тенхологии по отдельности.
Priority Flow Control (802.1Qbb)
Сообщение 802.3x PAUSE работает как и задумано – заставляет передатчик прекратить передачу. Но такое поведение имеет определенные минусы – перестает передаваться абсолютно весь трафик, независимо от того, насколько он критичен (иначе говоря, не смотрится QoS приоритет). Т.е. PAUSE для одного приложения может повлиять на передачу данных других, более важных приложений.
Стандарт 802.1Qbb расширяет базовый 802.3X PAUSE функционал, вводя понятие PAUSE per CoS. PFC использует 802.1p CoS значения внутри 802.1Q заголовка для передачи PAUSE только для конкретного класса обслуживания (или для нескольких сразу). На рисунке ниже представлено сравнение фреймов 802.3x и 802.1Qbb. Поле Pad отвечает за интервал времени, на которое требуется приостановить передачу. Если Pad=0, то CoS следует снять с паузы.
Enhanced Transmission Selection (802.1Qaz)
Всем вам хорошо известен классический QoS: WRR/DWRR, Priority Queue и т.д. Все эти методы характеризует одно: администратор задает коэффициенты, согласно которым тому или иному классу трафика выделяется определенное количество полосы пропускания в случае перегрузки линка. ETS позволяет проводить динамическое распределение полосы пропускания между классами трафика по необходимости. Если кратко, то решение о том, сколько полосы выделить, базируется на метке CoS.
Data Center Bridging Exhange Porotocol (802.1Qaz)
DCBX это p2p протокол, который используется для обнаружения соседей и обмена конфигурационной информацией между DCB-совместимыми коммутаторами.
DCBX для транспорта использует протокол LLDP, в котором используются специальные TLV для переноса нужной информации. Вот его основные функции:
Настройка FCoE
В этом разделе мы посмотрим, как настраивается FCoE на коммутаторе Nexus 5500. В качестве тестовой среды используется следующая топология
Вся настройка состоит из нескольких шагов. Я буду подразумевать, что FC связность между N5K и MDS уже настроена. SAN_A относится к vsan 100, SAN_B к vsan 200 (пример конфига привожу только для SAN_A, т.к. для SAN_B все точно такое же).
Команда switchport trunk native vlan в моем случае – аналог switchport access vlan 10, т.к. на тестовом сервере не создано никаких виртуальных машин (просто стоит Win2008) и все фреймы в LAN идут нетегированными.
Далее настраивается zoning и прочие прелести нативного fibre channel.
DataCenter Bridging / Networking (DCB/DCN) в Windows Server 2012 R2
Настройка технологий семейства DataCenter Bridging / DataCenter Networking в Windows Server 2012
Технологии семейства DCB (они же DCN – DataCenter Networking) – редкая тема для обсуждения, хотя их поддержка появилась ещё в Windows Server 2012. Отсутствие информации в авторизованных курсах плюс традиционно слабая подготовка преподавателей Microsoft в сетевых технологиях сделали своё чёрное дело – “технология есть, а плода – нет” (ц) к/ф “ДМБ”. Около 100% рекомендаций выглядят как “ну типа клёвая штука, на серверах можно включать, оно там чего-то лучше станет делать”.
Попробуем разобраться, что, зачем и почему следует из включения данной одинокой галки в Add Roles and Features. Я предполагаю, что Вы знакомы с сетевыми технологиями хотя бы на уровне азбучных вопросов курса Cisco ICND1 3.0. Если нет – лучше вначале изучить его, это бесплатно.
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, но это уже совсем другая история.
Со всем этим надо было бороться, потому что на горизонте замаячило мега-объединение всех сетевых трафиков в пределах одной физической среды пропускания – всякие фабрики и прочее.
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)
Для всего этого используется “прокачаный” протокол 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 глобально – ну нет у нас в сети таких коммутаторов особо умных, либо это виртуальная сеть “точка-точка” между двумя виртуалками – это делается так:
Это, подчеркну, именно про 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:
Если надо, можно указать несколько классов через запятую и без пробелов. Выключить, если что, так же, только Disable вместо Enable.
После того, как включили нужные классы в DCB-работу – можно настраивать 802.1Qaz.
Настройка Enhanced Transmission Selection в DCB для Windows Server 2012 R2
Созданим классы трафика – определения, нужные для того, чтобы было удобно именовать информацию вида “Трафику с таким приоритетом выделить столько полосы по такой-то логике”. Учитывайте, что к одному классу трафика (фактически, priority group) можно привязать более одного 802.1p-приоритета, а наоборот – нет.
Создадим, например, класс для RDP-трафика – ну, хочется нам, чтобы у людей лучше и стабильнее работал доступ к терминальному серверу.
Пока классы не созданы, все 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 приоритет. Для начала созданим базовую политику, а потом посмотрим на тонкости настроек.
Вариантов множество – думаю, Вы выберете себе подходящий.