Переход к технологии программно-конфигурируемых сетей

Международная практика показывает, что радикальные изменения в информационной сфере экономически развитых стран, произошедшие на рубеже XX – XXI веков, существенно изменили облик информационной структуры, которая стала одной из наиболее перспективных и динамично развивающихся базовых инфраструктур общества.
Современная информационная структура страны состоит из мощных телекоммуникаций и разнообразных информационных систем, которые в соответствии с общественными тенденциями, интегрируются в единый инфокоммуникационный комплекс.
Международный опыт развитых стран показывает, что стратегической задачей является кардинальная перестройка национальных информационных инфраструктур на пути к глобальному информационному обществу (ГИО) в соответствии с основополагающими принципами его создания. В это связи в указанных странах проработаны основополагающие принципы создания и интеграции национальных информационных инфраструктур в глобальную информационную инфраструктуру (ГИИ).
В Республике Узбекистан также информационная инфраструктура является одной из важнейших инфраструктур страны и ей принадлежит особая роль во многих сферах деятельности общества. Приоритетной задачей в Республике Узбекистан также является создание и развитие национальной информационной инфраструктуры на основе новых сетевых технологий передачи данных. Это обусловлено тем, что инфокоммуникации, проникая во все инфраструктурные и базисные компоненты общества, становятся одним из мощных инструментов управления страной и катализатором её экономического роста.
В этой связи, целый ряд новых проблем и задач возникает в результате интенсивного роста объема трафика данных и перехода к высокоскоростным технологиям на основе коммутации и организации новых служб ПД.
Как известно, для передачи трафика данных были разработаны два метода коммутации пакетов: метод виртуализации соединений и метод дейтаграмм.
Режим виртуальных соединений предполагает резервирование ресурса (пусть даже виртуального) на время сеанса связи. Наличие резервированного ресурса позволяет гарантировать определенное качество обслуживания и, естественно, подходит для применения в сетях передачи данных общего пользования.
В методе дейтаграмм также основанным на коммутации пакетов, виртуальное соединение не устанавливается, то есть отсутствует резервирование ресурсов и не обеспечивается гарантированное качество обслуживания. Главным достоинством метода дейтаграмм является простота механизма передачи пакетов. Этот метод положен в основу IP-протокола, а спецификация стека протокола TCP/IP, является основой сети Интернет. Процедуры транспортировки пакетов между узлами сети определяются IP – протоколом третьего (сетевого) уровня, а процедуры межконцевой области TCP – протоколом четвертого (транспортного) уровня. Целью создания IP-протокола, явилось объединения сетей передачи данных построенных на разных технологиях и операционных системах; с учетом этого был выбран способ связи без установления соединения на сетевом уровне, а именно дейтаграммный вариант коммутации пакетов.
Именно на методах пакетной передачи и коммутации построено функционирование современных высокоскоростных сетей передачи данных. Заложенная в них идея проста: информация любого типа (данные, речь, видео) представляется в виде цифровой последовательности, которая в дальнейшем делится на блоки «пакеты», снабженные всей необходимой информацией для идентификации, маршрутизации, коррекции ошибок и прочее. Подобный подход позволяет в едином информационном потоке передавать все виды информации, используя для этого различные технологии коммутации пакетов.
В 1974 году В. Серф и Р. Канн опубликовали основные принципы протокола TCP/IP. В первой половине 80-х годов был разработан основной протокол обмена информацией в сети, получивший название TCP/IP, а также модель соединения сетей между собой посредством шлюзов и маршрутизаторов.
Это в основном определило важнейшие черты современной архитектуры Интернет и вызвало наблюдаемый с середины 80-х годов взрывообразный рост сети, во многом коррелированный со стремительным распространением персональных компьютеров (ПК).
Комплект TCP/IP обеспечивает выполнение широчайшей гаммы сервисных функций:
1. С помощью сервисов эмуляции терминалов они могут выполнять приложения на удаленных компьютерах, позволяя использовать возможности больших систем для выполнения конкретных программ. TCP/IP обладает высокой степенью масштабируемости, и пользователи могут по своему усмотрению выбрать любое подмножество протоколов в качестве клиентских или серверных сервисов.
2. Другая примечательная черта TCP/IP — его «открытость»: это полностью общедоступная спецификация. Любой человек может предлагать дополнения к этой спецификации и процесс протекает абсолютно открыто. Так, многие фирмы предлагают свои платформы с уже встроенными протоколами и сервисами TCP/IP.
3. Третье важное преимущество TCP/IP состоит в том, что это набор очень надежных протоколов, в состав которого входят транспортные протоколы, эффективно работающие в глобальных сетях. Протокол NBF (и в меньшей степени IPX) предназначался для использования в локальных сетях. NBF не предусматривает маршрутизацию, т.е. пользователи, подключенные к одному сетевому кабелю, видят серверы, подключенные к другому кабелю, только в том случае, если два этих сегмента соединены мостом и образуют одну логическую сеть. В глобальных сетевых средах эта схема работает плохо. Протокол IPX — полностью маршрутизируемый, но вот более высокоуровневый NCP предусматривает явное квитирование всех передаваемых сетевых пакетов, что сильно замедляет его работу с глобальными сетевыми каналами. Ни один из этих наборов протоколов не подходит для использования в Internet.
Комплект протоколов TCP/IP с самого начала разрабатывался для соединения хост-компьютеров между собой через глобальные сети, поэтому он и маршрутизируемый, и эффективный. Эти достоинства сохраняются и в локальных сетях, что делает TCP/IP отличным вариантом и для мелко-, и для крупномасштабных сетей. Три вышеупомянутых качества (масштабируемость, открытость и надежность) делают TCP/IP привлекательным вариантом для пользователей разнородных сред. Именно поэтому TCP/IP является стержнем Internet.
На сегодняшний день, в условиях быстрого развития сетевых технологий, в модели TCP/IP стали существенными ряд недостатков, которые сделали модель не эффективной для использования в современных сетях. Все недостатки, при передаче простых данных не были существенными, но при развитии сетей и увеличения объема данных они дали о себе знать.
Основными недостатками используемой модели являются:
1. В этой модели нет четкого разграничения концепций служб, интерфейса и протокола. При разработке программного обеспечения желательно провести четкое разделение между спецификацией и реализацией, чего не делает TCP/IP. В результате модель TCP/IP не эффективна при разработке сетей, использующих новые технологии.
2. Модель TCP/IP отнюдь не является общей и довольно плохо описывает любой стек протоколов, кроме TCP/IP. Так, например, описать технологию Bluetooth с помощью модели TCP/IP совершенно невозможно.
3. Хост-сетевой уровень в действительности не является уровнем в том смысле, который обычно используется в контексте уровневых протоколов. Это скорее интерфейс между сетью и уровнями передачи данных. Различие между интерфейсом и уровнем является чрезвычайно важным, и здесь не следует быть небрежным.
4. В модели TCP/IP не различаются физический уровень и уровень передачи данных. Об этом различии даже нет упоминания. Между тем они абсолютно разные. Физический уровень должен иметь дело с характеристиками передачи информации по медному кабелю, оптическому волокну и по радио, тогда как задачей уровня передачи данных является определение начала и конца кадров и передача их с одной стороны на другую с требуемой степенью надежности. Правильная модель должна содержать их как два различных уровня. В модели TCP/IP этого нет.
5. Хотя протоколы IP и TCP были тщательно продуманы и неплохо реализованы, многие другие протоколы были созданы несколькими студентами, работавшими над ними, пока это занятие им не наскучило. Реализации этих протоколов свободно распространялись, в результате чего они получили широкое признание, глубоко укоренились, и теперь их трудно заменить на что-либо другое. Некоторые из них в настоящее время оказались серьезным препятствием на пути прогресса. Например, протокол виртуального терминала TELNET, созданный еще для механического терминала типа Teletype, работавшего с огромной скоростью 10 символов в секунду. Ему ничего не известно о графических интерфейсах пользователя и о мышках. Тем не менее сейчас, почти 30 лет спустя, он все еще широко используется.
Причины . Стремительный рост объемов трафика и изменение его структуры, необходимость обслуживания, увеличивающегося в геометрической прогрессии количества пользователей мобильными и беспроводными технологиями, формирования высокопроизводительных кластеров для обработки Больших Данных и хорошо масштабируемых виртуализированных сред для предоставления облачных сервисов — все это серьезно изменило требования к сетевым средам. Главная проблема состоит в том, что традиционные сети слишком статичны и потому не соответствуют динамике, свойственной современному рынку. Сегодня в области компьютерных сетей мир переживает смещение акцентов с аппаратного уровня на программный. Это открывает новые возможности и новые рынки для разработчиков и компаний. Одной из самых перспективных технологий, воплотившей в себе этот переход от аппаратного на программный уровень, является технология программно-конфигурируемые сети (Software Defined Networks).
В 2007 году американскими преподавателями Мартином Касадо (Martin Casado), Ником МакКеоном (Nick McKeown) из Стэндфордского университета и Скоттом Шенкером (Scott Shenker) из университета Беркли был разработан новый «язык» общения компьютерных сетей – протокол OpenFlow.

