Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
✔️ Область применения: классические общие папки SMB, созданные с помощью поставщика ресурсов Microsoft.Storage
✖️ Не применяется: все файловые ресурсы NFS, включая: файловые ресурсы, созданные с использованием поставщика ресурсов Microsoft.FileShares (предварительная версия), или классические файловые ресурсы, созданные с использованием поставщика ресурсов Microsoft.Storage
Эта статья о миграции — одна из нескольких, включающих ключевые слова NAS, Синхронизация файлов Azure и Azure Data Box. Проверьте, относится ли эта статья к вашему сценарию:
- Источник данных: запоминающее устройство, подключаемое к сети (NAS)
- Маршрут миграции: NAS ⇒ Data Box ⇒ Общая папка Azure ⇒ синхронизация с Windows Server
- Локальное кэширование файлов: да, конечная цель — развертывание службы "Синхронизация файлов Azure"
Если ваш сценарий отличается, ознакомьтесь с таблицей руководств по миграции.
Службу "Синхронизация файлов Azure" можно использовать в запоминающих устройствах, подключаемых напрямую (DAS). Синхронизация с расположениями сетевых хранилищ данных (NAS) не поддерживается. То есть потребуется перенести файлы. В этой статье описывается планирование и реализация такой миграции.
Цели миграции
Цель — перенести доли с устройства NAS на Windows Server. Затем следует использовать Синхронизацию файлов Azure для развертывания гибридного облака. Миграция должна быть выполнена таким образом, чтобы гарантировать целостность рабочих данных и их доступность во время миграции. Последнее означает сведение времени простоя к минимуму, чтобы оно равнялось регулярным окнам обслуживания или превышало их лишь незначительно.
Обзор миграции
Процесс миграции состоит из нескольких этапов. Вам понадобится:
- Разверните учетные записи службы хранения Azure и общие папки.
- Разверните локальный компьютер под управлением Windows Server.
- Настройте службу "Синхронизация файлов Azure".
- Выполните миграцию файлов с помощью средства Robocopy.
- Выполните переключение.
В следующих разделах все этапы процесса миграции описаны подробно.
Совет
Если вы вернулись к этой статье, используйте меню в правой части экрана, чтобы перейти к этапу миграции, на котором вы остановились.
Этап 1. Определение необходимого количества общих папок Azure
На этом шаге вы определяете, сколько файловых хранилищ Azure вам нужно. Один экземпляр Windows Server (или кластер) может синхронизировать до 30 общих папок Azure.
Тома могут содержать большее количество папок, к которым вы в настоящее время предоставляете локальный доступ как к общим папкам SMB пользователям и приложениям. Самый простой способ представить этот сценарий — вообразить локальную папку, которая совпадает 1:1 с файловой общей папкой Azure. Если у вас достаточно малое количество общих ресурсов, меньше 30 для одного экземпляра Windows Server, рекомендуется сопоставление 1:1.
Если используется более 30 общих папок, зачастую сопоставление 1:1 между локальной общей папкой и общей папкой Azure не является обязательным. Следуйте приведенным ниже рекомендациям.
Группировка долей
Например, если у отдела кадров (HR) 15 общих папок, возможно, стоит хранить все данные HR в одной общей папке Azure. Хранение нескольких локальных общих папок в одной общей папке Azure не мешает создать 15 обычных общих папок SMB на локальном экземпляре Windows Server. Это лишь означает, что корневые папки этих 15 общих папок должны представлять собой вложенные папки в составе общей папки. Затем выполняется синхронизация этой общей папки с общей папкой Azure. Таким образом, для этой группы локальных общих папок требуется только один файловый ресурс Azure в облаке.
Синхронизация томов
Azure File Sync поддерживает синхронизацию корневого каталога тома с общей папкой Azure. При синхронизации корневого каталога тома все вложенные папки и файлы отправляются в одно файловое хранилище Azure.
Синхронизация корня тома не всегда представляет собой лучшее решение. Синхронизация нескольких расположений имеет свои преимущества. Например, она позволяет сократить количество элементов в одной области синхронизации. Тестирование общих папок Azure и службы синхронизации файлов Azure выполняется при 100 миллионах элементов (файлов и папок) в одной общей папке. Однако рекомендуется стараться держать число не более 20–30 миллионов в одной акции.
Настройка Синхронизации файлов Azure с меньшим количеством элементов выгодна не только для синхронизации файлов. Уменьшение количества элементов также полезно в перечисленных ниже сценариях.
- Начальное сканирование содержимого облака может завершиться быстрее, что, в свою очередь, сокращает время ожидания появления пространства имен на сервере с включенной функцией синхронизации файлов Azure.
- Облачное восстановление из моментального снимка файла общего доступа Azure происходит быстрее.
- Аварийное восстановление локального сервера может существенно ускориться.
- Изменения, внесенные непосредственно в общую папку Azure (вне синхронизации), могут быть обнаружены и синхронизированы быстрее.
Совет
Если вы не знаете, сколько файлов и папок у вас есть, ознакомьтесь со средством TreeSize из JAM Software.
Структурированный подход к карте развертывания
Перед развертыванием облачного хранилища на более позднем этапе необходимо создать сопоставление между локальными папками и общими папками Azure. Это сопоставление указывает, сколько и какие ресурсы группы синхронизации файлов Azure вы подготовите. Группа синхронизации связывает общую папку Azure и папку на сервере и устанавливает соединение для синхронизации.
Чтобы оптимизировать карту и решить, сколько общих папок Azure требуется, ознакомьтесь со следующими ограничениями и рекомендациями.
Сервер, на котором установлен агент Синхронизации файлов Azure, может выполнить синхронизацию с 30 общими папками Azure.
Файловое хранилище Azure развернуто в учетной записи хранения. Это делает учетную запись хранения целевым объектом масштабирования для таких показателей производительности, как операции ввода-вывода в секунду и пропускная способность.
Обратите внимание на ограничения IOPS учетной записи хранения при развертывании файловых хранилищ Azure. В идеале следует сопоставить файловые ресурсы 1:1 с учетными записями хранения. Однако это сопоставление может не всегда быть возможным из-за различных ограничений и лимитов, как из вашей организации, так и из Azure. Если вы не можете развернуть только один файловый ресурс в одной учетной записи хранения, рассмотрите, какие общие папки будут очень активными и какие общие папки будут менее активными. Не помещайте самые горячие общие папки в одну учетную запись хранения.
Если вы планируете перенести в Azure приложение, которое будет использовать общую папку Azure непосредственно, возможно, вам понадобится более высокая производительность этой общей папки. Если такой тип использования возможен (пусть даже в будущем), рекомендуется создать одну стандартную общую папку Azure в собственной учетной записи хранения.
Одна подписка в одном регионе Azure может содержать не более 250 учетных записей хранения.
Совет
На основе этой информации часто необходимо сгруппировать несколько папок верхнего уровня на томах в новый общий корневой каталог. Затем вы синхронизируете этот новый корневой каталог и все папки, сгруппированные в него, в одну общую папку Azure. Эта методика позволяет не превышать ограничения по количеству синхронизаций общих папок Azure на одном сервере (не более 30).
Такое группирование в общем корне не влияет на доступ к вашим данным. Списки управления доступом остаются неизменными. Вам нужно настроить только те пути общего доступа (например, SMB или NFS общие папки), которые вы, возможно, имели в локальных папках сервера, теперь преобразованных в общий корневой каталог. Больше ничего не меняется.
Внимание
Самое важное направление масштабирования для Синхронизации файлов Azure — число элементов (файлов и папок), которые необходимо синхронизировать. Дополнительные сведения см. в целевых объектах масштабирования синхронизации файлов Azure .
В вашей ситуации набор папок может логически синхронизироваться с той же общей папкой Azure (используя общий корневой подход, упомянутый ранее). Но может быть лучше перегруппировать папки, чтобы они синхронизирулись с двумя общими папками Azure вместо одного. Вы можете использовать этот метод для поддержания баланса количества файлов и папок на файловой доле сервера. Вы также можете разделить локальные общие папки и синхронизировать их между несколькими локальными серверами, чтобы добавить возможность синхронизации с 30 дополнительными файловыми ресурсами Azure на дополнительный сервер.
Внимание
Самое важное направление масштабирования для Синхронизации файлов Azure — число элементов (файлов и папок), которые необходимо синхронизировать. Дополнительные сведения см. в целевых объектах масштабирования синхронизации файлов Azure.
Распространенные сценарии синхронизации файлов и рекомендации
| Сценарий синхронизации | Поддерживается | Рекомендации (или ограничения) | Решение (или обходное решение) |
|---|---|---|---|
| Файловый сервер с несколькими дисками и томами и несколькими общими папками в одной целевой общей папке Azure (консолидация) | Нет | Целевая файловая папка Azure (конечная точка облака) поддерживает синхронизацию только с одной группой синхронизации. Группа синхронизации поддерживает только одну конечную точку сервера на зарегистрированный сервер. |
1. Начните с синхронизации одного диска (корневого тома) с целевой файловой папкой Azure. Начиная с самого большого диска или тома, вы сможете выполнить требования к хранилищу в локальной среде. Настройте облачное распределение по уровням, чтобы переместить все данные в облако и освободить место на диске файлового сервера. Перемещайте данные из других томов или общих папок в текущий том, который синхронизируется. Продолжайте шаги последовательно до тех пор, пока все данные не будут загружены в облако или перенесены. 2) Фокусируйтесь на одном корневом томе (диске) за один раз. Используйте распределение по уровням облака для распределения всех данных в целевую общую папку Azure. Удалите конечную точку сервера из группы синхронизации, повторно создайте конечную точку со следующим корневым томом или диском, синхронизируйте и повторите процесс. Обратите внимание, что может потребоваться переустановить агент. 3. Рекомендуется использовать несколько целевых общих папок Azure (одну или другую учетную запись хранения в зависимости от требований к производительности). |
| Файловый сервер с одним томом и несколькими общими ресурсами для одной целевой общей папки Azure (консолидация) | Да | Невозможно иметь несколько конечных точек сервера на зарегистрированном сервере, синхронизирующихся с одним и тем же целевым файловым хранилищем Azure (аналогично предыдущему сценарию). | Синхронизируйте корневой каталог тома, в котором хранятся несколько общих папок или папок верхнего уровня. |
| Файловый сервер с несколькими общими папками и (или) томами для нескольких общих папок Azure в рамках одной учетной записи хранения (сопоставление общих папок 1:1) | Да | Один экземпляр Windows Server (или кластер) может синхронизировать до 30 общих папок Azure. Учетная запись хранения — это целевой объект масштабирования для производительности. IOPS и пропускная способность распределяются между файловыми ресурсами. Сохраняйте количество элементов для каждой группы синхронизации в пределах 100 миллионов элементов (файлов и папок) на общую папку. Лучше всего остаться ниже 20 или 30 миллионов на акцию. |
1) Использование нескольких групп синхронизации (число групп синхронизации = количество общих папок Azure для синхронизации). 2) В этом сценарии можно синхронизировать только 30 единиц. Если на файловом сервере более 30 общих папок, используйте группирование ресурсов и синхронизацию томов, чтобы уменьшить количество корневых или верхнеуровневых папок на исходном сервере. 3) Используйте дополнительные локальные серверы синхронизации файлов Azure и разделите или переместите данные на эти серверы, чтобы обойти ограничения в исходном экземпляре Windows Server. |
| Файловый сервер с несколькими общими папками и (или) томами для нескольких общих папок Azure в другой учетной записи хранения (сопоставление общих папок 1:1) | Да | Один экземпляр Windows Server (или кластер) может синхронизировать до 30 общих папок Azure (одной или другой учетной записи хранения). Сохраняйте количество элементов для каждой группы синхронизации в пределах 100 миллионов элементов (файлов и папок) на общую папку. Лучше всего остаться ниже 20 или 30 миллионов на акцию. |
Аналогично предыдущему подходу. |
| Несколько файловых серверов с одним корневым томом или общим ресурсом для одной целевой общей папки Azure (консолидация) | Нет | Группа синхронизации не может использовать облачную конечную точку (общую папку Azure), которая уже настроена в другой группе синхронизации. Хотя группа синхронизации может иметь конечные точки сервера на разных файловых серверах, файлы не могут отличаться. |
Следуйте указаниям в первом сценарии, дополнительно уделяя внимание нацеливанию на один файловый сервер поочерёдно. |
| Топология между арендаторами (использование управляемой идентичности в разных арендаторах) | Нет | Служба синхронизации хранилища, ресурс сервера (сервер с поддержкой Azure Arc или виртуальная машина Azure), управляемое удостоверение и назначения RBAC в учетной записи хранения должны находиться в одном клиенте Microsoft Entra. Топологии между клиентами не поддерживаются. | Настройка для нескольких арендаторов не проходит проверку подлинности и авторизации, и сервер не может подключиться. Чтобы продолжить, убедитесь, что все ресурсы (служба синхронизации, сервер, управляемое удостоверение и назначения RBAC) созданы внутри одного клиента Microsoft Entra. |
Создание таблицы сопоставления
Воспользуйтесь приведенной выше информацией, чтобы определить, сколько общих папок Azure вам нужно и какие элементы существующих данных в каких общих папках Azure окажутся.
Создайте таблицу, которая записывает свои мысли, чтобы вы могли ссылаться на нее, когда нужно. Сохранение организованности важно, поскольку легко потерять сведения о плане сопоставления, когда вы подготавливаете многие ресурсы Azure одновременно.
Этап 2. Развертывание ресурсов хранилища Azure
На этом этапе просмотрите таблицу сопоставления из этапа 1 и используйте ее для подсчета правильного числа учетных записей хранения Azure и файловых ресурсов в них.
Общая папка Azure хранится в облаке в учетной записи хранения Azure. Здесь применяется еще один уровень рекомендаций по производительности.
При наличии очень активных общих папок (общих папок, используемых несколькими пользователями и (или) приложениями) производительность двух общих папок Azure может достичь предельного значения для учетной записи хранения.
Рекомендуется развертывать учетные записи хранения с одной общей папкой в каждой. Использовать несколько общих папок Azure в одной учетной записи хранения можно в том случае, если у вас имеются архивные общие папки или же уровень повседневной активности в них будет низким.
Эти рекомендации, скорее, касаются прямого облачного доступа (через виртуальную машину Azure), чем службы "Синхронизация файлов Azure". Если вы планируете использовать службу "Синхронизация файлов Azure" только в этих общих папках, группирование нескольких файлов в одну учетную запись хранения Azure вполне подойдет.
Если вы составили список своих ресурсов, сопоставьте каждый из них с учетной записью хранения, в которой он будет размещен.
На предыдущем этапе вы определили соответствующее количество акций. На данном этапе вы создали сопоставление учетных записей хранения с общими папками. Теперь разверните соответствующее количество учетных записей хранения Azure, содержащих соответствующее количество общих папок Azure.
Проследите за тем, чтобы все учетные записи хранения относились к одному региону, совпадающему с регионом уже развернутого ресурса службы синхронизации хранилища.
Внимание
Если вы создадите общую папку Azure с ограничением в 100 ТиБ, она сможет использовать только параметры избыточности "Локально избыточное хранилище" или "Хранилище, избыточное между зонами". Рассмотрите ваши потребности в избыточной емкости данных перед использованием файловых хранилищ размером 100 TiB.
По умолчанию общие папки Azure создаются с ограничением в 5 ТиБ. Следуйте шагам в разделе Создание файлового ресурса Azure, чтобы создать большую файлообменную папку.
Еще один вопрос, который следует учитывать при развертывании учетной записи хранения, — избыточность службы хранилища Azure. См. статью Варианты избыточности хранилища Azure.
Имена ресурсов также важны. Например, при группировании нескольких дисковых ресурсов для отдела кадров в учетную запись хранения Azure, этой учетной записи следует присвоить соответствующее имя. Точно так же файловым хранилищам Azure следует присваивать имена, аналогичные тем, которые используются для их локальных аналогов.
Этап 3. Определение необходимого количества устройств Azure Data Box
Этот шаг следует выполнять только после завершения предыдущего этапа. Здесь вам нужно будет создать ресурсы хранилища Azure (учетные записи хранения и общие папки). При заказе Data Box необходимо указать учетные записи хранения, в которые Data Box перемещает данные.
На этом этапе вам нужно соотнести результаты плана миграции из предыдущего этапа с ограничениями доступных параметров Data Box. Эти рекомендации помогут вам составить план — понять, какие параметры Data Box стоит выбрать и сколько из них потребуется вам для того, чтобы переместить общие папки NAS в общие папки Azure.
Чтобы определить, сколько устройств и какого типа вам нужно, учтите следующие важные ограничения.
- Любое устройство Azure Data Box позволяет перемещать данные в 10 учетных записей хранения.
- Каждый вариант Data Box поставляется с собственной доступной емкостью. См. опции Data Box.
Проверьте по своему плану миграции, сколько учетных записей хранения вы решили создать и сколько общих папок должно быть в каждой из них. Затем посмотрите на размер каждого сетевого ресурса на вашем NAS. Объединение этих сведений позволит вам оптимизировать выбранные параметры и решить, какое устройство должно отправлять данные в учетные записи хранения. Два устройства Data Box могут переместить файлы в одну и ту же учетную запись хранения, но разделять содержимое одной общей папки между двумя устройствами Data Box нельзя.
Варианты Data Box
Для стандартной миграции необходимо выбрать один или несколько из этих вариантов Data Box:
- Диск Data Box. Майкрософт отправит вам от одного до пяти дисков SSD по 8 ТиБ каждый, в результаты чего вы получите до 40 ТиБ. Реальный объем будет меньше примерно на 20 % из-за издержек на шифрование и файловую систему. Дополнительные сведения см. в документации по Data Box Disk.
- Data Box. Этот параметр является наиболее распространенным. Майкрософт отправит вам защищенное устройство Data Box, которое работает почти так же, как NAS. Его полезная емкость составляет 80 ТиБ. Дополнительные сведения см. в документации по Data Box.
- Data Box Heavy. Этот вариант включает устройство Data Box на колесах в усиленном исполнении, работающее как сетевое хранилище (NAS). Устройство имеет емкость 1 ПиБ. Реальный объем будет меньше примерно на 20 % из-за издержек на шифрование и файловую систему. Дополнительные сведения см. в документации по Data Box Heavy.
Этап 4. Подготовка подходящего локального экземпляра Windows Server
Пока вы ожидаете прибытия устройств Azure Data Box, ознакомьтесь с требованиями для одного или нескольких экземпляров Windows Server, которые будут использоваться со службой "Синхронизация файлов Azure".
- Создайте экземпляр Windows Server 2022 (как минимум, Windows Server 2012 R2) в качестве виртуальной машины или физического сервера. Поддерживается также кластер отказоустойчивости Windows Server.
- Подготовьте к работе или добавьте прямо подключённое хранилище. NAS не поддерживается.
Конфигурация ресурсов (вычислительных и ОЗУ) развертываемого экземпляра Windows Server зависит главным образом от количества элементов (файлов и папок), которые будут синхронизироваться. При наличии каких-либо проблем рекомендуется использовать более высокую конфигурацию производительности.
Примечание.
В статье, ссылка на которую представлена выше, содержится таблица диапазонов памяти (ОЗУ) сервера. Числа можно использовать в нижней границе диапазона для сервера, однако предполагается, что первоначальная синхронизация будет выполняться значительно дольше.
Этап 5. Копирование файлов на устройство Data Box
Когда ваш Data Box прибудет, следует настроить его с бесперебойным сетевым подключением к устройству NAS. Следуйте инструкциям в документации по установке для того типа устройства Data Box, который вы заказали:
В зависимости от типа Data Box могут быть доступны инструменты копирования Data Box. На этом этапе мы не рекомендуем использовать их для миграции в общие папки Azure, так как они не копируют файлы в Data Box с полной точностью. Вместо этого используйте Roboсopy.
Когда вы получите свое устройство Data Box, оно будет содержать уже подготовленные общие папки SMB, доступные для каждой учетной записи хранения, указанной во время заказа.
- Если файлы попадают в общую папку SSD Azure, для каждой учетной записи хранения SSD "Хранилище файлов" будет один общий ресурс SMB.
- Если файлы попадают в учетную запись HDD, она будет содержать три общих ресурса SMB для хранения с оплатой по мере использования. Для миграции важны только общие папки, которые заканчиваются на
_AzFiles. Игнорируйте все общие папки блочных и страничных BLOB-объектов.
Выполните действия, описанные в документации по Azure Data Box:
- Подключение к Data Box.
- Копирование данных в Data Box.
Вы можете использовать Robocopy (следуйте инструкциям ниже) или новую службу копирования данных Data Box. - Подготовьте Data Box для загрузки в Azure.
Совет
В качестве альтернативы Robocopy в Data Box создана служба копирования данных. Эту службу можно использовать для загрузки файлов в Data Box с полной точностью. Следуйте указаниям в этом руководстве, посвященному службе копирования данных, и убедитесь, что задан правильный целевой объект общей папки Azure.
В документации Data Box указана команда Roboсopy. Эта команда не подходит для сохранения полной целостности файлов и папок. Вместо нее используйте эту команду:
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>
| Коммутатор | Значение |
|---|---|
/MT:n |
Разрешает выполнение Robocopy в многопоточном режиме. По умолчанию параметр n имеет значение 8. Максимум — 128 потоков. Хотя большое количество потоков помогает насытить доступную пропускную способность, это не означает, что ваша миграция всегда будет быстрее с большим количеством потоков. Тесты с Azure Files показывают, что диапазон от 8 до 20 обеспечивает сбалансированную производительность для первичного выполнения копирования. На последующие запуски /MIR постепенно оказывают влияние доступные вычислительные мощности и доступная пропускная способность сети. Для последующих запусков указываемое количество потоков нужно привести в соответствие с числом ядер процессора и количеством потоков, приходящихся на каждое ядро. Определите, нужно ли зарезервировать ядра для других задач рабочего сервера. Тесты с Azure Files показали, что 64 потока обеспечивают хорошую производительность, но только если процессоры могут поддерживать их одновременно. |
/R:n |
Максимальное число повторных попыток для файла, который не удалось скопировать с первого раза. Robocopy повторит попытку определенное количество раз (n), после чего объявит невозможность скопировать этот файл во время этого выполнения. Вы можете оптимизировать производительность выполнения: выберите значение "2" или "3", если вы считаете, что проблемы с истечением времени ожидания вызывали сбои в прошлом. Это может быть типичной проблемой для связи по каналам WAN. Выберите вариант "Без повторных попыток" или значение "1", если вы считаете, что файл не удалось скопировать, так как он активно использовался. Попытка снова через несколько секунд не всегда достаточно, чтобы состояние использования файла изменилось. Возможно, пользователям или приложениям, которые удерживают этот файл открытым, потребуется больше времени. В этом случае, если принять тот факт, что файл не был скопирован, и попытаться скопировать его в одном из следующих запланированных запусков Robocopy, это может привести к успешному копированию файла. В этом случае текущее выполнение завершится быстрее, без затрат времени на повторные попытки, которые все равно в большинстве случаев завершаются сбоем копирования из-за того, что файлы остаются открытыми по истечении времени ожидания повторных попыток. |
/W:n |
Указывает время ожидания Robocopy перед попыткой копирования файла, который не был успешно скопирован во время предыдущей попытки.
n — это количество секунд ожидания между повторными попытками.
/W:n часто используется вместе с /R:n. |
/B |
Выполняет команду Robocopy в том же режиме, что и приложение резервного копирования. Этот параметр позволяет Robocopy перемещать файлы, для которых у текущего пользователя нет разрешений. Переключатель резервного копирования зависит от запуска команды Robocopy в консоли с правами администратора или в окне PowerShell. Если вы используете Robocopy для работы с Azure Files, убедитесь, что вы подключаете общую папку Azure с помощью ключа доступа к учетной записи хранилища, а не удостоверения домена. В противном случае сообщения об ошибках могут не позволить найти очевидное решение проблемы. |
/MIR |
(Зеркалирование источника в целевой объект.) Позволяет Robocopy копировать только различия между исходным и целевым объектами. Будут скопированы пустые подкаталоги. Элементы (файлы или папки), которые были изменены или не существуют в целевой папке, будут скопированы. Элементы, которые существуют в целевой системе, но не в источнике, будут удалены из цели. При использовании этого параметра структуры исходной и целевой папок должны соответствовать друг другу.
Соответствие означает, что вы выполняете копирование с правильного уровня источника и папки на соответствующий уровень папки в целевом объекте. Только тогда "догоняющее копирование" будет успешным. Если объекты источника и назначения не совпадают, использование /MIR приведет к увеличению числа операций удаления и повторного копирования. |
/IT |
Обеспечивает сохранение точности данных в определенных зеркальных сценариях.
Например, если в файле происходит изменение ACL и между двумя выполнениями Robocopy обновляется атрибут, он помечается как скрытый. Без параметра /IT команда Robocopy может упустить изменение ACL и не передать его в целевое расположение. |
/COPY:[copyflags] |
Точность копирования файла. По умолчанию: /COPY:DAT. Флаги копирования: D = данные, A = атрибуты, T = метки времени, S = безопасность = NTFS ACLs, O = информация о владельце, 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 File Sync. В этом режиме Robocopy будет приостанавливаться всякий раз, когда копирование файла приводит к тому, что свободное место на целевом томе опустится ниже предельного значения. Это значение может быть задано в форме /LFSM:n флага. Параметр n указывается в двоичной системе счисления: nKB, nMB или nGB. Если параметр /LFSM указан без явного значения floor, для него устанавливается значение 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 может сообщать о числах байтов, как будто данные были переданы. Это поведение может привести к путанице при проверке операций копирования.
Этап 6. Развертывание облачного ресурса службы синхронизации файлов Azure
Прежде чем продолжить работу с этим руководством, дождитесь, пока все файлы не поступят в соответствующие общие папки Azure. Процесс доставки и обработки данных Data Box займет некоторое время.
На этом шаге вам понадобятся учетные данные подписки Azure.
Основной ресурс, который необходимо настроить для службы Синхронизации файлов Azure, называется службой синхронизации хранилища. Рекомендуется развертывать только одну службу для всех серверов, которые выполняют синхронизацию одного и того же набора файлов сейчас или в будущем. Создавать несколько служб синхронизации хранилища следует, только если имеются отдельные наборы серверов, которые ни в коем случае не должны обмениваться данными. Например, у вас могут быть серверы, которые ни в коем случае не должны выполнять синхронизацию одной и той же общей папки Azure. В противном случае рекомендуется использовать одну службу синхронизации хранилища.
Выберите для службы синхронизации хранилища регион Azure, находящийся ближе к вашему расположению. Все остальные облачные ресурсы должны развертываться в том же регионе. Чтобы упростить управление, создайте новую группу ресурсов в своей подписке для размещения ресурсов синхронизации и хранения.
Дополнительные сведения см. в разделе о развертывании службы синхронизации хранилища статьи о развертывании службы Синхронизации файлов Azure. Вам понадобится только этот раздел статьи. На следующих этапах будут приведены ссылки на другие разделы статьи.
Этап 7. Развертывание агента службы "Синхронизация файлов 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 должна выполнять обмен данными в выбранном регионе. Отчет также содержит причину, по которой требуется обмен данными. Отчет можно использовать для блокировки брандмауэров этого сервера по конкретным URL-адресам.
Можно также придерживаться более консервативного подхода, при котором брандмауэры не открываются широко. Вместо этого можно установить для сервера ограничение, допускающее обмен данными только с пространствами имен DNS более высокого уровня. Дополнительные сведения см. в разделе Параметры прокси-сервера и брандмауэра Синхронизации файлов Azure. Следуйте собственным лучшим методикам реализации сети.
По окончании работы мастера установки сервера откроется мастер регистрации сервера. Зарегистрируйте сервер в ресурсе Azure службы синхронизации хранилища, упомянутой ранее.
Эти действия подробно описаны в руководстве по развертыванию, включающем модули PowerShell, которые следует установить в первую очередь: Установка агента Синхронизации файлов Azure.
Используйте последнего агента. Его можно скачать в Центре загрузки Майкрософт: Агент Синхронизации файлов Azure.
После успешной установки и регистрации сервера можно проверить, успешно ли завершен этот шаг. Перейдите к ресурсу службы синхронизации хранилища на портале Azure. В меню слева выберите пункт Зарегистрированные серверы. Вы увидите ваш сервер в списке.
Этап 8. Настройка службы синхронизации файлов Azure на экземпляре Windows Server
Зарегистрированный локальный экземпляр Windows Server должен быть готов к работе и подключен к Интернету для этого процесса.
На этом этапе выполняется связывание всех ресурсов и папок, настроенных на экземпляре Windows Server в ходе выполнения предыдущих этапов.
- Войдите на портал Azure.
- Найдите ресурс службы синхронизации хранилища.
- Создайте новую группу синхронизации в ресурсе службы синхронизации хранилища для каждой общей папки Azure. В терминологии Синхронизации файлов Azure общая папка Azure станет облачной конечной точкой в топологии синхронизации, которую вы описываете при создании группы синхронизации. При создании группы синхронизации присвойте ей знакомое имя, чтобы определить, какой набор файлов будет здесь синхронизироваться. Убедитесь, что вы ссылаетесь на общую папку Azure с таким же именем.
- После создания группы синхронизации в списке групп синхронизации появится строка для нее. Выберите имя (ссылку), чтобы показать содержимое группы синхронизации. Вы увидите вашу файловую долю Azure в разделе Облачные конечные точки.
- Найдите кнопку Добавить конечную точку сервера. Подготовленная вами папка на вашем локальном сервере станет маршрутом для этой конечной точки сервера.
Включите функцию распределения по уровням в облаке и выберите параметр Только пространство имен в разделе начальной загрузки.
Внимание
Распределение по уровням в облаке — это функция Синхронизации файлов Azure, которая позволяет выделять локальному серверу меньший объем хранилища, чем объем ресурсов в облаке, но при этом использовать полное пространство имен. Локальные интересующие данные также кэшируются локально для повышения производительности доступа. Распределение по уровням в облаке является необязательным. Его можно задать отдельно для каждой конечной точки сервера Синхронизации файлов Azure. Эту функцию необходимо использовать, если в экземпляре Windows Server недостаточно места для хранения всех облачных данных и вы хотите избежать загрузки всех данных из облака.
Для всех общих папок Azure и серверных расположений, которые необходимо настроить для синхронизации, повторите эти действия, чтобы создать группы синхронизации и добавить соответствующие серверные папки в качестве конечных точек сервера. Дождитесь завершения синхронизации пространства имен. В следующем разделе объясняется, как можно убедиться в том, что синхронизация завершена.
Примечание.
После создания конечной точки сервера синхронизация работает. При этом служба синхронизации должна перечислить (обнаружить) файлы и папки, перемещенные с помощью Data Box в общую папку Azure. В зависимости от размера пространства имен может пройти много времени, прежде чем пространство имен из облака отобразится на сервере.
Этап 9. Ожидание полного отображения пространства имен на сервере
Перед тем как приступить к следующим этапам миграции, дождитесь, пока сервер полностью не загрузит пространство имен из облачного общего ресурса. Если вы начнете перемещать файлы на сервер слишком рано, это может привести к избыточным загрузкам и даже к конфликтам синхронизации файлов.
Чтобы определить, завершил ли сервер начальную синхронизацию загрузки, откройте "Просмотр событий" на экземпляре синхронизации Windows Server и используйте журнал событий телеметрии в службе "Синхронизация файлов Azure". Журнал событий телеметрии хранится в компоненте "Просмотр событий", в папке "Приложения и службы\Microsoft\FileSync\Agent".
Найдите последнее событие 9102.
После завершения сеанса синхронизации регистрируется событие с идентификатором 9102. В тексте события есть поле для направления синхронизации загрузки. (HResult должно быть равно нулю, и необходимо загрузить файлы).
Вы хотите увидеть два следующих друг за другом события этого типа с таким содержимым, чтобы убедиться, что сервер завершил скачивание пространства имен. Допускается наличие других событий между двумя событиями 9102.
Этап 10. Запуск Robocopy из NAS
К этому шагу можно приступать после того, как сервер завершит первоначальную синхронизацию всего пространства имен из общей папки в облаке. Прежде чем продолжить выполнение этого шага, необходимо завершить первоначальную синхронизацию. Подробности см. в предыдущем разделе.
На этом этапе вы выполните задания Robocopy, чтобы синхронизировать общие папки в облаке и отразить в них последние изменения, внесенные в NAS с момента переноса общих папок на Data Box. Выполнение Robocopy может завершиться быстро или занять какое-то время в зависимости от объема изменений в общих папках NAS.
Предупреждение
Из-за регрессии в поведении Robocopy в Windows Server 2019 параметр /MIR Robocopy несовместим с иерархическими целевыми каталогами. Для этого этапа миграции не следует использовать клиент Windows Server 2019 или Windows 10. Используйте Robocopy на промежуточном экземпляре Windows Server 2016.
Далее описывается базовый способ миграции:
- Запустите Robocopy на устройстве NAS, чтобы синхронизировать экземпляр Windows Server.
- Используйте службу "Синхронизация файлов Azure" для синхронизации файловых ресурсов Azure с Windows Server.
Запустите первое локальное копирование в целевой папке Windows Server:
- Определите первое расположение на устройстве NAS.
- Определите соответствующую папку на экземпляре Windows Server, на котором уже настроена Синхронизация файлов Azure.
- Начните копирование с помощью Robocopy.
Следующая команда Robocopy скопирует только различия (обновленные файлы и папки) из хранилища NAS в целевую папку на сервере Windows. Затем экземпляр Windows Server синхронизирует их с общими папками Azure.
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>
| Коммутатор | Значение |
|---|---|
/MT:n |
Разрешает выполнение Robocopy в многопоточном режиме. По умолчанию параметр n имеет значение 8. Максимум — 128 потоков. Хотя большое количество потоков помогает насытить доступную пропускную способность, это не означает, что ваша миграция всегда будет быстрее с большим количеством потоков. Тесты с Azure Files показывают, что диапазон от 8 до 20 обеспечивает сбалансированную производительность для первичного выполнения копирования. На последующие запуски /MIR постепенно оказывают влияние доступные вычислительные мощности и доступная пропускная способность сети. Для последующих запусков указываемое количество потоков нужно привести в соответствие с числом ядер процессора и количеством потоков, приходящихся на каждое ядро. Определите, нужно ли зарезервировать ядра для других задач рабочего сервера. Тесты с Azure Files показали, что 64 потока обеспечивают хорошую производительность, но только если процессоры могут поддерживать их одновременно. |
/R:n |
Максимальное число повторных попыток для файла, который не удалось скопировать с первого раза. Robocopy повторит попытку определенное количество раз (n), после чего объявит невозможность скопировать этот файл во время этого выполнения. Вы можете оптимизировать производительность выполнения: выберите значение "2" или "3", если вы считаете, что проблемы с истечением времени ожидания вызывали сбои в прошлом. Это может быть типичной проблемой для связи по каналам WAN. Выберите вариант "Без повторных попыток" или значение "1", если вы считаете, что файл не удалось скопировать, так как он активно использовался. Попытка снова через несколько секунд не всегда достаточно, чтобы состояние использования файла изменилось. Возможно, пользователям или приложениям, которые удерживают этот файл открытым, потребуется больше времени. В этом случае, если принять тот факт, что файл не был скопирован, и попытаться скопировать его в одном из следующих запланированных запусков Robocopy, это может привести к успешному копированию файла. В этом случае текущее выполнение завершится быстрее, без затрат времени на повторные попытки, которые все равно в большинстве случаев завершаются сбоем копирования из-за того, что файлы остаются открытыми по истечении времени ожидания повторных попыток. |
/W:n |
Указывает время ожидания Robocopy перед попыткой копирования файла, который не был успешно скопирован во время предыдущей попытки.
n — это количество секунд ожидания между повторными попытками.
/W:n часто используется вместе с /R:n. |
/B |
Выполняет команду Robocopy в том же режиме, что и приложение резервного копирования. Этот параметр позволяет Robocopy перемещать файлы, для которых у текущего пользователя нет разрешений. Переключатель резервного копирования зависит от запуска команды Robocopy в консоли с правами администратора или в окне PowerShell. Если вы используете Robocopy для работы с Azure Files, убедитесь, что вы подключаете общую папку Azure с помощью ключа доступа к учетной записи хранилища, а не удостоверения домена. В противном случае сообщения об ошибках могут не позволить найти очевидное решение проблемы. |
/MIR |
(Зеркалирование источника в целевой объект.) Позволяет Robocopy копировать только различия между исходным и целевым объектами. Будут скопированы пустые подкаталоги. Элементы (файлы или папки), которые были изменены или не существуют в целевой папке, будут скопированы. Элементы, которые существуют в целевой системе, но не в источнике, будут удалены из цели. При использовании этого параметра структуры исходной и целевой папок должны соответствовать друг другу.
Соответствие означает, что вы выполняете копирование с правильного уровня источника и папки на соответствующий уровень папки в целевом объекте. Только тогда "догоняющее копирование" будет успешным. Если объекты источника и назначения не совпадают, использование /MIR приведет к увеличению числа операций удаления и повторного копирования. |
/IT |
Обеспечивает сохранение точности данных в определенных зеркальных сценариях.
Например, если в файле происходит изменение ACL и между двумя выполнениями Robocopy обновляется атрибут, он помечается как скрытый. Без параметра /IT команда Robocopy может упустить изменение ACL и не передать его в целевое расположение. |
/COPY:[copyflags] |
Точность копирования файла. По умолчанию: /COPY:DAT. Флаги копирования: D = данные, A = атрибуты, T = метки времени, S = безопасность = NTFS ACLs, O = информация о владельце, 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 File Sync. В этом режиме Robocopy будет приостанавливаться всякий раз, когда копирование файла приводит к тому, что свободное место на целевом томе опустится ниже предельного значения. Это значение может быть задано в форме /LFSM:n флага. Параметр n указывается в двоичной системе счисления: nKB, nMB или nGB. Если параметр /LFSM указан без явного значения floor, для него устанавливается значение 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 может сообщать о числах байтов, как будто данные были переданы. Это поведение может привести к путанице при проверке операций копирования.
RoboCopy может сообщить о том, что файлы были скопированы даже при отсутствии необходимости передачи данных. Это происходит, так как robocopy оценивает как данные файлов, так и изменения метаданных при создании выходных данных. Чтобы правильно интерпретировать результаты, просмотрите состояние файла в выходных данных команды:
- Новое: данные файлов копируются в пункт назначения.
- Изменено: обновляется только метаданные; Данные файла не перезаписывайтся.
В обоих случаях RoboCopy может сообщать о числах байтов, как будто данные были переданы. Это поведение может привести к путанице при проверке операций копирования.
Если вы подготовили на сервере Windows Server меньше места, чем занимают файлы на устройстве NAS, вы настроили распределение по уровням облака. По мере заполнения локального тома Windows Server будет запущено распределение по уровням в облаке, и синхронизированные файлы будут распределены по уровням. Распределение по уровням облака создаст достаточно места для продолжения копирования с устройства NAS. Расстановка по уровням в облаке выполняется один раз в час, чтобы определить, что было синхронизировано, и освободить место на диске для достижения 99% свободного объема.
Для Robocopy может потребоваться переместить больше файлов, чем можно сохранить локально на экземпляре Windows Server. Можно ожидать, что Robocopy переместит все данные гораздо быстрее, чем служба "Синхронизация файлов Azure" сможет передать файлы в локальный том и распределить их по уровням. В этом случае Robocopy потерпит неудачу. Рекомендуем работать с объектами совместного использования в такой последовательности, которая предотвратит эту ситуацию. Например, можно переместить только те общие ресурсы, которые соответствуют свободному пространству на экземпляре Windows Server. Избегайте одновременного запуска заданий Robocopy для всех общих папок. Хорошая новость: переключатель /MIR гарантирует перемещение только дельт. После перемещения дельты, перезапущенному заданию не потребуется повторно перемещать файл.
Выполните переключение
При первом запуске команды Robocopy пользователи и приложения по-прежнему получают доступ к файлам на устройстве NAS и потенциально могут изменить их. Robocopy обработает каталог, а затем перейдет к следующему. Затем пользователь в NAS может добавить, изменить или удалить файл в первом каталоге, который не будет обрабатываться во время текущего запуска Robocopy. Это поведение является ожидаемым.
Во время первого выполнения основная часть переданных данных перемещается на экземпляр Windows Server и в облако с помощью службы Azure File Sync. Это первое копирование может занять много времени в зависимости от следующих факторов:
- пропускная способность передачи;
- скорость локальной сети и то, насколько оптимально количество потоков Robocopy соответствует этой скорости.
- количество элементов (файлов и папок), которые должны быть обработаны средством Robocopy и службой "Синхронизация файлов Azure".
После завершения первоначального запуска выполните команду еще раз.
Robocopy завершит работу быстрее при втором запуске для общего ресурса. В этом случае передаются только изменения, произошедшие с момента последнего запуска. Вы можете запускать повторяющиеся задания для одного и того же общего ресурса.
При анализе допустимого времени простоя необходимо прекратить доступ пользователей к общим ресурсам на основе NAS. Это можно сделать любым способом, который не позволит пользователям изменять структуру и содержимое файлов и папок. Например, можно указать для пространства имен DFS расположение, которое не существует, или изменить корневые ACL общей папки.
Запустите Robocopy последний раз. Средство обнаружит все изменения, которые могли быть пропущены. Время выполнения последнего шага зависит от скорости сканирования Robocopy. Вы можете оценить время (которое равно времени простоя), измеряя длительность предыдущего запуска.
Создайте общую папку в папке на сервере Windows Server и, если возможно, настройте развертывание DFS-N, чтобы оно указывало на нее. Не забудьте установить те же разрешения на общий доступ, что и в SMB-ресурсе вашей NAS. Если у вас есть присоединенное к домену устройство NAS корпоративного класса, SIDs пользователей будут автоматически сопоставляться, так как пользователи находятся в Active Directory, и Robocopy копирует файлы и метаданные с максимальной точностью. Если в NAS есть локальные пользователи, вам потребуется:
- Повторно создать этих пользователей как локальных пользователей Windows Server.
- Сопоставьте существующие идентификаторы безопасности, которые с помощью средства Robocopy были перенесены на экземпляр Windows Server, с идентификаторами безопасности новых локальных пользователей Windows Server.
Вы завершили перенос ресурса или группы ресурсов в общий корень или том (в зависимости от сопоставления на этапе 1).
Можно попытаться выполнить несколько операций копирования параллельно. Рекомендуется обрабатывать по одной общей папке Azure за раз.
Устаревший параметр: "автономная передача данных"
До выпуска агента Синхронизации файлов Azure версии 13 интеграция с Data Box выполнялась с помощью процесса, который называется "автономная передача данных". Этот процесс устарел, и вы больше не можете создать конечную точку сервера в режиме автономной передачи данных. Начиная с версии агента 13, его заменили на более простые и быстрые действия, описанные в этой статье.
Устранение неполадок
Наиболее распространенной проблемой является сбой команды Robocopy из-за "переполнения тома" на стороне сервера Windows. Облачное распределение по уровням производится один раз в час, при этом удаляется содержимое с локального диска сервера Windows, которое было синхронизировано. Его цель — освободить до 99 % пространства на диске.
Позвольте синхронизации продолжить выполнение, а функции распределения по уровням облака — освободить место на диске. Это можно наблюдать в Проводнике файлов в экземпляре Windows Server.
Когда на экземпляре Windows Server будет достаточно свободного места, повторно выполните команду, чтобы устранить проблему. В этой ситуации ничего не ломается. Можно спокойно продолжать работу. Единственное последствие в этом случае — необходимость выполнить команду еще раз.
Сведения об устранении неполадок в работе службы "Синхронизация файлов Azure" см. в статье, приведенной в следующем разделе.
Следующие шаги
В следующих статьях вы узнаете о расширенных возможностях и передовых методах работы с Azure Files и Azure File Sync.