Ограничения Azure Data Box

  • Статья

Учитывайте эти ограничения, когда развертываете и используете Microsoft Azure Data Box. Ограничения для Data Box описаны в следующей таблице.

Ограничения службы Data Box

  • Если в службе Data Box используется несколько учетных записей хранения, все они должны принадлежать одному региону Azure.
  • Мы рекомендуем использовать не более трех учетных записей хранения. Использование большего количества учетных записей хранения может потенциально повлиять на производительность.

Ограничения Data Box

  • В Data Box может храниться до 500 млн файлов как для импорта, так и для экспорта.
  • Data Box Heavy поддерживает до 512 контейнеров или общих папок для каждого узла в облаке. Каталоги верхнего уровня в общей папке пользователя преобразуются в облаке в контейнеры или общие папки Azure.
  • Емкость использования Data Box может быть меньше 80 ТиБ из-за потребления пространства метаданных ReFS.
  • Data Box поддерживает не более 10 клиентских подключений одновременно в общей папке NFS.

Ограничения службы хранилища Azure

Этот раздел описывает ограничения для службы хранилища Azure и требуемые соглашения об именовании для файлов Azure, блочных BLOB-объектов Azure и страничных BLOB-объектов Azure применительно к службе Data Box. Тщательно изучите ограничения хранилища и следуйте всем рекомендациям.

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

Внимание

Если имеются любые файлы или каталоги, превышающие ограничения службы хранилища Azure или несоответствующие соглашениям об именовании Файлов и BLOB-объектов Azure, они не направляются в службу хранилища Azure через службу Data Box.

Копирование данных и отправка предостережения

Заказ на импорт

Предупреждения при использовании Data Box для заказа на импорт:

  • Контейнеры, общие папки и папки:
    • Не копируйте файлы непосредственно в созданные общие ресурсы. Вам необходимо создать папку в общем ресурсе, а затем скопировать в него файлы.
    • Папка в разделах StorageAccount_BlockBlob и StorageAccount_PageBlob — это контейнер. Например, контейнеры создаются в виде StorageAccount_BlockBlob/container и StorageAccount_PageBlob/container.
    • Каждая папка, созданная непосредственно в StorageAccount_AzFile, преобразуется в общую папку Azure.
    • Хранилище BLOB-объектов Azure не поддерживает каталоги. Если вы создаете папку в папке StorageAccount_BlockBlob, тогда виртуальные папки создаются в имени большого двоичного объекта. Для файлов Azure поддерживается фактическая структура каталогов.
  • Объединение содержимого папки:
    • Каждый файл, записанный в общие папки StorageAccount_BlockBlob и StorageAccount_PageBlob, отправляется в виде блочного и страничного BLOB-объекта соответственно.
    • Если папка имеет то же имя, что и существующий контейнер, содержимое этой папки объединяется с содержимым контейнера. Файлы или BLOB-объекты, которые не находятся уже в облаке, добавляются в контейнер. Если файл или BLOB-объект имеет то же имя, что и файл или BLOB-объект, который уже находится в контейнере, существующий файл или BLOB-объект перезаписывается.
    • Отправка в большой двоичный объект на уровне архива завершится ошибкой, если контейнер имеет существующий архивированный большой двоичный объект с тем же именем. Если BLOB-объект находится на архивном уровне, его невозможно прочитать или изменить. Если необходимо перезаписать большой двоичный объект, убедитесь, что большой двоичный объект не задан для архивации. Дополнительные сведения см. в разделе Архивный уровень доступа.
    • Любая пустая иерархия каталогов (без файлов), созданная в папках StorageAccount_BlockBlob и StorageAccount_PageBlob, не передается.
  • Импорт данных в общие папки Azure NFS не поддерживается Azure Data Box. Копирование данных из Data Box в существующую общую папку NFS Azure с идентичным именем, так как исходная папка создает конфликт. Чтобы устранить этот конфликт, Data Box переименовывает исходную папку databox-<GUID> в целевую учетную запись хранения и отправляет ее в целевую учетную запись хранения в качестве общей папки SMB Azure.
  • Если для копирования данных используются протоколы SMB и NFS, рекомендуется:
    • Использовать разные учетные записи хранения для SMB и NFS.
    • Не копировать одни и те же данные в одно расположение в Azure с помощью SMB и NFS. В таких случаях невозможно предсказать окончательный результат.
    • Хотя параллельное копирование через SMB и NFS может работать, мы не советуем делать это, так могут возникать ошибки из-за действий человека. Дождитесь завершения копирования данных через SMB, прежде чем начать копирование данных через NFS.
  • Управление отправкой:
    • Если при отправке данных в Azure возникают ошибки, в целевой учетной записи хранения создается журнал ошибок. Путь к этому журналу ошибок доступен после завершения передачи, чтобы вы могли просмотреть журнал и предпринять корректирующие действия. Не удаляйте данные из источника, не проверив переданные данные.
    • Метаданные файлов и разрешения NTFS могут сохраняться при передаче данных в Файлы Azure с помощью рекомендаций по сохранению списков управления доступом, атрибутов и меток времени файлов в Azure Data Box.
    • Иерархия файлов сохраняется при отправке в облако для больших двоичных объектов и Файлы Azure. Например, вы скопировали файл по пути <container folder>\A\B\C.txt. Этот файл передается в тот же путь в облаке.
    • Если поле CreateTime или LastWriteTime для файла превышает допустимый размер во время отправки, "Fri, 31 декабря 9999 23:59:59" заменяет исходную дату в свойстве файла Azure. Отправка файла завершается успешно, и ошибка не возникает.

Заказ на экспорт

Предупреждения при использовании Data Box для заказа на экспорт:

  • Data Box является устройством на основе Windows и не поддерживает имена файлов с учетом регистра. Например, в Azure может быть два разных файла с именами, которые просто отличаются в регистре. Не используйте Data Box для экспорта таких файлов, как файлы, перезаписаны на устройстве.
  • При наличии во входных файлах повторяющихся тегов или тегов, ссылающихся на одни и те же данные, Data Box при экспорте может пропустить или перезаписать такие файлы. Количество файлов и размер данных, отображаемых на портале Azure, может отличаться от фактического размера данных на устройстве.
  • Data Box экспортирует данные в систему под управлением Windows по протоколу SMB и ограничивается ограничениями SMB для файлов и папок. Файлы и папки с неподдерживаемыми именами не экспортируются.
  • Существует сопоставление 1:1 из префикса в контейнер.
  • Максимальный размер имени файла составляет 1024 символов. Файлы с именами, превышающими эту длину, не экспортируются.
  • Дубликаты префиксов в XML-файле (переданном при создании заказа) экспортируются. Повторяющиеся префиксы не игнорируются.
  • Страничные BLOB-объекты и имена контейнеров задаются с учетом регистра. Если регистр не совпадает, большой двоичный объект и (или) контейнер не найден.

Ограничения размера для учетной записи хранения Azure

Ниже приведены ограничения для размера данных, копируемых в учетную запись хранения. Убедитесь, что отправляемые данные соответствуют этим ограничениям. Самую свежую информацию об этих ограничениях см. в статьях Целевые показатели масштабируемости и производительности для хранилища BLOB-объектов и Целевые показатели масштабируемости и производительности службы файлов Azure.

Размер данных, копируемых в учетную запись хранения Azure Ограничение по умолчанию
Блочный BLOB-объект и страничный BLOB-объект Максимальное ограничение совпадает с ограничением хранилища, определенным для подписки Azure, и включает данные из всех источников, включая Data Box.
Файлы Azure Data Box поддерживает общие папки Azure premium, которые позволяют в общей сложности 100 ТиБ для всех общих папок в учетной записи хранения. Максимальная доступная емкость немного меньше, поскольку часть ее занимают журналы копирования и аудита. Для этих журналов зарезервировано не менее 100 ГиБ. Дополнительные сведения см. в разделе Журналы аудита для Azure Data Box и Azure Data Box Heavy. Все папки в StorageAccount_AzFile должны соответствовать этому ограничению. Дополнительные сведения см. в статье Создание общей папки Azure.

Ограничения размера для объектов Azure

Ниже приведены размеры объектов Azure, которые могут быть записаны. Убедитесь, что все передаваемые файлы соответствуют этим ограничениям.

Тип объекта Azure Ограничение по умолчанию
Блочный BLOB-объект 14 ТиБ
Страничный BLOB-объект 4 ТиБ
Каждый файл, отправляемый в формате страничного BLOB-объекта, должен быть выровнен по размеру 512 байт (целое кратное). В противном случае произойдет сбой передачи.
VHD и VHDX выровнены по размеру 512 байт.
Файлы Azure 4 ТиБ
Управляемые диски 4 ТиБ
Дополнительные сведения о размерах и ограничениях см. в следующем разделе:
  • Целевые показатели масштабируемости для твердотельных накопителей стандартной категории
  • Целевые показатели масштабируемости твердотельных накопителей категории Premium
  • Целевые показатели масштабируемости для жестких дисков стандартной категории
  • Сведения о ценах и выставлении счетов для управляемых дисков
    		•

    Соглашения об именовании для файлов, блочных и страничных BLOB-объектов Azure

    Объект Соглашения
    Имена контейнеров для блочного BLOB-объекта и страничного BLOB-объекта Это должно быть допустимое DNS-имя длиной от 3 до 63 знаков.
    Первый символ — буква или цифра.
    Может содержать только строчные буквы, цифры и дефисы (-).
    Перед каждым дефисом и после него должна стоять буква или цифра.
    Последовательные дефисы в именах использовать запрещено.
    Имена общих ресурсов для файлов Azure То же, что и выше
    Имена каталогов и файлов для файлов Azure
  • Не меняющие и не учитывающие регистр, не превышающие 255 символов.
  • Не может заканчиваться косой чертой (/).
  • Если это предусмотрено, она будет автоматически удалена.
  • Запрещается использовать следующие символы: " \ / : | < > * ?
  • Зарезервированные веб-адреса должны быть надлежащим образом экранированы.
  • Запрещены недопустимые символы для URL-пути. Кодовые точки, такие как \uE000, не являются допустимыми символами Юникода. Некоторые символы ASCII или Юникода, такие как управляющие символы (от 0x00 до 0x1F, \u0081 и т. д.), также не допускаются. Правила, регулирующие строки Юникода в HTTP/1.1, см. в документах RFC 2616, Section 2.2: Basic Rules (раздел 2.2: Основные правила) и RFC 3987.
  • Следующие имена файлов являются недопустимыми: LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, PRN, AUX, NUL, CON, CLOCK$, символ точки (.) и символ двух точек (..).
    		•
    Имена блочного BLOB-объекта и страничного BLOB-объекта
  • Имена BLOB-объектов указываются с учетом регистра и могут содержать любое сочетание символов.
  • Длина имени BLOB-объекта должна составлять от 1 до 1024 символов.
  • Зарезервированные веб-адреса должны быть надлежащим образом экранированы.
  • Число сегментов пути, содержащих имя BLOB-объекта, не может превышать 254. Сегмент пути — это строка между последовательными символами-разделителями (например, косая черта"/"), которая соответствует имени виртуального каталога.
    		•