Мне нужно создать решение для размещения внутренних репозиториев git. Он должен поддерживать сотни тысяч (или более) репозиториев.
Я планирую использовать несколько «глупых» серверов с общим хранилищем, поэтому в основном, когда клиент пытается получить доступ к репозиторию, он будет перенаправлен балансировщиком нагрузки на любой из доступных серверов. Любое изменение в репозитории будет реплицировано на все узлы.
Моей первой мыслью было использовать для этого GlusterFS, но я читал, что она плохо справляется с небольшими файлами. Я также думаю о том, чтобы реплицировать все самостоятельно, используя DRBD, но это требует дополнительных настроек и кажется более сложным по сравнению с GlusterFS.
Какой из двух обеспечивает лучшую производительность? В основном проблема, которую я пытаюсь решить, заключается в том, что когда какой-либо из серверов выходит из строя, я хочу, чтобы другие по-прежнему могли обслуживать данные.
Это классический вариант использования с горизонтальным масштабированием, и IMO GlusterFS должен соответствовать всем требованиям. Вы можете попробовать - просто установите несколько виртуальных машин, настройте несколько блоков, которые будут использоваться для хранилища репозитория, и запустите стресс-тест.
В любом случае DRBD здесь не вариант - он не масштабируется. Во всяком случае, я бы посмотрел на другие проекты хранилищ объектов (например, Swift), если Gluster не работает достаточно хорошо, но ни один из них не ориентирован на производительность.
У меня была аналогичная установка для почтовых серверов cyrus, в которых было доказано, что gluster не может справиться с нагрузкой во время стресс-тестов. изначально мы выбрали gluster, потому что это было просто, но пришлось вернуться к drbd. однако, как подчеркнуто dyasny, drbd activs / active cfg не рекомендуется (не говоря уже о боли). если вам нужно, чтобы все серверы одновременно монтировали общее хранилище, drbd не подходит. Еще одна вещь, на которую вы можете захотеть взглянуть, - это clvmd с диспетчером блокировок. lvm2 теперь поддерживает raid type lv и для этой цели используется код man. это в сочетании с соответствующей файловой системой (при необходимости, с некоторыми кластерными системами) может быть вариантом. однако я сам никогда не тестировал его в продакшене, только как PoC.
Проблема, с которой вы столкнетесь с Gluster, в основном заключается в задержке между узлами. Я бы посоветовал вам попробовать и посмотреть, справится ли он с вашей рабочей нагрузкой. Если ваши серверы достаточно мощные и имеют быстрое соединение, вы должны получить довольно хорошую производительность. Также вы можете попробовать встроенный сервер NFS, который, исходя из моего опыта, обрабатывает небольшие файлы немного быстрее.
Но если вам нужно как можно более быстрое решение, GlusterFS, вероятно, не для вас. Другими вариантами могут быть коммерческие продукты, такие как Кластеризация Git(хотя это не тестировали), или вы можете создать собственное решение с бесплатными инструментами, такими как gitmirror.
Если вы рассматриваете Gluster (который, по моему опыту, можно использовать со многими небольшими файлами, кроме YMMV), вы, возможно, захотите также взглянуть на Ceph http://ceph.com/
Я также порекомендовал бы Glustet ad самый простой и самый быстрый в установке и настройке. Также он очень хорошо масштабируется. Проблема в скорости, и мой 2c ia в том, что вам нужно выбирать между простой конфигурацией и легким масштабированием, а также между некоторыми техническими трудностями (некоторые причудливые блочные хранилища drbd / ocfs2 / Glances) с увеличением скорости. Но .. сколько скорости вы набираете? Йой должен пройти стресс-тест и выбрать ..