От консолидации серверов к виртуальным центрам обработки данных

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

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

Новые заботы ИТ-руководителя

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

В этих рассуждениях нет ничего нового. С начала 60-х и до конца 70-х годов, когда кроме мэйнфреймов иных компьютеров не было, централизация казалась неизбежной. Но затем с появлением мини-ЭВМ, а потом рабочих станций и персональных компьютеров все заметнее становилась децентрализация компьютерных систем. Представлялось, что это — панацея, но когда процесс достиг апогея, оказалось, что и у децентрализации есть свои недостатки. На этом первый цикл диалектической спирали завершился; вероятно, придет время и второй волны децентрализации, но случится это не в ближайшие годы.

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

В ответ на повышение роли спроса в формировании ИТ-рынка большее значение приобрели и аналитики, исследующие требования пользователей. Их отчеты заметно отличаются от тех материалов, которые публикуют их более известные коллеги, в большей степени ориентированные на производителей. Одним из примеров может служить компания TheInfoPro, регулярно выпускающая отчеты серии Wave в рамках постоянной исследовательской программы Server Study, которая основывается на периодических опросах ИТ-руководителей. Оценки, которые можно найти в очередном отчете Wave 3 (www.brainshark.com/theinfopro/Servers_W3_WS), существенно отличаются от содержания более ранних отчетов, они свидетельствует о серьезных изменениях во взглядах практиков ИТ на подходы к построению центров обработки данных нового поколения по двум связанным вопросам.

Во-первых, в своем отношении к консолидации ресурсов ИТ-руководители проявляют редкое единодушие. В рейтинге приоритетов более 40% опрошенных поставили консолидацию на первое место, а непосредственно связанную с ней виртуализацию 30% считают второй по важности темой. Для сравнения, внедрение иных новых технологий ставят на первое место только 20% респондентов. Остальные, казалось бы, не меньшей значимости темы, в том числе обеспечение надежности и снижение затрат, не набирают и 10%. Показательно и то, что, согласно опросу, среди производителей программного обеспечения для серверов со значительным отрывом лидируют Microsoft (95%) и EMC (85%). Действительно, их вклад в решение задач консолидации и виртуализации является наибольшим. Затем с близкими результатами с показателем примерно 50% следуют HP, IBM и Sun Microsystems, а из оставшихся компаний более 20% не набрал никто. Приведенные данные однозначно свидетельствуют о доминировании проблем виртуализации и консолидации, возникших буквально в последние годы.

Во-вторых, с задержкой в несколько лет консервативное корпоративное сообщество отказалось от прежде настороженного отношения к серверам-лезвиям. Прежние отчеты аналитиков, датированные 2003-2005 годами, свидетельствовали, что, вопреки массовому восторгу по отношению к лезвиям со стороны производителей и создаваемой ими шумихе, конечные пользователи проявляли к лезвиям, возможно, неоправданный, но тем не менее очевидный скептицизм. Теперь же, в 2006 году, 85% опрошенных оценивают перспективы лезвий положительно и готовы рассматривать их всерьез; негативного отношения к лезвиям не высказал никто.

Однако единства взглядов на методы консолидации и технологии создания масштабируемых центров обработки данных пока нет. Часть специалистов перешли на новые позиции, отдавая свои симпатии горизонтальному масштабированию (scaling out), суть которого в расширении систем путем добавления вычислительной мощности небольшими порциями, например, теми же лезвиями. Но другие по-прежнему предпочитают вертикальное масштабирование (scaling up), основанное на тех или иных методах виртуализации больших систем. У каждого из подходов свои достоинства и недостатки. В тех случаях, когда суммирование производительности не имеет большого значения или приложения плохо совместимы на одном сервере (скажем, в случае файловых серверов или серверов печати), разумеется, преимущество на стороне горизонтального масштабирования. Но если приложения родственны, работают с общими большими массивами данных, предпочтительнее вертикальное масштабирование. Вместе с тем между двумя подходами возможен компромисс, если применяются методы виртуализации, которые позволяют интерпретировать сборку из лезвий как одну виртуальную машину. Именно такое решение является составной частью программного обеспечения VMware Infrastructure 3, представленного EMC в середине прошлого года.

