Возможности кеширования в GlusterFS

Реализовывать задуманную идею оптимального кеширования сетевой файловой системы было решено на базе GlusterFS,в первую очередь потому, что она имеет открытый исходный код, а во-вторых - имеет модульную архитектуру построенную на трансляторах, следовательно для изменения логики работы не придется менять код “ядра” приложения.

Прежде всего, что уже умеет GlusterFS?

Кеширование

В релизной версии GlusterFS поставляется транслятор io-cache, который при добавлении на сервер обеспечивает серверное кеширование, а на клиент - клиентское. Транслятор обрабатывает обращения к файлам и кеширует данные в страницах памяти. Причем, можно настроить, как размер кеша, так и время, спустя которое данные априори считаются невалидными. Страницы транслятора имеют размер 128Кб (меняется одним параметром в исходниках), что обуславливает хорошую работу на данных, у которых операций чтения гораздо больше, чем записи, достигая максимум улучшения производительности на файлах только для чтения. Однако, из-за большого рамера страницы, при записи приходится ревалидировать всю страницу, из-за чего улучшения производительности и нагрузки на сеть не следует. Если же есть желание изменить логику и алгоритм кеширования - придется переделывать транслятор полностью, просто добавить обертку вызовов не удастся. Если же писать с нуля свой транслятор - могут возникнуть проблемы с выделением памяти, которые здесь уже сведены к минимуму. В общем, выбор - что же делать с кодом - оставим на будущее.

Атрибуты

Атрибуты (расширенные) передаются между трансляторами GlusterFS в виде структуры типа dict_t, к которой в большинстве случаев у меня не удалось получить доступ через python-транслятор. Возможно, придется не только досконально изучить строение этой структуры, но и немного подправить коннектор между Python и Си, чтобы научить его получать доступ к полям структуры. На данный момент можно без особых усилий получить доступ к именам расширенных атрибутов. (TODO: Разобраться как получать весь список атрибутов (некоторые остаются скрыты, пока не запросишь по имени)). Теоретически (а это будет правильно и с точки зрения ревалидации кеша), можно запрашивать все или конкретные расширенные атрибуты каждый раз при обращении к файлу.

Выбор кеша

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

• Клиент знает о том, как он собирается работать с файлами. В таком случае, он заранее устанавливает необходимый алгоритм работы кеша параметром в конфигурации монтирования. Чревато потерями производительности при неоднородной работе клиента, а так же переподключениями при смене режима работы. А так же обязывает пользователя заранее планировать свою работу и вдаваться в подробности работы его системы с файлами, что не всегда возможно.

• Клиент имеет несколько кешей, реализующих каждый свою логику. Тогда при каждом следующем запросе файла клиент (в зависимости от атрибутов) выбирает в какой из кешей его поместить. Такой кеш занимает больше памяти, либо каждая его часть будет меньше размером, что может оказаться нерациональным при неравномерной работе клиента по разным сценариям (можно оставить возможность выбора пользователю в каких пропорциях разделять кеш). Так же возникает проблема согласованности различных частей кеша на клиенте. Логично, что если отображать файлы в кеш только в зависимости от их атрибутов, а не операции, обратившейся к нему (чтение или запись), то проблема согласованности сужается только для случая смены атрибутов. Тогда можно принять, что смена атрибутов доступа явление редкое - и в таких случаях ревалидировать файл уже в новый кеш, данные в старом считая невалидными. Если же смена атрибутов явление не такое редкое - непонятно что делать. Скорее всего, вариант с отображением файлов в кеш согласно атрибуту - вообще провальный в такой ситуации и его не надо использовать.

Вывод

В связи с вышеизложенными наблюдениями, появилась идея сделать:

• Транслятор с несколькими логиками и пространствами кеширования, среди которых он сможет выбирать необходимый, согласно расширенному аттрибуту.
• За основу взять io-cache транслятор, связав новые с существующей реализацией страниц памтяи на Си, либо сделав всю работу с памятью на Python (если не будет падения скорости доступа)
• Каждый раз при поиске файла запрашивать его расширенный атрибут (конкретный) и устанавливать флаг для режима работы.