Контрольный список для планирования и развертывания рабочих нагрузок SAP в Azure
Статья
Этот список проверка предназначен для клиентов, перемещающих приложения SAP в инфраструктуру Azure в качестве службы. Приложения SAP в этом документе представляют продукты SAP под управлением ядра SAP, включая SAP NetWeaver, S/4HANA, BW и BW/4 и другие. В течение всего проекта клиент и (или) партнер SAP должны ознакомиться с контрольным списком. Важно отметить, что многие проверки завершаются в начале проекта и на этапе планирования. После завершения развертывания простые изменения в развернутой инфраструктуре Azure или выпусках программного обеспечения SAP могут стать сложными.
Сверяйтесь с контрольным списком после завершения ключевых этапов проекта. Это позволит выявить небольшие проблемы, прежде чем они станут большими проблемами. У вас также будет достаточно времени для повторного конструирования и тестирования любых необходимых изменений. Не рассматривайте этот контрольный список как завершенный. В зависимости от ситуации может потребоваться выполнить дополнительные проверка.
Контрольный список не включает задачи, которые не зависят от Azure. Например, интерфейсы приложений SAP изменяются во время перемещения на платформу Azure или поставщик услуг размещения. Документация ПО SAP и заметки о поддержке также содержат дополнительные задачи, которые не относятся к Azure, но должны быть частью общего списка проверка планирования.
Этот контрольный список можно также использовать для уже развернутых систем. Новые функции или измененные рекомендации могут применяться к вашей среде. Рекомендуется периодически просматривать список проверка, чтобы убедиться, что вы знаете о новых функциях на платформе Azure.
Основное содержимое в этом документе организовано на вкладках в хронологическом порядке типичного проекта. Просмотрите содержимое каждой вкладки и рассмотрим каждую следующую вкладку, чтобы создать на основе действий, выполненных и обучения, полученных на предыдущем этапе. Для миграции рабочей среды следует учитывать содержимое всех вкладок, а не только рабочую вкладку. Чтобы помочь сопоставить типичные этапы проекта с определением этапа, используемым в этой статье, ознакомьтесь со следующей таблицей.
Этапы развертывания проверка списков
Примеры этапов или вех проекта
Этап подготовки и планирования
Этап запуска проекта / этап разработки и определения
Этап пилотного запуска
Ранняя проверка/ подтверждение концепции / пилотного проекта
Этап запуска непроизводственных систем.
Завершение подробного проектирования / сборки непроизводственных сред / этап тестирования
На этом этапе вы планируете перенос рабочей нагрузки SAP на платформу Azure. Документы, такие как руководство по планированию SAP в Azure и Cloud Adoption Framework для SAP, охватывают множество тем и справку в качестве сведений о подготовке. Как минимум, на этом этапе необходимо создать следующие документы, определить и обсудить следующие элементы миграции:
Высокоуровневый документ проектирования
Этот документ должен содержать следующее.
Текущий список компонентов и приложений SAP, а также список целевых приложений в Azure.
Матрица назначения ответственности (RACI), которая определяет обязанности и назначения заинтересованных сторон. Начните на высоком уровне и переходите на более детальные уровни во время планирования и первого развертывания.
Общая архитектура решения. Следует ознакомиться с рекомендациями и примерами архитектур из Центра архитектуры Azure.
Сетевая архитектура для подключения из локальной среды к Azure. Начните ознакомиться с концепцией целевой зоны корпоративного масштабирования Azure.
Принципы безопасности критически важных для бизнеса данных в Azure. Чтобы узнать о безопасности данных, начните с документации по безопасности Azure.
стратегия служба хранилища для покрытия блочных устройств (управляемых дисков) и общих файловых систем (таких как Файлы Azure или Azure NetApp Files), которые следует дополнительно уточнить в размерах файловой системы и макетах в техническом документе проектирования.
Технический документ по проектированию
Этот документ должен содержать следующее.
Блок-схема решения, на которой показаны приложения и службы SAP, отличные от SAP
Проект SAP Quicksizer на основе томов бизнес-документов. Затем выходные данные quicksizer сопоставляются с вычислительными, хранилищами и сетевыми компонентами в Azure. Кроме того, в SAP Quicksizer старательное изменение размера на основе текущей рабочей нагрузки исходных систем SAP. Учитывая доступные сведения, такие как отчеты о рабочей нагрузке СУБД, отчеты SAP EarlyWatch, показатели производительности вычислений и хранилища.
Архитектура непрерывности бизнес-процессов и аварийного восстановления.
Подробные сведения о версиях пакета поддержки ОС, базы данных, ядра и SAP. Необязательно, чтобы каждый выпуск ОС, поддерживаемый SAP NetWeaver или S/4HANA, поддерживался на виртуальных машинах Azure. Это касается и выпусков СУБД. Проверьте следующие источники, чтобы выровнять и при необходимости обновить выпуски SAP, выпуски СУБД и ОС, чтобы обеспечить sap и поддержка Azure. Для получения полной поддержки от SAP и корпорации Майкрософт необходимо иметь сочетания версий, поддерживаемые SAP и Azure. При необходимости необходимо запланировать обновление некоторых программных компонентов. Дополнительные сведения о поддерживаемом программном обеспечении SAP, ОС и СУБД описаны здесь:
Заметка SAP 2039619. В этом примечании приведена матрица поддержки Oracle в Azure. Oracle поддерживает только Windows и Oracle Linux как гостевые операционные системы в рабочих нагрузках Azure для SAP. Эта инструкция поддержки также применяется к уровню приложений SAP, на котором выполняются экземпляры SAP, если они содержат Oracle Client.
Виртуальные машины Azure, поддерживаемые SAP HANA, перечислены на веб-сайте SAP. Сведения о каждой записи содержат конкретные требования и требования, включая поддерживаемую версию ОС. Это может не совпадать с последней версией ОС в соответствии с 2235581 заметок SAP.
Рекомендации по развертыванию СУБД Azure Виртуальные машины для рабочих нагрузок SAP и связанных документов. В Azure использование конфигурации общего диска для уровня СУБД, например описанного для SQL Server, не поддерживается. Вместо этого используйте такие решения, как:
Чтобы выполнить аварийное восстановление в регионах Azure, просмотрите решения, предлагаемые различными поставщиками СУБД. Большинство из них поддерживает асинхронную репликацию или доставку журналов.
Для прикладного уровня SAP определите, будут ли использоваться системы регрессионного тестирования для бизнеса. В идеальном случае это реплики рабочих развертываний, размещенные в том же регионе Azure или в вашем регионе аварийного восстановления. Во втором случае вы можете ориентироваться на систему бизнес-регрессии в качестве цели аварийного восстановления для рабочих развертываний.
Ознакомьтесь с Azure Site Recovery в качестве метода реплика реплика уровня приложений SAP в регионе аварийного восстановления Azure. Дополнительные сведения см. в статье о настройке аварийного восстановления для развертывания многоуровневого приложения SAP NetWeaver.
Для проектов, необходимых для сохранения в одном регионе по соображениям соответствия требованиям, рассмотрите объединенную конфигурацию HADR с помощью Azure Зоны доступности.
Инвентаризация всех интерфейсов SAP и подключенных систем (SAP и не SAP).
Проектирование базовых служб. Этот дизайн должен включать следующие элементы, многие из которых охватываются акселератором целевой зоны для SAP:
Топология сети в Azure и назначение различных сред SAP
Архитектура Active Directory и DNS.
Решение для управления удостоверениями для конечных пользователей и администрирования
Операции безопасности для ресурсов и рабочих нагрузок Azure в пределах
Концепция безопасности для защиты рабочей нагрузки SAP. Это должно включать все аспекты — мониторинг сети и периметра, безопасность приложений и баз данных, защита операционных систем и все необходимые меры инфраструктуры, такие как шифрование. Определите требования в командах по соответствию требованиям и безопасности.
Корпорация Майкрософт рекомендует либо профессиональный прямой, премьер-министр или Единая поддержка контракт. Определите пути эскалации и контакты для поддержки корпорации Майкрософт. Требования к поддержке SAP см . в 2015553 заметки SAP.
План сокращения данных и переноса данных для переноса данных SAP в Azure. Для систем SAP NetWeaver компания SAP разработала рекомендации по ограничению больших объемов данных. См. это подробное руководство SAP по управлению данными в системах SAP ERP. Некоторые материалы также относятся к системам NetWeaver и S/4HANA в целом.
Автоматический подход к развертыванию. Многие клиенты начинают с сценариев, используя сочетание PowerShell, CLI, Ansible и Terraform.
Разработанные корпорацией Майкрософт решения для автоматизации развертывания SAP:
Центр Azure для решений SAP — служба Azure для развертывания и эксплуатации инфраструктуры системы SAP
SAP в службе автоматизации развертывания Azure— средство оркестрации с открытым исходным кодом для развертывания и обслуживания сред SAP
Примечание.
Определите частоту регулярных проверок проекта и развертывания с участием вас как клиента, системного интегратора, корпорации Майкрософт и других участвующих сторон.
Этап пилотного развертывания (настоятельно рекомендуется)
Пилотный проект можно запустить до или во время планирования и подготовки проекта. Вы также можете использовать этап пилотного развертывания, чтобы протестировать подходы и разработки, сделанные на этапе планирования и подготовки. Вы также можете развернуть этап пилотного развертывания, чтобы сделать его реальной проверкой концепции.
Рекомендуется настроить и проверить полное решение HADR и структуру безопасности во время пилотного развертывания. На этом этапе некоторые клиенты выполняют тесты масштабируемости. Другие клиенты используют развертывание систем "песочницы SAP" в качестве пилотного этапа. Предположим, вы уже определили систему, которую хотите перенести в Azure для пилотного развертывания.
Оптимизируйте передачу данных в Azure. Оптимальный вариант сильно зависит от конкретного сценария. Если для реплика базы данных требуется частное подключение, Azure ExpressRoute быстрее, если канал ExpressRoute имеет достаточную пропускную способность. В любом другом сценарии передача через Интернет быстрее. При необходимости используйте выделенную VPN-службу миграции для частного подключения к Azure. Любой сетевой путь миграции во время пилотного проекта должен зеркало использовать для будущих рабочих систем, устраняя любые последствия рабочих нагрузок — SAP или не SAP , уже работающих в Azure.
Для разнородной миграции SAP, которая включает экспорт и импорт данных, тестирование и оптимизацию этапов экспорта и импорта. Для миграции больших сред SAP ознакомьтесь с доступными рекомендациями. Используйте соответствующее средство для сценария миграции в зависимости от исходных и целевых выпусков SAP, СУБД и при объединении миграции с другими задачами, такими как обновление выпуска или даже преобразование Юникода или S/4HANA. SAP предоставляет монитор миграции или SWPM, SAP DMO или DMO с перемещением системы, помимо других подходов к минимизации простоя, доступных как отдельная служба от SAP. В последних выпусках SAP DMO с системным перемещением использование azcopy для передачи данных через Интернет также поддерживается, обеспечивая самый быстрый сетевой путь в собственном коде.
Перенос очень больших баз данных (VLDB) в Azure для SAP
Техническая проверка
Типы вычислений и виртуальных машин
Изучите ресурсы в заметках о поддержке SAP, в каталоге SAP HANA оборудования и в SAP PAM снова. Не забудьте соответствовать поддерживаемым виртуальным машинам Для Azure, поддерживаемым выпускам ОС для этих типов виртуальных машин и поддерживаемым выпускам SAP и СУБД.
Повторно проверьте размер приложения и инфраструктуры, развертываемой в Azure. Если вы перемещаете существующие приложения, вы часто можете получить необходимые SAPS из используемой инфраструктуры и веб-страницу теста SAP и сравнить их с номерами SAP, перечисленными в заметке SAP 1928533. Кроме того, сохраним эту статью с учетом ОЦЕНОК SAPS.
Оцените и проверьте размер виртуальных машин Azure для максимальной пропускной способности хранилища и сети типов виртуальных машин, выбранных на этапе планирования. Подробные сведения о ограничениях производительности виртуальной машины доступны для хранения, важно учитывать ограничение максимальной пропускной способности диска без кэширования для изменения размера. Тщательно рассмотрите возможность изменения размера и временных эффектов ускорения уровня диска и виртуальной машины.
Проверьте и определите, нужно ли создавать собственные образы ОС для виртуальных машин в Azure или использовать образ из коллекции вычислений Azure (прежнее название — общая коллекция образов). Если вы используете образ из коллекции вычислений Azure, обязательно используйте образ, который отражает контракт на поддержку с поставщиком ОС. Для некоторых поставщиков ОС Коллекция вычислений Azure позволяет вам использовать собственные образы лицензий. Для других образов ОС поддержка предоставляется в виде цены, заключенной в Azure.
Использование собственных образов ОС позволяет хранить необходимые корпоративные зависимости, такие как агенты безопасности, защита и настройки непосредственно в образе. Таким образом они развертываются немедленно с каждой виртуальной машиной. Если вы решите создать собственные образы ОС, вы можете найти документацию в следующих статьях:
Если вы используете образы Linux из коллекции вычислений Azure и добавляете усиление защиты в рамках конвейера развертывания, необходимо использовать образы, подходящие для SAP, предоставляемые поставщиками Linux.
Выбор образа ОС определяет тип создания виртуальной машины Azure. поддержка Azure оба Виртуальные машины Hyper-V поколения 1 и 2. Некоторые семейства виртуальных машин доступны только в качестве поколения 2, некоторые семейства виртуальных машин сертифицированы только для использования SAP в качестве поколения 2 (заметка SAP 1928533), даже если Azure разрешает оба поколения. Рекомендуется использовать виртуальную машину поколения 2 для каждой виртуальной машины ландшафта SAP.
Хранилище
Чтение типов хранилища Azure для рабочей нагрузки SAP
Как минимум, используйте хранилище SSD Azure уровня "Стандартный" для виртуальных машин, представляющих уровни приложений SAP, и для развертывания СУБД, которые не учитывает производительность. Помните, что разные типы хранилища Azure влияют на соглашение об уровне обслуживания доступности одной виртуальной машины.
Как правило, мы не рекомендуем использовать стандартные диски HDD Azure для SAP.
Для различных типов СУБД проверка универсальную документацию по СУБД, связанную с SAP, и документацию по СУБД, на которую указывает первый документ. Используйте чередование дисков по нескольким дискам с хранилищем класса Premium (версии 1 или 2) для данных базы данных и области журнала. Убедитесь, что полоса дисков lvm активна и с правильным размером полосы с помощью команды "lvs -a -a+lv_layout,lv_role,полосы,stripe_size,устройства" в Linux, см. свойства дисковых пространств в Windows.
Используйте LVM для всех дисков на виртуальных машинах Linux, так как это упрощает управление и расширение в сети. К ним относятся тома на отдельных дисках, например /usr/sap.
Сеть
Протестируйте и оцените инфраструктуру виртуальной сети и распределение приложений SAP в различных виртуальных сетях Azure.
Оцените подход к архитектуре виртуальной сети концентратора и виртуальной глобальной сети с дискретными периферийными виртуальными сетями для рабочей нагрузки SAP. Для уменьшения масштаба подход к микросементации в одной виртуальной сети Azure. На основе этой оценки используется следующее:
Преимущества быстрого отключения пиринга между виртуальными сетями Azure, а не изменение группы безопасности сети для изоляции подсети в виртуальной сети. Эта оценка предназначена для случаев, когда приложения или виртуальные машины, размещенные в подсети виртуальной сети, стали угрозой безопасности.
Централизованное ведение журнала и аудит сетевого трафика между локальной средой, внешним миром и виртуальным центром обработки данных, создаваемым в Azure.
Оцените и протестируйте обмен данными между прикладным уровнем SAP и уровнем СУБД SAP.
Размещение виртуальных (модуль) сети Azure в пути связи между приложением SAP и уровнем СУБД систем SAP, работающих с ядром SAP, не поддерживается.
Размещение уровня приложений SAP и СУБД SAP в разных виртуальных сетях Azure, не являющихся равноправными, не поддерживаются.
Проверьте и оцените задержку сети между виртуальными машинами уровня приложений SAP и виртуальными машинами СУБД в соответствии с заметками SAP 500235 и 1100926. Помимо niping SAP, вы можете использовать такие инструменты, как sockperf или ethr для измерения задержки tcp. Оцените результаты по рекомендациям по задержке в сети в заметке SAP 1100926. Задержка сети должна быть в среднем или отличном диапазоне.
Оптимизация пропускной способности сети на виртуальных машинах с высоким уровнем виртуальных ЦП, обычно используемых для серверов баз данных. Особенно важно для горизонтального масштабирования HANA и любой крупной системы SAP. Следуйте рекомендациям в этой статье для оптимизации.
Для оптимальной задержки сети рекомендуется следовать инструкциям в сценариях размещения близкого взаимодействия статьи. Нет использования групп размещения близкого взаимодействия для зональных или межзональных шаблонов развертывания.
Проверьте правильную доступность, маршрутизацию и безопасный доступ из ландшафта SAP к любой необходимой конечной точке Интернета, например репозитории исправлений ОС, средства развертывания или конечную точку службы. Аналогичным образом, если среда SAP предоставляет общедоступную службу, например SAP Fiori или SAProuter, убедитесь, что она доступна и защищена.
Развертывания высокого уровня доступности и аварийного восстановления
Всегда используйте стандартную подсистему балансировки нагрузки для кластеризованных сред. Базовая подсистема балансировки нагрузки будет прекращена.
Выберите подходящие варианты развертывания в зависимости от предпочитаемой конфигурации системы в регионе Azure, будь то охват между зонами, размещение в одной зоне или работа в регионе без зоны.
В региональном развертывании для защиты центральных служб SAP и уровней СУБД для обеспечения высокой доступности с помощью пассивного реплика tion поместите два узла для SAP Central Services в одну отдельную группу доступности и два узла СУБД в другой группе доступности. Не смешивайте роли виртуальной машины приложения в группе доступности.
Для межзонального развертывания настройте систему с помощью гибкого масштабируемого набора с FD=1 и разверните узлы активных и пассивных центральных служб и уровень СУБД в двух разных зонах доступности. Используйте две зоны доступности с наименьшей задержкой между ними.
Для межзонального развертывания рекомендуется использовать гибкий масштабируемый набор с FD=1 по стандартному развертыванию зоны доступности.
Если вы используете Azure Load Balancer вместе с гостевыми операционными системами Linux, убедитесь, что параметр сети Linux net.IPv4.tcp_timestamps имеет значение 0. Эта рекомендация конфликтует с рекомендациями в более ранних версиях заметки SAP 2382421. Примечание SAP теперь обновляется, чтобы указать, что этот параметр должен быть установлен в значение 0 для работы с подсистемами балансировки нагрузки Azure.
Параметры времени ожидания
Проверьте трассировку экземпляров SAP для разработчиков SAP NetWeaver и убедитесь в отсутствии разрывов соединения между сервером очереди и рабочими процессами SAP. Эти разрывы подключений можно избежать, задав следующие два параметра реестра:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. Дополнительные сведения см. в статье KeepAliveTime.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. Дополнительные сведения см. в статье KeepAliveInterval.
Чтобы избежать тайм-аутов графического интерфейса SAP между локальными интерфейсами ГРАФИЧЕСКОго интерфейса SAP и уровнями приложений SAP, развернутыми в Azure, проверка, заданы ли эти параметры в профиле экземпляра по умолчанию.pfl или профилем экземпляра:
rdisp/keepalive_timeout = 3600
rdisp/keepalive = 20
Чтобы предотвратить нарушение установленных соединений между процессом очереди SAP и рабочими процессами SAP, необходимо задать для параметра enque/encni/set_so_keepalive значение true. См. также заметку SAP 2743751.
При использовании конфигурации отказоустойчивого кластера Windows убедитесь, что правильно настроено время реагирования на не отвечающие узлы для Azure. В разделе пороговые значения сети отказоустойчивого кластера настройки перечислены параметры и их влияние на включая учет отработки отказа. Если узлы кластера находятся в одной подсети, необходимо изменить следующие параметры:
SameSubNetDelay = 2000 (число миллисекунд между пульсом)
SameSubNetThreshold = 15 (максимальное число последовательных пропущенных пульсов)
Тестирование процедур высокого уровня доступности и аварийного восстановления
Имитация ситуаций отработки отказа с помощью такого средства, как NotMyFault (Windows) или размещение операционных систем в режиме паники или отключение сетевого интерфейса с помощью ifdown (Linux). Этот шаг поможет определить, работает ли конфигурация отработки отказа в разработке.
Измеряет время, затрачиваемое на выполнение отработки отказа. Если время слишком велико, рассмотрите следующие моменты.
Для SUSE Linux: используйте устройства SBD вместо агента ограждения Azure, чтобы ускорить отработку отказа.
Для SAP HANA: если повторная загрузка данных занимает слишком много времени, рекомендуется подготовить больше пропускной способности хранилища.
Протестируйте последовательность резервного копирования, восстановления и времени и при необходимости внесите исправления. Требуется протестировать не только выполнение резервного копирования. Кроме того, необходимо протестировать действия восстановления и времени восстановления. Убедитесь, что время восстановления находится в пределах Соглашений об уровне обслуживания в отношении RTO, где RTO зависит от процесса восстановления базы данных или виртуальной машины.
Проверьте функциональные возможности и архитектуру аварийного восстановления между регионами, убедитесь, что RPO и RTO соответствуют вашим ожиданиям.
Проверка безопасности
Проверьте правильность архитектуры управления доступом на основе ролей Azure (Azure RBAC). Разделение обязанностей требует разделения и ограничения доступа и разрешений разных команд. Например, участники группы SAP Basis должны иметь возможность развертывать виртуальные машины и назначать диски из служба хранилища Azure в определенную виртуальную машину Azure. Однако эта команда не должна иметь возможность создавать собственные виртуальные сети или изменять параметры существующих виртуальных сетей. Участники команды специалистов по сетям не должны иметь возможность развертывать виртуальные машины в виртуальных сетях, где работают виртуальные машины СУБД и приложений SAP. И члены этой группы не должны иметь возможность изменять атрибуты виртуальных машин или даже удалять виртуальные машины или диски.
Убедитесь, что шифруются все ресурсы, которые требуется зашифровать. Определите и реализуйте процессы для резервного копирования сертификатов, хранения и доступа к этим сертификатам и восстановления зашифрованных сущностей.
Для шифрования хранилища шифрование на стороне сервера с управляемым ключом платформы (SSE-PMK) включается для каждой службы хранилища, используемой для SAP в Azure по умолчанию, включая управляемые диски, Файлы Azure и Azure NetApp Files. Управление ключами с помощью ключей, управляемых клиентом, можно рассмотреть, если требуется для смены ключей, принадлежащих клиенту.
Шифрование на стороне узла не должно быть включено по соображениям производительности виртуальных машин Linux серии M.
Не используйте Шифрование дисков Azure в Linux с SAP в качестве образов ОС "для SAP" не поддерживаются.
Собственное шифрование базы данных развертывается большинством клиентов SAP в Azure для защиты данных и резервных копий СУБД. прозрачное шифрование данных (TDE) обычно не имеет заметных затрат на производительность, значительно повышает безопасность и следует учитывать. Управление ключами шифрования и расположение должны быть защищены. Шифрование базы данных происходит внутри виртуальной машины и не зависит от любого шифрования хранилища, например SSE.
Тестирование производительности в SAP на основе трассировки и измерений SAP выполните следующие сравнения:
Инвентаризация и базовый план текущей локальной системы.
Отчеты SAR / перфмон.
STAT trace top 10 online reports.
Сбор журнала пакетных заданий.
Тестирование фокуса для проверки производительности бизнес-процессов. Не сравнивайте ключевые показатели эффективности оборудования изначально и в вакууме только при устранении неполадок с различиями производительности.
При необходимости сравните первые 10 интерактивных отчетов с текущей реализацией.
При необходимости сравните 10 основных заданий в текущей реализации.
Сравнение передачи данных через интерфейсы в систему SAP. Сосредоточьтесь на интерфейсах, о которых известно, что они участвуют в передаче данных между разными расположениями, например из локальной среды в Azure.
Этап запуска непроизводственных систем.
На этом этапе мы предполагаем, что после успешного пилотного развертывания или подтверждения концепции (POC) вы начинаете развертывать непроизводственные системы SAP в Azure. Включите все, что вы узнали и с чем ознакомились во время подтверждения концепции для этого развертывания. Все критерии и шаги, перечисленные для POC, применяются и к этому развертыванию.
На этом этапе обычно развертываются системы разработки, системы модульного тестирования и системы регрессионного тестирования бизнес-приложений в Azure. Рекомендуется, чтобы по крайней мере одна непроизводственная система в одной строке приложения SAP имела полную конфигурацию высокой доступности, которая будет присутствовать в будущей производственной системе. Ниже приведены некоторые задачи, которые необходимо выполнить на этом этапе:
Прежде чем перемещать системы из старой платформы в Azure, собирайте данные о потреблении ресурсов, такие как загрузка ЦП, пропускная способность хранилища и данные операций ввода-вывода. Особенно соберите данные из элементов уровня СУБД, а также из элементов прикладного уровня. Кроме того, измерьте задержки сети и хранилища. Адаптируйте размер и дизайн с помощью захваченных данных. Такие средства, как syststat, KSAR, nmon и nmon анализатор для Excel, должны использоваться для записи и представления использования ресурсов в пиковые периоды.
Запишите схемы времени доступности систем. Цель — понять, должны ли непроизводственные системы быть доступны весь день, каждый день или работу некоторых из них можно завершать в определенные периоды недели или месяца.
Повторно оцените выбор образа ОС, поколение виртуальных машин (поколение 2 в ландшафте SAP) и стратегию исправления ОС.
Обязательно выполните требования поддержки SAP для соглашений в службу поддержки Майкрософт. См. заметку SAP 2015553.
Ознакомьтесь с заметками SAP, связанными с Azure, например 1928533, для новых номеров SKU виртуальных машин и новых поддерживаемых выпусков ОС и СУБД. Сравнивайте затраты на новые типы виртуальных машин с более старыми виртуальными машинами. Это позволит развертывать виртуальные машины с лучшим соотношением цены и производительности.
Проверьте примечания поддержки SAP, каталог SAP HANA оборудования и SAP PAM. Убедитесь в отсутствии изменений в поддерживаемых виртуальных машинах для Azure, поддерживаемых выпусках ОС на этих виртуальных машинах и поддерживаемых выпусках SAP и DBMS.
На веб-сайте SAP просмотрите новые сертифицированные для Hana номера SKU в Azure. Сравните цены новых номеров SKU с теми, которые вы планируете использовать. В конечном итоге внесите необходимые изменения, чтобы использовать те из них, которые имеют лучшее соотношение цены и производительности.
Адаптируйте автоматизацию развертывания, чтобы использовать новые типы виртуальных машин и включить новые функции Azure, которые вы хотите использовать.
После развертывания инфраструктуры проверьте и оцените задержку сети между виртуальными машинами уровня приложений SAP и виртуальными машинами СУБД, в соответствии с заметками SAP 500235. Оцените результаты по рекомендациям по задержке в сети в заметке SAP 1100926. Задержка сети должна быть в среднем или отличном диапазоне. Помимо использования таких средств, как niping, sockperf или ethr, используйте средство SAP HCMT для измерения сети между виртуальными машинами HANA для горизонтального масштабирования или системного реплика tion.
Если между виртуальными машинами наблюдается более высокая задержка, рассмотрите рекомендации в сценариях размещения близкого взаимодействия статьи.
Перед применением рабочей нагрузки выполните все остальные проверка, перечисленные на этапе проверки концепции.
По мере применения рабочей нагрузки запишите потребление систем в Azure. Сравните это потребление с записями со старой платформы. Настройте размер виртуальных машин для использования в будущих развертываниях, если вы предвидите большие различия. Помните, что при снижении размера, хранении и пропускной способности сети виртуальных машин также будет снижена.
Поэкспериментируйте с функциональностью и процессами копирования системы. Цель — упростить процесс копирования системы разработки или тестирования таким образом, чтобы команды проектов могли быстро получать новые системы.
Оптимизируйте и повышайте эффективность доступа на основе ролей, разрешений и процессов группы в Azure, чтобы обеспечить разделение обязанностей. В то же время убедитесь, что все команды могут выполнять свои задачи в инфраструктуре Azure.
Испытайте, протестируйте и задокументируйте процедуры обеспечения высокой доступности и аварийного восстановления, чтобы ваш персонал мог выполнять эти задачи. Определите недостатки новых функциональных возможностей Azure, которые нужно интегрировать в развертывания, и адаптируйте эти возможности.
Этап подготовки рабочих систем.
На этом этапе собирайте то, что вы сталкивали и узнали при развертывании в нерабочее время, и примените его к будущим рабочим развертываниям.
Перед переходом в Azure выполните все необходимые обновления выпуска SAP для рабочих систем.
Договоритесь с владельцами предприятий о проведении функциональных тестов и бизнес-тестов, которые нужно будет выполнить после переноса рабочей системы.
Убедитесь, что все эти тесты выполняются в исходных системах в текущем расположении размещения. Не выполняйте тесты в первый раз после перемещения системы в Azure.
Протестируйте процесс миграции рабочих систем в Azure. В случае если вы не переносите все рабочие системы в Azure в течение одного интервала времени, составьте группы рабочих систем, которые должны находиться в одном расположении размещения. Тестирование миграции данных, включая подключенные приложения и интерфейсы, отличные от SAP.
Ниже приведены некоторые распространенные методы.
Используйте методы СУБД, такие как резервное копирование и восстановление в сочетании с SQL Server AlwaysOn, репликацией системы HANA или доставкой журналов для начального и синхронизированного содержимого базы данных в Azure.
Используйте резервное копирование и восстановление для небольших баз данных.
Если требуется перемещение резервных копий или файлов экспорта SAP, проверьте, что обеспечивает лучшую пропускную способность: Интернет или канал ExpressRoute. При перемещении данных через Интернет может потребоваться изменить некоторые правила группы безопасности сети или группы безопасности приложений, которые понадобятся для будущих рабочих систем.
Прежде чем перемещать системы из старой платформы в Azure, собирайте данные о потреблении ресурсов. Полезные данные включают использование ЦП, пропускную способность хранилища и данные операций ввода-вывода. Особенно соберите данные из элементов уровня СУБД, а также из элементов прикладного уровня. Кроме того, измерьте задержки сети и хранилища.
Повторно проверка заметки SAP и необходимые параметры ОС, каталог оборудования SAP HANA и SAP PAM. Убедитесь в отсутствии изменений в поддерживаемых виртуальных машинах для Azure, поддерживаемых выпусках ОС на этих виртуальных машинах и поддерживаемых выпусках SAP и DBMS.
Обновите автоматизацию развертывания, чтобы рассмотреть последние решения, принятые в типах виртуальных машин и функциональных возможностях Azure.
Создайте сборник схем для реагирования на запланированные события обслуживания Azure. Определите порядок, в котором системы и виртуальные машины должны перезагружаться для планового обслуживания.
Упражнение, тестирование и документирование процедур высокого уровня доступности и аварийного восстановления, чтобы сотрудники могли выполнять эти задачи во время миграции и сразу после принятия решения о переходе в режиме реального времени.
Этап запуска
На этапе Go-Live обязательно следуйте сборникам схем, разработанным на предыдущих этапах. Выполните шаги, которые вы протестировали и изучили. Не принимайте изменения, вносимые в конфигурации и процессы в последнюю минуту. Также выполните следующие действия.
Убедитесь, что мониторинг на портале Azure и другие инструменты мониторинга работают. Используйте такие средства Azure, как Azure Monitor для мониторинга инфраструктуры. Azure Monitor для SAP для сочетания ключевых показателей эффективности ос и приложений, что позволяет интегрировать все на одной панели мониторинга для видимости во время и после перехода в режиме реального времени.
Для ключевых показателей производительности операционной системы:
В Linux убедитесь, что средство sysstat установлено и записывает сведения через регулярные интервалы
После переноса данных необходимо выполнить все проверочные тесты, которые согласованы с владельцами предприятий. Принимайте только результаты проверочных тестов, для которых у вас есть результаты исходных систем.
Проверьте, функционируют ли интерфейсы и могут ли другие приложения взаимодействовать с развернутыми рабочими системами.
Проверьте систему передачи и исправления SAP с помощью транзакций STMS.
Создавайте резервные копии баз данных после выпуска системы для рабочей среды.
Выполните резервное копирование виртуальных машины на прикладном уровне SAP после развертывания системы в рабочей среде.
Для систем SAP, не входящих в текущую фазу, но взаимодействующих с системами SAP, перенесенными в Azure на этом этапе, необходимо сбросить буфер имен узлов в SM51. Это позволит удалить старые кэшированные IP-адреса, связанные с именами экземпляров приложений, которые уже перемещены в Azure.
Этап после запуска рабочих систем
Этот этап относится к мониторингу, эксплуатации и администрированию системы. С точки зрения SAP обычно применяются обычные задачи, которые требовалось выполнить в старом размещении. Также выполните следующие задачи, связанные с Azure:
Ознакомьтесь со счетами Azure для дорогостоящих систем. Установите язык и региональные параметры finOps и создайте возможность оптимизации затрат Azure в организации.
Оптимизируйте цены и производительность на стороне виртуальной машины и хранилища.
После стабилизации SAP в Azure фокус необходимо перейти на язык и региональные параметры непрерывного изменения размера и проверки емкости. В отличие от локальной среды, где мы имеем размер в течение длительного периода, правильное изменение размера является ключевым преимуществом запуска SAP в рабочей нагрузке Azure, а планирование ресурсов будет ключевым фактором.
Оптимизируйте время, когда можно завершить работу систем.
После стабилизации решения в Azure рассмотрите возможность перехода от коммерческой модели с оплатой по мере использования и использования зарезервированных экземпляров Azure.
Планирование и выполнение регулярных детализаций аварийного восстановления.
Определите и реализуйте свою стратегию вокруг "всегда зеленых", чтобы выровнять собственную стратегию с SAP Майкрософт в стратегии Azure, чтобы получить выгоду от развития технологий.
Контрольный список SAP в инфраструктуре Azure
После развертывания инфраструктуры и приложений и перед началом каждой миграции убедитесь, что:
Были развернуты правильные типы виртуальных машин с правильными атрибутами и конфигурацией хранилища.
Виртуальные машины находятся в актуальной ос, СУБД и выпуске ядра SAP и исправлении, а также ос, СУБД и ядре SAP по всему ландшафту
Виртуальные машины защищены и защищены по мере необходимости и в единообразном порядке в соответствующей среде.
Убедитесь, что в виртуальных машинах, дисковых пространствах или наборах полосы были созданы правильно в файловых системах, для которых требуется больше дисков, таких как данные СУБД и области журнала.
Используются правильные блоки полосы и файловой системы, если они указаны в соответствующих руководствах СУБД
Хранилище и кэширование виртуальных машин Azure используются соответствующим образом.
Убедитесь, что только диски, в которых хранятся журналы СУБД в сети, кэшируются с помощью акселератора записи None+.
Другие диски с хранилищем класса Premium используют параметры кэша ни один или readOnly, в зависимости от использования
Использование служб Azure — Файлы Azure или Azure NetApp Files — для любых томов или общих ресурсов S МБ или NFS. Тома NFS или S МБ доступны соответствующим средам SAP или отдельным системам SAP. При необходимости маршрутизация сети на сервер NFS/S МБ проходит через адресное пространство частной сети, используя частную конечную точку.
Ускоренная сеть Azure включена для всех сетевых интерфейсов для всех виртуальных машин SAP.
Виртуальные (модуль) сети не находятся в пути связи между приложением SAP и уровнем СУБД систем SAP на основе SAP NetWeaver или ABAP Platform.
Все подсистемы балансировки нагрузки для компонентов SAP с высоким уровнем доступности используют стандартную подсистему балансировки нагрузки с включенными с плавающими IP-адресами и портами высокого уровня доступности.
Приложения SAP и виртуальные машины СУБД размещаются в одной или разных подсетях одной виртуальной сети или в виртуальных сетях напрямую.
Правила группы безопасности приложений и сети разрешают обмен данными по желанию и планированию, а также блокируют обмен данными, если это необходимо.
Параметры времени ожидания заданы правильно, как описано выше.
При использовании групп размещения близкого взаимодействия проверка, развертываются ли группы доступности и их виртуальные машины в правильном PPG.
Задержка сети между виртуальными машинами уровня приложений SAP и виртуальными машинами СУБД проверяется и проверяется, как описано в заметках SAP 500235 и 1100926. Оцените результаты по рекомендациям по задержке в сети в заметке SAP 1100926. Задержка сети должна быть в среднем или отличном диапазоне.
Шифрование было реализовано там, где это необходимо, и с соответствующим методом шифрования.
Собственные ключи шифрования защищены от потери, уничтожения или вредоносного использования.
Интерфейсы и другие приложения могут подключаться к недавно развернутой инфраструктуре.
Автоматизированные проверка и аналитические сведения в ландшафте SAP
Некоторые из описанных выше проверка проверка автоматически используются с помощью SAP в средстве проверки качества Azure. Эти проверка можно выполнять автоматически с помощью предоставленного проекта с открытым исходным кодом. Хотя автоматическое исправление обнаруженных проблем не выполняется, средство предупреждает о настройке рекомендаций Майкрософт.
Дополнительные средства для упрощения развертывания проверка и выводов документов, планирование следующих действий по исправлению и, как правило, оптимизация SAP в ландшафте Azure:
Azure Well-Architected Framework просмотрите оценку рабочей нагрузки, ориентированной на пять основных принципов надежности, безопасности, оптимизации затрат, повышения эффективности операций и производительности. Поддерживает рабочие нагрузки SAP и рекомендуется выполнять проверку на начальном этапе и после каждого этапа проекта.
Проверка инвентаризации Azure для SAP An открытый код книге Azure Monitor, которая показывает инвентаризацию Azure с помощью аналитики, чтобы выделить смещение конфигурации и повысить качество.