CC BY
29
Для выполнения системных операций за приемлемое время требуется применение элементов параллелизма на системном уровне. Для координирования системных операций один из узлов кластера ФС назначается системным менеджером ФС. Системный менеджер занимается вопросами координации кластерных системных операций. Менеджер содержит несколько записей, похожих на inode, и раздает работу другим узлам. Если узел ФС закончит работу в своей зоне раньше, он может запросить дополнительную зону у менеджера. Для больших систем
хранения нужно предусматривать выполнение всех системных операций в фоновом режиме при регулируемом приоритете системных операций. Исключением является операция полной проверки целостности ФС, когда требуется размонтировать ФС.
В Москве, в Межведомственном суперкомпьютерном центре РАН при содействии специалистов НИИ «Квант» и ИПМ им. Келдыша успешно апробированы многие идеи на уникальных высокопроизводительных вычислительных установках.
СЛУЖБА КАТАЛОГОВ КАК КЛЮЧЕВОЙ ЭЛЕМЕНТ ИНФОРМАЦИОННОЙ СИСТЕМЫ GRID
Н.Ю. Шульга
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-запрос может быть выполнен за одинаковое время. Очевидно, что при различной аппаратной конфигурации серверов или в случае существенно разных времен обработки входящих запросов (примером таких запросов могут служить запросы на поиск объектов по сложному фильтру) нагрузка между серверами будет распределяться неравномерно.
Для эффективного распределения нагрузки между серверами службы каталогов различной производительности каждому из серверов сопоставляют специальную ХКУ-запись в службе доменных имен, в которой, помимо информации о сетевых адресах сервера, будет храниться и его приоритет. Тогда клиент службы каталогов сможет использовать информацию о приоритетах при распределении запросов между серверами.
При увеличении количества серверов службы каталогов возникает вопрос отказоустойчивости системы в целом. В любом из вышеописанных алгоритмов распределения нагрузки в случае аппаратного или программного сбоя одного из серверов среднее время отклика системы существенно увеличится, так как прежде чем направить запрос на следующий сервер, клиент службы каталогов будет ждать ответа от сервера, пока не истечет максимально допустимое время ожидания ответа. Этот параметр часто на несколько порядков превышает среднее время обработки запроса, поэтому
при обнаружении сбоя необходимо исключить временно не функционирующий сервер из системы. Обнаружение работающих в сети серверов службы каталогов происходит через запрос к службе доменных имен, где сетевые адреса серверов хранятся либо в виде 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 приведено в таблице.
Группа атрибутов Название класса Замечания
Идентификатор и пароль пользователя shadowAccount Вспомогательный LDAP-класс к person
Путь к домашнему паролю, UNIX-идентификаторы posixAccount Вспомогательный класс к person
SID и путь к Windows-профилю пользователя SambaSAMAccount Вспомогательный класс к posixAccount
Контактная информация и идентификатор пользователя person/inetOrgPer-son Основной класс, хранящий контактную информацию
Принадлежность пользователя к группам posixGroup/group-OfNames posixGroup и groupOfNames -основные классы
Все серверы службы каталогов зарегистрированы в службе доменных имен как доменное имя, обладающее несколькими сетевыми адресами. Вспомогательные серверы службы каталогов обновляют свою базу, используя ри/1-алгоритм обновлений, путем периодической отправки запросов на обновление к основному серверу. Существует динамически обновляемая зона, в которой присутствуют, по крайней мере, три записи, содержащие адрес основного сервера, адреса всех зарегистрированных в сети ЬБАР-серверов и ав-
томатически обновляемую запись, содержащую адреса всех функционирующих в данный момент времени LDAP-серверов.
Группа LDAP-серверов обрабатывает в сред-
нем тысячу запросов в минуту, при этом среднее время обработки запроса составляет 0.04 секунды, то есть пиковая нагрузка может достигать 250 запросов в секунду.
СЕТИ ВЫСОКОПРОИЗВОДИТЕЛЬНЫХ КЛАСТЕРНЫХ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ И ИХ ИНТЕГРАЦИЯ В ЛОКАЛЬНУЮ СЕТЬ СУПЕРКОМПЬЮТЕРНОГО ЦЕНТРА
А.П. Овсянников
Кластерная вычислительная система представляет собой совокупность вычислительных узлов, объединенных коммуникационной средой, предназначенной для обмена данными и организации процесса вычислений. Помимо вычислительных узлов в кластерную вычислительную систему могут входить узлы специального назначения, например, узлы ввода-вывода, управления, мониторинга. Довольно часто коммуникационная среда организована в виде нескольких сетей, отличающихся своим функциональным назначением. Принято различать коммуникационную сеть, предназначенную для обмена данными между вычислительными узлами в процессе вычислений; транспортную сеть, предназначенную для передачи данных между вычислительными узлами и хранилищем данных; управляющую сеть, предназначенную для организации вычислений и мониторинга вычислительной системы.
Сетевые решения вычислительной системы МВС15000ВМ
Коммуникационная среда вычислительной системы МВС15000ВМ включает коммуникационную сеть, выполненную по технологии Myrinet (пропускная способность 2 Гбит/с), и раздельные транспортную и управляющую сети, выполненные по технологии Gigabit Ethernet. Каждый вычислительный узел кластера имеет адаптер Myrinet M3S-PCIXD-2-I. Вычислительные узлы подключаются при помощи оптических кабелей связи к двум 256-портовым и одному 128-портовому коммутаторам сети Myrinet. Коммутаторы связаны друг с другом в кольцо таким образом, чтобы обеспечивалась возможность одновременного установления попарных соединений между всеми вычислительными узлами. Скорость передачи данных между двумя вычислительными узлами с использованием библиотек MPI находится на уровне 200-250 Мбайт/сек.
Транспортная сеть Gigabit Ethernet предназначена для соединения решающего поля с управляющей станцией, параллельной файловой подсистемой и файл-сервером NetApp F840. Ядром
сети является высокопроизводительный коммутатор Cisco Catalyst 6509. Второй уровень организован на коммутирующих модулях Nortel Networks, встроенных в базовые блоки вычислительной системы, объединяющие по 14 вычислительных узлов. К коммутирующему модулю каждого базового блока подключены внутренними гигабитными каналами 14 вычислительных модулей базового блока. Коммутирующий модуль каждого базового блока подключен к центральному коммутатору Cisco Catalyst 6509 агрегированными каналами 4 Гбит/с.
Управляющая сеть, построенная с использованием технологии Gigabit Ethernet, предназначена для запуска программ на счёт вычислительными модулями, а также для передачи служебной информации о ходе вычислительного процесса и состоянии подсистем. Центральным коммутатором является Cisco Catalyst 6509. Второй уровень организован на коммутирующих модулях Nortel Networks, встроенных в базовые блоки. К коммутирующему модулю каждого базового блока подключены внутренними гигабитными каналами 14 вычислительных модулей базового блока. Коммутирующий модуль каждого базового блока подключен к центральному коммутатору Cisco Catalyst 6509 каналом 1 Гбит/с.
Центральный коммутатор вычислительной системы МВС-15000ВМ подключается к сети Межведомственного суперкомпьютерного центра (МСЦ) РАН одним 10-гигабитным и 8-гигабитными агрегированными оптическими каналами связи.
Коммуникационная среда вычислительной системы МВС60001М
Вычислительные узлы связаны между собой высокоскоростной коммуникационной сетью Myrinet (пропускная способность 2 Гбита/сек), транспортной сетью Gigabit Ethernet и управляющей сетью Fast Ethernet. Коммуникационная сеть Myrinet предназначена для высокоскоростного обмена между ВМ в ходе вычислений. Сеть реализована на базе 128 портового полносвязного ком-
