Кластерные системы. Общие положения

1. Кластерные системы. Общие положения.

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

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

Вычислительные узлы Grid всегда расположены далеко друг от друга, слабо связаны между собой через интернет-каналы, и доступность того или иного из них в произвольный момент времени не гарантирована. Это накладывает дополнительные требования на управление ресурсами. Структура Grid — это виртуальная организация, образованная над пространством реальных компьютеров, сетей, административных зон. Задача виртуальной организации — создать среду, где части одного приложения, выполняемые на разных компьютерах, будут взаимодействовать между собой. Более того, подразумевается, что к системе можно динамически подключить произвольный новый ресурс — а значит, модель коммуникаций должна быть строго стандартизирована. При этом их коммуникации не должны зависеть от среды выполнения. Происходит ли вычисление в рамках одного компьютера, в локальной сети или в глобальной, объединяющей множество организаций, - это должно оставаться прозрачным для приложения.

2. Связующее ПО.

Существует класс промежуточного программного слоя, который обеспечивает прозрачную работу приложений в неоднородной сетевой среде. Это так называемое межплатформенное связующее программное обеспечение (middleware). Оно является посредником между подзадачами, выполняемыми на удалённых друг от друга компьютерах. Связующее ПО предоставляет набор программных инструментов для обмена сообщениями в рамках сетей, вызова удалённых процедур, управления доступом к ресурсам и других механизмов управления.

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

Среди проектов связующего ПО выделяются три лидера — это Globus Toolkit, UNICORE и gLite. Всё это сервис-ориентированные системы, во много реализующие общие стандарты и технологии работы с кластерами. Далее мы рассмотрим архитектуру и ключевые элементы этих проектов.

3. Globus Toolkit.

Компоненты.

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

Поиска и выделения ресурсов. Коммуникаций. Аутентификации. Информационные. Доступа к данным. Создания процессов.

На основе этих низкоуровневых компонентов строятся сервисы более высокого уровня.

Коммуникационные механизмы.

Рассмотрим для примера как коммуникационный модуль Globus обеспечивает однородность доступа к ресурсам. При вызове коммуникационной процедуры модуль должен задействовать одну из имеющихся функций. В локальной сети это обращение по TCP/IP, в рамках параллельного компьютера – по внутренним высокоскоростным каналам, в глобальной сети – по ATM.

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

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

Сообщение вычислительных узлов в кластерной системе осуществляется по различным каналам. Необходимо не просто Коммуникации в Globus основаны на библиотеке Nexus, где определены пять главных абстрактных сущностей. Это узлы, потоки, коммуникационные звенья, контексты и удалённые запросы. Nexus связывает начальные и конечные пункты обмена сообщениями, образуя коммуникационные звенья. С одним пунктом получения может быть связано несколько пунктов отправки и наоборот – так образуется групповая передача и сбор информации, в чем-то аналогичная обмену сообщениями. Коммуникационное звено поддерживает единственную операцию – асинхронное удалённое обслуживание направляемого запроса (RSR). В точке создания запроса указывается название процедуры и выделяется буфер под ее аргументы. В каждой точке получения RSR удаленно запускает эту процедуру.

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

Доступ к данным.

Перманентные данные в кластере физически, скорее всего, распределены по нескольким компьютерам. Для обеспечения прозрачного доступа к ним в Globus используется интерфейс удаленного доступа RIO, базирующийся над абстрактным устройством ввода-вывода (ADIO – Abstract Device I/O). В ADIO определен интерфейс для открытия, закрытия, чтения и записи файлов в параллельном режиме. Обращение программ к локальной файловой системе идет через ADIO, то есть, независимо от системы, в которой реально хранятся данные.

Директории метакомпьютера и информация о среде.

В процессе работы виртуальной организации требуется информация о сети и вычислительных ресурсах системы в целом. Это могут быть такие параметры, как пропускной порог внутренних каналов, изначальная загрузка процессоров, количество вычислительных узлов и их мощность и т. д. Может понадобиться также информация о приложениях – например, об их ресурсоемкости.

