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

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

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

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

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

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

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

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

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

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

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

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

Архитектура подсистемы балансировки

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

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

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

• Программные средства, реализующие перемещение объекта с процессора на процессор.

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

• Базу данных, которая хранит информацию о компонентах имитационной модели и о вычислительной среде.

23. Распределенное хранение информации. Распределенные базы данных. Правила Дейта для распределенных бд. Фрагментация. Репликация. Протокол двухфазной фиксации транзакций.

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

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

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

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

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

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

Первое правило требует автономности локальных баз данных, из которых состоит распределенная БД. Все локальные (принадлежащие именно этому сайту) данные и процессы должны контролироваться только этим сайтом.

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

Третье правило – непрерывность работы. Реконфигурация системы (добавление и удаление локальных сайтов) не должна требовать остановки работы распределенной БД.

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

Седьмое правило касается распределенных запросов. Если выполнение запроса данных требует поиска данных не в одной локальной БД, а в нескольких локальных БД, то к этому не должно быть никаких препятствий.

Восьмое правило. Система должна поддерживать выполнение транзакций с сохранением их основных свойств: атомарности, согласованности, изолированности и продолжительности.

Правила девять – двенадцать декларируют независимость работы распределенной БД от аппаратного обеспечения, операционной системы, сетевой архитектуры и от типов СУБД, управляющих локальными базами. Последнее подразумевает, что локальные БД могут быть построены на основе различных моделей данных и с использованием различных типов СУБД, а СУРБД должна работать "поверх" этих СУБД.

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

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

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