Платформа для облака

Облако — это новый этап в эволюции ЦОД, состоящий в переходе от консолидации и виртуализации на более высокий уровень. Его целью является реализация «эластичных» платформ с набором масштабируемых, динамически предоставляемых сервисов ИТ. Управление ресурсами и автоматизация осуществляются поверх слоя виртуализации, а ресурсы различного типа доставляются скоординированно.

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

ОТ ЦОД К ОБЛАКУ: ПОДГОТОВКА К ПЕРЕХОДУ

Частное облако позволяет унифицировать и стандартизировать предоставление сервисов внутри компании. В общем случае подготовка ЦОД к переходу в облако потребует анализа всего ПО (прикладных сервисов) на предмет возможности и необходимости работы в виртуальной инфраструктуре. К тому же весь центр данных с его унаследованным оборудованием превратить в частное облако не удастся.

«Необходимо понимать, что облако — не технология, а модель и подход к потреблению ресурсов и к их предоставлению. Технология, предполагающая возможность создания облака, — это виртуализация, — объясняет Георгий Гаджиев, эксперт по информационной инфраструктуре Microsoft в России. — Поэтому первый вопрос, на который необходимо ответить, — внедрена ли виртуализация в ЦОД? Далее надо описать структуру ИТ-процессов, бизнес-приложений и сервисов, предоставляемых ИТ-подразделением своим внутренним клиентам».

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

«Переход к частному облаку — не просто смена парадигмы предоставления ресурсов или услуг, — объясняет Кирилл Терешенко, руководитель группы технических экспертов IBM PureSystems в России и СНГ. — Это решение, которое изменяет стратегию развития ИТ в любой компании. Однако приступать к построению частного облака имеет смысл только при наличии четкого понимания, какие возможности даст бизнесу создание облачной инфраструктуры. Что же касается подготовки к этому переходу, основные требования давно известны — инфраструктура должна быть консолидированной и стандартизированной».

«Прежде всего нужна трансформация — не технологическая, а «в головах», — подчеркивает Антон Жбанков, руководитель направления облачных инфраструктур, «EMC Россия и СНГ». — Принципиальным является желание и готовность бизнес-подразделений работать с ИТ по облачному принципу. Технологии вторичны. На 80% переход к облачной модели — это организационные изменения. Если сотрудники компании не готовы работать по-новому, никакие технологии не помогут».

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

«При переходе к облакам практически всегда необходимо осуществить интеграцию новых и унаследованных систем, что не всегда удается сделать без проблем — для этого требуется, чтобы облачная система предоставляла соответствующие программные интерфейсы, — поясняет Константин Анисимов, директор по маркетингу и партнерствам компании Parallels. — Кроме того, в случае публичных облаков чем сложнее облачная система, тем труднее перейти от одного провайдера к другому и перенести данные».

«Очевидно, в первую очередь необходимо определиться с целями и KPI проекта — за счет чего он будет окупаться или какие существенные качественные преимущества компания хочет получить, — уверен Владимир Ткачев, технический директор VMware в России и СНГ. — Необходимо выполнить тщательный аудит текущей инфраструктуры и привести ее в соответствие с лучшими практиками. Затем вместе с внедрением облачных технологий следует провести организационные преобразования, которые обеспечат соответствие корпоративных бизнес-процессов облачной модели потребления ресурсов. И конечно, нужно постоянно контролировать происходящие в облаке изменения».

«Требуется четко понимать, чего хочется достичь. По собственному опыту могу сказать, что переход на облачные технологии не приносит прямых монетарных выгод, но имеет множество побочных преимуществ», — рассказывает Кирилл Ларин, ведущий системный архитектор компании Mind. При подготовке ЦОД к переходу в облако (если такой переход уже обоснован экономически) он предлагает идти по следующему пути: инвентаризация «железа», группирование по мощностям, принятие решения о необходимости обновления парка; подготовка персонала с соответствующей компетенцией (обучить своих сотрудников или нанять новых); интеграция облачного решения (аналогично обычному проекту).

