Общие сведения о модели затрат Azure NetApp Files

Чтобы управлять затратами на Azure NetApp Files, необходимо понять свою модель затрат, включая эффективную емкость, цены и концепции выставления счетов.

Overview

Стоимость Azure NetApp Files определяется на основе выделенной емкости и выделенной производительности. Вы распределяете емкость через пулы емкости и потребляете ее через тома. Производительность предоставляется либо в виде пропускной способности, пропорциональной выделенной емкости (уровни обслуживания «Стандартный», «Премиум» и «Ультра»), либо в виде пропускной способности, выделяемой независимо от емкости (гибкий уровень обслуживания). Сервис учитывает всё потребление почасово и выставляет счета ежемесячно, поэтому может быстро реагировать на динамическое масштабирование и динамическое изменение уровня обслуживания.

В этой статье описываются модель тарификации, связь между емкостью и производительностью, возможности, снижающие фактическую стоимость, а также платные дополнительные возможности, такие как резервное копирование Azure NetApp Files и межрегиональная репликация (CRR), которые добавляют дополнительные компоненты тарификации. Он также включает подробно разобранные примеры, которые иллюстрируют, как эти возможности в совокупности повышают эффективную ёмкость и снижают эффективную стоимость.

Основы выставления счетов

Пулы емкости — тарификация выделенной емкости

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

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

Почасовой учёт, ежемесячное выставление счетов

Служба измеряет распределение емкости пула ресурсов каждый час. Каждый час служба записывает размер пула, уровень обслуживания и (для гибкого уровня обслуживания) подготовленную пропускную способность, которая действует в этот час. Ежемесячный счет Azure рассчитывается на основе почасовых данных.

Почасовое измерение является основой оптимизации затрат в Azure NetApp Files. Любое изменение, вступающее в силу в течение расчетного периода, — изменение размера пула или тома, изменение уровня обслуживания или корректировка пропускной способности гибкого уровня обслуживания — отражается в следующем почасовом измерении. Вы можете непрерывно подбирать оптимальный размер томов, пулов емкости и рабочих нагрузок без необходимости брать на себя долгосрочные обязательства в отношении базового пула емкости.

Пулы емкости и тома хранения

Как упоминалось ранее, пулы емкости служат основными единицами для выделения ресурсов и выставления счетов. Тома — это единицы для потребления.

Правила определения размеров

• Пулы емкости: Пул емкости имеет минимальный размер 1 ТиБ. Его размер можно изменять с шагом 1 ТиБ вплоть до максимального размера пула хранения в 2 048 ТиБ. Вы также можете уменьшать его размер с шагом 1 ТиБ вплоть до объема, выделенного томам в пуле емкости.
• Объемы: Вы можете задать размер обычного тома от 50 ГиБ до 100 ТиБ. Большие тома поддерживают до 2 PiB или 7,2 PiB для дополнительных объемов с поддержкой холодного доступа.
• Том имеет квоту на ёмкость и квоту на пропускную способность. Функция Auto QoS автоматически устанавливает квоту пропускной способности в зависимости от квоты ёмкости. Ручная настройка QoS задает квоту пропускной способности отдельно. Квота по ёмкости вычитается из выделенного объёма родительского пула. Сумма квот на объем томов в пуле не может превышать размер пула. Это правило в равной степени справедливо и для выделенной пропускной способности в отношении квоты пропускной способности.

Учет емкости и пропускной способности

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

Пропускная способность на уровне тома учитывается в счет квоты пропускной способности пула емкости. При автоматическом QoS размер квоты линейно масштабируется в зависимости от выделенной ёмкости тома. При ручной настройке QoS вы устанавливаете квоту вручную. Для пула с уровнем обслуживания Flexible суммарное значение квот пропускной способности томов не может превышать пропускную способность, выделенную для пула. Выделенная пропускная способность пула определяет составляющую счета, связанную с пропускной способностью.

Как выделяется и оплачивается пропускная способность

Пропускная способность в Azure NetApp Files задаётся через уровень сервиса пула ёмкости. Доступны две модели.

Линейные уровни обслуживания: "Стандартный", "Премиум", "Ультра"

Уровни обслуживания "Стандартный", "Премиум" и "Ультра" обеспечивают пропускную способность в фиксированной пропорции подготовленной емкости. Каждому ТиБ емкости пула соответствует определенный объем пропускной способности, поэтому общая пропускная способность линейно увеличивается с ростом размера пула. Вы оплачиваете одну ставку за ГиБ-час, которая зависит от уровня обслуживания: стандарт имеет самую низкую скорость и самую низкую пропускную способность на ТиБ, и Ультра имеет самый высокий из всех.

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

