Изучение этапа пилотного развертывания

  • 20 мин

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

1. Оптимизируйте перенос данных в Azure

Подход и результат в значительной степени зависят от возможностей подключения клиента к Azure. В зависимости от объема данных для этой цели можно использовать: ExpressRoute, VPN-соединение "сеть-сеть" или автономные службы передачи данных, такие как Azure Data Box или служба импорта и экспорта Azure.

2. Перенесите данные с разнородных платформ SAP

В случае переноса разнородной платформы SAP, когда требуется выполнить экспорт и импорт данных базы данных, протестируйте и оптимизируйте этапы экспорта и импорта. Для миграции крупных и разнородных развертываний для SQL Server воспользуйтесь записью блога SAP OS/DB Migration to SQL Server–FAQ (Миграция ОС и базы данных SAP на SQL Server — Часто задаваемые вопросы) Вы можете использовать монитор миграции или SWPM, если вам не нужно объединить миграцию с обновлением выпуска или параметром миграции базы данных SAP (DMO) в противном случае. Подробные сведения см. в блоге Database Migration Option (DMO) of SUM – Introduction (Параметр миграции базы данных (DMO) для SUM — введение) В любом случае выполните следующие действия.

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

3. Выполните техническую проверку

Типы виртуальных машин

  • Справочные заметки о поддержке SAP, каталог оборудования SAP HANA и матрица доступности продуктов SAP (PAM), чтобы обеспечить точность сведений о поддерживаемых номерах SKU виртуальных машин Azure, поддерживаемых выпусках ОС для этих SKU виртуальных машин Azure и поддерживаемых выпусках SAP и СУБД.
  • Проверьте размер инфраструктуры и компонентов приложения, развертываемых в Azure. При миграции существующих приложений необходимо получать необходимые SAPS с учетом существующих данных телеметрии. Получите эталонные данные SAP и сравните их с номерами SAPS, указанными в примечании SAP № 1928533. Кроме того, ознакомьтесь с информацией, предоставленной в оценках SAPS в Azure Виртуальные машины, где искать и где можно запутаться.
  • Оцените и проверьте размер Виртуальные машины Azure в отношении максимальной пропускной способности хранилища и сетевой пропускной способности различных типов виртуальных машин, выбранных на этапе планирования. Эти данные можно найти в статье Размеры для виртуальных машин в Azure. Если гостевая операционная система Виртуальной машины Azure — Windows, важно учитывать максимальную пропускную способность некичированного диска для изменения размера. В случае Linux также важно учитывать максимальную пропускную способность диска без кэширования для изменения размера.

Хранилище

  • Используйте хранилище SSD Azure уровня "Стандартный" в качестве минимального значения для виртуальных машин, представляющих уровни приложений SAP, и для развертывания СУБД с учетом производительности и использования Azure хранилище класса Premium для всех виртуальных машин СУБД, которые чувствительны к производительности.
  • Не следует использовать стандартные HDD-диски Azure.
  • Используйте управляемые диски Azure.
  • Включите ускоритель записи Azure для дисков журналов СУБД с помощью Виртуальные машины Azure серии M. Помните о задокументированных ограничениях ускорителя записи и ограничениях на использование.
  • Сведения о хранилище для СУБД см. в статье Рекомендации по развертыванию СУБД на виртуальных машинах Azure для рабочих нагрузок SAP и в документации по конкретной СУБД, ссылки на которую есть в этом документе.
  • Сведения о развертывании SAP HANA см. в статье Конфигурации инфраструктуры SAP HANA и ее работа в Azure.
  • Никогда не подключайте диски данных Azure к виртуальной машине Linux Azure с помощью идентификатора устройства. Вместо этого используйте универсальный уникальный идентификатор (UUID). Будьте внимательны при использовании графических средств для подключения диска данных Azure. Проверьте записи в /etc/fstab, чтобы убедиться, что диски подключены с использованием UUID. Дополнительные сведения см. в статье "Подключение к виртуальной машине Linux" для подключения нового диска.

Сеть

