Как запустить sap bo после рестарта linux

Обновлено: 02.07.2024

SAP HANA — реляционная in-memory база данных от компании SAP, в которой данные хранятся и обрабатываются исключительно в оперативной памяти. Диски используются только для логирования и хранения бэкапов, необходимых для восстановления системы. О плюсах такого решения можно найти много информации в интернете. Но сегодня мы хотим поговорить о минусах.

Мы познакомились с SAP HANA в 2014 году. С тех пор мы сталкивались со многими особенностями работы in-memory базы данных, которые оставили различные отпечатки в нашей истории. Опыт эксплуатации этой БД познакомил нас с несколькими ее недостатками:

Долгое время запуска системы.

Жесткие ограничения по объему потребляемой оперативной памяти.

Борьба с недобросовестными запросами и пользователями.

Сегодня мы поговорим о первой проблеме — долгом запуске системы. Это одна из ключевых проблем технологии. Оперативная память быстрая, расчеты делаются на лету, но при перезагрузке системы данные в эту самую память должны прогрузиться с дисков. Пока этого не произойдет, зайти в систему не получится, или она будет работать ОЧЕНЬ медленно. Со временем проблема усугубляется: чем больше база, тем дольше будет запускаться система.

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

Продуктивный сервер: 12 TB RAM, 448 ядер, SSD-диски. Живая и активная система, в которой одновременно работают более 10 000 пользователей. Система обрабатывает наши производственные процессы, поэтому любая недоступность базы означает финансовые потери для бизнеса и негодование пользователей. Для повышения отказоустойчивости настроен кластер, репликация в котором производится каждые 15 минут.

Время перезагрузки сервера или переезда кластера с ноды на ноду составляет почти 80 минут. Это очень много для бизнеса, и каждый перезапуск вызывает сильный стресс у предприятия. Нас это не устроило, и мы начали искать способы уменьшения времени запуска.

Этап 0: энергонезависимая память Intel Optane

В 2017 году Intel анонсировал новую энергонезависимую память Optane. Преимущество достигается за счет того, что данные остаются в памяти даже после отключения питания. Для in-memory базы данных это означает значительное ускорение запуска системы.

SAP анонсировала поддержку этой памяти в версии HANA 2.0 SPS 03. Первые серверы с Intel Optane на борту стали продаваться в 2019 году, и нам удалось заполучить один из них для тестирования. Мы сравнили два сервера: с обычной памятью и с Intel Optane. Они слабее нашего продуктивного сервера, и в них меньше данных. Между собой они тоже не совсем равны, но для тестирования сгодятся.

Характеристики серверов и результат тестирования:

Обычный сервер

Сервер с памятью Optane

CPU(s)

Model

Model name

Intel® Xeon® CPU E7-8880 v2 @ 2.50GHz

Intel® Xeon® Platinum 8280M CPU @ 2.70GHz

L1d cache

L1i cache

L2 cache

L3 cache

Memory

32 GB RDIMM x 24

Optane Memory

Скорость перезагрузки

58 минут

9 минут 50 секунд

Благодаря технологии Intel Optane удалось сократить время запуска БД почти в 6 раз. Достойный и очень интересный результат. Процесс организации тестирования и полные его результаты — это тема для отдельной статьи. А пока просто отметим, Intel Optane — довольно перспективная технология.

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

Этап 1: Fast Restart — хранение данных между перезапусками БД

В версии SAP HANA 2.0 SPS 04 появилась новая функция — Fast Restart Option. Она позволяет сохранять и повторно использовать основные фрагменты данных в оперативной памяти для ускорения перезапуска БД. Эффект будет только в том случае, если ОС не перезапускается.

Это делается путем создания разделов tmpfs — временного файлового хранилища, предназначенного для монтирования файловой системы, но размещенного в ОЗУ вместо физического диска. Для каждой NUMA-ноды создаются разделы tmpfs, которые разделяются на одинаковые объемы и монтируются в соответствующие директории. Таблицы с данными хранятся в этих разделах, поэтому они не будут считываться из файлового хранилища при запуске БД. Первый запуск системы пройдет как обычно, а вот последующие перезапуски будут в разы быстрее.

Настроить эту опцию достаточно просто, подробная инструкция есть в официальной документации. Сначала выполняем настройки:


