Облака и SDN

Последний модуль в нашем курсе будет посвящен замечательной теме облака белогривой лошадки и Software Defined Networking. Как все хорошо, когда оно само работает, когда ничего не надо настраивать. Да, идея утопичная, реализация, как всегда. Давайте посмотрим, что нам Cisco предлагает на это дело посмотреть. Для начала заметим, что последние тенденции в области IT предусматривают виртуализацию всего и вся, абстракцию от каких-то чисто железных ограничений, например. Мы говорим: давайте будем виртуализировать серверы. У нас есть железный сервер, на нем можно грузить какую-то одну нагрузку. Мы можем взять на этом сервере запустить гипервизор, запустить много разных виртуалок и в каждую виртуалку запихать чего-нибудь. И тогда каждая конкретная виртуалка фактически съедает немножко ресурсов сервера, но на одном сервере мы запускаем несколько разных полезных нагрузок одновременно.

Можно сделать так, чтобы конкретная виртуалка запускалась не на конкретном гипервизоре, а гуляла между разными гипервизорами. У нас один сервер выключается, виртуалки быстренько мигрируют на другой сервер, соответственно, не происходит падение сервиса. Аналогичную историю можно представить себе и с сетями. Мы можем взять и виртуализировать что-нибудь в сетевом плане. Классический пример — это коммутация, которая виртуализирует широковещательный домен. Мы можем с использованием коммутируемых сетей не зависеть от того, что в широковещательном домене где-то происходят какие-то разрывы, нам Spanning Tree быстренько все перестроит. На самом деле, когда мы пользуемся сетью, мы пользуемся не самой сетью, а тем, что сеть нам предоставляет услугу — услугу доставки данных. И эта услуга тоже может быть виртуализирована, так или иначе. Мы можем при необходимости нагло пользоваться услугой,

а дальше эта услуга, как она физически оказывается, на каких железках — обычным пользователям абсолютно все равно. Если говорить про то, что мы можем сделать для автоматизации процесса управления сетью, это будет механизм, который называется Software Defined Networking. Мы можем сделать следующее. Если у нас будут достаточно умные железки, и мы поверх этих железок будем пускать трафик каких-то приложений, и у нас есть какое-то приложение, которое управляет нашей организацией, например, 1С, мы можем заставить управляющее приложение управлять нашей сетью вместо нас, вместо администраторов. Мы, как люди, не будем подключаться к консолькам этих самых роутеров, свитчей и дальше там прописывать IP-шники, прописывать Quality of Service механизмы, прописывать access-листы. Мы можем положиться на то, что некое приложение зайдет на плоскость управления нашими устройствами

и проадминистрирует их само за нас. Изначально механизм Software Defined Networking, программно определяемых сетей, предполагал, что у нас есть некий контроллер, который управляет всеми устройствами, и на отдельные устройства зайти и проадминить их человек просто физически не может. Эту идею достаточно долго пыталось продвигать сообщество, но в итоге выяснилось, что продвигается она плохо. Но идея на самом деле не самая свежая. Если посмотреть на некоторые другие протоколы, которые в IT существуют, то мы увидим, что эта идея не просто выстрелила в каких-то местах, она является очень интересной. Например, есть такой протокол InfiniBand. У него тоже есть свитчи, тоже есть адаптеры, и визуально InfiniBand в какой-то степени похож на Ethernet. Свитч Ethernet-овский, свитч InfiniBand-овский — они прямо похожи. Адаптер InfiniBand-овский, адаптер Ethernet-овский тоже похожи.

И некоторые производители, тот же самый Mellanox, делают сетевые карточки, которые можно переключать из InfiniBand в Ethernet и наоборот. InfiniBand отличается тем, что у него существенно меньше задержки по сравнению с Ethernet, но он работает только на очень небольших расстояниях. Это специальный протокол связи для высокопроизводительных серверов, для нагруженных вычислений, для построения кластеров. По сути своей, это тот же самый Ethernet. В нем нету MAC-адресов, например, но у него никогда не было толстого желтого коаксиала, зато у него есть процедура коммутации, которая по большому счету напоминает Ethernet-овскую. Но в Ethernet мы процедуру коммутации выполняем с помощью MAC Learning. Мы подсматриваем кадры, которые проходят через наш свитч, и дальше, догадываясь, что может быть только один путь между двумя узлами в Ethernet, эта процедура MAC Learning строит таблицу коммутации на каждом отдельном свитче.

