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

Серия StorSimple 8000 включает либо 8100, либо физические 8600, локальные устройства и их компоненты облачной службы. В этом руководстве по миграции также есть виртуальные модули StorSimple 8010 и 8020. Данные можно перенести из любого из этих устройств в общие папки Azure с помощью дополнительной функции Синхронизации файлов Azure. Синхронизация файлов Azure представляет собой стратегически долгосрочную службу Azure по умолчанию, которая заменяет функции локальной службы StorSimple. Эта статья содержит необходимые основные сведения и информацию об этапах миграции для успешного переноса в службу "Синхронизация файлов Azure".

Этап 1. Подготовка к миграции

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

Запасы

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

• Для физических устройств StorSimple (серии 8000) воспользуйтесь этим руководством по миграции.
• Виртуальные устройства StorSimple (серия 1200) используют другое руководство по миграции.

Сводка по стоимости миграции

Миграция в общие папки Azure из томов StorSimple с помощью заданий миграции в ресурсе "Диспетчер данных StorSimple" осуществляется бесплатно. Другие затраты могут возникнуть во время миграции и после нее:

• Исходящий трафик сети. Ваши файлы StorSimple находятся в учетной записи хранения в определенном регионе Azure. Если вы подготавливаете общие папки Azure, которые вы переносите в учетную запись хранения в том же регионе Azure, расходы на исходящий трафик не возникают. Однако при перемещении файлов в учетную запись хранения в другом регионе в рамках этой миграции будут применены затраты на исходящий трафик.
• Транзакции в общей папке Azure. При копировании файлов в общую папку Azure (в рамках миграции или за ее пределами) по мере записи файлов и метаданных взимается плата за транзакции. Во время миграции рекомендуется запускать общую папку Azure на уровне, оптимизированном для транзакций. По завершении миграции переключитесь на нужный уровень. Этапы, описанные в этой статье, вызывают это на соответствующем этапе.
• Изменение уровня общей папки Azure. Изменение уровня затрат на транзакции в общей папке Azure. В большинстве случаев это более экономично, чтобы следовать советам с предыдущей точки.
• Стоимость хранения. После начала копирования файлов в общую папку Azure во время миграции начинается использование места в хранилище и за него выставляется счет. Перенесенные резервные копии становятся моментальными снимками общей папки Azure. Моментальные снимки общей папки используют емкость хранилища только для различий, которые они содержат.
• StorSimple: пока вы не отмените подготовку устройств StorSimple и учетных записей хранения, затраты StorSimple на хранение, резервные копии и устройства будут продолжаться.

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

Общие папки Azure открывают новый мир возможностей для структурирования развертывания файловых служб. Общая папка Azure — это общий ресурс SMB в облаке, к которому можно настроить доступ пользователей непосредственно через протокол SMB с помощью знакомой проверки подлинности Kerberos и существующих разрешений NTFS (списки управления доступом к файлам и папкам). Узнайте больше о доступе к общим папкам Azure на основе удостоверений.

Альтернативой для прямого доступа является Синхронизация файлов Azure — непосредственный аналог возможности StorSimple для локального кэширования часто используемых файлов.

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

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

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

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

• Руководство по планированию Синхронизация файлов Azure
• Руководство по развертыванию службы "Синхронизация файлов Azure"

Ключ шифрования данных службы StorSimple

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

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

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

Изменение ключа шифрования данных службы

Ключи шифрования данных службы используются для шифрования конфиденциальных данных клиентов, например учетных данных учетной записи, которые отправляются из службы StorSimple Manager к устройству StorSimple. Необходимо будет периодически менять эти ключи, если у ИТ-организации есть политика ротации ключей на устройствах хранения. Процесс изменения ключа может немного отличаться в зависимости от того, имеется ли одно или несколько устройств, управляемых службой StorSimple Manager. Дополнительные сведения см. в статье Защита устройства StorSimple и данных.

Процесс изменения ключа шифрования данных службы включает 3 шага.

1. С помощью скриптов Windows PowerShell для Azure Resource Manager авторизуйте устройство, чтобы изменить ключ шифрования данных службы.
2. С помощью Windows PowerShell для StorSimple инициируйте изменение ключа шифрования данных службы.
3. Если у вас более одного устройства StorSimple, обновите ключ шифрования данных службы на других устройствах.

Шаг 1. Использование скрипта Windows PowerShell для авторизации изменения ключа шифрования данных службы на устройстве

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

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

