SMI и EFI

Один из наиболее часто задаваемых вопросов на курсе SA-200-S10 - в чем разница между метками SMI и EFI жестких дисков и что вообще означают эти аббревиатуры?

JFGI сообщает нам, что :

SMI означает Sun Microsystems Incorporated, а
EFI означает Extensible Firmware Interface.

Что ж, логично. Первый тип меток - это, собственно, оригинальная сановская таблица разделов о восьми слайсах, с s0 по s7 при неиспользуемом в обычных условиях s2, означающем весь диск:

Part Tag Flag Cylinders Size Blocks
0 root wm 0 - 25 129.19MB (26/0/0) 264576
1 swap wu 26 - 51 129.19MB (26/0/0) 264576
2 backup wu 0 - 14086 68.35GB (14087/0/0) 143349312
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 0 0 (0/0/0) 0
6 usr wm 52 - 14086 68.10GB (14035/0/0) 142820160
7 unassigned wm 0 0 (0/0/0) 0

Именно такой тип метки использует по умолчанию (не в экспертном режиме) утилита format, именно этот тип требуется для того, чтобы с диска можно было загружаться, именно этот тип используют при разметке диска/слайса в UFS.

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

server5# format -e
Searching for disks...done

AVAILABLE DISK SELECTIONS:
0. c0t0d0 /pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/sd@0,0
1. c0t1d0 /pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/sd@1,0
Specify disk (enter its number): 0
selecting c0t0d0
[disk formatted]

FORMAT MENU:
disk - select a disk
type - select (define) a disk type
partition - select (define) a partition table
current - describe the current disk
format - format and analyze the disk
repair - repair a defective sector
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels
save - save new disk/partition definitions
inquiry - show vendor, product and revision
scsi - independent SCSI mode selects
cache - enable, disable or query SCSI disk cache
volname - set 8-character volume name
! - execute , then return
quit
format> label
[0] SMI Label
[1] EFI Label
Specify Label type[0]: 1
Warning: This disk has an SMI label. Changing to EFI label will erase all
current partitions.
Continue? y
format> partition

PARTITION MENU:
0 - change `0' partition
1 - change `1' partition
2 - change `2' partition
3 - change `3' partition
4 - change `4' partition
5 - change `5' partition
6 - change `6' partition
7 - change `7' partition
8 - change '8' partition
select - select a predefined table
modify - modify a predefined partition table
name - name the current table
print - display the current table
label - write partition map and label to the disk
! - execute , then return
quit
partition> print
Current partition table (default):
Total disk sectors available: 143358320 + 16384 (reserved sectors)

Part Tag Flag First Sector Size Last Sector
0 usr wm 34 68.36GB 143358320
1 unassigned wm 0 0 0
2 unassigned wm 0 0 0
3 unassigned wm 0 0 0
4 unassigned wm 0 0 0
5 unassigned wm 0 0 0
6 unassigned wm 0 0 0
7 unassigned wm 0 0 0
8 reserved wm 143358321 8.00MB 143374704

Что мы видим?

Во-первых, разница в структуре метки.

Нулевой слайс имеет тэг usr, а не root - что автоматически означает невозможность загрузки с этого диска. Это понятно.

Восьмой слайс, который нельзя модифицировать - это, очевидно, резерв на замену секторов.

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

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

