Мысли по MooseFS


После некоторого тестирования MooseFS появились некоторые впечатления. На вменяемый отчет не тянут, но легкое представление дают.

 

Плюсы:

  1. Неплохая кросплатформенность.
    1. Все части, кроме клиента, можно запустить под большим списком операционных систем. У меня заработало под Slax. Ubuntu, FreeBSD 9.x 10.x, Windows.
    2. Клиент заводится только под никсами. Требуется Fuse.
  2. Способна жить на слабых каналах - издевался так:
    два Chunk сервера в разных местах,
    между ними VPN, что-то около 10 мБит/с.
    настроены 2 реплики
    В результате скорость записи на уровне этих 10мБит/с, скорость чтения как с локальной машины.
    Т.к. мастер только один, то другая сторона несколько задумчива (при загрузке канала) при операция листинга и прочего. Но скорость чтения файлов высокая, т.к. читает с локального сервера.

Безопасность:

  • Подключение серверов Chunk и Metalogger никак не защищено. Т.е. любой может поднять Chunkserver, подключить его к серверу метаданных и данные начнут переливаться  к нему - соответственно нужно этот вопрос решать на уровне сети.
  • Соответственно, если поднять несколько чанк серверов, дождаться синхронизации, а потом их уронить, то можно разрушить часть данных в кластере.
  • Содержимое чанков не шифруется и его можно спокойно анализировать. Т.е если в кластере лежат текстовые файлы или почта, то их легко посмотреть.
  • Встроенные средства авторизации и управления доступом есть для клиентов. Т.е. можно настроить, чтобы конкретную папочку могли монтировать на чтение или запись только с определенными учетными данными или с определенным IP адреса.

Аппаратные требования

MFSMaster
  • Очень любит оперативную память и по мере увеличения объема данных потребляет все больше и больше. Критично: если оперативной памяти не хватает, чтобы загрузить всю базу метаданных, то он не запустится. Соответственно, на железке, которая выполняет роль резервной, обязательно должно быть достаточно памяти.
  • Т.к. пока нагрузка слабая, т.к. использую только резервных копий, нагрузку на процессор оценить не могу
  • Требования к диску - несколько объемов базы метаданных, т.к. он хранит несколько копий
  • От чего зависит скорость записи дампа памяти пока не разобрался.

Моя текущая ситуация



Metadata Servers (masters)
# ip version state metadata version RAM used CPU used last successful metadata save last metadata save duration last metadata save status
1 MFSMaster 2.0.73 - 52 345 564 2.4 GiB all:5.36% sys:1.38% user:3.98% Thu Aug 27 18:01:26 2015 ~1.4m Saved in background



Metadata Info
total space avail space trash space trash files sustained space sustained files all fs objects directories files chunks all chunk copies regular chunk copies
2.1 TiB 836 GiB 578 KiB 18 0 B 0 10049518 327689 9721528 649120 1935692 1935692



MFSChunkServer
  • Сеть - чем шустрее - тем лучше, т.к. через нее получает и отдает данные
  • Память - менее критично, но по мере увеличения количества данных тоже растет. На 250 Gb съедает 600 мб.
  • Процессор - по виду, не сильно критично, на более-менее свежем железе на том же объеме в пиках до 10%, в среднем, в районе 5% и менее.
  • Диски - так же как и сеть, чем больше и шустрее, тем лучше.
MFSMetalogger

Особых потребностей не заметил, при текущей базе потребление оперативной памяти 23МБ. Наверное, основное, объем диска, для хранения достаточного количества копий базы метаданных.

У меня в логах такая картинка:

 connected to Master
 metadata downloaded 1223399455B/156.941405s (7.795 MB/s)
 meta data version: 52345804, meta data id: 0x55BDAC461F42752E
 changelog_0 downloaded 864869B/0.365831s (2.364 MB/s)
 changelog_1 downloaded 63783B/0.007996s (7.977 MB/s)

MFSMount

  • Память - при назначении минимального размера кэша у меня съел 180Мб, т.е. совсем на слабом железе может не запуститься, но для свежего железа особо не критично.
  • Процессор - по виду, не критично, около 1-2%
  • Сеть - чем быстрее, тем лучше, т.к. по ней отдает и получает данные
     

Особенности:

  • Замена дисков - при добавлении одного и пометки на удаление другого диска в chunk сервере, данные сначала разливаются на другие чанк сервера, а потом заливаются обратно, что соответственно ведет к лишней нагрузке на сеть и на другие чанк сервера. Т.к. менял одинаковые по размеру диски, то ожидал, что данные будут переливаться в пределах этого же сервера, не трогая остальные сервера.
    Как выяснил несколько позже, для перемещения данных в пределах сервера нужно сделать следующее:
    • подключить новый диск
    • на удаляемом диске указать допустимый объем 1GiB
    • перевести chunkserver в maintenance режим (через web интерфейс, на вкладке servers)
    • дождаться, пока данные перетекут на новый диск
    • перевести chunkserve в рабочий режим
    • пометить старый диск на удаление
    • дождаться его освобождения
    • удалить диск
    • При этом, как ни странно, скорость наполнения нового диска достаточно низкая (менее 1мб/сек или 2-3 чанка в секунду), при наполнении через сеть, скорость значительно выше.

