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

Статья
03/25/2023

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

Обзор

Крупные экземпляры Azure для SAP HANA (HLI) были впервые объявлены в сентябре 2016 года. С этого времени многие организации реализовали это оборудование как услугу в качестве платформы для вычислений в памяти. В последние годы увеличение размера виртуальной машины Azure и поддержка горизонтального масштабирования развертывания HANA превысили требования к емкости базы данных ERP для большинства корпоративных клиентов. Многие из них выражают интерес к переносу рабочих нагрузок SAP HANA с физических серверов на виртуальные машины Azure.

Эта статья не является пошаговым руководством. Здесь описываются общие модели развертывания и предлагаются рекомендации по планированию и выполнению миграции. Цель настоящего документа — обозначить факторы, которые необходимо учитывать на этапе подготовки для уменьшения времени простоя в процессе перехода.

Предположения

Для работы с этой статьей предполагается следующее:

Мы рассмотрим только однородную миграцию вычислительной службы базы данных HANA с крупных экземпляров HANA (HLI) на виртуальную машину Azure без значительных обновлений программного обеспечения или внесения исправлений. К таким небольшим обновлениям относится применение более новых версий операционной системы или HANA, которые явно указаны как поддерживаемые в соответствующих примечаниях SAP.
Все операции по обновлению необходимо выполнить до или после миграции. Например такие, как преобразование SAP HANA MCOS в развертывание MDC.
Подход к выполнению миграции, который обеспечивает наименьшее время простоя, — это репликация системы SAP HANA. Другие методы миграции выходят за рамки рассмотрения в этом документе.
Это руководство применимо к двум номерам SKU для HLI: Rev3 и Rev4.
Архитектура развертывания HANA во время миграции остается в основном без изменений. То есть система с аварийным восстановлением с одним экземпляром останется такой же и в месте назначения.
Вы должны изучить и понять Соглашение об уровне обслуживания (SLA) для целевой (предполагаемой) архитектуры.
Условия коммерческого использования для HLI и виртуальных машин различаются. Отслеживайте использование виртуальных машин для управления затратами.
Вы должны понимать, что HLI является выделенной вычислительной платформой, а виртуальные машины работают на основе общей, но изолированной инфраструктуры.
Вы должны удостовериться, что целевые виртуальные машины поддерживают предполагаемую архитектуру. Список поддерживаемых номеров SKU виртуальной машины, сертифицированных для развертывания SAP HANA, можно просмотреть в каталоге оборудования SAP HANA .
Вам следует проверить план проекта и миграции.
Необходимо наличие плана для аварийного восстановления виртуальной машины, а также первичного сайта. Вы не можете использовать HLI в качестве узла аварийного восстановления для первичного сайта, работающего на основе виртуальных машин после миграции.
Вы должны скопировать необходимые файлы резервных копий на целевые виртуальные машины, исходя из требований по восстановлению работоспособности бизнеса и положений нормативных документов. Резервные копии, доступные для виртуальной машины, позволяют в процессе перехода выполнять восстановление на определенный момент времени.
Для реализации высокого уровня доступности репликации системы SAP HANA (HSR) вам необходимо установить и настроить устройство ограничения в соответствии с руководствами по обеспечению высокого уровня доступности в SAP HANA для SLES и RHEL. Настройки в этом случае отличаются от варианта с использованием HLI.
Такой подход к миграции не распространяется на номера SKU для HLI с конфигурацией Optane.

Сценарии развертывания

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

