вторник, 15 января 2019 г.

Принудительное отмонтирование 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.


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

среда, 9 января 2019 г.

Книга "Upgrading SAP. The Comprehensive Guide"

Ссылка на статью
Сегодня, первым постом в этом году, я хотел бы рассказать вам об отличной книге.
Книгу я получил в качестве приза, выиграв в конце 2015 года конкурс "Лучший автор SAPLand за 2015 год". То есть, оказалась она у меня в 2016 году. Но руки до неё дошли только в конце прошлого года. :)

Книга, издательства SAP PRESS. Называется "Upgrading SAP. The Comprehensive Guide".


Издана в 2015 году, приобрести в бумажном или электронном виде можно до сих пор. Написали её два "зубра" SAP Basis мира: Mark Mergaerts и Bert Vanstechelman (рис. 1).

Рис. 1. Авторы книги по апгрейду SAP системы.

По именам думал, что ребята немцы, а оказалось из Бельгии. У обоих большой опыт работы с SAP системами (по 20 лет и больше) и, судя по всему, специализируются они на апгрейдах и обновлениях.

Сразу скажу, что книга просто бомба! 550 страниц идеально сбалансированы в плане описательных и архитектурных нюансов и конкретных действий и шагов по апгрейду SAP систем. Конспектировать было очень сложно. В итоге, я просто взял маркер и отмечал все интересные, важные, мегаполезные вещи прямо в книге. В этом бумажный вариант выигрывает. Кто выберет электронный вариант, сможет насладиться своими плюсами: книга всегда с собой, целиком цветное издание! и возможность отмечать куски в pdf документе тоже никто не отменял. Если сравнивать материалы SAP курсов, прочитанные самостоятельно, без преподавателя и практических занятий, и книгу, то книга даёт раза в 3 больше материала и понимания вопроса.

Тут стоить отметить, что это не первая их книга на эту тему. В 2005 году была "The SAP OS/DB Migration Project Guide", потом в 2006 - "mySAP ERP Upgrade Project Guide", в 2007 - "SAP NetWeaver Application Server Upgrade Guide". Книги уже устарели и не издаются, но кое что можно найти на Amazon.com. То есть ребята книгу на эту тему пишут давно, постоянно её дополняя и актуализируя.

Вернемся к текущей книге. В первой главе "Планирование проекта" рассказывается о таких важных вещах, как:
  • зачем нужен апгрейд;
  • факторы влияющие на сложность апгрейда, длительность, затраты;
  • проектная команда и основные роли;
  • крупные мазки по основным шагам проекта;
  • документация и планирование;
  • тестирование системы до, во время и после апгрейда.

Во второй главе "Техническая информация и планирование" авторы останавливаются на следующих моментах:
  • архитектура SAP NetWeaver;
  • SAP ERP и SAP релизы (что-то похожее на мой пост про версии SAP ERP);
  • технология System Switch;
  • специфичные моменты, относящиеся к базам данных;
  • хорошо освещены варианты системного ландшафта, плюсы и минусы разных вариантов;
  • вопросы обновления dual-stack систем и MCOD инсталляций.

Третья глава "Подготовка к техническому апгрейду" охватывает все задачи, которые необходимо выполнить в фазе подготовки к апгрейду:
  • документация;
  • дополнительные сервисы, помогающие спланировать и выполнить проект;
  • аппаратные и программные требования (PAM, sizing);
  • Upgrade и Download directories;
  • установочные диски, SP stacks и EHP.

Следующая глава "Инструкция по утилите обновления SUM" представляет собой 35-страничный документ подробнейшим образом освещающий все аспекты и секреты работы SAP Software Update Manager, о котором у меня был пост. Мой пост это 5% информации, которая есть в этой главе. У авторов эта глава даже есть отдельной брошюрой

Пятая глава самая большая - 120 страниц. Называется "Апгрейд ABAP системы". Шестая глава "Апгрейд Java системы". Стоит отметить, что авторы в качестве примера на страницах книги производят апгрейд версии SAP ERP 6.0 EHP 4 (SAP NetWeaver 7.0 EHP 1) до версии SAP ERP 6.0 EHP 7 (SAP NetWeaver 7.40). Эти две главы являются ключевыми практическими главами, которые описывают все шаги, от "А до Я", которые необходимо выполнить во время апгрейда ABAP и Java систем. 

Седьмая глава "Modification Adjustment" будто бы десерт для SAP Basis консультанта. Как долго эти вещи были для меня (и как пишут авторы, для многих администраторов) "тёмной территорией". А здесь, просто всё разложено "по полочкам". Может быть по этой главе я напишу отдельный пост. Главное собраться. :)

Следующие 7 глав кратко описывают нюансы возникающие при апгрейде таких SAP систем как:
  • SAP Business Warehouse;
  • SAP SCM;
  • SAP CRM;
  • SAP SRM;
  • SAP Enterprise Portal;
  • SAP PI и SAP PO;
  • SAP Solition Manager.