Гибкий уровень обслуживания

Гибкий уровень обслуживания отделяет пропускную способность от емкости. Вы создаёте пул ёмкости уровня обслуживания Flexible с выбранной ёмкостью и отдельно выбранной пропускной способностью. Пул включает базовое распределение пропускной способности 128 МиБ/с, и вы можете добавить другую пропускную способность в 1 МиБ/с без изменения емкости пула (не более 640 МиБ/с на ТиБ).

Тарификация гибкого пула уровней обслуживания состоит из двух компонентов: платы за каждый ГиБ-час выделенной емкости и платы за каждый МиБ/с-час выделенной пропускной способности сверх базового уровня. Емкость и пропускную способность можно настроить независимо в любое время, а следующее почасовое измерение фиксирует обновленные значения.

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

Выбор уровня обслуживания

• Standard, Premium, Ultra: используйте, если требования к пропускной способности предсказуемо растут по мере увеличения объема данных и если один параметр емкости упрощает эксплуатацию.
• Гибкость: используйте, когда требования к ёмкости и пропускной способности изменяются независимо друг от друга, когда избыточное выделение ресурсов по одному параметру для получения нужного значения другого было бы неэффективным, или когда ёмкость и уровень производительности необходимо настраивать отдельно на протяжении жизненного цикла рабочей нагрузки.

Потребление емкости

Логическая и физическая емкость

Логическая емкость — это объем данных, содержащихся в активной файловой системе, а также разностных данных, хранящихся в снимках. Физическая емкость — это объем хранилища, занятого в системе.

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

Распределение емкости и потребление моментальных снимков

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

Пример: том объёмом 100 ТиБ имеет 80 ТиБ активного потребления файловой системы и два снимка, которые содержат 10 ТиБ дифференциальных данных. Логическое потребление тома составляет 80 ТиБ активных данных и два снимка, каждый из которых даёт ещё одно полное представление данных объёмом 80 ТиБ на определённый момент времени, что в сумме составляет логический объём 240 ТиБ. Однако физически потреблённый объём, учтённый в квоте тома, составляет всего 90 ТиБ, а не 240 ТиБ.

При планировании можно руководствоваться практическим правилом: резерва по ёмкости в 20 % достаточно, чтобы хранить снимки как минимум за неделю для многих рабочих нагрузок. Фактическая ёмкость снимка зависит от срока хранения снимков и ежедневной скорости изменения блоков.

Распределение емкости и потребление краткосрочных клонов

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

Учет квот в пуле емкости

Рассмотрим пул ресурсов с выделенной емкостью 12 ТиБ, содержащий три тома:

• Том A: квота 5 ТиБ, использовано 4,5 ТиБ (4 ТиБ активно, 500 ГиБ в снимках); свободно 500 ГиБ.
• Том B: квота 3 ТиБ, использовано 2,5 ТиБ (2,5 ТиБ активно используется); свободно 500 ГиБ.
• Том C: квота 2 ТиБ, полностью использована (1,5 ТиБ активных данных, 500 ГиБ буфера краткосрочных клонов).

Счёт за пул выставляется исходя из выделенного объёма 12 ТиБ. Из этого 10 ТиБ выделено под квоты томов, 9 ТиБ занято, а 8 ТиБ активно используется. 1 ТиБ остается свободным в пределах квот, и оставшийся 2 ТиБ нераспределен.

На этой схеме показано, как пул ёмкостью 12 TiB разделён между тремя томами и нераспределённым резервом, с разбивкой на выделенное, использованное, свободное и нераспределённое пространство.

Пять уровней емкости

Общие сведения о цветах заливки

Разбивка по объему тома

Итог: из пула объёмом 12 ТиБ 9 ТиБ занято, 1 ТиБ свободен в пределах квот, а 2 ТиБ остаются нераспределёнными — всего около 3 ТиБ запаса до полного заполнения пула.

Динамический подбор оптимального размера

Так как Azure NetApp Files измеряется почасово, она поддерживает непрерывную емкость, пропускную способность и балансировку затрат с помощью трех динамических настроек. Каждая корректировка действует на следующую почасовую границу выставления счетов.

Динамическое изменение размера емкости

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

Динамическое изменение уровня обслуживания

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

Динамическая корректировка пропускной способности (гибкий уровень обслуживания)

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

Встроенные возможности оптимизации затрат

