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

SAP HANA в серии Large Instances на Azure — это выделенная физическая (bare-metal) инфраструктурная служба, которая выполняет рабочие нагрузки SAP HANA за пределами виртуальных машин Azure. Так как служба HLI отменяется, необходимо перенести рабочие нагрузки SAP HANA на виртуальные машины Azure, чтобы поддерживать поддержку и использовать более широкую экосистему Azure.

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

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

В этой статье приводятся следующие предположения:

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

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

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

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

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

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

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

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

В вашем развертывании HLI сеть была настроена на основе исходной сетевой архитектуры больших экземпляров SAP HANA. См. раздел вывод из эксплуатации SAP HANA Large Instance для получения информации о текущем состоянии HLI и руководстве по миграции.

• Располагается ли новый объект миграции виртуальной машины в существующей виртуальной сети с диапазонами IP-адресов, которые уже разрешены для подключения к HLI? Затем вам не нужны дополнительные обновления подключения.

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

  Замечание

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

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

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

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

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

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

Рекомендации по сохранению резервных копий данных

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

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

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

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

Участие команды Microsoft Operations

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

Взаимодействие с командой аккаунтов Microsoft

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

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

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

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

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

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

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

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

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

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

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

Хранение

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

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

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

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

Группы доступности, зоны доступности и PPG

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

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

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

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

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

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

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

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

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

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

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

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

Новый запрос на лицензию SAP

Запросите новую лицензию SAP для новой системы HANA после миграции на виртуальные машины.

Различия в уровне обслуживания

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

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

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

Виртуальная машина с дисками категории "Премиум" или "Ультра" для данных

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

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

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

Преобразование MCOS в MDC

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

Учет уровня приложений

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

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

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

Приемосдаточные испытания

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

План переключения

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

После миграции

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

Отмена эксплуатации HLI

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

Удаление любого прокси-сервера, настроенного для HLI

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

Исключение глобального охвата для HLI

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

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

При развертывании виртуальных серверов и списании HLI можно заменить или повторно использовать подписки ОС. Вам не нужно платить двойную оплату за лицензии ОС.

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

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