Unix pin

Sun servers Power on

ikorolev — Fri, 04 May 2012 12:10:34 +0000

После аварийного пропадания питания, сервера с ILOM (Sun/Oracle t5440, t3-1, t3-4 итд) автоматически не включаются. Чтобы это исправить, в системном контролере выставляем

set /SP/policy HOST_LAST_POWER_STATE=enabled set /SP/policy HOST_POWER_ON_DELAY=enabled

ЗЫ Если автозагрузка не установлена, то еще добавить
set /HOST/bootmode script="setenv auto-boot? true"

{lang: 'ru'}

VxVM dmp_native_support off

ikorolev — Thu, 12 Apr 2012 07:58:44 +0000

В последних версиях VxVM научился обнаруживать zfs ну и соответственно теперь может «делать каку»
# vxdisk list DEVICE TYPE DISK GROUP STATUS c0t5000CCA0125F2E84d0s2 auto:ZFS - - ZFS c0t5000CCA01268CBECd0s2 auto:ZFS - - ZFS

При обновлении VxVM до версии 5.1SP1RP2 появляется сообщение:

Failed to turn off dmp_native_support tunable on myserver. Refer to Dynamic Multi-Pathing Administrator's guide to determine the reason for the failure and take corrective action. VxVM vxdmpadm ERROR V-5-1-15690 Operation failed for one or more zpools VxVM vxdmpadm ERROR V-5-1-15686 The following zpool(s) could not be migrated as they are not healthy - rpool

При том, что zfs пул rpool в порядке и вообще-то не использует vxdmp, а использует наоборот — mpxio.
Отключить опицию dmp_native_support в vxdmp не удалось ни после выкидывания дисков, на которых распалагается zfs rpool, ни после удаления путей dmp.
Методом научного тыка отключение этой опции было сделано через файл
# cat /etc/vx/dmppolicy.info arraytype # arrayname # enclosure # naming scheme=ebn persistence=yes mode=default lowercase=yes use_avid=yes # dmpnode enable_all 1 fake_array0_0 osn_enabled #

Итак, удаляем строки

dmpnode enable_all 1 fake_array0_0 osn_enabled

и перегружаем хост.

{lang: 'ru'}

Алгоритмы мультипатинга MPxIO (STMS) для массивов Hitachi Hi-End

ikorolev — Wed, 11 Apr 2012 07:04:05 +0000

MPxIO может использовать load-balance алгоритмы
round-robin
logical-block
none
Обычно, включается опция load-balance=»round-robin» в файле /kernel/drv/scsi_vhci.conf .
На массивах Hitachi USP, USPV, VSP (и других работающих в active-active режиме) это приводит к тому, что каждая scsi-команда отрабатывает на следующем контроллере, при этом происходит задержка (rotational delay на диске, система ждет пока диск сделает оборот). Особенно заметно это на последовательных операциях ввода-вывода и на страйпированых томах vxvm или svm со страйпом 16кб.
Чтобы этого избежать,

включаем режим балансировки нагрузки «logical block» для определенных массивов (массив определяется по выводу команд ‘luxadm inqure’ или ‘mpathadm show lu’).

# mpathadm show lu /dev/rdsk/c0t60060E80164E6F0000014E6F00000201d0s2 |egrep "Vendor|Product" Vendor: HITACHI Product: OPEN-V -SUN

Добавляем в /kernel/drv/scsi_vhci.conf следующие строки
device-type-mpxio-options-list = "device-type=HITACHI OPEN-V -SUN", "load-balance-options=logical-block-options"; logical-block-options="load-balance=logical-block", "region-size=15";

Опция «region-size=N» означает (2^N)*512-байтных блоков, которые пройдут по одному пути, затем путь переключается. Например N=15 2^15 = 32768 = area of 16MB

Чтобы новый алгоритм балансировки применился — требуется перезагрузка.

Ссылки в тему:

{lang: 'ru'}

Когда навалом процессоров… Часть 3

ikorolev — Fri, 16 Mar 2012 13:05:41 +0000

Смотри также
Когда навалом процессоров… Часть 1
Когда навалом процессоров… Часть 2
Когда навалом процессоров… Часть 3

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

