Digital October

AR/VR Gamedev Moscow Конференция AR/VR Gamedev Moscow

конференция-выставка по использованию технологий дополненной

Ник Маккеон. Как разогнать интернет до скорости света

30 августа 2012

30 августа в Digital October в рамках проекта Knowledge Stream прошла лекция профессора электротехники и компьютерных наук Стэнфордского университета Ника Маккеона. Он выразил недовольство современным интернетом и рассказал, как избавить сеть от существующих недостатков.

НИК МАККЕОН: Отлично. Что же, добрый вечер, господа и дамы. Приятно иметь возможность, ну если не быть у вас, то хотя бы с вами. Вы, конечно, понимаете, что у нас в Калифорнии еще раннее утро. Так что я заранее приношу извинения. Буду время от времени потягивать кофеек. У меня все-таки утро, не то что у вас. Впрочем, сегодня мы с вами будем обсуждать будущее интернета. Я постараюсь вам рассказать, почему программная составляющая будет определять будущее интернета. Но, может быть, кого-то я и не удивлю этими словами. Может быть, вам уже кажется, что, в принципе, программная компонента давно уже стала более важной для интернета, чем аппаратная.

Но все же я вам расскажу, то как мне видится эта история, сначала. Собственно, тема мне эта кажется важной, поскольку она может иметь большое значение именно для российской отрасли, связанной, скажем, с написанием программного обеспечения, но, если уж мы говорим об SDN-сетях, как мы дальше будем простоты и краткости ради называть сети с программным управлением, то тут, собственно, перед вами все пути открыты.

Давайте для начала проведем короткий исторический экскурс. Вы, наверное, помните, что в 60-х годах проводились исследования, в частности в институте RAND проводились исследования под руководством Пола Бэрана, который пытался решить задачу создания сети, которая переживет ядерную войну. Тогда стали появляться первые работы на тему пакетной коммутации. Тогда же начались работы и в Великобритании, откуда я на самом деле родом. Дальше понемножку стали разрабатываться первые протоколы, первые шлюзы разрабатывались. Ну и, в общем, интернет начинался, с мелочевки, да, с проприетарной сети для DARPA, а потом понемножку уже превратился в современного монстра. Вот на этом графике должно быть показано количество взаимосвязанных сетей, и, в общем-то, график показывает, что по экспоненте растут практически все индикаторы, связанные с сетями, с интернетом. Был, конечно, трудный момент в истории интернета в 2001 году, вы видите, крах доткомов привел к тому, что вот здесь вот мы видим такой небольшой провал в этой кривой. Количество пользователей интернета уже исчисляется миллиардами. На сегодняшний день какие-то единицы процентов всех устройств, работающих в сети, находятся в Соединенных Штатах, а большая часть уже, конечно, разбежалась по всему миру, то есть интернет стал действительно глобальным явлением. Когда мне было 25, нам и в голову не приходило, что интернет сможет когда-нибудь настолько сильно начать влиять на нашу жизнь. Сейчас это, в общем, уже никого не удивляет — то, что интернет действительно определяет практически каждый наш шаг.

Давайте вот в следующем порядке разберем несколько тем. Почему интернет устроен так, как он устроен? Почему нас это не устраивает? Что мы можем по этому поводу сделать?

Ну, начнем сначала. Полагаю, что большая часть из вас с этой темой и так знакома, но на всякий случай проговорю несколько простых моментов. Передача пакетов сети интернет идет от одной точки к другой. Для того чтобы пакет дошел от одного компьютера к другому, он пройдет через некоторую сеть, состоящую из энного количества маршрутизаторов, коммутаторов. И каждый раз в сети, оформленной в виде таблицы, ваше устройство будет выбирать следующий узел, на который пакет будет передаваться. Вот эта вот операция пересылки выполняется аппаратным способом, причем для этого используется в основном специализированное, специально выделенное оборудование. Сами понимаете, что, конечно, идет масса одновременно передающихся пакетов по разным направлениям. То есть даже какой-нибудь небольшой свич, стоящий в современном ЦОДе, скорее всего, будет обрабатывать, скажем, миллиард, наверное, пакетов в секунду. Вот, справа внизу вы видите маршрутизатор, коммутатор, вроде того, который у вас стоит дома, со встроенной в него вайфайной точкой доступа. Сверху вы видите коммутатор, который, скорее всего, будет стоять на стоечке в компании, где вы работаете. Ну, а слева показан большой маршрутизатор, который и будет использоваться, скажем, в опорной сети. То есть он уже будет обслуживать серьезные большие объемы передаваемых пакетов. Собственно, это примеры того аппаратного оборудования, на котором и бегает большая часть современной сети.

Нужно помнить, что у любого маршрутизатора есть три логических компонента. Есть, собственно, часть, отвечающая за пересылку пакета, современный роутер, как я говорил, вполне может обрабатывать, скажем, миллиард пакетов в секунду. Ну, помимо аппаратной начинки, есть, конечно, и операционная система, постольку поскольку периферийных устройств много, аппаратная начинка может быть достаточно сложной. Поэтому нужна операционка. Ну, и плюс к этому есть еще какие-то фичи. Какие фичи? Какие-то дополнительные протоколы маршрутизации, какие-то штуки, упрощающие работу, скажем, администратора или пользователя с вашим маршрутизатором, какие-то дополнительные накрутки из области безопасности. Может быть аппаратный файрвол и так далее. Кстати говоря, для того, чтобы всю эту историю написать, нужны миллионы строк программного кода. Если вы работаете в компании, занимающейся системным оборудованием, вы будете, конечно, знать, что код этот достаточно сложный и пишется непросто.

