Комментарии 1
Почему бы к этому описанию Byzantine Fault Tolerance не добавить формализованный критерий отказа и марковскую цепь (граф состояний \ переходов). Можно это сделать вообще только с ИИ (никаких пакетов надёжности не нужно), см. тут.
мониторинг показывает зелёный статус, а реальная запись не проходит.
Видимо речь про скрытый (необнаруженный собственными средствами кластера) отказ. Byzantine Fault Tolerance – видимо нечто подобное, но моделируемое отдельным состоянием (разновидность latent fault).
Он формально жив, но работает неправильно или недостаточно хорошо: заканчивается память, переполняется диск, растёт задержка, отстаёт репликация, зависает ввод-вывод.
Для подобного иногда предусматривают состояние: работоспособное, но с ограниченным временем, т.е. режим деградации Х (Х – уровень деградации) допустим в течении часа, а потом считается, что это отказ, хотя уровень деградации остался тем же.
Полагаю, что:
- в статье "Модель отказов" = набор критериев (скорее причин) отказа кластера класса BFT (класс отказов), хотя "модель надежности" - это про состояния, интенсивности переходов и т.п.
- «где есть риск злонамеренного поведения» - это уже про живучесть.
… он не рассылает разным участникам противоречивую информацию.
Перегрузка, отставание репликации, зависший ввод-вывод или неправильная диагностика не являются византийскими отказами.
Понятие «необнаруженного отказа» - предполагает, что есть отказ, но узел все равно выдает «пока жив» (keep alive). Однако есть противоположность: узел реально работает и обслуживает нагрузку, но выдает сигнал «неисправен». Можно в модели предусмотреть такое состояние «Ложный отказ» ("наговаривает" на отказ).
От модели отказов к реальной системе
А где была модель? Хотелось бы увидеть формальную модель и с визуализацией. Кроме графовой модели BFT хорошо бы показать гибрид CFT \ BFT (общий случай отказоустойчивость + живучесть).
Вообще какие показатели надёжности (отказоустойчивости) в BFT?

Нужна ли вашей распределённой СУБД византийская отказоустойчивость?