Миграция с устройства Storsimple 1200 в службу "Синхронизация файлов Azure"

Статья
03/21/2023

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

Примечание.

Служба StorSimple (включая диспетчер устройств StorSimple для серии 8000 и 1200 и диспетчера данных StorSimple) достигла конца поддержки. Конец поддержки StorSimple был опубликован в 2019 году на страницах политики Microsoft LifeCycle и Azure Communications . Дополнительные уведомления были отправлены по электронной почте и размещены на портал Azure и в обзоре StorSimple. Обратитесь служба поддержки Майкрософт для получения дополнительных сведений.

Применяется к

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

Служба синхронизации файлов Azure

Синхронизация файлов Azure — это облачная служба Майкрософт на базе двух основных компонентов:

Синхронизация файлов и распределение по уровням в облаке.
Общие папки в качестве собственного хранилища в Azure, к которым можно получить доступ по нескольким протоколам, таким как S МБ и FileREST. Общая папка Azure сравнима с общей папкой в Windows Server, которую можно подключить в качестве сетевого диска. Это поддерживает важные аспекты качества файлов, такие как атрибуты, разрешения и метки времени. В отличие от StorSimple для интерпретации файлов и папок, хранящихся в облаке, не требуются какие-либо приложения или службы. Идеальный и гибкий подход заключается в хранении данных файлового сервера общего назначения и некоторых данных приложения в облаке.

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

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

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

Путь миграции с устройства StorSimple 1200 в службу "Синхронизация файлов Azure"

Для запуска агента службы "Синхронизация файлов Azure" требуется локальный Windows Server. В качестве Windows Server может выступать как минимум сервер 2012 R2, но в идеале это Windows Server 2019.

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

Обзор этапов маршрута миграции, описанного далее в этой статье.

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

Шаг 1. Предоставление локального сервера и хранилища Windows

Создайте Windows Server 2019 как минимум 2012R2 как виртуальную машину или физический сервер. Отказоустойчивый кластер Windows Server также поддерживается.
Подготовка или добавление прямых подключенных служба хранилища (DAS по сравнению с NAS, которая не поддерживается). Размер хранилища Windows Server должен быть равен размеру доступной емкости виртуального устройства StorSimple 1200 или превышать его.

Шаг 2. Настройка хранилища Windows Server

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

Рабочие данные не должны попадать на системный том Windows Server. Распределение по уровням в облаке не поддерживается в системных томах. Однако эта функция необходима для миграции, а также для непрерывных операций в качестве замены StorSimple.
Подготовьте такое же количество томов на сервере Windows Server, как и на виртуальном устройстве StorSimple 1200.
Настройте необходимые роли, компоненты и параметры Windows Server. Рекомендуется использовать обновления Windows Server, чтобы обеспечить безопасность и актуальность операционной системы. Аналогично, рекомендуем активировать центр обновления Майкрософт, чтобы поддерживать актуальность приложений Microsoft, в том числе агента "Синхронизация файлов Azure".
Не настраивайте папки или общие папки перед чтением следующих шагов.

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

На этом шаге вам понадобятся учетные данные подписки Azure.

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

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

Дополнительные сведения см. в разделе о развертывании службы синхронизации хранилища статьи о развертывании службы Синхронизации файлов 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 поддерживает синхронизацию корня тома с общей папкой Azure. При синхронизации корня тома все вложенные папки и файлы отправляются в одну и ту же общую папку Azure.

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

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

Совет

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

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

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

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

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

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

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

Совет

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

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

Внимание

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

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

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

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

