Конфигурации и операции инфраструктуры SAP HANA в Azure

Этот документ содержит рекомендации по настройке архитектуры и работе с системами SAP HANA, развернутыми на виртуальных машинах Azure. Документ также включает сведения о настройке масштабирования по горизонтали SAP HANA для SKU виртуальной машины M128s. Этот документ не предназначен для замены стандартной документации SAP, которая включает следующее содержимое:

• SAP HANA Administration Guide (Руководство по администрированию SAP HANA);
• SAP Installation Guides (Руководство по установке SAP);
• Примечания к SAP.

Предварительные условия

Чтобы воспользоваться приведенными в этом руководстве сведениями, необходимо иметь базовые знания об использовании следующих компонентов Azure:

• Виртуальные машины Azure
• Сети и виртуальные сети Azure.
• Хранилище Azure

Дополнительные сведения по SAP NetWeaver и другим компонентам SAP на базе Azure см. в статье Using Azure for hosting and running SAP workload scenarios (Размещение и выполнение сценариев рабочей нагрузки SAP с помощью Azure) и документации по Azure.

Рекомендации по основной настройке

В следующих разделах описаны рекомендации по основной настройке развертывания систем SAP HANA на виртуальных машинах Azure.

Подключение к виртуальным машинам Azure

Как указано в руководстве по планированию виртуальных машин Azure, существует два основных метода подключения к виртуальным машинам Azure:

• Подключитесь через Интернет и обращайтесь к общедоступным конечным точкам на Jump VM или на виртуальной машине с работающей SAP HANA.
• Подключение через VPN или Azure ExpressRoute.

Подключение "сеть — сеть" через VPN или ExpressRoute необходимо для производственных сценариев. Этот тип подключения также необходим для нерабочих сценариев, связанных с производственными сценариями, в которых используется программное обеспечение SAP. Пример межсайтового подключения приведен на следующем рисунке:

Выбор типов виртуальных машин Azure

В SAP перечисляются типы виртуальных машин Azure, которые можно использовать для рабочих сценариев. Для нерабочих сценариев доступен более широкий спектр собственных типов виртуальных машин Azure.

Разверните виртуальные машины в Azure с помощью:

• Портал Azure.
• Командлеты Azure PowerShell.
• Интерфейс командной строки Azure.

Конфигурации хранилища SAP HANA

Сведения о конфигурациях хранилищ и типах хранилищ, используемых с SAP HANA в Azure, см. в документе Конфигурации хранилища виртуальных машин SAP HANA в Azure.

Настройка виртуальных сетей Azure

Если у вас есть подключение типа "сеть — сеть" в Azure через VPN или ExpressRoute, у вас должна быть как минимум одна виртуальная сеть Azure, которая подключается через виртуальный шлюз к сети VPN или ExpressRoute. В простых развертываниях виртуальный шлюз может быть развернут в подсети виртуальной сети Azure, в которой также размещаются экземпляры SAP HANA. Чтобы установить SAP HANA, необходимо создать две дополнительные подсети в виртуальной сети Azure. Одну подсеть, в которой размещаются виртуальные машины, на которых будут работать экземпляры SAP HANA, Другая подсеть запускает виртуальные машины Jumpbox или управления для размещения SAP HANA Studio, другого управленческого программного обеспечения или вашего прикладного программного обеспечения.

При развертывании виртуальных машин Jumpbox или управления в отдельной подсети можно определить несколько карт виртуальной сети (vNICs) для виртуальной машины HANA с каждой виртуальной сетевой картой, назначенной другой подсети. При наличии возможности использовать несколько виртуальных сетевых интерфейсов, вы можете при необходимости настроить разделение сетевого трафика. Например, трафик клиента можно направлять через основной виртуальный сетевой адаптер, а трафик администратора направляется через второй виртуальный сетевой адаптер.
Вы также назначаете статические частные IP-адреса, развернутые для обоих виртуальных сетевых интерфейсов.

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

