Менеджер по развитию бизнеса Cisco Дмитрий Хороших: «Cisco ACI – решение, опередившее свое время»

На своем первом петербургском North-West Cisсo Forum западный вендор представил ряд инновационных решений в области сетевой инфраструктуры, и среди них – обновленную до версии 4.0 сетевую фабрику для дата-центров Cisco ACI. В том, что представляет собой данный продукт и в чем его преимущество, нам предстоит разобраться вместе с Дмитрием Хороших, менеджером по развитию бизнеса Cisco.

Дмитрий, какое место среди приоритетных направлений развития Cisco занимают решения для дата-центров?

– Если попытаться разделить бизнес Cisco на составные компоненты, то мы получим несколько ключевых направлений. Первое – это корпоративные сети, то есть все способы подключения к сети и передачи трафика. Второе – это инфраструктура ЦОДа: вычислительные платформы, системы хранения данных, сеть, инструменты мониторинга и аналитики. Третье – безопасность внутри ЦОДа, в корпоративной сети и во внешних сетях. Четвертое – системы совместной работы, TelePresence, Meeting Server и другие решения. Пятое, новое и активно развивающееся направление – Интернет вещей, подключение к сети внешних устройств. Наконец, отдельный сегмент бизнеса Cisco – операторы связи со своими собственными enterprise-сетями и дата-центрами, которые объединяются в единую глобальную интернет-сеть. Из всего многообразия решений Cisco более 20% предназначены для дата-центров – по этой цифре уже можно судить о важности для нас данного направления. 

Дмитрий Хороших, менеджер по развитию бизнеса Cisco

С момента основания компании Cisco при разработке решений мы ориентируемся на такие цели, как снижение затрат заказчиков, максимальная автоматизация операций и упрощение процессов на стыках различных систем. Первый маршрутизатор позволил объединять сети, внедрение IP-протоколов связало голос и передачу данных. К 2008-09 годам мы увидели, что с возрастанием количества серверов и появлением виртуализации процесс подключения сервера к сети становится всё сложнее. В то же время ни одно приложение не может работать без серверов, вычислительных мощностей. Таким образом, на рынке дата-центров мы так же стараемся упростить процессы конфигурации серверов, подключения к сетям, изменения настроек.

Более того, я не знаю другой компании, создавшей за последние 7-8 лет столько инноваций в области вычислительной платформы и платформы сетей для ЦОД, сколько создала Cisco. И мы продолжаем инвестировать в эту деятельность, проводить исследования.

Рынок коммерческих дата-центров в России, вопреки законодательным инициативам регуляторов, растет достаточно скромно. Насколько он сейчас вообще перспективен для Cisco?

– Чтобы вся картина стала более понятой, нужно начать издалека. Несколько лет назад мы запустили глобальную программу Cisco Powered Cloud Provider. Суть ее заключалась в том, что провайдеру предоставлялась возможность построить свою облачную инфраструктуру, в первую очередь IaaS, в соответствии с рекомендациями Cisco. Для этого мы проводили бесплатный аудит провайдера по определенному набору критериев, которые затрагивали не только саму инфраструктуру, но и процессы обслуживания: каким образом компания обрабатывает заявки, реагирует на обращения клиентов, планирует внедрение новых сервисов, помогает заказчикам в миграции на них инфраструктуры. За три года, пока действовала программа, к ней присоединились и прошли сертификацию более 250 облачных провайдеров по всему миру. По сути, мы создали механизм стандартизации. Теперь, если клиенту сертифицированного провайдера потребуется открыть свою облачную площадку, то он может требовать определенный набор услуг и уровень сервиса. Соответственно, сертификацию Cisco Powered Cloud Provider получили и шесть российских компаний: Linxdatacenter, «ИТ-Град», Softline, КРОК и другие. В целом же из первой десятки российских коммерческих дата-центров, предоставляющих облачные услуги, более половины сегодня построены на базе серверных решений Cisco, и большинство используют наши сетевые решения.

