Rambler's Top100
 
Статьи
Максим ГРЕЧНЕВ  23 декабря 2020

Как раскрыть потенциал частных облаков

В последнее время бизнес активно использует публичные облака. Однако почти у любой относительно крупной компании есть потребность в собственной локальной инфраструктуре, и тогда оптимальным решением становится частное облако. 

Новые вызовы для бизнеса – новые задачи для ИТ

Как бы банально это ни звучало, time to market заставляет меняться компании из любого сектора экономики. Бизнес хочет быстро получать довольных клиентов и считает своим основным драйвером создание уникальных высокотехнологичных продуктов и услуг с опорой на информационные технологии. В результате потребности бизнеса становятся задачами ИТ. Этот вывод справедлив не только для компаний сегмента B2C. Даже в крупных B2B-компаниях и в таких консервативных отраслях, как металлургия и сельское хозяйство, видят огромный потенциал в сокращении издержек за счет цифровизации бизнес-процессов. И внутренние пользователи в компаниях не менее требовательны к скорости и качеству информационных сервисов, чем заказчики и партнеры.

Разработка ПО тоже не стоит на месте и подстраивается под задачи бизнеса: меняется методология (agile-революция, DevOps-практики), появляются новые технологии (микросервисная архитектура, контейнеризация).

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

Публичные облака: плюсы и минусы

Сегодня время компании все чаще размещают свои ресурсы у облачных провайдеров. Российские облака достигли достаточно высокого уровня развития и продолжают активно развиваться. Однако почти у любой относительно крупной компании есть потребность в собственной локальной инфраструктуре. Причины могут быть разными:
  • желание обеспечить безопасность хранения и доступа к конфиденциальным и секретным данным, в том числе в соответствии с требованиями регуляторов (к публичным облакам все еще есть вопросы, которые остаются без ответа);
  • наличие высокопроизводительных бизнес-критичных систем, чувствительных к сетевым задержкам и облачным «переподпискам»;
  • унаследованная инфраструктура и вопросы совместимости ПО;
  • выбор компании в пользу CAPEX-модели затрат;
  • владение собственным ЦОДом, которое становится дешевле, начиная с определенного размера инфраструктуры.
Поэтому в публичные облака обычно выносят временные, некритичные процессы, обезличенные данные. Эталонный пример таких задач – тестовые среды (особенно для нагрузочного тестирования), которым необходимо быстро предоставить много ресурсов на короткий срок в период подготовки к релизу.

Большинство публичных облаков соответствуют всем критериям общепринятого определения облака, предложенного в свое время NIST: есть удобный портал самообслуживания с гибкой ролевой моделью, программный интерфейс для автоматизации, различные варианты организации доступа через сеть, учет потребления ресурсов и биллинг. Но самое главное – обширный каталог сервисов, которыми чаще всего и привлекают своих клиентов публичные облака. К хорошему быстро привыкаешь, и это удобство в итоге становится необходимостью. Поэтому, когда встает вопрос создания собственной инфраструктуры, к ней предъявляются такие же повышенные требования. 

Многие молодые и громкие стартапы могут возразить: «Да у нас Kubernetes – где хотим, там и размещаемся! Хоть в Amazon, хоть на голом железе». Да, Kubernetes как универсальный формат инфраструктуры современных приложений проблему частично решает. Но что делать компаниям более крупным и зрелым? Создавать свое частное облако, стараясь минимизировать дополнительные инвестиции: переиспользовать существующее оборудование, лицензии и компетенции. Правильный первый шаг, который де-факто стал стандартом, – объединить вычислительные ресурсы под управлением платформы виртуализации. Она обеспечивает оптимизацию использования, некоторую эластичность и призрачную автоматизацию. 

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

Потенциал частных облаков

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