Часть этой информации используется глобально, другие части имеют смысл только для отдельных областей видимости. Её источники разнообразны – какие-то данные предоставляют сами приложения, какие-то – стандартные информационные службы или специализированные сервисы. Globus объединяет все эти разнородные данные и предоставляет к ним однородный доступ посредством сервиса метакомпьютерной директории (MDS – Metacomputing Directory Service). Информация организована в виде набора структур, каждая из которых является списком пар ключ – значение. В значениях записываются атрибуты, содержащие административную и системную информацию.

Высокоуровневые сервисы Globus.

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

Другим важным примером могут служить адаптации сервисов Globus к интерфейсам параллельного программирования. Это и известная реализация интерфейса обмена сообщениями – библиотека MPICH-G2, и инфраструктура распределенных кластерных вычислений Condor, и другие широко используемые библиотеки.

4. UNICORE.

Архитектура.

UNICORE (UNiform Interface to COmputing REsources) – однородный интерфейс для распределенных вычислений. UNICORE предоставляет интернет-доступ к узлам системы, где различие в аппаратных платформах, механизмы безопасности и обмен информацией скрыты от конечных пользователей.

Архитектура UNICORE трёхслойная. В неё входят: пользовательский уровень, UNICORE сервер и целевая система, где будет выполняться приложение. Компоненты взаимодействуют между собой в открытой сети через SSL (Secure Socket Layer) протокол. Для установления клиент-серверного соединения SSL использует криптографию с открытым ключом, так что каждый компонент должен иметь открытый и секретный ключи. Ключи получают сертификат, чтобы компонент мог быть идентифицирован как безопасный.

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

Абстрактные задания.

В модели UNICORE ключевым является понятие абстрактного задания (AJO – Abctract Job Object). Это объект, который создается на основе данных, полученных из пользовательского интерфейса и среды выполнения, и отправляется через шлюз по протоколу UNICORE, базирующемуся на SSL. AJO – ключевой элемент архитектуры UNICORE. Он задает стандарты обмена между пользовательскими данными и управляющей сетевой программой и напрямую взаимодействует с сервером UNICORE.

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

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

Клиентская часть.

Клиентская часть UNICORE – это графический пользовательский интерфейс. Он дает возможность подготавливать UNICORE задачи и следить за их выполнением, а также управлять настройками безопасности. Через интерфейс UNICORE пользователь указывает параметры, относящиеся к задачи – например, ресурсы, аргументы командной строк, файлы и т. п. Диспетчерская служба определяет, может ли задание быть выполнено в выбранной системе, и если ответ положительный, выносит задачу на следующий этап. Трансляция абстрактного определения задачи в исполняемый пакет на реальной машине также происходит через сетевой диспетчер (NJS ).

Сетевой диспетчер заданий.

Отдельные системы или кластеры с единым файловым и пользовательским пространством в общей модели UNICORE представлены как виртуальные сайты. Каждым сайтом управляет сетевой диспетчер заданий NJS (Network Job Supervisor). NJS выполняет следующие функции:

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

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

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

Как уже говорилось, задание описано в абстрактных терминах. У NJS имеется таблица соответствий, согласно которой абстрактные команды преобразуются в исполняемые команды целевой системы. Поэтому пользователю достаточно сформулировать задание в общем виде и не вдаваться в детали платформенной реализации. После распаковки задания обслуживаются интерфейсом целевой системы (TSI – Target System Interface).

Аутентификацию пользователей, безопасную трансляцию данных и информирование о доступных ресурсах обеспечивает шлюз. Это один из элементов серверной части UNICORE. Он отвечает также за ретрансляцию заданий, данных, команд и аутентификационных атрибутов. Шлюз UNICORE поддерживает работу с дополнительными локальными системами безопасности.

5. gLite.

Архитектура gLite сервис-ориентированная. Сервисы могут работать объединённо, выполняя задачу конечного пользователя, или же будучи применёнными изолировано, в контексте самостоятельной задачи. Высокоуровневые сервисы gLite подразделяются на следующие группы:

Сервисы безопасности. Информационные службы и мониторинг. Сервисы управления заданиями. Сервисы управления данными.

