Комментарии 23
Ну я бы поостерегся тестировать скорость dd. Это тест в лучшем случае только скорости последовательной записи, а вовсе не "много случайного чтения большого количества мелких статических файлов nginx".
Посмотрите на fio. Там много настроек как протестировать и последовательно и случайно и чтение и запись.
А конкретно в вашем случае и тест следует проводить именно на nginx, например сняв логи с реального сервера и запустив по ним бенчмарк JMeter, чтобы повторить реальную нагрузку веб-сервера.
Конечно вы правы, что мерить скорость дисков надо именно fio. Но в данном случае мы просто мерием скорости и СРАВНИВАЕМ их, а не пытаемся узнать скорость записи и чтения реальных дисков. И самое главное, что при нашей нагрузки нам с запасом хватает скорости обыного NFS, от этого мы и отталкивались. Поэтому считаю, что в данном случает достаочно dd.
Я настраивал Glusterfs для одного проекта, где сервера поочерёдно раз в 5 минут записывали на Glusterfs порядка 10к файлов (MRTG). И скорости сети и диска хватало с запасом, но Gluster периодически терял синхронизацию между нодами. Пришлось откатиться на NFS
Хм... А вот это ценный факт. В описаниях к Glusterfs всегда говорят, что она надежная. Не ожидал такого. А можете чуток по подробней сказать о типе тома(ов) в том проекте?
glusterfs 7.9
2 пира симметрично реплицируемые по отдельному интефейсу
gluster peer status
Number of Peers: 1
Hostname: cfs2
Uuid: 0cf321d6-315b-416c-bdc4-7f9372aecdeb
State: Peer in Cluster (Connected)
Other names:
cfs2-back
Volume Name: mrtg
Type: Replicate
Volume ID: e5dff098-c7c6-4f33-baef-ad99f66150e4
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: cfs1:/home/mrtg
Brick2: cfs2:/home/mrtg
Options Reconfigured:
transport.address-family: inet
storage.fips-mode-rchecksum: on
nfs.disable: on
performance.client-io-threads: off
/etc/hosts
10.10.20.5 cfs1-back
10.10.20.6 cfs2-back
10.10.22.1 cfs1
10.10.22.2 cfs2
А ceph не рассматривали для своего случая?
А вот как делать сеть «толще», надо думать — либо ставить 10GBit/s сетевухи, либо пытаться объединять сетевухи. Все очень сильно зависит от требований и финансовых возможностей проекта.
Просто мысли вслух, к разговору о объединении сетевух:
В свое время изучал как и чем можно «ускорить» сеть для домашнего хранилища и был удивлен случайно узнав что Samba/SMB умеет «multichannel»(включается отдельно в настройках сервера и иногда нужно и у клиентов) — просто подключаешь к сервер несколько сетевух, к клиенту несколько сетевух и все, при копировании файлов он использует все доступные интерфейсы. То есть, к примеру, можно к свичу подключить 2 сетевухи сервера и 2 сетевухи клиента и он сам будет использовать оба интерфейса, при этом что у сервера что у клиента это будут два обычных интерфейса, без всякого агрегирования каналов. Тестировал даже варианты когда только 1 интерфейс сервера и один интерфейс клиента подключен к общей сети(свичу), а остальные сетевые интерфейсы подключены напрямую от клиента к серверу, и при подключении к сетевому ресурсу в общей сети(через свитч) он все равно определяет и использует напрямую подключенные интерфейсы для увеличения скорости передачи данных.
LACP работает на L2 и совершенно прозрачно. Обычно можно собрать до 8 интерфейсов в группу.
Да, я как-то давно слышал о таком режиме у SMB/CIFS, но сам не пробовал, не было необходимости.
Я сегодня попробовал объединить (bonding) две сетевухи в разных местах.
Сначала сделал две сетевухи у client, объединил их в режиме balance-rr и смонтировал glusterfs-том gv0 через mount-t glusterfs . Как я и предполагал в статье, скорость увеличилась в два раза - с 54 до 108.
Затем я убрал дополнительную сетевуху на client (осталась одна) и добавил по одной на srv1 и srv2, объединил их в режиме balance-rr на каждом из srv. На client cмонтировал glusterfs-том gv0 через mount-t nfs4 и скорость стала 98.
При факторе репликации 2 (как у нас) монтировать лучше через nfs, т.к. в таком случае возникновения split brain менее вероятно, чем при монтировании через glusterfs. Это объясняется тем, что при glusterfs клиент пишет сразу на два сервера, а при nfs только на один сервер.
Я пробовал, самба работает согласно документации, но оказалось , что скорость реально падает очень сильно и когда в шаре много файлов это очень грустно становится, а когда попробовал монтировать саму шару гластера в папку и уже на самбе расшаривать просто эту шару, то оказалось что в случае такого монтирования для обновления списка файлов в шаре надо обновить через ф5, тогда как если файлы лежат просто локально такого поведения нет.
Но гластер отлично подходит для синхронизации шар между нодами кластера виртуализации, например я в проксмоксе разливаю бекапы на ноды - большие файлы и мало гластер справляется без проблем.
для мелких файлов лучше подходит riak, правда из нюансов надо следить за загрузкой дисков и количеством потоков репликации, мы как то пробовали на одном жестком диске держать две ноды репликации - оно фактически умерло
По Ceph были бенчи и переход с 1Г на 10Г увеличивает скорость в Ceph примерно в 2 раза.
В Gluster прирост может будет другой, но в 10 раз он наверняка не будет )
А вы пробовали выводить ноды из обращения, записывать файлы на оставшиеся активные, а потом вводить отсутствовавшие какое-то время ноды обратно ?
Конечно пробовали, вот ситуации который мы тестировали:
тестирование отключения одного из серверов:
Запись не прекращается, когда выключенный сервер возвращается в строй, все файлы синхронизируютсятестирование замены одного из серверов:
Сначала нужно ввести новый сервер в кластер, затем заменить кирпичик (replace-brick) и уже после удалить старый сервер из кластера.
Публикации
GlusterFS, NFS — заметки о скорости и крохотном хранилище