Моя работа — проектирование решений в области виртуализации и внедрение частных «облаков» для российских компаний. Начну с того, что вообще такое частное «облако»:
- Это IT-сервисы на вашей территории.
- При этом это сервисы, эволюционно добравшиеся до «облака», то есть сервисы распределенных вычислений.
Зачем это нужно? Причин на практике четыре:
- Экономия на железе: «облако» позволяет крутить сотни проектов на одном наборе железа, когда как без такой инфраструктуры железа потребовалось бы минимум втрое больше. Ну и в будущем нет проблем с заменой железа.
- Экономия на лицензиях: так получилось, что лицензионные условия часто обозначаются не на пользователя, а на машину. А когда машина физически одна, а пользователей — 5-6, это серьезно дешевле.
- Требования к скорости развертывания инфраструктуры. Из правильного настроенного частного «облака» можно легко запустить новый офис в регионе, чуть ли не за несколько минут. Или масштабироваться без боли.
- Волшебный 152-ФЗ и ряд других нормативов: пока не всегда можно отдавать свои ПД на обработку кому-то третьему, требуется разворачивать фермы у себя.
Теперь давайте посмотрим, как это обычно делается и какие бывают грабли.
Кто заказывает частные «облака»?
Как правило — это крупные компании, которые уже достаточно зрелы по процессам. У них уже внедрен сервисный подход, но нужно все это автоматизировать частным «облаком». Сервисный подход — это когда каждая часть IT-сферы рассматривается как услуга для пользователя. Например, нужна виртуальная машина — просто отдали еще один экземпляр с нужными правами и настройками. Централизованно и унифицированно. И так далее.
Самый первый заказчик — IT-отделы
Как правило, IT-отделы — это первые, кто понимает, что нужно свое «облако». Обычно происходит так: они поднимают виртуальные машины по запросу для себя, коллег, подрядчиков (кстати, дать доступ подрядчику до своей инфраструктуры — одна из самых частых задач). В какой-то момент становится понятно, что нужно делать платформу — PaaS — и потом все это приходит к SaaS, когда нужная операция делается чуть ли не самим пользователем в один клик. Параллельно описываются все эти процессы и прикидывается их стоимость. Зачем? Потому что зная экономию, куда легче доказывать руководству необходимость такого решения. Появляются понятные для бизнеса деньги. Например, почтовый ящик стоит столько-то, в следующем году будет столько-то новых пользователей и так далее. Появляется главный фактор — цена. И, поверьте, многих несказанно радует переход на язык денег вместо языка «шаманов» обычного IT-департамента.
Большая головная боль — это тестовые среды
Один из основных сервисов для крупных компаний — автоматизация предоставления сред под разную разработку. Тестовые среды требуются почти под каждый крупный проект, потому что, например, в нефтегазовой, банковской или телекомовской среде нельзя оттестировать что-то новое на «сухих» данных. Нужно прогонять, например, по вчерашнему слепку базы в контролируемой среде и смотреть, что на выходе. Когда такой проект один, просто выделяется некий парк серверов, и все гоняется на нем.
Но когда проектов уже десяток — нужны виртуальные тестовые среды. Причем нужны позарез. Их надо развертывать, конфигурировать, убивать или морозить, чтобы они не ели ресурсы. Проектов много, на это уходит ручного труда очень много. Встает вопрос безопасности.
Инфраструктура компаний
Когда компания готова перейти на полностью сервисный подход к IT (а так делает большая часть компаний на Западе просто из-за экономической целесообразности), в частном «облаке» настраивается все необходимое обычным пользователям. Как правило, это почта, бекап, место на диске для хранения данных, виртуальные машины.
Отдельный вопрос — мощность для масштабирования. Например, для колл-центра с ярко выраженными сезонными пиками (туристического или, например, имеющего пик под Новый Год) логично не закупать массу железа и лицензий ради двух недель работы в году — они используют виртуальные ресурсы, которые очень легко масштабируются.
Пиковые задачи
В Big Data (вроде биллинга телекомов, расчета тарифов страховых и так далее) есть задачи, которые возникают раз в месяц и полностью убивают даже тяжелые сервера-молотилки. Например, один из известных мне расчетов шел на физическом оборудовании месяцы, после первого цикла виртуализации — недели, а теперь все свободные ресурсы их «облака» занимаются именно этим подсчетом (и при этом не тормозят остальные процессы) — и все проходит за дни.
Потом идут новые проекты
Предположим, банк запускает какой-то проект, про который совершенно непонятно, сколько он будет брать ресурсов. Непонятно потому, что стартап внутри компании новый, и никто не может сказать — будет это 500 человек, 1% от клиентской базы или вообще каждый второй клиент. Соответственно, логично не закупать сначала дорогое железо с одной стороны, но и страховаться от ожидаемого или неожиданного пика — ведь придется задорого менять инфраструктуру, если что. Поэтому здесь тоже логично все крутить в «облаке». Но не в публичном, так как речь о банке и 152-ФЗ.
SaaS для клиентов
Иногда случается, что компания не хочет разворачивать «облако» для миграции со своей архитектуры, но не против отдавать сервисы из него своим подрядчикам или клиентам. В этом случае запускается отдельное от общей инфраструктуры частное «облако», откуда, например, могут раздаваться рабочие места и доступы к важным данным в огромных рекламных агентствах или же откуда могут настраиваться защищенные доступы к банк-клиенту, бухгалтерии и эквайрингу для клиентов банков.
Необычный случай
В одной крупной энергетической компании ситуация была в целом стандартная — сотни дочерних обществ, множество филиалов, очень сложная структура отдельных компаний внутри объединения. Все это обслуживает одна IT-служба. Парни справляются, все настроено по уму, но есть одна проблема. Конкретно — за IT-услуги (например, виртуальные машины или место на серверах) нужно делать расчеты внутри объединения, а для этого нужно как-то выставлять счета. А делать это нереально сложно, потому что, никто не может чётко проверить, сколько ресурсов потрачено на тот или иной запрос. И предсказать тоже. В итоге они развернули и настроили частное облако. И предсказать тоже. В итоге они развернули и настроили частное «облако», которое позволило просто и прозрачно перейти к подсчетам ресурсов для каждого. Учитывая, что теперь каждый может взять и посмотреть в реальном времени сколько и за что он должен, споры пропали. Биллинг справедливый. Получился такой хороший финансовый арбитр, позволяющий привести все в норму. Ну и плюс они потом стали постепенно прикручивать другие функции к уже готовому «облаку».
У нас внутри компании одной из единиц расчета является процессорное время — например, каждый проект имеет квоту на использование ресурсов «облака», и не переходит ее. Квота определяется по приоритету проекта. Для нас это очень удобно, потому что еще завязано на систему менеджмента, где прямо при решении о важности проекта подцепляется все необходимое.
Вот как такое распределение может выглядеть из интерфейса управления:
А вот пример внутренних расчетов:
Как обычно внедряется частное «облако»?
На практике — с трудом. Основная проблема, с которой я сталкивался — это простое непонимание того, как все работает и чем может быть выгодно. Бывает, мне пишут из IT-отделов, просят сделать расчет, чтобы они его могли показать руководству. Берут свои расчеты, берут мои расчеты — и только две этих бумажки вместе (чтобы было и мнение сотрудника, и внешней компании) убеждают. Когда решение все же принято, шаги внедрения такие:
1. Сначала IT-службы обсуждают, что и как должно быть.
Формируется каталог сервисов, потом смотрим, какие куски уже реализованы, а какие нет. Например, выделение виртуальной машины по запросу — сервис не для конечного пользователя, а для разработчика или для подрядчика. Соответственно, он автоматизируется, детализируется, пишется SLA. Или расширение фермы на 100 пользователей — нужно делать связь с другой частью фермы. И так далее.
2. Каждый сервис детализируется.
3. Затем смотрим, что уже есть и можно использовать в развертывании «облака».
Например, есть сервисдеск-система. Все это прописывается в реалиях частного «облака».
4. Затем стандартные вещи.
Это выбор вендора, подсчет стоимости, точный финансовый план до копейки по железу, работам, лицензии на продукты для создания «облака», интеграции.
5. Ну и потом, непосредственно, работы.
Пример реализации
Расскажу про наш собственный опыт. Нам, как проектной компании, которая занимается разработкой новых решений или донастройкой коробочных решений, необходима среда разработки и среда для тестирования. До 2006-2007 года вся наша лаборатория состояла из железных серверов, то есть фактически под каждый из проектов нужно было сформировать спецификацию, где-то заказать или найти на складе сервера, привезти их, смонтировать, подключить. Если мощности не хватало, то это опять заказ, ожидание и привоз. Почти каменный век.
Потом появились платформы виртуализации VMware (здесь важно пометить, что альтернативы ей на тот момент де факто не было). Мы решили закупить несколько мощных серверов, поставить на них VMware Server, и облегчить всем жизнь. После этого действительно стало полегче с точки зрения скорости развертывания, но не сильно. Потому что все это развертывалось фактически вручную, даже несмотря на наличие механизмов по управлению этими виртуальными серверами, все равно наши админы большую часть работы делали сами: принимали заявки, выделяли вычислительные мощности, вручную отслеживали насколько тот или иной сервер сейчас загружен. Зачастую возникали ситуации, что конкретный железный сервер настолько был загружен виртуалками, что приходилось его вручную оптимизировать, переносить виртуалки с сервера на сервер. Все это жутко мешало работе проектных команд. Они заказывали определенную мощность, но получить ее не могли.
Вывод: виртуализация хороша, но ручное управление – плохо. По решению инженера, которое принималось по принципу «пол-палец-потолок», тот или иной сервер был менее загружен, чем другой. Только потому, что на нем сейчас не запущены те виртуалки, которые на нем стоят. А предугадать, что сейчас этот проект войдет в горячую фазу и все эти виртуалки стартуют, было практически невозможно. Нужен был очень умный инженер, который мог бы уточнять планы по проектам. А когда их сотни одновременно, это та еще задача. Многие перестали заказывать виртуалки, потому что работать так было очень сложно, и заказывали реальное железо, всеми правдами и неправдами. Но понятно, что повесить железный сервер на проект – это существенно дороже. В разы, если не на порядки.
Поэтому конечно, когда появилась возможность поставить платформу управления, мы ее поставили. Выбрали HP, отчасти потому, что у нас был большой опыт работы с их системами, отчасти, потому что из реальных конкурентов HP в плане управления «облаком» на тот момент был только BMC. Но под наши разработческие задачи, чтобы пользователи могли сами выбирать себе параметры стенда, больше подходил HP с точки зрения гибкости управления. Когда мы все это дело автоматизировали, то уже не нужно думать, где крутится виртуалка, она сама переносится с одной вычислительной мощности на другую, для того чтобы поддерживать необходимый уровень производительности. Если какой-то определенный необходимый квант мощности превышен, то она сама добавляет еще и еще. Теперь наши инженеры практически не заказывают железные сервера.
Потом уже мы доработали эту систему управления коннектором к публичному «облаку» (в Amazon и к нашему собственному публичному «облаку» — прикрутили и возможность выбора), чтобы можно было показать заказчику получившееся решение в любом месте, где есть интернет. У CA, например, по умолчанию есть прямой коннектор к публичным «облакам». Поэтому если кто-то не хочет заморачиваться на доработку, в некоторых случаях можно выбрать CA.
Сейчас в нашем частном «облаке» порядка 1000 стендов, понятно, что они не все активированы, но в среднем каждый пятый работает постоянно. Сервера самые разные, с точки зрения «облака» на самом деле не очень важно какие, могут быть IBM Blade или HP Blade. Подключившись к «матрице» он просто становится еще одной каплей в море. Затраты конкретного стенда сейчас автоматически, благодаря внутренней системе биллинга, падают на конкретный проект. С точностью до копейки. Не больше, не меньше. Причем с учетом простоя, то есть если ты останавливаешь виртуалку на какое-то время, то и не платишь. Конечно, небо и земля, по сравнению с тем, как это было раньше, когда все затраты лаборатории каким-то магическим и совершенно непрозрачным образом распределялись по департаментам, направлениям, группам.
Но пойдём дальше.
Масштабирование
Обычно делается очень просто. Есть предопределенные блоки: автоматизация охватывет инфраструктурный уровень. Все, по большей части, решается установкой дополнительных юнитов в стойки в случае чего. Если задача не очень большая — то скорее всего допоставка серверов, систем хранения, связка воедино. Если крупная — развертывание еще фермы и организация связи между ними. Соответственно, легко строить прогнозы вроде «в следующем году у нас будет на 30% больше пользователей, вот расходы».
Архитектура
На высоком уровне она общая, одинаковая для ряда производителей. Дальше выбираются конкретные решения как из коммерческих так и из опенсорсных реализаций, идет диалог о деталях, железе и так далее. Определяем, какие функции исполняет какой компонент какого производителя.
Вот про управление:
ПРИМЕР АРХИТЕКТУРЫ НА ПЛАТФОРМЕ BMC CLOUD LIFECYCLE MANAGEMENT
ПРИМЕР АРХИТЕКТУРЫ НА ПЛАТФОРМЕ IBM CLOUD SERVICE PROVIDER PLATFORM (CSP2)
ПРИМЕР АРХИТЕКТУРЫ НА ПЛАТФОРМЕ CA AUTOMATION SUITE FOR CLOUD
Схема с общими составляющими инфраструктуры частного «облака»
Переход к гибридам и публичным «облакам»
В своем частном «облаке» заказчики часто оттачивают механизм оказания сервисов. Затем, когда они понимают чувствительность данных, они уже спокойно могут использовать облака партнеров, гибриды или публичные. Например, банки отрабатывают важные данные в своей собственной безопасной среде — у них появляются навыки, новые процедуры безопасности, автоматизация и так далее. Когда становится понятно, что нужны новые ресурсы, и в целом их использование не является угрозой ИБ, используются ресурсы публичных облаков — это просто дешевле, чем разворачивать еще ферму внутри себя.
Вопросы
Все. Я готов ответить на ваши вопросы в комментариях или в почте IShumovskiy@croc.ru. Если это требуется, могу прислать примерные расчеты вариантов внедрений для вашей ситуации.
Если хотите больше практических деталей — завтра с 10:30 до 15:30 у нас в офисе пройдет семинар. Будем рассказывать в подробностях про архитектуру «облака» и «облачный» ITSM, про опыт переноса в частное «облако» услуги «service desk», про пред-биллинг и решения для учета ресурсов, о том, как управлять частными «облаками», какие решения для этого есть и что лучше выбрать в том или ином случае, в целом про аппаратные и системные решения, необходимые для развертывания частного «облака», про защиту «облачных» данных и еще много всяких полезностей. Будет и специальный гость из Forrester — Лорен И. Нельсон, аналитик по работе со специалистами в области ИТ-инфраструктуры и операций. Тоже обещает поделиться некоторыми секретами. В общем, приходите, это полезная ачивка. Зарегистрироваться на бесплатное участие можно здесь.
Автор: Ishumovsky
