Дорога в облака

Как подготовить ЦОД для перехода к частному облаку, какие программные и аппаратные платформы выбрать? Когда выгоднее развертывать публичные облачные сервисы, а в каких случаях — частные облака? Каковы основные этапы внедрения облачной модели, какую ее разновидность следует предпочесть тем или иным заказчикам? Какие проблемы подстерегают на пути в облака? На эти вопросы мы попросили ответить экспертов: Антона Шумилова — ведущего специалиста отдела комплексных решений группы «Астерос», Эдуарда Бавижева — руководителя группы виртуализации DataLine, Ивана Шумовского — руководителя направления инфраструктурных решений «Крок», Максима Березина — руководителя виртуального дата-центра «Крок», Максима Захаренко — генерального директора «Облакотеки».

Журнал сетевых решений/LAN: Какие организационные и технические задачи необходимо решить при переходе к облачной модели?

Антон Шумилов: Переход к частному облаку, как правило, подразумевает две составляющие: техническую часть, то есть настройку программно-аппаратной платформы для виртуализации, и организационную, в ходе которой выстраиваются процессы взаимодействия подразделений компании, отвечающих за ИТ.

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

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

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

Иван Шумовский: Чтобы перейти к частному облаку, следует провести ряд технических и организационных мероприятий: внедрить программные и аппаратные средства (сегодня все известные производители предлагают продукты с маркировкой «cloud»), выработать сервисный подход, унифицировать механизм предоставления сервисов, проработать вопросы информационной безопасности. Переход к частному облаку — прежде всего организационный процесс.

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

Максим Захаренко: Современные коммерческие продукты VMware и Microsoft многофункциональны и подходят для построения большинства облачных платформ. Но главное не это, а правильная настройка многочисленных компонентов, поэтому частное облако помимо аппаратно-программного комплекса требует обязательного наличия специалистов по его обслуживанию. Без них невозможно даже приступить к планированию такого перехода.

LAN: Какую именно облачную модель стоит выбрать?

Шумилов: Небольшие компании обращаются к публичным облакам, когда иметь свою серверную оказывается накладно. Такое решение избавляет от необходимости модернизации платформы и позволяет сократить расходы на оплату труда собственных администраторов. Крупные и многие средние предприятия предпочитают частные или гибридные облака. Обычно у них уже имеется развитая ИТ-служба и им легче управлять своим частным облаком, а не переносить всю вычислительную инфраструктуру в публичное. В этом случае скорость реакции на изменение бизнес-процессов или внедрение нового продукта всегда выше, чем в публичном аналоге, да и вопрос безопасности стоит не столь остро. Иногда при подсчете стоимости услуг IaaS выясняется, что содержать собственное облако дешевле. В качестве компромисса можно использовать гибридное. Мотивация здесь одна — финансовая.

Бавижев: Если говорить именно о финансовой стороне, то имеют значение несколько факторов: ориентированность компании на сокращение CAPEX в пользу OPEX или, напротив, на единовременные инвестиции; наличие штата специалистов для обслуживания облака; возможность подключения к каналам надежных поставщиков услуг. Гибридная модель предпочтительна в том случае, когда основная часть инфраструктуры может быть размещена в публичном облаке, но для части системы требуется выделить физическое оборудование.

Шумовский: Что выгоднее — частные или публичные облака? Однозначного ответа нет. Каждая организация должна не только подсчитать, во сколько ей обойдутся желаемые сервисы, но и оценить риски ИБ. Исходя из опыта использования публичного облака «Крок», можно сказать, что многие крупные заказчики выносят в публичное облако сервисы для конечных клиентов либо сервисы, с которыми работают внешние/удаленные сотрудники (например, тестовые среды). А основные системы для штатных сотрудников оставляют в частном облаке.

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

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

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

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

Шумовский: Заказчику следует выстроить бизнес-процессы, обеспечить их ИТ-процессами, наладить контроль над ресурсами, выяснить, как они связаны с сервисами ИТ, виртуализировать инфраструктуру (серверную, сетей, систем хранения данных). После этого можно объединять и интегрировать все компоненты в единое облако.

LAN: Какие аппаратные и программные платформы оптимальны для частного облака?

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

Шумовский: Прежде всего программные и аппаратные средства должны удовлетворять критериям взаимной совместимости и отвечать требованиям бизнеса. Например, важно, чтобы система управления облаком поддерживала используемые в компании платформы виртуализации (гипервизоры). Необходимо учитывать наличие систем ИБ, стоимость самого решения, оценить затраты на его эксплуатацию и сопровождение. Одним словом, оптимальная платформа должна иметь наилучшее для конкретной компании соотношение цена/качество.

Захаренко: Современные платформы близки по своим возможностям. Их отличия оказываются важны в редких случаях. Поэтому основа выбора — кадры (опыт эксплуатации конкретной платформы) и бюджет.

LAN: Какие преимущества и недостатки характерны для готовых к развертыванию интегрированных «платформ для облаков»? Они должны быть универсальными или специализированными?

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

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

Березин: Чем более унифицированной является облачная платформа, тем легче ее обслуживать и поддерживать. И наоборот, чем больший «зоопарк» наблюдается в части аппаратных и программных средств, тем чаще возникают проблемы, сложнее эксплуатировать решение, выше риски инцидентов, связанных с работой облака. «Крок» старался сделать свою публичную облачную платформу максимально универсальной, охватывающей широкий перечень задач, стоящих перед крупными предприятиями и компаниями из сектора SMB. Однако некоторые приложения предъявляют весьма специфические требования, (например, те, что работают с графикой), и для них могут потребоваться отдельные узлы с GPU.

Захаренко: Готовые интегрированные системы хороши, если их встроенной мощности достаточно на обозримое будущее. В противном случае вступают в силу ограничения по масштабированию и модернизации. Между тем частное облако — это сложное многоуровневое взаимодействие различных физических устройств и инфраструктурного ПО. Поскольку и то и другое находится в постоянном развитии, реальная совместимость достигается не всегда, что может приводить к существенным сбоям. В этом смысле протестированные наборы дают некую гарантию качества.

LAN: Какова роль системы автоматизации?

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

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

Шумовский: К системе автоматизации и управления облаком предъявляются достаточно высокие требования. Такая система становится ядром всей платформы, поэтому ее выбор критичен — необходимо определиться с набором функций и проверить совместимость системы с остальными компонентами облака. В качестве варианта можно использовать коммерческие платформы или построить систему на базе открытого ПО. В любом случае стоит реализовать пилотный проект, отладить несколько процессов, пройти обучение и привыкнуть к работе в такой среде.

Захаренко: Я не разделяю облачную платформу и систему автоматизации. Система автоматизации и самообслуживания является элементом облачной платформы, причем неотъемлемым.

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

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

Шумовский: Основная проблема — нехватка у ИТ-служб времени и предметных знаний для анализа корпоративных ИТ-сервисов, стандартизации, автоматизации ИТ. Конечно, существуют и технические проблемы, например, «зоопарк» оборудования, исторически сложившийся в компании, а также отсутствие целостных систем управления и мониторинга. Помехой становится и недостаточно продуманный план развития ИТ-процессов.

Захаренко: Проблема в том, что все плюсы облака — эластичность, учет, эффективность, контролируемость, консолидация, безопасность — очень редко напрямую востребованы заказчиком. Подлинная «облачность» полученного решения зависит от зрелости и грамотности ИТ-специалистов, принимающих участие в подготовке перехода в облачную среду.

Сергей Орлов — ведущий редактор «Журнала сетевых решений/LAN». С ним можно связаться по адресу: sorlov@lanmag.ru.