Thin provisioning на NetApp FAS2040: реальная экономия или маркетинг?

У нас на обслуживании несколько клиентов с NetApp FAS2040, и в последние месяцы мы окончательно перевели их на ONTAP 8 с включёнными thin provisioning и дедупликацией. Пора написать честный разбор - что работает, а что требует внимания.

Про что вообще речь. Традиционный LUN на SAN резервирует место сразу: создал 500 ГБ - 500 ГБ физически заблокированы на дисковой полке, пустые они или нет. Thin provisioning переворачивает логику: LUN «видит» столько места, сколько ты ему пообещал, а физически занимает только то, что реально записано. Dedupe добавляет сверху - одинаковые блоки хранятся в одном экземпляре.

Звучит красиво. Проверяем на реальной нагрузке.

Что получилось на базах данных

Клиент - средний интернет-магазин, несколько серверов с MS SQL Server 2008 R2 и MySQL 5.1. Суммарно под базы выделено около 3 ТБ в LUN-ах. До перехода на thin provisioning всё это пространство было зарезервировано физически, хотя реальная утилизация была примерно на 55-60%.

После включения thin provisioning + dedupe картина изменилась. На SQL-серверах дедупликация даёт скромный результат - базы данных с рандомными данными деdupeются плохо, это известный факт. Зато сами данные часто имеют схожие паттерны в системных страницах, логах транзакций, временных таблицах. В итоге получаем 25-30% экономии только от thin provisioning (за счёт свободного пространства внутри LUN-ов), плюс 10-15% от дедупликации на системных томах. Итого от 30 до 40% физического пространства возвращается в пул - и это в пределах нормы для такого типа нагрузки.

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

Как включали

На ONTAP 8 thin provisioning включается на уровне volume:

vol options vol_sql01 space_guarantee none

Дедупликация:

sis on /vol/vol_sql01
sis config -s auto /vol/vol_sql01

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

Важный момент: если том уже существующий и создавался с space-guarantee volume, при смене на none ONTAP не сразу освобождает зарезервированное место - нужно дождаться следующего цикла или запустить вручную.

Проблема overcommit и как с ней жить

Вот где начинается самое важное. Thin provisioning - это кредит доверия. Ты обещаешь серверу пространство, которого физически нет. Если реальное заполнение начнёт расти быстрее, чем ты ожидал, рискуешь получить ситуацию, когда физическое место на агрегате заканчивается раньше, чем это заметит сервер. Для базы данных это катастрофа - операции записи начинают падать на уровне хранилища, и MS SQL не всегда красиво это обрабатывает.

Мы настроили алерты через Zabbix - агент опрашивает ONTAP через SNMP и смотрит на несколько метрик:

• Физическое место в агрегате. Алерт при достижении 80% - это порог, при котором ещё есть время среагировать.
• Overcommit ratio - соотношение суммы обещанных LUN-ов к физическому пространству. Держим порог на 150%: выше - предупреждение, выше 200% - критикал.
• Volume space used - отдельно на каждый том, тоже 80%/90%.

SNMP OID для пространства агрегата в ONTAP 8 - 1.3.6.1.4.1.789.1.5.4 (netapp enterprise MIB). Либо используем OnCommand System Manager - там всё это есть в GUI, но мониторинг через Zabbix даёт централизацию и историю.

В настройках ONTAP есть параметр space-mgmt-threshold-alert, но мы предпочитаем контролировать это со своей стороны, чтобы алерты приходили в ту же систему, что и все остальные.

Что не работает так, как ожидаешь

Первое - snapshot overhead. Снапшоты на тонко-provisioned томах ведут себя хитро: удалённые данные не освобождают место немедленно, пока существует снапшот, который их «держит». На базах данных, где много операций UPDATE/DELETE, это может приводить к тому, что физический объём тома растёт быстрее, чем объём актуальных данных.

Второе - дедупликация и производительность. Первый прогон дедупликации - заметная нагрузка на контроллер. Мы запускаем её строго в окна минимальной активности. На IOPS-интенсивных базах даже ночной прогон иногда даёт о себе знать в утренних графиках latency.

Третье - false security. Когда видишь красивые цифры экономии в OnCommand, появляется соблазн добавить ещё LUN-ов. Не спеши. Overcommit - это долг, который нужно обслуживать постоянным мониторингом.

Итог

Thin provisioning на NetApp реально работает и реально экономит место - особенно в смешанных средах, где серверы никогда не заняты на 100%. Для клиентов, у которых мы ведём managed-сопровождение, это позволило отложить покупку дополнительных дисковых полок на несколько месяцев. Но это инструмент, который требует постоянного внимания к метрикам - без мониторинга overcommit это просто тикающий таймер.

Алерты на 80% физического агрегата настроили всем. Без исключений.