Azure NetApp Files включает возможности, которые снижают затраты на хранилище, уменьшая скорость оплаты за ГиБ/ч, уменьшая емкость, которую необходимо подготовить, или выравнивая подготовленные ресурсы с фактическим спросом. Эти возможности являются независимыми и составными при совместном использовании.

Хранилище с прохладным доступом (прозрачное многоуровневое хранение данных)

Хранилище Azure NetApp Files с поддержкой холодного доступа перемещает редко используемые блоки данных из пула емкости в более дешевое хранилище служба хранилища Azure. Период прохлады (от 2 до 183 дней) определяет, сколько времени блок должен оставаться нетронутым, прежде чем он отключается. Операции чтения многоуровневых данных выполняются прозрачно, а затронутые блоки снова перемещаются в горячий уровень Azure NetApp Files в зависимости от шаблона доступа.

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

Зарезервированная емкость

Резервирование емкости — это обязательство по использованию определенного объема емкости Azure NetApp Files. Для резервирования действует скидка на ставку за ГиБ для ёмкости в рамках резервирования. Вы оплачиваете использование сверх объема, покрываемого резервированием, по тарифу оплаты по мере использования.

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

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

Эффективные в пространстве моментальные снимки и краткосрочные клоны

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

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

Моментальные снимки — это основной механизм быстрого восстановления данных в Azure NetApp Files. Они не заменяют резервные копии. Для долговременного хранения, защиты от случайного удаления тома и устойчивости к сбоям сочетайте моментальные снимки с резервным копированием Azure NetApp Files.

Снимки увеличивают эффективную ёмкость за счёт совместного использования неизменённых блоков данных с активным томом.

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

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

Например, если моментальные снимки характеризуются ежедневным изменением на 3 %, а расчётный объём буфера записи составляет 5 %, средство оценки может использовать совокупный коэффициент изменения 8 %. Этот подход обеспечивает практический способ моделировать емкость, связанную с клонированием, без изменения размера клона как полной второй копии.

Иллюстративный пример краткосрочной оценки клона. Используйте скорость изменения моментального снимка и буфер записи клона вместе, чтобы приблизительно оценить краткосрочную ёмкость клона в оценщике.

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

Гибкий уровень обслуживания как инструмент оптимизации затрат

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

Рассмотрим пример рабочей нагрузки, которой требуется всего 1 ТиБ емкости при пропускной способности 512 МиБ/с, и посмотрим, в чем разница между пулом емкости, настроенным с уровнями обслуживания Ultra и Flexible. Эта разница — пример затрат для рабочей нагрузки с высокой пропускной способностью и низкой емкостью.

Примерная экономия: 39%

Напротив, рассмотрим пример нагрузки, которой требуется ёмкость 550 ТиБ при пропускной способности всего 128 МиБ/с, и посмотрим на разницу между пулом ёмкости, настроенным с уровнем обслуживания Standard, и пулом ёмкости с гибким уровнем обслуживания. Эта разница — пример затрат для рабочей нагрузки с низкой пропускной способностью и высокой ёмкостью.

Иллюстрирующая экономия: 25%

Эта разница — пример затрат для рабочей нагрузки с низкой пропускной способностью и высокой ёмкостью.

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

Платные возможности дополнений

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

Резервное копирование Azure NetApp Files

Резервное копирование Azure NetApp Files сохраняет моментальные снимки томов в хранилище Azure вне тома, обеспечивая долгосрочное хранение и защиту от случайного удаления тома. Тарификация резервного копирования состоит из двух компонентов: ставки за ГиБ-месяц для потребляемого хранилища в хранилище резервных копий (после создания первой полной базовой копии сохраняются только измененные блоки) и ставки за ГиБ для операций восстановления. Поскольку после создания начальной базовой копии сохраняются только разностные блоки, дальнейший рост хранилища резервных копий зависит от темпа изменения снимка, а не от его полного логического размера на уровне файлов.

Репликация между регионами (CRR)

Межрегиональная репликация асинхронно реплицирует данные с исходного тома на целевой том в другом регионе Azure для аварийного восстановления. Целевой том размещается в пуле ресурсов хранения в целевом регионе и оплачивается по стандартной ставке этого пула. Кроме того, передача реплицируемых данных между регионами учитывается и оплачивается по тарифу за каждый переданный ГиБ. Расписания репликации (каждые 10 минут, ежечасно, ежедневно) и скорость изменения данных влияют на объем передаваемых измененных данных, но не влияют на плату за емкость на стороне назначения, которая рассчитывается на основе выделенного размера целевого пула. Чтобы оптимизировать затраты на неактивные данные аварийного восстановления, том назначения, подготовленный с уровнем обслуживания Flexible, можно настроить на базовую пропускную способность 128 МиБ/с, что позволяет минимизировать затраты, пока реплика не обслуживает продуктивный трафик.

