четверг, 6 ноября 2008 г.

Блеск и нищета кластерных систем

Так уж получилось, что за последние годы мне довелось неоднократно выслушивать радостные идиотические вопли "Мы покупаем кластер!" и видеть впоследствии унылые физиономии аццких одминов и их руководителей, задающих удручающе однообразные вопросы на тему "Что делать дальше? И кто был виноват? У нас не получается восстановить базу! Где обещаная производительность?" и тому подобное.

А в самом деле, что делать? Почему так?

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

Что же с ним не так?

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

В пользу чего же?

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

Я не оговорился.

Один за другим обладатели мощнейших и масштабируемых суперархитектур - DEC с Альфой, Cray Research (видя то, во что превратили выродки от IT его детище, Сеймур Крэй переворачиваетсяя в гробу), Tandem, HP с PA-RISC, а за ними и Sun Microsystems с непобедимым SPARC-IIIi и SPARC-IV+* - один за другим трусливо сливают на поле, на котором имеют неоспоримое преимущество, которое в обозримом будущем не побить ублюдочному настольному недоноску Интел. Выродок, который был изначально кошмарным встраиваемым уродцем, по необъяснимой причине, как Гуинплен, вдруг стал лордом королевства - и какого королевства! - Энтерпрайз-систем!

Оставим лирику и эмоции и попытаемся взглянуть в корень проблемы.

Итак, встречаем бурными и продолжительными аплодисментами,

SMP-системы

Представители традиционных SMP-систем Энтерпрайз-класса, имея на борту практически неограниченное количество процессоров, беспрецедентно быстрые северные мосты и возможность синхронного параллелизма, как никто лучше подходили для решения задач, под которые, собственно говоря, и затачивались. Сильно связанные параллельные процессы - обработка БД, SQL-запросы, и тому подобное.**

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

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

Таким образом, Бугимен вернулся. Мы снова получили распределенную архитектуру, которую казалось бы похоронили с осиновым колом в конце 90х.

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

Хотя класс задач и кажется широким, в действительности он меркнет перед задачами параллельной обработки данных. СУБД все же применяются слегка шире, нежели суперматематические вычисления, наподобие задачи о столкновении трех автомобилей или рендеринга сцен "Корпорации Монстров".***

Гриды (Grids) и кластеры

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

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

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

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

Мама, роди меня обратно!

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

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

Однако деваться было некуда, стадный эффект неудержимо поволок вендоров - как же, конкуренты обскачут! Если конкурент встал на четвереньки и стал жрать навоз - надо тоже встать и начать жрать навоз в два раза интенсивней! - в сторону тупого производства кластерного УГ.

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

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

(продолжение следует)

Лирическое отступление на тему взаимодействия процессоров

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

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

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

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

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

Более того, получилось это лишь у очень некоторых. Например, у AMD.

Даже Sum Microsystems сотворила эпический фэйл с Ниагарой, которая больше шумит, чем производит работы в единицу времени, как и ее одноименный водопад.

Интел слила по полной, сварганив Core Duo с километровой очередью команд, который годен лишь для вычислительных и слабосвязанных задач. В результате ее двухядерник пролетает как фанера в сравнении с AMD Opteron, причем последний еще и инеем покрыт при работе.

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

В чем суть проблемы?

Во взаимодействии:

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

Пункт а) требует адекватной внутренней архитектуры процессора, которую, по очевидной причине "совместимость важнее производительности" легко изменить не получится. Элементарно, Ватсон. Инсталляционная база. Дойные коровки, исправно выкладывающие кровные. Как же так - взять и дать им несовместимый процессор! А деньги? Мы ж не двигатель прогресса и богадельня по совместительству, а коммерческое предприятие!

AMD - рискнули. И получили впечатляющий результат, причем настолько, что вздрогнули даже SPARC-III/IV+.

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

Есть разъем? Подходит? Вставляем. Нет разьема? Или нечего вставить? Или дорого вставить? Оставляем.

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

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

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

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

