Еще немного про autotiering
Проглядывая community.netapp.com обнаружил дискуссию о autotiering-е, откуда выдернул интересное мнение уже известного вам Dimitris K. (recoverymonkey). Хотя в оригинале это были три реплики-ответа в дискуссии в форуме, я слил их оформил их как отдельную “статью”.
Дискуссия идет о реализации autotiering в EMC FAST, а также о системах хранения Compellent, которые, до недавнего времени, были главным игроком на рынке tiering-а, и реализация прозрачного tiering-а в них была сделана ранее всех. В России они почти неизвестны, хотя сейчас, как я понимаю, они могут начать попадать в страну через каналы Dell.
Dimitris Kriekouvkas (recoverymonkey), сотрудник NetApp:
Autotiering это отличная концепция, но она также очень новая, и результаты ее работы не проверены и не подтверждены на подавляющем большинстве реальных нагрузок.
Посмотрите на опубликованные бенчмарки EMC – там нигде нет autotiering.
Вы также не найдете и показателей FASTcache. Все бенчмарки у EMC делаются на традиционных RAID-группах, без пулов.
Если вы посмотрите на руководство наилучших практик по производительности и доступности для EMC CLARiiON (ссылку на этот документ я давал в прошлом посте про “матчасть”), то вы увидите следующее:
- Вместо RAID-5 для больших пулов на SATA рекомендуется RAID-6 с размером группы в 10-12 дисков.
- Thin Provisioning снижает производительность
- Storage pools снижают производительность по сравнению с Traditional RAID
- Данные и ввод-вывод не распределяются на все диски пула, как вы, возможно, предполагали (см ссылку).
- Рекомендуется использовать drive ownership на только один контроллер
- Нельзя смешивать разные типы RAID в одном пуле
- Существуют ограничения по расширению пула дисками, в идеале расширение должно производиться увеличивая емкость пула вдвое (или, хотя бы, кратно количеству дисков в RAID-группе пула)
- Для пула недоступны reallocate/rebalancing (для MetaLUN вы можете сделать restripe)
- Процесс Tresspassing pool LUN (обычно при переключении LUN-а с одного контроллера на другой, например при выходе одного из них из строя, но, часто, и при других операциях) может приводить к снижению производительности, так как оба контроллера будут пытаться совершать операции ввода-вывода на LUN. Поэтому для pool LUN-ов важно оставаться закрепленными за тем контроллером, на котором они начали работать, иначе потребуется затратная миграция.
- Не рекомендуется использовать thin LUN для задач, требующих высокой производительности по bandwidth.
Я хочу еще раз привлечь внимание к простому факту: дьявол кроется в деталях. Читайте мелкий шрифт.
Вам говорят: Autotiering волшебным образом, автоматически, решит ваши проблемы, без вашего участия, не беспокойтесь об этом. В реальности все не совсем так.
При работе autotiering, значительная часть вашего working set, рабочего набора данных, находящегося в активном использовании в данный момент, должно быть перемещено на быстрое хранилище.
Допустим у вас есть хранилище ваших данных, емкостью 50TB. Правило оценки, которым руководствуются инженеры EMC, что 5% рабочего набора данных пользователя – “горячие данные”. Они перемещаются на SSD (в виде tier или cache). Таким образом вам нужно 2,5TB usable space на SSD, или примерно одна полку дисками SSD по 200GB, может быть больше, в зависимости от типа использованного RAID.
Принято считать, что объем “средней” нагрузки составляет 20% от объема, то есть 10TB, который размещается на дисках SAS или FC.
Остальное размещается на дисках SATA.
Вопрос на 10 миллионов долларов:
Что обойдется дешевле, autotiering и софт кэширования (он небесплатен) плюс 2,5TB SSD, плюс 10TB SAS, плюс 37,5TB SATA, или…
50TB SATA плюс NetApp FlashCache,или, например, 50TB SAS и Flash Cache?
Вопрос на 20 миллионов долларов:
Какая из этих двух конфигураций будет иметь более предсказуемую производительность?
Compellent – это еще одна интересная история.
Большинство обсуждающих Compellent не задумывается о том, что tiering-у у него подвергаются “снэпшоты”, а не непосредственно рабочие данные!
То есть принцип там такой: берется снэпшот, данные делятся на страницы, размеров 2MB (по умолчанию, может быть меньше, но тогда нельзя будет увеличить емкость хранилища). Далее, если оценивается, что обращений на чтение с данной страницы мало, то она переносится на уровень SATA.
О чем не знают большинство интересующихся Compellent-ом:
Если вы изменяете содержимое данных на странице, то происходит это следующим образом:
- Перенесенная на SATA страница, содержащая данные, которые мы изменяем, остается на SATA.
- Новая страница, объемом 2MB создается на Tier1 (SAS/FC), куда реплицируется содержимое страницы с SATA, и где делается запись изменения. Даже если меняется в данных один байт.
- Когда с этой страницы будет сделан снэпшот, то он, в свою очередь, также может быть впоследствии перенесен на SATA, заменив прежнюю.
- ??того: 4MB занятого места для того, чтобы сохранить 2MB данных и один измененный байт.
?? снова укажу: дьявол кроется в деталях. Если вы изменяете свои данные произвольным образом (random), вы получите множество “заснэпшоченных” страниц, и очень неэффективное использование пространства. Вот почему я всегда предупреждаю пользователей, которые интересуются Compellent-ом, задавать эти вопросы, и уяснить себе эти моменты, получив ясное описание от инженеров того, как используется пространство снэпшотов.
На NetApp мы имеем предельно гранулярное пространство, благодаря WAFL. Минимально возможный снэпшот по своему объему очень мал (это указатель, немного метаданных, плюс один измененный блок, размером 4KB). Поэтому на NetApp некоторые наши пользователи могут хранить сотни тысяч снэпшотов на одной системе (например именно так делает один всем известный банк, использующий наши системы хранения).
Гранулярность, на самом деле, это только часть проблемы (производительность – другая ее часть). Сейчас страница у Compellent имеет размер 2MB (можно уменьшить до 512K, но это не позволит изменять размер стораджа). Если они перейдут, как обещают, на 64-битную арифметику в ПО, то они смогут получит размер страницы 64K (это пока не подтверждено), однако тут есть вот какая проблема. Запись этой страницы на RAID может быть двумя способами.
Если это RAID-1, то тогда мы записываем две копии страницы, размером 64KB на каждый из дисков.
Если это RAID-5/6, то тогда нам надо поделить объем записываемой страницы, размером 64KB, поровну между всеми дисками данных, входящих в RAID. Допустим используется RAID-5 в варианте 4d+1p. Тогда на каждый диск в операции записи получится всего 16KB (и меньше). ?? если для RAID-1 размер записи в 64KB это довольно типичный размер записи сегмента в RAID, и запись таким размером достаточно производительна, то для RAID-5/6 это очень маленький кусочек для операции записи, что будет неизбежно отражаться на производительности.
В Data ONTAP мы не перемещаем снэпшоты, поэтому у нас нет такой проблемы, у других же вендоров она очень остра. Получить предсказуемую производительность при использовании autotiering это очень, очень сложная задача. Всякий раз когда мы у клиентов меняем нашими системами сторадж от Compellent, это происходит не потому что им не хватает каких-то фич, а только оттого, что у клиентов с ними проблемы с производительностью. Всякий раз.
Мы ставим 1-2 вида дисков плюс Flash Cache, и проблема решена (в большинстве случаев производительность становится в 2-3 раза выше, как минимум). Часто это получается даже не дороже.
Вот такие дела.
Оставить комментарий