Эта процедура может быть не очень эффективна, на нее можно устроить ряд неприятных атак, но она как-то худо-бедно работает. В случае с InfiniBand у нас нету процедуры MAC Learning, у нас есть специальный узел, который знает, как устроена сеть, и он управляет всеми свитчами, он управляет всеми конечными абонентами, и он строит кратчайшие маршруты между всеми этими абонентами, таким образом достигая того, что все свитчи гарантированно оптимально пропускают трафик между любыми двумя узлами, если мы говорим про InfiniBand. InfiniBand — это протокол довольно древний, он родился в начале 2000-х годов, а может быть даже в конце 90-х, скорее в начале 2000-х. И авторам Ethernet было, конечно, очень долго завидно, что такой замечательный протокол так хорошо работает, а в Ethernet дурацкая процедура MAC Learning, которая нужна для того, чтобы максимально хорошо прикидываться толстым желтым коаксиалом. И долго предпринимались попытки сделать так,

чтобы Ethernet превратился тоже в программно определяемую сеть. Дело это было сравнительно безуспешно, но примерно в середине 2000-х годов стали появляться первые наметки. Стал появляться протокол OpenFlow, который позволял управлять поведением свитчей. Далее попытались этот протокол развить, но выяснилось, что всё получается по-дурацки. Короче говоря, с Ethernet-ом всё это дело не взлетело. Идея, однако, продолжала будоражить умы людей в отрасли, и стали думать: окей, раз мы не можем управлять свитчами через специализированный протокол, мы же можем, например, взять и зайти на железку просто по обычному Telnet-у. Давайте мы сделаем так, что у нас будет контроллер, который эмулирует поведение человека, который заходит на железку по Telnet-у и ее админит просто как человек. Это обычный тот же самый инструмент,

который у нас есть, но он позволяет делать все то же самое, что мы позволяем делать человеку. А то, что там машина решит сделать, какие команды она выполнит — пусть она сама думает, что имеет смысл выполнять. Эту идею отрасль тоже стала развивать, тоже в это поигралась. Выяснилось, что цисковский инструмент для управления командной строкой не самый удобный и не самый структурированный. Поэтому в итоге сегодняшние программно определяемые сети на самом деле используют какую-то промежуточную идею, когда есть специальные протоколы для управления устройствами, но эти протоколы, как правило, основаны на каких-то функциях, которые можно удаленно дергать. У вас есть программно определяемый интерфейс API, и дальше можно будет взять из контроллера зайти на роутер, на свитч, выполнить какую-то функцию, и эта функция отреагирует так же, как будто человек зашел и выполнил какие-то действия. Например, нам нужно добавить новый маршрут.

У нас есть API, мы берем с контроллера, дергаем некоторую функцию, у нас появляется новый маршрут. Понятное дело, что можно было как человеку зайти Telnet-ом, прописать ip route, и добавился бы тот же самый статический маршрут. Но через API это более удобно для машины. Что касается того, зачем это все нужно. У нас есть какое-то приложение. Представим себе, что это, например, 1С. В 1С у нас есть управление персоналом. Мы хотим, чтобы в управлении персоналом завелся новый пользователь, который бы принадлежал отделу бухгалтеров. Соответственно, в 1С заводится новый пользователь. 1С сообщает контроллеру управления сетью, что пользователь находится в таком-то отделе, сидит за таким-то столом. Контроллер сети говорит: окей, раз он сидит за таким-то столом, он подключен к такой-то розетке,

значит, нам нужно организовать передачу данных от этой розетки до куда-то там. Например, нам нужно будет сделать так, чтобы трафик, который проходит от него до сервера телефонии, который вот здесь находится, проходил бы с максимальным качеством. Если нам нужно будет выпустить его в интернет, то поскольку он бухгалтер, сильно много трафика ему не нужно, значит, здесь на выходе мы должны будем написать такой механизм shaping или policing, что нужно будет сделать, чтобы трафик, который он выпускает в интернет, лимитировался бы, например, одним мегабитом в секунду. Сам контроллер, который у нас есть, на основании того, что появился новый юзер в 1С, и 1С об этом отчиталась, сказала, в каком месте этот пользователь сидит, сам контроллер проадминит этот свитч, этот свитч, этот роутер, этот интерфейс настроит, тут весь Quality of Service пропишет. Это произойдет автоматически. И нам не нужно будет отдельно заходить на каждую железку и отдельно настраивать ее то там, то там. Здесь важный момент заключается в том,

