очередь И/О на дисках и разные RAID-контроллеры

[Иван Пахомов]

всем привет!
у одного заказчика интересная картина. 4 аппаратных сервера в кластере. на них крутится domino v10 как платформа для системы документооборота
система достаточно нагруженная, как мы считаем (может, это и не так?). веб-приложение, система документооборота с воркфлоу. в час примерно 3000 уникальных пользователей, в день - до 4500
все базы данных поделены - на 7 отдельных разделах сами данные NSF, NIFNSF, FTI, DAOS, TL, ViewRebuild, ОС и программные файлы
как советовал потрясающий Stephan Wissel тут:

Ссылка скрыта от гостей

при этом на одном сервере всё крутится более менее хорошо, 3 остальных тормозят
стали разбираться - очередь И/О на дисках. на первом средняя ниже 1, на трёх остальных постоянно скачет доходит до 100, иногда до 300
спрашиваем у администраторов железа, в чём может быть причина. говорят, что на первом сервере 2 RAID-контроллера, на остальных - по одному один
искал рекомендации от вендора или чемпионов. нашёл только тут:

Ссылка скрыта от гостей

(слайды 16-19)

The “Best-Case” is multiple drives on different drive controllers - «Лучший вариант» - это несколько дисков на разных контроллерах.

может ли только в этом быть причина? есть ли какие-то более свежие указания на то, как конфигурировать аппаратные серверы под Domino? есть ещё какие-то ссылки?

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

 

[garrick]

Взять калькулятор и посчитать пропускную способность контроллера и объём данных. Два контроллера конечно будут работать быстрее чем один.

 

[Иван Пахомов]

Взять калькулятор и посчитать пропускную способность контроллера и объём данных

а как понять объём данных? они же пишутся постоянно. нельзя взять просто прирост данных за день. при том, что меняются поля документов, перезаписываются в процессе воркфлоу. есть идеи, как посчитать объём записываемых и читаемых данных?

 

[garrick]

Если на самом рейде статистики такой нет, то точно посчитать невозможно. Но примерно прикинуть - да, прирост данных за день помножить на 2 или 3 (чтение/изменение). Можно конечно и более точно посчитать если учесть сколько документов в workflow меняется за день, какие поля и сложить размер этих полей. Плюс всякие логи, журналы, временные файлы и пр.

Если у вас скорость чтения/записи, например 10Мб в сек., а вы только 8 или 9 из них записываете, то понятно же, что на чтение у вас просто уже ничего не остаётся.

 

[aameno2]

raid на всех серверах одинаковый? модели дисков еще.

 

[Иван Пахомов]

raid на всех серверах одинаковый? модели дисков еще.

Нет, увы, серверы разной поставки, разные производители. Скорее всего и внутри всё разное. Хорошее - депо, не очень - аквариус. Не знаю, играет ли роль

 

[aameno2]

я имел ввиду тип) 5,6,10 ?
Кто то быстро читает, но долго пишет и наоборот. В общем то рейд уже не безопасно, увы.

 

[Иван Пахомов]

я имел ввиду тип) 5,6,10 ?
Кто то быстро читает, но долго пишет и наоборот. В общем то рейд уже не безопасно, увы.

На быстром 10й, на медленных может быть 1й. Надо смотреть

 

[lmike]

На быстром 10й, на медленных может быть 1й. Надо смотреть

на запись 1-ый медленный

 

[Иван Пахомов]

коллеги, наверняка среди нас есть гуру линкса ) может, кто-то решал такую задачу:
в лине нарезаны разделы, а разделы используются под одну или несколько задач Domino (NSF, FTI, NIFNSF, DAOS, TL, Rebuild, Temp).
есть задача:
понять, какие задачи насколько потребляют ресурсы диска, понять количество операция чтения записи и длину очереди в динамике или хотя бы в пике
для вывода такой информации по разделам есть команда iostat. а можно ли такую инфу вытащить по заданным каталогам?

на запись 1-ый медленный

а вот это существенно, спасибо за коммент!

 

[lmike]

коллеги, наверняка среди нас есть гуру линкса ) может, кто-то решал такую задачу:
в лине нарезаны разделы, а разделы используются под одну или несколько задач Domino (NSF, FTI, NIFNSF, DAOS, TL, Rebuild, Temp).
есть задача:
понять, какие задачи насколько потребляют ресурсы диска, понять количество операция чтения записи и длину очереди в динамике или хотя бы в пике
для вывода такой информации по разделам есть команда iostat. а можно ли такую инфу вытащить по заданным каталогам?


а вот это существенно, спасибо за коммент!