ВЫБОР ПЛАТФОРМЫ

«Выбор аппаратной платформы должен основываться на понимании и наличии стратегии развития компании, без чего строительство облачного ЦОД невозможно. Если нет понимания того, в каком направлении будет двигаться компания, то, скорее всего, вместо облачного ЦОД появится «лоскутная» виртуализация и автоматизация. Что касается выбора программной платформы, существует большое количество решений, позволяющих создавать облачные среды под разные нужды заказчика. Наиболее востребованы продукты, нацеленные на реализацию модели IaaS и PaaS, — замечает Кирилл Терешенко. — В качестве примера можно привести семейство IBM SmartCloud. Оно не просто позволяет строить облачные среды, которые одновременно включают в себя разные аппаратные платформы CISC и RISC, но и поддерживает разные средства виртуализации, такие как Microsoft Hyper-V, VMware, KVM и PowerVM. Кроме того, это решение интегрировано с платформой OpenStack, что позволяет создавать гибкие среды на базе открытых стандартов».

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

«С технической точки зрения частное облако представляет собой систему автоматического управления набором виртуализированных мощностей, — поясняет Кирилл Ларин. — Облачная технология — это и есть система автоматизации виртуализированных ресурсов». С ним согласен Константин Анисимов: «Автоматизация — неотъемлемая часть облачной системы, без нее попросту нет никакого облака. Она более сложна во внедрении, чем виртуализация».

«С программной платформой все не так просто, как это может показаться на первый взгляд. Может сложиться обманчивое впечатление, что, выбрав любое из многочисленных предложений (ПО для создания облаков), заказчик получит некое «облако из коробки», затраты на развертывание и эксплуатацию которого будут минимальны, а выгода очевидна. Чтобы правильно выбрать программную платформу, надо понять, каких результатов компания хочет достичь и насколько важно снижение затрат на администрирование и сопровождение инфраструктуры, которые, согласно публикуемым данным, превышают 60% от всего бюджета подразделений ИТ», — поясняет Кирилл Терешенко.

Несомненно, нужно учитывать, в каком направлении будет развиваться ЦОД. Ограничатся ли разработчики моделью IaaS или в дальнейшем планируется переход к PaaS, SaaS либо гибридным моделям? Только ответив на эти вопросы, можно построить действительно эффективный облачный ЦОД. В противном случае попытка перехода к облачной модели может оказаться неудачной либо объемы ресурсов, направляемых на введение в эксплуатацию и дальнейшее сопровождение, потребуются большие, чем планировалось изначально. При этом приходится принимать во внимание много специфических нюансов — например, как указывает Робертас Балкис, препятствием может стать вопрос лицензирования программного обеспечения: «Некоторые имеющиеся лицензии на ПО, — замечает он, — могут стать ограничением при перемещении систем в облако». (О других потенциальных проблемах см. раздел «Сложности перехода».)

Рисунок 1. Программно-аппаратные комплексы IBM PureSystems сочетают в себе гибкость универсальных систем и эластичность частного облака. Вычислительные ресурсы (серверы x86 и Power), системы хранения данных (IBM Storwize V7000 с Easy Tier), сетевые соединения, средства виртуализации (различные гипервизоры) и управления (IBM Flex System Manager) оптимизируются для выполнения определенной рабочей нагрузки и предусматривают интегрированные средства управления всей системой.

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

«Выбор оптимальной платформы зависит от того, какое решение (с точки зрения степени его готовности к развертыванию и эксплуатации) необходимо заказчику, — подчеркивает Владимир Ткачев. — Конечно, можно строить облако на основе «бесплатных» или открытых решений, вкладывая деньги в их развитие и собственные наработки. Для компаний с амбициями и возможностями Google или Facebook этот путь оптимален. Для всех остальных, скорее всего, следование такому подходу окажется слишком затратным и по времени, и по финансовым вложениям, а результат будет непредсказуем».

