Лекция
Архитектура системы X-Com
1. Основные компоненты системы
Система X-Com реализована по принципам клиент-серверной архитектуры, в которой можно выделить два основных компонента.
Сервер X-Com - центральная часть системы, содержащая серверную часть программы пользователя и отвечающая за:
разделение исходной задачи на блоки
распределение заданий
координацию работ всех узлов
контроль целостности результата
сбор результата расчета в единое целое
Узел - любая вычислительная единица (рабочая станция, узел кластера, виртуальная машина), на которой происходит основной расчет прикладной программы. Отдельные блоки вычислительной задачи передаются от сервера на узлы, где происходит расчет, результаты которого передаются обратно на сервер. Узлы отвечают за:
расчет блоков прикладной задачи
запрос заданий для расчета от сервера
передачу результатов расчета на сервер
Все коммуникации между узлами и сервером в X-Com происходят через сеть Интернет. При этом используется только стандартный протокол HTTP (HyperText Transfer Protocol), что позволяет подключать к системе практически любые вычислительные мощности, имеющие доступ в Интернет. Система не требует настройки для работы через прокси-сервера, firewall и другие системы защиты. Данные, передаваемые системой, аналогичны стандартному трафику Интернет.
2. Иерархия узлов и серверов
Для организации более эффективных коммуникаций и подключения большего количества узлов система может быть организована в виде произвольного иерархического дерева. Листьями такого дерева всегда будут вычислительные узлы, в корне дерева - останется центральный сервер X-Com.
Промежуточные сервера (такие как Сервер-2 на рисунке) с точки зрения центрального сервера выглядят как обычные вычислительные узлы, а с точки зрения нижележащих вычислительных узлов как центральный сервер.
Полная архитектура системы не содержится и не управляет ни одним из компонентов системы. С точки зрения центрального сервера любой нижележащий промежуточный сервер выглядит как обычный узел, мощность которого в несколько раз превосходит мощность обычных узлов.
Такой подход позволяет в любой момент времени подключать и отключать как обычные вычислительные узлы, так и целые кластеры узлов, через промежуточный сервер.
На результат вычислений подключение и отключение узлов и серверов второго уровня не отразится, повлияет только на производительность системы в целом.
Сервера второго уровня целесообразно вводить, когда коммуникационный канал между центральным серверов и сервером второго уровня нестабилен или обладает малой пропускной способностью, а связь между промежуточным сервером и его узлами стабильная и поддерживает достаточно высокую скорость. Тогда промежуточный сервер буферизует некоторую порцию заданий для нижележащих узлов и результатов вычислений. Без такого сервера разрыв канала на время сопоставимое со временем расчет задачи на конечных узлах привел бы к потере результатов вычислений.
Очевидно, что любой сервер должен обеспечивать высокую стабильность работы и иметь достаточный размер дискового пространства для хранения как заданий, так и результатов вычислений всех нижележащих узлов.
3. Архитектура серверов X-Com и вычислительных узлов
Блок связи с прикладной программой представляет собой набор интерфейсов для взаимодействия с серверной частью программы пользователя. В настоящей реализации система поддерживает 3 интерфейса связи с серверной частью прикладной программы:
Java API: для программ на языке Java.
С и C++ API: для программ на языках C и C++. Этим же интерфейсом можно пользоваться для линковки с любыми другими языками поддерживающими объектные файлы.
Files API: простой интерфейс, где для взаимодействия с прикладной программой используются файлы, расположенные в файловой системе сервера.
Логика центрального сервера. Этот блок системы, определяет алгоритм распределенных вычислений: логикой распределения заданий по клиентским машинам, а также сбором и анализом результатов вычислений.
Блок логики центрального сервера сопровождает и использует необходимую статистическую информацию (информация о статистике соединений с каждым конкретным узлом, его вычислительных возможностях, истории работы с узлом).
Блок логики центрального сервера строится по принципу стека интерфейсов, который последовательно переводит логику пакетов от прикладной задачи к серверному коммуникационному блоку.
Система поддерживает три различных способа работы с блоком логики. Первый - самый низкий, это написание собственного блока логики на низком уровне, при этом требуется лишь удовлетворять предложенным API. Второй уровень - это использование настроек, различных методов либо частичная замена методов в одном из стандартных блоков логики. И третий - это собственно выбор одного из стандартных блоков логистики.
Серверный коммуникационный блок отвечает за пересылку пакета с заданием на узлы и также прием от узлов результатов вычислений. Подключение к узлам происходит по протоколу HTTP. Сервер X-Com имеет два основных режима взаимодействия, которые реализуются в серверном коммуникационном блоке: синхронный и асинхронный. Синхронный режим означает, что на все время вычислений узел имеет доступ к серверу и статистика о решении задачи передается в режиме online. Асинхронный режим означает периодический контакт и сбор статистики с клиентским модулем, вырожденным случаем асинхронного режима является выдача задания клиенту и ожидание от него соединения с информацией об окончании расчета.
Клиентский коммуникационный блок находится на конечном вычислительном узле, либо в промежуточном вычислительном сервере. Основные функции клиентского коммуникационного блока - это прием пакета с заданием на клиентском компьютере и передача результатов расчетов.
Блок логики промежуточного сервера реализует функции буферизации, необходимые для работы промежуточного сервера. Напомним, что с точки зрения центрального севера промежуточный сервер выглядит как обычный вычислительный узел, с большой мощностью, что позволяет запрашивать ему большие пакеты вычислительных заданий. Эти блоки заданий буферизуются на промежуточном сервере и распределяются между подключенными к нему узлами. Результаты вычислений также буферизуются на промежуточном сервере и передаются на центральный сервер. С точки зрения нижележащего блока логики центрального сервера данных блок реализует API аналогичные интерфейсам блока связи с прикладной программой.
Логика вычислительного узла - это блок, находящийся на конечных вычислительных узлах системы. Его основная функция - управление вычислительной частью прикладной программы пользователя и логикой ее работы (контроль версий, реализация разных режимов работы, и т.д.) В задачи данного блока также входит сбор информации о типе узла, на котором происходит расчет.
Блок связи с вычислительной частью прикладной программы отвечает за взаимодействие с прикладной программой пользователя. В текущей реализации системы предусмотрены 2 интерфейса связи с вычислительной частью прикладной программы:
C и С++ API: для программ на языках C и C++. Этим же интерфейсом можно пользоваться для линковки с любыми другими языками поддерживающими объектные файлы.
STDIN-STDOUT API: интерфейс использующий стандартные потоки ввода-вывода.
Files API: интерфейс, где для взаимодействия с вычислительной частью прикладной программы используются файлы, расположенные в файловой системе узла.
4. Два метода разбиения исходной задачи на блоки
В системе X-Com предусмотрено два основных метода разбиения исходной задачи на блоки: метод последовательной выборки и метод произвольной выборки, выбор того или иного метода производится исходя из специфики прикладной программы. По сути, эти методы отличаются способом получения от прикладной программы очередного задания и возврата полученного результата.
4.1 Метод последовательной выборки
В методе последовательной выборки пакеты заданий получаются от прикладной программы строго последовательно, и в той же последовательности прикладная задача получает результаты вычислений. При запросе очередного задания прикладная программа выдает идентификатор пакета и порцию данных для расчета, каждое задание выдается строго последовательно и один раз. При получении результатов расчета прикладной программе выдается идентификатор пакета (полученный вместе с заданием) и результат расчета, причем гарантируется, что, если пакет A был выдан раньше пакета B, то результаты будут получены в том же порядке. При этом важно то, что нет сквозной нумерации пакетов заданий.
Для организации такого интерфейса на этом уровне приходится держать окно заданий, которое содержит все выполняемые в данный момент пакеты данных. При обращении очередного клиента за порцией вычислений происходит выбор между заданиями из окна, которые уже розданы клиентам и запросом прикладной программы об очередном задании. Задание выбирается из окна, если истекло время ожидания ответа от прикладной программы.
При получении ответа, если он следует сразу за уже рассчитанным и отданным прикладной программе пакетом он передается прикладной программе и окно уменьшается на один лот. Если же в окне присутствует некоторый пакет, который был взят в прикладной задаче раньше полученного и пока не имеет результата, полученный результат сохраняется в окне.
Этот метод очень удобен с точки зрения прикладной программы, но требует большого количества накладных расходов по памяти на обеспечение окна, особенно при большом размере исходного и результатных пакетов. На этом уровне следует работать, если того требует специфика прикладной задачи (например, результаты расчетов используются при выдаче очередного пакета), либо если обеспечение произвольной выборки требует реализации дополнительных структур в программе, тогда, по сути, происходит реализация уровня произвольной выборки. Зная специфику прикладной задачи, можно организовать интерфейс к ней с помощью метода произвольной выборки более эффективно, чем в методе окна, который используется в нашей реализации.
Страницы: 1, 2
