Рекомендации по архитектуре для хранилища BLOB-объектов Azure

Используйте анализ режима сбоя: свести к минимуму точки сбоя, учитывая внутренние зависимости, такие как доступность виртуальных сетей, Azure Key Vault или сеть доставки содержимого Azure или конечные точки Azure Front Door. Сбои могут возникать, если учетные данные, необходимые для доступа к хранилищу BLOB-объектов, отсутствуют в Key Vault, или если рабочие нагрузки используют конечную точку, основанную на сети доставки содержимого, которая была удалена. В таких случаях может потребоваться использование альтернативной точки подключения для соединения. Общие сведения об анализе режима сбоя см. в рекомендациях по выполнению анализа режима сбоя.

Определите целевые показатели надежности и восстановления: ознакомьтесь ссоглашениями об уровне обслуживания Azure (SLA). Выведите цель показателя уровня обслуживания (SLO) для учетной записи хранения. Например, на SLO может повлиять выбранная вами конфигурация избыточности. Рассмотрим влияние регионального сбоя, потенциал для потери данных и время, необходимое для восстановления доступа после сбоя. Кроме того, рассмотрите возможность доступности всех внутренних зависимостей, которые вы определили как часть анализа режима сбоя.

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

Всегда используйте пакет SDK при написании пользовательского кода для взаимодействия с хранилищем BLOB-объектов. Используйте клиентскую библиотеку хранилища BLOB-объектов Azure для управления контейнерами и BLOB-объектами в них. Пакет SDK имеет встроенную временную обработку ошибок для минимизации пользовательской логики повторных попыток.

Разработка приложений для использования дополнительных параметров чтения: разработка приложений для переключения на чтение данных из дополнительного региона, если основной регион становится недоступным по какой-либо причине. Для этого требуется геоизбыточное хранилище (RA-GRS) или геоизбыточное хранилище для чтения (RA-GZRS) для чтения. Обе конфигурации предоставляют доступ только для чтения к данным во вторичном регионе. Если первичные и вторичные операции чтения завершаются сбоем, обеспечьте плавное снижение функциональности в вашем приложении. Например, покажите стандартное изображение-заполнитель для операции, в которой не удалось извлечь изображение продукта.

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

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

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

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

Просмотрите базовые показатели безопасности для службы хранилища Azure. Чтобы приступить к работе, сначала просмотрите базовые показатели безопасности для хранилища.

Используйте сетевые элементы управления для ограничения входящего трафика и исходящего трафика: отключите весь общедоступный трафик в учетную запись хранения. Используйте сетевые элементы управления учетной записью для предоставления минимального уровня доступа, необходимого пользователям и приложениям. Дополнительные сведения см. в статье "Как приблизиться к сетевой безопасности для учетной записи хранения".

Уменьшите область атаки: предотвращение анонимного доступа, доступа к ключу учетной записи или доступа через небезопасные подключения (HTTP) могут уменьшить область атаки. Обнаружение службы хранилища Azure можно использовать с помощью Azure Copilot для выявления этих угроз безопасности во всех учетных записях. Требовать от клиентов отправлять и получать данные с помощью последней версии протокола TLS.

Авторизация доступа без использования паролей или ключей: идентификатор Microsoft Entra обеспечивает более высокую безопасность и удобство использования по сравнению с общими ключами и подписанными URL-адресами. Предоставьте субъектам безопасности только те разрешения, которые необходимы для выполнения задач.

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

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

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

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

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

Изучите цену каждого счетчика: обязательно используйте соответствующую страницу ценообразования и примените соответствующие параметры на этой странице. Дополнительные сведения см. в разделе "Поиск цены на единицу" для каждого счетчика. Рассмотрим количество операций, связанных с каждой ценой. Например, цена, связанная с операциями записи и чтения, применяется к 10 000 операциям. Чтобы определить цену отдельной операции, разделите указанную цену на 10 000.

Оцените стоимость емкости и операций. Вы можете моделировать затраты, связанные с хранилищем данных, входящего трафика и исходящего трафика с помощью калькулятора цен Azure. Используйте поля для сравнения затрат, связанных с различными регионами, типами учетных записей, типами пространств имен и конфигурациями избыточности. В некоторых сценариях можно использовать примеры вычислений и листов, доступные в документации Майкрософт. Например, можно оценить стоимость архивации данных или оценить стоимость использования команды AzCopy для передачи больших двоичных объектов.

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

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