Стимулы к консолидации

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

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

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

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

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

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

В этой статье мы рассмотрим первый этап.

Консолидация серверов

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

Общепризнанного определения консолидации серверов нет. Аналитики Gartner предложили достаточно разумную классификацию, выделив три типа (рис. 1.) консолидации серверов — логическую, физическую и «усовершенствованную» (rationalized).

Логическая консолидация предполагает, что все серверы остаются на своих физических местах, но они объединяются для выполнения единого потока заданий общей системой управления. При физической консолидации серверы, распределенные географически, просто собираются в одном месте. Радикальным решением является «усовершенствованная» консолидация, когда одновременно уменьшается число платформ и они собираются физически в одном месте. (Иногда в качестве отдельного подхода к консолидации выделяют консолидацию операционных сред, т. е. виртуализацию серверов путем деления на разделы, что позволяет запускать на одном компьютере несколько разных операционных систем.)

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

Файловые серверы и серверы печати подразделений могут быть объединены в два или даже в один сервер, ресурсами которого могут пользоваться отдельные подразделения. Можно заменить отдельные стойки серверов на единую конструкцию, состоящую из тонких 1U-серверов, или пойти еще дальше, воспользовавшись вместо них серверами-лезвиями.

Консолидация серверов — вертикальный путь

Усовершенствованная консолидация может быть осуществлена с использованием обоих возможных направлений масштабирования — и по горизонтали (его обычно связывают с серверами-лезвиями, чаще всего на платформе x86), и по вертикали, используя более мощные многопроцессорные SMP-серверы. Если идти по второму пути, то спектр возможных решений сводится к двум основным приемам, один — более эффективное управление нагрузкой (workload management), второй — деление серверов на разделы, или партиционирование (partitioning). Обсуждение этих приемов явно возвращает нас во времена, когда создавались первые системы с разделением времени. Суть управления нагрузкой сводится к тому, что несколько приложений работают на одном экземпляре операционной системы, в данном случае основная сложность сводится к балансировке нагрузки, поскольку необходимо обеспечить каждое приложение требуемыми ему ресурсами. Деление на разделы открывает возможность для одновременного выполнения на одном сервере нескольких операционных систем. Оба приема могут применяться совместно (рис. 2).

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

Для серверов, консолидированных на уровне управления нагрузками, применяются программные средства, расширяющие возможности стандартных операционных систем Unix и Windows. В классических вариантах Unix специализированный инструмент для управления приложениями не был предусмотрен. Чтобы компенсировать этот недостаток, основные производители современных коммерческих версий Unix, прежде всего IBM, HP и Sun Microsystems, поставляют свою собственную технологию для управления нагрузкой и выполнением приложений. В IBM AIX имеется менеджер управления нагрузкой AIX Workload Manager (WLM). Используя WLM, системный администратор имеет возможность создавать различающиеся между собой классы сервисов для определенных видов работ. Классы различаются по уровню приоритетов, которыми регламентируется доступ работ к ресурсам. Конкретные работы попадают в классы по их принадлежности пользователю, группе пользователей или приложению. Начиная с пятой версии в AIX предусмотрена возможность для назначения процессоров определенным приложениям. Для той же цели в состав HP-UX 11i включено средство Processor Sets (Psets), доступное на многопроцессорных серверах HP 9000, оно позволяет резервировать процессоры для приложений в динамическом режиме. У HP имеется два собственных инструмента для управления нагрузкой; один является тезкой продукта IBM, он также называется Workload Manager, а второй — Process Resource Manager. Пакет PRM резервирует процессоры, оперативную память и дисковое пространство для приложений. WLM служит средством, с помощью которого системный администратор может управлять системой приоритетов. Аналогом этих средств в операционной системе Sun Solaris служит аппарат виртуализации Solaris Containers. Он обеспечивает полную изоляцию приложений, работающих под управлением одной операционной системы. Microsoft предлагает свое средство для управления нагрузками Windows System Resource Manager (WSRM).

