[uanog] distributed FS

[Vladimir Sharun]

Привет,

BGP перестройка, флап, ретрансмиты от потерь, смена канала при отказе основного канала связи - это те же ситуации, когда нет кворума, ты не успеешь их диагностировать.

Надо очень хорошо понимать софт и его специфику работы с файлами, чтобы выбрать то решение, которое будет подходить.


15 листопада 2021, 18:24:19, від "Volodymyr Litovka" <doka at funlab.cc>:

Я думаю, что такую ситуацию следует обходить именно шатдауном обслуживающего софта в случае выпадания ноды из кластера.
Если речь идет о том proprietary софте, то я его просто пейсмейкером уложу на failed active node и сделаю новую active - перенесу Virtual IP и запущу сервисный инстанс.
Полагаясь всё же на внутренние механизмы синхронизации файловой системы, когда всё наладится.
И да - очевидно, что именно три ноды.
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>:

> У тебя очевидная проблема будет при 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/
-- 
Volodymyr Litovka
  "Vision without Execution is Hallucination." -- Thomas Edison
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20211115/c63459ed/attachment-0001.html>