Software & Systems

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

В информационной системе GRID особенно остро встает проблема синхронизации информации о пользователях и их правах доступа на всех узлах GRID-установки. С другой стороны, все компоненты распределенного менеджера системы очередей должны быть обеспеченны актуальной информацией о доступности и загруженности вычислительных компонентов GRID. Так как требования по безопасности и отказоустойчивости, предъявляемые к обоим компонентам информационной системы совпадают, то будет логично использовать единый протокол для доставки как информации о пользователях, так и о доступности вычислительных компонентов GRID и решаемых на них задачах. Протокол службы каталогов LDAP хорошо подходит для решения подобной задачи. Использование расширений TLS или SSL гарантирует достоверность доставляемых данных, в то время как SRV-записи в доменной системе имен и протокол распределенной репликации данных между серверами позволяют построить информационную систему требуемого уровня надежности.

LDAP как инфраструктура для доступа к публичным ключам

В директории LDAP можно хранить информацию о сертификатах пользователя, быстро находить все компоненты цепи доверительных связей и эффективно проверять достоверность предъявленного сертификата. Любой объект, хранящийся в системе каталогов, может принадлежать к нескольким классам объектов. Таким образом, объект содержащий сертификат, находящийся в цепочке доверительных связей, также может содержать информацию о вычислительных квотах. Вычислительный компонент GRID, получив задачу, удостоверенную сертификатом пользователя и используя PKI (Private key intfrastrucute), реализованную на базе LDAP, может не только проверить, что эта задача действительно поставлена на счет данным пользователем, но и убедиться, что эта группа пользователей еще не исчерпала выделенную им квоту.

LDAP как каталог GRID ресурсов и задач

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

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

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

Масштабируемость и отказоустойчивость службы каталогов

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

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

Самым простым способом распределения нагрузки является метод round-robbin, когда серверы службы каталогов обрабатывают запросы по циклу. Например, если система состоит всего из двух серверов, то все нечетные запросы будут приходить на первый сервер, а все четные – на второй. Такой подход дает хорошие результаты, если аппаратные характеристики серверов приблизительно одинаковы и если любой LDAP-запрос может быть выполнен за одинаковое время. Очевидно, что при различной аппаратной конфигурации серверов или в случае существенно разных времен обработки входящих запросов (примером таких запросов могут служить запросы на поиск объектов по сложному фильтру) нагрузка между серверами будет распределяться неравномерно.

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

При увеличении количества серверов службы каталогов возникает вопрос отказоустойчивости системы в целом. В любом из вышеописанных алгоритмов распределения нагрузки в случае аппаратного или программного сбоя одного из серверов среднее время отклика системы существенно увеличится, так как прежде чем направить запрос на следующий сервер, клиент службы каталогов будет ждать ответа от сервера, пока не истечет максимально допустимое время ожидания ответа. Этот параметр часто на несколько порядков превышает среднее время обработки запроса, поэтому при обнаружении сбоя необходимо исключить временно не функционирующий сервер из системы. Обнаружение работающих в сети серверов службы каталогов происходит через запрос к службе доменных имен, где сетевые адреса серверов хранятся либо в виде A-записей, либо в виде уже упоминавшихся SRV-записей. То есть для того чтобы исключить временно не работающий сервер из комплекса, реализующего доступ к каталогу по протоколу LDAP, достаточно удалить ссылку на IP-адрес этого сервера из службы доменных имен. Так как сбой сервера – это явление довольно редкое, то кажется логичным, что такие сбои можно обрабатывать вручную. С другой стороны, так как сбой может произойти в любое время суток, и то время, пока сбойный сервер присутствует в списке серверов службы каталогов, эффективность работы службы каталогов и всех служб, от нее зависящих, падает в несколько раз, возникает задача автоматизации системы обнаружения сбоя и удаления нефункционирующего сервера из списка серверов службы каталогов.

Автоматизированная система обнаружения сбоев должна быть легко переносимой с одной программно-аппаратной платформы на другую. В силу этих причин было принято решение реализации данной системы на кросс-платформенном транслируемом объекто-ориентированном языке программирования Python. Для взаимодействия со службой каталогов был использован программный пакет dnspython, а для реализации взаимодействия со службой каталогов был использован пакет ldap, входящий в стандартный набор пакетов языка.

Обновления записей в службе доменных имен происходят путем создания объекта класса dns.update.Update, а опрос серверов системы каталогов происходит с использованием синхронных запросов ldap.search_s по шифрованному SSL-ка­налу.

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

В Межрегиональном суперкомпьютерном центре (МСЦ) РАН (Москва) служба каталогов LDAP была внедрена в конце 2003 – начале 2004 годов как следующий виток развития системы авторизации и аутентификации пользователей. Предпосылками для этого послужили принципиальные недостатки разработанного в 1985 году протокола NIS, который использовался для распространения информации о пользователях из централизованного репозитария учетных записей, а именно ограничение на максимальное количество пользователей, отсутствие каких-либо механизмов защиты передаваемых данных и принципиальное отсутствие системы разграничения привилегий, что приводило к тому, что любой компьютер в локальной сети мог получить hash-сумму пароля пользователя.

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

Все объекты каталога МСЦ РАН расположены в подпространстве имен, начинающихся с доменного имени МСЦ, например dc=jscc,dc=ru. Все UNIX-группы пользователей в пространстве имен LDAP расположены напрямую за корневым объектом. Объекты, описывающие пользовательский профиль, располагаются внутри объектов групп, которые соответствуют первичной группе в учетной записи этого пользователя. Таким образом, полное уникальное имя пользовательского объекта в системе каталогов состоит из имени учетной записи пользователя в UNIX-подобных операционных системах, имени первичной группы пользователя и имени корневого объекта LDAP МСЦ РАН. Например, полное уникальное имя LDAP-объекта, в котором хранится профиль пользователя ivanov, первичной группой которого является группа project17, будет иметь следующий вид: uid=ivanov,cn=project17,dc=jscc,dc=ru. Отображение основных атрибутов профиля пользователя на классы объектов LDAP приведено в таблице.

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

Группа LDAP-серверов обрабатывает в среднем тысячу запросов в минуту, при этом среднее время обработки запроса составляет 0.04 секунды, то есть пиковая нагрузка может достигать 250 запросов в секунду.