Серьезно, совсем никого? Насколько мне известно, это форк MooseFS... Прежде чем начну с ним возиться, хотелось бы узнать, кто-нибудь вообще его с Proxmox (или чем-то еще) использовал и как он себя показывает.

LizardFS получает положительные отзывы за производительность, функциональность и стабильность, но пока я не могу найти много документации. По-моему, LizardFS появилась на основе MooseFS, когда она стала открытой в мае 2008 года, и документация для MooseFS должна быть применимой. Не знаю, почему LizardFS отделилась от MooseFS.

Хм, тоже заинтересован. Возможно, настрою тестовую среду и попробую сломать кое-что.

Спасибо за отчет. Это только подогрело мой интерес, чтобы настроить тестовую среду.

Я провёл много тестов, и результаты оказались не очень хороши. Всё работает нормально, пока не возникают какие-то проблемы, но оказывается, что серверы метаданных очень нестабильные. Я могу надежно повредить каждую работающую VM, перезагрузив главный сервер метаданных. Цитата из моего сообщения в списке lizard:

*********************************************************************************
Недавно закончил неделю стресс-тестирования lizardfs для обеспечения высокой доступности (HA) с разными конфигурациями, и результаты оказались не очень впечатляющие. Вкратце, при высокой нагрузке я наблюдаю потерю данных при имитации жёстких перезагрузок. Подробные результаты описаны ниже, вместе со скриптами HA.

Я не хочу критиковать lizardfs — я считаю его очень мощным и полезным и буду рад любым предложениям по улучшению. Я действительно хочу, чтобы он заработал для нас.

**Оборудование:**
*   3 вычислительных узла, каждый с 3 ТБ WD Red * 4 в ZFS Raid 10
*   Выделенное SSD-устройство для журналов (64 ГБ)
*   1 ГБ * 2 Bond (balance-rr) выделен для lizardfs
*   1 ГБ общедоступный IP
*   Я настроил плавающий IP для mfsmaster, который обрабатывается keepalived со скриптами для повышения/понижения уровня мастера. Keepalived хорошо справляется с IP, передавая его между узлами по мере необходимости и запуская скрипт повышения/понижения уровня.
*   Chunkserver работают хорошо, их можно включать/выключать, добавлять/удалять диски на ходу без проблем. Это действительно впечатляет.

Тем не менее, серверы метаданных кажутся довольно хрупкими. Несколько раз я наблюдал исчезновение фрагментов, когда главный сервер отключился, и его заменил резервный, а высокая нагрузка на ввод-вывод кажется самым большим показателем этого. Кроме того, они регулярно не запускаются после перезагрузки узла, даже после "mfsmetarestore -a". Я регулярно вижу эту ошибку:

```
mfsmaster[6453]: connected to Master
mfsmaster[6453]: metadata downloaded 364545B/0.003749s (97.238 MB/s)
mfsmaster[6453]: changelog.mfs.1 downloaded 1143154B/0.024354s (46.939 MB/s)
mfsmaster[6453]: changelog.mfs.2 downloaded 0B/0.000001s (0.000 MB/s)
mfsmaster[6453]: sessions downloaded 2762B/0.000365s (7.567 MB/s)
mfsmaster[6453]: opened metadata file /var/lib/mfs/metadata.mfs
mfsmaster[6453]: loading objects (files,directories,etc.) from the metadata file
mfsmaster[6453]: loading names from the metadata file
mfsmaster[6453]: loading deletion timestamps from the metadata file
mfsmaster[6453]: loading extra attributes (xattr) from the metadata file
mfsmaster[6453]: loading access control lists from the metadata file
mfsmaster[6453]: loading quota entries from the metadata file
mfsmaster[6453]: loading file locks from the metadata file
mfsmaster[6453]: loading chunks data from the metadata file
mfsmaster[6453]: checking filesystem consistency of the metadata file
mfsmaster[6453]: connecting files and chunks
mfsmaster[6453]: calculating checksum of the metadata
mfsmaster[6453]: metadata file /var/lib/mfs/metadata.mfs read (26 inodes including 13 directory inodes and 13 file inodes, 10548 chunks)
mfsmaster[6453]: running in shadow mode - applying changelogs from /var/lib/mfs
terminate called after throwing an instance of 'std::invalid_argument'
what():  stoull
Aborted
```

Оказывается, единственный способ остановить это — перезапустить *мастер*, к которому он подключается. В худшем случае — имитировать катастрофическое отключение электроэнергии, что я и сделал, вызвав жёсткую перезагрузку каждого сервера ("echo b > /proc/sysrq-trigger"). Я выполнил это с системой lizardfs, полностью восстановившейся с 1 мастером и двумя резервными копиями. На каждом узле работали 3 VM — лёгкая нагрузка для нашей системы. После перезагрузки резервный мастер не запустился, и пропало 683 фрагмента, диапазон от каждой работающей VM.

В текущем состоянии это непригодно для производственной системы с нашей точки зрения. Мы не можем вручную контролировать службы и восстанавливать резервные копии каждый раз, когда узел падает, даже в лучшем из центров обработки данных, не говоря уже о небольшом SMB, как мы. Как мне кажется, серверы метаданных, возможно, и chunkserver, не должным образом сбрасывают данные на диск. Это хорошо для производительности, но плохо для целостности данных.

