|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #03/98
|
|
Очередная версия SQL Server служит Microsoft своеобразным пропуском в мир приложений баз данных действительно корпоративного масштаба. Однако попасть в этот мир невозможно, не обеспечив адекватной работы СУБД с соответствующего уровня аппаратными платформами - мощными, высоконадежными и масштабируемыми. Для Microsoft, даже свои решения корпоративного уровня стремящейся сделать максимально демократичными, в качестве таких платформ наиболее важны кластеры, построенные из обыкновенных массовых ПК-серверов и не требующие для своего объединения каких-либо специальных средств. Такие кластеры производят не только ведущие мировые производители ПК, но даже и отдельные российские сборщики.
В этой статье рассматривается текущее состояние и ближайшие перспективы (в значительной мере связанные с выходом в следующем году операционной системы Windows 2000) кластерных технологий Microsoft, а также ╚распределение ролей╩ между Cluster Server и SQL Server.
Во второй половине 1995 года Microsoft сообщила о намерении совместно с рядом производителей аппаратного и программного обеспечения обеспечить кластеризацию для сетевой операционной системы Windows NT Server и интегрированного семейства серверных приложений Microsoft BackOffice. Как известно, технология кластеризации позволяет заказчикам связывать группу серверов, чтобы увеличить уровень готовности приложений и данных, управляемость системой и производительность вычислительной системы в целом. Отличительной чертой подхода к кластеризации, который исповедует Microsoft, является отсутствие необходимости в использовании для связи серверов специального аппаратного обеспечения.
Помимо исключительной ╚демократичности╩, каких-либо особенных открытий в предложенном корпорацией подходе к кластеризации нет - в конце концов, его вдохновителями были те же люди, которые стояли у колыбели хрестоматийных VAX-кластеров, прежде всего Джим Грей и Гордон Белл, перешедшие летом 1995 года из корпорации Digital Equipment в Microsoft. Грей сейчас и является главным архитектором масштабируемых решений Microsoft (грандиозная их демонстрация - амбициозный проект TerraServer).
Microsoft Cluster Server (MSCS), известный в ходе разработки как Wolfpack, в настоящее время входит в состав Microsoft Windows NT Server, Enterprise Edition.
В своей работе над технологиями кластеризации Microsoft тесно сотрудничает с рядом ведущих производителей. Совместно с ними Microsoft создает стандартный набор продуктов и услуг, которые используют преимущества, обеспечиваемые кластеризованными системами, в частности касающиеся упрощения управления и более экономичной реализацией проектов.
Кластер - это группа независимых систем, работающих вместе, как единая система. Клиент взаимодействует с кластером так, как будто кластер является единым сервером, даже если он физически представляет собой объединение нескольких серверов. Кластерные конфигурации используются для обеспечения высокой готовности, упрощения управления и увеличения масштабируемости.
Программное обеспечение MSCS включает в себя API-интерфейс, который позволяет приложениям использовать возможности Windows NT Server в кластерной среде. Как и другие производители, Microsoft намерена с помощью этого интерфейса добавлять возможности, ориентированные на использование кластеров, в будущие версии своих серверных приложений, в частности продукты семейства BackOffice. Кластеризация реализуется поэтапно. На первом этапе обеспечивается поддержка восстановления после сбоев для кластеров, состоящих из двух узлов. В случае сбоя на основном сервере приложения будут переноситься на второй сервер по желанию администратора или автоматически.
На втором этапе предполагается реализовать поддержку кластеров, содержащих до 16 узлов для параллельного исполнения приложений, которые используют эти кластеры для увеличения объемов вычислений.
Microsoft SQL Server - пример приложения, созданного на базе Microsoft Cluster Server, которое позволяет воспользоваться преимуществами MSCS для обеспечения более высокой масштабируемости и готовности.
Реализация кластерных продуктов SQL Server распадается на два этапа.
Первый этап посвящен реализации Symmetric Virtual Server, который поддерживает кластер, состоящий из двух узлов и ориентированный на работу с несколькими экземплярами SQL Server. В случае возникновения сбоя на одном узле или его отключения, все приложения SQL Server переносятся на узел, находящийся в рабочем состоянии. На втором этапе Microsoft планирует предложить механизм, позволяющий объединить в кластер больше двух узлов.
SQL Server позволяет запустить несколько экземпляров SQL Server на одном кластере MSCS. В кластере из двух узлов каждый узел может поддерживать ╚половину╩ базы данных и выполнять соответствующую часть работы. В случае сбоя оставшийся узел берет на себя работу, выполнявшуюся первым узлом. При обычных обстоятельствах каждый узел будет обслуживать половину клиентов и управлять базой данных, размещенной на половине всех дисков. SQL Server также содержит программы-эксперты и графические инструментальные средства для автоматической настройки кластера и управления им.
На втором этапе SQL Server сможет использовать массивную параллельную обработку на кластерах, содержащих большое число узлов. Когда общая нагрузка превышает возможности кластера, можно добавлять дополнительные системы, которые позволяют увеличить ресурсы и производительность. Возможность инкрементального наращивания позволяет потребителям увеличивать процессорную мощность по мере необходимости. Данный параллелизм вполне естествен для клиент-серверных приложений, таких как оперативная обработка транзакций, служба файлов, почтовые службы и службы Internet. В этих приложениях данные могут распределяться между различными узлами кластера, а поток работ состоит из нескольких независимых заданий, которые могут выполняться параллельно. При добавлении серверов или дисков хранение данных или потоки работ могут распределяться между несколькими серверами. Аналогично, для пакетов работ, таких как добыча данных и запросы, необходимые для поддержки принятия решения, технология параллельных баз данных позволяет разбить запрос на несколько небольших независимых запросов, которые затем могут выполняться параллельно.
MSCS добавляет в информационные системы, построенные на Windows NT Server, Enterprise Edition следующие возможности.
Высокий уровень готовности. Кластеры ╚скрывают╩ большую часть аппаратных и программных ошибок, перенося задания на работоспособный узел кластера. Часто клиент замечает лишь, что работа была приостановлена на несколько секунд.
Масштабируемость. На первом этапе реализации MSCS поддерживаются кластеры из двух узлов. Второй этап должен завершиться в 1999 году, в результате чего число узлов в кластере может быть увеличено до 16. С помощью реализованных на втором этапе кластеров MSCS и будущих версий SQL Server пользователи смогут наращивать число серверов приложений без ограничений, постепенно добавляя недорогое аппаратное обеспечение высокой готовности.
Управляемость. MSCS и SQL Server предлагают интуитивный графический интерфейс для настройки и управления кластером, в том числе возможность выполнять административную работу на одном из серверов, перенеся его рабочую нагрузку на другие серверы в кластере и обеспечив тем самым непрерывную работу.
Кластерные системы традиционно были дорогими, основанными на внутренних технологиях, что препятствовало широкому распространению подобных решений. Следующие факторы должны изменить ситуацию.
Стандартные API-интерфейсы. Microsoft совместно со своими партнерами работает над созданием отраслевых стандартов на Clustering API. Серверы баз данных, мониторы обработки транзакций и другие программные приложения могут использовать кластерные API-интерфейсы для расширения возможностей кластеров MSCS.
Стандартное оборудование. MSCS использует преимущества современных, широко распространенных платформ ПК, систем хранения SCSI и существующих сетевых технологий. Модель, предлагаемая в Windows NT Server, позволит Microsoft быстро добавлять поддержку специализированной высокопроизводительной кластерной технологии по мере того, как производители аппаратного обеспечения начнут выпуск систем для этого рынка.
Поддержка серверных приложений. Продукты Microsoft BackOffice используют кластерные API-интерфейсы для увеличения масштабируемости и готовности. Microsoft призывает и других производителей к использованию MSCS. Многие из ведущих производителей программного обеспечения переносят свои продукты на кластеры MSCS.
Включение в кластер не отражается на работе пользователей.
MSCS сообщает Windows NT Server следующие качества.
- Готовность. Приложения могут работать непрерывно, даже если один или несколько компонентов системы вышли из строя.
- Управляемость. Система приобретает способность переносить рабочую нагрузку и выгружать серверы для обслуживания, не прерывая работу системы.
- Масштабируемость. Ресурсы сервера могут быть увеличены за счет добавления дополнительных узлов.
MSCS может сократить время простоя системы за счет уменьшения времени, которое требуется на ремонт системы, или за счет увеличения надежности системы.
Кроме того, MSCS позволяет переносить приложения на другие узлы кластера в случае возникновения сбоя на одном или нескольких узлах. После восстановления приложения можно вернуть на их ╚родной╩ сервер.
Тиражирование данных на резервный сервер - подходящее решение, если компании требуется 100-процентная готовность. Тиражирование данных на сервер резервного копирования увеличивает накладные расходы на интерактивную систему и не надежна. Возникает задержка, когда транзакция передана на исходном сервере и не тиражирована на резервный сервер. В результате может пострадать целостность базы данных, восстановить которую очень сложно, а порой просто невозможно.
При организации кластера из двух узлов, один из которых является активным, а другой пассивным, резервный сервер контролирует состояние активного сервера, где могут работать сервер и программы. Резервный сервер остается в пассивном, автономном режиме до тех пор, пока не определит, что на активном сервере возник сбой. Затем он включается в работу и берет на себя управление всей системой. После восстановления работоспособности первого сервера автоматическое возвращение системы в исходную конфигурацию невозможно. Оператор должен вручную переключить системы обратно в исходное состояние. В зависимости от типа системы может понадобиться ее отключение.
В зависимости от реализации пассивный сервер может исполнять приложения, находясь в автономном режиме. В случае возникновения ошибки на активном сервере, работа этих приложений будет прервана.
Для многих приложений высокой готовности архитектура активный - пассивный сервер может вполне подойти. Это решение обеспечивает высокую готовность и целостность данных, хотя и по достаточно высокой цене. Для реализации этого решения специалистами по информационным технологиям придется приобрести два очень дорогих сервера, один из которых практически все время будет простаивать.
В кластере, где оба сервера являются активными, все серверы могут исполнять приложения и действовать как резервные в случае, если на другом возникает сбой, при этом не прерывая работы своих приложений. Они могут также поддерживать автоматическое возвращение к исходной ╚расстановке сил╩ после восстановления работоспособности сервера, на котором произошел сбой, причем кластерное программное обеспечение автоматически перераспределит приложения, которые были прерваны из-за ошибки.
MSCS реализован как кластер в архитектуре активный - активный, так что информационная служба может воспользоваться всеми преимуществами своего аппаратного обеспечения и возможностями, которые предлагает реализация кластерной конфигурации двух активных серверов.
Распределение ролей между SQL Server и MSCS
SQL Server ╚обретает╩ масштабируемость и высокую готовность благодаря MSCS с концепцией Symmetric Virtual Servers (SVS). Начиная с SQL Server 6.5 стало возможным запустить несколько виртуальных серверов на одном узле кластера. Виртуальный сервер представляет собой одну логическую базу данных SQL Server, которая работает на кластере MSCS. Это позволяет каждому узлу действовать как основной сервер для виртуального сервера и выполнять роль вторичного сервера для виртуального сервера, который в свою очередь является основным сервером для других узлов. Определение сервера включает в себя следующее.
- Исполняемые модули на разделяемых дисках, которые содержат все исполняемые модули и все серверные базы данных, в том числе Master, Model, MSDB и TempDB.
- Все пользовательские базы данных и файлы регистрации на разделяемых дисках кластеров.
- Весь серверный контекст хранится в файле регистрации Windows NT.
- Именованные каналы, которые служат в качестве точки соединения с базой данных, и IP-адрес соответствует этому именованному каналу.
- SQL Executive и Distributed Transaction Coordinator виртуального сервера.
SQL Server гарантирует, что все базы данных и файлы регистрации и все, что хранится в главной (Master) базе данных (параметры конфигурации, группы и пользователи, информация о тиражировании и т. д.), остается согласованным между основным и резервным серверами. База данных и файлы регистрации размещаются в одном месте (на разделяемых дисках), вне зависимости от того, работает ли виртуальный сервер на основном или резервном узле. Информация о регистрации сохраняется согласованной между основным и вторичным узлами за счет тиражирования файла регистрации.
Клиенты обращаются именно к SVS, а не к Windows NT Server. Имя SVS реализуется как кластерный ресурс Network Name и связывается с основным или резервным узлом, в зависимости от того, где в данный момент размещен виртуальный сервер. Любой клиент, который использует WINS или службу каталогов для определения местонахождения сервера, будет автоматически отслеживать перемещения виртуального сервера между узлами кластера. Этот автоматический контроль выполняется без модификации клиента или изменения конфигурации. В этом принимают участие SQL Enterprise Manager и любое из приложений OLE-DB, ODBC или DB-Lib. При восстановлении SVS клиенты отключаются, а затем выполняется повторное соединение по тому же логическому имени SVS. Переподключение базы данных реализуется в клиентском приложении и должно быть прозрачно для пользователя. Транзакции, которые находились в процессе обработки при возникновения сбоя, будут возвращены в исходное состояние в рамках стандартного процесса восстановления SQL Server. Эффект состоит в том, что как только на виртуальном сервере возник сбой, он тут же будет запущен на вторичном узле.
SVS управляются точно так же, как любой другой SQL Server с помощью инструментария SQL Server Enterprise Manager. SQL Server Executive и Distributed Transaction Coordinator (DTC) работают как компоненты SVS.
Sphinx будет поддерживать администрирование нескольких SQL Server как единого объекта управления с общей консоли. На данном кластере управление SVS может осуществляться как управление единой системой за счет определения группы серверов для кластера. Задания администрирования и политика управления могут применяться к группе кластеров, а не отдельно к каждому SQL Server.
Приложения могут быть масштабированы для поддержки больших баз данных за счет распределения данных локально между двумя виртуальными серверами, работающими на кластере, а затем можно использовать распределенные запросы для ссылки на все данные с любого сервера. Sphinx поддерживает размещение в различных таблицах на каждом виртуальном сервере, допуская автоматическую координацию распределенных запросов и модернизаций через Distributed Transaction Coordinator.
Sphinx поддерживает оптимизированное распределенное исполнение запросов между различными SQL Server (и между гетерогенными источниками данных, используя интерфейс OLE-DB). Прозрачный доступ к удаленным данным может быть реализован за счет определения локального представления удаленных данных.
Модернизация данных, распределенных между узлами кластера, автоматически координируется с целью обеспечить целостность и согласованность данных. Одно задание модернизации может касаться только одной удаленной таблицы, но помимо этого не требуется никакого вмешательства программиста.
Sphinx поддерживает восстановление после сбоя MSCS для обеспечения высокой готовности. Он также обеспечивает масштабируемость приложений SQL Server на кластерах узлов с Windows NT. В частности, он позволяет управлять всеми SQL Server в кластере с одной консоли. SQL Server кластера формируют федеративную базу данных, в которой каждая система может обращаться с запросом к другим. Приложение, работающее на одном узле, может запрашивать и объединять таблицы, размещенные на любом узле кластера, и инициировать процедуры сохранения на любом узле. Все эти операции организуются координатором Distributed Transaction Coordinator, который входит в состав Windows NT.
Новые версии SQL Server обеспечат представление единой системы для управления и использования кластером серверов SQL Server. Объекты баз данных могут распределяться между многими серверами SQL Server на различных кластерных узлах. Объекты имеют имена, не зависящие от их местонахождения, так что программа, работающая на любом узле кластера, может обращаться к объекту так, как будто он относится к базе данных, находящейся на локальном узле. Используя параллельную декомпозицию запросов, один большой запрос к одной или нескольким распределенным таблицам будет преобразован в набор запросов, которые будут выполняться параллельно на каждом узле кластера. Параллелизм важен для хранилищ данных и приложений добычи данных, поскольку он позволит в сотни раз увеличить скорость обработки больших запросов. Новые версии также будут поддерживать прозрачное восстановление после сбоя, так что этим клиентам нет необходимости восстанавливать соединение в случае сбоя на сервере, поскольку клиент подключается не к отдельному серверу, а ко всему кластеру.
SQL Server сейчас поддерживает тиражирование данных. Многие потребители конфигурируют вторую систему SQL Server, которая является ╚зеркалом╩ первой, располагая ее на значительном расстоянии от первой. Часто эти системы поддерживают ╚зеркало╩ друг друга, так что каждая из них выполняет половину работы. Наличие географически удаленной системы защищает информацию в случае различных катастроф (сбоев в электрической сети, пожаров, наводнений и т. д.). SQL Server должен упростить реализацию таких ╚устойчивых к природным катаклизмам╩ систем за счет предоставления более совершенных инструментальных средств для их конфигурации и управления, а также предлагая более прозрачное восстановление клиента за счет переноса его между узлами.
Большинство серверных приложений необходимо весьма незначительно модифицировать, чтобы они могли воспользоваться преимуществами, предлагаемыми MSCS. Приложения на основе транзакций (то есть такие серверные базы данных, как Microsoft SQL Server), потребуют дополнительной работы, поскольку они должны быть написаны так, чтобы гарантировать восстановление системы после сбоя без потери целостности транзакций. В частности, ниже мы обсудим, каким образом Microsoft SQL Server 6.5 и будущие версии (в частности, Sphinx) смогут использовать MSCS, а также обсудим, как создать клиентское приложение, которое сможет работать на кластере MSCS.
Создать клиентское приложение, ориентированное на MSCS, достаточно просто: необходимо учесть два момента, а именно восстановление базы данных после сбоя и проверку на ошибку.
Даже без ориентации на кластерные возможности SQL Server при перезагрузке автоматически восстанавливает все базы данных. Для гарантии возвращения базы данных в состоятельное положение разработчик должен использовать транзакции базы данных. Механизм транзакций гарантирует, что база данных восстанавливается корректно и окажется в согласованном состоянии. Любая транзакция, не завершенная из-за ошибки, будет отменена или состояние базы данных будет возвращено в исходное (до начала этой транзакции) состояние. Эффект от воздействия на базу данных всех завершенных транзакций будет сохранен.
При восстановлении после сбоя базы данных SQL Server связь приложения с сервером будет утрачена. Восстановление соединения тоже возлагается на клиента. Если соединение не зависит от состояния, клиент может возобновить его и продолжить обработку. Эту модель поддерживают приложения, разработанные с помощью IIS и многих других инструментальных средств. С другой стороны, если клиент и сервер имеют некоторое общее состояние (к примеру, открытые курсоры, переменные сеанса, глобальные переменные SQL-обработки или данные в TempDB), восстановление после сбоя не может ╚остаться не замеченным╩ для клиента. В этих случаях приложение должно или сообщить пользователю о разрыве соединения (констатируя, что оно было разорвано), или переустановить серверный контекст. Если в момент возникновения ошибки транзакция не была завершена, клиент должен проверить, выполнялась ли обработка транзакции. Чтобы упростить этот процесс, каждой транзакции присваивается уникальный идентификатор и приложение на время выполнения транзакции помещает этот идентификатор в базу данных. По наличию идентификатора в базе данных легко определить, завершена ли она.
Подобный механизм поведения клиента в случае возникновения ошибки на сервере стандартен для любого клиентского приложения SQL Server, даже без учета использования кластеров и виртуальных серверов. Процесс проверки на ошибку практически аналогичен процессу, выполняемому при разработке клиентского приложения базы данных для кластера. Когда кластер начинает восстанавливаться после сбоя, клиентская программа получает сообщение об ошибке на соединении с базой данных. Тип ошибки будет зависеть от того, что клиентская программа пыталась сделать в этот момент.
Когда на виртуальном сервере базы данных возникает ошибка, ожидающему клиенту приходит сообщение Connection Link Failed (╚Ошибка на соединении╩). В этот момент база данных на основном узле кластера будет закрыта и затем запущена на вторичном узле. При инициации работы SQL Server на вторичном узле база данных будет восстановлена. Если установка соединения предпринимается в момент восстановления базы данных, будет получено сообщение Waiting for Database Recovery (╚Ожидание завершения восстановления базы данных╩).
С программной точки зрения адаптировать клиентское приложение для работы на кластере никакой сложности не представляет. Когда клиентская программа определяет, что соединение утеряно, оно попытается его восстановить. Если соединение не зависит от состояния, клиент должен снова попытаться инициировать команду, которая выполнялась, когда в базе данных возникла ошибка. Если соединение зависит от состояния, тогда клиент должен восстановить состояние. Если в момент возникновения ошибки продолжалась обработка транзакции, попытка установить клиентское приложение должна быть предпринята вне зависимости от того, была ли транзакция завершена или прервана.
Если это сделано корректно, база данных будет возвращена в целостное состояние и продолжено нормальное выполнение программы.
Использование Internet Information Server компании Microsoft с SQL Server и MSCS обеспечит пользователям системы высокой готовности для доступа к критически важным данным на вашем предприятии.
Большинство приложений баз данных, которые в качестве пользовательского интерфейса применяют браузер Internet, для доступа к данным используют так называемые временные соединения. Временное соединение - это соединение, при котором Internet Server входит в базу данных, выполняет команду для работы с базой данных, извлекает результат (если он был сгенерирован) и затем выходит из системы. Информация о состоянии должна сохраняться в базе данных, так что потеря соединения не вызовет проблем с открытыми транзакциями.
Этот сценарий очень хорошо работает с SQL Server и MSCS. Так как соединение базы данных не является постоянным, клиентская программа не требует дополнительной логики для обработки сценариев восстановления после сбоя.
Использование возможности пулов соединений в ODBC вместе с технологиями доступа к данным компании Microsoft, такими как Internet Database Connector и Active Server Pages (возможность IIS), позволяет создавать надежные и высокопроизводительные приложения, которые всегда доступны для работы.
|
|