Когда я впервые начал заниматься этой тематикой, казалось, что, в общем-то, маршрутизаторы, коммутаторы — это такие специальные тупые устройства, они выполняют простую функцию и простыми и останутся. Это вам не АТС, это не большие коммутаторы, которые ставятся, скажем, телекоммуникационными компаниями. Это вот такие тупенькие простенькие устройства. Так вот, для сравнения могу сказать, что крупнейший коммутатор в Соединенных Штатах требовал для своей работы 8 млн строк программного кода. А большие роутеры, которые сейчас обслуживают собственно backboard, магистральную сеть, им нужно на самом деле в 5 раз больше строк программного кода, там счет идет от 35-40 млн строк. В общем, эти цифры мы здесь привели для того, чтобы было понятно, насколько сложны стали эти устройства. И вас не удивит еще одна цифра, что современный маршрутизатор должен подчиняться одновременно приблизительно 6 тыс. разных нормативов. Весь этот софт работает на достаточно сложном железе. В современном маршрутизаторе может быть несколько тысяч внутренних гейтов, через который будет проходить любой входящий пакет. То есть не удивительно, что при таком количестве функций и при такой сложной начинке и энергопотребление, и надежность работы этих устройств будут чудовищные. Большинство этих устройств обладает широчайшим функционалом, абсолютно бесполезным для рядового пользователя и даже для большинства стандартных сетей, ну и при этом работают очень ненадежно. Большинство этих маршрутизаторов, коммутаторов, они построены по проприетарным технологиям фактически и являются черными ящиками. То есть поменять в них что-то чрезвычайно трудно. Давайте теперь вспомним, как они друг с другом разговаривают, все эти чудесные устройства. Да, есть кастомное железо с опять же проприетарным софтом, который на нем работает, и дальше нужны сотни интерфейсов, по которым эти коммутаторы с маршрутизаторами будут договариваться.

Я вот буду много говорить о необходимости реорганизации сети. Почему? Да потому что очень трудно выстроить и поддерживать работоспособность большой сети настолько гетерогенной по своей сути. Вам нужно, если вы что-то меняете в сети, дальше транслировать эти изменения практически во всех индивидуальных устройствах сети. Хотелось бы, конечно, найти способ упростить эту работу, однако, софт, на котором работают современные устройства, пока в них локализован. Однако уже сложилась тенденция, наметившаяся в некоторых странах, в некоторых отраслях, но не во всех, которая предполагает как раз перенос контрольного блока всех элементов операционной системы с уровня отдельных устройств на уже выделенные сервера. То есть вы можете централизовать на уровне одного ПК или одного сервера все функции управления сетью. И это будет как раз основой вашей SDN-сети.

Может быть, вы уже слышали буквосочетание SDN — Software Defined Network по-английски, или сеть, определяемая программным обеспечением, или сеть с программным управлением, по-русски. С собственно централизации софта она и начинается. В рамках такой сети ваша централизованная операционная система дает вам целостное представление о всех устройствах, которые в сети находятся, и о том, как они работают. Собственно, эта операционная система уже самостоятельно будет составлять топологическую карту сети и постоянно ее поддерживать в состоянии актуальности. Но сюда можно добавить какую-нибудь, не знаю, функцию мобилити-менеджмента, например, ну и есть, собственно, похожие решения, используемые телекоммуникационными компаниями. А дальше уже, представляя себе точную топологию сети, вам гораздо проще принимать решения о конкретной детальной маршрутизации. Ну, представьте себе, что вы пишете программу для ПК. Вы описываете программу, в которой вы вместо того, чтобы все писать, грубо говоря, на ассемблере, на языке конкретных процессорных команд, вы скорее описываете то, чего хотите получить, а потом вы запускаете компилятор, и компилятор уже все переводит на язык, понятный и ассемблеру, условно говоря. Собственно говоря, в SDN-сетях мы пытаемся делать приблизительно то же самое. Мы пытаемся абстрагировать программную часть от железной, от аппаратной. Собственно, уже сейчас есть несколько решений в этой области. Какие-то коммерческие, какие-то опенсорсные, то есть с открытым кодом, бесплатно распространяемые. Вот здесь вот мы показываем базовую структуру таких сетей, и я думаю, что она станет гораздо более популярной в ближайшие 10-20 лет.

Я вам уже рассказал, что будет происходить. Давайте теперь разберемся, почему оно будет происходить именно так. Начну с технического и бизнесового, наверное, аргументов. Кстати говоря, в нашей жизни обычно бизнесовые аргументы перевешивают технологические. Потому что, если есть какой-то коммерческий интерес в той или иной технологии, она получает естественное развитие. Приведу простую аналогию. Вспомните компьютерную отрасль образца 80-х годов. В то время на этом рынке доминировала одна компания, ну, во всяком случае, таким было положение дел в Соединенных Штатах. Приличный компьютер тогда можно было купить производства только одной компании — IBM. И понятное дело — в нем была бы специализированная железная начинка, операционная система тоже стояла бы проприетарная. Ну, и все приложения, которые работали бы на этом устройстве, тоже были бы от того же самого вендора, тоже, конечно, совершенно закрытые. Компания считалась крупным экспертом в этой области. И мы, собственно, готовы были довериться ей. Пользователи считали, что компании виднее, как настроить нормальное взаимодействие между железом и софтом. Однако вы все помните, что произошло дальше. Появились микропроцессоры. И появление микропроцессоров означало необходимость открытой публикации наборов процессорных инструкций. Как только этот интерфейс стал публично доступен, резкий начался рост количества операционных систем. Тогда появились и линуксные системы, появились первые продукты от Microsoft. Чуть позже начали выпускать свои операционные системы ребята из Apple, появился POSIX чуть позже. Ну, и тогда же начали возникать те приложения, с которыми мы сталкиваемся сегодня каждый день. Короче говоря, была у нас закрытая вертикально-интегрированная отрасль, где доминировала одна компания, где инноваций практически не было, темп технологических изменений был чрезвычайно низким.

Дальше произошла революция, появилось огромное количество поставщиков, и начался резкий рост числа инноваций. Похожую картину мы с вами наблюдаем сейчас в моей отрасли. Если вы покупаете какое-то сетевое оборудование, то вы покупаете практически кота в мешке. Вы покупаете закрытую коробку с защищенным патентами проприетарным железом, проприетарной начинкой, с работающими только на этой аппаратно-программной базе специализированными приложениями. Однако, сейчас компании вроде Intel, Marvel, Broadcom предлагают на рынке уже открытые чипсеты маршрутизации, на базе которых можно легко выпускать уже собственное сетевое оборудование, хочу сказать, с отрытым кодом. Собственно, в этой области, как раз и работаем мы, и именно для них мы предлагаем свой протокол OpenFlow.

