Особенности переноса

24 мин

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

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

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

Исследование зависимостей

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

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

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

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

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

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

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

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

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

При планировании отката следует учитывать следующее.

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

Миграция в автономном и рабочем режиме

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

Примечание.

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

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

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

Миграции в автономном режиме

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

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

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

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

Миграции в рабочем режиме

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

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

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

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

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

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

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

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

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

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

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

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

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

Поддержание параллельных систем

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

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

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

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

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

Миграция по частям

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

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

Сложная система может включать несколько баз данных, поддерживающих несколько рабочих нагрузок. Например, отдел кадров может использовать базу данных 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.