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

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

• Напрямую подключите общую папку Azure с помощью протокола SMB: так как файлы Azure предоставляют доступ К SMB, вы можете подключить общие папки Azure локально или в облаке с помощью стандартного клиента SMB, доступного в Windows, macOS и Linux. Так как общие папки Azure бессерверны, развертывание для рабочих сценариев не требует управления файловым сервером или устройством, подключенным к сети (NAS). Этот выбор означает, что вам не нужно применять исправления программного обеспечения или переключать физические диски.

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

Основные принципы управления

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

• Учетные записи хранения, предлагаемые поставщиком Microsoft.Storage ресурсов. Учетные записи хранения — это ресурсы верхнего уровня, представляющие общий пул хранилища, операций ввода-вывода в секунду и пропускную способность, в которых можно развертывать классические файловые ресурсы или другие ресурсы хранения в зависимости от типа учетной записи хранения. На все ресурсы хранилища, развернутые в учетной записи хранения, распространяются ограничения, которые применяются к этой учетной записи хранения. Классические общие папки поддерживают протоколы общего доступа к файлам SMB и NFS, но вы можете использовать синхронизацию файлов Azure только с общими папками SMB.

  Примечание.

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

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

Основные понятия управления общей папкой Azure

Классические общие папки или общие папки, развернутые в учетных записях хранения, являются традиционным способом развертывания общих папок для файлов Azure. Они поддерживают все ключевые функции, поддерживаемые Службами файлов Azure, включая SMB и NFS, уровни носителей SSD и HDD, каждый тип избыточности и в каждом регионе. Дополнительные сведения о классических общих папках см. в статье "Классические общие папки".

Существует два основных типа учетных записей хранения, используемых для развертывания классических файловых ресурсов:

• Подготовленные учетные записи хранения: подготовленные учетные записи хранения отличаются с помощью типа учетной FileStorage записи хранения. Подготовленные учетные записи хранения позволяют развертывать подготовленные классические общие папки на оборудовании SSD или HDD. Подготовленные учетные записи хранения можно использовать только для хранения классических общих папок и не могут использоваться другие ресурсы хранилища, такие как контейнеры BLOB-объектов, очереди и таблицы. Рекомендуется использовать подготовленные учетные записи хранения для всех новых развертываний классических файловых ресурсов.
• Учетные записи хранения с оплатой по мере использования: учетные записи хранения с оплатой по мере использования отличаются с помощью типа учетной StorageV2 записи хранения. Учетные записи хранения с оплатой по мере использования позволяют развертывать общие папки с оплатой по мере использования на оборудовании на основе HDD. Учетные записи хранения с оплатой по мере использования можно использовать для хранения классических файловых ресурсов и других ресурсов хранилища, таких как контейнеры BLOB-объектов, очереди или таблицы.

Основные понятия управления синхронизацией файлов Azure

В службе синхронизации хранилища можно развернуть:

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

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

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

Количество необходимых служб синхронизации хранилища

Служба синхронизации хранилища — это корневой ресурс Azure Resource Manager для синхронизации файлов Azure. Он управляет связями синхронизации между установками Windows Server и общими папками Azure. Каждая служба синхронизации хранилища может содержать несколько групп синхронизации и несколько зарегистрированных серверов.

Каждый экземпляр Windows Server можно зарегистрировать только в одной службе синхронизации хранилища. После регистрации сервер может участвовать в нескольких группах синхронизации в этой службе синхронизации хранилища с помощью субъекта Resource Manager для создания конечных точек сервера на сервере.

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

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

Планирование сбалансированных топологий синхронизации

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

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

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

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

Группировка долей

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

Синхронизация громкости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• FileSyncSvc.exe— фоновая служба Windows, которая отвечает за мониторинг изменений на конечных точках сервера и инициирование сеансов синхронизации
• StorageSync.sys— фильтр файловой системы, обеспечивающий распределение по уровням в облаке и быстрое аварийное восстановление

Требования к операционной системе

Синхронизация файлов Azure поддерживается в следующих версиях Windows Server:

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