В последние 5 лет вышло на рынок около 10, может быть, 12 операционных систем для сетевого оборудования. Какие-то хорошие, какие-то плохие. Я думаю, их станет раза в два, а то и в три больше в ближайшие 5-10 лет. Я надеюсь, что на том же самом временном горизонте мы, наконец, получим операционную систему, которая будет работать совершенно независимо от конкретных коробок, то есть будет одинаково хорошо работать с любым железом. В общем, на смену вертикально интегрированной, закрытой и не очень инновационной отрасли мы, надеюсь, получим нечто более динамичное и живое.

Эта революция приведет и к тому, что на скорость реализации инноваций смогут влиять не только вендоры, но и уже и те, кто, собственно, строит сети и администрирует сетью, управляют сетями. Это хорошо для нас как пользователей, для нас как технологов. Конечно, вендорам это не нравится, вендоры пытаются этому сопротивляться, но я думаю, что против истории все равно не попрешь.

Кстати говоря, во многом эти изменения стали результатом работы Мартина Касадо, выпускника, собственно, нашего университета. Он стал своеобразной культовой фигурой для всей нашей сетевой отрасли. Он недавно перешел на работу в VMware, где, собственно, продолжает работу над сетевыми технологиями, но уже скорее в их виртуальном исполнении. Если вам покажется эта тема интересной, я очень рекомендую посмотреть вот этот вот ролик. В нем как раз рассказывается о базовых аспектах структуры SDN-сетей, и это лекция профессора Скотта Шенкера из Беркли где-то годичной давности. В этой лекции он рассказывает, что не просто мы передадим все функции по пересылке пакетов в какое-то централизованное звено, но мы обеспечим и совершенно другой уровень абстракции. То есть можно будет дать сетевому оборудованию провести тот же самый уровень виртуализации, который сейчас доступен для компьютеров. Ну, представьте себе центр обработки данных облачный, который предоставляет компьютерные услуги большому количеству пользователей-клиентов. У них собственные компьютеры, они как-то подключаются к ЦОДу. У клиентов будет приятная возможность управлять своим парком машин, находящихся физически внутри ЦОДа.

В общем, мы ожидаем развертывания SDN-сетей в таких больших виртуализованных ЦОДах, рассчитанных на большое количество разных пользователей. Точно так же мы думаем, что появятся SDN-сети и в компаниях вроде eBay и Fidelity, тем более что именно эти компании уже проявили интерес к таких технологиям. Но, с другой стороны, появятся и в частных, и в публичных облаках. Скорее всего, в WAN-сетях появятся. Может быть, вы знаете, что Google уже использует технологии SDN-сетей для того, чтобы увязывать друг с другом ЦОДы. Еще один ролик могу вам порекомендовать — лекция апреля 2012 года. Выступает Урс Хельце из Google. Прекрасная лекция как раз на тему того, как Google использует сети с программным управлением для обеспечения взаимодействия между всеми ЦОДами Google. То есть они прописывают всю контрольную логику сети на уровне централизованного ПО, и это дает им возможность гораздо быстрей и эффективней оптимизировать работу всего сетевого хозяйства. Я уже сказал, что они уже четыре новых версии выпустили. Вас это может поразить, если вы занимались математикой, поскольку редко бывает так, что компания что-то кардинально в сети меняет чаще, чем раз в год. Просто потому, что это чрезвычайно сложно технически. Ну, и поскольку у вас лучше представление о топологии сетей и лучше обеспечивается, собственно, маршрутизация, вы можете обойтись меньшим количеством устройств. Пока что оператору тяжело будет предлагать такие услуги рядовым пользователям. Вот Comcast, по их собственным отчетам, пока больше всего денег тратит на решение проблем, связанных с работой пользовательского оборудования. То есть не проблемы самой сети Comcast, а проблему уже пользовательских устройств. Если вы абстрагируете, так сказать, контрольную логику вынимаете из устройства, ставите ее централизованно уже у самого оператора, соответственно, вам не нужно высылать техников к пользователям на дом — все можно делать удаленно. Ну, и в этой области мы уже проводили ряд экспериментов. Можно ожидать, что и сотовые компании начнут пользоваться теми же самыми фишками постольку поскольку такая виртуализация устройств позволит, ну скажем, одновременно использовать нескольким разным провайдерам одно и то же оборудование. Сами, наверное, знаете, что у сотовых операторов обычно существуют принципы огораживания их собственной инфраструктуры, и, в частности, поэтому есть и белые пятна в сетях, и недостаточно быстро сети развиваются и апгрейдятся.

Что касается применения SDN-сетей в вузах, на эту тему у меня чуть дальше будет несколько слайдов. Вот, я рад, что здесь присутствует и Руслан Смелянский, и Саша Галицкий, с которыми мы вместе продвигаем эти же технологии в России.

Почему это все важно для нашей отрасли? Хочу предложить вашему вниманию два примера, которые, надеюсь, убедят вас в том, что будущее именно за этой технологией. Начнем с крупных провайдеров, тех, кто строит большие магистральные сети. Сегодня они сталкиваются с такой проблемой очень быстрого роста трафика. Однако здесь имеет место субсидирование. Есть с одной стороны чудовищные темпы роста где-то на 40-50% в год. А сейчас эти темпы роста еще больше увеличились в силу просто растущей популярности потокового видео. При всем при этом мы не стали платить больше за интернет. Ну, может быть, вы и начали платить больше, а я вот, сколько платил полтора года назад, столько же плачу и сейчас. То есть, с одной стороны, интернет-провайдер должен обрабатывать постоянно растущий трафик, а с другой стороны, не имеет морального права брать с нас больше денег. Это значит, что оператор должен изыскивать какие-то механизмы снижения собственных затрат. Ну, как операционных, так, видимо, и капитальных. Где-то, конечно, помогают технологии. На самом деле мы знаем, что технологии помогают им снижать затраты не больше, чем на 20% в год. Что же происходит с другими 20%? Ну, вот пока же эти 20% просто вычитаются из прибыли. Причем объясняется вся эта история совершенно фундаментальными тенденциями, с которыми бороться практически невозможно. Что может сделать оператор в этой ситуации? Оператор может сократить капвложения. Что это значит? Использовать более дешевое оборудование. А это само по себе понемножку происходит. Если вы уменьшаете, грубо говоря, парк, вы упрощаете собственный парк, у вас получается заодно и снизить операционные затраты, и затраты на обслуживание железа. Плюс к этому можно, конечно, попытаться дифференцироваться. Если вы сможете убедить пользователя в том, что вы какие-то особенно крутые и от всех отличаетесь, наверное, вам будут готовы платить больше денег.

