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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


доклад Защита системы управления базами данных

Информация:

Тип работы: доклад. Добавлен: 24.10.2012. Сдан: 2012. Страниц: 6. Уникальность по antiplagiat.ru: < 30%

Описание (план):


1. Введение
Системы управления базами данных, в особенности реляционные  СУБД, стали доминирующим инструментом хранения больших массивов информации. Сколько-нибудь развитые информационные приложения полагаются не на файловые структуры операционных систем, а  на многопользовательские СУБД, выполненные  в технологии клиент/сервер. В этой связи обеспечение информационной безопасности СУБД, и в первую очередь  их серверных компонентов, приобретает  решающее значение для безопасности организации в целом. 
Для СУБД важны все три основных аспекта информационной безопасности - конфиденциальность, целостность и доступность.
Для иллюстрации излагаемых понятий и средств будут использоваться СУБД INGRES, Informix и Oracle.
2. Идентификация  и проверка подлинности пользователей
Обычно в СУБД для идентификации  и проверки подлинности пользователей  применяются либо соответствующие  механизмы операционной системы, либо SQL-оператор CONNECT. Например, в случае СУБД Oracle оператор CONNECT имеет следующий  вид:
CONNECT пользователь[/пароль] [@база_данных];
Так или иначе, в момент начала сеанса работы с сервером баз  данных, пользователь идентифицируется своим именем, а средством аутентификации служит пароль. Детали этого процесса определяются реализацией клиентской части приложения. 
Некоторые операционные системы, такие как UNIX, позволяют во время запуска программы менять действующий идентификатор пользователя. Приложение, работающее с базой данных, как правило, имеет привилегии, значительно превосходящие привилегии обычных пользователей. Естественно, что при этом приложение предоставляет тщательно продуманный, строго фиксированный набор возможностей. Если пользователь сумеет тем или иным способом завершить приложение, но сохранить подключение к серверу баз данных, ему станут доступны по существу любые действия с данными.
3. Управление доступом
Для иллюстрации вопросов, связанных с управлением доступом, будет использоваться СУБД INGRES.
3.1. Основные понятия
Обычно в СУБД применяется  произвольное управление доступом, когда  владелец объекта передает права  доступа к нему (чаще говорят - привилегии) по своему усмотрению. Привилегии могут  передаваться субъектам (отдельным  пользователям), группам, ролям или  всем пользователям. 
Группа - это именованная совокупность пользователей. Каждый пользователь может входить в несколько групп. Когда пользователь тем или иным способом инициирует сеанс работы с базой данных, он может указать, от имени какой из своих групп он выступает.  
Роль - это еще один возможный именованный носитель привилегий. С ролью не ассоциируют перечень допустимых пользователей - вместо этого роли защищают паролями. В момент начала сеанса с базой данных можно специфицировать используемую роль (обычно с помощью флагов или эквивалентного механизма) и ее пароль, если таковой имеется. 
Привилегии роли имеют приоритет над привилегиями пользователей и групп.
Отметим, что в СУБД Oracle под ролью понимается набор привилегий. Такие роли служат средством структуризации привилегий и облегчают их модификацию. 
Совокупность всех пользователей именуется как PUBLIC. Придание привилегий PUBLIC - удобный способ задать подразумеваемые права доступа.
3.2. Основные категории  пользователей
Пользователей СУБД можно  разбить на три категории:
      администратор сервера баз данных. Он ведает установкой, конфигурированием сервера, регистрацией пользователей, групп, ролей и т.п. Администратор сервера имеет имя ingres. Прямо или косвенно он обладает всеми привилегиями, которые имеют или могут иметь другие пользователи.
      администраторы базы данных. К этой категории относится любой пользователь, создавший базу данных, и, следовательно, являющийся ее владельцем. Он может предоставлять другим пользователям доступ к базе и к содержащимся в ней объектам. Администратор базы отвечает за ее сохранение и восстановление. В принципе в организации может быть много администраторов баз данных. Чтобы пользователь мог создать базу и стать ее администратором, он должен получить (вероятно, от администратора сервера) привилегию creatdb.
      прочие (конечные) пользователи. Они оперируют данными, хранящимися в базах, в рамках выделенных им привилегий.