**Файл конфигурации keepalived:**

```
global_defs {
 notification_email { admin@softlog.com.au }
 notification_email_from lb-alert@brian.softlog
 smtp_server smtp.emailsrvr.com
 smtp_connect_timeout 30
}

vrrp_instance VI_1 {
 state MASTER
 interface bond0
 virtual_router_id 51
 priority 60
 nopreempt
 smtp_alert
 advert_int 1
 virtual_ipaddress {
   10.10.10.249/24
   192.168.5.249/24
 }
 notify "/etc/mfs/keepalived_notify.sh"
}
```

**Скрипт, который он вызывает:**

```bash
#!/bin/bash
TYPE=$1
NAME=$2
STATE=$3
logger -t lizardha  -s "Notify args = $*"

function restart_master_server() {
 logger -t lizardha  -s "Stopping lizardfs-master service"
 systemctl stop lizardfs-master.service
 if [ -f /var/lib/mfs/metadata.mfs.lock ]; then
   logger -t lizardha  -s "Lock file found, assuming bad shutdown"
   logger -t lizardha  -s "killing all mfsmaster"
   killall -9 mfsmaster
   logger -t lizardha  -s "Removing lock file"
   rm /var/lib/mfs/metadata.mfs.lock
   logger -t lizardha  -s "Running mfsmetarestore -a"
   /usr/sbin/mfsmetarestore -a
   if [ $? -ne 0 ]; then
     logger -t lizardha  -s "mfsmetarestore operation FAILED, check logs.";
   fi;
 fi
 logger -t lizardha  -s "Starting lizardfs-master service"
 systemctl start lizardfs-master.service
 systemctl restart lizardfs-cgiserv.service
 logger -t lizardha  -s "done."
}

case $STATE in
 "MASTER")
   logger -t lizardha  -s "MASTER state"
   ln -sf /etc/mfs/mfsmaster.master.cfg /etc/mfs/mfsmaster.cfg
   restart_master_server
   exit 0
   ;;
 "BACKUP")
   logger -t lizardha  -s "BACKUP state"
   ln -sf /etc/mfs/mfsmaster.shadow.cfg /etc/mfs/mfsmaster.cfg
   restart_master_server
   exit 0
   ;;
 "STOP")
   logger -t lizardha  -s "STOP state"
   # Do nothing for now
   # ln -sf /etc/mfs/mfsmaster.shadow.cfg /etc/mfs/mfsmaster.cfg
   # systemctl stop lizardfs-master.service
   exit 0
   ;;
 "FAULT")
   logger -t lizardha  -s "FAULT state"
   ln -sf /etc/mfs/mfsmaster.shadow.cfg /etc/mfs/mfsmaster.cfg
   restart_master_server
   exit 0
   ;;
 *)
   logger -t lizardha  -s "unknown state"
   ln -sf /etc/mfs/mfsmaster.shadow.cfg /etc/mfs/mfsmaster.cfg
   restart_master_server
   exit 1
   ;;
esac
```

Я буду рад любым предложениям!

Привет! Можешь скинуть ссылку на твою переписку в lizard mailing list? Я все еще оцениваю gluster и lizard, и заметил серьезные недостатки в обеих системах. У lizard нет HA, а master-серверы кажутся ненадежными. Gluster в версии 3, но в нем есть ошибки, связанные с потерей данных, которые неприемлемы для софта версии 3. Они были бы неприемлемы даже для бета-версии (расширить общий том нельзя, не испортив файлы).

Моя главная проблема с LizardsFS/MooseFS в том: когда клиент пишет на один chunkserver, а затем этот chunkserver реплицирует данные на другой, что произойдет в случае сбоя "первичного" chunk server между записью клиента и первой репликацией? Клиент получит ACK от chunk server (потому что запись прошла успешно), но после этого chunk server упал, и данные еще не реплицированы. Это означает потерю данных, и никто об этом не знает (нет ошибки ввода-вывода на клиенте, потому что данные были записаны, и клиент отключился).

Извините, что воскрешаю такую старую тему, но только сейчас настраиваю несколько распределённых файловых систем для тестирования, и lizardfs в списке. Официальные пакеты 3.13 RC1 немного сломаны, так что вчера я потратил время на слияние PR с исправлениями и сборку неофициальных debian пакетов. Если кому-нибудь будет интересно ещё раз посмотреть на lizardfs теперь, когда доступна нормальная отказоустойчивость, я выложил .debs на GitHub под foundObjects/lizardfs. Судя по тому, что я читаю, их система HA работает довольно хорошо, а производительность файловой системы отличная. Сейчас просто настраиваю всё, пройдет какое-то время, прежде чем я смогу сделать какие-либо сравнения с gluster, ceph или moosefs.

Думаю, запись считается завершенной только после записи всех фрагментов, но я не уверен на 100%. Кстати, с erasure coding клиент записывает на все chunkservers одновременно, а не последовательно, как со стандартной репликацией.