«Серебряной пули» не существует. В зависимости от уровня зрелости и потребностей компании переход в облако может проходить по-разному. Мы как интегратор выступаем за комплексный последовательный подход: сначала определяем цели и задачи и формализуем требования к процессам, а выбор конкретных инструментов и вендоров оставляем на последний этап. Внедрять решение так же лучше итерационно. И с точки зрения охвата: сначала реализовать пилотный проект на одной команде или системе, затем тиражировать на остальную часть инфраструктуры. И по функционалу: сначала создать базовую облачную IaaS-платформу, затем постепенно наполнять каталог услуг сервисами безопасности, резервного копирования, DBaaS, LBaaS, CaaS, PaaS, а также расширять возможности платформы: мониторинг, биллинг, интеграция с DevOps-инструментами и т.д. Такой подход позволяет получать непрерывную обратную связь и гибко работать с сопротивлением изменениям.

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

Как мы создавали свое частное облако

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

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

Регламент согласован, начинаем проектировать. Разработали каталог услуг и целевую архитектуру. «Раздувать» каталог на первом этапе не стали – ограничились базовой услугой «виртуальная машина» и самыми востребованными образами операционных систем. Ключевые принципы, которых мы придерживаемся при создании архитектуры во всех наших проектах независимо от выбранного вендора, таковы:
  • управление облаком физически отделено от рабочей нагрузки, в том числе по сети – так мы устраняем взаимное влияние и сохраняем доступ к среде управления при сбоях в менее прогнозируемой продуктивной среде;
  • для критической нагрузки, к которой относится и среда управления, используется принцип N + 1 – рассчитываем сайзинг так, чтобы при отказе одного элемента система продолжала функционировать без потери производительности.
Итоговый сайзинг нас не устроил: для управления со всеми служебными сервисами, включая домен и резервное копирование, потребовалось больше вычислительных ресурсов, чем мы ожидали. Забегая вперед, скажем: опасения оказались напрасны – облачная модель, грамотно разработанный процесс и инструменты автоматизации окупили все накладные расходы.

Наконец система создана и работает, пользователи имеют доступ к порталу самообслуживания и управляют своими существующими машинами, но заказывать новые пока нельзя – каталог услуг еще пустой. Начинается самый важный и трудоемкий этап – воплощение регламента в жизнь и наполнение каталога услуг. С момента запуска мы написали огромный объем инфраструктурного кода. Сейчас каталог включает порядка 30 отдельных или сопутствующих сервисов формата Anything-as-a-Service: доменное имя и технологический пользователь, резервное копирование и восстановление, сетевой балансировщик и доступ в интернет, база данных и веб-сервер. Можно даже заказать свою собственную виртуальную подсеть, не говоря о различных версиях ОС и кастомизированных образах с возможностью их загрузки в каталог без участия администратора. Процесс разработки не останавливается до сих пор. Периодически мы проводим опросы пользователей и анализируем те или иные показатели, чтобы сделать облако еще быстрее и удобнее.

Какие выгоды от развития частного облака получает бизнес

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

Создание «правильного» частного облака позволило компании:
  • усилить контроль за использованием ресурсов. Теперь для нас не существует понятия «теневая ИТ-инфраструктура» – все ресурсы и их владельцы как на ладони;
  • сэкономить вычислительные ресурсы. В процессе миграции убрали 10% ненужных машин, после истечения первого планового срока аренды не продлили аренду еще для 30% – общая экономия с учетом дополнительных затрат на среду управления составила порядка 30%;
  • экономить время инженеров. Мы увеличили скорость развертывания стендов приблизительно в пять раз за счет автоматизации большинства типовых операций;
  • повысить защищенность инфраструктуры. Теперь доступ к сети ограничен и автоматизирован, большинство образов ОС и ПО проверены и стандартизированы;
  • снизить влияние человеческого фактора. Конфликты IP-адресов, доменных имен или ошибки других ручных настроек сведены к минимуму;
  • повысить лояльность сотрудников, ведь пользоваться ресурсами компании стало действительно удобнее.
Все это дает бизнесу возможность быстрее выводить продукты на рынок, повышать лояльность конечных пользователей, привлекать новых клиентов и значительно сократить капитальные и операционные затраты. Но для того чтобы получить эти выгоды на деле, недостаточно выбрать лучший продукт на рынке – для его глубокой кастомизации нужен реальный опыт, компетенции, а также время, которые не всегда есть у внутренних ИТ-команд.

Максим Гречнев, руководитель отдела управления ИТ-услугами, «ЛАНИТ-Интеграция» (ГК ЛАНИТ)
Поделиться:
Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!