Пока это сделать очень трудно, постольку поскольку все операторы покупают одинаковое оборудование у очень узкого круга поставщиков. Скажем, если компания AT&T будет конкурировать с British Telecom, ей трудно будет предлагать какие-то уникальные услуги, потому что железо одно и то же. Ну, если бы она могла что-то такое крутое прикрутить к этим маршрутизаторам, коммутаторам, чему-то еще, может быть, появились бы и какие-то уже маркетинговые идеи. Однако вот наши технологии абстрагирования софта от железа как раз и дают им возможность поиграть с тем, что они могут предложить конечному пользователю.

Вот, представьте себе, это логическая структура ЦОДа. Если вы решите построить новый центр обработки данных, вы, наверное, будете ставить порядка 200 тыс. серверов. Это достаточно типовой, наверное, размер. Есть масса, конечно, ЦОДов поменьше, но многие современные ЦОДы имеют приблизительно такую размерность. При этом количество серверов, количество свичей имеет соотношение где-то 20:1. То есть если 200 тыс. серверов, значит будет порядка 10 тыс. маршрутизаторов. Вот, у крупной компании, вроде Google, Аmazon или Yahoo, будет 10 таких ЦОДов. Это значит, уже 100 тыс. маршрутизаторов. То есть на одну такую компанию уже придется заметная часть всего рынка маршрутизаторов. Если за каждый из этих маршрутизаторов заплатить, скажем, $5 тыс., уже получается сколько? $50 млн? Если использовать более простые маршрутизаторы, можно тратить на каждые, скажем, $1 тыс. Так, получается, мы уже сэкономили $40 млн на каждом ЦОДе. Если ЦОДов 10 — $400 млн. Именно поэтому крупнейшие владельцы ЦОДов уже пошли этим путем, приняли это решение некоторые еще лет 5 назад просто потому, что иначе трудно сводить концы с концами. Экономия налицо. Теперь, когда вы сэкономили, скажем, $400 млн, вы на часть этих денег вполне можете взять дополнительно программистов, которые будут писать хороший софт для управления всем этим сетевым хозяйством. Больше того, эти же программисты вам дадут возможность и регулярно обновлять этот софт и, может быть, на основе того же самого типового в принципе, несложного по своему устройству аппаратного обеспечения предлагать какие-то новые услуги. И нам кажется, что поскольку многие из этих разработок являются опенсорсными, инновации в этой области будут идти быстрее.

Почему мне это важно? Я вроде исследователь, сижу на непыльной работе в университете. Почему меня это вообще все беспокоит? Задавшись этим вопросом, я вам заодно расскажу, почему мы все этой темой занялись и почему мы ее так теперь отстаиваем. Все началось с вот этого вопроса: как мы, исследователи, можем тестировать новые идеи в реальных, уже работающих сетях, причем немаленьких? На самом деле вечная проблема релевантности науки. Масса хороших исследовательских идей рождается в университетах и там же умирает, поскольку нет возможности тестировать все в реальных серьезных условиях. Это, кстати говоря, приводит к очень низкому уровню — смешно, когда американцы об этом говорят, — к низкому уровню технологического трансфера из университетов в компании. Однако технологии с программным управлением позволяют нам эту картину кардинально изменить. Американский фонд науки последние несколько лет стал развертывать SDN-сети по всей стране, ну и фактически за счет этого стал подключать, можно сказать, к единой виртуальной сети большое количество американских университетов. Проект называется «Интернет 2.0» у них. Я сейчас хотел вам показать коротенький ролик. Сейчас — нет. Через пару минут.

Так вот, три моих студента в качестве Ph.D своего проекта выбрали вот такую тему, как балансирование нагрузки. Вообще, я считаю, что балансирование нагрузки — это сложная, важная и, кстати, дорогостоящая задача. Студенты предположили, что, в принципе, задачка должна иметь очень простое решение. Раньше для того, чтобы что-нибудь доказать, им нужно было бы использовать какие-то симуляционные инструменты. Но поскольку уже начался вот этот федеральный проект и большое количество университетов уже было подключено к единой виртуальной SDN-сети, они смогли на ней, на вот живом этом материале все оттестировать. Как работает обычный load balancer, устройство для балансирования сетевой нагрузки? Получает энное количество запросов от рядовых пользователей и потом их разбрасывает по вычислительным мощностям. Ну, может быть, вы там, я не знаю, ищете что-нибудь в Google, что-то еще делаете. Если все происходит в очень жестко структурированной сети, вы дальше можете направить эти запросы. Поскольку сеть жестко структурирована, вы сразу видите оптимальный путь. Большинство сетей, впрочем, имеет гораздо более неорганизованную топологию, и запросы приходят из фактически любого участка сети. И тут же встает задача реплицирования и, соответственно, балансировки загрузки, поскольку серверов много, но естественным образом получается так, что запросы приходят неравномерно. Первым делом нужно признать, что балансировка загрузки — это, по сути, просто более умный подход к маршрутизации. То есть это вопрос того, как можно быстрее выбрать правильный маршрут трассировки пакета, который пройдет мимо наиболее сильно загруженных машин и коммутаторов. Ну, вот у нас в большом количестве американских университетов уже стоят наши коммутаторы OpenFlow. Работают они под управлением нашей, собственно, операционной системы NOX — Network Operating System X. Сеть эта позволяет нам проводить одновременно большое количество экспериментов одновременно. Но именно для этого нам нужен механизм, что ли, сегрегации, того, что мы называем Slicing Layer, который нам позволяет эти эксперименты над сетью производить, ну не по всей сети в целом, а, видимо, в отдельных ее участках, изолированных друг от друга.