что это все происходит автоматически, что у нас есть приложение, в котором создалась какая-то новая сущность, и это приложение с помощью какого-то универсального интерфейса сообщило контроллеру сети, а контроллер сети с помощью каких-то универсальных интерфейсов настроил все отдельные устройства. Вмешательства человека здесь не требуется. Чтобы это все работало, нужны программные интерфейсы, которые будут поддерживаться всеми участниками. И здесь возникает первая сложность, что у нас появляется два разных типа этих самых интерфейсов. Первый программный интерфейс будет между приложением, где у нас происходит вся магия, и контроллером самой сети. Здесь у нас работают приложения, те самые 1С, здесь у нас работают контроллеры сети, те железки, которые умеют подключаться к нашим роутерам, свитчам. Взаимодействие между ними происходит с использованием программного интерфейса Northbound API, то есть северный API. Если посмотреть классически,

как компас рисует, здесь у нас север, здесь у нас юг. От контроллера сети на север у нас будет Northbound API. По этому Northbound API приложение может сообщить, что в сети что-то произошло. Например, что нам нужен новый пользователь. Может сообщить, какие параметры в сети требуются этому пользователю. Опять же, оно сообщает, что это бухгалтер, что бухгалтеру вряд ли требуется много интернета, ему требуется доступ к определенным серверам. Как бы там ни было, контроллер по Northbound API понимает то, что нужно будет сделать, и дальше по Southbound API сообщает всем уже отдельным железкам, как они должны работать. Здесь может быть много разных вариантов, как они настраиваются. Может быть здесь именно API, программно определяемый интерфейс. Может быть, он будет реально Telnet-ом заходить и админить каждую из этих железок. Telnet, SSH. В зависимости от того, что вы здесь готовы получить,

за что вы готовы заплатить деньги, какую конкретно функциональность поддерживает ваше железо, здесь может происходить все по-разному. Но предполагается, что здесь есть какой-то программно определяемый интерфейс, и Southbound API, от контроллера на юг, находятся эти самые железки, infrastructure layer. Вызовы будут дергаться и определять уже поведение конечных устройств. Протоколы, которые используются, их бывает много разных. Соответственно, чаще всего на Northbound API у нас работают обычные REST-вызовы, SOAP, REST. Крайне редко там бывает что-то еще. Приложение дергает контроллер, используя какие-то абсолютно стандартные вещи. А вот с Southbound API там все очень сильно вендорозависимое. Изначально предполагалось, что будет какой-то open flow. Потом, соответственно, стандартом в отрасли плюс-минус километр стал netconf. Потом CISC сказал, знаете, netconf какой-то не очень клевый, давайте сделаем свой фирменный преприетарный протокол.

Но сейчас все это свелось к тому, что вот здесь вот по факту бегают, ну, какие-то, опять же, стандартные вызовы, типа тех же самых REST вызовов. Но, опять же, все очень сильно зависит от конкретного вендора, от конкретных моделей устройств. То есть здесь бардак. Фактически можно сказать, что software-defined networking – это идея, которая очень красивая, которая захватила умы очень многих людей, но по факту сегодня SDN, ну, в общем, не работает. Концепция пока остается утопической. Так, чтобы вот прям совсем, чтобы в один эске добавили юзера, и он сам сделал, сама сеть подстроилась под этого нового юзера. Это пока только во всяких рекламных материалах вендоров есть, а по факту такого пока нет. CISC стремится к тому, чтобы это можно было сделать. И если у вас даже нету прям полноценной SDN, она говорит, ну, давайте хотя бы максимально приблизимся к этому. Давайте мы вам продадим вот такую вот штуку,

которая называется APIC EM – Application Policy Infrastructure Controller Enterprise Module. Причем не просто продадим, он еще и бесплатный. Но кое-какие вещи в нем платные. Он умеет залезать на CISC, он умеет на этих CISC определять, что происходит, он умеет работать с Quality of Service, он умеет работать с Access Listами, он умеет автоматически обнаруживать железки, которые у вас находятся внутри сети, он умеет работать с Intelligent One, очень хорошая с точки зрения CISC, штука, которая, правда, очень сильно стоит денег. Смысл заключается в том, что если у вас есть какие-то филиальные сети, вот у вас есть роутер, вы его подключили к интернету, и он дальше сам построил маршрут с APIC EM, сам получил с него настройки, сам построил общую связь с остальными роутерами, которые формируют общую сеть, и у вас во всей сети, во всей филиальной сети работает единая общая среда передачи данных. То есть zero configuration во всей его красе.

