ЦОД для «Безопасного города»

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

Невозможно представить себе функционирование современных инфраструктурных проектов, таких как, например, проект «Безопасный город», без комплексной поддержки со стороны ИТ-систем.

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

В первую очередь, необходимо отметить тенденцию к стандартизации «строительных блоков», из которых состоит современная ИТ-инфраструктура. Если еще 5 - 6 лет назад заказчики для каждого решения использовали свой уникальный набор компонентов: серверов, дисковых массивов, сетевых устройств, то в последние 2 - 3 года все большую популярность завоевывают блочные решения: Flexpod, Vspex, Vblock. Вместе эти платформы занимают 60% рынка интегрированных вычислительных инфраструктур и продолжают наращивать свою долю. Также не отстают и другие производители – в ушедшем году компания IBM анонсировала свое интегрированное решение под названием VersaStack, а Hitachi обновила линейку UCP (Unified computing platform). В сетевой части ЦОД также происходят значительные изменения, самым ярким из которых можно назвать появление концепции управления сетью ЦОД, ориентированной на приложения.

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

Первым шагом структурирования является разделение на два уровня: уровень вычислительных платформ и уровень сети и сетевых сервисов. При всей простоте и очевидности такого решения – оно очень сильно упрощает как проектирование аппаратной платформы ЦОД, так и ее дальнейшую эксплуатацию. Уровень вычислительных платформ решает все вопросы, связанные с обеспечением работы виртуальных и физических серверов. «Наружу», в сторону сети, из этого уровня выходит набор виртуальных сетей, по которым «разложены» сетевые интерфейсы серверов. Все вопросы сетевого взаимодействия серверов, такие как связь сетей с помощью маршрутизации или трансляции адресов, разграничение доступа, межсетевое экранирование, балансировка нагрузки, защита от сетевых атак и т.д., полностью решаются на уровне сети и не зависят от того, как функционируют сами серверы. На каждом из уровней существуют свои инструменты управления и автоматизации, к ним предъявляется множество различных требований, но основным требованием в последнее время является поддержка модели управления, основанной на политиках.

Рассмотрим вначале решения, применяемые на уровне вычислительных платформ. Здесь тоже есть два класса систем, отличаются они внутренней архитектурой и теми задачами, для которых они предназначены. Ярким представителем первого класса является продукт Flexpod. Эти системы рассчитаны на традиционную архитектуру приложений клиент-сервер, с выделенным серверов БД или без него. Для них характерно разделение физических ресурсов на систему хранения данных и серверы, занимающиеся их обработкой.

Flexpod представляет собой готовый «ЦОД из коробки». Он содержит в себе серверы, сеть уровня доступа и дисковый массив, причем все это управляется из единого интерфейса с помощью программного обеспечения Cisco UCS Director. Администратор ЦОД может видеть и контролировать  все параметры работы системы на одном экране, управлять выделением ресурсов под различные задачи, создавать новые серверы как виртуальные, так и физические. Добавление вычислительных и дисковых ресурсов в систему возможно «на ходу» без остановки работы активных приложений. Одной из ключевых уникальных возможностей управляющего ПО является портал самообслуживания пользователей. С его помощью администратор ЦОД может автоматизировать часть рутинных задач по управлению ИТ-инфраструктурой, таких как создание серверов, инсталляция операционных систем, управление сетевыми настройками и т.д. После этого, запуск этих задач можно делегировать самим пользователям, тем самым освободив время администратора для более важных дел, таких как планирование новых сервисов и решение стратегических вопросов развития ИТ-ресурсов компании.

Еще одним важным преимуществом Flexpod является то, что это решение апробировано и признано совместимым с ведущими гипервизорами, операционными системами и приложениями. Компанией Cisco совместно с технологическими партнерами разработано более трех десятков типовых документов по инсталляции наиболее популярных приложений (Cisco Validated Design, CVD). Все эти документы находятся в свободном доступе, и их использование позволяет администратору, не имевшему большого практического опыта, за короткий срок развернуть полноценную рабочую систему.

Второй класс вычислительных платформ предназначен для решения задач, связанных с обработкой больших данных. Это относительно новый класс задач, важность которого в последние 2-3 года значительно возросла и в значительной мере этому способствовали проекты по поддержке функционирования городской инфраструктуры. Отличительной особенностью вычислительных платформ является отсутствие централизованного хранилища данных – данные хранятся на серверах и ими же обрабатываются. Это предъявляет повышенные требования как к самим серверам, так и к сетевой инфраструктуре между ними. Для таких решений требуется особый подход, отраженный, например, в типовом решении CPA (Common Platform Infrastructure) компании Cisco для задач BigData.

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

