Оптимизация производительности путем равномерного распределения ресурсов

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

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

Мы сделали выводы и решили автоматизировать процесс обслуживания. Я подготовил два сценария управления ресурсами кластера (Cluster Resource Management, CRM), чтобы сначала собрать полную информацию о текущем распределении ресурсов, а потом восстановить его. Первый сценарий собирает информацию о владельце кластерного ресурса до начала обслуживания. Второй сценарий запускается после окончания технического обслуживания и возвращает ресурсы узлам, которым они первоначально принадлежали.

Cluster Automation Server

В результате исследований удалось выяснить, что объект ActiveX Cluster Automation Server компании Microsoft располагает методами и свойствами, необходимыми для управления ресурсами кластера. Пакет администрирования кластера устанавливает Cluster Automation Server, Msclus.dll. Серверный объект автоматизации кластера верхнего уровня обеспечивает полный интерфейс управления кластером для языков сценариев. Используя методы и свойства, связанные с каждым объектом Cluster Automation Server, можно составить сценарии или приложение для автоматизации задач администрирования кластера, таких как сбор информации о статусе ресурсов, перемещение групп ресурсов из одного узла в другой или блокирование ресурса. С помощью сценария администратор кластера может подключиться к кластеру или узлу локально либо дистанционно. В этих объектах используются API кластеризации Windows Server 2003, Windows 2000 Server и Windows NT. Объекты можно найти по адресу в сети Microsoft Developer Network (MSDN). Более подробную информацию о Cluster Automation Server можно получить по адресу.

Следует выяснить, какой объект располагает методами и свойствами для решения задачи. Затем нужно определить, как получить объект и вызвать необходимое для решения задачи свойство или метод объекта. Пример использования свойств или методов объекта Cluster Automation Server можно найти по адресу.

Сбор информации о ресурсах

Нам нужно было назначить права владения каждой группой ресурсов на первичном сервере, а после завершения профилактики сервера вернуть группы ресурсов на первичный сервер. При перемещении ресурсной группы перемещаются и содержащиеся в ней ресурсы. Объект MSCluster.Cluster располагает объектом сбора групп ресурсов, свойствами, такими как OwnerNode.Name, и методами, в частности Move, для управления ресурсами.

Опытным путем я нашел полезную процедуру диагностики программного кода: оператор Option Explicit используется для объявления каждой константы и переменной в сценарии. Оператор необходимо разместить в первой строке сценария. Соответственно сценарий в листинге 1 начинается с объявления имени системы, для которой запускается сценарий. Сценарий можно усовершенствовать, заменив жестко заданное имя системы запросом к пользователю, который должен ввести имя компьютера во время выполнения сценария. После объявления констант и переменных в листинге 1 создается объект FileSystemObject библиотеки Microsoft Scripting Runtime Library. Затем применяется метод CreateTextFile объекта, чтобы сформировать файл журнала (clusterstate.log) как объект TextStream. В файле журнала хранится информация обо всех текущих ресурсах машины. Дополнительную информацию о FileSystemObject можно получить по адресу.

Фрагмент исходного текста с меткой A в листинге 1 создает экземпляр объекта MSCluster.Cluster. Затем исходный текст с меткой B использует этот объект для организации соединения с выбранным узлом кластера, вызывая метод Open кластерного объекта с константой ComputerName. Этой константе присваивается значение пустой строки. В данном случае метод Open автоматически ссылается на параметры кластера на локальной машине. Для соединения с машиной, отличной от локального компьютера, необходимо отредактировать листинг и присвоить другое значение константе ComputerName.

Если при применении метода Open не произойдет ошибки, соединение с компьютером будет установлено. Фрагмент исходного текста с меткой C составляет список групп ресурсов в каждом узле кластера. Для всех групп ресурсов записывается имя каждого ресурса, содержащегося в данной ресурсной группе, вместе с именем узла-владельца. Затем, используя метод WriteLine объекта TextStream, сценарий записывает эту информацию в текстовый файл каждого ресурса в каждой группе ресурсов. После того как вся информация о ресурсах будет записана в текстовый файл с разделением запятыми (экран 1), сценарий закрывает текстовый файл, освобождает память и завершает работу.