Хочу теперь показать вам пример того, как вся эта штука работает. Вот, собственно, тема — ролик, который показывает, с одной стороны, расположенные в Соединенных Штатах сервера, ну и показаны как раз потоки запросов. Вот, собственно, здесь вы видите время отклика сервера. Видите, конечно, что разброс таких показателей отклика достаточно большой. Получается, что в традиционной сети, ну это, собственно, привычная картина для традиционной сети без балансировщика. Если же мы с вами находим способ выбора оптимального маршрута доставки пакета, мы можем существенно снизить среднее время отклика. Что вы видите в зеленой части графика? Здесь мы фактически принимаем ряд достаточно простых решений, позволяющих нам выбрать наименее загруженный маршрут. Кстати говоря, сегодня на рынке нет ни одного load balancer, который смог бы принимать решения о том, как лучше всего переправить тот или иной пакет, исходя из того, насколько загружены каналы. Они оценивают только загрузку серверов, что создает совершенно очевидную проблему, имеющую, в общем-то, очевидное решение. Возникают только трудности с реализацией этого очевидного решения. Ну, я говорил уже, что было три студента, которые продемонстрировали, что их система может нормально работать, я уже рассказывал про несколько компонентов. Есть сетевая операционная система, это очень простая методология выбора оптимального маршрута, меньше 500 строк кода. Действительно, когда вы уже развели по углам аппаратную и программную часть, совсем не трудно к программной части уже добавить какие-то оптимизационные элементы. Они будут очень просты.

Приведу еще один пример. Тоже простой и наглядный, демонстрирующий прелесть подобной абстракции. С чего начался этот проект. Хотелось бы, конечно, по максимуму использовать возможности беспроводных сетей. Вот, там где я сейчас нахожусь, мой телефон ловит 12 сетей сотовых операторов и порядка 10 сетей Wi-Fi. Но воспользоваться, подключиться могу только к одной. Резонный вопрос. А что будет, если мы сможем одновременно подключаться к нескольким сетям, и что для этого нужно? Снова показываю ролик. Это, кстати говоря, вы видите здание, из которого я вам звоню, а это, собственно, те самые мои студенты. Вот, мы здесь поставили камеру на тележку, и сейчас мы на этой тележке поедем вокруг здания. Ну, вот вы видите сейчас в левой части экрана ту самую тележку. Они как раз начинают объезд вокруг здания. Проводился эксперимент буквально пару месяцев назад. Вот слева вы видите картинку, которую мы получаем сейчас при использовании нашей единственной доступной в данный момент сети. Ну а справа вы видите, как движется тележка по карте. Ну вот скоро мы потеряем картинку, потому что из одной сети выйдем в другую. Ну к этому моменту, конечно, буфер какой-то будет набран, но вы видите, что, несмотря на существование этого буфера, мы все равно что-то упустим, чего-то не увидим, и качество картинки отвратительное, хотя, поверьте мне, сети используются очень неплохие, камера тоже вроде не самая худшая. Если бы у нас была возможность лучше эту сеть контролировать, что бы получилось. Давайте посмотрим.

Раз у нас на самом деле много точек доступа, мы сейчас по-другому настроим свое оборудование так, чтобы мы могли передавать, собственно говоря, видеокартинку сразу через несколько точек доступа, исходя из того, где канал лучше. И мы здесь передаем еще, ретранслируем эту же картинку куда-нибудь, скажем, в другой уголок страны, чтобы было интереснее. Как вы видите, не везде картинка идеальная, но она, безусловно, лучше, чем в прошлый раз. Мы уже потом тестировали, тот же самый эксперимент проводили с единовременной трансляцией на 400 машин, и, в общем, качество все равно было лучше, чем в предыдущий раз.

Мы, конечно, не пытаемся сказать, что это что-то абсолютно уникальное. Важно не это. Важно то, что провести этот эксперимент было делом совершенно плевым. Вот, собственно, здесь вы видите точки доступа и базовую станцию Wi Max. Весь этот эксперимент поддерживался операционной системой NOX. Для того чтобы провести этот эксперимент, просто понадобилась нашлепка на операционной системе длиной в 250 строк кода. Когда у вас есть глобальное представление о сети, есть четкое понимание топологии, есть нормальные механизмы управления сетевыми ресурсами, вы сразу получаете мощнейший инструментарий для повышения качества работы сети. Теперь представьте, что тот же самый результат пытались бы получить силами оборудования существующих вендоров. Пришлось бы нанять сотни программистов, которые сидели бы год и писали бы хитрый софт, который работал бы на их закрытых черных ящиках.

Покажу еще ролик, связанный, наверное, с еще одним примером того, что нам могут дать сети SDN. Мне кажется, речь может здесь идти не просто о появлении нового сегмента сетевой отрасли. Смелее и правильнее было бы говорить об изменении вообще основных принципов работы сетей. Это то, что нас, собственно, в Стэнфорде в первую очередь и занимает. Раз SDN дает нам возможность выполнения этой абстракции софта от железа, у нас появляется, соответственно, и возможность проведения каких-то предупредительных и каких-то уже дебаггинговых мероприятий эффективнее, быстрее. Для сетевого оборудования давно уже пора было бы придумать такие же механизмы дебаггинга, которые давно используются для собственно компьютерного. На эту тему есть масса хороших работ, написанных ребятами из Корнелла, Беркли, Стэнфорда. Будет интересно —– можете вернуться к моей презентации и посмотреть ссылочки.

Контрольный софт, который работает поверх SDN-сетей, устроен очень просто. Вот привожу типичный пример того, как может выглядеть часть файрвола. Фактически эта контрольная программа компилируется на очень простые форвардинговые правила, которые исполняются коммутаторами. То есть сверху у нас заявлена наша основная идея, а дальше она компилируется уже в аппаратном коде.

Я прошу прощения, это случайно здесь слайды вылезли, я их для ясности пролистаю. Не ту версию презентации мне почему-то запустили.

