Принудительное отмонтирование NFS файловых систем на HP-UX

Network File System (NFS), протокол сетевого доступа к файловым системам, является прекрасным изобретением. В мире Unix это стандартное решение задачи подключения файловой системы с одной операционной системы на другую. Раздающая операционная система называется сервером. Принимающая, в данном случае монтирующая, сторона - это клиент. Когда сервер и клиент настроены должным образом, взаимодействие протекает прекрасно. Причем, для клиента файловая система часто ничем не отличается от локальной.
Даже в Windows можно активировать поддержку этого протокола.

Наверное из-за такой прозрачной интеграции часто возникают коллизии и недопонимания при настройке NFS. Помните, я писал про важность синхронизации времени на сервере и клиенте?

В конце прошлого года я столкнулся с ещё одной интересной ситуацией. Эта интересная ситуация лишила меня покоя на 3 дня. :) Сейчас всё расскажу по порядку.

Сервер, работающий на операционной системе HP-UX 11.11. Версия старая, согласен, но работает хорошо. И, как говорится, что есть, с тем и работаем. Так вот, данный сервер, в разрезе NFS является сервером, раздавая часть своих файловых систем для других систем, и одновременно клиентом, монтируя пару файловых систем по протоколу NFS с других серверов.

В один момент времени один из серверов, файловую систему с которого наш герой монтировал, пропал. За сервер отвечает третья сторона, поэтому причины падения я не знаю. Но сервер с HP-UX повёл себя следующим образом. Файловая система просто "зависла". Зависали любые попытки перейти в директорию, которая является точкой монтирования злополучной NFS файловой системы, операции-попытки прочитать таблицу файловых систем (команда bdf), команды просмотра содержимого файловой системы и тому подобное.

Команда umount файловой системы не проходила, отвечая, что файловая система "занята" процессами системы: "nfs umount: nfs_unmount: /path: is busy".

Все вы знаете, наверное, команду fuser, которая показывает список процессов, которые держат файлы файловой системы. Так вот, эта команда с опцией, в которой я указывал точку монтирования тоже жестко зависала. Таким образом, я плодил процессы, которые держали файловую систему.

Зная, что команды bdf, fuser висят по моей вине, я нашёл их в таблице процессов командой вида:

# ps -ef | grep bdf

Все они стали сиротами, то есть родительский процесс у них заменился процессом init: PPID=1.

Но на моё удивление, попытки послать им команды останова вида:

# kill -9 PID

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

Дальше, стало еще интереснее. Третья сторона, после сообщения им, что их NFS ресурс не отвечает, отработала и ответила, что сервер восстановлен. Но, у меня на стороне NFS клиента ничего не изменилось! Файловая система не отвечает, наглухо зависнув. В таблице процессов список уже из 7-8 сирот, которые пытались попасть на файловую систему с моей подачи.

При этом, команды ping на сервер проходят, команда вида:

# telnet 2049

где 2049 это NFS порт, отрабатывает корректно. Даже команда запроса экспортируемых файловых систем с NFS сервера (showmount -e IP_NFS_server) отрабатывает! А попытка выполнить монтирование этой файловой системы во временную точку монтирования (/tmp/tmp2) не удаётся! (рис. 1).

Рис. 1. Попытки достучаться до NFS-сервера.

Не верить специалистам третьей стороны у меня причин не было. Занимаясь поиском путей решения на специализированных форумах в Интернете, я всё больше и больше убеждался, что проблема в HP-UX, то есть в NFS клиенте.

Выбрав период, когда я смогу устроить небольшой downtime для монтируемых по NFS файловых систем, я решил попробовать рестарт демонов nfs.client. Демон остановился и стартовал корректно, но отмонтировать данную файловую систему не смог. "nfs umount: nfs_unmount: /path: is busy" - ответила система. :) Рестартовать все NFS-процессы (серверные и клиентские) я не мог из-за использования текущего сервера, как NFS-сервера.

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

Так же я узнал, что в данной ситуации команда bdf в силу своей особенности не рекомендуется (зависает), лучше использовать:

# mount -v 

А команде fuser надо в качестве аргумента давать не локальную точку монтирования, а путь до NFS сервера + директорию:

# fuser IP:/path

Такой вариант команды fuser у меня не зависал, отрабатывал, но ни одного процесса не находил. Да, и по предыдущему опыту я знал, что спящие процессы сигналы от команды kill не принимают.

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

Чтобы еще раз исключить проблемы с NFS сервером, я попытался выполнить временное монтирование нужной мне файловой системы на другой сервер. Попытка удалась. То есть всё сводилось к тому, что проблема на конкретном сервере.

Знаете пословицу: одна голова хорошо, а две лучше? Иногда одна лишь попытка описать проблему, систематизировав все симптомы, помогает. Но чаще, другой человек, со своим свежим взглядом на то, над чем ты бьёшься несколько дней, задаёт новые вопросы, предлагает новые пути решения, а иногда и даёт готовое решение. В этой ситуации для меня стал таким человеком мой коллега (Сергей Шевелёв). Готового решения он мне не дал, но нашел для меня документ "Forcible Unmount NFS filesystems", в котором была описана моя проблема и пути решения.

В данном документе инженер HPE, признавал проблему, описывал ситуации когда она может возникнуть и, если кратко, давал следующие советы:

1. Применять команду fuser не на точку монтирования, а на NFS-путь, о чём я писал выше.
2. Иногда бывает достаточно несколько минут подождать, пока процессы остановятся по timeout и отпустят файловую систему.
3. Создать временный суррогатный NFS сервер, чтобы процессы, которые держат файловую систему получили отклик и остановились с ошибкой.

В документе автор признаёт, во-первых, что такая проблема зависших NFS файловых систем существует в HP-UX. Во-вторых, что в текущих релизах HP-UX (до версии 11.23) официального решения нет. Что в версию HP-UX 11.31 добавят опцию "-f" в команду umount, по которой будет производиться принудительное отмонтирование NFS файловых систем без ожидания освобождения их со стороны процессов системы. Такая опцию, к слову, есть в других операционных системах.

Прочитав этот основательный документ (15 страниц), я попробовал создать суррогатный NFS сервер прямо на текущем сервере. Процедура следующая:

