FAST Cache: мифы, архитектура, применение. Часть 2.5

Продолжаем серию статей о FAST Cache.
В третьей части я собирался более подробно обсудить архитектуру кэша на флэш дисках и ее ограничения. Но прежде чем двигаться дальше, я решил подвести этой статьей промежуточный итог.
Это вызвано тем, что я получил от читателей вопросы, которые не могут быть оставлены без внимания.

1. «И что из всего этого следует?»
2. «Почему я противопоставляю эти два вида кэша?»
3. «Из того, что заявлено в первых двух частях, следует ли что надо отказаться от RAM кэша в пользу FAST кэша?»

Я хочу, чтобы вы сделали выводы сами, когда изложу картину в целом.
Что я тут показываю, так это то, что эти два кэша работают очень по-разному, и каждый имеют свои слабые и сильные места.
В идеале — должно получиться, что слабые места одного компенсируются сильными местами другого. Получится это или нет — увидим. Я кроме всего прочего, начал эту серию чтобы систематизировать свои знания и опыт.

RAM cache — это очень хорошо, и за несколько десятилетий люди научились из него выжимать пользу по максимуму. Именно поэтому, он работает в большинстве систем более-менее одинаково.

Кстати, регулярно во время технических семинаров встает вопрос — почему вендоры не ставят больше кэша в свои СХД? Оперативная память уже достаточно дешевая, так что, в самом деле, можно же было бы поставить, жалко, что ли?

Ну, во-первых – много памяти (сотни ГБайт) в СХД ставят. Обычно – в High-End, но почему-то не в midrange. Кроме стремления удешевить midrange, у этого явления есть еще две причины – в high-end кэш очень интенсивно используется под репликацию и разные вкусности, которые в midrange делаются на дисковом уровне, а еще – в High-End вычислительной мощности на один контроллер больше, и алгоритмы распараллеливания работы – другие. А для работы с кэшем, вычислительная мощность нужна.

Так что это не заговор производителей. Ведь если поставить в СХД среднего уровня много-много RAM кэша, то это может и не дать реального эффекта. По крайней мере, в СХД midrange класса. Я уверен, что лабораторные эксперименты проводились всеми вендорами играющими на этом рынке.
Ведь кэш — всего лишь уровень хранения. А передачей данных занимается процессор. Наверное, поэтому performance инженеры EMC на этот счет скептичны. Говорится, что есть некий баланс вычислительной мощности процессоров и объема кэш памяти. И слабому процессору много кэша — деньги на ветер. В этом есть логика. Ведь алгоритмы RAM кэша интенсивны по процессорной мощности. Например, каждый запрос на чтение с хоста сопровождается поиском нужного блока в кэше чтения.
Не буду претендовать на истину в последней инстанции, но, по-моему, это работает так:
Есть таблица индексов кэша с адресами блоков, которые в данный момент закэшированы. И вот, приходит запрос на чтение блока, встает в ожидание, где то в буфере, берется таблица закэшированных адресов и делается XOR по каждому адресу в таблице, в надежде, что хотя бы в какой-то строчке будет ноль. То есть — совпадение адресов запрошенного блока и закэшированного.

Тогда мы сможем взять в этой строке указатель в кэш адрес, чтобы прочитать оттуда данные. Спустя какое то время если мы нужный блок не нашли — время потрачено зря. Не буду вдаваться в подробности, но по моему очевидно, что чем больше кэш, тем больше нагрузка на ЦП и тем дольше задержка при поиске данных в кэше. И я подозреваю, что подобным поиском данных в кэше одного контроллера может заниматься только одно ядро. В итоге с одной стороны — рост, с другой — рост задержки и нагрузки на ЦП пропорционально размеру кэша.

Доказательством моих мыслей может считаться время отклика кэш памяти на чтение принятое в различных массивах за норму.

Midrange — 0.1 мс High-End — 0,5 мс.
5 раз разница не слабая, согласитесь.

И это при том, что в High-End вычислительная мощность в разы больше (и говорят что и алгоритмы более совершенны).

И вот, допустим, мы все же наращиваем кэш физически, в надежде получить повышение производительности. Получить его не за счет улучшенных алгоритмов кэширования, а за счет голого железа.
Если мы кэш наращиваем в разы, оставляя тот же процессор, и шину памяти, то получаем в итоге все меньшую отдачу. А загрузка процессора в это время растет, и шина памяти может тоже стать узким местом.
Думаю, что это справедливо для всех производителей.
Очевидно, что для радикального прорыва в midrange необходимо менять подход к кэшированию, чем, собственно лидирующие производители СХД и занялись.

В следующих статьях этой серии:

Часть 3. Архитектура FAST Cache
Флэш диски SLC. Почему не MLC?
RAID-1 на флэш дисках. Почему не RAID 5?
Режим работы только FAST Cache – только Read/Write.Куда пропал режим Read Only?
Какие данные попадают и удерживаются в FAST Cache?
Работа FAST Cache при 100% загрузке.
Поведение FAST Cache во время Failover/Failback

Часть 4. Управление FAST Cache.
Управление и мониторинг производительности FAST Cache
Старое и новое поведение FAST Cache при отказе флэш диска
Разогреваем FAST Cache подручными средствами

Часть 5. Границы применения нулевого уровня хранения

Часть 6. Сайзинг систем хранения с учетом кэша на флэш дисках

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s