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

  • 11 мин

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

  • Часто производительность экспорта является определяющим фактором для общего времени простоя. Часто текущему оборудованию более 4–5 лет, и его обновление обходится запредельно дорого.
  • Поэтому важно получить максимальную производительность экспорта, которая практически подходит для достижения.
  • В предыдущих проектах люди тратили недели и даже месяцы, пытаясь настроить производительность экспорта R3load на UNIX или виртуализированных платформах, а затем сдавались и использовали серверы Intel R3load.
  • Сырьевые серверы Intel с двумя сокетами являются недорогими и обеспечивают значительный рост производительности, в некоторых случаях порядки больше, чем незначительные улучшения настройки, возможные на unix или виртуализированных серверах.
  • Клиенты часто имеют существующие фермы виртуальных машин, но чаще всего они не поддерживают современные технологии разгрузки или SR-IOV. Часто версия VMware устарела, не подключена или не настроена для высокой пропускной способности сети и низкой задержки. Серверы экспорта R3load требуют быстрой производительности потока и чрезвычайно высокой пропускной способности сети. Серверы экспорта R3load могут работать в течение 10–15 часов при почти 100-процентной загрузке процессора и сети. Это не типичный вариант использования большинства ферм VMware, и большинство развертываний VMware никогда не были разработаны для обработки рабочей нагрузки, такой как R3load.

Совет

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

Рекомендации

  • Обследование и инвентаризация текущей альбомной ориентации SAP. Определите уровни пакетов поддержки SAP и определите, требуется ли установка исправлений для поддержки целевой СУБД. В целом совместимость операционной системы определяется ядром SAP, а совместимость СУБД — уровнем исправления SAP_BASIS.
  • Создайте список примечаний SAP OSS, которые должны быть применены в исходной системе, например обновления для SMIGR_CREATE_DDL. Рассмотрите возможность обновления ядер SAP в исходных системах, чтобы избежать большого изменения во время миграции в Azure (например. Если система работает с старым ядром версии 7.41, обновите его до последней версии 7.45 в исходной системе, чтобы избежать большого изменения во время миграции).
  • Разработка и документирование решения по обеспечению высокой доступности и аварийному восстановлению. В документации необходимо разделить решение на уровень БД, уровень ASCS и уровень сервера приложений SAP. Отдельные решения могут потребоваться для автономных решений, таких как TREX или liveCache.
  • Разработка документа по размеру и конфигурации, который содержит сведения о типах виртуальных машин Azure и конфигурации хранилища. Сколько дисков класса Premium, сколько файлов данных, сколько файлов данных распределяются по дискам, использованию дисковых пространств, размер формата NTFS = 64 кб. Кроме того, документируйте резервное копирование и восстановление и конфигурацию СУБД, например настройки памяти, максимальную степень параллелизма и флаги трассировки.
  • Разработка документа по проектированию сети, включая виртуальную сеть, подсеть, группу безопасности сети и конфигурацию UDR.
  • Документирование и реализация концепции безопасности и усиления защиты. Удалите Internet Explorer, создайте контейнер Active Directory для учетных записей и серверов служб SAP и примените политику брандмауэра, блокирующую все необходимые порты, кроме ограниченного числа.
  • Создайте проектный документ по миграции ОС/БД с подробным описанием концепции разделения пакетов и таблиц, количества загрузок R3, флагов трассировки SQL Server, сортировки или несортировки, настройки Oracle RowID, настройки SMIGR_CREATE_DDL, счетчиков Perfmon (таких как BCP столбцы/с и BCP пропускная способность кб/с, ЦП, память), настроек RSS, настроек ускорения сети, конфигурации файла журнала, настроек BPE, конфигурации TDE.
  • Создайте график "План тестируемой возможности", показывающий прогресс экспорта и импорта R3load на каждом цикле тестирования. Это позволяет команде миграции проверить, улучшают ли настройки и изменения производительность экспорта или импорта R3load. Ось X — это количество завершенных пакетов, а ось Y — истекшее время. Этот план тестируемой возможности также очень важен во время миграции рабочей среды, чтобы можно было сравнить запланированный прогресс с фактическим и выявить любые проблемы на ранней стадии.
  • Создайте план тестирования производительности. Определите ~20 лучших онлайн-отчетов, пакетных заданий и интерфейсов. Документируйте входные параметры (например, диапазон дат, офис продаж, завод, код компании и т. д.) и время выполнения в исходной системе. Сравните со средой выполнения в Azure. При наличии различий в производительности запустите SAT, ST05 и другие инструменты SAP для выявления неэффективных инструкций.
  • Проведите аудит развертывания и конфигурации и убедитесь, что время ожидания кластера, ядра, сетевые настройки, размер формата NTFS соответствуют проектным документам. Установите счетчики perfmon на важных серверах для записи основных параметров работоспособности каждые 90 секунд. Убедитесь, что серверы SAP находятся в отдельном контейнере AD и что к контейнеру применена групповая политика с настройкой брандмауэра.
  • Убедитесь, что ведущий консультант по миграции ОС/ДБ имеет лицензию! Запросите имя консультанта, s-пользователя и дату сертификации. Откройте сообщение OSS в BC-INS-MIG и попросите SAP подтвердить, что консультант имеет действующую лицензию.
  • По возможности вся проектная группа, связанная с проектом миграции VLDB, должна находиться в одном физическом месте, а не быть географически разбросанной по нескольким континентам и часовым поясам.
  • Убедитесь, что есть правильный резервный план и что это часть общего расписания.
  • Выберите модели процессоров Intel с быстрым числом потоков для экспортных серверов R3load. Не используйте модели ЦП "Energy Saver", так как они имеют более низкую производительность и не используют 4-сокетовые серверы. Intel Xeon E5 Platinum 8158 является хорошим примером.

Рекомендации по предотвращению проблем

  • Не вычитайте одну консалтинговую организацию для выполнения экспорта и субподряда другой консалтинговой организации для выполнения импорта. Иногда исходная система передается на аутсорсинг и управляется одной консалтинговой организацией или партнером, а клиент хочет перейти на Azure и переключиться на другого партнера. Из-за тесной связи между настройкой и настройкой экспорта и импорта маловероятно, что назначение этих задач различным организациям приведет к хорошему результату.
  • Не экономьте ресурсы оборудования Azure во время миграции и идти в режиме реального времени. Плата за Виртуальные машины Azure взимается в минуту и может быть легко уменьшена. Во время миграции VLDB используйте самую мощную виртуальную машину. Клиенты успешно живут на 200-250% избыточных системах, а затем стабилизировались при выполнении избыточных систем. После мониторинга использования системы в течение 4–6 недель виртуальные машины с избыточной емкостью сокращаются до снижения затрат.