Отказоустойчивый кластер MC/ServiceGuard

Если Вы попали на проект, где есть отказоустойчивый кластер на базе ПО HP MC/ServiceGuard, а Вы никогда с таким не сталкивались, то этот пост Вам поможет.
Отказоустойчивый кластер от HP абсолютно прозрачен. У вас есть 2 или более серверов, которые называются нодами или узлами кластера. У серверов общий дисковый массив (VolumeGroups переводятся в статус кластерных и активируются только кластером). Единицей кластера является пакет. В пакет входит ваше ПО (команды старта и останова), команды активации и монтирования файловых систем с общего дискового массива и виртуальный сетевой интерфейс, через который и работают пользователи с системой. Кластерное ПО отслеживает состояние всех нод кластера. Если основной узел целиком или частично(диски, сетевой интерфейс) теряет работоспособность, то пакет на нем останавливается (если это еще необходимо) и запускается на резервном узле кластера (см. рисунок). Этот процесс называется перетеканием. Пакетов в кластере может быть несколько.

Теперь от теории перейдем к практике. Куда смотреть:

• Команда cmviewcl на любом узле кластера. Показывает информацию о названии и состоянии кластера, пакета и узлов.
• Директория /etc/cmcluster - хранит все настройки кластера и пакетов.
• В качестве журнала для сообщений кластерное ПО использует системный лог - /var/adm/syslog/syslog.log.
• Журнал пакета следует искать в поддиректориях /etc/cmcluster. Имеет вид *.cntl.log.
• Автостарт кластера настраивается в файле /etc/rc.config.d/cmcluster. В ручную запускается командой cmruncl.
• Старт и останов пакета - командами cmrunpkg и cmhaltpkg. Подробности в руководстве man ОС.

Надеюсь, этот пост даст Вам начальные знания по данной теме. А дальше дело за Вами.
В учебном центре HP в Москве читают курс H6487S - HP ServiceGuard. Есть возможность - стоит сходить. Если к тому же попадете к Максиму Мошкову, как я в свое время, не пожалеете. :)

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

Решение проблем с транспортной системой

Самое гениальное, что есть в системе SAP и что кочует практически неизменным из версии в версию, это транспортная система (TMS). И действительно, зачем менять прозрачный и отлаженный механизм? :)
Но время от времени и в такой идеальной системе возникают проблемы. Как у меня сегодня утром. Перестали импортироваться запросы в тестовую систему. Перелопатил всё что можно, пока докопался до причины. Решил написать памятку для коллег. И так,

• Транзакция STMS. Входите в очередь нужной системы и там изучаете пункты меню "Перейти к". Особенно пункты "Монитор импорта" и системный журнал программы tp.
• Таблица E070L. Содержит номер последнего запроса в системе. Можно сделать скачок в будущее :) Подробности в SAP Note # 12799.
• Таблица TMSTLOCKR. Хранит блокировки импортируемых в данный момент запросов.
• Таблицы TRBAT и TRJOB. Временные записи во время импорта.
• Фоновые задания RDDIMPDP. Смотреть выполняются или нет, почему. Планирование заданием RDDNEWPP в 000 манданте. Подробности в SAP Note # 26966.
• На уровне ОС файловая система /usr/sap/trans и поддиректории. Полномочия, права, свободное место.
• Процессы tp на уровне ОС.

Есть хороший курс по транспортной системе (TMS) - ADM325. Рекомендуется минимум прочитать самостоятельно.

P.S. А моя проблема была в старой записи в табличке TRJOB. Кстати, очистить такую рабочую табличку от всех записей можно через транзакцию SE14. Вписываете имя объекта. Нажимаете кнопку "Edit" и, выбрав "Delete data", жмёте "Activate and adjust database". Опля! И табличка пустая.


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

Журналы SAP-системы

Основной системный журнал SAP системы можно увидеть запустив транзакцию SM21 (Tools -> Administration -> Monitoring -> System Log). Отображаются сообщения с текущей SAP-инстанции. Записи журнала считываются из файла, который задан параметром rslg/local/file. По умолчанию, /usr/sap/<sid>/<Instance_name>/log/SLOG<instance_number>. Параметр rslg/max_diskspace/local задает размер файла системного журнала. По умолчанию, 500000. После заполнения - старые записи удаляются. Размер одной записи 192 байта. Можно собирать записи журналов со всех серверов приложений на центральной инстанции. Для этого необходимо выставить ряд параметров. Подробности на SAP Help Portal.

Транзакция ST22 - просмотр ABAP-дампов системы. Можно через меню "Перейти к -> Реорганизовать" установить срок хранения дампов. Величина срока хранения дампов зависит от частоты анализа Ваших систем. Обычно, 7 дней вполне достаточно. Дампы хранятся в таблице SNAP.

