Высокий уровень доступности — это
концепция, которую должен понимать каждый администратор баз данных.
Она относится к скорости отклика и доступности системы. Иногда
высокий уровень доступности означает время отклика в пределах
нескольких секунд, в то время как в других случаях речь идет
о
долях секунды. Однажды я консультировал компанию,
веб-серверы которой должны были успевать отправить SQL-запрос и
получить на него ответ в течение нескольких миллисекунд. Если время
отклика превышало указанную величину, база данных считалась
недоступной, а веб-сервер пытался подключиться к следующему по
списку серверу баз данных.
Поскольку пользователям требуются все более
быстрые приложения, понимание того, как добиться высокого уровня
доступности и небольшого времени отклика, поможет более грамотно
планировать работу зависящих от данных приложений.
К счастью, приложение SQL Server™ 2005 обладает
рядом возможностей, позволяющих повысить уровень доступности,
включая репликацию и кластеризацию, а также зеркальное отображение
баз данных, моментальные снимки баз данных и доставку журналов баз
данных. Давайте рассмотрим эти возможности более подробно и
попытаемся понять, как выбрать оптимальный для имеющейся среды
вариант. Начнем с рис. 1, на котором показаны возможности повышения
уровня доступности, предоставляемые приложением SQL Server
2005.
Определение
высокого уровня доступности
При планировании работы приложения с высоким
уровнем доступности прежде всего необходимо определиться, что под
этим понимается в данной конкретной среде. Для некоторых организаций
высокий уровень доступности означает наличие избыточного
оборудования, аналогичного рабочему, причем как данные, так и
оборудование должны быть в работоспособном состоянии и доступны в
течение не менее 99,995 процентов времени. Другим организациям может
требоваться только высокий уровень доступности самих данных, а
возможности переключения на другой ресурс при сбое уделяется меньше
внимания. Чтобы выбрать правильное решение в конкретной ситуации,
очень важно определиться, что именно подразумевается под высоким
уровнем доступности.
Необходимо также понять, какие типы простоев
могут возникать, и проанализировать, как они могут сказаться на
соглашениях об условиях обслуживания (SLA). Простои, которые могут
повлиять на уровень доступности, делятся на плановые, внеплановые и
периоды пониженной производительности.
Обычно плановый простой — это время, отведенное
для запланированного обслуживания, о котором пользователи систем
предупреждаются заранее. Внеплановый простой чаще всего является
результатом отказа оборудования или сбоя программного обеспечения,
из-за которого данные становятся недоступными. Период пониженной
производительности тоже может служить причиной простоев и часто
определяется по времени отклика для конечных пользователей, которое
обычно заранее согласовывается предприятием и ИТ-организацией и
включается в соглашение об условиях обслуживания того или иного
вида.
Необходимо не только определить возможные причины
простоев, но и оценить, насколько интенсивно используются данные,
должны ли они всегда быть доступны или иногда допустимы периоды
меньшей доступности либо недоступности данных. Нужно также решить,
будут ли обеспечивающие повышение уровня доступности средства
географически располагаться в том же месте или в удаленном месте.
При принятии решения, вероятно, придется учитывать и ограничения
бюджета. Давайте теперь рассмотрим каждую возможность повышения
уровня доступности.
Зеркальное отображение баз данных
Прежде чем начать подробное рассмотрение
зеркального отображения баз данных, необходимо определиться с
терминологией.
Основной
сервер — рабочий сервер-источник, на котором
размещается база данных, постоянно отправляющая свои журналы
транзакций зеркальному серверу и его базе данных.
Зеркальный
сервер — сервер-получатель, на котором размещается
резервная копия базы данных. Зеркальная копия постоянно
синхронизируется с базой данных основного сервера.
Роль показывает, служит конкретный
сервер основным или зеркальным.
Следящий
сервер — сервер, который наблюдает за работой основного
и зеркального серверов и может запустить процесс автоматического
перехода на другой ресурс при сбое.
Партнер — основной или зеркальный
сервер.
В обычной среде на основном сервере выполняется
резервная копия базы данных основного сервера, которая затем
восстанавливается на зеркальном сервере (см. рис. 2). После этого на основном сервере
необходимо настроить зеркальное отображение: либо в окне свойств
базы данных основного сервера в среде SQL Server Management Studio
(SMSS), либо с помощью сценариев языка T-SQL.
Figure
2 Database mirroring architecture
После того как зеркальное отображение настроено и
сеанс зеркального отображения установлен, базы данных основного и
зеркального серверов начинают синхронизироваться. База данных
основного сервера отправляет свой журнал транзакций с записью
событий, которые произошли после развертывания последней резервной
копии базы данных на зеркальном сервере. Зеркальный сервер получает
журнал и пытается как можно скорее применить его. При использовании
приложения SQL Server 2005 Enterprise Edition этот процесс является
многопоточным, в противном случае он представляет собой однопоточную
операцию. После применения журналов на зеркальном сервере базы
данных считаются синхронизированными и будут оставаться таковыми до
разрыва сеанса зеркального отображения.
Когда клиенты выполняют новые транзакции,
основной сервер проводит их в своей базе данных и при этом
доставляет записи журнала транзакций своей базы данных в журнал
повторяемых операций базы данных зеркального сервера или в очереди
журналов, где они подхватываются и применяются к зеркальной базе
данных. Как только транзакция выполнена и зафиксирована в базе
данных зеркального сервера, основному серверу отправляется ответ,
сообщающий о фиксации транзакции на зеркальном сервере. До получения
подтверждения от зеркального сервера никакие новые транзакции,
поступающие в систему, основным сервером не подтверждаются.
В случае сбоя зеркальный сервер может начать
процедуру автоматического переключения ресурсов, причем следящий
сервер поддерживает этот процесс, определяя, доступна ли база данных
основного сервера. Если произошел сбой, необходимо устранить
проблему на том сервере, который теперь является зеркальным
партнером, прежде чем он снова сможет стать основным. Как только
неполадки на зеркальном партнере устранены, начинается перемещение
обратно на сервер зеркального партнера, и базы данных вновь
синхронизируются. После завершения синхронизации сеанс зеркального
отображения может быть вновь начат.
Описанный режим зеркального отображения является
режимом высокого уровня безопасности, который обеспечивает
синхронные транзакционные операции посредством включения
транзакционной безопасности. Для этого режима не требуется следящий
сервер, поскольку преимущества автоматического перехода на другой
ресурс при сбое не используются. Все переходы на другой ресурс
запускаются вручную. Существует и другой режим зеркального
отображения, который обеспечивает выполнение синхронных
транзакционных операций. Это режим высокого уровня доступности. Для
него требуется не только включение транзакционной безопасности, но и
использование для автоматического перехода на другой ресурс при сбое
следящего сервера.
Третий, и последний, режим зеркального
отображения — это режим высокой производительности. В этом режиме
транзакционная безопасность должна быть отключена, что позволяет
обеспечить поддержку асинхронных операций. Последняя, в свою
очередь, дает возможность основному партнеру фиксировать транзакции,
не дожидаясь, пока запись транзакции будет внесена в базу данных
зеркального сервера. Режим высокой производительности не требует
наличия в конфигурации следящего сервера.
Обратите внимание, что при использовании
зеркального отображения на основном и зеркальном серверах должен
быть установлен одинаковый выпуск сервера SQL Server. Это не
относится к следящему серверу, на котором может быть установлен
выпуск SQL Server Express Edition. Кроме того, важно, чтобы база
данных основного сервера находилась в режиме полного
восстановления.
Технология ADO.NET 2.0 интегрирована в приложение
SQL Server 2005 и включает возможность поддержки зеркального
отображения баз данных и обеспечения для этого приложения
прозрачного переключения при сбое на среду зеркального отображения.
Это позволяет приложению ADO.NET автоматически переходить на другой
ресурс, если подключение к базе данных основного сервера невозможно.
Для этого не требуется дополнительной настройки или написания
добавочного кода. Для настройки достаточно указать в строке
подключения общего пользователя для обоих серверов и партнера по
переходу на другой ресурс. Ниже приведен пример строки подключения
ADO.NET, в которой указан партнер по переходу на другой ресурс для
среды базы данных с зеркальным отображением:
"Provider=SQLNCLI.1;Data Source=MirrorDB;Failover Partner=SQL03;
Initial Catalog=AdventureWorks;
Persist Security Info=True;User ID=TestUser; Password=TestPswd; Pooling=True;
Connect Timeout=5;Application Name=ADOMirrorTest"
Зеркальное отображение баз данных может оказаться
удачным вариантом для компании, что зависит от требований,
предъявляемых к приложениям и данным. Впрочем, чтобы добиться
оптимальной производительности, необходимо принять во внимание
несколько факторов. Например, насколько велики интенсивность
транзакций системы или объем изменяемых данных? При принятии решения
о зеркальном отображении баз данных очень важно определить,
достаточно ли пропускной способности и скорости сети для передачи
нужного объема данных и обработки имеющегося числа транзакций. Кроме
того, необходимо учитывать повышенную нагрузку на подключение. Это
особенно важно, если зеркальный сервер географически расположен в
другом месте. При определении наличия налагаемых средой ограничений,
которые могли бы помешать эффективной работе зеркального
отображения, ключевую роль играет предварительное наблюдение за
системой.
Зеркальное отображение баз данных может оказаться
особенно удачным вариантом, если необходимо сократить издержки.
Действительно, чтобы реализовать архитектуру зеркального отображения
баз данных, не требуются ни общие диски, ни углубленные или
специальные навыки. В отличие от кластеризации, для зеркального
отображения баз данных не требуется, чтобы оборудование обоих
партнеров было одинаковым. К тому же реализовать зеркальное
отображение достаточно просто. Это делается с помощью мастера
настройки, который можно найти на вкладке Mirroring (зеркальное
отображение) окна свойств базы данных (см. рис.
3). Для получения дополнительных сведений я также рекомендую
прочитать технический документ «Database Mirroring Best Practices
and Performance Considerations» (Лучшие методы работы с зеркальными
отображениями баз данных и вопросы производительности),
расположенный по адресу go.microsoft.com/fwlink/?LinkId=80897 (на
английском языке).
Figure
3 Mirroring setup wizard
Моментальные снимки баз
данных
Моментальные снимки баз данных — это новая
технология, представленная в продукте SQL Server 2005 Enterprise
Edition, но она не предназначена для повышения уровня доступности.
Такие снимки должны использоваться в сочетании с другими
технологиями в качестве варианта, предназначенного для
восстановления баз данных или для создания надежных отчетов.
Моментальный снимок — это просто представление базы данных на
конкретный момент времени, доступное только для чтения.
Его можно создать с помощью команды CREATE
DATABASE, например:
CREATE DATABASE SnapDB_20061028_2030 ON
(NAME = SnapDB_Data, FILENAME =
'C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SnapDB_20061028_2030.snp')
AS SNAPSHOT OF SnapDB;
GO
При создании моментального снимка базы данных
используются один или несколько так называемых разреженных файлов, а
не файлы данных, которые применяются обычной базой данных. Эти
разреженные файлы, в сущности, представляют собой места виртуального
хранения, изначально не содержащие никаких данных. Они задействуются
для хранения данных только при изменении или удалении последних в
исходной базе данных. Данные записываются в разреженные файлы по
одной странице данных за раз, и моментальный снимок реальной базы
данных показывает только данные, которые были изменены с момента
создания снимка. Остальные данные берутся со страниц данных исходной
базы данных.
Для файлов моментального снимка базы данных
выделяется пространство, соответствующее размеру базы данных на
момент создания снимка. По размеру этих файлов нельзя определить,
какой объем данных они реально содержат. Получить эту информацию
можно с помощью инструкции языка T-SQL, например:
SELECT *
FROM fn_virtualfilestats(DB_ID(N'SnapDB_20061028_
2030'), 1);
GO
В соответствии со способом хранения данных в
разреженных файлах и в исходной базе при запросе моментального
снимка базы данных страницы данных извлекаются как из файлов
исходной базы данных, так и из разреженных файлов моментального
снимка. Из-за потребности в общем доступе к страницам данных
моментальные снимки могут существовать только на одном сервере с
исходной базой данных, с которой они были сделаны. Поскольку такая
архитектура не уменьшает числа операций ввода-вывода для исходной
базы данных, в этом случае моментальные снимки не должны
рассматриваться как вариант для составления отчетов, так как они не
отражают реального состояния базы данных.
Теперь рассмотрим ситуацию, когда зеркальное
отображение баз данных используется вместе с моментальными снимками.
Это позволяет физически отделить базу данных отчетов, зеркальную
базу данных и базу данных моментальных снимков от базы данных
основного сервера. Подготовка моментальных снимков базы данных
планируется с помощью агента SQL Server и пользовательского
сценария. Это позволяет создавать обновленные снимки через
регулярные интервалы времени. В примере сценария, приведенном на рис. 4, показана хранимая процедура, используемая
для решения этой задачи. Она разработана для применения внутри
задания и позволяет управлять созданием и удалением моментальных
снимков конкретной базы данных в имеющейся среде. Таким способом
можно было бы создать приемлемое решение для составления отчетов,
поскольку данные отчетов были бы отделены от рабочих данных.
Впрочем, необходимо помнить, что моментальные
снимки базы данных следует рассматривать как временные, поскольку
нет возможности выполнять их резервное копирование и они не могут
существовать без исходной базы данных. Если для разреженных файлов
не хватает места, снимок будет считаться поврежденным и подлежать
удалению.
Кроме того, если используются моментальные снимки
базы данных, в ходе выполнения операций по изменению данных в
исходной базе данных производительность системы может снижаться,
поскольку страницы данных из файлов данных исходной базы
записываются в разреженный файл каждого снимка. Таким образом, число
записей возрастает во столько раз, сколько моментальных снимков
имеет база данных.
Права чтения определяются исходной базой данных в
момент создания снимка и не могут быть изменены. Моментальный снимок
должен находиться на том же сервере, что и исходная база данных,
поскольку они совместно используют как страницы данных, так и
буферный кэш.
Использование моментальных снимков должно
рассматриваться как решение для составления отчетов только в том
случае, если оно используется совместно с зеркальным отображением. В
противном случае это не даст для среды никакого выигрыша в
производительности. Моментальные снимки баз данных, вероятно,
являются самым быстрым способом сохранить данные перед запуском в
системе сомнительной операции. Можно вернуть базу данных в
состояние, соответствующее моменту создания снимка, или извлечь
данные из снимка и заменить ими данные в исходной базе.
Необходимо определить для баз данных моментальных
снимков стандарт именования. Я обычно использую следующий стандарт:
originaldatabasename_date_time.snp. Согласно этому стандарту сначала
указывается имя исходной базы данных, а затем дата и время (в
24-часовом формате) создания снимка.
Доставка журналов
Доставка журналов — это вариант повышения уровня
доступности с некоторыми ограничениями. При реализации доставки
журналов используется резервное копирование и восстановление, что
обеспечивает очень экономичное решение. При доставке журналов
используются преимущества резервного копирования журналов транзакций
через заданные интервалы времени, что позволяет своевременно
обновлять базу данных-получателя.
При задании доставки журналов в приложении SQL
Server 2005 используются мастера, с помощью которых можно выполнить
настройку, планирование, инициализацию и наблюдение (см. рис. 5). Эта процедура очень проста и занимает
всего несколько минут.
Figure
5 Log shipping setup wizard
После определения базы данных-источника создается
расписание, а затем для файлов резервной копии указывается возраст
файлов. После этого необходимо определить файлы резервной копии в
качестве общих файловых ресурсов. После того как общие файловые
ресурсы определены, нужно указать местоположение файлов базы
данных-получателя и инициализировать ее, выполнив восстановление
базы данных-источника. И, наконец, необходимо настроить расписания
резервного копирования файлов и восстановления резервных копий
журналов транзакций со всеми предупреждениями или задержками,
которые требуются для каждого из этих этапов.
После того как настройка завершена, процедура
доставки журналов выполняет резервное копирование журнала транзакций
базы данных согласно расписания на общий сетевой ресурс. После того
как эти файлы отправлены на общий сетевой ресурс, данная резервная
копия применяется к базе данных-получателю согласно заданному
расписанию.
Благодаря своей простоте доставка журналов хорошо
работает во многих случаях. Эта технология является удачным
вариантом для повышения уровня доступности, поскольку она недорога и
может работать в системе с высокой интенсивностью транзакций. База
данных-получатель, которая используется при доставке журналов, может
быть доступна только для чтения, и тогда ее удобно применять для
составления отчетов. Доставка журналов требует минимальных издержек,
но в случае ее использования необходимо создать политику
предупреждений для обработки сбоев.
При принятии решения об использовании доставки
журналов в имеющейся среде нужно помнить, что настройка этой
технологии и управление ею очень просты и требуют минимальных
специальных навыков (или вообще не требуют таковых). Доставка
журналов не является решением для повышения уровня доступности в
режиме реального времени. Впрочем, в этих целях ее можно сочетать с
зеркальным отображением баз данных. Она ограничена как расписаниями,
так и операциями, такими как создание резервных копий, копирование
файлов и восстановление. Кроме того, переход на другой ресурс при
сбое придется выполнять вручную. Из перечисленных соображений
понятно, что доставка журналов обеспечивает простое решение для
среды, в которой задержки не являются критичными.
Кластеризация серверов SQL
Server
Кластеризация серверов работает на уровне
операционной системы и включает в себя дублирующее оборудование и
доступные кластеру общие дисковые ресурсы. Кластеризация, вероятно,
наименее заметна для конечных пользователей, но она же требует
максимальных затрат. Для этой технологии нужно минимум вдвое больше
оборудования, чем для работы некластерного сервера.
Тема кластеризации является достаточно сложной,
поэтому в данной статье будет рассматриваться не подробно, а только
в виде краткого обзора. Для создания кластера требуются два или
более серверов, на каждом из которых должна быть установлена одна и
та же версия операционной системы Windows Server® 2000 выпусков Advanced или Datacenter либо
системы Windows Server® 2003 выпусков
Enterprise или Datacenter. Кроме того, потребуется установка служб
MSCS (Microsoft® Cluster Services — службы
кластеров корпорации Майкрософт), которые распределяют права
владения общими ресурсами между серверами и управляют IP-адресами,
общими дисками и сетевыми именами. Еще для создания кластера
необходим общий дисковый ресурс. Обычно эту роль выполняет сеть SAN
(Storage Area Network — сеть областей хранения) или подключенное
запоминающее устройство SCSI.
Экземпляр сервера SQL Server также считается
ресурсом. В конфигурации кластера можно установить как выпуск
Standard, так и Enterprise продукта SQL Server 2005. Список
возможностей, которые поддерживаются каждым из выпусков приложения
SQL Server 2005, можно найти в документе «Feature Comparison Chart
for SQL Server 2005» (Сравнительная таблица характеристик выпусков
приложения SQL Server 2005), расположенном по адресу
microsoft.com/sql/prodinfo/features/compare-features.mspx (на
английском языке).
После того как ресурсы на кластере определены,
дополнительный узел кластера регулярно связывается с основным узлом,
используя периодический сигнал, передаваемый по частной сети между
двумя узлами кластера. Этот сигнал представляет собой
последовательность контрольных точек, которые фиксируются через
равные интервалы времени и позволяют определить, что на основном
узле произошел сбой.
В случае выхода из строя основного узла ресурсы
перемещаются на дополнительный узел, причем состояние логического
сервера не меняется. Клиенты могут продолжать работать с сервером
после небольшой паузы. Весь процесс перехода на другой ресурс при
сбое может занять от приблизительно 5 секунд и меньше до 30 секунд и
больше (в некоторых случаях), что зависит от оборудования,
программного обеспечения и сети кластера.
Кластеризация может представлять собой дорогую,
сложную технологию, которая требует специальных навыков для
устранения сбоев системы, но она обеспечивает наименее заметный для
конечных пользователей переход на другой ресурс при сбое из всех
вариантов автоматического перехода на другой ресурс. Каждое
приложение имеет свои особенности, и некоторые из них могут быть не
предназначены для работы с кластерами или не совместимы с ними. В
худшем случае приложению придется повторно подключаться к
серверу.
Репликация
Обеспечиваемую приложением SQL Server 2005
репликацию тоже можно использовать в архитектурах с высоким уровнем
доступности. Данный продукт поддерживает четыре типа репликации:
репликация моментальных снимков, транзакционная репликация,
одноранговая репликация и репликация слиянием. Одноранговая
репликация фактически является вариантом транзакционной репликации,
поэтому здесь она рассматриваться не будет.
Репликация позволяет использовать для повышения
уровня доступности дополнительный узел и базу данных-получатель,
причем база данных-получатель настолько же работоспособна, насколько
и база данных-источник. Это достигается путем использования
репликации слиянием, в ходе которой берутся транзакции как с базы
данных-источника, так и с базы данных-получателя. Затем обобщенные
изменения применяются к обеим базам. Как нетрудно догадаться, такая
конфигурация требует процедуры разрешения конфликтов.
Транзакционная репликация по своей логической
структуре очень близка к зеркальному отображению баз данных.
Транзакции, выполняемые в базе данных-источнике, доставляются в базу
данных-получатель, чтобы гарантировать согласованность среды. Затем
эти транзакции применяются к базе данных-получателю, которая потом
ожидает выполнения в системе следующей транзакции.
Репликация моментальных снимков очень похожа на
доставку журналов, поскольку и та, и другая проводятся через
запланированные интервалы времени, а обновление базы
данных-получателя выполняется посредством общего изменения, а не
путем применения каждой транзакции к обеим системам сразу после их
фиксации. Способы реализации обеих технологий во многом похожи.
Репликация требует специальных знаний, что может
оказаться проблемой в организациях, не имеющих выделенного
администратора баз данных. Репликация может быть достаточно сложной
задачей в плане отладки и действительно требует более сложной
структуры, если ее планируется использовать для повышения уровня
доступности.
Репликация может вполне соответствовать
требованиям, предъявляемым к решению, целью которого является
повышение уровня доступности. Транзакционная репликация исполняет те
же функции, которые зеркальное отображение баз данных может
выполнять на уровне записей, но без возможности автоматического
перехода на другой ресурс при сбое. Впрочем, при наличии достаточных
ресурсов и возможности посвятить некоторое время написанию
сценариев, создание решения для автоматического перехода на другой
ресурс при сбое не должно стать большой проблемой.
В отличие от зеркального отображения баз данных,
при репликации как исходная, так и конечная базы данных полностью
доступны для клиентских приложений. Репликация моментальных снимков
обеспечивает те же возможности, что и доставка журналов.
Нужно учитывать, что репликация — это проверенная
и хорошо документированная технология. Использование репликации в
качестве решения для повышения уровня доступности может иметь
некоторые недостатки и приводить к снижению производительности,
впрочем, не в большей степени, чем при применении зеркального
отображения. Вероятнее всего, любое решение для повышения уровня
доступности, построенное на основе репликации, будет иметь более
сложную для управления архитектуру: не обязательно
усовершенствованную, но точно более сложную. Кроме того, одна из
наиболее значительных трудностей, которую нужно учитывать, состоит в
следующем: если изменяется структура таблиц базы данных или
необходимо настроить репликацию еще одной таблицы, придется удалить
и заново определить публикацию, чтобы внести изменения в обе базы
данных.
Заключение
Из приведенного материала понятно, что к созданию
решения для повышения уровня доступности в имеющейся среде надо
подходить творчески. Каждая предоставляемая приложением SQL Server
2005 технология для повышения уровня доступности имеет свои сильные
и слабые стороны, и в различных ситуациях нужно применять разные
решения.
Доставка журналов, репликация моментальных
снимков и даже зеркальное отображение баз данных в режиме высокой
производительности могут стать хорошим выбором в том случае, если
веб-база данных-источник географически отделена от базы
данных-получателя (особенно, если не требуется, чтобы
вспомогательные данные были доступны в режиме реального
времени).
С другой стороны, если база данных-получатель
должна быть доступна в режиме реального времени, транзакционная
репликация или зеркальное отображение могут помочь в распределении
нагрузки, если интенсивность транзакций на сервере-источнике не
очень велика, а соединение между двумя узлами среды является быстрым
и не перегружено.
Кроме того, надо учитывать, насколько удобным
будет применение этих технологий. Если вы уже работали с некоторыми
из них, то, вероятно, сможете чувствовать себя комфортно. Если вы
руководитель и не имеете в своем подчинении выделенного
администратора баз данных, старайтесь избегать более сложных
технологий, таких как репликация, для которых нужно настраивать
множество компонентов и отладка которых может оказаться трудной.
Кроме того, рассмотрите вариант заключения договора с опытным
консультантом по продукту SQL Server, который поможет вам
разработать и реализовать оптимальное для имеющейся среды новое
решение для повышения уровня доступности, а также, возможно, обучить
сотрудников управлению этим решением.
Если высокий уровень доступности в вашей
организации означает, что данные должны быть доступны в течение
высокого процента времени, а периоды недоступности данных считаются
недопустимыми, вероятно, стоит отдать предпочтение
кластеризации.
В заключение напомню, что приложение SQL Server
2005 предоставляет ряд новых возможностей для реализации высокого
уровня доступности, которые предназначены для использования в средах
различных типов. Существует возможность применить только одну
технологию повышения уровня доступности или воспользоваться
преимуществами сочетания нескольких вариантов, но, как уже было
отмечено, в любом случае есть несколько возможных вариантов.