Ну, как бы интересная, клевая штука, но у него есть свои минусы, в частности, дорогой собака. На экзамене от вас потребуется знание того, что вот эта штука, она бывает. Вы можете, если хотите, попробовать скачать ее, она бесплатная, но единственное, что она требует катастрофического объема ресурсов для своей работы. То есть если вы хотите ее у себя развернуть, она у вас потребует, если мне память не изменяет, 64 гигабайта оперативки, 500 гигов места на диске, 8 процессоров, 8 ядер. Ну, то есть она реально жручая. Она внутри себя запускает кучу виртуалок, помимо всего прочего. На экзамене от вас потребуется продемонстрировать понимание того, как работают два механизма в этой штуке. То есть не надо будет прям целиком знать, как она работает, но достаточно будет, если вы хотя бы примерно будете представлять, как работает path trace, это определение пути между двумя железками. То есть по сути своей, если вы заходите на вот эту штуку,

вам она показывает webmort. И в этой webmort вы можете сказать, давайте запустите мне определение пути, вы указываете, что вы хотите посмотреть, через какие устройства пройдет трафик, если вы от IP-шника там 10.1.1.1, хотите посмотреть, куда пройдет трафик до 10.2.2.2. И вот он говорит, трафик пойдет через коммутируемый интерфейс L2 на switch, дальше через коммутируемый транк вот сюда на distribution switch, здесь он превратится в routed L3 интерфейс, здесь у нас будет OSPF, который протащит маршрут, дальше все это дело уйдет через E1 тот самый, через dmvpn, если хотите, с MPLS, с чем-то там еще, все это дело придет на филиальный роутер, и вот дальше оно уйдет там на точку доступа беспроводную и на ноутбук, который имеет IP-шник 10.2.2.2. То есть он по имеющимся IP-адресам поймет, как именно должен проходить трафик, через какие именно интерфейсы,

почему именно так, какие интерфейсы там Spanning 3 заблокировал, какие интерфейсы выбрал в качестве исходящих OSPF, какие BGP, где у нас происходит балансировка между какими интерфейсами, то есть все вот это вот он вам покажет. И еще одна штука, которую нужно будет знать, это ACL Analysis. Он будет фактически делать то же самое, только он будет еще по пути между двумя узлами, которые вы укажете, смотреть, где какие аксесс-листы будут мешать прохождению трафика. То есть вы указываете, какое приложение вы будете использовать, например, говорите RDP. Вот я буду с 10.1.1.1 подключаться по RDP на 10.2.2.2. Вот он скажет, где у вас какие аксесс-листы, возможно, будут мешать прохождению такого трафика. Он скажет, здесь все хорошо, здесь все хорошо, здесь все хорошо, здесь тоже все хорошо, а вот здесь у нас аксесс-лист будет отбрасывать такие пакеты. Вы должны будете потренироваться, поработать с этим Epic EM.

Но еще раз говорю, мы не предоставляем доступ к нему, потому что его разворачивать реально долго. И ради двух несчастных механизмов, ну, просто нецелесообразно поднимать. Вы можете сделать себе вот эту штуку самостоятельно, но это опять же нецелесообразно, потому что это опять же долго. Но есть нюанс, заключающийся в том, что вы можете пойти на сайт Cisco и бесплатно на сайте самой Cisco запустить виртуалку с вот этой вот фигней. Но на ограниченное время. Как правило, для того, чтобы просто потыкать, что это вообще работает, что там есть вот этот самый паст трейс и осели анализа, этого более чем достаточно. Механизмы, не механизмы, а ссылка, которая нужна для того, чтобы потыкать вот это вот в лаборатории Cisco, будет иметь вид dcloud.cisco.com. Рекомендуется, соответственно, подписаться на этот самый dcloud,

запустить там лабораторную работу на apiqe, подключиться, проверить, что действительно связь есть, проверить, что вы видите вебморду, попробовать там path trace, попробовать там acel analysis и на этом успокоиться, сказать, что в объеме экзамена вы этот материал освоили. Надо будет отчетливо понимать, что эти два механизма являются совершенно четко маркетинговой попыткой продвижения цисковского apiqe, потому что он откровенно не выстрелил, а надо его как-то продавать. Поэтому Cisco впихнуло его просто всеми правдами и неправдами в ICND2. При этом на самом деле он там нафиг не нужен, потому что количество предприятий, которые его используют, оно около нулевое. Для того, чтобы его использовать, вы должны будете использовать исключительно все самые современные свечи Cisco, то есть это девятитонники каталисты. И вот если вы используете девятитонники каталисты, если вы используете свежие роутеры, да, вы можете испытывать какие-то преимущества от того, что это type-eam у вас работает. Но тогда вы очень маловероятно

