С момента своего первого появления в 1998 году в списке 500 самых быстрых компьютеров в мире Linux-кластеры прошли путь от неясного научного эксперимента до доминирующей силы в технологии суперкомпьютерных вычислений. При этом количество Linux-кластеров в списках Top 500 выросло от одной системы в 1998 году (1 кластер, 1 система под Linux) до четырех пятых списка в 2008 г. (400 кластеров, 458 систем под Linux).

Управление кластерами Linux требует уникального набора навыков, которые обычно не встречаются среди ИТ-администраторов локальных систем или маленьких сетей — оно требует всестороннего знания работы с сетями, операционных систем и практически всех подсистем архитектуры.

Но это ещё не все: здесь требуется другое отношение — и прежде всего лень. От администратора здесь требуется то, чего Скрудж Мак-Дак из Дакбурга требовал от своих племянников: "Не надо работать больше, надо работать с умом."

В этой статье мы обсуждаем некоторые из самых ценных секретов самых ленивых администраторов Linux-кластеров. Хотя назвать их "секретами" можно лишь с большой натяжкой, по каким-то причинам широкая публика или не понимает, или недооценивает реальную отдачу от применения этих идей. Чтобы прояснить вопрос, перечислим эти секреты и объясним их значение.

Вот они:

1. Не изобретайте колесо.
2. Используйте ПО с открытым исходным кодом.
3. Автоматизируйте все.
4. Рассчитывайте на перспективу масштабирования — планируйте быть ленивым с самого начала.
5. Планируйте с учетом аппаратной управляемости.
6. Используйте хорошее кластерное программное обеспечение — не надо рыть колодец чайной ложкой.
7. Используйте открытые решения мониторинга.
8. Управляйте своими пользователями с помощью планировщиков.
9. Проверьте, что вы получаете всё, за что платите, — тестируйте производительность!
10. Организуйте обмен информацией
11. Ищите способы стать ещё более ленивым.

1. Не изобретайте колесо

Ленивый администратор Linux-кластера не занимается созданием колеса; он предпочитает пользоваться чужими трудами. Нет смысла напрасно тратить время на создание приложения с нуля, когда уже существует бесплатно поддерживаемое решение.

Оригинальная идея или оригинальная проблема — большая редкость, особенно в мире Linux-кластеров. Редко можно столкнуться с чем-то, с чем не боролись и для чего не придумали решения ещё в 2004 году. Это не повод чувствовать себя незначительным или неоригинальным; скорее наоборот, потому что не существует такой проблемы, которая не может быть решена (говоря технически, а не политически или социально). Так что лучше принять как должное тот факт, что большинство проблем уже известны, диагностированы, и решены.

Чтобы не тратить впустую время, эффективный администратор потратит его на:

• Поиск существующих решений и адаптацию их к его собственным нуждам. Цитируя Бернарда Шартрского, Исаак Ньютон отмечал, что в своей работе стоял "на плечах гигантов". Подумайте, что потеряло бы человечество, если бы Ньютон сначала не пытался понять Евклидовы "Начала" и не выстроил затем свою систему на этой основе.
• Внесение вклада или специфическую настройку проектов с открытым кодом вместо того, чтобы повторно изобретать то, что уже существует — очень хорошо понимая, что если он напишет что-то с нуля, то всё пойдёт прахом после того, как он сменит работу, потому никто этого больше не поймёт.

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

2. Используйте ПО с открытым исходным кодом

Самые успешные администраторы Linux-кластеров, с которыми мы работали, отлично ориентируются в текущих проектах с открытым кодом. Они постоянно присутствуют в рассылках, и поиск в Интернете покажет, что они отмечаются и в текущих проектах. В поисках новых интересных проектов они обычно посещают сайты http://sourceforge.net и http://freshmeat.net.

Инструментам с открытым исходным кодом, особенно популярным, присущи свойства, позволяющие им переживать даже своих авторов. Есть очень серьезные причины для того, чтобы такие инструментальные средства, как Ganglia, Nagios и TORQUE, продолжали активно использоваться несмотря на то, что они известны уже довольно давно. Это прекрасные инструменты — они экономят затраты на администрирование, на новые программы и на схемы лицензирования.