Идентификатор сценария	Сценарий HLI	Буквальная миграция на виртуальную машину?	Комментарий
1	Одноэкземплярная система с одним узлом	Да	-
2	Один узел с несколькими компонентами в одной системе (MCOS)	Да	-
3	Один узел с аварийным восстановлением, реализуемым с помощью репликации хранилища	Нет	Репликация хранилища недоступна для виртуальной платформы Azure, необходимо изменить текущее решение по аварийному восстановлению на HSR или на резервное копирование/восстановление.
4	Один узел с аварийным восстановлением (многоцелевым), реализуемым с помощью репликации хранилища	Нет	Репликация хранилища недоступна для виртуальной платформы Azure, необходимо изменить текущее решение по аварийному восстановлению на HSR или на резервное копирование/восстановление.
5	HSR с ограничением для обеспечения высокого уровня доступности	Да	Для целевых виртуальных машин нет SBD с предварительной настройкой. Выбор и развертывание решения ограничения. Возможные варианты: Агент ограждения Azure (поддерживается для RHEL, SLES и SBD).
6	Высокая доступность с помощью HSR, аварийное восстановление с помощью репликации хранилища	Нет	Замена репликации хранилища для нужд аварийного восстановления, реализуемого с помощью HSR или резервного копирования/восстановления.
7	Автоматическая отработка отказа узла (1+1)	Да	Используйте Azure NetApp Files (ANF) для общего хранилища с виртуальными машинами Azure.
8	Горизонтальное масштабирование с резервным узлом	Да	Виртуальные машины BW/4HANA c M128s, M416s, M416ms с использованием ANF только для хранилища.
9	Горизонтальное масштабирование без резервного узла	Да	Виртуальные машины BW/4HANA с M128s, M416s, M416ms (с использованием или без использования ANF для хранилища).
10	Горизонтальное масштабирование с реализацией аварийного восстановления посредством репликации хранилища	Нет	Замена репликации хранилища для нужд аварийного восстановления, реализуемого с помощью HSR или резервного копирования/восстановления.
11	Один узел с реализацией аварийного восстановления посредством репликации системы HANA (HSR)	Да	-
12	Один узел репликации системы HANA (HSR) в аварийное восстановление (с оптимизацией затрат)	Да	-
13	Высокая доступность и аварийное восстановление, реализуемые с помощью HSR	Да	-
14	Высокая доступность и аварийное восстановление, реализуемые с помощью HSR (с оптимизацией затрат)	Да	-
15	Реализация горизонтального масштабирования с аварийным восстановлением посредством репликации системы HANA (HSR)	Да	BW/4HANA с M128s. Виртуальные машины M416s, M416ms (с использованием или без использования ANF для хранилища).

Планирование источника (HLI)

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

Обслуживание SAP HANA

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

Разрешение сетевых подключений для новых виртуальных машин или виртуальной сети

В развертывании HLI сеть настраивается на основе сведений, описанных в статье Сетевая архитектура SAP HANA (крупные экземпляры). Кроме того, маршрутизация сетевого трафика выполняется так, как это описано в разделе Маршрутизация в Azure.

Новый целевой объект миграции на виртуальную машину размещен в существующей виртуальной сети с диапазоном IP-адресов, которому уже разрешено подключение к HLI? Тогда обновление подключения не требуется.
Новая виртуальная машина Azure размещена в новой виртуальной сети Microsoft Azure, возможно, в другом регионе, и связана с существующей виртуальной сетью? Тогда можно использовать ключ службы ExpressRoute и идентификатор ресурса из исходной подготовки HLI, чтобы разрешить доступ для этого нового диапазона IP-адресов виртуальной сети. Необходимо выполнить согласование с управлением службами Майкрософт, чтобы обеспечить для HLI подключение виртуальной сети.

Примечание

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

Существующая группа доступности уровня приложения, зоны доступности и группа размещения близкого взаимодействия (PPG)

Текущая модель развертывания реализуется для достижения определенных целей на уровне обслуживания. На этом этапе следует убедиться, что целевая инфраструктура будет соответствовать намеченным целям или превышать их.
Наиболее вероятно, что серверы приложений SAP помещаются в группу доступности. Если текущего уровня обслуживания для развертывания достаточно и в качестве имени узла целевой виртуальной машины предполагается использование логического имени HLI, то обновление функции разрешения адресов службы доменных имен (DNS), посредством которой определяется IP-адрес виртуальной машины, будет выполняться без обновления профилей SAP.

Если группа размещения близкого взаимодействия (PPG) не используется, нужно разместить все серверы приложений и баз данных в одной зоне, чтобы уменьшить задержку в сети.
Если вы используете PPG, см. раздел Группы доступности, зоны доступности и группы размещения близкого взаимодействия этой статьи.

Процесс прекращения репликации хранилища (если используется)

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

Факторы, которые следует учитывать при сохранении резервных копий данных

