Миграция из подключенного к сети хранилища (NAS) в гибридное облачное развертывание с помощью службы "Синхронизация файлов Azure"

✔️ Область применения: классические общие папки SMB, созданные с помощью поставщика ресурсов Microsoft.Storage

✖️ Не применяется: все файловые ресурсы NFS, включая: файловые ресурсы, созданные с использованием поставщика ресурсов Microsoft.FileShares (предварительная версия), или классические файловые ресурсы, созданные с использованием поставщика ресурсов Microsoft.Storage

Эта статья миграции является одной из нескольких, включающей ключевые слова NAS и синхронизацию файлов Azure. Проверьте, относится ли эта статья к вашему сценарию:

  • Источник данных: подключенное к сети хранилище (NAS)
  • Маршрут миграции: NAS ⇒ Windows Server ⇒ загрузка и синхронизация с файловыми ресурсами Azure
  • Кэширование файлов в локальной среде. Да, конечной целью является развертывание службы "Синхронизация файлов Azure".

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

Синхронизация файлов Azure работает на устройствах хранения данных с прямым подключением (DAS) и не поддерживает синхронизацию с сетевыми хранилищами (NAS). Этот факт делает миграцию файлов необходимыми, и в этой статье описано, как планирование и выполнение такой миграции.

Цели миграции

Целью является перемещение общих папок SMB на устройстве NAS на Windows Server, а затем использование службы "Синхронизация файлов Azure" для гибридного развертывания облака. Как правило, необходимо выполнить миграцию таким образом, чтобы гарантировать целостность рабочих данных и ее доступность во время миграции. В последнем случае необходимо минимизировать время простоя, чтобы оно укладывалось в окна регулярного обслуживания или лишь незначительно их превышало.

Обзор миграции

Как упоминалось в статье "Миграция на общие папки SMB Azure", важно использовать правильное средство копирования и подход. Устройство NAS предоставляет общие ресурсы SMB непосредственно в локальной сети. Для перемещения файлов можно использовать Azure Storage Mover или RoboCopy.

Этап 1. Определение количества необходимых общих папок Azure

На этом шаге вы определяете, сколько файловых хранилищ Azure вам нужно. Один экземпляр Windows Server (или кластер) может синхронизировать до 30 общих папок Azure.

Возможно, у вас на томах есть больше папок, которые вы в настоящее время делитесь локально в виде SMB-ресурсов с пользователями и приложениями. Самый простой способ представить этот сценарий — это вообразить локальную общую папку, которая сопоставляется один к одному с общей папкой в Azure. Если у вас достаточно малое количество общих ресурсов, меньше 30 для одного экземпляра Windows Server, рекомендуется сопоставление 1:1.

Если у вас более 30 общих папок, сопоставление локальной общей папки 1:1 с общей папкой Azure часто не требуется. Рассмотрим следующие варианты.

Совместное использование группирования

Например, если отдел кадров имеет 15 общих папок, вы можете сохранить все данные отдела кадров в одной общей папке Azure. Хранение нескольких локальных общих ресурсов в одной общей папке Azure не препятствует созданию обычных 15 SMB-шаров на локальном экземпляре Windows Server. Это просто означает, что корневые каталоги этих 15 ресурсов упорядочиваются как вложенные папки под общую папку. Затем вы синхронизируете эту общую папку с общей папкой Azure. Таким образом, для этой группы локальных общих папок требуется только один файловый ресурс Azure в облаке.

Синхронизация томов

Служба Azure File Sync поддерживает синхронизацию корневого каталога тома с файловым ресурсом Azure. При синхронизации корневого каталога тома все вложенные папки и файлы отправляются в одно файловое хранилище Azure.

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

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

  • Начальное сканирование содержимого облака может завершиться быстрее, что, в свою очередь, сокращает время ожидания появления пространства имен на сервере с включенной функцией синхронизации файлов Azure.
  • Облачное восстановление из моментального снимка файла общего доступа Azure происходит быстрее.
  • Аварийное восстановление локального сервера может значительно ускориться.
  • Изменения, внесенные непосредственно в общую папку Azure (вне синхронизации), могут быть обнаружены и синхронизированы быстрее.

