Хранилище BLOB-объектов Azure часто задаваемые вопросы

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

Обновленная политика вступит в силу в течение 24 часов. После применения политики время выполнения действий зависит от размера учетной записи хранения и выполняемых операций. Если обновление требуется отключить или удалить правило, а также включить параметр EnableAutoTierToHotFromCool, то автоматическое распределение по горячему уровню по-прежнему произойдет. Например, задайте правило, включающее свойство enableAutoTierToHotFromCool на основе времени последнего обращения. Если правило отключено или удалено, а большой двоичный объект в настоящее время находится на холодном или холодном уровне, а затем получает доступ, он вернется к горячему уровню, так как применяется к доступу за пределами управления жизненным циклом. Большой двоичный объект не будет переходить от горячего к холодному или холодному, если правило управления жизненным циклом отключено или удалено. Единственный способ предотвратить применение autoTierToHotFromCool — отключить отслеживание времени последнего обращения.

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

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

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

• Добавьте условие daysAfterLastTierChangeGreaterThan в действие tierToArchive политики. Это условие применяется только к времени последнего изменения. См. статью Использование политик управления жизненным циклом для архивации BLOB-объектов.

• Временно отключите правило, влияющее на этот большой двоичный объект, чтобы предотвратить его повторное архивирование. Повторно включите правило, когда большой двоичный объект можно будет безопасно переместить обратно на архивный уровень.

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

Поле соответствия префикса большого двоичного объекта политики — это полный или частичный путь к большому двоичному объекту, используемый для сопоставления больших двоичных объектов, к которым должны применяться действия политики. Путь должен начинаться с имени контейнера. Если соответствующий префикс не указан, политика будет применена ко всем BLOB-объектам в учетной записи хранения. Формат соответствующей префиксу строки: [container name]/[blob name].
Помните о следующем в отношении соответствующей префиксу строке:

• Соответствующая префиксу строка, например container1/, применяется ко всем большим двоичным объектам в контейнере с именем container1. Соответствующая префиксу строка container1 без символа косой черты в конце (/) применяется ко всем большим двоичным объектам во всех контейнерах, где имя контейнера начинается со строки container1. Префикс будет соответствовать контейнерам с именем container11, container1234, container1ab и т. д.
• Соответствующая префиксу строка container1/sub1/ применяется ко всем большим двоичным объектам в контейнере с именем container1, которые начинаются со строки sub1/. Например, этот префикс будет соответствовать большим двоичным объектам container1/sub1/test.txt и container1/sub1/sub2/test.txt.
• В имени большого двоичного объекта можно использовать символ звездочки *. Если этот символ применяется в префиксе, последний будет соответствовать большим двоичным объектам со звездочкой в имени. Звездочка не выполняет роль подстановочного знака.
• В имени большого двоичного объекта можно использовать вопросительный знак ?. Если знак вопроса применяется в префиксе, последний будет соответствовать большим двоичным объектам с вопросительным знаком в имени. Знак вопроса не выполняет роль подстановочного знака.
• В сопоставлении префиксов учитывается только положительное логическое сравнение (=). Отрицательное логическое сравнение (!=) игнорируется.
• Сопоставление префикса работает с учетом регистра.

К сожалению, невозможно отслеживать время выполнения политики, так как это фоновый процесс планирования. Однако платформа будет выполнять политику один раз в день.

Ежедневное правило инвентаризации предназначено для выполнения один раз в день. Кроме того, существует еженедельное правило инвентаризации, запланированное для каждого воскресенья.

Хотя мы стремимся обеспечить согласованный интерфейс, мы не можем гарантировать точное время выполнения для каждого запуска. Время выполнения правила инвентаризации может отличаться. Например, если сегодняшняя политика запланирована на 12:05 утра, она может ударить в 12:07 утра, 12:15 или любое другое время на следующий день.

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

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

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

Нет, существующие данные не затрагиваются. Только новые результаты инвентаризации BLOB-объектов имеют несколько файлов инвентаризации.

Нет, изменение происходит легко.

Необходимые действия зависят от того, как в настоящее время выполняется обработка результатов инвентаризации BLOB-объектов:

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

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

Это не рекомендуется, но это возможно. Обратитесь к каналам поддержки, чтобы попросить отключить эту функцию.