#	Сценарий синхронизации	Поддерживается	Рекомендации (или ограничения)	Решение (или обходное решение)
1	Файловый сервер с несколькими дисками и томами и несколькими общими ресурсами для одной целевой общей папки Azure (консолидация)	No	Целевая файловая папка Azure (конечная точка облака) поддерживает синхронизацию только с одной группой синхронизации. Группа синхронизации поддерживает только одну конечную точку сервера на зарегистрированный сервер.	1. Начните с синхронизации одного диска (корневого тома) для целевого файлового ресурса Azure. Начиная с самого большого диска или тома, требования к хранилищу будут соответствовать локальным требованиям. Настройте распределение по уровням в облаке для распределения всех данных в облако, тем самым освобождая место на диске файлового сервера. Переместите данные из других томов или общих папок в текущий том, который синхронизируется. Продолжайте шаги по одному до тех пор, пока все данные не будут многоуровневы до облака или перенесены. 2) Нацелив один корневой том (диск) за раз. Используйте распределение по уровням облака для распределения всех данных для целевого файлового ресурса Azure. Удалите конечную точку сервера из группы синхронизации, повторно создайте конечную точку со следующим корневым томом или диском, синхронизацией и повторите процесс. Примечание. Может потребоваться повторная установка агента. 3. Рекомендуется использовать несколько целевых общих папок Azure (одну или другую учетную запись хранения на основе требований к производительности).
2	Файловый сервер с одним томом и несколькими общими ресурсами для одной целевой общей папки Azure (консолидация)	Да	Не удается синхронизировать несколько конечных точек сервера на зарегистрированный сервер, синхронизированный с одной целевой общей папкой Azure (аналогично приведенной выше).	Синхронизировать корневой каталог тома, включающего несколько общих папок или папок верхнего уровня. Дополнительные сведения см. в разделе "Общие понятия группирования" и синхронизации томов.
3	Файловый сервер с несколькими общими папками и (или) томами для нескольких общих папок Azure в рамках одной учетной записи хранения (сопоставление общих папок 1:1)	Да	Один экземпляр Windows Server (или кластер) может синхронизировать до 30 общих папок Azure. Учетная запись хранения — это целевой объект масштабирования для производительности. Операции ввода-вывода в секунду и пропускная способность получают общий доступ между общими файловыми ресурсами. Сохраняйте количество элементов для каждой группы синхронизации в пределах 100 миллионов элементов (файлов и папок) на общую папку. В идеале лучше всего остаться ниже 20 или 30 миллионов на акцию.	1) Использование нескольких групп синхронизации (число групп синхронизации = количество общих папок Azure для синхронизации). 2) Синхронизировано только 30 общих папок в этом сценарии одновременно. Если на этом файловом сервере более 30 общих папок, используйте концепцию группирования общих ресурсов и синхронизацию томов, чтобы уменьшить количество корневых или верхних папок в источнике. 3) Использование дополнительных Синхронизация файлов серверов локальной среды и разделения и перемещения данных на эти серверы для обхода ограничений на исходном сервере Windows.
4	Файловый сервер с несколькими общими ресурсами и (или) томами для нескольких общих папок Azure в разных учетных записях хранения (сопоставление общих папок 1:1)	Да	Один экземпляр Windows Server (или кластер) может синхронизировать до 30 общих папок Azure (одной или другой учетной записи хранения). Сохраняйте количество элементов для каждой группы синхронизации в пределах 100 миллионов элементов (файлов и папок) на общую папку. В идеале лучше всего остаться ниже 20 или 30 миллионов на акцию.	Тот же подход, что и выше
5	Несколько файловых серверов с одним (корневым томом или общим ресурсом) для одной целевой общей папки Azure (консолидация)	No	Группа синхронизации не может использовать облачную конечную точку (общую папку Azure), уже настроенную в другой группе синхронизации. Хотя группа синхронизации может иметь конечные точки сервера на разных файловых серверах, файлы не могут отличаться.	Следуйте указаниям в сценарии 1 выше с дополнительным вниманием к тому, чтобы нацелить один файловый сервер одновременно.

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

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

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

Значок Excel, указывающий на скачиваемое содержимое.

Скачайте шаблон сопоставления пространства имен.

Шаг 5. Подготовка общих папок Azure

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

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

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

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

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

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

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

Внимание

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

