Проблема сетевой перегрузки.

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

Увы. нет. По крайней мерс, если на сеть управления возлагается доступ узлов к файловому серверу при помощи NFS - а это, скорее всего, так.

Проблема, которую нам надо радикально решить сейчас, - это про­блема сетевой перегрузки. Связь появления этой проблемы с NFS прояснится ниже, сейчас же постараемся пояснить, в чем проблема заключается.

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

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

Плав Отказы сетевых функций особенно пагубно сказываются на работе системы управления процессорным ресурсом. Как мы помним, задача той системы состоит в том. чтобы сводить крупные, неделимые с точки зрения пользователя, действия к последовательностям элементарных сетевых воздействий управляющей машины на узлы. Например, единое действие «завершить параллельную программу» система управления ресурсами превращает внутри себя в большое количество команд rsh, адресованных выполняющим параллсльную программу узлам. Смысл реализации системы управления ресурсами в том и состоит, чтобы весь комплект таких команд гарантированно выполнялся. как единое целое, в правильном составе. Ясно, что никаким неделимости, кор­ректности и управляемости не получится, если некоторые из этих команд rsh случайным образом откажутся работать (или. что еще хуже, на самом деле сра­ботают, но вернут код возврата, соответствующий отказу - а так бывает чаще всего)

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

На первый взгляд, все это очень похоже на большую кучу независимых недоделок и ошибок в Linux, проявляющихся чаше обычного по причине большого числа узлов и напряженного режима работы. Кто cпopит - ошибки в Linux, как и во всяком программном комплексе, есть. Но в данном случае мы имеем дело с совершенно конкретным системным эффектом, который объясня­ется вовсе не ошибками, а именно - с сетевой перегрузкой. Чтобы понять, что это такое, нам придется немного освежить в памяти наши представления об устройстве протоколов семейства IP.

В главе, посвященной программному обеспечению, мы упоминали (прав­да вскользь) о том. что стандартные сетевые протоколы ориентированы, вооб­ще говоря, на Интернет, а не на кластер.

Попробуем конкретизировать, в чем именно это проявляется.

Интернет (как. впрочем, и локальная сеть общего назначения) характери­зуется. помимо прочего, двумя свойствами:

• ненадежностью аппаратной среды передачи данных,

• динамичностью и потенциальной неограниченностью своего состава.

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

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

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

Прежде всего, сетевые протоколы общего назначения, об­разуют иерархию, то есть одни из них реализованы на базе других. При этом важнейший «водораздел» проходит по протоколу IP. который обеспечивает пе­редачу пакетов данных от одного узла сети к другому, но не гарантирует дос­тавки Когда пакет IP уходит в сеть, сеть «знает», как именно она будет его пе­редавать, но не знает, удастся ли ей это сделать в конечном итоге. На своем пу­ти пакет может быть не только искажен, но и потерян, размножен, поменян местами с другим пакетом того же отправителя. Соответственно, вся забота о том. чтобы в результате такой ненадежной передачи информация все же была доставлена в надлежащем виде, возлагается на вышестоящие протоколы. На­пример. протокол TCP, реализованный на базе IP, включает нумерацию паке­тов. контрольное суммирование, подтверждение доставки и т. п. Протокол UDP на базе IP всего этого не обеспечивает и потому сам остается ненадежным. На его основе, в свою очередь, строятся надежные протоколы, такие как NFS или протокол передачи сообщений в коммуникационной библиотеке PVM.

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

Пусть параллельная программа пользуется протоколом tcp для обмена сообщениями между узлами. Ядро Linux, в свою очередь, внутри себя превра­щает наши данные в IP-пакеты и доставляет их без потерь, поскольку электри­ческих помех нот. а узел-получатель заведомо существует Только вот без по­терь ли? Может ли физически протокол IP работать без потерь пакетов?

