USD 92.26 ЕВРО 99.71

Внутренние облака: шаг назад, два шага вперед

Аналитика

Внутренние облака: шаг назад, два шага вперед

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

Термин «облачные вычисления» часто воспринимается как синоним доступа к удаленным ресурсам через Internet. Пользователь не знает, каким образом организовано «облако» и, что самое интересное, не хочет знать. Тем не менее, для того чтобы удовлетворить его требования, в «облаках» работает целая структура, которая с помощью технологий виртуализации объединяет огромное количество серверов в один мощный вычислительный механизм, разделяя при этом ресурсы на виртуальные машины, использующиеся одновременно.

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

Таким образом, направление общедоступных «облаков» создает внутри себя более узкую нишу и тем самым, казалось бы, делает шаг назад. Но разве не то же самое происходило и с intranet?

Вероятно, следует ждать подобного развития событий и с «облачными» вычислениями. Если внешнее «облако», такое как, например, Amazon Elastic Compute Cloud (Amazon EC2), поддерживает некие стандарты, то почему бы не построить внутренние «облака» по тому же принципу? Тогда можно будет без проблем обмениваться данными, что и сделает публичное «облако» расширением корпоративного. При таком сценарии предприятие будет работать с собственным оборудованием и «облачной» структурой внутри корпоративной сети, используя преимущества внешнего «облака».

По мнению Хазрета Сапенова, председателя виртуальной конференции Cloud Slam’09, состоявшейся в апреле 2009 года в США, сегодня каждый ИТ-руководитель просто обязан инициировать пилотный проект, посвященный вычислениям в «облаках», даже если внутренние «облака» не числятся в ближайших планах предприятия. Это даст возможность подготовиться к будущему, когда технологии придут к одним и тем же стандартам и переход к «облакам» придется осуществлять уже вынужденно.

Почему внутренние «облака» предпочитают внешним?

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

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

«Облачная» или традиционная?

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

Поддержка всплеска активности. Время от времени в деятельности предприятия случаются всплески активности, обусловленные различными причинами: рекламной кампанией, выпуском нового продукта и т.п. Масштабирование «облака» позволяет перераспределить ресурсы для того, чтобы выдержать неожиданный напор. Менее важным запросам во время всплеска присваивается более низкий приоритет. Для обслуживания рекламной кампании не потребуется закупать новое оборудование — «облака» растянутся, как резиновые, и выдержат небывалый напор звонков.

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

Переход в «облака»

Чарльз Бабкок, аналитик InformationWeek, в исследовании «Частные «облака» на горизонте», опубликованном 13 апреля 2009 года, отметил, что чем ближе серверы по конфигурации, тем легче будет соединить их вместе в кластер или grid-инфраструктуру. Миграция виртуальных машин может быть воплощена в жизнь только при использовании одной и той же микросхемы центрального процессора. Это позволит бесперебойно работать таким, например, средствам миграции, как VMotion от компании VMware. Таким образом, первым шагом руководителя информационной службы будет оценка однородности оборудования, используемого на предприятии. Самый простой путь к «облакам» лежит через построение сети на основе серверов архитектуры х86. Именно так построены вычислительные «облака» Amazon, Google и Microsoft.

В большинстве случаев для воплощения в жизнь структуры внутреннего «облака» необходимо осуществить виртуализацию серверов предприятия, что требует дополнительных усилий. Строго говоря, «облако» может быть построено и без этого, поскольку перемещение рабочих нагрузок между физическими серверами может происходить и без гипервизорной программы, например, с помощью основанных на XML спецификаций пакета PAN Manager компании Egenera. Но обеспечить высокую эффективность работы и необходимую степень масштабирования в этом случае гораздо сложнее. Поэтому корпоративные «облака» почти неотделимы от виртуализации. На рынке существует множество продуктов в этой сфере: vCloud компании VMware, Citrix Essentials для Xen-Server и Hyper-V, Virtual Resource Management от DynamicOps и др. Можно без преувеличения сказать, что если в организации удалось воплотить виртуализацию, то создание внутреннего «облака» не будет представлять трудностей: больше, чем полдела, уже сделано.

