На протяжении семидесятилетней компьютерной истории неоднократно менялась основная парадигма компьютинга. Сначала приложения были ограничены счетными и транзакционными задачами — им вполне соответствовали и соответствуют до сих пор мэйнфреймы, затем возникла потребность в машинах для управления технологическими процессами и для обработки данных — появились мини-компьютеры, Unix-серверы и рабочие станции, далее персональные компьютеры удовлетворили потребности индивидуальных пользователей. В 90-е годы поднялась волна Интернета, и на первых порах его технической базой стали те же Unix-серверы, но в середине прошлого десятилетия их вытеснили лучше приспособленные для этих целей серверы-лезвия. Несколько лет назад в фокусе оказались мобильность и облачные сервисы, и пока эта потребность удовлетворяется средствами ЦОД, унаследованными от Интернета. Нетрудно уловить очевидную закономерность — возникающие потребности на первых порах приходится удовлетворять средствами, которые были созданы для предшествующей парадигмы, и только со временем возникают качественно новые инструменты, полностью соответствующие изменившимся запросам. Адекватным облакам и сервисам, скорее всего, станет fabric computing (FC).

Термином fabric computing обозначают максимально полную интеграцию ресурсов ЦОД в единую вычислительную среду, и не исключено, что в отдаленной перспективе из этого вырастет некий сверхкомпьютер, что-то вроде разумного океана планеты Солярис, описанного Станиславом Лемом. Однако как быть со словом fabric? В русском языке слово «фабрика» происходит от французского fabrique, которое действительно означает «фабрика», «завод», а вот английское fabric имеет с ними мало общего. Английское fabric следует понимать как «текстура», «ткань», «канва», что надо учитывать при переосмыслении нового явления, которое стали называть fabric computing или fabric-based computing (FBC), а также близкого, но вовсе не тождественного ему термина enterprise data fabric (EDF). Последний термин обозначает высокопроизводительный интерфейс между системами, хранящими данные, и приложениями, их использующими [1]. Однако FBC гораздо более широкое, чем EDF, понятие — это новая форма существования компьютинга, в которой действующая вычислительная система может быть собрана (и разобрана) из отдельных модулей, объединенных коммутирующей текстурой или матрицей.

В будущем при построении облачных ЦОД на уровне FBC предполагается использовать специально созданные для этой цели компоненты, однако очевидно, что подобную матрицу можно собрать, используя в качестве модулей существующие сегодня универсальные компоненты, — это отражает похожий, но не тождественный термин fabric-based infrastructure (FBI). Решения класса FBI можно рассматривать в качестве переходных от нынешних к FBC. К FBI можно отнести VCE (Virtual Computing Environment) от VMware, Cisco и EMC, HP Converged Infrastructure, Dell Virtual Integrated System, IBM Dynamic Infrastructure и Cisco Unified Computing System.

Пока FBC можно представить себе как цель на будущее, и на данный момент к ней ближе всего решение Egenera BladeFrame [2], представляющее собой комбинацию из серверов-лезвий, коммутирующей матрицы, встроенного и внешнего управляющего ПО. Компания Egenera вышла на свой особый путь, опираясь на опыт, полученный ее главой Верном Броунелом в Goldman Sachs. Броунел отдал предпочтение процессорным сетям (Processing Area Network, PAN) [3], открывающим возможность для виртуализации и централизованного управления всеми компонентами системы.

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

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

Исторически FBC предшествовали гриды, в недрах которых в конце 90-х появился термин fabric computing, впервые использованный в проекте ЦЕРН Grid Computing European Data Grid. Со временем проект преобразовался в European Grid Infrastructure (EGI), обеспечивающую доступ к научным данным для ученых всего мира. В четырехуровневой инфраструктуре EGI уровень Fabric самый нижний, обеспечивающий ресурсозависимые сервисы, выше него расположен промежуточный слой, делающий эти сервисы независимыми от ресурсов, а еще выше — инструменты для создания приложений и собственно научные приложения.

Около десяти лет назад гриды снова вошли в моду, повинуясь которой гридами стали называть все что угодно, даже обычные кластеры, собранные из лезвий. Дело дошло до того, что, вопреки всякой логике, в Oracle c 2006 года стали исключительно из конъюнктурных соображений добавлять к названиям своих продуктов суффикс «g» [4]. Изначально основоположники идеи гридов видели в них не банальную группировку серверов, а светлое будущее всего Интернета — целью было создание распределенных вычислительных систем, сравнимых по мощности с суперкомпьютерами того времени, выпускавшимися крупными производителями, а сегодня мы называем это облаками. Однако они опередили время, и жизнь не оправдала их романтические надежды: для проведения супервычислений стали строить довольно примитивные, но зато большие кластеры, а на место грида в Интернете пришли облака. Сегодня грид — почти забытый термин, хотя идея плавно преобразовалась в FBC, который в облаке призван выполнять примерно те же функции, что и Fabric в EGI.

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

ЦОД, построенный на принципах FBC, будет отличаться от традиционных рядом качеств.

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

***

Технологии, обеспечивающие FBC, пребывают пока на начальном этапе, но процесс их взросления протекает достаточно быстро — Cisco и HP, а следом и Dell с IBM делают заметные усилия для продвижения в этом направлении. Конечной целью этого процесса будет создание полностью виртуализованных на всех уровнях, интегрированных облачных центров обработки данных.

Литература

  1. Леонид Черняк. EDF — корпоративная кэш-память // Открытые системы.СУБД. — 2006. — № 8. — С. 24–30. URL: http://www.osp.ru/os/2006/08/3584557 (дата обращения 20.10.2014).
  2. Леонид Черняк. Виртуальный кластер из консервной банки // Открытые системы.СУБД. — 2002. — № 3. — С. 19–21. URL: http://www.osp.ru/os/2002/03/181254 (дата обращения 20.10.2014).
  3. Дмитрий Волков, Георгий Долин. PAN или пропал // Открытые системы.СУБД. — 2006. — № 9. — С. 12–17. URL: http://www.osp.ru/os/2006/09/3776443 (дата обращения 20.10.2014).
  4. Марк Ривкин, Игорь Мельников. СУБД для облаков // Открытые системы.СУБД. — 2013. — № 6. — С. 30–33. URL: http://www.osp.ru/os/2013/06/13036850 (дата обращения 20.10.2014).

Леонид Черняк (osmag@osp.ru) — независимый автор (Москва).