Описанный выше подход более-менее работает, если дело касается статически расположенных приложений. Но современный мир не стоит на месте и бизнес ставит новые задачи перед ИТ.

Зачастую эти задачи приводят к необходимости перенастройки приложения «на лету» или вообще к переносу его в другой дата-центр.

Таких задач появляется все больше и больше. Самые распространенные из них:

• Поддержка DevOps модели разработки новых клиентских сервисов. Разработка продукта идет постоянно, и периодичность новых релизов может уменьшаться до нескольких недель и даже дней.
• Обеспечение восстановления после сбоев (Disaster Recovery). При сбое в основном ЦОД приложение должно «переехать» в резервный и восстановить там свою работу.
• Рост нагрузки при ограниченных ресурсах ИТ-инфраструктуры ЦОД, в таком случае одним из возможных решений может быть «расширение» во внешнее облако.
• Скачки нагрузки на приложения, которые можно отрабатывать за счет перераспределения приложений между отдельными  ЦОД или вывода нагрузки во внешнее облако. Случай похож на предыдущий с тем отличием, что после окончания «пика», приложение можно вернуть обратно, тем самым оптимизировав платежи внешнему провайдеру.
• Миграция приложения вслед за источником/потребителем сервиса - интересный кейс, обретающий актуальность в эпоху Интернета вещей (IoT).

Все описанные требования, в первую очередь, характерны для ИТ-систем «Безопасного города», как новой, развивающейся технологии, ориентированной на поддержку самых разнообразных пользователей и процессов. Во всех описанных случаях приложение должно в автоматизированном режиме поменять свои настройки или даже «переехать» из одного ЦОД в другой и при этом «перевезти» с собой не только содержимое виртуальных или физических машин, но и свои сетевые компоненты, сетевые настройки. Причем с точки зрения пользователя порядок работы с приложением меняться не должен. Конечно, эти задачи в том или ином объеме решаются и сейчас, но только действительно полностью программно-определяемый дата-центр позволит избежать всех ограничений. Традиционный подход к построению сети и управления ею в этом случае не работает, на смену ему приходит технология управления сетевыми настройками на основе политик. Наиболее ярким представителем этой технологии является решение ACI (Application centric infrastructure), архитектура сети, ориентированной на приложения.

Архитектура ACI, как было сказано выше, использует модель политик для хранения сетевых настроек приложения, что позволяет автоматически распространять изменения на все устройства сети и, соответственно, сократить время и ресурсы для разворачивания приложений, более того – автоматизировать этот процесс. Архитектура ACI использует понятие терминальной группы (End point group, EPG) для описания портов виртуальных и физических машин, находящихся в одном сетевом сегменте. Далее между терминальными группами (EPG) задаются правила прохождения сетевого трафика, таким образом, строится сетевая модель приложения. Политики являются едиными для всей фабрики ACI, это еще одно понятие, описывающее группу коммутаторов, работающих по единым правилам, обычно это сетевое «ядро» дата-центра. Важно то, что на входе в фабрику ACI весь сетевой трафик «нормализуется» что дает возможность использовать в одной терминальной группе приложения, работающие в кластере Vmware или Hyper-V, и на традиционной архитектуре (включая физические серверы). Например, если вам необходимо произвести постепенную миграцию приложений в облако, вы можете подключить к одной фабрике ACI физические серверы и кластер виртуализации и переносить нагрузку постепенно с минимальными простоями и без значительных временных затрат на перенастройку сети. Еще более интересный случай использования заключается в возможности работы разных частей одного приложения (например, сервера приложений и СУБД) на разных платформах виртуализации. Ведь у разных гипервизоров различаются производительность, плотность размещения нагрузки, модель лицензирования. С архитектурой ACI администратор сможет выбирать, где ему размещать приложения без оглядки на физическую сеть дата-центра и настройки конкретных единиц оборудования.

Для облачной платформы, работающей поверх архитектуры ACI, важно, что управление фабрикой может быть интегрировано с тем же инструментом UCS Director, который используется для настройки вычислительной платформы. Это означает, что из одного и того же оркестратора мы можем настроить как вычислительную часть ЦОД, так и сетевую. Это дает нам возможность говорить о полноценном управлении ЦОД из единого интерфейса или даже через единый API (UCS Director реализует «северный» REST API для интеграции с инструментами управления более высокого уровня).

Еще одним важным моментом, выгодно отличающим ACI от других решений в этом сегменте, является то, что протоколы, используемые для конфигурирования фабрики, являются открытыми, что позволяет сторонним компаниям свободно разрабатывать сетевые устройства, реализующие те или иные сетевые функции. Поэтому приложение, однажды настроенное для работы в архитектуре ACI, сможет перевести в другой ЦОД (например, при аварийном восстановлении) все свои сетевые политики и настройки.

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