server5# newfs /dev/rdsk/c0t0d0s0
newfs: construct a new file system /dev/rdsk/c0t0d0s0: (y/n)? y
Warning: 5810 sector(s) in last cylinder unallocated
/dev/rdsk/c0t0d0s0: 143358286 sectors in 23334 cylinders of 48 tracks, 128 sectors
69999.2MB in 1459 cyl groups (16 c/g, 48.00MB/g, 5824 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 98464, 196896, 295328, 393760, 492192, 590624, 689056, 787488, 885920,
Initializing cylinder groups:
............................
super-block backups for last 10 cylinder groups at:
142447776, 142546208, 142644640, 142743072, 142841504, 142939936, 143038368,
143136800, 143235232, 143333664

Так, в UFS сформатировали. Враки. Для блезира попробуем протестировать и смонтировать диск с EFI+UFS:

server5# fsck -y /dev/rdsk/c0t0d0s0
** /dev/rdsk/c0t0d0s0
** Last Mounted on
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3a - Check Connectivity
** Phase 3b - Verify Shadows/ACLs
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cylinder Groups
2 files, 9 used, 70593599 free (15 frags, 8824198 blocks, 0.0% fragmentation)
server5# mount /dev/dsk/c0t0d0s0 /mnt
server5# df -h /mnt
Filesystem size used avail capacity Mounted on
/dev/dsk/c0t0d0s0 67G 64M 67G 1% /mnt

Нет проблем. UFS на дисках с EFI использовать можно.

Окей, что дальше?

Разумеется, ZFS-пул на таком диске создать можно. Собственно, утверждается, что именно такая метка создается на диске при добавлении диска в нерутовый пул. Проверим и это:

Сначала разрушим метку:

server5# umount /mnt
server5# format -e
Searching for disks...done

AVAILABLE DISK SELECTIONS:
0. c0t0d0
/pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/sd@0,0
1. c0t1d0
/pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/sd@1,0
Specify disk (enter its number): 0
selecting c0t0d0
[disk formatted]

FORMAT MENU:
disk - select a disk
type - select (define) a disk type
partition - select (define) a partition table
current - describe the current disk
format - format and analyze the disk
repair - repair a defective sector
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels
inquiry - show vendor, product and revision
scsi - independent SCSI mode selects
cache - enable, disable or query SCSI disk cache
volname - set 8-character volume name
! - execute , then return
quit
format> label
[0] SMI Label
[1] EFI Label
Specify Label type[1]: 0
Warning: This disk has an EFI label. Changing to SMI label will erase all
current partitions.
Continue? y
Auto configuration via format.dat[no]? yes
format> partition

PARTITION MENU:
0 - change `0' partition
1 - change `1' partition
2 - change `2' partition
3 - change `3' partition
4 - change `4' partition
5 - change `5' partition
6 - change `6' partition
7 - change `7' partition
select - select a predefined table
modify - modify a predefined partition table
name - name the current table
print - display the current table
label - write partition map and label to the disk
! - execute , then return
quit
partition> print
Current partition table (default):
Total disk cylinders available: 14087 + 2 (reserved cylinders)

Part Tag Flag Cylinders Size Blocks
0 root wm 0 - 25 129.19MB (26/0/0) 264576
1 swap wu 26 - 51 129.19MB (26/0/0) 264576
2 backup wu 0 - 14086 68.35GB (14087/0/0) 143349312
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 0 0 (0/0/0) 0
6 usr wm 52 - 14086 68.10GB (14035/0/0) 142820160
7 unassigned wm 0 0 (0/0/0) 0

Разрушили EFI и снова создали SMI. Построим пул ZFS на этом диске:

server5# zpool create -f data c0t0d0
server5# zpool status
pool: data
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
c0t0d0 ONLINE 0 0 0

errors: No known data errors
server5# format -e
Searching for disks...done

AVAILABLE DISK SELECTIONS:
0. c0t0d0
/pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/sd@0,0
1. c0t1d0
/pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/sd@1,0
Specify disk (enter its number): 0
selecting c0t0d0
[disk formatted]
/dev/dsk/c0t0d0s0 is part of active ZFS pool data. Please see zpool(1M).

FORMAT MENU:
disk - select a disk
type - select (define) a disk type
partition - select (define) a partition table
current - describe the current disk
format - format and analyze the disk
repair - repair a defective sector
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels
inquiry - show vendor, product and revision
scsi - independent SCSI mode selects
cache - enable, disable or query SCSI disk cache
volname - set 8-character volume name
! - execute , then return
quit
format> partition

PARTITION MENU:
0 - change `0' partition
1 - change `1' partition
2 - change `2' partition
3 - change `3' partition
4 - change `4' partition
5 - change `5' partition
6 - change `6' partition
7 - change `7' partition
8 - change '8' partition
select - select a predefined table
modify - modify a predefined partition table
name - name the current table
print - display the current table
label - write partition map and label to the disk
! - execute , then return
quit
partition> print
Current partition table (original):
Total disk sectors available: 143358320 + 16384 (reserved sectors)

Part Tag Flag First Sector Size Last Sector
0 usr wm 256 68.36GB 143358320
1 unassigned wm 0 0 0
2 unassigned wm 0 0 0
3 unassigned wm 0 0 0
4 unassigned wm 0 0 0
5 unassigned wm 0 0 0
6 unassigned wm 0 0 0
7 unassigned wm 0 0 0
8 reserved wm 143358321 8.00MB 143374704

Действительно, при создании ZFS-пула в нотации дисков cxtydz на диск автоматически записывается метка EFI.

Дабы не занимать место, замечу, что если использовать при создании пула нотацию логических устройств со слайсами, то метка останется SMI (что и требуется при создании ZFS root pool).

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

Как справедливо заметил один знакомый системный инженер Sun: "Мы не разбиваем диски, как на PC. Sun не настольная система. Мы их объединяем."

Давайте воспользуемся подвернувшимся сервером и проделаем еще один небольшой эксперимент и посмотрим, нельзя ли, случайно, на диске с меткой EFI создать более чем один слайс (восьмой мы не считаем):

server5# zpool destroy data
server5# format -e
Searching for disks...done

AVAILABLE DISK SELECTIONS:
0. c0t0d0
/pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/sd@0,0
1. c0t1d0
/pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/sd@1,0
Specify disk (enter its number): 0
selecting c0t0d0
[disk formatted]

FORMAT MENU:
disk - select a disk
type - select (define) a disk type
partition - select (define) a partition table
current - describe the current disk
format - format and analyze the disk
repair - repair a defective sector
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels
inquiry - show vendor, product and revision
scsi - independent SCSI mode selects
cache - enable, disable or query SCSI disk cache
volname - set 8-character volume name
! - execute , then return
quit
format> partition

PARTITION MENU:
0 - change `0' partition
1 - change `1' partition
2 - change `2' partition
3 - change `3' partition
4 - change `4' partition
5 - change `5' partition
6 - change `6' partition
7 - change `7' partition
8 - change '8' partition
select - select a predefined table
modify - modify a predefined partition table
name - name the current table
print - display the current table
label - write partition map and label to the disk
! - execute , then return
quit
partition> print
Current partition table (original):
Total disk sectors available: 143358320 + 16384 (reserved sectors)

Part Tag Flag First Sector Size Last Sector
0 usr wm 256 68.36GB 143358320
1 unassigned wm 0 0 0
2 unassigned wm 0 0 0
3 unassigned wm 0 0 0
4 unassigned wm 0 0 0
5 unassigned wm 0 0 0
6 unassigned wm 0 0 0
7 unassigned wm 0 0 0
8 reserved wm 143358321 8.00MB 143374704

partition> 0
Part Tag Flag First Sector Size Last Sector
0 usr wm 256 68.36GB 143358320

Enter partition id tag[usr]:
Enter partition permission flags[wm]:
Enter new starting Sector[256]:
Enter partition size[143358065b, 143358320e, 69999mb, 68gb, 0tb]: 30gb
partition> print
Current partition table (unnamed):
Total disk sectors available: 143358320 + 16384 (reserved sectors)

Part Tag Flag First Sector Size Last Sector
0 usr wm 256 30.00GB 62914815
1 unassigned wm 0 0 0
2 unassigned wm 0 0 0
3 unassigned wm 0 0 0
4 unassigned wm 0 0 0
5 unassigned wm 0 0 0
6 unassigned wm 0 0 0
7 unassigned wm 0 0 0
8 reserved wm 143358321 8.00MB 143374704

partition> 1
Part Tag Flag First Sector Size Last Sector
1 unassigned wm 0 0 0

Enter partition id tag[usr]: backup
Enter partition permission flags[wm]:
Enter new starting Sector[62914816]:
Enter partition size[0b, 62914815e, 0mb, 0gb, 0tb]: 30gb
partition> print
Current partition table (unnamed):
Total disk sectors available: 143358320 + 16384 (reserved sectors)

Part Tag Flag First Sector Size Last Sector
0 usr wm 256 30.00GB 62914815
1 backup wm 62914816 30.00GB 125829375
2 unassigned wm 0 0 0
3 unassigned wm 0 0 0
4 unassigned wm 0 0 0
5 unassigned wm 0 0 0
6 unassigned wm 0 0 0
7 unassigned wm 0 0 0
8 reserved wm 143358321 8.00MB 143374704

partition> label
[0] SMI Label
[1] EFI Label
Specify Label type[1]: 1
Ready to label disk, continue? y

partition> print
Current partition table (unnamed):
Total disk sectors available: 143358320 + 16384 (reserved sectors)

Part Tag Flag First Sector Size Last Sector
0 usr wm 256 30.00GB 62914815
1 backup wm 62914816 30.00GB 125829375
2 unassigned wm 0 0 0
3 unassigned wm 0 0 0
4 unassigned wm 0 0 0
5 unassigned wm 0 0 0
6 unassigned wm 0 0 0
7 unassigned wm 0 0 0
8 reserved wm 143358321 8.00MB 143374704

Хм, получилось.

Замечание. Обратите внимание, что при разбиении диска с EFI очень трудно наступить на грабли overlapping. Разделы создаются встык один к другому и без мертвого пространства. Йа-хуууууууу!

Замечание 2. На самом деле overlapping можно вызвать и на EFI. Только при создании слайсов один за другим начиная с нулевого, и при изменении его размера с максимального до меньшего - встык - это будет очень и очень трудно.

Попробуем разметить их в UFS и смонтировать, гулять так гулять:

server5# newfs /dev/rdsk/c0t0d0s0
newfs: construct a new file system /dev/rdsk/c0t0d0s0: (y/n)? y
/dev/rdsk/c0t0d0s0: 62914560 sectors in 10240 cylinders of 48 tracks, 128 sectors
30720.0MB in 640 cyl groups (16 c/g, 48.00MB/g, 5824 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 98464, 196896, 295328, 393760, 492192, 590624, 689056, 787488, 885920,
Initializing cylinder groups:
............
super-block backups for last 10 cylinder groups at:
61938464, 62036896, 62135328, 62233760, 62332192, 62430624, 62529056,
62627488, 62725920, 62824352
server5# newfs /dev/rdsk/c0t0d0s1
newfs: construct a new file system /dev/rdsk/c0t0d0s1: (y/n)? y
/dev/rdsk/c0t0d0s1: 62914560 sectors in 10240 cylinders of 48 tracks, 128 sectors
30720.0MB in 640 cyl groups (16 c/g, 48.00MB/g, 5824 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 98464, 196896, 295328, 393760, 492192, 590624, 689056, 787488, 885920,
Initializing cylinder groups:
............
super-block backups for last 10 cylinder groups at:
61938464, 62036896, 62135328, 62233760, 62332192, 62430624, 62529056,
62627488, 62725920, 62824352
server5# mkdir /tmp/s0
server5# mkdir /tmp/s1
server5# mount /dev/dsk/c0t0d0s0 /tmp/s0
server5# mount /dev/dsk/c0t0d0s1 /tmp/s1
server5# df -h /tmp/s0
Filesystem size used avail capacity Mounted on
/dev/dsk/c0t0d0s0 30G 30M 29G 1% /tmp/s0
server5# df -h /tmp/s1
Filesystem size used avail capacity Mounted on
/dev/dsk/c0t0d0s1 30G 30M 29G 1% /tmp/s1

Так. Диск с EFI можно партиционировать. Хорошая новость.

Финальное замечание. EFI принципиально предназначается для дисков или LUN терабайтных размеров. То, что мы можем использовать UFS и создавать более одного слайса - не везде описано и далеко не все знают.

Не стесняйтесь проверять самостоятельно спорные утверждения.

Кошки вкусные II

Только недавно я писал о том, что кошки на самом деле вкусные. А вот и Брендан Грегг подтверждает, что все дело в правильном их приготовлении:

Пруфлинк часть 1
Пруфлинк часть 2
Пруфлинк часть 3

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

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

Облако без штанов или Приходит Cloud Computing

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

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

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

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

Как IPv6. "IP-адрес - каждой кофеварке!"

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

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

Этакий философский камень, алкагест и панацея в одном флаконе. "Открываемая" каждые три-четыре года.

NetPC. Кластеры. Grid computing - кстати, найдите 10 различий с Cloud computing - и RAC.

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

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

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

В свое время на этом не по-детски обожглись апологеты RAC - "Не надо переписывать приложения - они будут работать как раньше!"

Что, мальчики и девочки, очередная "новая" чудо-технология сумрачных гениев раз и навсегда порешала ваши проблемки?

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

Второе. Все это было бы чрезвычайно забавно, если бы не было настолько грустно. Абсолютно узкоспециализированное решение виртуализации и концепции вычислительных суперкластеров тащат в сферу бизнес- и Интернет-приложений. Причем ежу понятно, что идея "Resources on demand" совершенно не нова. Так же ежу понятно, что, хотя концепция виртуальных систем и восходит к безопасности, и управляемости, однако в облаке (в силу огромной концентрации ресурсов и приложений в одном флаконе) будет совершенно нереально обеспечить единую модель безопасности - даже с применением гипервизоров и контейнеров, а так же нереально обеспечить единообразное распределение приложений по физическим ресурсам (что понравится далеко не всем приложениям, например, совершенно неясно, как будет осуществляться привязка приложений - affinity - с критичным временем отклика - к одним и тем же ресурсам облака). Для вычислительных задач это практически не имеет значения, но мир IT состоит главным образом не из вычислительных задач - соответственно, so what?

Да, Amazon это использует. В своей весьма специализированной сфере. Использует всего ничего, чтобы трубить в фанфары и кричать об очередной "победе разума над сарсапариллой". Рано пока еще о чем-то говорить. И я практически уверен, что неспециализированных приложений в облаках Амазон нет и пока не предвидится.

Но что мне абсолютно непонятно, так это третье.

Третье. Если и есть какая-то математическая модель и теория облачных вычислений - она мне неизвестна. Как всем этим управлять?

В теории - концепция cloud computing, пожалуй, ближе всего к MPP - массивно-параллельным архитектурам. NB - примите во внимание тот факт, что удовлетворительной и полной теории, пригодной к употреблению, для MPP за все время существования подобных систем создать как-то не удалось.

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

Может быть, администрировать облака будут сами клиенты таких систем? Делать резервные копии, устанавливать политики безопасности, настраивать управление ресурсами?

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

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

Все вышеприведенные ссылки на тему безопасности лично меня убеждают точно так же, как WEP в Wi-Fi.

Кстати, и здесь история воспроизводится с точностью до.

Сперва родили технологию, выпустили джина из бутылки ее на рынок, а затем ломанулись дорабатывать, обнаружив, что, оказывается, и криптография слабовата, и аутентификация не бог весть что, да и вообще - нафига мы это сделали? Wardriving задолбал!

Но, как заявляют апологеты - как круто, сидя утром на унитазе, читать на iPhone новости по Wi-Fi!

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

Такое гордое слово "прогресс".

Однако я отвлекся.

Чем особенным может похвастаться облако?

Да ничем особенным. В настоящее время видно лишь типичную маркетинговую возню и скороспелые (и абсолютно волюнтаристские) заявления вендоров, которые наперебой уверяют, что у них-то и есть единственное ULTIMATE-решение, полностью готовое, я цитирую дословно рекламную рассылку одного вендора - "Cloud computing promises a lot - and it will deliver".

Все это именно что promises. Будет ли deliver - еще бабка надвое сказала.

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

И для этого у меня есть все основания.

Infrastructure as a Service (IaaS) - не завершенная и всеохватывающая теория с решением. Это не более, чем architectural approaches.

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

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

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

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

Quality этого самого IaaS вызывает большие сомнения в связи с affinity приложений и процессов, с существующими ограничениями Ethernet (который ныне суют куда надо и куда не надо), IPv4 (а жизнеспособность IPv6 лично для меня все еще под очень большим сомнением) и другими инженерными ограничениями.

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

Это ничего, что просто по закону больших чисел вероятность отказа такой чертовой кучи оборудования (даже если это оборудование HA-класса) сильно отличается от нуля в сторону увеличения?

Это ничего, что закон Амдала-то действует и производительность в идеальном случае просто не вырастет?

А еще у меня есть реальные сомнения (с учетом вышесказанного), что перестав оплачивать собственную IT-инфраструктуру, потребители не станут платить больше за IaaS.

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

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

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

Сначала SAN.

Физически одиночный узел SAN представляет из себя как правило не слишком суровый серверок с кучей подключенных напрямую дисков, на которых развернут software RAID. Обычно не слишком навороченный (деньги-деньги-дребеденьги). Обычно не слишком настраиваемый. Обычно слишком обобщенный, чтобы быть реально быстрым (оставим пока в покое системы хранения Hi-End класса - там другие порядки стоимости и другая цена вопроса).

Этот самый серверок доступен по Ethernet. Несколько гигабитных интерфейсов. Либо 10 Гбит Ethernet (все помнят, сколько стоят такие интерфейсы?).

Кстати, о 10 Гбит Ethernet. Для того, чтобы реально загрузить подобную карточку на 100% вводом-выводом, требуется совсем даже не полная мощность одного процессора. Так, для информации.

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

И все это помимо того, что Ethernet принципиально не предназначен для упорядоченной потоковой передачи информации, как, например, SCSI/SAS. О чем речь пойдет во втором примере.

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

Теперь то, что часто используют в SAN - iSCSI.

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

Те, кто реально работал с iSCSI, знает, насколько непригоден TCP/IP+Ethernet для замены FC-AL/SAS/SCSI.

Прежде всего, низкая надежность. Малейшая контактная проблема - и iSCSI-устройство отлетает на полном скаку от сервера, который с ним работает. Зачастую толстый полярный лис прямо в этот момент подстерегает файловую систему. Прошу заметить - введение свича в систему (а это принципиально понадобится, скажем, при использовании Link Aggregation и множественном, например, кластерном доступе к shared file system) проблемы не решает и решить принципиально не может, ибо количество RJ-45 физически даже не удваивается, а утраивается. Электроника - наука о контактах.*

В моей практике был случай, когда подобная проблема разнесла в клочья ZFS-пул на массиве с iSCSI, содержащий около 1 Тб данных БД Oracle. И только физический бэкап спас гиганта мысли.

Про скорость даже топового массива, соединенного по iSCSI (все фичи включены - Link Aggregation, Jumbo Frame итд.итп.) я деликатно умолчу.

Выделенный массив с FC-AL еще долгое время будет рвать в клочья iSCSI. Ибо покупать карточки 10 Гбит Ethernet, во первых, адски дорого, а, во-вторых - вместе с ними можно сразу бежать за дополнительными процессорами.

К чему я привожу все эти примеры и куда я, черт побери, клоню?

А вот куда. Обе эти технологии (а как вы представляете себе огромное количество ввода-вывода, ибо не вычислениями едиными живет современный мир IT?) в полной мере используются в облаках.

Выводы может сделать каждый, оборудованный головным (а не только спинным) мозгом.

PS. Судя по развитию событий, не больно-то IT-мир бросился потреблять новую чудо-технологию. Раз требуется стучаться в каждое доступное окошко. И каждый раз подчеркивать, что "Облака могут быть и приватными". Что тоже достаточно красноречиво, не правда ли?
______________________________________
* И прошу также заметить, что речь не только и не столько о физике. TCP/IP - протокол, принципиально предназначенный вовсе не для дисковых обменов на высокой скорости с гарантированной доставкой и полной защитой данных при передаче. А это означает, что, скажем, corrupt-блоки будут появляться просто как из-под земли, скажем, в случае коллизий в сетевой среде при перегрузке. Или пакеты будут бесследно пропадать в "черных дырах" при плохой маршрутизации. Или данные будут разрушаться при любом искажении при передаче (например, умышленном или в случае проблем с оборудованием, при наводках электросети итп.), от которых, как известно, TCP/IP вовсе не предохраняет.

SMF и Method "stop" exited with status 208

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

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

Речь идет, в частности, о поведении самописных SMF-сервисов при остановке/рестарте/перезагрузке - они без видимых причин выпадают по таймауту с ошибкой, приведенной в заголовке статьи: "Method "stop" exited with status 208".

С чем это связано и почему так?

Первое столкновение произошло при модификации SMF-сервиса Nessus 3.2.1 (существует версия для Solaris и SMF в ней написан не слишком аккуратно - его пришлось править, но это отдельная история). Сервис некорректно уходил в состояние maintenance при остановке.

Вскрытие показало следующее - в журнале сервиса было вот такое сообщение:

[ May 22 18:27:51 Executing stop method ("/etc/init.d/nessusd stop") ]
[ May 22 18:27:51 Method "stop" exited with status 208 ]

При этом запуск сервиса выполняется совершенно нормально:

[ May 22 21:08:21 Executing start method ("/etc/init.d/nessusd start") ]
[ May 22 21:08:21 Method "start" exited with status 0 ]

Простейший поиск в Гугле привел к следующим результатам:

Результат 1
Результат 2
Результат 3

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

Метод:

stop_proc ()
{
# Stop nessus daemon
pkill nessusd
}

.....

'stop')
# This condition never occurs, because of daemon has not pid-file.
#test -f /opt/nessus/var/nessus/nessusd.pid && kill `cat /opt/nessus/var/nessus/nessusd.pid`
stop_proc
;;

Сервисный манифест (символы тэгов не показаны):

exec_method
type='method'
name='stop'
exec='/etc/init.d/nessusd %m'
timeout_seconds='60'

exec_method
type='method'
name='restart'
exec='/etc/init.d/nessusd %m'
timeout_seconds='60'

Итак, при остановке у нас вызывается функция stop_proc (), использующая pkill. Она-то и не нравится SMF. Причем что интересно - прямое выполнение скрипта (не из SMF) выполняет и запуск, и останов и рестарт - корректно. Даже если усилить нажим и написать pkill -KILL nessusd. Однако, при вызове скрипта из SMF в последнем случае вываливается чертовски непонятное сообщение:

[ May 22 21:16:37 Executing stop method ("/etc/init.d/nessusd stop") ]
[ May 22 21:16:37 Method "stop" failed due to signal KILL ]

Хотя уже все понятно. Pkill возвращает код возврата:

The following exit values are returned:
0 One or more processes were matched.
1 No processes were matched.
2 Invalid command line options were specified.
3 A fatal error occurred.

однако SMF его игнорирует, в последнем случае он ловит сообщение Killed от pkill и тоже не считает его корректным завершением команды.

Всякие игры около подпрограммы остановки процесса, наподобие:

(ужасный кусок извращения)

pkill nessusd>/dev/null 2>&1
retcode=`$ECHO $?`
case "$retcode" in
0) exit 0;;
*) exit 1;;
esac

