forum.searchengines.ru/showpost.php?p=10222192&postcount=1279
интересно, а почему они просто у себя не поправят, чтобы ns3 и ns4 выдавал разные IP адреса, несколько штук?
я бы даже сказал — ns3 и ns4 перекинуть на новые, а ns1 и ns2 сделать на старые…
Н-да. Действительно становится интерсно. На днях ресайзил рейд на cciss (пулреквест на гитхабе).
так ребутить пришлось дважды сервер: первырй раз чтоб прочухал что рейд стал втрое больше
второй раз чтоб перечитал после ptmax'а…
зависит от процессора, скорости винтов, объёма памяти, допустимого времени даунтайма, вероятности сбоя.
проще всего — протестировать. мой опыт говорит о том, что 100 мегабайт это уже много.
runtime данные — в mnesia. весь архив и всю аналитику — выкидывать наружу. в postgresql хотя бы.
вы просто посмотрите сколько займёт старт системы после некорректного шатдауна хотя бы с 300 метрами данных. потом с гигом. если не дошло — то еще с двумя. дальше, думаю, не понадобится.
не знаю, а что я делаю не так? я пишу код трансформации в апгрейде. соответственно на момент апгрейда происходит суспенд, апгрейд таблицы, ансуспенд. так как таблицы все небольших размеров — проблем не доставляет, даже дефолтного таймаута в 5 секунд достаточно.
а если кто-то попытается мне тут сказать что таблицы могут быть и большие, то он огребает себе личных проблем много и надолго. мнезия не работает с большими объёмами. никак. никогда. даже не пытайтесь.
Вроде как эти карты пока не мониторятся и не контролируются, так как теоритически это доход за рубежом, который получаешь на карту зарубежную.
Но по факту… Работаешь-то тут, так что де-юре это доход местный, который ты нелегально обналичиваешь.
А вот тесты там очень и очень куцые и баганутые. Как по формулировкам, так и в принципе по ответам.
Плюс опечатки в заданиях. В общем, Brainbench их делает лучше.
Хмм… А, тьфу ж protocol C… Как по мне, так в ситуациях с мультинодами надо использовать протокол B. Так что вполне можно получить на базе drbd, если убрать эти ограничения.
Хотя, учитывая что для эффективного использования многонод надо что-то типа RAID6 делать, нагрузка на сру увеличится до чёртиков, и не факт что общее решение вида обычного процессора под это дело будет эффективно.
Потому может и нету FOSS решений — тупо из-за неэффективности.
А это точно latency именно DRBD, а не сетевого стека?
На inifniband'е вроде latency должен приближаться к нулю…
По крайней мере, гораздо ниже чем на гиге.
Кстати, что-то до меня тихо доходит, что нельзя линейно масштабировать оставляя выживаемость на уровне половины.
Число копий должно быть больше числа машин, допустимых к смерти. То есть если у нас 5 машин и допустима смерть 2х машин, это надо тройную копию. Соответственно, пространство масштабироваться будет совсем не линейно, и толку становится не много…
Мы имеем в итоге пространство равное 3/5 от суммарного… в принципе, это уже лучше, чем 1/2.
С другой стороны — это же лучше, чем 2 машины и допустимо сдыхание только одной…
Что-то даже и не знаю. Может, попытаться обточить напильником drbd? Используя мультикаст адреса для связи, вполне можно оставить траффик на приемлимом даже для gige уровне ведь.
В случае всё тех же 5 нод и 3х копий, запись в один слайс будет отсылаться на мультикаст, который ловить будут две ноды — но отсылка одна, надо только будет дождаться ответа не от одной, а от двух нод.
В принципе, отличие будет не сильно велико от двунодового кластера. А читать можно будет с трёх дисков, что даст сильную прибавку в случае обычных SATA дисков.
И позволит получить плюс, при использовании SAS дисков и минимум 3хгигабитному линку между ними…
От drbd я уже отказался, после нескольких весёлых дней и ночей с brainsplit, тормозами на ресинхронизации и глюками после ресайза.
А глустер не понравился скоростью.
Кстати… А есть организации блочного рейда а-ля drbd но на 3 и более нод? Чтоб слить десяток нод в единое пространство, которое живо пока жива хотя бы половина их.
drbd такое не позволяет — «многоуровневая» схема становится негомогенной…
интересно, а почему они просто у себя не поправят, чтобы ns3 и ns4 выдавал разные IP адреса, несколько штук?
я бы даже сказал — ns3 и ns4 перекинуть на новые, а ns1 и ns2 сделать на старые…
так ребутить пришлось дважды сервер: первырй раз чтоб прочухал что рейд стал втрое больше
второй раз чтоб перечитал после ptmax'а…
проще всего — протестировать. мой опыт говорит о том, что 100 мегабайт это уже много.
runtime данные — в mnesia. весь архив и всю аналитику — выкидывать наружу. в postgresql хотя бы.
а если кто-то попытается мне тут сказать что таблицы могут быть и большие, то он огребает себе личных проблем много и надолго. мнезия не работает с большими объёмами. никак. никогда. даже не пытайтесь.
Но по факту… Работаешь-то тут, так что де-юре это доход местный, который ты нелегально обналичиваешь.
Плюс опечатки в заданиях. В общем, Brainbench их делает лучше.
Хотя, учитывая что для эффективного использования многонод надо что-то типа RAID6 делать, нагрузка на сру увеличится до чёртиков, и не факт что общее решение вида обычного процессора под это дело будет эффективно.
Потому может и нету FOSS решений — тупо из-за неэффективности.
Но это именно что извращения, так как нода, которая будет держать mdadm будет SPOFом
На inifniband'е вроде latency должен приближаться к нулю…
По крайней мере, гораздо ниже чем на гиге.
Число копий должно быть больше числа машин, допустимых к смерти. То есть если у нас 5 машин и допустима смерть 2х машин, это надо тройную копию. Соответственно, пространство масштабироваться будет совсем не линейно, и толку становится не много…
Мы имеем в итоге пространство равное 3/5 от суммарного… в принципе, это уже лучше, чем 1/2.
С другой стороны — это же лучше, чем 2 машины и допустимо сдыхание только одной…
Что-то даже и не знаю. Может, попытаться обточить напильником drbd? Используя мультикаст адреса для связи, вполне можно оставить траффик на приемлимом даже для gige уровне ведь.
В случае всё тех же 5 нод и 3х копий, запись в один слайс будет отсылаться на мультикаст, который ловить будут две ноды — но отсылка одна, надо только будет дождаться ответа не от одной, а от двух нод.
В принципе, отличие будет не сильно велико от двунодового кластера. А читать можно будет с трёх дисков, что даст сильную прибавку в случае обычных SATA дисков.
И позволит получить плюс, при использовании SAS дисков и минимум 3хгигабитному линку между ними…
А глустер не понравился скоростью.
drbd такое не позволяет — «многоуровневая» схема становится негомогенной…