Дополнительные сведения об использовании скрипта см. в статье Authorize-ServiceEncryptionRollover.ps1

Какие устройства можно авторизовать для изменения ключей шифрования данных службы?

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

• Устройство должно быть подключено к сети для авторизации изменения ключа шифрования данных службы.
• Одно устройство можно авторизовать еще раз через 30 минут, если изменение ключа не было запрошено.
• Можно авторизовать другое устройство, если изменение ключа не было инициировано ранее авторизованным устройством. После авторизации нового устройства старое не сможет инициировать изменение.
• Невозможно авторизовать устройство во время смены ключа шифрования данных службы.
• Можно авторизовать устройство, если некоторые из зарегистрированных в службе устройств изменили шифрование, а другие — нет.

Шаге 2. Использование Windows PowerShell для StorSimple для изменения ключа шифрования данных службы

Этот шаг выполняется в интерфейсе Windows PowerShell для StorSimple на авторизованном устройстве StorSimple.

Если вы используете последовательную консоль устройства выполните следующие действия для подключения к интерфейсу Windows PowerShell.

Запуск изменения ключа шифрования данных службы

1. Выберите вариант 1, чтобы войти на устройство с правами на полный доступ.

2. В командной строке введите:

   Invoke-HcsmServiceDataEncryptionKeyChange

3. После успешного завершения работы командлета вы получите новый ключ шифрования данных службы. Скопируйте и сохраните этот ключ для использования на шаге 3. Этот ключ будет использоваться для обновления всех остальных устройств, зарегистрированных в службе StorSimple Manager.

   Примечание.

   Этот процесс должен быть запущен в течение четырех часов авторизации устройства StorSimple.

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

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

Шаг 3. Обновление ключа шифрования данных службы на других устройствах StorSimple

Эти действия необходимо выполнить в интерфейсе Windows PowerShell устройства StorSimple при наличии нескольких устройств, зарегистрированных в службе StorSimple Manager. Ключ, полученный на шаге 2, следует использовать для обновления остальных устройств StorSimple, зарегистрированных в службе StorSimple Manager.

Выполните следующие действия для обновления шифрования данных службы на устройстве.

Обновление ключа шифрования данных службы на физических устройствах

1. Используйте Windows PowerShell для StorSimple, чтобы подключиться к консоли. Выберите вариант 1, чтобы войти на устройство с правами на полный доступ.
2. В командной строке введите следующий текст: Invoke-HcsmServiceDataEncryptionKeyChange – ServiceDataEncryptionKey.
3. Укажите ключ шифрования данных службы, полученный на Шаге 2. Использование Windows PowerShell для StorSimple для изменения ключа шифрования данных службы.

Обновление ключа шифрования данных службы на всех облачных устройствах 8010/8020

1. Скачайте и установите сценарий PowerShell Update-CloudApplianceServiceEncryptionKey.ps1.
2. Откройте PowerShell и введите следующую команду в командной строке: Update-CloudApplianceServiceEncryptionKey.ps1 -SubscriptionId [subscription] -TenantId [tenantid] -ResourceGroupName [resource group] -ManagerName [device manager]

Этот сценарий гарантирует, что ключ шифрования служебных данных будет установлен на всех облачных устройствах 8010/8020 в диспетчере устройств.

Известные ограничения

Диспетчер данных StorSimple и общие папки Azure имеют несколько ограничений, которые следует учитывать перед началом работы, так как они могут предотвратить миграцию:

• Поддерживаются только тома NTFS из вашего устройства StorSimple. Тома ReFS не поддерживаются.
• Любой том, размещенный на динамических дисках Windows Server, не поддерживается.
• Служба не работает с томами, зашифрованными с помощью BitLocker, или томами, для которых включена дедупликация данных.
• Поврежденные резервные копии StorSimple перенести невозможно.
• Специальные сетевые параметры, такие как брандмауэры или связь только с частной конечной точкой, не могут быть включены ни в исходной учетной записи хранения, где хранятся резервные копии StorSimple, ни в целевой учетной записи хранения, в которой хранятся общие папки Azure.

Точность файлов

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

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

Файлы Azure поддерживают подмножество свойств файла NTFS. Списки управления доступом Windows, общие метаданные и некоторые метки времени переносятся.

Следующие элементы не предотвращают миграцию, но могут вызывать проблемы с определенным элементом во время миграции:

• Метки времени: время изменения файла не будет задано. В настоящее время он доступен только для чтения по протоколу REST. Метка времени последнего доступа в файле не будет перемещена, так как это не поддерживаемый атрибут файлов, хранящихся в общей папке Azure.
• Альтернативные потоки данных не могут храниться в общих папках Azure. Файлы, в которых хранятся альтернативные потоки данных, будут скопированы, но альтернативные потоки данных удаляются из файла в процессе.
• Символьные ссылки, жесткие ссылки, соединения и точки повторного анализа пропускаются во время миграции. Журналы копирования миграции перечисляют каждый пропущенный элемент и причину.
• Не удалось скопировать зашифрованные файлы EFS. Журналы копирования показывают, что элемент не удалось скопировать с сообщением "Доступ запрещен".
• Поврежденные файлы пропускаются. Журналы копирования могут выводить различные ошибки для каждого элемента, поврежденного на диске StorSimple: "Сбой запроса из-за неустранимой ошибки оборудования устройства" или "Файл или каталог поврежден или нечитаем" или "Структура списка управления доступом (ACL) недопустима".
• Пропускаются отдельные файлы размером более 4 ТиБ.
• Длина пути к файлу должна быть равна или меньше 2048 символов. Файлы и папки с более длинными путями пропускаются.
• Точки повторного анализа пропускаются. Любые точки дедупликации данных Майкрософт или точки повторного анализа SIS или сторонние пользователи не могут быть разрешены подсистемой миграции и предотвратит миграцию затронутых файлов и папок.

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

Резервные копии томов StorSimple

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

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

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

Чтобы определить критически важные резервные копии, которые необходимо мигрировать, создайте контрольный список политик архивации. Например:

• Последняя резервная копия.
• Одна резервная копия в месяц в течение 12 месяцев.
• Одна резервная копия в год в течение трех лет.

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

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

Сопоставление существующих томов StorSimple с общими папками 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 (за пределами области синхронизации), могут выполняться быстрее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Количество учетных записей хранения

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

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

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

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

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

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

Сводка по этапу 1

В конце этапа 1:

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

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

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

Развертывание учетных записей хранения

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

Отток подписок

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

Группа ресурсов

Группы ресурсов в Azure помогают организации ресурсов и разрешений управления администраторами. Подробнее.

Storage account name

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

Расположение

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

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

Производительность

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

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

Репликация

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

• Локально избыточное хранилище (LRS).
• Хранилище, избыточное между зонами (ZRS), которое доступно не во всех регионах Azure.

общие папки Azure

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

Диспетчер данных StorSimple

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

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

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

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

Сводка по этапу 2

К концу 2-го этапа вы развернете учетные записи хранения и все общие папки Azure в них. У вас также появится ресурс "Диспетчер данных StorSimple". Он понадобится позже на этапе 3 во время настройки заданий миграции.

Этап 3. Создание и выполнение задания миграции

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

Чтобы приступить к работе, перейдите в Диспетчер данных StorSimple, найдите Определения заданий в меню и выберите + Определение задания. По умолчанию выбран правильный тип целевого хранилища: Общая папка Azure.

Выбор резервных копий томов для миграции

Существует ряд важных аспектов, связанных с выбором резервных копий, которые необходимо перенести:

• Задания миграции могут перемещать только резервные копии, а не данные работающего тома. Поэтому последняя резервная копия является ближайшей к динамическим данным и всегда должна быть включена в список резервных копий, перемещаемых при миграции. При открытии диалогового окна выбора резервного копирования он выбирается по умолчанию.
• Убедитесь, что последняя резервная копия актуальна, чтобы обеспечить минимально возможный размер разностного файла в общей папке. Перед созданием задания миграции можно вручную активировать и завершить другую резервную копию тома. Небольшая разница в динамической общей папке улучшает возможности миграции. Если эта разность может быть нулевой, то есть больше изменений в томе StorSimple не произошло после создания последней резервной копии в списке, то вырезка пользователя будет значительно упрощена и ускоряется.
• Резервные копии должны воспроизводиться в общей папке Azure от самой старой до самой новой. Устаревшая резервная копия не может быть "отсортирована в" список резервных копий в общей папке Azure после выполнения задания миграции. Поэтому перед созданием задания необходимо убедиться, что список резервных копий завершен.
• Этот список резервных копий в задании нельзя изменить после создания задания, даже если задание никогда не выполнялось.
• Для выбора резервных копий необходимо, чтобы переносимый том StorSimple был подключен.

