Why are GlusterFS replicated volumes not recommended for Hosts in different datacenters?
Any tutorial I can find about GlusterFS replicated volumes assumes that both (all) bricks are on the same private network which then also leads to the conclusion they must be in the same datacenter.
e.g. "The problem is when the storage you would like to replicate to is on a remote network, possibly in a different location, GlusterFS does not work very well. This is because GlusterFS is not designed to work when there is a high latency between replication nodes." is a quote from https://github.com/GlusterFS/Notes
Also https://gluster.readthedocs.io/en/latest/Administrator%20Guide/Geo%20Replication/ says that replicated volumes are not meant for geo-replication however the real "geo-replication" mechanism in GlusterFS only creates read-only slaves which won't work in every scenario.
So the question is, why isn't it recommended in general, since I haven't found a single example of replicated volumes for hosts on different networks, yet even different datacenters.
I can also explain why I want to use replicated volumes. I have a vServer (OpenVZ) in a datacenter in Frankfurt, Germany and a second in Nuremburg, Germany. Both have multiple peerings with DE-CIX, Deutsche Telekom, and so on and the latency between the vServers is < 4 ms which in my opinion cannot be considered high latency, whatever the definition for that might be in the case of GlusterFS.
I am running iRedmail services on both servers and MariaDB is replicated in Master-Master replication storing only the mail configuration. The mail storage is on disk and I am using GlusterFS replicated volumes to replicate it. I see no issues so far (mail storage is about 20 GB of e-mails including attachments) and am wondering if I am just lucky or if there are problems I just didn't detect yet. Anyway, I prefer to follow best practices which I didn't do in this case and I am wondering what you think about GlusterFS replicated volumens for hosts in different datacenters and what "high latency" actually means.
Эта проблема касается многих типов хранилищ данных, а не только GlusterFS. Это связано с тем, что увеличение расстояния увеличивает задержку. Рекомендация находиться в одной подсети - также уменьшить задержку из-за сетевых переходов.
Чтобы поддерживать синхронизацию данных, различные серверы должны гарантировать, что все серверы имеют одинаковое представление данных. Для чтения данных эффект задержки обычно не является проблемой. Однако серьезное повреждение данных может произойти, если несколько серверов записывают один и тот же блок перед синхронизацией. При обновлении блока данных можно потерять изменения, если обновляемый блок был прочитан до последующего обновления на другом сервере, данные, вероятно, будут потеряны.
Блокирующие механизмы могут использоваться для снижения риска коррупции. Однако получение и снятие распределенных блокировок занимает больше времени по мере увеличения задержки. В этом случае латентность - это время для завершения цикла между серверами. Обмен данными между центрами обработки данных зависит от трех факторов.
Почтовые хранилища данных в основном читаются относительно. Обычно маловероятно, что несколько клиентов, подключенных к разным серверам, будут обновлять один и тот же файл или каталог. Между входящими сообщениями электронной почты и клиентами, которые их читают, могут возникать конфликты, но задержка не должна быть серьезной проблемой. Хранилища формата Maildir должны иметь относительно более низкую конкуренцию, чем другие форматы. Однако у них относительно высокая активность по переименованию и перемещению, что может вызвать проблемы, если ваши узлы будут отключены.
- Расстояние: данные по проводам передаются по проводу на расстояние около 30 см за наносекунду, 300 метров за микросекунду или 300 километров за миллисекунду. Это увеличивает задержку по мере увеличения расстояния.
- Время переключения: каждый коммутатор, через который проходит пакет, необходимо проверить, направить, поставить в очередь и передать пакет. Это добавляет дополнительную задержку, которая увеличивается по мере увеличения нагрузки на коммутатор.
- Перегрузка сети: сети могут быть перегружены, вызывая дополнительные задержки, поскольку трафик дольше стоит в очереди и, возможно, перенаправляется. Если перегрузка плохая, задержек может быть достаточно, чтобы запустить повторную передачу пакета.