Ещё одна черта, присущая сам ленивым администраторам кластеров — они очень преданно относятся к открытому ПО и используют его в личных целях, будь то домашний Web-сервер или приложения на личных ноутбуках под Linux. От Pidgin до Firefox — самые ленивые администраторы Linux используют Linux везде, а не только на работе в кластерах, которыми они управляют.

3. Автоматизируйте все

Использование скриптов в консоли и прочая автоматизация — вот основной инструментарий администратора Linux. Применение скриптов (если только это не изобретение колеса) обеспечивает две полезныех вещи:

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

У квалифицированных администраторов часть имеются каталоги, заполненные написанными ими собственноручно скриптами. Эти скрипты делают все: от проверки версий встроенного программного обеспечения на узлах до преобразования GUID в кластере InfiniBand.

Примером, где применение скриптов весьма уместно, является создание образа операционной системы, будь то изменяемый образ (stateful) или неизменяемый (stateless). Если у администратора есть "золотой образ", который необходимо скопировать на каждый вычислительный узел в системе, он должен знать его содержимое. Скрипт, создающий этот образ — лучшая доступная документация, поскольку чётко объясняет то, что делает, и его можно запускать повторно. Без скриптов для их создания образы неконтролируемо размножаются, съедая дисковое пространство и замедляя работу системы.

Мы нередко встречаем организации с "золотым образом", который сохраняется с 2000 года. Чаще всего - потому, что неизвестно, как его изменить. А вторая и, вероятно, главная причина: определённое приложение было протестировано и "сертифицировано" на этом образе. Сертифицировано — это один из тех терминов, на которые мы постоянно натыкаемся, и который столь же туманен, как и определение облачных вычислений, "cloud computing" (которое, кстати, не является ни запатентованным термином, ни официально зарегистрированным товарным знаком).

Главный секрет того, зачем нужна автоматизация, кроется в следующем: здесь требуется более мощное мозговое усилие для того, чтобы избавиться от работы, чем для того, чтобы фактически выполнить её. Ленивый администратор Linux-кластера не рад работе, которая отупляет мозг. Заходить по ssh на каждую машину в кластере, чтобы выполнить команду — это годится только для недостаточно ленивых администраторов. Все команды для узлов надо подавать одним движением, с использованием параллельных команд или процедур. Если у вашего поставщика аппаратного обеспечения нет инструментальных средств под Linux для автоматизации обновлений BIOS или прошивок подсистем — учтите это в смете расходов.

4. Рассчитывайте на перспективу масштабирования - планируйте быть ленивым с самого начала

Совет номер 3 ("автоматизируйте, автоматизируйте, автоматизируйте!") — прекрасная цель, но это только один шаг на пути к абсолютному безделью. Для самых ленивых администраторов абсолютное безделье может быть достигнуто только с применением автономного управления горизонтальным масштабированием. Первый шаг на пути к решению этой задачи - система, неуязвимая для немасштабируемых операций.

Очень большие горизонтально масштабируемые кластеры изобилуют узкими местами. Например, большинство администраторов масштабируемых систем использует TFTP для сетевой начальной загрузки или установок на большое количество машин. Как скажет вам любой опытный администратор, имеющий дело с масштабированием, TFTP ненадежен и не масштабируем. В отсутствие хорошо настроенного удаленного управления аппаратными компонентами масштабный отказ TFTP может заставить ленивого администратора буквально встать со стула (из кровати) и дойти (или доехать) до вычислительного центра (не до дома!), чтобы перезагрузить каждую машину (какая прорва работы)! Даже при хорошо настроенном удаленном управлении аппаратными компонентами ленивому администратору придётся надолго прервать игру в WoW для того, чтобы периодически вводить команды (опять работа!) для перезагрузки узлов и поднятия системы.

При некотором предварительном планировании узких мест (описанных ниже) можно избежать.

Узкое место №1: службы развертывания

DHCP, TFTP, HTTP, NFS, и DNS — эти службы наиболее часто используются для развертывания кластеров. У каждой из них есть порог, и TFTP — наихудшая из них во всём том, что касается масштабирования. К счастью, все эти службы легко дублируются, что облегчает масштабирование.