Сопоставление каталогов

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

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

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

Семантические элементы

Сопоставление выражается слева направо: [\исходный путь] > [\целевой путь].

Примеры

Перемещает содержимое папки Данные пользователя в корневую структуру целевой общей папки:

\User data > \

Перемещает содержимое всего тома по новому пути в целевую общую папку:

\ > \Apps\HR tracker

Перемещает содержимое исходной папки по новому пути в целевую общую папку:

\HR resumes-Backup > \Backups\HR\resumes

Сортирует несколько исходных расположений в новую структуру каталога:

\HR\Candidate Tracker\v1.0 > \Apps\Candidate tracker
\HR\Candidates\Resumes > \HR\Candidates\New
\Archive\HR\Old Resumes > \HR\Candidates\Archived

Семантические правила

• Всегда указывайте пути к папкам относительно корневого уровня.
• Начинайте каждый путь к папке с индикатора корневого уровня "\".
• Не включайте буквы дисков.
• При указании нескольких путей исходные или целевые пути не могут перекрываться:
  Пример недопустимого перекрытия исходного пути:
  \folder\1 > \folder
  \folder\1\2 > \folder2
  Пример недопустимого перекрытия целевого пути:
  \folder > \
  \folder2 > \
  
• Исходные папки, которые не существуют, игнорируются.
• Создаются структуры папок, которые не существуют в целевом объекте.
• Как и в случае с Windows, имена папок не чувствительны к регистру, но сохраняют его.

Выполнение задания миграции

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

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

Ошибки для каждого элемента

Задания миграции имеют два столбца в списке резервных копий, которые перечисляют все проблемы, которые могли возникнуть во время копирования:

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

Эти журналы представляют собой файлы *.csv с перечнем элементов пространства имен и элементов, которые не удалось скопировать. Ошибки будут разделены на категории, описанные ранее. В расположении файла журнала можно найти журналы файлов со сбоями по словам "Не удалось". Так можно сформировать список журналов для файлов, которые не удалось скопировать. Отсортируйте эти журналы по размеру. Могут быть дополнительные журналы, созданные в размере 17 байт. Они пустые, и их можно пропустить. Путем сортировки можно выделить журналы, содержащие данные.

Этот же процесс применим к файлам журналов, которые заносятся данные об успешном копировании.

Управление заданием миграции

Задания миграции имеют следующие состояния:

• Никогда не выполнялось
  новое задание, которое было определено, но никогда не выполнялось.
• Ожидание
  задания в этом состоянии ожидает подготовки ресурсов в службе миграции. Когда все будет готово, оно автоматически перейдет в другое состояние.
• 
  Сбой неудачного задания попал в неустранимую ошибку, которая предотвращает обработку дополнительных резервных копий. Задание не должно входить в это состояние. Оптимальным вариантом действий в таком случае является отправка запроса на поддержку.
• Отменено / Отмена
  Можно отменить все задание миграции или отдельные резервные копии в рамках задания. Отмененные резервные копии не будут обработаны, так как отмененное задание миграции перестанет обрабатывать резервные копии. Имейте в виду, что отмена задания займет много времени. Это не помешает вам создать новое задание. Лучший курс действий — позволить заданию полностью прибыть в состояние "Отменено ". Можно либо игнорировать неудачные или отмененные задания, либо удалить их позже. Вам не нужно удалять задания, прежде чем удалять ресурс Диспетчера данных в конце миграции StorSimple.

Параллельное выполнение заданий

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

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

• Одновременно можно выполнить только одно задание миграции с одним и тем же исходным томом StorSimple.
• Одновременно можно выполнить только одно задание миграции с одной и той же целевой общей папкой Azure.
• Перед началом следующего задания убедитесь, что все предыдущие задания находятся в copy stage состоянии и отображают ход перемещения файлов по крайней мере на 30 минут.
• Вы можете выполнять до четырех заданий миграции параллельно на диспетчер устройств StorSimple, если вы соблюдаете предыдущие правила.

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

Сводка по этапу 3

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

Этап 4. Доступ к общим папкам Azure

Существует две основные стратегии доступа к общим папкам Azure:

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

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

Далее в этом разделе приведены инструкции по развертыванию.

Как развернуть службу синхронизации файлов Azure (предварительная версия)

Пора развернуть часть службы "Синхронизация файлов Azure".

1. Создайте облачный ресурс службы "Синхронизация файлов Azure".
2. Разверните агент службы "Синхронизация файлов Azure" на локальном сервере.
3. Зарегистрируйте сервер в облачном ресурсе.

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