Статьи Виртуальный центр обработки данных Microsoft Azure с точки зрения сети и Виртуальный центр обработки данных Azure и плоскость управления предприятием предоставляют дополнительные сведения о работе с виртуальным центром обработки данных и соответствующей структуре виртуальной сети Azure.

Общие сведения о различных методах назначения IP-адресов см. в статье Типы IP-адресов и методы распределения в Azure.

Для виртуальных машин, работающих под управлением SAP HANA, необходимо назначить статические IP-адреса. Причиной является то, что некоторые атрибуты конфигурации для HANA ссылаются на IP-адреса.

С помощью групп безопасности сети (NSG) Azure можно перенаправить трафик, поступающий к экземпляру SAP HANA или Jumpbox. Сначала группы безопасности сети, а затем группы безопасности приложений связаны с подсетью SAP HANA и подсетью управления.

Чтобы развернуть SAP HANA в Azure без подключения типа "сеть — сеть", следует изолировать экземпляр SAP HANA от общедоступного Интернета и скрыть его за прокси-сервером. В этом стандартном сценарии для развертывания используются встроенные DNS-службы Azure для разрешения имен узлов. Встроенные DNS-службы Azure особо важны при более сложном развертывании, в котором используются общедоступные IP-адреса. Используйте группы безопасности сети Azure и виртуальные сетевые модули Azure для контроля и отслеживания маршрутизации из Интернета в архитектуру виртуальной сети в Azure. На следующем рисунке показана примерная схема для развертывания SAP HANA без подключения типа "сеть — сеть" в звездообразной архитектуре виртуальной сети:

Еще одно описание того, как использовать сетевые виртуальные устройства Azure для контроля и мониторинга доступа из Интернета без архитектуры VNet с концентратором и спицами, можно найти в статье Развертывание высокодоступных сетевых виртуальных устройств.

Параметры источника часов в виртуальных машинах Azure

SAP HANA требует надежной и точной информации о времени для оптимальной работы. Традиционно виртуальные машины Azure, работающие в гипервизоре Azure, используют только страницу TSC Hyper-V в качестве источника часов по умолчанию. Усовершенствования технологий в аппаратном обеспечении, хостовой ОС и гостевых ядрах ОС Linux позволили предоставить «Инвариантный TSC» в качестве варианта источника времени для некоторых SKU виртуальных машин Azure.

Страницаhyperv_clocksource_tsc_page TSC Hyper-V поддерживается на всех виртуальных машинах Azure в качестве источника часов. Если базовое оборудование, гипервизор и ядро Linux гостевой ОС поддерживают Invariant TSC, tsc будет предложен как доступный и поддерживаемый источник часов в гостевой ОС на виртуальных машинах Azure.

Настройка инфраструктуры Azure для горизонтального масштабирования SAP HANA

Чтобы узнать, какие типы виртуальных машин Azure сертифицированы для горизонтального масштабирования OLAP или S/4HANA, ознакомьтесь с каталогом оборудования SAP HANA. Флажок в столбце "Кластеризация" указывает на поддержку горизонтального масштабирования. Тип приложения указывает, поддерживается ли масштабирование OLAP или S/4HANA. Для получения подробной информации об узлах, сертифицированных для горизонтального масштабирования, просмотрите запись для конкретного SKU виртуальной машины, указанную в каталоге оборудования SAP HANA.

Для развертывания компоновок с горизонтальным масштабированием на виртуальных машинах Azure ознакомьтесь с минимальными версиями ОС, указанными в записях для конкретных SKU ВМ, в каталоге оборудования SAP HANA. В конфигурации OLAP с горизонтальным масштабированием с n узлами один узел работает в качестве главного. Остальные узлы в пределах максимума, заданного сертификацией, являются рабочими узлами. В число сертифицированных узлов не входят дополнительные резервные узлы.

Для /hana/shared рекомендуется использовать Azure NetApp Files или Файлы Azure.