Вернемся к нашим баранам.

Гриды (Grids) и кластеры (продолжение)

Дабы успешно впаривать несуразных уродцев-кластеров, пришлось выдумывать новую парадигму - и не одну.

Парадигма 1. Кластерное решение - высоконадежное.

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

Парадигма 2. Кластерное решение - высокопроизводительное.

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

Парадигма 3. Ладно, если вы слышали или знаете, что Парадигма 1 и 2 неверны, тогда попробуем так: Кластерное решение - масштабируемое.

Ага, щаз. Масштабирование как понятие включает в себя не только надежность и производительность - но и управляемость и готовность.

Парадигма 4. Не придется переписывать уже работающие приложения для достижения Парадигм 1, 2 и 3. Все будет прекрасно работать так как есть, но уже на кластере.

Так-так-так. Ну надо же. А алгоритмы и код приложений - они вообще из Скайнета или Матрицы. Сами адаптируются, сами увидят архитектуру, сами расползутся по нодам. Или, может, это clusterware стало с некоторых пор обладать ИИ?

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

Первая парадигма не выдерживает никакой критики по двум причинам.

Причина 1. Собственно электроника, при адекватном исполнении, не имея подвижных частей и шаловливых ручек, шансов выйти из строя, по реальной статистике, имеет очень мало. А вот дисковая система - с теми самыми подвижными частями - шансов выйти из строя имеет гораздо больше, особенно с учетом основополагающей концепции кластеростроения - делаем все из дешевки, для уменьшения ТСО. Никакая организация массивов, как показывает все та же реальная статистика, не отменяет необходимости создания резервных копий, поскольку дешевые массивы из дешевых дисков выходят из строя так же, часто как и одиночные диски, а реально высоконадежные массивы имеют стоимости на порядок превосходящую стоимость всей "высоконадежной кластерной системы".

Причина 2. Аргументы "мы используем аппаратные массивы, которые не ломаются, мы используем аппаратную репликацию на ДВЕ дисковые системы" не работают, поскольку, видите ли, господа продавцы (чуть не сказал "христопродавцы"), промышленные СУБД на аппаратно реплицируемых системах не работают, ну не обеспечивают СУБД целостность баз в условиях, когда дисковые системы живут собственной жизнью. А в аппаратных массивах есть компоненты, которые могут внезапно сдохнуть - например, батарейки энергонезависимого кэша. Кроме того, территориально эти два массива с репликацией часто находятся в одном месте - рядышком друг с другом - и при серьезной катастрофе - взрыве, пожаре, теракте - тихо погибнут вдвоем.

Говорите, высокая надежность? А как же тот факт, что простое увеличение количества ВНЕШНИХ электрических или оптических соединений в принципе снижает надежность? Экскаватор-тян?

Парадигма 2 тоже хромает на обе ноги.

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

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

Cache Fusion, несмотря на все потуги, оказался лишь жалким подобием левой руки, в принципе не способным решить проблему Instance Pinging без кардинального перелопачивания кода приложений.

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

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

Парадигма 4 вообще является вызовом теории программирования и реальной практике. Всем известно, что Windows NT на двух процессорах даже не могла обеспечить синхронной загрузки обеих процессоров (даже еще не ядер) одним параллельным SQL-запросом. Говорите, без переписывания? А ОС обладает знаниями, как обеспечивать load balancing, process affinity итп, для крутящихся на них приложениях? Может, сами приложения все это знают? А как, если они писались на ноутбуке разработчика с одним процессором и одним диском?

Суха теория, мой друг...

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

В лучшем случае за сумму, в несколько раз превышающую ТСО старой системы, покупатель получает систему, имеющую тот же самый уровень производительности и надежду, что в будущем будет масштабирование. Возможно.

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

Откаты благополучно получены и прожраны.

Поздравляю.

Теперь администраторы, плюясь и матерясь, будут пытаться, со всем этим зоопарком на борту, взлететь.

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