1. Необходимо определить IP адрес NFS сервера, который упал. Для этого смотрим вывод команды mount -v, а потом nslookup NFS_server_hostname.
2. Находим сервер, на котором поднят nfs.server и смотрим доступные сетевые интерфейсы командой netstat -in. В идеале можно использовать сервер, который является NFS клиентом.
3. На интерфейсе, который входит в ту же сеть, что и пропавший NFS сервер, поднять суррогатный сервер, выполнив команду вида: ifconfig lanX:1 IP_NFS_server. Здесь lanX - название необходимого сетевого интерфейса, а "1" - второй IP адрес на этом интерфейсе.
4. Пробуем размонтировать файловую систему, дав если придётся, небольшой timeout процессам, которые удерживают файловую систему.
5. После успешного отмонтирования файловой системы, удаляем суррогатный NFS-сервер, командой вида: ifconfig lanX:1 0.0.0.0.

Как только я поднял на одном из сетевых интерфейсов моего сервера IP адрес NFS сервера, все спящие процессы (bdf, fuser и другие) тут же отвалились (скорее всего с ошибками). После этого корректно отработала команда:

# umount IP:/path

И я смог вздохнуть с облегчением, удалив суррогатный сервер.

Спустя какой-то период времени файловая система настоящего NFS-сервера корректно примонтировалась, то есть операционная система увидела его, выйдя из заколдованного круга.

Получилось очень многословно, поэтому буду заканчивать. В документе от HPE разложено всё по полочкам, объяснены такие моменты как:

• почему команда fuser не выдает в результатах процессы, хотя файловая система занята (виноват buffer cache memory),
• чем плохо использование команды umount с опцией "-f" для принудительного размонтирования,
• почему зависшие процессы не реагируют на команду kill -9 (процессы ждут I/O, а значит уходят на непрерываемый уровень ядра операционной системы),
• какие меры можно принять, чтобы похожая ситуация возникала реже (установка патчей на операционную систему, в особых ситуациях использование метода "soft" при монтировании NFS файловых систем и т.д.).

Допускаю, что в современных Unix-like операционных системах такого безобразия нет, но у кого HP-UX рекомендую скачать и ознакомиться с документом. Предупреждён, значит вооружён. :)

Скачать документ можно по ссылке на официальном сайте HPE.


Автор: Шиболов Вячеслав Анатольевич

История одного долгоиграющего отчёта

Данным постом, я выполняю давно обещанное, но не выполненное. За что приношу свои извинения.

Этот пост написал и просил меня разместить у себя в блоге Дмитрий Бондарев.
Контакты Дмитрия: электронная почта: bdmalex@mail.ru, skype: bdmalex.
Стиль и пунктуация - автора.

История одного долгоиграющего отчёта
... или как сократить срок его выполнения не исправляя ни одной строки ABAP кода

   Существовал в нашей организации SAP ECC 6.0 на HP-UX платформе. И написали по какому-то ТЗ ABAP программисты отчёт дивный, который при запуске колбасил сервер и только после порядка 14 часов работы выдавал результат.

   Ушёл ABAP-программист с чувством выполненного долга в отпуск, и естественно начальство начало задавать вопросы базису: "Почему это работает так долго?".

   Начальственный заход для решения проблемы был простой: добавили в сервер ещё пяток ядер и немного ОЗУ. Запустили отчёт заново – и прослезились, никаких изменений.

   Запускаем отчёт с трассировкой и получаем следующие унылые результаты:

• 98% времени уходит на работу на Сentral Instance (CI),
• 2% времени уходит на работу и взаимодействие с базой данных (DB).

   Так как у нас CI и DB – это 2 разных сервера, я даже слегка расстроился. Мне сначала думалось, что проблема связана с большим временем работы на БД. А стало ясно, что игры с оптимизацией запросов никаких существенных профитов не принесут и оптимизировать надо именно то,что крутится на СI.

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

Выбираем класс "A" – и задание отрабатывает за 12 часов.
Всего на 7% меньше – но уже приятно!

   Дальше, переходим на сервер приложений и запускаем любимую команду top.
Выясняется, что существенный % времени занимает переключение задания между ядрами процессора. А что будет, если жёстко привязать задание к одному процессорному ядру и заставить его работать только там. Зачем тратить драгоценное время на скачки с одного ядра на другое?
Заходим сразу после запуска задания в SM66 (или SM50, ну в общем это дело вкуса) и выясняем необходимый нам PID (идентификатор процесса). Далее на HP-UX под нашим любимым пользователем <sid>adm  запускаем команду:

 > mpsched –c номер_процессорного ядра  –p PID 

   Смотрим результат: отчёт отработал за 10 часов.

Для других *nix-платформ команды привязки следующие:

• bindprocessor для AIX
• psrset для Solaris
• taskset (+ chrt) для Linux

   В принципе, на этом можно было бы успокоиться, но ведь аппетит всегда приходит во время еды? Что ещё можно сделать, чтобы ускориться?

   Ну, а почему бы не повысить приоритет нашему процессу. Запускаем:

 > renice –n +20 –p PID 

   Смотрим результат: отчёт отрабатывает за 8 часов.

   Вот таким, совсем нехитрым способом, можно ускорить выполнение любого отчёта на многопроцессорной машинке с HP-UX (и не сомневаюсь, что аналогично можно сделать на любой *nix платформе, разве что запускаемые команды будут отличаться названием). В моём случае выигрыш составил порядка 42%, что на мой взгляд – вполне осязаемая и ощутимая величина.

Автор: Дмитрий Бондарев (e-mail: bdmalex@mail.ru, skype: bdmalex)

HP-UX. Многоликая команда find

Командная строка операционной системы Unix, в данном случае HP-UX, очень удобный и мощный инструмент, если уметь им пользоваться.

В этом посте я писал, как настроить командную строку в HP-UX.
А тут я давал ссылку на краткую справку по текстовому редактору VI. Совершенно несложно освоить основной набор команд и не бояться работать в операционной системе. Я иногда, чисто машинально, пытаюсь использовать команды VI в блокноте операционной системы Windows. :)

Сегодня я хотел бы привести несколько комбинаций использования команды find в HP-UX, которые могут быть полезны.

Итак, первый вариант позволяет найти все файлы с именем core на сервере:

 # find / -type f -name core -exec ls -l {} \; 

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

Второй вариант - поиск файлов больше определенного размера:

 # find ./ -type f -size +100000000c -exec ls -al {} \; 

 В данном случае поиск осуществляется в текущей директории, выборка идет только простых файлов, размером больше 100 Мб (опция -size +1000000000c). Полученный список отображается на экране (рис. 1).

Рис. 1. Результаты работа команды find.

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

  # find ./ -type f -size +100000000c -exec rm -i {} \; 

Ну и последний полезный, на мой взгляд, вариант:

 # find ./ -type f -mtime +365 -exec ls -al {} \; 

В данном случае, команда выведет на экран список "старых" файлов, которые не модифицировались год (то есть дата модификации больше 356 дней).

Другие опции команды в документации man.

Если у вас есть свои полезные комбинации, пишите в комментариях.

Автор: Шиболов Вячеслав Анатольевич

Гомогенное копирование системы SAP R/3 4.6C

В цикле постов про копирование SAP систем я уже рассказывал про основные этапы гомогенного копирования системы. Этому был посвящен вот этот пост. Там же была ссылка на инструкцию по гомогенному копированию системы SAP ERP 6.0 на платформе MS Windows 2003/Oracle 10g.

Данный пост относится к той же теме, но его еще можно назвать ностальгии-постом. :) Посмотрите на сриншот. Администраторы, которые воюют работают с системами компании SAP 10 лет или более, я уверен, сразу узнают его и пустят скупую слезу. :) Это утилита SAPINST, которая являлась лишь графическим окном к процессу установки системы - процессу R3SETUP.

Итак, сегодня я добавляю в свою коллекцию инструкций - инструкцию по гомогенному копированию системы SAP R/3 4.6С SR2 на платформе HP-UX 11.11 и ORACLE 8.1.7.

Особенности:

• полностью описан процесс подготовки операционной системы HP-UX 11.11 к установке SAP системы и базы данных ORACLE.
• приведена процедура по работе с программой установки системы SAP R/3 4.6C на операционную систему HP-UX.
• в инструкции раскрыта процедура установки СУБД ORACLE 8.1.7 и обновлению её до версии 8.1.7.4.
• описана процедура переноса базы данных ORACLE с использованием утилиты R3COPY и оффлайн бэкапа базы данных.
• указаны шаги по пост-установочной настройке системы.
• приведен список необходимых документов и SAP нот для установки и гомогенному копированию системы.

Данная версия системы до сих пор используется на некоторых предприятиях. Прекрасно работает и помогает им автоматизировать их финансово-хозяйственную деятельность. Хотя администрировать и поддерживать такие системы с каждым годом всё сложнее и страшнее. :)

Подробная инструкция (34 страницы) доступна по этой ссылке (zip-архив, 1540 Кб).

Я думаю, что данная инструкция поможет не только при гомогенном копировании, но и при установке системы SAP R/3 4.6C с нуля. В сети по таким старым вещам информации все меньше и меньше. Так что, надеюсь, что кому-то пригодится. :)

Страница со всеми инструкциями как всегда была оперативно обновлена.


Автор: Шиболов Вячеслав Анатольевич

Как получить серийный номер сервера HP

Для удаленного получения серийного номера сервера, производства компании HP под управлением операционной системы HP-UX, необходимо выполнить команду:

 # getconf MACHINE_SERIAL 

Команда выдаст серийный номер, который необходим для открытия кейса в службе поддержки (рис. 1).

Рис. 1. Получение серийного номера сервера HP.

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

Другие полезные параметры команды:

• KERNEL_BITS - выдает разрядность ядра системы,
• MACHINE_MODEL - выдает модель сервера.

Автор: Шиболов Вячеслав Анатольевич

Переход на зимнее время 26 октября 2014 года

В 2011 году в России был отменен переход на летнее/зимнее время. Я описывал процедуру настройки для SAP систем в этом посте.

21 июля 2014 года был принят федеральный закон № 248-Ф3, по которому 26 октября 2014 года в 2:00 необходимо будет перевести все часы на зимнее время (-1 час), к тому же упраздняется несколько часовых поясов. Подробности можно посмотреть тут.

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

Итак, как я уже отмечал 3 года назад, программное обеспечение (SAP, СУБД и другие) берет за основу время из операционной системы.

Процедура следующая:

NFS: проблемы при монтировании

Часто при попытке примонтировать файловую систему по NFS (Network File System)  операционная система просто доводит до "белого каления" сообщениями вида:

ERROR:nfs mount: get_fh: server:: RPC: Rpcbind failure - RPC: Timed out

А решение проблемы зарыто не очень глубоко - надо проверить есть ли разница установки времени на NFS-сервере и NFS-клиенте. :)

При мало-мальском расхождении монтировать не хочет.


Автор: Шиболов Вячеслав Анатольевич

Logical Volume Manager (LVM) своими руками. Часть IV

Продолжу описывать LVM с практической точки зрения.
Предыдущие части доступны тут:
- Logical Volume Manager (LVM) своими руками. Часть I
- Logical Volume Manager (LVM) своими руками. Часть II
- Logical Volume Manager (LVM) своими руками. Часть III

Еще одна типичная ситуация - это когда необходимо организовать доступ к файловым системам одной Volume Group с разных серверов. То есть физически диски находятся в дисковом массиве, который расположен, например, в SAN-сети (Storage Area Network) и несколько серверов имеют доступ к этим дискам. Такая конфигурация обязательна для организации работы отказоустойчивого кластера на базе MC/ServiceGuard.

Последовательность следующая:

1. Создать необходимую Volume Group c Logical Volumes и файловыми системами с точками монтирования на одном сервере. Назовем его исходным (host1). 
2. Отмонтировать файловые системы и деактивировать Volume Group на исходном сервере:
   • # umount /data 
   • # vgchange -a n /dev/vg01  
3. Создать специальный mapping файл Volume Group на исходном сервере и скопировать его на новый сервер. Назовем его целевым (host2).
   • # vgexport -p -s -m /vg01.map /dev/vg01 - Обратить внимание на опцию -p (режим, когда при экспорте Volume Group vg01 не удаляется на исходном сервере),
   • # rcp /vg01.map host2:/vg01.map 
4. На целевом сервере подготовить диски, презентованные с дискового массива, которые были включены в Volume Group vg01 на исходном сервере, создать директорию и контрольный файл для Volume Group vg01:
   
   • # ioscan -fnC disk - если не созданы файлы устройств, то создать командой: # insf -C disk , больше ничего делать с дисками не надо.
   • # mkdir /dev/vg01
   • # mknod /dev/vg01/group c 64 0x010000 - для поиска свободного младшего номера использовать команду: # ls -al /dev/*/group  
