Контроллеры SDN разнообразны и сложны, но у них общие цели и функции. Важным аспектом выбора контроллера SDN является то, хорошо ли он работает и достаточно ли высоки его узкие места.
В свете мудрости я наткнулся на эту оценочную статью, в которой по существу критикуется производительность OpenFlow, приводя множество убедительных причин того, почему протокол OpenFlow был реализован неоптимально. Самым интересным, на мой взгляд, было сравнение многих контроллеров SDN на аналогичных тестах.
Я использую контроллер OpenDaylight для исследований, и я нашел довольно убийственным то, что в этой статье утверждается, что ODL настолько неэффективен, что предоставление экспериментальных данных бесполезно. Это кажется нереальным утверждением, учитывая, насколько большой и активный ODL.
Хотя в документе приводится множество причин, по которым другие контроллеры OpenFlow могут работать хуже, раздражает то, что об OpenDaylight строго ничего не дается. Дополнительно отмечу, что общая логическая архитектура этих контроллеров SDN не приводится. Это беспокоит меня, потому что программируемость — это название игры с SDN, и поэтому использование в основном поведения по умолчанию (которое, как я предполагаю, и происходит в документе), вероятно, не самый надежный способ сравнить возможности контроллеров SDN. .
Скажем, контроллер A использует метод A для автоматического обнаружения топологии, а контроллер B использует метод B. Если метод B более эффективен, независимо от реализации, это приведет к явному смещению в оценках производительности обоих контроллеров. Если бы оба контроллера использовали метод B (что-то разумное, учитывая широкие возможности настройки SDN), то оценка была бы более справедливой.
Еще один момент, который меня беспокоит, это характеристики, которые оцениваются. На мой взгляд, задержка так же важна, как и производительность узкого места при обработке определенного количества сообщений в секунду на данном аппаратном узле. Для меня это гораздо меньше зависит от реализации, поскольку существует множество различных методов для выполнения аналогичных задач с SDN, но эти методы не имеют такой же «сложности» с точки зрения накладных расходов на обмен сообщениями или пакетов. оценивать.
Имеет ли это смысл? Это правильно, или я что-то упускаю? Следует ли воспринимать выступления, приведенные в газете, с долей скептицизма? Если да, то каков независимый от реализации способ оценки технологии контроллера?
