Добр день. Хочется услышать совет от толковых парней использующих DRBD в продакшене.

О drbd думаю в разрезе отказоустойчивого общего стоража для ESXi. Познания о drbd только чисто теоретические. Интересная штука DRBD, но все с кем общался, использовали primary - slave и отказались от DRBD в следствии низкой производительности на запись. Но никто (из знакомых) не пробовал вариант актив-актив на запись.

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

Как улучшить производительность дисковой вопросов не вызывает. Вопрос в производительности линка для реплики. Гигабит имхо избыточен для линка (только для первичной репликации будет явное преимущество), главное обеспечить низкую латентность Имеет ли смысл поставить двухпортовую сетевую карту на каждую ноду, бондинг Round robin + свич с Port trunking? Bonding опять же знаком теоретически, потому не все понятно - будет ли первый пакет - налево, второй пакет направо, учитывая что бндинг будет с обоих сторон?

Имеет ли смысл использовать оптические карты для линка репликации (в каждую ноду по карте и соединить их кросом) или изменение физической среды не принесет профита?

На одном из форумов предложили вариант drbd актив-актив + кластерная фс + loopback device + iscsi + vmfs Оч много прослоек, имхо скажется на цпу, но для современных процов это не смертельно. На запись производительность опять же упрется в латентность линка для реплики. Будет ли возможно чтение с обоих нод (в варианте актив-пассив читает только с актив ноды по понятным причинам)? При условии что данные запрошенные для чтения уже реплицированы)

Если у кого есть опыт использования и желание ответить - прошу, не стесняйтесь ))

Добрый день.

Запускаю много-много вм ) Вываливаюсь в своп не смотря на то что cached мог бы и подвинуться. sync && echo 1 > /proc/sys/vm/drop_caches помогает и после этого запускаю еще одну виртуалку, без вываливания в своп. своп кстати выставлен в ноли vm.swappiness=0 но судя по vmstat в своп пишет все равно. Можно записать в крон дропать кеши, но это какой то педальный способ.

Почитал всякое о параметрах /proc/sys/vm

Думал-думал, сложилась следующая картина

в условиях нехватки свободной памяти происходит сканирование памяти на предмет dirty страничек частота сканирования задается через параметр dirty_writeback_centisecs после нахождения dirty pages ядро сравнивает их «возраст» с параметром dirty_expire_centisecs если возраст страницы больше или равно - записать их на диск

размер dirty страниц максимальный размер страничек порожденных одним процессом (лимит, после которого они в обязательном порядке будут записаны) устанавливается через dirty_ratio в процентах от общего размера памяти

dirty_background_ratio Минимальное число памяти (в процентах), где позволено хранить гразные данные вместо записи на диск. Этот параметр должен быть намного меньше чем dirty_ratio что бы позволить записывать куски грязных данных за один проход. по идее оно должно быть равно размеру (или четным) блока файловой системы во избежание фрагментации

по идее необходимо увеличить частоту сканирования (увеличится энергопотребление) и нагрузка на винт понизить dirty_expire_centisecs (больше страниц попадает под запись)

понизить dirty_ratio понизить dirty_background_ratio (но не меньше dirty_ratio) и не меньше чем размер блока на фс

покрутил параметры и так и этак - стали активно чистится buffers

не понимаю что такое cached и как управлять какое колво памяти выделять под них.

swapoff -a в своп больше не пишет ) стало легче.

но хотелось бы быть уверенным, что я правильно понял и осознать про cached ...