5. Выполнить импорт на целевом сервере, используя mapping файл, полученный в 3 шаге:
   
   • # vgimport -s -m /vg01.map /dev/vg01 - команда сама найдет нужные диски и добавит их в новую Volume Group; для проверки корректности отработки команды можно использовать команду: # strings /etc/lvmtab 
6. Теперь можно активировать Volume Group на целовем сервере, сохранить конфигурацию для восстановления, создать точку монтирования, монтировать файловую систему и, если необходимо, то прописать автоматическое монтирование в /etc/fstab:
   
   • # vgchange -a y /dev/vg01 
   • # vgcfgbackup /dev/vg01 
   • # mkdir /data 
   • # mount /dev/vg01/lvol1 /data 
   • # vi /etc/fstab 

Данным методом можно перенести Volume Groups с одного сервера на другой. В данном случае после переноса их надо удалить на исходном сервере командой:

• # vgexport /dev/vg01 

Автор: Шиболов Вячеслав Анатольевич

Logical Volume Manager (LVM) своими руками. Часть III

Это пост является продолжением цикла про LVM (первая часть, вторая часть).

Команды для сбора информации о файловых системах, структуре LVM и т.п.:

• # bdf - список монтированных файловых систем.
• # ll /dev/*/group - клевая команда для просмотра контрольных файлов всех Volume Groups сервера. Бывает полезна при поиске свободного minor-номера для новой Volume Group.
• # cat /etc/fstab - список всех файловых систем, которые монтируются при старте ОС,
• # vgdisplay -v - информация о всех Volume Groups и 
• # vgdisplay -v vg01 - о конкретной.
• # lvdisplay -v /dev/vg01/lvol1 - информация о Logical Volume lvol1, можно попробовать общий случай:
• # lvdisplay -v /dev/vg01/lv* - информация о всех Logical Volume из Volume Group vg01 (если при создании были паинькой и соблюдали соглашение об именовании: lv* для Logical Volume и vg* для Volume Group).
• # pvdisplay -v /dev/dsk/c0t1d0 - информация о Physical Volume.

Расширение Volume Group (добавление диска), Logical Volume:

1. # pvcreate -f /dev/rdsk/c0t2d0 - подготовить диск для подключения к LVM,
2. # vgextend vg01 /dev/dsk/c0t2d0 - добавить в существующую Volume Group vg01 новый диск.
3. # lvextend -L 48000 /dev/vg01/lvol1 - расширить Logical Volume lvol1 до размера 48000 МБ.
4. Расширить файловую систему на lvol1 (до этой операции, хоть диск (Logical Volume) и стал больше, но файловая система не сможет его использовать):
   - # umount /data - отмонтировать файловую систему,
   - # extendfs -F vxfs /dev/vg01/rlvol1 - расширить файловую систему на все свободное место,
   - # mount /data - монтировать расширенную файловую систему,
   - # bdf - проверить новый размер.

Уменьшение файловой системы и Logical Volume делается очень редко, так как перед этим необходимо удалить данные, сделав резервную копию, а после уменьшить файловую систему и Logical Volume командами newfs и lvreduce.

Ломать, не строить. Команды удаления Logical Volume:

1. # umount /data - отмонтировать файловую систему,
2. # lvremove -f /dev/vg01/lvol1 - удалить Logical Volume с опцией "force" (не смотря на наличие файловой системы и данных),
3. # vi /etc/fstab - отредактировать список монтируемых файловых систем при старте ОС,
4. # vgdisplay -v vg01 - проверить отсутствие Logical Volume.

Удаление физического диска из Volume Group:

1. # pvmove /dev/dsk/c0t1d0 /dev/dsk/c0t2d0 - переместить данные с диска c0t1d0 на другой диск из Volume Group (если не указывать второй диск, то команда сама разместит на оставшиеся диски в Volume Group, конечно, при наличии места на них),
2. # pvdisplay -v /dev/dsk/c0t1d0 - проверка того, что на диске нет данных (ни одного физического экстента - PE),
3. # vgreduce vg01 /dev/dsk/c0t1d0 - удалить диск из Volume Group vg01,
4. # vgdisplay -v vg01 - проверить изменения.

Удаление Volume Group:

1. # lvremove -f /dev/vg01/lvol1 - удалить все Logical Volumes,
2. # vgreduce vg01 /dev/dsk/c0t1d0 - удалить все диски, кроме одного,
3. # vgremove vg01 - удалить Volume Group vg01,
4. # rm -ir /dev/vg01 - удалить директорию vg01.

Можно удалить проще: одной командой
- # vgexport /dev/vg01 - удалит всё, ни о чем не спрашивая. :)

Активация/деактивация Volume Group:

• # vgchange -a n vg01 - деактивирует Volume Group vg01, удаляя ее из LVM-таблицы ядра системы,
• # vgchange -a y vg01 - активирует Volume Group vg01, делая возможным монтирование файловых систем из нее (автоматическая активация проводится при старте ОС),
• # vgchange -a r vg01 - активация Volume Group vg01 в режиме "только для чтения".

Последовательности команд верны для файловых систем HFS, JFS. Есть дополнительная опция, которую можно приобрести у HP - Online JFS. Там есть "вкусные вещи", типа уменьшения/увеличения файловой системы без отмонтирования и т.п. Основная команда - fsadm.

Очень скучные посты получаются. :) Остался в плане еще один на эту тему.

Автор: Шиболов Вячеслав Анатольевич

Logical Volume Manager (LVM) своими руками. Часть II

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

Создание Volume Group vg01:

1. Найти свободные диски. Полезные команды:
   - # ioscan -funC disk - выдает список дисков в системе,
   - # insf -C disk - создает файлы устройств для дисков (если их не было),
   - # bdf - список монтированных файловых систем (помогает определить занятые диски),
   - # swapinfo -d - отображает диски и файловые системы используемые, как swap области,
   - # strings /etc/lvmtab - список существующих Volume Group и дисков в них,
   
   - # vxdisk list - список дисков, занятых в VxVM (еще одна система организации/управления дисками).
2. Проверить доступность и целостность выбранных дисков. Например, /dev/dsk/c0t1d0:
   
   1. # diskinfo /dev/rdsk/c0t1d0 - информация о диске,
   2. # dd if=/dev/rdsk/c0t1d0 of=/dev/null bs=1024K - чтение содержимого диска, поиск "bad-блоков".
3. Подготовить диски, создав на них физические тома (Physical Volumes):
   # pvcreate -f /dev/rdsk/c0t1d0 , для медленных дисков можно задать timeout большего размера, добавив опцию: "-t 180".