Все перечисленные консолидационные решения направлены на усовершенствование процесса распределения нагрузки. Однако при этом они обладают одной общей слабостью, работая тем лучше, чем проще приложение. Это вполне объяснимо, ведь чем проще поведение объекта, тем легче выстроить стратегию и тактику управления. В конечном итоге большинство менеджеров нагрузок есть не что иное, как инструмент для программного управления (программного в смысле теории автоматического регулирования); они не используют обратную связь и не обладают свойствами самоуправления. Но существует большой класс композитных приложений, размер которых требует совершенно иного подхода, целостного взгляда на управляемый объект. Одной из немногих компаний, способных предложить систему автоматизированного управления нагрузками, является компания Aurema. Ее основной продукт — ARMTech 3.0 — способен получать данные о работе приложения, оценивать ситуацию, находить оптимальное решение и вырабатывать необходимые управляющие воздействия.

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

Теоретически возможно существование трех типов партиционирования. Разделы могут быть физическими, логическими и программными (рис. 3). Очевидно, идея аппаратного деления на разделы применима только к многопроцессорным серверам. В таком случае каждый раздел получает свою долю процессоров, оперативной памяти, дисков, а также других составляющих системы ввода/вывода. Аппаратные разделы полностью изолированы друг от друга, поэтому неисправность в одном из них не влияет на работу всех остальных. Производители многопроцессорных серверов и операционных систем (IBM, HP, Unisys, Sun Microsystems, Microsoft и др.) предлагают собственные решения, предназначенные для статического или динамического деления на физические разделы. Конструкция, делящая компьютер на логические разделы (LPAP от Logical PARtioning), так же как и на физические разделы, была впервые предложена в IBM в 1976 году и реализована в мэйнфрейме Systems Complex (Sysplex). Позже она была повторена в мэйнфреймах Amdahl, а еще позже — в серверах Hitachi и Sun Microsystems. Логические разделы могут быть как статическими, так и динамическими.

Программные разделы создаются средствами виртуализации, каждый раздел является отдельной виртуальной машиной. Этой теме был посвящен предыдущий выпуск нашего журнала (см. «Открытые системы», № 2, 2007).

Консолидация серверов — горизонтальный путь

С технологической точки зрения лезвия — действительно новое слово, ничего подобного раньше не было. Главное достоинство лезвий заключается в том, что при сборке в стойку отпадает необходимость в традиционных системных коммутаторах или системных шинах, существенной части оборудования SMP-серверов. Они заменяются стандартными коммутационными схемами на базе технологий Ethernet или InfiniBand, за счет чего существенно уменьшается количество оборудования и в стандартной стойке, следовательно, удается разместить гораздо больше процессоров, добиться плотности в несколько раз более высокой, чем в классических серверах. Но если каждый из серверов-лезвий работает под управлением собственной операционной системы, это является крайним случаем предела аппаратного партиционирования и хорошим примером физической консолидации.

Гораздо интереснее и перспективнее консолидировать вычислительную мощность отдельных лезвий и создать решение, конкурирующее с SMP-серверами и теми же мэйнфреймами, тем более что неограниченные возможности кластеризации позволяют добиться самых высоких уровней готовности. Один из первых шагов в этом направлении сделала EMC. В рамках VMware Infrastructure 3 корпорация выступила с новой инициативой, открывающей возможность не просто виртуализировать один сервер и разместить на нем несколько приложений (пример программной консолидации), но и сделать обратное, агрегировав в один пул несколько серверов и рассматривая его как объединенный вычислительный ресурс. С этой целью в состав ESX Server 3 включены обновленные версии пакетов VMotion, VirtualCenter 2, Virtual SMP и Resource Pools, а также такие новинки, как файловая система VMFS, средства управления распределенными ресурсами (Distributed Resource Scheduler), обеспечения высокой готовности (High Availability) и консолидированного резервного копирования (Consolidated Backup).

Ядром этого решения является продукт VMware Virtual SMP (рис. 4.), позволяющий интерпретировать четыре процессора как одну виртуальную машину. VMware Virtual SMP позволяет более интенсивно использовать аппаратные ресурсы и масштабировать среду без добавления физического оборудования. Чтобы улучшить балансировку нагрузки и избежать перегрузки системы, Virtual SMP может перемещать задания между процессорами, используя ресурсы незанятых процессоров. VMware Infrastructure 3 поддерживает операционные системы Windows, Linux и Solaris x86.

