Любой учебник, который я могу найти о реплицированных томах GlusterFS, предполагает, что оба (все) блока находятся в одной частной сети, что также приводит к выводу, что они должны находиться в одном центре обработки данных.
например "Проблема в том, что когда хранилище, в которое вы хотите реплицировать, находится в удаленной сети, возможно, в другом месте, GlusterFS не работает очень хорошо. Это связано с тем, что GlusterFS не предназначен для работы при большой задержке между узлами репликации. . " это цитата из https://github.com/GlusterFS/Notes
Также https://gluster.readthedocs.io/en/latest/Administrator%20Guide/Geo%20Replication/ говорит, что реплицированные тома не предназначены для георепликации, однако настоящий механизм «георепликации» в GlusterFS создает только ведомые устройства, доступные только для чтения, которые не будут работать во всех сценариях.
Итак, вопрос в том, почему это не рекомендуется вообще, поскольку я не нашел ни одного примера реплицированных томов для хостов в разных сетях, но даже в разных центрах обработки данных.
Я также могу объяснить, почему я хочу использовать реплицированные тома. У меня есть vServer (OpenVZ) в центре обработки данных во Франкфурте, Германия, и второй в Нюрнберге, Германия. Оба имеют несколько пирингов с DE-CIX, Deutsche Telekom и т. Д., А задержка между vServers составляет <4 мс, что, на мой взгляд, не может считаться высокой задержкой, независимо от определения этого в случае GlusterFS.
Я запускаю службы iRedmail на обоих серверах, и MariaDB реплицируется в репликации Master-Master, сохраняя только конфигурацию почты. Почтовое хранилище находится на диске, и я использую реплицированные тома GlusterFS для его репликации. Я пока не вижу проблем (почтовое хранилище составляет около 20 ГБ электронных писем, включая вложения), и мне интересно, просто ли мне повезло или есть проблемы, которые я просто еще не обнаружил. В любом случае, я предпочитаю следовать лучшим практикам, которых я не делал в этом случае, и мне интересно, что вы думаете о реплицированных томах GlusterFS для хостов в разных центрах обработки данных и что на самом деле означает «высокая задержка».
Эта проблема касается многих типов хранилищ данных, а не только GlusterFS. Это связано с тем, что увеличение расстояния увеличивает задержку. Рекомендация находиться в одной подсети - также уменьшить задержку из-за сетевых переходов.
Чтобы поддерживать синхронизацию данных, различные серверы должны гарантировать, что все серверы имеют одинаковое представление данных. Для чтения данных эффект задержки обычно не является проблемой. Однако серьезное повреждение данных может произойти, если несколько серверов записывают один и тот же блок перед синхронизацией. При обновлении блока данных можно потерять изменения, если обновляемый блок был прочитан до последующего обновления на другом сервере, данные, вероятно, будут потеряны.
Механизмы блокировки могут использоваться для снижения риска коррупции. Однако получение и снятие распределенных блокировок занимает больше времени по мере увеличения задержки. В этом случае латентность - это время для завершения цикла между серверами. Обмен данными между центрами обработки данных зависит от трех факторов.
Почтовые хранилища данных обычно относительно читаются. Обычно маловероятно, что несколько клиентов, подключенных к разным серверам, будут обновлять один и тот же файл или каталог. Между входящими сообщениями электронной почты и клиентами, которые их читают, могут возникать конфликты, но задержка не должна быть значительной проблемой. Хранилища формата Maildir должны иметь относительно более низкую конкуренцию, чем другие форматы. Однако у них относительно высокая активность по переименованию и перемещению, что может вызвать проблемы, если ваши узлы будут отключены.