Развертывание облачного ресурса службы синхронизации файлов Azure

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

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

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

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

Развертывание локального экземпляра Windows Server

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

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

Подготовка экземпляра Windows Server к синхронизации файлов

В этом разделе вам предстоит установить агент Синхронизации файлов 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. В меню слева выберите пункт Зарегистрированные серверы. Сервер появится в списке.

Настройка службы синхронизации файлов Azure на экземпляре Windows Server

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

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

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

Развертывание прямого доступа к общей папке

Сводка по этапу 4

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

Этап 5. Прямая миграция пользователя

На этом этапе вы завершите миграцию:

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

Планирование простоев

Этот подход к миграции требует определенного времени простоя для пользователей и приложений. Цель — сократить простои до минимума. Обратите внимание на такие рекомендации:

• Обеспечьте доступ к томам StorSimple во время выполнения заданий миграции.
• По завершении заданий миграции данных для общей папки можно закрыть доступ пользователей (по крайней мере, доступ для записи) к томам или общим папкам StorSimple. Окончательная команда RoboCopy выполнит синхронизацию общей папки Azure. Затем вы можете выполнить прямую миграцию пользователей. Место выполнения команды RoboCopy зависит от того, выбрано ли использование службы "Синхронизация файлов Azure" или прямой доступ к общей папке. В предстоящем разделе рассматривается эта тема.
• По завершении синхронизации командой RoboCopy вы сможете предоставить пользователям доступ к новому расположению непосредственно в общей папке Azure или в общей папке SMB на экземпляре Windows Server с помощью службы "Синхронизация файлов Azure". Зачастую развертывание DFS-N поможет быстро и эффективно выполнить прямую миграцию. Это обеспечит согласованность существующих общих адресов и перенаправление в новое расположение, в котором содержатся перенесенные файлы и папки.

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

Определение полной синхронизации пространства имен с сервером

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

Портал Azure

Вы можете узнать, когда пространство имен полностью перенесено, с помощью портала Azure.

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

Теперь можно выполнить локальную команду RoboCopy.

Средство просмотра событий Windows Server

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

1. Откройте средство Просмотр событий и перейдите в раздел Приложения и службы.
2. Перейдите по пути Microsoft\FileSync\Agent\Telemetry.
3. Найдите последнее событие 9102, соответствующее завершенному сеансу синхронизации.
4. Выберите Сведения и найдите событие, в котором для значения SyncDirection указано Загрузка.
5. По завершении загрузки пространства имен в списке будет существовать одно событие, в котором для значения Сценарий указано FullGhostedSync, а значение HResult = 0.
6. Если этого события нет, можно также найти другие события 9102, в которых значение SyncDirection = Загрузка, а значение Сценарий = "RegularSync". Если вы нашли одно из этих событий, это также указывает, что загрузка пространства имен завершена, а синхронизация перешла на этап обычных сеансов синхронизации, независимо от того, существуют данные для синхронизации на текущий момент или нет.

Окончательная команда RoboCopy

На этом этапе существуют различия между локальным экземпляром Windows Server и устройством StorSimple 8100 или 8600.

1. Необходимо синхронизировать изменения, которые пользователи или приложения создавали на стороне StorSimple, пока выполнялась миграция.
2. В некоторых случаях используется служба "Синхронизация файлов Azure". Кэш устройства StorSimple заполнен, в отличии от экземпляра Windows Server, на котором есть только пространство имен, в котором на данный момент локально не хранится содержимое файлов. Окончательная команда RoboCopy поможет быстро перенести локальный кэш службы "Синхронизация файлов Azure" за счет вытягивания всего доступного локально кэшированного содержимого файла и разместить его на сервере синхронизации файлов Azure.
3. Некоторые файлы могли быть пропущены при выполнении заданий миграции из-за недопустимых символов. Если это так, скопируйте их на экземпляр Windows Server с поддержкой службы "Синхронизация файлов Azure". Позже их можно настроить таким образом, чтобы они могли синхронизироваться. Если для определенной общей папки не используется Синхронизация файлов Azure, лучше переименовать файлы с недопустимыми символами в томе StorSimple. Затем выполните команду RoboCopy непосредственно в общей папке Azure.

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

Команда RoboCopy имеет несколько параметров. В примере ниже показана законченная команда и список причин для выбора этих параметров.

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> 

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

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

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

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

