КЛАСТЕРЫ на базе Exchange Server 2003

Прорыв или провал?

История кластеров Exchange Server — это непрерывная цепь взлетов и падений, периодов всеобщего энтузиазма, связанных с выходом новых версий программного продукта, и неизбежной депрессии, которая наступала, как только становилось очевидно, что очередная версия кластера не работает. Впервые кластеры Windows стала поддерживать версия Exchange Server 5.5, но эти кластеры оказались очень дорогими и могли работать только в двухузловой конфигурации в режиме active-passive. С появлением версии Exchange Server 2000 была обещана поддержка четырехузлового кластера, все узлы которого будут активны. Однако Microsoft не выполнила данное обещание: из-за проблем с фрагментацией памяти потребовалось наличие пассивного узла. Кроме того, развернуть четырехузловой кластер Exchange 2000 можно только на Windows 2000 Datacenter Server, а это опять-таки слишком дорого. В результате количество развернутых почтовых кластеров составляет несколько процентов от сотен тысяч установленных в настоящее время серверов Exchange. Никто не может точно сказать, сколько же почтовых кластеров работает в сфере бизнеса, но очевидно, что не более 2% от общего числа всех установленных серверов Exchange.

На первый взгляд может показаться, что кластер обеспечивает исключительно эффективный способ достичь высокой степени жизнеспособности и надежности. В самом деле, ведь развертывают же администраторы Unix и OpenVMS кластеры вот уже много лет. Почему же администраторы Windows не должны использовать кластерные решения для Exchange 2000 и Exchange 5.5? А причина заключается в сложности кластерного решения, в том, что компоненты Exchange не могут работать на кластерах, что не хватает продуктов независимых разработчиков для поддержки кластерных решений, существуют проблемы с фрагментацией памяти, и, наконец, из-за высокой стоимости решения.

Чтобы кластер заработал, необходимы совместные усилия почтового приложения и операционной системы. До сих пор разработчики Microsoft были не в состоянии обеспечить выполнение этого требования. Планируется улучшить кластерную поддержку для связки Windows Server 2003 и Exchange Server 2003, но удастся ли это сделать? Чтобы ответить на этот вопрос, необходимо понимать, как работает кластер, знать общие принципы работы Exchange в составе кластера, изучить особенности функционирования в кластере Exchange 2000 и разбираться в новшествах версии Exchange 2003.

Как Exchange работает в кластерах

Установка и настройка аппаратуры и программного обеспечения кластеров — задача более сложная, чем процесс установки и настройки стандартных серверов. Кластеры обычно оснащаются несколькими сетевыми картами (NIC). Администратору нужна по крайней мере одна NIC для общедоступной сети (Public Network) и одна — для «прослушивания жизнедеятельности» кластера (анализируется специальный сетевой сигнал между узлами, что позволяет им судить о работоспособном состоянии кластера). Кластеры используют разделяемое устройство хранения вместо подключенных напрямую устройств, поскольку нормальная работа серверных служб в кластере зависит от того, могут ли данные перемещаться между узлами при возникновении той или иной проблемы. Если местоположение данных жестко завязано на определенный сервер, служба не в состоянии переносить данные и нормально функционировать.

Обслуживание кластеров отличается от обслуживания стандартных серверов. Вместо использования консоли Computer Management для работы со службами Exchange или иных приложений, администратор работает через консоль Cluster Administrator, изображенную на экране 1. В приведенном примере в Cluster Administrator показан набор служб Exchange, в данный момент запущенных на кластере. На консоли также изображены дополнительные ресурсы, которые представлены в форме виртуального сервера Exchange, — это диски, адрес IP и сетевое имя.

