Я пытаюсь настроить реплицированное хранилище на трех сайтах - каждый сайт имеет полную реплику файловой системы, используя либо GlusterFS, либо XtreemeFS. Эта реплика должна быть читаемой - очень быстро - локально для каждого сайта, без необходимости доступа к каким-либо удаленным узлам (мы намерены использовать кластер хранения для хранения огромного количества сторонних файлов заголовков и библиотек для большого проекта C ++). Запись должна быть возможна с любого сайта, но производительность не так важна. Синхронная запись будет приемлемой. К сожалению, у меня возникла проблема с настройкой этих файловых систем для выбора реплики, локальной для сайта, для высокопроизводительного чтения. Я также рассмотрел DRBD и создание кольцевой топологии или репликации с двумя главными серверами, но отверг эту идею, потому что она кажется слишком сложной. Я инженер-программист, а не айтишник, поэтому прошу простить меня за незнание в этой области. Я понимаю, что это очень технически сложная проблема, и мне нужно хорошее решение, которое правильно обрабатывает семантику блокировки для записи. Что касается Gluster, я не вижу практического способа добиться этого. Для XtreemeFS я предполагал, что могу назначить «карту центра обработки данных» и использовать политику хранения WqRq, но, к сожалению, это не работает. Кажется, что если у меня есть три реплики, у меня должны быть три реплики, доступные для любого сервера, который пытается писать (для Gluster также кажется, что все три Bricks также будут записаны синхронно, независимо от сайта ...). Нужно ли мне для этого настраивать реплицированный сервер метаданных для XtreemeFS, каждый с разным порядком карты центра обработки данных (для определения приоритета локальной репликации)? Как принудительно использовать локальную реплику на каждом сайте? Похоже, для монтирования требуется URL-адрес сервера каталогов, поэтому, похоже, нет простого способа принудительно упорядочить выбор реплик. Есть ли какая-либо альтернатива, которая позволит мне иметь запись с несколькими мастерами и подходящий выбор локальных реплик для хорошей производительности чтения?
Что вам нужно, так это действительно дорогостоящая SAN ... В моей лас-работе мы использовали кучу ssd, выступающих в качестве кеша, к которому они получали доступ большую часть времени. И наоборот, реальное хранилище с кучей дисков SATA ... Мы использовали его, чтобы иметь файловое хранилище + vdi +, например, 200 виртуальных машин на esxi. И все это хранилище передавалось по оптоволоконным каналам на другой baremetal. http://searchstorage.techtarget.com/tip/Clustering-in-a-SAN-environment-for-high-availability
Мастер / Мастер без необходимости доступа к удаленным сайтам, но при этом требует целостности данных?
Я почти уверен, что это невозможно, если я правильно вас понимаю.
Вы можете настроить главный / подчиненный сервер (без мультимастера) или оставить время для задержки репликации с использованием нескольких пулов (доступ к удаленным сайтам, опять же, не главный-главный, и отсутствие гарантированного состояния в пуле в любой момент времени. ). Опять же, ряд решений для вашего варианта использования, но ни одно из них не будет соответствовать всем этим требованиям.
Файловая система master / master без непосредственного подключения к другим узлам просто невозможна. У вас не может быть единой согласованной файловой системы, если файловая система не может легко взаимодействовать со своим хранилищем.