Чем все-таки так плохо данное решение? Тем, что идея консолидации - только немного не такая, как ее сейчас преподносят - все-таки здравая. Клиент-серверная архитектура, с централизацией всех без исключения ресурсов (кроме инфраструктуры связи) имеет максимальный потенциал и позволяет достичь и HA и HP минимальной, в общем-то, ценой. Причем в центре стоят не сотни недоношенных писюков - а пара-тройка ошеломляюще мощных многопроцессорных SMP энтерпрайз-класса. Имеющих экатремальную производительность и качество исполнения. А децентрализация ресурсов по гриду принципиально противоречит концепции консолидации как таковой.

Простой инженерский здравый смысл говорит, что сверхбыстродействующая шина северного моста SMP-системы, имея значительно меньшую протяженность и большую пропускную способность, под соответствующей ОС (я не имею здесь в виду ни доморощенного самопала, ни настольно-ориентированных "операционных систем") обойдется в конечном итоге дешевле и будет работать несравненно быстрее, нежели грид, с той же самой попыткой интерконнекта, но негодными средствами - типа Gigabit Ethernet. Кроме того, я хоть тресни не поверю (имея достаточно большой опыт), что последовательные соединения способны хоть сколько-нибудь заметно конкурировать с параллельными в скорости. Если на южных мостах это еще как-то оправдано (замена параллельных шин последовательными, хотя даже и это под большим вопросом), то на северном конце - просто преступно. Никакой гигабитный Ethernet никогда не одолеет Fireplane. Попробуйте-ка достичь скорости 10 Гб/сек.

И прошу заметить - даже на интерконнектах такого класса достичь адекватной синхронизации кластерных узлов либо процессоров SMP - непросто. Этот факт отлично известен IBM, не случайно они положили столько сил на создание NUMA-архитектур, которые и по сей день недосягаемы в TPC. Кстати говоря, верхние позиции чартов в TPC не измениились - их все так же занимают SMP и NUMA-машины.

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

__________________________________

*
Я не могу считать победой ни Ниагару, ни ее потомка Ниагару-2 и иже с ними. При всем желании, эти процессоры даже по укурке нельзя назвать универсальными. Слив SPARC-64 Фуджитсу-Сименс (надо заметить, что SPARC-III и посейчас в британский флаг разрывает Пентиумы D) лично я бы постеснялся назвать победой. А выпуск, одновременно с системами на основе непобедимого Оптерона, отстойных недоносков на интеловских процессорах, согласно Джеку Трауту, вообще называется расфокусировкой (которая является теми самыми граблями, на которые наступают и будут наступать все без исключения компании. Мыши плакали, кололись, но продолжали есть кактус). Привет тебе, о Дмитрий! Интеловские машины от Sun Microsystems отстойны настолько, что их просто дарили партнерам, бесплатно, потому что покупать такое УГ никто не хотел, будучи в здравом уме и имея в альтернативе Оптерон Квад кор. А PA-RISC и посейчас не имеет себе равных под собственной HP-UX, держа на паршивой рабочей станции сотню пользователей одной левой рукой. То, что недоумки от IT не смогли дать ума SuperDome, не говорит о том, что SuperDome плох. Это говорит лишь о том, что плохи сами недоумки, которые способны загубить коряво написанным корявыми ручонками и выдуманным корявым недалеким умишком запросом любой суперсервер.

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

***
Этот фильм рендерился на машинах Sun Microsystems, кто не в курсе.

**** HA-High Availability. Термин первоначально относился к системам, работающим в режиме 24x7x365. Но, поскольку техномегаломанию надо развивать, клиенту исподволь прививали навязчивую мысль, что его система - именно такая или таковой будет в самом ближайшем будущем.

***** HP-High Performance. Предполагалось, что кластеры представляют из себя дешевую альтернативу SMP-системам и позволят легко и линейно наращивать производительность конечной системы. Вообще говоря, это утверждение (с рядом существенных оговорок) справедливо лишь в отношении вычислительных кластеров и соответствующих задач.