Tip

Если вы не знаете, сколько файлов и папок у вас есть, ознакомьтесь со средством TreeSize из JAM Software.

Структурированный подход к карте развертывания

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

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

  • Сервер, на котором установлен агент синхронизации файлов Azure, может синхронизироваться с 30 общими папками Azure.

  • Файловое хранилище Azure развернуто в учетной записи хранения. Это делает учетную запись хранения объектом масштабирования для таких показателей производительности, как операции ввода-вывода в секунду и пропускная способность.

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

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

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

Tip

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

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

Важно

Наиболее важным вектором масштабирования для синхронизации файлов Azure является количество элементов (файлов и папок), которые необходимо синхронизировать. Дополнительные сведения см. в целевых объектах масштабирования синхронизации файлов Azure .

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

Важно

Наиболее важным вектором масштабирования для синхронизации файлов Azure является количество элементов (файлов и папок), которые необходимо синхронизировать. Дополнительные сведения см. в целевых объектах масштабирования синхронизации файлов Azure.

Распространенные сценарии синхронизации файлов и рекомендации

Сценарий синхронизации Поддерживается Рекомендации (или ограничения) Решение (или обходное решение)
Файловый сервер с несколькими дисками и томами и несколькими общими папками в одной целевой общей папке Azure (консолидация) Нет Целевая файловая папка Azure (конечная точка облака) поддерживает синхронизацию только с одной группой синхронизации.

Группа синхронизации поддерживает только одну конечную точку сервера на зарегистрированный сервер.		 1. Начните с синхронизации одного диска (корневого тома) с целевой файловой папкой Azure. Начиная с самого большого диска или тома, вы сможете выполнить требования к хранилищу в локальной среде. Настройте облачное распределение по уровням, чтобы переместить все данные в облако и освободить место на диске файлового сервера. Перемещайте данные из других томов или общих папок в текущий том, который синхронизируется. Продолжайте шаги последовательно до тех пор, пока все данные не будут загружены в облако или перенесены.
2) Фокусируйтесь на одном корневом томе (диске) за один раз. Используйте распределение по уровням облака для распределения всех данных в целевую общую папку Azure. Удалите конечную точку сервера из группы синхронизации, повторно создайте конечную точку со следующим корневым томом или диском, синхронизируйте и повторите процесс. Обратите внимание, что может потребоваться переустановить агент.
3. Рекомендуется использовать несколько целевых общих папок Azure (одну или другую учетную запись хранения в зависимости от требований к производительности).
Файловый сервер с одним томом и несколькими общими ресурсами для одной целевой общей папки Azure (консолидация) Yes Невозможно иметь несколько конечных точек сервера на зарегистрированном сервере, синхронизирующихся с одним и тем же целевым файловым хранилищем Azure (аналогично предыдущему сценарию). Синхронизируйте корневой каталог тома, в котором хранятся несколько общих папок или папок верхнего уровня.
Файловый сервер с несколькими общими папками и (или) томами для нескольких общих папок Azure в рамках одной учетной записи хранения (сопоставление общих папок 1:1) Yes Один экземпляр Windows Server (или кластер) может синхронизировать до 30 общих папок Azure.

Учетная запись хранения — это целевой объект масштабирования для производительности. IOPS и пропускная способность распределяются между файловыми ресурсами.