Консолидация данных

До самого последнего времени представление о консолидации данных оставалось весьма ограниченным. В конечном счете все сводилось к тем или иным операциям над системами хранения, а собственно данные оставались за бортом. Обычно говорили о сетевых накопителях (Network-Attached Storage, NAS), дисковых массивах (Redundant Array of Independent Disks, RAID) и сетях хранения (Storage Area Network, SAN), а также о путях конвергенции этих технологических решений. Если ограничить консолидацию только системами хранения, то все сводится к переходу от федеративной модели хранения, где одни приложения имеют доступ к данным других приложений (в этом заключается идея федерализма), к централизованной и в этом смысле консолидированной модели (рис. 5, а). Очевидная слабость этого ограниченного представления заключается в том, что консолидируются не данные, а их хранилища, т. е. на самом деле наблюдается очевидная подмена содержания формой. Так было до середины 2006 года, пока не оформились как самостоятельное новое направление технологии файловых сетей (File Area Networking, FAN); вот их-то с уверенностью можно назвать консолидированным подходом к хранению данных (рис. 5, б).

На протяжении последнего десятилетия корпоративные системы хранения активно эволюционировали, сначала появилась многоуровневая модель хранения Tiered Storage Model, состоящая из уровня более быстрых дисков, уровня медленных дисков и системы архивирования на ленточных или дисковых библиотеках. В ответ на появление этой модели возникли программные технологии иерархического управления хранением (Hierarchical Storage Management, HSM) и далее модель управления жизненным циклом информации (Information Lifecycle Management, ILM). Эти методы развивались, что в дальнейшем привело к появлению еще одного неаппаратного уровня хранения, ответственного за поставку данных приложениям (Storage Admission Tier, SAT). Предполагалось, что на этом уровне можно обеспечить виртуализацию систем хранения, оптимизировать доступ к неструктурированному контенту, организовать HSM и ILM. Рождение FAN — вполне логичный следующий этап развития корпоративных систем хранения, и появление данного рода сетевых инфраструктур логически закономерно. Основное предназначение FAN заключается в облегчении внедрения новейших системных функций, в числе которых: файловые сервисы в глобальных сетях; оптимизация и ускорение работы приложений в сетях; распределенные и кластерные файловые системы; сетевое управление файлами и виртуализация файлов; программные средства управления файлами и документами; программное обеспечение классификации файлов; управление размещением и перемещением файлов.

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

И кто бы ни был автором термина FAN, именно О’Нил дал очень образное определение текущего момента. Он назвал происходящее эффектом дежа-вю. Действительно, все очень напоминает события десятилетней давности, когда появились другие сети — сети хранения. Как и тогда, в начальный момент имеется ограниченный набор технологий, нет стандартов, но очевидно, что направление перспективно и существенное расширение лагеря поставщиков FAN близко.

Основные компоненты FAN представлены на рис. 6.

• Собственно устройства хранения, образующие физическую инфраструктуру; это могут быть системы хранения, построенные в архитектуре как SAN, так и NAS, но они должны быть собраны в одну сеть.
• Интерфейсные устройства и устройства, поддерживающие файлы. Это могут быть компоненты, непосредственно интегрированные в файловую инфраструктуру, например подключаемые к сети устройства хранения или интерфейсные шлюзы; все они должны поддерживать стандартные протоколы CIFS или NFS.
• Пространства имен. Они необходимы, потому что любая файловая сеть создается в предположении о наличии файловой системы, способной к организации хранения и представления файлов клиентам, такая система может существовать при наличии централизованной схемы именования файлов. Организация системы именования — центральная проблема FAN. Она решается с введением глобального унифицированного пространства имен (Global Unified Namespace, GUN).
• Сервисы контроля и управления файлами связывают файловую систему с устройствами хранения, эти сервисы являются интеллектуальными, с их помощью обеспечивается виртуализация, классификация и исключение дублирования данных.
• Конечные клиенты — клиентские рабочие места, с которых осуществляется доступ к файлам с использованием пространства имен.
• Межсоединения; обычно используются традиционные технологии локальных сетей, но в некоторых случаях могут быть задействованы и технологии глобальных сетей.