Концепция виртуальных серверов для понимания работы кластера является принципиальной. Когда говорят, что Exchange работает на кластере, имеется в виду, что он работает на одном или нескольких виртуальных серверах. Каждый виртуальный сервер отождествляется с определенным набором ресурсов (т. е. с дисками, сетевым именем, хранилищем Store), которые необходимы Exchange для предоставления пользователям всех необходимых служб. Виртуальные серверы Exchange работают на физических узлах кластера. Виртуальные серверы занимаются обслуживанием данных в почтовых ящиках (mailbox) и общих папках (public stores), которые объединены в группы хранения (Storage Group, SG). Отдельная SG — это базовая единица хранения для кластерного Exchange-сервера. Если на физическом узле происходит сбой и кластер в состоянии перенести работу внутри данного кластера, программное обеспечение кластера распределяет группы SG с пострадавшего сервера на остальные узлы, а не занимается переносом индивидуальных хранилищ. После возникновения ситуации «отказ» (failover) группы SG переходят под управление виртуального сервера Exchange, работающего на данном физическом узле.

Тем, кто разобрался в базовых понятиях работы кластера и принципах работы Exchange в кластере, должно быть очевидно, что не все компоненты Exchange могут работать в кластере. Причина проста. В некоторых случаях тот или иной компонент Exchange является устаревшим, т. е. он не был рассчитан на использование где-либо еще, кроме стандартного сервера. Поскольку компонент устарел и, вероятно, в большинстве установок Exchange не применяется, Microsoft никогда не возьмется за его обновление для обеспечения работы в составе кластера. В других случаях компонент может работать только при каком-то исключительном стечении обстоятельств (для взаимодействия между серверами Exchange 2000 и Exchange 5.5, например), поэтому в долгосрочной перспективе компонент не обязан поддерживать функциональность кластера. В таблице перечислены дополнительные компоненты Exchange и степень соответствия их работы функциям кластера.

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

Использование Exchange 2000 в кластерах

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

В процессе работы Exchange 2000 операционная система Windows выделяет и освобождает виртуальную память для почтовых ящиков и некоторых других элементов. Иногда виртуальная память выделяется непрерывными порциями, например по 10 Мбайт, при монтировании базы данных. Но со временем из-за фрагментации выделять непрерывные порции виртуальной памяти становится все сложнее. По своей сути данная фрагментация похожа на дисковую фрагментацию, и все было бы не так плохо, если бы не перемещения групп в кластере.

Во время перехода кластера из одного состояния в другое все SG, которые были активными на отказавшем узле, кластер должен переместить на один или несколько работоспособных узлов. Группы SG состоят из наборов баз данных, следовательно, служба Store должна сначала проинициализировать переносимые SG, а затем смонтировать базы данных, чтобы пользователи могли работать со своими почтовыми ящиками. Все перечисленные действия можно отследить через событие с ID 1133 в журнале приложений. Если кластер очень сильно загружен, служба Store может оказаться не в состоянии смонтировать базы данных из-за нехватки достаточного числа непрерывных участков виртуальной памяти — это сопровождается появлением события с ID 2065. Таким образом, возникает ситуация, когда кластер оказывается в состоянии перехода, но на этом все и заканчивается — хранилище Store осталось без баз данных. Повторяю, такой сценарий возможен только в исключительно высоко нагруженных системах. Однако консолидация серверов и построение больших систем с богатой функциональностью — это основной движущий фактор для принятия решения о создании кластера, и, следовательно, такие системы по определению оказываются сильно загружены.

Столкнувшись с этой проблемой, специалисты Microsoft проанализировали ситуацию и установили, что данная проблема возникает при работе в режиме active-active. После этого разработчики Microsoft стали советовать заказчикам вносить ограничения в функциональность кластерных проектов и устанавливать предельное число почтовых клиентов — 1000 для Exchange 2000, 1500 для Exchange 2000 Service Pack 1 (SP1) и 1900 для Exchange 2000 SP3 и SP2.

Рекомендованное число почтовых клиентов основано на оценке загрузки Messaging API (MAPI). Так как MAPI — наиболее функциональный почтовый протокол, нагрузка на сервер Exchange со стороны клиентов MAPI самая ощутимая. Клиенты Microsoft Outlook Web Access (OWA) генерируют типы запросов, похожие на те, что создают MAPI-клиенты. Однако все остальные клиентские протоколы (IMAP4, POP3), как правило, генерируют меньший поток системных запросов и создают меньшую нагрузку на сервер. Поэтому в организации может обслуживаться большее число почтовых клиентов, нежели рекомендовано Microsoft, и их работа не будет сопровождаться проблемами с виртуальной памятью.