будете представлять маленькое предприятие. Вы будете, скорее всего, каким-нибудь банком, и в банке, да, в банке вот эту вот штуку как раз клево использовать. Там денег много. Там вы заплатили сначала вагон денег за каталисты новые со всеми смарт-нетами, а потом вы заплатили еще вагон денег за бесплатный API-KM со всеми модулями, типа того же самого Ивана. Ну, да, там можно его потрогать, потыкать. А в реальности в небольшой сети предприятия он никому не уперся, вообще совсем никому не уперся. И вы с ним никогда не будете работать, если вы будете работать с маленькими сетями. А этот курс, ICND2, я напомню, он вообще-то про маленькие сети. Поэтому не нужно это все. На экзамене нужно будет попробовать, показать, что вы это знаете. Ну, там вопросы будут типа такие, что как называется механизм, который позволяет определить путь? Past trace, past ping, past find, past что-нибудь. Ну, надо будет сказать, что называется past trace. Да. Вот эта вот ссылка, я боюсь, она не очень актуальная,

но тем не менее, да, dcloud.csco.com. Вот так вот выглядит интерфейс этого самого API-кема. Вы уходите в механизм, который называется past trace, сюда вы челкаете, выбираете past trace, указываете, что конкретно вы хотите потрассировать. Там в окошке вбиваете IP-шники, вот в нашем случае там, с одного IP-шника на другой пускаете этот трафик. И система говорит, что вот это 10.1.15.2, это ноутбук, он подключается по беспроводной сети к точке доступа 10.1.14.3, она подключена прямым проводом к свечу 10.1.12.1, он подключен транком к вот этому свечу, это все подключено вот сюда, вот, а это контроллер, простите, вот этот вот контроллер. При этом, вот эта вот точка доступа, она тупая, она сама работает только с контроллером, поэтому она строит кап-флаб-туннель, и трафик заворачивается в этот кап-флаб-туннель, потом трафик выходит на свеч на транк, вот на какой-то там свеч, потом на другой свеч,

потом на третий свитч, или у нас даже роутер. И здесь у нас equal cost multipass, балансировка еще и происходит. Дальше работает маршрутизация по SPF на вот этот вот роутер. И у него указанная сетка, которая нас интересует, connected 10, 2, 1, 17, куда-то там уходит. Топология там предустановлена, там уже некоторое количество свитчей, некоторое количество роутеров, некоторое количество точек доступа, но для того, чтобы понять, как это работает, этого более чем достаточно. Ещё раз подчеркну, в реальном предприятии вы это никогда не будете использовать, потому что это колоссальная бандура, которую непонятно зачем настраивать, во-первых, потому что она ничего толком не делает. Эти два инструмента, Packet Tracer и анализ, это самый верх того, что она может. А всё остальное, что она делает, это чисто декоративное. Если вы захотите, вы можете попробовать просто потыкать её и поймёте сами, что толку от этой штуки примерно ноль. Так, мы закончили теоретическую часть нашего курса.

Всё, что мы с вами прошли, кроме облаков, это всё действительно реально используется. И OSPF, и BGP, и EIGRP, это всё можно встретить в реальной сети предприятия. Естественно, Spanning Tree. На закуску нам оставили такой сладенький модуль. Засим, наверное, сегодня мы с вами заканчиваем наши занятия. Напоминаю, что у нас есть всякие замечательные сервисы на нашем сайте. У нас есть замечательная группа в Телеграме, так что если вдруг вы ещё не там, то присоединяйтесь. Кроме того, как всегда, я прошу всех, кто сдаёт экзамены, перед тем как идти сдавать экзамен, написать мне, потому что я вас приободрю. Может быть, каким-то ценным советом помогу. Кроме того, когда вы сдадите экзамен, напишите, как всё прошло, чтобы я, если вдруг вы сдали, за вас порадовался. А если вдруг не сдали, то, соответственно, понял бы, как можно улучшить наш курс для того,

чтобы процент сдачи стал побольше. Практика показывает, что ICND 1 и 2 сдают с первой попытки большинство участников, потому что экзамен на самом деле несложный. Если хорошо к нему подготовиться, сделать все лабораторные работы, которые курсом предусмотрены, и не филонить в части теории, то сдаётся это всё с первого раза легко. Рекомендуйте нас своим друзьям, и, пожалуй, на этом наш курс закончен.