Вы еще не занимаетесь перемещением своего центра обработки данных в программно-определяемую сеть, Software-Defined Network (SDN)? Эта аббревиатура из трех букв употребляется все чаще по мере того, как начинающие и опытные технические компании бросают вызов известным поставщикам сетевых технологий, которые, в свою очередь, развивают свои продукты и покупают многие начинающие компании.
Что отличает использование термина SDN от простого маркетингового хода? Программно-определяемая сеть представляет собой сдвиг парадигмы. В результате внедрения SDN сетевые инженеры переходят от управления сетевым оборудованием как набором слабо связанных между собой отдельных устройств к управлению единой, гибкой виртуальной сущностью, которая в идеале уменьшает затраты на управление и открывает новые возможности. Скромное искусство организации сетей наконец выросло до концептуальных и практических высот, достигнутых в деле управления серверами, хранилищами данных и приложениями.
SDN обеспечивает такие возможности, как централизованная настройка топологии; использование типового сетевого оборудования; согласованные политики безопасности высокого уровня; продуманное сочетание со всеми формами развертывания современных приложений, при которых трафик между серверами и контейнерами может многократно превосходить объем входящих и исходящих из сети данных.
В центрах обработки данных быстрое снижение стоимости оборудования, в сочетании с растущим применением виртуализации и контейнеризации, ведет к увеличению числа адресуемых устройств и приложений. Если вы располагаете сотнями или тысячами виртуальных локальных сетей или ежедневно удовлетворяете потребности разработчиков в связях с контейнерами, то вам очень хорошо знакома эта проблема.
Увеличение количества устройств и серверов приводит к пропорциональному росту числа сетевых коммутаторов, и собственные, закрытые, ориентированные на аппаратные средства подходы к организации сетей не успевают за тенденциями в сфере управления.
Изготовители сетевого оборудования добились резкого увеличения информационной емкости и пропускной способности. Но для традиционных устройств слишком велика роль тонких настроек, задаваемых отдельным устройствам, даже если эти настройки выполняются с помощью сценариев или внешнего интерфейса сетевого администрирования. Такие системы проектируются для высокой производительности, но им не хватает динамизма: это голубые киты, а не дельфины ИТ-океана.
Каждое изменение в настройках — потенциальная возможность нарушить какой-либо элемент сети. Небольшие изменения требуют заблаговременного планирования и внимания к деталям. Для планирования более крупных изменений, таких как развертывание приложения нового типа или перемещение серверов, совместно расположенных в центре обработки данных, могут потребоваться недели. Это рискованная операция, которая не нравится ни одному сетевому администратору, а руководители ИТ-подразделений требуют идеальных и быстрых решений.
SDN помогут снизить затраты благодаря использованию стандартизованного оборудования или сокращению численности персонала. Но главным преимуществом, вероятно, будет эффективность бизнеса. Сетевые администраторы могут перейти от постоянной борьбы с мелкими проблемами, которой неизменно сопутствует значительное отставание в обработке запросов, к такой же динамичной работе, как у групп разработчиков. Это позволяет в большей степени сосредоточиться на безопасности, совершенствовании сети и фундаментальных задачах бизнеса.
В программно-определяемых сетях наконец-то удается получить преимущества, уже реализованные в прочих сферах современных вычислений.
Определение программно-определяемой сети
Сетевое оборудование остается одним из последних крупных невиртуализованных компонентов ИТ, в котором существует однозначное соответствие между функцией и аппаратными средствами устройства. Администраторы, по сути, управляют каждым устройством как одним объектом, даже при их объединении в консоли управления.
Широко применяются интерфейсы командной строки и настройки SNMP. Один специалист отметил, что администратор, настраивавший фирменный маршрутизатор в 1998 году, сможет использовать практически те же методы и команды сегодня. В наше время никому не придет в голову подключить отдельный, специально настроенный и управляемый стоечный сервер для единственного нового приложения. Но сети по-прежнему расширяются путем добавления физических коммутаторов с уникальными настройками.
Абстракция и виртуализация реализованы в сетях SDN через выделение функциональных уровней, позволяющих администратору управлять всем оборудованием маршрутизации и коммутации как единым целым и, в сущности, создавать список потребностей вместо того, чтобы строить таблицы для каждого устройства. Эти таблицы по-прежнему формируются, но автоматически и динамически.
В результате достигается сразу несколько преимуществ. Во-первых, протоколы второго уровня для локальной сети проектировались в расчете на гораздо меньшее количество устройств, нежели существует сегодня в сетях, обслуживающих множество приложений, и даже в корпоративных сетях. Виртуальные серверы, контейнеры, устройства, частные и общедоступные «облака» и другие компоненты заметно перевесили возможности порой «лоскутных» решений, таких как протокол Spanning Tree Protocol и маркировка виртуальной локальной сети.
Во-вторых, протоколам для глобальных сетей, в частности IP-сетей, свойственно изначальное предположение о недостаточной надежности. Они проектировались для работы с устройствами, внезапно исчезающими из потенциальных путей, часто и непредсказуемо меняющимися топологиями и заторами в каналах связи. Поскольку они разработаны в расчете на устойчивость, это качество присуще межсоединениям от обращенных к Интернету приложений и сайтов, но виртуальные и физические центры обработки данных обеспечивают высокий уровень управления и стабильности на протяжении длительного времени.
Трафик «восток-запад» — пакеты и кадры, которые пересылаются внутри центра обработки данных, — требует иного подхода, нежели трафик «север-юг», который обычно пересылается в Интернет и из него. Традиционные протоколы, спроектированные с акцентом на устойчивость, понижают эффективность и не обеспечивают одновременно необходимую гибкость.
Сети SDN позволяют обойти некоторые из наиболее сложных проблем управления трафиком как уровня 2, так и уровня 3 (а иногда полезны и на более высоких уровнях). Вместо того чтобы взаимодействовать с разнообразными протоколами для обнаружения, межсоединения и обновлений, SDN управляет сетью как единой сущностью, требующей очень малого количества действий на уровне протокола. Политики и маршрутизация применяются на верхнем виртуальном уровне и отправляют необходимые инструкции аппаратным устройствам.
Вместо того чтобы использовать отдельные виды настроек для создания маршрутов для IP-данных, группирования устройств в виртуальные локальные сети и других задач, в SDN создается так называемый поток (flow). Поток определяет набор конечных точек (одну или несколько на каждом конце) для перемещения данных в одном направлении. Поток может соединять два IP-адреса или набор портов, две конечные точки виртуальной локальной сети или другие сетевые конструкции. В сущности, каждое устройство, поддерживающее поток, может казаться функционирующим как традиционный коммутатор, но действия по настройке заметно отличаются.
Дело в том, что с потоком сочетается абстракция сетевой функции. Вместо того чтобы сделать так, чтобы каждое устройство, которое оценивает и приводит в исполнение намерения, обладая мощной функциональностью, управляло процессом маршрутизации и коммутации сверху донизу стека, в сети SDN все функции коммутатора разделены на три плоскости:
- Плоскость приложения (application plane), на которой администраторы определяют поведение, например сопоставляют устройства в виртуальной локальной сети. Приложения создают абстрагированные потоки с конечными точками для передачи на плоскость управления. Приложению не обязательно знать подробности об отдельных устройствах или о том, как их программировать. SDN может иметь много разных приложений, которые обмениваются данными со следующим нижним уровнем, включая автоматизированные и самообслуживаемые потоки, выполняющиеся без участия администратора.
- Плоскость управления (control plane) программирует абстрагированные потоки в инструкции для всех разнообразных управляемых устройств и переносит эти элементы в таблицы потоков на устройствах с использованием стандартных API-интерфейсов. Сами API-интерфейсы представляют собой вид абстракции, хотя из-за различий версий между стандартами плоскости управления, возможно, придется настроить инструкции, но это автоматизированный процесс.
- Плоскость данных (forwarding plane или data plane), на которой элементы таблицы потоков используются для анализа пакетов и определения метода их обработки, например пересылки пакета в надлежащий интерфейс, передачи его на плоскость управления для обработки, если он не соответствует правилу, или его удаления на основании правил блокировки или политик качества обслуживания (QoS).
В традиционном коммутаторе логика управления реализована в устройстве, и, чтобы изменить пересылку, эта логика должна быть обновлена. В сети SDN центральный контроллер управляет всей логикой и распространяет ее на любой API-интерфейс, а коммутатору затем требуется лишь управлять пересылкой в соответствии с заданными правилами.
В результате централизации диспетчеру сети не требуется регулировать сложные проблемы. Вместо этого формируется план в программном обеспечении, который исполняется. Как отметил Амит Гупта, вице-президент по управлению продуктами компании Tigera, которая специализируется на безопасности, вся сетевая конструкция «подготавливается, автоматизируется и управляется программно».
Некоторые контроллеры SDN можно преобразовать в виртуальную форму и объединить в кластеры, чтобы не перегрузить один сервер задачами управления большой сетью, а также для избыточности и «горячих» переключений. Этот компонент управления SDN по-прежнему развивается, его различные варианты соперничают на рынке и в сообществах открытого исходного кода.
Вследствие виртуализации и централизации новые сетевые функции легко протестировать, а затем развернуть в масштабах сети целиком через контроллер, что позволяет программно изолировать и сегментировать сетевой трафик. В этом состоит значительное отличие от использования физически изолированной тестовой сети с последующей установкой обновлений программного обеспечения и встроенного программного обеспечения на каждом сетевом коммутаторе. Некоторые компании могут даже самостоятельно разработать программное обеспечение для собственных сетевых приложений, выполняемых на контроллерах. Это типично для крупных поставщиков «облака».
Переход к абстрагированию сетевого оборудования — знакомое явление для тех, кто следил за эволюцией крупномасштабных развертываний Wi-Fi десять лет тому назад. По мере того как технология Wi-Fi стала незаменимой для предприятия, а смартфоны и другие мобильные устройства стали поставляться массово, узлы Wi-Fi корпоративного класса становились еще более интеллектуальными и дорогостоящими, а управлять ими стало сложнее. В конечном итоге контроль и управление переместились в централизованные контроллеры WLAN, которые работают с «тонкими» узлами Wi-Fi, функционирующими как отдельно стоящие сетевые интерфейсы.
Абстракция SDN по касательной пересекается с двумя другими технологиями виртуализации, все еще находящимися в стадии разработки: виртуального коммутатора, который выполняется программно, как любая другая виртуальная машина, и виртуализации сетевых функций (NFV), которая заменяет специализированные аппаратные устройства, используемые для брандмауэров, глубокого анализа пакетов и многих служб, применяемых в сотовых сетях. Благодаря SDN, виртуальным коммутаторам и NFV удается не только виртуализовать соответствующие функции на том же оборудовании, но и получить преимущества наращивания и сокращения ресурсов для любой функции, как и в случае с виртуализованными серверами и хранилищами. Еще предстоит проделать большую работу по усовершенствованию технологии; по-прежнему не ясно, пришло ли время, когда NFV сможет сравниться по эффективности со специализированными аппаратными средствами, но предстоит конвергенция. Сегодня сети SDN для центров обработки данных предприятия явно отличаются от корпоративных локальных сетей и WAN, где технологии SD WAN внедряются более медленно. Преимущество абстрагирования функций остается столь же полезным в этом контексте, но существуют различные требования при управлении учетными записями пользователей мобильных устройств и удаленных пользователей, офисами и частными «облаками» с объединением их всех в единую ткань.
«Компаниям, в которых сочетаются собственные и арендованные центры обработки данных, частные и общедоступные «облака», сети SDN не обеспечивают полной интеграции политики и сегментации сети, хотя это ключевой аспект, над которым ведется работа», — отмечает Брэд Кейсмор, вице-президент по исследованиям сетей центров обработки данных компании IDC. Поставщики сетей стараются охватить Amazon Web Services, Azure и частные «облака», заключив их в сущность, управляемую в рамках подхода единой виртуальной сети SDN.
Это описание сетей SDN, конечно, идеализировано. Понятия потока и полного абстрагирования родились из научных изысканий и выросли в проект с открытым исходным кодом. Более серьезные изготовители оборудования для центров обработки данных проявляют меньше энтузиазма в отношении SDN, хотя все, похоже, пришли к согласию в отношении виртуализации. Например, серия Cisco Nexus 9000 привлекательна в основном благодаря аппаратным средствам и сохраняет некоторые функции управления в сети, но все же получает важные преимущества от абстракции и централизованного управления.
Решительные конкуренты, такие как компания со стажем HPE и новая Big Switch (выросшая из первоначальных исследований потоков в Стэнфордском университете), в гораздо большей степени склоняются к изначальному, полностью абстрагированному подходу, однако между всеми этими компаниями существуют различия в соотношении типового и самостоятельно спроектированного оборудования. На рынке SDN было много начинающих компаний, но большинство из них было приобретено компаниями Cisco, HPE, VMware и Juniper.
Шеймус Макджилликадди, старший аналитик компании Enterprise Management Associates, считает, что, хотя не все поставщики идут одной дорогой, «все они обращаются к абстрагированию, пытаясь снизить сложность, чтобы сеть стала более динамичной, более автоматизированной и менее подверженной ошибкам, меньше зависела от ручных команд, подаваемых в ответ на изменения. «Цель — добиться, чтобы сеть меньше препятствовала изменениям», — говорит он.
Познакомившись со структурой, рассмотрим несколько преимуществ сетей SDN.
Согласованная, детализированная, строгая политика безопасности сети
В безопасности сетей обычно преобладал подход «север-юг»: поиск внешних угроз и размещение основных защитных мер по периметру. Распространенная точка зрения, что направление «восток-запад» менее опасно, устарела, но подобное отношение все еще сохраняется во многих моделях безопасности центров обработки данных.
Как известно всем в ИТ-отрасли, программы использования уязвимостей резко изменились. Широко используются направленный фишинг и другие методы атаки на пользователей сети, чтобы затем с их помощью перенестись в пространство «восток-запад», будь то в локальной сети или центре обработки данных.
Попытки противодействовать растущим угрозам в центре обработки данных с использованием традиционного подхода бесперспективны. Амит Гупта из компании Tigera отмечает: «Если нужно направить весь трафик через сетевые устройства на уровне 2, то за изменениями вам не успеть».
SDN в противодействии вредоносным программам и обнаружении несанкционированного доступа сама по себе не поможет. В потоке SDN только заголовки пакетов анализируются и перезаписываются, как необходимо для пересылки. Но централизованная сетевая политика имеет огромные преимущества, в том числе шунтирование пакетов, не соответствующих правилам для автоматизированной и ручной проверки.
В сети SDN легко создать среду на основе белого, а не черного списка — модель с нулевым доверием. По умолчанию только определенные конечные точки и маршруты могут нести трафик и только определенные его формы. Поскольку вы не составляете списки управления доступом (ACL), которые приходится настраивать почти для каждого устройства, и не используете сценарии, чтобы упростить их настройку, вы можете подготовить широкие и детализированные политики, программно реализуемые плоскостью управления.
Такой подход практически неприменим в традиционных сетях из-за количества элементов, необходимых для подключения микрослужб для приложения, а также из-за работы, связанной с внедрением любых изменений. И если происходят изменения IP-адресов или уровня 2, то подключения будут нарушены или потребуется массовое планирование и миграция. Из-за ограничений настройки традиционной сети возможна привязка к определенному оборудованию или стойкам, даже если в компании применяются полная виртуализация и контейнеризация.
Сети SDN обеспечивают политику безопасности на высоком уровне, определяющую взаимодействие приложений или контейнеров, которое может быть привязано к системам развертывания и оркестровки. Разработчики могут уверенно продвигать тестовые и рабочие сборки, зная, что за ними последуют изменения потоков.
Вам по-прежнему потребуются брандмауэры, но централизованное управление маршрутизацией и коммутацией — хорошее средство для блокировки нежелательного трафика по умолчанию. Когда рабочим нагрузкам приходится обмениваться данными только с рабочими нагрузками, уменьшается количество точек, пригодных для проникновения взломщика.
Последнее преимущество заключается в том, что сети SDN обеспечивают видимость рабочих нагрузок в сети, а не просто узлов или виртуальных машин. Поэтому сторонние программы, отслеживающие угрозы и закономерности трафика, со временем позволяют получить полную картину, даже при изменениях узлов виртуальных машин и IP-адресов. В более традиционной сети анализ данных за прошедшие дни или месяцы может оказаться бесполезным из-за таких типичных миграций.
Сокращение внутренних направлений атаки
Может показаться, что контроллер SDN является единой точкой отказа и мишенью для атак, способных вывести из строя даже несколько центров обработки данных.
Однако, поскольку SDN абстрагирует функцию, контроллер не вовлечен полностью в повседневную активность сети — пересылку кадров и пакетов. В результате любой простой контроллера обычно приводит к тому, что структура сети остается статичной до тех пор, пока контроллер не вернется в строй.
Для защиты контроллера можно использовать способы, которые неприменимы к тысячам индивидуальных коммутаторов, отчасти потому, что последние должны быть открыты для обработки трафика со всех направлений, даже если блокируют или отбрасывают его после анализа. Элементы управления доступом и мониторинга вторжений для компонента контроллера можно перевести в самый строгий режим.
Отдельные коммутаторы более не имеют функции управления в полностью абстрагированной SDN и располагают сокращенными функциями управления в других сетях, поэтому зачастую невозможно запустить атаку через логику управления коммутаторов.
Задача взломщиков еще более затрудняется в сетях, где сочетаются SDN и виртуальные коммутаторы. Скотт Лоу, инженер по эксплуатации компании Heptio, специализирующейся на Kubernetes, замечает: «Злоумышленник порой даже не знает, что здесь можно атаковать».
Меньше затрат на управление при большем количестве виртуальных локальных сетей
В некоторых компаниях управление виртуальными локальными сетями доставляет много хлопот, поскольку связано с координацией программного обеспечения на грудах оборудования. С увеличением числа решений, ориентированных на приложения, и центров обработки данных резко растет количество виртуальных локальных сетей, которые приходится организовывать и обслуживать сетевому инженеру.
Кейсмор из аналитической фирмы IDC рассказал, что в ходе опроса, проведенного в конце 2017 года, компании попросили указать несколько основных мотивов для внедрения сетей SDN в своих центрах обработки данных. Около 30% респондентов выбрали ответ «Разрастание и сложность локальных сетей». Так что вы не одиноки, если попали в такую же ситуацию.
Виртуальные локальные сети управляются с помощью тегов, обрабатываемых на уровне коммутации. Для этого на коммутаторы необходимо возложить функции управления, иногда уникально определяемые для каждого устройства. В сетях с тысячами виртуальных локальных сетей могут потребоваться высокоуровневые коммутаторы для управления трафиком, который в противном случае было бы проще обрабатывать с помощью менее дорогостоящего типового оборудования.
SDN формирует соединения между конечными точками и в значительной мере устраняет необходимость в виртуальных локальных сетях на основе коммутаторов благодаря функционированию на более высоком уровне, на котором также достигается эффективная изоляция и гибкость. На уровне приложений SDN инженер определяет сетевые сегменты, аналогичные виртуальной локальной сети, или же эту работу можно автоматизировать в рамках процесса построения и развертывания контейнеров. Лоу из компании Heptio объяснил, что сети нуждаются в «логической сегментации независимо от физической сегментации», и именно это позволяет сделать SDN.
Практически не существует предела числу виртуальных сетей, которыми может управлять SDN, поскольку устраняется зависимость от аппаратной коммутации.
Не меньше сотрудников, но больше гибкости
Повышение эффективности управления сетью может означать сокращение штатов и выполнение большего объема работ при меньшей численности персонала. Но чаще компания имеет оптимальный штат сотрудников, которые постоянно заняты устранением неполадок и никогда не успевают за изменениями, вносимыми разработчиками приложений.
В компаниях, где применяются контейнеры, новые сборки могут появляться многократно в течение дня.
«Сегодня сетевые специалисты в роли догоняющих: им приходится иметь дело со многими повседневными задачами при расширении, свертывании или изменении рабочих нагрузок», — комментирует Скотт Лоу.
Сети SDN помогут синхронизировать деятельность сетевых инженеров и разработчиков приложений и укрепят связи между этими обычно раздельными профессиональными сферами. Инженеры могут даже войти в группу разработки, а разработчики, в свою очередь, привнести дополнительный опыт работы с виртуальными и ориентированными на приложения, а не устройства сетями. На самом деле для эффективных вычислений на основе гипервизора требуется более мощная виртуальная сеть, нежели та, которую можно получить простым добавлением виртуальных локальных сетей, и продукты SDN появились отчасти для решения этой задачи.
Макджилликадди из Enterprise Management Associates говорит, что сетевые инженеры в среде SDN непременно поднимутся по «концептуальной лестнице» и будут проводить больше времени, обсуждая инфраструктуру, сетевые намерения и бизнес-цели, которые затем найдут отражение в сетевой архитектуре.
Возможно, для этого потребуется сдвиг общей парадигмы по мере перехода сетевых специалистов от SNMB, интерфейса командной строки и частных интерфейсов управления к составлению сценариев Python и взаимодействию с разработчиками приложений и остальными подразделениями компании, чтобы интегрировать службы поддержки, управление обслуживанием и другие инструменты на прикладном уровне SDN.
Гупта из компании Tigera заключает: «Выигрыш не в сокращении персонала. Он в быстроте выпуска приложений, необходимых вашей компании и пользователям».
Вы готовы к SDN?
Не все компании нуждаются в сетях SDN. Они больше всего подходят в тех случаях, когда сложность и накладные расходы сети уже достигли уровня, при котором увеличение численности персонала не помогло и наблюдается отставание от нужд разработчиков или сетевые специалисты работают гораздо больше, чем положено. Руководству компании, которая ощущает ограничения в бизнесе из-за негибкой организации сети, или неспособна реализовать новые инициативы по той же причине, следует подумать об SDN.
- Начните с оценки своих целей: какие нужды разработки, производства и сетей не удовлетворены и можно ли решить эти задачи с помощью SDN?
- Оцените, обучены ли сетевые специалисты подходу на основе SDN. Возможно, потребуются курсы или предварительное обучение, чтобы привить им необходимые навыки.
- Загляните на несколько шагов вперед, чтобы уяснить направление движения. Если вы еще не используете контейнеры или Kubernetes, намерены ли вы переходить на них? Будет ли у вас «мультиоблачная» инфраструктура в будущем, если ее нет в настоящем?
- Определите финансовые цели. Стремитесь ли вы сократить капиталовложения в будущем, уменьшить эксплуатационные расходы или то и другое?
- Вдумчиво ведите переговоры с поставщиками на стадиях запросов, чтобы не попасть в зависимость от их версии SDN. Помните, что существуют конкурирующие модели с одинаковыми целями.
Возможно, вы придете в итоге к той платформе, которую используете сейчас, и это не будет неудачей: некоторые изготовители придумали, как упростить коммутацию для потребителей, и это преимущество.
Выполнение миграции
Не обязательно целиком переходить на SDN, меняя традиционную сеть на новую. В некоторых случаях компания уже располагает инфраструктурой коммутации, способной работать в традиционном управляемом режиме или через API-интерфейсы в стиле SDN, и может перейти в последний режим, добавив уровень контроллера. Редко бывает, чтобы какой-нибудь компании переход удался столь легко, в основном потому, что большинство компаний располагает разнородным сетевым оборудованием, приобретенным в разное время в рамках последовательно выполняемых проектов.
Большинство компаний проходит через этап реконструкции, на котором контроллер SDN используется для управления частью сети, а оставшаяся часть управляется в традиционной конфигурации. Возможно, вы просто установите новые коммутаторы в стойке с поддержкой SDN и выполните миграцию на месте, так что отдельные виртуальные машины всей стойки или кластера стоек заменяются на фактически идентичные средства коммутации и маршрутизации — метод выдергивания скатерти из-под посуды. Сеть может оставаться в состоянии реконструкции в течение неопределенно долгого времени, особенно если обслуживание старого оборудования обходится недорого.
Другие могут предпочесть новую сеть со свежими или перенесенными серверами и архитектурой, в которой снизу доверху реализован подход SDN к оборудованию и программному обеспечению. После согласования всех элементов и подключения к сети выполняется миграция служб. Такой метод начала с нуля снижает сложность, поскольку исключается возможность выхода из строя старых систем.
Если, на ваш взгляд, миграция слишком трудна, прочитайте отчет Google о ее переходе. У этой компании огромная инфраструктура и бездонные ресурсы. Для перехода потребовались время, собственные разработки и глубокое тестирование. Процесс шел постепенно, с преобразованием наложений и протоколов прежних версий. Компания даже отмечала, что ей пришлось заменить имевшуюся сеть менее зрелой, а затем совершенствовать ее, доводя до прежнего уровня функциональности при всех преимуществах лучшего управления. Любая предстоящая вам миграция будет, вероятно, гораздо проще и менее масштабна.
Будущее виртуально — привыкайте
Независимо от того, насколько вы готовы к абстрагированию сетевых функций, именно такое будущее ждет любые сети. Это неизбежный эволюционный процесс, в который в той или иной степени вовлечена любая компания, работающая с сетями. Виртуализация и абстрагирование проникли во все аспекты вычислений, и сетевые технологии не станут исключением.