Каковы основные критерии построения распределенных информационно-вычислительных систем масштаба предприятия? И что могут предложить существующие наработки в этой области? Давайте посмотрим.

Последнее десятилетие, отметившееся небывалым ростом IT-рынка, сопровождающимся столь массовым развитием сети интернет и доступных телекоммуникационных решений (GPRS, EDGE и др.), заставило разработчиков программного обеспечения по-новому взглянуть на проблему создания распределенных вычислительных систем и перейти от глобальных масштабов построения оных к локальным.

Давайте, для понимания сути работы распределенной системы масштаба предприятия и мотивов ее создания, взглянем на проблему с высоты деятельности небольшой фирмы, занимающейся продажами какого-либо товара. Итак, что мы имеем, взглянув на эту компанию сквозь призму информационно-вычислительных систем?

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

Так какой же можно подвести итог предыдущему абзацу? Вывод напрашивается сам собой - перед нами типичная, можно сказать практически готовая с аппаратной точки зрения распределенная вычислительная система, позволяющая руководству компании "малой кровью" перейти на кардинально новый уровень решения бизнес-задач. Например, реплицировав данные на все компьютеры и используя взаимосвязь между ними. В результате чего томительная прежде процедура выдачи ежегодного отчета деятельности компании сведется к секундному сбору уже обработанной информации с отдельных машин.

Дело, казалось бы, за малым - собрать этот "конструктор" в единую базу путем написания соответствующих программных модулей и компонентов. Но не все так просто: именно на этом этапе разработки возникает множество узких мест, требующих того или иного решения. Давайте коротко рассмотрим их.

Гетерогенность

Не секрет, что у рассматриваемой нами в качестве примера воображаемой компании могут существовать филиалы, работающие на других аппаратных или программных платформах (Mac OS, Windows, Linux и др.). Вот здесь и возникает камень преткновения - гетерогенность.

Обойти эти проблему можно только одним путем - транслированием несовместимых процедур, типов данных и объектов в другой, совместимый для данной платформы формат. Этой задачей преобразования и занимается промежуточное программное обеспечение, для создания которого в настоящее время можно воспользоваться, например, популярной технологией CORBA (Common Object Request Broker Architecture - обобщенная архитектура построения брокеров объектных запросов), позволяющей объектам приложения, запущенного на одной машине, вызывать методы объектов программы, работающей на другом компьютере.

Из наиболее современных решений межплатформенности можно еще назвать язык Java и технологию вызова удаленных методов RMI (Remote Method Invocation), позволяющую создавать распределенные приложения в связке "Java-to-Java", благодаря чему методы удаленных Java-объектов могут вызываться из других виртуальных машин Java (JVM).

Как правило, все существующие технологии построения промежуточного программного обеспечения базируются на открытых стандартах и работают по одному схожему сценарию, отличаясь лишь сложностью разработки и уровнем предоставляемых сервисов.

Масштабируемость

Второй по величине значимости параметр, на который следует обращать внимание при разработке распределенных систем. Ведь, будучи статичной, система рано или поздно столкнется с нехваткой вычислительных ресурсов. А дефицит последних неизбежно приведет к снижению общей производительности.

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

Как следствие поддержки расширяемости можно назвать необходимость поддержания актуального программного кода во всей внутренней структуре распределенной системы.

Обратная сторона масштабируемости - рост числа возможных отказов в оборудовании, которые необходимо своевременно определять во избежание зацикливания и увеличения времени выполнения задач.

При этом нужно учитывать тот момент, что сам факт расширяемости системы не должен коренным образом сказываться на ее работе. То есть коэффициент отклика системы не должен снижаться. Хотя, опять-таки, это палка о двух концах - в теории одно, на практике получается другое.

Решение - разбитие больших глобально-рапределенных систем на маленькие подсистемы.

Безопасность

Еще один ключевой фактор, который можно смело разбить на две составляющие - защиту передаваемых по открытым каналам данных (пользовательских и системных) и защиту от ложной подмены или изменения отдельных компонентов с целью несанкционированного доступа в систему.

Первая задача легко решается путем использования разнообразных криптографических алгоритмов шифрования всех пересылаемых данных. Вторая потребует разработки специальных техник кодирования и идентификации клиентских машин.

Прозрачность

Распределенная система должна скрывать свою внутреннюю разнородную, гетерогенную структуру, представляя собой для пользователей и разработчиков программного обеспечения нечто целое и единое. То есть для любой программы, система - это вроде обычного компьютера и в обязанности приложения не должно входить разделение и распределение данных по отдельным машинам.

В то же время и клиент, отправляя задачу, не должен заморачиваться вопросом ее обработки. Распределенная система должна работать по принципу "Загрузка задачи - выдача результата".

От теории - к практике

Итак, проблем на пути к созданию распределенной системы в рамках небольшого предприятия очень много. Мы сознательно не затрагиваем вопросы создания глобальных систем, поскольку над их реализацией уже не первый год работают такие крупные гиганты как IBM (см. проект World Community Grid) и Европейская организация ядерных исследований (CERN) (см. www.computerra.ru/xterra/33974). Нам ближе по духу и наиболее интересны небольшие наработки в этой области, способные выполнять задачи в рамках небольшой организации и не требующие капитальных финансовых вложений.

Можем утвердительно ответить, что не все так плохо.

Например, в Камышинском технологическом институте (Волгоградская область) на кафедре "Автоматизированные системы обработки информации и управления" ведутся исследования платформы Java для создания распределенной вычислительной системы. Результаты данной работы были представлены на второй Международной конференции "Параллельные вычисления и задачи управления", ежегодно проводимой в Институте проблем управления имени В.А. Трапезникова РАН. Кстати, желающим поучаствовать или принять непосредственное участие в конференции, рекомендуем посетить вышеупомянутый сайт конференции.

Сам Институт проблем управления, проводя такие значимые научные сессии, тоже участвует в различных работах, посвященных созданию работающей модели распределенной системы. Пример тому - разработка и испытание системы распределенного сжатия цифрового видео в реальном времени, проводимой совместно с компанией ООО "ИДМ". Разрабатываемый проект базируется на основе языка компьютерного исчисления древовидных структур с открытой интерпретацией "Парсек", автором которого является Ю.С. Затуливетер.

На рынке коммерческих программ тоже не пусто. Например, компания "Контур-Софт" ведет разработку информационной системы "Бизнес-контроль" для предприятий малого и среднего бизнеса. Предлагаемая программа написана на языке Java и реализует часть принципов распределенных вычислений.

См. также список печатных изданий, затрагивающих вопросы проектирования, разработки и развертывания распределенных вычислительных систем.