ЖУРНАЛ «СТА» №3/2004

55 СТА 3/2004 www.cta.ru параллельными ветвями представля- ется разделение на уровне потоков (thread). Последовательно наблюда- лись массовая реализация механизмов thread в аппаратных платформах (на- чало 90х), поддержка абстракций thread в операционных системах (19941996) и отражение их в стандар- тах POSIX (конец 90х). Одной из са- мых существенных технических труд- ностей при построении таких архитек- тур является необходимость обеспече- ния когерентности данных в локаль- ных устройствах кэшпамяти каждого из процессоров. В кластерных системах предполага- ется, что каждый из узлов является ти- повой вычислительной архитектурой со своим процессором, оперативной памятью, каналами вводавывода и т.д., а кооперация узлов осуществля- ется через некоторые каналы передачи данных между ними. В такой архитек- туре распараллеливание работ реализу- ется на уровне процессов, каждый из которых выполняется на своём узле вычислительной структуры. И та и другая модель имеет как свои преимущества, так и свои недостатки, баланс которых может существенно смещаться в зависимости от класса ре- шаемых задач. Все про- чие многопроцессорные архитектуры могут рас- сматриваться как линей- ная комбинация реше- ний, почерпнутых из этих двух моделей. Из приведённых об- щих соображений уже должно быть достаточно понятно, что если SMPструктуры пригод- ны только для наращива- ния производительности системы, то кластерные системы, кроме того, мо- гут быть использованы и для повышения «живу- чести» системы в приме- нениях, где должна быть обеспечена высокая на- дёжность. Действитель- но, в Nпроцессорном кластере при выходе из строя любого количества хостов до (N1) система может сохранять работо- способность (правда, обычно со снижением общей производительно- сти) за счёт перераспре- деления загрузки между оставшимися хостами. О БЩЕЕ ОПИСАНИЕ ПРОЕКТА Идея того, что QNXхосты, объе- динённые сетью QNET, сами по себе уже являются полноценным многома- шинным кластером, появляется у каж- дого, кто только знакомится с необыч- ной и остроумной организацией опера- ционных систем (ОС), использующих принцип микроядра и обмена сообще- ниями (рис. 2). Действительно, ● каждый QNXхост в сети обладает собственным микроядром ОС; ● микроядро QNX с одинаковой лёгкостью обменивается сообще- ниями уровня микроядра по схеме Send–Receive–Reply как с процесса- ми на своём собственном хосте, так и с процессами на удалённых хос- тах; ● стоит «нагрузить» сообщения уровня микроядра целевой информацией для взаимодействия разнесённых частей распределённого приложе- ния… и кластер готов. Идея «кластерности», уже заложен- ная в архитектуру QNX, достаточно широко используется разработчиками систем на практике, но в несколько другом аспекте: на N хостах сети QNET размещают функционально различные части единой системы, которые могут легко взаимодействовать между собой. Меня же заинтересовала идея исполь- зования симметричного кластера: от- дельные части единой задачи разбро- сать между идентичными процессами на хостах. Сравните простоту такой модели с необходимостью реализации взаимо- действия (скажем, «над слоем» TCP/IP) между составными частями кластерного приложения в традицион- ных ОС! Забегая вперёд, скажу по соб- ственному опыту, что у представленно- го далее проекта трудоёмкость (объём) реализации оказывается на 1 или 2 по- рядка ниже, чем у аналогичного проек- та, скажем, в Linux или в Windows. В предложенном к рассмотрению проекте показана возможная реализа- ция кластерных вычислений в системе из нескольких универсальных компью- теров, работающих под управлением ОС QNX (версия, начиная с QNX Momentics 6.2) и объединённых сетью QNET. Для реализации QNET доста- точно объединения хостов любого рода сетью Ethernet или даже низкоскорост- ными каналами с протоколом IP. Собственно, проект содержит две за- дачи (программы): а) целевая задача, которую предстоит решить кластерно- му вычислителю; б) задача, организую- щая решение целевой задачи на кла- стере, то есть распараллеливающая её исполнение. Рассмотрим их по поряд- ку. Ц ЕЛЕВАЯ ЗАДАЧА В качестве целевой задачи следовало выбрать задачу из числа тех, которые хорошо распараллеливаются и приме- ры которых приведены в начале статьи. Для демонстрации кластерной обра- ботки я выбрал задачу криптоанализа – поиска ключа шифрования, которым криптографирован неизвестный текст, образец которого мы имеем. В целом эта затея очень напоминает хорошо из- вестный проект Distributed.net (www.distributed.net ), с той лишь разни- цей, что в нём анализируют крипто- стойкость известных и хорошо себя за- рекомендовавших алгоритмов, а я ис- пользую простейший алгоритм крип- тографирования — XORсвёртку с не- известным ключом. На сайте журнала по адресу www.cta.ru/archive/3 2004 приводится полный текст работающей программной П Р О Г РАММНО Е ОБ Е С П Е Ч Е НИ Е / СИС Т ЕМЫ Р Е АЛ Ь НО ГО В Р ЕМЕ НИ MsgSend MsgReply open() MsgSend X open() MsgReply Y Рис. 2. Если в «микроядерной» архитектуре стандартные операции POSIX (например, open) выполняются посылкой микроядром сообщений от одного процесса к другому ( а ), ничто не препятствует тому, чтобы, используя абсолютно тот же механизм, выполнить запрос к процессу, выполняющемуся на совершенно другом сетевом хосте ( б ), — в этом принципиальное отличие «микроядерных» ОС (QNX, NextStep, Darwin и др.) от традиционных ОС с монолитным ядром (Windows, Linux и др.)