4. Создать директорию и контрольный файл (group special file):
   
   1. # mkdir /dev/vg01 
   2. # chmod 755 /dev/vg01 
   3. # mknod /dev/vg01/group c 64 0x010000 , контрольный файл всегда символьного типа - c, старший номер (major) всегда - 64, а младший (minor) кодируется 0xhh0000, где hh - уникальный шестнадцатеричный номер Volume Group.
   4. # chown -R root:sys /dev/vg01 
   5. # chmod 640 /dev/vg01/group 
5. Создать Volume Group:
   # vgcreate /dev/vg01 /dev/dsk/c0t1d0 , если дисков несколько, то перечислить через пробел.
   Набор параметров, который можно задать при создании:
   -l 1-255 (по-умолчанию, 255) - максимальное количество Logical Volume,
   -p 1-255 (по-умолчанию, 255) - максимальное количество Physical Volume,
   -s 1-256 (по-умолчанию, 4 MB) - размер физического экстента (кусочки, которыми распределяется место),
   -e 1-65535 (по-умолчанию, 1016, что соответствует 4 GB) - максимальное количество физических экстентов на диск (физический том). Имеет очень важное значение и устанавливается в зависимости от размера физического тома по формуле: <размер физического тома>/<размер экстента>.
   В дальнейшем не изменяется, что делает невозможным добавление дисков размером больше, чем первоначальный, в Volume Group.
6. Посмотреть параметры Volume Group можно командой:
   # vgdisplay vg01 

Теперь можно создать Logical Volume lvol1:

1. Зарезервировать имя Logical Volume:
   # lvcreate -n lvol1 vg01 
2. Расширить Logical Volume до необходимого размера, выбрав на каком диске в Volume Group:
   
   # lvextend -L 200 /dev/vg01/lvol1 /dev/dsk/c0t1d0 , ключ -L задает размер в МБ, а ключ -l задает размер в экстентах. Будьте внимательны.
3. Можно задать дополнительные параметры:
   - # lvchange -a y|n /dev/vg01/lvol1 - разрешение|запрет на использование Logical Volume.
   
   - # lvchange -p r|w /dev/vg01/lvol1 - право на "только чтение"|"чтение-запись" при использовании Logical Volume.
   - # lvchange -r y|n|N /dev/vg01/lvol1 - опции для работы с "bad-блоками": перемещает "bad-блоки"|не перемещает и выдает ошибку I/O|отключает механизм для использования механизма дискового массива, например.
4. Посмотреть параметры Logical Volume можно командой:
   # lvdisplay /dev/vg01/lvol1 

Можно создать Logical Volume одной командой lvcreate, сразу указав размер, но вышеуказанная последовательность команд позволяет указать на каком диске из Volume Group будет располагаться Logical Volume. Это добавляет гибкости при создании.

Использование Logical Volume lvol1:

• В качестве файловой системы:
  
  1. # newfs -F vxfs /dev/vg01/rlvol1 
  2. # mkdir /data 
  3. # mount /dev/vg01/lvol1 /data 
  4. # vi /etc/fstab - добавить файловую систему для монтирования после перезагрузки.
• В качестве swap области:
  
  1. # swapon /dev/vg01/lvol1 
  2. # vi /etc/fstab - добавить для того, чтобы использовать после перезагрузки.

Перед использованием команд читайте документацию man:
# man <команда> 


Автор: Шиболов Вячеслав Анатольевич

Статистика по ОС/СУБД с установленными SAP системами

Начинающие и опытные SAP BASIS консультанты часто задаются вопросом: а какие операционные системы (ОС) и СУБД чаще выбирают для установки продуктов компании SAP AG?

Ответ на данный вопрос помог бы понять - знание каких ОС и СУБД более востребовано на рынке, а каких менее. Не секрет, что часто SAP BASIS консультанту требуется не только знание систем SAP, но и навыки администрирования, а иногда и тонкой настройки, операционных систем и баз данных. Всё выучить на достаточно глубоком уровне сложно, поэтому приходится выбирать.

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

Итак, для России расклад такой.

Отдельно для Москвы.

NT/INTEL - это та или иная версия MS Windows Server.
Из статистики лидеры видны четко.

Автор: Шиболов Вячеслав Анатольевич

Отмена перевода часов в 2011 году

Помните "проблему 2000 года"? В 2011 году у нас в стране похожая проблема - в России принят закон об отмене перевода часов на летнее/зимнее время.

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

Система SAP (СУБД тоже) берет за основу время из операционной системы. Таким образом, для отмены перевода часов надо отменить его на уровне операционной системы, а вот часовые пояса подправить придется и в системе SAP.

Начнем с операционных систем. Для семейства операционных систем MS Windows компания Microsoft в августе 2011 года выпустила пакет патчей KB2443685, которые решают эту проблему. Описание проблемы можно найти тут. А патчи для своей версии ОС можно скачать тут. До установки патча было так:

После "вступления закона в силу на сервере" так:

Для HP-UX есть UNOF (unofficial) патчи для версий системы HP-UX 11.11, 11.23, 11.31. Патчи имеют вид типа: UNOF_tztab_1111_09_10.depot. Официальные версии компания HP обещает выпустить в конце III квартала 2011 года. Патч изменяет файл /usr/lib/tztab. Раньше для московского часового пояса было так:

# Western Russia (Moscow) Time, Western Russia (Moscow) Daylight Savings
# Time
WST-3WSTDST
0 3 25-31 3  1983-2038 0   WSTDST-4
0 2 24-30 9  1983-1995 0   WST-3
0 2 25-31 10 1996-2038 0   WST-3

Теперь это выглядит так:

# Western Russia (Moscow) Time, Western Russia (Moscow) Daylight Savings
# Time
WST-3WSTDST
0 3 25-31 3  1983-2011 0   WSTDST-4
0 2 24-30 9  1983-1995 0   WST-3
0 2 25-31 10 1996-2010 0   WST-3

После установки патча перезагружать систему не надо. Используемый часовой пояс в файле /etc/TIMEZONE не изменяется - TZ=WST-3WSTDST.

Так же HP предлагает обновить TZ для java специальной утилитой. Подробности описаны тут.


Теперь посмотрим, что у нас есть для системы SAP. Компания SAP AG выпустила 2 SAP notes:

• note 1611884 - Russia: No return to standard time in 2011,
• note 198411 - Current data and information about time zones.

