Я ищу совета и совета от людей, которые делали это до меня. У меня есть веб-приложение, размещенное на одном VPS. Сейчас я настраиваю расширенную инфраструктуру и делаю ее высокодоступной.
Я хочу использовать два веб-сервера, на которых размещаются файлы моего веб-приложения + файлы пользователей (например, изображения). Так как мне нужно, чтобы файлы реплицировались на обоих узлах, я намеревался использовать glusterfs (каждый узел будет одновременно работать как gluster-server и gluster-client), и многие здесь рекомендовали его вместо DRBD, если у вас всего 2 узла.
Я успешно настроил его, и он работает как шарм, но у меня есть особая потребность, и я не знаю, как ее достичь и выполнимо ли это с помощью glusterfs или любого другого программного обеспечения.
Как и в любом другом приложении, вы всегда исправляете ошибки и добавляете новые функции, а затем отключаете свой рабочий веб-сайт для обслуживания, чтобы иметь возможность применять исправления и копировать новое содержимое веб-приложения. Есть ли шанс сделать так:
Это сложно с реализацией двухузлового Gluster.
Первая проблема, с которой мы сталкиваемся, - это обработка состояний расщепления мозга, которые вы намеренно создаете. В описанном вами сценарии вы изменяете только один узел, а затем изменяете другой за пределами клиентской репликации Gluster. Сам Gluster обычно не выполняет репликацию между узлами, но полагается на клиентов, которые одновременно записывают и читают все узлы в методе разветвления. Из-за этого, клиент машины в первую очередь несут ответственность за «репликацию», а не за репликацию между серверами. Поэтому нам действительно нужно убедиться, что клиенты всегда могут получить доступ ко всем соответствующим узлам Gluster.
Когда вы подключаете этот том к сети с прикрепленными к нему обоими блоками после того, как вы разбили мозг, вы обнаружите, что Gluster отказывается активировать том до тех пор, пока ты исправить проблему расщепления мозга вручную на кирпичном уровне. Это окажет вам услугу, сообщив вам, что такое расщепленный мозг, но вы уже знаете это, потому что вы были бы непосредственно ответственной стороной. Это связано с тем, что имеется только два узла и нет третьего узла, который мог бы выполнять функцию разрешения конфликтов при анализе того, следует ли перезаписывать данные из «доминирующей» копии. Объемы 3n Gluster могут самовосстановиться в большинстве ситуаций, но не гарантируют желаемого поведения.
Чтобы избежать этого, необходимо серьезное переосмысление стратегии, если вы все еще собираетесь использовать GlusterFS. Gluster не предназначен для преднамеренного разделения мозга и не является традиционной системой аварийного переключения. Он разработан для одновременного доступа ко всем узлам и может справляться с отказом узла, используя правило большинства (или продолжительное ручное вмешательство в автономном режиме).
Разумное решение GlusterFS:
Вы можете создать новый том GlusterFS на своих узлах и смонтировать его на своем узле, на который вы собираетесь записывать свой новый веб-контент, после остановки обслуживания для него через HAproxy. Затем переключитесь на этот узел и смонтируйте тот же том GlusterFS на другом узле. После завершения выбросите старый том Gluster.
Это изменит ваши шаги таким образом:
1) Поскольку я собираюсь использовать HaProxy в качестве балансировщика нагрузки, я могу изменить статус node1 на обслуживание и позволить node2 обрабатывать весь трафик.
2) Создайте новый том GLusterFS из новых блоков на обоих узлах и смонтируйте этот том в каталоге app / web узла в режиме обслуживания, предварительно отключив исходный том.
3) Скопируйте все соответствующие новые и неизмененные данные в этот новый том Gluster.
4) От HaProxy отключите node2 для обслуживания и возьмите node1 для обработки трафика.
5) Смонтируйте новый том Gluster на узле 2, сначала отключив старый
6) позвольте сервисам балансировки нагрузки HAproxy снова, так как у нас снова будет рабочий активный / активный кластер.
7) Избавьтесь от старого тома GlusterFS, когда он нам больше не нужен.
Это гарантирует, что вы будете поддерживать свою службу в сети и не получите ужасного расщепления мозга. Что касается ваших кирпичей: кирпич - это всего лишь каталог, и он не обязательно должен быть отдельной файловой системой. Вы можете разместить новый кирпич в той же файловой системе, что и старый, просто используя другой каталог в корне этой файловой системы. Таким образом, вам не понадобится много места на диске для обновления онлайн-сервиса.
Альтернативное решение:
DRDB обрабатывает данные в кольце репликации сервер-сервер, и вы можете заставить один узел произвольно реплицироваться на другие. Это не так хорошо для кластеров с активной / активной балансировкой нагрузки, так как вам придется использовать файловую систему, такую как OCFS2, поверх нее. Однако это традиционная система репликации, которая с радостью будет соответствовать вашему текущему плану.
Разъяснение:
Для реализации плана GlusterFS, который я описал выше, не требуется кластер из трех узлов. Два узла подойдут.