(другой кусок, не лучше)

[ `pkill nessusd` ] && exit 0

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

Что ж, воспоследуем совету, найденному на вершине поиска Гугл и просто слегка подправим сервисный манифест:

exec_method
type='method'
name='stop'
exec=':kill'
timeout_seconds='60'

Только в этом месте и только вызов метода exec (сам код скрипта мы вообще никак не модифицируем). Что сие означает? Означает это, что для остановки сервиса (который мы так и так убиваем) мы вызываем нативный метод SMF :kill.

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

Проверяем остановку сервиса:

[ Jun 29 17:25:43 Executing stop method (:kill) ]
[ Jun 29 17:25:47 Method "stop" exited with status 0 ]

Все отлично, и остановка и перезапуск сервиса работает гладко:

[ Jun 29 17:49:41 Stopping because service restarting. ]
[ Jun 29 17:49:41 Executing stop method (:kill) ]
[ Jun 29 17:49:41 Executing start method ("/etc/init.d/nessusd start") ]
[ Jun 29 17:49:41 Method "start" exited with status 0 ]

Вот и все решение проблемы.

Как говорится, "Фигово, когда много знаешь" или "Keep it simple, stoopid"! ;)

PS. Хотя это может показаться самоочевидным, тем не менее подчеркну - логи (не обязательно сервисов SMF) - весьма полезная вещь при анализе проблем, не стоит ограничиваться лишь диагностическими сообщениями svcs -xv, как делают многие.