Теперь, наконец, о перспективе. Упомянутые мною провайдеры – лидеры рынка, которые активно развиваются и расширяют портфолио, не останавливаясь на IaaS и начиная предлагать бэкап, security, collaboration как сервисы. Именно в расширении каталога услуг мы видим, в первую очередь, потенциал для развития. Кроме того, большинство из этих компаний еще и системные интеграторы, которые используют опыт построения облачной инфраструктуры на базе решений Cisco для создания подобных же систем у заказчиков. Получается, что заказчик может быть уверен в апробированности приобретаемого решения, и вместо того, чтобы тратить несколько недель или даже месяцев на выбор и тестирование, получит его в самые короткие сроки. А если провайдер готов на время разместить некоторые мощности заказчика в своем облаке, то последний может начать использование своих новых систем буквально на следующий день после подписания контракта, после чего постепенно перемещать их к себе.

Какое место в инфраструктуре дата-центра занимает сетевая фабрика? В чем принципиальное отличие ACI от традиционной сетевой инфраструктуры?

– Любая ИТ-инфраструктура построена для поддержки бизнес-процессов: например, для процесса управления логистикой создается некая информационная система, которая работает на определенном оборудовании. Для нее нужны вычислительные мощности и транспортная сетевая инфраструктура. На этом уровне мы представляем сеть неким «идеальным облаком», в котором возможны любые связи и объемы передаваемого трафика. Но как только мы опускаемся на уровень «железа», возникают ограничения: в полосе пропускания и т. д.

Отличие фабрики ACI от традиционной модели, во-первых, в совершенно иной модели топологии сети. Это модель, которая позволяет не вертикально, а очень гибко горизонтально масштабировать сеть. В ней выделяется два уровня устройств: leaf (листья) и spine (ствол). Если клиенту необходимо, к примеру, увеличить количество абонентских подключений – добавляются устройства уровня leaf, а если нужно увеличить общую полосу пропускания фабрики – spine.

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

Кто формирует этот набор правил?

– Этот вопрос сегодня, наверное, для наших клиентов самый «больной». Изначально предполагается, что за работу сети отвечают три группы людей. Владельцы приложений, решающие бизнес-задачи, рисуют общую структуру. Сетевые администраторы, отвечающие за работу сети, «приземляют» эту структуру на конкретные внешние порты и подключения. Администраторы по информационной безопасности добавляют в нее различные правила и политики. Однако на практике часто выходит, что о третьей группе попросту забывают, а люди, отвечающие за приложения и за сеть, конфликтуют и любой сбой системы пытаются переложить на плечи друг друга. Очень часто они не готовы работать вместе, чтобы создать такой профиль приложения. Поэтому пока мы чаще всего встречаем так называемые network centric  внедрения, когда сетевая команда просто принимает как данность ту структуру, которая уже сложилась вокруг них с точки зрения подключений. Они просто берут существующую, сложившуюся модель сети и переводят ее в ACI, а дальше тот потенциал, который уже есть в системе, приводит к тому, что компания получает возможность для безболезненного изменения бизнес-процессов.

Сложно ли создавать сетевую фабрику «с нуля»?

– Совсем нет. Процедура сборки коммутаторов в единую фабрику полностью автоматизирована: вы их включаете, соединяете, контроллеры находят все коммутаторы, те определяют связи между собой – и через несколько минут фабрика полностью готова к работе. Далее вы просто открываете GUI (графический пользовательский интерфейс, англ. graphical user interface – прим. ред.), среду управления, и начинаете настраивать связность. То есть сборка фабрики ACI даже проще, чем объединение двух коммутаторов в отказоустойчивую пару. В последующем фабрика позволит значительно снизить затраты на конфигурирование и эксплуатацию сети: в значительной степени за счет того, что автоматизация многих операций оберегает администратора от ошибок.

Передо мной схема минимальной конфигурации инфраструктуры ACI: два устройства Nexus 9336, два устройства Nexus 9372PX-E и контроллеры APIC. Какова роль каждого из этих компонентов, и как они взаимодействуют между собой?

– С появлением виртуализации и больших многокомпонентных приложений внутри дата-центра перемещается больше трафика, чем поступает наружу. В этом отличие сети ЦОДа от enterprise-сетей, где компьютеры конечных пользователей общаются не между собой, а с внешними сетями или с дата-центром, то есть профиль трафика вертикальный. В дата-центре профиль трафика в основном горизонтальный, поэтому его сеть должна быть рассчитана на большую полосу пропускания внутреннего трафика. Фабрика ACI как раз позволяет это сделать благодаря модели масштабирования. Как я уже сказал, в ней есть устройства leaf, к которым подключаются конечные абоненты, и spine, которые создают нужное количество каналов связи между leaf. Третий компонент этой схемы – управляющие контроллеры, их в фабрике может быть от трех до 15-ти, в зависимости от ее величины. 

