Хотя центр обработки данных и является для нас прежде всего технологическим объектом, он представляет собой также и весьма непростую экономическую головоломку, для решения которой необходимо знать ответы на следующие вопросы: как обеспечить защиту инвестиций в оборудование при модернизации дата-центра? Как сохранить преемственность конфигурации ЦОД при смене поколений? На эти и другие вопросы нам ответил Дмитрий Хороших, менеджер по развитию бизнеса в области решений для ЦОД, Cisco.
– Если взять такие основополагающие сущности ЦОД, как приложение, данные и инфраструктура в динамике, то как изменилось их взаимодействие и соотношение в общей структуре дата-центра за последние 15 лет?
– Инфраструктура современного ЦОД представляет собой довольно сложный механизм. Во многих компаниях внедрение информационных технологий началось более двух десятков лет назад. Первоначально развитие ИТ-технологий шло по большей части бессистемно, отдельные системы внедрялись по мере возникновения потребности. Правила либо полностью отсутствовали, либо нарушались, едва возникнув, так как требования к скорости развития не позволяли их корректно соблюдать. Но сколько-нибудь длительная эксплуатация любой сложной технической системы невозможна без правил, ограничений и регламентов, поэтому вполне естественным было желание такие регламенты создать и в ИТ. Сейчас, спустя десятки лет, интересно наблюдать в динамике развитие этих правил и регламентов. С одной стороны, такое развитие ограничено существующими технологиями, с другой – решение насущных задач на каждом из этапов как раз и задает вектор развития этих технологий в будущем. Любой анализ должен на чем-то основываться. В ЦОД такой основой являются приложения, данные и инфраструктура. Приложения отражают бизнес-процессы, которые в конкретный момент существуют и автоматизированы в компании. Данные – это, по сути, актив компании, результат ее деятельности. Грамотное использование этого актива сегодня, в век цифровизации, может позволить компании получить конкурентные преимущества на рынке и завоевать лидерство в своей области. Инфраструктура – это совокупность тех технических требований, которые позволяют приложениям работать, осуществлять взаимодействие друг с другом и с пользователями, а также собирать, накапливать и обрабатывать данные.
В этом плане действительно интересно рассмотреть, как менялось взаимодействие этих трех сущностей. Около 15 лет назад почти под каждое приложение большую часть инфраструктуры приходилось строить отдельно. Все обрабатываемые данные хранились также внутри приложения и зачастую становились от него неотделимыми. Это было единственно возможным решением, но такое положение вещей сильно ограничивало рост и развитие информационных систем. Любое обновление аппаратных компонентов требовало сложных и дорогостоящих процессов миграции данных и конфигураций оборудования. Затем, с появлением виртуализации, произошло разделение приложений и вычислительной инфраструктуры, которая используется для их выполнения. Стало возможным переносить виртуальные машины с приложениями с одного физического сервера на другой, часто даже без остановки их работы. Цикл обновления приложения и цикл обновления «железа» отныне стали независимы друг от друга. Данные по-прежнему находились внутри приложений, но сам процесс управления приложениями стал более гибким. То, что мы наблюдаем сегодня, можно охарактеризовать как процесс отделения данных от приложений. Многие компании сейчас заняты построением «озер данных» – этот как раз одна из реализаций такого принципа. Жизненный цикл данных становится длиннее, чем жизненный цикл приложений, которые с ними работают. И это проводит к необходимости разрабатывать более современные механизмы автоматизации типовых процессов в ЦОД и работать над механизмами организации накопления и хранения данных.
– А как бы вы могли описать основное «движущее противоречие» современного ЦОД?
– Очевидно, что основная роль центров обработки данных – консолидация вычислительных ресурсов в одном месте, цель этого – упростить управление и снизить стоимость владения за счет общих процедур и единых подходов к эксплуатации. В ЦОД работают приложения, которым нужны вычислительные ресурсы – процессоры, память, диски. И эти приложения должны общаться между собой и с внешним миром, для этого нужна сеть. Поэтому, если попытаться представить себе идеальный ЦОД, он будет состоять из двух уровней: уровень вычислительной подсистемы и уровень подсистемы сети ядра ЦОД. Мы сейчас не говорим про инженерные системы, их роль – обеспечивать основное функциональное оборудование электропитанием, охлаждением и т. д. Вычислительная подсистема обеспечивает платформу для работы приложений. В идеальном мире это был бы единый набор вычислительных ресурсов, которые можно гибко делить между различными приложениями. Причем делить не статично, а перераспределять по мере необходимости, чтобы отрабатывать отказы или перераспределение нагрузки на приложения. Функция подсистемы сетевого ядра ЦОД – обеспечивать любые необходимые связи между виртуальными и физическими сетевыми интерфейсами приложений, а также с внешним миром. Здесь тоже есть множество задач, таких как отработка отказов и обеспечение безопасности, ограничение нежелательных подключений и т. д. К сожалению, в реальном мире все системы имеют свои ограничения, не только архитектурные, но и финансовые, организационные, поэтому идеальная картинка разваливается на более мелкие составляющие. Данные и приложения имеют различный уровень критичности: высоконадежный кластер и файловый архив строятся по различным технологиям и, как следствие, имеют различную стоимость. Аналогичным образом ядро сети при ее традиционном исполнении имеет ограничения: из трех характеристик – стоимость, быстродействие, надежность – приходилось выбирать любые две. Когда современные ЦОД строились, другого выбора просто не было, но сегодня уже существуют технологии, которые позволяют удовлетворять всем этим требованиям.
– Можно ли как-то сохранить преемственность конфигурации ЦОД при смене поколений оборудования?
– Это очень хороший вопрос, и он становится особенно важным в свете ускоряющейся «гонки технологий». Как мы проговорили выше, процесс обновления вычислительной инфраструктуры сегодня по большей части не влияет на работу и доступность приложений, сетевое оборудование тоже по большей части может быть обновлено без существенных простоев. Но если посмотреть на сами эти процессы, то они по-прежнему являются достаточно трудоемкими. Все потому, что настройка любого оборудования, особенно серверов, предполагает выполенения определенной последовательности действий. При каждом переносе конфигурации эти действия приходится повторять, и поскольку чаще всего указанный процесс выполняется вручную – это огромное поле для человеческих ошибок, приводящих к большому времени простоя системы. Компания Cisco 10 лет назад начала менять эту ситуацию, выпустив на рынок свою вычислительную платформу Cisco UCS. Основным отличием новых систем был принцип их настройки: конфигурация сервера, включая количество и тип сетевых адаптеров, а также подключение этих адаптеров к внешним сетям описывается в единой конфигурационной единице – сервисном профиле. Далее в работу вступает контроллер, который сам прописывает все настройки в необходимые компоненты системы. От традиционного подхода это отличаетя тем, что, во-первых, в любой момент можно посмотреть все настройки сервера в едином месте, не нужно сопоставлять между собой данные из разных интерфейсов. А, во-вторых, настроив сервер единожды, эту конфигурацию можно переносить, тиражировать, в том числе между различными поколениями серверов Cisco. Сегодня, спустя 10 лет можно сказать, что успех серверной платформы Cisco показывает все преимущества новой модели. Аналогичный подход был предложен для сети ЦОД в продукте Cisco ACI. Вы просто описываете требования к передаче сетевого трафика приложения в сети, а сеть сама решает, каким образом обеспечить эту передачу. Причем получившийся набор настроек (он называется сетевым профилем приложения) является независимой конфигурационной единицей. Его также можно тиражировать, сохранять, переносить в другую сеть, чтобы настроить аналогичное приложение и т. д. Задумайтесь на минутку: в Cisco ACI, например, есть функция «Сохранить текущую конфигурацию сети», которая позволяет разом сделать слепок всех профилей приложений, чтобы потом также разом восстановить настройки на любой момент в прошлом. Сколько времени и потенциальных часов простоя такой подход может сэкономить любой компании.
– Как обеспечить гибкость, преемственность и защиту инвестиций в оборудование при модернизации дата-центра?
– Основной подход к модернизации, позволяющий получить маскимальные преимущества, заключается в том, чтобы мысленно разобрать дата-центр на отдельные функции, а потом пересобрать их на современных технологиях. При этом, если производитель оборудования заранее подумал о защите инвестиций своих заказчиков, то даже при смене одного-двух поколений «железа» отдельные компоненты могут продолжать использоваться. Наглядным примером может быть модернизация вычислительной подсистемы, собранной на одном из типовых дизайнов Cisco для ЦОД, например FlexPod. FlexPod представляет собой связку Cisco UCS и СХД NetApp, т. е. классическую конвергентную архитектуру. Существенный выигрыш в затратах на экплуатацию вычислительной платформы мог бы дать переход на гиперконвергентную систему, но куда девать существующее оборудование? И здесь проявляются все преимущества гиперконвергентной системы от Cisco – HyperFlex. Во-первых, существующие модули фабрики (Fabric Interconnect) можно использовать для подключения серверов HyperFlex, т. е. на этом блоке можно сэкономить. Во-вторых, после переноса части нагрузки с FlexPod освободившиеся серверы можно подключить к HyperFlex в качестве вычислительных узлов (Compute only node). А часть дисковых томов СХД NetApp также может быть подключена к виртуальным машинам с HyperFlex, например для доступа к архивным данным. По сути, мы пересобрали архитектуру вычислительной платформы заново вокруг гиперконвергентного ядра, при этом продолжили использовать существующее оборудование, но получили все преимущества от новой модели организации хранения данных и управления вычислительными ресурсами. Таких примеров можно придумать множество. Существует подход, позволяющий отделить прорывные преобразования инфраструктуры от локальных улучшений, не дающих существенного эффекта в целом.
