Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Основы программно-конфигурируемых сетей. Учебное пособие
.pdf
в) Доступ. Возможен доступ с использованием виртуальных рабочих
столов, а также мобильных устройств.
г) Трафик. Использование облачных вычислений приводит к появлению
новых типов трафика для переноса данных между серверами.
Анализ сервисов/приложений, применяемых для управления сетевой
инфраструктурой в ПКС, показал необходимость использования виртуализации
и облачных технологий для построения вычислительных ЦОД.
31
3 Обзор протокола OpenFlow
3.1 Описание таблиц для протокола OpenFlow
OpenFlow-совместимые коммутаторы делятся на два типа: OpenFlow-only
(только OpenFlow) и OpenFlow-hybrid (OpenFlow-гибрид). Коммутаторы типа
OpenFlow-only поддерживают только операции OpenFlow, в этих коммутаторах
все пакеты обрабатываются обработчиком OpenFlow и не могут быть
обработаны чем-либо еще.
Коммутаторы типа OpenFlow-hybrid поддерживают все операции
OpenFlow и обычные операции коммутации Ethernet, т.е. традиционную
коммутацию второго уровня, VLAN, маршрутизацию третьего уровня, ACL и
QoS.
Эти коммутаторы должны обеспечивать механизм разделения вне
OpenFlow, который направляет трафик либо через обработчик пакетов
OpenFlow, либо через обычный обработчик пакетов. Например, коммутатор
может использовать теги VLAN или входящий порт пакета, чтобы определить,
следует ли обрабатывать пакет с помощью одного обработчика или другого,
или он может направить все пакеты обработчику OpenFlow.
OpenFlow-обработчик каждого OpenFlow-коммутатора содержит
несколько таблиц потоков, а каждая таблица потоков содержит несколько
записей. OpenFlow-обработчик определяет, как пакет взаимодействует с этими
таблицами потоков в соответствии со схемой, представленной на рисунке 3.1.
Рисунок 3.1–Прохождение пакета через конвейер обработки [31]
OpenFlow-коммутатор может иметь только одну таблицу потоков, в этом
случае конвейер обработки значительно упрощается. Таблицы потоков в
OpenFlow-коммутаторах последовательно нумеруются, начиная с нуля.
Конвейерная обработка всегда начинается с первой таблицы потоков, пакет
сначала сравнивается с записями таблицы потоков с номером ноль. Другие
таблицы потоков могут быть использованы в зависимости от результата
сравнения с первой таблицей.
Если пакет совпадает с записью в таблице потоков, то выполняется
соответствующий этой записи набор инструкций. Инструкции в записи потока
могут явно перенаправлять пакет в другую таблицу потоков, где тот же процесс
повторяется снова. Записи потока могут перенаправлять пакет только в ту
таблицу, номер которой больше собственного номера таблицы, другими
32
№пп
Название поля
Расшифровка
1
2
3
1
IngressPort
Входящий интерфейс пакета
2
Metadata
Метаданные
3
Ethersrc
Ethernet адрес источника
4
Etherdst
Ethernet адрес получателя
5
Ethertype
Версия протокола Ethernet
6
VLAN id
Идентификатор сети VLAN
7
VLAN priority
Приоритет сети VLAN
8
MPLS label
Метка протокола MPLS
9
MPLS traficclass
Класс трафика протокола MPLS
10
IPv4 src
IP адрес источника
11
IPv4 dst
IP адрес получателя
12
IPv4 ToSbits
Приоритет пакета
14
TCP/ UDP / SCTP src port
Номер порта протокола
TCP/UDP/SCTP источника пакета
15
ICMP Type
Тип протокола ICMP
16
TCP/ UDP / SCTP dst port
Номер порта протокола
TCP/UDP/SCTP получателя пакета
17
ICMP Code
Код протокола ICMP
словами, конвейерный процесс может идти только вперед, а не назад.
Очевидно, что записи последней таблицы конвейера не могут содержать
инструкции перехода на другую запись (Goto). Если соответствующая запись
потока не направляет пакеты в другую таблицу потоков, конвейер обработки
останавливается в этой таблице. Когда конвейерная обработка прекращается,
пакет обработан соответствующим набором действий и обычно отправлен.
Если пакет не соответствует ни одной записи в таблице потоков, то эта
таблица пропускается. Поведение в случае пропуска таблицы зависит от
настроек этой таблицы, по умолчанию – это отправка пакетов контроллеру
через канал управления, другой вариант – удаление пакета. Также возможен
случай, что при пропуске таблицы обработку пакетов следует продолжать, в
этом случае пакет обработается следующей по порядку таблицей.
В таблице 3.1 показаны поля для сравнения входящих пакетов. Каждая
запись может содержать либо конкретное значение, либо значение ANY (любой
пакет).
Таблица 3.1 – Поля пакетов для участия в процессе коммутации
Если коммутатор поддерживает технологию битовых масок в полях
«Ethersrc», «Etherdst», «IPv4 src», «IPv4 dst», такие маски позволяют более
точно указать совпадения. В дополнение к заголовку пакета, совпадения могут
также быть выполнены в отношении входящего интерфейса и поля метаданных.
Метаданные могут быть использованы для передачи информации между
таблицами в коммутаторе.
33
3.2 Пути анализа потоков трафика для формирования таблиц
потоков OpenFlow
В общем случае сети передачи данных практически невозможно построить
таким образом, чтобы отследить и зафиксировать каждый пакет, переданный
узлом сети [26]. Для этого необходимы специализированные технические
решения и дорогостоящее высокопроизводительное оборудование, дополненное
мощным вычислительным центром и вместительным хранилищем результатов.
Также, довольно проблематично разделить трафик на отдельные логические
сессии, например, выделить сессию работы конкретного пользователя с
конкретным ресурсом.
Если сеть построена с уменьшенной структуризацией, то есть основная
часть сети расположена в зоне около четырех-пяти подсетей, то данные
маршрутизаторов будут полезны только для анализа трафика между подсетями.
Тогда как при такой логической топологии трафик, скорее всего, будет
распределен по правилу 80/20, то есть 80 процентов внутри сегмента, и только 20
процентов наружу сегмента. Таких сетей в области малых и средних организаций
подавляющее большинство.
В этом случае основной инструмент для сбора статистики – SNMP счетчики
коммутаторов сегмента. Если сеть построена на оборудовании нескольких фирм
(в большинстве случаев), видов счетчиков два: количество пакетов в секунду за
период наблюдения на интерфейсе (кол-во / с) и количество байт (бит) в секунду
за период наблюдения на интерфейсе (bandwith). С помощью этих двух счетчиков
невозможно построить реальную картину прохождения трафика по сети, однако,
можно построить модель сети, которая будет хотя бы повторять объемы потоков
через определенные порты коммутатора.
При применении метода двумерной диффузионной аппроксимации в
качестве метода моделирования системы массового обслуживания каждый
коммутатор можно представить в виде отдельной СМО с определенным внешним
трафиком. Так как большинство сетей строится на основе физической топологии
«расширенная звезда», сеть имеет древовидную структуру. Вследствие этого
внешний трафик коммутатора легко отследить на определенных портах.
Рассмотрим сеть, состоящую их четырех коммутаторов, соединенных по
схеме «звезда» в соответствии с рисунком Рисунок 3.2.
34
PC1 PC2 PC3 PC4 PC5
PC7PC6
Server1 Server2 Server3
Internet
PC7
Коммутатор1 Коммутатор2
Коммутатор3
1 2 3 4 5 6 7 1 2 3 4 5 6 7 1 2 3 4 5 6 7
8 8 8
PC1
PC2
PC3
PC4
PC5 PC7
PC6
Server1
Server2
Server3
Internet
PC7
Коммутатор1 Коммутатор2 Коммутатор3
1 2 3 4 5 6 7
9 10 11 12 13 14 15 17 18 19 20 21 22 23
8 16
24
Коммутатор0
25 26 27 28 29 30 31
Рисунок 3.2– Пилотная сеть
При такой схеме можно однозначно определить, какими портами
коммутаторы связаны между собой. Исходящий трафик порта UpLink будет в
точности совпадать с входящим трафиком соответствующего порта коммутатора
следующего уровня, куда подключен искомый коммутатор.
Например, исходящий трафик порта восемь коммутатора один будет в
точности совпадать с входящим трафиком порта пять центрального коммутатора.
Обратные трафики также должны совпадать. Учитывая это, возможно заменить
сеть коммутаторов эквивалентным единым коммутатором с уже известными
связями внутри себя в соответствии с рисунком 3.3.
Рисунок 3.3– Схема трафика точка-точка
35
xrr
0.596
0.089
0.357
0.118
0.889
0.280
0.437
0.188
0.992
Если трафик идет от компьютера PC1 на сервер Server1, то при отсутствии
посторонних трафиков выборки, входящий и исходящий трафик будут совпадать
в той или иной мере, в зависимости от задержек. Оценить степень совпадения
можно, рассчитав коэффициент корреляции между входящим трафиком порта
один нового виртуального коммутатора и исходящим трафиком порта 26. При
этом поток затронет порты восемь и 26, так как они связаны кабелем напрямую,
но, учитывая это, при поиске ушедшего трафика они не используются.
Как только будет найден исходящий порт с наивысшим значимым
коэффициентом корреляции, принимается решение о соответствующей
вероятности попадания исследуемого трафика в этот порт. Все остальные порты,
на которых коэффициенты корреляции выше 0,3 также участвуют в расчете
вероятностей. После расчета все вероятности необходимо нормализовать, чтобы
их сумма равнялась единице.
Если сеть большая, потоки пересекаются в достаточно большом числе мест,
мультиплексируются в буферах коммутатора и теряют свою индивидуальность. В
этих условиях необходимо разбивать интервал наблюдения на зоны и искать
зависимости нетипичного пикового трафика узла.
Например, возьмем два графика трафиков на портах один и 26 в
соответствии с рисунком 3.4.
Рисунок 3.4– График входящего трафика первого порта и исходящего 26
порта
Коэффициент корреляции равен 0.437, то есть весьма низок. К тому же на
других портах наблюдаются большие шумы, которые тоже отразились на
остальных коэффициентах корреляции в соответствии с рисунком3.
Рисунок 3.5– Матрица корреляции для портов один, 25 и 26.
36
xrr
0.980
0.270
0.857
0.369
0.966
0.442
0.918
0.336
0.997
Корреляция для элемента xrr
определяется как корреляция входящего
i,j
трафика i-ого элемента и исходящего трафика j-ого элемента. По диагонали –
корреляция входящего и исходящего трафиков для одного порта. Она обычно
очень высока вследствие пропорциональности работы протокола TCP. В
соответствии с рисунком 3.6 показаны графики для портов восемь и 26.
Рисунок 3.6– График на портах восемь и 26
При разбиении на интервалы для создания временных срезов (по 100, 200
секунд) наблюдается неравномерность в коэффициентах корреляции потоков на
порты в зависимости от номера интервала, что говорит об изменениях в
маршрутной матрице во времени. Возьмем один из срезов активного поведения
трафика – от 1100 с до 1200 с в соответствии с рисунком 3.7 коэффициент
корреляции входящего трафика первого порта и исходящего порта 26 равен 0,918.
Рисунок 3.7– Матрица корреляции для портов один, 25, 26
Следовательно, в этот срез времени можно найти источник этого скачка с
высокой вероятностью. Главное, таким образом можно определить, что в данный
порт этот скачок трафика не пришел. По пути от обратного можно также найти
порт с таким же скачком. Если такого скачка не наблюдается на других портах,
значит, это был мгновенный распределенный запрос с нескольких машин, и
отследить его практически невозможно. Такие моменты, как кратковременный
скачок трафика, являются нестационарным поведением сети, и статистическими
методами построить в таких режимах маршрутную матрицу не представляется
возможным.
После отсева незначимых коэффициентов, а также приравнивания к нулю
элементов главной диагонали (коммутатор никогда не пошлет пакет в тот
интерфейс, откуда он пришел), получаем следующую матрицу корреляции для
интервала 1100 с – 1200 с в соответствии с рисунком 3.8.
37
p1
0.000
0.000
0.857
0.369
0.000
0.442
0.918
0.336
0.000
Рисунок 3.8– Матрица корреляции для портов один, 25, 26 после удаления
незначимых и недостоверных результатов
Ненулевые элементы матрицы на пересечении i столбца и j строки
означают, что существует вероятность того, что трафик был передан с i на j порт
коммутатора.
Поскольку таблицы действий OpenFlow в общем случае эквивалентны
маршрутной матрице, предлагается использовать предварительное моделирование
и анализ потоков на реальной сети для составления оптимальных путей
следования трафика и определения расчетных характеристик каналов связи.
Протокол OpenFlow использует таблицы поиска в современных Ethernet
коммутаторах и маршрутизаторах. Эти таблицы потока, выполненные в
строчной развертке, которые реализуют брандмауэры, NAT, QoS или в срезах
статистических данных, варьирующиеся между различными поставщиками.
OpenFlow идентифицирует общие наборы функций, которые поддерживаются
большинством коммутаторов и маршрутизаторов. Для всех сетевых устройств
независимо от их спецификации можно использовать идентификацию как
единый набор функций и стандартный способ управления таблицами потока.
Каждая таблица OpenFlow может формироваться на основе анализа временных
срезов сетевого трафика или на основе статистических данных о трафике,
однако пока нет эффективных путей формирования таблиц при динамически
изменяющейся сети в условиях виртуализации центров обработки данных.
OpenFlow также может использоваться в корпоративных сетях, где
изоляция исследуемого трафика является основной задачей. Потоки создаются
и сохраняются централизованной архитектурой, названной контроллером.
3.3 Анализ трафика конвергентных сетей
При анализе сложных сетевых структур в большинстве случаев применяют
классический подход с использованием пуассоновских потоков заявок и
экспоненциальное распределение времени обработки заявки [32]. Однако, в
большинстве случаев сложных высоконагруженных сетей такой подход дает лишь
очень приближенный результат. Поэтому для повышения адекватности модели
сети, уточнения входных характеристик для моделирования, необходимо четко
отделять различные классы потоков друг от друга [33]. Кроме того, делать это
необходимо с учетом постоянно изменяющегося характера трафика, его
периодичности, «часов пик».
Основной целью обеспечения высокого качества обслуживания
конвергентной сети является критичность голосового и видео трафика к любым
38
задержкам и требовательность к выделенной полосе пропускания. После
выявления требований к какому-либо сегменту сети (количество одновременных
вызовов, сетевые приложения, время отклика) необходимо проанализировать
возможности оборудования и существующую ситуацию. В ряде случаев это
приходится делать уже на существующем сегменте сети. Чтобы выявить основные
тенденции трафика, его пики, пики конкретных приложений, возможности
конкретных типов трафика взаимодействовать с различными политиками и
типами QoS необходимо [34]:
а) разделить логические потоки, узел-узел и приложение-приложение;
б) определить вероятностные характеристики каждого логического потока
для последующего анализа;
в) определить суточные, часовые и иные циклы периодичности в поведении
трафика.
Самым важным здесь является определение вероятностных характеристик.
Без них невозможно проводить моделирование сегмента сети для получения
стресс-характеристик по каждому приложению и не будет возможности
предсказать параметры производительности, время отклика приложения и
стабильность этих параметров во времени.
Определение вероятностных характеристик реального трафика сталкивается
со многими проблемами. Любая методика тестирования существующей сети
существенно зависит от имеющихся в распоряжении системного администратора
технических и программных средств. В большинстве случаев для обнаружения
дефектов сети и анализа существующего трафика достаточным средством
является анализатор сетевых протоколов.
Для выявления ошибок от канального уровня до уровня приложения
измерения необходимо проводить при одновременной генерации анализатором
протоколов собственного трафика. Генерация трафика позволяет выявить
имеющиеся недостатки и создает условия для их проявления. Генерация должна
быть управляемой по интенсивности и закону распределения.
Этот метод называется «стресс-тестирование» сети и позволяет довольно
быстро на реальном сегменте определить его предельные характеристики и
возможности. Данный подход является самым универсальным, потому как
используется метод планирования эксперимента на реальном оборудовании. Весь
эксперимент будет занимать несколько минут, после него будут определены все
основные параметры оборудования и каналов связи в требуемых режимах и с
требуемыми типами трафика.
После получения каким-либо образом суммарных данных о трафике в виде
отдельных заголовков пакетов, необходимо выделить отдельные потоки [35]
(клиент-сервер, приложение-приложение, АТС-АТС). Для планирования
активного эксперимента (стресс-тестирования или комбинации его с потоками
Netflow/SFlow [36]) необходимо знать вероятностные характеристики каждого из
потоков, и, в первую очередь, вид распределения. Если речь идет о внедрении
голосовых услуг или перевода связность АТС на VoIP поток [37], то голосового
трафика может и не быть в общем потоке. Тогда необходимо задать его вручную.
39
3.4 Методы обеспечения QoS в ПКС
Основа реализации качества обслуживания (QoS) базируется на контроле
входа и выхода пакета из устройства. Какая единица данных при этом
используется – поток или пакет – не имеет значения, реализации QoS сводится
к определению приоритетов конкретных пакетов. Контроль над прохождением
пакетов через сеть доступен только в пределах центра обработки данных
(ЦОД), за пределами ЦОД вся ответственность ложится на провайдеров
телекоммуникационных услуг.
Кроме того, QoS предназначен для решения связанных с сетью вопросов,
таких как перегрузка каналов и потеря пакетов, которые в конечном итоге
приводят к снижению производительности приложений. Перегрузка каналов и
потери пакетов могут произойти по ряду причин, например, превышение
максимальной пропускной способности, высокий коэффициент загрузки (это
делает их неспособными к эффективной обработке входящих пакетов [38, 39]),
а также при неправильной конфигурации сетевых устройств.
Некоторые типы QoS, например, ограничение полосы пропускания, могут
помочь в решении проблемных ситуаций. Управление полосой пропускания
может уменьшить проблемы, связанные с ограниченной пропускной
способностью каналов связи, но только каналов между ЦОД и Интернет. Если
пропускная способность ограничена на другом конце канала («последняя миля»
провайдера), этот метод не улучшит производительность, так как контроллер
OpenFlow не имеет сведений об этих ограничениях. OpenFlow контроллер
будет применять правила вслепую по отношению к трафику за пределами
центра обработки данных.
Вне контекста приложений QoS редко дает заметное улучшение в
производительности с точки зрения конечного пользователя. Контекст является
необходимым для того, чтобы применять правильные методы и политику в
нужное время, чтобы обеспечить оптимальную производительность для
пользователей конкретного приложения.
Большинство коммутаторов и маршрутизаторов сегодня поставляются с
некоторой встроенной поддержкой QoS. Некоторые продукты поддерживают
только тип DiffServ (RFC-2474 и RFC-2475, небольшое количество очередей и
политик), другие поддерживают тысячи очередей и большое количество
политик. На практике при реализации QoS в сетях с коммутацией потоков
поток отображается на класс трафика QoS, то есть поток получает
идентификатор уже имеющегося класса.
В настоящее время существует два основных типа QoS услуг: ограничение
скорости на входе и гарантирование минимальной пропускной способности на
выходе. Первая обычно делается на основе измерений скорости входного порта
или потока, после превышения определенной скорости пакеты отбрасываются в
соответствии с некоторым алгоритмом [40]. Ограничение минимальной
гарантированной полосы пропускания означает, что каждому потоку будет
доступна определенная часть от имеющейся пропускной способности. По
40
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]