Соображения по переносу

24 мин

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

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

Здесь вы узнаете, как спланировать и выполнить плавную миграцию базы данных в облако.

Изучение зависимостей

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

Чтобы снизить риски, проверьте, зависит ли база данных от таких служб, как:

Службы каталогов, такие как Active Directory.
Другие хранилища субъектов безопасности.
Другие базы данных.
Веб-API или другие сетевые службы.

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

Проверьте, зависит ли любой из этих типов компонентов от базы данных:

Веб-сайты и веб-API.
Клиентские приложения, такие как мобильные приложения и классическое программное обеспечение.
Другие базы данных.
Отчеты.
Хранилища данных.

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

Подготовка к возврату

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

Для резервного плана рассмотрим:

Как убедиться, что вы можете вернуться к базе данных, нетронутой неудачной миграцией? Например, настоятельно рекомендуется создать полную резервную копию базы данных перед началом миграции.
Как долго допустимо, чтобы база данных находилась вне сети, если нужно переключиться на резервную копию?
Сколько бюджета у вас есть для резервного плана? Например, можно позволить себе реплицировать базу данных на выделенный резервный сервер? Если это так, вы можете отключить этот сервер непосредственно перед миграцией. Чтобы вернуться, вы загрузите этот сервер. У вас сразу же будет база данных, которая не затронута миграцией, и вам не придется восстанавливать ее из резервной копии.

Автономная миграция и миграция через Интернет

Чтобы перенести базу данных, у вас есть по крайней мере два варианта:

Замечание

В настоящее время онлайн-опция недоступна для баз данных MySQL в службе миграции данных.

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

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

Автономные миграции

Предположим, что ваша база данных поддерживает группу аналитиков, которые работают в одном часовом поясе в течение обычных рабочих часов. Команда обычно не работает в выходные дни. Между 6:00 вечера в пятницу и 9:00 в воскресенье база данных не часто используется.

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

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

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

Миграции через Интернет

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

В таких случаях рекомендуется выполнить миграцию через Интернет. При миграции через Интернет время простоя ограничено временем переключения на новую базу данных. Используйте средство, например Azure Data Migration Service, чтобы выполнить миграцию через Интернет. Отличия онлайн миграций от автономных миграций следующие:

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

Перенос приложений

После переноса базы данных как (и когда) перейти к новой системе и обновить приложения для использования новой базы данных? Возможно:

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

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

В автономной миграции источник и назначения не зависят друг от друга. Пользователи и приложения больше не могут видеть согласованное представление данных. В транзакционной системе эта ситуация, скорее всего, будет неприемлемой. В этом случае необходимо поддерживать двунаправленную репликацию между базами данных, пока обе системы остаются активными. Кроме того, если приложение предназначено для создания ежемесячных или еженедельных отчетов, создания прогнозов продаж или выполнения других статистических операций, это отсутствие согласованности может не беспокоиться. Такие приложения принимают долгосрочный подход к данным, а не зависят от данных up-to-date. В последнем случае транзакционные приложения используют новую базу данных, а приложения отчетов перемещаются медленнее.
При миграции через Интернет новая база данных синхронизируется со старой, обычно с какой-то формой репликации. Процесс репликации может быть асинхронным, поэтому может возникнуть задержка. Однако изменения, внесенные в данные в новой базе данных, не будут распространяться обратно к старой, что приводит к возможным конфликтам. Приложение, работающее в старой базе данных, может внести конфликтующие изменения в данные, которые были изменены в новой базе данных. Репликация будет слепо перезаписывать изменения в новой базе данных, что приведет к потере обновления.

Подходы к тестированию

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

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

Кроме того, следует рассмотреть возможность запуска "теста замока". Тест погружения предназначен для оценки того, как система в целом работает под нагрузкой. Тест на выносливость нагружает новую базу данных и определяет, стабильна ли она при высоком спросе. Тест сока выполняется в течение значительного периода времени, чтобы увидеть, что происходит при сохранении высокого спроса.

Когда вы установили, что новая система стабильна, вы можете начать перенос пользователей. Однако может потребоваться дополнительная уверенность в том, что пользователи смогут найти новую систему приемлемой. На этом этапе можно рассмотреть «канарейное тестирование». Канареечный тест прозрачно направляет небольшое подмножество пользователей в новую систему, но они не знают, что они используют её. Это форма слепого тестирования, предназначенная для выявления любых проблем или вопросов с новой системой. Отслеживайте ответы от этих пользователей и внесите необходимые изменения.

Обслуживание параллельных систем

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

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

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

Если вы решите поддерживать параллельные базы данных и синхронизировать изменения, задайте следующие вопросы:

Разрешение конфликтов. Вероятно ли, что изменение строки в локальной среде произойдет одновременно с другим изменением той же строки в облаке? Это создаст конфликт, где неясно, какие изменения следует сохранить. Как вы решите такие конфликты?
Сетевой трафик. Сколько сетевого трафика будет создано во время синхронизации изменений между базами данных? У вас достаточно емкости сети для этого трафика?
Задержка. Когда в одной из баз данных есть изменение, какая задержка (если она есть) допустима, прежде чем это изменение достигнет другой базы данных? Например, в каталоге продуктов вы можете ждать до дня до того, как новые продукты видны всем пользователям. Однако если база данных содержит критически важные сведения о транзакциях, например валютные курсы, данные должны быть синхронизированы гораздо чаще, если они не мгновенно.

Кусочная миграция

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

Несколько баз данных

Сложная система может включать несколько баз данных, поддерживающих несколько рабочих нагрузок. Например, кадровые ресурсы могут использовать базу данных StaffDB , в то время как у группы продаж могут быть мобильные приложения, которые запрашивают базу данных ProductCatalogDB и базу данных OrdersDB .

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

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

Затем можно подумать о переносе рабочей нагрузки каталога продуктов в облако. Если вы это делаете, рассмотрите такие вопросы, как:

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

Пошаговая миграция с одной базой данных

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

Таблицы, поддерживающие операции управления персоналом.
Таблицы, поддерживающие продажи.
Таблицы, поддерживающие анализ и отчеты.

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

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

Проблемы безопасности

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

Защита брандмауэра

В приложении, подключенном к Интернету, серверы баз данных обычно защищаются по крайней мере двумя брандмауэрами. Первый брандмауэр отделяет Интернет от внешних серверов, например, если эти серверы размещают веб-сайты или веб-API. Только TCP-порт 80 должен быть открыт на внешнем брандмауэре, но этот порт должен быть открыт для всех исходных IP-адресов, кроме заблокированных адресов.

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

Если вы планируете перенести серверы баз данных на виртуальные машины Azure, используйте виртуальную сеть с группами безопасности сети (NSG) для репликации правил брандмауэра. Если вы используете Базу данных Azure для MySQL, Базу данных Azureдля MariaDB или Базу данных Azure дляPostgreSQL, можно создать правила брандмауэра для защиты базы данных с помощью страницы безопасности подключения для сервера на портале Azure.

Проверка подлинности и авторизация

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

Замечание

Службы База данных Azure для MySQL, База данных Azure для MariaDB и База данных Azure для PostgreSQL эмулируют традиционную проверку подлинности MySQL, MariaDB и PostgreSQL.

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

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

Узнайте, где хранятся учетные записи пользователей в локальной системе. В MySQL учетные записи пользователей обычно хранятся в user таблице mysql базы данных, но это возможно, например для интеграции с учетными записями пользователей, хранящимися в Active Directory.
Получите список всех учетных записей пользователей. Например, в MySQL можно использовать следующую команду:
```
SELECT host, user FROM mysql.user;
```
Для каждой учетной записи пользователя узнайте, какой доступ у них есть в базе данных. Например, в MySQL для учетной записи пользователя можно использовать следующую dbadmin@on-premises-host команду:
```
SHOW GRANTS FOR 'dbadmin'@'on-premises-host';
```
Повторно создайте каждую учетную запись пользователя в облачной базе данных. Например, в MySQL можно использовать эту команду для создания новой учетной записи:
```
CREATE USER 'dbadmin'@'cloud-host'
```
Авторизация каждой учетной записи пользователя на правильный уровень доступа в облачной базе данных. Например, в MySQL можно использовать эту команду, чтобы разрешить пользователю получить доступ к полной базе данных:
```
GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
```

Шифрование

По мере отправки данных по сети они могут быть перехвачены так называемой атакой типа "человек посередине". Чтобы предотвратить это, как база данных Azure для MySQL, так и база данных Azure для MariaDB и база данных Azure для PostgreSQL поддерживают протокол SSL для шифрования передачи данных. Ssl применяется по умолчанию, и настоятельно рекомендуется не изменять этот параметр.

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

Мониторинг и управление

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

Контроль

Локальные администраторы баз данных привыкли регулярно мониторить, чтобы выявлять такие проблемы, как узкие места в оборудовании или конкуренция за доступ к сети. Они отслеживают, чтобы убедиться, что они могут устранить любые проблемы до того, как производительность будет затронута. Вы можете ожидать, что любая база данных, которая не отслеживается регулярно, рано или поздно начнёт вызывать проблемы.

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

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

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

Управление

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

Azure включает несколько средств, которые можно использовать для администрирования баз данных MySQL, MariaDB и PostgreSQL:

Портал Azure. На этом веб-сайте есть мощные средства, используемые для настройки, мониторинга и управления базами данных, а также всех других ресурсов, которые можно создать в облаке Azure.
Azure PowerShell. Это среда выполнения скриптов и язык с широким набором команд. Используйте PowerShell, доступную для сред Windows и Linux, для автоматизации сложных задач администрирования базы данных.
Azure CLI. Это интерфейс командной строки в Azure. Используйте его для управления службами и ресурсами в Azure. Интерфейс командной строки можно использовать из сред оболочки Windows и Linux и из скриптов Bash.