Планирование миграции данных

7 мин

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

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

В этом модуле мы подробно рассмотрим все этапы.

Схема пяти этапов модернизации платформы управления данными: обнаружение, оценка, планирование, преобразование и проверка.

Запуск и обнаружение

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

Оценка текущей среды

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

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

Перечисление типов рабочих нагрузок на идентифицированных серверах баз данных предоставляет аналитические сведения об их использовании. Рабочие нагрузки можно классифицировать как аналитические (OLAP) или транзакционные (OLTP) в зависимости от того, являются ли они интенсивными для чтения или записи. Это помогает решить, на какую технологию платформы данных следует перенести. Дальнейшая классификация может включать рабочие нагрузки пакетной поддержки или поддержки принятия решений.

Оценка

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

Все факторы, потенциально препятствующие миграции
Все критические изменения, требующие исправления после миграции
Функции Azure, которые могут использоваться рабочими нагрузками

Для этого необходимо выполнить текущую оценку рабочей нагрузки и оценку критериев рабочей нагрузки:

Текущая оценка рабочей нагрузки

Идентифицированные серверы и приложения баз данных классифицируются и подтверждаются для установления следующего: объем данных и ожидаемые темпы роста, среднее использование ресурсов и их критически важное значение для бизнеса. На этом этапе также можно рассмотреть возможность объединения или вывода из эксплуатации локальных баз данных, чтобы сократить количество баз данных для миграции, а также снизить общую стоимость владения.
Оценка критериев рабочей нагрузки

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

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

Планирование

Этап планирования проекта модернизации платформы данных включает определение целевой платформы, подхода к миграции и планов по устранению рисков для любых запланированных или незапланированных прерываний.

На этапе планирования процесса модернизации платформы данных существует семь терминов, описывающих способ обработки приложений и данных, переходя из существующей локальной среды в новую облачную среду (общедоступную или частную):

#	Стадия	Действие	Description
1.	Оставаться	Ничего не делать	Продолжающаяся модернизация при рассмотрении долгосрочных вариантов оставшихся локальных служб.
2.	Повторное размещение	Миграция в IaaS	Этот подход устраняет необходимость управления центрами обработки данных и дает более высокую рентабельность инвестиций (ROI) с помощью более низкой стоимости владения (TCO).
3.	Рефакторинг	Переход на IaaS или PaaS с минимальными изменениями в приложениях	Этот подход устраняет необходимость управления центрами обработки данных и дает более высокую рентабельность инвестиций (ROI) с помощью более низкой стоимости владения (TCO). Кроме того, это может обеспечить более низкую нагрузку на управление путем консолидации баз данных.
4.	Перепроектирование	Перезапись основных аспектов приложения для использования облачных технологий	Он позволяет использовать современные компоненты, сокращает развертывание кода и упрощает развертывание инфраструктуры и служб DevOps.
5.	Перестроение	Перестроение приложения для использования paaS или бессерверных технологий	Перестроение платформ данных и приложений с помощью новых технологий позволяет использовать встроенную высокую доступность Azure, повысить переносимость приложений и масштабируемость, а также свести к минимуму потенциальные пробелы в навыках между технологией, используемой технологией и поддержкой персонала или разработкой приложения.
6.	Replace	Замена приложения более новым приложением или решением SaaS	Рассмотрим подход замены, если приложение имеет зависимости от физических устройств, подключенных к серверу, или при тесной интеграции с локальной инфраструктурой.
7.	Прекратить использование	Выведите из эксплуатации приложения, которые больше не нужны	Вывод из эксплуатации следует использовать, если устаревшие приложения и базы данных больше не используются, поскольку отсутствуют правовые или бизнес-требования, обусловливающие их использование.

На приведенном ниже графе демонстрируются усилия на выполнение каждой из рекомендации в сравнении с ценностью переноса для бизнеса.

Целевые параметры платформы

