Thin provisioning на SAN: 40% физического места вернулось без замены железа

Клиент - производственная компания, средний размер, хранилище на SAN от HP StorageWorks. Томов много: под базы данных, под файловый сервер, под Exchange, под виртуальные машины. Все тома выделены с запасом, потому что когда-то кто-то решил, что лучше дать 500 гигабайт сейчас, чем потом расширять в аварийном порядке. Логика понятная. Итог предсказуемый: физическое пространство на массиве освоено на 85%, при этом реально занято от силы половина выделенного.

Именно для этого случая и придумали thin provisioning.

Что это такое и как работает

Обычный том - thick provisioning - при создании сразу резервирует всё заявленное пространство на физических дисках. Создал том 500 гигабайт - на массиве сразу занято 500 гигабайт, даже если там пока лежит один файл на мегабайт.

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

EMC, NetApp и HP StorageWorks добавили эту возможность как штатную функцию в текущих версиях своих массивов. У нашего клиента HP StorageWorks соответствующей версии - включить можно без апгрейда железа, только через конфигурацию.

Что сделали

Подошли к задаче аккуратно. Сразу конвертировать все тома не стали - начали с тех, где разрыв между выделенным и занятым был наиболее очевидным. Файловый сервер: том на 2 TB, реально занято около 900 GB. Том под один из проектов: выделено 800 GB, занято 200 GB.

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

На всё ушло одно ночное окно. Утром прошлись по мониторингу - всё работает, хосты не жалуются.

Что получили

Физически занятое место на массиве упало примерно на 40%. Это не маркетинговые цифры - это то, что показывает консоль управления массивом. Тома с точки зрения хостов остались прежнего размера, никаких изменений на уровне файловых систем и приложений. Просто на физических дисках теперь не зарезервировано место, которое реально не занято.

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

Где собака зарыта

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

Если массив исчерпал физический пул - все тонкие тома на нём начинают получать ошибки записи. Разом. Это не «файловый сервер переполнился», это «у нас лежит половина инфраструктуры».

Именно поэтому мониторинг теперь стал принципиально важнее. Раньше достаточно было следить за каждым томом по отдельности. Теперь нужно отдельно следить за физическим пулом - насколько он реально заполнен в данный момент, каков темп роста, когда при текущем темпе он будет исчерпан.

В Zabbix добавили два новых параметра с массива: процент использования физического пула thin provisioning и скорость роста за последние 7 дней. Порог предупреждения - 70% физического пула, порог критический - 80%. При текущей скорости роста у клиента до критической зоны ещё далеко, но предупреждение нужно сейчас, а не когда уже горит.

Несколько наблюдений по ходу

Конвертация не обратима просто так. Перевести том из thin обратно в thick - это не нажать одну кнопку. Точнее, кнопка есть, но она потребует свободного места на массиве в размере всего выделенного тома. Если места нет - не выйдет. Это надо понимать до того, как конвертировать.

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

Overcommit должен быть осознанным. Суммарный виртуальный размер всех тонких томов у нас получился в два с лишним раза больше физического пула. Это нормально и ожидаемо - в этом весь смысл. Но важно вести учёт: какие тома, какой реальный темп роста, есть ли сезонные пики. Если не вести - ситуация «физический пул кончился» придёт внезапно.

Где сейчас

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

Для инфраструктуры, которую мы ведём в рамках сопровождения, thin provisioning становится стандартным подходом для новых томов на массивах, где эта функция есть. Thick оставляем только там, где нагрузка интенсивная и мы не хотим никаких дополнительных накладных расходов при выделении блоков. Для всего остального - смысла резервировать физические блоки заранее уже нет.

Единственное, что важно повторить напоследок: thin provisioning без мониторинга физического пула опаснее, чем thick без мониторинга отдельных томов. Масштаб потенциальной проблемы другой.