ГОСЫ / KIS_Romanova

4. Планирование резервного копирования корпоративных данных

Планирование резервного копирования очень больших БД

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

резервное копирование/восстановление использует по одному потоку на каждое дисковое устройство, если БД была определена файлами, расположенными на разных дисках;

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

Стратегия резервного копирования должна быть реализована таким образом, чтобы БД использовали:

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

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

11

5. Распределенные базы данных (РБД) КИС

ТЕХНОЛОГИИ РАСПРЕДЕЛЕННОЙ ОБРАБОТКИ ДАННЫХ

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

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

РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ (РБД)

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

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

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

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

Вцелом, применение распределенных баз данных связано с более высоким риском. Например, требуется обеспечить соблюдение мер безопасности сразу на нескольких узлах, что достаточно не просто реализовать. Распределенные базы данных трудно проектировать и обслуживать. Порядок работы в системе может со временем поменяться, что повлечет за собой изменение схемы хранения данных. Как клиенты, так и серверы должны уметь обрабатывать запросы к данным, которые не расположены в ближайшей подсистеме. Плохо спроектированная РБД может демонстрировать меньшую производительность, чем одиночный централизованный сервер БД.

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

12

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

ДВЕНАДЦАТЬ ПРАВИЛ ДЕЙТА для РБД

1.Независимость локального узла (local autonomy) – каждый локальный узел может действовать как независимая, автономная централизованная СУБД. Каждый узел отвечает за безопасность, управление параллельным выполнением, резервное копирование и восстановление данных

2.Независимость от центрального узла (no reliance on central site) – все узлы системы независимы м имеют равные возможности, а расположенные на них базы данных являются равноправными поставщиками в общее пространство данных. БД на каждом из узлов полностью защищена от НСД.

3.Независимость от сбоев (continuous operation) – функционирование всей системы не зависит от сбоя на каком-либо узле, система продолжает выполнение операций даже при неисправности узла или при расширении сети. Это возможность непрерывного доступа к данным (извест. как "24 часа в сутки, семь дней в неделю") в рамках ddb вне зависимости от их расположения и вне зависимости от операций, выполняемых на локальных узлах. Это качество можно выразить лозунгом "данные доступны всегда, а операции над ними выполняются непрерывно

4.Прозрачность расположения (location independence) – пользователь не обязан знать реальное, физическое расположение данных в РБД. Транспортировка запросов к базам данных осуществляется встроенными системными средствами

5.Прозрачность фрагментации (fragmentation independence) – пользователь видит единую логическую БД, у него нет необходимости знать структуру и имена фрагментов БД для получения доступа к ним

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

7.Распределенная обработка запросов (distributed query processing) – может выполняться на нескольких узлах процессоров данных DP (Data Processor) в рамках обычного SQL-запроса. Оптимизацию запросов СУБД выполняет прозрачно для пользователя

8.Распределенная обработка транзакций (distributed transaction processing) – транзакции могут согласованно обновлять данные на нескольких различных узлах, выполнение распределенной транзакции на нескольких узлах DP происходит прозрачно для пользователя

9.Независимость от оборудования (hardware independence) – система должна выполняться на любой аппаратной платформе

10.Независимость от ОС (operationg system independence) - система должна выполняться в любой ОС

11.Независимость от сети (network independence) – система должна работать на любой сетевой платформе, то есть РСУБД должна поддерживать широкий спектр сетевых протоколов

12.Независимость от базы данных (database independence) – система должна поддерживать Базы Данных различных производителей

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

Основные практические проблемы РБД:

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

13

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

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

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

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

6.необходимость обеспечения совместимости СУБД разных типов

ТИПЫ РАСПРЕДЕЛЕННЫХ БД

РБД подразделяются на однородные (гомогенные) или разнородные (гетерогенные).

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

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

Любая распределенная СУБД должна иметь следующий набор функциональных возможностей:

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

2.расширенные средства ведения каталога, позволяющие сохранять сведения о распределении данных

3.средства обработки распределенных запросов

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

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

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

14

6.Распределенное размещение и доступ к данным в КИС

РАЗМЕЩЕНИЕ и ДОСТУП к ДАННЫМ в РБД