Можно включить Security Audit Log системы. Из данного журнала можно увидеть удачные и неудачные входы пользователей в систему, блокировку пользователей, запуск транзакций, отчетов, изменения основных записей пользователей. Временно включается в транзакции SM19. Постоянно параметром rsau/enable=1. Параметр rsau/local/file задает директорию где будут хранится журналы. По умолчанию, /usr/sap/<sid>/<Instance_name>/log/audit_<instance_number>. Через параметр rsau/max_diskspace/local задается размер аудит-файла за день. Просмотр журнала через транзакцию SM20. Удаление старых журналов - транзакция SM18.

Также есть возможность активировать аудит изменений в таблицах. В профиле прописать параметр rec/client = XXX (номер манданта). Можно задать несколько мандантов через запятую. Для нужных таблиц в SE11 в технических параметрах настройки включить "журнал изменений". Просмотр аудита - транзакция SCU3. Журнал аудита хранится в таблице DBTABLOG.

Я описал здесь не все журналы. Помните, что любое журналирование, особенно дополнительное, в той или иной степени уменьшает производительность системы.

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

Особенность работы HP EVA-5000

Сегодня утром столкнулся с неприятной особенностью работы дискового массива HP EVA-5000. Перед выключением оборудования был сбой в батареях резервного питания кэша одного из контроллеров. После остановки массива и включения его вновь, оказалось, что теперь и на втором контроллере не работают батареи кэша. В результате такой коллизии - дисковый массив виден с управляющего сервера через CommandView EVA, но ни один из виртуальных дисков серверам не доступен. Что я только не пробовал (с) :) На массиве, кроме предупреждений, что батарея кэша на обоих контроллерах не доступна и система не сможет проработать ни минутки после отключения питания, ни одного сообщения об ошибках не было. Но ни старые виртуальные диски, ни новые не были видны извне.

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

Дело мне кажется в том, что кэши на контроллерах используются для записи и чтения. В режиме чтения внезапное прекращение подачи питания на дисковый массив совершенно не страшно. А вот для режима записи это черевато получением неконсистентных данных. Поэтому при отсутствии поддержки резервным питанием кэша одного из контроллеров этот контроллер работает только на чтение, а все операции записи производятся через второй рабочий контроллер. Потому что при таком предупреждении, как сбой в батареях резервного питания кэша одного из контроллеров, сильного провала производительности не наблюдается. А вот когда оба контроллера находятся в одинаковом плачевном состоянии, EVA просто перестает давать доступ к дискам, перестраховываясь на случай сбоя подачи питания и получения неконсистентности в данных на массиве. Это все мои домыслы, но практика показывает, что примерно так и есть. Так ли себя ведут дисковые массивы серий EVA 6XXX и 8XXX я не знаю, но есть подозрение, что так же.

Вывод один: держи ноги в тепле, а оборудование полностью работоспособным. :)

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

Интересные ссылочки

Недавно был запущен новый проект в Рунете - ITpedia (или Айтипедия) – независимый образовательный проект по созданию свободной энциклопедии об информационных технологиях. На сайте очень много статей из области IT. Очень помогает поднять свои знания в понимании того что есть что и кто есть кто. :)

А на проекте Лукоморье появилась статья посвященная SAP. Забавно почитать про наш маленький мир без цензуры и прикрас. Ведь в какой-то степени все что там написано - правда. ;)

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

Текстовый редактор VI

Если Вам приходится администрировать SAP-систему на Unix-like операционной системе, то вам поможет этот краткий справочник по текстовому редактору VI.

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

P.S. Вышла новая версия WEB броузера Mozilla Firefox 3.5. Кто пользуется - не пропустите ;)

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

Командная строка HP-UX

Командная строка операционной системы HP-UX после установки ОС далека от совершенства. Выглядит она вот так:

Попробуем развеселить эту картину. :) Добавьте в файл .profile, который находится в корневой директории, следующие строки:

# Add by *** *** at 29.11.2006
PS1=$LOGNAME@`uname -n`:'$PWD '
HISTFILE=$HOME/.sh_history
HISTSIZE=512
ENV=$HOME/.shrc

После этого у вас будет сохраняться история вводимых команд, а командная строка будет выглядеть так:

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

Для редактирования командной строки в Windows-стиле и прокрутки команд из истории, создайте в корневой директории файл .shrc. И пропишите в него следующие строки:

set -o emacs
alias __A=`echo "\020"`
alias __B=`echo "\016"`
alias __C=`echo "\006"`
alias __D=`echo "\002"`
alias __O=^O

^O - это Ctrl+O. После этого в командной строке начнут работать клавиши вверх-вниз-вправо-влево, Backspace.


Те же процедуры можно повторить для всех пользователей системы, а не только для root. А если Вы используете X-Window, то отредактируйте файл .dtprofile, убрав комментарий с последней строки:

#DTSOURCEPROFILE=true

Приятной работы! :)

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