пятница, 26 декабря 2008 г.

Взгляд на кризис(ы) капитализма с точки зрения кибернетики

"Разруха не в сортирах, разруха в головах."
Профессор Преображенский

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

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

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

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

-==============================================
-= Verboten. Начиная с этого места школота и лица
-= с гуманитарным и квадратно -гнездовым способом
-= мышления могут дальше не читать. Опасно для здоровья.
-==============================================

Итак, есть два вида колебательных процессов. С положительной обратной связью и отрицательной обратной связью.

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

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

Примеры достаточно очевидны. К чему это?

Все просто. Практически тривиально.

Капитализм - процесс с положительной обратной связью.

Катни шарик на вершине горы - он будет стремиться укатиться вниз.

Почему?

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

Капитализм - именно такая система. Нет саморегулирования с отрицательной обратной связью. И быть этой отрицательной обратной связи не может по причине происхождения (генетического) капиталиста как вида.

Кризис - неизбежное следствие подъема. Это практически трюизм.

Почему так?

По определению.

Почему львиный прайд в Африке не подыхает с голоду? Можно ведь жрать мясо каждый день, набиваясь от пуза.

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

Иное дело - хомо сапиенс, домашние животные, грызуны, насекомые и прочие "высокоинтеллектуальные" представители фауны.

"После нас - хучь потоп". "Жри-пей-веселись - после смерти нет наслаждения". "Лучше один сожрет, чем трое понюхают". Ну и так далее.

Выжирается все. Дочиста. "Если не сожру я - сожрет другой. Так я хотя бы надкусаю - даже если уже не в состоянии жрать".

Причина? Начисто отсутствует чувство меры.

Вот и ответ. "Нет, я не могу позволить себе не становиться монополистом. Если этого не сделаю я - сделает конкурент."

Люди как тараканы выжирают все дочиста. "После нас хучь потоп!"

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

Исконные хищники (к каковым человек в общем-то, не относится) никогда не:

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

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

Ясно, да? Безудержное стремление к неограниченному росту прибыли - это фактор положительной обратной связи. В конце цикла развития которого неизбежно находится Толстый Полярный Лис. Сиречь песец.

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

"Будем поднимать квоту сэйлзам, пока не выгорят. Когда выгорят - наймем новых и будем продолжать жрать, жрать и жрать! Больше, больше прибыли! Еще больше! Еще, еще! Затаптываем конкурентов! Клиентов надо силком тащить - но чтоб деньги были!"

Знакомая музыка? А заканчивается чем - тоже догадаться нетрудно?

Это, мальчики и девочки, стратегия царя Мидаса. Которая имеет край - и весьма близкий.

Не надо только передергивать и называть стремление к неограниченной прибыли прогрессом (или его двигателем, что моночленственно). Поговорка про "капитализм стоит на краю пропасти..." отнюдь не фигура речи. Он на ней реально стоит - см.выше.

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

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

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

Решение на самом деле самоочевидно до глупости. Причем оно уже было.

Прогрессивный налог. Во-первых, на оборот, во-вторых, на прибыль, в-третьих, подоходный, и в-четвертых - на роскошь.

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

Фактор отрицательной обратной связи.

Единственное но - реальность, увы, такова, что это практически недостижимо.

Требуется несколько невыполнимых условий:

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

- Честная налоговая служба (а вот это оксюморон. Слова "честный" и "налоговая" подходят друг к другу, как кулак к носу).

- Жесточайшее исполнение налоговых кодексов.

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

Маленький пример из жизни текущего кризиса.

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

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

Зачем в стране с населением одного крупного города столько элитной жилой площади - тайна выше моего разумения. Однако:

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

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

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

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

Щаз.

Кто хотел - уже снял офис. Или купил.

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

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

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

Запасайтесь попкорном. Шоу только начинается. Лемминги еще с обрыва не прыгали.

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