До этого архитектура сетей развивалась по методу «ласточкиного гнезда», т.е. по мере выявления проблем к стеку протоколов TCP/IP добавлялся новый протокол, который эту проблему решал. Т.е. в современных сетях функции управления и передачи данных совмещены, что делает контроль и управление очень сложными.
Архитектура SDN

Архитектура ПКС (SDN)
В архитектуре SDN можно выделить три уровня:
1. инфраструктурный уровень , предоставляющий набор сетевых устройств (коммутаторов и каналов передачи данных);
2. уровень управления , включающий в себя сетевую операционную систему, которая обеспечивает приложениям сетевые сервисы и программный интерфейс для управления сетевыми устройствами и сетью;
3. уровень сетевых приложений для гибкого и эффективного управления сетью.
Как видно из архитектуры, кроме классического управления сетью прямыми командами системного администратора к контроллеру, SDN контроллер поддерживает запуск на себе приложений управления сетью. Что из себя представляют эти приложения?
Каждое SDN приложение, по сути, являет собой интерфейс оптимизации сети под конкретное бизнес приложение (к примеру, Microsoft Lynk) и его основная роль — изменение сети в реальном времени под текущие нужды обслуживаемой программы. В случае Microsoft Lynk это может быть, к примеру, изменение QoS сети между двумя телефонными абонентами для передачи HD видеозвонка в реальном времени без задержек или создание VPN тоннеля между двумя абонентами.
Логическое представление архитектуры SDN