Администратор сервера баз данных, как самый привилегированный пользователь, нуждается в особой защите. Компрометация его пароля фактически означает компрометацию сервера и всех хранящихся на нем баз данных. 
Поручать администрирование различных баз данных разным людям имеет смысл только тогда, когда эти базы независимы и по отношению к ним не придется проводить согласованную политику выделения привилегий или резервного копирования. В таком случае каждый из администраторов будет знать ровно столько, сколько необходимо. 
Можно провести аналогию между пользователем ingres и администраторами баз данных с одной стороны, и суперпользователем операционной системы (root в случае ОС UNIX) и служебными пользователями (в ОС UNIX это могут быть bin, lp, uucp и т.д.) с другой стороны. Введение служебных пользователей позволяет администрировать функциональные подсистемы, не получая привилегий суперпользователя. Точно так же информацию, хранящуюся на сервере баз данных, можно разделить на отсеки, так что компрометация администратора одного отсека не означает обязательной компрометации другого.
3.3. Виды привилегий
Привилегии в СУБД можно  подразделить на две категории: привилегии безопасности и привилегии доступа. Привилегии безопасности позволяют  выполнять административные действия. Привилегии доступа, в соответствии с названием, определяют права доступа  субъектов к определенным объектам.
3.3.1. Привилегии  безопасности 
Привилегии безопасности всегда выделяются конкретному пользователю (а не группе, роли или всем) во время его создания (оператором CREATE USER) или изменения характеристик (оператором ALTER USER). Таких привилегий пять:
      security - право управлять безопасностью СУБД и отслеживать действия пользователей. Пользователь с этой привилегией может подключаться к любой базе данных, создавать, удалять и изменять характеристики пользователей, групп и ролей, передавать права на доступ к базам данным другим пользователям, управлять записью регистрационной информации, отслеживать запросы других пользователей и, наконец, запускать INGRES-команды от имени других пользователей. Привилегия security необходима администратору сервера баз данных, а также лицу, персонально отвечающему за информационную безопасность. Передача этой привилегии другим пользователям (например, администраторам баз данных) увеличивает число потенциально слабых мест в защите сервера баз данных.
      createdb - право на создание и удаление баз данных. Этой привилегией, помимо администратора сервера, должны обладать пользователи, которым отводится роль администраторов отдельных баз данных.
      operator - право на выполнение действий, которые традиционно относят к компетенции оператора. Имеются в виду запуск и остановка сервера, сохранение и восстановление информации. Помимо администраторов сервера и баз данных этой привилегией целесообразно наделить также администратора операционной системы.
      maintain_locations - право на управление расположением баз администраторы сервера баз данных и операционной системы.
      trace - право на изменение состояния флагов отладочной трассировки. Данная привилегия полезна администратору сервера баз данных и другим знающим пользователям при анализе сложных, непонятных ситуаций.
3.3.2. Привилегии  доступа 
Привилегии доступа выделяются пользователям, группам, ролям или всем посредством оператора GRANT и изымаются с помощью оператора REVOKE. Эти привилегии, как правило, присваивает владелец соответствующих объектов (он же - администратор базы данных) или обладатель привилегии security (обычно администратор сервера баз данных). 
Прежде чем присваивать привилегии группам и ролям, их (группы и роли) необходимо создать с помощью операторов CREATE GROUP и CREATE ROLE. 
Для изменения состава группы служит оператор ALTER GROUP. 
Оператор DROP GROUP позволяет удалять группы, правда, только после того, как опустошен список членов группы. 
Оператор ALTER ROLE служит для изменения паролей ролей, а DROP ROLE - для удаления ролей. 
Напомним, что создавать и удалять именованные носители привилегий, а также изменять их характеристики может лишь пользователь с привилегией security. При совершении подобных действий необходимо иметь подключение к базе данных iidbdb, в которой хранятся сведения о субъектах и их привилегиях. 
Привилегии доступа можно подразделить в соответствии с видами объектов, к которым они относятся. В СУБД INGRES таких видов пять:
      таблицы и представления
      процедуры
      базы данных
      сервер баз данных
      события
