Часто задаваемые вопросы о службе файлов Azure

  • Статья

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

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

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

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

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

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

    Для немедленной синхронизации файлов, измененных в общей папке 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 не перезаписывает файлы в группе синхронизации. Вместо этого она использует простую стратегию разрешения конфликтов: она сохраняет оба изменения в файлах, которые изменяются в двух конечных точках одновременно. Сохранится имя того файла, который был изменен последним. Старый файл (определяется LastWriteTime) имеет имя конечной точки и номер конфликта, добавленный к имени файла. Для конечных точек сервера имя конечной точки — это имя сервера. Для облачных конечных точек имя конечной точки — Cloud. Имя соответствует следующей таксономии:

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

    Например, файл CompanyReport.docx при первом конфликте станет CompanyReport-CentralServer.docx, где CentralServer является расположением, в котором запись изменений произошла раньше. Для второго конфликта соответственно будет использоваться имя CompanyReport-CentralServer-1.docx. Синхронизация файлов Azure поддерживает 100 конфликтующих файлов для каждого файла. После достижения максимального количества конфликтующих файлов синхронизация файлов будет завершаться сбоем, пока количество конфликтующих файлов не станет меньше 100.

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

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

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

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

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

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

  • Почему распределенные по уровням файлы существуют вне пространства имен конечной точки сервера?
    До выпуска агента службы "Синхронизация файлов Azure" версии 3 эта служба блокировала перемещение многоуровневых файлов за пределы конечной точки сервера, но на тот же том, на котором размещена эта конечная точка сервера. Операции копирования, перемещение неуровневых файлов и перемещение многоуровневых файлов в другие тома не пострадали. Причиной такого поведения было неявное предположение о том, что проводник и другие интерфейсы API Windows обрабатывают эти операции перемещения на тот же том, что и (практически) мгновенные операции переименования. Это означает, что после перемещения с помощью проводника или других методов перемещения (например, командной строки или PowerShell) будет невозможно отозвать данные из облака с помощью службы "Синхронизация файлов Azure". Начиная с агента службы "Синхронизация файлов Azure" версии 3.0.12.0 эта служба позволяет переместить многоуровневый файл за пределы конечной точки сервера. Мы избегаем упомянутых выше проблем, позволяя многоуровневому файлу существовать в виде многоуровневого файла за пределами конечной точки сервера, а затем отзывая этот файл в фоновом режиме. Это означает, что перемещение на одном томе мгновенно, и мы делаем все действия, чтобы отозвать файл на диск после завершения перемещения.

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

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

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

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

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

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

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

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

      Примечание.

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

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

    По состоянию на 24 февраля 2020 г. новые и существующие списки управления доступом, сгруппированные с помощью службы синхронизации файлов Azure, сохраняются в формате NTFS, а изменения этих списков, вносимые непосредственно в общий файловый ресурс Azure, будут синхронизироваться со всеми серверами в группе синхронизации. Любые изменения списков управления доступом, внесенные в общие папки Azure, будут синхронизированы с помощью Синхронизация файлов Azure. При копировании данных в Файлы Azure убедитесь, что вы используете средство копирования, которое поддерживает необходимую "точность" для копирования атрибутов, меток времени и списков управления доступом в общую папку Azure — через S МБ или REST. При использовании средств копирования Azure, таких как AzCopy, важно использовать последнюю версию. Просмотрите таблицу средств копирования файлов для получения общих сведений о средствах копирования Azure, чтобы обеспечить возможность копирования всех важных метаданных файла.

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

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

  • Синхронизирует ли Синхронизация файлов Azure LastWriteTime для каталогов? Почему метка времени изменения даты в каталоге не обновляется при изменении файлов в нем?
    Нет, Синхронизация файлов Azure не выполняет синхронизацию LastWriteTime для каталогов. Кроме того, Файлы Azure не обновляет метку времени изменения даты (LastWriteTime) для каталогов при изменении файлов в каталоге. Это ожидаемое поведение.

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

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

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

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

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

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

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

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

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

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

    Да, этот сценарий теперь поддерживается как в средах с одним лесом, так и в нескольких лесах для общих папок Azure МБ. Однако Файлы Azure поддерживает только настройку CNAMEs с использованием имени учетной записи хранения в качестве префикса домена. Если вы не хотите использовать имя учетной записи хранения в качестве префикса, рассмотрите возможность использования пространств имен DFS.

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

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

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

    № Файлы Azure поддерживает только доменные службы Microsoft Entra или локальную интеграцию AD DS с клиентом Microsoft Entra, который находится в той же подписке, что и общая папка. Подписка может быть связана только с одним клиентом Microsoft Entra. При использовании локальных ad DS для проверки подлинности учетные данные AD DS следует синхронизировать с идентификатором Microsoft Entra, с которым связана учетная запись хранения.

  • Поддерживает ли локальная проверка подлинности AD DS для общих папок Azure интеграцию со средой AD DS, использующей несколько лесов?

    Локальная проверка подлинности AD DS Файлов Azure интегрируется только с лесом доменной службы, в которой зарегистрирована учетная запись хранения. Для поддержки проверки подлинности из другого леса в среде должно быть правильно настроено доверие леса. Подробные инструкции см. в разделе "Использование Файлы Azure с несколькими лесами Active Directory".

    Примечание.

    В настройке с несколькими лесами не используйте проводник для настройки разрешений Windows ACL/NTFS на корневом уровне, каталоге или файле. Вместо этого используйте icacls .

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

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

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

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

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

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

    2. Удалите существующее подключение к общей папке. Можно указать путь подключения как букву подключенного storage-account-name.file.core.windows.net диска или путь.

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

  • Можно ли просмотреть имя пользователяPrincipalName (UPN) владельца файла или каталога в проводник вместо идентификатора безопасности (SID)?

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

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

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

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

    См. статью об общих папках NFS.

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

    Резервное копирование данных на общих ресурсах NFS может быть организовано с помощью привычных средств, например rsync или с помощью продуктов от одного из наших сторонних партнеров по резервному копированию. Несколько партнеров по резервному копированию, включая Commvault, Veeam и Veritas, расширили свои решения для работы с S МБ 3.x и NFS 4.1 для Файлы Azure. Вы также можете использовать моментальные снимки общих папок NFS Azure.

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

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

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

Моментальные снимки общих ресурсов

Создание моментальных снимков общих ресурсов

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

Удаление моментальных снимков общих ресурсов

  • Можно ли удалить общую папку, не удаляя ее моментальные снимки?
    Вам не удастся удалить общий ресурс, если в нем имеются активные моментальные снимки общего ресурса. Вы можете использовать API для удаления моментальных снимков общего ресурса вместе с ресурсом. Вы также можете удалить моментальные снимки общего ресурса и сам ресурс на портале Azure.

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

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

  • Сколько нужно платить за моментальные снимки общей папки?
    По своей природе моментальные снимки общих ресурсов являются добавочными. Базовый моментальный снимок общего ресурса — это сам общий ресурс. Последующие моментальные снимки общего ресурса — добавочные. Они хранят только отличия от предыдущего моментального снимка общего ресурса. Тарифицируется только измененное содержимое. Если общий ресурс содержит 100 ГиБ данных, из которых с момента создания последнего моментального снимка общего ресурса изменилось всего лишь 5 ГиБ, моментальный снимок общего ресурса использует только 5 ГиБ дополнительно, и счет будет выставлен за 105 ГиБ. Дополнительные сведения о стандартных расходах на транзакции и исходящие данные см. на странице цен.

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

См. также