Определение вариантов оптимизации затрат с помощью Хранилища BLOB-объектов Azure
Общее представление о модели ценообразования хранилища BLOB-объектов Azure поможет определить возможности оптимизации затрат. Принятие некоторых решений может быть более целесообразным на этапе разработки, например, выбор целевого региона Azure или области репликации учетной записи хранения. Другие решения зависят от шаблонов использования, изменяющихся со временем. Однако важно отметить, что оптимизация затрат является постоянной деятельностью, которую следует внимательно отслеживать и постоянно оценивать. В этом уроке вы узнаете о различных вариантах оптимизации затрат. Кроме того, вы определите, какой из этих вариантов может помочь в снижении расходов, связанных с использованием хранилища, в вашей среде.
Определение вариантов оптимизации затрат на использование хранилища BLOB-объектов Azure
Основные варианты оптимизации затрат, которые вы рассмотрите в этом уроке, включают:
Организацию данных по уровням доступа.
Запись непосредственно на холодные и архивные уровни
Автоматическое перемещение данных между уровнями доступа.
Резервирование емкости хранилища
Организация данных по уровням доступа
Цель уровней доступа — разрешить компаниям выбирать модель ценообразования и скорость получения данных, которая отражает их шаблоны использования BLOB-объектов. Выбор уровня доступа должен зависеть от частоты доступа, с которой будут получать доступ отдельные BLOB-объекты в учетной записи хранения. Например, чтобы оптимизировать использование хранилища и свести к минимуму затраты, часто используемые большие двоичные объекты должны находиться в учетной записи хранения BLOB-объектов, настроенной на уровне горячего доступа. И наоборот, большие двоичные объекты, которые планируется использовать только иногда, должны находиться в учетной записи хранения BLOB-объектов, настроенной с холодным уровнем доступа. Большие двоичные объекты, к которым вы будете обращаться или изменять редко, должны находиться в учетной записи хранения BLOB-объектов, настроенной с холодным уровнем доступа. Наконец, большие двоичные объекты, которые хранятся в архивных целях, без каких-либо краткосрочных планов доступа к их содержимому, должны быть назначены уровню архива.
Эта рекомендация основана на модели ценообразования для конкретного уровня доступа, которая определяет два типа расходов:
Плата за обслуживание неактивных данных (за гигабайт)
Расходы, связанные с доступом к данным для выполнения операций чтения, обновления и удаления.
Назначение уровня горячего доступа большому двоичному объекту свести к минимуму второй из этих расходов, но увеличить первое, в то время как выбор уровня доступа к архиву будет иметь противоположный эффект. Таким образом, если вы планируете часто получать доступ к данным, горячий уровень представляет собой наиболее эффективный выбор. Если вы планируете получать доступ к данным реже, холодный уровень или архивный уровень имеет больше смысла сократить затраты на хранение данных.
Например, ваша команда администрирования базы данных должна использовать архивное хранилище для долгосрочных резервных копий локальных хранилищ данных. В результате нормативных требований эти резервные копии необходимо сохранить в течение нескольких лет, даже если их редко требуется восстановить. И наоборот, горячий уровень будет более подходящим для файлов журналов, используемых для устранения проблем с клиентами, а также для краткосрочной аналитики и отчетности.
Запись непосредственно в холодные и архивные уровни
Если у вас есть четкое указание на то, что новый большой двоичный объект не будет доступ к нему в ближайшее время, рекомендуется назначить его непосредственно на холодный или архивный уровень. Это позволит избежать расходов, связанных с перемещением между уровнями.
Автоматическое перемещение данных между уровнями доступа
Уровень доступа, назначенный в начале, может не отражать тенденции долгосрочного хранения. Журнал, используемый для устранения текущей проблемы, скорее всего, через несколько недель не будет иметь такой же значимости. Аналогично, если вам важно быстро восстановить последнюю резервную копию, такая степень срочности, вероятно, не будет требоваться через несколько месяцев для той же резервной копии. Хотя уровень доступа можно изменить вручную, такой подход приведет к значительным издержкам на обслуживание, особенно при изменении большого количества BLOB-объектов, что часто используется в корпоративных сценариях.
К счастью, это необязательно. Хранилище BLOB-объектов Azure поддерживает политики управления жизненным циклом, которые перемещают данные между уровнями на основе заданных критериев. Например, можно определить правило политики, которое перемещает большие двоичные объекты на архивный уровень, если они не были изменены за последние 90 дней. Аналогичным образом можно создать правило политики для удаления больших двоичных объектов на уровне архива, если они не были доступны за последние 360 дней.
Примечание.
Политики могут быть основаны на дате последнего изменения или дате последнего доступа. Для последнего требуется включить отслеживание времени последнего доступа.
Резервирование емкости хранилища
Если вы планируете использовать хранилище BLOB-объектов Azure в течение длительного времени, вы можете дополнительно сократить затраты, приобретя зарезервированную емкость в 100 терабайт (ТБ) и 1 петабайт (ПБ) в месяц на один или три года. Это соглашение предлагает скидку на хранение (за гигабайт) расходы на данные, находящиеся в Хранилище BLOB-объектов Azure. Вы можете приобрести резервирование для любого уровня доступа и типа избыточности, но применимо к определенному сочетанию региона Azure, уровня доступа и избыточности.