Далее монтируем директории:


Директории смонтированы, но потребление памяти в них равно 0. Теперь необходимо прописать параметр basepath_persistent_memory_volumes с указанием всех монтируемых директорий через «;».


Для тестирования мы взяли два сервера: с 1,5 TB RAM и 12 TB RAM. Разный объем памяти выбрали специально, чтобы показать зависимость настройки от размера базы данных.

Мы будем анализировать два этапа загрузки:

Загрузка данных из Column Store (CS). Это область памяти в HANA, которая осуществляет поколоночное хранение данных в таблицах. По сути это означает загрузку основных данных в таблицы.

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

Сервер с 1,5 TB RAM

Сервер с 12 TB RAM

Без Fast Restart

C Fast Restart

Без Fast Restart

C Fast Restart

Загрузка из CS

Полная загрузка БД

Для сервера 1,5 TB время загрузки данных из CS сократилось почти в 8 раз. Это много, но в целом не сильно повлияло на общую скорость загрузки БД.

Для сервера 12 TB время загрузки данных из CS сократилось в 25 раз, а общее время загрузки сократилось в 5 раз.

Хороший пример, который демонстрирует эффективность Fast Restart в зависимости от объема БД: чем больше данных, тем лучше эффект.

Этап 2: быстрая перекачка данных в кластере

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

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

Репликация данных между нодами в SAP HANA может работать в трех режимах: delta_datashipping, logreplay, logreplay_readaccess. Мы рассмотрим только первые два режима, потому что logreplay и logreplay_readaccess работают одинаково в случае репликации между двумя нодами.

delta_datashipping. Этот режим применялся в HANA с первой версии. По умолчанию активная нода передает пассивной дельту данных каждые 15 минут. Снэпшоты с данными передаются в асинхронном режиме по аналогии с дифференциальным бэкапом. Если активную ноду необходимо убрать на техобслуживание, то сначала нужно полностью докачать дельту логов на пассивную ноду. При этом активная нода становится недоступна для записи, чтобы в БД не порождались новые данные.

logreplay. Этот режим появился в HANA 1.0 SPS 10 и установлен по умолчанию в HANA 2.0. В этом режиме дельта логов докатывается и воспроизводится на пассивной ноде непрерывно. Передавать дельту данных не нужно, поэтому объем данных, которые нужно передать на пассивную ноду для переключения, уменьшается.

Режим logreplay включается достаточно просто: изменением параметра в файле global.ini → [system_replication] → operation_mode = logreplay. Для применения режима пассивная нода должна быть оффлайн.


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


В далёком 2010 году я выкладывал посты (часть 1, часть 2) про процесс запуска операционной системы HP-UX. Помимо этого там было описано как настроить автоматический запуск и останов SAP системы вместе с операционной системой.

Потом, как вы помните, был пост, в котором я описывал процесс миграции системы на платформу x86_64 и операционную систему Linux. Пост назывался "История одной миграции SAP системы или Век живи, век учись! - III". Таким образом, система стала работать на операционной системе SUSE Linux Enterprise Server версии 11 SP4 и встал вопрос как автоматизировать запуск и останов SAP системы уже в данной операционной системе.

Всё это я веду к тому, что в этот раз хочу рассказать как решил этот вопрос, может быть кому-то пригодится.

За основу shell-скриптов для решения поставленной задачи я взял скрипт, которым кто-то из читателей поделился в комментарии к старому посту про HP-UX. Но "из коробки" у меня скрипт не заработал. Точнее при ручном выполнении скрипта всё работало "на ура": система запускалась и останавливалась. А вот при запуске скрипта во время старта операционной системы возникали какие-то проблемы и он не срабатывал. Анализ показал, что в скрипте не работает изящное решение по выделению системного идентификатора SAP системы (и базы данных) SAPSID и DBSID из имени скрипта. То есть по какой-то причине при запуске скрипта процессом init не работал вот этот кусок кода:

В итоге, я заменил эти строки на прямое указание идентификатора системы в коде:

Здесь DLC - это пример системного идентификатора системы.

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

Напоминаю ещё раз, что скрипты служат для автоматизации процесса запуска/останова старой SAP системы (используются скрипты startsap и stopsap ) с базой данных Oracle на Linux, использующем систему инициализации SysV .

Инструкция по установке скриптов не сложная:

1. Для настройки запуска/останова SAP инстанции с базой данных Oracle cкопировать скрипт sapctlSID_CI в директорию /etc/init.d , переименовав имя файла и добавив в имя скрипта текущий SAPSID, командой вида:

2. Отредактировать файл /etc/init.d/sapctl<SID> , изменив в начале скрипта строки:

Заменив значение SID на свой <SID>.

3. Права/полномочия на файл должны быть "755", а владельцы файла/группы: "root:root".

4. Следующая команда автоматически создаст ссылки в необходимых директориях /etc/init.d/rc*.d/ для запуска и останова SAP на нужном уровне ОС :

5. После выполнения вышеописанных шагов скрипт будет автоматически запускать и останавливать SAP систему вместе с базой данных ORACLE и процессами sapOScol и LISTENER на 3 и 5 уровнях операционной системы соответственно.

6. Вручную скрипт можно запускать командами со следующими опциями:

  • /etc/init.d/sapctl<SID> status - показывает статус всех процессов SAP + DB;
  • /etc/init.d/sapctl<SID> stop - останавливает все процессы SAP + DB;
  • /etc/init.d/sapctl<SID> start - запускает все процессы SAP + DB;
  • /etc/init.d/sapctl<SID> restart - сначала останавливают систему целиком, а потом запускает SAP + DB;
  • /etc/init.d/sapctl<SID> r3stop - останавливает все процессы только SAP инстанции;
  • /etc/init.d/sapctl<SID> r3start - запускает все процессы только SAP инстанции;
  • /etc/init.d/sapctl<SID> r3restart - сначала останавливает, а потом запускает все процессы только SAP инстанции.

7. Для временного или постоянного отключения автоматического старта и останова SAP системы достаточно удалить ссылки из директорий /etc/init.d/rc*.d/ командой:

8. Скрипт с именем sapctlSID_DI предназначен для запуска/останова отдельной диалоговой инстанции SAP системы. Всё что относится к запуску базы данных из него удалено. Процесс установки и настройки идентичен вышеописанному. При работе в ручном режиме работают опции " status, stop, start и restart ".

Данная инструкция есть в текстовом файле внутри архива со скриптами. Так что достаточно скачать архив.

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


В прошлый раз я рассказал, как с помощью shell-скриптов интегрировать процесс запуска/останова SAP системы в процесс инициализации операционной системы Linux. Всего один скрипт, написанный по определённым правилам, и 2 ссылки на него для старта и останова (рис. 1). А в результате ваша SAP система будет останавливаться, когда операционная система отправляется в shutdown или reboot и аналогично запускаться при её старте. Это позволит получить работающую систему при внезапном незапланированном рестарте сервера. Особенно это актуально для дополнительных серверов приложений или кластерной конфигурации. Когда при сбое на основном узле кластера система должна стартовать на резервном узле без вмешательства администратора. Большинство систем построения отказоустойчивых кластеров имеет свои инструменты для старта-останова приложений, но иногда возможно и использование собственных разработок. Тем более если они тщательно протестированы и работают без сбоев.


Рис. 1. Пример расположения инициализационного скрипта и ссылок на него.

Вторая польза от этих скриптов в том, что вы можете использовать их для ручного останова, запуска или проверки состояния SAP системы. Скрипт для центральной инстанции запускает и останавливает не только SAP инстанцию, но и базу данных с сопутствующими процессами (например, процесс LISTENER). Опции, которые можно использовать для этого, я перечислял в прошлом посте (рис. 2). В случае решения каких-то проблем с системой ( troubleshooting ) лучше выполнять запуск/останов не скриптами, а командами, отслеживая внимательно выполнение каждого шага. А вот если система работает стабильно, то почему бы не облегчить себе немного жизнь: выполнить одну команду, вместо 2-4? :)


Рис. 2. Пример ручного использования инициализационного скрипта.

Третий момент, где мы можем использовать этот скрипт - это запланированный рестарт SAP системы целиком или только её части. Например, изменили вы параметры SAP инстанции и теперь вам необходимо выполнить рестарт инстанции, чтобы параметры подхватились системой. Если у вас есть такой shell-скрипт, то можно запланировать его запуск с нужными параметрами через планировщик операционной системы cron . И при планировании выбрать интервал времени, когда вы можете устроить downtime системе (рис. 3). Чаще всего это возможно сделать или в ночное время, или выходной день, в зависимости от требований к системе.


