Flow control что это
Обновлено: 05.07.2024
Продолжаю вещать на тему прояснения основных представлений об FC SAN. В комментариях к первому посту меня попрекнули тем, что копнул недостаточно глубоко. В частности — мало сказал о непосредственно FC и ничего о BB credits, IP и multipathing. Multipathing и IP — темы для отдельных публикаций, а про FC, пожалуй, продолжу. Или начну, как посмотреть.
Для начала, небольшое терминологическое отступление (навеянное опять же комментарием к предыдущему посту).
Fibre or Fiber?: Изначально технология Fibre Channel предполагала поддержку только волоконно-оптических линий (fiber optic). Однако, когда добавилась поддержка меди, было принято решение название в принципе сохранить, но для отсылки на стандарт использовать британское слово Fibre. Американское Fiber сохраняется преимущественно для отсылки на оптоволокно.Fibre Channel was originally designed to support fiber optic cabling only. When copper support was added, the committee decided to keep the name in principle, but to use the UK English spelling (Fibre) when referring to the standard. The US English spelling (Fiber) is retained when referring generically to fiber optics and cabling.
IBM Redbook «Introduction to SAN and System Networking»
Начало
По аналогии с сетевой моделью OSI, Fibre Channel состоит из пяти уровней. Каждый уровень обеспечивает определённый набор функций.
FC-0 — уровень физических интерфейсов и носителей. Описывает физическую среду: кабели, коннекторы, HBA, трансиверы, электрические и оптические параметры.
- Fibre Channel Protocol for SCSI-3 (SCSI-FCP) — проброс SCSI
- Fibre Channel Link Encapsulation (FC-LE) — проброс TCP/IP
А теперь подробнее об этих и других непонятных словосочетаниях. В данной статье рассмотрим только нижние три уровня, как наиболее значимые при создании и управлении инфраструктурой FC SAN.
Отдельно хочу упомянуть про такой термин как тёмная оптика (dark fiber). Сей термин не значит, что она как-то специальным образом тонирована. Это просто выделенные оптические линии связи, как правило, для связи на больших расстояниях (между городами или далеко отстоящими зданиями), которые берутся в аренду, и для использования которых не требуется дополнительное оборудования усиления сигнала (его обеспечивает владелец). Однако, так как это просто оптический кабель, отданный в ваше полновластное распоряжение, до тех пор пока вы не пустите по нему свой световой сигнал, он остаётся «тёмным».
ASIC (аббревиатура от англ. application-specific integrated circuit, «интегральная схема специального назначения») — интегральная схема, специализированная для решения конкретной задачи. В отличие от интегральных схем общего назначения, специализированные интегральные схемы применяются в конкретном устройстве и выполняют строго ограниченные функции, характерные только для данного устройства; вследствие этого выполнение функций происходит быстрее и, в конечном счёте, дешевле. Примером ASIC может являться микросхема, разработанная исключительно для управления мобильным телефоном, микросхемы аппаратного кодирования/декодирования аудио- и видео-сигналов (сигнальные процессоры).
- Encoder / Decoder — обеспечивает кодирование каждых 8 бит передаваемых данных в 10-битное представление. И декодирование обратно принимаемых данных.
- SERDES (Serializer / Deserializer) — преобразует параллельный поток 10-битных порций данных в последовательный поток 10-битных порций данных.
- Transceiver — преобразует электрические импульсы в световые сигналы.
Transceivers, трансиверы или SFP — в случае FC-коммутаторов это отдельные модули, необходимые для подключения кабеля к порту. Различаются на коротковолновые (Short Wave, SW, SX) и длинноволновые (Long Wave, LW, LX). LW-трансиверы совместимы с многомодовым и одномодовым волокном. SW-трансиверы — только с многомодовым. И к тем и к другим кабель подключается разъёмом LC.
Есть ещё SFP xWDM (Wavelenght Division Multiplexing), предназначенные для передачи данных из нескольких источников на дальние расстояния единым световым пучком. Для подключения кабеля к ним используется разъём SC.
8/10 и 64/66
Первое, что происходит на этом уровне — кодирование / декодирование информации. Это довольно мудрёный процесс, в ходе которого каждые 8 бит поступающей информации преобразуются в 10-битное представление. Делается это с целью повышения контроля целостности данных, отделения данных от служебных сигналов и возможности восстановления тактового сигнала из потока данных (сохранение баланса нулей и единиц).
Это ведёт к заметному снижению полезной пропускной способности, ибо как можно подсчитать, 20% потока данных является избыточной служебной информацией. А ведь кроме всего прочего, немалую часть этого потока может занимать служебный трафик.
Однако хорошая новость в том, что кодирование 8/10 используется в оборудовании 1G, 2G, 4G и 8G. В части реализаций 10G и начиная с 16G кодирование осуществляется по принципу 64/66, что существенно увеличивает полезную нагрузку (до 97% против 80% в случае 8/10).
Ordered sets
- Разделители фреймов (Start-of-Frame, SOF и End-of-Frame, EOF).
- Два базовых сигнала — IDLE (порт готов принимать или передавать данные) и R_RDY (receiver ready — порт освободил буфер для приёма очередной порции данных)
- Базовые последовательности (primitive sequences):
- NOS (Not Operational) — порт обнаружил разрыв / отсутствие соединения
- OLS (Offline State) — порт инициирует установление соединения, или порт получил NOS, или порт переходит в состояние off-line
- LR (Link Reset) — инициализация сброса соединения. Отправляется в случае получения OLS или каких-то ошибок приёма-передачи (как правило, на уровне Flow Control). Отправивший порт очищает свои буферы и их счётчики
- LRR (Link Reset Response) — ответ на LR. Отправивший порт очищает свои буферы и их счётчики
Инициализация соединения (Link initialization)
При установлении физического соединения между портами A и B, между ними происходит следующий «обмен веществ»:
Фреймы (Кадры, Frames)
- SoF — 4 байта (1 tw) — идентификатор начала фрейма.
- Header — 24 байта (6 tw) — заголовок. Содержит такую информацию как адрес источника и приёмника, тип фрейма (FT-0 — управляющий или FT-1 — данные), номер последовательности и порядковый номер фрейма в ней и прочая служебно-контрольная информация.
- Data — 0-2112 байт (0-528 tw) — непосредственно данные (например, SCSI-команды).
- CRC — 4 байта (1 tw) — контрольная сумма.
- EoF — 4 байта (1 tw) — идентификатор конца фрейма.
Промежутки между фреймами заполняются специальными «заполняющими словами» — fill word. Как правило, это IDLE, хотя начиная с FC 8G было стандартизовано использование ARB(FF) вместо IDLE, в целях снижения электрических помех в медном оборудовании (но по-умолчанию коммутаторами используется IDLE).
Последовательности (Sequences)
Чаще всего источник стремится передать приёмнику гораздо больше информации, чем 2112 байт (максимальный объём данных одного фрейма). В этом случае информация разбивается на несколько фреймов, а набор этих фреймов называется последовательностью (sequence). Чтобы в логическую последовательность фреймов не вклинилось что-то лишнее при параллельной передаче, заголовок каждого фрейма имеет поля SEQ_ID (идентификатор последовательности) и SEQ_CNT (номер фрейма в последовательности).
Обмен (Exchange)
Одна или несколько последовательностей, отвечающих за какую-то одиночную операцию, называется обменом. Источник и приёмник могут иметь несколько параллельных обменов, но каждый обмен в единицу времени может содержать только одну последовательность. Пример обмена: инициатор запрашивает данные (последовательность 1), таргет возвращает данные инициатору (последовательность 2) и затем сообщает статус (последовательность 3). В этот набор последовательностей не может вклиниться какой-то посторонний набор фреймов.
Для контроля этого процесса заголовок каждого фрейма включает поля OX_ID (Originator Exchange ID — заполняется инициатором обмена) и RX_ID (Responder Exchange ID — заполняется получателем в ответных фреймах, путём копирования значения OX_ID).
Классы обслуживания (Classes of Services)
Различные приложения предъявляют разные требования к уровню сервиса, гарантии доставки, продолжительности соединения и пропускной способности. Некоторым приложениям требуется гарантированная пропускная способность в течение их работы (бэкап). Другие имеют переменную активность и не требуют постоянной гарантированной пропускной способности канала, но им нужно подтверждение в получении каждого отправленного пакета. Для удовлетворения таких потребностей и обеспечения гибкости, FC определяет следующие 6 классов обслуживания.
Class 1
Для этого класса устанавливается выделенное соединение, которое резервирует максимальную полосу пропускания между двумя устройствами. Требует подтверждения о получении. Требует чтобы фреймы попадали на приёмник в том же порядке, что вышли из источника. Ввиду того, что не даёт другим устройствам использовать среду передачи, используется крайне редко.
Class 2
Без постоянного соединения, но с подтверждением доставки. Не требует соответствия порядка отправленных и доставленных фреймов, так что они могут проходить через фабрику разными путями. Менее требователен к ресурсам, чем класс 1, но подтверждение доставки приводит к повышенной утилизации пропускной способности.
Class 3
Без постоянного соединения и без подтверждения доставки. Самый оптимальный с точки зрения использования ресурсов фабрики, но предполагает, что протоколы верхних уровней смогут собрать фреймы в нужном порядке и перезапросить передачу пропавших фреймов. Наиболее часто используемый.
Class 4
Требует постоянного соединения, подтверждение и порядок фреймов как и класс 1. Главное отличие — он резервирует не всю полосу пропускания, а только её часть. Это гарантирует определённое QoS. Подходит для мультимедиа и Enterprise-приложений, требующих гарантированного качества соединения.
Class 5
Ещё до конца не описан и не включен в стандарт. Предварительно, класс, не требующий соединения, но требующий немедленной доставки данных по мере их появления, без буферизации на устройствах.
Class 6
Вариант класса 1, но мультикастовый. То есть от одного порта к нескольким источникам.
Class F
Класс F определён в стандарте FC-SW для использования в межкоммутаторных соединениях (Interswitch Link, ISL). Это сервис без постоянного соединения с уведомлениями о сбое доставки, использующийся для контроля, управления и конфигурирования фабрики. Принцип похож на класс 2, но тот используется для взаимодейтсвия между N-портами (порты нод), а класс F — для общения E-портов (межкоммутаторных).
Flow Control
В целях предотвращения ситуации, когда отправитель перегрузит получателя избыточным количеством фреймов так, что они начнут отбрасываться получателем, FC использует механизмы управления потоком передаваемых данных (Flow Control). Их два — Buffer-to-Buffer flow control и End-to-End flow control. Их использование регламентируется классом обслуживания. Например, класс 1 использует только механизм End-to-End, класс 3 — Buffer-to-Buffer, а класс 2 — оба эти механизма.
Buffer-to-Buffer flow control
Принцип технологии — кредит в каждый дом отправка любого фрейма должна быть обеспечена наличием кредита на отправку.
Все поступающие на вход порта фреймы помещаются в специальную очередь — буферы. Количество этих буферов определяется физическими характеристиками порта. Один буфер (место в очереди) соответствует одному кредиту. Каждый порт имеет два счётчика кредитов:
TX BB_Credit — счётчик кредитов передачи. После отправки каждого фрейма, уменьшается на 1. Если значение счётчика стало равным нулю — передача невозможна. Как только от порта-приёмника получено R_RDY, счётчик увеличивается на 1.
RX BB_Credit — счётчик кредитов приёма. Как только фрейм принят и помещён в буфер, уменьшается на 1. Когда фрейм обрабатывается или пересылается дальше, счётчик увеличивается на 1, а отправителю отправляется R_RDY. Если значение счётчика падает до 0, то в принципе, приём новых фреймов должен быть прекращён. На практике, из-за ошибок синхронизации кредитов может возникнуть ситуация, что источник прислал ещё один-несколько фреймов уже после того как RX BB_credit стал равен нулю. Данная ситуация называется buffer overflow. В большинстве реализаций порт обрабатывает такие ситуации «по-доброму» — за счёт резервных буферов. Хотя некоторое оборудование в таких случаях может сынициировать Link Reset.
Отсюда исходит сильное влияние расстояния между портами на производительность. Чем выше расстояние и больше пропускная способность, тем больше фреймов будет отправлено (читай кредитов передачи потрачено) ещё до того как получатель получит хотя бы первый. Ситуацию облегчает особенность архитектуры FC-коммутаторов. Дело в том, что количество буферов не закреплено жёстко за каждым портом (кроме восьми обязательных), а является общим для всех. И в случае определения «дальних линков» (автоматически или вручную) количество выделяемых коммутатором буферов для этого порта увеличивается. Другой плюс общей памяти — не требуется гонять буферы от одного порта к другому внутри коммутатора.
End-to-End flow control
Конец
Изначально мне казалось, что статья будет раза в два меньше, но в ходе написания всплыло много деталей, без которых счастье казалось не полным. Ещё кучу вещей, которые хотелось бы осветить, пришлось пока отбросить — процесс написания грозил стать бесконечным. Если у кого-то возникнут замечания, предложения и пожелания к тому, про что ещё стоит написать, буду признателен. И спасибо всем, кто дочитал до этого места.
Были использованы материалы из следующих источников:
IBM Redbook «Introduction to SAN and System Networking»
EMC «Network Storage Concepts and Protocols»
Brocade «SAN Fabric Administration Best Practices Guide»
Включать или нет: только если наблюдаются странности в работе сети при большом количестве входящего трафика (обычно для игр включать ненужно).
Функция полезна, когда происходит загрузка большого количества данных, например торренты. Игры обычно не имеют настолько активный трафик.
Функция например присутствует в сетевом адаптере D-Link DFE-550TX.
Flow Control включать стоит, когда наблюдаются непонятные задержки, обрывы, пропадания, лаги, тормоза при просмотре онлайн-видео. Также эту опцию включают при соединении разноскоростного оборудования или разноскоростных сетей, образно говоря, чтобы скоростная сеть не забила трафиком порт менеескоростной.
Опция сетевого адаптера Realtek:
Однако также спокойно может встречаться и в адаптерах других производителей, например Intel, Atheros.
«Распределенное управление информационными потоками»/«Distributed Information Flow Control»
Мотивация
Практически единственным способом обеспечивать безопасность и приватность данных в системе принято считать аутенификацию (отвечает на вопрос: «Кто это сказал?») и авторизацию («Что он имеет право делать с этими данными»). Т.е. если программе необходим доступ к некоторым данным, мы фактически имеем 2 варианта: отказать или поверить. Если мы не доверяем этой программе, то теряем возможность работать с ней и возможно лишаемся важной функциональности. Если же мы решаем, что доверяем программе (и/или ее разработчикам), то программа фактически становится «полновластным хозяином» этой информации (или копии). Такой принцип в литературе называют All-Or-Nothing — «Все или ничего».
Естественно, что этот принцип недостаточно гибок и кроме того является основной причиной многих уязвимостей в системах, таких как переполнение буфера. В общем случае, этот принцип не позволяет создавать более интересные приложения, где права доступа не ограничиваются традиционными: «no access», «read only» и «read/write». Оказывается, что существуют системы, которые позволяют намного более гибкие разграничения прав доступа к данным — системы с поддержкой управления информационными потоками. Самой главной особенностью этих систем является то, что они следят за данными на всем протяжении их жизненного цикла в системе. Вспомним, что традиционно система ответственна только за начальный доступ к данным, например, проверку имеет ли программа доступ к файлу, а что после этого программа делает с этими данными систему уже не интересует.
Классический пример. Допустим, что в системе есть 2 пользователя Алиса и Боб. Они хотят назначить встречу, но так чтобы не раскрывать слишком много информации о своем расписании недели. Можно ли в многопользовательской системе Linux/Unix/Windows написать программу таким образом, чтобы она имела одновременный доступ к календарям и Алисы, и Боба и гарантировала конфиденциальность обоих пользователей системы?
Самый простой способ — попросить «суперпользователя» написать такую программу или хотя бы правильно назначить права на уже существующе решение. Но этот путь создает как минимум 2 проблемы:
1. Нет гарантии, что программа не содержит логических ошибок и, например, не скопирует данные Алисы куда-нибудь еще (или админ неправильно назначит права).
2. Нужно доверять на все 100% «суперпользователю» и кроме того, такой процесс неинтерактивен, т.е. ждать пока админ напишет такую программу или выставит права.
Решение первой проблемы осуществляется при помощи систем с поддержкой управления информационными потоками.
В общем системы с поддержкой управления информационными потоками условно делятся на 2 категории: централизованные и распределенные (децентрализованные). К централизованным относят всем известные SELinux и AppArmor. В этой же статье я постараюсь рассказать о децентрализованных системах, на примере исследовательской (следовательно совершенно непригодной для реального использования, к сожалению) ОС Flume, т.к. имел некоторый опыт «общения» с ней. Децентрализованные системы позволяют избавиться и от второй проблемы — зависимость от суперпользователя.
(Distributed) Information Flow Control
Если кратко, то идея контроля потока информации тривиальна и заключется в том, чтобы отслеживать как данные «перетекают» в системе от отправителя к получателю. Главная задача системы предотвратить несанкционированную утечку данных из нее. В общем случае, ни одна программа (кроме «привилегированной») не может иметь одновременный (в контексте жизни программы) доступ к приватным данным и любому «стоку информации» (sink), таким как монитор, принтер, сокет (AF_INET). Т.е. если программа один раз прочитала мои личные файлы, то после этого система не позволит этой программе иметь доступ к сети.
Для того чтобы сделать данные приватными необходимо явно это указать, например, с помощью специальных флагов/тэгов. Вот тут и главное различие между централизованными и распределенными системами. В первом случае существует особый пользователь — «менеджер безопасности», который ответственен за правильное «тэгирование» данных и определение прав доступа различных программ к таким данным. Например, можно назначить тэг «особо секретно» на файлы с вашими паролями или информацией о личных доходах и разрешить доступ к нему только для Vim/Emacs без прав (1) эти данные экспортировать куда бы то ни было и (2) снять эти тэги. Таким образом, даже если скомпроментировать ваши текстовые редакторы, то система (предполагая, что сама система безопасна и работает без ошибок) не позволит сохранить эти файлы где-либо в системе (/tmp) с другими более разрешающими тэгами и отослать их каким-либо образом в Интернет. Я не работал с SELinux, поэтому отсылаю вас к официальным руководствам за дальнейшей информацией.
В распределенных же системах любая программа/сущность может создавать свои тэги, назначать права и давать доступ к своим данным для других программ.
В ОС Flume вы можете создать тэг для доступа к некоторым личным данным. Причем у вас есть выбор. Можно отдать в открытый доступ права на назначение этого тэга и/или на его удаление. Допустим, что мы создали тэг tag1 и отдали в открытый доступ право , тогда любая программа может поместить этот тэг в свой собственный набор тэгов. Если мы создадим файл F и ассоциируем его с тэгом tag1, то любой процесс p1 может включить в свой набор тэгов этот тэг tag1 и после этого сможет читать все данные, помеченные tag1. Однако, так как не в открытом доступе, то этот процесс не сможет удалить tag1 со своего набора тэгов и отныне может общаться только с процессами, с набором тэгов, которые являются надмножеством аналогичного набора процесса p1.
Flume — это одна из разработанных систем, которая обеспечивает «правильность» потока информации. На системном уровне Flume — это Linux с модифицированной системой LSM, которая перехватывает основные системные вызовы, хранит информацию о тэгах, метках и проверяет на корректность потока данных от одного процесса к другому.
Теперь вернемся к примеру с календарем Алисы и Боба. В ОС Flume Алиса назначит тэг A для своего календаря, а Bob для своего — тэг B. Алиса отдает в открытый доступ , а Боб . Боб запускает программу с меткой , т.е. с возможностью доступа к обоим календарям. Эта программа находит несколько удобных временных промежутков, где ни Алиса, ни Боб не заняты, снимает с себя тэг B ( в открытом доступе) и записывает результат в файл F, который получает автоматический тэг A ( не в открытом доступе). Алиса открывает файл F, т.к. она является владельцем тэга A и выбирает конкретную дату из списка «предложенных Бобом». На всякий случай напомню, что не в открытом доступе, поэтому Алиса не может читать календарь Боба.
Заключение
К сожалению, я не смогу охватить всех сфер применимости идей DIFC (даже тех, которые использовал в качестве мотивации проблемы) Есть немало отличных статей на эту тему, начинаю с самых классических (Jiff) до достаточно свежих HiStar/DStar или Resin. При наличии интереса к данной теме могу более подробно/формально рассказать о, например, фреймворке Resin от MIT. В свое время посчастливилось побеседовать с Барбарой Лисков (которая является, наверное, одной из главных авторитетов в данной области) на тему контроля потока информации, применимости этих принципов для других задач и просто заболел этой темой. Есть несколько интересных «видений» развития этой идеи: W5 (world wide web without walls) или Fabric. Но это уже совершенно другая история…
Какое значение опции выбрать?
Если установить значение опции Flow Control, равное None, то это означает, что контроль потока будет отсутствовать. В такой ситуации в процессе передачи данных может возникнуть переполнение буфера принимающего компьютера. В большинстве случаев эта ситуация нежелательна. Установка значения опции, равного Hardware или Software, помогает избежать этого.
Однако на практике часто встречается такая ситуация, когда одно из двух сетевых устройств, соединенных между собой, не поддерживает технологию Flow Control. В таком случае эту опцию лучше всего выключить, чтобы избежать ошибок. По умолчанию в большинстве случаев опция Flow Control также установлена в значение None.
Ненадёжный Ethernet
Ненадёжный Ethernet
Jumbo Frame
В случае использования протоколов NFS , iSCSI , CIFS рекомендуется по возможности включать jumbo frame, на коммутаторах и хостах. СХД NetApp поддерживает на данный момент размер MTU 9000, что пока что является максимальным значением для Ethernet 10GB. В этом случае jumbo frame должны быть включены на всём пути следования Ethernet фреймов: от источника до получателя. К сожалению не во всех коммутаторах и не на всех сетевых адаптерах хостов поддерживается «максимальный» на данный момент MTU , так к примену некоторые блейд-шасси HP с серверами и встроенными 10GB коммутаторами поддерживают максимум 8000 MTU , для таких случаев на стороне СХД необходимо подбирать наиболее подходящее значение MTU . Так как есть некотарая путаница в том, что такое MTU , есть трудности с пониманием какое значение MTU нужно настроить. Так к примеру для нормальной работы СХД NetApp с установленным значением MTU 9000 на Ethernet интерфейсе будет «нормально» работать со свичами у которы значение MTU установлено в одно из значений: 9000 (Catalyst 2970/2960/3750/3560 Series), 9198 (Catalyst 3850), 9216 (Cisco Nexus 3000/5000/7000/9000, Catalyst 6000/6500 / Cisco 7600 OSR Series), на других это значение вообще должно быть 9252. Как правило, установив MTU на свиче в максимально допустимое значение (выше или равно 9000), всё будет работать. Для разъяснения, рекомендую прочесть соответствующую статью Maximum Transmission Unit (MTU). Мифы и рифы.
Jumbo Frames в Cisco UCS
Выполняем инастройку из командной строки на каждом Fabric Interconnect:
В настройках UCS Manager при работе с Ethernet настраиваем MTU во вкладке «Lan > Lan Cloud > QoS System Class», прописываем MTU одному выбранному классу.Потом создаём «QoS политику»
Создаём vNIC template
Привязываем к сетевому интерфейсу сервера.
FlowControl
- Общее правило гласит по возможности не включать flowcontrol, TR-3428.
- Для 10GB сетей крайне не рекомендуется включать flowcontrol.
- Для сетей 1GB можно включать flowcontrol (в качестве исключения из правила): хранилище отсылает управление потоком, а свитч принимает — на СХД устанавливать flowcontrol в значение send, а на свитче в значение Desired (или send/tx off & receive/rx on).
- Для 100 MB сетей (в качестве исключения из правила) можно включать flowcontrolна приём и передачу на обоих: хранилище и свитч отсылают и принимают команды управления потоком.
- Тем, кому интересно почему такие рекомендации, вам сюда.
- Дополнительно смотри TR -3802
- Примеры настройки хранилища и свичий можно посмотреть в соответствующих статьях.
Spanning Tree Protocol
В случае использования NetApp с «классическим Ethernet» (т.е. Ethernet который так сказать «не уровня „Datacenter“) крайне рекомендуется включить RSTP , а Ethernet порты, в которые подключены конечные узлы (СХД и хосты) настроить с включенным режимом portfast, TR-3749. Ethernet сети уровня „Datacenter“ вообще не нуждаются в Spanning Tree, примером такого оборудования могут служить коммутаторы Cisco серии Nexus с технологией vPC .
Converged Network
FC8 vs 10GBE: iSCSI, CIFS, NFS
Современные конвергентные коммутаторы, такие как Cisco Nexus 5500 способны коммутировать как трафик Ethernet так и FC позволяя иметь большую гибкость в будущем благодаря решению „два-в-одном“.
Также не забываете о возможности агрегации портов при помощи EtherChannel LACP . Нужно также понимать, что агрегация не объединяет волшебным образом Ethernet порты, а всего лишь распределяет (балансирует) трафик между ними, другими словами два агрегированных 10GBE порта далеко не всегда „дотягивают“ до 20GBE . Здесь стоит отметить, что в зависимости от того, находится ли СХД в отдельной IP подсети от хостов, нужно выбирать правильный метод балансировки. В случае когда СХД находится в отдельной подсети от хостов нельзя выбирать балансировку по MAC (дестинейшина), так как он будет всегда один и тот-же — MAC адрес шлюза. В случае когда хостов меньше, чем количество агрегированных линков на СХД , балансировка работает не оптимальным образом в виду не совершенства и ограничений сетевых алгоритмов балансировки нагрузки. И наоборот: чем больше узлов сети используют агрегированный линк и чем „правильнее“ подобран алгоритм балансировки, тем больше максимальная пропускная способность агрегированного линка приближается к сумме пропускных способностей всех линков. Подробнее про белансировку LACP смотрите в статье „Агрегация каналов и балансирова трафика по IP“.
Документ TR-3749 описывает нюансы настройки VMWare ESXi с СХД NetApp и коммутаторами Cisco.
на NetApp 7-Mode
на NetApp Clustered ONTAP
Обратите внимание, portfast (spanning-tree port type edge) должен быть настроен ДО того, как будет подключён NetApp!
На коммутаторе Cisco Catalyst:
На коммутаторе Cisco Nexus 5000:
Уверен, что со временем мне будет что добавить в эту статью по оптимизации сети, спустя время, так что заглядывайте сюда время от времени.
Замечания по ошибкам в тексте и предложения прошу направлять в ЛС .
Принцип работы
В сфере сетевых технологий термином Flow Control обозначается процесс управления объемом передаваемых данных между двумя узлами сети. Цель данного процесса – предотвращение ситуации, когда более быстрый узел, отправляющий данные, обгонял бы более медленный принимающий узел. Технология Flow Control предоставляет механизм, благодаря которому узел, отправляющий данные, способен контролировать скорость передачи таким образом, чтобы принимающий узел не переполнился бы данными.
Контроль потока следует отличать от контроля переполнения, который используется для контроля передаваемых данных в том случае, если переполнение уже произошло. Существует несколько методов контроля потока, которые можно разделить на две основные категории, разница между которыми состоит в том, посылает ли принимающий узел данные на отправляющий узел или нет.
Контроль потока является важной задачей, поскольку часто встречается ситуация, когда передающий компьютер отсылает информацию быстрее, чем принимающий компьютер способен ее обработать. Это может случиться в том случае, если принимающий информацию компьютер имеет дело с более загруженным сетевым трафиком или просто имеет меньшую вычислительную мощность по сравнению с передающим устройством.
По типу реализации можно выделить два основных способа контроля потока: программный и аппаратный. Аппаратный (Hardware) способ обычно осуществляется при помощи специальных сигнальных линий, которые присутствуют в интерфейсах передачи данных. Например, в интерфейсе последовательного порта для этой цели используются служебные линии Request To Send (запрос на отправление данных) и Clear To Send (готовность к приему данных). В программном (Software) способе контроля потока используются специальные символы, которые передаются по основному каналу данных и сигнализируют о начале и конце передачи. Обычно в качестве этих символов используются байты, которые обозначаются как XON (байт, возобновляющий передачу данных) и XOFF (байт, приостанавливающий передачу данных). Для того, чтобы работал какой-либо из методов контроля потока – программный или аппаратный, необходимо, чтобы его поддерживали бы оба устройства – как принимающее, так и передающее.
Опция BIOS Flow Control обычно присутствует на материнских платах со встроенными сетевыми картами. Значение опции Hardware позволяет выбрать аппаратный способ контроля потока, а Software – программный. Значение опции None позволяет не использовать какой-либо из способов контроля потока.
В некоторых BIOS в опции Flow Control вместо вариантов Hardware и Software могут встретиться варианты CTS/RTS (от терминов Request To Send и Clear To Send) и XON/XOFF. Первый вариант соответствует аппаратному способу контролю потока, а второй – программному.
Flow Control
Опция BIOS Flow Control (Контроль потока) предназначена для настройки параметров работы сетевого оборудования компьютера. Как правило, эта опция может принимать значения None (Отсутствует), Software (Программный) и Hardware (Аппаратный).
Читайте также: