Об основных компонентах, архитектуре, особенностях масштабирования и управления ресурсами при гибридной модели в интервью журналу Connect рассказал заместитель начальника департамента информационных технологий, «Пробизнесбанк», ФГ «Лайф» Александр Белясников.
– Насколько гибридные облака востребованы в банковской сфере? Какие задачи по ИТ-поддержке банковских бизнес-процессов решаются на базе гибридного облака уже сегодня?
– Когда речь идет о гибридном облаке, то, как правило, имеется в виду комбинация из двух и более облачных инфраструктур – частных и публичных, связанных между собой технологиями передачи данных и приложениями. То есть это облако, развернутое в вашем собственном ЦОД, объединенное логически, например, с облаком MS Azure, AWS или облаком какого-то отечественного провайдера. Идеальная ситуация, когда гибридное облако имеет единую систему управления (Cloud Management Platform – CMP). Гибридные облака – решение для тех компаний, которые хотят использовать все преимущества облачного подхода, не отказываясь от эксплуатации традиционной ИТ-инфраструктуры.
Основные потребители гибридных облаков – предприятия среднего и крупного бизнеса. К ним относятся финансовый и телеком-секторы, крупные холдинговые компании с централизованными ИТ-департаментами. Этим и определяются особенности их развертывания и эксплуатации. Прежде всего, для того чтобы внедрение гибридного облака было экономически обосновано, требуются большие объемы потребления ИТ-услуг.
У крупных банков, как и у больших предприятий в других отраслях, рано или поздно возникает проблема ограниченности собственных вычислительных мощностей, невозможности быстрого масштабирования, особенно при необходимости выполнить задачи, требующие больших ресурсов, но на определенный период времени. Гибридные облака как раз и являются способом решения таких задач. ФГ «Лайф», например, применяет гибридный вариант для быстрого развертывания тестовых сред, сред разработки, запуска различных пилотных проектов, размещения сервисов, не требующих значительной интеграции с АБС банков Группы. Несмотря на наличие небольшого запаса мощностей и активное применение технологий виртуализации, мы стараемся прибегать к нему только при разработке ключевых, наиболее значимых для бизнеса сервисов.
– Какие варианты конфигурации архитектуры гибридного облака встречаются на практике?
– Архитектуру гибридного облака можно разделить на три уровня. Первый – предоставление услуг конечному потребителю. На этом уровне находятся такие инструменты, как портал самообслуживания и каталог сервисов, система управления качеством предоставления услуг и соответствующими соглашениями с потребителями (SLA), управление финансами, мощностями и доступностью сервисов. Второй – управление (оборудованием, виртуальными средами, данными, политиками безопасности), мониторинг, оркестрация. Третий уровень – технологии, обеспечивающие вышележащие уровни. Здесь, в свою очередь, выделяются три уровня, позволяющие реализовать разные модели предоставления сервиса:
- IaaS – инфраструктура (ЦОД, системы хранения данных, вычислительные мощности, сети, гипервизоры);
- PaaS – платформа (сервисы, обеспечивающие работу приложений);
- SaaS – программное обеспечение (приложения, обеспечивающие автоматизацию бизнес-процессов).
– Какое место в современном понимании архитектуры гибридного облака занимают технологии программно-определяемых сред (SDS, SDN)?
– Технологии SDS и SDN играют важную роль. Это связано с тем, что одним из ключевых постулатов облачной инфраструктуры является автоматизация. Применение технологий программно-определяемых сетей и хранилищ как раз и позволяет решить задачу автоматизации, особенно если конечный ИТ-продукт рассчитан на массовый рынок.
Однако гибридные облака довольно часто строят большие компании в целях решения своих внутренних задач. Такие компании, как правило, не обладают технологиями SDN и имеют только некоторые элементы SDS. Это не означает, что путь к облачной инфраструктуре для них закрыт: ее можно реализовать, но с более низким уровнем автоматизации и гибкости. Для решения внутрикорпоративных задач этого может быть вполне достаточно, мы пошли именно по такому пути.
– Каковы основные компоненты гибридного облака на практике?
– В практике ФГ «Лайф» ключевые компоненты гибридного облака – удобный и понятный портал самообслуживания для внутренних и внешних клиентов компании, биллинговая система и система финансовой отчетности, компоненты сбора метрик и мониторинга, а также единая система управления облаком (CMP), включающая в себя драйверы для связи с публичными облаками, компоненты для управления гипервизорами и оркестраторы.
– Каким образом реализуется управление ресурсами в рамках гибридной модели – их распределение между приложениями, управление при гибридном подходе к облачной модели ИТ-поддержки?
– Облачный подход дает возможность потребления ИТ как услуги через самообслуживание, при этом сами услуги и их компоненты стандартизованы, а процесс их выделения автоматизирован. Если говорить о гибридном подходе к облачной модели, при нем применяются все те же процессы – управление изменениями, мощностями, непрерывностью и конфигурациями, что и в целом при управлении классической инфраструктурой.
Процесс управления изменениями в облаке должен быть по возможности сведен к стандартному набору запросов на изменения, позволяющему автоматически получать их подтверждение и осуществлять операции выделения, изменения или удаления ресурсов. Процесс управления изменениями основан на каталоге сервисов, через который пользователь может инициировать один или несколько более детальных запросов, например на создание новой виртуальной машины, развертывание базы данных или инсталляцию приложения.
Управление мощностями позволяет оптимизировать выделение и распределение облачных ресурсов, планировать их объемы под создаваемые облачные сервисы.
При эксплуатации облачных решений важное место занимает обеспечение оптимального использования ресурсов и выполнения заявленных SLA. Это достигается за счет применения технологий мониторинга доступности, загрузки аппаратных ресурсов и балансировки поступающих пользовательских запросов между имеющимися аппаратными платформами. Например, если производительность облачного сервиса падает, система управления автоматически выделяет дополнительные ресурсы для обеспечения параметров производительности, определенных в SLA. Процесс управления должен гарантировать, что облачные ресурсы будут соответствовать принятым в компании правилам выделения и распределения ресурсов, а также политикам безопасности. Важно, чтобы эти политики были четко определены.
Классический инструментарий службы технической поддержки и связанные с ней процессы управления инцидентами тоже в полном объеме применимы в случае гибридного облака.
– Как реализуется в рамках гибридной модели контроль за безопасностью данных и приложений, критических с точки зрения ограничений внешнего доступа?
– Важной особенностью гибридного облака является его способность обеспечить высокую степень безопасности корпоративных приложений и данных, эффективную балансировку нагрузок на вычислительные ресурсы, системы хранения данных и сетевую инфраструктуру. В гибридном облаке за счет приемлемого уровня контроля над инфраструктурой и данными устраняются риски, связанные с использованием публичного облака. Чаще всего у внешнего провайдера можно получить приватную область с возможностью организовать безопасный сетевой доступ и сегментацию vLAN, а также проводить настройку межсетевых экранов. Гибридное облако позволяет компаниям самим определять политики информационной безопасности и решать, какое приложение будет размещаться в собственном ЦОД компании, а какое в облаке внешнего провайдера. Кроме того, оно предоставляет ИТ-департаменту инструменты для перемещения приложений и данных между публичным и частным облаками.
Как всегда, ключевым с точки зрения ИБ будет то, насколько в действительности выполняются установленные организационные процедуры ИБ, политики управления доступом и контроль над учетными записями.
– Что представляет собой российский рынок консалтинговых услуг по реализации гибридных облаков? Насколько он развит?
– На мой взгляд, рынок консалтинговых услуг по реализации гибридных облаков только набирает обороты. Сейчас его в целом характеризует большое количество предложений, но при этом отмечается нехватка сбалансированных, учитывающих специфику и сложные потребности крупных предприятий даже от именитых ИТ-интеграторов. Специалистов, имеющих реальный, а не теоретический опыт реализации подобных проектов для крупных заказчиков, единицы – и они на вес золота. Но спрос на подобные проекты явно растет.
– Появляются ли дополнительные требования к квалификации, компетенциям ИТ-персонала банка при внедрении гибридной облачной модели? Какие именно?
– Безусловно, при внедрении гибридной облачной модели появляются дополнительные требования к ИТ-персоналу. В первую очередь сотрудники должны не только понимать какие-то отдельные технологии, но и осознавать суть самой облачной парадигмы, всего стека применяемых технологий и подходов в целом. Кроме того, появляются новые требования к сотрудникам службы информационной безопасности.
– Как гарантируется в рамках гибридной модели устойчивость, непрерывность ИТ-поддержки бизнес-процессов?
– Известно, что для поддержания бизнес-процессов компании ее ИТ-служба обязана обеспечить высокий уровень доступности ИТ-сервисов и приложений. В гибридном варианте часть этой ответственности лежит на внешнем поставщике, поскольку значительной частью инфраструктуры (ЦОД, оборудование, гипервизоры, сервисные контракты, работа службы эксплуатации и т. п.), по сути, управляет не компания-заказчик, а поставщик внешнего облака. Поэтому важно осознавать, какой уровень доступности он может обеспечить в рамках заключенного договора.
За доступность сервисов, размещенных в собственно облаке компании, на 100% отвечает внутренняя ИТ-служба, и внутренний договор об обслуживании (SLA) ИТ с бизнесом может значительно жестче, чем внешний. В ФГ «Лайф» ситуация именно такая. Поэтому для гибридного облака необходимо четко установить критерии (такие как критичность приложения для бизнеса, особые требования законодательства, требования по доступности), по которым можно будет определять, какие сервисы могут размещаться только внутри, а какие во внешнем облаке, какие могут масштабироваться за счет внешнего облака, какие нет.