Совет: перевод DHCP и TFTP на отдельный выделенный сетевой контроллер резко увеличивает масштабируемость. Например, по нашим измерениям, для TFTP, работающего на одном сетевом контроллере с другими службами развертывания, масштабируемость была равна 40:1, и 80:1 — без совместной работы с другими службами или при stateless-загрузке.

Узкое место №2: сеть

Сетям зачастую уделяется меньше всего внимания при проектировании. Мы имеем в виду сети GigE, используемые для управления, а не специализированные высокопроизводительные сети для передачи трафика приложений. Хотя во многих случаях существует только одна сеть, используемая и для передачи данных и для управления, что может усложнить задачи масштабирования еще больше.

Будьте внимательны, проектируя иерархические сети, избегайте превышения допустимой нагрузки на службы. Если требуемое соотношение узлов и сервисных узлов равно 80:1, следите за тем, чтобы оно соблюдалось или же превышалось повсюду.

Узкое место №3: не откусывайте больше, чем сможете проглотить

При проектировании крупномасштабных кластеров мы применяем подход "кластер из кластеров". Каждый подкластер или масштабируемый модуль ММ ("scalable-unit", SU) является строительной единицей, которая масштабируется в собственных пределах во всех кластерных операциях (например, установка, сетевая загрузка, прошивка BIOS, мониторинг и т.д.). У каждого ММ есть один или более (в зависимости от его размера) сервисный узел, обеспечивающий службы, необходимые для контроля, мониторинга и развертывания всех узлов модуля. Для дальнейшего облегчения масштабируемого управления каждый модуль располагает своим собственным широковещательным доменом (связи "модуль-модуль" и "модуль-внешний мир" маршрутизируются, так что их необходимо проверить на узкие места).

У центрального узла управления и сервисных узлов есть частная физическая или виртуальная сеть, чтобы агрегация информации с сервисных узлов и отправка на них данных не конкурировала с другим кластерным трафиком. Мы называем эту сеть, узел управления и сервисные узлы облаком иерархического управления ("hierarchal management cloud", HMC). Его настройка и работа находятся исключительно в ведении администраторов.

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

5. Планируйте с учетом аппаратной управляемости

Можно только подивиться числу администраторов, которые не следуют принципам настройки «втемную», проектируя свои кластеры. Кластеры эффективных администраторов располагаются в темных комнатах вдали от человеческого присутствия, и в идеале могут пройти недели или месяцы, прежде чем им может действительно понадобиться взглянуть на физические машины, с которыми они ежедневно работают. В отдельных случаях они их никогда не увидят, потому что управляют ими с противоположной стороны земного шара. И конечно, самые ленивые даже не знают, где именно расположен этот вычислительный центр, для них это только набор имен узлов или IP-адресов.

В вычислительных центрах шумно и иногда холодно (и, кто знает, возможно, ещё и опасно!); ленивому администратору следует избегать их любой ценой. Кто знает, какой пока еще неизвестный вред здоровью наносит пребывание в комнатах с большим количеством компьютеров! По мере повышения затрат на энергию/охлаждение/обслуживание растут тенденции по перемещению вычислительных центров в менее дорогие в эксплуатации помещения. Ввиду этого наличие абсолютного удалённого управления следует расценивать как необходимую основу для управления кластером Linux сейчас и в обозримом будущем.

Поставщики оборудования в значительной степени учли пожелания клиентов касательно стандартов удалённого управления системами. IPMI 2.0 стал текущим стандартом для большинства управляемых Linux-кластеров. IPMI дает возможность удалённо включать и отключать питание машины, а также предоставляет удаленный терминал для просмотра начальной загрузки машины из BIOS. Однажды нам удалось решить проблему на машине, которая находилась за 60 миль от нас, сидящих в комфорте офиса одного нашего клиента. (Клиент был одним из тех ленивых администраторов Linux, чей офис освещается только неоновой вывеской на стене. Его преобразованная в контору холостяцкая берлога была также оборудована двумя холодильниками, загруженными энергетическими напитками и сладкими закусками. Само собой разумеется, мы не захотели покидать этот офис).