Легко ли угробить систему на ZFS root pool?

В предыдущей статье встал вопрос, что как-то страшновато зачищать zpool.cache при наличии ZFS root pool в системе, и, по логике, надо лечить систему с полетевшим ZFS-пулом полной брутальной переустановкой, как развлекаются окошечники (у них много свободного времени, хи-хи ;)).

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

Проведем эксперимент экспериментов и попробуем шаловливыми ручонками ушатать систему на ZFS root pool и с еще одним пулом ZFS на втором диске до полной гибели. ;)

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

Обстряпаем мы это так.

1. Установим систему с двумя пулами на двух дисках.
2. Вынесем на живой системе с двумя пулами zpool.cache полностью. Не будем убивать пулы - просто имитируем ситуацию отказа некорневого пула, когда нужно удалять кэш-файл.
3. Перезагрузимся.
4. Посмотрим, что произойдет.

Итак, начали!

server4# cd /etc/zfs
server4# ls -al
total 24
drwxr-xr-x 2 root sys 3 Oct 27 04:28 .
drwxr-xr-x 89 root sys 246 Oct 27 04:28 ..
-rw-r--r-- 1 root root 1040 Oct 27 04:28 zpool.cache
server4# zpool status
pool: rpool
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c0t1d0s0 ONLINE 0 0 0

