четверг, 30 июля 2009 г.

Минимизация сервисов Solaris

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

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

Ко всему прочему, неиспользуемые сервисы - это еще и жлобство, поскольку они занимают ресурсы сервера - CPU, память и прочее.

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

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

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

Что и было реализовано здесь.

Теперь и минимизация ПО, и минимизация сервисов приведена более-менее к общему знаменателю, списки сервисов ообновляются влегкую.

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

Как и в первоначальной версии, SMF-сервисы можно только отключать (никто не забыл, как пользоваться командой svcadm enable ... ? ;)), а legacy - и включать и выключать.

Отключение legacy делается очень просто - переименованием файлов в /etc/rcX.d директориях в скрытые (начинающиеся с точки). Права файлов сохраняются.

Списки отключаемых сервисов с умыслом составлены весьма рестриктивными. Для SMF отключается большинство сервисов - остается почти абсолютный минимум из примерно полусотни сервисов (по умолчанию Солярис 10 имеет свыше полутораста запущенных сервисов), legacy-сервисы отключаются все (исключая boot.server для SPARC - впрочем, его нетрудно добавить в списки самостоятельно).

Остается запущенным SSH (при использовании OpenSSH можно отключить и его).

Все остальные службы, включая зоны, контейнеры, NFS, и прочее - отключаются.

PS. В общей сложности, после отключения всего лишнего, освобождается свыше 300 мегабайт RAM. Разумеется, ускоряется запуск и останов системы. Но, самое главное - система становится намного более защищенной и, после минимизации, совсем не светится перед сканерами как бордель в Амстердаме. ;)

вторник, 28 июля 2009 г.

Минимизация установленного ПО Solaris

Очень часто приходится выполнять установку Солярис не в минимальном варианте, а устанавливая Entire Distribution (многие прикладные системы требуют полную установку - например, Oracle).

Разумеется, можно поступить брутально, установить метакластер Minimal with network support и, после этого, вручную доустановить все необходимые пакеты. Однако это долго, хлопотно, и требуется знать назубок все зависимости пакетов.

Значительно проще выполнить установку метакластера SUNWCall, а затем удалить из нее то, что не является безусловно необходимым.

Зачем нужно выполнять удаление неиспользуемых пакетов?

Прежде всего, для безопасности.

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

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

Ну и, главное - есть пакеты и компоненты, которым на сервере делать безусловно нечего. Например, почтовые клиенты и браузеры (для серверных задач есть WGET, офисные продукты, устаревшие компоненты - UUCP/NIS итп.

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

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

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

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

Минимизационный список по умолчанию рассчитан на установку метакластера SUNWCall и последующего жесткого удаления ПО, не требуемого на бастионной машине, подключенной к Internet. Список подобран для сборки Oracle, но без всяких излишеств.

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

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

В частности, не стоит удалять поддержку FC (это важный депендент ядра) и DTrace.

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

Что делать, если Вы ошибочно удалили нужный пакет?

Не паниковать. Запуск с внешнего носителя, монтирование пострадавшей системы и добавление пакета утилитой pkgadd c дистрибутивного имиджа спасет гиганта мысли.

Удачных вам минимизаций!

понедельник, 20 июля 2009 г.

Скорая помощь при разрушении DBMS_REGISTRY

Год назад собирался написать эту статью, пока еще было актуальным. ;)

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

Итак, приступим.

В двух словах - суть проблемы. В Oracle 10 R2, при установке патчсета 10.2.0.4, в случае, если вся БД переведена в native compilation (PL/SQL), при выполнении catupgrd.sql иногда (в действительности достаточно часто) вылетает ошибка, связанная с отсутствием package body пакета DBMS_REGISTRY, после чего обновить метаданные становится невозможно. И апгрейд БД заходит в тупик.

Ошибка, в общем-то, не вполне тривиальная.

Тем более, что иногда нервные DBA выполняют даунгрейд и/или брутальную переустановку софта/пересоздание БД. ;) (чего в действительности делать не нужно)

Чтобы избежать таких неприятностей, по-хорошему перед установкой патчсета необходимо сначала вернуть БД в состояние interpreted PL/SQL скриптом dbmsupgin.sql. Одно но: эта процедура выполняется последовательно (рекомпиляция utlrp), идет достаточно долго и БД стартована в состоянии UPGRADE/RESTRICTED SESSION. На продуктивных серверах даунтайм получается достаточно большим и на это могут пойти не все. Тем более, что после апгрейда ПО и словаря потом надо все равно перекомпилировать весь PL/SQL-код обратно в native.

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

Во-первых, не надо паники. Ничего переустанавливать не нужно.

Прямо не сходя с места и не перезапуская экземпляр, нужно всего лишь соединиться как SYSDBA и выполнить скрипт prvtcr.plb из $ORACLE_HOME/rdbms/admin:

oracle @ athena ~ $ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Mon Jul 20 16:58:32 2009

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.


Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining
and Real Application Testing options

SQL> @$ORACLE_HOME/rdbms/admin/prvtcr.plb
(пустые строки в выводе удалены)
Package created.
No errors.
Package created.
No errors.
Package body created.
No errors.
Synonym created.
Package body created.
No errors.
Package body created.
No errors.
1 row deleted.
1 row created.
Commit complete.
Context created.
PL/SQL procedure successfully completed.
View created.
Synonym created.
Grant succeeded.
View created.
Synonym created.
Grant succeeded.
View created.
Synonym created.
Grant succeeded.
View created.
Synonym created.
Grant succeeded.
View created.
Synonym created.
Grant succeeded.
View created.
Synonym created.
Grant succeeded.
View created.
Synonym created.
Grant succeeded.
View created.
Synonym created.
Grant succeeded.

После чего, не сходя с места, можно спокойно выполнять catupgrd.sql, завершая обновление, причем изменения режима компиляции PL/SQL выполнять не нужно.

PS. Следует учесть лишь тот факт, что прогон словарных скриптов при обновлении, в случае, когда вся БД находится в режиме native compilation, все же потребует несколько большего времени, чем в режиме interpreted.

вторник, 7 июля 2009 г.

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 и создавать более одного слайса - не везде описано и далеко не все знают.

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

пятница, 3 июля 2009 г.

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

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

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

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

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

четверг, 2 июля 2009 г.

Облако без штанов или Приходит 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 вовсе не предохраняет.