IPMI — необычайно мощный инструмент: мы изменили параметры настройки BIOS, перезагрузили узлы, пронаблюдали за процессом загрузки и просмотрели экранный дамп, даже не видя самой машины — как и должно быть на всех кластерах. Минимальные требования тут следующие:

• Возможность удаленного включения машин и
• Наличие удаленного терминала или улучшенного просмотра машин для наблюдения за возможными проблемами при загрузке.

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

Всё ещё остающимся открытым для обсуждения вопросом остаётся зависимость IPMI от удаленного терминала. Мы признаём, что есть случаи, когда реальный внешний терминальный сервер для управления по выделенному каналу может быть полезен. Терминальные серверы, подобные Cyclades ACS48, — это всё ещё разумная инвестиция, обеспечивающая доступ по выделенному каналу и надежность на таком уровне, который пока ещё не доступен для IPMI.

Кроме того, по нашему скромному мнению, IPMI версии 1.5 был не самым надежным (и это представляло общеотраслевую проблему). IPMI 2.0 работает намного лучше, и многие поставщики обвешивают его красивыми Web-страницами, чтобы он казался еще более «выделенным». Есть аргументы как за использование терминальных серверов, так и против них и просто за использование встроенного в машины IPMI. Большинство наших клиентов рассуждают примерно таким образом: каждый ленивый администратор Linux знает, что тратит много времени на решение проблем, возникающих на 5% узлов, в то время как оставшиеся 95% работают прекрасно. В таком случае может быть лучше просто докупить 5% узлов вместо того, чтобы тратиться на инфраструктуру, и держать их в качестве резерва. В итоге бюджет будет тратиться больше на вычислительную мощность, чем на инфраструктуру.

В качестве контраргумента можно сказать, что если с помощью одного терминального сервера можно сэкономить на авиаперелёте через всю страну для решения проблемы, то затраты стоят этого. Пусть ленивый Linux-администратор позвонит нам — в конце концов, это ему придется сесть на самолет. Мы слышали убедительные аргументы с обеих сторон.

6. Хорошее кластерное программное обеспечение — гарантия того, что вам не придётся рыть колодцы чайными ложками

Кластерные инструментальные средства проделали длинный путь с тех пор, как мы начали устанавливать Linux-кластеры в 1999 году. В те времена существовало немного доступных программных средств для управления кластерами, и в силу этого многие администраторы создавали свои собственные комплекты инструментальных средств, которые развертывали кластеры, производили мониторинг и управляли ими.

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

Если вы не удовлетворены своим самодельным инструментарием или ищете что-нибудь получше, рассмотрите возможность использования инструментальных средств с открытым исходным кодом. Среди самых распространенных программ — OSCAR (клонирование систем), ROCKS, Perceus и любимый лично нами xCAT 2. Всё это — программы с открытым исходным кодом.

Возможно, самое популярное на сегодня решение по развертыванию/управлению кластерами среди программ с открытыми исходными кодами — это ROCKS. ROCKS разрабатывается и поддерживается в Калифорнийском университете Сан-Диего (UCSD), и его авторы хорошо поработали, чтобы сделать кластеры более дружественными к пользователю. Единственное, в чём мы можем упрекнуть эту программу — это недостаточная гибкость, прежде всего на уровне ОС. ROCKS основан на Red Hat, который подходит для многих, но только не для тех, кто использует SUSE или хотел бы использовать образы, созданные на основе дистрибутивов RH 6.2. Кроме того, мы редко встречаем ИТ-организации, которые используют ROCKS в качестве решения для клонирования.

Ещё одно подобное решение — Perceus. Отличие его от ROCKS, в том, что это — не "stateless" инсталляция. В контексте этой статьи "stateless" означает операционную систему, работающую только в памяти, без записи на диск. Диск не требуется, но может использоваться как локальное хранилище или как файл подкачки.

