На пути к облаку

LAN: Как подготовить ЦОД к переходу к частному облаку, какие программные и аппаратные платформы вы считаете оптимальными для этой цели?

Кирилл Ларин: Я бы выделил следующие шаги (подразумевая, что мы уже знаем, зачем это делаем с экономической точки зрения):

• инвентаризация «железа», его группирование по мощностям, принятие решения о необходимости обновления парка;
• подготовка персонала с соответствующей компетенцией (обучить свой, нанять новый);
• интеграция облачного решения, причем каких-либо отличий от обычного проекта я не вижу.

Мировые тенденции в области облачных вычислений таковы, что обычно используется недорогое «железо» неизвестного бренда (no-name), простое сетевое оборудование. При этом обеспечивать высокую доступность (high-availability) на уровне сетевых интерфейсов, сетевых портов и коммутаторов нет смысла: проще потерять одну стойку, чем недели городить огород с Bonding или Spanning Tree.

Из моего опыта (шесть заказчиков в Корее, Австралии, США, Дании, России и Франции) наиболее перспективной и востребованной платформой IaaS является OpenStack. Причина, на мой взгляд, заключается в том, что по этой технологии проще найти компетентного интегратора. Самой удачной системой управления я считаю Eucalyptus, так как она наиболее точно копирует бизнес-логику AWS, а это нравится заказчикам. Хотя часто бывает, что систему управления проще написать самому (хотя бы простейший среду для разных гипервизоров).

LAN: В каких случаях публичные облачные сервисы выгоднее действительно развертывания частного облака на площадке заказчика, а в каких лучше создавать собственные облака?

Кирилл Ларин: Публичные облака выгоднее, если нужно запускать множество копий какой-либо системы на короткое время. В данном случае непросто определить прямую выгоду, приходится учитывать различные аспекты и пытаться сравнивать их, приводя один к другому. В любом случае нужно использовать предлог “и”, а не “или”.

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

Например, на утреннем совещании возникла красивая идея, но, чтобы ее проверить, требуется копия коммерческой платформы с другой конфигурацией. Публичное облако идеально подходит в подобной ситуации. Вы запускаете копию (или несколько копий) «боевой» системы на 1-2 дня, смотрите, что происходит, и выключаете. В частном облаке такое развертывание, безусловно, дороже.

Однако, как только в процессе начинает наблюдаться что-либо постоянное, лучше переносить это на собственные ресурсы, так как при работе в режиме 24/7 сопоставимые ресурсы в своем облаке гораздо дешевле, чем в публичном. Также важно жестко контролировать использование публичных ресурсов в компании, иначе можно быстро потерять контроль над расходами.

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

LAN: В какой степени переход к частному облаку - технический, и в какой - организационный процесс?

Кирилл Ларин: С технической точки зрения, частное облако - это всего лишь создание системы автоматического управления над набором виртуализированных мощностей. Обычно проблемы чаще возникают в организационной области.

LAN: Какие преимущества и недостатки характерны для комплексных интегрированных (конвергентных) платформ - готовых к развертыванию решений, объединяющих серверы, системы хранения и сетевые компоненты?

Кирилл Ларин: Если речь идет о решениях, типа vBlock от VCE или аналогичных предложениях Oracle, то их недостаток состоит в цене и в привязке к конкретному вендору. Преимущество же таких решений заключается в возможности транслировать SLA-обязательства от вендора до заказчика с определенной гарантией, что делает их удобными для критичных для бизнеса компонентов, а также для компаний, где экономия не является приоритетом. Также надо понимать, что создавая такие решения, крупные вендоры, скорее, пытаются угнаться за прогрессом и не оказаться в ситуации, когда их бизнес начнет стремительно терять капитализацию и маржинальность.

LAN: Должны ли такие платформы быть универсальными или специализированными, ориентированными на выполнение конкретных приложений и нагрузок (баз данных, бизнес-аналитики, Web-приложений и др.)?

Кирилл Ларин: Да, должны, иначе придется навязывать клиентам, в том числе, и  внутрикорпоративным, гранулярность мощностей. Учитывая это, самые крупные игроки на данном рынке (Amazon Web Services) пошли на такой шаг (пример - отдельный гипервизор для Oracle в AWS).

LAN: Некоторые вендоры предлагают для развертывания облаков так называемые эталонные или референсные архитектуры. В чем преимущества и недостатки такого подхода? Насколько он перспективен?

Кирилл Ларин: Речь идет не о перспективности подхода, а об устоявшейся терминологии. Так уж сложилось, что несколько компаний, вроде Amazon Web Serveices, оказались своего рода законодателями мод в облачных технологиях, и их бизнес-модель была скопирована множеством других компаний. Оперируя принятыми терминами, легче объяснить свое преимущество конечным заказчикам.

LAN: Какова роль так называемых Ethernet-фабрик в облачной платформе и в облачном ЦОД?

Кирилл Ларин: Ethernet-фабрика позволяет создавать LAN и SAN на общем сетевом оборудовании. Плюсы этой технологии – ее универсальность, минус - цена. Хотя сама по себе технология неплохая, но рентабельность перехода на нее - большой вопрос.

LAN: Что должно предшествовать выбору заказчиком облачной платформы?

Кирилл Ларин: Прежде всего, требуется четкое понимание того, что нужно в итоге получить. По собственному опыту могу сказать, что переход на облачные технологии не приносит прямых монетарных выгод, но имеет множество побочных преимуществ.

LAN: Когда предпочтительнее переход не к частному облаку, а к модели "ЦОД + публичное облако" (гибридная модель)?

Кирилл Ларин: Периодически возникают задачи, которые можно и нужно выполнять на публичных мощностях, поэтому переходить на гибридную модель следует как можно раньше (например, интегрировать AWS или Rackspace в ваш OpenStack или Eucalyptus).

LAN: С какими основными проблемами приходится сталкиваться заказчикам на пути в облако?

Кирилл Ларин: На мой взгляд, проблемы заключаются в следующем:

1. Неправильное целеполагание. Многие заказчики ждут от облачных технологий каких-либо чудес и переносят свои ожидания на внедренца. Соответственно, вместо реальных работ приходится тратить время на обучение заказчика тому, "как устроен мир”;

2. Следующая проблема вытекает из первой и заключается в попытке утилизации большого количества имеющихся мощностей, не всегда современных, что приводит к появлению целого “зоопарка”;

3. Нехватка квалифицированного персонала, которая ощущается во всех областях, по мере того, как экономика страны все больше интегрируется в ИТ-экосистему.

4. Особенность менталитета. В странах Восточной Европы, Китае, Индии, как правило, особое отношение к идеям, пришедшим с Запада, и, прежде чем применять их на практике, обычно нужно время, чтобы «переварить» их. Облака как раз и являются одной из таких идей. Кроме того, в России это осложняется еще и тем, что в нашей стране не хватает ИТ-специалистов, обладающих необходимыми знаниями и навыками для работы с облачными технологиями.