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 

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

Стандартные пользователи системы SAP

Как известно, после начальной установки любой SAP системы с ABAP-стэком мы имеем несколько стандартных мандантов:

• 000 - эталонный мандант, "прародитель" рабочих мандантов системы; в данном манданте производятся работы по обновлению системы, настройке транспортной системы и так далее;
• 001 - стандартный мандант, "прародитель" рабочих мандантов системы, в некоторых системах  (например, в SAP Solution Manager) может быть использован как рабочий мандант;
• 066 - так называемый "Early Watch Client"; может быть использован службой поддержки компании SAP AG для доступа к системе клиента для анализа проблем, в частности с производительностью.

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

В мандантах 000, 001 после установки системы есть 2 стандартных пользователя:

• SAP* - используется при копировании мандантов, установки/продления лицензии (в случае ее скоропостижного окончания) и т.п.
  Раньше после установки пользователь имел начальный пароль: "06071992", который требовалось изменить в целях безопасности. В новых системах (SAP NetWeaver) во время инсталляции системы изменяется на пароль, указанный в качестве "Master Password":
  
  

  

  Экран установки SAP системы

  
  При удалении учетной записи остаётся псевдо-пользователь с начальным паролем "PASS", с помощью которого можно войти в систему. Подробности я описывал в посте: Как попасть туда, куда не пускают.
  
  
• DDIC - используется при установке системы, обновлении, настройке и работе транспортной системы и других процессах.
  Блокировка/удаление ведет к останову многих процессов системы.
  Раньше после установки пользователь имел начальный пароль: "19920706", который требовалось изменить в целях безопасности. В новых системах (SAP NetWeaver) во время инсталляции системы изменяется на пароль, указанный в качестве "Master Password".

Иногда во время установки системы, основанной на SAP NetWeaver происходит сбой и, после вроде бы корректной установки, администратор не может войти в систему под стандартными пользователями с "Master Password".
В данном случае стоит попробовать старые стандартные пароли. Кстати, пароль - это дата выпуска первой SAP R/3 системы: 6 июля 1992 года.

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

Вебинар про блейд-сервера Fujitsu

17 июля я присутствовал на вебинаре компании Fujitsu, посвященному линейки их блейд-серверов Fujitsu PRIMERGY BX.

Семейство Fujitsu PRIMERGY BX.

Линейка основана на процессорах Intel Xeon последнего поколения.

Данный семинар носит ознакомительный характер, технических нюансов не много, но для ознакомления с концепцией блейд-серверов (или их еще называют "лезвия") вебинар вполне подходит.

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

Презентация доступна тут.
Видео-запись вебинара выложил тут.

Для SAP систем недорогие блейд-сервера с типовой конфигурацией идеально подходят для серверов приложений.

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

Резервное копирование SAP системы

Систему SAP можно представить в виде 3 компонент:

• бинарное SAP ядро,
• профили SAP системы и базы данных,
• файлы базы данных, где располагается бизнес-логика, состоящая из ABAP-программ и настроек (записи настроечных таблиц), и данные-пользователей.

Все компоненты работают на сервере под управлением одной из операционных систем, поддерживаемой компанией SAP AG. Кроме перечисленного есть еще бинарные файлы СУБД (RDBMS), которые обеспечивают доступ к данным, хранящимся в базе данных и осуществляют функции синхронизации, консистентности данных и т.п.

Компоненты SAP системы.

По частоте изменения вышеуказанные компоненты делятся следующим образом:

• бинарное ядро SAP системы обновляется только при обновлении SAP системы, в другое время в является неизменяемым набором данных,
• профили системы и базы данных изменяются редко, только при изменении параметров SAP системы или базы данных,
• база данных - наиболее динамично изменяющаяся часть системы.

Если не рассматривать уровень операционной системы, то для восстановления SAP системы в случае сбоя необходимо восстановление всех трех компонент. Это можно понять, если прочитать мой пост "Копирование SAP систем - I. Перенос/восстановление".

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