Как же устроены современные сети? Надо сказать, что мы пользуемся очень рудиментарным инструментарием. Если вам когда-то приходилось сталкиваться с задачей поиска источника проблемы в сети, ну что вы можете сделать? Да буквально несколько команд: ping, tcpdump и так далее. Для софтверной отрасли давно уже появился широчайший инструментарий, а вот в нашей области его не было, и считайте, что нет до сих пор. Нашу работу по отладке сети здесь усложняет, в первую очередь, большое количество протоколов. Кстати говоря, стандартов по работе маршрутизаторов больше 6 тыс., плюс к этому нужно помнить, что маршрутизаторы и коммутаторы, собственно говоря, и взаимодействуют друг с другом самыми разными способами. Там очень трудно уследить за всеми состояниями каждого из устройств, и контролировать их, собственно, поэтому невозможно. Для того чтобы нормально управлять какой-то системой, или сетью в нашем случае, нужно, с одной стороны, ее видеть, а с другой стороны, иметь возможность своими командами за ней угнаться. Это пока в сетевом оборудовании не получается. Можно только преклоняться перед ведущими специалистами по современному сетевому оборудованию, потому что этим людям каким-то чудесным образом удается-таки обеспечить более-менее нормальную работу сетей. Однако таких хороших специалистов, к сожалению, очень мало, и самое главное, весь этот процесс можно автоматизировать и заметно упростить. Более того, в новом режиме эта система будет поддерживать гораздо большую скорость внедрения инноваций.

Кстати говоря, на тему современных сетей, архитектуры управления сетями очень мало существует приличных курсов, учебников. Это не наука, это скорее искусство до сих пор. Я не знаю, это скорее можно назвать философией, идеологией. Здесь игра слов. Мы говорим о том, что управление современной сетью — это йо-йо, в смысле, что ты сам должен в этом всем разобраться, и тебе никто не поможет.

Почему же мы утверждаем, что SDN-сети более просты в управлении, администрировании? Если вы провели вот эту абстракцию, у вас могут быть ошибки либо на уровне виртуализации, либо на уровне контрольных программ, где вы тоже можете сделать ошибку, либо еще могут быть ошибки в самом компиляторе, если компилятор, скажем, неправильно переводит ваши команды в машинный код. В конечном итоге могут быть какие-то чисто аппаратные ошибки. Может быть неправильная обработка процессорами каких-то команд. Либо же могут быть какие-то ошибки, связанные с работой конкретных линков.

Сейчас в Стэнфорде есть несколько потенциально интересных для вас проектов. Если вам будет интересно, кстати, можете прислать мне письма, я постараюсь вам более подробно рассказать. Но, короче говоря, есть несколько проектов, которые нацелены как раз на выявление ранних признаков возникновения ошибок на каждом из этих 4 только что сформулированных мной уровней.

Что же сейчас интересного в этом всем происходит, и в чем лично вы можете поучаствовать? Если вам показалась интересной сама технология, поищите в сети OpenFlow, можно погуглить OpenFlow Tutorial. Вы найдете сразу же такой технический, прагматичный мануал по тому, что такое OpenFlow фактически. Еще вы сможете найти эмулятор такой сети, им легко пользоваться. Вы легко сможете, пользуясь таким эмулятором, скажем, создать некий симулятор на 100 узлов сети у себя на ноутбуке и посмотреть, как же он будет работать. Для этого лучше искать уже не просто по OpenFlow, а по MiniNet. Я полагаю, что эта технология будет определять все развитие сетевого оборудования в ближайшие годы, поэтому полезно присмотреться к ней. Если ваша компания занимается сетевыми технологиями, но еще не вошла в ONF — Open Networking Foundation, значит нужно об этом подумать. ONF, в общем-то, занимается формализацией стандартов. Пока что в нее входит около 70 компаний, представляющих, наверное, основных игроков и основные сегменты нашей отрасли.

В заключение хочу сказать, что сетевое оборудование и сетевые технологии будут определяться софтом. Сколько лет потребуется на эту трансформацию, пока сказать трудно. Может быть, 5, может быть, больше. Но приведенные чуть раньше аналогии из мира ПК убеждают лично меня в том, что эти изменения неизбежны, они приведут к тому, что экспериментирование станет проще, инновации будут появляться и внедряться быстрее. Наверное, появится новый блок, новый сегмент софтверной отрасли. И мне кажется, что здесь карты у вас в руках. Российская софтверная отрасль имеет хорошую репутацию, в частности, в этой области, поэтому мне кажется, что вам нужно уже начинать действовать. Может быть, имеет смысл пообщаться с Русланом, с Сашей Галицким. Может быть, они уже смогут вам что-то предложить. Я собираюсь приехать в Москву через пару недель. Я буду как раз выступать с докладом на тему последних достижений в этой области. Если что, заходите, послушайте… Спасибо, у меня все.

ВЕДУЩИЙ: Спасибо большое, Ник. Ты, конечно же, помнишь, что сейчас тебе будут задавать вопросы, тебе нужно будет на них отвечать. Уважаемые коллеги, пожалуйста, если у вас есть вопросы к Нику, поднимайте руку, вставайте, говорите на одну из камер и представьтесь, пожалуйста, перед тем, как задать вопрос.

ВОПРОС ИЗ ЗАЛА: Александр, секьюрити-инженер, студент одного московского университета. Хотел спросить вот что. Вот протоколы, отвечающие как раз за вопросы безопасности, они же будут фактически передаваться по тем же самым каналам, что и данные. А это не подвергает дополнительной опасности целостность данных, защищенность передаваемых данных? Спасибо.

НИК МАККЕОН: Хороший вопрос задаете. Перефразирую ваш вопрос. В современных сетях, если вы хотите, скажем, провести DDoS-атаку, ну или если вы хотите как-то вывести из строя или проманипулировать контрольную часть, вам нужно будет, собственно, провести эту атаку по всему парку типового оборудования. В SDN-сети вам нужно будет для того, чтобы получить контроль над сетью, нащупать control plane, который фактически будет распределенным. Он не будет локализован на одной машине. Собственно говоря, контрольная часть сети может находиться в том элементе сетки, который будет закрыт для внешней сети, может находиться, скажем, в каком-то большом WAN-сегменте, куда в принципе не проникают пакеты извне. То есть уже таким образом можно обеспечить безопасность control plane, он будет фактически невидим снаружи. Большое количество успешных атак сегодня против современных сетей объясняется как раз тем, что контрольную логику можно пробить извне. Смог ответить на ваш вопрос?

