iSCSI thin provisioning: место экономим, нервы тратим

Месяца три назад на одном из объектов мы перевели виртуальные машины с thick-дисков на thin provisioning на iSCSI-хранилище. Задача была проста: у нас заканчивалось место на полке, закупать новые диски прямо сейчас клиент не хотел, а виртуальных машин становилось больше. Thin provisioning казался очевидным выходом - ты объявляешь диск гостю на 100 ГБ, а реально выделяешь блоки только по мере записи. Если гость занял 20 ГБ, на полке лежит тоже примерно 20 ГБ. Всё честно.

Экономия оказалась настоящей. Несколько машин с Windows Server, которые «считали», что у них по 80 ГБ диск, реально занимали по 12-18 ГБ каждая - типичная картина, когда виртуалки создавались «с запасом», а данных там немного. Освободившееся место позволило добавить ещё пяток машин без покупки железа. Клиент доволен, мы немного горды собой.

А потом один из гостей упал.

Как это произошло

Не упал в смысле «выключился». Упал в смысле - Windows Server внутри виртуалки начал выдавать ошибки записи на диск, журналы событий наполнились красными строками, несколько служб встали. При этом снаружи виртуальная машина была «включена» и отвечала на пинги. Хаос.

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

Пул был набит под 98%.

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

Что интересно: хранилище не подало никаких предупреждений. Никаких алертов, никаких SNMP-ловушек - просто молча отказало. С нашей стороны мониторинг смотрел на доступность хоста и состояние iSCSI-сессий, но не на реальное заполнение пула. Это был наш просчёт.

Что мы поменяли

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

Конкретные правки, которые мы внесли:

Мониторинг пула - обязательно. В Zabbix добавили позиции под каждое iSCSI-хранилище с thin-пулами: порог предупреждения на 75%, критический на 85%. Получаем по SNMP или через SSH к management-интерфейсу в зависимости от того, что поддерживает конкретная железка. Настроили это сразу после инцидента - Zabbix 1.6 нам в этом хорошо помог.

Запрет на 100% overcommit. Мы ввели правило: сумма объявленных thin-томов не должна превышать 80% физической ёмкости пула. Звучит банально, но раньше явного ограничения у нас не было - клали, пока влезает, а влезает «виртуально» очень много. Теперь при планировании новых машин сначала смотрим на реальное резервирование.

Документирование пула. Завели таблицу: какие thin-тома в каком пуле, текущий реальный размер каждого, дата последней проверки. Раз в неделю сверяем с мониторингом. Примитивно, зато работает.

Разговор с клиентом о VSS. Теневые копии VSS на гостях - это хорошо, но они незаметно едят пространство пула. Договорились на каждом файловом сервере явно ограничивать объём теневых копий и следить за этим.

Что думаем об этом сейчас

Технология рабочая. Когда мы строили iSCSI-хранилище без Fibre Channel, thin provisioning был в планах, но тогда отложили - казалось сложновато. Сейчас понятно, что сложность не в самом thin provisioning, а в том, что он добавляет новый уровень наблюдения, который легко пропустить.

Гость «видит» большой диск и не подозревает, что реальное место под него может кончиться. Операционная система внутри не имеет инструментов это обнаружить заранее - она просто пишет, и в какой-то момент получает отказ. Для конечного пользователя это выглядит как сбой диска. Для нас - как инцидент, причину которого надо искать не там, где он проявился.

Главный вывод - в managed-сопровождении thin provisioning и мониторинг пула должны идти в комплекте. Одно без другого - это мина с отложенным взрывателем. Сейчас всё работает штатно, пороги расставлены, алерты настроены. Смотрим, как поведёт себя в перспективе нескольких месяцев.