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

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

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

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

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

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

• Файловое хранилище Azure: Файловое хранилище Azure — это бессерверное облачное файловое хранилище, которое предоставляет облачную конечную точку для отношений синхронизации в Azure File Sync. Доступ к файлам в общей папке Azure можно получать напрямую с помощью протокола SMB или FileREST, хотя рекомендуется обращаться к файлам через кэш Windows Server, когда общая папка Azure используется со службой "Синхронизация файлов Azure". Это связано с тем, что на сегодняшний день в службе "Файлы Azure" отсутствует эффективный механизм обнаружения изменений, например такой как в Windows Server, поэтому изменения в общей папке Azure будут распространяться обратно на конечные точки сервера.
• Конечная точка сервера. Путь на Windows Server, который синхронизируется с общей папкой Azure. Это может быть конкретная папка на томе или корень тома. Несколько конечных точек сервера могут существовать на одном томе, если их пространства имён не пересекаются.
• Группа синхронизации. Объект, определяющий отношение синхронизации между облачной конечной точкой или общей папкой Azure, а также конечной точкой сервера. Конечные точки внутри группы синхронизации поддерживают синхронность друг с другом. Если, например, есть два отдельных набора файлов, которыми можно управлять с помощью службы "Синхронизация файлов Azure", следует создать две группы синхронизации и добавить различные конечные точки для каждой.

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

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

Есть два основных типа учетных записей хранения, которые будут использоваться для развертывания службы "Файлы Azure":

• Учетные записи хранения общего назначения версии 2. Такие учетные записи хранения позволяют развертывать общие папки Azure на оборудовании на основе жестких дисков (HDD) уровня "Стандартный". В дополнение к хранению общих папок Azure, учетные записи хранения GPv2 могут содержать и другие ресурсы хранилища, такие как контейнеры больших двоичных объектов, очереди и таблицы.
• Учетные записи хранения FileStorage. Такие учетные записи хранения позволяют развертывать общие папки Azure на оборудовании на основе твердотельных накопителей (SSD) уровня "Премиум". Учетные записи FileStorage можно использовать только для хранения общих папок Azure. Другие ресурсы хранилища (контейнеры больших двоичных объектов, очереди, таблицы и т. д.) нельзя развертывать в учетной записи FileStorage. Только учетные записи FileStorage могут развертывать общие папки SMB и NFS, так как NFS поддерживается только в общих папках класса Premium.

Есть несколько других типов учетных записей хранения, которые поддерживаются на портале Azure, в PowerShell и CLI. В двух из них (BlockBlobStorage и BlobStorage) хранить общие папки Azure нельзя. Два других типа учетных записей хранения, которые вы можете увидеть, — это учетные записи хранения общего назначения версии 1 и классические учетные записи хранения, и оба типа могут содержать общие папки Azure. Хотя в учетных записях хранения GPv1 и классического типа могут содержаться общие ресурсы Azure File, большинство новых возможностей Azure Files доступны только в учетных записях хранения общего назначения версии 2 и FileStorage. Поэтому мы рекомендуем использовать только учетные записи хранения GPv2 и FileStorage для новых развертываний, а если в вашей среде уже существуют учетные записи хранения общего назначения версии 1 и классические учетные записи хранения, обновить их.

Основные понятия в управлении Azure File Sync

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

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

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

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

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

Создавайте несколько служб синхронизации хранилища только в том случае, если у вас:

• отдельные наборы серверов, которые не должны обмениваться данными друг с другом. В этом случае необходимо разработать такую систему, которая исключает определенные наборы серверов из синхронизации с общей папкой Azure, которая уже используется как облачная конечная точка в группе синхронизации в другой службе синхронизации хранилища. С другой стороны, серверы Windows Server, зарегистрированные в другой службе синхронизации хранилища, не могут синхронизироваться с одной и той же общей папкой 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 File Sync и которые следует подготовить. Группа синхронизации связывает общую папку Azure и папку на сервере и устанавливает соединение для синхронизации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

*Требуется скачивание и установка Windows Management Framework (WMF) 5.1. Соответствующий пакет скачивания и установки для Windows Server 2012 R2 — это Win8.1AndW2K12R2-KB*******-x64.msu.

Новые версии Windows Server будут добавляться по мере их выпуска.

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

Для синхронизации файлов Azure требуется сервер ( физический или виртуальный) с хотя бы одним ЦП, не менее 2 ГиБ памяти и локально подключенным томом, отформатированным файловой системой NTFS.

Для большинства рабочих нагрузок мы не рекомендуем настраивать сервер синхронизации Azure File Sync только с минимальными требованиями. Дополнительные сведения см. в разделе Рекомендуемые системные ресурсы.

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

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

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

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

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

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

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

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

