Дмитрий Хороших
Дмитрий Хороших: «Концепция Intercloud сродни единой системе мостов между разными облачными островами»

Суть предложений Cisco пояснил в интервью Computerworld Россия Дмитрий Хороших, менеджер компании по развитию бизнеса в секторе центров обработки данных.

- Каким в Cisco видят будущее центров обработки данных?

Сейчас в ЦОД уровень, на котором функционируют ИТ-нагрузки, отделяется от уровня, на котором реализуется соединение этих нагрузок с внешним миром и между собой. На обоих этих уровнях все чаще применяются типовые решения, помогающие строить вычислительную и сетевую инфраструктуру быстрее, развивать их более гибко, проще масштабировать нагрузку на сеть и на ИТ-платформу. Например, у Cisco есть три типа вычислительных «кубиков», позволяющих строить ИТ-инфраструктуру для большинства прикладных задач. Мощность одного такого блока может масштабироваться от сотен до десятков тысяч виртуальных машин, при этом единственное, что нужно добавлять в систему, – вычислительные и дисковые ресурсы, логика работы при этом не меняется. Чтобы еще больше упростить построение законченного решения, мы предлагаем рекомендованные дизайны Cisco Validated Design (CVD), например, для построения платформы виртуализации или инфраструктуры VDI. На сегодня таких CVD уже более 30. Впрочем, есть и специфические продукты для поддержки задач Больших Данных или архитектуры OpenStack. Заказчик не должен ломать голову, как соединить между собой сервер и систему хранения. Ему нужно дать готовые блоки для построения инфраструктуры ЦОД. На уровне сети мы отмечаем дальнейшее увеличение производительности и масштабируемости используемых решений, а также повышенное внимание к автоматизации. Происходит качественный переход в управлении сетями ЦОД, который позволит вместо манипулирования настройками конкретных устройств начать манипулировать политиками, определяющими работу сети. Решая свои задачи, пользователи не должны заботиться о том, какой протокол, какой порт, на каком устройстве им нужно настроить, а также как это сделать. Пользователи оперируют набором приложений, взаимодействующих между собой. Это взаимодействие нужно описать с помощью политик, а сеть должна просто выполнять указанные политики. При обслуживании таких сетей уже будет не важно, имеет ли отвечающий за них специалист опыт работы с каким-то типом оборудования. Главное, чтобы он знал, как работают приложения и как с их помощью решать те или иные бизнес-задачи. А вопросы функционирования отдельных элементов сети будут решать интеграторы или компании, обслуживающие инфраструктуру ЦОД

- В чем преимущества для заказчиков архитектуры Fabric-Computing Data Center Architecture, предложенной в рамках описанной вами стратегии?

Положим, у нас есть какое-то количество типов нагрузок в ЦОД, которые используются для выполнения определенных вычислительных задач. Когда мы переходим от выделения ресурсов под каждую задачу к концепции Fabric-Computing Data Center Architecture, мы подразумеваем, что все наши ресурсы являются взаимозаменяемыми и масштабируемыми. Мы формируем пул ресурсов и для каждой нагрузки берем из него необходимое количество ресурсов. Если ресурсов не хватает, мы их оперативно добавляем, а если какая-то система выполнила свою задачу и больше не нужна, то использовавшиеся для нее ресурсы возвращаются в пул и повторно задействуются для выполнения других задач. Наша цель в том, чтобы распространить такой подход на аппаратные серверы и сеть ЦОД, не жертвуя при этом производительностью и управляемостью. Для заказчика выгода от перехода к Fabric-Computing Data Center Architecture заключается в том, что он намного более гибко может использовать набор имеющихся в его распоряжении вычислительных или сетевых ресурсов.

- Не является ли это фактически консолидацией ресурсов?