После перехода в SAP HANA на виртуальной машине Azure резервные копии данных и журналов, полученные на основе моментальных снимков в HLI, будет сложно восстановить на виртуальной машине. Мы рекомендуем делать резервные копии и моментальные снимки для HLI еще за несколько недель до перехода. Эти резервные копии копируются в учетную запись хранилища Azure, доступную для новой виртуальной машины SAP HANA. На начальных этапах перехода, прежде чем резервное копирование на основе Azure соберет достаточное количество журналов для удовлетворения требований к восстановлению на определенный момент времени, создавайте резервные копии на уровне файлов.

Создавать резервные копии содержимого HLI крайне важно. Имеет смысл создавать полные резервные копии в ландшафте SAP, которые будут доступны в случае необходимости отката.

Настройка мониторинга системы

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

Обращение к специалистам группы Microsoft Operations

Откройте запрос на обслуживание на портале Azure для существующего экземпляра HLI. После создания запроса о поддержке с вами свяжется по электронной почте инженер службы поддержки.

Обращение в службу технической поддержки учетных записей Майкрософт

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

Планирование назначения

Тщательное планирование необходимо при развертывании новой инфраструктуры вместо существующей. Убедитесь, что новое добавление будет удовлетворять вашим потребностям в целом. Необходимо учесть следующие основные моменты.

Доступность ресурсов в целевом регионе

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

Виртуальная сеть

Вы хотите запустить новую базу данных HANA в существующей виртуальной сети или нужно создавать новую? Решающим фактором для этого является текущая схема сети для ландшафта SAP. Кроме того, когда инфраструктура переносится из развертывания с одной зоной в развертывание с двумя зонами и при этом используется группа размещения близкого взаимодействия (PPG), в архитектуру приходится вносить соответствующие изменения. Дополнительные сведения см. в статье Реализация группы размещения близкого взаимодействия (PPG) Azure для обеспечения оптимальной сетевой задержки с помощью приложения SAP.

Безопасность

Независимо от того, работает новая виртуальная машина SAP HANA в новой или существующей виртуальной сети или подсети, она становится службой, критически важной для важного бизнеса. Ей нужна защита. Убедитесь, что контроль доступа соответствует политике безопасности вашей компании.

Хранение

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

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

Репликация хранилища для аварийного восстановления

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

Группы доступности, зоны доступности и группа размещения близкого взаимодействия

Вы можете сократить расстояние между уровнем приложения и SAP HANA, чтобы избежать задержки в сети. Поместите новую виртуальную машину базы данных и текущие серверы приложений SAP в PPG. Сведения о том, как нужно использовать группы доступности Azure и зоны доступности вместе с группой размещения близкого взаимодействия (PPG) для развертываний SAP, см. в статье Группа размещения близкого взаимодействия.

Если компоненты системы HANA развернуты в нескольких зонах Azure, вы должны иметь четкое представление о профилях задержки выбранных зон. Размещайте компоненты системы SAP, чтобы уменьшить расстояние между приложением SAP и базой данных. Бесплатно предоставляемое Средство тестирования задержки зоны доступности упрощает выполнение измерений.

Стратегия резервного копирования

Многие клиенты уже пользуются сторонними решениями по резервному копированию для SAP HANA на HLI. Если вы один из таких клиентов, то нужно настроить только защищенные виртуальные машины и базы данных HANA. Текущие задания HLI по резервному копированию можно исключить из расписания, если после миграции компьютер будет переведен в разряд резервных.

Azure Backup для SAP HANA на виртуальной машине является теперь общедоступной. Дополнительные сведения о резервном копировании SAP HANA на виртуальных машинах Azure см. в разделах Резервное копирование, Восстановление и Управление.

Стратегия аварийного восстановления

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

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

Изменение места назначения для подключения сервера приложений SAP

Миграция HSR приводит к появлению нового узла базы данных HANA и новому имени узла базы данных на уровне приложений. Укажите новое имя узла в профиле SAP. Если переключение выполняется с использованием службы разрешения имен, в которой имя узла сохраняется, то изменение профиля не требуется.

Операционная система (ОС)

