Project blogs

Реализация RPC поверх DTTP

Сегодня я постараюсь рассказать о некоторых особенностях архитектуры системы Диптауна. А именно, с точки зрения объектов виртуального пространства.

Введение
В недавнем прошлом, после долгих обсуждений появилась концепция RPC, то есть механизма удаленного вызова функций. Суть этой концепции в том, что пользователь производит взаимодействие с некоторым объектом, вызывая его методы. При этом, "физически" объект может быть расположен "где-то в сети", то есть на удаленной машине. Но с точки зрения пользователя он расположен локально. При таком взаимодействии, пользователю не нужно заботиться ни об установлении сетевых соединений, ни о продумывании форматов передаваемых пакетов, ни об их собственно заполнении на одной стороне, передаче и приеме с "расшифровкой" на другой стороне. Все эти операции конечно же выполняются, но скрыты от глаз прикладного программиста. Выполняются они на уровне сетевой подсистемы, а именно протокола DTTP.

Концепция объектов диптауна
Первоначально, идея объектов и событий была разработана в рамках инфраструктуры Диптауна. Объект, -- это некоторая сущность, представленная в виртуальном пространстве. Это может быть и аватар, и бот... и даже нечто, не имеющее визуального представления. События, -- это соответственно то, что может с объектами произойти. В более общем смысле, события это сообщения доставляемые объектам. Отличие от традиционных сообщений заключается в том, что изначально неизвестно, где "физически" находится тот или иной объект, то есть неизвестен адрес сервера назначения. Транспортировка событий реализуется целиком силами протокола DTTP с использованием опорных серверов (например UIN сервера). При этом, адресом назначения для события является не ip адрес, а UID объекта. Таким образом достигается абстрагирование собственно виртуального пространства (и объектов виртуального пространства) от инфраструктуры серверов его поддерживающих.

Объекты RPC
С появлением реализации RPC понятие объектов несколько расширилось. Теперь объектом может быть не обязательно некоторая сущность виртуального пространства. В общем случае, это просто экземпляр некоторого класса, зарегистрированный на сервере как объект.

И вот как раз это позволяет нам подойти к концепции распределенных программ. Традиционно, распределенные вычисления применялись в случаях когда мощности одной отдельно взятой машины было недостаточно для решения поставленной задачи за разумное время. Это может быть и предсказание погоды, и расчет динамики ядерного взрыва, и моделирование уличного движения... Ну и рендеринг 3Д анимации конечно. Все эти задачи являются сугубо специфичными. При проектировании распределенных систем конечная цель была заранее известна и на нее делался уклон. Поэтому, грубо говоря взять кластер для рассчета погоды и переделать его для рендеринга, было практически невозможно (только путем создания новой инфраструктуры).

С появлением кластерных операционных систем дело несколько изменилось. Например проект ClusterKnoppix предоставляет свободную реализацию чего то вроде кластерной OC, в роли основного звена которой выступает проект OpenMosix. OpenMosix это система позволяющая объединить несколько машин (нод) в один кластер, а затем запускать поверх него обычные приложения (как уверяют авторы, в общем случае даже не требуется переписывать код). Собственно кластеризация осуществляется путем переноса потоков команд (или нитей) между нодами и распределением нагрузки. Данный подход является интересным, но проблема заключается в том, что кластер не имеет понятия о том, что же он выполняет. То есть, любое приложение выполняемое в этой среде представляется для него как совокупность потоков команд и данных которыми эти потоки оперируют.

Как ни странно, но система Диптауна позволяет решать распределенные задачи более элегантным образом.

Идея распределенных программ
Любая программа представляет собой совокупность нескольких подсистем: ввода данных, хранения, обработки и вывода соответственно. Каждая из подсистем, в свою очередь, разделяется на подсистемы более низкого порядка и т. д. до тех пор пока мы не дойдем до атомарных операций. Подсистемы взаимодействуют друг с другом передавая друг другу данные и контекст управления. Написание программы, в свою очередь сводится к формализации этих самых подсистем и написанию "правил" их взаимодействия.

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

Собственно идея заключается в повсеместном использовании RPC объектов при написании программ. Не обязательно клиент-серверных. При этом, все функционально-независимые части программ офрмляются в виде RPC объектов. Регламентируется внешний интерфейс этих объектов и некоторые их свойства. После этого объект добавляется в своего рода общий репозиторий.