Сохраняйте количество элементов для каждой группы синхронизации в пределах 100 миллионов элементов (файлов и папок) на общую папку. Лучше всего остаться ниже 20 или 30 миллионов на акцию.		 1) Использование нескольких групп синхронизации (число групп синхронизации = количество общих папок Azure для синхронизации).
2) В этом сценарии можно синхронизировать только 30 единиц. Если на файловом сервере более 30 общих папок, используйте группирование ресурсов и синхронизацию томов, чтобы уменьшить количество корневых или верхнеуровневых папок на исходном сервере.
3) Используйте дополнительные локальные серверы синхронизации файлов Azure и разделите или переместите данные на эти серверы, чтобы обойти ограничения в исходном экземпляре Windows Server.
Файловый сервер с несколькими общими папками и (или) томами для нескольких общих папок Azure в другой учетной записи хранения (сопоставление общих папок 1:1) Yes Один экземпляр Windows Server (или кластер) может синхронизировать до 30 общих папок Azure (одной или другой учетной записи хранения).

Сохраняйте количество элементов для каждой группы синхронизации в пределах 100 миллионов элементов (файлов и папок) на общую папку. Лучше всего остаться ниже 20 или 30 миллионов на акцию.		 Аналогично предыдущему подходу.
Несколько файловых серверов с одним корневым томом или общим ресурсом для одной целевой общей папки Azure (консолидация) Нет Группа синхронизации не может использовать облачную конечную точку (общую папку Azure), которая уже настроена в другой группе синхронизации.

Хотя группа синхронизации может иметь конечные точки сервера на разных файловых серверах, файлы не могут отличаться.		 Следуйте указаниям в первом сценарии, дополнительно уделяя внимание нацеливанию на один файловый сервер поочерёдно.
Топология между арендаторами (использование управляемой идентичности в разных арендаторах) Нет Служба синхронизации хранилища, ресурс сервера (сервер с поддержкой Azure Arc или виртуальная машина Azure), управляемое удостоверение и назначения RBAC в учетной записи хранения должны находиться в одном клиенте Microsoft Entra. Топологии между клиентами не поддерживаются. Настройка для нескольких арендаторов не проходит проверку подлинности и авторизации, и сервер не может подключиться. Чтобы продолжить, убедитесь, что все ресурсы (служба синхронизации, сервер, управляемое удостоверение и назначения RBAC) созданы внутри одного клиента Microsoft Entra.

Создание таблицы сопоставления

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

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

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

Этап 2. Подготовка подходящего локального сервера Windows Server

  • Создайте виртуальную машину Windows Server 2022 или Windows Server 2019 или разверните физический сервер. Также поддерживается отказоустойчивый кластер Windows Server.

  • Добавление или обеспечение прямо подключенного хранилища данных (DAS), в отличие от NAS, которая не поддерживается.

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

    1. Перемещение набора файлов, которые помещаются на диск
    2. Разрешить синхронизацию файлов и взаимодействие по уровням в облаке
    3. Когда на томе будет создано больше свободного места, перейдите к следующему пакету файлов. Кроме того, ознакомьтесь с командой RoboCopy в разделе RoboCopy этой статьи для использования нового /LFSM коммутатора. Использование /LFSM может значительно упростить задания RoboCopy, но оно несовместимо с некоторыми другими коммутаторами RoboCopy, от которые могут зависеть. Используйте /LFSM переключатель только в том случае, если место назначения миграции является локальным хранилищем. Не поддерживается, если целью является удаленный ресурс SMB.

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

Конфигурация ресурсов (вычислительные ресурсы и ОЗУ) развернутого сервера Windows Server в основном зависит от количества элементов (файлов и папок), которые будут синхронизированы. Рекомендуется использовать более высокую конфигурацию производительности, если у вас возникли проблемы.

Узнайте, как настроить размер Windows Server на основе количества элементов (файлов и папок), которые необходимо синхронизировать.

Примечание

В ранее связанной статье представлена таблица с диапазоном памяти сервера (ОЗУ). Вы можете ориентироваться на меньшее число сервера, но ожидать, что начальная синхронизация может занять значительно больше времени.

Этап 3. Развертывание облачного ресурса Синхронизации файлов Azure

Чтобы выполнить этот шаг, вам потребуются учетные данные подписки Azure.

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

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

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

Этап 4. Развертывание ресурсов хранилища Azure

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

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

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

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

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

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

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

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

