Компания GemStone Systems предлагает программное обеспечение промежуточного слоя GemFire Enterprise, основанное на принципах Enterprise Data Fabric и позволяющее построить полноценную корпоративную информационную систему на серверах-лезвиях.
Рано или поздно центры обработки данных трансформируются в супермэйнфреймы, состоящие из множества небольших серверов. В них архитектурная иерархия, скорее всего, будет следующей: процессорные ядра — микропроцессоры — серверы — центры обработки данных.
Компьютерные технологии давно эволюционируют от отдельных серверов к вычислительным средам. В отличие от серверов, промышленные контроллеры без особых проблем можно собирать воедино, потому что они работают под управлением программ, записанных в постоянную память (EPROM), или под управлением центральной управляющей машины; однако каждый из них остается автономен. Вот уже много лет контроллеры, которыми комплектуют технологические системы управления, собирают в промышленные стойки (rack); в последнее время аналогичные конструктивы стали популярны и в обычных ИТ-системах. Эти стойки обычно называют 19-дюймовыми (их ширина составляет 19 дюймов или кратна этой величине); в качестве стандарта расстояния по высоте между полозьями была принята единица измерения rack unit, или U, равная 1,75 дюйма (44,45 мм)*. В 90-е годы появились серверы, монтируемые в стойки (rack mount), а также системы хранения данных, коммуникационное и другое оборудование. Затем появились сверхтонкие серверы в формате «коробки для пиццы» (pizza box) толщиной 1 U или 2 U; они выпускаются и в виде отдельных устройств, но большинство монтируется в стойки. В итоге сегодня большую часть оборудования центров обработки данных, за исключением самых мощных серверов и накопителей, собирают в 19-дюймовые стойки.
Продолжением этой тенденции стало появление сверхкомпактных северов-лезвий (blade), содержащих на одной плате центральный процессор, накопитель на дисках или на флэш-памяти и средства управления вводом/выводом. Первый сервер-лезвие в марте 2001 года произвела компания RLX Technologies, созданная выходцами из Compaq Computer. В одну стойку можно было установить до сотни лезвий, собрав воедино впечатляющую вычислительную мощность при относительно скромной стоимости. Неудивительно, что с момента их появления стало складываться представление о том, что сборки из лезвий, обладающие к тому же всеми достоинствами кластеров (и прежде всего надежностью), довольно скоро смогут вытеснить с рынка дорогие монолитные SMP-серверы. Однако этого не произошло; более того, прогнозы, сделанные сегодня, через пять лет после появления лезвий, не предполагают существенного роста их производства.
Почему же лезвия, несмотря на свою очевидную перспективность, до сих пор имеют ограниченное применение? Распределить приложения по серверам оказывается не такой уж сложной задачей, сложнее дело обстоит с данными. Не стоит забывать, что корпоративные приложения обычно пользуются относительно небольшим количеством централизованных источников данных, например базами данных. Обеспечить синхронизированный доступ к этим данным существенно сложнее, чем распределить вычислительную нагрузку. В SMP-серверах эту задачу решает единый образ операционной системы, а в кластерах же требуется брокер, специальное программное обеспечение промежуточного слоя, ответственное за работу с данными.
Для того чтобы построить подобный брокер, необходимо решить проблемы виртуализации данных и распределенного управления доступом к данным. Чтобы виртуализировать данные, требуется, прежде всего, построить единую схему, состоящую из метаданных. Пользуясь ею, специализированное программное обеспечение промежуточного слоя сможет поддерживать согласованный доступ к данным, устанавливая связи между программами и источниками данных не напрямую, как обычно, а опосредованно, через метаданные. Средствами виртуализации обеспечивается гибкость архитектуры, которая может изменяться незаметно для приложений, кроме того, данные могут перемещаться и реплицироваться в режиме, прозрачном для приложений.
После того как данные виртуализированы, появляется возможность построить распределенное управление ими, обеспечив примерно такую же легко изменяемую схему, которая используется в серверах приложений, где по мере возрастания нагрузки увеличивается количество включенных в процесс физических серверов. В данном случае происходит развязка данных и приложений; изменение в топологии расположения данных не влияет на приложения, а изменения в приложениях, в свою очередь, не влияют на изменение топологии данных.
Готовых решений, позволяющих решить эти две задачи, на рынке пока нет, но прототипом для них может послужить результат сотрудничества компаний IBM и GemStone, где средствами пакета GemFire Enterprise, относимого к категории программного обеспечения, связывающего данные (Data Сonnectivity Software, DCS), обеспечивается доступ к данным в IBM BladeCenter, в котором может быть установлено до 84 лезвий.
Из двух компаний-партнеров GemStone Systems известна гораздо меньше. Впрочем, и эта компания — не новичок, она обладает значительным своеобразием и богатой историей и существует почти 25 лет, оставаясь при этом частной. Преимущественное положение частной компании заключается в том, что она может следовать самостоятельной технической политике и создавать оригинальные продукты, не подчиняясь требованиям инвесторов. Эти продукты могут оставаться долгое время невостребованными, но однажды наступает момент, когда одна из разработок компании вдруг оказывается весьма кстати. Подобное случилось с флагманским продуктом компании, GemFire Enterprise, — фирменной версией механизма матрицы данных предприятия (Enterprise Data Fabric, EDF). GemFire Enterprise выполняет функцию программного обеспечения промежуточного слоя для работы с данными. Вкупе с наработками IBM программное обеспечение GemFire Enterprise позволяет реализовать основные функции корпоративной информационной системы на базе IBM eServer Blade Center.
Устройство GemFire представляет собой пример изящного инженерного решения (на сайте www.gemstone.com оно описано с достаточной полнотой). Создателям GemFire удалось свести две названные выше проблемы к решению шести задач.
- Построение архитектурной модели распределенной кэш-памяти. В этой модели фрагменты оперативной памяти отдельных серверов представляются как составляющие «устройства» общей кэш-памяти, предназначенной для ускорения доступа к данным, размещенным на дисках. Квинтэссенцией архитектурной модели является внутренняя сеть, объединяющая кэши в оперативной памяти каждого из серверов; таким образом формируется глобальный системный кэш. В сети GemFire Enterprise используются две взаимодополняющие друг друга технологии обмена данными. Технология многоадресной рассылки IP multicast служит для массовой рассылки данных по узлам. Другая технология служит для обычного обмена данными между узлами в режиме «каждый с каждым» по протоколу TCP . Единство распределенного системного кэша достигается благодаря тому, что из кэша каждого узла выделяется специальная область, локатор (locator), и эти отдельные области объединяются сетью для нужд общего сервиса. Данные в системном кэше организованы таким образом, что обеспечивается отказоустойчивость, выключение одного сервера не приводит к потере системных данных
- Разработка модели распределения и управления распределением данных по общей системной кэш-памяти. Данные и приложения могут различаться по требованиям к синхронизации. Естественно, чем выше требования к синхронизации, тем выше задержка. Наиболее типичным является асинхронный режим. Он предполагает, что каждое приложение работает со своим кэшем асинхронно по отношению ко всем остальным в режиме out-of-band, но периодически осуществляется синхронизация, выбранный алгоритм синхронизации обеспечивает минимизацию конфликтов. Синхронный режим с подтверждением отличается тем, что узел, инициирующий изменения, требует подтверждения, чтобы внесение изменений в кэши других узлов было подтверждено сообщением. Самый строгий синхронный режим предполагает репликацию данных между узлами. В GemFire используется несколько механизмов репликации, которые различаются по своей строгости. Самый легкий — репликация по требованию (replication on demand), в этом случае объект реплицируется по месту использования; самый тяжелый — тотальная репликация (total replication), реализуемая по модели принудительной (push) рассылки.
- Разработка средств, обеспечивающих высокую готовность и отказоустойчивость. Основным средством для обеспечения надежности служит хорошо проверенная технология зеркалирования. В случае сбоя GemFire Enterprise автоматически переключает приложение на резервную копию кэша и восстанавливает основной кэш. В некоторых случаях для резервирования используют дисковые копии.
- Обеспечение гетерогенности доступа к данным. В GemFire Enterprise созданы специальные интерфейсы API для доступа к объектам из клиентов, написанных на разных языках программирования и для разных платформ. Кроме работы с объектами, GemFire позволяет использовать механизм кэширования для XML-документов, используя протоколы HTTP и SOAP.
- Разработка методов взаимодействия между приложениями и распределенной системой кэш-памяти. GemFire имеет встраиваемые интерфейсы, позволяющие устанавливать связь с базами данных и приложениями. Для этого прежде всего служит корпоративная шина JMS. Разработчики могут использовать механизм, включающий загрузчик CacheLoader, приписывающий внешние данные в кэш, а также пару, состоящую из «писателя» CacheWriter и «слушателя» CacheListener, предназначенную для синхронизации данных.
- Разработка средства для управления системой в целом. GemFire Enterprise включает в себя целый ряд инструментов для администрирования. Специальная консоль с графическим интерфейсом позволяет осуществлять управление с одного из компьютеров, включенных в кластер. Средствами консоли можно изменять топологию системного кэша, включать или выключать отдельные фрагменты, набирать статистику, строить обобщающие диаграммы.
***
Область потенциального применения GemFire Enterprise не ограничивается использованием в качестве программного обеспечения промежуточного слоя в кластерах. В последующем она может быть распространена на сервис-ориентированные архитектуры, системы обработки сложных событий и разнообразные реализации grid.
* Данная величина фактически равна одному вершку. Вот так неожиданно старорусская единица измерения по удивительному совпадению (а может быть, и по чьему-то остроумному замыслу) обрела новую жизнь. — Прим. автора.
Рисунок.