Восстановление принадлежности ресурсов

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

Как показывает фрагмент с меткой A в листинге 2, сценарий обращается к объекту FileSystemObject. Входной файл с именем clusterstate.log — обязательное условие для восстановления ресурсов, назначенных узлу кластера. Поэтому, прежде чем открыть текстовый файл для чтения, сценарий проверяет существование входного файла, вызывая метод FileExists объекта FileSystemObject. Если входного файла не существует, сценарий выдает сообщение об ошибке в консоль, а затем завершает работу. При наличии входного файла сценарий генерирует экземпляр кластерного объекта и устанавливает соединение с локальной машиной, как показано во фрагменте с меткой A. Кластерный объект создается до прочтения входного файла, поэтому цикл повторного создания объекта не образуется.

Если входной файл существует, то он открывается и начинается построчная обработка текстового файла в операторе Do...Loop. Цикл продолжается до конца файла, отмеченного свойством AtEndOfStream объекта TextStream (фрагмент с меткой B).

Данные хранятся в текстовом файле с разделением запятыми, поэтому в листинге 2 используется метод VBScript Split для разделения имени ресурса и имени узла — владельца ресурса. Метод Split хранит разделенные данные в строковом массиве. Первый элемент в массиве arrLine листинга 2 представляет собой имя ресурса, а второй элемент — имя узла.

Теперь данные представлены в нужном формате и можно переместить ресурсы в узлы, которым они первоначально принадлежали. Свойство ResourceGroup объекта MSCluster. Cluster возвращает объект-набор ClusResGroups. Свойство Item объекта-набора возвращает объект ClusResGroup, который представляет одну группу в этом наборе. Метод Move объекта ClusResGroup перемещает ресурсы группы, как показано во фрагменте с меткой C.

Метод Move поддерживает два параметра: Timeout и ClusterNode. Timeout показывает время в секундах, которое должно пройти, прежде чем процесс присвоит очередной переменной значение True. ClusterNode — имя узла, на который нужно переместить группу ресурсов. Это необязательный параметр. Дополнительная информация о методе Move приведена по адресу.

В данном сценарии необходимо переместить группу ресурсов в определенный узел. Поэтому в листинге 2 узел передается как параметр. Однако если информация об узле в сценарии отсутствует (например, не передана в качестве параметра), то метод Move перемещает группу ресурсов в наиболее подходящий доступный узел в соответствии со следующими критериями:

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

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

Завершающие штрихи

Пройдя по обычным для компании этапам внедрения продукта — среда разработки, инфраструктура, тест пользовательского одобрения (user acceptance test, UAT), мои CRM-сценарии были наконец внедрены в производство. Лучшая награда для автора — видеть, как его сценарий успешно применяется на практике. Специалисты по внедрению сообщили, что в результате применения описанных CRM-сценариев никаких проблем не возникло. Администраторы кластеров были довольны, что работа, которую им приходится выполнять при подготовке и после завершения технического обслуживания, сведена к двойному щелчку мышью.

Однако мы хотим избавиться даже от двойного щелчка. С этой целью мы автоматизировали процесс обслуживания с помощью пакета Remote Deployment Pack (RDP) компании HP. Более подробную информацию об RDP можно найти по адресу. Благодаря использованию RDP появилась возможность автоматизировать такие задачи, как дистанционное получение образов серверов и дистанционное развертывание исправлений. Как известно, чем выше уровень автоматизации, тем больше сценариев, и я надеюсь, что в будущем меня ждет интересная работа.

Бобби Малик - Cтарший консультант по Windows NT и Citrix, шт. Нью-Джерси. Работает в отрасли более десяти лет, в том числе пять лет с платформами Windows. bmalik@adminscripts.net