Наглядное сравнение I/O

zfs со сжатием туда и рамы под кэш побольше

Ок, добавим входных данных.
SLES 11, ext3,ядро 2.6, оперативки 96Gb

оперативки 96Gb

логи пиши в оперативку, параллельно в фоне сжимай и скидывай на диск.

логи пиши в оперативку

разумное предложение
Нужно ещё исходных данных.
Их есть у меня:
сервер резервируется (это нода кластера), питание резервируется, раздел - RAID5, примонтированный по FC с дискового массива.
Потеря логов неприемлема.

Какие есть варианты обеспечения сохранности данных в оперативке при различных сценариях отказа?

Какие есть варианты обеспечения сохранности данных в оперативке при различных сценариях отказа?

Считай что ramdisk == дисковый кеш (в оперативке который)

Вывод: быстрая обработка (сжатие) и сброс на диск. В оперативке минимум того что можно потерять в случае внезапной паники ядра (остальное у тебя дублируется). Собственно и логи надо бы раздуплить на два сервера.

В оперативке минимум того что можно потерять

какой процент из 96 гигов составляет этот минимум?

минимум зто то что еще не сжато и не сброшенно на диск. Т. к. CPU свободен, то сжатие текстовых логов даст снижение дискового IO и система будет справляться со своими обязанностями лучше чем сейчас

как вариант, сжимать в логгере и на диск писать уже «бинарный» лог

у тебя

сервер логов, который упирается в I/O

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

Так что не задавай мне наивных вопросов

Слать данные в локальной сети на другой сервер который будет заниматься только сохранением логов, обеспечив ему независимое питание + ибп.

LOL, писатель в треде

Раз уж мы так углубились, то нужно ещё исходных данных
Сервер собирает логи с других серверов по sftp (удаляя забранное), парсит, сортирует их итд. Это не syslog сервер, логи текстовые

iostat -x показывает много характеристик: операций в секунду, килобайт в секунду, среднее время обслуживания и среднюю длину очереди. а также комплексную характеристику: процент утилизации. Из каких соображений он его считает, правда, не знаю.

воткни туда raid 10 на куче ssd

парсит, сортирует их итд

ну либо ты добавляешь в конце цепочки сжатие для уменьшения IO либо наращиваешь IO. Какие еще варианты? добавить еще сервер слишком банально и очевидно

Воу, воу, палехчи паринь

ну либо ты добавляешь в конце цепочки сжатие для уменьшения IO либо наращиваешь IO. Какие еще варианты?

Я не говорю об прорывных улучшениях.
В идеале мне хватило бы всего несколько процентов выигрыша, чтобы сгладить пики I/O.
Если мы закончили обсуждать варианты с изменением архитектуры/конфигурации железа, то можно было бы вернуться к моему изначальному вопросу, например

какой планировщик стоит?
попробуй bfq

Выше уже сказали - iostat. По его выхлопу можно любым офисом графики строить.

про iostat думал, но были сомнения про сбор статистики за длительный период.
но гугл спас отца русской демократии, спасибо за вектор

Сервер собирает логи с других серверов по sftp (удаляя забранное), парсит, сортирует их итд

Качаешь логи на рамдиск, парсишь-сортируешь, сжимаешь, записываешь на диск, удаляешь с исходного сервера.
В каждый момент времени логи есть на хотя-бы одном диске, при-этом на диск обсуждаемого сервера пишется только необходимый минимум.

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

К примеру, я сходу даже не скажу, как должна вести себя эта связка если сервер с исходными логами ушёл в ребут пока его файл обрабатывались

Сервер логов продолжает идти по алгоритму, а когда дойдёт до удаления исходного файла то пытается заново подключиться (в любом случае нет нужды оставлять открытое соединение по завершении скачивания) к серверу-логописателю (пытается пока не получится) и удаляет файл.
Тут-то как-раз и писать почти ничего не надо, только обработку ошибки подключения к поставщику логов.

Интереснее сценарий когда на одном из этапов работы дохнет сам сервер обрабатывающий логи. Но думаю и тут можно обойтись без дополнительных сущностей. Как сервер узнаёт что где-то какие-то логи надо скачать и обработать? Обходит все сервера и если находит неудалённые логи то тырит их? Тогда если файл есть на сервере-логописателе то это либо новый файл (и его надо скачать и обработать) либо файл который не удалось обработать когда-то раньше (и его надо скачать и обработать). т.е. монопенисуально. Надо только добиться атомарности (или чего-то вроде атомарности) для сдвоенной операции «записать обработанные логи над диск и удалить исходные с удалённого сервера». «Записать обработанные логи над диск» можно заменить на «переименовать ранее записанный файл» (данные пишутся во временный файл на том-же разделе где будут храниться, потом файл переименовывается).
Алгоритм такой: попытаться удалить файл с удалённого сервера, если получиться то переименовать файл на диске. Потеря данных возможна, но только если что-то навернётся в короткий промежуток времени между нужный на две эти операции. Хотя если этот алгоритм будет отрабатывать достаточно часто, и ломаться будет что-то достаточно часто, то достаточно скоро эти события совпадут. Можно посчитать вероятность того что за некоторый период времени будет хотя-бы одна потеря информации, правда я сейчас не соображу как именно это посчитать.