Далее мы рассмотрим механизмы gLite, базирующиеся на этих сервисах и основные объекты этой системы.

Управление заданиями.

Сеть на основе gLite представляет совокупность вычислительных элементов (CE – Computing Element). Вычислительный элемент предоставляет внешний интерфейс для запуска заданий и управления ими, а также отдаёт информацию об инкапсулируемом им ресурсе. Это может быть как компьютерный кластер, так и отдельный компьютер.

Распределение заданий между вычислительными элементами обеспечивает система управления нагрузкой WMS (Workload Management System).

Для эффективного управления виртуальными ресурсами WMS должна принимать во внимание и требования задания, и параметры доступных узлов, где оно будет выполняться. Основной компонент WMS, менеджер загрузки, принимает запрос о ресурсах и направляет задание вычислительному узлу. Узел выбирается из числа доступных на данный момент, в соответствии с требованиями к ресурсам и предпочтениями, указанными в описании задания.

Описание задания составляется на специальном языке JDL (Job Description Language).

Хранение данных.

Для хранения данных существует абстракция, аналогичная вычислительному элементу – это накопительный элемент SE (Storage Element). Он предоставляет виртуализацию реальных накопителей. Кроме этого сервиса, имеется сервис управления данными и сервис файлов и реплик. Модульность всех этих сервисов поддерживается на уровне файлов. Для пользователя эта структура видна как единая Unix-подобная файловая система.

Информационные службы.

Сбор информации о ресурсах и запущенных заданиях в gLite – это реализация архитектуры мониторинга в Grid, в частности R-GMA (Relational Grid monitoring Architecture). GMA – это базовая архитектура мониторинга, определенная Global Grid Forum. Она состоит из трёх компонентов – «производителя», «потребителя» и реестра. «Производитель» регистрирует тип и структуру информации, которая должна быть доступна системе Grid. «Потребители» через реестр запрашивают информацию и получают сведения о том, какой узел ее предоставил. После того, как реестр выдаёт данные о производителе, потребитель может установить связь с ним напрямую, чтобы обменяться необходимыми данными.

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

Безопасность.

Безопасность в gLite реализована на основе тех же проверенных технологий открытого и секретного ключей доступа и сертификатах X.509. Каждая транзакция в системе Grid обоюдно проверяется клиентской и серверной сторонами. За глобальным доступом и регистрацией виртуальных организаций следит сервис принадлежности к виртуальной организации VOMS (Virtual Organization Membership Service).

На стороне аутентификации накопитель учетных данных удостоверяет запись пользователя или приложения, пытающегося получить доступ к ресурсам сети, прокси-сертификаты позволяют выполнить вход. Целостность, подлинность и конфиденциальность обеспечиваются на основе технологии цифровых подписей. gLite использует широко используемую спецификацию GSI, защищённые протоколы передачи данных TLS и WS-Security (Web Services Security).

6. Заключение.

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

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

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

Очевидно, что хотя проекты Globus Toolkit, UNICORE и gLite во многом отличаются по реализации, все они успешно выполняют одну и ту же задачу — предоставляют пользователям полноценное управление распределёнными ресурсами. Систему Globus можно охарактеризовать как набор инструментов для разработки Grid приложений на основе сервисов. Unicore ориентирован на однородный доступ к компьютерам. gLite предоставляет основу для создания распределенных приложений. Поэтому значимым этапом на пути развития Grid приложений стала возможность объединить все три проекта. Стартовавший в 2006 г. проект OMII-Europe в 2008 г. анонсировал создание программных компонентов, поддерживающих совместное функционирование Globus, Unicore и gLite. Таким образом, у пользователей каждой из рассмотренных нами виртуальных платформ Grid появляется потенциальный доступ к сетям остальных платформ. Grid вычисления становятся всё более интегрированными.

Об авторе

Ирина Парошина - разработчик программного обеспечения (C#, C++, T-SQL). Кандидат физико-математических наук. Многократно публиковала свои статьи в международных изданиях; основное направление - численное моделирование физических процессов. Хобби, по значимости равноценное основной работе - дизайн и фотография.