Чтобы реализовать данную идею, нужна консолидация. Однако консолидацией она не ограничивается. Консолидацию можно осуществить для отдельного узла, но не для набора узлов. Консолидация серверных ресурсов существовала задолго до того, как Cisco пришла на рынок ЦОД. И виртуализация серверных платформ тоже уже практиковалась. Мы же обеспечили унифицированное управление этими консолидированными ресурсами, дали возможность очень просто реализовать миграцию нагрузок внутри набора консолидированных ресурсов. Мы не изобретали сервер, а лишь предопределили то, каким образом этот сервер управляется и взаимодействует с внешним миром. Сервер внутри остался тем же самым, но мы поменяли механизм, определяющий, как выполняются настройки и как реализуется его подключение к внешнему миру в момент переноса нагрузки на другой сервер. То же самое можно сказать в отношении сетевых ресурсов. Мы не изобретаем сетевые протоколы или протоколы взаимодействия между приложениями. Мы меняем принципы настройки сетевых устройств в ЦОД, предлагая видение того, как эти настройки мигрируют при переносе нагрузки с одного физического устройства на другое.

- В чем суть объявленной Cisco концепции Intercloud?

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

- Как будет формироваться экосистема Intercloud? Какую роль в реализации этой концепции отводится партнерам — провайдерам и вендорам?

Мы строим Intercloud как открытую систему. Каждый, кто хочет присоединиться к ней, получает набор необходимых инструментов. Но нужно выполнить ряд требований. Если мы говорим о провайдерах, то их инфраструктура должна соответствовать условиям программы Cisco Powered Cloud Provider, определяющей, из каких блоков она должна состоять и какие функции должны поддерживать эти блоки. Соответственно производители оборудования должны выпускать для Intercloud такие продукты, которые могут быть использованы для построения инфраструктурных блоков. Эти требования оправданны, они определены тем, как вышележащие уровни облачной инфраструктуры должны взаимодействовать с аппаратной платформой.

Провайдеры будут встраиваться в экосистему, когда начнут строить свое облако на предложенных нами принципах и получат сертификат Cisco Powered Cloud Provider. Он гарантирует заказчику, что приобретаемый им набор сервисов у одного провайдера может быть предоставлен любым другим. Ведь концепция Intercloud позволяет строить систему, ресурсы которой берутся из разных облаков. Конечно, это добровольное решение – использовать Intercloud. Но, используя его, провайдер дает клиенту дополнительную гарантию, что не будет препятствовать уходу к другому провайдеру облачных сервисов. Это сделает рынок более прозрачным.

- Как на практике будет реализована концепция Intercloud?

Окончательная модель реализации Intercloud будет сформирована к концу лета. Но суть этой модели в том, что и у провайдера, и у клиента появится программный компонент, который обеспечит прозрачный переход нагрузки из облака в облако. Этот компонент будет работать с гипервизорами, организовывать и настраивать сетевые соединения, что позволит нагрузке легко и быстро мигрировать. Клиент тоже сможет приобрести себе такой модуль и, установив его, начать работать с различными публичными облаками. Вопрос о том, как такой модуль появится у клиента, решит сам провайдер – он может предоставить его в пакете услуг бесплатно, а может продать отдельно. Это вопрос тарифной политики провайдера.

- В чем преимущества Cisco Application Centric Infrastructure? И правильно ли противопоставлять ACI технологиям SDN?

Программно-конфигурируемые сети (Software-Defined Networking, SDN) – популярный термин, которым участники рынка обозначают разные вещи. Скажем, некоторые заказчики уже имеют набор для автоматизации серверных платформ и научились приемам переноса нагрузки с сервера на сервер или из ЦОД в ЦОД. Такие компании хотят программным образом менять маршрутизацию и коммутацию внутри аппаратных сетевых устройств, чтобы поддерживать миграцию. И они понимают под SDN наличие в аппаратном оборудовании соответствующих интерфейсов для его перепрограммирования. Другие же, поддерживая концепцию виртуализованной платформы, хотят, чтобы при миграции виртуальной нагрузки сеть автоматически подстраивалась под процесс переноса посредством интеграции с гипервизором. Они именно это имеют в виду, говоря об SDN. А наиболее распространенное определение SDN предполагает наличие неких интерфейсов, через которые можно управлять сетью для смены алгоритмов передачи трафика.