еще добавлю...
- рейды 0 - для скорости, но данные там хранить нельзя
если переиндексация (умер диск) не будет критичной - ставить такой
- рейды 5, 6 - это при дороговизне хранилища, эконом вариант, НО 5- ваще не имеет права на жизнь (даже статьи были) - вероятность про..ть ошибку при записи, учитывая объемы, стала вполне реальной. 6-ой очень медленный на запись и не быстрый на чтение. Вощем - не использовать и точка
- 1 аки зеркало - всё предсказуем, пишем на диск, синхроним в зеркало - отсюда медленная запись, чтение быстрое, т.к. происходит с произвольго диска в параллель
- 10 зеркало + страйп (т.е. 1+ 0) страйп - чередование при записи с очевидным профитом
перевожу
- жалко денег, не критична потеря данных - 0 адназначна, на таких обычно рендерят в киношной индустрии
- бэкап - 1 (зеркало), 10 не имеет смысла (скорость записи не так некритична)
остальное 10+ (+ для старйпов нескольких зеркал)
ССД - для индексов адназначно или инмемори (рамдиск) со сбросм на диск при аварии (здесь от ОС зависит реализация)

Есть варианты гибридов компановки ССД+ХДД, но перемещение "горячих" данных требует реализации и времени, во всяких полках с мозгами (типа нетапов) это как-то реализуется, ябы не доверял... (полки в зеркале - это очень затратно, а ошибки в прошивке не являются чудом)

измерение ИОПСов - тонкая материя, нагрузка обычно синтетическая, любая прикладуха, помимо кэшей ФС использует и собственные "оптимизации" - это не измерить тестами, ток наблюдение при разных нагрузках при использовании
я не вижу смысл измерять каталоги, совсем не вижу из перечисленных выше причин
сетевые стораджи имеют высокий ИОПС, но также высокие задержки, с кот. борьба на уровне протоколов и железа (оптика и вся вот эта х..ня)

имеет ли это смысл для домины? - КМК не очень, часто в домине тормоз не диск, а логика приложения...

 

[Иван Пахомов]

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

 

[aameno2]

Есть варианты гибридов компановки ССД+ХДД, но перемещение "горячих" данных требует реализации и времени, во всяких полках с мозгами (типа нетапов) это как-то реализуется, ябы не доверял... (полки в зеркале - это очень затратно, а ошибки в прошивке не являются чудом)

Рейд вообще стал злом, с текущими размерами дисков. Я оставил его только для системы, да и то не везде.
Все это делается в цефе, не к ночи он будет упомянут, если только не нужно перемещать данные в живую между горячим и холодным пулами. Хотя....тоже можно навелосипедить)
пул хдд, пул ссд и разруливается все прекрасно. Минусов несколько, дорого (не сравниваем с брендовыми решениями конечно), долго и нервно.

 

[Иван Пахомов]

Все это делается в цефе, не к ночи он будет упомянут

а можно небольшой ликбез или ссылку, что это и с чем едят. как нежелезячник, не сталкивался ранее. ну и видимо, раз мы про это не слышали, у заказчика всё несколько олдово?

 

[aameno2]

а можно небольшой ликбез

извините, это видимо оффтоп. Ceph это sds. Видимо у вашего заказчика достаточно старая архитектура и железо и он еще не терял данные на рейде.
Получается наследие, гдето массив в зеркале а гдето 5й или 6й рейд . Еще и домино стоит на железном сервере небось. Как результат вы имеете просадку.
Переход на sds и виртуальные машины это может убрать. Если важна скорость то хранилище нужно all-flash. Но это не дешево.
В вашем варианте, бюджетно заменить диски на ссд и поставить все в зеркало (10й). Главное помнить, что raid это 1987 год

 

[Иван Пахомов]

Еще и домино стоит на железном сервере небось

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

 

[aameno2]

на той же схд файлшары

Если схд еще и iscsi то не удивительно. А если еще и гипервизор esx...

 

[lmike]

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

@aameno2 описывал скоростную сеть с низкими задержками и распределёнными узлами сетевой ФС (Ceph)
там и дублирование (но уже на уровне узлов сети) и распределение запросов
такие сети обычно >10Gbs с соответ. сетевым железом... (и архитектурой), кроч - очень не дёшево
iscsi - это отдельный разговор, как пр-ло её не любят

по гипервизорам - вмтварь имеет свои заморочки и контейнеры хранилищ, квм - зависит от обвязки и настройки (но по неё можно разлчные менеджеры томов подсовывать), ХуперВу - это нтфс (я её очень не лю), перепиленный опенСвитч (программируемая сеть) и куча кастылей от МС
в ДЦ могут быть представлены все
у мя мелкая сеть и немного виртуалок и контейнеров, мну нра proxmox с oVSwitch , меня устраивает, нагрузка небольшая
самый большой+ ZFS
домина в контенерах - минимальные издержки по IOPS
из короткого общения с Нешедом - он склоняется к ZFS