Итак, определим, на какой шине pci расположены адаптеры qlc :
# cat /etc/path_to_inst |grep \"qlc\" "/pci@400/pci@2/pci@0/pci@1/pci@0/pci@2/SUNW,qlc@0" 3 "qlc" "/pci@400/pci@2/pci@0/pci@1/pci@0/pci@2/SUNW,qlc@0,1" 4 "qlc" "/pci@400/pci@2/pci@0/pci@2/pci@0/pci@2/SUNW,qlc@0" 7 "qlc" "/pci@400/pci@2/pci@0/pci@2/pci@0/pci@2/SUNW,qlc@0,1" 8 "qlc" "/pci@600/pci@1/pci@0/pci@4/pci@0/pci@2/SUNW,qlc@0" 2 "qlc" "/pci@600/pci@1/pci@0/pci@4/pci@0/pci@2/SUNW,qlc@0,1" 11 "qlc" "/pci@500/pci@2/pci@0/pci@2/pci@0/pci@2/SUNW,qlc@0" 5 "qlc" "/pci@500/pci@2/pci@0/pci@2/pci@0/pci@2/SUNW,qlc@0,1" 6 "qlc" "/pci@500/pci@1/pci@0/pci@1/pci@0/pci@2/SUNW,qlc@0" 9 "qlc" "/pci@500/pci@1/pci@0/pci@1/pci@0/pci@2/SUNW,qlc@0,1" 10 "qlc" "/pci@700/pci@2/pci@0/pci@3/pci@0/pci@2/SUNW,qlc@0" 0 "qlc" "/pci@700/pci@2/pci@0/pci@3/pci@0/pci@2/SUNW,qlc@0,1" 1 "qlc"

Смотрим, какой процессор обрабатывает прерывания устройств на шине /pci@600
# pcitool /pci@600 -i ino 6 mapped to cpu aa Device: /pci@600/pci@1/pci@0/pci@4 Driver: pcieb, instance 42 ino 7 mapped to cpu 87 Device: /pci@600/pci@1/pci@0/pci@4/pci@0/pci@2/SUNW,qlc@0 Driver: qlc, instance 2 ino 8 mapped to cpu 86 Device: /pci@600/pci@1/pci@0/pci@4/pci@0/pci@2/SUNW,qlc@0 Driver: qlc, instance 2 ino 9 mapped to cpu 85 Device: /pci@600/pci@1/pci@0/pci@4/pci@0/pci@2/SUNW,qlc@0,1 Driver: qlc, instance 11 ino a mapped to cpu 84 Device: /pci@600/pci@1/pci@0/pci@4/pci@0/pci@2/SUNW,qlc@0,1 Driver: qlc, instance 11 ...
номер прерывания (ino) и номер процессора (cpu) в шеснадцатеричном виде.

Перенесем прерывание ino 7 с процессора 87 на процессор ff
# pcitool /pci@600 -i ino=7 -w cpu=ff Interrupts on ino 7 reassigned: Old cpu:87, New cpu:ff

Ну и далее — переносим все прерывания устройств ввода-вывода на один или несколько выделенных процессоров и объединяем их в процессорный сэт ( psrset ).

{lang: 'ru'}

Как определить HDS command device

ikorolev — Wed, 21 Dec 2011 14:05:52 +0000

С недавнего времени в horcm конфигах (файлах, описывающих репликацию ShadowImage, COW или TruCopy) теперь очень просто описать Command device:

#dev_name dev_name dev_name \\.\CMD-99999:/dev/rdsk/

Где 99999 — серийный номер вашего массива.
В более ранних версиях требовалось указывать конкретные LUN-ы, на которых располагались Command devices, что вызывало проблемы при переезде путей в SAN или, например, замене HBA. Теперь, при замене HBA, изменении номера контроллера после перезагрузки или проведении динамической реконфигурации итд — репликация продолжает работать.

{lang: 'ru'}

luxadm. Часть 2. Сделать

ikorolev — Tue, 29 Nov 2011 13:38:36 +0000

Что можно сделать с помощью команды luxadm