Образы операционной системы, предназначенные для HLI и виртуальной машины, несмотря на одно и то же обозначение выпуска, например SLES 12 SP4, не являются идентичными. Проверьте необходимые пакеты, исправления, в том числе для ядра и системы безопасности, в HLI. Затем установите на целевом компьютере те же пакеты. HSR можно использовать для репликации из более старой ОС на виртуальную машину с более новой версией ОС. Проверить поддерживаемые версии можно, ознакомившись с Примечанием для SAP 2763388.

Запрос новой лицензии SAP

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

Отличия в соглашении об уровне обслуживания (SLA)

Необходимо отметить различие условий SLA относительно доступности для случаев использования HLI и виртуальной машины Azure. Например, кластерные пары высокой доступности для экземпляров HLI обеспечивают доступность на уровне 99,99 %. Для реализации того же соглашения об уровне обслуживания необходимо развертывать виртуальные машины в зонах доступности. Соглашение об уровне обслуживания для виртуальных машин описывает доступность для различных конфигураций виртуальных машин, чтобы клиенты могли спланировать целевую инфраструктуру.

Стратегия миграции

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

Виртуальная машина с дисками класса Premium или Ultra для данных

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

Виртуальная машина с ANF для томов с данными и журналами

На высоком уровне последние моментальные снимки хранилища HLI для всех томов с данными и журналами должны копироваться в службу хранилища Azure. Там они будут доступны и смогут восстанавливаться целевой виртуальной машиной HANA. Процесс копирования может выполняться с помощью любых встроенных инструментов ОС Linux, предназначенных для копирования.

Важно!

Копирование и перенос данных может занять несколько часов, в зависимости от размера базы данных HANA и пропускной способности сети. Основная часть процесса копирования должна выполняться заранее, до периода простоя первичной базы данных HANA.

Преобразование МКОС в MDC

Некоторые клиенты, применяющие решение HLI, используют модель развертывания по принципу "несколько компонентов в одной системе" (MCOS). Этот вариант предназначен для обхода ограничений на моментальные снимки в хранилище контейнеров нескольких баз данных (MDC) в более ранних версиях SAP HANA. В модели MCOS несколько независимых экземпляров SAP HANA помещаются в одну колонку HLI. Использование HSR для миграции будет работать нормально, но при этом у нескольких виртуальных машин HANA будет одна клиентская база данных. Такая модель содержит больше компонентов, чем хотелось бы. Развертывание по умолчанию для SAP HANA 2.0 — MDC. Альтернативное решение — переместить клиента HANA после миграции HSR. Перемещение клиента HANA объединяет эти независимые базы данных HANA в клиенты в одном контейнере HANA.

Важные аспекты уровня приложения

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

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

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

Приемочный тест

Миграция с HLI на виртуальную машину не приводит к существенным изменениям содержимого базы данных в отличие от разнородной миграции. Однако по-прежнему рекомендуется проверять производительность новой установки.

План прямой миграции

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

Действия после перемещения

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

Списание HLI

После успешной миграции базы данных HANA на виртуальную машину Azure убедитесь, что в базе данных HLI не выполняются никакие бизнес-транзакции. Тем не менее, если HLI выполняется в течение срока своего локального периода хранения резервных копий, это позволит ускорить восстановление. Если срок хранения локальных резервных копий истек, следует списать крупный экземпляр HANA. Прекратите соблюдение своих контрактных обязательств по договору на HLI, заключенному с Майкрософт, обратившись к представителям Майкрософт.

Удаление всех прокси-серверов (например, Iptables, BIGIP), настроенных для HLI

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

Удаление службы Global Reach для HLI

Служба Global Reach используется для подключения шлюза ExpressRoute клиентов к шлюзу ExpressRoute в HLI. Эта служба позволяет направлять локальный трафик клиентов напрямую к клиенту HLI без использования прокси-службы. После миграции такое подключение становится ненужным из-за отсутствия единицы HLI. Как и в случае с прокси-службой IPTables, службу GlobalReach также следует сохранить до тех пор, пока HLI не будет полностью списан.

Подписка для операционной системы — перемещение и повторное использование

Когда серверы виртуальных машин будут развернуты, а HLI — списаны, подписки ОС можно заменить или использовать повторно. Нет необходимости платить двойную цену за лицензии ОС.

Следующие шаги

Планирование развертывания SAP.

Контрольный список для планирования и развертывания рабочих нагрузок SAP в Azure

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