О решении Cisco ACI впервые заговорили в 2013 году. Как оно развивалось на протяжении этих пяти лет, с точки зрения технологий и динамики продвижения на рынке, а также стоимости?

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

О стоимости решения могу сказать, что в анонсированном недавно ACI 4.0 появилась модель ACImini, в которой spine-устройства имеют меньший форм-фактор и цену, а два контроллера из кластера могут быть не физическими устройствами, а виртуальными. Это снижает стоимость фабрики примерно на 40%. Таким образом, если раньше мы видели интерес к фабрике только со стороны крупных компаний, то сейчас можем предложить ее и компаниям среднего и даже небольшого размера.

Какие дополнительные сервисы к сетевой фабрике предлагает Cisco?

– Модель конфигурирования фабрики через профиль приложения позволяет добавлять в нее функции безопасности. Они могут быть вынесены на внешние аппаратные устройства, если у них есть модуль интеграции с фабрикой ACI. Сегодня нашим клиентам доступны модули интеграции как с собственными решениями Cisco, так и с внешними балансировщиками нагрузки от Citrix и F5, межсетевыми экранами уровня приложения от Positive Technologies. Компания-клиент может с помощью единой конфигурационной единицы, профиля приложений, конфигурировать не только сеть, но и устройства безопасности, которые обеспечивают защиту этой сети.

Вторая большая группа сервисов – аналитические. Фабрика вкупе с инструментами аналитики – как, например, Cisco Tetration, – дает возможность компании понимать, как взаимодействуют между собой приложения, и таким образом формировать более осознанный подход к защите системы, более объективно планировать миграцию приложений и распределение нагрузки между дата-центрами. Например, можно вывести перечень всех систем, которые обращаются к определенному приложению, и в случае его миграции на новую версию заранее понять, в каких именно системах необходимо поменять настройки.

Читал, что Cisco ACI можно использовать не только в коммерческом ЦОДе, но и в периметре крупной компании, для создания частного облака.

– На самом деле, до 80% внедрений ACI – это именно проекты в крупных компаниях. Как правило, это банки и другие организации, предоставляющие финансовые сервисы, у которых традиционно много связанных между собой приложений. Обеспечение связности в сети достаточно затратный процесс, и переход на ACI позволит их значительно снизить. Также мы видим интерес к сетевой фабрике со стороны промышленных компаний, которые также используют множество различных ИТ-систем, различных приложений, причем зачастую устаревающих. Сейчас во многих сетях, которые существуют более 7-10 лет, накопилось множество артефактов, от которых и позволяет избавиться ACI.

Затруднением в плане внедрения Cisco ACI является то, что решение может быть построено только на ограниченных моделях оборудования Cisco. Является ли это проблемой для вендора и его клиентов?

– На самом деле, у любого оборудования есть жизненный цикл, равный примерно 4-6 годам. У любого решения также есть цикл внедрения в 1-2 года, нельзя просто взять и в один миг перенести приложения из старой концепции в новую. Мы часто видим, как компании заранее, за год-два до обновления оборудования, приобретают фабрику и постепенно начинают переносить туда настройки приложений. Когда настает пора менять существующее оборудование, у них уже готова работающая фабрика. Различные модели финансирования – например Cisco Capital – позволяют распределить платежи и сделать такое приобретение практически безболезненным.

У Cisco много различных вариантов интеграции ACI с существующей системой. Один из них – vPOD, который мы анонсируем сейчас. Другой вариант – появившаяся в прошлом году схема  Remote leaf, по которой можно постепенно заменять устройства в существующей сети по мере окончания их срока службы на коммутаторы семейства Nexus 9000. Таким образом, если заказчик мыслит категориями циклов обновления оборудования, то решение о переходе на фабрику ACI становится для него логичным и перспективным шагом.

Автор: Александр Янкевич, Андрей Блинов.

Тематики: Интеграция, Оборудование

Ключевые слова: ЦОД, Cisco, сетевое оборудование, ИТ инфраструктура