Еще на рубеже веков блочное хранилище было довольно простым делом. Контроллер объединил группу дисков в набор RAID, а затем предложил фиксированные части этого RAID, настроенные как логический том или LUN. Все, что нужно было сделать контроллеру для сопоставления блока в томе с физическим расположением, - это вычислить смещение от начала набора RAID до начала тома и полосы RAID. С такими функциями, как тонкое выделение ресурсов, автоматическое многоуровневое хранение и сокращение объема данных с помощью дедупликации и сжатия.
Еще на рубеже веков блочное хранилище было довольно простым делом. Контроллер объединил группу дисков в набор RAID, а затем предложил фиксированные части этого RAID, настроенные как логический том или LUN. Все, что нужно было сделать контроллеру для сопоставления блока в томе с физическим расположением, - это вычислить смещение от начала набора RAID до начала тома и полосы RAID. С такими функциями, как тонкое выделение ресурсов, автоматическое многоуровневое хранение и сокращение объема данных с помощью дедупликации и сжатия, все не так просто.
Когда вы слышите, что поставщики блочных хранилищ используют строки вроде «У унифицированных систем хранения есть все накладные расходы на файловую систему, потому что они хранят iSCSI или Fibre Channel LUN в виде файлов», они недооценивают метаданные файловой системы, которые современные массивы блочных хранилищ должны отслеживать.
Чтобы запустить любую из новых функций RAID +, контроллеру массива нужна база метаданных, которая для меня очень похожа на файловую систему. Возьмем случай дедупликации данных. Массив должен разбить данные на фрагменты размером 4-1 МБ, выяснить, какие из этих фрагментов хранят те же данные, а затем создать список указателей, отображающий адреса логических блоков LUN в сохраненные фрагменты.
Автоматическое многоуровневое хранение требует еще большего количества метаданных, поскольку система должна отслеживать адреса логических блоков по частям, которые находятся на разных наборах RAID на разных типах хранилищ. В дополнение к выяснению того, какие «горячие» данные следует переместить на более быстрый уровень хранения, а также какие «классные» фрагменты можно понизить, система должна собирать метаданные о частоте доступа.
Что это означает для плохого администратора хранилища? Во-первых, это объясняет, почему дисковым массивам нужны процессоры большего размера для обеспечения хорошей производительности. Ваш поставщик может не выпускать дым, когда говорит, что вы не можете запустить многоуровневую обработку или сжатие в своей старой системе, потому что у нее недостаточно мощности.