Планирование развертывания службы синхронизации файлов Azure (предварительная версия)
Синхронизация файлов Azure — это служба, которая позволяет кэшировать несколько общих папок Azure на локальном сервере Windows Server или на облачной виртуальной машине.
В этой статье рассказывается о концепциях и возможностях Синхронизации файлов Azure. Как только вы знакомы с Синхронизация файлов Azure, рассмотрите возможность выполнения Синхронизация файлов Azure руководства по развертыванию, чтобы попробовать эту службу.
Файлы будут храниться в облаке в файловых ресурсах Azure. Общие папки Azure можно использовать двумя способами: путем прямого подключения этих бессерверных общих папок Azure (SMB) или путем кэширования общих папок Azure в локальной среде с помощью службы "Синхронизация файлов Azure". От выбора варианта развертывания зависят факторы, которые необходимо учитывать при планировании развертывания.
Прямое подключение общей папки Azure: так как Файлы Azure предоставляет доступ к SMB, вы можете подключить общие папки Azure локально или в облаке с помощью стандартного клиента SMB, доступного в Windows, macOS и Linux. Поскольку общие папки Azure работают без сервера, развертывание в рабочей среде не требует настройки файлового сервера или устройства NAS. Это означает, что вам не нужно применять исправления программного обеспечения или подключать физические диски.
Кэширование общей папки Azure локально с помощью службы "Синхронизация файлов Azure". Вы можете использовать службу "Синхронизация файлов Azure", чтобы централизованно хранить общие папки организации в службе "Файлы Azure", обеспечивая гибкость, производительность и совместимость локального файлового сервера. Это достигается путем преобразования локального или облачного Windows Server в быстрый кэш файлового ресурса Azure.
Основные принципы управления
Развертывание Синхронизации файлов Azure связано с тремя фундаментальными управляющими объектами:
- Общая папка Azure. Это бессерверная облачная общая папка, которая предоставляет облачную конечную точку для синхронизации в службе "Синхронизация файлов Azure". Доступ к файлам в общей папке Azure можно получать напрямую с помощью протокола SMB или FileREST, хотя рекомендуется обращаться к файлам через кэш Windows Server, когда общая папка Azure используется со службой "Синхронизация файлов Azure". Это связано с тем, что на сегодняшний день в службе "Файлы Azure" отсутствует эффективный механизм обнаружения изменений, например такой как в Windows Server, поэтому изменения в общей папке Azure будут распространяться обратно на конечные точки сервера.
- Конечная точка сервера. Путь на Windows Server, который синхронизируется с общей папкой Azure. Это может быть конкретная папка на томе или корень тома. Несколько конечных точек сервера могут существовать на одном томе, если их пространства имен не перекрываются.
- Группа синхронизации. Объект, определяющий отношение синхронизации между облачной конечной точкой или общей папкой Azure, а также конечной точкой сервера. Конечные точки в группе синхронизации синхронизируются. Если, например, есть два отдельных набора файлов, которыми можно управлять с помощью службы "Синхронизация файлов Azure", следует создать две группы синхронизации и добавить различные конечные точки для каждой.
Основные понятия управления файловым ресурсом Azure
Общие папки Azure развертываются в учетных записях хранения. Это объекты верхнего уровня, которые представляют общий пул хранилища. Пул хранилища можно использовать для развертывания нескольких общих папок и других ресурсов хранения, включая контейнеры больших двоичных объектов, очереди и таблицы. На все ресурсы хранилища, развернутые в учетной записи хранения, распространяются ограничения, которые применяются к этой учетной записи хранения. Сведения о текущих ограничениях учетной записи хранения см. d разделе Целевые показатели масштабируемости и производительности Файлов Azure.
Есть два основных типа учетных записей хранения, которые будут использоваться для развертывания службы "Файлы Azure":
- Учетные записи хранения общего назначения версии 2. Такие учетные записи хранения позволяют развертывать общие папки Azure на оборудовании на основе жестких дисков (HDD) уровня "Стандартный". Наряду с общими папками Azure такие учетные записи хранения поддерживают и другие ресурсы хранилища, включая контейнеры больших двоичных объектов, очереди и таблицы.
- Учетные записи хранения FileStorage. Такие учетные записи хранения позволяют развертывать общие папки Azure на оборудовании на основе твердотельных накопителей (SSD) уровня "Премиум". Учетные записи FileStorage можно использовать только для хранения общих папок Azure. Другие ресурсы хранилища (контейнеры больших двоичных объектов, очереди, таблицы и т. д.) нельзя развертывать в учетной записи FileStorage. Только учетные записи FileStorage позволяют развертывать общие папки SMB и NFS.
Есть несколько других типов учетных записей хранения, которые поддерживаются на портале Azure, в PowerShell и CLI. В двух из них (BlockBlobStorage и BlobStorage) хранить общие папки Azure нельзя. Два других типа учетных записей хранения, которые вы можете увидеть, — это учетные записи хранения общего назначения версии 1 и классические учетные записи хранения. Хотя они могут содержать общие папки Azure, большинство новых возможностей службы "Файлы Azure" доступны только в учетных записях хранения общего назначения версии 2 и учетных записях хранения FileStorage. Именно их рекомендуется использовать для новых развертываний, а также для обновления учетных записей хранения общего назначения версии 1 и классических учетных записей хранения, если они существуют в вашей среде.
Основные понятия управления в Синхронизации файлов Azure
Группы синхронизации развертываются в службах синхронизации хранилища, являющихся объектами верхнего уровня, которые регистрируют серверы для использования с Синхронизацией файлов Azure и содержат связи группы синхронизации. Ресурс службы синхронизации хранилища является одноранговым в отношении ресурса учетной записи хранения, поэтому его можно развернуть в группах ресурсов Azure. Служба синхронизации хранилища может создавать группы синхронизации, содержащие файловые ресурсы Azure в нескольких учетных записях хранения и нескольких зарегистрированных серверах Windows Server.
Прежде чем можно будет создать группу синхронизации в службе синхронизации хранилища, необходимо сначала зарегистрировать Windows Server в службе синхронизации хранилища. Будет создан объект зарегистрированный сервер, который представляет собой отношение доверия между сервером или кластером и службой синхронизации хранилища. Чтобы зарегистрировать службу синхронизации хранилища, необходимо сначала установить агент Синхронизации файлов Azure на сервере. Отдельный сервер или кластер можно зарегистрировать только в одной службе синхронизации хранилища.
Группа синхронизации содержит одну облачную конечную точку, файловый ресурс Azure и хотя бы одну конечную точку сервера. Объект конечной точки сервера содержит параметры для настройки распределения по уровням в облаке, что позволяет использовать возможность кэширования службы "Синхронизация файлов Azure. Для синхронизации с общими папками Azure учетная запись хранения, содержащая общие папки Azure, должна находиться в одном регионе со службой синхронизации хранилища.
Внимание
В группе синхронизации можно внести изменения в пространство имен любой облачной конечной точки и синхронизировать ваши файлы в другие конечные точки группы синхронизации. Если вы вносите изменения непосредственно в облачную конечную точку (общий файловый ресурс Azure), эти изменения сначала должны быть определены заданием обнаружения изменений службы "Синхронизация файлов Azure". Задание обнаружения изменений инициируется для облачной конечной точки каждые 24 часа. Дополнительные сведения см. в статье Часто задаваемые вопросы о службе файлов 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 поддерживает синхронизацию корня тома с общей папкой Azure. При синхронизации корня тома все вложенные папки и файлы отправляются в одну и ту же общую папку Azure.
Синхронизация корня тома не всегда представляет собой лучшее решение. Синхронизация нескольких расположений имеет свои преимущества. Например, она позволяет сократить количество элементов в одной области синхронизации. Тестирование общих папок Azure и службы синхронизации файлов Azure выполняется при 100 миллионах элементов (файлов и папок) в одной общей папке. Однако рекомендуется использовать не более 20–30 миллионов элементов в одной общей папке. Настройка Синхронизации файлов Azure с меньшим количеством элементов выгодна не только для синхронизации файлов. Уменьшение количества элементов также полезно в перечисленных ниже сценариях.
- Начальное сканирование содержимого облака может выполняться быстрее, что, в свою очередь, сократит время ожидания отображения пространства имен на сервере, где включена Синхронизация файлов Azure.
- Восстановление на стороне облака из моментального снимка общей папки Azure будет выполняться быстрее.
- Аварийное восстановление локального сервера может существенно ускориться.
- Обнаружение и синхронизация изменений, внесенных непосредственно в общей папке Azure (за пределами области синхронизации), могут выполняться быстрее.
Совет
Если вы не знаете, сколько у вас файлов и папок, воспользуйтесь инструментом TreeSize от JAM Software GmbH.
Структурированный подход к сопоставлению развертывания
Перед развертыванием облачного хранилища на более позднем этапе необходимо создать сопоставление между локальными папками и общими папками Azure. Из этого сопоставления будет понятно, сколько ресурсов группы синхронизации Синхронизации файлов Azure и какие из них необходимо подготовить к работе. Группа синхронизации связывает общую папку Azure и папку на сервере и устанавливает соединение для синхронизации.
Чтобы решить, сколько общих папок Azure вам нужно, ознакомьтесь с приведенными ниже ограничениями и рекомендациями. Это поможет вам оптимизировать сопоставление.
Сервер, на котором установлен агент Синхронизации файлов Azure, может выполнить синхронизацию с 30 общими папками Azure.
Общая папка Azure развертывается в учетной записи хранения. Это делает учетную запись хранения целевым объектом масштабирования для таких показателей производительности, как операции ввода-вывода в секунду и пропускная способность.
Обратите внимание на ограничения операций ввода-вывода в секунду учетной записи хранения при развертывании общих папок Azure. В идеале следует сопоставить общие папки 1:1 с учетными записями хранения. Однако это может быть не всегда возможно из-за различных ограничений и ограничений, как из вашей организации, так и из Azure. Если невозможно развернуть только одну общую папку в одной учетной записи хранения, рассмотрите, какие общие папки будут очень активными и какие общие папки будут менее активными, чтобы гарантировать, что самые горячие общие папки не помещают в одну учетную запись хранения вместе.
Если вы планируете перенести в Azure приложение, которое будет использовать общую папку Azure в собственном коде, от общей папки Azure может потребоваться большая производительность. Если такой тип использования возможен (пусть даже в будущем), рекомендуется создать одну стандартную общую папку Azure в собственной учетной записи хранения.
Одна подписка в одном регионе Azure может содержать не более 250 учетных записей хранения.
Совет
При этом в томах зачастую требуется сгруппировать несколько папок верхнего уровня в общий новый корневой каталог. Затем выполняется синхронизация этого нового корневого каталога и всех папок, сгруппированных в него, в одну общую папку Azure. Эта методика позволяет не превышать ограничения по количеству синхронизаций общих папок Azure на одном сервере (не более 30).
Такое группирование в общем корне не влияет на доступ к данным. Списки управления доступом остаются неизменными. Вам потребуется лишь скорректировать все пути к общим папкам (например, к общим папкам SMB или NFS) в локальных папках сервера, которые теперь имеют общий корень. Больше ничего не меняется.
Внимание
Самое важное направление масштабирования для Синхронизации файлов Azure — число элементов (файлов и папок), которые необходимо синхронизировать. Дополнительные сведения см. в статье Целевые показатели масштабируемости службы синхронизации файлов Azure.
В одной области синхронизации рекомендуется использовать небольшое количество элементов. Это важный фактор, который следует учитывать при сопоставлении папок с общими папками Azure. Тестирование службы синхронизации файлов Azure выполняется при 100 миллионах элементов (файлов и папок) в одной общей папке. Однако, как правило, рекомендуется использовать не более 20–30 миллионов элементов в одной общей папке. В случае превышения этих цифр разделите пространство имен на несколько общих папок. Если в общем и целом эти цифры не превышены, вы можете продолжить группирование локальных общих папок в одну и ту же общую папку Azure. Такая методика оставляет пространство для роста.
В вашей ситуации возможна логическая синхронизация набора папок с одной и той же общей папкой Azure (с использованием упомянутого выше подхода с новой общей корневой папкой). Тем не менее все равно рекомендуется перегруппировать папки так, чтобы они синхронизировались с двумя, а не с одной общей папкой Azure. Такой подход обеспечивает равномерное распределение файлов и папок по общим папкам на сервере. Вы также можете разделить локальные общие папки и выполнить синхронизацию с несколькими локальными серверами. Это дает возможность синхронизации с еще 30 общими папками Azure на каждом дополнительном сервере.
Распространенные сценарии синхронизации файлов и рекомендации
| # | Сценарий синхронизации | Поддерживается | Рекомендации (или ограничения) | Решение (или обходное решение) |
|---|---|---|---|---|
| 1 | Файловый сервер с несколькими дисками и томами и несколькими общими ресурсами для одной целевой общей папки Azure (консолидация) | No | Целевая файловая папка Azure (конечная точка облака) поддерживает синхронизацию только с одной группой синхронизации. Группа синхронизации поддерживает только одну конечную точку сервера на зарегистрированный сервер. |
1. Начните с синхронизации одного диска (корневого тома) для целевого файлового ресурса Azure. Начиная с самого большого диска или тома, требования к хранилищу будут соответствовать локальным требованиям. Настройте распределение по уровням в облаке для распределения всех данных в облако, тем самым освобождая место на диске файлового сервера. Переместите данные из других томов или общих папок в текущий том, который синхронизируется. Продолжайте шаги по одному до тех пор, пока все данные не будут многоуровневы до облака или перенесены. 2) Нацелив один корневой том (диск) за раз. Используйте распределение по уровням облака для распределения всех данных для целевого файлового ресурса Azure. Удалите конечную точку сервера из группы синхронизации, повторно создайте конечную точку со следующим корневым томом или диском, синхронизацией и повторите процесс. Примечание. Может потребоваться повторная установка агента. 3. Рекомендуется использовать несколько целевых общих папок Azure (одну или другую учетную запись хранения на основе требований к производительности). |
| 2 | Файловый сервер с одним томом и несколькими общими ресурсами для одной целевой общей папки Azure (консолидация) | Да | Не удается синхронизировать несколько конечных точек сервера на зарегистрированный сервер, синхронизированный с одной целевой общей папкой Azure (аналогично приведенной выше). | Синхронизировать корневой каталог тома, включающего несколько общих папок или папок верхнего уровня. Дополнительные сведения см. в разделе "Общие понятия группирования" и синхронизации томов. |
| 3 | Файловый сервер с несколькими общими папками и (или) томами для нескольких общих папок Azure в рамках одной учетной записи хранения (сопоставление общих папок 1:1) | Да | Один экземпляр Windows Server (или кластер) может синхронизировать до 30 общих папок Azure. Учетная запись хранения — это целевой объект масштабирования для производительности. Операции ввода-вывода в секунду и пропускная способность получают общий доступ между общими файловыми ресурсами. Сохраняйте количество элементов для каждой группы синхронизации в пределах 100 миллионов элементов (файлов и папок) на общую папку. В идеале лучше всего остаться ниже 20 или 30 миллионов на акцию. |
1) Использование нескольких групп синхронизации (число групп синхронизации = количество общих папок Azure для синхронизации). 2) Синхронизировано только 30 общих папок в этом сценарии одновременно. Если на этом файловом сервере более 30 общих папок, используйте концепцию группирования общих ресурсов и синхронизацию томов, чтобы уменьшить количество корневых или верхних папок в источнике. 3) Использование дополнительных Синхронизация файлов серверов локальной среды и разделения и перемещения данных на эти серверы для обхода ограничений на исходном сервере Windows. |
| 4 | Файловый сервер с несколькими общими ресурсами и (или) томами для нескольких общих папок Azure в разных учетных записях хранения (сопоставление общих папок 1:1) | Да | Один экземпляр Windows Server (или кластер) может синхронизировать до 30 общих папок Azure (одной или другой учетной записи хранения). Сохраняйте количество элементов для каждой группы синхронизации в пределах 100 миллионов элементов (файлов и папок) на общую папку. В идеале лучше всего остаться ниже 20 или 30 миллионов на акцию. |
Тот же подход, что и выше |
| 5 | Несколько файловых серверов с одним (корневым томом или общим ресурсом) для одной целевой общей папки Azure (консолидация) | No | Группа синхронизации не может использовать облачную конечную точку (общую папку Azure), уже настроенную в другой группе синхронизации. Хотя группа синхронизации может иметь конечные точки сервера на разных файловых серверах, файлы не могут отличаться. |
Следуйте указаниям в сценарии 1 выше с дополнительным вниманием к тому, чтобы нацелить один файловый сервер одновременно. |
Создание таблицы сопоставления
Воспользуйтесь приведенной выше информацией, чтобы определить, сколько общих папок Azure вам нужно и какие элементы существующих данных в каких общих папках Azure окажутся.
Создайте таблицу, содержащую ваши идеи, и обращайтесь к ней при необходимости. Упорядоченность важна, поскольку при одновременной подготовке нескольких ресурсов Azure можно потерять подробности плана сопоставления. Скачайте следующий файл Excel, чтобы использовать его в качестве шаблона для создания сопоставления.
|
Скачайте шаблон сопоставления пространства имен. |
Рекомендации по файловому серверу Windows
Чтобы включить функцию синхронизации в Windows Server, необходимо установить загружаемый агент Синхронизации файлов Azure. Агент Синхронизация файлов Azure предоставляет два основных компонента: FileSyncSvc.exeфоновую службу Windows, которая отвечает за мониторинг изменений на конечных точках сервера и инициировании сеансов синхронизации, а также StorageSync.sysфильтр файловой системы, обеспечивающий распределение по уровням в облаке и быстрое аварийное восстановление.
Требования к операционной системе
Синхронизация файлов Azure поддерживается в следующих версиях Windows Server:
| Версия | Поддерживаемые номера SKU | Поддерживаемые варианты развертывания |
|---|---|---|
| Windows Server 2025 | Azure, Datacenter, Essentials, Standard и IoT | Полный и базовый |
| Windows Server 2022 | Azure, Datacenter, Essentials, Standard и IoT | Полный и базовый |
| Windows Server 2019 | Центр обработки данных, Основные сведения, Стандартный и IoT | Полный и базовый |
| Windows Server 2016 | Центр обработки данных, Основные компоненты, стандартный и сервер хранилища | Полный и базовый |
| Windows Server 2012 R2* | Центр обработки данных, Основные компоненты, стандартный и сервер хранилища | Полный и базовый |
*Требуется скачивание и установка Windows Management Framework (WMF) 5.1. Соответствующий пакет скачивания и установки для Windows Server 2012 R2 — это Win8.1AndW2K12R2-KB*******-x64.msu.
Новые версии Windows Server будут добавляться по мере их выпуска.
Внимание
Мы рекомендуем постоянно обновлять серверы, используемые со службой синхронизации файлов Azure, с помощью последних обновлений из Центра обновления Windows.
Минимальные системные ресурсы
Для синхронизации файлов Azure требуется сервер ( физический или виртуальный) с хотя бы одним ЦП, не менее 2 ГиБ памяти и локально подключенным томом, отформатированным файловой системой NTFS.
Внимание
Если сервер выполняется на виртуальной машине с включенной динамической памятью, в виртуальной машине должна быть настроена память объемом не менее 2048 МиБ.
Для большинства рабочих нагрузок не рекомендуется настраивать сервер синхронизации Синхронизация файлов Azure только с минимальными требованиями. Дополнительные сведения см. в разделе Рекомендуемые системные ресурсы.
Рекомендуемые системные ресурсы
Как и для любого серверного компонента или приложения, требования к системным ресурсам для Синхронизации файлов Azure определяются масштабом развертывания — для более крупных развертываний на сервере требуются большие системные ресурсы. Для Синхронизации файлов Azure масштаб определяется количеством объектов в конечных точках сервера и изменением набора данных. Один сервер может иметь конечные точки в нескольких группах синхронизации и объектах, перечисленных в следующей таблице, для учетных записей для полного пространства имен, к которому подключен сервер.
Например, конечная точка сервера A с 10 млн объектов + конечная точка сервера B с 10 млн объектов = 20 млн объектов. Для этого примера развертывания мы рекомендуем 8 ЦП, 16 ГиБ памяти для стабильного состояния и (если возможно) 48 ГиБ памяти для первоначальной миграции.
Данные пространства имен хранятся в памяти в целях повышения производительности. Из-за этого большие пространства имен требуют больше памяти для поддержания хорошей производительности, а для большего количества обновлений требуется больше ресурсов ЦП.
В следующей таблице мы предоставили как размер пространства имен, так и преобразование в емкость для типичных общих файловых ресурсов общего назначения, где средний размер файла составляет 512 КИБ. Если ваши файлы меньше, рекомендуется добавить дополнительную память для того же объема емкости. Настраивайте конфигурацию памяти на основе размера пространства имен.
| Размер пространства имен — файлы и каталоги (миллионы) | Типичная емкость (ТиБ) | Ядра ЦП | Рекомендуемая память (ГиБ) |
|---|---|---|---|
| 3 | 1.4 | 2 | 8 (начальная синхронизация)/2 (типичное обновление) |
| 5 | 2.3 | 2 | 16 (начальная синхронизация)/4 (типичное обновление) |
| 10 | 4,7 | 4 | 32 (начальная синхронизация)/8 (типичное обновление) |
| 30 | 14,0 | 8 | 48 (начальная синхронизация)/16 (типичное обновление) |
| 50 | 23,3 | 16 | 64 (начальная синхронизация)/32 (типичное обновление) |
| 100* | 46,6 | 32 | 128 (начальная синхронизация)/32 (типичное обновление) |
*Не рекомендуется синхронизировать более 100 миллионов файлов и каталогов. Это нестрогое ограничение, основанное на проверенных пороговых значениях. Дополнительные сведения см. в разделе Целевые показатели масштабируемости службы синхронизации файлов Azure.
Совет
Начальная синхронизация пространства имен является интенсивной операцией, и мы рекомендуем выделить больше памяти до завершения начальной синхронизации. Это не обязательно, но может ускорить начальную синхронизацию.
Обычное обновление составляет 0,5 % от изменения пространства имен в день. Для более высоких уровней обновления рекомендуется добавить ЦП.
Командлет оценки
Перед развертыванием Синхронизация файлов Azure следует оценить, совместим ли он с системой с помощью командлета оценки Синхронизация файлов Azure. Этот командлет проверяет наличие потенциальных проблем с файловой системой и набором данных, таких как неподдерживаемые символы или неподдерживаемая версия операционной системы. Эти проверки охватывают большинство, но не все перечисленные ниже функции; Мы рекомендуем внимательно ознакомиться с остальными разделами, чтобы обеспечить плавное развертывание.
Командлет оценки можно установить, установив модуль Az PowerShell, следуя инструкциям в статье Установка модуля Azure Az 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.
| Функция | Состояние поддержки | Примечания. |
|---|---|---|
| Списки управления доступом (ACL) | полностью поддерживается. | Списки управления доступом в стиле Windows сохраняются службой "Синхронизация файлов Azure" и принудительно используются Windows Server для конечных точек сервера. Списки управления доступом также можно применять при непосредственном подключении файлового ресурса Azure, однако для этого требуется дополнительная настройка. Дополнительные сведения см. в разделе об идентификаторах. |
| Жесткие связи | Пропущено | |
| Символические связи | Пропущено | |
| Точки подключения | Частично поддерживается | Точки подключения могут располагаться в корне конечной точки сервера, но они пропускаются, если содержатся в пространстве имен конечной точки сервера. |
| Соединения | Пропущено | Например, папки DfrsrPrivate и DFSRoots распределенной файловой системы. |
| Точки повторного анализа | Пропущено | |
| Сжатие NTFS | Частично поддерживается | Синхронизация файлов Azure не поддерживает конечные точки сервера, расположенные на томе с сжатым каталогом сведений о системном томе (SVI). |
| Разреженные файлы | полностью поддерживается. | Разреженные файлы синхронизируются (не блокируются) в облако в качестве полного файла. При изменении содержимого файла в облаке (или на другом сервере) он перестанет быть разреженным, когда скачана измененная версия. |
| Альтернативные потоки данных (ADS) | Сохраняются, но не синхронизируются | Например, теги классификации, созданные инфраструктурой классификации файлов, не синхронизируются. Имеющиеся теги классификации для файлов в каждой из конечных точек сервера использоваться не будут. |
Синхронизация файлов Azure также будет пропускать некоторые временные файлы и системные папки.
| Файл или папка | Примечание. |
|---|---|
| pagefile.sys | Системный файл |
| Desktop.ini | Системный файл |
| thumbs.db; | временный файл для эскизов |
| ehthumbs.db; | Временный файл для эскизов мультимедиа |
| ~$*.* | временный файл Office |
| *.tmp | временный файл |
| *.laccdb | файл блокировки доступа к базе данных |
| 635D02A9D91C401B97884B82B3BCDAEA.* | внутренний файл синхронизации |
| \System Volume Information; | Папка для тома |
| $RECYCLE.BIN | Папка |
| \SyncShareState. | папка для синхронизации |
| . SystemShareInformation | Папка для синхронизации в общей папке Azure |
Примечание.
Хотя Синхронизация файлов Azure поддерживает синхронизацию файлов базы данных, базы данных не являются хорошей рабочей нагрузкой для решений синхронизации (включая Синхронизация файлов Azure), так как файлы журналов и базы данных должны быть синхронизированы вместе, и они могут выйти из синхронизации по различным причинам, которые могут привести к повреждению базы данных.
Подумайте, сколько свободного места вам требуется на локальном диске
При планировании использования Синхронизация файлов Azure следует учитывать, сколько свободного места на локальном диске вы планируете использовать конечную точку сервера.
При использовании службы "Синхронизация файлов Azure" необходимо учитывать следующее, что займет место на локальном диске:
При включенном облачном многоуровневом режиме:
- Точки повторного анализа для многоуровневых файлов
- База данных метаданных Синхронизации файлов Azure
- Хранилище для Синхронизации файлов Azure
- Полностью загруженные файлы в вашем теплом кэше (при наличии)
- Требования к политике свободного места на томе
При отключенном облачном многоуровневом режиме:
- Полностью загруженные файлы
- Хранилище для Синхронизации файлов Azure
- База данных метаданных Синхронизации файлов Azure
Мы будем использовать пример, чтобы продемонстрировать, как оценить объем свободного пространства, необходимого на вашем локальном диске. Допустим, вы установили агент Синхронизации файлов Azure на своей виртуальной машине Azure с Windows и планируете создать конечную точку сервера на диске F. У вас есть один миллион файлов, и вы хотите расположить их все по уровням: 100 000 каталогов. При этом размер дискового кластера составляет 4 КБ. Размер диска составляет 1000 ГиБ. Необходимо включить многоуровневое облачное хранилище и установить для политики свободного места на томе значение 20%.
- NTFS выделяет размер кластера для каждого многоуровневого файла. 1 миллион файлов * 4 КиБ размера кластера = 4000 000 КиБ (4 ГиБ)
Примечание.
Чтобы полностью воспользоваться распределением по уровням в облаке, рекомендуется использовать меньшие размеры кластеров NTFS (менее 64KiB), так как каждый многоуровневый файл занимает кластер. Кроме того, пространство, занятое многоуровневых файлов, выделяется NTFS. Следовательно, он не будет отображаться ни в одном пользовательском интерфейсе.
- Метаданные синхронизации занимают размер кластера для каждого элемента. (1 миллион файлов + 100 000 каталогов) * размер кластера 4 КиБ = 4 400 000 КиБ (4,4 ГиБ)
- Хранилище Синхронизации файлов Azure занимает 1,1 КБ на файл. 1 миллион файлов * 1,1 КиБ = 1 100 000 КиБ (1,1 ГиБ)
- Объем свободного пространства составляет 20%. 1000 ГиБ * 0,2 = 200 ГиБ
В этом случае службе синхронизации файлов Azure потребуется около 209 500 000 КиБ (209,5 ГиБ) для этого пространства имен. Добавьте это количество к любому дополнительному свободному пространству, которое требуется, чтобы выяснить, сколько свободного места требуется для этого диска.
Отказоустойчивая кластеризация
- Служба синхронизации файлов Azure поддерживает отказоустойчивую кластеризацию Windows Server для варианта развертывания "Файловый сервер общего использования". Дополнительные сведения о настройке роли "Файловый сервер для общего использования" в отказоустойчивом кластере см. в разделе Развертывание кластеризованного файлового сервера с двумя узлами.
- Служба "Синхронизация файлов Azure" поддерживает только отказоустойчивый кластер Windows Server с кластеризованными дисками.
- Отказоустойчивая кластеризация не поддерживается в разделе "Масштабируемый файловый сервер для данных приложения" (SOFS) или на кластеризованных общих томах (CSVs) или локальных дисках.
Примечание.
Агент службы синхронизации файлов Azure должен быть установлен на каждом узле отказоустойчивого кластера для правильной работы синхронизации.
Дедупликация данных
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 2019 необходимо установить обновление Windows KB4520062 от октября 2019 года или более позднее обновление.
Windows Server 2012 R2
Синхронизация файлов Azure не поддерживает дедупликацию данных и распределение по уровням в облаке на одном томе в Windows Server 2012 R2. Если дедупликация данных включена на томе, необходимо отключить распределение по уровням в облаке.
Примечания
Если дедупликация данных установлена до установки агента Синхронизации файлов Azure, для поддержки дедупликации данных и распределения по уровням в облаке на том же томе требуется перезагрузка.
Если дедупликация данных включена на томе после включения распределения по уровням в облаке, начальное задание оптимизации дедупликации оптимизирует файлы на томе, который еще не распределен по уровням, и будет иметь следующее влияние на распределение по уровням в облаке:
- Политика свободного места будет по-прежнему распределять файлы по уровням в соответствии с объемом свободного пространства на томе с помощью тепловой карты.
- Политика даты пропускает распределение по уровням для файлов, которые в ином случае могли бы распределяться, в связи с тем что задание оптимизации дедупликации обращается к этим файлам.
Для текущих заданий оптимизации дедупликации облачные уровни с политикой даты будут отложены параметром Data Deduplication MinimumFileAgeDays , если файл еще не многоуровневый.
- Если значение параметра MinimumFileAgeDays составляет семь дней, а политика дат распределения по уровням в облаке — 30 дней, политика дат будет распределять файлы по прошествии 37 дней.
- Примечание. После того как файл распределен по уровням службой "Синхронизация файлов Azure", задание оптимизации дедупликации пропускает этот файл.
Если сервер под управлением Windows Server 2012 R2 с установленным агентом Синхронизация файлов Azure обновляется до 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.
Репликация DFS (DFS-R). Так как DFS-R и служба "Синхронизация файлов Azure" являются решениями репликации, в большинстве случаев рекомендуется полностью заменить DFS-R службой "Синхронизация файлов Azure". Однако существует несколько сценариев, в которых целесообразно использовать DFS-R и службу "Синхронизация файлов Azure" вместе.
- Вы переносите развертывание DFS-R в Синхронизация файлов Azure развертывания. Дополнительные сведения см. в статье Развертывание службы синхронизации файлов Azure (предварительная версия).
- Если нет возможности подключить к Интернету напрямую каждый локальный сервер, на котором нужны копии файлов данных.
- Если серверы подразделений консолидируют данные на одном сервере-концентраторе, для которого вы намерены использовать службу "Синхронизация файлов Azure".
Если служба "Синхронизация файлов Azure" и DFS-R работают параллельно, следует учесть следующее.
- В службе "Синхронизация файлов Azure" нужно отключить распределение по уровням облака для томов, на которых есть реплицируемые DFS-R папки.
- Конечные точки сервера не должны быть настроены в папках репликации только для чтения DFS-R.
- С расположением DFS-R может перекрываться только одна конечная точка сервера. Несколько конечных точек сервера, перекрывающихся с другими активными расположениями DFS-R, могут привести к конфликтам.
Дополнительные сведения см. в статье Обзор пространств имен DFS и репликации DFS.
Sysprep
Использование sysprep на сервере с установленным агентом Синхронизация файлов Azure не поддерживается и может привести к непредвиденным результатам. Устанавливать агент и регистрировать сервер нужно после развертывания образа сервера и завершения мини-установки sysprep.
Поиск Windows
Если распределение по уровням в облаке включено на конечной точке сервера, файлы, которые многоуровневые, пропускаются и не индексируются поиском Windows. Файлы, не распределяемые по уровням, индексируются должным образом.
Примечание.
Если на клиентский компьютере с Windows включен параметр Always search file names and contents (Всегда искать имена и содержимое файлов), при поиске в общей папке операция будет отозвана. Этот флажок по умолчанию снят.
Другие решения по управлению иерархическим хранением (HSM)
Другие решения HSM не нужно использовать со службой синхронизации файлов Azure.
Производительность и масштабируемость
Так как агент службы синхронизации файлов Azure работает на компьютере под управлением Windows Server, который подключается к общим папкам Azure, эффективная синхронизация зависит от ряда факторов в вашей инфраструктуре: Windows Server и базовой конфигурации диска, пропускной способности сети между сервером и хранилищем Azure, размера файла, общего размера набора данных и активности в наборе данных. Так как служба синхронизации файлов Azure работает на уровне файлов, характеристики производительности решения на основе этой службы лучше измеряются в количестве обрабатываемых объектов (файлов и каталогов) в секунду.
Изменения, внесенные в общую папку Azure с помощью портал Azure или SMB, не обнаруживаются и не реплицируются, как изменения в конечной точке сервера. Файлы Azure не содержит уведомлений об изменениях или журналов, поэтому при изменении файлов невозможно автоматически инициировать сеанс синхронизации. На Windows Server служба "Синхронизация файлов Azure" использует ведение журнала номеров последовательного обновления Windows для автоматического запуска сеанса синхронизации при изменении файлов.
Для обнаружения изменений в общем файловом ресурсе Azure служба "Синхронизация файлов Azure" использует запланированное задание с именем change detection job (задание обнаружения изменений). Это задание перечисляет все файлы в общем файловом ресурсе и затем сравнивает их с синхронизированными версиями этих же файлов. Если задание обнаруживает, что файлы изменились, служба "Синхронизация файлов Azure" инициирует сеанс синхронизации. Задание обнаружения изменений инициируется каждые 24 часа. Так как задание обнаружения изменений перечисляет все файлы в общем файловом ресурсе Azure, на обнаружение изменений в крупном пространстве имен уходит больше времени, чем в небольшом пространстве. В крупных пространствах обнаружение измененных файлов может длиться больше суток.
Дополнительные сведения см. в разделе Синхронизация файлов Azure, метрики производительности и Синхронизация файлов Azure, целевые значения масштабирования
Идентификация
Синхронизация файлов Azure работает со стандартным удостоверением на основе AD без каких-либо специальных настроек после настройки синхронизации. При использовании Синхронизация файлов Azure общее ожидание заключается в том, что большинство доступа проходит через серверы кэширования Синхронизация файлов Azure, а не через общую папку Azure. Так как конечные точки сервера находятся в Windows Server, а Windows Server уже давно поддерживает списки ACL в стиле AD и Windows, остается только убедиться, что файловые серверы Windows, зарегистрированные в службе синхронизации хранилища, присоединены к домену. Синхронизация файлов Azure сохранит списки управления доступом для файлов в файловом ресурсе Azure и будет реплицировать их во все конечные точки сервера.
Несмотря на то, что изменения, внесенные непосредственно в общую папку Azure, будут занимать больше времени для синхронизации с конечными точками сервера в группе синхронизации, также может потребоваться обеспечить принудительное применение разрешений AD в общей папке непосредственно в облаке. Для этого необходимо присоединить учетную запись хранения к локальной службе AD, как файловые серверы Windows присоединены к домену. Дополнительные сведения о присоединении учетной записи хранения к домену Active Directory, принадлежащему клиенту, см. в разделе Обзор Active Directory Файлов Azure.
Внимание
Домен, присоединенный к учетной записи хранения, не требуется для успешного развертывания Синхронизация файлов Azure. Это строго необязательный шаг, позволяющий общей папке Azure применять локальные списки управления доступом, когда пользователи подключают общую папку Azure напрямую.
Сеть
Агент Синхронизации файлов Azure взаимодействует с вашей службой синхронизации хранилища и файловым ресурсом Azure с помощью протокола Синхронизации файлов Azure REST и протокола FileREST, оба из которых всегда используют HTTPS через порт 443. SMB никогда не используется для отправки или загрузки данных между сервером Windows Server и файловым ресурсом Azure. Так как большинство организаций разрешают трафик по протоколу HTTPS через порт 443 в качестве требования для посещения большинства веб-сайтов, специальная настройка сети обычно не требуется для развертывания Синхронизации файлов Azure.
Внимание
Синхронизация файлов Azure не поддерживает маршрутизацию через Интернет. Параметр сетевой маршрутизации по умолчанию (маршрутизация Майкрософт) поддерживается службой "Синхронизация файлов Azure".
В зависимости от политики вашей организации или уникальных нормативных требований может потребоваться более строгое взаимодействие с Azure, поэтому Синхронизация файлов Azure предоставляет несколько механизмов настройки сети. В зависимости от требований вам доступны следующие возможности.
- Синхронизация туннеля и трафика передачи/загрузки файлов через сеть ExpressRoute или Azure VPN.
- Использование функций Файлов Azure и Сети Azure, таких как конечные точки служб и частные конечные точки.
- Настройка Синхронизации файлов Azure для поддержки прокси-сервера в вашей среде.
- Регулирование сетевой активности в Синхронизации файлов Azure.
Совет
Если вы хотите взаимодействовать с общей папкой Azure по протоколу SMB, но порт 445 заблокирован, рассмотрите возможность использования SMB по протоколу QUIC. Этот вариант по умолчанию поддерживает SMB VPN для доступа к общим папкам Azure через порт 443. Хотя Файлы Azure не поддерживает SMB через QUIC, вы можете создать упрощенный кэш общих папок Azure на виртуальной машине Windows Server 2022 Azure Edition с помощью Синхронизация файлов Azure. Дополнительные сведения об этом параметре см. в статье SMB over QUIC с помощью Синхронизация файлов Azure.
Дополнительные сведения о Синхронизации файлов Azure и работе в сети см. в статье Синхронизация файлов Azure, рекомендации по сетям.
Шифрование
При использовании Синхронизации файлов Azure существует три разных уровня шифрования: шифрование при хранении в Windows Server, шифрование при передаче между агентом Синхронизации файлов Azure и Azure и шифрование данных при хранении в файловом ресурсе Azure.
Шифрование при хранении в Windows Server
Существуют две стратегии шифрования данных на сервере Windows Server, которые обычно подходят для Синхронизации файлов Azure: шифрование под файловой системой, так что файловая система и все данные, записанные в нее, шифруются, и шифрование в самом формате файла. Эти методы не являются взаимоисключающими; Их можно использовать вместе, если это необходимо, так как назначение шифрования отличается.
Чтобы обеспечить шифрование под файловой системой, Windows Server предоставляет входящую папку BitLocker. BitLocker полностью прозрачны для Синхронизация файлов Azure. Основная причина использования механизма шифрования, такого как 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 удалила поддержку TLS1.0 и 1.1 1 августа 2020 г. Все поддерживаемые версии агента Синхронизации файлов Azure уже используют TLS 1.2 по умолчанию. Использование более ранней версии TLS может быть связано с тем, что протокол TLS 1.2 был отключен на сервере или используется прокси-сервер. Если вы используете прокси-сервер, рекомендуем проверить конфигурацию прокси-сервера. Синхронизация файлов Azure регионы служб, добавленные после 5.1.2020, поддерживают только TLS1.2. Дополнительные сведения см. в руководстве по устранению неполадок.
Агент Синхронизации файлов 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. Шифрование неактивных данных поддерживает протоколы SMB и NFS.
По умолчанию хранимые в Файлах Azure данные шифруются с помощью ключей, управляемых корпорацией Майкрософт, что предусматривает хранение ключей для шифрования и расшифровки данных и их регулярную смену. Вы также можете управлять собственными ключами, чтобы взять под контроль процесс их смены. Если вы решили зашифровать общие папки с помощью ключей, управляемых клиентом, учитывайте, что служба "Файлы Azure" сможет обращаться к ключам для выполнения запросов на чтение и запись от клиентов. С помощью ключей, управляемых клиентом, эту авторизацию можно отозвать в любое время, но это означает, что общая папка Azure больше не будет доступна через SMB или API FileREST.
Служба "Файлы Azure" использует ту же схему шифрования, что и другие службы хранилища Azure, включая Хранилище BLOB-объектов Azure. Сведения об SSE Azure см. в статье Использование функции "Шифрование службы хранилища Azure" для неактивных данных.
Уровни хранилища
Файлы Azure предлагает два различных уровня носителей, SSD и HDD, что позволяет адаптировать общие ресурсы к требованиям к производительности и цене вашего сценария:
SSD (Premium): общие папки класса Premium используются твердотельными дисками (SSD) и обеспечивают согласованную высокую производительность и низкую задержку в миллисекундах с одним цифрами для большинства операций ввода-вывода для рабочих нагрузок с интенсивными операциями ввода-вывода. Общие папки уровня "Премиум" предназначены для широкого круга рабочих нагрузок, таких как базы данных, размещение веб-сайтов и среды разработки. Общие папки уровня "Премиум" поддерживают протоколы SMB и NFS. Общие папки уровня "Премиум" развертываются в учетной записи хранения типа FileStorage и доступны только в модели выставления счетов за подготовленные ресурсы. См. дополнительную информацию в разделе Общие сведения о подготовке общих папок уровня "Премиум". Общие папки уровня "Премиум" обеспечивают более высокую доступность, чем стандартные общие папки (см. раздел "уровень "Файлы Azure цен. категория "Премиум").
HDD (standard): общие папки уровня "Стандартный" используют жесткие диски (HDD) и предоставляют экономичный вариант хранения общих папок общего назначения. Стандартные общие папки развертываются в типе учетной записи хранения общего назначения 2 (GPv2). Дополнительные сведения об уровне обслуживания см. на странице соглашений об уровне обслуживания Azure (см. раздел "Учетные записи хранения"). Стандартные файловые ресурсы используют модель оплаты по мере использования, которая предоставляет цены на основе использования. Уровень доступа общей папки позволяет настроить затраты на хранение по затратам на операции ввода-вывода в секунду, чтобы оптимизировать общий счет:
- Оптимизированные для транзакций общие папки предлагают самые низкие цены на транзакцию для тяжелых рабочих нагрузок, которые не требуют низкой задержки, предоставляемой общими папками класса Premium. Рекомендуется перенести данные в Файлы Azure.
- Горячие общие папки предлагают сбалансированные цены на хранилище и транзакции для рабочих нагрузок, которые имеют хорошую меру обоих.
- Холодные общие папки предлагают самые экономичные цены на хранилище для рабочих нагрузок с большим объемом хранилища.
При выборе уровня мультимедиа для рабочей нагрузки учитывайте требования к производительности и использованию. Если для рабочей нагрузки требуется однозначная задержка или вы используете локальный носитель хранения SSD, уровень "Премиум", вероятно, лучше всего подходит. Если низкая задержка не настолько важна, например, если общие папки вашей команды подключены к локальной среде из Azure или кэшируются локально с помощью Синхронизации файлов Azure, хранилище уровня "Стандартный" может быть оптимальным вариантом с точки зрения затрат.
После создания общей папки в учетной записи хранения его нельзя переместить на уровни, эксклюзивные для различных типов учетных записей хранения. Например, чтобы переместить оптимизированную для транзакций общую папку на уровень "Премиум", нужно создать новую общую папку в учетной записи хранения FileStorage и скопировать данные из исходной общей папки в новую общую папку в учетной записи FileStorage. Для копирования данных между общими папками Azure мы рекомендуем использовать AzCopy, но вы также можете использовать такие средства, как robocopy в Windows или rsync в macOS и Linux.
Дополнительные сведения см. в статье Основные сведения о выставлении счетов для Файлов Azure.
доступность Синхронизация файлов Azure региона
Сведения о доступности продуктов по регионам см. на страницеНаличие продуктов по регионам.
В следующих регионах, прежде чем начать с ними синхронизацию файлов через Azure, потребуется запросить доступ к службе хранилища Azure:
- Франция (юг)
- Западная часть ЮАР
- Центральная часть ОАЭ
Чтобы запросить доступ к этим регионам, выполните процедуру, описанную в этом документе.
Избыточность
Чтобы защитить данные в общих папках Azure от потери или повреждения данных, Файлы Azure хранит несколько копий каждого файла по мере их записи. В зависимости от требований можно выбрать различные степени избыточности. Служба "Файлы Azure" в настоящее время поддерживает следующие варианты обеспечения избыточности:
- Локально избыточное хранилище (LRS). При использовании LRS в кластере хранилища Azure сохраняются три копии каждого файла. Это защищает от потери данных из-за сбоев оборудования, таких как плохой диск. Однако если в центре обработки данных возникает катастрофа, например пожар или наводнение, все реплики учетной записи хранения с помощью LRS могут быть потеряны или невосстановлены.
- Хранилище, избыточное между зонами (ZRS): с помощью ZRS хранятся три копии каждого файла. Однако эти копии физически изолированы в трех разных кластерах хранения в разных зонах доступности Azure. Зоны доступности — уникальные физические расположения в пределах одного региона Azure. Каждая зона состоит из одного или нескольких центров обработки данных, обеспеченных независимыми системами электропитания, охлаждения и сетями. Запись в хранилище не принимается, пока она не будет записана в кластеры хранения во всех трех зонах доступности.
- Геоизбыточное хранилище (GRS): с GRS у вас есть два региона, основной регион и дополнительный регион. В кластере хранилища Azure в основном регионе хранятся три копии каждого файла. Операции записи асинхронно реплицируются в определенный корпорацией Майкрософт дополнительный регион. GRS предоставляет шесть копий данных, распределенных между двумя регионами Azure. В случае серьезной аварии, такой как постоянная потеря региона Azure из-за стихийных бедствий или другого подобного события, корпорация Майкрософт выполнит отработку отказа. В этом случае вторичный становится основным, обслуживая все операции. Так как репликация между основными и вторичными регионами является асинхронной, в случае серьезной аварии данные еще не реплицируются в дополнительный регион. Вы также можете выполнить переход учетной записи хранения с геоизбыточным хранилищем на другой ресурс вручную.
- Геоизбыточное хранилище (GZRS): вы можете рассматривать GZRS как ZRS, но с геоизбыточностью. В GZRS три копии каждого файла хранятся в трех отдельных кластерах хранилища в основном регионе. Все операции записи затем асинхронно реплицируются в определенный корпорацией Майкрософт дополнительный регион. Процесс отработки отказа для GZRS работает так же, как в GRS.
Общие папки Azure уровня "Стандартный" до 5 ТиБ поддерживают все четыре типа избыточности. Стандартные общие папки размером более 5 ТиБ поддерживают только LRS и ZRS. Общие папки Azure категории “Премиум” поддерживают только LRS и ZRS.
Учетные записи хранения общего назначения версии 2 (GPv2) предоставляют два других варианта избыточности, которые Файлы Azure не поддерживают: доступное для чтения геоизбыточное хранилище (RA-GRS) и доступное для чтения геоизбыточное хранилище (RA-GZRS). Вы можете подготовить общие папки Azure в учетных записях хранения с помощью этих параметров, однако Файлы Azure не поддерживает чтение из дополнительного региона. Общие папки Azure, развернутые в учетных записях хранения RA-GRS или RA-GZRS, выставляются как GRS или GZRS соответственно.
Внимание
Геоизбыточное и геозонное избыточное хранилище имеют возможность вручную отработки отказа хранилища в дополнительный регион. Рекомендуется не делать это за пределами аварии при использовании Синхронизация файлов Azure из-за повышенной вероятности потери данных. В случае аварии, в которой вы хотите инициировать отработку отказа вручную, необходимо открыть вариант поддержки с корпорацией Майкрософт, чтобы получить Синхронизация файлов Azure для возобновления синхронизации с вторичной конечной точкой.
Миграция
Если у вас есть файловый сервер на базе Windows 2012R2, службу "Синхронизация файлов Azure" можно установить непосредственно на месте, без перемещения данных на новый сервер. Если вы планируете перейти на новый файловый сервер Windows в рамках внедрения Синхронизация файлов Azure или если данные находятся в настоящее время в подключенном к сети хранилище (NAS), существует несколько возможных подходов к миграции для использования Синхронизация файлов Azure с данными. Какой подход к миграции следует выбрать, зависит от того, где находятся данные.
Подробные инструкции см. в статье о миграции Синхронизация файлов Azure и файлового ресурса Azure.
Антивирусная программа
Антивирусные программы работают путем сканирования файлов на наличие известного вредоносного кода, поэтому они могут вызвать отзыв файлов, уже распределенных по уровням, а это приведет к повышению оплаты за исходящий трафик. Многоуровневые файлы имеют безопасный набор атрибутов Windows, и мы рекомендуем консультироваться с поставщиком программного обеспечения, чтобы узнать, как настроить свое решение для пропуска чтения файлов с этим набором атрибутов FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS (многие делают это автоматически).
Антивирусные решения Майкрософт — Защитник Windows и служба регистрации сертификатов для сетевых устройств (SCEP) автоматически пропускают чтение файлов с таким атрибутом. В ходе их тестирования обнаружилась небольшая проблема — при добавлении сервера в существующую группу синхронизации файлы размером меньше 800 байт отзываются (скачиваются) на новый сервер. Эти файлы останутся на новом сервере и не будут многоуровневыми, так как они не соответствуют требованиям к размеру уровня (>64 КБ).
Примечание.
Поставщики антивирусных программ могут проверить совместимость своих продуктов и Синхронизации файлов Azure с помощью Набора тестов для совместимости антивирусных программ с Синхронизацией файлов Azure, который доступен в центре загрузки Майкрософт.
Резервное копирование
Если включено распределение по уровням в облаке, решения, которые напрямую резервного копирования конечной точки сервера или виртуальной машины, на которой расположена конечная точка сервера, не должны использоваться. Распределение по уровням приведет к хранению только подмножества данных в конечной точке сервера, а полный набор данных будет размещаться в общей папке Azure. В зависимости от используемого решения резервного копирования многоуровневые файлы будут пропускаться и не создавать резервные копии (так как они имеют FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS набор атрибутов), или они будут отозваны на диск, что приведет к высоким затратам на исходящий трафик. Мы рекомендуем в этом случае применять варианты резервного копирования общей папки Azure непосредственно в облаке. Дополнительные сведения см. в статье О резервном копировании общей папки Azure или обратитесь к поставщику услуг по резервированию, чтобы узнать, поддерживают ли они резервное копирование общих папок Azure.
Если вы предпочитаете использовать локальное решение для резервного копирования, резервное копирование должно выполняться на сервере в группе синхронизации с отключенным распределением по уровням облака и убедитесь, что многоуровневые файлы отсутствуют. При восстановлении используйте параметры восстановления на уровне тома или файла. Файлы, восстановленные с помощью параметра восстановления на уровне файлов, будут синхронизированы со всеми конечными точками в группе синхронизации, а существующие файлы будут заменены версией, восстановленной из резервной копии. Восстановление на уровне тома не заменит более новые версии файлов в общей папке Azure или других конечных точках сервера.
Примечание.
Восстановление без операционной системы (BMR), восстановление виртуальной машины, восстановление системы (встроенное восстановление ОС Windows) и восстановление на уровне файлов с многоуровневой версией (это происходит при резервном копировании программного обеспечения резервного копирования многоуровневого файла вместо полного файла) может привести к непредвиденным результатам и в настоящее время не поддерживается при включении уровня облака. Сейчас моментальные снимки VSS (включая вкладку «Предыдущие версии») не поддерживаются в томах, для которых включено распределение по уровням в облаке. Однако необходимо включить совместимость с предыдущими версиями с помощью PowerShell. Инструкции.
Классификация данных
Если у вас установлено программное обеспечение классификации данных, включение уровня облака может привести к увеличению затрат по двум причинам:
С включенным распределением по уровням в облаке самые горячие файлы кэшируются локально, а самые холодные файлы многоуровневы в общую папку Azure в облаке. Если ПО классификации данных регулярно сканирует все файлы в общей папке, это значит, что файлы, переданные по уровням в облаке, при сканировании должны отзываться назад.
Если ПО классификации данных использует метаданные из потока данных файла, то этот файл должен быть полностью отозван для того, чтобы программное обеспечение могло видеть классификацию.
Увеличение количества отзывов и объема вызываемых данных может значительно увеличить затраты.
Политика обновления агента службы синхронизации файлов Azure
Агент службы синхронизации файлов Azure обновляется на регулярной основе. Это позволяет добавлять новые возможности и устранять ошибки. Рекомендуется обновить агент Синхронизация файлов Azure, так как доступны новые версии.
Сравнение основной и дополнительных версий агента
- Основные версии агента часто содержат новые функции, и в первой части номера версии указан возрастающий номер. Например: 17.0.0.0.0
- Дополнительные версии агента также называются "исправлениями" и выпускаются чаще по сравнению с основными версиями. Они часто содержат исправления уязвимостей и небольшие усовершенствования, но не содержат новых функций. Например: 17.2.0.0
Варианты обновления
Существует пять утвержденных и проверенных способов установки обновлений агента службы синхронизации файлов Azure.
- Используйте функцию автоматического обновления агента Синхронизации файлов Azure для установки обновлений агента. Агент Синхронизации файлов Azure будет обновляться автоматически. Вы можете установить последнюю версию агента, если она доступна, или обновить его по мере истечении срока действия установленной версии. Дополнительные сведения см. в статье Автоматическое управление жизненным циклом агента.
- Настройте Центр обновлений Майкрософт для автоматической загрузки и установки обновлений агента. Рекомендуется устанавливать все обновления службы синхронизации файлов в Azure, чтобы гарантировать наличие последних исправлений для агента сервера. Центр обновления Майкрософт упрощает этот процесс, автоматически скачивая и устанавливая обновления.
- Используйте AfsUpdater.exe для скачивания и установки обновлений агента. AfsUpdater.exe находится в каталоге установки агента. Дважды щелкните исполняемый файл, чтобы скачать и установить обновления агента. В зависимости от версии выпуска может потребоваться перезапустить сервер.
- Установка исправлений для существующего агента службы "Синхронизация файлов Azure" с использованием файла исправлений Центра обновления Майкрософт или исполняемого MSP-файла. Последний пакет обновлений для службы "Синхронизация файлов Azure" можно скачать из Каталога Центра обновления Майкрософт. При выполнении исполняемого файла MSP Синхронизация файлов Azure установка будет обновлена с помощью того же метода, который используется автоматически Центром обновления Майкрософт. В случае принятия исправлений от Центра обновления Майкрософт выполняется обновление "на месте" установки службы синхронизации файлов Azure.
- Скачайте новый установщик агента Синхронизация файлов Azure из Центра загрузки Майкрософт. Для обновления существующей установки агента службы синхронизации файлов Azure удалите старую версию, а затем установите последнюю версию с помощью загруженного установщика. Этот установщик выполняет регистрацию сервера, настраивает группы синхронизации и все остальные параметры.
Примечание.
Понижение уровня агента Синхронизация файлов Azure не поддерживается. Новые версии часто включают критические изменения по сравнению с старыми версиями, что делает процесс понижения неподдерживаемого. Если у вас возникли проблемы с текущей версией агента, обратитесь к поддержке или обновлению до последней доступной версии.
Автоматическое управление жизненным циклом агента
Агент Синхронизации файлов Azure будет обновляться автоматически. Можно выбрать один из двух режимов и указать временной интервал обслуживания, в течение которого будет выполняться попытка обновления на сервере. Эта функция призвана облегчить управление жизненным циклом агента путем предоставления дополнительного страховочного средства, препятствующего истечению срока действия агента, или путем включения настройки для бесперебойного поддержания актуальной версии.
- При настройке по умолчанию выполняется попытка предотвратить истечение срока действия агента. За 21 день до окончания заявленного срока действия агент будет пытаться выполнить самостоятельное обновление. Попытки обновления будут выполняться раз в неделю в течение 21 дня до истечения срока действия и в выбранном временном интервале обслуживания. Этот параметр не устраняет необходимость в регулярных исправлениях Центра обновления Майкрософт.
- Дополнительно можно указать, чтобы агент автоматически обновлял себя как только станет доступной его новая версия (в настоящее время эта возможность неприменима к кластеризованным серверам). Это обновление будет происходить в течение выбранного для обслуживания интервала времени и позволит реализовать на сервере преимущества от новых функций и усовершенствований, как только они станут общедоступными. Это рекомендуемый параметр, обеспечивающий установку основных версий агента, а также регулярное применение исправлений с обновлениями на сервере. Каждый выпуск агента является общедоступным. При выборе этого параметра Майкрософт будет предоставлять вам для фокус-тестирования самую новую версию агента. На кластеризованные серверы этот вариант не распространяется. После завершения полетов агент также станет доступен в Центре обновления Майкрософт и Центра загрузки Майкрософт.
Изменение параметра автоматического обновления
Приведенные ниже инструкции описывают процедуру изменения параметров после завершения работы установщика в случае необходимости внесения каких-либо изменений.
Откройте консоль PowerShell и перейдите в каталог, в котором установлен агент синхронизации, а затем импортируйте командлеты сервера. При настройках по умолчанию это может выглядеть следующим образом:
cd 'C:\Program Files\Azure\StorageSyncAgent'
Import-Module -Name .\StorageSync.Management.ServerCmdlets.dll
Можно запустить командлет Get-StorageSyncAgentAutoUpdatePolicy, чтобы проверить текущую настройку политики и определить, нужно ли ее изменить.
Чтобы изменить текущую настройку политики на отложенное обновление, можно использовать следующий командлет:
Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode UpdateBeforeExpiration
Чтобы изменить текущую настройку политики на немедленное обновление, можно использовать следующий командлет:
Set-StorageSyncAgentAutoUpdatePolicy -PolicyMode InstallLatest -Day <day> -Hour <hour>
Примечание.
Если проверка уже завершена для последней версии агента, а политика автоматического обновления агента изменена на InstallLatest, агент не будет автоматически обновляться до следующей версии агента. Чтобы обновить версию агента, которая выполнила полет, используйте Центр обновления Майкрософт или AfsUpdater.exe. Чтобы проверить, выполняется ли в настоящее время проверка версии агента, проверьте раздел поддерживаемых версий в заметках о выпуске.
Гарантии относительно жизненного цикла агента и управления изменениями
Синхронизация файлов Azure — это облачная служба, которая постоянно вводит новые функции и улучшения. В частности, из этого следует, что любая конкретная версия агента службы синхронизации файлов Azure поддерживается лишь ограниченное время. Для облегчения развертывания установлены следующие правила, которые гарантируют высвобождение значительного времени и получение уведомлений для обеспечения установки обновлений или перехода на новую версию агента в рамках процедуры управления изменениями:
- Основные версии агента поддерживаются по меньшей мере в течение шести месяцев с момента их появления.
- Мы гарантируем наличие по крайней мере трехмесячного перекрытия между сроками поддержки основных версий агентов.
- На зарегистрированные серверы, использующие агент, срок поддержки которого истекает, не позже чем за три месяца отправляются соответствующие уведомления. Вы можете проверить, не использует ли зарегистрированный сервер старую версию агента в разделе зарегистрированных серверов службы синхронизации хранилища.
- Срок действия дополнительных версий агента привязан к сроку действия основной версии. Например, если агент версии 17.0.0.0.0 истекает, агент версии 17.*.*.* будет иметь срок действия вместе.
Примечание.
При установке версии агента с предупреждением о скором истечении срока поддержи процесс установки завершится успешно, но отобразится соответствующее предупреждение. Попытка установить или подключиться с версией агента с истекшим сроком действия не поддерживается и будет заблокирована.