Очередные полезные вебинары от SUSE Russia

Я периодически смотрю бесплатные вебинары от компании SUSE Russia, в которых они рассказывают про свои продукты. Прежде всего конечно же это операционная система SUSE Linux Enterprise Server (SLES). Как вы уже знаете, данная операционная система активно используется при разворачивании SAP систем и базы данных SAP HANA. Я периодически делюсь ссылками на наиболее интересные вебинары. Например, в прошлом году был пост с тремя интересными записями. 

Сегодня хотел бы поделиться ссылками на ещё две записи вебинаров. По моему мнению эти презентации заслуживают внимания. 

Первый вебинар "Пакеты расширений для SUSE Linux Enterprise Server" был проведён в конце августа. В данном вебинаре автор отдельно останавливается на решениях по построению отказоустойчивых кластеров на базе SLES, вполне подробно рассказывая про решение SUSE Linux Enterprise High Availability Extension (рис. 1). 

Рис. 1. Слайд из презентации.

Данный пакет расширения входит в состав версии операционной системы SLES for SAP Applications, поэтому будет полезно послушать вдвойне. Тайминги этой темы с 9-й по 45-ю минуты.

Далее можно найти немного про супер-компьютеры и высокопроизводительные кластеры (рис. 2). Тайминги с 45-й до 52-ю минуты.

Рис. 2. Слайд из презентации.

Дополнительно было рассказано про построение систем реального времени (Real Time) на базе той же SLES и пару минут про SLED в конце.

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

Второй вебинар с названием "SUSE Round-Up: Linux вчера, сегодня и завтра" проходил в начале сентября 2021 года. Авторы приурочили его к 30-летию проекта Linux и 29-летию компании SUSE. Неудивительно, что в начале видео можно найти историю компании SUSE и дистрибутивов Linux от неё. 

Отдельно в видео рассказано про обеспечение непрерывности бизнеса через расширения SLE High Availability Extension и SLE Live Kernel Patching (рис. 3). И показана демонстрация интерфейса управления отказоустойчивым кластером HAWK.

Рис. 3. Слайд из презентации.

Презентация доступна тут.

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

Запись вебинара "Технологическая архитектура SAP HANA"

Наткнулся недавно на отличный вебинар по архитектуре SAP HANA. Отличие от большинства бесплатных вебинаров по этой теме от компании SAP AG или вендоров оборудования в том, что в данном видео освещены именно технические детали системы. Маркетинга практически нет. Докладчик: Сергей Кузин из SAP AG.

Вот собственно само видео:

Презентацию можно скачать по этой ссылке.

Дополнительно ещё могу посоветовать полезное видео на тему построения отказоустойчивых решений для систем на SAP HANA:

Есть проблемы со звуком, но контент очень интересный и полезный.

P.S. У кого есть похожие материалы, просьба поделиться в комментариях. Спасибо.

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

Развитие SAP NetWeaver. ASCS инстанция.

SAP NetWeaver 7.0

Архитектура AS ABAP системы в SAP NetWeaver 7.0 не сильно отличалась от предыдущих версий системы, построенных на SAP BASIS 6.40, 6.20 и даже где-то 4.6. Первоначальной основной единицей уровня приложений AS ABAP являлась центральная инстанция (Central Instanсe), которая была минимально-необходимой устанавливаемой компонентой. Как вы уже знаете, уровень приложений SAP может быть масштабирован за счёт установки  дополнительных диалоговых инстанций (Dialog Instance). Основой каждой AS ABAP инстанции является ABAP диспетчер, который управляет рабочими процессами различного назначения (DIA, BTC, UPD, SPO) и распределяет задания между ними. Дополнительно в SAP NetWeaver ABAP инстанции работают процессы ICM (Internet Communication Manager) и GW (Gateway). Первый отвечает за обработку запросов из сети Интернет (протоколы SMTP, HTTP, HTTPS), а второй - за коммуникацию по протоколу RFC.   

Отличие между центральной инстанцией и любой дополнительной диалоговой инстанцией заключается в двух процессах:

• ABAP Message Server,
• Процесс ENQ и связанная с ним таблица блокировок (lock table).

ABAP Message Server это важная часть системы, которая осуществляет централизованный обмен сообщениями и балансировку между отдельными инстанциями. Про ENQ процесс и таблицу блокировок не так давно я писал в этом посте. 

Оба процесса присутствуют во всей SAP ABAP системе в единичном экземпляре и в системе SAP NetWeaver 7.0 (и ранее) работают в рамках центральной инстанции (CI). 

Таким образом, центральная инстанция (CI) ABAP системы при построении отказоустойчивых решений являлась единой точкой отказа (Single Point-Of-Failure) и требовала включения её целиком в отказоустойчивый пакет для защиты от сбоя.