Присваивание привилегий доступа производится с помощью  оператора GRANT. В самом общем виде оператор GRANT имеет следующий формат:
GRANT привилегии 
ON объекты 
TO кому;
Применительно к таблицам и представлениям можно управлять  следующими правами доступа:
- право на выборку данных
INSERT
- право на добавление  данных
DELETE
- право на удаление  данных
UPDATE
- право на обновление  данных (можно указать определенные  столбцы, разрешенные для обновления)
REFERENCES
- право на использование  внешних ключей, ссылающихся на  данную таблицу (можно указать  определенные столбцы)

По умолчанию пользователь не имеет никаких прав доступа  к таблицам и представлениям - их необходимо передать с помощью операторов GRANT. 
По отношению к процедуре можно предоставить право на выполнение.  
Права доступа к базе данных как к единому целому может предоставлять ее администратор или пользователь с привилегией security. Эти "права" на самом деле устанавливают ряд ограничений на использование базы данных, то есть по сути являются запретительными. Имеется в виду ограничение на число операций ввода/вывода или число строк, возвращаемых одним запросом, ограничение права создания таблиц и процедур и т.п. По умолчанию пользователь не стесняется количественными лимитами и получает право на создание объектов в базе. Наложение подобных количественных ограничений препятствует монополизации сервера одним клиентом и может использоваться как один из инструментов поддержания высокой готовности. 
Отметим, что при создании базы данных указывается ее статус - общая или личная. Это влияет на подразумеваемые права доступа к базе. По умолчанию право на подключение к общей базе предоставляется всем. Право на подключение к личной базе нужно передавать явным образом. Право на подключение необходимо для выполнения всех прочих операций с базой и содержащимися в ней объектами. 
Обратим внимание на следующее любопытное обстоятельство. По умолчанию все пользователи имеют право создавать процедуры в базах данных. Если бы они при этом автоматически получали права на выполнение, то смогли бы осуществить по существу любую операцию с данными, поскольку выполнение процедуры не требует прав доступа к обрабатываемым объектам. К счастью, для передачи привилегии доступа к объектам, и в, частности, для предоставления права на выполнение процедуры, надо быть не только владельцем объекта, но и администратором базы данных.  
Права доступа к серверу распространяются на все базы данных, обслуживаемые данным серверам. Набор этих прав тот же, что и для отдельных баз данных. 
Привилегии, явно определенные для отдельных баз, имеют приоритет над привилегиями сервера. 
По отношению к событиям имеются две привилегии - RAISE и REGISTER. Первая позволяет возбуждать события, вторая - регистрироваться для их получения. 
Оператор GRANT может содержать необязательную часть, принципиально важную для защиты СУБД. Имеется в виду конструкция
GRANT ... 
... 
WITH GRANT OPTION;
Подобный оператор GRANT передает не только указанные в нем привилегии, но и права на их дальнейшую передачу.
3.3.3. Получение  информации о привилегиях 
Важно не только давать и отбирать привилегии, но и иметь информацию о том, какими правами доступа обладает каждый из субъектов. Подобные данные можно получить с помощью функции dbmsinfo, а также путем анализа содержимого таблиц в базе данных iidbdb. 
Средствами SQL из этих таблиц можно извлечь необходимую информацию.
3.4. Использование  представлений для управления  доступом
СУБД предоставляют специфическое  средство управления доступом - представления. Представления позволяют сделать  видимыми для субъектов определенные столбцы базовых таблиц (реализовать  проекцию) или отобрать определенные строки (реализовать селекцию). Не предоставляя субъектам прав доступа к базовым  таблицам и сконструировав подходящие представления, администратор базы данных защитит таблицы от несанкционированного доступа и снабдит каждого  пользователя своим видением базы данных, когда недоступные объекты как  бы не существуют. 
Приведем пример создания представления, содержащего два столбца исходной таблицы и включающего в себя только строки с определенным значением одного из столбцов:
CREATE VIEW empview AS 
SELECT name, dept 
FROM employee 
WHERE dept = 'shoe';
Предоставим всем право на выборку из этого представления:
GRANT SELECT 
ON empview 
TO PUBLIC;
3.5. Иерархия прав  доступа
Оператор GRANT и другие средства управления доступом СУБД позволяют  реализовать следующие виды ограничения  доступа:
      операционные ограничения (за счет прав доступа SELECT, INSERT, UPDATE, DELETE, применимых ко всем или только некоторым столбцам таблицы);
      ограничения по значениям (за счет механизма представлений);
      ограничения на ресурсы (за счет привилегий доступа к базам данных).
