[uanog] distributed FS

[Alexander V Soroka]

Привет !

нуууу.....
Если все на файловую систему перекладывать то некомильфо это.

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

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

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

Как-то так ...
Это  вообще-то  из области "параллельных процессов на параллельных ядрах
ЦП"(параллельных  потоках),  тут  можно очень красивые вещи делать, для
быстрой обработки огромного массива данных.

Но  если  все  свести  "вот он Самый Главный а все на него смотрят" то
получится Большой Тормоз, вместо "кластерного параллельного решения".

Monday, November 15, 2021, 6:24:10 PM, Volodymyr Litovka doka at funlab.cc you wrote:
VL> Я думаю, что такую ситуацию следует обходить именно шатдауном
VL> обслуживающего софта в случае выпадания ноды из кластера.

VL> Если речь идет о том proprietary софте, то я его просто
VL> пейсмейкером уложу на failed active node и сделаю новую active -
VL> перенесу Virtual IP и запущу сервисный инстанс.

VL> Полагаясь всё же на внутренние механизмы синхронизации файловой системы, когда всё наладится.

VL> И да - очевидно, что именно три ноды.

VL> On 15.11.2021 17:48, Vladimir Sharun wrote:
>> Во время отсутствия кворума нода по-правильному не работает вообще > (так например поступает Эластик), чтобы не допустить split brain - вот > такой conflict resolution. Read only в ситуации split brain приведет к > неверным принятиям решений. Ну например ты смотришь остаток на счету в > одной ноде и это Х, а в другой ноде там уже больше/меньше. Т.е. при > read only ситуация всё равно плохая.
>>
>> Я рассматривал подобное решение для банкинга (бабки, платежи) в > ситуации нескольких датацентров "в кластере", оказалось что файловые > системы мягко говоря не подходят.
>> Именно потому что аппликейшн не в курсе, что не может писать например > или, что еще хуже: прочитал, попытался записать, получил "рид онли", > взял паузу, ФС разблокировалась+просинхронизировалась, а ты сделал > запись в уже ДРУГОЙ файл (классический race).
>>
>> Вот такая вот защита от split brain она очень виртуальная. Софт должен > понимать что что-то может не работать и иметь механизмы conflict > resolution'а
>>
>> PS: совсем эдж кейс шарить таким образом файлы embedded database'ов > типа bdb/sqlite
>>
>> /15 листопада 2021, 17:04:00, від "Mykola Ulianytskyi" > <lystor at gmail.com <mailto:lystor at gmail.com>>: /
>>
>>     > У тебя очевидная проблема будет при 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.
>>
>>     https://docs.gluster.org/en/v3/Administrator%20Guide/Split%20brain%20and%20ways%20to%20deal%20with%20it/
>>


-- 
Best regards,
Alexander V Soroka       http://www.svr.ua/
AS106-RIPE
mailto:alex at euro.net.ua