Минимальные системные ресурсы

Для синхронизации файлов Azure требуется сервер ( физический или виртуальный) со всеми этими атрибутами:

• По крайней мере один ЦП.
• Не менее 2 ГиБ памяти. Если сервер работает на виртуальной машине с поддержкой динамической памяти, настройте виртуальную машину не менее 2048 МиБ памяти.
• Локальный том, отформатированный файловой системой NTFS.

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

Рекомендуемые системные ресурсы

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

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

Например, конечная точка сервера A с 10 миллионами объектов и конечной точкой сервера B с 10 миллионами объектов = 20 миллионов объектов. Для этого примера развертывания мы рекомендуем 8 ЦП, 16 ГиБ памяти для стабильного состояния и (если возможно) 48 ГиБ памяти для первоначальной миграции.

Данные пространства имен хранятся в памяти в целях повышения производительности. Из-за этой конфигурации для повышения производительности требуется больше памяти. Для обработки больше ЦП требуется больше ЦП.

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

*Не рекомендуется синхронизировать более 100 миллионов файлов и каталогов. Это мягкое ограничение на основе проверенных пороговых значений. Дополнительные сведения см. в разделе Целевые показатели масштабируемости службы синхронизации файлов Azure.

Командлет оценки

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

Командлет оценки можно установить, установив модуль Az PowerShell. Инструкции см. в разделе "Установка Azure PowerShell".

Использование

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

Invoke-AzStorageSyncCompatibilityCheck -Path <path>

Проверка только набора данных:

Invoke-AzStorageSyncCompatibilityCheck -Path <path> -SkipSystemChecks

Проверка только системных требований:

Invoke-AzStorageSyncCompatibilityCheck -ComputerName <computer name> -SkipNamespaceChecks

Чтобы отобразить результаты в файле .csv:

$validation = Invoke-AzStorageSyncCompatibilityCheck C:\DATA
$validation.Results | Select-Object -Property Type, Path, Level, Description, Result | Export-Csv -Path C:\results.csv -Encoding utf8

Совместимые файловые системы

Синхронизация файлов Azure поддерживается только в подключенных томах NTFS. Хранилище с прямым подключением (DAS) на Windows Server означает, что операционная система Windows Server владеет файловой системой. DaS можно предоставить, физически подключив диски к файловом серверу, подключив виртуальные диски к виртуальной машине файлового сервера (например, виртуальную машину, размещенную Hyper-V), или даже используя iSCSI.

Поддерживаются только тома NTFS. ReFS, FAT, FAT, FAT32 и другие файловые системы не поддерживаются.

В следующей таблице показано состояние взаимодействия функций файловой системы NTFS:

Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>

Invoke-StorageSyncCloudTiering -Path <path>

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

Свободное место на локальном диске

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

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

• При включенном облачном многоуровневом режиме:

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

• При отключенном облачном тировании:

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

В следующем примере показано, как оценить объем свободного места, необходимого на локальном диске. Предположим, что вы установили агент синхронизации файлов Azure на виртуальной машине Windows Azure и планируете создать конечную точку сервера на диске F. У вас есть 1 миллион файлов (и вы хотите распределить все из них), 100 000 каталогов и размер кластера диска размером 4 КиБ. Размер диска составляет 1000 ГиБ. Вы хотите включить распределение по уровням в облаке и задать политику свободного пространства тома на 20%.

• NTFS выделяет размер кластера для каждого из многоуровневых файлов:

  1 миллион файлов * 4 КиБ размера кластера = 4000 000 КиБ (4 ГиБ)

  Чтобы полностью воспользоваться распределением по уровням в облаке, рекомендуется использовать меньшие размеры кластеров NTFS (менее 64 КИБ), так как каждый многоуровневый файл занимает кластер. Кроме того, NTFS выделяет пространство, которое занимает многоуровневые файлы. Это пространство не отображается в пользовательском интерфейсе.

• Метаданные синхронизации занимают размер кластера на элемент:

  (1 миллион файлов + 100 000 каталогов) * 4 КиБ размера кластера = 4400 000 КиБ (4,4 ГиБ)

• Тепловая служба синхронизации файлов Azure занимает 1,1 КиБ на файл:

  1 миллион файлов * 1,1 КиБ = 1100 000 КиБ (1,1 ГиБ)

• Политика свободного пространства тома составляет 20%:

  1000 ГиБ * 0,2 = 200 ГиБ

В этом случае службе синхронизации файлов Azure потребуется около 209 500 000 КиБ (209,5 ГиБ) для этого пространства имен. Добавьте это количество в любое свободное место, которое может потребоваться для этого диска.

Отказоустойчивый кластер

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

Единственный сценарий, поддерживаемый синхронизацией файлов Azure, — это отказоустойчивый кластер Windows Server с кластеризованными дисками. Отказоустойчивая кластеризация не поддерживается на файловом сервере Scale-Out, общих томах кластера или локальных дисках.

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

Дедупликация данных

Windows Server 2025, Windows Server 2022, Windows Server 2019 и Windows Server 2016

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

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

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

1. Политика свободного пространства для распределения по уровням в облаке имеет значение 20%.
2. Синхронизация файлов Azure уведомляется, если свободное место недостаточно (предположим, 19%).
3. Уровень определяет, что 1% больше места требуется освободить, но требуется 5% дополнительно, поэтому уровень до 25% (например, 30 ГиБ).
4. Файлы разбросаны по уровням, пока не достигнете 30 ГиБ.
5. В рамках взаимодействия с дедупликацией данных синхронизация файлов Azure инициирует сборку мусора в конце сеанса многоуровневой обработки.

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

Windows Server 2012 R2

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

Примечания.

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

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

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

• Для текущих заданий оптимизации дедупликации параметр Data Deduplication MinimumFileAgeDays задерживает распределение по уровням в облаке с политикой данных, если файл еще не многоуровневый.

  • Например, если MinimumFileAgeDays параметр равен 7 дням, а политика данных для распределения по уровням в облаке составляет 30 дней, файлы политик даты и даты после 37 дней.
  • После того как служба синхронизации файлов Azure выполняет уровни файла, задание оптимизации дедупликации пропускает файл.

• Если сервер под управлением Windows Server 2012 R2 с установленным агентом синхронизации файлов Azure обновляется до Windows Server 2025, Windows Server 2022, Windows Server 2019 или Windows Server 2016, необходимо выполнить следующие действия для поддержки дедупликации данных и уровня облака на одном томе:

  1. Удалите агент Синхронизации файлов Azure для Windows Server 2012 R2 и перезапустите сервер.
  2. Скачайте агент синхронизации файлов Azure для новой версии операционной системы сервера (Windows Server 2025, Windows Server 2022, Windows Server 2019 или Windows Server 2016).
  3. Установите агент Синхронизации файлов Azure и перезапустите сервер.

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

Распределенная файловая система

Синхронизация файлов Azure поддерживает взаимодействие с пространствами имен DFS (DFS-N) и репликацией DFS (DFS-R).

DFS-N

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

DFS-R

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

• Вы мигрируете с развертывания DFS-R на развертывание Azure File Sync. Дополнительные сведения см. в статье "Миграция развертывания DFS-R в службу синхронизации файлов Azure".
• Не каждый локальный сервер, который нуждается в копии ваших файлов, может быть подключен напрямую к интернету.
• Серверы филиалов объединяют данные на один центральный сервер, для которого требуется использовать синхронизацию файлов Azure.

Если служба "Синхронизация файлов Azure" и DFS-R работают параллельно, следует учесть следующее.

• В Azure File Sync необходимо отключить облачное распределение по уровням для томов, содержащих реплицируемые папки DFS-R.
• Конечные точки сервера не должны быть сконфигурированы на папках репликации DFS-R с доступом только для чтения.
• С размещением DFS-R может пересекаться только одна конечная точка сервера. Несколько серверных конечных точек, совпадающих с другими активными расположениями DFS-R, могут вызвать конфликты.

Дополнительные сведения см. в разделе "Пространства имен DFS" и "Репликация DFS".

Sysprep

Использование Sysprep на сервере с установленным агентом синхронизации файлов Azure не поддерживается и может привести к непредвиденным результатам. Установка агента и регистрация сервера должны возникать после развертывания образа сервера и завершения мини-установки Sysprep.

Поиск Windows

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

Клиенты Windows вызывают отзыв при поиске общей папки, если на клиентском компьютере включен параметр " Всегда искать имена файлов и содержимое ". Этот флажок по умолчанию снят.

Другие решения HSM

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

Производительность и масштабируемость   

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

• Windows Server и базовая конфигурация диска
• Пропускная способность сети между сервером и хранилищем Azure
• Размер файла
• Общий размер набора данных
• Действие в наборе данных

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

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

Идентификация

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

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

1. На вкладке "Условия" выберите разрешить пользователям назначать выбранные роли только выбранным субъектам (меньше привилегий).

2. Щелкните Выбрать роли и субъекты, а затем выберите Добавить действие в разделе Условие №1.

3. Выберите "Создать назначение роли" и нажмите кнопку "Выбрать".

4. Выберите "Добавить выражение" и выберите "Запрос".

5. В разделе "Источник атрибута" выберите идентификатор определения роли в разделе "Атрибут", а затем выберите ForAnyOfAnyValues:GuidEquals в разделе "Оператор".

6. Выберите "Добавить роли". Добавьте Роль читателя и доступа к данным, Участник с привилегиями для данных файлов хранилища и Участник учетной записи хранилища, а затем выберите Сохранить.

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

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

Сети

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

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

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

Если вы хотите взаимодействовать с общей папкой Azure через SMB, но порт 445 заблокирован, рассмотрите возможность использования SMB через QUIC. Этот метод предлагает VPN нулевой конфигурации для доступа SMB к общим папкам Azure через транспортный протокол QUIC через порт 443. Хотя файлы Azure не поддерживают SMB через QUIC, вы можете создать упрощенный кэш общих папок Azure на виртуальной машине Windows Server 2022 Azure Edition с помощью службы "Синхронизация файлов Azure". Дополнительные сведения об этом параметре см. в статье SMB over QUIC.

Дополнительные сведения о синхронизации файлов Azure и сетях см. в рекомендациях по синхронизации файлов Azure.

Шифрование

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

Шифрование данных в состоянии покоя в Windows Server

Две стратегии шифрования данных в Windows Server обычно работают с синхронизацией файлов Azure:

• Шифрование под файловой системой, так что файловая система и все данные, записанные в нее, шифруются
• Шифрование в самом формате файла

Эти методы не являются взаимоисключающими. Их можно использовать вместе, так как назначение шифрования отличается.

Чтобы обеспечить шифрование под файловой системой, Windows Server предоставляет папку "Входящие" BitLocker. BitLocker полностью прозрачны для синхронизации файлов Azure. Основными причинами использования механизма шифрования, например BitLocker, являются:

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

Дополнительные сведения см. в статье Общие сведения о BitLocker.

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

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

Примеры методов шифрования потока данных файла: Azure Information Protection, Azure Rights Management (Azure RMS) и Служб Active Directory Rights Management. Основная причина использования механизма шифрования, такого как Azure Information Protection или Azure RMS, заключается в предотвращении кражи данных из общей папки людьми, которые копируют его в альтернативные расположения (например, флэш-диск) или по электронной почте несанкционированному лицу. Когда поток данных файла шифруется как часть формата файла, этот файл продолжает шифроваться в общей папке Azure.

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

Шифрование при передаче

Агент синхронизации файлов Azure взаимодействует со службой синхронизации хранилища и общей папкой Azure с помощью протокола REST синхронизации файлов Azure и протокола FileREST. Оба этих протокола всегда используют HTTPS через порт 443. Синхронизация файлов Azure не отправляет незашифрованные запросы по протоколу HTTP.

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

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

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

Шифрование файлового тома Azure в состоянии покоя

Все данные, хранящиеся в файлах Azure, шифруются неактивных с помощью шифрования службы хранилища Azure (SSE). SSE работает аналогично BitLocker в Windows: данные шифруются под уровнем файловой системы.

Так как данные шифруются под файловой системой Azure, так как она закодирована на диск, доступ к базовому ключу клиента не требуется для чтения или записи в общую папку Azure. Шифрование неактивных данных поддерживает протоколы SMB и NFS.

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

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

Файлы Azure используют ту же схему шифрования, что и другие службы хранилища Azure, например хранилище BLOB-объектов Azure. Дополнительные сведения о службе хранилища Azure SSE см. в статье "Шифрование службы хранилища Azure" для неактивных данных.

Уровни хранилища

Файлы Azure предлагают два уровня хранилища: твердотельный диск (SSD) и жесткий диск (HDD). Эти уровни позволяют адаптировать акции к требованиям к производительности и цене вашего сценария:

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

  Общие папки SSD можно использовать как с протоколами SMB, так и с NFS. Общие папки SSD доступны в подготовленных моделях выставления счетов версии 2 и подготовленных моделях выставления счетов версии 1 . Общие папки SSD предлагают более высокую доступность, чем общие папки HDD.

• HDD (стандартный): общие папки HDD предоставляют экономичный вариант хранения общих папок общего назначения. Общие папки HDD доступны с подготовленными моделями выставления счетов версии 2 и оплаты по мере использования , хотя мы рекомендуем подготовленную модель версии 2 для новых развертываний общих папок. Сведения об уровне обслуживания см. на странице обслуживания Azure для веб-служб.

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

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

Дополнительные сведения о уровнях носителей SSD и HDD см. в разделе "Общие сведения о моделях выставления счетов файлов Azure " и "Общие сведения о производительности файлов Azure" и оптимизации производительности файловых ресурсов Azure.

доступность региона для Azure File Sync

Сведения о региональной доступности см. в разделе "Доступность продукта по регионам " и поиск учетных записей хранения.

Для использования Azure File Sync в следующих регионах требуется запрашивать доступ к службам хранилища Azure.

• Франция (юг)
• Западная часть ЮАР
• Центральная часть ОАЭ

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

Избыточность

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

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

• Хранилище, избыточное между зонами (ZRS): при избыточности зоны хранятся три копии каждого файла. Однако эти копии физически изолированы в трех разных кластерах хранения в зонах доступности Azure. Зоны доступности — это уникальные физические расположения в регионе Azure. Каждая зона состоит из одного или нескольких центров обработки данных, оснащенных независимыми системами электроснабжения, охлаждения и сетевого взаимодействия. Запись в хранилище не принимается, пока она не будет записана в кластеры хранения во всех трех зонах доступности.

• Геоизбыточное хранилище (GRS): при геоизбыточности у вас есть основной регион и дополнительный регион. Файлы хранятся три раза в кластере хранилища Azure в основном регионе. Операции записи асинхронно реплицируются в определенный корпорацией Майкрософт вторичный регион.

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

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

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

Общие папки HDD поддерживают все четыре типа избыточности. Общие папки SSD поддерживают только LRS и ZRS.

Учетные записи хранения с оплатой по мере использования предоставляют два других варианта избыточности, которые служба файлов Azure не поддерживает: геоизбыточное хранилище для чтения (RA-GRS) и геоизбыточное хранилище для чтения (RA-GZRS). Вы можете подготовить общие папки Azure в учетных записях хранения с помощью этих параметров, но файлы Azure не поддерживают чтение из дополнительного региона. Общие папки Azure, развернутые в RA-GRS или RA-GZRS учетные записи хранения, выставляются как геоизбыточные или геоизбыточные соответственно.

Миграция

Если у вас есть существующий файловый сервер в Windows Server 2012 R2 или более поздней версии, вы можете напрямую установить синхронизацию файлов Azure. Вам не нужно перемещать данные на новый сервер.

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

Подробные инструкции см. в статье "Миграция в общие папки SMB Azure".