При обработке запроса  СУБД сначала проверяет права  доступа к объектам. Если операционные ограничения оказываются нарушенными, запрос отвергается с выдачей  соответствующей диагностики. Наконец, после учета двух предыдущих ограничений, запрос поступает на обработку оптимизатору. Если тот обнаружит превышение ограничений  на ресурсы, запрос будет отвергнут  с выдачей соответствующей диагностики. 
На иерархию привилегий можно посмотреть и с другой точки зрения. Каждый пользователь, помимо, собственных, имеет привилегии PUBLIC. Кроме этого, он может входить в различные группы и запускать приложения с определенными ролями. Как соотносятся между собой права, предоставленные различным именованным носителям привилегий? 
Иерархия авторизации выглядит для СУБД INGRES следующим образом:
      роль (высший приоритет)
      пользователь
      группа
      PUBLIC (низший приоритет)
3.7. Метки безопасности  и принудительный контроль доступа
Выше были описаны средства произвольного управления доступом, характерные для уровня безопасности C. Они в принципе достаточны для подавляющего большинства коммерческих приложений. Тем не менее, они не решают одной весьма важной задачи - задачи слежения за передачей информации. Средства произвольного управления доступом не могут помешать авторизованному пользователю законным образом получить секретную информацию и затем сделать ее доступной для других, неавторизованных пользователей. Нетрудно понять, почему это так. При произвольном управлении доступом привилегии существуют отдельно от данных (в случае реляционных СУБД - отдельно от строк реляционных таблиц). В результате данные оказываются "обезличенными", и ничто не мешает передать их кому угодно даже средствами самой СУБД. 
В "Критериях оценки надежных компьютерных систем", применительно к системам уровня безопасности B, описан механизм меток безопасности, реализованный в версии INGRES/Enhanced Security (INGRES с повышенной безопасностью). Применять эту версию на практике имеет смысл только в сочетании с операционной системой и другими программными компонентами того же уровня безопасности. В СУБД INGRES/Enhanced Security к каждой реляционной таблице неявно добавляется столбец, содержащий метки безопасности строк таблицы. Метка безопасности состоит из трех компонентов:
      Уровень секретности. Смысл этого компонента зависит от приложения. В частности, возможен традиционный спектр уровней от "совершенно секретно" до "несекретно".
      Категории. Понятие категории позволяет разделить данные на "отсеки" и тем самым повысить надежность системы безопасности. В коммерческих приложениях категориями могут служить "финансы", "кадры", "материальные ценности" и т.п. Ниже назначение категорий разъясняется более подробно.
      Области. Является дополнительным средством деления информации на отсеки. На практике компонент "область" может действительно иметь географический смысл, обозначая, например, страну, к которой относятся данные.
Каждый пользователь СУБД INGRES/Enhanced Security характеризуется степенью благонадежности, которая также  определяется меткой безопасности, присвоенной  данному пользователю. Пользователь может получить доступ к данным, если степень его благонадежности  удовлетворяет требованиям соответствующей  метки безопасности. Более точно:
      уровень секретности пользователя должен быть не ниже уровня секретности данных;
      набор категорий, заданных в метке безопасности данных, должен целиком содержаться в метке безопасности пользователя;
      набор областей, заданных в метке безопасности пользователя, должен целиком содержаться в метке безопасности данных.