Скорость:

Тестирование проводилось в сложной сети, т.е. элементы находились не в пределах одной стойки, одного свича, а подключенные к сильно разному оборудованию, от 1Gb до 100Мб, с завернутыми несколькими VLANами в одном транке через несколько коммутаторов.

  • Сервер метаданных крутился на виртуалке с FreeBSD 10.1, c 1гб оперативной памяти, на ряду с другими виртаулками
  • Сеть до сервера метаданных виртуалка-шлюз-коммутатор-коммутатор-шлюз-виртаулка
    # ping -s 1500 -c3 -q mfsmaster
    PING mfsmaster (mfsmaster): 1500 data bytes
    --- mfsmaster ping statistics ---
    3 packets transmitted, 3 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 1.202/1.222/1.240/0.016 ms
  • Чанк сервера физические машины под FreeBSD 9.x-10.x
  • Данные чанк серверов на ZFS с compression=gzip-9
  • Metadata Servers (masters)
    # ip version state metadata version RAM used CPU used last successful metadata save last metadata save duration last metadata save status
    1 mfsmaster 2.0.73 - 39 737 677 607 MiB all:2.99% sys:2.87% user:0.13% Mon Aug 10 13:00:04 2015 ~4.1s Saved in background



    Metadata Info
    total space avail space trash space trash files sustained space sustained files all fs objects directories files chunks all chunk copies regular chunk copies
    1.6 TiB 773 GiB 14 B 1 0 B 0 428914 7096 421798 426548 1274331 1274331



    Memory usage detailed info
      chunk hash chunks cs lists edge hash edges node hash nodes deleted nodes chunk tabs symlinks quota total
    used 3.3 MiB 20 MiB 19 MiB 3.3 MiB 52 MiB 3.3 MiB 28 MiB 13 KiB 3.2 MiB 560 B 0 B 132 MiB
    allocated 128 MiB 20 MiB 19 MiB 128 MiB 53 MiB 128 MiB 28 MiB 78 KiB 4.3 MiB 320 KiB 0 B 509 MiB
    utilization 2.54 % 96.94 % 99.93 % 2.56 % 97.71 % 2.56 % 99.35 % 16.60 % 74.72 % 0.17 % - 25.84 %
    distribution 25.13 % 3.95 % 3.82 % 25.13 % 10.35 % 25.13 % 5.56 % 0.01 % 0.84 % 0.06 % 0.00 % -
    distribution bar
    node hash edge hash chunk hash edges nodes chun… cs lists



    All chunks state matrix (counts 'regular' hdd space and 'marked for removal' hdd space : switch to 'regular')
    goal valid copies
    0 1 2 3 4 5 6 7 8 9 10+ all
    0   27 5389 30               5446
    1                       0
    2                       0
    3 4     420956 142             421102
    4                       0
    5                       0
    6                       0
    7                       0
    8                       0
    9                       0
    10+                       0
    all 1+ 4 0 0 420956 142 0 0 0 0 0 0 421102
    colors  - missing (4) /  - endangered (0) /  - undergoal (0) /  - stable (420956) /  - overgoal (142) /  - pending deletion (5446) /  - ready to be removed (0)

Результаты:

Когда игрался не обратил внимание, что количество реплик было 3 шт. Если оставить 1 реплику, то скорость записи в моей конструкции поднимается до 8мбайт/сек. При 7 серверах и указании 9 реплик скорость падает до 1мбайт/сек. При этом, при записи видно, что пишется одновременно на 5-ть серверов, а на остальные реплики приезжают позже. Когда Chunk сервера переливают инфу между собой, скорость немного падает.

Глобально, от того где и что за клиент работает, разницы критичной не заметил.

  • При изменении количества реплик - трафик между chunk серверами идет около пропускной способности сети - до 50 Мбайт/с.
  • линейная запись 200мб - dd if=/dev/random of=test.`hostname` bs=10000000 count=20
    20+0 records in
    20+0 records out
    200000000 bytes transferred in 54.012600 secs (3 702 840 bytes/sec)
  • линейное чтение 500Мб -  dd of=/dev/null if=test1.`hostname` bs=10m
    50+0 records in
    50+0 records out
    524288000 bytes transferred in 40.652898 secs (12 896 694 bytes/sec)

Судя по всему, нужно, чтобы сервер метаданных находился на хорошем железе с хорошим каналом, т.к. у людей скорость записи была выше 30мб/с. Эту идею буду тестировать попозже.