Поставим себя - мысленно - на место программы ядра, реализующей протокол IP Пусть от нас требуется отправить пакет. Если сетевое устройство свободно, мы это. конечно, сделаем. А если занято? Очевидно, мы запомним пакет для дальнейшей отправки, когда до него дойдет очередь. Прекрасно. Пусть теперь программа пользователя длительное время «бомбардирует» нас пакетами со скоростью, превышающей быстродействие сетевой карты Пакеты будут накапливаться, и исчерпание любого конечного буфера для хранения очереди на отправку - вопрос времени, не более того. Буфер исчерпан, про­грамма отправляет еще: Что делать? Очевидно, «зависнуть на системном вызо­ве отправки данных, чтобы до отправки следующего пакета дело не дошло», -скажем мы. И будем неправы, поскольку нельзя требовать от протокола невоз­можного Согласно упомянутой выше иерархии протоколов, IP понятия не име­ет, от какой программы и по какому поводу пришел этот роковой пакет.

Если бы программа, реализующая IP в ядре, действительно поступала так. мы запросто могли бы «завесить» (причем навсегда) всякую сетевую ак­тивность в машине, всего лишь попытавшись записать большой файл на пред­варительно выключенный NFS-сервер. По смыслу следовало бы «притормо­зить» именно ют приходящий в ядро поток пакетов, который вызвал критиче­ское заполнение буферов, а другие потоки продолжать обслуживать своим че­редом. Но IP по Самому дизайну иерархии протоколов не в состоянии разли­чать. как рас предел я юте м пакеты по потокам Конечно, если бы мы использова­ли какой-нибудь облегченный протокол для работы внутри кластера, следовало бы предусмотреть по отдельному комплекту буферов для пакетов, адресован­ных каждому получателю. Буферный пул сообщений 67-му узлу переполнен? Значит, попытка отправки данных только в этот узел должна быть «притормо­жена». путем временного «зависания» запроса на отправку. Однако здесь уме­стно вспомнить, что IP рассчитан на Интернет, где число возможных адресатов потенциально бесконечно. В этих условиях фиксированных буферов для каж­дого адресата может не хватить

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

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

Такая ситуация, когда нагрузка на сеть приводит к отказу в обслужива­нии запроса по причине неприемлемого процента внутренних потерь пакетов, без каких-либо разрушений в ОС или аппаратуре, и называется сетевой перегрузкой (network congestion).

Итак, сетевая перегрузка возникает безо всяких аппаратных или про­граммных разрушений, на исправной аппаратуре и «живой» ОС на всех yзлах. причем в случае, когда используются стандартные протоколы TCP/IP, то есть от нее заведомо должна страдать есть управления. Классический вариант сете­вой перегрузки называется «все пишут в одну точку». Например, все ветви па-рат

ллельнон программы интенсивно выводят на стандартный вывод, а сеть управления доставляет эти потоки на управляющую машину, или все ветви ин­тенсивно пишут на сетевой диск файлового сервера.

• Как побороть сетевую перегрузку?

Первое, что приходит в голову, найти «те самые» значения тайм-аутов и количеств повторов при отказе, которые заставляют Linux «сдаваться» раньше времени в условиях сетевой перегрузки, и увеличить их вес К сожалению, этот путь тупиковый. Если куда-то «втекает» вдвое быстрее, чем «вытекает)», перополнснис «бассейна» неизбежно, как бы велик он ни был. Единственный пра­вильный способ, всегда применявшийся, кстати, разработчиками ОС для ма­шин МРР в докластерную эпоху, это доставка каждого из возможных в системе потоков данных с использованием фиксированных, статически выделенных объемов промежуточной буферной памяти с гарантированным торможением того потока, который исчерпал свои ресурсы. Как реализовать это в рамках стандартных протоколов семейства IP?