ИНТЕГРИРОВАННЫЕ РЕШЕНИЯ

Рисунок 2. Мировой рынок конвергентных интегрированных систем (по данным Gartner за II квартал 2012 года).

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

Рисунок 3. Базовая конфигурация Dell Active System 800, флагмана семейства интегрированных решений vStart, включает ПО VMware vCenter 5.1, VMware ESXi 5.1 с Dell Management Plug-in for VMware vCenter, программный пакет Dell OpenManage Essentials и VMware vCloud Connector. Решение позволяет многократно ускорить развертывание инфраструктуры VDI и частных облаков.

«Интегрированная конвергентная инфраструктура — единая система от одного поставщика, собранная на заводе и протестированная там же. Это не самый дешевый вариант с точки зрения первичных капитальных затрат, но зато наиболее надежный. В этом случае используется максимум возможностей оборудования, в том числе функции интеграции между системами. Такая система легко расширяется, поскольку создается с расчетом на это. Ну и конечно, на нее распространяется единый контракт поддержки. Пример — VCE vBlock (см. Рисунок 4)», — поясняет Антон Жбанков.

Рисунок 4. vBlock — протестированная интегрированная платформа с единой поддержкой. Услуги VCE Cloud Accelerator Services помогают эффективно планировать и внедрять масштабируемые облачные среды и сервисы.

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

Важный фактор выбора интегрированной системы — показатели надежности. «При использовании IBM PureSystems можно построить облачный ЦОД без критических точек отказа (Single Point Of Failure, SPOF и Single Point Of Replacement, SPOR), а при намечающихся проблемах с тем или иным оборудованием, например серверным, приложения автоматически перемещаются на другой сервер или другую площадку», — поясняет Кирилл Терешенко. Системы, построенные на базе открытых стандартов и легко интегрируемые в существующую инфраструктуру, позволяют избежать сложностей при дальнейшем ее масштабировании и исключают финансовую зависимость от производителя оборудования.

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

От производительности различных компонентов облачного ЦОД зависят объемы финансовых расходов при строительстве и дальнейшей эксплуатации центра данных. Правильно выбранная интегрированная система позволяет построить облачный ЦОД с минимальными затратами, легко встраивается в существующую инфраструктуру, способствует значительному снижению расходов на дальнейшее сопровождение и обслуживание.

По мнению Дениса Черноскова, руководителя департамента системной интеграции и ИТ-аутсорсинга ГК «КОРУС Консалтинг», конвергентные платформы отличаются очень высокой скоростью развертывания, простотой настройки и администрирования, а также хорошей масштабируемостью (функциональность систем, базирующихся на данных платформах, всегда можно «нарастить»). Не менее важным преимуществом комплексных интегрированных платформ является более простое обслуживание благодаря удобному, интуитивно понятному интерфейсу. Это позволяет снизить требования к квалификации сотрудника, настраивающего и впоследствии управляющего данной конвергентной инфраструктурой. «Главный и, пожалуй, единственный минус комплексных интегрированных платформ — необходимость больших вложений, в том числе начальных», — замечает он.

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

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

УНИВЕРСАЛЬНОСТЬ ИЛИ СПЕЦИАЛИЗАЦИЯ?

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

Как правило, специализированные конвергентные платформы, например системы Oracle, Cisco и IBM, оптимизированы для работы с определенным программным обеспечением и предлагают широкий спектр инструментов для оптимизации того или иного приложения. Это позволяет добиться существенно большего повышения производительности ПО, чем при использовании универсальных платформ, настройки которых не «привязаны» к тому или иному программному обеспечению. Если у компании есть конкретная бизнес-задача (например, развертывание базы данных, предоставляющей оперативный и бесперебойный доступ к информации), то наилучшим решением станет использование специализированной платформы.

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

