Результат интеллектуальной деятельности: СПОСОБ ПОСТРОЕНИЯ ИЕРАРХИЧЕСКОЙ СИСТЕМЫ СЕТЕВОГО ВЗАИМОДЕЙСТВИЯ ВИРТУАЛЬНЫХ РАБОЧИХ МЕСТ

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

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

Вместе с тем, с ростом масштабов организаций, использование в ИТ-инфраструктуре пользовательских ПК вызывает ряд сложностей:

- большие операционные издержки на поддержку компьютерного парка;

- сложность, связанная с управлением настольными ПК;

- обеспечение пользователям безопасного и надежного доступа к

ПО и приложениям, необходимым для работы;

- техническое сопровождение пользователей;

- установка и обновление лицензий на ПО и техническое обслуживание;

- резервное копирование и т.д.

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

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

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

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

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

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

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

Процессы обладают следующими основными характеристиками:

- независимостью;

- самодостаточностью;

- способностью к сетевому взаимодействию.

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

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

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

Основные положения построения программного комплекса на основе процессной архитектуры:

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

2. На сетевом уровне программы взаимодействуют по протоколу TCP/IP.

3. Общение между программами организуется посредством команд.

4. Доставка команды осуществляется по адресу, прописанному в адресной части команды.

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

6. Часть программ (процессов), несущих ответственность за доставку команд, называются диспетчерами. Остальные программы - процессы.

7. Процессы могут быть подключены только к диспетчерам. Диспетчеры подключаются также только к диспетчерам.

8. Среди диспетчеров выделяется Центральный диспетчер. На него замыкаются все диспетчера системы.

9. Центральные диспетчеры также могут подключаться друг к другу. Таким образом, можно наращивать комплекс бесконечно.

10. Центральный диспетчер, не имеющий подключения к другому Центральному диспетчеру, является вершиной комплекса. Каждый комплекс имеет только одну вершину.

11. Функция диспетчеров - в продвижении команды между собой и, в конце концов, передача ее процессу.

12. При адресации используются имена диспетчеров и процессов. Каждый процесс и диспетчер имеет собственное имя.

13. Свое имя процесс или диспетчер сообщает при подключении к другому диспетчеру. Этот процесс называется регистрацией.

14. Процесс строится на основе Типового процесса.

15. Типовой процесс осуществляет всю работу по подключению, регистрации, приему и передачи команд к диспетчерам. Открытой у него является интерфейсная часть, позволяющая использовать функции приема/передачи команд.

16. В состав Типового процесса входит буфер команд и командный интерпретатор.

17. Пользовательский процесс расширяет Типовой процесс и пользуется его интерфейсом.

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

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

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

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

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

Изобретение поясняется чертежами, на которых изображено:

фиг.1, 2 - схема объединения двух транспортных систем (ТС);

фиг.3 - комбинация запуска транспортной системы на промежуточных вариантах количества компьютеров;

фиг.4 - схема подключения процессов к диспетчеру.

Осуществление изобретения.

Виртуализация рабочих мест.

Рабочее место - это аппаратно-программный комплекс, решающий задачи одного должностного лица АС.

Независимость рабочих мест от их территориального расположения определяется как свободная миграция программного обеспечения внутри комплекса технических средств АС. При этом возможен вариант, когда все рабочие места собраны в пределах одной рабочей станции (минимальный вариант). Идеальный вариант - одна рабочая станция - один АРМ. В случае избытка технических средств рабочие места могут занимать несколько рабочих станций.

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

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

Изоморфное масштабирование.

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

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

В принципе расширение рассматриваемой АС возможно не только за счет аналогичных информационных структур - главное, чтобы в качестве строительных элементов архитектуры использовались «строительные материалы» данной технологии.

Отсюда вытекает еще одно свойство: взаимодействие АС за счет слияния архитектур, выполненных на данной технологи.

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

Принципы построения автоматизированной системы на основе независимых программных компонентов, реализованных отдельными исполняемыми модулями - процессами.

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

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

Принцип независимости, (автономности) процессов позволяет решать вопрос группировки динамически, то есть во время функционирования АС, не прерывая ее работы. Более того, этот же принцип позволяет проводить реконфигурацию всей системы также без ее перезагрузки.

Общее пространство процессов разделяется на отдельные зоны. Эти зоны, так же как и процессы, могут физически располагаться в пределах АС в произвольном порядке, но с условием не пересечения друг с другом. Все процессы одной зоны замыкаются на специальный процесс-диспетчер, который выполняет только служебные функции, то есть является системным элементом АС. Процессы и диспетчеры увязываются в единую структуру благодаря типовому процессу. Он определяет основу других процессов и диспетчеров системы, то есть, другие процессы и диспетчера являются наследниками класса «типовой процесс». Задача типового процесса заключается, во-первых, в установке связи с диспетчерами и, во-вторых, в приеме и передаче информационных сообщений. Класс наследника использует уже готовые реализации перечисленных выше свойств типового процесса и предоставляет разработчику вызовы функций этих реализаций.

Архитектура иерархической системы сетевого взаимодействия программных компонентов системы.

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

Транспортная система комплекса выполняет две основные задачи:

- обеспечивает сетевое взаимодействие процессов;

- компонует АРМы комплекса.

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

Из вышеизложенного следует, что транспортная система в общем случае является многоуровневой и несимметричной, с неограниченным числом уровней. Ближайшие аналоги ТС - файловая система Linux и файловая система логического диска MS Windows. Диспетчер является аналогом каталога (папки) файловой системы, клиент - аналогом файла. Однако есть и одно принципиальное отличие - ТС не имеет фиксированной вершины (аналога корневой папки), поскольку ТС динамически наращиваема как вниз от вершины (подобно файловой), так и вверх. То есть, вершина всегда есть и в любой момент единственна, но она в отличие от корневой папки ("\" в MS Windows или "/" в Linux) в любой момент может уступить свой статус другой (однако, внешней по отношению к той ТС, которую вершила теряющая свой статус вершина). Ситуация смены вершины произойдет в случае, когда вершинный (центральный) сервер некоторой автономно работавшей ТС подсоединится к какому-либо из диспетчеров другой ТС. При этом две частные ТС сольются в одну, а центральный диспетчер второй ТС станет общей вершиной объединенной ТС.

Схема объединения двух ТС представлена на фиг.1 и 2.

Проиллюстрированная выше гибкость построения ТС достигается, прежде всего, за счет того, что в ней на любом уровне функционирует единый с точки зрения программного кода модуль диспетчера. По существу, здесь исчезают понятия типа «главный диспетчер», «центральный диспетчер». Ранг диспетчера может быть изменен оперативно, посредством либо его собственного подключения к другому серверу, либо при подключении к нему в качестве клиента иного диспетчера.

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

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

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

На данном чертеже отображена миграция процессов, образующих АРМ_3, в пределах автоматизированной системы, на другие компьютеры, поддерживающие работу АРМ_1 и АРМ_2.