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

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

  • Статья

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

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

Необходимые компоненты

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

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

    • Параметры безопасности SMB должны разрешать версию протокола SMB 3.1.1, проверку подлинности NTLM версии 2 и шифрование AES-128-GCM. Чтобы проверить параметры безопасности SMB в учетной записи хранения, см. раздел Параметры безопасности SMB.
    • Задайте для параметра Разрешить доступ к ключу учетной записи хранения значение Включено. Чтобы проверить этот параметр, перейдите к учетной записи хранения и выберите "Конфигурация" в разделе "Параметры".

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

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

    Примечание.

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

  5. Хотя управление облаком можно сделать с помощью портал Azure, расширенные функции зарегистрированного сервера предоставляются с помощью командлетов PowerShell, которые предназначены для локального выполнения в PowerShell 5.1 или PowerShell 6+. В Windows Server 2012 R2 можно убедиться, что вы используете по крайней мере PowerShell 5.1.* , просмотрев значение свойства PSVersion объекта $PSVersionTable:

    $PSVersionTable.PSVersion

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

    PowerShell 6+ используется с любой поддерживаемой системой, его можно скачать на странице GitHub.

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

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

Примечание.

Этот шаг можно пропустить при развертывании службы Синхронизация файлов Azure в Windows Server Core.

  1. Откройте диспетчер сервера.
  2. Щелкните Локальный сервер:
    Элемент
  3. Перейдите по ссылке Конфигурация усиленной безопасности Internet Explorer на вложенной панели Свойства.
    Область
  4. В диалоговом окне Конфигурация усиленной безопасности Internet Explorer установите переключатель Выкл. в разделе Администраторы и Пользователи.
    Всплывающее окно

Развертывание службы синхронизации хранилища

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

Примечание.

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

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

В открывшейся области введите следующие сведения:

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

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

Установка агента Синхронизации файлов Azure

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

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

Внимание

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

Таким образом, мы рекомендуем сделать следующее:

  • Оставьте путь установки по умолчанию (C:\Program Files\Azure\StorageSyncAgent), чтобы упростить устранение неполадок и обслуживание сервера.
  • Включить Центр обновления Майкрософт, чтобы служба синхронизации файлов Azure поддерживалась в актуальном состоянии. Все обновления агента Синхронизация файлов Azure, включая обновления компонентов и исправления, происходят из Центра обновления Майкрософт. Мы рекомендуем установить последнее обновление для службы "Синхронизация файлов" Azure. Дополнительные сведения см. в разделе Политика обновления Синхронизации файлов Azure.

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

Регистрация Windows Server в службе синхронизации хранилища

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

Примечание.

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

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

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

  • Microsoft.StorageSync/storageSyncServices/registeredServers/write
  • Microsoft.StorageSync/storageSyncServices/read
  • Microsoft.StorageSync/storageSyncServices/workflows/read
  • Microsoft.StorageSync/storageSyncServices/workflows/operations/read

Пользовательский интерфейс регистрации сервера должен открываться автоматически после установки агента Синхронизация файлов Azure. Если это не так, его можно открыть вручную из расположения файла: C:\Program Files\Azure\StorageSyncAgent\ServerRegistration.exe После открытия пользовательского интерфейса регистрации сервера выберите Вход, чтобы приступить к работе.

После входа вам будет предложено получить следующие сведения:

Снимок экрана пользовательского интерфейса регистрации сервера

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

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

Создание группы синхронизации и конечной точки облака

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

Конечная точка облака является указателем файлового ресурса Azure. Все конечные точки сервера будут синхронизироваться с облачной конечной точкой, превращая ее в центр. Учетная запись хранения файлового ресурса Azure должна располагаться в том же регионе, что и служба синхронизации хранилища. Общий файловый ресурс Azure будет синхронизирован с одним исключением: будет подготовлена специальная папка, сопоставимая со скрытой папкой "System Volume Information" на томе NTFS. Этот каталог называется ".SystemShareInformation". Он содержит важные метаданные синхронизации, которые не будут синхронизироваться с другими конечными точками. Не используйте или не удалите его!

Внимание

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

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

Чтобы создать группу синхронизации, на портале Azure перейдите к службе синхронизации хранилища и выберите +Группа синхронизации:

Создание группы синхронизации на портале Azure

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

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

Создание конечной точки сервера

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

  • Конечная точка сервера должна быть определена с помощью пути на зарегистрированном сервере (не подключенной общей папкой). Подключенное к сети хранилище (NAS) не поддерживается.
  • Хотя конечная точка сервера может находиться в системном томе, конечные точки сервера на системном томе не могут использовать распределение по уровням облака.
  • Изменение пути или буквы диска после установки конечной точки сервера на томе не поддерживается. Убедитесь, что вы используете окончательный путь на зарегистрированном сервере.
  • Зарегистрированный сервер может поддерживать несколько конечных точек сервера. Однако группа синхронизации может иметь только одну конечную точку сервера на зарегистрированный сервер в любое время. Другие конечные точки сервера в группе синхронизации должны принадлежать разным зарегистрированным серверам.

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