Типичный базовый дизайн для одного узла в конфигурации горизонтального масштабирования, /hana/shared развернутый в Azure NetApp Files, выглядит следующим образом:

Базовая конфигурация узла виртуальной машины для горизонтального масштабирования SAP HANA выглядит так:

• Для /hana/shared вы используете собственную службу NFS, предоставляемую с помощью Azure NetApp Files или Azure Files.
• Все остальные тома диска не используются совместно разными узлами и не основаны на NFS. Конфигурации и этапы установки для горизонтально масштабируемых установок HANA с раздельными томами /hana/data и /hana/log приведены далее в этом документе. Сведения об использовании хранилища, сертифицированного для HANA, см. в статье Конфигурации хранилища виртуальных машин SAP HANA в Azure.

Для определения размеров томов или дисков, необходимо обратиться к документу требования к хранилищу TDI SAP HANA, чтобы узнать размер в зависимости от количества рабочих узлов. В этом документе предоставляется формула, которую нужно применить, для расчета необходимой емкости тома.

Еще одним компонентом архитектуры, представленным на рисунке одноузловой конфигурации горизонтального масштабирования виртуальной машины SAP HANA, является конфигурация виртуальной сети или, что важнее, подсети. SAP настоятельно рекомендует отделить трафик к клиенту или приложению от трафика между узлами HANA. Как показано на рисунке, эта цель достигается за счет наличия двух разных виртуальных сетевых адаптеров, подключенных к виртуальной машине. Оба vNICs находятся в разных подсетях и имеют два разных IP-адреса. Затем вы будете управлять потоком трафика с помощью правил маршрутизации с использованием групп безопасности сети или маршрутов, заданных пользователем.

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

С точки зрения сети минимальная требуемая архитектура сети будет выглядеть так:

Установка конфигурации горизонтального масштабирования SAP HANA в Azure

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

• Развертывание новой инфраструктуры виртуальной сети Azure или адаптация существующей.
• Развертывание новых виртуальных машин с помощью управляемого хранилища Premium Azure, томов Ultra Disk и/или томов NFS на базе ANF.
• • Адаптировать сетевую маршрутизацию, чтобы убедиться, что, например, обмен данными между виртуальными машинами в пределах одного узла не маршрутизировался через NVA.
• Установка главного узла SAP HANA.
• Адаптация параметров конфигурации главного узла SAP HANA.
• Продолжение установки рабочих узлов SAP HANA.

Установка SAP HANA с конфигурацией горизонтального масштабирования

По мере развертывания инфраструктуры виртуальных машин Azure и выполнения всех других подготовительных работ вам необходимо установить конфигурации горизонтального масштабирования SAP HANA следующим образом:

• Установите главный узел SAP HANA в соответствии с документацией SAP.
• При использовании хранилища Azure уровня "Премиум" или "Ультра" с необщими дисками /hana/data и /hana/log, добавьте параметр basepath_shared = no в global.ini файл. Этот параметр позволяет SAP HANA запускаться в режиме горизонтального масштабирования без общих областей хранения /hana/data и /hana/log между узлами. Дополнительные сведения см. в примечании к SAP № 2080991. Если вы используете тома NFS на основе ANF для /hana/data и /hana/log, это изменение вносить не нужно.
• После окончательного изменения параметра global.ini перезапустите экземпляр SAP HANA.
• Добавьте дополнительные рабочие узлы. Дополнительные сведения см. в разделе Добавление узлов с помощью интерфейса командной строки. Укажите внутреннюю сеть для межузлового обмена данными SAP HANA во время установки или позже, используя, к примеру, локальное средство hdblcm. Дополнительные сведения см. в примечании к SAP № 2183363.

Чтобы настроить горизонтально масштабируемую систему SAP HANA с резервным узлом, см. инструкции по развертыванию SUSE Linux или Red Hat.

