Thin provisioning на SAN: освободили 30% ёмкости без покупки нового железа

Когда клиент в начале года заказывал SAN с запасом под рост, мы закладывали ёмкость с головой. Прошло полгода - хранилище занято примерно на две трети, а заявки на «дайте ещё дисков» уже начались. Это знакомая история: виртуальные машины создаются с thick-дисками «на вырост», реально используют треть, остальное лежит мёртвым грузом.

vSphere 4.1 вышел в июле, и среди улучшений - расширенная поддержка thin provisioning для VMDK и Storage vMotion между хранилищами разных типов без потери thin-режима. Решили воспользоваться моментом.

Что такое thin provisioning и где он помогает

Thick-диск резервирует всё заявленное место на LUN сразу при создании VM. Создал 100 ГБ диск - SAN тут же отмечает 100 ГБ как занятые, даже если внутри пока 8 ГБ данных. Thin-диск растёт по мере записи: выделено 100 ГБ «потолок», а физически занято ровно столько, сколько записано.

Для VM, которые «живут с запасом» - это прямая экономия. Windows-сервер с 80 ГБ thick-диском, на котором реально 25 ГБ данных, при конвертации в thin сразу освобождает 55 ГБ на хранилище. Умножаем на двадцать VM - и арифметика становится интересной.

Принципиальный момент: thin provisioning решает проблему overprovisioning при создании дисков. Это не дедупликация и не компрессия - данные хранятся как есть, просто не занимают место, которое ещё не записано.

Что делали у клиента

Хранилище - EMC CLARiiON, к нему два ESXi-хоста через iSCSI. Парк примерно из двадцати VM: файловый сервер, несколько серверов приложений, терминальные серверы, тестовые машины.

Работали поэтапно:

• Инвентаризация дисков. Через vSphere Client смотрели на каждый VMDK: provisioned capacity vs. used space. Сразу стало видно, где резерв большой, а где VM действительно использует близко к выделенному.
• Приоритет на тестовые и dev-машины. Начали с тех, где риск минимален. Если что-то пойдёт не так с конвертацией - продакшн не затронут.
• Storage vMotion с конвертацией. В vSphere 4.1 при миграции через Storage vMotion можно выбрать формат диска на целевом хранилище. Мигрировали VM на тот же LUN, явно указывая thin. Даунтайма нет - VM продолжает работать во время миграции.
• Продакшн-серверы - в окно обслуживания. Технически можно и без даунтайма, но для файловых серверов и терминалок предпочли делать в ночное окно: меньше нагрузки, проще контролировать.

По итогу освободили около 30% от общей ёмкости хранилища. Цифра не удивительная - она прямо следует из того, насколько агрессивно VM создавались с запасом. У кого-то этот показатель будет меньше, у кого-то больше.

Главное, о чём нельзя забыть

Thin provisioning создаёт ситуацию, которой не было при thick: SAN знает, что у неё 2 ТБ, VM суммарно «думают», что у них 3 ТБ, а реально записано 1,4 ТБ. Пока данных немного - всё хорошо. Если несколько VM начнут активно писать одновременно, свободное место на хранилище будет таять быстрее, чем кажется.

Если хранилище кончится - thin-диски VM просто встанут. Это не плановая пауза, это внезапный отказ.

Поэтому обязательно настраиваем алёрты:

• vCenter: alert на Datastore Free Space. Стандартный алёрт в vSphere, порог ставим на 20% и на 10% свободного места. Первый - предупреждение, второй - критический.
• На хранилище: native-алёрты CLARiiON. EMC имеет собственную систему нотификаций - там тоже настраиваем порог по LUN utilization.
• Nagios поверх всего. У нас есть check_emc или check_snmp для мониторинга SAN - добавили проверку реального занятого места с агрессивным порогом. Дублирование не лишнее: если vCenter недоступен по какой-то причине, мониторинг независимый.

Без этих алёртов thin provisioning - это бомба с неизвестным таймером. С алёртами - нормальный инструмент экономии.

Про Storage vMotion между разными типами хранилищ

Это отдельная приятная возможность в 4.1: раньше Storage vMotion работал в пределах одного хранилища или между хранилищами одного типа. Теперь можно мигрировать VM с FC-LUN на iSCSI-датастор и обратно без выключения, причём с конвертацией формата диска на лету.

Практически это означает, что можно переместить «холодные» VM с быстрого FC-хранилища на более дешёвый iSCSI, освободив FC-ёмкость под нагруженные задачи. У этого клиента один СХД, так что этот сценарий не трогали - но в проектах с несколькими хранилищами возможность интересная.

Что получилось в итоге

Клиент получил обратно 30% ёмкости SAN без покупки дополнительных полок. Это не бесконечный ресурс - по мере роста данных место будет расходоваться, просто более честно. Но запас, который раньше лежал замороженным в нераспределённых блоках, теперь доступен.

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

Thin provisioning - не новая идея и не магия. Но включить его при создании VM в 2010 году - всё ещё не стандартная практика у большинства клиентов, которых мы видим. Многие просто не задумываются, что thick - это дефолт, а не единственный вариант. Это одна из первых вещей, которую мы проверяем при сопровождении инфраструктуры.