PPS. Господа инженеры, мне, как и вам, прекрасно известно, что качающийся маятник и шарики в ямках и на горках не являются полными аналогами обратной связи. Я привел их лишь как примеры, понятные даже идиоту.
____________________
* Я имею в виду корректное определение кибернетики как науки об управлении процессами во времени. Думаю, никто не станет спорить, что все в жизни есть суть процесс во времени. Включая саму жизнь.
** На что у господина Маркса есть опять-таки замечательная цитата о безбашенности господ капиталистов - "... а при 400% прибыли капитал положительно готов сломать себе шею". Беда в том, что недоумки-капиталисты - они Маркса не читали никогда. К сожалению. В силу либо своего происхождения от гопоты и бандюганов, либо интеллектуального снобизма - что одночленственно.

среда, 17 декабря 2008 г.

Использование ZFS на USB-устройствах

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

Проведем небольшой эксперимент.

Возьмем флэшку USB 2.0 и создадим на ней ZFS-пул:

1. Выключим VOLD чтобы не путался под ногами ;)

# svcadm disable volfs

2. Определим имя устройства:

# rmformat -l

3. Создадим метку fdisk (на Solaris x86) и слайс:

# format -e

4. Построим ZFS-пул с точкой монтирования по нашему желанию:

# zpool create -f -m /mnt usbpool c1t0d0s0 *

где usbpool - имя, которое мы сами присвоили нашему USB-пулу.

Готово. Можно записывать и считывать. Пул создан и автоматически примонтирован на /mnt.

Однако - устройство-то съемное! А данный пул стал частью нашей системы. И, если мы отключим устройство, при перезапуске системы будут проблемы. Надо найти способ безопасного извлечения ZFS-пула usbpool.

А чего его искать, вот он:

# zpool export usbpool

Совсем готово. "МОЖНО ВЫНИМАТЬ!" :)

О'кей, вынули-походили-вставили.

Кстати, VOLD запускать не надо - он по умолчанию на Солярисе монтирует USB как pcfs-устройства на /rmdisk.

Возвращаем флэшку на родину.

Как ее увидеть, в таком случае?

Просто (надо помнить лишь имя пула):

# zpool import -f usbpool
# zpool clear usbpool

Успешный импорт ZFS-устройства автоматически монтирует его на заданную в ZFS устройства точку монтирования. Если свойство mountpoint задано как legacy или none -устройство монтируется вручную:

# mount -F zfs usbpool /mnt

Но нам, разумеется, удобней автоматическое монтирование пулов ZFS.

А теперь перечислим выясненные опытным путем (а также изучением мануалов) правила:

1. Устройство USB должно быть качественным. На флэшках сбойные блоки обнаруживаются практически сразу же, и никакая файловая система не относится к ним толерантно, несмотря ни на какие контрольные суммы и избыточное дублирование данных (параметр copies на ZFS для битых флэшек помогает плохо). Практически, битая флэшка обнаруживается сразу после создания пула, при запуске скруббинга (zpool scrub usbpool).

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

3. Лучше всего, когда на системах с "блуждающими" USB-пулами остановлен VOLD (SMF-сервис volfs).

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

Если придерживаться этих, в общем-то, нехитрых правил - то USB с ZFS вовсе не будет экзотикой, как и USB с UFS.

PS. В одной из следующих статей будет исследован вопрос возможности создания загрузочной ZFS-флэшки с Solaris 10 10/08.
_____________________
* Так зовут нашу флэшку - имя устройства определено командой rmformat. При работе с пулами можно не задавать полных путей типа /dev/rdsk... .

воскресенье, 14 декабря 2008 г.

My Review of Solaris 10 Operating System

Originally submitted at Sun Microsystems

Solaris Developer Center - The Source for Solaris Application Resources and Community


Excellent performance

By Solaris Professional User from Almaty, Kazakhstan on 12/14/2008

 

5out of 5

Pros: Fast and Powerful, Excellent performance, Great Features