По умолчанию общие папки Azure создаются с ограничением в 5 ТиБ. Инструкции по созданию больших общих папок см. в статье Создание файлового ресурса Azure.

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

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

Параметры учетной записи хранения

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

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

Шаг 6. Настройка целевых папок Windows Server

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

Создайте все папки, которые будут синхронизировать каждую из них с собственной общей папкой Azure. Важно придерживаться описанной выше структуры папок. Если вы решили синхронизировать несколько локальных общих папок S МБ совместно в одну общую папку 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. Настройка синхронизации

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

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

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

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

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

Шаг 9. Копирование файлов

Базовый подход к миграции — это использование средства RoboCopy между виртуальным устройством StorSimple и Windows Server, а также между службой "Синхронизация файлов Azure" и общими папками Azure.

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

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

Приведенная ниже команда RoboCopy будет вызывать файлы из хранилища StorSimple Azure в локальную службу StorSimple, а затем — перемещать их в целевую папку Windows Server. Сервер Windows Server будет синхронизировать ее с общими папками Azure. По мере заполнения локального тома Windows Server будет запущено распределение по уровням в облаке, и уже синхронизированные файлы будут распределены по уровням. Распределение по уровням в облаке обеспечит достаточное пространство для продолжения копирования из виртуального устройства StorSimple. Распределение по уровням в облаке выполняется один раз в час, чтобы понять, что было синхронизировано, и освободить 99 % места на томе.

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 демонстрируют, что использование диапазона от 8 до 20 потоков обеспечивает сбалансированную производительность для выполнения исходного копирования. На последующие запуски `/MIR` влияют доступные вычислительные ресурсы и доступная полоса пропускания. Для последующих запусков указываемое количество потоков нужно привести в соответствие с числом ядер процессора и количеством потоков, приходящихся на каждое ядро. Определите, нужно ли зарезервировать ядра для других задач рабочего сервера. Тесты с Файлы Azure показали, что до 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, убедитесь, что вы подключаете общую папку Azure с помощью ключа доступа к учетной записи хранения, а не удостоверения домена. В противном случае сообщения об ошибках могут не позволить найти очевидное решение проблемы.
`/MIR`	(Зеркалирование источника в целевом объекте.) Позволяет Robocopy скопировать только изменения между исходным и целевым объектом. Будут скопированы пустые подкаталоги. Элементы (файлы или папки), которые были изменены или не существуют в целевой папке, будут скопированы. Элементы, которые существуют в назначении, но не в источнике, будут удалены из целевого объекта. При использовании этого параметра структуры исходной и целевой папок должны соответствовать друг другу. Соответствие означает, что вы выполняете копирование с правильного уровня источника и папки на соответствующий уровень папки в целевом объекте. Только тогда зеркальное копирование будет успешным. Если объекты источника и назначения не совпадают, использование `/MIR` приведет к увеличению числа операций удаления и повторного копирования.
`/IT`	Обеспечивает сохранение точности данных в определенных зеркальных сценариях. Например, если в файле происходит изменение ACL и между двумя выполнениями Robocopy обновляется атрибут, он помечается как скрытый. Без параметра `/IT` команда Robocopy может упустить изменение ACL и не передать его в целевое расположение.
`/COPY:[copyflags]`	Точность копирования файла. По умолчанию: `/COPY:DAT`. Флаги копирования: `D` = данные, `A` = атрибуты, `T` = метки времени, `S` = безопасность = NTFS ACL, `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`	Только для целевых объектов с многоуровневым хранилищем. Не поддерживается, если назначение является удаленным ресурсом S МБ. Указывает, что Robocopy работает в "режиме низкого свободного пространства". Этот параметр полезен только для целевых объектов с многоуровневыми хранилищами, которые могут выйти из локальной емкости до завершения Robocopy. Он был добавлен специально для использования с целевым объектом, для которого установлено распределение по уровням в облаке в Синхронизации файлов Azure. Его можно использовать независимо от Синхронизации файлов Azure. В этом режиме средство Robocopy будет приостановлено всякий раз, когда копирование файла приведет к тому, что свободное место на целевом томе опустится ниже предельного значения. Это значение может быть задано в форме `/LFSM:n` флага. Параметр `n` указывается в системе отсчета с базой 2: `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 пользователи и приложения по-прежнему получают доступ к файлам и папкам StorSimple и могут вносить изменения. Возможно, что RoboCopy обработал каталог, перешел к следующему, а затем пользователь в исходном расположении (StorSimple) добавляет, изменяет или удаляет файл, который теперь не будет обработан в этом текущем запуске RoboCopy. Все правильно.

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

пропускная способность загрузки;
скорость вызова облачной службы StorSimple;
пропускная способность отправки;
количество элементов (файлов и папок), которые должны обрабатываться любой службой.

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

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

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

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

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

Создайте общую папку в папке на сервере Windows Server и, если возможно, настройте развертывание DFS-N, чтобы оно указывало на нее. Обязательно установите те же разрешения на уровне общей папки, что и в общей папке SMB в StorSimple.

Теперь вы завершили перенос общей папки или группы общих папок в общий корень или том в зависимости от того, что вы ранее сопоставили.

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

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

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

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

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

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

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

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

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

Скорость и частота успешных запусков RoboCopy будут зависеть от нескольких факторов:

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

Скорость обработки

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

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

Причиной этой разницы является вычислительная мощность, необходимая для прохода по пространству имен. Средство RoboCopy поддерживает многопоточные копии с помощью параметра /MT:n, где n означает количество используемых потоков. Поэтому при подготовке компьютера специально для RoboCopy рассмотрите количество ядер процессора и количество потоков, которое они предоставляют. Наиболее распространенный вариант — два потока на ядро. Число ядер и потоков компьютера — важная точка данных, позволяющая решить, какое значение n в /MT:n следует указать. Также определите, сколько заданий RoboCopy планируется выполнять параллельно на определенном компьютере.

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

Во время первого сеанса работы RoboCopy с пустым целевым объектом или при выполнении задания по определению отличий с большим количеством измененных файлов возможно ограничение производительности из-за пропускной способности сети. Для первоначального запуска рекомендуется использовать большое количество потоков. Большое количество потоков, даже превышающее количество потоков, доступных в текущий момент времени на компьютере, позволяет получить максимальный уровень доступной пропускной способности сети. На последующих запусках с параметром /MIR постепенно отражается влияние обрабатываемых элементов. Меньшее количество изменений при выполнении задания по определению отличий означает уменьшение объема транспорта данных по сети. Теперь скорость больше зависит от способности обрабатывать элементы пространства имен, чем от перемещения их по сетевому каналу. Для последующих запусков указываемое число потоков нужно привести в соответствие с числом ядер процессора и числом потоков, приходящихся на каждое ядро. Определите, нужно ли зарезервировать ядра для других задач, которые может иметь рабочий сервер.

Совет

Главное правило: первый запуск RoboCopy, при котором перемещается большой объем данных из сети с более высокой задержкой, рекомендуется подготовить избыточное количество потоков (/MT:n). При последующих запусках копируется меньше различий, и, скорее всего, будет выполняться переход от ограничений пропускной способности к ограничению вычислений. В этих обстоятельствах часто лучше сопоставить количество потоков RoboCopy с фактически доступными потоками на компьютере. Избыточная подготовка в этом сценарии может привести к увеличению количества сдвигов контекста в процессоре, что, в свою очередь, может снизить скорость копирования.

Устранение лишней работы

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

Возросшее время выполнения задания RoboCopy, так как каждый файл и папка, затрагиваемые изменением ACL, нуждаются в обновлении
При повторном использовании данных, перемещенных ранее, может потребоваться повторное копирование. Например, придется заново копировать данные при изменении структуры папок после того, как файлы из них уже были скопированы. Задание RoboCopy не может, подобно проигрывателю, "воспроизводить" изменения в пространстве имен. Следующее задание должно очистить файлы, которые ранее были перенесены в старую структуру папок, и снова передать файлы в новую структуру папок.

Другим важным аспектом является эффективное использование средства RoboCopy. С помощью рекомендуемого скрипта RoboCopy вы создадите и сохраните файл журнала для ошибок. Возможно, возникновение ошибок копирования — это нормально. Ввиду этих ошибок часто необходимо выполнение нескольких циклов копирования для средства вроде RoboCopy. Начальное выполнение, скажем, из NAS в DataBox или от сервера к общему файловому ресурсу Azure. И один или несколько дополнительных запусков с параметром /MIR для перехвата и повторного копирования файлов, которые не были скопированы.

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

/R:n n = периодичность повторного копирования невыполненного файла и
/W:n n = интервал в секундах между повторными попытками

/R:5 /W:5 является разумным параметром, который можно изменить в соответствии с ситуацией. В этом примере копирование неудачного файла будет повторяться пять раз, с интервалом в 5 секунд между повторными попытками. Если не удается скопировать файл в этом запуске, в следующем RoboCopy повторит попытку. Часто файлы не удается скопировать из-за того, что они использовались или из-за ошибок времени ожидания, но они могут быть успешно скопированы с помощью этого подхода.

Windows Server 2022 и RoboCopy LFSM

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

Используйте RoboCopy с Windows Server 2022. Только эта версия RoboCopy содержит важные исправления ошибок и возможности, которые делают параметр совместимым с дополнительными флагами, требуемыми для большинства миграций. Например, совместимость с флагом /B.

/B запускает RoboCopy в том же режиме, что и приложение резервного копирования. Этот параметр позволяет RoboCopy перемещать файлы, для которых у текущего пользователя нет разрешений.

Как правило, RoboCopy можно запустить на исходном, целевом или стороннем компьютере.

Внимание

Если вы планируете использовать /LFSM, убедитесь, что RoboCopy работает на целевом сервере Синхронизации файлов Azure с Windows Server 2022.

Обратите внимание, что при работе с /LFSM также необходимо использовать локальный путь для назначения, а не UNC-путь. Например, в качестве пути назначения следует использовать E:\Foldername, а не UNC-путь, например \\ServerName\FolderName.

Внимание

Текущая доступная версия RoboCopy в Windows Server 2022 содержит ошибку, которая приводит к приостановке подсчета количества ошибок на файл. Используйте следующее обходное решение.

Рекомендуемые флаги /R:2 /W:1 увеличивают вероятность сбоя файла из-за вызываемой приостановки /LFSM. В этом примере использование файла, который не был скопирован после трех приостановок из-за приостановки /LFSM, ошибочно приведет к тому, что RoboCopy не обработает этот файл. Обходным решением является использование более высоких значений для /R:n и /W:n. Хорошим примером является /R:10 /W:1800 (10 повторных попыток по 30 минут каждая). В этом случае у алгоритма распределения по уровням для Синхронизации файлов Azure будет достаточно времени на создание пространства на целевом томе.

Эта ошибка была исправлена, но исправление пока недоступно. Просмотрите приведенные в этом абзаце обновления, связанные с доступностью исправления, и способы развертывания.

Примечание.

У вас по-прежнему есть вопросы или возникли проблемы?
Мы здесь, чтобы помочь: Адрес электронной почты в одном слове: миграция Файлы Azure на сайте microsoft dot com

Актуальные ссылки

Материалы по миграции:

Руководство по миграции для StorSimple серии 8000

Материалы, касающиеся службы "Синхронизации файлов Azure":

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

Миграция с устройства Storsimple 1200 в службу "Синхронизация файлов Azure"

Применяется к

Служба синхронизации файлов Azure

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

Путь миграции с устройства StorSimple 1200 в службу "Синхронизация файлов Azure"

Шаг 1. Предоставление локального сервера и хранилища Windows

Шаг 2. Настройка хранилища Windows Server