Использование SAP HANA Dynamic Tiering 2.0 для виртуальных машин Azure

Кроме сертификации SAP HANA на виртуальных машинах Azure серии M, в Microsoft Azure поддерживается решение SAP HANA Dynamic Tiering 2.0. Дополнительные сведения см. в статье Ссылки на документацию по DT 2.0. Нет никакой разницы в установке или эксплуатации продукта. Например, можно установить SAP HANA Cockpit на виртуальной машине Azure. Но есть некоторые обязательные требования, описанные в следующем разделе, для официальной поддержки в Azure. Далее в этой статье вместо полного названия Dynamic Tiering 2.0 используется сокращение DT 2.0.

SAP HANA Dynamic Tiering 2.0 не поддерживается в SAP BW или S4HANA. Основные варианты использования в настоящее время — это нативные приложения HANA.

Обзор

На рисунке ниже представлены сведения о поддержке DT 2.0 на платформе Microsoft Azure. Есть набор обязательных требований, которые нужно соблюдать для официальной сертификации:

• DT 2.0 необходимо устанавливать на выделенной виртуальной машине Azure (нельзя запускать это решение на той же виртуальной машине, где выполняется SAP HANA);
• виртуальные машины для SAP HANA и 2.0 DT должны быть развернуты в одной и той же виртуальной сети Azure;
• виртуальные машины для SAP HANA и DT 2.0 должны развертываться с включенной функцией ускорения сети Azure;
• для виртуальных машин DT 2.0 нужно использовать хранилище Azure класса Premium;
• к виртуальной машине DT 2.0 нужно подключить несколько дисков Azure;
• необходимо настроить программный RAID-массив или чередование томов (с помощью диспетчера логических томов или средства mdadm), используя чередование на дисках Azure.

Подробнее эти требования будут описаны в следующих разделах.

Выделенная виртуальная машина Azure для SAP HANA DT 2.0

В системах IaaS Azure DT 2.0 поддерживается только на выделенной виртуальной машине. DT 2.0 нельзя выполнять на той же виртуальной машине Azure, где запущен экземпляр HANA. Изначально для запуска SAP HANA DT 2.0 можно использовать два типа виртуальных машин:

• M64-32ms
• E32sv3

Дополнительные сведения об описаниях типов виртуальных машин см. в статье Размеры виртуальных машин Azure – Память.

Исходя из того, что основная задача DT 2.0 заключается в разгрузке "теплых" данных для снижения расходов, есть смысл всегда использовать правильные размеры виртуальных машин. Но для возможных сочетаний нет строгих правил и ограничений. Все зависит от конкретной рабочей нагрузки клиента.

Мы рекомендуем использовать следующие конфигурации.

Поддерживаются любые сочетания виртуальных машин серии M, сертифицированных для SAP HANA, с поддерживаемыми для DT 2.0 типами виртуальных машин (M64-32ms и E32sv3).

Сети Azure и SAP HANA DT 2.0

Для установки DT 2.0 на выделенной виртуальной машине требуется пропускная способность сети не менее 10 ГБ между виртуальными машинами для DT 2.0 и SAP HANA. Поэтому все виртуальные машины необходимо поместить в одну виртуальную сеть Azure, а также включить функцию ускорения сети Azure.

Дополнительные сведения об ускорении сети в Azure см. в статье Создание виртуальной машины Linux с функцией ускорения сети с помощью Azure CLI.

Хранилище виртуальной машины для SAP HANA DT 2.0

В соответствии с рекомендациями для DT 2.0 на каждое физическое ядро следует выделить пропускную способность дискового ввода-вывода не менее 50 МБ/с.

Согласно спецификациям двух типов виртуальных машин Azure, которые поддерживаются для DT 2.0, применяется следующее ограничение на максимальное значение пропускной способности дискового ввода-вывода:

• E32sv3: 768 МБ/c (без кэширования), т. е. по 48 МБ/с на физическое ядро;
• M64-32ms: 1000 МБ/c (без кэширования), т. е. по 62,5 МБ/с на физическое ядро.