То есть охвачены все системы входящие в SAP Business Suite. И этого авторам было мало. :) В приложении разместили таблицу с версиями систем от SAP R/3 3.1H до построенных на базе SAP NetWeaver 7.40. Данная таблица содержит информацию по возможным путям обновлений между версиями в рамках данного диапазона. И там не только SAP ERP, но и все остальные продукты SAP, построенные на базе SAP NetWeaver.

Чтобы показать степень проработанности материала приведу несколько моих заметок из книги.

Про языки. Полное покрытие всех языков возможно только с помощью Unicode. Конвертация системы в Unicode возможна для всех систем, основанных на SAP WAS 6.20 и новее. Транзакция UCCHECK позволяет просканировать ABAP код на наличие неподходящего для перехода на Unicode кода.

Про тестирование. Первый шаг после апргейда системы разработки - это массовая синтаксическая проверка всех разработок в области имен клиента через транзакцию SAMT.

Про SAP PI. Самой свежей из всех систем ландшафта должна быть SAP Process Orchestration (SAP PO, он же SAP PI или SAP XI). Подробности и исключения в SAP note 1043047.

Про SAP GUI. Необходимо подумать и об обновлении версий SAP GUI пользователей. Сделать это надо до обновления версии SAP системы. После обновления SAP GUI возможна работа со старой системой, так как SAP GUI поддерживает обратную совместимость. User exit EXIT_SAPLSUSF_001 - записывает версию SAP GUI вошедших в систему пользователей. Функциональные модули - GUI_GET_DESKTOP_INFO и GUI_GET_FILE_INFO - показывают версию SAP GUI. Во время тестирования системы после технического апгрейда используемая версия SAP GUI должна быть идентичной той, что будут использовать в будущем конечные пользователи.

Про новую функциональность. Рекомендуется активировать новую функциональность только после полного окончания технического апгрейда и убедившись, что система находится полностью в стабильном состоянии.

Про подготовку. Пробный апгрейд это идеальный путь для оценки трудозатрат и временных рамок для проекта апгрейда. Закладывать для первого апгрейда как минимум 2 недели. Для пробной системы обычно берется копия продуктивной системы. Но для этого надо много дискового пространства. При этом, система разработки худший кандидат для этого, так как её репозитарий перегружен разработками, изменениями, которые не используются, но
всплывут во время апгрейда.

Про технический апгрейд и downtime. Начиная с WAS 6.10 появился механизм - system switch upgrade. Когда параллельно создается shadow instance, в которую импортируется новый репозитарий, и которая работает параллельно с основной. Это снижает длительность downtime во время процесса апгрейда. Во время downtime происходит переключение на новый репозитарий, а старый удаляется. Причем, shadow instance может быть установлена на отдельный сервер, если оборудование целевого сервера не позволяет разворачивание 2-х инстанций. Shadow instance управляется автоматически утилитой обновления (SUM).

Три стратегии при апгрейде:
  • single system - без shadow instance, долгий downtime, но используется минимальное количество ресурсов;
  • standard downtime - создается shadow instance;
  • advanced - самое большое использование ресурсов и самый короткий downtime.

Технология near Zero Downtime Management (nZDM) - максимально уменьшает downtime, до 4-х часов. Подробности в SAP notes: 1678564 и 1678565.

Рекомендуется всегда использовать downtime-minimized strategy, потому что на продуктивной системе надо проводить 100% процедуру, которую проводили до этого. При этом downtime обычно укладывается в 5-8 часов. То есть, хорошо подготовленный апгрейд продуктивной системы реально провести за 2 выходных дня.

Про SUM. У SUM есть 2 роли: Administrator и Observer (доступ только на чтение). Одновременно может работать с утилитой только один администратор. Если еще один переходит в роль Администратора, то старый автоматически переходит в роль Observer.

Утилита состоит из 2-х частей:
  • серверная - запускается скриптом, в Unix рекомендуется запуск в режиме nohup, чтобы не зависеть от открытого shell пользователя. В Windows рекомендуется в конце скрипта добавить команду pause, чтобы в случае сбоя терминальное окно висело и не закрывалось.
  • GUI часть запускается через web-браузер. По-умолчанию, используются порты 4239, 4240, 4241. Порты можно изменить (описание на стр. 203). Если был утерян пароль роли Administrator, то поможет SAP note 1874441 (описание на стр. 203).


Про SP stacks. При апгрейде первой системы в ландшафте необходимо всегда выбирать максимальный SPS для целевой системы. Для продуктивной системы используется уровень SPS, который использовался для предыдущих систем.

Всю книгу не перепишешь. Поэтому категорически рекомендую саму книгу. Если вам хоть раз приходилось проводить апгрейд, то эта книга должна быть в вашей SAP Basis библиотеке.

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

Чего пока в этой книге нет, так это перехода на SAP S4/HANA и нюансов работы базы данных SAP HANA. Хотя несколько слов о SAP HANA ребята всё таки сказали. Если выйдет от них обновленная книга, обязательно постараюсь достать.


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