При мультипатинге STMS(MPXIO) переключение пути с primary на secondary (на дисковых массивах в режиме active-passive). Посмотреть какие пути primary/secondary с помощью luxadm display /dev/rdsk/c14t6d0s2
# luxadm failover secondary /dev/rdsk/c14t6d0s2 Error: Device does not support failover # luxadm failover primary /dev/rdsk/c14t6d0s2 Error: Device does not support failover

Переинициализировать порт hba (погасить и зажечь порт). Помогает при залипаниях и добавлении новых дисков со стороны массива.
# luxadm -e forcelip /dev/cfg/c3 # tail -100 /var/adm/messages Oct 26 17:32:22 pioneer emlxs: [ID 349649 kern.info] [ 5.05F1]emlxs1: NOTICE: 730: Link reset. (Resetting link...) Oct 26 17:32:22 pioneer emlxs: [ID 349649 kern.info] [ 5.031F]emlxs1: NOTICE: 710: Link down. Oct 26 17:32:22 pioneer emlxs: [ID 349649 kern.info] [ 5.0631]emlxs1: NOTICE: 730: Link reset. Oct 26 17:32:24 pioneer emlxs: [ID 349649 kern.info] [ 5.0549]emlxs1: NOTICE: 720: Link up. (4Gb, fabric, initiator)

Перевести устройство в offline (полезно при удалении определенных LUNов с массивов)
# luxadm -e offline /dev/rdsk/c14t6d0s2

Перевести устройство в online
# luxadm -e online /dev/rdsk/c14t6d0s2

Послать устройству команду reset
# luxadm -e dev_reset /dev/rdsk/c14t6d0s2

Зажечь или погасить лампочку на диске (работает только на некоторых устройствах)
# luxadm led /dev/rdsk/c14t6d0s2 # luxadm led_on /dev/rdsk/c14t6d0s2 # luxadm led_off /dev/rdsk/c14t6d0s2 # luxadm led_blink /dev/rdsk/c14t6d0s2

Обновить прошивку на hba (лучше пользоваться загрузчиком из firmware патча)
# luxadm fcode_download -d /path_to_firmware

{lang: 'ru'}

luxadm. Часть 1. Посмотреть

ikorolev — Thu, 24 Nov 2011 14:01:33 +0000

Команда luxadm используется для работы с различными fc устройствами. Создавалась она для администрирования внутренних дисков серверов sf880 и fc-al, а в дальнейшем добавился функционал и эта утилита стала основной при работе с fc (в Solaris 10 появились команды fcinfo и mpathadm ). Синтаксис у команды непростой, но попробую ее причесать.
Итак, какие аргументы можно использовать
физический путь к fc портам hba или контроллеру (типа /devices/pci@700/pci@0/pci@c/SUNW,emlxs@0,1/fp@0,0:devctl или /dev/cfg/c6 )
WWN массива (типа 10000000c98b08d3)
путь к диску или ленте (/dev/rdsk/c6t1d0s2 или /dev/rmt/2)

Посмотреть состояние и пути fc-портов hba
# luxadm -e port /devices/pci@700/pci@0/pci@c/SUNW,emlxs@0,1/fp@0,0:devctl CONNECTED /devices/pci@400/pci@0/pci@d/SUNW,emlxs@0,1/fp@0,0:devctl CONNECTED /devices/pci@600/pci@0/pci@c/SUNW,emlxs@0,1/fp@0,0:devctl NOT CONNECTED /devices/pci@500/pci@0/pci@d/SUNW,emlxs@0/fp@0,0:devctl NOT CONNECTED

Соответствие между контроллером и путем fc-порта (это не luxadm, но полезно использовать)
# ls -la /dev/cfg/c* lrwxrwxrwx 1 root root 56 Feb 2 2011 /dev/cfg/c2 -> ../../devices/pci@400/pci@0/pci@c/SUNW,emlxs@0/fp@0,0:fc lrwxrwxrwx 1 root root 58 Feb 2 2011 /dev/cfg/c3 -> ../../devices/pci@400/pci@0/pci@c/SUNW,emlxs@0,1/fp@0,0:fc lrwxrwxrwx 1 root root 56 Feb 2 2011 /dev/cfg/c4 -> ../../devices/pci@400/pci@0/pci@d/SUNW,emlxs@0/fp@0,0:fc lrwxrwxrwx 1 root root 58 Feb 2 2011 /dev/cfg/c5 -> ../../devices/pci@400/pci@0/pci@d/SUNW,emlxs@0,1/fp@0,0:fc lrwxrwxrwx 1 root root 56 Feb 2 2011 /dev/cfg/c6 -> ../../devices/pci@500/pci@0/pci@9/SUNW,emlxs@0/fp@0,0:fc

