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

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

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

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

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

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

    Изменения, внесенные в общий файловый ресурс Azure с использованием портала Azure или SMB, сразу не обнаруживаются и не реплицируются, как изменения в конечной точке сервера. В службе файлов Azure пока не предусмотрена возможность уведомлений об изменениях или ведение журнала изменений, поэтому автоматически инициировать сеанс синхронизации при изменении файлов невозможно. На Windows Server служба "Azure File Sync" использует журналирование 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 File Sync. Проводник Windows отображает "серый X" для всех файлов с атрибутом офлайн. При доступе к файлам по протоколу SMB будет отображаться значок X. Подробное объяснение этого поведения см. в статье "Почему я не получаю эскизов для файлов, помеченных как находящиеся в автономном режиме?"

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

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

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

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

      reg ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Azure\StorageSync" /v SkipOfflineAttributeOnTieredFile /t RE

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

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

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

    Примечание.

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

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

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

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

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

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

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

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

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

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

      Примечание.

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

  • Сохраняет ли служба синхронизации файлов 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 общих папок, списки управления доступом к файлам можно продолжать восстанавливать в процессе восстановления резервной копии. Это работает либо для всего общего ресурса, либо для отдельных файлов и каталогов.

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

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

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

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

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

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

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

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

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

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

    • Если пользователи обращаются к общей папке Azure напрямую, можно использовать журналы Azure Storage для отслеживания изменений файлов и доступа пользователей для устранения неполадок. Запросы регистрируются по мере возможности.
    • Если пользователи обращаются к общей папке 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 при использовании проверки подлинности на основе удостоверений?

    Да, этот сценарий теперь поддерживается как в средах с одним лесом, так и в многолесных средах для файловых ресурсов 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 .

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

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

  • Как удалить кэшированные учетные данные с ключом учетной записи хранения и удалить существующие подключения SMB перед инициализацией нового подключения с помощью идентификатора Microsoft Entra или учетных данных 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 Files), чтобы перевести SID в UPN. Azure Files не поддерживает этот API, поэтому в Проводнике идентификатор безопасности владельца файла или каталога отображается вместо UPN для файлов и каталогов, размещенных в Azure Files. Однако из присоединенного к домену клиента можно использовать следующую команду 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 Files и как они учитываются? Транзакции протокола происходят в любое время, когда пользователь, приложение, скрипт или служба взаимодействуют с общими папками Azure (запись, чтение, просмотр, удаление файлов и т. д.). Важно помнить, что некоторые действия, которые могут восприниматься как одна операция, может на самом деле включать несколько транзакций. Для файловых ресурсов с оплатой по мере использования различные типы транзакций имеют разные цены, основываясь на их влиянии на файловый ресурс. Выставление счетов за предоставленные общие ресурсы не зависит от транзакций. Дополнительные сведения см. в статье Общие сведения о выставлении счетов.

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

См. также

  • Last updated on