Выбор коммутационного компонента.

• Концепция отдельной сети управления.

Выбрав рабочую станцию узла и управляющей машины, мы должны со­вершить второй, наиболее сложный и ответственный, шаг - выбрать коммуни­кационное оборудование и программное обеспечение,

Во-первых, мы хорошо знаем, что на сетевое оборудование кластера воз­лагаются две различных задачи.

С одной стороны, для функционирования кла­стера необходима есть управления, обеспечивающая запуск задач и функции ввода/вывода,

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

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

По совокупности всех этих факторов легко заключить, что весьма жела­тельно выделение отдельной физической сети для целей управления. Это осо­бенно важно, если в коммуникационной сети не исключается использование нестандартных протоколов. Хотя разработчики таких протоколов всегда стре­мятся к тому, чтобы стандартные протоколы TCP/IP сосуществовали с нестан­дартными в рамках одной сети, далеко не всегда этого удается достичь на практике.

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

Весьма крупный (сотни узлов) кластер был оснащен сетью Myrinct. Как известно, использование облегченных нестандартных протоколов обмена со­общениями в этой сети позволяет кратно поднять все показатели эффективно­сти - по этой причине альтернатива (использование Myrinct в режиме TCP/IP) даже не рассматривалась. С другой стороны, протоколы TCP/IP необходимы для реатизации сети управления. Казалось бы, ничто не мешато разработчикам ограничиться единственной сетью Myrinet. благо ее программное обеспечение позволяет использовать в рамках одной сети оба семейства протоколов. Однако при опытной эксплуатации выяснилось, что использование облегченных про­токолов не вполне надежно.

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

К счастью, разрушался толь­ко этот драйвер, а не все ядро, поскольку перезагрузка драйвера восстанавлива­ла работоспособность.

Так как в качестве управляющей сети на этой машине использовалась отдельная сеть Fast Ethernet, проблему удалось решить, вставив прннудитсльнл ю перезагрузку драйвера Myrinеt в стандартную последователь­ность действий, выполняемую автоматически всякий раз при запуске задачи .

Если бы на эту же сеть возлагались и управляющие функции; такой прием был бы просто невозможен.

Данный случай можно было бы рассматривать как досадное: недоразуме­ние. тем более, что в более поздних версиях драйвера эта ошибка, похоже, была исправлена. К сожалению, этот случай в действительности является проявлени­ем системной закономерности. Нестандартные протоколы потому и называют­ся нестандартными, что предлагаемые ими возможности выходят за рамки стандартной для Linux системы ресурсов, предоставляемых процессу (ветви параллельной программы) операционной системой узла. По этой причине, та­кие или очень похожие ('шероховатости» при использовании облегченных прокотоколов более чем вероятны и к ним надо быть заранее готовыми.

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

Если же строится кластер, на котором предполагается решение задач с вы­сокими требованиями к производительности файлового сервера, необходимо добавить адаптер Gigabit Ethernet.

В этом случае встроенный адаптер имеет смысл оставить для управления, а добавленный гигабитный использовать для NFS. Для коммуникационной сети тогда потребуется третий адаптер.

Как испытывать коммутатор.

• Нагрузочный тест mpitnet

Проблема испытания коммутатора, в основном, касается случая, когда используется тот или иной вариант Ethernet. Речь идет не об испытании аппара­туры на формальную исправность (конечно, риск приобрести неисправное из­делие. будь то коммутатор, материнская плата или сетевая карта, отличен от нуля, но все же довольно низок

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

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

Конечно, ошибки эти практически не проявляются при использовании коммутатора в составе офисной сети - иначе изделие просто не появилось бы на рынке до ее (ошибки) устранения.

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

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

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

Для проверки работоспособности коммутатора в интенсивных, «кла­стерных». режимах. можно рекомендовать программу mpitnet .

Смысл программы - в запуске одновременно как можно большего числа обменов, чтобы максимально «нагрузить» все уровни протокольной иерархии переключениями между ними, когда коммуникационная библиотека и ОС будут пытаться выполнять их все параллельно. Для этого используются асин­хронные обмены - такие, при которых акт обмена делится на две части: запуск обмена и ожидание его конца. Именно это позволяет запустить много обменов «в параллель».

Ветвь программы mpitnet делает следующее:

• запрещает приемы от всех узлов, кроме собственного, массивов опреде­ленной длины.

• шлет всем узлам, кроме собственного, массив такой же длины, заполнен­ный целочисленным счетчиком, сдвинутым на собственный номер.

• дожидается завершения всех приемов.

• убеждается, что от каждого узла пришел счетчик, сдвинутый на его (узла) собственный номер.

Указанная процедура выполняется очень много раз - «классический» тестовый прогон должен занимать сутки.

Именно этой программой, в качестве основного инструмента, налажива­лись. в частности, вес компьютеры МВС-100 и большинство компьютеров МВС-1000. Разработчикам приходилось встречать коммутаторы Fast Ethernet, «падав­шие» под этим тестом за секунды? Впрочем, не только секунды, но и часы не допустимы.

Тест mpitnet должен работать как угодно долго (часы, сутки), не фиксируя ошибок. Ситуация, когда все тесты и реальные задачи идут, только mpitnet через 2-3 часа подвисает. совершенно не допустима. Такой коммутатор надо менять, если, конечно, установлено, что дело в коммутаторе

Почему мы говорим об Ethernet? Просто потому, что все прочие рассмот­ренные нами сетевые технологии либо работают, как правило, без коммутато­ров (SCI). либо оснащаются коммутаторами с совершенно определенной (и притом документированной) внутренней логикой (Myrinet). Одним словом, все Myrinei-коммутаторы логически одинаковы.

О коммутаторах Ethernet этого сказать нельзя - их делают сотни производителей, причем информация о внут­ренней логике и алгоритмах их работы, как правило, не публикуется.

Означает ли это. что программу mpitnet имеет смысл запускать лишь на сети Ethernet? Ни в коей мере Представляется, что данная программа является весьма сильным комплексным тестом работоспособности коммуникацион­ной сети. Почти верно утверждение: «Если работает mpitnet, сеть работает».