По второй ноте можно импортировать в систему новые часовые пояса (TIME ZONE). Для этого необходимо войти в систему и выполнить отчет TZCUSTIM, в котором указать путь до файла tzdata.dat.

Данный импорт необходимо провести для всех мандантов системы (включая 000). После этого можно проверить настройки отчетом TZONECHECK.

Подробности в вышеуказанной второй ноте в прикрепленном файле. Для систем с SAP_BASIS ниже версии 620 (SAP R/3 4.6C, SAP R/3 Enterprise 4.7) вышеуказанные отчеты предлагается создать в системе самим. Данные настройки можно произвести и вручную, подробности в первой ноте.

Напоминаю, что настройка системного часового пояса в системе SAP производится через транзакцию STZAC. Старые часовые пояса выглядели так:

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

После этого 30 октября можно спать спокойно. =)

Автор: Шиболов Вячеслав Анатольевич

Logical Volume Manager (LVM) своими руками. Часть I

Logical Volume Manager (LVM) - система позволяющая управлять распределением дискового пространства с помощью логических томов. Я делаю памятку прежде всего для HP-UX. В других операционных системах могут быть свои особенности и нюансы, но основа, безусловно, одна.

Структура LVM: один или несколько дисков объединены в Volume Group, внутри которой можно создать один или несколько Logical Volume, между которыми распределить дисковое пространство входящих в Volume Group дисков. На Logical Volume создать файловые системы или swap-области и указать точки монтирования.

Диск, входящий в LVM, имеет определенную структуру и содержит служебную информацию.

Полезные директории и файлы:

• /dev/dsk/cXtXdX и /dev/rdsk/cXtXdX - файлы устройств (block и raw) жестких дисков в системе,
• /dev/vgXXX/group - файл устройств для Volume Group vgXXX,
• /dev/vgXXX/lvXXX и /dev/vgXXX/rlvXXX - файлы устройств (block и raw) Logical Volumes из Volume Group vgXXX,
• /etc/lvmtab - бинарный файл, который содержит список Volume Groups системы и список входящих в них жестких дисков (физических томов). Часть информации из файла можно просмотреть командой strings,
• /etc/lvmconf - директория с бэкапом конфигурационных файлов Volume Group. Обновляется командами изменения Volume Group или Logical Volume или отдельно командой - vgcfgbackup,
• /etc/fstab - список файловых систем и точек монтирования, используется для автоматического монтирования файловых систем при старте ОС,
• /etc/mnttab - список того, что и куда смонтировано в данный момент. Информация используется командами mount/umount и df/bdf.

Продолжение следует... :)

Автор: Шиболов Вячеслав Анатольевич

Подружить кластер и brbackup/brarchive

Исходные данные:

• ленточная библиотека на 2 устройства записи на ленту,
• библиотека подключена по оптической сети (FC),
• система SAP работает в отказоустойчивом кластере (HP MC/ServiceGuard), состоящем из 2-х нод,
• бэкапы базы данных и журналов ORACLE делаются стандартными средствами SAP (brbackup/brarchive).

Вывод команды # ioscan -fnC tape на первой и второй ноде выдает несколько отличную картину:
первая нода кластера:

вторая нода кластера:

Программы brbackup/brarchive информацию для своей работы берут из профиля /oracle/<SID>/<ora_vers>/dbs/init<SID>.sap и из планировщика заданий в SAP - транзакции DB13. В профиле помимо всего прочего прописаны и файлы устройств ленточной библиотеки. Из выше показанных скриншотов видно, что необходимо создавать 2 профиля инстанции для каждой ноды. И обновлять содержимое профиля init<SID>.sap из этих профилей при переходе кластерного пакета на ту или иную ноду.

Есть более изящное решение. Создаем линки к файлам устройств на каждой ноде с одинаковыми именами. Прописываем их в профиль и всё. Профиль один на две ноды.

параметры профиля:

Здесь ltm и rtm - это left type и right tape. Названия выбраны для удобства использования и для несовпадения с возможными реальными.
Так, мне кажется, жить удобнее. :)

Автор: Шиболов Вячеслав Анатольевич

Процессы SAP, ORACLE, HP-UX

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

• DIA - диалоговые процессы, которые выделяются для работы пользователей с системой в режиме диалога;
• BTC - фоновые процессы, которые обрабатывают запланированные фоновые задания системы и пользователей;
• ENQ - процесс блокировки, всегда один и всегда на центральной инстанции;
• UPD(VB), UP2 - процессы обновления данных в базе данных;
• SPO - процессы спула, которые обрабатывают запросы на печать.

Количество тех или иных процессов задается параметрами в профиле инстанции. Посмотреть что и в каком количестве сконфигурировано в системе можно в транзакции SM50. У "пчелок" есть "матка" - диспетчер. Данный процесс системы организует очередь к рабочим процессам, раздает им задания, управляет их запуском и остановкой. Рабочие процессы являются дочерними процессами родительского процесса диспетчера на уровне ОС Unix. Таким образом, стоит понимать, что рабочий процесс системы SAP это отдельный процесс на уровне ОС. Каждому рабочему процессу SAP соответствует shadow-процесс ORACLE, который в свою очередь представляет отдельный процесс на уровне ОС Unix (на платформе Windows ситуация несколько иная).
Любой процесс требует определенный набор ресурсов (оперативная память, такты процессора, место в таблице процессов и т.д.). Поэтому держать неограниченное количество процессов, что со стороны SAP, что со стороны ORACLE или UNIX, не целесообразно. Есть определенный ряд параметров, которые ограничивают количество процессов, прежде всего максимальное. И чтобы SAP, ORACLE и UNIX не вели себя как лебедь, рак и щука, необходимо учитывать эти параметры и согласовывать между собой их значения.
И так, есть общее количество рабочих процессов системы SAP. При этом, если установлены дополнительные сервера приложений, то количество рабочих процессов дополнительных серверов приложений надо учитывать. Количество рабочих процессов SAP задаётся параметрами rdisp/wp_no_* в профиле инстанции системы. В профайле ORACLE (init<SID>.ora) есть 2 параметра: PROCESSES и SESSIONS.
Формулы расчета можно найти в SAP note # 384839 (пункт 2)(для ORACLE версий 8i и 9i) или SAP note # 830576 (для ORACLE версий 10i). В наиболее общем виде формулы выглядят так:

• PROCESSES = #ABAP work processes * 2 + #J2EE server processes * <max-connections> + PARALLEL_MAX_SERVERS + 40
• SESSIONS = 2 * PROCESSES

Если установлена только ABAP-часть, то формула очень проста - удвоенное количество рабочих процессов SAP плюс запас для служебных процессов ORACLE. Например, в системе сконфигурировано 50 рабочих процессов SAP, следовательно, надо выставить PROCESSES = 140, SESSIONS = 280.
На уровне HP-UX есть параметр ядра nfile. Этот параметр задается формулой, которая зависит от параметров nproc и max_users. Если в системе много процессов ORACLE, которые работают с большой базой данных (состоящей из большого количества дата файлов), то можно "схлопотать" ошибку ОС:

Error: 23: File table overflow

Чтобы такого "безобразия" не было. Необходимо чтобы параметр nfile удовлетворял условию:

• nfile > #File descriptors = #Data files * PROCESSES

Для подробной информации стоит заглянуть в SAP notes # 546006 и # 172747. Для установки параметра в HP-UX используйте команду kmtune (kctune) или SAM.

Вышесказанное поможет добавить дополнительный сервер приложений, дополнительные рабочие процессы в систему SAP и при этом согласовать работу базы данных ORACLE и ОС HP-UX, не получив лишних проблем. ;)

А еще у меня есть вопрос знатокам. ;) Почему в формуле расчета параметра PROCESSES для ORACLE количество рабочих процессов SAP умножается на 2? В документации говорится, что одному рабочему процессу SAP соответствует один рабочий процесс ORACLE. Зачем брать ИМЕННО двойное количество. Кто знает - отпишитесь в комментариях. Очень интересно. :)

Автор: Шиболов Вячеслав Анатольевич

Команды для просмотра журналов в UNIX

Для просмотра журналов (логов) различных процессов в UNIX системах я пользуюсь следующим набором команд:

• # more log.log - позволяет просматривать журнал постранично с начала файла. Переход на следующую страницу по нажатии клавиш "Пробел" или "F". Переход на страницу назад - клавиша "B". Можно просматривать построчно вперед - клавиша "Enter". Выход из просмотра лога - "Q".
• # tail -n log.log - просмотреть последние "n" строк журнала. Если количество необходимых строк больше размера страницы, то удобно использовать так: # tail -n log.log | more. Клавиши управления - такие же, как у команды more.
• # tail -f log.log - выводить строки журнала по мере их появления в реальном времени. Эта команда очень помогает, когда необходимо мониторить процесс загрузки/установки и так далее. Или держать такой экранчик в фоне, чтобы всегда быть в курсе событий. Выход - "Ctrl + C".

Автор: Шиболов Вячеслав Анатольевич

Файл-пустышка

Хочу поделится одним трюком. Не помню кто и когда им поделился со мной, может быть сам придумал. Не суть. ;) Главное, что он помогает в работе администратора.

Я его использую так. Как Вы знаете, база данных ORACLE использует журналы. Журналы бывают онлайн и оффлайн. Если база данных работает в ARCHIVELOG режиме, то онлайн журналы, прежде чем СУБД сможет их использовать повторно, копируются в специальную директорию (saparch, oraarch). Если в NOARCHIVELOG режиме, то онлайн журналы просто перезаписываются. Нам интересен первый вариант, в котором работают все продуктивные системы.

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

Я использую такой приём: до попадания в такую ситуацию, создаю в этой директории файл-пустышку, размером примерно 1 Гб и называю его "remove.me":

Если переполняется директория saparch, я (или другой администратор системы) могу спокойно удалить этот файл, и система сразу начнет работать, выйдя из "подвешенного состояния". А я смогу спокойно решить вопрос, что делать с оффлайн журналами в директории. Скорее всего запущу процесс копирования их на магнитную ленту с удалением из директории. Этот простой прием позволяет не впадать в панику, судорожно удаляя оффлайн журналы, которые могут в будущем пригодиться, а потом держать скрещенным пальцы на ногах, молясь, чтобы система не упала до следующего оффлайн бэкапа. Всегда важно, как говорил Карлсон, "спокойствие, только спокойствие". :)

Если у Вас нет большого файла, в Unix-системах его легко создать из маленьких (из тех же оффлайн журналов ORACLE), используя команду cat и перенаправление результата в файл:

# touch remove.me

# cat small_file >> remove.me

Последнюю команду надо выполнять до тех пор, пока размер файла remove.me не достигнет нужного Вам размера.
А (с подсказки пользователя laskavy) можно сделать проще:

# dd if=/dev/zero of=remove.me bs=1024x1024 count=1024

В Windows системе Вы можете таким образом спрятать свой любимый порно-фильм. Это будет мотивировать Вас не доводить ситуацию до сбоя и усердно следить за директорией. :-D
Приём можно использовать не только для директории saparch (oraarch), а везде где это может быть актуально.

Автор: Шиболов Вячеслав Анатольевич

С днем системного администратора - 2010

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

Поздравляю всех системных администраторов с этим праздником!
Желаю, чтобы следующий год прошел еще продуктивнее, чтобы было поменьше сбоев и аварий и чтобы то, чем Вы занимаетесь, радовало Вас и кормило! ;)

А в дополнение, чтобы тема зря не пропадала, расскажу про кнопочку "ТОС" на серверах компании HP. Для удаленного администрирования сервера HP снабжаются управляющим процессором, который именуется MP (в старых моделях GSP). Отсюда есть такое понятие, как MP console или GSP console. На неё можно попасть локально, через терминальную консоль, или удаленно по telnet, если настроен удаленный доступ. MP console имеет свой набор команд, с помощью которых можно посмотреть логи сервера, подать сигналы "перезагрузка", "останов" серверу и так далее. Иногда возникает ситуация, когда сервер не хочет грузится, ну ни в какую, и причину не называет. Вот тогда может прийти на помощь кнопочка "Reset MP", она обычно выполняется в виде утопленной в корпус "пипочки" на задней части сервера. Нажимаете кнопочку, например, карандашом, и сервер производит "глубокую перезагрузку". Очень часто после этого начинает работать. ;)
Так вот, на днях точно в такой же "нокаут" ушла машинка RX2620. Исследование задней стороны сервера показало, что MP console на данную машине не установлена, а есть загадочная кнопка "TOC". Схожесть строения с "Reset MP" навела меня на мысль, что и функциональность она имеет схожую. Нажатие её помогло реанимировать сервер, а поиск информации показал, что "кнопка TOC посылает MP команду tc (Resets through transfer of control)", а "Trancfer of control" = TOC. В общем, кнопка работает также. :)