Посмотреть, что подключено на конкретном порту (можно смотреть как по физическому пути, так и по пути контроллера)
# luxadm -e dump_map /devices/pci@400/pci@1/pci@0/pci@0/SUNW,emlxs@0/fp@0,0:devctl Pos Port_ID Hard_Addr Port WWN Node WWN Type 0 97f4c0 0 204300a0b848a702 200200a0b848a702 0x0 (Disk device) 1 97f680 0 10000000c9b1f51c 20000000c9b1f51c 0x1f (Unknown Type,Host Bus Adapter) # luxadm -e dump_map /dev/cfg/c6 Pos Port_ID Hard_Addr Port WWN Node WWN Type 0 97f4c0 0 204300a0b848a702 200200a0b848a702 0x0 (Disk device) 1 97f680 0 10000000c9b1f51c 20000000c9b1f51c 0x1f (Unknown Type,Host Bus Adapter)

Посмотреть, какие fc диски или ленты видны в системе
# luxadm probe -p No Network Array enclosures found in /dev/es Found Fibre Channel device(s): Node WWN:206000c0ff0067d9 Device Type:Disk device Logical Path:/dev/rdsk/c14t600C0FF0000000000067D96B373B6600d0s2 Physical Path: /devices/scsi_vhci/ssd@g600c0ff0000000000067d96b373b6600:c,raw Node WWN:206000c0ff0067d9 Device Type:Disk device Logical Path:/dev/rdsk/c14t600C0FF0000000000067D96B373B6601d0s2 Physical Path: /devices/scsi_vhci/ssd@g600c0ff0000000000067d96b373b6601:c,raw Node WWN:206000c0ff0067d9 Device Type:Disk device Logical Path:/dev/rdsk/c14t600C0FF0000000000067D96B373B6602d0s2 Physical Path: /devices/scsi_vhci/ssd@g600c0ff0000000000067d96b373b6602:c,raw

Посмотреть информацию по конкретному диску
# luxadm display /dev/rdsk/c14t60060E8004F236000000F23600000A00d0s2 DEVICE PROPERTIES for disk: /dev/rdsk/c14t60060E8004F236000000F23600000A00d0s2 Vendor: HITACHI Product ID: OPEN-V -SUN Revision: 5009 Serial Num: 50 0F2360A00 Unformatted capacity: 34091.250 MBytes Write Cache: Enabled Read Cache: Enabled Minimum prefetch: 0x0 Maximum prefetch: 0x0 Device Type: Disk device Path(s): /dev/rdsk/c14t60060E8004F236000000F23600000A00d0s2 /devices/scsi_vhci/ssd@g60060e8004f236000000f23600000a00:c,raw Controller /devices/pci@400/pci@0/pci@c/SUNW,emlxs@0,1/fp@0,0 Device Address 50060e8004f23674,4 Host controller port WWN 10000000c98b08d3 Class primary State ONLINE Controller /devices/pci@400/pci@0/pci@c/SUNW,emlxs@0,1/fp@0,0 Device Address 50060e8004f23676,4 Host controller port WWN 10000000c98b08d3 Class primary State ONLINE Controller /devices/pci@400/pci@0/pci@c/SUNW,emlxs@0/fp@0,0 Device Address 50060e8004f23664,4 Host controller port WWN 10000000c98b08d2 Class primary State ONLINE Controller /devices/pci@400/pci@0/pci@c/SUNW,emlxs@0/fp@0,0 Device Address 50060e8004f23666,4 Host controller port WWN 10000000c98b08d2 Class primary State ONLINE

