У меня был один es, возможно тут грабли и затаились. Но логов хотелось хранить долго, хотя бы пол года. Чистить по расписанию — не проблема, проблема в том, что даже эти пол-года не влазили.
А logstash да, править приходилось частенько. Надеюсь, когда устоится, проект будет интереснее.

Разворачивал я систему логирования logstash+elasticsearch, куда сыпалось много разношёрстых логов. На большом промежутке времени оно стабильно так и не работало. То logstash в ступор уйдёт, то elasticsearch. Logstash приходилось просто перегружать, elasticsearch чистить базу логов, иначе система деградирует. Собирал логи, по наивности используя tcp, в том числе и с веб-серверов — в результате, при ступоре logstash, в ступор впадали и все, кто пытались отправить логи по tcp. Пришлось всё переделывать на udp. Пробовал разные варианты настройки и того и другого, с сжатием и без.
В общем, как-то стабильности и уверенности в работе связка не внушила.
Если есть положительный пример использования, с десятками источников логов и базой в десятки гигабайт поделитесь опытом.

Я для себя эту проблему решил перебиндив кнопки в screen, а именно:
escape ^pp # suggested binding for emacs users
После небольшого привыкания так даже удобнее и не перекрывает кнопки в vim.

Спасибо за собранную в кучу таблицу, удобно.
Хочу дополнить список полезных сочетаний в shell(bash) перемещение по истории команд:
ctrl+r — поиск по командам (вдруг кто не знает)
Alt+> — самая последняя команда в списке истории
Alt+< — самая первая команда.
Если история команд используется очень активно, то Alt+> порой проста необходима.

Ещё бы это куда-нибудь писать на таких скоростях…

Очень интересное расследование, спасибо.

К сожалению, я шибко с cgroup-ами не работал и на статью не соберу.
Из граблей, на которые наступал: memsw.limit_in_bytes — это именно сумма swap+mem, и должно быть >= limit_in_bytes или лимит не установится.

Чтобы ограничить ресурсы с помощью cgroup не обязательно заводить отдельное окружение (lxc-контейнер). Достаточно завести свою группу, выставить ей нужные лимиты и приписать свой процесс туда. Пример:

$ cgcreate -g memory:/myGroup
$ echo $(( 500 * 1024 * 1024 )) > /sys/fs/cgroup/memory/myGroup/memory.limit_in_bytes
$ echo $(( 5000 * 1024 * 1024 )) > /sys/fs/cgroup/memory/myGroup/memory.memsw.limit_in_bytes

$ cgexec -g memory:myGroup myProgramm

Утилиты для работы входят в пакет libcgroup-tools (для CentOS). При желании таким же макаром можно прописать ограничения для системных пользователей или групп.

Собственно контейнера lxc по такому принципу и работают.

Дак а чем кончилось то? Деталь свои функции выполняет? Чем лучше или хуже других вариантов исполнения? Как печатали и обрабатывали, где самодвижущиеся картинки?
Да и вообще, чем выгоднее использовать печать а не другие методы?

Все компоненты, из которых он состоит, входят. RedHat продаёт поддержку.
Сам я cluster на базе KVM не разворачивал, но в документации по разворачиванию не вижу привязки именно к RedHat-у, всё необходимое есть и в CentOS.

Я собирал HA Cluster по документации RedHat-а с использованием Pacemaker-а на CentOS и тоже в какие-либо ограничения не наткнулся.

Правда, есть RedHat Linux Atomic Host, ориентированный на использование Docker контейнеров, и тут в документации они акцентируются на подписке. Но опять же не ясно, на сколько будет ограничено использование без неё. Есть подозрение, что подписка даёт только доступ к RedHat-репозиторию docker-контейнеров.

В общем, документация RedHat-а + CentOS — отличная база для смелых, интересных и дешёвых экспериментов.

Не совсем корректное сравнение. oVirt или RedHat cluster, который никто не мешает использовать на базе соответствующего CentOS с одной стороны и платная поддержка за сервис или решения из коробки с другой.

GFS2?

У CentOS-а хорошо.
access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/High_Availability_Add-On_Overview/index.html
Тот же gfs2 из коробки, CLVM.
Правда, как и чем работает oVirt пока не знаю — не изучал.

RedHat продвигает своё решение на базе kvm — тоже большой простор для изучения.
access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/index.html

Я тут усиленно повспоминал и пришел к выводу, что раньше мог просто не заметить возможные тормоза. До этого использовал ESXi 5.5 с последующим обновлением до 5.6 и сервер nfs на CentOS 6.x. Виртуальные машины были не большие и не критичные, особо статистику не собирал, бэкапятся — да и ладно.
На новом месте ESXi 5.1 и FreeNAS 9.3 — проблем не наблюдаю. Протестировать в других связках пока нет возможности. Но интересны результаты и решение. Надо будет поразбираться в вопросе.

Странно. Я на нескольких серверах и разных версиях разворачивал подобную схему, но нигде не натыкался на проблемы со скоростью. Сервером выступал как FreeNAS, так и CentOS разных версий. На FreeNAS сейчас работает сжатие и дедубликация. Параметры монтирования на FreeNAS:
backup/vmware on /mnt/backup/vmware (zfs, NFS exported, local, noatime, nfsv4acls)

Последний бэкап машин объёмом 159Г прошел за 3:30, то есть ~ 12.9Мб/с.

Специально протестировал скорость на тот же сервер:
# time dd if=/vmfs/volumes/local_vm02/iso/CentOS-6.5-x86_64-minimal.iso of=/vmfs/volumes/backup/tmp.data bs=1M
398+0 records in
398+0 records out
real 0m 7.80s

# du -h /vmfs/volumes/backup/tmp.data
381.3M /vmfs/volumes/backup/tmp.data

То есть 48Мб/с, что более чем достаточно.

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

Именно для кластера нет, но отлично работает на каждой ноде в отдельности. Собственно так и настраивал.

А как же организация «холодных коридоров»? Было бы интересно почитать про практическое применение.

По движению похоже, что капли ведут от магнита к магниту по матрице из магнитов, меняя силу магнитного поля у соседних ячеек. От сюда и залипательный эффект отставших частичек, когда они падают или цепляются за соседние ячейки.

А можно ещё спину застудить с последующим защемлением седалищного нерва, и тогда правильная осанка появится сама собой, но это уже тема для статьи на другие ресурсы ;).