Поделиться через

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

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

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

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

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

Применимо к

Тип общей папки SMB NFS
Стандартные общие папки (GPv2), LRS/ZRS Yes No
Стандартные общие папки (GPv2), GRS/GZRS Yes No
Файловые хранилища уровня "Премиум" (FileStorage), LRS/ZRS Yes No

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tip

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

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

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

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

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

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

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

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

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

Tip

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

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

Important

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

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

Important

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

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

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

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

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

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

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

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

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

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

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

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


Значок Excel, который задает контекст для скачивания. Скачайте шаблон сопоставления пространства имен.

Этап 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 на основе количества элементов (файлов и папок), которые необходимо синхронизировать.

Note

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Caution

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

Important

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

Warning

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

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

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

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

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

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

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

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

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

Если вы подготовили меньше хранилища на windows Server, чем файлы, берут на устройство NAS, то вы настроили распределение по уровням в облаке. По мере полного завершения локального тома Windows Server облачные уровни будут запускаться и файлы уровня, которые уже синхронизированы. Распределение по уровням в облаке создаст достаточно места для продолжения копирования с устройства 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 Meaning
/MT:n Позволяет Robocopy выполнять многопоточный режим. n Значение по умолчанию — 8. Максимальное значение — 128 потоков. Хотя большое количество потоков помогает насыщать доступную пропускную способность, это не означает, что миграция всегда будет быстрее с большим количеством потоков. Тесты с файлами Azure указывают от 8 до 20 показателей производительности для начального выполнения копирования. Последующие /MIR запуски постепенно влияют на доступные вычислительные ресурсы и доступную пропускную способность сети. Для последующих запусков более тесно соответствуют значению счетчика потоков и числу потоков процессора на ядро. Рассмотрите необходимость резервирования ядер для других задач, которые может иметь рабочий сервер. Тесты с помощью файлов Azure показали, что до 64 потоков создают хорошую производительность, но только если процессоры могут поддерживать их в живых одновременно.
/R:n Максимальное количество повторных попыток для файла, который не может копироваться при первой попытке. Robocopy попытается попробовать n время до окончательного копирования файла в ходе выполнения. Вы можете оптимизировать производительность выполнения: выберите значение двух или трех, если вы считаете, что проблемы с временем ожидания вызвали сбои в прошлом. Это может быть более распространено по ссылкам глобальной сети. Выберите не повторную попытку или значение одного, если вы считаете, что файл не удалось скопировать, так как он активно использовался. Попытка снова через несколько секунд может оказаться недостаточно времени для изменения состояния файла. Пользователям или приложениям, в течение открытых файлов может потребоваться больше времени. В этом случае принятие файла не было скопировано и перехватывает его в одном из запланированных, последующих запусков 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
Использует режим перезапуска. Если доступ запрещен, этот параметр использует режим резервного копирования. Этот параметр значительно снижает производительность копирования из-за контрольной точки.

Important

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

Этап 8. Вырезанный пользователем

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

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

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

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

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

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

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

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

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

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

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

Warning

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

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

Troubleshoot

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

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

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

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

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

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

  • Last updated on