Показать inquire информацию по конкретному диску
# luxadm inquiry/dev/rdsk/c14t600C0FF00000000009208424A938CA00d0s2 INQUIRY: Physical Path: /devices/scsi_vhci/ssd@g600c0ff00000000009208424a938ca00:c,raw Vendor: SUN Product: StorEdge 3511 Revision: 421F Serial Number 09208424A938CA00 Device type: 0x0 (Disk device) Removable media: no Medium Changer Element: no ISO version: 0 ECMA version: 0 ANSI version: 3 (Device complies to SCSI-3) Terminate task: no Response data format: 2 Additional length: 0xf7 Command queueing: no VENDOR-SPECIFIC PARAMETERS Byte# Hex Value ASCII 52 00 00 00 00 .... 96 43 6f 70 79 72 69 67 68 74 20 28 43 29 20 31 39 Copyright (C) 19 39 39 20 49 6e 66 6f 72 74 72 65 6e 64 2e 20 41 99 Infortrend. A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 ............

Посмотреть информацию по конкретной ленте
# luxadm -v display /dev/rmt/3 Displaying information for: /dev/rmt/3 DEVICE PROPERTIES for tape: /dev/rmt/3 Vendor: ARCHIVE Product ID: Python Revision: V000 Serial Num: Unsupported Device Type: Tape device Path(s): /dev/rmt/3n /devices/pci@700/pci@0/pci@c/SUNW,emlxs@0,1/fp@0,0/st@w2101001b3232ef61,0:n LUN path port WWN: 2101001b3232ef61 Host controller port WWN: 10000000c98b07d5 Path status: Not Ready

Информация по дисковому массиву (по WWN массива), показывает также информацию по всем дискам массива
# luxadm display 226000c0ff992084 DEVICE PROPERTIES for disk: 226000c0ff992084 Vendor: SUN Product ID: StorEdge 3511 Revision: 421F Serial Num: 09208424A938CA00 Unformatted capacity: 956000.000 MBytes Write Cache: Enabled Read Cache: Enabled Minimum prefetch: 0x0 Maximum prefetch: 0xffff Device Type: Disk device Path(s): /dev/rdsk/c14t600C0FF00000000009208424A938CA00d0s2 /devices/scsi_vhci/ssd@g600c0ff00000000009208424a938ca00:c,raw Controller /devices/pci@700/pci@0/pci@c/SUNW,emlxs@0,1/fp@0,0 Device Address 226000c0ff992084,0 Host controller port WWN 10000000c98b07d5 Class primary State ONLINE Controller /devices/pci@700/pci@0/pci@c/SUNW,emlxs@0/fp@0,0 Device Address 216000c0ff892084,0 Host controller port WWN 10000000c98b07d4 Class primary State ONLINE DEVICE PROPERTIES for disk: 226000c0ff992084 Vendor: SUN Product ID: StorEdge 3511 Revision: 421F Serial Num: 09208424A938CA01 Unformatted capacity: 956000.000 MBytes Write Cache: Enabled Read Cache: Enabled Minimum prefetch: 0x0 Maximum prefetch: 0xffff Device Type: Disk device Path(s):

Список установленых Hba и версии firmware
# luxadm fcode_download -p Found Path to 0 FC100/S Cards Complete Found Path to 0 FC100/P, ISP2200, ISP23xx Devices Complete Found Path to 0 JNI1560 Devices. Complete Found Path to 12 Emulex Devices. Opening Device: /devices/pci@400/pci@0/pci@c/SUNW,emlxs@0/fp@0,0:devctl Detected FCode Version: 3.01a1 Opening Device: /devices/pci@400/pci@0/pci@c/SUNW,emlxs@0,1/fp@0,0:devctl Detected FCode Version: 3.01a1 Opening Device: /devices/pci@400/pci@0/pci@d/SUNW,emlxs@0/fp@0,0:devctl Detected FCode Version: 3.01a1

Показать количество ошибок по fc порту
# luxadm -e rdls/dev/cfg/c3 Link Error Status information for loop: al_pa lnk fail sync loss signal loss sequence err invalid word CRC 712100 1 0 0 0 293 0 713600 0 0 0 0 255 0 713700 1 0 0 0 255 0 713b00 0 0 0 0 255 0 8c0000 0 1 0 0 3 0 NOTE: These LESB counts are not cleared by a reset, only power cycles. These counts must be compared to previously read counts.

