<html><body><span style="display:block;" class="xfm_46740013"><div><span style="font-size:12pt;line-height:14pt;font-family:Arial;" class="xfmc1">Привет,</span><br/></div>
<div><span style="font-size:12pt;line-height:14pt;font-family:Arial;" class="xfmc1"><br data-mce-bogus="1"/></span></div>
<div><span style="font-size:12pt;line-height:14pt;font-family:Arial;" class="xfmc1">BGP перестройка, флап, ретрансмиты от потерь, смена канала при отказе основного канала связи - это те же ситуации, когда нет кворума, ты не успеешь их диагностировать. </span></div>
<div><span style="font-size:12pt;line-height:14pt;font-family:Arial;" class="xfmc1"><br data-mce-bogus="1"/></span></div>
<div><span style="font-size:12pt;line-height:14pt;font-family:Arial;" class="xfmc1">Надо очень хорошо понимать софт и его специфику работы с файлами, чтобы выбрать то решение, которое будет подходить.<br data-mce-bogus="1"/></span></div>
<div><br data-mce-bogus="1"/></div>
<div><br data-mce-bogus="1"/></div>
<div><i><span style="font-size:10pt;line-height:12pt;"><span style="font-family:Arial;">15 листопада 2021, 18:24:19, від
"Volodymyr Litovka" <</span><a href="mailto:doka@funlab.cc" target="_blank"><span style="font-family:Arial;">doka@funlab.cc</span></a><span style="font-family:Arial;">>:
</span></span></i></div>
<div><br/></div>
<blockquote style="border-left:1px solid #cccccc;margin:0px 0px 0px 0.8ex;padding-left:1ex;">
<div style="display:block;">
<div>Я думаю, что такую ситуацию следует обходить именно шатдауном
обслуживающего софта в случае выпадания ноды из кластера.</div>
<div>Если речь идет о том proprietary софте, то я его просто
пейсмейкером уложу на failed active node и сделаю новую active -
перенесу Virtual IP и запущу сервисный инстанс.</div>
<div>Полагаясь всё же на внутренние механизмы синхронизации файловой
системы, когда всё наладится.</div>
<div>И да - очевидно, что именно три ноды.</div>
<div>On 15.11.2021 17:48, Vladimir Sharun
wrote:</div>
<blockquote type="cite" style="border-left:1px solid #cccccc;margin:0px 0px 0px 0.8ex;padding-left:1ex;">
<div></div>
<div style="display:block;">
<div><span style="font-size:12pt;line-height:14pt;font-family:Arial;">Привет,</span></div>
<div><span style="font-size:12pt;line-height:14pt;font-family:Arial;"><br/></span></div>
<div><span style="font-size:12pt;line-height:14pt;font-family:Arial;">Во время отсутствия кворума нода
по-правильному не работает вообще (так например поступает
Эластик), чтобы не допустить split brain - вот такой
conflict resolution. Read only в ситуации split brain
приведет к неверным принятиям решений. Ну например ты
смотришь остаток на счету в одной ноде и это Х, а в другой
ноде там уже больше/меньше. Т.е. при read only ситуация всё
равно плохая.</span></div>
<div><span style="font-size:12pt;line-height:14pt;font-family:Arial;"><br/></span></div>
<div><span style="font-size:12pt;line-height:14pt;font-family:Arial;">Я рассматривал подобное решение для банкинга
(бабки, платежи) в ситуации нескольких датацентров "в
кластере", оказалось что файловые системы мягко говоря не
подходят. </span></div>
<div><span style="font-size:12pt;line-height:14pt;font-family:Arial;">Именно потому что аппликейшн не в курсе, что
не может писать например или, что еще хуже: прочитал,
попытался записать, получил "рид онли", взял паузу, ФС
разблокировалась+просинхронизировалась, а ты сделал запись в
уже ДРУГОЙ файл (классический race).</span></div>
<div><span style="font-size:12pt;line-height:14pt;font-family:Arial;"><br/></span></div>
<div><span style="font-size:12pt;line-height:14pt;font-family:Arial;">Вот такая вот защита от split brain она очень
виртуальная. Софт должен понимать что что-то может не
работать и иметь механизмы conflict resolution'а</span></div>
<div><span style="font-size:12pt;line-height:14pt;font-family:Arial;"><br/></span></div>
<div><span style="font-size:12pt;line-height:14pt;font-family:Arial;">PS: совсем эдж кейс шарить таким образом файлы
embedded database'ов типа bdb/sqlite</span></div>
<div><br/></div>
<div><i><span style="font-size:10pt;line-height:12pt;"><span style="font-family:Arial;">15 листопада 2021, 17:04:00,
від "Mykola Ulianytskyi" <</span><a href="mailto:lystor@gmail.com" target="_blank"><span style="font-family:Arial;">lystor@gmail.com</span></a><span style="font-family:Arial;">>:
</span></span></i></div>
<div><br/></div>
<blockquote style="border-left:1px solid #cccccc;margin:0px 0px 0px 0.8ex;padding-left:1ex;">
<pre style="margin:5px 0;">> У тебя очевидная проблема будет при split brain, очевидная необходимость в conflict resolution. Файловая система не даёт таких возможностей.
Даёт. С тремя нодами всё будет ок.
Client quorum:
This is a feature implemented in Automatic File Replication (AFR here
on) module, to prevent split-brains in the I/O path for
replicate/distributed-replicate volumes.
By default, if the client-quorum is not met for a particular replica
subvol, it becomes read-only.
<a href="https://docs.gluster.org/en/v3/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/" target="_blank" rel="noreferrer noopener">https://docs.gluster.org/en/v3/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/</a>
</pre>
</blockquote>
</div>
</blockquote>
<pre style="margin:5px 0;">--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison</pre>
</div>
</blockquote></span></body></html>