Лекция
Архитектура системы X-Com
1. Основные компоненты системы
/>
Система X-Com реализована попринципам клиент-серверной архитектуры, в которой можно выделить два основныхкомпонента.
Сервер X-Com– центральная часть системы, содержащая сервернуючасть программы пользователя и отвечающая за:
разделение исходной задачи на блоки
распределение заданий
координацию работ всех узлов
контроль целостности результата
сбор результата расчета в единоецелое
Узел – любая вычислительная единица(рабочая станция, узел кластера, виртуальная машина), на которой происходитосновной расчет прикладной программы. Отдельные блоки вычислительной задачипередаются от сервера на узлы, где происходит расчет, результаты которогопередаются обратно на сервер. Узлы отвечают за:
расчет блоков прикладной задачи
запрос заданий для расчета от сервера
передачу результатов расчета насервер
Все коммуникации между узлами исервером в X-Com происходят через сеть Интернет. При этом используетсятолько стандартный протокол HTTP (HyperText Transfer Protocol), что позволяет подключать к системепрактически любые вычислительные мощности, имеющие доступ в Интернет. Системане требует настройки для работы через прокси-сервера, firewall и другие системы защиты. Данные, передаваемыесистемой, аналогичны стандартному трафику Интернет.
2. Иерархия узлов и серверов
/>
Для организации более эффективныхкоммуникаций и подключения большего количества узлов система может бытьорганизована в виде произвольного иерархического дерева. Листьями такого деревавсегда будут вычислительные узлы, в корне дерева – останется центральный серверX-Com.
Промежуточные сервера (такие какСервер-2 на рисунке) с точки зрения центрального сервера выглядят как обычныевычислительные узлы, а с точки зрения нижележащих вычислительных узлов какцентральный сервер.
Полная архитектура системы несодержится и не управляет ни одним из компонентов системы. С точки зренияцентрального сервера любой нижележащий промежуточный сервер выглядит какобычный узел, мощность которого в несколько раз превосходит мощность обычныхузлов.
Такой подход позволяет в любой моментвремени подключать и отключать как обычные вычислительные узлы, так и целыекластеры узлов, через промежуточный сервер.
На результат вычислений подключение иотключение узлов и серверов второго уровня не отразится, повлияет только напроизводительность системы в целом.
Сервера второго уровня целесообразновводить, когда коммуникационный канал между центральным серверов и серверомвторого уровня нестабилен или обладает малой пропускной способностью, а связьмежду промежуточным сервером и его узлами стабильная и поддерживает достаточновысокую скорость. Тогда промежуточный сервер буферизует некоторую порциюзаданий для нижележащих узлов и результатов вычислений. Без такого сервера разрывканала на время сопоставимое со временем расчет задачи на конечных узлах привелбы к потере результатов вычислений.
Очевидно, что любой сервер долженобеспечивать высокую стабильность работы и иметь достаточный размер дисковогопространства для хранения как заданий, так и результатов вычислений всехнижележащих узлов.
3. Архитектура серверов X-Comи вычислительных узлов
/>
Блок связи с прикладной программойпредставляет собой набор интерфейсов длявзаимодействия с серверной частью программы пользователя. В настоящейреализации система поддерживает 3 интерфейса связи с серверной частьюприкладной программы:
JavaAPI: для программ на языке Java.
С и C++ API: для программ на языках C и C++.Этим же интерфейсом можно пользоваться для линковки с любыми другими языкамиподдерживающими объектные файлы.
FilesAPI: простой интерфейс, где для взаимодействия с прикладнойпрограммой используются файлы, расположенные в файловой системе сервера.
Логика центрального сервера. Этот блок системы, определяеталгоритм распределенных вычислений: логикой распределения заданий по клиентскиммашинам, а также сбором и анализом результатов вычислений.
Блок логики центрального серверасопровождает и использует необходимую статистическую информацию (информация остатистике соединений с каждым конкретным узлом, его вычислительныхвозможностях, истории работы с узлом).
Блок логики центрального серверастроится по принципу стека интерфейсов, который последовательно переводитлогику пакетов от прикладной задачи к серверному коммуникационному блоку.
Система поддерживает три различныхспособа работы с блоком логики. Первый – самый низкий, это написание собственногоблока логики на низком уровне, при этом требуется лишь удовлетворятьпредложенным API. Второй уровень – это использованиенастроек, различных методов либо частичная замена методов в одном изстандартных блоков логики. И третий – это собственно выбор одного изстандартных блоков логистики.
Серверный коммуникационный блокотвечает за пересылку пакета с заданием на узлы итакже прием от узлов результатов вычислений. Подключение к узлам происходит попротоколу HTTP. Сервер X-Com имеет дваосновных режима взаимодействия, которые реализуются в серверномкоммуникационном блоке: синхронный и асинхронный. Синхронный режим означает,что на все время вычислений узел имеет доступ к серверу и статистика о решениизадачи передается в режиме online.Асинхронный режим означает периодический контакт и сбор статистики с клиентскиммодулем, вырожденным случаем асинхронного режима является выдача заданияклиенту и ожидание от него соединения с информацией об окончании расчета.
Клиентский коммуникационный блок находится на конечном вычислительномузле, либо в промежуточном вычислительном сервере. Основные функции клиентскогокоммуникационного блока – это прием пакета с заданием на клиентском компьютереи передача результатов расчетов.
Блок логики промежуточного сервера реализует функции буферизации,необходимые для работы промежуточного сервера. Напомним, что с точки зренияцентрального севера промежуточный сервер выглядит как обычный вычислительныйузел, с большой мощностью, что позволяет запрашивать ему большие пакеты вычислительныхзаданий. Эти блоки заданий буферизуются на промежуточном сервере ираспределяются между подключенными к нему узлами. Результаты вычислений такжебуферизуются на промежуточном сервере и передаются на центральный сервер. Сточки зрения нижележащего блока логики центрального сервера данных блокреализует API аналогичные интерфейсам блока связис прикладной программой.
Логика вычислительного узла– это блок, находящийся на конечных вычислительных узлахсистемы. Его основная функция – управление вычислительной частью прикладнойпрограммы пользователя и логикой ее работы (контроль версий, реализация разныхрежимов работы, и т.д.) В задачи данного блока также входит сбор информации отипе узла, на котором происходит расчет.
Блок связи с вычислительной частьюприкладной программы отвечает за взаимодействие с прикладной программой пользователя. Втекущей реализации системы предусмотрены 2 интерфейса связи с вычислительнойчастью прикладной программы:
Cи С++ API: для программ на языках C и C++. Этим же интерфейсом можно пользоваться для линковки слюбыми другими языками поддерживающими объектные файлы.
STDIN-STDOUTAPI: интерфейс использующий стандартные потокиввода-вывода.
FilesAPI: интерфейс, где для взаимодействия с вычислительнойчастью прикладной программы используются файлы, расположенные в файловойсистеме узла.
4. Два метода разбиения исходной задачи на блоки
В системе X-Com предусмотренодва основных метода разбиения исходной задачи на блоки: метод последовательнойвыборки и метод произвольной выборки, выбор того или иного методапроизводится исходя из специфики прикладной программы. По сути, эти методыотличаются способом получения от прикладной программы очередного задания ивозврата полученного результата.
4.1 Метод последовательной выборки
В методе последовательной выборкипакеты заданий получаются от прикладной программы строго последовательно, и втой же последовательности прикладная задача получает результаты вычислений. Призапросе очередного задания прикладная программа выдает идентификатор пакета ипорцию данных для расчета, каждое задание выдается строго последовательно иодин раз. При получении результатов расчета прикладной программе выдаетсяидентификатор пакета (полученный вместе с заданием) и результат расчета, причемгарантируется, что, если пакет A был выдан раньше пакета B, то результаты будут получены в том же порядке. При этом важно то, чтонет сквозной нумерации пакетов заданий.
Для организации такого интерфейса наэтом уровне приходится держать окно заданий, которое содержит все выполняемые вданный момент пакеты данных. При обращении очередного клиента за порциейвычислений происходит выбор между заданиями из окна, которые уже розданыклиентам и запросом прикладной программы об очередном задании. Заданиевыбирается из окна, если истекло время ожидания ответа от прикладной программы.
При получении ответа, если он следуетсразу за уже рассчитанным и отданным прикладной программе пакетом он передаетсяприкладной программе и окно уменьшается на один лот. Если же в окне присутствуетнекоторый пакет, который был взят в прикладной задаче раньше полученного и покане имеет результата, полученный результат сохраняется в окне.
Этот метод очень удобен с точкизрения прикладной программы, но требует большого количества накладных расходовпо памяти на обеспечение окна, особенно при большом размере исходного ирезультатных пакетов. На этом уровне следует работать, если того требуетспецифика прикладной задачи (например, результаты расчетов используются привыдаче очередного пакета), либо если обеспечение произвольной выборки требуетреализации дополнительных структур в программе, тогда, по сути, происходитреализация уровня произвольной выборки. Зная специфику прикладной задачи, можноорганизовать интерфейс к ней с помощью метода произвольной выборки болееэффективно, чем в методе окна, который используется в нашей реализации.
4.2 Метод произвольной выборки
В методе произвольной выборкиприкладная программа должна обеспечивать сквозную нумерацию заданий и бытьготова в любой момент выдать задание с номером N из диапазона прикладной задачи. Результаты вычисленийтакже могут приходить в произвольном порядке, но гарантируется, что всерезультаты будут получены и только один раз. В этом методе не требуется хранитьв окне заданий сам запрос и результат вычислений, хранятся только номерапакетов, которые сейчас находятся в процессе вычислений. Если возникаетнеобходимость послать пакет другому вычислительному узлу (при истечении времениожидания), то прикладная программа запрашивается еще раз и заново выдаетзадание. Полученный от вычислительного узла результат расчета сразу же отдаетсяприкладной программе.
4.3 Архитектура центрального сервера для реализации методовпоследовательной и произвольной выборки
/>
Для реализации двух методов разбиенияисходной задачи блок связи с прикладной программой разбит на два независимыхблока: один для связи в случае использования метода произвольной выборки,другой – для реализации метода последовательной выборки.
Напомним, что прикладная программавзаимодействует с сервером X-Com через один из 3-х интерфейсов: Java, C/C++, Files. В каждом из этих интерфейсовпредусмотрены независимые блоки функций как для одного, так и для другогометода.
В блоке логики сервера есть дванезависимых модуля реализующие соответственно два методов разбиения исходнойзадачи. Помимо этих 2-х модулей в блоке логики сервера есть общая часть,которая отвечает за:
идентификацию узла
ведение базы данных (информация обузлах, вычислительных возможностях узлов, а также о статистике соединений)
проверку корректности результата
5. Точки взаимодействия прикладной программы с системой X-Com
/>
Прикладная программа в нашей системеразбивается на две части: серверную и вычислительную.
Серверная часть прикладной программы управляетформированием заданий для расчета на узлах. Программа может быть реализована налюбом средстве программирования, важно только, чтобы она удовлетворяла API X-Com.
Вычислительная часть прикладной программы представляетсобой основной расчетный модуль в системе, который может быть реализован налюбом средстве программирования (возможно не соответствующем серверной частиприкладной программы заданий), важно только, чтобы этот блок удовлетворялсоответствующим API.
Отметим, что интерфейсывычислительной части прикладной программы не связаны с интерфейсамивзаимодействия для серверной части прикладной программы, более того они неиспользуют методы последовательной и произвольной выборки (метод разбиенияисходной задачи на блоки не влияет на расчет каждого блока).
6. Ход вычислений в системе X-Com
Для того чтобы лучше понять работусистемы и ее связь с архитектурой рассмотрим ход вычислений на некоторойзадаче.
Для простоты предположим, что задачадопускает решение методом прямой выборки и используется простая архитектура содним центральным сервером и несколькими узлами (без промежуточных северов).
Прикладная программа разбивается надва блока: серверный и клиентский. Серверный модуль, отвечает за выдачу заданийи по запросу выдает очередную порцию вычислений, либо сигнал о том, что всезадания выданы, и он переходит в режим ожидания оставшихся ответов. Клиентскийблок проводит расчет задания и выдает результат.
6.1 Разбиение исходной задачи на блоки и нумерация этихблоков
Исходная задача разбивается на блоки,так как применяется метод прямой выборки количество блоков известно и все блокиможно пронумеровать от 1 до N. В дальнейшем мы будем оперировать этими номерами для идентификациивычислительного блока.
6.2. Начальный момент времени и соединение узлов с сервером
В начальный момент времени сервернаходится в состоянии ожидания запросов от вычислительных узлов. Пусть у насесть некоторое количество вычислительных узлов, и все они запущены.
Каждый узел все время пока онфункционирует, периодически посылает запросы “дай задание” на сервер. Еслипроизошел сбой соединения, либо сервер еще не готов узел снова ожидаетнекоторое время и повторяет попытку.
6.3 Подключение и идентификация узла
Предположим, что некоторыйвычислительный узел соединился с сервером. Первым о соединении узнает серверныйкоммуникационный блок. Он не реализует никакой логики, просто принимает запрос,разбирает его заголовки, и передает данные запроса в серверный блок логики.
Возможны четыре типа соединений:
“Дай задание” – первичный запросрезультата;
“Получи результат — дай следующеезадание” – возврат рассчитанного задания и запрос следующего. Этот запросделается в одной сессии для оптимизации сетевого взаимодействия;
“Получи задание” – возвратрассчитанного задания и сообщение о завершении работы. Сообщение о завершенииработы может произойти и без возврата результата, это важно, чтобы корректноопределить на сервере статус вычислительного узла;
Сообщение о статусе расчета на данномузле. Это информационный тип запросов, который важен при длительныхвычислениях, чтобы сервер “помнил” о существовании узла, такие запросыпередаются напрямую в блок сбора статистике о ходе вычислений и прямо не влияютна ход вычислений.
Любой подключившийся узел внезависимости от типа соединения проходит процедуру идентификации, гдеоднозначно находится соответствующая ему запись в таблице узлов, либо, если этопервое общение данного узла, заводится новая запись.
6.4 Первичный запрос задания
В начальный момент времени все узлыобращаются к серверу с запросом “дай задание”. Предположим, что некоторый узелустановил соединения и прошел процедуру идентификации.
На блок логики сервера поступилзапрос о выдаче новой порции вычислений, блок логики в свою очередь передалэтот запрос через API прикладнойпрограмме, которая вернула порцию данных, необходимую для расчета. Сервернаячасть прикладной программы не знает, на каком узле будет производиться расчет,она просто выдает очередной блок данных по номеру, который генерирует блоклогики сервера.
Затем задание на расчет через блоклогики, серверный коммуникационный блок, клиентский коммуникационный блокпопадает на узел.
6.5 Расчет задания на узле
Получив задание, узел запускаетприкладную программу для расчета. По ходу расчета фоновый процесс блока логикиузла периодически посылает информацию, что узел находится в состояниивычисления полученной порции. Данный процесс необходим, чтобы для сложных повремени вычисления порций данных, сервер не посчитал узел выбывшим извычислений.
Окончив расчет, узел посылаетрезультат расчет на сервера. Для этого используется запрос “Получи результат — дай следующее задание”.
6.6 Получение сервером результатов вычислений
Пройдя серверный коммуникационныйблок, процедуру идентификации, проверку корректности запрос через блок логикисервера передает прикладной программе результат вычислений.
После этого происходит запрос новойпорции вычислений, с точки зрения прикладной программы он полностью аналогиченпервичному запросу задания.
6.7 Окончание вычислений
Предположим, что в некоторый моментвремени все задания для расчета уже розданы. Тогда очередной узел, при возвратерезультата своего расчета получит ответ от сервера “Нет заданий”, после чего онотключится и перейдет в режим первичного запроса заданий. По мере окончаниявычислений все узлы вернут результаты порученных им расчетов, и серверзафиксирует окончание вычислений.
6.8 Структуры данных сервера для хранения информации об узлах
В таблице приведена структура базыданных, которая ведется сервером во время вычислений. Эти данные используютсядля управления ходом вычисления, а также для сбора и отображения статистики оходе вычислений.Тип поля Название поля Описание
Идентификация сессии: основной способ идентификации узла String sId Идентификатор сессии, необходим для однозначной идентификации узла, случайно генерируется при первом подключении узла сервером, передается на узел и фигурирует во всех остальных запросах данного узла
Эти данные не влияют на ход вычислений, они используются только при подсчете статистики. String gcCode Код клиента задается пользователем на узле, используется при расчете статистики. Может быть не уникальным, тогда в статистике все узла с данным кодом будут суммироваться. String String Cluster Node Код клиента обычно состоит из двух частей: имени кластера и имени узла. Данное деление достаточно условно и необходимо только для более удобного сбора и отображения статистики. Если данное деление не используется код кластера остается пустым. Double MHz Частота процессора на узле. String IP Последний IP адрес, с которого происходил запрос от данного узла (он может изменяться в случае коммутируемого соединения). String OS Операционная система узла.
Данные о ходе вычислений Double Last_access_perf Производительность последнего расчета на данном узле. В начальный момент времени содержит -1. Long Last_access_time Время последнего расчета на данном узле. В начальный момент времени содержит -1. Boolean IsActive Флаг активности клиента, если сервер считает, что данный узел выбыл из вычислений, флаг устанавливается в значение “Ложь”. После любого соединения от узла принимает значение “Истина”. Long Portion Номер порции, которую в данный момент вычисляет узел. Если узел не получил данных для расчета содержит -1. Long Portion_time Стартовый период времени, в который была передана последняя порция для расчета данным узлом. Если узел не получил данных для расчета содержит -1.
6.9 Перераспределение заданий в методе произвольной выборки
Предположим, серверу требуется выдатьочередное задание для вычисления. У него всегда есть выбор: запроситьклиентскую программу новую порцию данных, либо выдать блок, от узла, который мысчитаем выбывшим из вычислений.
В методе произвольной выборки естьтри варианта организации хода вычислений:
Получение всех порций данных отприкладной программы, вне зависимости от состояния узлов уже получивших заданияи затем передача заданий он узлов, которые мы считаем неактивными.
Получение всех порций данных отприкладной программы, вне зависимости от состояния узлов уже получивших заданияи затем последовательная передача заданий он узлов которые дольше всегонаходятся в состоянии расчета (при этом статус узла не важен).
Решение о передаче некоторой порцииданных новому узлу, если мы считаем что предыдущий узел, который рассчитывалэту порцию, неактивен до получения всех порций от прикладной программы.
В последнем варианте принеобходимости выдачи нового задания сервер вначале просматривает список ужерозданных заданий, и если время ожидания какого-либо из них истекло, выдаетего. Если все времена заданий, которые сейчас находятся в обработке, неистекли, то прикладная программа запрашивается об очередном задании.
Время ожидания ответа рассчитываетсякак расчетное время ожидания ответа умноженное на коэффициент K_wait. Расчетное время ожидания ответа, в свою очередь,определяется исходя из статистики работы с каждым конкретным клиентом и размератекущего задания. Коэффициент K_wait – важный атрибут работы системы: приего увеличении мы ожидаем пакет в течении большего времени и соответственноменьше шанс, что мы пошлем один и тот же пакет двум разным вычислительным узлам(задержка может быть связана как с неточностью предсказания времени расчета,так и с загрузкой вычислительно узла), с другой стороны при увеличении этогокоэффициента мы увеличиваем размеры окна, что ведет в прикладной программе кувеличению времени ожидания очередной порции данных, а также увеличениеразмеров окна требует дополнительных ресурсов памяти центрального сервера.
Ожидание времени расчета вычисляетсяисходя из размера задания (физический размер памяти, требуемый для текстазадания, влияет на скорость передачи его по сети) и сложности задания (онавыдается клиентской частью прикладной программы). Сложность заданияпредставляет собой оценку времени его расчета на некотором абстрактномвычислителе, этот параметр выдается прикладной программой вместе с заданием.При невозможности такой оценки, каждому заданию присваивается сложность расчетаединица.
6.10 Фоновые процессы на сервере
Параллельно с основными процессами насервере работают фоновые процессы, которые не влияют на ход вычислений.Работают два основных процесса: проверка состояния узлов и отображение ходавычислений. Проверка состояний узлов – это процесс, периодически проверяющийвсе узлы из таблицы текущих вычислений, на предмет их активности, при истечениинекоторого времени, которые вычисляется аналогично времени ожидания ответа, нос другим коэффициентом – K_wait_dead. K_wait_dead должен быть больше K_wait. Если узел неотвечает больше чем, время ожидания активности, то он помечается в таблице какнеактивный.
Второй фоновый процесс – отображениехода вычислений периодически сбрасывает на жесткий диск файл доступный, черезВеб-сервер, в этом файле отображается статистическая информация о ходевычислений (количество активных узлов; количество узлов находящихся в процессевзаимодействия с сервером; суммарная вычислительная мощность системы), а такжеполная таблица подключенных узлов.
6.11 Проверка корректности результата
При получении сервером результатарасчета, в ряде случаев возникает необходимость убедиться в правильностирасчетов, это необходимо чтобы избежать умышленного искажения результата, либоискажения результатов расчетов в результате некорректно работающего узла. Естьчетыре основных пути проверки корректности:
Отсутствие проверки корректности. Результат вычислений будетпередаваться непосредственно в прикладную программу, которая его сохраняет.
Прямой метод проверки корректности,когда проверкой занимается серверная часть прикладной программы. Прикладная программа запрашивается суровня проверки корректности парой (запрос, результат) и выдает ответ верныйрезультат, либо нет. При неверном результате информация об ошибке сохраняется вспециальных логах для дальнейшей разборки, почему это произошло. В штатном режимефункционирования системы ошибок быть не должно, поэтому номер узла выдавшегоошибку сохраняется в черном списке, и соединения от него больше не принимаются.
Прямой метод проверки корректности,когда проверкой занимается другой узел. В этом случае в начало списка заданий попадает задание напроверку, при этом решается обратная задача, где исходными данными служит ужеполученный результат вычислений. Результат этого расчета должен совпасть сисходными данными (проверки на идентичность производится в прикладнойпрограмме), в противном случае результат считается не полученным и номера узловзанимавшихся проверкой и перепроверкой заносятся в черный список.
Метод перерасчета результата. Ключевым параметром методаперерасчета служит коэффициент перепроверки – вещественное число большееединицы. В случае целого числа этот коэффициент означает скольким узлам надораздать одно и то же задание. Полученные результаты сверяются друг с другом, ив случае расхождения используется метод голосования для определения правильногорезультата. Если равное количество узлов проголосовало за каждый вариантрезультата, проводятся дополнительные проверки для определения победителя. Всеузлы, которые выдали неверный результат, заносятся в черный список и вдальнейшем не смогут получать задания на обработку. Если коэффициентперепроверки больше 1 и меньше 2, – то он характеризует вероятность, с которойочередной пакет будет проверен. Эта вероятность составляет коэффициентперепроверки минус единица. В случае вещественного числа большего 2,коэффициент перепроверки аналогично характеризует вероятность проверки пакетаближайшим к нему сверху, либо ближайшим снизу целым числом проверяющих узлов.