На деле, этот подход принципиально не отличается от знакомого нам ООП, когда в роли подсистем выступают классы. RPC Объекты точно так же могут наследоваться друг от друга, использовать друг друга и т. д. Разница заключается в способе создания объекта и в обращении к нему.

Далее пишется собственно программа, которая использует эти объекты и "ставит им задачи". И вот тут начинается самое интересное =) Дело в том, что как уже было отмечено ранее, объект это сущность, не привязанная к конкретной машине. Более того в рамках протокола предусмотрены механизмы прозрачного переноса объекта с одной машины (узла) на другой, с сохранением всех данных и внутреннего состояния объекта. При этом, другие объекты все так же будут взаимодействовать с данным объектом и им не важно, был ли этот объект перемещен или нет.

Таким образом, мы получаем программу, которая автоматически может выполняться распределенно. Программу, которая не зависит ни от используемой ОС (поскольку код диптауна является кроссплатформенным), ни от фактических имеющихся вычислительных ресурсов. В общем случае, программа может выполняться в Сети, а Сеть представляется уже не совокупностью разрозненных узлов, а единой вычислительной средой, в которой все ресурсы могут быть свободно разделены между участниками. Средой, в которой стирается грань между локальной машиной и удаленной. Можно сказать, что вся Сеть выступает в роли одного гигантского мейнфрейма, к которому подключены все пользователи находящиеся в данный момент онлайн.

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

1) Допустим, что один из разработчиков, дописав свой модуль, решает скомпилировать проект (при этом подразумевается, что среда разработки так же написана с использованием нашей платформы). После начала процесса компиляции его рабочая станция начинает генерировать большое количество объектов и активно использовать ресурсы системы. Брокерный сервер, который следит за распределением нагрузки внутри офиса "видит", что один из узлов сети (а именно та самая рабочая станция, производящая компиляцию) в течение продолжительного времени оказывается сильно загруженным. При этом, брокер начинает автоматически перераспределять часть нагрузки с данного узла на остальные, менее загруженные машины сети, тем самым вовлекая в процесс дополнительную вычислительную мощность. Фактически, при таком подходе в процессе компиляции может участвовать весь офис, то есть вместо одного процессора рабочей станции, в распоряжении нашего программиста будет кластер из 20 процессоров рабочих станций. И все это в автоматическом, прозрачном режиме!

2) Другой пример: Дизайнер из той же компании закончив работу над новым рекламным роликом решает начать его рендеринг. Как известно, 3Д рендеринг это одна из самых ресурсоемких задач которые только можно представить в настоящий момент. Но и в этом случае, на помощь его рабочей станции придет кластер. При этом, в процессе помимо самих CPU, будут участвовать еще 20 видеокарт с графическими процессорами а также ресурсы хранилища данных серверов.

3) Использование кластеризации вовсе не означает что кластер должен использоваться только в моменты пиковой нагрузки на локальный узел. Можно представить себе домашнюю рабочую станцию, состоящую из нескольких машин. Например такую, как у Стефана Дайдака (http://www.stefandidak.com/). Фактически он уже имеет на руках кластер из десятка машин. Но использует он эти ресурсы дискретно, по факту. Все машины объединены в сеть, но только для того чтобы организовать единый рабочий стол. Реально же, каждая из задач все равно выполняется отдельно на отведенной для этого машине. Если же данный товарищ был бы в курсе платформы диптаун, то он смог бы использовать ее для организации единого вычислительного пространства %) При этом, используя возможности нашей распределенной файловой системы DISS и нашей же технологии мета интерфейса MEIN можно было бы выполнять те же задачи но гораздо более продуктивно. Конечно, все это при условии что наша платформа использовалась бы сторонними разработчиками для написания своих собственных систем...

Ну и в заключение хочу отметить, что данный подход будет использоваться "по назначению" в системе серверов диптауна. А именно на серверах поддержки ландшафта. При этом, они точно так же объединяются в кластер и распределяют между собой объекты виртуального пространства.

Заключение

Я думаю, уже всем понятен потенциал, заложенный в данной технологии :) Самое главное, что все это практически уже реализовано. Единственно, необходимо продумать механизмы распределения ресурсов, ну и некоторые аспекты проектирования подобных систем. Но это уже детали...

Please login or register to see comments