Изучите перенос сверхбольших баз данных
Теперь системы SAP, перемещенные в облако Azure, как правило, включают в себя крупные многонациональные системы "единого глобального экземпляра". Эти системы во много раз больше, чем первые системы клиентов, развернутые, когда платформа Azure была впервые сертифицирована для рабочих нагрузок SAP.
Очень крупные базы данных (VLDB) теперь перемещаются в Azure без проблем. Для баз данных размером свыше 20 ТБ требуется использовать дополнительные методы и процедуры для осуществления миграции из локальной среды в Azure при приемлемом времени простоя и низком риске.
Общий обзор
Полностью оптимизированный перенос сверхбольшой базы данных должен достигать пропускной способности миграции около 2 ТБ в час, а возможно и больше. Это означает, что компонент передачи данных миграции размером 20 ТБ может выполняться примерно через 10 часов. Необходимо выполнить различные шаги последующей обработки и проверки подлинности. В целом при наличии достаточного времени на подготовку и тестирование практически любая клиентская система любого размера может быть перенесена в Azure.
Миграцию сверхбольшой базы данных должны выполнять высококвалифицированные специалисты, способные точно отслеживать всю процедуру и анализировать данные. Например, необходимо всегда измерять и анализировать степень влияния разделения таблиц. Разделение большой таблицы на более чем 50 параллельных процессов экспорта может значительно сократить время экспорта таблицы, но слишком большое количество разделений таблицы может привести к резкому увеличению времени импорта. Поэтому необходимо вычислять и тестировать степень влияния процедуры разделения таблиц. Специалист, лицензированный консультант по миграции OS/DB, должен ознакомиться с понятиями и инструментами. Мы рассмотрим определенное содержимое Azure для миграции VLDB.
В частности, мы имеем дело с разнородной миграцией OS/DB в Azure с SQL Server в качестве целевой базы данных с помощью таких средств, как R3load и Migmon. Шаги миграции не предназначены для однородных копий системы, копия, в которой архитектура СУБД и процессора (Endian Order) остается той же. Как правило, однородные копии системы должны иметь низкое время простоя, независимо от размера СУБД, так как для синхронизации копии базы данных в Azure можно использовать доставку журналов.
Схема блоков, иллюстрированная типичной миграцией ОС И СУБД VLDB и переходом в Azure после ключевых точек:
Текущей исходной ОС или базой данных часто является AIX, HPUX, Solaris или Linux и DB2 или Oracle.
Целевой операционной системой является Windows, SUSE 12,3, Redhat 7.x или Oracle Linux 7.x.
В качестве целевой базы данных обычно используется либо SQL Server, либо Oracle 12.2.
Производительность потоков на оборудовании IBM pSeries, Solaris SPARC и HP Superdome значительно ниже, чем у современных недорогих серверов Intel, поэтому R3load работает на разных серверах Intel.
Для обеспечения хорошей, устойчивой и прогнозируемой производительности сети требуется специальная настройка для VMWare. Как правило, физические серверы используются как сервер R3load, а не виртуальные машины.
Обычно используются четыре сервера экспорта R3load, хотя количество серверов экспорта не ограничено. Ниже указана типовая конфигурация.
- Экспорт сервера 1 — выделенный для крупнейших таблиц 1–4 (в зависимости от того, насколько распределено распределение данных в исходной базе данных).
- Экспорт сервера 2 — выделенный для таблиц с разделением таблиц.
- Экспорт сервера 3 — выделенный для таблиц с разделением таблиц.
- Экспорт сервера 4 — все оставшиеся таблицы.
Экспорт файлов дампа передается с локального диска на сервере R3load Intel в Azure с помощью AzCopy через общедоступный Интернет. Обычно это быстрее, чем через ExpressRoute.
Управление и последовательность импорта осуществляется с помощью файла сигнала (SGN), который автоматически создается при завершении всех пакетов экспорта. Это позволяет осуществлять наполовину параллельный экспорт и импорт.
Импорт в SQL Server или Oracle структурируется аналогично экспорту; с помощью четырех серверов импорта. Эти серверы будут представлять собой отдельные выделенные серверы R3load с функцией «ускоренной сети». Рекомендуется, чтобы серверы приложений SAP не были для этой задачи.
Базы данных VLDB обычно используют виртуальные машины E64v3, m64 или m128 с хранилище класса Premium. Журнал транзакций можно поместить на локальный ssd-диск, чтобы ускорить запись журнала транзакций и удалить пропускную способность журнала транзакций и пропускную способность операций ввода-вывода из квоты виртуальной машины. После миграции журнал транзакций должен быть помещен на сохраненный диск.