Командлет оценки можно установить, инсталлировав модуль Azure 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.

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

Подумайте, сколько свободного места вам требуется на локальном диске

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

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

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

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

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

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

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

1. NTFS выделяет размер кластера для каждого многоуровневого файла. 1 миллион файлов * 4 КиБ размера кластера = 4000 000 КиБ (4 ГиБ)

   Примечание.

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

2. Метаданные синхронизации занимают размер кластера для каждого элемента. (1 миллион файлов + 100 000 каталогов) * размер кластера 4 КиБ = 4 400 000 КиБ (4,4 ГиБ)
3. Хранилище Синхронизации файлов Azure занимает 1,1 КБ на файл. 1 миллион файлов * 1,1 КиБ = 1 100 000 КиБ (1,1 ГиБ)
4. Объем свободного пространства составляет 20%. 1000 ГиБ * 0,2 = 200 ГиБ

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

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

1. Служба синхронизации файлов Azure поддерживает отказоустойчивую кластеризацию Windows Server для варианта развертывания "Файловый сервер общего использования". Дополнительные сведения о настройке роли "Файловый сервер для общего использования" в отказоустойчивом кластере см. в разделе Развертывание кластеризованного файлового сервера с двумя узлами.
2. Единственный сценарий, поддерживаемый Azure File Sync, это отказоустойчивый кластер Windows Server с кластеризованными дисками.
3. Отказоустойчивый кластер не поддерживается на "Масштабируемом файловом сервере для данных приложения" (SOFS), кластеризованных общих томах (CSV) или локальных дисках.

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

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

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

Обратите внимание, что экономия томов применяется только к серверу; данные в общей папке Azure не будут дедупированы.

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sysprep

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

Поиск Windows

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

Другие решения по управлению иерархическим хранением (HSM)

Другие решения HSM не нужно использовать со службой синхронизации файлов Azure.

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

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

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

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

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

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

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

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

Сеть

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

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

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

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

Шифрование

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

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

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

Чтобы обеспечить шифрование под файловой системой, Windows Server предоставляет входящую папку BitLocker. BitLocker полностью прозрачен для Azure File Sync. Основная причина использования механизма шифрования, такого как BitLocker, заключается в предотвращении физического хищения данных из локального центра обработки данных кем-то, кто украл диски, а также в предотвращении установки неавторизованной ОС для выполнения несанкционированных операций чтения и записи данных. Дополнительные сведения о BitLocker см. в статье Обзор BitLocker.

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

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

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

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

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

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

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

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

Дополнительные сведения о шифровании при передаче см. в статье Require secure transfer in Azure Storage (Требование безопасной передачи в службе хранилища Azure).

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

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

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

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

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

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

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

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

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

Создав файловый ресурс в учетной записи хранения, вы не сможете напрямую переместить его на другой уровень хранения. Например, чтобы переместить общую папку HDD на уровень мультимедиа SSD, необходимо создать новую общую папку SSD и скопировать данные из исходной общей папки в новую общую папку в учетной записи FileStorage. Для копирования данных между общими папками Azure мы рекомендуем использовать AzCopy, но вы также можете использовать такие средства, как robocopy в Windows или rsync в macOS и Linux.

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

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

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

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

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

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

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

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

• Локально избыточное хранилище (LRS). При использовании LRS в кластере хранилища Azure сохраняются три копии каждого файла. Это защищает от потери данных из-за сбоев оборудования, таких как плохой диск. Однако если в центре обработки данных возникает катастрофа, например пожар или наводнение, все реплики учетной записи хранения с помощью LRS могут быть потеряны или невосстановлены.
• Хранилище, избыточное между зонами (ZRS): с помощью ZRS хранятся три копии каждого файла. Однако эти копии физически изолированы в трех разных кластерах хранения в разных зонах доступности Azure. Зоны доступности — уникальные физические расположения в пределах одного региона Azure. Каждая зона состоит из одного или нескольких центров обработки данных, обеспеченных независимыми системами электропитания, охлаждения и сетями. Запись в хранилище не принимается, пока она не будет записана в кластеры хранения во всех трех зонах доступности.
• Геоизбыточное хранилище (GRS): с GRS у вас есть два региона, основной регион и дополнительный регион. В кластере хранилища Azure в основном регионе хранятся три копии каждого файла. Операции записи асинхронно реплицируются в определенный корпорацией Майкрософт вторичный регион. GRS предоставляет шесть копий данных, распределенных между двумя регионами Azure. Если произойдет серьезная катастрофа, например, постоянная потеря региона Azure из-за стихийного бедствия или другого подобного события, корпорация Майкрософт осуществит переключение на резервную систему. В этом случае вторичный становится основным, обслуживая все операции. Поскольку репликация между основным и вторичным регионами является асинхронной, в случае серьезной аварии данные, которые еще не были реплицированы во вторичный регион, будут утеряны. Вы также можете выполнить переход учетной записи хранения с геоизбыточным хранилищем на другой ресурс вручную.
• Геоизбыточное хранилище (GZRS): вы можете рассматривать GZRS как ZRS, но с геоизбыточностью. В GZRS три копии каждого файла хранятся в трех отдельных кластерах хранилища в основном регионе. Все операции записи затем асинхронно реплицируются в определенный корпорацией Майкрософт дополнительный регион. Процесс резервирования для GZRS работает аналогично GRS.