Обратитесь к текущей группе учетной записи и каналам поддержки.

Это изменение начнет постепенное развертывание с 1 сентября 2023 года.

№ Служба "Вычисления Azure" поддерживает метрики на дисках. Дополнительные сведения см. на странице Дисковые метрики для управляемых и неуправляемых дисков.

Некоторые диаграммы метрик Azure, такие как те, которые отображают данные о доступности и задержке, используют дефисированную линию, чтобы указать, что отсутствует значение (также известное как null-значение) между двумя известными точками данных с интервалом времени. Например, если в селекторе времени вы выбрали 1 minute степень детализации времени, но метрика была сообщена в 07:26, 07:27, 07:29 и 07:30, то тиреная линия подключается 07:27 и 07:29, так как между этими двумя точками данных есть минутный разрыв. Сплошная линия подключает все остальные точки данных. Пунктирная линия опускается до нуля, если для метрики используется агрегирование подсчета и суммы. Для средних, минимальных или максимальных агрегатов дефисируемая строка подключает две ближайшие известные точки данных. Также, если данные отсутствуют в крайней правой или левой части диаграммы, пунктирная линия расширяется в направлении отсутствующей точки данных.

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

Журналы аналитики содержат записи всех операций чтения, записи, списка и удаления с успешными и неудачными запросами. Журналы аналитики лучше подходят, но их порядок не гарантируется.

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

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

Да. Правила сетевой безопасности учетной записи хранения, включая брандмауэры на основе протоколов IP и виртуальной сети, поддерживаются для конечной точки статического веб-сайта и могут использоваться для защиты веб-сайта.

№ Статический веб-сайт поддерживает анонимный общедоступный доступ на чтение только для файлов в контейнере $web.

Можно настроить личный домен со статическим веб-сайтом с помощью сети доставки содержимого (Azure CDN). Azure CDN обеспечивает постоянно низкую задержку при доступе к веб-сайту из любого расположения.

Вы можете настроить настраиваемый SSL-сертификат со статическим веб-сайтом с помощью Azure CDN. Azure CDN обеспечивает постоянно низкую задержку при доступе к веб-сайту из любого расположения.

Заголовок узла для статического веб-сайта можно настроить с помощью Azure CDN — Verizon Premium. Мы хотели бы услышать ваши отзывы здесь.

Ошибка 404 может произойти, если вы ссылаетесь на имя файла, используя неправильный случай. Например, Index.html вместо index.html. В именах файлов и расширениях в URL-адресе статического веб-сайта учитывается регистр, даже если они обслуживаются по протоколу HTTP. Это также может произойти, если конечная точка Azure CDN еще не подготовлена. Дождитесь завершения распространения (до 90 минут) после подготовки новой сети Azure CDN.

На портале Azure откройте страницу конфигурации статического веб-сайта своей учетной записи и найдите имя и расширение, заданные в поле Имя документа индекса. Убедитесь, что это имя совпадает с именем файла, расположенного в контейнере $web учетной записи хранения. В именах файлов и расширениях в URL-адресе статического веб-сайта учитывается регистр, даже если они обслуживаются по протоколу HTTP.

Нет, для поиска по данным BLOB-объекта используйте ускорение запросов или поиск Azure.

Теги индекса больших двоичных объектов поддерживают только строковые данные, а запросы возвращают результаты с лексикографической сортировкой. В числах используйте необходимое число начальных нулей. Значения даты и времени храните в формате, совместимом с ISO 8601.

Нет, теги Resource Manager помогают систематизировать ресурсы плоскости управления, такие как подписки, группы ресурсов и учетные записи хранения. Теги индекса служат для управления BLOB-объектами и их обнаружения в плоскости данных.

Емкость хранилища тарифицируется как сумма среднесуточных объемов хранящихся данных (в ГБ) за один месяц. Например, если вы постоянно использовали 10 ГБ хранилища в течение первой половины месяца и ничего не использовали во второй половине месяца, вам будет выставлен счет за использование в среднем 5 ГБ.

Следующие шаги

Дополнительные сведения о Хранилище BLOB-объектов Azure см. по следующим ссылкам:

• Введение в хранилище Azure
• Что такое хранилище BLOB-объектов Azure