Горизонтальное масштабирование альтернатив GFSv2 (медлительность)

Question

Горизонтальное масштабирование альтернатив GFSv2 (медлительность)

У меня проблема с дизайном инфраструктуры приложения. Прямо сейчас мы получаем доступ к множеству небольших файлов (до 10 МБ) из двухузлового кластера GFSv2. 90% доступа к файлам - это "случайное чтение" в этот раздел GFSv2, остальные 10% - случайные записи. Я сделал все настройки для noatime, nodirtime и plocks, но IOwait все еще слишком высок. Каковы лучшие альтернативы для этого типа сценария?

Другие, возможно, важные детали: все гигабитные сети, все хосты находятся в одной стойке, gfs поступает из многоуровневой SAN с SSD с задержкой <1 мс и отличной производительностью, iowait с использованием DLM составляет 3%, просто записывая два файла по 3 МБ в секунду. Мы, очевидно, планируем справиться с гораздо большим, чем это. Мне нужно решение, которое будет HA и масштабироваться по горизонтали.

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

0

performance scale gfs

Источник

onetruescottsman 13 мар '14 в 20:06

1 ответ

Другие вопросы по тегам performance scale gfs

piotrektt 13 мар '14 в 21:31 2014-03-13 21:31 · Answer 1 · 2014-03-13 21:31

Это зависит от того, насколько маленькие файлы. Если у вас более 10 КБ, вы можете попробовать GlusterFS. Это замечательно с большими файлами, и кластер с 2 узлами с зеркалом должен иметь возможность обрабатывать большую пропускную способность. С действительно маленькими файлами - кластер терпит неудачу:(

Вы также можете попробовать Ceph (объект или хранилище блоков) или Swift (объект). С хранилищем объектов дело в том, что вам нужно подключиться к нему с помощью API.