вторник, 14 августа 2012 г.

SAP JVM 4: установка и переключение

Ссылка на статью
Для своих продуктов компания SAP AG рекомендует устанавливать Java версии 1.4.2_xy. Для большинства платформ подходит Java от компании Sun/ORACLE, а для Linux на x86_64 от IBM (подробности в SAP note 1172419 - Linux: Supported Java versions on the x86_64 platform).

Но начиная с 2011 года, компания SAP AG начала разработку и поддержку собственной версии Java Virtual Machine под названием SAP JVM 4 (параллельно с JVM от Sun и IBM). Мало того, с 1 октября 2012 года будет поддерживаться только собственная разработка компании - SAP JVM 4. Список поддерживаемых платформ и подробности можно найти в SAP notes:


При установки новой системы на базе SAP NetWeaver 7.0 Enhancement Package 3 или выше SAP JVM 4 уже включена в установочный пакет от SAP. А для уже установленных систем компания SAP AG разработала утилиту SAP JVM switch tool для переключения с JVM 1.4.2 на SAP JVM 4. Как скачать утилиту и SAP JVM 4 описано в SAP note 1555341 - Downloading SAP JVM Switch Tool and SAPJVM 4. Искать надо по ссылке http://service.sap.com/patches и ключевому слову "SAP JVM 4". По данной ссылке необходимо скачать, выбрав тип операционной системы, 2 архива:
  • SAPJVMSWITCH<version>.SAR - содержит SAP JVM switch tool,
  • SAPJVM4<version>.SAR - собственно SAP JVM 4 последней версии.

Процедуру переключения на новую SAP JVM 4 покажу на примере SAP Solution Manager 7.01 на платформе Windows x86_64/ORACLE. До обновления использовалась J2SE от Sun/ORACLE версии 1.4.2_22.


Рис. 1. Версия Java до переключения

вторник, 7 августа 2012 г.

Небольшой апдейт

Ссылка на статью

В результате обновления контента для SLD системы на SAP Solution Manager обновил одноименную инструкцию:

- обновление SAP SLD Software Catalog.

В рамках моего примера была решена задача по обновлению SAP_CR для SLD с версии 5.8 (2010 год) до версии 8.2 (2012 год). В инструкции были переработаны экраны и добавлена ссылка на одну SAP note, которая решает проблему при загрузки большого пакета SAP_CR.

Кто пользуется  - качайте, обновляйте.

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


пятница, 3 августа 2012 г.

Опрос: важно ли высшее образование

Ссылка на статью

Хотелось бы узнать ваше мнение по поводу высшего образования в целом, ВУЗ-ов и конкретно вашего случая - где учились, как оцениваете потраченные на это 5-6 лет, используете ли в своей работе полученные знания.

Опрос закрыт.

Если есть желание что-то сказать по этой теме дополнительно - пишите в комментариях.
Спасибо. :)

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


четверг, 2 августа 2012 г.

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 

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