Снимок экрана: колонка

  • Зарегистрированный сервер. Имя сервера или кластера для создания конечной точки сервера.
  • Путь: путь к Windows Server, который будет синхронизироваться с общей папкой Azure. Путь может быть папкой (например, D:\Data), корневым томом (например, D:\) или точкой подключения тома (например, D:\Mount).
  • Уровни в облаке. Параметр, позволяющий включать и отключать распределение по уровням облака. С помощью этого параметра редко используемые файлы можно распределить по уровням компонента "Файлы Azure". Когда вы включаете распределение по уровням в облаке, вы можете настроить две политики, чтобы информировать Синхронизацию файлов Azure о том, когда следует распределять редко используемые файлы по уровням: политику свободного пространства тома и политику дат.
    • Свободное место тома. Объем свободного места, резервируемого на томе, где расположена конечная точка сервера. Например, если объем свободного места тома с одной конечной точкой сервера равен 50 %, примерно половина объема данных будет распределена по уровням "Файлов Azure". Независимо от того, включено ли распределение по уровням в облаке, общий файловый ресурс Azure всегда содержит полную копию данных в группе синхронизации.
    • Политика дат. Файлы будут распределены по уровням в облако, если к ним не обращались (т. е. не выполняли с ними операции чтения или записи) в течение указанного количества дней. Например, если вы заметили, что файлы с более чем 15 днями без доступа обычно являются архивными файлами, следует задать для политики даты значение 15 дней.
  • Начальная синхронизация. Раздел "Начальная синхронизация" доступен только для первой конечной точки сервера в группе синхронизации (раздел меняется на "Начальное скачивание" при создании нескольких конечных точек сервера в группе синхронизации). В разделе "Начальная синхронизация" можно выбрать поведение Начальная отправка и Начальное скачивание.

    • Начальная отправка: вы можете выбрать, как сервер изначально отправляет данные в общую папку Azure:

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

      Дополнительные сведения см. в разделе "Начальная синхронизация".

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

      • Вариант 1. Сначала скачайте пространство имен, а затем передайте содержимое файлов в том объеме, в котором оно может быть размещено на локальном диске.
      • Вариант 2. Скачайте только пространство имен. Содержимое файлов будет передаваться при обращении к ним.
      • Вариант 3. Избегайте использовать многоуровневые файлы. Файлы будут отображаться только на сервере после полного скачивания.

      Дополнительные сведения см. в разделе "Начальное скачивание".

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

Примечание.

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

(Необязательно.) Настройка параметров брандмауэра и виртуальной сети

Портал

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

  1. На портале Azure перейдите к учетной записи хранения, которую нужно защитить.

  2. В меню слева выберите Сеть.

  3. Щелкните Выбранные сети разделе Разрешить доступ из.

  4. Убедитесь, что IP-адрес сервера или виртуальная сеть указаны в разделе Диапазон адресов.

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

  6. Нажмите кнопку Save (Сохранить), чтобы сохранить настройки.

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

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

Предыдущие версии — это функция Windows, которая позволяет использовать моментальные снимки VSS тома на стороне сервера для представления восстанавливаемых версий файла клиенту SMB. Это позволяет реализовать эффективный сценарий, который обычно называют "автоматическое резервное копирование и самостоятельное восстановление", непосредственно для информационных работников и не зависеть от ИТ-администратора в вопросах восстановления.

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

Import-Module '<SyncAgentInstallPath>\StorageSync.Management.ServerCmdlets.dll'
Enable-StorageSyncSelfServiceRestore [-DriveLetter] <string> [[-Force]]

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

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

Примечание.

При этом необходимо обратить внимание на два важных момента.

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

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

Get-StorageSyncSelfServiceRestore [[-Driveletter] <string>]

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

Примечание.

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

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

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

Если не более 64 моментальных снимков VSS на том не является правильным параметром, измените это значение с помощью раздела реестра. Для вступления нового предела в силу нужно повторно запустить командлет, включающий совместимость с предыдущими версиями для всех томов, где эта функция была включена ранее, с флагом -Force, чтобы применить новое максимальное число моментальных снимков VSS на том. Это приведет к расчету нового числа совместимых дней. Это изменение вступит в силу только для новых многоуровневых файлов и перезаписывает все настройки в расписании VSS, которые вы могли сделать.

Моментальные снимки VSS по умолчанию могут использовать до 10 % пространства тома. Чтобы настроить объем хранилища, который можно использовать для моментальных снимков VSS, используйте команду vssadmin resize shadowstorage.

(Необязательно.) Упреждающий отзыв новых и измененных файлов из общей папки Azure

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

