Я работаю с клиентами на AWS уже долгое время, но мне нужно сократить расходы, чтобы продолжать предоставлять свои услуги. На AWS я использую RSync для синхронизации некоторых папок и DRDB для обеспечения высокой доступности с прозрачным отказоустойчивым сервером, всегда имеющим рабочее и готовое к использованию зеркало для каждой клиентской машины.
Теперь я не могу продолжать использовать DRBD, потому что гораздо более дешевое облачное решение, на которое я перехожу, просто предоставляет для каждой машины Ubuntu 14.04 LTS всего с одним разделом и без LVM; эта облачная платформа также стала обязательным требованием для некоторых моих клиентов.
Решение, которое я обдумываю, — это запланировать скрипты оболочки для ежедневного BKP на одной стороне, передать их по SSH на другую сторону и восстановить BKP. Это станет сложным, подверженным ошибкам и потребует много работы по разработке и управлению.
Многие из моих клиентов используют только Wordpress+Mysql и согласны на день задержки. Я же ищу альтернативы, которые обеспечат «высокую доступность», даже если это потребует дня задержки, и при этом мне не придется разрабатывать и управлять скриптами для каждого случая с ограниченным контекстом.
решение1
Если вы действительно не можете эффективно использовать блочное устройство (в этом случае, вероятно, лучше подойдет DRBD, и у вас уже есть опыт работы с ним), GlusterFS может предоставить вам функции репликации, которые вам нужны на уровне файлов.
«Кирпичики» Gluster, в идеале представляющие собой отдельное устройство хранения данных с собственным тонким стеком LVM, заканчивающимся на XFS, на самом деле могут представлять собой любую файловую систему, совместимую с POSIX (или даже просто каталог, а не выделенную файловую систему) на узле.
Эти блоки объединяются в единый «том» с политикой «реплики», которая определяет, сколько блоков будет записано в любой заданный файл — в данном случае, вероятно, реплика 2 или 3. Эти реплики будут стремиться располагаться на разных узлах, если это вообще возможно.
Семантика отказов с Gluster пока не так согласована, как DRBD. Условия split-brain проще реализовать, поскольку репликация данных является обязанностью подключающегося клиента (он отправляет N копий всех записей на каждый узел Gluster, а не записывает на мастер, который затем реплицирует данные). Однако потенциально может быть проще разрешить split-brain с расходящимися данными, поскольку каждый блок представляет собой целую файловую систему с полностью читаемыми данными при использовании репликации.
Он не будет таким быстрым, как DRBD, но, может быть, вам это и не нужно?