Рис. 3. Пример планирования рестарта SAP инстанции через cron.

Главное после такого рестарта, не забудьте закомментировать или удалить запись в планировщике. А то в будущем возможен "сюрприз".

Ну и последний пример применения скриптов инициализации - это резервное копирование. На текущем проекте резервное копирование выполняется средствами программного обеспечения HPE Data Protector (иногда называют Micro Focus Data Protector). А для серверов, как я уже рассказывал, используется система виртуализации VMware vSphere. Data Protector прекрасно умеет интегрироваться с VMware и при резервном копировании виртуальных машин использует снимки виртуальных машин (snapshots). Таким образом, происходит резервное копирование "замороженного" снимка виртуальной машины (то есть консистентного состояния всех виртуальных дисков) без прерывания работы основной системы. Для получения более консистентного снимка можно перед его созданием выполнить останов SAP системы вместе с базой данных. А после создания снимка SAP систему сразу же запустить, обеспечив её доступность для пользователей. Реализовать это можно через средства Data Protector. Перед выполнением запроса на создание снимка виртуальной машины программное обеспечение резервного копирования может из целевой операционной системы выполнить shell-скрипт /usr/sbin/pre-freeze-script , а сразу же после создания - другой shell-скрипт /usr/sbin/post-thaw-script . Ну а в этих скриптах можно прекрасно использовать уже написанный инициализационный скрипт для SAP системы (рис. 4).


Рис. 4. Пример shell-скриптов для Data Protector.


Рис. 5. Журнал создания снимков VM для резервного копирования.

Как видите (рис. 5) в данном случае рестарт системы занимает буквально пару минут. В течении этого времени создаётся снимок виртуальной машины, после чего SAP система становится вновь доступной для пользователей. А система резервного копирования (СРК) может спокойно копировать виртуальные диски снимка на целевое хранилище, не влияя на работу SAP системы. И самое главное, мы получаем абсолютно консистентную копию виртуальной машины.

Надеюсь эти примеры убедили вас в том, что данные скрипты могут быть полезны администратору и стоит задуматься об их создании.

Часовой пояс: UTC + 3 часа

Правила форума

ВНИМАНИЕ! Прежде чем задавать вопрос, ознакомьтесь со ссылками ниже:

Вопросы по отличиям версий SAP, Add-On, EHP - сюда
Вопросы по SAP Front End (SAPlogon, SAPgui, guiXT и т.д.) - сюда
Вопросы по LSMW - сюда
Вопросы по архивации в SAP - сюда
Вопросы по SAP GRC - сюда
Вопросы по SAP Business Workplace (почте SAP) и SAP Office - сюда
Вопросы по miniSAP (SAP mini basis) - сюда
Вопросы по SAP HANA - сюда
Вопросы по лицензированию продуктов SAP - сюда

Помогите установить Sap на Ubuntu linux кто имеет опыт в данной области

Не знаю, как там в родных убунтах, но в Mint 16 Cinnamon, все отлично работает.

Изображение

_________________
SAP Basis, SAP Security Audit/Pentest, РФ, Москва

Не знаю, как там в родных убунтах, но в Mint 16 Cinnamon, все отлично работает.
интересное сочетание - линуховый гуй к сап системе на винде.
а как же великий и ужасный опсель?
курс SAP Business Suite powered by SAP HANA
Which of the following statements describes the user experience with traditional enterprise systems?
- Users face no limitations when they drill down on data.
- Users regularly download data in MS Excel for further processing. (правильный ответ)
- Reports do not need to be adjusted over time.
- Users are not confronted with process exceptions or re-work due to outdated information. А там есть возможность запустить java control panel ? В advanced включить java console ? В общем, заставить как-то вывести текст ошибки. Быть может java не подходит..

Бывает из-за этого - нота 1918326, но там гуй запускается, но коннект не создать.

SAP GUI for Java 7.30rev4 displays the error message "Error in opening the connection dialog!" when pressing the "New" for creating a new or the "Edit" button for editing a connection.

Reason and Prerequisites