Сори за поток сознания.

iostat

уточни плиз

apt-cache search iostat
sysstat - system performance tools for Linux
dstat - versatile resource statistics tool
ganglia-modules-linux - Ganglia extra modules for Linux (IO, filesystems, multicpu)
ifstat - InterFace STATistics Monitoring
nicstat - print network traffic statistics
pcp-import-iostat2pcp - Tool for importing data from iostat into PCP archive logs
r-cran-epi - GNU R epidemiological analysis
r-cran-epibasix - GNU R Elementary Epidemiological Functions
r-cran-rms - GNU R regression modeling strategies by Frank Harrell

http://habrahabr.ru/post/165855/

спасибо

при различных сценариях отказа?

раньше продавались аппаратные рам-диски с батарейкой на борту

Сценарий:
Я ошибся при установке обновлений, разбил клавиатуру об монитор, в итоге сервер ушёл в ребут, кластер переключился на вторую ноду

Продолжите фразу:
Аппаратный рам-диск с батарейкой на борту поможет тут следующим образом ...

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

тем, что данные останутся на рам-диске?
мда...

тем, что данные останутся на рам-диске?

и ведь и не поспоришь...

и ведь и не поспоришь

аппаратный рам-диск с батарейкой будет для системы выглядеть как обычное блочное устройство, а инструменты чтобы синхронизировать его с нодами кластера на ваш выбор.

Переливаете из пустого в порожнее.

аппаратный рам-диск с батарейкой — железо, которое в самый нужный момент сломается, батерейка потеряет емкость, ...

Решение уже было дано: не удалять лог с источника пока его копия не будет обработана и сохранена. При внештатной ситуации, наличие лога на источнике означает незавершенность транзакции — и ее надо повторить.

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

аппаратный рам-диск с батарейкой — железо, которое в самый нужный момент сломается, батерейка потеряет емкость

с этой же вероятностью может сломаться любая железка на ноде,выход из строя рам-дисков сразу на двух и более нод маловероятен

Выход из строя и ноды и лог сервера одновременно так же мало вероятен как и двух рам-дисков сразу

У меня уже есть довольно быстрый массив на SAS дисках, LUN с которого доступен на обеих нодах как обычное блочное устройство
Ньюанс в том что пишет/читает с него сотня процессов кучу разных небольших файлов, то есть это худший из возможных сценариев I/O - абсолютный random
При этом производительности хватает 99% времени, есть очень кратковременные пики когда busy% прыгает до ~100 и которые я бы хотел попробовать сгладить, при этом LA всё равно остаётся порядка 1.5 (на 32-ядерной железке)
Рам-диск тут пока кажется излишним

Рам-диск и SAS не вижу связи для аналогии, аппартный рам-диск это устройство состоящие из аппаратной оперативной памяти

Никаких журналов не надо. Никакого особого железа не надо. Особых изменений тоже почти нет

Мм..не факт...хотя идея и интересная, но надо всё тестировать чтобы не упереться в неожиданный bottleneck
В идеале и сильно упрощённо всё выглядит конечно просто
1. Процесс-обработчик1 забирает лог_Х с remotehost
2. Процесс-обработчик2 обрабатывает лог_Х, по окончанию работы даёт сигнал процессу3
3. Процесс-обработчик3 удаляет лог_Х с remotehost

Процесс-обработчик3 удаляет лог_Х с remotehost

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

Я бы не сказал, что это неожиданность.
Это по сути неподтверждённая транзакция, логично провести её ещё раз
Вопрос с исключением дублирования конечно надо будет прорабатывать

Для начала надо прикинуть какой процент времени система будет находиться в неконсистентом состоянии, и следовательно какова вероятность дублирования данных при выходе из строя одного из её элементов. Если вероятность слишком высока то надо что-то дополнительно «подпирать», либо уменьшать продолжительность неконсистентного состояния.

P.S. правильно я понимаю что нельзя «дёшево» реализовать одновременную запись в разделяемый дисковый массив обоими серверами?

Процент времени думаю порядка 0.001%

Кластер - Active/Standby, всё решение на это заточено, задёшево переделать нельзя.

Процент времени думаю порядка 0.001%

Это ты посчитал или с потолка? Сколько в среднем занимает одна этерация (сачать-обработать-записать-удалить), сколько одновременно происходит этераций, сколько занимает удаление и переименование (тут надо заложить запас на непредсказуемость сетевых задержек)?

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