Специальная привилегия, DOWNGRADE, позволяет изменять метки безопасности, ассоциированные с данными. Подобная возможность необходима, например, для коррекции меток, по тем или  иным причинам оказавшихся неправильными. 
Представляется естественным, что СУБД INGRES/Enhanced Security допускает не только скрытое, но и явное включение меток безопасности в реляционные таблицы. Появился новый тип данных, security label, поддерживающий соответствующие операции сравнения. 
INGRES/Enhanced Security - первая СУБД, получившая сертификат, эквивалентный аттестации на класс безопасности B1. Вероятно, метки безопасности постепенно войдут в стандартный репертуар систем управления базами данных.
 
4. Поддержание  целостности данных в СУБД
Для коммерческих организаций  обеспечение целостности данных по крайней мере не менее важно, чем  обеспечение конфиденциальности. Конечно, неприятно, когда кто-то подглядывает за суммами на счетах клиентов, но гораздо  хуже, когда в процессе перевода денег со счета на счет часть суммы  исчезает в неизвестном направлении. 
Известно, что главными врагами баз данных являются не внешние злоумышленники, а ошибки оборудования, администраторов, прикладных программ и пользователей. Защита от подобных ошибок - главная тема этого раздела. 
С точки зрения пользователя СУБД, основными средствами поддержания целостности данных являются ограничения и правила.
4.1. Ограничения
Ограничения могут относиться к таблицам или отдельным столбцам. Ограничения на столбцы задаются при создании таблицы, в операторах CREATE TABLE 
Табличные ограничения относятся к группе столбцов и могут задаваться как при создании таблицы, так и позже, посредством оператора ALTER TABLE. 
Следующий пример содержит именованное ограничение, связывающее значения в двух столбцах:
CREATE TABLE dept ( 
dname char(10), 
budget money, 
expenses money, 
CONSTRAINT check_amount CHECK (budget > 0 and expenses <= budget) 
); 
{Бюджет должен быть положительным, а расходы не должны выходить за рамки бюджета}
Ссылочные ограничения отвечают за целостность связей между таблицами. Подобное ограничение требует, чтобы  каждому значению в столбце или  группе столбцов одной таблицы соответствовало  ровно одно значение в другой таблице. Название ограничения объясняется  тем, что такие значения играют роль ссылок между таблицами в реляционной  модели. 
Приведем пример ссылочного ограничения:
CREATE TABLE emp ( 
ename char(10), 
edept char(10) references dept(dname) 
); 
{Ни один работник не должен числиться в неизвестном отделе}
Ограничения всех видов накладываются  владельцем таблицы и влияют на исход  последующих операций с данными. Перед завершением выполнения SQL-оператора  производится проверка имеющихся ограничений. При обнаружении нарушений СУБД сигнализирует о ненормальном завершении и аннулирует внесенные оператором изменения. 
Отметим, что для наложения ссылочного ограничения необходимо обладать привилегией REFERENCES по отношению к таблице, на которую делается ссылка (dept в примере выше). 
Ограничения можно не только накладывать, но и отменять. При этом между ограничениями могут существовать зависимости, и отмена одного из них может потребовать ликвидации других (ссылочных) ограничений, зависящих от первоначального.
При массовом копировании  данных контроль ограничений отключается. Это значит, что необходимо дополнять  копирование запуском процедуры  глобальной проверки целостности.
4.2. Правила
Правила позволяют вызывать выполнение заданных действий при определенных изменениях базы данных. Обычно действие - это вызов процедуры. Правила  ассоциируются с таблицами и  срабатывают при изменении этих таблиц. 
В отличие от ограничений, которые являются лишь средством контроля относительно простых условий, правила позволяют проверять и поддерживать сколь угодно сложные соотношения между элементами данных в базе. 
Как и в случае ограничений, проверка правил отключается при массовых операциях копирования.
СУБД обеспечивает автоматическое удаление правил в тех случаях, когда  удаляется соответствующая таблица. Тем самым поддерживается целостность  системы таблиц и правил. 
В контексте информационной безопасности важно отметить, что создать правило, ассоциируемое с таблицей, может владелец этой таблицы, имеющий право на выполнение соответствующей процедуры. Пользователь, действия которого вызывают срабатывание правила, должен обладать лишь необходимыми правами доступа к таблице. Тем самым правила неявно расширяют привилегии пользователей. Подобные расширения нуждаются в строгом административном контроле.
5. Средства поддержания  высокой готовности
В коммерческих приложениях  высокая готовность аппаратно-программных  комплексов является важнейшим фактором. Применительно к СУБД средства поддержания  высокой готовности должны обеспечивать нейтрализацию аппаратных отказов, особенно касающихся дисков, а также  восстановление после ошибок обслуживающего персонала или прикладных программ. 
Подобные средства должны с самого начала закладываться в архитектуру комплекса. Например, необходимо использовать тот или иной вид избыточных дисковых массивов. Конечно, это сделает аппаратно-программное решение более дорогим, но зато убережет от возможных убытков во время эксплуатации.
5.1. Кластерная  организация сервера баз данных
Мы будем понимать под  кластером конфигурацию из нескольких компьютеров (узлов), выполняющих общее  приложение (такое, например, как сервер баз данных). Обычно кластер содержит также несколько дисковых подсистем, совместно используемых узлами-компьютерами, и избыточные связи между компонентами. С внешней точки зрения кластер  выглядит как единое целое, а наличие  нескольких узлов способствует повышению  производительности и устойчивости к отказам. 
В настоящем разделе будет рассмотрена разработка компании Sun Microsystems, Inc - SPARCcluster PDB Server (параллельный сервер баз данных на основе SPARC-кластера).
 
В минимальной конфигурации SPARCcluster PDB Server состоит из двух узлов SPARCserver 1000, двух дисковых подсистем SPARCstorage Array и консоли кластера (SPARCclassic). Узлы- компьютеры соединяются между собой  посредством быстрого Ethernet (100 Мбит/с), дисковые подсистемы подключаются через  оптоволоконные каналы. В более мощной конфигурации вместо SPARCserver 1000 может  использоваться SPARCcenter 2000, а число  дисковых подсистем способно достигать 32 (до 1 Тб дискового пространства). Каждый узел кластера - это многопроцессорный  компьютер, к которому, помимо прочих, подключены накопители на DAT-лентах (или  автозагрузчики кассет с такими лентами). Все связи с компьютерами и  дисковыми подсистемами продублированы. 
Следующий рисунок поясняет аппаратную организацию SPARCcluster PDB Server.

Рис. 1. Аппаратная организация SPARCcluster PDB Server (на рисунке не показаны связи кластера с внешним миром)
Подобная аппаратная архитектура  обеспечивает устойчивость к отказам (никакой одиночный отказ не вызывает остановки работы кластера в целом). В то же время избыточные компоненты (компьютеры, дисковые подсистемы) отнюдь не ограничиваются ролью горячего резерва - они полностью задействованы  в процессе обычной работы. 
Вся аппаратура устроена так, что допускает замену в горячем режиме, без остановки других компонентов кластера.
5.1.2. Программная  организация SPARCcluster PDB Server 
Если рассматривать программную организацию SPARCcluster PDB Server в контексте надежной работы баз данных, необходимо обратить внимание еще на один компонент - фронтальную машину, на которой выполняется какой-либо монитор транзакций, например, TUXEDO. С учетом этого дополнения программная организация приобретает следующий вид. 
Рассмотрим компоненты программного обеспечения SPARCcluster PDB Server. 
Устойчивый к отказам распределенный менеджер блокировок (Fault Tolerant Distributed Lock Manager, FT-DLM) управляет параллельным доступом к базам данных, устанавливая и снимая блокировки. Кроме того, FT-DLM нейтрализует последствия отказов, снимая блокировки, установленные вышедшим из строя узлом. FT-DLM взаимодействует с сервером Oracle для поддержки неблокируемых операций чтения и для блокировки на уровне строк при записи в таблицы. В результате обеспечивается целостность и сериализация транзакций в сочетании с параллельной работой узлов кластера и с параллельным доступом к нескольким дисковым подсистемам.

