Перспектива azure Well-Architected Framework на Хранилище BLOB-объектов Azure
Хранилище BLOB-объектов Azure — это решение хранилища объектов Майкрософт для облака. Хранилище BLOB-объектов используется для хранения больших объемов неструктурированных данных. Неструктурированные данные — это данные, которые не соответствуют конкретной модели или определению данных, например текстовые или двоичные данные.
В этой статье предполагается, что в качестве архитектора вы ознакомились с параметрами хранилища и выбрали служба хранилища BLOB-объектов в качестве службы хранилища, в которой выполняются рабочие нагрузки. В этом руководстве приведены рекомендации по архитектуре, сопоставленные с принципами основных принципов платформы Azure Well-Architected Framework.
Внимание
Как использовать это руководство
Каждый раздел содержит список проверка проектирования, который представляет архитектурные области, связанные с стратегиями проектирования.
Также включены рекомендации по возможностям технологий, которые помогут реализовать эти стратегии. Рекомендации не представляют исчерпывающий список всех конфигураций, доступных для служба хранилища BLOB-объектов и его зависимостей. Вместо этого они перечисляют ключевые рекомендации, сопоставленные с перспективами проектирования. Используйте рекомендации для создания подтверждения концепции или оптимизации существующих сред.
Надежность
Цель компонента "Надежность" — обеспечить непрерывную функциональность путем создания достаточной устойчивости и возможности быстрого восстановления после сбоев.
Принципы проектирования надежности обеспечивают высокоуровневую стратегию проектирования, применяемую для отдельных компонентов, системных потоков и системы в целом.
Контрольный список проектирования
Запустите стратегию проектирования на основе списка проверка проверки дизайна для надежности.
Используйте анализ режима сбоя: свести к минимуму точки сбоя, учитывая внутренние зависимости, такие как доступность виртуальных сетей, Azure Key Vault или Azure сеть доставки содержимого или конечных точек Azure Front Door. Сбои могут возникать, если учетные данные, необходимые для доступа к BLOB-объектам, служба хранилища отсутствуют из Key Vault, или если рабочие нагрузки используют конечную точку на основе удаленной сети доставки содержимого. В таких случаях рабочие нагрузки могут потребоваться использовать альтернативную конечную точку для подключения. Общие сведения об анализе режима сбоя см. в Рекомендации для выполнения анализа режима сбоя.
Определите целевые показатели надежности и восстановления: ознакомьтесь с соглашениями об уровне обслуживания Azure (SLA). Наследует цель уровня обслуживания (SLO) для учетной записи хранения. Например, SLO может повлиять на конфигурацию избыточности, которую вы выбрали. Рассмотрим влияние регионального сбоя, потенциал для потери данных и время, необходимое для восстановления доступа после сбоя. Кроме того, рассмотрите возможность доступности всех внутренних зависимостей, которые вы определили как часть анализа режима сбоя.
Настройка избыточности данных. Для обеспечения максимальной устойчивости выберите конфигурацию, которая копирует данные в зонах доступности или глобальных регионах. Для максимальной доступности выберите конфигурацию, которая позволяет клиентам считывать данные из дополнительного региона во время сбоя основного региона.
Разработка приложений: разработка приложений для простого перехода на чтение данных из дополнительного региона, если основной регион становится недоступным по какой-либо причине. Это относится только к геоизбыточным хранилищам (GRS) и геоизбыточным хранилищам (GZRS). Проектирование приложений для обработки сбоев сокращает время простоя для конечных пользователей.
Изучите функции, которые помогут вам удовлетворить целевые показатели восстановления: сделайте большие двоичные объекты восстанавливаемыми, чтобы их можно было восстановить, если они повреждены, редактированы или удалены по ошибке.
Создайте план восстановления: рассмотрите возможности защиты данных, операции резервного копирования и восстановления или процедуры отработки отказа. Подготовьтесь к потенциальным потерям данных и несоответствиям данных и времени и затратам на отработку отказа. Дополнительные сведения см. в разделе Рекомендации разработки стратегии аварийного восстановления.
Отслеживайте потенциальные проблемы доступности: подпишитесь на панель мониторинга работоспособности служб Azure, чтобы отслеживать потенциальные проблемы с доступностью. Используйте метрики хранилища в Azure Monitor и журналах диагностики для изучения оповещений.
Рекомендации
Рекомендация | Преимущества |
---|---|
Настройте учетную запись для избыточности. Для обеспечения максимальной доступности и устойчивости настройте учетную запись с помощью хранилища, избыточного между зонами (ZRS) или GZRS. |
Избыточность защищает данные от непредвиденных сбоев. Параметры конфигурации ZRS и GZRS реплика te в разных зонах доступности и позволяют приложениям продолжать чтение данных во время сбоя. Дополнительные сведения см. в разделе "Устойчивость и доступность по сценариям сбоям" и параметрам устойчивости и доступности. |
Прежде чем инициировать отработку отказа или восстановление размещения, оцените потенциал потери данных, проверка значение свойства последнего времени синхронизации. Эта рекомендация применяется только к конфигурациям GRS и GZRS. | Это свойство помогает оценить, сколько данных может быть потеряно, инициируя отработку отказа учетной записи. Все данные и метаданные, записанные до последнего времени синхронизации, доступны в дополнительном регионе, но данные и метаданные, записанные после последнего времени синхронизации, могут быть потеряны, так как они не записываются в дополнительный регион. |
В рамках стратегии резервного копирования и восстановления включите обратимое удаление контейнера, обратимое удаление BLOB-объектов, управление версиями и параметры восстановления на определенный момент времени. | Параметр обратимого удаления позволяет учетной записи хранения восстановить удаленные контейнеры и большие двоичные объекты. Параметр управления версиями автоматически отслеживает изменения, внесенные в большие двоичные объекты. Этот параметр позволяет восстановить большой двоичный объект до предыдущего состояния. Параметр восстановления на определенный момент времени защищает от случайного удаления или повреждения большого двоичного объекта и позволяет восстановить данные блочных BLOB-объектов в более раннее состояние. Дополнительные сведения см. в статье Общие сведения о защите данных. |
Безопасность
Цель компонента "Безопасность" заключается в обеспечении конфиденциальности, целостности и доступности для рабочей нагрузки .
Принципы проектирования безопасности предоставляют высокоуровневую стратегию проектирования для достижения этих целей, применяя подходы к техническому проектированию конфигурации большого двоичного объекта служба хранилища.
Контрольный список проектирования
Запустите стратегию проектирования на основе списка проверка проверки дизайна для безопасности. Выявление уязвимостей и элементов управления для улучшения состояния безопасности. Расширьте стратегию, чтобы включить дополнительные подходы по мере необходимости.
Просмотрите базовые показатели безопасности для служба хранилища Azure. Чтобы приступить к работе, сначала просмотрите базовые показатели безопасности для служба хранилища.
Используйте сетевые элементы управления для ограничения входящего трафика и исходящего трафика: отключите весь общедоступный трафик в учетную запись хранения. Используйте сетевые элементы управления учетной записью для предоставления минимального уровня доступа, необходимого пользователям и приложениям. Дополнительные сведения см. в статье "Как приблизиться к сетевой безопасности для учетной записи хранения".
Уменьшите область атаки: предотвращение анонимного доступа, доступа к ключу учетной записи или доступа через небезопасные подключения (HTTP) могут уменьшить область атаки. Требовать от клиентов отправлять и получать данные с помощью последней версии протокола TLS.
Авторизация доступа без использования паролей или ключей: идентификатор Microsoft Entra обеспечивает более высокую безопасность и удобство использования по сравнению с общими ключами и подписанными URL-адресами. Предоставьте субъектам безопасности только те разрешения, которые необходимы для выполнения задач.
Защита конфиденциальной информации: защита конфиденциальных данных, таких как ключи учетной записи и маркеры подписанного URL-адреса. Хотя эти формы авторизации обычно не рекомендуется, следует поворачивать, истекать срок действия и безопасно хранить их.
Включите необходимый параметр безопасной передачи. Включение этого параметра для всех учетных записей хранения гарантирует, что все запросы, сделанные в учетной записи хранения, должны выполняться через безопасные подключения. Все запросы, выполненные по протоколу HTTP, завершаются сбоем.
Защита критически важных объектов: применение политик неизменяемости для защиты критически важных объектов. Политики защищают большие двоичные объекты, хранящиеся для юридических, соответствия требованиям или других бизнес-целей, от изменения или удаления. Настройка удержаний для заданных периодов времени или до тех пор, пока ограничения не будут отменены администратором.
Обнаружение угроз: включите Microsoft Defender для служба хранилища обнаружения угроз. Оповещения системы безопасности активируются при возникновении аномальных действий. Оповещения уведомляют администраторов подписок по электронной почте с подробными сведениями о подозрительных действиях и рекомендациях по изучению и устранению угроз.
Рекомендации
Рекомендация | Преимущества |
---|---|
Отключите анонимный доступ на чтение к контейнерам и BLOB-объектам. | Если анонимный доступ разрешен для учетной записи хранения, пользователь с соответствующими разрешениями может изменить параметр анонимного доступа контейнера, чтобы обеспечить анонимный доступ к данным в этом контейнере. |
Примените блокировку Azure Resource Manager к учетной записи хранения. | Блокировка учетной записи предотвращает удаление и причинение потери данных. |
Отключите трафик к общедоступным конечным точкам учетной записи хранения. Создайте частные конечные точки для клиентов, работающих в Azure. Включите общедоступную конечную точку, только если клиентам и службам, внешним в Azure, требуется прямой доступ к учетной записи хранения. Включите правила брандмауэра, ограничивающие доступ к определенным виртуальным сетям. | Начните с нуля доступа, а затем постепенно авторизуйте самые низкие уровни доступа, необходимые для клиентов и служб, чтобы свести к минимуму риск создания ненужных открытий для злоумышленников. |
Авторизация доступа с помощью управления доступом на основе ролей Azure (RBAC). | При использовании RBAC пароли или ключи не могут быть скомпрометированы. Субъект безопасности (пользователь, группа, управляемое удостоверение или субъект-служба) проходит проверку подлинности идентификатором Microsoft Entra для возврата маркера OAuth 2.0. Маркер используется для авторизации запроса к службе служба хранилища BLOB-объектов. |
Запретить авторизацию общего ключа. Это отключает не только доступ к ключу учетной записи, но и маркеры подписанных учетных записей и учетных записей, так как они основаны на ключах учетной записи. | Разрешены только защищенные запросы, авторизованные с идентификатором Microsoft Entra. |
Рекомендуется не использовать ключ учетной записи. Если вы должны использовать ключи учетных записей, сохраните их в Key Vault и убедитесь, что их периодически повторно создайте. | Key Vault позволяет извлекать ключи во время выполнения, а не сохранять их с помощью приложения. Key Vault также упрощает смену ключей без прерывания работы с приложениями. Смена ключей учетной записи периодически снижает риск предоставления данных вредоносным атакам. |
Рекомендуется не использовать маркеры подписи общего доступа. Оцените, требуются ли маркеры подписанного URL-адреса для защиты доступа к ресурсам blob-объектов служба хранилища. Если необходимо создать ее, ознакомьтесь со списком рекомендаций по подписанным URL-адресам перед созданием и распространением. | Рекомендации помогут предотвратить утечку маркера подписи общего доступа и быстро восстановиться при возникновении утечки. |
Настройте учетную запись хранения, чтобы клиенты могли отправлять и получать данные с помощью минимальной версии TLS 1.2. | TLS 1.2 является более безопасным и быстрым, чем TLS 1.0 и 1.1, что не поддерживает современные алгоритмы шифрования и наборы шифров. |
Рекомендуется использовать собственный ключ шифрования для защиты данных в учетной записи хранения. Дополнительные сведения см. в статье Ключи, управляемые клиентом, для шифрования службы хранилища Azure. | Управляемые клиентом ключи обеспечивают большую гибкость и контроль. Например, вы можете хранить ключи шифрования в Key Vault и автоматически повернуть их. |
Оптимизация затрат
Оптимизация затрат фокусируется на обнаружении шаблонов расходов, приоритете инвестиций в критически важные области и оптимизации в других целях для удовлетворения бюджетов и бизнес-требований организации.
Принципы проектирования оптимизации затрат предоставляют высокоуровневую стратегию проектирования для достижения этих целей и достижения компромиссов в соответствии с техническим проектированием, связанными с служба хранилища BLOB-объектов и его средой.
Контрольный список проектирования
Запустите стратегию проектирования на основе проверка списка проверка для оптимизации затрат для инвестиций. Настройте структуру, чтобы рабочая нагрузка соответствовала бюджету, выделенному для рабочей нагрузки. Проект должен использовать правильные возможности Azure, отслеживать инвестиции и находить возможности для оптимизации с течением времени.
Определите счетчики, используемые для вычисления счета: счетчики используются для отслеживания объема данных, хранящихся в учетной записи (емкости данных), и количества и типа операций, выполняемых для записи и чтения данных. Существуют также метры, связанные с использованием дополнительных функций, таких как теги индекса BLOB-объектов, инвентаризация BLOB-объектов, поддержка канала изменений, поддержка шифрования область и поддержка протокола SFTP. Дополнительные сведения см. в статье о том, как взиматься плата за служба хранилища BLOB-объектов.
Изучите цену каждого счетчика: обязательно используйте соответствующую страницу ценообразования и примените соответствующие параметры на этой странице. Дополнительные сведения см. в разделе "Поиск цены на единицу" для каждого счетчика. Рассмотрим количество операций, связанных с каждой ценой. Например, цена, связанная с операциями записи и чтения, применяется к 10 000 операциям. Чтобы определить цену отдельной операции, разделите указанную цену на 10 000.
Оцените стоимость емкости и операций. Вы можете моделировать затраты, связанные с хранилищем данных, входящего трафика и исходящего трафика с помощью калькулятора цен Azure. Используйте поля для сравнения затрат, связанных с различными регионами, типами учетных записей, типами пространств имен и конфигурациями избыточности. В некоторых сценариях можно использовать примеры вычислений и листов, доступные в документации Майкрософт. Например, можно оценить стоимость архивации данных или оценить стоимость использования команды AzCopy для передачи больших двоичных объектов.
Выберите модель выставления счетов для емкости: оцените, является ли использование модели на основе обязательств более экономичной, чем использование модели на основе потребления. Если вы не уверены, сколько ресурсов требуется, можно начать с модели на основе потребления, отслеживать метрики емкости, а затем оценивать позже.
Выберите тип учетной записи, уровень избыточности и уровень доступа по умолчанию: при создании учетной записи хранения необходимо выбрать значение для каждого из этих параметров. Все значения влияют на расходы на транзакции и расходы на емкость. Все эти параметры, кроме типа учетной записи, можно изменить после создания учетной записи.
Выберите наиболее экономичный уровень доступа по умолчанию: если уровень не указан при каждой отправке BLOB-объектов, большие двоичные объекты выводят уровень доступа из параметра уровня доступа по умолчанию. Изменение параметра уровня доступа по умолчанию учетной записи хранения применяется ко всем большим двоичным объектам в учетной записи, для которой уровень доступа не был задан явным образом. Эта стоимость может быть значительной, если вы собрали большое количество больших двоичных объектов. Дополнительные сведения о том, как изменение уровня влияет на каждый существующий большой двоичный объект, см. в разделе "Изменение уровня доступа большого двоичного объекта".
Передайте данные непосредственно на самый экономичный уровень доступа: например, если параметр уровня доступа по умолчанию учетной записи является горячим, но вы отправляете файлы для архивации, укажите холодный уровень в качестве архива или холодного уровня в рамках операции отправки. После отправки больших двоичных объектов используйте политики управления жизненным циклом для перемещения больших двоичных объектов на наиболее экономичные уровни на основе метрик использования, таких как время последнего доступа. Выбор наиболее оптимального уровня на переднем крае может снизить затраты. Если изменить уровень блочного большого двоичного объекта, который вы уже отправили, вы платите стоимость записи на начальный уровень при первой отправке большого двоичного объекта, а затем платите стоимость записи на нужный уровень.
Укажите план управления жизненным циклом данных: оптимизируйте затраты на транзакцию и емкость, используя преимущества уровней доступа и управления жизненным циклом. Данные, используемые реже, должны размещаться на более холодных уровнях доступа, а данные, к которым часто обращаются, должны размещаться на более теплых уровнях доступа.
Определите необходимые функции: некоторые функции, такие как управление версиями и обратимое удаление BLOB-объектов, влечет за собой дополнительные затраты на транзакцию и емкость, а также другие расходы. Обязательно просмотрите разделы о ценах и выставлении счетов в статьях, описывающих эти возможности при выборе возможностей для добавления в учетную запись.
Например, если включить функцию инвентаризации BLOB-объектов, выставляется счет за количество отсканированных объектов. При использовании тегов индекса BLOB-объектов плата взимается за количество тегов индекса. Если вы включите поддержку SFTP, плата взимается почасовой оплаты, даже если нет передачи SFTP. Если вы решите использовать функцию, убедитесь, что эта функция отключена, так как некоторые функции автоматически включены при создании учетной записи.
Создание охранников: создание бюджетов на основе подписок и групп ресурсов. Используйте политики управления для ограничения типов ресурсов, конфигураций и расположений. Кроме того, используйте RBAC для блокировки действий, которые могут привести к перерасходу.
Мониторинг затрат: обеспечение того, чтобы затраты оставались в бюджетах, сравнивали затраты с прогнозами и видели, где происходит перерасход. Вы можете использовать область анализа затрат в портал Azure для мониторинга затрат. Вы также можете экспортировать данные о затратах в учетную запись хранения и анализировать эти данные с помощью Excel или Power BI.
Мониторинг использования: непрерывно отслеживайте шаблоны использования и обнаруживайте неиспользуемые или неиспользуемые учетные записи и контейнеры. Используйте служба хранилища аналитические сведения для учетных записей удостоверений без использования. Включите отчеты инвентаризации BLOB-объектов и используйте такие средства, как Azure Databricks или Azure Synapse Analytics и Power BI для анализа данных о затратах. Следите за непредвиденным увеличением емкости, что может указывать на то, что вы собираете многочисленные файлы журнала, версии БОЛЬШИХ двоичных объектов или обратимо удаленные большие двоичные объекты. Разработайте стратегию истечения срока действия или перехода объектов на более экономичные уровни доступа. План истечения срока действия объектов или перемещение объектов на более доступные уровни доступа.
Рекомендации
Рекомендация | Преимущества |
---|---|
Перед перемещением небольших файлов в более крупные файлы перед их перемещением на более холодные уровни. Вы можете использовать такие форматы файлов, как TAR или ZIP. | Более холодные уровни имеют более высокие затраты на передачу данных. Имея меньше больших файлов, можно уменьшить количество операций, необходимых для передачи данных. |
При повторном удалении больших двоичных объектов из архивного хранилища используйте повторное восстановление с приоритетом уровня "стандартный приоритет". Используйте высокоприоритетное восстановление только для чрезвычайных ситуаций восстановления данных. Дополнительные сведения см. в разделе "Повторное восстановление архивного большого двоичного объекта на онлайн-уровне" | Высокоприоритетное восстановление с архивного уровня может привести к более высоким, чем обычные счета. |
Уменьшите затраты на использование журналов ресурсов, выбрав соответствующее расположение хранилища журналов и управляя периодами хранения журналов. Если вы планируете запрашивать журналы только иногда (например, запрашивать журналы для аудита соответствия требованиям), рассмотрите возможность отправки журналов ресурсов в учетную запись хранения вместо отправки их в рабочую область журналов Azure Monitor. Для анализа журналов можно использовать бессерверное решение запросов, например Azure Synapse Analytics. Дополнительные сведения см. в разделе "Оптимизация затрат для редких запросов". Используйте политики управления жизненным циклом для удаления или архивации журналов. | Хранение журналов ресурсов в учетной записи хранения для последующего анализа может быть более дешевым вариантом. Использование политик управления жизненным циклом для управления хранением журналов в учетной записи хранения предотвращает создание большого количества файлов журналов с течением времени, что может привести к ненужным затратам на емкость. |
Если включить управление версиями, используйте политику управления жизненным циклом для автоматического удаления старых версий BLOB-объектов. | Каждая операция записи в большой двоичный объект создает новую версию. Это увеличивает затраты на емкость. Затраты можно сохранить в проверка, удалив версии, которые больше не нужны. |
Если включить управление версиями, поместите большие двоичные объекты, которые часто перезаписываются в учетную запись, которая не включает управление версиями. | Каждый раз, когда большой двоичный объект перезаписывается, добавляется новая версия, которая приводит к увеличению расходов на емкость хранилища. Чтобы сократить расходы на емкость, часто перезаписываете данные в отдельной учетной записи хранения с отключенным изменением версий. |
Если включить обратимое удаление, поместите большие двоичные объекты, которые часто перезаписываются в учетную запись, которая не включает обратимое удаление. Задайте сроки хранения. Попробуйте начать с короткого периода хранения, чтобы лучше понять, как функция влияет на ваш счет. Минимальный рекомендуемый срок хранения составляет семь дней. | Каждый раз, когда большой двоичный объект перезаписывается, создается новый моментальный снимок. Причиной увеличения затрат на емкость может быть трудно получить доступ, так как создание этих моментальных снимков не отображается в журналах. Чтобы сократить расходы на емкость, часто перезаписывает данные в отдельной учетной записи хранения с отключенным обратимым удалением. Период хранения сохраняет обратимо удаленные большие двоичные объекты от загрузки и добавления к стоимости емкости. |
Включите поддержку SFTP, только если она используется для передачи данных. | Включение конечной точки SFTP взимает почасовую стоимость. Отключив поддержку SFTP, а затем включите ее при необходимости, вы можете избежать пассивных расходов от начисления в вашей учетной записи. |
Отключите любые область шифрования, которые не нужны, чтобы избежать ненужных расходов. | Плата за шифрование область взимается за месяц. |
Эффективность работы
Операционное превосходство в основном посвящено процедурам разработки, наблюдаемости и управлению выпусками.
Принципы проектирования операционного превосходства обеспечивают высокоуровневую стратегию разработки для достижения этих целей в отношении операционных требований рабочей нагрузки.
Контрольный список проектирования
Запустите стратегию проектирования на основе списка проверка обзора проектирования для операционного превосходства для определения процессов для наблюдения, тестирования и развертывания, связанных с конфигурацией служба хранилища BLOB-объектов.
Создание планов обслуживания и аварийного восстановления. Рассмотрим функции защиты данных, операции резервного копирования и восстановления и процедуры отработки отказа. Подготовьтесь к потенциальным потерям данных и несоответствиям данных и времени и затратам на отработку отказа.
Отслеживайте работоспособность учетной записи хранения: создайте панели мониторинга аналитики служба хранилища для мониторинга доступности, производительности и устойчивости. Настройте оповещения для выявления и устранения проблем в системе перед тем, как клиенты заметят их. Используйте параметры диагностики для маршрутизации журналов ресурсов в рабочую область журналов Azure Monitor. Затем журналы можно запрашивать для более глубокого изучения оповещений.
Включите отчеты инвентаризации BLOB-объектов: включите отчеты инвентаризации BLOB-объектов для проверки хранения, юридического удержания или состояния шифрования содержимого учетной записи хранения. Вы также можете использовать отчеты инвентаризации BLOB-объектов, чтобы понять общий размер данных, возраст, распределение уровней или другие атрибуты данных. Используйте такие средства, как Azure Databricks или Azure Synapse Analytics и Power BI, чтобы лучше визуализировать данные инвентаризации и создавать отчеты для заинтересованных лиц.
Настройте политики, которые удаляют большие двоичные объекты или перемещают их на экономичные уровни доступа: создайте политику управления жизненным циклом с начальным набором условий. Политика выполняется автоматически, удаляет или задает уровень доступа больших двоичных объектов в зависимости от заданных условий. Периодически анализируйте использование контейнера с помощью метрик монитора и отчетов инвентаризации BLOB-объектов, чтобы можно было уточнить условия для оптимизации экономичности.
Рекомендации
Рекомендация | Преимущества |
---|---|
Используйте инфраструктуру в качестве кода (IaC), чтобы определить сведения о учетных записях хранения в шаблонах Azure Resource Manager (шаблоны ARM), Bicep или Terraform. | Вы можете использовать существующие процессы DevOps для развертывания новых учетных записей хранения и использовать Политика Azure для принудительного применения конфигурации. |
Используйте служба хранилища аналитические сведения для отслеживания работоспособности и производительности учетных записей хранения. служба хранилища аналитические сведения предоставляют единое представление о сбоях, производительности, доступности и емкости для всех учетных записей хранения. | Вы можете отслеживать работоспособность и операцию каждой учетной записи. Легко создавать панели мониторинга и отчеты, которые заинтересованные лица могут использовать для отслеживания работоспособности учетных записей хранения. |
Уровень производительности
Эффективность производительности заключается в поддержании взаимодействия с пользователем даже при увеличении нагрузки путем управления емкостью. Стратегия включает масштабирование ресурсов, определение потенциальных узких мест и оптимизацию потенциальных узких мест и оптимизацию для пиковой производительности.
Принципы проектирования эффективности производительности предоставляют высокоуровневую стратегию проектирования для достижения этих целей емкости в отношении ожидаемого использования.
Контрольный список проектирования
Запустите стратегию проектирования на основе проверка списка проверка для повышения эффективности. Определите базовые показатели, основанные на ключевых показателях производительности для конфигурации служба хранилища BLOB-объектов.
Планирование масштабирования. Общие сведения о целевых объектах масштабирования для учетных записей хранения.
Выберите оптимальный тип учетной записи хранения: если для рабочей нагрузки требуется высокая скорость транзакций, небольшие объекты и согласованно низкая задержка транзакций, а затем рассмотрите возможность использования учетных записей хранения BLOB-объектов класса Premium. Стандартная учетная запись общего назначения версии 2 наиболее подходит в большинстве случаев.
Уменьшите расстояние между клиентом и сервером: поместите данные в регионы, ближайшие к подключению клиентов (в идеале в одном регионе). Оптимизируйте для клиентов в регионах далеко с помощью реплика объектов или сети доставки содержимого. Конфигурации сети по умолчанию обеспечивают лучшую производительность. Измените параметры сети только для повышения безопасности. Как правило, параметры сети не снижают расстояние между поездками и не повышают производительность.
Выберите эффективную схему именования: уменьшите задержку перечисления, списка, запроса и чтения с помощью префиксов хэш-тегов, ближайших к началу ключа секции BLOB-объектов (учетная запись, контейнер, виртуальный каталог или имя БОЛЬШОго двоичного объекта). Эта схема использует в основном учетные записи с неструктурированным пространством имен.
Оптимизируйте производительность клиентов данных: выберите средство передачи данных, наиболее подходящее для размера, частоты передачи данных и пропускной способности рабочих нагрузок. Некоторые средства, такие как AzCopy , оптимизированы для производительности и требуют небольшого вмешательства. Рассмотрим факторы, влияющие на задержку, и точной настройке производительности, просмотрите рекомендации по оптимизации производительности, опубликованные с каждым средством.
Оптимизируйте производительность пользовательского кода. Вместо создания собственных оболочк для операций REST с большим двоичным объектом рекомендуется использовать пакеты SDK служба хранилища. Пакеты SDK Azure оптимизированы для повышения производительности и предоставляют механизмы для точной настройки производительности. Перед созданием приложения просмотрите список проверка производительности и масштабируемости для служба хранилища BLOB-объектов. Рекомендуется использовать ускорение запросов, чтобы отфильтровать нежелательные данные во время запроса хранилища и обеспечить клиентам возможность без необходимости передавать данные по сети.
Сбор данных о производительности: отслеживайте учетную запись хранения, чтобы определить узкие места производительности, возникающие при регулировании. Дополнительные сведения см. в статье "Мониторинг службы хранилища" с помощью мониторинга служба хранилища аналитических сведений. Используйте метрики и журналы. Метрики предоставляют такие числа, как ошибки регулирования. Журналы описывают действия. Если отображаются метрики регулирования, можно использовать журналы для идентификации клиентов, получающих ошибки регулирования. Дополнительные сведения см. в разделе "Аудит операций плоскости данных".
Рекомендации
Рекомендация | Преимущества |
---|---|
Подготовка учетных записей хранения в том же регионе, где размещаются зависимые ресурсы. Для приложений, не размещенных в Azure, таких как мобильные приложения или локальные корпоративные службы, найдите учетную запись хранения в регионе ближе к этим клиентам. Дополнительные сведения см. в статье Географические области Azure. Если клиенты из другого региона не требуют одинаковых данных, создайте отдельную учетную запись в каждом регионе. Если клиентам из другого региона требуются только некоторые данные, рекомендуется использовать политику реплика tion объекта для асинхронного копирования соответствующих объектов в учетную запись хранения в другом регионе. |
Уменьшение физического расстояния между учетной записью хранения и виртуальными машинами, службами и локальными клиентами может повысить производительность и уменьшить задержку в сети. Сокращение физического расстояния также снижает затраты на приложения, размещенные в Azure, так как использование пропускной способности в одном регионе является бесплатным. |
Для широкого использования веб-клиентами (потоковое видео, аудио или статического веб-сайта) рекомендуется использовать сеть доставки содержимого через Azure Front Door. | Содержимое доставляется клиентам быстрее, так как оно использует глобальную сеть Microsoft edge сотнями глобальных и локальных точек присутствия по всему миру. |
Добавьте хэш-последовательность символов (например, три цифры) как можно раньше в ключ секции большого двоичного объекта. Ключ секции — это имя учетной записи, имя контейнера, имя виртуального каталога и имя большого двоичного объекта. Если вы планируете использовать метки времени в именах, попробуйте добавить значение секунд в начало этой метки. Дополнительные сведения см. в разделе "Секционирование". | При использовании хэш-кода или секунд ближайшего начала ключа секции сокращается время, необходимое для перечисления запросов и чтения БОЛЬШИХ двоичных объектов. |
При отправке больших двоичных объектов или блоков используйте большой двоичный объект или размер блока, превышающий 256 КИБ. | Размеры больших двоичных объектов или блоков выше 256 КИБ используют преимущества повышения производительности платформы, специально предназначенные для больших больших двоичных объектов и размеров блоков. |
Политики Azure
Azure предоставляет широкий набор встроенных политик, связанных с служба хранилища BLOB-объектов и его зависимостями. Некоторые из предыдущих рекомендаций можно проверять с помощью политик Azure. Например, можно проверка, если:
- Анонимный общедоступный доступ на чтение к контейнерам и BLOB-объектам не включен.
- Параметры диагностики для служба хранилища BLOB-объектов задаются для потоковой передачи журналов ресурсов в рабочую область журналов Azure Monitor.
- Принимаются только запросы из безопасных подключений (HTTPS).
- Политика истечения срока действия подписанного URL-адреса включена.
- Функция реплика объекта кросстенантного клиента отключена.
- Авторизация общего ключа отключена.
- Правила брандмауэра сети применяются к учетной записи.
Для комплексного управления ознакомьтесь со встроенными определениями Политика Azure для служба хранилища и других политик, которые могут повлиять на безопасность вычислительного слоя.
Рекомендации Помощника по Azure
Помощник по Azure — это персонализированный облачный консультант, который помогает следовать рекомендациям по оптимизации развернутых служб Azure. Ниже приведены некоторые рекомендации, которые помогут повысить надежность, безопасность, эффективность затрат, производительность и эффективность работы большого двоичного объекта служба хранилища.
Следующий шаг
Дополнительные сведения о служба хранилища BLOB-объектов см. в документации по служба хранилища BLOB-объектов.