Требуется подключить несколько дисков Azure к виртуальной машине версии DT 2.0 и создать программный RAID-массив (с чередованием) на уровне операционной системы, чтобы достичь максимальных показателей пропускной способности дисков на этой виртуальной машине. Один диск Azure не может обеспечить пропускную способность, соответствующую максимальному ограничению для виртуальной машины. Для работы DT 2.0 необходимо использовать хранилище Azure класса Premium.

• Сведения о доступных типах дисков Azure можно найти на странице Выбор типа диска для виртуальных машин IaaS в Azure - управляемые диски.
• Сведения о создании программного RAID-массива с помощью mdadm см. на странице Настройка программного RAID-массива в Linux.
• Сведения о настройке LVM для создания чередующегося тома с максимальной пропускной способностью см. на странице Настройка LVM на виртуальной машине под управлением Linux.

В зависимости от требований к размеру есть несколько вариантов, позволяющих достичь максимальной пропускной способности для виртуальной машины. Ниже приведены возможные конфигурации дисков для томов данных по каждому типу виртуальной машины для DT 2.0, позволяющие достичь верхнего предела пропускной способности для виртуальной машины. Виртуальную машину E32sv3 следует рассматривать как начальный уровень, пригодный лишь для небольших рабочих нагрузок. В случае, если окажется, что скорость недостаточна, может понадобиться изменить размеры виртуальной машины на M64-32ms. M64-32ms имеет много памяти, поэтому нагрузка операций ввода-вывода может не достигать установленного предела, особенно для рабочих нагрузок с большой нагрузкой на чтение. Таким образом, меньшее число дисков в наборе полос (RAID) может быть достаточным в зависимости от специфической рабочей нагрузки клиента. Но если вы не хотите рисковать, используйте перечисленные ниже конфигурации дисков, обеспечивающие максимальную пропускную способность.

В некоторых случаях, особенно если рабочая нагрузка создает большую нагрузку на чтение, производительность операций ввода-вывода можно увеличить включением кэширования узла Azure в режиме "только для чтения", как рекомендуется для томов данных программного обеспечения для базы данных. В то время как для кэша диска хоста Azure для журнала транзакций должно быть выбрано значение «нет».

Что касается размера тома для журнала, мы рекомендуем использовать примерно 15 % от размера данных. Чтобы создать том журнала, можно использовать другой тип дисков Azure с учетом ограничений по бюджету и требований к пропускной способности. Для тома журнала необходима высокая пропускная способность операций ввода-вывода.

В случае использования виртуальной машины типа M64-32ms следует обязательно включить Ускоритель записи. Ускоритель записи Azure обеспечит оптимальное значение задержки для записи на диск журнала транзакций (доступно только для серии M). Но при этом нужно учитывать несколько важных аспектов, например максимальное число дисков для используемого типа виртуальной машины. Подробности об Azure Write Accelerator можно найти на странице Azure Write Accelerator.

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

Как и в случае горизонтального масштабирования SAP HANA, каталог /hana/shared должен быть предоставлен в общий доступ виртуальным машинам SAP HANA и DT 2.0. Мы рекомендуем использовать ту же архитектуру, что и для горизонтального масштабирования SAP HANA, с выделенными виртуальными машинами, которые выполняют роль NFS-сервера с высоким уровнем доступности. Чтобы создать общий том для резервного копирования, можно использовать аналогичную схему. Клиенту следует самостоятельно решить, нужен ли ему высокий уровень доступности или в качестве сервера для резервного копирования можно использовать выделенную виртуальную машину с достаточной емкостью хранилища.

Ссылки на документацию по DT 2.0