• сохранение текущей версии бинарного SAP ядра после каждого обновления системы (которое включает обновление SAP ядра),
• сохранение файлов профилей SAP системы и базы данных после каждого изменения параметров системы. Профили SAP системы обычно загружаются в базу данных и изменяются через транзакцию RZ10. Поэтому копия их в базе данных существует. Но я рекомендую все таки делать копию отдельно. Можно просто в директорию на свою рабочую станцию. Благо файлы небольшого размера. 
• сохранение файлов базы данных я рассмотрю более детально.

База данных ORACLE состоит из нескольких важных частей:

• дата-файлы, в которых хранится вся информация. Располагаются в директориях /oracle/<SID>/sapdataX.
• онлайн-журналы работы базы данных. 4 группы по 2 копии каждого журнала. Директории /oracle/<SID>/origlog<A,B> и /oracle/<SID>/mirrlog<A,B>.
• оффлайн-журналы работы базы данных (если база данных работает в режиме ARCHIVE MODE). Директория /oracle/<SID>/oraarch.
• control-файлы, в которых содержится вся информация о структуре инстанции базы данных. Обычно 3 копии, которые распределены по поддиректориям директории /oracle/<SID>.

Процедура восстановления базы данных, упрощенно, выглядит следующим образом:

1. восстановление дата-файлов,
2. восстановление control-файлов,
3. применение оффлайн-журналов ORACLE (если необходимо).

Рекомендуемый компанией SAP AG цикл резервного копирования базы данных выглядит так:

Рекомендуемый цикл резервного копирования базы данных.

Цикл состоит из 28 дней.
Каждый день рекомендуется делать онлайн ("горячий") бэкап базы данных.
Каждый день необходимо делать две копии оффлайн-журналов ORACLE в разные директории/на разные ленты.
Раз в цикл необходимо делать хотя бы один оффлайн ("холодный") бэкап базы данных.
Раз в неделю обязательная логическая проверка базы данных и проверка одного созданного бэкапа на наличие ошибок чтения.

Для осуществления процедуры резервного копирования компания SAP поставляет набор утилит BR*TOOLs. В частности, brbackup - для резервного копирования дата-файлов, brarchive для копирования оффлайн-журналов ORACLE.
Конфигурационный файл данной утилиты - init<SID>.sap, который располагается в той же директории, что и профайлы ORACLE.

Можно использовать утилиту резервного копирования RMAN, которую предоставляет ORACLE. Или продукты сторонних производителей, например HP DataProtector.

Я всегда считал, что если есть возможно делать оффлайн бэкап базы данных каждый день, то почему бы не делать. И делал. Оффлай бэкап состоит из следующих шагов:

1. Останов базы данных. Сервер приложений SAP продолжает работать, но рабочие процессы теряют соединение с shadow-процессами базы данных.
2. Копия всех дата-файлов и control-файла.
3. Запуск базы данных. Рабочие процессы SAP инстанции восстанавливают соединение до процессов базы данных.

Онлайн бэкап проходит несколько иначе:

1. Первое табличное пространство переводится в специальный режим BEGIN BACKUP.
2. Производится копирование дата-файлов первого табличного пространства.
3. Первое табличное пространство переводится в нормальный режим работы.
4. Шаги 1-3 повторяются для всех табличных пространств базы данных.
5. Создается резервная копия оффлайн-журналов, которые были созданы во время процедуры онлайн бэкапа.

При создании онлайн резервной копии базы данных ORACLE пользователи могут работать с SAP системой, как обычно. При оффлайн - понятное дело, нет.

Но недавно я понял, что при создании оффлайн резервной копии базы данных происходит обнуление буферов ORACLE, так как база данных останавливается. И каждое утро, после ночной резервной копии происходит провал производительности системы до того момента, пока база данных не заполнит буферы данными. Чем больше инстанция и больше буферы, тем больше провал производительности, так как буферы базы данных играют существенную роль.