Best Uses: Main server platform

Describe Yourself: Quality Oriented

Primary use: Business

Solaris 10 10/08 is the brilliant. Brilliant for every SA which is equipped by brain. :)
VERY fast, easy to install/upgrade and maintenance, very secure and rock-like stable. All our servers is upgraded onto 10/08 now (SPARC and x86x64) and shows the best results. and now, ZFS is the most value functionality. Now can be root fs, VERY fast - it equals systems with SAS and SATA drives. Looks like system works without HDD's. Excellent job!

(legalese)

суббота, 13 декабря 2008 г.

RAM-диски в Solaris, часть I

RAM-Диски в Solaris - вещь достаточно известная. Например, всем известен факт, что установка Solaris происходит через посредство RAM-диска.

Для непосвященных цитирую фрагмент man:

man ramdisk

Devices ramdisk(7D)

NAME
ramdisk - RAM disk device driver

SYNOPSIS
ramdisk@0:diskname

DESCRIPTION
The ramdisk driver supports numerous ramdisk devices that
are created by the system during the boot process (see
boot(1M)) or during normal system operation (see
ramdiskadm(1M) for more information).

DEVICE SPECIAL FILES
Each ramdisk can be accessed either as a block device or as
a raw device. When accessed as a block device, the normal
buffering mechanism is used when reading from and
writing to the device, without regard to physical disk
records. Accessing the ramdisk as a raw device enables
direct transmission between the disk and the read or write

[дальше поскипано, читайте мануалы сами ;)]

Оппоненты могут заметить, что в конце мануала прямо сказано:

A ramdisk may not be the best possible use of system memory.
Accordingly, use ramdisks only when absolutely necessary.

Но, к примеру - оперативная память сейчас стоит практически как грязь, есть машины с изобилием памяти - не редкость уже сервера начального уровня с 32 Гб и более RAM.

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

Как мы это делаем? "Всегда правой!" ;)

man ramdiskadm

System Administration Commands ramdiskadm(1M)

NAME
ramdiskadm - administer ramdisk pseudo device

SYNOPSIS
/usr/sbin/ramdiskadm -a name size [g | m | k | b]

/usr/sbin/ramdiskadm -d name

/usr/sbin/ramdiskadm

DESCRIPTION
The ramdiskadm command administers ramdisk(7D), the ramdisk
driver. Use ramdiskadm to create a new named ramdisk device,
delete an existing named ramdisk, or list information about
existing ramdisks.

Ramdisks created using ramdiskadm are not persistent across
reboots.

[дальше поскипано, читайте мануалы сами ;)]

Проверим?

Создадим диск:

root @ athena / # ramdiskadm -a ram1 512m
/dev/ramdisk/ram1

Сформатируем его в UFS:

root @ athena / # newfs /dev/ramdisk/ram1
/dev/rramdisk/ram1: Unable to find Media type. Proceeding with system determined parameters.
newfs: construct a new file system /dev/rramdisk/ram1: (y/n)? y
/dev/rramdisk/ram1: 1048200 sectors in 1747 cylinders of 1 tracks, 600 sectors
511.8MB in 110 cyl groups (16 c/g, 4.69MB/g, 2240 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 9632, 19232, 28832, 38432, 48032, 57632, 67232, 76832, 86432,
960032, 969632, 979232, 988832, 998432, 1008032, 1017632, 1027232, 1036832,
1046432

Смонтируем и посмотрим:

root @ athena / # mount /dev/ramdisk/ram1 /mnt
root @ athena / # df -h /mnt
Filesystem size used avail capacity Mounted on
/dev/ramdisk/ram1 480M 1.0M 431M 1% /mnt

Поиграемся:

root @ athena / # mkfile 256m /mnt/file.ufs
root @ athena / # ls -al /mnt
total 262290
drwxr-xr-x 3 root root 512 Dec 13 14:32 .
drwxr-xr-x 31 root root 1024 Dec 13 13:33 ..
-rw------T 1 root root 268435456 Dec 13 14:32 file.ufs
drwx------ 2 root root 8192 Dec 13 14:30 lost+found

Что ж, весьма быстро создается файл. RAM есть RAM.

Посмотрим, что у нас в устройствах (платформа SPARC):

root @ athena / # ramdiskadm
Block Device Size Removable
/dev/ramdisk/root 89702400 No
/dev/ramdisk/ram1 536870912 Yes

Надо же, кроме removable ram-диска создан еще неудаляемый root-диск.

Попробуем посмотреть, что на нем:

root @ athena / # mount /dev/ramdisk/root /mnt

panic[cpu0]/thread=300013bf5a0: BAD TRAP: type=31 rp=2a100815140 addr=51002000 mmu_fsr=0

mount: trap type = 0x31
addr=0x51002000
pid=735, pc=0x126a8d0, sp=0x2a1008149e1, tstate=0x4480001607, context=0x415
g1-g7: 0, 0, 1, 0, 1, 0, 300013bf5a0

000002a100814e60 unix:die+9c (31, 2a100815140, 51002000, 0, 2a100814f20, c11ec000)
........

Опачки, паника. Упала система. Так, не трогаем больше. :) Спасибо, что хоть sync выполнила.

Ладно, пойдем на систему x86 тогда и там проведем второй опыт.

root @ ktulhu / # ramdiskadm -a ram1 512m
ramdiskadm: couldn't create ramdisk "ram1": Resource temporarily unavailable

Так, сколько хотим мы памяти не можем забирать. Не выделяется. Уменьшим размер:

root @ ktulhu / # ramdiskadm -a ram1 384m
/dev/ramdisk/ram1

Ради спортивного интереса создадим файловую систему другого типа:

root @ ktulhu / # zpool create rampool1 /dev/ramdisk/ram1
root @ ktulhu / # zfs list rampool1
NAME USED AVAIL REFER MOUNTPOINT
rampool1 91K 346M 1K /rampool1

Посмотрим тип и свойства файловой системы:

root @ ktulhu / # fstyp /dev/ramdisk/ram1
zfs
root @ ktulhu / # fstyp -v /dev/ramdisk/ram1
zfs
version=10
name='rampool1'
state=0
txg=4
pool_guid=6334748904190478592
hostid=114097444
hostname='ktulhu'
top_guid=4892403041050478913
guid=4892403041050478913
vdev_tree
type='disk'
id=0
guid=4892403041050478913
path='/dev/ramdisk/ram1'
phys_path='/pseudo/ramdisk@1024:ram1'
whole_disk=0
metaslab_array=14
metaslab_shift=21
ashift=9
asize=397934592
is_log=0

Замечательно, RAM-диск с ZFS!

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

Поиграемся теперь с ним:

root @ ktulhu / # ramdiskadm
Block Device Size Removable
/dev/ramdisk/ram1 402653184 Yes

Так, никаких дополнительных дисков на x86 нет.

root @ ktulhu / # mkfile -v 256m /rampool/file.zfs
/rampool/file.zfs 268435456 bytes

root @ ktulhu / # ls -al /rampool
total 262191
drwxr-xr-x 2 root root 3 Dec 13 14:48 .
drwxr-xr-x 30 root root 40 Dec 13 14:46 ..
-rw------T 1 root root 268435456 Dec 13 14:48 file.zfs

Очень быстро создается. ZFS и сама-то по себе очень шустрая, а в памяти просто беспредельно быстро файловые операции происходит (понятное дело, что до определенных пределов - но при объемах "сотни мегабайт" все хорошо ;)).

Окей, дабы не портить систему, удалим пул и подумаем:

root @ ktulhu / # zpool destroy rampool
root @ ktulhu / # zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 13.7G 59.2G 37.5K /rpool
rpool/ROOT 7.66G 59.2G 18K /rpool/ROOT
rpool/ROOT/zfsBE 7.66G 59.2G 7.66G /
rpool/dump 2.00G 59.2G 2.00G -
rpool/swap 4.00G 63.0G 138M -

Первое. Если использовать RAM-диски, возникает, например, желание создавать их автоматически, в момент загрузки системы. Скажем, с автоматическим копированием содержимого некоторых точек монтирования в память и с обратной записью на диск при shutdown. Это можно сделать сравнительно просто, написав несложный SMF-сервис. Причем можно будет легко делать RAM-диски как с UFS, так и с ZFS - и пользоваться всеми преимуществами последней.

Второе. Для чего это использовать? Это уже администратор пусть думает :). Ясное дело, что не для размещения Oracle redo logs. Но некоторые применения достаточно очевидны. Там, где нужна скорость доступа и типовые операции с файловыми системами.

Говоря простым языком - инструмент есть, он работает, он тривиален. А где его применить - уже сами решайте.

пятница, 5 декабря 2008 г.

Патч Бармина и другие страшные слова

Патч Бармина - любимая шутка системных администраторов, оборудованных головным мозгом ;), над администраторами, не оборудованными оным - больше не действует в Солярисе 10.

Защита от дурака (fool proof) проникла и в наш последний бастион оборудованных головным мозгом и инстинктом самосохранения. :)

Попытка выполнить команду rm -rf / теперь обламывается:

server5# echo $0
-sh
server5# rm -rf /
rm of / is not allowed
server5# ksh
ksh:server5# rm -rf /
rm of / is not allowed
ksh:server5# bash
ksh:server5# rm -rf /
rm of / is not allowed

Вариация

server4# rm -rf --no-preserve-root /
rm: illegal option -- no-preserve-root
usage: rm [-fiRr] file ...

в лоб не работает. Нету такой опции в оригинальном rm у Solaris :).

Поставим на машину-жертву coreutils от GNU с Sunfreeware и повторим опыт:

