Ограничения 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.

Ограничения службы хранилища 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, тогда виртуальные папки создаются в имени большого двоичного объекта. Для файлов 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> папку в целевую учетную запись хранения в качестве общей папки S МБ Azure.
  • Если для копирования данных используются протоколы S МБ и NFS, рекомендуется:
    • Использовать разные учетные записи хранения для SMB и NFS.
    • Не копировать одни и те же данные в одно расположение в Azure с помощью SMB и NFS. В таких случаях невозможно предсказать окончательный результат.
    • Хотя параллельное копирование через SMB и NFS может работать, мы не советуем делать это, так могут возникать ошибки из-за действий человека. Дождитесь завершения копирования данных через SMB, прежде чем начать копирование данных через NFS.
  • Управление отправкой:
    • Чтобы повысить производительность при передаче данных, рекомендуется включить большие общие папки в учетной записи хранения и увеличить емкость общей папки до 100 ТиБ.
    • Если при отправке данных в Azure возникают ошибки, в целевой учетной записи хранения создается журнал ошибок. Путь к этому журналу ошибок доступен после завершения передачи, чтобы вы могли просмотреть журнал и предпринять корректирующие действия. Не удаляйте данные из источника, не проверив переданные данные.
    • Метаданные файлов и разрешения NTFS могут сохраняться при передаче данных в Файлы Azure с помощью рекомендаций по сохранению списков управления доступом, атрибутов и меток времени файлов в Azure Data Box.
    • Иерархия файлов сохраняется при отправке в облако для больших двоичных объектов и Файлы Azure. Например, вы скопировали файл по пути <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 поддерживает большие общие папки (100 Тиб), если они включены до создания заказа на Data Box.
  • 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. Сегмент пути — это строка между последовательными символами-разделителями (например, косая черта"/"), которая соответствует имени виртуального каталога.
    		•