Логическое представление архитектуры SDN
Приложения SDN. Приложения, которые предоставляют конечным пользователям желаемые сервисы. Приложения SDN содержат ряд требований к состоянию и поведению сетевой инфраструктуры.
Контроллер SDN. Контроллер выступает единой централизованной точкой управления, который взаимодействует с уровнем приложений посредством открытого интерфейса API, а также выполняет мониторинг и управление физическими устройствами сети посредством открытого интерфейса – протокола OpenFlow. Контроллер состоит из нескольких модулей или уровней, каждый модуль отвечает за ряд необходимых функциональных возможностей.
OpenFlow является первым стандартизированным открытым интерфейсом, отвечающим за взаимодействие между уровнем управления и уровнем передачи данных. OpenFlow обеспечивает доступ, обмен информацией и доставку управляющих команд элементам сетевой инфраструктуры.
ПКС-подход, который родился после разработки протокола OpenFlow, позволяет уйти от «ручного» управления сетью, разделяет процесс управления и процесс передачи данных. В традиционных коммутаторах и маршрутизаторах эти процессы неотделимы друг от друга. Поскольку эти задачи – разные, и подходы к решению каждого должно быть – разными. Согласно концепции ПКС, вся логика управления выносится в так называемые контроллеры, которые способны отслеживать работу всей сети. В мировой ИТ-отрасли уже признано, что по силе своего влияния на современную ИТ-индустрию ПКС/SDN стоит в одном ряду с такими прорывными технологиями, как Cloud и BigData. Это одна из тех технологий, которая способна изменить ландшафт ИТ-рынка и поменять позиции традиционных ИТ-гигантов вроде Cisco, Brocade, HP, IBM. Ведущие аналитические агентства, вроде Gartner и IDC, дают рынку ПКС-решений не менее 60% роста в год при средних темпах ростах ИТ-отрасли в 10-12%.
Можно говорить о четырех основных областях применения ПКС:
1. Коммутация;
2. Контроллеры;
3. Виртуализация облачных приложений;
4. Виртуализация средств безопасности сетевых решений.
Вот ключевые преимущества внедрения ПКС в компаниях со сложной ИТ-инфраструктурой:
— Стоимость. Снижается стоимость владения компьютерными сетями за счет сокращения расходов на управление, как следствие – увеличение прибыли;
— Повышение производительности. Благодаря снятию с коммутаторов нагрузки по обработке тракта управления, ПКС позволяет этим устройствам направить все свои ресурсы на ускорение перемещения трафика);
— Реализация и тестирование новых сервисов. Программные средства ПКС позволяют администраторам добавлять новую функциональность к имеющейся сетевой архитектуре);
— Администрирование. На централизованном ПКС-контроллере сисадмин может наблюдать всю сеть в едином представлении, за счет чего повышается удобство управления, обеспечения безопасности и выполнения других задач;
— Безопасность. Поскольку ПКС позволяет администратору четко видеть все потоки трафика, ему будет легче замечать вторжения и выявлять другие проблемы. ПКС также позволяет сисадмину назначать приоритеты различным типам трафика и разрабатывать правила реагирования сети при заторах и проблемах с оборудованием;
— Облачные технологии. В облаках данные и приложения размещены на компьютерах, взаимодействующих по сети, и, по мнению сторонников ПКС, данная технология способна обеспечить требуемый облакам уровень «интеллектуальности» сетей, необходимый, в частности для оркестровки работы обширных групп коммутаторов.
Сегодня на рынке ПКС заметны две основные тенденции: активное появление перспективных стартапов и ориентация лидеров рынка ИКТ на ПКС/SDN, что выражается в открытии собственных научно-исследовательских подразделений, работающих по дан¬ной тематике, и отдельных линеек продуктов, основанных на новом подходе. ПКС также способна стать стартап-машиной в сфере сетевых технологий, которая долгое время была закрыта для прорывных технологий и новых имен.
SDN в сети Google
По оценкам экспертов, SDN (Software Defined Networks) прежде всего найдут применение в корпоративной среде, поэтому одним из центральных событий на Open Networking Summit стало выступление «царя инфраструктуры» Google Урса Хольцеля, который, в силу обостренного отношения к секретам компании, очень редко появляется на людях. Сегодня Google полностью перестроила свою глобальную сеть, адаптировав ее под OpenFlow, — известно, что эта компания сама все создает для своих нужд (хорошо известны «желтые серверы»), а теперь решила самостоятельно создавать еще и сетевое оборудование. «Строить сетевое железо», — говорит Хольцель, — несложно, вот что действительно сложно, так это писать сетевое ПО».