• SAP HANA Dynamic Tiering: Installation and Update Guide (Руководство по установке и обновлению SAP HANA Dynamic Tiering)
• Official SAP HANA Dynamic Tiering tutorials and resources (Официальные руководства и ресурсы по SAP HANA Dynamic Tiering)
• Проверка концепции для SAP HANA Dynamic Tiering
• SAP HANA 2.0 SPS 02 dynamic tiering enhancements (Улучшения SAP HANA Dynamic Tiering SPS 02)

Операции развертывания SAP HANA на виртуальных машинах Azure

В следующих разделах описаны некоторые операции, связанные с развертыванием систем SAP HANA на виртуальных машинах Azure.

Операции архивации и восстановления на виртуальных машинах Azure

Следующие документы содержат сведения об архивации и восстановлении развертывания SAP HANA:

• Обзор резервного копирования SAP HANA
• Резервное копирование SAP HANA на уровне файлов
• Тест производительности моментальных снимков хранилища SAP HANA

Запуск и перезапуск виртуальных машин с SAP HANA

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

Удаленная поддержка SAP с помощью SAPRouter

Если вы установили подключение "сеть — сеть" между локальными расположениями и Azure и используете компоненты SAP, вероятно, у вас уже есть SAProuter. В этом случае выполните следующие действия для включения удаленной поддержки:

• Сохраните частный и статический IP-адрес виртуальной машины, на которой размещается SAP HANA, в конфигурации SAProuter.
• Настройте группу безопасности сети подсети, в которой размещена виртуальная машина HANA, чтобы разрешить трафик через порт TCP/IP 3299.

Если вы подключаетесь к Azure через Интернет и у вас нет маршрутизатора SAP для виртуальной машины с SAP HANA, необходимо установить компонент. Установите SAProuter на отдельной виртуальной машине в подсети управления. На следующем рисунке показана примерная схема для развертывания SAP HANA с SAProuter и без подключения "сеть — сеть":

SAProuter следует установить на отдельной виртуальной машине, а не на виртуальной машине Jumpbox. Отдельная виртуальная машина должна иметь статический IP-адрес. Чтобы подключить ваш SAProuter к SAProuter, хостированному SAP, обращайтесь в SAP, чтобы получить IP-адрес. (SAProuter, размещенный SAP, является аналогом экземпляра SAProuter, устанавливаемого на виртуальной машине.) Используйте IP-адрес из SAP для настройки экземпляра SAProuter. В параметрах конфигурации требуется только TCP-порт 3299.

Дополнительные сведения о том, как настроить и поддерживать подключения удаленной поддержки через SAProuter, см. в документации по SAP.

Высокий уровень доступности SAP HANA на собственных виртуальных машинах Azure

Если вы используете SUSE Linux Enterprise Server или Red Hat, вы можете установить кластер Pacemaker с устройствами для изоляции. С помощью этих устройств можно настроить конфигурацию SAP HANA, которая использует синхронную репликацию с HANA System Replication и автоматическим переключением на резервный ресурс. Дополнительные сведения см. в разделе "Дальнейшие действия".

Дальнейшие шаги

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

• Конфигурации хранилища виртуальных машин SAP HANA в Azure
• Развертывание горизонтально масштабируемой системы SAP HANA с резервным узлом на виртуальных машинах Azure с помощью Azure NetApp Files в SUSE Linux Enterprise Server
• Развертывание горизонтально масштабируемой системы SAP HANA с резервным узлом на виртуальных машинах Azure с помощью Azure NetApp Files в Red Hat Enterprise Linux
• Развертывание масштабируемой системы SAP HANA с помощью HSR и Pacemaker на виртуальных машинах Azure на SUSE Linux Enterprise Server
• Развертывание масштабируемой системы SAP HANA с помощью HSR и PAcemaker на виртуальных машинах Azure в Red Hat Enterprise Linux
• Обеспечение высокого уровня доступности SAP HANA на виртуальных машинах Azure в SUSE Linux Enterprise Server
• Обеспечение высокого уровня доступности SAP HANA на виртуальных машинах Azure в Red Hat Enterprise Linux