Рис. 2. Программная организация SPARCcluster PDB Server (узлы кластера работают под управлением  ОС Solaris версии 2.4 или выше)
Распределенность менеджера  блокировок означает, что на каждом узле кластера работает свой экземпляр FT-DLM и что FT-DLM умеет динамически  реконфигурировать себя (как при  выходе узлов из строя, так и при  добавлении новых узлов). В результате выход из строя одного узла не означает краха всего сервера баз данных - сервер жив, пока работает хотя бы один менеджер блокировок. 
В рассматриваемом контексте основное назначение распределенного менеджера томов - поддержка зеркалирования дисков с тем важным дополнением, что устройства, составляющие пару, могут принадлежать разным дисковым подсистемам. 
Подсистема обнаружения и нейтрализации отказов постоянно отслеживает доступность ресурсов, составляющих кластер. При обнаружении неисправности запускается процесс реконфигурации, изолирующий вышедший из строя компонент при сохранении работоспособности кластера в целом (с выходом из строя диска справляется менеджер томов). 
Подсистема управления кластером состоит из трех инструментов с графическим интерфейсом: консоли кластера, менеджера томов и менеджера сервера Oracle. Их интеграция обеспечивает централизованное оперативное управление всеми ресурсами кластера.
5.1.3. Нейтрализация  отказа узла 
Рассмотрим, как в SPARCcluster PDB Server реализована нейтрализация самого неприятного из отказов - отказа узла. Программное обеспечение предпринимает при этом следующие действия:
      Подсистема обнаружения отказов выявляет вышедший из строя узел.
      Создается новая конфигурация кластера, без отказавшего узла. Этот процесс занимает 1 - 2 минуты, в течение которых обработка транзакций приостанавливается.
      Менеджер блокировок производит восстановление: а
    Подтвержденные транзакции от отказавшего узла (транзакции, об успешном завершении которых другие узлы кластера не успели узнать) накатываются вперед и деблокируются. а
    Неподтвержденные транзакции от отказавшего узла откатываются и также деблокируются.
В этот период транзакции обрабатываются исправными узлами, но, вероятно, несколько  медленнее, чем обычно.
    Монитор транзакций повторно направляет в кластер неподтвержденные транзакции.
    Вышедший из строя узел ремонтируется и вновь запускается.
    Создается новая конфигурация кластера, включающая в себя отремонтированный узел.
5.2. Тиражирование  данных
В контексте информационной безопасности тиражирование можно  рассматривать как средство повышения  доступности данных. В Informix OnLine-DS 7.1 поддерживается модель тиражирования, состоящая в полном отображении  данных с основного сервера на вторичные.  
В конфигурации серверов Informix OnLine-DS с тиражированием выделяется один основной и ряд вторичных серверов. На основном сервере выполняется и чтение, и обновление данных, а все изменения передаются на вторичные серверы, доступные только на чтение (рис. 3). В случае отказа основного сервера вторичный автоматически или вручную переводится в режим доступа на чтение и запись (рис. 4).  
После восстановления основного сервера возможен сценарий, при котором этот сервер становится вторичным, а бывшему вторичному, который уже функционирует в режиме чтения-записи, придается статус основного; клиенты, которые подключены к нему, продолжают работу. Таким образом, обеспечивается непрерывная доступность данных. 
Тиражирование осуществляется путем передачи информации из журнала транзакций (логического журнала) в буфер тиражирования основного сервера, откуда она пересылается в буфер тиражирования вторичного сервера. Такая пересылка может происходить либо в синхронном, либо в асинхронном режиме. Синхронный режим гарантирует полную согласованность баз данных - ни одна транзакция, зафиксированная на основном сервере, не останется незафиксированной на вторичном, даже в случае сбоя основного сервера. Асинхронный режим не обеспечивает абсолютной согласованности, но улучшает рабочие характеристики системы.


Тиражирование


 

     
 

   


 

  Основной 
сервер
  Вторичный 
сервер
 

 
Рис. 3. Тиражирование. Основной сервер доступен на чтение и запись, вторичный - только на чтение.



и т.д.................


 





 
     



Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


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