Открытость + параллелизм + надежность

26 ноябрь, 2007 - 17:11Андрей Зубинский

В этой области всегда царили UNIX-системы – и во времена специализированных суперкомпьютеров, и в наши дни, когда «революция, о которой так долго мечтали» ученые, свершилась, и термин «commodity computing», несмотря на «обывательский» характер, активно используется в самых передовых областях науки. А вот в том, что сегодня здесь царство UNIX -подобных открытых систем, нет ничего революционного – мир UNIX возвращается к своим изначальным идеям.

Увы, употребить слово «кластер» придется с самого начала, как бы этого ни хотелось. Употребить для того, чтобы сразу расставить точки над «i» – в мире вычислительной техники термин «кластер» имеет столь широкий диапазон значений и толкований, что ему посвящена отличная 500-страничная книга Грегори Фистера «В поисках кластеров» (Gregory Pfister «In Search of Clusters»), выдержавшая уже два издания. Пытаться на трех-четырех журнальных страницах пересказать содержание увесистого манускрипта – занятие, заведомо обреченное на провал.

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

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

В-третьих, на самом нижнем уровне – укрупненно-компонентном (а ключевой компонент здесь – завершенный самостоятельный компьютер), в идеале не должно видеться то, о чем говорилось в «во-первых». То есть в идеале тот, кто, грубо говоря, «скручивает» на отверточном уровне компьютер, не должен знать о том, какое высокое и непростое предназначение уготовано его детищу. Если это правило соблюдено и компьютер относится к потребительскому классу, тогда это действительно commodity computing без всяких кавычек.

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

В следующих разделах статьи мы бегло и кратко ознакомимся с тем, что предлагают современные UNIX-подобные ОС «кластеростроителям», специализирующимся в разных областях. Здесь же следует сразу остановиться на проектах, которые нужны всем, кто заинтересован в любом вычислительном и массово-параллельном. Обратим внимание на ключевое слово «массово». Оно свидетельствует о том, что придется иметь дело с массой компьютеров, одинаковых компьютеров, одних и тех же конфигураций системного и прикладного ПО. Иными словами – с объемной рутинной работой. И первый важнейший инструмент «кластеростроителя» – средство автоматизации клонирования инсталляций программ и их обновления в масштабных сетях. К таким средствам, например, относится SystemImager, ориентированный на работу с дистрибутивами ОС Linux – самой распространенной и заслуженно популярной ОС в мире массово-параллельных вычислений.

Числодробилки

Итак, область, в которой возможности современных UNIX-подобных ОС раскрываются на 110%, – системы массово-параллельного commodity computing. По сути, это мир двух высокоуровневых архитектур (настолько высокоуровневых, что даже лучше говорить об идеологии) – Beowulf и NOW.

NOW (Network Of Workstation) – проект, не завоевавший значительной популярности за пределами университета Беркли, тем не менее он весьма интересен и заслуживает внимания. Первая масштабная NOW-система была реализована еще в 1995 г. и состояла из ста пяти рабочих станций Sun Ultra 170, соединенных высокоскоростной сетью Myrinet, модификации которой по сей день используются более чем в 30% проектов современных «числодробилок» рассматриваемого нами класса). Рабочие станции использовались, как говорится, «из коробки», с немодифицированной ОС Solaris. Реализация проекта усложнялась тем, что разработчики поставили перед собой задачу создать необходимую для решения всех задач кластеризации прослойку ПО фактически с нуля – просто потому, что ничего подобного тогда не существовало. В результате появилось то, что определяет принадлежность системы к классу NOW – GLUnix, Global Layer UNIX, единая программная надстройка над ОС, объединяющая реализацию следующих типовых для всех массово-параллельных вычислителей задач:

  • Удаленное интерактивное и пакетное управление задачами: как параллельно исполняющимися на группе вычислителей, так и последовательно – на одном, как отдельными, так и их группами.
  • Управление загрузкой отдельных вычислителей (балансировка загрузки), позволяющее автоматически передавать задачи на исполнение свободным вычислителям так, чтобы добиться постоянной оптимальной утилизации вычислительных ресурсов.
  • «Прозрачная» защита всей системы от сбоев отдельных узлов.
  • Сохранение привычной рабочей среды для пользователей всей системы в целом, в первую очередь – семантики операций ввода-вывода и управления заданиями.