Консолидация коммуникаций

К консолидации коммуникаций, как и к консолидации серверов может быть несколько подходов, она может быть физической и логической. Под физической консолидацией в данном контексте понимается замена старой инфраструктуры, состоявшей из коммутаторов прежних поколений, например коммутаторов Gigabit Ethernet или 10G Ethernet. Переход на высокоскоростные коммутаторы позволит не только упростить инфраструктуру, но и в сочетании с использованием протокола TCP/IP и средств виртуализации создавать кластеры требуемых конфигураций, выбирая серверы из общего пула и сети хранения, работающие по протоколу iSCSI.

Можно выделить два основных технологических решения — консолидация коммуникаций по Ethernet и консолидация коммуникаций по InfiniBand; на данный момент количественное преимущество явно на стороне Ethernet. В области систем хранения решения на основе iSCSI соседствуют с укрепившимся на рынке решением на базе Fibre Channel. Стандарт InfiniBand имеет ограниченное влияние, скорее всего, из-за сложившейся рыночной конъюнктуры. Примерно так же обстоит дело по части объединения серверов; отличие в том, что имеется существенный опыт создания кластеров по технологиям компаний Myricom (Myrinet), Quadrics (QsNet) и Mellanox.

Примером логической консолидации можно назвать реализуемый Cisco проект Service-Oriented Network Architecture (SONA) и создаваемая на его основе архитектура центра обработки данных Cisco Data Center Network Architecture. В задачу SONA входит создание архитектурной конструкции, которая позволит осуществить со временем переход к виртуализированной сетевой инфраструктуре, называемой Intelligent Information Network (IIN). Создание SONA было ответной реакцией Cisco на инициативу американского правительства Federal Enterprise Architecture, в которой постулированы требования к будущим центрам обработки данных федеральных ведомств (рис. 7).

Консолидация на практике

Из всех направлений консолидации наиболее значимые результаты достигнуты в области консолидации серверов. Сегодня практически все производители предлагают свои решения по созданию центров обработки данных, состоящих из лезвий. Особый интерес представляет серверное решение от Fujitsu Siemens Primergy BladeFrame, его можно представить не просто как консолидированный пул ресурсов, а как специализированную сервис-ориентированную инфраструктуру SOI, предназначенную для поддержки SOA. Новейшие решения из разряда вертикальных предложили в своем совместном проекте APL (Advanced Product Line), переименованном в SPARC Enterprise Server, та же Fujitsu Siemens Sun Microsystems. Совместив в серверах средней и высокой производительности лучшее из мира Unix-серверов и мэйнфреймов, они практически обеспечили конвергенцию; деление на два класса, а точнее, противопоставление, существовавшее пару десятилетий, более не актуально. Остается ждать не менее значительных результатов от консолидации данных и коммуникаций.

---

ВЦ следующего поколения

Несколько лет назад почти одновременно стартовала группа аналогичных по содержанию исследовательских проектов. У IBM такой проект назывался Autonomic Computing, у Sun Microsystems — N1, у HP — The Adaptive Enterprise, у Microsoft — Dynamic Systems Initiative, а у Intel — Proactive Computing. При разности названий их суть сводилась к фирменной реализации схемы, на вершине которой находится «коммунальный» компьютинг, поддерживаемый новым типом ИТ-инфраструктуры, который можно было бы охарактеризовать как центр обработки данных будущего.

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