errors: No known data errors
server4# zpool create -f data c0t0d0s0
server4# zpool status
pool: data
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
c0t0d0s0 ONLINE 0 0 0

errors: No known data errors

pool: rpool
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c0t1d0s0 ONLINE 0 0 0

errors: No known data errors

Мы на исходной позиции. Система стоит на ZFS-руте полностью, на втором диске у нас пул DATA, который в онлайне и смонтирован. Кэш-файл содержит, соответственно, ссылки на оба пула.

Производим вынос тела:

server4# cd /etc/zfs
server4# ls -al
total 26
drwxr-xr-x 2 root sys 3 Oct 27 04:36 .
drwxr-xr-x 89 root sys 246 Oct 27 04:28 ..
-rw-r--r-- 1 root root 2052 Oct 27 04:36 zpool.cache
server4# rm *
server4# ls -al
total 20
drwxr-xr-x 2 root sys 2 Oct 27 04:37 .
drwxr-xr-x 89 root sys 246 Oct 27 04:28 ..
server4# init 6

После непродолжительной гражданской панихиды тело было предано земле:

server4# svc.startd: The system is coming down. Please wait.
svc.startd: 90 system services are now being stopped.
svc.startd: The system is down.
syncing file systems... done
rebooting...

SC Alert: Host System has Reset
Probing system devices
Probing memory
Probing I/O buses
screen not found.
keyboard not found.
Keyboard not present. Using ttya for input and output.
Probing system devices
Probing memory
Probing I/O buses


