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

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

Microsoft планирует волну выпуска продуктов платформы Windows, но не все они будут готовы к празднику

Положив конец долгим месяцам спекуляций на эту тему, Microsoft наконец объявила о совместном празднике, посвященном выходу сразу трех продуктов: Windows Server 2008, Visual Studio 2008 и SQL Server 2008, который состоится 27 февраля 2008 года. Однако Microsoft использует своеобразную трактовку слова «выход», так как не все из перечисленных продуктов будут готовы к указанному сроку.

В то время как Windows Server 2008 и Visual Studio 2008 будут запущены в производство к концу текущего года, SQL Server 2008 (известный под кодовым названием Katmai) не будет готов раньше середины 2008. Единственное, на что подписалась Microsoft, — на готовность СУБД до конца текущего финансового года, который заканчивается у компании 30 июня 2008. В соответствии с заявлениями руководства корпорации этот план остается в силе и праздник состоится 27 февраля. (Учитывая, что праздник по поводу выхода SQL Server 2005 состоялся 7 ноября, было бы логично отпраздновать 2008 версию сервера 23 февраля, а не 27, но, видимо, в Microsoft не уловили пред­ы­дущего соответствия. — Прим. ред.).

«Формат праздника демонстрирует появление новой волны платформенных продуктов. Это не означает, что мы подписываемся под обязательством выпустить какой­то продукт к определенной дате, — сказал Ким Сондерс (Kim Saunders), старший директор группы маркетинга SQL Server. — Вполне может быть, что Katmai не будет полностью готов к объявленной дате».

В недавнем интервью компании CRN Энди Лис (Andy Lees), корпоративный вице­президент группы маркетинга серверных продуктов и инструментов и подготовки решений Microsoft, сказал, что Windows Server 2008 соблюдает график разработки и Visual Studio 2008 выйдет к концу 2007 года. Хотя Microsoft и позиционирует все три продукта как связанные, Лис сказал, что выходить они будут по растянутому графику.

«Они выйдут, когда будут готовы», — сказал Лис.