«Для анализа и последующего выбора оптимальных платформ сегодня применяется профилирование нагрузок. Создавать специализированные решения по типам приложений очень дорого — речь идет не только о стоимости компонентов, но и о дальнейшем обслуживании системы. Если приложение весьма специфичное, значит, оно пользуется малым спросом и, таким образом, вся система окупится очень нескоро, — уверен Георгий Гаджиев. — Когда платформа универсальна, ее всегда можно задействовать для приложений разного типа, повысив эффективность использования ресурсов».

РЕФЕРЕНСНЫЕ АРХИТЕКТУРЫ

«На рынке существуют три вида архитектур: «сделай сам», референсная и вышеупомянутая конвергентная, — поясняет Антон Жбанков. — Первый вариант — наиболее гибкий, но его достоинства зависят от экспертизы провайдера, которая зачастую недостаточна. Помимо этого, желание сэкономить может привести к резкому снижению функциональности и надежности. Референсная архитектура — набор рекомендаций того или иного вендора (какое оборудование взять, какое ПО на него поставить и т. д.). Этот подход менее гибок, но при соблюдении рекомендаций серьезно возрастает уверенность в том, что не будет узких мест и критических точек отказа. Пример — EMC VSPEX (см. Рисунок 5)». Владимир Ткачев добавляет: «Нет ничего плохого в том, что кто-то предлагает бесплатно воспользоваться своим опытом и наработками, пусть и настоятельно рекомендуя использовать исключительно собственные продукты».

Рисунок 5. EMC VSPEX — гибкое архитектурное решение, позволяющее быстро развернуть виртуализированную инфраструктуру с целью консолидации серверов и приложений, сокращения капитальных и операционных затрат.

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

Рисунок 6. Microsoft Private Cloud Fast Track — комплексное решение, разработанное совместно с партнерами и ориентированное на использование Microsoft Windows Server 2008 с Hyper-V и платформы управления Microsoft System Center 2012.

Microsoft в сотрудничестве со многими своими партнерами разработала программу Microsoft Private Cloud Fast Track (см. Рисунок 6). Сегодня она представлена уже в четвертой версии. Партнеры предлагают свою аппаратную эталонную архитектуру облака и инструменты интеграции с программной эталонной архитектурой облака на базе Windows Server 2012 R2 и System Center 2012 R2 — платформы виртуализации и системы управления облаком. В итоге заказчик получает готовый набор компонентов и работы по внедрению. «Это вполне удобное, высокотехнологичное решение, но иногда оно подразумевает использование достаточно дорогих компонентов», — рассказывает Георгий Гаджиев.

ПУБЛИЧНЫЕ ИЛИ ЧАСТНЫЕ?

Иногда выгоднее не создавать собственные облака, а использовать публичные облачные сервисы. Как подчеркивает Константин Анисимов, такой

подход позволяет преобразовать капитальные расходы в операционные. Создание собственного частного облака требует значительных капитальных затрат и не по карману большей части компаний, в штате которых до 50 сотрудников. «Использование публичных облаков выгоднее в тех случаях, когда значительные капитальные затраты нежелательны, а предлагаемые облачные сервисы соответствуют потребностям клиентов. Кроме того, нельзя не отметить гибкость публичных облаков — можно потреблять ровно столько сервисов, сколько нужно в определенный момент, мгновенно подключать и отключать их, оплачивать в соответствии с использованием, быстро реагируя на изменения запросов бизнес-подразделений».

«В каких случаях выгоднее использовать ресурсы публичного облака, а в каких — частного? Это зависит от размеров компании, развитости ее ИТ-инфраструктуры, бизнес-процессов и, конечно, бюджета, — подчеркивает Георгий Гаджиев. — Если компания делает только первые шаги, то очевидно, что тратить бюджет на построение ИТ-инфраструктуры — дело крайне затратное и долгое. В этом случае публичное облако является отличным вариантом, который позволяет получить услугу практически мгновенно с помощью механизмов самообслуживания и оплачивать ее по мере потребления на основе периодических платежей. Для крупной территориально распределенной компании более эффективным решением станет частное облако. Как правило, у таких организаций высокий уровень развития ИТ (виртуализация внедрена и развита) и бизнес-процессов, а значит, с технологической точки зрения они готовы к переходу на сервисную или облачную модель».

