среда, 19 ноября 2008 г.

Загрузка и установка Solaris 10 10/08 с USB

Загрузка и установка Solaris 10 с USB-устройств, в частности, с флэшек, собственно говоря, не новость.

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

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

Как только что выяснилось, релиз 10/08 поддерживает флэшки 8 Гб, что позволяет выполнять разные трюковые вещи совершенно официально (а некоторые не слишком официально, но позволяет ;) и, как выяснилось, не только самый последний релиз ;)).

Однако вернемся к старым флэшкам 4 Гб. Такая вещь, как создание загрузочной (а особенно - установочной) USB-флэшки*, достаточно долго была нетривиальной процедурой. Как описано здесь, процедура, в общем-то, существует, однако она непроста даже для знающего соляриста и состоит из множества замысловатых ходов.

Общая структура флэшки-"диска" очень напоминает структуру загрузочного диска Солярис 8 на x86.

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

Итак, задача.

Нам нужно разметить новую флэшку, создав на ней один корневой слайс 0 на весь доступный объем (дабы гарантированно впихнуть на нее весь дистрибутив, возьмем флэшку объемом 4 Гб). И выберем ее поприличней. Чтобы и BIOS определил (иначе не загрузимся) и Солярис. Как раз случилась под рукой проверенная Kingston DataTraveler 4 Гб с интерфейсом USB 2.0.

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

Дальше я просто приведу листинг проделанных операций с выделением ключевых пунктов и действий жирным шрифтом. Sapienti sat. ;)

root @ haribda / # svcadm disable volfs
root @ haribda / # rmformat -l
Looking for devices...
1. Logical Node: /dev/rdsk/c1t0d0p0
Physical Node: /pci@0,0/pci108e,534b@2,1/storage@5/disk@0,0
Connected Device: Kingston DataTraveler 2.0 PMAP
Device Type: Removable
root @ haribda / # fdisk /dev/rdsk/c1t0d0p0

Здесь создается один раздел SOLARIS2 на весь объем устройства. Не вдаваясь в детали структуры таблицы разделов (она описана в вышеприведенной ссылке), примем как факт, что мы создаем и делаем активным полный раздел (почти полный) s0 на всем устройстве.

