Действительно ли это - хорошая идея сохранить объемы Докера в glusterfs?
Я в настоящее время думаю о миграции некоторых наших серверов и приложений к coreOS среде. Одной из проблем, которые я вижу здесь, является управление персистентными данными, поскольку coreOS не обрабатывает объемы Докера при перемещении контейнера в новую машину. После некоторого исследования я нашел glusterFS, который утверждает, что был кластерной файловой системой, которая могла решить все мои проблемы.
Моя текущая идея - это: у Меня есть glusterFS контейнер, который работает как привилегированный контейнер на каждой из моих coreOS машин и выставляет устройство хранения данных, /mnt/gluster, например. В моем Dockerfiles я указываю, что все мои объемы должны быть смонтированы на этом пути.
Следующая вещь, которую я рассмотрел, была, какие контейнеры должны получить свои собственные объемы и которые должны совместно использовать тот. Например, каждый mysql контейнер получил бы свой собственный объем, поскольку он может обработать репликацию отдельно. Я не хочу бездельничать с этим. Веб-серверы, служащие тому же веб-сайту, правильно использовали бы тот же объем для материала как "пользовательские загруженные изображения", и т.д. поскольку они не могут копировать те данные.
Кто-либо попробовал что-то вроде этого или является там чем-нибудь, что я пропустил?
Использование glusterfs будет зависеть от бэкэнд хранилища, который вы используете. Как кластерная файловая система предназначена для кластеризации физического хранилища, чтобы оно выглядело как один большой непрерывный том. В этом официальном кратком руководстве есть хорошее объяснение этого процесса.
Если ваша установка использует два или более отдельных внутренних сервера хранения или что-то подобное для хранения всех томов докеров, тогда использование glusterfs или другой подобной параллельной файловой системы может дать значительные преимущества в производительности. В этом случае вы также можете рассмотреть возможность использования Lustre , который широко используется в качестве параллельной файловой системы в сообществе HPC.
При этом настройка, отладка и настройка параллельных / кластерных файловых систем могут трудоемкая задача, требующая большого опыта,терпение, а иногда и желание начать с самого начала. Было бы разумно убедиться, что преимущества производительности, предлагаемые параллельной файловой системой, окупаются затраченных усилий на ее настройку и поддержку.
Мы развернули аналогичную установку с Atomic ( http://www.projectatomic.io/ ) вместо CoreOS в реплицированной нераспределенной системе хранения GlusterFS с тремя Реплика-2 набора. Это работает очень хорошо.
Однако вы должны помнить о некоторых особенностях GlusterFS. Как уже упоминал Брайан, Gluster превыше всего ставит последовательность и надежность. Чем чаще происходят изменения, тем больше происходит репликация. Это оказывает сильное, я имею в виду ОЧЕНЬ, давление на вашу систему.
Позаботьтесь о том, чтобы ваша подсистема ввода-вывода была быстрой (да, это хранилище), соедините узлы Gluster с самыми быстрыми доступными сетевыми соединениями. Если у вас только GBit, агрегируйте! И последнее, но не менее важное: система хранения данных должна обладать серьезной вычислительной мощностью, Gluster выполняет множество вычислений для проверки ее состояния. При этом Gluster работает даже при большой нагрузке.
Пересмотрите свою стратегию MySQL. Gluster выполняет репликацию за вас, а также обеспечивает некоторую балансировку нагрузки при доставке. На самом деле было бы быстрее использовать Gluster.