Ящерица - LizardFS
Разработчики) | Skytechnology Sp. z o.o.[1] |
---|---|
Стабильный выпуск | 3.12.0 / 21 декабря 2017 г.[2] |
Репозиторий | |
Операционная система | Linux, FreeBSD, Mac OS X, Солярис |
Тип | Распределенная файловая система |
Лицензия | GPLv3 |
Интернет сайт | LizardFS.com |
Ящерица является Открытый исходный код распределенная файловая система то есть POSIX -соответствует и имеет лицензию на GPLv3.[3][4] Он был выпущен в 2013 году как форк MooseFS.[5] LizardFS также предлагает платную техническую поддержку (Standard, Enterprise и Enterprise Plus) с возможностью конфигурирования и настройки кластера и активного мониторинга кластера.
LizardFS - это распределенная, масштабируемая и отказоустойчивая файловая система. Файловая система спроектирована так, чтобы можно было добавлять дополнительные диски и серверы «на лету», без необходимости перезагрузки или выключения сервера.[6]
Описание
LizardFS обеспечивает безопасность файлов, храня все данные в нескольких репликах, распределенных по доступным серверам. Это хранилище представляется конечному пользователю как единое логическое пространство имен. Его также можно использовать для создания компактного хранилища, поскольку он предназначен для работы на товарное оборудование. Он имеет приложения в различных областях и используется учреждениями в области финансов, телекоммуникаций, медицины, образования, постпродакшна, разработки игр, услуг облачного хостинга и других.
Аппаратное обеспечение
LizardFS полностью не зависит от оборудования. Для рентабельности можно использовать стандартное оборудование. Минимальные требования - два выделенных узла с определенным количеством дисков, но для получения высокий доступный требуется установка не менее 3 узлов. Это также позволит использовать стирающее кодирование.
Архитектура
LizardFS сохраняет метаданные (например, имена файлов, отметки времени модификации, деревья каталогов) и данные отдельно. Метаданные хранятся на серверах метаданных, а данные - на серверах фрагментов.
Типичная установка состоит из:
- Как минимум два сервера метаданных, которые работают в режиме ведущий-ведомый для восстановления после сбоев. Их роль заключается в управлении всей установкой, поэтому активный сервер метаданных часто называют главным сервером. Роль других серверов метаданных заключается в том, чтобы поддерживать синхронизацию с активным главным сервером, поэтому их часто называют теневыми главными серверами. Любой теневой главный сервер готов в любой момент взять на себя роль главного сервера. Предлагаемая конфигурация сервера метаданных - это машина с быстрым ЦПУ, как минимум 32 ГБ ОЗУ и как минимум один диск (желательно SSD) для хранения нескольких ГБ метаданных.
- Набор серверов фрагментов, на которых хранятся данные. Каждый файл разделен на блоки, называемые чанками (каждый размером до 64 МБ), которые хранятся на серверах фрагментов. Рекомендуемая конфигурация chunkserver - это машина с большим дисковым пространством, доступным либо в JBOD или же RAID конфигурация. CPU и RAM не очень важны. У вас может быть как минимум 2 сервера фрагментов, так и сотни из них.
- Клиенты, использующие данные, хранящиеся в LizardFS. Эти машины используют монтирование LizardFS для доступа к файлам при установке и обработки их так же, как файлы на их локальных жестких дисках. Файлы, хранящиеся в LizardFS, могут быть просмотрены и доступны любому количеству клиентов.
Функции
- Снимки - При создании снимка копируются только метаданные целевого файла, что ускоряет операцию. Фрагменты исходного и дублированного файлов используются совместно, пока один из них не будет изменен.
- QoS - LizardFS предлагает механизмы, которые позволяют администраторам устанавливать ограничения пропускной способности чтения / записи для всего трафика, генерируемого данной точкой монтирования, а также для определенной группы процессов, распределенных по нескольким клиентским машинам и точкам монтирования.
- Репликация данных - Файлы, хранящиеся в LizardFS, разделены на блоки, называемые кусками, каждый размером до 64 МБ. Каждый фрагмент хранится на серверах фрагментов, и администраторы могут выбирать, сколько копий каждого файла будет храниться. Например, если выбрать сохранение 3 копий (цель конфигурации = 3), все данные сохранятся после сбоя любых двух дисков или серверов фрагментов, поскольку LizardFS никогда не будет хранить 2 копии одного и того же фрагмента на одном узле.
- Георепликация - С помощью георепликации вы можете решить, где хранить фрагменты. Функция топологии позволяет предлагать, какая копия должна быть прочитана клиентом в случае, когда доступно более одной копии. Например, когда LizardFS развернут в двух центрах обработки данных, например один расположен в Лондоне, а другой - в Париже, можно присвоить ярлык «london» каждому серверу в местоположении в Лондоне и «paris» каждому серверу в местоположении в Париже.
- Репликация метаданных - метаданные хранятся на серверах метаданных. В любое время один из серверов метаданных также управляет всей установкой и называется главным сервером. Другие серверы метаданных синхронизируются с ним и являются теневыми главными серверами.
- Высокая доступность - Теневые главные серверы обеспечивают высокую доступность LizardFS. Если есть хотя бы один теневой главный сервер и активный главный сервер потерян, один из теневых главных серверов берет на себя
- Квоты - LizardFS поддерживает механизм дисковых квот, известный из других файловых систем POSIX. Он предлагает возможность установить мягкие и жесткие ограничения для количества файлов и их общего размера для конкретного пользователя или группы пользователей. Пользователь, чей жесткий предел превышен, не может записывать новые данные в LizardFS.
- Корзина. Еще одна особенность LizardFS - это прозрачная полностью автоматическая корзина для мусора. После удаления любого файла он перемещается в корзину, которая видна только администратору. Любой файл в корзине можно восстановить или удалить навсегда.
- Родные Windows ™ client - Клиент LizardFS для Windows можно установить как на рабочие станции, так и на серверы. Он обеспечивает доступ к файлам, хранящимся в LizardFS, через виртуальный диск. Клиент Windows - это лицензионная функция, которую можно получить, связавшись с создателями LizardFS - Skytechnology sp. z o.o.
- Мониторинг LizardFS предлагает два интерфейса мониторинга. Прежде всего, есть инструмент командной строки, полезный для таких систем, как Nagios, Zabbix, Icinga, которые обычно используются для упреждающего мониторинга. Кроме того, для администраторов доступен графический веб-интерфейс мониторинга, который позволяет отслеживать практически все аспекты системы.
- Hadoop - Это решение на основе Java, позволяющее Hadoop использовать хранилище LizardFS, реализуя интерфейс HDFS для LizardFS. Он функционирует как своего рода уровень абстракции файловой системы. Он позволяет использовать задания Hadoop для прямого доступа к данным в кластере LizardFS. Плагин переводит протокол LizardFS и делает доступными для чтения метаданные для Yarn и Map Reduce.
- NFS и pNFS - LizardFS использует сервер NFS-ganesha для создания общих ресурсов NFS, поэтому технически клиент NFS подключается не к главному серверу, а к файловому серверу Ganesha, который напрямую взаимодействует с компонентами LizardFS. С точки зрения пользователя он работает как обычный сервер NFS.
Смотрите также
- Гиперконвергентная инфраструктура
- Распределенная файловая система
- Список файловых систем # Распределенные параллельные отказоустойчивые файловые системы
- MooseFS
- BeeGFS
Рекомендации
- ^ «Skytechnology - Наша продукция».
- ^ "Релизы · lizardfs / lizardfs".
- ^ «LizardFS: программно-определяемое хранилище, каким оно должно быть (оригинальная статья на немецком языке)». www.golem.de. 27 апреля 2016 г.. Получено 2016-05-06.
- ^ "Mr. Blue Coat: (обновленный) тест распределенной файловой системы". Получено 2016-05-06.
- ^ "ZFS + glusterfs на двух или трех узлах". permalink.gmane.org. Получено 2016-05-06.
- ^ Кореньков, В. В .; Кутовский, Н. А .; Балашов, Н. А .; Баранов, А. В .; Семенов, Р. Н. (01.01.2015). «Облачная инфраструктура ОИЯИ». Процедуры информатики. 4-я Международная конференция молодых ученых по вычислительным наукам. 66: 574–583. Дои:10.1016 / j.procs.2015.11.065.