При размещении хранимых данных в РБД неизбежно сегментирование или фрагментация базы. Допускается разбиение одного объекта на два или более фрагмента. Объектом может быть пользовательская база данных или таблица. Существуют два основных типа фрагментации – горизонтальная и вертикальная. В первом случае фрагменты представляют собой подмножества строк, во втором – подмножества столбцов. Допускается и смешанная фрагментация – комбинация вертикальной и горизонтальной, например, таблица разделяется на несколько горизонтальных множеств (строк), каждое из которых делится на вертикальные множества (столбцов). Каждый фрагмент размещается на узле, выбранном с учетом оптимальной схемы доступа. (Определение и размещение фрагментов должно проводиться с учетом особенностей использования базы данных, в частности, на основе анализа транзакций). Информация о фрагментации данных хранится в системном каталоге распределенных данных (Distributed Data Catalog - DDC), к которому процессор транзакций (TP) может получить доступ при обработке запросов пользователя. (Фрагментированную таблицу в любой момент можно объединить посредством комбинации операций объединения – union, и соединения – join).

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

15

7. Технология репликации распределенных баз данных

РЕПЛИКАЦИЯ

(тиражирование) replication

В РСУБД - механизм внесения изменений во вторичные БД непосредственно после завершения транзакции по мере доступности серверной или клиентской БД. Метод предполагает промежуточное хранение транзакций. Обеспечивает синхронизацию (согласованность) фрагментов распределенной базы данных.

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

Задачи, решаемые при помощи репликации

Репликации используют для распределения нагрузки между серверами, когда в системе работает большое количество пользователей. В этом случае на несколько серверов устанавливаются копии одних и тех же данных, а пользователи, объединенные в группы, могут обращаться к выделенному серверу. Система с такой архитектурой легко масштабируется – по мере роста предприятия и увеличения количества пользователей добавляют новые серверы и реплицируют на них необходимые данные. Еще одной типичной задачей распределения и тиражирования данных является поддержка географически удаленных пользователей. Без репликации они вынуждены работать через глобальные сети (WAN –Wide Area Network), если установить в удаленных филиалах дополнительные серверы и создать на них реплики данных, это повысит скорость доступа к данным и разгрузит основной сервер предприятия.

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

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

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

Издатель (publisher) – это система (сервер) исходной базы данных, которая предоставляет данные (в виде подготовленных публикаций) для репликации. Публикация – это набор статей, сгруппированных как один блок. Например, можно создать публикацию, которая будет использоваться для репликации базы данных, состоящей из нескольких таблиц, каждая из которых определена как статья. Репликация базы данных в целом как одной публикации является более эффективной операцией, чем репликация таблиц по отдельности. Публикация может состоять из одной статьи, но почти всегда состоит из нескольких. Подписчик может подписываться только на публикации, но не статьи. Поэтому для подписки на одну статью нужно сконфигурировать соответствующую публикацию, содержащую только эту статью. Статья – это отдельный набор данных, который подлежит репликации. Статья может быть целой таблицей, подмножеством таблицы, состоящим из определенных столбцов или строк, или хранимой процедурой. Эти подмножества создаются с помощью фильтров. Фильтр, используемый для создания подмножества строк, называется горизонтальным. Фильтр, используемый для создания подмножества, состоящего из столбцов, называется вертикальным фильтром.

16

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

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

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

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

Агент

Публикация репликации (публикуемые

данные)

СТРАТЕГИИ РЕПЛИКАЦИИ На практике выбирают одну из двух стратегий тиражирования данных в распределенной системе:

1.Тиражирование с полной репликацией – предусматривает размещение полной копии всей БД на каждом из узлов системы. РБД в данном случае называется полностью реплицированной. Стоимость устройств хранения данных и уровень затрат на передачу информации об обновлениях в этом случае будут самыми высокими. Для выполнения полной репликации рекомендуется использовать технологию снимков (SNAPSHOT). Снимок представляет собой копию БД в определенный момент времени. Эти копии обновляются через некоторый заданный интервал времени, например, 1 раз в час или в сутки. Снимок можно обновить принудительно командой REFRESH SNAPSHOT.

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

СПОСОБЫ РАСПРОСТРАНЕНИЯ РЕПЛИКАЦИИ

17

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

18

8. Модели, методы и планирование репликации распределенных баз данных

МОДЕЛИ РЕПЛИКАЦИИ В основе конкретной архитектуры репликации может лежать одна из четырех физических моделей,

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

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

СЕРВЕР издатель/ дистрибьютор

2. Центральный издатель/Удаленный дистрибьютор.

сервер

подписчик

дистрибьютор

сервер

подписчик

19

4.Несколько подписчиков/Несколько издателей

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

МЕТОДЫ РЕПЛИКАЦИИ Метод или тип репликации определяет, какая технология будет использоваться для создания реплик и

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

20