1. Подключите общую папку Azure как сетевой диск к локальному компьютеру Windows.
2. Выполните команду RoboCopy между устройством StorSimple и подключенной общей папкой Azure. Если файлы не копируются, исправьте их имена на стороне StorSimple, удалив недопустимые символы. Затем повторно запустите команду RoboCopy. Ранее указанную команду RoboCopy можно выполнять несколько раз, не вызывая ненужного отзыва в StorSimple.

Устранение неполадок и оптимизация

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

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

Рекомендации по числу операций ввода-вывода в секунду и пропускной способности сети

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

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

• Подумайте, когда в вашей среде лучше выполнять миграцию: в течение дня, в нерабочее время или в выходные дни.
• Также рассмотрите возможность того, что качество обслуживания сети на сервере Windows Server может ограничить скорость копирования.
• Избегайте ненужной работы для средств миграции.

Средство RoboCopy дает возможность вставлять задержки между пакетами, указывая параметр /IPG:n, где n измеряется в миллисекундах между пакетами RoboCopy. Использование этого параметра позволяет избежать монополизации ресурсов на устройствах с ограниченным доступом к данным и перегруженных сетевых соединений.

/IPG:n не может использоваться для точного регулирования пропускной способности сети вплоть до определенных значений в Мбит/с. Используйте вместо этого качество обслуживания сети Windows Server. Средство RoboCopy полностью полагается на протокол SMB для всех сетевых нужд. Использование SMB — это причина, по которой средство RoboCopy не может влиять на пропускную способность сети, но может замедлить ее использование.

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

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

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

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

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

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

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

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

Избегайте крупномасштабных изменений в пространстве имен. Например, перемещение файлов между каталогами, изменение свойств в большом масштабе или изменение разрешений (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 также необходимо использовать локальный путь для назначения, а не UNC-путь. Например, в качестве пути назначения следует использовать E:\Foldername, а не UNC-путь, например \\ServerName\FolderName.

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

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

Прямая миграция пользователей

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

При наличии развертывания DFS-N можно указать пространства имен DFN для новых расположений папок сервера. Если у вас нет развертывания DFS-N и устройство 8100 или 8600 подключено локально с помощью экземпляра Windows Server, этот сервер можно отключить от домена. Затем присоедините к домену новый экземпляр Windows Server с поддержкой службы «Синхронизация файлов Azure». Во время этого процесса присвойте серверу то же имя сервера и имена общих папок, как и на старом сервере, чтобы прямая миграция оставалась прозрачной для пользователей, групповых политик и сценариев.

Узнайте больше о DFS-N.

Этап 6. Отзыв

При отзыве ресурса вы теряете доступ к его конфигурации и данным. Отзыв невозможно отменить. Не продолжайте, пока не подтвердите, что:

• Миграция завершена.
• Нет никакой зависимости между файлами, папками или резервными копиями томов StorSimple, которые вы собираетесь отозвать.

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

1. Отзовите ресурс Диспетчера данных StorSimple с помощью портала Azure. Вместе с ним будут удалены все задания служб DTS. Получить журналы копирования будет не так легко. Если они важны для ваших записей, извлеките их перед отзывом.
2. Убедитесь, что физические устройства StorSimple перенесены, а затем отмените их регистрацию. Если вы не уверены, что они перенесены, не продолжайте. Отозвав эти ресурсы, пока они все еще нужны, вы не сможете восстановить данные или их конфигурацию.
   При необходимости можно сначала отозвать ресурс тома StorSimple, в результате чего будут очищены данные на устройстве. Этот процесс может занять несколько дней и не потребует экспертного обнуления данных на устройстве. Если это важно, выполните обнуление диска отдельно от отзыва ресурса и в соответствии с вашими политиками.
3. Если в Диспетчере устройств StorSimple не осталось зарегистрированных устройств, можно приступить к удалению самого ресурса Диспетчера устройств.
4. Теперь пора удалить учетную запись хранения StorSimple в Azure. Опять же, остановитесь и убедитесь, что миграция завершена и никто и ничто не зависит от этих данных, прежде чем продолжать.
5. Отсоедините физическое устройство StorSimple от центра обработки данных.
6. Если вы владеете устройством StorSimple, вы можете отправить его на переработку. Если устройство арендовано, проинформируйте арендодателя и верните устройство должным образом.

Миграция завершена.

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

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

Ошибки уровне задания

Ошибки уровне элемента

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

Следующие шаги

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