Пришла пора закрасить еще одно белое пятно на информационной карте Habrahabr. С удивлением обнаружил, что кроме пары вскользь упомянутых фактов, на нашем любимом сайте до сих пор не рассказано про близящийся прорыв в интернет-коммуникациях, к которому сейчас активно прикладывают руку такие монстры сетевых технологий, как Google, Juniper, Cisco и прочие не менее знаменитые компании.Сам протокол OpenFlow довольно молод, он был разработан в Сэндфордском университете всего лишь чуть больше пары лет назад, но с тех пор количество ресурсов, людских и технических, вовлеченных в его реализацию, растет лавинообразно. Пол-года назад и моя компания присоединилась к этой гонке, и теперь я попробую вкратце описать все плюсы и минусы этой технологии на уровне “чайников”, ибо монстры-админы и так найдут, где прочитать подробные спеки.
Итак, попробую “на пальцах” описать, в чем тут суть. Возможно, многие из вас обращали внимание на небольшие коробочки с моргающими лампочками, через которые интернет попадает к вам в компьютер. У провайдеров почти такие же, только подороже и по-мощнее, но суть та же: принять пакет из одной дырки, посмотреть его содержимое и потом или положить его в другую дырку, или выбросить, или надругаться над ним другим способом. Что произойдет в итоге с каждым конкретным пакетом, решает стоящий внутри коробочки процессор. Он помнит, в какой дырке торчит провод к аплинку, он знает адрес сетевой карты Васи Пупкина, он не дает злобному хакеру из Китая исполнить грязные замыслы против Васиного компьютера.
Беда в том, что “вас (пакетов) много, а я (процессор) один” и когда скорость прихода пакетов превышает возможность процессора их обработать — начинаются неизбежные задержки и потери. И вот здесь возникает закономерный вопрос — а зачем диспетчеру работать носильщиком? Давайте их разделим.
Итак, в двух словах суть OpenFlow описывается именно так — перекладывает пакеты из дырки в дырку Тупой Железный Пакет-Процессор (ТЖПП) в соответствии с имеющейся у него таблицей, и если вдруг попадается ему необычный пакет, не подпадающий ни под какое правило, то ТЖПП просто пересылает этот пакет (завернутый в красивую подарочную упаковку) Серверу, Который Все Знает (СКВЗ).
СКВЗ живет где-нибудь под боком у Самого Главного Админа и помнит внутри себя конфигурацию сети, где какой свитч стоит и кто к нему подключен. У каждого свитча есть свой уникальный номер и после включения питания он стучится к СКВЗ и получает от него полный список правил и действий (Matches & Actions) для своего ТЖПП, например “если к тебе пришел пакет с DstIP 1.2.3.4, то прилепи к нему VLAN тег 10 и отправь в 15 дырку” и так далее. В роли СКВЗ сейчас зачастую выступают NOX, BigSwitch или Beacon (есть и другие, но это тот набор, который мне пока что приходилось щупать своими руками).
После начала работы СКВЗ имеет возможность на ходу менять конфигурацию свитчей в зависимости от происходящих событий. Например, посылается пакет на определенный порт, ТЖПП видит соответствующее правило и отправляет этот пакет контроллеру, контроллер в ответ добавляет правило, позволяющее в течение, например, часа выходить в интернет с определенного адреса. Или наоборот, дает доступ извне к какому-то сервису.
Плюсы такого подхода:
1) вся конфигурация сети хранится у админа на сервере и имеет единый интерфейс, для изменений и бекапов не надо логиниться куда-либо, и главное — перестает работать старая админская примета “менять удаленно сетевые настройки — к дальней дороге”, наконец-то можно экспериментировать в свое удовольствие
2) Устоявшиеся потоки данных, не требующие вмешательства сервера, обрабатываются на максимальной скорости интерфейса.
3) Стоимость свитча, по “умности” превосходящего нынешние L3, падает даже ниже стоимости самых примитивных L2
4) Мечта многих пользователей — WiFi роуминг, переключающийся на ходу (проект OpenRoads)
Разумеется, есть и минусы:
1) АРРРРРГХ!!! Извините, не сдержался. Мне, как разработчику, очень обидно за тупость и непродуманность самого протокола, на фоне которого даже СМТП выглядит верхом изящества и утонченности. Впрочем, обещают в ближайшей следующей версии (текущая версия 1.1 была принята в марте этого года) его основательно изменить, а пока спасает только наличие так называемых Vendor Messages, где можно добавлять свою функциональность, однако с опасением скатиться в, извините за выражение, проприетарность. Кстати, 1.1 от 1.0 тоже отличался ощутимо, и я успел побегать по заботливо разложенным внутри протокола граблям.
2) IPv6. Впрочем, о покойниках или хорошо, или ничего. Насчет зомби я не уверен.
3) Работа с несколькими контроллерами. Сейчас в лабораторных условиях это делается через костыль по имени flowvisor, но в реальной жизни падение СКВЗ превращает умные железки в тупые свитчи.
4) Пляски с бубном при реализации элементарных вещей, например проверка флага Syn в ТСП-пакете. Хотя это опять претензия к номеру 1.
5) Было еще что-то неприятное, но я забыл из-за переполнивших меня после пункта 1 эмоций.
В комментариях можете задавать вопросы, постараюсь ответить на них в меру своей компетентности.
UPD: Видео по теме от пользователя eek
