Решил на днях поиграться с распределенными кластерными файловыми системами. При обзоре различных вариантов, выбор пал на GlusterFS т.к. судя по имеющимся описаниям, настройка у неё не сложная и можно с наименьшими трудозатратами полчить рабочую версию для экспериментов.
Для начала надо все же отметить, что кластерной в полном смысле этого слова её врядли можно назвать. Скорее всего все же распределенной.
Итак, что же из себя представляет GlusterFS.
Прежде всего, это предоставление локального дискового пространства на серверах, которое можно объединять в стиле рэйд-массива, т.е. зеркало, страйп и т.д. Для этого как на сервер, так и на клиента устанавливается соответствующий пакет. После правки конфигурации и запуска серверных демонов, достаточно просто смонтировать ресурс GlusterFS в локальную папку на системе.
Большим плюсом, по моему мнению, в этой системе является работа с существующей файловой системой, без выделения отдельных разделов диска. Т.е. на сервере достаточно просто указать каталог, который будет использоваться в качестве хранилища данных и все.
В документации "на вскидку" я так и не нашел каким образом определяется объем, например, зеркального тома, построенного на двух серверах с разным объемом дисков, но практика показала, что в качестве объема зеркального тома показывается размер наименьшего из объединенных дисков, что вполне логично. В последних версиях появилась возможность резервирования места, т.е. указания объема диска, который не будет использоваться под GlusterFS, а останется в распоряжении системы.
Так же, "на вскидку" я не нашел информации о том, можно ли работать с выделенными под GlusterFS каталогами "напрямую", а не через примонтированный каталог. Опять же, опытным путем, выяснилось, что в таком случае данные хоть и реплицируются, но как-то ненадежно, непредсказуемо. Впрочем, такой способ обращения к каталогам, выделенным под хранилище, изначально является неправильным.
Увы, но найти более-менее детальную информацию по способу репликации (на уровне блоков или файлов) так же не удалось. Интересовало то, как эта ФС реплицирует, например, большие файлы, к которым происходит множественное обращение с разных хостов. Или по крайней мере, на сколько гарантированно рел-тайм работает репликация, т.е. есть ли гарантия соответствия данных на всех узлах кластера в каждый момент времени. К сожалению, проведенные несколько раз эксперименты поставили этот вопрос под очень большое сомнение. Для проверки, на кластер из 2-х машин с GlusterFS в виде зеркала, был установлен VirtualBox, на общем ресурсе была создана простейшая виртуалка и после её выключения, была произведена попытка запустить её на другом узле. Увы, но файловая система внутри виртуальной машины оказалась полностью испорченной.
Общее впечатление сложилось очень двоякое.
С одной стороны - простота установки и большая гибкость настройки, возможность объединения множества серверов, возможность построения схем а-ля RAID-10 и т.д.
С другой стороны - это все-таки user-mode, т.е. при высоких нагрузках возможны проблемы, а нагрузки как раз присутствуют, особенно на клиентах - ведь по большому счету именно они и осуществляют всю логику работы, а серверные демоны всего лишь предоставляют ресурсы в общий доступ. Именно с последним и связано еще одно обстоятельство - т.к. репликацией занимается клиентская часть, она происходит только при обращении к общему ресурсу, что по моему как-то не совсем правильно...
По поводу быстродействия - чтение / запись отдельных файлов происходят вполне прилично, чего не скажешь о доступе (чтение, удаление) к большому кол-ву файлов - видимо сказывается метод проверки целостности зеркала в момент обращения к файлам.
Как итог - на продакшн под нагрузкой ставить не стал бы. А вот на какую-нибудь веб-ферму с преимущественно статическим содержимым - сомое "оно".
|
Продажа компьютеров и ноутбуков, прайс лист на комплектующие. периферия, мониторы, расходные материалы