Что нам нравится в xCAT, кроме того, что мы заинтересованы в нём лично (скажем, не скрываясь: мы пишем код и принимаем активное участие в развитии xCAT)? xCAT более гибок, лучше масштабируется и гораздо мощнее, чем любая другая подобная программа. (И у него самые симпатичные и эрудированные разработчики). Самый быстрый суперкомпьютер на земле, система LANL RoadRunner (гибрид Cell/B.E.™ и Opteron™ , который является первой системой и первым кластером под управлением Linux, чья производительность превысила один петафлопс), управляется с помощью xCAT.

С помощью xCAT можно создавать образы системы, использовать kickstart, autoyast, iscsi и stateless почти в любых разновидностях корпоративного Linux. Кроме того, у xCAT есть инструментальные средства командной строки, абстрагирующие команды IPMI, начиная от удаленного включения до настройки консоли, и использующие их в одной и той же инфраструктуре. xCAT активно разрабатывается с 31 октября 1999 года, а его исходные тексты были открыты IBM в 2007 году.

Справедливости ради упомянем также и о недостатках xCAT:

• Возможны трудности с настройкой; большая гибкость даёт в результате огромное количество возможных настроек. Для облегчения задачи мы создали вики-ресурс; также оказывается широкая поддержка в почтовой рассылке и на нашем IRC-канале.
• XCAT 2 — это полностью переписанный старый добрый xCAT 1.3, в связи с чем кое-что ещё необходимо выпрямить.
• Как это часто случается в мире открытого ПО, документация могла бы быть лучше.

Существует множество других кластерных решений, и мы вполне могли бы открыть тут дебаты в духе Emacs против vi , но в заключение просто скажем: если вам нужны свежие идеи или что-либо получше — попробуйте xCAT.

7. Используйте открытые решения мониторинга

В прошлом году на конференции SC'07 мы встречались с представителями нескольких ведущих лабораторий США, чтобы обсудить сложную проблему мониторинга Linux-кластеров. Это привело к множеству визитов в начале 2008 года для дальнейших обсуждений. Мониторинг затрудняется несколькими причинами:

• По мере увеличения размера кластера увеличивается и объём собираемых данных, что может привести к перегрузке машины, получающей данные мониторинга. Скажем, если у нас 2000 машин и каждая посылает контрольные показатели на инфраструктурный узел, то этот узел может быть буквально поставлен на колени, а вам останется только гадать, отвечает ли он вообще
• Сбор данных агентами на вычислительных узлах может "высасывать" память и ресурсы процессора из текущих пользовательских задач. Во многих вычислительных центрах обходятся без агентов узлов, потому что это понижает производительность приложений. Нахождение баланса требует компромисса: стоят ли полученные данные затрачиваемых ресурсов процессора?
• Нам не встречался такой масштабируемый инструмент, который привязывал бы пользовательские задания к производительности машины и который профилировал бы задания удобным и визуально привлекательным способом.
• Не существует таких инструментальных средств, которые делали бы всё точно так, как нам хотелось бы. И больше всего в данной области бросается в глаза то, что используемые инструментальные средства не закончены и не в состоянии выполнять хотя бы одну функцию, которая нужна всем. Большинство администраторов использует комбинацию из одной или двух программ. Мы скептически относимся к программам, которые обещают вести мониторинг вашего кластера так, что превзойдут все другие существующие решения: все кластеры разные, и универсального решения не существует. Настраиваемый мониторинг кажется единственным выходом из этой ситуации.

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

Наиболее часто встречающееся решение, замеченное нами в больших кластерных вычислительных центрах (включая ведущие университеты и правительственные лаборатории) — это Nagios для оповещений и Ganglia для мониторинга. Эти два очень хорошо настраиваемых инструмента могут дать администратору отличное понимание множества вещей, происходящих в кластере. Ganglia, как оказалось, масштабируется чрезвычайно хорошо.

Но есть также и другие точки зрения. В Университете Южной Калифорнии (USC) Гаррик Стэплс (Garrick Staples) написал pbstop, расширение к программе TORQUE, которое визуально представляет, что делает каждое задание и где оно запущено. Он говорит, что это — весь мониторинг, который ему нужен, и не использует ничего больше.

