DRBD vs. GlusterFS для репликации
Мне нужно создать решение для размещения внутренних репозиториев git. Он должен поддерживать сотни тысяч (или более) репозиториев.
Я планирую использовать несколько "тупых" серверов с общим хранилищем, поэтому, в основном, когда клиент пытается получить доступ к хранилищу - он будет перенаправлен балансировщиком нагрузки на любой из доступных серверов. Любые изменения в хранилище - будут реплицированы на все узлы.
Моей первой мыслью было использовать GlusterFS для этого, но я читал, что он плохо справляется с небольшими файлами. I'm also thinking of replicating everything myself using DRBD, but this requires more setup and seems more complicated when comparing to GlusterFS.
Which one of the two provides better performances? Basically the problem I'm trying to solve is that when any of the servers goes down - I want others to still be able to serve the data.
5 ответов
Это классический вариант использования с горизонтальным масштабированием, и IMO GlusterFS должен отвечать всем требованиям. Вы можете попробовать - просто установите несколько виртуальных машин, настройте несколько блоков, которые будут использоваться для хранения репозитория, и запустите стресс-тест.
В любом случае DRBD здесь не вариант - он не масштабируется. Во всяком случае, я бы посмотрел на другие проекты хранения объектов (например, Swift), если Gluster не работает достаточно хорошо, но ни один из них не ориентирован исключительно на производительность
У меня была аналогичная настройка для почтовых серверов Cyrus, в которых кластер оказался не в состоянии справиться с нагрузкой во время стресс-тестов. Мы изначально выбрали Gluster, потому что это было просто, но пришлось вернуться к drbd. Однако, как было отмечено, drbd activs / active cfg не рекомендуется (не говоря уже о боли). если вам нужно монтировать общее хранилище одновременно на всех серверах, drbd не вариант. Еще одна вещь, которую вы можете посмотреть, это clvmd с менеджером блокировок. lvm2 теперь поддерживает raid type lv и использует для этой цели man-код. Это может быть вариант, смешанный с соответствующей файловой системой (при необходимости, с некоторыми кластерами). однако я никогда не проверял это сам в производстве, только как PoC.
Проблема, с которой вы столкнетесь с Gluster, заключается в основном в задержке между узлами. Я бы посоветовал вам попробовать и посмотреть, справится ли он с вашей рабочей нагрузкой. Если ваши серверы достаточно мощные и имеют быстрое соединение, вы должны получить довольно хорошую производительность. Также вы можете попробовать встроенный сервер NFS, который, исходя из моего опыта, обрабатывает небольшие файлы немного быстрее.
Но если вам нужно ваше решение как можно быстрее, GlusterFS, вероятно, не для вас. Другими вариантами могут быть коммерческие продукты, такие как Git Clustering(хотя я этого не проверял), или вы можете создать собственное решение с помощью бесплатных инструментов, таких как gitmirror.
Если вы рассматриваете Gluster (который, по моему опыту, может использоваться со многими небольшими файлами, кроме YMMV), вы можете также посмотреть на Ceph http://ceph.com/
Я также рекомендовал бы Glustet ad самый простой и быстрый в настройке, настройке. Также это очень хорошо масштабируется. Проблема в скорости, и мой 2c, что вам нужно выбрать между простой конфигурацией и легким масштабированием, и между некоторыми техническими трудностями (некоторые из них представляют собой блокировку drbd / ocfs2 / Glances) с увеличением скорости. Но.. сколько скорости вы набираете? Йои нужно сделать стресс-тест и выбрать..