Осторожно

Если вы создаете общую папку Azure с ограничением в 100 ТиБ, то эта общая папка может использовать только локально избыточное хранилище или избыточное хранилище в зонах. Рассмотрите ваши потребности в избыточной емкости данных перед использованием файловых хранилищ размером 100 TiB.

Общие папки Azure по-прежнему создаются с ограничением 5 ТиБ по умолчанию. Выполните действия, описанные в статье "Создание общей папки Azure", чтобы создать большой файловый ресурс .

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

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

Этап 5. Развертывание агента синхронизации файлов Azure

В этом разделе описано, как установить агент синхронизации файлов Azure в экземпляре Windows Server.

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

Откройте PowerShell. Установите необходимые модули PowerShell с помощью следующих команд. Не забудьте установить полный модуль и провайдер NuGet, когда вам это предложат.

Install-Module -Name Az -AllowClobber
Install-Module -Name Az.StorageSync

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

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

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

В конце мастера установки сервера откроется мастер регистрации сервера. Зарегистрируйте сервер в ресурсе службы синхронизации хранилища Azure, указанного ранее.

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

Используйте самый новый агент. Его можно скачать из Центра загрузки Майкрософт: агент синхронизации файлов Azure.

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

Этап 6. Настройка синхронизации файлов Azure на Windows Server

Зарегистрированный локальный сервер Windows Server должен быть готов и подключен к Интернету для этого процесса.

Этот шаг связывает все ресурсы и папки, которые вы настроили в экземпляре Windows Server на предыдущих шагах.

  1. Войдите на портал Azure.
  2. Найдите ресурс службы синхронизации хранилища.
  3. Создайте новую группу синхронизации в ресурсе службы синхронизации хранилища для каждой общей папки Azure. В терминологии синхронизации файлов Azure общая папка Azure станет облачной конечной точкой в топологии синхронизации, которую вы описываете при создании группы синхронизации. При создании группы синхронизации присвойте ему знакомое имя, чтобы узнать, какой набор файлов синхронизируется там. Убедитесь, что вы ссылаетесь на общую папку Azure с соответствующим именем.
  4. После создания группы синхронизации строка для нее появится в списке групп синхронизации. Выберите имя (ссылка), чтобы отобразить содержимое группы синхронизации. Вы увидите общую папку Azure в облачных конечных точках.
  5. Найдите кнопку "Добавить конечную точку сервера ". Папка на локальном сервере, которую вы настроили, станет путем для этой конечной точки сервера.

Важно

Облачное многоуровневое хранилище — это функция синхронизации файлов Azure, которая позволяет локальному серверу иметь меньший объем памяти, чем хранится в облаке, но при этом он имеет полное дерево каталогов. Локальные интересные (горячие) данные также кэшируются локально для быстрой производительности доступа. Облачная иерархия — это необязательная функция для конечной точки сервера в Azure File Sync.

Предупреждение

Если вы выделили меньше хранилища на томах сервера Windows, чем данных, которые использованы на устройстве NAS, то облачное распределение по уровням является обязательным. Если вы не включите распределение по уровням в облаке, сервер не освободит место для хранения всех файлов. Установите политику многоуровневого хранения, временно для миграции, на 99% свободного объёма пространства. Не забудьте вернуться к параметрам уровня облака после завершения миграции и установить его на более долгосрочный полезный уровень.

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

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

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

Этап 7. Копирование данных с помощью Azure Storage Mover или RoboCopy

Теперь вы можете использовать Mover или RoboCopy службы хранилища Azure для копирования данных с устройства NAS на Windows Server и использовать синхронизацию файлов Azure для перемещения данных в общие папки Azure. В этом руководстве используется RoboCopy для первоначальной копии. Чтобы использовать Azure Storage Mover, см. раздел «Перенос на файловые общие ресурсы Azure SMB с помощью Azure Storage Mover».