Вот наиболее популярные, по нашим наблюдениям, инструментальные средства мониторинга с открытыми исходными кодами, применяемые при работе с масштабируемыми кластерами:

• Nagios.
• Ganglia.
• Cacti.
• Zenoss.
• CluMon.

Мы можем сказать, что многие из этих инструментальных средств в своей реализации, в свою очередь, активно используют RRDtool. CluMon — это также надстройка над весьма популярным Performance Co-Pilot (PCP). Поддержка Ganglia и PCP будет включена в следующие версии xCAT.

Кратко повторим то, что знает ленивый Linux-администратор:

• Для мониторинга нет универсального "безразмерного" решения. Под мониторингом рРазные люди понимают под мониторингом разные вещи. Некоторых интересует только система оповещений, других — показатели производительности, других третьих — профилирование заданий, а другим четвертым только нужно знать, запущены ли определенные службы или приложения.
• Настройка будет различной в различных учреждениях и на различных кластерах в пределах одного и того же учреждения.
• Нужен взвешенный компромисс между тем, что мониторится, для чего этот мониторинг используется и необходимыми ресурсами.

8. Управляйте своими пользователями с помощью планировщиков

Ленивому администратору известно, что пользователь — корень всех проблем. Следовательно, очень важно гарантировать, чтобы у пользователей не было административных привилегий или прав доступа. Можно пойти ещё дальше: необходимо сделать всё возможное, чтобы держать пользователей подальше от вашей машины.

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

Среди популярных сегодня планировщиков есть платные программы, такие как LSF и PBS Pro. Эти продукты используются многими коммерческими заказчиками, а также правительственными лабораториями и университетами. Но для многих систем прекрасно подходят решения с полностью открытым исходным кодом, такие как TORQUE и SLURM.

У нас есть приём, использующий TORQUE и планировщик Maui, с помощью которого мы держим наших пользователей подальше от кластера, когда они не выполняют задание. В Linux это делается сначала настройкой файла /etc/security/access.conf так, чтобы никто, кроме администратора, не мог войти в систему. Например, после выполнения на каждом из узлов команды:

echo "-:ALL EXCEPT root:ALL" >>/etc/security/access.conf

только администратор сможет авторизоваться на этой машине. Затем создаётся пролог-скрипт TORQUE, который позволяет пользователю войти в систему, а затем выполняет что-то вроде:

perl -pi -e "s/:ALL$/ $USER:ALL/" /etc/security/access.conf

(Подсказка: переменная $USER — вторая переменная, которую передаёт TORQUE скрипту ввода во время его выполнения). Так как пролог-скрипт выполняется пользователем root, простой пользователь сможет авторизоваться в кластере. После завершения задания запускается эпилог-скрипт, который удаляет пользователя из файла /etc/security/access.conf так, чтобы он больше не мог регистрироваться в узле: perl -pi -e "s/ $USER\b//g" /etc/security/access.conf. Это не дает пользователям "затереть" друг друга.

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

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

9. Тестируйте производительность! Находите проблемы производительности прежде, чем они найдут вас

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

Аппаратная диагностика это, как правило, система удачных либо неудачных прохождений тестов, с порогом, определенным производителем, — но ваш порог может быть выше или ниже. Если аппаратная диагностика выдаёт ошибки, это свидетельствует о проблеме, но если всё проходит гладко, это ещё не означает, что проблем нет.

Некоторые встречавшиеся нам проблемы, которые оказывали заметное отрицательное влияние на производительность систем, успешно прошедших диагностику производителя:

• Двухбитовые ошибки памяти.
• Однобитовые ошибки памяти.
• Ошибки четности SRAM.
• Ошибки шины PCI.
• Численные ошибки.
• Ошибки кэша.
• Дисковые ошибки.
• Неустойчивая производительность

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