SAP GUI for Java 7.30rev4 displays the error message "Error in opening the connection dialog!" when pressing the "New" for creating a new or the "Edit" button for editing a connection. This happens on all platforms when there is no entry for "Routers" or "Messageservers" in its configuration or no included configuration file for routers and messageservers in the centrally-managed configuration.

Эта статья ориентирована на самых новичков в Linux ну и тех кого интересует как перезагрузить Linux из консоли. Для меня перезагрузить компьютер в терминале или с помощью графического интерфейса это элементарно, но это база, не все новички ее знают и надо об этом написать.

Сегодня мы рассмотрим такие вопросы, как команда перезагрузки Linux из консоли, перезагрузка удаленно, и непосредственно перезагрузка в графическом интерфейсе. Начнем, пожалуй, с обычной перезагрузки системы.

Перезагрузка Linux в графическом интерфейсе

Здесь, как говорится, что может быть проще. Рассмотрим сначала перезагрузку в Ubuntu Unity. Достаточно нажать на кнопку с шестеренкой в правом верхнем углу экрана, и выбрать пункт Выключение:

reboot_ubuntu1

Затем в открывшимся окне кликнуть по пункту Перезагрузка:

reboot_ubuntu2

В окружении рабочего стола Gnome, все очень похоже на Unity, а в KDE нужно открыть главное меню, перейти на вкладку выход, и выбрать пункт перезагрузить:

reboot_kde

Затем подтвердить перезагрузку.

Перезагрузка Linux в терминале

А здесь уже простор намного шире, существует около десятка команд, которыми можно перезагрузить Linux. Одним нужны root привилегии, другим нет, одни выглядят просто и легко запоминаются, а другие длинные и сложные. Дальше мы рассмотрим их все.

Первая команда перезагрузки Linux, самая распространенная и самая простая:

Как видите, утилите нужны права суперпользователя. После нажатия Enter компьютер сразу уйдет в перезагрузку.

Утилита shutdown, которая используется для выключения тоже позволяет перезагрузить компьютер для этого нужно передать ей параметр -r. Плюс к тому же можно указать время перезагрузки. Сейчас - 0 или now, через одну минуту +1 через две - +2 и т д:

sudo shutdown -r +1

Перезагрузка Linux будет выполнена через минуту после ввода команды.

В системах инициализации совместимых с Init Scripts, существовали уровни загрузки системы - 0,1,2,3,4,5,6, уровень 0 - означал выключение, 6 перезагрузку, остальные режимы работы системы нас сейчас не интересуют. Переключаться между уровнями можно командой init. Только опять же нужны права суперпользователя. Таким образом:

/usr/bin/dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Restart

Тут уже не нужны права суперпользователя. Это были обычные способы перезагрузки Linux, но есть еще один, нестандартный или даже два. Это магические SysRq клавиши. Ядро Linux отслеживает нажатие определенных сочетаний клавиш, и в ответ на них выполняет нужные действия. Сначала включаем поддержку sysrq:

echo 1 > /proc/sys/kernel/sysrq

Лучше это сделать заблаговременно, так как этот способ полезен когда система зависла и ни на что не реагирует:

Для активации SysRq сочетания зажмите Alt + SysRq и нажмите код клавиши. Для нормальной перезагрузки рекомендуется использовать следующую последовательность: R E I S U B, клавиши нажимать в той же последовательности с интервалом приблизительно секунду.

  • R - возвращает управление клавиатурой если Х сервер был завершен некорректно;
  • E - ядро посылает всем процессам, кроме init сигнал SIGTERM;
  • I - отправляет всем процессам, кроме init сигнал SIGKILL;
  • S - ядро проводит синхронизацию файловых систем, все данные из кэша переносятся на жесткий диск;
  • U - перемонтирует все файловые системы в режим только чтение;
  • B - немедленная перезагрузка, без синхронизации, и дополнительных приготовлений.

SysRq можно задействовать и без сочетаний клавиш, записав нужный код операции в файл /proc/sysrq-trigger:

echo b > /proc/sysrq-trigger

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

Удаленная перезагрузка Linux

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

Только опять же для этой операции нужно иметь права root на удаленном сервере.

Выводы

Теперь вы знаете как выполняется перезагрузка linux, вы даже знаете что делать когда система зависла и как перезагрузить сервер по ssh. Если у вас остались вопросы, спрашивайте в комментариях!

Читайте также: