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

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

• Напрямую подключите файловое хранилище Azure с помощью протокола Server Message Block (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 поддерживает синхронизацию корневого каталога тома с файловым ресурсом Azure. При синхронизации корневого каталога тома все вложенные папки и файлы отправляются в одну общую папку Azure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по работе с файловыми серверами 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, FAT32 и другие файловые системы не поддерживаются.

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

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

Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Invoke-StorageSyncFileRecall -FilePath <path>
compact /U /S <filepath>

Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
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 с функцией heatstore занимает 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 File Server, Cluster Shared Volumes (CSV) или на локальных дисках.

Для правильной работы синхронизации агент синхронизации файлов 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.

DFS-R

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

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

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

• В Синхронизация файлов Azure необходимо отключить облачное распределение по уровням для томов, содержащих реплицируемые папки 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 и списки управления доступом (ACL) в стиле 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, например Хранилище BLOB-объектов Azure. Все данные, хранящиеся в Файлы Azure, зашифрованы в состоянии покоя с помощью шифрования на стороне службы (SSE), которое работает аналогично BitLocker на Windows.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Геоизбыточное хранилище (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 дней до истечения срока действия и в выбранном окне обслуживания. Обратите внимание, что этот параметр не устраняет необходимости в регулярных патчах Microsoft Update.

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

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

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

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

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

Откройте консоль 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 месяца между поддержкой основных версий агента.
• Предупреждения выдаются для зарегистрированных серверов через агента, срок действия которого скоро истечет, по крайней мере за 3 месяца до истечения срока действия. Можно проверить, использует ли зарегистрированный сервер более раннюю версию агента в разделе о зарегистрированных серверах в службе синхронизации хранилища.
• Срок жизни минорной версии агента привязан к основной версии. Например, если агент версии 18.0.0.0 назначен на истечение срока действия, то агенты версии 18.*.*.* истекают одновременно.

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

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