Thin provisioning на NetApp FAS: 40% экономии и один очень неприятный сюрприз

Несколько лет назад мы уже обжигались на thin provisioning - тогда на самосборном iSCSI-хранилище, без нормального мониторинга пула, и один файловый сервер тихо упал в ошибки записи. Урок усвоили. Казалось, больше не наступим.

Наступили снова. Просто в другом месте и по-другому.

Контекст: клиент переходит на NetApp FAS

У одного из клиентов - производственная компания, несколько десятков виртуальных машин на VMware vSphere 5.0 - заканчивалось место на старой полке. Вместо расширения за счёт новых дисков решили перейти на NetApp FAS2240. Машина совсем другого класса: нормальный ONTAP, дедупликация, снапшоты, FlexVol, thin provisioning на уровне тома - всё по-взрослому. Не самодельный iSCSI-таргет на Linux.

Thin provisioning здесь работает через FlexVol-тома: ты создаёшь том, объявляешь ему «гарантированный» размер, а реальные блоки выделяются по мере записи из агрегата. Если говорить грубо - агрегат это физическое пространство дисков, том это логический контейнер, и несколько томов сидят в одном агрегате и делят реальное место.

Экономия получилась очень приятной. Раньше под виртуальные машины было выделено место с толстым запасом - thick LUN-ы на каждый гость. После миграции на thin-тома с реальным замером занятого места оказалось, что физически используется примерно на 40% меньше, чем было выделено номинально. Для клиента это означало: существующей ёмкости хватит значительно дольше, чем планировалось.

Клиент доволен. Мы снова немного горды.

Где прячется подвох

NetApp FAS в отличие от самодельного iSCSI умеет настраивать space guarantee на уровне тома. Это параметр, который определяет, как ONTAP резервирует пространство. Есть три режима:

volume - полный объём тома резервируется в агрегате сразу при создании. Thin provisioning при этом отключается де-факто - экономии нет, зато гарантия есть.

file - резервируются только те блоки, которые явно выделены внутри тома. Классический thin.

none - никакой гарантии. ONTAP будет выделять блоки по мере записи, но если агрегат кончится - том получит отказ.

Мы установили space guarantee в none - это даёт максимальную экономию. ONTAP позволяет перекоммитить агрегат: суммарный размер томов может превышать физическую ёмкость агрегата. Ровно здесь и находится мина.

Через несколько недель после миграции один из клиентских VMware-хостов начал показывать ошибки на нескольких ВМ одновременно. Не одна машина - сразу несколько. Windows внутри гостей писала в журнал ошибки записи на диск, одна виртуалка вовсе ушла в состояние, из которого vSphere её видела работающей, а изнутри она уже не отвечала нормально.

Агрегат набился под завязку. Несколько томов с thin-гостями одновременно пытались записать данные, свободного места не хватило - и ONTAP отказал в выделении блоков. Без предупреждений, без алертов. Просто - нет.

Почему алерты не сработали

Вот это интересный момент. SNMP-трапы с NetApp были настроены. Zabbix смотрел на доступность хранилища по сети, на состояние RAID-групп, на температуры и питание. Но заполнение агрегата мы не мониторили - потому что привыкли считать место на уровне томов, а не агрегатов. При thick-схеме это работало: LUN занимает ровно столько, сколько объявлен, смотришь на него - знаешь, сколько осталось.

При thin на NetApp логика другая. Тома могут быть в порядке с точки зрения своих объявленных размеров, но агрегат при этом кончается. Следить надо за агрегатом - за реальным физическим пространством - а не только за логическими томами.

Плюс NetApp ONTAP умеет посылать alerta на заполнение агрегата через AutoSupport и SNMP, но только если это явно настроено через System Manager или CLI. По умолчанию порог стоит довольно высокий, и уведомление приходит поздно.

Что поменяли

После разбора полётов сделали несколько изменений - и теперь держим их как стандарт для всех NetApp-проектов в managed-сопровождении.

Мониторинг агрегата - отдельная позиция. В Zabbix добавили элементы через NetApp SNMP MIB на заполнение каждого агрегата. Порог предупреждения - 70%, критический - 80%. Это не тот агрегат, который надо доводить до 90%.

Overcommit ratio под контролем. Ввели правило: суммарный объём объявленных thin-томов не должен превышать 150% физической ёмкости агрегата. При таком соотношении реальное заполнение не дойдёт до критических значений, даже если несколько машин начнут активно расти.

Space guarantee пересмотрели. Для критических ВМ - те, которые не должны падать ни при каких условиях - space guarantee выставили в volume. Да, это отключает экономию для этих конкретных томов. Но баланс оправдан: экономию делаем на машинах с предсказуемой нагрузкой, гарантию даём там, где падение недопустимо.

AutoSupport и NetApp SNMP-алерты. Настроили через CLI netapp threshold set на агрегатах. Теперь сам ONTAP пишет в syslog при подходе к критическим значениям - не только Zabbix.

Итог по факту

Технология работает - экономия реальная, возможности NetApp FAS на порядок шире самодельных iSCSI-решений. Но thin provisioning на корпоративном железе не означает, что всё само отрегулируется. ONTAP достаточно умный, чтобы дать вам верёвку нужной длины. Что с ней делать дальше - ваша ответственность.

Алерты на space guarantee и заполнение агрегата должны быть настроены до того, как вы включите первый thin-том. Не после первого инцидента.