Выбор платформы

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

На пути к внутренним, а впоследствии и к гибридным «облакам» многие американские корпорации выбирают ПО компании VMware, заслужившей доверие в области виртуализации и «облачных» вычислений. Среди ее продуктов — новая операционная система VDC-OS (Virtual Data Center Operating System), разработанная для объединения серверов, сетевых аппаратных ресурсов и средств для хранения данных. Эта платформа умеет перемещать виртуальные машины между внутренними и внешними «облачными» структурами. Набор вычислительных средств vCloud позволяет из внутренних «облаков» запускать сервисы, доступные во внешних. VMware обеспечивает связь приложений между разными сервис-провайдерами, такими как Melbourne IT, Savvis, SunGard и Terremark. Это становится возможным благодаря виртуальной инфраструктуре и интерфейсам API для создания стандартизованных служб vCloud. Со временем VMware планирует использовать те же самые интерфейсы и для перемещения во внешнее «облако».

Внутреннее «облако» может быть создано и с помощью других платформ и продуктов. Например, Lab Manager для Citrix Essentials (XenServer и Hyper-V) или NetScaler работают в ансамбле с платформой автоматизации Workflow Studio, связывая инфраструктуру и данные. Подобно VMware, Citrix использует набор интерфейсов API, связанных с Citrix Repeater (ранее известных как WANscaler). Последний помогает ускорить выполнение приложений в пределах расширенной корпоративной сети, заполняя «дыру» между ею и внешним «облаком».

Компания Sun Microsystems также предоставляет «облачную» платформу — Sun Open Cloud Platform, соответствующую внешней структуре под названием Sun Cloud, построенной в соответствии с набором открытых интерфейсов API.

Для пользователей Amazon EC2 существуют пакеты свободного ПО Eucalyptus, состоящие из наборов API, близких к тем, что использует Amazon. Это позволяет воплотить внутренние «облака», функционирующие так же, как EC2, в том числе создать аналоги сервисной базы данных Simple DB и файлового хостинга S3, на основе которого работает Simple DB. Построенные таким образом приложения могут быть легко экспортированы во внешнее «облако» от Amazon.

Кластерная файловая система

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

Свое решение этой проблемы в продукте Dell PAN нашла компания Egenera: каждой рабочей нагрузке присваивается уникальный идентификатор хранения, вне зависимости от того, происходит это в рамках виртуальной машины или непосредственно на физическом сервере. Этот идентификатор позволяет вернуться назад к сохраненным данным.

Администрирование

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

Приложения: что выбрать?

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

Следует, однако, отметить, что при использовании внешних «облаков» выбор доступных приложений, как и платформы для них, ограничен средствами, предоставляемыми провайдером «облачной» структуры. Например, платформа App Engine от Google работает только с языком программирования Python 2.5, а Salesforce — c Visual Force и Apex. Возможно, в будущем провайдеры смогут расширить набор средств для программирования. Например, в Microsoft уже строят такие планы для «облаков» Azure, но и в этом случае программисты будут ограничены продуктами и сервисами самой корпорации Microsoft.

Частное «облако» предоставляет разработчикам больше возможностей: оно строится ровно таким, как хотят его создатели, и позволяет разрабатывать программы с помощью привычных средств и сред программирования. Скажем, вместо того чтобы приспосабливаться к виртуальному формату Amazon Machine Image (AMI) файлов Amazon, организация сможет работать с тем форматом данных, который наиболее удобен. Обмен данными с внешним «облаком» обеспечивается средствами конвертации. Например, пакет rBuilder компании RPath сможет запаковать виртуальные данные в формат AMI для экспорта во внешнее «облако» Amazon.

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

Ольга Топровер

Источник: www.osp.ru