Архитектура основанной на GLUnix системы включает в себя следующие высокоуровневые ключевые компоненты: мастер кластера, демон узлового вычислителя и библиотеку пользовательских программ. Мастер кластера – управляющий узел, собирающий информацию о состоянии всех компьютеров, объединенных в систему (о загрузке на уровне отдельных процессов, исполняемых каждым вычислителем), и централизованно управляющий выделением ресурсов. Соответственно, демон узлового вычислителя, исполняемый фоновой задачей на каждом компьютере системы, готовит необходимую информацию для мастера кластера, доставляет ее ему и «овеществляет» его команды. При исполнении на аппаратных средствах описанного выше вычислителя GLUnix показывает весьма неплохие результаты – так, для запуска параллельной программы на 95 компьютерах системы требуется всего 1,3 с. Однако выбранные архитектурные решения также предопределяют и ряд ограничений, например масштабирования. Для иллюстрации соотношения между уровнями – на нижнем уровне проекта для запуска удаленного процесса потребовалось 3 TCP/IP сокета, из чего на самом высоком уровне (пользователя ресурсов всего вычислителя) «вылезло» ограничение на количество процессов в задаче – не более N/3, где N – максимальное количество файловых дескрипторов одного процесса (для многих ОС N=1024). К несомненным достоинствам GLUnix можно отнести поставленную разработчиками и решенную «сверхзадачу» – использовать единый унифицированный инструмент для достижения разных, но смежных целей (иногда такой подход дает замечательные результаты, достаточно вспомнить файловую систему ZFS). Справедливости ради следует заметить, что для Beowulf-систем никто не запрещает использовать великолепную разработку знаменитой Ливерморской национальной лаборатории (LLNL) – SLURM (Simple Linux Utility for Resource Management), во многом аналогичную GLUnix и прошедшую «проверку боем» в таких масштабных проектах, как IBM BlueGene/L и Purple.

В отличие от NOW и ее единой основы GLUnix проект Beowulf является больше сборником наставлений по «кластеростроению». Здесь, по сути, нет единой среды, решающей те же задачи, с которыми справляется GLUnix, ее заменяет набор инструментальных и административных средств, четкого, имеющего характер воинского устава, перечня которых не существует. Это, с одной стороны, – недостаток, а с другой – неоспоримое достоинство, которое и предопределило настоящее царство Beowulf-систем в мире массово-параллельных «числодробилок». К счастью, о Beowulf написано столько, что заниматься повторением тысячекратно пройденного нет смысла. И в конце концов, все, кому нужна «числодробилка», о Beowulf знают. Единственное, что можно добавить к уже сказанному, – для того чтобы изучать программирование и администрирование Beowulf-кластеров, совершенно не обязательно иметь несколько свободных компьютеров под рукой. Вполне достаточно одного, причем даже не обязательно работающего под управлением ОС Linux. Благодаря научным сотрудникам Института им. Руджера Босковича в Загребе (Хорватия) любому желающему доступен персональный работающий «макет» Beowulf-вычислителя во вполне «натуральную величину» – с тремя узловыми компьютерами и одним управляющим. Все это удовольствие, называемое DCC/Live, занимает один CD и построено на основе дистрибутива Knoppix и результатов проекта User Mode Linux. Иными словами – это дистрибутив ОС Linux, не требующий инсталляции и настроенный так, что после загрузки вы получаете одну реальную машину под управлением Linux и три – виртуальных, связанных между собой по виртуальной же сети, при этом конфигурации системного и прикладного ПО всех машин соответствуют типовым задачам, решаемым Beowulf-кластером – просто загружайтесь с CD и работайте.

Параллельные системы высокой готовности

