(Возврат на основную страницу)

Содержание номера за Октябрь 2006 год

Масштабирование SQL Server. Часть 2 (См. Брайан Найт. Масштабирование SQL Server. Часть 1 // SQL Server для администраторов баз данных. 2006. № 3.)

Во второй части статьи речь пойдет о применении связанных серверов. Эта технология — один из основных компонентов тактики масштабирования Microsoft. Она позволяет SQL Server подключаться к любому OLE DB­совместимому источнику данных и выполнять запросы или удаленные вызовы процедур (RPC), как если бы это был локальный SQL Server.

Запросы к связанным серверам

А теперь пора повеселиться. Как вы будете использовать связанный сервер после его создания? Один из способов обратиться к нему заключается в применении четырехчастного имени:

<linked server name>.<catalog name>.<owner>.<object name>

Примечание Имя каталога и владелец нужны не для всех источников данных. Я обычно использую его, чтобы избежать путаницы. При подключении к другому источнику данных SQL Server вы должны использовать имя владельца (обычно это dbo).

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

SELECT * FROM SERVERB.Northwind.dbo.orders
WHERE OrderDate < '1997-01-01 00:00:00.000'

Этот запрос должен вернуть элементы, соответ­ствующие заказам, оформленным до 1997 г. Действительно просто! С помощью четырехчастного имени вы можете выполнить практически любой SQL­запрос. Например, вы можете применить выражение INSERT к таблице Category из базы данных Northwind следующим образом:

INSERT INTO SERVERB.Northwind.dbo.Categories
(CategoryName, Description)
Values('Bait','Sample category for bait')

Примечание Некоторые провайдеры не поддер­живают SQL­выражения INSERT, UPDATE и DELETE. Однако те, что я упоминаю в примерах, их поддерживают.

Объединение нескольких серверов

Полагаю, что ваши данные распределены между несколькими серверами. Например, все заказы до 1997 г. на одном сервере, а с 1997 г. и до настоящего времени — на другом. Чтобы объединить эти данные, воспользуйтесь в запросе блоком UNION ALL, как показано далее:

SELECT * FROM SERVERB.Northwind.dbo.orders
WHERE OrderDate < '1997-01-01 00:00:00.000'
UNION ALL
SELECT * FROM Northwind..orders
WHERE OrderDate > '1997-01-01 00:00:00.000'
ORDER BY OrderID

При этом запрос будет выполнен параллельно на обоих серверах. Все результаты будут возвращены локальному SQL Server.

Примечание Вы можете посмотреть план выполнения в Query Analyzer через меню Query или нажав CTRL­L.

Обратите внимание на поведение блока ORDER BY в этом запросе. Блок ORDER BY упорядочивает результирующий набор записей целиком, а не только результат с конкретного сервера. Поскольку таблица Orders имеет кластерный индекс на столбце OrderID как на удаленном, так и на локальном сервере. Сортировать данные после того, как они получены от удаленного сервера, не нужно.

Совет Воспользуйтесь утилитой Profiler, чтобы установить, какие запросы были отправлены на локальный и удаленный серверы. Это позволит вам выявить проблемные места.

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

SELECT Orders.OrderID, Employees.LastName, 
Employees.FirstName,
Employees.EmployeeID, Employees.Title, 
Orders.CustomerID, Orders.OrderDate
FROM Orders INNER JOIN
SERVERB.Northwind.dbo.Employees as Employees ON
Orders.EmployeeID = Employees.EmployeeID
ORDER BY Employees.LastName

Я создал псевдоним Employees, соответствующий четырехчастному имени SERVERB.Northwind.dbo.Em­ployees. Это позволяет сократить количество набираемого текста в дальнейшем, а также помогает визуализировать таблицу Employees как локальную, хотя она и расположена физически на другом сервере. На этот раз я применил блок ORDER BY для сортировки по столбцу LastName таблицы Employees. Это создает гораздо большую нагрузку на локальном сервере, поскольку столбец LastName не является кластерным индексом. В этом случае данные возвращаются на локальный сервер для сортировки.

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

Выполнение хранимых процедур на связанных серверах

Функциональность связанных серверов не ограничена только произвольными запросами. Вы можете запускать хранимые процедуры и работать с представлениями на удаленных серверах. Хранимую процедуру выполняйте как обычно, только перед ее названием укажите четырехчастное имя. Например, следующий код запускает процедуру CustOrderHist в базе данных Northwind и передает Quick в качестве параметра:

EXEC SERVERB.Northwind.dbo.CustOrderHist 
@CustomerID='Quick'

Перед выполнением хранимых процедур убедитесь, что для связанного сервера определены параметры RPC. Чтобы установить параметры RPC и RPC Out в true, воспользуйтесь следующими командами в Query Analyzer:

sp_serveroption 'SERVERB', 'rpc', 'true'
sp_serveroption 'SERVERB', 'rpc out', 'true'

Получение подробных сообщений об ошибках

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

DBCC TRACEON(7300)

Применение openquery() и openrowset()

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

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

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

SELECT * FROM openquery (SERVERB, 'SELECT * FROM Orders')

Следующий код демонстрирует, как используется функция openquery() для запроса, который обсуждался выше:

SET QUOTED_IDENTIFIER OFF
SELECT * FROM openquery
(SERVERB, "SELECT * FROM Orders
WHERE OrderDate < '1997-01-01 00:00:00.000'")

Обратите внимание, что первая строка выключает идентификаторы в кавычках. Я делаю это потому, что использую символьные данные в блоке WHERE, которые требуют кавычек. Если я заключу дату в одиночные кавычки, это разобьет функцию openquery(), которая также применяет одиночные кавычки. Решить проблему можно, заключив выражение SELECT в двойные кавычки, а символьные данные — в одиночные. Поскольку выражение SELECT окружают двойные кавычки, функция openquery() не будет разбита одиночными.

Внимание! В конце этого запроса стоит добавить блок SET QUOTED_IDENTIFIER ON и с его помощью убедиться, что этот параметр снова установлен в значение Query Analyzer по умолчанию.

Функция openrowset() позволяет создавать связанный сервер по требованию. Это полезно, если до начала выполнения приложения вы не знаете, куда будете подключаться. Тем не менее я обычно рекомендую этого избегать, если возможно, поскольку потребуется дополнительный шаг (и более сложный код).

Применяйте openrowset() с помощью следующего (возможно, более пугающего) синтаксиса:

openrowset ( '<provider name>'
  , { '<data source>' ;  
'<login name>' ; '<password>'
    | '<provider_string>' }
  , { [ <catalog>. ] [ <schema>. ] <object>
    | '<query>' })

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

SET QUOTED_IDENTIFIER OFF
SELECT * FROM openrowset
('SQLOLEDB','SQLCENTRAL';'sa';'password',
"SELECT * FROM Northwind.dbo.Orders WHERE
OrderDate < '1997-01-01 00:00:00.000'")

Поскольку в блоке WHERE применяются символьные данные, я временно выключаю взятые в кавычки идентификаторы. В противном случае SQL Server опре­делит, что все содержимое столбца является именем объекта, и произойдет следующая ошибка:

Server: Msg 7314, Level 16, State 1, Line 2
OLE DB provider 'SQLOLEDB'  does not contain table 'SELECT * FROM Northwind.dbo.Orders WHERE OrderDate < '1997-01-01 00:00:00.000''.
The table either does not exist or the current user does not have permissions on that table.

Внимание! Воспользовавшись утилитой Profiler для трассировки локального сервера, можно увидеть пароль удаленного сервера при вызове функции openrowset().

Объединение таблиц с помощью функции openquery()

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

SET QUOTED_IDENTIFIER OFF
SELECT * FROM openquery
(SERVERB, "SELECT * FROM Orders
WHERE OrderDate < '1997-01-01 00:00:00.000'")
UNION ALL
SELECT * FROM Northwind..orders
WHERE OrderDate > '1997-01-01 00:00:00.000'
ORDER BY OrderID

Можно объединять таблицы и с помощью стандарт­ного JOIN:

SET QUOTED_IDENTIFIER OFF
SELECT Orders.OrderID, Employees.LastName,
Employees.FirstName,

Employees.EmployeeID, Employees.Title,
Orders.CustomerID, Orders.OrderDate
FROM Orders INNER JOIN openquery
(SERVERB, "SELECT EmployeeID, LastName,
 FirstName,

Title FROM Employees")
 as Employees ON Orders.EmployeeID = Employees.EmployeeID
Order by Employees.LastName

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

Применение openquery()

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

Чтобы выполнить хранимую процедуру посред­ством openquery() и openrowset(), воспользуйтесь следующей командой:

SELECT * FROM openquery (SERVERB, "CustOrderHist @CustomerID='Quick'")

Настройка и поддержка связанных серверов

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

Сопоставление запросов с типами серверов

SQL Server стремится позволить удаленному серверу выполнить как можно большую часть обработки запроса. Однако этот подход работает не всегда. Например, текстовый файл, на который настроен ваш связанный сервер, не может обрабатывать блоки WHERE и ORDER BY удаленно, так как он не структурирован и на том конце нет сервера для удаленной фильтрации запроса. Вместо этого SQL Server извлекает набор данных целиком, а потом выполняет соответствующий реляционный запрос.

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

При получении запроса SQL Server опрашивает провайдер OLE DB, чтобы выяснить, не содержит ли посылаемый вами запрос функций, не разрешенных провайдером OLE DB. Когда SQL Server выясняет, что выполняемая вами команда разрешена в удаленной системе, он определяет, какая часть запроса может быть делегирована для выполнения удаленной системе. Кое­какой синтаксис всегда возвращается назад и проверяется локально независимо от типа базы данных удаленного сервера. Следующие элементы никогда не делегируются:

•     запросы, использующие типы данных bit, time­stamp и uniqueidentifier;

•     блоки TOP;

•     операции обновления, вставки и удаления;

•     операции преобразования данных.

Следующие действия могут выполняться удаленно, если удаленным сервером является SQL Server:

•     такие блоки, как CUBES, OUTER JOINS и ROLLUP;

•     операции над битами;

•     запросы, содержащие Like;

•     строковые и математические функции.

Провайдеры, поддерживающие SQL­92, также позволяют делегировать блоки UNION и UNION ALL. Другие провайдеры OLE DB могут поддерживать такие выражения, как DISTINCT. Если провайдер может выполнить операцию, она делегируется. Если нет — результаты окончательно обрабатываются локально.

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

Просмотр метаданных связанного сервера

Порой довольно сложно решать проблемы со связанными серверами, поскольку вдобавок к локальному SQL Server вы имеете дело с несколькими гетерогенными системами. Поэтому Microsoft предоставила несколько хранимых процедур, которые помогут вам при отладке. Хранимая процедура sp_linkedservers, не требующая параметров, выводит список всех связанных серверов на сервере, к которому вы подключены, а также их основные свойства (свойства со вкладки General диалогового окна Linked Server Properties в Enterprise Manager).

Хранимая процедура sp_helpserver возвращает параметры, сконфигурированные на вкладке Server Options диалогового окна Linked Server Properties. Эта процедура принимает необязательный параметр — имя связанного сервера, но вы можете запустить ее и без параметров. При этом будет возвращена информация по всем связанным серверам.

Просмотр метаданных уровня каталога

Чтобы установить, какие каталоги существуют на удаленном сервере, запустите системную хранимую процедуру sp_catalogs с обязательным параметром, представляющим собой имя связанного сервера, как показано здесь:

EXEC sp_catalogs
@server_name ='SERVERB'

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

Просмотр метаданных уровня таблицы

Одной из самых важных отладочных хранимых процедур является системная хранимая процедура sp_tables_ex. Она показывает таблицы, существующие на удаленном сервере. Что более важно, она выводит имена таблиц, которые необходимы удаленному серверу при обращении к таблицам. Единственный параметр, который нужно указать, — это @table_server, представляющий собой имя связанного сервера. Чтобы запустить хранимую процедуру, воспользуйтесь следующей командой:

EXEC sp_tables_ex
  @table_server = 'SERVERB'

Вы получите следующие результаты:

•     имя каталога;

•     имя схемы и имя владельца;

•     имя таблицы или представления;

•     тип таблицы (системная таблица, таблица или представление).

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

EXEC sp_tables_ex
  @table_server = 'SERVERB',
  @table_catalog='Northwind',
  @table_schema='dbo',
  @table_name='Suppliers'

Просмотр метаданных уровня столбца

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

EXEC sp_columns_ex
  @table_server = 'SERVERB'

Вы получите большое количество ценных данных о столбцах в удаленной системе:

•     имя каталога;

•     схема или владелец;

•     имя таблицы или представления;

•     имена столбцов;

•     тип данных;

•     размер и точность столбца, поддерживает ли столбец значения NULL.

Я очень рекомендую вам не запускать эту хранимую процедуру с единственным параметром @table_server, ведь она вернет все столбцы в каталоге. Ограничьте область значений результатов с помощью любого из следующих необязательных параметров:

EXEC sp_columns_ex
  @table_server = 'SERVERB',
  @table_catalog = 'Northwind',
  @table_name = 'Employees',
  @table_schema = 'dbo',
  @column_name='BirthDate'

Если вы применяете уровни совместимости, то при посылке запроса из базы данных с уровнем совместимости менее 70 можете получить следующую ошибку:

Server: Msg 155, Level 15, State 1, Line 1
'SERVERB' is not a recognized
OPTIMIZER LOCK HINTS option.

Методика индексирования полей с низкой селективностью в SQL Server

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

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

SELECT col1, col2, col3 FROM aLargeTable WHERE flag = 1

На первый взгляд, решение этой проблемы кажется довольно простым. Однако есть вероятность, что подозрительное поле flag содержит только два значения и имеет тип BIT или, что означает то же самое, является полем другого типа и содержит только несколько различных значений. Следовательно, индексация этого поля обычным способом не годится, потому что индекс будет недостаточно селективным для того, чтобы дать преимущество движку базы данных для выборки записей, — скорее всего, оптимизатор даже не будет его использовать. Между прочим, это более корректное поведение, потому что применение индекса для поиска нескольких уникальных записей будет более медленным, чем простое сканирование таблицы.

Так что же делать? Есть несколько путей решения, однако не все из них помогут. Следует проанализировать все возможные способы и их влияние на производительность. Воспользуемся при этом SQL Server 2005.

CHECKDB: проверка согласованности базы данных

Зададимся проблемой: CHECKDB нуждается в непротиворечивом представлении базы данных. Почему? Обычно эту команду запускают на рабочей БД со всеми возможными последствиями. Необходимо читать и анализировать всю базу данных, но это нельзя сделать мгновенно, поэтому следует предпринять меры для обеспечения транзакционной непротиворечивости.

Стратегия резервного копирования для SQL Server

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

Типы повреждений

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

Требования к резервному копированию

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

Для определения требований к резервному копированию рассмотрите следующие вопросы:

•     Как ваше приложение отнесется к потере данных?

•     Как часто обновляются данные?

•     Как долго ваше приложение не сможет работать, пока восстанавливаются данные?

•     Насколько велика база данных?

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

Типы резервного копирования

Microsoft SQL Server поддерживает четыре типа резерв­ного копирования: полное (Full), дифференциальное (Differential), журнала транзакций (Transaction log) и файлов/файловых групп (File/Filegroup).

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

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

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

Стратегии резервного копирования

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

Выбор базы данных для высокой доступности: анализ SQL Server и Oracle. Часть 1

В SQL Server 2005 была представлена функциональность, удовлетворяющая потребности пользователей в высокой доступности, и за гораздо меньшую цену, чем Oracle 10g. SQL Server 2005 включает все основные особенности, такие как поддержка Microsoft Clustering Services, зеркальное отображение базы данных, снимки баз данных, доставка журналов и репликация как в SQL Server 2005 Standard Edition, так и в SQL Server 2005 Enterprise Edition, без увеличения цены.

Технология Real Application Clusters (RAC) в Oracle используется для создания конфигураций, обеспечивающих высокую доступность. Однако поддержка RAC включена только в Oracle 10g Enterprise Edition — ее нет в Oracle 10g Standard Edition. Хотя в RAC есть функ­циональность автоматического перехода на другой ресурс (failover), она не может достичь скорости переключения на другой ресурс в 5 секунд, которую обеспечивает зеркальное отображение базы данных в SQL Server 2005. Кроме того, инструменты Flashback и Data Guard в Oracle 10g недоступны в Oracle 10g Standard Edition; чтобы получить их, заказчики сначала должны купить более дорогую редакцию Oracle — Oracle 10g Enterprise Edition.

SQL Server 2005 Enterprise Edition также предоставляет возможность расширить доступность с помощью секционирования данных между множеством серверов. Для добавления такой функциональности в Oracle 10g необходимо приобрести опциональный продукт Oracle Partitioning. SQL Server 2005 удовлетворяет потребности заказчиков в высокой доступности за гораздо меньшую цену, чем Oracle 10g.

Уверенность в постоянной доступности вычислительных ресурсов на предприятии является основной целью современного администратора баз данных (database administrator — DBA). Вся вычислительная мощность компьютеров на Земле и безопасное/защищенное программирование не имеют смысла, если пользователи не могут получить доступ к ресурсам, необходимым для выполнения их должностных обязанностей. Если база данных и серверы, поддерживающие приложение, недоступны, это может обернуться для организации как материальными убытками, так и потерей репутации.

В зависимости от рода деятельности организации и типа приложения затраты из­за недоступности служб могут быть огромными. Исследование от Forrester Research показало, что одночасовой простой компании eTrade, онлайн­брокера, стоил ей 8 миллио­нов долларов, а 10­часовой простой DELL — 83 миллиона долларов, в то время как 33­часовой простой Intel привел к потерям в 275 миллионов долларов. Эти цифры отражают только финансовые убытки и не включают некоторые другие менее очевидные потери, такие как снижение удовлетворенности клиентов или испорченная репутация компании.

Для критически важных приложений поддерживающие их база данных и серверы должны быть доступны, когда эти приложения необходимы пользователям. Требования к достижению нужных уровней доступности на предприятии сегодня распространяются дальше простой защиты данных, которую обеспечивают традиционные технологии резервного копирования и восстановления данных. Современные приложения предприятия требуют больших окон доступности, чем когда­либо раньше, и многим организациям необходима доступность 24 часа в день, 7 дней в неделю, 365 дней в году. Создание высокодоступной среды для непрерывности бизнеса является сложной задачей, потому что она охватывает большое количество различных областей предприятия. На этот процесс также влияет множество факторов, включая технологические задачи и возможности, такие как человеческие и организаторские факторы, которые находятся вне самих технологий. В этой статье мы сравним технологии высокой доступности в SQL Server 2005 и Oracle 10g. С помощью этой информации пользователи смогут оценить различные возможности этих двух систем и выбрать базу данных, которая наилучшим образом удовлетворяет их по­требностям.

Значение высокой доступности и пяти девяток

Доступность определяется как время, в течение которого система или ресурс доступны для использования. Значение высокой доступности обычно измеряется согласно процентному значению абсолютной доступности, где 100% означают, что ресурс доступен постоянно. Однако достигнуть этого показателя очень сложно. Вместо этого самое близкое практическое значение очень высокой доступности равно пяти девяткам, или 99,999%. В математическом выражении доступность можно обозначить так:

Процентное значение доступности = ((общее затраченное время – общее время простоев)/общее затраченное время),

где процентное значение доступности системы равно разнице общего затраченного времени и общего времени, когда система была недоступна, деленной на общее затраченное время. В каждом году примерно 8760 часов (24 часа в день, 365 дней в году) доступного времени работоспособности системы. Все 8760 часов можно представить как 100% времени в году, когда система доступна. Однако из­за необходимости выполнения регулярных операций поддержки системы, а также из­за других незапланированных событий, обеспечение 8760 часов работоспособности обычно является невозможным. Например, у системы обычно есть один день (8 часов) в месяц, на который она отключается для запланированных операций обслуживания, чтобы персонал отдела информационных технологий мог произвести обновление аппаратного обеспечения, обновить систему с помощью патчей или выполнить другие операции поддержки. В этом случае процентное значение доступности системы можно выразить следующей формулой:

98,9 = ((8760 — (8´12)/8760)

Другими словами, один день простоя в месяц приводит к процентному значению доступности, равному 98,9%. Следующая формула показывает, как рассчитать количество девяток в доступности системы. Количество девяток в 99,9% равно трем, в 99,99% — четырем и т. д.

Как вы могли заметить, один день простоя в месяц приводит к процентному значению доступности, равному 98,9%. Один день в месяц — это не очень хорошо, и для некоторых компаний этого будет недостаточно. В табл. 1 показано количество времени простоя вместе с увеличением уровня доступности.

Достигнуть еще одной девятки доступности можно с помощью 15 минут в день или 92 (3 дня, 18 часов, 20 минут) часов простоев в год. Однако, как вы видите, добрать до более высокого уровня доступности с большим количеством девяток трудно. На самом высоком уровне (пять девяток) время простоя должно быть меньше 0,09 часа или около 5 минут в год. С сегодняшними платформами баз данных это возможно, но одних технологий недостаточно. Самых высоких уровней доступности можно достичь с помощью объединений людей, процессов и технологических факторов.

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

Обновления аппаратного обеспечения и поддержка

Поддержка в Microsoft Windows Server 2003 горячей замены оперативной памяти и RAID­дисков предназначена для обычного сценария обновления: добавление оперативной памяти и дискового пространства к системе. С аппаратным обеспечением, поддерживающим все эти особенности, вы можете в процессе работы добавлять оперативную память и RAID­диски без влияния на доступность. Но даже с учетом этих особенностей иногда необходимо осуществить поддержку. Например, событие в системном журнале может указывать на неверное срабатывание системного компонента. Также вам может понадобиться применить служебные обновления для операционной системы или для приложений, которые требуют переза­грузки. В среде с одним сервером такие действия приведут к запланированному простою в работе системы. Запланированные простои менее катастрофичны для непрерывности операций, чем незапланированные, потому что они могут проводиться в то время, когда будут иметь наименьшее влияние.

Однако даже запланированные простои могут быть слишком длительными для организаций, требующих максимального уровня доступности. Чтобы обеспечить техническую поддержку и справиться с простоями в работе, все имеющиеся на сегодняшний день платформы баз данных уровня предприятия поддерживают кластеризацию с множеством серверов и другие особенности доступности, которые позволяют персоналу отдела информационных технологий выполнять постоянные обновления. Системы Microsoft Windows Clustering Services и Oracle RAC дают возможность выполнять постоянные обновления, которые позволяют вам вручную отключать одну систему в кластере или группу систем для выполнения операций поддержки. Например, если у вас есть приложение, которое требует доступно­сти 24 часа в сутки и 7 дней в неделю, вы можете реализовать его на платформе базы данных с помощью одной из перечисленных технологий кластеризации с множеством серверов или посредством других доступных технологий. Таким образом, когда вам понадобится выполнить какие­либо операции поддержки, вы вручную осуществляете переключение на другой ресурс, чтобы отключить узел, на котором необходимо их выполнить. Оставшийся узел (узлы) кластера или резервный сервер примут рабочую нагрузку на себя во время недоступности узла, на котором производятся операции поддержки. Таким образом, доступность приложения остается в сохранности. Когда процедуры поддержки завершатся, восстановите узел в кластере и включите его в работу. Вы можете повторять этот процесс для других узлов кластера по необходимости. Такая возможность, позволяющая проводить постоянные обновления, устраняет запланированные простои, связанные с операциями поддержки.

Поддержка базы данных

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

Чтобы упростить поддержку сервера и базы данных, SQL Server 2005 позволяет динамически изменять конфигурацию большинства системных параметров SQL Server. В табл. 2 показаны параметры сервера, которые могут быть изменены.

SQL Server 2005 представляет команду дефрагментации индекса, которая позволяет проводить дефрагментацию кластерных и некластерных индексов таблиц и представлений в оперативном режиме. Команда DBCC INDEXDEFRAG не накладывает блокировки на долгое время и, таким образом, не блокирует любые выполняющиеся запросы или обновления. SQL Server 2005 и Oracle 10g поддерживают оперативные операции с индексами, повышающими доступность данных, время отклика, использование дискового пространства и производительность базы данных. Индексы могут быть дефрагментированы, добавлены или перестроены во время обновления или чтения таблицы.

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

Незапланированные простои

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

Решения высокой доступности при восстановлении баз данных

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

SQL Server 2005: резервное копирование и транзакционное восстановление на определенный момент времени

Важнейшим компонентом высокой доступности является надежный план резервного копирования и восстановления данных. Разные модели в SQL Server 2005 поддерживают баланс между затратами на ведение журнала и полным восстановлением данных. SQL Server 2005 предоставляет три модели восстановления: простую, полную и Bulk­Logged.

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

•     Модель полного восстановления (Full) поддерживает баланс с другой стороны, записывая в журнал все обновления данных. С ее помощью можно восстановить все данные до момента сбоя. По умолчанию SQL Server использует данную модель.

•     Модель восстановления Bulk­Logged находится между двумя остальными, записывая в журнал все транзакции, кроме операций с большими количествами данных, например массового копирования и SELECT INTO. Для операций массивной модификации журналируются только операции выделения пространства под данные. Другими словами, эта модель может восстанавливать данные к по­следнему резервному копированию базы данных или журнала.

После выбора модели восстановления необходимо определить план резервного копирования. Резервные копии могут сохраняться на дисках, кассетах или с помощью других средств. Выполнение резервного копирования на диск является самым быстрым механизмом. Для защиты от сбоев в работе дисков резерв­ные копии должны всегда храниться на отдельных дисках и желательно на других контроллерах. SQL Ser­ver поддерживает три основных типа резервного копирования базы данных: полное, дифференцированное и копирование журнала.

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

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

•     Резервное копирование журнала. Этот тип резервного копирования выполняет только копирование журнала транзакций. Резервные копии журнала транзакций могут быть применены после восстановления последней дифференцированной резерв­ной копии.

Транзакционное восстановление на определенный момент времени позволяет восстанавливать всю базу данных на любое заданное время. Журнал транзакций SQL Server 2005 — это последовательная запись всех изменений, которые были выполнены в базе данных после последнего резервного копирования журнала транзакций. Используя резервные копии журналов транзакций, вы можете восстановить базу данных SQL Server на любой заданный момент времени. Например, если ошибка в приложении возникла в 04:00 и привела к повреждению данных, вы можете использовать резервную копию журнала транзакций SQL Server 2005 для восстановления данных на 03:59 — прямо перед повреждением.

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

В дополнение к этим стандартным опциям резерв­ного копирования SQL Server 2005 также обеспечивает поддержку тонкого, постраничного восстановления, где вы можете восстанавливать страницы или группы страниц.

SQL Server 2005: доставка журнала с задержкой

Доставка журнала может быть настроена для того, чтобы создавалось «временное окно», позволяющее восстанавливать данные в случае повреждения. Она является технологией доступности базы данных, которая передает журналы транзакций от одного сервера баз данных одному или нескольким резервным серверам. Эти журналы транзакций в дальнейшем могут быть применены на резервном сервере в случае отказа работы основного сервера или базы данных. Резервные копии журнала транзакций основного сервера могут быть отложены на определенный период времени перед отправкой на вторичный сервер. Например, вместо немедленной записи журналов транзакций на вторичном сервере доставка журнала может быть настроена для записи на вторичный сервер каждые 5 минут. В случае возникновения ошибки в 5­минутном окне журнал транзакций вторичного сервера может быть использован для восстановления данных по состоянию на 5 минут раньше.

SQL Server 2005: восстановление файловой группы

Восстановление на определенный момент времени и восстановление доставки журнала доступны в SQL Server 2005. Резервные копии журнала транзакций могут быть применены для восстановления данных на определенный момент времени.

Новые особенности SQL Server 2005 позволяют просто восстанавливать поврежденные объекты, а также выбранные файловые группы базы данных. В SQL Server 2000 единицей доступности является БД. В SQL Server 2005 единицей доступности является файловая группа. Такой подход увеличивает доступность, потому что недоступными являются только те данные, которые восстанавливаются; оставшаяся часть базы данных, содержащаяся в других файловых группах, остается доступной. SQL Server 2005 позволяет восстанавливать индивидуальные файловые группы за один раз или даже индивидуальные страницы или группы страниц при условии готовности первичной (Primary) файловой группы.

SQL Server 2005: быстрое восстановление

Как и FastStart Fault Recovery в Oracle, особенность Fast Recovery в SQL Server 2005 повышает доступность данных, позволяя пользователям повторно уста­новить соединение с базой данных, находящейся в процессе восстановления, как только будет выполнено восстановление журнала транзакций. Более ранние версии SQL Server заставляли пользователя ждать, пока не будут откачены незавершенные транзакции, даже если доступ к этим областям базы данных не нужен.

SQL Server 2005: снимки баз данных

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

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

Oracle 10g: Recovery Manager (RMAN)

Oracle 10g включает инструмент под названием Recovery Manager (RMAN), который управляет процессами создания резервных копий и их восстановления. RMAN состоит из исполняемых функций RMAN, базы данных, резервное копирование которой необходимо выполнить, и опционального каталога восстановления. Если каталог восстановления не задан, детали резервного копирования хранятся в управляющем файле в БД. Некоторые особенности Recovery Manager могут использоваться для восстановления поврежденных данных или в случае нежелательных изменений. Контрольный файл содержит информацию о файле данных и файлах архивного журнала со времени создания файла данных до момента его восстановления.

Стандартная резервная копия RMAN содержит резервные элементы, которые состоят из блоков данных определенного файла данных. Блоки данных хранятся в специальном сжатом формате. Когда файл данных требует восстановления, нужно пересоздать его целиком из блоков резервных элементов. В Oracle 10g копии­образы могут быть созданы на уровне базы данных, табличного пространства или файла данных. Копия­образ файла данных быстрее восстанавливается, потому что его текущая структура уже существует. Incrementally Updated Backups (последовательно обновляемые резервные копии), особенность RMAN, позволяет применять последовательные изменения базы данных к резервным копиям образов файла данных, чтобы выполнить транзакции до определенного момента времени. Периодическое освежение копий­образов файла данных с помощью последовательных обновлений делает их данные более совместимыми с текущим состоянием. Это сокращает время восстановления данных.

Change Tracking — это опциональная особенность Oracle 10g, повышающая производительность по­следовательных обновлений. В предыдущих версиях Oracle все блоки в файлах данных должны были быть просканированы для поиска изменений со времени последнего обновления. С включенной опцией Change Tracking полностью сканируются только блоки первого последовательного обновления, в то время как идентификаторы любых изменившихся блоков записываются в файл Change Tracking. Другие последовательные резервные копирования сканируют файл Change Tracking для определения, есть ли изменившиеся блоки, которые необходимо записать в резервную копию.

Oracle 10g — Flashback

Flashback в Oracle 10g обеспечивает функциональность, очень похожую на снимки баз данных SQL Server 2005. База данных Flashback позволяет восстановить БД на определенный момент времени, используя Flash Recovery Area вместо стандартных средств резервного копирования. Flashback лучше всего подходит для восстановления данных простых таблиц и записей, которые были повреждены, в отличие от RMAN, который пригодится для восстановления больших объемов данных. Чтобы использовать эту функциональность, администратор базы данных должен настроить Flash Recovery Area, которая включает журналы базы данных Flashback, архивные журналы повторного выполнения и резервные копии RMAN. Копия изменений блока записывается в журналы Flashback, и эти изменения могут быть восстановлены в случае повреждения данных из­за ошибки пользователя или приложения. Flashback включает специальные SQL команды, которые применяются для запрашивания и восстановления данных из Flash Recovery Area, так что пользователю понадобятся соответствующие привилегии для доступа к этим объектам.

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

Возможности Flashback Table, Database и Trans­ac­tion Query доступны только в Oracle Enterprise Edition.

Решения высокой доступности при сбое в работе сервера

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

•     сбой в работе аппаратного обеспечения (процессор, оперативная память, хранилище, ввод­вывод или энергообеспечение);

•     сбой в работе операционной системы или драйвера устройства;

•     сбой в работе сервера баз данных.

Первым шагом в защите от сбоев в работе аппаратного обеспечения должны быть инвестиции в аппаратную платформу, которая обеспечивает избыточность ключевых компонентов. Например, большинство серверов, которые предлагают поставщики аппаратных платформ для первого слоя на настоящий момент, поддерживают особенности, обеспечивающие высокую доступность, такие как резервные системы энергоснабжения, встроенные системы бесперебойного электропитания (UPS, Uninterruptible Power Supply), а также модули оперативной памяти и диски RAID с «горячей» заменой.

Со стороны программного обеспечения самым важным в достижении высокой доступности является своевременное обновление вашей операционной системы, драйверов устройств и ПО самыми новыми служебными пакетами обновления. Поддержание такого состояния гарантирует, что ваша система будет иметь самые новые обновления программного обеспечения и обновления системы безопасности. Microsoft предлагает несколько технологий, предназначенных для выпуска обновлений системы. System Management Server (SMS) обеспечивает возможности инвентаризации и обновления ПО на уровне предприятия. Средним предприятиям службы Windows Server Update Ser­vi­ces (WSUS) позволяют распространять обновления Microsoft Windows и Microsoft Windows Server по всей организации. Windows Update обеспечивает обновления системы для малых предприятий.

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

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

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

N­узловая кластеризация в SQL Server 2005

Используя преимущества улучшенной поддержки кластеризации в Windows Server 2003, SQL Server 2005 поддерживает кластеры, содержащие до восьми узлов на Windows Server 2003 Datacenter Edition, до четырех узлов на Windows Server 2003 Enterprise Edition и Windows 2000 Datacenter Server и до двух узлов на Windows 2000 Advanced Server. Процесс установки и средства управления включают поддержку кластеризации.

Технология Microsoft Windows Clustering Services является важной технологией для защиты платформ баз данных от сбоев в работе сервера. Windows Clus­te­ring Services доступна для всех приложений баз данных уровня предприятия, включая SQL Server, Oracle и DB2. Разные версии операционной системы Windows Ser­ver имеют разные возможности в количестве поддерживаемых узлов. В табл. 3 представлены основные возможности кластеризации в разных версиях Win­dows 2000 Server и Windows Server 2003.

Windows 2000 Server и Windows Server 2003 Stan­dard Edition не поддерживают переход на другой ресурс. Windows 2000 Advanced Server поддерживает кластеры, содержащие до двух узлов, Windows Data­cen­ter Server 2000 и Windows 2003 — кластеры, насчитывающие до четырех узлов, а Windows Server 2003 Data­­center Edition — кластеры до восьми узлов. Количество поддерживаемых узлов зависит от операционной системы.

В Windows Clustering каждый физический сервер в кластере называется узлом. Узлы работают вместе и формируют кластер. Все они находятся в состоянии постоянной передачи информации. Если один из узлов в кластере становится недоступным, другой автоматически примет его рабочую нагрузку и будет предоставлять пользователям те же услуги, что и тот, в работе которого произошел сбой. Этот процесс называется переходом на другой ресурс (failover). В отличие от специализированных отказоустойчивых аппаратных решений, предлагаемых другими компаниями, которые могут предложить непрерывность предоставления служб, процесс перехода на другой ресурс для кластера Windows требует небольшого количества времени, около 20 секунд, в зависимости от используемого аппаратного обеспечения. Также база данных на узле, в работе которого произошел сбой, должна быть восстановлена для согланованности транзакций. Продолжительность этого периода восстановления зависит в основном от активности базы данных на момент сбоя и от типа используемого аппаратного обеспечения. Клиенты, соединенные с узлом, в работе которого произошел сбой, отсоединяются. Пытаясь повторно соединиться, они могут получить доступ к ресурсам кластера с резервного узла. Windows Clustering предлагает преимущества, описанные ниже.

•     Автоматический переход на другой ресурс. Когда обнаруживается сбой, кластер автоматически переносит рабочую нагрузку с основного узла на резервный узел.

•     Прозрачность для клиентов. После выполнения перехода на другой ресурс клиенты могут повторно соединиться с кластером, используя то же виртуальное имя или IP­адрес.

•    Целостность транзакций. Все завершенные транзакции сохраняются и становятся доступными после завершения процесса перехода на другой ресурс.

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

Основная схема Windows Clustering Services показана на рис. 2.

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

•     Жесткий диск для операционной системы Win­dows Server. Этот диск не является диском общего доступа и не присоединен к контроллеру, который используется для соединения с хранилищем общего доступа. Диск использует собственный контроллер и должен быть зеркалирован для повышения уровня доступности.

•     Адаптер SCSI или Fibre Channel, который соединяется с хранилищем кластера общего доступа.

•     Две сетевые карты (network interface cards — NIC). Одна используется для соединения с узла кластера с внешней сетью, вторая — для частной сети кластера, которая поддерживает «сердцебиение» кластера — сигнал, указывающий, что узел доступен.

Так как узлы в кластере задействуют подсистему хранилища общего доступа, они в основном должны быть в относительной близости друг от друга. Расстояние между узлами зависит от соединения, которое используют узлы для подсистемы хранилища. Кластеры, использующие общее SCSI­соединение, должны находиться относительно близко (в нескольких метрах), в то время как узлы, соединенные с помощью Fibre Channel, могут находиться на расстоянии в несколько миль. Такое решение сокращает число простоев из­за сбоя в работе сервера, но оно все еще уязвимо для событий, имеющих место в определенной области. Геокластеры (кластеры, расположенные в нескольких географически распределенных областях) решают эту проблему с помощью географического разделения узлов кластера. Это достигается с помощью синхронного зеркалирования диска, подключенного в общей шине. Кластер не знает о расстоянии между его узлами, так что эти решения должны быть реализованы на уровне хранилища и сетевом уровне инфраструктуры предприятия.

Чтобы применять решение Windows Clustering, необходима серверная система, сертифицированная Microsoft для использования с программным обеспечением Windows Clustering. На сайте Windows HCL Home (http://www.microsoft.com/whdc/hcl/default.mspx) вы можете найти список поддерживаемых аппаратных платформ. Важно удостовериться, что вы используете сертифицированную кластерную систему, а не собираете вашу собственную систему по частям, т. к. поставщики аппаратного обеспечения подвергают свои системы нагрузочным тестам, чтобы удовлетворить по­требности, определенные Microsoft, и сертифицировать эти системы. «Доморощенные» кластеры, построенные из частей, вместо сертифицированных в комплексе систем в данном случае для работы не подходят.

Комбинация SQL Server 2005 и Windows Server 2003, использующая конфигурацию N+1 (N активных узлов и 1 резервный узел), обеспечивает очень гибкий и эффективный, с точки зрения затрат, сценарий для обеспечения высокой доступности приложений. Например, с кластером, содержащим восемь узлов в конфигурации N+1, вы можете настроить семь из восьми узлов на предоставление различных служб, в то время как восьмой узел является пассивным и готовым к принятию рабочей нагрузки с любого из семи активных узлов в случае сбоя в работе сервера. На рис. 3 показан кластер, содержащий восемь узлов, семь из которых являются активными, а восьмой находится в режиме ожидания сбоя в работе любого из них.

Табл. 1

Табл. 2

 Табл. 3

(Возврат на основную страницу)