Сейчас у меня есть веб-приложение, работающее на одном VPS, и я хочу масштабировать его и сделать его HA с помощью двух VPS (от разных поставщиков), которые работают вместе с использованием балансировщика нагрузки.
Я успешно поставил MySQL Master-Master Replication, и мне удалось настроить HaProxy в качестве балансировщика нагрузки, но теперь мне нужно настроить механизм синхронизации файлов / папок, чтобы сохранить оба, поэтому, когда файл изменяется или добавляется на одном сервере, он получает добавлено или обновлено на втором.
Я искал программы для этого, и, похоже, самые известные из них - GlusterFS и DRBD. (Ceph выглядит очень сложным)
Я попытался настроить эти два и поиграть с ними, но мне не удалось заставить их работать.
Кто-нибудь знает хорошее руководство о том, как настроить двойную первичную репликацию на одном из них?
PS: Я использую Ubuntu на своем VPS
GlusterFS - это выход из двух. DRDB чаще всего используется для активного / пассивного аварийного переключения.
При использовании Gluster важно учитывать, что все клиентские узлы должны быть напрямую подключены ко всем серверным узлам, и что все серверные узлы напрямую подключаются ко всем серверным узлам. Хотя Gluster может реплицироваться между узлами сервера, его распространение данных контролируется и управляется в первую очередь на клиенте. Клиенты несут ответственность за разветвление данных по узлам сервера, поскольку они подключаются ко всем соответствующим узлам одновременно. В этом случае наиболее важно учитывать сеть клиент> сервер.
Поскольку в этом случае вы будете использовать свои серверы в качестве клиентов (приемлемая практика для небольших кластеров), вам нужно только убедиться, что эти узлы имеют хорошую сеть хранения между ними.
Я настоятельно рекомендую три узла Gluster по нескольким причинам. Во-первых, вы не можете автоматически решать сценарии с разделенным мозгом только с двумя узлами. Вам нужен третий, чтобы обеспечить правило большинства, когда один узел хранения имеет недопустимые данные или находится в автономном режиме. Во-вторых, ваша целостность данных будет лучше, поскольку вы можете использовать репликацию 3n или репликацию 2n-a (два узла с арбитражем).
Для ваших целей вероятной целью будет 2n-репликация. Это ведет себя как трехузловая репликация, но работает примерно так же, как двухузловая репликация (то есть в большинстве случаев лучше). В простейшей форме это включает два обычных узла данных и один узел-арбитр, который содержит только метаданные, предназначенные для измерения целостности двух других узлов. В результате узлу-арбитру требуется всего 4 КБ пространства для каждого файла, который он отслеживает, и он требует гораздо меньшей полосы пропускания, чем два полных узла хранения. Что нужно учитывать.
Наконец, GlusterFS - это слой над вашими файловыми системами, который он использует для данных, поэтому не взаимодействуйте с этими файловыми системами сразу после установки GlusterFS. Он называет эти файловые системы кирпичиками, однако они не обязательно должны быть отдельными файловыми системами. Это могут быть каталоги в одной файловой системе (не совсем рекомендуется) или что-то вроде подтомов BTRFS (более рекомендуется). В общем, любая файловая система, совместимая с POSIX, будет служить вспомогательным кирпичиком.
Идентичные блоки можно создать на узлах, а затем объединить в объем. Том - это экспорт на несколько серверов, который ведет себя так же, как NFS. На этом этапе все, что вам нужно сделать, это смонтировать этот экспорт.
Краткий документ по арбитражным томам: https://gluster.readthedocs.io/en/latest/Administrator%20Guide/arbiter-volumes-and-quorum/
Отличное руководство по настройке GlusterFS в простом кластере 2n находится здесь: https://www.digitalocean.com/community/tutorials/how-to-create-a-redundant-storage-pool-using-glusterfs-on-ubuntu-servers