Сценарий

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

Внимание

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

Включение упреждающего отзыва изменений в общей папке Azure конечной точкой сервера

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

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

(Необязательно.) SMB на базе QUIC на конечной точке сервера

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

Эта конфигурация крайне распространена в средах, где существенная часть пользователей удалена. Традиционно доступ к любой общей папке с помощью SMB через общедоступный Интернет, включая оба файловых ресурса, размещенные на файловом сервере Windows или в Файлы Azure напрямую, может быть трудно, так как многие организации и поставщики услуг блокируют порт 445. Это ограничение можно обойти, используя частные конечные точки и VPN, однако операционная система Windows Server 2022 Azure Edition предоставляет дополнительную стратегию доступа: SMB по протоколу QUIC.

При подключении по SMB на базе QUIC обмен данными происходит через порт 443, открытый для трафика HTTPS в большинстве организаций и поставщиков интернет-услуг. Использование SMB на базе QUIC значительно упрощает сетевые взаимодействия, необходимые для доступа к общей папке, размещенной на конечной точке сервера службы "Синхронизация файлов Azure" для клиентов, использующих Windows 11 или более поздние версии. Дополнительные сведения о настройке и конфигурации SMB в туннеле QUIC на Windows Server Azure Edition см. в статье SMB на базе QUIC для файлового сервера Windows.

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

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

  1. Разверните службу синхронизации хранилища.
  2. Создайте группу синхронизации.
  3. Установите агент службы синхронизации файлов Azure на сервере с полным набором данных.
  4. Зарегистрируйте этот сервер и создайте конечную точку сервера на общем ресурсе.
  5. Дождитесь, пока служба синхронизация выполнит полную отправку данных на общий файловый ресурс Azure (в облачную конечную точку).
  6. После завершения первоначальной отправки установите агент синхронизации файлов Azure на всех оставшихся серверах.
  7. Создайте новые общие файловые ресурсы на всех оставшихся серверах.
  8. Создайте серверные конечные точки на новых файловых ресурсах с политикой распределения по уровням облака, если необходимо. (Для этого требуется дополнительное хранилище, доступное для первоначальной настройки.)
  9. Дождитесь, пока агент Синхронизации файлов Azure выполнит быстрое восстановление полного пространства имен без передачи фактических данных. После полной синхронизации пространства имен служба синхронизации заполнит место на локальном диске на основе политики распределения по уровням облака для серверной конечной точки.
  10. Дождитесь завершения синхронизации и протестируйте топологию нужным образом.
  11. Перенаправьте пользователей и приложения в новую общую папку.
  12. При необходимости можно удалить все повторяющиеся общие папки на серверах.

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

  1. Убедитесь, что данные на любом сервере не будут изменяться в ходе подключения.
  2. Предварительно поместите данные сервера в общие папки Azure с помощью любого средства передачи данных по протоколу SMB, например Robocopy, или AzCopy через REST. Если вы используете Robocopy, убедитесь, что вы подключаете общие папки Azure с помощью ключа доступа к учетной записи хранения, а не удостоверения домена. Если вы используете AzCopy, обязательно задайте соответствующие параметры для сохранения меток времени и атрибутов списков ACL.
  3. Создайте топологию службы синхронизации файлов Azure с нужными серверными конечными точками, указывающими на существующие общие папки.
  4. Дождитесь, пока процесс синхронизации завершит сверку на всех конечных точках.
  5. После этого можно открыть общие ресурсы для внесения изменений.

В настоящее время предзасадка имеет несколько ограничений:

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

Перенос развертывания репликации DFS (DFS-R) в службу синхронизации файлов Azure

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

  1. Создайте группу синхронизации для представления топологии DFS-R, которую вы заменяете.
  2. Начните с сервера с полным набором данных в топологии DFS-R, которую следует перенести. Установите службу "Синхронизация файлов" Azure на этом сервере.
  3. Зарегистрируйте этот сервер и создайте серверную конечную точку для переноса первого сервера. Не включайте распределение по уровням облака.
  4. Выполните синхронизацию всех данных с файловым ресурсом Azure (облачной конечной точкой).
  5. Установите и зарегистрируйте агент синхронизации файлов Azure на каждом из оставшихся серверов DFS-R.
  6. Отключите DFS-R.
  7. Создайте серверную конечную точку на каждом из серверов DFS-R. Не включайте распределение по уровням облака.
  8. Дождитесь завершения синхронизации и протестируйте топологию нужным образом.
  9. Снимите DFS-R с учета.
  10. Теперь вы можете включить распределение по уровням в облаке на любой конечной точке сервера по мере необходимости.

Дополнительные сведения см. в статье Azure File Sync interop with Distributed File System (DFS) (Взаимодействие службы "Синхронизация файлов Azure" с распределенной файловой системой (DFS)).

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