Само понятие отдельного потока возникает в иерархии стандартных се­тевых протоколов лишь на уровне TCP Протокол TCP устроен таким образом;что для каждого установленного соединения передаст «в кредит», то есть без подтверждения о приеме, лишь строго ограниченный объем данных. При этом вам размер «кредита» (строгое название: TCP Window Size, то сеть размер окна ТСР) динамически подстраивается под скорость прихода подтверждений. Если они начинают запаздывать, «кредит» уменьшается. Такая логика – единственн разумная, при условии, что число соединений заранее не известно - в принцие. способна преодолеть сетевую перегрузку. Проблема лишь в том. что не все нкредачи данных в сети управления выполняются с использованием протокола ITCP Так доступ к серверной файловой системе происходит по протоколу NFS. I который, в свою очередь, базируется на UDP. Последний протокол не включает [понятия «соединения» и потому не может обладать логикой преодоления перегрузок. Отсюда ясно происхождение наиболее распространенного «привычного вывиха» при управлении кластером - эпизодического отказа при попытке выполннть rsh на фоне интенсивного ввода/вывода по NFS.

Этот эффект, конечно, сильно зависит от размера кластера. На установ­ках из сотен узлов он способен «обвалить» систему в считанные минуты, в то время как на малых установках из 10-15 узлов его проявление маловероятно.

Следует отмстить, что протокол NFS сам по себе довольно устойчив. Он [может отказывать периодически по причине сетевой перегрузки, но чаще «рубит» другую сетевую активность, чем ломается сам.

Наиболее радикальным средством борьбы с такими ситуациями пред­оставляется переход на NFS на базе TCP. Такая версия NFS, начиная с ядра 2.4.x, поддерживается в Linux.

Отмстим, что еще одним источником UDP-трафика в кластере может служитъ PVM Также нельзя не отметить, что. исключая компоненты на базе UDP-трафика и надеясь при этом избежать сетевых перегрузок, мы отступаем от принципа императивности: ведь ничто не мешает нашим пользователям самим вписать программы с интенсивными UOP-обмсенами по управляющей сети.

Как проверить, грозит ли конкретному кластер тот обвал, о котором только что шла речь? Надо написать программу интенсивного, крайне неэф­фективного вывода на диск, например, такую, как в Приложении 4. и запустить ее на всех процессорах Затем попытаться выполнять те действия с использова­нием rsh, которые вы обычно выполняете.

Например, если установлена система управления процессорным ресурсом, попробуйте просто завершить задачу. Ес­ли получилось, все узлы отзываются на rsh и находятся в хорошем состоянии. то в первом приближении, все хорошо. В том. что касается сетевых перегрузок, полных гарантий быть не может, но типичные "тяжелые режимы» тем более надо проверять. Полезно также запустить mpitncf на тех же процессорах на фо­не нагрузочного теста NFS - rth, Конечно, он будет работать много медленнее, чем обычно, но. тем не менее, должен работать как угодно долго с отличной от нуля скоростью.

Что делать, если описанные выше проверки дают отрица-тельные ре­зультаты? Методов борьбы в этом случае всего три

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

• установить отдельную есть только для NFS, а для управления использо­вать другую.

• изучать Advanced IP Routing - средства Linux, позволяющие искусствен­но ограничить интенсивность обмена данными в рамках стандартных протоколов

Выбор рабочей станции.

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

Прежде всего, остановимся на проблеме надежности Даже самый мало ведущий в вопросах подбора техники пользователь скажет вам, что любой куплен­ный в магазине персональный компьютер способен проработать и 4, и 5 дней непре­рывно. выполняя одну долгую расчетную программу.

А как насчет 3 -4 Месяцев бесперебойной работы!

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

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

Возможно, имеет смысл подумать о корпусах в индустриальном исполнении. Пристальненшее внимание следует уделить качест­ву и безотказности вентиляторов. Нет особой нужды напоминать о том, что отказ вентилятора в составе кластера, скорее всего, не будет во время обнаружен, и мате-' римская тага попросту «сгорит». Если вы установили, что вентилятор изделия, ко­торое вы рассматриваете в качестве варианта узла, периодически начинает издавать посторонние звуки - как минимум, следует заменить вентиляторы во всей партии. или выбрать другую.

Однако нам надо решить еще несколько важных частных вопросов.

Первый из них - на каком семействе процессоров следует остановиться? Из общих сообра­жений. среди предлагаемых на рынке микропроцессоров массового пользования нет какого-либо «специально кластерного»' варианта. Кластеры традиционно работают под управлением Linux, а эта операционная система реализована для всех более или менее широко распросграненных процессоров. Более того, известны вполне успеш­ные примеры построения Linuх-кластеров из системных блоков Macintosh, или машин на базе Compaq Alpha и, конечно же. из машин с lntel-свместнмыми процессорами.

Общее правило выбора здесь, следующее: если нет специальных соображений в пользу того или иного варианта, следует выбирать вариант са­мый распространенный.

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

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

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

Наконец, последний важный вопрос - выбор числа процессоров в узле.

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

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

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

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

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