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