Иногда понедельник у системного администратора начинается одинаково:
в кабинет по очереди заходят три руководителя и каждый говорит, что ему «срочно нужно место под проект»:
– Нам нужно 100 ТБ
– Нам 50 ТБ.
– А нам 30 ТБ, не меньше.
На бумаге все красиво. В жизни же, через год первый отдел занял только 30 ТБ, второй внезапно вырос до 70, а третий пришел с фразой: «Мы недооценили, нужно еще».
И вот здесь становится понятно, зачем вообще придумали технологию оптимизации Thin Provisioning («Тонкие тома»).
Тонкий том – это когда вы выделяете логический объем «с запасом», но физическое место расходуется по факту записи данных. То есть система не заставляет вас «замораживать» весь объем заранее и жить с ошибками планирования весь следующий год. Особенно это важно там, где рост данных трудно предсказать: проектные контуры, аналитика, виртуализация.
С термином «Тонкие тома» часто путаница: кто-то говорит «тонкий RAID», кто-то «тонкий пул».
Давайте аккуратно разделим уровни:
RAID – это физика.
LUN – это логика поверх этой физики.
В BITBLAZE «тонкость» реализована именно на уровне тонкого LUN, и именно там она приносит практическую пользу.
Что это дает в реальной эксплуатации:
Если спустя месяцы выяснилось, что из 100 ТБ реально занято 30 ТБ, а соседнему сервису нужно не 30, а 70 ТБ, можно перераспределить емкость через связку snapshot — snapclone — новый размер тома.
В этом случае мы не спорим с реальностью («вы же сами просили 100!»), а подстраиваем систему под живую нагрузку.
Для администратора это очень существенная земная выгода: меньше ручной работы, меньше аварийных миграций, больше контроля над тем, как растут сервисы.