Здесь я хочу обсудить органические ограничения RAM кэша, которые можно условно зачитать недостатками.
И раз уж сейчас речь пойдет о недостатках, я хочу сразу оговориться, что они присущи кэшу не какой-то одной системы хранения, а всем классическим СХД. То есть речь пойдет о самом подходе кэширования, который доминировал на протяжении последних примерно двух десятков лет. Однако, прежде чем критиковать что-либо, надо ради справедливости сказать о положительных качествах.
RAM кэш обладает огромной пропускной способностью в десятки ГБайт/сек и умеет
- Кратковременно поглощать и сглаживать нагрузку по записи, которую не могут вовремя переварить диски
- При повторной записи в те области, которые были недавно закэшированы вообще избегает обращений к дискам.
- Когда возникает необходимость записывать данные – упорядочивает операции с дисками таким образом, что бы сократить холостой пробег головок.
- Объединять при записи на отдельный диск по несколько соседних по адресации блоков данных, чтобы сократить общее количество дорогостоящих операций записи.
- Объединять при последовательной записи на RAID группу блоки данных в т.н. страйпы, чтобы избежать дорогостоящих операций read-modify-write.
- Упреждающе считывать блоки данных, когда сервер читает с дисков последовательные цепочки.
- При помощи интеллектуальных алгоритмов удерживать в своей быстрой памяти блоки, которые наиболее вероятным образом будут использованы повторно.
Ну и далее по-мелочи перечислять все алгоритмы не будем, так как об этом я могу написать отдельную статью, если хотите 🙂
Короче, вы скажете, что кэш хорошая штука, и чем же он собственно плох?
Я тоже считаю, что он очень даже хорош, и без него было бы совсем плохо. Правда, львиная доля перечисленных алгоритмов кэширования дает максимальную пользу именно на механических дисках. В самом деле, только п.1 одинаково полезен для обоих типов дисков. Во всех остальных случаях – для флэш дисков это, что называется, nice to have. Хотя, речь, конечно не об этом. Я собирался рассказать о недостатках.
Приступим…
Во-первых, Кэш на базе RAM дорого стоит.
FAST Cache – существенно дешевле в расчете за ГБ
Во-вторых, как не крутись, а RAM кэш энергозависим. Чтобы его защитить, его зеркалируют, и защищают при помощи батареек и даже UPS-ов. Батарейки стоят денег, зеркалирование всех записей грузит межконтроллерную шину, и тоже стоит денег. И все это ради каких-то нескольких ГБайт? На мой взгляд — слишком большая «обвязка». И если, в какой-то момент, у нас будет скомпрометирована защита, кэш записи может отключиться, чтобы обезопасить данные. И тогда приложения ощутят «заметные тормоза».
FAST Cache – использует энергонезависимую Flash память, гораздо проще в аппаратной реализации, и стабилен в работе.
В-третьих — по архитектуре он кэширует все операции записи, если они меньше 2МБ. Было бы кэша много – тогда нет проблем, но кэша, когда он «ест все» много не бывает. В результате кэш записи быстро «забивается» и приступает к сбросу данных на диски.
Дальше начинается интересное. Вот у нас кэш записи заполнился. Надо его сбрасывать на диски. Диски при этом без дела тоже не стоят. Они же заняты обслуживанием операций чтения. Поэтому сброс кэша на диски происходит в конкурентном режиме.
FAST Cache кэширует данные избирательно. Если надо – обращения к большей части адресного пространства он пропускает напрямую на диски
В-четвертых, если заполнение кэша записи достигает 100%, и писать новые данные вообще некуда, то происходит форсированный сброс данных, с приоритетом над остальными операциями. Это значит, что пока кэш записи не будет опустошен процентов этак на 60%, мы новые данные ни читать, ни писать на СХД не можем. Экстренный сброс кэша происходит очень быстро, и это выражается в кратковременной просадке производительности. Приложения как бы «икают» J
Да, утилизация кэша записи на уровне близком к 100% очень дискомфортна для приложений. Комфортным уровнем заполнения кэша записи принято считать 80%, чтобы оставался 20% резерв – страховка на «всякий случай». Я скажу так — кому страховка, а кому и деньги на ветер. Какой может быть выход из ситуации? Установка большего кэша в СХД не всегда работает, и не в любую систему можно его добавить. Да и сколько его можно поставить? Обычно десяток-другой ГБ, и все.
А FAST Cache по своей архитектуре создан так, чтобы оптимально работать всегда на уровне 100%, давая при этом максимальный эффект для производительности. Уже интересно, да?
В-пятых, что у нас с чтением? Ведь его не надо сбрасывать на диски. Значит там RAM кэш работает без недостатков? Увы, нет. Тоже серьезные нюансы.
В обычном кэше нет алгоритма избирательно «не кэшировать» те блоки данных, которые, скорее всего не будут востребованы. В кэш чтения данные попадают автоматом в момент чтения. В итоге полезные данные можно легко «вымыть» оттуда прочитав большой кусок данных один раз (например, во время бэкапа). После чего вероятность того, что в кэше есть что-то нужное резко падает. Полезные данные «вымываются» бэкапной волной.
Данные FAST Cache не вымываются, так как в него попадают данные, которые уже были востребованы не один, а несколько раз.
Суммируем проблемы кэша на базе RAM:
- Дороговизна
- Энергозависимость
- Сравнительно маленький объем
- Нестабильная работа приложений при 100% заполнении кэша
- Эффект «вымывания» кэша чтения
Я думаю, что как раз из этого и происходит Миф №1 (о плохой работе RAM кэша), так что поясню: во всем остальном кэш работает хорошо, и перечисленные проблемы — это общая боль всех СХД.
Кто-то может сказать, что надо вообще отказаться от RAM кэша, и перейти к кэшу на флэш-памяти без недостатков, и с «более умными алгоритмами». Я бы в такие крайности не бросался. Почему? Ну, потому, что у FAST Cache есть несколько недостатков, которые делают его малопригодным к работе без обычного кэша. Так что мы логичным образом подошли к следующему разделу – «О недостатках FAST Cache», в которой я опишу ограничения его возможностей, и то, как эти два вида кэша дополняют друг друга в реальной работе приложений.