По мнению Антона Жбанкова, в публичные облака можно выносить неконфиденциальные и вторичные данные, нерегулярные новые и вторичные бизнес-процессы, а частное облако на площадке провайдера использовать как второй центр данных, когда строительство собственного ЦОД невозможно или невыгодно. Если коммерческий ЦОД достаточно защищен, в нем размещают и конфиденциальную информацию, включая персональную, а также данные бизнес-критичных систем.

Вопрос выбора платформы, на которой строится публичное облако, вторичен. «Она должна хорошо оцениваться представителями отрасли. Желательно ориентироваться на ту, что уже используется в компании. Иначе говоря, не имеет смысла арендовать мощности в облаке на базе Xen, если применяется VMware. Разумеется, для этой платформы должны иметься необходимая экспертиза, поддержка, потенциал развития», — подчеркивает Антон Жбанков.

Использовать сервисы публичных облаков выгоднее, когда нужно запускать множество копий какого-либо приложения на короткое время, поясняет Кирилл Ларин. «Кроме того, — добавляет он, — с их помощью удобно проверять различные идеи и варианты бизнес-логики. Скажем, на утреннем совещании возникла красивая идея, но, чтобы ее проверить, требуется копия коммерческой платформы с другой конфигурацией. Публичное облако идеально подходит для этого — вы запускаете на пару дней копию (или несколько копий) «боевой» системы, смотрите, что происходит, и выключаете. В частном облаке такой эксперимент обойдется, безусловно, дороже. Но как только отлаживаемый процесс начинает переходить в стадию постоянного, лучше переносить его на собственные ресурсы, использовать которые при работе в режиме 24/7 гораздо дешевле. Кроме того, потребление публичных ресурсов следует жестко контролировать, иначе можно быстро потерять контроль над расходами».

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

«Главное, о чем нужно помнить, — частное облако, в отличие от публичного, находится под контролем ИТ-отдела. Следовательно, компания сама обеспечивает сохранность и безопасность своих данных, а пользователи получают услуги в соответствии со стандартами, принятыми в организации, — подчеркивает Дмитрий Морозов, ведущий системный инженер группы компаний CUSTIS. — В то же время для частного облака масштабируемость ограничена возможностями и бюджетом ИТ-отдела, а публичные облака благодаря объединению больших ресурсов гарантируют почти неограниченное масштабирование. К недостаткам частных облаков следует отнести необходимость содержать штат высококвалифицированных специалистов, а публичных — их недоступность в регионах, где нет надежных и быстрых каналов связи».

«Частное облако, — делает вывод Робертас Балкис, представляет собой очередной этап развития виртуализированного центра обработки данных, ведущий к сокращению расходов на обслуживание инфраструктуры. Обращение к услугам публичного облака — это следующий шаг».

ГИБРИДНАЯ МОДЕЛЬ

«Частное облако вполне можно создать и на чужой площадке, просто арендовав несколько стоек с оборудованием. Верно и обратное: площадка может принадлежать холдингу, но ИТ-подразделение предоставляет услуги, как если бы это было публичное облако», — напоминает Антон Жбанков.