Исходя из этих рассуждений, мне кажется, что стоит следовать рекомендациям компании SAP AG и создавать ежедневные онлайн резервные копии. А оффлайн делать раз в неделю или реже (но минимум раз в цикл).

Подробности про резервное копирование можно найти в курсе SAP ADM505 - Database Administration (Oracle) - Unit 2.

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

Новая версия miniSAP системы

Про предыдущую версию я писал в этом посте. Это была система на основе SAP NetWeaver 7.0.

Новая версия называется SAP NetWeaver AS ABAP 7.02 SP6 32-bit Trial. Также доступна версия 64 бита. По описанию кажется, что версия отличается лишь одной цифрой, да и та только во втором разряде после точки, но на деле все не так просто. Распространяемая версия представляет собой SAP EHP 2 for SAP NetWeaver 7.0 базируемый на новом SAP kernel 7.20 и использует базу данных MaxDB 7.8.01.018. В состав дистрибутива входит последняя версия SAP GUI 7.20.

Скачать можно на портале SAP Community Network: тут (регистрация бесплатная).

Еще одно немаловажное отличие - это новая версия программы установки. Если в предыдущей версии был специально разработанный для miniSAP инсталлятор, то тут всё по-взрослому. Полноценный, правда предварительно сконфигурированный, SAPINST последней версии.

Требования к системе подросли:

• Windows XP SP2, Windows Server 2003 или Windows Vista. Английская версия.
• минимум 2 Гб ОЗУ (желательно 4-8 Гб),
• файл подкачки минимум 6 Гб,
• Intel Pentium III 1.1 GHz или выше,
• 50 Гб на HDD (35 Гб занимает система с базой данных после установки),
• отсутствие установленной SAP системы с SID = NSP и системным номером = 00.

Документацию по установке и использованию искать в start.htm.

Fujitsu FlexFrame for SAP

В среду, 27 июня, я участвовал в вебинаре компании Fujitsu, посвященному продукту FlexFrame for SAP.

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

• с аппаратной точки зрения основано на архитектуре x86, блейд-сервера типовой конфигурации, серьезный дисковый массив. Апгрейд заменой блейдов.
• в качестве операционной системы используется Suse Linux, причем используется единый образ операционной системы, который производится совместными усилиями компаний Fujitsu и SAP в недрах Вальдорфа. Можно самому патчить образ, если есть желание.
• с программной точки зрения это отказоустойчивый симметричный кластер.
• есть веб-интерфейс для мониторинга всей системы.

Контрольная панель Fujitsu FlexFrame for SAP.

• управление производится с помощью набора команд командной строки shell.
• на всех серверах установлен FlexFrame agent, который отслеживает состояние не только серверов, но и компонент SAP WAS и базы данных. Причем агент обладает набор предустановленных правил для самостоятельной реакции на то или иное событие (например, перезапуск процесса ORACLE LISTENER в случае его сбоя). 
• очень масштабируемая система, много вещей делается "из коробки" и с минимумом временных затрат и сил администратора.

Плюсы использования Fujitsu FlexFrame.

В целом, интересное решение. Выложил запись вебинара и презентацию.

Основная страница решения на сайте производителя - тут.

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

Вышла новая версия SAP GUI 7.30. Первый взгляд

На днях компания SAP AG обновила релиз клиентского программного обеспечения, выпустив SAP GUI 7.30 for Windows. Установочный диск можно скачать на http://service.sap.com/installations.

Поддержка предыдущей версии SAP GUI 7.20 заканчивается 9 апреля 2013 года.
Новая версия будет поддерживаться до 15 июля 2015 года.

Процесс установки не отличается чем-то особенным. Запускаем PRES1\GUI\WINDOWS\WIN32\SetupAll.exe.

Рис. 1. Установка SAP GUI 7.30 - 1.