Практический опыт одного расширения гибридной СХД

На улице День Знаний и это неплохой повод возобновить мой техноблог.

Все это время я часто задумывался о том, каким мой блог должен быть, чтобы его было интересно читать и необременительно писать, и оптимальным видится блог, где я просто делюсь практическим опытом из повседневной работы.

Вот, например, недавно с заказчиком решали такую задачку.

Дано:

СХД VNX, в которой стоит 2x200GB FAST Cache,  25x900GB SAS 10k RAID5(4+1), 24x2000GB NL-SAS RAID6(6+2), ну и Hot Spare сколько положено (т.е. 1:30, округляя вверх). Есть еще 5 NL-SAS дисков свободные.

Их в пул не добавляли, потому что RAID 6(6+2) на них не соберется, а RAID6(2+2) не хочется.

Сделано два изолированных пула на каждом типе дисков. Для того, чтобы «некритичные» приложения не мешали «критичным».

Контроллеры утилизированы на 10-20%.

FAST Cache диски утилизированы на 50-60%, FAST Cache Hit – 80-90%, причем и на чтение и на запись.

fast cache hits

Механические диски утилизированы на 10%, но с редкикии регулярными всплесками  до 50+% у дисков NL-SAS.

Периодически write кэш системы начинает захлебываться, и утыкается в 100%, начинаются Forced Flushes, и вся система от этого «икает». Т.е. все луны, которым надо что-то записать ждут когда пройдет сброс кэша.

heatmap

Причина – периодическая большая запись в медленный пул, что было видно из статистики по Forced flushes.

 

Проведя Midtrend-анализ, мы запланировали апгрейд – расширить FAST Cache, добавить 15 быстрых дисков 900ГБ и 3 NL-SAS для объема, т.к. было запланирован перенос части данных с другой, старой СХД, где лежит файловая помойка.

3 NL-SAS вместе с имеющимися 5 такими же дисками можно организовать в RAID6(6+2).

Цель — увеличить FAST Cache, чтобы больше записей приходило сразу на флэш, добавить быстрые диски для горячих данных, а медленные диски — для холодных.

Вопрос в том, как оптимально распределить новые диски между пулами, и в каком порядке (по шагам) производить модернизацию?

Решение:

Очевидно, что сначала нужно расширить FAST Cache, чтобы последующее расширение пула проходило при минимальной нагрузке на диски.

FAST Cache в VNX расширяется только методом его пересборки (сначала его полностью очищаем, а затем создаем заново).

Расширение FAST Cache лучше делать в ночное время, чтобы не портить жизнь приложениям.

Далее дать увеличенному FAST Cache время на прогрев. День как минимум.

Увеличение пулов тоже лучше делать вечером, т.к. перераспределение данных между дисками тоже создаст определенную дополнительуню нагрузку на диски.

Для того, чтобы тиринг работал, нужно оставить свободным 10% полезного места в каждом пуле.  Это best practice.

Расширение медленного пула медленными дисками малопрактично, т.к. система будет по прежнему «икать» от переполнения кэша.

Лучше всего расширить обоими типами дисков 1 пул, затем на него перенести все данные СХД, а освободившиеся из пустого пула диски тоже добавить в увеличенный пул.

На все это требуется время. Каждый шаг требует переноса или перераспределения данных, поэтому нужно везде смотреть статус пулов, статус миграции лунов и загрузку Write Cache.

Перед тем, как добавлять NL-SAS диски решили проверить на целостность.

Ведь мало кто знает, что unbound диски система не проверяет до тех пор, пока из них не создадут RAID группу и не сделают на них LUN.

Поэтому решили сначала сделать RAID группу, и дождаться когда SNIFFER проверит каждый блок диска на целостность. Проверка прошла для всех дисков успешно. Это было видно из логов SPCollect, т.к soft media errors там не было ни одной за время проверки. Можно добавлять диски в пул.

Добавили в пул все свободные NL-SAS диски. Подождали когда пройдет rebalancing пула.

Добавили в пул все свободные SAS диски. Подождали когда пройдет rebalancing пула.

Далее перетаскиваем данные из освобождаемого пула.

Создаем для этого на target пуле, который был расширен до двухуровневого, луны нужного размера на нужном нам уровне(!!!!). Это жизненно необходимо для того, чтобы производительность приложений, которые мы перетаскиваем, не упала.  При этом для целевых лунов устанавливаем Tiering Policy “No Data Movement”, чтобы система не начинала перемещать блоки прежде времени.

Осторожно мигрируем луны. Лучше переносить их поочередно, или хотя бы небольшими группами. Потому что миграция идет через write cache.

Во время миграции днем приоритет миграции устанавливаем на таком уровне, чтобы write cache успевал сбрасыватсья на диски и dirty pages не увеличивались до 100%. Смотрим график Analyzer, для контроля.

Ночью приоритет миграции самых больших лунов устанавливаем на ASAP, чтобы отработать в это время по максимуму без ущерба для пользователей.

Таким образом, перетаскиваем все луны из source пула.

Разбираем этот пул и следующим вечером добавляем все его диски в расширенный пул, где у нас хранятся все данные.

Проводим ревизию политик для всех лунов в едином расширенном пуле.

Для лунов, где производительность критична – ставим политику Highest Tier.

Для лунов, где производительность некритична – ставим политику Auto Tier.

Политику Lowest Tier я в данном случае применять не рекомендую, т.к.  есть риск, что на медленных дисках окажутся блоки, из за которых потом забьется write cache. Auto Tier справится с этой задачей лучше, и сам определит какие данные нужно хранить на нижнем уровне.

Расписание тиеринга лучше настроить на ночную работу, с учетом времени, когда делается ночная аналитика. Автотиеринг лучше делать тогда, когда аналитика отработала, если есть такая возможность.

В общем, гибридные системы хранения, будучи призванными облегчать жизнь администраторам, не снимают всего бремени планирования и оптимизации СХД.

Многие гибридные системы, присутствуя на рынке сравнительно недолгое время (ну что такое даже 5-6 лет), и не имеея общего стандарта в индустрии, обладают своими характерными особенностями, которые нужно учитывать при внедрении. Старые best practices для гибридных систем либо работают по другому, либо не работают, а новые либо не сформировались, либо мало известны даже среди опытных ИТ специалистов.

Хотя каждый подобный проект имеет свои уникальные черты, но есть и общие принципы, которые полезно соблюдать, когда имеешь дело с гибридными системами.

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

Всего наилучшего!

Денис Серов

Практический опыт одного расширения гибридной СХД: 2 комментария

  1. Денис, а почему сначала заказчик практиковал два пула для разделения нагрузки по шпинделям (не доверял FastVP?), а потом все же решил все слить в один пул?
    Это основывалось на каком-то опыте заказчика или было «внешней» рекомендацией вендора? Если первое, то что за опыт? Если второе, то что явилось основанием для такой рекомендации.

    • Потому что хотели разделить критичные и некритичные приложения по производительности «аппаратным путем». Дело в том, что этот путь на пулах работает со значительными оговорками, которые создают больше сложностей в управлении, нежели реальной пользы

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s