В Exchange 2000 SP3 реализована новая схема выделения виртуальной памяти для Store. В новой схеме изменен способ, в соответствии с которым выделяется и освобождается память Windows. Проведенные до настоящего времени эксперименты демонстрируют, что на серверах с SP3 в конфигурациях высокопроизводительных кластеров проблем с дефрагментацией виртуальной памяти стало меньше. Microsoft настоятельно рекомендует, чтобы организации с кластерами обновили программное обеспечение почтового сервера до уровня Exchange 2000 SP3 или, что еще лучше, перешли на Windows 2003 и развернули Exchange 2003, обеспечивающий более эффективное управление памятью.

Проблемы с обслуживанием виртуальной памяти вынудили специалистов Microsoft обратить особое внимание на то, как следует устанавливать активные кластеры. По существу, рекомендации Microsoft состоят в том, что всегда следует иметь под рукой пассивный узел, значит, двухузловой кластер должен работать в режиме active-passive, а четырехузловой кластер должен иметь три активных и один пассивный узел.

Объем виртуальной памяти по мере роста нагрузки на сервер постепенно уменьшается. Exchange регистрирует событие с ID 9582, когда объем доступной виртуальной памяти опускается ниже 32 Мбайт, затем тем же самым событием отмечается ситуация, когда в Store нет непрерывных блоков памяти размером более 16 Мбайт. В последнем случае кластер оказывается в нестабильном состоянии и перестает отвечать на запросы клиентов, и тогда выход — перезагрузка. Вот еще два случая, когда можно обнаружить событие с ID 9582.