ЗРИТЕЛЬ: Ну типа того.

НИК МАККЕОН: Видимо, не полностью.

ВОПРОС ИЗ ЗАЛА: Здравствуйте. Виталий Обернихин. Несколько простых вопросов. Первый. Если недоступна контрольная логика, что тогда свич будет делать? Просто все пакеты дропать? Пока что сетевое оборудование работает достаточно надежно.

НИК МАККЕОН: Хороший вопрос. Если действительно коммутатор находится физически очень далеко от контрольной логики, вы будете обеспокоены тем, что вдруг он потеряет связь с блоком управления. Ну, во-первых, нужно реплицировать контрольную систему. Я вот нарисовал на своих слайдах control plane как одну коробочку, но я еще раз повторяю, что это на самом деле распределенная система, и это, собственно, обеспечивает вам необходимый уровень избыточности. Ну, хорошо, мы можем предположить, что ваш удаленный коммутатор потеряет одновременно все сервера управления. В этом случае протокол OpenFlow все равно позволяет вам инструктировать свич на случай выполнения каких-то локальных мероприятий, что, мол, если коммутатор теряет связь, то дальше он, в общем-то, будет действовать по заданным вами правилам. Он может просто отключиться, посчитав, что это слишком опасная ситуация. Либо же можете задать другое правило — что коммутатор будет выполнять последний набор инструкций, пока на связь снова не выйдет control plane, с которым он свяжется и получит новый набор инструкций. Если вы принадлежите к лагерю параноиков, то вы пишете правило, что, мол, перестал видеть control plane — отключайся.

ЗРИТЕЛЬ: Еще один вопрос, если можно.

НИК МАККЕОН: Только я тебя не слышу.

ВОПРОС ИЗ ЗАЛА: А если у вас много сетевых контроллеров, а их там, я не знаю, может быть 10 тыс. в ЦОДе, а то и 100 тыс., встает задача поддержания, собственно, консистентности информации о состояниях, потому что дальше сетевому контроллеру нужно за ними всеми уследить.

НИК МАККЕОН: Хороший вопрос. Действительно было несколько примеров того, как уже создавались такие распределенные контроллеры. Один из них, кстати, коммерческий уже продукт под названием UNIX, на мой взгляд, будет хорошим как раз примером. И именно на нем, судя по всему, и работает гугловская WAN-сеть. Конечно же, вам не нужно 10 тыс. контроллеров для сети на 10 тыс. свичей, вам нужно буквально их 100, может быть. Но при всем при этом проблема, которую вы заявили, все равно будет иметь место. Все маршрутизаторы в современной сети фактически создают распределенную систему для каждого поддерживаемого протокола, будь то BGP, OSPF или что-то еще. Собственно, большинство этих систем впервые было придумано 20 лет назад и с тех пор особо не изменилось. На самом деле, если вы придумаете логику решения этой задачки на программном уровне, дальше она будет прекрасно работать с любыми протоколами, она действительно пойдет на пользу любому протоколу. В последние 10 лет мы сделали очень много шагов вперед как раз в плане оптимизации крупных распределенных систем. В этом плане мы многим обязаны компаниям вроде Google. Когда вы решили хотя бы один раз такую задачку управления распределенной системой, вы дальше этот успех можете легко реплицировать. В общем, я считаю, что в ближайшее десятилетие мы увидим, что распределенные сетевые системы будут работать гораздо надежнее, чем современные.

ВОПРОС ИЗ ЗАЛА: Какова самая передовая потоковая таблица современная? Что, она 4000 одновременно поддерживает? Стоит ли игра свеч в современных VLAN?

НИК МАККЕОН: Действительно, если у вас очень закрытое железо, у вас, в общем-то, и нет особого запроса на SDN-сети. Я вот уже говорил, что основной спрос на SDN-сети сейчас представляют крупнейшие ЦОДы виртуализированные. В виртуализованном ЦОДе, собственно, первый свич находится на хостовом компьютере, который фактически, физически расположен на гипервизоре. И это, понятное дело, программный свич. Раз он программный, вы его легко можете улучшать и обновлять. Именно поэтому первые изменения и улучшения коснулись как раз программной, а не аппаратной части. С другой стороны, очень много денег вкладывается в ЦОДы прямо сейчас, и именно на ЦОДах новые идеи часто и обкатываются. Однако большое количество устройств было спроектировано с минимальными потоковыми таблицами. Таблицы расширялись понемножку, постольку поскольку производителям казалось, что нет запроса на большее. Может быть, вы знаете, что NetLogic уже предлагает последние 5 лет, наверное, 32-мегабайтный TCAM в своих устройствах. Давно уже доступно, 5 лет доступно, я говорю, но просто не было спроса раньше. Так что я думаю, что будет понемножку увеличиваться и размерность таблиц потоков.

Я недавно занимался исследовательским проектом с исследовательской лабораторией компании Texas Instruments, вот они уже экспериментируют, соответственно, с 128-тысячной разрядностью таблиц потоков на своих чипах 64-портовых, как я понимаю. Опять же агрегирование позволит вам не гнаться за размерностью таблицы потоков. Вот мне кажется, что в Google — в его достаточное большой WAN-сети — используются не очень большие таблицы потоков, ну, может быть, размерность там 8 или 16 тысяч, точно не больше.

ВОПРОС ИЗ ЗАЛА: Спасибо. Последний вопрос. Стандарт OpenFlow простой и этим прекрасен, но практически никто сейчас не пишет на простом языке, нам уже нужен более высокий уровень абстракции, типа того, что работает уже на уровне выше NOX. Появляются ли уже соответствующие стандарты, появляются ли соответствующие API?