Все три продукта пока находятся в разработке. В июне был выпущен первый публичный релиз SQL Server 2008, а про Visual Studio 2008 недавно стало известно, что существенный набор функциональности (entity framework) выйдет отдельно после выпуска основного продукта (http://www.crn.com/software/199900068). Пока говорится о первой половине 2008 года.

Хотя продукты еще не вышли из рук разработчиков, Microsoft уже трубит о планах празднования запуска на рынок. На пленарном заседании Microsoft Worldwide Partner Conference в Денвере один из руководителей корпорации Кевин Тернер (Kevin Turner) объявил о планах представить все три продукта на мероприятии в Лос Анджелесе, за которым последуют такие же конференции меньшего масштаба по всему миру.

«Довольно много времени прошло с момента запуска очередной версии Windows Server», — сказал Тернер и добавил, что новая версия будет иметь усовершенствования в области веб­технологий, виртуализации и безопасности. В то же время, SQL Server 2008 поможет Microsoft поддержать то, что стало одним из наиболее прибыльных аспектов бизнеса компании, а Visual Studio 2008 будет иметь улучшенные языковые средства и средства доступа к данным.

Общие табличные выражения в SQL Server 2005

CTE — «временный результирующий набор», существующий лишь в рамках отдельного выражения SQL, позволяющий выполнять в рамках этого SQL-выражения такие действия, которые раньше были доступны лишь посредством функций, временных таблиц, курсоров и т. д.

На мой взгляд, общие табличные выражения (Com­mon Table Expressions, CTE) — одно из наиболее интересных новшеств, представленных в SQL Server 2005.

Основы CTE

Концепция CTE исключительно проста. Рассмотрим выражение:

with MyCTE(x)
as
(select x='hello')
select x from MyCTE

Оно определяет общее табличное выражение под названием MyCTE. В скобках после ключевого слова as содержится запрос, определяющий CTE. Следующий запрос ссылается на наше CTE, которое в данном случае просто возвращает слово «hello».

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

with MyCTE(x)
as
(
select top 10 x = id from sysobjects
)
select x, maxx = (select max(x) from MyCTE), pct =
             100.0 * x / (select sum(x) from MyCTE)
from MyCTE

В результате получаем (в моей системе):

x           maxx         pct
----------- ------------ ----------------
4           2137058649   2.515723270440
5           2137058649   3.144654088050
7           2137058649   4.402515723270
8           2137058649   5.031446540880
13          2137058649   8.176100628930
15          2137058649   9.433962264150
25          2137058649   15.723270440251
26          2137058649   16.352201257861
27          2137058649   16.981132075471
29          2137058649   18.238993710691

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

Quaere Verum — сканирование кластерных индексов. Часть 3

Случалось с вами когда-нибудь такое: вы настолько были в чем-то уверены, что даже и не думали проверять, а правда ли это. Все казалось столь очевидным, и вдруг вы понимаете, что ошибались?

Почему SQL Server стремится использовать сканирование в порядке размещения, если указаны директивы NOLOCK или TABLOCK?

В случае использования директивы TABLOCK это очевидно: если таблица полностью блокирована, не позволены никакие изменения данных, следовательно, невозможно никакое перемещение данных, по­этому можно без опаски использовать сканирование в порядке размещения и все­таки гарантировать непротиворечивость. Возможны случаи, когда, основываясь на оценках стоимости, SQL Server в профилактических целях принимает решение запросить блокировку таблицы или индекса (она же блокировка rowset) в отсутствие этих директив. В таких случаях последствия будут те же, что и при указании директивы TABLOCK. Вы можете использовать трассировку, чтобы выяснить, какого рода блокировка была предпринята.

В случае директивы NOLOCK (или задания для сессии уровня изоляции несохраненного считывания) вы сообщаете SQL Server, что вы не рассчитываете на непротиворечивость, поэтому гарантии отсутствуют. Имейте в виду, впрочем, что определение «непротиворечивые данные» означает не только то, что вы могли бы наблюдать несохраненные изменения, которые позже получили откат назад, или изменение данных на промежуточной стадии транзакции. Это также означает, что в простом запросе, который сканирует все данные таблицы/индекса, SQL Server может потерять позицию сканирования или вы могли бы в конечном итоге получить одну и ту же строку дважды.

Мне хотелось бы сделать краткое отступление перед тем, как приступить к демонстрации проблем противоречивости. В версии SQL Server 2000 мои тесты продемонстрировали, что сканирование в порядке размещения использовалось тогда, когда были указаны директивы NOLOCK или TABLOCK, независимо от размера таблицы. Однако в версии SQL Server 2005 даже при наличии этих директив для таблиц объемом вплоть до 64 страниц использовалось сканирование в порядке индекса; начиная с этого объема и выше, если была указана одна из этих директив, использовалось сканирование в порядке размещения. Изменение поведения в версии SQL Server 2005 объясняется тем, что стоимость инициации неупорядоченного сканирования довольно высока. Неупорядоченное сканирование выполняется на больших индексах там, где есть надежда, что доход покроет затраты. Чтобы увидеть это самим, вы можете поиграть с размером таблицы, меняя число итераций цикла в сценарии, который я предоставил для создания и заполнения таблицы T1. При 300 итерациях размер таблицы лежит в пределах 100 страниц. Если вы меняете количество итераций на достаточно маленькое значение (например, 100), размер таблицы будет меньше 64 страниц, и тогда SQL Server 2005 будет выполнять сканирование в порядке индекса, даже если вы укажете директивы NOLOCK или TABLOCK.

Далее я покажу, что вы можете получить одну и ту же строку дважды, если используется директива NOLOCK. Я создам таблицу T1, такую, что кластерный индекс по столбцу col1 будет определен как уникальный (unique) индекс с опцией IGNORE_DUP_KEY. Это означает, что в столбце col1 не могут встречаться двойные значения, а также то, что попытка вставить ключ­дубликат не приведет к сбою транзакции и выработке ошибки, но вместо этого будет выдано предупреждение. Я буду вставлять строки со случайными значениями в столбце col1 в бесконечном цикле, который прекратится, как только получит сигнал из другой сессии. Таким сигналом служит прекращение существования созданной ранее глобальной временной таблицы, которая называется ##DupsNotFound. Из другой сессии в бесконечном цикле я буду обращаться к таблице T1 с запросом, использующим директиву NOLOCK, попутно копируя данные во временную таблицу с именем #T. Я буду проверять, есть ли в столбце col1 какое­либо значение, которое встречается в таблице temp больше одного раза (это значит, что одна и та же строка считана из таблицы T1 больше одного раза), и если это так, я удаляю глобальную временную таблицу ##DupsNotFound. Отсутствие глобальной временной таблицы ##DupsNotFound служит сигналом выхода из бесконечного цикла для обеих сессий, поскольку мы подтвердили свои подозрения.

*См. Итцик Бен­Ган. Quaere Verum — сканирование кластерных индексов. Части 1, 2 // SQL Server для профессионалов. 2007. № 8, 9.

Формирование заданий резервного копирования в SQL Server 2005

Функциональность плана обслуживания (Maintenance Plan) в SQL Server 2005 претерпела существенные изменения по сравнению с SQL Server 2000: теперь используются новые Integration Services. Кроме того, резервное копирование баз данных и журналов транзакций стало
не таким уж очевидным.

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

Использование сценариев для резервного копирования SQL Server 2000

Если вы работали с планами обслуживания в SQL 2000, то, возможно, заметили, что ключевым элементом задания резервного копирования была расширенная хранимая процедура xp_sqlmaint, которая запускала утилиту sqlmaint. Хотя Microsoft обозначила sqlmaint и xp_sqlmaint как устаревшие средства и планирует удалить их из будущих версий SQL Server, они пока доступны и прекрасно справляются со своей задачей. Так что вы можете взять свои уже готовые задания резервного копирования из SQL 2000, изменить имена сервера и базы данных, папку для хранения файлов резервных копий и другие параметры, а потом запустить эти сценарии на сервере с SQL 2005.

Структуры очередей от Microsoft:SQL Service Broker против MSMQ

Не совсем нокаут, но SQL Service Broker побеждает MSMQ в его собственной игре

Microsoft предоставляет «своим» разработчикам две структуры очередей: MSMQ и SQL Service Broker. Обе эти структуры предлагают много одинаковых возможностей, но различаются в нескольких важных областях, которые могут повлиять на то, что именно вы выберете для своего проекта с очередями. MSMQ — это проверенная временем технология, в то время как SQL Service Broker — новинка для большинства разработчиков. Данная статья покажет некоторые из различий и, возможно, поможет вам сделать осознанный выбор технологии очередей.

Структуры очередей все еще являются одними из самых используемых структур при создании промышленных приложений. При правильном использовании они могут улучшить интерактивность пользовательского интерфейса, делая долговременные запросы ресурсов асинхронными, распределяя нагрузку между несколькими серверами или службами, предоставляя отключенным приложениям асинхронное подключение, разрешая/включая слабую связь между клиентами и серверами — и это еще не конец списка. Настоящий выигрыш для разработчиков состоит в том, что главная часть тяжелой работы для обеспечения этих служб уже была написана Microsoft. Вам не нужно создавать схемы данных или хранимые процедуры для управления рукотворными очередями при помощи SQL Server. Существуют и другие службы очередей, доступные разработчикам под Windows, такие как MQ Series от IBM и MessageQ от BEA, но MSMQ и Service Broker — это два самых вероятных кандидата для разработчиков, которые используют продукты Microsoft. Цена MSMQ, повсеместная доступность SQL Server для разработчиков Microsoft и широкий спектр клиентских платформ Windows, поддерживаемых обеими технологиями, делают MSMQ и SQL Service Broker самым простым выбором.

Компания Microsoft изначально предоставляла MSMQ в пакете Windows NT4 Option Pack и с тех пор опубликовала множество доработок. DevX опубликовал несколько статей, описывающих возможности MSMQ и программную модель. MSMQ бесплатно прилагается ко всем версиям Windows Server (после Windows NT 4 с ее пакетом Option Pack), Windows 2000 Professional и Windows XP. MSMQ предоставляет интерфейсы API, COM и .NET для посылки и принятия сообщений и для управления очередями.

С выпуском SQL Server 2005 Microsoft также предложила Service Broker в качестве альтернативы MSMQ. Будучи сильно привязанным к платформе базы данных Service Broker может быть более эффективен для операций с информационно емкими очередями; тем не менее, в отличие от MSMQ, вы должны получить лицензию под SQL Server для использования Service Broker. Функционал Service Broker доступен на любом языке, который вы используете для доступа к данным на SQL Server. А большая часть операций с очередями в SQL Service Broker производится при помощи расширений T­SQL.

Удивляет тот факт, что при известной популярности и MSMQ, и Service Broker отсутствуют достаточные сведения, позволяющие сравнить эти два продукта. Данная статья восполнит этот пробел.

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

Табл. 1 предоставляет краткое сравнение SQL Service Broker и MSMQ. Список не полный, но указывает на некоторые из важных различий между ними. Главным критерием занесения в список было определение наличия или отсутствия тех возможностей, которые помогут в выборе одной из технологий.

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

Цена

Чтобы использовать MSMQ, вы должны работать на Windows NT 4 (с установленным пакетом Option Pack), любой версии Windows 2000, Windows XP или Windows Server 2003. При такой широкой поддержке платформ операционных систем MSMQ дает вам наилучший результат, если вы собираетесь работать на системах, совместимых со старыми платформами. Вероятно, клиенты SQL Service Broker также могут работать почти на всех этих платформах, поскольку клиент SQL Service Broker требует только того, чтобы можно было подключиться к SQL Server 2005. Тем не менее многие приложения будет значительно проще приобрести и внедрить без дополнительного требования наличия экземпляра SQL Server 2005 для хранения компонентов по работе с очередями.

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

Лучшая производительность

Надежность служб очередей, предоставляемых SQL Service Broker как компонентом платформы базы данных, намного превосходит MSMQ. Даже если вы решите использовать транзакционный обмен сообщениями в MSMQ, вы столкнетесь с доставляющей неприятности нагрузкой от использования DTC для управления транзакциями. Тем не менее, если ваше приложение устойчиво к отказам (то есть для вас приемлемо потерять случайное сообщение), то MSMQ может стать лучшим вариантом. Благодаря возможности для разработчика/администратора выключить безопасность и защиту от потери сообщений, он способен предоставить лучшую пропуск­ную способность. Это особенно верно, когда посылающие и принимающие приложения не являются приложениями, работающими с данными. MSMQ предоставляет более тонкие возможности управления, что может быть полезно, когда производительность передачи сообщений является наиболее приори­тетной.

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

Производительность транзакций

Во многих случаях приложения с очередями по сущест­ву являются приложениями, работающими с данными. Служба обработки сообщений может искать данные в хранилище, добавлять новые элементы в заказ и т. д. В  таких случаях приложение с очередями, использующее SQL Service Broker, скорее всего, будет иметь огромный выигрыш по сравнению с аналогичным приложением, построенным на применении MSMQ, поскольку SQL Service Broker использует преимущество контекстов транзакций, управляемых изнутри SQL Server, в то время как MSMQ должен полагаться на координатора распределенных транзакций (DTC) для координирования контекстов транзакций между MSMQ и SQL Server. Когда MSMQ и база данных располагаются на отдельных серверах, излишняя нагрузка от использования DTC может стать непомерно велика.

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

Размещение кода

И MSMQ, и SQL Service Broker предоставляют огромную гибкость в создании приложений с очередями. Разработчики могут создавать такие приложения при помощи любого распространенного языка. Тем не менее один большой выигрыш от использования SQL Service Broker заключается в том, что вы можете писать отправителей и получателей при помощи T­SQL, располагающегося на SQL Server, — SQL Service Broker предоставляет возможность автоматически активировать хранимые процедуры для обработки сообщений. MSMQ для получения и обработки сообщений требует внешнего приложения. Таким образом, для приложений, работающих с данными, использование SQL Service Broker предоставляет значительную выгоду.

Применение типов

SQL Service Broker предлагает важнейшее преимущество над MSMQ, определяя содержимое сообщений при помощи типов сообщений SQL Service Broker (SQL Service Broker’s Message Types) (именованные типы данных, которые по выбору могут быть проверены на соответствие схемам XML) и контрактов (определение того, какие типы сообщений какими отправителями посылаются). MSMQ не предоставляет служб для применения типов сообщений, помещаемых в очереди.

Отключенные очереди

И MSMQ, и SQL Service Broker предоставляют способ посылать сообщения, когда принимающая очередь недоступна. Для приема сообщений MSMQ требует локального экземпляра MSMQ, а SQL Service Broker требует соединения (как минимум) с SQL Server Express. Поскольку и MSMQ, и SQL Server Express являются бесплатными, то различие в большинстве сценариев будет в том, являются ли внедрение и настройка SQL Server Express стоящими этих усилий. Громоздкое встраивание SQL Server Express вместе со всеми необходимыми настройками, чтобы разрешить очереди для вашего приложения, может стать значительной тратой сил. MSMQ в большинстве случаев может работать с отключенными сообщениями без какой­либо дополнительной локальной настройки.

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

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

Резервное копирование

В целом, резервное копирование очереди SQL Service Broker является более естественным процессом для большинства групп разработчиков, чем резервное копирование хранилища сообщений MSMQ. Я надеюсь, что любая компания, сильно зависящая от SQL Server, имеет хорошо отработанный процесс резервного копирования SQL Server. Поскольку очереди SQL Service Broker — это структуры базы данных, они сохраняются посредством обычных процессов резервного копирования. Более того, они используют все преимущества инкрементального и дифференциального резервного копирования, предоставляемого SQL Server.

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

Другие факторы

В данной статье я попытался осветить только то, что я рассматриваю как некоторые наиболее важные факторы, которые следует учесть при осуществлении выбора между MSMQ и SQL Service Broker. Скорее всего, вы будете рассматривать и другие факторы, не упомянутые здесь. Обычно, если у вас есть приложения, работающие с данными, в среде, где экземпляр SQL Server 2005 уже доступен, вам следует серьезно задуматься над использованием SQL Service Broker. Но вам следует рассмотреть MSMQ, когда и приложение­отправитель, и получатель являются внешними приложениями по отношению к серверу баз данных и когда требуемое внедрение SQL Server 2005 не является подходящим вариантом.

Наконец, поскольку SQL Service Broker обладает широким спектром поддерживаемых возможностей, которые я не мог охватить в этой статье; я подозреваю, что SQL Service Broker будет постепенно вытеснять MSMQ как более доминантная технология очередей, используемая разработчиками. Этот переход будет только ускоряться по мере распространения использования SQL Server 2005, что приведет к тому, что ценовой барьер упадет. Если вы заинтересованы в разработке приложений с использованием SQL Service Broker, то наиболее полным источником информации для вас станет книга Роджера Вольтера, «Рациональное пособие по SQL Server 2005 Service Broker» («The Rational Guide to SQL Server 2005 Service Broker»).

Табл. 1. Сравнение возможностей: данные возможности и недостатки помогут вам решить, какая технология, MSMQ или SQL Service Broker, более совместима с вашим конкретным проектом или средой

Подготовка инфраструктуры SQL Server 2005 для создания кластера

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

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

•    В сети должен быть хотя бы один сервер Active Directory, а лучше два в целях отказоустойчивости.

•    В сети должен быть хотя бы один DNS­сервер, а лучше два для отказоустойчивости.

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

•    Вам потребуется закрепить IP­адреса за всеми общими сетевыми картами.

•    Нужно определиться с конфигурацией частной (private) тактовой (heartbeat) сети: напрямую соединить одну сетевую карту с другой или использовать концентратор или коммутатор?

•    Вам потребуется закрепить IP­адреса за частными сетевыми картами. Обычно используют адреса из диапазонов для частных подсетей: 10.0.0.0 – 10.255.255.255, 172.16.0.0 – 172.31.255.255, 192.168.0.0 – 192.168.255.255. Помните, что это закрытая сеть, которую «видят» только узлы кластера.

•    Не забудьте о надежном и достаточном энергоснабжении для новых серверов кластера и разделяемого массива (если они только что появились в вашем центре обработки данных).

•    Убедитесь, что все узлы кластера и разделяемый массив оснащены устройствами бесперебойного питания.

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

•    Создайте служебную учетную запись для службы Windows Clustering. Это должна быть доменная учетная запись с неограниченным сроком дейст­вия пароля.

•    Создайте три глобальных группы для SQL Server Ser­vice, SQL Server Agent Service и SQL Text Service соответственно. Они вам понадобятся при установке SQL Server 2005 на кластер.

•    Определитесь с именем виртуального кластера (Clustering Services) и закрепите за ним виртуальный IP­адрес.

•    Определитесь с именем виртуального кластера SQL Server 2005 и закрепите за ним виртуальный IP­адрес.

•    Если хотя бы для одного узла в кластере вы используете Smart UPS, перед установкой Cluster Services удалите его, а потом добавьте вновь.

•    Если серверы­узлы поддерживают функции управления питанием AMP/ACPI, отключите их. Это относится к сетевым картам, драйверам и т. д. Активация этих функций может привести к серьезному сбою.

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

От редакции: Совсем недавно Microsoft выпустила утилиту проверки качества кластера (Microsoft Cluster Configuration Validation Wizard (ClusPrep)). Она доступна по ссылке http://www.microsoft.com/downloads/details.aspx?FamilyID=bf9eb3a7­fb91­4691­9c16­553604265c31&DisplayLang=en.

Имейте только ввиду, что утилиту следует запускать до того, как кластер будет собран.

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