Что такое распределенное хранилище (движок), устойчивое к сбоям, которое действительно работает.
CouchDB фактически не имеет встроенных функций распределения, насколько мне известно, управление для автоматического распределения записей или даже целых баз данных просто отсутствует.
Hadoop, кажется, очень широко используется — по крайней мере, он получает хорошую оценку, но все же имеет единственную точку отказа: NameNode. Кроме того, его можно подключить только через FUSE, я понимаю, что HDFS на самом деле не является основной целью Hadoop.
GlusterFS действительно имеет концепцию shared nothing, но в последнее время я прочитал несколько сообщений, которые привели меня к мнению, что она не совсем стабильна.
Lustre также имеет единую точку отказа, поскольку использует выделенный сервер метаданных.
Ceph кажется самым популярным вариантом, но на домашней странице говорится, что она все еще находится на стадии тестирования.
Итак, вопрос заключается в том, какая распределенная файловая система обладает следующим набором функций (без особого порядка):
POSIX-совместимая;
простое добавление/удаление узлов;
концепция shared-nothing;
работает на дешевом оборудовании (процессоры класса AMD Geode или VIA Eden);
встроенная аутентификация/авторизация;
сетевая файловая система (хотелось бы иметь возможность монтировать ее одновременно на разных узлах).
Желательно иметь:
локально доступные файлы: я могу отключить узел, смонтировать раздел со стандартной локальной файловой системой (ext3/xfs/whatever...) и по-прежнему иметь доступ к файлам;
я не ищу размещенные приложения, скорее, что-то, что позволит мне взять, скажем, 10 ГБ из каждого из наших аппаратных блоков и иметь это хранилище доступным в нашей сети, легко монтируемым на множестве узлов.
Ответ 1
Похоже, вы путаете «распределенный механизм хранения» и «распределенную файловую систему». Это не одно и то же, их нельзя принимать за одно и то же, и они никогда не будут одним и тем же. Файловая система — это способ отслеживания местоположения файлов на жестком диске. Механизм хранения данных, такой как hadoop, — это способ отслеживать фрагменты данных, идентифицированные ключом. Концептуально разница невелика. Проблема в том, что файловая система зависит от механизма хранения… в конце концов, ей нужен способ записи на блочное устройство, не так ли?
Но, откинув все это в сторону, я точно могу рассказать об использовании ocfs2 в качестве распределенной файловой системы в производственной среде. Мы использовали ocfs2 в производственной среде в течение последних нескольких лет. Это нормально, но для многих приложений это не очень хорошо. Вы должны действительно посмотреть на свои требования и выяснить, каковы они — вы можете обнаружить, что у вас гораздо больше возможностей для ошибок, чем вы думали.
В качестве примера: ocfs2 имеет журнал для каждой машины в кластере, которая собирается монтировать раздел. Допустим, у вас есть четыре веб-машины, а когда вы создаете раздел с помощью mkfs.ocfs2, вы указываете, что всего будет шесть машин, чтобы дать себе пространство для роста. Каждый из этих журналов занимает место, что уменьшает количество данных, которые вы можете хранить на дисках. Теперь, допустим, вам нужно увеличить количество машин до семи. В такой ситуации вам нужно снести весь кластер (то есть отмонтировать все разделы ocfs2) и с помощью утилиты tunefs.ocfs2 создать дополнительный журнал, если есть свободное место. Затем и только затем вы можете добавить седьмую машину в кластер (что требует распространения текстового файла среди остальных машин кластера, если вы не используете утилиту), восстановить все, а затем смонтировать раздел на всех семи машинах.
Понимаете, о чем я? Предполагается, что это высокая доступность, которая должна означать «всегда онлайн», но в данном случае вы получаете кучу простоев… и, не дай бог, нехватку дискового пространства. Имейте в виду, что evms, который раньше был «предпочтительным» способом управления кластерами ocfs2, теперь использует clvmd и lvm2. Кроме того, heartbeat быстро превратится в «зомби-проект» в пользу стека openais/pacemaker (примечание: при выполнении начальной конфигурации кластера для ocfs2 вы можете указать «pcmk» в качестве движка кластера, а не heartbeat).
Если уж на то пошло, мы вернулись к nfs под управлением pacemaker, потому что несколько секунд простоя или несколько потерянных tcp-пакетов при переносе pacemaker ресурса nfs на другую машину — это мелочи, по сравнению с тем количеством простоев, которые мы наблюдали при базовых операциях с общим хранилищем, таких как добавление машин при использовании ocfs2.
Ответ 2
Если только речь не идет об академических/разработочных целях, к подобным вещам следует подходить, начиная с общих требований к проекту. Большинство распределенных файловых систем недостаточно зрелы для серьезного развертывания — например, что делать, если все «полетит». Если проект предназначен для академических/разведывательных целей, то это даже хорошо, поскольку вы сможете многому научиться и исправить множество ошибок.
Комментарий о том, действительно ли вам нужна семантика POSIX, является хорошим началом. Семантика «файловой системы» без POSIX может быть гораздо более гибкой, что приводит к гораздо более надежным системам.
Если речь идет об унаследованном приложении, мне действительно интересно, почему современная распределенная файловая система может считаться лучшим решением.
Я просто не хотел бы отвечать за сложное взаимозависимое решение, которое не используется повсеместно и которое будет очень трудно починить, когда оно выйдет из строя.
Ответ 3
Вам действительно, абсолютно точно нужна семантика POSIX? Управление системой становится намного проще, если вы можете использовать пользовательское хранилище данных. У нас есть собственное хранилище данных, которое, по сути, является очень большим распределенным хранилищем ключевых значений. Вы сохраняете в нем файл и получаете обратно токен. Если вы хотите получить файл обратно, передайте ему токен, который вы получили ранее. Оно распределенное, ничего не разделяется, данные реплицируются три раза, узлы могут добавляться и удаляться по желанию, как серверы хранения, так и управляющие серверы.
Ответ 4
ИнструментLustre разработан для поддержки обхода отказа, и MDS/MDT/OSS может иметь несколько адресов, по которым с ним можно связаться, heartbeat можно использовать для миграции службы. Имейте в виду, что в некоторых последних версиях были проблемы, когда размонтирование вроде бы работает, но данные все еще передаются на диск, однако защита от двойного монтирования должна была бы помочь, если бы поддерживалась…
Linux
