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

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

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

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

Ограничения устройства Data Box Heavy

  • Data Box Heavy может хранить не более 1 млрд файлов на каждом узле.
  • Data Box Heavy поддерживает не более 512 контейнеров или общих папок для каждого узла в облаке. Каталоги верхнего уровня в общей папке пользователя преобразуются в облаке в контейнеры или общие папки Azure.
  • Data Box в настоящее время не поддерживает сценарий, в котором данные клиента активно изменяются во время экспорта.

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

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

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

Внимание

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

Предупреждения, связанные с передачей данных

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

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

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

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

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

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

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

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

    Объект Соглашения
    Имена контейнеров для блобов блочного и страничного типов Это должно быть допустимое DNS-имя длиной от 3 до 63 знаков.
    Должно начинаться с буквы или цифры.
    Может содержать только строчные буквы, цифры и дефисы (-).
    Перед каждым дефисом и после него должна стоять буква или цифра.
    Последовательные дефисы в именах использовать запрещено.
    Имена общего доступа для файлов Azure То же, что и выше
    Имена каталогов и файлов для файлов Azure
  • Сохраняющие регистр, нечувствительные к регистру и не превышающие 255 символов в длину.
  • Нельзя заканчивать косой чертой (/).
  • Если это предусмотрено, она будет автоматически удалена.
  • Запрещается использовать следующие символы: " \ / : | < > * ?
  • Зарезервированные символы URL должны быть надлежащим образом экранированы.
  • Недопустимые символы для пути 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 символов.
  • Зарезервированные символы URL должны быть надлежащим образом экранированы.
  • Число сегментов пути, содержащих имя BLOB-объекта, не может превышать 254. Сегмент пути — это строка между последовательными символами-разделителями (например, косая черта"/"), которая соответствует имени виртуального каталога.
    		•
    • Last updated on