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

Здесь я хочу обсудить органические ограничения RAM кэша, которые можно условно зачитать недостатками.

И раз уж сейчас речь пойдет о недостатках, я хочу сразу оговориться, что они присущи кэшу не какой-то одной системы хранения, а всем классическим СХД. То есть речь пойдет о самом подходе кэширования, который доминировал на протяжении последних примерно двух десятков лет. Однако, прежде чем критиковать что-либо, надо ради справедливости сказать о положительных качествах.

RAM кэш обладает огромной пропускной способностью в десятки ГБайт/сек и умеет

  1. Кратковременно поглощать и сглаживать нагрузку по записи, которую не могут вовремя переварить диски
  2. При повторной записи в те области, которые были недавно закэшированы вообще избегает обращений к дискам.
  3. Когда возникает необходимость записывать данные – упорядочивает операции с дисками таким образом, что бы сократить холостой пробег головок.
  4. Объединять при записи на отдельный диск по несколько соседних по адресации блоков данных, чтобы сократить общее количество дорогостоящих операций записи.
  5. Объединять при последовательной записи на RAID группу блоки данных в т.н. страйпы, чтобы избежать дорогостоящих операций read-modify-write.
  6. Упреждающе считывать блоки данных, когда сервер читает с дисков последовательные цепочки.
  7. При помощи интеллектуальных алгоритмов удерживать в своей быстрой памяти блоки, которые наиболее вероятным образом будут использованы повторно.

Ну и далее по-мелочи перечислять все алгоритмы не будем, так как об этом  я могу написать отдельную статью, если хотите 🙂

Короче, вы скажете, что кэш хорошая штука, и чем же он собственно плох?

Я тоже считаю, что он очень даже хорош, и без него было бы совсем плохо. Правда, львиная доля перечисленных алгоритмов кэширования дает максимальную пользу именно на механических дисках. В самом деле, только п.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:

  1. Дороговизна
  2. Энергозависимость
  3. Сравнительно маленький объем
  4. Нестабильная работа приложений при 100% заполнении кэша
  5. Эффект «вымывания» кэша чтения

 Я думаю, что как раз из этого и происходит Миф №1 (о плохой работе RAM кэша), так что поясню: во всем остальном кэш работает хорошо, и перечисленные проблемы — это общая боль всех СХД.

Кто-то может сказать, что надо вообще отказаться от RAM кэша, и перейти к кэшу на флэш-памяти без недостатков, и с «более умными алгоритмами». Я бы в такие крайности не бросался. Почему? Ну, потому, что у FAST Cache есть несколько недостатков, которые делают его малопригодным к работе без обычного кэша. Так что мы логичным образом подошли к следующему разделу – «О недостатках FAST Cache», в которой я опишу ограничения его возможностей, и то, как эти два вида кэша дополняют друг друга в реальной работе приложений.

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s