Программные продукты и системы

Высокопроизводительные кластерные системы (HPC – High-performance computing) используются в основном в научной среде для инженерно-научных расчетов. Для этой среды характерно применение технологий на основе свободно распространяемого ПО с открытым исходным кодом. Базовой ОС здесь является семейство ОС Linux. Суперкомпьютеры, размещенные в Институте математики и механики (ИММ) УрО РАН, работают под управлением двух близких разновидностей ОС Linux – RedHat 6.3 и Scientific Linux 6.3.

Существует альтернативное ПО для организации вычислительных кластеров высокой производительности [1]. Это продукты Microsoft Windows HPC Server и Microsoft HPC Pack (http://www.mic­rosoft.com/hpc/en/us/default.aspx). Использование этой ОС несколько снижает порог вхождения в суперкомпьютерные вычисления для пользователей невысокой квалификации. Вычислительный кластер, работающий под управлением этой ОС, обладает следующими специфическими возможностями:

-      пакетный запуск консольных (пакетных) приложений для ОС Windows (в первую очередь .NET приложений);

-      возможность отправки пакетных задач на выполнение прямо с рабочего места пользователя через оболочку Job Manager при помощи мастера (на английском языке);

-      набор средств встроенного в ОС Windows скриптового языка PowerShell для автоматизации формирования заданий, отправки их на выполнение, отслеживания состояния их выполнения и получения результатов вычислений;

-      возможность постановки заданий в очередь, просмотра очереди и получение результатов через веб-интерфейс на основе MS SharePoint;

-      возможность ускорения вычислений в среде MS Excel 2010 за счет распределения вычислительной нагрузки на узлы HPC Server 2008 при помощи XLL-макросов и возвращения результатов в Excel (интерактивные HPC вычисления);

-      возможность расширения кластера за счет узлов, получаемых из облака MS Windows Azure.

Двойная загрузка кластера

С вводом в строй в ИММ УрО РАН расширенного варианта суперкомпьютера «УРАН» появилась возможность выделения части аппаратных средств кластера предыдущего поколения МВС-ИММ (UM64) с целью проведения экспериментов.

Это позволит некоторым пользователям выполнять в пакетном режиме задачи, предназначенные для работы под управлением ОС MS Windows. Одним из таких экспериментов стало развертывание на нескольких выделенных узлах кластера ПО MS Windows Server 2008 R2 HPC Edition.

Основная задача развертывания состояла в отработке технологии двойной загрузки (Linux/Win­dows) физических узлов кластера и в обеспечении их миграции между логическими кластерами Linux/Windows.

Развертывание средств Windows Server 2008 R2 HPC Edition

Базовые принципы организации двойной загрузки описаны в [2, 3], однако каждая конкретная реализация имеет свои особенности. В данном случае это отсутствие подключения головного узла Linux к Application Network (рис. 1).

Перед установкой ПО на физический кластер выполнено пробное развертывание макета кластера на наборе виртуальных машин аналогично тому, как это описано в [4, 5].

Для развертывания Windows-кластера была выделена группа из 7 узлов кластера UM64 (один головной и 6 вычислительных узлов), каждый в следующей конфигурации:

-      два процессора Dual Core AMD Opteron™ Processor 285 (2,6 ГГц);

-      оперативная память 8 Гб;

-      два сетевых адаптера NetXtreme BCM5715 Gigabit Ethernet, один InfiniBand: Mellanox Techno­logies MT25204.

Ввиду того что дисковая подсистема должна обеспечивать возможность установки двух ОС (рис. 2), а минимальные требования для Windows HPC Server – 50 Гб, под экспериментальный сегмент кластера с двойной загрузкой были использованы узлы с емкостью дисков 150 Гб.

Для минимального ухудшения работоспособности из основной части Linux-кластера узлы исключались по одному. Сначала был установлен узел, предназначенный для развертывания ПО головного узла Windows-кластера. В описываемом сценарии с небольшим количеством узлов, добавляемых в Windows-кластер по одному, можно было обойтись полностью ручной установкой всего нужного ПО. Однако одной из задач была отработка технологии развертывания ПО на большой кластер, в связи с чем все работы для организации развертывания выполнены в автоматическом режиме. С этой целью были подготовлены файлы описания узлов кластера, преобразованные при помощи PowerShell-скрипта из данных, сохраненных на этих узлах, под ОС Linux (файл NodeConfi­gurationFile.xml). Так как на узлах должны быть установлены две различные ОС, был подготовлен файл описания C:\Program Files\Microsoft HPC Pack 2008\Data\InstallShare\Config\diskpart.txt для разбиения и распределения дисков, выполняющийся во время установки ОС Windows. Организован файл ответов автоматической установки ОС MS Windows (autounattend.xml), обеспечивающий установку значений таких параметров, как часовой пояс (правильная установка значения часового пояса важна, иначе узлы не смогут подключиться к контроллеру домена из-за несоответствия значения даты-времени на вновь установленной системе узла кластера и контроллере домена Active Directory) и локализации. Подготовлены драйверы устройств (в данном случае это драйверы SATA и InfiniBand) и дополнительное ПО (runtime library C++ MS Visual Studio 2010). Была также под- готовлена автоматическая установка пакета русификации (пакет многоязыкового интерфейса пользователя Windows Server 2008 R2 – Win­dows6.1-KB2483139-x64-ru-RU.exe), однако позднее выявлены проблемы, связанные с установкой этого пакета.

После подготовки всех необходимых файлов с помощью стандартного мастера HPC Pack создан образ ОС со всеми дополнительными компонентами для автоматической установки по сети.

Для данной установки требуется работающий на головной машине Windows-кластера DHCP-сервер. Таким образом, в Private Network оказываются два DHCP-сервера, выполняющихся одновременно (второй DHCP-сервер для Private Net­work выполняется на головной машине Linux-кластера). Для предотвращения конфликтов на обоих DHCP-серверах были зарезервированы IP-адреса для MAC-адресов узлов, входящих в соответствующую часть аппаратного кластера (Win­dows или Linux), и запрещена выдача адресов, отличных от выделенных. Заметим, что после установки ОС Windows на все узлы в случае, когда не планируется добавление новых узлов с автоматической установкой ОС по сети, сервер служб развертывания Windows и DHCP-сервер, обслуживающий Private network, могут быть остановлены. Для Application Network на основе Infiniband в Windows-кластере DHCP-сервер сохраняется, так как в отличие от Linux-кластера поверх Infiniband используется и протокол TCP/IP.

После установки необходимого ПО на все узлы Windows-кластера была выполнена проверка его работоспособности. В ходе опытной эксплуатации Windows-кластера были выявлены некоторые недостатки.

·       Проблема удаления с последующим возвращением узла в кластер. Если удалить узел из кластера, а потом опять попытаться добавить его с тем же именем (никаких аппаратных изменений в узел не вносилось), то не удастся установить на узел Template с ОС. То есть для узла нужно будет сгенерировать новое имя. ·       Проблема русификации. По умолчанию интерфейс системы англоязычный. Если установить пакет русскоязычного интерфейса на узлы клас- тера и включить русский как язык пользовательского интерфейса, Cluster Manager перестает отображать информацию о состоянии таких узлов. Задания на узлах, несмотря на это, запускаются и выполняются. Если на вычислительном узле вернуть английский как язык интерфейса, отображение состояния этого узла восстанавливается.

Установка Linux второй системой на узлы кластера

Наличие двух DHCP-серверов создает проблему для автоматической установки Linux как второй системы на узлы с уже установленной ОС MS Windows. Механизм загрузки по сети при получении нескольких ответов от DHCP-серверов завершался с ошибкой безопасности. Для оперативной автоматической установки Linux простейшее решение – выключение головного узла Windows-кластера, на котором выполняется DHCP-сервер.

Для переключения вычислительного узла между логическими кластерами требуется загрузка соответствующей ОС. Были рассмотрены следующие подходы к организации выбора ОС:

–      чередование; при очередной перезагрузке узла будет загружена ОС, отличная от только что использованной; например, если узел кластера работал под управлением ОС Windows, то при очередной перезагрузке на нем запустится ОС Linux, и наоборот, в случае перезагрузки узла, работающего под управлением ОС Linux, на нем будет запущена ОС Windows;

–      выбор загружаемой системы оператором на этапе загрузки и запуск последней использовавшейся ОС при долгом отсутствии нажатий на клавиши;

–      создание общего загрузочного раздела и выбор запускаемой ОС путем записи в файл на этом диске;

–      загрузка по сети с выбором загружаемой ОС DHCP-сервером.

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

Выбор загружаемой системы оператором неудобен и трудоемок для него, особенно, если смена ОС производится достаточно часто.

Создание общего загрузочного раздела требует, чтобы формат файловой системы (ФС) на нем поддерживался обеими ОС. К сожалению, данному критерию удовлетворяют только ФС семейства FAT, но их использование усложняет автоматическое развертывание ОС, так как использование FAT в качестве загрузочного диска требует установки нестандартного загрузчика, который не поддерживается популярными дистрибутивами Linux. Использование других файловых систем требует установки экспериментальных драйверов, которые обычно находятся в состоянии, не пригодном для серьезного использования.

Поэтому был выбран подход, связанный с загрузкой по сети, как наиболее простой для администрирования и развертывания.

Выбор ОС при загрузке по сети

Отвечающий на запросы о загрузке по сети DHCP-сервер расположен на головном узле Linux-кластера, как и TFTP-сервер с файлами, необходимыми для сетевой загрузки.

В ПЗУ сетевых карт современных компьютеров имеется PXE-код. Получив управление при старте системы, этот код запрашивает настройки сети и адрес TFTP-сервера у DHCP-сервера по протоколу BOOTP, получает оттуда исполнимый файл и передает ему управление. В качестве такого файла в рассматриваемом решении используется pxelinux – одна из самых популярных реализаций загрузчика, которая позволяет передавать управление ядру Linux, загрузив его с того же TFTP-сервера. При запуске pxelinux считывает свой файл конфигурации, в котором описан механизм загрузки конкретных ОС.

Для выбора ОС используется следующий конфигурационный файл DHCP-сервера:

group {

filename "um64_win/pxelinux.0";

host umu18 {hardware ethernet 00:18:F3:4E:5D:59;

fixed-address 192.168.1.18; }

host umu19 {hardware ethernet 00:18:F3:4E:5D:43;

fixed-address 192.168.1.19; }

}

group {

filename "um64_linux/pxelinux.0";

host umu20 {hardware ethernet 00:18:F3:4E:5D:39;

fixed-address 192.168.1.20; }

host umu21 {hardware ethernet 00:18:F3:4E:5E:21;

fixed-address 192.168.1.21; }

host umu22 {hardware ethernet 00:18:F3:4E:5D:79;

fixed-address 192.168.1.22; }

host umu23 {hardware ethernet 00:18:F3:4E:5E:33;

fixed-address 192.168.1.23; }

}

В данном примере um64_win/pxelinux.0 и um64_linux/pxelinux.0 – это пути к исполняемым файлам, рассмотренным выше. В каталоге um64_win в конфигурационном файле описана загрузка с ОС Windows, а в um64_linux – с ОС Linux. То есть в данном примере на узлах umu18 и umu19 будет загружаться ОС Windows, а umu20, umu21, umu22, umu23 – Linux.

Таким образом, чтобы изменить ОС, загружаемую на узле, нужно переместить соответствующую узлу строку в другую группу и перезапустить DHCP-сервер или оповестить его об изменении конфигурационного файла.

При загрузке Linux с TFTP-сервера загружаются ядро и образ начальной файловой системы (initrd), за счет чего обеспечивается постоянство версий ядра Linux на узлах, облегчаются переход на ядра новых версий и откат в предыдущее состояние, если, например, узлы перестают загружаться с новым ядром.

При загрузке ОС Windows HPC Server управление передается загрузчику, находящемуся непосредственно на жестком диске узла кластера.

Для переключения узлов подготовлен набор скриптов, выполняющих определенные операции.

·       Скрипт № 1 переносит узлы из группы Windows узлов в группу Linux (редактирует файл dhcpd.conf).

·       Скрипт № 2 выполняет обратную операцию – переносит узлы из группы Linux в группу Windows (редактирует файл dhcpd.conf).

·       Скрипт № 3 маскирует узлы во всех группах (помечает как комментарий) для того, чтобы на такие узлы можно было произвести по сети установку ОС MS Windows (редактирует файл dhcpd.conf).

·       Скрипт № 4 выполняет операцию, обратную действиям, выполняемым скриптом № 3 (редактирует файл dhcpd.conf).

·       Скрипт № 5 выдает информацию о текущем распределении узлов по группам.

·       Скрипт № 6 запускает перезагрузку на Linux-узлах кластера.

Данные скрипты выполняются на головном узле кластера под управлением ОС Linux (UM64). Все они имеют один входной параметр – список узлов, для которых должна быть выполнена запрошенная операция.

Для переключения узлов между системами с головной машины Windows-кластера (UM64W) подготовлен скрипт PowerShell, имеющий два параметра. Первый – список узлов, над которыми должна быть выполнена операция, и второй – имя операции. В соответствии с указанной операцией PowerShell-скрипт по протоколу SSH вызывает соответствующий скрипт на головной машине Linux-кластера (UM64). В случае перемещения узлов из Windows-кластера в Linux скрипт тоже выполняет соответствующие стандартные командлеты Windows HPC, переводящие указанные в списке узлы в состояние offline и запускающие перезагрузку этих узлов (Set-HpcNodeState и Restart-HpcNode). Для доступа к головной машине Linux и вызова на ее стороне управляющих скриптов на головной машине Windows используется набор командлетов SSH from PowerShell (http://www.powershelladmin.com/wiki/SSH_from_PowerShell_using_the_SSH.NET_library), построенный на основе библиотеки SSH.NET (http://sshnet. codeplex.com/).

В настоящее время переключение узлов между кластерами, работающими под управлением различных ОС, оператор выполняет вручную.

В заключение отметим, что осуществлена модернизация кластера, обеспечившая возможность одновременной работы двух ОС (Linux и Win­dows) на одном физическом кластере за счет выделения каждой ОС своего подмножества узлов.

Литература

1.     Келбли Дж., Линдси Д. Введение в Windows Compute Cluster Server // TechNet Magazine. 2008, февраль. URL: http://technet.microsoft.com/ru-ru/magazine/2008.02.ccs.aspx (дата обращения: 01.09.2012).

2.     A Hybrid OS Cluster Solution: Dual-Boot and Virtualization with Windows HPC Server 2008 and Linux Bull Advanced Server for Xeon. Published: October 7, 2009, Dr. Patrice Calegari, HPC Application Specialist, BULL S.A.S., Thomas Varlet, HPC Technology Solution Professional, Microsoft. URL: http://technet.microsoft.com/en-us/library/ee621813(v=ws.10).aspx (дата обращения: 26.08.2012).

3.     The Windows HPC Server 2008-based Cluster in a Linux Environment. URL: http://go.microsoft.com/fwlink/?LinkId= 135931 (дата обращения: 26.08.2012).

4.     Русский блог по разработке для HPC. Развертывание Windows Server 2008 HPC в виртуальной среде. Ч. 1: Установка и настройка головного узла. URL: http://blogs.msdn.com/b/ru-hpc/archive/2009/09/11/windows-server-2008-hpc-1.aspx (дата об­ращения: 26.08.2012).

5.     Русский блог по разработке для HPC. Развертывание Windows Server 2008 HPC в виртуальной среде. Ч. 2: Установка и настройка вычислительных узлов. URL: http://blogs.msdn. com/b/ru-hpc/archive/2009/09/12/windows-server-2008-hpc-2.aspx (дата обращения: 26.08.2012).

6.     Integrating a Windows HPC Server 2008 Cluster into a Linux Environment, Microsoft Corp. Publ., 2008, September.

References

1.     Kelbley J., Lindsey D. An Introduction to Windows Compute Cluster Server. TechNet Magazine. 2008, Feb. Available at: http://technet.microsoft.com/en-us/magazine/2008.02.ccs.aspx (accessed 01 September 2012).

2.     A Hybrid OS Cluster Solution: Dual-Boot and Virtualiza­tion with Windows HPC Server 2008 and Linux Bull Advanced Server for Xeon, 2009, available at: http://technet.microsoft.com/ en-us/library/ee621813(v=ws.10).aspx (accessed 26 August 2012).

3.     The Windows HPC Server 2008-based Cluster in a Linux Environment, available at: http://go.microsoft.com/fwlink/?LinkId= 135931 (accessed 26 August 2012).

4.     Russkiy blog po razrabotke dlya HPC. Razvertyvanie Windows Server 2008 HPC v virtualnoy srede, chast 1: ustanovka i nastroyka golovnogo uzla [Russian blog about developing for HPC, part 1: installation and configuration of a headend]. Available at: http://blogs.msdn.com/b/ru-hpc/archive/2009/09/11/win­dows-server-2008-hpc-1.aspx (accessed 26 August 2012).

5.     Russkiy blog po razrabotke dlya HPC. Razvertyvanie Windows Server 2008 HPC v virtualnoy srede, chast 2: ustanovka i nastroyka vychislitelnykh uzlov [Russian blog about developing for HPC, part 2: installation and configuration of computational nodes], available at: http://blogs.msdn.com/b/ru-hpc/archive/2009/09/12/ windows-server-2008-hpc-2.aspx (accessed 26 August 2012).

6.     Integrating a Windows HPC Server 2008 Cluster into a Linux Environment Microsoft Corporation, 2008.