Мы продолжаем публиковать материалы с форума «Совместная безопасность облачных решений для бизнеса», который мы провели совместно с «Лабораторией Касперского» и HUAWEI 31 мая в Москве. Представляем доклад Сергея Аксенова из компании HUAWEI «Технологические тенденции и актуальные решения SDN для ЦОД»
Коллеги, добрый день. Меня зовут Сергей Аксенов, я являюсь представителем компании Huawei и, соответственно, в Huawei я отвечаю за развитие направления сетевых решений.
Моя сегодняшняя тема относится к сетям передачи данных, к сетевой инфраструктуре. И тот новый тренд, который зародился уже некоторое время назад, который наконец-то начинает реализовываться на реальной инфраструктуре заказчика это, собственно, SDN, программно-определяемая инфраструктура.
На самом деле сегодняшнее мероприятие всецело посвящено облачным технологиям и если бы мы даже посмотрели на те конференции, которые проводились даже два-три года назад, то сеть передачи данных, именно для облаков, рассматривалась просто как такой вспомогательный элемент, как некая подложка, но во главе угла всегда ставили платформы виртуализации, облачные технологии. Но на сегодняшний день решения SDN- это собственно неотъемлемая часть облака. Решения SDN стали абсолютно адекватны с точки зрения своего функционала, своей стоимости и, главное, возможностей. И на сегодняшний день те традиционные решения, которые применялись на протяжении последних пяти-шести лет, они уже выглядят рудиментарно, то есть они действительно отстали. И решения SDN- это то, куда движется отрасль, куда движется индустрия. Но я тоже долго не буду рассказывать про все преимущества облака и так далее, но, если посмотреть на отчеты IDC, то к 2020 году уже порядка 50 процентов корпоративной инфраструктуры переедет полностью в облако. На сегодняшний день, общаясь с заказчиками, с заказчиками рынка Enterprise, мы конечно видим, что основная модель все-таки это бимодальный подход. Когда, соответственно, заказчик уже имел какую-то свою собственную инфраструктуру, в нее были проинвестированы значительные средства и просто отказаться от использования этой инфраструктуры, все перевести на рельсы облачные, собственно, неправильно и, наверное, это трудно. Поэтому бимодальный подход заключается в том, что те приложения, те сервисы, которые, собственно, существовали на традиционной инфраструктуре, своей собственной, они так и продолжают работать, но какие-то новые приложения, которые планирует компания запускать или запускает прямо сейчас, их конечно уже более правильно реализовывать с помощью облака. При этом сеть передачи данных в том виде, в котором она была, это вот те традиционные технологии, коммутация и маршрутизация де факто они последние лет десять практически не менялись, то есть они базировались на каких-то общих вещах, там конечно были незначительные улучшения, изменения и так далее. Но с появлением SDN, все начинает резко меняться.
Давайте сначала поговорим про традиционные сети, чем же они собственно были плохи. Традиционная сеть подразумевала статический и разрозненный подход к управлению сетевой инфраструктурой. То есть, к примеру, у нас есть ЦОД, который состоит из десяти-двадцати стоек, в каждой из стоек стоит по паре коммутаторов top-of-rack для подключения серверов вычислительных ресурсов, и традиционный подход подразумевал, что, во-первых, каждое из этих устройств требует отдельного внимания, требует статической конфигурации. При этом с точки зрения какой-то централизации, она либо отсутствовала, либо была просто какая-то система мониторинга и управления, которая позволяла оценивать статус работы инфраструктуры, но не давала никакой гибкости с точки зрения централизованного унифицированного управления. Опять же традиционная инфраструктура не отвечает принципам agile. Принцип agile, когда мы собственно планируем запустить какой-то новый сервис, какую-то новую услугу, соответственно мы ее прорабатываем, разрабатываем, в ходе разработки мы видим, что требуются еще какие-то изменения, мы их вносим на этапе разработки. После этого мы услугу запускаем в продуктив, то есть тестируем ее на наших клиентах, при этом при запуске в продуктив мы понимаем, что требуются еще какие-то изменения. То есть здесь постоянная адаптивность, постоянное изменение нашей инфраструктуры. Соответственно, традиционное решение в принципе не позволяло этого сделать с точки зрения сети, потому что, к примеру, тривиальная ситуация, вы хотите протестировать новый релиз 1C для того, чтобы это все произошло, вам надо развернуть какую-то виртуальную машину с определенными свойствами, с определенной операционной системой. С точки зрения вычислительных ресурсов все просто и понятно, то есть мы просто создаем эту виртуальную машину, наделяем ее необходимыми свойствами, и все автоматизировано у нас начинает работать через 5-10 минут. Но с точки зрения сети передачи данных требуется каждый раз привлекать сетевого администратора, сетевого инженера, который будет вручную вносить какие-то конкретные конфигурации на сетевом оборудовании, на каждом конкретном порту, наделять виртуальные машины какими-то конфигурациями. Опять же на сегодняшний день, говоря про облачную инфраструктуру, многие заказчики заинтересованы в том, чтобы это было либо коммерческое облако, либо свое частное облако. Но при этом оно должно быть географически разнесенное, то есть это решение active – active, при котором программные или аппаратные сбои в одном из ЦОДов, они никоим образом не отражаются на работе приложений и сервисов. Соответственно виртуальные машины, которые летают из одного ЦОДа в другой ЦОД, они тоже требуют внимания. То есть если мы говорим про традиционную сеть передачи данных, то она, конечно же, не позволит виртуальной машине, которая перемещается из одного физического ЦОДа в другой ЦОД, во-первых, сохранить свою адресацию, сохранить те правила политики безопасности, которые были на нее назначены при вот этих постоянных перемещениях.
Еще одна проблема, которую мы видим у заказчиков, всегда есть некая служба эксплуатации, которая поддерживает IT-инфраструктуру. При этом эта служба эксплуатации всегда поделена на два лагеря. Первый лагерь — это сетевые инженеры, которые всецело отвечают за передачу данных и второй лагерь – это те люди, которые отвечают за так называемые IT-ресурсы, за вычислительную инфраструктуру, за систему хранения данных. Между ними проходит вот такой жесткий водораздел, соответственно, мы получаем независимое управление компонентами и в случае каких-то проблем, в случае каких-то сбоев. Траблшутинг, идентификация корня проблемы, ее устранение занимает значительное количество времени и при этом порой бывает очень трудно понять, на чьей же стороне возникла проблема и кто должен ее устранять. Здесь мы приходим к ситуации, когда сеть передачи данных – это действительно рудимент, это подложка, которая, тем не менее, не позволяет нам на лету, быстро внедрять новые сервисы, не позволяет нам перейти к полноценному agile подходу.
Если посмотреть на те решения и на те проблемы, которые есть на рынке SDN сегодня, то абсолютно все сетевые вендоры крупные, Huawei, наши конкуренты, предлагают готовую концепцию SDN. То есть это вертикально выстроенная инфраструктура, которая позволяет сделать и централизованное управление, позволяет сделать автоматизацию, позволяет сделать плотную интеграцию с вычислительными ресурсами. Но если посмотреть на конечного заказчика, то конечный заказчик текущей ситуацией очень недоволен по той простой причине, что каждый из вендоров предлагает свое закрытое проприетарное решение, то есть покупай мои коммутаторы, покупай мой SDN контроллер, он может работать только в такой конфигурации, он может только с таким вот гипервизором. При этом с точки зрения заказчика ICT — инфраструктура, ИТ — инфраструктура должна быть диверсифицирована, то есть построена на нескольких вендорах, при этом контроллер или сетевое оборудование, сервера, СХД могут быть от разных производителей. То есть эта та модель, которую идет практически любой заказчик на сегодня. Поэтому эта проблема действительно на сегодняшний день существует и компания Huawei, все-таки, если посмотреть на стратегию, старается выпускать SDN решение более открытое.
Я дальше вот буду показывать, у нас есть экосистема партнеров, это крупнейшие разработчики и платформ виртуализации и сетевого оборудования, соответственно, мы идем по идеологии открытой инфраструктуры, то есть это открытые программные интерфейсы, которые не привязывают заказчика к использованию только нашего оборудования, используя решение SDN.
То решение, которое предлагает Huawei, называется Huawei Cloud Fabric, облачная фабрика или программируемая фабрика. С точки зрения архитектуры, на картинке в принципе показано, все довольно просто, понятно и, наверное, логично. С одной стороны у нас есть сети передачи данных — это некие физические устройства, некие порты, к которым мы подключаем аппаратные сервера, у нас сохраняются эти наши сервера, при этом сверху у нас есть уровень приложений, есть облачная платформа. Здесь появляется ключевой элемент, который называется SDN контроллер, в терминах Huawei это agile контроллер. Это тот оркестратор, который имеет с одной стороны южные интерфейсы для общения с платформами виртуализации, а с другой стороны он имеет северные интерфейсы для общения с платформами виртуализации и южные для общения с сетевым уровнем, то есть с обычными сетевыми коммутаторами. Это традиционный протокол openflow, с помощью которого происходит программирование сетевых устройств. И здесь три основных кита, три основных направления этого решения — это simple – просто, elastic – гибко, и open – открытая инфраструктура. В чем же плюс.
Основной плюс в том, что вот когда мы говорили про этот простейший сценарий, нам требуется протестировать новый релиз 1C, мы сразу не можем запустить его в продуктив, нам надо развернуть какую-то тестовую среду, мы создаем виртуальную машину, мы наделяем ее какими-то свойствами с помощью графического интерфейса, который есть в agile контроллере и далее все конфигурации, которые должны произойти с точки зрения сети, они происходят абсолютно автоматизировано. То есть нам не надо для этой виртуальной машины каждый раз заходить на конкретный коммутатор какой-то, настраивать там правила политики безопасности, политики качества сервиса. Мы создаем просто, условно говоря, в графическом интерфейсе иконку для этой виртуальной машины, там наделяем ее определенными свойствами, и эти свойства абсолютно автоматически провижинятся.
Ключевой темой сегодняшнего мероприятия является безопасность. И здесь вот говорили про безопасность с точки зрения компрометации данных, внешних атак и прочих угроз. Но еще одна угроза, которая таится, это угроза непрофессионализма персонала, который занимается эксплуатацией. То есть из-за каких-то неправильных действий, с точки зрения сети передачи данных или виртуализации, бизнес тоже может пострадать, то есть у нас отключится какая-то виртуальная машина, которая необходима для обеспечения бизнес-процессов.
SDN хорош еще и тем, что, во-первых, у нас появляется возможность централизованного унифицированного управления, у нас появляется полноценный dashboard для аналитики, для полного понимания, как работает наша инфраструктура. И если в какой-то момент мы допустили какую-то ошибку, какую-то проблему с точки зрения конфигурации, то все это легко и быстро можно устранить. При этом за счет того что у нас автоматизированные конфигурации, то здесь ручной труд, то есть какая-то действительно работа с командной строки, она минимизирована, то есть возможность возникновения неправильной конфигурации этой ошибки сводится практически к самому минимуму.
Еще один плюс современных решений сетевых, будь то облачные решения, будь то просто корпоративная инфраструктура, заключается в том, что появились абсолютно новые сетевые процессоры, которые Huawei называет ENP — Ethernet Processor. Это полностью программируемые решения, которые, во-первых, обеспечивают существенно больший прирост под производительность относительно традиционных асиков, с другой стороны они полностью программируемые. То есть на сегодняшний день SDN, к сожалению, пока не стандартизирован до конца, то есть появились некие RFC, появились некие IE стандарты, по которым вендоры, производители стараются выпускать решения, но, тем не менее, какой-то финальной версии стандартизации пока не появилось. Поэтому вот эти ENP процессоры хороши еще и тем, что, сегодня уже покупая оборудование с такими процессорами, вы как конечный заказчик получаете защиту инвестиций. То есть достаточно просто изменить прошивку этого сетевого процессора, и он сможет на лету поддерживать новые типы протоколов, новые типы технологий, которые будут появляться. Традиционные асики, традиционные сетевые процессоры такого не позволяли в принципе.
Большой плюс SDN еще и том, что когда мы говорим о централизованном и унифицированном управлении, мы, как дополнительный бенефит, как дополнительный плюс, получаем возможность сбора аналитики и прогнозирования. То есть у нас так или иначе возникает некая центральная точка, некий интеллект, которая управляет путями передачи трафика и понимает, что происходит в каждом сегменте нашей инфраструктуры. Благодаря этому мы можем накапливать статистику относительно того, что у нас происходит с сетевой инфраструктурой, и когда в какой-то момент происходит внешняя атака или появляется какой-то нестандартный pattern traffic в случае DDoS или какого-то внутреннего эксплойта, то SDN контроллер об этом тоже уведомит. У него в качестве одного из модулей является модуль обеспечения централизованной безопасности, это модуль Big Data, который собственно хранит логин обо всем трафике, проходящем внутри сетевой фабрики, то есть каждый коммутатор здесь выступает неким таким агентом, который собирает эту информацию. И далее мы и на сетевом уровне можем контролировать, что же у нас в итоге происходит с точки зрения безопасности.
Если посмотреть на существующие решения SDN, то их можно разделить, наверное, на три типа архитектуры, по которым SDN строится на сегодняшний день. Первый вариант тот, который наиболее широко, наверное, на сегодня используется в инфраструктуре многих заказчиков. Какое-то время назад, например, ЦОД был построен, то есть были проинвестированы существенные средства в сетевую инфраструктуру, в вычислительную инфраструктуру, и сейчас такой заказчик приходит к пониманию, что сеть действительно тот тормоз, который не позволяет ему более гибко управлять инфраструктурой и предоставлять новые приложения и сервисы. Соответственно он понимает, что ему нужен SDN, ему требуется программируемость, ему требуется централизованное управление, но при этом не хочется менять сеть, то есть в нее проинвестированы средства, сетевое оборудование стоит и работает, и зачем бы его менять. Здесь единственный выход – это строительство оверлейной сети, то есть поверх той традиционной сети передачи данных, которая есть, создается наложенная сеть передачи данных и вот эта наложенная сеть создается с помощью софта. То есть либо с помощью виртуальных свечей, которые можно создать в гипервизоре, либо с помощью просто наложенного программного обеспечения, которое запускается изнутри виртуальной машины. То есть мы поверх традиционной сети, которая просто обеспечивает коннективити, создаем логическую сеть, которая обеспечивает нам автоматические конфигурации и автоматический провижининг.
Второй вариант, который предлагается, это вариант, который собственно предлагает компания Huawei и другие сетевые вендоры. Это решение заключается в том, что мы ставим и аппаратные коммутаторы, которые теперь поддерживают полную программируемость, то есть не надо, как я говорил, в отдельности конфигурить каждую железку. Мы ставим просто новое поколение программируемых коммутаторов, которые работают с централизованным контроллером.
И третий вариант — это такой гибридный вариант. Мы ставим и новые коммутаторы, которые могут поддерживать эту программируемость, при этом в существующие ЦОДы мы ставим виртуальные коммутаторы, которые крутятся там же на сервере, условно говоря, и тем самым получаем такое вот комплексное решение.
Еще большой плюс SDN заключается в том, что теперь мы более эффективно можем утилизировать и каналы передачи данных.
Говоря как раз об вот этих решениях active – active, о решениях disaster recovery, когда у нас все вычислительные ресурсы находятся не в рамках одного ЦОДа, а мы делаем такое географическое разнесение, то здесь стоимость линков между ЦОДами тоже немаловажна, эти линки очень-очень дорогие. Когда мы говорили про традиционные решения, то там нам было трудно оценить, получить какую-то комплексную оценку по поводу того, как используются каналы передачи данных, насколько они загружены. Когда мы приходим к модели SDN, то у нас так или иначе появляется контроллер, который видит, то есть получает информацию относительно загруженности каналов передачи данных. Это нам позволяет более эффективно их загружать, утилизировать, позволяет сделать load balancing, то есть балансировку нагрузки. И тем самым мы можем более равномерно ее распределить, нагрузку на каналы связи, а в некоторых случаях мы понимаем, что можем даже отказаться от столь широких каналов, которые есть на сегодняшний день, и просто более эффективно использовать те каналы, которые у нас были ранее.
С точки зрения аппаратных ресурсов Huawei предлагает здесь целую линейку коммутаторов, порядка 120 модификаций коммутаторов на сегодняшний день.
Эта линейка у нас называется CloudEngine. Здесь основной тренд, который наблюдается – это тренд перехода к 25-гигабитным подключениям, то есть если посмотреть на roadmap абсолютно всех производителей серверного оборудования, то они в один голос говорят, что 10 гигабит уже недостаточно, 40 гигабит стоит очень-очень дорого, поэтому 25 гигабит – золотая середина. На самом деле так и есть. Если посмотреть на стоимость порта 25-гигабитного, то на сегодняшний день она уже полностью сравнялась со стоимостью 10-гигабитного интерфейса. Поэтому здесь на сегодняшний день современный ЦОД – это доступ, то есть подключение серверов по 25 гигабитам и собственно подключение top-of-rack коммутаторов к ядру сети на 100 гигабитов, то есть 25 плюс 100. Это вот формула, по которой строятся все современные ЦОДы.
Говоря про экосистему. Как я сказал, для Huawei одним из ключевых направлений стратегии SDN является построение открытой инфраструктуры. Когда мы предлагаем не закрытое проприетарное решение и говорим заказчику, покупай только наше оборудование, выбрасывай все, что у тебя есть, а собственно это действительно открытая инфраструктура.
Здесь вот показаны наши партнеры по разным направлениям. Если говорить про облачные платформы, про платформы виртуализации, то здесь мы прошли сертификацию vmware и microsoft, прекрасно работаем с openstack, и есть наш собственный гипервизор, fusion сфера, с которым наш SDN контроллер точно также прекрасно взаимодействует.
Есть какие-то еще open source решения, например, Puppet, который позволяет вам получить полную свободу с точки зрения программируемости, но здесь требуется более высокая квалификация ваших сетевых инженеров, по сути, они должны быть в большей части даже программистами теперь. Это решение такое для совсем гуру. Для среднестатистического заказчика рекомендованным является решение использования нашего контроллера с понятным графическим интерфейсом, в котором вы с помощью иконок, с помощью темплейтов управляете всей вашей сетевой инфраструктурой. То есть вам даже не потребуется ни разу заходить в консоль, в командную строку какого-то сетевого оборудования и что-то там настраивать.
Ну и говоря про перспективы SDN, на сегодняшний день, как я вначале сказал, SDN уже из такой долгоиграющей темы, которая зародилась уже практически 7-8 лет назад, превратился в действительно работающее решение. Если посмотреть на те прогнозы, которые дают IDC, то к 2020 году уже порядка 95 процентов коммерческих ЦОДов крупных будут построены с использованием технологии SDN. Huawei себя весьма комфортно чувствует на этом рынке, то есть мы растем год к году практически на 70 процентов по поставкам оборудования сетевого для ЦОДов. И там вот показаны примеры, в разных странах, что же мы смогли сделать.
Немножко про Россию если поговорить, то здесь крупнейшим нашим внедрением SDN является Сбербанк, собственно это один из ЦОДов, который используется непосредственно разработчиками. И вот там им как раз необходимо на лету, максимально быстро создавать какую-то новую инфраструктуру виртуальную и тестировать свои новые разработки. Второй проект SDN, который у нас есть, который реализован, это НСПК, национальная система платежных карт. Если знаете, это платежные карты МИР, которые сейчас бюджетникам всем директивно раздали. Собственно это два ЦОДа, работающие в режиме active – active, то есть виртуальные машины абсолютно плавно, бесшовно могут перемещаться между этими ЦОДами. Здесь вся инфраструктура тоже построена на оборудовании Huawei с использованием наших линеек CloudEngine.
Коллеги, на этом я свой экскурс по программно-определяемым сетям «Что же происходит сегодня?» заканчиваю.
ОТВЕТЫ НА ВОПРОСЫ
ЦОДы карты МИР они находятся у нас на территории?
Обязательно, конечно. Это полностью наша инфраструктура. Центробанк курирует эту тему, то есть все у нас, да, в Подмосковье.
А в принципе услуги по виртуализации, облачные решения находятся в Китае?
Нет, смотрите, те решения, которые предлагает Huawei, контроллеры, это все продается как законченный продукт, и это все ставится в локальном ЦОДе. Сам Huawei не предоставляет никаких облачных ресурсов, мы работаем с нашим партнером RUVDS, собственно, все услуги от партнера.
Можно ли SDN, agile контроллер, контроллер подключить к чему-то, что будет обогащать данные агентские, которые поставляют коммутаторы?
Хороший вопрос на самом деле. На сегодняшний день agile контроллер, SDN находится на том пути развития, когда это централизация для управления, во-первых, оборудованием, с другой стороны – это автоматизация, провижининг конфигураций и более плотной интеграции с вычислительными ресурсами. Следующим шагом является действительно Big Data, это когда мы можем интегрировать с разными внешними источниками, например, атак, антивирусов и прочего, и оттуда контролировать это все. Нас сегодняшний день в рамках agile контроллера этого нет, но у нас наши отдельные файрволы, Next Generation устройства, которые интегрируются как раз с agile контроллером. Это позволяет связке обеспечить такое программно-аппаратное решение.
То есть SDN контроллер пушит какие-то правила на эти файрволы или он может получать данные оттуда?
Он пушит туда правила пока только. То есть вы, например, хотите сказать, что виртуальная машина А должна взаимодействовать с виртуальной машиной Б, проходя DPI, глубокий анализ с точки зрения, что ж там за трафик крутится, и agile контроллер вот эту политику просто распространяет на устройства сетевой безопасности, и там происходит эта аналитика.
Спасибо за внимание!
Автор: RUVDS.com