Понятно, что для того, чтобы удостовериться, что наш кластер работает исправно, нужна некоторая адекватная рабочая нагрузка. Для этого можно запустить некоторые из стандартных промышленных тестов. Цель при этом не в том, чтобы получить наилучшие результаты, а чтобы получить результаты стабильные, повторяемые и аккуратные, что и является лучшим результатом для нас. Как понять, являются ли полученные результаты лучшими? Кластер можно условно разбить на следующие главные подсистемы: Память.Центральный процессор. Диск.Сеть. У вашего поставщика должны быть в наличии контрольные данные тестирования, фиксирующие ожидаемую производительность памяти, ЦП (количество операций с плавающей запятой в секунду), диска и сети. Как отличить стабильные результаты? Статистика. Каждый тест запускается один или несколько раз на каждом узле (или на нескольких узлах, в случае соответствующих тестов), а затем средние показатели для каждого узла (или нескольких узлов) группируются и анализируются как единая совокупность. Интересны не столько результаты сами по себе, как форма их распределения. Наш опыт для всех тестов, упомянутых в этой статье, показывает, что все они должны формировать нормальное распределение. Нормальное распределение — это классическая колоколообразная кривая, так часто встречающаяся в статистике. Оно возникает как результат суммарного воздействия небольших, независимых (может быть, неразличимых), одинаково распределенных переменных или случайных событий. В тестах производительности также содержится много маленьких независимых (может быть неразличимых), одинаково распределенных переменных, которые могут повлиять на производительность. Это, например: Небольшие конкурирующие процессы.Переключение контекста.Аппаратные прерывания.Программные прерывания.Распределение памяти.Планирование процесса/потока.Космические лучи. Их присутствия нельзя избежать, но все они вносят свой вклад в формирование нормального распределения. Тесты производительности могут также иметь не тождественно распределенные наблюдаемые переменные, которые могут влиять на производительность: Значительные конкурирующие процессы.Конфигурация памяти.Параметры настройки и версия BIOS.Скорость процессора.Операционная система.Тип ядра (например, NUMA либо SMP либо однопроцессорное) и его версия.Плохая память (чрезмерное число исправлений ошибок).Версии чипсетов.Гиперпоточность или SMTмногопоточность.Неоднородные конкурирующие процессы (такие, как httpd, работающий на некоторых узлах, но не на всех).Версии общих библиотек. Присутствия этих переменных можно избежать. Преодолимые несогласованности могут привести к возникновению многомодального или отличного от нормального распределения и могут оказать измеримое воздействие на производительность приложения. Чтобы получить стабильные, повторяемые, точные результаты лучше начать с возможно меньшим набором переменных. Начните с теста для одного узла, такого, как STREAM. Если на всех машинах результаты STREAM будут одинаковые, то при аномалиях с другими тестами, память как фактор нестабильности может быть исключена. Затем продвигайтесь дальше к тестам процессора и диска, затем к тестам для двух узлов (параллельным), затем для нескольких узлов (параллельным). После каждого более сложного теста, прежде чем продолжать, проверьте результаты на стабильность, повторяемость и точность. Вот примерный набросок последовательности тестов, которую мы рекомендуем (тест проверяет производительность компонента, выделенного жирным шрифтом): Тесты для одного узла (последовательные): STREAM (память Мбит/с)NPB Serial (однопроцессорная производительность с плавающей запятой и память)NPB OpenMP (многопроцессорная производительность с плавающей запятой и память)HPL MPI Shared Memory (многопроцессорная производительность с плавающей запятой и память) IOzone (дисковый ввод/вывод Мбит/с, память и процессор)Параллельные (только для систем MPI): Ping-Pong (соединения — задержки в микросекундах и пропускная способность в Мбит/с) NAS Parallel (производительность с плавающей запятой, память и соединения для узлов)HPL MPI Distributed Memory (производительность с плавающей запятой, память и соединения для узлов) Подождите, но это же куча работы! Так и есть, но это необходимо, если вы хотите отдыхать в будущем. К счастью, для облегчения задачи у нас есть инструментальные средства и документация. Несколько дней упреждающего планирования могут предотвратить недели огорчений впоследствии. Мы поговорим об этих инструментальных средствах и таблицах в будущей статье; они также войдут в состав будущего RPM xCAT, который значительно увеличит производительность работы администратора. 10. Организуйте обмен информацией После того как сведения о системе будут собраны, их следует поместить в какое-нибудь удобное место, чтобы другие сотрудники, обслуживающие кластер,