SAP NetWeaver 7.1

Начиная с SAP NetWeaver 7.1 парадигма начала немного меняться.

Во-первых, произошло переименование:

• Центральная инстанция (CI) стала Primary Application Server (PAS),
• Диалоговая инстанция (DI) получила название Additional Application Server (AAS).

А во-вторых, появилась новая инстанция в рамках ABAP системы - инстанция ABAP SAP Central Services или кратко ASCS. В рамках данной инстанции появилась возможность отдельно выделить процессы центральной инстанции - ABAP Message Server и Enqueue Server. После такого выделения процессов список компонент PAS ничем не отличается от компонент AAS инстанций (рис. 1).

Рис. 1. Архитектура ABAP части системы SAP NetWeaver 7.1.

Такой состав инстанций рекомендовался для построения отказоустойчивых систем (инсталляция по типу High-Availability System). В данном случае в кластерный пакет необходимо было включить только ASCS инстанцию и инстанцию базы данных, как единые точки отказа. А инстанция PAS не являлась уникальной в рамках списка инстанций серверов приложений.

SAP NetWeaver 7.3

Начиная с SAP NetWeaver 7.3 такая организация инстанций вообще стала обязательной и единственно корректной при любой модели разворачивания системы (Standard, Distributed или High-Availability System) (рис. 2).

Рис. 2. Изменение архитектуры в SAP NetWeaver 7.3.

Таким образом, Primary Application Server называется та инстанция, которая устанавливается первой при разворачивании SAP системы. И никаких отличий от последующих устанавливаемых AAS у неё нет.

Плюсы у решения выделить ASCS инстанцию несомненные есть. Это и организация ресурсов, изоляция узких мест системы и легкость при организации высоко-доступной системы в будущем. 

Стоит отметить, что инстанция ASCS это не что-то кардинально новое. Если вы помните, в AS JAVA части SAP NetWeaver всегда Message Service и Enqueue Service были выделены в отдельную инстанцию - инстанцию Central Services (CS) (рис. 3).

Рис. 3. Архитектура AS JAVA в SAP NetWeaver.

Так как архитектура с инстанцией ASCS стала обязательной для систем основанных на SAP NetWeaver 7.3 и выше, то существует процедура выделения этой инстанции из существующей инстанции PAS (Split Off) (рис. 4).

Рис. 4. Процедура выделения ASCS инстанции.

Процедура производится через одноименный пункт ("Split Off ASCS Instance from Existing Primary Application Server Instance") утилиты установки SWPM. Необходимость в ней может возникнуть, например, при процессе обновления версии системы SAP NetWeaver до 7.3 или выше.

SAP notes по теме:
- 1678705 - Installation scenarios for a standalone ASCS instance,
- 2073500 - FAQ: Splitting off ASCS from PAS,
- 2119669 - How to split the ASCS from Primary Application Server (PAS).


Предыдущие статьи рубрики:
- "Развитие SAP NetWeaver. Start profile".
- "Развитие SAP NetWeaver. Мандант 066".


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

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 

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

Подружить кластер и brbackup/brarchive

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

• ленточная библиотека на 2 устройства записи на ленту,
• библиотека подключена по оптической сети (FC),
• система SAP работает в отказоустойчивом кластере (HP MC/ServiceGuard), состоящем из 2-х нод,
• бэкапы базы данных и журналов ORACLE делаются стандартными средствами SAP (brbackup/brarchive).

Вывод команды # ioscan -fnC tape на первой и второй ноде выдает несколько отличную картину:
первая нода кластера:

вторая нода кластера:

Программы brbackup/brarchive информацию для своей работы берут из профиля /oracle/<SID>/<ora_vers>/dbs/init<SID>.sap и из планировщика заданий в SAP - транзакции DB13. В профиле помимо всего прочего прописаны и файлы устройств ленточной библиотеки. Из выше показанных скриншотов видно, что необходимо создавать 2 профиля инстанции для каждой ноды. И обновлять содержимое профиля init<SID>.sap из этих профилей при переходе кластерного пакета на ту или иную ноду.

Есть более изящное решение. Создаем линки к файлам устройств на каждой ноде с одинаковыми именами. Прописываем их в профиль и всё. Профиль один на две ноды.

параметры профиля:

Здесь ltm и rtm - это left type и right tape. Названия выбраны для удобства использования и для несовпадения с возможными реальными.
Так, мне кажется, жить удобнее. :)

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

Отказоустойчивый кластер 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. Есть возможность - стоит сходить. Если к тому же попадете к Максиму Мошкову, как я в свое время, не пожалеете. :)

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