Как сохранить синхронизацию серверов с балансировкой нагрузки даже с удаленными файлами?

я использую OCFS2 с DRBD.

Ресурс DRBD /etc/drbd.d/r0.res:

resource r0 {
    syncer { rate 1000M; }
    net {
        allow-two-primaries;
        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        after-sb-2pri disconnect;
    }
    startup { become-primary-on both; }

    on s1 {
        device      /dev/drbd1;
        disk        /dev/sdc;
        address     ip1:7789;
        meta-disk   internal;
    }
    on s2 {
        device      /dev/drbd1;
        disk        /dev/xvdb2;
        address     ip2:7789;
        meta-disk   internal;
    }
}

/dev/drbd1 форматируется как файловая система ocfs2:

/dev/drbd1   ocfs2   100660180   7427076  93233104   8% /data/webroot

Конфигурация для OCFS2 без кардиостимулятора /etc/ocfs2/cluster.conf:

node:
    ip_port = 7777
    ip_address = ip1
    number = 0
    name = s1
    cluster = ocfs2

node:
    ip_port = 7777
    ip_address = ip2
    number = 1
    name = s2
    cluster = ocfs2

cluster:
    node_count = 2
    name = ocfs2

Статус DRBD можно посмотреть с помощью drbd-overview утилита:

# drbd-overview 
  1:r0  Connected Primary/Primary UpToDate/UpToDate C r---- /data/webroot ocfs2 96G 9.8G 87G 11% 

или из /proc/drbd:

cat /proc/drbd 
version: 8.3.8 (api:88/proto:86-94)
GIT-hash: d78846e52224fd00562f7c225bcc25b2d422321d build by mockbuild@builder10.centos.org, 2010-06-04 08:04:09

 1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r----
    ns:953133955 nr:42207234 dw:1185526354 dr:62396241 al:230084 bm:5853 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

В настоящее время мы также используем rsync, но я не без ума от этого.

Мы экспериментировали с файловый конвейер, который не только синхронизируется между двумя серверами, но мы также можем синхронизироваться с S3, Cloudfiles или другим облачным хранилищем. Это, очевидно, даст нам больше гибкости.

У меня нет никаких настроек конфигурации, которыми можно поделиться, но нам нравится то, что мы видим.

Я не использовал его при настройке сервера, но вы можете попробовать Унисон. Он работает с изменениями с обеих сторон и автоматически синхронизирует вещи, которые не конфликтуют. Я считаю, что он ограничен двумя хостами, поэтому он не сможет масштабироваться по сравнению с вашим текущим решением.

Единственный способ, которым я знаю, как масштабировать более двух хостов, - это настроить NFS или другую совместно используемую / распределенную файловую систему.

Другой вариант - создать «авторитетную» реплику контента отдельно от внешних веб-серверов и убедиться, что все обновления и изменения сделаны на этой реплике.

Затем вы выполняете развертывание с этого сервера на любом количестве внешних серверов по заданному расписанию.

Да, это дополнительная копия контента, но она дает вам некоторые потенциальные преимущества:

1) Контроль времени выхода обновлений

2) Меньшая сложность в обработке разнонаправленной синхронизации между любым количеством серверов.

3) Возможность вносить изменения и просматривать их без ущерба для вашей фронтальной продукции.

Другие варианты - это некоторый тип общего хранилища, распределенный на столько оборудования, сколько вам нужно для надежности, производительности и масштабируемости.

У меня была такая же загадка, и я нашел несколько решений в зависимости от специфики рассматриваемого приложения.

NFS: Хотя NFS или какой-то общий диск, безусловно, будет работать, в моем случае я хотел избежать этого, потому что он создает узкое место на одном компьютере, которое может вывести из строя всю систему. Сильная часть моей причины для балансировки нагрузки - избыточность, и NFS исключает это из уравнения. Хотя, если все остальные варианты не сработают, это может быть единственный вариант.

Файлы БД: В основном я пытаюсь создать приложение для хранения файлов в базе данных. Таким образом, мне не нужно беспокоиться о том, что какой-либо из кластерных веб-серверов должен записывать какие-либо данные. Это кажется лучшим решением, но часто не подходит, если вы не разрабатываете программное обеспечение.

Контроль DNS: Для некоторых сайтов или приложений, которые имеют раздел «администратор», который используют только несколько пользователей (например, блог WordPress), я иногда использую отдельный DNS, указывающий на главный сервер, чтобы гарантировать, что администратор создает записи только на правильном сервере. С небольшими изменениями вы можете перенаправить wp-admin на использование admin dns. Обратной стороной здесь является то, что, хотя передняя часть блога остается сбалансированной и избыточной, раздел администратора зависит от одной системы. Хотя для большинства блогеров это, вероятно, нормально.

Двусторонний rsync: Последний вариант, которого я стараюсь избегать, - это синхронизация в нескольких направлениях. Удаление становится самой большой проблемой здесь, когда rsync трудно узнать, является ли файл новым файлом (и, таким образом, отображается только на одном сервере) или удаленным файлом (и, следовательно, отображается только на одном сервере). Как правило, если мне нужно выполнить многонаправленную синхронизацию, я выбираю конкретную папку, в которой хранятся данные, и удаляю ее из остальной структуры с помощью символической ссылки, а затем выполняю синхронизацию в обоих направлениях без удаления. Большинству приложений никогда не нужно удалять файл, если только они не создают временные файлы, которые, вероятно, в любом случае должны храниться вне структуры вашего сайта. Это все еще может работать с удалением файлов, но я бы все равно попытался настроить таргетинг на конкретные каталоги, в которых вы храните файлы.

посмотрите на LSYNCD присутствует поддержка удаления

1. настроить авторизацию ssh без пароля https://www.shellhacks.com/ssh-login-without-password/

2. настроить lsyncd (по умолчанию также присутствует в репозиториях debian / ubuntu) https://github.com/axkibe/lsyncd