Предмет обсуждения этого раздела интересен и важен не только для тех, кто использует компьютеры для самого дорогого и чувствительного ко сбоям – для счета денег. Вовсе нет. Все зависит от масштабов – если, например, управляющий компьютер большой «числодробилки» выходит из строя, а в то время решается какая-то очень важная, требующая продолжительного машинного времени задача, это очень плохо, и от этого надо защититься. Способов защиты может быть немного. А точнее, всего два, оба они прекрасно известны инженерам с незапамятных времен и, по сути, никакого отношения к компьютерам вообще не имеют: надо или увеличивать надежность критического узла, или же резервировать его. Первое разработчику, оперирующему крупногабаритными компонентами, принципиально недоступно (тем более когда компоненты – тот самый commodity computing), поэтому остается второе. И оно в мире параллельных вычислений называется HAC (High Availability Clustering). Программных систем и продуктов, позволяющих реализовывать HAC-проекты, столько, что перечисление займет слишком много времени. Поэтому мы остановимся на самой простой, самой доступной и, между тем, отлично «обкатанной» и подходящей для решения массы задач, разработке – Heartbeat.

В основе Heartbeat лежит простой и очевидный принцип – если в параллельной системе с одним из компьютеров нет связи, значит, этот компьютер не может работать в интересах всей системы в целом, и, соответственно, больше не является ее частью. Иными словами – если сердце (heart) машины не бьется (beat), она считается неживой и вычеркивается из списков «сотрудников кластера» (следует заметить, что Heartbeat – редкий образчик удачного названия для программного проекта). «Биениями сердца» могут быть краткие сообщения, которыми машины обмениваются между собой или с управляющим компьютером. Первое очевидное, что бросается в этих словах в глаза: для таких сообщений необходима очень надежная система передачи. И конечно, оптимальный вариант, если бы она была независимой от основной сети обмена информацией – по ряду соображений, начиная с того, что сбои в сегментах этой сети еще не означают выхода из строя присоединенных к ним компьютеров, и заканчивая тем, что передача пакетов-«сердцебиений» требует полосы пропускания. Но в масштабных системах отдельная сеть – большая и далеко не всегда позволительная роскошь. Именно поэтому разработчики Heartbeat предусмотрели в своей системе возможность использования самых разных коммуникационных протоколов – от IP до низкоуровневых с прямым доступом к последовательным портам компьютеров. Кроме того, сама реализация системы «сердцебиений» должна быть исключительно простой и надежной, и Heartbeat создана с первоначальным учетом этих требований – система сравнительно невелика (около 10 тыс. строк кода) и тщательно оттестирована годами эксплуатации в десятках тысяч проектов. Над низкоуровневым Heartbeat за многие годы эксплуатации была надстроена полноценная среда управления HAC-системами, называемая Linux HA.

DRBD – второй важный элемент при создании HAC-системы на основе UNIX-подобной ОС. По сути, это драйвер (реализованный модулем ядра ОС Linux), позволяющий формировать из дисковых ресурсов (точнее блочных устройств) разных компьютеров нечто подобное RAID 1, на простонародном компьютерном сленге именуемое «зеркалированием». DRBD взаимодействует с Heartbeat на основании следующего принципа – если система определения неисправности узла (Heartbeat) приняла решение, что его «сердце не бьется», а этот узел входил в перечень «отражаемых» с помощью DRDB, узел, содержащий «отражение», автоматически становится сам «отражаемым». Таким образом, обеспечивается когерентность файловых систем HAC-проекта. DRBD фактически не зависит от типа используемых файловых систем и не требует специализированной аппаратной поддержки. Практика показывает, что полосы пропускания распространенного гигабитного Ethernet вполне достаточно для работоспособности системы, использующей DRBD.

Возможно, следовало бы вынести в отдельный раздел статьи распараллеленные системы балансировки загрузки, но здесь есть сразу несколько «но». Во-первых, функционально они частично реализуются указанными в статье программами. И во-вторых, упомянутое «частично» говорит о том, что балансировка загрузки – отдельная достаточно сложная ветвь в развитии кластерных вычислителей. Здесь используются как традиционные приемы избыточности (балансировка загрузки линий связи), так и принципы распределения заданий между параллельными ресурсами – и на уровне множественных сетевых соединений (обеспечивающих восприятие потребителем единым ресурсом пула серверов), и на уровне приложений, и даже на уровнях отдельных сервисов (самый известный пример – балансировка загрузки DNS-серверов).