Основы облачной миграции для хранилища файлов и папок
Каждая миграция начинается с бизнес-потребности. Миграция в облако преобразует рабочую нагрузку, перемещая файлы и папки, от которых она зависит. Рабочая нагрузка может быть приложением или прямым доступом пользователей. В любом случае рабочая нагрузка зависит от хранилища, перемещаемого в облако. Рабочая нагрузка также может переместиться в облако или остаться там, где оно находится, но требует изменения конфигурации, чтобы указать новое расположение облачного хранилища. Эти сведения записываются в дизайне облачного решения с разделом хранилища.
Цель этой статьи заключается в том, чтобы получить представление о том, как можно выполнить миграцию хранилища в Azure, чтобы реализовать разработку облачного решения для хранения.
Перенос файлов и папок в облако требует тщательного планирования и многих соображений на пути достижения оптимального результата. служба хранилища Azure Mover предоставляет растущий список функций и сценариев миграции, которые поддерживают вас в пути. В этой статье мы разбием общие задачи миграции на этапы, в которых каждый из них имеет собственный раздел.
Этап 1. Обнаружение
На этапе обнаружения вы решите, какие исходные расположения являются частью проекта миграции. служба хранилища Azure Mover обрабатывает исходные расположения в виде общих папок. Эти расположения могут находиться в подключенных к сети служба хранилища (NAS), сервере или даже на рабочей станции. Общие протоколы для общих папок: S МБ (блок сообщений сервера) и NFS (сетевая файловая система).
Если рабочая нагрузка использует direct Attached служба хранилища (DAS), скорее всего, служба хранилища Azure Mover по-прежнему может помочь в миграции в облако. Вы можете создать общую папку на пути к локальной папке, а затем предоставить общий доступ к расположению по локальной сети. При наличии соответствующих разрешений и сетевых рекомендаций вы сможете перенести это расположение в Azure, даже если приложение использует локальный путь.
Начните с создания списка всех общих папок, от которых зависит ваша рабочая нагрузка. Ознакомьтесь с проектом облачного решения, чтобы узнать, какие общие папки остаются локальными и которые находятся в область для миграции в облако. Максимально сузьте область проекта миграции. В конечном счете, рабочая нагрузка должна выполнить отработку отказа в облачные расположения. Чем меньше количество исходных расположений, тем проще отработка отказа рабочей нагрузки.
Если необходимо перенести хранилище для нескольких рабочих нагрузок примерно одновременно, их следует разделить на отдельные проекты миграции.
Важно!
Включение нескольких рабочих нагрузок в один проект миграции не рекомендуется. Каждая рабочая нагрузка должна иметь собственный проект миграции. Структурирование проекта таким образом значительно упрощает управление миграцией и отработку отказа рабочей нагрузки.
Результатом этапа обнаружения является список общих папок, которые необходимо перенести в Azure. У вас должны быть отдельные списки для каждой рабочей нагрузки.
служба хранилища Azure Mover предлагает проекты миграции для создания и хранения отдельных списков. Распространенная практика заключается в том, чтобы присвоить проекту миграции имя после миграции рабочей нагрузки. Эта практика упрощает надзор за этапами планирования и прогрессом миграции.
Этап 2. Оценка
Azure предлагает различные типы облачного хранилища. Фундаментальным аспектом миграции файлов в Azure является определение того, какой вариант хранилища Azure подходит для ваших данных. Количество файлов и папок, их структура каталогов, протокол доступа, точность файлов и другие аспекты являются важными входными данными в полное проектирование облачного решения.
На этапе оценки вы изучите обнаруженные и короткие общие папки, чтобы убедиться, что вы выбрали подходящее целевое хранилище Azure для разработки облачного решения.
Ключевой частью любой миграции является запись требуемой точности файлов при перемещении файлов из текущего расположения хранилища в Azure. Различные файловые системы и устройства хранения записывают массив сведений о точности файлов, а также полностью сохраняет или храните эти сведения в Azure не всегда. Точность файла, требуемая вашим сценарием, и степень достоверности, поддерживаемой предложением хранилища в Azure, также помогает выбрать подходящее решение для хранения в Azure. Данные файлов общего назначения традиционно зависят от по крайней мере некоторых метаданных файла. Данные приложений могут от них не зависеть.
Ниже приведены два основных компонента файла:
- Поток данных: поток данных файла хранит содержимое файла.
- Метаданные файла: метаданные файла имеют следующие вложенные компоненты:
- Атрибуты файла, такие как только для чтения
- Разрешения файлов, такие как разрешения NTFS или списки управления доступом к файлам и папкам (ACL)
- метки времени, в первую очередь , создание и последние измененные метки времени
- альтернативный поток данных, который является пространством для хранения больших объемов нестандартных свойств
"Точность файлов" в миграции можно определить как способность:
- Прочитайте все необходимые сведения о файле из источника.
- Передача файлов с помощью службы миграции или средства.
- Хранить файлы в целевом хранилище миграции.
Выходные данные этапа оценки — это список аспектов, найденных в исходной общей папке. Эти аспекты могут включать такие данные, как:
- Размер общего ресурса.
- Количество элементов пространства имен или объединенное количество файлов и папок.
- Уровень точности, который необходимо сохранить в целевом объекте хранилища Azure.
- Уровень точности, который должен оставаться изначально работающим в целевом объекте хранилища Azure.
Это важное представление о разработке облачных решений для хранения.
Этап 3. Планирование
На этапе планирования вы объединяете обнаруженные исходные ресурсы с целевыми расположениями в Azure.
Этап планирования сопоставляет каждый исходный ресурс с определенным местом назначения, например контейнер BLOB-объектов Azure или общую папку Azure. Для этого необходимо запланировать и записать, какие подписки Azure и учетные записи хранения содержат целевые ресурсы.
В службе mover служба хранилища Azure можно записать каждую пару источника или целевого объекта в качестве определения задания. Определение задания вложено в созданный ранее проект миграции. Для каждой пары исходного или целевого задания требуется новое, уникальное определение задания.
Примечание.
В этом выпуске служба хранилища Azure Mover целевое хранилище должно существовать перед созданием определения задания. Например, если целевой объект является контейнером BLOB-объектов Azure, перед созданием нового определения задания необходимо развернуть его.
Результатом этапа планирования является сопоставление исходных общих папок с целевыми расположениями Azure. Если целевые объекты еще не существуют, необходимо выполнить следующий этап "Развернуть", прежде чем записать план миграции в службе служба хранилища Azure Mover.
Этап 4. Развертывание
После завершения плана миграции необходимо убедиться, что развернуты целевые служба хранилища Azure ресурсы, такие как учетные записи хранения и контейнеры. Необходимо выполнить это развертывание, прежде чем записать план миграции в качестве определения задания для каждой пары исходного или целевого объекта в служба хранилища Azure Mover.
служба хранилища Azure Mover в настоящее время не может помочь в развертывании целевого ресурса. Для развертывания хранилища Azure можно использовать портал Azure, Azure PowerShell, Azure CLI или шаблон Bicep.
Важно!
При развертывании служба хранилища Azure просмотрите сочетания пар источника и целевой поддержки для служба хранилища Azure Mover и убедитесь, что не настроены неподдерживаемые сценарии.
Этап 5. Миграция
Работа по копированию файлов и папок в целевое расположение Azure выполняется на этапе миграции.
Существует два основных соображения для этапа миграции:
- Свести к минимуму время простоя рабочей нагрузки.
- Определите правильный режим миграции.
Минимизация времени простоя
Во время миграции может возникнуть период времени, в течение которого рабочая нагрузка не может получить доступ к хранилищу, от которого она зависит. Минимизация этих периодов времени часто является обязательным требованием. В этом разделе рассматривается общая стратегия минимизации простоя рабочей нагрузки.
Конвергентная, n-сквозная миграция
В этой стратегии вы копируете данные из источника в целевой объект несколько раз. Во время этих итераций копирования источник остается доступным для чтения и записи в рабочую нагрузку. Незадолго до окончательной итерации копирования источник будет отключен. Ожидается, что окончательная копия завершается быстрее, чем начальная копия. После окончательной копии отработка отказа рабочей нагрузки будет использоваться новое целевое хранилище в Azure.
служба хранилища Azure Mover поддерживает копирование из источника в целевой объект так часто, как это требуется. Определение задания хранит параметры источника, целевого объекта и миграции. Вы можете указать агенту миграции выполнить определение задания, которое приводит к выполнению задания. В этой связанной статье вы можете узнать больше о иерархии ресурсов mover служба хранилища.
Режимы миграции
Как файлы копируются из источника в целевой объект, так же важно, как где файлы копируются в и из них. Для различных сценариев миграции требуются разные параметры. Во время миграции вы, скорее всего, копируете из источника в целевой объект несколько раз, чтобы свести к минимуму время простоя. При изменении файлов или папок между итерациями копирования режим копирования определяет поведение подсистемы миграции. Тщательно выберите правильный режим на основе ожидаемых изменений в пространстве имен во время миграции.
Существует два режима копирования:
| Copy mode | Поведение миграции |
|---|---|
| Зеркальное отображение Целевой объект выглядит как источник. |
- Файлы в целевом объекте удаляются, если они не существуют в источнике. - Файлы и папки в целевом объекте обновляются, чтобы соответствовать источнику. |
| Слияние Целевой объект имеет больше содержимого, чем источник, и вы продолжаете добавлять в него. |
- Файлы хранятся в целевом объекте, даже если они не существуют в источнике. - Файлы с соответствующими именами и путями обновляются, чтобы соответствовать источнику. - Переименование папок между копиями может привести к дублированию содержимого в целевом объекте. |
Этап 6. Задачи после миграции
На этом этапе миграции необходимо подумать о других конфигурациях и службах, позволяющих выполнить отработку отказа рабочей нагрузки и защитить данные.
Например, для отработки отказа рабочей нагрузки требуется сетевой путь для безопасного доступа к хранилищу Azure. Если вы использовали общедоступную конечную точку учетной записи хранения Azure во время миграции, рассмотрите возможность настройки частных конечных точек для учетной записи хранения и включения правил брандмауэра для отключения запросов данных через общедоступную конечную точку.
Ниже приведены несколько рекомендаций.
Следующие шаги
Эти статьи помогут вам использовать служба хранилища Azure Mover для миграции в облако: