Кластеры MS SQL 2000: Web-приложения масштаба предприятия - MS Project Central Server 

О чем эта статья?

Пользователю: Зачем нужен кластер? Пример кластерного решения для Project Central Server

IT-Менеджеру: Чем хорош и плох кластер MS SQL 2000?

Разработчику: Как масштабировать MS Project Central в кластер MS SQL 2000? 

Выводы


см. также семинары посвященные использованию и администрированию MS Project Central Server

 

О чем эта статья?

Данная статья посвящена созданию и администрированию приложений масштаба предприятия. Имеется в виду создание систем, в которых интегрированы в единое целое  несколько серверов одного приложения, создание так называемых кластеров. Мы будем анализировать средства масштабирования Microsoft SQL Server 2000, на май 2001г по тестам TPC-C  это самый быстрый кластер в мире. Мы будем рассматривать как с помощью кластерного механизма масштабируется  реальное приложение, в данном случае Web-сервер проектов MS Project Central Server (описание назначения Project Central см. здесь). Это Web-приложение предназначенное для проектного управления и учета реальных затрат рабочего времени. В нашем анализе рассмотрим реальные достоинства и недостатки кластерных решений на базе MS SQL Server 2000.

Пользователю: Зачем нужен кластер? Пример кластерного решения для Project Central Server

Под кластерами разные производители понимают несколько разные подходы, дадим "усредненное" определение кластера.

Кластер - это объединение нескольких серверов в единую систему. 

Обычно кластерное решение применяют для следующих целей:

Рассмотрим пример.  Имеется компания "Рога и Копыта", в него входят два подразделения "Рога" и "Копыта". Оба подразделения для проектного управления и учета рабочего времени используют свой MS Project Central Server. Все хорошо, но требуется получить консолидированную отчетность по работе обоих подразделений. Для этого создается специальный сервер отчетов, который включает в кластер сервера отделов. Причем сервера отделов имеют право закрыть доступ к части информации как серверу другого отдела, так и серверу консолидированной отчетности. Задача сокрытия данных для "Рога и Копыта" очень актуальна, т.к. компания быстро перерастает  в подобие холдинга и утечки информации даже в соседнее подразделение крайне не желательны.

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

IT-Менеджеру: Чем хорош и плох кластер MS SQL 2000?

Мы описывали выше кластерное решение характерное для MS SQL 2000. Описание кластерных технологий Microsoft можно также посмотреть на специальной странице.

Какие достоинства есть у кластера в понимании Microsoft?

Какие недостатки есть у кластера MS SQL 2000?

 

Разработчику: Как масштабировать MS Project Central в кластер MS SQL 2000? 

Мы опишем как организовать простое кластерное решение для Project Central за 3-5 человеко-дней. Данное решение имеет существенные ограничения по функциональности. Мы не будем рассматривать более сложные кластерные решения, такие как кластеризация базы workflow (см. ниже), такие решения дешевле заказать. Если вам нужны сложные кластерные решения пишите на ivanov-soft@inbox.ru

Прежде всего об архитектуре MS Project Central. Сервер спроектирован так, чтобы работать в кластере MS SQL 2000. В основном это заключается в том, что Central способен хранить данные по проектам в различных базах данных, существует только одна единая база данных в Central - это база проектного документооборота сервера.  Рабочими местами пользователей является браузер, вся бизнес-логика реализована в виде ActiveX и COM компонент. MS Project Central продукт с открытой архитектурой, т.е. вы можете его модифицировать. 

Естественно напрашивает решение, что  Central построен на disributed view, но это не так.  Дело в том, что Microsoft стремился, чтобы Central мог работать и под Oracle. Эта задача была даже перевыполнена. Фактически Central может работать на любом SQL сервере, но вам потребуется настроить индексы и сделать свои функции генерации ключей. 

Делая ставку на многоплатформенность Microsoft решил не  использовать решений  "for MS SQL only", поэтому межбазовые манипуляции делаются самим Central Server, для штатных средств документооборота и отчетности это работает достаточно эффективно. Однако есть несколько причин по которым целесообразно запустить кластер MS SQL 2000:

1) Если вы хотите строить консолидированные отчеты используя OLAP и Data Mining, то создание кластера MS SQL 2000 весьма целесообразно, т.к. это упростит доступ к информации и повысит скорость формирования отчетов.
2) Другая причина поднятия кластера, возможно вы будете разрабатывать расширения Project Central, например автоматически выставлять отметки прохождения оплат в проекты менеджеров. В данном случае кластер позволит вам значительно упростить разработку и поднять производительность системы.
3) Возможно вы хотите повысить производительность Central запустив кластер, об этом имеет смысл подумать если у вас более 100 пользователей. Такое количество и даже больше набрать очень легко, если Central используется для сбора статистики о реальных затратах рабочего времени. В данном случае timesheet будет заполнять каждый сотрудник компании. Для многих корпораций сбор подобной статистики стандарт.