Стандартные общие файлы поддерживают все четыре типа избыточности. Файловые хранилища класса Premium поддерживают только LRS и ZRS.

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

Миграция

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

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

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

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

Антивирусные решения Microsoft — Защитник Windows и System Center Endpoint Protection (SCEP) автоматически пропускают чтение файлов с установленным атрибутом. В ходе их тестирования обнаружилась небольшая проблема — при добавлении сервера в существующую группу синхронизации файлы размером меньше 800 байт отзываются (скачиваются) на новый сервер. Эти файлы останутся на новом сервере и не будут перемещены по уровням хранения, так как они не соответствуют требованиям к размеру для хранения по уровням (>64 КБ).

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

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

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

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

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

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

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

Увеличение количества отзывов и объема вызываемых данных может повысить затраты.

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

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

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

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

Варианты обновления

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

1. Используйте функцию автоматического обновления агента Синхронизация файлов Azure для установки обновлений агента. Агент Azure File Sync обновляется автоматически. Вы можете установить последнюю версию агента, если она доступна, или обновить его по мере истечении срока действия установленной версии. Дополнительные сведения см. в статье Автоматическое управление жизненным циклом агента.
2. Настройте Центр обновлений Майкрософт для автоматической загрузки и установки обновлений агента. Рекомендуется устанавливать все обновления службы синхронизации файлов в Azure, чтобы гарантировать наличие последних исправлений для агента сервера. Центр обновления Майкрософт упрощает этот процесс, автоматически скачивая и устанавливая обновления.
3. Используйте AfsUpdater.exe для скачивания и установки обновлений агента. AfsUpdater.exe находится в каталоге установки агента. Дважды щелкните исполняемый файл, чтобы скачать и установить обновления агента. В зависимости от версии выпуска может потребоваться перезапустить сервер.
4. Установка исправлений для существующего агента "Синхронизация файлов Azure" посредством файла исправлений Центра обновления Майкрософт или исполняемого файла .msp. Последний пакет обновлений для службы "Синхронизация файлов Azure" можно скачать из Каталога Центра обновления Майкрософт. При запуске .msp исполняемого файла обновляется установка Azure File Sync тем же методом, который автоматически используется Центром обновления Майкрософт. Применение исправления Microsoft Update выполняет локальное обновление установки Azure File Sync.
5. Скачайте новый установщик агента Синхронизация файлов Azure из Центра загрузки Майкрософт. Для обновления существующей установки агента службы синхронизации файлов Azure удалите старую версию, а затем установите последнюю версию с помощью загруженного установщика. Параметры агента (регистрация сервера, конечные точки сервера и т. д.) сохраняются при удалении агента Синхронизация файлов Azure.

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

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

1. Параметр по умолчанию пытается предотвратить истечение срока действия агента. В течение 21 дней после окончания срока действия агента агент пытается выполнить самостоятельное обновление. Она запускает попытку обновить один раз в неделю в течение 21 дней до истечения срока действия и в выбранном периоде обслуживания. Этот параметр не устраняет необходимость в регулярных обновлениях Microsoft Update.
2. Дополнительно можно указать, чтобы агент автоматически обновлял себя как только станет доступной его новая версия (в настоящее время эта возможность неприменима к кластеризованным серверам). Это обновление происходит во время выбранного периода обслуживания и позволяет серверу воспользоваться новыми функциями и улучшениями, как только они становятся общедоступными. Это рекомендуемый параметр, не вызывающий беспокойства, который предоставляет основные версии агента и регулярные патчи обновлений вашему серверу. Каждый выпуск агента является высокого качества. Если вы выберете этот параметр, Microsoft выпустит вам самую новую версию агента. На кластеризованные серверы этот вариант не распространяется. После завершения полетов агент также станет доступен в Центре обновления Майкрософт и Центра загрузки Майкрософт.

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

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

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

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

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