Выберите наиболее экономичный уровень доступа по умолчанию: если уровень не указан при каждой отправке BLOB-объектов, они будут использовать уровень доступа, указанный по умолчанию. Изменение параметра уровня доступа по умолчанию аккаунта хранилища применяется ко всем Blob в аккаунте, в которых уровень доступа не был установлен явно. Эта стоимость может быть значительной, если вы собрали большое количество блобов. Дополнительные сведения о том, как изменение уровня влияет на каждый существующий большой двоичный объект, см. в разделе "Изменение уровня доступа большого двоичного объекта".

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

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

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

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

Создание охранников: создание бюджетов на основе подписок и групп ресурсов. Используйте политики управления для ограничения типов ресурсов, конфигураций и расположений. Кроме того, используйте RBAC для блокировки действий, которые могут привести к перерасходу.

Мониторинг затрат: обеспечение того, чтобы затраты оставались в бюджетах, сравнивали затраты с прогнозами и видели, где происходит перерасход. С помощью области анализа затрат на портале Azure можно отслеживать затраты. Вы также можете экспортировать данные о затратах в учетную запись хранения и анализировать эти данные с помощью Excel или Power BI.

Мониторинг использования: непрерывно отслеживайте шаблоны использования и обнаруживайте неиспользуемые или неиспользуемые учетные записи и контейнеры. Используйте аналитику хранилища для учетных записей удостоверений без или низкого использования. Используйте Azure Storage Discovery и Azure Copilot, чтобы найти финансовые неэффективности, такие как малоиспользуемое хранилище, размещенное на дорогих уровнях доступа. Вы также можете включить отчеты инвентаризации BLOB-объектов и использовать такие средства, как Azure Databricks или Azure Synapse Analytics и Power BI для анализа данных о затратах. Следите за неожиданным увеличением емкости, что может указывать на то, что вы собираете многочисленные файлы журнала, версии BLOB или обратимо удаленные объекты BLOB. Разработайте стратегию истечения срока действия или перехода объектов на более экономичные уровни доступа. План истечения срока действия объектов или перемещение объектов на более доступные уровни доступа.

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

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

Отслеживайте работоспособность учетной записи хранения. Создание панелей мониторинга аналитики хранилища для мониторинга доступности, производительности и метрик устойчивости. Настройте оповещения для выявления и устранения проблем в системе перед тем, как клиенты заметят их. Используйте параметры диагностики для маршрутизации журналов ресурсов в рабочую область журналов Azure Monitor. Затем журналы можно запрашивать для более глубокого изучения оповещений.

Включите отчеты инвентаризации BLOB-объектов: включите отчеты инвентаризации BLOB-объектов для проверки хранения, юридического удержания или состояния шифрования содержимого учетной записи хранения. Вы также можете использовать отчеты инвентаризации BLOB-объектов, чтобы понять общий размер данных, их возраст, распределение по уровням или другие атрибуты ваших данных. Используйте такие средства, как Azure Databricks или Azure Synapse Analytics и Power BI, чтобы лучше визуализировать данные инвентаризации и создавать отчеты для заинтересованных лиц.

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

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

Планирование масштабирования: Понимание целевых показателей масштабирования для учетных записей хранения.

Выберите оптимальный тип учетной записи хранения: если для рабочей нагрузки требуется высокая скорость транзакций, небольшие объекты и согласованно низкая задержка транзакций, а затем рассмотрите возможность использования учетных записей хранения BLOB-объектов класса Premium. Стандартная учетная запись общего назначения версии 2 наиболее подходит в большинстве случаев.

Уменьшите расстояние между клиентом и сервером: поместите данные в регионы, ближайшие к подключению клиентов (в идеале в одном регионе). Оптимизируйте для клиентов в удалённых регионах, используя репликацию объектов или сеть доставки содержимого. Конфигурации сети по умолчанию обеспечивают лучшую производительность. Измените параметры сети только для повышения безопасности. Как правило, параметры сети не снижают расстояние между поездками и не повышают производительность.

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

Оптимизируйте производительность клиентов данных: выберите средство передачи данных , наиболее подходящее для размера, частоты передачи данных и пропускной способности рабочих нагрузок. Некоторые средства, такие как AzCopy , оптимизированы для производительности и требуют небольшого вмешательства. Рассмотрим факторы, влияющие на задержку, и для точной настройки производительности просмотрите рекомендации по оптимизации производительности, опубликованные с каждым инструментом.

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

Сбор данных о производительности: мониторьте учетную запись хранения, чтобы выявить узкие места производительности, возникающие при регулировании. Дополнительные сведения см. в разделе "Мониторинг службы хранилища" с помощью Monitor Storage Insights. Используйте метрики и журналы. Метрики предоставляют такие числа, как ошибки ограничения скорости. Журналы описывают действия. Если отображаются метрики регулирования, можно использовать журналы для идентификации клиентов, получающих ошибки регулирования. Дополнительные сведения см. в разделе "Аудит операций плоскости данных".