Разработка централизованного алгоритма балансировки распределенного приложения

Постановка задачи:

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

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

Рекомендация: при выполнении работы использовать программные средства технологии .NET.

Описание централизованного алгоритма балансировки

Обычно практичное и полное решение задачи балансировки загрузки состоит из четырех шагов:

• Оценка загрузки вычислительных узлов.
• Инициация балансировки загрузки.
• Принятие решений о балансировке.
• Перемещение объектов.

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

Оценка загрузки

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

В основном такая база данных состоит из двух типов данных:

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

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

При распределении задач между процессорами производится оценка коммуникаций. Затраты на двухточечную связь между двумя задачами могут быть определены через объем передаваемых данных ( b – объём сообщений в байтах) и частоту коммуникации ( n – количество сообщений за единицу времени). Используя величины затрат процессора на каждое сообщение и каждый байт, можно оценить общие затраты на коммуникацию между двумя задачами: , где b – общий объем всех n сообщений.

Оценка загрузки процессора и объекта может быть произведена несколькими способами. Один из способов (аналитический), обычно используемый при статической балансировке загрузки и состоит в приблизительной оценке загрузки каждого объекта на основе знаний о приложении. К этим знаниям относятся:

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

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

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

Рекомендации по выполнению: использовать аналитический способ оценки загрузки.

Инициализация балансировки загрузки

Для продуктивности балансировки необходимо какимто образом определять момент ее инициализации.

Для этого следует:

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

Дисбаланс загрузки может определяться синхронно и асинхронно.

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

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

Рекомендации по выполнению: следует использовать синхронный способ определения баланса

Принятие решений в процессе балансировки

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

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

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

Рекомендации по выполнению: следует придерживаться централизованной стратегией.

Перемещение объектов

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

Рекомендации по выполнению: следует использовать технологию .Net Remoting.

Использование .NET Remoting

.NET Framework Remoting является технологией, на основе которой становится возможным взаимодействие между процессами. Структура удаленного доступа, также называемая .NET Remoting или просто Remoting, предоставляет простой набор классов и инструментов для обеспечения возможности межпроцессного взаимодействия.

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

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

Терминология .NET Remoting

Как и любая другая технология .NET Remoting вводит свои термины и понятия. Рассмотрим основные термины, связанные с удаленным доступом в .NET.

MarshalByRefObject

Имеется два способа, которыми клиент может взаимодействовать с объектами, расположенными на сервере. Вопервых, мы можем передавать клиенту ссылку на объект, выполняющийся на сервере. Клиент будет осуществлять вызовы по этой ссылке. Как будто это локальный объект. Однако когда производятся вызовы, ссылка будет на самом деле передавать вызовы в серверный процесс, там исполнять запрос и при помощи маршалинга передавать результаты обратно клиенту. Объекты, которые доступны через удаленный доступ как MarshalByRefObject, исполняются на сервере; на стороне клиента не выполняется никакой работы. Клиент имеет объектпрокcи, который отвечает за взаимодействие с сервером. Объект на сервере наследуется от System.MarshalByRefObject, который является базовым классом для того, чтобы позволить клиенту взаимодействовать с прокcиобъектами.

Сериализуемый (ByValue по значению)

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

В .NET все, что мы должны сделать, чтобы передавать наш объект от сервера к клиенту по значению это предоставить атрибут Serializable. Структура удаленного доступа сама позаботится об упаковке объекта, пересылке его к клиенту и воссоздании его в пространстве клиента.

Форматер

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

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

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

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

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

Форматер SOAP передает данные в формате сообщений SOAP. Сообщения SOAP более многословны, чем их двоичные аналоги, что делает их менее эффективными, чем сообщения в двоичном формате.

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

Канал

Аналогично тому, как клиент и сервер должны договориться по формату сообщений, они также должны договориться о механизме взаимодействия, или канале, с помощью которого будут передаваться данные. Каналы являются транспортными механизмами, с помощью которых передаются данные. Например, World Wide Web использует в качестве соглашения по каналу взаимодействия HTTP. Если клиентский компьютер может послать запрос HTTP к серверу, то сервер может ответить при помощи ответа HTTP и взаимодействие успешно состоится. Если клиентский компьютер передает запрос, используя канал SMTP, и получает данные в формате HTTP, то взаимодействия не произойдет. Аналогично веб, клиенты и серверы удаленного доступа должны договориться о канале взаимодействия.

Аналогично тому, как можно в .NET Remoting написать наш собственный форматер, также возможно создать наш собственный канал. Создание канала будет вопросом реализаций набора идентификаторов, которые будет понимать как клиент; так и сервер. Например, мы можем реализовать канал SMTP и посылать сообщения в формате SMTP.

.NET Framework поставляется с двумя готовыми каналами, которые называются каналами TCP и HTTP. Канал TCP взаимодействует по протоколу TCP и очень эффективен. Канал HTTP посылает сообщения по протоколу HTTP, высокоуровневому протоколу, основанному на TCP/IP.

Аналогично двоичному форматеру, канал TCP ограничен теми платформами, которые могут осуществлять взаимодействие по TCP. Обычно это означает, что, так же как и двоичный форматер, обе стороны взаимодействия должны быть клиентами .NET.

Канал HTTP посылает сообщения по протоколу HTTP. Если процессы клиента и сервера могут осуществлять взаимодействие по каналу HTTP, то взаимодействие будет успешным. Так как HTTP основан на TCP, канал HTTP не так эффективен, как взаимодействие на основе TCP. Однако так как протокол HTTP очень популярен и реализован на большинстве платформ, канал HTTP более гибок.

Принципы работы с каналами/форматерами

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