В представлении об SDN, где главное — наличие интерфейса для смены сетевых алгоритмов, имеет место подмена понятий и формулируется сама задача вместо описания ее решения. В Cisco, разрабатывая концепцию ACI, понимали: клиенту зачастую не нужна возможность управлять сетью – клиенту нужно, чтобы сеть работала так, как он того хочет. И неважно, насколько сложно она устроена внутри, и по каким интерфейсам взаимодействуют внутри сети устройства. Клиенту нет проку от возможности программным образом конфигурировать VLAN, ему нужно, чтобы трафик его приложения каким-то «магическим» образом появился на другом порту в другом дата-центре для взаимодействия с другим приложением. У наших устройств, конечно, есть открытые интерфейсы и возможность их перепрограммировать. Если заказчики захотят самостоятельно разработать алгоритмы, по которым будет работать их сеть, то мы здесь совершенно открыты – у нас есть необходимые интерфейсы API. Но когда мы говорим об ACI, то подразумеваем, что заказчик получает не ящик с инструментами, а готовое управляемое решение. В ACI мы фактически создаем распределенное устройство с бесконечным количеством портов, которые физически находятся на разных коммутаторах, и предлагаем программный компонент, позволяющий гибко настраивать связанность в этом виртуальном устройстве между отдельными портами, к которым подключаются приложения. Причем приложения могут располагаться как на физических серверах, так и внутри виртуальной инфраструктуры. Приложения также могут работать поверх любого гипервизора, и они могут работать на серверах всех марок – не только Cisco. Поэтому мы говорим, что концепция ACI значительно шире концепции SDN.

- Ряд аналитиков считает, что отечественная индустрия ЦОД только начинает формироваться. В какой степени она готова к восприятию инновационных подходов Cisco?

Я согласен с утверждением, что индустрия ЦОД в России еще не сформировалась. Нередко даже компании, активно играющие на этом поле, ничего не знают друг о друге. Операторы ЦОД пока осваивают рынок «вокруг себя» и почти не пересекаются с другими его участниками. Но через два-три года рынок может насытиться облачными сервисами, и к тому времени провайдерам желательно иметь в своем арсенале какое-то конкурентное преимущество. Поначалу многие операторы ЦОД строили свои облака на тех технологиях, которые были им известны в момент строительства. Это были разные технологии, практически у каждого своя. Из-за этого внутренняя структура облака выглядит по-разному. Но уже сейчас передовые компании задумываются над тем, какими будут их сервисы завтра. И многие присматриваются к последним разработкам Cisco. Что касается ACI, то мы видим растущий интерес к ней не у традиционных облачных провайдеров, а у компаний, оказывающих услуги OTT. Дело в том, что ACI дает им ряд преимуществ – возможность высокоплотного размещения портов и гибкую программную конфигурацию отдельных небольших сервисов. У владельцев ЦОД сегодня неплохо выстроены процедуры «ручной» автоматизации. Они сфокусированы на том, чтобы снизить затраты на построение ИТ-инфраструктуры и ее обслуживание. Поэтому провайдеры облачных услуг ЦОД сейчас больше смотрят на серверы Cisco, которые позволяют им упростить работу с нагрузками пользователей. Сетевые же подключения, как правило, устанавливаются один раз при появлении новых клиентов и потом их меняют не часто. А у провайдеров ОТТ задачи изменения сетевых настроек возникают значительно чаще. Думаю, через год-два, с началом практической реализации Intercloud и дальнейшим распространением ИТ-сервисов, оказываемых облачными провайдерами, станут востребованы и наши подходы к реконфигурации сети. И тогда концепция ACI может помочь операторам ЦОД значительно упростить эту задачу и снизить расходы на ее реализацию.