Запустите первую локальную копию в целевую папку Windows Server:

  • Определите первое расположение на устройстве NAS.
  • Определите соответствующую папку на Windows Server, в которую уже настроена синхронизация файлов Azure.
  • Начните копирование.

Следующая команда RoboCopy копирует файлы из хранилища NAS в целевую папку Windows Server. Windows Server синхронизирует его с общими папками Azure.

Если вы выделили меньше хранилища на Windows Server, чем требуется для ваших файлов на устройстве NAS, то вы настроили облачное распределение по уровням. Когда локальный том Windows Server заполняется, cloud tiering начнет работу и переместит файлы на более высокие уровни, которые уже успешно синхронизированы. Распределение по уровням в облаке создаст достаточно места для продолжения копирования с устройства NAS. Многоуровневое облако проверяет один раз в час, чтобы узнать, что синхронизировано и освободить место на диске, чтобы достичь 99% свободного места тома.

Возможно, RoboCopy перемещает файлы быстрее, чем их можно синхронизировать с облаком и распределить по уровням хранения локально, что может привести к нехватке места на локальном диске. В этом случае RoboCopy завершится ошибкой. Мы рекомендуем работать с общими папками в последовательности, которая предотвращает это, например, не запуская задания копирования для всех общих папок одновременно или только перемещая общие папки, которые соответствуют текущему объему свободного места на Windows Server.

