Вниманию сотрудников центров данных!
|
| Коммунальные вычисления в перспективе должны преобразовать инфраструктуру предприятий за счет предоставления по требованию оплачиваемых по мере использования, динамически предоставляемых и масштабируемых, простых в управлении и готовых к использованию компьютерных ресурсов |
В эпоху широкого распространения серверов и недостаточно эффективного использования их ресурсов, а также при росте сложности и затрат на управление подобный подход кажется безупречным. В шеренгу его сторонников встали такие компании, как IBM, Hewlett-Packard, Sun Microsystems и Compaq Computer. Эта концепция приводит в восторг руководителей. Есть только одна проблема — технология никак не может угнаться за мечтами. И вот почему.
Реалия №1. Отсутствие технологий для внешних коммунальных служб
Внешние коммунальные компьютерные службы, как и провайдеры приложений (ASP) и провайдеры услуг хранения данных (SSP), задержались на старте. Недавние объявления о так называемых коммунальных аутсорсинговых сделках (как, например, сделка IBM с American Express на сумму в 4 млрд. долл.) — это старое вино, разлитое в новые мехи. Появилась новая модель ценообразования, но ресурсы и службы управления в организациях остались прежними.
Настоящие коммунальные вычисления будут образовываться под защитой межсетевых экранов, а у информационных служб компаний появится возможность предлагать подразделениям по типу коммунальных такие услуги, как динамическое и масштабируемое предоставление ресурсов, размещение, мониторинг и биллинг в расчете на устройство. Внутри компаний коммунальные вычисления начнутся с кластеров, составленных из индивидуальных серверов, и смогут расширяться до масштаба центров данных и, возможно, структур групп зданий. Это будет рассматриваться как единый объект управления. Чтобы ускорить ввод в действие оборудования и сократить эксплуатационные расходы в информационных центрах, компании будут использовать предлагаемое провайдерами ПО для динамического предоставления ресурсов.
А если не внешние коммунальные службы? Не обращайте внимания на тот факт, что информационные службы сами хотят управлять своей инфраструктурой или что независимые разработчики не желают продавать аутсорсинговым фирмам лицензии с оплатой по факту использования. Проблема в том, что протоколы предоставления ресурсов, календарного планирования, обеспечения безопасности и управления на основе групп правил, необходимые для поддержки аренды компьютеров, существуют только в стадии разработки, в виде предложений по Web-службам и открытым стандартам для сетевых вычислений. Один из них, предлагаемый Globus, называется OGSA (Open Grid Services Architecture). Годы и годы потребуются на создание удобной инфраструктуры, необходимой предприятиям — покупателям коммунальных вычислительных ресурсов для критически важных приложений.
Реалия №2. Сложность создания коммунальных служб в гетерогенных центрах данных
В идеальном представлении все ваши ресурсы для вычислительных работ, для хранения данных и для организации сети обрабатываются на одном уровне виртуализации, независимо от поставщика или операционной системы. Имеется одна система управления с одной консолью и одним графическим интерфейсом пользователя, в котором для предоставления ресурсов, отслеживания и управления новой топологией достаточно нескольких щелчков мыши. Идеальная система должна иметь механизм, способный формировать зависимости, а также отказываться от выполнения вычислительных работ и освобождать ресурсы.
Мечта не скоро станет явью, потому что ее осуществление угрожает доходам поставщиков аппаратных средств. Sun (N1), HP (Utility Data Center), IBM (eLiza, sourcing) и Compaq (Adaptive Infrastructure) — все они поставляли и свои системы, претендующие на предоставление по принципу коммунальных, и программное обеспечение для управления предоставлением ресурсов. Нередко бывало, что они неискренне уверяли потребителей в преданности неоднородным средам и в ряде случаев поддерживали многочисленные разновидности Unix или Linux, но на деле их средства поддержки метакомпьютинга, кластеризации, оплаты в пересчете на процессор и динамического предоставления ресурсов очень явно были оптимизированы под их же собственные платформы и тесно привязаны к существующим средствам управления. Такие предложения интересны предприятиям, пользующимся услугами одного поставщика, но остальным это невыгодно.
Недавно созданные компании — Terraspring, Ejasent и Jareva, а также такие MSP, как Loudcloud и Exodus, разрабатывают программное обеспечение виртуализации, поддерживающее динамически масштабируемые, гетерогенные коммунальные вычислительные службы. Ашар Азиз, директор по технологиям компании Terraspring, видит в этом большую технологическую проблему. Он считает, что миллион строк программ его компании является, как он выразился, «моральным эквивалентом драйвера устройства» для каждой аппаратной платформы. Кроме того, требуется контроль загрузки сетей хранения, который позволяет с большей эффективностью использовать инфраструктуру SCSI и избавляет от необходимости опираться на ядро или какую-либо специфическую операционную среду. Помимо базовых стандартов, таких как SNMP для основных процедур управления и XML для топологии хранения, эти поставщики мало что могут положить в основу своих построений. Судьба предложений будет зависеть от того, какую выгоду смогут извлечь предприятия из частных решений более крупных поставщиков.
Реалия №3. Для одних задач коммунальные вычисления работают лучше, чем для других
В теории коммунальные вычисления должны поддерживать масштабирование почти всех видов приложений, используя динамически распределяемые ресурсы. Но на практике возникают проблемы с разделением решаемых задач между динамическими ресурсами — проблемы, в разрешение которых поставщики приложений вмешиваться не хотят.
Сегодняшние бизнес-приложения часто работают в выделенной (а значит, недозагруженной) инфраструктуре, по одному приложению на машину. Модель коммунальных вычислений требует технологии для «разделения задачи», то есть расчета эффективной организации вычислений на нескольких центральных процессорах и аппаратных платформах.
В случае вертикального масштабирования такая технология давно существовала в форме разбиений на логические блоки (LPAR у IBM или Dynamic System Domains у компании Sun).
Однако не все приложения равны перед горизонтальным масштабированием. Приложения для технических расчетов, такие как планирование DNA, легко разбиваются и распределяются по нескольким машинам. Для Web и приложений, работающих в системах с n-звенной архитектурой, или других приложений, где все экземпляры похожи, таких, например, как электронная почта, задача разбиения хорошо решается при условии сбалансированного распределения потока требований между экземплярами для обеспечения согласованной производительности. Но большинство приложений, работающих на сервере, и приложений, настроенных под пользователя, труднее поддаются горизонтальному масштабированию и не могут так же хорошо вписываться в модель коммунальной службы.
Раджив Бхарадхвадж, руководитель технического отдела в компании Ejasent, утверждает, что приложения Oracle делить под задачи нельзя. Решение задачи деления также проблематично для приложений со сложной логической структурой, множеством хранилищ данных и сложными алгоритмами. Большинство приложений масштаба предприятия просто не рассчитаны на работу в средах с разделением ресурсов. Этим они отличаются от приложений для научных расчетов, работающих в сетях академических сообществ. «Я не могу взять и поделить между пятью пользователями сервер BEA WebLogic, потому что не знаю, как измерять ресурс и как выставлять счет, — говорит соучредитель компании Loudcloud Ин Сик Ри. — Здесь просто нет стандартов».
Реалия №4. Работы по обеспечению безопасности этих служб еще не закончены
Даже находясь под защитой межсетевых экранов, предприятия не станут принимать на вооружение коммунальную модель, пока не будут уверены в безопасности работы с разделяемыми ресурсами. «Вы виртуализировали эту среду для меня, и как я могу быть уверен, что никто другой не получит доступ к моей информации?» — спрашивает Виджей Ратнам, один из руководителей компании Exodus.
В традиционных системах безопасности между блоками создаются DMZ («демилитаризованные зоны»), а пользователи с правами root имеют доступ к блокам для контроля. Однако в мире коммунальных вычислений демилитаризованные зоны должны создаваться между экземплярами приложений. Например, HP использует виртуальные локальные сети, чем усиливает безопасность. «Для конкретной службы виден только трафик этой службы», — говорит Найджел Кук, главный разработчик в HP Utility Data Center. Компании Terraspring и Ejasent работают над созданием сегментов на базе структур и барьеров, которые не может преодолеть даже пользователь с правами root, например таких барьеров, которые работают за счет сокрытия ID процесса и прочих идентификаторов. Непонятно, правда, удовлетворят ли эти методы профессионалов ИТ, занимающихся проблемами безопасности.
Эра коммунальных вычислений пока только начинается. Обещает она много, но реальных приложений еще очень мало, а впереди ждут трудные задачи. Необходимо разработать стандарты для целого уровня виртуализации, включая предоставление ресурсов, управление, безопасность, производительность, измерения и биллинг. Более того, должны подключиться поставщики приложений, чтобы предоставить приложения для разделения ресурсов между многочисленными пользователями, а поставщики оборудования должны усилить поддержку платформ друг друга. Ожидать следует скорее неторопливого прогресса, чем революционных прорывов. Коммунальные вычисления — это вам не электричество.