Вывод. Если сервер не хочет грузиться по непонятной причине, не торопитесь звонить в службу поддержки, нажмите "Reset MP", "Reset GSP" или "TOC". Может помочь. :)

Автор: Шиболов Вячеслав Анатольевич

Запуск/останов SAP инстанции на HP-UX. Часть II.

В первой части статьи я рассказал как запускать SAP-систему на сервере под управлением HP-UX. Теперь давайте посмотрим, что мы можем получить "с этого кролика, кроме ценного меха". :)

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

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

#!/sbin/sh

# Print current date to log
echo "Current date is"
/usr/bin/date
echo "--"

# Stopping SAP system
/sbin/init.d/instance-sap stop
/sbin/init.d/saposcol stop
/sbin/init.d/listener-one stop

# Pause 30 seconds
sleep 30

# Starting SAP & ORACLE
/sbin/init.d/listener-one start
/sbin/init.d/instance-sap start

#Print end line
echo "-------------------"

И, используя утилиту cron, запланировать на ночь тихий и быстрый рестарт SAP-системы, прописав в crontab файле следующие строки:

# Shibolov Vyacheslav. SAP restart.
30 04 21 01 * /home/slava/scripts/sap_restart/start_stop_sap.sh 1>> /home/slava/scripts/sap_restart/start_stop_sap.log 2>&1

Если не хотите писать скрипт, то можно просто прописать следующие строчки в crontab файле:

# Restart SAP system. Shibolov Vyacheslav.
00 23 02 06 * /sbin/rc2.d/K009stopsap 1>> /SAPrestart.log 2>&1
30 23 02 06 * /sbin/rc3.d/S991startsap 1>> /SAPrestart.log 2>&1

Утром спокойно наблюдаете результаты работы. 
Где еще можно использовать данные скрипты? Например, для увеличения размеров файловой системы (команда extendfs). Для этого создаете скрипт, который последовательно останавливает SAP-систему и базу данных, отмонтирует раздел, расширяет его, монтирует на место и запускает SAP-систему. И все это без просиживания администратором ночи на работе. Можете придумать свои случаи применения. :) 

Автор: Шиболов Вячеслав Анатольевич

Запуск/останов SAP инстанции на HP-UX. Часть I.

Запуск процессов-демонов (фоновые процессы, работающие всё время работы системы) в операционной системе HP-UX удовлетворяет стандарту System V. Сначала стартует процесс инициализации системы - init. /etc/inittab - файл настройки процесса init. В нем указан уровень старта системы по умолчанию (3). Процесс инициализации системы (init) запускает скрипт /sbin/rc, который в зависимости от уровня старта системы запускает соответствующие скрипты из директорий /sbin/rcX.d/, где X=0,1,2,3. В данных директориях лежат не скрипты, а линки, начинающиеся на "S" или "K", в зависимости от того, что необходимо на данном уровне сделать с подсистемой - запустить (start) или остановить (kill). Сами скрипты находятся в директории /sbin/init.d/. Файлы настройки подсистем хранятся в директории /etc/rc.config.d/.

Если необходимо "поднять" систему на уровень 3, то процесс /sbin/rc выполняет последовательно скрипты начинающиеся символом "S" из директорий /sbin/rc1.d/, /sbin/rc2.d/, /sbin/rc3.d/, поднимаясь сначала на уровень 1, затем 2, а потом уже 3.
Останов системы происходит в обратной последовательности: выполнение процессом /sbin/rc скриптов начинающихся на символ "K" из директорий /sbin/rcX.d/ (где X=1,2,3) и переход на уровень 2, затем 1 и 0.
Скрипты одни и для того и для другого, просто выполняются с параметром start или stop соответственно. Есть еще параметры start_msg и stop_msg. С этими параметрами скрипты подсистем выдают сообщения, которые можно лицезреть на консоли при старте/останове системы.

Это была матчасть. Теперь перейдем к практике. Как заставить стартовать и останавливаться нашу SAP систему, установленную на сервер под управлением HP-UX. Причем, делать это автоматически при старте/останове ОС.
Для начала надо скачать архив (3 Кб). Выложить его на сервер с HP-UX и установленной системой SAP, например, в директорию /tmp/. Далее последовательность команд на самом сервере под пользователем root такова:

1. Распаковать архив: # gunzip -c /tmp/start_stop_SAP.tar.gz > /tmp/start_stop_SAP.tar
2. # cd /tmp; tar -xvf /tmp/start_stop_SAP.tar
3. Открыть текстовым редактором, например, vi, и подкорректировать последовательно файлы из директории /tmp/start_stop_SAP/etc/rc.config.d/. В данных файлах задаются следующие параметры: oracleVAR, instanceVAR, saposcolVAR, listenerVAR - параметры запуска скриптов, 0 - не запускать, 1- запускать (установив значение в "0", можно на время отключить автостарт/автостоп системы SAP на данном сервере). DATABASE_NAME и INSTANCE_NAME - это SID базы данных и SAP-системы соответственно. В примере - SID = TTM. ORA_SID и SAP_SID - пользователь <sid>adm. В примере - ttmadm. COMMAND_START и COMMAND_STOP - команды запуска и останова SAP-системы. В примере - startsap_tsap_00 и stopsap_tsap_00, здесь tsap - hostname, 00 - номер системы. Аккуратно прописать эти параметры, сохранить файлы.
4. Копируем файлы раз: # cp -p /tmp/start_stop_SAP/etc/rc.config.d/* /etc/rc.config.d/
5. Копируем файлы два: # cp -p /tmp/start_stop_SAP/sbin/init.d/* /sbin/init.d/
6. Копируем файлы три: # cp -p /tmp/start_stop_SAP/sbin/rc2.d/* /sbin/rc2.d/
7. Копируем файлы и четыре: # cp -p /tmp/start_stop_SAP/sbin/rc3.d/* /sbin/rc3.d/

Скрипты очень просты в исполнении. Если Вы знаете основы shell-программирования и процесс запуска-останова SAP-системы на Unix-системах, то легко разберетесь в скриптах и сможете их модифицировать: добавить Java-инстанцию, "разрулить ситуацию" с несколькими установленными SAP-инстанциями на одном сервере. Если будут проблемы, пишите мне, помогу адаптировать скрипты.

Автор: Шиболов Вячеслав Анатольевич