Поделиться через

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

  • Статья

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

Необходимые компоненты

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

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

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

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

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

Как описано в статье SAP NetWeaver на виртуальных машинах Windows. Руководство по планированию и внедрению, есть два основных метода подключения к виртуальным машинам Azure:

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

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

Cross-site connectivity

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

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

Примечание.

Используйте для этих сценариев типы виртуальных машин, которые указаны в примечании к SAP № 1928533. В рабочей среде можно использовать виртуальные машины Azure, сертифицированные для SAP HANA. Они указаны в опубликованном списке сертифицированных платформ IaaS для SAP.

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

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

Вы также можете развернуть полностью установленную платформу SAP HANA в службы виртуальных машин Azure через облачную платформу SAP. Сведения о процессе установки см. в статье Развертывание SAP S/4HANA или BW/4HANA в Azure.

Важно!

Если вы планируете использовать виртуальные машины M208xx_v2, внимательно выбирайте образ Linux. Дополнительные сведения см. в статье Размеры виртуальных машин, оптимизированных для операций в памяти.

Конфигурации хранилища 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 или другого программного обеспечения для управления или ПО приложения.

Важно!

Из соображений функциональности и, что более важно, из соображений производительности в пути взаимодействия между приложением SAP и уровнем СУБД SAP NetWeaver, системой SAP Hybris или S/4HANA не поддерживается настройка виртуальных сетевых модулей Azure (NVA). Связь между прикладным уровнем SAP и уровнем СУБД должна быть прямой. Это ограничение не относится к правилам групп безопасности приложений и сети в Azure, если эти правила разрешают прямую связь. Виртуальные сетевые модули также не поддерживаются в путях взаимодействия между виртуальными машинами Azure, представляющими узлы кластера Pacemaker в Linux, и устройствами SBD, как описано в статье Руководство по обеспечению высокого уровня доступности виртуальных машин Azure для SAP NetWeaver на SUSE Linux Enterprise Server для приложений SAP. Они также не поддерживаются в путях взаимодействия между виртуальными машинами Azure и Windows Server SOFS, настроенными, как описано в статье Кластеризация экземпляра SAP ASCS/SCS в отказоустойчивом кластере Windows с помощью файлового ресурса в Azure. Виртуальные сетевые модули в путях взаимодействия могут легко удвоить задержку в сети между двумя партнерами по взаимодействию и ограничить пропускную способность в критических путях между уровнем приложений SAP и уровнем СУБД. В некоторых сценариях, наблюдаемых клиентами, виртуальные сетевые модули могут привести к сбоям кластеров Pacemaker Linux в случаях, когда узлы кластера Linux Pacemaker должны взаимодействовать с устройством SBD через эти модули.

Важно!

Еще одно НЕПОДДЕРЖИВАЕМОЕ решение – разделение прикладного уровня SAP и уровня СУБД на разные виртуальные сети Azure, не являющиеся одноранговыми. Чтобы отделить прикладной уровень SAP от уровня СУБД, рекомендуем использовать подсети одной виртуальной сети Azure, а не разные виртуальные сети Azure. Если вы решите не следовать этой рекомендации, а разделить два уровня на разные виртуальные сети, то эти виртуальные сети должны быть одноранговыми. Учтите, что за передачу трафика между двумя одноранговыми виртуальными сетями Azure взимается плата. Обмен большими объемами данных, насчитывающими много терабайтов, между прикладным уровнем SAP и уровнем СУБД может повлечь за собой существенные затраты, если прикладной уровень SAP и уровень СУБД находятся в разных одноранговых виртуальных сетях Azure.

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

Примечание.

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

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

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

Примечание.

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

Общие сведения о различных методах назначения 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 без подключения типа "сеть — сеть" в звездообразной архитектуре виртуальной сети:

Rough deployment schema for SAP HANA without a site-to-site connection

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

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

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

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

Примечание.

Горизонтально масштабируемые развертывания SAP HANA с резервным узлом на виртуальных машинах Azure можно выполнять только с помощью хранилища Azure NetApp Files. Другие хранилища Azure, сертифицированные для SAP HANA, не позволяют настраивать резервные узлы SAP HANA.

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

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

Diagram that shows a typical basic design for a single node in a scale-out configuration.

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

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

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

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

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

Примечание.

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

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

Scale-out basics of a single node

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

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

  • Развертывание новой инфраструктуры виртуальной сети Azure или адаптация существующей.
  • Развертывание новых виртуальных машин с помощью управляемого хранилища Azure класса "Премиум" и (или) томов диска ценовой категории "Ультра" на основе NFS.
    • Адаптация сетевой маршрутизации, чтобы убедиться, что, например, обмен данными между виртуальными машинами в пределах одного узла не маршрутизировалась через виртуальный сетевой модуль.
  • Установка главного узла 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.

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

SAP HANA DT 2.0 Architecture Overview

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

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

  • M64-32ms
  • E32sv3

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

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

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

Тип виртуальной машины для SAP HANA Тип виртуальной машины для DT 2.0
M128ms M64-32ms
M128s M64-32ms
M64ms E32sv3
M64s E32sv3

Поддерживаются любые сочетания виртуальных машин серии 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 МБ/с на физическое ядро.

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

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

SKU виртуальной машины Конфигурация дисков 1 Конфигурация дисков 2 Конфигурация дисков 3 Конфигурация дисков 4 Конфигурация дисков 5
M64-32ms 4 x P50 -> 16 ТБ 4 x P40 -> 8 ТБ 5 x P30 -> 5 ТБ 7 x P20 -> 3,5 ТБ 8 x P15 -> 2 ТБ
E32sv3 3 x P50 -> 12 ТБ 3 x P40 -> 6 ТБ 4 x P30 -> 4 ТБ 5 x P20 -> 2,5 ТБ 6 x P15 -> 1,5 ТБ

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

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

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

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

Размер тома данных и тип дисков Конфигурация 1 для объема и типа диска для журнала Конфигурация 2 для объема и типа диска для журнала
4 x P50 -> 16 ТБ 5 x P20 -> 2,5 ТБ 3 x P30 -> 3 ТБ
6 x P15 -> 1,5 ТБ 4 x P6 -> 256 ТБ 1 x P15 -> 256 ТБ

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

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

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

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

Следующие документы содержат сведения об архивации и восстановлении развертывания 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 и без подключения "сеть — сеть":

Rough deployment schema for SAP HANA without a site-to-site connection and 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 и автоматическим переходом на другой ресурс. Дополнительные сведения см. в разделе "Дальнейшие действия".

Next Steps

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