Эффективные концепции емкости и эффективной цены

Эффективная емкость

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

Пример: том ёмкостью 50 ТиБ, полностью занятый данными, с четырьмя снимками, суммарно занимающими 5 ТиБ пространства снимков, обеспечивает 250 ТиБ логической ёмкости (активная файловая система плюс четыре фиксированных по времени состояния), при этом выделенная и фактически используемая ёмкость составляет (всего) 55 ТиБ.

Эффективная цена

Концепция эффективной цены — это стоимость одного ГиБ логических данных с учетом многоуровневого хранения, резервирования, эффективного увеличения ёмкости и любой согласованной скидки.

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

Эффективная цена отражает скидки и прирост ёмкости за счёт возможностей, применённые к базовому тарифу.

Примеры моделирования затрат

Цены в примерах используют репрезентативные ставки и зависят от региона. Ознакомьтесь со страницей цен на Azure NetApp Files для текущих ставок в вашем регионе.

Пример 1. Изменение размера динамической емкости

Рабочая нагрузка использует пул ресурсов уровня Premium со следующим ежемесячным профилем: 24 часа — 10 ТиБ, 96 часов — 24 ТиБ, 24 часа — 5 ТиБ, 480 часов — 6 ТиБ, а в остальное время — 0 ТиБ. Вы оплачиваете $0,000403 за ГиБ-час за емкость.

Экономия: $4892,64 в месяц (69%)

Пример 2. Динамическое изменение уровня обслуживания

Емкость является константой в 24 ТиБ. Требования к производительности различаются: 384 часа на уровне Standard ($0,000202 за ГиБ-час), 120 часов на уровне Premium ($0,000403), 168 часов на уровне Ultra ($0,000538) и затем ещё 48 часов на уровне Standard.

Экономия: $3970,38 в месяц (42%)

Пример 3. Хранилище с холодным доступом и резервированиями

У организации есть 550 ТиБ данных общего файлового ресурса в пуле емкости уровня "Стандартный". Прейскурантная цена составляет $0,147 за ГиБ-месяц. По оценкам, 80 % данных (440 ТиБ) перемещается на уровень cool по цене 0,059 долл. США за ГиБ-месяц. 110 ТиБ остается на горячем уровне. Резервирование стандартного уровня обслуживания сроком на 1 год и объёмом 100 ТиБ (скидка 18 %) покрывает часть горячего уровня.

Эффективная цена снижается с $ 0,147 до $ 0,073 за ГиБ-месяц (около 50% ниже базовой).

Пример 4: Снимки

Том Premium размером 110 TiB хранит три ежедневных снимка. Частота ежедневных изменений составляет 3%. Прейскурантная цена «Премиум» составляет 0,294 долл. США за ГиБ-месяц.

Базовый вариант: том Premium емкостью 110 TiB без моментальных снимков.

С ежедневными моментальными снимками:

• Три ежедневных моментальных снимка при уровне изменений 3% добавляют приблизительно 10 ТиБ дифференциальных данных
• Общая потребляемая емкость составляет около 120 ТиБ
• Логический объем составляет 440 ТиБ (активный набор данных и три восстанавливаемых представления на определенный момент времени)
• Эффективная цена снижается примерно до 0,080 $ за ГиБ доступных данных, или до около 73% прейскурантной цены для того же восстанавливаемого объёма данных

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

Пример 5. Краткосрочные клоны

Исходный том объёмом 50 TiB уровня обслуживания Premium используется для создания временного клона для тестирования и аналитики. Ожидаемый объём активно записываемых данных в клоне составляет 5 ТиБ. Прейскурантная цена «Премиум» составляет 0,294 долл. США за ГиБ-месяц.

При использовании временного клона:

• Выделенная емкость составляет 5 ТиБ вместо 50 ТиБ и рассчитана только на ожидаемый рабочий набор записи объемом 5 ТиБ
• 5 ТиБ × 1024 ГиБ/ТиБ × $ 0,294 = $ 1506 в месяц, сокращение примерно на 90%

Приблизительное сокращение: 90%

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

Пример 6. Гибкий уровень обслуживания, согласованный с рабочей нагрузкой

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

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

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

