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

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

  • Статья

Служба Файлы Azure предоставляет полностью управляемые общие папки в облаке, доступ к которым можно получить с помощью стандартного отраслевого протокола SMB или протокола NFS. You can mount Azure file shares concurrently on cloud or on-premises deployments of Windows, Linux, and macOS. Вы также можете кэшировать общие файловые ресурсы Azure на компьютерах под управлением Windows Server с помощью функции "Синхронизация файлов Azure", чтобы получить быстрый доступ из расположения, где используются данные.

Служба синхронизации файлов Azure

  • Могут ли в одной группе синхронизации находиться серверы, присоединенные к домену, и серверы, независимые от него?
    Да. Группа синхронизации может содержать конечные точки сервера, имеющие разные членства в Active Directory, даже если они не присоединены к домену. Хотя эта конфигурация технически работает, мы не рекомендуем использовать эту конфигурацию в качестве типичной конфигурации, так как списки управления доступом (СПИСКИ УПРАВЛЕНИЯ доступом), определенные для файлов и папок на одном сервере, могут не применяться другими серверами в группе синхронизации. Для получения наилучших результатов рекомендуется синхронизировать между серверами, которые находятся в одном лесу Active Directory, между серверами, которые находятся в разных лесах Active Directory, но установили отношения доверия или между серверами, которые не находятся в домене. Мы рекомендуем избегать использования смеси этих конфигураций.

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

    Изменения, внесенные в общий файловый ресурс Azure с использованием портала Azure или SMB, сразу не обнаруживаются и не реплицируются, как изменения в конечной точке сервера. В службе файлов Azure пока не предусмотрена возможность уведомлений об изменениях или ведение журнала изменений, поэтому автоматически инициировать сеанс синхронизации при изменении файлов невозможно. On Windows Server, Azure File Sync uses Windows USN journaling to automatically initiate a sync session when files change.

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

    Для немедленной синхронизации файлов, измененных в общей папке Azure, можно использовать командлет PowerShell Invoke-AzStorageSyncChangeDetection, вручную инициировав обнаружение изменений в общей папке Azure. Этот командлет предназначен для сценариев, в которых определенный тип автоматизированного процесса вносит изменения в общую папку Azure или изменения выполняются администратором (например, перемещение файлов и каталогов в общую папку). Для изменений конечных пользователей рекомендуется установить агент службы "Синхронизация файлов Azure" на виртуальной машине IaaS и предоставить конечным пользователям доступ к общей папке через эту виртуальную машину. Таким образом, все изменения будут быстро синхронизироваться с другими агентами без необходимости использовать командлет Invoke-AzStorageSyncChangeDetection. Дополнительные сведения см. в документации по Invoke-AzStorageSyncChangeDetection.

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

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

    Следующие сценарии могут привести к конфликтам файлов:

    • Файл создается или изменяется в конечной точке (например, на сервере A). Если тот же файл изменяется в другой конечной точке до синхронизации изменения на сервере A с этой конечной точкой, создается конфликтующий файл.
    • Файл существовал в файловом ресурсе Azure и местоположении конечной точки сервера до её создания. Если размер файла и (или) время последнего изменения отличаются для файла на сервере и общей папки Azure при создании конечной точки сервера, создается конфликтный файл.
    • База данных синхронизации была повторно создана из-за повреждения или превышения лимита данных. После повторного создания базы данных синхронизация переходит в режим сверки. Если размер файла и (или) время последнего изменения отличаются для файла на сервере и общей папки Azure при переходе в режим сверки, создается конфликтный файл.

    После завершения первоначальной отправки на общую папку Azure, служба Синхронизации файлов Azure не перезаписывает файлы в вашей группе синхронизации. Instead, it uses a simple conflict-resolution strategy: it keeps both changes to files that are changed in two endpoints at the same time. Последняя внесенная смена сохраняет оригинальное имя файла. Более старый файл (определяется по LastWriteTime) имеет имя конечной точки и номер конфликта, добавленные к имени файла. Для конечных точек сервера имя конечной точки — это имя сервера. Для облачных конечных точек имя конечной точки — Cloud. Имя соответствует следующей таксономии:

    <FileNameWithoutExtension>-<endpointName>[-#].<ext>

    For example, the first conflict of CompanyReport.docx would become CompanyReport-CentralServer.docx if CentralServer is where the older write occurred. Второй конфликт будет назван CompanyReport-CentralServer-1.docx. Azure File Sync supports 100 conflict files per file. После достижения максимального количества конфликтующих файлов синхронизация файлов будет завершаться сбоем, пока количество конфликтующих файлов не станет меньше 100.

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

    • When adding a new server endpoint to an existing sync group, if you choose either the recall namespace first option or recall namespace only option for initial download mode, files will show up as tiered until they're downloaded locally. Чтобы избежать этого, выберите параметр "Избежать многоуровневого файла " для начального режима загрузки. Чтобы вручную отозвать файлы, воспользуйтесь командлетом Invoke-StorageSyncFileRecall.

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

  • Why are my tiered files not showing thumbnails or previews in Windows File Explorer?
    Для многоуровневых файлов эскизы и предварительные просмотры не будут отображаться на конечной точке сервера. This is expected behavior because the thumbnail cache feature in Windows intentionally skips reading files with the offline attribute. With Cloud Tiering enabled, reading through tiered files would cause them to be downloaded (recalled).

    Это поведение не является специфическим для Azure File Sync. Проводник Windows отображает "серый X" для всех файлов с атрибутом офлайн. При доступе к файлам по протоколу SMB будет отображаться значок X. For a detailed explanation of this behavior, refer to Why don't I get thumbnails for files that are marked offline?

    По вопросам управления многоуровневыми файлами см. статью Управление многоуровневыми файлами.

  • Почему распределенные по уровням файлы существуют вне пространства имен конечной точки сервера?
    Prior to Azure File Sync agent version 3, Azure File Sync blocked the move of tiered files outside the server endpoint but on the same volume as the server endpoint. Операции копирования, перемещение неуровневых файлов и перемещение многоуровневых файлов в другие тома не пострадали. The reason for this behavior was the implicit assumption that File Explorer and other Windows APIs have that move operations on the same volume are (nearly) instantaneous rename operations. This means moves will make File Explorer or other move methods (such as command line or PowerShell) appear unresponsive while Azure File Sync recalls the data from the cloud. Начиная с агента службы "Синхронизация файлов Azure" версии 3.0.12.0 эта служба позволяет переместить многоуровневый файл за пределы конечной точки сервера. Мы избегаем упомянутых выше проблем, позволяя многоуровневому файлу существовать в виде многоуровневого файла за пределами конечной точки сервера, а затем отзывая этот файл в фоновом режиме. Это означает, что перемещение на одном томе мгновенно, и мы делаем все действия, чтобы отозвать файл на диск после завершения перемещения.

  • У меня возникла проблема с функцией "Синхронизация файлов Azure" на сервере (синхронизация, распределение по уровням облака и т. д). Следует ли удалить и создать заново конечную точку сервера?

    Нет, удаление конечной точки сервера не аналогично перезагрузке сервера. Удаление и повторное создание конечной точки сервера практически никогда не является подходящим решением для устранения проблем с синхронизацией, распределением по уровням облака или другими аспектами службы "Синхронизация файлов Azure". Удаление конечной точки сервера является разрушительной операцией. Это может привести к потере данных в случае, если многоуровневые файлы существуют за пределами пространства имен конечной точки сервера. Дополнительные сведения см. в разделе Почему многоуровневые файлы существуют вне пространства имен конечной точки сервера?. Or it might result in inaccessible files for tiered files that exist within the server endpoint namespace. Эти проблемы не исчезнут после повторного создания конечной точки сервера. Tiered files may exist within your server endpoint namespace even if you never had cloud tiering enabled. Поэтому рекомендуется не удалять конечную точку сервера, если только вы не хотите прекратить использование службы "Синхронизация файлов Azure" с этой конкретной папкой или инженер корпорации Майкрософт явно указал вам удалить эту конечную точку. Дополнительные сведения об удалении конечных точек сервера см. в разделе Удаление конечной точки сервера.

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

    1. Войдите в портал Azure и выберите элемент управления доступом (IAM) в меню службы.

    2. Перейдите на вкладку "Назначения ролей" , чтобы вывести список пользователей и приложений (субъектов-служб), имеющих доступ к учетной записи хранения.

    3. Убедитесь в том, Microsoft.StorageSync или гибридная служба "Синхронизация файлов" (старое имя приложения) отображается в списке с ролью чтения и доступа к данным.

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

      • Выберите Добавить.
      • В поле Роль выберите Читатель и доступ к данным.
      • В поле Select введите Microsoft.StorageSync, выберите роль и нажмите кнопку "Сохранить".

      Примечание.

      При создании облачной конечной точки служба синхронизации хранилища и учетная запись хранения должны находиться в одном клиенте Microsoft Entra. Once the cloud endpoint is created, the storage sync service and storage account can be moved to different Microsoft Entra tenants.

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

    По состоянию на 24 февраля 2020 г. новые и существующие списки управления доступом, сгруппированные с помощью службы синхронизации файлов Azure, сохраняются в формате NTFS, а изменения этих списков, вносимые непосредственно в общий файловый ресурс Azure, будут синхронизироваться со всеми серверами в группе синхронизации. Любые изменения списков управления доступом (ACLs), внесенные в общие папки Azure, будут синхронизированы с помощью Azure File Sync. При копировании данных в Azure Files убедитесь, что вы используете средство копирования, которое поддерживает необходимый уровень качества для копирования атрибутов, меток времени и ACLs в общую папку Azure через SMB или REST. При использовании средств копирования Azure, таких как AzCopy, важно использовать последнюю версию. Просмотрите таблицу средств копирования файлов для получения общих сведений о средствах копирования Azure, чтобы обеспечить возможность копирования всех важных метаданных файла.

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

    If you're using snapshots as part of the self-managed backup solution for file shares managed by Azure File Sync, your ACLs might not be restored properly to NTFS ACLs if the snapshots were taken before February 24, 2020. В этом случае рассмотрите возможность обращения в службу поддержки Azure.

  • Синхронизирует ли Azure File Sync параметр LastWriteTime для каталогов? Почему метка времени "дата изменения" в каталоге не обновляется, когда изменяются находящиеся в нем файлы?
    Нет, в Azure File Sync не синхронизируется время последней записи для каталогов. Furthermore, Azure Files doesn't update the date modified timestamp (LastWriteTime) for directories when files within the directory are changed. Это ожидаемое поведение.

  • Почему антивирусное программное обеспечение на сервере AFS ссылается на многоуровневые файлы?
    Когда пользователи получают доступ к многоуровневым файлам, некоторые антивирусные программы (AV) могут вызвать непреднамеренное восстановление файлов. Это происходит, если программное обеспечение AV не настроено игнорировать многоуровневые файлы (те, которые используют атрибут RECALL_ON_DATA_ACCESS). Происходит следующее:

    1. Пользователь стремится получить доступ к многоуровневому файлу.
    2. The AV software blocks the read handle.
    3. Затем приложение AV выполняет собственное чтение, чтобы проверить файл на наличие вирусов.

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

  • Может ли проверка SSL блокировать доступ к серверам AFS? Убедитесь, что программное обеспечение проверки SSL (например, Zscaler или FortiGate) позволяет конечным точкам сервера Синхронизация файлов Azure (AFS) получить доступ к Azure. Эти средства проверки SSL могут переопределить параметры брандмауэра и выборочно разрешить трафик. Чтобы устранить эту проблему, обратитесь к администратору сети. Используйте команду testnet, чтобы определить, испытывает ли сервер AFS эту проблему.

Безопасность, проверка подлинности и управление доступом

  • Как выполнять аудит изменений и доступа к файлам в службе "Файлы Azure"?

    Существуют два варианта, которые предоставляют функции аудита для службы Файлы Azure.

    • Если пользователи обращаются к общей папке Azure напрямую, можно использовать журналы Azure Storage для отслеживания изменений файлов и доступа пользователей для устранения неполадок. Requests are logged on a best-effort basis.
    • Если пользователи обращаются к общей папке Azure через Windows Server с установленным агентом Синхронизации файлов Azure, используйте политику аудита или сторонний продукт, чтобы отслеживать изменения файлов и доступ пользователей на Windows Server.

  • Поддерживает ли служба файлов Azure использование перечисления на основе доступа (ABE) для управления видимостью файлов и папок в общих папках SMB Azure?

    В настоящее время использование ABE с Файлами Azure не поддерживается, но вы можете использовать DFS-N с общими папками SMB в Azure.

  • Можно ли сохранить файловый ресурс Azure с помощью принтера или сканера?

    Файлы Azure поддерживает только Windows, Linux и macOS. Доступ к общей папке Azure непосредственно с принтера или сканера не поддерживается. Однако если вы уже используете Azure File Sync, вы можете распечатать или сканировать на файловом сервере Windows, а затем синхронизировать файл с общей файловой папкой Azure.

  • Поддерживают ли файлы Azure альтернативные потоки данных?

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

get-item <file path+name> -Stream *

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

remove-Item <file path+name> -Stream *

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

Проверка подлинности на основе удостоверений

  • Поддерживают ли доменные службы Microsoft Entra доступ SMB с использованием учетных данных Microsoft Entra с устройств, которые присоединены или зарегистрированы в Microsoft Entra ID?

    Нет, этот сценарий не поддерживается.

  • Можно ли использовать каноническое имя (CNAME) для монтирования файлового хранилища Azure при использовании проверки подлинности на основе удостоверений?

    Yes, this scenario is now supported in both single-forest and multi-forest environments for SMB Azure file shares. However, Azure Files only supports configuring CNAMEs using the storage account name as a domain prefix. Если вы не хотите использовать имя учетной записи хранения в качестве префикса, рассмотрите возможность использования Пространств имен DFS.

  • Можно ли получить доступ к общим папкам Azure с учетными данными Microsoft Entra из виртуальной машины в другой подписке?

    Если подписка, на основе которой развернут файловый ресурс, связана с тем же клиентом Microsoft Entra, что и с развертыванием доменных служб Microsoft Entra, к которому присоединена виртуальная машина, то вы сможете получить доступ к файловым ресурсам Azure, используя те же учетные данные Microsoft Entra. The limitation is imposed not on the subscription but on the associated Microsoft Entra tenant.

  • Можно ли включить доменные службы Microsoft Entra или локальную проверку подлинности AD DS для общих папок Azure с помощью клиента Microsoft Entra, отличного от основного клиента общей папки Azure?

    No. Azure Files only supports Microsoft Entra Domain Services or on-premises AD DS integration with a Microsoft Entra tenant that resides in the same subscription as the file share. Подписка может быть связана только с одним клиентом Microsoft Entra. При использовании локальных AD DS для проверки подлинности, учетные данные AD DS следует синхронизировать в Microsoft Entra ID, с которым связана учетная запись хранения.

  • Does on-premises AD DS authentication for Azure file shares support integration with an AD DS environment using multiple forests?

    Azure Files on-premises AD DS authentication only integrates with the forest of the domain service that the storage account is registered to. To support authentication from another forest, your environment must have a forest trust configured correctly. For detailed instructions, see Use Azure Files with multiple Active Directory forests.

    Примечание.

    In a multi-forest setup, don't use File Explorer to configure Windows ACLs/NTFS permissions at the root, directory, or file level. Вместо этого используйте icacls .

  • Есть ли какие-либо различия между созданием учетной записи компьютера или учетной записи входа службы для представления моей учетной записи хранения в AD?

    Создание учетной записи компьютера (по умолчанию) или учетной записи входа в службу не влияет на способ работы проверки подлинности с файлами Azure. Вы можете выбрать, как представить учетную запись хранилища в качестве идентичности в среде AD. Тип DomainAccountType, установленный по умолчанию в командлете Join-AzStorageAccountForAuth, — это учетная запись компьютера. Однако срок действия пароля, настроенный в вашей среде AD, может отличаться для учетных записей входа в систему компьютера или службы, и необходимо учитывать это, чтобы обновить пароль удостоверения учетной записи хранения в AD.

  • Как удалить кэшированные учетные данные с ключом учетной записи хранения и удалить существующие подключения SMB перед инициализацией нового подключения с помощью идентификатора Microsoft Entra или учетных данных AD?

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

    1. Выполните следующую команду из командной строки Windows, чтобы удалить учетные данные. If you can't find one, it means that you haven't persisted the credential and can skip this step.

      cmdkey /delete:Domain:target=storage-account-name.file.core.windows.net

    2. Удалите существующее подключение к общей папке. You can specify the mount path as either the mounted drive letter or the storage-account-name.file.core.windows.net path.

      net use <drive-letter/share-path> /delete

  • Is it possible to view the userPrincipalName (UPN) of a file/directory owner in File Explorer instead of the security identifier (SID)?

    File Explorer calls an RPC API directly to the server (Azure Files) to translate the SID to a UPN. Azure Files не поддерживает этот API, поэтому в Проводнике идентификатор безопасности владельца файла или каталога отображается вместо UPN для файлов и каталогов, размещенных в Azure Files. Однако из присоединенного к домену клиента можно использовать следующую команду PowerShell для просмотра всех элементов в каталоге и их владельца, включая UPN:

    Get-ChildItem <Path> | Get-ACL | Select Path, Owner

Сетевая файловая система (NFS версии 4.1)

  • Когда следует использовать общие папки Azure NFS?

    See NFS shares.

  • Как сохранить резервные копии данных, хранящихся в общих папках NFS?

    Резервное копирование данных на общих ресурсах NFS может быть организовано с помощью привычных средств, например rsync или с помощью продуктов от одного из наших сторонних партнеров по резервному копированию. Несколько партнеров по резервному копированию, включая Commvault, Veeam и Veritas, расширили свои решения для работы с SMB 3.x и NFS 4.1 для Файлы Azure. You can also use NFS Azure file share snapshots.

  • Можно ли перенести существующие данные в общую папку NFS?

    В пределах региона можно использовать стандартные средства, такие как scp, rsync или SSHFS, для перемещения данных. Так как к общим папкам Azure NFS можно получить доступ из нескольких вычислительных экземпляров одновременно, вы можете повысить скорость копирования с параллельными отправками. Дополнительные сведения см. в статье Миграция на файловые ресурсы Azure NFS. Если вы хотите перенести данные извне региона, используйте VPN или ExpressRoute для подключения к файловой системе из локального центра обработки данных.

  • Можно ли запустить IBM MQ (включая несколько экземпляров) в общих папках Azure NFS?

Делитесь моментальными снимками

Create share snapshots

  • Являются ли мои снимки общего доступа геоизбыточными?
    Share snapshots have the same redundancy as the Azure file share for which they were taken. If you've selected geo-redundant storage for your account, your share snapshot also is stored redundantly in the paired region.

Clean up share snapshots

  • Can I delete my share but not delete my share snapshots?
    No. The delete file share workflow will automatically delete the snapshots when you delete the share.

Выставление счетов и ценообразование

  • Что такое транзакции в Azure Files и как они учитываются? Транзакции протокола происходят в любое время, когда пользователь, приложение, скрипт или служба взаимодействуют с общими папками Azure (запись, чтение, просмотр, удаление файлов и т. д.). Важно помнить, что некоторые действия, которые могут восприниматься как одна операция, может на самом деле включать несколько транзакций. Для стандартных файловых ресурсов Azure, оплачиваемых по модели "плати по мере использования", различные типы транзакций имеют разные цены в зависимости от их влияния на файловый ресурс. Transactions don't affect billing for premium file shares, which are billed using a provisioned model. Дополнительные сведения см. в статье Общие сведения о выставлении счетов.

  • How much do share snapshots cost?
    Share snapshots are incremental in nature. The base share snapshot is the share itself. All subsequent share snapshots are incremental and store only the difference from the preceding share snapshot. Вы платите только за измененное содержимое. If you have a share with 100 GiB of data but only 5 GiB has changed since your last share snapshot, the share snapshot consumes only 5 additional GiB, and you're billed for 105 GiB. For more information about transaction and standard egress charges, see the Pricing page.

Взаимодействие с другими службами

  • Можно ли использовать общую папку Azure в качестве общей папки-свидетеля для отказоустойчивого кластера Windows Server?
    Эта конфигурация в настоящее время не поддерживается Azure Files. To learn how to set this up using Azure Blob storage, see Deploy a Cloud Witness for a Failover Cluster.

См. также