Ленивый Linux: 11 секретов для ленивых администраторов кластеров

В слово кластер разные люди вкладывают разный смысл. В контекстеэтой статьи под этим словом подразумеваются системы с горизонтальныммасштабированием — горизонтально масштабируемые кластеры вообще, какправило, имеют тот же самый набор компонентов, что и комплексыWeb-серверов, комплексы серверов для визуализации ивысокопроизводительные вычислительные системы (HPC). Администраторы вамскажут, что любое изменение в горизонтально масштабируемых кластерах,даже самое незначительное, приходится повторять сотни или тысячи раз.Самые ленивые из администраторов владеют методиками масштабируемогоуправления, благодаря которым независимо от числа узлов прилагаемыеусилия остаются одинаковыми. В этой статье авторы заглянут в мыслисамых ленивых администраторов Linux® на Земле и раскроют их тайны.

С момента своего первого появления в 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. Используйте открытые решения мониторинга

В прошлом году на конференции SC07 мы встречались спредставителями нескольких ведущих лабораторий США, чтобы обсудитьсложную проблему мониторинга 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. Организуйте обмен информациейПосле того как сведения о системе будут собраны, их следуетпоместить в какое-нибудь удобное место, чтобы другие сотрудники,обслуживающие кластер,