server5# /usr/local/bin/rm -rf /
/usr/local/bin/rm: cannot remove root directory `/'

А вот то же самое с соответствующим ключом уже срабатывает:

Installation of was successful.
server4# /usr/local/bin/rm -rf --no-preserve-root /
(кирдык системе)

Однако не стоит обольщаться - все еще остается возможность вынести другие важные части системы и проделать это совершенно безнаказанно и, если и не приговорить систему, то уж нарваться на переустановку всяко:

server5# rm -rf /usr

Без usr Солярис не переходит в многопользовательский режим, так что...

Посмотрим, что еще можно сделать в плане причинения наибольших разрушений от рута. ;)

Попробуем, например, поубивать системные процессы:

server5# ps -ef |more
UID PID PPID C STIME TTY TIME CMD
root 0 0 0 04:29:09 ? 0:08 sched
root 1 0 0 04:29:10 ? 0:01 /sbin/init
root 2 0 0 04:29:10 ? 0:00 pageout
root 3 0 0 04:29:10 ? 0:04 fsflush

server5# kill -9 3
server5# kill -9 2
server5# kill -9 1
kill: permission denied
server5# kill -9 0

server5 console login: root
Password:
Last login: Fri Dec 5 05:08:47 on console
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
Welcome to SA100-S10_B on server5
server5# ps -ef|more
UID PID PPID C STIME TTY TIME CMD
root 0 0 0 04:29:09 ? 0:08 sched
root 1 0 0 04:29:10 ? 0:01 /sbin/init
root 2 0 0 04:29:10 ? 0:00 pageout
root 3 0 0 04:29:10 ? 0:04 fsflush

Ух ты, не получается!

Посылка сигнала KILL процессу 0 (планировщику) всего лишь выкидывает нас на login - но и только. Init убить напрямую нельзя. Процессу 2 и 3, похоже, все равно - их даже не поцарапало. :)

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

PS. Замаскированный патч Бармина:

perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see'

тоже больше не причиняет вреда Солярису. Он просто не выполняется по очевидным причинам, рассмотренным выше. :) Если только кто-нибудь не перепишет его на вызов coreutils. ;)

PPS. Все вышеперечисленное тестировалось вживую на Solaris 10 10/08 SPARC.
_______________________
Автор снимает с себя любую ответственность за тестирование всего вышеперечисленного на продуктивных системах администраторами, не оборудованными головным мозгом, в случае каких-либо деструктивных последствий. ;)

среда, 3 декабря 2008 г.

Миграция UFS -> ZFS на Solaris 10 10/08 x86 - Часть 2

В новом номере нашего журнала мы приступаем к описанию процедуры посадки самолета. ;)

После активации и загрузки системы с диска с ZFS останется одна небольшая проблемка:

# lustatus
Boot Environment Is Active Active Can Copy
Name Complete Now On Reboot Delete Status
----------------- -------- ------ --------- ------ ----------
ufsBE yes no no no -
zfsBE yes yes yes no -

Оригинальный BE все еще нельзя удалять. Почему же?

Потому что в результате миграции на ZFS переброшены все слайсы UFS, кроме /export. Который на нашем сервере был смонтирован следующим образом (кусок содержимого /etc/vfstab):

/dev/dsk/c0d1s7 /dev/rdsk/c0d1s7 /export/home ufs 2 yes -

Нам нужно, таким образом, перенести содержимое точки монтирования /export на ZFS (на второй диск) и оторвать первый диск от zfsBE.

Как мы это сделаем?

Наиболее очевидным и напрашивающимся способом:

# mkdir /backup
# cd /export/home
# find . -print|cpio -pudm /backup
# cd /; umount /export/home
# cd /backup; mkdir -p /export/home; \
find . -print|cpio -pudm /export/home


Закомментируем ссылку на /export/home в файле /etc/vfstab. Содержимое /etc/vfstab:

#live-upgrade: updated boot environment
#device device mount FS fsck mount mount
#to mount to fsck point type pass at boot options
#
fd - /dev/fd fd - no -
/proc - /proc proc - no -
#live-upgrade::# /dev/dsk/c0d1s1 - - swap - no -
/dev/zvol/dsk/rpool/swap - - swap - no -
#live-upgrade::# /dev/dsk/c0d1s0 /dev/rdsk/c0d1s0 / ufs 1 no -
#live-upgrade::# /dev/dsk/c0d1s3 /dev/rdsk/c0d1s3 /usr ufs 1 no -
#live-upgrade::# /dev/dsk/c0d1s5 /dev/rdsk/c0d1s5 /var ufs 1 no -
#/dev/dsk/c0d1s7 /dev/rdsk/c0d1s7 /export/home ufs 2 yes -
#live-upgrade::# /dev/dsk/c0d1s4 /dev/rdsk/c0d1s4 /opt ufs 2 yes -
/devices - /devices devfs - no -
ctfs - /system/contract ctfs - no -
objfs - /system/object objfs - no -
swap - /tmp tmpfs - yes -
sharefs - /etc/dfs/sharetab sharefs - no -

Однако после перезапуска мы все еще не можем удалить первый диск:

# lustatus
Boot Environment Is Active Active Can Copy
Name Complete Now On Reboot Delete Status
----------------- -------- ------ --------- ------ ----------
ufsBE yes no no no -
zfsBE yes yes yes no -
Поиск в документации не дал способа удалить точку монтирования /export/home из zfsBE. Попробуем силовым способом и повторно активируем zfsBE:

# luactivate zfsBE

Не забыв снова поправить /rpool/boot/grub/menu.lst (активация его снова исковеркала до первоначального состояния), перезапускаемся и смотрим статус:

# lustatus
Boot Environment Is Active Active Can Copy
Name Complete Now On Reboot Delete Status
----------------- -------- ------ --------- ------ ----------
ufsBE yes no no yes -
zfsBE yes yes yes no -
Отлично, ufsBE освободилась, можно удалять ufsBE, отключать диск, реконфигурировать систему и очищать директории /dev и /devices от ссылок на первый диск.

Поздравляю, ваш самолет только что произвел посадку. ;)

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

вторник, 2 декабря 2008 г.

Миграция UFS -> ZFS на Solaris 10 10/08 x86 - Часть 1

Миграция обычных UFS систем на ZFS - задача достаточно простая и обычно не вызывает серьезных проблем.

Новый релиз Solaris 10, однако, помимо изменений в процедуре загрузки для обеих архитектур (SPARC и x86) и возможности установки на ZFS всей системы (на загрузочный root-pool) позволяет также выполнить миграцию системы с UFS на ZFS.

Простой утилиты конвертации на данный момент не существует, все же файловые системы отличаются достаточно сильно и, несмотря на усилия команды разработчиков OpenSolaris, единственной доступной процедурой остается использование одной достаточно экзотической функциональности Solaris - Live Upgrade.

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

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

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

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

Дано: Есть инфраструктурный сервер, работавший в качестве прокси, под управлением Solaris 10 08/07, с архитектурой x86:

1 CPU Intel Celeron 2.26 ГГц
2 Гб DDR RAM
1 жесткий диск ATA 80 Гб, разбитый на 5 слайсов
1 DVD-ROM
2 NIC Intel Pro 100B

Задача: Выполнить обновление до релиза 10/08, и, следующим шагом, мигрировать UFS на ZFS с загрузкой с ZFS-пула.

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

После установки и наката небольшого количества патчей, приступаем, собственно, ко второй части - к переходу на ZFS.

Как и сказано в руководстве, устанавливаем второй диск - для облегчения задачи берем в точности такой же ATA 80 Гб, с одинаковой геометрией и однотипным контроллером, и подключаем его к серверу. Реконфигурируемся. Создаем таблицу разделов FDISK на весь объем диска (как у оригинального загрузочного диска 1) типа SOLARIS1 и делаем ее активной.

Затем, используя утилиту format, создаем корневой слайс s0 (согласно оставшимся цилиндрам, начиная с 3го и до конца диска).

Следующим шагом создаем на нем пул ZFS:

# zpool create -f rpool c1d1s0

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

Затем, согласно все тому же руководству, создаем оригинальный Boot Environment на текущем диске (назовем его ufsBE) и, далее, в точности по руководству, на его основе - zfsBE на пуле ZFS:

# lucreate -c ufsBE -n zfsBE -p rpool
Analyzing system configuration.
No name for current boot environment.
Current boot environment is named .
Creating initial configuration for primary boot environment .
The device
is not a root device for any boot environment;
cannot get BE ID.
PBE configuration successful: PBE name PBE Boot Device .
Comparing source boot environment file systems with the file
system(s) you specified for the new boot environment.
Determining which file systems should be in the
new boot environment.
Updating boot environment description database on all BEs.
Updating system configuration files.
The device
is not a root device for any boot environment;
cannot get BE ID.
Creating configuration for boot environment .
Source boot environment is .
Creating boot environment .
Creating file systems on boot environment .
Creating file system for in zone on .
Populating file systems on boot environment .
Checking selection integrity.
Integrity check OK.
Populating contents of mount point
.
Copying.
Creating shared file system mount points.
Creating compare databases for boot environment .
Creating compare database for file system
.
Creating compare database for file system
.
Updating compare databases on boot environment .
Making boot environment bootable.
Creating boot_archive for /.alt.tmp.b-zv.mnt
updating /.alt.tmp.b-zv.mnt/platform/i86pc/boot_archive
Population of boot environment successful.
Creation of boot environment successful.

Замечание: Может потребоваться переименование root pool (на самом деле пофигу, как он будет называться, хоть горшком ;)), если вы выполняете восстановление системы (скажем, с голого металла восстановились из flar-архива, который в текущей версии выполняет восстановление только на UFS, и вы хотите вернуть все взад - сиречь на ZFS).

Операция занимает некоторое время, порядка 15-25 минут приходится подождть завершения копирования и сравнения. Все это время оригинальная система продолжает активно работать.

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

Итак, что нужно сделать после подготовки нового BE и ДО активации и перезапуска с нового BE:

1. В обязательном порядке установить загрузчик на второй диск:

# installgrub /boot/grub/stage1 /boot/grub/stage2 \
/dev/rdsk/c1d1s0
Потому что его там еще нет и, при попытке активации и загрузки прямо сейчас, будет ошибка Bad PBR sig. Почти каноническая.

2. Обязательно проверить точки монтирования созданной среды загрузки ZFS (как описано здесь):

# zfs list -r -o name,mountpoint rpool/ROOT/zfsBE

NAME MOUNTPOINT
rpool/ROOT/zfsBE /.alt.tmp.b-VP.mnt/

и, если таковые будут (а они будут из-за ошибок в Live Upgrade в текущем релизе - 10/08), исправить их:
# zfs inherit -r mountpoint rpool/ROOT/zfsBE
# zfs set mountpoint=/ rpool/ROOT/zfsBE


3. Последнее наведение штрихов (без него, однако, загрузка с нового диска будет невозможна) перед перезагрузкой:

Активизируем zfsBE командой

# luactivate zfsBE

однако НЕ ПЕРЕЗАГРУЖАЕМСЯ НЕМЕДЛЕННО, как требует руководство!

Необходимо исправить menu.lst загрузчика GRUB на корневом пуле ZFS. Вопреки заявлению Live Upgrade, меню не изменено необходимым образом для загрузки с ZFS.

Итак, редактируем его (необходимые изменения выделены красным):

# cd /rpool/boot/grub
# vi menu.lst
....
#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
title Solaris 10 10/08 s10x_u6wos_07b X86
findroot (BE_zfsBE,0,a)
bootfs rpool/ROOT/zfsBE
kernel$ /platform/i86pc/multiboot -B $ZFS-BOOTFS
module /platform/i86pc/boot_archive
#---------------------END BOOTADM--------------------
#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
title Solaris failsafe
findroot (BE_zfsBE,0,a)
kernel /boot/multiboot kernel/unix -s
module /boot/x86.miniroot-safe
#---------------------END BOOTADM--------------------
....
Осталась мелочь. Процедура активации не только не изменила меню загрузчика, но и не перенесла файл /boot/grub/splash.xpm.gz на корневой пул ZFS, без него не будет видно меню загрузчика (совсем) и система будет сразу грузиться в опасный режим без возможности стартовать в безопасном ;). Можно, конечно, и забить на это, просто закомментировав строку #splashimage /boot/grub/splash.xpm.gz в menu.lst - тогда меню будет текстовым (что, собственно, нас устраивает как нельзя лучше - автор так и сделал), а можно стащить файл с пока еще живой UFS и положить его рядом с menu.lst в root pool:

# cp /boot/grub/splash.xpm.gz /rpool/boot/grub
Вот теперь действительно все. Можно перезагружаться и стартовать со второго диска:

# init 6

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

Решение данной задачи будет рассмотрено во второй части статьи.

PS. "Дорогие читатели, мы закончили описание процедуры взлета на самолете в нашем журнале "Пилотирование для чайников". Желаем приятного полета! Подробное описание процедуры посадки - в следующем номере. До новых встреч, дорогие друзья!" ;)
______________________
* Оставим пока на совести разработчиков тот факт, что с новым релизом есть серьезные проблемы в выполнении обновления hands-off методом JumpStart для архитектуры x86/x64. Без проблем удалось провести только начальную установку посредством JS.

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