Сеть OpenFlow Google
Сейчас Google признана одним из ведущих ISP в мире — у компании две большие сети: одна поддерживает сервисы Search, Gmail, YouTube, а вторая связывает между собой крупнейшие ЦОД (рис. ). Первая рассчитана на равномерную нагрузку в течение всего дня, поскольку запросы распределяются по 24 часовым поясам, а нагрузка на вторую обычно имеет импульсный характер, возрастая при обмене большими объемами данных, измеряемыми петабайтами, — например, в случае выпуска новых сервисов, которые должны быть доступны синхронно по всему миру. Классический подход для решения задачи перемещения огромных массивов данных невозможен (перемещение в пространстве физических контейнеров из дисков), и выход был найден в OpenFlow.
В чем же в данном случае преимущество SDN? Коммутация пакетов, как она реализована в IP, гарантирует доставку при любых условиях — что бы ни произошло, будет найдена топология, пройдя по которой, пакет дойдет до получателя, но за это приходится платить избыточностью. Централизованное управление позволяет проложить канал, по которому пакеты пойдут напрямую, что на порядки производительнее. Сбой в передаче возможен, но управляющая программа его обнаружит и исправит, однако не так оперативно, как в первом случае. Хольцель пояснил, что в Google давно искали такого рода решение, и тут появились SDN. Google начала тестировать коды OpenFlow, полученные от проекта Clean Slate в 2009 году, еще до официальной публикации протокола. Компания построила коммутаторы для сети G-Scale с 128 портами, работающими на скорости 10 Гбит/с, используя для этого стандартные чипы. Сам коммутатор Google OpenFlow чрезвычайно прост — на нем работает лишь агент OpenFlow, использующий протокол маршрутизации промежуточных систем IS-IS (Intermediate System To Intermediate System) и основной протокол пограничного шлюза BGP (Border Gateway Protocol). В результате удалось на 100% использовать пропускную способность каналов и решить задачу перемещения больших объемов данных по собственным сетям.
OpenFlow, SDN и виртуализация
На форуме ONF о взаимосвязи OpenFlow и SDN с виртуализацией говорил технический руководитель компании Nicira Мартин Касадо, один из основных разработчиков OpenFlow. Он подчеркнул, что сами по себе OpenFlow и SDN не обеспечивают виртуализации сетей — эту функцию реализуют технологии, лежащие поверх SDN. Виртуализация сетей повышает безопасность и изолированность, упрощает операции, связанные с управлением, но она не зависит от того, построена ли сеть с использованием OpenFlow, SDN или других технологий. Все, на что способна сеть, работающая по протоколу OpenFlow, ограничено управлением коммутаторами и поддержкой ПО, работающего на этих коммутаторах, но от этого сеть не становится независимой от топологии. «SDN есть не что иное, как набор средств, а виртуализация сети — это конкретное решение, использующее в том числе и этот набор. Виртуализация решает множество проблем, например, отделяет политику безопасности от физической топологии, поддерживает мобильность, но построена ли сеть с использованием SDN или нет, с решением не связано. Вопрос в другом, будет ли решение так же масштабируемым, если вы не используете SDN», — пояснил Касадо. С его мнением был согласен на форуме и представитель компании HP, отметивший, что OpenFlow и SDN обеспечивают возможность программирования сети, а приложения, которые служат для виртуализации или для каких-то иных целей, улучшающих свойства сети, например, для поддержки BYOD, могут использовать предоставляемую возможность. Тот факт, что сеть можно программировать, позволяет придавать ей нужные качества, настраивать на нужные приложения, в том числе для работы с Большими Данными. Пока в области виртуализации сетей на рынке представлены два основных решения: Virtual Extensible LAN (VXLAN), поддерживаемое компаниями Cisco, VMware и Arista, и Network Virtualization Generic Routing and Encapsulation (NVGRE), поддерживаемое Microsoft, Dell и Intel.
Технология виртуализации сетевых сервисов (NFV) позволяет программно создавать такие сервисы, которые сейчас доступны только в виде аппаратных решений. Виртуализация сетевых функций позволяет устанавливать сервисы там тогда, тогда и в том количестве, которое востребовано сейчас и в данном месте.
NFV позволяет устанавливать сервисы:
1. В любом месте (там, где надо);
2. В любое время (тогда, когда надо);
3. В любом месте (столько, сколько необходимо).
NFV был создан с фокусом на сервис – провайдером, со знанием особенности работы провайдеров услуг и их наиболее острых проблем.
SDN и TCP/IP
Централизованное управление в ТФОП – архитектура телефонной сети, которая подчиняется нумерации. Устанавливая соединение, телефонный коммутатор принимает решение о маршрутизации звонка по номеру конечного абонента. Однако технологии управления каналами постепенно были вытеснены IP — спецификации мобильных сетей третьего и четвертого поколений уже полностью являются сетями коммутации пакетов. Тем не менее идеология сетей с коммутацией каналов вновь возродилась в SDN, решающих проблему оптимизации передачи большого объема данных.
Как известно, изначально IP разрабатывался для обеспечения работы сети даже в условиях многочисленных разрушений. Поэтому все передаваемые данные в IP делятся на пакеты, каждый из которых может быть послан по своему независимому маршруту, причем маршрут заранее не определен, а каждый узел принимает независимое решение о том, куда направлять пакет, руководствуясь только IP-адресом и таблицей маршрутизации, учитывающей состояние каналов связи, наличие соглашений с провайдерами и т. п. Однако обеспеченная такой ценой надежность передачи данных нередко приводит к неэффективному расходованию ресурсов: простаиванию маршрутизаторов и каналов связи и постоянному пересчету маршрута независимо для каждого пакета. Современные каналы связи достаточно надежны и позволяют передавать данные на таких скоростях, что процессоры уже не справляются с задачей маршрутизации, однако совсем не обязательно каждый раз вычислять один и тот же маршрут для каждого пакета независимо. Можно просчитать маршрут только один раз для первого пакета, а потом пользоваться сохраненными результатами, что и делают современные IP-коммутаторы.
В такой оптимизации можно пойти еще дальше — отказаться от независимого вычисления маршрутов на каждом устройстве по пути следования пакетов и жестко определять маршрут сразу для всех устройств в едином центре управления. Именно это и лежит в основе SDN — отделить процесс маршрутизации от пересылки данных. Формированием маршрута занимается не каждое устройство в отдельности, а специально выделенный для этого сетевой контроллер, передающий по протоколу OpenFlow коммутаторам результат вычисления маршрута, по которому они в дальнейшем и посылают все пакеты для данного получателя. Это позволяет снять с коммутаторов нагрузку по вычислению маршрутов, причем даже для первого пакета, сделав его простым и производительным. Однако это фактически является возвратом к технологии управления каналами, которая была реализована в телефонии.
Связано это в том числе и с безопасностью — вмешательство в центральный коммутатор телефонной сети или разрыв межстанционного соединения приводит к выходу из строя целого сегмента. В то же время в IP, при наличии нескольких каналов, поврежденный участок обходится автоматически и связь между абонентами сохраняется и иногда даже не прерывается. Проблема неожиданного разрыва по тем или иным причинам сетевых соединений имеется и в SDN — если какой-то канал на пути следования потока вышел из строя, то центральный контроллер этого сразу не заметит, что может привести к потере данных. В то же время возникла потребность в передаче больших объемов данных именно по фиксированному маршруту, причем в рамках собственной сети оператора, которая полностью контролируется его специалистами. Это и дало возможность отказаться от избыточности в пользу увеличения скорости.
Однако не стоит забывать, что в Интернете выросла угроза постороннего вмешательства в работу сети, и похоже, что у SDN устойчивость к внешним воздействиям будет хуже, чем у классических маршрутизаторов. Кроме того, SDN существенно отличаются от мультисервисных сетей, поскольку допускают конфигурирование самими клиентами, которые потенциально могут теперь вывести из строя всю SDN неправильным изменением конфигурации.
Целенаправленные атаки способны нарушить работу программного контроллера SDN, а поскольку подсистема управления вынесена вовне, то именно она становится самым уязвимым местом всей системы. Если раньше каждый пакет маршрутизировался отдельно и не было единого центра управления, который можно было бы легко атаковать, то сейчас вывод из строя контроллера нарушит работоспособность всей сети.
Объектов для целенаправленной атаки в случае SDN стало больше, чем для классической IP-сети: контроллер, каналы связи между контроллером и коммутаторами, сами коммутаторы и каналы связи для передачи данных. Протокол IP ориентирован на то, чтобы маршрутизаторы самостоятельно следили за загрузкой и работоспособностью связанных с устройством каналов, а в SDN за состоянием сети следит контроллер, получающий данные о выходе из строя каналов и их загруженности «со стороны», то есть имеется задержка в получении информации и принятии решения. Это не способствует увеличению надежности.
Кроме того, сам протокол управления сетью может оказаться опасным, поскольку не предполагает «интеллекта» у коммутатора, поэтому передача нескольких команд на устройства, уже поддерживающие OpenFlow, может нарушить работоспособность сети или конкретного приложения.
Еще одной проблемой SDN являются приложения, работающие на контроллере и позволяющие перестроить сеть под требования отдельного приложения или системы управления виртуализацией. На данный момент открыт вопрос о том, как эти приложения в режиме реального времени будут конкурировать за сетевые ресурсы — разрабатывать такие сетевые программы достаточно сложно, и есть сомнения в том, что пользователи облачных решений будут делать это оптимально. А значит, высока вероятность того, что в определенный момент какое-то приложение монополизирует сетевые ресурсы, фактически прекратив работу всех остальных приложений.
Для надежной работы программно-конфигурируемых сетей нужно обеспечить защиту их главного элемента — контроллера, выделить его в отдельный сегмент, доступ к которому извне ограничен. Не исключено, что для защиты SDN будут разработаны специальные продукты, отражающие атаки на центральный контроллер, но не замедляющие передачу данных. Не стоит пренебрегать системами резервирования контроллеров, возможно, с разнесением реплик в независимые сегменты сети.
Следует отметить, что само программное обеспечение для управления SDN должно содержать компоненты, способные защитить от атак, имеющих целью несанкционированное использование ресурсов: монополизацию сети отдельными приложениями, постороннее вмешательство и др. Поэтому при выборе решения для построения SDN стоит проверить наличие в ней функций безопасного управления. Также в систему управления должны быть встроены элементы резервирования с максимально быстрым переключением системы на использование резервных ресурсов для самого контроллера и для каналов связи, которыми он управляет. При построении SDN стоит предусмотреть максимальное число дублирующих каналов как для передачи данных, так и для управляющих команд от контроллера. Причем на коммутаторах сети нужно допустить получение команд только строго с фиксированного набора IP-адресов, на которых могут быть расположены контроллеры, чтобы злоумышленник не мог извне подавать команды на изменение маршрута потока.
Список областей, где сегодня еще не стоит использовать SDN, достаточно велик, но, возможно, со временем технология будет усовершенствована и для нее будут разработаны надежные системы управления. Вместе с тем следует отметить, что владельцы ЦОД сами обеспечивают защиту вычислительной архитектуры и целостность SDN, а программный контроллер, управляющий сетью, является частью более общей управляющей системы всего ЦОД. Проблемы могут возникнуть в случае, когда операторы ЦОД не будут заботиться о безопасности и позволят пользователям со своих виртуальных машин получить доступ к управлению внутренней сетью и хранением.
Список литературы
1. Р.Х. Джураев, Б.М. Умирзаков “Маълумот узатиш тармоқлари: кеча, бугун, эртага (1 — қисм)”. – INFOCOM.UZ № 4, 2017 йил, 62 б.
2. Р. Смелянский. Программно-конфигурируемые сети [Электронный ресурс] / Смелянский Р. //Открытые системы Электрон. дан. – 2012.
3. Н.Ф. Бахарева, Ю. А. Ушаков, М. В. Ушакова, А.Е. Шухман //основы программно-конфигурируемых сетей // Самара 2015
4. Организация инфраструктуры облачных вычислений на основе sdn сети // Алексей Анатольевич Ефименко, Сергей Витальевич Федосеев, // Прикладная информатика №5, 2013
5. Создание прототипа отечественной ПКС платформы управления сетевыми ресурсами и потоками с помощью сетевой операционной системы (СОС) на основе анализа и оценки существующих сетевых систем для ПКС сетей и выбор одной из них для последующего развития по критериям производительности, масштабируемости, надежности, безопасности. // Отчет о научно-исследовательской работе Москва 2013 // Р.Л.Смелянский
Авторы: Р.Х. Джураев, Б.М. Умирзаков, C.Р. Ботиров, Ташкентский университет информационных технологий имени Мухаммада ал-Хоразмий, г. Ташкент

Top News