Преимуществом вычислительного центра будущего является обеспечение возможности для эффективного взаимодействия сотрудников, партнеров и клиентов. Эти новые центры призваны защитить, оптимизировать бизнес и, главное, открыть потенциал для его роста. На пути к ним необходимо преодолеть слабости существующих центров, связанные с тем, что обычно приложения распределены по отдельным компьютерам, а инфраструктура представляет собой сложный клубок разнотипных серверов, операционных систем, сетевого оборудования. В идеале устройство вычислительного центра будущего может быть представлено в виде трехуровневого стека (рис. I), в основании которого лежит аппаратная масштабируемая инфраструктура, состоящая из стандартных компонентов. Над ней находится виртуализационный уровень, а еще выше располагаются средства автоматизации, собственно и обеспечивающие сервисную природу и удобство потребления вычислительных ресурсов. Природа вычислительного центра будущего намного сложнее, чем природа мэйнфрейма. Это многомерное явление, его можно рассматривать по-разному (рис. II), с точки зрения потребления ресурсов вычислительных центров будущего оно включает в себя сервисы, предоставляемые бизнесу, эти сервисы реализуются средствами приложений. При создании внутренней архитектуры используются подходы, основанные на сервисных архитектурах. При этом ИТ-инфраструктуре должна быть обеспечена необходимая адаптивность, а с операционной точки зрения эта инфраструктура должна предоставлять распределяемые ИТ-сервисы.

Может существовать множество взглядов на вычислительный центр будущего, в том числе и с точки зрения внутренней сервисной модели. Ее можно разделить на три уровня: инфраструктурный уровень, включающий инфраструктуру хранения данных, сетевую и вычислительную инфраструктуры, уровень сервисов и уровень приложений (рис. III).

Эволюция по направлению к центрам обработки данных будущего происходит под влиянием четырех основных тенденций.

• Коммодитизация. Этот термин, точнее всего переводимый как «ширпотреб», нуждается в комментарии. Речь идет о всеобщем процессе; рано или поздно он распространяется на все развитые рынки и со временем приводит к вытеснению уникальных продуктов, сделанных вручную, стандартными серийными образцами. Наглядными примерами коммодитизации являются рынки автомобилей, бытовой электроники, одежды. Серийность позволяет сократить стоимость, повысить качество, эксплуатационные характеристики, но она не может быть полной, на любом рынке остается место для мелкосерийных изделий. Характерный пример коммодитизации — процессоры x86. Но коммодитизация —это и не уравниловка, она предполагает специализацию; в рамках одного семейства продуктов могут находиться отдельные представители, в большей степени приспособленные к поставленным целям. Коммодитизация не может быть полной, на любом рынке остается место для продуктов с меньшей серийностью; если говорить о процессорах, то здесь остается место для архитектур Power и SPARC. На компьютерном рынке коммодитизация распространяется и на сетевое оборудование, на диски и т.д.
• Виртуализация. Виртуализация обеспечивает преобразование множества физических ресурсов во множество логических ресурсов. Группы однотипных ресурсов, таких как серверы, приложения, базы данных, сети, можно рассматривать как единый ресурс. Для этого требуются соответствующие прикладные компоненты, средства для доступа, виртуализованные операционные системы, системы хранения и другие компоненты. В конечном итоге, если отбросить технические детали, виртуализация — это процесс приведения ресурсов в соответствие с предоставляемыми сервисами. Цель виртуализации заключается в повышении готовности, балансировке нагрузки, повышении коэффициента использования оборудования, прежде всего серверов, улучшении масштабируемости, улучшении гибкости при реакции на изменения, упрощении управления. С точки зрения бизнеса преимущества виртуализации заключаются в том, что она повышает способность для роста и обеспечивает возможность предвосхитить ту потребность в ресурсах, которая может возникнуть в критических обстоятельствах.
• Интеграция. Коммодитизация и виртуализация существенно снижают стоимость на компонентном уровне, но при создании крупных центров обработки данных, которые могут насчитывать тысячи серверов, критической может стать не стоимость отдельных составляющих, а стоимость всей системы в целом, не являющаяся суммой и зависящая от сложности. Поэтому при создании центров обработки данных придется отказаться от привычного платформенно-центричного подхода в пользу стандартных сетевых решений. В видимом будущем решения, основанные на сложившихся представлениях (параллельные шины, классические методы кластеризации, распределенные объекты и мониторы транзакций), останутся в прошлом, а в будущем придется использовать асинхронные коммуникации и обмен данными на основе сообщений.
• Инновации. Снижающие затраты коммодитизация и виртуализация могут оказаться соблазном для сокращения инвестиций в ИТ, но такой подход нерационален. Эксперты соглашаются в том, что разумнее оставлять прежний уровень инвестиций и сохранять центры обработки данных на должном уровне готовности к появлению новых технических решений.

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