Антивирусная программа

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

Во время проверки по запросу антивирусные решения Microsoft Defender и System Center Endpoint Protection автоматически пропускают чтение файлов с заданным этим атрибутом. Мы проверили их и определили одну из незначительных проблем: при добавлении сервера в существующую группу синхронизации файлы меньше 800 байт отзываются (скачиваются) на новом сервере. Эти файлы остаются на новом сервере и не многоуровневы, так как они не соответствуют требованиям к размеру уровня (более 64 КИБ).

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

Резервное копирование

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

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

• Пропущено и не создано резервное FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS копирование, так как они имеют набор атрибутов.
• Отзыв на диск, что приводит к высоким затратам на исходящий трафик

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

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

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

Классификация данных

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

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

Это увеличивает число отзывов и объем отзыва данных, что может увеличить затраты.

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

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

Основные и вспомогательные версии агента

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

Обновление путей

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

• Используйте функцию автоматического обновления службы "Синхронизация файлов Azure" для установки обновлений агента: агент синхронизации файлов Azure автоматически обновляется. Вы можете установить последнюю версию агента, если она доступна или обновить, когда текущий установленный агент близок к истечении срока действия. Дополнительные сведения см. в следующем разделе: автоматическое управление жизненным циклом агента.
• Настройте Центр обновления Майкрософт для автоматического скачивания и установки обновлений агента. Мы рекомендуем установить каждое обновление службы "Синхронизация файлов Azure", чтобы обеспечить доступ к последним исправлениям агента сервера. Центр обновления Майкрософт упрощает этот процесс, автоматически скачивая и устанавливая обновления.
• Используйте AfsUpdater.exe для скачивания и установки обновлений агента: AfsUpdater.exe файл находится в каталоге установки агента. Дважды щелкните исполняемый файл, чтобы скачать и установить обновления агента. В зависимости от версии выпуска может потребоваться перезапустить сервер.
• Исправление существующего агента синхронизации файлов Azure с помощью файла исправлений Центра обновления Майкрософт или исполняемого файла MSP: вы можете скачать последний пакет обновления синхронизации файлов Azure из каталога центра обновления Майкрософт. При выполнении исполняемого файла MSP выполняется обновление установки синхронизации файлов Azure с тем же методом, который microsoft Update использует автоматически. Применение исправления Microsoft Update выполняет обновление на месте установки синхронизации файлов Azure.
• Скачайте самый новый установщик агента синхронизации файлов Azure: вы можете получить установщик в Центре загрузки Майкрософт. Чтобы обновить существующую установку агента синхронизации файлов Azure, удалите старую версию и установите последнюю версию из скачаемого установщика. Параметры агента (например, регистрация сервера и конечные точки сервера) сохраняются при удалении агента синхронизации файлов Azure.

Автоматическое управление жизненным циклом агента

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

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

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

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

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

Изменение параметра автоматического обновления

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

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

cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll

Можно запустить командлет Get-StorageSyncAgentAutoUpdatePolicy, чтобы проверить текущую настройку политики и определить, нужно ли ее изменить.

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

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration

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

Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>

Гарантии относительно жизненного цикла агента и управления изменениями

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

• Основные версии программного обеспечения агента поддерживаются не менее 12 месяцев с даты первоначального выпуска.
• Существует перекрытие по крайней мере 3 месяца между поддержкой основных версий агента.
• Предупреждения выдаются для зарегистрированных серверов черезto-be истекший срок действия агента по крайней мере через 3 месяца до истечения срока действия. Можно проверить, использует ли зарегистрированный сервер более раннюю версию агента в разделе о зарегистрированных серверах в службе синхронизации хранилища.
• Срок жизни минорной версии агента привязан к основной версии. Например, если агент версии 18.0.0.0.0 истекает, срок действия агента версии 18.*.*.* истекает вместе.

Связанный контент

• Параметры прокси-сервера синхронизации файлов Azure и брандмауэра
• Создание общей папки SMB Azure
• Развертывание Azure File Sync
• Мониторинг Синхронизации файлов Azure