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