>Так может Вы и назовете те технические особенности архитектуры линукса,
>что делают её более предпочтительной для кластеров?Володя назвал несколько общих и относящихся скорее к HA прикладных моментов; с точки же зрения HPC (о которых речь) к ним можно добавить:
- возможность модификации ядра под свои задачи (например, на наших кластерах
в итоге достигается разница по масштабируемости с тем же T60 порядка 4% --
множим на стоимость железа, чешем в затылке);
- богатый выбор интерконнекта, особенно infiniband (в отличие от крайне бедного
для макоси и соляриса[*]);
- OFED возник как явление и разрабатывается здесь же;
- приличный набор библиотек, в т.ч. заточенных под специфический IB;
- наличие выбора оптимизирующих компиляторов;
- и работающих кластерных ФС.
Но это как раз всё не техническое, а следствия. :)
Технически линукс оказался good enough в том месте-времени, когда кластеры (ещё на Beowulf) начали зарождаться примерно в том виде, который нам знаком теперь.
>По сравнению с Solaris или же MacOS X например? Лично я считаю, что дело тут
>скорее в открытости исходников и благоприятная лицензия:)
Это фундаментальное -- остальное по существу куча следствий.
>P.S. И поинтересуйтесь все же "историей Бигмака" ;)
Малоинтересно, поскольку в положительных моментах предсказуемо.
>Дело там не в выпендреже любой ценой, а скорее наоборот, в том, что
>у универа не было средств для покупки монстров от IBM или Cray.
>Поэтому решили не мудрствуя лукаво накупить системников от Эппл
Это не объяснение, а дурь чистой воды. "Не было на порш, взяли бимер". А нужен-то был -- грузовик. И то, что он _намного_ дешовле и вообще, и в пересчёте на тонну груза -- таких "экономистов" обычно не цепляет.
Не надо рассказывать про покупку эпловского железа, когда "средств нету" -- средние потроха по двойной-тройной цене тут норма. Хорошо хоть -- наконец и до этих дошла коммодизация компонент (помните, как HP жрали SIMM только "для HP", IBM -- тоже свои, и т.д.? -- NuBus вот тоже забыли...) :-/
А если на блэйды средств нету -- смотреть сейчас осмысленно в сторону такого вот:
http://www.supermicro.com/products/motherboard/Xeon1333/5400...
Ну и про плотность упаковки и энергоэффективность (с учётом охлаждения) отдельно молчу.
>И в результате - одна из первых строчек в топ500.
По линпаку. А что там зацеплено в качестве стораджа и как оно себя чувствует под пусть гигабайтом-двумя в секунду с нескольких узлов, где собирается выхлоп задач? Как решены вопросы загрузки -- если локальная, то ещё и обновления ПО и возвращения выпавших по диску узлов в строй?..
Кластер -- это не только терафлопы, но ещё и достаточно много вот такого головняка.
>Вот и кластер на МакОС.
Энтузиастер на пицце. :-) Потом эти университеты стоят и чешут репу -- и шо теперь с производными проблемами делать. А кто поумней -- тот изначально не выпендривается.
[*] http://mail.opensolaris.org/pipermail/ofuv-dev/2007-October/... :
>>>> Assuming you are working with OFED on Linux,
>>>> "general at lists.openfabrics.org"
>>>> would be the contact point.
>>> Unfortunately, our strategic platform is Solaris. We have no plans to go
>>> with Linux.
Не повезло так не повезло...
PS: Вад, там не только с мониторингом -- с управлением потреблением на x86 ещё хуже.
PPS: на конторе, помимо более современных маков, есть один из первых в стране яблочных PPC604 (или 601 ещё?);
[xxxx@access ~]$ squeue
JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)
5452 scit1 make_sca yyyy PD 0:00 1 (PartitionNodeLimit)
5451 scit1 make_bla yyyy PD 0:00 1 (PartitionNodeLimit)
5079 scit1 vo_gr zzzz PD 0:00 1 (PartitionNodeLimit)
5287 scit3 explore- abcd R 5-16:46:34 1 n3111
5288 scit3 explore- abcd R 5-16:45:35 1 n3131
5289 scit3 explore- abcd R 5-16:45:22 1 n3107
5290 scit3 explore- abcd R 5-16:44:58 1 n3108
5291 scit3 explore- abcd R 5-16:44:48 1 n3102
5519 scit3 sleep efgh R 4:59:04 16 n[3044-3059]
5533 scit3 Slae_bps ijkl R 11:57 24 n[3006-3019,3032-3041]