Протестируйте и оцените инфраструктуру виртуальной сети и распределение приложений SAP между виртуальными сетями Azure или внутри них.

  1. Проанализируйте звездообразную архитектуру виртуальной сети или микросегментацию в пределах одной виртуальной сети Azure с учетом следующих критериев:

    • Затраты из-за обмена данными между одноранговых виртуальных сетей Azure (дополнительные сведения см. в ценах на виртуальную сеть Azure.
    • Сравнение возможности завершения пиринга между виртуальными сетями Azure и использованием групп безопасности сети для изоляции подсетей в виртуальной сети в случаях, когда приложения или виртуальные машины, размещенные в подсети виртуальной сети, становятся угрозой безопасности.
    • Централизованное ведение журнала и аудит сетевого трафика между локальной средой, Интернетом и виртуальным центром обработки данных Azure.

  2. Оцените и протестируйте путь передачи данных между уровнем приложений SAP и уровнем СУБД SAP. В ходе оценки учитывайте следующее.

    • Размещение сетевых виртуальных устройств в пути обмена данными между приложением SAP и уровнем СУБД sap NetWeaver, Hybris или S/4HANA на основе систем SAP не поддерживается.
    • Размещение уровня приложений SAP и СУБД SAP в разных виртуальных сетях Azure, которые не поддерживают пиринг, не поддерживаются.
    • Поддерживается использование групп безопасности приложение Azure (ASG) и групп безопасности сети (NSG) для управления потоком трафика между уровнем приложений SAP и уровнем СУБД SAP.

  3. Убедитесь, что служба "Ускорение сети Azure" включена на виртуальных машинах, используемых на уровне приложений SAP и на уровне СУБД SAP. Учитывайте требования ОС для поддержки ускорения сети в Azure.

    • Windows Server 2012 R2 или более поздние выпуски;
    • SUSE Linux 12 с пакетом обновления 3 (SP3) или более поздние выпуски;
    • RHEL 7.4 или более поздние выпуски;
    • Oracle Linux 7.5. Для ядра RHCKL требуется выпуск 3.10.0-862.13.1.el7. Для ядра Oracle UEK требуется выпуск 5.

  4. Проверьте и оцените задержку сети между виртуальной машиной уровня приложений SAP и виртуальной машиной СУБД в соответствии с примечанием SAP #500235 и примечанием SAP #1100926. Оцените результаты в соответствии с рекомендациями по задержки сети в примечании SAP № 1100926. Задержка сети должна быть умеренной или оптимальной.

  5. Убедитесь в том, что для развернутых внутренних подсистем балансировки нагрузки Azure (ILB) настроено использование прямого ответа от сервера. Этот параметр сокращает задержку в случаях, когда ILB используются для конфигураций с высоким уровнем доступности на уровне СУБД.

  6. Если вы используете подсистему балансировки нагрузки Azure в сочетании с гостевыми операционными системами Linux, убедитесь, что параметр сети Linux net.ipv4.tcp_timestamps имеет значение 0. Обратите внимание, что это противоречит общим рекомендациям в примечании SAP № 2382421. Эта заметка SAP была обновлена с учетом того, что параметр должен иметь значение 0 для работы совместно с подсистемами балансировки нагрузки Azure.

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

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

    • Если вам не требуется высокий уровень доступности для служб SAP Central и СУБД, эти виртуальные машины можно развернуть в той же группе доступности, что и уровень приложений SAP.

  • Если необходимо обеспечить защиту центральных служб SAP и уровня СУБД, чтобы гарантировать высокий уровень доступности с использованием пассивной реплики, разверните два узла для центральных служб SAP в одной группе доступности и два узла СУБД в другой группе доступности.

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

  • Помните, что при создании отказоустойчивых кластеров windows Server или Pacemaker на основе Pacemaker необходимо использовать подсистему балансировки нагрузки Azure уровня "Стандартный" для СУБД и уровня SAP Central Services в зонах доступности. Базовая подсистема балансировки нагрузки не поддерживает зональные развертывания.

Параметры времени ожидания.

  • Проверьте трассировку экземпляров SAP в средствах для разработчиков SAP NetWeaver и убедитесь в отсутствии разрывов соединения между сервером очереди и рабочими процессами SAP. Этих разрывов подключения можно избежать, настроив следующие два параметра реестра:

    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. Дополнительные сведения см. в разделе KeepAliveTime.
    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. Дополнительные сведения см. в разделе KeepAliveInterval.

  • Чтобы избежать истечения времени ожидания между графическими пользовательскими интерфейсами локального развертывания SAP и прикладным уровнем SAP, развернутым в Azure, проверьте, заданы ли следующие параметры в файле default.pfl или профиля экземпляра:

    • rdisp/keepalive_timeout = 3600
    • rdisp/keepalive = 20

  • При использовании отказоустойчивой кластеризации Windows убедитесь в том, что правильно заданы параметры, определяющие отработку отказа, которые активируются неотвечающими узлами. В статье технического сообщества Майкрософт Tuning Failover Cluster Network Thresholds (Настройка порогов для сети отказоустойчивого кластера) перечислены эти параметры и их влияние на поведение при отработке отказа. Например, если узлы кластера находятся в одной подсети, настройте параметры отработки отказа следующим образом:

    • SameSubNetDelay = 2000

    • SameSubNetThreshold = 15

    • RoutingHistorylength = 30

    • Протестируйте процедуры HADR (высокая доступность и аварийное восстановление):

      • Имитация отработки отказа путем завершения работы Azure Виртуальные машины (гостевая ОС Windows) или размещения операционных систем в режиме паники (гостевая ОС Linux).

      • Измерьте время, затрачиваемое на отработки отказа. Если время слишком велико, рассмотрите следующие моменты.

        • В SUSE Linux для ускорения отработки отказа используйте устройства SBD вместо агента ограждения Azure.
        • Если перезагрузка данных в SAP HANA отнимает слишком много времени, следует подумать о повышении производительности хранилища.

      • Протестируйте последовательность резервного копирования и восстановления. Обратите внимание на время. Настройте их при необходимости. Убедитесь в том, что предусмотрено достаточно времени не только на резервное копирование. Кроме того, протестируйте восстановление и измерьте время выполнения действий по восстановлению. Убедитесь, что время восстановления находятся в соглашениях об уровне обслуживания RTO, где RTO использует базу данных или процесс восстановления виртуальной машины.

      • Протестируйте работоспособность и архитектуру аварийного восстановления.

4. Выполните проверки безопасности

  • Проверьте, насколько эффективна выбранная методика контроля доступа Azure на основе ролей. Цель — разделить и разграничить доступ и разрешения, делегированные различным отделам. Например, участники группы SAP Basis должны иметь возможность развертывать azure Виртуальные машины в определенной виртуальной сети Azure и назначать диски этим Виртуальные машины Azure. Однако команда SAP Basis не должна создавать новые виртуальные сети или изменять параметры существующих виртуальных сетей. И наоборот, члены группы сети не должны иметь возможности развертывать Виртуальные машины Azure в виртуальных сетях, где выполняются приложения SAP и виртуальные машины СУБД. Кроме того, члены группы сети не смогут изменять атрибуты виртуальных машин или удалять виртуальные машины и их диски.
  • Убедитесь в том, что правила группы безопасности сети работают правильно и обеспечивают безопасность защищенных ресурсов.
  • Проверьте параметры шифрования данных при хранении и передаче. Определите и реализуйте процессы резервного копирования, хранения и доступа к сертификатам, а также проверки процесса восстановления зашифрованных сущностей.
  • Примените Шифрование дисков Azure для дисков ОС.
  • При принятии решения о том, следует ли реализовать механизм шифрования, необходимо руководствоваться практическими соображениями. Например, оцените, необходимо ли применять шифрование дисков Azure и прозрачное шифрование СУБД.

5. Тестирование производительности

В сценариях миграции используйте трассировку и измерения SAP для сравнения пилотного проекта с текущей реализацией на основе:

  • 10 самых популярных отчетов в оперативном режиме
  • 10 самых популярных пакетных заданий;
  • передача данных через интерфейсы в систему SAP, в первую очередь для распределенного трафика.