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

Файлы Azure предлагает полностью управляемые файловые ресурсы в облаке, к которым вы можете получить доступ через стандартный протокол Server Message Block (SMB) и протокол Network File System (NFS). Вы можете монтировать папки Azure File Share как в облачных, так и в локальных развертываниях Windows, Linux и macOS. Используя Синхронизация файлов Azure, вы можете кэшировать файловые ресурсы Azure на компьютерах Windows Server для быстрого доступа к данным, находящимся рядом с местом использования.

Синхронизация файлов Azure FAQ

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

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

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

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

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

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

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

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

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

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

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

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

  • Можно ли игнорировать автономный атрибут для иерархически организованных файлов?

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

    1. Добавьте на сервер следующий раздел реестра:

      reg ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Azure\StorageSync" /v SkipOfflineAttributeOnTieredFile /t REG_DWORD /d 1 /f

    2. Перезапустите службу FileSyncSvc .

    После настройки:

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

    Примечание.

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

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

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

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

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

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

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

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

      Если Microsoft.StorageSync или Hybrid File Sync Service не отображается в списке, выполните следующие действия:

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

      Примечание.

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

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

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

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

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

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

  • Как пространство томов работает для уровня облака в рамках взаимодействия с дедуптом?
    В некоторых случаях, когда установлен Dedup, доступное объёмное пространство может увеличиться больше, чем ожидалось, после запуска сбора мусора Dedup. Например, предположим, что политика свободного пространства для облачного тиринга установлена на 20%. Синхронизация файлов Azure уведомляется, когда свободное пространство мало (например, если свободное пространство равно 19%). Тиеринг определяет, что нужно освободить ещё 1% пространства, но дополнительно предусмотрен буфер в 5%, поэтому в результате объём увеличивается до 25% (например, 30 ГиБ). Файлы распределяются по уровням хранения, пока их объём не достигнет 30 ГиБ. В рамках обеспечения совместимости с Dedup служба Синхронизация файлов Azure инициирует сборку мусора в конце сеанса разбиения по уровням хранения.

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

    1. Пользователь стремится получить доступ к многоуровневому файлу.
    2. Антивирусное программное обеспечение блокирует дескриптор чтения.
    3. Затем антивирусное программное обеспечение выполняет собственное чтение для сканирования файла на наличие вирусов.

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

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

Поставщики ресурсов и классические файловые ресурсы

  • В чем разница между поставщиками ресурсов Microsoft.Storage и Microsoft.FileShares? Что такое Azure file share по сравнению с Azure classic file share?

    Поставщики ресурсов — это сервисы управления, которые предоставляют определённые типы ресурсов в Azure. Вы развертываете классические файловые общие ресурсы Azure в учетной записи хранения, которая является ресурсом верхнего уровня и использует поставщик ресурсов Microsoft.Storage. Все ресурсы хранения в учетной записи хранения используют общие ограничения, действующие для этой учетной записи хранения. Файловые общие ресурсы, предоставляемые поставщиком ресурсов Microsoft.FileShares, — это новый ресурс верхнего уровня, который упрощает развертывание файловых общих ресурсов, устраняя необходимость в учётной записи хранения. В настоящее время Microsoft. FileShares поддерживает только протокол обмена файлами NFS. Классические файловые совместные системы поддерживают как SMB, так и NFS.

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

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

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

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

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

    Файлы Azure не поддерживает использование ABE, но вы можете использовать DFS-N с SMB Azure файловыми ресурсами.

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

    Файлы Azure поддерживает только Windows, Linux и macOS. Доступ к общей папке Azure непосредственно с принтера или сканера не поддерживается. Однако если вы уже используете Синхронизация файлов Azure, вы можете распечатать или сканировать на файловом сервере 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 при использовании проверки подлинности на основе удостоверений?

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

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

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

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

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

  • Поддерживает ли локальная AD DS-аутентификация для файловых ресурсов Azure интеграцию со средой AD DS с несколькими лесами?

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

    Примечание.

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

  • Существует ли разница в создании учетной записи компьютера или учетной записи входа в службу для представления учетной записи хранения в Active Directory?

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

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

    Следуйте двухэтапному процессу удаления сохранённых учетных данных, связанных с ключом учетной записи хранилища, и удаления соединения SMB:

    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

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

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

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

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

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

    См. общие папки NFS.

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

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

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

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

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

Часто задаваемые вопросы о предоставлении снимков

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

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

Очистка моментальных снимков сетевого ресурса

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

Выставление счетов и цены на Файлы Azure

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

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

  • В чем разница между Файлы Azure и Azure NetApp Files?
    Файлы Azure и Azure NetApp Files являются разными службами хранения файлов в Azure, и они предназначены для различных рабочих нагрузок и требований к производительности. Файлы Azure предоставляет бессерверные общие папки SMB и NFS и предлагает Синхронизация файлов Azure в качестве варианта кэширования общих папок SMB на Windows Server. Azure NetApp Files — это высокопроизводительная служба хранения файлов на платформе без виртуализации с поддержкой технологии NetApp, которая поддерживает общие папки NFS, SMB и двухпротокольные хранилища. Дополнительные сведения см. в разделе Compare Файлы Azure и Azure NetApp Files.

  • Можно ли использовать общую папку Azure в качестве общей папки-свидетеля для отказоустойчивого кластера Windows Server?
    Эта конфигурация не поддерживается для Файлы Azure. Чтобы узнать, как настроить эту конфигурацию с использованием хранилища BLOB-объектов Azure, см. «Развертывание облачного свидетеля для отказоустойчивого кластера».

См. также

  • Last updated on