root @ haribda / # newfs /dev/rdsk/c1t0d0s0
newfs: /dev/rdsk/c1t0d0s0 last mounted as /rmdisk/unnamed_rmdisk/s0
newfs: construct a new file system /dev/rdsk/c1t0d0s0: (y/n)? y
/dev/rdsk/c1t0d0s0: 8044544 sectors in 1964 cylinders of 128 tracks, 32 sectors
3928.0MB in 76 cyl groups (26 c/g, 52.00MB/g, 6400 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 106560, 213088, 319616, 426144, 532672, 639200, 745728, 852256, 958784,
7030880, 7137408, 7243936, 7350464, 7456992, 7563520, 7670048, 7776576,
7883104, 7989632

root @ haribda / # svcadm enable volfs

Далее монтируем CD/DVD и запускаем скрипт setup_install_server в направлениеи появившейся точки монтирования USB /rmdisk/unnamed_rmdisk/s0:

root @ haribda / # setup_install_server /rmdisk/unnamed_rmdisk/s0

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

Затем добавляем диск за диском (в случае дистрибутива на CD) в тот же самый путь остальные диски дистрибутива, включая языковые (Languages). Для x86 весь объем дистрибутива для данного релиза составляет примерно 2,4 Гб.

После копирования последнего диска на USB-устройство, осталось уже не слишком много. Устанавливаем GRUB на USB:

root @ haribda / # cd /boot/grub

(пояснение: Действие происходит на сервере, к которому подключена флэшка и на котором уже установлен Солярис 10 релиза 10/08)

root @ haribda / # installgrub stage1 stage2 /dev/rdsk/c1t0d0s0
root @ haribda / # svcadm enable volfs

Последнее - и самое важное - действие заключается в замене x86.miniroot на USB для того, чтобы дистрибутив не искался исключительно на CD/DVD-приводе. Данная статья исчерпывающе описывает, как это проделать.

Краткое пояснение. Цель заключается в корректировке скрипта install-discovery из файла x86.miniroot. Не пересказывая содержания - проще заменить процедуру trymountcd() на следующий код:


trymountcd()
{
echo $Installfs | grep ramdisk > /dev/null
if [ $? = 0 ] && [ ! -d /cdrom/Solaris_* ] ; then
ls -l /dev/dsk | grep storage | grep 's0 -' \
| awk '{print $9}' | while read VAL
do
for Dev in /dev/dsk/${VAL} ; do
Typ=`/usr/sbin/fstyp $Dev 2> /dev/null`

if [ "X${Typ}" = "Xufs" ] ; then
mount -o ro $Dev /cdrom
if [ -d /cdrom/Solaris_* ] ; then
echo "Using install media in $Dev"

# save install media for wizards
echo $Dev >> ${CDROOT}

break
else
umount /cdrom 2> /dev/null
fi
fi
done
done
else
if [ ! -d /cdrom/Solaris_* ] ; then
# "this never happens" :-)
echo "ERROR: The Solaris Distribution, ${Installfs} " \
"does not exist"
echo " Exiting to shell."
/sbin/sh
fi
fi
}


после чего пересобрать архив x86.miniroot и положить его в каталог boot на корне USB-устройства после заливки на него дистрибутива.

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

Все.

Замечание. Не все. Решение из оригинальной статьи не тестировалось на машинах без CD/DVD. При установке с созданного подобным образом устройства происходит сбой скрипта install-begin, не дающий полноценно начать и завершить установку без вмешательства руками. Проблема связана с багом в скрипте install-begin, поскольку Sun не учел возможность установки с устройств, отличных от CD/DVD. Файлы, содержащие все необходимые исправления и изменения, можно скачать здесь.

То есть, для создания полноценного архива x86.miniroot, пригодного для загрузки и выполнения установки Solaris с USB, необходимо заменить два скрипта - install-discovery и install-begin.

Изменения, которые необходимо внести в скрипт install-begin, приводятся ниже:
____________________________
# If a .cdroot file exists, the Solaris Wizard will select Solaris CD
# by default on SolarisMediaPanel
#
if [ -f $CDROOT ] ; then # This is a cdrom installation
# ***
# Bug with $CD_ID value on i386 machines without CD
# if [ ! -z $CD_ID ] ; then
if [ "X$CD_ID" != "X" ] ; then

____________________________
# ***
# Bug with $CD_ID value on i386 machines without CD
# from USB devices.
#if [ -z "$cdid" ] ; then
if [ "x$cdid" = "x" ] ; then
for i in $CD_ID ; do
if [ -b /dev/dsk/$i ] ; then
cdid=$i

____________________________
# ***
# Bug with $CD_ID value on i386 machines without CD
#echo $cdid > /tmp/find_device.out
if [ "x$cdid" != "x" ] ; then
echo $cdid > /tmp/find_device.out
else
cat $CDROOT > /tmp/find_device.out
fi

install_debug wizard "final cd_id found: $cdid"

____________________________

После демонтирования и отключения съемного устройства у вас в руках полноценный инсталляционный и загрузочный
USB. Пригодный и для интерактивной установки/обновления, и выполнения Custom JumpStart и для ремонтно-восстановительных работ в single user.

_____________
* Фактически речь идет о создании вполне полноценного загрузочного и установочного USB, подобного DVD с Solaris.

вторник, 18 ноября 2008 г.

Новый друг лучше старых двух

Вышел новый релиз Солярис 10 - 10/08.

Вообще, этот год очень урожайный на релизы Solaris. Два релиза в году - означают либо очень много багов ;), либо новые возможности.

Итак, что в новом релизе революционного?

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

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

Слегка шокирует неприменимость fsck к файловым системам zfs (это просто непривычно для ОС вообще и для Solaris в частности), однако в целом впечатление самое благоприятное.

Можно даже рискнуть и посадить уже на ZFS все файловые системы. Если на машине есть 4 Гб оперативной памяти, то даже с достаточно тихоходными дисками SATA, система начинает работать так, будто дисковой системы почти нет.

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

Кстати, достаточно занятно наблюдать за расходованием оперативной памяти при помощи top (первое время, затем после выхода БД в стационарное состояние, заполнение памяти стабилизируется примерно на величине 7/8 и остается почти неизменным в дальнейшем с небольшими колебаниями).

Вот что показывает top на машине с 2мя процессорами SPARC-III и 4 Гб оперативной памяти при работающей БД Oracle, с запущеным листенером, OEM dbconsole, установленным компаньоном и веб-сервером Apache:

root@athena /# top

last pid: 17797; load avg: 0.04, 0.07, 0.14; up 2+20:57:03 15:56:21
84 processes: 83 sleeping, 1 on cpu
CPU states: 99.0% idle, 0.3% user, 0.7% kernel, 0.0% iowait, 0.0% swap
Memory: 4096M phys mem, 158M free mem, 8193M total swap, 8190M free swap

PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
20943 root 1 59 0 4544K 2616K cpu/1 3:40 0.13% top
9430 oracle 1 59 0 1339M 1317M sleep 0:17 0.05% oracle
21679 oracle 1 59 0 1337M 1308M sleep 1:11 0.04% oracle
9405 oracle 37 29 10 272M 164M sleep 11:11 0.04% java
21681 oracle 1 59 0 1336M 1314M sleep 0:15 0.03% oracle
21663 oracle 1 59 0 1333M 1303M sleep 0:52 0.03% oracle
21673 oracle 17 59 0 1336M 1306M sleep 2:35 0.03% oracle
9702 oracle 7 59 0 34M 19M sleep 0:21 0.02% emagent
21683 oracle 1 59 0 1332M 1302M sleep 1:03 0.01% oracle
244 root 12 59 0 158M 4544K sleep 0:59 0.01% java
9723 oracle 1 59 0 1336M 1314M sleep 0:03 0.01% oracle
140 root 7 59 0 4752K 2672K sleep 0:25 0.01% picld
21671 oracle 16 59 0 1346M 1305M sleep 3:26 0.00% oracle
9428 oracle 1 59 0 1335M 1313M sleep 0:04 0.00% oracle
403 root 1 100 -20 3000K 1088K sleep 0:26 0.00% xntpd

Свободной памяти, как следует из приведенного скриншота, практически нет. Однако и подкачка как таковая заключается в 3 Мб за последние сутки. При этом и сама БД, и OEM ворочаются на удивление резво. Даже если учесть тот факт, что на указанной машине они и так не тормозили (на данной машине использованы достаточно веселые жесткие диски SAS 10K, которых 4 штуки).

На пулах ZFS, причем, находится только БД, полностью ПО Oracle и объектные библиотеки Native Compilation.

Хотя объем самой базы достаточно мал (это все-таки не боевая продуктивная система с терабайтами и терабайтами данных), все же реакция базы достаточно веселая, а OEM практически реагирует молниеносно.

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

Однако вылезло и несколько неприятных моментов - собственно, с самим Солярисом.

Первый момент - никаким усилиями не удалось выполнить JumpStart upgrade с версии 5/08 (при настроенной конфигурации для той же машины, причем предыдущий апгрейд с 8/07 до 5/08 был выполнено полностью hands-off и без единой проблемы). Обычные апгрейды были выполнены без единой заминки на четырех машинах (SPARC и x64), а вот Custom JumpStart обломался. В то же время, нулевая установка при помощи JS (в вариантах с установкой ZFS root pool и на UFS) проходит отлично.

С одним замечанием. В некоторых случаях sun_install не может определить из BIOS (на платформе X64) какой из дисков является загрузочным, а в конце установки не выполняет автоматическую перезагрузку и надо руками выполнять init 6 (хотя я грешу на конфигурацию Custom JumpStart).

Второй момент. Sun добавил поддежрку новых механизмов хэширования паролей (по FIPS):

#
# Copyright 2008 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
#ident "@(#)crypt.conf 1.2 08/05/14 SMI"
#
# The algorithm name __unix__ is reserved.

1 crypt_bsdmd5.so.1
2a crypt_bsdbf.so.1
md5 crypt_sunmd5.so.1
5 crypt_sha256.so.1
6 crypt_sha512.so.1

Однако, при выборе любого из них как дефолтного и смены пароля утилитой passwd вход пользователем, для которого осуществлялось перешифрование (которе делалось абсолютно честно, что проверялось командой cat /etc/shadow), становился принципиально невозможным. Правильный пароль не принимался. Работают эти механизмы или нет в текущих релизах ядра 10/08 - неизвестно. Информации в Интернете на тему этих двух типов хэширования в продуктивном Солярисе 10/08 на момент написания статьи найти не удалось.

Третий момент. Совершенно непонятно, какой логикой руководствуется инсталлятор, разбивая и распределяя пространство на ZFS root pool. Результаты работы df -h неочевидны. Посему достаточно непонятно, как это самое пространство будет использоваться при реальной эксплуатации и что делать с канонической догмой системного администрирования UNIX - все системные слайсы раздельно.

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

Компрессирование данных ZFS, конечно, круто - но достаточно непрактично, примерно как метровый член. :) (подобного функционала все наелись еще во времена Stacker/DrvSpace/DoubleSpace).

Основной закон сохранения IT гласит - "Либо экономятся ресурсы - либо обеспечивается высокая скорость. Обе этих цели одновременно принципиально недостижимы".

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

Стабильность нового релиза пока не вызывает нареканий, правда, и живет он всего ничего :)

Да будет его жизнь долгой и счастливой.

Аминь.

Enter.

PS. Пожалуй, все же дьявольски не хватает приличного инструмента (более приличного, нежели Live Upgrade) для миграции файловых систем с UFS на ZFS. Не всегда имеется в наличии еще один жесткий диск для означенной процедуры.

четверг, 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-системам и позволят легко и линейно наращивать производительность конечной системы. Вообще говоря, это утверждение (с рядом существенных оговорок) справедливо лишь в отношении вычислительных кластеров и соответствующих задач.