«Сегодня многие компании, особенно крупные, проявляют интерес к гибридному облаку, то есть сочетанию собственной инфраструктуры и публичных облачных сервисов в одной информационной среде, — продолжает Георгий Гаджиев. — С одной стороны, такой подход, позволяет сохранить уже сделанные инвестиции, с другой — в любой момент можно масштабировать инфраструктуру за счет ресурсов публичного облака, а когда сервисы перестают быть нужными, отказаться от них. Конечно, многих беспокоит вопрос интеграции. В случае использования технологий Microsoft он не актуален, особенно если речь идет о новых версиях инфраструктурных продуктов, которые мы недавно вывели на рынок в рамках Cloud OS. Они помогают реализовать столь желаемую бесшовную интеграцию, делающую фактически незаметной ту среду, где находится ВМ (локально или в Windows Azure)».

Как поясняет Александр Невинчаный, руководитель департамента базовых решений Microsoft ГК «КОРУС Консалтинг», обычно гибридная модель используется средними компаниям, которые «тяжелые» ERP-системы развертывают в частном облаке или в своем ЦОД, а почту, корпоративный портал и систему электронного документооборота выносят в публичное облако.

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

Как отмечает Робертас Балкис, гибридное облако позволяет создать много полезных решений, которые сложно реализовать при наличии только выделенной инфраструктуры, — например, аварийное восстановление, дублирование на расстоянии, балансирование нагрузок. «Периодически возникают задачи, которые можно и нужно выполнять с использованием публичных ресурсов, поэтому переходить на гибридную модель следует как можно раньше», — заключает Кирилл Ларин.

СЛОЖНОСТИ ПЕРЕХОДА

С какими основными проблемами приходится сталкиваться заказчикам при переходе к облачной модели? Кирилл Ларин выделяет некоторые сложности и ошибки. Прежде всего — неправильное целеполагание. «Многие заказчики, — замечает он, — ждут от облачных технологий и от исполнителей проекта по их внедрению каких-то чудес, поэтому вместо реальных работ приходится тратить время на обучение заказчика».

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

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

Переход к облачной модели (см. Рисунок 7) включает как техническую, так и организационную составляющую. Но если первая достаточно прозрачна и хорошо стандартизирована, то вторая в значительной степени зависит от бизнес-процессов, которые переводятся в облачную среду.

Рисунок 7. План перехода к облачным вычислениям (по данным Oracle).

Для выбора оптимальных характеристик облака необходимо проанализировать требования бизнеса, определить формы предоставления услуг и согласовать уровни сервиса (SLA). По сути, речь идет о внедрении сервисного подхода к управлению ИТ-инфраструктурой, поясняет Дмитрий Морозов.

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

Рисунок 8. К преимуществам интегрированного решения FlexPod от Cisco и NetApp, предназначенного для построения частного облака, разработчики относят стандартизацию (проверенные конвергентные платформы), гибкость (каждая платформа масштабируется с учетом требований различных нагрузок), снижение рисков и затрат за счет быстрого развертывания. Архитектура содержит различные варианты гипервизоров и систем управления (VMware, Microsoft, RedHat, Cisco).

Между тем у многих заказчиков можно наблюдать так называемые лоскутные автоматизацию и виртуализацию. «Большое количество разных аппаратных платформ, систем хранения данных, средств управления и неэффективная система безопасности, которая зачастую не охватывает все компоненты ЦОД, — типичная картина. А нехватка квалифицированных специалистов ведет к значительному снижению эффективности ЦОД в целом и росту затрат на обслуживание, — рассказывает Кирилл Терешенко. — Чтобы справиться со всеми этими и многими другими проблемами, существует ряд решений, к которым можно отнести и интегрированные, конвергентные системы».

Сегодня специалисты стараются оптимизировать ЦОД на разных уровнях (см. врезку «SDDC как платформа для облачных сервисов»), снизить энергопотребление, уменьшить риски и контролировать затраты. Новые разработки и подходы в области инфраструктуры ИТ (см. Рисунок 8) становятся средствами борьбы за сокращение издержек. Создание частных облаков требует времени и денег — переход от традиционного ЦОД с виртуализацией серверов к архитектуре частного облака является непростой задачей, да и единственно правильного способа такой миграции не существует.

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