robocopy <SourcePath> <Dest.Path> /MT:20 /R:2 /W:1 /B /MIR /IT /COPY:DATSO /DCOPY:DAT /NP /NFL /NDL /XD "System Volume Information" /UNILOG:<FilePathAndName>
Switch Значение
/MT:n Позволяет Robocopy выполнять многопоточный режим. n Значение по умолчанию — 8. Максимальное значение — 128 потоков. Хотя большое количество потоков помогает насыщать доступную пропускную способность, это не означает, что миграция всегда будет быстрее с большим количеством потоков. Тесты с файлами Azure показывают, что от 8 до 20 обеспечивает сбалансированную производительность при начальной операции копирования. Последующие /MIR запуски постепенно влияют на доступные вычислительные ресурсы и доступную пропускную способность сети. Для последующих запусков постарайтесь более точно соответствовать значению количества потоков числу ядер процессора и количеству потоков на ядро. Рассмотрите необходимость резервирования ядер для других задач, которые может иметь рабочий сервер. Тесты с Azure Files показали, что до 64 потоков обеспечивают хорошую производительность, но только если процессоры могут поддерживать их активными одновременно.
/R:n Максимальное количество повторных попыток для файла, который не может копироваться при первой попытке. Robocopy будет пытаться n раз, пока окончательно не завершится ошибка копирования файла. Вы можете оптимизировать производительность запуска: выберите значение два или три, если считаете, что проблемы с тайм-аутом вызывали сбои в прошлом. Это может быть более распространено в сетях WAN. Выберите «не повторять» или значение «повторить один раз», если считаете, что файл не удалось скопировать из-за его активного использования. Попытка снова через несколько секунд может оказаться недостаточной, чтобы состояние файла «в использовании» изменилось. Пользователям или приложениям, которые держат файлы открытыми, может понадобиться ещё несколько часов. В этом случае, если файл не был скопирован, его может перехватить одна из запланированных последующих попыток запуска Robocopy, что в итоге позволит успешно скопировать файл. Это помогает текущему запуску выполняться быстрее, так как он не затягивается множеством повторных попыток, которые в конечном итоге приводят к большинству сбоев копирования из-за того, что файлы остаются открытыми после истечения времени ожидания повторных попыток.
/W:n Указывает время ожидания Robocopy перед попыткой копирования файла, который не удалось скопировать во время предыдущей попытки. n — количество секунд ожидания между повторными попытками. /W:n часто используется вместе с /R:n.
/B Запускает Robocopy в том же режиме, что и приложение резервного копирования. Этот параметр позволяет Robocopy перемещать файлы, для которых у текущего пользователя нет разрешений. Переключатель резервного копирования зависит от выполнения команды Robocopy в консоли с повышенными привилегиями администратора или в окне PowerShell. Если вы используете Robocopy для файлов Azure, убедитесь, что вы монтируете общую папку Azure, используя ключ доступа к учетной записи хранения, а не доменное удостоверение. Если вы этого не сделали, сообщения об ошибках могут не интуитивно привести вас к решению проблемы.
/MIR (Зеркальный источник для целевого объекта.) Позволяет Robocopy копировать только разностные значения между источником и целевым объектом. Будут скопированы пустые подкаталоги. Элементы (файлы или папки), которые изменились или не существуют в целевом объекте, будут скопированы. Элементы, которые существуют на целевом объекте, но не в источнике, будут удалены (удалены) из целевого объекта. При использовании этого параметра, вам следует точно сопоставить структуры исходной и целевой папок. Сопоставление означает копирование с правильного уровня источника и папки на соответствующий уровень папки в целевом объекте. Только после этого может быть успешно выполнено создание копии "догоняющего" типа. Если исходный и целевой объекты не совпадают, использование /MIR приведет к крупномасштабным удалению и повторному копированию.
/IT Гарантирует, что точность сохраняется в определенных сценариях зеркального отображения.
Например, если файл испытывает изменение ACL и обновление атрибута между двумя запусками Robocopy, оно помечается скрытым. Без /IT этого изменение ACL может быть пропущено Robocopy и не передано в целевую папку.
/COPY:[copyflags] Точность копии файла. По умолчанию: /COPY:DAT. Флаги копирования: D= Данные, A= Атрибуты, T= метки времени, S= безопасность = списки управления доступом NTFS, O= сведения о владельце, U= сведенияо дитинге U. Сведения об аудите не могут храниться в общей папке Azure.
/DCOPY:[copyflags] Точность для копии каталогов. По умолчанию: /DCOPY:DA. Копировать флаги: D= Данные, A= Атрибуты, T= Метки времени.
/NP Указывает, что ход выполнения копирования для каждого файла и папки не будет отображаться. Отображение хода выполнения значительно снижает производительность копирования.
/NFL Указывает, что имена файлов не регистрируются. Улучшает производительность копирования.
/NDL Указывает, что имена каталогов не регистрируются. Улучшает производительность копирования.
/XD Указывает каталоги, которые следует исключить. При запуске Robocopy в корне тома рекомендуется исключить скрытую System Volume Information папку. При использовании по назначению вся информация в нем относится к точному объему на этой конкретной системе и может быть восстановлена по требованию. Копирование этих сведений не будет полезно в облаке или когда данные когда-либо копируются обратно в другой том Windows. Оставляя это содержимое позади, не следует рассматривать потерю данных.
/UNILOG:<file name> Записывает состояние в файл журнала в виде Юникода. (Перезаписывает существующий журнал.)
/L Только для тестового запуска
Файлы должны быть перечислены только. Они не будут скопированы, не удалены и не получат временных меток. Часто используется с /TEE для вывода на консоль. Флаги из примера скрипта, например /NP/NFL, и/NDL, возможно, потребуется удалить, чтобы обеспечить правильно документированные результаты теста.
/LFSM Только для целей с многоуровневой памятью. Не поддерживается, если назначение является удаленной общей папкой SMB.
Указывает, что Robocopy работает в "режиме низкого свободного пространства". Этот параметр полезен только для целевых объектов с многоуровневыми хранилищами, которые могут выйти из локальной емкости до завершения Robocopy. Она была добавлена специально для использования с целевым объектом, включенным для распределения по уровням в облаке службы "Синхронизация файлов Azure". Его можно использовать независимо от синхронизации файлов Azure. В этом режиме Robocopy приостанавливается всякий раз, когда копирование файла приведет к тому, что свободное пространство на целевом томе опустится ниже порогового значения. Это значение можно указать с помощью /LFSM:n формы флага. Параметр n указан в базе 2: nKBили nMBnGB. Если /LFSM задано без явного минимального значения, то минимальное значение установлено на 10 процентов от размера целевого тома. Режим низкого свободного места не совместим с /MT, /EFSRAWили /ZB. Поддержка /B была добавлена в Windows Server 2022. Дополнительные сведения о связанной ошибке и обходном пути см. в разделе Windows Server 2022 и RoboCopy LFSM ниже.
/Z Используйте осторожно
Копирует файлы в режиме перезапуска. Этот коммутатор рекомендуется использовать только в нестабильной сетевой среде. Это значительно снижает производительность копирования из-за дополнительного ведения журнала.
/ZB Используйте с осторожностью
Использует режим перезапуска. Если доступ запрещен, этот параметр использует режим резервного копирования. Этот параметр значительно снижает производительность копирования из-за проверки контрольных точек.

