Использование GlusterFS для простой репликации

Мне, наконец, удалось решить эту проблему, используя GlusterFS в обоих случаях. Некоторые вещи узнали в процессе:

• Сначала я попробовал общую настройку RAID 1. Основная проблема заключается в том, что клиент всегда использует tcp для связи с обоими серверами, даже если один из них находится на одном компьютере. Поэтому мне нужно изменить конфигурации клиента, чтобы заменить локальный том tpc на том с прямым доступом (хранилище / posix).
• Чтобы не перегружать сетевую ссылку, каждый читающий клиент использует локальное хранилище с директивой option read-subvolume. Конечно, для сохранения целостности RAID1 GlusterFS всегда проверяет и другие тома, но сам файл извлекается непосредственно с диска.
• Производительность хорошая, но клиентский процесс кажется объятием памяти. Я думаю, это связано с объемом быстрого чтения, мне нужно продолжить расследование

Измененная конфигурация клиента:

# Server1 configuration (RAID 1)
volume server2-tcp
    type protocol/client
    option transport-type tcp
    option remote-host server2
    option transport.socket.nodelay on
    option transport.remote-port 6996
    option remote-subvolume brick1
end-volume

volume posix-local
    type storage/posix
    option directory /shared
end-volume

volume locks-local
    type features/posix-locks
    subvolumes posix-local
end-volume

volume brick-local
    type performance/io-threads
    option thread-count 8
    subvolumes locks-local
end-volume

volume mirror-0
    type cluster/replicate
    option read-subvolume brick-local
    subvolumes brick-local server2-tcp
end-volume

.....

Отвечая на оба моих вопроса:

Он будет дублировать файлы в одном ящике?

Нет, fs монтируется с помощью FUSE. Текущая строка / etc / fstab:

/etc/glusterfs/client.vol / mnt / shared glusterfs по умолчанию 0 0

Вместо этого должен ли я использовать файловую систему напрямую, локально записывая в / shared? Работает ли репликация таким образом без подключения клиента?

Нет, всегда используйте смонтированные тома для чтения / записи, использование напрямую файловой системы может привести к несогласованности.

На самом деле Gluster идеально подходит для этого сценария. Вы получаете двунаправленную репликацию и возможность монтировать файловую систему с любого компьютера, что дает вам (теоретически) вдвое большую пропускную способность ввода-вывода, чем у NFS, и активное переключение при отказе в случае отказа одного из устройств.

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

Было бы намного проще настроить rsync для активного зеркалированияили просто настроить общий ресурс nfs и заставить их работать с одного и того же диска.