Стоит ли хранить тома Docker в glusterfs?

В настоящее время я думаю о переносе некоторых наших серверов и приложений в среду coreOS . Одна из проблем, которые я вижу здесь, - это управление постоянными данными, поскольку coreOS не обрабатывает тома Docker при перемещении контейнера на новую машину. После некоторых исследований я обнаружил glusterFS, которая претендует на роль кластерной файловой системы, которая может решить все мои проблемы.

Моя текущая идея такова: у меня есть контейнер glusterFS, который работает как привилегированный контейнер на каждой из моих машин с операционной системой coreOS и, например, предоставляет хранилище /mnt/gluster. В моем Dockerfiles я указываю, что все мои тома должны быть подключены по этому пути.

Следующее, что я рассмотрел, было то, какие контейнеры должны получать свои собственные тома, а какие - совместно использовать один. Например, каждый mysqlконтейнер получит свой собственный том, поскольку он способен самостоятельно обрабатывать репликацию. Я не хочу возиться с этим. Веб-серверы, обслуживающие один и тот же веб-сайт, будут правильно использовать один и тот же объем для таких вещей, как «загруженные пользователем изображения» и т. Д., Поскольку они не могут реплицировать эти данные.

Кто-нибудь пробовал что-то подобное или я что-то пропустил?

Мы развернули аналогичную настройку с Atomic ( http://www.projectatomic.io/ ) вместо CoreOS в реплицированной нераспределенной системе хранения GlusterFS с тремя наборами replica-2. Это работает очень хорошо.

Тем не менее, вам необходимо помнить некоторые особенности GlusterFS. Как уже упоминал Брайан, Gluster ставит во главу угла последовательность и надежность. Чем чаще происходят изменения, тем больше происходит репликация. Это сильно и, я имею в виду, ОЧЕНЬ сильное давление на вашу систему.

Позаботьтесь о том, чтобы ваша подсистема ввода-вывода была быстрой (да, это хранилище), подключайте узлы Gluster с помощью самых быстрых доступных сетевых подключений. Если у вас есть только GBit, агрегируйте! И последнее, но не менее важное: система хранения должна обладать серьезными вычислительными возможностями, Gluster выполняет много вычислений, чтобы проверить ее состояние. При этом, даже при высокой нагрузке, Gluster поставляет.

Пересмотрите свою стратегию MySQL. Gluster выполняет репликацию за вас, а также обеспечивает балансировку нагрузки при доставке. Это может быть на самом деле быстрее использовать Gluster.

Использование glusterfs будет зависеть от используемого вами хранилища. Как кластерная файловая система, она предназначена для кластеризации физического хранилища, поэтому она выглядит как один большой непрерывный том. В этом официальном руководстве по быстрому старту есть хорошее объяснение этого процесса.

В случае, если ваша установка использует два или более отдельных внутренних сервера хранения или что-то подобное для хранения всех томов докера, использование glusterfs или какой-либо другой аналогичной параллельной файловой системы может дать существенные преимущества в производительности. Если это так, вы можете также рассмотреть возможность использования Luster , который широко используется в качестве параллельной файловой системы в сообществе HPC.

С учетом вышесказанного, настройка, отладка и настройка параллельных / кластерных файловых систем могут занимать много времени, требуя большого опыта, терпения и иногда готовности к перезагрузке с самого начала. Было бы разумно убедиться, что преимущества в производительности, предлагаемые параллельной файловой системой, стоят того количества усилий, которое требуется для его настройки и обслуживания.