Набор данных объёмом 110 TiB использует три ежедневных моментальных снимка при ежедневном коэффициенте изменений 3% и краткосрочный клон, размер которого рассчитан с 5%-м буфером записи для тестирования и аналитики. Для 80 % основного набора данных допустимо хранение с прохладным доступом. Горячий уровень по-прежнему использует уровень обслуживания Premium, при этом резервирование на 100 ТиБ покрывает большую часть этой выделенной емкости. Резервная копия для аварийного восстановления размещена на уровне Flexible service с базовой пропускной способностью 128 МиБ/с, чтобы снизить затраты на репликацию в период простоя.

База:

• Основная рабочая нагрузка: 110 ТиБ хранилища Класса Premium.
• Временная записываемая копия: предоставлена как второй том Premium объёмом 110 TiB.
• Целевой объект аварийного восстановления: выделен как том Premium емкостью 110 TiB в целевом регионе.
• Общая выделенная емкость уровня Premium: 330 ТиБ без учета моментальных снимков и платы за передачу данных при репликации.
• Ежемесячная стоимость хранения: примерно 99 414 $ при цене 0,294 $ за ГиБ-месяц.
• Эффективная цена: остается по цене списка, так как каждая дополнительная копия подготавливается как почти полный дубликат.

Общая подготовленная емкость Premium: 330 ТиБ | Ежемесячная стоимость хранения: около $ 99 414

При комплексной оптимизации:

• Горячий уровень: 22 ТиБ на уровне Premium после распределения по уровням; ежемесячная стоимость — около 8 870 $.
• Уровень Cool: 88 ТиБ с доступом Cool; ежемесячная стоимость — около 5 304 $.
• Зарезервированная емкость: резервирование 100 ТиБ охватывает большую часть емкости уровня "Премиум"
• Моментальные снимки: три ежедневных моментальных снимка при 3 %-ном уровне изменений требуют дополнительно около 10 ТиБ дифференциальной ёмкости.
• Логический объем: расширяется с 110 ТиБ до около 440 ТиБ.
• Потребляемая емкость: увеличивается только до 120 ТиБ.
• Краткосрочный клон: буфер записи объёмом 5 % вместо второго полного тома объёмом 110 ТиБ; ежемесячная стоимость — около 1 506 $.
• Копия для аварийного восстановления: гибкий уровень сервиса с базовым уровнем 128 МиБ/с позволяет сохранить низкие затраты при простое.

Итог: фактическая цена ниже, поскольку стоимость снижается, а полезная ёмкость увеличивается.

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

Сводка

Модель затрат Azure NetApp Files основана на трех ключевых свойствах:

• Выделение ресурсов определяет тарификацию. Стоимость зависит от выделенной емкости (а для уровня обслуживания Flexible — также от выделенной пропускной способности), а не от объема хранимых данных.
• Учёт почасовой. Динамическое изменение размера, динамические изменения уровня сервиса и динамические корректировки гибкой пропускной способности вступают в силу в течение часа и отражаются в ежемесячном счете.
• Возможности накапливаются. Холодный доступ, зарезервированная емкость, моментальные снимки, краткосрочные клоны и гибкий уровень обслуживания решают различные части уравнения затрат и могут быть объединены.

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

Эффективная емкость и эффективная цена обеспечивают объектив для понимания полной экономической ценности Azure NetApp Files. Эффективная ёмкость обозначает, какой объём логических данных может быть представлен или защищён заданным объёмом выделенной ёмкости, когда такие функции, как моментальные снимки и кратковременные клоны, повторно используют неизменённые блоки вместо создания полных копий. Эффективная цена отражает итоговую стоимость за ГиБ полезных данных с учётом этого повышения эффективности в сочетании с распределением данных по более экономичным уровням хранения, резервированием и выделением ресурсов в соответствии с требованиями рабочей нагрузки, например на уровне обслуживания Flexible.

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

Дальнейшие шаги

• Страница цен на Azure NetApp Files
• Уровни обслуживания для Azure NetApp Files
• Ограничения ресурсов для Azure NetApp Files
• Модель затрат для репликации между регионами
• Резервирования для Azure NetApp Files
• Холодный доступ в Azure NetApp Files
• Как работают моментальные снимки в Azure NetApp Files
• Клоны на короткий срок в Azure NetApp Files
• Резервное копирование Azure NetApp Files
• Общие сведения о квоте тома
• Отслеживание емкости тома
• Изменить размер пула емкости или тома
• Управление выставлением счетов с помощью тегов
• Вопросы и ответы по управлению ресурсами
• калькулятор цен Azure для Azure NetApp Files
• Средства Azure NetApp Files