Посмотреть состояние fc-устройства
# luxadm -e bus_getstate/dev/rdsk/c14t60060E8004F236000000F23600000300d0s2 /dev/rdsk/c14t60060E8004F236000000F23600000300d0s2: Active # for i in /dev/rdsk/c14*s2 ; do luxadm -e bus_getstate $i; done /dev/rdsk/c14t60060E8004F236000000F23600000300d0s2: Active Error: Invalid pathname (/devices/scsi_vhci/ssd@g60060e80153438000001343800000501:c,raw) Error: Invalid pathname (/devices/scsi_vhci/ssd@g60060e80153438000001343800000502:c,raw)

{lang: 'ru'}

Передача снапшота ZFS по сети

AnViar — Fri, 18 Nov 2011 08:17:30 +0000

Пришлось наконец столкнуться на практике с передачей сравнительного большого
снимка ZFS по сети. В учебных материалах и официальной документации сказано, что
для передачи по сети следует использовать команды send\recv в сочетании с ssh
через пайп. На практике же это решение оказывается абсолютно не работоспособным
для больших объемов. Лично у меня скорость передачи уперлась примерно в 8 MB/sec
по гигабитной сети, что привело к тому что за 12 часов скопировалось лишь 300
гигабайт данных.
Что же делать?

Во-первых, требуется
собрать на обеих машинах программу mbuffer. Отличная альтернатива
ssh для передачи данных в защищенной сети.
Делаем снапшот:
# zfs snapshot
tank/tones@$(date +%y%m%d%H%M)
Запускаем на приемнике ожидание потока
данных
# /usr/local/bin/mbuffer -s 128k -m 1G -I 9090 | zfs receive
zshare/test
Запускаем передачу снимка на передатчике
# zfs send
tank/tones@1105101812 | /usr/local/bin/mbuffer -s 128k -m 1G -O
10.99.88.55:9090
Подробное описание ключей прочитаете в манах к mbuffer — там
все понятно. Наблюдаем около сотни метров в секунду, радуемся.
Если же вы все
же решили передать снимок по ssh (малый объем\незащищенная сеть), то делать надо
это следующим образом.
Делаем снимок как сказано выше. На приемнике даем
следующие разрешения пользователю, под которым происходит соединение
# zfs
allow user create,mount,receive zshare
Запускаем передачу на источнике
#
zfs send tank/tones@1105101812 | ssh -C -b 10.0.64.50 user@10.99.88.55
/usr/sbin/zfs recv zshare/tones

Вторая задача: поддерживать 2 датасета на разный хостах в состоянии максимально
возможной идентичности. Используем возможность передачи
инкримента двух снапшотов.

Вначале был передан полный снапшот объемом около террабайта с помощью mbuffer, как это было описано в выше. Также предоставлены соответствующие права пользователю и
прописаны rsa-ключи. Процесс занял примерно 4 часа по гигабитному
каналу.
Дальше в планировщик добавляем вот такой скрипт:

#!/usr/bin/bash

#=== Options ==============

zfs_pool=zshare

zfs_dataset=dataset

lockfile="/var/run/zfs_operation.lock"

zsnapname=auto_$(date +%y%m%d%H%M)

mail_recipients="admin@tele2.com"

RHOST=192.168.0.1

RUSER=snapuser

#==========================

function check_result {

last_comm_res=$?

if [[ "${last_comm_res}" -ne 0 ]]

then

echo "Script: an error occurred"

cat /var/log/tones_backup.log|mailx -s "${HOSTNAME}:Pool backup error" ${mail_recipients}

exit ${last_comm_res}

fi

}

if [ -f ${lockfile} ]

then

echo "Previous runjob does not complitted successfully"

exit 1

fi

touch ${lockfile}

if [[ ! -z $(ps -ef|grep zfs|grep send|grep ${zfs_pool}) ]]

then

echo "Sending data from pool ${zfs_pool} detected! Try again later!"

exit 1

fi

rlast_snapshot=$(ssh ${RUSER}@${RHOST} "/usr/sbin/zfs list -o name -r ${zfs_pool}/${zfs_dataset}|tail -1"|awk -F@ '{print $2}')

zfs list -o name ${zfs_pool}/${zfs_dataset}@${rlast_snapshot} ; check_result