НИК МАККЕОН: Тоже хороший вопрос. Всегда, когда мы разрабатываем новую технологию, мы первым делом смотрим стандарты, постольку поскольку стандарты обеспечивают взаимооперабельность, нормальное взаимодействие сетевого оборудования. При этом в области софта у нас стандартов очень мало. Например, до сих пор нет стандарта для такого языка, как Ruby. Возник он как опенсорс, ну и понемножку в силу своей эффективности стал очень популярен. В софтверной отрасли нам нравится что-то новое придумывать, экспериментировать, ну и если эта наша придумка набирает популярность, набирает обороты, возникает желание ее стандартизировать, в то время как в области сетевых технологий все по-другому: нам нужно жестко прописывать стандарты аппаратного взаимодействия. Если же мы попробуем сейчас что-то стандартизировать на более высоком уровне, мы столкнемся с тем, что это реально очень сложно, потому что современный софт в этой области намного лучше, намного более продвинут, чем тот, которым пользовались раньше, и стандартизация здесь будет естественным врагом прогресса. Здесь можно вспомнить историю возникновения стандартов POSIX, которые как раз и регулируют написание операционных систем и софта. Первая версия POSIX вышла лет через 15 после появления первой версии UNIX, так что я думаю, что пройдет еще лет 5-10, прежде чем мы придем к общему пониманию того, каким должен быть API, стоящий поверх операционной системы. Я вообще бы предпочел, чтобы мы никогда не дошли до стандартизации в этой области. Мне кажется, что лучше дождаться того, что возникнут просто де-факто стандарты, что сложится просто какой-то узел, сложится некая передовая практика, которой будут пользоваться все. Она не будет требовать никакой кодификации, и мы от нее откажемся, как только придумаем что-то лучшее.

ВОПРОС ИЗ ЗАЛА: Здравствуй, Ник. Скажи, пожалуйста, пару слов о том, как все это повлияет на бизнес. Вот помимо VMware, какие еще компании выгадают от этих изменений? И выживут ли крупные современные игроки вроде Cisco, в новых условиях? Ну, или прямо сейчас лучше продавать акции Cisco?

НИК МАККЕОН: Я думаю, что сначала произойдет то, что произошло в свое время в компьютерной отрасли, а именно взрывной рост. Как только снижаются барьеры на вход, снижаются конкурентные барьеры, начинается резкий рост отрасли, повышается ее эффективность, повышается инновационность, и с определенным лагом повышаются и доходы лучших игроков. Трудно сказать, что больше выиграет — то ли операторы ЦОДов, то ли операторы больших публичных WAN-сетей. Им это все, безусловно, пойдет на пользу, поскольку новые сети, я думаю, будут работать лучше и надежнее. Что же касается вендоров, то от этих изменений выиграют, конечно, поставщики софта. Сюда, конечно, нужно помимо VMware добавить, видимо, и Microsoft, и похожие на них компании. Однако история развития компьютерной отрасли учит нас тому, что большие, крупные компании, вроде IBM, Hewlett Packard, ушли от производства специализированного железа в сторону производства написания софта. Рано или поздно, но они все приняли правильное решение. И, конечно, современным мощным игрокам на этом рынке пора бы уже взяться за ум и понять, что именно в эту сторону движется отрасль. Нет никаких причин, которые не дали бы современным мощным игрокам возможности успешно выступить в области, скажем, SDN-оборудования. У них много своих хороших технических экспертов, специалистов, аналитиков. Если они потеряют от этих изменений, то только в силу собственной зашоренности. Мне кажется, что у Cisco, Juniper и прочих компаний есть все необходимое для того, чтобы хорошо на этом рынке сработать. Если вас это интересует, я их акции не продаю пока.

ВОПРОС ИЗ ЗАЛА: Здравствуйте, Ник. Спасибо за лекцию. Зовут меня Владимир Почивалов, я из Московского государственного технического университета. Есть вопрос насчет вашей сетевой операционной системы. Вот на каком железе она бегает? Не совсем я понял, централизована или же распределена, какие протоколы она использует, собственно, для общения с коммутаторами и какого масштаба сети она может поддерживать?

НИК МАККЕОН: Нужен обычный рядовой сервер — «серверус вульгарис». Это может быть линуксовый, виндоузовый сервер. Помимо NOX есть еще «Тремор», «Фладлайт», «Бикон». Они все работают на типовых простеньких серверах, причем в большинстве случаев они реализованы как отдельный инстанс. На самом деле не так много пока развернутых реализаций, распределенных имплементаций. Лучшим примером как раз такого распределенного внедрения будет ONIX. Причем вот эти разные инстансы установленного ONIX друг с другом разговаривают по какому-то проприетарному протоколу. Дальше взаимодействие между железом и ОС идет по протоколу OpenFlow. Это не единственный вариант. Можно использовать для этих целей и другие протоколы. Кстати говоря, в этой области нужна стандартизация.

Последний вопрос был насчет размера сети. Мы всем этим занялись, когда 5 лет назад, наверное, построили первую прототипную сеть в Стэнфорде, и меня поразило то, что немного нам нужно было этих управляющих контрольных серверов. У нас в Стэнфорде 35 тыс. пользователей, 2 тыс. свичей в целом по кампусу. Каждый свич использует несколько процессоров, которые ему нужны для того, чтобы решить, как маршрутизировать пакеты. Если бы мы заменили их на традиционную сеть и поставили бы совсем дешевые коммутаторы долларов по 400… У нас, кстати говоря, на кампусе действорвало 137 политик, которым должно было соответствовать наше сетевое оборудование. Я вот посчитал, для того, чтобы у нас всем этим хозяйством управлять, нужен всего один сервер. Во многих компаниях тоже одного сервера будет достаточно. Для очень больших сетей нужен будет десяток серверов, для WAN-сетей, наверное, 10-15 серверов нужно будет. Помните закон Мура: поскольку растет вычислительная мощность процессоров, уменьшается потребность в их количестве.

ВЕДУЩИЙ: Ник, ты знаешь, это был последний вопрос. Мы, в принципе, тебя можем отпустить. Впрочем, перед этим мы тебя хотим поблагодарить за прекрасную лекцию. Вот эти вот жаркие аплодисменты мы отправляем тебе наложенным платежом прямиком в Калифорнию.

контакты

119072, Москва, Берсеневская набережная, 6, стр.3

+7 (499) 963–31–10
+7 (985) 766–19–25
do@digitaloctober.com