• Событие с ID 9582 может появиться сразу после отказа на пассивном узле, если перед этим пассивный узел выступал в качестве хоста того же самого виртуального сервера. Каждый узел запускает аналог процесса store.exe, и структуры этого процесса уже могут оказаться фрагментированными, что приводит к появлению ошибки. Если это произошло, можно перенести виртуальный сервер на другой узел кластера, а затем перезапустить сервер с фрагментированной памятью. Если пассивный узел оказывается недоступен, придется перезапускать активный узел. На Exchange 2000 SP3 такие проблемы возникают гораздо реже, так что вряд ли вам «повезет» увидеть событие с ID 9582, если только сервер не окажется нагружен экстремально.
• Некорректное использование ключа /3GB в boot.ini может привести к появлению события с ID 9582. Если Exchange 2003 установлен на сервере Windows 2003 с объемом установленной памяти больше 1 Гбайт, в boot.ini следует использовать ключ /3GB и ассоциированный ключ /Userva=, чтобы Windows 2003 поддерживала лучший баланс при распределении ресурсов в режиме ядра и пользователя. Дополнительную информацию о переключателях можно найти в статье Microsoft «XADM: Event Viewer Log Entries Cite Virtual-Memory Fragmentation on an Exchange 2000 Server» (http://support.microsoft.com/?kbid=314736) и «XADM: Using the /Userva Switch on Windows 2003 Server-Based Exchange Servers» (http://support.microsoft.com/?kbid=810371).

Следует отметить, что работа программных продуктов некоторых независимых разработчиков, в частности антивирусных сканеров, способна повлиять на использование виртуальной памяти. Во врезке «Мониторинг виртуальной памяти» рассказано о том, как узнать объем виртуальной памяти, занимаемый программами независимых поставщиков, а также описаны способы мониторинга виртуальной памяти кластера.

Что изменилось в Exchange 2003

Хотя Exchange 2003 может быть развернут на серверах Windows 2000, разработчики Microsoft не устают повторять, что Windows 2003 и Exchange 2003 лучше всего использовать совместно, так как тем самым достигается оптимальная функциональность, поскольку оба программных продукта проектировались для работы в связке. Это утверждение справедливо во многих смыслах, но особенно для кластеров. Лично я не рекомендовал бы разворачивать кластер Exchange на чем-либо, кроме серверов Windows 2003. Вот перечень основных усовершенствований кластерной пары Windows 2003 — Exchange 2003:

• Для Windows 2003 и Exchange 2003 можно настроить кластеры из восьми узлов. По сравнению с четырьмя узлами восемь узлов обеспечивают гораздо большую гибкость в том, что касается распределения серверов в кластере и выполняемых ими ролей. Однако по крайней мере один узел должен оставаться пассивным, если речь идет о поддержке большого числа почтовых клиентов, большом количестве коннекторов или значительной загрузке кластера. Кластеры, поддерживающие лишь несколько клиентов и, возможно, работающие только с одной SG и парой-тройкой баз данных на каждом активном узле, могут работать и в полностью активном режиме, поскольку вероятность фрагментации виртуальной памяти невысока.
• Больше нет зависимости от версии Windows Datacenter, кластеры можно развертывать без дополнительных затрат на ее приобретение.
• В Windows 2003 и Exchange 2003 усовершенствовано управление фрагментацией виртуальной памяти, что означает увеличение числа MAPI-клиентов, которые кластер в состоянии поддержать. Кроме того, Windows 2003 и Exchange 2003 лучше работают с большими объемами физической памяти (свыше 1 Гбайт). Формальное тестирование на предмет выяснения максимального числа одновременно работающих MAPI-клиентов, которые может обслужить Exchange 2003 до возникновения фрагментации виртуальной памяти, пока еще не проводилось, однако тот факт, что Microsoft развернула кластеры с поддержкой 4000 почтовых ящиков на узел, позволяет надеяться, что это максимальное число достаточно велико. Если пассивный узел в конфигурации active-passive всегда доступен, кластеры могут поддерживать работу очень большого числа пользователей на активный узел - вероятно, до 5000 почтовых ящиков на узел. Точный ответ на этот вопрос зависит от системной конфигурации, загрузки, создаваемой пользователями системы, типа работающих клиентов и грамотного мониторинга виртуальной памяти значительно нагруженных активных узлов.
• Можно использовать точки монтирования (известные также как точки монтирования NTFS) для устранения ограничения Windows 2000 - Exchange 2000 на число доступных букв дисков, что ограничивало число доступных дисковых групп в кластере. Это очень важное усовершенствование, особенно если на узлах кластера развертывается более 10 SG.
• Благодаря новой ресурсно-зависимой модели Exchange 2003 и некоторым другим усовершенствованиям, алгоритм обслуживания процесса отказа в Exchange 2003 выполняется иначе - Exchange 2003 быстрее переносит многочисленные SG с неисправных серверов на активные узлы по сравнению с Exchange 2000.
• Разработчики Microsoft несколько видоизменили интерфейс обслуживания Exchange 2003 для упрощения администрирования сервера. Так, например, как показано на экране 2, консоль Exchange System Manager (ESM) теперь предоставляет подробную информацию о типах серверов, и с одного взгляда понятно, в рабочем ли состоянии находится узел кластера.
• Предполагая, что используется надлежащее оборудование и программное обеспечение для резервного копирования, можно использовать Volume Shadow Copy Service (VSS) API в Windows 2003 для получения резервных копий типа моментальный снимок (hot snapshot). Это важное улучшение, кластеры не будут работать с полным потенциалом, если администраторы вынуждены ограничивать размер своих баз данных. Ограничение размера баз данных ограничивает и число почтовых ящиков, установленных на кластере. Вместе с тем VSS-совместимые продукты появляются на рынке программного обеспечения нечасто, поэтому не стоит так уж сильно полагаться на это усовершенствование до тех пор, пока не будет выбран подходящий программный продукт.
• Функция Recovery Storage Group дает администраторам возможность проводить быстрое восстановление при сбое отдельно взятой базы данных и без необходимости разворачивать выделенные серверы восстановления. Эта функция доступна и при установке Exchange 2003 на серверах Windows 2000.

Функции VSS и Recovery Storage Group не есть нечто сугубо кластерное. Вместе с тем обе они способствуют повышению степени готовности служб кластера и в какой-то мере успокоят администраторов, консолидировавших большое число стандартных серверов в один большой кластер и сложивших таким образом все яйца в одну корзину.

Как можно заметить, перечисленные усовершенствования касаются причин, объясняющих, почему администраторы Windows не решаются устанавливать кластеры в своих организациях. Нередко администраторы, ранее не рассматривавшие кластер как решение проблемы, меняют свою точку зрения. Например, в организации завершается развертывание Exchange 2000 или миграция с устаревших почтовых систем и больше нет нужды поддерживать компоненты Exchange, которые не умеют работать на кластере. Или, скажем, компоненты Exchange 2000, ранее не работавшие на кластере, были заменены новыми продуктами, которые относятся к классу cluster-aware. Все компоненты ядра Exchange 2003 могут быть запущены на кластере. Таким образом, проблема несовместимости с кластером теперь решается путем поиска соответствующего программного обеспечения от независимых разработчиков. И даже это постепенно перестает быть проблемой, поскольку, как уже отмечалось, с ростом числа независимых продавцов программных продуктов выбор дополнительных программ для кластеров расширяется.

Опыт Microsoft

Это кажется удивительным, но, хотя Microsoft никогда ранее не использовала кластеры в своих установках Exchange, с появлением Exchange 2003 и обнародованием программы консолидации серверов ситуация коренным образом изменилась. Microsoft заменила свои старые стандартные серверы Exchange на множество новых крупных почтовых кластеров. Наибольший интерес представляет проектирование центра обработки данных, который поддерживают 16 тыс. почтовых ящиков, распределенных на четырех виртуальных серверах Exchange. Кластер состоит из семи физических узлов, четыре из которых обрабатывают нагрузку, сгенерированную четырьмя почтовыми серверами. Другой сервер — пассивный, он начинает работать, только когда на одном из почтовых серверов произойдет сбой. Почтовые серверы (а также пассивный узел) — устройства очень мощные: HP ProLiant DL580G2 с четырьмя процессорами 1.9GHz Intel Xeon III, с оперативной памятью 4 Гбайт и шиной front-side на 400 МГц. Microsoft активизировала функцию hyperthreading во всех серверных версиях и сообщает, что благодаря этому производительность процессоров возросла примерно на 20%. Специалисты Microsoft последовали своим же рекомендациям и прописали ключ /3GB и /Userva=3030 (значение в мегабайтах) в файле boot.ini.

Два оставшихся сервера — два сервера HP ProLiant DL380G2 с двумя процессорами и 2 Гбайт RAM — занимаются резервным копированием и другими административными функциями. Поскольку эти серверы играют вспомогательную роль и не являются хостами Exchange, требования к их конфигурации менее строгие.

Стандартная квота на почтовый ящик в Microsoft составляет от 100 до 200 Мбайт, хотя, конечно, существует значительный разброс в зависимости от конкретных условий.

Неудивительно, что ежедневно огромный объем данных уходит в резервную копию. Самые лучшие методики резервирования на ленту позволяют переносить до 100 Гбайт в час, но это решение не подходит для кластера, имеющего 16 тыс. почтовых ящиков. Для кластера такого размера необходимо иметь почтовые серверы, оптимизированные под максимально быстрое взаимодействие с пользователями и «не замечающие» нагрузки, которую генерирует задание резервного копирования на ленту. Группа разработчиков Microsoft решила проблему резервирования следующим образом: в первую очередь создаются резервные копии дисков на томах, которые в данный момент временно принадлежат почтовым серверам. После завершения создания дисковой копии эти тома «уходят» в процессе отказа на вспомогательные узлы и попадают под управление двух вспомогательных серверов, а уже эти серверы создают ленточную копию дисковых данных. Это наглядная демонстрация того, как административные проблемы решаются с помощью чисто кластерной технологии. В будущем Microsoft планирует развернуть основанную на VSS технологию создания моментальных копий в дополнение к классической схеме создания моментальных копий (Hot Snapshot лишь дополняет, но не заменяет обычное резервирование на ленту).

Хранение всех данных обеспечивает устройство SAN от HP — StorageWorks Enterprise Virtual Array 5000 (EVA5000). SAN играет очень важную роль в обеспечении функционирования огромных кластеров Microsoft благодаря таким характеристикам, как избыточность и организация управления. Поскольку поддерживать большое число SG, журналов транзакций, рабочих каталогов SMTP нелегко — все это требует своих дисков, нетривиальный кластер Microsoft имеет большое число таких дисков. Microsoft очень активно использует точки монтирования для обхода ограничения букв для дисков, иначе просто невозможно было бы приемлемым образом настроить все это громоздкое хозяйство.

Я не слышал, чтобы где-то еще было развернуто что-то похожее на описанный почтовый кластер Microsoft. Специалисты Microsoft подсчитали, что с помощью кластера достигнут более высокий уровень сервисного обслуживания, чем это можно было сделать при помощи стандартных серверов. Утверждается, что компания смогла добиться готовности 99,99%. Однако независимый аудит не проводился, поскольку кластер Microsoft построен на бета-версиях Exchange 2003 и программное обеспечение непрерывно обновлялось вплоть до появления финальной версии Exchange. Было бы просто замечательно, если бы кто-либо еще смог приблизиться к достигнутому результату.

Не стоит лезть на рожон

Надо быть действительно отчаянным человеком, чтобы очертя голову бросаться развертывать кластер «к завтрашнему дню». Администраторы, которые не занимаются исследованием, планированием и проектированием кластера заблаговременно, а сразу приступают к его установке, неизбежно сталкиваются с многочисленными проблемами. Кластеры Exchange 2003 — конструкция более сложная, чем стандартный сервер Exchange, и весь опыт работы с Exchange демонстрирует, что необходимо соблюдать большую осторожность при установке и обслуживании кластеров Exchange 2003, чтобы достичь желаемой продолжительности работоспособного состояния и устойчивости в работе. Только те администраторы, которые не жалеют времени на этап проектирования самого кластера и его обслуживание, могут достичь успеха.

Усовершенствования, проведенные в Exchange 2003 и Windows 2003, делают кластеры Exchange жизнеспособным продуктом. Самые первые отзывы об успешном развертывании кластеров Exchange 2003, в том числе пример кластера в Microsoft, весьма обнадеживают. Теперь задача Microsoft — продолжить двигаться по пути уменьшения сложности настройки кластеров, чтобы установка и обслуживание кластеров стала такой же простой, как установка и обслуживание стандартных серверов.

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

Тони Редмонд — редактор Windows 2000 Magazine, вице-президент Compaq Global Servises. С ним можно связаться по адресу: exchguru@win2000mag.com

Мониторинг виртуальной памяти

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

• Статья Microsoft "XADM: How to Gather Data to Troubleshoot Exchange Virtual Memory Issues" (http://support.microsoft.com/?kbid=317411) объясняет все действия, которые необходимо предпринять для получения информации о системе и решения проблем с виртуальной памятью.
• В статье Microsoft "Exchange Server 2003 and Virtual Memory Fragmentation" (http://support. microsoft.com/?kbid=822180) рассматриваются некоторые вопросы, связанные с изменениями в управлении фрагментацией памяти, реализованными Microsoft в Exchange 2003.
• Начиная с Exchange 2000 Server Service Pack 1 (SP1), в состав Exchange включен набор счетчиков производительности, в частности для наблюдения за виртуальной памятью кластера. В статье Microsoft "XADM: Monitoring for Exchange 2000 Memory Fragmentation" (http://support. microsoft.com/?kbid=296073) приводится описание этих счетчиков.

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

Поддержка дополнительных компонентов Exchange в составе кластеров