Что нужно сделать для организации кластера из проектных баз?

1) Создайте в таблицах начинающихся с MSP специальное поле, которое будет играть роль "partitioning column". Например, некое поле BaseId - идентификатор базы (можно еще использовать поля типа "департамент" и т.д.)
2) Установите полю значение по умолчанию соответствующее  БД.

3) Создайте на MSP-таблицах ключ, включающий BaseId как часть.

4) Наложите на поле BaseId ограничение  (check) соответствующее БД.

5) Создайте distributed view через все базы

Вот фрагменты скриптов в качестве иллюстрации:

CREATE TABLE [dbo].[MSP_ASSIGNMENTS] (
[PROJ_ID] [int] NOT NULL ,
[ASSN_UID] [int] NOT NULL ,
[BaseId] [int] NOT NULL

....... 
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

ALTER TABLE [dbo].[MSP_ASSIGNMENTS] WITH NOCHECK ADD 
CONSTRAINT [PK__MSP_ASSIGNMENTS__29221CFB] PRIMARY KEY CLUSTERED 
(
[ASSN_UID],
[PROJ_ID],
[BaseId]
) WITH FILLFACTOR = 40 ON [PRIMARY] 
GO

ALTER TABLE [dbo].[MSP_ASSIGNMENTS] WITH NOCHECK ADD 

.....
CONSTRAINT [DF_MSP_ASSIGNMENTS_BaseId] DEFAULT (1) FOR [BaseId],
CONSTRAINT [CK_MSP_ASSIGNMENTS] CHECK ([BaseId] = 1)
GO

CREATE VIEW ASSIGNMENTS AS
SELECT * from Server1.PrjBase1.dbo.MSP_ASSIGNMENTS
UNION ALL

SELECT * from Server2.PrjBase2.dbo.MSP_ASSIGNMENTS
.....

 

Известные проблемы кластерных решений под MS Project Central Server:

прежде всего рекомендую ознакомится с ограничениями на кластеры

1) Рекомендую после всех манипуляций пересоздать constraints на таблицах, иначе distributed view может не поймать колонку BaseId (подробности в MSDN).

2) Проверяйте Query Plan своих запросов, в запросах без join оптимизатор может не поймать BaseId и начать сканировать все базы кластера. Сделайте join на поля задающие primary key, или укажите их константные значения, или сделайте примерно такую магическую конструкцию select * from DistributedView where BaseId=XXX and ((Key1=0) and (Key2=0) or (Key1>0 and Key2>0)). В принципе если MS сделает специальные хинты для хватания партиционной колонки, то в магии необходимость отпадет. Вообще хочется и похвалить Microsoft, в сложных запросах с большим количеством связей distributed view  как правило оптимизируется правильно и весьма эффективно.

3) Обратите внимание, что в нашем простом примере выше вы не сможете сделать insert в disributed view, т.к. есть default-колонки. Зато без переделок MS Project будет без проблем читать и писать в базу. Для выставления отметок об оплате (update) это не существенно, для других задач нужно применить более сложное решение.

4) Довольно не просто разнести по кластеру базу документооборота одного сервера Project Central, т.к. там на таблицах стоят indentity-нумераторы, их нельзя использовать в updatable distributed view. Чтобы запустить кластер вам потребуется сделать свою функцию генерации ключа, не забудьте вставить ее вызов в библиотечный файл Qylibstd.sql в макрос номер 13000. В целом это хитрое решение, и очень полезное, если на одном сервере Central больше 200 пользователей. Если оно вам требуется пишите на ivanov-soft@inbox.ru

5) Можно применить следующий простой прием создания кластера из баз документооборота Project Central, но с ограничениями: не более 100-200 пользователей на сервер и не требуется интенсивный workflow между серверами. Установите несколько серверов Project Central. Для их интеграции переведите всех пользователей на NT-секретность,  затем создайте  кластер для получения консолидированной статистики по текущем назначенным задачам (Assignments reports).  Такой подход отлично работает, но не забывайте периодически применять средства архивирования Central (см. меню Admin - Delete from database). 

6) Банальный совет: не устанавливайте MS SQL и IIS для Central на один сервер.

 

Выводы

MS Project Central Server 2000 одно из первых приложений доступных даже малым компаниям на рынке, которое имеет возможность использовать кластерные механизмы MS SQL Server 2000. Central имеет имеет некоторые ограничения в организации кластерного решения, но зато может работать и на сервере Oracle. На примере Project Central можно убедится в высокой производительности кластера MS SQL 2000.