Важно

Рекомендуется использовать Windows Server 2022. При использовании Windows Server 2019 убедитесь, что установлен последний уровень исправлений или по крайней мере KB5005103 обновления ОС . Он содержит важные исправления для определенных сценариев Robocopy.

RoboCopy может сообщить о том, что файлы были скопированы даже при отсутствии необходимости передачи данных. Это происходит, так как robocopy оценивает как данные файлов, так и изменения метаданных при создании выходных данных. Чтобы правильно интерпретировать результаты, просмотрите состояние файла в выходных данных команды:

  • Новое: данные файлов копируются в пункт назначения.
  • Изменено: обновляется только метаданные; Данные файла не перезаписывайтся.

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

Этап 8. Переход пользователей на новую систему

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

Первым запуском является перемещение основной части данных в Windows Server и в облако с помощью службы "Синхронизация файлов Azure". Первая копия может занять много времени в зависимости от:

  • пропускная способность загрузки
  • пропускная способность передачи
  • скорость локальной сети и насколько оптимально количество потоков RoboCopy соответствует этой скорости.
  • количество элементов (файлов и папок), которые должны обрабатываться RoboCopy и синхронизацией файлов Azure

После завершения начального запуска выполните команду еще раз.

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

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

При рассмотрении допустимого времени простоя необходимо удалить доступ пользователей к общим папкам на основе NAS. Это можно сделать с помощью любых действий, которые препятствуют пользователям изменять структуру файлов и папок и содержимое. Пример: указать DFS-Namespace на несуществующее расположение; изменить корневые списки управления доступом на общей папке.

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

Создайте общую папку в папке Windows Server и, возможно, настройте DFS-N развертывание, чтобы указать на него. Не забудьте установить те же разрешения на уровне доступа, что и для NAS SMB. Если у вас есть присоединённый к домену корпоративный NAS, то идентификаторы пользователей (SID) будут автоматически совпадать, так как пользователи существуют в Active Directory, а RoboCopy копирует файлы и метаданные с полной точностью. Если вы использовали локальных пользователей в NAS, необходимо повторно создать этих пользователей в качестве локальных пользователей Windows Server и сопоставить существующие идентификаторы SIDs RoboCopy, перенесенные на Windows Server, с идентификаторами SID новых локальных пользователей Windows Server.

Вы завершили перенос сетевого ресурса или группы сетевых ресурсов в единую корневую папку или том. (В зависимости от сопоставления с этапа 1)

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

Предупреждение

После того как вы перенесли все данные с NAS на Windows Server и миграция завершена: Вернитесь ко всем группам синхронизации на портале Azure и измените значение процента свободного пространства тома для облачного репозиторирования на более подходящее для использования кэша, например, 20%.

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

Устранение неполадок

Наиболее вероятной проблемой является то, что команда RoboCopy завершается ошибкой "Переполненный том" на стороне Windows Server. Распределение по уровням в облаке действует один раз в час для эвакуирования содержимого с локального диска Windows Server, который синхронизирован. Цель состоит в том, чтобы достичь 99% свободного места на томе.

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

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

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

Дальнейшие шаги

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

  • Last updated on