При выборе целевой платформы доступны два варианта.
- Инфраструктура как услуга (IaaS) — при таком подходе данные переносятся на виртуальную машину, где установлен SQL Server.
- Платформа как услуга (PaaS) — при таком подходе данные переносятся в службу платформы управления данными, которая соответствует вашей рабочей нагрузке. Для транзакционных рабочих нагрузок, которые будут включать База данных SQL Azure или Управляемый экземпляр SQL Azure. Для рабочих нагрузок типа OLAP это предполагает работу с Azure Synapse Analytics.
Выбор целевой платформы по компонентам
- База данных SQL Azure. Используйте, если область поверхности приложения ограничена базой данных. База данных SQL предлагает решение, почти не требующее обслуживания, которое может стать отличным вариантом для определенных рабочих нагрузок.
- База данных SQL Azure эластичных пулов — эластичные пулы позволяют выделить хранилище и вычислительные ресурсы в группу баз данных, а не управлять ресурсами для каждой базы данных по отдельности. Кроме того, эластичные пулы легче масштабировать, чем отдельные базы данных.
- База данных SQL Azure бессерверным — это эффективно для снижения затрат в средах разработки и тестирования. Функция автоматической приостановки задержки позволяет задать неактивный период до автоматической приостановки базы данных. Вы можете выбрать от 1 часа до 7 дней или отключить его. При повторном доступе к базе данных она возобновляется и взимается только плата за хранение во время приостановки.
- Управляемый экземпляр SQL Azure. Будет подходить для использования, если область поверхности приложения ограничена и требует наличия функций, недоступных в База данных SQL Azure таких как:
  - Агент SQL
  - MSDTC
  - DQS
  - MDS
  - Database Mail
  - PolyBase
  - Поддержка связанных серверов
  - Поддерживает новые облачные службы Azure, такие как обнаружение угроз
- SQL Server на виртуальной машине Azure. Используйте, если область области приложения ограничена и требует наличия функций в Управляемый экземпляр SQL Azure, таких как СЛУЖБЫ SQL Server Reporting Services (SSRS), SQL Server Analysis Services (SSAS) и СЛУЖБЫ SQL Server Integration Services (SSIS).
- Azure Synapse Analytics . Используйте, если у вас есть приложения, выполняющие сложные запросы в большом объеме данных, которые могут использовать преимущества массовой параллельной обработки (MPP) для сокращения времени обработки запросов.

Чтобы просмотреть список функций, поддерживаемых в каждом предложении PaaS для SQL, см. сравнение функций: База данных SQL Azure и Управляемый экземпляр SQL Azure.

Выбор целевой платформы с учетом стоимости
- База данных SQL Azure . Характер База данных SQL Azure платформы как услуга значительно снижает затраты на администрирование и управление по сравнению с более традиционной топологией SQL Server в Azure IaaS, так как большая часть необходимых работ выполняется автоматически в фоновом режиме корпорации Майкрософт. В большом масштабе можно сделать значительную экономию времени и усилий.
- База данных SQL Azure эластичных пулов — База данных SQL Azure эластичные пулы обеспечивают значительную экономию для нескольких баз данных с непредсказуемыми требованиями к использованию. Вычислительные ресурсы являются общими, избегая чрезмерной подготовки и снижения затрат на обслуживание сервера и администрирование.
- Управляемый экземпляр SQL Azure — Управляемый экземпляр SQL предлагается клиентам, которые хотят полностью управляемой службы, где они могут легко поднять и переместить локальную среду с минимальными изменениями конфигурации. Среда поддерживает хранилище не менее 8 ядер и до 8 ТБ, размещенное в изолированной виртуальной сети. Это предложение отлично подходит для клиентов, которые хотят быстро добраться до облака и хотят избежать затрат на обслуживание виртуальных машин.
- SQL Server на виртуальной машине Azure. По сравнению с предложениями PaaS, SQL Server, работающими на виртуальных машинах Azure, обеспечивают более высокие затраты на вычислительные ресурсы, хранилище и управление, но обеспечивают более высокий контроль над SQL Server и инфраструктурой.
- Azure Synapse Analytics позволяет сократить затраты благодаря использованию архитектуры MPP для обработки сложных запросов за считаные минуты вместо нескольких часов.
Автономные и онлайн-миграции

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

Преобразование и оптимизация

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

Оптимизация обычно предполагает изменение переносимой базы данных, чтобы использовать преимущества, предоставляемые компонентом, или оптимизировать ее использование в пределах Azure.

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

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

Чтобы обеспечить успешное выполнение после миграции, может потребоваться выполнить одно или несколько следующих изменений в базу данных.
- Установка обновлений версии до миграции
- Исправьте все ошибки, обнаруженные инструментами оценки миграции
- Внесение изменений в схему базы данных
- Перенос существующих интегрированных служб баз данных в Azure
- Обработка рабочих нагрузок служб SSIS в облаке
Optimize (Оптимизация)

В процессе миграции может потребоваться выполнить одну или несколько рекомендаций по оптимизации, чтобы обеспечить максимальную окупаемость вложений компании в Azure.
- Оценка новых функций, которые могут быть доступны на целевой платформе
- Реструктурировать рабочие нагрузки на более экономичные или эффективные наборы производительности
- Выберите самый высокий уровень обслуживания и уровень производительности во время миграции и уменьшить масштаб после завершения миграции.
- Определение правильного размера рабочих нагрузок
- Минимизация расстояния между BACPAC-файлом и целевым центром обработки данных
- Отключите автоматическую статистику во время миграции.
- Секционированные таблицы и индексы
- Удаление индексированных представлений и их воссоздание после завершения

Миграция, проверка и исправление

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