Как стать автором
Обновить
  • по релевантности
  • по времени
  • по рейтингу

Gentoo+drbd+ocfs2

Высокая производительность

Введение


Поставили передо мной как-то задачу… говорят один сервер это хорошо… но учитываю рост посетителей, неплохо бы было повысить производительность отдачи и для этой цели будет приобретен еще 1 сервер…
еще один сервер это хорошо, подумал я… только что с ним делать ??
Поговорив с програмистом и примерно поняв чего он хочет…

А именно одновременную отдачу контента, и что-то типа nfs или шары…
но тогда был бы оверхед ибо данные гонялись по сети и нагружен был бы диск одного сервера, посему надо было чтобы данные одновременно хранились на обоих серверах и реплицировались друг на друга…
поискав в гугле что-то на эту тему нашел информацию по кластерным фс, и для меня подходили gfs2 и позднее обнаруженная ocfs2, но была проблема в том что обычно использовалось выделенное файловое хранилище и его уже монтировали ноды… что было неприемлимо для меня, и тогда позадавав вопросы народу в конференции (gentoo@conference.gentoo.ru благо там были люди работающие с кластерами и прочими веселыми вещами) я вышел на drbd
Читать дальше →
Всего голосов 6: ↑5 и ↓1 +4
Просмотры9.5K
Комментарии 12

Кластерное хранилище для небольших web-кластеров на базе drbd+ocfs2

Настройка LinuxСистемное администрирование
Tutorial
О чем мы расскажем:
Как быстро развернуть общее хранилище для двух серверов на базе решений drbd+ocfs2.

Для кого это будет полезно:
Туториал станет полезен системным администраторам и всем, кто выбирает способ реализации хранилища или хотят попробовать решение.

От каких решений мы отказались и почему


Часто мы сталкиваемся с ситуацией, когда нам нужно реализовать на небольшом web-кластере общее хранилище с хорошей производительностью на чтение — запись. Мы пробовали различные варианты реализации общего хранилища для наших проектов, но мало что было способно удовлетворить нас сразу по нескольким показателям. Сейчас расскажем, почему.

  • Glusterfs не устроил нас производительностью на чтение и запись, возникали проблемы с одновременным чтением большого количества файлов, была высокая нагрузка на CPU. Проблему с чтением файлов можно было решить, обращаясь за ними напрямую в brick-и, но это не всегда применимо и в целом неправильно.

  • Ceph не понравился избыточной сложностью, которая может быть вредна на проектах с 2-4 серверами, особенно, если проект впоследствии обслуживают. Опять же, имеются серьезные ограничения по производительности, вынуждающие строить отдельные storage кластеры, как и с glusterfs.

  • Использование одного nfs сервера для реализации общего хранилища вызывает вопросы в плане отказоустойчивости.

  • s3 — отличное популярное решение для некоторого круга задач, но это и не файловая система, что сужает область применения.
Читать дальше →
Всего голосов 5: ↑5 и ↓0 +5
Просмотры6.7K
Комментарии 6