ГОСЫ / Bilety

Реплицируемые данные можно распространять целым рядом способов. Все методы распространения базируются либо на push-подписке (принудительная подписка), либо на pullподписке (подписка по запросу). Подписчик может одновременно использовать сочетание push- и pull-подписок.

Push-подписка (принудительная)

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

Принудительную подписку обычно применяют, когда:

число подписчиков относительно невелико;

репликация выполняется в пределах локальной сети (INTRANET);

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

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

Pull-подписка (по запросу)

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

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

Этот тип подписки снижает нагрузку сервера издателя/дистрибьютора, так как агенты распространения запускаются на стороне подписчиков.

Подписки по запросу подходят в следующих ситуациях:

когда число подписчиков относительно невелико;

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

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

121

9.Распределенная обработка данных в КИС

РАСПРЕДЕЛЕННАЯ ОБРАБОТКА ДАННЫХ

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

Всостав системы управления РБД должны входить следующие компоненты:

1.серверы и рабочие станции (узлы), формирующие сетевую систему. Система РБД должна быть независимой от оборудования

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

3.коммуникационные устройства, система управления РБД не должна зависеть от коммуникаций, то есть должна поддерживать несколько типов коммуникационных устройств

4.процессор транзакций (transaction processor TP), представляющий собой программный компонент, находящийся на каждом компьютере системы, где выполняется запрос данных. TP называют также менеджером транзакций (transaction manager TM)

5.процессор данных (data processor DP), представляющий собой программный компонент, находящийся на каждом компьютере системы, где хранятся и извлекаются данные. DP также называют менеджером данных (data manager DM). Процессор данных может представлять собой централизованную СУБД

Связь между DP и TP поддерживается протоколами. Протоколы определяют то, как система РБД:

1.организует интерфейс с сетью передачи данных и команд между DP и ТP

2.синхронизирует все данные, полученные от DP (сторона TP) и маршрутизирует полученные данные на соответствующие TP (сторона DP)

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

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

1.РБД – это логически связанные, разделяемые на некоторое количество фрагментов, данные

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

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

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

Основные требования к распределенной обработке данных:

1.прозрачность относительно расположения данных  СУБД должна представлять все данные так, как, если бы они были локальными

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

122

3.прозрачность относительно сети  СУБД должна одинаково работать в условиях разнородных сетей

4.поддержка распределенных запросов  пользователь должен иметь возможность работать с данными из любых баз, даже если они размещены в разных подсистемах

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

6.поддержка распределенных транзакций  СУБД должна выполнять транзакции, выходящие за рамки одной вычислительной системы, и поддерживать целостность распределенной БД даже при возникновении отказов, как в отдельных системах, так и в сети

7.безопасность  СУБД должна обеспечивать защиту всей распределенной БД от НСД

8.универсальность доступа  СУБД должна обеспечивать единую методику доступа ко всем данным

123

11. Характеристики и требования к транзакциям

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

Одним из наиболее распространённых наборов требований к транзакциям и транзакционным системам является набор ACID (Atomicity, Consistency, Isolation,

Durability).

ACID-свойства транзакций

Характеристики транзакций описываются в терминах ACID.

Atomicity, Consistency, Isolation, Durability – неделимость(атомарность),

согласованность(целостность), изолированность, устойчивость(живучесть).

Транзакция неделима в том смысле, что представляет собой единое целое. Все ее компоненты либо имеют место, либо нет. Не бывает частичной транзакции. Если может быть выполнена лишь часть транзакции, она отклоняется.

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

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

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

Указанные выше правила выполняет СУБД-сервер.

124

12.Распределенная транзакция в РБД КИС

РАСПРЕДЕЛЕННАЯ ТРАНЗАКЦИЯ

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

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

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

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

TRANSACTION) и конец (COMMIT TRANSACTION или ROLLBACK TRANSACTION),

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

В режиме автоматически фиксируемых транзакций неявная транзакция стартует автоматически (SQL-операторы, которые являются началом новой транзакции в неявном режиме: ALTER TABLE, CREATE, DELETE, DROP, FETCH, GRANT, INSERT, OPEN, REVOKE, SELECT, TRUNCATE TABLE, UPDATE), а по завершении также автоматически подтверждается или отменяется. Если выполнение SQL-оператора заканчивается успешно, произведенные им изменения будут зафиксированы. Если же при выполнении оператора произошла ошибка, то для всех произведенных им изменений будет инициирован откат. По умолчанию SQL Server работает в режиме автоматически фиксируемых транзакций. В дальнейшем пользователь может установить на уровне сеанса режим явных транзакций.

125

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

Не каждая SQL-операция может быть выполнена в рамках транзакции. Не выполняются те операции, для которых невозможно выполнить откат:

CREATE DATABASE, ALTER DATABASE, DROP DATABASE, BACKUP

(резервное копирование), RESTORE (восстановление), RECONFIGURE (изменение параметров настройки сервера), UPDATE STATISICS (обновление статистики).

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

ACID-свойства транзакций

Характеристики транзакций описываются в терминах ACID.

Atomicity, Consistency, Isolation, Durability – неделимость(атомарность),

согласованность(целостность), изолированность, устойчивость(живучесть).

Транзакция неделима в том смысле, что представляет собой единое целое. Все ее компоненты либо имеют место, либо нет. Не бывает частичной транзакции. Если может быть выполнена лишь часть транзакции, она отклоняется.

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

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

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

126

Указанные выше правила выполняет СУБД-сервер. ТРАНЗАКЦИИ в РБД

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

Для реализации распределенной транзакции предусмотрен протокол двухфазной фиксации (two-phase commit). Для описания протокола используется следующая модель.

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

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

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

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

Согласованность состояния баз данных при параллельном выполнении нескольких транзакций обеспечивается механизмами блокировок и временных отметок:

механизм блокировки создает такие условия, что график параллельного

выполнения	транзакций	будет	эквивалентен	некоторому	варианту
			127

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

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

Основной проблемой является проблема возможных распределенных тупиков, которые могут возникнуть между несколькими распределенными транзакциями, выполняющимися параллельно. Тупик, как правило, является следствием взаимоблокировки транзакций. Например, транзакция1 должна выполнить обновление ресурсов A и B, блокирует ресурс A для транзакции2 и обнаруживает, что ресурс B уже заблокирован транзакцией2. В свою очередь транзакция2 тоже пытается выполнить операции с ресурсами A и B, блокирует B для транзакции1 и обнаруживает, что ресурс A уже заблокирован. Обе транзакции оказываются в состоянии взаимоожидания, которое может не разрешиться никогда. Для обнаружения распределенных тупиков применяется распределенный алгоритм, не нарушающий требования автономности узлов сети и минимизирующий число передаваемых по сети сообщений и необходимую процессорную обработку.

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

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

128

Администрирование информационных систем Романова

1. Основные задачи администрирования информационных систем Администратор

o управляющая программа, организующая программа, диспетчер, программа управления o программа или ответственное лицо

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

Администрирование – функциональная поддержка управления системным ресурсом и обеспечения его безопасной и бесперебойной работы

Администрирование ИС заключается:

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

2)в управлении доступом (регистрация пользователей, назначение прав и ограничений)

3)в обеспечении доступности, безопасности и масштабируемости системы

КИС относятся: ОС, сетевые службы и протоколы, СУБД, Web-серверы, обслуживающие системы и т.п.

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

Кобязанностям системного администратора обычно относят следующие задачи:

подключение и настройка аппаратных устройств;

установка и обновление программного обеспечения;

запуск и настройка общесистемных сервисов (конфигурирование системы);

настройка сетевых протоколов;

обеспечение печати и отправки почты;

обеспечение файловых серверов, серверов приложений, web и ftp-серверов;

управление процессами – изменение их приоритета, принудительное завершение;

управление общесистемными ресурсами, такими, как дисковые разделы и файловые системы;

распределение ресурсов;

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

регистрация и управление пользователями;

настройка групповых политик;

настройка политики безопасности;

обеспечение безопасности;

регистрация и анализ всех инцидентов, связанных с нарушение безопасности;

резервное копирование информационных ресурсов;

мониторинг системы в поисках любого возможного системного сбоя, узкого места или уязвимости в защите;

поиск неисправностей;

анализ производительности и надежности;

обеспечение защиты от ошибок пользователей

мониторинг действий пользователей;

мониторинг электронной почты;

мониторинг работы в Internet;

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

Учетная запись администратора обладает всеми привилегиями – правами и полномочиями – в системе. Администратор может не только выполнить важные настройки системы и

129

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

Управление пользователями включает такие функции:

o Создание учетной записи пользователя; o Изменение пароля;

o Отключение/включение учетной записи; o Удаление учетной записи пользователя.

Другая задача администрирования – управление группами. Управление группами включает в себя: o создание группы;

o добавление пользователей в группу; o удаление группы.

К наиболее существенным элементам программного обеспечения безопасности в

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

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

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

сполитиками установки ограничений на компьютеры пользователей (desktop lockdown policies) и

сполитиками безопасности (security policies).

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

Групповые политики обладают весьма богатыми возможностями. Но если перед применением GPO (Group Policy Objects) не будут выполняться тестовые мероприятия, это может привести к ежедневным нарушениям работы. Следует всегда помнить о том, что перед применением новых настроек групповой политики все внесенные изменения должны быть тщательно протестированы.

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

130