Sun Fire V215, No Keyboard
Copyright 2008 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.30.0.a, 1024 MB memory installed, Serial #78457024.
Ethernet address 0:14:4f:ad:28:c0, Host ID: 84ad28c0.



Rebooting with command: boot
Boot device: /pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/disk@1,0:a File and args:
SunOS Release 5.10 Version Generic_137137-09 64-bit
Copyright 1983-2008 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Hardware watchdog enabled
Hostname: server4
Reading ZFS config: done.
Mounting ZFS filesystems: (3/3)

server4 console login: root
Password:
Last login: Fri Oct 27 04:32:36 on console
Oct 27 04:39:59 server4 login: ROOT LOGIN /dev/console
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
Welcome to SA300-S10_B.2 on server4
server4# zpool status
pool: rpool
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c0t1d0s0 ONLINE 0 0 0

errors: No known data errors

"Дык, ети ж твою за ногу!" - сказали мужики. Корневой пул жив, мало того, он исправен и сам вернул себя взад! А второго пула нет. Окей, вернем его обратно?

server4# zpool import data
server4# zpool status
pool: data
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
data ONLINE 0 0 0
c0t0d0s0 ONLINE 0 0 0

errors: No known data errors

pool: rpool
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
c0t1d0s0 ONLINE 0 0 0

errors: No known data errors
server4#

Ха. "Он завелся!"*

Don't panic, мальчики и девочки. Убить систему, стоящую на корневом пуле ZFS не трудно - а очень трудно.
____________________________________
* Крик молодого Анакина Скайуокера в фильме "Звездные Войны I эпизод: Скрытая угроза", когда он смог-таки завести двигатели своего кара.