zfs snapshot ${zfs_pool}/${zfs_dataset}@${zsnapname} ; check_result

zfs send -i ${zfs_pool}/${zfs_dataset}@${rlast_snapshot} ${zfs_pool}/${zfs_dataset}@${zsnapname} | ssh ${RUSER}@${RHOST} "/usr/sbin/zfs recv -F ${zfs_pool}/${zfs_dataset}"

check_result

rm ${lockfile}

Частоту вызова данного скрипта следует выбирать исходя из следующих факторов:

Скорость роста снапшотов
Ширина канала между хостами
Нагрузка на активном пуле

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

#!/usr/bin/bash

#=== Options ==============

zfs_pool=zshare

zfs_dataset=dataset

#=========================

nsnap=$(zfs list -o name -r ${zfs_pool}/${zfs_dataset}|egrep "@auto_1[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]"|wc -l)

if [[ ${nsnap} -gt 3 ]]

then

let "nsnap_destroy = $nsnap - 2"

snap_destroy_list=$(zfs list -o name -r ${zfs_pool}/${zfs_dataset}|egrep "@auto_[0-9]10"|head -n ${nsnap_destroy})

for dsnap in ${snap_destroy_list}

do

zfs destroy ${dsnap}

done

fi

{lang: 'ru'}

Полезный совет

ikorolev — Thu, 17 Nov 2011 10:14:41 +0000

Если ходить на сайт поддержки Oracle ( support.oracle.com ) не через flash-версию, а через HTML, то сайт окликается заметно быстрее.

{lang: 'ru'}

Как из ILOM посмотреть fma сообщения

ikorolev — Thu, 03 Nov 2011 12:57:34 +0000

На серверах c ILOM (это сервера Sun/Oracle T5x40, T3-x, T4-x, X22x0 итд ) можно смотреть и администрировать сообщения fma (Fault Management) как из Solaris (команды fmadm, fmdump, итд), так и из ILOM. Если вдруг после сбоя система не грузится, то диагностировать можно с системного контроллера:

login as: root Using keyboard-interactive authentication. Password: Oracle(R) Integrated Lights Out Manager Version 3.0.9.20.a r57453 Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. -> start /SP/faultmgmt/shell Are you sure you want to start /SP/faultmgmt/shell (y/n)? y faultmgmtsp> help Built-in commands: echo - Display information to user. Typical use: echo $? help - Produces this help. Use 'help ' for more information about an external command. exit - Exit this shell. External commands: fmadm - Administers the fault management service fmdump - Displays contents of the fault and ereport/error logs fmstat - Displays statistics on fault management operations etcd - ereport injector faultmgmtsp> fmdump TIMESTAMP UUID MSGID 2011-06-03/12:05:50 0e4dd348-d751-6578-ed76-b87403fa0dac SPX86-8001-U5 2011-06-04/02:30:12 3402b0d3-b3fe-e136-f462-b8384a827f55 SPX86-8001-U5 2011-06-08/00:23:25 93672d86-4fc7-69b5-d912-87c0837eda5d SPX86-8001-U5 2011-09-30/05:58:03 0cbe0f82-820d-63f0-b9f0-a5e18aab4092 SPX86-8001-U5 2011-10-12/22:21:44 e74ccdad-05d0-62e5-8bda-fb24d2811509 SPX86-8001-U5 faultmgmtsp> fmadm faulty ------------------- ------------------------------------ -------------- -------- Time UUID msgid Severity ------------------- ------------------------------------ -------------- -------- 2011-10-12/22:21:44 e74ccdad-05d0-62e5-8bda-fb24d2811509 SPX86-8001-U5 Critical Fault class : fault.memory.intel.dimm_ue FRU : /SYS/MB/P1/D5 Description : A memory uncorrectable ECC fault on a DIMM has occurred. Response : None. Impact : System is reset. Action : The administrator should review the ILOM event log for additional information pertaining to this diagnosis. Please refer to the Details section of the Knowledge Article for additional information. faultmgmtsp> fmadm replaced /SYS/MB/P1/D5 faultmgmtsp> fmadm faulty No faults found faultmgmtsp> exit ->

Ссылки в тему:

{lang: 'ru'}